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

[hector]

Barry,

I don't recall the reason for them in the base spec, but as I recall 
there were exchanges to explore the compatibility idea via policy.  The 
I-D policy proposal (DSAP)l I wrote was based on  these discussions:

    http://tools.ietf.org/html/draft-santos-dkim-dsap-00#page-15

   The main purpose of the a= tag is to allow domain signers the design
   and implementation opportunity to determine the highest strength
   possible by a particular target verifier by looking the DSAP DNS
   record for the target recipient domain host.  If this query results
   with no a= tag information, the default should be rsa-sha1 is the
   highest strength possible.

   Essentially, this is a negotiation and backward compatibility
   concept.  It is quite possible earlier pre-standard DKIM
   implementations supporting only rsa-sha1 may still exist.  The domain
   DKIM message signer's desire is to achieve the highest protection
   possible.  Instead of signing mail with a particular algorithm and
   hoping for the best, the signer can predetermine what the receiving
   system can handle in terms of hashing strength.


and I believe Doug's own proposal also touched base with it.

But as I recall, the push back was that it was would another lookup 
which to me is a non-issue for domains who will be thinking  to maximize 
secure exchanges knowing 100% that any strength upgrade will put them  
into a compatibility problem.  So if they really wanted to see if an 
important target domain supported XYZ, they can  lookup it up.

==


Barry Leiba wrote:
>> Help me understand. Describe the use case where someone will use it.
>>     
>
> Here's what I remember from the original discussion of h= and k= in
> the key record.
>
> First, part of the idea was to have them both there, to make things
> parallel: "This key is used for this crypto suite."
>
> Now, as I remember -- and it's been a long time, and I've killed many
> brain cells since then -- at least one scenario we discussed was this:
>
> 1. Crypto suite X had been seriously cracked, such that an attacker
> could, at least in some cases, create a valid suite-X signature on his
> own.  Perhaps there was a badly broken hash algorithm, perhaps there
> was a way to reverse-engineer it from a bunch of collected real
> signatures, or whatever.
>
> 2. Signer A, knowing that, will never, ever sign with suite X, and
> exclusively uses suite Y.  Smart signer.
>
> 3. Verifier B, however, continues to support suite X.  Maybe they're
> not as smart, or maybe they just want to keep verifying the suite-X
> signatures from less-smart signers.
>
> 4. An attacker fakes a suite-X signature from signer A, and sends it
> to verifier B.
>
> The argument I remember was that if signer A had a way to say "This
> key is only used with suite Y," then verifier B would know that the
> signature was bogus.  Lacking that statement, the signature will
> verify and appear fine, even though it came from an attacker.
>
> That could provide a transition period, until "all" verifiers had
> stopped accepting suite-X sigs.
>
>
> Does anyone else remember anything vaguely similar to what I've said?
>
> (Note that I'm not arguing to keep h= and k=, here... I'm just trying
> to recall the discussion that led to their inclusion in the first
> place.)
>
> Barry
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
>