Re: [TLS] Re-thinking OPTLS

Hugo Krawczyk <> Sat, 22 November 2014 05:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D189C1A003A for <>; Fri, 21 Nov 2014 21:30:06 -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 wbtb5xw67M3C for <>; Fri, 21 Nov 2014 21:30:02 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D1F01A0035 for <>; Fri, 21 Nov 2014 21:30:02 -0800 (PST)
Received: by with SMTP id pv20so5275104lab.23 for <>; Fri, 21 Nov 2014 21:30:00 -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=Zoa/aGQmOM40fwJQf9hYzuol15Qo0b45nZG+Oxp6IDo=; b=UFCgnrdRwAFDYC/sA1tP5laZDBVG2Hj7RCUTngYPbZ9FGkZYL9S52bkF8oBIgGW1rN XmH4utxq20dJ7wcBn/7ZYJWBnDxTzIjOfcej5eL4/f2f0iRy8k35FrFv8Ind48Nc1iLP UssvHeFCC8ZoDeBCA29U+j0ahqEVRI4UtYUEPOpvK0caDctSrrUBiChoI30tOYb5Egou x1HCoTioxpEp/eV4rFMhnNBpn8sfY+TJRfytfNOs6RMO93o+CwzghdandYBi3pm5cAjb Tx081wwpbE6YdL2oos/laJhaFAxrbOn/vTdCrx+ArKEb2lN7riDeVOIuBJuoTDqSKXMu 6rzQ==
X-Received: by with SMTP id aj2mr9177560lbd.70.1416634200638; Fri, 21 Nov 2014 21:30:00 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 21 Nov 2014 21:29:30 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Hugo Krawczyk <>
Date: Sat, 22 Nov 2014 00:29:30 -0500
X-Google-Sender-Auth: j87sUCIX7IqtTqUhtupB3j4Y06M
Message-ID: <>
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary="001a113462be4e4c5605086bda16"
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 05:30:07 -0000

On Fri, Nov 21, 2014 at 8:24 PM, Martin Thomson <>

> On 21 November 2014 11:55, Hugo Krawczyk <> wrote:
> > - It is a "last minute" proposal that will delay the publication of TLS
> 1.3.
> I don't think that this is at all the concern.  Far from it.  Not only
> did this not come up to my recollection, my impression that the
> participants in the conversation were seriously considering the
> proposal without regard to this particular cost.

​I'm glad to hear that the "last minute" objection that was communicated to
me is not a real concern and that people are willing to seriously consider
the proposal.

> The most trite argument leveled against your proposal was the
> complexity one, but even that was recognized as being manageable.

​I am glad to hear this too. Please let me know what the sources of
perceived complexity are.
I might have addressed some of these in my recent posts, particularly the
issue of delegation and certificates, but there is probably more to be
In particular, I am not expert in the realities of the certification world
- I do hope these realities will not mean a show stopper for the proposal.
After all, the same certification issues will arise with any protocol that
uses ECDH or ECDSA keys. Such protocol will either need per-group
certificates or will have to accommodate some form of "delegation" (what I
call subcerts) for signing keys in different groups.

​Another possible source of ​perceived complexity is the support of 0-RTT
as part of the protocol. Note, however, that while this feature is built-in
into the protocol, its use is optional and it has no extra cost for those
who do not use it. Its inclusion is simple to specify and it may avoid the
need for a future revision/extension of the protocol.