Re: [TLS] Another IRINA bug in TLS

Watson Ladd <watsonbladd@gmail.com> Wed, 20 May 2015 16:23 UTC

Return-Path: <watsonbladd@gmail.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 3DFD71A1AA9 for <tls@ietfa.amsl.com>; Wed, 20 May 2015 09:23:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_PASS=-0.001] 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 WmKvN4x0ZWdS for <tls@ietfa.amsl.com>; Wed, 20 May 2015 09:23:44 -0700 (PDT)
Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (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 8AC601A8907 for <tls@ietf.org>; Wed, 20 May 2015 09:23:26 -0700 (PDT)
Received: by wgfl8 with SMTP id l8so58482817wgf.2 for <tls@ietf.org>; Wed, 20 May 2015 09:23:25 -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; bh=ekdjZaDtUq1fdaekqWtgysaox7MTNHySKoe0ZV29v4c=; b=RoEU4aUV9jscPH8E4JUZXK5E7UtwZDNVTt59u1GgqdrotUBTZnuxwFesF4Wr9ZoGbk Y03SVo/S4XWvQZVHJgG5e8xDsd87vS6rX0hU4m3zNl+YdrUGz6/yOnWob4Y20e0pS5Hy 6VUZSrG8DfxYbrr7KNmDDCUKyl4JG3/+gKKirWVdNf8gq8xPT9piqkoo6ctaublQOmSO c1jS5U201/mJ/eol3WmAN1YHrhyN0gLYgDDspp+mUbU9X9vm6WnFi7XBTPO5kB2gj9K1 uXj+R7eZlpZEXv286duwWFroCVe+Y/gaqwoy0VXHRYKafS5CKPZjsNi70TffAkYu56lv M6nw==
MIME-Version: 1.0
X-Received: by 10.180.187.141 with SMTP id fs13mr43428326wic.26.1432139005277; Wed, 20 May 2015 09:23:25 -0700 (PDT)
Received: by 10.194.20.97 with HTTP; Wed, 20 May 2015 09:23:25 -0700 (PDT)
In-Reply-To: <555CA61C.5090405@azet.org>
References: <CACsn0ckaML0M_Foq9FXs5LA2dRb1jz+JDX7DUej_ZbuSkUB=tQ@mail.gmail.com> <1432134170.2926.9.camel@redhat.com> <555CA61C.5090405@azet.org>
Date: Wed, 20 May 2015 12:23:25 -0400
Message-ID: <CACsn0cnspWsewguQfdZ9sV95007ZJhCi3bXtYB==pO5dHhrOGg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Aaron Zauner <azet@azet.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/2CxBOhEzRZO2SfbQeNkNL6qBIiU>
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 16:23:46 -0000

On Wed, May 20, 2015 at 11:19 AM, Aaron Zauner <azet@azet.org> wrote:
> Hi,
>
> Nikos Mavrogiannopoulos wrote:
>> On Wed, 2015-05-20 at 10:05 -0400, Watson Ladd wrote:
>>> https://weakdh.org/
>>>
>>> Transcript hashing will solve this problem. In the meantime, you want
>>> to turn off DH_EXPORT.
>>
>> The interesting thing is that there are no DHE_EXPORT ciphersuites.
>>
>
> I was also wondering about that. IANA has no entries for DHE_EXPORT*. As
> far as I can tell there isn't even information on the searchable web on
> that. If you google DHE_EXPORT it'll point you to this very paper and
> that's about it.

This is what I get for writing before coffee.

They do mean DHE_EXPORT to refer to dhe_rsa_export and dhe_dss_export,
as "defined" in RFC 2246. These are ciphersuite values.

Tom Ritter's comments are correct: synchronization isn't going to work
here, and we should either disable insecure ciphers entirely or ensure
that signatures of keys indicate the context. Clients need to do more
validation of DH parameters.

Finally, as DJB pointed out on twitter so long as insecure options
need to be removed. Not disabled, removed. That way bugs like this
one, or other negotiation bugs, cannot lead to insecure ciphers being
used.

Sincerely,
Watson Ladd

>
> Aaron
>



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