On Sun, Mar 13, 2016 at 4:14 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> With 0rtt, I think it also becomes a dangerous > implement. So, that's my personal opinion, while not wearing an > AD hat. > +1 for this as 0RTT is outlined in the draft. But to expand a little: * Losing forward secrecy for "GET" requests and user cookies seems like a very bad privacy trade-off. Collection of wire data, combined with a bug or an attack that could disclose the ECDH parameters, does not seem so far fetched these days. * I imagine that 0RTT data may be intended for pre-fetching hints, e.g. "I'm request URL foo as user bar, so please get a start on fetching the resources I need". That suggests trivial application-level "is the cache warm" side channels, or "lets trash the whole cache" DOS attacks, would both be common. * A vast number of APIs build on top of TLS/HTTPS are not idempotent or replay safe. Even carefully designed APIs may have subtle side effects such as a user being charged for the request, or the request counting towards a throttle of some kind. Even ones as silly as there go your 10 free nytimes articles; or booting an opponent out of your less-than-friendly sudoku tournament. * The draft calls out that early data needs to be handled differently than regular TLS data. This reminds me of the problems with renegotiatable client authentication - similar to what Marsh Ray highlighted a long time ago. What if a request or action spans both the early and the regular data sections? what would a "safe" API look like, for an SSL/TLS library layer? It seems like the benefits of of 0-RTT boil down to two things; 1. Increased throughput 2. Give the recipient a chance to a get a head-start on servicing some kind of request. For 1. Raw data throughput could be improved by envelope encrypting the early data; and transferring the envelope key only once the session has been fully authenticated. Not that interesting to most people; but works. I can't think of a good way to achieve 2 without all of the problems that have been mentioned. At a minimum I'd suggest that the draft could not call it "data", but maybe instead "hint"; and make it so that early_data and application_data are not supposed to appear sequentially in a stream. E.g. someone calling TLSRead() or whatever should never expect to see the early_data; it's a deliberate and separate stream. -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
