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 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 [[email protected]] on behalf of Martin Thomson [[email protected]] 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) On 8 July 2017 at 05:40, Russ Housley <[email protected]> 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). _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
