Subject: Re: [TLS] [kitten] Fwd: Last Call: <draft-ietf-kitten-tls-channel-bindings-for-tls13-09.txt> (Channel Bindings for TLS 1.3) to Proposed Standard

From: Jonathan Hoyland <[email-masked]>
Date: Fri, 5 Nov 2021 15:34:00 +0000

Hi Simo,

As I said in my email to Sam, my language here was sloppy, I meant that the
channel binding is included in the key derivation process, and thus the
output keys will be related to each other.
The term channel bindings has two different meanings using in very similar
contexts, which leads to great confusion and is why I prefer the term
compound authentication (see Chapter 4.4 of my thesis)
<https://pure.royalholloway.ac.uk/portal/files/33074422/2018HoylandJGPhD.pdf>.

A channel binding is a "name" of a channel as you say, but it is also used
to mean using one channel to authenticate another.
Very specifically if channel `a` is bound to channel `b` then that means
that if channel `b` is securely authenticated then channel `a` was formed
honestly (i.e. even if all of the long term key material for channel `a`
has been leaked, I can be sure that my channel `a` peer is the same actor
as my channel `b` peer.)

Channel bindings that aren't bound to a specific session are less secure
than ones that are, so yes, you can use them, but that doesn't mean they
have the security properties you need.
The purpose of binding a protocol to an underlying TLS session is to
leverage some of the security guarantees offered by the TLS layer.
If those guarantees are never necessary because the over-the-top protocol
is always perfectly secure, just run the protocol on the wire and drop the
TLS complication.
If those guarantees are at least sometimes necessary then you need to
securely bind the two channels together.

Channel binding does more than simply guarantee that the messages were the
same, it also guarantees that the identity of the actors at each layer
remains the same, and that the keys derived in each layer match.
With an appropriately designed channel binding you can use TLS's protection
against MITM attacks to protect insecure protocols run over the top.
Having now looked at SCRAM a little bit, using the TLS channel binding
guarantees that some malicious server isn't passing the client's messages
off to another server and performing a malicious authentication there.
Using a unique string from SCRAM means that messages from some other
protocol won't be compatible.
If you don't require a unique string I could write a new protocol SCRAM++
with cross-compatible messages, but different security guarantees, and use
that to compromise SCRAM clients.
Obviously that's a patently malicious example, but it's perfectly possible
that some new version of SCRAM produces messages that an old version of
SCRAM misinterprets.
It's even highly likely that a server that supports old versions of SCRAM
for backwards compatibility would use the same key material for all
versions.

Requiring a unique string makes the messages totally unrelated.

I don't find the arguments "It's always been insecure in the past" or "We
have bad APIs" especially compelling.

Regards,

Jonathan

On Fri, 29 Oct 2021 at 14:55, Simo Sorce <[email-masked]> wrote:

