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

From: "Dan Harkins" <[email-masked]>
Date: Sat, 2 Jan 2016 10:21:43 -0800 (PST)

On Fri, December 11, 2015 3:29 am, Tero Kivinen wrote:
[snip]
> 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.

  Trying to administratively force people to do things they
have no technical reason to do makes the IETF look impotent
and kind of petty.

  If you want someone to use protocol BAR instead of protocol FOO
then BAR should offer some compelling reason to change. A decree
by the mandarins of the IETF is not compelling, as reality continues
to demonstrate.

  best regards,

  Dan.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Jan 2016 21:20:31 -0500

On 12/10/2015 09:31 AM, Tero Kivinen wrote:
> Stephen Farrell writes:
>> 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.
> 
> 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... 

What Tero said.

I hadn't even seen this until now. I think it sets a bad precedent to allow IKE modifications against the working group's policies. One of those policies is "no
more IKEv1 updates".

I'm fine with an IKEv2 document being submitted to IPsecME for these new algorithms.

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Jan 2016 10:10:03 +0000

I guess I should've looped back on this before.

TL;DR: it's ok, or tell Nevil if you disagree

On 20/01/16 02:20, Paul Wouters wrote:
>> 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?
>> 
> I hadn't even seen this until now. I think it sets a bad precedent to
> allow IKE modifications against the working group's policies. One of
> those policies is "no more IKEv1 updates".
> 

Right. The IESG did return a please-don't-publish 5742 result to
the ISE on the basis of the IKEv1 text. The authors were fine with
fixing that, so they removed all the IKEv1 stuff. At that point
the IESG were ok with the document from a 5742 conflict-review
perspective. The authors did not accept all of Tero's comments but
if you think that needs more work, then the thing to do is to
send mail to the ISE (cc'd here) about the latest revision which
is not yet an RFC. (You'd have to ask Nevil where it is in his
publication queue.)

Cheers,
S.