On Wed, Aug 31, 2022 at 10:43 AM Eric Orth <ericorth= 40google....@dmarc.ietf.org> wrote:
> I'm not sure what exactly is being changed or clarified with this > suggestion. Section 9.5 already applies at SHOULD-level, whether > cryptographically protected or not and whether the received records were > AliasMode or ServiceMode. > The text in 9.5 has some language that is actually NOT at the SHOULD level: Because HTTPS RRs are received over an often- insecure channel (DNS), clients MUST NOT place any more trust in this signal than if they had received a 307 (Temporary Redirect) response over cleartext HTTP. That's what the suggestion is making an effort to strengthen, under specific conditions (e.g. cryptographically protected HTTPS records received). The current 9.5 text quoted above, is placing MUST NOT guidance, independent of whether the records were cryptographically protected. I'm thinking it would be better to fix the quoted language above, in a -bis document, if the suggested text isn't acceptable as an update to the about-to-be-published draft. The logic used to reach that MUST NOT is suspect, IMHO. The main non-requirements on DNSSEC (i.e. that HTTPS does not require it) are then turned into an "assume all DNS responses are not cryptographically protected" inferentially. It would be better guidance to instruct clients to use appropriate levels of trust, on signed vs unsigned DNS, and/or DNS received over encrypted transports. I also think the guidance would be more precise if the encrypted transport were not lumped together with the signed content. Also something for a potential -bis or best practice document. Brian > On Wed, Aug 31, 2022 at 5:43 AM Martin Thomson <m...@lowentropy.net> wrote: > >> On Wed, Aug 31, 2022, at 18:39, Brian Dickson wrote: >> > One additional suggested addition to the end of section 3.1 is: >> >> If DNS responses are cryptographically protected, and at least >> >> one HTTPS AliasMode record has been received successfully, >> >> clients MAY apply Section 9.5 (HSTS equivalent) restrictions >> >> even when reverting to non-SVCB connection modes. Clients >> >> also MAY treat resolution or connection failures subsequent >> >> to the initial cryptographically protected AliasMode record >> >> as fatal. >> > [Brian's note: this last would provide some guidance to implementers of >> > clients: a signed HTTPS AliasMode record is a strong signal that the >> > DNS operator is discouraging fallback, albeit at a "MAY" level.] >> > >> > NB: The 2.4.3 change could be removed as it is mostly independent, as >> > could the last addition to 3.1. >> > The 1.2 change is very minor, is not too important but presents a >> > succinct clarification on the hostname vs domain name thing. >> > The 2.4.2 change and section 3 changes together are fixes for the >> > prefix/no-prefix issue (which was basically a scrivener's error, and >> > does not change the semantics at all.) They should stay or go as one >> > unit. >> >> I somewhat like this change, but I would generalize to receiving any >> signed HTTPS record during resolution, rather than limiting it to AliasMode. >> >> That said, it is somewhat gratuitous. I'd want it standardized if that >> was what was expected, but I'd prefer to defer that to an >> extension/follow-up. >> >> (In case you hadn't guessed, I tend to agree with those arguing for no >> change to the spec.) >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
