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 aler-> "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
