Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)

[Shumon Huque <[e-mail]>]

On Thu, Feb 8, 2018 at 4:51 AM, Willem Toorop <[e-mail]> wrote:

> Op 08-02-18 om 03:27 schreef Shumon Huque:
> > On Wed, Feb 7, 2018 at 8:21 AM, Mirja Kühlewind <[e-mail]
> > <mailto:[e-mail]>> 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.