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

Nico Williams <> Tue, 11 November 2014 02:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 51C631AD3F4 for <>; Mon, 10 Nov 2014 18:12:43 -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 Tg50e93dIH7u for <>; Mon, 10 Nov 2014 18:12:42 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 84B551AD3DE for <>; Mon, 10 Nov 2014 18:12:05 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 615474012D696; Mon, 10 Nov 2014 18:12:05 -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:content-transfer-encoding; s=; bh=c6n5w9tYE8MgA5T2o4eY2vPh33w=; b=eGpYCedz+jV PlY7mJWlJRVLtSI5TaNHzF+FktDJaxHEvX33Ra7g0Vmd0O4PY5CW4bulaqfloOau 6MCkqD3hfzkf/S6FnYucDRp/ooguTB6kQEsjD3+k6tDhLAY/K1rg7/yg4KcGI5Xf OvKs5Jb3fDif43lqb1AKdzPagAkjMSNE=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id 0AF5E4012D695; Mon, 10 Nov 2014 18:12:04 -0800 (PST)
Date: Mon, 10 Nov 2014 20:12:04 -0600
From: Nico Williams <>
To: Yoav Nir <>
Message-ID: <20141111021201.GH3412@localhost>
References: <> <> <> <> <> <> <> <> <20141111005220.GG3412@localhost> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
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 02:12:43 -0000

On Mon, Nov 10, 2014 at 03:53:35PM -1000, Yoav Nir wrote:
> On Nov 10, 2014, at 2:52 PM, Nico Williams <> wrote:
> > 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. 

The time should be relative, as a TTL.

"This resumption ticket is good for 2 hours."

"This DH pubkey is good for 2 hours."

"hours" is good.  "days" is not.

That's good enough.  The items in question should be stored in memory
(tmpfs, ...), not stable storage anyways, so all that matters is that
time tick somewhat accurately for that TTL, unless the client reboots.

> Sure, we MUST fix time. [...]

Not for this.

> > 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.

Maybe, but until and unless we convince ourselves that these delegated
DH pubkeys can have lifetimes much longer than session resumption state
tickets... then there doesn't seem to be much value in static DH here.

> > 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. 

API-wise we can: you can have integrity and confidentiality protection
immediately, but PFS not until you consume the server's handshake
message.  (The GSS-API pretty much deals with this in the context of
authentication state, and it'd take adding a boolean flag to do the same
for PFS.)

The problem is that HTTP can't know if the data to be sent is sensitive,
and probably neither can the user-agent.  They have to assume it's all
sensitive.  If you want PFS you have to settle for either: a) (EC)DHE
and no 0rt every time, or b) (EC)DHE and no 0rt occasionally + 0rt w/
session resumption w/ short-lived sessions.