On Thu, Feb 8, 2018 at 9:32 AM, Shumon Huque <shu...@gmail.com> wrote: > 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.
What's the behavior when the middlebox is a proxy, let's say existing a managed network? I presume from from section 3.1 that this negotiation doesn't work in that instance unless sites configured for this are not subject to the proxy as is often done for financial site access from corporate networks. It would be good to know if it does work and that is addressed with the text Mirja calls out for her #1 question. Having this clarified could be helpful. Thanks. > > Shumon. > -- Best regards, Kathleen _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
