On Tuesday, May 12, 2015 09:27:51 PM Murray S. Kucherawy wrote: > On Tue, May 12, 2015 at 8:28 PM, Scott Kitterman <[email protected]> > > 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
