Re: [websec] Question regarding RFC 6797: What is the proper reading of §8.3 #5

"Svensson, Lars" <L.Svensson@dnb.de> Fri, 09 March 2018 12:54 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 E707112741D for <websec@ietfa.amsl.com>; Fri, 9 Mar 2018 04:54:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, HTML_MESSAGE=0.001, 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 yFnQbuvn5uTq for <websec@ietfa.amsl.com>; Fri, 9 Mar 2018 04:54:13 -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 086E2126E01 for <websec@ietf.org>; Fri, 9 Mar 2018 04:54:13 -0800 (PST)
Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by mail.dnb.de (Postfix) with ESMTP id 1761C5337AD0; Fri, 9 Mar 2018 13:54:11 +0100 (CET)
X-AuditID: 0a453fe7-d3dff70000000f94-c5-5aa283f2aded
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 69.60.03988.2F382AA5; Fri, 9 Mar 2018 13:54:10 +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; Fri, 9 Mar 2018 13:54:09 +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; Fri, 9 Mar 2018 13:54:09 +0100
From: "Svensson, Lars" <L.Svensson@dnb.de>
To: Eric Mill <eric.mill@gsa.gov>, Yoav Nir <ynir.ietf@gmail.com>
CC: "websec@ietf.org" <websec@ietf.org>
Thread-Topic: [websec] Question regarding RFC 6797: What is the proper reading of §8.3 #5
Thread-Index: AdOxVDb2UFoi/l3sSAa/HL8Ou9xTRAAG1TqAAANCBAABij4FkA==
Date: Fri, 09 Mar 2018 12:54:08 +0000
Message-ID: <afc08baa27344655bec60abd53d20cba@dnb.de>
References: <84bee28e52764d75a9f15effaea8358e@dnb.de> <94B62129-BF27-4D73-99A2-D510ED68644E@gmail.com> <CAC7uhV82ku+Ro=YCLW7iwOvfU1VE_ix29oKnf7M8dzGNMrK6NQ@mail.gmail.com>
In-Reply-To: <CAC7uhV82ku+Ro=YCLW7iwOvfU1VE_ix29oKnf7M8dzGNMrK6NQ@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.69.248]
Content-Type: multipart/related; boundary="_004_afc08baa27344655bec60abd53d20cbadnbde_"; type="multipart/alternative"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPKcWRmVeSWpSXmKPExsXC5Wr/RfdT86Iog63rNCwerF/HYnF63mJW i6XHPjA5MHvsnHWX3ePh8znMHkuW/GQKYI7isklJzcksSy3St0vgyli69gVzwYL9HBWvT59j b2D8sIiji5GDQ0LARKLjuVAXIxeHkMBBRonn266xQziPGCW2f5nF2MXICeRsZpQ411jbxcjO wSagJfE+AyQqIuAosW3deRYQm1lAXWL94o+sIK3CAhMYJe7ebWECcUQEJjJKHPm0kg2iw0ni +641TCA2i4CKxImFp8G6eQVMJX5NuQC1eD2jxMq919lBruMUCJRYODEYpIZRQFZiw4bzzBDb xCU2PfvOCmJLCIhIPLx4mg3CFpV4+fgfVFxRoq1nGxNEfaXE7e5X7BC7BCVOznzCMoFRdBaS UbOQlM1CUgYRj5WY9f8nkM0BZGtKrN+lDxFWlJjS/ZAdwtaQaJ0zlx1TXEfi97cuNpj47atT gVZxAdnLGCWOzdvBBlM0c9sNFM0LGHlXMfIV56Yb6iWm6KWkJOmlpG5ihCSC5zsY+y65HGIU 4GBU4uFNcV0YJcSaWFZcmXuI0Z+DSUmU1zdrQZQQX1J+SmVGYnFGfFFpTmqxkghvZ/SiKCFe uHBSaU62khzvfRWgqDhctLi0uCAzOTO/tDi+tCjnEKMK0EmPNqy+wCjFkpeflwo05n0NyJiU xMqq1KJ8iOGHGKU5WJTEeV/uY4gQEkhPLEnNTk0tSC2CyUZwcChJ8FoAk66QYFFqempFWmZO CUwaqO95A1BGAFkG7DhF3quXgT6RQpZAdx8TB+chRh8OHqDDrjeBHFZckJhbnJkONVuY93Q5 UJQHJgo2V5b3A8jTYjBBVDNPMc5m5Fgz90EbM8e3vSBy1dqHQLLpxBMgeewciDwBJs+AyS2P XgLJA2DyxovXIJFlb9qYhcDBJSXOuxPkKgGQVRmleXBPS4nxSqkCJfiRJEBuk1LgXdAyP0pI Ekkc1XmvGD2B8S7M2wkKTR5g+YDwrBCvcyNQkBsqCParDO87kF9FoWLoZvkAE4wI715QMPMW lySWIIdcuyo45KCi0JDrUQWHHFQQ1TipBsamBY7CLAJ36z3Fr57/6iF3eOXR2zc62VaqSPuc fnCk/LHqrHdn48W2XOpbVOAi+HK77wqTzcbsEjH+S3Nmbrhvu/PJtCuBotfCfn98NF36jXJP zaXD9jP1IkJStZ87OiW0XL8970Swdc+/G5eNDaaFhqpz61usM9/w8O+3poSEznMTk4Xkfycp sRRnJBpqMRcVJwIAQ4CUa0IFAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/websec/sHt38ze9jG0yu5PUTFPYr5MHmSQ>
Subject: Re: [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: Fri, 09 Mar 2018 12:54:17 -0000

Yoav, Eric,

Thanks for your insights.

Best,

Lars

From: Eric Mill [mailto:eric.mill@gsa.gov]
Sent: Thursday, March 01, 2018 6:45 PM
To: Yoav Nir <ynir.ietf@gmail.com>
Cc: Svensson, Lars <L.Svensson@dnb.de>; websec@ietf.org
Subject: Re: [websec] Question regarding RFC 6797: What is the proper reading of §8.3 #5

Yoav's diagram is my understanding as well.

On Thu, Mar 1, 2018 at 11:11 AM, Yoav Nir <ynir.ietf@gmail.com<mailto:ynir.ietf@gmail.com>> wrote:
This is how I understand it:
[cid:image001.png@01D3B7AE.148BDFE0]



On 1 Mar 2018, at 13:59, Svensson, Lars <L.Svensson@dnb.de<mailto:L.Svensson@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<tel:+49%2069%2015251752>
Telefax: +49 69 1525-1799<tel:+49%2069%2015251799>
mailto:l.svensson@dnb.de
http://www.dnb.de

_______________________________________________
websec mailing list
websec@ietf.org<mailto:websec@ietf.org>
https://www.ietf.org/mailman/listinfo/websec


_______________________________________________
websec mailing list
websec@ietf.org<mailto:websec@ietf.org>
https://www.ietf.org/mailman/listinfo/websec



--
Eric Mill
Senior Advisor, Technology Transformation Services
Federal Acquisition Service, GSA
eric.mill@gsa.gov<mailto:eric.mill@gsa.gov>, +1-617-314-0966