Subject: Re: [I18n-discuss] Fwd: [iab] #138: Marc's review

From: Dave Thaler <[email-masked]>
Date: Wed, 25 Apr 2012 01:26:19 +0000

Hi Marc,

So far I've addressed your comments but not John's yet (will do those next).

Version in progress:
http://research.microsoft.com/~dthaler/draft-iab-identifier-comparison-02a.txt 

Diffs from -01:
http://tools.ietf.org/rfcdiff?url1=draft-iab-identifier-comparison-01.txt&url2=http://research.microsoft.com/~dthaler/draft-iab-identifier-comparison-02a.txt 

Below is what I've done to try to address Marc's comments.

> Section 2.
>  Maybe on purpose, but the section talks about Authentication and
> Authorization, but not Accounting. I would add a paragraph on accounting,
> since it is part of security issues with comparing identifiers. Some text
> suggestion:
>   Accounting: a system may create an accounting record for an identifier while
> another system may create an accounting record for the same object but using a
> different representation of the identifier, while yet another system may get
> another representation of the identifier from user input searching through the
> accounting records.  The (improper) matching of identifiers in accounting
> records may have  various levels of impacts. For example, law enforcement
> agencies shall really need to get full match. IDS may act upon accounting records
> and then add new filtering rules based on the identifiers of these accounting
> records to stop an attack.

Thanks for the suggestion.  I found the above a bit too wordy, but good for
getting me to understand your point.   I've added a shorter version, which
uses a language construction similar to the other two paragraphs:

   o  Accounting: a system might create an accounting record for a  
          security principal identifier or resource name, and then might  
          later need to match a supplied identifier to allow (for example)  
          law enforcement to follow up based on the records, or add new  
          filtering rules based on the records in order to stop an attack.

> 2.2: the use of the word "thing" was for me not clear. I would suggest replacing
> "thing" with "object" in those paragraphs.

Done.

> 2.2 s/should not have been permitted/should not have been permitted
> otherwise/.

Done.

> 2.2: I'm not native speaker, but shall we do s/permissable/permissible/

Yes, done.

> 2.3 since it is like a named service, I would suggest s/stuff service/Stuff service/

Done, and for consistency changed it in the beginning of the path inside the URIs
since the text was referring to that segment.

> 3.1.3 there are many terms, acronyms and implied understanding in these
> paragraphs. I would suggest to add references when using new acronyms.
> example: punycode [RFC3492], IDNA [...], ...

Done.

> 3.1.3 s/For example, labels might/For example, DNS labels might/....

Not quite.  As noted in RFC 6055, it's not just DNS.   Instead changed
to "hostname labels" which is consistent with the surrounding language.

> 3.1.4 I think this discussion should also add examples where 2 names may have
> different combinations of IPv[46] addresses. Some text suggestion:
> Moreover, if name1 resolves to IPv4 address A  and IPv6 address B, and
> name2 resolves to IPv4 address C and IPv6 address B, then the resolution for
> comparison is ambiguous. Other variations of these cases can show that it could
> be even worse.

Again I found the above a bit verbose (especially since this isn't a huge point
in the doc) but good at getting me to understand your point so thanks.  
Updated text quoted further below.
 
> 3.1.4 would be good to have a reference to the specific Java version we are
> talking about. And if this has been fixed or not, and if fixed, in which release.
> While it is more specific, I think it is good to show if this is still a real problem or
> not.

Looks like it's still that way in the latest version of Java.   
With this change and the previous one the first paragraph of 3.1.4 now reads:

	Some systems (specifically Java [JAVAURL] URLs) use the rule that if
	two hostnames resolve to the same IP address then the hostnames are
	considered equal.  That is, the canonicalization algorithm involved
	name resolution with an IP address being the canonical form.
	However, with the introduction of dynamic IP addresses, private IP
	addresses, multiple IP addresses per name, multiple address families
	(e.g., IPv4 vs. IPv6), etc., this method of comparison cannot be
	relied upon.  There is no guarantee that two names for the same host
	will resolve the name to the same IP addresses, nor that the
	addresses resolved refer to the same entity such as when the names
	resolve to private IP addresses.

   [JAVAURL]  Oracle, "Class URL, Java(TM) Platform, Standard Ed. 7",
              2011, <http://docs.oracle.com/javase/7/docs/api/java/net/
              URL.html>.

> 4.  I don't agree with "As such, highly secure systems cannot rely on visual
> inspection.", since it kinda imply that only in secure systems this problem
> happen. I think just having a user going to a wrong web site even if there is no
> threat is an important problem of visual inspection.  So
> suggesting: "As such, systems cannot rely on visual inspection."

Well maybe "cannot" isn't quite right there, since nothing prevents them
from doing so, and indeed many less secure systems do so.  Changed to:
"As such, using visual inspection for security is unreliable."
 
> 4. I think this section should get some text/ideas from the precis- problem-
> statement, by the following perspective.  Here is some suggested
> text:
> The preparation algorithm of an identifier and the allowed code point repertoire
> in protocol A may be different from protocol B. But the id may be used and
> passed between the two protocols, therefore creating comparison problems.
> See [draft-ietf-precis-problem-statement] for more information on the issue and
> also contains reviews of various protocols using different preparation algorithms
> and code point repertoires.

Suggested text above introduces too many new terms in my view, but I did find 
it a useful starting point.  Here's what I've added that uses terms already used 
elsewhere in the doc:

	Finally, the set of permitted characters and the canonical form of
	the characters (and hence the canonicalization algorithm) sometimes
	varies by protocol today, even when the intent is to use the same
	identifier, such as when one protocol passes identifiers to the
	other.  See [I-D.ietf-precis-problem-statement] for further
	discussion.

Let me know if these changes appropriately address your feedback.

Thanks, and especially thanks for suggesting text.

-Dave

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 25 Apr 2012 09:00:25 -0400

- all fine.  The only minor is that I sometimes prefer to state issues with detailed examples (such as the few ones I wrote with A, B, C…) than generic statements. But I guess that is the writing style...

Marc.

Le 2012-04-24 à 21:26, Dave Thaler a écrit :

> _______________________________________________
> I18n-discuss mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/i18n-discuss