Hi Ted, Doesn't this section of RFC 9460 address this case and say what you are recommending:
https://www.rfc-editor.org/rfc/rfc9460.html#section-3.1 -Ekr On Fri, Mar 29, 2024 at 6:49 PM Ted Lemon <mel...@fugue.com> wrote: > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
