Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10

[Eric Rescorla <[e-mail]>]

On Sat, Mar 23, 2019 at 3:08 AM Wang Haiguang <
[e-mail]> 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-mail]]
> *Sent:* Saturday, 23 March, 2019 1:13:03 AM
> *To:* Wang Haiguang
> *Cc:* [e-mail]
> *Subject:* Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10
>
>
>
> On Fri, Mar 22, 2019 at 8:28 AM Wang Haiguang <
> [e-mail]> 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-mail]]
>> *Sent:* Thursday, 21 March, 2019 9:46:07 PM
>> *To:* Wang Haiguang
>> *Cc:* [e-mail]
>> *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 <
>> [e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>