Good morning, Singapore!
A few of us from the MAMI project started arriving in Singapore on Friday, in order to participate in the hackathon, which has become an IETF tradition. A few hours later we were at our tables, Thomas Fossati and James Bulmer working on a STAR Requests implementation, and Brian Trammell sitting with the QUIC and TLS tables to work on passive measurability of the protocol with mokumkuoren. We had a day and a half of fun coding, patching specs, improving test coverage, and generally hacking about. Pretty good progress indeed, a few nice chats with old and new friends and great food and beers. Thank you hackathon organisers!
Test coverage improved by the end of the hackathon…
The next step for STAR is to get the e2e demo up & running on our dear Blue Box with a miniaturised but fully functional CDN talking to an ACME STAR CA in time for IETF 101 in London in March.
Back to the hotel we posted acme-star-01, since we had missed the pre-IETF cutoff date and we needed people to get a chance to glance through the changes which had been quite abundant. The updated draft includes an “implementation status” section (as per BCP205) documenting the work that Diego De Aguilar Cañellas has done on top of Boulder and Certbot (LetsEncrypt’s server and EFF’s client, respectively) to add the new STAR flow in ACME.
Then Monday arrived, and the meeting started. Diego went to TRANS to talk about ACME STAR (slides) and discuss the cost that an increase in log ingestion of one or two orders of magnitude poses on the Certificate Transparency infrastructure. Based on the observation that all STARs belonging to the same ACME order are basically equivalent modulo their validity dates and serial number, we also prepared and presented a napkin design that uses a new SCT type to address the scale problem. The discussion (youtube link) was, as often happens in the IETF, very instructive but inconclusive. We went away without a clear answer whether this is going to cause troubles or not. The reactions up to this point are scattered all over the spectrum, ranging from “omg, this will melt the world” to “nah, the log can cope” to “meh, future problems”.
Monday’s session of the Measurement and Analysis of Protocols research group (MAPRG), co-chaired by Mirja Kühlewind, included a presentation by Brian of Principles for Measurability in Protocol Design (slides). This paper articulates our vision for measurement as a first-class function of the protocol stack.
Another meeting of the not-very-secret Post Sockets cabal
Tuesday started off with the Transport Services (TAPS) WG, where discussion focused on whether the working group should take on work in defining abstract programming interfaces for applications atop a dynamic . Here, discussion focused on Post Sockets, a realization of MAMI’s flexible transport layer (FTL). We came to no conclusion, but will schedule a meeting in the margins of our upcoming plenary in Cambridge in January to further develop Post Sockets into an architecture for flexible transport services.
The QUIC mic line (©Stonehouse Photography)
The first session of QUIC was Tuesday afternoon. A slightly congested mic line and very robust discussion surrounded the wrap up of the design team for the “spin bit”, designed to provide explicit passive measurability of end-to-end latency in QUIC flows, replacing TCP timestamps for this purpose. While the design team itself was unable to come to consensus to add the spin but to the protocol (though it did conclude that passive latency measurement poses no known threat to privacy), there was a balance of support in the room for adding passive latency measurability to the protocol, and a sense that the spin bit is a good method for doing so. However, work to achieve consensus is ongoing; watch this space for future posts about our experiences with implementation and use of the spin bit.
Thursday was definitely a busy day. In TLS we did the call for adoption for the connection identifier for (D)TLS. That went really smooth and the draft has been adopted – pending confirmation on the mailing list, obviously. The co-authors have slightly different opinions on a few key points, including implicit vs explicit signals and the protocol friendliness to troubleshooting (deja-vu?). But we all agree this solves the big issues related to connection migration and NAT rebinding that we already discussed in a previous post and the important thing here is that the TLS working group reckons this is worth spending working group cycles on.
Thursday afternoon saw the second meeting of the Path Aware Networking research group (PANRG), and included presentations on path property dissemination and interfaces for path control (hello again, Post Sockets), as well as an examination of open questions in bringing path awareness to the Internet architecture. We see the general area of path-aware networking as being an unexpected legacy of the project.
Later, in the ACME session we presented the updates we’d been working on in the months following Prague. The document is in good shape, the protocol flow should be stable and my impression is that once we complete the security and operational analysis, the document should be ready for last call. After ACME, we had another informal STAR-centred meeting organised by Yoav to talk about generic short-lived certificates that automatically renew which may or may not depend on the ACME ecosystem – for example, based on ANIMA, or on proprietary systems – and may or may not address the HTTPS use case and address instead IPsec, non-web uses of TLS & SSH in enterprise and datacentre-type environments. The meeting was well attended with more than 20 people at the table (a couple of CDNs, middlebox vendors, web folks, mobile network operators, academia, other SDOs) all bringing their own experience and perspective on the issues related to certificate revocation (one of the core motivations to look into STAR) and the solution space. The discussion was great – with use cases in NSF, vehicle-to-vehicle, SAN, IPsec, and of course the Web – though a tad too short: many had to run, including Diego and I to our traditional MAMI dinner 🙂 One core thing that was concluded is that the “short” in short-term is a very fluid concept and must be defined on a case by case basis. In fact, the exact definition of “short” should match the time it takes to the revocation information (CRL and/or OCSP) to propagate to the relying parties. We hope to continue the exchange on the SAAG list or maybe in an ad-hoc list.
With that, we bid farewell to Singapore! See you all at IETF 101 in London!