Re: [TLS] Re-thinking OPTLS

Hugo Krawczyk <> Sat, 22 November 2014 23:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EEAEF1A037E for <>; Sat, 22 Nov 2014 15:04:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P1sNMhtfRDD0 for <>; Sat, 22 Nov 2014 15:04:13 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7F0631A036A for <>; Sat, 22 Nov 2014 15:04:12 -0800 (PST)
Received: by with SMTP id p9so4679049lbv.21 for <>; Sat, 22 Nov 2014 15:04:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=kl0E+Nc3F+nVZroI5E/JjPSd+DnC6WWt2CPF9y6NAoY=; b=tWSu/kp4/Fn1y8LlIai6RpYRDHpxLgy0CeVFGvQ1KRlKwHqENNUv4M34ips7RLjluV UHCxYv9gd/hIZcbECcZQSusZQKt2j1XQAXOE2jhi7VokXA8Wn+DHz3XFdsN8U+upOY7s RHCb+q1UzJ/sbovu+8ZS1e7fJpFANiavArnCKh0XfSWGmHGLUw3Z4OfLYFII1pnatdvd zjTNPsBC3XyqeuZRjkSkauxk3M1MEHKV+cbmru4fN37RlCkC/dg+rGfsplhLkfrYFljm 58EIp0s+0+k1wGLMGlKoqBYv3Xu73Okn4YI4JzMkUQOZJnU7HhJ8SKcEj/3aw9vS9JKH N0zA==
X-Received: by with SMTP id yb11mr12648751lbc.51.1416697450739; Sat, 22 Nov 2014 15:04:10 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sat, 22 Nov 2014 15:03:40 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Hugo Krawczyk <>
Date: Sat, 22 Nov 2014 18:03:40 -0500
X-Google-Sender-Auth: sX4NscvzZlwJYkgLZHeLSRRiLMk
Message-ID: <>
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary="001a1134de924e3d9605087a94c5"
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 23:04:16 -0000

Martin, one does not have to resort to delegation for using OPTLS, you can
ECDH certificates, except that you may need a certificate for each group you
support. The *same* goes for using ECDSA in current TLS. That is, if you
to be able to sign in TLS with different groups (I think this will be
then you need one certificate for each group that you want to support or
you need delegation (for signing subcerts for mutliple ECDSA keys).

Let me parse all the options we have.

If you don't want delegation you have three options: RSA certificates (and
for per-session RSA signing performance cost), per-group ECDSA certificate
(requiring per-session signature), or per-group ECDH certificates (requires
signing at all and no delegation). All other cases require delegation.

So, if you don't care about per-session RSA cost AND do not care about the
added value/functionality of OPTLS, then you can keep current TLS 1.3.

Otherwise, you are left with essentially two choices.

- If you are willing to live with multiple certificates, one per-group, then
  run OPTLS with ECDH certificates: It gives the best
  security-functionality-performance return (and no delegation).

- If you don't want per-group certificates then you must resort to
  (this is the case whether you use current TLS 1.3 with ECDSA or use
  But if you are going to live with delegation then there is no advantage
  TLS 1.3 over OPTLS.

The interesting thing about OPTLS (with the optional online signature tweak)
is that it can accommodate all of the above options in one compact protocol:

- you don't want delegation or per-group keys, use OPTLS with Online RSA
  signature (the subcert signs the client nonce)

- you don't want delegation but accept per-group keys, use OPTLS with ECDH
  certificates (no signatures, no subcert/delegation)

- you don't like the above options (hence forced to live with delegation),
  use OPTLS with offline-signed subcerts for ECDH keys.

The above, I think, is nice and provides a strong justification for OPTLS.
However, if you want the protocol to support delegation and are concerned
about the
"HSM attacks" discussed here, then you need to require servers to obtain new
certificates (ECDH, ECDSA or RSA). The point is that you don't want servers
use their TLS 1.2 (or earlier) keys to also sign subcerts.


PS: ​I will answer the issue of key derivation separately.​

On Sat, Nov 22, 2014 at 1:14 AM, Martin Thomson <>

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