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

[Ted Lemon <[e-mail]>]

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