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

[Martin Thomson <[e-mail]>]

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