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

Watson Ladd <> Fri, 25 July 2014 04:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CB6AB1A0ADA for <>; Thu, 24 Jul 2014 21:33:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ffFKp99BJr19 for <>; Thu, 24 Jul 2014 21:33:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C57E91A0AD6 for <>; Thu, 24 Jul 2014 21:33:44 -0700 (PDT)
Received: by with SMTP id v1so2573403yhn.23 for <>; Thu, 24 Jul 2014 21:33:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qLLW0hhAY61zMyQbG6sgdYfRnu52eUNTn/uuwLsnL7s=; b=fUfR1GZYFVReS1SDJPAKotHwkDL5PDwruRL5Zcq2gWHYsr66pEVciI2SKE9RLxcgSA J558+mncoK639m2usKyzIgYvSWik4ey7KRyVBdJcpF4ncbZJDJd7yWIe2DEw98quviGj dLbshgCXP5h5IxYBN58jqRzqbXwo8DnnNROX0pb6JNsiQQNOC7QEthoqW3p4ZEJFIYT1 E6hLlnz4KYyYvy0l2uelX48Cqfhu4JIBVbOF45na1K6HKyqSu4Uh8VyxBlCWu9zcwZZQ xDsap66K24zI0pBVRYLqygAl7/4lqqcxx92IN663XFyXPQTD0bDhu7WaRmouIjB6ZyUW xIKQ==
MIME-Version: 1.0
X-Received: by with SMTP id a61mr19136839yhf.2.1406262824153; Thu, 24 Jul 2014 21:33:44 -0700 (PDT)
Received: by with HTTP; Thu, 24 Jul 2014 21:33:44 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Thu, 24 Jul 2014 21:33:44 -0700
Message-ID: <>
From: Watson Ladd <>
To: Peter Gutmann <>
Content-Type: text/plain; charset="UTF-8"
Cc: "<>" <>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-00.txt
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 Jul 2014 04:33:47 -0000

On Thu, Jul 24, 2014 at 9:10 PM, Peter Gutmann
<> wrote:
> Andrey Jivsov <> writes:
>>* It adds only one bit of security
>>* an implementation that shares code between IKE and TLS will need to store
>>an additional hardcoded prime.
> * The IKE values have been around since before IKE (in the form of Oakley),
> nearly twenty years.  These new values have been around since last Wednesday.
> This could mean a difference in anything from 0 to 1024, 2048, or whatever
> bits of security (0 bits if they're no better or worse, the full bitsize if
> they turn out to have some issue that the existing, well-proven ones don't).

What makes you think I sit around all day, looking at a particular
prime, dreaming of ways to break that prime, and not
others?  The analogy to symmetric cryptanalysis is wrong: there is
nothing "well-proven" about the Oakley primes.
>>Most people will not have strong preferences here, I assume.
> Well I do, the RFC 3526 values are already used in SSH (alongside IKE), and
> I've been using them in TLS as well.  I really don't want to have to implement
> a whole new set of gratuitously incompatible parameters.

I would love to know how your implementation manages to optimize
arithmetic modulo a really nasty
prime. The best strategy I can think of is Montgomery reduction, which
requires a single per-prime table,
so the logic is similar no matter what prime is used. (I don't care
much one way or the other: IKE values
would be fine).

> All we need in order to deal with this is a signalling mechanism for which set
> of parameters to use.  The RFC should provide this, and reference a standard
> set of parameters, i.e. the IKE/SSH/whatever ones.  Alongside this there could
> be a second RFC, "Additional parameters for xxx", which contains the new
> parameters, although I can't see why anyone would want them.
> (OK, there's always the "as a spare in case the existing ones fail", it's a
> pretty thin argument but I can accept it.  Just make the standard RFC 3526
> ones the default and have any new ones as a backup).

The backup is ECC. The NFS is steadily improving, and harms all primes
almost equally. Add that to the CPU consumption
that keeps people from the higher bitlengths, and the days of prime
group DH are numbered. Backups are only good if people
use them: see the trouble with turning RC4 off.

Watson Ladd

> Peter.
> _______________________________________________
> TLS mailing list

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin