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

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!]