[messaging] Opportunistic encryption and authentication methods

[Dave Crocker]

G'day.

Very nice note.

Thoughts...


On 9/3/2014 4:37 PM, Trevor Perrin wrote:
>  * Authenticating a public key is harder than distributing it.

As phrased, this is an interesting point.  I don't recall seeing this
phrasing before, in spite of all the recent OE discussion, but I haven't
been deep in the topic until quite recently.  At the least,
distinguishing between authenticating a key vs. distributing does seem
quite useful.

As phrased, the implication is that distributing keys isn't a
significant barrier and to that I'll take exception, other than highly
localized distribution, such as during a session.

That's probably exactly the scenario you have in mind, but I'm also
thinking of cases in which there is a linkage claimed between an
identifier and a key, but that the linkage isn't necessarily 'validated'.

Perhaps that should be declared out of scope, but I thought it worth
mentioning.

So yes, authenticating a key/identifier linkage might be harder, but as
of now, we have no solution for distributing keys at Internet scale, if
they have persistent linkage to an identifier.


> This has traditionally been controversial:  An
> encrypted-but-not-authenticated connection is vulnerable to active
> attack, so OE might not be worth much.  It might even have negative
> value if it gives a false sense of security.

>From the recent IETF list discussion, points raised by Bernard Aboba:

     https://mailarchive.ietf.org/arch/msg/ietf/nGXy1kOYaNCZWvstaBTE3Rznrxw

     https://mailarchive.ietf.org/arch/msg/ietf/q4L2jlEe9sEZTlLfxW2mTUHbkPU



> OE for email-like messaging
> ------
> There's another argument for OE in the person-to-person case:
> 
> 4) In the absence of widespread OE, users who publish their public key
> and encrypt conversations will draw unwanted attention.
> 
> There's a new argument *against* widespread OE in the asynchronous
> messaging case:  A key directory might get out of sync with a user,
> and return a public key that the user has (for example) lost the
> private key for.

Hmmm.  There are two lines of discussion/effort here.  One is for
pervasive opportunistic TLS.  This is hop-by-hop OE, which isn't
technically distinctive from typical uses.  It merely gets messaging
links encrypted.

That doesn't provide any protection within the handling nodes, of
course, which is where e2e object-based encryption gets more
interesting.  And that is where things like per-user keys become the
challenge.

The concern for a directory being out of sync is of course valid, but
it's secondary to our entirely lacking any directory service that's
workable for distribution at Internet scale, for every Internet user.

Using OE for object-based encryption is something I haven't noticed
discussion about.  Interesting idea, though I am not sure I know how it
could work.


> I'll contend that 1-4 make a good case for widespread OE, and the risk
> of messages encrypted to an out-of-sync public key is manageable:
> 
>  * At minimum, a service provider could implement a sort of "half-OE"
> by registering key pairs for users and simply holding the private
> keys.  This would hide to outsiders whether the user had opted for
> full end-to-end encryption, and would provide some confidentiality for
> messages that flow through multiple providers (like email; this is an
> idea from UEE [21]).

(You might consider having the UEE doc use RFC 5598 (Internet Mail
Architecture) vocabulary.  There was 5 years of community debate to
produce that document...)

Your UEE document sets the task:

     "For users who wish to manage their own key, and face the
difficulties of Key Management themselves, we recognize our current
e-mail encryption tools are harder to use than they must be for
widespread adoption."

Unfortunately the track-record in the UX/UI world seems pretty clear
that having users manage their keys is not scalable.

More generally, the UEE proposal is really for 'originator' to
'receiver'.  That is, from the author's operator to the recipient's
operator.  For the capability being discussed, there doesn't seem to be
any incremental benefit in having the granularity be per-user.
Per-domain suffices.

That let's you invoke a DKIM-like model, which works at the domain level
and which is known to work well for authentication and ought to work as
well for encryption.  In fact, see:

   http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_1.pdf

It's authentication oriented but would be easily adapted to encryption
uses, IMO.


>  * A service provider could store most users' private keys encrypted
> by a password, so that even a lost device doesn't result in
> undecryptable messages.  A user could try password cracking in the
> worst case of a forgotten password.

The essence of your model is to trust the user's operator.  That's fine
in some circumstances, but not others.


> B) Since widespread OE would limit provider-based spam and malware
> filtering, figuring out how to move these to the client is important
> [10].

It has the anti-abuse community quite worried.

The two paths that probably need to be followed are to get better at
using domain names for reputation assessment, and to move filtering
engines to run in the recipient's MUA, or their operator's server if the
operator is providing encryption control.


> FINGERPRINTS: Compatible with OE since users could "stealthily"
> communicate about fingerprints out-of-band, there's no effect on users
> who don't, and no scaleability issues.  In conjunction with TOFU, this
> is Moxie's "simple thing" argument [11,12].

But fingerprints requires first having candidate keys that are linked to
identifiers.



d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net