Re: Secondary Certificates and 0-RTT

2018-07-13 10:55 GMT+09:00 Ben Schwartz <bemasc@google.com>:
> 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.

That contradicts to what is stated in the http2-secondary-certs I-D.
It says: "Clients MUST NOT consider previous secondary certificates to
be validated after TLS session resumption."

As we have discussed, a resuming handshake does not involve the
primary certificate. Therefore, I would argue that the statement
should be applied to both 0-RTT and 1-RTT keys.

Anyways, let's discuss why the prohibition exists. The draft refers to
the increased impact when key is compromised and to the lack of proof.
But I think there is also a practical issue.

It is common for operators that run edge nodes in multiple locations
to have different set of certificates in each location. It could be
due to a contract with the customer (e.g. "I do not need my website
served from outside where my customers live"), could be due to
jurisdictional issue (e.g., "my website hosts contents that are
illegal in certain countries, and therefore it should not be served
from there"), or could be due to privacy concerns (e.g., "I do not
want to have the private key of my website stored in that country").

Consider the case where the client first connects to an edge node in
country A designating "example.com" using SNI, then obtains a
secondary certificate for "exmaple.jp" on that connection. Then, the
client successfully resumes the session to an edge node located in
country B designating "example.com". Note that the server IP address
is allowed to change when a session is resumed.

In this scenario, can the client assume that the resumed connection is
also authoritative for "example.jp"? As I have described, that is not
what we see in practice. If "example.jp" was not hosted in country B,
the client will be sending the request to an unauthorized server.

It is evident that this applies to both 0-RTT keys and 1-RTT keys.

To summarize, if we are to allow clients to assume that a resumed
connection is authoritative for the domains designated in the
secondary certificates offered in the previous connection, we need to
require servers that have overlaps between the set of the domains they
serve to serve the exact same set of domains. Such requirement not
only goes against current practice (as stated above), but is also very
hard to achieve (atomic update in a distributed environment!) and hard
to prove from client's side of view.

Therefore, I think that the prohibition should be retained.

> 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



-- 
Kazuho Oku

Received on Friday, 13 July 2018 04:45:18 UTC