Andrei-Popov
commented
7 years ago 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 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).
b---c
(Below is copied from this message to the WG list but I'm never quite sure if here is better or the list or both. Also my mail gets spam filtered a lot. So going with both for posterity)
Shortly after Seoul TBPROTO-11 "Clarified that other signature schemes may require longer exporter output", 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 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.