I'm not that concerned about this, though I will concede that it's worth pointing out.
Failing to validate a secondary certificate for a server shouldn't be cause for terminating an otherwise usable connection. The same goes for clients that authenticate using this. As long as users of exported authenticators are aware of this, then they can design for it. If those users wanted confirmation, then we could provide a confirmation-of-mechanism-viability in the application layer. That could just be by including a value derived from the exporter in the negotiation. In h2, we could do as much as 4 octets of confirmation for cheap, and maybe we should. https://github.com/httpwg/http-extensions/issues/617 On Wed, May 9, 2018 at 11:28 PM Eric Rescorla <e...@rtfm.com> wrote: > Regardless of where it goes in the document, I think there's a real deployment > consideration here: if you run this mechanism through a conventional MITM > proxy, what will happen will be that the secondary cert auth will appear to just > fail with a bogus signature. If clients respond to that by terminating the connection, > then we're going to be in pretty bad shape [0]. So I think we either need: > 1. To negotiate this with an extension > 2. To tell people not to treat signature failures as a hard failure. > 3. To have some way to indicate that there was a MITM on-path (e.g., have the > application level mechanism include some separate value that's tied to > the channel that lets the endpoints detect when its two separate channels). > -Ekr > [0] Note that this also applies to post-handshake authentication, but that's negotiated > with an extension, so S 9.3 applies. > On Wed, May 9, 2018 at 12:39 AM, Martin Thomson <martin.thom...@gmail.com> wrote: >> This isn't really a security consideration though, it's a truism. A MitM >> can break things that depend on end-to-end integrity of the connection. >> On Wed, May 9, 2018 at 11:25 AM Roelof duToit <r@nerd.ninja> wrote: >> > If the use of the mechanism is not negotiated on the TLS level then I >> would appreciate it if the “Security Considerations” section of the draft >> could be amended to include a paragraph that warns potential implementors >> that protocol-agnostic middleboxes will break the mechanism without any >> clear failure indicators. >> > > On May 8, 2018, at 8:13 PM, Martin Thomson <martin.thom...@gmail.com> >> wrote: >> > > >> > > On Wed, May 9, 2018 at 2:20 AM Roelof duToit <r@nerd.ninja> wrote: >> > > >> > >> I understand that there is not really anything to negotiate per se, but >> > > would it not be prudent to add a TLS extension to negotiate support for >> > > exported-authenticator in the TLS layer prior to using it in the >> > > application layer? >> > > >> > > We don't signal the potential need for exporters. I see no reason to >> > > signal this either. Any signaling necessary really belongs at the >> higher >> > > layer. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
