Mark,
I agree that the best approach would be for protocol designers to do it right
the first time. However we do not live in that world.
In practice we are still going to need a security policy layer because of the
need to protect changes in cryptographic algorithms against downgrade attack.
We also have a big problem due to the legacy 'crypto-perfectionism' approach to
security. Protocol designers are actively discouraged from putting security
into their protocols because they hear scare stories about the consequences of
doing it wrong. Empirically nobody has ever got it 100% right but this does has
not mattered, crooks are not exploiting bad crypto, they are exploiting lack of
crypto.
I would rather provide an open and extensible architecture that allows a
protocol designer the means to make a protocol secure by declaring the
necessary policy information. If this is going to be broadly successful an
essential criteria is that the security protocol MUST NOT depend on prior
registration.
________________________________
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org on behalf of Mark Delany
Sent: Wed 07/12/2005 1:48 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] domainkeys for other protocolls/applications
As you point out, there are a few different ways that signing policy can
handle services. You can make the service name a "selector", or use a
tag similar to s= in the policy record. The latter doesn't scale as
well to large numbers of services, but the SSP records are short to
begin with, and I can't think of enough services to run out of UDP-space
for the policy.
For a new service that always signs and discards unauthenticated
traffic, policy could be embedded in each selector. A global policy,
with a well-defined namespace is only needed if unauthenticated
traffic is possibly acceptable.
Mark.
_______________________________________________
ietf-dkim mailing list
http://dkim.org
_______________________________________________
ietf-dkim mailing list
http://dkim.org