[Security] Re: e2e feedback

[Peter Saint-Andre]

Matthias Wimmer wrote:
> Hi!
> 
>> We received some initial feedback from an IETF security guru regarding 
>> encrypted sessions (XEP-0116 etc.). He thinks that, based on our 
>> requirements, we could simply re-use TLS semantics in XMPP syntax 
>> rather than define a completely new security protocol (which is 
>> considered to be a bad idea). Essentially this would treat XMPP as the 
>> transport layer, so instead of doing TLS over TCP (as we do for 
>> channel encryption) we would do TLS over XMPP for encrypted sessions 
>> between endpoints, where we communicate TLS primitives in XML syntax.
> 
> I had this concern about defining a new cryptographic protocol as well
> some time ago, when I asked Ian, why at all he is designing a completely
> new protocol. I think it is a very good thing, that we got input from the
> outside as well, that we should not do this.
 >
> While on the other hand I am not sure if mapping TLS on XMPP solves all
> our problems. - At least for now. It may change when
> draft-hajjeh-tls-sign-02.txt gets finished.

In non-repudiation in our requirements?

> But still I keep saying that the protocol we are looking for is XML
> Signature and XML Encryption, that have been defined by the W3C.
> http://www.w3.org/Signature/
> http://www.w3.org/Encryption/2001/
> This are standards specially made to sign and encrypt XML data, so it is
> exactly what we need. And even while I asked on the standards JID, nobody
> could yet tell me, what would be a problem with this standards. (Maybe
> beside, that some people just seem to want to create their own 
> cryptographic
> standard. But this is nothing that can be done by anyone, but just by a
> group of people with review of even more people.)

Does xmlenc+xmldsig provide perfect forward secrecy (PFS)? PFS means 
that even if your private key is compromised, no one will be able to 
read messages that have been encrypted with that key in the past.

> So mapping TLS on top of XMPP might be one option for me, while I think we
> should also very heavily consider the w3c standards for this. But with
> XEP-0116 I am still very very sceptic.

We have had 6 (!) different proposals for e2e encryption over the years:

1. OpenPGP (XEP-0027)

2. S/MIME (RFC 3923)

3. xmlenc+xmldsig (never formally proposed or spec'd out)

4. Off-The-Record Communications (OTR) -- never formally proposed but 
informally discussed (e.g., we could base64-encode the complete stanza 
and force it into the OTR message body)

5. ESessions (what Ian has been working on in XEP-0116 etc.)

6. "XTLS" (XMPP Over TLS)

None of these has ever been widely deployed -- probably OpenPGP is the 
closest we've come to that.

AFAICS, both OpenPGP and S/MIME are non-starters because very few end 
users have PGP keys or X.509 certs.

AFAIK, xmlenc+xmldsig does not provide PFS.

OTR is a possibility (there are existing libraries) but munging an 
entire stanza into base64 and then forcing it into the OTR format seems 
messy. However, implementation would happen quickly. :)

ESessions addresses all of our requirements (PFS, repudiability, etc.) 
but it's new (although based on SIGMA).

XTLS has not yet been scoped out or proposed. I'm still trying to 
understand exactly how it would work, but it has potential. It would be 
nice if TLS included the ability to communicate a short authentication 
string (SAS), but that may be added as a TLS extension since other folks 
are interested in it.

Are there are other proposals on the table? Am I missing anything?

Ian defined a set of requirements here:

http://www.xmpp.org/extensions/xep-0188.html#reqs

It would be good to get agreement on the requirements first so that we 
can determine which technologies can help us address those.

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20070316/c58b6b07/smime-0001.bin