Re: [websec] WG Last Call on draft-ietf-websec-strict-transport-sec-06 until April-9

Paul Hoffman <> Wed, 21 March 2012 01:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E19021F855B for <>; Tue, 20 Mar 2012 18:22:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.672
X-Spam-Status: No, score=-102.672 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rmu+JpaJp3lW for <>; Tue, 20 Mar 2012 18:22:01 -0700 (PDT)
Received: from (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by (Postfix) with ESMTP id 9F8B921F8559 for <>; Tue, 20 Mar 2012 18:22:01 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.5/8.14.3) with ESMTP id q2L1LvP6038123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <>; Tue, 20 Mar 2012 18:21:58 -0700 (MST) (envelope-from
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <>
X-Priority: 2 (High)
In-Reply-To: <>
Date: Tue, 20 Mar 2012 18:21:57 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: IETF WebSec WG <>
X-Mailer: Apple Mail (2.1257)
Subject: Re: [websec] WG Last Call on draft-ietf-websec-strict-transport-sec-06 until April-9
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Mar 2012 01:22:02 -0000

Greetings again. I have read the draft again, and am quite happy that this is moving forwards. Having said that, I have a list of issues that I think need to be dealt with, and a few editorial issues.

--Paul Hoffman


This document pretends that the TLSA protocol from the DANE WG will not exist. This is a tad odd, given that TLSA is likely to be published a few weeks before HSTS. In specific, bullet 2 of section 2.2 and all of section 10.2 are written as if self-signed certificates will always cause HTST-compliant browsers to fail, even if those certificates cause matching when used with TLSA.

Proposed replacements:

   2.  The UA terminates any secure transport connection attempts upon
       any and all secure transport errors or warnings, including those
       caused by a web application presenting a certificate that does
       chain to a trusted root or match a trusted certificate association
       from the TLSA protocol [I-D.draft-ietf-dane-protocol].

. . .

   If a web site/organization/enterprise is generating their own secure
   transport public-key certificates for web sites, and that
   organization's root certification authority (CA) certificate is not
   typically embedded by default in browser CA certificate stores, and
   if HSTS Policy is enabled on a site identifying itself using a self-
   signed certificate, and the certificate presented by the TLS server
   does not match a trusted certificate association from the TLSA
   protocol [I-D.draft-ietf-dane-protocol],
   then secure connections to that site will fail,
   per the HSTS design.  This is to protect against various active
   attacks, as discussed above.

   However, if said organization strongly wishes to employ self-signed
   certificates, and their own CA in concert with HSTS, they can do so
   by deploying their root CA certificate to their users' browsers.
   They can also, in addition or instead, distribute to their users'
   browsers the end-entity certificate(s) for specific hosts.  There are
   various ways in which this can be accomplished (details are out of
   scope for this specification).  Once their root CA certificate is
   installed in the browsers, they may employ HSTS Policy on their

   Alternately, that organization can deploy the TLSA protocol; all
   browsers that also use TLSA will then be able to trust the
   self-signed certificates if it announced through TLSA.

   Note:  Interactively distributing root CA certificates to users,
          e.g., via email, and having the users install them, is
          arguably training the users to be susceptible to a possible
          form of phishing attack, see Section 14.6 "Bogus Root CA
          Certificate Phish plus DNS Cache Poisoning Attack".


In section 8.1.2, I don't know what "ignoring separator characters" means, and suspect it will cause pain if left this way.

[I-D.ietf-tls-ssl-version3] is not a "work in progress". I'll take this up on the rfc-interest mailing list, and nothing needs to be done here.

RFC 2818 is listed as a normative reference, and yet it is Informational. This will need to be called out in the PROTO report. Alternately, it can be called an informative reference, since one does not need to understand it in order to implement this document.

I have alerted the idna-update mailing list of this WG LC. This might cause some helicoptered-in comments, but better now than during IETF LC.


"annunciate" (used a few times) is a fancy word for "announce". Maybe use the far more common word instead.

In section 3.1, "suboptimal downside" is unclear. Is there an optimal downside? I suggest replacing it with "negative".

The lead sentences in sections 11.2, 11.4, and 11.5 lack verbs; verbs are used in 11.1 and 11.3. This should be an easy fix.