Op 08-02-18 om 03:27 schreef Shumon Huque:
> On Wed, Feb 7, 2018 at 8:21 AM, Mirja Kühlewind <[email protected]
> <mailto:[email protected]>> 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).
There is a RFC that outlines detection and mitigation techniques on how
to deal with this from DNSSEC validation stub resolvers:
RFC8027 - DNSSEC Roadblock Avoidance
Ultimately such a stub resolver has to be able to fallback to full
recursive resolving (i.e. iterating from the root). Although even that
might fail...
Furthermore, hampered DNS (but not specifically DNSSEC), is the primary
motivation for the new DNS over HTTPS draft (and workgroup):
https://tools.ietf.org/html/draft-ietf-doh-dns-over-https
(DoH might be the ultimate final fallback in DNSSEC Roadblock Avoidance)
>
> or would
> it be enough to say something like this: " It also provides the
> ability to avoid potential problems with TLS clients being unable to
> look up DANE records when DNS server is not reachable."
>
>
> Your rewording of this sentence would unfortunately not be accurate.
> It's usually not the DNS server that is unreachable, but that some middlebox
> has done something wrong, such as: not allow DANE queries or responses
> through; not allow DNSSEC signatures through; not allow EDNS options
> that enable DNSSEC through, or engage in other misbehavior.
>
>
> 2) IANA Considerations should probably be updated.
>
>
> I guess you are suggesting that the last sentence is probably obsolete:
>
> "If the draft is adopted by the WG, the authors expect to make an
> early allocation request as specified in [RFC7120]."
>
> Agreed. It's a little late for that! :-)
>
> We will remove it.
>
> Shumon Huque
>
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
