[websec] [Technical Errata Reported] RFC6797 (5204)

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 13 December 2017 21:07 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 005D1126E7A for <websec@ietfa.amsl.com>; Wed, 13 Dec 2017 13:07:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fcJfIMVa45g3 for <websec@ietfa.amsl.com>; Wed, 13 Dec 2017 13:07:28 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C99126B7E for <websec@ietf.org>; Wed, 13 Dec 2017 13:07:28 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 5BFC3B810CE; Wed, 13 Dec 2017 13:07:02 -0800 (PST)
To: Jeff.Hodges@PayPal.com, collin.jackson@sv.cmu.edu, ietf@adambarth.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, tobias.gondrom@gondrom.org, ynir.ietf@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: nick.dilssner@kirchbergerknorr.de, websec@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20171213210702.5BFC3B810CE@rfc-editor.org>
Date: Wed, 13 Dec 2017 13:07:02 -0800 (PST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/websec/zlkwQ_mh38mlG518wtNJvQKUC9g>
X-Mailman-Approved-At: Sun, 17 Dec 2017 06:04:25 -0800
Subject: [websec] [Technical Errata Reported] RFC6797 (5204)
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: Wed, 13 Dec 2017 21:07:30 -0000

The following errata report has been submitted for RFC6797,
"HTTP Strict Transport Security (HSTS)".

You may review the report below and at:

Type: Technical
Reported by: Nick Dilßner <nick.dilssner@kirchbergerknorr.de>

Section: 6.1.2

Original Text

Corrected Text



- In Section 6.1 the Strict-Transport-Security is defined as follows:

Strict-Transport-Security = "Strict-Transport-Security" ":" [ directive ]  *( ";" [ directive ] )

 - valueless Directive "includeSubDomains" is defined as a optional directive
 - a directive is definied as followed:

directive = directive-name [ "=" directive-value ]

 - so "includeSubDomains" is only a directive-name which is defined as "token"
 - according to "[RFC2616], Section 2.2" a token is any octet from 0 - 127 except CTL's (octets 0 - 31 + 127) and separators which NOT exclude '-' (octet 45)

So all Fine? Yes, BUT at [RFC6797], Section 6.1 the "overall reuqirements for directives", Rule 3 defines:

3.  Directive names are case-insensitive.

And there is no other specification in Section 6.1.2 or has a IANA policy definition [RFC5226] like it is defined for additionals.

 - That means the "directive-name" includeSubDomains is "case-insensitive"!

The "case-sensitive" camelized directive-name is misleading, because of many other definitions with "-", like seen in all examples or in Header Field itself. 

 - to aware the clear understanding the "directive definition" in section 6.1.2 and ALL occurences needs to be renamend.

the minimum of renaming is "includesubdomains" OR "INCLUDESUBDOMAINS", but this is not readable anymore.
- So it should be renamed like other valuless directives for Example the "schemes-source's" directives at "Content-Security-Policy", which means:


Best Regards


This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

RFC6797 (draft-ietf-websec-strict-transport-sec-14)
Title               : HTTP Strict Transport Security (HSTS)
Publication Date    : November 2012
Author(s)           : J. Hodges, C. Jackson, A. Barth
Category            : PROPOSED STANDARD
Source              : Web Security
Area                : Applications
Stream              : IETF
Verifying Party     : IESG