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

Nico Williams <> Tue, 11 November 2014 17:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CFDB41A0140 for <>; Tue, 11 Nov 2014 09:33:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Bs140l_5OTpU for <>; Tue, 11 Nov 2014 09:33:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8336B1A0145 for <>; Tue, 11 Nov 2014 09:33:28 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 5478120047B87; Tue, 11 Nov 2014 09:33:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=KcAKqYsN5iBodE zdhKg0z8M9ra4=; b=VQQBKFvQx1JYe97TzRXMchitvm+Ckl22QXcYqC0P7OeYB+ erdszKfinq6X/9nvlEK+2yuawbMw3HyUX2nfoi6MEdtw+vfAIvbiFlEgYZg6OUBo GY9XGd1Xgw4OE3nqaI9gVrE80eA/kkENTuqCXGfNiUJzt1cSoZWEEGUmaRZIQ=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id DACE420047B85; Tue, 11 Nov 2014 09:33:27 -0800 (PST)
Date: Tue, 11 Nov 2014 11:33:27 -0600
From: Nico Williams <>
To: Hugo Krawczyk <>
Message-ID: <20141111173325.GK3412@localhost>
References: <> <> <> <> <> <20141111005220.GG3412@localhost> <> <20141111021201.GH3412@localhost> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "" <>, Hoeteck Wee <>
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 17:33:30 -0000

On Tue, Nov 11, 2014 at 09:46:38AM -0500, Hugo Krawczyk wrote:
> I am surprised to see such an abrupt decision to drop consideration of
> OPTLS. [...]

I didn't see such a decision.  Just a lot of questions.

> First, note that if we had ECDH certificates then this whole issue of how
> to sign the static DH key g^s would be moot. [...]

Yes, though there'd be no 0rt the first time a client meets a server
(unless DANE is used).

> The whole reason to create a "sub-certificate" for g^s by signing it with
> the server's certified signature is that we currently only have
> certificates for signature keys, not ECDH. This may or may not change in

That and the fact that we can't have intermediate CA certs because of
the lack of implementation (and deployment) of naming constraints, nor
can we have proxy certs [RFC3820] -I think, but correct me if I'm wrong-
for similar reasons.

(Note that RFC3820 proxy certs have no revocation mechanism.)

> the future - actually, as I argue below, there are advantages of sub-certs
> for g^s over a long-term ECDH certificate.

Isn't "sub-cert" ~= proxy cert?

> So what is the concern that has been voiced regarding the use of sub-certs
> for g^s? That the leakage of a private key s that was sub-certified allows
> [...]

That the "sub-cert" needs either a revocation scheme (not likely) or a
short lifetime.  The latter puts this on a par with session resumption,
thus making one (well, me) wonder what the advantage to the static DH
concept would be.

We could put static DH keys in DNSSEC and learn them that way, which
would get us 0rt.

> to impersonate the server for the validity period of that sub-certificate,
> and that clients with skewed clocks will be accepting it beyond the
> intended validity period. This is true but not different than the situation
> with current certificates. In particular, the validity period of the
> sub-cert will never exceed that of the signing certificate. How about
> revocation? It requires the main certificate revocation exactly as needed
> now.
> So none of these issues is worse than vulnerabilities of signing keys today.

Server certificates can be revoked (wellll).  Delegations can't be, not
without losing the optimization value of delegation in the first place.
That seems like a deal killer for anything other than short-lived