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
