Re: [DNSOP] key lengths for DNSSEC
Frederico A C Neves fne...@registro.br wrote: On Wed, Apr 02, 2014 at 04:25:10PM -0400, Nicholas Weaver wrote: IMO they do until validators record and use a 'root key ratchet': never accept a key who's expiration is older than the inception date of the RRSIG on the youngest root ZSK seen, or have some other defense to roll-back-the-clock attacks. What do you mean by ..key who's expiration is..? A new propertie recorded at this ratchet, btw what is this? I assume he means that the ratchet would observe when a key is no longer published in the DNSKEY RRset and treat it as implicitly revoked. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Portland, Plymouth: South 4 or 5, occasionally 6 in Plymouth. Slight or moderate. Rain, fog patches later. Moderate or poor, occasionally very poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] key lengths for DNSSEC
On Apr 2, 2014, at 10:19 AM, Jim Reid j...@rfc1035.com wrote: My gut feel is large ZSKs are overkill because the signatures should be short-lived and the keys rotated frequently. Though the trade-offs here are unclear: is a 512-bit key that changes daily (say) better than a 2048-bit key that gets rotated once a week/month/whatever? Remember too we're not talking about keys to launch ICBMs or authenticate billion dollar transactions. I doubt it matters if a previous key can be cracked provided it gets retired before the bad guys can throw enough CPU-years to break it. The problem with the way you've phrased this question is that there does not seem to be agreement amongst the parties to this discussion whether old keys matter. If you think they do, you need longer keys. If you think they don't, you need shorter keys. So rather than talking about key lengths first, it would be more productive to come to a consensus about which threat model we are trying to address. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] key lengths for DNSSEC
On 2 Apr 2014, at 10:26, Ted Lemon ted.le...@nominum.com wrote: The problem with the way you've phrased this question is that there does not seem to be agreement amongst the parties to this discussion whether old keys matter. If you think they do, you need longer keys. If you think they don't, you need shorter keys. So rather than talking about key lengths first, it would be more productive to come to a consensus about which threat model we are trying to address. I'm trying to understand the time-based attack, but I'm not seeing it. The gist seems to be that if I can turn back the clock on a remote resolver, I can pollute its cache with old signatures (made with an old, presumably compromised key) and the results will appear to clients of the resolver to validate. This sounds plausible, but without administrative compromise of the remote resolver (in which case you have much simpler options) this attack seems to involve: 1. subverting sufficient NTP responses over a long enough period to cause the remote resolver's clock to turn back in time (long period suggested due to many/most? implementations' refuse large steps in times, and hence many smaller steps might be required) 2. replacing every secure response that would normally arrive at the resolver with a new one that will validate properly at whatever the resolver's idea of the time and date is (or, if not every, sufficient that the client population don't see validation failures for non-target queries). This potentially involves having factored or otherwise recovered every ZSK and KSK that might be used to generate a signature in a response to the resolver, for the time period between now and then. This seems like an intractably difficult thing to accomplish. What am I missing? Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] key lengths for DNSSEC
On 02 Apr 2014, at 15:19, Jim Reid j...@rfc1035.com wrote: There's been a lot of noise and very little signal in the recent discussion. It would be helpful if there was real data on this topic. Is an RSA key of N bits too weak or too strong? I don't know. Is N bits good enough? Probably. Change the algorithm and/or value of N to taste. My gut feel is large ZSKs are overkill because the signatures should be short-lived and the keys rotated frequently. Though the trade-offs here are unclear: is a 512-bit key that changes daily (say) better than a 2048-bit key that gets rotated once a week/month/whatever? Remember too we're not talking about keys to launch ICBMs or authenticate billion dollar transactions. I doubt it matters if a previous key can be cracked provided it gets retired before the bad guys can throw enough CPU-years to break it. However I'm just going on my own gut feel and common sense which could be wrong. Large keys might well be advisable at the root and/or for TLD KSKs. But so far there does not appear to have been much science or engineering on just how large those keys should be or how frequently they change. So in the absence of other firm foundations the established wisdom becomes do what gets done for the root. If there is a threat or risk here, please present solid evidence. Or, better still, an actual example of how any DNSSEC key has been compromised and then used for a real-world (or proof of concept) spoofing attack. BTW, the apparent profanity on an earlier thread was annoying because it didn't spell whisky correctly. As every drinker of fine single malt knows. :-) :-) Jim, Just a thought that occured to me. Crypto-maffia folk are looking for a minimum (i.e. at least so many bits otherwise its insecure). DNS-maffia folk are looking for a maximum (i.e. at most soo many bits otherwise fragmentation/fallback to tcp). It seems that the cryptomaffia’s minimum might actually be larger than the DNS-maffia’s maximum. As an example (dns-op perspective). Average case: 2 keys (KSK/ZSK) + 1 sig (by KSK) with 2048 bit keys is at least 768 bytes (and then some). Roll case: 3 keys(2 KSK/1 ZSK) + 2 sig (by KSK) with 2048 bit keys is at least 1280 bytes (and then some). Then there is this section in SAC63: Interaction of Response Size and IPv6 Fragmentation” Which relates to response sizes larger than 1280 and IPv6 and blackhole effects. https://www.icann.org/en/groups/ssac/documents/sac-063-en.pdf Hope this helps Roy signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] key lengths for DNSSEC
Joe Abley (jabley) writes: 1. subverting sufficient NTP responses over a long enough period to cause the remote resolver's clock to turn back in time (long period suggested due to many/most? implementations' refuse large steps in times, and hence many smaller steps might be required) Many systems will run ntpdate on startup. This seems like an intractably difficult thing to accomplish. It does seem far fetched. What am I missing? There may be good reasons to increase key length, this is not one I'm worried about (then again, no one worried about source port randomization before 2008 :) P. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] key lengths for DNSSEC
On Wed, Apr 2, 2014 at 11:19 AM, Roy Arends r...@dnss.ec wrote: Just a thought that occured to me. Crypto-maffia folk are looking for a minimum (i.e. at least so many bits otherwise its insecure). DNS-maffia folk are looking for a maximum (i.e. at most soo many bits otherwise fragmentation/fallback to tcp). It seems that the cryptomaffia’s minimum might actually be larger than the DNS-maffia’s maximum. As an example (dns-op perspective). Average case: 2 keys (KSK/ZSK) + 1 sig (by KSK) with 2048 bit keys is at least 768 bytes (and then some). Roll case: 3 keys(2 KSK/1 ZSK) + 2 sig (by KSK) with 2048 bit keys is at least 1280 bytes (and then some). Part of jim's query is of interest: Where are the requirements? (boiled down some to that I think) There's also a point I asked about previously in jim's note: Where's the POC at? I don't think anyone's going to change anything without your referred to 2008-like incident... and without some requirements at least as a swag, right? I'd expect the key length discussion relates pretty closely to: If I can factor the key in less time than you will rotate keys... So, how often to the keys rotate? at least every 30 days? So you have to be able to be 'secure' longer than 30 days of compute resources time, right? Then there is this section in SAC63: Interaction of Response Size and IPv6 Fragmentation” Which relates to response sizes larger than 1280 and IPv6 and blackhole effects. https://www.icann.org/en/groups/ssac/documents/sac-063-en.pdf good times :( ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] key lengths for DNSSEC
On Wed, Apr 2, 2014 at 11:31 AM, Christopher Morrow morrowc.li...@gmail.com wrote: On Wed, Apr 2, 2014 at 11:19 AM, Roy Arends r...@dnss.ec wrote: Just a thought that occured to me. Crypto-maffia folk are looking for a minimum (i.e. at least so many bits otherwise its insecure). DNS-maffia folk are looking for a maximum (i.e. at most soo many bits otherwise fragmentation/fallback to tcp). It seems that the cryptomaffia’s minimum might actually be larger than the DNS-maffia’s maximum. As an example (dns-op perspective). Average case: 2 keys (KSK/ZSK) + 1 sig (by KSK) with 2048 bit keys is at least 768 bytes (and then some). Roll case: 3 keys(2 KSK/1 ZSK) + 2 sig (by KSK) with 2048 bit keys is at least 1280 bytes (and then some). Part of jim's query is of interest: Where are the requirements? (boiled down some to that I think) There's also a point I asked about previously in jim's note: Where's the POC at? I don't think anyone's going to change anything without your referred to 2008-like incident... and without some requirements at least as a swag, right? oops, apologies, phil's 2008 reference. I'd expect the key length discussion relates pretty closely to: If I can factor the key in less time than you will rotate keys... So, how often to the keys rotate? at least every 30 days? So you have to be able to be 'secure' longer than 30 days of compute resources time, right? Then there is this section in SAC63: Interaction of Response Size and IPv6 Fragmentation” Which relates to response sizes larger than 1280 and IPv6 and blackhole effects. https://www.icann.org/en/groups/ssac/documents/sac-063-en.pdf good times :( ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] key lengths for DNSSEC
On Apr 2, 2014, at 10:49 AM, Joe Abley jab...@hopcount.ca wrote: This seems like an intractably difficult thing to accomplish. Bear in mind that all you _really_ have to do is get a bogus ZSK with the current time into the resolver, which you may be able to do with some clever NTP shenanigans over a relatively short timescale. But yeah, this isn't likely to be useful except in cases where a device has been powered off, doesn't have an accurate battery-backed-up clock, and does DNSSEC, which is a weird set of circumstances. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] key lengths for DNSSEC
On Wed, Apr 02, 2014 at 11:33:20AM -0400, Ted Lemon wrote: Bear in mind that all you _really_ have to do is get a bogus ZSK with the current time into the resolver, which you may be able to do with some clever NTP shenanigans over a relatively short timescale. But yeah, this isn't likely to be useful except in cases where a device has been powered off, doesn't have an accurate battery-backed-up clock, and does DNSSEC, which is a weird set of circumstances. I predict that will be a less weird set of circumstances in a year or so: dnsmasq now has DNSSEC validation in beta. (Tony Finch has a nifty idea to replace ntpdate with a quorum of tlsdate responses; it might still be subvertible but it would be a much harder nut to crack. https://git.csx.cam.ac.uk/x/ucs/u/fanf2/temporum.git) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] key lengths for DNSSEC
On Apr 2, 2014, at 11:19 AM, Roy Arends r...@dnss.ec wrote: Just a thought that occured to me. Crypto-maffia folk are looking for a minimum (i.e. at least so many bits otherwise its insecure). DNS-maffia folk are looking for a maximum (i.e. at most soo many bits otherwise fragmentation/fallback to tcp). It seems that the cryptomaffia’s minimum might actually be larger than the DNS-maffia’s maximum. The problem from the dns-op maximalist viewpoint is there is basically two magic numbers: 512B and ~1400B. As someone who's measured this, the 512B is not a problem, but the 1400B here be fragments is. Yet at the same time, the current 1024B ZSK/2048B KSK configuration on TLDs does blow through it: I reported in the previous thread how org's DNSKEY record already blew past that limit. And even in that case, resolvers can handle fragments don't work, albeit with a latency penalty. So its not a DNSSEC fails point but simply performance degraded. So the real question is do the common answers fragment, the ones with short TTLs that are accessed a lot, have a fragment problem. With 2048b keys, they don't: the one that gets you is NSEC3, and that only blows up in your face on 4096b keys. (But boy does it, those 3 RRSIGs get big when you're using 4096b keys). And please don't discount the psychology of the issue. If DNSSEC wants to be taken seriously, it needs to show it. Using short keys for root and the major TLDs, under the assumptions that it can't be cracked quickly (IMO, we have to assume 1024b can be.) and that old keys don't matter [1], is something that really does draw criticism. [1] IMO they do until validators record and use a 'root key ratchet': never accept a key who's expiration is older than the inception date of the RRSIG on the youngest root ZSK seen, or have some other defense to roll-back-the-clock attacks. -- Nicholas Weaver it is a tale, told by an idiot, nwea...@icsi.berkeley.edufull of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] key lengths for DNSSEC
Nicholas, On Wed, Apr 02, 2014 at 04:25:10PM -0400, Nicholas Weaver wrote: ... And please don't discount the psychology of the issue. If DNSSEC wants to be taken seriously, it needs to show it. Using short keys for root and the major TLDs, under the assumptions that it can't be cracked quickly (IMO, we have to assume 1024b can be.) and that old keys don't matter [1], is something that really does draw criticism. [1] IMO they do until validators record and use a 'root key ratchet': never accept a key who's expiration is older than the inception date of the RRSIG on the youngest root ZSK seen, or have some other defense to roll-back-the-clock attacks. What do you mean by ..key who's expiration is..? A new propertie recorded at this ratchet, btw what is this? Fred ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] key lengths for DNSSEC
Speaking for myself: First: Thank you Jim and Joe for seeking to increase the signal-to-noise ratio on this thread and for explaining what the attack vector would be for lower IQ folk like myself. Second: I have always taken my instructions from the community. So regardless of what I believe I will faithfully do my part (with your help) to make it happen. Third: From my vantage point and as author of the code used for the KSK side of things, I do not see any immediate barriers to increasing key lengths. The members of the original root DNSSEC design team have enjoyed a very good working relationship and I expect that to continue. However, like any other change at this level it must be one that is approached conservatively and thoroughly tested before deployed (software, increased RRSet sizes, IPv6 impact, new ZSK generation). This will take human resources and time. I look forward to following further discussions on this topic. -Rick -Original Message- From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Joe Abley Sent: Wednesday, April 02, 2014 7:50 AM To: Ted Lemon Cc: IETF DNSOP WG Subject: Re: [DNSOP] key lengths for DNSSEC On 2 Apr 2014, at 10:26, Ted Lemon ted.le...@nominum.com wrote: The problem with the way you've phrased this question is that there does not seem to be agreement amongst the parties to this discussion whether old keys matter. If you think they do, you need longer keys. If you think they don't, you need shorter keys. So rather than talking about key lengths first, it would be more productive to come to a consensus about which threat model we are trying to address. I'm trying to understand the time-based attack, but I'm not seeing it. The gist seems to be that if I can turn back the clock on a remote resolver, I can pollute its cache with old signatures (made with an old, presumably compromised key) and the results will appear to clients of the resolver to validate. This sounds plausible, but without administrative compromise of the remote resolver (in which case you have much simpler options) this attack seems to involve: 1. subverting sufficient NTP responses over a long enough period to cause the remote resolver's clock to turn back in time (long period suggested due to many/most? implementations' refuse large steps in times, and hence many smaller steps might be required) 2. replacing every secure response that would normally arrive at the resolver with a new one that will validate properly at whatever the resolver's idea of the time and date is (or, if not every, sufficient that the client population don't see validation failures for non-target queries). This potentially involves having factored or otherwise recovered every ZSK and KSK that might be used to generate a signature in a response to the resolver, for the time period between now and then. This seems like an intractably difficult thing to accomplish. What am I missing? Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] key lengths for DNSSEC
On Wed, Apr 2, 2014 at 11:19 AM, Roy Arends r...@dnss.ec wrote: On 02 Apr 2014, at 15:19, Jim Reid j...@rfc1035.com wrote: There's been a lot of noise and very little signal in the recent discussion. It would be helpful if there was real data on this topic. Is an RSA key of N bits too weak or too strong? I don't know. Is N bits good enough? Probably. Change the algorithm and/or value of N to taste. My gut feel is large ZSKs are overkill because the signatures should be short-lived and the keys rotated frequently. Though the trade-offs here are unclear: is a 512-bit key that changes daily (say) better than a 2048-bit key that gets rotated once a week/month/whatever? Remember too we're not talking about keys to launch ICBMs or authenticate billion dollar transactions. I doubt it matters if a previous key can be cracked provided it gets retired before the bad guys can throw enough CPU-years to break it. However I'm just going on my own gut feel and common sense which could be wrong. Large keys might well be advisable at the root and/or for TLD KSKs. But so far there does not appear to have been much science or engineering on just how large those keys should be or how frequently they change. So in the absence of other firm foundations the established wisdom becomes do what gets done for the root. If there is a threat or risk here, please present solid evidence. Or, better still, an actual example of how any DNSSEC key has been compromised and then used for a real-world (or proof of concept) spoofing attack. BTW, the apparent profanity on an earlier thread was annoying because it didn't spell whisky correctly. As every drinker of fine single malt knows. :-) :-) Jim, Just a thought that occured to me. Crypto-maffia folk are looking for a minimum (i.e. at least so many bits otherwise its insecure). DNS-maffia folk are looking for a maximum (i.e. at most soo many bits otherwise fragmentation/fallback to tcp). It seems that the cryptomaffia’s minimum might actually be larger than the DNS-maffia’s maximum. As an example (dns-op perspective). Average case: 2 keys (KSK/ZSK) + 1 sig (by KSK) with 2048 bit keys is at least 768 bytes (and then some). Roll case: 3 keys(2 KSK/1 ZSK) + 2 sig (by KSK) with 2048 bit keys is at least 1280 bytes (and then some). Then there is this section in SAC63: Interaction of Response Size and IPv6 Fragmentation” Which relates to response sizes larger than 1280 and IPv6 and blackhole effects. https://www.icann.org/en/groups/ssac/documents/sac-063-en.pdf There is no doubt that we can get close to the limit on response sizes. Which is why I have been pushing the notion that if we are going to do DNSE then part of the DNSE solution should be to get us out of the single response packet straightjacket. Its not just crypto that gets crippled by this issue. We are not in 1995 any more. We have bigger computing resources and bigger security challenges. The Internet isn't a science project any more. Too much of the debate here has been for one security approach versus another. That is obsolete thinking we have been moving to multiple layers of cryptography for some time now. -- Website: http://hallambaker.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
