Subject: [TLS] Call for acceptance on multi-stapling

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Apr 2012 17:02:22 -0400

WG members,

At the meeting in Paris there was broad consensus to adopt Yngve's
TLS Multi-Stapling draft
(http://www.ietf.org/id/draft-pettersen-tls-ext-multiple-ocsp-03.txt).

The WG chairs would like to confirm this consensus. Please send any
comments by Wednesday April 25.

-Ekr
[For the chairs]

---

From: Kyle Hamilton <[email-masked]>
Date: Wed, 18 Apr 2012 18:06:37 -0700

> comments by Wednesday April 25.

I believe that this is improper for TLS-WG to take up.  The problem
that multi-stapling is intended to address can be done completely
within an X.509 self-signed structure, and derives from PKIX-WG not
producing a single coherent standard that client protocols can simply
plug in.  Trying to work around a PKIX-WG problem in TLS is not going
to solve the same types of problems that exist in all other PKIX
client protocols.

If PKIX-WG could get its collective head out of its... darkness... I'd
say push this over there, and force them to come up with a real single
atomic credential format that can securely support asserting multiple
certificate chains, stapled OCSP responses for ALL certificates in ALL
chains, multiple timestamps... basically, TLS has one place to assert
one keypair.  All we need is a signature chain (or multiple signature
chains) to say that someone (an identified X.509 principal, not an
X.509 device) actually *gasp* used their own authority to assign a key
to a device.

That we can't do this is a bug in PKIX, not a bug in TLS.  That we
can't get multiple certificate status responses in a single structure
is a failure of PKIX, not TLS.  Working around it in TLS-WG is
inefficient, and will not solve the same problem in other PKIX client
protocols.

Unfortunately, because PKIX-WG can't/won't do anything because
everybody's too afraid of changing the status quo, this seems to be
the only effective option that presents.  I would prefer that it not
be handled here, but since the problem in PKIX (which won't change) is
exposed by TLS...

I (grudgingly) shall support this, with many reservations.

-Kyle H

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Apr 2012 03:45:41 +0200 (MEST)

Kyle Hamilton wrote:
> 
> Eric Rescorla <[email-masked]> wrote:
> >
 [quotations rearranged from Kyle's original response]
> I (grudgingly) shall support this, with many reservations.

I support adopting the work.

> to solve the same types of problems that exist in all other PKIX

This was a _known_ characteristic/shortcoming of X.509/PKIX when it
was (re-)used by SSLv3 and carried through to TLSv1.0, that revocation
checking was designed strictly out-of-band.  Originally CRLs, OCSP & SCVP
were later defined as alternative mechanisms, but similarly out-of-band.

Therefore I consider it INappropriate to blame X.509 for what it is
(even though I dislike this property of the X.509 architecture myself).

There are huge benefits associated with the multiple OCSP-responses
stapling, obviating the RP from additional third-party communication
in order to verify the TLS peer's certificate (chain), and protecting
the RPs privacy.  On top of this, the credential holder is in the
best position to ensure an efficiently accessible OCSP responder
for his own certificate (chain), efficiently cache OCSP responses
for his own cert (chain) and to refresh them out-of-band.

> inefficient, and will not solve the same problem in other PKIX client

Actually, I believe just the opposite.  While CRL suffers from a
design defect that can result in real world security vulnerability,
the OCSP design and the narrow set of acceptable signer certs is
a _huge_ improvement over CRLs, without that CRL signer design flaw.

-Martin

---

From: <[email-masked]>
Date: Wed, 18 Apr 2012 21:52:18 -0400

I support adopting draft-pettersen-tls-ext-multiple-ocsp as a working group item.

------------------------------------------------
Peter Robinson - [email-masked]
Engineering Manager
RSA, The Security Division of EMC - http://www.rsa.com/
Level 32, Waterfront Place, 1 Eagle Street, Brisbane, Queensland 4000, AUSTRALIA.
Phone: +61 7 3227 4427, Mobile: +61 407 962 150, Fax: +61 7 3227 4400.

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 Apr 2012 21:26:17 -0500

> to solve the same types of problems that exist in all other PKIX

Self-signed structure?  No.  If freshness indication is to be solved
via PKIX then it has to be backwards compatible with existing relying
parties' certificate validation code.  The obvious solution is to have
online CAs issuing short-lived certs to systems that posses the
corresponding long-lived cert, with the online CAs having different
keys from the issuers of the long-lived certs (of course).

I'd be quite happy with such a scheme.  Much happier than with OCSP
response stapling, and much, much happier than with a solution based
on self-signed certs that [presumably] hold the real cert and OCSP
responses.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Apr 2012 05:21:16 +0200 (MEST)

Nico Williams wrote:
> > I believe that this is improper for TLS-WG to take up. Â The problem
> > plug in. Â Trying to work around a PKIX-WG problem in TLS is not going

I'd be EXTREMELY UNHAPPY with short-lived certs, because it entirely
precludes cert pinning, a scheme that is magnitudes more secure than the
existing Alzheimer approach of to identifying servers with zero prior
knowledge over and over and over again.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Apr 2012 20:26:19 -0700

> knowledge over and over and over again.

Short-lived certs aren't a problem if you pin by public key, as in:
http://tools.ietf.org/html/draft-ietf-websec-key-pinning-01

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 Apr 2012 22:37:59 -0500

> knowledge over and over and over again.

Why would it prevent cert pinning?  Sure, you couldn't pin a hash of
the cert.  You'd have to pin one or more of: the subject public key,
the subject name and issuer, or both.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Apr 2012 05:56:28 +0200 (MEST)

Eric Rescorla wrote:
> 
> Martin Rex <[email-masked]> wrote:
> >

Credential management operations on the server are quite
risky for the availabilty of the server.  I doubt that I would
ever implement something like that for our server (and refuse
to do maintenance/support for such an architecture).

If there is some change on the CA that makes the resulting short-lived
server certs inacceptable (be it to clients or to responible servers
that check credentials before trying to use them) and *ALL* production
server depending on the CA will come to a grinding halt.

Given how complex PKIX/X.509 is and how crappy the CA software is
(boldly issuing certs with invalid or inconsistent content),
such a scheme would be IMO screaming for trouble.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Apr 2012 21:03:57 -0700

> such a scheme would be IMO screaming for trouble.

What I meant was that it wasn't an issue for cert pinning. Sorry if
that wasn't clear from the context.

That said,
1. I think you're somewhat overstating the case here: a reasonable
server will check rather before the short-lived cert expires, giving
you some time to detect errors and correct them.

2. It's not clear to me that this is a significantly worse set of problems
than OCSP stapling; for OCSP stapling to work correctly, it has to
be hard fail on the client and so bogus OCSP responses will also
bring all such production servers to a grinding halt.

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 Apr 2012 23:26:35 -0500

> bring all such production servers to a grinding halt.

+1.  Also, the cert needn't be short-lived so much as fresh (recently
issued).  Of course, we don't want online CAs issuing long-lived
certs, and to make up for their being online we must be prepared to
revoke them frequently, which means we still have a headache for cert
lifetime trade-off.  Still, if OCSP responses need to be fresh within
10 minutes, having short-lived certs live up to 24 hours but be
refreshed every ten minutes would probably work well enough.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Apr 2012 06:38:06 +0200 (MEST)

> you some time to detect errors and correct them.

24/7 availability of server admins for each and every important
server in a company.  That is creating lots of new jobs.
But the resulting TCO might make it a hard sell.

> bring all such production servers to a grinding halt.

OCSP stapling has the big advantage that things works pretty much
exactly like they do now.  Hard fail is not necessary, especially
not for the absence of the stapling.  The server can get and check
the OCSP responses before updating what it inserts as a black box into
ServerHelloExtension.  And even if something goes wrong on the
server with the OCSP response renewal, clients that have a necessity
to continue have three options available:

  - try to obtain OCSP responses themselves
  - try to work from CRLs instead
  - do their very own risk management about how old OCSP responses
    or CRLS they want to tolerate.

I would not be surprised if it's more than a magnitude easier to
(accidentally) cause a CA cert issuance malfunction than to cause
an OCSP server response malfunction by adminstrative action.
And while being soft about revocation is not uncommon, being
soft about cert expiration would be (and not alternatives possible).

If the software components involved in the usage scenarios
(CA software, servers, clients) are all from different vendors/suppliers,
then allegedly small changes can easily break things that that the
changing supplier didn't foresee (or care).

*I* would not even dare shipping something that brittle even for
a single supplier solution when 24/7 availabilty is important,

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Apr 2012 06:43:23 +0200 (MEST)

> refreshed every ten minutes would probably work well enough.

OCSP Responses fresh within 10 minutes?
Sounds like an extreme case of paranoia to me.  I likely would not
even support such frequent refreshes within our server software,
and probably enforce >= 1 hour on that configuration parameter.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 Apr 2012 23:47:04 -0500

> exactly like they do now.  Hard fail is not necessary, especially

If you want revocation to work then you must have some point where you
fail hard.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 Apr 2012 23:50:16 -0500

> OCSP Responses fresh within 10 minutes?

The point was that the ration of lifetime to freshness can be quite
large.  Whatever the freshness requirement, you can have the lifetime
of the credential be a fair be longer.

> and probably enforce >= 1 hour on that configuration parameter.

In the Kerberos world we typically see *service* ticket lifetimes as
short as one hour for plain services and as short as a few minutes for
high-value services, with TGTs being renewable for possibly many days.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 18 Apr 2012 23:59:22 -0500

OCSP stapling pros:

 - no changes to CAs

Fresh certs from online CAs pros:

 - no changes to concentrators (except to automate the refreshing of
certs and cert chains)
 - no or minimal changes to relying parties (TLS clients) to insist on freshness

OCSP stapling cons:

 - software/firmware changes required on TLS servers
 - software changes required on TLS clients
 - procedures needed to keep OCSP responses fresh

Fresh certs from online CAs cons:

 - changes to CA infrastructure required
 - procedures needed to keep certs fresh

Both should increase the amount of PKIX goop to send similarly (OCSP
responses vs. extra certs in the validation chain).

Hmmm.  I'm not sure yet which is more workable.  And then there's the
Chrome model of revocation to consider.  I think we need to debate
this some more.  Or at least we need more information.  If CAs refuse
to go along with the fresh, short-lived certs with online CAs approach
then that's that for that approach, but in terms of code (and
firmware) to change, this is much better than OCSP stapling.

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Apr 2012 22:03:53 -0700

>  - software/firmware changes required on TLS servers

This is required as well for auto-refreshing of short-lived certs, and
I believe that both IIS and Apache currently support OCSP stapling.

>  - software changes required on TLS clients

Currently, Chrome at least supports OCSP stapling and there are
patches for NSS. It's also not entirely clear that short-lived certs
don't cause clients to choke. They shouldn't, but don't and shouldn't
aren't always the same.

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 Apr 2012 00:36:46 -0500

> This is required as well for auto-refreshing of short-lived certs, and

Not really: if there are any interfaces suitable for automation you
can just automate the periodic installation of new certs.

> I believe that both IIS and Apache currently support OCSP stapling.

But not this extension, right?

> don't cause clients to choke. They shouldn't, but don't and shouldn't

With TLS it's like a box of chocolates...  (hint: they're all awful).

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Apr 2012 07:16:39 -0700

> can just automate the periodic installation of new certs.

You wish. :)

I believe that changing a cert in Apache, at least, involves
a restart.

> But not this extension, right?

Correct.

-Ekr

---

From: "Ryan Sleevi" <[email-masked]>
Date: Thu, 19 Apr 2012 07:54:17 -0700

>  comments by Wednesday April 25.

I support adopting this as a WG item.

---

From: Adam Langley <[email-masked]>
Date: Thu, 19 Apr 2012 11:01:03 -0400

> comments by Wednesday April 25.

I support the adoption of this as an item.

Cheers

AGL

---

From: Tom Ritter <[email-masked]>
Date: Thu, 19 Apr 2012 12:55:42 -0400

-tom

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 Apr 2012 11:57:09 -0500

> I believe that changing a cert in Apache, at least, involves

But at least it's possible.  And with a server farm and a freshness
requirement of, say, a few hours, outages can be avoided altogether.
Also, it's not Apache I'm concerned about, but the concentrators.  I
imagine some may require something like expect scripting to automate
server cert replacement (ewww).

>> But not this extension, right?

That's important.  It's clear that changes to concentrator
software/firmware are difficult to effect and deploy.  To me that's a
big problem with the OCSP stapling proposal.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Apr 2012 21:33:37 +0200 (MEST)

