Re: [TLS] FW: New Version Notification for draft-jay-tls-psk-identity-extension-02.txt

"Andreas Walz" <andreas.walz@hs-offenburg.de> Thu, 12 January 2017 15:27 UTC

Return-Path: <andreas.walz@hs-offenburg.de>
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 3916E129887 for <tls@ietfa.amsl.com>; Thu, 12 Jan 2017 07:27:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.198
X-Spam-Level:
X-Spam-Status: No, score=-5.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-offenburg.de
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 2xvrH_3_uL84 for <tls@ietfa.amsl.com>; Thu, 12 Jan 2017 07:27:47 -0800 (PST)
Received: from mx.hs-offenburg.de (mx.hs-offenburg.de [141.79.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ECA9129886 for <tls@ietf.org>; Thu, 12 Jan 2017 07:27:44 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx.hs-offenburg.de (Postfix) with ESMTP id B7F851636A29 for <tls@ietf.org>; Thu, 12 Jan 2017 16:27:42 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-offenburg.de; h=content-type:content-type:mime-version:in-reply-to:references :subject:subject:from:from:date:date:x-mailer:message-id :received:received:received; s=default; t=1484234861; x= 1485098862; bh=xA+2lmL2Vwsp2sK+eS8n9mF7etixf774864m4KmdFUc=; b=A dyQ8Q+UrIn8Q9k1Dza85kUtPQgHKK1YoSa+yBmxVwRJ/Lfy0x/CHNN40T2vGYKLb +Qzf95E9hLCbUXpGp51tSO/SWZij6JkkvvU73esjmRv6dGvaJEXo12+FRaCYwKa8 PiNijlHGUau17Iy82zLqWS6g8dhZf6orcpbOXIF7fU=
X-Virus-Scanned: amavisd-new at hs-offenburg.de
Received: from mx.hs-offenburg.de ([127.0.0.1]) by localhost (mx.hs-offenburg.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNwq-jW_5q2S for <tls@ietf.org>; Thu, 12 Jan 2017 16:27:41 +0100 (CET)
Received: from gwia2.rz.hs-offenburg.de (gwia2.rz.hs-offenburg.de [141.79.10.30]) by mx.hs-offenburg.de (Postfix) with ESMTPS id ECECA1636A1A for <tls@ietf.org>; Thu, 12 Jan 2017 16:27:40 +0100 (CET)
Received: from gw_dom-gwia2-MTA by gwia2.rz.hs-offenburg.de with Novell_GroupWise; Thu, 12 Jan 2017 16:27:40 +0100
Message-Id: <5877AE7B020000AC00125968@gwia2.rz.hs-offenburg.de>
X-Mailer: Novell GroupWise Internet Agent 14.2.1
Date: Thu, 12 Jan 2017 16:27:39 +0100
From: Andreas Walz <andreas.walz@hs-offenburg.de>
To: raja.ashok@huawei.com, tls@ietf.org
References: <FDFEA8C9B9B6BD4685DCC959079C81F5E1918C90@BLREML509-MBX.china.huawei.com>
In-Reply-To: <FDFEA8C9B9B6BD4685DCC959079C81F5E1918C90@BLREML509-MBX.china.huawei.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=__Part9CA5BE7B.2__="
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dGtupq9aJVBoepnSFoFEZ6UmuHo>
Subject: Re: [TLS] FW: New Version Notification for draft-jay-tls-psk-identity-extension-02.txt
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: Thu, 12 Jan 2017 15:27:50 -0000

Dear all,

I read through the draft and I do have some questions/comments which you
can find below:

-> Section 1, 2nd paragraph: Maybe one could mention explicitly that the
new extension allows to do during the Hello phase what would otherwise
be done in separate messages in a separate round trip.
-> Section 3, 2nd paragraph, under a): it is written "...it checks
whether it supports PSK based authentication for its client.". What does
"its client" refer to? This is supposed to refer to the ordinary PSK
handshake where the server only knows the client's network address at
this point in time, isn’t it?
-> Section 5.2, 1st paragraph: "Clients supporting this extension should
include ...". Is there a reason you don't use "SHOULD"?
-> Section 5.2: There is no statement about the order of PSK identities
in the extension. Does it mean the order is of no relevance at all? Why
not allowing the client to express its preferences by means of ordering
the items in the list?
-> Section 5.3: The fact that abbreviating the handshake only works for
pure PSK cipher suites is only mentioned in the third paragraph. Maybe
this can be made more explicit somewhere at the beginning of this
section (e.g. changing the heading to "Abbreviated Handshake for pure
PSK Cipher Suites" or the like)?
-> Section 5.3, 4th paragraph: the last paragraph only states that for
DHE_PSK, RSA_PSK, ECDHE_PSK the server and client key exchange messages
are still required. It doesn't say anything about whether the presence
of the new extension changes the format of these messages. I would
expect that server and client key exchange messages omit the PSK_ID part
then…or do they keep that part? What is the content then? This should be
mentioned somehow, maybe as a separate section?
-> Section 5.3: What is a server (client) expected to do if it receives
a client (server) key exchange message during an abbreviated handshake
(with pure PSK cipher suites)? Maybe mention "During an abbreviated
handshake the server MUST NOT send a server key exchange message and the
client MUST NOT send a client key exchange message. Otherwise the
receiver MUST abort the handshake with an unexpected_message alert."

Some minor comments/typos:

-> "PSK" and "pre-shared key" is used alternately in the draft
-> Section 2, 2nd paragraph: "Incase" -> "In case"
-> Section 5.2, 2nd paragraph: "Please note that, Server MUST include
this extension ...". I would change this to "Servers MUST NOT send this
extension unless the client sent it in the client hello."
-> Section 5.3: A "(" is missing in the diagram below "ServerHello"
-> There are some more typos. Do you have a Git repository where I could
post a pull request for those? I guess that would be more efficient than
listing them here.

Thanks and Cheers,
Andi Walz

___________________________________

Andreas Walz
Research Engineer
Institute of reliable Embedded Systems and Communication Electronics
(ivESK)
Offenburg University of Applied Sciences, 77652 Offenburg, Germany






>>> Raja ashok <raja.ashok@huawei.com> 01/11/17 1:31 PM >>>
Hi All

A new extension is proposed for [D]TLS1.2 and its lower version(not for
[D]TLS1.3), to send PSKID in client hello msg instead of client key
exchange msg. Using this extension, client can send its list of PSKIDs
to server in its hello msg and server can select any one of them and
respond in its hello msg. 
    - With the help of this extn, PSK cipher handshake can be completed
in 1RTT. Messages exchanged are similar to resumption.
    - For DHE_PSK, RSA_PSK and ECDHE_PSK ciphers, PSKID in client hello
msg gives additional information to server for cipher negotiation. If
unknown PSKIDs are present, then server can select any NON PSK cipher or
fail at that place only (instead of failing in finished message
verification).

Already we received interest and review comments from Nikos
Mavrogiannopoulos, David Woodhouse and Andreas Walz. Based on that we
have submitted the 3rd version of this document. 
I am requesting otheprovide comments for further improvements.

Regards,
Raja Ashok V K
Huawei Technologies
Bangalore, India
http://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!

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
Sent: 17 December 2016 04:11
To: Raja ashok; Raja ashok; Jayaraghavendran Kuppannan
Subject: New Version Notification for
draft-jay-tls-psk-identity-extension-02.txt


A new version of I-D, draft-jay-tls-psk-identity-extension-02.txt
has been successfully submitted by Raja Ashok V K and posted to the IETF
repository.

Name:        draft-jay-tls-psk-identity-extension
Revision:    02
Title:        TLS/DTLS PSK Identity Extension
Document date:    2016-12-15
Group:        Individual Submission
Pages:        10
URL:           
https://www.ietf.org/internet-drafts/draft-jay-tls-psk-identity-extension-02.txt
Status:        
https://datatracker.ietf.org/doc/draft-jay-tls-psk-identity-extension/
Htmlized:      
https://tools.ietf.org/html/draft-jay-tls-psk-identity-extension-02
Diff:          
https://www.ietf.org/rfcdiff?url2=draft-jay-tls-psk-identity-extension-02

Abstract:
   Pre-Shared Key (PSK) based Key Exchange Mechanism is primarily used
   in constrained environments where resource intensive Asymmetric
   Cryptography cannot be used. In the Internet of Things (IoT)
   deployments, constrained devices are commonly used for collecting
   data via sensors for use in home automation, smart energy etc. In
   this context, DTLS is being considered as the primary protocol for
   communication security at the application layer and in some cases, it
   is also being considered for network access authentication.

   This document provides a specification for a new extension for
   Optimizing DTLS and TLS Handshake when the Pre-Shared Key (PSK) based
   Key Exchange is used. This extension is aimed at reducing the number
   of messages exchanged and the RTT of the TLS & DTLS Handshakes.

                                                                        
         
Hi, 

I am submitting my 3rd version of our
draft(draft-jay-tls-psk-identity-extension) in TLS working group. 

Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.

The IETF Secretariat

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