Re: [TLS] draft-jay-tls-psk-identity-extension-01

Raja ashok <raja.ashok@huawei.com> Wed, 21 September 2016 17:46 UTC

Return-Path: <raja.ashok@huawei.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8243D12BB90 for <tls@ietfa.amsl.com>; Wed, 21 Sep 2016 10:46:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.537
X-Spam-Level:
X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Fywydc5r9xjS for <tls@ietfa.amsl.com>; Wed, 21 Sep 2016 10:46:52 -0700 (PDT)
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 53FBC12BB8F for <tls@ietf.org>; Wed, 21 Sep 2016 10:46:51 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRQ73174; Wed, 21 Sep 2016 17:46:48 +0000 (GMT)
Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 21 Sep 2016 18:46:47 +0100
Received: from BLREML509-MBX.china.huawei.com ([169.254.7.156]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0235.001; Wed, 21 Sep 2016 23:16:35 +0530
From: Raja ashok <raja.ashok@huawei.com>
To: David Woodhouse <dwmw2@infradead.org>, Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Thread-Topic: draft-jay-tls-psk-identity-extension-01
Thread-Index: AQHSELia/WQtXDK+QECTlnp0r3XqMaCAEtmAgAQjBQA=
Date: Wed, 21 Sep 2016 17:46:34 +0000
Message-ID: <FDFEA8C9B9B6BD4685DCC959079C81F5E18F6DA9@BLREML509-MBX.china.huawei.com>
References: <1474098807.2070.10.camel@gmail.com> <1474270465.144982.206.camel@infradead.org>
In-Reply-To: <1474270465.144982.206.camel@infradead.org>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.213.121]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.57E2C788.029C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.156, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 63d49d5525e67b8e3b254b2be7bc34ad
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/U5OsPYXPLx0i9QKebnITnnLJ114>
Cc: "jayaraghavendran@gmail.com" <jayaraghavendran@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] draft-jay-tls-psk-identity-extension-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 21 Sep 2016 17:46:54 -0000

Hi David & Nikos,

My comments are inlined in below mail, please check it.

-----Original Message-----
From: David Woodhouse [mailto:dwmw2@infradead.org] 
Sent: 19 September 2016 13:04
To: Nikos Mavrogiannopoulos; Raja ashok; jayaraghavendran.k@huawei.com
Subject: Re: draft-jay-tls-psk-identity-extension-01

On Sat, 2016-09-17 at 09:53 +0200, Nikos Mavrogiannopoulos wrote:
> Hello,
>  We were with David implementing the draft-jay-tls-psk-identity-
> extension-01 on openconnect VPN, however we noticed that the latest
> version of TLS 1.3 modified the identity extension in an incompatible
> way. I am not sure if the new format can be used in place of the old
> one. For that we would like to ask what is your plan about it. Would
> you include the new format with some guidance on how to be used under
> tls 1.2, or would you stick to the existing format?

[ashok]  : PSK Identity extension specified in our extension differs from the extension specified in TLS1.3. In TLS1.3 PSK identity extension they are trying to exchange whether its DHE based PSK or not and also authentication mechanism (PSK or cert based authentication), all these things for key_share extension. So that TLS1.3 has PskKeyExchangeModes and PskAuthenticationModes. But I hope these are not required for lower versions (TLS1.2, 1.1 and 1.0). So the extension proposed in this draft is only for usage with TLS1.2, 1.1 and 1.0. And I feel, we can make this as a separate extension to avoid confusion with TLS1.3 extension. If we feel anything needs to be inherited from TLS1.3 extension, we can do it.

A couple of other comments on looking in detail at the draft...

RFC4279 §5.1 says that PSK identities MUST be a character string,
encoded in UTF-8.

But the TLSv1.3 draft doesn't say this anywhere, and in fact in §4.5.1
it seems to suggest that for session resumption, we use a ticket
constructed according to RFC5077 as the PSK identity. Which would
probably be binary.

If TLSv1.3 is going to allow non-UTF8 PSK identities and TLSv1.2 still
doesn't, then it would be useful to clarify precisely what is allowed
in draft-jay-tls-psk-identity-extension.

[ashok] : PSK identity extension specified in this draft also expects the PSK ID as character string in UTF format, similar to RFC 4279. I will update this point in our draft, thanks for reminding me.

Another difference I note between your draft and the current TLSv1.3
draft is that in TLSv1.3, the PreSharedKeyExtension data returned by
the server is just an index in the identities offered by the client;
not a copy of the identifier itself:

   struct {
       select (Handshake.msg_type) {
           case client_hello:
               PskIdentity identities<6..2^16-1>;

           case server_hello:
               uint16 selected_identity;
       }
   } PreSharedKeyExtension;


...
   selected_identity     The server’s chosen identity expressed as a
                         (0-based) index into the identities in the
                         client’s list.

[ashok] : I feel sending the selected ID is better, otherwise while process "server hello" msg, client has to maintain the PSK ID list in the same order in which it sent. Already there was a discussion in TLS1.3 group for sending selected ID instead of index. 

And a final nitpick... replace every instance it "it's" with "its" :)

[ashok] : I will check and fix it. I will upload a revised draft. Thanks for your comments.


-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation




Raja Ashok
HUAWEI TECHNOLOGIES CO.,LTD. 

E-mail: raja.ashok@huawei.com
www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
This e-mail and its 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!