Re: [TLS] Comments on draft-ietf-tls-tls13-18

Watson Ladd <> Tue, 01 November 2016 15:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 388FD129841 for <>; Tue, 1 Nov 2016 08:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JpyWKnAbRNBr for <>; Tue, 1 Nov 2016 08:45:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 78DC0129AE0 for <>; Tue, 1 Nov 2016 08:45:17 -0700 (PDT)
Received: by with SMTP id 12so131767873uas.2 for <>; Tue, 01 Nov 2016 08:45:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id c92mr27854198uac.111.1478015116337; Tue, 01 Nov 2016 08:45:16 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 1 Nov 2016 08:45:15 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Watson Ladd <>
Date: Tue, 01 Nov 2016 08:45:15 -0700
Message-ID: <>
To: Eric Rescorla <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Comments on draft-ietf-tls-tls13-18
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Nov 2016 15:45:20 -0000

On Mon, Oct 31, 2016 at 2:28 PM, Eric Rescorla <> wrote:
> Watson,
> Thanks for your comments!
> On Mon, Oct 31, 2016 at 11:41 AM, Watson Ladd <> 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:
> 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:
> "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 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

>> 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:
> "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:
> "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

"Man is born free, but everywhere he is in chains".