Subject: Re: [dane] [openpgp] The DANE draft

From: Paul Wouters <[email-masked]>
Date: Sat, 25 Jul 2015 08:19:04 -0400 (EDT)

On Fri, 24 Jul 2015, Werner Koch wrote:

PHB wrote:

>> 2) If people find it does not meet OpenPGP needs, they should say so and
>> have no qualms about objecting. It is much more important that there be a
>> spec people use than that the document progress quickly.

This document has not progressed "quickly". The original draft was
published in July 2013. No one is trying to rush this through.

> I was a bit disappointed by the process: I learned about the I-D too late
> and was surprised that it started out at the OpenPGP WG mailing list (2
> years ago?) with just a few messages and then continued at the DANE list
> without having notified the OpenPGP list.

This is now the fourth time I am having this discussion with you, so I
think your representation is not entirely fair. The previous discussions
ended with you saying we should not do this and stick to the CERT record
type and me stating why I disagree with that view.

>  IIRC, I send some thoughts on
> this to the GnuPG list but people told me that it is too late for
> changes to the I-D - so I gave up.

That is not a fair representation of what happened. I have told you on
the openpgpkey, on the dane list and in private emails why we do not
want to use the CERT record. It is fine to disagree with that, but the
reason for not going back to CERT have nothing to do with timing. It
is never too late to say a certain draft has no merit and should be
shot or majorly changed. I am sorry if our previous communication did
not make that clear.

> Here are some thoughts, anyway:
>
> - Why a new DNS record despite that the CERT type has PGP support for
>  9 years now (RFC-4398).
>
>  The argument for a new record is that this makes parsing easier
>  because there is no need to loop over the record's sub-types.  I do
>  not consider it a valid argument because there is a need to loop
>  anyway because there may be several DANE records for the same key.
>  Adding an extra loop over the sub-types is a non-brainer and the
>  selection logic to find the best matching record will be the same.

Using subtypes for DNS is something the DNS people in general have
concluded to be a wrong idea. As stated before, even Olafur who is one
of the authors of the CERT RRtype advised us not to use CERT (or
subtyping in general)

Additionally, because the CERT record is a meta-container record,
support for CERT is not good because to properly parse it you need
all of openpgp and all of x509 and all of what other subtypes would
be added later on. So instead of implementing CERT records partially,
many DNS implementations just did not bother with it at all.

>  The CERT record is more flexible because it also allows the use of an
>  indirect specification via fingerprint.

Which is a problem not a feature. It makes the security model very
complex. Specifying a fingerprint and a URI that could be http or https
reduces the security of the key to the strength of the fingerprint.
Did we not already ran into issues in older (v3?) keys on this issue?
Adding a level of indirection where not required does reduce the
security.

If using https, it adds back a whole trust mechanism of CA's, or it
confusingly will ignore the CAs involved in the transaction.

If the http(s) service is blocked by an attacker, it is indistinguishable from
a regular outage.

Putting the keys into DNS without indirection avoids all these problems.
I know the CERT could also store the entire certificate, but this
difference then has to be explained to the user, and that is way too
complicated. Compare:

"The user you are trying to mail has published their OpenPGP key in DNS,
  do you wish to use this key to encrypt this email?"

versus:

"The user you are trying to mail has published their OpenPGP
  key fingerprint in DNS and the key was obtained over HTTP(S) on
  anothersite.com whose certificate was validated by ACME inc. Do
   you wish to use this key to encrypt this email?"

And the additional:

"The user you are trying to mail has published their OpenPGP
  key fingerprint in DNS but the URI resource anothersite.com appears
  to be down. do you wish to postpone this email or send it
  unencrypted?"

>  GnuPG has support for such CERT records including a script to create
>  them also for about 9 years.  It is not widely used because most users
>  have no way to add records to their zone - that is the same problem
>  for DANE of course.

CERT wasn't widely used because frankly pgp is not widely used. Also,
CERT without DNSSEC makes no sense, and we are only seeing DNSSEC
protected application data being deployed recently in the last few
years only. We now see small email providers adding webgui elements
for their users to upload their pgp key to publish in DNS. So I do
believe we are seeing an uptake in "pgp keys from dns". Of course
this has no relation to the CERT vs OPENPGPKEY format question.

> - The I-D says about the local-part of the mail address:

The I-D was left unchanged at the request of the chairs. The intention
right now is to use a base32 encoding split on 60 character labels.

>      ... it is turned into lowercase and hashed using the SHA2-256
>      [RFC5754] algorithm, with the hash truncated to 28 octets ...
>
>  Lowercasing UTF-8 characters is not easy and a likely reasons for
>  interoperability problems.  It would be better to only require
>  lowercasing ASCII characters and keep characters > 127 as they are.

Yes, that was discussed on the dane list and after consultation with
internationalised email address experts, this same conclusion was
reached. I am not sure if we actually reached consensus about the
lowercase vs using a second DNS lookup for lowercase if the first
query fails to find a record. The argument here is that a client
should not "guess" that [email-masked] is the same as [email-masked],
but there does seem to be concensus that in practise these are the
same and it should be supported either through a lowercase before
base32 (for ASCII only) or be allowing the client to try both as
base32 lookups. One of the main reasons here is that virtual keyboards
and web form fields often automatically capitalise recognised names,
and otherwise we would need to add two records (Paul and paul) for
each LHS side.

> - There is no hint in the RFC on how to find a key to verify a
>  signature.  This can't be done via a mail address but requires the
>  fingerprint (or as of today the key-id).

The draft is about finding keys based on email address. It is not meant
to be the global keyserver bag for all keyids or fingerprints. If you
only have a keyid and nothing else, the DNS hierarchy cannot help you.

But perhaps the openpgp group can extend the signature format allowing
the inclusion of an ID so this could be possible in the future?

> - How shall a key be retrieved or updated after a mail account has been
>  closed?  It should be possible to verify signatures at all times.

Why should that be possible? In fact, the key could be compromised so
it might lead to the wrong actions if you verified the signature.

The OPENPGPKEY draft specifies one method of finding a key. What you
do with it, or what the lifetime of such a key or its signatures
are is completely out of scope of this key discovery mechanism.

If we want to specify those kind of usage scenarions, we can revive
the openpgpkey-usage draft document. But I fear everyone has their
own local policies on these.

>  Thus another non DNS service to keep the key available needs to be
>  setup too (e.g. a keyserver).

I disagree. If the email was sent while the mail account was still
operational with OPENPGPKEY, you should have fetched and stored the
key then. If the account is closed and you don't have a copy of the
key, than that is your problem. If you want to have some kind of
global key store for all keys ever issued, then I guess you could
look at something like "transparency" for openpgp keys. But that
is a out of scope for this document, just as me sending you a key
without any advertising on any public key server resource and
then closing my mail account is.

>  dissemination of revocation certificates.  IPGP records could be kept
>  as long as the mail address has not been re-assigned.

Again, that seems like a "transparency" issue. The issue of losing
control of your email address, and someone else generating a new key
for that email address and advertising thism, whether in DNSSEC or
on keyservers, in an attempt to get encrypted email intended for you,
is really not in scope here either. It might be in scope for the
openpgpkey-usage document, but it seems to me to be a more generic
openpgp issue, so perhaps would be better in the openpgp bis document
or elsewhere. (and of course this would be no different with CERT
records in DNS)

> - Implementation nit: The I-D states:
>
>      The lookup result MUST pass DNSSEC validation; if validation
>      reaches any state other than "Secure", the verification MUST be
>      treated as a failure.
>
>  As an implementer I see no way to do this without adding a full
>  fledged DNSSEC resolver.

There are various libraries to do this. You can look at getdns,
libunbound or various other libraries. We hope you would not write
your own dnssec validation code. If you do not want to link against
new unknown libraries you could outsource it to a separate tool, and
possibly warn the user of that. I'm happy to help you with that.

>> People have been attempting to put email address related records into the
>> DNS since the first drafts of the spec and none has taken off.
>
> That is a general problem.  You need the support from the mail
> providers.

Of course this is a big catch22. While I have been approached by a few
email providers who have or are implementing this to allow their users
to publish their openpgp keys this way, the 5 big email providers
business model relies on advertisement targetted specifically by
reading your email. So I do not expect those email providers to have
much incentives to become free binary blob relaying services.

>> I do not find the idea of relying on the DNS for my keys remotely
>> comforting and would not want to rely on such a record directly. The DNS
>> has no persistence to it. Give me the MIT keyserver any day.
>
> When intending to send a mail the first time the DNS is pretty useful
> because it creates an association between mail address and key.  Thus
> you can pick the right key and the recipient won't be annoyed by
> encrypted mails they can't decrypt because the keyservers carry several
> "faked" keys for their mail address.

Indeed. And no one is saying you should ONLY trust the DNS. In fact, no
one is saying that. The prime motivation for this document is to allow
MTAs and MUAs to encrypt emails that would otherwise be send out in the
clear by the user. In no way is it intended to replace the web of trust
or manual key verification, and I hope implementations will ensure this
point to their users.

Now, one thing I _would_ like to see from the openpgp working group, is
comments on content of the public key ring format that we should or
should not put into the OPENPGPKEY record. The draft basically refers
to the openpgp RFC, but people have wondered about some things:

- What to do when there is more than one pubkey?
- Should it be mandatory for the email address to appear as an ID
   on the key? (if yes, how to support domain wild cards)
- Should any third party signatures be allowed/encourages/discouraged?
- Should revoked keys be allowed?

One issue during deployment for all fedora developer keys was that people
do have keys that are larger than 64k and those will not fit into the
DNS. There is no easy way for tools to try and reduce the signatures
because it does not know which signatures carry more weight for the user.

Paul

---

From: Olafur Gudmundsson <[email-masked]>
Date: Sat, 25 Jul 2015 08:50:39 -0400

> On Jul 25, 2015, at 8:19 AM, Paul Wouters <[email-masked]> wrote:
> 

I want to strongly support this point, Bulk container records like CERT have been shown to be a bad idea is 
every time they get used in DNS. Lets learn from experience. 

> many DNS implementations just did not bother with it at all.

+1 

> right now is to use a base32 encoding split on 60 character labels.

Dane WG (which I co-chair) is trying to settle this issue by the end of July 
so if you have a comment please state it there. 

> the inclusion of an ID so this could be possible in the future?

As Paul says this is about connecting a one form of ID to a OPENPGP key 
this can be used as additional method. 
As a matter of fact the reason I stopped using PGP many years ago was the difficulty
in discovering someone’s else PGPkey, in particular there was no way to look up based on the
handles I had. 

> own local policies on these.

I asked the same questions and came to the following conclusion:
OPENPGP via DANE/DNSSEC verification SHOULD be done when the email is received and
that information should be stored with the message.
DNS lookup of a key via the method specified here provides a binding at particular point in time. 
For the email provider it is her choice to remove the key or revoke the key, the net effect is the same 
they key is not available for use after that action. 
How this is done is depends on the software that validates the message. 

>> setup too (e.g. a keyserver).

This is the core difference between the way Certificate world thinks and how DNS world behaves. 
DNS is and answer at particular point in time. Either the data exists or does not exist. No history at all.
Removal of OPENPGP is almost a revocation, addition is “publication”. 

> because it does not know which signatures carry more weight for the user.

Olafur

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 25 Jul 2015 12:23:12 -0400

On Sat, Jul 25, 2015 at 8:19 AM, Paul Wouters <[email-masked]> wrote:

> published in July 2013. No one is trying to rush this through

I am quite happy waiting till 2016 or 2018.

If it isn't done right its better not to publish at all.

> type and me stating why I disagree with that view.

Ummm watch your attributions, that is Werner, not me.

The DANE group has been rather ineffective in getting the constituencies
they purport to be serving to buy into their proposal.

> many DNS implementations just did not bother with it at all.

All of X509 isn't a big barrier. Took me a week, four days of that was
writing the Assinine One compiler. I am not aware of any major crypto
package that doesn't have the ability to parse X.509 certs. Werner isn't
the only person who has a PKIX package in his OpenPGP library.

Back in 1990 the idea of using OpenPGP to avoid the need to mess with
Assinine One made arguable sense. Today its a lost cause. I stopped
fighting that battle in 1995.

> complex.

No, the security model is complex because you are trying to use a vast,
aging and vaguely understood infrastructure with a byzantine administrative
model to provide security.

Failing to accept that fact is one of the many reasons people are skeptical
of this project and looking for ways to work round it.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 26 Jul 2015 04:20:52 -0400 (EDT)

On Sat, 25 Jul 2015, Phillip Hallam-Baker wrote:

> On Sat, Jul 25, 2015 at 8:56 AM, Paul Wouters <[email-masked]> wrote:
>
>       Answering phb and dkg:

[note I stated my answer was to both you and dkg, and I used traditional
  ">" and ">>" which your email client seems to have eaten, so it is
  unfortunate if that causes further confusion to a lot of people's email
  client when reading this response]

>       That's not how I see it. It is surely a discovery and distribution
>       system for keys. But it is not a policy publication mechanism.  The
>       draft (carefully) does not tell you what you can or cannot do with the
>       key. Some people tried to propose this (mostly for smime) by having
>       different prefixes for _encrypt or _sign, but this was not adopted.
> 
> Again, you don't seem to understand the spec. 'MUST USE TLS' is one of the purported benefits.

Which specification are you refering to? The OPENPGPKEY specification
does not say "MUST USE TLS".

> Key pinning to a specific key is another.

I assume you mean "key pinning to a specific user"? If so, the OpenPGP
RFC already binds the public key and the various key ID's. Any such
existing pinning is in the OpenPGP RFC. This draft does not modify
OpenPGP in any way whatsoever. It only provides a discovery mechanism
to find an openpgp key based on an email address.

> Those are security policy.

whether or not they are, they are not specified in this draft.

> I think those should be taken out of DANE but that hasn't happened yet as far as I am aware.

I don't even understand what you mean with "DANE" in this context. This
draft has nothing to do with the TLSA record which _does_ do further
security policy specification using Selectors and Usage types. This
draft specifically does not use Selectors or Usage types and leaves
all the openpgp key policies to the OpenPGP RFC options.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sun, 26 Jul 2015 05:11:02 -0400 (EDT)

> If it isn't done right its better not to publish at all.

While a worthwhile generic goal, let's do a reality check here. We are
talking about assigning a DNS RRcode for an experimental RFC for storing
RFC 4880 section 5 openpgp packet types into an RDATA field at a
predictable DNS QNAME entry.

If that takes 5 years, the IETF will be on its way to become irrelevant,
and the associated working groups will be to blame for the proliferation
of more TXT type records containing non-text content. It ignores that
many of the original DNSSEC architects meant for the DNS to be able to
securely store signed data.

> Ummm watch your attributions, that is Werner, not me.

My apologies that was not made clearer. I indeed meant to indicate I was
talking to Werner.

> The DANE group has been rather ineffective in getting the constituencies they purport to be
> serving to buy into their proposal.

Are you referring to the OPENPGPKEY document when saying "their proposal" ?

