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, 1 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.