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

[Alexey Melnikov <[e-mail]>]

Hi Ekr,

On Sat, Feb 24, 2018, at 8:13 PM, Eric Rescorla wrote:
> 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"

I've added the direct reference to [WEBER], as I think it is the most
appropriate here.
Best Regards,
Alexey

> 
> 
> On Fri, Feb 16, 2018 at 9:24 AM, Russ Housley
> <[e-mail]> wrote:>> 
>>>> 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.>>> 
>>> 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
>> 
>>