RE: [TLS] Comments on TLS identity protection

Peter Williams <home_pw@msn.com> Wed, 27 December 2006 20:23 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzfIt-0000e6-4I; Wed, 27 Dec 2006 15:23:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GzfIr-0000dU-IK for tls@ietf.org; Wed, 27 Dec 2006 15:23:09 -0500
Received: from bay0-omc1-s36.bay0.hotmail.com ([65.54.246.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GzfIn-0003lS-56 for tls@ietf.org; Wed, 27 Dec 2006 15:23:09 -0500
Received: from BAY103-W1 ([65.54.174.101]) by bay0-omc1-s36.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 27 Dec 2006 12:23:04 -0800
X-Originating-IP: [24.6.106.3]
X-Originating-Email: [home_pw@msn.com]
Message-ID: <BAY103-W1BEB824CAF7E47E64148B92C00@phx.gbl>
From: Peter Williams <home_pw@msn.com>
To: EKR <ekr@networkresonance.com>
Subject: RE: [TLS] Comments on TLS identity protection
Date: Wed, 27 Dec 2006 12:23:04 -0800
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Dec 2006 20:23:04.0920 (UTC) FILETIME=[D0716580:01C729F4]
X-Spam-Score: 2.2 (++)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
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>
Content-Type: multipart/mixed; boundary="===============1613977122=="
Errors-To: tls-bounces@lists.ietf.org

 
> > There's no way in TLS to currently have a NULL MAC algorithm.> > I doubt there is lilkely to be one soon.
 
if we look at the text of SSLv3, it discussed null mac functions in the architecture:-
 
If the CipherSuite is SSL_NULL_WITH_NULL_NULL, encryption consists of the identity 
operation (i.e., the data is not encrypted and the MAC size is zero implying that 
no MAC is used). SSLCiphertext.length is SSLCompressed.length plus 
CipherSpec.hash_size. 
 
I'd claim that a complete, SSL-patent implementing state machine (E.g TLS ) therefore
supports null MAC algorithms. As TLS implies SSLv3 fallback capability...the capability needs
to be provided to be complete. I think we can allow for "no MAC is used" (spec) to be equivalent to 
"NULL MAC algorithm" (peter-speak), linguistically.
 
if we consider
 
"The encryption and MAC algorithms are set to SSL_NULL_WITH_NULL_NULL at the beginning of the SSL 
Handshake Protocol,  indicating that no message authentication or encryption is performed. The handshake 
protocol is used to negotiate a more secure CipherSpec and to generate cryptographic keys. "
 
So perhaps the truthful political-appropriate statement would be that https (vs TLS) supports NULL 
MAC (as https tends to include the SSLv3 fallback modes of TLS)
 
_________________________________________________________________
Fixing up the home? Live Search can help.
http://imagine-windowslive.com/search/kits/default.aspx?kit=improve&locale=en-US&source=wlmemailtaglinenov06
_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls