ietf
[Top] [All Lists]

Re: Last Call: Recognising RFC1984 as a BCP

2015-08-11 07:24:18
On Mon, 10 Aug 2015, Michael Richardson wrote:


Roy T. Fielding <fielding(_at_)gbiv(_dot_)com> wrote:
   > Umm, the document is specifically worded as a position statement from
   > the IAB and IESG.  There is no "current practice" described by it.
   > Rather, it is an argument against key escrow and limited key sizes; a
   > sort of anti-pattern for an old practice.

1) I think that the goal here is that RFC1984 permitted WG to
  make things like KEY ESCROW, weaker keys, etc. as out of scope.
  But 1984 didn't actually say that; it just provided the background
  by which to argue (or rather, conclude the argument quickly) the point.
  So I agree with the letter of Roy's argument.

2) I think that the BCP that we are trying to describe is that
  the IETF doesn't design back doors into protocols.

  I agree that RFC1984 doesn't actually say that.

Having said this, I support an effort to re-inforce or re-recognize 1984
as still relevant.  If marking it as BCP, and therefore giving it a BCP#
makes sense, I'm for it.  As BCP# can refer to multiple documents, we could
then write a short BCP that captures point (1) above, and it could be added.
I don't want to re-open 1984... we'll wind up boiling an ocean.

I agree. I think it is important that we re-inforce RFC 1984. So I am in
favour of turning the existing document into a BCP.

   > I'd rather it be left as an informational document, as it was approved,
   > and a new BCP be produced that explains current best practices
   > regarding minimum key sizes, currently-safe algorithms, etc.  Something
   > that isn't tied to a specific protocol (unlike TLS 1.3).

Such a document has been produced by the IPsec(ME) WG on an irregular
basis. For instance: http://datatracker.ietf.org/doc/rfc7321/
which obsoleted http://datatracker.ietf.org/doc/rfc4835/

And really, one must do this on a (security) protocol-by-protocol basis.
I think that TLS has updated this in the main protocol document.

But such documents are very hard to write. Even within the IPsec
community, the various updates on which crypto related options to
obsolete and which to recommend end up in a very strange combination of
consensus. I would actually prefer to see a stand-alone document that
tries to extract all the cross-protocol crypto options into one set of
recommendations, so that these are not ending up with different
consensus calls within different working groups. For example, we should
have a crypto recommendation about SHA1, HMAC-SHA1 and even things like
PFS and only leave protocol specific things (eg AH vs ESP-NULL) into the
respective working groups.

Paul