Subject: Re: [lamps] Suresh Krishnan's No Objection on draft-ietf-lamps-eai-addresses-15: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Sat, 10 Feb 2018 15:56:40 -0800

Suresh: ping?

On Thu, Jan 11, 2018 at 8:11 AM, Alexey Melnikov <[email-masked]>
wrote:

> Hi Suresh,
>
> On Thu, Jan 11, 2018, at 3:11 AM, Suresh Krishnan wrote:
> > Suresh Krishnan has entered the following ballot position for
> > draft-ietf-lamps-eai-addresses-15: No Objection
> >
> > I think some of the comparison issues brought up in RFC6943 might be
> relevant
> > in the Security Considerations here.
>
> Can you be more specific? Are you thinking about confusable characters or
> about something else?
>
> Thank you,
> Alexey
>
>

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 12 Feb 2018 07:17:52 +0000

Hi Alexey,

> On Jan 11, 2018, at 11:11 AM, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Suresh,
> 
>> I think some of the comparison issues brought up in RFC6943 might be relevant
> Can you be more specific? Are you thinking about confusable characters or about something else?

Yep. Exactly about visually confusable characters.

Thanks
Suresh

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 12 Feb 2018 10:39:47 +0000

Hi Suresh,

> Yep. Exactly about visually confusable characters.

The document already covers that:

7.  Security Considerations

   Use of SmtpUTF8Mailbox for certificate subjectAltName (and
   issuerAltName) will incur many of the same security considerations as
   in Section 8 in [RFC5280], but introduces a new issue by permitting
   non-ASCII characters in the email address local-part.  This issue, as
   mentioned in Section 4.4 of [RFC5890] and in Section 4 of [RFC6532],
   is that use of Unicode introduces the risk of visually similar and
   identical characters which can be exploited to deceive the recipient.
   The former document references some means to mitigate against these
   attacks.

I looked at RFC 6943. While it is a good document, I don't see an obvious way of referencing it. There is so much material there unrelated to Internationalization, so it is difficult to find a useful way of referencing it. If you have some specific suggestions, please let me know.

Thank you,
Alexey

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 13 Feb 2018 03:53:20 +0000

Hi Alexey,

On Feb 12, 2018, at 5:39 AM, Alexey Melnikov <[email-masked]<mailto:[email-masked]>> wrote:

Hi Suresh,

On Jan 11, 2018, at 11:11 AM, Alexey Melnikov <[email-masked]<mailto:[email-masked]>> wrote:

Hi Suresh,

I thought of putting in a reference to Section 4.2. of RFC6943 could be useful especially since I personally found the reference to [WEBER] there very useful to understand the potential attacks. That said, maybe that is only because I am a total outsider to this space and these could be well understood attacks in the community that is the target of the draft. I am fine to proceed without adding a reference. Thanks for checking to see if this is covered.

Regards
Suresh

---

From: Russ Housley <[email-masked]>
Date: Fri, 16 Feb 2018 12:24:45 -0500

> I thought of putting in a reference to Section 4.2. of RFC6943 could be useful especially since I personally found the reference to [WEBER] there very useful to understand the potential attacks. Th…

Where are we in resolving this comment.  It seems to be the only thing keeping this document from the RFC Editor Queue.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 24 Feb 2018 12:13:00 -0800

I tend to agree with Suresh that a reference here would help. Could we just
have something like
"See [] for more on security issues with Unicode"

On Fri, Feb 16, 2018 at 9:24 AM, Russ Housley <[email-masked]> wrote:

> I looked at RFC 6943. While it is a good document, I don't see an obvious
> way of referencing it. There is so much material there unrelated to
> Internationalization, so it is difficult to find a useful way of
> referencing it. If you have some specific suggestions, please let me know.
>
>
> I thought of putting in a reference to Section 4.2. of RFC6943 could be
> useful especially since I personally found the reference to [WEBER] there
> very useful to understand the potential attacks. That said, maybe that is
> only because I am a total outsider to this space and these could be well
> understood attacks in the community that is the target of the draft. I am
> fine to proceed without adding a reference. Thanks for checking to see if
> this is covered.
>
>
> Where are we in resolving this comment.  It seems to be the only thing
> keeping this document from the RFC Editor Queue.
>
> Russ
>
>