Subject: [DNSOP] New draft: Algorithm Negotiation in DNSSEC

From: Shumon Huque <[email-masked]>
Date: Tue, 4 Jul 2017 11:42:56 -0400

Hi folks,

We've posted a new draft on algorithm negotiation which we're hoping to
discuss at IETF99 (and on list of course). I've discussed this topic with
several folks at DNS-OARC recently.

    https://tools.ietf.org/html/draft-huque-dnssec-alg-nego-00

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : Algorithm Negotiation in DNSSEC
        Authors         : Shumon Huque
                          Haya Shulman
 Filename        : draft-huque-dnssec-alg-nego-00.txt
 Pages           : 9
 Date            : 2017-07-03

Abstract:
   This document specifies a DNS extension that allows a DNS client to
   specify a list of DNSSEC algorithms, in preference order, that the
   client desires to use.  A DNS server upon receipt of this extension
   can choose to selectively respond with DNSSEC signatures using the
   most preferred algorithm they support.  This mechanism may make it
   easier for DNS zone operators to support signing zone data
   simultaneously with multiple DNSSEC algorithms, without significantly
   increasing the size of DNS responses.  It will also allow an easier
   way to transition to new algorithms while still retaining support for
   older DNS validators that do not yet support the new algorithms.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-huque-dnssec-alg-nego/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-huque-dnssec-alg-nego-00
https://datatracker.ietf.org/doc/html/draft-huque-dnssec-alg-nego-00

-- 
Shumon Huque

---

From: Bob Harold <[email-masked]>
Date: Mon, 10 Jul 2017 13:50:16 -0400

> https://datatracker.ietf.org/doc/html/draft-huque-dnssec-alg-nego-00
I like the idea.  I am not an DNSSEC expert, but wondering in section 7,
paragraph:

   In order to detect such attacks, the client SHOULD compare the zone
   signing algorithms listed in the zone's authenticated DNSKEY RRset,
   and the preferred list in the query that it sent, to the algorithms
   seen in the response signatures.  If signatures by the most preferred
   algorithm they have in common have not been sent, this may indicate

   an algorithm downgrade attack.

Can there be 'pre-pubished' DNSKEY's that are not used for signing yet, to
would not be available for response signatures?

And perhaps a really dumb off-topic question:
I do not use DNSSEC yet, mostly due to time and effort, secondly due to
concern over the additional size and processing.  Is it possible for me to
start with a new, rarely implemented, algorithm with shorter records, that
most resolvers won't understand yet, and have those that don't understand
it treat the zone as unsigned?  Or will it break everything?  (Section 5
sounds like it breaks)

-- 
Bob Harold

---

From: Shumon Huque <[email-masked]>
Date: Mon, 10 Jul 2017 14:53:43 -0400

> would not be available for response signatures?

Hi Bob,

Very good question Yes, there certainly can be. If the pre-published key's
algorithm is higher strength than the others, then it could cause the
resolver to mistakenly deduce an algorithm downgrade attack might be in
progress. I think this argues that we really do need the new zone apex
(active) algorithms list record - which we already were thinking of
proposing - in the last paragraph of Section 7.

> it treat the zone as unsigned?  Or will it break everything?  (Section 5

(Only) Unknown algorithms will currently cause resolvers to treat the zone
as unsigned (fail open). So, nothing will break, but resolvers that don't
understand the new algorithm won't authenticate the signatures and the
benefit of DNSSEC is lost.

-- 
Shumon Huque

---

From: "Michael H. Warfield" <[email-masked]>
Date: Mon, 10 Jul 2017 16:05:03 -0400

> On Tue, Jul 4, 2017 at 11:42 AM, Shumon Huque <[email-masked]>

...

> I do not use DNSSEC yet, mostly due to time and effort, secondly due
> to concern over the additional size and processing.  Is it possible
> for me to start with a new, rarely implemented, algorithm with
> shorter records, that most resolvers won't understand yet, and have
> those that don't understand it treat the zone as unsigned?  Or will
> it break everything?  (Section 5 sounds like it breaks)

There is not much at all involved in time or effort any more.

I use to manually sign my zones but I've shift over to having "bind"
just manage all my keysigning and I just update the zone and it
happens.  You just set up your initial keys and register your KSK (Key
Signing Key) with your registraur (assuming they support it) and you
should be good to go.  Rolling your KSK's is still (cough) entertaining
but not essential if you're just getting your feet wet. 

Some registraurs support this and some don't.  Some will support DNSsec
for the zones but then require you to "self host" your DNS (optionally
slaving from your master).  I self host and always have.  I also use
Hurricane Electric for additional slaves.  They've gotten much better
at DNSsec though they won't manage it for their hosted zones. 
DreamHost is another one that will support registration but you have to
self host your master (which then becomes problematical if you want
them to host your web site).  If you want the hosting company to manage
DNSsec for you, good luck.  There are some registraurs (some very big
ones) that still don't support DNSsec or only support it as a "premium"
feature and you should just kick them to the curb.

Over all, it's gotten a lot easier and really not a big deal.  Biggest
challenge is getting your IT department to spell DNSsec.  :-P

Mike

-- 
Michael H. Warfield (AI4NB) | (706) 850-8770 |  [email-masked]
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
ARIN whois: ARIN-MHW9       | An optimist believes we live in the best of all
PGP Key: 0xC0EB9675674627FF | possible worlds.  A pessimist is sure of it!

---

From: Shumon Huque <[email-masked]>
Date: Mon, 10 Jul 2017 16:22:37 -0400

On Mon, Jul 10, 2017 at 2:53 PM, Shumon Huque <[email-masked]> wrote:

>> Can there be 'pre-pubished' DNSKEY's that are not used for signing yet,
>> to would not be available for response signatures?
>>
>
> Hi Bob,
>

Replying to my own message (sorry!) ..

It occurs to me that RFC 4035 and RFC 6781 both say that zone data
currently need to be signed by a key of each algorithm in the DNSKEY RRset.
So perhaps you can't pre-publish a key of a new algorithm. This draft, if
adopted, may also have to qualify some existing language (e.g.
distinguishing an authoritative server _having_ signatures of each
algorithm, from selectively _returning_ signatures of a specific algorithm,
if signaled).

-- 
Shumon Huque

---

From: Paul Wouters <[email-masked]>
Date: Mon, 10 Jul 2017 17:00:33 -0400 (EDT)

On Mon, 10 Jul 2017, Shumon Huque wrote:

> We've posted a new draft on algorithm negotiation which we're hoping
> to discuss at IETF99 (and on list of course). I've discussed this
> topic with several folks at DNS-OARC recently.
> 

I'm not a fan :)

 	This means that DNS servers have to send responses with signatures of
 	all algorithms that the requested data are signed with, which can
 	result in significantly large responses.

This seems to be a pretty small use case. And it is the only one
mentioned in the introduction. It only affects zones that are in
algorithm rollover, unless you want to run zones that permanently sign
using multiple algorithms, but that's not a use case mentioned.

For any caching nameserver with multiple clients, there will be no gain
for the next 10 years, as it only takes 1 old client not using this
option to cause the caching nameserver to refetch (adding more bandwidth
usage)

You explain all this is vulnerable to a downgrade attack. And the
clients SHOULD (not MUST?) check the algorithms used in the DNSKEY
RRset. If the client can do that, why bother with a new EDNS0 option
to begin with? (I think the answer is "because an exiting DNSKEY might
be in the DNSKEY RRset, but no longer in use" but that would also affect
the downgrade attack then)

Since you need to survive the DNSEY RRset size, most of the introduction
explaining how this is to survive packet size matters at all, you still
need to survive it.

I don't think response size during a KSK algorithm roll is an issue that
needs fixing.

> algorithm is higher strength than the others, then it could cause the resolver to
> mistakenly deduce an algorithm downgrade attack might be in progress. I think this
> argues that we really do need the new zone apex (active) algorithms list record -
> which we already were thinking of proposing - in the last paragraph of Section 7.

One would hope zones are migrated from "strong" to "even stronger"
algorithms, and not from "weak" to "strong enough", so I don't think
algorithm downgrade is ever an issue.

This draft gives me a feeling it is really about something else, keeping
long term dual signed zones out there. I don't think that we should
aim for that to become commonplace.

Paul

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Mon, 10 Jul 2017 17:01:16 -0400

Shumon,

In section 5 your draft says:

   If an Authoritative Server has no algorithms in common with the
   Preferred Algorithms list in the incoming query, it MUST send back a
   SERVFAIL response (Response Code 2).  This response MUST contain the
   list of algorithms supported by the server in the EDNS0 Preferred
   Algorithms option.

This is a HORRIBLE violation of the DNSSEC spirit. All validators are
supposed to fail to open when they can not validate algorithm the signature
is generated by.

Section 6
This is hopeless algorithm, that goes against the justification of the
document.
basically it may force validating resolvers to fetch the answers multiple
times for each TTL; once without DNSSEC, then for first algorithm, then for
all algorithms ==> right now validating resolvers only fetch once with
DNSSEC enabled.

This is a HORRIBLE violation of the DNSSEC spirit. All validators are
supposed to fail to open when they can not validate algorithm the signature
is generated by.

overall this draft main idea: DNS publishers should sign with more
algorithms, ===> this means more keys in DNSKEY set i.e. larger DNSKEY set
==> better for DDoS

Olafur

On Tue, Jul 4, 2017 at 11:42 AM, Shumon Huque <[email-masked]> wrote:

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

---

From: Shumon Huque <[email-masked]>
Date: Mon, 10 Jul 2017 17:59:18 -0400

> using multiple algorithms, but that's not a use case mentioned.

Perhaps we didn't explain it clearly enough, so let me give you a concrete
example:

My zone is currently signed with 2048-bit RSASHA256. I want to offer
signatures with Ed448 (or some other new algorithm) also, so that newer
validators can take advantage of it. However, I want to be able to continue
to support the current population of validators that don't support Ed448
until a sufficient amount of time has passed where they have all been
upgraded - this could be some number of years.

I also don't want to double sign the zone and return multiple signatures in
the responses, because they might be fragmented and cause timeouts and
retransmissions at the client (validator) end. I could truncate those
responses and prompt them to re-query over TCP, but then again I have
caused an unnecessary failed roundtrip and have incurred additional
processing costs associated with TCP, and maybe I haven't scaled up my
authoritative infrastructure sufficiently to deal with that.

I also don't want to deploy only Ed448 and cause my zone to be instantly
treated as unsigned by the vast majority of resolvers. Obviously, because
I've nullified the security benefit of DNSSEC, but also because I have
application security protocols, like DANE, that critically depend on DNSSEC
authentication, for which this would pose a grave security risk.

So the goal is not to have them "permanently" signed with multiple
algorithms, but for a defined transition period, which may not be very
short. At that point, the older algorithm would be withdrawn -- so
algorithm rollover, but over an extended period.

> RRset.

Yes, that should have been a MUST (I made a note of that already for the
next revision).

> explaining how this is to survive packet size matters at all, you still

Of course there are initial costs. The goal is longer term - the benefits
will increase with more adoption over time. There will be a lot of large
responses initially, which will decrease over time.

>> resolver to

Really? RSA1024 is still widely deployed, and is frequently why DNSSEC is
the butt of jokes in the larger security community.

> aim for that to become commonplace.

See the first example I gave. We're not trying to surreptitiously sneak in
a use case.

-- 
Shumon Huque

---

From: Shumon Huque <[email-masked]>
Date: Mon, 10 Jul 2017 18:16:53 -0400

> supposed to fail to open when they can not validate algorithm the signature

As I tried to explain in my previous note to Paul Wouters - fail open is
horrible for DANE. Protocols can evolve. If DNSSEC had algorithm
negotiation from the beginning, fail open would not have been necessary.
This fail open behavior frequently takes people not in the DNSSEC club by
complete surprise. I've lost track of how many "WTF" moments I've had to
explain to other people about this behavior. This proposed behavior change
is also signaled, not unilateral. But let's debate ...

Section 6
> all algorithms ==> right now validating resolvers only fetch once with

There has to be some initial fallback behavior with costs. This is not
uncommon in new protocols. Think about longer term benefits.

> supposed to fail to open when they can not validate algorithm the signature

See previous discussion.

> algorithms, ===> this means more keys in DNSKEY set i.e. larger DNSKEY set

DNSSEC already has a DDoS reputation - this isn't going to make things that
much worse. Also DNSSEC has already been way surpassed in this area by
NTP/SNMP etc. What we should be working on is deployment of proper protocol
level mitigations, like Cookies, etc.

-- 
Shumon Huque

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Jul 2017 08:41:02 +1000

In message <[email-masked]>, Shumon 
> upgraded - this could be some number of years.

It will take a number of years.
 
> authoritative infrastructure sufficiently to deal with that.

Just send the large UDP messages up to the advertised EDNS UDP size.
Just make sure that your end correctly handles ICMP PTB messages
and doesn't have stupid firewall rules (or othe equipement) that
drop your fragmented replies.  If your equipement can't handle ICMP
PTB, fragment at sizes that won't generate PTB responses / don't
set DF on the packets and set your TCP segment sizes so that they
won't generate ICMP PTB.  Let the other end deal with their
broken/misconfigured equipment.  Its not your job to get the answers
through their broken equipement.  All you are doing is penalising
those that have working equipement by forcing them to use TCP when
UDP would be sufficient.  All that does is shift packet size issues
to TCP.  Slow validation will get them to fix their equipement.

> authentication, for which this would pose a grave security risk.

For some reason there is this insane rush to use Ed448 before even
the major crypto providors have shipped releases which support it.
Get support into major packages then use it in production.  Yes,
we are working on adding it to BIND.  Name servers get upgraded.

> the butt of jokes in the larger security community.
 
Which is solved by not allowing key generators to generate small keys.  This
isn't a algorithm roll issue.

> --f403045dd5b0d7d11d0553fdb193
> Content-Type: text/html; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
> on, Jul 10, 2017 at 5:00 PM, Paul Wouters <span dir=3D"ltr">&lt;<a href=3D"=
> mailto:[email-masked]" target=3D"_blank">[email-masked]</a>&gt;</span> wrot=
> e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
> eft:1px #ccc solid;padding-left:1ex"><span class=3D"">On Mon, 10 Jul 2017, =
> Shumon Huque wrote:<br>
> <br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex">
> We&#39;ve posted a new draft on algorithm negotiation which we&#39;re hopin=
> g<br>
> to discuss at IETF99 (and on list of course). I&#39;ve discussed this<br>
> topic with several folks at DNS-OARC recently.<br>
> <br>
> =C2=A0 =C2=A0 <a href=3D"https://tools.ietf.org/html/draft-huque-dnssec-alg=
> -nego-00" rel=3D"noreferrer" target=3D"_blank">https://tools.ietf.org/html/=
> dr<wbr>aft-huque-dnssec-alg-nego-00</a><br>
> </blockquote>
> <br></span>
> I&#39;m not a fan :)<br>
> <br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 This means that DNS servers have to send respon=
> ses with signatures of<br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 all algorithms that the requested data are sign=
> ed with, which can<br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 result in significantly large responses.<br>
> <br>
> This seems to be a pretty small use case. And it is the only one<br>
> mentioned in the introduction. It only affects zones that are in<br>
> algorithm rollover, unless you want to run zones that permanently sign<br>
> using multiple algorithms, but that&#39;s not a use case mentioned.<br></bl=
> ockquote><div><br></div><div>Perhaps we didn&#39;t explain it clearly enoug=
> h, so let me give you a concrete example:</div><div><br></div><div>My zone =
> is currently signed with 2048-bit RSASHA256. I want to offer signatures wit=
> h Ed448 (or some other new algorithm) also, so that newer validators can ta=
> ke advantage of it. However, I want to be able to continue to support the c=
> urrent population of validators that don&#39;t support Ed448 until a suffic=
> ient amount of time has passed where they have all been upgraded - this cou=
> ld be some number of years.</div><div><br></div><div>I also don&#39;t want =
> to double sign the zone and return multiple signatures in the responses, be=
> cause they might be fragmented and cause timeouts and retransmissions at th=
> e client (validator) end. I could truncate those responses and prompt them =
> to re-query over TCP, but then again I have caused an unnecessary failed ro=
> undtrip and have incurred additional processing costs associated with TCP, =
> and maybe I haven&#39;t scaled up my authoritative infrastructure sufficien=
> tly to deal with that.</div><div><br></div><div>I also don&#39;t want to de=
> ploy only Ed448 and cause my zone to be instantly treated as unsigned by th=
> e vast majority of resolvers. Obviously, because I&#39;ve nullified the sec=
> urity benefit of DNSSEC, but also because I have application security proto=
> cols, like DANE, that critically depend on DNSSEC authentication, for which=
>  this would pose a grave security risk.</div><div><br></div><div>So the goa=
> l is not to have them &quot;permanently&quot; signed with multiple algorith=
> ms, but for a defined transition period, which may not be very short. At th=
> at point, the older algorithm would be withdrawn -- so algorithm rollover, =
> but over an extended period.</div><div><br></div><blockquote class=3D"gmail=
> _quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
> 1ex">
> For any caching nameserver with multiple clients, there will be no gain<br>
> for the next 10 years, as it only takes 1 old client not using this<br>
> option to cause the caching nameserver to refetch (adding more bandwidth<br=
> >
> usage)<br>
> <br>
> You explain all this is vulnerable to a downgrade attack. And the<br>
> clients SHOULD (not MUST?) check the algorithms used in the DNSKEY<br>
> RRset. </blockquote><div><br></div><div>Yes, that should have been a MUST (=
> I made a note of that already for the next revision).</div><div>=C2=A0</div=
> ><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
> px #ccc solid;padding-left:1ex">
> Since you need to survive the DNSEY RRset size, most of the introduction<br=
> >
> explaining how this is to survive packet size matters at all, you still<br>
> need to survive it.<br></blockquote><div><br></div><div>Of course there are=
>  initial costs. The goal is longer term - the benefits will increase with m=
> ore adoption over time. There will be a lot of large responses initially, w=
> hich will decrease over time.</div><div>=C2=A0</div><blockquote class=3D"gm=
> ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
> ft:1ex">
> I don&#39;t think response size during a KSK algorithm roll is an issue tha=
> t<br>
> needs fixing.<span class=3D""><br>
> <br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
> argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Can there be &#39;pre-pubished&#39; DNSKEY&#39;s that are not used for sign=
> ing yet, to<br>
> would not be available for response signatures?<br>
> </blockquote></blockquote>
> <br>
> </span><span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0=
>  0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Very good question Yes, there certainly can be. If the pre-published key&#3=
> 9;s<br>
> algorithm is higher strength than the others, then it could cause the resol=
> ver to<br>
> mistakenly deduce an algorithm downgrade attack might be in progress. I thi=
> nk this<br>
> argues that we really do need the new zone apex (active) algorithms list re=
> cord -<br>
> which we already were thinking of proposing - in the last paragraph of Sect=
> ion 7.<br>
> </blockquote>
> <br></span>
> One would hope zones are migrated from &quot;strong&quot; to &quot;even str=
> onger&quot;<br>
> algorithms, and not from &quot;weak&quot; to &quot;strong enough&quot;, so =
> I don&#39;t think<br>
> algorithm downgrade is ever an issue.<br></blockquote><div><br></div><div>R=
> eally? RSA1024 is still widely deployed, and is frequently why DNSSEC is th=
> e butt of jokes in the larger security community.</div><div>=C2=A0</div><bl=
> ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
> ccc solid;padding-left:1ex">
> <br>
> This draft gives me a feeling it is really about something else, keeping<br=
> >
> long term dual signed zones out there. I don&#39;t think that we should<br>
> aim for that to become commonplace.</blockquote><div><br></div><div>See the=
>  first example I gave. We&#39;re not trying to surreptitiously sneak in a u=
> se case.=C2=A0</div><div><br></div><div>--=C2=A0</div><div>Shumon Huque</di=
> v><div><br></div></div></div></div>
> 
> --f403045dd5b0d7d11d0553fdb193--
> 
> 
> --===============7925457567352458756==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============7925457567352458756==--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Mon, 10 Jul 2017 18:55:25 -0400 (EDT)

On Mon, 10 Jul 2017, Shumon Huque wrote:

> Perhaps we didn't explain it clearly enough, so let me give you a concrete example:
> 
> My zone is currently signed with 2048-bit RSASHA256. I want to offer signatures with Ed448 (or some other new algorithm) also, so that
> newer validators can take advantage of it. However, I want to be able to continue to support the current population of validators that
> don't support Ed448 until a sufficient amount of time has passed where they have all been upgraded - this could be some number of years.
> 
> I also don't want to double sign the zone and return multiple signatures in the responses, because they might be fragmented and cause
> timeouts and retransmissions at the client (validator) end. I could truncate those responses and prompt them to re-query over TCP, but
> then again I have caused an unnecessary failed roundtrip and have incurred additional processing costs associated with TCP, and maybe I
> haven't scaled up my authoritative infrastructure sufficiently to deal with that.
> 
> I also don't want to deploy only Ed448 and cause my zone to be instantly treated as unsigned by the vast majority of resolvers. Obviously,
> because I've nullified the security benefit of DNSSEC, but also because I have application security protocols, like DANE, that critically
> depend on DNSSEC authentication, for which this would pose a grave security risk.
> 
> So the goal is not to have them "permanently" signed with multiple algorithms, but for a defined transition period, which may not be very
> short. At that point, the older algorithm would be withdrawn -- so algorithm rollover, but over an extended period.

Okay, that explains it better. but does also confirm you basically want
to be permanently in this state. Because every few years you will have
new fancy algorithms. As a community we should really roll out updated
algorithms faster and deprecate obsoleted algorithms faster.

> Of course there are initial costs. The goal is longer term - the benefits will increase with more adoption over time. There will be a lot
> of large responses initially, which will decrease over time.

But then why not depend on adoption of (and deprecation of) old signing
algorithms?

> Really? RSA1024 is still widely deployed, and is frequently why DNSSEC is the butt of jokes in the larger security community.

You are mixing up keysize and algorithm rollover :P

RSA is not broken, and safe to use, preferably at 2048 key size. No double
signing or algorithm signaling is needed to go from RSA1024 to RSA2048 :)

also: https://www.internetsociety.org/doc/state-dnssec-deployment-2016

 	"The overwhelming majority (~99%) of TLDs use 2048 bit keys"

I can't find a statistics URL for all domains (secspider seems to have
changed and I cannot find the RSA key sizes per domain anymore) but I'm
pretty sure 1024 will be on the decline.

Anyway, my point is that we should not have 20 sexy algorithms, but only
a very limited set of a few algorithms that we all agree are strong
enough. We shouldn't enter into negotiations of prefered crypto
algorithms between auth and recursive servers.

And once opendnssec algorithm rollover is available from stable
distributions, I think we will see most zones go from RSASHA1 to
RSASHA256 or ECDSA.

Paul

---

From: Shumon Huque <[email-masked]>
Date: Mon, 10 Jul 2017 19:43:57 -0400

> algorithms faster and deprecate obsoleted algorithms faster.

I certainly agree with that goal. In practice it is hard to achieve given
the vast population of DNS software and the long tail of feature adoption.

>> will increase with more adoption over time. There will be a lot

That would be ideal. Again desire vs reality. In this case, the earlier
deployers of multiple algorithms are bearing the costs, and would expect to
gain the benefits of selective signature delivery slowly over time. Of
course they are imposing costs in terms of larger responses on everyone
else too, but they would be doing that even without this feature.

This feature is really looking longer term - and hoping to prepare us
better for the introduction of new algorithms in the future. If this gets
implemented, even if no-one initially uses it, we might be prepared for
future iterations of new algorithms (like various post quantum algorithms
or something else).

> You are mixing up keysize and algorithm rollover :P

I was mainly disputing your remark about hoping there are no "weak"
algorithms :-)

I realize that keysize upgrade could address this, but so also could
rolling to a stronger algorithm like ECDPSAP256.

> pretty sure 1024 will be on the decline.

You're only as strong as your weakest link. The weak link in almost all
deployed DNSSEC paths today is RSA1024. Your 2048-bit figure is for KSKs.
Most zone data is signed with RSA1024. Here are my current stats of TLD
keysize distribution:

Key Signing Keys (KSK):
1024 bits: 1 (0.0%)
1280 bits: 5 (0.2%)
1536 bits: 1 (0.0%)
2048 bits: 2022 (98.8%)
4096 bits: 17 (0.8%)

Zone Signing Keys (ZSK):
1024 bits: 1566 (69.7%)
1048 bits: 2 (0.1%)
1152 bits: 5 (0.2%)
1280 bits: 537 (23.9%)
2048 bits: 138 (6.1%)

So roughly 70% of TLDs sign zone data with RSA1024.

> a very limited set of a few algorithms that we all agree are strong enough.

Yes, I am in total agreement. We should as few strong ones as possible. But
that's still more than one.

Some crypto folks are now advocating for new protocols, define only one
cipher family and don't negotiate. But in reality, deployed protocols that
evolved over time have many, and correspondingly have a cipher negotiation
mechanism. TLS has something on the order of 100 cipher suites last time I
looked.

-- 
Shumon Huque.

---

From: Shumon Huque <[email-masked]>
Date: Mon, 10 Jul 2017 19:51:01 -0400

> we are working on adding it to BIND.  Name servers get upgraded.

Hi Mark,

This was a hypothetical example that I thought might come up for some in
the future. I wasn't describing my personal plans, so don't rush to
implement Ed448 on my account! :-)

-- 
Shumon Huque

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Jul 2017 07:05:41 -0400

> algorithms faster and deprecate obsoleted algorithms faster.

Just a reminder: a few years we were talking about how to bootstrap trust on devices that had been on the shelf for longer than the life of the root key.   Now you are proposing that we roll algorithms faster than that.   I'm not saying you're wrong, but there are operational implications to this position.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 19 Jul 2017 10:49:42 +0200

On Tue, Jul 04, 2017 at 11:42:56AM -0400,
 Shumon Huque <[email-masked]> wrote 
 a message of 108 lines which said:

