Re: [Unbearable] ramifications of longer EKMs

[Brian Campbell <[e-mail]>]

>
> 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 <[e-mail]>
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
> <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) 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:[e-mail]] *On Behalf Of *Brian
> Campbell
> *Sent:* Wednesday, February 22, 2017 1:53 PM
> *To:* IETF Tokbind WG <[e-mail]>
> *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.
>
>
>
>
>
>
>
>