Re: [saag] Possible backdoor in RFC 5114

> I have no idea why we would want to mark the document as historic, or obsolete it, especially as it does define things that are in use (ECP groups).
> It does not give any recommendations for using those groups, for example in IPsec we do have separate documents which gives those recommendations and for the 256-bit ECP we are saying SHOULD, and for the MODP groups defined in the 5114 we are saying SHOULD NOT.
> That is much better way to define the recommendations and how those groups should or should not be used.

Agreed. The ECP groups are widely used in IKE. "Historifying" will not add value especially before a 25519 group is defined.
Panos

-----Original Message-----
From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Tero Kivinen
Sent: Friday, October 07, 2016 10:00 AM
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: saag@ietf.org
Subject: Re: [saag] Possible backdoor in RFC 5114

Stephen Farrell writes:
> 
> So I'm not seeing anyone so far argue to not deprecate these somehow.
> 
> We could just make 5114 historic as Yoav suggests, or, if someone 
> writes an I-D to explain why, we could obsolete 5114. (Such an I-D 
> would presumably also say something about codepoints that point at
> 5114 from other registries.)
> 
> Assuming nobody shows up saying these are in fact in widespread use 
> I'd be supportive of us getting rid of cruft.

I think the NIST ECP groups are quite widely supported, and used.
RFC5114 includes both Nist ECP Groups (192, 224, 256, 384 and 521) and
3 MODP groups.

In IPsec, ECP groups are widely used, those MODP groups with subgroup are not. On the other hand I think only those 192, 256 and 521 bit groups are really used, and those are defined also in RFC5903 (which obsoleted original 4753 which had serious bug in it).

> So, someone wanna volunteer to write an I-D that'd obsolete 5114? If 
> so, say so here.

Or parts of it or something. 

> Or, if you want me to start the "mark it historic"
> process (which doesn't need an I-D), please say so here. (Note that 
> even though this doesn't need an I-D the status-change does get an 
> IETF last
> call.)

Marking NIST ECP groups as historic might be preferrable for some people, but it might be good idea to wait before we have curve25519 etc published as rfc for all protocols that 5114 covers before we go that far. In IPsec the curve25519 etc are now in the IESG, I do not know what is the status for other protocls (X.509, TLS, SSH, SMIME). 

> Or, if you wanna argue that none of the above are right, then please 
> do that.

I have no idea why we would want to mark the document as historic, or obsolete it, especially as it does define things that are in use (ECP groups).

It does not give any recommendations for using those groups, for example in IPsec we do have separate documents which gives those recommendations and for the 256-bit ECP we are saying SHOULD, and for the MODP groups defined in the 5114 we are saying SHOULD NOT.

That is much better way to define the recommendations and how those groups should or should not be used.
--
kivinen@iki.fi

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag