Subject: Re: [therightkey] Will the real RPF please stand up?

From: "Joe St Sauver" <[email-masked]>
Date: Tue, 7 Feb 2012 12:05:17 -0800 (PST)

Kent commented on Kyle Hamilton's remarks...

#>Using the same key across multiple places may not seem to be 
#>something which has turned out to be a problem in practice, in that 
#>TLS sites use the same keys across every client.  However, it's a 
#>major reason why client-side authentication isn't accepted by the 
#>individual consumer.
#
#most folks believe that client certs are not widely used because of 
#the added hassle to issue them, poor cert management tools for users 
#who need to use the certs, and associated private keys, across 
#multiple machines, and the inertia associated with moving away from 
#passwords.

This is actually a fascinating question, and one where the answer you
get for "Why don't people deploy client certs?" varies from person to 
person. I attempt to capture a little of that in a talk I did a week 
or so ago at Internet2/ESNet Joint Techs in Baton Rouge:

"Client Cert Deployment Models and Hardware Tokens/Smart Cards"
http://pages.uoregon.edu/joe/client-cert-models/jt-louisiana.pdf

It wasn't possible to do an exhaustive analysis of that question in
a 20 minute slot, but you can at least get an idea of what we're seeing...

#>This means that we can't rely on a single certified public key.  We 
#>can't even rely on knowing ahead of time how many keys we need to 
#>enroll.  We can't accept constant DNs.  We can't accept static keys. 
#>We can't accept static certifications.
#
#I agree that users ought to have multiple keys/certs, and have done 
#so in papers and talks since 1997. I don't see how this relates to 
#constant names, static keys or static certification.

FWIW, even the Feds issue multiple certs, if only because some need to
be non-repudiable (e.g., for signing) while others need to be escrowed
for potential recovery (or authorized monitoring) of encrypted content
(at least in a Federal environment).

That said, given my druthers, I'd prefer a single client cert to use for
MOST purposes, just as I prefer to use a single PGP/GPG key -- it's
easier, and reduces correspondent confusion.

#>As a result, we need certifications to be API-enrollable.  The API 
#>must allow the user to able to specify what aspects of his certified 
#>identity are placed into the certificate.  Certifications should be 
#>a marginal cost item (a penny or two), because there is something of 
#>a queue for the certifier token service.  They should not be free, 
#>but they shouldn't be expensive either.

