Re: [TLS] 0-RTT & resumption

Eric Rescorla <ekr@rtfm.com> Fri, 07 August 2015 21:50 UTC

Return-Path: <ekr@rtfm.com>
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 537741A1A97 for <tls@ietfa.amsl.com>; Fri, 7 Aug 2015 14:50:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 0gP1iwd7WadK for <tls@ietfa.amsl.com>; Fri, 7 Aug 2015 14:50:56 -0700 (PDT)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (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 A6F641A1A04 for <tls@ietf.org>; Fri, 7 Aug 2015 14:50:55 -0700 (PDT)
Received: by wicne3 with SMTP id ne3so74527896wic.1 for <tls@ietf.org>; Fri, 07 Aug 2015 14:50:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=i21hygIt6h2SZSEcJuHpvbhBZlE4KRNiYDljZ6bpDuU=; b=CD+z6eslcIL5Eab855YSJKMSDBLvmHtd4gcoQCcwUmJ5CQDkg1z4DcyeNbHVvvmalJ vsQ3IJyDSaoXRS8vBRbC6ZAu/kpQSePOfa/lUBny+SdgsZe5JCP9UIMVFEvT8rEUeKPQ NO3bB+g6Gb6Plvp8HUg2pD0zFp7X/9XvGcsgc24toF8hDS04CAQ2h8L6I5sZIYVutlj/ Q6+InGdr0CmJl49q8ASMD4dTP7vlND2/R38gu9xAcZt556bGwGfhBO/FegsizjXwDxT+ yIUVX7cJH8x9mjtwuzIYL9quGDOXZa8jRdeDryFvoxpesvZVEc7DrwDj93uDIp0e4TrH vHIA==
X-Gm-Message-State: ALoCoQnC0uXQPGbWm+hJehAXYQVpuyqDw4OcY73WZ4n/OW647/R2Ioo1feMmnm8W5xyRQkkkxrpm
X-Received: by 10.194.79.225 with SMTP id m1mr19395037wjx.8.1438984254213; Fri, 07 Aug 2015 14:50:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.85.99 with HTTP; Fri, 7 Aug 2015 14:50:14 -0700 (PDT)
In-Reply-To: <CABcZeBPvu-n+RxdQ7oKYUFxRKd=+SBvX7n-aUo1au9caEOhvaA@mail.gmail.com>
References: <201507251453.18237.davemgarrett@gmail.com> <CABcZeBNXfPv02nzxW8YJnZdypcr-DvfmT5cqto29mXo+weEi9w@mail.gmail.com> <20150804065149.GA27148@LK-Perkele-VII> <CABcZeBPvu-n+RxdQ7oKYUFxRKd=+SBvX7n-aUo1au9caEOhvaA@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 7 Aug 2015 14:50:14 -0700
Message-ID: <CABcZeBNYYjDuB85Gvb17u2GHf4k_YscMNLqrOY-WwPL2iWb-+Q@mail.gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Content-Type: multipart/alternative; boundary=047d7b10c9034fbf6e051cbfa1ba
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/OPRutso8GO9gBnirIFxk4AVmH5E>
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: Fri, 07 Aug 2015 21:50:58 -0000

I've updated the PR based on feedback from Dave, Ilari, and Martin.

https://github.com/tlswg/tls13-spec/pull/211

I'll merge this PR on 8/11 unless there are serious objections. As usual
please send minor changes as github comments and/or PRs.

-Ekr


On Tue, Aug 4, 2015 at 5:40 AM, Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Mon, Aug 3, 2015 at 11:51 PM, Ilari Liusvaara <
> ilari.liusvaara@elisanet.fi> wrote:
>
>> 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
>
>
> Oops. It wasn't supposed to be done. I meant to make it a PR against my
> own branch so that I could get early comments from MT, but obviously that
> didn't work out. Regardless, thanks for your comments.
>
>
> - 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).
>>
>
> This is just extending existing practice for 1-RTT handshakes.
>
> I tend to agree with you that it would be good to change that, but I
> didn't want
> to do that in this PR, because it would be a big semantic change in TLS.
> I suggest you start a new thread on this topic, or perhaps add it to
> Andrei's
> client auth thread?
>
>
> - EncryptedExtensions looks to be mandatory in some exchanges, optional
>>   in others. I agree it should be mandatory in all (issue #213).
>>
>
> Me too. That's just editing error.
>
>
>
>> - "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)?
>>
>
> The client knows what the server selected based on his previous offer and
> the server's configuration (which by hypothesis is still extant) so the
> server
> should choose the same value again.
>
>
>> - 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)?
>>
>
> Yes. good catch.
>
>
> 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).
>>
>
> This seems like a good argument.
>
>
>
>> I think it would simplify the security analysis a bit if CertificateVerify
>> was always immediately before Finished and covered everything before that
>> point.
>>
>
> Isn't this always the case presently? Are you just thinking we should say
> it's
> a rule?
>
> -Ekr
>
>