Re: [TLS] 0-RTT & resumption
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Tue, 04 August 2015 06:51 UTC
Return-Path: <ilari.liusvaara@elisanet.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C401B3671 for <tls@ietfa.amsl.com>; Mon, 3 Aug 2015 23:51:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 Ox7wwt-3X7_h for <tls@ietfa.amsl.com>; Mon, 3 Aug 2015 23:51:53 -0700 (PDT)
Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C751B366C for <tls@ietf.org>; Mon, 3 Aug 2015 23:51:51 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 784D33FC9; Tue, 4 Aug 2015 09:51:49 +0300 (EEST)
Date: Tue, 04 Aug 2015 09:51:49 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20150804065149.GA27148@LK-Perkele-VII>
References: <201507251453.18237.davemgarrett@gmail.com> <CABcZeBNXfPv02nzxW8YJnZdypcr-DvfmT5cqto29mXo+weEi9w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABcZeBNXfPv02nzxW8YJnZdypcr-DvfmT5cqto29mXo+weEi9w@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/joTui1J4WlC46Wa6prCh66R9wLM>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] 0-RTT & resumption
X-BeenThere: tls@ietf.org
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." <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: Tue, 04 Aug 2015 06:51:56 -0000
On Sat, Jul 25, 2015 at 09:07:49PM +0200, Eric Rescorla wrote: > > > We agreed on how to do this in Prague. The sticking point was establishing > the cipher suite. I have WIP text on my machine for both of these which I > will be > sending early next week, once I get enough sleep to be able to clean it up, > so I'd ask people to sit tight till then. > Okay, now the PR (#211) seems to be up, let's review: - Lacks client-driven client authentication[1]. All client auth is server driven, which I think isn't very useful in real world (there are all sorts of bad hacks[2] trying to work around lack of client-driven auth). - EncryptedExtensions looks to be mandatory in some exchanges, optional in others. I agree it should be mandatory in all (issue #213). - "The client's cryptographic determining parameters match the parameters that the server has negotiated based on the rest of the ClientHello." ... Does that mean the client has to guess what ciphersuite the server will choose (more than pure-PSK vs. GDHE, which is unvaoidable with just one encrypted block)? - Regarding other extensions, it doesn't look to be the same list as ServerHello extensions, as max_fragment_length is on ServerHello, but certainly makes no sense as 0-RTT extension (I didn't see any other possibly relevant extensions). - Am I reading the syntax wrong, or does the extensions field in server configuration only allow exactly one extension (shouldn't it be zero or more)? Also, regarding issue #212, unless the Certificate is handled specially, it would mean that the signature does not cover certificate. And not signing the certificate (esp. the public key within) causes problems in some exotic cases (I don't know if any of those cases pop up in TLS 1.3). I think it would simplify the security analysis a bit if CertificateVerify was always immediately before Finished and covered everything before that point. On client side, one gets that "no certificate" special case anyway. [1] A lot of time, the client knows if it is going to present client certificate or not before it initiates the handshake. [2] At best ugly, at worst security problem. -Ilari
- [TLS] 0-RTT & resumption Dave Garrett
- Re: [TLS] 0-RTT & resumption Viktor Dukhovni
- Re: [TLS] 0-RTT & resumption Eric Rescorla
- Re: [TLS] 0-RTT & resumption Ilari Liusvaara
- Re: [TLS] 0-RTT & resumption Eric Rescorla
- Re: [TLS] 0-RTT & resumption Eric Rescorla
- Re: [TLS] 0-RTT & resumption Ilari Liusvaara