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

Fedor Brunner <fedor.brunner@azet.sk> Tue, 29 July 2014 14:09 UTC

Return-Path: <fedor.brunner@azet.sk>
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 EE1241A02F3 for <tls@ietfa.amsl.com>; Tue, 29 Jul 2014 07:09:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.096
X-Spam-Level:
X-Spam-Status: No, score=-0.096 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, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 9Eo1zCZADz8j for <tls@ietfa.amsl.com>; Tue, 29 Jul 2014 07:09:20 -0700 (PDT)
Received: from smtp-01-out.s.azet.sk (smtp-07-out.s.azet.sk [91.235.53.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5EE1B2889 for <tls@ietf.org>; Tue, 29 Jul 2014 07:08:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=azet.sk; s=azet; t=1406642931; bh=XCcAvq3jcRr68jN4gLjCxetCQYlsOoFmRcXX/awPDoM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=LIx6XlFfX6eTWi95hfDWOxG0bDkmmuEku+wI0ZiDgibesBBLEitH+BAXIBO4etbRx x8CuRzSp5G8Ntg8FB7YHQdxk/TIJWLVtLVFzHbu6jKH+hF2X2cpu+DILfBvnWU73Hg mzF7FZZj1DBJqf6H7RlIM9lDdYtNbPkABi6wtCO8=
X-Virus-Scanned: by AntiSpam at azet.sk
X-SenderID: Sendmail Sender-ID Filter v1.0.0 smtp.azet.sk CC6F08B
Authentication-Results: smtp.azet.sk; sender-id=fail (NotPermitted) header.from=fedor.brunner@azet.sk; auth=pass (PLAIN); spf=fail (NotPermitted) smtp.mfrom=fedor.brunner@azet.sk
Message-ID: <53D7AAEB.7090309@azet.sk>
Date: Tue, 29 Jul 2014 14:08:43 +0000
From: Fedor Brunner <fedor.brunner@azet.sk>
MIME-Version: 1.0
To: tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C738EFB24A6@uxcn10-5.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738EFB24A6@uxcn10-5.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/beWKXAhguDTpgSTLL1AtGaQI8Gc
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: Tue, 29 Jul 2014 14:09:22 -0000

Peter Gutmann:
> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
> 
>> There's a possibility that a very expensive (e.g. precomputation) attack
>> exists that can be mounted against any given group.  If we reuse the same
>> group used by other mechanisms (e.g. ipsec) then the value for mounting such
>> an expensive attack goes up.
>>
>> Selecting a different group forces an attacker to choose which group to
>> attack.
> 
> Yeah, I can see that, but it's a bit of a hypothetical attack, we have no way
> to quantify the risk.  For something like "don't use the same key to encrypt
> and MAC" there's a clear, well-known threat, but for "don't use the same key
> (DH group) for IPsec and TLS" it's really just speculation.  Once you start
> down this path, where do you stop?
> 


If we assume an attack exists for fixed DH group then not fixed  DH
groups generated for each server (as is current option in TLS) would
make the attack much more expensive.

In RFC 4253 (The Secure Shell (SSH) Transport Layer Protocol) 1024-bit
MODP Group, 2048-bit MODP Group are used. But the newer RFC 4419 allows
to use arbitrary safe primes.

For example OpenSSH supplies a set of 40 DH groups for each 1023, 1535,
2047, 3071, 4095, 6143, 8191-bit primes . During key exchange one of
these groups with desired size is selected in server by random. The
OpenSSH server administrator can also generate his own set of DH
parameters, for each prime length.

OpenSSH supports also elliptic curve Diffie-Hellman key agreement using
NIST curves and Curve25519.


>> This was based on the 112-bit symmetric equivalence published by ECRYPT II.
>> The ECRYPT document is referenced in the draft.
> 
> Is there really any good reason to want to match group size to algorithm key
> sizes, and (I'm assuming for a 112-bit key) one for an obsolete (if still
> widely-used) block cipher?  I'd just pick some standard group sizes (1K, 2K,
> 3K, 4K) and go with those as general-purpose solutions rather than selecting
> oddball sizes to match some particular other algorithm.
> 
> (Where did the fashion of specifically choosing the hat to match the shoes
> come from in crypto?  AFAIK it's NSA-originated from things like the original
> DSA's hardcoding of the SHA-1 blocksize into the algorithm, and KEA and
> Skipjack key sizes.  I've never been able to understand why something like a
> particular cipher block size needs an entire range of fashion accessories to
> go with it, if an n-bit prime is good enough for a 256-bit symmetric algorithm
> then it should also be good enough for 128 bits, 192 bits, and 77 1/2 bits).
> 
>> by q i think you mean (p-1)/2 -- i'm happy to document those values
>> explicitly in the draft if you think that would be useful.
> 
> Yes, thanks.
> 
> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>