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
- [TLS] Are we holding TLS wrong? David Schinazi
- Re: [TLS] Are we holding TLS wrong? Fossati, Thomas (Nokia - GB/Cambridge)
- Re: [TLS] Are we holding TLS wrong? Hannes Tschofenig
- Re: [TLS] Are we holding TLS wrong? Martin Thomson
- Re: [TLS] Are we holding TLS wrong? Juliusz Chroboczek
- Re: [TLS] Are we holding TLS wrong? Martin Thomson
- Re: [TLS] Are we holding TLS wrong? David Schinazi
- Re: [TLS] Are we holding TLS wrong? David Schinazi
- Re: [TLS] Are we holding TLS wrong? David Schinazi
- Re: [TLS] Are we holding TLS wrong? Martin Thomson
- Re: [TLS] Are we holding TLS wrong? Juliusz Chroboczek
- Re: [TLS] Are we holding TLS wrong? Juliusz Chroboczek
- Re: [TLS] Babel-HMAC [was: are we holding TLS wro… Juliusz Chroboczek
- Re: [TLS] Are we holding TLS wrong? David Schinazi