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

[David Benjamin <[e-mail]>]

On Tue, Aug 21, 2018 at 1:34 PM 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.
>
> 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.
>

Add a separate function? It's reasonable for a caller which configures a
client to expect raw public keys to call a function that returns the peer
identity as a raw public key. Likewise, it's reasonable for a caller
configuring a server which uses raw public keys to call a
raw-public-key-specific configuration function. The same goes for any other
non-certificate-based authentication.

We have no plans to support this feature in BoringSSL, but if a need of
this shape ever arised, that's how I would imagine doing it.

David