Subject: Re: [TLS] AD comments on draft-ietf-tls-ecc-11

From: Russ Housley <[email-masked]>
Date: Tue, 01 Nov 2005 10:17:44 -0500

Bodo:

Two points:

1)  I understand your points, and I understood them before I made my 
comments.  It seems to me that we would be doing the community a big 
service is the same API could be used in both environments.  I think 
it is work a  bit of discussion before we assume that different APIs 
are the way to go.

2) I am concerned that the nonces that are exchanged in the 
ClinetHello and ServerHello might not big enough when the ECDH keys 
are not ephemeral.  The random values are a fixed length (28 bytes or 
224 bits), which is quite a bit smaller that the EC values (either 
256, 384, or 512 bits).  The inclusion of a UKM would resolve this 
concern by allowing the client to provide more random input.

Russ

At 11:46 PM 10/29/2005, Bodo Moeller wrote:
>On Sat, Oct 29, 2005 at 04:41:04PM -0400, Russ Housley wrote:
>
> >>> [ RFC 3278 specifies ECDH for use with S/MIME and CMS.  These two
> >>>   specifications are not compatible in some significant ways.  By this,
> >>>   I mean that a subroutine cannot be written that works with both this
> >>>   document and with RFC 3278.  To me, this would be highly desirable.
> >>>   One glaring difference is the support for UserKeyingMaterial (or UKM)
> >>>   that is provided by the originator (the client in this context).  The
> >>>   UKM and the ECDH shared secret are both inputs to the KDF. ]
>
> >> SBW> Both documents use the same ECDH primitive but different KDFs. This
> >> is a very common situation, isn't it? You can use a single subroutine for
> >> both if your subroutine only does the Z computation, or takes the KDF as a
> >> parameter.
>
> > I agree that the computation of Z is the same.  If you consider the KDF to
> > be a selectable parameter, the the inputs still do not line up.  Maybe I
> > am missing something.  Here is how I am interpreting your comment:
> >
> >    RFC 3278:
> >
> >       1) Use ECDH to compute the shared secret Z.
> >
> >       2) Compute KEK using a KDF with the following inputs:
> >          a) Z
> >          b) KEK algorithm identifier and key size
> >          c) UserKeyingMaterial
> >
> >    TLS-ECC Draft:
> >
> >       1) Use ECDH to compute the shared secret Z.
> >
> >       2) Compute KEK using the identity KDF one input: Z
> >
> > So, I continue to be confused about the API.  It does not look to me
> > like the same API can be used for ECDH_Key_Agreement() in these two
> > cases.
>
>TLS has no need for something like the UserKeyingMaterial in CMS since
>TLS always includes client and server nonces in the hash computation
>that obtains the master secret from the premaster secret.
>
>When using an API designed for the CMS case *with* these additional
>parameters (where the result is supposed to be a key-encryption key,
>KEK), you'd just not use them for the TLS case -- i.e. write NULL or
>an appropriate equivalent.  TLS does not need such parameters and has
>no input to provide for them.  So the TLS case of ECDH_Key_Agreement()
>presumably would fail if any UserKeyingMaterial *is* provided, since
>this would indicate a programming error.  The inputs don't line up,
>but they don't have to.
>
>Note that the ECDH computations in the TLS-ECC draft are modelled
>quite closely after the standard DH computations in TLS.  This
>delivers what TLS needs in a straightforward way and avoids
>unnecessary protocol complexity.  There is no reason to do ECDH
>fundamentally different from DH -- and there certainly is no reason to
>make the *differences* between ECDH in CMS and ECDH in TLS
>fundamentally different from those between DH in CMS and DH in TLS.

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 1 Nov 2005 08:52:41 -0700

> concern by allowing the client to provide more random input.

Would we require more from the nonces than that they be unique?
Even if so, 224 bits (plus a few from the 32-bit timestamp) is plenty.
In comparison, from the 384-bit curve, we can expect only 384/2 = 192
"bits of security" (which, if course, is actually a lot).

I certainly understand that sometimes it is preferred to be a little
more paranoid, just in case.  But, then, one clearly should use
ephemeral ECDH and avoid using fixed keys for anything other than
signatures!  In an interactive protocol like TLS, there's no need to
prefer fixed-key ECDH except when one is intentionally sacrificing
some security in the sake of performance.  And your concern applies
only to the case of fixed-key ECDH.

---

From: Russ Housley <[email-masked]>
Date: Mon, 07 Nov 2005 16:26:55 -0500

>only to the case of fixed-key ECDH.

While I am not satisfied with the size of the nonce with 512-bit 
ECDH, this document should probably not be the brunt of this 
criticism.  I will raise this issue as the working group moves 
forward with updates to the base TLS protocol specification to 
address hash function independence.

Russ