On Tue, Apr 18, 2017 at 11:29:31AM -0400, Victor Vasiliev wrote: > I've read the draft, and I support its adoption. I believe that the > mechanism > is sound for its stated use. > > The second issue I have is with the question of when does authentication > succeed. In TLS, by the time any party can send application data, normally > (with exception of server-to-client data in client auth case) both parties > know that the other side has authenticated them.
I don't think that is actually true for client authentication (even in- handshake). > Here, a new identity is introduced while application data can be already > in flight, and it's not clear to me when the sender of the exported > authenticator can act assuming the peer has accepted its new identity. > My current understanding is that this issue is deferred to the application > layer, but it would be nice to discuss those considerations explicitly. IMO, the application layer is the only layer that actually knows the relevant state. > The last question I have is how does this interact with the state of TLS > connection. Does accepting a new identity mean that the entire connection > now has that identity too? Does this mean that the session tickets issued > after the library receives the authenticator are valid for the new > identity? Does it make the tickets sent previously on that connection valid > for the new identity? I believe this is up to the application. (And even in case of TLS authentication, I think some of these are "implementation-dependent". > Also, what is the distinction between "jointly authoritative for A and B" > and "individually authoritative for A and individually authoritative for > B"? Pretty much the whole paragraph mentioning that reads like some mumbo- jumbo to me (not a good sign). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
