Re: [TLS] Re-thinking OPTLS

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C98401A037D for <>; Sat, 22 Nov 2014 15:09:51 -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 sLB0qhIlk6Wr for <>; Sat, 22 Nov 2014 15:09:50 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7AE461A036A for <>; Sat, 22 Nov 2014 15:09:49 -0800 (PST)
Received: by with SMTP id l4so252409lbv.11 for <>; Sat, 22 Nov 2014 15:09:47 -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=wh9FzI6DAG4o527N4psFasYYvQ43bLKcbOsprVqncFo=; b=SEZvAFeioBArobPzp0Svmvlf1toqR7C/BClnL+t1uplo9xNp5dH/MzcOzrQVPK9SdK PFlTXMtdJPJkQLYtI7gAmaMLrFFPSjtIPSPeOb4FDLuY0r34n4evKUV4LXsrz3YHImOM SuOW+yVJ0HJ4pagLg8OzWm6p/QuB/9i8BWHv+8X4TDECYgwkIr5txJ8OgQ3mCgAV1dKE DhpROThapq72V99JpWO+aUdSLbyq53Pd/1l5yyl22r1TaEfTNkXNx9kPTptOrQNHG2FB b2+ftM8Fb4LdP2BSlkP52tH4ww19BjYi642iAvZ24QfN8qSZO8LJMuYD4q/lpYNbzNrt 8XZA==
X-Received: by with SMTP id lu7mr12694567lac.81.1416697787553; Sat, 22 Nov 2014 15:09:47 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sat, 22 Nov 2014 15:09:17 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Hugo Krawczyk <>
Date: Sat, 22 Nov 2014 18:09:17 -0500
X-Google-Sender-Auth: l5FuK448BoqrIQAM48dL9d3njBc
Message-ID: <>
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary="001a113473da61a08a05087aa839"
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:09:52 -0000

See below on the issue of key derivation

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

​I haven't seen these slides and didn't know about them.
The derivation of keys based on g^{xs} and g^{xy} does NOT use a sum or any
other algebraic combination (although some combinations are secure, most are
not, and identifying the good ones is non-trivial). Anyway, I have left the
details of key derivation unspecified, not because they are not important
security (they are!), but because optimizing the derivation depends on the
functionality and properties one wants from the protocol and I wanted to
more about them from these discussions. For the moment just think that a key
derived from the above two quantities will be computed by hashing the two
together (with some additional information) and we will model the hash as a
oracle in the cryptographic analysis. The actual derivation will be a bit
involved for the sake of better provability but not significantly different
from an implementation point of view.


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