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

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