Re: [DNSOP] RSA/SHA-1 to = RSA/SHA-256 ?
In your previous mail you wrote: Currently a number of validators don't do ECC, because of the openssl library from the distribution they are using doesn't include support. This makes ECC an unsupported algorithm, and so it fails open (See RFC4035, Section 5.2, around If the validator does not support any of the algorithms...). Geoff also has a good blog post (http://labs.apnic.net/blabs/?p=544) and presentations at various places (e.g: https://ripe69.ripe.net/presentations/135-18-2014-11-01-ecc.pptx). = This very unfortunate fact is IMHO the major (and perhaps only) issue to solve before deploying ECDSA (and solve the RSA/SHA-1 vs RSA/SHA-2 question). I suggest that folk whose ssl libraries don't support ECC should figure out why (see http://tools.ietf.org/html/rfc6090 and also Geoff's blog post for some background) and then recompile with support[0]. = I can't say more. Thanks francis.dup...@fdupont.fr ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RSA/SHA-1 to = RSA/SHA-256 ?
I think its possible people have misunderstood what we said, when we measured 'do not understand ECDSA' as a problem and presented on it. It is a tenable, arguable case, that PRECISELY because the fail mode is 'unsigned' we can move to ECDSA more easily than any other key transition under discussion: the fail mode breaks DNSSEC validation by returning to unsigned state. Not by preventing name resolution. its the weaker, unprotected but results returned fail mode. If we want small, short tractable signatures in DNS, moving to eCDSA is easier now than at any other time. We just have to accept we make a lot of DNSSEC clients stop validating until code updates. thats how I read it, anyway. -G On Mon, Jan 19, 2015 at 1:17 PM, Warren Kumari war...@kumari.net wrote: On Monday, January 19, 2015, Francis Dupont francis.dup...@fdupont.fr wrote: In your previous mail you wrote: Currently a number of validators don't do ECC, because of the openssl library from the distribution they are using doesn't include support. This makes ECC an unsupported algorithm, and so it fails open (See RFC4035, Section 5.2, around If the validator does not support any of the algorithms...). Geoff also has a good blog post (http://labs.apnic.net/blabs/?p=544) and presentations at various places (e.g: https://ripe69.ripe.net/presentations/135-18-2014-11-01-ecc.pptx ). = This very unfortunate fact is IMHO the major (and perhaps only) issue to solve before deploying ECDSA (and solve the RSA/SHA-1 vs RSA/SHA-2 question). Unfortunately not the only - we also need the registrars to accept ECDSA. But yes, this is annoying- rolling the DNSSEC root key to ECDSA would be very cool, as we could then fit 2 signatures well within the IPv6 MTU. Oh, as was pointed out earlier, Google Public DNS does ECDSA. W I suggest that folk whose ssl libraries don't support ECC should figure out why (see http://tools.ietf.org/html/rfc6090 and also Geoff's blog post for some background) and then recompile with support[0]. = I can't say more. Thanks francis.dup...@fdupont.fr -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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] RSA/SHA-1 to = RSA/SHA-256 ?
Next release of Net::DNS::SEC will support ECDSA and ECC-GOST Dick Franks On 19 January 2015 at 15:17, Warren Kumari war...@kumari.net wrote: On Monday, January 19, 2015, Francis Dupont francis.dup...@fdupont.fr wrote: In your previous mail you wrote: Currently a number of validators don't do ECC, because of the openssl library from the distribution they are using doesn't include support. This makes ECC an unsupported algorithm, and so it fails open (See RFC4035, Section 5.2, around If the validator does not support any of the algorithms...). Geoff also has a good blog post (http://labs.apnic.net/blabs/?p=544) and presentations at various places (e.g: https://ripe69.ripe.net/presentations/135-18-2014-11-01-ecc.pptx ). = This very unfortunate fact is IMHO the major (and perhaps only) issue to solve before deploying ECDSA (and solve the RSA/SHA-1 vs RSA/SHA-2 question). Unfortunately not the only - we also need the registrars to accept ECDSA. But yes, this is annoying- rolling the DNSSEC root key to ECDSA would be very cool, as we could then fit 2 signatures well within the IPv6 MTU. Oh, as was pointed out earlier, Google Public DNS does ECDSA. W I suggest that folk whose ssl libraries don't support ECC should figure out why (see http://tools.ietf.org/html/rfc6090 and also Geoff's blog post for some background) and then recompile with support[0]. = I can't say more. Thanks francis.dup...@fdupont.fr -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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] RSA/SHA-1 to = RSA/SHA-256 ?
On Monday, January 19, 2015, Francis Dupont francis.dup...@fdupont.fr wrote: In your previous mail you wrote: Currently a number of validators don't do ECC, because of the openssl library from the distribution they are using doesn't include support. This makes ECC an unsupported algorithm, and so it fails open (See RFC4035, Section 5.2, around If the validator does not support any of the algorithms...). Geoff also has a good blog post (http://labs.apnic.net/blabs/?p=544) and presentations at various places (e.g: https://ripe69.ripe.net/presentations/135-18-2014-11-01-ecc.pptx ). = This very unfortunate fact is IMHO the major (and perhaps only) issue to solve before deploying ECDSA (and solve the RSA/SHA-1 vs RSA/SHA-2 question). Unfortunately not the only - we also need the registrars to accept ECDSA. But yes, this is annoying- rolling the DNSSEC root key to ECDSA would be very cool, as we could then fit 2 signatures well within the IPv6 MTU. Oh, as was pointed out earlier, Google Public DNS does ECDSA. W I suggest that folk whose ssl libraries don't support ECC should figure out why (see http://tools.ietf.org/html/rfc6090 and also Geoff's blog post for some background) and then recompile with support[0]. = I can't say more. Thanks francis.dup...@fdupont.fr javascript:; -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RSA/SHA-1 to = RSA/SHA-256 ?
Next release of Net::DNS::SEC will support ECDSA and ECC-GOST Dick Franks On 19 January 2015 at 15:17, Warren Kumari war...@kumari.net wrote: On Monday, January 19, 2015, Francis Dupont francis.dup...@fdupont.fr wrote: In your previous mail you wrote: Currently a number of validators don't do ECC, because of the openssl library from the distribution they are using doesn't include support. This makes ECC an unsupported algorithm, and so it fails open (See RFC4035, Section 5.2, around If the validator does not support any of the algorithms...). Geoff also has a good blog post (http://labs.apnic.net/blabs/?p=544) and presentations at various places (e.g: https://ripe69.ripe.net/presentations/135-18-2014-11-01-ecc.pptx ). = This very unfortunate fact is IMHO the major (and perhaps only) issue to solve before deploying ECDSA (and solve the RSA/SHA-1 vs RSA/SHA-2 question). Unfortunately not the only - we also need the registrars to accept ECDSA. But yes, this is annoying- rolling the DNSSEC root key to ECDSA would be very cool, as we could then fit 2 signatures well within the IPv6 MTU. Oh, as was pointed out earlier, Google Public DNS does ECDSA. W I suggest that folk whose ssl libraries don't support ECC should figure out why (see http://tools.ietf.org/html/rfc6090 and also Geoff's blog post for some background) and then recompile with support[0]. = I can't say more. Thanks francis.dup...@fdupont.fr -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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] RSA/SHA-1 to = RSA/SHA-256 ?
On Mon, 19 Jan 2015, Paul Hoffman wrote: If we want small, short tractable signatures in DNS, moving to eCDSA is easier now than at any other time. We just have to accept we make a lot of DNSSEC clients stop validating until code updates. A big +1 to this. A big -1 to this. You suggest basically obsoleting RSA before ECDSA is widely supported. If you want to sunset RSA, write a draft with a clear time table. I don't see why the root zone (or anyone else) currently could not switch the ZSK from 1024 to 2048. I would expect root zone queries including a bigger signature over the DS record would still be much smaller than most zone's APEX with A//MX and RRsigs, which already use 2048 RSA keys on top of that. I think the reason it is still 1024 lies more within practical and procedural matters, and do not relate to packet sizes (which is the only argument for ECDSA unless you think the NSA can factor 2048 or even 1024 in trivial amount of time). So for the root, I suspect switching the ZSK from 1024 RSA to 2048 RSA or to ECDSA is the exact same problem. So why drop RSA and cause a lot of invalidation to happen? That would be much more of a reputation damage than the ill-conceived problem of current 1024 bit RSA keys. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RSA/SHA-1 to = RSA/SHA-256 ?
On Jan 19, 2015, at 7:30 AM, George Michaelson g...@algebras.org wrote: I think its possible people have misunderstood what we said, when we measured 'do not understand ECDSA' as a problem and presented on it. It is a tenable, arguable case, that PRECISELY because the fail mode is 'unsigned' we can move to ECDSA more easily than any other key transition under discussion: the fail mode breaks DNSSEC validation by returning to unsigned state. Not by preventing name resolution. its the weaker, unprotected but results returned fail mode. If we want small, short tractable signatures in DNS, moving to eCDSA is easier now than at any other time. We just have to accept we make a lot of DNSSEC clients stop validating until code updates. thats how I read it, anyway. A big +1 to this. One of the major reasons that the browser vendors are not even considering using DANE is that the DNS root is signed with a 1024-bit key. If all we want from DNSSEC is protecting DNS caches from spoofing, and we're willing to live with the restrictions that RSA puts us under, there is no need to change from the current setup. Some (many?) of us want DNSSEC to be more, if possible. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RSA/SHA-1 to = RSA/SHA-256 ?
On Monday, January 19, 2015, George Michaelson g...@algebras.org wrote: I think its possible people have misunderstood what we said, when we measured 'do not understand ECDSA' as a problem and presented on it. Dunno. I think many / most folk got it, at least in the venues I saw it.. It is a tenable, arguable case, that PRECISELY because the fail mode is 'unsigned' we can move to ECDSA more easily than any other key transition under discussion: the fail mode breaks DNSSEC validation by returning to unsigned state. Not by preventing name resolution. ... thereby defeating the purpose of having signed the zone. its the weaker, unprotected but results returned fail mode. Yes, is is definitely way better than having it break / go bogus, but, depending on what you think you are getting from DNSSEC, still suboptimal. If we want small, short tractable signatures in DNS, moving to eCDSA is easier now than at any other time. We just have to accept we make a lot of DNSSEC clients stop validating until code updates. Well, IMO, we need people to *understand* what the impact is, especially for the root key / things up the tree. My personal view is that the benefit of ECC outweighs the cost, but it's not just my domains that get affected. W thats how I read it, anyway. -G On Mon, Jan 19, 2015 at 1:17 PM, Warren Kumari war...@kumari.net javascript:_e(%7B%7D,'cvml','war...@kumari.net'); wrote: On Monday, January 19, 2015, Francis Dupont francis.dup...@fdupont.fr javascript:_e(%7B%7D,'cvml','francis.dup...@fdupont.fr'); wrote: In your previous mail you wrote: Currently a number of validators don't do ECC, because of the openssl library from the distribution they are using doesn't include support. This makes ECC an unsupported algorithm, and so it fails open (See RFC4035, Section 5.2, around If the validator does not support any of the algorithms...). Geoff also has a good blog post (http://labs.apnic.net/blabs/?p=544) and presentations at various places (e.g: https://ripe69.ripe.net/presentations/135-18-2014-11-01-ecc.pptx). = This very unfortunate fact is IMHO the major (and perhaps only) issue to solve before deploying ECDSA (and solve the RSA/SHA-1 vs RSA/SHA-2 question). Unfortunately not the only - we also need the registrars to accept ECDSA. But yes, this is annoying- rolling the DNSSEC root key to ECDSA would be very cool, as we could then fit 2 signatures well within the IPv6 MTU. Oh, as was pointed out earlier, Google Public DNS does ECDSA. W I suggest that folk whose ssl libraries don't support ECC should figure out why (see http://tools.ietf.org/html/rfc6090 and also Geoff's blog post for some background) and then recompile with support[0]. = I can't say more. Thanks francis.dup...@fdupont.fr -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org javascript:_e(%7B%7D,'cvml','DNSOP@ietf.org'); https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RSA/SHA-1 to = RSA/SHA-256 ?
Another take on this, which may make some people feel very uncomfortable, is to propose key migration in RSA via a downgrade keylength: sign with a shorter RSA key, and re-sign with a long one once the original long one is widely deprecated under 5011. 1024- new512 (!) - new1024 this avoids having to carry 1024+new2048 because you only ever carry 1024+512. but this is morally the story roll often which also makes people unhappy. Its not 'invalidation' outcome Paul: its non-validation. the damage is that you cease to validate, not that you invalidate otherwise valid things. But yes. it has qualities of reputational damage because you promise DNSSEC but for some validators, cannot deliver. On Mon, Jan 19, 2015 at 3:10 PM, Paul Wouters p...@nohats.ca wrote: On Mon, 19 Jan 2015, Paul Hoffman wrote: If we want small, short tractable signatures in DNS, moving to eCDSA is easier now than at any other time. We just have to accept we make a lot of DNSSEC clients stop validating until code updates. A big +1 to this. A big -1 to this. You suggest basically obsoleting RSA before ECDSA is widely supported. If you want to sunset RSA, write a draft with a clear time table. I don't see why the root zone (or anyone else) currently could not switch the ZSK from 1024 to 2048. I would expect root zone queries including a bigger signature over the DS record would still be much smaller than most zone's APEX with A//MX and RRsigs, which already use 2048 RSA keys on top of that. I think the reason it is still 1024 lies more within practical and procedural matters, and do not relate to packet sizes (which is the only argument for ECDSA unless you think the NSA can factor 2048 or even 1024 in trivial amount of time). So for the root, I suspect switching the ZSK from 1024 RSA to 2048 RSA or to ECDSA is the exact same problem. So why drop RSA and cause a lot of invalidation to happen? That would be much more of a reputation damage than the ill-conceived problem of current 1024 bit RSA keys. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] RSA/SHA-1 to = RSA/SHA-256 ?
Hi, SHA-1 for TLS-certificates is considered insufficient nowadays. But what about the usage of RSA/SHA-1 in DNSSEC ? Should TLD's such as .se make preparations for an algorithm roll-over? -- Marco smime.p7s Description: S/MIME-cryptografische ondertekening ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RSA/SHA-1 to = RSA/SHA-256 ?
Yes, in my opinion it is a good idea to have a plan to migrate to a new algorithm and RSA/SHA-256 is probably the candidate as ECDSA is not widely implemented as far as we can tell (but not sure). NIST is advocating migration (or initial deployment) of RSA/SHA-256 within the .gov TLD. The .gov TLD rolled to RSA/SHA-256 a few years ago when the new operator took over. In the second level, it's roughly half, with the other half using code 7 (RSA/SHA1 with NSEC3) and a few deployments that were still using code 5. I have heard of some large enterprises removing their DS RRset from the parent zone before performing an algorithm roll to prevent validation errors. They were an island during the roll, then added the new KSK's DS RRset when completed. Not ideal, but they were constrained by resources and time. They were also migrating several dozen zones at once too, not just one. I don't think that is a good path for a TLD though. Scott On Jan 16, 2015, at 5:13 AM, Marco Davids (SIDN) marco.dav...@sidn.nl wrote: Hi, SHA-1 for TLS-certificates is considered insufficient nowadays. But what about the usage of RSA/SHA-1 in DNSSEC ? Should TLD's such as .se make preparations for an algorithm roll-over? -- Marco ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop === Scott Rose NIST scott.r...@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ https://www.had-pilot.com/ === ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RSA/SHA-1 to = RSA/SHA-256 ?
On Jan 16, 2015, at 5:13 AM, Marco Davids (SIDN) marco.dav...@sidn.nl wrote: Hi, SHA-1 for TLS-certificates is considered insufficient nowadays. But what about the usage of RSA/SHA-1 in DNSSEC ? Should TLD's such as .se make preparations for an algorithm roll-over? -- Marco ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop Yes, but they should not restrict themselves to just RSA-xxx as a rollover target :-) ECDSA is available and is a good alternative if you want stronger zone signing signatures than 1024 bits. Hopefully we will have a modern ECC signature algorithm available in few years. Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RSA/SHA-1 to = RSA/SHA-256 ?
On Fri, Jan 16, 2015 at 10:59 AM, Olafur Gudmundsson o...@ogud.com wrote: On Jan 16, 2015, at 5:13 AM, Marco Davids (SIDN) marco.dav...@sidn.nl wrote: Hi, SHA-1 for TLS-certificates is considered insufficient nowadays. But what about the usage of RSA/SHA-1 in DNSSEC ? Should TLD's such as .se make preparations for an algorithm roll-over? -- Marco ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop Yes, but they should not restrict themselves to just RSA-xxx as a rollover target :-) ECDSA is available and is a good alternative if you want stronger zone signing signatures than 1024 bits. Hopefully we will have a modern ECC signature algorithm available in few years. Currently a number of validators don't do ECC, because of the openssl library from the distribution they are using doesn't include support. This makes ECC an unsupported algorithm, and so it fails open (See RFC4035, Section 5.2, around If the validator does not support any of the algorithms...). Geoff also has a good blog post (http://labs.apnic.net/blabs/?p=544) and presentations at various places (e.g: https://ripe69.ripe.net/presentations/135-18-2014-11-01-ecc.pptx ). I and some others disagree on the impact of this, but my view is that if I sign a zone it is because I'd like everyone doing DNSSEC to actually validate the answers, not just shrug and move on... I suggest that folk whose ssl libraries don't support ECC should figure out why (see http://tools.ietf.org/html/rfc6090 and also Geoff's blog post for some background) and then recompile with support[0]. W [0]: Assuming they find that appropriate, of course... Olafur ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
