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

Nico Williams <> Tue, 11 November 2014 00:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 23F7D1AD23D for <>; Mon, 10 Nov 2014 16:19:37 -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 vCGUvMRRG_x3 for <>; Mon, 10 Nov 2014 16:19:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 084541AD0D1 for <>; Mon, 10 Nov 2014 16:19:34 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id BB59527BC061; Mon, 10 Nov 2014 16:19:33 -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=vZX3i0OfJRG1r1 yesG2mCw5yaW8=; b=sn6fl8Q/Us2F92/lYswrACpurvGs7HL1glx622EBZDVTTY jgfrWQyR+voOL1OAC07uW1x/ezOroWsiGV25tZ6XzN4Uyqah9+cEpwTvnXJAhAkd DhCKMtOtH1kZi8c5b1UjYGB8O/3nvoiBbivZlzIqoFYVelU691pppEKky5IOA=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id 69E6427BC05D; Mon, 10 Nov 2014 16:19:33 -0800 (PST)
Date: Mon, 10 Nov 2014 18:19:32 -0600
From: Nico Williams <>
To: Yoav Nir <>
Message-ID: <20141111001930.GE3412@localhost>
References: <> <> <> <> <> <> <> <> <> <>
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)
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:19:37 -0000

On Mon, Nov 10, 2014 at 02:08:06PM -1000, Yoav Nir wrote:
> The issue is that the server sends a certificate + a buffer that is a
> long-term DH public key signed with the private key associated with
> the public key in that certificate. 
> Anyone who has that certificate and buffer plus the long-term DH
> private key can impersonate the server. It's delegation in the sense
> that the server can sign a DH public key and let another node
> impersonate it. 

Session tickets too are a form of delegation, with narrower scope (just
one client).  But surely clients won't be sharing these delegated DH
pubkeys with each other?

This sort of delegation is probably a fine thing, except that:

> So the argument against it is that the new signed buffer is in effect
> a credential, a certificate. Except that this kind of certificate does
> not have the PKIX stuff. Specifically, there is no revocation for that
> signature. A compromised signed  DH public key can only be revoked by
> revoking the certificate.   As we are not currently prepared to work
> on TLS delegation, we don't want to sneak delegation in through the
> back door.

it needs to have an explicit notAfter date, that needs be in the near
future.  The acceptable lifetime of a delegated server pubkey should be
comparable to the acceptable lifetime of a session ticket, and both
should be relatively short (hours, not days, and certainly not weeks).