Re: Last Call: <draft-ietf-lamps-eai-addresses-05.txt> (Internationalize

On Fri, Feb 3, 2017 at 8:07 AM, John C Klensin <john-ietf(_at_)jck(_dot_)com> 
wrote:

> Victor, Wei Chuang, and IESG,
>
> The more this discussion goes on, the more I become convinced
> that this document should make an explicit reference to the IDNA
> 2008 and SMTPUTF8 documents,

There is a recently posted 06 draft now, that calls out the IDNA 2008
requirement (RFC 5890) for the domain of the email address explicitly.
This is for SmtpUtf8Name and rfc822Name.  In the very brief time its been
up, we haven't gotten feedback in the WG for that proposal.  It currently
and previously called out that the format of SmtpUtf8Name is SmtpUtf8Mailbox,
and that is a modified form of Internationalized Mailbox defined in Section
3.3 of (RFC6531).

say that strings in certificates
> MUST conform to whatever is allowed there and then, other than
> making a statement about preference for U-labels over A-labels
> (or vice versa), say as little as possible.

The document calls for SmtpUtf8Name to use U-labels or NR-LDH ASCII labels
for domain but not A-labels.  We got advice to minimize alternative domain
forms as some implementations have had bugs doing the transform.  We chose
U-labels to be consistent as the local-part is already UTF8 form and to
simplify implementations.  The document recommends that SmtpUtf8Name only
be used when the local-part requires UTF8 and otherwise use rfc822Name.

-Wei


> The problem is that
> use of forms that might have coded meanings without knowing what
> those meanings are is an opportunity for mischief, something
> that should be of special concern for a piece of work that is
> security-specific.
>
> I note that "prohibit everything that has a prefix consisting of
> two ASCII letters followed by '--' unless the letter sequence is
> specifically allowed" has been discussed at length and then
> agreed on in at least three WGs specialized about the
> identifiers, not just their embeddings (original IDN, IDNbis,
> and PRECIS).  Even if there were a growing consensus that a
> different rule would be more appropriate (and, AFAICT, there
> definitely is not), it would be a bad idea for LAMPS or other
> certificate-related work to get ahead of that consensus and
> specify something inconsistent with the identifier standards
> themselves.
>
> Phill's proposal, independent of its merits, is almost
> irrelevant to the question.  From the standpoint of the present
> work, it is one of many proposals to do interesting things with
> the DNS by using ACE-style (or trick-prefix) labels.  If the
> community concludes that it is a good idea and has a plausible
> chance of global deployment, the DNS/IDNA and SMTP (or SMTPUTF8)
> specs will need to be modified to allow the prefix.  The LAMPS
> "eai" spec should be written so that, if those specifications
> are modified, whatever they allow should be allowed in certs,
> but should, again, not be allowed to get ahead.   If that means
> we are now in need of an IANA registry of such prefixes (with
> exactly one initial entry plus maybe one long-deprecated one),
> that ought to be easy to do.
>
> As to "put all the alternate forms in the cert", we've been
> there too and it hasn't ended happily.  Fully-qualified DNS
> names are part of a hierarchy.   Transcoding between A-labels
> and U-labels is an algorithmic matter, not a hierarchy of
> choices but, if there are even two choices for the form of a
> label at each of several different levels of the hierarchy, one
> rapidly gets to a combinatorial explosion.  I trust everyone
> here can do the arithmetic.  If listing all of the possible
> variations on an FQDN in the certificate is the solution, then
> the WG -- on behalf of those who issue, certify, validate, and
> check certificates -- needs to be prepared for certs with
> dozens, sometimes hundreds, of names in them, not just the
> examples that have been floated with perhaps two or three.
>
> Remembering that, if, as Porky Pig, I can get a cert issued to
> me with Mickey Mouse as an alternate name that is treated as a
> synonym for all purposes, much of the value of certification is
> lost and, IMO, we are all in big trouble.   If the WG wants to
> encourage alternate name behavior, I think it is imperative that:
>
>         (i) The document contain explicit instructions to
>         certificate issuers and CAs about what should be checked
>         and to client systems about what should be
>         believed/trusted and under what circumstances.
>
>         (ii) Certificate provisions to specify certification
>         levels and exactly what is being certified need to be
>         reexamined and probably expanded to identify trust
>         levels and accountability around alternate names.
>
>         (iii) The "Security Considerations" section of the I-D
>         should be expanded to explicitly discuss these cases and
>         the risks.
>
> The document should not be approved until that work is complete
> and reaches consensus.
>
>    best,
>       john
>
>
> --On Wednesday, February 1, 2017 21:01 +0000 Viktor Dukhovni
> <ietf-dane(_at_)dukhovni(_dot_)org> wrote:
>
> > On Tue, Jan 24, 2017 at 07:31:09PM -0000, John Levine wrote:
> >
> > > > My impression is that there is little problem with the
> > > > intended underlying spec, but the document text needs some
> > > > tuning.
> > > Agreed.  The subsequent section on comparing names would
> > > likely benefit from clearer instructions, e.g.
> > >
> > > a) if the domain contains A-labels, turn them into U-labels
> > > b) if the domain still contains R-LDH labels, stop, not a
> > > valid name. c) if the domain contains NR-LDH labels, make
> > > them all the same case d) do a straight byte comparison of
> > > the addresses
> > I think that restricting R-LDH labels that are not A-labels is
> > too strict, see for example Phil Hallam-Baker's proposed
> > encapsulation of email addresses with "the mesh" (attached).
> >
> >   TL;DR:
> > alice(_at_)example(_dot_)com(_dot_)mm--MBTVK-ZKCWT-KHMTE-XM3I7-GSQNK-MLFYE
> >
> > The "mm" R-LDH namespace (if/when implemented) or some other
> > future namespace should probably not be excluded at this time.
> >
> > If the intent is to canonicalize A-labels to U-labels, then
> > perhaps only "xn--" labels should be proscribed, if any.
> >
> > On the other hand, I see there is some support for allowing
> > certificates to contain whatever form is actually used in email
> > headers, and perhaps more than just one such form.  If so,
> > there is no need to proscribe any names at all.  The client
> > performs no conversions, and the certificate would need to be
> > inclusive of any addresses that are in actual use.

smime.p7s
Description: S/MIME Cryptographic Signature