Re: Secondary Certificates and 0-RTT

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?

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

Received on Thursday, 12 July 2018 03:35:51 UTC