Re: [HASMAT] wrt port numbers - comment 51 bug 495115 (bugzilla.mozilla.org)

=JeffH <Jeff.Hodges@KingsMountain.com> Sat, 17 July 2010 01:53 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 16EF73A6765 for <hasmat@core3.amsl.com>; Fri, 16 Jul 2010 18:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.501
X-Spam-Level:
X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 g6jq1VFDrbak for <hasmat@core3.amsl.com>; Fri, 16 Jul 2010 18:53:39 -0700 (PDT)
Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 870663A6407 for <hasmat@ietf.org>; Fri, 16 Jul 2010 18:53:39 -0700 (PDT)
Received: (qmail 4519 invoked by uid 0); 17 Jul 2010 01:53:51 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 17 Jul 2010 01:53:51 -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=Hm+yCg01yy8DZKuLzZAOXKOXyg9Iq1VqxAMPIZ6SX+zi13HI1Qgud/PSoe5Kj0Wi647V1BdaVAJbwoIn+8AR/cHefvFhzfQobpnzEZ7Xfwd1C1e9pzZPK771w9p5WrV4;
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 1OZwb9-0004Mi-CH; Fri, 16 Jul 2010 19:53:51 -0600
Message-ID: <4C410D2D.9070001@KingsMountain.com>
Date: Fri, 16 Jul 2010 18:53:49 -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: Re: [HASMAT] wrt port numbers - comment 51 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 01:53:41 -0000

Adam wrote:
 >
 > Another way of thinking about the situation is as follows:
 >
 > 1) An STS server is promising never to use HTTP or send broken certificates.
 >
 > 2) If we're trying to issue an HTTP request to example.com:8080, then
 > that's not what example.com wants and we shouldn't do it.

Adam's of course correct here.

Though, to pedantically fill in some of the blanks...

1) An HSTS server is promising never to use HTTP over insecure transport or to 
send a broken certificate (or fail to establish the secure connection without 
errors for whatever reason).

2. If we're trying to issue an HTTP request over insecure transport to 
example.com:8080, when we've previously established (by legit means) that /that 
host is an HSTS Server/, then that is not what example.com wants and we 
shouldn't do it.


 > With respect to port numbers, I think that's not well covered in the spec.

I agree, will try to rectify this in -03.


 > The way it works in chrome is that the STS state is for the whole host (this
 > is important to protect secure cookies, which are shared by the whole host).

Another way to say it is that the notion of a HSTS Server maps to a DNS Domain 
(aka host) name, regardless of port.


 >  For the redirect behavior: port numbers are preserved except port 80 is
 > changed to port 443 because 80 is the default port for http.

Hm, I wonder if that should be in the spec (I'm thinking yes offhand). It 
presently isn't and thus is perhaps a impl characteristic of Chrome only.


=JeffH