Re: [TLS] TLS 1.2 draft comments
EKR <ekr@networkresonance.com> Sun, 31 December 2006 16:02 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H139D-0000sf-Kr; Sun, 31 Dec 2006 11:02:55 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H139D-0000sa-6t for tls@ietf.org; Sun, 31 Dec 2006 11:02:55 -0500
Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H139B-0001eS-Rt for tls@ietf.org; Sun, 31 Dec 2006 11:02:55 -0500
Received: by delta.rtfm.com (Postfix, from userid 1001) id 67BEC1CC67; Sun, 31 Dec 2006 08:01:37 -0800 (PST)
To: home_pw@msn.com
Subject: Re: [TLS] TLS 1.2 draft comments
References: <BAY103-DAV17E2A403A0F53177A5D23792C50@phx.gbl> <868xgp594m.fsf@delta.rtfm.com> <BAY103-DAV18B3EF60CDF312016ABCF892C40@phx.gbl>
From: EKR <ekr@networkresonance.com>
Date: Sun, 31 Dec 2006 08:01:37 -0800
In-Reply-To: <BAY103-DAV18B3EF60CDF312016ABCF892C40@phx.gbl> (home pw's message of "Sun, 31 Dec 2006 06:12:04 -0800")
Message-ID: <86fyaw2gwu.fsf@delta.rtfm.com>
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.2 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: EKR <ekr@networkresonance.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
<home_pw@msn.com> writes: > 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]." Yes, I'll clean this up. > 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. I would advise you to read draft-mcgrew-auth-enc-01, which describes the rationale for this kind of primitive. > 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. Huh? Data origin authentication failures in TLS always occured at the record layer. We're just replacing two algorithms at the record layer with one. > (a) can the DOA properties of non-AEAD-based confidentiality services > also be tied > to the (authenticated) error signaling I don't know what this means. > (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? The behavior here is exactly like it always has been for TLS. You generate a protected MAC on the write channel and then abort. (Note that DTLS behaves differently since MAC errors are not fatal.) > 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. Yes. This creates a normative dependency on that 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. TLS staying at Proposed for 7 years had to do primarily with WG inertia. And the reason that 1.2 will not go to Draft is that we are making major technical changes. > 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. The reference is to an RFC. [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet Public Key Infrastructure: Part I: X.509 Certificate and CRL Profile", RFC 3280, April 2002. -Ekr _______________________________________________ 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