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

[Paul Wouters <[e-mail]>]

On 04/19/2016 01:42 PM, Alexey Melnikov wrote:
> 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.

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

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

I have added this to the document.


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

I have added this to the document.



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

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

> Second, it probably makes sense to note that local-part is an ABNF
> 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.

> 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 on e 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.

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.

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

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


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

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

Paul