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

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 1 Oct 2021 12:00:02 -0700

This draft got some previous discussion on the WG list, but it's worth
having people take another look at it during last call.
In particular, note that it updates RFC 8446.

-Ben

On Fri, Oct 01, 2021 at 11:20:35AM -0700, The IESG wrote:
> 
> The IESG has received a request from the Common Authentication Technology
> Next Generation WG (kitten) to consider the following document: - 'Channel
> Bindings for TLS 1.3'
>   <draft-ietf-kitten-tls-channel-bindings-for-tls13-09.txt> as Proposed
>   Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2021-10-15. Exceptionally, comments may
> be sent to [email-masked] instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>    This document defines a channel binding type, tls-exporter, that is
>    compatible with TLS 1.3 in accordance with RFC 5056, On Channel
>    Binding.  Furthermore it updates the "default" channel binding to the
>    new binding for versions of TLS greater than 1.2.  This document
>    updates RFC5801, RFC5802, RFC5929, and RFC8446.
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/
> 
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 Oct 2021 15:49:08 -0700

I don't believe that this document should update 8446. As noted in S 1, we
didn't define these bindings because we didn't have complete analysis. This
document doesn't seem to either contain or reference such analysis and
until we have that, I think RFC 8446 shouldn't be retconned into endorsing
this construction.

-Ekr

On Fri, Oct 1, 2021 at 12:00 PM Benjamin Kaduk <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Rob Sayre <[email-masked]>
Date: Fri, 1 Oct 2021 16:01:35 -0700

On Fri, Oct 1, 2021 at 3:50 PM Eric Rescorla <[email-masked]> wrote:

> I don't believe that this document should update 8446.
>

Agree. This document should not update 8446.

thanks,
Rob

---

From: "Sam Whited" <[email-masked]>
Date: Fri, 01 Oct 2021 23:02:43 -0400

I have to respectfully disagree with this.

Anecdotally, RFCs are hard to discover. Having them linked from a
logical place in other RFCs is one way that discovery happens, and if
you're looking for how to do channel bindings with TLS the first place
you're going to look is the TLS RFC (and its list of updates).

Secondly, this is an update, not a retconn. It in no way implies that
TLS 1.3 always said this, or that the TLS 1.3 authors were involved in
the channel bindings spec. TLS 1.3 does an analysis of its own keying
material exporters and we rely on this and present a standard name for
one scenario where it may be used, this does not involve new technology
or even a novel use of EKM.

—Sam

On Fri, Oct 1, 2021, at 18:49, Eric Rescorla wrote:
> I don't believe that this document should update 8446. As noted in S
> 1, we didn't define these bindings because we didn't have complete
> analysis. This document doesn't seem to either contain or reference
> such analysis and until we have that, I think RFC 8446 shouldn't be
> retconned into endorsing this construction.
>
> -Ekr

---

From: Rob Sayre <[email-masked]>
Date: Fri, 1 Oct 2021 20:11:01 -0700

On Fri, Oct 1, 2021 at 8:04 PM Sam Whited <[email-masked]> wrote:

> Anecdotally, RFCs are hard to discover.

What do you mean, exactly, here?

Are you saying that this draft “update” 8446 in order for readers to
understand it and 8446 itself?

thanks,
Rob

Having them linked from a

---

From: "Sam Whited" <[email-masked]>
Date: Fri, 01 Oct 2021 23:18:02 -0400

No, I am saying that I have seen people implement custom solutions to
problems in an RFC because they don't realize that there is a related
RFC that fixes those problems (or suggests how to do whatever tangential
thing they needed to implement). Having a link in the related RFCs make
things easier to discover.

In this case, if I was someone wanting to, for example, implement
channel binding between TLS and some sort of authentication token so
that the token would not remain valid if the TLS session changed, I
would probably go to the TLS spec to see if such a thing exists. If that
spec doesn't contain the "Updated by" link, I don't think it's as likely
that I'd find that there was a standard way to do this.

—Sam

---

From: Rob Sayre <[email-masked]>
Date: Fri, 1 Oct 2021 20:32:12 -0700

On Fri, Oct 1, 2021 at 8:18 PM Sam Whited <[email-masked]> wrote:

> problems in an RFC

Makes sense a goal—I think the objection is more that updating 8446 on
paper here is presumptuous, since that document took orders of magnitude
more work.

That should not detract from the work in this new draft, but hopefully my
message at least makes the disagreement more clear.

thanks,
Rob

because they don't realize that there is a related

---

From: "Sam Whited" <[email-masked]>
Date: Fri, 01 Oct 2021 23:42:47 -0400

This is just a registration with IANA more than anything else; this
required almost no work compared to the many people and many years spent
on TLS. I don't believe marking this as an update implies any flaw in
TLS, or any presumption that this is somehow its equal in terms of
effort. This isn't a competition, it's just logically part of the same
ecosystem.

If we start thinking about one document referencing or updating another
as somehow being presumptuous or implying that we're trying to retcon
the other authors work I don't see the culture of the IETF ever becoming
a very inviting one. Similarly, if we decide that every document that
updates another document has to be its equal in terms of effort, no
documents will ever get updates until they are ready to be entirely
replaced. Lots of documents receive small updates, this is no different.

Would it make a difference if I added a section thanking the TLS authors
for their work and for including bits like EKM that make keying material
possible? I'd be happy to include such a section if it would make people
feel better about it.

—Sam

On Fri, Oct 1, 2021, at 23:32, Rob Sayre wrote:
> paper here is presumptuous, since that document took orders of
> magnitude more work.
>
> That should not detract from the work in this new draft, but hopefully
> my message at least makes the disagreement more clear.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 2 Oct 2021 10:10:57 -0700

> or even a novel use of EKM.

Well, perhaps it would be useful to step back for a moment from the
implications of "updates". We are currently preparing an 8446-bis.
What would you have that document say about this topic?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 2 Oct 2021 10:12:42 -0700

I want to be clear that I don't think this is about credit. My concern is
purely about accurately reflecting the level of confidence one should have
in this mechanism.

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Sat, 2 Oct 2021 10:19:19 -0700

> purely about accurately reflecting the level of confidence one should have

Yes, that is how I feel also (although my opinion matters much less here).
I think the document is a fine thing to try, though.

thanks,
Rob

---

From: "Sam Whited" <[email-masked]>
Date: Sat, 02 Oct 2021 21:29:11 -0400

Even if linking this in updates implied confidence (though I don't think
it does), TLS alread implies confidence in its own EKM mechanism. I
don't believe this document expands on that. For example, it does not
detail any particular use of channel binding.

—Sam

On Sat, Oct 2, 2021, at 13:12, Eric Rescorla wrote:
> I want to be clear that I don't think this is about credit. My concern
> is purely about accurately reflecting the level of confidence one
> should have in this mechanism.

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 3 Oct 2021 13:06:40 +0000

Perhaps adding text that says no security analysis has been done.

---

From: Sam Whited <[email-masked]>
Date: Sun, 03 Oct 2021 13:37:17 +0000

I'd be okay with that provided we can release an update if such an analysis is ever done?

Although this is such a low-stakes issue that I worry that the prejudicial value of such a statement far outweighs the security value. I don't feel strongly about it though.

—Sam

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 3 Oct 2021 12:02:07 -0700

Sorry to be difficult, but as I said, I'd prefer to focus not on the
question of the header of this document but rather on what we wish 8446
said. To that end, what text do you think should go in 8446-bis?

-Ekr

---

From: "Sam Whited" <[email-masked]>
Date: Sun, 03 Oct 2021 20:31:44 -0400

8446 currently contains:

> However, it is also possible to bind such connections to an external
> authentication mechanism via out-of-band validation of the server's
> public key, trust on first use, or a mechanism such as channel
> bindings (though the channel bindings described in [RFC5929] are not
> defined for TLS 1.3).

If I were part of the TLS group I'd want to see discussion of the the
parenthetical at the end being  replaced with something like:

"such as the bindings defined in <future RFC number>".

