Re: [TLS] Verify data in the RI extension?

[David-Sarah Hopwood <[e-mail]>]

Eric Rescorla wrote:
> I also share [David-Sarah] Hopwood's concern about ambiguity in the handshake
> hashes stream created by having data which is not properly formatted
> injected into the hash
> (http://www.ietf.org/mail-archive/web/tls/current/msg04857.html),
> so I don't think the particular approach in Martin's draft is
> really satisfactory.

That potential weakness can be avoided by encoding the data to be added
into the hash as follows:

   struct {
       enum { fake_finished(20) } fake_handshake_type;
       enum { zero(0), (2^24-1) } fake_length;
       opaque previous_client_verify_data<12..255>;
       opaque previous_server_verify_data<12..255>;
   } PreviousVerifyData;

This works because the bytes {20, 0, 0, 0} encode a zero-length
Finished message, which if they actually appeared on the wire as
a handshake message sent in either direction, would cause the
recipient to abort the handshake. (This is similar to what Martin
suggested in a recent post. Since any fake_length that is not a
valid length for verify_data will work, we might as well use 0.)

Note that for the receiver of the extra data to fail to abort the
handshake in that case, it would have to make two independent errors,
both violating 'MUST' requirements present since SSLv3: it would have
to accept the empty Finished message out-of-order [*], *and* not
check that the contents of that message is a correct verify_data hash.

I'm completely satisfied that this approach solves the problem I was
concerned about.

> This isn't to say that one couldn't design a mechanism that didn't
> carry the signaling data over the wire--one obviously could. 
> However, when I look back over the 50 or so messages that were
> sent to the list yesterday, a large fraction of them are various
> tweaks on exactly how incorporate that data, which suggests to
> me that this approach isn't at all easy to reason about.

What matters is whether we have a solution that is easy to reason about
(and to implement and specify) once it has been proposed, not how many
posts to a mailing list were needed to get there.

----
[*] <http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt>

#  The handshake protocol messages are presented in the order they must
#  be sent; sending handshake messages in an unexpected order results
#  in a fatal error.

TLS 1.0 (RFC 2246)

#  The handshake protocol messages are presented below in the order they
#  must be sent; sending handshake messages in an unexpected order
#  results in a fatal error. Unneeded handshake messages can be omitted,
#  however. Note one exception to the ordering: the Certificate message
#  is used twice in the handshake (from server to client, then from
#  client to server), but described only in its first position. The one
#  message which is not bound by these ordering rules in the Hello
#  Request message, which can be sent at any time, but which should be
#  ignored by the client if it arrives in the middle of a handshake.

TLS 1.1 (RFC 4346)
   same wording but with "must" -> "MUST".

TLS 1.2 (RFC 5246)
   same wording but also with "should" -> "SHOULD".

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com