ietf-dkim
[Top] [All Lists]

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

2009-06-11 10:09:45


Stephen Farrell wrote:
The putative attack would be to sign with foo-sha256 where foo is some
algorithm that a verifier supports and such that the foo key encoding could
accept an rsa p= value as input and such that that combination allows the
attacker to forge signatures.

That's fairly theoretical, but there'd be a bit of work to go check that
there is in fact no realistic situation where such confusion could arise. So
on the whole, for me, keeping the k= just makes it easier to get things right
now and in future.


If out-of-band algorithm/key-type registration like this is not a regular 
"protection" mechanism provided in existing, related crypto-based schemes:

      1) Why should it be only in DKIM?

      2) Won't it need expert vetting by the security community to validate 
that 
the threat is real and the protection is sufficient?

I have been repeatedly taught by the security community to be extremely 
cautious 
about casual assumptions of what will fix a theoretical exposure.  So, for 
example, there have been cases where encrypting twice using the same algorithm 
reduces protection rather than raising it.  That ain't intuitive.

Same concern here.

Having this information maintained in the DNS isn't free and isn't certain to 
be 
safe.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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