Re: [TLS] Comments on TLS identity protection

Eric Rescorla <ekr@networkresonance.com> Wed, 20 December 2006 16:08 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx3zJ-0006el-KQ; Wed, 20 Dec 2006 11:08:13 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx3zG-0006ed-NU for tls@ietf.org; Wed, 20 Dec 2006 11:08:11 -0500
Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx3zF-0003Bg-Cn for tls@ietf.org; Wed, 20 Dec 2006 11:08:10 -0500
Received: by raman.networkresonance.com (Postfix, from userid 1001) id 973641E8C5D; Wed, 20 Dec 2006 08:08:08 -0800 (PST)
To: badra <badra@isima.fr>
Subject: Re: [TLS] Comments on TLS identity protection
References: <B356D8F434D20B40A8CEDAEC305A1F24038FD72F@esebe105.NOE.Nokia.com> <458959A2.8020309@isima.fr>
From: Eric Rescorla <ekr@networkresonance.com>
Date: Wed, 20 Dec 2006 08:08:08 -0800
In-Reply-To: <458959A2.8020309@isima.fr> (badra@isima.fr's message of "Wed, 20 Dec 2006 16:41:22 +0100")
Message-ID: <86slfaim8n.fsf@raman.networkresonance.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR <ekr@networkresonance.com>
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

badra <badra@isima.fr> writes:
> Pasi.Eronen@nokia.com a écrit :
>> The fact that anybody can
>> connect at any time does not automatically imply that lots of people
>> are connecting all the time! (And in particular, lots of people
>> without client certificates connecting all the time to servers that
>> always require client
>> authentication, and without malicious intent to DoS the server.)
>>
> But the "anybody" that can connect at any time will be able to
> establish several "double handshake" in parallel; especially when TLS
> is used over EAP or UDP (I don't have data but maybe Eric).
>
> My point is that double handshake will increase complexity and will
> not help in reducing TLS server overload factor, especially when
> legitimate clients that don't have certificates are trying to
> connect. Their number is not actually important.

Wait, there are two issues here:

1. General server load in the absence of malicious behavior.
   As Pasi points out, there's no evidence that the double
   handshake technique is widely enough used to cause this
   to be a problem.

2. Enabling DoS attacks. There are lots of ways to DoS a
   TLS server, and since this only doubles server load, 
   I don't think it's much of an amplifier.

>>>> (at least sufficiently to spend the $$$ for designing,
>>>> implementing,  testing, deploying, etc. a new mechanism).
>>>>
>>> How much :). The proposed changes are minimal.
>>>
>>
>> To get widespread deployment, several TLS implementations would have
>> to be updated, e.g. Microsoft Schannel, OpenSSL, Mozilla NSS, JSSE,
>> GnuTLS, etc. Getting any change, no matter how "minimal", to them is
>> not easy.
>>
>
> I don't see the point here. Any TLS feature will require updating TLS
> implementations.

Right, which is why it's a good idea to avoid making changes unless
we have to.

-Ekr

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls