Re: [TLS] Semi-Static Diffie-Hellman Key Establishment for TLS 1.3

Christopher Wood <christopherwood07@gmail.com> Thu, 08 March 2018 23:34 UTC

Return-Path: <christopherwood07@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5873124B17 for <tls@ietfa.amsl.com>; Thu, 8 Mar 2018 15:34:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eivx_1OATeuP for <tls@ietfa.amsl.com>; Thu, 8 Mar 2018 15:34:00 -0800 (PST)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA0112E050 for <tls@ietf.org>; Thu, 8 Mar 2018 15:33:51 -0800 (PST)
Received: by mail-qk0-x231.google.com with SMTP id d206so1741527qkb.3 for <tls@ietf.org>; Thu, 08 Mar 2018 15:33:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=X3OsWlVEzy24S6rd31IkrD5R6JU0EGdgTHAGT5+gNN8=; b=EsvRktorLbGezL87vRupmGzBESF4mUj005dGQkz1Jpj9eAoSAAYHFuxHKtAQM1Xobu /tqSrOaE2/ap4xQWYrNSkWVfBeSp+WVM2A0fzuaQvImB4cQpYcIxnPnnckrnS7Fhr/Kb cciSjo06Z0El4ryDIZMjK7IxQVm5qiBswLlTbWRvZPASI7mWtRYNG7p2zQk7xC4Z2g4K STRjHiMgfy5wWeZSgDaEaBAaZdosdPlUzTaOlvaaNMETVHcJwrEmFEV6WJ+k2zbgZrxy rx8M+rwFpXPoInLUrN/8CD5+IxDfIS1wod3BBIBUzfR2XjdRBBEXDZrDuCBpK2W0vVk9 Yytg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=X3OsWlVEzy24S6rd31IkrD5R6JU0EGdgTHAGT5+gNN8=; b=h0FvuCv7LmMKpMBvQvEGtfw0PD00cm6qUViHqhqQ7p1RQLXeIq0fL9ld3KAbbPWT6/ s54oSpsl6IxRkxE9UWYPz1Ev+whC7Wxzc1m4R/8IkUSgc6WBWglC/DEkUHw4MrzJF/9X wP/+G+pSQY5QLWMjaJsqSEV51m3TGzhMiSL0lnCtDMBg5efca54sh/UxuKe2IdUvN5Ma dhQuxofH4fbbFgmi4y1VOHTrqP4Ugj3tgJrLjeX+RUb8Fv9sqETjgiAQTBO6/uJdYOY0 LnlmlFqU7Bq0plKWax7CFWjaYbJ2xdGSdRD0Yr0RP2CruRl/uUbKeK7UVpg9J+45pIu/ lrOw==
X-Gm-Message-State: AElRT7EY1k3Y5/5Jy2xfsavvhvMBYIxiCvaynUl5E1xT3OnSw1RY1PAC BfmMtWxjeqRVZoJH8y7q6T8eQk5E
X-Google-Smtp-Source: AG47ELvC1E6GPdREmYRr5Ac3O8ngbIYuL38mNF6E4IRERJjJPy43658azFgHn11EZAKqkji04zoV7w==
X-Received: by 10.233.232.75 with SMTP id a72mr42377429qkg.76.1520552030101; Thu, 08 Mar 2018 15:33:50 -0800 (PST)
Received: from [192.168.2.161] (cpe-67-246-123-177.twcny.res.rr.com. [67.246.123.177]) by smtp.gmail.com with ESMTPSA id s42sm14445086qtc.82.2018.03.08.15.33.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Mar 2018 15:33:49 -0800 (PST)
Date: Thu, 08 Mar 2018 18:27:10 -0500
From: Christopher Wood <christopherwood07@gmail.com>
To: Tony Putman <Tony.Putman@dyson.com>, Eric Rescorla <ekr@rtfm.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <38f530d3-e394-4a84-8e40-a223ee8cc83e@Spark>
In-Reply-To: <CABcZeBNowz0irFwU-hJkrbV=zJhW4Vgtn5=e6zvm_NU2ZAG7_g@mail.gmail.com>
References: <CABcZeBON1KiUUFx9h863APxB31Poy-czNpYS1+HwZjyQxn6wEw@mail.gmail.com> <b76b0d82-5714-4e1e-82ff-3f8af59c2c3e@Spark> <140080C241BAA1419B58F093108F9EDC1678CD1A@UK-MAL-MBOX-02.dyson.global.corp> <CABcZeBNowz0irFwU-hJkrbV=zJhW4Vgtn5=e6zvm_NU2ZAG7_g@mail.gmail.com>
X-Readdle-Message-ID: 38f530d3-e394-4a84-8e40-a223ee8cc83e@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5aa1c858_6b8b4567_d813"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2B1QdyIgMHEWoO-1QrnQnjvzXuQ>
Subject: Re: [TLS] Semi-Static Diffie-Hellman Key Establishment for TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2018 23:34:06 -0000

