RFC: on a potential extension for in-band noise authority key rotation

[plebhash]

intro

Rotating the server static key is already free and in band, via the certificate. Rotating the authority key is not: it is the trust anchor, and today only reaches clients out of band (4.7). This RFC asks whether an extension should let a server deliver a successor authority key in band, over the already-authenticated session. Motivation is operational — out-of-band rotation means touching every client. The sketch is in the first comment below.

This is also correlated with PR #234, which adds 4.8 Key Management and Rotation and already covers offline custody of the authority key (4.8.2), the cost of rotating it (4.8.4), and clients trusting a set of authority keys (4.8.5).

24/09/2026 Sv2 Working Group call

Notes auto-generated by Gemini from the Google Meet recording, then refined and reformatted with Claude Opus 5.

Server Security and Key Trust Assumptions

Participants: @coleFD, @TheBlueMatt, @plebhash, @GitGab19, @bit-aloo

Topic: server security and pool trust without traditional TLS certificate authorities.

• @coleFD raised concerns about the configuration costs and complexities of dynamic ports and load balancers.
• @TheBlueMatt and @plebhash responded that authority keys can be kept offline and derived securely from Bitcoin wallets or HSMs, using an SECP key and a hierarchical deterministic path.
• Unlike TLS, which relies on certificate authorities vulnerable to BGP attacks, Stratum v2 intentionally relies on endpoint-locked keys requiring physical security barriers.
• @TheBlueMatt concluded that this deliberate design provides superior security compared to TLS models, despite requiring pools to properly secure their keys.

Key rotation challenges and compromise mitigation

Participants: @coleFD, @TheBlueMatt

• @coleFD argued that if pools fail to follow the security assumptions, key rotation becomes a difficult process that forces a reliance on users updating their keys.
• @TheBlueMatt countered that bypassing key verification removes all security, reducing the system to Stratum v1 level security.
• @TheBlueMatt further explained that a key compromise does not result in immediate Bitcoin theft, because an attacker still requires an active man-in-the-middle attack — so rotation does not need to occur within seconds.

Consensus: a compromised key forces a temporary fallback to less secure states, but immediate rotation is not critically time-sensitive, since an active man-in-the-middle is still required.

Evaluating In-Band Key Rotation Proposals

Participants: @plebhash, @coleFD, @TheBlueMatt, @average-gary, @GitGab19, @bit-aloo

Topic: potential protocol extensions and in-band methods for handling key rotation and failovers.

• @plebhash introduced @coleFD's initial proposal: clients maintain a local set of authority keys, and the server delivers a successor key in band. Note the local set itself is uncontested and already described in 4.8.5 of document authority key management and rotation #234; only the in-band delivery is at issue here.
• @TheBlueMatt strongly rejected the proposal, arguing it introduces severe vulnerabilities where an attacker could permanently redirect miners via a malicious authority key update.
• @average-gary suggested pre-creating a secondary authority key as a failover index; @TheBlueMatt and @GitGab19 acknowledged this as theoretically possible but similarly vulnerable to compromise.
• @GitGab19 proposed displaying different keys on pool websites and configuring firmware to test fallback keys sequentially.
• @bit-aloo noted that no clear solution exists for sudden compromises.

Consensus: reject in-band rotation due to security risks, leaving pools to manage manual updates through offline key storage.

Codebase adjustments and SRI support for multiple keys

Participants: @TheBlueMatt, @bit-aloo, @GitGab19

• @TheBlueMatt recommended that documentation explicitly detail the difficulty of key rotation and mandate offline key storage derived from Bitcoin keys.
• @TheBlueMatt suggested SRI take on supporting multiple key configurations and client IP tracking on the same port — though not as a high-priority item.
• @bit-aloo confirmed that codebase changes in noise-sv2 for checking a single authority key would not require massive modifications.
• @GitGab19 emphasized that pools will still need to temporarily support two separate endpoints simultaneously during key transitions, to accommodate varying firmware capabilities.

Agreed actions: update documentation, task SRI with multi-key support, and require pools to maintain dual endpoints during migrations.%

[plebhash]

my current mental model of how a potential extension would work for this (needs refinement)

- initial noise handshake happens with the out-of-band authority key (vanilla Sv2)
- usual routine of SetupConnection and Extension Negotiation
- if server ever desires to rotate, they notify the client via extended Reconnect message
- server pushes fallback authority key in-band (in the secure channel)
- client operates a smooth transition to the new encryption (without leaving machines idle, which is the important detail here)

if the reason for rotation is the fact that authority private key 0 was compromised, as long as private key 1 remains non-compromised, the new connections will still be authenticated

the implications here are not only that there's a way to mitigate key compromise, but also that this enables continuous in-band key rotation without loss of funds (during the switch), which could be argued as best practices while dealing with large scale deployments

edit: I think the idea above is flawed... if attacker holds private key 0, they could lie about the new authority key that would be communicated in-band

[GitGab19]

• Routine rotation: "please update to our new key." Having the old and new keys valid at the same time during the migration is fine.
• Compromise: "stop trusting the old key now." Clients need to drop it immediately.

I think it makes a lot of sense to frame this issue by pinning these two scenarios in our heads.

---

During yesterday's meeting we mainly discussed about the second case, which is when the key gets compromised.

In that case, I think there's no way other than communicating this out-of-band to your clients, as a pool, and wait for all of them to migrate to the new safe key (during the migration the pool would still have to accept the old key, accepting the usual Sv1 risks until everyone migrates).

---

For the case where the pool wants to rotate the key as a security routine, we could have an extension to communicate the new key to use in-band, but this would still have the same issues IMO:

• what do you with clients which does NOT support the extension?
  • you have to still accept the old key for those clients, because you don't want to lose their hashrate as a pool
• how can you be sure that this new key sent through the extension is not being sent by an attacker who got the pool's key and it's doing MITM, as a client?
  • there's no way to prove anything here IMO, so an out-of-band communication about the routine key rotation is still needed to inform your clients about that

That's why I guess that the best thing to do, as a pool, is to define a clear strategy handle these two scenarios with out-of-band communications.

[coleFD]

for the second case, it doesn't matter if an attacker sends a key because the client still has your local set that that they can ensure was given to them out of band by the pool and if it doesn't match, the client will know it's unsecure. The benefit is that the miner can add the key locally before the pool actually switches. Here is a walkthrough of what I am proposing:

1. pool wants to rotate keys
2. pool generates new key pair and give the new pubkey to the client
3. client update their local set [old_pool_pubkey, new_pool_pubkey]. All of them still successfully mine because the pool is still using old_pubkey which is sent in-band
4. pool rotates key config in server, all clients still successfully mine because the in-band pubkey is now new_pool_pubkey and all clients have that in their set
5. pool tells clients to remove the old pubkey

In the case of a MITM, the attacker would have to know one of the pubkeys (new or old) to actually do the attack and we dont assume that is the case during a routine rotation.

[coleFD]

An alternative proposal could be:

1. client optionally appends it's configured pool authority pubkey to the end of Message 1 in band
2. pool is configured to accept both [old_pubkey, new_pubkey]
3. upon connection pool decides which keypair to use based on the in-band pubkey in Message 1

I think this may be better because it would allow clients that both have and havent updated their keys in a routine rotation to continue mining and the pool has visibility on which clients havent updated their configured pubkeys instead of just seeing "failed handshake" logs. And this could be entirely encapsulated by the api by allowing pool implementers to pass in a set of pubkeys and for client implementers to pass in their configured pubkey

[TheBlueMatt]

There's two ways a "here's my new key" message could work: (a) the client stores the new key and uses it as the new required-authority key or (b) the client doesn't store it and requires the "here's my new key" message on every reconnect.

(a) enables the attacker who has temporarily compromised the pool's infra to permanently steal hashrate. This seems way worse than not having rotation support. Of course, if the client doesn't store anything the client may still need a reconnect/reboot to go back to the original pool server but at least that's straightforward (and if the attacker's infra crashes at some point in the coming days the client may reset to their original server and start mining on the recovered pool infra).

(b) doesn't accomplish anything - the client still starts up and requests a certificate signed by the compromised key, and that has to be provided as a first step. Having compromised key K sign temporary key A to tell the client to reconnect using authority key B which signs temporary key C is just extra steps - stop at A.

[bit-aloo]

Yeah, I think this gets to the actual conclusion.

As you point out in (a), allowing an in-band message to introduce and persist a new authority key means that a temporary compromise of the transport/session state could be turned into a permanent compromise.

I think the useful model here is that the client already has a set of authority keys configured out of band, e.g. [K0, K1]. The extension never introduces a new trusted key, it only coordinates switching between keys the client already trusts.

So, if the pool is currently using K0 and wants to move to K1, clients can already have both configured. For clients with an established secure session, the extension can coordinate the transition to K1 without interrupting mining. The client would only accept the transition if K1 is already in its locally configured set.

If the session state is compromised, the attacker still can't install some K_attacker and make the compromise persistent, because the client will only transition to a key it already trusts.

If the connection needs to be respawned, I don't think we need to provide any additional guarantee through this extension. The trusted authority keys are already configured out of band, so we don't need clients or servers advertising authority keys or attaching additional keys to certificates as part of the handshake.

And if an authority key is actually compromised and needs to be removed from the trusted set, communicating that still ultimately has to happen out of band.

