[TLS]Re: Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Erik Nygren <[e-mail]>]

Submitted new revision:

 https://datatracker.ietf.org/doc/html/draft-ietf-tls-svcb-ech-02

Only change is adding the text to Security Considerations as discussed
above.

   Erik

On Wed, Apr 10, 2024 at 9:14 AM Sean Turner <[e-mail]> wrote:

> Ted & ErikN,
>
> So it looks like ErikN submitted the following PR and ekr approved:
> https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/1
>
> If we have resolved your comments, can I ask on of the authors to spin a
> new version and we can look to move this I-D.
>
> Also, could I kindly ask you to revise your review to change to “ready”
> and maybe refer to thread:
> https://mailarchive.ietf.org/arch/msg/tls/VQcqUuOXSE8sgcp4_CHa6Jlc394/
>
> spt
>
> > On Mar 30, 2024, at 19:17, Eric Rescorla <[e-mail]> wrote:
> >
> >
> >
> > On Sat, Mar 30, 2024 at 11:09 AM Ted Lemon <[e-mail]> wrote:
> > Encrypted dns transport works if you can trust the provider you are
> talking to. DNSSEC works even if you can’t. And if your provider is
> trustworthy, DNSSEC validation of results acquired through this tunnel
> should work. So it’s silly in this case to trust the tunnel—there’s no
> upside to doing so other than avoiding a few signature verifications.
> >
> > I don't object to people doing DNSSEC validation of ECH records (though
> AFAIK no major browser does so), but...
> >
> > 1. The resolver only gains a limited amount by forging the SVCB response
> because the resolver already knows the domain name you are going to. This
> does conceal (say) the ALPN, but that's usually less interesting than the
> SNI.
> > 2. If the authoritative domain is misconfigured, which is not unheard
> of, then this can create resolution failures (this is true for A/AAAA, of
> course). Probably not much of an issue for the big public recursives, but
> can definitely be an issue if you are just talking to some locally-supplied
> resolver.
> >
> > -Ekr
> >
> >
> > Op za 30 mrt 2024 om 14:02 schreef Rob Sayre <[e-mail]>
> > On Sat, Mar 30, 2024 at 10:47 AM Erik Nygren <[e-mail]>
> wrote:
> >
> > An attacker who can prevent SVCB resolution can deny clients any
> associated security benefits.
> >
> > Yes.
> >
> > A hostile recursive resolver can always deny service to SVCB queries,
> but network intermediaries can often prevent resolution as well, even when
> the client and recursive resolver validate DNSSEC and use a secure
> transport. These downgrade attacks can prevent a client from being aware
> that "ech" is configured which would result in the client sending the
> ClientHello in cleartext.
> >
> > I think s/would/could/ here.
> >
> > I don't know if we want to write it, but doesn't using encrypted
> transport DNS to an IP address avoid this problem? Like using 1.1.1.1 or
> 8.8.8.8 etc. I know that raises centralization issues, but it does help
> with this issue.
> >
> > thanks,
> > Rob
> >
>
>