Skip to main content

Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations
draft-klensin-idna-rfc5891bis-06

Discuss


Yes

(Adam Roach)
(Barry Leiba)

No Objection

(Deborah Brungard)
(Magnus Westerlund)
(Martin Vigoureux)

No Record

Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Warren Kumari
Zaheduzzaman Sarker

Summary: Needs a YES. Needs 8 more YES or NO OBJECTION positions to pass.

Roman Danyliw
No Objection
Comment (2019-09-18 for -05) Sent
** Section 2.  Recommend citing homograph attacks like was done in RFC8324:
[CACM-Homograph] Gabrilovich, E. and A. Gontmakher, "The Homograph Attack", Communications of the ACM, Volume 45, Issue 2, pp. 128, DOI 10.1145/503124.503156, February 2002, <http://www.cs.technion.ac.il/~gabr/papers/homograph_full.pdf>.

** Section 2.  Per “The most obvious of those restrictions include provisions … so as to avoid homograph attacks and other issues”, what are “other issues"?

** Section 3.  Per “registries SHOULD normally consult … [ICANN-MSR4]”, what does the normative language of consulting mean here?

** Section 4.  Per “IDNA (and IDNs generally) would work better and Internet users would be better protected and more secure if registries and registrars (of any type) confined their registrations to scripts and code point sequences that they understood thoroughly”:

-- Is there a citation to back the claim that tighter scripts/code point sequences have resulted in better end user security? Or that loose practices are sources of attacks?

-- what does “understood thoroughly” mean here?  How does one know that they have an “understanding”?

** Section 7.  Per “As discussed in IAB recommendations about internationalized domain names [RFC4690], [RFC6912], and elsewhere, poor choices of strings for DNS labels can lead to opportunities for attack …”, isn’t the key issue design policies for the labels (as noted later).  An attacker choosing a clever name doesn’t seem like a poor choice of a string.
Éric Vyncke
No Objection
Comment (2019-09-17 for -05) Sent
Thank you for the work put into this document. I have only one easy to fix COMMENT but I also wonder (like Mirja) about the sections about errata.

Regards,

-éric

== COMMENTS ==

-- Section 1 --
C.1) Please use a the RFC 8174 boilerplate.
Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Alissa Cooper Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2019-09-18 for -05) Sent
(1) Labeling one category of zones as "for-profit" gives me pause because a number of such zones are operated by not-for-profit entities, and retaining that status is quite important for both them and the Internet (e.g., .org, which is obviously significant for the IETF). I think the distinction being made is not whether the zone is run for profit, but whether it is commercial -- that is, whether domain names in the zone are bought and sold. 

(2) Section 4 says:

"While the IETF rarely gives advice to those who choose to violate
   IETF Standards, some advice to zones in the second category above may
   be in order.  That advice is that significant conservatism in what is
   allowed to be registered, even for reservation purposes, and even
   more conservatism about what labels are actually entered into zones
   and delegated, is the best option for the Internet and its users."

I don't see how we can have this formulation in a consensus IETF document. Either we are giving the advice to the specific audience, in which we should give it in a straightforward manner, or we are not giving the advice, in which case we should not have this text in the document. I think a better approach would be to re-formulate the whole paragraph in which this text is embedded to explain what the best practices are as far as conservatism for registries and registrars of any type.
Lars Eggert Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2021-04-26) Sent
[Remove the item that was addressed in -06. Add new DOWNREF issue.]

Taking over this DISCUSS from Alissa.

> (2) Section 4 says:
> 
>    "While the IETF rarely gives advice to those who choose to violate
>    IETF Standards, some advice to zones in the second category above may
>    be in order.  That advice is that significant conservatism in what is
>    allowed to be registered, even for reservation purposes, and even
>    more conservatism about what labels are actually entered into zones
>    and delegated, is the best option for the Internet and its users."
> 
> I don't see how we can have this formulation in a consensus IETF document.
> Either we are giving the advice to the specific audience, in which we should
> give it in a straightforward manner, or we are not giving the advice, in which
> case we should not have this text in the document. I think a better approach
> would be to re-formulate the whole paragraph in which this text is embedded to
> explain what the best practices are as far as conservatism for registries and
> registrars of any type.

On this one, I see no text changes in -06. I agree with Alissa's objection.
Asmus Freytag proposed a rephrasing that looks like it would address this DISCUSS.

Appendix "A.6.", paragraph 9, discuss:
>    o  References to RFCs 5893 and 6912 moved from Informative to
>       Normative.

This change created a new DOWNREF to RFC6912 that consequently has not been
through IETF Last Call.
Adam Roach Former IESG member
Yes
Yes (for -05) Not sent

                            
Alexey Melnikov Former IESG member
Yes
Yes (2019-08-31 for -05) Not sent
The document suggests possible changes to other documents, which might not age well once published. These need to be double checked.
Barry Leiba Former IESG member
Yes
Yes (for -05) Unknown

                            
Benjamin Kaduk Former IESG member
(was Discuss) Yes
Yes (2020-07-13) Sent
Trimming most of my comments originally on the -05 as (assumed to be)
addressed or explained to be non-issues.  I can't find in my archives anything
that is responsive to the following one, though (my apologies if I just didnt'
look hard enough):

I'm not really sure I understand the response to the secdir reviewer's
suggestion to more clearly differentiate "domain registry", "IANA
registry", and "script registry"; could the relevant portion of the
reply be pointed out more clearly?  (Absent a better understanding of
the existing response, I have similar sentiments as the reviewer.)


Additional comments on the -06:

draft-klensin-idna-unicode-review became RFC 8753; is there a reason
to mention it instead of just removing the pointer to the draft?

s/revenue about actual costs/revenue above actual costs/?
Deborah Brungard Former IESG member
No Objection
No Objection (for -05) Not sent

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (for -05) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -05) Not sent

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2019-09-05 for -05) Sent
I think the status of this document should be BCP or informational. The shepherd write-up says that it's PS because it updates rfc5890, however, I don't think there is requirement for an updating document to have the same status (given this is "just" and update and not a bis that's obsoleting the old doc; which btw. is confusing given this naming of this draft).

I also don't find it a useful practice to (only) update RFCs to integrate errata. If the errata as currently logged as verified are not correct (and the document is not actually obsoleted by a bis), there should probably be a way to update the errata correctly.