Then the parenthetical could be moved to the security considerations
section or similar (right now it's quite hard to find).

At the risk of veering into 8446 feedback, I have gotten a lot of push
back when I mentioned that the RFC5929 channel bindings weren't defined
for TLS 1.3 in the past, normally something along the lines of "that's
just one random throw-away sentence in the middle of the document, why
should I not implement this?"

That being said, I haven't really thought about this and don't know
whether this would be appropriate or not, I'm just trying to respond to
your query with some initial thoughts. None of this should be taken as
what I've been pushing for in the rest of this thread.

—Sam

On Sun, Oct 3, 2021, at 15:02, Eric Rescorla wrote:
> question of the header of this document but rather on what we wish
> 8446 said. To that end, what text do you think should go in 8446-bis?

---

From: Jonathan Hoyland <[email-masked]>
Date: Tue, 26 Oct 2021 17:32:25 +0100

Hi Sam, all,

I'd like to again raise the issues I pointed out in
https://mailarchive.ietf.org/arch/msg/kitten/13pPj4E3-gYwpbu2K844uI1BPoU/ .
This draft hasn't received enough security analysis, and further, I pointed
out a specific security issue that remains unaddressed.

Using the same label for different protocols produces trivial collisions,
and thus it is perfectly possible that a message meant for GSS-API is
identical in both form and key to a message for SCRAM, and thus there is
strong potential for confusion.
I'm not familiar with either of these protocols, so maybe they have
internal reasons why this example doesn't work, but that misses the much
larger and more significant point.
Any future protocol that uses the same label will potentially be
confusable, and further updates to GSS-API now must ensure that they don't
form valid SCRAM messages, and vice versa.

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.
Again, whether that is a specific problem for GSS-API is totally irrelevant.
Another protocol that uses this draft may well be vulnerable, and thus this
is just leaving a huge security landmine in TLS channel bindings.

At an absolute minimum this draft should include "A TLS session using this
RFC to produce a binding for any purpose MUST NOT generate more than one
per session. If a second exporter using this protocol is required the TLS
session MUST be rekeyed."

The correct solution would be to use unique labels for every different mode
and variant of SCRAM and GSS-API, and require this for all runs, and
further include a run number in the label derivation.
This string can be (should be) constructed mechanistically, and commit the
TLS client and TLS server to all relevant security parameters.

Another approach would be to use a fixed string to generate a channel
binding, use that in a run of GSS-API, and then call the Exporter API again
on the hash of the transcript and any relevant key material*.
Taking the resultant output and HKDFing it with the keys resulting from the
GSS-API run would give you a channel binding that is unique for every
unique run of GSS-API.
This is a much stronger binding, tying the specific run of the GSS-API back
to the TLS layer. The idea being that even in the case that the TLS
server's private key has been compromised, if the GSS-API run was secure
then the TLS layer was run honestly (i.e. is with the server.)

Regards,

Jonathan

* Specifically everything listed in Verified Contributive Channel Bindings
for Compound Authentication
<https://www.ndss-symposium.org/wp-content/uploads/2017/09/08_5.pdf>
Section II should be included.

---

From: "Ruslan N. Marchenko" <[email-masked]>
Date: Tue, 26 Oct 2021 21:58:07 +0200

Hi Jonathan,

Am Dienstag, dem 26.10.2021 um 17:32 +0100 schrieb Jonathan Hoyland:
> This draft hasn't received enough security analysis, and further, I
> pointed out a specific security issue that remains unaddressed.
> 
> Using the same label for different protocols produces trivial
> collisions, and thus it is perfectly possible that a message meant for
> GSS-API is identical in both form and key to a message for SCRAM, and
> thus there is strong potential for confusion.
> internal reasons why this example doesn't work, but that misses the
> much larger and more significant point. 
> confusable, and further updates to GSS-API now must ensure that they
> don't form valid SCRAM messages, and vice versa.
> 
> 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.
> Another protocol that uses this draft may well be vulnerable, and thus
> this is just leaving a huge security landmine in TLS channel bindings. 
> 
> At an absolute minimum this draft should include "A TLS session using
> this RFC to produce a binding for any purpose MUST NOT generate more
> than one per session. If a second exporter using this protocol is
> required the TLS session MUST be rekeyed."
> 
Can you please elaborate a bit more on this particular attack vector?
What exactly information it may leak/compromise and how?

The reason I'm asking is that application is the one glueing together
TLS and authentication sessions, however application does not always
have access to internals of either one(tls), or another(auth) or even
both. Therefore asking application to transfer context between
authentication and transport APIs may not always be feasible or even
possible.

Regards,
Ruslan

---

From: Jonathan Hoyland <[email-masked]>
Date: Wed, 27 Oct 2021 18:02:00 +0100

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.
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.
You just need to use different strings based on the configuration.
If keeping a counter of the number of calls to the API is really hard it
might be easier to just pick a big enough random number to make collisions
sufficiently unlikely.

Using the second approach lets you achieve a higher level of security, but
is perhaps overkill if you don't include attackers that can break TLS /
steal certificates in your threat model.
I totally accept that passing state between layers can be tricky, but if
you need the security then I think the correct solution is to design the
API carefully, rather than to implement something insecurely.
As it so happens implementing my second suggestion specifically doesn't
require any access to TLS internals.
The authentication session needs to make two calls to the `Exporter` API
but doesn't require anything more of the TLS connection.

Regards,

Jonathan

---

From: "Ruslan N. Marchenko" <[email-masked]>
Date: Wed, 27 Oct 2021 20:39:22 +0200

Hi Jonathan,

Am Mittwoch, dem 27.10.2021 um 18:02 +0100 schrieb Jonathan Hoyland:
> 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.
> 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.

> 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?

---

From: "Sam Whited" <[email-masked]>
Date: Wed, 27 Oct 2021 17:12:22 -0400

I've been trying to figure out exactly what you mean before replying and
have been struggling to do so, so I apologize if I'm misunderstanding
your emails, but I believe this isn't a problem unless you use the
channel binding itself as keying material for something. The I-D
specifically has a section where it says *not* to do that for this
reason. This is supposed to be a generic mechanism that lets you
invalidate a session or token if a TLS session changes, that's all. Any
further use of the CB value would have the problems you describe, and
therefore they are forbidden.

On the other hand, if an XMPP session's authn and some sort of authz
token are both using this CB mechanism and are bound to the same TLS
session that is not a problem. If the session changes they both would
become invalid. if it doesn't, they both remain valid and do not leak
any information about each other that wasn't already public.

I believe there is value in having a generic channel binding, even if
it's so generic that this means it can't be used as a secret value
itself. Maybe I'm misunderstanding what you're saying though?

—Sam

On Wed, Oct 27, 2021, at 13:02, Jonathan Hoyland wrote:
> 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.
>
> 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. 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.
>
> API call. You just need to use different strings based on the
> configuration. If keeping a counter of the number of calls to the API
> is really hard it might be easier to just pick a big enough random
> number to make collisions sufficiently unlikely.
>
> Using the second approach lets you achieve a higher level of security,
> but is perhaps overkill if you don't include attackers that can break
> TLS / steal certificates in your threat model. I totally accept that
> passing state between layers can be tricky, but if you need the
> security then I think the correct solution is to design the API
> carefully, rather than to implement something insecurely. As it so
> happens implementing my second suggestion specifically doesn't require
> any access to TLS internals. The authentication session needs to make
> two calls to the `Exporter` API but doesn't require anything more of
> the TLS connection.
>
> Regards,
>
> Jonathan
>
>
>
>
>
>
> On Tue, 26 Oct 2021 at 20:58, Ruslan N. Marchenko
> <[email-masked]> wrote:
>
>> Hi Jonathan,
>>
>> https://mailarchive.ietf.org/arch/msg/kitten/13pPj4E3-gYwpbu2K844uI1BPoU/
>> > . This draft hasn't received enough security analysis, and further,
>> >   I pointed out a specific security issue that remains unaddressed.
>> >
>> > collisions, and thus it is perfectly possible that a message meant
>> > for GSS-API is identical in both form and key to a message for
>> > SCRAM, and thus there is strong potential for confusion. I'm not
>> > familiar with either of these protocols, so maybe they have
>> > much larger and more significant point. Any future protocol that
>> > uses the same label will potentially be confusable, and further
>> > updates to GSS-API now must ensure that they don't form valid SCRAM
>> > messages, and vice versa.
>> >
>> > Again, whether that is a specific problem for GSS-API is totally
>> > irrelevant. Another protocol that uses this draft may well be
>> > vulnerable, and thus this is just leaving a huge security landmine
>> > in TLS channel bindings.
>> >
>> > At an absolute minimum this draft should include "A TLS session
>> > using this RFC to produce a binding for any purpose MUST NOT
>> > generate more than one per session. If a second exporter using this
>> > protocol is required the TLS session MUST be rekeyed."
>> >
>> Regards, Ruslan

-- 
Sam Whited

---

From: Jonathan Hoyland <[email-masked]>
Date: Thu, 28 Oct 2021 18:34:19 +0100

Hi Sam,

Please see my comments inline.

Regards,

Jonathan

On Wed, 27 Oct 2021 at 22:13, Sam Whited <[email-masked]> wrote:

> You are correct in as much as using a channel binding as a key directly
would be bad, one of the requirements of channel bindings in RFC 5056 is
that even if the binding itself is leaked the security of the protocol
shouldn't be undermined.
My assumption is that running GSS-API or SCRAM over TLS is supposed to
provide a security benefit over just running it over an unsecured
connection.
If you view a channel binding as simply the "name" of the TLS channel, and
are simply requiring that the client and server are using the same TLS
channel then the current design achieves that.
However, you lose most of the other security benefits of running the
protocols over TLS.
Specifically you can no longer assume that an honest server cannot be
tricked into producing messages it shouldn't i.e. becoming an oracle.

I was sloppy with my language in my earlier message, it's true that the
channel binding is not key material, it is material that is included in key
derivation to ensure independent runs of the protocol have independent key
spaces.
The idea IMO of using a channel binding is to have a one-to-one binding
between the lower protocol and the upper protocol such that the pair of
protocols together have a globally independent key space, i.e. that it is
impossible for an attacker to cause distinct pairs of runs of the protocols
to have cryptographically related keys.
Under the current designs, multiple runs of GSS-API over a single TLS
session would use related keys.
Not only this, SCRAM runs would _also_ produce related keys.

This is supposed to be a generic mechanism, so we need to consider
composability, i.e. how it works when run alongside other unknown
protocols.
The only global state we maintain across all protocols (at least IETF-wise)
is through IANA registries.
To ensure that runs of different protocols have independent keys we use
context strings, to ensure that runs are one-to-one we use either counters
or nonces.

> I don't think this is correct in general, although as I have mentioned, it
may be true for the current implementation of GSS-API / SCRAM, this is not
guaranteed to remain the case and doesn't account for future protocols and
updates to current ones, which is vital for generic mechanisms.
You have to guarantee that no future protocol will have the same message
format, or leak any information derived using the same keys.

> You are right, you can't use channel bindings (in this context) as secret
values (although channel bindings must be derived from secret values, which
is something I write about in excruciating detail in my thesis.)
Having a generic channel binding mechanism is great, I totally support
that, we just need to consider that a single TLS session may be used for
more than one thing, and that channel bindings should keep each of those
things separate.

—Sam

---

From: Jonathan Hoyland <[email-masked]>
Date: Thu, 28 Oct 2021 18:46:26 +0100

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.
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.)

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.

Regards,

Jonathan

On Wed, 27 Oct 2021 at 19:39, Ruslan N. Marchenko <[email-masked]>
wrote:

> > material.

---

From: Simo Sorce <[email-masked]>
Date: Fri, 29 Oct 2021 09:55:39 -0400

Hi Jonathan,

> sure that different protocols run in the same TLS session produce disjoint

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).

> (not to mention every other protocol past, present, and future that uses

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.

> 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.

> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

---

From: Sean Turner <[email-masked]>
Date: Sat, 30 Oct 2021 00:03:27 -0400

tl;dr: With the caveat that the text that might go in 8446bis is more important, I think kitten should probably follow tls’ lead here and not include the header.

The updates header has been the source of numerous debates for over a decade. It has been used to indicate critical normative updates, optional extensions, and what I would call “bread crumbs” to find related RFCs. In tls, we have probably used each of these [0]. But, the new normal is not including the updates header. RFC 8773, which is experimental, changes the behavior of TLS 1.3 to permit the server to send a CertificateRequest message when a PSK is being used and it did not get an updates header. draft-ietf-tls-subcerts is adding a mechanism to allow servers to use a delegated credential and it’s not got an updates header. EAP-TLS 1.3 doesn’t have an updates header.

I feel your pain about needing to get the word out, but I am not sure where it stops. If everybody wants a breadcrumb, the splash page for the RFC will be about 3 pages long as it references all of the RFCs that now refer to it and the I-Ds that do. Check out the lengthy list here:
https://datatracker.ietf.org/doc/rfc8446/referencedby/

Finally, even with the “liberal" policy back when TLS 1.2 was newer, the original tls-unique didn’t get an updates header.

If you really want bread crumbs, what I would do is find all the places tls-unique is used (https://datatracker.ietf.org/doc/rfc5929/referencedby/) in TLS 1.2 and make sure for the TLS 1.3 a reference to this I-D gets in. Sorry I just noticed this now, but top ‘o the list would be:
https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/
This I-D references possibly including an updated tls-unique mechanism for 1.3 (see s10.1) and is therefore ripe for a reference. I will note it is in the RFC editor’s queue awaiting publication but Ben can work magic.

spt

[0] The extreme case is probably where TLS 1.2 [RFC5246] is “updated" by an experimental RFC from the ISE stream.

> On Oct 2, 2021, at 21:29, Sam Whited <[email-masked]> wrote:
>