Recently in IETF Category

 

April 9, 2012

The IETF RTCWEB WG has been operating on a fast track with an interim meeting between each IETF meeting. Since we needed to schedule a lot of meetings, thought it might be instructive to try to analyze a bunch of different locations to figure out the best strategy. Here's a lightly edited version of my post to the RTCWEB WG trying to address this issue.

Note that I'm not trying to make any claims about what the best set of venues is. It's obviously easy to figure out any statistic we want about each proposed venue, but how you map that data to "best" is a much more difficult problem. The space is full of Pareto optima, and even if we ignore the troubling philosophical question of interpersonal utility comparisons, there's some tradeoff between minimal total travel time and a "fair" distribution of travel times (or at least an even distribution).

METHODOLOGY
The data below is derived by treating both people and venues as airport locations and using travel time as our primary instrument.

  1. For each responder for the current Doodle poll, assign a home airport based on their draft publication history. We're missing a few people but basically it should be pretty complete. Since these people responded before the venue is known, it's at least somewhat unbiased.
  2. Compute the shortest advertised flight between each home airport and the locations for each venue by looking at the shortest advertised Kayak flights around one of the proposed interim dates (6/10 - 6/13), ignoring price, but excluding "Hacker fares". [Thanks to Martin Thomson or helping me gather these.]

This lets us compute statistics for any venue and/or combination of venues, based on the candidate attendee list.

The three proposed venues:

  • San Francisco (SFO)
  • Boston (BOS)
  • Stockholm (ARN)

Three hubs not too distant from the proposed venues:

  • London (LHR)
  • Frankfurt (FRA)
  • New York (NYC) (treating all NYC airports as the same location)
Also, Calgary (YYC), since the other two chair locations (BOS and SFO) were already proposed as venues, and I didn't want Cullen to feel left out.

RESULTS
Here are the results for each of the above venues, measured in total hours of travel (i.e., round trip).

Venue         Mean         Median           SD
----------------------------------------------
SFO           13.5             11         12.2
BOS           12.3             11          7.5
ARN           17.0             21         10.7
FRA           14.8             17          7.3
LHR           13.3             14          7.5
NYC           11.5             11          5.8
YYC           14.9             13         10.2
SFO/BOS/ARN   14.3             13          3.6
SFO/NYC/LHR   12.7             11.3        3.7
XXX/YYY/ZZZ is a three-way rotation of XXX, YYY, and ZZZ. Obviously, mean and median are intended to be some sort of aggregate measure of travel time. I don't have any way to measure "fairness", but SD is intended as some metric of the variation in travel time between attendees.

The raw data and software are attached. The files are:

home-airports: the list of people's home airports
durations.txt: the list of airport-airport durations
doodle.txt: the attendees list
pairings: the software to compute travel times
doodle-out.txt -- the computed travel times for each attendee

This was a quick hack, so there may be errors here, but nobody has pointed out any yet.

