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

Alyssa Rowan <akr@akr.io> Wed, 02 April 2014 06:20 UTC

Return-Path: <akr@akr.io>
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 0716A1A0140 for <tls@ietfa.amsl.com>; Tue, 1 Apr 2014 23:20:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 3OhOZdUSEKR5 for <tls@ietfa.amsl.com>; Tue, 1 Apr 2014 23:20:00 -0700 (PDT)
Received: from entima.net (entima.net [78.129.143.175]) by ietfa.amsl.com (Postfix) with ESMTP id CE8C31A013A for <tls@ietf.org>; Tue, 1 Apr 2014 23:19:59 -0700 (PDT)
Received: from [10.10.42.10] (cpc5-derb12-2-0-cust796.8-3.cable.virginm.net [82.31.91.29]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by entima.net (Postfix) with ESMTPSA id 6E45460171 for <tls@ietf.org>; Wed, 2 Apr 2014 07:19:55 +0100 (BST)
Message-ID: <533BAC14.90803@akr.io>
Date: Wed, 02 Apr 2014 07:20:04 +0100
From: Alyssa Rowan <akr@akr.io>
MIME-Version: 1.0
To: tls@ietf.org
References: <EBC54843816A0E9AD64C880F@96B2F16665FF96BAE59E9B90> <CAKC-DJi2CHC5Jqu77qE7NxgF0P5QdhQvsRdfdzvhLeHbCnC0iA@mail.gmail.com>
In-Reply-To: <CAKC-DJi2CHC5Jqu77qE7NxgF0P5QdhQvsRdfdzvhLeHbCnC0iA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/c4tq7ea6fZThWgD8Sbv6vCFASkw
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 06:20:07 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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

> 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.

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
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTO6wUAAoJEOyEjtkWi2t6YpEP+wW2B23Ig8sBFV7pWnhowGLG
dqYTEPDRYn0XPTKTqYm4Nmg+fZedfhiFj/T6jkN+gMV6hTUKYOpBRfX0u+1RLtDl
zSHQ0T9n9Sf7oWbhSn6sgZ3iLDlLfelHm66iJCiBJqLXoWWBKBz1aFjiyzJkWSNP
nBhY9BqGPVvR8LhT5Yzz9Lrg5PSh2eQ3BoJvZMssp6VvMcIEkzDwC1wDRaWBBUCS
6h2Jksj67CyKG5v/uC7S9PVUFvdB+CbJanT75Jua5tXcAVFixBfXuXcjA6TAUPeb
y9KWcBD6n3uvKgF3onrcBYKb16cxh3bS8spATy/l59m3MewQsTBqIjpOrP5jjPMl
8cLlGwrGFEaHPnJytWfcxjih1gIs4KqtT7SS6MvB2Mmp2uLQiuA7qF3sQHCNLO8g
fWT2YGQ6qACXT8nBdZyTvKjJlEb6SoT39btk/w7fdWDjepDcaIjIWPV+8KNoPbAS
ybv/7YPmKxV8LytcPDZpGwwCYz6K4Ru5Lo1/XrHtYyuy6RZ3lG7/Fdr85NaYHQDM
d7jYENHNak3FoB3PqktuqIr1A7LwCPvbg5BcVtrzfDqEftWfdBkIbUgK1W0EjI1h
HuOYjSuCknK4TonRcdqkAejhN33LNBtFjU20h0QMLPQOD/lCLQAnscP1NjENtMuW
qEVTCggR64L9Ntv8JRlb
=3YuW
-----END PGP SIGNATURE-----