In message <cahpuvdvfyfrxxmpjg-ho0wv_sd9fmpzyzjwtgfzeza-9hfq...@mail.gmail.com>, Shumon Huque writes: > On Mon, Jul 10, 2017 at 5:00 PM, Paul Wouters <p...@nohats.ca> wrote: > > > 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. > >> > >> https://tools.ietf.org/html/draft-huque-dnssec-alg-nego-00 > >> > > > > 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. > > > > 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.
It will take a 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. 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. > 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. 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. > 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. > > 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. > > > Yes, that should have been a MUST (I made a note of that already for the > next revision). > > > > 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. > > > > 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. > > > > I don't think response size during a KSK algorithm roll is an issue that > > needs fixing. > > > > Can there be 'pre-pubished' DNSKEY's that are not used for signing yet, to > >>> would not be available for response signatures? > >>> > >> > > 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. > >> > > > > 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. > > > > Really? RSA1024 is still widely deployed, and is frequently why DNSSEC is > 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. > > 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. > > See the first example I gave. We're not trying to surreptitiously sneak in > a use case. > > -- > Shumon Huque > > --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"><<a href=3D"= > mailto:p...@nohats.ca"; target=3D"_blank">p...@nohats.ca</a>></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've posted a new draft on algorithm negotiation which we're hopin= > g<br> > to discuss at IETF99 (and on list of course). I'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'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's not a use case mentioned.<br></bl= > ockquote><div><br></div><div>Perhaps we didn'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'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'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't scaled up my authoritative infrastructure sufficien= > tly to deal with that.</div><div><br></div><div>I also don'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'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 "permanently" 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'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 'pre-pubished' DNSKEY'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= > 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 "strong" to "even str= > onger"<br> > algorithms, and not from "weak" to "strong enough", so = > I don'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't think that we should<br> > aim for that to become commonplace.</blockquote><div><br></div><div>See the= > first example I gave. We'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 > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --===============7925457567352458756==-- > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