OBSERVATIONS
Obviously, it's hard to know what the optimal solution is without some model for optimality, but we can still make some observations based on this data:

  • If we're just concerned with minimizing total travel time, then we would always in New York, since it has both the shortest mean travel time and the shortest median travel time, but as I said above, this arguably isn't fair to people who live either in Europe or California, since they always have to travel.
  • Combining West Coast, East Coast, and European venues has comparable (or at least not too much worse) mean/median values than NYC with much lower SDs. So, arguably that kind of mix is more fair.
  • There's a pretty substantial difference between hub and non-hub venues. In particular, LHR has a median travel time 7 hours less than ARN, and the SFO/NYC/LHR combination has a median/mean travel time about 2 hours less than SFO/BOS/ARN (primarily accounted for by the LHR/ARN difference). [Full disclosure, I've favored Star Alliance hubs here, but you'd probably get similar results if, for instance, you used AMS instead of LHR.]
  • Obviously, your mileage may vary based on your location and feelings about what's fair, but based on this data, it looks to me like a three-way rotation between West Coast, East Coast, and European hubs offers a good compromise between minimum cost and a flat distribution of travel times.

     

    March 31, 2011

    Here at IETF 80. Doing some presentations:

    Sorry about the certificate validation errors. Blame the reSIProcate SVN admins.

     

    November 5, 2009

    Marsh Ray has published a new attack on the TLS renegotiation logic. The high level impact of the attack is that an attacker can arrange to inject traffic into a legitimate client-server exchange such that the TLS server will accept it as if it came from the client. This may allow the attacker to execute operations on the server using the client's credentials (e.g., order a pizza as the client). However, the attacker does not (generally) get to see the response. Obviously this isn't good, but it's not the end of the world. More details below.

    TLS Details
    The attack exploits TLS's renegotiation feature, which allows a client and server who already have a TLS connection to negotiate new parameters, generate new keys, etc. Renegotiation is carried out in the existing TLS connection, with the new handshake packets being encrypted along with application packets. The difficulty is that they're not otherwise tied to the channel, which gives the attacker a window. The simplest form of the attack is shown below [cribbed from draft-rescorla-tls-renegotiate.txt]

    Client                        Attacker                        Server
    ------                        -------                         ------
                                      <----------- Handshake ---------->
                                      <======= Initial Traffic ========>
    <--------------------------  Handshake ============================>
    <======================== Client Traffic ==========================>
    

    So, in order to mount the attack, the attacker first connects to the TLS server. He can communicate with the server as much as he wants, including making an arbitrary number of requests/responses, etc. This traffic is all encrypted and shown as ==. Then when he's ready, he hijacks the client's connection to the server (in practice he might start by hijacking the connection and then connect to the server but it doesn't matter) and just proxies the client's traffic over the encrypted channel. The client negotiates with the server and from that point on the client and the server communicate directly. Note that the client is communicating with the attacker in the clear but the second handshake is encrypted and goes over the attacker's channel. Thus, the client does not know that he is renegotiating. However, the server thinks that the initial traffic with the attacker is also from the client. There are also other (probably less useful) variants where both sides see a renegotiation but of different connections.

    Impact on Existing Applications
    TLS itself is just a security protocol, so the impact of this attack depends on the application protocol running over TLS. The most important of these protocols is of course HTTP over TLS (HTTPS). Most Web applications do initial authentication via a username/password pair and then persist that authentication state with HTTP cookies (a secret token that is sent with any request). An attacker might exploit this issue by sending a partial HTTP request of his own that requested some resource. This then gets prefixed to the client's real request.

    E.g., the attacker would send:

    GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 
    X-Ignore-This:
    

    And leave the last line empty without a carriage return line feed. Then when the client makes his own request

    GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1 
    Cookie: victimscookie
    
    

    the two requests get glued together into:

    GET /pizza?toppings=pepperoni;address=attackersaddress HTTP/1.1 
    X-Ignore-This: GET /pizza?toppings=sausage;address=victimssaddress HTTP/1.1 
    Cookie: victimscookie
    

    And the server uses the victim's account to send a pizza to the attacker.

    You can mount a similar attack if the server uses certificate-based client authentication: it's common (well, common in the small number of cases where client certs are used at all) for the server to let the client connect and request a resource and then if the resource is protected renegotiate asking for a certificate. The attacker can exploit this by doing the initial handshake and asking for the resource and then letting the client do the renegotiation, at which point the server acts as if the initial request was made by the client.

    It's important to note that in both the cases we just described the attacker doesn't get to see any sensitive information directly: that's just sent back encrypted to the client. However, he can exploit side effects of the exchange, e.g., to get a pizza. It may also be possible to exploit HTTP features to directly access the data. For instance, he might be able to generate a combined request that would cause the server (or perhaps somehow mirrored through the client) to send the original client request to the attacker. If the request contains the client's cookie or password, this would cause their credentials to leak. It's not clear to me if this is possible, but I'm hoping some of the Web security specialists will weigh in.

    The impact on other protocols (IMAP, SIP, etc.) would depend on those protocols and I haven't seen complete analyses of these yet.

    Mitigations
    Eventually there will be a TLS level protocol fix (see below). However, in the meantime options are limited.

    For 99+% of applications, the mitigation is very simple: the server should simply disable all renegotiation, which stops the attack. (OpenSSL will helpfully automatically renegotiate which facilitates the attack even if the application isn't otherwise set up to do renegotiation). Unfortunately, there is no similar defense on the client side. In the example I showed above, the client is unaware that renegotiation happened. Moreover, the client can't tell that the server will refuse renegotiation (it could explicitly probe but the attacker could of course fake a failure). So, the client can't really do anything useful to protect itself.

    The second drawback is that there are a small number of cases (e.g., the certificate authentication one I described above) where renegotiation actually should happen. The most practical defense on the server side is to restructure the site so that requests which require client auth are redirected to a different address or port which always requests a certificate and itself refuses renegotiation. However, this obviously requires major work on many sites.

    There are a few other legitimate reasons for renegotiation, but they're mostly things one doesn't need to do. For instance, people sometimes renegotiate to force the generation of fresh keying material. This is not necessary with modern cryptographic algorithms. Another example provided by Ray is sites that support algorithms with differential strength. Again, this isn't really necessary. Unless you're doing certificate-based client authentication it's very unlikely you need to renegotiate and if you are using it, the workaround above is the simplest.

    Long-Term Defense
    Despite the existence of some defenses, it seems clear that TLS should really defend against this. There's a fairly obvious defense that at least three people have independently come up with: carry information about handshake n-1 in handshake n (if n==1 you just carry an empty field). This prevents attacks where the client and server have different views of the negotiation state. The predisclosure group that worked on this after Ray discovered this worked to develop a draft describing this technique which can found at draft-rescorla-tls-renegotiate.txt and we'll be submitting it to the TLS working group shortly. Of course, this will take a very long time to make it into enough clients and servers to make a real difference, so for now we're mostly stuck with the mitigations I've described.

    The Software Situation
    People have also developed patches for existing implementations. These fall into two categories:

    • Just disable renegotiation (really important for OpenSSL because of the aforementioned automatic renegotiation) issue.
    • Implement the long-term fix.

    As far as I know none of these have been formally released yet. Ben Laurie's OpenSSL disabling patch can be found here. I've developed a patch that performs the long-term fix protocol pieces but it doesn't disable non-fixed renegotiation so it's usable primarily for interop testing right now. That can be found here. Expect both of these to eventually appear in official OpenSSL distributions/patches. I don't know the release status of other fixes.

    Big Picture Perspective
    Now that we've covered how this attack works, how bad is it? It's being billed as a man-in-the-middle attack, but it's really far more limited than your classic MITM. Rather, it's a plaintext injection attack. I'm not saying that's good, but we need to put it into perspective: over the past two years, we have seen two separate issues that allow a complete TLS server impersonation: the Debian PRNG bug (see our paper here for a description of the issue [which we did not discover] and its impact) and the TLS certificate "NULL" issue. Both of these issues had much more severe impact since they allowed the attacker access to all the data sent by the client. However, it's worth noting that they differed from this issue in that they were detectable/fixable on the client side so people could in principle protect themselves. As a practical matter, however, most clients never checked the Debian keys against a blacklist, so that protection was minimal at best.

    Second, it's important to remember that even simple MITM attacks with fake certificates don't seem that hard to mount. Cranor et al. report that users very frequently ignore browser warnings of bad certificates, which more or less obviates any security protections TLS provides. If the user will accept the attacker's certificate, there's no need to do anything as limited as the attack described here. Obviously, that's not information that should give you a huge amount of confidence in any form of Internet communications security, but it does provide some perspective on the marginal impact of this attack.

    One other comparison point is a remote vulnerability in the server. TLS implementations have historically had and continue to have remote vulnerabilities which would allow an attacker to subvert the server. Such an attacker could read all your traffic to that server. As with this issue, you can't really detect that from the client side and need to rely on the server being upgraded. So, this issue is somewhat less serious than a remote vulnerability in a really popular server stack like OpenSSL. It's primarily unusual because it's an issue in the protocol not the software and those are quite rare.

    Bottom Line
    As I said at the beginning, this obviously isn't good. We'd like SSL/TLS to provide it's nominal security guarantees and it clearly doesn't. There likely to be exploitable attack paths using this issue. It's far less clear whether they will actually see exploitation, given that these attacks aren't necessarily as powerful as other already known paths. In the not too distant future you should expect most important servers to have fixed, at which point most of your Web server interactions will be safe (even though you can't verify it easily). In the long term, most clients and servers will adopt the protocol fix at which point clients will be able to be sure that the servers they are interacting with are safe.

     

    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
    alice@atlanta.com to bob@biloxi.net go through Alice and Bob's
    respective servers (atlanta.com and biloxi.net) 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.
    
    THREAT MODEL
    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 atlanta.com decides it wants
    to take the name "alice@atlanta.com" 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.
    
    
    AUTHENTICATION MECHANISMS
    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
    [http://www.educatedguesswork.org/2008/08/authentication.html] 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
    situation.
    
    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.
     

    January 14, 2009

    As I mentioned earlier, the IETF managed to pass copyright terms that more or less precluded the preparation of revisions of any existing standard. Opinions differ about whether this was understood before it was passed, (see the comments on the linked post), but it seems clear that many IETFers didn't understand the implications of the new requirements when they were published. As far as I can tell, potential submissions fall into three categories:

    • Documents which contain all new text and which can be safely submitted.
    • Documents which contain at least some old text but the new contributors aren't paying attention and submit them anyway.
    • Documents which contain at least some old text and are being held because they can't be safely submitted.

    In principle, there might be a fourth category: documents which contain old text but where the contributors have obtained licenses from all the copyright holders. Unfortunately, the form that the IETF meant to provide for this purpose is, uh, broken so you're kind of on your own, unless, that is, you can convince people to sign a blank signature page. I'm not aware of any documents that fall into this category, but maybe there are some. In any case, I know a number of authors who are holding back documents because they don't believe they can obtain the necessary rights.

    The current state of play is that the IETF Trustees have proposed some new boilerplate that will go onto submissions that more or less disclaims the 5378 rights grants. Unfortunately, the current text is inadequate and it's not clear when new text will be posted, let alone approved. IETF San Francisco (March) may turn out to be pretty interesting.

     

    December 18, 2008

    This is sort of IETF inside baseball, but also a good example of how things can go really wrong even when you're trying to do the right thing. As you may or may not know, the Internet Engineering Task Force (IETF) is the standards body responsible for most of the Internet standards (TCP, HTTP, TLS, ...) that you know and hate. The IETF is a non-membership organization and participants aren't compensated by the IETF for their contributions. Moreover, most IETF participants are working on IETF standards as part of their job. This all makes the copyright situation a bit complicated, since, at least in the US, companies tend to own work you do for them in the course of your employment.

    The IETF has opted to deal with this situation with a combination notify and attest model, which works like this. There are three main ways in which people submit "contributions" i.e., text for documents, comments, etc. to the IETF:

    • As actual documents ("internet-drafts").
    • As mailing list messages.
    • As comments at IETF meetings.

    The first case is the clearest: every I-D submission is required to have a boilerplate license grant attached to it, or rather a reference to a license grant. It looks (or at least until recently) something like this:

    This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

    That's the attest part. But what about submissions on mailing lists, stuff said at the mic at meetings, etc.? It's not really practical to expect people to start every comment with a copyright statement. Instead, the IETF has a general policy on submissions which you're given a copy of when you sign up for an IETF meeting or join a mailing list. (This policy is colloquially called "Note Well" after the title of the document). Contributing once you've read the statement is deemed to be an acknowledgement and acceptance of the policy. Note: I'm not a lawyer and I'm not taking a position on whether this will hold up in court. I'm just reporting how things are done.

    OK, so you have to agree to some license terms. But what are those terms? Until recently (confusingly, the date is a bit uncertain), they were approximately that the text in your document could be reused for any IETF purpose, e.g., you could republish them, prepare derivative works for the purpose of doing revisions, etc. So far so good. Once documents were in the IETF system you could pretty much do anything IETFy with them, since you could safely (at least that's the theory) assume that the authors had granted the appropriate rights. What you couldn't do, however, was take text out of the documents and use them to prepare documents for some other standards body such as OASIS, ITU, etc. Anyway, IETF decided that it was a good idea to fix this and so a new set of license terms were prepared which involved granting this additional set of rights (the details are actually quite a bit more involved, but not really that relevant). Moreover, the new rules required IETF contributors (i.e., document authors) to attest that they had the right to submit the document under these new terms.

    This last bit is where things started to go wrong. Consider what happens if you want to prepare a revision of some RFC that was written before the rule change. Ordinarily, you could do this, but now you need to submit under the new rules, and moreover you need to attest that you've obtained the necessary permissions to do so. But since all you know is that the document was submitted under the old rules, you need to go back to every contributor to the original document and get them to provide a more expansive license grant. That's fairly inconvenient already, but it gets worse. IETF doesn't really keep records of who contributed which piece of each document (remember: if it's in the system it was supposed to be automatically OK), so you don't actually know who you're supposed to contact. Even if you just take the list of people who were acknowledged in the document, this can run to tens of people, some of whom might have changed employers, died, or whatever. So, there's a reasonable chance that some documents can't practically be revised under these terms, and some IETFers are already avoiding contributing documents they would otherwise have submitted. The IETF hasn't totally ground to a halt yet, presumably due to some combination of virgin submissions, participants unaware of the issue, and participants aware of the issue but assuming they're not going to get caught.

    Unfortunately, this didn't quite get figured out (for some unknown reason, people aren't really excited about spending a lot of time reading licensing agreements) until it was too late and the terms were already in effect. Next step: figure out how to unscrew things. Outstanding!

     

    March 20, 2008

    After all my complaining about the xml2rfc bibliography system, I decided to do something about it. I thought for a while about hacking xml2rfc itself, but after spending a while reading the crufty tcl code in xml2rfc, I decided it might be easier to do a secondary bibliography management tool in the style of bibtex.

    There are two tools:

    • bibxml2rfc: the bibliography manager. It runs through the XML file, finds everything that looks like a reference, and the builds a pair of bibliography files (one for normative and one for informative) for inclusion into your XML file. It automatically fetches reference entries for RFCs and Internet Drafts. You can use ordinary XML inclusion techniques so you don't need to modify the XML file reference section when the bibliography changes.
    • bibxml2rfc-merge: a tool to make merged files for submission. The Internet Drafts submission tool won't accept a bunch of separate XML files, so bibxml2rfc-merge merges them into one for submission. You don't need this for your ordinary work.

    The source can be found at: https://svn.resiprocate.org/rep/ietf-drafts/ekr/bibxml2rfc. Documentation for bibxml2rfc can be found at https://svn.resiprocate.org/rep/ietf-drafts/ekr/bibxml2rfc/bibxml2rfc.txt