Re: [TLS] Are we holding TLS wrong?

Juliusz Chroboczek <jch@irif.fr> Tue, 13 November 2018 21:39 UTC

Return-Path: <jch@irif.fr>
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 E534C12DDA3; Tue, 13 Nov 2018 13:39:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 XsxIZYWbWC-9; Tue, 13 Nov 2018 13:39:19 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64AA112F18C; Tue, 13 Nov 2018 13:39:19 -0800 (PST)
Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id wADLdAop029397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Nov 2018 22:39:10 +0100
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id wADLdCPE003090; Tue, 13 Nov 2018 22:39:12 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id C706C3C723; Tue, 13 Nov 2018 22:39:16 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id eqDO0VY4MwX8; Tue, 13 Nov 2018 22:39:14 +0100 (CET)
Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 8CC083C71F; Tue, 13 Nov 2018 22:39:14 +0100 (CET)
Date: Tue, 13 Nov 2018 22:39:14 +0100
Message-ID: <875zx0irnh.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: David Schinazi <dschinazi.ietf@gmail.com>, "<tls@ietf.org>" <tls@ietf.org>, draft-ietf-babel-dtls@ietf.org
In-Reply-To: <CABkgnnUsd3wzNhwo+eNwW7n8bPzpYTsxMrN8EsPmOMRO7R-2ig@mail.gmail.com>
References: <CAPDSy+7-ceNNLJpFK0Z4SitBaUgxTpxiea8Z0QtpeSr+MNLKFg@mail.gmail.com> <CABkgnnWF6_cqhMCKMWHYNcdOTU=4BjRYaYMtfz-A3jtxprRAHA@mail.gmail.com> <CAPDSy+7pwaGX-5Si37JHTuBxygPN4sF9bseM-zHDLaFzEPP8cw@mail.gmail.com> <CABkgnnUsd3wzNhwo+eNwW7n8bPzpYTsxMrN8EsPmOMRO7R-2ig@mail.gmail.com>
User-Agent: Wanderlust/2.15.9
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 13 Nov 2018 22:39:10 +0100 (CET)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 13 Nov 2018 22:39:12 +0100 (CET)
X-Miltered: at korolev with ID 5BEB447E.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-Miltered: at potemkin with ID 5BEB4480.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5BEB447E.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/<jch@irif.fr>
X-j-chkmail-Enveloppe: 5BEB4480.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@irif.fr>
X-j-chkmail-Score: MSGID : 5BEB447E.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Score: MSGID : 5BEB4480.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WUD6A68gk32Swcc6a27ih7t5iLE>
Subject: Re: [TLS] Are we holding TLS wrong?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 13 Nov 2018 21:39:22 -0000

> Yep, all of which speaks to some serious shortcomings of the
> HMAC-based protocol.

The scope of Babel-HMAC is deliberately limited.  Babel-HMAC aims to
implement the strict minimum of features that make it useful.

Any deployment that needs features beyond what Babel-HMAC provides should
use Babel-DTLS instead.

> If N^2 is feasible, it would be good to hear how those keys are managed.

Not in Babel-HMAC, no.  We've tried to be very clear about that in Section 1.1
of draft-ietf-babel-hmac-00 :

   The protocol defined in this document assumes that all interfaces on
   a given link are equally trusted and share a small set of symmetric
   keys (usually just one, two during key rotation).  The protocol is
   inapplicable in situations where asymmetric keying is required, where
   the trust relationship is partial, or where large numbers of trusted
   keys are provisioned on a single link at the same time.

   This protocol supports incremental deployment (where an insecure
   Babel network is made secure with no service interruption), and it
   supports graceful key rotation (where the set of keys is changed with
   no service interruption).

   This protocol does not require synchronised clocks, it does not
   require persistently monotonic clocks, and it does not require any
   form of persistent storage.

If you believe this deserves further clarification, we'll be grateful for
your guidance.

-- Juliusz