Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 07 March 2017 22:18 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B896C12960D for <ietf@ietfa.amsl.com>; Tue, 7 Mar 2017 14:18:12 -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, URIBL_BLOCKED=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 4vosJHt3I-8i for <ietf@ietfa.amsl.com>; Tue, 7 Mar 2017 14:18:11 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B746129630 for <ietf@ietf.org>; Tue, 7 Mar 2017 14:18:01 -0800 (PST)
Received: from [172.31.30.83] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 93D577A32D8 for <ietf@ietf.org>; Tue, 7 Mar 2017 22:18:00 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email Addresses in X.509 certificates) to Proposed Standard
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <25454827-48CD-4268-A44E-35ECB67C0BCE@vigilsec.com>
Date: Tue, 7 Mar 2017 17:17:59 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <A84C7A12-2B68-4A2E-AB3B-85811023AF90@dukhovni.org>
References: <CAAFsWK2QjdkovXTgJR-6Hpj=u=MD5Mjk0srYVpoqNnK_d7_Y9Q@mail.gmail.com> <78EFB6CA-BB21-4B6F-964C-9A0BBAA68023@dukhovni.org> <CAAFsWK0p5Zjj73Av3Z=TpjRmpJwFekfj9N+4zdcE_fFDcw65dA@mail.gmail.com> <20170206182023.GN28349@mournblade.imrryr.org> <20170208051311.GP28349@mournblade.imrryr.org> <CAAFsWK3xY35+yD5drtmUJUNMaAA8pRUwM3h22rvm+k7g5W8uKg@mail.gmail.com> <20170208151943.GQ28349@mournblade.imrryr.org> <CAAFsWK20Sf51W+cRUBET8-U5XXO+Z1ixOt3dgu70ad99FPsrWg@mail.gmail.com> <20170209175737.GV28349@mournblade.imrryr.org> <EB04BFE1-6A74-4697-9D4F-67A356B107DE@vigilsec.com> <20170209223951.GW28349@mournblade.imrryr.org> <25454827-48CD-4268-A44E-35ECB67C0BCE@vigilsec.com>
To: IETF general list <ietf@ietf.org>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/UI80qs6HFDDCeNbJgZm1oyD6gvE>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: IETF general list <ietf@ietf.org>
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Mar 2017 22:18:13 -0000

> On Feb 9, 2017, at 7:06 PM, Russ Housley <housley@vigilsec.com> wrote:
> 
> 
> Wei is arguing that the two (ffc822Name and SmtpMUtf8Name) should be completely separate.
> 
> You are arguing for some crossover,

I am not arguing for "some crossover", I am arguing to stop bypass attacks
when rfc822Name constraints are specified by a (legacy) CA, and SmtpUtf8Name
constraints are not.

Anything that prevents the creation of SmtpUt8Name entries that violate the
intent of the rfc822Name constraints is sufficient.  In particular, it is
not absolutely necessary to allow "faß.de" to be used via a name-constained
legacy certificate.  The most recently proposed compromise was to just ban
all SmtpUtf8Name altnames when rfc822Name constraints are set, with no
corresponding SmtpUtf8Name constraints.

> but I do not understand how A-labels in the rfc822Name are handled in your proposal.

No special treatment, just disallow bypass via use of unconstrained SmtpUtf8Name.

> If rfc822Name permits 'xn--fa-hia.de’ then it would need to be translated to 'faß.de’ for comparison in SmtpUtf8Name.

Simplest to avoid translation, and just deny.

-- 
	Viktor.