Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507)

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 04 July 2017 11:21 UTC

Return-Path: <ilariliusvaara@welho.com>
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 94503131F06 for <tls@ietfa.amsl.com>; Tue, 4 Jul 2017 04:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 qCV8cuDZK0z0 for <tls@ietfa.amsl.com>; Tue, 4 Jul 2017 04:21:49 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id F0942131DEE for <tls@ietf.org>; Tue, 4 Jul 2017 04:21:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 18EDB33876; Tue, 4 Jul 2017 14:21:47 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 8VqLrp6QCfWX; Tue, 4 Jul 2017 14:21:46 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id BABD8C4; Tue, 4 Jul 2017 14:21:44 +0300 (EEST)
Date: Tue, 4 Jul 2017 14:21:44 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Wang Haiguang <Wang.Haiguang1@huawei.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Message-ID: <20170704112144.gzfenmkmvmwry4tg@LK-Perkele-VII>
References: <149907920017.607.217202033021863337.idtracker@ietfa.amsl.com> <0AE05CBFB1A6A0468C8581DAE58A31309DF69D8C@SINEML521-MBX.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <0AE05CBFB1A6A0468C8581DAE58A31309DF69D8C@SINEML521-MBX.china.huawei.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/E5k3nz76EOBB3feqguQ2-Hdb-lY>
Subject: Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 04 Jul 2017 11:21:51 -0000

On Tue, Jul 04, 2017 at 08:47:16AM +0000, Wang Haiguang wrote:
> Dear all,
> 
> This Haiguang Wang from Huawei Technology. 
> 
> I have submitted an IETF draft on using ECCSI public key for
> authentication over TLS protocols. It is the first version, so the
> draft still have a lot of spaces to improve. 

Some feedback:

- I see the certificate message has single opaque field. This is the
  same as RPK, but isn't trivially mappable to TLS 1.3. See TLS 1.3
  draft section 4.4.2 on how TLS 1.3 handles RPK.

- I think you shouldn't duplicate existing arms in TLS structures.
  See RFC 4279, section 4 for one example on omitting such arms.

- I think you shouldn't duplicate definitions of ClientCertificateType
  and ServerCertificateType. Leave that to RFC 7250 and TLS 1.3 RFC.
  You just need the certificate type value.

- I think you shouldn't define a new key exchange algorithm, but
  use ECDHE_ECDSA instead (like EdDSA does). Then get a new TLS 1.3
  signatureScheme value, which decomposes to the corresponding TLS
  1.2 values (see RFC4492bis for an example). However, this requires
  TLS 1.2 or newer, but that should not be a problem.

- The proposed ciphersuites are really bad. No new blockmode or stream-
  mode ciphers should be defined (especially blockmode, those are almost
  impossible to implement in secure way). If ECDHE_ECDSA is used, one
  avoids allocating any new ciphersuites.

- Security considerations missing.

- IANA considerations missing, should ask for allocation of all
  new codepoints (and that one OID).

- References section is duplicated.



-Ilari