headers
Pasi.Eronen | 7 Jan 2008 08:25
Picon

ECDHE_PSK as WG item?

<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
Permalink | Reply |
headers
Pasi.Eronen | 4 Feb 2008 11:10
Picon

Re: ECDHE_PSK as WG item?

<wg chair hat on>

So far, we have four people (in addition to the author) who 
support adopting draft-badra-ecdhe-tls-psk as TLS WG item, 
and have committed to participating in the work.

While getting more people involved certainly wouldn't hurt, 
I'm judging this to be sufficient interest for a simple
document like this.

Mohamad, please submit draft-ietf-tls-ecdhe-psk-00 at your 
convenience (but before the IETF 71 draft cut-off date).

Best regards,
Pasi
Permalink | Reply |
headers
Eric Rescorla | 1 Feb 2008 16:43

Re: ECDHE_PSK as WG item?

At Mon, 7 Jan 2008 09:25:20 +0200,
<Pasi.Eronen <at> nokia.com> wrote:
> 
> <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.

I think it's generally useful to have a reasonably orthogonal
suite of cipher suites, so it would be good to have PSK usable
with ECDH. I'm willing to commit to reviewing this draft.

-Ekr
Permalink | Reply |
headers
Simon Josefsson | 10 Jan 2008 15:23
Favicon
Gravatar

Re: ECDHE_PSK as WG item?

<Pasi.Eronen <at> nokia.com> writes:

> 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.

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.
(Continue reading)

Permalink | Reply |
headers
Pasi.Eronen | 29 Jan 2008 13:51
Picon

Some comments about draft-badra-ecdhe-tls-psk-01

<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
(Continue reading)

Permalink | Reply |
headers
Mohamad Badra | 31 Jan 2008 15:54
Picon

Updated version of draft-badra-ecdhe-tls-psk

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
Permalink | Reply |
headers
Dan Harkins | 29 Jan 2008 19:52

Re: Some comments about draft-badra-ecdhe-tls-psk-01


  Hi Pasi,

On Tue, January 29, 2008 4:51 am, Pasi.Eronen <at> nokia.com wrote:
> <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...

  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.
Permalink | Reply |
headers
Pasi.Eronen | 30 Jan 2008 07:58
Picon

RE: password-based authentication (was: Some comments about draft-badra-ecdhe-tls-psk-01)

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
Permalink | Reply |
headers
Chris Newman | 31 Jan 2008 00:12
Picon

RE: password-based authentication (was: Some comments about draft-badra-ecdhe-tls-psk-01)

Pasi.Eronen <at> nokia.com wrote on 1/30/08 9:58 +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?

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
(Continue reading)

Permalink | Reply |
headers
Dan Harkins | 31 Jan 2008 03:52

RE: password-based authentication (was: Some comments about draft-badra-ecdhe-tls-psk-01)


  Hi Chris,

On Wed, January 30, 2008 3:12 pm, Chris Newman wrote:
> Pasi.Eronen <at> nokia.com wrote on 1/30/08 9:58 +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?
>
> 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,
(Continue reading)

Permalink | Reply |
headers
Chris Newman | 6 Feb 2008 22:37
Picon

Re: password-based authentication (was: Some comments about draft-badra-ecdhe-tls-psk-01)

--On January 30, 2008 18:52:01 -0800 Dan Harkins <dharkins <at> lounge.org> 
wrote:

>
>   Hi Chris,
>
> On Wed, January 30, 2008 3:12 pm, Chris Newman wrote:
>> Pasi.Eronen <at> nokia.com wrote on 1/30/08 9:58 +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?
>>
>> 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)
(Continue reading)

Permalink | Reply |
headers
Dan Harkins | 7 Feb 2008 00:19

Re: password-based authentication (was: Some comments about draft-badra-ecdhe-tls-psk-01)


  Hi Chris,

  It sounds like your TLS implementation is a horribly complex mess.
I'm very sorry about that but please realize that not everyone's is.
It's possible to implement password-based authentication without
"doubling the complexity" (as you claimed) but then maybe not with
all TLS implementations. Your mileage may vary, and apparently may
vary considerably.

  Nobody said anything about "application authentication" so that's
just a red herring.

  Also I don't know what's debatable about the benefits of server-side
authentication in TLS unless you want to enable phishing expeditions.
Most people don't.

  best regards,

  Dan.

On Wed, February 6, 2008 1:37 pm, Chris Newman wrote:
> --On January 30, 2008 18:52:01 -0800 Dan Harkins <dharkins <at> lounge.org>
> wrote:
>
>>
>>   Hi Chris,
>>
>> On Wed, January 30, 2008 3:12 pm, Chris Newman wrote:
>>> Pasi.Eronen <at> nokia.com wrote on 1/30/08 9:58 +0200:
(Continue reading)

Permalink | Reply |
headers
Dan Harkins | 30 Jan 2008 08:29

RE: password-based authentication (was: Some comments about draft-badra-ecdhe-tls-psk-01)


  Technically nothing.

  Dan.

On Tue, January 29, 2008 10:58 pm, Pasi.Eronen <at> nokia.com wrote:
> 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
>
Permalink | Reply |
headers
Blumenthal, Uri | 29 Jan 2008 17:01
Picon

Re: Some comments about draft-badra-ecdhe-tls-psk-01

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, "Pasi.Eronen <at> nokia.com" <Pasi.Eronen <at> nokia.com> wrote:

<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...

 
_______________________________________________
TLS mailing list
TLS <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls
Permalink | Reply |
headers
Mohamad Badra | 29 Jan 2008 16:43
Picon

Re: Some comments about draft-badra-ecdhe-tls-psk-01

Dear Pasi,

> 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...

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?

> 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.

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

> 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.

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

> 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.

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.

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

OK.

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

OK.

> 
> Best regards,
> Pasi 

Many thanks!
Best regards,
--

-- 
Mohamad Badra
CNRS - LIMOS Laboratory
Permalink | Reply |
headers
badra | 11 Jan 2008 20:50
Picon

Re:  Re: ECDHE_PSK as WG item?

Dear Simon,

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

>
> 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.
>

OK.

> * 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.
>

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

> * 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.

OK.

Best regards,
Badra
Permalink | Reply |
headers
Blumenthal, Uri | 7 Jan 2008 17:06
Picon

Re: ECDHE_PSK as WG item?

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, "Pasi.Eronen <at> nokia.com" <Pasi.Eronen <at> nokia.com> wrote:

<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
TLS <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls




 
_______________________________________________
TLS mailing list
TLS <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls
Permalink | Reply |

Gmane