That seems okay. Would be good to document in the security considerations. On Fri, Mar 29, 2024 at 4:41 PM Eric Rescorla <e...@rtfm.com> wrote:
> > > On Fri, Mar 29, 2024 at 1:02 PM Ted Lemon via Datatracker < > nore...@ietf.org> 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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
