On Tuesday, May 12, 2015 09:27:51 PM Murray S. Kucherawy wrote:
On Tue, May 12, 2015 at 8:28 PM, Scott Kitterman
<ietf-dkim(_at_)kitterman(_dot_)com>
wrote:
Is it appropriate to change the protocol document for this? Isn't it
really more of a BCP?
I think when key size got put in the protocol, then it's a protocol update
to
change it.
Is it part of the protocol, or is it part of the prose around the protocol?
The DKIM algorithms don't break if you use weak keys any more than they
break if you put false information in a header field. More generally, I
don't believe DKIM itself cares about the size of the key. All of our
advice absolutely does, and rightly so.
Do we have any other crypto-related protocols where the protocol itself
legislates the appropriate key parameters for the encoding, decoding,
signing or verifying? Section 6 of RFC3207 (STARTTLS) explains explicitly
that it's a local matter and out of scope, for example. I scanned
RFC4033-4035 (DNSSEC) and didn't see any restrictions or advice about key
size selection at all. I always go cross-eyed when I try to read the TLS
RFCs so I'll stop there for now. ;-)
The size of the key doesn't affect interoperability, but rather the
receiver's choice to accept the signature as valid when it's based on a
weak key.
To me that's equivalent to saying choice of crypto algorithm doesn't
affect
interoperability since it only affects the receivers choice to accept the
signature as valid.
There's also nothing wrong with a receiver deciding it doesn't like
signatures that use relaxed canonicalization, SHA1, or decline to sign the
Subject header field. The algorithm itself worked fine -- that's
interoperability -- but the receiver doesn't like one of the parameters the
signer used and thereby makes a local policy decision.
You have to set a floor below which it's not reasonable to accept
signatures as
valid. Since receivers have no way to vet sender's key rotation policies,
taking an out like RFC 6376 and its predecessors do and say that keys
smaller
that 1024 bits are OK for keys that aren't long lived is not tenable.
That
and since DKIM was first deployed, at least for 512 bit keys, the not long
lived required to meet even the modest security goals of DKIM are
substantially shorter than the amount of time typically needed to ensure
that
mail deliveries are completed (some fraction of a day at longest).
Key lengths less than 1024 need to be killed dead.
I don't argue with any of that, except to say again that I'm not convinced
DKIM, the protocol, has to suddenly break for small keys. I absolutely
agree with a BCP statement of some kind, and I also agree in retrospect
that the not-long-lived key advice in RFC6376 is probably not helpful.
(You could in theory observe the timestamp of when you first saw a key and
then watch how long it gets used, but that puts an unreasonable burden on
receivers.)
It's been known for years (see the original reference I provided) the 512 bit
keys were trivially spoofable. All open source implementations I'm aware of
have not accepted keys < 1024 bits for several years. The only sudden is in
an abstract sense if one hadn't been paying any attention at all to
operational reality regarding DKIM. I don't view this as a functional change
to the operational protocol as much as making the IETF paperwork match that
reality (which I think is important). We're already several years late
writing this, so I don't think any alleged suddenness should be considered at
all.
If you take out the poorly considered aspect of giving an exception to the
existing MUSTard about short lived keys (which is never defined), 1024 bits has
always been the limit, it's just that people often ignored it. Rapid key
rotation is not something that's generally done.
Do we also want to issue a BCP more generally that tries to compel all
implementations of TLS or anything doing signatures to flatly decline to
operate if someone tries to use a sub-1024-bit key size?
I think the considerations for other protocols might be different. I'd rather
focus on DKIM for the moment. Once you get to all, it's no longer a quick,
easy update.
BTW (for reference), I'm prompted to do the work to make this change by a
recent change in opendkim [1] that removed the ability to mark messages
with small keys as DKIM fail.
The change I think you're talking about (you didn't include a reference
URL; I think it's https://sourceforge.net/p/opendkim/bugs/221/) appears to
agree with what I'm saying above. When talking about unacceptably small
keys, the "unacceptable" decision is not made by the protocol, but by the
receiver. DKIM didn't fail, so it shouldn't be treated as a DKIM failure.
Accordingly, OpenDKIM now reports those as failures for policy reasons
rather than failures for protocol reasons.
That is the issue in question. I copied the URL, but then neglected to paste.
Thanks. If the analysis in that issue is correct, key length can never be a
reason to call a signature invalid. I don't think that's correct.
So, if I publish a DKIM key of 128 bits and rotate it every minute for
security, is that a DKIM signature? What if it's 2 bits? The signature isn't
in violation of any MUST or even an a SHOULD. Neither is verifying it.
DKIM is a security protocol. I find it very odd to claim that the security
part of a security protocol isn't part of the protocol.
While I have an opinion on what I think the right answer is, what I'd really
like is whatever is easiest to get published in the IETF that gets signatures
based on keys less than 1024 bits marked fail by opendkim again.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html