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

Yoav Nir <> Tue, 11 November 2014 01:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8B4571AD3E6 for <>; Mon, 10 Nov 2014 17:53:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8QcJPnH3HH8n for <>; Mon, 10 Nov 2014 17:53:43 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 638AA1AD3E1 for <>; Mon, 10 Nov 2014 17:53:43 -0800 (PST)
Received: by with SMTP id b13so10507311wgh.26 for <>; Mon, 10 Nov 2014 17:53:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XKpBwSWxIZJKS9Ze9fPn8FdeCmJadct4LJhHgWkYR1w=; b=jFeemxAXviS5G2mN0mevI6MgPWg0bSoCNApd+ErvbNnDSYtHH6UZh0C1O3cxPl6Zm0 4gZUNDvj0BUEknmdj+LxycOa384z8dF4UtbUpMCVUMTJ9Ka3c34v6lVjhyJaAFzg3Zho +blBfDhziuqHYxUc5ZRasgUyuQMBrUG+NHCNEUZiG0e1HendVRyDdF0WK3AY7W9ccL2L yj7cLvj5wN3ivclFd1kJ0MyiyzqB9qEyI2cLTkEccs770BbkeWAhjRe23ZBrl8XlAHDb 293WhaMT0IXmsM+wakgtgZ/9T0gGR1z3OY9uXFSEdrYlcQf48u+/V4mMIFYVfI7wqeQX BH9A==
X-Received: by with SMTP id cv8mr25107314wjb.114.1415670822184; Mon, 10 Nov 2014 17:53:42 -0800 (PST)
Received: from ( [2001:67c:370:160:e455:ad7f:8d9b:e850]) by with ESMTPSA id ll2sm12566786wjb.11.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Nov 2014 17:53:41 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Yoav Nir <>
In-Reply-To: <20141111005220.GG3412@localhost>
Date: Mon, 10 Nov 2014 15:53:35 -1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <20141111005220.GG3412@localhost>
To: Nico Williams <>
X-Mailer: Apple Mail (2.1990.1)
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 01:53:46 -0000

> On Nov 10, 2014, at 2:52 PM, Nico Williams <> wrote:
>> 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.
> The delegation has to have a short lifetime because otherwise it
> might as well be a certificate issued by an intermediate CA...
> ...which the customer can't get because of the failure to widely
> implement and deploy PKIX name constraints.
> But also because of revocation: if you have to check the status of the
> key then you lose the 0rt.
> By putting a short lifetime on the delegation that problem goes away.
> But then there's no advantage over plain session resumption.

How short is “short”? This is yet another thing that is hosed by the non-availability of a secure time signal. Clocks are skewed, so if you use a notAfter date that is less than 24 hours away, you’re going to have clients thinking that this has already passed. 

Sure, we MUST fix time. But we also MUST fix PKIX name constraints, and I think we’re close to solving the latter than we are to solving the former.

> Even if each 0rt connection can lengthen the delegatee key's life by
> having the server send a fresh signature of the key as needed, the
> server could also just refresh the session resumption state/ticket.
> IMO the main value in static DH is in learning the server's static DH
> pubkey out of band, via DNSSEC (DANE).  That eliminates all these
> concerns while enabling 0rt connections _every_ time for servers that
> have such keys.

This assumes a deployed DNSSEC. That will happen some time after the secure time signal.

> Of course, 0rt connections can't provide proper PFS to data sent
> immediately after the client's first TLS handshake message.  That's a
> problem, no?

I guess you can’t have everything.