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

Watson Ladd <> Thu, 06 November 2014 05:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AB4C01A1A5B for <>; Wed, 5 Nov 2014 21:58:29 -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 4hbw3ov-Pmeq for <>; Wed, 5 Nov 2014 21:58:28 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F1B591A1A59 for <>; Wed, 5 Nov 2014 21:58:27 -0800 (PST)
Received: by with SMTP id z6so1076553yhz.10 for <>; Wed, 05 Nov 2014 21:58:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=08w81Anbo7dywmhfr5gU7QpHSYO8X1keXgHWPz3NHII=; b=1DnXwRv6l37RXF0kMEmKkMWn2n/FsEKipZjAjwYJO5B56H/pUyUfKcLny69/XvP553 nOIx9EO9nWmIDxKz5J3+q3JyaL4U5ymaNLffiHQAllH7foaKN1FdY4cXGRIsUtdEQBtS akjxzM9fp1cgDWN3C1GwMGlW1FxFZcsOoN9P1TkK3UTYYX9T+sY6phHjJ12S+WP7V5tN 8qrXMFNE10s0pF0ufVbkWONCui7SRUzEwrRaCAp8ERv9zvUwKF+wxRFGao1UTIbVFvsJ 8mU2s2hl8MTGyCxAb07fcMxYQswDdlICS8UNdnVgX2awyFmN+/GASVi6HghAbuM4QQnj xRHQ==
MIME-Version: 1.0
X-Received: by with SMTP id 40mr1740799yho.172.1415253507232; Wed, 05 Nov 2014 21:58:27 -0800 (PST)
Received: by with HTTP; Wed, 5 Nov 2014 21:58:27 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
Date: Wed, 05 Nov 2014 21:58:27 -0800
Message-ID: <>
From: Watson Ladd <>
To: Nico Williams <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
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: Thu, 06 Nov 2014 05:58:29 -0000

On Nov 5, 2014 10:01 AM, "Nico Williams" <> wrote:
> On Wed, Nov 5, 2014 at 11:56 AM, Watson Ladd <> wrote:
> > On Nov 5, 2014 9:51 AM, "Nico Williams" <> wrote:
> >> Perhaps we should pin latest datetime advertised by the server for
> >> which other things are being pinned.  This would prevent time travel
> >> into the past.  Time travel into the far future is, presumably, not
> >> that big a deal, even with pinning, because server operators will
> >> strive to make sure that doesn't happen.
> >
> > Or kernels can set the flag that stops this from being possible. We should
> > note the issue, and, as with randomness, let the vendors solve it.
> User-land code can "correct" kernel time.  For example, most Kerberos
> libraries record time offset between the client and the KDC, and
> correct local time when making AP-REQs for any service subsequently.
> Clients trust KDCs, so that's OK.
> But if TLS clients also attempt to correct local clocks on the basis
> of time advertised by arbitrary servers...  Obviously, that's the
> problem: TLS clients should not use the TLS protocol to attempt to
> correct local clock skew.


No, the issue is that an attacker can fool NTP clients, and thus
change the time on a computer. All we need to do is note the need for
secure clocks, and let the implementor figure out how to get the right
time. If there is an issue with NTP security, and there is, that's for
the NTP WG to solve. That may be an OS issue: the same is true for the
generation of random numbers. We already depend on secure time for
OCSP stapling and certificate validity: I don't think Hugo's proposal
is worse in that regard. We need to document the dependency, but
whether water clock, sundial, atomic clock, pendulum clock, or RTC on
the motherboard, we don't care how that is satisfied. Martin Thompson
makes this same point upthread.

I think the OPTLS proposal makes it extremely easy to host servers
worldwide while keeping the certificate in a nice jurisdiction, or on
a slow HSM while enabling performance enhancements as computers get
faster. I think it resolves many longstanding security issues, and
doesn't introduce any obvious new ones. (Of course, the cross-protocol
attacks may be an issue: why data signed with the same key doesn't
have a type pre-appended to it in the form of a UUID or similar is
beyond me)

It provides most of the tricky requirements like 0-RTT and privacy of
certificates. It's genericly secure. It's a performance enhancement
for sites that have avoided PFS until now because of performance
issues. There's plenty of details to flesh out, and it may be that we
find showstoppers that make the entire approach not work. But it would
be a shame if we wasted another 6 months getting to this point by
patching a protocol that is extremely hard to think about: there isn't
a 0-RTT proposal on the table yet beyond this one.

We still need to decide some details if we move forward, and hammer
out the serialization and interaction with the TLS 1.2 negotiation
that ensues when a TLS 1.3 hello is sent to a TLS 1.2 server (do we
share group specifications? which extensions make sense and which
don't? are ciphersuites going to be shared across the Client Hello?
How do signature groups relate to the DH groups?) If I could start
with a clean slate, it would be with this proposal. Yes, it's a major
change. It doesn't solve all our problems. Some semantics,
particularly around client authentication, will likely change.
However, it has the great benefit of existing, and I hope we decide to
build on it or find flaws that doom it.

Watson Ladd


> Nico
> --