On Sun, Mar 13, 2016 at 8:51 PM, Colm MacCárthaigh <c...@allcosts.net> wrote:
> 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 > Can you expand on this. Cryptographically, this is effectively how both the DHE and PSK modes work: you get a key in session N (which is authenticated) and you use it in session N+1. -Ekr . 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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
