Re: [TLS] comment on draft-kinnear-tls-client-net-address

[Hubert Kario <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 
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
> > > > > > [e-mail]
> > > > > > 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
> [e-mail]
> 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