Re: [Cfrg] RFC 5742 conflict review for draft-dolmatov-kuznyechik

[Simon Josefsson <[e-mail]>]

mån 2016-02-01 klockan 16:33 +0000 skrev Stephen Farrell:
> Hi Simon,
> 
> On the higher level, I agree with those who think this is
> not a 5742 conflict, but I'll point the rest of the IESG
> at this thread so they can read about it themselves.

Hi Stephen, IESG (bcc'd),

If you and others disagree on there being a conflict (something I would
consider being on the wrong side of of balance between practalities and
security), please consider below a suggestion to add text to the
document to somewhat mitigate the consequences of that decision.

> On 01/02/16 16:27, Simon Josefsson wrote:
> > "Valery Smyslov" <[e-mail]> writes:
> > 
> >>> Also consider that AES isn't an RFC: the disadvantage of that does not
> >>> seem to be stopping us from using it.
> >>
> >> Situation with AES is different - it is documented in English.
> >> Camellia is a better example - and it was published (RFC 3713).
> >> Do you think that many people have implemented it since then
> >> without understanding the consequences?
> > 
> > Yes.  I think Camellia is a good example here.  I recall seeing
> > implementations that preferred Camellia over AES when both were
> > available, which I suspect was due to misunderstanding or mistake.  The
> > document can inform the reader about some aspects, but sometimes having
> > too much rope available causes bad things to happen.
> 
> I agree that that happened and was undesirable, but I think
> that the mistake then was in the TLS code point allocation.

I don't believe that is the only reason  People use RFCs outside of IETF
protocol context too.  I recall seeing Camellia used in non-IETF
protocols too, with unclear rationale.

> We (the IETF) should've made sure that the registry or the
> specification that created the code points clarified things
> for implementers. With TLS1.3, I think the TLS WG have
> decided to structure the IANA registries so this'll end up
> better. I forget if that'd also mean re-structuring the
> registries for earlier TLS versions or not, but in any case
> the issue is one for the TLS WG (or IPSECME or whoever) and
> not something that the ISE ought handle in the basic spec
> describing the algorithm details.

I believe a discussion of IETF's thoughts on the suitability of a crypto
algorithm ought to be in the crypto specification itself when there are
concerns about the Internet-wide applicability of the algorithm.  This
is for the following reasons:

1) The IETF ought to recognize the best interest and safety of Internet
users as a collective.  I encourage you all to re-read the IETF's
mission statement and consider again whether publishing GOST, with or
without sufficient security considerations, are consistent with that.
https://ietf.org/about/mission.html

2) People use RFCs for non-IETF purposes, especially crypto algorithms.
Consider the number of places HMAC-SHA1 or PBKDF#2 are used.

3) The IETF does not distinguish between different crypto algorithms it
publishes -- they are all informational -- so it is not easy to
understand that Camellia is not a generally recommended cipher these
days.  Especially since there is no RFC on AES which is what I believe
we historically have been encouraging.  Having a discussion in the
document itself is probably the only place the IETF can inform the
reader about what it believes the intended use for the algorithm is.

Thus I suggest that the IESG 1) consider whether they believe publishing
this is consistent with the goal's of the IETF (I believe it conflicts
with the IETF's mission), and 2) propose to add text to the document
explaining that the IETF does not encourage nor recommend the algorithm
for general purpose Internet-wide use.

/Simon