Subject: [Unbearable] ramifications of longer EKMs

From: Brian Campbell <[email-masked]>
Date: Wed, 22 Feb 2017 14:52:58 -0700

Shortly after Seoul TBPROTO-11 "Clarified that other signature schemes may
require longer exporter output
<https://github.com/TokenBinding/Internet-Drafts/commit/cac99f7c9337f32c8573c878878d4da7f9eeb186>",
which generally seems like a good thing in terms of facilitating
cryptographic agility going forward (i.e. a super-duper signature scheme
might need to sign over a longer EKM to realize its super-duperness).

However, that future TokenBindingKeyParameters type might use a longer EKM
has some ramifications when a TokenBindingMessage has more than one
TokenBinding that maybe weren't fully considered. A server has to parse the
TokenBindingMessage and look at the TokenBindingKeyParameters of each
TokenBinding in order to know the length of the EKM to use in validating
the signature on each. And possibly have to get two (or more) different EKM
values to service a single TokenBindingMessage or request. This situation
only occurs when a referred_token_binding is sent but that's a valid case
that needs to be handled and the server can't really know if it's there
without parsing the message. So rather than getting the EKM based on the
negotiated key parameters type, the whole TokenBindingMessage needs to
effectively be preprocessed.

It's certainly possible to do things that way but it seems potentially
error prone (especially given that all the currently defined
TokenBindingKeyParameters use 32 byte EKMs so there's likely an
ossification effect) and less than ideal.

It's even less ideal for the model that's proposed in HTTPS Token Binding
and TLS Terminating Reverse Proxies
<https://tools.ietf.org/html/draft-campbell-tokbind-tls-term-00> because
the TLS Terminating Reverse Proxy (TTRP), which we are trying to keep as
"dumb" as possible, has to process the TokenBindingMessage to know the
length of the EKM(s) that it will pass along in the Token-Binding-Context
header/message. The Token-Binding-Context message also would need to be
updated to allow for more than one EKM value. That feels rather ugly and
somewhat undermines the effort to keep as much TB related processing out of
the TTRP as possible.

Thoughts on this?

Seems to me like there are a few options,

1) Leave it as it is and suck up the complexity on the server side and in
the TTRP spec.

2) Leave it as it is and suck up the complexity on the server side but
change the model of the TTRP spec to do token binding validation and
processing in the TTRP and pass just validated TokenBindingIDs (or
something) to the back-end/origin server

3) Go back to TB only ever using 32 byte EKM values, which isn't as crypto
agile but will likely be good enough for a long long time

4) Change things so that the EKM length used for all the TokenBindings in a
single TokenBindingMessage is determined by the negotiated key parameters
type. This simplifies things considerably while still providing some
agility. The downside is not getting the benefits of a longer EKM when a
referred would use it but the provided doesn't. Which doesn't seem that bad
actually.

5) Something else and/or I'm confused and made a mistake in thinking about
this whole issue.

---

From: Andrei Popov <[email-masked]>
Date: Wed, 22 Feb 2017 23:32:23 +0000

The WG decided that the negotiated TB key parameters (specifically, signature scheme), rather than TB version, determine the size of the EKM. This means that a “dumb” (or “slim”?) TTRP supporting TB vX does not guarantee compatibility with all TB key types that may be defined (perhaps, after the TTRP ships) for TB vX.

Ø  It's even less ideal for the model that's proposed in HTTPS Token Binding and TLS Terminating Reverse Proxies<https://tools.ietf.org/html/draft-campbell-tokbind-tls-term-00> because the TLS Terminating Reverse Proxy (TTRP), which we are trying to keep as "dumb" as possible, has to process the TokenBindingMessage to know the length of the EKM(s) that it will pass along in the Token-Binding-Context header/message.
Parsing TB messages at TTRP is not necessary: the TTRP could pass along all EKM lengths it supports (at the cost of extra bytes on the wire). Even then, a new signature scheme can be defined requiring an EKM length that is not supported by the TTRP.

My preferred option is 3), where TB v 1.0 will only ever use 32-byte EKM values. Future TB versions may define some other EKM(s).
I could live with option 1) as well, but then I would be reluctant to negotiate those TB key parameters that require a different EKM length (for TB v 1.0). Which effectively turns option 1) into option 3) ☺.
Option 2) does not make sense to me, because TTRP can’t realistically require one particular model of TB processing in a datacenter (as there is little reason for a datacenter operator to comply).
Option 4) defeats the purpose of having per-signature-scheme EKM lengths. If we don’t care for per-signature-scheme EKM lengths, then we should go with 3).

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Wednesday, February 22, 2017 1:53 PM
To: IETF Tokbind WG <[email-masked]>
Subject: [Unbearable] ramifications of longer EKMs

