[openssl-users] Authentication over ECDHE

[Matt Caswell]

On 24/12/2018 19:52, Viktor Dukhovni wrote:
>> On Dec 24, 2018, at 2:44 PM, Salz, Rich via openssl-users <openssl-users at openssl.org> wrote:
>>
>> Pre-shared keys (PSK) don't require certs, maybe that meets the need.  A thing to know about PSK is that each side is fully trusted, and if one side gets the key stolen, then the thief can pretend to be either side.
> 
> PSK only makes sense for svelte SSL libraries that either run
> on devices with too little CPU to do public key crypto, or don't
> want to the pay the code footprint of X.509 certificate processing.
> 
> For OpenSSL on a typical computer, PSK deployment and application
> support is more complex than just going with self-signed certs.
> 
> The OP is IMHO better off avoiding PSKs.
> 

I disagree with this assessment of what PSKs are good for. As with any
technology choice there are trade offs that have to be made. PSKs are actually
*simple* to deploy (far simpler than X.509 based certificates IMO) and are
perfectly suitable for all sorts of environments - it doesn't just have to be
"devices with too little CPU to do public key crypto". The problem with PSKs is
that they do not scale well. If you have lots of endpoints then the cost of
deploying and managing keys across all of them becomes too high too quickly. By
comparison X.509 certificate based authentication is complex and costly to
deploy and manage. Such a solution does scale well though.

If you've got a small number of endpoints then PSKs may be a suitable choice. If
you've got lots of endpoints then, probably, an X.509 certificate based solution
is the way to go.

The OP talks about a "select few machines" being able to access a database
server. This sounds precisely the sort of environment where PSKs would work well.

On 24/12/2018 16:43, Viktor Dukhovni wrote:
> This requires more complex application code on the client and server,
> so I would not recommend it.

Not really. The application code for PSKs is quite straight forward in most cases.

> And IIRC there may be some complications
> with getting PSKs to work across both TLS 1.2 and TLS 1.3???

Yes, there are differences between PSKs in TLSv1.2 and TLSv1.3, so if supporting
both of those is a requirement then there are additional things to bear in mind.

In TLSv1.2:
1) A server (optionally) provides an identity hint to the client
2) The client looks up the identity to be used and the associated PSK value
(possibly using the hint provided by the server to select the right identity)
3) The client sends the identity to the server
4) The server receives the identity from the client and finds the PSK associated
with it
5) Both sides derive keys for the session based on the PSK (possibly
additionally using (EC)DHE to add forward secrecy)

In TLSv1.3 there is no identity hint - the client just finds the identity
without the use of a hint. The identity has an associated key (as in TLSv1.2)
but it *also* has an associated hash algorithm. If no hash algorithm is
explicitly specified then SHA256 is assumed by default.

OpenSSL 1.1.0 (and earlier) provided an API for TLSv1.2 PSKs. This continues to
work in OpenSSL 1.1.1 and it can be used in both TLSv1.2 *and* TLSv1.3. However
the callbacks will get called with a NULL identity hint on the client side.
Since this older API was not designed with TLSv1.3 in mind there is no way to
specify the hash to be used - so if you use this older API then SHA256 is always
in use (and a SHA256 based TLSv1.3 ciphersuite must be available).

OpenSSL 1.1.1 provides additional APIs for doing TLSv1.3 PSKs that may be used
instead of (or as well as) the TLSv1.2 PSK API. This API *does* allow you to
specify the hash to be used, but does not work in TLSv1.2.

So, if you're happy with the SHA256 default, then you can just use the older PSK
API and it will work quite happily in both TLSv1.2 and TLSv1.3. If you want more
control in TLSv1.3 then you might need to use a combination of the old API (in
TLSv1.2) and the new API (in TLSv1.3).

Matt