The DANE working group in general has the strange effect that it
is completely ignored when it writes documents to use DNSSEC based
Authentication (its main charter goal!) and only when documents are
getting to WGLC, do people in other areas suddenly wake up and throw on
the brakes waving their expert hats around saying that the DANE working
group cannot make any decisions about their protocol. I've heard in
hallway talks that some people felt so attacked that they basically left
the DANE working group. We had a round of PKIX people, we had a round
of email people, all coming in really late into the process. It would be
really helpful if people get involved earlier in the process.

> All of X509 isn't a big barrier.

The point is preventing needless CVE's, not adding ASN.1 parsers and
X.509 parsers where not needed. If you don't think X.509 is a problem,
then you haven't been paying attention to CVE's.

> I am not aware of any major crypto package that doesn't have the ability to parse X.509

I am not aware of any major crypto package that did not have a number of
CVE's in their X.509 code.

> . Werner isn't the only person who has a PKIX package in his OpenPGP library. 

Actually, a quick ldd on /usr/bin/gpg* shows no libraries that I know of
that do PKIX. And it would be good not to add new ones just because we
are trying to save one DNS RRTYPE code point by re-using a bad idea from
the past that is today basically unused (the CERT record).

> No, the security model is complex because you are trying to use a vast, aging and vaguely
> understood infrastructure with a byzantine administrative model to provide security.

I am not even sure what refers to what in that sentence. DNS is a set of
well maintained protocols, and RFC 4880 is solid and seeing an update
now in the newly re-chartered openpgp working group. Email addresses
in their current form while vast and old, aren't being obsoleted
any time soon and I don't think my [email-masked] address is aging.

I also find it _really_ ironic that it is not the openpgp key servers
that you are calling "vast, aging and vaguely understood infrastructure"
because if anything is a dangerous misunderstood mess that we cannot
seem to clean up, it is the current electronic garbage heap of pgp
keys we can never clean up because the owners lost their keys or
the keys were generated and uploaded by those not actually being the
real owners of those email address specified in the openpgp key id.

It is _really_ difficult to design any other method of openpgp key
distribution that would be _worse_ than the current key servers.

> Failing to accept that fact is one of the many reasons people are skeptical of this project and
> looking for ways to work round it.

And this is an actual real problem. There is no valid reason for needing
to "work around" an experimental proposal that has a significant backing
of people in the IETF, the mail community and opensource software
writers and distributions. This document is not a protocol extension
you are forced to deal even though you never wanted to. You can simply
not publish OPENPGPKEY records and remain as secure as you are today.

If there are real security issues or operational issues that this draft
might cause, then I would love to hear those. But I've spoken with the
bind implementors and others and they know how to serve big zones and big
records and know how to deal with DOS attacks. They do not see this record
as harmful. The latest suggested base32/split for QNAME was suggested to
support the issues raised by the email and online signing communities.

If you have any specific security concerns about the draft that is not
addressed in the security section, let's discuss those on the list(s)
and fix it.

Paul

---

From: Coyo <[email-masked]>
Date: Sun, 26 Jul 2015 09:38:02 -0500

Or am I fundementally misunderstanding something?

I apologize in advance if this seems like a dumb question, but I was not able to find a definitive answer.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 26 Jul 2015 15:18:11 +0000

On Sun, Jul 26, 2015 at 09:38:02AM -0500, Coyo wrote:

> [ Is running a DANE nameserver for a TLD as complex as running a CA? ]
>

In short no.  Firstly, there's no such thing as a "DANE nameserver",
rather there are nameservers authoritative for a DNSSEC signed zone
that happens to include DANE records.

Running a DNSSEC signed zone is not especially complex.

As for the DANE records, if you have so many servers that it makes
to consolidate the various TLSA records into a single trust-anchor
record, and issue the servers certificates signed by that trust
anchor, then you're running a CA, which is as complex as running
a CA (whatever that means).

If on the other hand the number of servers to manage is small
enough, or you have simplified the coordination of server certificates
with the publication of corresponding TLSA (or other DANE) records,
then it is not like running a CA, but rather like running a public
key whitepages service.

