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

From: Sean Turner <[email-masked]>
Date: Thu, 3 May 2018 16:12:14 -0400

> On Apr 21, 2018, at 10:25, Sean Turner <[email-masked]> wrote:
> 
> 
>> On Apr 19, 2018, at 16:32, Sean Turner <[email-masked]> wrote:
>> 
>> All,
>> 
>> This is the working group last call for the "Exported Authenticators in TLS" draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/.  Please review the document and send your comments to the list by 2359 UTC on 4 April 2018.
> 
> … 4 May 2018 ...

Just a reminder the WGLC ends tomorrow.

spt

---

From: Nick Sullivan <[email-masked]>
Date: Thu, 03 May 2018 20:16:04 +0000

Does anyone have any comments about the draft, criticisms, or votes of
support?

Nick

On Thu, May 3, 2018 at 1:12 PM Sean Turner <[email-masked]> wrote:

> >> This is the working group last call for the "Exported Authenticators in
> TLS" draft available at
> https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/.
> Please review the document and send your comments to the list by 2359 UTC
> on 4 April 2018.
> >
> > … 4 May 2018 ...
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 04 May 2018 02:24:04 +0000

I've already provided enough input on this draft, but I sent in a few
editorial PRs.

Otherwise, this looks fine to go from my perspective.  I would like to see
some other opinions though, I'm probably too close to this.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 04 May 2018 11:00:56 +0200

On Thu, 2018-04-19 at 16:32 -0400, Sean Turner wrote:
> All,
> 
> This is the working group last call for the "Exported Authenticators
> in TLS" draft available at https://datatracker.ietf.org/doc/draft-iet
> f-tls-exported-authenticator/.  Please review the document and send
> your comments to the list by 2359 UTC on 4 April 2018.

I have not checked the mechanism, but I have few questions based on the
description in the introduction.
   "Post-handshake authentication is defined in TLS 1.3, but it has the
   disadvantage of requiring additional state to be stored in the TLS
   state machine and it composes poorly with multiplexed connection
   protocols like HTTP/2.  It is also only available for client
   authentication.  This mechanism is intended to be used as part of a
   replacement for post-handshake authentication in applications."

* Was this proposed to be included in TLS 1.3 as post-handshake
authentication mechanism instead?

* What are the actual problems that post-handshake authentication has
with HTTP/2?

regards,
Nikos

---

From: Tim Hollebeek <[email-masked]>
Date: Fri, 4 May 2018 12:44:24 +0000

I generally really like it.

My only comment is about the use of a zero byte as a separator in a string (4.2.2).

There are commonly used languages where this is likely to lead to implementation bugs, causing the signature to be computed over a shorter length than expected.

While I doubt this causes any problems other than failures and debugging pain, the first 64 bytes contain the octet 32; I don’t see any reason why byte 87 can’t also be octet 32.

-Tim

From: TLS [mailto:[email-masked]] On Behalf Of Nick Sullivan
Sent: Thursday, May 3, 2018 4:16 PM
To: Sean Turner <[email-masked]>
Cc: TLS WG <[email-masked]>
Subject: Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator

Does anyone have any comments about the draft, criticisms, or votes of support?

Nick

On Thu, May 3, 2018 at 1:12 PM Sean Turner <[email-masked] <mailto:[email-masked]> > wrote:

> On Apr 21, 2018, at 10:25, Sean Turner <[email-masked] <mailto:[email-masked]> > wrote:
> 
> 
>> On Apr 19, 2018, at 16:32, Sean Turner <[email-masked] <mailto:[email-masked]> > wrote:
>> 
>> All,
>> 
>> This is the working group last call for the "Exported Authenticators in TLS" draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ <https://datatracker.ietf..org/doc/draft-ietf-tls-exported-authenticator/> .  Please review the document and send your comments to the list by 2359 UTC on 4 April 2018.
> 
> … 4 May 2018 ...

spt
_______________________________________________
TLS mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/tls

---

From: Jonathan Hoyland <[email-masked]>
Date: Fri, 04 May 2018 13:15:57 +0000

Hi Nikos,

