On Wednesday, 4 July 2018 18:50:14 CEST Eric Rescorla wrote: > On Wed, Jul 4, 2018 at 6:27 AM, Hubert Kario <hka...@redhat.com> wrote: > > 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 > > That's true if you have some kind of mixed rollout, but if you never > supported > 0-RTT, then there is something wrong with the client.
yes, from omniscient point of view, there is something wrong from the client but I think we can agree that there are no omniscient TLS server implementations and there won't be for quite some time :) (e.g. there could be a situation with a TLS-enabled transparent proxy between a client and a server that was later removed – internal corporate network vs. coffee shop) -- 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
