I don't think it relates to DNSSEC. You can fail at DNS (DNSSEC failure) or you can fail during ECH (unless you want to use non-ECH, which is not ECH, and not part of this draft).
It makes sense to me: one can reject a request unless the requirements embedded in the SVCB are met (the server chooses those, which can include many aspects of the request). I don't understand why one would insert DNSSEC here. That seems to be the whole point--it works without it. thanks, Rob On Fri, Mar 29, 2024 at 3:57 PM Ted Lemon <mel...@fugue.com> wrote: > 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
