Re: [dnsdir] [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01

[Tim Wicinski <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]> 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 <[e-mail]> wrote:
>>
>>> I think that would make sense, yes.
>>>
>>> On Sat, Mar 30, 2024 at 10:58 AM Erik Nygren <[e-mail]>
>>> 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 <[e-mail]> wrote:
>>>>
>>>>> Yes, that fully addresses my concern. Thanks!
>>>>>
>>>>> Op vr 29 mrt 2024 om 22:54 schreef Eric Rescorla <[e-mail]>
>>>>>
>>>>>>
>>>>>> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>>>>>>>> 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 <[e-mail]>
>>>>>>>>>> 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 <[e-mail]>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker <
>>>>>>>>>>>> [e-mail]> 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
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>>>>
>>>>>> --
> dnsdir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsdir
>