Subject: [dane] Updated draft-ietf-dane-openpgpkey

From: Paul Wouters <[email-masked]>
Date: Wed, 1 Apr 2015 23:28:50 -0400 (EDT)

I have updated draft-ietf-dane-openpgpkey

Latest version: http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03
Diff: http://www.ietf.org/rfcdiff?url1=draft-ietf-dane-openpgpkey-02&url2=draft-ietf-dane-openpgpkey-03

Items changed:

- SHA-224 changed to SHA-256 truncated at 28 octets. It was indicated
   that SHA224 is the black sheep of the SHA2 (FIPS) family and is
   also not part of the Microsoft CryptoAPI. [various people including
   Stephen Farrell and Sean Leonard]

- Clarify the local part should be in UTF-8/ASCII encoding [Wil Tan]

- Lowercase before hash - as there seems to be consensus that all email
   servers in real life deployments do not have different mailboxes for
   different case ([email-masked] vs [email-masked]). This avoids the
   most common problem of webforms and phone virtual keyboards automatically
   capitalizing the first letter of a recognised name. [based on John
   Levine's input]

- Forbid any other kind of attempt at guessing or rewriting the local-part
   [based on the many people present at the Dallas DANE meeting]

- Added a section more clearly documenting the usage of OPENPGPKEY and
   updating the Introduction section [result of discussion with Paul Hoffman]

- Do not allow replacing/adding local key stores without user
   confirmation [Pieter Lexis]

- Do not cache the record beyond its TTL [Pieter Lexis]

- Point to the OpenPGP key ring section within the RFC, instead of just
   the RFC [based on feedback from Petr Spacek]

---

From: Christian Rößner <[email-masked]>
Date: Thu, 2 Apr 2015 15:40:18 +0200

Hi,

>  Stephen Farrell and Sean Leonard]

Is this also an option for SMIMEA draft?

>  capitalizing the first letter of a recognised name. [based on John

And is this also an option for the SMIMEA draft?

Christian
--
Bachelor of Science Informatik
Erlenwiese 14, 36304 Alsfeld
T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345
USt-IdNr.: DE225643613, http://www.roessner-network-solutions.com

---

From: Paul Wouters <[email-masked]>
Date: Thu, 2 Apr 2015 10:03:02 -0400 (EDT)

> And is this also an option for the SMIMEA draft?

We're trying to keep the location the same with the two drafts, so if
people are okay with it for openpgpkey, I assume the smime draft will
follow.

Paul

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 2 Apr 2015 10:23:39 -0400

<chair-hat on> 
The drafts will be advanced with the same lookup mechanism. 
The process is defined in OPENPGP draft, the SMIME draft will follow OPENPGP lead in email address “transformation”. 

Olafur

> On Apr 2, 2015, at 9:40 AM, Christian Rößner <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 2 Apr 2015 15:08:41 +0000

> The process is defined in OPENPGP draft, the SMIME draft will follow OPENPGP lead in email address “transformation”. 

Hey all,

As a clarifying side comment (to the hashing algo): there is still some interest in having _encr and _sign labels in the SMIMEA RR’s lookup name.  imho, this can offer a lot of benefits in managing user preference when looking up the association between a mailbox and crypto material.  I only mention that because I think this could be seen as part of the ``lookup mechanism.’’

libsmaug uses these labels (as well as our soon-to-be available provisioning portal).

Eric

---

From: Christian Rößner <[email-masked]>
Date: Thu, 2 Apr 2015 18:52:33 +0200

> Am 02.04.2015 um 17:08 schrieb Osterweil, Eric <[email-masked]>:
> 
> 

Just a question for ._encr and ._sign:

Do you really plan to store private keys in public DNS? Is it, what ._sign will be used for? Isn’t this really a security issue?

I am not a DNS expert, but isn’t it possible to walk through a DNS zone using NSEC and get all records of a zone and therefor you also would get all private keys in the subdomain ._sign?

I personally only would store public keys in DNS for opportunistic encryption. Therefor I would not see a need for an extra subdomain ._encr (and of course not ._sign)

Christian

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Apr 2015 17:12:41 +0000

On Thu, Apr 02, 2015 at 06:52:33PM +0200, Christian R??ner wrote:

> Do you really plan to store private keys in public DNS? Is it, what ._sign will be used for? Isn?t this really a security issue?

No they are public keys in both cases.  Some public keys are for
signing only, others are for encryption (which means that they can
receive encrypted content).

The idea that these need separate locations in DNS has not seen
much support on this list.  In consumer deployments, I don't see
such separation as likely to take place.

In enterprise deployments, I expect implementations will publish
gateway keys that decrypt the email, apply various content policies,
and then sometimes deliver re-encrypted content to the end-user,
but using keys that the outside world does not see.

-- 
	Viktor.

To be honest, I don't expect encrypted messages in the mailbox to
ever be very popular, encrypted storage is just too inconvenient
for most users.  End-to-end is good for live conversations, but
not so well suited to archived communication.  We can try to make
it more usable for those willing to put up with the inconvenience,
but I would not really expect large-scale adoption.

That's a personal best guess of course, I am willing to be proved
wrong.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 2 Apr 2015 13:24:29 -0400 (EDT)

> but using keys that the outside world does not see.

Also, the smime key attributes will tell if if they are usable for
signing and/or encrypting. So my preference is to not have another
place to indicate this so we avoid needing to deal with mismatches.

> for most users.

Having run openpgpkey-milter and gotten all of my email encrypted
due to my own forwarder, I strongly agree with that it is completely
inconvenient right now. But it is a problem that we need to solve to
make it convenient. I'm hoping that encrypting more email will mean
more people will work on better MUA integration of it. We really
need to fix this problem.

> End-to-end is good for live conversations, but
> not so well suited to archived communication.

I personally would like my MUA to store email decrypted, replace the
encrypted email headers inside the body back into real email headers
and rely on full disk encryption. That way, I get the best of both
worlds.

Paul

---

From: Christian Rößner <[email-masked]>
Date: Thu, 2 Apr 2015 19:29:21 +0200

> Am 02.04.2015 um 19:12 schrieb Viktor Dukhovni <[email-masked]>:
> 

Ok, seems I have to learn a lot more about security. I always thought that a pair of keys consist of one public key and one private key and that the public key is distributed for those who want to encrypt mail and that the private key is used for decryption. At the other hand using that private key for signing mails and giving others the chance to verify with the published public key. Is that wrong thinking?

I never knew that you can use a public key for signing. Or at least I never tried.

Sorry, if I ask :-)

Christian

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Apr 2015 17:33:42 +0000

> I never knew that you can use a public key for signing. Or at least I never tried.

Your initial thinking was right, the private key is used for signing,
but the public key is published so that verifiers can validate the
signature.  The proposal is to publish verification (public) keys
(that validate received mail) separately from encryption (public)
keys that enable encryption of outgoing mail.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 2 Apr 2015 13:43:21 -0400 (EDT)

> keys that enable encryption of outgoing mail.

Right, and:

for email signing):
- must have the Digital Signature or Non-Repudiation OID’s as a Key Usage.

(for email encryption):
-  must have the Key Agreement or Data Encipherment OID’s as a Key Usage.

So why add the dns complexity for _sign and _encrypt. While it is nice
that you can skip fetching an smime cert if you need to sign but the you
cannot find it at the _sign prefix, once you have the cert and then you
need to encrypt, you either need to repeat a DNS lookup for a cert you
already have or you need to store the "sign" or "encrypt" flags, meaning
you will want to do two lookups always even if you only want to sign or
encrypt now. And then you still need to check for conflicts within the
smime certificate's OID.

When you drink the X.509 kool-aid, you have to play by its rules, which
means full PKIX validation of the EKU.

Paul

---

From: Christian Rößner <[email-masked]>
Date: Thu, 2 Apr 2015 19:50:20 +0200

> Am 02.04.2015 um 19:33 schrieb Viktor Dukhovni <[email-masked]>:
> 

Thanks. But in that case I don’t really get the use case of ._encr and ._sign, as I can not believe that people would distribute different keys for signing and encrypting mails (in the sense you described)

If I have a pair of public/private keys, I would expect that a sender does not use a second private key just for signing and that you would require a second public the public key for verification. Das that scenario really exist?

Or is it more of a theoretical nature with these two subdomains? Just my personal opinion, if I may say it: I would vote against two different subdomains.

Christian

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 2 Apr 2015 17:55:37 +0000

>> Do you really plan to store private keys in public DNS? Is it, what ._sign will be used for? Isn?t this really a security issue?

<snip>

