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

[Ted Lemon <[e-mail]>]

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
>>>>
>>>