On Mar 8, 2018, 6:25 PM -0500, Eric Rescorla <ekr@rtfm.com>, wrote:
> > On Thu, Mar 8, 2018 at 9:41 AM, Tony Putman <Tony.Putman@dyson.com> wrote:
> > > Hi Ekr,
> > >
> > > Firstly, thanks for this. My primary reason for putting together draft-putman was to propose a handshake exchange which only uses a single asymmetric algorithm. If this proposal is extended to include raw public keys (I think these are already supported, but not mentioned in the text) and an ECDH-based MAC for client authentication, then this satisfies my constraints.
> >
> > Yep, that should actually work just fine.

Agreed.

> >
> >
> > > As a single data point, I can state that some of the IoT products that I'm working with already use static ECDH keys for client authentication (though not within TLS).
> >
> >
> > >
> > > Although OPTLS is able to use 0-RTT, I don't see how this capability could be used in this implementation, even if the client knows the server static key. Because SS is only included in the key schedule when the master secret is generated, the client_early_traffic_secret has no input secret. Conversely, if the SS is included in the key schedule as the PSK, then the certificate cannot be decrypted by a client which does not have the server static key.
> >
> > Yes, I agree with you. OPTLS had a less linear key schedule. I think if you wanted to do 0-RTT you would have to have it be a pretend PSK as you suggest in your draft.

That sounds right — the early application data key with OPTLS is `g^{sx}` instead of `psk`.

Best,
Chris

> >
> >
> > > I think that this and draft-putman are not competing, but rather that they serve different use case
> >
> > Agreed. It sounds like you have a set of use cases where you know how to predistribute the server key? This is the part we found challenging int he web context.
> >
> > -Ekr
> >
> >
> >
> >
> > > s. They could be synergistic, such that this draft provides a mechanism for distributing a static key which could later be used in a draft-putman exchange; however, the natural continuation would be to use a resumption PSK, so this would only be useful if there were a long gap between session, which seems unlikely.
> > >
> > > Regards,
> > > Tony
> > >
> > > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Christopher Wood
> > > Sent: 07 March 2018 01:26
> > > To: <tls@ietf.org>; Eric Rescorla
> > > Subject: Re: [TLS] Semi-Static Diffie-Hellman Key Establishment for TLS 1.3
> > >
> > > Thanks for putting this together! I’m in favor of the mechanism and look forward to discussing it. Negotiating with signature_algorithms is a simple way to roll this out, it fits in cleanly with the key schedule, and the benefits outlined in the introduction (PRNG hardening, plausible deniability, etc.) seem worth the effort. Although the approach has its roots in OPTLS, we will certainly need to re-assess its impact on the handshake. (I know of some folks actively working on this.) We also need to spend more time thinking about the open issues — specifically, the story around early data encryption. This variant has the benefit of enabling early data with public key encryption, as opposed to (trackable) symmetric key encryption. It’s unclear to me whether or not we need to address the static share publication issue for this benefit.
> > >
> > > Anyway, thanks again for the draft. I’ll read it carefully before London.
> > >
> > > Best,
> > > Chris
> > >
> > > On Mar 5, 2018, 4:14 PM -0500, Eric Rescorla <ekr@rtfm.com>, wrote:
> > >
> > > Hi folks,
> > >
> > > Here's another entry in the DH-only pile.
> > >
> > > I've just posted:
> > >    draft-rescorla-tls13-semistatic-dh-00
> > >
> > > This implements a semi-static DH exchange mostly borrowed from
> > > OPTLS [0]. There are obviously connections with draft-putman, but
> > > this is more oriented towards implementing a 1-RTT style
> > > exchange where the client has no foreknowledge of the server's
> > > capabilities (though it's extensible to 0-RTT) than towards
> > > pre-distributed DH keys, and has less invasive changes to the
> > > key schedule.
> > >
> > > We'd like 10 minutes to discuss this in London.
> > >
> > > Thanks,
> > > -Ekr
> > >
> > > [0] http://ieeexplore.ieee.org/abstract/document/7467348/
> > >
> > >
> > >
> > > _______________________________________________
> > > TLS mailing list
> > > TLS@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tls
> > >
> > > Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury, SN16 0RP, UK.
> > > This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please immediately and permanently delete it, and do not use, copy or disclose the information contained in this message or in any attachment.
> > > Dyson may monitor email traffic data and content for security & training.
>