Re: [EAI] Quick comments on draft-ietf-eai-mailto-00

[Martin Duerst <duerst at it.aoyama.ac.jp>]

Hello John,

Many thanks (also to Frank) for your very quick feedback.

At 09:48 08/02/19, John C Klensin wrote:
>Martin,
>
>Some quick reactions...
>
>(1) This is really ugly.  Perhaps nothing can be done about it,
>but I think that is worth noting, especially since we have gone
>out of our way to make
>non-ASCII-string at non-ASCII-string.whatever.tld a value email
>address.

What are you referring to by "This"? If it's all the %-escaping,
then I fully agree with you. That's why we have IRIs :-).
I can guarantee that the draft would contain quite a few IRI
examples if the ID/RFC format allowed non-ASCII.

But we can't change the fact that we have to escape '<' and '>'
and so on.

More later.      Regards,    Martin.

>(2) It might be a bit less ugly if you used only envelope
>addresses (RFC2821-derived) rather than header (RFC2822-derived)
>ones.  In particular, I really see little need to incorporate
>name phrases in these strings and much less need to incorporate
>comments.  See also (6) below.
>
>(3) It is perhaps worth a comment that "?" is a valid character
>in a local-part.  More %-encoding, I assume.  The first Note 1
>in Section 2 doesn't go quite far enough in that regard, even
>though the requirement for surrounding "<" and ">" might
>eliminate the parsing problem for i18n addresses.
>
>(4) In Section 2's final set of notes (below "Non-ASCII
>characters can be encoded in "hvalue"...), your first bullet
>says "SHOULD".  If the sending system ignores that
>recommendation, what do you think will happen?  Think someone
>might apply the UTF-8 encoding algorithm to ISO 8859-6
>characters?
>
>(5) While I sympathize with the reasons for Section 3, it is
>handwaving, since the typical context in which a mailto URI
>might be used would have absolutely no way to tell at the time
>the URI is written.
>
>(6) Your examples should include one in which the phrase and
>comments, including characters in the former that require
>quoting, are used if you really want to require support for them.
>
>(7)  If a relatively simple mailto URI will look like
>
>mailto:%3Ccaf%C3%A9 at %E7%B4%8D%E8%B1%86.example.org%20%3Ccafe@
>   natto.example.org%3E%3E
>
>then I contend there is a security threat associated with this
>system that is not present in the listed RFCs.  The problem is
>that one of our more important security aids is the user's
>ability to inspect a string and determine that it is nonsense or
>a threat.  I suggest that, for a typical user, the effect of a
>string similar to the above is "the eyes glaze over" rather
>than, e.g., the implied warning of seeing the domain name (at
>least) as an ACE.   Put differently, this sort of string makes
>it extremely easy for an attacker to hide hostile information in
>the string, since no user will be able to render that string
>into anything familiar.
>
> best,
>    john
>
>
>_______________________________________________
>IMA mailing list
>IMA at ietf.org
>http://www.ietf.org/mailman/listinfo/ima


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst at it.aoyama.ac.jp     

_______________________________________________
IMA mailing list
IMA at ietf.org
http://www.ietf.org/mailman/listinfo/ima