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

[Martin Thomson <[e-mail]>]

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

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

> 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 <[e-mail]>
wrote:

>> 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 <[e-mail]> wrote:



>>> > On Apr 21, 2018, at 10:25, Sean Turner <[e-mail]> wrote:
>>> >
>>> >
>>> >> On Apr 19, 2018, at 16:32, Sean Turner <[e-mail]> 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
>>> _______________________________________________
>>> TLS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls

> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls