Re: [TLS] TLS 1.3 and RFC 4279, Pre-Shared Key Ciphersuites

Jayaraghavendran k <jayaraghavendran.k@huawei.com> Fri, 27 November 2015 14:00 UTC

Return-Path: <jayaraghavendran.k@huawei.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420661A1AB1 for <tls@ietfa.amsl.com>; Fri, 27 Nov 2015 06:00:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.785
X-Spam-Level:
X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 226saCf2Hky1 for <tls@ietfa.amsl.com>; Fri, 27 Nov 2015 06:00:22 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA9F1A1AA3 for <tls@ietf.org>; Fri, 27 Nov 2015 06:00:21 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAW85230; Fri, 27 Nov 2015 14:00:18 +0000 (GMT)
Received: from SZXEMI413-HUB.china.huawei.com (10.86.210.41) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 27 Nov 2015 14:00:16 +0000
Received: from SZXEMI501-MBX.china.huawei.com ([169.254.1.253]) by SZXEMI413-HUB.china.huawei.com ([10.86.210.41]) with mapi id 14.03.0235.001; Fri, 27 Nov 2015 22:00:04 +0800
From: Jayaraghavendran k <jayaraghavendran.k@huawei.com>
To: Xuelei Fan <xuelei.fan@vimino.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] TLS 1.3 and RFC 4279, Pre-Shared Key Ciphersuites
Thread-Index: AQHRKQsBuPOPt0q8fE+pH+tBV6IRKZ6v4YMw
Date: Fri, 27 Nov 2015 14:00:04 +0000
Message-ID: <8D925D4C0B78EE41857D407022ECD163BFF02A60@SZXEMI501-MBX.china.huawei.com>
References: <CAAgBOhtGnaf12xBnmSph4p1Akrndu=SX37cdDCPjkKPub3RO8w@mail.gmail.com>
In-Reply-To: <CAAgBOhtGnaf12xBnmSph4p1Akrndu=SX37cdDCPjkKPub3RO8w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.213.218]
Content-Type: multipart/alternative; boundary="_000_8D925D4C0B78EE41857D407022ECD163BFF02A60SZXEMI501MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.565861F3.00FC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.253, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: eaf63c6599d72eb877407c3a5b6dc5a2
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/WRjyQ-YJT9Jr4Z4Ekq5HqquFpvo>
Subject: Re: [TLS] TLS 1.3 and RFC 4279, Pre-Shared Key Ciphersuites
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Nov 2015 14:00:25 -0000

Hi Xuelei,

As per RFC 4279 also, both the client and server are supposed to have a set of “Identity – key” pair  on either sides. The “ServerKeyExchange.psk_identity_hint” only helps the client in choosing an “identity-key” pair from a list of several “identity-key pairs” the client may have.

In TLS 1.3, instead of the ServerKeyExchange.psk_identity_hint, client sends its list of identities in the client hello itself through PreSharedKey Extension and server chooses one from it and replies in the PreSharedKey Extension.  Now, instead of traditional session resumption, this logic will be used  which basically has the same abbreviated handshake.

So, essentially, TLS 1.2 to TLS 1.3 transition for the above scenario should be viewed as below:

(a)    In case of PSK, instead of Client guessing and using an Identity based on PSK Identity Hint, both client and server negotiate which identity to use in the hello messages itself.

(b)   ServerKeyExchange.psk_identity_hint can be obsoleted removed when you transition from 1.2 to 1.3.

In my opinion, this makes the PSK based handshake a lot more simpler and easier to use.

Could you elaborate on your scenario based on which you say the transition from TLS 1.2 to TLS 1.3 for PSK will be difficult?

Regards,
Jay

***************************************************************************************
This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
***************************************************************************************

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Xuelei Fan
Sent: 27 November 2015 17:29
To: tls@ietf.org
Subject: [TLS] TLS 1.3 and RFC 4279, Pre-Shared Key Ciphersuites

Hi,

In the draft spec of TLS 1.3, ServerKeyExchange and ClientKeyExchange get removed, and key_share extension applies to non-PSK cipher suites only. As RFC 4279 need ServerKeyExchange and ClientKeyExchange messages, I think TLS 1.3 updates or obsoletes RFC 4279.

Per the draft spec of TLS 1.3, if no suitable identity is provided in pre-shared key extension, the server MUST NOT negotiate a PSK cipher suite.  The question comes to me: where the suitable identity comes from?  The identity can be acquired by out-of-band approach, or the server NewSessionTicket message.  If no out-of-band approach in some circumstances, the server NewSessionTicket message would be the only way to create the identity.  The scenarios of using  pre-shared key may look like:
1. establish a fresh connection, server sends the NewSessionTicket to indicate it supports session resumption and provide the psk_identity.
2. if client wants a session resumption, subsequent handshaking will use pre_shared key extension with the server provided psk_identity.

Looks like PSK applies to session resume only in TLS 1.3, and cannot be used for fresh (initial) handshaking any more,  unless out-of-band approach is used to define the identities.  I have no experience on PSK, but looks like that it is not A minimal effort for PSK deployments to upgrade from TLS 1.2 to TLS 1.3, if ServerKeyExchange.psk_identity_hint is used previously.

It would be nice to consider and specify the impact on RFC 4279 in TLS 1.3 protocols.

Regards,
Xuelei