Subject: Re: [TLS] ECDHE_PSK as WG item?

From: Eric Rescorla <[email-masked]>
Date: Fri, 01 Feb 2008 07:43:52 -0800

At Mon, 7 Jan 2008 09:25:20 +0200,
<[email-masked]> 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

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

---

From: <[email-masked]>
Date: Mon, 4 Feb 2008 12:10:04 +0200

<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

---

From: Chris Newman <[email-masked]>
Date: Wed, 06 Feb 2008 13:37:39 -0800

--On January 30, 2008 18:52:01 -0800 Dan Harkins <[email-masked]> 
wrote:

>
>   Hi Chris,
>
> On Wed, January 30, 2008 3:12 pm, Chris Newman wrote:
>> [email-masked] 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
>> 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.

Agreed.  This doesn't belong in the TLS stack so it shouldn't be in the TLS 
protocol.

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

The server I work on only supports client certificates signed by a locally 
stored CA cert (and locally stored CRLs) for TLS authentication and it's 
difficult to keep it working because the extra layering through the TLS 
stack makes it more fragile than other authentication code.  There's OCSP 
support in the TLS stack, but the server doesn't enable it -- it'd probably 
be problematic since the application would have limited control over the 
OCSP connections and that won't be viable in a highly scalable server.

>> 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.
>
> Channel bindings are orthogonal to a password-based authentication
> protocol.

Not for one that does mutual authentication.

>> 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.
>
>   Dubious utility? Wow. They are arguably the predominant method used for
> network access in the Internet today, and for the past umpteen years.

I've never seen TLS PSK used so I question your assertion.

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

That's why I'd prefer to keep TLS out of the game of application 
authentication.  The TLS stack is too critical as a mechanism to provide an 
encrypted tunnel (it's debatable if the server authentication in TLS is 
useful for the reason you cite).

IKE got into the game of application authentication because VPNs are the 
primary deployed use for IPsec/IKE and the VPN application has all the 
standard application authentication requirements.

		- Chris

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 6 Feb 2008 15:19:58 -0800 (PST)

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.