> Hi Jonathan,
>
> On Thu, 2021-10-28 at 18:46 +0100, Jonathan Hoyland wrote:
> > Hi Ruslan,
> >
> > Yes, two distinct TLS connections having the same exporter key would be
> > really bad, but I'm specifically talking about two runs of some protocol
> > bound to a single TLS session.
> > A single TLS session will return the same key (modulo rekeying,
> resumption
> > etc.) if you call the Exporter API with the same label.
> > This means that the channel bindings it produces, which will then be used
> > to derive the keys of the higher layer protocol, will produce related
> keys.
> >
> > The key reason for making the binding retrieval context-specific is to
> make
> > sure that different protocols run in the same TLS session produce
> disjoint
> > keys.
>
> Note, Channel Bindings are *not* a key and should never used as such,
> so I think you are using a false premise here.
> Channel Bindings are, at most, a unique value associated with a session
> (keep in mind that often Channel Bindings do not even bind to a
> specific session, see 'tls-server-end-point' which is used in
> preference in many cases within HTTPS endpoints because of the way
> server termination is built in some scalable architectures).
>
> > When someone tries to copy a message from a SCRAM handshake into some
> > GSS-API run on a single TLS connection I want to be sure that it will be
> > rejected, without having to understand exactly how every version of SCRAM
> > and GSS-API ever (including ones that will be drafted in the future)
> works
> > (not to mention every other protocol past, present, and future that uses
> > the same string.)
>
> Both SCRAM and GSS-API are authentication mechanisms that use shared
> keys for authentication. Both protocols are inherently resistant to
> message swapping because the chances of producing a message on one
> protocol that can be successfully decrypted/HMACed on the other are
> astronomically low (they must be or the protocols are broken).
>
> Channel bindings are just a way to tie those authentications to the
> specific channel used underneath. I can't see how using the same value
> for both protocols can lead to any compromise (see again 'tls-server-
> end-point', where there isn't even a "same" channel guarantee, or
> previous CBs where the binding was done to an IP address or other clear
> text session value).
>
> If passing an arbitrary channel binding values could suddenly (and
> predictably?) allow one protocol to be swapped for the other or have
> one protocol generate derived session keys that are usable with the
> other, it would mean those authentication mechanisms (SCRAM,GSS-
> API,...) are completely broken, as that would mean the keys and
> derivations used in those protocols are not providing the necessary
> security guarantees.
>
> > In the same way that we include strings in the TLS key schedule to ensure
> > that handshake messages can't be confused with each other or with earlier
> > versions of TLS, or even with Exported Authenticators, or MLS, or any
> other
> > protocol that uses keys, we should use channel bindings to separate
> > protocols run over the top of TLS.
>
> Yes, this is done because those messages are not further confounded
> with additional private keys, but the situation is substantially
> different when you talk about authentication mechanism that already use
> additional key material, key derivation and random challenges.
>
> HTH,
> Simo.
>
> > Regards,
> >
> > Jonathan
> >
> > On Wed, 27 Oct 2021 at 19:39, Ruslan N. Marchenko <[email-masked]>
> > wrote:
> >
> > > Hi Jonathan,
> > >
> > > Am Mittwoch, dem 27.10.2021 um 18:02 +0100 schrieb Jonathan Hoyland:
> > > > Hi Ruslan,
> > > >
> > > > Without digging into the guts of GSS-API and SCRAM I can't give you a
> > > > concrete attack, the issue is that all our assumptions about protocol
> > > > security assume that different protocols use totally separate key
> > > > material.
> > > > For example if I have one protocol that signs arbitrary blobs and
> > > > another that requires me to sign a challenge to prove I know a
> private
> > > > key then even if they're both perfectly secure on their own they are
> > > > totally broken in composition.
> > > > This separation of keys is one of the core reasons for the use of
> > > > HKDFs, it lets us take some source randomness and use it to generate
> > > > independent keys.
> > > >
> > > > Designing a channel binding that explicitly suggests people use the
> > > > same key material for different things is bad practice and poor
> > > > protocol design.
> > > > Pretty much every attack is on the table if you have multiple
> protocols
> > > > using the same keys, message forgery, improper authentication, key
> > > > leakage, etc.
> > > > The reason for separation of keys is to simply rule out this entire
> > > > class of vulnerability.
> > >
> > > Sorry maybe I'm missing something but why would two unrelated protocols
> > > have same key? The binding is derived from TLS session key, if two
> > > unrelated TLS sessions are having the same key this is the problem by
> > > itself, and binding material is not amplifying it, just falling to the
> > > same problem bucket. And if they are related (eg resumed) then protocol
> > > muxing should perhaps be part of applicaiton stack and it should still
> > > be happy with a common security context.
> > >
> > > > If you don't separate the keys then whenever you make any change to
> any
> > > > protocol you have to consider its security in composition with every
> > > > other protocol, including ones that you don't know about or that
> > > > haven't been written yet.
> > > >
> > > > Using different labels for different purposes shouldn't require
> > > > anything complicated, as it's just changing the input literals to the
> > > > API call.
> > > >
> > > There's a difference in telling TLS stack "give me binding of that
> > > type" - which is pretty much high level abstract call, and asking TLS
> > > to perform key derivation (export) for specific label - which requires
> > > speaking native TLS implementation api. Now that we have a bunch of TLS
> > > implementations and several abstractions and all other binding types
> > > are independent of the higher protocol - it may be challenging changing
> > > the API to make the binding retrieval context-specific. Not that it is
> > > impossible to make such change, but why?
> > >
> > >
> > >
> > >
> > _______________________________________________
> > Kitten mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/kitten
>
> --
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc
>
>
>
>
>

---

