Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator

[Eric Rescorla <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]> 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 <[e-mail]>
> wrote:
> > >
> > > On Wed, May 9, 2018 at 2:20 AM Roelof duToit <[e-mail]> 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.
>