Re: [Unbearable] Adam Roach's Yes on draft-ietf-tokbind-https-14: (with COMMENT)

[Adam Roach <[e-mail]>]

On 6/4/18 4:56 PM, Dirk Balfanz wrote:
> Hi Adam,
>
> thanks for the feedback. Most of it is addressed in the new draft 
> (https://tools.ietf.org/html/draft-ietf-tokbind-https-16). See below 
> (inline) for details.
>
>

Thanks! Some responses inline.


>
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>
>     Thanks to everyone who worked on this document. I am balloting
>     "Yes", but
>     still have a handful of comments, including several that I believe are
>     rather important.
>
>
>     ---------------------------------------------------------------------------
>
>     §2:
>
>     >  Once a client and server have negotiated the Token Binding Protocol
>     >  with HTTP/1.1 or HTTP/2 (see [I-D.ietf-tokbind-protocol] and
>     >  [I-D.ietf-tokbind-negotiation])
>
>     Presuming this document is intended to cover use of TLS 1.3, I
>     believe this
>     list needs to also include [I-D.ietf-tokbind-tls13].
>
>
> Actually, the document doesn’t address TLS 1.3 - that will be covered 
> in a separate document.

Please adjust the title, abstract, and introduction to make this clear. 
I see neither prose nor technical mechanism in this document that 
precludes use with TLS 1.3, and it's virtually guaranteed that 
implementors will try to use it with TLS 1.3 unless there is clear text 
saying not to.


>
>
>     ---------------------------------------------------------------------------
>
>     §5.3:
>
>     >  When a client receives the Include-Referred-Token-Binding-ID
>     header,
>     >  it includes the referred token binding even if both the Token
>     >  Provider and the Token Consumer fall under the same eTLD+1 and the
>     >  provided and referred token binding IDs are the same. Note that the
>     >  referred token binding is sent only on the request resulting
>     from the
>     >  redirect and not on any subsequent requests to the Token Provider.
>
>     I think this needs some clarification about handling of multiple
>     redirections of
>     the transaction. E.g.: Token Consumer sends a 3xx to redirect the
>     user to a
>     Token Provider (using, perhaps, an endpoint that is in the process
>     of being
>     migrated), and then the Token Provider sends an additional 3xx to
>     get the
>     client to the correct server.  Presumably, the inclusion of the
>     referred token
>     binding should survive both redirections, but this text might be
>     read as
>     preventing that.
>
>
> This was consciously chosen to have the semantics that you took from 
> this section (i.e., the header doesn’t survive multiple redirects). 
> The migrating endpoint would have to communicate the Token Binding ID 
> to the final endpoint in some other manner (e.g., through a custom 
> authenticated query parameter).

That's okay as behaviors go, but I still think the document is somewhat 
unclear, as the notion of what constitutes a single "request" is a bit 
muddy in the context of request redirection. I would suggest adding 
clarifying text similar to what you say above.

/a