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

["Alexey Melnikov" <[e-mail]>]

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) [e-mail]
(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
[e-mail], [e-mail] and
[e-mail], 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.