Re: [TLS] Draft status and updates

Eric Rescorla <ekr@rtfm.com> Tue, 01 December 2015 19:29 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 D61D71B2F5E for <tls@ietfa.amsl.com>; Tue, 1 Dec 2015 11:29:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.677
X-Spam-Level:
X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] autolearn=no
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 RKymutp3u6zt for <tls@ietfa.amsl.com>; Tue, 1 Dec 2015 11:29:25 -0800 (PST)
Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (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 ADB271B2F5A for <tls@ietf.org>; Tue, 1 Dec 2015 11:29:25 -0800 (PST)
Received: by ykfs79 with SMTP id s79so20144190ykf.1 for <tls@ietf.org>; Tue, 01 Dec 2015 11:29:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=6IidVQfhdhafZjBME/nplCo7FiAzLjJqXDPKUTSdFME=; b=aIS+JwVo2OAJIMq7WuliqNvbl6yvWZwN5/PbL7Ua74NxjFsnj34Y1Pz+Ve1seRFyvX lWnjlBi2GcA0BDr7r2OW1IUkecFO7fzAXDWGbJE7097s+ABk0v1mbn5h1SKuat/MlJpX nNiNqOtLbCHyYn9K2QoTMf0O/LuQr7JCRoKTvUXgaiEXe8mS7gqCE6HwmeGwAckr+jZH tLpXJ5XCIP+7q+GZxLTQ1B4bTA1v3HSjOuBqz8hrHEJgkGOnOz5s1albM+jSplQhali9 9TnNiN7nbOBgKBCloRsJJOstoEyfwpGk5m80RhetMUVENsF+KSEBZK48ayM/S4URbMce 4iVw==
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=6IidVQfhdhafZjBME/nplCo7FiAzLjJqXDPKUTSdFME=; b=jSj/LbPvp4VCpRxOBCXZ+NisIjI07KUBZDjCViX7zhbO/dSPfoYTBWbeBloucCkgQe S/nEdY1TdoSf8+OS21clsOz/Xx8ZmOkIodeUvhCT8/chLaPi168H67K57ua7P2kOqvuJ P0g2IxQ2z9PLXXjCmu3qrBGD49Wt4ZQ/39d9fUYUjrKFe92sgdzNiGnDzezYXSTdaLH4 6bY9Ntysi54RqG06odtqcmZosRLekiUFm4V1Fly3/BZRrE7cUAftkc0bI8Qtm7b5ZICE 9mt+Ka6UI6QAY3epOHOTr2rMRxcuVDhKkgq4a4xh2coOSXyJMnnFnB43xaVY5X9jkEDi /GUg==
X-Gm-Message-State: ALoCoQkfx2xM2JxwJzIoeCas7wj9h/d7n+P5rTfVUAR/kWqLvtHdAIYxTv/SdKLVtvDCwX3ZMwWY
X-Received: by 10.129.73.198 with SMTP id w189mr30382985ywa.223.1448998164973; Tue, 01 Dec 2015 11:29:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.249.197 with HTTP; Tue, 1 Dec 2015 11:28:45 -0800 (PST)
In-Reply-To: <CABcZeBNS1r2vjKhioOQdyHh9dgFhFmZL+-6qJQpn01Tqfw2a-g@mail.gmail.com>
References: <CABcZeBNxxC=uOg3bKtJP2bpMa9Z7En_RR2q3zn-qduse+Oh8-g@mail.gmail.com> <20151201185733.GB15222@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBNS1r2vjKhioOQdyHh9dgFhFmZL+-6qJQpn01Tqfw2a-g@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 01 Dec 2015 11:28:45 -0800
Message-ID: <CABcZeBOWUjSg6hpb-Hg=oJyT5c8dwdjuzLaMZVK9hTGDv6DUqA@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary="001a114dc814e778ad0525db2c5d"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/WGvwpol8r4xRuTa_S4BoaGKJ-cc>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Draft status and updates
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, 01 Dec 2015 19:29:28 -0000

On Tue, Dec 1, 2015 at 11:19 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> Ilari,
>
> Thanks for your quick review.
>
> On Tue, Dec 1, 2015 at 10:57 AM, Ilari Liusvaara <ilariliusvaara@welho.com
> > wrote:
>
>> On Tue, Dec 01, 2015 at 10:11:17AM -0800, Eric Rescorla wrote:
>> >
>> > This clears out the big pipeline stall from PR#316, but probably has
>> > created some bustage. Expect a series of cleanup commits and some
>> > other things that were head-of-line blocked this week and then
>> > draft-11 in the next week or so. Please file PRs and/or github
>> > issues for any issues you see.
>>
>> Looks like the note about the PSK+ClientCert "attack" got lost
>> somewhere.
>
>
> See the last graf of:
> http://tlswg.github.io/tls13-spec/#certificate-verify
>
> I pointed to the e-mail by Sam's group and also prohibit entirely
> the use of cert-based client auth in pure PSK, since that
> seemed safer. If you think more is needed here I would be happy
> to add it.
>
>
> While I don't think that is important as the underlying
>> issue is fixed, I think there might be a note about dangers of using
>> server certificates in any mode where transcript and configuration
>> do not jointly imply SS.
>>
>
>
>
>> Actually, scanning the editor's copy, it looks VERY broken to me:
>> I don't see how server certificate verify (indirectly) signs on the old
>> configuration. Such signing is required for security, as otherwise
>> SS is not impiled by signature, breaking authentication.
>>
>> Previously, the document was clear about this...
>>
>
> I'm sorry, but I'm not following the issue you are raising here. Perhaps
> you could expand further? Here's my reasoning.
>
> 1. The server delivers the server configuration in handshake #0
> and signs the entire transcript with the certificate verify. At this
> point the client has assurance of the server's g^s.
>
> 2. In handshake #1, the client sends g^x and there is authentication
> for g^xs and hence the client knows that any data it is sending to the
> server in 0-RTT is actually going to the server.
>
> 3. The server provides g^y in his ServerHello and then g^xy and g^xs
> are jointly used to produce the traffic keys and also to form a MAC over
> the handshake. As Hugo pointed out originally, this alone should
> be sufficient to authenticate the server's side of the connection and
> you could omit the server CertificateVerify (Hugo, please correct
> me if I have misunderstood).
>
> 4. However, for consistency reasons (per the discussion in Prague),
> the server *also* signs the entire transcript. This authenticates
> g^y (even though the MAC with g^xs already authenticated it)
> and proves possession of the signing key.
>
> Trying to read between the lines, is your concern that the server is
> now no longer explicitly signing over the ServerConfiguration in
> its CertificateVerify [Note that the client continues to do so]?
>

And, I should note the server's certificate.

-Ekr


> The idea
> behind removing that was to make the 1-RTT part of the handshake
> more uniform regardless of whether 0-RTT data was used.
> I'm certainly open to putting that back in if it's needed, but can you
> explain your concern in more detail?
>
>
>
> > In addition, PR#354 (https://github.com/tlswg/tls13-spec/pull/354)
>> > implements the rekey mechanism that we discussed in Yokohama.  There
>> > was broad agreement to adopt something like this.  I would appreciate
>> > it if a few people could give it a sanity check, but absent strong
>> > objections, I intend to merge this PR on Friday.
>>
>> The restrictions on when the rekey message can be sent: Do those
>> essentially boil down to "any time after sending Finished"?
>>
>
> Except not during 0-RTT.
>
>
> Also, I think the requirement to immediately send the KeyUpdate
>> is problematic. I think it should be requirement to send it as
>> next record(s).
>
>
>> The two aren't the same: The first seemingly requires scheduling
>> extra flights, which can be problematic. The second can piggyback
>> on existing flights.
>>
>
> Good suggestion. PR welcome.  :)
>
> -Ekr
>
>
>>
>>
>> -Ilari
>>
>
>