[TLS] Review of draft-dugal-tls-ecmqv-00
Eric Rescorla <ekr@networkresonance.com> Tue, 07 March 2006 01:29 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGR1O-0004er-Tq; Mon, 06 Mar 2006 20:29:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGR1N-0004aM-Eb for tls@ietf.org; Mon, 06 Mar 2006 20:29:53 -0500
Received: from [198.144.201.116] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGR1L-0002UH-Tu for tls@ietf.org; Mon, 06 Mar 2006 20:29:53 -0500
Received: from networkresonance.com (delta.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id D981BB811 for <tls@ietf.org>; Mon, 6 Mar 2006 17:29:50 -0800 (PST)
To: tls@ietf.org
X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 18)
Date: Mon, 06 Mar 2006 17:29:50 -0800
From: Eric Rescorla <ekr@networkresonance.com>
Message-Id: <20060307012950.D981BB811@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc:
Subject: [TLS] Review of draft-dugal-tls-ecmqv-00
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
1. It would be nice somewhere around sections 1-2 to have an overview of the inputs to ECMQV. In particular, the requirement for the client to have two key pairs--one of which is always ephemeral--is sufficiently different from classic DH that it makes sense to review here. As usual, it would be nice to have some kind of ladder diagram that summarizes the exchanges at an abstract level. S 3. As a practical matter, how likely is it that client and server will share a group? S 4.1. What about DSA-signed certificates? S 4.2. As I understand this scheme, the ECMQV-capable ECDSA key in the certificate is used to sign the server's ephemeral ECMQV key. Unless I'm missing something, there's no security reason why the server's static key needs to be an EC key at all. It could just as well be an RSA key. True, the server needs to communicate the group that the ephemeral key is generated in but that could be sent in the ServerKeyExchange, as in TLS/ECC. Have I missed something? You write: The client retrieves the server's ephemeral ECMQV public key from the ServerKeyExchange message. Probably worth mentioning that it needs to verify the SKE. S 4.6. Nit: "demonstrate it's control". Should be "its" Same error in 4.7. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- [TLS] Review of draft-dugal-tls-ecmqv-00 Eric Rescorla
- Re: [TLS] Review of draft-dugal-tls-ecmqv-00 Vipul Gupta
- Re: [TLS] Review of draft-dugal-tls-ecmqv-00 Brian Minard