> but I would not really expect large-scale adoption.

Actually, we’re seeing a lot of renewed interest in this.  Issues ranging from the Sony incident, to APT threats in networks have seemed to be very motivating to a number of people in the security space.  I think we all ought to be very worried about our data when it's at rest (i.e. controlling where and when our data/email/etc is encrypted, by whom, etc.).

> That's a personal best guess of course, I am willing to be proved

We’ve been trying to validate with industry and are seeing the opposite, but I’m certain ymmv.

Eric

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 2 Apr 2015 18:00:54 +0000

> place to indicate this so we avoid needing to deal with mismatches.

I think this was better described by Doug M before, and you and I spoke about this at the interim meeting, but to rehash: my certs may be used for any number of actions (like the USG PIV cards), but I may not want them to be used arbitrarily for different services (like all manner of email).  I may also have a cert that I want to no longer use for email, but I do _not_ want to revoke it.  I may want to use a cert (whose attributes are very permissive) for just email signing.  I can codify my wishes by not listing it as an encryption key in DNS.

> need to fix this problem.

I’m aware of a lot of enterprise interest in encrypted email at rest.

> and rely on full disk encryption. That way, I get the best of both

I actually favor the encrypted email for the afore mentioned reasons.  At the very least, it seems fair to consider giving the user the option.

Eric

---

From: Paul Wouters <[email-masked]>
Date: Thu, 2 Apr 2015 14:15:34 -0400 (EDT)

On Thu, 2 Apr 2015, Paul Wouters wrote:

> Right, and:
>
> for email signing):
> - must have the Digital Signature or Non-Repudiation OID?s as a Key Usage.
>
> (for email encryption):
> -  must have the Key Agreement or Data Encipherment OID?s as a Key Usage.
>
> So why add the dns complexity for _sign and _encrypt.

Additionally, using the DNS prefix leaks the intent of the user. The DNS
servers should not know whether or not a user is going to sign or
encrypt.

Paul

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 2 Apr 2015 18:27:37 +0000

> servers should not know whether or not a user is going to sign or

I think that’s a red hearing.  Either the user is worried about this, and we have the whole learning intent through DNS lookups (in which case I refer to an email I sent earlier today, which proposes to use URIs in SMIMEA certs at the apex of a zone), or not.  In any event, I really can’t understand where there is clear gain to an adversary in knowing encr/sign over just the transmission of email, when the real protection in the crypto being used _after_ keys are learned?   By contrast, we get a lot of management and configurability gains by giving users these hooks.

Eric

---

From: Paul Wouters <[email-masked]>
Date: Thu, 2 Apr 2015 14:40:47 -0400 (EDT)

> I think this was better described by Doug M before, and you and I spoke about this at the interim meeting, but to rehash: my certs may be used for any number of actions (like the USG PIV cards), bu…

Well, this is SMIME and it uses PKIX, so the proper way to express any
kind of attributes is via EKU OIDs.

> I actually favor the encrypted email for the afore mentioned reasons.  At the very least, it seems fair to consider giving the user the option.

The MUA can implement either. But I can tell you that it is next to
impossible to search through old encrypted emails. I often search
through old email, so I have a clear preference for storing it in
decrypted form accessable to my MUA, all of it protected by whole
disk encryption. But that's all a MUA based local/user policy
decision and we don't have to indicate any of this in DNS.

Paul

---

From: Doug Montgomery <[email-masked]>
Date: Mon, 6 Apr 2015 08:46:18 -0400

On Thu, Apr 2, 2015 at 2:40 PM, Paul Wouters <[email-masked]> wrote:

>> I think this was better described by Doug M before, and you and I spoke
>> about this at the interim meeting, but to rehash: my certs may be used for
>> any number of actions (like the USG PIV cards), but I may not want them to
>> be used arbitrarily for different services (like all manner of email).  I
>> may also have a cert that I want to no longer use for email, but I do _not_
>> want to revoke it.  I may want to use a cert (whose attributes are very
>> permissive) for just email signing.  I can codify my wishes by not listing
>> it as an encryption key in DNS.
>>
>

Part of the issue here is that we have large enterprise identity management
systems that issue credentials for security functions, but independent of
application.  So while the EKU bits say that a CERT is useful for
encryption, it does not say if that is for file encryption, disk
encryption, or email encryption.

