Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

Harlan Lieberman-Berg <hlieberman@setec.io> Mon, 14 March 2016 01:26 UTC

Return-Path: <hlieberman@setec.io>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1239412D86D for <tls@ietfa.amsl.com>; Sun, 13 Mar 2016 18:26:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=setec.io header.b=tDVIBbeD; dkim=pass (1024-bit key) header.d=setec.io header.b=omjYsTpX
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 1YGkngowFV9K for <tls@ietfa.amsl.com>; Sun, 13 Mar 2016 18:26:16 -0700 (PDT)
Received: from xmenrevolution.com (xmenrevolution.com [97.107.134.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F18B12D827 for <tls@ietf.org>; Sun, 13 Mar 2016 18:26:15 -0700 (PDT)
Received: by xmenrevolution.com (Postfix, from userid 113) id 2EBDB16AB3; Sun, 13 Mar 2016 21:26:15 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=setec.io; s=mail; t=1457918775; bh=1lMt8YOF6J9XqHPeorga8i/sFxfhjTz6sPDko67rdMM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=tDVIBbeDk25OTceIY9gSrTVgmH65Aw3wV+R9U3spfWzhWjoljrTgcwkE79pHxqR7N 4baA1bd6IAJ96U1z73O93u0x6JNzoQuFPhYKm/uMlnBrWaYweWy51EXxnWoQT0gKwt 3UAExaeRYA4IMKkDkP3iIqCFjKVa0H3Gb8ntxFl8=
Received: from agartha (static-155-212-141-65.mas.onecommunications.net [155.212.141.65]) by xmenrevolution.com (Postfix) with ESMTPSA id 6B27416991; Sun, 13 Mar 2016 21:26:14 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=setec.io; s=mail; t=1457918774; bh=1lMt8YOF6J9XqHPeorga8i/sFxfhjTz6sPDko67rdMM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=omjYsTpXgtgr4b1RwIwesbxDe2s6ru/xi5Jv6jwPRsgxTlCg4XWyY/hgx/4kyaIQq wbPJ7JE1mG6vorERBJX0m5peA2WqdqfJRqIyKcFTt/ZIN1l4Th5PYAzAVnVLdHZj6i X/HMVXvOCWSX0cg4HrMPbk7NAZ1im42YGKHAT1no=
From: Harlan Lieberman-Berg <hlieberman@setec.io>
To: Bill Cox <waywardgeek@google.com>, Scott Schmit <i.grok@comcast.net>
In-Reply-To: <CAH9QtQFAJkq-cmY3xhvw43N4q1E7i1JJoECKLpVFb_vTRbGs4A@mail.gmail.com>
References: <56E54B85.4050204@cs.tcd.ie> <20160313212342.GA27160@odin.ulthar.us> <CAH9QtQFAJkq-cmY3xhvw43N4q1E7i1JJoECKLpVFb_vTRbGs4A@mail.gmail.com>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu)
Date: Sun, 13 Mar 2016 21:26:14 -0400
Message-ID: <874mc9g895.fsf@setec.io>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/U70VlWE3R01_lf9qyCxiFAYWCFQ>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: Mon, 14 Mar 2016 01:26:18 -0000

Bill Cox <waywardgeek@google.com> writes:
>> Most server admins won't be reading the TLSv1.3 spec.  They're going to
>> see "shiny feature added specifically in this version that makes it
>> faster!" with *maybe* a warning that there are risks, which they'll
>> dismiss because "if it was so insecure, they wouldn't have included it
>> in the protocol in the first place."  Unless 0-RTT can be fixed, it
>> looks like an attractive nuisance.
>
> I agree.  Instead of dropping 0-RTT, I think we should make it easy for
> admins to learn about what is involved in using 0-RTT in ways we believe
> are secure.  [snip]

I agree with a slight tweak in wording here, Bill.  I think that we
/should/ drop the parts of 0-RTT where we are not confident that an
admin who blindly enables functionality in TLS 1.3 will not end up
harming themselves.

More generally, I strongly believe that TLS 1.3 should not
provide options which we think should be restricted to "admins who know
what they're doing".  These end up hurting us down the line (cf EXPORT
cipher suites.)

I think we should ship the parts of 0-RTT that we believe are
intrinsically safe for (the vast majority) of the internet to enable and
use on day 1.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman