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
>>>>>>
>>>>>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