> discuss at IETF99

For the discussion on thursday:

> In contrast, many other security protocols, like TLS, IKE, SSH and
> others, support an algorithm or cipher suite negotiation mechanism

TLS and SSH are end-to-end. Not the DNS, and it makes things more
complicated (see section 6).

> because fragments are often blocked by network security devices.

by STUPID AND BROKEN network security devices. Otherwise, you do not
put the blame where it belongs.

> As can be readily seen from the RSA to ECDSA transition, very few
> zones have transitioned from RSA to ECDSA,

True, but not for the reasons of the response size. Both for my
employer's zones and for my own personal zones, the big issue is the
lack of support in tools like HSMs, the difficulty of algorithm
rollover, and the fact that tools like OpenDNSSEC don't make it
easy. So, we have apparently a disagreement on the basic diagnostic.

> the resolver has selectively cached signatures of a subset of
> algorithms supported by the zon

How does it know? I mean, in the response from the authoritative
server, nothing indicates if the signatures are a subset or
not. Suppose I send the list ECDSA;RSA, and I receive only ECDSA
signatures. How the resolver/cache would now if it was a complete
list?

> but prefers algorithms known to be supported for the name,

Again, where does this knowledge come from?

---

From: Shumon Huque <[email-masked]>
Date: Wed, 19 Jul 2017 14:28:37 +0200

> complicated (see section 6).

Yes, that's certainly true!

> put the blame where it belongs.

I was being polite :-)

I don't disagree at all. But as practical matter, it is still an
operational problem that needs to be dealt with. I would love to eradicate
this problem Internet wide (which I think is Mark Andrew's preferred
solution), but I doubt it will happen any time soon.

> easy. So, we have apparently a disagreement on the basic diagnostic.

It is a problem for some sites. I agree that there are other problems that
dissuade people from algorithm rollovers. But this just means that we need
to collectively work on making this easier, whatever the reasons. This
proposal can address some aspects of this.

