Re: [TLS] I-D Action: draft-ietf-tls-ctls-00.txt
Some suggestion from my side for cTLS 1. Currently supported ciphersuites in cTLS are only 5. In that case I feel changing 2 byte "CipherSuite" also to "varint" will help to reduce few more bytes on wire. Similarly for "NamedGroup" and "SignatureScheme". 2. In section 5.1, last sentence in the explanation of "version" should contain "SeverHello.extensions" version (integer): indicates that both sides agree to the single TLS version specified by the given integer value (772 == 0x0304 for TLS 1.3). The supported_versions extension is omitted from ClientHello.extensions and reconstructed in the transcript as a single-valued list with the specified value. The supported_versions extension is omitted from ClientHello.extensions and reconstructed in the transcript with the specified value. Thanks & Regards Raja Ashok On Mon, Apr 27, 2020 at 2:41 AM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > > Title : Compact TLS 1.3 > Authors : Eric Rescorla > Richard Barnes > Hannes Tschofenig > Filename: draft-ietf-tls-ctls-00.txt > Pages : 17 > Date: 2020-04-26 > > Abstract: >This document specifies a "compact" version of TLS 1.3. It is >isomorphic to TLS 1.3 but saves space by trimming obsolete material, >tighter encoding, and a template-based specialization technique. cTLS >is not directly interoperable with TLS 1.3, but it should eventually >be possible for a cTLS/TLS 1.3 server to exist and successfully >interoperate. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-ctls/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-ctls-00 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-ctls-00 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > ___ > 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] New Version Notification for draft-rashok-tls-ticket-request-msg-01.txt
Hi All, Updated draft with performance improvement on Client's App data processing when TLSv1.3 server ignores session ticket msg after handshake. Requesting all to provide your opinion on this draft. +--+-+-+ | Num of Ticket | Average time taken by | Average time taken by | | send by Serv |SSL_read |SSL_read | | after handshake | (AES_GCM_256) |(Chacha20Poly1305) | +--+-+-+ |0 | 62 usecs| 56 usecs | |1 |102 usecs| 86 usecs | |2 |132 usecs| 128 usecs | |4 |195 usecs| 185 usecs | |6 |250 usecs| 241 usecs | +--+ +--+-+-+ | Num of Ticket |Average number of|Average number of| | send by Serv | connections per second | connections per second | | after handshake | (AES_GCM_256) |(Chacha20Poly1305) | +--+-+-+ |0 | 1260 | 1356 | |1 | 1134 | 1229 | |2 | 1092 | 1141 | |4 | 1001 | 1060 | |6 |929 | 1002 | +--+ A new version of I-D, draft-rashok-tls-ticket-request-msg-01.txt has been successfully submitted by Raja Ashok and posted to the IETF repository. Name: draft-rashok-tls-ticket-request-msg Revision: 01 Title: TLS Ticket Request Message Document date: 2020-04-14 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-rashok-tls-ticket-request-msg-01.txt Status: https://datatracker.ietf.org/doc/draft-rashok-tls-ticket-request-msg/ Htmlized: https://tools.ietf.org/html/draft-rashok-tls-ticket-request-msg-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-rashok-tls-ticket-request-msg Diff: https://www.ietf.org/rfcdiff?url2=draft-rashok-tls-ticket-request-msg-01 Abstract: TLS session ticket provides a stateless mechanism for server to resume connection with client. As per TLS 1.3 [RFC8446], server always sends arbitary number of session ticket after handshake. This document introduces a new message which is TicketRequest message, it can be send by client after handshake at any point of connection lifetime to retrieve new session ticket. The proposed mechanism in this document is only for TLS 1.3 and DTLS 1.3 and future versions. 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] Fwd: Fwd: New Version Notification for draft-rashok-tls-ticket-request-msg-00.txt
Hi All, https://tools.ietf.org/html/draft-rashok-tls-ticket-request-msg-00 I am keen on improving this specification, so requesting all to provide feedback on this. Thanks & Regards, Raja Ashok This seems to be solving a very similar problem to > draft-ietf-tls-ticketrequests (which I see you reference in your draft). I > see two cases where this mechanism might be useful compared to the > ticket_request extension, but I'm skeptical those are useful use cases. > > The first case is if partway through a connection a client decides it > wants more tickets from the server. With the ticket_request extension, a > client can only specify at the beginning of a connection how many tickets > it wants, whereas with this TicketRequest message the client can ask for > more later. I can't think of a use case where a client would need more > tickets from this specific connection; > Consider a Video Streaming Application, which holds a TLS (HTTPS) connection to URI of lower resolution video (and audio). Based on dynamic improvement on bandwidth it might switch to higher resolution video content, which inturn might have different URIs for video and audio. At this point TLS client needs to open another TLS connection. So if TicketRequest msg support is there, at this scenario it can get ticket on the fly. Getting more amount of session ticket after handshake delays application data processing as well as some ticket might not be used. Like this lot of scenarios are there for a TLS client to choose how many tickets are needed on the fly. Basically TicketRequest msg gives 2 benefits to application - Avoid wastage of ticket - Improves application data processing by postponing session ticket msg issuance. > if a client does need more tickets it can get them from a new connection. > Consider a TLSv1.3 client opens a fresh Connection, and retrieves one ticket immediately after handshake. Now it opens 2nd connection (resumed) with ticket_request extension count as zero, by assuming not needed. But later if it needs to open one more connection based on dynamic need, then there is no way to get ticket without TicketRequest msg. > > The other case is one you mentioned in the draft: delaying sending tickets > to prioritize sending application data. There's no requirement that a > server send NewSessionTicket messages immediately after the handshake. A > server could prioritize sending application data over sending tickets and > delay sending tickets for some period of time. > As per my understanding RFC8446 says a TLSv1.3 server should send session ticket immediately after handshake. Even if it can delay, it will be very difficult to identify how long it should delay sending session ticket by prioritizing application data. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-rashok-tls-ticket-request-msg-00.txt
This seems to be solving a very similar problem to > draft-ietf-tls-ticketrequests (which I see you reference in your draft). I > see two cases where this mechanism might be useful compared to the > ticket_request extension, but I'm skeptical those are useful use cases. > > The first case is if partway through a connection a client decides it > wants more tickets from the server. With the ticket_request extension, a > client can only specify at the beginning of a connection how many tickets > it wants, whereas with this TicketRequest message the client can ask for > more later. I can't think of a use case where a client would need more > tickets from this specific connection; > Consider a Video Streaming Application, which holds a TLS (HTTPS) connection to URI of lower resolution video (and audio). Based on dynamic improvement on bandwidth it might switch to higher resolution video content, which inturn might have different URIs for video and audio. At this point TLS client needs to open another TLS connection. So if TicketRequest msg support is there, at this scenario it can get ticket on the fly. Getting more amount of session ticket after handshake delays application data processing as well as some ticket might not be used. Like this there a lot of scenarios are there for a TLS client to choose how many tickets are needed on the fly. Basically TicketRequest msg gives 2 benefits to application - Avoid wastage of ticket - Improves application data processing by postponing session ticket msg issuance. > if a client does need more tickets it can get them from a new connection. > Consider a TLSv1.3 client opens a fresh Connection, and retrieves one ticket immediately after handshake. Now it opens 2nd connection (resumed) with ticket_request extension count as zero, by assuming not needed. But later if it needs to open one more connection based on dynamic need, then there is no way to get ticket without TicketRequest msg. > > The other case is one you mentioned in the draft: delaying sending tickets > to prioritize sending application data. There's no requirement that a > server send NewSessionTicket messages immediately after the handshake. A > server could prioritize sending application data over sending tickets and > delay sending tickets for some period of time. > As per my understanding RFC8446 says a TLSv1.3 server should send session ticket immediately after handshake. Even if it can delay, it will be very difficult to identify how long it should delay sending session ticket by prioritizing application data. Thanks & Regards, Raja Ashok ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Fwd: New Version Notification for draft-rashok-tls-ticket-request-msg-00.txt
Hi All, Requesting to go through this draft and provide your views on it. Thanks & Regards, Raja Ashok -- Forwarded message - From: Date: Fri 20 Dec, 2019, 7:03 AM Subject: New Version Notification for draft-rashok-tls-ticket-request-msg-00.txt To: Raja Ashok A new version of I-D, draft-rashok-tls-ticket-request-msg-00.txt has been successfully submitted by Raja Ashok and posted to the IETF repository. Name: draft-rashok-tls-ticket-request-msg Revision: 00 Title: TLS Ticket Request Message Document date: 2019-12-20 Group: Individual Submission Pages: 4 URL: https://www.ietf.org/internet-drafts/draft-rashok-tls-ticket-request-msg-00.txt Status: https://datatracker.ietf.org/doc/draft-rashok-tls-ticket-request-msg/ Htmlized: https://tools.ietf.org/html/draft-rashok-tls-ticket-request-msg-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-rashok-tls-ticket-request-msg Abstract: TLS session ticket provides a stateless mechanism for server to resume connection with client. As per TLS 1.3 [RFC8446], server always sends arbitary number of session ticket after handshake. This document introduces a new message which is TicketRequest message, it can be send by client after handshake at any point of connection lifetime to retrieve session ticket. The proposed mechanism in this document is only for TLS 1.3 and DTLS 1.3 and future versions. 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
Re: [TLS] Doubts in draft-ietf-tls-rfc4492bis
Hi David, Thanks for your response. If it is already fixed in TLS1.3, then I also feel ok to leave this behavior for older version (TLS1.2 and earlier). Recently I started reading TLS1.3 specification, I will go through fully to get more info. Regards, Ashok [Company_logo] 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! From: David Benjamin [mailto:david...@chromium.org] Sent: 24 July 2017 21:57 To: Ilari Liusvaara; Raja ashok Cc: Subject: Re: [TLS] Doubts in draft-ietf-tls-rfc4492bis I believe what Raja is pointing out is that a server which accepts an ECDSA *client* certificate has no way to advertise to the client which curves it accepts. The signature algorithm list (and before TLS 1.2, the certificate types) do advertise ECDSA as a whole, but not curves. E.g., a client with both a P-256 and P-384 certificate may send P-384 when the server only accepted P-256. This issue existed in RFC 4492 as well. Though I wouldn't say the implication is all curves must be implemented. Rather I think you just reject those curves you don't accept and manage your client certificate deployment so that all servers accept a curve before starting to use those certificates. That's not great, so TLS 1.3 fixes this by moving ECDSA curves into signature algorithms. It's too late to change supported_groups to allow a TLS 1.2 ServerHello acknowledgement since clients will unexpected server extensions[*], so I would suggest we just leave this in the awkward state for TLS 1.2 and say it is fixed in TLS 1.3. David [*] Although, glancing through ours, it seems we do accept and ignore a ServerHello supported_groups in TLS 1.2. We apparently came across a server implementation which sent it, contrary to the spec. On Mon, Jul 24, 2017 at 10:58 AM Ilari Liusvaara mailto:ilariliusva...@welho.com>> wrote: On Mon, Jul 24, 2017 at 01:48:13PM +, Raja ashok wrote: > Hi Nir, Josefsson & Pegourie, > > As per section 5.2 server should send only "Supported Point Format" > extensions in server hello message. And it doesn't require to send > "Supported Elliptic Curve" extensions. Because of this if server is > supporting only few Curves and if it receives unsupported Elliptic > curve in client certificate message, then server might not be able > to continue the handshake. In TLS 1.2, the client sends the list of curves (and other groups and DHFs) it supports. The server picks one if it can. Thus if there is at least one common curve that both client and server support, then the group selection will succeed (if there is none, then no matter what one does things won't work). The actual curve server selected is transmitted in ServerKeyExchange message. In TLS 1.3, things get bit more complicated, since client can signal it supports a group without sending a share for it (if server selects such group, it needs to tell the client to retry using HelloRetryRequest message). The server group selection is in KeyShare extension in ServerHello message. -Ilari ___ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Doubts in draft-ietf-tls-rfc4492bis
Hi Nir, Josefsson & Pegourie, As per section 5.2 server should send only "Supported Point Format" extensions in server hello message. And it doesn't require to send "Supported Elliptic Curve" extensions. Because of this if server is supporting only few Curves and if it receives unsupported Elliptic curve in client certificate message, then server might not be able to continue the handshake. This makes (D)TLS server should mandatory implement all the curves mentioned in "NamedCurve". But I feel mandating (D)TLS server to support all NamedCurve is not feasible, as in future if new named curves are defined then updating legacy server is not easy. And also constraint (D)TLS server generally doesn't support all the curves. Please provide your suggestion on this. If my understanding is wrong, please correct me. Regards, Ashok ____ [Company_logo] 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! ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Suggestions in draft-mavrogiannopoulos-tls-cid
Hi Nikos, Hannes & Thomas, This ConnectionID concept is really a useful feature for a client node which faces a change in transport and network layer. I am having few suggestions in the proposed draft, which are listed below. 1) In section 3 of this draft, explains about the modification in "DTLSCiphertext" structure. I feel instead of modifying existing DTLS and TLS record header, we can directly introduce a new record type (ContentType) for app data (application_data_with_cid(25)). For this new record type, we can propose a modified record header for both TLS and DTLS. 2) More over section 3 says modification only in "DTLSCiphertext", not for "TLSCiphertext". I hope this CID mechanism should be used for both TLS and DTLS. Because this transport layer change problem is there for TLS based applications (HTTPS) also in Smartphone(when it switches from Wifi to LTE). But this TLS application problem is solved by MPTCP, but I dont think all webservers are supporting this MPTCP. So I feel CID is required for both TLS and DTLS. 3) As part of defining new record type, we can remove some unused fields like version, epoch. After removing epoch we can mandate that both entity should not start renegotiation. Sample design for new record header with CID is mentioned below struct { uint8_t ContentType; uint8_t CID_len; CID cid;/* Length varies from 4 to 8 (or 16) */ uint48 sequence_number; uint16_t record_length; } DTLSRecordHeader; opaque CID <4..8>; struct { uint8_t ContentType; uint8_t CID_len; CID cid;/* Length varies from 4 to 8 (or 16) */ uint16_t record_length; } TLSRecordHeader; opaque CID <4..8>; 4) Another option is we can keep CID_len as 4 bit to represent a CID of size. And this 4 bit can be placed in the MSB of the CID field. uint8_t CID_len:4; CID cid;/* Length varies from 28bit to 60 bit (or 124bit) */ 5) Section 3.1 and 3.2 talks about the new extensions for negotiating this feature support. But I feel no need of new extensions to negotiate this, we can make client to add new SCSV cipher in its cipher list. If server accepts then after handshake the first application data send by server should be of type application_data_with_cid(25), which should hold the new record header with CID. The same CID should be used by client in the further messasge. If client sends the 1st application data after handshake, then it can send application data with default record type (application_data(23)). If the first application data record received from server is not of application_data_with_cid(25) means client should understand that server has not accepted the SCSV proposed. And client should continue app transfer with default record type (application_data(23)). Please provide your comments on this suggestion. Regards, Ashok ________ [Company_logo] 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! ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] adopted: draft-ghedini-tls-certificate-compression
Hi Victor & Alessandro, I have gone through the draft and I am having a doubt. > The extension only affects the Certificate message from the server. > It does not change the format of the Certificate message sent by the > client. This draft provides a mechanism to compress only the server certificate message, not the client certificate message. I feel client authentication is not performed in HTTPS of web application. But in all other applications (eg. Wireless sensor network) certificate based client authentication is more important. So I suggest we should consider compression on client certificate message also. Regards, Ashok 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: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Sean Turner Sent: 06 June 2017 12:50 To: Subject: [TLS] adopted: I appears that we’ve got enough consensus/interest to adopt draft-ghedini-tls-certificate-compression-00 based on the WG session in Chicago and this thread: https://mailarchive.ietf.org/arch/msg/tls/U5AmA9OerD_9zTBNWl7ZBC3-HOE Authors, Please submit draft-ietf-tls-certificate-compression at your earliest convenience. All, I’ve established a GH repo at: https://github.com/tlswg/certificate-compression Victor and Alessandro are Admins so they’ll be copying over their repo. Thanks! J&S ___ 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
Re: [TLS] Stopping retransmission DTLS 1.2
Hi Simon, In case of partial read, after retransmit timeout if a DTLS receiver doesn’t retransmits then peer will retransmit its flight again only if it is not the final flight. Consider a receiver is DTLS client, and peer (server) is sending its final flight (CCS and FM). If any one of the message is not received, then client has to retransmit its previous flight (CKE, CCS and FM) otherwise server wont retransmit its message. Regards, Ashok [Company_logo] 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: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Simon Bernard Sent: 31 May 2017 22:06 To: tls@ietf.org Subject: [TLS] Stopping retransmission DTLS 1.2 Hi, The RFC6347, 4.2.4 [1] say : "3. The implementation receives the next flight of messages: if this is the final flight of messages, the implementation transitions to FINISHED. If the implementation needs to send a new flight, it transitions to the PREPARING state. Partial reads (whether partial messages or only some of the messages in the flight) do not cause state transitions or timer resets." I would like to know why "partial reads do not cause state timer resets". I mean if we receive the first "handshake message" of the expected "flight". we can assume that the foreign peer received our previous flight and so we can stop retransmissions of this flight. If the next message is lost, we will never respond and so the foreign peer should retransmit the whole flight. We don't need to retransmit on our side, so timer should be reset ? Did I missed something ? Thx. Simon [1]https://tools.ietf.org/html/rfc6347#section-4.2.4 ___ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] FW: New Version Notification for draft-jay-tls-psk-identity-extension-02.txt
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
Re: [TLS] draft-jay-tls-psk-identity-extension-01
Hi David & Nikos, 3rd version of the draft-jay-tls-psk-identity-extension has been submitted. Your valuable comments are also fixed. Please go through once and provide me your suggestion. @Andreas : Requesting you also to go through and provide your suggestion. 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: Raja ashok Sent: 21 September 2016 23:17 To: 'David Woodhouse'; Nikos Mavrogiannopoulos Cc: 'jayaraghavend...@gmail.com'; tls@ietf.org Subject: RE: draft-jay-tls-psk-identity-extension-01 Hi David & Nikos, My comments are inlined in below mail, please check it. -Original Message- From: David Woodhouse [mailto:dw...@infradead.org] Sent: 19 September 2016 13:04 To: Nikos Mavrogiannopoulos; Raja ashok; jayaraghavendra...@huawei.com Subject: Re: draft-jay-tls-psk-identity-extension-01 On Sat, 2016-09-17 at 09:53 +0200, Nikos Mavrogiannopoulos wrote: > Hello, > We were with David implementing the draft-jay-tls-psk-identity- > extension-01 on openconnect VPN, however we noticed that the latest > version of TLS 1.3 modified the identity extension in an incompatible > way. I am not sure if the new format can be used in place of the old > one. For that we would like to ask what is your plan about it. Would > you include the new format with some guidance on how to be used under > tls 1.2, or would you stick to the existing format? [ashok] : PSK Identity extension specified in our extension differs from the extension specified in TLS1.3. In TLS1.3 PSK identity extension they are trying to exchange whether its DHE based PSK or not and also authentication mechanism (PSK or cert based authentication), all these things for key_share extension. So that TLS1.3 has PskKeyExchangeModes and PskAuthenticationModes. But I hope these are not required for lower versions (TLS1.2, 1.1 and 1.0). So the extension proposed in this draft is only for usage with TLS1.2, 1.1 and 1.0. And I feel, we can make this as a separate extension to avoid confusion with TLS1.3 extension. If we feel anything needs to be inherited from TLS1.3 extension, we can do it. A couple of other comments on looking in detail at the draft... RFC4279 §5.1 says that PSK identities MUST be a character string, encoded in UTF-8. But the TLSv1.3 draft doesn't say this anywhere, and in fact in §4.5.1 it seems to suggest that for session resumption, we use a ticket constructed according to RFC5077 as the PSK identity. Which would probably be binary. If TLSv1.3 is going to allow non-UTF8 PSK identities and TLSv1.2 still doesn't, then it would be useful to clarify precisely what is allowed in draft-jay-tls-psk-identity-extension. [ashok] : PSK identity extension specified in this draft also expects the PSK ID as character string in UTF format, similar to RFC 4279. I will update this point in our draft, thanks for reminding me. Another difference I note between your draft and the current TLSv1.3 draft is that in TLSv1.3, the PreSharedKeyExtension data returned by the server is just an index in the identities offered by the client; not a copy of the identifier itself: struct { select (Handshake.msg_type) { case client_hello: PskIdentity identities<6..2^16-1>; case server_hello: uint16 selected_identity; } } PreSharedKeyExtension; ... selected_identity The server’s chosen identity expressed as a (0-based) index into the identities in the client’s list. [ashok] : I feel sending the selected ID is better, otherwise while process "server hello" msg, client has to maintain the PSK ID list in the same order in which it sent. Already there was a discussion in TLS1.3 group for sending selected ID instead of index. And a final nitpick... replace every instance it "it's" with "its" :) [ashok] : I will check and fix it. I will upload a revised draft. Thanks for your comments. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel
Re: [TLS] Maximum Fragment Length negotiation
Hi Thomas Your idea of defining a new similar extension is the only choice for us. Because as per existing max_fragment_length extension in RFC 6066, client should fail if it receives different value from server. And also your idea of making the new extension as mandatory for TLS1.3 is good, as it will be more useful for constraint server. Earlier in our team also we were discussing about defining new extension specially for constraint client and server. I suggest we should include the below points for new fragment length extension 1) As per RFC 6066, if 512 is negotiated then both entity should keep buffer of size 805 bytes (5 byte - record header, 512 bytes - data, 256 bytes - padding, 32 bytes - MAC). I think we should change this in our new fragment extension. If 512 is negotiated then both entity should not send any [D]TLS record of size more than that (includes record header and payload). Because the control overhead of 256 bytes padding and 32 bytes MAC are not applicable for recent AEAD algorithms. That too in AES_CCM there is no need of padding. 2) Currently least value supported by max_fragment_length is 512. I prefer we should add support for 256 and 128 also. If AES_CCM_8 is used, the control overhead on application record is 21 bytes (5 byte - record header, 8 byte - IV and 8 byte - MIC). If its DTLS record, overhead is 29 bytes. So if max fragment length is 128, we get 99 bytes for data. This is more than sufficient for a constraint protocol like CoAP. Note : Existing max_fragment_length extension cannot be extended to support new values like 128 and 256. 3) If a client sends both old and new extension, then priority should be given to new extension. Server MUST not send both the extension. I feel the current IoT world needs this kind of new extension. This is the time to do. Regards, Ashok Raja Ashok VK 华为技术有限公司 Huawei Technologies Co., Ltd. [Company_logo] Phone: Fax: Mobile: Email: 地址:深圳市龙岗区坂田华为基地 邮编:518129 Huawei Technologies Co., Ltd. Bantian, Longgang District,Shenzhen 518129, P.R.China 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: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Thomas Pornin Sent: 30 November 2016 00:25 To: Fossati, Thomas (Nokia - GB) Cc: tls@ietf.org Subject: Re: [TLS] Maximum Fragment Length negotiation On Thu, Nov 24, 2016 at 09:10:00PM +, Fossati, Thomas (Nokia - GB) wrote: > I like your proposal, but I'm not convinced that overloading the > semantics of an already existing extension when used in combination > with a specific version of the protocol is necessarily the best > strategy. Besides, I'd like to be able to deploy a similar mechanism > in 1.2. Defining a new extension is certainly possible. However, it would then require deciding on the intended behaviour when both that new extension and the RFC 6066 extension are present. Tentatively, one could try this: - The new extension documents the maximum record length supported by whoever sends it. Encoding is as in RFC 6066: one byte of value x for a maximum record plaintext length of 2^(x+8) bytes). We extend that to the whole 1..8 range so that larger records may be used by implementations who can afford them and obtain some performance increase by doing so (actual maximum plaintext length will be slightly less than 65535 bytes becose the length header is 16-bit and there must be some room for the MAC). - If a client sends both the RFC 6066 extension and the new extension, and the server supports the new extension, then the RFC 6066 extension is ignored and only the new extension is used. A server MUST NOT send both extensions. - All implementations that support the extension MUST have the ability to apply a shorter size limit than their maximum limit (this is for _sending_ records). - The length sent by the server is the one that will be applied to subsequent records on the connection, in both directions. This applies to the whole connection, including subsequent handshakes (renegotiations), unless both client and server send the new extension again in a renegotiation (in which case the new length appplies). - If using TLS 1.3,
Re: [TLS] Confirming consensus: TLS1.3->TLS*
I feel we can go ahead with TLS 1.3. Or else TLS 3.4, because anyway we send 0x0304 on wire for TLS 1.3. I hope all other three options (TLS 2.0, TLS 2 and TLS 4) will make confusion with SSL versions for end user. Raja Ashok VK 华为技术有限公司 Huawei Technologies Co., Ltd. [Company_logo] Phone: Fax: Mobile: Email: Huawei Technologies Co., Ltd. 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: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Sean Turner Sent: 18 November 2016 07:43 To: Subject: [TLS] Confirming consensus: TLS1.3->TLS* At IETF 97, the chairs lead a discussion to resolve whether the WG should rebrand TLS1.3 to something else. Slides can be found @ https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf. The consensus in the room was to leave it as is, i.e., TLS1.3, and to not rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision on the list so please let the list know your top choice between: - Leave it TLS 1.3 - Rebrand TLS 2.0 - Rebrand TLS 2 - Rebrand TLS 4 by 2 December 2016. Thanks, J&S ___ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Prospects of draft-jay-tls-psk-identity-extension
Hi Andreas, Last week received some comments from Ilari and David. We are working on the next version of this draft. We will upload it soon. Regards, Ashok Raja Ashok VK 华为技术有限公司 Huawei Technologies Co., Ltd. [Company_logo] Phone: Fax: Mobile: Email: Huawei Technologies Co., Ltd. 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! From: Andreas Walz [mailto:andreas.w...@hs-offenburg.de] Sent: 05 October 2016 17:45 To: jayaraghavendra...@huawei.com; Raja ashok Subject: Prospects of draft-jay-tls-psk-identity-extension Dear authors of draft-jay-tls-psk-identity-extension, I was wondering whether there is any plan to revive your draft on the TLS-PSK-identity-extension. I very much liked the idea and we also have a use case where it might be very helpful. Thanks for your answer. With 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-jay-tls-psk-identity-extension-01
Hi David & Nikos, My comments are inlined in below mail, please check it. -Original Message- From: David Woodhouse [mailto:dw...@infradead.org] Sent: 19 September 2016 13:04 To: Nikos Mavrogiannopoulos; Raja ashok; jayaraghavendra...@huawei.com Subject: Re: draft-jay-tls-psk-identity-extension-01 On Sat, 2016-09-17 at 09:53 +0200, Nikos Mavrogiannopoulos wrote: > Hello, > We were with David implementing the draft-jay-tls-psk-identity- > extension-01 on openconnect VPN, however we noticed that the latest > version of TLS 1.3 modified the identity extension in an incompatible > way. I am not sure if the new format can be used in place of the old > one. For that we would like to ask what is your plan about it. Would > you include the new format with some guidance on how to be used under > tls 1.2, or would you stick to the existing format? [ashok] : PSK Identity extension specified in our extension differs from the extension specified in TLS1.3. In TLS1.3 PSK identity extension they are trying to exchange whether its DHE based PSK or not and also authentication mechanism (PSK or cert based authentication), all these things for key_share extension. So that TLS1.3 has PskKeyExchangeModes and PskAuthenticationModes. But I hope these are not required for lower versions (TLS1.2, 1.1 and 1.0). So the extension proposed in this draft is only for usage with TLS1.2, 1.1 and 1.0. And I feel, we can make this as a separate extension to avoid confusion with TLS1.3 extension. If we feel anything needs to be inherited from TLS1.3 extension, we can do it. A couple of other comments on looking in detail at the draft... RFC4279 §5.1 says that PSK identities MUST be a character string, encoded in UTF-8. But the TLSv1.3 draft doesn't say this anywhere, and in fact in §4.5.1 it seems to suggest that for session resumption, we use a ticket constructed according to RFC5077 as the PSK identity. Which would probably be binary. If TLSv1.3 is going to allow non-UTF8 PSK identities and TLSv1.2 still doesn't, then it would be useful to clarify precisely what is allowed in draft-jay-tls-psk-identity-extension. [ashok] : PSK identity extension specified in this draft also expects the PSK ID as character string in UTF format, similar to RFC 4279. I will update this point in our draft, thanks for reminding me. Another difference I note between your draft and the current TLSv1.3 draft is that in TLSv1.3, the PreSharedKeyExtension data returned by the server is just an index in the identities offered by the client; not a copy of the identifier itself: struct { select (Handshake.msg_type) { case client_hello: PskIdentity identities<6..2^16-1>; case server_hello: uint16 selected_identity; } } PreSharedKeyExtension; ... selected_identity The server’s chosen identity expressed as a (0-based) index into the identities in the client’s list. [ashok] : I feel sending the selected ID is better, otherwise while process "server hello" msg, client has to maintain the PSK ID list in the same order in which it sent. Already there was a discussion in TLS1.3 group for sending selected ID instead of index. And a final nitpick... replace every instance it "it's" with "its" :) [ashok] : I will check and fix it. I will upload a revised draft. Thanks for your comments. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation Raja Ashok HUAWEI TECHNOLOGIES CO.,LTD. E-mail: raja.as...@huawei.com 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! ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Keeping TLS extension points working
Hi David & Steven, Here our intension is to find out buggy server which implemented a cipher suite support with wrong value other than specified in RFC. - If that wrong value usage in that buggy server collides with any real cipher suite on the period of deployment means, the bug would have identified immediately with some other non buggy client. - If that wrong value is in the range of unspecified value, then that bug thrives and it will come out only after several years when IANA assigns that value to some new cipher suite. In this case, can you please tell me why we decided only few values as GREASE value {0x0A0A, 0x1A1A, ..}. Whether chrome browser has found a real buggy web server which supports these values ? Regards, R Ashok ____ Raja Ashok VK 华为技术有限公司 Huawei Technologies Co., Ltd. [Company_logo] Phone: Fax: Mobile: Email: Huawei Technologies Co., Ltd. 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! From: David Benjamin [mailto:david...@chromium.org] Sent: 02 August 2016 19:30 To: Steven Valdez; Raja ashok; tls@ietf.org Subject: Re: [TLS] Keeping TLS extension points working To expand on that a little, since it seems comments (a) and (b) are really the same one: The purpose of having an explicitly reserved list (b) is precisely so we do not have to do a second handshake (a). The purpose here is to ensure we exercise the little-used codepaths, not introduce new ones. This is intended to be an extremely minimal mechanism. Clients add a tiny bit of code to their ClientHello and no server code changes at all. (Note that every MUST in the document is just reiterating what TLS already requires.) David On Tue, Aug 2, 2016 at 9:47 AM Steven Valdez mailto:sval...@google.com>> wrote: a) It seems like if an implementation has updated to be able to handle a specific GREASE alert, it should be able to handle not sending an invalid cipher suite. In general, its probably cleaner for the connection to fatally shutdown and then restart if the server is behaving that poorly. Servers that are sending back non-existent ciphers are also potentially broken in other ways, and I don't know whether a client should trust that it can reset any handshake state correctly if it were to try doing a "warning" alert. b) The reasoning behind having an explicit list is so that implementations don't send a value that ends up being defined as some other valid value. Otherwise its possible that some implementations will update to include GREASE values, but they might not update immediately upon new values being assigned by IANA, which means that there will be periods of times that some clients might send "fake" values that collide with real values, confusing the peer implementation into believing they actually support something that they don't and resulting in more intolerance issues between outdated GREASE clients and newly updated servers, with this intolerance being firmly the GREASE clients fault. The hardcoded list gets around this by making sure GREASE never overlaps with an actual value, though at the trade-off that badly designed implementations could choose to just hard-code ignore the GREASE codepoints. On Tue, Aug 2, 2016 at 2:59 AM Raja ashok mailto:raja.as...@huawei.com>> wrote: Hi Benjamin, I have gone through the GREASE mechanism which you proposed in your new draft. It’s really a nice idea for finding a buggy server before it thrives. I am having few doubts on this, which are listed below. a) What should be the behaviour of client incase if a buggy server responded for a GREASE value ? - Consider a client sends a GREASE cipher value at first place and followed by valid cipher suites, in its client hello. - If a buggy server selects that cipher then it will response server hello with that GREASE cipher value. At this case if client sends FATAL alert then both side TLS and TCP needs to be closed and client needs to recreate a new TCP connection, and then restart TLS handshake without GREASE cipher value. - Instead of this we can make client to send warning alert (with new TLS alert code GREASE_CIPHER_VALUE_SELECTED(111)) and restart TLS handshake by sending client hello again. - If a server receives this new warning, t
Re: [TLS] Keeping TLS extension points working
Hi Benjamin, I have gone through the GREASE mechanism which you proposed in your new draft. It’s really a nice idea for finding a buggy server before it thrives. I am having few doubts on this, which are listed below. a) What should be the behaviour of client incase if a buggy server responded for a GREASE value ? - Consider a client sends a GREASE cipher value at first place and followed by valid cipher suites, in its client hello. - If a buggy server selects that cipher then it will response server hello with that GREASE cipher value. At this case if client sends FATAL alert then both side TLS and TCP needs to be closed and client needs to recreate a new TCP connection, and then restart TLS handshake without GREASE cipher value. - Instead of this we can make client to send warning alert (with new TLS alert code GREASE_CIPHER_VALUE_SELECTED(111)) and restart TLS handshake by sending client hello again. - If a server receives this new warning, then it should be ready to receive new client hello to restart handshake. SERVER CLIENT CH (GREASE Cipher value & Valid Cipher value) --> <--- SH (GREASE cipher value) Fatal alert> TCP (SYN)> <TCP(SYN ACK) TCP (ACK)> CH (Valid cipher value) ---> Scenario 1 : Sending FATAL alert for server selecting GREASE value SERVER CLIENT CH (GREASE Cipher value & Valid Cipher value) ---> <--- SH (GREASE cipher value) Warning alert > CH (Valid cipher value) ---> Scenario 2 : Sending WARNING alert for server selecting GREASE value - I hope sending warning msg and restarting TLS handshake will be efficient. - TLS Server must notify the application, whenever it receives a GREASE warning alert. b) Why only few values are specified as GREASE value ? Basically all value which are not specified by IANA should be considered as GREASE value right ? - Basically client should maintain the list of values (cipher suite, extensions) specified by IANA. The range of values. - For example IANA specified cipher suite values are {{0x,0x005C}, {0x0060,0x006D}, {0x0084, 0x00C5}, {0x00FF, 0x00FF} ….. }. This should be maintained in client. - We should make the client to choose a random value which are not in this supported value list. That cipher value should be considered as GREASE value and need to keep in first place of its cipher list. - If its selected by a buggy server, then client should behave as mentioned in above scenario 2. - Even in future if IANA provides new values to new cipher, then this list also should be updated. Consider in this case server is supporting that new cipher and client is not aware about it, so client can propose that value as GREASE value, then still connection will work with the 2nd handshake. - I am not understanding why we are planning to maintain a few set of GREASE values {0x0A0A, 0x1A1A …. }. If I am missing something, please clarify me. Regards, R Ashok ____ Raja Ashok VK 华为技术有限公司 Huawei Technologies Co., Ltd. [Company_logo] Phone: Fax: Mobile: Email: Huawei Technologies Co., Ltd. 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! From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of David Benjamin Sent: 26 July 2016 04:02 To: tls@ietf.org Subject: [TLS] Keeping TLS extension points working Hi folks, I'm not sure how this process usually works, but I w