Re: Last Call: Recognising RFC1984 as a BCP

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'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.

--
Michael Richardson <mcr+IETF(_at_)sandelman(_dot_)ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

signature.asc
Description: PGP signature