I'm not telling you that you have to require DNSSEC. I'm saying the document is incomplete if you don't talk about how it relates to DNSSEC. I think EKR got the point, so maybe go with his approach?
On Fri, Mar 29, 2024 at 6:27 PM Rob Sayre <say...@gmail.com> wrote: > It's a policy choice, though, right? I think ekr hinted at this issue as > well. > > It's that one might also view requests that reveal the SNI as insecure. If > that's the case, DNSSEC doesn't help. There will certainly be a transition > period where that will be impractical for many servers. I think these are > separate problems, though. > > thanks, > Rob > > > On Fri, Mar 29, 2024 at 3:10 PM Ted Lemon <mel...@fugue.com> wrote: > >> It looks like if you can't get the SCVB you're going to fail insecure, so >> being able to use DNSSEC to prevent that for signed domains seems >> worthwhile. >> >> On Fri, Mar 29, 2024 at 4:41 PM Rob Sayre <say...@gmail.com> wrote: >> >>> On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker < >>> nore...@ietf.org> wrote: >>> >>>> >>>> I don't think it's reasonable to specify the privacy properties of SVCB >>>> and >>>> /not/ talk about DNSSEC validation. >>>> >>> >>> Could you explain more about this part? I think DNSSEC doesn't add much >>> here, unless you want to accept non-ECH traffic. For example, many of the >>> test servers will bounce you to some other site if you don't send ECH or >>> screw it up in some way (speaking as someone who has screwed it up many >>> times...). >>> >>> I think there might be a DoS attack here, where someone messes with the >>> response, but they can also turn off the DNSSEC bit unless it's DoT/DoH/DoQ >>> etc. So, if using those, it's just the trustworthiness of the DNS server >>> itself, right? Sorry if I'm missing something. >>> >>> thanks, >>> Rob >>> >>>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