I'd also argue that there's a discontinuity in potential cert prices:
you can have free certs, and you can have not free certs, but you 
probably can't have really really cheap certs (e.g., in the couple of
cent range) for all the reasons that micropayments have traditionally
been tricky online, to say nothing of customer expectations ("Hey 
buddy, I paid a dime for that cert, I want to see some SERVICE when I 
have a problem!")

I'd also assert that the cost of the cert is trivial relative to the
cost of the secure storage device that might hold the cert (e.g., a 
USB format hard token, or a smart card and reader).

#there are other models of cert issuance that might yield free certs, 
#with limits on the context in which each cert is used. such limits 
#help protect user privacy, because a user need not employ the same 
#cert with a lot of different services. but, any model that requires 
#user to have a number of certs must contend with the user interface 
#problems to which I alluded above.

I concur that multiple certs equal user confusion unless you can really
make it pretty darn clear (e.g., [email-masked] or
[email-masked], for example).

If I want non-attributability, I'm not sure that I want to be using a 
cert at all

#>We should focus on providing as many chains of authority as are 
#>necessary to ensure security.  Perhaps enroll new keys using both a 
#>personal enrollment key and a device enrollment key, so that it's 
#>possible to identify which device was compromised?
#
#we don't require the same level of security for all transactions. if 
#we assume that the cost to issue a credential may be proportional to 
#the assurance associated with its issuance (which may not be true in 
#all cases), then we might have very cheap, maybe free credentials for 
#many transactions, and better ones, perhaps more expensive ones, for 
#a more limited set of transactions. One size need not fit all re 
#issuance. But it is nice if one format can be used to reduce costs 
#for CAs and RPs.

An interesting approach, BTW, is the one that CILogon takes, leveraging
federated authentication to mint certs for secure access to cyber
infrastructure -- see http://www.cilogon.org/ for more information about
this approach, if interested.

Regards,

Joe

---

From: Stephen Kent <[email-masked]>
Date: Tue, 7 Feb 2012 17:25:43 -0500

At 12:05 PM -0800 2/7/12, Joe St Sauver wrote:
>...

I think there are multiple reasons why client certs have not taken off,
based on 20+ years of experience in the area. We provided a client 
cert system for a financial firm in the early 90's. It was easy to 
use, bootstrapped from the password-based system that the firm used. 
But, because there were no good tools to allow users to move certs 
and private keys among client machines, it was eventually turned off.

>...

The 3-cert CAC is not what I was suggesting. (And the reasons there are
separate certs for sigs vs. key transport is because users need to 
perform key recovery for themselves for old e-mail, rather than for 
monitoring.) What I was advocating is certs with different IDs, each 
appropriate for a well-defined set of contexts, issued by CAs that 
are authoritative for identity in specific contexts.

>easier, and reduces correspondent confusion.

It is easier, but is undermines privacy and raises the question of 
what CA is appropriate for ALL contexts.

>...

The cost of managing a cert has a lot to do with the nature of the 
relationship between the issuer and subject, and the liability that 
the CA incurs as a result of issuing  the cert. For example, I have 
relationships with credit card issuers. They make money when I use my 
cards. If they issued certs to me, that could be used in lieu of 
plastic, because they believed the security could be better, I 
probably would not pay for the cert.

>...

not the sort of IDs I had in mind. I have an identity with Visa, with 
Amex, with UA, US, Hertz, Avis, etc. Each is authorized to identify 
me in certain contexts, and my ID is context specific. I also have a 
relationship entities who provide e-mail services, and they are the 
best entities to act as CAs when my e-mail address is the subject 
name. It's not about signing vs. encryption, but more about what 
entity is authoritative for identifying me.

>...

federated authentication systems using certs generally seem to be 
motivated because folks can make cross-certification work properly. 
other federated auth systems seem to be based on having one org trust 
another to assert and identity for a user know to the second, but not 
the first. that's a recipe for secruity problems.

Steve

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Feb 2012 18:52:47 -0500

On Tue, Feb 7, 2012 at 5:25 PM, Stephen Kent <[email-masked]> wrote:

> based on 20+ years of experience in the area. We provided a client cert
> system for a financial firm in the early 90's. It was easy to use,
> bootstrapped from the password-based system that the firm used. But, because
> there were no good tools to allow users to move certs and private keys among
> client machines, it was eventually turned off.

The reason I no longer believe in end-to-end solutions is that the
endpoint for a public key is always a machine and the desired endpoint
is a person.

So what happens is that people talk past each other with engineers
developing a scheme that prevents an attack the users don't care about
and prevent implementation of controls that they consider essential,
like spam filtering.

Cardspace fell victim to a similar problem. The system was very secure
but users no longer have a single machine that they use.

Any scheme that does not take account of the fact that a user must be
able to access their account from at lest fifteen different devices,
some of which will be mobile and possibly lost is useless in the real
world. The military can tollerate such systems because they will order
people to use them.

S/MIME with a private key shared to fifteen devices no longer looks
very secure to me.

In practice most email that is sent encrypted is encrypted using TLS.
If we had an infrastructure that allowed mail servers to know that
their corresponding servers required use of TLS, the man in the middle
downgrade attack could be defeated.

-- 
Website: http://hallambaker.com/

---

From: "Ryan Hurst" <[email-masked]>
Date: Tue, 7 Feb 2012 15:56:13 -0800

A very good point, this is also one of the reasons deploying smart card
authentication is difficult as well.

Today people use IP Phones, mobile phones, tablets, desktops, kiosks and
more; moving to a "require" solution for authentication requires one have a
solution for all of these devices or you increase complexity without the
benefit as you have to continue to support the weaker authentication
schemes.

Ryan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Phillip Hallam-Baker
Sent: Tuesday, February 07, 2012 3:53 PM
To: Stephen Kent
Cc: Joe St Sauver; [email-masked]
Subject: Re: [therightkey] Will the real RPF please stand up?

On Tue, Feb 7, 2012 at 5:25 PM, Stephen Kent <[email-masked]> wrote:

> I think there are multiple reasons why client certs have not taken 
> off, based on 20+ years of experience in the area. We provided a 
> client cert system for a financial firm in the early 90's. It was easy 
> to use, bootstrapped from the password-based system that the firm 
> used. But, because there were no good tools to allow users to move 
> certs and private keys among client machines, it was eventually turned
off.

The reason I no longer believe in end-to-end solutions is that the endpoint
for a public key is always a machine and the desired endpoint is a person.

So what happens is that people talk past each other with engineers
developing a scheme that prevents an attack the users don't care about and
prevent implementation of controls that they consider essential, like spam
filtering.

Cardspace fell victim to a similar problem. The system was very secure but
users no longer have a single machine that they use.

Any scheme that does not take account of the fact that a user must be able
to access their account from at lest fifteen different devices, some of
which will be mobile and possibly lost is useless in the real world. The
military can tollerate such systems because they will order people to use
them.

S/MIME with a private key shared to fifteen devices no longer looks very
secure to me.

In practice most email that is sent encrypted is encrypted using TLS.
If we had an infrastructure that allowed mail servers to know that their
corresponding servers required use of TLS, the man in the middle downgrade
attack could be defeated.

--
Website: http://hallambaker.com/
_______________________________________________
therightkey mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/therightkey

---

From: Martin Rex <[email-masked]>
Date: Wed, 8 Feb 2012 07:12:07 +0100 (MET)

> downgrade attack could be defeated.

I'm sorry Phillip, but MTA<->MTA delivery with STARTTLS is thoroughly
broken and effectively unfixable at the moment.

Not only is there no secure algorithm to determine which domains use
a TLS-enabled mail relay and which do not, but PKIX path validation
can not be done because plenty of mail relays are using certs that
do not validate under the (questionable) TLS X.509 PKI used by browsers,
and server endpoint validation can not be done because exactly noone
is carrying the Email domains in their SMTP Server certs for which
these servers are authorized to receive mail, and several SMTP fanciers
seem to be strongly attached to the idea that matching to the
*result* of an MX lookup rather than to the EMail target domain
would make sense security-wise (it doesn't).

And then there are SMTP servers out there (e.g. @gmail.com), that,
while being issued by a CA that is recognized under TLS X.509 PKI
of browsers, neither matches the EMail target domain, nor does
it match the insecure target of the MX record.

In theory, DNSSEC could be used to solve several problems (indicating
that a domain offers STARTTLS *plus* secure identification of acceptable
MTA servers.  But in the near term I expect a wide adoption of DNSSEC
not more likely or faster than the wide adoption of IPv6 to solve
the IPv4 address depletion...

-Martin

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Wed, 08 Feb 2012 08:52:39 +0100

> the first. that's a recipe for secruity problems.

Well, at the end, having an org trust another to identify a user only known to the latter is what certificates do, don't they? The problem with federated schemas is the number of potential sources of identity, that has to become unbounded by definition. You have then to rely on federation metadata, telling you which orgs are trusted to make assertions on whom, and you need some root(s) of trust for those metadata, metadata revocation procedures, etc.  And this collapses again into finding the-right-key(s)…

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Feb 2012 08:04:03 -0500

Yes, STARTTLS is broken in precisely the way I pointed out.

BUUUUT!

Now imagine that we have a mechanism that allows the mail server to
state 'TLS is always offered'. The problem can be solved.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 8 Feb 2012 11:36:12 -0500

At 8:52 AM +0100 2/8/12, DIEGO LOPEZ GARCIA wrote:
>Well, at the end, having an org trust another to 
>identify a user only known to the latter is what 
>certificates do, don't they? The problem with 
>federated schemas is the number of potential 
>sources of identity, that has to become 
>unbounded by definition. You have then to rely 
>on federation metadata, telling you which orgs 
>are trusted to make assertions on whom, and you 
>need some root(s) of trust for those metadata, 
>metadata revocation procedures, etc.  And this 
>collapses again into finding the-right-key(s)Š

I was a bit sloppy in my choice of words. Let me try again.

In the physical world we recognize that certain 
entities are authoritative for identifying people 
or orgs. These entities issue credentials to 
people and orgs, and these credentials are 
accepted for identification and/or authorization 
purposes, in selected contexts.  If a CA issues 
certs with IDs for which the CA is authoritative, 
it mimics the real world model, and that's 
generally good.  In many of the federation 
examples with which I am familiar, there is too 
much reliance on parties to vouch for identities 
in a nonauthoritative fashion. This is not a 
problem for all such systems, but for many.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 8 Feb 2012 12:06:55 -0500

>endpoint for a public key is always a machine and the desired endpoint

yes, the machine is the endpoint, but machines are always in the loop 
for the sorts of transactions we're discussing, unless we're very 
restrictive. The EU-inspired PIN pad + display that shows the user a 
number representing a value being authorized by a sig is an 
exception.)

So, I don't agree that the distinction between the user and a machine 
operated by a user is really significant, in the end.  (Yes, I am 
ware of the many security problems that arise because the user 
doesn't really know what the code is doing, but nothing is perfect.)

>world. The military can tollerate such systems because they will order

I agree that credential portability is essential. BTW, the US DoD 
operates more like a company with an eye on the bottom line than a 
monolithic security-focused organization, as you suggest above :-).

>S/MIME with a private key shared to fifteen devices no longer looks

Crednetial portability does not necessarily imply a private key kept 
in SW in  every device.

Steve

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Wed, 08 Feb 2012 19:56:13 +0100

> problem for all such systems, but for many.

I won't argue your point, but let me insist that is rather a matter of common practices in identity vetting than of the architectures or technologies themselves. CAs can as lax as the sloppiest federated identity provider, and conversely a federation can require its participating identity providers to apply procedures as strict as the ones used by top-level CAs.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: Stephen Kent <[email-masked]>
Date: Wed, 8 Feb 2012 14:30:29 -0500

At 7:56 PM +0100 2/8/12, DIEGO LOPEZ GARCIA wrote:
>I won't argue your point, but let me insist that is rather a matter 
>of common practices in identity vetting than of the architectures or 
>technologies themselves. CAs can as lax as the sloppiest federated 
>identity provider, and conversely a federation can require its 
>participating identity providers to apply procedures as strict as 
>the ones used by top-level CAs.
>

I think the real issue, which you ay have overlooked in my comments 
above, is the notion that the best candidate for a CA is an entity 
that is authoritative for the identity asserted in the cert. Based on 
you reply, I get the sense that you're focusing on CAs like the 
current set of browser TAs, all of which fail to meet the criteria I 
cited.

Steve

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Feb 2012 15:03:31 -0500

But authentication works in that scenario because the protocols can allow each user to have as many keys as they need. The key is not shared across devices, the protocols allow for multiple cards per end user

Sent from my iPad

On Feb 8, 2012, at 12:06, Stephen Kent <[email-masked]> wrote:

> yes, the machine is the endpoint, but machines are always in the loop for the sorts of transactions we're discussing, unless we're very restrictive. The EU-inspired PIN pad + display that shows the user a number representing a value being authorized by a sig is an exception.)
> 
> So, I don't agree that the distinction between the user and a machine operated by a user is really significant, in the end.  (Yes, I am ware of the many security problems that arise because the user doesn't really know what the code is doing, but nothing is perfect.)
> 
>> ...
>> 
> I agree that credential portability is essential. BTW, the US DoD operates more like a company with an eye on the bottom line than a monolithic security-focused organization, as you suggest above :-).
> 
> Crednetial portability does not necessarily imply a private key kept in SW in  every device.
> 
> Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 8 Feb 2012 16:52:11 -0500

