Re: [TLS] A new draft for "Using Identity as Raw Public Key in Transport Layer Security (TLS)" has been updated

[Ilari Liusvaara <[e-mail]>]

On Wed, Dec 26, 2018 at 09:00:08AM +0000, Wang Haiguang wrote:
> Hello, everyone
> 
> We have just updated the internet draft for "Using Identity as Raw Public Key in Transport Layer Security (TLS)". 
> 
> In this draft, we propose to use the Identity as raw public key, which further simplifies authentication and identity management of large scale IoT devices. 
> 
> The updating are mainly in the IANA consideration part. 
> 
> We have some IANA related issues that need expert from this group to help:
> 1) TLS protocol require OID to identify an signature algorithm used in authentication and key exchange. 
>      However, the identity-based signature algorithm (ECCSI) specified by IETF in RFC 6507 does not have an OID yet. 
>      We have written to IANA for consideration but do not get it yet. 

Also, Huawei seems to have an OID arc...

> 2) TLS cipher suites and a  few TLS registries need to be updated also, by adding in the relative names for ECCSI: 
>      * TLS  cipher suites

This registry seems to be specification required.

>      * TLS TLS KeyExchangeAlgorithm Registry

>From what I can tell, there is no such registry. The key exchange
algorithms seem to be specified in the RFCs themselves.

>      * TLS ClientCertificateType Registry

Specification required range exists.

>      * TLS SignatureAlgorithm Registry

Note that SignatureAlgorithm registry has all entries reserved, it
does not have unassigned codepoints. Instead, request SignatureScheme
assignment, and specify if it is valid for TLS 1.2 or not. From
the above registry requests, I would guess it is meant to be valid in
TLS 1.2.

> Although the draft is still personal draft , some telecom customer
> want to use TLS+ECCSI in their network for IoT  device authentication.
> Therefore, is it possible for IANA to assign value for above TLS
> registries and OID for ECCSI since ECCSI is specified by IETF?
> 
> Please give us some suggestion on the OID and TLS registries updating issues.
>
> Below is the link to our recently uploaded draft. 
> https://www.ietf.org/internet-drafts/draft-wang-tls-raw-public-key-with-ibc-03.txt
>

Some other comments:

- Why is this seemi~ngly only specified for TLS 1.2? I am not seeing any
  obstacles to porting this to TLS 1.3 in fairly straightforward
  manner. The only problematic aspects I see are:
  - Using SignatureAlgorithm, but I do not think that would work in
    TLS 1.2 either (use SignatureScheme instead).
  - The weird preference signaling for client signature via
    ciphersuite.
  For TLS 1.3, new ciphersuites, key exchange algorithms and client
  certificate types would be unnecressary (the last two do not even
  exist in TLS 1.3, with first the standard algorithms should work).
- Section 2 references RFC 2119 and not RFC 8174 (I have seen complaints
  about this).
- Section 2 seems to be missing "NOT RECOMMENDED" (or if the list is
  supposed to be minimal, "RECOMMENDED" does not seem to be used
  anywhere (this is actually an errata on RFC 2119).
- Section 3 has "SubjectECCSIPublicKeyInfo" in figure 1 title. I
  suppose that should be "subjectPublicKeyInfo"?
- Section 3 has mechanism to fetch the parameters from URL. Those
  parameters should be strongly checksummed (e.g., SHA-256). Also, the
  risks of fetching information from URL as part of handshake (probing,
  pointing at some large file, etc...) should be considered.
- Section 4 references RFC 4492. Use RFC 8422 instead.
- Section 4 defines AES-CBC cihpersuites. No new ciphersuites using
  AES-CBC are to be defined. Use AES-GCM and/or Chacha20-Poly1305
  instead. The usual hash algorithms are SHA-384 for AES-256-GCM and
  SHA-256 for AES-128-GCM and Chacha20-Poly1305.
- Section 5 has "ANSI.1 structure for CertificateRequest" I presume
  that should be "TLS 1.2 structure for CertificateRequest". 
- Section 5: Since eccsi_sign in ClientCertificateType is actual
  codepoint, but no value is known, it presumably should be
  "eccsi_sign(TBD1)".
- Section 5: I do not think SignatureAlgorithm can be obtained.
  One should use SignatureScheme instead. And if it is indeed
  fixed to SHA-256, it should be specified as "eccsi_sha256(TBD2)"
  or something like that. And then specify TLS 1.2 to use whatever
  HashAlgorithm and SignatureAlgorithm that SignatureScheme gets read
  as).
- Section 6 has example url of "pkgx.org/1.html". I presume that
  should be something like "http://pkgx.example/1.pkg" or thereabouts.
- Section 6.2: Negotiatating client preference for signature types
  using ciphersuites looks very odd. If server used X.509, but 
  supported both ECDSA and ECSSI for client, it would pick ECDSA
  ciphersuite and include both ECDSA and ECSSI in CertificateRequest,
  and then the client would pick. Alternatively the server could
  include only ECSSI in CertificateRequest if it demanded ECSSI from
  the client (the ciphersuite could still be ECDSA one).
- Section 8 has obsolete registration policy information. None of
  the registeries are "standards action" anymore, all the existing
  ones are "specification required". One should also duplicate all
  requested codepoints in this section.


-Ilari