Re: Secondary Certificates and 0-RTT

On Fri, Jul 13, 2018 at 6:20 PM Kazuho Oku <kazuhooku@gmail.com> wrote:

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

I agree (when the server chooses to resume).


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

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.


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