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) > On Mon, Mar 25, 2019, at 19:12, Hubert Kario wrote: > > On Monday, 25 March 2019 17:02:34 CET David Schinazi wrote: > > > Ah, I see - thanks. In other words, the proposal requires trusting the > > > server and the reply comes before the identity of the server has been > > > authenticated. > > > > exactly > > > > > David > > > > > > On Mon, Mar 25, 2019 at 4:54 PM Hubert Kario <hka...@redhat.com> wrote: > > > > On Monday, 25 March 2019 15:09:21 CET David Schinazi wrote: > > > > > Hi Hubert, > > > > > > > > > > Can you elaborate on how "TLS is a providing integrity and > > > > > authenticity > > > > > > > > to > > > > > > > > > the IP address information"? In my understanding, TLS only provides > > > > > integrity and authenticity to a byte stream, not to how your byte > > > > > stream > > > > > > > > is > > > > > > > > > being transported over the network. > > > > > > > > my point is that EncryptedExtensions, while encrypted and integrity > > > > protected > > > > on record layer level, are _not yet_ bound to any identity, so an > > > > attacker > > > > can > > > > trivially reply to any non-PSK ClientHello with a ServerHello of its > > > > own > > > > and > > > > then he'll be able to generate arbitrary encrypted EncryptedExtensions > > > > message > > > > > > > > the forgery will be noticed only after the CertificateVerify is > > > > processed > > > > > > > > > Thanks, > > > > > David > > > > > > > > > > On Mon, Mar 25, 2019 at 12:31 PM Hubert Kario <hka...@redhat.com> wrote: > > > > > > I wanted to rise one comment on the IETF session, but we ran out > > > > > > of > > > > > > > > time: > > > > > > given that TLS is a providing integrity and authenticity to the IP > > > > > > > > address > > > > > > > > > > information, shouldn't the protocol require the client to perform > > > > > > the > > > > > > > > full > > > > > > > > > > handshake and only then request information from the server? I.e. > > > > > > make > > > > > > > > it > > > > > > > > > > a > > > > > > post-handshake messages, like KeyUpdate, rather than an extension. > > > > > > > > > > > > I worry that some clients may short-circuit processing and do the > > > > > > handshake > > > > > > only up to EncryptedExtensions, without processing > > > > > > CertificateVerify > > > > > > or > > > > > > Finished (in case of PSK), and in result expose themselves to MitM > > > > > > attacks. > > > > > > -- > > > > > > 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_______________________________________________ > > > > > > TLS mailing list > > > > > > TLS@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/tls > > > > > > > > -- > > > > 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 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- 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
