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

Watson Ladd <watsonbladd@gmail.com> Thu, 16 April 2015 15:34 UTC

Return-Path: <watsonbladd@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 740521A89C5; Thu, 16 Apr 2015 08:34:20 -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 57F031A89EF for <xfilter-draft-ietf-tls-session-hash.all@ietfa.amsl.com>; Thu, 16 Apr 2015 08:34:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.334
X-Spam-Level:
X-Spam-Status: No, score=-1.334 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, 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 uJtdbNJA0rgk for <xfilter-draft-ietf-tls-session-hash.all@ietfa.amsl.com>; Thu, 16 Apr 2015 08:34:15 -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 355491A8AB7 for <draft-ietf-tls-session-hash.all@ietf.org>; Thu, 16 Apr 2015 08:33:27 -0700 (PDT)
Received: from mail-wi0-x22e.google.com ([2a00:1450:400c:c05::22e]:33666) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from <watsonbladd@gmail.com>) id 1Yiln6-0005FT-8m for draft-ietf-tls-session-hash.all@tools.ietf.org; Thu, 16 Apr 2015 08:33:26 -0700
Received: by wiax7 with SMTP id x7so14450156wia.0 for <draft-ietf-tls-session-hash.all@tools.ietf.org>; Thu, 16 Apr 2015 08:33:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=t5mvbI2/US9Pkr8lrV7I4jj+eqnwmUjFhRoS9aCD000=; b=hkNsITo8FpupbWJVCNE/H6NEZwNMseiAAgfeAidHqe6Av0A/TBNUCpNAvYaNRoVeV6 Jvv+nMeC2u+V2umgPpj0rXkMV5j7owytJGP60tOM3A9TN8U/63m5rbXuVWAaDMI/WINf xRnbiv+G85DNepPPYBOIqIIvVz1iNOJuPsxNcBUMCL44fxTyzaUstrn6kwyHxmYhaqmQ WQzaD8eqdqB3HH8ZLs7FGo/k57AbqJs23kpaFHhGcZ5B7ArllHN4JJksSmqUW7dUWj23 M4vsIGWW6iG7GqtrhJFhj+S4mGdGhkxxwaMcxTORFDRNcFJoZHfs/ZcPxtMLuGpWd4HN yqkQ==
MIME-Version: 1.0
X-Received: by 10.194.9.98 with SMTP id y2mr62745068wja.85.1429198389460; Thu, 16 Apr 2015 08:33:09 -0700 (PDT)
Received: by 10.194.136.233 with HTTP; Thu, 16 Apr 2015 08:33:09 -0700 (PDT)
In-Reply-To: <BB1534CC-76ED-482E-BA9B-D11E8B52C7AE@gmail.com>
References: <CAFOuuo7MA9Rd7zbsic8pJgShYF8NRgnddyC5JHfA6hGcGkkAfA@mail.gmail.com> <BB1534CC-76ED-482E-BA9B-D11E8B52C7AE@gmail.com>
Date: Thu, 16 Apr 2015 08:33:09 -0700
Message-ID: <CACsn0cmJBk0BVbktwyf0Qkyd0P8YOwfKz22kUAQmQcKT6W8hUQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-SA-Exim-Connect-IP: 2a00:1450:400c:c05::22e
X-SA-Exim-Rcpt-To: draft-ietf-tls-session-hash.all@tools.ietf.org
X-SA-Exim-Mail-From: watsonbladd@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: <20150416153327.355491A8AB7@ietfa.amsl.com>
Resent-Date: Thu, 16 Apr 2015 08:33:27 -0700 (PDT)
Resent-From: watsonbladd@gmail.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/draft-ietf-tls-session-hash.all@tools/W00hjX8IgRFsctwVrCabxvaISAM>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/hVWyurUYShawLiPmzSX8cYlNT1w>
X-Mailman-Approved-At: Thu, 16 Apr 2015 08:36:08 -0700
Cc: "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-tls-session-hash.all@tools.ietf.org, Radia Perlman <radiaperlman@gmail.com>, The IESG <iesg@ietf.org>
Subject: Re: [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 15:34:20 -0000

On Thu, Apr 16, 2015 at 12:06 AM, Karthikeyan Bhargavan
<karthik.bhargavan@gmail.com> wrote:
> Hi Radia,
>
> Thanks for the comments. I made many of the smaller changes, and have some
> questions about the interop concerns.
>
>> 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.”
>
> The style we chose was to say that the client/server SHOULD abort the handshake,
> but we also say in paragraph 7:
>
> "If the client or server choose to continue a full handshake without the extension, they use the legacy master secret derivation for the new session. In this case, the considerations in section 5.4 apply.”
>
> That is, we do offer them the choice of opting out of this draft for interoperability, by following
> the recommendations in 5.4.
>
> We could make this forward pointer more explicit by saying instead:
>
> “In order to interoperate with legacy peers, some lients and servers may choose to
>  to continue a full handshake without the extension. In this case, they use
>  the  legacy master secret derivation for the new session, and the
>  considerations in section 5.4 apply.”
>
> Would this assuage the security/interoperability concern?
>
>
>> 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.

I seem to recall a discussion about this, where my minority position
was that breaking renegotiation instead was more acceptable. We need
to break one, and renegotiation is not used nearly as commonly for
browsers.

>
> During resumption we use similar language to point forward to section 5.2
> if the client or server chooses to continue without the extension.
>
>> 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.
>
> This case seems most difficult, because section 5.4 is the defense of
> last resort. Weakening the MUST requirements here would, in our mind,
> be tantamount to disabling the extension altogether.

Web browsers have adopted a more minimal solution, namely not
permitting renegotiation to change certificates. I doubt that the
stricter defense in 5.4 will cause interoperability issues, and it may
have been adopted by some of them. Input from browser writers would be
greatly appreciated.

Sincerely,
Watson Ladd

>
> Recall that in  the triple handshake attack, the man-in-the-middle is a valid peer
> who is trying to fool both the client and the server. Hence, we cannot
> rely on this man-in-the-middle sending the extension. If we allow
> handshakes without the extension, the attack cannot be prevented, only mitigated.
> The MUSTs in this section try to enforce these mitigations.
>
> Best regards,
> Karthik
>
>
>>
>> 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,
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



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