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 <s...@sn3rd.com> 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...@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 To unsubscribe send an email to tls-le...@ietf.org
