On 24/12/2018 19:52, Viktor Dukhovni wrote: >> On Dec 24, 2018, at 2:44 PM, Salz, Rich via openssl-users <openssl-users@xxxxxxxxxxx> 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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