Shortly after Seoul TBPROTO-11 "Clarified that other signature schemes may require longer exporter output<https://github.com/TokenBinding/Internet-Drafts/commit/cac99f7c9337f32c8573c878878d4da7f9eeb186>", which generally seems like a good thing in terms of facilitating cryptographic agility going forward (i.e. a super-duper signature scheme might need to sign over a longer EKM to realize its super-duperness).

However, that future TokenBindingKeyParameters type might use a longer EKM has some ramifications when a TokenBindingMessage has more than one TokenBinding that maybe weren't fully considered. A server has to parse the TokenBindingMessage and look at the TokenBindingKeyParameters of each TokenBinding in order to know the length of the EKM to use in validating the signature on each. And possibly have to get two (or more) different EKM values to service a single TokenBindingMessage or request. This situation only occurs when a referred_token_binding is sent but that's a valid case that needs to be handled and the server can't really know if it's there without parsing the message. So rather than getting the EKM based on the negotiated key parameters type, the whole TokenBindingMessage needs to effectively be preprocessed.
It's certainly possible to do things that way but it seems potentially error prone (especially given that all the currently defined TokenBindingKeyParameters use 32 byte EKMs so there's likely an ossification effect) and less than ideal.
It's even less ideal for the model that's proposed in HTTPS Token Binding and TLS Terminating Reverse Proxies<https://tools.ietf.org/html/draft-campbell-tokbind-tls-term-00> because the TLS Terminating Reverse Proxy (TTRP), which we are trying to keep as "dumb" as possible, has to process the TokenBindingMessage to know the length of the EKM(s) that it will pass along in the Token-Binding-Context header/message. The Token-Binding-Context message also would need to be updated to allow for more than one EKM value. That feels rather ugly and somewhat undermines the effort to keep as much TB related processing out of the TTRP as possible.
Thoughts on this?
Seems to me like there are a few options,
1) Leave it as it is and suck up the complexity on the server side and in the TTRP spec.

2) Leave it as it is and suck up the complexity on the server side but change the model of the TTRP spec to do token binding validation and processing in the TTRP and pass just validated TokenBindingIDs (or something) to the back-end/origin server
3) Go back to TB only ever using 32 byte EKM values, which isn't as crypto agile but will likely be good enough for a long long time
4) Change things so that the EKM length used for all the TokenBindings in a single TokenBindingMessage is determined by the negotiated key parameters type. This simplifies things considerably while still providing some agility. The downside is not getting the benefits of a longer EKM when a referred would use it but the provided doesn't. Which doesn't seem that bad actually.
5) Something else and/or I'm confused and made a mistake in thinking about this whole issue.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 22 Feb 2017 17:08:57 -0700

>
> The WG decided that the negotiated TB key parameters (specifically,
> signature scheme), rather than TB version, determine the size of the EKM.
> This means that a “dumb” (or “slim”?) TTRP supporting TB vX does not
> guarantee compatibility with all TB key types that may be defined (perhaps,
> after the TTRP ships) for TB vX.
>

That's true. And matching up supported TB key parameters will likely be a
challenge for the currently proposed TTRP support model regardless.

Parsing TB messages at TTRP is not necessary: the TTRP could pass along all
> EKM lengths it supports (at the cost of extra bytes on the wire). Even
> then, a new signature scheme can be defined requiring an EKM length that is
> not supported by the TTRP.
>

That's a good point and an approach I hadn't considered. Allows for the
TTRP stay similarly "dumb"/"slim".  The extra bytes cost is not ideal and
it's feels a little ugly. But would probably be better than the parsing
approach I was thinking of.

>
>
> My preferred option is 3), where TB v 1.0 will only ever use 32-byte EKM
> values. Future TB versions may define some other EKM(s).
>
> I could live with option 1) as well, but then I would be reluctant to
> negotiate those TB key parameters that require a different EKM length (for
> TB v 1.0). Which effectively turns option 1) into option 3) J.
>

I don't know that it would necessarily turn option 1) into option 3) but I
can see and concede the point.

> Option 2) does not make sense to me, because TTRP can’t realistically
> require one particular model of TB processing in a datacenter (as there is
> little reason for a datacenter operator to comply).
>

I'm not sure I follow this?

I'd think, if this kind of model was used, a TTRP could do all the TB
validation work and just expose the TB ID(s) to the backend where they can
bind to whatever tokens/cookies they are issuing. The backend apps would
only be able to use TB key parameters that the TTRP supports but that's
pretty much true of the other model too - the TTRP still is the one
negotiating.

> Option 4) defeats the purpose of having per-signature-scheme EKM lengths.
> If we don’t care for per-signature-scheme EKM lengths, then we should go
> with 3).
>

It only defeats the purpose of having per-signature-scheme EKM lengths in
the case of a refereed TB using a longer EKM than the provided. Which
should be a much less common occurrence and something that would dissipate
over time as the new TB key parameters type gets adopted/deployed.

On Wed, Feb 22, 2017 at 4:32 PM, Andrei Popov <[email-masked]>
wrote:

