Re: [xmpp] Review of draft-ietf-xmpp-e2e-requirements-00

[Peter Saint-Andre <[e-mail]>]

On 11/28/09 4:19 AM, Bernard Aboba wrote:

First, thank you for the review. Please accept my apologies for the
seriously delayed reply. It is clear to me that, among other things, the
XMPP developer community lacks a robust conversation about e2e security.
That in itself is a problem, because we won't find good solutions if we
don't have a productive, ongoing conversation.

> Overview
> 
> The IETF has attempted (and failed) several times its efforts to specify
> e2e security for a number of protocols that make use of intermediaries. 
> These include SIP (S/MIME not implemented, SIP Identity not widely
> deployed), Diameter (CMS not implemented), RADIUS (Kerb-RADIUS not
> widely deployed) and XMPP (RFC 3923 not widely deployed). 
> 
> If there's anything we've learned from all of this, it is to think very
> carefully about the role and responsibilities of the intermediaries as
> well as the endpoint pre-requisites and usage scenarios

To my mind, we might also have learned that:

1. Security is hard.

2. End-to-end security is especially hard.

3. The lack of a robust conversation about e2e security indicates that
even geeky developers don't really care about it (let alone end users).

4. If we don't care enough to even talk about e2e security, we might not
deserve e2e security.

> What has made e2e security so hard to get right in many of the previous
> cases is that:
> 
> 1. The "tussle" between endpoints and intermediaries that we see on the
> Internet at large ends up getting replicated on a smaller scale in the
> e2e security design, without the rights and responsibilities of the
> parties ever being clearly defined;
> 
> 2. The supported endpoint credentials and the pre-requisites for the e2e
> conversation are not well matched to the relationship between the
> endpoints.

I see #1 as less significant than #2. We don't have a clear idea of what
endpoint credentials might even look like. Most conversations about
credentials assume that (a) credentials live on a server and (2) a
client needs to provide those credentials to the server in order to
authenticate (gain access to the network, retrieve data, etc.). In other
words, there is an inherent power relationship here (a "tussle" if you
prefer that language). For end-to-end security we have an even weaker
notion of credentials than we have for client-to-server security (or
server-to-server security). End-to-end "credentials" feel unnatural to
most people (and, yes, most endpoints are controlled by people). We
don't have enough experience with e2e credentials in real life, so we
have very little to abstract from in producing online credentials for
the purpose of e2e communication. Humans might understand the idea of a
password or secret to join a club or enter a fort or whatever, but that
doesn't scale very well (I can't remember the secret I need to have a
secure chat with all 2500+ people in my buddy list if I have a separate
secret for each communication partner), secrets get leaked, etc. To
solve the scaling issue we need something like public keys, but humans
don't warm up to keys, don't know how to manage them, etc. The
challenges here are significant.

> To address issue #1, "Tussle in Cyberspace" suggests going beyond
> arguments about the proper role of intermediaries to recognize the
> importance of providing flexibility to the domain administrators to
> express their preferences.  In this particular case, this would involve
> recognizing that not all domains allow their users to set up e2e
> security, so that domain administrators require the flexibility to
> express their preferences on this (and potentially other) aspects.  So
> if the Capulets and Montagues don't want Juliet and Romeo setting up an
> e2e secure session, the design should allow them to express that
> prohibition.
> 
> To address issue #2, it's helpful to think through the scenarios leading
> up to establishment of an e2e secure session.  For example:
> a.  Romeo and Juliet's conversation is fully supported by the Montagues
> and Capulets (yeah, right) so that they each have a public key
> certificate provided by the domain CA.

Much of the thinking in the XMPP community (and wider messaging
community) seems to assume that it's none of the intermediary's business
whether Romeo and Juliet want to have a secure session, the parties have
a right to do so and the intermediary cannot intervene without tramping
the rights of the parties, etc. That assumption does not obtain in many
scenarios (e.g., my messaging account is provisioned by my employer and
I am allowed to use it only so long as I fulfill the conditions of
employment). On the other hand, it is unrealistic and IMHO flat out
wrong to expect a journalist working in an autocratic country (say) to
ask permission before negotiating a secure session. However, from whom
would such a person ask permission? Only of her server, not the
authorities. If your server doesn't allow you to negotiate a secure
session, find a better server or run your own (that's what decentralized
technologies are for in the first place).

> b.  Romeo and Juliet are able to exchange a (weak? strong?) shared
> secret out-of-band prior to attempting to set up an e2e security
> association.

