[TLS] Secdir review of draft-ietf-tls-session-hash-04

Radia Perlman <radiaperlman@gmail.com> Thu, 16 April 2015 05:53 UTC

Return-Path: <radiaperlman@gmail.com>
X-Original-To: expand-draft-ietf-tls-session-hash.all@virtual.ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 96E931A90EE; Wed, 15 Apr 2015 22:53:47 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-tls-session-hash.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-tls-session-hash.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7122C1A90D4 for <xfilter-draft-ietf-tls-session-hash.all@ietfa.amsl.com>; Wed, 15 Apr 2015 22:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.333
X-Spam-Level:
X-Spam-Status: No, score=-1.333 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, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=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 aHtWogYpljUk for <xfilter-draft-ietf-tls-session-hash.all@ietfa.amsl.com>; Wed, 15 Apr 2015 22:53:42 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 16E691A90EC for <draft-ietf-tls-session-hash.all@ietf.org>; Wed, 15 Apr 2015 22:53:39 -0700 (PDT)
Received: from mail-lb0-x229.google.com ([2a00:1450:4010:c04::229]:35687) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from <radiaperlman@gmail.com>) id 1Yicjy-0001EY-Jz for draft-ietf-tls-session-hash.all@tools.ietf.org; Wed, 15 Apr 2015 22:53:38 -0700
Received: by lbbuc2 with SMTP id uc2so50501737lbb.2 for <draft-ietf-tls-session-hash.all@tools.ietf.org>; Wed, 15 Apr 2015 22:53:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=VL8OdO5aAqgq0ETCKr15cuNppSszaeCLT7Sp3jN/USg=; b=fUqQQHPZWcAHS70CYm5t34CAPYqOSDJ+i1UIi50P6FNDhfgBga+z5eOwL9v6ADY9Fn y6Z5tMnKxodZr9pfu96n+GQm+cQ4zaDJ0/61CLXqy60iTW9v+6UUMLJpS+U0j7kSwRe5 2AvDN7zxPZdGmszUJjhmLMAD19pvGTBevPgbhBHJfwY13HUrPLAM8ND0mtKULofQnNZV 521YSLB9mCfSXv/wVFbTM9mvluEGMsYEGGMTId7Z6UIhiaTxbqPvxZd88Qpq0W9rlGBf Jkk9JmgFEbGYJFyU33bwlYAjc4tL652opGuMF41iPaVz0XXqTWDKMua5iiPa1Yemwo19 Q5AQ==
MIME-Version: 1.0
X-Received: by 10.152.27.194 with SMTP id v2mr26562091lag.75.1429163598763; Wed, 15 Apr 2015 22:53:18 -0700 (PDT)
Received: by 10.112.133.68 with HTTP; Wed, 15 Apr 2015 22:53:18 -0700 (PDT)
Date: Wed, 15 Apr 2015 22:53:18 -0700
Message-ID: <CAFOuuo7MA9Rd7zbsic8pJgShYF8NRgnddyC5JHfA6hGcGkkAfA@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-tls-session-hash.all@tools.ietf.org
Content-Type: multipart/alternative; boundary=089e0158c2aca15e810513d1141d
X-SA-Exim-Connect-IP: 2a00:1450:4010:c04::229
X-SA-Exim-Rcpt-To: draft-ietf-tls-session-hash.all@tools.ietf.org
X-SA-Exim-Mail-From: radiaperlman@gmail.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
Resent-To: draft-ietf-tls-session-hash.all@ietf.org
Resent-Message-Id: <20150416055342.16E691A90EC@ietfa.amsl.com>
Resent-Date: Wed, 15 Apr 2015 22:53:39 -0700 (PDT)
Resent-From: radiaperlman@gmail.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/draft-ietf-tls-session-hash.all@tools/uMAJnmsOzfNZA17hjBCQ2YO7CL8>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/qf7rd9AJwJWaABnZRY7UQz7xAjo>
X-Mailman-Approved-At: Thu, 16 Apr 2015 07:32:49 -0700
Subject: [TLS] Secdir review of draft-ietf-tls-session-hash-04
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 16 Apr 2015 05:53:47 -0000

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors. Document editors and WG chairs should treat these comments just
like any other last call comments.

This document proposes an extension and a small computation change to TLS to
mitigate the "triple handshake" (and perhaps other related
yet-to-be-discovered) vulnerabilities in TLS. For details of the attack,
see: Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, A., and P.
Strub, "Triple Handshakes and Cookie Cutters: Breaking and Fixing
Authentication over TLS", IEEE Symposium on Security and Privacy
(Oakland'14) , 2014.

In my judgement, the proposed change does a fine job of addressing the
vulnerability. I assume this has gotten lots of other eyes as well.

I hope that someone has tested the major server implementations of TLS to
assure that they follow the spec and will ignore the new unrecognized
extension if a client presents it. The TLS spec clearly says that they MUST
do so, but there has been a history of hacks done by implementers to get
around bugs in legacy implementations. If there are a significant number of
implementations that get this wrong, it would be worth considering
implementing the extension in some different way (e.g. as an additional
proposed cipher-suite).

This vulnerability is subtle and would not affect the security of most uses
of TLS, though evaluating whether it does or does not in any particular case
is difficult so it makes sense to implement this change universally over
time. This spec, however, takes a hard line in the trade-off between
security and interoperability that I believe needs to be carefully
considered. In particular, I believe lots of implementers will *not* follow
this spec in implementing the feature in order to get greater
interoperability with deployed systems.

In particular, section 5.2 paragraph 4 & 5 say:

"If the server receives a ClientHello without the extension, it SHOULD abort
the handshake. If it chooses to continue, then it MUST NOT include the
extension in the ServerHello."

"If a client receives a ServerHello without the extension, it SHOULD abort
the handshake."

Implementations that follow these SHOULDs will not interoperate with any
existing implementation of TLS, making a phased deployment of the new
software impossible. I believe it would be preferable to say that
implementations of TLS SHOULD be configurable to reject peers that do not
implement the extension so that improved security at the expense of
interoperability can be enabled after a critical mass of deployments exist.

In section 5.3, there is similar language to disable session resumption when
the extension is not present. While this may be more acceptable because it
will not break interoperability, it *will* cause a significant performance
degradation in some important scenarios. I would again recommend that it be
a configuration parameter so that no one will refuse to deploy this change
because of performance concerns.

Section 5.4 also mandates breaking behavior (and here it is a MUST) in
scenarios where there is most likely to be a triple handshake vulnerability.
Given that there are cases with no such vulnerability and given that people
will be reluctant to deploy software that turns a subtle security
vulnerability into non-interoperability, I believe this should be a matter
of configuration.

Section 5.4 paragraph 4 seems to be undermining earlier requirements, saying
that it MAY be safe (to break rules stated earlier). Taking this to heart, I
would propose that the "MUST abort" clauses in sections 5.2 and 5.3 be
softened to at least allow - and perhaps recommend - implementations to
support this scenario.

-------

Nits:

In section 6.2, it is claimed that the security of TLS depends on the hash
function used being collision resistant, use of MD5 and SHA1 is NOT
RECOMMENDED. That would rule out use of TLS 1.0 and TLS 1.1. While a worthy
goal, I don't believe this enhancement makes migration away from TLS 1.0 and
TLS 1.1 any more urgent. I also don't believe that TLS depends on the hash
function being collision resistant (but only that it is second preimage
resistant).

P9: "each other identity" -> "each other's identities"
P10: "that where hence" -> "that were hence"
P11: "server/ Hence," -> "server. Hence,