On Mon, 10 Aug 2015, Michael Richardson wrote:
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 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