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

Daniel Kahn Gillmor <> Tue, 11 November 2014 05:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A35BF1AD546 for <>; Mon, 10 Nov 2014 21:51:35 -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 pUXNZmPrDEDh for <>; Mon, 10 Nov 2014 21:51:32 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8770C1AD395 for <>; Mon, 10 Nov 2014 21:51:32 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 081E1F986 for <>; Tue, 11 Nov 2014 00:51:29 -0500 (EST)
Message-ID: <>
Date: Mon, 10 Nov 2014 19:51:25 -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
References: <> <> <> <> <> <> <> <> <20141111005220.GG3412@localhost> <> <20141111021201.GH3412@localhost>
In-Reply-To: <20141111021201.GH3412@localhost>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="bBe8uMKR6WLiVF258llsjdACt7lP5e1PI"
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 05:51:35 -0000

On 11/10/2014 04:12 PM, Nico Williams wrote:
> The time should be relative, as a TTL.

relative to what?

If the credential is standalone (e.g. in such a way that the signing key
can be kept offline) then the TTL established can be replayed by an
attacker who takes control of the DH secret to extend the lifetime of
the delegated credential, right?

if the credential isn't standalone (i.e. if it's accepted by the client
based on its inclusion in the signed handshake which has been
authenticated by a signature from the signing key), then we aren't in a
signature-less TLS scheme.

if it's not relative, but it's long-lived, then we introduce a new
revocation problem.  if it's not relative and it is short-lived, then we
introduce interesting clock skew issues (though perhaps those are the
same as OCSP-must-staple clock skew issues?)

None of this is to say that delegation is a terrible idea, but just that
the details matter and it's not something to casually adopt without
understanding the tradeoffs we're taking.

and those tradeoffs are complex enough that they seem to overwhelm the
possible performance gains from the OPTLS proposal.  (esp. when there
are other ways like ECDSA certs that give comparable performance gains).

> "This resumption ticket is good for 2 hours."
> "This DH pubkey is good for 2 hours."
> "hours" is good.  "days" is not.

I agree that short-lived is nice; I think it also possibly removes the
pro-OPTLS argument about keeping the signing keys offline.  (maybe
that's ok)

But without a concrete specification of what the delegation mechanism
looks like, the properties of the deployed proposal end up being very