Subject: [dane] Alexey Melnikov's No Record on draft-ietf-dane-openpgpkey-08: (with COMMENT)

From: "Alexey Melnikov" <[email-masked]>
Date: Sun, 10 Apr 2016 08:22:33 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-dane-openpgpkey-08: No Record

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/

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

I might have more comments/questions before the telechat. Here is my
initial batch:

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"?
TTL for the corresponding RR?

In section 7:

What is the difference between "an email client" and MUA?

In 7.1:

   If the DNS request for an OPENPGPKEY record returned an Indeterminate
   or Bogus answer as specified in [RFC4035], the MTA MUST NOT send the
   message and queue the plaintext message for encrypted delivery at a
   later time.  If the problem persists, the email should be returned
   via the regular bounce methods.

Is this behaviour only specific to encrypting gateways? I want to make
sure that this is not applied uncondionally to general MTAs, which don't
need to understand this specification.

In 7.2:
   If the public key for a recipient obtained from the locally stored
   sender’s public keyring differs from the recipient’s OPENPGPKEY RR,
   the MUA MUST NOT accept the message for delivery.

Minor terminology issue: It is better to say here "accept the message for
submission", because "delivery" is a recipient side operation which is
not done my MUAs, it is performed by MDAs.

In 7.5:

   The hashing of the user name in this document is not a security
   feature.

Please use "local part" instead of username here, email addresses are not
user names.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 13 Apr 2016 00:04:36 -0400 (EDT)

Thanks for the review and comments....

> TTL for the corresponding RR?

TTL advise for this RRTYPE is not different from other RRTYPEs. After
talking to implementors, they stated they have their own methods for
dealing with things like attacks using short TTLs or overly long TTLs.

> What is the difference between "an email client" and MUA?

Nothing. I can pick one of the two terms and make it consistent.

> need to understand this specification.

This document only refers to those MTA's and MUA's (or their plugins)
that implement/support this document. I am not sure what you mean with
"encrypting gateways", but it applies to all those that implement
encrypting using OPENPGPKEY records. If the DNS returns Indeterminate
or Bogus, it means the DNSSEC records are bad or mangled, or withheld
by a MITM. To prevent a downgrade to plaintext, the above process is
defined to ensure no unencrypted message is sent out.

> not done my MUAs, it is performed by MDAs.

How about:

    [...] the MUA MUST abort sending the message and seek user assistance.

> Please use "local part" instead of username here, email addresses are not

Agreed.

Paul

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 13 Apr 2016 11:05:16 +0100

Hi Paul,

> Nothing. I can pick one of the two terms and make it consistent.

Please do. You have separate sections for them, they need to be merged.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Apr 2016 11:27:31 +0100

Paul,

If you can make changes easily now, say before Friday, please feel
free to do so. Better to not make too many changes when other ADs
are reading the draft but I suspect Alexey's in early so the next
few days should be fine. It's also fine if we fix things after the
21st too, if you don't have time right now.

Cheers,
S.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 13 Apr 2016 11:05:36 -0300

> 21st too, if you don't have time right now.

Done,

- Resolve IETF LC comments from Alexey Melnikov regarding "email client"
  vs MUA and change "user name" to "local-part".

https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-openpgpkey-09

Paul