Re: [TLS] FW: New Version Notification for draft-jay-tls-psk-identity-extension-02.txt
Jayaraghavendran Kuppannan <jayaraghavendran.ietf@gmail.com> Mon, 16 January 2017 15:04 UTC
Return-Path: <jayaraghavendran.ietf@gmail.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 037C1129560 for <tls@ietfa.amsl.com>; Mon, 16 Jan 2017 07:04:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 u8odCbohj3vK for <tls@ietfa.amsl.com>; Mon, 16 Jan 2017 07:04:09 -0800 (PST)
Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CDD712955A for <tls@ietf.org>; Mon, 16 Jan 2017 07:04:09 -0800 (PST)
Received: by mail-vk0-x22a.google.com with SMTP id k127so29032181vke.0 for <tls@ietf.org>; Mon, 16 Jan 2017 07:04:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8GbTV1M1NRjaeeUzPhXXBsgAncXn5LR8D7Yy67VlgTE=; b=gNPOKTsjWDOo/GRR7M9Hu70B+dtgOAsiH796EVPni6ZFUjjHQyEuRYatxhAn9dAFHJ sobp2XVH24gTPS9X0NUYgbYieNtbrVavDJzA/Qm+Ubyoo+Jr8UDuncKwT66og9SlMI4/ jMh69EdIaAJ5VXsPWS/boEdgvgu4IsiHwqNfq4UaGtsyHmhCZqwmTacWGs/YxI3J2lUI VtyG+BKGbzIsOs6PUUK0EtjKAdJd6JS95909v+YqhVDuQaUlXRvXovQczStHi42PSVmo D8EZzhof6xxc5dSFpmMME9ygVXdiHjy5ddnd65zmersZvAOnLnLrgE4yI30XhBas6rIB s13w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8GbTV1M1NRjaeeUzPhXXBsgAncXn5LR8D7Yy67VlgTE=; b=rkdaBLKWqfpJj+XyNI1YKZddLuY7HRQlA7t4J6iO0c7aUyOp+H76vRyqgUIKCJor7P xj3nlLG7fk1pZg2WGjz/A8frr+xidKaVgsaKMo657faLwrHis1JmSr2S6XicNsaXfI6B RMVrFsGga5/+YCYEvwQTAb4680svBJ7OYk9+563RDUFCJSZRGDU6MrAWCl0fjqkh2dcT IhbDvCRqtBF4OpZHqXqGe4Ckl6yDkG2YwZ5ki/YgD/QaKRu4WAH3hFdt3B7IV5W/iu/u 7BphAdTbeW2RqcFLDixIN0Ag0UdCipeHPp7L72hZgENr4+7nZQGBYxYyzXuTaSYwXIWX 481A==
X-Gm-Message-State: AIkVDXK8OPz7jwtUbBuw7RVPV8R2f5QrxIp4kRwLYrPWoIe24Hq4tWeTQANMG2EcxL+VCb/zHFy5QsMulL4NmQ==
X-Received: by 10.31.158.9 with SMTP id h9mr16094507vke.114.1484579048060; Mon, 16 Jan 2017 07:04:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.28.70 with HTTP; Mon, 16 Jan 2017 07:04:07 -0800 (PST)
In-Reply-To: <587CD706020000AC00125EDA@gwia2.rz.hs-offenburg.de>
References: <FDFEA8C9B9B6BD4685DCC959079C81F5E1918C90@BLREML509-MBX.china.huawei.com> <5877AE7B020000AC00125968@gwia2.rz.hs-offenburg.de> <CAOxcgchjznu_mKwERfY6vzV+mFNupvWV8ebJ5_zA-x1hE1pm1g@mail.gmail.com> <587CD706020000AC00125EDA@gwia2.rz.hs-offenburg.de>
From: Jayaraghavendran Kuppannan <jayaraghavendran.ietf@gmail.com>
Date: Mon, 16 Jan 2017 20:34:07 +0530
Message-ID: <CAOxcgchtd_9cDjBebiOKAk2QtWa0s0ny+Y1ieu7K1rXMMoMvnQ@mail.gmail.com>
To: Andreas Walz <andreas.walz@hs-offenburg.de>
Content-Type: multipart/alternative; boundary="001a11426c06cd03680546377e79"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/tUH6tEECDrqJU148Asn4tUWFxSM>
Cc: tls@ietf.org
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: Mon, 16 Jan 2017 15:04:13 -0000
Hi Andreas, Thanks for the help in reviewing the draft as well as in providing your usage scenario. Regards, Jay On Mon, Jan 16, 2017 at 6:51 PM, Andreas Walz <andreas.walz@hs-offenburg.de> wrote: > Hi Jay, > > our scenario is the following: we are considering a legacy industrial > communication system with a number of spatially distributed stations. > Inter-station communication is based on a simple proprietary protocol over > a very lean and lossy wireless channel. The channel features 2.4 kbits/s > and a bit error rate of up to 1E-4. Packets might take several hops until > they reach their destination. > > Despite the aforementioned constraints we would like to use DTLS for > wireless communication between stations. Therefore, we are investigating > the potential to minimize the communication overhead of DTLS, both during > the handshake and for application data datagrams. Every single byte we can > save is welcome. > > Currently, our scenario does not involve any internet-related > communication. I could image that because of this IETF's interest in our > use case is small. We would like to stay standard-compliant though and > support any plan or effort that helps scaling (D)TLS down without > sacrificing security. > > Thanks and Best Regards, > Andi Walz > > ___________________________________ > > Andreas Walz > Research Engineer > Institute of reliable Embedded Systems and Communication Electronics > (ivESK) > Offenburg University of Applied Sciences, 77652 Offenburg, Germany > > > > >>> Jayaraghavendran Kuppannan <jayaraghavendran.ietf@gmail.com> 01/13/17 > 10:27 AM >>> > Hi Andi, > > Thanks a lot for your comments. We will be fixing them. > > Right now, we don't have the Git Repository for this draft. Will set it up > shortly (within a day or two) and send you the link for the updates related > to the typos. > > Also, it would be great, if you could elaborate on your scenario, so that > we can add parts of it in our draft as a part of the use cases. > > > Regards, > Jay > > > > On Thu, Jan 12, 2017 at 8:57 PM, Andreas Walz < > andreas.walz@hs-offenburg.de> wrote: > >> 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 other members of this group also to look into and provide >> 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 >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> >
- [TLS] FW: New Version Notification for draft-jay-… Raja ashok
- Re: [TLS] FW: New Version Notification for draft-… Andreas Walz
- Re: [TLS] FW: New Version Notification for draft-… Jayaraghavendran Kuppannan
- Re: [TLS] FW: New Version Notification for draft-… Andreas Walz
- Re: [TLS] FW: New Version Notification for draft-… Jayaraghavendran Kuppannan
- Re: [TLS] New Version Notification for draft-jay-… Russ Housley