> The WG decided that the negotiated TB key parameters (specifically,
> signature scheme), rather than TB version, determine the size of the EKM.
> This means that a “dumb” (or “slim”?) TTRP supporting TB vX does not
> guarantee compatibility with all TB key types that may be defined (perhaps,
> after the TTRP ships) for TB vX.
>
>
>
> Ø  It's even less ideal for the model that's proposed in HTTPS Token
> Binding and TLS Terminating Reverse Proxies
> header/message.
> Parsing TB messages at TTRP is not necessary: the TTRP could pass along
> all EKM lengths it supports (at the cost of extra bytes on the wire). Even
> then, a new signature scheme can be defined requiring an EKM length that is
> not supported by the TTRP.
>
>
>
> My preferred option is 3), where TB v 1.0 will only ever use 32-byte EKM
> values. Future TB versions may define some other EKM(s).
>
> I could live with option 1) as well, but then I would be reluctant to
> negotiate those TB key parameters that require a different EKM length (for
> TB v 1.0). Which effectively turns option 1) into option 3) J.
>
> Option 2) does not make sense to me, because TTRP can’t realistically
> require one particular model of TB processing in a datacenter (as there is
> little reason for a datacenter operator to comply).
>
> Option 4) defeats the purpose of having per-signature-scheme EKM lengths.
> If we don’t care for per-signature-scheme EKM lengths, then we should go
> with 3).
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
>
>
> *From:* Unbearable [mailto:[email-masked]] *On Behalf Of *Brian
> Campbell
> *Sent:* Wednesday, February 22, 2017 1:53 PM
> *To:* IETF Tokbind WG <[email-masked]>
> *Subject:* [Unbearable] ramifications of longer EKMs
>
>
>
> Shortly after Seoul TBPROTO-11 "Clarified that other signature schemes
> may require longer exporter output
> 4) Change things so that the EKM length used for all the TokenBindings in
> a single TokenBindingMessage is determined by the negotiated key parameters

---

From: Andrei Popov <[email-masked]>
Date: Thu, 23 Feb 2017 00:39:08 +0000

Ø  I'm not sure I follow this?

Ø  I'd think, if this kind of model was used, a TTRP could do all the TB validation work and just expose the TB ID(s) to the backend where they can bind to whatever tokens/cookies they are issuing.
Sure, this design would work. My point is that the tokbind-tls-term document cannot require one particular model of TB processing, because if this one model does not meet a data center’s requirements/architecture, the document is easily ignored. And it would be particularly undesirable to lose the “dumb/slim” TTRP model.

Ø  The backend apps would only be able to use TB key parameters that the TTRP supports but that's pretty much true of the other model too - the TTRP still is the one negotiating.
Backend could pass the TB key parameters to the TTRP, or these could be part of the TTRP configuration. All the “dumb/slim” TTRP needs to know is TB protocol version and a prioritized list of TB key parameter IDs.

Ø  It only defeats the purpose of having per-signature-scheme EKM lengths in the case of a refereed TB using a longer EKM than the provided.
Let’s say a client negotiates signature scheme A with the RP, and signature scheme A calls for a 64-bit EKM. Then the client negotiates a signature scheme B with the IDP, and signature scheme B calls for a 32-bit EKM. The client sends Provided and Referred bindings to this IDP, and the Referred binding uses signature scheme A in combination with an EKM length 32 (which does not agree with the signature scheme definition). Is this what you’re proposing as option 4), or did I get it wrong?

---

From: Andrei Popov <[email-masked]>
Date: Thu, 23 Feb 2017 01:03:59 +0000

Correction inline☺.

From: Unbearable [mailto:[email-masked]] On Behalf Of Andrei Popov
Sent: Wednesday, February 22, 2017 4:39 PM
To: Brian Campbell <[email-masked]>
Cc: IETF Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] ramifications of longer EKMs

Ø  It only defeats the purpose of having per-signature-scheme EKM lengths in the case of a refereed TB using a longer EKM than the provided.
Let’s say a client negotiates signature scheme A with the RP, and signature scheme A calls for a 64-byte EKM. Then the client negotiates a signature scheme B with the IDP, and signature scheme B calls for a 32-byte EKM. The client sends Provided and Referred bindings to this IDP, and the Referred binding uses signature scheme A in combination with an EKM length 32 (which does not agree with the signature scheme definition). Is this what you’re proposing as option 4), or did I get it wrong?

---

From: Brian Campbell <[email-masked]>
Date: Thu, 23 Feb 2017 06:18:08 -0700

>
> Sure, this design would work. My point is that the tokbind-tls-term
> document cannot require one particular model of TB processing, because if
> this one model does not meet a data center’s requirements/architecture, the
> document is easily ignored. And it would be particularly undesirable to
> lose the “dumb/slim” TTRP model.
>

Are you suggesting that tokbind-tls-term should have more than one model?
Or that the “dumb/slim” TTRP model is most likely to be the desired model?

Backend could pass the TB key parameters to the TTRP, or these could be
> part of the TTRP configuration. All the “dumb/slim” TTRP needs to know is
> TB protocol version and a prioritized list of TB key parameter IDs.
>
Sure, that prioritized list of TB key parameter IDs is still the TTRP
'supporting' them in that it will use them in negotiation.

The TB key parameter IDs the TTRP is willing/able to use will need to be
the intersection of the supported TB key parameters of each of the
backends. This might be cumbersome in some cases but is just the way it has
to be for the “dumb/slim” TTRP model.

Let’s say a client negotiates signature scheme A with the RP, and signature
> scheme A calls for a 64-byte EKM. Then the client negotiates a signature
> scheme B with the IDP, and signature scheme B calls for a 32-byte EKM.
> The client sends Provided and Referred bindings to this IDP, and the
> Referred binding uses signature scheme A in combination with an EKM length
> 32 (which does not agree with the signature scheme definition). Is this
> what you’re proposing as option 4), or did I get it wrong?
>
Yes, that's an accurate description of what I'd proposed as option 4)

On Wed, Feb 22, 2017 at 6:03 PM, Andrei Popov <[email-masked]>
wrote:

> Correction inlineJ.
>
>
>
> *From:* Unbearable [mailto:[email-masked]] *On Behalf Of *Andrei
> Popov
> *Sent:* Wednesday, February 22, 2017 4:39 PM
> *To:* Brian Campbell <[email-masked]>
> *Cc:* IETF Tokbind WG <[email-masked]>
> *Subject:* Re: [Unbearable] ramifications of longer EKMs
>
>
>
> Ø  I'd think, if this kind of model was used, a TTRP could do all the TB
> bind to whatever tokens/cookies they are issuing.
>
> Sure, this design would work. My point is that the tokbind-tls-term
> document cannot require one particular model of TB processing, because if
> this one model does not meet a data center’s requirements/architecture, the
> document is easily ignored. And it would be particularly undesirable to
> lose the “dumb/slim” TTRP model.
>
> Ø  The backend apps would only be able to use TB key parameters that the
> TTRP supports but that's pretty much true of the other model too - the TTRP
> still is the one negotiating.
>
> Backend could pass the TB key parameters to the TTRP, or these could be
> part of the TTRP configuration. All the “dumb/slim” TTRP needs to know is
> TB protocol version and a prioritized list of TB key parameter IDs.
>
> Ø  It only defeats the purpose of having per-signature-scheme EKM lengths
> in the case of a refereed TB using a longer EKM than the provided.
>
> Let’s say a client negotiates signature scheme A with the RP, and
> signature scheme A calls for a 64-byte EKM. Then the client negotiates a
> signature scheme B with the IDP, and signature scheme B calls for a 32-
> byte EKM. The client sends Provided and Referred bindings to this IDP,
> and the Referred binding uses signature scheme A in combination with an EKM
> length 32 (which does not agree with the signature scheme definition). Is
> this what you’re proposing as option 4), or did I get it wrong?
>

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 23 Feb 2017 17:53:46 +0000

I’m not sure the value of standardizing the tokbind-tls-term, not sure how much interoperability requirements there are here, maybe this should be an experimental until we figure out if there is a need and if so what are the requirements

From: Unbearable [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Thursday, February 23, 2017 5:18 AM
To: Andrei Popov <[email-masked]>
Cc: IETF Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] ramifications of longer EKMs

Are you suggesting that tokbind-tls-term should have more than one model? Or that the “dumb/slim” TTRP model is most likely to be the desired model?
Backend could pass the TB key parameters to the TTRP, or these could be part of the TTRP configuration. All the “dumb/slim” TTRP needs to know is TB protocol version and a prioritized list of TB key parameter IDs.
Sure, that prioritized list of TB key parameter IDs is still the TTRP 'supporting' them in that it will use them in negotiation.
The TB key parameter IDs the TTRP is willing/able to use will need to be the intersection of the supported TB key parameters of each of the backends. This might be cumbersome in some cases but is just the way it has to be for the “dumb/slim” TTRP model.

On Wed, Feb 22, 2017 at 6:03 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
Correction inline☺.

From: Unbearable [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andrei Popov
Sent: Wednesday, February 22, 2017 4:39 PM
To: Brian Campbell <[email-masked]<mailto:[email-masked]>>
Cc: IETF Tokbind WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] ramifications of longer EKMs

>  I'd think, if this kind of model was used, a TTRP could do all the TB validation work and just expose the TB ID(s) to the backend where they can bind to whatever tokens/cookies they are issuing.

>  The backend apps would only be able to use TB key parameters that the TTRP supports but that's pretty much true of the other model too - the TTRP still is the one negotiating.

>  It only defeats the purpose of having per-signature-scheme EKM lengths in the case of a refereed TB using a longer EKM than the provided.

---

