Integrity protection for RFCs (was Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Dir review of) draft-ietf-json-text-sequence-09)

[Nico Williams <[e-mail]>]

On Sat, Dec 06, 2014 at 11:37:45PM +0000, Dave Cridland wrote:
> On 6 December 2014 at 22:49, <[e-mail]> wrote:
> > Security pedants might wonder why there is no easy way to authenticate
> > electronic copies of RFCs, given the vast array of security-related
> > protocols that the IETF has defined. How can I check the integrity of an
> > RFC document and that it hasn't been tampered with? I imagine an MD5sum
> > just won't do.
> 
> All the copies I'm reading are properly signed, according to RFC 4637. If
> yours aren't, maybe they *have* been tampered with.

Maybe each RFC should be like a commit in any modern version control
system, complete with a commit hash binding all past RFCs into each new
RFC.

Of course, that would really bind us to having canonical RFC
representations, and/or new renderings by the RFC-Editor added as
"commits".

Then we could reference RFCs as RFC-af551e0 (short-form) and
RFC-af551e089ca623216a312e475a6837de0aa7995b (long-form) and so on :) in
mailing list discussion, verbally, in RFCs as rendered, in other
documents, ..., and by doing so we'd be embedding the commit hashes of
the entire RFC series deeply into the Internet, in a way that would be
quite difficult to tamper with.

No digital signatures needed, just a decent hash function.

Or at least that's what I think Lloyd was suggesting.

I leave it to others to make a serious proposal along these lines.

(We can't quite adopt a VCS for this: we'd have to standardize it.)

Nico
--