[TLS] TLS 1.2 draft comments
<home_pw@msn.com> Sat, 30 December 2006 21:21 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0ldZ-0004Hl-Mr; Sat, 30 Dec 2006 16:21:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0ldX-0004Fe-Il for tls@ietf.org; Sat, 30 Dec 2006 16:21:03 -0500
Received: from bay0-omc2-s25.bay0.hotmail.com ([65.54.246.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0ldW-0000Hq-RI for tls@ietf.org; Sat, 30 Dec 2006 16:21:03 -0500
Received: from hotmail.com ([65.54.174.89]) by bay0-omc2-s25.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sat, 30 Dec 2006 13:21:02 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 30 Dec 2006 13:21:02 -0800
Message-ID: <BAY103-DAV17E2A403A0F53177A5D23792C50@phx.gbl>
Received: from 69.227.152.254 by BAY103-DAV17.phx.gbl with DAV; Sat, 30 Dec 2006 21:20:59 +0000
X-Originating-IP: [69.227.152.254]
X-Originating-Email: [home_pw@msn.com]
X-Sender: home_pw@msn.com
From: home_pw@msn.com
To: tls@ietf.org
Date: Sat, 30 Dec 2006 13:21:14 -0800
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Live Mail desktop 8.0.1223
X-MimeOLE: Produced By Microsoft MimeOLE V8.0.1223
X-OriginalArrivalTime: 30 Dec 2006 21:21:02.0115 (UTC) FILETIME=[68407F30:01C72C58]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae
Cc:
Subject: [TLS] TLS 1.2 draft comments
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="===============0955568471=="
Errors-To: tls-bounces@lists.ietf.org
Inline comments, for 7 fragments of the I-D:- 1. - The connection is private. Symmetric cryptography is used for data encryption (e.g., DES [DES], RC4 [SCH], etc.). The keys for this symmetric encryption are generated uniquely for each connection and are based on a secret negotiated by another protocol (such as the TLS Handshake Protocol). The Record Protocol can also be used without encryption. There are errors both technical and semantic in the above. Fortezza connections don't have unique keys per connection. We also need to stop including within 'key' objects such as "mac secrets." Furthermore, the secret may always not be "negotiated" by TLS. Furthermore, if the Record Protocol can be used without encryption, we can hardly have the privacy asserted in the topic sentence: without encryption, its hard to get the data origin authentication of the TLS application messages that allows for expressing the very expectation of pairwise privacy! 2. - The connection is reliable. Message transport includes a message integrity check using a keyed MAC. Secure hash functions (e.g., SHA, MD5, etc.) are used for MAC computations. The Record Protocol can operate without a MAC, but is generally only used in this mode while another protocol is using the Record Protocol as a transport for negotiating security parameters. Keep the point about RP can operate without a MAC, strike the general qualifier. Either one can or cannot...operate without MacTags. We readers don't need protocol design advice from TLS WG stuffed into an interoperability spec, thanks! 3. One such encapsulated protocol, the TLS Handshake Protocol, allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys While we are at it, lets get this accurate."One such encapsulated protocol, the TLS Handshake Protocol, allows the server and client to authenticate each other and to negotiate a __ciphersuite, key, and varios secrets.__" If I argue with myself, the word negotiate should really become "agree". In combination with the first use of the ciphersuite and keys, the final KDF executes an "agreement" between the named parties roles, as to those objects. One is forced to (I) use, (2) rely, and (3) agree, in the final protocol. 4. The peer's identity can be authenticated using asymmetric, or public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This authentication can be made optional, but is generally required for at least one of the peers. how about: The peer's identity can be authenticated using asymmetric, or public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This authentication can be made optional, but is generally required for at least one of the peers __in order to establish appropriate assurance for the key exchange component of a ciphersuite.__" 5. The negotiation of a shared secret is secure: the negotiated secret is unavailable to eavesdroppers, and for any authenticated connection the secret cannot be obtained, even by an attacker who can place himself in the middle of the connection. How about: The negotiation of a shared secret is secure: the negotiated secret is unavailable except to the server and client, each party can confirm the other possesses the secret, and for any authenticated connection the secret cannot be _obtained from the wire_ , even by an attacker who can place himself in the middle of the connection. 6. One advantage of TLS is that it is application protocol independent. Higher level protocols can layer on top of the TLS Protocol transparently. The TLS standard, however, does not specify how protocols add security with TLS; the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left up to the judgment of the designers and implementors of protocols which run on top of TLS. To address EAP-TLS session resumption rules and TLSPSK rules on self-signed certs etc: the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left up to the judgment of the designers and implementors of protocols which run on top of _or below_ TLS. 7. Concerning section 1.1: " - Allow the client to indicate which hash functions it supports. - Allow the server to indicate which hash functions it supports - Addition of support for authenticated encryption with additional data modes." distinguish indicating hash functions, from mac functions. hash functions used in securing the handshake are not the same as mac functions used in the record-layer. Without reading further, I don't know which are being referred to in this summary. I don't know what "authenticated encryption" is, only that support for it has been added. Apparently, it has "data modes". Its presumably not a confidentiality service. Its presumably not the privacy service. Its X. From the form of the summary, it may be an X.800 mechanism, not a service. Peter.
_______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- [TLS] TLS 1.2 draft comments home_pw
- Re: [TLS] TLS 1.2 draft comments EKR
- Re: [TLS] TLS 1.2 draft comments home_pw
- Re: [TLS] TLS 1.2 draft comments EKR
- Re: [TLS] TLS 1.2 draft comments home_pw
- Re: [TLS] TLS 1.2 draft comments Omirjan Batyrbaev
- Re: [TLS] TLS 1.2 draft comments EKR
- Re: [TLS] TLS 1.2 draft comments EKR
- Re: [TLS] TLS 1.2 draft comments Omirjan Batyrbaev
- Re: [TLS] TLS 1.2 draft comments EKR
- Re: [TLS] TLS 1.2 draft comments home_pw