From: Andrei Popov <[email-masked]>
Date: Thu, 23 Feb 2017 20:13:44 +0000

Ø  Are you suggesting that tokbind-tls-term should have more than one model?
Alternatively, we may end up with more than one tokbind-tls-term☺.

Ø  Or that the “dumb/slim” TTRP model is most likely to be the desired model?
It seems undesirable to prevent “dumb/slim” TTRPs, regardless of what tokbind-tls-term ends up saying.

Ø  Yes, that's an accurate description of what I'd proposed as option 4)
Then what we have in option 4) is an IDP that supports a subset, rather than superset, of its RP’s TB key parameters. Which is a known type of misconfiguration that can happen between the IDP and RPs.
In any case, the TB key parameters negotiation would not be very robust if we say that a given signature scheme really requires a 64-byte EKM, but may also be used with a 32-byte EKM if the binding is Referred…

From: Brian Campbell [mailto:[email-masked]]

---

From: Andrei Popov <[email-masked]>
Date: Thu, 23 Feb 2017 21:00:49 +0000

Tokbind-tls-term does not necessarily have to be on the standards track, but I think the issue Brian has raised deserves discussion regardless of the destiny of tokbind-tls-term.

WRT Brian’s listed options, I prefer 3) or, failing that, 1).
Option 2) affects the tokbind-tls-term document, not the core I-Ds; from the core I-D perspective it is identical to option 1).
Option 4) makes the TB key parameter negotiation less definitive. It says that the length of the EKM now depends not only on the signature scheme of the TB key that signs this EKM, but also on the type of the Binding, and on the signature scheme of a different, unrelated TB key.

Cheers,

Andrei

From: Anthony Nadalin
Sent: Thursday, February 23, 2017 9:54 AM
To: Brian Campbell <[email-masked]>; Andrei Popov <[email-masked]>
Cc: IETF Tokbind WG <[email-masked]>
Subject: RE: [Unbearable] ramifications of longer EKMs

---

From: Brian Campbell <[email-masked]>
Date: Thu, 23 Feb 2017 16:49:03 -0700

>
> Then what we have in option 4) is an IDP that supports a subset, rather
> than superset, of its RP’s TB key parameters. Which is a known type of
> misconfiguration that can happen between the IDP and RPs.
>

I wouldn't characterize it as misconfiguration but rather just different
domains supporting different sets of TB key params. And could happen even
if the sets were the same but prioritized differently.

> In any case, the TB key parameters negotiation would not be very robust if
> we say that a given signature scheme really requires a 64-byte EKM, but may
> also be used with a 32-byte EKM if the binding is Referred…

The negotiation is only for the TB key parameters for the provided binding.
I'm just suggesting that the EKM length choice for the whole TB message
could be tied to that.  It seemed like an okay simplification at what felt
like a low cost of signing over less data in the case of the referred TB
otherwise using a longer EKM.  You don't seem to see it as okay though and
there's yet to be any other opinions expressed on it. So I can let that
idea go.

On Thu, Feb 23, 2017 at 1:13 PM, Andrei Popov <[email-masked]>
wrote:

> Alternatively, we may end up with more than one tokbind-tls-termJ.
>
>
>
> Then what we have in option 4) is an IDP that supports a subset, rather
> than superset, of its RP’s TB key parameters. Which is a known type of
> misconfiguration that can happen between the IDP and RPs.
>
> In any case, the TB key parameters negotiation would not be very robust if
> we say that a given signature scheme really requires a 64-byte EKM, but may
> also be used with a 32-byte EKM if the binding is Referred…
>
>
>
> *From:* Brian Campbell [mailto:[email-masked]]
> *Sent:* Thursday, February 23, 2017 5:18 AM
> *To:* Andrei Popov <[email-masked]>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 23 Feb 2017 16:59:26 -0700

Thanks Andrei.

I admit to having had some fondness for option 4). But I guess, at this
point, I'd lean towards 3) as well. It simplifies the TTRP case as well as
server processing logic (assuming the logic would be generalized to
accommodate future TB key params with a longer EKM).

On Thu, Feb 23, 2017 at 2:00 PM, Andrei Popov <[email-masked]>
wrote:

> Tokbind-tls-term does not necessarily have to be on the standards track,
> but I think the issue Brian has raised deserves discussion regardless of
> the destiny of tokbind-tls-term.
>
>
>
> Option 2) affects the tokbind-tls-term document, not the core I-Ds; from
> the core I-D perspective it is identical to option 1).
>
> Option 4) makes the TB key parameter negotiation less definitive. It says
> that the length of the EKM now depends not only on the signature scheme of
> the TB key that signs this EKM, but also on the type of the Binding, and on
> the signature scheme of a different, unrelated TB key.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Anthony Nadalin
> *Sent:* Thursday, February 23, 2017 9:54 AM
> *To:* Brian Campbell <[email-masked]>; Andrei Popov <
> [email-masked]>
> *Subject:* RE: [Unbearable] ramifications of longer EKMs
>
>
>
> I’m not sure the value of standardizing the tokbind-tls-term, not sure how
> much interoperability requirements there are here, maybe this should be an
> experimental until we figure out if there is a need and if so what are the
> requirements
>
>
>
>
>

