Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\))
Subject: Re: [Gen-art] Gen-ART LC Review of
 draft-ietf-websec-strict-transport-sec-11
From: Ben Campbell <ben@estacado.net>
In-Reply-To: <502441B7.8020001@isode.com>
Date: Fri, 10 Aug 2012 09:16:32 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <C11651CD-3713-4F2E-9026-E4D7AFF44B31@estacado.net>
References: <50161BD5.7040901@KingsMountain.com>
 <344AB802-6D45-4399-A628-6852A4732C16@nostrum.com>
 <502441B7.8020001@isode.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Cc: Ben Campbell <ben@nostrum.com>, IETF Discussion List <ietf@ietf.org>,
 General Area Review Team <gen-art@ietf.org>, IETF WebSec WG <websec@ietf.org>,
 draft-ietf-websec-strict-transport-sec.all@tools.ietf.org
Precedence: list

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.

Thanks!

Ben.

On Aug 9, 2012, at 6:03 PM, Alexey Melnikov <alexey.melnikov@isode.com> =
wrote:

> On 02/08/2012 10:46, Ben Campbell wrote:
>> Hi, thanks for the response.  Comments inline:
>>=20
>> On Jul 29, 2012, at 10:29 PM, =3DJeffH =
<Jeff.Hodges@kingsmountain.com> wrote:
> [...]
>>>> -- section 7.2:
>>>>=20
>>>> 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?
>>>=20
>> I think something of the form SHOULD redirect to HTTPS, but MUST NOT =
under any circumstances send the content unprotected would improve the =
text.
>=20
> Sounds good to me. (And yes, this is implied, but it doesn't hurt to =
state explicitly.)
>=20
>> 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.
>=20
>=20
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art