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.
On Thu, Jan 12, 2017 at 8:57 PM, Andreas Walz <andreas.w...@hs-offenburg.de>
> 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
> 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.
> Raja Ashok V K
> Huawei Technologies
> Bangalore, India
> 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
> 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-
> 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
> 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-
> Status: https://datatracker.ietf.org/doc/draft-jay-tls-psk-
> Htmlized: https://tools.ietf.org/html/draft-jay-tls-psk-identity-
> Diff: https://www.ietf.org/rfcdiff?url2=draft-jay-tls-psk-
> 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.
> I am submitting my 3rd version of our
> 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
> The IETF Secretariat
> TLS mailing list
> TLS mailing list
TLS mailing list