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 <[email protected]> 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 <[email protected]> 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 < > [email protected]> 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 <[email protected]> 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: [email protected] [mailto:[email protected]] >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/tls >> >> _______________________________________________ >> TLS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/tls >> >> >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