Nico Williams wrote:
>> Nico Williams <[email-masked]> wrote:
>>>> Nico Williams <[email-masked]> wrote:
>>>>> OCSP stapling cons:
>>>>>
>>>>> Â - software/firmware changes required on TLS servers
>>>>

First of all, the OCSP stapling extension will _not_ preclude that
you change your servers to use short-lived certs.

But short-lived certs create several additional operational problems,
because they expire so often.

 - on the client: you have to somehow recognize the short-lived certs and
   distinguish them from normal, long-lived certs and have the client
   skip traditional revocation-checking, so you would have to augment PKIX
   with a new attribute for that purpose and then update the entire
   installed base of TLS clients(!) and CA-Software... rather than
   just a few servers that will be under premium maintenance anyway
   if they important.

 - on the server: the changes necessary on the server to support OCSP
   stapling is in the ballpark of rfc5746 (renegotiation_info).
   the actual change to the TLS state machine is much smaller than
   rfc5746, but the acquisition of the OCSP staple is extra.

 - the real issue is about the management operation itself on the server.
   obtaining a new certificate from the CA typically requires mutual
   authentication, whereas obtaining a fresh OCSP staple can be
   performed over an insecure channel (followed by a validation that
   the info is valid).

 - short-lived certs interfere *badly* with TLS session caching,
   where clients may end up with factually expired certs after
   SSL session resumption.

