This is how I understand it:
> On 1 Mar 2018, at 13:59, Svensson, Lars <l.svens...@dnb.de> wrote:
>
> When implementing HSTS, my colleagues and I had discussions on how to
> correctly interpret §8.3, #5 of RFC 6797 [1]. In our opinion the text is
> ambiguous and we hope that you can help us to clarify what is the proper
> reading of that section. In §8.3 #5 the following is stated:
>
> [[
> If, when performing domain name matching any superdomain match
> with an asserted includeSubDomains directive is found, or, if no
> superdomain matches with asserted includeSubDomains directives
> are found and a congruent match is found (with or without an
> asserted includeSubDomains directive), then before proceeding
> with the load:
>
> The UA MUST replace the URI scheme with "https" [RFC2818], and
>
> if the URI contains an explicit port component of "80", then
> the UA MUST convert the port component to be "443", or
>
> if the URI contains an explicit port component that is not
> equal to "80", the port component value MUST be preserved;
> otherwise,
>
> if the URI does not contain an explicit port component, the UA
> MUST NOT add one.
>
> NOTE: These steps ensure that the HSTS Policy applies to HTTP
> over any TCP port of an HSTS Host.
>
> NOTE: In the case where an explicit port is provided (and to a
> lesser extent with subdomains), it is reasonably likely that
> there is actually an HTTP (i.e., non-secure) server running on
> the specified port and that an HTTPS request will thus fail
> (see item 6 in Appendix A ("Design Decision Notes")).
> ]]
>
> The question is how to interpret the "and" and "or" connections between the
> paragraphs. One possibility is to use arithmetic ordering ("and" before
> "or"), another to collect all "or" statements into one expression and then
> apply the "and". In the first case we arrive at:
>
> The UA MUST replace the URI scheme with "https" [RFC2818], and
>
> (
> if the URI contains an explicit port component of "80", then
> the UA MUST convert the port component to be "443", or
>
> if the URI contains an explicit port component that is not
> equal to "80", the port component value MUST be preserved;
> otherwise,
>
> if the URI does not contain an explicit port component, the UA
> MUST NOT add one.
> )
>
> That is, the UA _always_ has to replace the URI scheme with https and then
> will continue to handle the port component. In pseudocode this would be:
>
> If( Scheme = "http" ) {
> Replace scheme with "https"
> If ( URI contains explicit port "80" ) {
> Replace port with "443" ;
> } ElseIf( URI contains explicit port ) {
> Keep explicit port ;
> } Else {
> Do not add explicit port ;
> }
> }
>
>
> In the second case the reading would be:
>
> (
> The UA MUST replace the URI scheme with "https" [RFC2818], and
>
> if the URI contains an explicit port component of "80", then
> the UA MUST convert the port component to be "443", or
> )
>
> if the URI contains an explicit port component that is not
> equal to "80", the port component value MUST be preserved;
>
> # The otherwise starts a new scope so we repeat the first clause:
>
> otherwise,
>
> (
> The UA MUST replace the URI scheme with "https" [RFC2818], and
>
> if the URI does not contain an explicit port component, the UA
> MUST NOT add one.
> )
>
> That is, the UA must change the schema to https _only then_ when the port is
> explicitly "80" (and then convert the port to 443) or when there is no port.
>
> In pseudocode:
>
> If ( Scheme = "http" ) {
> If ( URI contains no port ) {
> Replace URI scheme with https ;
> } ElseIf ( URI contains port "80" ) {
> Replace URI scheme with "https" ;
> Replace port with "443" ;
> } Else {
> /* don't touch this, do nothing */
> }
>
> }
>
> This way it's possible to run internal http-based services (e. g. behind a
> firewall) on other ports than 80 without having to upgrade those to https.
>
> But if the UA acts like described first, then it will try to upgrade to https
> on any other port but 80, too.
> As a consequence, you then will have to offer all "real" services on other
> port with https - with the exception of a "https-bumper" on 80.
>
> [1] https://tools.ietf.org/html/rfc6797#section-8.3
>
> Thanks for any insight,
>
> Lars
>
>
> *** Lesen. Hören. Wissen. Deutsche Nationalbibliothek ***
> --
> Dr. Lars G. Svensson
> Deutsche Nationalbibliothek
> Informationsinfrastruktur
> Adickesallee 1
> 60322 Frankfurt am Main
> Telefon: +49 69 1525-1752
> Telefax: +49 69 1525-1799
> mailto:l.svens...@dnb.de
> http://www.dnb.de
>
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec
_______________________________________________
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec
