IETF conflict review for draft-smyshlyaev-tls12-gost-suites
conflict-review-smyshlyaev-tls12-gost-suites-01

The following approval message was sent
From: The IESG
To: Adrian Farrel ,
    draft-smyshlyaev-tls12-gost-suites@ietf.org,
    rfc-ise@rfc-editor.org
Cc: IETF-Announce ,
    The IESG ,
    iana@iana.org
Subject: Results of IETF-conflict review for draft-smyshlyaev-tls12-gost-suites-17

The IESG has completed a review of draft-smyshlyaev-tls12-gost-suites-17
consistent with RFC5742.

The IESG has no problem with the publication of 'GOST Cipher Suites for
Transport Layer Security (TLS) Protocol Version 1.2'
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-smyshlyaev-tls12-gost-suites/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-smyshlyaev-tls12-gost-suites/

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

Thank you,

The IESG Secretary

[Ballot comment]
==[ for -17
I support the revised conflict review text of "The IESG has concluded that this work is related to IETF work done in WG
TLS, but this relationship does not prevent publishing."

==[ for -13
I support the conflict review text of "The IESG has concluded that this document violates IETF procedures for what behaviors TLS cipher suites are allowed to modify and should therefore not be published without IETF review and IESG approval."

If this document was proposing a TLS 1.2 profile, rather than just a ciphersuites, I don’t believe there would be a conflict with constraining compression behavior; or the values for supported_signature_algorithms and certificate_types.

[Ballot comment]
PREFACE

This note constitutes a ballot position on the IESG conflict review
response for draft-smyshlyaev-tls12-gost-suites-13.  RFC 5742 requires
the IESG to review documents submitted to the RFC Editor by the IRTF and
ISE, and to produce one of a fixed set of conflict-review responses.  The
response I have selected is visible in the datatracker page for this
conflict review.  In this case, the response is number 2, "the IESG has
concluded that this work is related to IETF work ... but this relationship
does not prevent publishing."

However, that response is not final until approved by the IESG as a
whole, and other IESG members may produce ballot comments on
this conflict-review as well.  Since the primary purpose of this IESG
balloting activity is to agree on the conflict-review response, I will
include remarks in the "IESG" section below that are directed at the
other IESG members and attempt to clarify why I chose this option for
the response, as well as laying out any other potentially relevant
factors that might influence the IESG's decision (even if they do not
directly support the conclusion that I reached).  That said, the remarks
in the "IESG" section may be of interest to the authors, if they
indicate changes that could be made to the document that might result in
a different conflict-review response from the IESG.  Please note that in
preparing the IESG conflict-review response, I am tasked only with
determining whether IETF process is being followed, and am not tasked
with assessing the quality or content of the document in other ways.
However, because I had to read the draft in question in order to decide
what conflict-review response to propose, I also include (under the
"COMMENT" heading) some remarks about the document itself; these
comments are directed at the authors and ISE, but have no formal
standing.  They are safe to ignore, and whether/how to act (or not act)
on them is a matter for the ISE and authors to determine; I will only
participate in further discussion if explicitly asked to do so.

IESG

The changes from version -13 to version -17 of the draft address
my previous concerns about what behaviors are allowed to be specified
as part of a TLS cipher suite vs a profile of TLS.  In fact, there may
have been a slight over-correction, as noted in the COMMENT below.

The comments on Section 9 may also be of interest to IESG members --
the values from the orphaned TLS SignatureAlgorithms registry were
approved by the experts even though the Reserved values should not
have been allocated.  This was not discovered until a couple years later,
at which point code was already shipping.  My understanding is that the
only actual use is in combination with the "intrinsic" HashAlgorithm value,
which corresponds to the compatibility TLS SignatureScheme values that
this draft is also allocating.  The DEs recommended against trying to
"claw back" the Reserved TLS SignatureAlgorithm values, and all parties
have been quite helpful in seeking the best way to resolve this situation
so as to avoid any future interoperability failures relating to the codepoint
allocations.  In the COMMENT, I suggest adding a (foot)note to the
SignatureAlgorithm registrations; that's mostly out of expedience, since
such notes can be added by this document itself.  It would also be possible
to add a similar note to the registry itself, but that would probably require
an IETF-stream document and incur additional delay.

COMMENT

Many thanks to the authors for the updates since the -13!
I have a few comments remaining, mostly that are refining or revising
some of my previous comments (including a couple that represent a change
of position from my previous comments; my apologies for that churn).

Section 4.1.1

  Note that the profile of TLS 1.2 with GOST algorithms uses the
  authenticate-then-encrypt method (see Appendix F.4 of [RFC5246]).
  The profile of TLS 1.2 with GOST algorithms requires that the
  encrypt_then_mac extension is not used in the ServerHello message
  (see Section 4.2.1).

Having gone and re-read RFC 7366 since my first review of this document,
I think it would be better to make a statement about non-use of
encrypt_then_mac that's based on these GOST ciphers acting as stream
ciphers, rather than as a requirement of the profile.  So this might look
something like:

% Note that the CTR_OMAC cipher suites use the authenticate-then-encrypt
% method (see Appendix F.4 of [RFC5246]).  Since these ciphers are
% functioning as stream ciphers, the authenticate-the-encrypt method is
% secure, and as specified by [RFC7366], a server that selects the
% CTR_OMAC ciphers must not send an encrypt-then-MAC response extension
% to the client.

[further commentary on the above]
I recognize that this is a somewhat different message than I gave in my
initial review comments, and I apologize for having changed my position.
While §6.2.3.1 of RFC 5246 does say that for GenericStreamCipher "the
MAC is computed before encryption", I think that the key point is that
the plaintext data is the MAC input (vs the ciphertext), and no strong
statement is intended about whether the MAC value is used as input to
the encryption operation.  (Indeed, TLS 1.2 does not encrypt the MAC
value, despite Appendix F.4 of RFC5246 claiming that the
authenticate-then-encrypt case that is proven secure is when the MAC
value *is* encrypted with the stream cipher.  So this draft clearly
falls in the "secure" case while TLS 1.2 itself is not directly
covered.)  Additionally, while RFC 7366 does mention the
GenericStreamCipher structure, the actual normative requirement on the
server is written conditional on "selects a stream or [AEAD] ciphersuite",
which does seem to apply in this case.

I don't have a position on whether it's worth putting in more effort to
write the formulas for the MACValue_seqnum and ENCValue_seqnum in some
"pedandtically correct" method that has a separate MAC output (as RFC
5246 wants for GenericStreamCipher) from the encryption output while
keeping the actual wire format unchanged.  It seems unlikely that an
implementor would actually be confused about what to do, and given that
there are existing implementations to do interoperability testing with,
trying to change the specification text in that manner seems like a lot
of work for minimal benefit.
[end commentary]

Section 4.1.2

  Note that the profile of TLS 1.2 with GOST algorithms uses the
  authenticate-then-encrypt method (see Appendix F.4 of [RFC5246]).
  The profile of TLS 1.2 with GOST algorithms requires that the
  encrypt_then_mac extension is not used in the ServerHello message
  (see Section 4.2.1).

My comments on CTR_OMAC apply essentially unchanged here; my analogous
proposal would be:

% Note that the CNT_IMIT cipher suite uses the authenticate-then-encrypt
% method (see Appendix F.4 of [RFC5246]).  Since this cipher is
% functioning as a stream cipher, the authenticate-the-encrypt method is
% secure, and as specified by [RFC7366], a server that selects the
% CNT_IMIT cipher must not send an encrypt-then-MAC response extension
% to the client.

Section 4.2

  The profile of TLS 1.2 with GOST algorithms described in this
  document uses a key encapsulation mechanism based on Diffie-Hellman
  to share the TLS premaster secret.

I think its okay to talk about "the cipher suites defined in this
document", here -- in TLS 1.2, the key-exchange mechanism is formally
part of the cipher suite specification.  (The authentication behavior is
more muddled; as §7.4.1.4.1 of RFC 5246 notes, "the semantics of [the
"signature_algorithms"] extension are somewhat complicated because the
cipher suite indicates permissible signature algorithms but not hash
algorithms.")

Section 4.2.1

  *  The ServerHello.extensions field MUST NOT contain the
      encrypt_then_mac extension (see [RFC7366]).

The previous notes I suggested about how RFC 7366 already forbids the
server from sending encrypt_then_mac for stream ciphers might supersede
this explicit requirement.  But it's not problematic in any way to have
the GOST profile also require this -- your choice.

Section 9

Some side discussions with IANA have revealed that they have the ability
to attach footnotes to registry entries.
I think it would be helpful for the SignatureAlgorithm entries to have a
note indicating the unusual circumstances that accompanied them.  In
particular, it seems noteworthy that they were assigned from the
"Reserved" state due to an oversight by the DEs, and that these should
not be seen as setting a precedent for future allocations from that
registry (per RFC 8447 the registries are "orphaned" and thus not
expected to see further development).

There are probably lots of ways to write something that would be useful,
and I don't know how much effort it makes sense to put into optimizing
this text.  My current proposal for what to add to this document is:

% IANA [has added/is requested to add] a note to the allocated TLS
% SignatureAlgorithm values 64 and 65, reading "This value was allocated
% from the Reserved state due to a misunderstanding of the difference
% between Reserved and Unallocated that went undetected for a long time.
% Additional allocations from the Reserved state are not expected, and
% the TLS SignatureScheme registry is suitable for use for new
% allocations instead of this registry."

I would be happy for suggestions on how to improve that text, especially
from IANA and/or the DEs for that registry.

Appendix A

[I did not attempt to validate the examples, but thank you very much for
including them!]

[Ballot comment]
I support the conflict review text.

If this document was proposing a TLS 1.2 profile, rather than just a ciphersuites, I don’t believe there would be a conflict with constraining compression behavior; or the values for supported_signature_algorithms and certificate_types.

[Ballot comment]
PREFACE

This note constitutes a ballot position on the IESG conflict review
response for draft-smyshlyaev-tls12-gost-suites-13.  RFC 5742 requires
the IESG to review documents submitted to the RFC Editor by the IRTF and
ISE, and to produce one of a fixed set of conflict-review responses.  The
response I have selected is visible in the datatracker page for this
conflict review.  In this case, the response is number 4, "the IESG has
concluded that this document violates IETF procedures ... and should
therefore not be published without IETF review and IESG approval".
However, that response is not final until approved by the IESG as a
whole, and other IESG members will likely produce ballot comments on
this conflict-review as well.  Since the primary purpose of this IESG
balloting activity is to agree on the conflict-review response, I will
include remarks in the "IESG" section below that are directed at the
other IESG members and attempt to clarify why I chose this option for
the response, as well as laying out any other potentially relevant
factors that might influence the IESG's decision (even if they do not
directly support the conclusion that I reached).  That said, the remarks
in the "IESG" section may be of interest to the authors, if they
indicate changes that could be made to the document that might result in
a different conflict-review response from the IESG.  Please note that in
preparing the IESG conflict-review response, I am tasked only with
determining whether IETF process is being followed, and am not tasked
with assessing the quality or content of the document in other ways.
However, because I had to read the draft in question in order to decide
what conflict-review response to propose, I also include (under the
"COMMENT" heading) some remarks about the document itself; these
comments are directed at the authors and ISE, but have no formal
standing.  They are safe to ignore, and whether/how to act (or not act)
on them is a matter for the ISE and authors to determine; I will only
participate in further discussion if explicitly asked to do so.

