> On Aug 21, 2018, at 2:18 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
>> As for TLS 1.3, it is indeed missing both null encryption and null
>> authentication ciphers.
>
> If by "null authentication" you mean "without certificates", then TLS 1.3 does
> support these via RFC 7250. See:
>
> https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.5
My comment was about ADH/AECDH cipher-suites, in which the server
does not sign the key exchange, because it has no keys and the
client has no intention/means to authenticate such a signature.
You are of course right that TLS 1.3 supports raw public keys,
which make it possible to do away with X.509 support. I would
not call these null authentication, since DANE or key pinning
(much less scalably) make it possible to authenticate raw public
keys.
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?
In the case of OpenSSL, adding such support is difficult, because
the assumption that the peer returns X.509 certificates and not
some more general data type is baked into the API. 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.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