> big problem with the OCSP stapling proposal.

This would be a total software logistics goof on the part of the
concentrator supplier if that was the case.  What use is a
?$$.$$$,- component if the vendor declares itself unable to
deploy a change of around 50 lines of code in a software update
under maintenance contracts?

The usefulness of a specialized concentrator looks somewhat overrated to me
(or might be an indicater of non-optimal server software behind it),
unless maybe you compare it to an Apache reverse proxy that does not
use SSL session resume on the connection to backend servers and
also has request pipelining disabled...

With a reasonable reverse proxy implementation, which sometimes is
included with the server software itself,  installed on an x86 or x64 PC,
performance should IMHO not be an issue.  With newer CPUs that support
AES-NI, maybe even less so.  Clients that are still limited to 3DES-EDE-CBC
are a little harder to serve, but far from unbearable.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Apr 2012 12:45:15 -0700

>   just a few servers that will be under premium maintenance anyway

This may or may not be an issue. Depends how clients behave if there
is merely no revocation information in extensions.

>   performed over an insecure channel (followed by a validation that

The assumption behind short-lived certiifcates is that they will be
provided over a public channel without authentication, precisely
as new OCSP responses can be. Certificates are public information
so as long as nothing has changed, you just reissue with the
same key.

>   where clients may end up with factually expired certs after

As far as I can tell, precisely the same situation obtains with
respect to the client's opinion of expired OCSP responses.

-Ekr

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 Apr 2012 15:10:04 -0500

> you change your servers to use short-lived certs.

Neither precludes the other.  That's not the question.  The questions
are: does one, the other, or both solve the problem at hand?  and if
both do, which is easier to deploy?

> because they expire so often.

No.  If clients hard fail when they can't check revocation status of a
server cert, then it the operational problem applies to both.  If
clients prompt when the server cert is expired or the client can't
check revocation status then both schemes are still equivalent.  If
clients neither hard fail nor prompt in one scheme but not the other
then that one scheme is useless (this could happen to both schemes).

You've not yet demonstrated that one scheme is worse than the other.

More importantly, we need to decide when clients (RPs, really) should
fail hard.  That's critical, no?

>   just a few servers that will be under premium maintenance anyway

No, you wouldn't be REQUIRED to "somehow recognize ..."  Doing so
helps reduce the amount of work the client does -- it's an
optimization, and a very good one, yes, but still, only an
optimization.

A new OCSP wstapling extension, on the other hand, can't be deployed
without client-side changes, much more extensive changes than those
needed to take advantage of fresh certs!

>   rfc5746, but the acquisition of the OCSP staple is extra.

Agreed.  But this is critical, no?  Server-side changes include
changes to concentrators, in some cases to firmware.  That's a high
barrier.

>   performed over an insecure channel (followed by a validation that

See EKR's response, with which I agree entirely.

>   where clients may end up with factually expired certs after

Depends.  I'm arguing for *fresh* certs more than for short-lived
certs.  Same semantic as for OCSP.  We could conceivably be using
long-lived certs for this, just refreshed frequently.  Nothing wrong
with that, eh?

> under maintenance contracts?

Well, this: http://www.imperialviolet.org/2012/04/11/falsestart.html
leads me to think that concentrator changes are much harder to get
than you think.  Google clearly worked very hard on False Start and
still came up short.  And we think that a new OCSP stapling extension
will fare better??  Why would that be so?!

Now, this is all about optimizing certificate revocation status
checking.  It's just an optimization.  A very good and desirable
optimization.  We need an optimization in this area.  The question is:
what's the path of least resistance to getting that optimization
deployed?

> [...]

Me too, but that doesn't change the reality of their being widely
deployed.  I doubt that reality is going to change anytime soon.

Nico
--

---

From: Geoffrey Keating <[email-masked]>
Date: 19 Apr 2012 13:34:10 -0700

> I believe that changing a cert in Apache, at least, involves

You can typically do it using 'apachectl graceful' without an
interruption to service, the same as any other Apache configuration
change.

---

From: Tom Ritter <[email-masked]>
Date: Thu, 19 Apr 2012 16:46:41 -0400

> will fare better??  Why would that be so?!

Browsers: We have worked with CAs for the past year on their OCSP
responders, and with websever developers for the past year on their
OCSP Stapling Support.  We are comfortable enough with OCSP Stapling
to run it on our own servers.  In x months/1 year we will be enabling
OCSP hard fail in our product.
BigCo: What does this mean for me?
Browser: It means that because your current certificate is not
stapled, your users will get slower performance visiting your website,
and if there is a network problem or failure on the OCSP responder of
your CA, the user cannot reach your site.  Also the user's browsing
habit is leaked to the CA, although you probably don't care.
BigCo: Thanks

BigCo: ConcentratorCo, I need OCSP Stapling support, do you provide it?
ConcentratorCo: No.
ResponsibleConcentratorCo: We do, we do!
ConcentratorCo: Shutup.

BigCo: Which is more important to us: not spending the money of
changing SSL Concentrators or eliminating the possibility that CA's
could go down and take down our site?

Perhaps I'm being a naive optimist, but I sincerely hope that
corporations will vote with their money and show these companies that
are _literally_ impeding the adoption of more secure technologies
throughout the _entire Internet_ (and not just Stapling, but TLS 1.1
too) that they are not interested in buying from a company that
provides less value than their up-to-date competitor.

I want to name and shame these companies that are slowing things down.
 I don't like this current trend of "certain companies do X".  Call
them out.  Journalism is want someone doesn't want you to print,
everything else is marketing. If a person takes adequate steps to
research the truthfulness of a statement - such as "We sent a TLS
ClientHello with a SNI extension to the server, and received an Alert.
 The same ClientHello sent without the extension did not produce an
alert" - you are covered legally.  Continuing to cover for these
companies that don't interoperate is doing their marketing for them.
It's frustrating for participants on this list, embarrassing at how
backwards this niche of security is, and it's ridiculous that I can
get better information about the Chinese Restaurant around the corner
than I can about the company I'm going to pay millions of dollars to
help run my secure infrastructure.

-tom

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Apr 2012 22:48:54 +0200 (MEST)

> so as long as nothing has changed, you just reissue with the

Sounds like an additional, brand-new enrollment protocol.

> respect to the client's opinion of expired OCSP responses.

Hardly.  The server cert is an integral part of the session state,
whereas the OCSP responses would quite probably be from a seperate
OCSP response cache.  So when the client processes the ExtendedServerHello,
it will stuff any OCSP responses from the existing single-OCSP or the
new stapled OCSP response into the global cache and continue, and
when processing the server's certificate handshake message, it
will check the global cache for acceptably fresh OCSP responses and
for all that are missing, expired or insufficiently fresh, the client
will, all by himself, decide whether to perform OCSP lookup itself,
whether the client considers that his privacy is more important and
uses only what he has on hand.

A TLS peer will not necessarily perform cert revocation checking
during certificate path validation on full handshakes, but instead
perform cert revocation checking *AFTER* the TLS handshake and
independent of whether the session was resumed or newly established.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 19 Apr 2012 13:54:06 -0700

> will fare better??  Why would that be so?!

False Start was not indicated by an extension, so a client could not
know whether the server supported it.  Google tried to blacklist known
incompatible servers, but they were unable to reliably determine if a
server needed to be blacklisted.

A concentrator that doesn't implement OCSP stapling will just ignore
the extension and proceed normally.

Mike

---

From: Marsh Ray <[email-masked]>
Date: Thu, 19 Apr 2012 06:54:29 -0500

On 04/14/2012 12:43 PM, Paul Hoffman wrote:
> <http://www.imperialviolet.org/2012/04/11/falsestart.html>
>
> Not a good sign for TLS changes that require field updates...
>
> --Paul Hoffman

On 04/19/2012 03:54 PM, Michael D'Errico wrote:
> Nico Williams wrote:
>> Well, this:
>> http://www.imperialviolet.org/2012/04/11/falsestart.html leads me
>> to think that concentrator changes are much harder to get than you
>> think. Google clearly worked very hard on False Start and still
>> came up short. And we think that a new OCSP stapling extension
>  know whether the server supported it.

I wonder why they didn't propose an extension to negotiate the use of
False Start. Surely that would fix the server intolerance problem.

 From http://www.imperialviolet.org/2012/04/11/falsestart.html
> The `servers' with problems were nearly always SSL terminators.

Perhaps they didn't think the WG would adopt it and/or the servers would
deploy support for it soon enough?

I would love to support a revised version of the proposal
http://tools.ietf.org/id/draft-bmoeller-tls-falsestart-00.txt
that negotiated via a TLS extension.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Apr 2012 23:52:39 +0200 (MEST)

> False Start. Surely that would fix the server intolerance problem.

+1

> that negotiated via a TLS extension.

+1, but I do not understand what kind of problem the Google proposal
has with the RSA key exchange method.  The functionality of FalseStart
and the RSA key exchange method are completely orthogonal (i.e. unrelated).

-Martin

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 Apr 2012 17:15:09 -0500

> server needed to be blacklisted.

Ahhh, good point.

> the extension and proceed normally.

Sure, ok.  As long as this is just an optimization that's ok.

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Thu, 19 Apr 2012 07:38:26 -0500

On 04/19/2012 04:52 PM, Martin Rex wrote:
>
> I do not understand what kind of problem the Google proposal

The thing with FS is that it could allow an active attacker to 
manipulate the handshake in ways which are not detected by the client 
until it receives the server's Finished message. But the whole point of 
FS is that the client sends application data bearing ciphertext before 
he gets the server's Finished.

So in general this would be a recipe for disaster (e.g. rollback 
attacks), except that certain ciphersuites might be judged "good enough" 
to use. For example, if the client sends the premaster secret by 
encrypting it with RSA to a properly-validated server cert, he might 
feel comfortable transmitting the app data encrypted with AES before 
knowing whether or not the handshake was manipulated.

When using DHE, the Server Key Exchange message ("sent by the server 
only when the server certificate message (if sent) does not contain 
enough data to allow the client to exchange a premaster secret") would 
appear to authenticate the handshake to the client. Assuming he 
validated it before deciding to start falsely.

There are other ways this could backfire. For example, if there were any 
extensions negotiated in the Hello exchange which were necessary for 
security. Are any extensions like that? I don't know. How about those 
extensions for the ECDH that "allow a client to negotiate the use of 
specific curves"? Certainly we'd have to be careful when adding future 
extensions how they might break in an FS environment.

The ciphersuite selection could be faked. The attacker could trick the 
client into parsing a validly signed ServerRSAParams structure as a 
ServerDHParams structure, or vice versa.

Nate Lawson feels that False Start is dangerous because of downgrade 
attacks, even allowing a BEAST attack.
http://rdist.root.org/2012/02/27/ssl-optimization-and-security-talk/

Still, the prospect of saving half a round trip in latency is quite 
attractive.

- Marsh

---

From: Adam Langley <[email-masked]>
Date: Thu, 19 Apr 2012 18:16:13 -0400

> False Start. Surely that would fix the server intolerance problem.

We wanted to try and speed up everything. Negotiating via an extension
significantly limits deployment as servers are rarely updated.

The hope was that the fallout would be limited and that we could clean
up HTTPS servers to the point where other clients could choose to
enable False Start without significant compatibility concerns. That
didn't work out I'm afraid.

> that negotiated via a TLS extension.

As of Chrome 20, False Start will be limited to servers supporting NPN
and forward secrecy. As that effectively limits it to Google servers
I'd be quite happy to respin the draft with an explicit extension
number if the WG will take it. (I guess the answer is to propose it
and see.)

Cheers

AGL

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 Apr 2012 17:17:01 -0500

> deploy support for it soon enough?

Dunno.  Suppose it'd worked?  Then it would have been wonderful that
it requires no server changes.  So that's my guess: Google was hoping
to have an optimization that works instantly with no changes required
on servers.

> that negotiated via a TLS extension.

Agreed.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Apr 2012 01:04:48 +0200 (MEST)

> validated it before deciding to start falsely.

I fail to understand what protection DHE provides over RSA.

http://tools.ietf.org/html/rfc5246#page-52

      struct {
          select (KeyExchangeAlgorithm) {
              case dh_anon:
                  ServerDHParams params;
              case dhe_dss:
              case dhe_rsa:
                  ServerDHParams params;
                  digitally-signed struct {
                      opaque client_random[32];
                      opaque server_random[32];
                      ServerDHParams params;
                  } signed_params;
              case rsa:
              case dh_dss:
              case dh_rsa:
                  struct {} ;
                 /* message is omitted for rsa, dh_dss, and dh_rsa */
              /* may be extended, e.g., for ECDH -- see [TLSECC] */
          };
      } ServerKeyExchange;

The digital signature in the ServerKeyExchange handshake message
IMO provides none such protection.

The client_random is under full control of the attacker, the server_random
is unpredictable by the client and whether the KeyExchange is performed
with signed ServerDHParams or the public RSA key from the server cert
is orthogonal to FalseStart.

Maybe the client does not want to use FalseStart if the encryption
strength of the server-selected cipher suite is poor, but since there
is nothing in DHE ServerKeyExchange that would protect TLS extensions
or the ciphersuite, I don't see a rationale why DHE is OK and RSA not.

> extensions how they might break in an FS environment.

FalseStart only makes sense in an environment, where the confidentiality
protection applied to application data that is optimistically sent
ahead of the handshake completion is deemed adequately strong to
not be susceptible to brute force decryption or iterative guessing.

But that depends on the PRF (which depends on the TLS protocol
version), the symmetric cipher strength and the strength of the
key exchange algorithm in general, but not on whether the latter
is DHE vs RSA.

> Still, the prospect of saving half a round trip in latency is quite 

It's half a round trip in the handshake tokens, and either nothing or a
full round-trip on the initial communication overhead.

For HTTP/1.x, where the client sends the request, there is *NO* saving
on the abbreviated handshake (aka session resume).

Unless either the server's or the client's tls session management is
significantly screwed, or majority of elements on the pages are completely
scattered all over different servers, the performance benefit will be
in the noise.  On reasonably configured, high-load servers I see

  full handshake : resumes

          98     : 2

if TLS session caching _works_.

And if session caching doesn't work, I see the CPU cores getting maxed out,
so that the saved roundtrip latency on the full handshake is more
than compensated by the CPU contention...

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Apr 2012 01:10:26 +0200 (MEST)

Typo on the  full handshake : session resumes.
                     2      :    98

Sorry,
-Martin

---

From: Adam Langley <[email-masked]>
Date: Thu, 19 Apr 2012 19:20:42 -0400

> Typo on the  full handshake : session resumes.

DHE/ECDHE makes a difference because, otherwise, an attacker can make
the client send data in a non-forward secure fashion by playing with
the handshake. (I don't believe that the signature in the
ServerKeyExchange signs anything useful in this situation.)

To the other point, your resumption rates are a lot better than mine :)

None the less, as a client, browsers frequently hit sites without
session resumption information. Either because it's a site that we've
never visited before, or because resumption information is only kept
in memory and browsers get restarted quite often.

The extra RTT to the server (without False Start) delays the fetch of
the initial HTML. That HTML frequently references blocking resources
on another HTTPS server, which, in turn, do the same thing. It's not
uncommon to go 3, 4 or even 5 layers deep with this. So we end taking
3, 4, or 5 extra RTTs due to the full handshakes.

That's why it's so attractive to remove round trips. Also keep in mind
that our biggest transport security problem is that most sites don't
use TLS at all and part of the reason is because of the additional
latency. So there's always complex tradeoffs between speed and
security in this domain.

Cheers

AGL

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Apr 2012 16:20:38 -0700

> Sounds like an additional, brand-new enrollment protocol.

There's no additional enrollment involved. You just HTTP fetch the
certificate from a specified location in the cert.

-Ekr

---

From: Marsh Ray <[email-masked]>
Date: Thu, 19 Apr 2012 08:41:28 -0500

> IMO provides none such protection.

Yes, you're right. I was misremembering. Probably thinking of the 
Certificate Verify message, but of course that's in the other direction.

> is unpredictable by the client

Well, interestingly, the client_random and server_random actually are 
signed along with the DH params. So at least the client can verify those 
values.

I don't know why they didn't just sign over a hash of all handshake 
messages to that point like in Cert Verify. A design decision from back 
when there was only one protocol version supporting DHE at all and no 
extensions to worry about.

> not be susceptible to brute force decryption or iterative guessing.

I think we should remember too that it's always the client's choice 
whether or not to start falsely. Even if it were a negotiated protocol 
feature it wouldn't commit the client to anything in advance, it only 
relaxes a sequencing constraint.

It also seems to require an API change: application code needs to hand 
the TLS stack some data in advance of a successful handshake result. 
Apps need to opt-in consciously.

I usually object to this line of reasoning, but it seems like the worst 
case is it turns out to be an exploitable browser bug of the sort that 
requires a MitM, less attractive to attackers than the drive-by 
exploitable sort of bug patched every week or two. So if a few 
closely-maintained client apps like browser vendors want to opt-in to 
it, that sounds like an honest risk-reward decision.

- Marsh

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Apr 2012 19:10:41 -0700

Good news. Thanks

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Apr 2012 04:48:55 +0200 (MEST)

Geoffrey Keating wrote:
> Eric Rescorla writes:

What is possible probably depends very much on the type
of Server you're using.

Does that work with Tomcat as well?

Our server does all connection management, TLS and the HTTP-protocol
processing within one multi-threaded process.  I added the
capability to update credentials and trust anchors gracefully
and transparently for the caller ~5 years ago, to get rid of
the process restart.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Apr 2012 05:21:30 +0200 (MEST)

Adam Langley wrote:
> > Typo on the Â full handshake : session resumes.
> >                       2      :    98
> 

I'm lost.  traffic protection keys will be newly derived in the
same fashion from the premaster secret for both, DHE/ECDHE and RSA
by using the PRF.

> To the other point, your resumption rates are a lot better than mine :)

If yours are worse than 4:96, then I strongly suspect problems with
your (or your clients) TLS session caching.

The 2:98 was measured on a big server (24 core) of a customer 6 years
ago who was facing significant load problems for two days every month
when a few million customers were trying to pick up their online billing
information.  The problem was due to a bug in the session caching
of our OEM TLS implementation when it reached the session cache limit
and purged the wrong session when adding to and already full cache,
resulting in a 98% full TLS handshakes and maxing out the CPUs.

By raising the default session cache size and lowering the time-based
expiration to 30min. the ratio reverse (98% resumes) and the CPU load
of the server dropped to the 10-20% range.

The impact of dysfunctional session caching is going to become
much worse with 2048-bit instead of 1024-bit RSA keys, because of
the 6-fold increase in processing times for RSA crypto operations.

> 3, 4, or 5 extra RTTs due to the full handshakes.

False can not possibly save on TLS session resumes with HTTP/1.x,
so I'm inclined to believe that your figures are be the result
of serious TLS session caching problems; and fixing those problems would
result in significantly higher improvement than FalseStart could achieve.

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 20 Apr 2012 09:53:32 +0200

> ServerDHParams structure, or vice versa.

Nice that you bring this up. I am working on attack involving
ServerDHParams and ServerECDHParams, and from what I have so far a
man in the middle attack is possible (with significant effort at
attacker's part though).

regards,
Nikos

---

From: Adam Langley <[email-masked]>
Date: Fri, 20 Apr 2012 12:34:06 -0400

> same fashion from the premaster secret for both, DHE/ECDHE and RSA

If the client is willing to False Start with an RSA ciphersuite then
it'll be encrypting the premaster secret to a fixed public key (the
one in the server's certificate) and sending data protected by that
encryption. Therefore that data isn't forward secure because I can
break into the real server and steal its private key from its disk.

Many TLS servers don't do forward secrecy anyway, so there's no loss
there and one could make a fair argument that the attack is
unrealistic. None the less, that's the thinking behind the
requirement.

> result in significantly higher improvement than FalseStart could achieve.

Of course we have significant resumption problems; this is the Internet :)

With my server-side hat on, we do everything we can but clients a)
don't do session resumption or b) restart quite often and flush their
caches. But if we assume that only competent clients will be doing
False Start anyway, we can discount a) as an advantage, certainly.

With my client-side hat on, many servers don't do session resumption
right. It's obscure and most administrators probably don't even know
that it exists. Fixing the world isn't something that I have the power
to do, so a client-side, unilateral change that can get us the same
effect is still very useful.

Cheers

AGL

---

From: Martin Rex <[email-masked]>
Date: Mon, 23 Apr 2012 23:21:04 +0200 (MEST)

> man in the middle attack is possible (with significant effort at

Looking at the TLS full handshake:

  http://tools.ietf.org/html/rfc5246#page-36

How about changing the ServerKeyExchange handshake message
to produce a digital signature over the handshake message hash
up to that point, i.e. ClientHello+ServerHello+opt. ServerCertificate
instead of only ClientRandom+ServerRandum,
plus the server key parameters as usual?

-Martin

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 24 Apr 2012 16:31:39 +0200

Eric Rescorla a écrit :
> It's also not entirely clear that short-lived certs

They make time synchronization problems at lot more acute.
This can be interpreted as "causing them to choke", I'd expect the scale 
of the problem to be larger than the one with false start.

---

From: Nico Williams <[email-masked]>
Date: Tue, 24 Apr 2012 09:39:24 -0500

On Tue, Apr 24, 2012 at 9:31 AM, Jean-Marc Desperrier <[email-masked]> wrote:
> This can be interpreted as "causing them to choke", I'd expect the scale of
> the problem to be larger than the one with false start.

They don't have to be short-lived, just fresh.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 24 Apr 2012 16:58:57 +0200

> comments by Wednesday April 25.

I support this as a working group item.

I also think the proposal would gain from allowing the OCSPResponseList 
to contain ARLs (authority revocation list) and not only OCSP token.

In my opinion, the cost is not big for the implementation, and they are 
real use cases, but this I mean a *lot* of deployed PKI that do not 
implement OCSP for intermediate certificates, but have an ARL available 
that is the same size, or smaller, than an OCSP token would be.

On another hand, I believe the ResponderID thing is not worth the effort.

In RFC2560, option 1 of 4.2.2.2 (locally configured responder) only 
works in a mutually agreed private context.
Option 2 and 3 (responder same as CA, responder with the 
id-ad-ocspSigning EKU) are the only one that work in a public context 
(and for example are mandated in the Mozilla policy) and they do not 
need this ResponderID thing.
Only option 1 would use it, when there's an ambiguity about which 
responder this specific client trusts, but then outside of multi-status 
there would be no way to get the same functionality with RFC2560.
So, including it seems to me to be implementation pain for extremely 
small and specific advantage.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Apr 2012 21:14:42 +0300

Hi Nico

> They don't have to be short-lived, just fresh.

I don't understand the distinction. If a relying party (in our case, the browser) requires that certificates are at most 24 hours old (presumably calculated by subtracting the current time from the notBefore field), what difference does it make if the notAfter field is 5 years in the future?

Yoav