IETF conflict review for draft-camwinget-tls-ts13-macciphersuites
conflict-review-camwinget-tls-ts13-macciphersuites-00

The following approval message was sent
From: The IESG
To: Adrian Farrel ,
    draft-camwinget-tls-ts13-macciphersuites@ietf.org,
    rfc-ise@rfc-editor.org
Cc: IETF-Announce ,
    The IESG ,
    iana@iana.org
Subject: Results of IETF-conflict review for draft-camwinget-tls-ts13-macciphersuites-11

The IESG has completed a review of
draft-camwinget-tls-ts13-macciphersuites-11 consistent with RFC5742.

The IESG has no problem with the publication of 'TLS 1.3 Authentication and
Integrity only Cipher Suites'
as an Informational RFC.

The IESG has concluded that this work is related to IETF work done in WG TLS,
but this relationship does not prevent publishing.

The IESG would also like the Independent Submissions Editor to review the
comments in the datatracker related to this document and determine whether or
not they merit incorporation into the document. Comments may exist in both
the ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-camwinget-tls-ts13-macciphersuites/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-camwinget-tls-ts13-macciphersuites/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
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).

[Ballot comment]
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'

[Ballot comment]
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.