Re: [TLS] OPTLS: Signature-less TLS 1.3

Daniel Kahn Gillmor <> Tue, 11 November 2014 00:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 281D11AD01E for <>; Mon, 10 Nov 2014 16:15:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gsnELksJPxeR for <>; Mon, 10 Nov 2014 16:15:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 554F61ACFEE for <>; Mon, 10 Nov 2014 16:15:43 -0800 (PST)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 8E900F986; Mon, 10 Nov 2014 19:15:39 -0500 (EST)
Message-ID: <>
Date: Mon, 10 Nov 2014 14:15:34 -1000
From: Daniel Kahn Gillmor <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Icedove/33.0
MIME-Version: 1.0
To: Watson Ladd <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="PARQIHUaC4v2AplrRhXl4Pchid16QTXbM"
Subject: Re: [TLS] OPTLS: Signature-less TLS 1.3
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Nov 2014 00:15:45 -0000

On 11/10/2014 01:45 PM, Watson Ladd wrote:
> Furthermore,  eliminating online certificates enables
> isolation of certs without a performance penalty.

if we get people to move their secret keys offline by replacing certs
with something that is cert-equivalent for purposes of authentication,
then what have we gained?

The reason to move secret keys offline is to protect the identity
credentials of the TLS endpoint, not because those keys are valuable in
themselves.  If a delegation process creates a new object that is an
identity credential for the TLS endpoint, and the secret part of that
object remains online, we haven't actually gained anything.

Note: we *could* gain something, of course, if we manage to clearly and
effectively scope the utility of the delegated credential more narrowly
than the parent credential; then moving the wider-scoped parent
credential's secrets offline is indeed a win.

But it's not clear how to do that kind of scoped delegation correctly --
or even what forms of scoped delegation are desirable -- do we want to
narrow the scope by time?  by identity?  by network address?  by protocol?

If someone wants to work on delegation in its own right, i think that
could be useful.  But adopting delegation "by accident" while we're
defining a new key exchange mechanism seems likely to get us into worse
trouble down the road.