Subject: [secdir] Secdir last call review of draft-klensin-idna-rfc5891bis-05

From: Paul Wouters via Datatracker <[email-masked]>
Date: Mon, 02 Sep 2019 19:58:49 -0700

Reviewer: Paul Wouters
Review result: Has Nits

I have reviewed this document as part of the security directorate's  ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat  these comments just like any
other last call comments.

This document collects IDNA  information from Errata's, external information
such as ICANN, and some wisdom gathered since RFC 5891 was published and
presents this set of information for operations of domains to make their
domains more secure with respect to IDNA and its (ab)use.

The Security Section is a clear summary that states the operators should really
heed the advise of this document (and the documents references and updated)

Issue:

It seems the document asks for the IANA Consideration section to be removed.
Instead, it should keep the Section but use the text along the lines of  " This
document has no IANA actions.". This helps people who are looking through
various RFC's to find IANA considerations.

Minor issues:

I find the term "For-profit domain" very confusing as .pizza is a very much for
profit domain. Normally, the terms "Generic domain" and "Brand domain" although
I guess the latter is usually avoided in written text. While the term is
described to mean a Generic Domain, I think it would be better to use Generic
domain instead of For-profit domain.

  Registries choosing to make exceptions -- allow code points that
  recommendations such as the MSR do not allow -- should make such
  decisions only with great care and only if they have considerable
  understanding of, and great confidence in, their appropriateness.

This paragraph seems really to say "Registries SHOULD NOT make exceptions" and
seems a good place for some RFC 2119 wording.

I find the term "registry" in this document confusing, as it could refer to an
"IANA registry", "script registry" or  "domain registry". Perhaps always spell
this out to make the context clearer?  Or alternatively, perhaps introduce the
term Registry (with captial R)  and use that to refer to domain registries.

[ID.draft-klensin-idna-unicode-review] is in progress.  Its status
   should be checked in conjunction with application of the present
   specification.

I think this is meant as informational to the RFC Editor ? Perhaps these
documents should go out as a cluster?

Note I find some documents are references within [square brackets] but not all
of them, even some RFC's are in brackets and others are not. Please make this
consistent.

      The algorithm and rules of RFCs 5891 and 5892

missing xref's to the RFCs?

     registries SHOULD normally consult

Either use "SHOULD" or "normally", not both? It's a little odd.

   to fully satisfy the mandate set out above

Instead of mandate, which is a bit generic and confusing, why not refer to the
mentioned "IAB guidance", which I think it is referring to ?

    may provide useful guidance.

Remove the word "may"

---

From: John C Klensin <[email-masked]>
Date: Tue, 03 Sep 2019 17:47:23 -0400

Paul,

Noting the arrival of this review 4 1/2 days after the IETF Last
Call nominally closed, and copying the IESG rather than the IETF
list as a result...  I also would have tried to write a shorter
and less complete response had there been a week or so for any
remaining issues or lack or clarify to be the subject of
additional discussion.

--On Monday, September 2, 2019 19:58 -0700 Paul Wouters via
Datatracker <[email-masked]> wrote:

> Reviewer: Paul Wouters
> Review result: Has Nits
> 
> I have reviewed this document as part of the security
> directorate's  ongoing effort to review all IETF documents
> being processed by the IESG.  These comments were written
> primarily for the benefit of the security area directors.
>  Document editors and WG chairs should treat  these comments
> just like any other last call comments.
> 
> This document collects IDNA  information from Errata's,
> external information such as ICANN, and some wisdom gathered
> since RFC 5891 was published and presents this set of
> information for operations of domains to make their domains
> more secure with respect to IDNA and its (ab)use.
> 
> The Security Section is a clear summary that states the
> operators should really heed the advise of this document (and
> the documents references and updated)
> 
> Issue:
> 
> It seems the document asks for the IANA Consideration section
> to be removed. Instead, it should keep the Section but use the
> text along the lines of  " This document has no IANA
> actions.". This helps people who are looking through various
> RFC's to find IANA considerations.

Until and unless the rules are changed to require IANA
Considerations sections in all IETF Stream documents, this is a
judgment call.  Your preference is noted but at least this
author believes that the omission of an essentially trivial
statement is more helpful to many users then including it and
keeps documents shorter.  I note that we have several section
titles, including one for Internationalization, that are
routinely omitted if the document has nothing to say that would
call for such a section.

