On Sat, Mar 23, 2019 at 3:08 AM Wang Haiguang < wang.haiguang.shield...@huawei.com> wrote:
> 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? > I don't understand this question. -Ekr > 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> 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] >> *Sent:* Thursday, 21 March, 2019 9:46:07 PM >> *To:* Wang Haiguang >> *Cc:* 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> 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 >>> https://www.ietf.org/mailman/listinfo/tls >>> >>
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
