Subject: [Unbearable] [TBPROTO] clarification of renego and EKM 2nd parag

From: =JeffH <[email-masked]>
Date: Tue, 29 Nov 2016 12:17:46 -0800

in 
<https://tools.ietf.org/html/draft-ietf-tokbind-protocol-11#section-3.3> 
we now have this 2nd parag after the list of bullet items..

 >    Specifications defining the use of Token Binding with various
 >    application protocols, such as Token Binding over HTTP
 >    [I-D.ietf-tokbind-https], may prohibit the use of TLS renegotiation
 >    in combination with Token Binding.  Alternatively, such
 >    specifications need to define a way to determine which EKM value
 >    corresponds to a given TokenBindingMessage, and a mechanism
 >    preventing a TokenBindingMessage from being split across the
 >    renegotiation boundary.

I am wondering about what the 2nd sentence above is saying, especially 
the after the 2nd comma, and am curious whether the below is an 
equivalent (and more clear) way to write it..

                                         Alternatively, such
    specifications need to define a way to determine which EKM value
    corresponds to a given TokenBindingMessage, and a mechanism
    ensuring that TokenBindingMessages sent after a renegotiation event
    are signing the post-renegotiation EKM value.

..?

thanks,

=JeffH

---

From: Andrei Popov <[email-masked]>
Date: Tue, 29 Nov 2016 20:34:12 +0000

>   and a mechanism

Nick refers to the fact that an application_data message can be fragmented, with some fragments delivered before renegotiation and others after renegotiation.
If one fragmented TB message is therefore sent both before and after a renegotiation, it's not clear which EKM it's using (probably from before the renegotiation, but then it's not the current one).
Nick's solution is to prohibit such splitting of TB messages across the renegotiation boundary.

(Nick please correct if I mis-represented).

Cheers,

Andrei

----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of =JeffH
Sent: Tuesday, November 29, 2016 12:18 PM
To: IETF TokBind WG <[email-masked]>
Subject: [Unbearable] [TBPROTO] clarification of renego and EKM 2nd parag

in

 >    preventing a TokenBindingMessage from being split across the

I am wondering about what the 2nd sentence above is saying, especially the after the 2nd comma, and am curious whether the below is an equivalent (and more clear) way to write it..

                                         Alternatively, such

..?

thanks,

=JeffH

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

---

From: Nick Harper <[email-masked]>
Date: Tue, 29 Nov 2016 13:33:20 -0800

Yes, that's one way for a TokenBindingMessage to be split across the
renegotiation boundary. There also isn't a one-to-one mapping from bytes in
a TokenBindingMessage to (unencrypted) bytes in application_data records.
E.g. an application protocol could have the TokenBindingMessage in
something that's compressed, so the bytes necessary to form a
TokenBindingMessage may be from various different application_data records,
e.g. some bytes in a recent record which references a dictionary sent a
while ago. When I refer to the TokenBindingMessage being split across a
renegotiation boundary, I don't mean requiring that those underlying bytes
not span the boundary (e.g. if the compressed TokenBindingMessage falls
after the boundary, but references a dictionary before the boundary), but
that the TokenBindingMessage from the perspective of the application
semantics not span that boundary.

I think Jeff's language has the same effect, in that if a
TokenBindingMessage is split across the renegotiation boundary, then part
of it falls after renegotiation, meaning that it has to use the
post-renegotiation EKM, which isn't possible unless the whole
TokenBindingMessage is post renegotiation.

On Tue, Nov 29, 2016 at 12:34 PM, Andrei Popov <[email-masked]>
wrote:

> Nick refers to the fact that an application_data message can be
> fragmented, with some fragments delivered before renegotiation and others
> after renegotiation.
> If one fragmented TB message is therefore sent both before and after a
> renegotiation, it's not clear which EKM it's using (probably from before
> the renegotiation, but then it's not the current one).
> I am wondering about what the 2nd sentence above is saying, especially the
> after the 2nd comma, and am curious whether the below is an equivalent (and
> more clear) way to write it..
>
>                                          Alternatively, such

---

From: Andrei Popov <[email-masked]>
Date: Tue, 29 Nov 2016 21:40:16 +0000

Ø  I think Jeff's language has the same effect, in that if a TokenBindingMessage is split across the renegotiation boundary, then part of it falls after renegotiation, meaning that it has to use the post-renegotiation EKM, which isn't possible unless the whole TokenBindingMessage is post renegotiation.
It's possible that Jeff’s language has the same effect, but I still prefer your language, because it seems to refer to the issue in a more direct way…

From: Nick Harper [mailto:[email-masked]]
Sent: Tuesday, November 29, 2016 1:33 PM
To: Andrei Popov <[email-masked]>
Cc: =JeffH <[email-masked]>; IETF TokBind WG <[email-masked]>
Subject: Re: [Unbearable] [TBPROTO] clarification of renego and EKM 2nd parag

Yes, that's one way for a TokenBindingMessage to be split across the renegotiation boundary. There also isn't a one-to-one mapping from bytes in a TokenBindingMessage to (unencrypted) bytes in application_data records. E.g. an application protocol could have the TokenBindingMessage in something that's compressed, so the bytes necessary to form a TokenBindingMessage may be from various different application_data records, e.g. some bytes in a recent record which references a dictionary sent a while ago. When I refer to the TokenBindingMessage being split across a renegotiation boundary, I don't mean requiring that those underlying bytes not span the boundary (e.g. if the compressed TokenBindingMessage falls after the boundary, but references a dictionary before the boundary), but that the TokenBindingMessage from the perspective of the application semantics not span that boundary.

I think Jeff's language has the same effect, in that if a TokenBindingMessage is split across the renegotiation boundary, then part of it falls after renegotiation, meaning that it has to use the post-renegotiation EKM, which isn't possible unless the whole TokenBindingMessage is post renegotiation.

Cheers,

Andrei

----Original Message-----
From: Unbearable [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of =JeffH
Sent: Tuesday, November 29, 2016 12:18 PM
To: IETF TokBind WG <[email-masked]<mailto:[email-masked]>>
Subject: [Unbearable] [TBPROTO] clarification of renego and EKM 2nd parag

in

                                         Alternatively, such

..?

thanks,

=JeffH

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