The problems post-handshake authentication has with HTTP/2 are described in
draft-ietf-httpbis-http2-secondary-certs-00
<https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-00#section-1.2.3>
 a.k.a. draft-Bishop. See Section 1.2.3 in particular.

In brief, the problem is that requests and responses are multiplexed in
HTTP/2, and threfore there is not a tight coupling between TLS frames and
HTTP/2 streams.

With post-handshake authentication, the authentication happens in band, and
so the HTTP/2 layer doesn't have visibility into whether or not specific
data was sent before or after the authentication.

Regards,

Jonathan

---

From: Roelof duToit <[email-masked]>
Date: Fri, 4 May 2018 11:20:55 -0400

How will this (and any mechanism built on top of RFC 5705 exported key material) interoperate with middleboxes?  This use of the mechanism is not negotiated on the TLS level, so there is no extension for the middlebox to strip that would warn the endpoints not to use exported authenticators.  Are application level proxies the only compatible middleboxes?

—Roelof

> On Apr 19, 2018, at 4:32 PM, Sean Turner <[email-masked]> wrote:
> 
> All,
> 
> Thanks - J&S

---

From: Christopher Wood <[email-masked]>
Date: Fri, 04 May 2018 20:56:43 +0000

I sent in one editorial PR as well. Pending the suggested change, I think
the document is ready to go.

Best,
Chris
On Thu, May 3, 2018 at 7:24 PM Martin Thomson <[email-masked]>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 4 May 2018 16:37:22 -0500

> This is the working group last call for the "Exported Authenticators in TLS" draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/.  Please review the document…

Are we using values in the same certificate_request_context space as those that
in-TLS post-handshake authentication would use?  If so, we should probably have
some text in Section 3 (and maybe more explanation in Section 5.2 as well?)
about the application coordinating with the TLS stack to avoid conflicts (since
just from a data structure point of view the application could send a
CertficiateRequest without checking with the TLS stack).  We may also need the
TLS stack to accound for context values chosen arbitrarily for spontaneous
authentications.  The API considerations might also be more clear that there
are different spaces for the context values for server auth and client auth.

Section 4.1 talks of the length of the exporter value in terms of the length of the
TLS PRF hash, adding that cipher suites not using TLS PRF have to define a hash function.
But TLS 1.3 ciphersuites do not use the TLS PRF and we say nothing about them...

It doesn't look like we adapted to the addition of the signature_algorithms_cert
extension in TLS 1.3.

-Ben (with no hats)

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 4 May 2018 16:48:35 -0500

> How will this (and any mechanism built on top of RFC 5705 exported key material) interoperate with middleboxes?  This use of the mechanism is not negotiated on the TLS level, so there is no extensi…

I'm not sure I properly understand the question, in particular what kind of
middlebox you're considering.  Note that application protocols will need to
have some way to negotiate the use of this functionality, which presumably a
middlebox could also inspect.

-Ben

---

From: Roelof duToit <[email-masked]>
Date: Mon, 7 May 2018 11:06:10 -0400

> On May 4, 2018, at 5:48 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

That is the problem.. some middleboxes are protocol agnostic and are used to strip the TLS layer before feeding the rest of the security stack - so called “Transport Layer Active Intercept” vs “Application Layer Intercept” (ignoring “Transport Layer Passive Intercept” for the moment).  Some middleboxes might also perform transport layer active intercept in combination with passive application detection, i.e. L7 analysis vs L7 termination.
In summary: the endpoints cannot assume that exported key material is identical in a middlebox environment.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 7 May 2018 09:06:13 -0700

Note that this is different from Token Binding because that's negotiated by
an extension, so per S 9.3, non-supporting middleboxes need to strip out
the extension

-Ekr

On Mon, May 7, 2018 at 8:06 AM, Roelof duToit <[email-masked]> wrote:

> >> How will this (and any mechanism built on top of RFC 5705 exported key
> material) interoperate with middleboxes?  This use of the mechanism is not
> negotiated on the TLS level, so there is no extension for the middlebox to
> strip that would warn the endpoints not to use exported authenticators.
> Are application level proxies the only compatible middleboxes?
> >
> That is the problem.. some middleboxes are protocol agnostic and are used
> to strip the TLS layer before feeding the rest of the security stack - so
> called “Transport Layer Active Intercept” vs “Application Layer Intercept”
> (ignoring “Transport Layer Passive Intercept” for the moment).  Some
> middleboxes might also perform transport layer active intercept in
> combination with passive application detection, i.e. L7 analysis vs L7
> termination.

