Roy T. Fielding <fielding@xxxxxxxx> 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@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =-
Attachment:
signature.asc
Description: PGP signature