At 3:03 PM -0500 2/8/12, Phillip Hallam-Baker wrote:
>But authentication works in that scenario because the protocols can 
>allow each user to have as many keys as they need. The key is not 
>shared across devices, the protocols allow for multiple cards per 
>end user
>
Sorry, I don't understand you comment.

Steve

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Feb 2012 20:22:19 -0500

Alice has three mobile phones and six laptops.

Using embedded keys in those devices for authorization is no problem
since each device can have a separate private key and the
authentication server tracks the fact that there are nine devices that
might authenticate Alice.

The same model can even be made to work for confidentiality. Alice can
read her DRM protected Kindle content on any one of those devices.
(Though there may be limits on how many devices the DRM scheme will
permit).

Trying to make S/MIME email work in that scenario is futile. The
sender only tracks one private key for Alice. So Alice has to export
her private key to all her S/MIME clients. Not only is that terrible
security practice, it is too much work. Worse, Alice has to repeat the
process once a year.

That is why I no longer believe that end-to-end is a desirable
quality. A security requirement that does not consider the cost it
imposes versus the risks it mitigates is ideology.

On Wed, Feb 8, 2012 at 4:52 PM, Stephen Kent <[email-masked]> wrote:
>> But authentication works in that scenario because the protocols can allow
>> each user to have as many keys as they need. The key is not shared across
>> devices, the protocols allow for multiple cards per end user
>>

---

From: Zack Weinberg <[email-masked]>
Date: Wed, 8 Feb 2012 17:46:32 -0800

...
> security practice, it is too much work. Worse, Alice has to repeat the

This is a special case of the confidentiality scenario, isn't it?
Alice's private key is stored somewhere in the cloud, and the server
will send it only to a device that can authenticate as Alice's device.
 But you also want to prevent the server from impersonating Alice: so
the key needs to be encrypted on the server, and decrypted on the
device. The dumb, probably good-enough way to do that is to have Alice
enter a passphrase on the device which gets PBKDFed to the decryption
key.  I bet there's something cleverer in the land of secret sharing
schemes, but I'd have to go dig it up.

zw

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Feb 2012 02:11:05 +0000

<trying to poke things along a bit more actively hat on>

So S/MIME works fine in many cases but does not work well
between random people connected to the Internet, unlike email.
That's a pity.

Its not an easy problem though, XMPP have been trying for a
good while and we don't even seem to have a good solution for
SIP or Diameter which ought be much easier.

I guess if this discussion lead to a way to manage keys that
could work at the same scale as email that would be a major
advance. I don't expect that myself.

And of course, whatever the right answer there (if there
is one) is maybe very different from how we might manage keys
for web servers or MTAs or XMPP servers.

Maybe we ought also think about whether or not the same key
management scheme is right for all those or not as part of
this too and whether we're able to solve all or just some/one
of those problems.

Put another way: maybe it'd be better to tighten the focus
a teeny bit more on this list. Specific suggestions for topics
welcome. Why not start a new thread with your favourite
problem that's worth solving and maybe solveable. (Being the
IETF, we're not very interested in other things in the end:-)

S.

PS: I bet I'm not the only one who can no longer associate
the subject line with the content. Be good to be better at
that since it'll help to try move towards some concrete
outcomes here.

On 02/09/2012 01:22 AM, Phillip Hallam-Baker wrote:
> On Wed, Feb 8, 2012 at 4:52 PM, Stephen Kent<[email-masked]>  wrote:

---

From: "Kyle Hamilton" <[email-masked]>
Date: Wed, 8 Feb 2012 19:09:03 -0800 (Pacific Standard Time)

Once upon a time in the IETF, there was a mandatory-to-implement cipher.  This cipher was the best-selected at the time, using cutting-edge technologies.

Time changed.  The new mandatory-to-implement cipher came along.

Why haven't we ever considered that maybe S/MIME doesn't have to be fully authenticated on first contact?  Why haven't we considered that with only a single certificate chain, the user would first have to communicate his MUA capabilities to his CA and then not upgrade his mail client without coordination?

Instead, we should have a new header in our email.  X-Secure-MIME-Capabilities:

We could make it contain a base64-encoded representation of what the Capabilities extension's OCTET STRING would contain.  Or we could assign labels to the various cipher algorithms to make them human-readable.

Instead of thinking along the lines of "only the named recipient will get it", why don't we start thinking along the lines of "the destination mailbox will be able to get it"?

From there, it becomes fairly easy.  "I must ensure that the symmetric key used to encrypt the message can be decrypted by all of my user devices and recovery keys."  A procmail recipe could perhaps re-send the message with additional recipient keys.

At that point, it's "what if I don't have my keys on the device where I can run procmail?"  IMAP becomes a useful tool, as does POP3.  They can't alter messages, but they permit a daemon that can, for example, ensure that its re(multiply)destined messages make it back into the mailbox before the original, single-destination message is purged.

This would also allow for additional commands to be sent from the devices to the keystore, such as "sign this with my corporate key" or "send this to [email-masked] with the best security you know how to do".

The problem is...?

-Kyle H

On Wed, Feb 8, 2012 at 6:11 PM, Stephen Farrell <[email-masked]> wrote:
>>>> allow

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Feb 2012 22:15:49 -0500

Umm, no, I was showing why end-to-end works for authentication (no
need for the same key in every device) but not for S/MIME.

