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

[Wang Haiguang <[e-mail]>]

Hi, Eric

Thanks very much for the comments.

For the first point, to some extent, we partly agree with you but let me clarify as follows:

For some IBS algorithms such as RFC 6507 (ECCSI), there are two different interpretations on the public keys. The first is that ID is a public key, and PVT as part of the signatures. This is exactly that RFC 6507 has specified. The second is what you stated in the previous email, the public key is derived from both ID and PVT.

For Bilinear pairing based IBS algorithms, ID is absolutely public key.

For second point, IBS algorithms cab be seen as something in between pure raw public and PKI. So it is normal that we both have different interpretation on this point.

So it is acceptable that IBS algorithms can be treated as raw public. It simplifies the management of raw public key and identity binding as long as PKG parameters are provisioned to both peer and server.

Regards.

Haiguang


________________________________
From: Eric Rescorla [[e-mail]]
Sent: Sunday, 24 March, 2019 1:02:05 AM
To: Wang Haiguang
Cc: [e-mail]
Subject: Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10



On Sat, Mar 23, 2019 at 8:57 AM Wang Haiguang <[e-mail]<mailto:[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]<mailto:[e-mail]>]
Sent: Saturday, 23 March, 2019 7:30:50 PM
To: Wang Haiguang
Cc: [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>]
Sent: Saturday, 23 March, 2019 1:13:03 AM
To: Wang Haiguang
Cc: [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>]
Sent: Thursday, 21 March, 2019 9:46:07 PM
To: Wang Haiguang
Cc: [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tls