Comment 1:

For now at least, very low priority.

Labels changed: added priority-someday, removed priority-triage.

Status changed to Accepted.

Comment 2:

Labels changed: added go1.3maybe.

Comment 3:

Labels changed: added release-none, removed go1.3maybe.

Comment 4:

Labels changed: added repo-main.

Might be a good idea to revisit this. I am interested in IoT and some devices simply cannot do regular TLS. Having a solid implementation of TLS-PSK would enable people to use Go to implement a server communicating with a swarm of IoT devices. I am not so much into crypto to be able to implement this myself. Basically just saying that IoT is on hype today and the last comment in this thread is more than 3 years old. For someone knowing crypto and crypto/tls it seems that this would not be too much work...

Sorry, the last change in this thread is 2015, but anyway :-)

/cc @agl for advice

My feeling is that this is fairly obscure and that we (by which I mean "I") should focus on TLS 1.3 support in crypto/tls, at least in the 1.9 cycle.

@agl @rsc @tchap I have implemented the PSK and DHE_PSK ciphers (server and client). Is there interest in merging code for this? It required removing assumptions about there always being a server cert, so it's not totally trivial.

Go 1.9 is frozen, but I'll let @agl decide for Go 1.10.

You can find my fork with PSK support here:
https://github.com/mordyovits/golang-crypto-tls

Well, I can't speak for everybody, but in my case, forward secrecy is not important to me because we have a mechanism to rotate the PSKs outside the context of TLS. (Also, because in an IoT sensor network, the ability to go back and decode old sensor data is of limited value.) I can certainly understand why we might not want to enable TLS modes that don't provide forward secrecy by default, but enough people thought there was a valid use case for plain to include it in the TLS1.3 spec despite the lack of forward secrecy, so I can't be the only one who would use it if it were available.

I realize I'm in the minority, but I work with tiny embedded devices for which every kilobyte of code space is precious, and every single byte sent over a network costs me battery life. So, rather than have a 'dummyproof' TLS stack with PFS, I would much rather have one that lets me make the security tradeoffs that make sense for my problem space.

All that said, if this change never makes it into the std library, I would love a writeup explaining how to handle vendoring crypto/tls. And if any kind soul wants to provide some unofficial code with the 'easy' changes to handle plain external PSKs, I wouldn't turn my nose up at that, either. ;)

I agree with John. My specific usecase was using the ESP8266 embedded computing modules, and trying to avoid rolling my own crypto. The benefit of ESP8266 is an extremely cheap WiFi enabled module, but it has limited computational power (and no hardware support for cryptography). It's normally running at 40 MHz, but the vendor's SSL library boosts it to 80 MHz during RSA computations... 1,536 bits is barely doable, and at 2,048 bits the watchdog timer usually resets the device.

And so, I didn't feel the RSA support was worth using. AES is fine, and as @jvmatl mentioned, pre-provisioning per-device symmetric keys is often fine for embedded devices.

I think it's important to have something that allows even the smallest of devices to run encryption, and ECDH/RSA/EC is too slow to be really practical. I completely agree it should be harder to enable PSK than forward-secrecy mechanisms, there is certainly a risk that making it difficult to use TLS at all for some devices leads us to a "roll-your-own" situation that benefits no-one in the end.

Finally, I'd like to mention that Mosh is another great example of a situation where PSK works. They have a pre-authenticated channel over SSH, but need to switch to UDP. So they simply send a symmetric key. (They're of course not using TLS, due to UDP.)

I had been watching this thread for a while but noticed today there was some discussion happening on it. I work consulting on cryptography (and other items) with a number of companies in the embedded IoT space, and it is very common that we have to figure out a transport encryption solution that works with their embedded constraints. It looks like @jvmatl above has mentioned some of those cases -- limited code size and battery life. In some cases, our code size is more constrained than the chip as for security purposes (among others) we want to be able to bank memory to be able to safely update in the field -- meaning our code size is cut in half. Regardless of how it happens -- code size and battery usage are real-world constraints and it would be great to use TLS rather than roll-their-own. The movement to use a supported TLS implementation in my opinion would add security benefit to people implementing transport encryption -- and allow them to go directly to their Go backends (if they use Go, which we have seen movement on a few of our customers to want to use) rather than having a proxy to decrypt between the IP connection and the backend.

@rmspeers For battery-constrained devices where you wouldn't want to wake up just to send a TCP keep-alive (or similar), wouldn't a more datagram-friendly layer like DTLS be preferred?

My ESP8266 use-case was just a hobby project, so I didn't have any hard constraints to work with. I wanted PSK in TLS because the ESP8266 standard library implements that, so I could have faster turn-around. Does this apply to other devices, or would it make more sense to add PSK in e.g. crypto/dtls specifically for these?

@FiloSottile - you said

It is indeed pretty easy to add PSK support in TLS 1.3. (Or at least everything but the actually hard part of picking an API for it.)

-- What do you think about what Raff did as a starting point for discussion? (https://github.com/raff/tls-psk/blob/tls13/psk.go#L44)

If we take that, and add a boolean to explicitly allow pskModePlain, wouldn't that address everybody's concerns? The server could (and should!) still prefer to use pskModeDHE if offered by the client, and so nobody would ever accidentally get a session without forward secrecy;

The only time a TLS1.3 session with a Go server would lack forward secrecy would be if:

• The client and server have a shared PSK (can't happen by accident)
• The client only offers only pskModePlain in the clientHello.pskModes
• The server enables AllowPskModePlain in the tls config

package tls
type Config struct {
    ...
    // Configure the use of Pre-Shared external keys for use between
    // endpoints. This is typically only used in closed environments
    // where client and server can agree on keys out-of-band from TLS
    // and use of public/private keys is impractical. 
    PreSharedKeys PSKConfig
    ...
}

type PSKConfig struct {
    // Controls support for a PSK key exchange mode that is easier to
    // compute on very low-powered devices, but which does NOT offer
    // "Forward Secrecy". Enable only if you understand the security tradeoff.
    // (See `psk_ke` in RFC 8446, Section 4.2.9.)
    AllowPskModePlain bool

    // client-only - returns the client identity
    GetIdentity func() string

    // for server - returns the key associated to a client identity
    // for client - returns the key for this client
    GetKey func(identity string) ([]byte, error)
}

If the change to add external, plain PSK to TLS1.3 really is an easy one, and it's impossible for users to accidentally shoot themselves in the foot, and there are real-world use-cases for the feature where potentially millions of IoT devices get better transport security, isn't this a no-brainer?

@tommie - in some contexts, yeah, DTLS with PSK would be preferred, but DTLS support in applications/frameworks is not nearly as widely available as TLS.

For example, the Eclipse Paho project (arguably the go-to project for people looking for open-source mqtt clients) has clients for MQTT-SN (which is explicitly designed for low-power sensor networks!) and they don't even support DTLS yet, let alone DTLS with PSK. (See eclipse/paho.mqtt-sn.embedded-c#90)

But if Go's official crypto were to add baked-in support for external PSKs in TLS1.3 support, you can bet that every single Golang-based MQTT, CoAP, and LWM2M project would find they had a bunch of users wanting to make use of that new capability.

I have just updated my "tls-ext" package to latest Go crypto/tls (from Go 1.13.4). See https://github.com/raff/tls-ext/tree/tls13

This is the minimum required for my PSK implementation (i.e. I have only exported methods/values needed to build my tls-psk package) so it's easy to compare with the original code.

Note that this version doesn't actually support TLS 1.3 for PSK (the TLS 1.3 path is still trying to pick a certificate, that doesn't exist). I wasn't sure of what cipher-suites to add and I don't have any tests or implementation to compare to. So for now it's really just an "update" to my original implementation.

With these suggestions, adding PSK seems like a good choice.

The argument that it doesn't achieve PFS seems like perfect is the enemy of good. Encouraging forking the standard implementation and rolling your own PSK extension sounds more likely to lead to vulnerable code in the wild than having a PSK implementation in the standard library. Having it in the standard library leads to better testing, compatibility, and visibility over an external implementation. It would have to be explicitly enabled, so the security of default implementations isn't diminished.

Finally, now that modules are here it's actually pretty easy to replace crypto/tls by using the vendor folder, without having to fork net/http or replace the whole GOROOT. I should probably write that up

@FiloSottile -- can you elaborate on this? It seems like discussion on this topic halted over the holidays...

Now that I have gone further down my current path, the real cost of not having this in the standard library is growing geometrically; the downstream cost is much higher than just having to use an alternate TLS package in my own homegrown code. So just in case it's not clear, here is where I am at.

• I cannot change the embedded platforms: there are literally millions of IoT endpoints already manufactured over the course of years, and even if some of them are upgradeable over-the-air (and many are not) -- they don't have the code space or computational power to use asymmetric crypto effectively.
• If I want to develop a service that these devcies can connect to securely, I can (and am) using @raff's fork of the Go 1.13 crypto/tls. This is pretty straightforward
• I wanted to run a third-party MQTT broker and have it listen for TLS-PSK connections. In order to do this, I am forced to fork the MQTT broker package to make the modifications required to let it use the new tls package, rather than simply modifying some entries in the broker config file's tls.Config. Once I have done that, I have added the indefinite maintenance burden of keeping my changes in sync with upstream (so I can continue to receive new features/bugfixes)
• Next, I wanted to be able to run load-testing and integration tests with simulated clients written in Go. But in order to do that, I had to fork the Eclipse Paho mqtt client package o use the new tls. Again, I now have the maintenance burden of keeping that fork in sync with upstream, all because I couldn't add psk-tls functionality in a config file.

From where I'm sitting, this ever-growing spiral of forked code is unmanageable - so at some point I will probably bite the bullet and fork the builtin library itself, because at least that maintenance cost is a constant, but given the complexity of TLS implementation, I am less confident that I will always get this right.

None of this would be necessary if the TLS1.3 stack were extended to include support for PSK connections - something we have already established is technically easy to do, at least according to @FiloSottile.

(*) before somebody points out that getting tls-psk in TLS1.3 does not help me with my embedded clients, that's sort of true, but since I can write homegrown psk listeners relatively easily, I can deploy proxies that listen with the forked tls-psk and forward connections to my internal servers -- and over time, as the old devices retire, I can phase this monstrosity out of service. But if tls-psk never makes it into the standard library, the treadmill never ends...

Just for the record, I came here looking for something like this. PSK's might make my life easier. I have an already established secure channel (out of band) where I can exchange the PSKs securely, and discard them after I've used them. I don't need PFS in this context because I already have it by virtue of the fact I'm' using a secure channel (which does have PFS properties) to exchange these PSKs (which for my use would make them more like single use session keys.)

Notably earlier today I also came looking for DTLS support (for another but related reason).

It almost seems like the maintainers of this package kind of don't care about having it fully featured.

The failure to also have a FIPS 140-2 cert is also limiting.

I'm feeling like there is a business case in here somewhere.... probably an opportunity for someone to charge real $$ to provide a solution to these gaps.

Since in TLS 1.3 PSKs are merged with resumption, what would help here is an actual proposal of how an API that allows applications to inject PSKs through the same mechanism used to store session tickets/IDs would look like.

A good API would probably solve in one shot this, #25351, #25228 and #19199. (And #46718 and #57753.)

It almost seems like the maintainers of this package kind of don't care about having it fully featured.

For the record, the maintainers of this package care about not having it fully featured. crypto/tls implements a useful subset of the TLS protocol, it's how it stayed secure and maintainable for 10 years.

Looks like https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-05 is going to get published, so we might want to just jump ahead to its Importer API, and provide a way to import an external PSK into the session store through that mechanism.

Note that we are not going to support ECDH-less PSK modes, as they don't provide per-connection PFS.

@gdamore Go does have pion/dtls and it supports Certifitates and Pre-shared Keys. If it is missing any features that stop you from using it would love to hear!

Sorry to de-rail this ticket. I was looking around crypto/tls for an unrelated thing and saw this.

Also if anyone is interested I would totally be up for giving up ownership to the Go team! #13525 (comment) the code base is drastically different though. I wrote it to be more verbose/readable, things like each handshake message being their own struct

Thanks @Sean-Der -- I will look later.. I don't have an immediate need for DTLS, but its probably something I need to think about soon.

Change https://go.dev/cl/415034 mentions this issue: crypto/tls: add cipher suites TLS_ECDHE_PSK

Anyone cite a plain PSK client-server sample?

i'm using the rc candidate version

$ go version
go version go1.21rc3 linux/amd64

and trying to create a simple TLS client server with just PSK alone and i'm unsure how to construct the tls.Config

the best i could get is

	sstate := &tls.SessionState{
		Extra: [][]byte{[]byte("client1")},
		//secret: []byte(combinedKey),
	}
	
	tlsConfig := &tls.Config{
		GetConfigForClient: func(ci *tls.ClientHelloInfo) (*tls.Config, error) {
			return &tls.Config{
				MinVersion:   tls.VersionTLS13,
				WrapSession: func(cs tls.ConnectionState, ss *tls.SessionState) ([]byte, error) {
					// todo encrypt
					return sstate.Bytes()
				},
				UnwrapSession: func(identity []byte, cs tls.ConnectionState) (*tls.SessionState, error) {
					b, err := sstate.Bytes()
					// todo decrypt
					if err != nil {
						return nil, err
					}
					return tls.ParseSessionState(b)
				},
			}, nil
		},
	}

but don't know how to specify the 'secret' (i think you're supposed to encode the PSK secret into the sessionstate which gets wrapped unwrapped)

for ref, with nodejs and PSK, you can "just set" the secret via tls pskCallback

If you look at the code there is a mention of an "extra master secret" (it ends up being a 0 for non-secret and 1 for secret).
I didn't really follow the latest implementation but you can try to set the secret at Extra[1] (i.e. Extra[0] would be your "client1" thing, and Extra[1] would be the secret). When you unwrap you can retrieve from there.

Again, I didn't try, just a wild guess :)

@raff unfotunately, that didn't work.

@FiloSottile is it possible to directly inject a PSK or is the implementaion for go1.21 using PSK internally for other usecases and not surfaced to users? (i suspect thats the case)

Hey guys, any update on this?
Would be interested to see an example on how to use PSK with crypto/tls(even if it's forked), stuff I found is a bit outdated and I'm not sure what state is it in...