On Tue, Jan 08, 2019 at 03:27:58PM +0100, Olivier Houchard wrote: > On Tue, Jan 08, 2019 at 03:00:32PM +0100, Janusz Dziemidowicz wrote: > > pt., 4 sty 2019 o 11:59 Olivier Houchard <[email protected]> > > napisa??(a): > > However, I believe in general this is a bit more complicated. RFC 8446 > > described this in detail in section 8: > > https://tools.ietf.org/html/rfc8446#section-8 > > My understanding is that RFC highly recommends anti-replay with 0-RTT. > > It seems that s_server implements single use tickets, which is exactly > > what is in section 8.1. The above patch disables anti-replay > > completely in haproxy, which might warrant some updates to > > documentation about allow-0rtt option? > > > > Hi Janusz, > > Yes indeed, I thought I documented it better than that, but obviously I > didn't :) > The allow-0rtt option was added before OpenSSL added anti-replay protection, > and I'm pretty sure the RFC wasn't talking about it yet, it was mostly saying > it was a security concern, so it was designed with "only allow it for what > would be safe to replay", and the documentation should certainly reflect that. > I will make it explicit. > > Thanks a lot !
To clear some of the confusion on this subject, when 0-RTT was designed in TLS 1.3, it was sort of a backport from QUIC, and it was decided that the replay protection was up to the application layer (here "application" is not in the sense of the web application you're using, but the HTTP layer on top of TLS). And RFC8470 (https://tools.ietf.org/html/rfc8470), which haproxy implements, was produced exactly to address this specific area. Thus an HTTP implementation which properly implements RFC8470 does have TLS anti-replay covered by the application layer. Hoping this helps, Willy
