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

From: Wang Haiguang <[email-masked]>
Date: Tue, 4 Jul 2017 08:47:16 +0000

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. 

ECCSI is an identity-based certificateless signature algorithm based on Elliptic Curve. It is specified in RFC 6507.  It has great potential for IOT device authentication. 

The advantages of using ECCSI signature algorithm is that, comparing to PKIX certificate, ECCSI public key is less complicate; and comparing to raw public scheme, it provides the in-band identity and public key binding. 

The propose draft has been submitted yesterday and please find the relative document from the links below. 

Please kindly let me know your comments for the draft.

Best regards

Haiguang

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, 3 July, 2017 6:53 PM
To: Wang Haiguang; Wang Haiguang; Yang Yanjiang
Subject: New Version Notification for draft-wang-tls-eccsi-00.txt

A new version of I-D, draft-wang-tls-eccsi-00.txt has been successfully submitted by Haiguang Wang and posted to the IETF repository.

Name:		draft-wang-tls-eccsi
Revision:	00
Title:		Using ECCSI Public Keys in Transport Layer Security (TLS)
Document date:	2017-07-03
Group:		Individual Submission
Pages:		11
URL:            https://www.ietf.org/internet-drafts/draft-wang-tls-eccsi-00.txt
Status:         https://datatracker.ietf.org/doc/draft-wang-tls-eccsi/
Htmlized:       https://tools.ietf.org/html/draft-wang-tls-eccsi-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-wang-tls-eccsi-00

Abstract:
   This document specifies a new certificate type and a TLS extension
   for authentication with ECCSI public keys in Transport Layer Security
   (TLS).  The new certificate type allows ECCSI public keys to be used
   for mutual authentication over TLS protocol.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 4 Jul 2017 14:21:44 +0300

On Tue, Jul 04, 2017 at 08:47:16AM +0000, Wang Haiguang wrote:
> 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

---

From: Wang Haiguang <[email-masked]>
Date: Wed, 5 Jul 2017 08:18:23 +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.

Haiguang

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

Some feedback:

-Ilari

---

From: Dave Garrett <[email-masked]>
Date: Thu, 6 Jul 2017 22:01:08 -0400

On Tuesday, July 04, 2017 07:21:44 am Ilari Liusvaara wrote:
>   However, this requires
> - The proposed ciphersuites are really bad.

Just as a clarification, all new RFCs should ideally meet all of the following criteria:
* AEAD only
* PFS only
* TLS 1.2 and 1.3 support
* no TLS 1.0 or 1.1 support (let alone SSL)
* no use of broken hashes (MD5, SHA1, etc.)

Dave

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 7 Jul 2017 15:14:10 +0000

> * no use of broken hashes (MD5, SHA1, etc.)

That's a good idea.

Want to throw together a quick draft for curdle or AD-sponsored SAAG?

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 7 Jul 2017 19:15:25 +0300

> Want to throw together a quick draft for curdle or AD-sponsored SAAG?

Well, my own view is (with explanations):

- AEAD only.

TLS streammode has all ciphers deprecated, and furthermore contains a
design mistake. TLS blockmode padding is outside MAC, which makes
implementing such modes securely very hard. This leaves just AEAD
ciphers.

- No use of broken, dubious, <128-bit keylength or <128-bit blocklength
  ciphers.

These probably won't last long until becoming attack vectors (RC4
anyone, that was dubious back in late 90s, when TLS 1.0 was done).

- PFS or pure-PSK only.

Small things can't do PFS unforunately.

- No use of l < 2^241 for key exchange.

Such key exchanges provode <120 bits of security (or thereabouts).
I used 2^241, since this is between the values used by methods claiming
to be "128-bit secure" and "112-bit secure" (or even weaker).

- Security of any key exchange method against classical attacks has to
  be well established.

No key exchanges that are dubious against non-quantum attacks. Impiles
hybrid PQC exchanges,if relevant. I have seen a dubious key exchange
method just catastrophically fail.

- Support TLS 1.3 (unless it is a security fix for earlier TLS, in that
  case it has to co-exist with TLS 1.3).

The current version of TLS in the relevant timeframe will be 1.3.

- No fallbacks for TLS 1.0 or 1.1.

Don't waste effort on TLS 1.0 or 1.1. Use any new features in TLS 1.2
(e.g., not having to define key exchange methods for signature methods)
if those make things simpler.

- No use of broken, dubious, unusual (including usage mode) or <128-bit
  secure hashes.

These probably won't last long, or will be headache to find
implementations for (e.g., try finding implementation of Skein that
supports any more exotic use of datatyping than the native MAC mode,
the reference implementation does not).

-Ilari

---

From: Russ Housley <[email-masked]>
Date: Fri, 7 Jul 2017 15:40:03 -0400

> - PFS or pure-PSK only.
> 
> Small things can't do PFS unfortunately.

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.  Of course, that PSK must be distributed without any public-key crypto or it will not provide any quantum protection.

Russ

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 7 Jul 2017 22:51:55 +0300

On Fri, Jul 07, 2017 at 03:40:03PM -0400, 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.

Well, PSK with DH does provode classical PFS.

And did you perhaps mean using PSK with DH and certificates? Because
both TLS 1.2 and TLS 1.3 can combine PSK with DH, but not all
three of PSK, DH and certificate all at once.

-Ilari

---

From: Dave Garrett <[email-masked]>
Date: Sat, 8 Jul 2017 01:26:40 -0400

On Friday, July 07, 2017 11:14:10 am Salz, Rich wrote:
> On Thursday, July 06, 2017 10:01:08 pm Dave Garrett wrote:

I was just enumerating the points that seem to have a general consensus in this WG and come up each time a new doc is discussed. I was going for FAQ, not RFC. ;)

That said, if we think there could be an actual benefit to formalizing this, probably with more detail (such as in Ilari's follow-up), that would be something I'd support.

Dave

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Jul 2017 09:48:57 +1000

On 8 July 2017 at 05:40, Russ Housley <[email-masked]> 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
anywhere).

---

From: Wang Haiguang <[email-masked]>
Date: Tue, 11 Jul 2017 03:53:02 +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.

Regards.

Haiguang

Some feedback:

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

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

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

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

[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 [[email-masked]] on behalf of Martin Thomson [[email-masked]]
Sent: Monday, 10 July, 2017 7:48:57 AM
To: Russ Housley
Cc: IETF TLS
Subject: Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507)

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls