ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

2009-06-02 19:26:20
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Jun 2, 2009, at 3:17 PM, Douglas Otis wrote:


On Jun 2, 2009, at 2:38 PM, Jon Callas wrote:

The only use I can see of it is the case where you have many live  
messages out there, some of them with (e.g.) RSA and others with  
(e.g.) ECDSA and you want to make all RSA messages start failing  
now, and yet for some reason want to keep the RSA keys still in the  
DNS.

This does not represent the intended use the key's algorithm list.

While currently most receivers recognize rsa-sha256, they may not  
recognize ecdsa-md6. Removing indications of currently used  
algorithms by the key for a particular domain will allow bad actors  
to take advantage of a transition period.  Receiving MTAs may make  
exceptions for ADSP when ecdsa-md6 is recognized as a valid, albeit  
unsupported algorithm.  Rather than rejecting the message, it might  
be marked as having an unsupported signature algorithm.  By having  
the key indicate specifically which algorithms are in current use,  
then algorithm exceptions do not need to extend across all domains.   
Just domains indicating the use of the newer algorithm should  
receive an exception indication.  Just as in the days of base64  
encoded messages, a post-process can be used to confirm the validity  
of messages having a newer algorithm signature.  This post process  
check could even be offered as a web based service.

Without this feature, people may soon find their inbox flooded by  
bogus messages indicating the use of new algorithm, that could have  
been mitigated extensively by having the key feature.

Help me understand. Describe the use case where someone will use it.

As a cryptographer, I do not understand how the sketch you give above  
can happen. If the cryptography works, I don't see how the situation  
you describe can occur at all.

Signatures are either valid or invalid. There are many ways it can be  
invalid and only a few it can be valid. By that I mean among other  
things that a signature might be syntactically valid but by policy  
invalid; e.g. in the case of SHA1 collisions.

If an MTA decides that an invalid signature is for some reason  
acceptable anyway -- well, that's daft, but it's *their* MTA. People  
have the right to be stupid.

I don't get it, Doug.

However -- I just wrote a note about the meta-issue. If you want to  
say that you think it should be there because you like it and that  
should be good enough, I'll support you. It's the burden of people to  
convince others why something should go, not why it should stay.

        Jon



-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII

wj8DBQFKJa3MsTedWZOD3gYRAt3AAKDSwk24E0YhgbB+7z8BUB6Hl7jFPACgrz4U
ucIGma8+/Fuqcm/FWGAxQr0=
=D7jj
-----END PGP SIGNATURE-----
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>