For people who really care about security, bootstrapping the XMPP
channel from some other secure channel seems reasonable. Or, at least,
using multiple channels in quick succession so that an attacker would
need to compromise (say) email and phone and web instead of just XMPP.
That appears to be good enough for most people. Furthermore, because
XMPP provides a communication network, we also might have ways to check
fingerprints with other entities on the network (e.g., I might know that
the fingerprint for X's key is Y and you might trust me to answer
truthfully about X's fingerprint).

> c.  Romeo and Juliet meet by accident (perhaps in MUC?), and go off for
> the first (of many?) private chats.  Since they don't have an
> out-of-band mechanism for establishing credentials, they instead only
> seek the assurance that they are communicating with the same (user?
> device?) that they contacted initially. 

This is a harder case, but it seems to be what lazy end users expect.
Whether lazy people deserve security is another question...

> So in reviewing this document, I looked for details relating to issues
> #1 and #2. 

That's helpful, thanks.

> Detailed Review
> 
> Section 2
> 
> This section seems to define the right scope.
> 
> Section 3
> 
> I'd suggest that you are going to take a position in this section about
> the acceptability of "leap of faith"  (e.g. scenario c above).   It is
> one thing to be vulnerable to a MiTM or Deletion attack on a first
> encounter;  it is another thing to have this vulnerability on every
> encounter.   Elsewhere in the document, it suggests that scenario c is a
> valid use case, so I'd suggest that it might be worthwhile clarifying
> this in Section 3.

Agreed. I've added a paragraph about that.

> Section 4
> 
> Within Confidentiality, the definition of "only to the extent required
> to route them" requires more clarification.  Keep in mind that the
> Capulets and Montagues may have somewhat differing ideas about what
> information they "require" prior to agreeing to route a message than
> Romeo and Juliet do.  For example, Financial institutions have logging
> requirements.  As an example, is it sufficient to only make the domain
> of the destination visible to the originating server, but not the
> destination username? This would allow the House of Capulet to know that
> one of their members was communicating with the House of Montague, but
> perhaps not that Juliet was communicating with Romeo.

I've added some clarifying text.

> PKI Independence:  Rather than talking about what credentials are *not*
> required, it might be useful to go through what set of credentials you
> envisage supporting.  In particular, the variation in credentials is
> important.  For example, will you need to support weak passwords as a
> credential, or is it possible to assume a pre-shared key? 

That's hard to know. The possibilities include self-signed certificates,
pre-shared keys, and shared secrets (at least for bootstrapping). I
agree that it's better to focus on what's supported than on what's not
supported. I've adjusted the text accordingly.

> Authentication:  Do you really want to require that authentication prove
> the precise identities of the parties, or merely that it prove the
> possession of a credential (which might have been established in-band at
> a first meeting)?  Given the objection to mandating PKI, requiring a
> definitive identity proof is somewhat of a contradiction. 

Agreed. I've cleaned that up a bit.

> Identity protection:  I think we need to define what "no other entity"
> means here.  The server run by the Capulets authenticates Juliet and the
> server run by the Montagues authenticates Romeo, so surely these servers
> can identify them also.  To route messages between the servers, it would
> seem that the destination JIDs also need to be visible.  Given this, it
> would seem that "no other entity" refers to entities other than the
> servers run by the Capulets and Montagues.  Is that right?  

Yes, that's right. Clarified in the text.

> Or are we
> trying to keep the identity of the originator from the destination server?

We are not. IMHO that's out of scope.

> Robustness: Is this trying to capture the ability to negotiate
> key-strength, or is it expressing a potential need for multiple factor
> authentication or key generation?  I wasn't sure on reading it. 
> Certainly, it's a good idea for keys to be generated based on
> contributions from more than one party, in case one of the parties has a
> poor quality random number generator.

I don't think this requirement is well-worded at present, but I think it
is trying to say that we want it to be hard to attack the protocol
because the protocol has multiple lines of defense.

> Upgradeability:  Are you referring to crypto-agility here (e.g. the
> ability to negotiate ciphersuites, including key management algorithms)?
> If so, it might be helpful to clarify exactly what is required to be
> negotiable and what doesn't.

As I understand it, the upgradability requirement refers to the protocol
as a whole as well as to components thereof (such as cryptographic
hashing algorithms).

> Section 5
> 
> Implementability.  While it's hard to argue with this paragraph,
> depending on the definition of "robustness" it is possible that a
> different *version* of TLS might be required for e2e than might be
> acceptable for transmission-layer security (e.g. TLS 1.2 vs. 1.0 or
> 1.1).  So you might want to think about whether you're willing to
> require that an e2e secure implementation have the "latest and greatest"
> TLS and SASL implementations. 

Naturally, there are tradeoffs. However, one of the problems we've faced
in the XMPP community is that none of the e2e security technologies
we've developed over the years has been particularly easy to implement
and deploy.

> Usability.  As with the "no PKI requirement" statements earlier, I'd
> like to see the potential scenarios defined somewhat more.

I agree that this needs to be defined more clearly.

> Efficiency.  Reading this, I'm not clear how I would apply it to judging
> whether a particular scheme is efficient or not.  For example, there are
> tables describing how long certain cryptographic operations take on
> various processors -- but this by itself won't rule almost anything
> out.  For example,  TLS only utilizes public key operations during key
> exchange, and the keys can be reused across sessions via session
> resume.  Given this, even fairly large RSA key sizes could be considered
> efficient. 

True. More discussion is needed.

> Flexibility.  How is this different from upgradeability?  Is this
> another reference to crypto-agility?  Or is this more about credential
> types? 

I don't think it's much different from upgradability, if at all. I think
we can probably merge these two requirements.

In fact the section on application requirements is rather vague in many
places, and I think we need to tighten things up.

> One thing I don't see here is the expression of a preference with
> respect to encumbrance or key strength.  For example, must the
> mandatory-to-implement algorithms be unencumbered?   What key strengths
> need to be supported?  Is there a preference for support of FIPS
> certified algorithms? (e.g. no use of SHA-1 in signatures). 

My feeling is that we'd probably prefer unencumbered solutions (in line
with BCP 79) and prefer FIPS-certified algorithms. I'll try to formulate
some text along those lines.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/