Ballot for draft-klensin-idna-rfc5891bis
Discuss
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
** 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.
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.
(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.
[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.
The document suggests possible changes to other documents, which might not age well once published. These need to be double checked.
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/?
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.