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

From: John C Klensin <[email-masked]>
Date: Mon, 18 Feb 2008 19:48:58 -0500

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
[email-masked] a value email
address.

(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@%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
[email-masked]
http://www.ietf.org/mailman/listinfo/ima

---

From: Martin Duerst <[email-masked]>
Date: Tue, 19 Feb 2008 18:26:07 +0900

Hello John,

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

>[email-masked] a value email

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.

>the string, since no user will be able to render that string

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

---

From: John C Klensin <[email-masked]>
Date: Tue, 19 Feb 2008 13:55:59 -0500

--On Tuesday, 19 February, 2008 18:26 +0900 Martin Duerst
<[email-masked]> wrote:

>> (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
> 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.
> 

Understood.  And that was, in fact, what I was referring to.

   john