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

Russ Housley <housley@vigilsec.com> Fri, 16 February 2018 17:24 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBD3128C0A for <spasm@ietfa.amsl.com>; Fri, 16 Feb 2018 09:24:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vs-1C_DmN9XL for <spasm@ietfa.amsl.com>; Fri, 16 Feb 2018 09:24:49 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC16124C27 for <spasm@ietf.org>; Fri, 16 Feb 2018 09:24:49 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0A95430063B for <spasm@ietf.org>; Fri, 16 Feb 2018 12:24:47 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EPPUbhWuUZwe for <spasm@ietf.org>; Fri, 16 Feb 2018 12:24:44 -0500 (EST)
Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id AB75C3002AD; Fri, 16 Feb 2018 12:24:44 -0500 (EST)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <C8F2790D-2EF9-4380-82D0-240D9CCC526D@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A8B91E4D-8A1D-4DCD-A094-7F7AC2DBEA6F"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 16 Feb 2018 12:24:45 -0500
In-Reply-To: <31F17EFC-2DE2-4614-BAC7-6822E7C152C5@kaloom.com>
Cc: "spasm@ietf.org" <spasm@ietf.org>
To: Suresh Krishnan <suresh@kaloom.com>, Alexey Melnikov <aamelnikov@fastmail.fm>, Wei Chuang <weihaw@google.com>, Eric Rescorla <ekr@rtfm.com>
References: <151564026499.22453.4457143592887035396.idtracker@ietfa.amsl.com> <1515687117.1257366.1232046744.30F6CC88@webmail.messagingengine.com> <39EBFE0E-F7D5-4257-9254-CEC8D15C4435@kaloom.com> <1518431987.1831236.1267758584.2A4EF883@webmail.messagingengine.com> <31F17EFC-2DE2-4614-BAC7-6822E7C152C5@kaloom.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/kej28Ymjr25ceL6sVzA3ouiMGOg>
Subject: Re: [lamps] Suresh Krishnan's No Objection on draft-ietf-lamps-eai-addresses-15: (with COMMENT)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Feb 2018 17:24:51 -0000

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