Re: [TLS] Comments on TLS identity protection

badra <badra@isima.fr> Wed, 20 December 2006 13:15 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx1I8-0000NS-9U; Wed, 20 Dec 2006 08:15:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx1I7-0000N6-0D for tls@ietf.org; Wed, 20 Dec 2006 08:15:27 -0500
Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx1I5-0005BG-KO for tls@ietf.org; Wed, 20 Dec 2006 08:15:26 -0500
Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with ESMTP id OAA55070 ; Wed, 20 Dec 2006 14:13:57 +0100
Message-ID: <4589375B.8070201@isima.fr>
Date: Wed, 20 Dec 2006 14:15:07 +0100
From: badra <badra@isima.fr>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Pasi.Eronen@nokia.com
Subject: Re: [TLS] Comments on TLS identity protection
References: <B356D8F434D20B40A8CEDAEC305A1F24038FD564@esebe105.NOE.Nokia.com>
In-Reply-To: <B356D8F434D20B40A8CEDAEC305A1F24038FD564@esebe105.NOE.Nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by sp.isima.fr id OAA55070
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

Hi Pasi,

Pasi.Eronen@nokia.com a écrit :
> And why would anyone care about this? (Note that your proposal doesn't
> help against intentional denial-of-service attacks either, only
> accidental misconfiguration.)
>
>   

does no one care about his server consuming amounts of CPU to do, among 
others, two sets of crypto-computations for nothing?
I didn't say the proposal helps againt MITM. I said double handshake 
raises security considerations regarding MITM, when the proposal does't 
raise new security considerations.

> What configuration? A TLS server that supports both privacy and no
> privacy doesn't need any configuration options to do so (it does
> need the code to do double handshake, but new code would be required
> for your proposal as well). A TLS client might concievably have 
> configuration option "require privacy", but this applies to your 
> proposal as well.
>   

Many mechanisms can be designed to add client privacy to TLS, but the 
question arises: which one is more efficient and preferment? Haven't 
many documents been originally approved for easy deployment and 
optimization reasons?

> Best regards,
> Pasi
>
>   

Best regards,
Badra


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