IETF: March 2009 Archives


March 27, 2009

Sorry about the lack of content last week—was at IETF and just didn't have time to write anything. I should have some more material up over the weekend. In the meantime, check out this photo of the bathroom sink at the Hilton where we were having the conference:

That thing to the left of the sink is an automatic soap dispenser (surprisingly, powered by a battery pack underneath the sink). Now notice that the sink itself is manually operated. Isn't this kind of backwards? The whole point of automatic soap dispensers and sinks in bathrooms is to appeal to your OCD by freeing you from having to touch any surface which has been touched by any other human without being subsequently sterilized. But when you wash your hands, the sequence of events is that you turn on the water, wet your hands, soap up, rinse, and then turn off the water. So, if you have a manually operated sink, people contaminate the handles with their dirty, unwashed hands, which means that when you go to turn the sink off, your just-washed hands get contaminated again. The advantage of automatic faucets, then, is the automatic shutoff, which omits the last stage. By contrast, having the soap dispenser be automatic doesn't buy you that much because you only need to touch it before washing your hands. There's probably some analogy here to viral spread in computer systems, but for now let's just say that this is how security guys think.


March 24, 2009

Leslie Daigle just summed up the situation with IPv6 at today's ISOC IPv6 press event: "It's [IPv6] sort of a broccoli technology; good for you but not necessarily attractive in its own right."

UPDATE: Corrected the quote a bit. Thanks to Greg Lebovitz for the correction.


March 20, 2009

From my review of draft-meyer-xmpp-e2e-encryption-01:

The context of this draft is that currently messages in XMPP from to go through Alice and Bob's
respective servers ( and in transit.  This
implies that Alice and Bob need to trust their servers both to enforce
appropriate security policies (i.e., to make sure there is TLS along
the whole path if appropriate) and not to actively subvert security as
by message sniffing, injection, etc. The purpose of this document is
to allow Alice and Bob to establish an end-to-end secure cryptographic
channel that does not rely on the server for security.

Before talking about the draft details, it's important to get clear on
the threat model. In particular, we need to be clear on how much the
server are trusted. There are at least three plausible models:

- The server is trusted completely (the current system).
- The server is trusted to authenticate Alice and Bob,
  but should not see the traffic.
- Server not trusted at all.

Clearly, we're trying to do better than the first of these, so it's
between the second two.  For contrast, in SIP (cf. RFC 4474) the basic
assumption is that that proxy (the server) owns the namespace
associated with it. So, for instance, if decides it wants
to take the name "" away from Alice and give it to
her sister "Alice", it can. So, the proxy is trusted to authenticate
Alice, but shouldn't see the traffic, i.e., the second model.

The security requirements for these two are different. In particular,
in the second case, you need some independent mechanism for Alice and
Bob to authenticate each other. 

I think it's important to be clear on which of these environments
you think is the dominant one. I'm sure there are *some* cases
where people don't trust the servers at all, but I suspect in most cases
they just want (1) not to have to trust the server to enforce security
policy and (2) deter casual sniffing by server operators. In these
cases, a model where the server authenticates the users for an
E2E connection (a la DTLS-SRTP) is appropriate. If that's a common
model, then forcing all users to use a secure independent channel
just because some want to is going to be a very serious inconvenience.
My instinct is that that's a mistake.

The design of a system in which the servers vouch for the users identities
is fairly straightforward, with DTLS-SRTP as a model: the servers simply
authenticate the users and then pass on digests of the user's certificates
(as provided by the user) along with an authenticated indication of the
user's identity (a la RFC 4474 or even the current TLS model)
and the end-to-end connection is compared to these fingerprints.

As noted above, the design of a system in which the servers aren't trusted
is significantly more complicated. Roughly speaking, thre are three
major techniques available here: key/certificate fingerprints, a
shared password, and a short authentication string. See
[] for
some background here.

I think it's generally agreed that fingerprints are too much of a hassle
for regular use, though if your model was that most users would be
happy without it, then you might think that they would be OK for 
the exceptionally paranoid. 

This leaves us with SAS and shared passwords. The important interface
differences here are as follows:

- The SAS must be verified *after* the connection is set up. The password
  must be set up before hand.
- You can use the same password with multiple people semi-safely. 
  The SAS is new for every message.
- SAS probably requires modifying TLS. There are existing mechanisms 
  for passwords.
- The SAS is "optional" in the sense that you can generate it and not
  check it. The password is "mandatory" in the sense that if it's
  specified, it must be supplied or the connection will not be set up.

Passwords can be further broken down into two variants: ZKPP/PAKE
schemes and ordinary PSK schemes. The relevant differences between
these two are that PSK schemes are susceptible to offline dictionary
attack but that ZKPP/PAKE schemes have a much more problematic IPR

Finally, there is the question of where the authentication is done.
As I noted above, TLS has existing PSK and SRP mechanisms. However,
one could also add at least password and PAKE mechanisms to 
SASL if one wanted and use a channel binding to connect the two.

More to come at the XMPP2 BOF next week in San Francisco, which BOF for some unknown reason, I'm chairing.


March 10, 2009

Over the past few years I and a few collaborators have been working to develop a better system for key establishment for standards-based real time voice (i.e., SIP/RTP). Skype already has such a system, but unfortunately it's a closed system and the available systems for SIP and RTP had some serious problems. While this job is far from finished, today the IESG approved the first round of documents describing the two major pieces of this protocol: draft-ietf-avt-dtls-srtp and draft-ietf-sp-dtls-srtp-framework. There are a few smaller documents still and the minor task of getting widespread implementations remains, but this is definitely progress. Thanks are due to everyone who contributed to this effort.