Re: [websec] new rev: draft-ietf-websec-strict-transport-sec-06

Peter Saint-Andre <stpeter@stpeter.im> Mon, 26 March 2012 06:39 UTC

Return-Path: <stpeter@stpeter.im>
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 7FA6421F8474 for <websec@ietfa.amsl.com>; Sun, 25 Mar 2012 23:39:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0a-j2PfP8VMW for <websec@ietfa.amsl.com>; Sun, 25 Mar 2012 23:39:20 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDA221F8470 for <websec@ietf.org>; Sun, 25 Mar 2012 23:39:20 -0700 (PDT)
Received: from dhcp-1422.meeting.ietf.org (unknown [130.129.20.34]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0C4EA4005B; Mon, 26 Mar 2012 00:52:18 -0600 (MDT)
Message-ID: <4F700F15.3090508@stpeter.im>
Date: Mon, 26 Mar 2012 08:39:17 +0200
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120313 Thunderbird/11.0
MIME-Version: 1.0
To: =JeffH <Jeff.Hodges@KingsMountain.com>
References: <4F6FEF04.7050800@KingsMountain.com>
In-Reply-To: <4F6FEF04.7050800@KingsMountain.com>
X-Enigmail-Version: 1.4
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] new rev: draft-ietf-websec-strict-transport-sec-06
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 26 Mar 2012 06:39:21 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/26/12 6:22 AM, =JeffH wrote:
> [ this msg is a tad late, -06 was pub'd on 12-Mar, apologies.
> Sending it for the record. ]

Hi Jeff, thanks for addressing my earlier comments. I found time to
read -06 on the flight to Paris. Here are some small comments.

Section 1:

   This specification also incorporates notions from [JacksonBarth2008]
   in that policy is applied on an "entire-host" basis: it applies to
   all TCP ports of the issuing host.

Please make it clear that all TCP ports does not mean all application
protocols, only HTTP on all ports where it might be offered (not only
the ports registered with the IANA).

Section 7.2

Does is make sense to mention that status code 308 might be
appropriate in certain circumstances? See draft-reschke-http-status-308.

Section 8.4

The HTTP-Equiv <Meta> Element Attribute is defined in the HTML
specification, so a reference would be helpful.

Section 9

The phrase "valid Unicode-encoded string-serialized domain name" seems
a bit strange, because we don't typically refer to Unicode as an
encoding scheme. See RFC 6365 regarding such terminology.

Section 11.1

I think the text about "no user recourse" conflates two things:
showing a warning, and allowing the user to click through: "the user
should not be presented with an explanatory dialog giving her the
option to proceed." Would it be OK for a user agent to show an
explanatory dialog but not provide an option to proceed? Is there a
security reason to fail the connection without any explanation?

Section 11.5

The note it worded a bit oddly (e.g., "it shouldn't be possible for an
attacker to inject script..." might be better worded along the lines
of "implementations need to guard against alowing an attacker to
inject script...").

Peter

- --
Peter Saint-Andre
https://stpeter.im/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9wDxUACgkQNL8k5A2w/vwzMwCg0eK+344UU3yBAuKuZS6G/YwQ
M48AoLfpwOK//yp/LbKWBS2Mn0D1++F4
=VgD6
-----END PGP SIGNATURE-----