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

Wang Haiguang <> Tue, 11 July 2017 03:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 779CB12EC06 for <>; Mon, 10 Jul 2017 20:53:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 2_kL9EYx9Vfb for <>; Mon, 10 Jul 2017 20:53:13 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C262A129AAD for <>; Mon, 10 Jul 2017 20:53:12 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id DQW02852; Tue, 11 Jul 2017 03:53:10 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 11 Jul 2017 04:53:09 +0100
Received: from ([]) by ([]) with mapi id 14.03.0301.000; Tue, 11 Jul 2017 11:53:02 +0800
From: Wang Haiguang <>
Thread-Topic: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507)
Date: Tue, 11 Jul 2017 03:53:02 +0000
Message-ID: <>
References: <> <> <20170704112144.gzfenmkmvmwry4tg@LK-Perkele-VII> <> <> <20170707161525.ayv4z4olmo4r3h73@LK-Perkele-VII> <>, <>
In-Reply-To: <>
Accept-Language: en-SG, en-US
Content-Language: en-SG
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_0AE05CBFB1A6A0468C8581DAE58A31309DF6BFECSINEML521MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59644BA7.003A, 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: 2b5d864eb28ec7e99dab34ca7dc08975
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: Tue, 11 Jul 2017 03:53:15 -0000

Dear all

Thanks very much for the discussion over the thread. We have learnt a lot from the discussion.

Due to the oversea travel, we were not able to send back our reply the comments from Ilari. Only yesterday, we got some time to prepare the reply. So in the below, we addressed the issue raised by Ilari and highlighted the answer in yellow collor.

We will continue our effort to improve the draft and will submit an updated draft once we finished.



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.

[Answer]: In fact, here we want to define a simple structure, and please see the definition of subjectIdentityBasedPublicKeyInfo. Thanks a lot for pointing to us TLS 1.3 for reference.

- 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.

[Answer]: Thanks a lot for raising these issues and pointing out relevant references. We will rectify them in our subsequent versions.

- 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.

[Answer]: Yes, exactly. Our intention is to use existing key exchange algorithm, but with a different signature scheme (just like EdDSA does, as you said). At the time of writing, we actually followed the TLS 1.2 convention, and later we will change to follow TLS 1.3.

- 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.

[Answer]: We specified the ciphersuites according to TLS 1.2. We now realized that the way ciphersuites are defined has been changed in TLS 1.3, and we will follow accordingly later. In fact we have no intention to introduce new ciphersuites in the sense of TLS 1.3.

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

[Answer]: We will add or rectify in the subsequent versions.

Anyway, our idea of the proposal is simple: to use a certificateless signature (RFC 6507) in TLS to avoid the certificate-based signatures, in order to avoid the hassle of certificates.

From: TLS [] on behalf of Martin Thomson []
Sent: Monday, 10 July, 2017 7:48:57 AM
To: Russ Housley
Subject: Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507)

On 8 July 2017 at 05:40, Russ Housley <>; wrote:
> The TLS WG wants to work on a a way to combine a PSK with (EC)DH after the
> current specification is finished for quantum protection.

TLS 1.3 allows this already. The drawback being that you need to get
the PSK. At the moment, this means talking to the server once before
in most cases. I thought that the PQ plan was to add a new key
exchange paired with ECDH, along the lines of what was proposed in
draft-whyte-qsh-tls13-01 (I recall someone asking CFRG for advice on
combining of the outputs, but that doesn't seem to have gone

TLS mailing list