> signatures. How the resolver/cache would now if it was a complete

The response contains the EDNS0 option if the responder executed this
protocol. In which case, the cache would tag this response as a subset.

> Again, where does this knowledge come from?

When the resolver queries the DNSKEY RRset for the zone, it knows which
algorithms are supported for the zone.

We're working on some additional tweaks to the protocol, which I'll discuss
on Thursday.

Shumon

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 20 Jul 2017 09:51:45 +0200

On Wed, Jul 19, 2017 at 02:28:37PM +0200,
 Shumon Huque <[email-masked]> wrote 
 a message of 153 lines which said:

> > Suppose I send the list ECDSA;RSA, and I receive only ECDSA
> The response contains the EDNS0 option if the responder executed
> this protocol. In which case, the cache would tag this response as a
> subset.

Sorry, I still do not understand. The EDNS0 option does not indicate
if the set is a subset or not. Or do you assume that, if the response
indicates that the responder executes this protocol, an answer is
always a subset (even if it's not)?

> When the resolver queries the DNSKEY RRset for the zone, it knows
> which algorithms are supported for the zone.

You can have keys which are not used for signing (such as in the root
today).

---

From: Shumon Huque <[email-masked]>
Date: Thu, 20 Jul 2017 10:08:27 +0200

> always a subset (even if it's not)?

The EDNS0 option, if received from the server, indicates that both (1) the
server understands this protocol and (2) the server executed this protocol,
i.e. that response includes a subset (specifically 1) of the deployed
signature algorithms. I think the latest draft says this, but if not, I'll
fix:

    https://tools.ietf.org/html/draft-huque-dnssec-alg-nego-01

Also, if the server uses only one algorithm, but understands this protocol,
then it probably shouldn't include this option, because there is nothing to
do.

> You can have keys which are not used for signing (such as in the root

Certainly, but only for the same algorithm. If there are multiple
algorithms in use at an authoritative server, then there needs to be
signatures associated with each algorithm.

RFC 4035, Section 2.2

   There MUST be an RRSIG for each RRset using at least one DNSKEY of
   each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
   itself MUST be signed by each algorithm appearing in the DS RRset
   located at the delegating parent (if any).

-- 
Shumon Huque

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Thu, 20 Jul 2017 10:39:35 +0200

On Tue, Jul 11, 2017 at 12:16 AM, Shumon Huque <[email-masked]> wrote:

> On Mon, Jul 10, 2017 at 5:01 PM, Ólafur Guðmundsson <[email-masked]
> > wrote:
>
>> Shumon,
>>
I disagree, if a zone operator selects "less-than" common algorithm they do
that at their own risk,
if the risk is not acceptable then it should dual sign....

> uncommon in new protocols. Think about longer term benefits.

After thinking about this a few times,  I still see no future benefits.

> DNSSEC already has a DDoS reputation - this isn't going to make things
> that much worse. Also DNSSEC has already been way surpassed in this area by

I'm not sold on Cookies solving real problems.
The way to get away from that reputation  is online signing of negative
answers and retirement of all RSA signatures (no I'm not promoting NSEC5),
Online signing with NSEC works just fine.

Olafur

---

From: Shumon Huque <[email-masked]>
Date: Thu, 20 Jul 2017 10:45:44 +0200

On Thu, Jul 20, 2017 at 10:39 AM, Ólafur Guðmundsson <[email-masked]>
wrote:
>
>
> I disagree, if a zone operator selects "less-than" common algorithm they
> do that at their own risk,

Yes. The point I was trying to make is that DANE sites (and probably others
if they care about security) cannot afford to fail open. So they have to
dual sign if they can stomach the costs, or delay deploying new algorithms
for a long time. This draft is intended to (eventually) make the dual
signing case easier to deal with operationally.

-- 
Shumon Huque

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Thu, 20 Jul 2017 11:08:35 +0200

On Thu, Jul 20, 2017 at 10:45 AM, Shumon Huque <[email-masked]> wrote:

> On Thu, Jul 20, 2017 at 10:39 AM, Ólafur Guðmundsson <
> [email-masked]> wrote:
>>
>>
> Yes. The point I was trying to make is that DANE sites (and probably
> others if they care about security) cannot afford to fail open. So they
> have to dual sign if they can stomach the costs, or delay deploying new
> algorithms for a long time. This draft is intended to (eventually) make the
> dual signing case easier to deal with operationally.
>

The point I'm making is that the proposed medicine is worse than the
ailment.

Olafur

---

From: Willem Toorop <[email-masked]>
Date: Thu, 20 Jul 2017 11:48:51 +0200

Op 20-07-17 om 10:45 schreef Shumon Huque:
> On Thu, Jul 20, 2017 at 10:39 AM, Ólafur Guðmundsson
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>     I disagree, if a zone operator selects "less-than" common algorithm
>     they do that at their own risk, 
> algorithms for a long time. This draft is intended to (eventually) make
> the dual signing case easier to deal with operationally.

So,

Providers of DANE backed services are stuck on the well-known
algorithms, and do not have insight on algorithm support by clients
verifying these services with DANE.

This draft in combination with double signing, provides the means to
deal with this (and in a secure manner too).

I think this is an important motivation of this work and that this
should be reflected in the Introduction section of the draft.

-- Willem

---

From: Shumon Huque <[email-masked]>
Date: Thu, 20 Jul 2017 12:11:33 +0200

> should be reflected in the Introduction section of the draft.

Thank you Willem, and your point is noted. We will work on improving the
introduction to address this.

-- 
Shumon Huque

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 20 Jul 2017 11:08:10 -0400

Dear colleagues,

On Mon, Jul 10, 2017 at 06:16:53PM -0400, Shumon Huque wrote:
> explain to other people about this behavior.

DNSSEC is mostly like that.  I think it is because most people used to
security extensions are used to them in end to end protocols, and used
to failing when the arrangement is not end-to-end.  For instance,
people also express astonishment that DNSKEYs don't expire.  Everyone
always has to be reminded that signatures expire, and if you want to
expire keys you take them out of the zone.

This is not to say, "Stupid users," but instead to say that at least
_part_ of the reason DNSSEC violates a lot of expectations is because
DNS does.  People continue to believe, for example, that there's
always one authoritative server, one recursive, and one stub.  We all
know that's _also_ a bad model, but it's mostly good enough except
when it isn't.

So, I think one can sympathise completely with the "WTF" moments, but
still think the response is, "Yep, this thing violates all your
assumptions.  Sorry."

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Fri, 21 Jul 2017 12:36:33 +0100

Andrew Sullivan <[email-masked]> wrote:
>
> For instance, people also express astonishment that DNSKEYs don't
> expire.  Everyone always has to be reminded that signatures expire, and
> if you want to expire keys you take them out of the zone.

I agree with your message.

It might be useful to explain this DNSKEY oddity by comparison with x.509
certificates. In particular, it's the cert that expires, not the key, and
when you renew a cert you can re-use the same key.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Portland, Plymouth, North Biscay: Southerly or southwesterly 6 to gale 8
veering westerly or southwesterly 4 or 5, occasionally 6 later. Moderate or
rough. Rain or showers. Good, occasionally poor.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 21 Jul 2017 13:46:58 +0200

> when you renew a cert you can re-use the same key.

Yeah, you *can* reuse the same key, but (I suspect) most don't -- from
what I've seen, then general process is:
1: Erk! My cert is about to / has just expired!!!
2: Search for and follow some online recipe related to "make ssl certificate"
3: ????
4: Go back to sleep.

I think that (but would be happy to be proven wrong) that most
certificate renewals[0] involve a change of keys too.

W
[0]: Well, "legacy certs", excluding sexy new things like LE / ACME, etc.

-- 
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: Fri, 21 Jul 2017 14:58:23 +0200

A fine bit of epistemology lies in the question: is it the same
certificate, if you re-issue it with the same keys? No, because it has
a different serial. but the crypto doesn't care, its the validation
which cares which is a product of the crypto. so validation cares but
cryptographic functions themselves, not such.

The nice thing about bare key cryptography, is that fish don't need
bicycles. Dates are dates and validity intervals are a thing, but you
can re-bake as many times as you like if there is nothing embedded in
the structure like a serial. Oh wait.. we sign the SOA don't we...

I (for one) hang onto the .req file. Maybe thats naughty, but I do, so
in my case Warren routine is that the keypair is being reused,
because.. well.. because I like to. Software I consume I suspect (like
you) doesn't, and re-mints shiny new keys now with added keynomium,
but when I do it by hand? yes I reuse the .req file.

But I am probably being led into bad places as a result. I am sure
wiser heads will say.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 21 Jul 2017 15:23:26 +0200

I've also heard the "changing the keys is good hygiene" argument -- if
someone has wandered off with your private keys (like an old
administrator) you have limited how long they can reuse them.... but,
a: there is room for argument and b: we have gotten way down into the
weeds here...

W

---

From: "Peter van Dijk" <[email-masked]>
Date: Sat, 22 Jul 2017 01:52:34 +0200

Hello George,

> but when I do it by hand? yes I reuse the .req file.

As a data point, several Let’s Encrypt clients will reuse keys. Those 
that do not by default can often be configured to do so. The benefits of 
reusing the key should be obvious to anyone that also uses TLSA. If you 
think about it, a TLSA record is also a certificate, but your signer 
auto-renews it for you.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/