Re: [TLS] Comments on draft-ietf-tls-tls13-18
Watson Ladd <watsonbladd@gmail.com> Tue, 01 November 2016 15:45 UTC
Return-Path: <watsonbladd@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 388FD129841 for <tls@ietfa.amsl.com>; Tue, 1 Nov 2016 08:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 JpyWKnAbRNBr for <tls@ietfa.amsl.com>; Tue, 1 Nov 2016 08:45:18 -0700 (PDT)
Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (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 78DC0129AE0 for <tls@ietf.org>; Tue, 1 Nov 2016 08:45:17 -0700 (PDT)
Received: by mail-ua0-x232.google.com with SMTP id 12so131767873uas.2 for <tls@ietf.org>; Tue, 01 Nov 2016 08:45:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=r3SrC7K+dlnneIDhH6rweQDUKVi8sdKBgkRXkwgFlIo=; b=rPl+CSQQUUdCGelPWyLvic/0PrPBVGmpMWPKBj7sxA8qXrAx3xEmWIaHm6uNa+xEvy Os7G5uZYkwkk8YBOX7SSCaxmv2+X5LhCf8/N6+MWOd0VmEsVsfSFaiLDq1kooHwk14HA eipjodBAw39FzrDD9igA/r2X6dPbPQBmez+rcUuxMpB44QUV6pilVwoGf3Pj00VercbH Rjnog9RHIj2u2jeGXEZs59CVdl4VNsJggnVCQ1og1bUykO3iPhJCYfRpRLgTr+0FGHfi oiYIwiAeZ4xdeqkyd4lPCYtbf77Qr9rpy2XPMSEf9+y0ogMlKpOxfeHRy0O+E0UffMhw RqZg==
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-transfer-encoding; bh=r3SrC7K+dlnneIDhH6rweQDUKVi8sdKBgkRXkwgFlIo=; b=PRUv9TISaHyGs7Tzz8cNU4MZ2R6GYuf1Mh3MjllWIkW7zaG9Lp+QS39IOsAw8fMpRM 6oVNpSG2zOV4ZZK4kAoRZoLmnylqRIoD4MIGXn6Qo4n++qHXlrEhIv9QxwkwGYtzaDVX r6558fB6X1qpHEbpaH2Mmp9d9o08ryDvhF4xeF5K4TFd6clLj1AQhJ2/CaOHLHpBbsfc eZ2zRADHxpT2TEFC6bUFLWlj65Q7c29jhSCx0jR6RPGU97BWZC8ryt5n9tW5eyGnX7VE s9c5DDYWptuSYWF6bycLXRAqtTMGouqwgLzGsds2OUfVDFNXY7w47fTF6uLZ/U312z8e idcw==
X-Gm-Message-State: ABUngvekgDCkEeA6884NQYHAYbaB5aEJ+guaRCrDCUEWG05BsrNVd7zSYVC3wW9+mQZIfjCFfNg+Ruv5mTjSyg==
X-Received: by 10.159.40.101 with SMTP id c92mr27854198uac.111.1478015116337; Tue, 01 Nov 2016 08:45:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.68.135 with HTTP; Tue, 1 Nov 2016 08:45:15 -0700 (PDT)
In-Reply-To: <CABcZeBOGc0rfEFB8BYwtSw6-EJ5bFav5mLCz4a2T7XXUHN5sDA@mail.gmail.com>
References: <CACsn0ckbKRRy0sQ+i8bNLSqh-mqAb0UMHY13CyzmonGj8cL-qQ@mail.gmail.com> <CABcZeBOGc0rfEFB8BYwtSw6-EJ5bFav5mLCz4a2T7XXUHN5sDA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Tue, 01 Nov 2016 08:45:15 -0700
Message-ID: <CACsn0c=QYM7TZwWFzifYLa0ebsGaKdAVtjJ9XapX6T6HvGiV8w@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/64zAxnc53415JmTpSIYULvbfefo>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Comments on draft-ietf-tls-tls13-18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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 Nov 2016 15:45:20 -0000
On Mon, Oct 31, 2016 at 2:28 PM, Eric Rescorla <ekr@rtfm.com> wrote: > Watson, > > Thanks for your comments! > > On Mon, Oct 31, 2016 at 11:41 AM, Watson Ladd <watsonbladd@gmail.com> wrote: >> >> Hello, >> >> Looking at the history of TLS implementation attacks we see that many >> result from the standard not strictly enough prescribing behavior, >> particularly of the state machine. This draft does not actually fix >> this problem, but continues to present example flows without >> explicitly requiring them to be the only possible flows. > > > >> For example, consider HelloRetryRequest. Do servers only send one of >> these per connection, or can it be resent multiple times? Obviously >> there is a DoS possibility here, but I do not see where this behavior >> is explicitly defined. I think we should require that the server only >> ever sends one HelloRetryRequest, and then terminates the connection >> if the ClientHello is unacceptable. > > > > The server is forbidden to send multiple HRRs and the client is required > to enforce it. See: > > https://tlswg.github.io/tls13-spec/#hello-retry-request > > I agree that we don't require the server to behave this way. I can fix the > draft to say this. That sounds good. The more we can turn bugs into ones that violate the spec, the easier it will be to get them fixed. (Hopefully) > > >> At no point is it stated that only >> the example flows should be supported. I would prefer more clarity >> about what messages are to be expected when, especially with alerts. > > > Actually the text does say something here: > https://tlswg.github.io/tls13-spec/#handshake-protocol > > "Protocol messages MUST be sent in the order defined below (and shown in the > diagrams in Section 2). A peer which receives a handshake message in an > unexpected order MUST abort the handshake with an “unexpected_message” > alert. Unneeded handshake messages are omitted, however." > > However, this text was also in 5246, so I think there's a fair argument > that it's not strong enough. I'm not quite sure how to make it better. > Suggestions? So I was reading in order, so I saw the diagrams first, which seemed like examples and then missed this sentence in the draft. Maybe a sentence in section 2 would help? > > >> ECDSA cannot be used with x25519 or x448, but the draft seems to >> require support in TLS 1.2 for this as a consequence of its >> description of the fallback mode. > > > I don't *think* that that's true: can you point to the specific text that > you are concerned with? It's the interaction between https://tlswg.github.io/tls13-spec/#negotiated-groups and the statement that ECDSA needs to be supported with any curve appearing in the supported_groups extension when negotating a TLS 1.2 hello. We explicitly call x25519 an elliptic curve there. Yes, I doubt anyone will end up making an implementation that does this (except by accident). > > >> ALPN, resumption, and 0-RTT remain problematic. For instance we see >> that 0-RTT data is sent with the same ALPN state when the PSK was >> derived, but this could be different from the ALPN transmitted and >> negotiated during the handshake, which is explicitly allowed later in >> the document. I do not understand what is supposed to happen in this >> scenario. > > > Here's the relevant text: > https://tlswg.github.io/tls13-spec/#early-data-indication > > "If any of these checks fail [ALPN is in the list above] the server MUST NOT > respond with the extension and must discard all the remaining first flight > data (thus falling back to 1-RTT). If the client attempts a 0-RTT handshake > but the server rejects it, it will generally not have the 0-RTT record > protection keys and must instead trial decrypt each record with the 1-RTT > handshake keys until it finds one that decrypts properly, and then pick up > the handshake from that point." > > Is there anything else you'd like to see here? > >> Appendix B removes the text about upper-layer protocol interactions >> with 0-RTT I provided, merely discussing the API. I think this is a >> mistake: how 0-RTT should be used safely depends on the upper-layer >> protocol, and can be complex. API guidance is not enough. > > > This ended up in the main text: > https://tlswg.github.io/tls13-spec/#zero-rtt-data > > "Protocols MUST NOT use 0-RTT data without a profile that defines its use. > That profile needs to identify which messages or interactions are safe to > use with 0-RTT. In addition, to avoid accidental misuse, implementations > SHOULD NOT enable 0-RTT unless specifically requested. Special functions for > 0-RTT data are RECOMMENDED to ensure that an application is always aware > that it is sending or receiving data that might be replayed." > > Is this missing pieces you think we need? Yes, thanks for pointing out where I missed it. > > >> There is still a note about needing a channel binding mechanism in the >> text. I think this should be resolved soon so it can be analyzed, >> probably built on top of the exporter mechanism. Either that, or we >> consciously punt and remove the note and replace with something else. > > > The idea here is that we need a separate draft that just says "use exporters > with > label X". I think we remove the note and see if we can get someone to write > that draft. > > >> As for process, I support the idea of having a last call on November >> 20th, and then completing the security analysis by January 20th (or >> whatever date was decided). This will prevent a flurry of changes >> potentially breaking things. > > > That's the idea. > > -Ekr > >> >> Sincerely, >> Watson Ladd >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > -- "Man is born free, but everywhere he is in chains". --Rousseau.
- [TLS] Comments on draft-ietf-tls-tls13-18 Watson Ladd
- Re: [TLS] Comments on draft-ietf-tls-tls13-18 Ilari Liusvaara
- Re: [TLS] Comments on draft-ietf-tls-tls13-18 Eric Rescorla
- Re: [TLS] Comments on draft-ietf-tls-tls13-18 Watson Ladd
- Re: [TLS] Comments on draft-ietf-tls-tls13-18 Martin Thomson
- Re: [TLS] Comments on draft-ietf-tls-tls13-18 Watson Ladd
- Re: [TLS] Comments on draft-ietf-tls-tls13-18 Martin Thomson