Thus the EKU bits may not be enough to understand if the domain in question
supports/allows encrypted email or not.   DANE/SMIMEA offers the potential
to clearly express / control key usage per service and at the domain level.
  Both of which are not controllable, and/or, are out of scope of the
business processes and regulations that control the creation of the actual
certificates.

Enterprise identity management systems, business process, and the laws and
policies that govern them are the long pole in the tent here.  At least on
the enterprise side, we are not talking about an individual getting a $5
CERT or running ssh-keygen.

>> I actually favor the encrypted email for the afore mentioned reasons.  At
>> the very least, it seems fair to consider giving the user the option.
>>
>

+1

Having seen the awkward and complex machinery that exists to allow users to
recover their decade old encryption keys so as to read an old email in
their inbox, I personally think the idea of storing encrypted email
encrypted by the original key both useless and misguided / misleading.
After delivery to the end user it offers no security service to the
original sender as I could have done anything with the decrypted message.

The only sane way to do this is to store in local encrypted file store that
presumably is actively managed in terms of keying material.

> Paul

dougm

-- 
DougM at Work

---

From: Paul Wouters <[email-masked]>
Date: Mon, 6 Apr 2015 12:08:21 -0400 (EDT)

On Mon, 6 Apr 2015, Doug Montgomery wrote:

> Part of the issue here is that we have large enterprise identity management systems that issue
> credentials for security functions, but independent of application.  So while the EKU bits say
> that a CERT is useful for encryption, it does not say if that is for file encryption, disk
> Thus the EKU bits may not be enough to understand if the domain in question supports/allows
> encrypted email or not.

Do we need the PKIX/SMIME people to write a document to express these?
This really seems to be in their domain, and using the DNS to work
around not having the right EKUs seems wrong to me.

>  DANE/SMIMEA offers the potential to clearly express / control key
> usage per service and at the domain level.

The DANE working group sees regular invasions of other IETF areas
whenever that area feels the DNS is trespassing on their domain. I'd
prefer not to see another wave.

And additionally, I do think it matters that we leak key usage intent
into the DNS - especially in the current architecture of a few big
resolvers like google dns and opendns seeing many of the queries.

> Enterprise identity management systems, business process, and the laws and policies that govern
> them are the long pole in the tent here.  At least on the enterprise side, we are not talking
> about an individual getting a $5 CERT or running ssh-keygen.   

i would expect the enterprise to have a lot more control on the EKU's in
the certificates they hand out to their employees than I would have
ordering my $5 certificate online from an SMIME CA.

Paul

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 6 Apr 2015 10:18:35 -0700

> -----Original Message-----
> From: dane [mailto:[email-masked]] On Behalf Of Paul Wouters
> Sent: Monday, April 06, 2015 9:08 AM
> To: Doug Montgomery
> Cc: [email-masked]
> Subject: Re: [dane] Updated draft-ietf-dane-openpgpkey
> 
> > Part of the issue here is that we have large enterprise identity
> > management systems that issue credentials for security functions, but
> > independent of application.  So while the EKU bits say that a CERT is
> > useful for encryption, it does not say if that is for file encryption,
> > disk encryption, or email encryption.
> >
> > Thus the EKU bits may not be enough to understand if the domain in
> > question supports/allows encrypted email or not.
> 
> This really seems to be in their domain, and using the DNS to work around not
> having the right EKUs seems wrong to me.

 I have been doing my best to ignore this thread, but I guess I cannot any more.

