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...@rtfm.com> wrote: > > > > On Sat, Mar 30, 2024 at 11:09 AM Ted Lemon <mel...@fugue.com> 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 <say...@gmail.com> > On Sat, Mar 30, 2024 at 10:47 AM Erik Nygren <erik+i...@nygren.org> 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 > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
