[HASMAT] wrt handling TLS establishment - comment 41 bug 495115 (bugzilla.mozilla.org)

=JeffH <Jeff.Hodges@KingsMountain.com> Sat, 17 July 2010 05:19 UTC

Return-Path: <Jeff.Hodges@KingsMountain.com>
X-Original-To: hasmat@core3.amsl.com
Delivered-To: hasmat@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A49BB3A67FC for <hasmat@core3.amsl.com>; Fri, 16 Jul 2010 22:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.554
X-Spam-Level:
X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjOrThmAQjLJ for <hasmat@core3.amsl.com>; Fri, 16 Jul 2010 22:19:11 -0700 (PDT)
Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id F0ECA3A6876 for <hasmat@ietf.org>; Fri, 16 Jul 2010 22:19:10 -0700 (PDT)
Received: (qmail 6324 invoked by uid 0); 17 Jul 2010 05:19:23 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 17 Jul 2010 05:19:23 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=MmVttEg6vCemfAQGephXjyKwNw6DrNDEmn64FWs/pgIhDtoaeNR9advl5GkW6SGiAtLsW64dL3lkePWJZWsnB1NMLmSU58GUVBiw8sOgGYDYHTNUXusW7SDj7lFiePm5;
Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1OZzo2-00021M-V6; Fri, 16 Jul 2010 23:19:23 -0600
Message-ID: <4C413D59.4070304@KingsMountain.com>
Date: Fri, 16 Jul 2010 22:19:21 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Kai Engert <kaie@kuix.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com}
Cc: IETF HASMAT list <hasmat@ietf.org>
Subject: [HASMAT] wrt handling TLS establishment - comment 41 bug 495115 (bugzilla.mozilla.org)
X-BeenThere: hasmat@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: HTTP Application Security Minus Authentication and Transport <hasmat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hasmat>, <mailto:hasmat-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hasmat>
List-Post: <mailto:hasmat@ietf.org>
List-Help: <mailto:hasmat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hasmat>, <mailto:hasmat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Jul 2010 05:19:12 -0000

Adam replied:
 >
 > Kai proposed:
 >
 >> I propose to clarify section 7.3 of the STS document.
 >>
 >> It currently says:
 >>
 >>  "When connecting to a Known STS Server, the UA must terminate the
 >>  connection with no user recourse if there are any errors (e.g. certificate
 >>  errors), whether "warning" or "fatal" or any other error level, with the
 >>  underlying secure transport."
 >>
 >> I propose to add another section:
 >>
 >>  During the initial https connection to a STS server,
 >>  the server certificate verification performed by a UA happens prior to
 >>  receiving the http headers.
 >>  If a user has configured the UA to continue the connection
 >>  despite certificate errors, the UA must ignore any such configuration
 >>  as soon as the server identifies itself as a STS server.
 >>
 >> Based on comment 23 in this bug I conclude we agree on this, but I'm worried
 >> that some readers of the spec might overlook this detail.
 >
 > I'm not sure exactly what that means, but a server opting into STS
 > should trump user configuration to ignore certificate errors.  That's
 > the whole point of the protocol.  :)

agreed.


 >> Also, I'm worried that someone might be able to construct an attack based on
 >> the fact that the initial connection is not yet strict.
 >
 > That's correct.  The protocol requires a secure initialization step.
 > If an active network attacker is present during the first connection
 > to the site, there's nothing the protocol does to help the user.

Yes, and that's also why the spec mentions, and Chrome implements, a "preloaded 
STS list" <http://dev.chromium.org/sts>


 >> I propose to be more
 >> restrictive for the initial connection if it involved errors and error
 >> overrides, and propose to add this:
 >>
 >>  If an https connection to a not-yet-known-as-STS-server involves
 >>  certificate errors and a user's decision to ignore certificate errors,
 >>  and the server identifies itself as being a STS server,
 >>  then the UA MUST show an error message and
 >>  MUST NOT display the information received from the server.
 >
 > This situation is most likely to be a configuration error on the
 > server where it both has a bogus certificate and is sending the STS
 > header.  It's essential that we don't anoint the server as an STS
 > server,

The spec as currently written (-02) has this base covered in the first para of 
section "7.1. Strict-Transport-Security Response Header Field Processing"


 > but either proceeding with the connection or erroring out is
 > probably fine.

However, it is silent on this -- it presently specifies neither option in this 
particular situation.


 > I don't think there's a security reason to prefer one
 > over the other.  It's a question of what you think its a better
 > experience for users and/or developers.

I think leaving it silent in the protocol portion of the spec is fine, and that 
it's another item to add to section "10. UA Implementation Advice".

=JeffH