On Wednesday, 4 July 2018 15:06:27 CEST Ilari Liusvaara wrote: > On Wed, Jul 04, 2018 at 02:42:51PM +0200, Hubert Kario wrote: > > All the implementations I deal with in my day-to-day work fail to handle > > the 0-RTT client hello correctly when the 0-RTT support is not enabled on > > the server. > > > > I.e. they ignore the MUST clause from > > https://tools.ietf.org/html/draft-ietf-tls-tls13-28#page-58 stating that > > the server can handle an early_data extension (and following encrypted > > data) in only one of three ways, neither which allows for unconditional > > connection abort. > > > > This also runs afoul the recommendation from https://tools.ietf.org/html/ > > draft-ietf-tls-tls13-28#section-D.3 on 0-RTT backwards compatibility. > > OTOH, such servers probably do not send out tickets allowing 0-RTT, so > any client attempting 0-RTT with such server is very broken.
please read Section D.3, it is spelled out in detail there why that's not the case the short of it: the client has no way of knowing if it is connecting to the same server/instance/process it received the ticket from -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
