Re: [TLS] TLS 1.2 draft comments
<home_pw@msn.com> Sun, 31 December 2006 14:11 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H11Po-00058R-0W; Sun, 31 Dec 2006 09:11:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H11Pm-000574-Ii for tls@ietf.org; Sun, 31 Dec 2006 09:11:54 -0500
Received: from bay0-omc1-s14.bay0.hotmail.com ([65.54.246.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H11Pj-0003xZ-Gy for tls@ietf.org; Sun, 31 Dec 2006 09:11:54 -0500
Received: from hotmail.com ([65.54.174.90]) by bay0-omc1-s14.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Sun, 31 Dec 2006 06:11:50 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 31 Dec 2006 06:11:50 -0800
Message-ID: <BAY103-DAV18B3EF60CDF312016ABCF892C40@phx.gbl>
Received: from 69.227.152.254 by BAY103-DAV18.phx.gbl with DAV; Sun, 31 Dec 2006 14:11:49 +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
References: <BAY103-DAV17E2A403A0F53177A5D23792C50@phx.gbl> <868xgp594m.fsf@delta.rtfm.com>
Subject: Re: [TLS] TLS 1.2 draft comments
Date: Sun, 31 Dec 2006 06:12:04 -0800
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
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: 31 Dec 2006 14:11:50.0891 (UTC) FILETIME=[9DBD4BB0:01C72CE5]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48
Cc:
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
----- Original Message ----- From: "EKR" <ekr@networkresonance.com> To: <home_pw@msn.com> Cc: <tls@ietf.org> Sent: Saturday, December 30, 2006 2:09 PM Subject: Re: [TLS] TLS 1.2 draft comments > <speaking for mysef....> Well, there are only two listed authors of the TLS1.2 text... and I know how Tim thinks. Lets assume no ghost authors. But, you cannot stop being IAB, EKR. The role exists to render intuitive judgment to the engineering process. 1. NONCES, KDF, EVIDENCE in TLS1.2 we need to consider what the security section says about nonce generation. Folks are known to claim that being public, they do not need a known-safe PRNG process. Id claim (a) the random component (and time) are not always public (in renegotiation) (b) the random component is specified for use in TLS PRF(s) acting as a KDF SEF and an HMAC SEF. We have to be careful, as there is assurance "feedback". The nonces protect the handshake, by generating keying material for the encryption of the finished message, which provides the integrity protection for the handshake's activation of pending state that gates the very encryption mechanism logic unit. In TLS Evidence, this is a major auditable semantic event, furthermore, and Russ evidently intends the times and nonces to become part of the uncompressed-plaintext-handshake evidence that is stored, under US data retention laws. How long is the ClientHello random anyways? One book says it stored in 28 opaque bytes, on the wire, as does http://ietf.org/rfc/rfc2246.txt. However, Section 6.1 of the I-D list connection state as: client random A 32 byte value provided by the client. Is the master_secret KDF implmented on the message from in socket queue, or from the connection state? This is important as (computations on the ) master_secret may be limited to the kernel, in the privileged ring of the CPU. The hello messages may well be in user mode space by now. Concerning 7.4.1.1 " Note: This message MUST NOT be included in the message hashes which are maintained throughout the handshake and used in the finished messages and the certificate verify message" this will need to go in the connection state maintaining the hash for TLS Evidence digital signatures. 2. CIPHERSPEC, EXPORT If the 40-bit export ciphersuites are being deprecated, will the standard maintain the rest of the strengh-limitation (export reg.) apparatus that IESG endorsed? (the changecipherspec process leading to the final derivation of keying material in non MISSI ciphersuites?) We might leave it as is, bind the traditional function(s) associated with the current value of cipherspec (1), and introduce a second value (2) - to be associated with the expected practices hereonafter. A fatal alert might be introduced for a modern implementation to react to value=1. 3. RSA CIPHERSUITES WITH NEW KDFs, LOCAL RSA CIPHERSUITES Does IETF intend to now standardize any RSA ciphersuite that define their own KDFs? Or is IETF going to limit itself to only addressing ciphersuites that use the TLS PRF as a KDF? The following text may need updating, as KDFs per ciphersuite now may or may not be using (in the handshake layer) "HMAC, keyed MACs, or secure digesting of data that is protected by a secret" "A number of operations in the TLS record and handshake layer required a keyed MAC; this is a secure digest of some data protected by a secret. Forging the MAC is infeasible without knowledge of the MAC secret. The construction we use for this operation is known as HMAC, described in [HMAC]." "In TLS the entire output of the hash function is used as the MAC tag." Interesting to see such a "govt term" in the spec. This is not typical netscape-era use of language. but the following is done well: "Note that if new cipher suites are added that do not use HMAC, and the session negotiates one of these cipher suites, this extension will have no effect." The main problem is that we have locally-defined ciphersuites these days, FORMALLY. The style of language still often assumes ciphersuite are defined in the "standard document" (e.g. "added"). The standard has to adapt - the architecture now assumes the record layer may be being protected using non-IETF-endorsed ciphersuites. 4. AEAD I still don't understand the objective for introducing AEAD. It seems to exist to provide a explicit data origin authentication service tied a confidentiality service. Unlike the DOA that traditionally provided by assured writer-to-reader confidentiality service, the implied DOA is then tied to the error signaling in and of the record layer. At second reading, I still don't like AEAD as a construction, and I still don't like the tying of a confidentiality service state to any error signaling. My first impression was correct: a lot more rationale is required, both function claims and then assurance claims/arguments. (a) can the DOA properties of non-AEAD-based confidentiality services also be tied to the (authenticated) error signaling (b) once the AEAD internal error state is detected on the read subchannel, does the standard intend the encryption mechanism in the HSM to stay active, ... so it can now be used authenticate/encrypt/DOA the fatal alert on the write subchannel? c) is it non-conforming for an AEAD cipersuite to specify a NULL MAC component? We need an authoritative reference for AEAD, not just some I-D. All this draft document chasing is like Tom chasing Jerry chasing Tom, right now. I assume with AEAD added, TLS will now have to stay at Proposed for 7 more years... till we understand its impact. 5.PKIX 7.4.2 "All certificate profiles, key and cryptographic formats are defined by the IETF PKIX working group [PKIX]." This needs to go. TLS1.2 introduces non X.509 certificates, very clearly. And, one assumes PKIX WG has to die one day, too. We don't want references to working groups in standards. _______________________________________________ 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