Re: [websec] [Gen-art] Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11

Ben Campbell <> Fri, 10 August 2012 14:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 622DB21F8604; Fri, 10 Aug 2012 07:19:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IqPgMkHDslNP; Fri, 10 Aug 2012 07:19:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9771121F85C3; Fri, 10 Aug 2012 07:19:16 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id q7AEGWUQ049872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Aug 2012 09:16:38 -0500 (CDT) (envelope-from
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\))
From: Ben Campbell <>
In-Reply-To: <>
Date: Fri, 10 Aug 2012 09:16:32 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Alexey Melnikov <>
X-Mailer: Apple Mail (2.1485)
X-Mailman-Approved-At: Fri, 10 Aug 2012 08:16:33 -0700
Cc: Ben Campbell <>, IETF Discussion List <>, General Area Review Team <>, IETF WebSec WG <>,
Subject: Re: [websec] [Gen-art] Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11
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: Fri, 10 Aug 2012 14:19:17 -0000

Jeff and I had a f2f discussion about this point in Vancouver. To paraphrase (and I assume he will correct me if if I mischaracterize anything), Jeff indicated that this really wasn't a MUST level requirement due to the variation and vagaries in application behavior and abilities. Rather, it's more of a "do the best you can" sort of thing. Specifically, he indicated that an implementation that chose to go ahead and serve unprotected content due to the listed caveats on redirecting to HTTPS would necessarily be out-of-compliance.

If the requirement really that you SHOULD NOT (rather than MUST NOT) serve unprotected content, then I think the original language is okay.



On Aug 9, 2012, at 6:03 PM, Alexey Melnikov <> wrote:

> On 02/08/2012 10:46, Ben Campbell wrote:
>> Hi, thanks for the response.  Comments inline:
>> On Jul 29, 2012, at 10:29 PM, =JeffH <> wrote:
> [...]
>>>> -- section 7.2:
>>>> Am I correct to assume that the server must never just serve the content over
>>>> a non-secure connection? If so, it would be helpful to mention that, maybe
>>>> even normatively.
>>> It's a SHOULD, see the Note in that section, so it's already effectively stated normatively, though one needs to understand HTTP workings to realize it in the way you stated it above.  Perhaps could add a simple statement as you suggest to the intro para for section 7 Server Processing Model, to address this concern?
>> I think something of the form SHOULD redirect to HTTPS, but MUST NOT under any circumstances send the content unprotected would improve the text.
> Sounds good to me. (And yes, this is implied, but it doesn't hurt to state explicitly.)
>> That's probably already implied, and a reasonable implementor wouldn't due it anyway. But my experience is that some readers will find strange interpretations whenever you give them the wiggle room to do so, so it's better to be explicit.
> _______________________________________________
> Gen-art mailing list