The way to make S/MIME practical for Alice would be to do as you
suggest and have Alice's private key out there in the cloud somewhere
and have the server where it is kept be in charge of decrypting
inbound messages and then re-encrypting them for each of Alice's
devices.

This is a very good model for protecting content, but it is not end to
end, there is a bump in the wire where the email messages are being
decrypted and re-encrypted. So in practice this use of S/MIME is no
more end-to-end than SMTP over SSL.

Now I guess we could throw some crypto pixie dust over the scheme
maybe and reduce the ability of the intermediary to default, but in
the real world nobody is now going to accept encrypted email from just
anyone. Well not once the number of other people doing that has risen
to the point where it is worthwhile spamming PGP or S/MIME users.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Feb 2012 22:40:58 -0500

I think we have a set of requirements that point to a need for three
separable technologies:

1) A means by which a site can express the intended security policy
2) An append only notary service
3) A means by which a client can obtain security policy curated by a
fourth party

Each of these components can be designed in stovepipe fashion to only
serve one set of requirements or they can be conceived in slightly
more general form.

For example, Convergence, SK and CT all involve some form of append
only notary. Such a facility would have far more general applicability
than just addressing public keys. It might well be easier to get a
broad range of parties establishing and supporting the necessary
ecology of notary service providers if they are designed in such a
fashion that they can be used for general purposes.

So I will make separate protocol proposals in each area, but I think
what we are designing is going to be easier to deploy if we give some
thought to re-usability of components and dual use.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Feb 2012 03:55:07 +0000

Kyle,

I have no idea what you're talking about, sorry.

I think the best way to handle that is to go write an
I-D describing what you'd like and then send the URL
here. (Honestly, in my experience it helps a lot.)

S.

On 02/09/2012 03:09 AM, Kyle Hamilton wrote:
> Once upon a time in the IETF, there was a mandatory-to-implement cipher.
> This cipher was the best-selected at the time, using cutting-edge
> technologies.
>
> Why haven't we ever considered that maybe S/MIME doesn't have to be
> fully authenticated on first contact? Why haven't we considered that
> with only a single certificate chain, the user would first have to
> communicate his MUA capabilities to his CA and then not upgrade his mail
> client without coordination?
>
> We could make it contain a base64-encoded representation of what the
> Capabilities extension's OCTET STRING would contain. Or we could assign
> labels to the various cipher algorithms to make them human-readable.
>
> Instead of thinking along the lines of "only the named recipient will
> get it", why don't we start thinking along the lines of "the destination
> mailbox will be able to get it"?
>
>  From there, it becomes fairly easy. "I must ensure that the symmetric
> key used to encrypt the message can be decrypted by all of my user
> devices and recovery keys." A procmail recipe could perhaps re-send the
> message with additional recipient keys.
>
> At that point, it's "what if I don't have my keys on the device where I
> can run procmail?" IMAP becomes a useful tool, as does POP3. They can't
> alter messages, but they permit a daemon that can, for example, ensure
> that its re(multiply)destined messages make it back into the mailbox
> before the original, single-destination message is purged.
>
> This would also allow for additional commands to be sent from the
> devices to the keystore, such as "sign this with my corporate key" or
> "send this to [email-masked] with the best security you know how to
> do".
>
> The problem is...?
>
> -Kyle H
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Feb 2012 04:05:20 +0000

Hi Phill,

On 02/09/2012 03:40 AM, Phillip Hallam-Baker wrote:
> So I will make separate protocol proposals in each area, but

Great. That's what's needed for progress to be made here. Send
the I-D URLs here as soon as you can!

More opinions on your categorisation and its utility would also
be good, (e.g. it clearly doesn't try to address the secure-mail-from-
all-to-all problem, right?).

> I think

Well... that assumes that there are folks out there who want to
re-use stuff. To some extent this space, for now, seems to be
a bit more solipsistic. Maybe the people proposing to solve all
problems aren't quite as confident as they claim? (...he said
deliberately, but honestly, trying to provoke people out of
silence:-)

S.

PS: I do appreciate your being constructive on this.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Feb 2012 23:14:33 -0500

I see this problem as being somewhat off topic but the missing
component identified is precisely the same as the one missing for TLS:

1) There is no means for a recipient to express its security policy.
2) There is no infrastructure to allow senders to evaluate expressions
of security policy and come to a useful decision on whether or how
they should be enforced.

Lets get away from the details of how the security policy is
expressed. The core missing component in SMIME is that a sender does
not know whether or not to use encryption when sending a message.

The security policy could be expressed in headers or encoded in DNS
records or transported through out of band means. There are pros and
cons to each approach, the same ones that come up in the TLS case.

So what I would like is a policy language that allows expressions of the form:

example.com YYY "path=woqioiqoi2jq3roi2jqwoij2q==; xxx=_http,_smtp"
_http.example.com  XXX "tls=always"
_smtp.example.com XXX "tls=always; smime=offered"
_smime.example.com XXX "discover=ldap,xkms"

Meaning, certs offered for example.com will obey the specified
certificate path constraint identifying the cert signing cert for the
enterprise PKI, there are additional policy specifications for http
and smtp both of which say tls is always offered, smime is also
available and you can pull the client cert up using either ldap or
xkms discovery routes.

Now the same information could be presented in HTTP or SMTP headers or
exchanged out of band entirely. There are advantages and disadvantages
to each distribution mechanism. Which is why my vote would be to have
an abstract means of specifying the policy and flow the statements via
whatever works.

Unlike the usual case of looking at a protocol where people insist
that it support PGP keys, SPKI keys and sixteen different public key
algorithms because they happen to like 'em, there is a real set of
requirements and a real constituency for secure SMTP. And SMTP was the
other killer application for the Internet besides the Web.

The problem with just having security policy origination is that raw
security policy statements tend to have a much higher error rate than
is generally tolerable. Particularly during the introductory phase
when there is little relying infrastructure.

So even though email servers can in theory simply pull up raw
statements through the DNS, it is useful to have some background data
to help evaluate them. In particular to have reference to some agent
that knows the history of that security policy and the number of
violations being reported against it.

Deploying crypto is actually quite hard for the typical network
administrator who is rather more competent in World of Warcraft than
PKI to be honest. What almost everyone in IETF land tends to be unable
to grasp is that they are members of the technological 1% and that
what they find obvious, the 99% will find anything but.

So the thing that saved DKIM policy statements was the fact that they
are only interpreted by services that are actually very experienced in
handling bad data and in fact data that people are intentionally
trying to corrupt.

On Wed, Feb 8, 2012 at 10:09 PM, Kyle Hamilton <[email-masked]> wrote:
> Why haven't we ever considered that maybe S/MIME doesn't have to be fully
> authenticated on first contact?  Why haven't we considered that with only a
> single certificate chain, the user would first have to communicate his MUA
> capabilities to his CA and then not upgrade his mail client without
> coordination?
>
> Instead of thinking along the lines of "only the named recipient will get
> it", why don't we start thinking along the lines of "the destination mailbox
> will be able to get it"?
>
> From there, it becomes fairly easy.  "I must ensure that the symmetric key
> used to encrypt the message can be decrypted by all of my user devices and
> recovery keys."  A procmail recipe could perhaps re-send the message with
> additional recipient keys.
>
> At that point, it's "what if I don't have my keys on the device where I can
> run procmail?"  IMAP becomes a useful tool, as does POP3.  They can't alter
> messages, but they permit a daemon that can, for example, ensure that its
> re(multiply)destined messages make it back into the mailbox before the
> original, single-destination message is purged.
>
> This would also allow for additional commands to be sent from the devices to
> the keystore, such as "sign this with my corporate key" or "send this to
> [email-masked] with the best security you know how to do".
>
> The problem is...?
>
> -Kyle H
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Feb 2012 23:20:41 -0500

