Subject: [saag] IETF 93 Agenda Request - Key Discovery

From: ⌘ Matt Miller <[email-masked]>
Date: Thu, 16 Jul 2015 12:20:49 -0600

I would like to request a 10 minute slot during SAAG on Thursday to
discuss entity key discovery and <
https://tools.ietf.org/html/draft-miller-saag-key-discovery-00 >.

Thank you,

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 16 Jul 2015 18:57:28 +0000

> https://tools.ietf.org/html/draft-miller-saag-key-discovery-00 >.

Sorry, I won't be in Prague.  A few concerns:

   * Retrieval of unencrypted private keys over HTTPS seems
     rather risky (perhaps a bad precedent).  One might instead
     specify that these are to made available as PKCS#12 or similar
     objects that support passphrase encryption.  The client would
     then extract the secret keys by using local knowledge of the
     applicable passphrase.

   * Finally, I am skeptical that the WebPKI CAs are a good fit
     for key management beyond the usual web server certificates.
     Trusting all of the usual suspects to also secure public keys
     for long-term content encryption (S/MIME, ...) not just
     authentication keys for web servers should not be done lightly.

     Perhaps this is a space, where proof of control of the domain
     needs to be stronger than WebPKI DV certs.  As I see it the
     confidence in the validity of a certificate is:

	EV >> DANE >> DV

     Since EV does won't scale to provide universal coverage, this
     is a space in which HTTPS with WebPKI may be inadequate.

   * This seems to want to support public-key lookup for email
     accounts.  You're perhaps aware of the DANE WG drafts in
     this space, perhaps these should be at least mentioned.
     Do we want competing (proposed) standards in this space?

-- 
	Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Jul 2015 22:14:46 -0400

>      Do we want competing (proposed) standards in this space?

Since DANE has now been around for what, four years without making much
headway, I think we should be very clear in saying that the field is wide
open to alternatives.

That said, as a CA, the last thing I ever want to see is a customer's
private key. If it is not the liability that would kill me, I would have
lawful access demands every hour of the day and night to handle. People
have asked me to provide that type of service on numerous occasions. It
isn't for lack of demand that it does not exist.

The way I propose to address the problem is to use end-to-end security and
a personal PKI to manage the keys.

https://tools.ietf.org/html/draft-hallambaker-cryptomesh-00

Setting up a PKI for myself and devices I own is pretty straightforward. I
am the only CA and the only root of trust. Deploying a PKI that allows
Carol to vouch for Alice's key to Bob is a hard problem. Deploying a PKI
that allows Alice's mobile phone to vouch for Alice's laptop computer is a
much easier problem.

As a CA I am more than happy to store someone's encrypted private key.

I do not use PKCS#12 in the mesh following my 'no new ASN.1' design goal.
It is a seriously complex and poorly documented spec. I am using JOSE JWE
instead. But PKIX works fine for the trust paths. (apart from discovering
that I have to write my own path construction engine because the existing
ones are built on some very peculiar assumptions but that is the
implementations not the code).

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 17 Jul 2015 03:26:35 +0000

> headway, I think we should be very clear in saying that the field is wide

That was DANE for browsers, now we're starting to see uptake in
places where it makes more sense to start.  Plus TLS library support
for DANE is not there yet, so lack of uptake is not surprising.
This too will change.

> isn't for lack of demand that it does not exist.

Well, the proposal is not quite to store the private key at the
CA, but it is to use the CAs to authenticate the server where the
private keys are stored to the user (an MiTMed user is likely to
disclose access tokens and compromise the private key).

> instead. 

I did say PKCS#12 or similar, can't say I am exceptionally fond of
PKCS#12 either.  The similarity need neither be a requirement for
ASN.1, nor an exclusion.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 21 Jul 2015 22:23:08 +0000

> https://tools.ietf.org/html/draft-miller-saag-key-discovery-00 >.

I've just glanced at

    https://tools.ietf.org/html/draft-moore-email-addrquery-01

I think it is a more promising effort in the intended direction.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 21 Jul 2015 23:10:21 -0000

>I think it is a more promising effort in the intended direction.

Agreed.  It distributes mail information through mail servers, rather
than hoping one can keep mail servers and web servers synchronized.

It's not perfect but the problems are fixable.

R's,
John

---

From: ⌘ Matt Miller <[email-masked]>
Date: Wed, 22 Jul 2015 09:18:15 +0200

On 7/22/15 12:23 AM, Viktor Dukhovni wrote:
>> I would like to request a 10 minute slot during SAAG on Thursday 
>> to discuss entity key discovery and < 
>> https://tools.ietf.org/html/draft-miller-saag-key-discovery-00
>>> .
> 
> I've just glanced at
> 

Thanks for the pointer.  I had missed it earlier, and will take a look
at it.

However, do not confuse RFC 7565 "acct:" URIs for email addresses.
Yes, they look a lot like an email address, as a "xmpp:" or "sip:" URI
can look a lot like an email address.  The "acct:" URI is for a
generic account identifier; it could be a placeholder to email, IM,
VoIP, filesharing, etc.

My draft is intended for more than email.

- -- 
- - m&m

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 22 Jul 2015 20:28:21 +0000

> My draft is intended for more than email.

A major difficulty is that email addresses and "accounts", are not
necessarily in one to one correspondence or even "few to one"
correspondence.  

How is one to know which "acct" URI is applicable to finding the
keys for a particular email recipient?  I probably should not even
be able to easily find out the login account behind a particular
email address.

Is the proposal intended to support key discovery for first contact?
If so how is the sender (of an email say), going to the find the
associated account to query?

Or is the sender expected to have previously received an "acct"
URI out-of-band and is only using it to maintain key freshness?

It still seems like this proposal is not a natural fit for email.
Perhaps it is better applicable to other protocols...

-- 
	Viktor.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 23 Jul 2015 14:30:34 +0200

> It's not perfect but the problems are fixable.

I'm kind of astonished that people still think that extending email
protocols is a good idea for things like this.  For example:

"BASE64 is used to avoid the need for the server to produce JSON text
which conforms to SMTP line-length restrictions."

Why, in 2015, would we continue to choose modalities that come with
these arcane restrictions?

Let's use modern technology for this.  What's needed here is
request/response protocol that can carry JSON, not a store-and-forward
protocol that carries an oddly constrained text format.  WebFinger
seems fine.

--Richard

>
> R's,
> John
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Richard Barnes <[email-masked]>
Date: Thu, 23 Jul 2015 14:35:18 +0200

> necessarily in one to one correspondence or even "few to one"

This doesn't actually matter.  WebFinger lets you put any URI in the
"resource" field.  So just use a "mailto" URI if you're sad about
"acct".  The document should probably say that, and probably say you
should return the same thing in either case.

--Richard

---

From: Russ Housley <[email-masked]>
Date: Thu, 23 Jul 2015 08:45:34 -0400

> should return the same thing in either case.

RFC 4387 provides a means to find an X.509 certificate using HTTP.  It seems pretty straightforward.  Do we have any running code for it?

Russ

---

From: 🔓Dan Wing <[email-masked]>
Date: Thu, 23 Jul 2015 14:50:29 +0200

> protocol that carries an oddly constrained text format.  WebFinger

+1.

-d

---

From: Richard Barnes <[email-masked]>
Date: Thu, 23 Jul 2015 14:53:04 +0200

> RFC 4387 provides a means to find an X.509 certificate using HTTP.  It seems pretty straightforward.  Do we have any running code for it?

With that "uri" attribute, it would probably be OK.  It would need
some more definition.

I suspect, though, that you're going to have applications that don't
want a cert, they want a key.  I think JWK strikes the right balance
here by providing the cert as metadata attached to the key.

--Richard

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Jul 2015 13:05:01 +0000

> which conforms to SMTP line-length restrictions."

SMTP line length restrictions are primarily a constraint on the
command side of the protocol.  The new command could be defined to
return lines of arbitrary length, but in practice it is much simpler
to in fact base64 encode the output.

> these arcane restrictions?

Because email servers understand the email address namespace and
canonicalization rules.  Because email clients, already talk to
MSAs, which are well positioned to find the remote MX hosts.  The
MSA might even cache the responses for sufficiently "popular" email
addresses.

MX hosts already have code for connection and request rate limits,
which can be extended to apply to these new queries.  

Also for first-contact keys, the MX host would typically return
the mail server's public key, not the recipient's so it can continue
to offer spam and malware protection to the target user.  Real
end-to-end keys would often only be returned by the user in a reply.

Returning the MTA's key allows the MTA to return a public key
regardless of whether email address requested exists or not, just
return the same key for all inputs (there should also be one or
more per-user signature key digests along with that key, to verify
any end-to-end keys later sent by the user, which can be random
for non-existent users).

> protocol that carries an oddly constrained text format.  WebFinger

The "store-and-forward" bit is irrelevant here, requests are not
for multiple recipients, nor are there keys for mailing lists.
Therefore, the envelope never splits, and there's no need to
commit data to a queue to ensure reliable delivery to multiple
destinations.

WebFinger requires email server operators to also deploy HTTP
WebFinger servers, or email servers to support an additional request
protocol.  Neither seems necessary.

-- 
	Viktor.

---

From: Phil Hunt <[email-masked]>
Date: Thu, 23 Jul 2015 15:15:49 +0200

Phil

> On Jul 23, 2015, at 15:05, Viktor Dukhovni <[email-masked]> wrote:
> 

I wonder of this is true (not wanting http) for those supporting the oauth sasl extension.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Jul 2015 13:26:37 +0000

> I wonder of this is true (not wanting http) for those supporting the oauth

Firstly, SASL is for MUA to MSA, not MSA/MTA to MTA.  Lookups of
keys for recipients is at the receving end, not the sending end.

Even if some large email provideds do end up supporting oauth SASL
for various web services, it seems unlikely that they would do so
for email accounts, where federated authentication seems rather
out of place.  More typically, the email provider would also be
the primary identity provider.

I can see an easy path to add support for the addrquery draft in
Postfix.  The same cannot be said for WebFinger.

-- 
	Viktor.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 23 Jul 2015 16:38:14 +0200

> any end-to-end keys later sent by the user, which can be random

I don't know why you think MXs or MTAs have any role in this at all.
The major point of this stuff is to look up keys for e2e, so it's most
likely to be implemented in MUAs, most of which either already have an
HTTP stack (to support HTML email), or are web pages themselves.  If
you want to add this to a web mail client, here's your implementation:

function getKey(uri) {
  var xhr = new XMLHttpRequest();
  xhr.open("GET", makeWebfingerURL(uri), false);
  xhr.send();
  var jrd = JSON.parse(xhr.responseText);
  return jrd.properties.keys;
}

It's not that many more to add it to Thunderbird.  How many lines of
code do you want to add to your MUA?

> protocol.  Neither seems necessary.

That is only necessary if you want to make keys discoverable for your
users.  And it's probably easier than upgrading your MTA to support
some new thing.

--Richard

---

From: ⌘ Matt Miller <[email-masked]>
Date: Thu, 23 Jul 2015 17:00:21 +0200

On 7/23/15 3:26 PM, Viktor Dukhovni wrote:
>>> WebFinger servers, or email servers to support an additional
>>> request protocol.  Neither seems necessary.
>> 
> for email accounts, where federated authentication seems rather out
> of place.  More typically, the email provider would also be the
> primary identity provider.
> 

I think key discovery will be used far far more by MUAs than MTAs or
MSAs.  All the MUAs I use today already do a fair amount over HTTPS;
the extra effort for WebFinger seems fairly trivial.

- -- 
- - m&m

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Jul 2015 15:04:46 +0000

> you want to add this to a web mail client, here's your implementation:

Because, MTAs implement all the optional case-folding, address
extensions, address canonicalization, ... logic that makes an email
address ultimately reach some user's mailbox.  They also provide
front-line abuse defense.

>   return jrd.properties.keys;

Of course, the request should be via HTTPS, and to really scale to
cover more domains, should support DANE auth, but all the client
API convenience in the world won't help if the request reaches a
server that can't provide the right answer, because the knowledge
of which email addresses are valid, what their canonical forms are,
etc., is in the MTA.

Also in the MTA are any keys for gateway-layer decryption of initial
contact email.  Many (corporate) gateways will choose to not expose
per-user keys to the outside, and will publish only the MTA's keys
to the outside world (regulatory compliance and corporate security
requirements).

> users.  And it's probably easier than upgrading your MTA to support

Deploying a later release of the MTA software is not notably onerous.

New data sources don't magically implement themselves without
software changes on the server side, even when new requests are
carried over an existing general-purpose protocol.  Even WebFinger
servers would need new server-side software to respond to to the
newly proposed request messages.

The domain owner would typically implement the address to keys
mapping as part of provisioning email addresses at the MTA, just
another lookup table that leverages existing logic to
normalize/canonicalize email addresses at which poitn the relevant
keys can be located.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 23 Jul 2015 15:16:09 -0000

>Even if some large email providers do end up supporting oauth SASL
>out of place.

In the era of DMARC damage to third party mail, oath for SUBMIT is the
only way that things like forward-an-article can continue to work in a
reasonable way.  

But that's unrelated to this discussion, where I completely agree with
you that mail lives in SMTP and that's where the key distribution
belongs.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 23 Jul 2015 15:31:31 -0000

>> The major point of this stuff is to look up keys for e2e, ...

Because MTAs are the only ones that know what account goes with what
addresses.  (Remember that when you log in for SUBMIT, your credentials
as often as not are not your address.)  

As I said yesterday in a related thread, here's my usage model:

I set up my online access at Bigbank.  One of the things I do is to
give them the addresss [email-masked].  The bank looks up my
PGP key and sends all subsequent mail encrypted to my key, which in
this case happens to be the same one as for [email-masked].

My MTA already knows where it routes that address and can find the
appropriate account and the corresponding keys.  Webfinger or anything
else would either need a side channel into the MTA or try to match the
local address resolution logic.  Ugh.

R's,
John

PS: To summarize some lengthy discussions in DANE, the response to
any suggestion starting "You can just canonicalize the address by ..."
is "No, that may work on your MTA, but it doesn't work in general."

---

From: Richard Barnes <[email-masked]>
Date: Thu, 23 Jul 2015 17:54:20 +0200

> this case happens to be the same one as for [email-masked].

Thanks a lot for the example.  I was wondering what Viktor meant by
"canonicalization".  I understand better now why you guys are inclined
to localize things on the MTA, however...

> local address resolution logic.  Ugh.

Consider the security requirements.  The MUA needs to know that it's
got the authentic address/key binding, where the address is the one
the user put into the MUA.  So if it's going to talk to an MTA, it
needs to be the REMOTE MTA.  If it reaches that remote MTA through its
local MTA, that's a problem, since now either (1) the MUA has to trust
the local MTA for all of its keys or (2) the remote MTA needs to sign
its address/key bindings.  Both of which are gross.

For security reasons, then, you're going to need to depart from your
usual mail protocol habits.  So you might as well just ditch the old
protocol and do something that's easier for implementors to build to.
Yes, you might have to wire your WebFinger (etc) server to your MTA --
but only if you have non-trivial translation rules.

--Richard

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Jul 2015 16:23:29 +0000

> its address/key bindings.  Both of which are gross.

The MSA authenticates the requestor, which is not something the
remote WebFinger server can do, and might be required to authenticate
itself to the remote MTA (Shumon Huque and I are proposing extending
DANE TLSA to client auth).  This will help reduce abuse vectors
for the key lookup service.

Recall that the party managing the MSA is generally also the party
managing the Inbox, and can supply MiTM keys to the user's
correspondents.  Reading the reverse traffic is often sufficient
to recover most of the forward traffic.

In the simplest model, the MUA will need to trust its MSA as an
introducer of said keys.  Just like Webmail clients trust the
javascript email application engine from the Webmail provider.
Just as the MUA would have to trust the WebFinger server, and
whatever sources that server consults to vend the keys.

Note that keys will be exchanged via ongoing email traffic, not
just initial contact.  The MSA's role will then be mostly as a
proxy to confirm the freshness of those keys, and lying about that
would be distruptive and rather noticeable.  Tamper-evidence is
likely to deter the majority of attacks.

It is of course also possible to specify that the protocol preserve
remote signatures across the MSA proxy, along with the appropriate
DNSSEC RRs to authenticate those signatures.  I am just not sure
it is worth it.  Injection of MiTM keys is difficult to do
undetectably.  Security savvy users can always check fingerprints
via additional channels, plus see above comments on ongoing traffic.

--
	Viktor.

---

From: "John R Levine" <[email-masked]>
Date: 23 Jul 2015 12:40:56 -0400

> its address/key bindings.  Both of which are gross.

Yes, but webfinger is just as bad.

One of my clients is an ad agency in Montreal.  I host their mail at 
Tucows, their web site is at some hosting provider in Toronto with whom I 
have had no contact beyond what's needed to point A records at them.  It 
is not unusual for a domain's mail and web to be handed this separately.

If it were easy to use encrypted e-mail, I expect they would, e.g., mail 
to a client about a campaign for an unannounced product.

So where do you do your webfingering for say, [email-masked]?  It's not 
going to be https://flacks.biz, they don't know anything about the mail. 
So you need some way to publish the location of the server, presumably a 
SRV record.  Even if you assume that an MUA behind a corporate firewall 
won't filter out SRV record requests, unless you believe in DNSSEC 
everywhere, you can't trust the SRV more than anything else, so the 
responses from webfinger need to be signed just like the ones from the MTA 
do.

I presume JOSE is the way to do that, but you'd know better than I would.

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 23 Jul 2015 23:48:30 -0400 (EDT)

On Thu, 23 Jul 2015, Viktor Dukhovni wrote:

> out of place.  [...]

I do not think it is a question of "even if" --
https://www.ietf.org/mail-archive/web/kitten/current/msg03528.html is
one example of Google declaring intent to implement the final version of
draft-ietf-kitten-sasl-oauth, and explicitly mentions email.

-Ben

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 24 Jul 2015 05:00:04 +0000

> draft-ietf-kitten-sasl-oauth, and explicitly mentions email.

Poorly poorly stated conditionals, I meant to say "even if some
[particular] large provider".  Of course "some", perhaps even most
will.  The intent is to say that support for SASL OATH somewhere,
does not then lead to HTTP code in the receiving MTA.

--
	Viktor.

---

From: Chris Newman <[email-masked]>
Date: Fri, 24 Jul 2015 10:25:16 +0200

--On July 23, 2015 14:30:34 +0200 Richard Barnes <[email-masked]> wrote:
> protocols is a good idea for things like this.

Extending email protocols to lookup information about an email address is the
only model that provides good architecture, operational/security isolation, and
maximizes deployability.

It's a fundamental architectural principle of email addresses that the
semantics of the local part are owned by the domain on the RHS, or more
specifically the SMTP server that is the target of MX records for that domain
and performs routing, aliasing, local part transformations, subaddress
processing, list expansion, forwarding, SRS, rejection, delays, sieve, address
blinding policy, SMTPUTF8 mappings, etc. The only way for web finger to follow
the architectural principles of email and do a lookup on an email address is to
communicate with the configuration and codebase present on the SMTP server.

It's desirable to have security sensitive components of the infrastructure
isolated to the greatest extent possible. Web protocols have a lot of security
consequences. Email protocols have a lot of different security consequences.
Mixing those security consequences is bad security architecture as it increases
the attack surface of the combined server. Let's not do that.

Lookup protocol syntax is a trivial amount of code in the overall system
(regardless of debatable opinions about protocol modernity). What gets complex
is the semantics, infrastructure and operational practices behind those
protocols, so when that complexity is involved it's best to use the primary
protocol of the server codebase that owns those semantics.

I do think it's desirable for protocols that do certificate lookup to use a
common data model for results. It looks like the WebFinger and addrquery
protocols are moving in a similar (JSON) direction for the result data model so
alignment should be encouraged to the extent an aligned data model can provide
simple/necessary functionality.

		- Chris