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

Yoav Nir <ynir.ietf@gmail.com> Thu, 01 March 2018 16:11 UTC

Return-Path: <ynir.ietf@gmail.com>
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 518FF12EAD8 for <websec@ietfa.amsl.com>; Thu, 1 Mar 2018 08:11:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Level:
X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 QSn5IYGQvdhE for <websec@ietfa.amsl.com>; Thu, 1 Mar 2018 08:11:23 -0800 (PST)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE2F512DA03 for <websec@ietf.org>; Thu, 1 Mar 2018 08:11:22 -0800 (PST)
Received: by mail-wm0-x231.google.com with SMTP id w128so13246348wmw.0 for <websec@ietf.org>; Thu, 01 Mar 2018 08:11:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=awXXTGO3xSoPXiLnlvJt03tdfNCLwOIdX5weU6vo054=; b=j20/GgrSoQx3YU1IRTVLmRT23gy8jEITj5vxznhloszysxDXZiu72dMPG2C6BeeroI jEJk34JQiV2/odV4uiSe0rNVrXR/jOE35HSxKNTYatYSOl34nFJYzENol0IUU89/8bip MRQFjbU4zR7YxHPX3HIItyQidxYuqKnBbkkN15DHwvvQCrNGSGVRXHFDFfJjDkK9B2u4 DJeEaTkp3Ts23tEMq/ZxajfTh+AiBxvzeEx3gSqov784MBlC17pssj5Y/nZxk812ju24 i3cMxN4HBSbtEFE/f/bN9ijq1Gc041TIQK6/D4HXFwhmWdclSO68b40xNEPQ+8v/ngiL 8KyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=awXXTGO3xSoPXiLnlvJt03tdfNCLwOIdX5weU6vo054=; b=HqvMHJO8urLt2/xWy81AQUeNNj83Ioh/s9nv2tPxRPO5qkD8rPynQxCO10xxnsBjpK 12zo6R7SDTJtogInRCm5VcEWnF2NDZQaU62F+ICIqHIaGMYjSHisedWIOGviT73OgkKc WEe6sjNPZDi0ftxpa7oZ3CXBw81s3QtKI74/stpAa/tjjJ9ycwvi+Hw6VI42s0Wr2nTu AX9+iSmlk8Vb7ppT0RV+uuUmrKAGo5R9paxlCiyoCWBpHwAUGxMI5/JTrJFSYXjPzPlM pWQTNXGYpteICOvtgz53cOzzCRKEj6IrNCgWRL67Pf5EFKhdXueYPrMi5Qsy9PNhN2fl W0nA==
X-Gm-Message-State: APf1xPBT3xfjJuoJ0T4hmJiQxRTQimxgiqEXoqlbxYnPWkis1921kalr PwAlWrsCPSDuacnEfuFbIxA=
X-Google-Smtp-Source: AG47ELu/fq0/N18XRlyUwNTFaIZVF6xC+tRWG810Uha2jJypCT75GML8i6QYoVeHi7xFx/jE/fx5/Q==
X-Received: by 10.28.191.193 with SMTP id o62mr2203310wmi.113.1519920681177; Thu, 01 Mar 2018 08:11:21 -0800 (PST)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id u63sm6653172wrc.26.2018.03.01.08.11.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Mar 2018 08:11:20 -0800 (PST)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <94B62129-BF27-4D73-99A2-D510ED68644E@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3E7F1E35-AACE-43C3-AE50-AEEA3668C218"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Thu, 01 Mar 2018 18:11:17 +0200
In-Reply-To: <84bee28e52764d75a9f15effaea8358e@dnb.de>
Cc: "websec@ietf.org" <websec@ietf.org>
To: "Svensson, Lars" <L.Svensson@dnb.de>
References: <84bee28e52764d75a9f15effaea8358e@dnb.de>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/websec/MONKJZisU792iXcvHCu9zYciXUA>
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: Thu, 01 Mar 2018 16:11:26 -0000

This is how I understand it:


> On 1 Mar 2018, at 13:59, Svensson, Lars <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
> Telefax: +49 69 1525-1799
> mailto:l.svensson@dnb.de 
> http://www.dnb.de
> 
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec