As one of those who yammered constantly about splitting the ECH portions out of the SVCB document to move it forward, I feel some responsibility. But I think Erik's text pulled from 9460 does a good job discussing this. Is it enough text to reference the section in 9460?
tim just a DNS guy On Sat, Mar 30, 2024 at 1:47 PM Erik Nygren via dnsdir <dns...@ietf.org> wrote: > I pulled some text directly over from the 9460 security considerations > with some minor tweaks: > https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/1/files > > An attacker who can prevent SVCB resolution can deny clients any > associated security benefits. A hostile recursive resolver can always deny > service to SVCB queries, but network intermediaries can often prevent > resolution as well, even when the client and recursive resolver validate > DNSSEC and use a secure transport. These downgrade attacks can prevent a > client from being aware that "ech" is configured which would result in the > client sending the ClientHello in cleartext. To prevent downgrades, > {{Section 3.1 of !SVCB}} recommends that clients abandon the connection > attempt when such an attack is detected. > > > On Sat, Mar 30, 2024 at 1:43 PM Rob Sayre <say...@gmail.com> wrote: > >> 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 >>>>>>> >>>>>> -- > dnsdir mailing list > dns...@ietf.org > https://www.ietf.org/mailman/listinfo/dnsdir >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
