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

Wang Haiguang <> Wed, 05 July 2017 08:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5EB19131B06 for <>; Wed, 5 Jul 2017 01:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p2ThTCAjkOjO for <>; Wed, 5 Jul 2017 01:18:32 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8D737131826 for <>; Wed, 5 Jul 2017 01:18:31 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id DJT85766; Wed, 05 Jul 2017 08:18:29 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 5 Jul 2017 09:18:27 +0100
Received: from ([]) by ([]) with mapi id 14.03.0301.000; Wed, 5 Jul 2017 16:18:24 +0800
From: Wang Haiguang <>
To: "" <>
Thread-Topic: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507)
Thread-Index: AQHS9KIjbGMCVggeCEW+lkbi2Qxg8qJDAA4AgAHj4KA=
Date: Wed, 5 Jul 2017 08:18:23 +0000
Message-ID: <>
References: <> <> <20170704112144.gzfenmkmvmwry4tg@LK-Perkele-VII>
In-Reply-To: <20170704112144.gzfenmkmvmwry4tg@LK-Perkele-VII>
Accept-Language: en-SG, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.595CA0D5.00D0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 41fd2983f8fc3b7cf0364e5067d75698
Archived-At: <>
Subject: Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507)
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Jul 2017 08:18:33 -0000

Dear Ilari

Thanks very much for the feedback. 

We are now working on the comments you provided in the earlier email and will update our proposal accordingly. 

We will reply to your comments as soon as possible. 

Thanks very much.

Best regards.


-----Original Message-----
From: [] 
Sent: Tuesday, 4 July, 2017 7:22 PM
To: Wang Haiguang
Subject: Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507)

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.