Subject: [dnsext] OPENPGPKEY RRTYPE review - Comments period ends Aug 6th

From: Frederico A C Neves <[email-masked]>
Date: Wed, 23 Jul 2014 18:34:03 -0300

Dear Colleagues,

Bellow is a completed template requesting a new RRTYPE assignment
under the procedures of RFC6895.

This message starts a 2 weeks period for an expert review of the DNS
RRTYPE parameter allocation for OPENPGPKEY specified at:

http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00#section-2

If you have comments regarding this request please post them here
before Aug 6th 21:00 UTC.

Best Regards,
Frederico Neves

--begin 6895 template TLSA--
 A. Submission Date: 23-07-2014

 B.1 Submission Type:  [x] New RRTYPE  [ ] Modification to RRTYPE
 B.2 Kind of RR:  [x] Data RR  [ ] Meta-RR

 C. Contact Information for submitter (will be publicly posted):
    Name: Paul Wouters         Email Address: [email-masked]
    International telephone number: +1-647-896-3464
    Other contact handles: [email-masked]

 D. Motivation for the new RRTYPE application.

    Publishing RFC-4880 OpenPGP formatted keys in DNS with DNSSEC
    protection to faciliate automatic encryption of emails in
    defense against pervasive monitoring.

 E. Description of the proposed RR type.

    http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00#section-2

 F. What existing RRTYPE or RRTYPEs come closest to filling that need
    and why are they unsatisfactory?

    The CERT RRtype is the closest match. It unfortunately depends on
    subtyping, and its use in general is no longer recommended. It
    also has no human usable presentation format. Some usage types of
    CERT require external URI's which complicates the security model.
    This was discussed in the dane working group.

 G. What mnemonic is requested for the new RRTYPE (optional)?

    OPENPGPKEY

 H. Does the requested RRTYPE make use of any existing IANA registry
    or require the creation of a new IANA subregistry in DNS
    Parameters?  If so, please indicate which registry is to be used
    or created.  If a new subregistry is needed, specify the
    allocation policy for it and its initial contents.  Also include
    what the modification procedures will be.

    The RDATA part uses the key format specified in RFC-4880, which
    itself use https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtm

    This RRcode just uses the formats specified in those registries
    for its RRdata part.

 I. Does the proposal require/expect any changes in DNS
    servers/resolvers that prevent the new type from being processed
    as an unknown RRTYPE (see [RFC3597])?

    No.

 J. Comments:

    Currently, three software implementations of draft-ietf-dane-openpgpkey
    are using a private number.
--end 6895 template TLSA--

---

From: Joe Abley <[email-masked]>
Date: Wed, 23 Jul 2014 18:06:34 -0400

Hi Fred,

> before Aug 6th 21:00 UTC.

The specification seems clear, the motivation for the specification is easy to understand, and I can think of no reason not to assign the requested code-point.

Two side-comment to the authors of draft-ietf-dane-openpgpkey-00:

(1) you might consider using the phrase "owner name" in the second-last paragraph of section 3, since referring to queries and QNAMEs in the context of publishing an RRSet seems a little clumsy.

(2) given that there is already a (weak) specification for encoding an e-mail address in a domain name in 1035's description of the RNAME field of the SOA RDATA, it might be worth providing a reference to that and describing briefly why it is inadequate for this purpose. (It's clearly inadequate, and I'm not suggesting it be used; I just think the reference would be informative.)

Joe

---

From: Jay Daley <[email-masked]>
Date: Thu, 24 Jul 2014 11:08:41 +1200

The text contains this specification element:

	 3.  The string "_openpgpkey" becomes the second left-most label in
       the prepared domain name.

without any explanation (that I can see) of a) why it is needed and b) why openpgpkey has been chosen.  

The only reason I can see is to support partitioning these RRs into a separate zone but then if an admin wanted to do that they might also want to put lots more email records there and so maybe _email would be better.  But then what about other personally identifying URIs like those used in SIP endpoints?  Umm.

The rest seems like a good idea.

Jay

On 24/07/2014, at 9:34 am, Frederico A C Neves <[email-masked]> wrote:

> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840
linkedin: www.linkedin.com/in/jaydaley

---

From: Joe Abley <[email-masked]>
Date: Wed, 23 Jul 2014 19:13:01 -0400

Hi Jay,

> without any explanation (that I can see) of a) why it is needed and b) why openpgpkey has 

I have no skin in this game, but it seems to me that use of an underscore label is a reasonable way to avoid overloading a zone apex with yet another large RRType that would (if used) no doubt gleefully be abused by amplification monkeys.

Joe

---

From: Mark Andrews <[email-masked]>
Date: Thu, 24 Jul 2014 13:02:01 +1000

In message <[email-masked]>, Joe Abley writes:
> > without any explanation (that I can see) of a) why it is needed and b) why 
> openpgpkey has 
> > been chosen.
> 
> I have no skin in this game, but it seems to me that use of an underscore lab
> el is a reasonable way to avoid overloading a zone apex with yet another larg
> e RRType that would (if used) no doubt gleefully be abused by amplification m
> onkeys.

It also creates a distinct namespace for the mapped email addresses
for this purpose.  This is one thing the existing mbox encoding got
wrong.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Jay Daley <[email-masked]>
Date: Thu, 24 Jul 2014 15:10:06 +1200

> for this purpose.  This is one thing the existing mbox encoding got

I understand that.  My questions should perhaps be better put as 

- why should there be a distinct namespace for mapped email addresses?  
I see Joe has provided one reason (which doesn't appear to make sense to me since a large RRType can't be 'hidden' lower down), but my point is that there isn't a reason in the draft.

- why should that distinct namespace have a 1 to 1 link with the RR that it will contain?  
This I think is something quite novel and worth a lot more discussion.

cheers
Jay

---

From: Mark Andrews <[email-masked]>
Date: Thu, 24 Jul 2014 13:56:48 +1000

In message <[email-masked]>, Jay Daley writes
:
> >> I have no skin in this game, but it seems to me that use of an
> >> underscore label is a reasonable way to avoid overloading a zone
> >> apex with yet another large RRType that would (if used) no doubt
> >> gleefully be abused by amplification monkeys.
> >
> I see Joe has provided one reason (which doesn't appear to make sense to
> me since a large RRType can't be 'hidden' lower down), but my point is
> that there isn't a reason in the draft.

Because it it is bad to mix foo.example.net the host with [email-masked]
the email address as they are different entities.  mbox did this.
Both mapped to foo.example.net in the DNS.  This results in overloading
so you can't know which records at the name apply to which entity.  Does
a TXT record refer to foo.example.net or [email-masked]?

> This I think is something quite novel and worth a lot more discussion.

Take CERT for example.  You may have may protocols that all use
[email-masked] but each has a different CERT record.  By having
different namespace for each protocol you avoid stuffing too many
records at a node (we are still limited to 64k).  If you want to
use the same CERT for multiple services you can enter it multiple
times or use CNAME to refer to a single instance.

---

From: Jay Daley <[email-masked]>
Date: Thu, 24 Jul 2014 16:18:38 +1200

> a TXT record refer to foo.example.net or [email-masked]?

Ah I see what you mean, though the hash algorithm means it's not a straight foo to foo comparison.   By using a hash nobody gets to choose what the actual first label is, it is chosen for them by the algorithm and so there's the possibility of collision now or future.  But unless I am missing something, the chances of someone needing a host that has the same first label as a SHA2-224 hash are practically zero so I'm not sure the issue is strong enough to insist on a distinct namespace .

> times or use CNAME to refer to a single instance.

Hmm.  Still thinking about that.

cheers
Jay

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 24 Jul 2014 06:06:31 -0400

<hat dane co-chair> 

> I see Joe has provided one reason (which doesn't appear to make sense to me since a large RRType can't be 'hidden' lower down), but my point is that there isn't a reason in the draft.

Few reasons, one not to collide with regular names (unlikely in the first place) 
Secondly this allows the namespace to be delegated to the E-mail department to maintain. 
Thirdly if you do not want to have this extra label then you can just do the following
	_openpgpkey.foo.example.  DNAME foo.example. 
or 
	_openpgpkey.foo.example. DNAME _email.foo.example. 

> This I think is something quite novel and worth a lot more discussion.

Good point, namespaces are cheap, but we should think about the big picture. 
Well we also have a Smime draft that has different namespace “_smimecert” 
maybe we should think about having only one namespace for email “certs”. 

This is a discussion that probably needs bigger review than dnsext.

	Olafur

---

From: Joe Abley <[email-masked]>
Date: Thu, 24 Jul 2014 12:18:56 -0400

On 23 July 2014 at 23:10:21, Jay Daley ([email-masked]) wrote:

> I see Joe has provided one reason (which doesn't appear to make sense to me since a large  
> RRType can't be 'hidden' lower down),

I was referring to the ongoing habit of choosing an apex QNAME and using QTYPE=ANY in a reflection attack; the more stuff you load into the apex owner name, the bigger the amplifier. From that perspective the more apex-related stuff you can shift to sub-layers, the worse the amplifier, the better the Internet.

> but my point is that there isn't a reason in the draft. 

... and that is a fair point.

Joe

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 24 Jul 2014 09:38:10 -0700

> I was referring to the ongoing habit of choosing an apex QNAME and using QTYPE=ANY in a reflection attack; the more stuff you load into the apex owner name, the bigger the amplifier. From that pers…

Attackers can (and have in the past) created their own domain that serves a very cacheable, arbitrarily-large response.

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Jay Daley <[email-masked]>
Date: Fri, 25 Jul 2014 09:06:45 +1200

Hi Olafur

> This is a discussion that probably needs bigger review than dnsext.

Actually I think your DNAME example solves any issues for me.  If someone wanted to they could have

	_openpgpkey.foo.example.	DNAME	_email.foo.example.
	_smimecert.foo.example.	DNAME	_email.foo.example.

which is quite neat and hopefully makes DNAME a more common RR.

cheers
Jay

---

From: Petr Spacek <[email-masked]>
Date: Fri, 25 Jul 2014 19:22:06 +0200

Hello,

> http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00#section-2

I was asking dane-list [1] if it makes sense to publish PGP key revocation 
certificate in OPENPGPKEY. I haven't heard any reply to this idea yet (maybe 
it is too dumb idea to warrant single reply).

There is one important detail to note:
- OPENPGPKEY as proposed requires DNSSEC protection (it is public key).
- Key revocation certificate doesn't require DNSSEC because the certificate 
itself is signed.

I think it is worth considering support for key revocation certificates in DNS 
because they can be deployed even more easily and rapidly (because DNSSEC is 
not required).

The question is if it makes sense to publish both types of data using:
- Different RR type (a la OPENPGPREVOC)
- The same RR type but under different _prefix (_revoc._openpgpkey?)
- Under the same owner name and RR type, which would (I guess) require an 
additional field in OPENPGPKEY RR type

Mixing keys and revocation data in single RR set will obviously result in 
bigger replies. The question is if client should verify always verify that the 
other keys of the same user were not revoked so it could make sense to send 
him all the data in one response. (The older key could be obtained via non-DNS 
means etc.)

On the other hand, "_openpgpkey aware" clients could always check live data in 
DNS and use only keys which are present in DNS at the moment. In that case 
removing RR which represents particular key will have the same affect as key 
revocation (but only for "_openpgpkey aware" clients).

Unfortunately I will not be available for next two weeks so I'm throwing the 
idea to mailing list without any promise to reply before 2014-08-11.

[1] http://www.ietf.org/mail-archive/web/dane/current/msg06672.html

-- 
Petr Spacek  @  Red Hat

---

From: Derek Atkins <[email-masked]>
Date: Fri, 25 Jul 2014 14:10:56 -0400

Petr Spacek <[email-masked]> writes:

> I was asking dane-list [1] if it makes sense to publish PGP key
> revocation certificate in OPENPGPKEY. I haven't heard any reply to
> this idea yet (maybe it is too dumb idea to warrant single reply).
>

Note that this public key could still (theoretically) be signed.  Unless
DANE is specifying it differently there should be no limitation that it
be *just* the public key.

> - Key revocation certificate doesn't require DNSSEC because the
> certificate itself is signed.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: James Cloos <[email-masked]>
Date: Fri, 25 Jul 2014 16:12:20 -0400

>>>>> "PS" == Petr Spacek <[email-masked]> writes:

PS> I was asking dane-list [1] if it makes sense to publish PGP key
PS> revocation certificate in OPENPGPKEY. I haven't heard any reply to
PS> this idea yet (maybe it is too dumb idea to warrant single reply).

I must have missed that last paragraph when I replied to the other part
of that mail.

If one is to publish openpgp keys in dns, then also publishing related
revocation certs seems reasonable.

If the querier already has a path through the WoT to the revoked key, a
revocation signed by that key indeed does not need a dnssec trust path,
too.  But if the querier does not have a WoT path, they would benefit
from the dnssec path.

So as you wrote a signed revocation is useful even w/o dnssec, but
dnssec does benefit some.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: James Cloos <[email-masked]>
Date: Sun, 27 Jul 2014 18:23:11 -0400

>>>>> "DA" == Derek Atkins <[email-masked]> writes:

DA> Note that this public key could still (theoretically) be signed.  Unless
DA> DANE is specifying it differently there should be no limitation that it
DA> be *just* the public key.

That is an important point; unsigned OPENPGPKEY provides similar
benefits as using the key servers.

Part of the motivation for OPENPGPKEY was to provide an additional trust
path to the dnssec root for those who lack a existing or sufficient path
through the WoT.

(I think everyone agrees that a nice path through the WoT to a key with
ultimate trust is better, but if you WoT path is weak or non-extant than
dns can at least provide /some/ trust.)

Another aspect of the motivation is to have similar discovery paths for
openpgp and smime -- where a dns trust path is arguably more useful.

-JimC