From: "Ruslan N. Marchenko" <[email-masked]>
Date: Sat, 06 Nov 2021 00:01:34 +0100

Hi Jonathan,

Am Freitag, dem 05.11.2021 um 15:34 +0000 schrieb Jonathan Hoyland:
> 
> Having now looked at SCRAM a little bit, using the TLS channel
> binding guarantees that some malicious server isn't passing the
> client's messages off to another server and performing a malicious
> authentication there.
> ...
> If you don't require a unique string I could write a new protocol
> SCRAM++ with cross-compatible messages, but different security
> guarantees, and use that to compromise SCRAM clients. 
> Obviously that's a patently malicious example, but it's perfectly
> possible that some new version of SCRAM produces messages that an old
> version of SCRAM misinterprets. 
Authentication method and SCRAM mechanism negotiation must happen
before SCRAM exchange. if parties don't agree on the method/mechanism
negotiation fails. If you control the server to the level that you
negotate one method/mechanism but use another - you're not mitm, you
just _pwn_ the service, and no binding in the world would solve that.
> It's even highly likely that a server that supports old versions of
> SCRAM for backwards compatibility would use the same key material for
> all versions. 
> 
> I don't find the arguments "It's always been insecure in the past" or
> "We have bad APIs" especially compelling. 
> 
It's not "historically insecure", it's just not a secret key by design.
It's public (non-secret) but unique and imutable property of the TLS
channel (not application/authentication channel, mind you). Finished
packet - is not a secret - any sneaky person can snoop it. Certificate
digest - is not a secret, any person in the world can get it. It's not
a guardian of the confidentiality, rather a warrant of integrity.

Regards,
Ruslan

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 8 Nov 2021 11:58:36 +0000

Hi Jonathan,

On 05/11/2021 15:34, Jonathan Hoyland wrote:
> Hi Simo,
>
> As I said in my email to Sam, my language here was sloppy, I meant 
> that the channel binding is included in the key derivation process, 
> and thus the output keys will be related to each other.
> The term channel bindings has two different meanings using in very 
> similar contexts, which leads to great confusion and is why I prefer 
> the term compound authentication (see Chapter 4.4 of my thesis) 
> A channel binding is a "name" of a channel as you say, but it is also 
> used to mean using one channel to authenticate another.
> Very specifically if channel `a` is bound to channel `b` then that 
> means that if channel `b` is securely authenticated then channel `a` 
> was formed honestly (i.e. even if all of the long term key material 
> for channel `a` has been leaked, I can be sure that my channel `a` 
> peer is the same actor as my channel `b` peer.)
>
> Channel bindings that aren't bound to a specific session are less 
> secure than ones that are, so yes, you can use them, but that doesn't 
> mean they have the security properties you need.
> If those guarantees are never necessary because the over-the-top 
> protocol is always perfectly secure, just run the protocol on the wire 
> and drop the TLS complication.
> Channel binding does more than simply guarantee that the messages were 
> the same, it also guarantees that the identity of the actors at each 
> layer remains the same, and that the keys derived in each layer match.
> With an appropriately designed channel binding you can use TLS's 
> protection against MITM attacks to protect insecure protocols run over 
> the top.
> guarantees that some malicious server isn't passing the client's 
> messages off to another server and performing a malicious 
> authentication there.

I've been reading this exchange and I still struggle to understand what 
do you think the issue is. But more importantly, what are the possible 
fixes? If you can propose specific modifications to how 
draft-ietf-kitten-tls-channel-bindings-for-tls13 should be constructing 
channel binding for TLS 1.3, then maybe we can make some progress on this.

Best Regards,

Alexey

> On Fri, 29 Oct 2021 at 14:55, Simo Sorce <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Jonathan,
>
>     > to derive the keys of the higher layer protocol, will produce
>     related keys.
>     >
>     > The key reason for making the binding retrieval context-specific
>     is to make
>     > sure that different protocols run in the same TLS session
>     produce disjoint
>     > keys.
>
>     > and GSS-API ever (including ones that will be drafted in the
>     future) works
>     > versions of TLS, or even with Exported Authenticators, or MLS,
>     or any other
>     > On Wed, 27 Oct 2021 at 19:39, Ruslan N. Marchenko
>     <[email-masked] <mailto:[email-masked]>>
>     > wrote:
>     >
>     > > Hi Jonathan,
>     > >
>     > > > another that requires me to sign a challenge to prove I know
>     a private
>     > > > Pretty much every attack is on the table if you have
>     multiple protocols
>     > > > If you don't separate the keys then whenever you make any
>     change to any
>     > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/kitten>
>
>     -- 
>     Simo Sorce
>     RHEL Crypto Team
>     Red Hat, Inc
>
>
>
>
>
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 08 Nov 2021 23:47:59 +0100

Jonathan Hoyland <[email-masked]> writes:

> and GSS-API ever (including ones that will be drafted in the future) works

If I understand you correctly, this behaviour was a design choice of
SCRAM (and indirectly GS2) -- it was designed so that SCRAM native in
SASL would produce the same tokens as SCRAM used via GSS-API, for the
same TLS session.  Whether that was a wise decision remains to be seen,
but I don't think it will come as a surprise for anyone, nor is there
any publicly documented attack based on this property that I am aware
of.

/Simon

---

From: Dave Cridland <[email-masked]>
Date: Tue, 9 Nov 2021 12:59:58 +0000

On Tue, 26 Oct 2021 at 17:33, Jonathan Hoyland
<[email-masked]> wrote:
> There isn't even a one-to-one relationship between GSS-API / SCRAM runs. This channel binding design doesn't protect against messages being swapped between two GSS-API runs on a single TLS connection.

As I understand your case, you're suggesting that if the same channel
binding is used on multiple authentication runs within the same TLS
session, there may be cases where this may result in weakening of the
bound authentication.

It is not clear to me that this is the case. The channel binding data
is known to both parties of the TLS session for the duration of the
TLS session, so it doesn't seem likely that reusing it could actually
cause problems here.

Most SASL or GSS-API based protocols do not allow multiple
authentications within a single connection, and therefore TLS session,
but there are exceptions.

I think the exceptions are:
* IMAP with draft-newman-imap-unauth - a three year old I-D not
published as an RFC.
* LDAP (and X.500 DAP) both allow multiple consecutive binds.

The suggestion you propose in the quote above is that a single message
could be replayed within one TLS session.

Replay resistance is generally baked into SASL and GSS-API mechanisms,
rather than the channel binding itself. This includes, for example,
SCRAM - replaying one of the messages would result in a failed
authentication whether or not TLS channel binding were to be used.
Some mechanisms are replayable - PLAIN being one - but these both
assume that the TLS session remains confidential, and also they do not
include channel binding information anyway. But there are SASL
mechanisms that have been proposed in the past that do not provide
replay resistance but do include a TLS channel binding. In these
cases, then, your attack is possible and hinges on the reuse of a TLS
channel binding.

The result would be that - on some IMAP and LDAP servers - an
authenticated user could reauthenticate as themselves.

Now, all this does assume that an attacker cannot break a TLS session
during the duration of a TLS session; that is, that we assume TLS
sessions maintain confidentiality, integrity, and authenticity during
the session at least. If this is not the case, then it's game over
anyway, on a number of levels, and your proposed attack (which, I
reiterate, is entirely unproven) makes no difference.

What we do not assume however is that the certificate remains
sacrosanct during this. Again, SASL mechanisms often (and again, this
includes SCRAM) handle their own mutual authentication, so not only
does the client authenticate to the server but the server has to prove
its identity to the client. Assuming ephemeral keying, then, an
attacker compromising the server's certificate doesn't actually make
as much difference as you'd think here. At this point I'm reaching the
edges of my knowledge, but I believe that although the identity as
authenticated by the server's certificate could be spoofed if the
certificate were compromised, ephemeral keying would still protect the
session and SASL mutual authentication would still authenticate the
server later.

Overall, therefore, I have to ask you to find some kind of concrete
attack. "Reusing an exported key within the same TLS session" does not
appear to form the core of an attack as you suggest.

Dave.

---

From: Jonathan Hoyland <[email-masked]>
Date: Tue, 9 Nov 2021 16:01:11 +0000

Hi All,

My specific solution is to simply include a *different* fixed string for
each variant of SCRAM and GSS-API, and ideally a nonce.
Given that applications will have to update their stacks anyway to
accommodate the new fixed string in the current proposal I don't see that
as a hugely difficult proposition.

The goal of labels in material that is used to derive keys (yes, material
that is used to derive keys is necessarily secret, yes material derived
from keys is not necessarily secret), is to exclude classes of attack.
It is good protocol design.

One of the things use of a TLS channel binding gives you is protection for
the upper level protocol against TLS being MITMed.
Using a fixed string for multiple protocols probably gives you that
protection (assuming the channel binding is correctly agreed by both sides).

Using a distinct channel binding, even if the upper level protocol is not
secure, means that if both sides agree on the channel binding they agree on
the intent of the upper layer protocol, i.e. it gives you some level
assurance that the client and server agree on what was intended.
This eliminates classes of attack such as message confusion.
Adding this protection costs virtually nothing, given that you are
_already_ commiting to updating this section of code (no code currently
makes this specific call to the TLS-Exporter interface).
Leaving it out means that people like me who do formal analysis can't
reasonably analyse these designs.
I build models of protocols and prove they meet certain properties.
The only way to keep that analysis viable (we're already talking hundreds
of hours of work) is to eliminate classes of attack wholesale.
Yes, you can add unique and clever protections into every sub-protocol, but
it makes formally proving anything about the security exponentially harder
(and yes, I mean that in the literal / mathematical sense).

Regards,

Jonathan

On Tue, 9 Nov 2021 at 13:00, Dave Cridland <[email-masked]> wrote:

> > There isn't even a one-to-one relationship between GSS-API / SCRAM runs.
> This channel binding design doesn't protect against messages being swapped
> between two GSS-API runs on a single TLS connection.
>

---

From: Dave Cridland <[email-masked]>
Date: Tue, 9 Nov 2021 16:13:01 +0000

On Tue, 9 Nov 2021 at 16:01, Jonathan Hoyland
<[email-masked]> wrote:
>
> Hi All,
>
> My specific solution is to simply include a different fixed string for each variant of SCRAM and GSS-API, and ideally a nonce.

I think you may mean SASL and GSS-API, but more probably I think you
need to decide what it is you mean.

SCRAM *already* includes a nonce in its hash calculations. Your
proposal is to include another, to avoid an unspecified attack.

