Re: [ietf-dkim] Issue #1184, 1196, 1271

On May 23, 2006, at 5:46 PM, Paul Hoffman wrote:

> At 5:12 PM -0700 5/23/06, Douglas Otis wrote:
> > There still should be a strategy defined in the base draft to  
> > ensure an unknown algorithm can be confirmed.
> Could you define "confirmed"?
An unknown algorithm noted within the signature must be confirmed as  
being the _same_ algorithm used in the associated key offered by the  
signing domain, or a bad actor could introduce any algorithm to  
exploit a deprecated signature.  Without an ensured means to always  
make this confirmation in the base draft, an inability to compare an  
algorithm indicated in the signature might be viewed as the  
introduction of a new method of representation.  In other words,  
going from an mnemonic to numeric either must be excluded between  
query methods per the base draft, or specify a list of algorithm  
representations (mnemonic, numeric), in addition to query methods.

> > Without a strategy devised within the base draft, if there is a  
> > weakness discovered, an exploit can not be fully prevented until  
> > it becomes practical not to use an algorithm that might be the  
> > subject of some exploit.
> Of course. So?
The window of opportunity would rapidly close as major players  
upgraded their servers, only when there is an ability to ensure a  
deprecated signature could not be exploited in the case where both  
the signing and verifying domains now handle the non-deprecated  
signature.  Without being able to exclude the deprecated signature in  
this case, the window of the exploit continues until it becomes  
practical to not offer the deprecated signature.  With an ability to  
exclude the use of deprecated signatures, the difference in the  
threat window for a majority of recipients could be measured in  
weeks, instead of months or years.

> > With a relatively simple deprecation flag, and a requirement that  
> > a message must include a non-deprecated signature from the signing  
> > domain, once both the signing and verifying domain upgrade,  
> > inclusion of a deprecated signature will not introduce an  
> > additional risk.
> It doesn't anyway: the verifier simply doesn't use the signature  
> that uses the now-bad algorithm.
A verifier may not have been upgraded to handle a new, more secure  
algorithm.  There is no means to negotiate algorithms, which will  
likely mean multiple signatures (deprecated/non-deprecated) will be  
needed for some (perhaps extended) period of time.  Even an abrupt  
transition in algorithms may permit an exploit where a bad actor  
offers an unknown algorithm purportedly from some domain.  To prevent  
this type of spoofed algorithm exploit, there MUST be an iron-clad  
method available to confirm the sending domain actually offers a key  
using the algorithm indicated within the signature.  With that  
absolutely essential confirmation ability, adding a deprecated key  
flag then also allows a safe multi-signature transition, where an  
exploit of a weaker algorithm can be curtailed as soon as possible.

> > This is a genuine security concern, as email does not offer a  
> > means to negotiate and a transition period may take years, hence  
> > offering a deprecated signature must not permit an exploit beyond  
> > where both signing and verifying domains handle the non-deprecated  
> > signature.
> How is the DKIM case any different than in S/MIME and OpenPGP? Or  
> are you claiming that they too need to be fixed with your "simple  
> deprecation flag" as well? The value of DKIM signatures is orders  
> of magnitude less than the value of these other signature formats,  
> and yet those IETF WGs (which have been around for a decade) have  
> not found a need to solve this "genuine security concern".
Both S/MIME and OpenPGP exist at different places in the channel.   
DKIM is designed to work in conjunction with the MTA.  Unlike these  
protocols, DKIM is better positioned to achieve a higher level of  
deployment.  With DKIM perhaps soon providing protection from now  
common and highly criminal activity, it would be reasonable to expect  
significant resources will be arrayed against this DKIM scheme.   
DKIM's survival from an initial setback may largely depend upon a  
strategy that permits a smooth and safe transition when reacting to  
such a possible setback.  Ensuring the confirmation of the key  
algorithm, and a means to mark a key deprecated does not seem  
unreasonable.  Just the opposite.
-Doug
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html