Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

"Dan Harkins" <dharkins@lounge.org> Mon, 11 July 2016 20:26 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8772412D0E8 for <tls@ietfa.amsl.com>; Mon, 11 Jul 2016 13:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 wvXrP4ws8ZvJ for <tls@ietfa.amsl.com>; Mon, 11 Jul 2016 13:26:42 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 61DD012D0E4 for <tls@ietf.org>; Mon, 11 Jul 2016 13:26:42 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 805811FE02C8; Mon, 11 Jul 2016 13:26:41 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 11 Jul 2016 13:26:42 -0700 (PDT)
Message-ID: <80bc8ae67e0ba0e2355b26bdbb34d1b6.squirrel@www.trepanning.net>
In-Reply-To: <6CE18F17-F8E0-4F4A-95A4-BE9B3A8250A2@sn3rd.com>
References: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> <7a3597ae-92b8-23c8-b2c3-357f6fdb6792@bouncycastle.org> <6CE18F17-F8E0-4F4A-95A4-BE9B3A8250A2@sn3rd.com>
Date: Mon, 11 Jul 2016 13:26:42 -0700
From: Dan Harkins <dharkins@lounge.org>
To: Sean Turner <sean@sn3rd.com>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/zYcIuGxzDogJrRBxN5NCRkrLLig>
Cc: tls@ietf.org
Subject: Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 11 Jul 2016 20:26:43 -0000

  I'm glad I have to opportunity to make you happy Sean :-)

On Mon, July 11, 2016 7:40 am, Sean Turner wrote:
> I think I can take this bit:
>
> On Jul 10, 2016, at 06:51, Peter Dettman <peter.dettman@bouncycastle.org>
> wrote:
>>
>> I'm also curious whether there is a precedent in other RFCs for an
>> explicit minimum curve bits, or perhaps a de facto implementer's rule?
>
> I'd be happy to be wrong here. but to my knowledge no there's not been
> an explicit minimum for curve bits.  There have however been similar (at
> least in my non-cryptographer mind) for RSA key sizes so if we wanted to
> define an explicit minimum curve bits then we could.

  draft-ietf-tls-pwd-07 includes a RECOMMENDED practice of ensuring
the curves used provide commensurate strength with the ciphersuite
negotiated. Section 10, "Implementation Considerations", says:

   It is RECOMMENDED that implementations take note of the strength
   estimates of particular groups and to select a ciphersuite providing
   commensurate security with its hash and encryption algorithms.  A
   ciphersuite whose encryption algorithm has a keylength less than the
   strength estimate, or whose hash algorithm has a blocksize that is
   less than twice the strength estimate SHOULD NOT be used.

  And I would like to take this opportunity to remind everyone that
the only difference between TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
and TLS_ECCPWD_WITH_AES_128_GCM_SHA256 is that the latter is resistant
to dictionary attack and the former is not.

  regards,

  Dan.