Re: [Endymail] We're not done yet

[Watson Ladd <[e-mail]>]

On Sun, Nov 16, 2014 at 11:49 PM, Viktor Dukhovni
<[e-mail]> wrote:
> On Mon, Nov 17, 2014 at 02:34:06AM -0500, Paul Wouters wrote:
>
>> >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.
>>
>> 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.
>
> 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.

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!

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

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
> [e-mail]
> 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