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 <martin.thom...@gmail.com> 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 > <nicholas.sulli...@gmail.com> 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 <martin.thom...@gmail.com> > 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 < > 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
