On Tue, Mar 15, 2016 at 3:51 PM, Bill Cox <waywardg...@google.com> wrote:
> I think it is worth documenting what we feel would be the simplest secure > 0-RTT mode that is safe for any company to use. I think we owe the users a > link to such a document in the TLS 1.3 spec. Here is my attempt at > creating the simplest possible TLS 1.3 compatible safe 0-RTT scheme. It > uses a traditional server-side session-cache. > Thanks for the awesome write up! This helped me clear my thinking a lot, especially the proof. > During a 0-RTT resumption handshake: > - Get the session ID from the ticket, check for a cache hit, and drop to > 1-RTT if not found > - compare the resumption counts in the session state and ticket, and fall > back to 1-RTT if they do not match > - increment the resumption count in the ticket and session state > - send the updated ticket to the client > Here the resumption counts have to be synchronized between the client and server, but is the count cryptographically authenticated? can can attacker can take 0RTT data from session N, increment the resumption count, and replay that 0RTT data? Since synchronization and authenticity are both required here, would it be simpler to use the sequence number and PRF state from the session? it can be saved by the client and server on session close, and they take off where they left things on any subsequent connection. That also gives clients and their users additional confidence in the protocol: the server can't just ignore things like resumption counts. Another sort of warm and fuzzy reason I like this is that the whole thing resembles a single-long-running regular TLS connection over a single TCP socket. That makes things easier to verify, and some things easier to implement. To see that this provides roughly TLS 1.2 security, note that so long as > the protocol never has to drop to 1-RTT, it is basically equivalent to TLS > 1.2 session-ID based resumption. When we do drop down to 1-RTT, we will > replay 0-RTT application data, opening up new replay attacks. However, > after this paper > <http://blog.valverde.me/2015/12/07/bad-life-advice/#.VucOsJMrIxN>, I do > not believe there are any significant new replay attacks against HTTPS, > ssh, or any real protocol I can think of. > Unfortunately I don't think that's a safe assumption. The paper is about browser behavior, but there are API clients and SDKs that do not retry as a matter of design, they rely on TLS for non-replayability. In any event, there might be no problem: wouldn't it be a TLS library bug if the library somehow fell back to 1-RTT mode while also decrypting and passing on the 0RTT data? the client and the server need to agree on whether it was received. -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
