Subject: Re: [Unbearable] Sec- prefix for Token-Binding headers (was: new draft-ietf-tokbind-https-03

From: =JeffH <[email-masked]>
Date: Tue, 22 Mar 2016 18:22:56 -0700

Hey Dirk,

 > I was told that in Yokohama it was decided to add the Sec- prefix again. (I
 > wasn't at that meeting.)

doh, yeah, I only checked mailing list traffic and my modest notes from the 
tokbind session at ietf-94 Yok and didn't check the (also modest) minutes..

https://www.ietf.org/proceedings/94/minutes/minutes-94-tokbind

..which state..

Questions about threats:

victim's private key should not only be kept secret, but also
protected from signing arbitrary attacker-controlled data.

EKR: why does EKM need to be secret.

EKR: if EKM is leaked, attacker can impose their own sec header.

MThomson: if we know about the header we can make ...

EKR: sec header by default makes it impossible to inject. What
is the argument for not using a sec header

..so it seems to me EKR was posing similar questions to those in my original 
msg.

 > As for the security considerations, they already state that a
 > man-in-the-middle shouldn't be able to pick the value of the
 > (Sec-)Token-Binding header.

yes.

 > One corollary of that is that the value of the
 > (Sec-)Token-Binding header can't be set by application (Javascript) code
 > (since that is potentially controlled by a man-in-the-middle).

yes, and that would seem to be justification for using the Sec- header field 
prefix.

 >  But perhaps
 > it bears saying that explicitly. Wanna open an Issue?

Sure. I've added it to my review comments notes (which I'll get sent to the 
list here before ietf-95 BA (of all three tokbind drafts)

HTH,

=JeffH