RE: Secondary Certificates and 0-RTT

I think Ben’s point is that you could make a case for resumed-1-RTT still being authoritative for those other certificates, but it’s simpler for the HTTP layer not to have to differentiate between flavors of 1-RTT.  Therefore, in 1-RTT, everything has to be freshly proven.  You make a good point that there are operational reasons you might not want the resumption bound to all the certificates which were ever provided on a connection, though.



In your scenario, the increased disclosure is that the server receives the contents of a request that wouldn’t otherwise have been sent to it.  You’ll hopefully get back a 421, but that ought to be moot as you’ll also fail to get an updated secondary certificate for example.jp and never consume the response because it’s not authoritative.  The risk is the information leakage that’s already happened in the request, or in the fact that you made the request.



I think the fundamental question is whether we believe a potentially misdirected safe/idempotent request in the 0-RTT flight is risk enough to prohibit this case.  I haven’t heard an argument that we should change the stance of the document on what certificates are considered authenticated for 1-RTT data.



-----Original Message-----
From: Kazuho Oku <kazuhooku@gmail.com>
Sent: Thursday, July 12, 2018 9:45 PM
To: Ben Schwartz <bemasc@google.com>
Cc: Martin Thomson <martin.thomson@gmail.com>; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Secondary Certificates and 0-RTT



2018-07-13 10:55 GMT+09:00 Ben Schwartz <bemasc@google.com<mailto:bemasc@google.com>>:

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

>>

>> 2018-07-10 5:24 GMT+09:00 Ben Schwartz <bemasc@google.com<mailto:bemasc@google.com>>:

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

>>

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


>>

>>

>>

>> --

>> Kazuho Oku







--

Kazuho Oku