[Cryptography] multi-key encryption of "meta" data

[John Denker]

On 07/15/2014 05:07 PM, Jerry Leichter wrote:

> We have some data to deliver; we need a way to specify and resolve
> who to send it to.  We may want to protect against traffic analysis.
> These are issues common to many transport protocols.  There's little
> reason - other than history - for mail-specific encryption.

I appreciate the sentiment, but it's not that simple.  One
of the first rules of sound reasoning is to consider /all/
the possibilities.

In this case, the four most obvious possibilities form a
2x2 matrix:

      [ A  C ]
      [ B  D ]

  A) Some problems allow alternative solutions at different
   layers.  Some problems /require/ multi-level solutions.

  B) We agree that /some/ problems exist at the transport
   layer, and ought to be solved at that layer.

          C) OTOH, some problems are email-specific, and  
           demand email-specific solutions.

          D) Some problems cannot be solved either way,
           and will therefore persist.


At the next level of detail, in a different order:

   B) Defeating traffic analysis starts with concealing 
    the very fact that email has been sent.  This requires 
    encryption at a very low level -- OSI transport layer
    or below -- so that everything that gets transmitted
    is an opaque blob.

    Ditto for everything that gets stored.  Transmission
    carries data from one place to another, while storage 
    carries data from one time to another, so we should
    see the two as very similar.

    Also:  Defeating traffic analysis requires cover traffic.
    I have seen appallingly little discussion of this.  I
    get less than 50 relevant hits from
    https://www.google.com/search?q=%22cover+traffic%22+site%3Aietf.org

            C) The email client needs to show some of the
             metadata, such as sender, date, subject, etc.
             This is email-specific.  This is different 
             from decrypting the main body of the email,
             which is why a /layered/ approach has been
             suggested.  We do not need new cryptologic
             primitives, but we need better protocols for
             using the existing primitives.

             This need is not merely "historical".  If email
             did not exist, we would have to invent it.

    A) If you don't have good encryption at a lower level,
     then email-specific encryption such as STARTTLS is better
     than nothing.  Even if you do have lower-level encryption,
     additional layers of superencryption are still needed.

     1) Traffic analysis needs to be dealt with at a low level.
      OTOH, traffic analysis is not the only threat, not by a
      long shot.
     2) MITM attacks are a documented problem in the wild.  See 
      companion message:
      Subject: hard to trust all those root CAs
     3) Unencrypted email headers pose far more of a threat
      than low-level traffic analysis.  This is a huge burning 
      issue that needs to be dealt with ASAP if not sooner.
      If you don't believe me, ask Ed Snowden:
      http://www.theguardian.com/world/2014/jul/18/-sp-edward-snowden-interview-rusbridger-macaskill

            D) One of the virtues of email is that it is easy
             to use.  OTOH real security will never be easy.
             Sending email to <president at whitehouse.com> is 
             easy, but it is not quite so easy to recognize
             that you should not have done that, and should 
             have said <president at whitehouse.gov> instead.


> The main message has to be:  Keep it as simple as possible.

We all agree with that, as far as it goes.  Einstein said every
theory should be as simple as possible, but no simpler.

Sometimes cleverness plus hard work makes extreme simplicity 
possible, but sometimes you have to accept some complexity
as the cost of doing business.