Re: [TLS] Need for S->C signaling

[Yoav Nir <ynir at checkpoint.com>]

On Nov 20, 2009, at 10:11 PM, Michael D'Errico wrote:

> I agree that something along these lines might be an improvement.
> I found it difficult to explain how the upper bit of version is
> set, but is not really a version change.
> 
> But messing with gmt_unix_time might cause trouble since it's
> possible that _something_ out there might rely on it (for what
> I have no idea).

How about: If the client has its clock set way into the future, you don't want to send it a certificate that is already expired.
That works even better the other way. If the client does have its clock set to the past, you can send it an expired certificate.
Peter Gutmann says that many implementations randomize this value for exactly that reason.
That is an important data point, because since such implementations are out there (and presumably working), it's safe to assume that we CAN mess with this field.

>  So since the bottom few bytes of the random
> have no restriction whatsoever, putting the actual cipher suite
> there would not break anything.
> 
> I'm not convinced that we need a field of flags, though, since
> we have TLS extensions.  We should point out in our spec. that
> this solution is a HUGE compromise in the quest for backward
> compatibility, and that future fixes MAY require extensions.
> "You've been warned", etc.
> 
> Mike
>