Re: [DNSOP] HSTS on receiving a signed HTTPS record (was: Questions / concerns with draft-ietf-dnsop-svcb-https ...)
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 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 > 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 >>> 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
Re: [DNSOP] HSTS on receiving a signed HTTPS record (was: Questions / concerns with draft-ietf-dnsop-svcb-https ...)
On Wed, Aug 31, 2022 at 10:43 AM Eric Orth 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 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
[DNSOP] HSTS on receiving a signed HTTPS record (was: Questions / concerns with draft-ietf-dnsop-svcb-https ...)
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
