Re: [secdir] Secdir last call review of draft-klensin-idna-unicode-review-03

"Christopher Wood" <> Thu, 12 September 2019 02:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F6401200B7; Wed, 11 Sep 2019 19:10:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=Uw6CaxDv; dkim=pass (2048-bit key) header.b=XYMexm8w
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 17UpnYoMd0zc; Wed, 11 Sep 2019 19:10:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 72CDC120013; Wed, 11 Sep 2019 19:10:03 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id C548322535; Wed, 11 Sep 2019 22:10:02 -0400 (EDT)
Received: from imap4 ([]) by compute6.internal (MEProxy); Wed, 11 Sep 2019 22:10:02 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm2; bh=vt DHPrXZ8QiqEbORIDCV6CnjD7wgcVLoSk09nQqz4Gs=; b=Uw6CaxDvqNqhC/WKHO fLvysxWyjBldbRyCDu/VVsU6ctaF7/fHLjwVG9NRg9NekJ6K76o4SgXYmNuImbAR +jGgbHgll5rPek+MDvllIO168FBKUyJi9Wdq7cuEgDobg9YEOi7cdEZX9uDoPeGl kcbvx98GEkZe8iKpIkHxSi0l3mkEPaQ9oxkXkyr9V2pSBw7Hw8TpIUOBitQRjD1G nI8jSkfSL3sd5IOeUAfQ3C4NXBbxC+RRl7IB8ajUycN7rmc/y7pD+GTDd2WpgyTd X2jNiB0+wyqkeee0LR5bMdphDCLzR9CSJWTlp4Xg+rU29WP4Ed5xDF6JlvJ29VyB V0LQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=vtDHPrXZ8QiqEbORIDCV6CnjD7wgcVLoSk09nQqz4 Gs=; b=XYMexm8wLTMpHV29id2HbP4lZTJx2f5MAS4QEX+wBtGlOLtWuBGc5T4l2 Ssw388P93UvE706ubKaPLDOZefuMLwrP3eI3fKNxJ8a0KEnNjMHtTDB4ypExqkRt maHRsGhH2jgfRIJq1MlH01ivm1KSf6o7wlM/te+DJiK45RSzqhkDuOhSP8+J4P2O z2JnfK6xUQIiKZX9/yxfQpYu4xh+K+a0X1wW8364wXG4GIxCxJgKMaALxLGOovHj kzPtvTtSewmdqqClfedMlc4auX9syONY9kQlAli5suNIrp+rD4ShzarLidjOyqFy 3PQ7Lmqeb1twPW3s04bj66cuciU/A==
X-ME-Sender: <xms:-qh5XYE1BXamLM4js845xK-hP-Y7NF6PMhCyyi_FfuBimaN6bwsL7w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrtdeggdehiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomheptg grfieshhgvrghpihhnghgsihhtshdrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:-qh5XSG3qGB8j6KTZn0tyVMMqeeD4fYVGiEHDu6Mg06qpGIQJ0v_gw> <xmx:-qh5XbDOjlrq9-nxxLxUB5ey1HV6oCF2LqX2pYqkDu5b9MmSob_4LA> <xmx:-qh5XR-3XkxOmAWdwBllJhk_-IaVJFcnQAvZLbWuVt4X12VFpgnjjg> <xmx:-qh5Xf_-swCrlgWiTtnHJ0SJeuJsWy2Wa-Z2ExTRLM-hnOPiY-zx8A>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7940E3C00A1; Wed, 11 Sep 2019 22:10:02 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-227-g18586b54-fmstable-20190911v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <645388ABB5D92E33447C55DF@PSB>
References: <> <645388ABB5D92E33447C55DF@PSB>
Date: Wed, 11 Sep 2019 19:09:42 -0700
From: "Christopher Wood" <>
To: "John C Klensin" <>
Cc: "" <>,,
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [secdir] Secdir last call review of draft-klensin-idna-unicode-review-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Sep 2019 02:10:06 -0000


On Wed, Sep 11, 2019, at 3:07 PM, John C Klensin wrote:
> Christopher,
> This has already been discussed in the context of another review
> but, the tracker showed the review as being due by August 30,
> the same date as Last Call closed, until yesterday.  It is
> important that area reviews appear within the Last Call period
> so that others in the community can comment on them.  Late
> reviews, especially ones that arrive after the IESG evaluation
> period starts, are also a bit disrespectful of authors who
> struggle to get complete documents posted immediately after IETF
> Last Call and before the IESG evaluation period begins so as to
> have documents that are as complete as possible before ADs start
> their reviews and of those ADs who might have done so.

Understood. Things happen. I figured a late review was better than none. 