---

From: Andrei Popov <[email-masked]>
Date: Fri, 24 Feb 2017 00:07:27 +0000

Ø  I wouldn't characterize it as misconfiguration but rather just different domains supporting different sets of TB key params.
An RP negotiating TB key parameters that the corresponding IDP does not support makes it impossible for the IDP to bind the token, therefore I think of it as a misconfiguration. Unfortunately, RPs are limited in their TB options by their IDP’s capabilities…

Ø  And could happen even if the sets were the same but prioritized differently.
If the TB key parameter sets are the same, but prioritized differently, then there is no problem: the IDP can handle the EKM length required by the signature scheme used in the Referred binding, correct? I think the issue only exists when the IDP does not support the signature scheme that an RP negotiates.

Ø  But I guess, at this point, I'd lean towards 3) as well. It simplifies the TTRP case as well as server processing logic (assuming the logic would be generalized to accommodate future TB key params with a longer EKM).
Great. Let’s see if someone else cares one way or another. This would be a trivial change to make, following WGLC…

---

From: John Bradley <[email-masked]>
Date: Thu, 23 Feb 2017 22:00:18 -0300

I think in the federated case having the IDP support the same or a superset of the RP algorithms is not unreasonable.  
It might be worth reminding people in a implementation note to have logging for unsupported alg ekm size errors so that when a RP updates before the server it is easier to figure out what happened.
RP implementations should also allow disabling algs to allow for IDP servers to be updated first.

The idea of always using the EKM size negotiated for the provided Token binding seems like people are more likely to get that wrong in the clients by having multiple possible EKM size per alg.

It might be simpler for the server, but  if it supports the alg it will support the EKM size, so I don’t think it is a big advantage for the server. 

It may have advantages for the reverse proxy processing.

John B.
> On Feb 23, 2017, at 9:07 PM, Andrei Popov <[email-masked]> wrote:
> 
> _______________________________________________
> Unbearable mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/unbearable <https://www.ietf.org/mailman/listinfo/unbearable>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 24 Feb 2017 08:21:04 -0700

>
> If the TB key parameter sets are the same, but prioritized differently,
> then there is no problem: the IDP can handle the EKM length required by the
> signature scheme used in the Referred binding, correct? I think the issue
> only exists when the IDP does not support the signature scheme that an RP
> negotiates.

Yes, in that case the IDP can handle the EKM length required by the
signature scheme used in the referred TB. When an IDP doesn't support a
signature scheme that an RP negotiates, the IDP won't be able to validate
the Referred TB. That's the case regardless of EKM length. Sorry, maybe
I've been unclear about my concern or have gotten sidetracked in the
discussion.  My concern is about the consequences of a single TB message
needing two different EKM values in order to be validated. It's certainly
possible for a server to do it but it's a bit more cumbersome and may
necessitate exporting key materail twice in processing a single request.
And it's really awkward and likely less efficient for the TTRP case because
the header message being passed to the backend needs to allow for multiple
EKM values and either have all possible EKM lengths based on supported key
params (as you'd suggested) or the TTRP evaluating the TB message to
determine the EKM lengths needed for the given request.

On Thu, Feb 23, 2017 at 5:07 PM, Andrei Popov <[email-masked]>
wrote:

> Ø  I wouldn't characterize it as misconfiguration but rather just
> different domains supporting different sets of TB key params.
>
> An RP negotiating TB key parameters that the corresponding IDP does not
> support makes it impossible for the IDP to bind the token, therefore I
> think of it as a misconfiguration. Unfortunately, RPs are limited in their
> TB options by their IDP’s capabilities…
>
>
>
> If the TB key parameter sets are the same, but prioritized differently,
> then there is no problem: the IDP can handle the EKM length required by the
> signature scheme used in the Referred binding, correct? I think the issue
> only exists when the IDP does not support the signature scheme that an RP
> negotiates.
>
>
>
> Ø  But I guess, at this point, I'd lean towards 3) as well. It simplifies
> the TTRP case as well as server processing logic (assuming the logic would
> be generalized to accommodate future TB key params with a longer EKM).
>

---

From: John Bradley <[email-masked]>
Date: Fri, 24 Feb 2017 13:30:47 -0300

The communication between the TTRP and the backend is generally inside a datacenter.  I don't think bandwidth is a big issue if you export all the EKM that the TTRP supports.  
It is a bit more work for the TTRP but it avoids processing the actual TB header.  

Is your concern that for servers it would be better / more efficient to only use a single EKM size?  
I don’t know if that is true if there is more than one EKM size in play then the lower level of the stack with the EKM exporter will need to know what size to produce based on the negotiated alg anyway.

I suspect that the lower level TLS exporter will just produce multiple EKM one for each supported alg and pass those on to whatever is doing the token binding.

If we went nuts and decided to introduce RFC7748 based Curve 448 signing (you know someone will ask).  Given that has a bit strength of ~224 bits vs P256 and RSA 2048 that are ~112 bits someone will wat to double the size of the nonce (I personally suspect that 256 bits as we have it would be just fine for Curve 448) so we double the EKM to 64 bytes.  How would people implement that.

We would defiantly stick with 32 bytes for Curve 25519.  I don’t think anyone in there right mind is going to propose RSA 4096.

So I personally find the need to have a EKM larger than the current 256 bits a touch hypothetical.   If someone could point me to a good reason I would like to know.

But for the sake of alg agility how would people deal with it?

John B.

> On Feb 24, 2017, at 12:21 PM, Brian Campbell <[email-masked]> wrote:
> 
> Yes, in that case the IDP can handle the EKM length required by the signature scheme used in the referred TB. When an IDP doesn't support a signature scheme that an RP negotiates, the IDP won't be able to validate the Referred TB. That's the case regardless of EKM length. Sorry, maybe I've been unclear about my concern or have gotten sidetracked in the discussion.  My concern is about the consequences of a single TB message needing two different EKM values in order to be validated. It's certainly possible for a server to do it but it's a bit more cumbersome and may necessitate exporting key materail twice in processing a single request. And it's really awkward and likely less efficient for the TTRP case because the header message being passed to the backend needs to allow for multiple EKM values and either have all possible EKM lengths based on supported key params (as you'd suggested) or the TTRP evaluating the TB message to determine the EKM lengths needed for the given request.    
>  
>  
> 
> On Thu, Feb 23, 2017 at 5:07 PM, Andrei Popov <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable

---

From: Brian Campbell <[email-masked]>
Date: Fri, 24 Feb 2017 09:33:16 -0700

>
> I think in the federated case having the IDP support the same or a
> superset of the RP algorithms is not unreasonable.
> It might be worth reminding people in a implementation note to have
> logging for unsupported alg ekm size errors so that when a RP updates
> before the server it is easier to figure out what happened.

I think that stuff is generally relevant and applicable regardless of EKM
size. It's just the nature of the protocol supporting different algorithms.
EKM size is just another piece of it.

>
> The idea of always using the EKM size negotiated for the provided Token
> binding seems like people are more likely to get that wrong in the clients
> by having multiple possible EKM size per alg.
>

Maybe. I suspect most or all implementations are currently using a 32 byte
EKM with no regard for the alg. I guess likelihood for getting things wrong
depends on perspective.  And I was looking at it from the perspective of
updating an implementation that only ever used 32 byte EKM to something
that's aware of alg dependent lengths.

It might be simpler for the server, but  if it supports the alg it will
> support the EKM size, so I don’t think it is a big advantage for the
> server.
>

Yeah, it'd be a simplification for the server but not a big one.

> It may have advantages for the reverse proxy processing.

Yes.

On Thu, Feb 23, 2017 at 6:00 PM, John Bradley <[email-masked]> wrote:

> I think in the federated case having the IDP support the same or a
> superset of the RP algorithms is not unreasonable.
> It might be worth reminding people in a implementation note to have
> logging for unsupported alg ekm size errors so that when a RP updates
> before the server it is easier to figure out what happened.
> The idea of always using the EKM size negotiated for the provided Token
> binding seems like people are more likely to get that wrong in the clients
> by having multiple possible EKM size per alg.
>
> It might be simpler for the server, but  if it supports the alg it will
> support the EKM size, so I don’t think it is a big advantage for the
> server.
>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 24 Feb 2017 10:07:56 -0700

>
> The communication between the TTRP and the backend is generally inside a
> datacenter.  I don't think bandwidth is a big issue if you export all the
> EKM that the TTRP supports.

Yeah, bandwidth probably isn't a big issue. So maybe not such a concern.
Sending all supported EKM lengths all the time just strikes me as an
unwarranted inefficiency. But maybe it's not so bad. And anything other
than 32 bytes is only theoretical at this point anyway.

> It is a bit more work for the TTRP but it avoids processing the actual TB

That's true and keeping it so a TTRP does not process the actual TB header
seems like a good thing to maintain.

Is your concern that for servers it would be better / more efficient to
> only use a single EKM size?
> I don’t know if that is true if there is more than one EKM size in play
> then the lower level of the stack with the EKM exporter will need to know
> what size to produce based on the negotiated alg anyway.
>

The negotiated alg only tells you about the provided TB. So the server
would either have to process the TB message to see if there are other
(refereed) bindings and what size EKM they'd need or get all possible EKM
sizes up front.

>
> I suspect that the lower level TLS exporter will just produce multiple EKM
> one for each supported alg and pass those on to whatever is doing the token
> binding.
>

