[TLS] draft-ietf-tls-tls13-24 supported_versions complexity

Nikos Mavrogiannopoulos <nmav@redhat.com> Thu, 01 March 2018 13:24 UTC

Return-Path: <nmav@redhat.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 49E93126DCA for <tls@ietfa.amsl.com>; Thu, 1 Mar 2018 05:24:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 h9NWnzJlUWi1 for <tls@ietfa.amsl.com>; Thu, 1 Mar 2018 05:24:54 -0800 (PST)
Received: from mail-wr0-f176.google.com (mail-wr0-f176.google.com [209.85.128.176]) (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 3F879126BF0 for <tls@ietf.org>; Thu, 1 Mar 2018 05:24:54 -0800 (PST)
Received: by mail-wr0-f176.google.com with SMTP id m5so6114606wrg.1 for <tls@ietf.org>; Thu, 01 Mar 2018 05:24:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:mime-version :content-transfer-encoding; bh=Rs5PS/NwzFY1PTMDeXtvspxJg3ZynpjrEMtjGgPQU0E=; b=DbZUkPn5ThFTiz4CZGHJhZ4AbjCLG24v7zFbxXdJjHBeKd0CIhDricPQQUxDTjsYw0 98KHP/Vv+AFmDLxV/Odg7R88e1Ow/s2sGqkPftIVg36wpBCeJV4rgWxsLn3sf1nD/ati zgLroquJG3ItXgJZFcwjuoIzrIGyMlav5YjjHt80uecAmop+3n5bJHwl5xzI3bDggiSs 9O5LXJJfctnUAmwWwy4yisu9ePM6rMSDHxWiFAVanGDlrFmPYYdXCdzXz1Ds38hBkWzS 3/EB4t6reX7M+WrKTLrIyBD1vDRCq/FHfItzaISiSt+PH0JOaR/6zakKY5OuurEG/cKp Saqw==
X-Gm-Message-State: APf1xPDPNzh793THPGZ83f5HXMuUXBNBNatcG2HMfa8cKfQ2od8NeILI 6j2ovOto6WkmYEsAEJnm+VqemQ==
X-Google-Smtp-Source: AG47ELuDAQUiCcHLO2mus5QYRqEXFlgFQMxKbwZmeHEPkJPYQkdxmCgG9xvTv6wQ6TQUgEhzIoaTCg==
X-Received: by 10.223.179.82 with SMTP id k18mr1777089wrd.173.1519910692625; Thu, 01 Mar 2018 05:24:52 -0800 (PST)
Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id k18sm6478500wmd.4.2018.03.01.05.24.51 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 01 Mar 2018 05:24:51 -0800 (PST)
Message-ID: <1519910691.19043.48.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: ietf@ietf.org
Cc: draft-ietf-tls-tls13@ietf.org, tls@ietf.org
Date: Thu, 01 Mar 2018 14:24:51 +0100
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.5 (3.26.5-1.fc27)
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/A2z3c0_XBgromB_TtO2rDF5zGJU>
Subject: [TLS] draft-ietf-tls-tls13-24 supported_versions complexity
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 01 Mar 2018 13:24:56 -0000

The TLS draft after version -21 requires TLS1.3 servers to negotiate
pre-TLS1.3 versions with a new, mechanism. The document states:

   "If this extension is present, servers MUST ignore the
   ClientHello.legacy_version value and MUST use only the
   "supported_versions" extension to determine client preferences."

...

   "Note that this mechanism makes it possible to negotiate a
   version prior to TLS 1.2 if one side supports a sparse range."


At this point, a server receiving a supported_versions extension which
contains the single value 'TLS 1.0' has to follow the draft's
recommendations and do:

  1. It MUST set the ServerHello.legacy_version field to 0x0303
     (TLS 1.2). 
  2. On the serverHello extensions include a supported_versions
     extension and advertise TLS1.0

That modifies the way TLS 1.1  or TLS 1.0 are negotiated, possibly
introducing new issues with middle-boxes which see TLS1.2 in the
ServerHello but TLS1.0 anywhere else. That is also a quite impossible
code path (why would an implementation negotiate TLS1.0 using a TLS1.3
mechanism?). It is however anticipated to be used for that purpose as
this draft mentions:

   "Servers should be prepared to receive ClientHellos that include
    this extension but do not include 0x0304 in the list of versions."

Irrespective to any middle-box issues, I believe impossible code paths
allowed by the protocol are more likely to cause problems than solve
any, because they are often not tested, and provide attackers with
additional tools to manipulate implementations.

My recommendation to address that would to either ignore that extension
if pre-TLS1.2 is negotiated, or revert to -21 draft behavior for pre-
TLS1.3 protocol negotiation. That is, the server MUST not send the
supported_versions extension if a pre-TLS1.3 protocol is to be
negotiated. The first case ensures that there is a single way to
negotiate TLS1.x, where x<3, and the second that the clientHello
extension is only used informatively.

regards,
Nikos