Re: [TLS] 1rtt thoughts

[Michael StJohns <[e-mail]>]

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.



On 7/14/2014 5:22 PM, Daniel Kahn Gillmor wrote:
> On 07/14/2014 04:06 PM, Michael StJohns wrote:
>
>>  From the server's side this looks like two different connections. From
>> 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.

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.


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


>
> 	--dkg
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls