Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3)

Eric Rescorla <ekr@rtfm.com> Fri, 28 March 2014 14:10 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EC01A0684 for <tls@ietfa.amsl.com>; Fri, 28 Mar 2014 07:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 XBQgShJrehoe for <tls@ietfa.amsl.com>; Fri, 28 Mar 2014 07:10:40 -0700 (PDT)
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5091A065A for <tls@ietf.org>; Fri, 28 Mar 2014 07:10:40 -0700 (PDT)
Received: by mail-wi0-f176.google.com with SMTP id r20so794388wiv.3 for <tls@ietf.org>; Fri, 28 Mar 2014 07:10:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8RW7/yY3IfUe42csHJG51AvU1V+lhuSO2fT1hyfdbAc=; b=XBQEbQu5nfZ7hgdw7W2mm7RfXTgG646R6yaLXHSlRdmkzeaIPYCB6bwW/d9vmDlaj3 tifsNZorDjMP/xvBd6OOVrsGY0zCskHlni1X8yHuqcxUpbJds2si1wANTod4YxKA25zD hX4l7trw0aqOnRpTFmdFX+cvKGvytxm++vDj/UlV/8r9zNfzwYqUxdM3cd5c8EHl9TPJ AGvdVvJI4GrS71Waq/SaiJFeiWGAtacZpB44zkSAmesLK7Mr6ZLgR34s9WWG1Ifh93bl aPrEqI9NqGe2ocuiTElyp3oVWL2ZPbGc7MDJgJDyROvIDm4qB8Ubeg/cQmQ/qRGr4weA dvmA==
X-Gm-Message-State: ALoCoQlTB07Kd2nkHe2kOi4hmF9aP6ft+qJ/VycABHFocPn4AfgHr9wU0rb6vHC+yT6a+3JooeV5
X-Received: by 10.180.81.228 with SMTP id d4mr21475385wiy.49.1396015837673; Fri, 28 Mar 2014 07:10:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.218.198 with HTTP; Fri, 28 Mar 2014 07:09:57 -0700 (PDT)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <C3A58B39-69DE-4AF9-99F5-41169886F87A@gmail.com>
References: <CABkgnnX=KM4YVf1+znp_HS+Pu6DSw64q1adDC4EOPqRLuTDZKQ@mail.gmail.com> <CACsn0cksap5t0--65gnJt5a2yJCNtzvkDX9mmQR=T_r2xYJjYQ@mail.gmail.com> <5334C8A8.2020906@streamsec.se> <C3A58B39-69DE-4AF9-99F5-41169886F87A@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 28 Mar 2014 07:09:57 -0700
Message-ID: <CABcZeBMB9mcDkYua_GHvwm5tWt7UNDAmMycJCJUGzd2kqq5qYg@mail.gmail.com>
To: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
Content-Type: multipart/alternative; boundary=f46d043bdb0e1b1f3f04f5ab4476
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RrX8jliSCGjb0awFeUB4ilK1W_c
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Nuking DHE in favour of ECDHE (Was: Re: Confirming Consensus on removing RSA key Transport from TLS 1.3)
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: Fri, 28 Mar 2014 14:10:44 -0000

On Thu, Mar 27, 2014 at 11:38 PM, Karthikeyan Bhargavan <
karthik.bhargavan@gmail.com> wrote:

>
> Well, the DHE handshake has validation issues: implementations aren't
>
> checking they get sensible inputs.
>
> Fix that, and maybe you have an argument for keeping it. But as it
>
> stands now the insecure resumption attacks are exploiting behavior in
> DHE that isn't fixable without a DOS vector being introduced.
>
>
> In regard to DHE validation, one answer (already proposed on this thread)
> is to use well-known named groups, instead of arbitrary groups. So, rather
> than banning DHE, we could standardise named groups (like named curves) and
> ban the use of arbitrary groups (and arbitrary explicit curves).
>

Note that we could do this for TLS 1.x not just for TLS 1.3, though
obviously we couldn't *require* standardized groups for older
versions for compatibility reasons.

WRT group validation being a DoS vector (a point made by Watson),
the effect of the DoS seems somewhat limited by the fact that it's the
server who selects the group and therefore the client who has to validate
it, so you can't push arbitrary computational load onto some server just by
connecting
to them and forcing it to validate parameters (though of course you can
already do so to some extent by forcing them to do signatures, key
exchanges, etc.)

This isn't to say that DoS of clients isn't a potentially big deal but at
least in the Web context any network attacker can force arbitrary amounts
of computation onto the client just by pushing JS into any HTTP connection
[0]. Outside the Web context, there probably are cases where this would be a
more viable attack, though depending on the cost of validation they
might require the client to also be willing to do a lot of reconnects
automatically in order to be really affected.

-Ekr

[0] And of course in Karthik's attack, the assumption is that the client
would connect to the attack server in any case and so even in an
all HTTPS world, the attacker could shove down arbitrary JS from
his own site.


Still, public key validation remains important for both ECDHE and DHE, and
> essential to prevent insecure resumption-like attacks.
>
> 1. At the end of the first handshake, the finished messages of the
> connections C/A and A/S will be different.
> 2. The outline of the attack rests on the assumption that A might simply
> forward the messages during the second handshake, because all parameters
> are the same, and here the finished messages for C/A and A/S will
> consequently also be the same. Well, they will be if no renegotiation
> indication extension is included. If it is, this will however be different
> for C/A and A/S, and hence result in different finished messages after the
> second handshake as well.
>
>
> Yes, which is why the attack requires 3 handshakes not two. By injecting a
> resumption handshake between 1. and 2. above, the finished messages of C/A
> and A/S can be made the same. I'd be happy to discuss off-list.
>
> Best,
> Karthik
>
>
>
> Am I missing something obvious?
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>