Re: [TLS] PR for anti-downgrade mechanism

[Eric Rescorla <[e-mail]>]

On Sat, Oct 17, 2015 at 3:05 PM, Viktor Dukhovni <[e-mail]>
wrote:

> On Sat, Oct 17, 2015 at 02:53:57PM -0700, Eric Rescorla wrote:
>
> > > It also has a slightly better collision risk, though it's already down
> > > quite low
> >
> > Given that the TCP checksum has a false negative rate far higher than
> > 2^{-56} and
> > any TCP errors cause TLS handshake failures, this doesn't seem like much
> of
> > an argument.
>
> This argument is not complete.  The false negative rate from TCP
> is not by itself sufficient to determine the observed error rate.
> One needs to combine that with the undetected error rate from
> underlying network to obtain the frequency of TCP errors that
> percolate up to the TLS layer.
>

A bit old but see:
http://www.ir.bbn.com/documents/articles/crc-sigcomm00.pdf

"After an analysis we conclude that the checksum will fail to detect
errors for roughly 1 in 16 million to 10 billion packets".

-Ekr



> The question is not so much whether 48, 56 or 64 bits is the right
> amount of protection against random false positives, though if 64
> bits is way overkill and the original 48 is more than enough, we
> could look more closely at that.  Rather, I think the question is
> whether this work-around should be as simple as possible, or should
> be a more feature-full new sub-protocol.  I'm in the keep it simple
> camp (if we should do this at all).