On Wed, May 9, 2018 at 7:15 PM, Martin Thomson <martin.thom...@gmail.com> wrote:
> 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. To be clear: it's not failing to validate the *certificate* it's that the CertificateVerify to validate. This should ordinarily never happen, so I definitely think we should call that out. -Ekr 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
