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

From: =JeffH <[email-masked]>
Date: Sun, 25 Mar 2012 21:22:28 -0700

[ this msg is a tad late, -06 was pub'd on 12-Mar, apologies. Sending it for 
the record. ]

New rev:
https://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-06

This rev addresses issue ticket #38 (Tobias' editorial comments from:
https://www.ietf.org/mail-archive/web/websec/current/msg01076.html
)

full issue ticket list for strict-transport-sec:
<http://trac.tools.ietf.org/wg/websec/trac/query?status=assigned&status=closed&status=new&status=reopened&component=strict-transport-sec&order=id>

Redline spec diff from previous rev:
https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-websec-strict-transport-sec-06.txt

=JeffH

==============================================================

Appendix D. Change Log

    [RFCEditor: please remove this section upon publication as an RFC.]

    Changes are grouped by spec revision listed in reverse issuance
    order.

D.1. For draft-ietf-websec-strict-transport-sec

       Changes from -05 to -06:

       1.  Addressed various editorial comments provided by Tobias G.
           This addresses issue ticket #38.
           <http://trac.tools.ietf.org/wg/websec/trac/ticket/38>

       Changes from -04 to -05:
                 .
                 .
                 .
                 .
---
end

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Mar 2012 08:39:17 +0200

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/