Re: [therightkey] Secure e-mail, and why it's not an intractable problem

["Kyle Hamilton" <[e-mail]>]

Comments inline.

On Wed, Feb 8, 2012 at 8:14 PM, Phillip Hallam-Baker <[e-mail]> wrote:
> 1) There is no means for a recipient to express its security policy.

More importantly, there's no current basis for action if the client's security policy is violated by the server.  Communicating it is all well and good, but the server is a peer and can't be forced to follow it if there's no teeth to it.

Our technologies should permit the world to grow and evolve more effectively.  Right now, they do nothing but hamper it.  Why haven't we created anything to allow our users to leverage existing law to enforce their policies?

> 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.

Expression of security policy: "I will not connect on port 80."  Simple and to the point.

Unfortunately, it's never going to be able to happen on this Internet as long as the certification-authentication model is broken.

> 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.

This is only true in the Special Case of "no prior communication".  A sender knows whether to use encryption as soon as he has information about the remote's ability to handle it, regardless of whether he has a certificate.  This is why a header is necessary, the only way that S/MIME capabilities can be expressed right now is to send a certificate which must be issued by someone else about what your software is capable of doing right now.

Unless we start allowing self-signed S/MIME certificates (which is a completely different matter) or bare SPKI (a bit less useful), the only way to keep the people actually involved in the communication itself in sync with their software's capabilities is to allow the initial signed communication itself to contain information on the desired security parameters.

The "looking for the right key" bootstrap problem is being made into so much of a mountain that "what do we do with the right key?" has fallen by the wayside.  Until we know that, what are we fighting over?

> 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.

As it stands at this moment, for individuals the security policy is the same everywhere.   It also works about as well everywhere as everywhere else, which is to say "not at all".

As a standards body, I think IETF should specify the security architecture.  It should define what a competent policy should address, it should define the places where policy can be applied, and it should from time to time define a minimal policy which conformant implementations must be able to use.  In every other respect, policy processing and policy decisions must be completely up to the peer involved.

> 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"

S/MIME is a MUA thing, not a MTA thing.  This makes it rather difficult to put an S/MIME advertisement in place.  (TLS advertisement, though, is a good idea.)

> _smime.example.com XXX "discover=ldap,xkms"

This works on the off chance that example.com runs its own certifier and can publish its own certificates.

I want to enable the capacity for domain owners to issue S/MIME certificates for email addresses within their own domains, without requiring the delegation of any kind of CA infrastructure.  This is because:
1) It provides a way to let end-users play with the technology without being forced into another commercial contract of which they have not yet been convinced of the value.
2) Domain owners are authoritative for the email addresses and the bodies which hold them.  They are not authoritative for the real-world identities of the bodies, but they are authoritative for mail routing, web site content, network infrastructure, and so on.  They are also authoritative for their own policies.
3) Domain owners are the best suited to determining exactly what kind of security their independent endpoints and services need and need to advertise support for.

If there's a true need to prevent the domain owner from issuing a certificate to someone who is not legitimately authorized to receive messages at that email address, a person can get a key certified by a trustworthy authoritative CA.  However, this cannot be the bootstrap case.

> 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.

Ah, so you're not considering the individual's initial contact with other individuals.  You're considering only the case of the individual's initial contact with a cell of a corporate body, or corporate to corporate initial contact.  You're not considering the idea of introducers (people who share contact details with others, for initial contact only), or how that can logically be extended with electronic mediation.

I am not a fan of federated identity systems for authoritative identity information (meaning, information maintained by a public register, and useful in bringing the power of the state to bear).  I am a fan of federated identity systems for privately-useful reputation information, where that reputation information is linked to "the holder of a particular key".

Our computers have no concept of identity other than "the thing which provides input which can be verified under these rules with this key".  Everything else is metadata associated with that identity.

Keys are useful both internally and externally.  There are two types, the 'utility key' and the 'ceremonial key'.  A utility key is signed or used in the ordinary everyday machinery.  A ceremonial key is any key which is signed by a key held by someone else.  This includes internal network access certificates issued to employees and partners.  This includes Better Business Bureau.  It includes various localities' chambers of commerce.  It includes a service access certificate issued by a forum operator.  Anything which is useful to obtain something which would not be obtainable without it, such as trust or computer cycles. 

By elevating the signer of every ceremonial key of any type in the UI to peerage with the Authoritative Identity CA, and simply taking care to note to our user interface when there's a chain from someone trusted to provide authoritative identity information in the case of legal dispute, we can make cryptographic security something that people can actually use.

> 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.

Instead of getting hung up on that, why don't we just create protocols that handle abstract types and formats of authorities, with a credential type field?  (You know, like the use of OIDs to identify the type of an SPKI or signature algorithm, or the TLS auth_type extension?)

> 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.

This is why the default case must be to enable security without requiring certification from a 'trustworthy' authority.  Get the technology working first, then add the certification layer as a means of improving it.

> 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.

This is an application-specific policy, applied by people who don't own the rights to the material they're transporting.  It is necessarily limited.  The one who does can do a much better and more thorough job of applying and enforcing policy.

...but only if the tools exist.

> 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.

You're right, it is a problem.  We need to solve it.

Someone mentioned "if the problem were a header, we would have solved it by now".  I think the problem is the box that everyone seems to be thinking within.  Instead of thinking about it from outside the interaction, we should be considering what we want to see and what we want to share when we're one of the endpoints.  We should be considering what we want from our systems, not merely trying to dictate what we think other people should want from theirs.  We should consider what our own customers need from us, not merely what we think they need.

-Kyle H

> 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 <[e-mail]> 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.
>>
>> 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
>> [e-mail] 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 <[e-mail]>
>> wrote:
>>>
>>>
>>> <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:
>>>>
>>>>
>>>> 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<[e-mail]>  wrote:
>>>>>
>>>>>
>>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> therightkey mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/therightkey
>>
>>
>>
>> _______________________________________________
>> therightkey mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/therightkey
>>
>
>
>
> --
> Website: http://hallambaker.com/