[Dev] Automatic secure email

[Mike C. Fletcher]

Couple comments on issues in Andy's message...

To avoid the potential for and pitfalls of an encrypted message sent to 
an "unready" recipient:

    * Unless the user explicitly specifies it, do _not_ encrypt email to
      any given person (i.e. the goal seems improper)
          o Instead target _signing_ all emails transparently (that is,
            the system's goal is to get to the point where it is
            verifying the signatures of all your correspondents (which
            happens to be the same point where it can encrypt for all
            your correspondents))
                + preferably with a header-based, not a text-body-based
                  signatures
                + on finding a signature from a person whose key is
                  not-yet-known, the MTA can append a MIME PK
                  certificate attachment to the next message to that
                  person (on the principle that if you're sending signed
                  message, you're able to receive the PK as well).  As a
                  usability note, it would be best if this were treated
                  specially compared to a "normal" mime mail (i.e.
                  doesn't show up as an attachment in our UI).
          o Use reply-verification/confirmation headers in replies to
            signed messages
                + I get your signed email, I send back a signed hash of
                  the email if/when I reply
                + (Note: with inclusion of certificate in the first
                  reply that may bulk up the message noticable)
                + Potentially this may trigger the sender to say "hey,
                  wait a minute, that's not what I sent" or "hey, you
                  don't seem to be who you were", in which case we'd
                  likely want to alter the display and re-request a PK
                  certificate on the next exchange (mail/IM/whatever).
                   Again, we're not yet actively needing any of this, so
                  it's okay to allow a little back-and-forth.
          o This establishes (fairly transparently) that the encrypted
            channel can be created, and means that at some point in the
            future the user can simply click "encrypt communications to
            this user" with a fair likelihood of success.
          o Avoids potential for user to see security as "getting in the
            way"
    * Make encrypting content a "step-up", which may require some
      (small) extra effort
          o In effect, make the system establish the web-of-trust
            dynamically "out-of-band"
          o When the user wants/needs it, the system is already there,
            with enough information and history to have a decent chance
            of "soft" security
          o Explain the risks and "softness" when the user does the step-up
                + Offer easy ways to improve security at this point
                  (e.g. using public key-servers, using a pass-phrase to
                  encrypt the public-key on disk (with option to
                  generate a new one and invalidate the old one in case
                  you've been compromised))
          o Enable UI features for encryption when the user steps-up
                + Until the user expresses interest, there's no other
                  encryption-specific UI.  Have a simple control on
                  comms windows reflect the current encryption/signing
                  capability status (i.e. whether it would work at the
                  moment to try and encrypt for the current recipient(s)).
                + Once enabled, give the user whatever (hopefully
                  minimal) tools they need (e.g. examine keys, verify
                  fingerprint OOB, send introduction email)
          o Offer to upload a certificate to PGP/GPG key-servers at this
            point
                + Same PK as has been used all along, you're just
                  putting it out there explicitly
    * If the user wants immediate encryption (first-time problem)
          o Allow for explicitly sending our key/certificate (normally
            done by the auto-discoverer)
          o Allow for explicitly including our key/certificate in a
            response to a person's message
          o Explain that MiTM attacks are much more likely in this case!
            (single capture suffices to compromise)

To make MiTM attacks harder:

    * Share our PK fingerprint(s) whenever interoperating with another
      system
          o Put them in mail headers
          o Put them in meta-data for Spread messages
          o Put them in IM setup headers
    * Keep histories of keys and fingerprints
          o Basically, any change/discrepancy is a potential problem and
            should reduce the trust of the values.  That should be
            reflected in the UI (e.g. if there are two keys in active
            use for a user, show their encryption-ready status as 25%
            (or whatever), you may need to select one of the two keys
            for use, and it may be that there are two MUA's in use, so
            you might want to use both, or there might be an attack...)
          o Keep statistical records for the keys/fingerprints (I've
            seen this fingerprint associated with emails associated with
            this user 90 times, whereas this one has only shown up
            twice), potentially also keep record of when the various
            keys were discovered
          o When the user goes to encrypt something to someone, if
            there's _any_ ambiguity, stop the process and explain the
            potential for an attack to be going on (suggest out-of-band
            verification techniques and provide a way to specify which
            fingerprint should be trusted as well)
    * Promiscuously share full PK data
          o This has significant privacy concerns (you often don't want
            people to be able to discover who you are corresponding with)
          o It requires the MiTM attacker to be basically everywhere
    * Allow for key-server integration
          o Those currently using encryption generally are using a
            key-server, so it's important for acceptance anyway
          o Allow for easy querying of a key-server (and automatic
            addition of a certificate found there to a user), for instance:
                + you click on a red (not ready) "encrypt" button
                + a given user's certificate isn't yet known
                + explain that the user's certificate isn't yet known
                  and offer to check a keyserver (using SSL, of course)
                + check some list of key-servers with the user's
                  standard meta-data
                + present the resulting certificates for consideration
                  ranked by similarity to known facts about the user
          o Mass-checking of certificates?
    * Where possible, use direct connections for verification
          o Harder to intercept a direct socket connection than to gain
            control of a mail-server
    * Use inter-message tying
          o "This is the fifth mail sent to you with this key,
            signatures for last 3 messages were..."
    * Allow for creating explicit "introduction" messages
          o That is, a known person (someone whose key is widely
            distributed), sends a signed message with a set of "person"
            identifier to certificate mappings

Okay, have fun,
Mike

Andy Hertzfeld wrote:

> I wrote up some ideas about automatic secure email in a paper posted 
> on our website at 
> http://www.osafoundation.org/automatic_secure_email.htm . I'm also 
> including it below.  Please let us know what you think.
>
> -- Andy

...

>    We are interested in your feedback about the approach outlined 
> above.  Is automatic encryption as described above a worthwhile goal, 
> or will it cause more trouble than its worth, especially during the 
> early stages of adoption.  What can be done to ease the transition?
>
>    Other open issues include determining the structure of the profile 
> and what information it contains.  Hopefully, we can leverage xml to 
> allow an extensible framework, where clients can include optional 
> information in custom namespaces.  Is requiring a hash-cash puzzle in 
> the request worthwhile or is it adding too much complexity?  What kind 
> of algorithm should it use?
>   We're also interested in an analysis from a security point of view.  
> What kind of attacks is our scheme subject to, and what can we do to 
> remedy them?  Is there anything we can do to make "man in the middle" 
> attacks harder?

...

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/