Note that this is different from Token Binding because that's negotiated by an extension, so per S 9.3, non-supporting middleboxes need to strip out the extension
-Ekr On Mon, May 7, 2018 at 8:06 AM, Roelof duToit <r@nerd.ninja> wrote: > > > On May 4, 2018, at 5:48 PM, Benjamin Kaduk <bka...@akamai.com> wrote: > > > > On Fri, May 04, 2018 at 11:20:55AM -0400, Roelof duToit wrote: > >> How will this (and any mechanism built on top of RFC 5705 exported key > material) interoperate with middleboxes? This use of the mechanism is not > negotiated on the TLS level, so there is no extension for the middlebox to > strip that would warn the endpoints not to use exported authenticators. > Are application level proxies the only compatible middleboxes? > > > > I'm not sure I properly understand the question, in particular what kind > of > > middlebox you're considering. Note that application protocols will need > to > > have some way to negotiate the use of this functionality, which > presumably a > > middlebox could also inspect. > > > That is the problem.. some middleboxes are protocol agnostic and are used > to strip the TLS layer before feeding the rest of the security stack - so > called “Transport Layer Active Intercept” vs “Application Layer Intercept” > (ignoring “Transport Layer Passive Intercept” for the moment). Some > middleboxes might also perform transport layer active intercept in > combination with passive application detection, i.e. L7 analysis vs L7 > termination. > In summary: the endpoints cannot assume that exported key material is > identical in a middlebox environment. > > > > _______________________________________________ > 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
