Yeah, that sounds fine. I think 9460 is pretty good in that it covers both DNSSEC and encrypted transports for DNS.
thanks, Rob On Sat, Mar 30, 2024 at 10:27 AM Ted Lemon <mel...@fugue.com> wrote: > I think that would make sense, yes. > > On Sat, Mar 30, 2024 at 10:58 AM Erik Nygren <erik+i...@nygren.org> wrote: > >> Do we want a few sentences in Security Considerations that references >> https://www.rfc-editor.org/rfc/rfc9460.html#section-3.1 to call this out? >> >> This seems like something that became less clear when we split these two >> docs apart. >> Most of draft-ietf-tls-svcb-ech used to be a section of what is now >> rfc9460 but got split out >> due to publication timelines. It may be that some non-normative >> references back to rfc9460 >> might help readers not miss things like this which might have been more >> clear when they >> were a single document. >> >> Erik >> >> >> >> >> On Fri, Mar 29, 2024 at 11:31 PM Ted Lemon <mel...@fugue.com> wrote: >> >>> Yes, that fully addresses my concern. Thanks! >>> >>> Op vr 29 mrt 2024 om 22:54 schreef Eric Rescorla <e...@rtfm.com> >>> >>>> >>>> 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
