Re: [Unbearable] tokbind - New Meeting Session Request for IETF 102

[Brian Campbell <[e-mail]>]

Thanks again for the review, James. I've submitted -04 with changes
addressing the comments.


Name:           draft-ietf-tokbind-ttrp
Revision:       04
Title:          HTTPS Token Binding with TLS Terminating Reverse Proxies
Document date:  2018-06-06
Group:          tokbind
Pages:          13
URL:            https://www.ietf.org/internet-drafts/draft-ietf-tokbind-ttrp
-04.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/
Htmlized:       https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-04
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-tt
rp
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-ttrp-04

On Tue, Jun 5, 2018 at 12:04 PM, Brian Campbell <[e-mail]>
wrote:

> Thanks for the review, James. Replies to the individual comments are
> inline below.
>
>
> On Mon, Jun 4, 2018 at 6:34 PM, Manger, James <
> [e-mail]> wrote:
>
>> draft-ietf-tokbind-ttrp-03 looks ok.
>>
>
> Thanks, that is high praise indeed!
>
>
> There is nothing to distinguish between Token Binding being offered by the
>> TTRP but not accepted by the client vs not being offered at all. I’m not
>> sure if that matters. Perhaps it only makes sense for a server to look for
>> these headers if it is sure all the reverse proxies that serve it support
>> Token Binding and are configured to insert these headers.
>>
>
> Yeah, there is nothing provided to the back-end server to distinguish
> between those two cases. But I can't think of a reason that the back-end
> would do anything meaningful with that distinction.  The client and TTRP
> are doing token binding or they are not and that is what gets conveyed
> (along with the TB ID, of course).
>
>
>
>>
>> Minor typos:
>>
>> There is no example of Sec-Other-Token-Binding.
>>
>
> I was somewhat hesitant about adding support at all for conveying token
> binding types other than provided and referred. That and a touch of
> laziness led me to not do an example for Sec-Other-Token-Binding in the
> last draft revision. But it is somewhat incomplete or inconsistent without
> it. I'll add such an example in the next draft.
>
>
>
>>
>>
>> 2.1.2 ABNF for EncodedTokenBindingType doesn’t strictly need "A" / "a" as
>> “ABNF strings are case insensitive” [RFC5234 section 2.3
>> <https://tools.ietf.org/html/rfc5234#section-2.3>] so just "A" would do.
>> Having both does reinforce that upper and lower case can be used. Re-using
>> the HEXDIG core ABNF rule would be slightly better, with a case-insensitive
>> mention in the text.
>>
>
> I'd chosen not to reuse HEXDIG so as to allow upper and lower case.
> However, I'd overlooked the case insensitive nature of ABNF strings you
> referenced there. I think you're right that using the HEXDIG core ABNF rule
> along with with a case-insensitive mention in the text is somewhat better.
> I'll update accordingly.
>
>
>
>>
>> Typo: section 3: “… they are **a** single logical server”
>>
>
> Will fix.
>
>
> Thanks!
>
>
>
>
>
>>
>> --
>>
>> James Manger
>>
>>
>>
>> *From:* Unbearable [mailto:[e-mail]] *On Behalf Of *Brian
>> Campbell
>> *Sent:* Saturday, 2 June 2018 2:07 AM
>> *To:* Leif Johansson <[e-mail]>
>> *Cc:* IETF Tokbind WG <[e-mail]>
>> *Subject:* Re: [Unbearable] tokbind - New Meeting Session Request for
>> IETF 102
>>
>>
>>
>> It's pretty short! https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-03
>>
>>
>>
>> On Fri, Jun 1, 2018 at 8:32 AM, Leif Johansson <[e-mail]> wrote:
>>
>>
>>
>> On 2018-06-01 00:49, Brian Campbell wrote:
>> > I'd like to request some agenda time to cover the TTRP draft, which will
>> > likely consist of an overview and status update (with some gratuitous
>> > photos of recent IETF meeting locations) and a plea to move towards
>> > WGLC. Thanks!
>>
>> In order to facilitate that... could we get some folks to review
>> the TTRP draft before 102?
>>
>> Maybe... please... ??
>>
>>         Cheers Leif
>>
>>
>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the intended recipient(s). Any
>> review, use, distribution or disclosure by others is strictly prohibited..
>> If you have received this communication in error, please notify the sender
>> immediately by e-mail and delete the message and any file attachments from
>> your computer. Thank you.*
>>
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._