Subject: [TLS] Alert type for connection limit or server busy?

From: Chris Newman <[email-masked]>
Date: Tue, 01 Apr 2014 12:35:38 -0700

Is there a TLS Alert type that can be used by a TLS server to reject a TLS
client connection based on a per-IP-address connection limit?

The idea would be to have the server reject the connection before spending
cycles on the TLS negotiation. But it's important to inform the client why the
connection is rejected in order to reduce the number and severity of support
calls that might be generated by such a limit if the connections were silently
dropped.

Another case that's interesting is when the server is temporarily overloaded
and wants to reserve CPU cycles for existing connections rather than spending
cycles accepting new connections. Again, it's desirable to indicate to the
client the cause of this connection failure in an attempt to reduce the number
and severity of support calls and also desirable not to spend unnecessary
server time on the TLS negotiation.

With the STARTTLS model, applications could just reject at the banner with a
text error message. But with the separate-port-for-TLS model, this needs to be
done in the TLS layer.

I didn't see appropriate alerts in RFC 5246 section 7.2.

Could alerts for these two cases be added as an extension or a TLS 1.3 feature?

		- Chris

---

From: Erik Nygren <[email-masked]>
Date: Tue, 1 Apr 2014 22:44:29 -0700

Along these lines, it would be worth discussing an optional proof-of-work
extension such that the server could introduce an extra RT by pose a
problem back to the client under certain overload circumstances and then
wait for a successful response from the client before performing additional
cryptographic operations.  This would be something that would normally only
be used when the server is under attack to help it selectively raise the
bar.  (Clients could also chose to abandon the connection.)

For example, a server under attack could propose back to clients:

           { partial_value, num_bits, SHA256(full_value) }

where the first num_bits of full_value have been zeroed out.  The client
must respond back with full_value before the the server will spend
additional CPU time on the negotiation.  This also lets the server select
different values for num_bits depending on how much load it is intending to
shed (or perhaps based on how many connections have come in from that
particular client recently).

While not necessarily being "fair" to low-powered devices, it would be
extremely valuable for allowing servers to selectively shed load by
controlling how symmetric the workload for a given set of clients must be.

         Erik

On Tue, Apr 1, 2014 at 12:35 PM, Chris Newman <[email-masked]>wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Alyssa Rowan <[email-masked]>
Date: Wed, 02 Apr 2014 07:20:04 +0100

On 02/04/2014 06:44, Erik Nygren wrote:

> where the first num_bits of full_value have been zeroed out.

Otherwise known as "hashcash".

It's been noted (by Satoshi Nakamoto, I think?) that you get better
granularity with "here's an integer: find me a value that hashes to
less than that" (given a particular form of integer
representation<->octets).

Of course, the server would have to spend cycles generating and
validating challenges.  Not as many as the clients, but still, cycles.

I don't think this is necessarily useful.  Might even make a DoS
surface more visible.

- -- 
/akr

---

From: Alyssa Rowan <[email-masked]>
Date: Wed, 02 Apr 2014 07:23:25 +0100

> Otherwise known as "hashcash".

[Ugh, shouldn't post before breakfast, mistake. It's not hashcash,
 although it is kinda like it. Reverse hashcash, maybe.]

It'd have to remember full_value under overload conditions, though.
Unless that's shared, that's memory (stored) or CPU (generated).

- -- 
/akr

---

From: Erik Nygren <[email-masked]>
Date: Tue, 1 Apr 2014 23:34:59 -0700

> validating challenges.  Not as many as the clients, but still, cycles.

Of course, but considerably less (orders of magnitude less?).  Very similar
to the cycles used in syncookies.

> Unless that's shared, that's memory (stored) or CPU (generated).

Not necessarily.  If structured right, the server could construct
full_value from something
like { HMAC-SHA256(key, nonce || client_ipaddr) || nonce }
that could be reconstructed when the client returns.  The server might then
went
to keep these around for a bit for *accepted* connections to avoid replay
attacks.

(Disclaimer:  I'm not a cryptographer, so the example given was more
a sample type of proof-of-work rather than a particular proposed
implementation.)

        Erik

On Tue, Apr 1, 2014 at 11:23 PM, Alyssa Rowan <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJTO6zdAAoJEOyEjtkWi2t6UiYP+wawQNs3Y1jWl/IPCngGKISe
> TjW4zbSI8zOjbk6gCrkI3tMnUHIchWMR972EaFNqDBGT9LIMir4ak1vpD/m+g7pG
> 1F4KgVH+b7iJ/Z/ZfISNNjXx6MoqDmWjLVoxbiHghjTEkf0ElinNNsOu7QE9znzd
> mRpfQofHf2V6xSZt4PmE/oLUtXjiEda2WG3AW8OhOLdjw+Ihgs4fN9SxsLjYq4/7
> vznGO8qXQYAfh95XZQ1VsT9lf2mMASW/lH10czb4djXYrp7wNKQ2aG16PmSozZdr
> qnCYb4IZ3YciG16mQ5sBiPf0wtEu9tpc/BeYpGVFkm2c/chjS7jzoP4gjehyWihm
> eB8e/dO7HwIk+iaF1M+0VA4KkmcEqKHTFMsqyD0d0RR5J5ejbAn3T8Kae3OyNpUA
> 9t/4SdI/Wrt9o5r1hCS1p8LjeksmENJMjQE6Z21lPX5RkGJ2+F1Zk5ieNMjcFEOA
> UYXK5DWcs+Wofw3+dcR++zQyDgYSr3L8UgUZltOQIrESmrGq4bSeRXuPa2lwyOus
> /n3aSeuBqOAqbKfVFkCC6l86BJH2/GybEIsP70RHZgcWXdCpIWhitxD/jM8w2LUr
> biMVUzbGviDyo1S3JSCu82tQBqqzixD7UmCCRSKtmtwJjCtp39igKMtdKHIy6URo
> u4FgGxztq8HWjV30W323
> =31sI
> -----END PGP SIGNATURE-----
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 2 Apr 2014 10:23:54 +0300

Hi Erik

I raised a similar idea on the SAAG mailing list and at the SAAG meeting in London. This method is often called “client puzzles”. For me this is interesting for both IKE and TLS.

There is an issue that makes this a hard sell, and that is a patent.  See my post to SAAG: http://www.ietf.org/mail-archive/web/saag/current/msg04579.html

I’ve asked some people who work for the patent owner, and am waiting to hear from them.

Yoav

On Apr 2, 2014, at 8:44 AM, Erik Nygren <[email-masked]> wrote:

> Along these lines, it would be worth discussing an optional proof-of-work extension such that the server could introduce an extra RT by pose a problem back to the client under certain overload circumstances and then wait for a successful response from the client before performing additional cryptographic operations.  This would be something that would normally only be used when the server is under attack to help it selectively raise the bar.  (Clients could also chose to abandon the connection.)
> 
> where the first num_bits of full_value have been zeroed out.  The client must respond back with full_value before the the server will spend additional CPU time on the negotiation.  This also lets the server select different values for num_bits depending on how much load it is intending to shed (or perhaps based on how many connections have come in from that particular client recently).  
> 
> While not necessarily being "fair" to low-powered devices, it would be extremely valuable for allowing servers to selectively shed load by controlling how symmetric the workload for a given set of clients must be.
> 
>          Erik
> 
> 
> 
> On Tue, Apr 1, 2014 at 12:35 PM, Chris Newman <[email-masked]> wrote: