Re: [TLS] I-D ACTION:draft-ietf-tls-psk-null-00.txt

Bodo Moeller <bmoeller@acm.org> Fri, 21 July 2006 09:39 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3rTz-0004dO-Pc; Fri, 21 Jul 2006 05:39:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3rTy-0004dJ-S7 for tls@ietf.org; Fri, 21 Jul 2006 05:39:42 -0400
Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3rTx-0001Ha-Ei for tls@ietf.org; Fri, 21 Jul 2006 05:39:42 -0400
Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1G3rTv3rPL-00048b; Fri, 21 Jul 2006 11:39:40 +0200
Received: by tau.invalid (Postfix, from userid 1000) id E004517D41; Fri, 21 Jul 2006 11:39:38 +0200 (CEST)
Date: Fri, 21 Jul 2006 11:39:38 +0200
From: Bodo Moeller <bmoeller@acm.org>
To: tls@ietf.org
Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-psk-null-00.txt
Message-ID: <20060721093938.GA21125@iota.site>
References: <E1G3hLF-00055R-Fd@stiedprstage1.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <E1G3hLF-00055R-Fd@stiedprstage1.ietf.org>
User-Agent: Mutt/1.5.9i
X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc:
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

On Thu, Jul 20, 2006 at 06:50:01PM -0400, Internet-Drafts@ietf.org wrote:

> 	Title		: Pre-Shared Key Cipher Suite with NULL Encryption for Transport Layer Security 
> 	Author(s)	: U. Blumenthal, P. Goel
> 	Filename	: draft-ietf-tls-psk-null-00.txt
> 	Pages		: 5
> 	Date		: 2006-7-20
> 	
>    This document specifies authentication-only cipher suites for the 
>    Pre-Shared Key based [TLS-PSK] Transport Layer Security (TLS) [TLS] 
>    protocol to support null encryption. These cipher suites are useful 
>    for countries and places with cryptography-related restrictions.  

> http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-null-00.txt

The new I-D contains three ciphersuites:

    TLS_PSK_WITH_NULL_SHA
    TLS_DHE_PSK_WITH_NULL_SHA
    TLS_RSA_PSK_WITH_NULL_SHA

Is there a good case for definining a DHE_PSK ciphersuite with NULL
encryption?  RSA_PSK involves server certificates, so it does not
solely rely on pre-shared keys for authentication.  DHE_PSK, however,
uses ephemeral Diffie-Hellman without certificate-based
authentication.  This is very useful when the key exchange is used to
obtain keys for symmetric encryption.  However, in these NULL
encryption ciphersuites, the key exchange is only used to derive
authentication keys, so there is only a very limited need for forward
security.  (DHE_DSK, when using NULL encryption, provides protection
against exposure of a pre-shared key if use of said key has been
stopped, but TLS session based on the key remain active.)

If we are going to allocate additional ciphersuite numbers for new PSK
ciphersuites, other key exchange mechanisms for use with symmetric
encryption would appear more useful to me than DHE_PSK for NULL
encryption: RFC 4247 does not have any DHE_RSA_PSK and EDH_DSS_PSK
methods, which would combine ephemeral Diffie-Hellman with RSA or DSA
certificates -- thus providing both forward security and
certificate-based server authentication.  I don't know if this variant
is really needed (probably so rarely that combining multiple different
key exchange methods via renegotiation is a more reasonable technique
than specifying another set of specific ciphersuites), but it
certainly looks more useful to me than TLS_DHE_PSK_WITH_NULL_SHA!

So currently I think we should cut down the I-D to only two
ciphersuites, TLS_PSK_WITH_NULL_SHA and TLS_RSA_PSK_WITH_NULL_SHA.



_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls