Subject: [TLS] Review of draft-dugal-tls-ecmqv-00

From: Eric Rescorla <[email-masked]>
Date: Mon, 06 Mar 2006 17:29:50 -0800

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Vipul Gupta <[email-masked]>
Date: Wed, 08 Mar 2006 17:48:55 -0800

I'm confused by this part of Section 4.6 which reads

" ... demonstrate it's control over the private half of the  
*certified* ECMQV
    public key"

because Section 4.5 appears to allow a case where the client has no
certified ECMQV key

  "If the client has sent a certificate with an MQV key, ecmqv_ephemeral
    will contain the client's ephemeral public key for the MQV  
operation;
    ***otherwise ecmqv_ephemeral will contain an ephemeral public key  
that
    is used as the ephemeral public key for the MQV operation and ecmqv
    will contain a second ECMQV public key which takes the place of the
    certified key***"

What am I missing?

vipul

---

From: Brian Minard <[email-masked]>
Date: Fri, 10 Mar 2006 09:45:06 -0500

Section 4.6 only applies when the client has a suitable
certificate. In 4.5, the situation when the client cannot produce
a suitable certificate is similar to ECHDE except 2 emphemeral
keys are provided.

Does this improve 4.5:

   Actions of the sender:

      ecqmv_ephemeral MUST contain an ephemeral ECMQV public key.

      If the client has not sent a certificate with an
      ECMQV-capable key, then ecmqv MUST contain a second
      ephemeral ECMQV public key.

On Wed, Mar 08, 2006 at 05:48:55PM -0800, Vipul Gupta wrote:

> *certified* ECMQV public key"
>
> because Section 4.5 appears to allow a case where the client
> has no certified ECMQV key
>
>  "If the client has sent a certificate with an MQV key,
> ecmqv_ephemeral will contain the client's ephemeral public
> key for the MQV operation; ***otherwise ecmqv_ephemeral will
> contain an ephemeral public key that is used as the ephemeral
> public key for the MQV operation and ecmqv will contain a
> second ECMQV public key which takes the place of the certified
> key***"
>
> What am I missing?