Subject: Secondary Certificates and 0-RTT

From: Ben Schwartz <[email-masked]>
Date: Mon, 9 Jul 2018 11:28:49 -0400

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Jul 2018 06:11:17 +1000

Either certificates are available after resumption or not.  0-RTT is
just resumption.  Of a particular kind, but it's still resumption.

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.
On Tue, Jul 10, 2018 at 1:32 AM Ben Schwartz <[email-masked]> wrote:
> I think we should amend this to clarify the status of 0-RTT.  Here's a proposed change.
>    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

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 9 Jul 2018 16:24:46 -0400

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

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

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

---

From: Mike Bishop <[email-masked]>
Date: Mon, 9 Jul 2018 22:00:23 +0000

I’m mostly inclined to Ben’s view.  The reasons why we decided that we wouldn’t make Secondary Certs carry forward into a new connection were:

  *   Those certificates had no relationship with the keys which would be established under the new connection

·         The security analysis for exported authenticators concluded that it was “difficult to formally prove that a server is jointly authoritative over multiple certificates, rather than individually authoritative over each.”

  *   There was no liveness proof that the peer still possesses those certificates, even if it did once

The first and third properties are also true of the primary certificate at the time the 0-RTT data is sent.  You’re speculatively sending requests to an authority for which you strongly suspect the server is still authoritative.  This is safe provided that you won’t consume a response until you have verified the server’s current possession of a certificate and the proof of possession is related to the keys under which you receive that response.  Ben’s proposal is equivalent as far as I can tell, though more formal security analysis is always welcome.

I think it would be reasonable to say clients MAY send requests for domains authenticated by a secondary certificate during 0-RTT, but if they do so, MUST also request that certificate again as part of the 0-RTT payload and MUST validate the new authenticator before consuming the response.  (Sending a CERTIFICATE_NEEDED after the request would communicate this state well, but might not be necessary.)

From: Ben Schwartz <[email-masked]>
Sent: Monday, July 9, 2018 1:25 PM
To: Martin Thomson <[email-masked]>
Cc: HTTP Working Group <[email-masked]>
Subject: Re: Secondary Certificates and 0-RTT

On Mon, Jul 9, 2018 at 4:11 PM Martin Thomson <[email-masked]<mailto:[email-masked]>> 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.

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.

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 12 Jul 2018 12:35:24 +0900

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

-- 
Kazuho Oku

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 12 Jul 2018 09:47:34 +0300

> certificates that have been validated in the previous handshake.

Yes, I think it is not correct. All the certificates are not on equal
footing, because only the primary certificate has been incorporated, not
the secondary ones. And there is no new primary certificate if PSK is
used, because PSK can not be mixed with certificates (there is proposal
to allow it, but only with static PSKs).

And 0-RTT is very sensitive piece. It is much more difficult to analyze
than anything else in TLS 1.3. So a security issue that is not there for
just plain dynamic PSKs but is there for 0-RTT is not unthinkable for
me. I am certainly not able to make an analyisis of this.

The dynamic PSK keys also incorporate the primary client certificate,
but not the post-handshake ones. Which makes it unsafe to use dynamic
PSKs from connections that utilize post-handshake authentication, unless
the application protocol will not misbehave because of possbily
inconsistent connection states on both ends. Post-handshake
authentication also happens to be directly unsafe with some protocols,
even if resulting PSKs are not used.

There are two pieces in TLS 1.3 that actually scare me: One is 0-RTT
and the another is post-handshake authentication.

And HTTP/2 is one of the most sensitive protocols for various kinds of
security issues in underlying transport. Issues that are no problem
for most protcols can become nasty security problems in HTTP.

-Ilari

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Jul 2018 15:53:02 +0100

(For some reason the other thread made me wonder about
this...)

This may be handled already and even if not is probably
not a real-world problem, but do we know what happens if
the subjects/SANs from primary and 2ndary certs combined
result in there sorta being no valid names due to
excludedSubtrees in one nixing the names from the other?

I expect it'd be ok to say "ditch any 2ndary certs that
have excludedSubtrees" if any change is needed. There
are probably other workable answers too, but saying nothing
could easily lead to weirdness and maybe attacks if
different libraries behave differently.

I wonder if there are any other PKIX oddities that also
ought be noted? Might be worth a check of this draft
vs. 5280 with that in mind, as I don't recall PKIX (despite
it's longevity;-) considering the semantics of sets of
certs, which is what's in play here I guess.

Cheers,
S.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 12 Jul 2018 18:25:44 +0300

> excludedSubtrees in one nixing the names from the other?

I do not think certificates are supposed to interact with one another,
so ExcludedSubtrees can not nix names from the other.

> certs, which is what's in play here I guess.

Letting certificate chain affect the interpretation of the leaf
certificate is probably a bad idea. And letting certificate chains
affect interpretation of each other is much worse idea.

Besides the other problems, certificates affecting each other tends to
rather easily lead into intractable (not known to be efficiently
solvable) computational problems trying to make sense of what the
mess actually means. :-)

-Ilari

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Jul 2018 16:35:37 +0100

Hiya,

> so ExcludedSubtrees can not nix names from the other.

I guess that might be an ok answer too. OTOH, it's a bit
confusing if we can have one h2 session that is associated
with example.com via cert1 and via cert2 with 'example.net and
excluded=example.com'

If there's no possibility for confusion to arise that'd be
fine but I'm not sure.

> solvable) computational problems trying to make sense of what the

Yep. It would be a mess. (Frankly though x.509 is a mess already:-)
But I hope the secondary certs draft doesn't cause and/or avoids
that mess.

Cheers,
S.

---

From: Mike Bishop <[email-masked]>
Date: Thu, 12 Jul 2018 15:39:35 +0000

I'd agree, albeit with cursory knowledge of how excluded subtrees work.  The fact that one certificate (chain) is explicitly not valid for a certain subtree is unrelated to whether a different certificate chain is valid for a name in that subtree.

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Thursday, July 12, 2018 8:26 AM
To: Stephen Farrell <[email-masked]>
Cc: HTTP Working Group <[email-masked]>; Martin Thomson <[email-masked]>
Subject: Re: secondary certs and names (was: Re: Secondary Certificates and 0-RTT)

On Thu, Jul 12, 2018 at 03:53:02PM +0100, Stephen Farrell wrote:
> This may be handled already and even if not is probably not a 
> real-world problem, but do we know what happens if the subjects/SANs 
> from primary and 2ndary certs combined result in there sorta being no 
> valid names due to excludedSubtrees in one nixing the names from the 
> other?

I do not think certificates are supposed to interact with one another, so ExcludedSubtrees can not nix names from the other.

> I wonder if there are any other PKIX oddities that also ought be 
> noted? Might be worth a check of this draft vs. 5280 with that in 
> mind, as I don't recall PKIX (despite it's longevity;-) considering 
> the semantics of sets of certs, which is what's in play here I guess.

Letting certificate chain affect the interpretation of the leaf certificate is probably a bad idea. And letting certificate chains affect interpretation of each other is much worse idea.

Besides the other problems, certificates affecting each other tends to rather easily lead into intractable (not known to be efficiently
solvable) computational problems trying to make sense of what the mess actually means. :-)

-Ilari

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 12 Jul 2018 12:13:43 -0400

excludedSubtrees are restrictions on the issuer, not on the subscriber. It
would not make sense for them to interact with H/2 in any way.

Even restrictions on subscriber certs wouldn't make sense to apply -
they're restrictions on the keys, not the channels themselves.

The only interaction model that would be relevant is making sure both
certificates explicitly opt-in to being allowed as secondary certificates.
Given the risks that secondary certificates pose, this seems like a natural
and much-needed requirement. Without such a declarative opt-in, then as
mentioned at the mic at IETF 101, you have a scenario in which the
compromise of the private key of a certificate can be used virtually
undetectably to MITM (by combining Origin + Secondary Certs).

This approach - of requiring explicit consent - is a model that HTTP Signed
Exchanges have taken, among other reasons.

On Thu, Jul 12, 2018 at 11:39 AM, Mike Bishop <[email-masked]> wrote:

> I'd agree, albeit with cursory knowledge of how excluded subtrees work.
> The fact that one certificate (chain) is explicitly not valid for a certain
> subtree is unrelated to whether a different certificate chain is valid for
> a name in that subtree.
>
> I do not think certificates are supposed to interact with one another, so
> ExcludedSubtrees can not nix names from the other.
>
> certificate is probably a bad idea. And letting certificate chains affect
> interpretation of each other is much worse idea.
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Jul 2018 17:20:22 +0100

> would not make sense for them to interact with H/2 in any way.

True! Silly me for forgetting that.

S.

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 12 Jul 2018 21:55:06 -0400

> certificates that have been validated in the previous handshake.

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.

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 13 Jul 2018 13:44:46 +0900

2018-07-13 10:55 GMT+09:00 Ben Schwartz <[email-masked]>:
> 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!).
>
> 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.
>
>> >

-- 
Kazuho Oku

---

