Re: [TLS] Renegotation redux

[Watson Ladd <[e-mail]>]

On Mon, Apr 14, 2014 at 9:36 PM, Nico Williams <[e-mail]> wrote:
> On Mon, Apr 14, 2014 at 9:48 AM, Watson Ladd <[e-mail]> wrote:
>> Are there any users of renegotiation beyond authentication with client
>> side certificates? In particular has anyone come up with a use for
>> changing the claimed identity of the server?
>
> Yes, it's been discussed in the context of protecting the server's
> identity: start with anon ECDHE ciphersuites then renegotiate to [use
> SNI and] authenticate the server.

That won't work if you do it like that. Hint: how does the server know
who to reveal their identity to?

>
> This is important in general given that privacy protection is desirable.
>
>> I think we can do client authentication upgrades via a channel
>> extraction+signing solution while preserving the privacy currently
>
> We call that channel binding.  I agree as to that.
>
>> given by renegotiation. I haven't yet run Proverif on this solution,
>> so it might not work, but my intuition is that this will work better
>> than trying to expose the semantics of renegotiation correctly.
>>
>> Renegotation has been responsible for two major security issues, and
>> significantly complicates the TLS handshake state machine and
>> semantics.
>
> First off, renego was responsible for one bug -- the other is a
> resumption bug, and BOTH were the result of insufficient or
> non-existent channel binding between the one connection and the other.

It's not "a lack of channel binding". It's a failure to hash
transcripts in a key exchange. That's why you can have the same
pre-master secret on two different connections, and thus break
resumption. If the two connections were completely independent these
problems wouldn't have happened as you wouldn't trust the earlier data
as coming from the person you now authenticated. (My understanding of
insecure resumption is that a renegotiation was necessary to seal the
deal: i'll double check the paper to see if that's correct).

>
> Second, we do have uses for renego (see above).
>
> Third, I'm skeptical of proposals to throw the baby out with the bathwater.
>
> Fourth, renego need not complicate the TLS handshake state machine if
> we see the two (or three, or...) handshakes as distinct connections
> with channel binding of inner to outer.\

And that's not complicated? I don't see how channel binding fixes the
confusion that is changing claimed identities across connections, or
reduces the impact of renegotiation on implementation complexity.

The problem Nick had was the following: you want a software component
that sits between a bidirectional stream of bytes and a socket, and
applies TLS after the handshake has completed. Because this is C, and
not Go (or CML, or etc...), you cannot write an independent event loop
without an OS level thread. (Completing the handshake involves a bit
more work)

The usual solution would be as follows: when the host application
writes to the stream, it signals there is new data to send, which the
component dutifully encrypts, and sends (since the host application
has checked that sending is possible on the fd via poll(3) or
equivalent). On read the same thing happens in reverse.

However, with renegotiation the component suddenly goes into a state
into which sending data is dependent on receiving some data. How you
deal with this cleanly is beyond me. It's not solved by any retooling
of the API: it's fundamental to any protocol exchange in which a read
can block a write.

>
> I'll admit that the fact that we did not discover the lack of
> sufficient channel binding in resumption after the renego bug does
> give me pause.  We should audit the protocol and implementations on
> this point, but we have to anyways.  Also, note that your proposal
> regarding client certs is to push the problem to the app layer and
> hope that they get channel binding right, which given our collective
> failure to do the same in TLS should give us pause.  I.e., TANSTAAFL,
> which makes me think even more that yours is a
> throw-the-baby-out-with-the-bathwater proposal.

I'm not pushing it to the app layer any more than now, nor am I
suggesting that the average application developer be ever trusted with
cryptography. The library should say "pass me a cert" (ideally not
even that) and handle the rest.

In the course of my writing this missive, another email from you
arrived. You suggested that we hand this over to the application layer
in part, by exposing channel binding inputs and outputs. This is a
terrible idea. The application developer is not supposed to know or
understand cryptography. They are supposed to write dial("443",
"secure.example.com") and have the OS take care of determining which
certs are trusted, opening a secure connection, and the fiddly details
of managing that connection, and authenticating the user over that
connection (if needed). They get it wrong too often to be trusted with
it, and shouldn't even be trusted with cert selection (as that means
they can read certs). (TCP is spelled dial_insecure, just be sure
everyone gets the message). (and by application developer I mean me
when I don't want to think about this).

What does the application do with the return value of dial? write(2),
read(2), poll(3), close(2), just like anything else.

Sincerely,
Watson Ladd

>
> Nico
> --



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin