Thanks Martin and Daiki! ----- Original Message ----- > From: "Martin Thomson" <m...@mozilla.com> > To: "Daiki Ueno" <du...@redhat.com> > Cc: "mozilla's crypto code discussion list" > <dev-tech-crypto@lists.mozilla.org> > Sent: Tuesday, July 7, 2020 10:26:07 PM > Subject: Re: NSS v3.52 and TLSv1.3's Post-Handshake Authentication -- > completion notification? > > On Wed, Jul 8, 2020 at 2:36 AM Daiki Ueno <du...@redhat.com> wrote: > > > > Martin Thomson <m...@mozilla.com> writes: > > > > > I think that we considered this when we first landed this code, but > > > deferred adding any callbacks until it was clear what the right answer > > > was. As you say, you get the callback, but you might not if the > > > request is rejected. > > > > I think that is about the server side. On the client side, it seems > > even harder to detect the completion, because there will be no > > indication of acceptance until the next application data is sent. > > Fair point, but we have never had a way to indicate that you consider > your peer to be authenticated as "X". It's down to individual > authorization decisions to reflect whatever opinion you have formed. > For instance, a 403 response in HTTP might provide some more > information.
(I seem to have lost Daiki's reply) I don't care too much (from a client perspective) whether or not our credentials were accepted. If they weren't, the worst that will happen is I'll get an alert later and everything will close down anyways -- or, the server will ignore them (passing the failure to the application) and I'm left wondering why it asked for credentials anyways. Perhaps the application will reject the lack of credentials and close the connection itself, but with a pretty application-level error message. Either way, my working assumption is that if the server doesn't like the credentials, it'll at worst close the connection. At best, it'll prompt me for new credentials again. (It'll probably get the same answer, but that's a different discussion). "meh"? So on the client side, I'd be fine triggering the alert once the outbound FINISHED message is written to the wire. The same holds on the server: I'd always trigger once the AuthCertificateCallback is complete, regardless of its outcome (accepted or not). I've not checked NSS's behavior here: if PHA is requested, and the cert fails to verify, does NSS return the error as a fatal alert? Or is it up to the application code whether a failed PHA gives a fatal alert? The doc text for SendCertificateRequest seems to indicate that no fatal alert is sent in the event of invalid certificates, which is fine by me. I think that this last suggestion differs from the triggering during regular handshakes? If the handshake fails, the handshake callback won't trigger... We failed to get new, valid credentials, but--if the application needs to know that we negotiated new credentials, it can always save the previous PeerCertificate() prior to executing the PHA request and then check it in the callback and act accordingly. My 2c, - Alex -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
