Re: Secondary Certificates and 0-RTT

On Mon, Jul 9, 2018 at 4:11 PM Martin Thomson <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> 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
>