-- 
	Viktor.

---

From: Coyo <[email-masked]>
Date: Sun, 26 Jul 2015 20:21:09 -0500

On Sun, 26 Jul 2015 15:18:11 +0000

> then it is not like running a CA, but rather like running a public

Thank you, that was helpful. I greatly appreciate your wisdom.

---

From: Werner Koch <[email-masked]>
Date: Mon, 27 Jul 2015 08:49:44 +0200

> then you haven't been paying attention to CVE's.

There is a lot more X.509 code in use than OpenPGP code and thus it
might be unfair to compare CVE counts.  But sure, BER encoding along
with all bug compatibility stuff is a mess.

> that do PKIX. And it would be good not to add new ones just because we

Do it on gpgsm and dirmngr and you will find libksba [1] which provides
the X.509 and CMS parser and builder.  gpgsm does high level processing
including validation and dirmngr takes care of CRLs and OCSP.

> keys we can never clean up because the owners lost their keys or

We do not want to clean that up - there is and should be no need to ever
delete a public key from a public server.

Unfortunatly the keyservers are also the only working solution to map
mail addresses to keys/fingerprints.  This is the practical problem we
need to solve - not the public storage of the keys.

> real owners of those email address specified in the openpgp key id.

What is an "owner" of a mail address?  Definitely nothing a keyserver
has to decide.

> distribution that would be _worse_ than the current key servers.

Nope.  As I menotioned: distribution is not the problem.  Association of
mail addresses to keys is the problem because the WoT does not really
scale.

> of people in the IETF, the mail community and opensource software

Experimental? I might be confused but draft-ietf-dane-openpgpkey-03
states Standards Track and Intended Status.

Salam-Shalom,

   Werner

[1] KSBA = rot13("XFON")  // X-Five-O-Nine

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: "Wiley, Glen" <[email-masked]>
Date: Tue, 28 Jul 2015 10:52:43 +0000

It might help if you offered more specific points to your question.
Serving DANE style records for a TLD probably doesn¹t make much sense as
those records have more meaning for a SLD.  Are you asking about running a
DNSSEC capable name server or serving a signed zone?

-- 
Glen Wiley

Principal Engineer
Verisign, Inc.
(571) 230-7917

http://vbsdcon.com

A5E5 E373 3C75 5B3E 2E24
6A0F DC65 2354 9946 C63A

On 7/26/15, 10:38 AM, "Coyo" <[email-masked]> wrote:

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

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Jul 2015 13:03:07 -0500

> DNSSEC capable name server or serving a signed zone?

That was my take.

DNSSEC is a PKI, so running a signed domain is like running a CA, yes.
There are differences:

 - There's only one trust anchor for the clients (mostly), because
   DNSSEC has naming constraints in place from day one.

 - There's no CRLs and no OCSP (but stapling of DNSSEC data is possible,
   though still being nailed down [har]).

   Revocation is easy: change the keys (and wait for TTLs to pass).

   This does mean that you have to think carefully about what TTLs to
   use.

 - Enrollment and key rollover still need work, but that's kinda true
   for PKIX CAs too...

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 30 Jul 2015 22:30:03 +0200

> of the authors of the CERT RRtype advised us not to use CERT (or

Then I believe that community should attempt to move RFC 2538/4398 to
historic.  I don't believe there is sufficient consensus for doing that
-- there is good use of CERT records already, although limited.

> many DNS implementations just did not bother with it at all.

I disagree -- CERT can be implemented without understanding any of
OpenPGP or X.509, and it is implemented by DNS software already.

> CERT without DNSSEC makes no sense

This is false -- CERT makes a lot of sense without DNSSEC, as OpenPGP
keys can be verified through the web of trust.  I don't believe
comparing deployment sizes should be a deciding factor in this context,
but I disagree with your notion that OpenPGP is not widely used.

/Simon