Okay, I think I see the disconnect, maybe. The issue I'm pointing to is that you may or may not be doing DNSSEC validation. And you may or may not be /able/ to do DNSSEC validation if the infrastructure breaks it accidentally or deliberately.
The document says: "The SVCB-optional client behavior specified in (Section 3 of [SVCB]) permits clients to fall back to a direct connection if all SVCB options fail. This behavior is not suitable for ECH, because fallback would negate the privacy benefits of ECH." So it's saying that the default handling of SVCB is incorrect and would fail open, and overriding that behavior. Given that this is the case, that implies that it matters whether the data has been validated, but nowhere in the document, certainly not in Security Considerations, is any mention made of this issue. So that's what I'm pointing out. It is absolutely not the case in practice that all stub resolvers do validation. You are making a security decision about trust based on data the trustworthiness of which you've not discussed, in a situation where the implementor has meaningful choices to make with respect to validating that trustworthiness. So it's worth mentioning that if the policy is not to validate, this vulnerability exists. I'm a DNS guy, not a TLS guy, so I don't know the history of this work—I'm just making this observation about the document I was asked to review. The fact that (apparently) no DNSDIR review ever raised this issue about the other documents you mentioned is of no interest to me—I'm not reviewing those documents.Whether you take this advice is between you and the IESG. I'm not even claiming to be right—just pointing out the issue I see. On Fri, Mar 29, 2024 at 7:21 PM Rob Sayre <say...@gmail.com> wrote: > 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
