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

[Martin Thomson <[e-mail]>]

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-mail]> 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 <[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.