On Tue, Aug 21, 2018 at 11:33 AM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> > > > 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. > Yes. TLS 1.3 explicitly does not support those. > 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. > Or you could just generate a fresh signing key for each connection. -Ekr > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
