Re: [TLS] Another IRINA bug in TLS

Tom Ritter <tom@ritter.vg> Wed, 20 May 2015 14:49 UTC

Return-Path: <tom@ritter.vg>
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 75BF81A87BE for <tls@ietfa.amsl.com>; Wed, 20 May 2015 07:49:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] 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 L7ZxtGttnBVJ for <tls@ietfa.amsl.com>; Wed, 20 May 2015 07:49:06 -0700 (PDT)
Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (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 0FFAF1A87B0 for <tls@ietf.org>; Wed, 20 May 2015 07:49:06 -0700 (PDT)
Received: by wgbgq6 with SMTP id gq6so55599916wgb.3 for <tls@ietf.org>; Wed, 20 May 2015 07:49:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Hx0SDxdrM8cBAdwe/tm17IJmINt6E3juLKO5Bn+nq4U=; b=tbEcD84z2OYRANe0IF+cJhlQUGLzZ1hzWcKbI58ZinHsBcooUYnRWhx4OuIFidYRy7 bWjwaYr/kOK3xfv8yDNP5njFtupaBd1l2eGwTuKmqe6GyWFgkCZSLqfhMJ2WQiCyHYYP 8myMRHWpeoia1SsLrnmReQQ4LLv4iuQwR+zqI=
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=Hx0SDxdrM8cBAdwe/tm17IJmINt6E3juLKO5Bn+nq4U=; b=kimOB7UlF0q6TPaJ42c9Z0wUZeiCEZCbojYTULtTXeHCiULidgWYgFCVNKQ6I2KB70 /hjiM9xNDGLTORPBWUQtd5V388MVu9wHyT0O98L1I1RuDZyJB2ruxEaQxidz1MumWgFa 1Bb8Q935LnN8QfzJuhNv2kD/EfeLXsRKAnzKa4EtMXiBX3R3EWQjfGmfvPp8DbxwCYWU M0/TqXwKyfk8dX2o5rCd+dgHFpK66bsVmMYaw7Y3lYMvjj7CvGj9WriU5yVcx0ng4uOJ L3irX/ioNO3lA7kZtScNt2FlWOxWo5nackST9yrusdiO0kFsAeazPgZ1ctUuP+e/ADuN fNLQ==
X-Gm-Message-State: ALoCoQnFoQveJ+WvkQGh07te6F7NzcC9Yp7Wy+1nsf7KeIcthTkOL8R9sWfVGgBA9zpFqRU2jyIo
X-Received: by 10.194.122.200 with SMTP id lu8mr64390222wjb.30.1432133344756; Wed, 20 May 2015 07:49:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.141.80 with HTTP; Wed, 20 May 2015 07:48:44 -0700 (PDT)
In-Reply-To: <CACsn0ckaML0M_Foq9FXs5LA2dRb1jz+JDX7DUej_ZbuSkUB=tQ@mail.gmail.com>
References: <CACsn0ckaML0M_Foq9FXs5LA2dRb1jz+JDX7DUej_ZbuSkUB=tQ@mail.gmail.com>
From: Tom Ritter <tom@ritter.vg>
Date: Wed, 20 May 2015 09:48:44 -0500
Message-ID: <CA+cU71kQrDee921==xz0Cqw-j79D5+V+FMwXqP4uw7AaBQoRMw@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ydGETWxHxwGCaJgeVSVn-Oue3K0>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Another IRINA bug in TLS
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: Wed, 20 May 2015 14:49:07 -0000

On 20 May 2015 at 09:05, Watson Ladd <watsonbladd@gmail.com>; wrote:
> https://weakdh.org/
>
> Transcript hashing will solve this problem.

Will it?  (Or at least, I'm not sure where you intend to include the
transcript hash, in which case - maybe.)

I think the issue is the same as the Section 4.4 here:
https://www.schneier.com/paper-ssl-revised.pdf - the underlying cause
being that the ephemeral parameters' signature doesn't include enough
context.   In Schneier's, the algorithm needed to be included (it
still isn't, in TLS 1.2 - we just (hope) we have stricter checking on
the data in implementations).

In this one, the signature could be argued to be needed to go over the
ciphersuite (to say "Don't use these parameters except with this
ciphersuite"), maybe more data (to say "Only uses these parameters if
you've sent me this transcript"), or even arguably no change at all:
don't sign things you don't intend to use.  (Not that that last one is
good IMO.)

If you mean hash the transcript into the master secret (e.g. the
extended master secret draft) - I don't think that's a fix.  The
client will hash all of its handshake messages into its master secret
- but the client is talking to _me_ the attacker.  I copy-and-paste
the server's ephemeral parameters, and the signature, but I can derive
the same MS as the client and happily talk to the client, decrypting
and passing the data back along to the server who I'm talking to in a
different connection.

-tom