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

Hugo Krawczyk <> Thu, 13 November 2014 18:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 947151A9253 for <>; Thu, 13 Nov 2014 10:55:14 -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 8pE4u1IZyKSp for <>; Thu, 13 Nov 2014 10:55:12 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5E1581A924E for <>; Thu, 13 Nov 2014 10:55:12 -0800 (PST)
Received: by with SMTP id gf13so1871001lab.27 for <>; Thu, 13 Nov 2014 10:55: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=ZTwh/ktEjV4LxHodyk7SHLVctOO8Y5Lr+8nhP2gzV0s=; b=ABHDAbgiVkUSica3ot9NVoYwG9FNP6hReKSBWc/vT+uj6ccofluyCtGSqCc8oHNEVt 2ehEYP0nz8ic2uiow9VL7PD+K1AaDFGiiRrXAQ6us9ZqFwxy/0TZ+yd53miaVBmeUThR VyTIX9n8JG0EJxG7G7qok+JwsQa607XPrE7NYY54wrKxfVx7PiKBlk9HJmBs6mRp2Muq TX8ddXsg5/AffekLM8UO/2t31fXI04fR/4C5c4szhWBjQAmlnsb6bT9Mx7i70Pwl30KK 7EMfvlM+GXu5/fIIPWkAkAtmcilm7zRU5KrK+zbq9o5KkEru8qHGnSs2w7lfbXcY8The 6nvg==
X-Received: by with SMTP id v1mr4016177lal.3.1415904910868; Thu, 13 Nov 2014 10:55:10 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 13 Nov 2014 10:54:40 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <20141111005220.GG3412@localhost> <> <20141111021201.GH3412@localhost> <> <> <20141111173325.GK3412@localhost> <> <20141111203740.GN3412@localhost> <> <> <> <>
From: Hugo Krawczyk <>
Date: Thu, 13 Nov 2014 13:54:40 -0500
X-Google-Sender-Auth: atmPtd0sxqqw54NMJy1RCqBhRg0
Message-ID: <>
To: "Salz, Rich" <>
Content-Type: multipart/alternative; boundary="001a11c356263f857d0507c20d7c"
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, 13 Nov 2014 18:55:14 -0000

If you consider the t-mode of OPTLS I suggested in the previous email then
the changes relative to 1.2 are not much more significant than those
introduced in 1.3. Please think about this point. It is important! Right
now people are going through the process of digesting these ideas so it all
seems much more complex than they really are.

This is particularly true for the t-mode where the only thing that changes
w.r.t current TLS 1.3 is that servers generate keys g^s which they can do
as frequently or non-frequently as they wish, can support as many groups as
they wish, require no certification and raise no issues of delegation. The
rest is just a change of what you sign and the key derivation formulas. It
is hard to believe that this should be considered as changing things
radically. The fact that this enables the more forward looking r-mode
should be an advantage that servers can enjoy down the road (without yet
another revision of the protocol). In particular, the r-mode could be the
real incentive (together with 0-RTT, for those that need it) to move to
1.3. Currently, the only substantial thing that 1.3 is offering (other than
security improvements that people seem to consider less significant than
functional/performance improvements) is forward secrecy. I am not sure that
by itself it would be a strong enough incentive to upgrade.


On Thu, Nov 13, 2014 at 1:18 PM, Salz, Rich <> wrote:

> I think the major concern is that this is a pretty radical change from the
> current deployment model of SSL/TLS.  For what it's worth, I think it's
> cool and clever and has a number of real nice properties. But we are
> already getting 'picked on' for adding too many new things, and I am
> concerned that adding this, fairly late in the game, will delay the
> deployment of TLS 1.3 as people will take a step back and consider if they
> really need to use this revolutionary new protocol, rather than the
> evolutionary changes they were expecting.
> I used my personal opinion here, but I feel pretty comfortable saying I'm
> not the only one who feels this way. It's a case of "too much, too late."
> Does that make sense?
> Can we wrap up TLS 1.3 and perhaps do a TLS 2 based on these concepts,
> including a  non-CA trust model?
>         /r$