Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt

Yoav Nir <ynir.ietf@gmail.com> Thu, 24 July 2014 18:01 UTC

Return-Path: <ynir.ietf@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 A61F71A03C4 for <tls@ietfa.amsl.com>; Thu, 24 Jul 2014 11:01:00 -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 H2Q_nIxlsQij for <tls@ietfa.amsl.com>; Thu, 24 Jul 2014 11:00:58 -0700 (PDT)
Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90DD1A019C for <tls@ietf.org>; Thu, 24 Jul 2014 11:00:57 -0700 (PDT)
Received: by mail-we0-f181.google.com with SMTP id k48so3171678wev.40 for <tls@ietf.org>; Thu, 24 Jul 2014 11:00:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vz/ldi/56oD/eUG1989xzoWMR5ZXoW078TYB++Fkx1A=; b=bLn0QKBVkhQfYCiPHoHC+Az/7ALeuMyLK0SV7TA+VgS0B6oKkKl1d0j3TIjSQzB6aR 7cIcWouWc1Q+G09NfSuJ36dMZ4YyPWb6skVtyICrwVz8y+a+lbBNoetQF9PD6oy3ygn4 XVc9YnxwcNjbsGkH9ChYdlVckKLFEQA88kv5thWKgKGQXmojcPVfJu/JG1Q8fF5dN/rU 7z4n8ABkEvwsYdbSu8NVLyzTsZGbAcvLwo1h9zFqFicXkdSZ18jNUfp/WNIS44ncpGcg zESp0YFcSWMC0cJ1wR3pmN5eMTR06PG7aECvHw2P/XTYUrNdco43RYd6+mhA4ppzC955 JYzQ==
X-Received: by 10.180.218.12 with SMTP id pc12mr37697403wic.15.1406224856255; Thu, 24 Jul 2014 11:00:56 -0700 (PDT)
Received: from wireless-v6.meeting.ietf.org ([2001:67c:370:160:98a4:b998:3a17:1e6f]) by mx.google.com with ESMTPSA id h13sm17810579wjs.2.2014.07.24.11.00.55 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 11:00:55 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738EFB003E@uxcn10-5.UoA.auckland.ac.nz>
Date: Thu, 24 Jul 2014 14:00:51 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <E293BCD4-46DB-4F5D-94EE-0ABA752949ED@gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C738EFB003E@uxcn10-5.UoA.auckland.ac.nz>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/x3Z48v6VsCjaKFESBYFgh72y5so
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt
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, 24 Jul 2014 18:01:00 -0000

On Jul 24, 2014, at 10:53 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:

> <internet-drafts@ietf.org> writes:
> 
>>  Traditional finite-field-based Diffie-Hellman (DH) key exchange
>>  during the TLS handshake suffers from a number of security,
>>  interoperability, and efficiency shortcomings.  These shortcomings
>>  arise from lack of clarity about which DH group parameters TLS
>>  servers should offer and clients should accept.  This document offers
>>  a solution to these shortcomings for compatible peers by establishing
>>  a registry of DH parameters with known structure and a mechanism for
>>  peers to indicate support for these groups.
> 
> Some comments:
> 
> - Why not just use the well-known and -accepted IKE groups from RFC 3526 for
> this?  In fact why invent entirely new groups (that don't even cover the
> existing range in RFC 3526) when there's already well-established ones
> available?

That’s been asked at the meeting. No particular answer.

> - What's the thinking behind a 2432-bit group?  2048-bit I could understand,
> 2560 bits perhaps, but 2432?

I asked that at the meeting. The answer is that this number supposedly exactly matches the 112-bit level of security. 

> - Publishing the values of q (rather than just telling people how to calculate
> them) would be good, since it'd provide known-correct values for them.
> 
> In general though, we don't need yet another set of parameters, all that's
> needed is a mechanism for specifying the existing RFC 3526 groups.

And that’s assuming we even want FFC parameters (as opposed to ECC).

Yoav