Re: [websec] IETF WebSec WG <websec@ietf.org>
=JeffH <Jeff.Hodges@KingsMountain.com> Wed, 02 May 2012 18:56 UTC
Return-Path: <Jeff.Hodges@KingsMountain.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 3AB0221F84CF for <websec@ietfa.amsl.com>; Wed, 2 May 2012 11:56:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.495
X-Spam-Level:
X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=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 F1CcKkg8lPdX for <websec@ietfa.amsl.com>; Wed, 2 May 2012 11:56:12 -0700 (PDT)
Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 4566C21F847E for <websec@ietf.org>; Wed, 2 May 2012 11:56:12 -0700 (PDT)
Received: (qmail 16424 invoked by uid 0); 2 May 2012 18:56:11 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 2 May 2012 18:56:11 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=ltgPC35izhlhtMgU9ijW6S6xJxPSop/ZVQE6dEM2O8U=; b=TXCYzJgA6W1RFxdzc1gsEGWgBab2qryylS6KPXw+xRD9wJjUh7kUufB2tRMn+7K+UzagJUlW1xXP8NbX4/WGQlADDmULKxElGuikwTMMHOnu4n9GDourQqEFxszRm9PL;
Received: from [205.248.100.252] (helo=[10.69.6.184]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1SPeih-0007uN-8U; Wed, 02 May 2012 12:56:11 -0600
Message-ID: <4FA18343.2050901@KingsMountain.com>
Date: Wed, 02 May 2012 11:56:03 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: Alexey Melnikov <alexey.melnikov@isode.com>, IETF WebSec WG <websec@ietf.org>
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 205.248.100.252 authed with jeff.hodges+kingsmountain.com}
Subject: Re: [websec] IETF WebSec WG <websec@ietf.org>
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: Wed, 02 May 2012 18:56:13 -0000
Hi Alexey, thanks for the review, apologies for latency. > The two directives defined in this specification are described below. > The overall requirements for directives are: > > o The order of appearance of directives is not significant. > > o All directives MUST appear only once in an STS header field. > > o Directive names are case-insensitive. > > o UAs MUST ignore any STS header fields containing directives that > do not conform to their ABNF definition. > > Should this list also say something about how unrecognized directives > should be treated? I.e. are they ignored by default, is the whole > STS header field ignored, etc. Does the last bullet item above not address those questions? > Additional directives extending the semantic functionality of the STS > header field may be defined in other specifications (which "update" > this specification), > > Is this a requirement on future extensions? > (In general "updating" this specification using Updates: in the header > of the relevant RFC > is a) a heavy weight mechanism (it prevents Experimental extensions) and > b) this seems > like a wrong mechanism anyway, as Updates usually means that the > document being > updated can't be implemented without the document which updates it.) We can place in the above para whatever we/you/ourADs wish. Suggestions welcome. > 8.3. Errors in Secure Transport Establishment > > When connecting to a Known HSTS Host, the UA MUST terminate the > connection (see also Section 11 "User Agent Implementation Advice", > below) if there are any errors (e.g., certificate errors), whether > "warning" or "fatal" or any other error level, with the underlying > secure transport. This includes any issues with certificate > revocation checking whether via the Certificate Revocation List (CRL) > [RFC5280], or via the Online Certificate Status Protocol (OCSP) > [RFC2560]. > > This was discussed in Paris, but I had this in my notes already and would > like to emphasize this: I assume that explaining the reason for the failure > to the user (without letting the user to opt-out) is Ok? I think the > document > needs to make it clear that this is not prohibited. the above is being discussed in the "Showing errors in HSTS" thread. > 10.3. Implications of includeSubDomains > > For example, certification authorities often offer their CRL > distribution and OCSP services over plain HTTP, and sometimes at a > > The first use of OCSP needs an Informative reference. It's referenced way up at beginning of spec, but now ref'd here also in my -07 working copy. > subdomain of a publicly-available web application which may be > secured by TLS/SSL. For example, <https://example-ca.com/> is a > publicly-available web application for "Example CA", a certification > authority. Customers use this web application to register their > public keys and obtain certificates. Example CA generates > certificates for customers containing > <http://crl-and-ocsp.example-ca.com/> as the value for the "CRL > Distribution Points" and "Authority Information Access:OCSP" > certificate fields. > > 13. Internationalized Domain Names for Applications (IDNA): Dependency > and Migration > > IDNA2008 obsoletes IDNA2003, but there are differences between the > two specifications, and thus there can be differences in processing > (e.g., converting) domain name labels that have been registered under > one from those registered under the other. There will be a > transition period of some time during which IDNA2003-based domain > name labels will exist in the wild. User agents SHOULD implement > IDNA2008 [RFC5890] and MAY implement [RFC5895] (see also Section 7 of > [RFC5894]) or [UTS46] in order to facilitate their IDNA transition. > > I might be kicking a dead horse here, but MAY sounds a bit weak. > I especially dislike having the choice between 2 incompatible specs, > I think this might cause some interop problems. As far as I can tell, having had fairly extensive discussions with IDNA folk both privately and on various lists such as idna-update@, the above relects the the unfortunate state of the world at this time. For instance, Pete Resnick signed off on the language in the spec in this message to websec@... Re: [websec] wrt IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec https://www.ietf.org/mail-archive/web/websec/current/msg01015.html we should probably fork off any further discussion on this topic to that thread. > Also, does "in order to facilitate their IDNA transition" apply > to the second reference or to both references? It applies to both. One may implement [RFC5895] /or/ [UTS46] to facilitate one's IDNA transition (as I understand it). again, followups on this item and the above should probably be in the "Re: [websec] wrt IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec" thread here on websec@. > In Section 14.5: NTP needs an Informative Reference. fixed in my -07 working copy. > 15. IANA Considerations > > Below is the Internet Assigned Numbers Authority (IANA) Provisional > > I think here (and below) we should use "Permanent" registration for this > header field. > > Message Header Field registration information per [RFC3864]. > > Header field name: Strict-Transport-Security > Applicable protocol: HTTP > Status: provisional > Author/Change controller: TBD > Specification document(s): this one fixed in my -07 working copy thanks again, =JeffH