On Mon, Oct 19, 2015 at 11:10 AM Eric Rescorla <e...@rtfm.com> wrote:
> 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.
>
If I'm understanding things correctly, servers which expect to be the
target of tools like tlsdate (or aren't sure) will be unable to deploy this
mechanism if the sentinel collides with gmt_unix_time. If you're not sure
whether you care about tlsdate, you at least risk some compatibility
problems with anything that might have been making assumptions here.
It seems slightly strange to me to say the reason to do it this way is that
we don't risk collision with conformant TLS 1.2 ServerHellos. The reason
it's not a collision is because it means servers (supporting TLS 1.3) are
now required to produce non-conformant TLS 1.2 ServerHellos.
David
>
>
>> 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
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
