Re: [ietf-dkim] DKIM Key Size Reporting Methods
On 5/13/2015 3:19 PM, Hector Santos wrote: > There are several ways to offer the DKIM key size expectation for > Receiver local policies to deal with: > > 1) Report the bit size in Authentication-Results (Auth-Res) header. > > Authentication-Results: mail.example.com > dkim=pass . bitsize=num-bits; > > 2) Add a DMARC tag extension "ess=" Expected Signature Strength with > values > > ess=std76,default, tell receivers to follow DKIM STD76.(RFC6376) > ess=num-bits, num-bits key size is or higher is acceptable > > 3) Or use "ess=" as a DKIM tag extension: > >DKIM-Signature: d=signer.domain; ess=1024; .. > > Any method allows for local policy filtering engines to deal with it. The last one can be spoofed so nix #3. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] DKIM Key Size Reporting Methods
There are several ways to offer the DKIM key size expectation for Receiver local policies to deal with: 1) Report the bit size in Authentication-Results (Auth-Res) header. Authentication-Results: mail.example.com dkim=pass . bitsize=num-bits; 2) Add a DMARC tag extension "ess=" Expected Signature Strength with values ess=std76,default, tell receivers to follow DKIM STD76.(RFC6376) ess=num-bits, num-bits key size is or higher is acceptable 3) Or use "ess=" as a DKIM tag extension: DKIM-Signature: d=signer.domain; ess=1024; .. Any method allows for local policy filtering engines to deal with it. -- HLS On 5/13/2015 2:13 PM, Dave Crocker wrote: > On 5/12/2015 10:25 PM, Roland Turner wrote: >> On 05/13/2015 12:27 PM, Murray S. Kucherawy wrote: >> >>> 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. >> >> +1 > > > (I haven't been tracking this thread in detail, so please forgive my > missing some nuance.) > > > I think the issue separates between 'interoperability' vs. 'usage > policy'. The former is the protocol. The latter is either > Internet-wide BCP or local policy, depending upon strong community > consensus. > > I did a quick search for (rfc ietf minimum key size cryptograph) and > found a series of RFCs that do indeed talk about minimum key size. All > of them are Informational, rather than standards track or BCP. > > As a non-crypto-geek, the solid constant I've observed is that crypto > algorithm and key size choices are highly malleable: they change over > time. So a protocol needs some agility with respect to these and MUST > NOT be locked in too tightly. > > DKIM is algorithm-agile. It needs to also be key-length-agile. > > If there is strong community consensus on the choices of algorithm and > key-length, it needs to be asserted as an operational convention, not in > the base protocol > > d/ > ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Size Constraints
On 5/12/2015 10:25 PM, Roland Turner wrote: > On 05/13/2015 12:27 PM, Murray S. Kucherawy wrote: > >> 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. > > +1 (I haven't been tracking this thread in detail, so please forgive my missing some nuance.) I think the issue separates between 'interoperability' vs. 'usage policy'. The former is the protocol. The latter is either Internet-wide BCP or local policy, depending upon strong community consensus. I did a quick search for (rfc ietf minimum key size cryptograph) and found a series of RFCs that do indeed talk about minimum key size. All of them are Informational, rather than standards track or BCP. As a non-crypto-geek, the solid constant I've observed is that crypto algorithm and key size choices are highly malleable: they change over time. So a protocol needs some agility with respect to these and MUST NOT be locked in too tightly. DKIM is algorithm-agile. It needs to also be key-length-agile. If there is strong community consensus on the choices of algorithm and key-length, it needs to be asserted as an operational convention, not in the base protocol d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Size Constraints
On Wed, May 13, 2015 at 01:21:36PM +0800, Roland Turner wrote: > (e.g. perhaps measurement discovers that 512 bit keys are only used by > low-risk domains; does this warrant killing the feature for the good of those > who are being targeted, or retaining it because it's still in use, with a > clear > understanding that highly-targeted organisations aren't going to use 512 bit > keys to begin with?) I did some measurements this morning. In a corpus of emails sent in the past three weeks, I found ~400 different DKIM selector-domain combinations used to sign legitimate emails. (This is out of ~11k such emails.) Out of these, three used a 512-bit RSA key. A further seven used 768-bit RSA and a handful published SPF data in their DKIM record. None of these were highly-targeted organisations. The 512-bit keys were used to send (opt-in) bulk emails; most 768-bit keys were used to send one-to-one emails. Two out of the three selectors that used 512-bit keys included a year (2011 and 2012) which is good news (as they haven't created weak keys recently) and bad news (as they've been using weak keys for a very long period of time). I don't think this is just about highly-targeted domains though, even if the risk there is larger. An adversary could crack the DKIM key of LocalShop Ltd. to send a fake version of their weekly mailing with the latest offers. Make the links go to crypto-ransomware and you've earned back your investement of cracking the RSA key very quickly. (Note that this does make the assumption that signing emails with the DKIM key of a domain that has a reasonably good reputation significantly improves delivery rates. I am not sure how correct this assumption is, but I think DKIM was designed under the implicit assumption that this could become correct one day.) FTR, I do agree with others that in retrospect, including explicit key parameters in the RFC wasn't a good idea. I'm also fine to address this issue in a BCP if that is considered more appropriate - if only because the STD already says not to use keys smaller than 1024 bits - and I think it's a good idea to refer to NIST to determine what key parameters are considered secure rather than us making a somewhat informed decision. I don't think such a BCP should be so broad as to cover other protocols, including TCP, which is orders of magnitude more complicated. Martijn. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Size Constraints
On 5/13/2015 7:31 AM, Scott Kitterman wrote: > > 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. Good point. But we did take it into account. As you point out, the APIs seem to have limited the size. > 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. IMO, that would be a SUPPORT REQUEST for a specific implementation, not a STD76, across the board, change request. You can't enforce this on other implementators. Keep in mind what a STD76 means -- its a standard, thats it. The bar is going to be very high to make changes to it. Just like STD11 (RFC822) and STD10 (RFC821) are real IETF standards, a fully compliant SMTP package still supports them and they might have strict options to turn off/on 822/821 related protocol features. Those are implementation concepts. Its a good suggestion to have an an "Informational or BCP" for DKIM. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Size Constraints
On 5/13/2015 1:25 AM, Roland Turner wrote: > On 05/13/2015 12:27 PM, Murray S. Kucherawy wrote: > >> 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. > > +1 +1 -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Size Constraints
IMO, this suggestion would be better as an Informational and BCP note. I don't think it warrants a change to STD76. We went through this already. We (DKIM WG) were well aware of the weakness of a smaller key but we had backward compatibility concerns so the proper verification migration path was set. I see this more as an implementation note. In our DKIM package, it was provided in the API as a functional "numbits" parameter with a default of 1024 but it is not settable via the sysop configuration/UI. IOW, 1024 is always used. No option for setting 512. What we can do in the future is add the option for higher sizes and even add the option to "[_] Invalidate 512 signatures". But IMV, that is Informational/BCP material. Not a change in the STD76 specification. -- HLS On 5/12/2015 6:35 PM, Murray S. Kucherawy wrote: > On Tue, May 12, 2015 at 8:31 AM, Martijn Grooten > mailto:martijn.groo...@virusbtn.com>> > wrote: > > > Why remove 512 support from the verification side? Does this mean the > > verifier will take valid 512 signature and make it invalid, no signature > > message? Is there a correlation out there that 512 bits signers are > more > > prune to be Bad Guys? Spammers? > > The problem here is that 512-bit keys can be trivially broken: it > takes less than 8 hours and about 100 USD to do so[1]. So there is > no way to be certain that the signer of the message is the same > organisation that published the (512-bit) DKIM key, even if that > organisation only were to send email that everyone would want to > receive. > > You are right to point out that the RFC says that "[t]he security > goals of this specification are modest", which indeed they are, > but I think 100 USD is well within the means of the kind of > adversary DKIM is trying to protect against. The story of Google's > 512-bit key that Scott already pointed to[2] gives at least some > anecdotal evidence about why this matters in practice. > > > Is it appropriate to change the protocol document for this? Isn't it > really more of a BCP? > > 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. > > I'm not arguing that it's a bad idea to discourage this practice, but > rather ruminating about whether this is the right way to do it. > > Then again, RFC6376 doesn't expressly say that keys smaller than 512 > have to be accepted either. Hmmm. > > -MSK > > > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Size Constraints
On Tuesday, May 12, 2015 09:27:51 PM Murray S. Kucherawy wrote: > On Tue, May 12, 2015 at 8:28 PM, Scott Kitterman > > 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 t
