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

[Ted Lemon <[e-mail]>]

That seems okay. Would be good to document in the security considerations.

On Fri, Mar 29, 2024 at 4:41 PM Eric Rescorla <[e-mail]> wrote:

>
>
> On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker <
> [e-mail]> wrote:
>
>> Reviewer: Ted Lemon
>> Review result: Almost Ready
>>
>> This is a DNS Directorate review for draft-ietf-tls-svcb-ech-01.
>>
>> Section 4.1 advises disabling fallback, but does not talk about DNSSEC,
>> which
>> is surprising given that the draft proposes privacy properties for SVCB
>> responses containing ECH data. I would think that it would make sense to
>> say
>> that the SVCB querier should attempt to validate the response, and then
>> talk
>> about what to do for bogus, insecure and valid positive and negative
>> responses.
>>
>> For example, I would think that a /bogus/ response should be taken to
>> mean that
>> the SVCB record must be assumed to exist and should be treated the same
>> as if
>> the list of destinations were not reachable. An /insecure/ NXDOMAIN or
>> NODATA
>> response would not provide this assurance, and so what is currently
>> described
>> in the document makes sense for this case. A /valid/ NXDOMAIN would
>> assure that
>> no SVCB record existed, and hence ECH is not available.
>>
>> I don't think it's reasonable to specify the privacy properties of SVCB
>> and
>> /not/ talk about DNSSEC validation.
>>
>
> I could see that there might be an objection that if DNSSEC isn't working
>> at a
>> particular site because of a broken DNS resolver, this would prevent
>> connecting
>> to perfectly acceptable destinations simply because of general DNSSEC
>> breakage,
>> not a specific attack on this specific domain. The problem is that
>> there's no
>> way to distinguish this from an attack. So if this exception is allowed,
>> the
>> security considerations section should talk about what the risks are of
>> allowing it. E.g. if we succeed in validing the root and com, but can't
>> validate the zone containing the SVCB (or determine that it's not
>> signed), that
>> would be a clear indication of an attack, but if we can't validate the
>> root, it
>> could just be brokenness, and an attacker would do well to just prevent
>> all
>> validation so that we can't distinguish.
>
>
> Thanks for your comments.
>
> While I agree that SVCB being bogus deserves some consideration. I don't
> think this
> resolutions is *quite* correct. In general, TLS and HTTP don't take a
> position
> on what if any DNSSEC validation is to be done or what to do in response to
> failures.
>
> The new angle here is that there are two queries, and so it is possible
> for the
> A/AAAA queries to produce a valid response but the SVCB to produce a bogus
> one, which might be used by an attacker to disable ECH. What I would say
> here
> is that a bogus SVCB should be handled in the same way as if A/AAAA were
> bogus.
> So if you would normally fail the resolution, you should do that, but if
> you would
> normally log and move on, then you should do that.
>
> -Ekr
>
>