Re: [Add] fixing coffee shop brokenness with DoH

[Petr Špaček <[e-mail]>]

On 25. 07. 19 7:57, Eric Rescorla wrote:
> 
> 
> On Wed, Jul 24, 2019 at 8:33 PM Petr Špaček <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
> 
> 
>     On 24. 07. 19 13:14, Eric Rescorla wrote:
>     >
>     >
>     > On Wed, Jul 24, 2019 at 9:00 AM Jim Reid <[e-mail]
>     <mailto:[e-mail]>
>     > <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>     >
>     >
>     >
>     >     > On 24 Jul 2019, at 16:11, Eric Rescorla <[e-mail]
>     <mailto:[e-mail]>
>     >     <mailto:ekr@rtfm. <mailto:ekr@rtfm.>.com>> wrote:
>     >     >
>     >     > See my response to Ted. From the perspective of the client,
>     acting
>     >     accordingly looks basically identical to how you behave with a
>     valid
>     >     NXDOMAIN, and so DNSSEC doesn't change the situation very much.
>     >
>     >     Not really. A validation failure is a fairly strong indication
>     that
>     >     the resolver is lying to you.
>     >
>     >
>     > Not really, no. Our current belief is that there is going to be
>     quite a
>     > high rate of non-malicious validation failures.
> 
>     Could you please elaborate why you believe so?
> 
>     According to APNIC measurements, any site which has DNSSEC-related
>     problem will become unreachable for > 20 % of Internet users [0]. In my
>     coutry (CZ), more than 60 % of users are behind a DNSSEC-validating
>     resolver [1].
> 
>     As far as I can tell, telco support lines are not ringing because of
>     DNSSEC.
> 
>     What data indicate some DNSSEC-related breakage?
> 
> 
> The concern isn't misconfigured zones but rather middleboxes that strip
> RRSIGs or otherwise
> invalidate the DNSSEC signatures, so these measurements, which primarily
> measure whether
> the recursive resolver has a clear path, are not really that relevant.
> 
> This hasn't been directly measured in some years, but here's AGL's post
> on this from 2015
> https://www.imperialviolet.org/2015/01/17/notdane.html
> 
> I'd certainly be interested in some evidence that this kind of problem
> has gone away, but
> it probably won't be us who takes it.

Understood, so it is worry about transport, which should be solved by
DoH, right?

What kind of non-clear path problem you are expecting in DoH channel
from Firefox to a recursive of your choice?

Petr Špaček  @  CZ.NIC

> 
> -Ekr
> 
> 
>     Thank you.
> 
> 
>     [0] https://stats.labs.apnic.net/dnssec/XA
>     [1] https://stats.labs.apnic.net/dnssec/CZ
> 
>     Petr Špaček  @  CZ.NIC
> 
> 
>     >
>     >
>     >     Or should be. So a security-aware application would know the
>     current
>     >     resolver can't be trusted (or is at the very least suspcious) and
>     >     take suitable countermeasures. That's what I meant by "act
>     accordingly".
>     >
>     >  
>     > What do you believe those countermeasures are?
>     >
>     > -Ekr
> 
>     -- 
>     Add mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/add