Hi, Eric Thanks very much for the clarification.
Regarding the raw public key, could you please elaborate a little bit more on the actual definition on the raw public key? Regards. Haiguang ________________________________ From: Eric Rescorla [e...@rtfm.com] Sent: Saturday, 23 March, 2019 1:13:03 AM To: Wang Haiguang Cc: tls@ietf.org Subject: Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10 On Fri, Mar 22, 2019 at 8:28 AM Wang Haiguang <wang.haiguang.shield...@huawei.com<mailto:wang.haiguang.shield...@huawei.com>> wrote: Hi, Eric Thanks very much for your comments. Please see my reply inline. Our draft is still under development, we will improve it continuously based on the comments from experts in this area. ________________________________ From: Eric Rescorla [e...@rtfm.com<mailto:e...@rtfm.com>] Sent: Thursday, 21 March, 2019 9:46:07 PM To: Wang Haiguang Cc: tls@ietf.org<mailto:tls@ietf.org> Subject: Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10 I have taken an initial look at this draft [0]. Comments follow. First the motivation for this technique appears rather weak. Primarily, you argue that a PKI is complicated to implement and this is simpler. However, there are a number of factors to consider. [HG] The statement "PKI is more complicated than raw public key" is from RFC 7250 (1st paragraph in the introduction section), and the raw public key has been supported in TLS 1.3. We share a similar point of view with the authors of RFC 7250. Yes, but IBC is not raw public key. It is effectively a differently-construted PKI. Moreover, the advantage of using IBC is beyond succint key management. As analysed in [1] using of certificates has serious impact on the performance of resource contrained devices (see section 7) including RAM usage , bandwith cost, etc. Yes, but its not clear that IBC will be any better. Quote from [2] "MIKEY-SAKKE sped up the setup of HTTPS sessions by 7 times over standard TLS, meaning websites loaded over 200ms faster". What algorithms is this comparing? If it's (say) BB versus RSA, that's not really apples to apples. [1] H. Shafagh. Leveraging Public-key-based Authentication for the Internet of Things. Master thesis,https://people.inf.ethz.ch/mshafagh/master_thesis_Hossein_Shafagh_PKC_in_the_IoT.pdf";, [2] CESG. Using MIKEY-SAKKE Building secure multimedia services First, I believe the design you have selected is too simple to work outside of toy scenarios. Specifically, it doesn't seem to account for any form of revocation. How do you handle the case where someone's keys are compromised? There are a number of ways to handle this inside the context of an IBC system (time-based PKG parameters, have the identities have a timestamp built into them, etc.), but you don't specify these, and they add complexity. [HG] Regarding the revocation, we did not mention it in the draft, but we have considered it in the design. In practice, an expiring time can be included in the identity for the IBC system. In fact, in RFC 6507 page 7-8, authors have mentioned that expiration time may be included in the identity. That’s the reason we have not discussed the revocation issue in our draft. If experts in this group think we should address this issue, we can provide more information and details in the next draft. Besides, in ITU-T SG-17, we have specified a framework (x.ibc-iot) for using IBC over telecom This draft needs to provide a complete description. In a similar vein, another thing that adds complexity is having a certificate hierarchy rather than a single CA. If you are willing to have a single-level hierarchy then life is much simpler. With an IBC system, one typically either foregoes this or uses HIBC. Are these systems HIBC capable? [HG] At the moment, our target is to support a single-level IBC system. In the future, if there are needs from industry, we can add in the support of HIBC. But again, this is an additional source of complexity. If you only want a one-level CA system, you can have something much simpler than PKIX. See, for instance: https://datatracker.ietf.org/doc/draft-tschofenig-tls-cwt/ In addition, the innherent escrow capability that you describe in Section 7 is a way in which IBC systems are materially worse than PKI systems in a way we don't know how to ameliorate (as opposed to CT). [HG] For telecom operator networks, symmetric keys are used for authentication, the home operators always know the root key of a user device have in their SIM card. Therefore, the key escrow is not issue in telecom networks. Thus, whether key escrow being a severe issue depends on the application scenario. I don't think this is a demonstration that this is not severe. It's merely a demonstration that the current situation is bad. For these reasons, I don't think this WG should adopt this work, though the process allows you to have a code point without adoption. Thank you for your comments. It is better we do not make a decision at this moment. In fact, IBC sees an increasing acceptance in the industry: 3GPP has adopted the RFC 6507, RFC 6508 and RFC 6509 for mission critical communications, and UK government has already started to use it. Considering this, we would like to suggest that the group do consider our draft. You're of course free to request this, but you have not persuaded me. TECHNICAL COMMENTS I don't understand why you are sending the PKG parameters over the wire. Either the parameters are already known to the relying party, in which case they are unnecessary or they are not in which case they cannot be trusted. It seems like a hash of them would be sufficient. And of course this doesn't mesh well with multiple generations of PKG parameters (see above) unless you have signed parameters, but now you have a mini PKI. [HG] We agree with your comments, and for the single PKG case, we can use hash values. For multiple PKGs, it is reasonable to assume PKGs to trust each other, just like "root" CAs to trust each other. I don't understand what this means. First, in a PKI-based system trust anchors don't need to trust each other. It's true that in some cases a trust anchor will sign another trust anchor, but that's a delegation of trust. Are you assuming something like that here? If so, how would it work? You need to specify the format of "ServerID". Is it a domain name? Something else? [HG] ServerID is simply the identity of the server, and the format of the identity is application-specific. That is not going to promote interoperability. -Ekr -Ekr [0] Note that it's much harder to review documents in PDF. Please send text in future. On Thu, Mar 21, 2019 at 12:33 AM Wang Haiguang <wang.haiguang.shield...@huawei.com<mailto:wang.haiguang.shield...@huawei.com>> wrote: Hello, everyone. Attached is an updated version to our personal draft on draft-wang-tls-raw-public-key-with-ibc-10. The target of the draft is to use identity as raw public key over TLS. Idenitty-based signature (IBS) algorithms are used for peer/server authentication. The draft has been updated from time to time and this is the 10th version. The main change in this version is we have extended the draft to support three other IBS algorithms, i.e. the ISO-IBS1, ISO-IBS2 and ISO-Chinese-IBS. Data structures for these three algorithms are has been defined. This version has not been submitted to the IETF data trackers yet. We will submit it once it is reopen. It is appreciate if expert in this mailing list can provide comments and help us to improve the draft. Best regards. Haiguang _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
