[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