[websec] Question regarding RFC 6797: What is the proper reading of §8.3 #5
"Svensson, Lars" <L.Svensson@dnb.de> Thu, 01 March 2018 11:59 UTC
Return-Path: <L.Svensson@dnb.de>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538B5128D2E for <websec@ietfa.amsl.com>; Thu, 1 Mar 2018 03:59:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APUTMKee5tWj for <websec@ietfa.amsl.com>; Thu, 1 Mar 2018 03:59:29 -0800 (PST)
Received: from mail.dnb.de (mail.dnb.de [193.175.100.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07953126BF6 for <websec@ietf.org>; Thu, 1 Mar 2018 03:59:28 -0800 (PST)
Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by mail.dnb.de (Postfix) with ESMTP id 64EE64B03DFC for <websec@ietf.org>; Thu, 1 Mar 2018 12:59:26 +0100 (CET)
X-AuditID: 0a453fe7-d3dff70000000f94-9e-5a97eb1e493d
Received: from dnbf-ex.AD.DDB.DE (dnbf-ex.AD.DDB.DE [10.69.63.244]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id F4.D3.03988.E1BE79A5; Thu, 1 Mar 2018 12:59:26 +0100 (CET)
Received: from dnbf-ex.AD.DDB.DE (10.69.63.244) by dnbf-ex.AD.DDB.DE (10.69.63.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.669.32; Thu, 1 Mar 2018 12:59:25 +0100
Received: from dnbf-ex.AD.DDB.DE ([fe80::3576:7565:4f15:49c7]) by dnbf-ex.AD.DDB.DE ([fe80::3576:7565:4f15:49c7%4]) with mapi id 15.01.0669.032; Thu, 1 Mar 2018 12:59:25 +0100
From: "Svensson, Lars" <L.Svensson@dnb.de>
To: "websec@ietf.org" <websec@ietf.org>
Thread-Topic: Question regarding RFC 6797: What is the proper reading of §8.3 #5
Thread-Index: AdOxVDb2UFoi/l3sSAa/HL8Ou9xTRA==
Date: Thu, 01 Mar 2018 11:59:25 +0000
Message-ID: <84bee28e52764d75a9f15effaea8358e@dnb.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.69.208]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA12Te0hTURzHO7tXd1w7dZpTjysjlxRJrda7iIzKKDB6UBQjsGu7udGcdu9W 2oM0THLRy0TXqOhhQaOXq7DsZSvQkpIEI4xKS/JVFL2j5zlus9k/P879/M73+3vceyGnaVfq oNXuECW7YNNHqnhVasqnMUO7y03jLh9QTa0/ciJiFphfUfFdsRiYVDPMos26QZTGzlytsnR8 jMrxjs+t6XrJ5YNCowtEQYInkupdDUoXUEENvg3Ir2qvIvDwEhBXbWUwcxGQQ2XdES6ghJE4 mbyzuACEWjyS1DZsYTeicT4gxb5ynj1o8Q5AbjS/4FkFLTaQh+3eSCbgcRLZ+2I+wwhPIiXb KyPZGeAEcuFCA8fOHI4jvtdfIwLNYVJxPcAJjiGdr34HeSI5fbgJMEsOjyLnq8cGpImkdFer MmA/iNw72MbvA9GeMFfPP4UnTOEJUxwFvBcMkLMyjQbBbDCbMwxm0QcCe26/AvY0zvUDDIFe jWw1ZSZNhLBBzsvyg0VQoY9B27rKTZoBGdnmPIsgW9Ilp02U9Vo0uYNi1IsznLZ1+qHoZCrV x/VS2SnnWNdYs51yulOy+QGBHJXWV9FLyCzkbRKl7IChHwyGvD4Odd7st1KDMwWHuE4Uc0Qp lF0JoZ4gdyetOUgSM8XctVabI5SmuhONNIPDMz0NJaLLn0pNGl144v+eFDDKD9KgmjZWzvyR nCNkydbMoHc0evCKUnWI9vgmoK9s0NgQ7Ot5H2yFZw63FHHwyw0WvWdbadxe10bjk45uGi+d elPEaXh7tl3UxaE6VhYzL4vT3juVLhbVzaNFBoYlWHHdMPTAQwXxYbxv/S6wgL7MaFTAfNX0 v/o3jQZdY7B/EPYMMwSpWZ2YIPvfK41+BVp092MpW41DcISvRsmE6hANrkYxr2c1QdjXTpcP Kn+vakk2upWdJXXLJtQmTW/xxVe5Swxv06ZGPamXzh3VTvlwPP3PuYXTV2x81mQseD7nT2PC hwS3tVVn2D2a25/ue//rx6N7b3KLUxZ9+7nz1rSmqtLjk5/ui10ye2nSoVRbYlJszYjC5jPW kcXX8iq+XF1vvHPk8Wbv8OWr3M2TjqW0fdbzskUwJnOSLPwFSulYZXoEAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/websec/TuvtD1TVR6m-XEZtqjJCzcYPqe0>
Subject: [websec] Question regarding RFC 6797: What is the proper reading of §8.3 #5
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/websec/>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2018 11:59:31 -0000
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.svensson@dnb.de
http://www.dnb.de
- [websec] Question regarding RFC 6797: What is the… Svensson, Lars
- Re: [websec] Question regarding RFC 6797: What is… Yoav Nir
- Re: [websec] Question regarding RFC 6797: What is… Eric Mill
- Re: [websec] Question regarding RFC 6797: What is… Svensson, Lars