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

Alexey Melnikov <alexey.melnikov@isode.com> Fri, 10 August 2012 08:55 UTC

Return-Path: <alexey.melnikov@isode.com>
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 8DA4F21F841B; Fri, 10 Aug 2012 01:55:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.375
X-Spam-Level:
X-Spam-Status: No, score=-102.375 tagged_above=-999 required=5 tests=[AWL=-0.845, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, 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 ROKsW45Fovmy; Fri, 10 Aug 2012 01:55:37 -0700 (PDT)
Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id D4A7821F852C; Fri, 10 Aug 2012 01:55:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1344588934; d=isode.com; s=selector; i=@isode.com; bh=00/1+9E+AM7GqxYBAXVF+YQh/LQlEXBj8s3wxQ/OuJ8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ncGxuHp0wlue+qJqcRblnzyg4u4o351jL53HTSWq/NtO8sShNNfZnWRsqPQ2bQ1McIQWEA 9APIDlfHgo0XzhOs14XgV9ih2FtGFZDayBHPJZN9suNB8H3W7CBwqepyG03zutOipZpDgy Z4NyOgT5p1jF5tGZHBKnVxHiXIw0dwI=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <UCTMfgBvaBmt@waldorf.isode.com>; Fri, 10 Aug 2012 09:55:33 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <502441B7.8020001@isode.com>
Date: Fri, 10 Aug 2012 00:03:19 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
To: Ben Campbell <ben@nostrum.com>, =JeffH <Jeff.Hodges@kingsmountain.com>
References: <50161BD5.7040901@KingsMountain.com> <344AB802-6D45-4399-A628-6852A4732C16@nostrum.com>
In-Reply-To: <344AB802-6D45-4399-A628-6852A4732C16@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: General Area Review Team <gen-art@ietf.org>, IETF WebSec WG <websec@ietf.org>, draft-ietf-websec-strict-transport-sec.all@tools.ietf.org, IETF Discussion List <ietf@ietf.org>
Subject: Re: [websec] Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11
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: Fri, 10 Aug 2012 08:55:37 -0000

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 <Jeff.Hodges@kingsmountain.com> 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.