Re: [TLS] Results of interim meeting

Andy Lutomirski <luto@amacapital.net> Mon, 26 May 2014 19:40 UTC

Return-Path: <luto@amacapital.net>
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 62DD91A0246 for <tls@ietfa.amsl.com>; Mon, 26 May 2014 12:40:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 q3bW9YXklFET for <tls@ietfa.amsl.com>; Mon, 26 May 2014 12:40:10 -0700 (PDT)
Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F35E1A023D for <tls@ietf.org>; Mon, 26 May 2014 12:40:10 -0700 (PDT)
Received: by mail-pb0-f54.google.com with SMTP id jt11so8095375pbb.13 for <tls@ietf.org>; Mon, 26 May 2014 12:40:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vxEdCFKCdPoq2JRfAJjHCzbRImpxXOm+UVg3ooKokkw=; b=H9GtKi38alg6XWiZ8gOC/HVNFLEo2Di5+j+E8AlwY+OLM2yqdu5V4RMSp4fesQRO/W aSal6UdTPxNv9wqqaA1Rb2JoPbxK5Js0msS/vFqjJYilj4Alc3JZO5XlJlcuZOdZkTrA /W2bDXYefuzdrJhhM0fbVVaAJYG9cZ43dxAGtusNJ7DuRL+8dOXO8QgpQ2QpA67NeFku kE94TCjMIc1mi7OgCOBweRddlJbTdYkM4K5lnZQxZHevQNtM80dsJjS2Mk7P1qWVjWJb VYm8n31ob+wl9ecUgUHX6b3A4Cq3Nu33DPipM7UYXLzYsYpOUka3WWOwVo5BQXBE/lZ+ EcVg==
X-Gm-Message-State: ALoCoQlmq5Zhwo3GVV9Wd3A8vRuDROskHF+fTypWO9A42hVSKVWBROoKbnyWCLfT2q+mmXcYNs4G
X-Received: by 10.68.223.202 with SMTP id qw10mr6945335pbc.163.1401133207370; Mon, 26 May 2014 12:40:07 -0700 (PDT)
Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id iq10sm19589052pbc.14.2014.05.26.12.40.06 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 May 2014 12:40:06 -0700 (PDT)
From: Andy Lutomirski <luto@amacapital.net>
X-Google-Original-From: Andy Lutomirski <luto@mit.edu>
Message-ID: <53839895.5000508@mit.edu>
Date: Mon, 26 May 2014 12:40:05 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Watson Ladd <watsonbladd@gmail.com>, "tls@ietf.org" <tls@ietf.org>
References: <CACsn0cmHwo6E2tGZu64q0RxTdzvxGgh8Jonzj4rr1zZxehswLg@mail.gmail.com>
In-Reply-To: <CACsn0cmHwo6E2tGZu64q0RxTdzvxGgh8Jonzj4rr1zZxehswLg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/i1_XakbIFPauG3ooMVVxKyn7TG0
Subject: Re: [TLS] Results of interim meeting
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: Mon, 26 May 2014 19:40:11 -0000

On 05/26/2014 09:34 AM, Watson Ladd wrote:
> Dear all,
> 
> It looks like most of the slides were devoted to SNI, and it is not
> clear what was actually decided.
> 
> I haven't seen any slides about Triple Handshake, despite being on the
> interim agenda. Is this a sign that the proposed fix for TLS 1.2 is
> acceptable?

There was a concern that the proposed fix might allow the client to
construct two different ClientHellos that would nonetheless result in
the same tls-unique value using the pre-TLS-1.2 PRFs.  The issue is
that, if you could find a SHA-1 collision, then MD5 is short enough that
it could be possible to do a length-extension attack and brute-force it
to be an MD5 collision as well.

No one present knew whether this mattered.

--Andy