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

[michael cheng <[e-mail]>]

Hi Ekr,


    As Haiguang explained in the email, the proposal now mainly targets the
IoT scenario and we believe there is a strong case that we should take a
new approach to the security of this scenario.



  As for IoT devices, mainly there are three possible choices. 1) use the
symmetric-key solution. Concurrently in the telecom networks, symmetric
keys are used for device authentication and session key establishment.
Maybe TLS could be further applied but with only server authentication and
a client device, whose symmetric key is known by the server, is
authenticated with the symmetric key in the application layer. 2) force
every device to obtain a certificate and use TLS with both client and
server authentication. 3)every device has a pair of public/private key and
use TLS for both client and server authentication. However, the raw public
key should be validated with separate mechanisms.



  As suggested in Erk's previous email, " the current situation is bad."
The first method is vulnerable to certain attacks and makes the whole
authentication process complicated if TLS+symmetric key (separated client
authentication) is used. In particular, roaming device authentication has
to involve the homework to participate in the authentication process.
However, the method is light on the client side and makes it the favorite
choice.


   The second method has the strongest security. On the other hand, it is
heavy, particularly for resource-constrained devices. This may be the main
reason that the first method is still a favorite choice for client
authentication.


   For the third method, the public key validation process should be
carried out. There are a couple of choices like DNS or PKIX or preinstalled
keys. For the server side's public key validation, DNS may be OK, but for
billions of IoT devices, this is not feasible. For PKIX, it is arguable
that if such system is "viable" in many cases with online certificate query
for tens of millions or even billions of devices. "viable" I mean both
technically and financially. Cost-effectiveness plays an important role
when a technical decision is made.  A PKI system with billions of
certificates may be technically possible like the one run by EMVCo.
However, for low-value target IoT devices, many service providers favor
low-cost solutions. A database containing the pairs of id and public keys
is a possible choice. On the other hand, the integrity of such maps has to
be guaranteed. If only a server needs to access such information, this may
not be critical. However, more scenarios should be considered too, like
cross-domain verifications and device2device authentications.



  Identity-based cryptography, particularly, identity-based signature in
the proposal offers another option. The entity's public key is calculated
from an identity string and a set of system parameters. It has several
advantages. First, it could use less bandwidth and computation power. For
example, the ECCSI algorithm could work exactly with an infostructure like
a PKIX with revocation capability. It still offers clear advantages. It
takes one point scalar to compute the public key and one point to represent
the public key reconstruction data. While in PKIX issuing certificates with
ECDSA, a certificate validation process requires two point scalar for ECDSA
verification, and the certificate contains an entity's identity info, a
public key and CA's signature (64 bytes at least). So,  ECCSI could be 50%
faster in term of public key validation and 50% shorter than a certificate
(if an identity encoding scheme with expiry info is about 32-bytes long,
for example, Zigbee smart energy standard uses 26-byte id encoding).
Second, IBC does not need a mechanism to map id with a key set, this
certainly simplifies the system. At least a highly protected database to
store a user's secret key is not necessary.



  As for the key escrow problem frequently raised in the emails, indeed,
there is a PKG in the system which could generate each device's private
key. However, when IBS is used in TLS1.3, passively attack to recover the
session key is not possible. Actively man-in-the-middle attack by replacing
exchanged DH tokens and signatures would certainly leave traces even
transiently. Similarly, a PKG could impersonate an entity to conduct a TLS
session, just as the KMS in the symmetric key solution, but forensic traces
could be also collected in this situation. It would be hugely risky for a
PKG, which would usually be a trusted party, to launch such attacks. If
such an attack is caught in red-handed, no one would trust the PKG's
service anymore.



   Overall, TLS+IBS offers advantages over symmetric-key based solution
with better security properties and flexibility. TLS+IBS could be better in
term of computation efficiency and communication bandwidth than
TLS+Certificate or TLS+raw public key. As for security, the only issue is
the key escrow capability of PKG. The passive attack is not possible with
TLS 1.3+IBS, and launching the active man-in-the-middle attack or
impersonation attack could severely corrode the PKG's reputation if such an
attack was detected. We believe for many application scenarios like the IoT
that the proposal is currently targeting, TLS+IBS makes a step forward
towards a better or more secure alternative.


Michael Cheng