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

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 <erik+ietf@nygren.org> 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.)
> 
> 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 <chris.newman@oracle.com> wrote:
> 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
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls