Re: [Endymail] spam versus cleartext

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

On Sun, Sep 7, 2014 at 5:12 PM, Pete Resnick <[e-mail]> wrote:
> On 9/7/14 11:09 AM, Phillip Hallam-Baker wrote:
>>
>> On Sun, Sep 7, 2014 at 9:21 AM, Pete Resnick<[e-mail]>
>> wrote:
>>
>>
>>>
>>> Along similar lines to what John Levine said,: Obviously doing e2e crypto
>>> gets you signatures. Since we are blue-skying here, I think it is
>>> perfectly
>>> plausible to say, "If you want to send me e2e encrypted messages, you
>>> also
>>> have to send me signed messages, and you don't or your signature is not
>>> in
>>> my contacts list already, your encrypted mail is going to bounce." I
>>> think
>>> it's possible that in the fullness of time, many users go to a
>>> contact-list
>>> model of email (a la IM) where the mail simply bounces unless it has a
>>> signature that is already in the contacts list.
>>>
>>
>>
>> I think that is right, but not the whole picture.
>>
>
>
> A tangential up-level: I haven't gotten through all of the mail on the list
> yet (travel and other things have slowed me down), but I do notice that
> there has been quite a bit of "whole picture" discussion. I think that's
> fine, as blue-skying does involve thinking about how all of the pieces fit
> together. But as Stephen and I said in the first message, the thing we're
> looking for on this list is to "identify some bit(s) of work that the IETF
> could credibly do that'd improve the real-world end-to-end security and
> privacy of email. And note that 'credible' there requires stuff to be both
> technically sane and to have a sufficient set of capable folks interested
> and willing to do work." So while it's *possible* that a forklift
> replacement of email as we know it might be one of those "bits of work",
> separating out some smaller work items that could eventually be fit together
> into a shiny new system are probably the more interesting ideas. :-)

I don't think we can get rid of SMTP right now.

But any system that allows a sender to decide between sending
encrypted and sending in plaintext can easily contain a slot that
makes it *really easy* to swap out SMTP if desired.


The bit that I really don't want to redo is the S/MIME messaging
layer.  That works fine for packaging up the bytes. It works with
attachments and all the stuff we expect from modern mail.

Any new mail security standard has to be able to serve as a
replacement for both S/MIME and PGP. Otherwise we will just continue
the standards stalemate. It is easier to graft PGP functions onto the
fully developed S/MIME message format than to try to get PGP/MIME up
to a similar level of support.

But we do have to make sure PGP users don't get left behind and they
have to be able to achieve the same level of security they can achieve
today without being required to use a CA.


> That said, a couple of questions that have been rattling around in my brain:
>
>> I see endymail as a subset of mail. All mail should be encrypted at
>> the message layer but only whitelisted mail would be e2e encrypted.
>>
>> This can be done automatically as follows:
>>
>>
>> A) Some sort of discovery infrastructure maps email addresses to key
>> hashes.
>> B) Some sort of discovery infrastructure maps key hashes to keys.
>>
>
>
> I've been wondering about this. When I think about using crypto (whether
> encryption or signatures), it seems like requiring a discovery mechanism was
> increasing the burden. For many of my correspondents, with whom I'm
> currently communicating in the clear, a TOFU key exchange in those emails
> (authenticated out-of-band) might be a plausible mechanism.
>
> When we think about this, do we really need to assume that we either use the
> old or the new, and never the twain shall meet?

Well the discovery mechanism could be as minimal as 'take a domain
name and a hash of the key, pull the key from
http://<domain>/.well-known/phb/<hash>

I don't want to put anything more complicated in the client though.
Because as you point out, there are likely to be lots of ideas. And in
particular there will be ideas based on TRANS like infrastructures.

>From a trust point of view, the expiry of the Harber-Stornetta patents
is a very big deal. Putting keys and/or certs into notary logs gives a
huge amount of leverage. It also means that you will want some sort of
infrastructure fishing keys out of the logs.

But just don't weld any of that into clients yet...