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

[Eric Rescorla <[e-mail]>]

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