Re: [DNSOP] HSTS on receiving a signed HTTPS record (was: Questions / concerns with draft-ietf-dnsop-svcb-https ...)

[Ben Schwartz <[e-mail]>]

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=
[e-mail]> 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 <
> [e-mail]> wrote:
>
>>
>>
>> On Wed, Aug 31, 2022 at 10:43 AM Eric Orth <ericorth=
>> [e-mail]> 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 <[e-mail]>
>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>>
>>> _______________________________________________
>>> DNSOP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>