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

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 01 February 2012 15:00 UTC

Return-Path: <alexey.melnikov@isode.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 2900111E8089 for <websec@ietfa.amsl.com>; Wed, 1 Feb 2012 07:00:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.138
X-Spam-Level:
X-Spam-Status: No, score=-102.138 tagged_above=-999 required=5 tests=[AWL=0.461, BAYES_00=-2.599, 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 upf1z8rfEehe for <websec@ietfa.amsl.com>; Wed, 1 Feb 2012 07:00:40 -0800 (PST)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 317AD11E8073 for <websec@ietf.org>; Wed, 1 Feb 2012 07:00:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1328108438; d=isode.com; s=selector; i=@isode.com; bh=/Pw0VyTYIJsLg9Ol0bmZyKAiYcX9DqCa7uRNWdbUXy8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=K6H359SBtFXa3sI93yV0tHo4BGOpNCEmhjZ3Yi8XzmhKIJOoQb10tqUijHx33jaqfJECv0 2GUP2bLoiNlPVoE8fsTrOuZHgJIqed+mAplW8geC/CFrafTZ3Q1SxXlQiKNnWw++nqXKww 4BksfclO7q8YLG7cJYoa5lgSZ7O7/Gc=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <TylTlQAvKFTQ@rufus.isode.com>; Wed, 1 Feb 2012 15:00:38 +0000
Message-ID: <4F295398.1000108@isode.com>
Date: Wed, 01 Feb 2012 15:00:40 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
To: =JeffH <Jeff.Hodges@KingsMountain.com>
References: <4F288700.3040104@KingsMountain.com>
In-Reply-To: <4F288700.3040104@KingsMountain.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: IETF WebSec WG <websec@ietf.org>
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 15:00:41 -0000

On 01/02/2012 00:27, =JeffH wrote:
> Alexey pointed out to me..
Hi Jeff,
> >
> > 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.
You have normative (RFC 2119) language about use of IDN related 
specifications in the document, IESG statement on normative/informative 
references apply: 
<http://www.ietf.org/iesg/statement/normative-informative.html>.
> Also please point out any other refs y'all think should be in the 
> Normative section but aren't.
>
> thanks,
>
> =JeffH