Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] ramifications of longer EKMs (#95)

From: Andrei-Popov <[email-masked]>
Date: Wed, 22 Feb 2017 15:34:13 -0800

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

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/TokenBinding/Internet-Drafts/issues/95#issuecomment-281840618