On Wednesday, 27 March 2019 14:51:43 CET Martin Thomson wrote: > On Tue, Mar 26, 2019, at 14:30, Hubert Kario wrote: > > On Tuesday, 26 March 2019 09:07:51 CET Martin Thomson wrote: > > > We don't trust that the key share or certificate is good either, but > > > once we have a Finished message, that is retroactively authenticated > > > and can be used. We rely on this property for a bunch of things. > > > > yes, but those things are part of the protocol, not destined for > > application (or even if they are, they are actionable only after the > > handshake finished) > Yep, but that's something that QUIC relies on already. As does ALPN. And > it is likely that there are other things that I can't think of in my > current frazzled state.
how is ALPN similar?
a). the information gained by processing the handshake only up to
EncryptedExtensions with ALPN is "what protocol server is willing to use"
b). that information is useful _only_ for establishing future _TLS_
connections and guides what happens _after_ the handshake is finished
OTOH, the information gained from client-net-address is useful outside the TLS
scope
--
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
