Re: Secondary Certificates and 0-RTT

On Wed, Jul 11, 2018 at 11:35 PM Kazuho Oku <kazuhooku@gmail.com> wrote:

> 2018-07-10 5:24 GMT+09:00 Ben Schwartz <bemasc@google.com>:
> > 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.
>
> I am not sure if that is correct.
>
> When the session is resumed, the primary certificate is not sent.
>
> 0-RTT key is derived from the previous handshake. 1-RTT key is derived
> from the previous handshake and the key exchange of the resumption.
>
> So I would assume that Martin is correct; both 0-RTT and 1-RTT keys of
> a resumed session will be either valid or invalid for the secondary
> certificates that have been validated in the previous handshake.
>
> Am I missing something?
>

You are right.  Let me try my third stage again:

3. In response to the ClientHello, the server can choose whether to perform
session resumption or start a new session.  If the server chooses to use
session resumption, then the 1-RTT state (after resumption) is equally
valid for all the primary and secondary certificates of  the previous
session.  However, if the server chooses not to use session resumption, it
will perform a full TLS handshake instead, and the 1-RTT state will only be
valid for the new primary certificate (which might not be the old primary
certificate!).

Or, more briefly: after session resumption is attempted, the session might
no longer be tied to the old secondary certificates.

I think it's reasonable to avoid surfacing (to HTTP/2) the distinction of
whether the server opted to resume or not.  However, I think it's
worthwhile to maintain the previous session's secondary certificate state
for the 0-RTT data, because (a) 0-RTT is already special for HTTP/2 and (b)
this saves a roundtrip when resuming (or attempting to resume) Secondary
Certificate sessions.

>
> > 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
>
>
>
> --
> Kazuho Oku
>