Re: [TLS] null auth ciphers for TLS 1.3?

Hi, all.

Regarding the raw public, I would like to contribute a few words for you to think about it. 

Raw public key is useful for IoT networks due to the constraint of bandwidth and processing capability of devices. A normal certificate takes about a few hundred bytes while an raw public key can be less than one hundred bytes. 

The raw public with TLS can be used together with EAP framework to perform mutual authentication between device and server, i.e. raw public key with EAP-TLS. It not only saves transmission bandwidth, but also simplify the implementation at device side. 

Currently we are collaborate with some leading telecom operator on a solution of using raw public key with EAP-TLS. However, with the normal raw public, the server side need to maintain a table that maps the public key and identity at server side, which can be huge. 

To solve this issue, we are investigating of using identity-based cryptography (i.e. ECCSI in RFC 6507) to eliminate  the huge mapping table. So far it looks good. 

Authentication for IoT could be another huge usage scenarios for TLS, it is expected to have more than 50 billion iot devices deployed in the next 10 years. It is good opportunity to extend the usage of TLS.

Currently, 3GPP has already enable the support for using EAP-TLS in the 5G neworks. Please find the most recent 5G security specification http://www.3gpp.org/ftp/Specs/archive/33_series/33.501/. It has been specified in the Annex B. 

We hope the scope of raw public key with TLS can be extended in the future.  

Regards.

Haiguang Wang
________________________________________
From: TLS [tls-bounces@ietf.org] on behalf of Peter Gutmann [pgut001@cs.auckland.ac.nz]
Sent: Wednesday, 22 August, 2018 9:55:47 AM
To: <tls@ietf.org>
Subject: Re: [TLS] null auth ciphers for TLS 1.3?

Viktor Dukhovni <ietf-dane@dukhovni.org> writes:

>I've not yet seen raw public key support in any mainstream TLS libraries,
>though admittedly my focus is primarily on OpenSSL.  Do any of NSS, GnuTLS,
>BoringSSL, LibreSSL, ... support raw public keys?

I've never seen it either.  My code does actually support them, but not in the
way you think, for devices that don't have the ability to deal with certs
there's the memcpy()-into-send() certificate implementation I've mentioned
before, you memcpy() a pre-encoded cert chain onto the network, and for
receiving memcpy() the data in and pick out the SPKI.  So in effect it's raw
public keys, but to anyone watching it looks like it's certificates.  There
are other embedded implementations that do this too, it's a pretty obvious
optimisation (in other words I'm not trying to claim credit for inventing it).

>We'd need to invent some sort of special X.509 object that holds only a
>public key, but behaves in some sensible way when used with functions that
>expect X.509 certificates.

That's exactly what my code does, but with certificates
(CONFIG_USE_PSEUDOCERTIFICATES).  So there's no need for raw public keys, you
just treat certs as raw keys and everything works the way it already does with
certificates.

Is there any known actual use of raw public keys for TLS?

Peter.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls