Subject: [Endymail] We're not done yet

From: Watson Ladd <[email-masked]>
Date: Sun, 16 Nov 2014 21:27:58 -0800

Dear all,

Last email was a few months ago. There are a few drafts: I think Paul
Wouters had a DNSSEC key discovery draft around, but I feel we are a
long way from declaring victory. It would be nice to know that this is
because silently we solved the problem and deployed the solution over
the past month, but I've got a feeling its more likely we gave up.

So if I could summarize the problems they are:

1: keys are hard
2: spam is hard
3: discovery is hard.

UI work is needed for 1. 2 I have no idea. 3 seems to have some good
ideas floating around to solve it. Of course, in an ideal world we
would get perfect secrecy, but that's much harder, although methods
are floating around to do it.

Sincerely,
Watson Ladd

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Nov 2014 06:39:48 +0000

> are floating around to do it.

So at least in terms of keys and discovery, the DANE-specific
obstacles as are I see them (feel free to contribute to the Dec 02
DANE WG interim):

1. Mapping user addresses onto DNS:

   a. Email addresses use an alphabet more extensive than DNS labels.
   b. Email address localparts can (infrequently) be longer than DNS labels,
      and base32 or similar encodings make the problem worse.
   c. Email addresses are often, but not always case insensitive.
   d. DNS names are case insensitive.
   e. There are for better or worse significant concerns around directory
      harvesting (even with NSEC3).
   f. Some folks want key lookups to work with DNAMEs, with the keys
      published just once and automatically functional for all domain
      name variants.

   The current draft proposal lookup keys are base32 encoding of
   SHA2-254 hashes of the just the user address localparts.  This
   addresses a/b/f and very marginally e.

   However, the conflict between c and d is rather severe.  Key
   lookups will only succeed when the email address query is for
   the canonical capitalization of the email address.  If the
   email address were something like:

	[email-masked]

   and the destination domain supported case-insensitive delivery
   (e.g. via LDAP in which addresses are not case-sensitive), one
   might publish the same keys for each of:

	[email-masked]
	[email-masked]
	[email-masked]

    and hope that these combinations cover all the likely variants.

2. Revocation, or where does one attach the horse to the motor car?

	http://www.psmag.com/blogs/time-machine/electric-hybrid-cars-cyclists-pedestrians-traffic-safety-52337/

    - DANE is an online system for publishing fresh key material.

    - Ideally revocation in DANE is a matter of just removing the
      relevant records from DNS, and publishing only those keys
      are valid at the present time (modulo TTLs and ideally
      short RRsig lifetimes).

    - Since X.509 PKI certificates (OCSP notwithstanding) are typically
      long-term offline attestations, carrying over the web PKI "revocation"
      compensating measure is not necessarily a good idea for DANE.

    - Furthermore, in current mail client S/MIME implementations
      there is no semantically sound treatment of revoked or expired
      certificates.  Mail that arrives today should indeed avoid no
      longer applicable keys (whether revoked or simply no longer
      published).  However mail that arrived while the key was still
      valid and was successfully verified at the time, should generally
      remain valid even if the key is (sufficiently) later withdrawn.

    - So we are still talking past each other with completely
      different models and associated requirements, some want to
      put the horse before the cart, others say the cart is a motor
      car.

    - There needs to be a life-cycle model of key management in a
      world where today's keys are published online, that defines
      not only how the current keys are located, but how saved mail
      is handled and whether any sort of "revocation" is required,
      or whether de-publication is sufficient.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 17 Nov 2014 01:57:15 -0500 (EST)

>    and hope that these combinations cover all the likely variants.

That problem already exists at the SMTP level. There is nothing we can
do anymore. Implementations for OPENPGPKEY or SMIMEA will just have to
try some varients, or just lowercase it all. The discovery of those
records in cheap and the DNS probes can be sent in parallel.

> 2. Revocation, or where does one attach the horse to the motor car?

Use the key that is valid NOW and in DNS. There is nothing else better.

I don't see these two as a problem (and the fact that people are
implementing OPENPGKEY is a good sign they believe this too)

For me, the biggest problem in this is for people who don't run their
own DNS. It would be good if there was some kind of method for people
with just a gmail account to also be able to publish their public keys.
I think something along the lines of "DLV like" but requiring proof of
ownership of both email address and public key for registration, with
a requirement to keep signing something to keep the key in the "DLV
like" publication space (DNS or otherwise).

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Nov 2014 07:25:36 +0000

On Mon, Nov 17, 2014 at 01:57:15AM -0500, Paul Wouters wrote:

> >  one might publish the same keys for each of:
> >
> >	[email-masked]
> >	[email-masked]
> >	[email-masked]
> >

The client does not know whether these are safely treated as the
same address, so should only query for the address it is sending
to as-is.  Any variant equivalent lookup keys should be created at
the receving domain.  So there's only one lookup.

> Use the key that is valid NOW and in DNS. There is nothing else better.

For the record, I agree.  We still need to explain how this works
to others, why revocation is out of scope, and document the complete
life-cycle requirements (including the need for MUAs to save signing
keys associated with the message at time of delivery, and to securely
tag already verified messages, so that old mail can still be
verified).

Users likely also need to store old private keys forever so that
old mail can still be read.  The complete architecture for encrypted
email has many parts we're not making explicit, but all have a
bearing on key management requirements for MUAs.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 17 Nov 2014 02:34:06 -0500 (EST)

> the receving domain.  So there's only one lookup.

Well, that's a nice theory. Now in practise what happens is that SMTP
servers really don't have different accounts for LHS that are only
different in case. And we have the issue of too many phone input boxes
and webforms automatically capitalizing names. I just happened to me
today on my phone, so it send email to [email-masked].

If those are different people those people are going to end up with each
others email already. So the problem will not be worse.

> bearing on key management requirements for MUAs.

I'd call that out of scope. I think of OPENPGKEY as a transport plus
data in rest protection while in-transit. Once the final enduser gets
the email, I expect their email client to decrypt it and store it
locally, so it remains searchable, indexable, etc. I also expect them
to use full disk encryption to protect all their email. This method
does not require keeping old private keys.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 17 Nov 2014 07:49:41 +0000

> does not require keeping old private keys.

It is out of scope for the DANE SMIMEA and OPENPGP documents, but
it is not out of scope for an architecture or requirements document.
The pieces have to fit together.

Decrypted local storage is a fine model.  We need more MUAs that
support that mode of operation.  We also need to consider the
implications for sign-then-encrypt vs. encrypt-then-sign, and how
signature validation status is retained.  Yes, of course not in
the DANE-specific documents, but these should be part of a more
complete architecture (IIRC something along those lines is an argument
that PHB is making).

-- 
	Viktor.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 17 Nov 2014 21:11:02 -0800

> The pieces have to fit together.

Provide mechanism not policy. How MUAs decide to handle old messages
and keys isn't really relevant, nor should we force changes from
existing practice: people already have keys they will want to use with
whatever system for discovering keys we make.

Do architecture and requirements documents actually work? Or do they
end up overcomplicating solutions, as designers attempt to address
things that maybe should be punted on, as they cost too much to
implement? They certainly don't help with analysis: the requirements
documents may be wrong themselves!

> complete architecture (IIRC something along those lines is an argument

The correct construction is sign-then-encrypt. However, it could be
that authenticated encryption is a better idea, but S/MIME and PGP do
not support this.

One weakness of DNS vs. HTTPS is that HTTPS works in javascript for
browser extensions, while DNS data access may be an issue. I
understand Google wants to put PGP in the browser: the easiest way to
access keys would then be via HTTPS at a well-known URL. However, a
DANE-to-Web bridge shouldn't be that much of a pain if needed.

This minor, probably wrong, technical point, underscores a broader
deployability issue. Success of e2e email depends on everyone in the
world doing something. I'd be more confident in our getting this right
if people who understood the limitations and possibilities of webmail
better would participate in the discussion, or if we had running code
for whatever solution was being proposed.

Sincerely,
Watson Ladd

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

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 18 Nov 2014 05:22:18 +0000

> for whatever solution was being proposed.

Absolutely, the correctness of the ideas is only apparent once
there are implementations, and running code is a major part of
that.  The DANE SMTP draft was developed in parallel with an
implementation.  Work on both began in March of 2013, the implementation
was done by July, and officially released in January 2014, the
draft is just now in WG Last Call.

So for endymail, whether key management is via DANE or HTTPS, the
important thing is working code.  Fork Thunderbird, or Evolution,
do something real that's not just a toy.  The discipline of having
to create a fully usable implementation will bring all the hidden
problems to the surface.

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Nov 2014 09:43:46 +0000

> documents may be wrong themselves!

Oftentimes, those documents don't work in the IETF, I agree.
This might be an exception, since there are a bunch of folks
who're developing full solutions outside of the IETF and part
of the point of this list is to see if there are things the
IETF can do to help multiple of those solutions. (In the
hope that one of 'em cracks it and would then get sufficient
adoption that it'd be worth standardising later.)

I know Dave Crocker has done some work in this space (and he's
the author of RFC5598 as well) - so Dave, do you think there'd
be value in an RFC along those lines describing an architecture
for a modern secure interpersonal messaging system that could
scale and supports implementations with privacy friendly
features? (I'd like to see such a document myself, but am
unsure if doing one now-ish would be effective or not - we
might be too early or late.)

S.

---

From: carlo von lynX <[email-masked]>
Date: Tue, 18 Nov 2014 13:39:15 +0100

>From my point of view these are all very solvable problems,
but that is because I stand looking from a technologically
completely different place. In the following contribution I
describe how either Distributed Social Graph or the GNU Name 
System or a combination of the two can be used to solve the
three problems listed above quite nicely.

https://moderncrypto.org/mail-archive/messaging/2014/001081.html

Please ask any questions if there are any logical building
blocks missing. Probably there are. Or check out documents on
http://secushare.org

---

From: Dave Crocker <[email-masked]>
Date: Tue, 18 Nov 2014 14:02:41 -0800

On 11/18/2014 1:43 AM, Stephen Farrell wrote:
>> end up overcomplicating solutions, 
...
> features? 

Whether it's code, protocol specifications, architecture or
requirements, whatever is written requires serious discipline and
careful attention to utility -- that is, to being useful.  Each of these
has a long history of examples of impracticality, bloat, and/or
silliness.  (The worst piece of code I've ever seen what written in a
highly structure-oriented language; the prettiest piece of code was
written in assembler.  So code is as subject to abuse as architecture
documents.)

Requirements docs tend to suffer from failures to distinguish between
what really is essential, versus what is merely desired. (Hence, almost
all the IETF documents that call themselves 'requirements' should be
re-labeled, IMO.)

Architecture defines components, objects and the relationships among
them.  Good architecture docs clarify things well and guide further work.

Architecture exists whether we document or not.  The difference is that
when it is documented, we have a better chance of sharing the same
understanding of it, and therefore meaning the same thing as we discuss
things.  (As a consequence, good architecture docs often allows
debugging issues prior to the work of coding.)

Quite a bit of discussion on this list has been about architecture, when
it hasn't debated specific algorithms.  But I'm unclear what goals are
being agreed to or met or how decisions being made satisfy them.
Documenting the architecture doesn't answer such questions, but it
provides a useful place for reviewing whether the decisions match and
satisfy the goals.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net