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

["Christopher Wood" <[e-mail]>]

John,

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 <[e-mail]> 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.

Best,
Chris