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

From: Wang Haiguang <[email-masked]>
Date: Thu, 21 Mar 2019 07:32:30 +0000

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Mar 2019 06:46:07 -0700

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.

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.

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?

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).

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.

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.

You need to specify the format of "ServerID". Is it a domain name?
Something else?

-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-masked]> 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 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.
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Wang Haiguang <[email-masked]>
Date: Fri, 22 Mar 2019 15:28:42 +0000

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-masked]]
Sent: Thursday, 21 March, 2019 9:46:07 PM
To: Wang Haiguang
Cc: [email-masked]
Subject: Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10

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.
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.
As claimed in [2], TLS with  IBC  could significantly improve the performance.
Quote from [2] "MIKEY-SAKKE sped up the setup of HTTPS sessions by 7 times over standard TLS,
meaning websites loaded over 200ms faster".
[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
network. We do have a separate section in the draft to address the identity format, which includes expiring
time, location, service type (Appendix A).
We also want to point out that IBC is not a toy scenario. 3GPP has adopted the RFC 6507, RFC 6508 and RFC 6509
for mission critical communications, and UK government has already started to use it.

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.

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 think in the security consideration section, we can remind the TLS-IBC users of this key
escrow issue, and they should make a judgment before including TLS-IBC in their system.

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.

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.

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.
-Ekr

On Thu, Mar 21, 2019 at 12:33 AM Wang Haiguang <[email-masked]<mailto:[email-masked]>> wrote:
Hello, everyone.

Best regards.

Haiguang

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 22 Mar 2019 10:13:03 -0700

On Fri, Mar 22, 2019 at 8:28 AM Wang Haiguang <
[email-masked]> wrote:

> ------------------------------
> *From:* Eric Rescorla [[email-masked]]
> *Sent:* Thursday, 21 March, 2019 9:46:07 PM
> *To:* Wang Haiguang
> *Cc:* [email-masked]
> *Subject:* Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10
>

Yes, but IBC is not raw public key. It is effectively a
differently-construted PKI.

> of resource contrained devices (see section 7) including RAM usage ,

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,
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
> ",
>

In fact, in RFC 6507 page 7-8, authors have mentioned that expiration time
> may be included

This draft needs to provide a complete description.

> 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/

> 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.

> Considering this, we would like to suggest that the group do consider our

You're of course free to request this, but you have not persuaded me.

> 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?

> [HG] ServerID is simply the identity of the server, and the format of the
That is not going to promote interoperability.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 22 Mar 2019 18:24:03 +0000

Hiya,

> way we don't know how to ameliorate (as opposed to CT).

I agree with Ekr here. I'd go further and argue that applications
really need to be aware that somewhere there's a key generator who
knows all private keys and that it'd be too dangerous for that
kind of difference to be hidden inside a TLS library.

> the process allows you to have a code point without adoption.

+1

Cheers,
S.

---

From: Melinda Shore <[email-masked]>
Date: Sat, 23 Mar 2019 10:12:20 +0100

On 3/22/19 7:28 AM, Wang Haiguang wrote:
> group think we should address this issue, we can provide more
> information and details in the next draft.
> 

I generally agree with EKR's comments but I do think this is a
particular problem that needs to be addressed.  The security of a
mechanism like this depends on the ability to revoke compromised keys.
Your draft does not, in fact, include a key lifetime in the identifier
(and note that the timestamp is a MAY in RFC 6507).  If you decide to
include one it will probably need to be notably short in order to
provide any robustness against key compromises, which means that
rekeying and provisioning are going to be a practical problem that
may not be in scope for the draft but which will need to be addressed
in implementation and deployment.

I'm unenthusiastic about this draft but to the extent that there's a
hope to progress it, revocation really must be dealt with.

Melinda

-- 
Software longa, hardware brevis

PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
                     34C0 DFB8 9172 9A76 DB8F

---

From: Wang Haiguang <[email-masked]>
Date: Sat, 23 Mar 2019 10:08:43 +0000

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?

Regards.

Haiguang

________________________________
From: Eric Rescorla [[email-masked]]
Sent: Saturday, 23 March, 2019 1:13:03 AM
To: Wang Haiguang
Cc: [email-masked]
Subject: Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10

On Fri, Mar 22, 2019 at 8:28 AM Wang Haiguang <[email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>]
Sent: Thursday, 21 March, 2019 9:46:07 PM
To: Wang Haiguang
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10

Yes, but IBC is not raw public key. It is effectively a differently-construted PKI.

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.

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/

I don't think this is a demonstration that this is not severe. It's merely a demonstration that the current situation is bad.

TECHNICAL COMMENTS

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?

-Ekr

-Ekr

Best regards.

Haiguang

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 23 Mar 2019 04:30:50 -0700

On Sat, Mar 23, 2019 at 3:08 AM Wang Haiguang <
[email-masked]> wrote:

> 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

> *Sent:* Saturday, 23 March, 2019 1:13:03 AM
> *To:* Wang Haiguang
> *Cc:* [email-masked]

---

From: Wang Haiguang <[email-masked]>
Date: Sat, 23 Mar 2019 15:57:25 +0000

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.

Thanks very much.

Haiguang

________________________________
From: Eric Rescorla [[email-masked]]
Sent: Saturday, 23 March, 2019 7:30:50 PM
To: Wang Haiguang
Cc: [email-masked]
Subject: Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10

On Sat, Mar 23, 2019 at 3:08 AM Wang Haiguang <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Eric

-Ekr

Regards.

Haiguang

TECHNICAL COMMENTS

-Ekr

-Ekr

Best regards.

Haiguang

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 23 Mar 2019 10:02:05 -0700

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

> 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

> *Sent:* Saturday, 23 March, 2019 7:30:50 PM
> *To:* Wang Haiguang
> *Cc:* [email-masked]
>> 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 think this is a demonstration that this is not severe. It's
>> merely a demonstration that the current situation is bad.
>>
>>
>>>> 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 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.

---

From: Wang Haiguang <[email-masked]>
Date: Sun, 24 Mar 2019 11:47:50 +0000

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 [[email-masked]]
Sent: Sunday, 24 March, 2019 1:02:05 AM
To: Wang Haiguang
Cc: [email-masked]
Subject: Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10

On Sat, Mar 23, 2019 at 8:57 AM Wang Haiguang <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Eric

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

-Ekr

Regards.

Haiguang

TECHNICAL COMMENTS

-Ekr

-Ekr

Best regards.

Haiguang

---

From: Wang Haiguang <[email-masked]>
Date: Sun, 24 Mar 2019 12:05:33 +0000

Hi, Stephen

Thanks much for your comments. 

As IBS using a centralized PKG to generate keys for the peer, some users do concern about this feature. 
However, for some usage scenarios such as telecom operators, key escrow is not a issue since 
with the current telecom networks, all the mobile devices embedded with a root key in their USIM card,
which is known to the home operators. So knowing the private keys of devices are not a issue, depends 
on the usage of the keys. 

If users worry about this feature, can we make it an optional feature and only when companies want to use
it, then they can enable this feature or patch the library. 

Best regards.

Haiguang       
________________________________________
From: Stephen Farrell [[email-masked]]
Sent: Saturday, 23 March, 2019 2:24:03 AM
To: Eric Rescorla; Wang Haiguang
Cc: [email-masked]
Subject: Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10

Hiya,

+1

Cheers,
S.

---

From: Wang Haiguang <[email-masked]>
Date: Sun, 24 Mar 2019 12:16:41 +0000

Hi, Melinda

We do plan to include an expire date in the identity design. The valid period is a decision that should be decide either by the user or the PKG manager. 

When we use the existing raw public as specified in the TLS 1.3, somebody has to decide the lifetime of a raw public key also.   

Wtih IBC, re-keying is needed when a private key is expired. Similarly, when a raw public (as in TLS 1.3) expires, the binding list has to be updated by re-keying the raw public key at server side.  

Haiguang 
________________________________________
From: TLS [[email-masked]] on behalf of Melinda Shore [[email-masked]]
Sent: Saturday, 23 March, 2019 5:12:20 PM
To: [email-masked]
Subject: Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10

Melinda

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 24 Mar 2019 13:24:35 +0000

I agree with EKR. 

It's another type of PKI, in the sense that there's some infrastructure you have to trust, in addition to or instead of your own key pair. Some, myself included, would prefer facing the kinds of attacks that are possible with the traditional PKI, rather than those that IBC enables.

Regards,
Uri

Sent from my iPhone

> On Mar 24, 2019, at 08:17, Wang Haiguang <[email-masked]> wrote:
> 
> Hi, Melinda
>

---

From: Melinda Shore <[email-masked]>
Date: Sun, 24 Mar 2019 14:46:44 +0100

On 3/24/19 4:16 AM, Wang Haiguang wrote:
> We do plan to include an expire date in the identity design. The
> valid period is a decision that should be decide either by the user
> or the PKG manager.

The problem here is that you do not want to get into the
position of allowing a known compromised key to be treated
as valid for, say, a period of several years.  Even if you
replace the private key in the handset, a "compromise"
typically involves the existence of an uncontrolled instance
of the private key.  Consequently you need to either narrowly
constrain the key lifetime or provide a revocation mechanism.

Melinda

---

From: Wang Haiguang <[email-masked]>
Date: Sun, 24 Mar 2019 15:33:55 +0000

To handle the compromised key, a revocation list maintained at server side can help. This is similar to the PKI certificate. 

The binding list used by existing raw public in TLS 1.3 actually is a white list. If I have a few million devices, then the white list contains a few million records.   

On the other hand, the number of compromised keys usually should be only a small number.  So the revocation list is much shorter compare to the binding list maintain for raw public.

This is value point of using IBS as signature algorithm. 

TLS with IBS is not proposed for use with the existing browser/server kind of communication. The intention is to use IBS for IoT networks.  

________________________________________
From: Melinda Shore [[email-masked]]
Sent: Sunday, 24 March, 2019 9:46:44 PM
To: Wang Haiguang; [email-masked]
Subject: Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10

Melinda