> Minor issues:
> 
> I find the term "For-profit domain" very confusing as .pizza
> is a very much for profit domain. Normally, the terms "Generic
> domain" and "Brand domain" although I guess the latter is
> usually avoided in written text. While the term is described
> to mean a Generic Domain, I think it would be better to use
> Generic domain instead of For-profit domain.

"For-profit" was chosen after multiple discussions about the
best term and was chosen, in part, because it is not in common
use.  IIR, we started with "public domain", a term that is
widely used but, unfortunately, use inconsistently wrt
definitions.  I've personally never seen or heard "brand domain"
used prior to your note but I travel in different circles than
the domainer community.    "Generic" does not work for several
reasons.  First, the term has been used since RFC 1591 and
earlier to make the distinction at the top level from
country-code domains (see https://www.iana.org/domains/root/db
as an example) .  If "sponsored" (a term ICANN started using
around 2000) or "brand" are useful at the top level, they are
presumably subsets of "generic". Second, to use your example, a
"pizza" TLD is generic in the "not a ccTLD" sense, but not in
others (I gather than there are places where a claim that
something was a "generic pizza" would be considered culturally
offensive).  

In the interest of time and space, I won't go on much further,
but remember that this document, like all of the IDNA core
documents, is intended to be applicable to every zone in the
DNS, not just the root or maybe the behavior of TLDs vis-a-via
the names they allocate or delegate.   The main point of this
document, the relevant text in the base IDNA documents, and some
of the language in RFC 1591 is that registries (a term that
comes from early DNS documents is that is repeated in RFC 1591,
and that appears in RFC 8499) are responsible for whatever
strings they register and that they should take that
responsibility seriously.   For IDN purposes and in the core
IDNA documents, that statement took the form of "if you don't
understand the implications of a particular string, including
the writing system implications, don't allow it".   While rarely
explicit, that rule is followed in an overwhelming fraction of
the zones in the DNS.  Most enterprise and organization zones
allocate subdomains using names and terms (or abbreviations for
them) that make sense to them.  They are doing the right thing
and don't need this I-D or the language in the base IDNA
documents to tell them to do that or help with it.   The
problems mostly seem to occur in domains (gTLD, ccTLD, and
deeper in the tree alike) that are dependent on the number of
domains they sell for their income and support.   Probably
because they have incentives to sell more and more names that a
registry that is operated as a public service or on a strict
cost recovery basis typically does not, the former groups have
far less incentive to push boundaries.   Again the offenders
include both traditional ccTLDs, traditional gTLDs, and many or
most of the "new TLDs" created by ICANN in recent years as well
as some situations deeper in the tree -- not all of them,
clearly, but some.

So, for any zone that naturally behaves as the documents being
updated by this one specify, i.e., that doesn't delegate
anything the registry doesn't understand thoroughly, this
document is a non-issue.  It is important for domains that don't
intend to follow that guidance but who intend to register IDNs
anyway.  This is guidance primarily for them and to keep them
and the Internet out of horrible trouble, and "for-profit" is
the closest we could get.  And, before you ask, we didn't say
that in so many words because we are aware that the boundaries
are not absolute and we didn't want to be over-broad.

If you have better suggestions about terminology, they would be
welcome... at least as long as they do not result in delaying
processing and approval of this document.  

>   Registries choosing to make exceptions -- allow code points
> that   recommendations such as the MSR do not allow -- should
> make such   decisions only with great care and only if they
> have considerable   understanding of, and great confidence in,
> their appropriateness.
> 
> This paragraph seems really to say "Registries SHOULD NOT make
> exceptions" and seems a good place for some RFC 2119 wording.

While the language was a compromise -- Asmus is inclined to be
somewhat more restrictive and directive than I am -- "SHOULD
NOT" is definitely not appropriate.   

One of my favorite examples, and one that came up several times
in the discussions leading to IDNA2008, has to do with
characters from archaic scripts.  IDNA2008, after long
discussion, allows them.  ICANN won't allow them in the root
(for good reason) and discourages them at the second level (also
for good reason, although it is more controversial) and hence
they are not in the MSR.  But, if one had a museum or academic
department with a specialty in those scripts or the languages
and cultures with which they are associated, subdomains with
those characters might make perfectly good sense (and the
"understand what you register" requirement is probably easily
met).