> That said....
> --On Tuesday, September 10, 2019 18:41 -0700 Christopher Wood
> via Datatracker <> wrote:
> > Reviewer: Christopher Wood
> > Review result: Has Nits
> > 
> > This document looks mostly good to go. I only have a few
> > questions and some various editorial nits.
> > 
> > Questions:
> > - Section 4, last paragraph: Will code points "considered
> > unsafe" be labelled as such, and if so, where? In the derived
> > property IANA tables? (Assuming those tables are kept.) -
> The document should be clear on this.  In particular, the last
> sentence of Section 3.2, which, AFAICT, is the first comment in
> it about "considered unsafe", says
> 	'The affected code points should be considered unsafe
> 	and identified as "under review" in the IANA tables
> 	until final derived properties are assigned.'

My point was that "considered unsafe" is not necessarily the same as "under review." One can read the latter and conclude the thing is safe, for example.

> That seems very clear to me unless you think the document should
> say "... identified as 'unsafe and under review' in the IANA
> tables..." or something similar.  That, to me, is a tradeoff
> against tediousness and against the fairly clear language in the
> base IDNA specifications, as well as language in
> draft-klensin-idna-5891bis (in Last Call and IESG evaluation
> current with this document) that spell out what a zone is
> allowed to do with code points that IDNA considers PVALID.  

A tradeoff indeed! I was merely calling out the possible confusion.

> The intent is to give a registry a clear warning that the status of
> a code point might change as reviews continue.   If there were
> community consensus that the issue should be described in more
> detail in this document, I assume we would happily change it.
> But, because this issue did not come up during IETF Last Call,
> there is no time for such a discussion and, IMO, a presumption
> that the text is ok.
> > Section 5, second paragraph: How will the success of this
> > document's proposed changes be measured in order to determine
> > if further steps towards minimizing confusion are needed?
> First of all, the nature of human languages and writing systems
> and their evolution is such that, as characters other than those
> from very simple scripts designed for easy recognition (e.g.,
> Roman script as used in the early Roman Republic) are allowed in
> identifiers (including domain name labels), aspirations for zero
> confusion are up there with aspirations for perfect security
> that cannot be broken by any mechanism now or in the future.
> That makes "good enough" subjective, circumstantial, and, to
> some extent, dependent on the dedication of the attackers and
> resources available to them.    But this paragraph is not about
> that.  It is about the observation that publishing non-normative
> tables with IANA, rather than telling people what the rules and
> algorithms are and expected them to do their own computation or
> relying on tables that are not an IETF responsibility,  has
> resulted in a good deal of confusion (and some complaints) about
> what the true and correct values are.  If those complaints now
> stop, we are successful.  If they continue, then we conclude the
> that IANA tables are a bad idea on balance and we drop them.  It
> occurs to me that your comment about "unsafe and under review"
> and the discussion above suggest that, if we decided to get rid
> of the IANA tables in their current form, we'd need to find a
> place to publish that information.  But let's cross that bridge
> when and if we get to it.

Sure. My underlying point was that use of the word "measure" is not really actionable. 

> > Nits:
> > - Section 2, first paragraph, first sentence: It seems a comma
> > is missing after [RFC3491] reference, i.e., "..., commonly
> > known as "IDNA2003" [RFC3490] [RFC3491], ...".
> Correct.  Working draft fixed.  Thanks although I'm confident
> the RFC Editor would have caught this. 
> > - Section 3,
> > second paragraph: s/full Unicode versions/major Unicode
> > versions?
> IIR, "full Unicode versions" is Unicode's preferred terminology.
> We should check this.
>  - Section 3.1: s/also concluded that maintain
> > Unicode/also concluded that Unicode?
> Yes.  Cut and paste error as that sentence was rewritten several
> times.  Fixed in working draft.
> > - Section 4, third
> > paragraph: Is the requirement that changes which are
> > "documented" redundant with the following "explained"
> > requirement? (That is, perhaps just say "... must be
> > documented and explained."
> It is actually not redundant although I understand why you might
> read it that way.  Explanation on request if you or some AD
> think it is important.
> > - Security Considerations, second
> > paragraph: Do "end users" include systems that process or
> > interpret Unicode values? If not, it might help to specifically
> > call them out, as problems may arise from misinterpretation
> > there.
> They do not.  "End user" refers to human beings and, perhaps
> eventually, robots who are using the Internet as surrogates for
> human beings.  One of the design goals of IDNA2008 (successfully
> realized) was to create a situation in which there simply are no
> ambiguities in Unicode strings as they pass through the
> protocol.  As an overused example, as far as computer systems
> processing or interpreting values are concerned, Latin small "a"
> (U+0061) is quite distinct from Cyrillic small "а" (U+0430) in
> all relevant encoding forms including what happens when those
> code points are passed through the Punycode algorithm.   The
> problem occurs only when those characters are displayed to
> humans and they can't tell the difference.  Hence end users.  
> Processes that try to figure out what a human might confuse are
> a different story, but they, necessarily, operate off
> assumptions about the graphemes associated with particular code
> points and not the code points themselves.  Hence they are just
> not relevant to this document.

I don't agree that they're irrelevant, though that's my humble opinion.