I believe the proposed change here is moot. The point of the current "MUST NOT" is just a reminder that this logic does not require doing anything unsafe. A DNSSEC signature on the HTTPS record would not enable any substantial improvements to the pseudo-HSTS upgrade.
Also, HTTP specifications generally do not rely on DNSSEC. If there is appetite for exploring possible enhancements to HTTP that rely on DNSSEC, I think this would be better addressed in a general "DNSSEC-Enhanced HTTP" document. (However, I think it would not be wise to publish such a document until such time as end-to-end DNSSEC is reasonably prevalent in the HTTP ecosystem.) On Wed, Aug 31, 2022 at 6:40 PM Eric Orth <ericorth= 40google....@dmarc.ietf.org> wrote: > Does any HTTP client not follow 307 redirects if received over cleartext? > This feels to me like a purely theoretical situation. I'm not opposed to a > bis making the trust in the HSTS feature be treated more similarly to > receiving the 307 over HTTPS when DNS is protected, but I also wouldn't > consider this important enough on its own to adopt a bis. > > On Wed, Aug 31, 2022 at 6:22 PM Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > >> >> >> 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 >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
