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

[Bodo Moeller <[e-mail]>]

On Nov 28, 2009, at 9:41 AM, David-Sarah Hopwood wrote:

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

Arguably a single receiver-side bug might be enough -- namely, having  
a receiver *ignore* out-of-sequence messages without looking at their  
content.  Then if an adversary includes the above in the actual  
handshake data sent to one of the peers, the receiver would interpret  
the concatenation previous_client_verify_data ||  
previous_server_verify_data as one or more additional handshake  
messages, might similarly ignore these as unexpected, and with a non- 
negligible probability would end up at the correct message boundary to  
parse the next actual handshake message.

(Encoding the actual combined length of the previous_..._verify_data  
fields seems simpler to analyze -- this still wouldn't be a valid  
Finished message; or hash an empty Finished first, then a pseudo- 
message containing the previous verify data.  Of course, neither of  
this avoids the potential problem with buggy receivers that ignore out- 
of-sequence messages.  That pseudo-message *could* use the Certificate  
type to maximize the probability that buggy implementations will look  
at it and stop [given that Certificate is expected at that point of  
the protocol], but I guess that looks even weirder.)

Bodo