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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 847EA1AD2C0 for <>; Mon, 10 Nov 2014 16:30:03 -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 lpLcChRBJ8Si for <>; Mon, 10 Nov 2014 16:30:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DA82B1AD28D for <>; Mon, 10 Nov 2014 16:30:01 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id B8060264058; Mon, 10 Nov 2014 16:30:01 -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=5b2mIKWYIrhle5 K1oeUGsy9Mdqc=; b=WKTPdEiZxJrwNObNtlYvpOg96/Ur/IXU0oQWB9KV/gcMaR tivCA7xJyGGlBm/KO8f/mC2XitRaJa6SlhXDflC4XAne+YTlioVo4/Pq6i7p4n1B 01eKUm57T6zht0KAjGqLH4safDzD/JMOyYygEjN2ZTCwWn+djKop9oSpZr8og=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id 67FF326406A; Mon, 10 Nov 2014 16:30:01 -0800 (PST)
Date: Mon, 10 Nov 2014 18:30:00 -0600
From: Nico Williams <>
To: Yoav Nir <>
Message-ID: <20141111002959.GF3412@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:30:04 -0000

On Mon, Nov 10, 2014 at 02:08:06PM -1000, Yoav Nir wrote:
> It should be noted that CloudFlare manages to make delegation work
> ([1]) even without changing the protocol, but I wonder a little about
> that solution. Isn't the latency horrible? [...]

Session resumption makes up for it, amortizing the impact on the user.

It's probably no worse (typically) than 2 or 3x the normal latency, for
the first connection (or first handful of concurrent connections).  It'd
be interesting to see how noticeable this is, but I suspect that on the
whole it's not really all that noticeable.

>                                      [...] How secure is the
> connection between CloudFlare and the customer? [...]

In principle it should be no less secure than TLS itself.  (I've not
looked closely enough, but I imagine that's exactly what CloudFlare uses
for their connection to their customers' key sign server.)

>                                           [...] Does it create a
> sign-everything service?

Yes, which is why you need to get authentication (of CloudFlare to the
key server) right, so you can authorize key sign requests.  And the
customer should be doing this with server names and certs and keys that
are only for the CloudFlare use anyways.

This brilliantly lets CloudFlare out of the business of having certs
with lots of names, and it simplifies key management for their
customers.  The price is that this requires SNI.

> [1]