Subject: [TLS] FW: New Version Notification for draft-jay-tls-psk-identity-extension-02.txt

From: Raja ashok <[email-masked]>
Date: Wed, 11 Jan 2017 12:30:14 +0000

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-masked] [mailto:[email-masked]] 
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

---

From: "Andreas Walz" <[email-masked]>
Date: Thu, 12 Jan 2017 16:27:39 +0100

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-masked]> 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-masked] [mailto:[email-masked]] 
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:

         
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-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Jayaraghavendran Kuppannan <[email-masked]>
Date: Fri, 13 Jan 2017 14:57:20 +0530

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-masked]>
wrote:

> 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: 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?
> 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)?
> 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."
>
> -> Section 5.2, 2nd paragraph: "Please note that, Server MUST include this
> extension ...". I would change this to "Servers MUST NOT send this
> 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).
>
> Mavrogiannopoulos, David Woodhouse and Andreas Walz. Based on that we have
> submitted the 3rd version of this document.

---

From: "Andreas Walz" <[email-masked]>
Date: Mon, 16 Jan 2017 14:21:58 +0100

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

>>> Jayaraghavendran Kuppannan <[email-masked]>
01/13/17 10:27 AM >>>
Hi Andi,

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-masked]> wrote:
Dear all,

receiver MUST abort the handshake with an unexpected_message aler-> "PSK" and "pre-shared key" is used alternately in the draft

Thanks and Cheers,
Andi Walz

Andreas Walz
Research Engineer

Hi All

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 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 17 December 2016 04:11
To: Raja ashok; Raja ashok; Jayaraghavendran Kuppannan
Subject: New Version Notification for

Abstract:

         
Hi, 

The IETF Secretariat

---

From: Jayaraghavendran Kuppannan <[email-masked]>
Date: Mon, 16 Jan 2017 20:34:07 +0530

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-masked]>
wrote:

> 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.
>
> 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.
>
> >>> Jayaraghavendran Kuppannan <[email-masked]> 01/13/17
> 10:27 AM >>>
> Hi Andi,
>
> On Thu, Jan 12, 2017 at 8:57 PM, Andreas Walz <
> [email-masked]> wrote:
>
>> Dear all,
>>
>> handshake where the server only knows the client's network address at this
>> point in time, isn’t it?
>> in the extension. Does it mean the order is of no relevance at all? Why not

---

From: Russ Housley <[email-masked]>
Date: Tue, 17 Jan 2017 16:46:31 -0500

I think there are two very different scenarios where an identity needs to be associated with an external PSK, that is a PSK that is not produced by a previous handshake.  This draft only addresses one of them, and I would rather see a way forward that considers both.

This draft considers the scenario where the PSK is used to avoid the use of (EC)DHE altogether.

The other scenario is where the PSK is combined with the (EC)DHE shared secret as protection against a quantum computer.  In this case the identity associated with the PSK must be compatible with the identity in the certificate.  We have not had any discussion about the meaning of compatible in this context.  I believe the TLS WG wants to wrap up the core TLS 1.3 specification before delving into that topic.

For that reason, I think that the topic of this draft must also wait until the core TLS 1.3 specification is in the hands of the IESG.

Russ

Abstract:

Hi, 

The IETF Secretariat