Subject: [pkix] Key lookup service via draft-bhjl-x509-srv-00

From: Wei Chuang <[email-masked]>
Date: Tue, 22 Mar 2016 11:42:02 -0700

(was from: why you shouldn't even try to canonicalize local parts)

On Sun, Mar 13, 2016 at 1:25 PM, John Levine <[email-masked]> wrote:
>
>
> If you're going to do local signing, the reasonable way to publish the
> signing cert is with DNSSEC as I suggest in draft-bhjl-x509-srv-00
> section 5.
>

I think this draft (draft-bhjl-x509-srv-00
<https://tools.ietf.org/html/draft-bhjl-x509-srv-00>) very usefully defines
a means to lookup certificates for S/MIME users, and wonder if we could
discuss this.  As far as I can tell it hasn't been discussed else where.  I
also don't know if there are other similar proposals, and if a comparison
between this and other approaches has been done.  This or some other key
lookup service would be very helpful in enabling email message based
encryption/authentication.

The draft proposes a new DNS SRV record that defines a URL to lookup
certificate (both PKIX and PGP) over HTTPS for email.  As a key lookup
service this proposal resolves the barrier of an initial key lookup i.e.
given an email address for a person the sender has never corresponded with,
can provide a means to get their certificate.  Currently initial
conversations must happen in cleartext until the certificates are
exchanged.  Also as the author points out, this service can also provides a
means to potentially resolve potentially different email addresses for the
same user i.e. resolving capitalization differences or addresses with
subaddressing.  The draft proposes using DNSSEC to  authenticates and
protects the integrity of the the SRV record.

The draft is pretty complete but some of the description could be
expanded.  It doesn't define define behavior when the certificate is
missing or invalid.  Presumably some sort of HTTP error code?  What should
be the response when the key server is aware that the certificate has been
revoked, and there is no replacement?  The draft specifies that if multiple
certificates are returned, that they are embedded in a mime/multipart
format.  It may be useful to always return in this format even for a single
certificate.  The multipart format likely was to allow for multiple entity
certificates to be returned.  In another discussion it was mentioned
providing the full certificate chain to the trust anchor certificate would
be very helpful for interoperability as not everyone may have access to the
CA certificates.  Providing further structure via content-description could
allow for embedding full chains with multiple entity certificates.

The set of related things outside the main scope of the draft.  A tricky
problem with key lookup has been privacy.  The worry is that spammers or
phishers would try to use such a key discovery service to find more
victims.  Understandably the authors may want to keep the scope narrow but
ideas would certainly be welcome.  Another worry is that the security of
this proposal is based on DNSSEC which is only very slowly being deployed
and many clients may not be able to interoperate with that.  One purely
PKIX based trust solution may be to adapt the mechanism that Margolis used
in draft-margolis-smtp-sts-00
<https://tools.ietf.org/html/draft-margolis-smtp-sts-00> to mirror the SRV
record on an HTTPS served page as an intermediate step.

-Wei

---

From: "John R Levine" <[email-masked]>
Date: 22 Mar 2016 16:38:18 -0400

> discuss this.  As far as I can tell it hasn't been discussed else where.

We offered it to DANE, but it appears that DANE is rapidly winding down so 
PKIX seems as good a place as any.

> I also don't know if there are other similar proposals, and if a comparison

> certificate (both PKIX and PGP) over HTTPS for email.

Actually, they're not new, all straight out of RFC 4387.  This draft is 
mostly a profile of 4387, which offers multiple ways to do stuff, choosing 
one option from each set so it's easier to interoperate.

> missing or invalid.  Presumably some sort of HTTP error code?

RFC 4387 says to use normal http error codes.  If there's no such 
certificate that would be the familiar 404 code.  I suppose we could say 
that but I'd prefer not to repeat material from other specs.

> What should be the response when the key server is aware that the 
> certificate has been revoked, and there is no replacement?

I'd think it's 404, no cert for you, or maybe 410 Gone.

> victims.

Having been in the mail business for decades, I'm not worried about it. 
Bad guys already have more addresses than they know what to do with, and 
there are easier ways to scrape addresses than guessing one address 
per URL.  We've had PGP key servers forever and bad guys don't seem to 
find them attractive.

> Another worry is that the security of this proposal is based on DNSSEC 
> which is only very slowly being deployed and many clients may not be 
> able to interoperate with that.

Not really.  The keys deliberately are *not* automatically authoritative 
so it's not a privacy crisis if someone inserts a fake server.  Clients 
need to apply local policy to decide whether to trust them, just like you 
would for keys from traditional PGP key servers or anywhere else.

The only thing that depends on DNSSEC for trust is the new option for a 
domain to publish a S/MIME signing key for its users' keys.  Lacking 
DNSSEC, the traditional CA PKI is still there.

R's,
John

---

From: Wei Chuang <[email-masked]>
Date: Wed, 23 Mar 2016 11:26:52 -0700

Thanks for the explanation.

On Tue, Mar 22, 2016 at 1:38 PM, John R Levine <[email-masked]> wrote:

>> which is only very slowly being deployed and many clients may not be able
>> to interoperate with that.
>>
>

I think the benefits of an authoritative server out weighs the worries that
you suggest.  In the web world, its been very helpful to be certain what
one should chain up via browser certificate pinning or HPKP.  A whole host
of malfeasance was found this way.  Even in the limited use that S/MIME has
today, in government and defense, its likely to be very useful.

> DNSSEC, the traditional CA PKI is still there.
There some risk in authenticating via email CA PKI.   What use of S/MIME
there is suggests a fair amount of domain private issued or self issued
certificates and consequently S/MIME MUAs often make it easy to add these
private trust anchors.  Due to human factors that we've often read about,
its would not be difficult to convince users to accept a fraudulent
certificate and trust anchor, and thereby lessens the strength of email CA
PKI and its ability to effectively distinguish a fake key server.

-Wei

---

From: "John R Levine" <[email-masked]>
Date: 23 Mar 2016 14:33:12 -0400

>> DNSSEC, the traditional CA PKI is still there.

If the WG thinks the domain's key should be authoritative, that'd be fine 
with me.  We didn't want to make any unilateral changes to the trust model 
without it being clear that it's a change and that there's consensus 
behind it.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 23 Mar 2016 20:00:09 +0000

>without it being clear that it's a change and that there's consensus 

So an authoritative service makes sense in an Enterprise context, but not in a consumer context.  How do you preserve consumer choice if Yahoo! owns their email service, but they want to certify keys elsewhere?

-- T

---

From: "John R Levine" <[email-masked]>
Date: 23 Mar 2016 16:28:41 -0400

> So an authoritative service makes sense in an Enterprise context, but not in a consumer context.  How do you preserve consumer choice if Yahoo! owns their email service, but they want to certify ke…

Welcome to the key semantics undrainable swamp of despair.

If the domain says "I'm authoritative for all my users" and one of the 
users says "no you're not", there's no mechanical way to resolve that. 
You can punt to the user, which is known not to work ("Accept domain 
self-signed key for [email-masked] gargle jargon blurch OK!") or else 
you can appeal to a credible third party.  Except the third parties are 
CAs and they're not as credible as we might wish.

This is why the draft tip-toes around the edge of the swamp, for fear of 
falling in.

Regards,

---

From: Wei Chuang <[email-masked]>
Date: Wed, 23 Mar 2016 14:29:12 -0700

On Wed, Mar 23, 2016 at 1:00 PM, Miller, Timothy J. <[email-masked]>
wrote:

> On 3/23/16, 1:33 PM, "smime on behalf of John R Levine" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
>
> So an authoritative service makes sense in an Enterprise context, but not
> in a consumer context.  How do you preserve consumer choice if Yahoo! owns
> their email service, but they want to certify keys elsewhere?
>

Could Yahoo! (in this example) not provide a means for their users to
update the key lookup service?  As the user is authenticated through their
UI, he or she could upload the keys they want in a secure way.   (A
realistic deployment caveat might be that Yahoo! puts some restrictions on
e.g. Yahoo! might not support self-signed, weak key sizes etc).  One might
argue Yahoo! wouldn't want to provide a key service, but then that's fine.
Without the SRV RR, things should be defined to fall back to the current
state of things.

-Wei

---

From: "John R Levine" <[email-masked]>
Date: 23 Mar 2016 18:23:36 -0400

> UI, he or she could upload the keys they want in a secure way.

Sure, and then Yahoo would serve the keys the users provide.

R's,
John

PS: Except for the MITM keys intalled by government order or rogue 
employees.

---

From: Wei Chuang <[email-masked]>
Date: Wed, 23 Mar 2016 16:00:46 -0700

> PS: Except for the MITM keys intalled by government order or rogue

If this is part of the threat model, Coniks has some ideas about auditing
key services against what they term equivocation or presenting different
keys to different users. The other aspect albeit in the far future one
could try to replicate what has been done with WebPKI which in my opinion
has been effective against those threats, and create a broad trusted anchor
eco-system with strong enforcement.

-Wei

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 24 Mar 2016 12:25:34 +0000

> Could Yahoo! (in this example) not provide a means for their users to update
> the key lookup service?  As the user is authenticated through their UI, he or
> she could upload the keys they want in a secure way.   (A realistic
> deployment caveat might be that Yahoo! puts some restrictions on e.g.
> Yahoo! might not support self-signed, weak key sizes etc).  One might argue
> Yahoo! wouldn't want to provide a key service, but then that's fine.  Without
> the SRV RR, things should be defined to fall back to the current state of
> things.

First, consider a user forwarding mail from Yahoo! to some other service, or using a single client to access multiple mailboxes but replying from a single address.  Who attests to what in these cases?

Second, by adding provider-side infrastructure you're increasing the cost of providing the mail service with no direct benefit to the mail provider himself.  There's an indirect benefit in which you're making the service slightly more attractive to a certain niche of users, but that's probably not even measurable as that niche is exceedingly small.  IOW, there's no incentive.

My advice is to keep it as simple as possible.  MUAs interact directly with users, so it should be MUAs that provide assurance, not mail providers.  This relieves the provider from having to worry about it, and users can opt in or out at will using any mail provider or key infrastructure they choose (up to and including roll-your-own).

-- T

---

From: Wei Chuang <[email-masked]>
Date: Thu, 24 Mar 2016 06:34:50 -0700

On Thu, Mar 24, 2016 at 5:25 AM, Miller, Timothy J. <[email-masked]>
wrote:

> update
> First, consider a user forwarding mail from Yahoo! to some other service,
> or using a single client to access multiple mailboxes but replying from a
> single address.  Who attests to what in these cases?
>

I don't believe a key service complicates these scenarios, rather as you
say the underlying PKI 'who' question does.

>
> Second, by adding provider-side infrastructure you're increasing the cost
> of providing the mail service with no direct benefit to the mail provider
> himself.  There's an indirect benefit in which you're making the service
> slightly more attractive to a certain niche of users, but that's probably
> not even measurable as that niche is exceedingly small.  IOW, there's no
> incentive.
>

Providing a key service would be up to the provider.  Some might choose not
to, and thereby solely use MUA based distribution.

Where a key service is provided, I would think there could be these
benefits:
* Keep private the initial conversation
* Certificate renewal upon expiry or similarly when revoked
* Describe the allowed trust anchor (for verification which shouldn't be
all the time)
* Potentially handle email address name variants e.g. subaddressing,
capitalization

-Wei

>
> My advice is to keep it as simple as possible.  MUAs interact directly
> with users, so it should be MUAs that provide assurance, not mail
> providers.  This relieves the provider from having to worry about it, and
> users can opt in or out at will using any mail provider or key
> infrastructure they choose (up to and including roll-your-own).
>
> -- T
>
>
>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 24 Mar 2016 13:58:06 +0000

> * Keep private the initial conversation

Peter's (I think it's his, at least he's the first person I heard it from) GETSMIME concept achieves the same result.  

Personally I prefer keeping discovery as a metaprotocol so only the MUA needs to implement it independent of MTAs, recognizing that this trades off against user convenience when the receiver is intermittently connected.  

The plus is that the MUA *always* has the current key, whereas all repositories get out of date quickly.  We have extensive experience with this in the DoD--expired userSMIMECertificate attributes in the Exchange GAL (effectively an LDAP directory) are a constant problem.  Keeping userCertificate attributes sync'd with the CA publication directory is also a royal PITA.

Reduce the moving parts and the system will be more robust.  Direct client-to-client key discovery will be more accurate, more easily deployed, and can be semi or fully automated.

> * Certificate renewal upon expiry or similarly when revoked

No.  Renewal is security sensitive, so automation is really not a great idea.  In certain niches--e.g., non-person autorenewal within an enterprise authentication domain like Active Directory--it's acceptable, but for persons I would recommend against it.

Revocation--in the commercial world and consumer PKI use case, anyway--is rare enough to just ignore.  Key continuity is a safer approach.

> * Describe the allowed trust anchor (for verification which shouldn't be all
> the time)

Why does the *cert repository* get to say who my CA is?

> * Potentially handle email address name variants e.g. subaddressing,

Too hard a problem to address external to the mail system, as we've seen.  

OTOH, direct client-to-client discovery doesn't have this problem *at all*.

-- T

---

From: "John R Levine" <[email-masked]>
Date: 24 Mar 2016 11:12:15 -0400

> My advice is to keep it as simple as possible.  MUAs interact directly with users, so it should be MUAs that provide assurance, not mail providers.  This relieves the provider from having to worry…

I wouldn't disagree, but I would also point out that there are a lot of 
people who are eager to add a per-domain key lookup to their mail service. 
There are proposals in DANE to publish PGP and S/MIME keys directly in the 
DNS which are a bad idea for various reasons, but I don't see any reason 
that a domain operator shouldn't be able to offer a key server if it 
wants.  Scott Rose at NIST and Richard Lau at ICANN have expressed 
interest in the DANE versions, so I'd like to give them an option that 
could work.

My main concern would be to keep it crystal clear that the key server 
semantics are "foo.com asserts this is the key for [email-masked]" rather 
than "this is the key for [email-masked]".

Regards,

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 24 Mar 2016 17:35:21 +0000

> I wouldn't disagree, but I would also point out that there are a lot of people
> who are eager to add a per-domain key lookup to their mail service.
> DNS which are a bad idea for various reasons, but I don't see any reason that
> a domain operator shouldn't be able to offer a key server if it wants.  Scott
> Rose at NIST and Richard Lau at ICANN have expressed interest in the DANE
> versions, so I'd like to give them an option that could work.

DANE's purpose is to allow me to clearly associate a trust anchor to a domain name, which is critical to resolve the "How do I signal which CA is authoritative?" problem in TLS/SSL, but I'm not sure that ports over to S/MIME.  In TLS the association between DNS name and a CA is virtually always 1:1 (domain name owner and the service owner are the same organization), but in S/MIME it's 1:many (the domain name owner and email users are not always the same organization; e.g., yahoo.com, gmail.com, hotmail.com, &etc.).

Providing an option sounds good on paper, but in practice not so much.  Options add complexity and ambiguity, and that leads to violated expectations, which is counter to the goal of having something that "just works" such that it can be taken up without penalty.  Simplicity serves that goal far better.

> semantics are "foo.com asserts this is the key for [email-masked]" rather than
> "this is the key for [email-masked]".

A certificate repository is, at best, relaying *stale* information it got from somewhere else.  Only the MUA actually knows what keys are held by the user at any given moment.  So why have a middleman?  Convenience?  Convenient access to the MUA's knowledge can be had without a central repository.  Why else?  

-- T

---

From: "John R Levine" <[email-masked]>
Date: 24 Mar 2016 14:23:08 -0400

> A certificate repository is, at best, relaying *stale* information it 
> got from somewhere else.  Only the MUA actually knows what keys are held 
> by the user at any given moment.  So why have a middleman? 
> Convenience?  Convenient access to the MUA's knowledge can be had 
> without a central repository.  Why else?

I'm sorry, this makes no sense.  How is my MUA supposed to know about the 
key of someone from whom I have not yet received a message?  Based on the 
arguments I've seen, the main point of a key lookup service is to enable 
opportunistic encryption on the first message.

Also, your assertion that the cert repository is likely to be stale makes 
a bunch of assumptions that were reasonable in the 1990s but not now. 
For example, vast numbers of people primarily use web mail, so the MTA and 
MUA are the same, they're both attached to the web server, so the 
repository sees the same certs the users do.  (We know why this model has 
all sorts of security problems, but half a billion web mail users aren't 
going away.)

And in domains that are authorities for their users, e.g., businesses that 
provide accounts to their employees, the domain's repository is accurate 
by definition, and there's an argument that repository checks can detect 
some kinds of mail forgery.

Regards,

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 24 Mar 2016 19:59:14 +0000

> key of someone from whom I have not yet received a message?  Based on
> the arguments I've seen, the main point of a key lookup service is to enable

My MUA knows my key.  Your MUA knows your key.  All that's missing is a way to have my MUA talk to yours.  

Practically speaking, S/MIME MUAs already do this using the quintessential exchange of signed messages and automatic collection of certs when caching contact data.  However, this was never formalized into something that MUAs could actively provide; rather, it was left as a passive function.  GETSMIME was an attempt to make this active. 

> Also, your assertion that the cert repository is likely to be stale makes a
> bunch of assumptions that were reasonable in the 1990s but not now.
> repository sees the same certs the users do. 

I'm hesitant to enable something as incredibly...naïve...as would give a convenient private key store for {insert your favorite Evil Agency here} to target to further their surveillance goals.  I take BCP 188 seriously, and the best way to address that threat model is to preserve the end-to-end guarantees of S/MIME.  You want S/MIME in webmail?  We need Web Crypto implemented in browsers.

Once you have Web Crypto, the private key store and the service provider are separate again, and the repository goes stale.

Also, since webmail service providers all allow fat clients (mobile mail apps are fat clients using a web API and are not fundamentally different from using a traditional mail client over POP3/IMAP4), in many (most?) use cases the client's key store is still separate from the provider, so the provider's repository still can and will go stale.

> provide accounts to their employees, the domain's repository is accurate by
> definition, 

Bzzt.   Incorrect, but thank you for playing.   :)

Building and maintaining an enterprise PKI directory is actually very complex, not fully automatable, and is a right royal PITA.  For example, Outlook wants userSMIMECertificate and will ignore userCertificate in most cases, because userSMIMECertificate is a PKCS#7 object and contains the user's encryption capabilities.  However, you can't automatically generate the PKCS#7 object since it's signed and requires a user action.  So even if you have your CA publishing directly to AD, it's publishing userCert, and you have to *train your users* to drill down into Trust Center (3 to 4 clicks), re-set the S/MIME profile, and Publish to GAL *every time they get a new cert*.

Good luck with that.  :)

> and there's an argument that repository checks can detect some
> kinds of mail forgery.

An MUA using key continuity concepts can do this too.

-- T

---

From: "John R Levine" <[email-masked]>
Date: 24 Mar 2016 17:12:43 -0400

> My MUA knows my key.  Your MUA knows your key.  All that's missing is a way to have my MUA talk to yours.

Right.  When you come up with a way for my MUA to fetch a key from your 
MUA when you have never sent me a message, let us know.

In the meantime, I think you need a better argument against per-domain key 
stores than "I don't trust them."  The people from DANE are determined to 
use per-domain stores, so it'd be a lot more useful to figure out how to 
minimize the suckage than to yet again stick our fingers in our ears and 
pretend we don't hear them.

Regards,

---

From: Michael StJohns <[email-masked]>
Date: Thu, 24 Mar 2016 17:24:11 -0400

On 3/24/2016 5:12 PM, John R Levine wrote:
> Right.  When you come up with a way for my MUA to fetch a key from 
> your MUA when you have never sent me a message, let us know. 

Is it possible that you're both using the wrong term above?  E.g. MTA vs 
MUA?

I would expect it might be possible for a user to arrange to have its 
inbounds MTA configured with some amount of data related to the user's 
delivery email address, and I would also expect that such data could be 
retrieved from the MTA by an MUA wanting to send email to that delivery 
email address.

I expect that John is correct that finding your MUA might be hard if 
he's never received an email from it.

Mike

---

From: "John Levine" <[email-masked]>
Date: 25 Mar 2016 15:58:43 -0000

>Is it possible that you're both using the wrong term above?  E.g. MTA vs 

No, this is the classic mail crypto model from the 1990s.  The
endpoints know the secrets, the intermediate nodes aren't trustworthy.
We are all familiar with vast popularity of crypto schemes that work
this way like, um, and er.

>retrieved from the MTA by an MUA wanting to send email to that delivery 

That's what DEEP does.  It has the practical problem that due to the
plague of botnet spam, most MUAs can't directly talk to remote MTAs,
only to their local MSA, so it needs a kludge to proxy the retrieval
MUA->MSA->remote MTA->MSA->MUA.  One of the reasons we wrote our draft
is that it does the lookups over https, which most MUAs already know
how to do.

R's,
John