Re: Secondary Certificates and 0-RTT

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

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
>