RE: Secondary Certificates and 0-RTT

I’m mostly inclined to Ben’s view.  The reasons why we decided that we wouldn’t make Secondary Certs carry forward into a new connection were:

  *   Those certificates had no relationship with the keys which would be established under the new connection

·         The security analysis for exported authenticators concluded that it was “difficult to formally prove that a server is jointly authoritative over multiple certificates, rather than individually authoritative over each.”

  *   There was no liveness proof that the peer still possesses those certificates, even if it did once

The first and third properties are also true of the primary certificate at the time the 0-RTT data is sent.  You’re speculatively sending requests to an authority for which you strongly suspect the server is still authoritative.  This is safe provided that you won’t consume a response until you have verified the server’s current possession of a certificate and the proof of possession is related to the keys under which you receive that response.  Ben’s proposal is equivalent as far as I can tell, though more formal security analysis is always welcome.

I think it would be reasonable to say clients MAY send requests for domains authenticated by a secondary certificate during 0-RTT, but if they do so, MUST also request that certificate again as part of the 0-RTT payload and MUST validate the new authenticator before consuming the response.  (Sending a CERTIFICATE_NEEDED after the request would communicate this state well, but might not be necessary.)

From: Ben Schwartz <bemasc@google.com>
Sent: Monday, July 9, 2018 1:25 PM
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Secondary Certificates and 0-RTT

On Mon, Jul 9, 2018 at 4:11 PM Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> wrote:
Either certificates are available after resumption or not.  0-RTT is
just resumption.  Of a particular kind, but it's still resumption.

In  my view, 0-RTT is before resumption, or possibly during, but not "after", which is what's currently written.

It might be possible to use 0-RTT to proactively probe for secondary
certificates while retaining this restriction, but if you want this, I
think that we need to discuss the reasons we opted not to allow those
secondary certificates to transfer to a resumed connection.

Indeed.  I'm not clear on the whole history of that decision, but my understanding is as follows:

1. At the end of the previous session, all certificates (primary and secondary) are on equal footing.
2. Under 0-RTT keys, nothing has changed to break this symmetry.
3. After session resumption, the 1-RTT keys represent a new Diffie-Hellman with the (new) primary certificate, so the 1-RTT keys are no longer tied to the old secondary certificates.

Therefore, not only should it be possible to probe for secondary certificates during 0-RTT, but it should be allowable to send (replay-insensitive) data to any of the secondary certificate domains under the 0-RTT keys.

The client can't trust a response (under 1-RTT keys) until after Secondary Certificate validation completes.  If it includes a proactive probe in the 0-RTT as well, then this doesn't have to add latency.

On Tue, Jul 10, 2018 at 1:32 AM Ben Schwartz <bemasc@google.com<mailto:bemasc@google.com>> wrote:
>
> Hi HTTP,
>
> Section 5.1 of the Secondary Certificate Authentication draft [1] says:
>    Clients MUST NOT consider
>    previous secondary certificates to be validated after TLS session
>    resumption.  However, clients MAY proactively query for previously-
>    presented secondary certificates.
>
> I think we should amend this to clarify the status of 0-RTT.  Here's a proposed change.
>    Clients MUST NOT consider
>    previous secondary certificates to be validated after TLS session
>    resumption.  However, clients MAY treat previous secondary certificates as validated
>    when sending TLS-1.3 0-RTT data, and MAY proactively query for previously-
>    presented secondary certificates in the 0-RTT data or after session resumption.
>
> This is my attempt to clarify that 0-RTT data retains the security scope of the session that is being resumed, which is the union of the validated certificates for that session.
>
> --Ben
>
> [1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-02#section-5.1