Subject: [saag] another conflict review of some GOST stuff

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Dec 2015 01:16:31 +0000

Hiya,

On Dec17, the IESG will also be doing the conflict review for a
draft [1] that documents some more about using GOST algorithms.

Since we've typically handled national algorithms in this manner
(basic alg details are documented as independent submission
stream RFCs) I think this one does not represent a conflict with
ongoing IETF work or process. But if I'm wrong, please do let me
know.

Should someone want code points for using these algorithms in IETF
protocols, that'd of course go through the normal consensus process.
See RFC 5742 [2] for details of what this bit of process is about.

If you have comments on the draft content then please send those
to the authors and cc the independent submissions editor, Nevil
Brownlee ([email-masked]).

Cheers,
S.

[1] https://datatracker.ietf.org/doc/draft-smyshlyaev-gost-usage/
[2] https://tools.ietf.org/html/rfc5742

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 10 Dec 2015 16:31:52 +0200

> ongoing IETF work or process. But if I'm wrong, please do let me

I wonder why this draft do specify PRFs for TLS, IKEv1 and IKEv2? It
does not allocate any IANA numbers for them, so there is no way of
using them, so why include those sections in this draft at all. I
think it would be better to have those in the draft that allocates the
numbers which allows these to be used?

Also specifying anything for the obsoleted IKEv1 protocol is bad
idea... 

-- 
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Dec 2015 14:38:00 +0000

> numbers which allows these to be used?

I agree, but figured that wasn't a sufficient deal to consider it
a reason for the IESG to ask the ISE to not publish.

> Also specifying anything for the obsoleted IKEv1 protocol is bad

Also true.

If folks think having additional stuff defined for OBSOLETEd protocols
like IKEv1 is so bad an idea that we ought ask the ISE to not do that,
please say so. I'm sure we'd push back on that if someone wanted to
do it via an IETF stream document (though I think I vaguely recall
that we may have done exactly that - anyone remember?)

Ta,
S.

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 10 Dec 2015 10:34:24 -0500

On Thu, Dec 10, 2015 at 9:38 AM, Stephen Farrell
<[email-masked]> wrote:
>> ...

I believe you are talking about the case where algorithms were added
for "IKEv1" because the IKEv1 table of algorithms was being used by
another protocol that is part of IEEE 802.11.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Dec 2015 15:36:17 +0000

> another protocol that is part of IEEE 802.11.

That's the one, thanks Donald.

S.

---

From: Dmitry Belyavsky <[email-masked]>
Date: Fri, 11 Dec 2015 09:24:26 +0300

Dear Tero,

> Also specifying anything for the obsoleted IKEv1 protocol is bad

The draft [1] describes the current usage of the Russian GOST message
digest and signature algorithms.
As the algorithms themselves were described in RFCs [2], [3], we now need
to specify some details describing how to use them.

The draft does not specify any locally invented non-standard constructions
but uses the standard ones for HMAC, PRFs and KDFs.

Also, there seems to be no IANA registry at least for PRFs for TLS [4]

[1] https://tools.ietf.org/html/draft-smyshlyaev-gost-usage-17
[2] https://tools.ietf.org/html/rfc6986
[3] https://tools.ietf.org/html/rfc7091
[4] http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

Thank you!

-- 
SY, Dmitry Belyavsky

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 11 Dec 2015 13:29:58 +0200

Dmitry Belyavsky writes:
> The draft [1] describes the current usage of the Russian GOST
> message digest and signature algorithms. 

That draft is not enough to specify how them are used in the
interoperable manner, as it does not allocate IANA numbers for them.
Of course if you have some other document specifying how to use
private use numbers for those algorithms then you could use those
algorithms, but then I think it would be better to move sections
4.2.2 to that document. 

> As the algorithms themselves were described in RFCs [2], [3], we now
> need to specify some details describing how to use them.

So if the algorithms are already specified in earlier RFCs, this
document tries to specify how to use them, but does not do that as it
does not even try to do IANA allocations, I do fail to see the meaning
of this document.

I.e. is this document trying to make GOST so that it can be used in
the IPsec or not. If yes, are you expecting to do IANA allocations
based on this document later, or what?

