On Tue, May 09, 2017 at 11:44:14AM -0700, Colm MacCárthaigh wrote: > On Tue, May 9, 2017 at 11:12 AM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote:
> > Because HTTP specification expressly forbids any and all updates and > > writes using safe methods. Ignoring that causes very severe security > > vulernabilities even today (e.g., causes essentially undefendable CSRF > > attacks). > > > > These aren't browser requests, they can be SDK and other clients making > HTTP API requests. That's much more common too, by volume. CSRF isn't an > issue in cases like that. Hope your API is actually idempotent, because the HTTP code, which sits below the SDK code can replay requests on its own... > I think everything I'm writing applies even for a careful REST-compliant > case too. Even if the client is using PUT or POST or DELETE or whatever, > the same kind of transactional semantics apply. All it takes is a > disconnect between the settings in any of the middle transport layers and > the expectations of the underlying protocol. I just think that disconnect > is very predictable. PUT and DELETE are also subject to autoretry. Which means that any PUT or DELETE in failed 0-RTT can be immediately replayed as 1-RTT by the HTTP code. However, POST is not subject to autoretry. Which means that any POST in failed 0-RTT must be reported to next layer as "error: connection to server lost before reply was received". Which is the same error if server somehow sent a TLS close_notify with pending POST (which is considered autenticated close!). (In HTTP/2, if the server explicitly refuses the stream POST is on, that does not count as fatal failure, and the http library can autoretry). The next layer can then decide to retry the request upon getting the connection lost error. However, in such situation, one _always_ needs to handle possible reordering, _regardless_ of 0-RTT or TLS version! Unified-stream model has the following to keep in mind: - The client TLS library APIs must not be subject to races that may cause data corruption if server rejects 0-RTT (_including_ selecting different application-layer protocol). - The 0-RTT data may not be suitable for replay, even if application- layer protocol matches. And 0-RTT containing HTTP POSTs is the not the only case even in HTTP (e.g. what Tokbind has specified so far renders such replay unsafe even for GET). Two recommendations: - Always require strong 0-RTT anti-replay, even accross servers. The attacks raising from failing to do this are just too severe and virtually impossible to address in any other way. - Clients shall treat any 0-RTT data sent as potentially received by the server, _even_ if server refuses the 0-RTT. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
