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

[Eric Rescorla <[e-mail]>]

On Tue, Aug 21, 2018 at 11:33 AM, Viktor Dukhovni <[e-mail]>
wrote:

>
>
> > On Aug 21, 2018, at 2:18 PM, Eric Rescorla <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>