So IMO the extension is useful for coordinating a smooth transition between already configured authority keys, not for introducing new authority keys.

@TheBlueMatt, curious if you could give this a read: #235 (comment)

[coleFD]

im curious about this argument

"@TheBlueMatt strongly rejected the proposal, arguing it introduces severe vulnerabilities where an attacker could permanently redirect miners via a malicious authority key update."

What are the vulnerabilities? The only vulnerability that is clear to me is an opt-in config to mine on an outdated key and firmwares could log that they are mining on an outdated key so the error is loud. The same vulnerabilities are present in the case a untrustworthy pool doesnt want to rotate due to the various costs associated with it (losing hashrate, work required for support, etc). At least in the proposal, rotation for pools is actually zero cost and failures are loud for the client

[TheBlueMatt]

I was referring to the design listed as (a) at #235 (reply in thread)

[bit-aloo]

Ok, so let me try to explain how noise works right now, how we can avoid the problem around an authority key leak, and what other attack vectors are possible.

We use the NX variant of Noise for Sv2. The client sends its ephemeral key, and the server replies with its ephemeral and static keys, plus a certificate where the authority key signs the server's static key. The client checks that signature against the authority pubkey it got out of band from the server. If it matches, both sides derive the transport keys. The client's decryption key is the server's encryption key and vice versa.

Once the handshake is done, the session is secured by those transport keys. Forward secrecy comes from the ephemeral keys in the handshake: leaking the authority key later doesn't expose past sessions. But if someone gets the transport keys, they can read everything on that connection.

So there are two things that can leak: the authority private key, and the session state (transport keys).

1. Authority private key leaks, session state is safe.
   a. Client not connected: the attacker can impersonate the server on new connections. The only way to help the client is for the server to reach out out of band and ask it to update the authority pubkey.
   b. Client connected: the connection is still secure, so the server should be able to rotate the key in band, via a reconnect or an extension.

2. Session state leaks, authority private key is safe.
   a. Client connected: the attacker can already see all client messages. If the rotation extension exists and the client accepts any key sent over the session, the attacker can rotate the client to its own authority key and own every future connection. Without the extension, a reconnect to its own server won't work, since it can't sign a certificate the client accepts.
   b. Client not connected: no session state exists.

3. Session state and authority private key both leak: only out of band communication can save the client. Nothing in band can.

With this in mind, we can implement in-band authority key rotation with an extension. It won't save us in every scenario, but it does solve the one that started this discussion, the authority private key leaking.

1. An extension that just rotates keys: keeps the connection secure in 1b, but makes 2a worse, since a leaked session can now be turned into a permanent takeover.
2. An extension that rotates keys, but only to authority keys the client has pre-stored: covers 1b and also 2a, since the attacker can't rotate the client to a key it controls.
3. Or any other variation to this

Option 2 covers the case we care about. For the rest, the server has to fall back to out of band communication.

cc: @coleFD @plebhash @GitGab19

[TheBlueMatt]

I'm not really sure what this accomplishes in the real world, tbh. The attacks were concerned about aren't really "hacker compromises the pool's servers, pools retains control of its servers, but hacker still has MitM access to the pool's clients, but also the pool can send a rotation message". I don't really understand that threat model.

The threat model we're mostly worried about is ISPs and rogue employee attacks (mostly on the miner but to a lesser extent on the pool's side).

You might combine an ISP attack with a key-compromise attack, where the ISP retains MitM after compromising the key, but of course then your rotation message isn't going to make it to the client.

Can you describe a concrete attack you think is realistic that is prevented through a "disable key B" message?

Not that I'm against it, really, there's nothing wrong with a second key pre-enrolled and a way for the server to disable the old one, I just think we're way down the rabbit hole and not thinking about what we're trying to protect against.

[plebhash]

an important factor that has probably been overlooked up until now:

in its early development stages, SRI's noise_sv2 made the KISS decision of making server static key ephemeral... every session leverages RNG to create a new static key, and a new throw-away certificate is signed

moreover, the application layer of SRI is currently structured in a way where authority keypairs are written into config.toml and deployed on the server (which is not a good idea for production)

all of that is still true on SRI today

this oversimplification was practical for early development, but now it might be nudging implementers (e.g.: @coleFD ) in a direction where their custody expectations around authority keys might be shaped by what SRI does today, not by what the protocol was designed for

---

while ephemerally generating static keys for every handshake is not violating the spec as-is, I don't think it is good practice for production systems

static keys do deserve "cheap" rotation, but making them ephemeral pushes authority key to a "hot" position where it doesn't belong