---

From: Roelof duToit <[email-masked]>
Date: Mon, 7 May 2018 12:16:30 -0400

Agree.  Middleboxes can signal on the TLS layer that token-binding is not supported, but not for exported-authenticator.

> On May 7, 2018, at 12:06 PM, Eric Rescorla <[email-masked]> wrote:
> 
> Note that this is different from Token Binding because that's negotiated by an extension, so per S 9.3, non-supporting middleboxes need to strip out the extension
> 
> -Ekr
> 
> 
> On Mon, May 7, 2018 at 8:06 AM, Roelof duToit <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > On May 4, 2018, at 5:48 PM, Benjamin Kaduk <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
>

---

From: Roelof duToit <[email-masked]>
Date: Tue, 8 May 2018 12:20:13 -0400

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?

—Roelof

> On May 7, 2018, at 12:16 PM, Roelof duToit <[email-masked]> wrote:
> 
>> On May 7, 2018, at 12:06 PM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Mike Bishop <[email-masked]>
Date: Tue, 8 May 2018 23:42:04 +0000

Belatedly, as I’ve been offline for the past week, but I support this draft moving forward.

From: Nick Sullivan <[email-masked]>
Sent: Thursday, May 3, 2018 1:16 PM
To: Sean Turner <[email-masked]>
Cc: TLS WG <[email-masked]>
Subject: Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator

Nick
On Thu, May 3, 2018 at 1:12 PM Sean Turner <[email-masked]<mailto:[email-masked]>> wrote:

> On Apr 21, 2018, at 10:25, Sean Turner <[email-masked]<mailto:[email-masked]>> wrote:
>
>
>> On Apr 19, 2018, at 16:32, Sean Turner <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> All,
>>

spt
_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Thomson <[email-masked]>
Date: Wed, 09 May 2018 00:13:18 +0000

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

---

From: Roelof duToit <[email-masked]>
Date: Tue, 8 May 2018 21:24:53 -0400

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 <[email-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 09 May 2018 07:39:07 +0000

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 <[email-masked]> 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.

---

From: Roelof duToit <[email-masked]>
Date: Wed, 9 May 2018 09:20:43 -0400

Perhaps, but it still behooves us to warn implementors that a significant percentage of enterprise traffic will break with this mechanism.

> On May 9, 2018, at 3:39 AM, Martin Thomson <[email-masked]> wrote:
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 9 May 2018 13:25:03 +0000

>    Perhaps, but it still behooves us to warn implementors that a significant percentage of enterprise traffic will break with this mechanism.
  
Why do you think a significant percentage will break?

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 May 2018 06:28:10 -0700

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.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 May 2018 02:15:50 +0000

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

deployment
> 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,

the
channels).

that's negotiated

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 May 2018 21:06:42 -0700

On Wed, May 9, 2018 at 7:15 PM, Martin Thomson <[email-masked]>
wrote:

> 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
> >> > > On May 8, 2018, at 8:13 PM, Martin Thomson <
> [email-masked]>
> >> wrote:
> >> > >

---

From: Nick Sullivan <[email-masked]>
Date: Fri, 11 May 2018 16:58:35 -0700

Thanks all for the comments on the draft. Let me try to summarize the
comments and propose next steps.

Tim Hollebeek had a comment about 0 as the separator. I generally don’t
think this is a big issue, and prefer 0 because it is a natural way to
terminate a string. If anyone strongly disagrees, please reply to the list.

