Re: Secondary Certificates and 0-RTT

2018-07-13 14:22 GMT+09:00 Mike Bishop <mbishop@evequefou.be>:
> 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.

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



-- 
Kazuho Oku

Received on Friday, 13 July 2018 05:43:43 UTC