Subject: [DNSOP] RSA/SHA-1 to >= RSA/SHA-256 ?

From: "Marco Davids (SIDN)" <[email-masked]>
Date: Fri, 16 Jan 2015 11:13:14 +0100

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

---

From: "Rose, Scott W." <[email-masked]>
Date: Fri, 16 Jan 2015 09:57:46 -0500

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) <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

===================================
Scott Rose
NIST
[email-masked]
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
https://www.had-pilot.com/
===================================

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 16 Jan 2015 10:59:00 -0500

> Should TLD's such as .se make preparations for an algorithm roll-over?

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

---

From: Warren Kumari <[email-masked]>
Date: Fri, 16 Jan 2015 14:22:57 -0500

> 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...

-- 
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

---

From: Francis Dupont <[email-masked]>
Date: Mon, 19 Jan 2015 15:44:36 +0100

In your previous mail you wrote:

>  (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).

>  Geoff's blog post for some background) and then recompile with

=> I can't say more.

Thanks

[email-masked]

---

From: Warren Kumari <[email-masked]>
Date: Mon, 19 Jan 2015 10:17:22 -0500

On Monday, January 19, 2015, Francis Dupont <[email-masked]>
wrote:

> places

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

> [email-masked] <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

---

From: George Michaelson <[email-masked]>
Date: Mon, 19 Jan 2015 13:30:08 -0200

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 <[email-masked]> wrote:

> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.

---

From: Dick Franks <[email-masked]>
Date: Mon, 19 Jan 2015 15:59:43 +0000

Next release of Net::DNS::SEC will support  ECDSA and ECC-GOST

Dick Franks
________________________

---

From: Dick Franks <[email-masked]>
Date: Mon, 19 Jan 2015 15:25:19 +0000

Dick Franks
________________________

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 19 Jan 2015 08:21:22 -0800

On Jan 19, 2015, at 7:30 AM, George Michaelson <[email-masked]> 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.
> 
> 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. 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

---

From: Warren Kumari <[email-masked]>
Date: Mon, 19 Jan 2015 11:39:32 -0500

> 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..

> 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.

> 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

> On Mon, Jan 19, 2015 at 1:17 PM, Warren Kumari <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>>
>>
>> On Monday, January 19, 2015, Francis Dupont <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>>
>>> >  (e.g:
>>> https://ripe69.ripe.net/presentations/135-18-2014-11-01-ecc.pptx).
>>>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 19 Jan 2015 12:10:28 -0500 (EST)

> 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/AAAA/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

---

From: George Michaelson <[email-masked]>
Date: Mon, 19 Jan 2015 16:12:50 -0200

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.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 20 Jan 2015 10:55:26 -0500

On Jan 16, 2015, at 14:22, Warren Kumari <[email-masked]> wrote:
> actually validate the answers, not just shrug and move on…

DNSSEC exists to allow the receiver of data to validate what they have received.  For this reason, DNSSEC is all about making the validator happy.

It’s become a common misconception of DNSSEC it that it is there to benefit the zone administrator.  (Think how silly that sounds!)

The root of this is the nature of open-ended distributed systems.  In such environments, of which the Interent is a sterling example, one cannot ennumerate the participants.  This has a number of theoretical implications, too many to list in an email.   What applies here is, in such an environment it is insane to have an expectation that one's messages will be treated as one wishes.  Whenever designing a method of interaction in such a system, the most reslient design will rely on defining how a participant reacts to environmental stimuli - i.e., how a receiver of a packet reacts to it.

In DNSSEC the most important part of the protocol definition[0] is how (under local policy) the process of validation is recommended to be performed.  Subsidiary to that is guidance given to the sources of data when preparing data for transmission - for the mere fact that this sets up expectations of the receiver.

It’s good to recommend improved cryptography to deployers of validators.  (Better is an open/relative term.)  It’s bad to expect deployers to follow the recommendations.  That is the reason DNSSEC “fails” “open.”

[0] Definition is a terse word, “guidance” is more appropriate but makes the sentance harder to read.