On Mon, Oct 19, 2015 at 7:37 AM, Short, Todd <tsh...@akamai.com> wrote:
> Does the sentinel have to be the first N bytes?
>
> RFC 5246 (S7.4.1.2) specifies Random as a combination of a uint32 time
> value and 28 random bytes.
>
> Rather than risk breaking backwards compatibility by changing the
> definition of the first 4 bytes, perhaps the sentinel can be moved to
> another location within the ServerRandom field? Either the second set of N
> bytes or the last set of N bytes? Where the sentinel is located shouldn’t
> really matter. Subsequently, the sentinel can be chosen with more freedom.
> As I recall, one reason (but not the only reason) the length was extended
> to 8 bytes due to the gmt_unix_time issue; is an 8-byte sentinel still
> needed if it’s not overlapping the gmt_unix_time (yes, I’m concerned about
> a reduction of entropy by 25%)?
>
Maybe it's because I haven't had my coffee yet, but ISTM that overloading
the time field
lowers the risk of false positives because we can choose a sentinel that
will never
collide with a conformant TLS 1.2 ServerHello. By contrast, a sentinel in
the
randomly generated portion always has a 2^{-n} chance of collision.
> In extending this, should the ClientHello random value also include the
> sentinel? (Yes, I know this again reduces entropy.) A MITM can implement a
> downgrade attack in either direction. The server can terminate the
> connection that much earlier
>
How does this help? The attacker will just rewrite the ClientHello.random.
-Ekr
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
