idnits 2.17.00 (12 Aug 2021) /tmp/idnits8821/draft-asmithee-tls-dnssec-downprot-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 draft header indicates that this document updates RFC10000, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- No information found for rfc10000 - is the name correct? -- The document date (May 15, 2018) is 1460 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) == Missing Reference: 'TBD' is mentioned on line 170, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'TLSIANA' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Alan Smithee 3 Internet-Draft 4 Updates: 10000 (if approved) Alan Smithee 5 Intended status: Standards Track May 15, 2018 6 Expires: November 16, 2018 8 TLS Downgrade protection extension for TLS DNSSEC Authentication Chain 9 Extension 10 draft-asmithee-tls-dnssec-downprot-00 12 Abstract 14 This draft specifies a TLS extension that adds downgrade protection 15 for another TLS extension, [dnssec-chain-extension]. Without the 16 downgrade protection specified in this TLS extension, the only effect 17 of deploying [dnssec-chain-extension] is to reduce TLS security from 18 the standard "WebPKI security" to "WebPKI or DANE, whichever is 19 weaker". 21 This draft dictates that [dnssec-chain-extension] MUST only be used 22 in combination with this TLS extension, whose only content is a two 23 octet SupportLifetime value. A value of 0 prohibits the TLS client 24 from unilaterally requiring ongoing use of both TLS extensions based 25 on prior observation of their use (pinning). A non-zero value is the 26 value in hours for which this TLS extension as well as 27 [dnssec-chain-extension] MUST appear in subsequent TLS handshakes to 28 the same TLS hostname and port. If this TLS extention or 29 [dnssec-chain-extension] is missing from the TLS handshake within 30 this observed pinning time, the TLS client MUST assume it is under 31 attack and abort the TLS connection. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on November 16, 2018. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 68 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 3. TLS DNSSEC Extension Downgrade Protection Extension format . 3 70 4. Operational Considerations . . . . . . . . . . . . . . . . . 3 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 73 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 76 1. Requirements Notation 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 80 "OPTIONAL" in this document are to be interpreted as described in BCP 81 14 [RFC2119] [RFC8174] when, and only when, they appear in all 82 capitals, as shown here. 84 2. Introduction 86 This draft specifies a TLS extension that adds downgrade protection 87 for another TLS extension, [dnssec-chain-extension]. Without the 88 downgrade protection specified in this TLS extension, the only effect 89 of deploying [dnssec-chain-extension] is to reduce TLS security from 90 the standard "WebPKI security" to "WebPKI or DANE, whichever is 91 weaker". 93 This draft dictates that [dnssec-chain-extension] MUST only be used 94 in combination with this TLS extension, whose only content is a two 95 byte SupportLifetime value. A value of 0 prohibits the TLS client 96 from unilaterally requiring ongoing use of both TLS extensions based 97 on prior observation of their use (pinning). A non-zero value is the 98 value in hours for which this TLS extension as well as 99 [dnssec-chain-extension] MUST appear in subsequent TLS handshakes to 100 the same hostname and port. If this TLS extention or 101 [dnssec-chain-extension] is missing from the TLS handshake within 102 this observed pinning time, the TLS client MUST assume it is under 103 attack and abort the TLS connection. 105 3. TLS DNSSEC Extension Downgrade Protection Extension format 107 The "extension_data" field of the "dnssec_chain_commit" extension 108 contains a two octet value specifying the pinning time in hours for 109 both this extension and [dnssec-chain-extension] in the following 110 form: 112 struct { 113 uint16 SupportLifetime; 114 } DnssecChainExtensionCommitTime; 116 A zero "SupportLifetime" prohibits the client from unilaterally 117 requiring ongoing use of this extension or [dnssec-chain-extension] 118 based on prior observation of their use (pinning). 120 A non-zero value signifies the time in hours for which this resource 121 commits to publishing both this extension and 122 [dnssec-chain-extension]. If within the specified time a TLS 123 connection for this resource omits either TLS extension, the TLS 124 client MUST conclude it is under attack and MUST abort the TLS 125 connection. 127 4. Operational Considerations 129 A positive DANE validated response for the TLSA record in 130 [dnssec-chain-extension] MUST override any previous SupportLifetime 131 information that the TLS client stored previously. In addition, if 132 the TLS client previously obtained a valid TLSA record with a 133 SupportLifetime commitment further into the future, and as part of 134 the current TLS handshake it receives a DNSSEC-validated answer 135 containing no TLSA record and a Denial of Existence proof via 136 [dnssec-chain-extension], the TLS client MUST clear the previously 137 stored TLS extensions pinning value. 139 If a specific resource is served using multiple TLS servers or 140 clusters, and a non-zero value for SupportLifetime is used, all TLS 141 server instances MUST support serving both this extension and 142 [dnssec-chain-extension]. As long as no TLS service instance uses a 143 non-zero value, both TLS extensions can be rolled out incrementally 144 without any TLS clients commiting to either TLS extension. 146 5. Security Considerations 148 This draft specifies a TLS extension that adds downgrade protection 149 for another TLS extension, [dnssec-chain-extension]. Without the 150 downgrade protection specified in this TLS extension, the only effect 151 of deploying [dnssec-chain-extension] is to reduce TLS security from 152 the standard "WebPKI security" to "WebPKI or DANE, whichever is 153 weaker". 155 This draft dictates that [dnssec-chain-extension] MUST only be used 156 in combination with this TLS extension, whose only content is a two 157 byte SupportLifetime value. A value of 0 prohibits the TLS client 158 from unilaterally requiring ongoing use of both TLS extensions based 159 on prior observation of their use (pinning). A non-zero value is the 160 value in hours for which this TLS extension as well as 161 [dnssec-chain-extension] MUST appear in subsequent TLS handshakes to 162 the same hostname and port. If this TLS extention or 163 [dnssec-chain-extension] is missing from the TLS handshake within 164 this observed pinning time, the TLS client MUST assume it is under 165 attack and abort the TLS connection. 167 6. IANA Considerations 169 This extension requires the registration of a new value in the TLS 170 ExtensionsType registry. The value requested from IANA is [TBD], and 171 the extension should be marked "Recommended" in accordance with "IANA 172 Registry Updates for TLS and DTLS" [TLSIANA]. 174 7. Normative References 176 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 177 Requirement Levels", BCP 14, RFC 2119, 178 DOI 10.17487/RFC2119, March 1997, . 181 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 182 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 183 May 2017, . 185 [dnssec-chain-extension] 186 Shore, M., Barnes, R., Hugue, S., and W. Toorop, "A DANE 187 Record and DNSSEC Authentication Chain Extension for TLS", 188 March 2018, . 191 [TLSIANA] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 192 and DTLS", . 195 Authors' Addresses 197 Alan Smithee 199 EMail: pwouters@redhat.com 201 Alan Smithee 203 EMail: ietf-dane@dukhovni.org