At the moment I have

* An Internet draft for expressing security policy in the form of DNS
statements.
* A draft of a white paper describing a general solution framework.
* Some proprietary protocols that implement the client-broker interface
* An aspiration to write a notary protocol ID.

I guess the sensible thing to do is probably to focus on getting out
drafts for the security policy origination and the client-broker
interface.

---

From: Nico Williams <[email-masked]>
Date: Wed, 8 Feb 2012 23:35:28 -0600

E-mail is not an online protocol between two MUAs.  When you send an
e-mail your MUA is not talking directly to the recipient's MUA, and
there are no automated replies except for vacation replies.

Thus in a cold-call e-mail send you have no knowledge about the
recipient's MUA's capabilities.  You can only sign your e-mail and
hope that the recipient can validate the signature.

If you know the recipient's public key and can derive some knowledge
about the recipient's MUA's capabilities from that public key and
surrounding material, such as a certificate or other metadata, then
you can send signed and encrypted e-mail to them.  The required
metadata -the recipient's MUA's capabilities- are found where the
recipient's public key is found.  That metadata has to be somewhere,
but e-mail headers isn't that somewhere.  This limits your and your
correspondents' ability to switch to other MUAs: they'd better support
the capabilities that you've advertised with your keys.

Sure, we could build a TLS-like protocol out of e-mail, if MUAs knew
how to speak to each other the mail network.  You'd say you want to
send e-mail to [email-masked] and your MUA could send a
specially crafted e-mail that Joe's MUA understands as a ClientHello
(and which Joe wouldn't see, as it would do Joe no good to see it),
responding with ServerHello and so on, and then you have a session key
that you can use to send encrypted mail to Joe.  And then we'd need to
negotiate cipher suites and such just like TLS.  But that's not how
e-mail works.  You send an e-mail, and hopefully it gets there, and
there's no automatic ping-pong until keys are established, there's
only that one e-mail.

That's why S/MIME and PGP work the way they do.  There are reasons why
S/MIME and PGP haven't become killer apps (and someone who knows much
more about them than I can lay them out), but lack of a header by
which to communicate MUA capabilities is not one of them -- we would
have solved that long ago if it had been.

Nico
--

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 09 Feb 2012 00:49:41 -0500

On 02/08/2012 08:22 PM, Phillip Hallam-Baker wrote:

> Worse, Alice has to repeat the process once a year.

Why would Alice have to repeat the process once a year?  Are you
suggesting she has to replace her decryption key every year?  Does this
have to do with the "repeat customer" lock-in model operated by modern
CAs where certificates are given artificially-short lifespans?  Even in
the face of that kind of tactic, why wouldn't Alice just get an updated
certificate from the same key and avoid having to re-key all her devices?

The only thing Alice needs for decryption is the secret key material;
she doesn't have to synchronize certificates at all for this use case.

	--dkg

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Feb 2012 08:16:16 -0500

Agreed, but!

Let us drop the end to end ideology in the dustbin and accept that
email is an MTA to MTA protocol, or to be more precise it is three
protocols:

MUA -> MTA:   SMTP/SUBMIT or HTTP
MTA -> MTA:  SMTP
MTA -> MUA:  POP / IMAP or HTTP

Note the presence of HTTP. People have been discussing email as if
SMTP == email. In fact a huge proportion of email travels over HTTP
instead of SUBMIT or POP/IMAP and quite a bit flows over HTTP alone
(all email from one gmail account to another, or hotmail, yahoo, yadda
yadda).

For Alice and Bob there are many possible paths:

I very often start writing an email message on one machine and
continue on another. In the course of a typical day I use a minimum of
one PC, one Macbook, one iPhone and my work iPad. So for me it is
actually quite usual for me to start writing an email on the Mac and
continue on the PC. I typically read the messages on whichever one of
the four machines is close at hand.

So the arity of the relationships is:

MUA -> MTA:  Many -> 1
MTA -> MTA:  1 -> 1
MTA -> MUA:  1-> Many

Now a good email setup should of course have multiple MTAs. But they
should have a setup that makes them look like a single logical unit.
There are many mail servers for example.com but only one logical mail
service.

So now we see why security policy driven by MUA published security
policy is going to fail: there is no consistency in the MUA loop. I
read mail on four separate devices. They have no way to communicate
between themselves to negotiate a common security policy and I
certainly would not want them to.

Conclusion:

1) Security policy is a property of MTAs and not MUAs and hence of
domains and not accounts.

2) We need a security policy layer for the internet as a whole and not
just for what people imagine to be the 'Web' or 'email' portions
thereof. This is a problem caused by stovepipe thinking and
non-my-problemism.

A SUBMIT MTA should tell the MUAs that it serves how to connect to it.
That is the port, protocol, use of TLS and certificate chain.

An SMTP server should likewise tell MTA clients what its security
policy is (use of STARTTLS, use of certificate chain, availability of
SMIME/PGP), authentication requirements.

The MTA -> MUA loop is interesting in that the directionality of the
protocol changes. The data has been flowing from client to server, now
it flows from a server to a client:

Client -> [Server : Client] -> [Server : Server] -> Client

So the POP or IMAP service would again publish policy telling clients
to connect.

Not that this is also a usability win. No more check boxes to tick in
order to get the configuration params right.

Add the capability for MTAs to publish policy and we can establish a
hop-by hop security mechanism that covers each of the three mail
interactions in three separate end-to-end sessions.

Getting back to the bigger problem, no this is not solving all the
problems we are seeing in the Web space. But it is solving a pretty
big one there. Web security is harder to improve than email security
because we already have quite a bit of Web security and very little
email security.

---

From: Nico Williams <[email-masked]>
Date: Thu, 9 Feb 2012 09:34:30 -0600

> Agreed, but!

No but, we agree on the rest regarding e-mail as well, and some of
what you say is a restatement of what I said.  You go further and note
that the very fact that PGP and such public keys and capabilities are
divorced from the MUAs is the problem -- something I hadn't noticed
last night, but I agree.

> email is an MTA to MTA protocol, or to be more precise it is three

I'm happy to drop the end-to-end principle where it can't be applied.
E-mail is mostly such a case (I say mostly because for a very, very
small group of people PGP has worked well enough).

> policy is going to fail: there is no consistency in the MUA loop. I

Indeed.  There's no way to ensure that all your MUAs have the same
capabilities.  I regularly use four different MUAs myself.

> thereof. This is a problem caused by stovepipe thinking and

