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 <nicholas.sulli...@gmail.com> 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 <nicholas.sulli...@gmail.com> 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 <s...@sn3rd.com> wrote: >>> > On Apr 21, 2018, at 10:25, Sean Turner <s...@sn3rd.com> wrote: >>> > >>> > >>> >> On Apr 19, 2018, at 16:32, Sean Turner <s...@sn3rd.com> 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 >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
