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 >> > >
- [TLS] Draft status and updates Eric Rescorla
- Re: [TLS] Draft status and updates Ilari Liusvaara
- Re: [TLS] Draft status and updates Eric Rescorla
- Re: [TLS] Draft status and updates Eric Rescorla
- Re: [TLS] Draft status and updates Eric Rescorla
- Re: [TLS] Draft status and updates Ilari Liusvaara
- Re: [TLS] Draft status and updates Ilari Liusvaara
- Re: [TLS] Draft status and updates Eric Rescorla