Perhaps you're not communicating your vision of (2) very well.  I'm
not entirely sure what you mean, and I'm dubious of any
one-size-fits-the-Internet scheme (if that's what you have in mind).

> [...]

Right.  This is a case where hop-by-hop security is the best we can do.

> because we already have quite a bit of Web security and very little

I agree with this as well.

The web also has lots of end-to-end-ness, though HTTP doesn't require
it, and, indeed, encourages middle boxes.  And we also use the web for
different purposes than e-mail.  I don't think the hop-by-hop security
argument applies quite as well to the web...  For the web we really
want end-to-end security (with the server's concentrator being thought
of as part of the server).  I'm open to arguments to the contrary.
Perhaps you'd suggest hop-by-hop security where the hops are
client<->ISP<->server?

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Feb 2012 10:49:27 -0500

I agree on the problem of Web middleboxen being a problem.

What I really dislike about the BlueCoat solution is that it is
transparent. Which is of course why enterprises like them. They can
just deploy and forget. The fact that the purpose of the box is to
violate core assurances in the Web UI is irrelevant to them. They have
a regulatory requirement and will pay someone to achieve that at the
least personal effort to them.

I think we need to address SSL middleboxen properly (and not in this
forum, probably in TLS). Like prostitution, there are people who are
going to do this somehow, better to allow for  it and regulate it
properly than have it happening in dark corners. The next logical step
is to attack the client with some sort of applet that adds a bogus
root into the certstore.

First off, the whole point of the SEC regulations is that traders etc.
should know that they are being watched. So they should not be using a
regular client anyway. They should be using a client that regularly
tells them that their connections are being intercepted. I would think
this is also advisable from a liability, privacy and ethical point of
view.

Second, anyone who demands a cert that allows them to intercept any
SSL session is being an idiot and putting themselves at great personal
risk. There are people who are prepared to do a very great deal to get
such a cert. I believe in separation of duties for my own personal
protection.

Having an authorized bypass mode would enable the browser providers to
provide the appropriate (and really really intrusive) warnings to the
user at regular intervals. This is how Ari Luotonen, Rob McCool and co
originally conceived SSL intercept back when they did the Netscape
proxy.

---

From: Nico Williams <[email-masked]>
Date: Thu, 9 Feb 2012 10:09:53 -0600

> least personal effort to them.

There is a much better solution: block most outgoing HTTPS.  I know it
works because I know of at least one major organization where such a
policy is applied.  There's also a prohibition on accessing sites for
personal purposes.  So no gmail, no nothing.  There's also a
prohibition on using personal systems (laptops, say) on the corporate
network.  How do people get by?  Smartphones and wireless.  Who needs
to access the 'Net through an employer's network anymore?  (Yes, I
know, lots of people have no other way, but it's only a matter of time
till very few have no other way.)

> is to attack the client with some sort of applet that adds a bogus

Web authentication that handles channel binding would detect the
MITMs.  Then authentication just fails.  We could make it so users
could choose to do hop-by-hop security across MITMs they approve of,
but I'd rather just fail and let the user find a non-MITMed path.
Sadly, *very* sadly, we don't have such authentication mechanisms on
the web :(

> this is also advisable from a liability, privacy and ethical point of

Indeed.

Nico
--

---

From: Stephen Kent <[email-masked]>
Date: Thu, 9 Feb 2012 12:34:00 -0500

>imposes versus the risks it mitigates is ideology.

OK, now I understand your argument (aided by 5 paragraphs explanatory of text).

If this is the major issue, then, for the S/MIME context, one could
develop procedures for easy, secure xfer of private keys between 
devices, so that Alice could have the same key for encryption (more 
properly decryption)
for S/MINE. Procedures for doing this have been proposed in secruity 
conferences for at least a decade. Aslo, this is an issue only for 
encrypted S/MIME
messages, not signed messages. Outside of enterprise contexts I 
rarely see encrypted messages, and I don't think the problem you 
cited is the primary'
reason for this.

Steve

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Thu, 09 Feb 2012 23:29:16 +0100

On 8 Feb 2012, at 20:30 , Stephen Kent wrote:
> that is authoritative for the identity asserted in the cert.

I cannot agree more with you in that statement. And I don't think I overlooked it. What made me reply was the point about federated identity ("having one org trust another to assert and identity for a user known to the second, but not the first") being "a recipe for security problems". My point was that a certificate was precisely such an assertion, and I do agree with you in that whichever entity making such assertion (X.509, SAML, JWT…) has to be authoritative for the identity asserted if you want it to be usable.

> Based on you reply, I get the sense that you're focusing on CAs like the

As well as many of the federation systems you and I are aware of, for sure. But not all, and not because the concept behind them is flawed.

Be goode,

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091

---

From: "Kyle Hamilton" <[email-masked]>
Date: Thu, 9 Feb 2012 14:46:31 -0800 (Pacific Standard Time)

> least personal effort to them.

I think this can be solved via code.  Make it so that name:certificate pairs which pass based on the built-in roots can present blue and green, and certificates which pass based on non-built-in roots show up in gold.

> is to attack the client with some sort of applet that adds a bogus

The next logical way to defend against this is to enable it on our terms.

> originally conceived SSL intercept back when they did the Netscape

Why isn't this already part of the browser codes which handle network proxies?

-Kyle H

---

From: Stephen Kent <[email-masked]>
Date: Thu, 9 Feb 2012 18:05:47 -0500

At 11:29 PM +0100 2/9/12, DIEGO LOPEZ GARCIA wrote:
>  >...and I do agree with you in that whichever 
>entity making such assertion (X.509, SAML, JWTŠ) 
>has to be authoritative for the identity 
>asserted if you want it to be usable.

I think we are in agreement. CAs that are not authoritative for asserted
identities are as bad as federated trust entities with similar properties.

Steve

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 15 Feb 2012 17:06:08 +0100

> domains and not accounts.

I am wading through the list trying to catch up... and something in the above makes me wonder.

You start of with Alice and Bob, describe a relation between machinery, and conclude that the security policy is a property of the machinery.

Why is the security policy not tied to Alice and Bob?

--Olaf

________________________________________________________ 

Olaf M. Kolkman                        NLnet Labs
http://www.nlnetlabs.nl/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 15 Feb 2012 14:08:54 -0500

Yes, the policy has to come either from Alice or Alice's employer depending on the context. If Alice is at home, she choses, but if she is at work dealling with work issues, her employer should decide.

This is why i think policy should ultimately tie one to oneto DNS names: they are cheap and easy to obtain. If you are tied to someones dns name you are in their power anyway. That is why i own hallambaker.com.

But regardless of who is setting that policy, there has to be a single control point or it is not going to be practical. I have 48 ip enabled devices in my house. And in the future that wont be unusual. My car has 3 separate rs422 networks with 60 devices. 

The end to end argument is not obsolete: complexity really matters. What has changed is the conclusion. In 1970 the endpoint was the place to put complexity. Forty years later, a bump in the wire contolled by the policy maker is better.

Sent from my iPad

---

From: "Kyle Hamilton" <[email-masked]>
Date: Wed, 15 Feb 2012 19:56:55 -0800 (Pacific Standard Time)

> certainly would not want them to.

'Certainly'?  You wouldn't want your systems to work together to seamlessly and transparently add protections to all of your personal intellectual property, permitting secure access from devices which you enrolled or otherwise authorized, with potentially a completely transparent and automatic secure authorization process?  You wouldn't want your systems to automatically and securely manage your utility and ceremonial keys so that your command is the only one which can permit their application?  You wouldn't want your systems to implement key expiration and rollover, or automatically enroll new keys into new PKIs as such would become useful?

I'm sorry, but I would.  And I do.

The Person is the one who specifies policy.  Not the service that the Person hires to carry his mail or his traffic.  (The service may indeed specify its own policies, but that's the Terms of Service, part of the contract between two Persons (individual and corporate), and only of note if the service must cut the individual off for their violation.)

-Kyle H

---

From: Martin Rex <[email-masked]>
Date: Thu, 16 Feb 2012 05:30:20 +0100 (MET)

Kyle Hamilton wrote:
> 
> Phillip Hallam-Baker <[email-masked]> wrote:
> >
> 'Certainly'?  You wouldn't want your systems to work together to
> seamlessly and transparently add protections to all of your personal
> intellectual property, permitting secure access from devices which you
> enrolled or otherwise authorized, with potentially a completely
> transparent and automatic secure authorization process?  You wouldn't
> want your systems to automatically and securely manage your utility
> and ceremonial keys so that your command is the only one which can
> permit their application?  You wouldn't want your systems to implement
> key expiration and rollover, or automatically enroll new keys into
> new PKIs as such would become useful?
> 

I certainly would NEVER want that.

What you're calling for is a "single break-in" system, where breaking
into one of your devices enables the attacker to immediately take
posession of all your other devices for free.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Feb 2012 09:13:00 -0500

A single break system that was deployed is 100% better than a system
that will never be deployed.

We have tried doing the undeployable approach to secure email for
thirty years and it has not worked yet and shows no sign of becoming
more deployable in the future.

If we go back to the earliest security work at the O/S level by the
likes of Tony Hoare and Butler Lampson we get to the idea that all
security sensitive actions should be funneled through a single gating
point that is pervasive.

That works really well in the O/S world because in practice you can't
stop a policy enforcement point from being a potential point of
failure. The reason I dislike the peering model is that instead of one
single point of failure you end up with fifty single points of
failure.

If Alice has her private key on every device that can read email then
the loss of any one of those devices exposes her key and all the
emails.

---

From: Nico Williams <[email-masked]>
Date: Thu, 16 Feb 2012 12:16:34 -0600

> the loss of any one of those devices exposes her key and all the

You seem gung-ho on abandoning the end-to-end model.  I understand the
reasoning, and in the case of e-mail accept it fully, but I don't
understand why we can't have a hybrid in the web case.  A hybrid uses
!end-to-end to security bootstrap end-to-end security.

Note also that if all users get personal domainnames, like you and I
and another .01% of users, then we can have end-to-end secure e-mail
between personal domains once we boostrap end-to-end relationships
between them (a big caveat, that, because most likely there will be a
multi-hop PKI trust path only, certainly to begin with).  The ends
here would be servers in closets, sure, but they are suitable ends
because they are the users' servers, not some other organization's.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Feb 2012 13:49:09 -0500

I have been saying this for five or six year now, that is hardly gung
ho. And I have discussed it at length with the people behind the
original end to end model.

What I am saying is that the design of a security protocol needs to
come from an analysis of risks and of the constraints imposed by
users, legacy technology, etc.

If the approach that happens to minimize residual risk in practice is
end to end, then fine, go with it. But 'must be end to end' has no
place in a requirements document.

Remember that SSL was very different from the designs that I proposed,
EKR and Shiffman proposed and everyone in IETF land was considering.
It broke with the current dogma in very significant ways. Now in
retrospect, those breaks turn out to have been critical for the
success of SSL.

---

From: "Kyle Hamilton" <[email-masked]>
Date: Fri, 17 Feb 2012 15:27:22 -0800 (Pacific Standard Time)

> there are no automated replies except for vacation replies.

That last assertion is demonstrably false.  Among other things, there's the "return receipt requested" processor.  There's the "mailing list distribution autoresponder".  There is what I'm developing, which is exactly what I'm talking about.

Email acceptance by an MTA does not have a divine right to a reply.  But if it does merit one, wouldn't it be nice for the remote to be able to opportunistically encrypt it with knowledge of our security capacities?  Remember, the only thing that we can ultimately rely on is that a public key identifies its own and only its own private key.  We can use that to our advantage, if we stop worrying so much about MitM at the cryptography layer and instead present the "you might not be speaking only to who you think you're speaking to, someone else might be listening in, so don't say anything that you want to keep private" MitM possibility elsewhere in the UI.

> hope that the recipient can validate the signature.

A cold-call email is a special case.  The initial reply isn't a cold-call email. nor is any reply after that.  Neither is any further communication with that endpoint.

It is absurd that we're letting the special case become the enemy of the good.  "We assume that because it's not presently possible to query public registries for email keys, the entire model and concept is crap."  This is another instance of the binary "completely utterly blindly correct" or "it's not worth the bits it's encoded in", and it's as harmful here as it is in the browser security model.

We must fix the security model here, not push the burden onto application designers who have neither guidance nor expertise in the field.

> you can send signed and encrypted e-mail to them.

There is metadata associated with every email.  It exists in the form of headers.  These headers identify, among other things, the MUA the sender is using.  There's no reason this can't be extended.  (In fact, extending it is encouraged!)

If the sending MUA includes (for example) an EC public key and notes that it supports ECDH with Sha128 or Sha256 key derivation and Aes128 or Aes256, there is no certificate involved so there's no fear.  The recipient MUA can see that public key in the header, and it can generate its own EC public key to include in the header of the reply -- which has been encrypted with the ECDH-derived shared value as the key.

We must permit this kind of opportunistic, unauthenticated encryption, because email is far too important to leave plaintext.  We must accept that Alice has absolute right to put whatever she wants in her messages, and she can engage in any activity she wants to do to figure out what it's going to be.  We must accept that Bob has the absolute right to do whatever he wants with any message he receives, no matter its content.   We must plan for when Bob doesn't want to abide by Alice's security policy, by making the system depend on copyright exercise (which includes the exclusive ownership of the right to derive a shared key from a public key).  We must plan for when Alice sends something to Bob that breaks our narrow-minded interpretation of the rules, and present it as something other than full-stop "this isn't something I (software) recognize, so I not only won't let you do it, I'll scare you away from it."  We must plan for when Bob sends something with a clickwrap license that Alice doesn't want to accept.

If we do it right, we enforce that the derivation of the shared key is subject both to Alice's policy (by deriving the shared key to send with) and Bob's otherwise-unilateral imposition of policy.  This makes the participants peers in the conversation, not one master and one slave.

  The required
> but e-mail headers isn't that somewhere.

Not right now.  I believe it should be, because...

  This limits your and your
> the capabilities that you've advertised with your keys.

...more correctly, they'd better support the capabilities that my CA has advertised with my key, and I'd better not change my client to something with different capabilities or lose the private key (which, in keeping with security extremism, I have created in a piece of hardware such that I can't export it -- meaning that as soon as the hardware dies, I've lost the key).  If I change clients, or heaven forbid have multiple clients with different capabilities, I require the cooperation of an external entity, which is a commercial enterprise charging me for that cooperation.

The common insistence on "must be authoritative CA" operates in the real world as nothing more than a railroad into a racket.  This is why a header is necessary.  It is the least motion which must be made to enable opportunistic encryption.  (The alternative is allowing self-signed S/MIME certificates, that the client software creates itself.  I don't know that people would really like to accept self-signed certificates without a way to leverage the existing CA infrastructure and its authoritative identity assertions.)  

> how to speak to each other the mail network.

They do.  The packet is called a message, the transport is called "the MTA network".  The packet arrives in substantially unchanged form at the destination via a reception protocol such as IMAP or POP3.

  You'd say you want to
> that you can use to send encrypted mail to Joe.

Have you not heard of Diffie-Hellman?  Or Elliptical Curve Diffie-Hellman?  This is a mathematical transformation which allows two independent private key holders to arrive at the same value using one's own private key and the other's public key, based solely upon one exchange of public key material.  There's no need, reason, or desire for a full ClientHello TLS negotiation, and focusing on the handshake to the exclusion of what the technology actually permits is an astoundingly unintelligent idea.  This is another problem, people involved in the processes who don't know what the cryptography actually allows for so they can't comprehend when their rules are harmful.

  And then we'd need to
> there's no automatic ping-pong until keys are established, there's

Wow.  From this description, one would think that the recipient MUA didn't have the power to parse headers, send via SMTP, or keep track of the parameters that were sent with any given message or from any given sender.  One would also think that it was impossible for automatic mail processors to exist, like remailiers.

Your point is misapplied, it's much more suited to Usenet than email.  Usenet implies "I'm posting something for anyone to read".  Email implies "I'm sending a communique to someone with whom I want to engage in dialogue."  The special case of "cold call email" is much, much less common than the common case of "mail to a colleague or someone with a pre-existing relationship".  Getting hung up on the special case has prevented solutions for the common case.

Our job is to specify interoperability standards, not to inflict our personal horizons on the utility of the standards we come up with.  (Put another way: Just because a standards designer can't comprehend why a client legitimately and validly needs a particular capacity doesn't mean that the standards body has the right or responsibility to prohibit it in their output.)

So.  You send a quick query signed with a throwaway uncertified key to the intended remote, via SMTP.  The recipient MUA receives that message, parses it, and then sends (via SMTP) a self-signed key encrypted to the public key you queried with.  This is accomplished with information in a header which MUAs already parse, such as From:, Replies-To:, and Errors-To: headers.

If we do it right, we don't have to disclose the sender's or recipient's identities, even to each other -- while still obtaining the benefits of strong authentication and accountability in the network.  Right now, it relies upon the disclosure of email addresses.  I have a design which doesn't even need that.

> That's why S/MIME and PGP work the way they do.

That hangup is also (one of the reasons) why S/MIME and PGP haven't caught on.  (For more, see below.)

S/MIME and PGP rather missed much of the point, because everybody in OPGP-WG and PKIX-WG have been too hung up on what other people say identities are.  That hang-up has caused these security technologies to be unacceptably useless in the real world.  There is no recognition (beyond lip-service in OPGP) that the person is his own ultimate authority, and can choose to accept anything he wants even if it doesn't meet the standard's concept of "acceptability".

Societies don't have reputation because they need identity, they have identity because they need reputation.  A person legitimately has many more reputations than just the ones labeled with the label the state uses, and a person legitimately has a need to issue credentials within his own domain.

This means that there exist legitimate reasons to snub the authoritative Certification Authority industry, especially given standard protocols that permit assertions from one and only one chain of authority.

  There are reasons why
> have solved that long ago if it had been.

I mentioned one reason above.  Others are:
2) the artificial and unnecessary terror induced by misguided-by-IETF implementors who present untrusted chains as somehow less secure than no signature at all.
3) the lack of transparent operation, it's another step in the rote process of getting set up that people don't plan time for.
4) The exhortation in PGP's documentation to keep your private key on a single medium, with no provisions for what to do if that medium is lost.  If you (like me) had your private key on a floppy disk way back when, you probably (like me) lost it to bad sectors at some point, and (like me) lost access to information encrypted to it.  If we can't guarantee that the user data will be accessible, it's not secure.
5) The authoritarian model which PKIX-WG has improperly assumed fits reality, when in reality society is much more democratic with its petty fiefdoms.
6) The inability of people to play around with ASN.1-based authentication technologies without feeling like every time they clicked the "sign" button they'd just somehow sold their firstborn, again due to the misguided-by-IETF implementors who inflict terror in their user interfaces.