> Given that applications will have to update their stacks anyway to accommodate the new fixed string in the current proposal I don't see that as a hugely difficult proposition.
>
> The goal of labels in material that is used to derive keys (yes, material that is used to derive keys is necessarily secret, yes material derived from keys is not necessarily secret), is to exclude classes of attack.
> One of the things use of a TLS channel binding gives you is protection for the upper level protocol against TLS being MITMed.
> Using a fixed string for multiple protocols probably gives you that protection (assuming the channel binding is correctly agreed by both sides).
>
> Using a distinct channel binding, even if the upper level protocol is not secure, means that if both sides agree on the channel binding they agree on the intent of the upper layer protocol, i.e. it gives you some level assurance that the client and server agree on what was intended.
> Adding this protection costs virtually nothing, given that you are _already_ commiting to updating this section of code (no code currently makes this specific call to the TLS-Exporter interface).
> Leaving it out means that people like me who do formal analysis can't reasonably analyse these designs.
> The only way to keep that analysis viable (we're already talking hundreds of hours of work) is to eliminate classes of attack wholesale.
> Yes, you can add unique and clever protections into every sub-protocol, but it makes formally proving anything about the security exponentially harder (and yes, I mean that in the literal / mathematical sense).

SASL (and GSS-API) are pluggable authentication systems which means
that if you want a formal proof (or even just a finger-in-the-air
back-of-the-envelope one) you have to do it against a specific SASL
(or GSS-API) mechanism.

Without knowing the mechanism, it's impossible to perform a formal
proof, because you don't know how the channel binding is exchanged and
proven, and so you would be missing an absolutely crucial part of your
model.

Dave.

---

From: Jonathan Hoyland <[email-masked]>
Date: Tue, 9 Nov 2021 18:03:30 +0000

Hi Dave,

On Tue, 9 Nov 2021 at 16:13, Dave Cridland <[email-masked]> wrote:

> > My specific solution is to simply include a different fixed string for
I meant what I wrote.

> proposal is to include another, to avoid an unspecified attack.
Firstly, the proposal under question is *NOT* just for SCRAM, it is for an
arbitrary number of unspecified protocols. And the nonce is to prevent
messages being moved between runs of an upper level protocol over a single
TLS channel.

> > The goal of labels in material that is used to derive keys (yes,
> material that is used to derive keys is necessarily secret, yes material
> derived from keys is not necessarily secret), is to exclude classes of
> attack.
> > One of the things use of a TLS channel binding gives you is protection
> for the upper level protocol against TLS being MITMed.
> > Using a distinct channel binding, even if the upper level protocol is
> not secure, means that if both sides agree on the channel binding they
> agree on the intent of the upper layer protocol, i.e. it gives you some
> level assurance that the client and server agree on what was intended.
> > The only way to keep that analysis viable (we're already talking
> hundreds of hours of work) is to eliminate classes of attack wholesale.
> > Yes, you can add unique and clever protections into every sub-protocol,
> but it makes formally proving anything about the security exponentially
> harder (and yes, I mean that in the literal / mathematical sense).
>

That's correct. If you want to do a proof you have to do it against a
specific mechanism.
The problem is that the analysis has to include all sources of protocol
messages from the same key space (yes, again. I know that channel bindings
are not keys. Yes I know that channel bindings are not required to be
secret.)
With the draft as proposed that is an arbitrary number of protocols,
including any that may be written in future.
Even if you managed to do some huge analysis of anything that falls into
this space, it would immediately be invalidated the moment any new version
or design came along.

> proven, and so you would be missing an absolutely crucial part of your
Firstly, even without knowing the mechanism there are lots of things we can
prove or that we assume.
For example, I assume that an attacker cannot decrypt messages for which it
does not have the key.
Most formal analysis is based on a fairly small set of assumptions and
standard proofs.
One key assumption is that different protocols use unrelated keys. (Yes,
again. I know that channel bindings are not keys. Yes I know that channel
bindings are not required to be secret.)
If you include channel bindings in your key derivation then you cannot
assume that the keys are unrelated.

Now it's totally possible to prove your protocol is universally composable
irrespective of channel bindings, but if you're proving that you might as
well just drop the TLS layer.

Second: The issue isn't about picking a specific mechanism, the issue is
that I can't ignore other mechanisms.

Regards,

Jonathan

---

From: "Ruslan N. Marchenko" <[email-masked]>
Date: Tue, 09 Nov 2021 19:16:41 +0100

Hi Jonathan,

Am Dienstag, dem 09.11.2021 um 16:01 +0000 schrieb Jonathan Hoyland:
> not secure, means that if both sides agree on the channel binding
> they agree on the intent of the upper layer protocol, i.e. it gives
> you some level assurance that the client and server agree on what was
> intended.
The binding is just that, a binding. Insecure protocols will remain
insecure but that still does not compromise secure protocols because
they can still bind securely app session to tls session. And again,
revealing binding data is not a leak/security breach.

> _already_ commiting to updating this section of code (no code
> currently makes this specific call to the TLS-Exporter interface).
Actually it is already implemented in GnuTLS and GIO-TLS. Introducing
context specific label will require changing API to accept input
context (do something) while now it is simle property retrieval (get
something). Moreover it will stay aside from existing binding interface
which is still "get property".

> hundreds of hours of work) is to eliminate classes of attack
There's still no demonstration or even hint of the attack as of now,
therefore I still do not see a justification to change API except "it
is a right thing to do". But I repeat again - it can be done, if there
is a reason for that.

Regards,
RUslan

---

From: "Sam Whited" <[email-masked]>
Date: Tue, 09 Nov 2021 20:26:08 -0500

I'm still struggling to figure out what the exact problem is you're
describing or if you have an actual class of attack in mind that might
be possible due to this, but the following in your previous email jumped
out at me:

> assume that the keys are unrelated.

Is this the crux of the issue you're pointing out? If so, I'd say surely
you need to do a formal analysis of a specific key derivation mechanism
instead of the data being mixed into it, and you can't (and shouldn't)
worry about all future mechanisms.

If a key derivation mechanism is so weak that mixing in the same
arbitrary string to two keys results in related keys that can be
correlated or attacked, this is a weakness in the key derivation
function and not something that can be solved by adding more
randomness to every possible set of bytes that could ever be hashed
into those keys.

In other words: keys should be unpredictable and not leak data used to
derive them; if they do, the data is not at fault.

—Sam