On Fri, Aug 26, 2022 at 4:29 AM Ben Schwartz <bemasc= 40google....@dmarc.ietf.org> wrote:
> > > On Thu, Aug 25, 2022 at 7:19 PM Viktor Dukhovni <ietf-d...@dukhovni.org> > wrote: > >> On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote: >> > Indeed it is a possible position to say that the Internet is not yet >> ready for semantically distinct services seen by SVCB-aware and legacy >> clients. > > > In addition to the deployment concerns I've mentioned earlier, a > deployment of this kind would be intrinsically insecure: a hostile > intermediary could override the choice of which semantically distinct > service is seen by the client. That's another reason why this > configuration is not permitted. > I don't think it is the case that it is not permitted. Note that many/most of the cases in 3.1 do not account for one specific permutation: - An apex AliasMode HTTPS record, with no prior or subsequent CNAMEs, and no subsequent AliasMode records, in a DNSSEC signed zone, which also has apex A/AAAA records. All the records in the zone are signed. - It is literally impossible for a hostile intermediary to selectively block service, without the client having the ability to detect this (if the client is doing DNSSEC validation itself, or if the client is asking the upstream DNS resolver to do DNSSEC validation and return data with the AD bit set). - If the client detects any failure (including SERVFAIL), and the Chain length is 1, and the DNS lookups are cryptographically protected, the client MUST hard-fail (per the current spec). This particular case appears to me (and I'd argue is also proveably) intrinsically secure. NB: When GoDaddy begins publishing HTTPS records in customer-managed DNS zones, it will do so only with DNSSEC signed zones, using AliasMode records with Chain length of 1, with or without apex A/AAAA records (mostly likely with). (The intent of making DNSSEC widely available has previously been discussed, so this isn't really news per se, except in the context of HTTPS and section 3.1) Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
