Re: [TLS] Fwd: New Version Notification for draft-ietf-tls-rfc4492bis-04.txt

Ilari Liusvaara <ilariliusvaara@welho.com> Mon, 19 October 2015 17:14 UTC

Return-Path: <ilariliusvaara@welho.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 7F9E11ACE6D for <tls@ietfa.amsl.com>; Mon, 19 Oct 2015 10:14:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 J9gPYGmXJuwm for <tls@ietfa.amsl.com>; Mon, 19 Oct 2015 10:14:45 -0700 (PDT)
Received: from filtteri2.pp.htv.fi (filtteri2.pp.htv.fi [213.243.153.185]) by ietfa.amsl.com (Postfix) with ESMTP id C79C01ACE62 for <tls@ietf.org>; Mon, 19 Oct 2015 10:14:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by filtteri2.pp.htv.fi (Postfix) with ESMTP id B206519C67D; Mon, 19 Oct 2015 20:14:43 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from smtp5.welho.com ([213.243.153.39]) by localhost (filtteri2.pp.htv.fi [213.243.153.185]) (amavisd-new, port 10024) with ESMTP id TVDv00AipxNQ; Mon, 19 Oct 2015 20:14:43 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp5.welho.com (Postfix) with ESMTPSA id 8CD845BC004; Mon, 19 Oct 2015 20:14:43 +0300 (EEST)
Date: Mon, 19 Oct 2015 20:14:42 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Message-ID: <20151019171442.GB31869@LK-Perkele-V2.elisa-laajakaista.fi>
References: <20151019155617.4544.29879.idtracker@ietfa.amsl.com> <2B0C47EF-34AE-4B75-BF83-D2E937847ED4@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2B0C47EF-34AE-4B75-BF83-D2E937847ED4@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/0NsPUAU3NoDIdX-b1d7JQoQ8X5g>
Cc: IETF TLS <tls@ietf.org>
Subject: Re: [TLS] Fwd: New Version Notification for draft-ietf-tls-rfc4492bis-04.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: <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, 19 Oct 2015 17:14:46 -0000

On Mon, Oct 19, 2015 at 06:58:52PM +0300, Yoav Nir wrote:
> Hi
> 
> I’ve submitted version -04 of this draft, incorporating the new curves Curve25519 and Curve448.
> 
> I’m sorry to say that I have made the merge far too quickly and the result is quite sketchy, but I did beat the deadline.
> 
> So I’m hoping to complete the merge soon.

Some comments:

- The document seems to lack obsoletes RFC4492 (or even updates
  RFC4492). Isn't this supposed to supercede that document?
- Curve25519 and Curve448 are called "X25519" and "X448" in the
  (looks to be imminently sent to RFC editor) draft.
- In public key validation, X448 resists invalid point attacks
  the same way as X25519 (of course, all bits of X448 public
  keys can be nonzero, as the value can get to almost 256^56).
- The document still does have restrictions on algorithms used
  to sign the certificate. AFAIK, TLS 1.2 (RFC5246) lifted all
  such restrictions (at least sections 2.2, 5.3 and 5.6).
- Do we want to keep ECDH client keys? Those were used in one
  recent exploit against one implementation of TLS. And using
  one destroys forward secrecy anyway.
- Is this document meant to also include the CFRG signatures
  work? The interfaces to functions are already known.


-Ilari