Subject: Re: [TLS] Next steps for draft-ietf-tls-renegotiation

From: Marsh Ray <[email-masked]>
Date: Tue, 01 Dec 2009 09:12:07 -0600

Martin Rex wrote:
> Marsh Ray wrote:
>> No compromise on actual protocol security of course, but no time to
>> delay for aesthetics either.
>>
>>> [1]  The simplest such change would be have the peers send zeros in the
>>>      extensions but modify the hellos to insert the CB data prior to
>>>      hashing the hellos as part of the verify_data computation.
>> Changing inputs to the hash function theoretically introduces new
>> possibilities for attack (verify_data which looks like a valid handshake
>> message prefix for example).
>>
>> I fear that any change to the way the hashing inputs are done will
>> trigger a formal crypto review in some important deployments.
> 
> 
> That seems a little far fetched, given that MitM attackers have
> no restrictions of any kind to feed whatever they like into the
> handshake message hash.
> 
> 
> Quoting from rfc5246 7.4.1.4 Hello Extensions:
> 
>       Often the fact that the extension fields are included in the
>       inputs to the Finished message hashes will be sufficient, but
>       extreme care is needed when the extension changes the meaning of
>       messages sent in the handshake phase.  Designers and implementors
>       should be aware of the fact that until the handshake has been
>       authenticated, active attackers can modify messages and insert,
>       remove, or replace extensions.
> 
> 
> The problem that David-Sarah Hopwood noticed in my initial approach
> was that my change only inserted data in the renegotiation, it did
> _not_ insert different data on the initial handshake.  So there
> was a theoretical attack that the attacker might be able to insert
> what one side added into the message stream for the other--which
> had not added for an initial handshake, provided there was an
> accidental collision with a de-facto no-op handshake message.
> The attack is fairly theoretical, because the verify_data
> is not predictable (for TLS sessions where the attacker controls
> only one side) and the protocol itself does not define any
> no-op handshake messages (but implementations could have bugs
> to this effect).
> 
> The obvious fix is to add reliably distinct data in both initial and
> renegotiation handshake.  The handshake message protection comes
> from the fact that an attacker may only insert data into the message
> streams (and get them added to the handshake message hashes this way),
> but not remove any of the data previously added by either side.

My point was simply that it could result in a lot of additional
analysis, one which I think you've proven quite nicely.

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 1 Dec 2009 12:51:05 -0600

On Tue, Dec 01, 2009 at 09:12:07AM -0600, Marsh Ray wrote:
> > [...]

We'd better have a "formal cryptographic review" no matter what we do.
Claiming that we'd to have one as an argument against a particular
solution seems like a fallacy.

I should stop at that, but the analysis of the prefix attack is simple
and, most importantly, interesting enough, at least at first glance.

1) If there's such a prefix attack then we already have it because
the hello messages come first in the hash that is used in the
verify_data computation.  I.e., a prefix attack is orthogonal to the
re-negotiation problem and solutions.

2) The client's hello comes first, and it includes the client's nonce,
so there's no prefix attack on clients -- there could only be a prefix
attack on servers.

3) A prefix attack on servers is useless in mounting the attacks we
have with the re-negotiation vulnerability: the client and server will
be able to distinguish re-negotiations from initial ones as long as we
do the channel binding thing, and there's no way that the MITM can
defeat this by manipulating the verify_data computations for its
connection to the server (the server will want to use CB for the
re-negotiation, while the client won't, which will necessarily result in
failure).

5) Yes, the MITM can modify the inner negotiation's handshake
messages, and if the MITM can create collisions at will and in real-time
then the MITM could win, but this would be not a result of the RI
proposal nor any variation thereof, but a fundamental weakness in TLS
resulting from the use of fundamentally weak hash functions.

6) Yes, the client hello starts with a constant (client_version) and a
predictably changing item (gm_time) -- a total of 48 bits that could be
used to mount a prefix collision attack.  But 48-bits is less than all
current hash function block sizes, and the next item is the client's
nonce, which is 28 bytes.  Collision attacks on hash functions would
have to work with just a 48-bit prefix, or less!  (Or client PRNGs would
have to be broken, but then you have other problems anyways.)

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Tue, 01 Dec 2009 13:58:17 -0600

> solution seems like a fallacy.

Proposals to change the hash calculations definitely reach deeper into
than a hello extension which simply passes a duplicate value for bitwise
comparison.

> and, most importantly, interesting enough, at least at first glance.

I, too, find the idea deeply appealing.

Unfortunately, we cannot compare the alternatives against perfection.
The status quo is a horribly broken, vulnerable protocol and perhaps
billions of affected systems. Every day that goes by, the attacks get
better and more sites simply disable what is otherwise a useful feature.

If anyone has a serious deficiency in draft-ietf-tls-renegotiation
(either a correct implementation of it doesn't thoroughly fix the
problem, it can't be implemented correctly by competent maintainers, or
it can't be deployed by existing sites) then please point it out to me.
I am willing to change my support, but it needs to be better than "it's
12 unnecessary bytes" or "an incompetent implementor could forget to
compare the hashes".

We have have had multiple implementations of this draft sitting on the
shelf for almost a month now. Some of them have done interop testing and
even simulated verify_data mismatches (nobody forgot to do the
comparison). It has never been the intention to bypass or rubber-stamp
the open review process, but still this "running code" has got to count
for something.

> have to be broken, but then you have other problems anyways.)

Or you could just use memcmp().

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 1 Dec 2009 15:26:43 -0600

> Or you could just use memcmp().

No, that's a problem: implementors might forget and still interop.  An
implementor that forgets to insert the channel binding data where it
belongs will simply fail to interop, thus they will not forget.

---

From: Marsh Ray <[email-masked]>
Date: Tue, 01 Dec 2009 16:04:37 -0600

> No, that's a problem: implementors might forget and still interop.  An

Again, they could also forget to check Finished.verify_data and many
other conditions. No one wanted to add another thing to get right just
for the fun of it, but at the end of the day draft-ietf-tls-renego is a
relatively simple fix for a pretty deep problem.  Personally, I think we
should be grateful to get off so easy.

> belongs will simply fail to interop, thus they will not forget.

The existence of publicly-available exploit code will help them to not
forget. Someone posted some to the full-disclosure list in early November.

Developers can just modify a byte in the debugger and watch the remote
behavior. QA testers (and other interested parties) could benefit from a
tool.

I've refused all requests for my exploit code, but it seems like we
could come up with a test client or server that merely simulated an
incoming exploit by handling a renegotiation with an empty or incorrect
extension data. This would give product testers something to work with.

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 1 Dec 2009 16:03:46 -0600

> should be grateful to get off so easy.

They were already checking the finished messages, thus this is not a new
check.

The issue is moot however, I think.  As I've said, I think we can all
live with this issue -- it's unfortunate, but hardly fatal.  I've
indicated my support for the RI proposal.

Nico
--

---

From: Ben Laurie <[email-masked]>
Date: Wed, 2 Dec 2009 08:31:48 -0800

> extension data. This would give product testers something to work with.

Exactly. I'm stunned that there's been so much discussion over
something that can be tested for so easily. On the other hand, I have
to admit that OpenSSL does not seem to test renegotiation at all,
which ought to get fixed!

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