looking at it from a pure protocol design perspective (@TheBlueMatt please correct me if I'm wrong here):

• ephemeral keys are meant to be rotated on every session
• static keys are meant to be hot, and periodically rotated (with new signed certificates)
• authority keys are meant to be kept off the internet-facing server (offline, HSM, or an internal signing service), and only ever touched when new certificates need to be signed... rotation is expensive by design

so I've updated #234 accordingly:

• §4.8.1 now says a server SHOULD NOT sign certificates at handshake time or generate a static key per connection outside development and testing
• §4.8.2 is now more explicit about keeping the authority private key off the internet-facing server.
• §4.8.3 now says renewal SHOULD issue the certificate for a new static key rather than extend the old one, so a leaked static key stops verifying at the end of its window even if nobody noticed the leak

since authority key rotation is meant to be expensive by design, trying to work around that with an extension feels backwards

the rare authority rotation that still needs to happen (e.g.: staff turnover, or key compromise) should be handled by a parallel endpoint (as clarified on §4.8.4 of #234), or ideally via clients configured with MULTIPLE authority keys (as clarified on §4.8.5 of #234), which is the multi-key support SRI already agreed to take on.

communication of the new authority pubkey stays out of band by design, but with multiple keys configured upfront, the switch itself needs no coordination: servers just start presenting certificates signed by the new key, and clients remove the old keys from their configs at their own pace

---

in summary:

I suspect an early PoC-style implementation decision on noise_sv2 is driving us to walk in circles.

I think we should just make noise_sv2 and sv2-apps capable of the deployment §4.8.2 of #234 describes, without lazy shortcuts.

[coleFD]

im not really sure what this solves in regards to the topic discussed. The issue is the client needs to know what key to use in the case of a rotation. Each of the three updates, may be improvements, but don't really address that.
4.8.1 - urges the server to sign certificates at a different time (the client knows nothing about this)
4.8.2 - urges servers to use offline signing (the client knows nothing about this)
4.8.3 - not exactly sure but still something on the server side that the client doesnt know about.

this is where the questions still lie:

"the rare authority rotation that still needs to happen (e.g.: staff turnover, or key compromise) should be handled by a parallel endpoint (as clarified on §4.8.4 of #234), or ideally via clients configured with MULTIPLE authority keys (as clarified on §4.8.5 of #234), which is the multi-key support SRI already agreed to take on."

[plebhash]

yeah, most of my comment above is about the server side: by generating static keys ephemerally, noise_sv2 is currently forcing the authority key into a hot place where it doesn't belong, which is what makes authority key rotation feel routine (instead of exceptional, as it was originally designed)

the client-side question is what §4.8.5 of #234 answers: the client is configured with a set of authority keys and accepts a certificate that verifies against any of them, so it never has to pick which key to use.

the operator publishes multiple keys beforehand, including backup keys (which are ideally stored separate from eachother, so they cannot be all compromised at once).

clients add them to their configs. and whenever the server switches, clients drop the old key with their next update (and potentially add new backup keys).

nothing on the wire changes and no client has to act at the moment of the switch.

[plebhash]

for extra context, here's the direction we're probably going to take SRI in case the proposed §4.8.5 lands on #234

clients like tProxy and JDC will have this field on their config.toml:

# for every server
[[upstreams]]
address = "75.119.150.111"
port = 3333

# a set with potentially multiple authority pubkeys
#
# the certificate is accepted if it verifies against ANY
# of them, in the same handshake (one extra signature check per extra key).
#
# this is NOT a sequential fallback: the client does not reconnect to retry
# with the next key, it just checks all of them.
#
# client operators add new keys here before the pool starts using them, and
# remove old ones once the pool stops using them.
#
# all of this is communicated out of band, via trusted channels.
authority_pubkeys = [
  "9auqWEzQDVyd2oe1JVGFLMLHZtCo2FFqZwtKA5gd9xbuEu7PH72",
  "9cB2iQ94uacCZawucSdFTejHgjqg1pRPubbVHu4TcivseMmJXha",
]

# rest of the config file
...

---

assuming §4.8.5 lands on #234, we're also going to try to steer the Sv2 community so that firmware and proxy UI all allow for this kind of UX

[plebhash]

Closing this. On a call today with @coleFD, Derrick, @GitGab19 and @bit-aloo it became clear this thread has been chasing the wrong proposal.

I opened it around a server→client message delivering a successor authority key in band, and that is what @TheBlueMatt's (a)/(b) rebuttal and the rest of the thread addressed.

What Cole actually wants is the alternative he posted on 2026-09-25 (#235 (reply in thread)): the client appends its configured authority key to the first handshake message, and the server answers with the certificate signed by that key. No key is learned in band, so the permanent-theft argument doesn't apply.

That is a change to the handshake itself, not an extension, so it needs its own proposal.