Re: [TLS] [kitten] Fwd: Last Call: (Channel Bindings for TLS 1.3) to Proposed Standard

[Jonathan Hoyland]

Hi Sam,

Please see my comments inline.

Regards,

Jonathan

On Wed, 27 Oct 2021 at 22:13, Sam Whited  wrote:

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


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


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?
>
> 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
>
> On Wed, Oct 27, 2021, at 13:02, Jonathan Hoyland wrote:
> > 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 e

Re: [TLS] Spec issue with RFC 7627 (EMS) and resumption

[David Benjamin]

It depends on what the server is trying to do. If the server is trying to
mandate EMS, aborting the connection is correct. E.g. the full handshake
section then says:

   If the server receives a ClientHello without the extension, it SHOULD
   abort the handshake if it does not wish to interoperate with legacy
   clients.

Though I suppose the abbreviated handshake version is missing a "if it does
not wish to interoperate with legacy clients". Yeah, okay, this probably
also needs an erratum to add the right qualifier. Gosh this document is
confusingly organized.

On Wed, Oct 27, 2021 at 4:55 AM Achim Kraus  wrote:

> Hi David,
>
> my question considers 2. ,
> if one peer uses RFC 7627 and the other not (legacy).
>
> Case 1:
> - client using RFC 7627, server not (legacy)
> -- client fallsback to full-handshakes
>
> Case 2:
> - server using RFC 7627, client not (legacy)
> -- if the client tries a resumption, the current definition is, that the
> server SHOULD abort.
>
> In my opinion in case 2, the server SHOULD also just fallback to a
> full-handshake. That's done by sending a ServerHello with a new Session
> ID and the other handshake messages of a full handshake.
> In the end, that prevents, that a client to have to execute a second,
> then full handshake, as fallback.
>
> best regards
> Achim
>
>
> Am 26.10.21 um 17:50 schrieb David Benjamin:
> > At least for an erratum, I don't think it makes sense to change that as
> > part of this.
> >
> > I think your question is conflating a few things. Let me try to untangle
> > this, as this document is little confusing. It seems to be describing,
> > via SHOULDs and MUSTs, three different implementation profiles
> concurrently:
> > 1. A client or server that negotiates EMS when available, but continues
> > to be compatible with legacy peers, resumption and all.
> > 2. A client or server that negotiates EMS when available, continues to
> > be compatible with legacy peers, but only allows full handshakes with
> > them. I forget how 3SHAKE worked, but I vaguely recall that cutting out
> > legacy resumptions avoided a source of issues
> > 3. A client or server that requires EMS on all connections, and is not
> > compatible with legacy peers at all. This way you can rely on the EMS
> > bugfix being applied.
> >
> > Because these are all interleaved, it's a very hard to tell what bits
> > correspond to this profile and what bits correspond to EMS itself. I
> > think this was overambitious. Anything but (1) was implausible for most
> > deployments in 2016, because EMS only just started existing. I expect it
> > is still implausible for most, though I don't have metrics for the web.
> > Hence, if we were completely redoing this document (probably not worth
> > it?), I think it should be reorganized. :-)
> >
> > Now, as to your question, I don't believe this is right:
> >
> >  > If the client follows this guide, it falls-back to use a full
> handshake.
> >  > If the client doesn't follow this (maybe, the client is not aware of
> RFC
> >  > 7627), the server SHOULD aborts.
> >
> > The client SHOULD you are referring to is for a client that implements
> > (2). If a client does not follow this, it implements (1). The server
> > SHOULD, however, says "If neither the original session /nor the new
> > ClientHello/ uses the extension, the server SHOULD abort the handshake."
> > That clause doesn't apply to the client SHOULD in the first place
> > because, whether the client is (1) or (2), the ClientHello will signal
> EMS.
> >
> > It does apply to legacy clients that do not implement EMS at all.
> > Whether the server continues, does a full handshake, or aborts depends
> > on whether the server wants to do (1), (2), or (3). Yes, if it picks (3)
> > and aborts, the server will not interoperate with a legacy client. That
> > is exactly what those servers would want. It is odd that the text only
> > describes (1) and (3) for the server in this case, not (2). But adding
> > (2) in without a rework will only make this complicated situation worse,
> > so I do not propose to address it as part of this fix.
> >
> > On Tue, Oct 26, 2021 at 1:05 AM Achim Kraus  > > wrote:
> >
> > Hi David,
> >
> > if you're on it, maybe it's worth to consider my question from
> January
> > 2021 as well.
> >
> >   > If the client follows this guide, it falls-back to use a full
> > handshake.
> >   > If the client doesn't follow this (maybe, the client is not
> > aware of RFC
> > 7627), the server SHOULD aborts.
> >
> >   > Why SHOULD the server not (also) just fall-back to use a full
> > handshake?
> >
> > For more details see:
> >
> >
> https://mailarchive.ietf.org/arch/msg/tls/gjBFHWwp1k-w1KdBkotp496zaf8/
> > <
> https://mailarchive.ietf.org/arch/msg/tls/gjBFHWwp1k-w1KdBkotp496zaf8/>
> >
> > best regards
> > Achim Kraus
> >
> > Am 26.10.21 um 00:51 schrieb David Benjamin:
> >  > Here's some possible replacement text

Re: [TLS] [kitten] Fwd: Last Call: (Channel Bindings for TLS 1.3) to Proposed Standard

[Jonathan Hoyland]

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 
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?
>
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Spec issue with RFC 7627 (EMS) and resumption

[Achim Kraus]

Hi David,

I'm still not sure, if there is just a misunderstanding:

For me, case 2, the support of legacy peers comes with using only
full-handshakes, and no abbreviated handshakes.

For the client the consequence is, to use full-handshakes with legacy
servers.

So, I would assume, that just the same applies for servers as well.

If a legacy client tries to execute a resumption handshake, the server
in mode 2 has two options to support such a legacy client according the
general rule to only use "full-handshakes" and not "abbreviated" ones.

- abort the client initiated abbreviated handshake in order to make the
client restart with a full-handshake (that's what the RFC defines)
- the server chose to fallback to a full-handshake directly in the same
way, that the server would do, if no matching session id is available.

https://datatracker.ietf.org/doc/html/rfc5246#page-36

"The client sends a ClientHello using the Session ID of the session to
be resumed.  The server then checks its session cache for a match.
...
If a Session ID match is not
found, the server generates a new session ID, and the TLS client and
server perform a full handshake."

With such a fallback by the server, the general rule, to only use
"full-handshakes", will be also full filled. And the benefit would be,
that the client doesn't need to send a second handshake.

best regards
Achim Kraus


Am 28.10.21 um 19:44 schrieb David Benjamin:

It depends on what the server is trying to do. If the server is trying
to mandate EMS, aborting the connection is correct. E.g. the full
handshake section then says:

    If the server receives a ClientHello without the extension, it SHOULD
    abort the handshake if it does not wish to interoperate with legacy
    clients.

Though I suppose the abbreviated handshake version is missing a "if it
does not wish to interoperate with legacy clients". Yeah, okay, this
probably also needs an erratum to add the right qualifier. Gosh this
document is confusingly organized.



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls