Re: [ietf-dkim] DKIM Key Size Constraints
I propose a short draft that updates 6376 to say MUST use at least 1024 bits and setting that as the minimum size verifiers must be able to validate. I'm volunteering to write it if people agree it's appropriate. I think it is appropriate - and I agree with others that we shouldn't go beyond that. Though why not make it even stronger and say that verifiers MUST (or SHOULD, perhaps) consider signatures with keys shorter than 1024 bits invalid? This makes it even more explicit. Martijn. Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England. Company Reg No: 2388295. VAT Reg No: GB 532 5598 33. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Size Constraints
John R. Levine: The only problem I'm aware of is the 512 byte UDP DNS packet size. Is anyone aware of actual stats on how often larger packets fail? for that reason I started using 4096 bit dkim keys years ago. but message modifications are the only relevant reason of broken dkim sigs here. Andreas ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Size Constraints
-Original Message- From: John R. Levine [mailto:jo...@iecc.com] Sent: Tuesday, May 12, 2015 10:44 AM To: MH Michael Hammer (5304) Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] DKIM Key Size Constraints Apart from that I think we should start a (separate) effort to determine where we go from here. For the most part 2048 length keys seem not to be a problem in the wild at this time. On the other hand, given the speed (or lack thereof) involved in working groups generating useful output, if we start now (for some definition of now) we should (hopefully) have a solution before 2048 keys are at risk. The only problem I'm aware of is the 512 byte UDP DNS packet size. Is anyone aware of actual stats on how often larger packets fail? The IETF is not useful here. The IETF DNS crowd swears that it's not a problem at all and anyone who believes otherwise is stupid. I suppose in one sense they are correct in that between TCP fallback and EDNS0 there shouldn't be a problem. On the other hand we know (or should know) that there are a number of firewall implementations that don't allow for TCP fallback (DOH!) for larger packets and/or have a hard limit of 512 bytes for UDP DNS packets (I believe first gen Cisco ASAs will be with us through 2018 or something like that timeframe) by default. I don't know how big either of these issues are. Presumably there should be some sort of breakage info from our DNSSEC brethren (due to larger DNSSEC generated packets). Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Size Constraints
On Tue, May 12, 2015 at 8:31 AM, Martijn Grooten 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
Re: [ietf-dkim] DKIM Key Size Constraints
-1 Please stop! No more DKIM code changes ok? The IETF just made it a STD. Maybe we should remove the STD status first, move it back to proposed standard or experimental if this and other changes are coming. If signers want 1024 bits, then can do so ready. -- HLS On 5/11/2015 1:06 PM, Scott Kitterman wrote: RFC 6376 (which I think is the latest) includes: 3.3.3. Key Sizes Selecting appropriate key sizes is a trade-off between cost, performance, and risk. Since short RSA keys more easily succumb to off-line attacks, Signers MUST use RSA keys of at least 1024 bits for long-lived keys. Verifiers MUST be able to validate signatures with keys ranging from 512 bits to 2048 bits, and they MAY be able to validate signatures with larger keys. Verifier policies may use the length of the signing key as one metric for determining whether a signature is acceptable. Since receivers have no good way of knowing what keys are long-lived, there's no way on the receiver side to reliably determine if a key shorter than 1024 bits is being appropriately used or not. I think it's time to kill keys shorter than 1024 bits dead. It's not like the risks associated with them are new [1]. I propose a short draft that updates 6376 to say MUST use at least 1024 bits and setting that as the minimum size verifiers must be able to validate. I'm volunteering to write it if people agree it's appropriate. Scott K [1] http://www.wired.com/2012/10/dkim-vulnerability-widespread/ ___ 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 May 12, 2015 7:28:25 AM EDT, Hector Santos hsan...@isdg.net wrote: -1 Please stop! No more DKIM code changes ok? The IETF just made it a STD. Maybe we should remove the STD status first, move it back to proposed standard or experimental if this and other changes are coming. If signers want 1024 bits, then can do so ready. True, but irrelevant. The change that's needed is to remove the requirement for receivers to verify signatures with keys to small to be secure. Any cryptographic protocol will need periodic adjustment to remain secure. I'm surprised you are surprised. Presumably your implementation already checks for the current minimum key size of 512 bits. If changing that constant to 1024 is too hard, I think you're doing it wrong. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Size Constraints
On Tue, May 12, 2015 at 8:28 PM, Scott Kitterman ietf-d...@kitterman.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.) 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? 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. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Size Constraints
STD76, DKIM is an Internet Standard, already has a Signer/Verifier migration path in section 3.3 towards the higher key with backward compatibility support for the verification of the smaller key. 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? Lets also remember what the rest of STD76 section 3.3 says: Factors that should influence the key size choice include the following: o The practical constraint that large (e.g., 4096-bit) keys might not fit within a 512-byte DNS UDP response packet o The security constraint that keys smaller than 1024 bits are subject to off-line attacks o Larger keys impose higher CPU costs to verify and sign email o Keys can be replaced on a regular basis; thus, their lifetime can be relatively short o The security goals of this specification are modest compared to typical goals of other systems that employ digital signatures See [RFC3766] for further discussion on selecting key sizes. IMO, this is all still true. It hasn't change. Has it? -- HLS On 5/12/2015 9:16 AM, MH Michael Hammer (5304) wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Martijn Grooten Sent: Tuesday, May 12, 2015 3:23 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] DKIM Key Size Constraints I propose a short draft that updates 6376 to say MUST use at least 1024 bits and setting that as the minimum size verifiers must be able to validate. I'm volunteering to write it if people agree it's appropriate. I think it is appropriate - and I agree with others that we shouldn't go beyond that. Though why not make it even stronger and say that verifiers MUST (or SHOULD, perhaps) consider signatures with keys shorter than 1024 bits invalid? This makes it even more explicit. +1 I think that Scott is correct in suggesting that this proposed update be limited to setting the minimum size (and nothing else). I also like the suggestion of considering anything smaller than 1024 invalid (Thank you Martijn). This should be a quick and easy update. Apart from that I think we should start a (separate) effort to determine where we go from here. For the most part 2048 length keys seem not to be a problem in the wild at this time. On the other hand, given the speed (or lack thereof) involved in working groups generating useful output, if we start now (for some definition of now) we should (hopefully) have a solution before 2048 keys are at risk. Mike ___ 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 03:35:37 PM Murray S. Kucherawy wrote: On Tue, May 12, 2015 at 8:31 AM, Martijn Grooten 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? I think when key size got put in the protocol, then it's a protocol update to change it. 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. I think that of course it's an interoperability issue. There has to be a meeting of the minds on key signing and key verification in order for DKIM to be interoperable. 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. 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. 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. Scott K [1] ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Size Constraints
I am not concern about us (Santronics) and our DKIM implementation with 1024 bit support on both ends per STD. I am concern about everyone else. In other words, I am not about to begin invalidating, rejecting perfectly signed DKIM 512 bit hashed messages purely based on your revised MUST. That is when the engineering begins to go wrong. If I would even consider it, it would be made optional anyway: [_] Enforce 1024 bit hashing If you are going to proposes changes, then think about all the other considerations already being done to revise, enhanced DKIM.I am tired of all the patch work and lack of engineering insights requiring later adjustments. Perhaps it was premature to make DKIM a STD. All you can at best is a SHOULD and I am pretty sure that is how the more STD closer DKIM implementations currently does it at this point in time. In other words, most likely the default settings are 1024 bits. Maybe you can write an informational I-D recommending implementations to change their defaults and/or even perhaps suggest, not mandate they they remove the option. By why? We don't have this theoretical exploit in action and its easily addressable with all the current DKIM features and options. On 5/12/2015 8:56 AM, Scott Kitterman wrote: On May 12, 2015 7:28:25 AM EDT, Hector Santos hsan...@isdg.net wrote: -1 Please stop! No more DKIM code changes ok? The IETF just made it a STD. Maybe we should remove the STD status first, move it back to proposed standard or experimental if this and other changes are coming. If signers want 1024 bits, then can do so ready. True, but irrelevant. The change that's needed is to remove the requirement for receivers to verify signatures with keys to small to be secure. Any cryptographic protocol will need periodic adjustment to remain secure. I'm surprised you are surprised. Presumably your implementation already checks for the current minimum key size of 512 bits. If changing that constant to 1024 is too hard, I think you're doing it wrong. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Size Constraints
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Martijn Grooten Sent: Tuesday, May 12, 2015 3:23 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] DKIM Key Size Constraints I propose a short draft that updates 6376 to say MUST use at least 1024 bits and setting that as the minimum size verifiers must be able to validate. I'm volunteering to write it if people agree it's appropriate. I think it is appropriate - and I agree with others that we shouldn't go beyond that. Though why not make it even stronger and say that verifiers MUST (or SHOULD, perhaps) consider signatures with keys shorter than 1024 bits invalid? This makes it even more explicit. +1 I think that Scott is correct in suggesting that this proposed update be limited to setting the minimum size (and nothing else). I also like the suggestion of considering anything smaller than 1024 invalid (Thank you Martijn). This should be a quick and easy update. Apart from that I think we should start a (separate) effort to determine where we go from here. For the most part 2048 length keys seem not to be a problem in the wild at this time. On the other hand, given the speed (or lack thereof) involved in working groups generating useful output, if we start now (for some definition of now) we should (hopefully) have a solution before 2048 keys are at risk. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Size Constraints
PS References that were left out of the version of the email I did not send to Hector only: [1] http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html [2] http://www.wired.com/2012/10/dkim-vulnerability-widespread/ Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England. Company Reg No: 2388295. VAT Reg No: GB 532 5598 33. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Size Constraints
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. Martijn. Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England. Company Reg No: 2388295. VAT Reg No: GB 532 5598 33. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM Key Size Constraints
Apart from that I think we should start a (separate) effort to determine where we go from here. For the most part 2048 length keys seem not to be a problem in the wild at this time. On the other hand, given the speed (or lack thereof) involved in working groups generating useful output, if we start now (for some definition of now) we should (hopefully) have a solution before 2048 keys are at risk. The only problem I'm aware of is the 512 byte UDP DNS packet size. Is anyone aware of actual stats on how often larger packets fail? The IETF is not useful here. The IETF DNS crowd swears that it's not a problem at all and anyone who believes otherwise is stupid. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
