Subject: [TLS] ECDHE_PSK as WG item?

From: <[email-masked]>
Date: Mon, 7 Jan 2008 09:25:20 +0200

<wg chair hat on>

Mohammad Badra has requested that the TLS WG adopt
draft-badra-ecdhe-tls-psk as a WG item. This draft was presented 
in Vancouver, but few comments have been received so far.

Please use this thread to comment; not only the technical
details, but whether you think this is useful; should it be
done as WG item or individual document; and whether you're
willing to work on this document.

Best regards,
Pasi

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

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Mon, 7 Jan 2008 11:06:37 -0500

I strongly believe that ECDHE-PSK is useful and should be done as a WG item. Technical comments will follow.

Tnx!
--
Regards,
Uri

On 1/7/08 2:25 AM, "[email-masked]" <[email-masked]> wrote:

<wg chair hat on>

Best regards,
Pasi

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 10 Jan 2008 15:23:14 +0100

> willing to work on this document.

While GnuTLS does not support ECDHE yet, which means we are not likely
to implement the document immediately, I believe the document solve a
clearly described problem and that it should be adopted by the WG.  I'm
willing to review the document.

Some minor issues from a quick review:

* In the abstract RFC 4785 (PSK-NULL) and RFC 4279 (PSK) are mentioned
  in that order, twice.  I think it would be useful to mention them in
  the reverse order.

* Section 2 contains:

   "The PSK identity and identity hint fields have the same 
   meaning as in the previous section (note that the ServerKeyExchange 
   message is always sent, even if no PSK identity hint is provided)."

  What does 'the previous section' refer to?  I can't find any
  discussions of PSK identity earlier in the document.

* The document could say explicitly that the PSK case in
  ClientKeyExchange and ServerKeyExchange should not apply to PSK-ECDHE,
  instead the ec_diffie_hellman_psk case should apply.  I propose:

    When the CipherSuites defined in this document are used, the
    'ec_diffie_hellman_psk' case inside the ServerKeyExchange and
    ClientKeyExchange structure is used, instead of the 'psk' case
    defined in RFC 4279.

Thanks,
/Simon

---

From: [email-masked]
Date: Fri, 11 Jan 2008 20:50:15 +0100 (CET)

Dear Simon,

Thank you for your comments on the document. Short comments in line...

>   in that order, twice.  I think it would be useful to mention them in

OK.

>   discussions of PSK identity earlier in the document.

That's true. I will replace 'as in the previous section' with 'as in
RFC4279' (section 6).

>     ClientKeyExchange structure is used, instead of the 'psk' case

OK.

Best regards,
Badra

---

From: <[email-masked]>
Date: Tue, 29 Jan 2008 14:51:27 +0200

<not wearing any hats>

Overall comment: While the technical solution is reasonably defined 
and scoped, do we have any evidence that someone cares about it?
I.e., do we have information suggesting that if this was specified,
it would actually be used in real world? If we don't, let's not 
spend WG time on it...

Some additional comments based on a quick read:

Abstract, "This document updates RFC 4785 and 4279..."; it 
doesn't "update" either of them (in the sense the word "update" 
is usually used when talking about relationships between RFCs);
it just defines additional cipher suites.

Section 2, "First, perform the Elliptic Curve Diffie-Hellman
computation in the same way as for other Diffie-Hellman-based
ciphersuites in [TLS1.0] or [TLS1.1]" Neither document contains
information on how to perform ECDH computations.

Section 2, "Let Z be the value produced by this computation",
Elliptic Curve Diffie-Hellman is somewhat different in this
respect; text should be consistent with RFC 4492 Section 5.10.

Typos/grammar:
"These ciphersuites provides.."
"It specifies as well one.."

>From idnits: Unused Reference: 'RFC2119' is defined on line 160, 
but no explicit reference was found in the text

Best regards,
Pasi

---

From: Mohamad Badra <[email-masked]>
Date: Tue, 29 Jan 2008 16:43:48 +0100

Dear Pasi,

> it would actually be used in real world? If we don't, let's not 

A few of volunteers already reviewed the document. As you said early, 
the technical solution is reasonably defined and scoped and therefore I 
don't think that we need enough time to spend on it. The evidence that 
someone cares about it depends on the TLS-PSK itself: why someone care 
on RSA_PSK and DH_PSK but not on ECDHE_PSK? However, I do support any 
opinion poll on that through asking that someone: Do you support 
adopting that document?

> it just defines additional cipher suites.

OK, I will replace "update" with "extend".

> information on how to perform ECDH computations.

This is a mistake, I will replace "[TLS1.0] or [TLS1.1]" with "RFC4492".

> respect; text should be consistent with RFC 4492 Section 5.10.

What about replacing:

    The premaster secret is formed as follows. First, perform the
    Elliptic Curve Diffie-Hellman computation in the same way as for
    other Diffie-Hellman-based ciphersuites in [TLS1.0] or [TLS1.1]. Let
    Z be the value produced by this computation. Concatenate a uint16
    containing the length of Z (in octets), Z itself, a uint16
    containing the length of the PSK (in octets), and the PSK itself.

With:

    The premaster secret is formed as follows. First, perform the
    Elliptic Curve Diffie-Hellman computation in the same way as for
    other Diffie-Hellman-based ciphersuites defined in RFC4492 to
    generate the octet string [RFC4492]. Next, concatenate a uint16
    containing the length of the octet string (in octets), the octet
    strinf itself, a uint16 containing the length of the PSK (in octets),
    and the PSK itself.

