Re: Agenda, security, and monitoring

[Phillip Hallam-Baker <[e-mail]>]

On Sun, Feb 2, 2014 at 3:54 AM, Dave Crocker <[e-mail]> wrote:

> On 2/2/2014 12:48 AM, Patrik Fältström wrote:
>
>> On 2014-02-02 00:34, Dave Crocker wrote:
>>
>>> 1. It has demonstrated unacceptable usability for average users.
>>>
>>
>> At last my view and experience is that latest Enigmail and MacGPG is
>> making it usable.
>>
>> The key exchange is hard, but works really well in Enigmail+Thunderbird,
>> as key management is directly from mail read/compose window. Not in a
>> separate application.
>>
>
> You think that's a system that can and will be convenient and used by the
> mass market???
>
> So why isn't it already?


I address that in my video. Sorry, its not in text yet, but the argument is
not really part of the technical specifications.

The part that you don't state by name but imply is 'what is the business
model'. We are talking about a multi-million dollar change to the email
infrastructure. That is only justified if we can show a multi-billion
dollar return on the investment.

I think that there is such a return. If my bank, my doctor, my brokerage
can send mail and be assured that the transport is confidential end to end,
they can use email in more ways. SSL made Web commerce possible and added
roughly five trillion dollars to global GDP according to one estimate.
Email security can make Internet commerce better and simpler and sustain
that growth. Even if the additional benefits from making the other Internet
killer application secure are 1% of the Web benefits, that is a lot of
potential.


I see S/MIME and PGP as being 95% right respectively. The problem is that
Internet applications don't take off if they are 'pretty good' back in 1992
they had to be extremely good. And now they have to be exceptionally good.

Most of us have a box full of smartphones we bought before the iPhone came
out. The Palm Treo, HP iPaq and the Rim pager. They were all functional but
none of them had the real web, they were all walled gardens. Remember that
before the iphone the industry was flushing a billion dollars a year down
the WAP toilet in the confused belief that what cell phone users really
wanted was a dumbed down version of the Web with more adverts.

That missing 5% is critical. Specifically any new security scheme has to be
frictionless:

* Key Management: Has to make starting a key set simple and intuitive. The
user cannot be required to perform annual maintenance to replace expired
certificates. Everything has to be completely automatic.

* Multiple devices: It must be really easy to read the encrypted mail on
the many devices real users use today. I have eight machines that I
regularly read email on. Making it possible to read mail on a new device
has to be a one or two clicks affair.

* Transparent: Sending mail securely has to take no more effort that
insecure mail. That means that the mail client (or a proxy) has to decide
whether to send mail in cleartext or encrypted. Which in turn means that
there has to be a mechanism for specifying security policy.


S/MIME already supports an enveloping mode that protects the headers and
metadata. It just isn't fully supported by the deployed base. So there has
to be a way for a receiver to tell the sender what they support. Which is
why we can't use the PGP or S/MIME infrastructure just as is, we need to
add a little policy glue.

Take a look at the message that John posted, opening this thread.  That
> some systems use multipart/signed is fine, but it's not what's most common
> for PGP.


One of the biggest problems we have is that rather than tell PGP and S/MIME
to use a common packaging format and compete on the trust model, both
groups were told they could go ahead independently (although Jeff Schiller
told me that PGP was "not allowed to develop a PKI" then he rolled his
eyes).

End-to-end email has stalled in part because of the S/MIME vs PGP standards
war. PGP has ended up with all the mindshare, S/MIME has the deployed base.
When I was at VeriSign I had some long discussions with Jon Callas about
what might we do to fix things and come to a common platform. The division
was particularly silly when PGP had one of the best S/MIME platforms in the
market. That effort was overtaken by events and DKIM. The industry didn't
have bandwidth for two email crypto efforts at once. When I left VeriSign I
lobbied PGP inc to start a CA precisely to see if we could start to heal
the rift. Not that it helped. Symantec now own both companies and that
hasn't helped either.


If people want to move forward on this, something that would be very
helpful is for the naysayers to put all their objections into an Internet
Draft. Then those of us looking to solve the problem can go through and see
what we have solved and what is left to do.

I wrote a set of IDs as design documents before starting work on the code:

http://tools.ietf.org/html/draft-hallambaker-prismproof-req-00
http://tools.ietf.org/html/draft-hallambaker-prismproof-key-00
http://tools.ietf.org/html/draft-hallambaker-prismproof-dep-00
http://tools.ietf.org/html/draft-hallambaker-prismproof-trust-00

I now have code that is incomplete but shows proof of concept:
http://sourceforge.net/projects/prismproof/

There are two phases to the code:

Phase One is a scheme that employs a direct trust model and requires no
trusted third parties or infrastructure beyond the existing email
infrastructure and access to a Web Server to publish the Phingerprint
Blocks. This scheme uses the 'strong email address' which is essentially a
PGP fingerprint prepended to a mail address.

Phase Two allows people who have not met directly to exchange secure mail.
This scheme allows people to use their normal email address without any
visible cryptogunk. It necessarily relies on some form of infrastructure
but does not force a peer-to-peer or hierarchical model.

Right now the proxy can generate and manage keys, accept outbound mail,
encrypt it and forward it to the actual outbound mail server. I hope to get
the code to the point where it can make the decision to encrypt or not and
pull keys from a web server before London.


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