Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix)
 with ESMTP id A098A21F8646 for <ietf@ietfa.amsl.com>;
 Fri, 10 Aug 2012 03:03:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.711
X-Spam-Level: 
X-Spam-Status: No, score=-97.711 tagged_above=-999 required=5 tests=[AWL=-2.350,
 BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765,
 FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35,
 HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, 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 NXf6B2cLmEgV for
 <ietf@ietfa.amsl.com>; Fri, 10 Aug 2012 03:03:18 -0700 (PDT)
Received: from lvps176-28-13-69.dedicated.hosteurope.de
 (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com
 (Postfix) with ESMTP id A050621F8577 for <ietf@ietf.org>;
 Fri, 10 Aug 2012 03:03:17 -0700 (PDT)
Received: (qmail 20391 invoked from network); 10 Aug 2012 12:03:11 +0200
Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.65?)
 (94.194.102.93) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA
 (DHE-RSA-AES256-SHA encrypted, authenticated); 10 Aug 2012 12:03:11 +0200
Message-ID: <5024DC5E.60404@gondrom.org>
Date: Fri, 10 Aug 2012 11:03:10 +0100
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: alexey.melnikov@isode.com
Subject: Re: Gen-ART LC Review of draft-ietf-websec-strict-transport-sec-11
References: <50161BD5.7040901@KingsMountain.com>
 <344AB802-6D45-4399-A628-6852A4732C16@nostrum.com>
 <502441B7.8020001@isode.com>
In-Reply-To: <502441B7.8020001@isode.com>
Content-Type: multipart/alternative;
 boundary="------------080205060203060004010107"
Cc: ben@nostrum.com, ietf@ietf.org, gen-art@ietf.org, websec@ietf.org,
 draft-ietf-websec-strict-transport-sec.all@tools.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>,
 <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
 <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Aug 2012 10:03:18 -0000

This is a multi-part message in MIME format.
--------------080205060203060004010107
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 10/08/12 00:03, 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 <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.
>
>
<hat="individual">
Agree with Alexey and Ben. Tobias



--------------080205060203060004010107
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 10/08/12 00:03, Alexey Melnikov
      wrote:<br>
    </div>
    <blockquote cite="mid:502441B7.8020001@isode.com" type="cite">On
      02/08/2012 10:46, Ben Campbell wrote:
      <br>
      <blockquote type="cite">Hi, thanks for the response.&nbsp; Comments
        inline:
        <br>
        <br>
        On Jul 29, 2012, at 10:29 PM, =JeffH
        <a class="moz-txt-link-rfc2396E" href="mailto:Jeff.Hodges@kingsmountain.com">&lt;Jeff.Hodges@kingsmountain.com&gt;</a> wrote:
        <br>
      </blockquote>
      &nbsp;[...]
      <br>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">-- section 7.2:
            <br>
            <br>
            Am I correct to assume that the server must never just serve
            the content over
            <br>
            a non-secure connection? If so, it would be helpful to
            mention that, maybe
            <br>
            even normatively.
            <br>
          </blockquote>
          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.&nbsp;
          Perhaps could add a simple statement as you suggest to the
          intro para for section 7 Server Processing Model, to address
          this concern?
          <br>
          <br>
        </blockquote>
        I think something of the form SHOULD redirect to HTTPS, but MUST
        NOT under any circumstances send the content unprotected would
        improve the text.
        <br>
      </blockquote>
      <br>
      Sounds good to me. (And yes, this is implied, but it doesn't hurt
      to state explicitly.)
      <br>
      <br>
      <blockquote type="cite">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.
        <br>
      </blockquote>
      <br>
      <br>
    </blockquote>
    &lt;hat="individual"&gt;
    <br>
    <font face="Arial">Agree with Alexey and Ben. Tobias<br>
      <br>
    </font><br>
  </body>
</html>

--------------080205060203060004010107--
