Re: [TLS] Comments on TLS identity protection

Martin Rex <martin.rex@sap.com> Thu, 28 December 2006 13:00 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzurd-0007nm-Me; Thu, 28 Dec 2006 08:00:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gzurb-0007nS-Ti for tls@ietf.org; Thu, 28 Dec 2006 08:00:03 -0500
Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzurX-0001RS-Dx for tls@ietf.org; Thu, 28 Dec 2006 08:00:03 -0500
Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id NAA07716; Thu, 28 Dec 2006 13:59:48 +0100 (MEZ)
From: Martin Rex <martin.rex@sap.com>
Message-Id: <200612281259.NAA28445@uw1048.wdf.sap.corp>
Subject: Re: [TLS] Comments on TLS identity protection
To: ekr@networkresonance.com
Date: Thu, 28 Dec 2006 13:59:48 +0100
In-Reply-To: <8664bw7r1t.fsf@delta.rtfm.com> from "EKR" at Dec 27, 6 05:22:22 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
X-SAP: out
X-SAP: out
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: martin.rex@sap.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

EKR wrote:
> 
> Yes, but TLS explicitly forbids you to negotiate this algorithm
> (i.e., it's only useful for performing the handshake).
> 
>    TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
>    TLS connection during the first handshake on that channel, but must
>    not be negotiated, as it provides no more protection than an
>    unsecured connection.
> 
> So, it's basically a different way of expressing "do your first
> handshake in the clear".

TLS_NULL_WITH_NULL_NULL does not provide per-message MAC.  
It is sort-of a hack for the SSL protocol engine to cover
the initial phase when there is not yet a shared secret.

It is OK to use for the messages of the SSL handshake -- which
do not need a per-message MAC as they're protected by the
full handshake MAC of the Finished messages.

-Martin

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