[Though the above paragraph reads like it should be standard
boilerplate, I actually wrote it from scratch just now.  Please let me
know if any parts are confusing and could be improved for future use.]

IESG

The cipher suite definition in Section 4.1 attempts to place
restrictions on what TLS compression method can be used with these
ciphers ("MUST be 'null'" is the phrase in question).  While TLS
compression is now considered to be a bad idea, was removed in TLS 1.3,
etc., TLS 1.2 itself does not admit the possibility for a cipher suite
to restrict what compression methods it can be used with.  Attempting to
make the non-use of TLS compression a requirement of the cipher suite
breaks a protocol abstraction of TLS.  (It would not be a problem,
however, to note that the same authorities that require the use of a
GOST cipher suite also require the non-use of TLS compression, as a
non-normative statement.)  The actual protocol mechanisms described in
the document seem to be compatible with the generic TLS abstraction,
since references are made to TLSCompressed as opposed to TLSPlaintext.

Similarly, the discussion of the CertificateRequest handshake message in
Section 4.2.3 attempts to limit the values sent for
supported_signature_algorithms and certificate_types when these cipher
suites are used, which is attempting to redefine core TLS protocol
semantics.

My understanding is that the situation here is similar to the situation
relating to the Chinese ciphers using SM2/SM3/SM4; RFC 8998 takes the
approach of defining both a set of cipher suites and a profile of TLS
suitable for use in the Chinese regulartory regime.  The cipher suites
themselves "plug and play" nicely with the core TLS machinery, and the
additional limitations on what algorithms may be combined with each
other are part of the TLS profile.  I suggest that a similar approach
would be appropriate here.

Additionally, the IANA considerations attempt to allocate values from
the TLS SignatureAlgorithm registry that have been marked as Reserved by
the standards-track document RFC 8447.  Any (re)allocation of such values
must be done in another standards-track document.  These particular
allocations seem more appropriate for the new TLS SignatureScheme
registry.

COMMENT

What is to happen to the IANA ciphersuite registrations for ciphers that
are allocated and list this draft as their reference, but do not appear
in this draft?:

0xC1,0x03      TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L      N N      [draft-smyshlyaev-tls13-gost-suites]
0xC1,0x04      TLS_GOSTR341112_256_WITH_MAGMA_MGM_L    N      N [draft-smyshlyaev-tls13-gost-suites]
0xC1,0x05      TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S      N N      [draft-smyshlyaev-tls13-gost-suites]
0xC1,0x06      TLS_GOSTR341112_256_WITH_MAGMA_MGM_S    N      N [draft-smyshlyaev-tls13-gost-suites]

Section 3

  i & j  bitwise AND of integers i and j;

bitwise AND of negative integers requires knowledge of the
representation convention (e.g., twos-complement).  Perhaps there is a
presumption that all integers in question are unsigned?

  P_s    the point of order q_s that belongs to the same curve as Q_s;

Is there really only a single such point?  My understanding is that
nearly all elements of the (sub)group generated by P_s would have the
same order, for prime-order groups.  In such a case, I would guess that
referring to P_s as the distinguished/well-known generator would be more
accurate.

Section 4.1

  All of the cipher suites described in this document use the stream
  cipher (see Section 4.3.3) to protect records.  The TLSCiphertext
  structure for the CTR_OMAC and CNT_IMIT cipher suites is specified in
  accordance with the Standard Stream Cipher case (see Section 6.2.3.1
  of [RFC5246]):

While the use of the indicated RFC 5246 Standard Stream Cipher
abstraction is appropriate for many block cipher modes of operation
(such as the counter-based ones employed here), the referenced Section
4.3.3 does not seem to actually describe how the cipher mode of
operation is translated into functioning as a stream cipher, so as to
justify this statement.

Section 4.1.1, 4.1.2

I strongly recommend some explicit discussion of the interaction between
these ciphers and the encrypt-then-mac extension.  While the current
formulation claims to use the RFC 5246 GenericStreamCipher
representation (for which RFC 7366 says encrypt-then-mac should not be
negotiated), the actual operation does not actually reflect the
GenericStreamCipher format, since the MACValue_seqnum is covered by the
encryption operation.  (It also redefines the MAC() operation to use a
per-record key, so the RFC 7366 expressions are not directly
transferrable, either.)
[ed. I see that there is some mention of encrypt-then-mac down in
§4.2.1.  It might be useful here as well.]

Section 4.2

  The cipher suites specified in this document define the ClientHello,
  ServerHello, server Certificate, CertificateRequest,
  ClientKeyExchange, CertificateVerify and Finished handshake messages,
  that are described in further detail below.

At risk of excessive pedanticism, the cipher suite cannot "define" the
hello messages, since those are used to negotiate what cipher suite is
to be used.  The ClientHello message format is a protocol invariant, and
the ServerHello message format is defined by the protocol version in
use (invariant to what cipher suite is used).

Section 4.2.1

  o  The ClientHello.compression_methods field MUST contain exactly one
      byte, set to zero, which corresponds to the "null" compression
      method.

(As mentioned above, this is not in the remit for a cipher suites to
mandate.)

  o  The ClientHello.extensions field MUST contain the
      signature_algorithms extension (see [RFC5246]).

      If the negotiated cipher suite is one of CTR_OMAC/CTR_IMIT and the
      client implementation does not support generating the
      signature_algorithms extension with the values defined in
      Section 5, the server MUST either abort the connection or ignore
      this extension and behave as if the client had sent the
      signature_algorithms extension with the values {8, 64} and {8,
      65}.

This setup seems a little confused.  First off, the first "MUST" isn't
really a MUST, since you go on to specify that a handshake can succeed
without such an extension.  (It's also rather unusual and surprising for
a cipher suite to require an extension to be included if the cipher
suite is advertised.)  Second, the server has no way of knowing that the
client implementation "does not support" generating the
signature_algorithms extension, just that the client ended up not
generating it this time around.  Saying that the server has to either
abort or use a default if the server negotiates the cipher and the
extension is missing is okay, though (but it would be even better to
remove the choice and say always abort or always assume the default).

  o  The ServerHello.compression_method field MUST contain exactly one
      byte, set to zero, which corresponds to the "null" compression
      method.

(same as above)

  o  The ServerHello.extensions field MUST NOT contain the
      encrypt_then_mac extension (see [RFC7366]).

Ah, this looks like something I had asked for in a previous comment.
Thank you!

Section 4.2.3

  o  the CertificateRequest.supported_signature_algorithm field MUST
      contain only signature/hash algorithm pairs with the values {8,
      64} or {0, 65} defined in Section 5;

Is the "{0,65}" a typo for "{8,65}"?  I'm not sure why the 256-bit
version of gostr34102012 would map up to the "intrinsic" hash but the
512-bit version use the "none" hash.
(Also, per the high-level comment, we really need to be treating these
pairs as coming from the TLS SignatureScheme registry, and not the
separate HashAlgorithm and SignatureAlgorithm registries.)

Section 4.2.4.1

  3.  Generates an export representation PSExp of the premaster secret
  PS using the KExp15 algorithm defined in Section 8.2.1:

