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

Watson Ladd <watsonbladd@gmail.com> Mon, 31 October 2016 18:41 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F27F31299E3 for <tls@ietfa.amsl.com>; Mon, 31 Oct 2016 11:41:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ZUHmbVSi4bL5 for <tls@ietfa.amsl.com>; Mon, 31 Oct 2016 11:41:57 -0700 (PDT)
Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 9E1811299FD for <tls@ietf.org>; Mon, 31 Oct 2016 11:41:48 -0700 (PDT)
Received: by mail-vk0-x235.google.com with SMTP id x186so53252056vkd.1 for <tls@ietf.org>; Mon, 31 Oct 2016 11:41:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=P4VIfyhXnSNWmW3ioTDEnQ82TQvBjqZERDQ5VhrNDFs=; b=OQof5MAqMn8imDOGWbRAkY/ehhTY6dNN9H697sS17ZCFcHQGB1q78JCaWT0CfqcV6Y zuxc1HqIMBqDia5008yAqNHg3KyFVCywSOdCSIV50oibXwvfaEQUYTq6uHjXbvNzmebU iY+XrPW/7FvWSZy1LktWUzc2IoofWsS3pNvvYtIetdFScOqMy6uzcQ6BVk05hWoAUqiC rjHHWg0JhxLdYGVxmxw5waadVmi+/v3MyFEbJKN25HtDv3Efxq5nAcKnBadoxzj5h3yh pBqhTh7tPvRdfigHzFs6rKlLwWq8a86uhKo0amocYm7RaUCZQi72sITGWmK9OlGSh6hQ Epcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=P4VIfyhXnSNWmW3ioTDEnQ82TQvBjqZERDQ5VhrNDFs=; b=aagShxEtfIukWw0r/sgBjfxx4tYQe1YHZ8dPtMbFSrIO3JUOIG6cJLRjaMJxsA57Cx OM4P6rtOtlXFLg/nGjpWtRTfwnetmSuJF7ChVsFRzOf3s7DX2rlmRZH7Tk3dVv+Uyqtu 0KaVOE6ctH6pEvjpcDQDQieYpBs9vQ6cNOu9GQOWx6jljIyUKCCeFBppTTLeuwIxKlwo /AoVmcEVvrqdUbRIQUVyNI6eA5ujkiuOn9zvKY69y86vfxfY6tLAGIZObMOR1fAEhwvs EPeNEDGgfqPo9lhhrPJ4drUWtmDD1FzkrHF7raPQPPbNpkF/4C9yJC6PwJN4k/6nGpuE U28A==
X-Gm-Message-State: ABUngveJUFlsEfUIgmzDRestFMMZ6YeiJJfaLL1nrCW9L33nGRtIm59LkGsRPhi1d5TWeCt9kz+vbxiP5XJO0Q==
X-Received: by with SMTP id z13mr6381999vkd.41.1477939307382; Mon, 31 Oct 2016 11:41:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 31 Oct 2016 11:41:46 -0700 (PDT)
From: Watson Ladd <watsonbladd@gmail.com>
Date: Mon, 31 Oct 2016 11:41:46 -0700
Message-ID: <CACsn0ckbKRRy0sQ+i8bNLSqh-mqAb0UMHY13CyzmonGj8cL-qQ@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/H6O8tED5BSywZDEL5uaf8z0kD4k>
Subject: [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: Mon, 31 Oct 2016 18:41:59 -0000


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

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. The mandated use of uncompressed
points invites easy wrong-curve attacks: mandating support and use for
compressed points would solve this problem. I think at minimum we
should fix the text to make clear what we mean about TLS 1.2.

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

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.

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.

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.

Watson Ladd