Thanks for the review. I'm open to adding text indicating that the exported authenticator SHOULD be sent using an application protected by the TLS stream in question, but I don't want to remove the possibility of sending the data over a secure secondary channel, depending on the application.
Nick On Tue, Apr 18, 2017 at 8:29 AM Victor Vasiliev <vasi...@google.com> wrote: > I've read the draft, and I support its adoption. I believe that the > mechanism > is sound for its stated use. > > I have some minor concerns about the wording in the draft, though. First, > the > draft describes the authenticators as sent "out-of-band", while my > understanding is that they are always intended to be sent in-band as > application data. If they were truly sent out-of-band, there would be some > questions about the security analysis, because that would imply those > could be > sent unprotected. Hence, I suggest the draft to adapt the premise that > exported authenticators MUST be sent as application data within the same > connection. This might simplify your security proofs too. > > 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. 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. > > 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? > > Also, what is the distinction between "jointly authoritative for A and B" > and > "individually authoritative for A and individually authoritative for B"? > > -- Victor. > On Fri, Apr 14, 2017 at 12:29 AM, Joseph Salowey <j...@salowey.net> wrote: > >> Hey Folks, >> >> At the IETF 98 meeting in Chicago there was support in the room to adopt >> draft-sullivan-tls-exported-authenticator [0]. We are looking for >> feedback on adopting this draft form the list. Please respond if you >> support the draft and are willing to review it. If you object to its >> adoption, please let us know why. Please respond to the list by 20170501 >> >> Cheers, >> >> J&S >> >> [0] >> https://datatracker.ietf.org/doc/html/draft-sullivan-tls-exported-authenticator >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