That may well be how things end up. I'd been thinking about it as looking
at the negotiated alg and then asking for the appropriate EKM based on
that. Which works for the provided but not referred.

>
> If we went nuts and decided to introduce RFC7748 based Curve 448 signing
> (you know someone will ask).  Given that has a bit strength of ~224 bits vs
> P256 and RSA 2048 that are ~112 bits someone will wat to double the size of
> the nonce (I personally suspect that 256 bits as we have it would be just
> fine for Curve 448) so we double the EKM to 64 bytes.  How would people
> implement that.
>
> We would defiantly stick with 32 bytes for Curve 25519.  I don’t think
> anyone in there right mind is going to propose RSA 4096.
>
> So I personally find the need to have a EKM larger than the current 256
> bits a touch hypothetical.   If someone could point me to a good reason I
> would like to know.
>

I honestly don't know the relationship between the bit strength of the
signature alg and the length of the signing input needed to maintain that
strength. Needing to sign over more than 256 bits does seem a a touch
hypothetical. But I have nothing to back that up beyond a general
guess/feeling.

> But for the sake of alg agility how would people deal with it?

I guess that's kind of the heart of the question.

On Fri, Feb 24, 2017 at 9:30 AM, John Bradley <[email-masked]> wrote:

> The communication between the TTRP and the backend is generally inside a
> datacenter.  I don't think bandwidth is a big issue if you export all the
> EKM that the TTRP supports.
> I don’t know if that is true if there is more than one EKM size in play
> then the lower level of the stack with the EKM exporter will need to know
> what size to produce based on the negotiated alg anyway.
>
> I suspect that the lower level TLS exporter will just produce multiple EKM
> one for each supported alg and pass those on to whatever is doing the token
> binding.
>
> If we went nuts and decided to introduce RFC7748 based Curve 448 signing
> (you know someone will ask).  Given that has a bit strength of ~224 bits vs
> P256 and RSA 2048 that are ~112 bits someone will wat to double the size of
> the nonce (I personally suspect that 256 bits as we have it would be just
> fine for Curve 448) so we double the EKM to 64 bytes.  How would people
> implement that.
>
> We would defiantly stick with 32 bytes for Curve 25519.  I don’t think
> anyone in there right mind is going to propose RSA 4096.
>
> So I personally find the need to have a EKM larger than the current 256
> bits a touch hypothetical.   If someone could point me to a good reason I
> would like to know.
>
>> Ø  But I guess, at this point, I'd lean towards 3) as well. It
>> simplifies the TTRP case as well as server processing logic (assuming the
>> logic would be generalized to accommodate future TB key params with a
>> longer EKM).
>>
>> Great. Let’s see if someone else cares one way or another. This would be
>> a trivial change to make, following WGLC…
>>
>

---

From: Andrei Popov <[email-masked]>
Date: Fri, 24 Feb 2017 17:44:15 +0000

Ø  But for the sake of alg agility how would people deal with it?

Brian’s option 3): We go back to saying that the TB protocol version defines the EKM size. Once a new signature scheme is proposed that requires a longer EKM, we’ll need to define TB v 1.1 with, e.g., a 64-byte EKM.

Brian’s option 1): We stick with the signature scheme defining EKM size. Once a new signature scheme is proposed that requires a longer EKM, there is no need to define a new TB protocol version. However, operators willing to deploy this new signature scheme will need to ensure that their infrastructure supports the new signature scheme and EKM size. Which may include updating TTRPs, back-end servers, etc. as if a new TB protocol version was deployed.

So, I’m thinking there isn’t much extra agility, practically speaking, that we buy with option 1).

Cheers,

Andrei

---

From: John Bradley <[email-masked]>
Date: Fri, 24 Feb 2017 15:36:23 -0300

Personally speaking, Brian’s option 3 may be more practical to manage.

I think we can double our signing key strength before being under pressure to increase the EKM size to 64 bytes.

> On Feb 24, 2017, at 2:44 PM, Andrei Popov <[email-masked]> wrote:
>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 24 Feb 2017 15:17:41 -0700

Double the signing key *lenght* right? Which way more than doubles the
strength (for EC anyway). Or am I really bad at math?

On Fri, Feb 24, 2017 at 11:36 AM, John Bradley <[email-masked]> wrote:

> Brian’s option 3): We go back to saying that the TB protocol version
> defines the EKM size. Once a new signature scheme is proposed that requires
> a longer EKM, we’ll need to define TB v 1.1 with, e.g., a 64-byte EKM.
>
> Brian’s option 1): We stick with the signature scheme defining EKM size.
> Once a new signature scheme is proposed that requires a longer EKM, there
> is no need to define a new TB protocol version. However, operators willing
> to deploy this new signature scheme will need to ensure that their
> infrastructure supports the new signature scheme and EKM size. Which may
> include updating TTRPs, back-end servers, etc. as if a new TB protocol
> version was deployed.
>