On Fri, Mar 22, 2019 at 8:28 AM Wang Haiguang < [email protected]> 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 [[email protected]] > *Sent:* Thursday, 21 March, 2019 9:46:07 PM > *To:* Wang Haiguang > *Cc:* [email protected] > *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 < > [email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/tls >> >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