The idea that unauthenticated cryptography is useless is false.  Among other things, it enforces that attacks on the privacy of the content have a minimum work factor which must be surpassed.  In the real world, this means that a state would actively have to attempt to attack a person with an MitM email relay.  This is certainly doable, but I don't think it's something that we can really prevent.  In addition, even non-authoritarian regimes have legitimate law-enforcement needs to intercept communications.  And even then, once authoritative certifications or external-channel fingerprints are exchanged, it could be detected and its utility would be severely limited.

The idea that "Self Assertions are Null Assertions" is false.  Self-assertions permit the person, the Self, to communicate information that they say about themselves, rather than solely what other people have said about them.  The idea of providing only a single certificate chain is bad, because it even limits the information a person can put forth to what -one- other person has said about him.

The worldview that SAaNA spawned has stifled the advancement of incremental, effective, useful cryptographic technology.  The indoctrination into the "certifications are the only way to know you're talking to who you think you're talking to" worldview begs the question, "do we always need to know precisely who we're talking to?"  And I assert the answer is no.  If it were yes, we wouldn't have unencrypted HTTP going over the network.  The mandate to only ever grudgingly permit Absolutely Correct semantics to be presented without UI failure prevents effective application of transparent, opportunistic cryptographic implementations with effective on-ramps into Authoritative Semantics.

Thus is the indoctrination of the PKI Priesthood.  Peter Gutmann (U. of Auckland NZ) has referred to this indoctrination as "PKI me harder".  To make the world a better and more secure place, it must be shaken.

-Kyle H

---

From: Nico Williams <[email-masked]>
Date: Fri, 17 Feb 2012 18:03:47 -0600

On Fri, Feb 17, 2012 at 5:27 PM, Kyle Hamilton <[email-masked]> wrote:
> That last assertion is demonstrably false.  Among other things, there's the
> "return receipt requested" processor.  There's the "mailing list
> distribution autoresponder".  There is what I'm developing, which is exactly
> what I'm talking about.

Sigh.  I think I failed to finish that sentence.  What I meant to say
is that there are no unattended standard (de facto or otherwise)
protocols based on e-mail that could be used to do what OTR does.
Yes, such protocols are feasible.  But there's a reason we've got
them, and use them for IM (OTR) and not so much for e-mail: users
wouldn't have the patience for an e-mail OTR.

Nico
--