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 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: [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
