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

[Bernard Aboba <[e-mail]>]

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

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.


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.
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.
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.

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

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.

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.

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?

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.

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?  Or are we trying to keep the
identity of the originator from the destination server?

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.

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.

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.


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

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.

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

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).