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: [EMAIL PROTECTED] on behalf of Mark Delany
Sent: Wed 07/12/2005 1:48 PM
To: [email protected]
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
