In message <CAKr6gn2P6u=MO-YrXAYMyUCQDPcwM9xLGkZgQSLN5VAVfG-PAg@xxxxxxxxxxxxxx> , George Michaelson writes: > > I understand its not the core issue, but would it be safe to assume any > resolver which passes the cookie test has 5011 capability? No. I would expect cookies to be deployed even if you are not doing DNSSEC. It is very light weight compared to DNSSEC. As for RFC 5011, it is a crock. We should be using something like CDS with start and end dates plus retry timers. That way a resolver will know which keys/ds records are supposed to be used as trust anchors instead of the mess we have now where there is no certainty that any zone is using RFC 5011. > do we have any > concept of a minimum functionality set which you have to meet, such that we > can assume cookies tells us anything about protocol capability? The prerequistes for cookies is EDNS support. You can theoretically deploy it without having to know if the remote supports it. That said there are some really broken EDNS implementations out there. See http://users.isc.org/~marka/ts.html for various measurements. However I think that a active campain to inform operators that they are deploying broken servers will work. In many cases upgrading to the latest nameserver release will fix the issue. We also have a the following draft-andrews-dns-no-response-issue which covers this as well as other issues. Mark > I'm going with no, but if anyone thinks this is a viable heuristic, I'd > love to know. > On Thu, Dec 4, 2014 at 11:31 AM, Mark Andrews <marka@xxxxxxx> wrote: > > > > > In message <9450AE5B-9401-4E16-856E-FB6B45C3FAAD@xxxxxxxxx>, > > =?utf-8?Q?=F0=9F=9 > > 4=93Dan_Wing?= writes: > > > RFC6346 reduces the space for TCP/UDP ports, which makes port-based = > > > attacks against protocols easier, as was mentioned in RFC6056: =20 > > > > > > "It is also worth noting that, provided adequate algorithms are in > > > use, the larger the range from which ephemeral ports are selected, > > > the smaller the chances of an attacker are to guess the selected port > > > number." > > > > > > The primary mitigation against the Kaminsky was port randomization and = > > > attacks against other protocols may also need such port randomization. = > > > If RFC6346 progresses to Proposed Standard, its impact to the size of = > > > the port space should be noted in RFC6346bis's security considerations. > > > > > > -d > > > > And https://tools.ietf.org/html/draft-ietf-dnsop-cookies-00 removes > > the need for port randomization once deployed. If you don't get a > > cookie back then you can retry using a randomised port. > > > > And just so you know it is not vapour ware BIND 9.10 has a experimental > > implementation sans the error code called SIT. We haven't yet > > stopped randomizing the port but that is planned for. > > > > Once we have a allocated code point we will be dropping non SIT > > responses from servers we have had a SIT response from. > > > > > On Dec 1, 2014, at 2:38 PM, The IESG <iesg-secretary@xxxxxxxx> wrote: > > > > > > >=20 > > > > The IESG has received a request from an individual participant to make > > > > the following status changes: > > > >=20 > > > > - RFC6346 from Experimental to Proposed Standard > > > > (The Address plus Port (A+P) Approach to the IPv4 Address Shortage) > > > >=20 > > > > The supporting document for this request can be found here: > > > >=20 > > > > = > > > > > http://datatracker.ietf.org/doc/status-change-address-plus-port-to-propose= > > > d/ > > > >=20 > > > > The IESG plans to make a decision in the next few weeks, and solicits > > > > final comments on this action. Please send substantive comments to the > > > > ietf@xxxxxxxx mailing lists by 2014-12-29. Exceptionally, comments > > may = > > > be > > > > sent to iesg@xxxxxxxx instead. In either case, please retain the > > > > beginning of the Subject line to allow automated sorting. > > > >=20 > > > > The affected document can be obtained via > > > > http://datatracker.ietf.org/doc/rfc6346/ > > > >=20 > > > > IESG discussion of this request can be tracked via > > > > = > > > > > http://datatracker.ietf.org/doc/status-change-address-plus-port-to-propose= > > > d/ballot/ > > > >=20 > > > >=20 > > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx > > > > > > --047d7bdca1e442406305095a372f > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > <div dir=3D"ltr">I understand its not the core issue, but would it be safe = > to assume any resolver which passes the cookie test has 5011 capability? = > =C2=A0do we have any concept of a minimum functionality set which you have = > to meet, such that we can assume cookies tells us anything about protocol c= > apability?<div><br></div><div>I'm going with no, but if anyone thinks t= > his is a viable heuristic, I'd love to know.=C2=A0</div></div><div clas= > s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Dec 4, 2014 at 11:= > 31 AM, Mark Andrews <span dir=3D"ltr"><<a href=3D"mailto:marka@xxxxxxx"; = > target=3D"_blank">marka@xxxxxxx</a>></span> wrote:<br><blockquote class= > =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= > ing-left:1ex"><br> > In message <<a href=3D"mailto:9450AE5B-9401-4E16-856E-FB6B45C3FAAD@cisco= > .com">9450AE5B-9401-4E16-856E-FB6B45C3FAAD@xxxxxxxxx</a>>, =3D?utf-8?Q?= > =3DF0=3D9F=3D9<br> > 4=3D93Dan_Wing?=3D writes:<br> > > RFC6346 reduces the space for TCP/UDP ports, which makes port-based = > =3D<br> > > attacks against protocols easier, as was mentioned in RFC6056: =3D20<b= > r> > <span class=3D"">><br> > >=C2=A0 =C2=A0"It is also worth noting that, provided adequate algo= > rithms are in<br> > >=C2=A0 =C2=A0 use, the larger the range from which ephemeral ports are = > selected,<br> > >=C2=A0 =C2=A0 the smaller the chances of an attacker are to guess the s= > elected port<br> > >=C2=A0 =C2=A0 number."<br> > ><br> > </span>> The primary mitigation against the Kaminsky was port randomizat= > ion and =3D<br> > > attacks against other protocols may also need such port randomization.= > =C2=A0 =3D<br> > > If RFC6346 progresses to Proposed Standard, its impact to the size of = > =3D<br> > <span class=3D"">> the port space should be noted in RFC6346bis's se= > curity considerations.<br> > ><br> > > -d<br> > <br> > </span>And <a href=3D"https://tools.ietf.org/html/draft-ietf-dnsop-cookies-= > 00" target=3D"_blank">https://tools.ietf.org/html/draft-ietf-dnsop-cookies-= > 00</a> removes<br> > the need for port randomization once deployed.=C2=A0 If you don't get a= > <br> > cookie back then you can retry using a randomised port.<br> > <br> > And just so you know it is not vapour ware BIND 9.10 has a experimental<br> > implementation sans the error code called SIT.=C2=A0 We haven't yet<br> > stopped randomizing the port but that is planned for.<br> > <br> > Once we have a allocated code point we will be dropping non SIT<br> > responses from servers we have had a SIT response from.<br> > <span class=3D""><br> > > On Dec 1, 2014, at 2:38 PM, The IESG <<a href=3D"mailto:iesg-secret= > ary@xxxxxxxx">iesg-secretary@xxxxxxxx</a>> wrote:<br> > ><br> > </span>> >=3D20<br> > <span class=3D"">> > The IESG has received a request from an individu= > al participant to make<br> > > > the following status changes:<br> > </span>> >=3D20<br> > <span class=3D"">> > - RFC6346 from Experimental to Proposed Standard= > <br> > > >=C2=A0 =C2=A0 (The Address plus Port (A+P) Approach to the IPv4 Ad= > dress Shortage)<br> > </span>> >=3D20<br> > <span class=3D"">> > The supporting document for this request can be = > found here:<br> > </span>> >=3D20<br> > > > =3D<br> > > <a href=3D"http://datatracker.ietf.org/doc/status-change-address-plus-= > port-to-propose=3D" target=3D"_blank">http://datatracker.ietf.org/doc/statu= > s-change-address-plus-port-to-propose=3D</a><br> > > d/<br> > > >=3D20<br> > <span class=3D"">> > The IESG plans to make a decision in the next fe= > w weeks, and solicits<br> > > > final comments on this action. Please send substantive comments t= > o the<br> > </span>> > <a href=3D"mailto:ietf@xxxxxxxx";>ietf@xxxxxxxx</a> mailing= > lists by 2014-12-29. Exceptionally, comments may =3D<br> > <span class=3D"">> be<br> > > > sent to <a href=3D"mailto:iesg@xxxxxxxx";>iesg@xxxxxxxx</a> instea= > d. In either case, please retain the<br> > > > beginning of the Subject line to allow automated sorting.<br> > </span>> >=3D20<br> > <span class=3D"">> > The affected document can be obtained via<br> > > > <a href=3D"http://datatracker.ietf.org/doc/rfc6346/"; target=3D"_b= > lank">http://datatracker.ietf.org/doc/rfc6346/</a><br> > </span>> >=3D20<br> > <span class=3D"">> > IESG discussion of this request can be tracked v= > ia<br> > </span>> > =3D<br> > > <a href=3D"http://datatracker.ietf.org/doc/status-change-address-plus-= > port-to-propose=3D" target=3D"_blank">http://datatracker.ietf.org/doc/statu= > s-change-address-plus-port-to-propose=3D</a><br> > > d/ballot/<br> > > >=3D20<br> > > >=3D20<br> > ><br> > <span class=3D"HOEnZb"><font color=3D"#888888">--<br> > Mark Andrews, ISC<br> > 1 Seymour St., Dundas Valley, NSW 2117, Australia<br> > PHONE: <a href=3D"tel:%2B61%202%209871%204742" value=3D"+61298714742">+61 2= > 9871 4742</a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= > =A0INTERNET: <a href=3D"mailto:marka@xxxxxxx";>marka@xxxxxxx</a><br> > <br> > </font></span></blockquote></div><br></div> > > --047d7bdca1e442406305095a372f-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx