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

[Rob Sayre <[e-mail]>]

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