Re: [websec] Review of draft-ietf-websec-strict-transport-sec-06.txt

Peter Saint-Andre <stpeter@stpeter.im> Fri, 04 May 2012 17:00 UTC

Return-Path: <stpeter@stpeter.im>
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 6335C21F85D5 for <websec@ietfa.amsl.com>; Fri, 4 May 2012 10:00:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.532
X-Spam-Level:
X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 qfyFY33ZPD-C for <websec@ietfa.amsl.com>; Fri, 4 May 2012 10:00:23 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B68CC21F85D1 for <websec@ietf.org>; Fri, 4 May 2012 10:00:23 -0700 (PDT)
Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4EF2B40058; Fri, 4 May 2012 11:15:28 -0600 (MDT)
Message-ID: <4FA40B26.7000808@stpeter.im>
Date: Fri, 04 May 2012 11:00:22 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Alexey Melnikov <alexey.melnikov@isode.com>
References: <4FA18EF1.9040206@KingsMountain.com> <4FA2DF3B.7000506@stpeter.im> <8E815A59-6F8C-404B-B88C-E8C7CFA1CB1C@isode.com>
In-Reply-To: <8E815A59-6F8C-404B-B88C-E8C7CFA1CB1C@isode.com>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] Review of draft-ietf-websec-strict-transport-sec-06.txt
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: Fri, 04 May 2012 17:00:24 -0000

On 5/4/12 2:47 AM, Alexey Melnikov wrote:
> On 3 May 2012, at 20:40, Peter Saint-Andre <stpeter@stpeter.im> wrote:
> 
>> On 5/2/12 1:45 PM, =JeffH wrote:
>>
>>>> 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.
>>
>> Unfortunately, I think the text that Jeff produced is about the best
>> we're going to do 
> 
> We are setting ourselves up for some interop problems. We should bite the bullet and through RFC 5894 or UTS 46 out.

Jeff's point is that we already have interop problems but we need to be
realistic about the state of the browsers. From reports we've received,
some of them will be stuck on IDNA2003 for a long time...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/