Roelof duToit raised a question about middlebox interoperability,
specifically that the exporters will not match if the TLS connection is not
end-to-end. There was a subsequent discussion about where to signal this
property. Martin Thomson suggested a signaling mechanism at the application
layer (https://github.com/httpwg/http-extensions/issues/617) and Eric
Rescorla suggested that the fact that this could cause CertificateVerify
failures should be called out in the document. I'll put a PR together to
add some helpful text around debugging CertificateVerify failures to
address Eric's suggestion.

Ben Kaduk had three points:
- The certificate_request_context is prone to collisions with
post-handshake authentication and there are different spaces for the server
and client context values. He suggested some text in Section 3 and maybe
more explanation in Section 5.2 as well. I’ll put together a PR for this.
- Section 4.1 talks of the length of the exporter value in terms of the
length of the
TLS PRF hash, adding that cipher suites not using TLS PRF have to define a
hash function, but TLS 1.3 ciphersuites do not use the TLS PRF. I’ll put
together a PR to clarify the text around this clarifying that for TLS 1.3
cipher suites, the HDKF hash is what is meant.
- The “signature_algorithms_cert” extension was not incorporated into the
draft. I’ll put together a PR for 4.2.1., 4.2.2. and 5.1. to incorporate
this extension.

I'll have the proposed changes for the above comments ready next week.

There were also some uncontroversial suggestions that I propose merging:
https://github.com/tlswg/tls-exported-authenticator/pull/21
https://github.com/tlswg/tls-exported-authenticator/pull/22
https://github.com/tlswg/tls-exported-authenticator/pull/23
https://github.com/tlswg/tls-exported-authenticator/pull/24

Nick

On Thu, May 3, 2018 at 1:16 PM Nick Sullivan <[email-masked]>
wrote:

>> in TLS" draft available at

---

From: Martin Thomson <[email-masked]>
Date: Fri, 25 May 2018 10:54:33 +1000

Mike just inadvertently (?) discovered a problem with exported
authenticators.

TLS post handshake authentication provides an authenticated refusal when a
certificate can't be found.  It turns out that the current design of the
HTTP/2 CERTIFICATE frame might need to rely on the same capability here.

The current draft doesn't really say anything about what happens.

https://github.com/tlswg/tls-exported-authenticator/issues/25

length of the
> TLS PRF hash, adding that cipher suites not using TLS PRF have to define
a hash function, but TLS 1.3 ciphersuites do not use the TLS PRF. I’ll put
together a PR to clarify the text around this clarifying that for TLS 1.3
cipher suites, the HDKF hash is what is meant.

support?

---

From: Nick Sullivan <[email-masked]>
Date: Wed, 30 May 2018 18:23:25 -0700

I've put together some PRs to address the comments from last call. Comments
welcome.

Failing CertificateVerify due to MITM text:
https://github.com/tlswg/tls-exported-authenticator/pull/28

Comments from Ben Kaduk:
https://github.com/tlswg/tls-exported-authenticator/pull/26

Authenticated Denial:
https://github.com/tlswg/tls-exported-authenticator/pull/27

Nick

On Thu, May 24, 2018 at 5:54 PM Martin Thomson <[email-masked]>
wrote:

> On Sat, May 12, 2018 at 9:59 AM Nick Sullivan <[email-masked]
> >
> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 May 2018 11:48:25 +1000

I've reviewed changes.  Thanks for writing them up Nick.

Two concerns:

On #26, I think that there is a misunderstanding of how
signature_algorithms and signature_algorithms_cert work.  My
understanding is that the former applies to the entire chain, unless
the latter is present, in which case the latter applies to all
signatures produced by certificates in the chain other than the end
entity certificate.  Thus, signature_algorithms entirely governs the
choice of signature algorithm that is used in TLS itself, whereas
signature_algorithms_cert (if present) governs the use of signatures
that are used in building the certification path.

#26 switches to signature_algorithms_cert exclusively.  That's an
error, I think.

In #27, I think that dropping Certificate entirely isn't a good idea.
TLS 1.3 sends it, but leaves it empty.  There are a few reasons I
mention in the PR comments.
On Thu, May 31, 2018 at 11:23 AM Nick Sullivan
<[email-masked]> wrote:
>
> I've put together some PRs to address the comments from last call. Comments welcome.
>
> On Thu, May 24, 2018 at 5:54 PM Martin Thomson <[email-masked]> wrote:
>>

---

From: Nick Sullivan <[email-masked]>
Date: Thu, 31 May 2018 11:44:21 -0700

Martin,

Thanks for the corrections, and thank you others who have reviewed the
patches. I've updated the PRs appropriately.

Nick