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

[Nick Sullivan <[e-mail]>]

Martin,

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

Nick

On Wed, May 30, 2018 at 6:48 PM Martin Thomson <[e-mail]>
wrote:

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