[ietf-dkim] RFC4871bis - whether to drop -- k: Key type
gmail.sant9442 at winserver.com
Wed Jun 10 11:08:21 PDT 2009
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:
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
> NOTE WELL: This list operates according to
More information about the ietf-dkim