Subject: [dane] Alexey Melnikov's Discuss on draft-ietf-dane-openpgpkey-09: (with DISCUSS and COMMENT)

From: "Alexey Melnikov" <[email-masked]>
Date: Tue, 19 Apr 2016 10:42:40 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-dane-openpgpkey-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

NOTE to editors: Thank you for addressing my earlier comments in -09.
If you need any more specific suggestions about text being
added/deleted/updated, please let me know.

Despite many objections to publishing this specification I believe we
should run the experiment. I will vote "Yes" once DISCUSS-points are
addressed. I would rather see this experiment being done and fail (or
better - succeed), than to block publication of this document because it
is not perfect.

1). As per Sean Leonard/Ned Freed:

There's also - as noted by Sean Leonard - a technical glitch in the
current
specification: The local-part is not the correct input to the hash
function. A
canonicalization step is needed because all of these addresses are
equivalent:

(1) [email-masked]
(2) first . last @example.com
(3) "first.last"@example.com
(4) "\f\i\r\s\t.last"@example.com

(2) is equivalent to (1) because CWS has no semantics, (3) is equivalent
to
(1) because the enclosing quotes are not properly part of the address,
and (4)
is equivalent to (1) because quoted-pairs are semantically equivalent to
just the quoted character.
 
I believe this is the entire list, so the obvious canonicalization to
use
on the local-part portion of an address prior to hashing is:
 
(a) If the local-part is unquoted remove any whitespace (CFWS) around
"."s.
(b) Remove any enclosing double quotes.
(c) Remove any literal quoting.

2). Ned Freed wrote:

> First, there's no way to define a mapping of local-parts to a new set
of
> identifiers *without* effectively interpreting the local-part! If you
define
> the mapping as the draft currently does, implicit in that definition is
that
> local-parts are case-sensitive. And similarly, if you convert the
local-part to
> lower (or upper) case, you're now assuming the local-part is
case-insensitive.
>
> And in the case of EAI, without some sort of normalization you're
assuming that
> different UTF-8 representations of the same string of characters
correspond to
> different recipients. (Which, as Harald Alvestrand and I both pointed
out on
> the IETF list, is technically untenable and needs to be addressed. My
> suggestion was and is to specify that the same case-folding and
normalization
> algorithm used for IDNs also be employed here.)

RFC 6532 and Section 10.1 of RFC 6530 recommend using NFC Unicode
Normalization Form. (This is similar to what IDN recommends, although
there is no standard mapping there.) I think it would be reasonable for
this document to say SHOULD apply NFC before hashing.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Some (edited) comments from Ned Freed that I (mostly) agree with:

1) In Section 3:

Finally, a couple of observations about terminology are in order. The
current
text covering the hashing of local-parts begins with:
 
       The user name (the "left-hand side" of the email address, called
       the "local-part" in the mail message format definition [RFC5322]
       and the local-part in the specification for internationalized
       email [RFC6530]) is encoded in UTF-8 (or its subset ASCII).  If
       the local-part is written in another encoding it MUST be
converted
       to UTF-8.
 
First, the left hand side of an email address is not a "user name" and
should
not be referred to as such. (The entire address is in some cases a "user
name"
of sorts, and in some cases the local-part is identical to some kind of
login
credential. But neither of these are universally true, and more to the
point,
none of this is relevant to the matter at hand.)

Second, it probably makes sense to note that local-part is an ABNF
production contained in a broader syntax, not just a name.

Third, the term "encoding" here is inaccurate; it should be "charset".

2) Ned Freed wrote:

> So when a domain owner publishes such records in the DNS, a reasonable
way to
> look at it is that they are effectively saying, "Everyone is allowed
to
> interpret the local-parts of our addresses as specified in this
document in
> this one narrow context." I'm pretty confident there's nothing in any
standard
> that forbids such a delegation of authority.
>
> And once you realize this is what is going on, not only does it become
clear
> that this draft is *not* violating the longstanding rules about
local-part
> interpretation, it casts the decision not to normalize the local-parts
to lower
> (or upper) case in an entirely different light. By choosing not to
normalize
> this specification is effectively restricting its own applicability to
domains
> with case-sensitive local parts. That is, IMO, a highly suboptimal
choice - the
> overwhelming majority of domains treat the local part in a
case-insensitive
> fashion, and so should the mechanism specified in this draft.
>
> Or, to put this another way, the inherent limitations of using the DNS
to
> provide the mapping from address to PGP key restricts the domain of
> applicability of this specification to domains with particular
local-part
> policies, and the way in which the local-part to DNS mapping is
specified
> determines which policies the specification supports. And while it
seems
> logical to support a policy that's known to be in wide use, the
specification
> also needs to be very clear that domains that employ case-sensitive
local-parts
> MUST NOT avail themselves of this mechanism.

I don't think I agree on "MUST NOT" here, because I think an email owner
can publish the preferred form (which can be lowercased) or even multiple
common forms of the email address. E.g. I can publish DNS records for
[email-masked], [email-masked] and
[email-masked], but not others.

> What needs to happen here is that the specification be revised to make
it clear
> that this is what is going on: That by publishing such records a domain
is
> granting a limited right to interpret the local parts of its
addresses.