Firstly.  EKU is not the correct way to deal with what type of key is in a certificate.  EKU is used to say this is an SMIME only certificate (and I don't believe without looking that this was ever done).  Key Usage (KU) is used to say this is a signing key or this is an encryption key (by restricting the usages).  Yes EKU could say that a certificate is used for a specific type of encryption, however that should not be an issue here as only those targeted for S/MIME should be published in the directory.  

NONE OF THESE VALUES CAN BE CHANGED by the user after the certificate has been issued.  This means that there is nothing that can be done to say - Oh, I have this encryption certificate that is being published but I don't want you to use it.  I want you to use a different one.  In this case you just stop publishing the first certificate - no problems as long as the second is published at the same time.

One can continue to publish signing certificates long after one has stopped using the matching key to perform signature operations.  There is more of a problem with a validator that cannot deal with the fact that you have the same public key in two certificates, however good practice says that an EE should not do this.

There is nothing that the PKIX/SMIME people should need to write to deal with any of these issues.

> The DANE working group sees regular invasions of other IETF areas whenever
> that area feels the DNS is trespassing on their domain. I'd prefer not to see
> another wave.
> 
> And additionally, I do think it matters that we leak key usage intent into the
> DNS - especially in the current architecture of a few big resolvers like google
> dns and opendns seeing many of the queries.

This I completely agree with.  If one is using certificates, that information is totally public.

Jim

> 
> > Enterprise identity management systems, business process, and the laws
> > and policies that govern them are the long pole in the tent here.  At
> > least on the enterprise side, we are not talking about an individual
> > getting a $5 CERT or running ssh-keygen.
> 
> i would expect the enterprise to have a lot more control on the EKU's in the
> certificates they hand out to their employees than I would have ordering my
> $5 certificate online from an SMIME CA.
> 
> Paul
>

---

From: Christian Rößner <[email-masked]>
Date: Mon, 6 Apr 2015 21:46:20 +0200

> Am 06.04.2015 um 19:18 schrieb Jim Schaad <[email-masked]>:
> 
> 
> 

For S/MIME (SMIMEA), if you publish your S/MIME DER cert in DNS (1 0 0 or 3 0 0), I think you must check for keyUsage to make sure that the certificate was issued for this use case. You will have to check this on encryption software (not sure for signing software). It doesn’t matter, if the certificate was already issued and the user can not change things anymore, but the software that retrieves a certificate from DNS still can validate (and in my opinion MUST validate) certain things. Not only keyUsage, also not before and not after date validity). So every software MUST do sanity checks.

Sorry, if I should have misunderstood you :-)

Christian

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 6 Apr 2015 13:08:48 -0700

> From: Christian Rößner [mailto:[email-masked]]
> Sent: Monday, April 06, 2015 12:46 PM
> To: Jim Schaad
> Cc: Paul Wouters; Doug Montgomery; [email-masked]
> >>> management systems that issue credentials for security functions,
> >>> but independent of application.  So while the EKU bits say that a
> >>> CERT is useful for encryption, it does not say if that is for file
> >>> encryption, disk encryption, or email encryption.
> >>>
> > Firstly.  EKU is not the correct way to deal with what type of key is in a
> certificate.  EKU is used to say this is an SMIME only certificate (and I don't
> believe without looking that this was ever done).  Key Usage (KU) is used to
> say this is a signing key or this is an encryption key (by restricting the usages).
> Yes EKU could say that a certificate is used for a specific type of encryption,
> however that should not be an issue here as only those targeted for S/MIME
> should be published in the directory.
> >
> > NONE OF THESE VALUES CAN BE CHANGED by the user after the certificate
> has been issued.  This means that there is nothing that can be done to say -
> Oh, I have this encryption certificate that is being published but I don't want
> you to use it.  I want you to use a different one.  In this case you just stop
> publishing the first certificate - no problems as long as the second is published
> at the same time.
> >
> > One can continue to publish signing certificates long after one has stopped
> using the matching key to perform signature operations.  There is more of a
> problem with a validator that cannot deal with the fact that you have the same
> public key in two certificates, however good practice says that an EE should
> not do this.
> >
> For S/MIME (SMIMEA), if you publish your S/MIME DER cert in DNS (1 0 0 or 3
> 0 0), I think you must check for keyUsage to make sure that the certificate was
> issued for this use case. You will have to check this on encryption software
> (not sure for signing software). It doesn’t matter, if the certificate was already
> issued and the user can not change things anymore, but the software that
> retrieves a certificate from DNS still can validate (and in my opinion MUST
> validate) certain things. Not only keyUsage, also not before and not after date
> validity). So every software MUST do sanity checks.

Complete and total agreement on this.  I was responding to the fact that people seemed to be wanting to change this information to control things when publishing this information in the SMIMEA records.

Jim

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 6 Apr 2015 21:49:13 +0000

> encryption, or email encryption.

Public keys in the form of certificates can be obtained by MUAs
from a variety of sources.  For example, they may be obtained and
cached from a signed email.  If the key usa supports encryption,
the MUA may attempt to encrypt email replies to the sender.

It seems odd to communicate the requisite key usage information
via DANE records but fail to communicate it via other channels.

So I would suggest that the usage bits be in the certificate, 
regardless of transport.

-- 
	Viktor.