Re: [websec] #36: HSTS: fixup references

=JeffH <Jeff.Hodges@KingsMountain.com> Wed, 01 February 2012 00:27 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 8041C11E8096 for <websec@ietfa.amsl.com>; Tue, 31 Jan 2012 16:27:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.226
X-Spam-Level:
X-Spam-Status: No, score=-100.226 tagged_above=-999 required=5 tests=[AWL=0.269, 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 6dVYcrfpfgCD for <websec@ietfa.amsl.com>; Tue, 31 Jan 2012 16:27:42 -0800 (PST)
Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id D1E6A11E8095 for <websec@ietf.org>; Tue, 31 Jan 2012 16:27:42 -0800 (PST)
Received: (qmail 19008 invoked by uid 0); 1 Feb 2012 00:27:42 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 1 Feb 2012 00:27:42 -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=GfjOBYOaA7MdA9hjwa42alVy8k380ThlO6IenT9kULI=; b=qvnR1LfZSGY/Y4zrq3EfNCzynZa3E9sOxUEky82M7LAC3zo9tKprYI9u1Vh1bM3ZCFbANhxntXmpnTsvQfRK71pbMP5qqaKL3uWW3YEhR5O2gRJ7XWR/9H8mihH53qxc;
Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.48]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1RsO33-0003WA-Kg for websec@ietf.org; Tue, 31 Jan 2012 17:27:41 -0700
Message-ID: <4F288700.3040104@KingsMountain.com>
Date: Tue, 31 Jan 2012 16:27:44 -0800
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16
MIME-Version: 1.0
To: 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 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Subject: Re: [websec] #36: HSTS: fixup references
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, 01 Feb 2012 00:27:43 -0000

Alexey pointed out to me..
 >
 > BTW, you moved lots of references to Informational (e.g. all IDNA
 > related), I think this is incorrect - their understanding is required in
 > order to implement HSTS correctly.

So, yes, I did (ruthlessly) move a ton of references to Informational. I wanted 
to pare down the Normative references to the absolutely necessary ones.

Wrt IDNA refs, I'm happy to move them back to Normative if that's what folks 
think. Note that in typical implementations, all the IDN normalizations have 
occurred before getting to the actual HSTS implementation. there's this text in 
Section 8. User Agent Processing Model...

    This processing model assumes that the UA implements IDNA2008
    [RFC5890], or possibly IDNA2003 [RFC3490], as noted in Section 13
    "Internationalized Domain Names for Applications (IDNA): Dependency
    and Migration".  It also assumes that all domain names manipulated in
    this specification's context are already IDNA-canonicalized as
    outlined in Section 9 "Domain Name IDNA-Canonicalization" prior to
    the processing specified in this section.

    The above assumptions mean that this processing model also
    specifically assumes that appropriate IDNA and Unicode validations
    and character list testing have occurred on the domain names, in
    conjunction with their IDNA-canonicalization, prior to the processing
    specified in this section.  See the IDNA-specific security
    considerations in Section 14.8 "Internationalized Domain Names" for
    rationale and further details.

So, if folks indeed wish IDN refs to be Normative, I'll move 'em back.

Also please point out any other refs y'all think should be in the Normative 
section but aren't.

thanks,

=JeffH