Dear Ilari, Thanks very much for the suggestion. We need some time to discuss and will reply back to the mailing list as soon as possible.
Happy new year! Haiguang -----Original Message----- From: ilariliusva...@welho.com [mailto:ilariliusva...@welho.com] Sent: Wednesday, December 26, 2018 10:51 PM To: Wang Haiguang <wang.haiguang.shield...@huawei.com> Cc: tls@ietf.org Subject: Re: [TLS] A new draft for "Using Identity as Raw Public Key in Transport Layer Security (TLS)" has been updated 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-wit > h-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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
