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
[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] 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 Corporation
Raja Ashok
HUAWEI
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, then the
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] 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
<sval...@google.com<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
<raja.as...@huawei.com<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.
