IETF conflict review for draft-camwinget-tls-ts13-macciphersuites
conflict-review-camwinget-tls-ts13-macciphersuites-00
Yes
No Objection
Roman Danyliw
(Alvaro Retana)
(Martin Duke)
(Robert Wilton)
Note: This ballot was opened for revision 00 and is now closed.
Ballot question: "Is this the correct conflict review response?"
Erik Kline
No Objection
Comment
(2021-05-29)
Not sent
I support requesting the authors to consider Ben's comments.
Murray Kucherawy
No Objection
Comment
(2021-06-02)
Sent
I support requesting the authors to consider the other ADs' comments.
Roman Danyliw
No Objection
Zaheduzzaman Sarker
No Objection
Comment
(2021-06-03)
Not sent
Ben's comment should be addressed.
Éric Vyncke
No Objection
Comment
(2021-05-31)
Sent
I can only regret that the TLS WG has not adopted this document (or perhaps was it against the TLS WG charter ? I have not checked). As I quickly browsed through the document, here are some comments. I cannot parse the first sentence of the abstract (but, I am not a native English speaker). I suggest that the abstract part starting with "The approach described in this document" should be another paragraph. 2nd paragraph of section 3: integrity is important but what about authentication in this use case ? While I like the civil aviation use case of section 3, ATC is 'Aviation Traffic Control', i.e., does not include 'center'
Benjamin Kaduk Former IESG member
Yes
Yes
(2021-05-28)
Sent
IESG There are a few points here that are potentially noteworthy as the IESG considers whether the proposed "related, but no conflict" text is the correct conflict-review response: (1) TLS 1.3 treats ciphers as AEAD. https://datatracker.ietf.org/doc/html/rfc8446#section-5.2 does call out that the field of ciphersuites has been swept clean and the expectation for AEAD in future ciphers, but it seems that one can model null-encryption-with-HMAC-tag to fit an AEAD interface. Similarly, the changes to the IANA registry procedures in RFCs 8446 and 8447 seem pretty clear that the intent is not to have a gatekeeping function for getting codepoints allocated, even at the cost of having algorithms get codepoints that are cryptograhpically bad. (2) This draft does not specify a mechanism for DTLS record sequence number encryption. To me, this seems more properly a matter that IANA should enforce, rather than calling for a "violates IETF procedures" conflict-review response. I would expect that IANA can have DTLS-OK set to 'N' until some explicit text about the DTLS record sequence number encryption procedure being to just send the cleartext number. (3) The text in Section 5 as written appears to redefine the TLSCiphertext and DTLSCiphertext structures in a non-compatible manner. I assume this is just an editorial issue and not an intent to change the wire format, given the nature of the surrounding prose. COMMENT Since I was reviewing the document anyway, I took the opportunity to record some comments (as well as some nit-level remarks that are unlikely to merit a response, in a separate section). Hopefully the authors and ISE find them useful and treat them as they would any other review of the document. It is interesting to compare this work with draft-ietf-hip-dex, which is also an attempt to produce a cryptographic suite for highly constrained devices that benefit from reducing the number of cryptographic primitives needed (at the cost of weakened protections). That scheme was able to utilize CMAC and CKDF that can leverage the hardware AES support present on many CPUs, while avoiding the need for cryptographic hash functions. GMAC is another (relatively) lightweight MAC that often benefits from hardware support, though is not (to my knowledge) suitable for use as a KDF and thus probably not a great fit for TLS 1.3 where a KDF is needed. Additionally, I can't help but sympathize with the IOTdir reviewer that the "constrained device" use cases as motivation are underwhelming. The mere absence of a requirement to do something is not in and of itself a motivation to not do that thing (since it is otherwise desirable, here, given RFC 7258 and the like); the specific requirement to not encrypt in the railway-signaling case is much more persuasive. The "constrained device" scenario would benefit from presenting actual hard data about device throughput in the various scenarios, in order to present a compelling motivation for these ciphers. (That hard data could also compare a CMAC-based scheme, per the previous paragraph.) It seems that a complete treatment of MAC-only ciphersuites would include an analysis of the limits on key usage (akin to https://datatracker.ietf.org/doc/html/rfc8446#section-5.5), since even the MAC-only write keys would still experience degraded protection with extended use. I can't really justify recommending (in any capacity) that the ISE hold publication until such analysis appears, though. Abstract The first bits of the abstract are quite hard to follow, and maybe not even well-formed sentences. I'd suggest a rewrite to: % This document defines the use of HMAC-only cipher suites for TLS 1.3, % which provides server and optionally mutual authentication and data % authenticity, but not data confidentiality. Cipher suites with these % properties are not of general applicability, but there are use cases, % specifically in Internet of Things (IoT) and constrained environments, % that do not require confidentiality of exchanged messages while still % requiring integrity protection, server authentication, and optional % client authentication. This document gives examples of such use % cases, with the caveat that prior to using these integrity-only cipher % suites, a threat model for the situation at hand is needed, and a % threat analysis must be performed within that model to determine % whether the use of integrity-only ciphersuites is appropriate. The % approach described in this document is not endorsed by the IETF and % does not have IETF consensus, but is presented here to enable % interoperable implementation of a reduced security mechanism that % provides authentication and message integrity without supporting % confidentiality. (In light of the iotdir review, it seems like it would also be fine to drop the clause aboue "specifically in Internet of Things (IoT) and constrained environments" entirely, but I attempted to remain faithful to the original in my proposal above.) Section 3 still quite important. Modification of the data can at best lead to a denial-of-service attack, although a more intelligent threat actor might be able to cause actual physical damage. As these time Given that the second half of the sentence goes on to contradict it, I suggest changing "can at best lead to". Perhaps "the consequences of maliciously modified time data can vary from mere denial of service to actual physical damage, depending on the particular situation and attacker capability". (FWIW, I could perhaps contrive a scenario where bad time information leads a component to dispatch physical materials containing confidential trade-secret information to a party not authorized to receive them, but that's quite far afield from the actual point here.) Sending data that is just authenticated but not encrypted significantly eases the burden placed on these devices, yet still allows the data to be protected against any tampering threats. A (It's not actually clear what kind of data exists to support the "significantly" in "significantly eases".) In many systems the reading of this data doesn't grant the attacker information that can be exploited, it is generally just information regarding the airplane states, controller pilot communication, meteorological information It's a bit surprising to see "controller/pilot communication" classified in this way, assuming that's referring to actual live human-to-human communication. My colleagues on the IESG who are licensed pilots can correct me (if they're reading this), but I'm given to understand that a fair bit of banter can occur between pilots and ground controllers they know well, and may well involve discussion of their family situation, personal details, etc., that would be considered confidential information in other contexts. Section 4 These cipher suites allow the use of SHA-256 or SHA-384 as the HMACs for data integrity protection as well as its use for Hashed Message Authentication Code (HMAC)-based Key Derivation Function (HKDF). [...] It might be helpful to map this more clearly to the definition of a TLS 1.3 cipher suite, which is an (AEAD, HKDF hash) pair. That the indicated hash is the hash used for HKDF is clear, but I would say something about how the AEAD interface is modeled by having the HMAC authentication tag play the role of the AEAD authentication tag, with null encryption. The authentication mechanisms remain unchanged with the intent to only update the cipher suites to relax the need for confidentiality. This part doesn't seem to be about "relax the need for confidentiality"; it's more of a "remove the confidentiality protection". Given that these cipher suites do not support confidentiality, they MUST NOT be used with authentication and key exchange methods that rely on confidentiality. I would expect a "this includes, but is not limited to" here. Section 5 The record payload protection as defined in [RFC8446] can be retained when integrity only cipher suites are used. Note that due to the Don't say what "can" be done, say what *is* done. Which to me sounds like "is retained in modified form". purposeful use of hash algorithms, instead of AEAD algorithms, the confidentiality protection of the record payload cannot be provided. Likewise, "is not provided". TLSCiphertext = TLS13-HMAC-Protected = TLSInnerPlaintext || HMAC(write_key, nonce || additional_data || TLSInnerPlaintext) This is wrong. The TLSCiphertext structure includes opaque_type, legacy_record_version, and length before the enccrypted_record (which will start with the TLSInnerPlaintext for the integrity-only cipher suites being defined here). DTLSCiphertext = DTLS13-HMAC-Protected = DTLSInnerPlaintext || HMAC(write_key, nonce || additional_data || DTLSInnerPlaintext) Likewise, this omits the required header structure from DTLSCiphertext. The Protect and Unprotect operations provide the integrity protection using HMAC SHA-256 or HMAC SHA-384 as described in [RFC6234]. It's not clear that we get much value out of defining the abstract "Protect" and "Unprotect" operations just to use them in this one place. Section 7 decrypt_error: This alert as described in [RFC8446] Section 6.2 occurs when the signature or message authentication code can not be validated. I think it would be appropriate to remind the reader that per RFC 8446, this alert is only sent for a handshake (not record layer) cryptographic operation failure, and as such will never be generated in response to the modified record-layer processing this document specifies. Section 9 Some statement about the expected (non?) impact on 0-RTT usage of MAC-only ciphers might be interested. I think it's important to reiterate that application protocols building on TLS (e.g., HTTPS) may have implicit assumptions of data confidentiality that are invalidate by the use of these cipher suites. Merely noting that the "data transported" over TLS has no such protection glosses over this aspect of things. provisions for confidentiality. Furthermore, with this lack of confidentiality, any private PSK data MUST NOT be sent in the handshake while using these cipher suites. In a similar vein, we could note that bearer tokens must not be sent over the application-data channel, here. In general, with the exception of confidentiality and privacy, the security considerations detailed in [RFC8446] and in [RFC5246] apply to this document. [...] It's slightly surprising to pull in TLS 1.2 (RFC 5246) for what is otherwise a (D)TLS-1.3-only document. NITS Section 1 closed system). Note however, this situation will not apply equally to all use cases (for example, a robotic arm might be used in one case for a process that does not involve any intellectual property, but in another case that does). Therefore, it is important that a I don't think that "but in another case that does" is a complete clause in that part of the sentence. user or system developer carefully examine both the sensitivity of the data and the system threat model to determine the need for encryption before deploying equipment I'm not sure if this is just a missing full stop or there was intended to be more to the sentence (seems more like the latter). Section 2 Although this document is not an IETF Standards Track publication it I'd consider dropping "Standards Track"; the BCP 14 keywords are described as being used for "IETF documents", with standards-track documents being only an example of (then-)current usage. Section 3 The two HMAC SHA [RFC6234] based cipher suites referenced in this s/referenced/defined/ document are intended for a small limited set of applications where confidentiality requirements are relaxed and the need to minimize the cryptographic algorithms are prioritized. This section describes Singular/plural mismatch for need/are. Also, probably "number of cryptographic algorithms required" or similar (since "cryptographic algorithms" itself is a collection without cardinality or metric). Section 3 Another use case which is closely related is that of fine grained time updates. Motion systems often rely on time synchronization to hyphenate "fine-grained". ensure proper execution. Time updates are essentially public, there is no threat from an attacker knowing the time update information. comma splice. automated system to take corrective action. Once again, in many systems the reading of this data doesn't grant the attacker information that can be exploited, it is generally just information regarding the physical state of the system. At the same time, being Interestingly, this also looks like a comma splice but my native-speaker filter doesn't seem to find it problematic. Curious. passing train. Furthermore, requirements for providing blackbox recording of the safety related network traffic can only be fulfilled through using integrity only ciphers, to be able to provide the "through use of" or "by using". The fifth use case deals with data related to civil aviation airplanes and ground communication. Pilots can send and receive messages to/from ground such as airplane route-of-flight update, IIUC, "ground" typically takes an article or other specifier (e.g., "ground control"). Similarly, the Air Traffic Control Centers (ATC) use air to ground communication to receive the surveillance data that relies on (is dependent on) downlink reports from an airplane's avionics that occur automatically in accordance with contracts established between the ATC ground system and the airplane's avionics. [...] This sentence is maybe getting a little long. occur, or specific time intervals are reached. In many systems the reading of this data doesn't grant the attacker information that can be exploited, it is generally just information regarding the airplane states, controller pilot communication, meteorological information etc. [...] comma splice attacker to either put aircraft in the wrong flight trajectory or to provide false information to ground that might delay flight and (same comment about taking an article as a few lines above) "delay flight" seems to have a mismatch as well, maybe "delay a flight" or "delay flights". The above use cases describe the relaxed requirements to not provide confidentiality, and as these devices come with a small runtime This flows a bit oddly to me, as the requirement that is being relaxed is the requirement *to* provide confidentiality, and we end up in a situation where we have relaxed requirements that do not include a need to provide confidentiality. memory footprint and reduced processing power, the need to minimize the number of cryptographic algorithms used is prioritized. Despite I think "prioritized" comes with an implication of action, and so "is a priority" might be more appropriate here. Section 5 I think "integrity-only cipher suites" should be hyphenated thusly. As integrity is provided with protection over the full record, the "integrity protection is provided over the full record". As integrity is provided with protection over the full record, the encrypted_record in the TLSCiphertext along with the additional_data input to protected_data (termed AEADEncrypted data in [RFC8446]) as defined in Section 5.2 of [RFC8446] remains the same. The s/remains/remain/ (both encrypted_record and additional_data) Note that TLSInnerPlaintext_length is not defined as an explicit field in [RFC8446], this refers to the length of the TLSInnterPlaintext structure comma splice. Also, I'd put "encoded" somewhere in "length of the TLSInnerPlaintext structure". The resulting protected_record is the concatenation of the This is the only instance of the string "protected_record" in the document. Replacing with "encrypted_record" probably makes the most sense, as that is the field from RFC 8446 that is being populated. Due to the lack of encryption of the plaintext, record padding is not needed, although it can be optionally included. I would say that record padding "does not provide any obfuscation as to plaintext sizes". Whether or not it is "needed" depends on many things even for regular TLS 1.3. The key lengths and IVs for these cipher suites are according to the hash lengths. In other words, the following key lengths and IV lengths SHALL be: I'd say "hash output lengths"; there's also a (larger) internal block length that could be considered a "length". Section 9 privacy requirements and concerns; and the runtime memory requirements can accommodate support for more cryptographic constructs. Is the sense of this reversed? (If not, what are the "more cryptographic constructs" that this specification pulls in?) With the lack of data encryption specified in this draft, no I'd go with "in this specification", since it won't be a draft if it becomes an RFC.
Alvaro Retana Former IESG member
No Objection
No Objection
()
Not sent
Lars Eggert Former IESG member
No Objection
No Objection
(2021-05-31)
Sent
This document uses RFC2119 keywords, but does not contain the recommended RFC8174 boilerplate. (It contains a variant of the RFC2119 boilerplate.) ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 1, paragraph 2, nit: > red to ensure integrity of the message.. Besides having a strong need for aut > ^^ Two consecutive dots Section 3, paragraph 3, nit: > ch is closely related is that of fine grained time updates. Motion systems of > ^^^^^^^^^^^^ This word is normally spelled with a hyphen. Section 3, paragraph 4, nit: > ack surface dealing with privacy. However the authenticity is still quite im > ^^^^^^^ Did you forget a comma after a conjunctive/linking adverb? "I", paragraph 3, nit: > ollowing: This document requests a numbers be assigned for each TLS_SHA256_S > ^^^^^^^^^ The plural noun "numbers" cannot be used with the article "a". Did you mean "a number" or "numbers"? Section 8, paragraph 1, nit: > rovided for the data transported in the the TLS tunnel. 9. Acknowledgements > ^^^^^^^ Maybe you need to remove one determiner so that only "the" or "the" is left. Document references draft-ietf-tls-tls13, but that has been published as RFC8446. Obsolete reference to RFC4634, obsoleted by RFC6234 (this may be on purpose). Obsolete reference to RFC5246, obsoleted by RFC8446 (this may be on purpose).
Martin Duke Former IESG member
No Objection
No Objection
()
Not sent
Robert Wilton Former IESG member
No Objection
No Objection
()
Not sent