Re: [TLS] PR for anti-downgrade mechanism

Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 17 October 2015 22:05 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2006D1B2C8B for <tls@ietfa.amsl.com>; Sat, 17 Oct 2015 15:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ED7DxaNhELxL for <tls@ietfa.amsl.com>; Sat, 17 Oct 2015 15:05:55 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 533571B2C84 for <tls@ietf.org>; Sat, 17 Oct 2015 15:05:55 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 71A6F284DA3; Sat, 17 Oct 2015 22:05:48 +0000 (UTC)
Date: Sat, 17 Oct 2015 22:05:48 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20151017220548.GF15070@mournblade.imrryr.org>
References: <CABcZeBOB9mnQ8bLOCSysnx9LMv0hxrPCA21jTnxAMb3Yom_Aow@mail.gmail.com> <201510171708.16547.davemgarrett@gmail.com> <CABcZeBOzJkdjC-NnjPcHtoU_6rmEMPqj4Y7xKuA=CHZLT9r49w@mail.gmail.com> <201510171734.26589.davemgarrett@gmail.com> <CABcZeBNFvUN6KOpzGO5_tPU9dqbJ8q=k_CaqmkjeCR_hS2RCOg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABcZeBNFvUN6KOpzGO5_tPU9dqbJ8q=k_CaqmkjeCR_hS2RCOg@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ISn8YYQS7Vz36YdwXfu3Df_dC_w>
Subject: Re: [TLS] PR for anti-downgrade mechanism
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Oct 2015 22:05:57 -0000

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.

There are of course also errors in the memory subsystem, or machine
crashes, ... that all interrupt TLS connections.

Indeed 2^{-64} is a very low error probability, it is I would guess
substantially smaller that any of the other possible error sources,
and this is a good thing.

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).

-- 
	Viktor.