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

From: Hubert Kario <[email-masked]>
Date: Mon, 25 Mar 2019 12:30:29 +0100

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

---

From: David Schinazi <[email-masked]>
Date: Mon, 25 Mar 2019 15:09:21 +0100

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.

Thanks,
David

On Mon, Mar 25, 2019 at 12:31 PM Hubert Kario <[email-masked]> wrote:

> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech
> Republic_______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Hubert Kario <[email-masked]>
Date: Mon, 25 Mar 2019 16:54:37 +0100

> 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

---

From: David Schinazi <[email-masked]>
Date: Mon, 25 Mar 2019 17:02:34 +0100

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.

David

On Mon, Mar 25, 2019 at 4:54 PM Hubert Kario <[email-masked]> wrote:

> > > handshake and only then request information from the server? I.e. make
> it
> > > a

---

From: Hubert Kario <[email-masked]>
Date: Mon, 25 Mar 2019 19:11:41 +0100

> server and the reply comes before the identity of the server has been

exactly

> > > Can you elaborate on how "TLS is a providing integrity and authenticity
> > 
> > to
> > 
> > > integrity and authenticity to a byte stream, not to how your byte stream
> > 
> > is
> > 
> > > > 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
> >

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 26 Mar 2019 04:07:51 -0400

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.

On Mon, Mar 25, 2019, at 19:12, Hubert Kario wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> Attachments:
> * signature.asc

---

From: Hubert Kario <[email-masked]>
Date: Tue, 26 Mar 2019 14:30:32 +0100

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 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
> > > > > > only up to EncryptedExtensions, without processing
> > > > > > CertificateVerify
> > > > > > or

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 27 Mar 2019 09:51:43 -0400

> (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.

---

From: Hubert Kario <[email-masked]>
Date: Wed, 27 Mar 2019 15:07:47 +0100

On Wednesday, 27 March 2019 14:51:43 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