Re: [TLS] PR for anti-downgrade mechanism

On Sat, Oct 17, 2015 at 3:17 PM, Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:

> On Sat, Oct 17, 2015 at 03:10:01PM -0700, Eric Rescorla wrote:
>
> > > 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".
>
> That's all fine and good, but my point is that this is a distraction.
> Though the specific numbers depend greatly on the underlying layer-2
> networks traversed by the TCP frame, let's accept the 1:10^10
> estimate, in which case anything better than ~2^{-40} is quite
> enough.  If so, send a shorter sentinel.

Sure, that's fine. I'm simply dispensing with arguments that we need to
avoid sending a version because we need the bits to avoid false
positives.

> > 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).
>
> However, the question of simplicity still remains...  I would go
> with at most a 1 bit field for "TLS 1.2" vs. "TLS 1.3" in whatever
> length sentinel is used.

I don't feel strongly about this, but I don't see how what you suggest
is any simpler than the version number encoding I proposed.  Arguably,
it's more complicated since you can't implement the sentinel check with
memcmp().

-Ekr

>         VIktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>