OK.

OK.

> Pasi 

Many thanks!
Best regards,
-- 
Mohamad Badra
CNRS - LIMOS Laboratory

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 29 Jan 2008 11:01:23 -0500

I believe this document is relevant to WG - we slowly but surely move towards ECC (as part of Suite B).
--
Regards,
Uri

On 1/29/08 7:51 AM, "[email-masked]" <[email-masked]> wrote:

<not wearing any hats>

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 29 Jan 2008 10:52:27 -0800 (PST)

Hi Pasi,

> it would actually be used in real world? If we don't, let's not

  Personally I would view a password-based authentication scheme that
assumes the shared key is a low-entropy one or is selected from a limited
set of keys, like a dictionary, as more useful to the real world. I
believe that is the predominant access method used in the Internet today.

  IEEE P1363.2 has a draft out describing password-based authentication
protocols using elliptic curves.

  While a password-based authentication scheme would be _more_ useful
I still think there's value in pursuing a PSK-based scheme using elliptic
curves. It's an efficient alternative to the existing PSK cipher suites
that use groups based on exponentiation modulus a large prime.

  Dan.

---

From: <[email-masked]>
Date: Wed, 30 Jan 2008 08:58:50 +0200

Dan Harkins wrote:

> Personally I would view a password-based authentication scheme 
> that assumes the shared key is a low-entropy one or is selected 
> from a limited set of keys, like a dictionary, as more useful to 
> the real world. I believe that is the predominant access method 
> used in the Internet today.

Just being curious, what would be the main differences between
the authentication scheme you're thinking about, and RFC 5054?

Best regards,
Pasi

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 29 Jan 2008 23:29:50 -0800 (PST)

Technically nothing.

  Dan.

---

From: Chris Newman <[email-masked]>
Date: Wed, 30 Jan 2008 15:12:42 -0800

> the authentication scheme you're thinking about, and RFC 5054?

On the protocol side, not much.

On the implementation side, it would roughly double the complexity of a typical 
TLS API in order to actually be useful to applications.  The password verifier 
could be stored in any one of a number of external repositories (LDAP, RADIUS, 
DIAMETER, SQL, Liberty, some other SOAP/HTTP mechanism, /etc/passwd, NIS, etc) 
and the application would have to provide the TLS stack with sophisticated 
configuration knobs related to these protocols.  As a matter of efficiency, 
some of these protocols are not cheap so high performance servers will have to 
keep a pool of connections, then fetch and cache the information locally. 
Attributes that are peripherally related to authentication or unrelated to 
authentication may also be accessed via these protocols and need to be cached 
as well to avoid the need for double-fetching of the same entry.  So the API 
needs a way to put all sorts of controls on the protocols used to fetch this 
data, timeouts, what attributes are of interest, caching parameters, etc.  Then 
there's need for back-channels to the cache (flushing specific entries on 
provisioning changes) which means hooking up to a notification mechanism to the 
caching logic under the TLS stack.

Personally, I think TLS stacks are plenty complex enough without all this 
machinery.  As a matter of architecture, I'd rather keep this machinery 
completely separate from the TLS stack and use TLS channel bindings when mutual 
authentication at the application layer is needed.

Although I'm dubious of the utility of PSK, it seems mostly harmless to the TLS 
stack as long as it's not a password.  The primary utility I see for PSK would 
be for server->server connections if it's coupled with an SSH-style 
zero-configuration key setup mechanism (I don't see it as having much 
real-world utility without the latter piece).  If PSK proves to be useful than 
ECC-PSK is also likely to be useful simply because of the improved key 
scalability.

                - Chris

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 30 Jan 2008 18:52:01 -0800 (PST)

Hi Chris,

> caching logic under the TLS stack.

Why would you put all that cruft into the TLS stack? That's what protocol
layers are for, abstracting out this complexity.

What do you do for supporting certificates? For RFC2885 support do you have
HTTP and FTP support to obtain certificates and CRLs from repositories built
into the TLS stack? Is the entire OCSP protocol part of your TLS stack?
What about CMS? Et cetera.

> authentication at the application layer is needed.

Channel bindings are orthogonal to a password-based authentication
protocol.

> ECC-PSK is also likely to be useful simply because of the improved key

  Dubious utility? Wow. They are arguably the predominant method used for
network access in the Internet today, and for the past umpteen years.

  One lesson I learned very hard from IKE was that if your protocol does
not handle username/password authentication then people are going to hack
the hell out of it to put it in, to the detriment of protocol security.
Why do you think the "do not validate server certificate" checkbox exists?
Let me give you an actual quote I heard: "to make SSL work".

  Dan.

---

From: Mohamad Badra <[email-masked]>
Date: Thu, 31 Jan 2008 15:54:50 +0100

Dear Pasi & Eric,

According to the comments of Uri, Pasi and Simon, I posted a new version 
of "ECDHE_PSK Ciphersuites for TLS" to the IETF repository.

I hope the document is ready to be adopted as WG item, especially 
because some WG members paid attention to what can be the "value-added" 
and that they are willing to work on this document.

Best regards,
-- 
Mohamad Badra
CNRS - LIMOS Laboratory