Subject: Re: [Unbearable] wrt handling multiple sec-token-binding header occurrences

From: =JeffH <[email-masked]>
Date: Tue, 14 Feb 2017 15:15:23 -0800

Andrei replied:
 >
 > Per PKP thread referenced below:
 > "No matter where the header is injected (first or second), it's never
 > wrong reject both. It certainly feels safer to me; after all we know
 > that that response is contaminated."

yes, that was written by Ivan and was/is his position wrt HPKP. 
Regardless, the spec shipped with the "UA MUST process only the first 
PKP header field" language (as did HSTS). There were real-world HTTP 
vagaries as I recall which caused us to use the language we did in HSTS 
and HPKP, but maybe things are different now.

That said, I personally am ok with stipulating this..

   If the server receives more than one Sec-Token-Binding header field
   in an HTTP request, then the server MUST reject the message with a
   400 (Bad Request) HTTP status code.

..and seeing if we get any pushback during IETF-wide Last Call.

=JeffH

---

From: Andrei Popov <[email-masked]>
Date: Tue, 14 Feb 2017 23:24:04 +0000

Yes, I think this would be cleanest/simplest, and then we can easily adjust the language if someone brings up a reason to do so.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of =JeffH
Sent: Tuesday, February 14, 2017 3:15 PM
To: IETF TokBind WG <[email-masked]>
Subject: Re: [Unbearable] wrt handling multiple sec-token-binding header occurrences

Andrei replied:
 > "No matter where the header is injected (first or second), it's never  > wrong reject both. It certainly feels safer to me; after all we know  > that that response is contaminated."

yes, that was written by Ivan and was/is his position wrt HPKP. 
Regardless, the spec shipped with the "UA MUST process only the first PKP header field" language (as did HSTS). There were real-world HTTP vagaries as I recall which caused us to use the language we did in HSTS and HPKP, but maybe things are different now.

=JeffH

_______________________________________________
Unbearable mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/unbearable