(The steps listed here don't actually show the client computing the PS
value itself, just PSExp.)

  4.  Generates the ClientKeyExchange message using the
  GostKeyTransport structure that is defined as follows:



  GostKeyTransport ::= SEQUENCE {
      keyExp              OCTET STRING,
      ephemeralPublicKey  SubjectPublicKeyInfo,
      ukm                  OCTET STRING OPTIONAL

Do we care what ASN.1 encoding rules are used to encode the
GostKeyTransport structure for conveyance in the ClientKeyExchange?
(It's a little weird to use the same name for the TLS
presentation-language object and the ASN.1 object whose encoding it
contains; typically we would have the TLS presentation-language object
be defined as an opaque[length] and use the prose to specify what it
contains (and, in this case, that its length is determined by the
containing Handshake structure).

  where the keyExp field contains the PSExp value, the
  ephemeralPublicKey field contains the Q_eph value and the ukm field
  MUST be ignored by the server.

We would often say what the ukm contains (zero-length octet string?) in
addition to that the recipient ignores its contents.

Section 4.2.4.2

  In case of the CNT_IMIT cipher suite the body of the
  ClientKeyExchange message consists of a TLSGostKeyTransportBlob
  structure that is defined bellow.

We probably want to say something about what ASN.1 encoding rules are
used.

  3.  Generates an export representation PSExp of the premaster secret
  PS using the KExp28147 algorithm defined in Section 8.2.2:

As above, the actual value of PS used by the client does not seem to be
specified.

Section 4.3.2

  The CNT_IMIT cipher suite uses the message authentication code
  function gostIMIT28147 defined in Section 8.4 with the initialization
  vector IV = IV0, where IV0 in B_8 is a string of all zeros, with the
  CryptoPro Key Meshing algorithm defined in [RFC4357].  The resulting
  MAC length is 4 bytes and the MAC key length is 32 bytes.

A 32-bit MAC seems short enough to merit particular mention, whether
here or in the security considerations section.

Section 4.3.3

As alluded to by an earlier comment, I suggest mentioning here that the
use of a counter mode makes the cipher effectively function as a stream
cipher, so the TLS GenericStreamCipher case is (almost) applicable.
(The "almost" refers to the MAC being encrypted.  In theory one could
make the encryption part of the definition of the MAC operation and have
the formalism line up, but that seems like it would be very painful to
write up accurately, and is almost certainly not worth the effort.  At
most I would add some hedging language up where we talk about
GenericStreamCipher to clarify that though it's technically not correct
in practice it is fine.)

Section 5

My comments here are closely intertwined with the issues surrounding the
IANA registrations.  I would suggest an approach that starts off
something like this:

> TLS 1.3 [RFC8446] has redefined the SignatureAndHashAlgorithm
> structure to convey elements of type "SignatureScheme" that are
> two-byte values taken from a new IANA registry.  This change was made
> in a manner compatible with TLS 1.2 at the time of publication, by
> allocating values that correspond to the signature and hash pairs that
> were defined in the IANA registries for SignatureAlgorithm and
> HashAlgorithm at that time.  This document specifies new cipher suites
> for TLS 1.2 and is thus constrianed to using the TLS 1.2 terminology,
> with separate HashAlgorithm and SignatureAlgorithm components.
> However, the SignatureAlgorithm values shown here are not actually
> allocated in the IANA registry for SignatureAlgorithms, and are only
> defined when used in combination with the HashAlgorithm 0x08
> ("intrinsic").  Implementations [SHOULD/MUST] check for the use of these
> signature algorithm values with other HashAlgorithm values and abort
> the handshake if such usage is detected.

Section 7

It's a little surprising to have different ClientCertificateType values
just for the length of the signature key.  We don't do that, for
example, for rsa_sign or ecdsa_sign.  That said, the identifiers are
already allocated, so there may not be much value in trying to
consolidate and reclaim one.

Section 8.2.1

  The keys K_Exp_MAC and K_Exp_ENC MUST be independent.  For every pair
  of keys (K_Exp_ENC, K_Exp_MAC) the IV values MUST be unique.  For the
  import of key K with the KImp15 algorithm every IV value MUST be sent
  with the export key representation or be a preshared value.

Hmm, it seems that we use an IV extracted from H(c_r|s_r), which is not
exactly preshared or sent with the export key representation.

Section 10

  Note that prior to the existence of this document implementations
  could use only the values from the Private Use space in order to use
  the GOST-based algorithms.  So some old implementations can still use
  the old value {0x00, 0x81} instead of the {0xC1, 0x02} value to
  indicate the TLS_GOSTR341112_256_WITH_28147_CNT_IMIT cipher suite;

The "old value" {0x00, 0x81} is not in the private-use range for cipher
suites; was {0xff, 0x81} intended?

  Client should be prepared to handle any of them correctly if
  corresponding group is included in the supported_groups extension
  (see [RFC8422] and [RFC7919]).

I'm not entirely sure that I'm interpreting this correctly -- the
GC256[BCD] groups are defined in Table 2 and have IANA-allocated
codepoints.  Is this saying that if I receive one of those group
codepoints, I might receive points that actually correspond to the
groups listed in Table 8, as opposed to the "real" groups that are
listed in table 2?  I don't see these parameter set (OID names) listed
in either of RFCs 7836 or 4357; are they available somewhere that can be
referenced?  (Even a Russian-language reference seems preferable to no
reference at all, in this case.)

Section 11

Typically we would note here that the use of a static DH key/cert by the
server means that these ciphers do not provide forward secrecy.

Appendix A

[I did not attempt to validate the examples, but thank you very much for
including them!]