> The draft does not specify any locally invented non-standard
> constructions but uses the standard ones for HMAC, PRFs and KDFs.
> 

I am mostly concerned about the IPsec, not TLS, as I happen to be IANA
expert for reviewing the IKEv2 assignments.

>From that point of view the IKEv2 section of the draft (4.2.2.2) is
not enough. The section 4.2.2.2 says that for this document specifies
HMAC_GOST3411_2012_256 and HMAC_GOST3411_2012_512 for PRFs for IKEv2,
but this document does not specify those at all. There is
HMAC_GOSTR3411_2012_256 and HMAC_GOSTR3411_2012_512, but I am not sure
whether they are actually same (GOST vs GOSTR), i.e. is this just typo
on one of those sections or something else?

The section 4.1.1 defining HMAC_GOSTR3411_2012_256 says that it "uses
H_256 as a hash function for HMAC", but does not specify what H_256
actually means. I assume it means n = 256 bits hash function from the
RFC6986, but that is not exactly clear.

Anyways if you ever plan to do IANA allocations for IKEv2 that might
mean that the information in this document is not enough, thus you
might still need to make yet another draft to provide the missing
details (I have not reviewed the draft yet to see what else is
missing except those things I found with just quick check).

Also text in this document only covers using those GOST as PRF, there
is not enough specification to use them as AUTH algorithm, or to use
the digital signatures in the IKEv2 authentication.

--

As for the IKEv1, we had long discussion [1] on the ipsec list when we
had this issue with brainpool IKEv1 curves, and they were added to the
IKEv1 registry with note saying "Not for RFC 2409." [2] meaning they
are not for the IPsec use. They are only there for the 802.11 use.

There was strong objections in the discussion for adding any new
algorithms for IKEv1 use, so specifying how this is used in the IKEv1
does not really help, as there will be strong objections for getting
IANA numbers for IKEv1 use.

[1] https://www.ietf.org/mail-archive/web/ipsec/current/msg07925.html
    Start of discussion thread

[2] https://www.ietf.org/mail-archive/web/ipsec/current/msg08216.html
    Summary from the WG
-- 
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 11 Dec 2015 13:06:36 +0000

Yes, Tero's correct, and I'd forgotten about that, sorry. I
think there was then a consensus to not define new things for
IKEv1 and the IEEE stuff was considered very much an exception.

I think the least that requires is that the IESG return a
5742 result to the ISE saying that this extends an IETF protocol
in a way that requires IETF consideration. Regardless of
whether or not we think doing what's asked is ok, and regardless
of whether or not the IEEE case sets a precedent, I think it's
correct that the IETF and not ISE should get to decide whether
or not to extend an OBSOLETEd protocol via a last call.

I have changed the ballot thusly. [1]

And sorry again for not spotting this before,
Cheers,
S.

[1] https://datatracker.ietf.org/doc/conflict-review-smyshlyaev-gost-usage/

---

From: Paul Lambert <[email-masked]>
Date: Fri, 11 Dec 2015 18:17:41 +0000

>IKEv1 and the IEEE stuff was considered very much an exception.

The IEEE stuff has one mechanism (SAE) that references IKEv1 with text in
less than a dozen locations of the total 3,701 pages.  Primary text is:

	

	Groups are negotiated using an identifying number from a repository
	maintained by IANA as ³Group Description² attributes for IETF
	RFC 2409 (IKE) [B17][B29]. The repository maps an identifying
	number to a complete set of domain parameters for the particular
	group. For the purpose of interoperability, a conformant STA
	shall support group nineteen (19), an ECC group defined
	over a 256-bit prime order field.

If there was a better reference for "group nineteen², the IEEE
specification could be changed if this would help in this process.

Paul
>[1] 
>https://datatracker.ietf.org/doc/conflict-review-smyshlyaev-gost-usage/
>
>_______________________________________________
>saag mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/saag

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 22 Dec 2015 16:43:37 -0500

I did actually come up with a use case for these:

Encrypt data under AES, Encrypt the result under GOST using a different key.

The chance that the NSA and GRU would cooperate to share their NOBUS
keys is very small.