Subject: [TLS] 1rtt thoughts

From: Michael StJohns <[email-masked]>
Date: Mon, 14 Jul 2014 13:16:48 -0400

The current 1rtt draft uses a ClientHello with a ClientKeyExchange 
embedded in an EarlyData extension of the hello to get around the 
problem of pre-TLS1.3 handshake message ordering.   That solves the 
problem mostly, but at the cost of yet another tweak to message formats 
and slightly more complexity in processing.

Instead, how about simply sending the ClientKeyExchange first and then 
the ClientHello (same TCP/UDP send call, just a different record 
order)?  A TLS1.2 server receiving things in this order discards the 
ClientKeyExchange with an out of sequence error, and then starts the 
handshake normally with the receipt of the ClientHello.   The TLS1.3 
client detects the error report and resends the ClientKeyExchange in the 
appropriate TLS1.2 order.

For Finished message processing, the ClientKeyExchange record is 
included in the hash/mac in its normal location, regardless of when it 
was received.

Mike

---

From: Adam Langley <[email-masked]>
Date: Mon, 14 Jul 2014 10:27:35 -0700

On Mon, Jul 14, 2014 at 10:16 AM, Michael StJohns
<[email-masked]> wrote:
> A
> TLS1.2 server receiving things in this order discards the ClientKeyExchange
> with an out of sequence error, and then starts the handshake normally with
> the receipt of the ClientHello.

I've never encountered a TLS 1.2 implementation that will discard an
unexpected handshake message like that as opposed to sending a fatal
alert (maybe) and closing the connection.

We could refine TLS 1.2 processing, of course, but if you were
expecting that to be backwards compatible with existing code then I
fear it won't work.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Jul 2014 10:49:08 -0700

> alert (maybe) and closing the connection.

Indeed, it's required by TLS.

-Ekr

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Michael StJohns <[email-masked]>
Date: Mon, 14 Jul 2014 16:06:50 -0400

On 7/14/2014 1:49 PM, Eric Rescorla wrote:
>
>
>
> On Mon, Jul 14, 2014 at 10:27 AM, Adam Langley <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     > A

Umm...

Part of the problem I have at times in discussions about TLS is the 
confusion between what happens as part of the transport connection and 
what happens as part of the TLS connection.  I think of TLS as a record 
connection over a bearer transport service.  They interact, but not 
strongly, and usually not without intervention from the client or server 
application.  The TLS thing (server, message processor, etc) attached to 
the server side of the transport connection snarfs up individual TLS 
records one by one and processes them according to its current state.

While you're both correct that TLS requires the "connection" to be 
closed in the event of a fatal error  (and here I'm referring to 7.2.2 
of RFC5246), the context of the word "connection" in that section 
doesn't appear to be same as closing the "transport" (see just above 
that where the two different terms are used).   It appears to only refer 
to closing the current TLS connection.

Nothing in section 7.2.2 suggests either the requirement to close the 
transport, nor the requirement to discard pending data in the transport 
connection.  I'm not arguing that implementations don't do exactly that 
though - I don't actually know.   if you're arguing that the standard 
says to close the transport and discard the pending TLS records, can you 
point me at that section?

I also can't find anything that says that a new connection can't be 
opened on the same transport connection after a fatal close.

So I would suggest that even with 7.2.2 you get this as an error case 
between a 1rtt TLS1.3 client and a 1.2 server:

Client                                                      Server
ClientKeyExchange ----->
ClientHello ---->
                                                            [Server 
notices data waiting on the transport
                                                             Server 
begins a connection state
                                                             Server 
receives and processes unexpected ClientKeyExchange
                                                             Server 
sends a fatal alert and discards the connection state]
                                        <--------------- Error Alert 
(unexpected_message) (plus close_notify??)
  [Client receives the error alert
    checks for type and discards it as expected]
                                                            [Server 
notices data waiting on the transport
                                                             Server 
begins a connection state
                                                             Server 
Receives and processes ClientHello
                                                             Server 
sends its part of a TLS1.2 handshake]
                                         <--------------- ServerHello, 
ServerKeyExchange etc
[Client receives the Server Side messages and processes
   them...
  Client resends the ClientKeyExchange that was ignored above]
ClientKeyExchange  ------>
etc --->
  .............................  Continue through the normal connection 
process.

 From the server's side this looks like two different connections. From 
the client side, it's just negotiating to the right suite.

Mike

>     Adam Langley [email-masked]
>     <mailto:[email-masked]> https://www.imperialviolet.org
>
>     [email-masked] <mailto:[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Jul 2014 13:18:53 -0700

A large fraction of existing TLS servers will respond to this situation by
generating a fatal alert and closing the connection.That makes this
approach a nonstarter.

Given that, whether it is possible for a compliant TLS server to behave
differently seems like a largely academic question.

-Ekr

On Mon, Jul 14, 2014 at 1:06 PM, Michael StJohns <[email-masked]>
wrote:

> confusion between what happens as part of the transport connection and what
> happens as part of the TLS connection.  I think of TLS as a record
> While you're both correct that TLS requires the "connection" to be closed
> in the event of a fatal error  (and here I'm referring to 7.2.2 of
> RFC5246), the context of the word "connection" in that section doesn't
> appear to be same as closing the "transport" (see just above that where the
> two different terms are used).   It appears to only refer to closing the
> current TLS connection.
> I
> though - I don't actually know.   if you're arguing that the standard says
> to close the transport and discard the pending TLS records, can you point
> me at that section?
>
> I also can't find anything that says that a new connection can't be opened
> on the same transport connection after a fatal close.
>
>                                                            [Server notices
> data waiting on the transport
>                                                             Server begins
> a connection state
>                                                             Server
>                                                             Server sends a
> fatal alert and discards the connection state]
>                                                            [Server notices
> data waiting on the transport
>                                                             Server begins
> a connection state
>                                                             Server
>                                                             Server sends
> its part of a TLS1.2 handshake]

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 14 Jul 2014 17:22:11 -0400

> the client side, it's just negotiating to the right suite.

I'm not sure what toolkit presents this as two different connections on
the server side.  This closure and reopening smells very much like
problems we fixed with insecure renegotiation only a few years ago.  A
TLS toolkit capable of keeping the underlying transport open while
restarting a new TLS session would need to be very clear about how it
presents such a transition to the upper-layer logic, if we don't want
another round of prefix-injection attacks.

I recognize that this is an API question more than a protocol question,
and therefore at the edge of scope for the WG.  But we've seen enough
problematic APIs that cause applications to lose the security guarantees
that the protocol is supposed to provide that i can't help thinking we
should take these concerns seriously.

	--dkg

---

From: Michael StJohns <[email-masked]>
Date: Tue, 15 Jul 2014 14:37:31 -0400

Daniel  - inline below, but first

For grins I wrote a quick and dirty program to send a ClientKeyExchange 
before a ClientHello, read the response, try again, and then close the 
connection.

I got three different results from three different machines:

 From my local apache server, I got a single "unexpected_message" alert, 
and afterwards anything sent to the TCP connection was blackholed.  The 
TCP connection remained up though.

 From "mail.google.com:443" I got an abort of the TCP connection without 
any error alert.

 From "www.navyfederal.org:443" I got no error message, and no response 
on any further data sent on the TCP connection.  The TCP connection 
appeared to remain up.

These were the first and only ones I tried.  I'm sure if I worked 
through a larger list I'd probably get even a wider set of responses.

> another round of prefix-injection attacks.

This is an interesting comment that made me consider what the issues 
might be lurking with things like STARTTLS style connections. Although 
all the current STARTTLS models have the clear text/non TLS only at the 
beginning of the TCP connection, I'm wondering if there isn't some 
application where interspersing TLS with plaintext (or maybe multiple 
differently credentialed TLS sessions) over the life of the TCP 
connection has any utility.  This is just a thought experiment for now.

> should take these concerns seriously.
It's not exactly an API, but an interface question.  RFC793 (TCP) is 
sort of a gold standard in my eyes for how you describe them.  It talks 
about what TCP offers to the upper layer protocol, and what it needs 
from the lower layer protocol.  For the specifics of IP as the LLP for 
TCP, it provides some guidance on IP parameters.

The TLS spec is very good at specifying the on-the-wire and TLS protocol 
processor to TLS protocol processor, but less good at specifying 
interface characteristics for talking to the protocol levels above or 
the protocols levels below.

Later, Mike

---

From: James Cloos <[email-masked]>
Date: Tue, 15 Jul 2014 15:51:39 -0400

>>>>> "MS" == Michael StJohns <[email-masked]> writes:

MS> I'm wondering if there isn't some application where interspersing
MS> TLS with plaintext (or maybe multiple differently credentialed TLS
MS> sessions) over the life of the TCP connection has any utility.

There are several protocols where multiple credentials make sense.

Among them are imap, pop, ftp and any of the tls-capable sql protocols.
I'm sure there are several more I cannot think of just now.

It may be uncommon to switch identities mid-stream, but not unknown.

I doubt many currently use tls mutual auth in such a fashion, rather
than application-level aaa, but they could.

(Of the protocols I though of above, pgsql is the one where I've most
often changed users in place and where cert auth is a viable option.
That being said, I've never tested whether changing roles works with a
connection which requires cert auth.)

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6