Re: Secondary Certificates and 0-RTT

On Sat, Jul 14, 2018 at 3:52 AM Kazuho Oku <kazuhooku@gmail.com> wrote:

> 2018-07-14 8:23 GMT+09:00 Ben Schwartz <bemasc@google.com>:
> >
> >
> > 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.
>
> 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.
>

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