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

[Eric Rescorla <[e-mail]>]

On Sat, Mar 23, 2019 at 8:57 AM Wang Haiguang <
[e-mail]> wrote:

> Hi, Eric
>
> It is just for clarification on the concept of raw public key.
>
> In your previous email, you said that IBC is not a raw public key. But to
> my understanding, with supporting from the IBS signature algorithm, the
> identity can be used as raw public key. If you think that because we have
> transmit the PKG public parameters that makes it not a raw public key, I
> think in single PKG scenario, both client and server does not need to
> exchange parameters. That makes the identity take exactly the same role as
> raw public key.
>
> I would like to know that, in your understanding, which technical point
> makes you think that IBC is not raw public key.
>

It's not a raw public key. It's an identity which, together with
parameters, is then used as input to some function which produces a public
key. This is especially obvious when you include stuff like validity
windows.

Fundamentally, IBC is an alternate type of PKI much more than it's like a
raw public key.

-Ekr


> Thanks very much.
>
> Haiguang
>
> ------------------------------
> *From:* Eric Rescorla [[e-mail]]
> *Sent:* Saturday, 23 March, 2019 7:30:50 PM
> *To:* Wang Haiguang
> *Cc:* [e-mail]
> *Subject:* Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10
>
>
>
> 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
>>>>
>>>