On Thu, Feb 8, 2018 at 4:51 AM, Willem Toorop <wil...@nlnetlabs.nl> wrote:
> Op 08-02-18 om 03:27 schreef Shumon Huque: > > On Wed, Feb 7, 2018 at 8:21 AM, Mirja Kühlewind <i...@kuehlewind.net > > <mailto:i...@kuehlewind.net>> wrote: > > > > Mirja Kühlewind has entered the following ballot position for > > draft-ietf-tls-dnssec-chain-extension-06: No Objection > > > > ------------------------------------------------------------ > ---------- > > COMMENT: > > ------------------------------------------------------------ > ---------- > > > > Two minor, mostly editorial comments: > > > > 1) Intro (sec 2): " It also provides the > > ability to avoid potential problems with TLS clients being unable > to > > look up DANE records because of an interfering or broken > middlebox on > > the path between the client and a DNS server." > > Is that actually a well-known problem (can you provide a reference?) > > > > > > Some folks (at Google and NLnet Labs if I recall; maybe others) have done > > measurements to show this is an actual problem -- for a relatively small > but > > still non-trivial fraction of clients. We'll try to see if we can dig up > > specific > > references to documents that could be cited. > > I wouldn't call it a relatively small fraction :) DNSSEC is severely > hampered for end-entities by broken infrastructure in many different > ways. Sometimes an upstream resolver can be used for positive DNSSEC > answers (i.e. existing records), but not for non-existent or wildcard > answers, because it simply doesn't forward the NSEC(3) proof for it. > > The last measurements we at NLnet Labs did was in July 2015: > > Gorjón, Xavier Torrent, and Willem Toorop. > "Discovery method for a DNSSEC validating stub resolver." > (2015) > > https://nlnetlabs.nl/pub/os3-2015-rp2-xavier-torrent-gorjon.pdf > > Measurements were done with RIPE Atlas, with at the time +-8200 probes. > At the time only 56% of probes received enough DNSSEC data from their > upstreams to be able to perform DNSSEC validation for both positive and > non-existent answers (required for DANE). > Ah, thanks. I'd forgotten that it was so high! I think my "relatively small" comment was recalling an earlier study (I think by Google) that saw a breakage of around ~ 5%, but I think that was just measuring the ability to lookup and obtain less common RR types and did not measure ability to perform full DNSSEC validation. Shumon.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