From: Mike Bishop <[email-masked]>
Date: Fri, 13 Jul 2018 05:22:02 +0000

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 <[email-masked]>
Sent: Thursday, July 12, 2018 9:45 PM
To: Ben Schwartz <[email-masked]>
Cc: Martin Thomson <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: Secondary Certificates and 0-RTT

2018-07-13 10:55 GMT+09:00 Ben Schwartz <[email-masked]<mailto:[email-masked]>>:

> On Wed, Jul 11, 2018 at 11:35 PM Kazuho Oku <[email-masked]<mailto:[email-masked]>> wrote:

>> 2018-07-10 5:24 GMT+09:00 Ben Schwartz <[email-masked]<mailto:[email-masked]>>:

>> > On Mon, Jul 9, 2018 at 4:11 PM Martin Thomson

>> > <[email-masked]<mailto:[email-masked]>>

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

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

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

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

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.

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.

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.

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

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

>> >> > Section 5.1 of the Secondary Certificate Authentication draft

>> >> > says:

>> >> >    resumption.  However, clients MAY proactively query for

>> >> > I think we should amend this to clarify the status of 0-RTT.

>> >> > Here's a proposed change.

>> >> >    resumption.  However, clients MAY treat previous secondary

>> >> > certificates as validated

>> >> >    when sending TLS-1.3 0-RTT data, and MAY proactively query

>> >> > for

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

--

Kazuho Oku

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 13 Jul 2018 14:43:17 +0900

2018-07-13 14:22 GMT+09:00 Mike Bishop <[email-masked]>:
> 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.

Thank you for the response.

For HTTP at least, I do not think that 0-RTT data can be considered to
only contain lower risk information than what is found in 1-RTT data.

The Early Data I-D allows a client to send any kind of request using
0-RTT. The defense we have is to postpone the processing of the
request rather than prohibiting the use of 0-RTT for certain types of
requests.

Even if it is the case that browsers only send idempotent GET requests
using 0-RTT, they could still have a cookie associated to it. The
result will be a disclosure of an access credential to an unauthorized
host.

>>> > <[email-masked]>
>
>>> > wrote:
>
>>> >>
>
> 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.
>
> 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.
>
>
>
> 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.
>
>
>

-- 
Kazuho Oku

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 13 Jul 2018 08:11:53 -0400

On Fri, Jul 13, 2018 at 12:44 AM Kazuho Oku <[email-masked]> wrote:

> >> > Diffie-Hellman
> >> > with the (new) primary certificate, so the 1-RTT keys are no longer
> tied
> >> > to
> perform
> valid

By this logic, the client cannot consider previous primary _or_ secondary
certificates to be validated after session resumption!  Reductio ad
absurdum.

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

The SNI, chosen by the client, has no impact on whether the server is
authorized to receive the request.  If the server has the resumption PSK,
then it will be able to resume regardless of what the SNI says.

The primary certificate can easily be different between servers that can
resume each other's sessions, so it's clearly not relevant either.

The only question is: do you believe that we must support having a server
that holds the resumption PSK, but nevertheless is not authorized to
receive data encrypted to that PSK?  If so, TLS cannot help you.  Instead,
it seems what you are arguing for is that TLS session resumption, be it
0-RTT or 1-RTT, can only be used for an HTTP authority whose name currently
resolves to the IP address of the server.  A secure client in your model
doesn't have to redo Secondary Certificate Authentication (SCA), but it
does have to redo resolution of any name it wants to use after resumption,
even names that were present in the original primary certificate.

I don't agree with this threat model, but I also think it's independent of
SCA, and not relevant to my proposed change.  Under this threat model, if I
have valid name resolutions that show two names at the same IP address, and
both of those names were covered in a previous session, I should be able to
resume the session, put one name in the SNI, and include requests for both
in the 0-RTT data.  This is equally true whether the second name was bound
to the original session by SCA or the primary certificate's SAN.

> valid
> might
> worthwhile
> >> > Secondary
> Here's
> >> >> > a
> >> >> > session

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 14 Jul 2018 07:20:48 +0900

2018-07-13 21:11 GMT+09:00 Ben Schwartz <[email-masked]>:
> certificates to be validated after session resumption!

That is incorrect observation.

The primary certificate can be considered valid because the session
ticket is tied to the handshake transcript that is derived from the
previous handshake that involved the primary certificate.

What I am referring to is the original claim that based on the
incorrect assumption that *because primary certificate is involved in
the resuming handshake*, the connection loses the tie to the secondary
certificates that it had during 0-RTT (see point 3 of [1]). Actually,
primary certificate is not involved in the resuming handshake, and
therefore it should be considered that 0-RTT and 1-RTT are authorized
for the same set of certificates.

> Reductio ad

No. If you bind different Session Ticket encryption keys (STEKs) to
each of the server certificate, a server that is incapable of
performing a full handshake for a server certificate it cannot sign
will never be possible to accept a resuming handshake for the host,
nor even decrypt the 0-RTT data.

I understand that some large scale providers might not be doing this.
That is fine if either of the following properties are met:
a) 0-RTT is not used and you can trust the code running on any of the
edge nodes (i.e. the code that rejects resumption based on SNI)
b) all the websites being hosted has equivalent jurisdictional
requirements, and all of them are happy with the security guarantees
provided by the weakest edge node

But as I have pointed out in [2], there are cases that do not meet
such properties.

[1] https://lists.w3.org/Archives/Public/ietf-http-wg/2018JulSep/0047.html
[2] https://lists.w3.org/Archives/Public/ietf-http-wg/2018JulSep/0098.html

> that holds the resumption PSK, but nevertheless is not authorized to receive
> data encrypted to that PSK?  If so, TLS cannot help you.  Instead, it seems
> what you are arguing for is that TLS session resumption, be it 0-RTT or
> 1-RTT, can only be used for an HTTP authority whose name currently resolves
> to the IP address of the server.  A secure client in your model doesn't have
> to redo Secondary Certificate Authentication (SCA), but it does have to redo
> resolution of any name it wants to use after resumption, even names that
> were present in the original primary certificate.
>
>> > of
>> >> > Certificate validation completes.  If it includes a proactive probe
>> >> > in
>> >> > the

-- 
Kazuho Oku

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 13 Jul 2018 19:23:48 -0400

On Fri, Jul 13, 2018 at 6:20 PM Kazuho Oku <[email-masked]> wrote:

> is
> not
> secondary
> >> >> >> certificates while retaining this restriction, but if you want
> this,
> >> >> >> I
> derived

I agree (when the server chooses to resume).

> But as I have pointed out in [2], there are cases that do not meet

Yes, but the cases that do not meet these properties (with the set of
certificates in question) cannot use Secondary Certificate Authentication
anyway.  I am talking about resumption of Secondary Certificate
Authentication sessions.

> receive
> >> > data, because (a) 0-RTT is already special for HTTP/2 and (b) this
> saves
> >> > a
> domains
> >> >> > under
> security
> >> >> >> > scope

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 14 Jul 2018 16:52:35 +0900

> anyway.  I am talking about resumption of Secondary Certificate

They can.

Such servers can use secondary certificates under the current rule
that a client cannot trust them after resumption. This is because
there is an assumption that once a server certificate is verified by a
client, it is considered valid at least for the lifetime of the
connection.

Such servers do meet the assumption, and can send secondary
certificates that would be considered valid for the lifetime of the
connection.

>> >> > to maintain the previous session's secondary certificate state for
>> >> > the
>> >> > 0-RTT

-- 
Kazuho Oku

---

From: Ben Schwartz <[email-masked]>
Date: Sat, 14 Jul 2018 11:30:29 -0400

On Sat, Jul 14, 2018 at 3:52 AM Kazuho Oku <[email-masked]> wrote:

> >> >> > session resumption or start a new session.  If the server chooses
> to
> >> >> > use

OK, I think I understand the scenario you are describing.  I would clarify
this by adding the following text to the Secondary Certificate
Authentication draft:

"A server that enables 0-RTT resumption MUST NOT share a session's
resumption secrets with another server unless that server is authoritative
for all the domains that might be covered by this session."

This is as opposed to the policy that you were proposing: that servers
using SCA can share a session's resumption secrets if they are both
authoritative for the session's primary certificate.

>
> >>
> >>
> >> [1]
> https://lists.w3.org/Archives/Public/ietf-http-wg/2018JulSep/0047.html
> >> [2]
> https://lists.w3.org/Archives/Public/ietf-http-wg/2018JulSep/0098.html
> >>
> >> >
> >> > to the IP address of the server.  A secure client in your model
> doesn't
> >> > have
> >> > to redo Secondary Certificate Authentication (SCA), but it does have
> to
> >> > redo
> >> > I don't agree with this threat model, but I also think it's
> independent
> >> > of
> >> > have valid name resolutions that show two names at the same IP
> address,
> >> > and
> >> > both of those names were covered in a previous session, I should be
> able
> >> > to
> >> >> >> >> On Tue, Jul 10, 2018 at 1:32 AM Ben Schwartz <
> [email-masked]>
> >> >> >> >> wrote:
> >> >> >> >> >
> >> >> >> >> > Hi HTTP,
> >> >> >> >> >
> >> >> >> >> > of the session that is being resumed, which is the union of
> the
> >> >> >> >> > validated