> I find the term "registry" in this document confusing, as it
> could refer to an "IANA registry", "script registry" or
> "domain registry". Perhaps always spell this out to make the
> context clearer?  Or alternatively, perhaps introduce the term
> Registry (with captial R)  and use that to refer to domain
> registries.

See above.

> [ID.draft-klensin-idna-unicode-review] is in progress.  Its
> status    should be checked in conjunction with application of
> the present    specification.
> 
> I think this is meant as informational to the RFC Editor ?
> Perhaps these documents should go out as a cluster?

Yes, it is informational to the RFC Editor.  And, yes, it is not
an accident that the two documents went out for Last Call at the
same time and are being evaluated concurrently.  My hope is to
see both to them in the RFC Editor's hands at the same time,
whether they are explicitly handled as a cluster or not.

> Note I find some documents are references within [square
> brackets] but not all of them, even some RFC's are in brackets
> and others are not. Please make this consistent.

I think you will find that all documents are cited (with the
square brackets) at least once.  After many discussions over the
years with the RFC Editor, subsequent mentions of the same
document are not handled as citations if that would make the
text awkward (in the opinion of the authors).  The RFC Editor
certainly has the right to dispute those choices during their
editing pass.  If you have identified references to documents
that do no appear in citations at all, please tell us about them
and they will be fixed.  If you are disputing the policy, take
it up with the RFC Editor.

On checking on your comment, I did catch one instance of a
reference in square bracket that was not properly set up as a
citation.  It is now fixed in the working version but, unless
the AD directs otherwise, I'm not going to repost for this
rather trivial problem that I'm confident the RFC Editor would
have caught.

> missing xref's to the RFCs?

Nope.  Cited with xrefs in the same section, two paragraphs
earlier.  See above.

> Either use "SHOULD" or "normally", not both? It's a little odd.

This document is a little odd in the sense that, in a more
perfect world, it should be completely unnecessary.  If there
were greater understanding of and consensus about the issues
associated with IDNs in the various communities that want to use
them and will encounter them, we would not be bothering with it
(much of that is explained above).   In particular, the IETF
usually avoids publishing documents that say "you MUST do X,
but, if you don't, then you SHOULD do Y or Z.  But that is
precisely the position this document is in with MUST language in
the base IDNA RFCs that a number of registries have chosen to
ignore for business or other reasons.   Given that, language
that is "a little odd" is probably predictable.    

> Instead of mandate, which is a bit generic and confusing, why
> not refer to the mentioned "IAB guidance", which I think it is
> referring to ?

Because it isn't referring to the IAB guidance or, more
specifically, is referring to parts of it and some other things.
Suggested better language would be welcome, again subject to the
request/ suggestion above.

> Remove the word "may"

"may" was intentional.   Those documents are completely
irrelevant if one of the script or language-specific RFCs are
considered.  Whether the MSR is relevant or not below the root
or in a zone for which ICANN does not have authority is
controversial.    If everyone agreed that it was relevant, this
document could be replaced by something much shorter that would
say "regardless of what IDNA allows, no characters or character
sequences are permitted unless they exclusively use one of the
scripts that ICANN has considered as part of the VIP/ LGR
process and by the MSR and other ICANN recommendations and rules
that derive from that process".  But, for a number of reasons
including those that are at least hinted at above, there is no
such agreement,

---

From: Paul Wouters <[email-masked]>
Date: Wed, 4 Sep 2019 10:38:01 -0400 (EDT)

On Tue, 3 Sep 2019, John C Klensin wrote:

> Subject: Re: Secdir last call review of draft-klensin-idna-rfc5891bis-05

[ Only addressing the document review items in this email, not the SecDir review process ]

> keeps documents shorter.

I understand it is a matter of preference. I find it takes me less time
to go through the document's Table of Contents to find the IANA Section
that says "nothing to see here, move along" than it is for me to try
and find the non-existing IANA Section.

> use.

Okay. Again personally, I think as a person who has spend time in
IETF and ICANN that this term is less clear, but if the WG and
author has spent considerable time on this discussion already, then
there is no need to revisit this based on my single added opinion.

> NOT" is definitely not appropriate.

If this has been discussed and the result of a compromise, again
my one voice shouldn't matter anymore in this case so feel free
to leave as is. Although personally I do think you could have
used "SHOULD NOT" followed by a "MAY" to give this a little more
weight (especially as the document talks about outsiders/implementors
getting things wrong). But this is not important enough to re-open
an old discussion.

> See above.

Same here, that's fine.

> whether they are explicitly handled as a cluster or not.

Good.

> years with the RFC Editor

That's fine then too. I personally prefer to have it clickable, so
if at the third time of an RFC being mentioned I go like "okay, I
should really read this" and I can click on it on that 3rd instance.
But I also understand the document shouldn't become a Christmas tree
of links.

> rather trivial problem that I'm confident the RFC Editor would

That's fine, thanks.

> perfect world, it should be completely unnecessary.

For me as a programmer, I prefer to read SHOULDs followed by MAY
to relay these kind of "should normally do X". It is just more
formal and thus easier for implementers to follow programatically.
But again, if this has seen lots of discussion already, please
feel free to leave as is.

> request/ suggestion above.

Now this does seem like a real issue. After reading it a few times,
I included that "mandate" meant the IAB guidance, and now you are
telling me it actually does not. So that just confirms the use of
"the mandate set out above" is actually not at all clear and should
be clarified.

> "may" was intentional.

Okay.

So in conclusion, all my comments/questions are addressed, except for
the mandate issue. It is not big enough to block the document for, but
I think it would be useful to clarify further.

Paul

---

From: Barry Leiba <[email-masked]>
Date: Wed, 4 Sep 2019 11:56:57 -0400

Hi, Paul, and let me add my thanks for your careful review of a rather
esoteric document.

> But I also understand the document shouldn't become a Christmas tree

This has come up often.  As a text style thing, I know that John
prefers not to have the citation as part of the text.  It's the
difference between "As [RFC5891] says, ...," and "As the IDNA Protocol
[RFC5891] says, ...."  I mostly agree with John on this, from a
stylistic point of view, but accept (and even embrace) the reality
that many people like the former.  But style aside, Paul, your issue
is more about convenience to the reader, and that's an important
thing.  Clearly, there's no direct difference, simply from a "reading
the text" angle, between "RFC 5891" and "[RFC5891]".  This is,
therefore, an issue of tooling.  If we should change the HTML
rendering so that "RFC 5891" or "RFC5891" were as readily clickable as
"[RFC5891]", this would simply not be a problem, right?  Assuming
that, I think I will have a conversation with the tools team: we
should just do it.

> feel free to leave as is.

Yes, lots of discussion, yes, we'll leave it as it is for this case.  But...

In the general case, I actually rail *against* "SHOULD X, but MAY Y",
because I think they're contradictory: doing Y is not an entirely
optional choice (and MAY is too flaky anyway, and doesn't work here).
My strong preference is for using the following:
- MUST do X unless <condition>, in which case MUST do Y.
- MUST do X unless <condition>, in which case SHOULD do Y.
- MUST do X unless <condition>, in which case implementations generally do Y.
- SHOULD do X.  <explanation>

I note that in the last case, you already have an out, if you have a
good reason not to do X and understand the interoperability or
security implications.  But I think that most SHOULDs ought to include
an explanation of why it's "SHOULD" (and not MAY or MUST), what the
implications are, and what is done otherwise.  That explanation
doesn't need to have BCP 14 key words in it, and it probably detracts
from it if it does, at least much of the time.

Perhaps an exception to that last is if there are only, say, two
options, and one is strongly preferred from an
interoperability/security point of view.  Then, "SHOULD do X, but if
you don't do X you MUST do Y."  Or maybe "MUST do X or Y, and SHOULD
do X."

(BTW, I also think that "MAY do X" is useful only in certain
circumstances.  It's useful to alert one side that something might
happen that could otherwise be unexpected ("The server MAY close the
connection without warning."), and for clarity in certain situations
("The client MAY include multiple instances of X.").  It's not good
for things like, "The client MAY set the FARBLE bit to indicate that
it is farbling."  Well, yes, one presumes that's what the FARBLE bit
is for.)

Barry