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

From: "Stefan Santesson" <[email-masked]>
Date: Sun, 6 Nov 2005 17:55:25 -0000

Russ,

I sense a misunderstanding.

You write:

 TLS-ECC Draft:
  1) Use ECDH to compute the shared secret Z.
  2) Compute KEK using the identity KDF one input: Z

This is not how I read the tls-ecc draft. I read it as:

 TLS-ECC Draft:
  1) Use ECDH to compute the ECDH shared secret
  2) Use identity KDF (IEEE 1363) to obtain the TLS premaster secret
from
     the ECDH shared secret.
  3) Compute TLS master secret and KEK using the TLS PRF as defined
     in RFC 2246

Observe the note in 5.10 in draft-ietf-tls-ecc-12:

  "(Note that this use of the identity KDF is a technicality.  The
   complete picture is that ECDH is employed with a non-trivial KDF
   because TLS does not directly use the premaster secret for anything
   other than for computing the master secret.  As of TLS 1.0 [2] and
   1.1 [3] this means that the MD5- and SHA-1-based TLS PRF serves as a
   KDF; it is conceivable that future TLS versions or new TLS extensions
   introduced in the future may vary this computation.)"

AND

  "...using the ECKAS-DH1 scheme with the identity map as key derivation
   function (KDF), so that the _premaster secret_ is the x-coordinate of
   the ECDH shared secret elliptic curve point represented as an octet
   string."

I think the draft is correct. The RFC 3278 KDF is out of scope here
unless we want to change RFC 2246 key derivation.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Russ Housley
> Sent: den 1 november 2005 07:18
> To: Bodo Moeller
> Cc: [email-masked]
> Subject: Re: [TLS] AD comments on draft-ietf-tls-ecc-11
> 
> 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

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

---

From: "Stefan Santesson" <[email-masked]>
Date: Sun, 6 Nov 2005 18:19:09 -0000

I was a little hot on the send button.

I meant step 3 to say:
   3) Compute TLS master secret and derive other keys and secrets
      using the TLS PRF as defined in RFC 2246

I'm not sure what secret or key you mean by "KEK" in your example.

Stefan Santesson

On
> Behalf Of Stefan Santesson
> Sent: den 6 november 2005 09:55
> To: Russ Housley; Bodo Moeller
> Cc: [email-masked]
> Subject: RE: [TLS] AD comments on draft-ietf-tls-ecc-11
> 
> Russ,
>