Re: [TLS] Re-thinking OPTLS

Watson Ladd <> Sat, 22 November 2014 07:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E201E1A007D for <>; Fri, 21 Nov 2014 23:23:39 -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 MpWysAJNCvfh for <>; Fri, 21 Nov 2014 23:23:36 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8C8821A007B for <>; Fri, 21 Nov 2014 23:23:36 -0800 (PST)
Received: by with SMTP id 131so2962799ykp.13 for <>; Fri, 21 Nov 2014 23:23:35 -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=DzJh3RmgbK8Dh+qDoKCuBNQW1/LUFvpIP3uFmAj6Rkw=; b=VHDE9OrJcCYyTog7UPbEL2HyAdFhylSkVxkVL57Ilbp+zgWNrT0J/Sp4SsP8nvvbdO kSeM2b267MS1FAY3CaCHMi5XFg2zJP9DjFYa1+MFrRPZwam1ilbvUMaEgZU4WJylJQuT N9/b8W+W4uWMjF+KHhcmwTxwJY8AhJBkEx0etuAZzdH8MNOV5QclG9gHS0TdccHcQkS1 H8z+wUSeK/6vbm+P7Us0FUijpOSs5nLb3GvBv52dCjc+VawpHCjEQabvYPOlEmm35btF mPvh7p2DrZtGIyBnz4e7pIL+M14ACoJJmmmozjn69ZmWIP3deu3U5u3spPg6ZmDLGEGg jGTQ==
MIME-Version: 1.0
X-Received: by with SMTP id g6mr7925980ykf.34.1416641015750; Fri, 21 Nov 2014 23:23:35 -0800 (PST)
Received: by with HTTP; Fri, 21 Nov 2014 23:23:35 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Fri, 21 Nov 2014 23:23:35 -0800
Message-ID: <>
From: Watson Ladd <>
To: Martin Thomson <>
Content-Type: text/plain; charset="UTF-8"
Cc: Hoeteck Wee <>, "" <>
Subject: Re: [TLS] Re-thinking OPTLS
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: Sat, 22 Nov 2014 07:23:40 -0000

On Fri, Nov 21, 2014 at 10:14 PM, Martin Thomson
<> wrote:
> On 21 November 2014 19:29, Hugo Krawczyk <> wrote:
>> I am glad to hear this too. Please let me know what the sources of perceived
>> complexity are.
> The only items of note were:
>  - the second update to the handshake protection under g^{xs}+g^{xy}.
> We all realized that this was trivially addressed (ekr had a slide at
> the meeting that showed an easy simplification, which should be in the
> meeting materials).

Both variants were in fact in Hugo's email. However, if you have
computed [xy]g, there are no savings from computing
[xy]g+[xs]g vs [xs]g. I'm not sure the "variant of Hugo's proposal" in
the slides is worthwhile at all: the original reason to use
[xy]g+[xs]g was for a 1-RTT round trip with forward secrecy, and it
was mentioned that this would require other changes.

In fact the scheme presented on the slides as a "variant" is insecure,
in addition to having no efficiency gains. Did anyone catch the

(For the correct variants, as well as description of the attack on
this variant see,

>  - the delegation scheme itself
> I don't think that you can underestimate the costs involved with
> creating an external dependency of any sort - for any project. The
> reliance on PKIX updates could be problematic.  That said, I'm not
> entirely sure that this is as straightforward a win as you suggest.
> If such a flag existed, using it would create the delegation problem
> we were most concerned about.

I understood the delegation problem as one concerned with the
following scenario: someone owns a box with an HSM attached, signs a
delegation, uses it surreptitiously. So long as TLS 1.3 could work for
a cert issues not for it, this was a problem: certain security
guarantees would be broken.

But if TLS 1.3 is opt-in how is this a problem? The HSM could execute
the ECDH related operations itself, and return only the keys, and a
server requiring this level of security without such an HSM could
continue using TLS 1.2. Or is the issue one that any protocol not
requiring online signatures would run into?

Moreover, even if people don't want delegation, OTLS is still a good
idea. Many of the areas like client authentication and 0-RTT that are
labeled "very sketchy" or "TODO" in the EKR draft are solved by OTLS.
As far as I know, we've not had anyone look at the TLS 1.3 draft and
say they could prove it secure. That said, with renegotiation dead, it
should be a lot easier. But I'm not an expert in this area: it may be
the current draft is comparable to OPTLS in terms of provability.

> I'll let others explain more of the thinking behind the delegation
> problem.  I think that it's the only real issue with your proposal
> that you need to worry about.  The performance characteristics are
> probably manageable.

Not requiring online signatures is a win for performance for users
with RSA certificates. The current draft has very similar performance.


> _______________________________________________
> TLS mailing list

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin