idnits 2.17.1 draft-rashok-tls-ticket-request-msg-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8446]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 20, 2019) is 1582 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-tls-dtls13' is defined on line 163, but no explicit reference was found in the text == Unused Reference: 'RFC5077' is defined on line 169, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-tls-ticketrequests-04 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-34 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Ashok 3 Internet-Draft Huawei 4 Intended status: Standards Track December 20, 2019 5 Expires: June 22, 2020 7 TLS Ticket Request Message 8 draft-rashok-tls-ticket-request-msg-00 10 Abstract 12 TLS session ticket provides a stateless mechanism for server to 13 resume connection with client. As per TLS 1.3 [RFC8446], server 14 always sends arbitary number of session ticket after handshake. This 15 document introduces a new message which is TicketRequest message, it 16 can be send by client after handshake at any point of connection 17 lifetime to retrieve session ticket. The proposed mechanism in this 18 document is only for TLS 1.3 and DTLS 1.3 and future versions. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 22, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 56 2. SessionTicket Generation . . . . . . . . . . . . . . . . . . 2 57 3. TicketRequest Message . . . . . . . . . . . . . . . . . . . . 3 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 6.1. Normative References . . . . . . . . . . . . . . . . . . 3 62 6.2. Informative References . . . . . . . . . . . . . . . . . 4 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1. Introduction 67 As per TLS 1.3 [RFC8446], TLS server sends arbitary number of session 68 ticket after handshake (or after post-handshake authentication). 69 Such session tickets are needed only for a client which resumes 70 parallel connections to server immediately. But this delays the 71 application data processing for a client which is not going to resume 72 parallel connections immediately. Such clients might need session 73 ticket at later point of time or it may not need also. 75 So a client's need based session ticket generation will be more 76 efficient on both server and client. 78 To achieve this a new TicketRequest message is proposed in this 79 specification, which should be send by client as and when it needs 80 session ticket for resumption. 82 1.1. Requirements Language 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 86 "OPTIONAL" in this document are to be interpreted as described in 87 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 88 as shown here. 90 2. SessionTicket Generation 92 Client should be able to retrieve session ticket from server in two 93 ways 95 o As per [RFC8446] immediately after handshake or after post- 96 handshake authentication. 98 o By sending TicketRequest message to server at later time during 99 data transfer. 101 A new ticket_request extension [I-D.ietf-tls-ticketrequests] has been 102 proposed to give control over client to request the amount of session 103 ticket it needs for resuming parallel connection immediately after 104 handshake. 106 This extension SHOULD be send by client with 107 TicketRequestContents.count as zero, if it does not need to resume 108 parallel connection immediately after handshake. Then it can use 109 TicketRequest message at later point when it needs to resume 110 connection. 112 A client can send any number of TicketRequest message in its 113 connection lifetime with server. But server SHOULD limit the total 114 number of ticket issued to client per connection to prevent DOS 115 attack. 117 3. TicketRequest Message 119 TicketRequest message send by client holds the count parameter, which 120 indicates how much session ticket immediately client needs. 122 Structure of this message: 124 struct { 125 uint8 count; 126 } TicketRequest; 128 count The number of tickets needed by client 130 4. IANA Considerations 132 Needs to register new TLS message type TicketRequest in IANA 134 5. Security Considerations 136 The amount of ticket requested per connection should be limited by 137 threshold value at server to prevent DOS attack. 139 6. References 141 6.1. Normative References 143 [I-D.ietf-tls-ticketrequests] 144 Pauly, T., Schinazi, D., and C. Wood, "TLS Ticket 145 Requests", draft-ietf-tls-ticketrequests-04 (work in 146 progress), November 2019. 148 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 149 Requirement Levels", BCP 14, RFC 2119, 150 DOI 10.17487/RFC2119, March 1997, 151 . 153 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 154 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 155 May 2017, . 157 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 158 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 159 . 161 6.2. Informative References 163 [I-D.ietf-tls-dtls13] 164 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 165 Datagram Transport Layer Security (DTLS) Protocol Version 166 1.3", draft-ietf-tls-dtls13-34 (work in progress), 167 November 2019. 169 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 170 "Transport Layer Security (TLS) Session Resumption without 171 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 172 January 2008, . 174 Author's Address 176 Raja Ashok 177 Huawei 178 Whitefield 179 Bengaluru, Karnataka 560037 180 India 182 Email: rashok.ietf@gmail.com