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

Erik Nygren <erik+ietf@nygren.org> Wed, 02 April 2014 05:44 UTC

Return-Path: <nygren@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E7C1A0134 for <tls@ietfa.amsl.com>; Tue, 1 Apr 2014 22:44:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTyW4B3k76wK for <tls@ietfa.amsl.com>; Tue, 1 Apr 2014 22:44:34 -0700 (PDT)
Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 250F71A0133 for <tls@ietf.org>; Tue, 1 Apr 2014 22:44:33 -0700 (PDT)
Received: by mail-vc0-f182.google.com with SMTP id ks9so10982423vcb.41 for <tls@ietf.org>; Tue, 01 Apr 2014 22:44:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4EC/bDyrqAW6n6/LHIV4bMnBT7pH6DyKSLotyB+WZCc=; b=imng/5r1d2damalvONpt/27R0tDIYZGMVnqPb2MNnLjGNHidiOZRywNuq6au0jvX0f YgGgmLRMxiqtMGLFLLCfw0DKrGMobcxaftZ6XHFgtZ+q8xX4zn8D/bUKX/i1b0v0E9td bjnqpN11dPElckgGbxOFhS0ShUlkzgrWW6GROudUe5rST/cP4REXHr+kBpUto8fTGDcz D+94L3CsNSP0jZA8STBhWvMgPeUxYLwQwvmIG/I0vX8KLygVJNF8Q6SibCS03hQRA8o6 DPlETF3wAC3BoLvOShydKsHQNTHQ4hbJ0u++21nDaMtYtdlBIyMvWicnuZ2dzyME2Ip/ Y+jg==
MIME-Version: 1.0
X-Received: by 10.52.249.105 with SMTP id yt9mr5717726vdc.34.1396417470077; Tue, 01 Apr 2014 22:44:30 -0700 (PDT)
Sender: nygren@gmail.com
Received: by 10.221.18.70 with HTTP; Tue, 1 Apr 2014 22:44:29 -0700 (PDT)
In-Reply-To: <EBC54843816A0E9AD64C880F@96B2F16665FF96BAE59E9B90>
References: <EBC54843816A0E9AD64C880F@96B2F16665FF96BAE59E9B90>
Date: Tue, 01 Apr 2014 22:44:29 -0700
X-Google-Sender-Auth: A4gmLMwwCvFHvAq0lw8Eft9Uawk
Message-ID: <CAKC-DJi2CHC5Jqu77qE7NxgF0P5QdhQvsRdfdzvhLeHbCnC0iA@mail.gmail.com>
From: Erik Nygren <erik+ietf@nygren.org>
To: Chris Newman <chris.newman@oracle.com>
Content-Type: multipart/alternative; boundary="089e0153686443223004f608c70f"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FG4MhdEnBi0npte1CZgyyZjWt48
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Alert type for connection limit or server busy?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Apr 2014 05:44:38 -0000

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
>