I agree with this. A sentence or two on this would suffice.

---------------

3) The following issues/comments/questions were reported earlier:

5.1.  Obtaining an OpenPGP key for a specific email address

   If no OpenPGP public keys are known for an email address, an
   OPENPGPKEY DNS lookup MAY be performed to seek the OpenPGP public key
   that corresponds to that email address.  This public key can then be
   used to verify a received signed message or can be used to send out
   an encrypted email message.  An application whose attempt fails to
   retrieve a DNSSEC verified OPENPGPKEY RR from the DNS should remember
   that failure for some time to avoid sending out a DNS request for
   each email message the application is sending out; such DNS requests
   constitute a privacy leak

Should the document give a specific recommendation about "remember for
some time"? Is it tied to TTL for the corresponding RR?
If you can provide some additional text explaining what is reasonable (or
not) here, that would improve the specification.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Apr 2016 16:05:50 -0400

> https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/

I have addressed most issues and incorporated most suggestions. See below for the two issues left.

https://tools.ietf.org/rfcdiff?url2=draft-ietf-dane-openpgpkey-10.txt

> (c) Remove any literal quoting.

I have added this to the document.

> this document to say SHOULD apply NFC before hashing.

I have added this to the document.

This has been changed to use local-part instead of user name.

> production contained in a broader syntax, not just a name.

See above. text was changed.

> Third, the term "encoding" here is inaccurate; it should be "charset".

Fixed.

>> this on e narrow context." I'm pretty confident there's nothing in any
> standard

The problem with putting any text into the document regarding case is that a few people in the working group
deemed that mentioning the case issue would only lead implementations to "illegally" lowercase it. I was
explicitly prevented from adding any text about lowercase/uppercase. What you are asking me to do here,
is exactly that - introduce text to mention the lowercase problem.

I do believe it is only logical to lowercase and that case-sensitive local-parts do not effectively exist on
the internet. This can further be seen by the references implemention section that lists only software that
performs this "illegal" lowercase.

I will need guidance from the IESG on how to proceed. If we do not add lowercasing as a step before hashing,
please let me know what text should be added where, so that I do not run into new objections within the working group.

> I agree with this. A sentence or two on this would suffice.

Can the IESG please provide the text and location for this, as some in the working group are loudly opposed to any such text.

I do not think the TTL should be used here for key management. The TTL relates to the DNS transport and caching only.

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Apr 2016 21:10:04 +0100

Thanks Paul for the really speedy response.

I'll raise the outstanding points on the IESG telechat and respond
after the IESG has discussed those. (Alexey and/or other ADs might
choose to also respond in the meantime which is also fine.)

Cheers,
S.

On 19/04/16 21:05, Paul Wouters wrote:
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 20 Apr 2016 12:04:25 +0100

Hi Paul,
A very quick reply, as I am travelling. I will do a longer version later:

> On 19 Apr 2016, at 21:05, Paul Wouters <[email-masked]> wrote:
> 

I will suggest some text.

I think we shouldn't add text about unconditional lower casing, but instead we should acknowledge that some systems are case sensitive (I think MTA from my employer can be like that when gatewaying to other email systems) and some are not.
> Can the IESG please provide the text and location for this, as some in the working group are loudly opposed to any such text.

Considering that this proposal came from an email expert, I don't think it would be controversial. (Earlier objection were from email experts.) But maybe I am optimistic.

I will suggest some text.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 20 Apr 2016 13:01:01 +0100

Hi Paul,

> I do not think the TTL should be used here for key management. The TTL relates to the DNS transport and caching only.

That is fine, but you don't say that one way or another. My concern is that the document doesn't provide any specific details here on what is reasonable and what is not. Even putting a specific number here (if you think you can) would be better, IMHO.

Best Regards,
Alexey

---

From: Warren Kumari <[email-masked]>
Date: Wed, 20 Apr 2016 21:59:49 +0000

On Wed, Apr 20, 2016 at 7:02 AM Alexey Melnikov <[email-masked]>
wrote:

> > please let me know what text should be added where, so that I do not run
> into new objections within the working group.
>

Thank you!

>
> I think we shouldn't add text about unconditional lower casing, but
> instead we should acknowledge that some systems are case sensitive (I think
> MTA from my employer can be like that when gatewaying to other email
> systems) and some are not.
> >
> > Can the IESG please provide the text and location for this, as some in
> the working group are loudly opposed to any such text.
>
> Considering that this proposal came from an email expert, I don't think it
> would be controversial. (Earlier objection were from email experts.) But
> maybe I am optimistic.
>

I suspect you are being optimistic, but hopefully correctly so :-P
W

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 27 Apr 2016 14:31:15 +0100

Hi Paul,

> Hi Paul,

 [snip]

> Considering that this proposal came from an email expert, I don't think
> it would be controversial. (Earlier objection were from email experts.)
> But maybe I am optimistic.
> 

After thinking more about this: as the document [correctly] prohibits
any modifications of local-parts, the OPENPGP RRs don't really provide
any information on whether a particular domain supports case-sensitive
or case-insensitive local-parts (or any other variants a la Gmail). So I
think leaving existing text "as is" is fine.

I will separately suggest text to address other comments.