Subject: [perpass] ID based encryption for email

From: Watson Ladd <[email-masked]>
Date: Sun, 29 Dec 2013 14:38:51 -0500

One obvious solution for end-to-end email encryption is to use
ID-based cryptography: a new record type would be defined in the DNS
containing the system key for an ID-based system, and the username
(everything before the '@') would be the identity used. This would not
obscure addresses or the fact of communication right now, but would
prevent interception at intermediate nodes. It would be webmail
compatible.

Are there any issues beyond the merely cryptographic that I need to
consider here? Can this be shoehorned into S/MIME, or do we need to do
something new?  In the next few days I will try to make a
draft/implementation for this.

Sincerely,
Watson Ladd

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 29 Dec 2013 17:08:20 -0500

> draft/implementation for this.

There are several problems with identity based crypto. The main one being
that the technology

1) Requires a trusted third party
2) The trusted third party has knowledge of every user's private key
3) There is no way to revoke a private key in the case of key compromise

There are of course various proposals to mitigate the last problem but none
that does not completely erase all the benefits of identity based crypto.

If the relying party is going to check some service to get key status they
might was well check for a certificate.

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

---

From: Watson Ladd <[email-masked]>
Date: Sun, 29 Dec 2013 17:32:52 -0500

> 1) Requires a trusted third party

In this system the trusted third party is already trusted right now:
they are the recipients ISP.
This system doesn't interfere with spam trapping and advertising, and
so is easy to adopt.
I'm not trying to replace PGP, just make something we can turn on by default.

> 2) The trusted third party has knowledge of every user's private key

A user can opt-out by running their own receiving mail server.

> 3) There is no way to revoke a private key in the case of key compromise

This one is probably the most serious limitation. I think the best way to fix it
is to use keys with limited temporal validity periods, say by hashing
with the year or
month/year as well. Then you wait a month and the old key is expired.
Accessing old
mail gets a bit tricky here, but clients could store local copies or
servers could hand out
the needed keys if you are logged in.

> might was well check for a certificate.

I was thinking sender mail client. Certificates could work, but then
we would have
to serve them up efficiently, and that's likely to be a bit of a mess,
particularly if
we don't want to reveal address books. If you could give every Gmail
user a Google
signed S/MIME certificate, and have Google distribute the list
(s/Google/mail provider of choice/)
that solves the issue, but adding 64 bytes (or maybe 128 bytes) in a
DNS extension is much
easier operationally.

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Stephen Kent <[email-masked]>
Date: Mon, 30 Dec 2013 10:42:37 -0500

Watson,
> prevent interception at intermediate nodes. It would be webmail
IBE requires an infrastructure in which we trust CAs not only to
correctly identify subjects, but also to not snoop on traffic,
since the CAs intrinsically have access to the private keys. It also
requires an infrastructure in which the CAs are directly tied to e-mail
names, and then into some bigger hierarchy, else we wind up with tens of
thousands of TAs. It would be much simpler, and more secure, to use DANE.
> draft/implementation for this.
IBE for S/MINE was defined in RFC 5408, in 2008. But, the issues
I noted above, plus IPR issues, have diminished enthusiasm for its
deployment.

Steve

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 30 Dec 2013 11:04:04 -0500

On Sun, Dec 29, 2013 at 02:38:51PM -0500, Watson Ladd wrote:
> consider here?

It seems like the scaling properties are going to be a little tricky
in places with very large numbers of users at a mail domain.  How will
the data get into the DNS?  Dynamic update?  What if people don't know
abou this new RRTYPE (please don't say "TXT record" for this use case
without explaining how you're going to subtype the TXT record without
stepping on other things).

A

-- 
Andrew Sullivan
[email-masked]

---

From: Leif Johansson <[email-masked]>
Date: Mon, 30 Dec 2013 17:05:33 +0100

> thousands of TAs. It would be much simpler, and more secure, to use DANE.

+1 - we already have that hierarchy lying about...

> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 30 Dec 2013 11:07:16 -0500

> the needed keys if you are logged in.

You better think hard about caches in the DNS, as well, for this.
Consider the timing problems that have bedeviled DNSSEC deployment.

A
-- 
Andrew Sullivan
[email-masked]

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 30 Dec 2013 18:17:36 +0000

Hi Watson,

ID-based crypto is not at all an obvious choice for email security.

I would even go further by saying that ID-based crypto has been a
solution in search for a problem so far. In my investigations (based on
prior proposals in the IETF) I could not find benefits with ID-based
crypto.

Ciao
Hannes

---

From: Paul Lambert <[email-masked]>
Date: Mon, 30 Dec 2013 10:26:06 -0800

Why do we even need DNS and names for email encryption?

The path/address to reach a peer should be independent
of the cryptographic identity used for peer-to-peer
authentication/encryption.

IMHO we should be looking a key centric approaches that loosely
bind one or more sets of names/email addresses to public key identifiers.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 30 Dec 2013 14:25:34 -0500

> they are the recipients ISP.

That is a bigger bug than you imagine. If you are going to accept the ISP
is trusted then we might as well just use STARTTLS which is a done and
dusted technology. The only problem TLS does not solve is that the ISPs
have to be trusted.

If the objective here is to allow the sender to know that only the
authorized recipients can read the message, having the receiving ISP in the
look isn't helping at all. It puts them at risk of being suborned.

> I'm not trying to replace PGP, just make something we can turn on by

PGP has not met the original goal of becoming ubiquitous so replacing PGP
seems to me to be a very worthwhile goal. Replacing STARTTLS with something
that has message scope but is not end to end does not seem like a good
proposition.

> A user can opt-out by running their own receiving mail server.

And how then do they get the root key for their identity based crypto
published?

Any answer that you give here can be used to authenticate a STARTTLS key or
a site wide wildcard S/MIME key.

> the needed keys if you are logged in.

Which gets us back to the need to automate the key management and if we can
do that then we can use traditional public key with much less effort.

I know the Identity based crypto looks like it should be really
fantastically useful but I have been looking at schemes for 15 odd years
and still not seen any practical application where it gives value except as
a device key.

Identity based crypto would be a very good way for Apple, Microsoft, Google
and co to put ignition crypto into a device. Every ethernet and wifi
address should come with a built in crypto key that is installed during
device manufacture and never leaves the device.

I would never ever want to encrypt data under an ignition key but I would
be happy to use such a key to authenticate an initial bootstrap process to
install the long term crypto credentials for that device to use in my
network.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 30 Dec 2013 19:45:27 +0000

Hi Paul,

I am now guess what you are trying to say here. So, apologies for
misinterpreting your suggestion.

Some on this list are trying to do the following: they take the existing
email infrastructure as a starting point and brainstorm about how to add
end-to-end security to it. Of course, there are solutions available
already (namely S/MIME and PGP) but both are not widely deployed for a
variety of reasons *.

Another approach, however, is to start from scratch and to define an
entirely new email system, which uses cryptographic addresses instead of
human-readable identifiers. I guess that's the approach you are
suggesting. Is this correct?

Ciao
Hannes

PS: It would be great if someone could point me to a good write-up about
the reasons why these two solutions are not widely deployed. I know
about a number of "not-so-useful" write-ups...

---

From: Peter Lawler <[email-masked]>
Date: Tue, 31 Dec 2013 06:56:07 +1100

> that has message scope but is not end to end does not seem like a good

Maybe a little OT on this thread, but for those who missed it
(OpenPGPv4) Key IDs seem to have problems (at least when those pesky
humans get involved)

http://www.ietf.org/mail-archive/web/openpgp/current/msg07195.html
http://debian-administration.org/users/dkg/weblog/105

+1 for replacing PGP.

Pete.

---

From: Paul Lambert <[email-masked]>
Date: Mon, 30 Dec 2013 12:38:41 -0800

Hi Hannes,

>misinterpreting your suggestion.

No apologies required .. You should always ignore what I type and only
pay attention to what I mean :-)
>already (namely S/MIME and PGP) but both are not widely deployed for a
S/MIME and PGP have specific public key trust models that have

>suggesting. Is this correct?

Yes - we should start from scratch (versus direct
augmentation of S/MIME/PKI or PGP).

In a key centric model, the recipient would be identified
by a cryptographic identifier.  P2P authentication would be based
on the identifier and the friendly human readable email address
would be secondary or even unbound.

Decentralized transitive binding of email addresses to a identifier
should be possible, but not mandated (e.g. signed bindings/certificates of
id to
Email address).  This would be Œforest¹ versus Œsingle tree¹ model
for name/attribute binding.  Where there was no visible explicit binding,
some level of anonymity and traffic analysis protection could be
provided.  

Public keys and identifiers for public keys (e.g. Hash of key) could be
used for more than email.  I¹m currently working on layer 2 proposals
for P2P authentication with these ideas, but see no reason that
the same model should not work quite well for email.

Paul

---

From: Dave Crocker <[email-masked]>
Date: Mon, 30 Dec 2013 12:44:01 -0800

> augmentation of S/MIME/PKI or PGP).

Starting from scratch to build a new email system is not likely to 
succeed, any more than the various, earlier efforts to do that 
succeeded, back when the installed base was a few orders of magnitude 
smaller and adoption of a new system relatively easier.

And then there is the small matter of wondering how viable the human 
factors of cryptographic email addresses will prove to be...

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Paul Lambert <[email-masked]>
Date: Mon, 30 Dec 2013 13:42:09 -0800

>smaller and adoption of a new system relatively easier.
To be clear, I am not advocating replacing the underlying protocols
for email delivery (SMTP, IMAP, etc.)

MIME encapsulation would likely still be the best transport.

>factors of cryptographic email addresses will prove to be...

My proposal is to unbind the cryptographic identifier - it would not
need to be part of the address.

However, using such an identifier in an address might be an interesting
transport technique.

UIs already map user name to email address Š S/MIME, PGP or anything new
all need some supporting user model and software to map address
to perceived identity.

Paul

---

From: "Jiankang Yao" <[email-masked]>
Date: Tue, 31 Dec 2013 09:49:18 +0800

From: Watson Ladd
Date: 2013-12-30 06:32
To: Phillip Hallam-Baker
CC: perpass
Subject: Re: [perpass] ID based encryption for email
On Sun, Dec 29, 2013 at 5:08 PM, Phillip Hallam-Baker <[email-masked]> wrote:
>> prevent interception at intermediate nodes. 

email includes many header fields; some fields may not be encrypted. 
you plan to encrypt the address for "mail from" and "rcpt to" too?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Dec 2013 08:21:25 -0500

Phillip Hallam-Baker <[email-masked]> wrote:
    > PGP has not met the original goal of becoming ubiquitous so replacing
    > PGP seems to me to be a very worthwhile goal. Replacing STARTTLS with
    > something that has message scope but is not end to end does not seem
    > like a good proposition.

I reluctantly agree that maintaining any kind of backwards compatibility with
PGP or S/MIME SHOULD NOT be a requirement.

(If it happens that I can leverage, through new code/protocol, my existing
web of trust, that could be a MAY)

PGP did not take off because it was too decentralized and therefore very enterprise
    hostile, and so it failed to get past early adopters.
S/MIME did not take off because it was too centralized and therefore early
    adopter hostile.

Both then ran up against webmail systems, e.g: hotmail/gmail/etc. in the
early 2000s, when having had the RSA patent run out, a renewed push could
have occured.  That problem will affect any new solution as well.

I look forward to reviewing drafts, and running beta code.
Who is going to make money on this system?
What's the market incentive to deploy?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting for hire =-

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 31 Dec 2013 19:26:59 +0100

>smaller and adoption of a new system relatively easier.

What makes the new email system different from other new communication
media with hundreds of millions of users and why is it necessary for it
to have those properties? Looking at Skype, WhatsApp, Facebook, Bit-
Torrent, and many others, it seems simple to achieve mass adoption.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 31 Dec 2013 19:47:11 +0100

>about a number of "not-so-useful" write-ups...

A current problem is that "webmail" systems cannot support either with-
out compromising the long term keys involved and the confidentiality of
the messages without proprietary and privileged web browser extensions.
That is something that probably can reasonably be addressed but if some
standardisation effort to that effect exists, then I have missed it.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 31 Dec 2013 13:50:48 -0500

> PGP or S/MIME SHOULD NOT be a requirement.

No, I did not say that. Backwards compatibility is probably a deployment
requirement. But I don't think that there is any group that is slavishly
devoted to PGP or nothing. There is an S/MIME or nothing group but that is
a different matter and their commitment does not exclude adding PGP like
features.

My original point was that re-inventing the wheel is only a bad thing if a
scheme has already succeeded and is ubiquitously deployed and in use. So
people need not be afraid of re-inventing PGP or S/MIME but proposals for a
new scheme that would meet the STARTTLS use cases have to meet a much
higher bar.

> web of trust, that could be a MAY)

I can make use of PGP keys and fingerprints in my proposal. But they are
more limited than the phingerprints that I use in strong email addresses.

In the current code a phingerprint is a digest of a master key that is only
used to sign policy statements. which in turn authorize the use of
encryption and/or signature keys. So there is always a policy layer.

The advantage this brings is that if people are using my scheme the
infrastructure will always support publication of a statement such as 'PGP
format encryption preferred'. While S/MIME and PGP both lack this essential
capability. [And no, the fact that some dufuses have made a hash of
security policy in the past does not make it an impossible problem or one
to avoid tackling]

> S/MIME did not take off because it was too centralized and therefore early

I think the issue is actually simpler. The criteria for ubiquitous adoption
of a security technology is that it has to be 100% right and S/MIME, PGP
are only 95% there.

Good enough for government work doesn't cut it for mass adoption of S/MIME.
The PGP ideology gets in the way of PGP use. Building the toll booths and
hoping the revenues will pay for building the highway is never a good
strategy.

> have occured.  That problem will affect any new solution as well.

I don't think Webmail needs to be considered a show stopper. I use Gmail to
organize all my mail through mailing lists because it has the search
capability and it can handle my mail volume (I am atg 8.09 GB (53%) of 15 GB
 used)

I would have no problem using a different client to send encrypted mail and
a browser extension could make reading encrypted mail possible.

Making this work is important to me as I invented WebMail back when I was
at CERN. Implementing Web Mail is what lead to the Content-Length header in
HTTP after I discovered that the HTTP POST spec was broken in 1993. (And
yes this is prior art for a certain patent claim).

> What's the market incentive to deploy?

Good

https://sourceforge.net/projects/prismproof

The market incentive is that the Web+SLL gave us the Internet e-commerce
boom which added several percent to world GDP in the 1990s. Email is the
other killer application of the Internet and there is the potential for
another economic boost albeit maybe a smaller one.

Current e-commerce is limited to the patterns that are supported by our
current security tools. If we add more security tools we may see more
e-commerce patterns.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 31 Dec 2013 14:03:07 -0500

On Mon, Dec 30, 2013 at 3:44 PM, Dave Crocker <[email-masked]> wrote:

> succeed, any more than the various, earlier efforts to do that succeeded,
> back when the installed base was a few orders of magnitude smaller and
> adoption of a new system relatively easier.
>

Starting from scratch is not likely to succeed. Any new scheme has to
support SMTP for legacy.

But when I am looking at adding crypto to SMTP+JABBER+SIP etc and realize
that 90% of the effort required is due to having to retrofit the security
to a badly designed protocol, I think that it is quite likely easier to
support secure JABBER etc. through a new protocol with crypto designed in
from the start and that if the messaging protocol is done right it would be
capable of being used as an SMTP replacement as well.

The reason for replacing SMTP would be not so much to replace the protocol
as to distinguish infrastructure that is designed with some sort of clue
from the muck that festers out in SMTP land. There will always be some twit
bleating on about how a change to the protocol is completely unacceptable
because he might have to stop using his 30 year old mail server program.

Mailing lists will never work well in SMTP because the protocol does not
really support them properly and the extensions designed to add support are
not supported in the clients. The only way to fix support properly is for
control messages to follow the same path as outbound messages and the only
way to make that change is to move to a new protocol.

That can't be done in the current mail system but it is easy to do if there
is a policy layer. Any mechanism that can be used to tell the sending mail
client that S/MIME or PGP format mail is preferred can in principle be used
to say that the mail should be sent over some JSON-B based REST scheme that
provides a superset of SMTP and JABBER capabilities.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 31 Dec 2013 11:08:38 -0800

> Torrent, and many others, it seems simple to achieve mass adoption.

Wow.

Please consider that things always look easy if one only studies successes.

In the case of new messaging systems, you need to look at the long and 
varied history of the very many failures to gain adoption.  Early 
Arpanet efforts at multi-media and then X.400 offer early examples of 
failures.  Facebook and Google had major projects that more offer recent 
examples.

Anyone who thinks that gaining global adoption of an infrastructure 
service is easy either hasn't done it or doesn't understand what caused 
their success.

d/

---

From: Peter Lawler <[email-masked]>
Date: Wed, 01 Jan 2014 08:25:45 +1100

> provides a superset of SMTP and JABBER capabilities.

(I'm new to IETF lists so I beg some leeway with my comments whilst I
get a grip on the netiquette of posting)

It would seem to me the main stumbling block for mass adoption of PGP on
SMTP and OTR on IM has been the multiplicity of additional software
layers. The typical day to day users I encounter understandably find it
hard to understand why they should need multiple additional applications
to provide these services and they're just way too busy with the
kids/education/work balance to spend time learning both, let alone other
tools. The people I believe to be typical end users don't want to have
to mess around with different encryption systems (nor do I believe
should they need to) to the extent that even installing a 'no-click'
solution is too much.[1]

A policy layer, to my mind at least, could go a very long way in
reducing this all too human overhead.

I suspect XMPP/XEP may provide some ideas with regards to areas of
crossover between SMTP and IM. As I've seen it, a Group Chat is somewhat
analogous to a mail list, an IM sent in 'offline' mode is somewhat
analogous to SMTP and XMPP Federation is somewhat analogous to SMTP
relaying.

Certainly, I recall a time when a certain major webmail provider had
XMPP chats turn up in their webmail view[2].

Pete.

[1] <mini rant>It was a long fight to get users to look for the 'lock'
icon in their web browser. Now, I'm finding I have to get them to check
whether PFS is enabled, how about cipher size and type etc. as well as
trying to get what I'd call critical business infrastructure (ISPs,
banks, certain Govt depts) to fix their web servers so that people not
using outdated/broken ciphers can talk to them. The other day I went to
report some breakage to my ISP but couldn't because... their webserver
was using what I consider broken ciphers. I thus tried reporting this in
less than 140 characters using to me what was an obvious string [cipher
overlap] and the response was basically 'CANNOTREPRODUCE: I submitted
the forms successfully, try a different browser'. I get the feeling that
each type of encryption/security we make available for typical users
increases difficulty of uptake exponentially and would probably have a
go at proving this mathematically if it weren't 2014/01/01 08:15 where I
am at the moment</rant>

[2] If memory serves correctly, this was removed recently when they
federated their new Social platform with their Chat platform and
disabled external XMPP federation.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 01 Jan 2014 01:32:20 +0100

>Please consider that things always look easy if one only studies successes.

My bicycle is protected by a combination lock. Breaking it without any
special equipment is simple, you just try different combinations until
it opens. But it is not easy because there are so many combinations to
try and you have limited time until you get exhausted or caught.

>failures.  Facebook and Google had major projects that more offer recent 

Perhaps incremental changes to the deployed email systems to improve
cryptographic properties have not succeeded because taken alone they
offer too little benefit. If the goal is to have a messaging system
with those cryptographic properties, then starting from scratch might
be the only way to succeed?

It goes without saying that designing and deploying a new planetary
messaging system is not easy, but I do not want to be stuck with the
limitations of the deployed email system forever, and I do not want
end up stuck with a proprietary replacement instead.

A useful response to my question would be to say, for instance, most
of the recently successful communication media are proprietary single
vendor systems, but a new email system necessarily must be federated.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Dave Crocker <[email-masked]>
Date: Tue, 31 Dec 2013 16:54:19 -0800

> end up stuck with a proprietary replacement instead.

Thia proposal fits a template in the form of:

    1.  Throw out existing email

    2.  Start over

    3.  The new system will fix major problems

It has been a popular refrain due to spam and other abuse, for at least 
20 years.  It is the template you are using, for proposing encrypted mail.

A decade or two or ago, I developed my own response template:

    1.  Specify the details of whatever functional improvements are 
being proposed.

    2.  Gain community rough consensus in favor of those differences 
from existing email.

    3.  Give the email technical community an opportunity to add the 
changes to the existing infrastructure.  There will come a point at 
which some needed change can't be accommodated, but we've done 
remarkably well over the last 35 years...

    4.  When we indeed fail to add the changes, then throw out existing 
mail and start over.

I've never seen anyone get past step 2.

> vendor systems, but a new email system necessarily must be federated.

Indeed, standards for truly distributed architectures do seem to be far 
more difficult to gain adoption.

But note that proprietary, centralized architectures fail regularly too.

d/