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.w...@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.i...@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.w...@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.as...@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-dra...@ietf.org [mailto:internet-dra...@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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
