Re: Secondary Certificates and 0-RTT

2018-07-13 21:11 GMT+09:00 Ben Schwartz <bemasc@google.com>:
>
>
> On Fri, Jul 13, 2018 at 12:44 AM Kazuho Oku <kazuhooku@gmail.com> wrote:
>>
>> 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.
>
>
> By this logic, the client cannot consider previous primary _or_ secondary
> 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
> absurdum.
>
>>
>> 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.
>
>
> 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.

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

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



-- 
Kazuho Oku

Received on Friday, 13 July 2018 22:21:13 UTC