Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.)

[Christopher Morrow <[e-mail]>]

On Fri, Jul 19, 2019 at 4:13 PM Nico Williams <[e-mail]> wrote:
>
> On Fri, Jul 19, 2019 at 03:50:14PM -0400, Christopher Morrow wrote:
> > This, 'publish between an rfc and ID' is, I think, what the
> > living-documents/evolving-documents work was supposed to enable.
> > I was going to dither with John's suggestion of 7525 as an example,
> > mostly because TLS tends to get people's hackles up :) but.. actually,
> > because of things like:
> >   https://tools.ietf.org/html/rfc7525#page-11
> >
> > this is a great example actually. The advice to set cipher suites and
> > other options for TLS has been changing quite a bit of late, having a
> > consistent location that's not 'rando website cipherl.st ?' seems like
> > a great plan, to me. If that location is able to keep up in close to
> > real time with all the various 'heartbleed' type problems so  much the
> > better. We should be making this simpler and easier to locate and
> > digest, right? and up-to-date to the best of our ability?
>
> Good point.  Not only that, but the notion of "cryptographic strength"
> of various cipher/digest/MAC algorithms and ciphersuites, public key
> algorithms and protocols, PRFs, and other functions, vary over time as
> cryptanalysis advances.  A registry of current perceived cryptographic
> strength, subject to significantly less strenuous review than Standards
> Action, would be useful.  Perhaps we could make this an IANA registry,
> though that seems a bit of a stretch.

I think a registry doesn't really get to the point though.. I can
imagine the example here is really a few documents:
  o  cipher/algorithm/key-size/etc advice (which is mostly 7525's aim)
  o documents for common IETF server/client focused things:
        webserver config advice
        mailserver advice
        ssh client/server advice
        ....
  o advice on how often to rotate keys used in securing basic plumbing
infrastructure (dns, bgp, tacacs+ etc)

Having all of these have to spin up multi-month long processes in the
IETF to get errata + rfc + ... is going to be less useful.
Having these managed at a faster pace based on advice from experts
(from the ietf even!  :) ) seems like  good compromise...

-chris