Re: [TLS] draft-ietf-tls-renegotation: next

[Kyle Hamilton <[e-mail]>]

I support making the MCSV mandatory in the ClientHello.  The benefit
is obvious: the server *knows*, without a doubt, that the client knows
how to do secure renegotiation, even if the client doesn't send the
extension.  This means that servers can relax their "absolutely no
renegotiation" stance, in regards to that particular client, in the
same way that they could if they received the extension.

As far as I can tell, there is no mechanism (other than extensions)
for the server to signal the client that it knows how to do the secure
renegotiation.  As has been discussed, this would be a static set of 6
bytes appended to the ServerHello.

I rather disagree with making the RI extension anything other than
empty, because each peer *must* (in order to implement it securely)
remember the last hashes for that session and compare them to see if
they match, else the MITM could just add bogus information that isn't
checked and the handshake proceeds anyway -- which violates the
authenticity guarantee.  If we're going to force the implementors to
save the hashes anyway, why should we take the risk of putting them
out on the wire?  (To avoid a "chosen plaintext" attack... against a
key and negotiation that's about to change?)  If the values calculated
don't match up with what's received from the other end, the
ChangeCipherSpec will work but the Finished message won't be able to
be decoded, which will cause the connection to be aborted.

(However, I do recognize that putting the prior hashes into an RI
extension will cause them to be part of the final hash for Finished
anyway, without requiring any changes in how the cryptographic system
is set up.  I'm unhappy with this idea, though, because there are
still MANY extension-agnostic clients and servers out there.  Clients
won't send extensions if they don't have to, and servers won't show
that they know about extensions unless the client shows exactly the
extension they expect.)

If those hashes are saved by each peer (as would be required under
this proposal), then it follows that since they're placed under
separate cover by the Finished message, they're an appropriate input
for the Renegotiation-Finished hash calculation.  Again, there's no
reason to put them on the wire.

What we're looking for isn't really a "session-based" design -- we're
simply looking for a way to authenticate future handshakes as
following naturally from prior handshakes.  The session parameters are
frozen by the time ChangeCipherSpec hits; the Finished message is and
always has been the time to determine whether the peer understands the
cipher spec parameters.

Also, it is illegal for any TLS implementation to negotiate
NULL-NULL-NULL, and it is illegal for any TLS implementation to
transmit application data after the initial handshake has been
initiated and before the Finished messages have been generated by both
sides.

This would suggest that another mitigation for this attack would be to
include a zero-length application-data packet in all renegotiations;
if one side thinks it's an initial negotiation, and it receives an
application data packet under the state that it thinks is
NULL-NULL-NULL, it is required that it close the connection with a
fatal handshake_failure alert.

(The only problem with this potential mitigation is that if the client
is connected to the MITM, and the MITM is connected to the server, the
MITM could simply strip out the zero-length application-data chunk,
since TLS relies on underlying mechanisms to verify that it has a
two-way error-detected/corrected clear channel -- TCP/IP, SPX/IPX, a
clean serial line, or an MNP5 modem.  TLS doesn't try to detect lost
chunks from the server.)

So, in addition to mandating the MCSV, I also support an empty RI
extension as a means of notifying the server that the client knows how
to do it.  For interoperability and ease of implementation, it's an
easy MUST to send both, if the client understands how to send
extensions.  I'm less happy about forcing the client to understand
extensions enough to verify the data being put into the RI extension
on subsequent handshakes, but even in that case the ServerHello
wouldn't have the correct 6 bytes at the end (for the initial
handshake that the client sees) and thus would cause the client to
abort with a handshake_failure.

(Since the cryptographic properties of the protocol aren't being
discussed, it's only a matter of identifying what oversight in the TLS
protocol allowed this attack to work, which is simply that a means was
found to trick both sides of a connection into believing that the
connection was continuous without cryptographic verification.)

At least one good thing that the original protocol designers did was
to ensure that both peers must renegotiate their own cipher parameters
in the event that either side initiates a renegotiation.  Since it's
mandatory that servers include the bytes after the end of the
ClientHello as part of the hash of handshake messages, regardless of
whether it can identify them or not (this was the language previous to
TLS-EXT), the client can send anything it wants.

The server side is a bit more complex: it can't signal anything to the
client unless it uses an extension.  For the client, it's very easy to
compare 6 bytes in memory to verify that the extension exists and is
the proper one.

It's only if the Finished message happens and it doesn't have the
correctly-seeded hash that it's detected as being bogus.

(Notably, the TLS specification requires that after the initial
negotiation, applications need to be able to interleave data into the
connection -- except in the case of ChangeCipherSpec and Finished,
where Finished must always be sent immediately after the
ChangeCipherSpec is sent.  A way to break compatibility with older
clients would be to send a zero-length, HMAC'd application data chunk
between the ChangeCipherSpec and Finished messages, using the cipher
suite that was put into the current connection state by the
ChangeCipherSpec, not count it as a handshake message, and only after
that send the Finished message precisely as it is calculated
elsewhere.  I would prefer that it not be broken, but it could be a
means by which TLS 1.3+ ensures that the handshakes under its own
cover are acceptable.)

Once a handshake determined to be bogus, the spec is clear: abort the
connection with a handshake_failure alert.

I support making what I see is the minimum number of changes in the
specification necessary to ensure security, in such a way as to
minimize the amount of work to implementation developers.  If there is
a way that is simpler, I would like to see it.

(I'm wondering if it's time to start making breaking changes, and call
the result TLS v2.0.)

-Kyle H

On Thu, Dec 17, 2009 at 3:30 AM,  <[e-mail]> wrote:
> Martin Rex worte:
>
>> I do not fully agree with the AD's determination of rough consensus.
>>
>> For the MCSV signaling, the real rough consensus is different from
>> what Pasi wrote:
>>
>> http://www.ietf.org/mail-archive/web/tls/current/msg05306.html
>>
>> A mandatory Client->Server signaling through cipher suite may
>> have less fanatic followers by the count of numbers, but technical
>> advantages and _no_ technical objections have been raised against it.
>
> Several people have very clearly and strongly objected to making the
> MSCV mandatory-to-include in ClientHello. You seem to be suggesting
> that their opinions don't somehow matter because they are, in *your*
> opinion, not "technical".
>
>> The current either cipher suite or empty TLS extension RI signaling
>> may have more "pro", but has significant objections against it
>> because of the ambiguity, increased complexity, a 4x code size
>> burden for old non-rengotiating servers and additional testing
>> complexity.
>
> If the specification text is ambiguous, we obviously need to fix that.
>
> About the code/testing complexity/effort: I would say most people
> believe that no matter what details get selected, this is not a
> significant amount of work (so small differences in lines of code or
> test cases should not signify much in making the decision).
>
>> So as far as rough consensus is concerned, it is definitely with the
>> approach I described.
>
> I disagree.
>
> Best regards,
> Pasi
> (wearing Security Area Director hat)
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>