Re: [saag] AD review of draft-iab-crypto-alg-agility-06

[Viktor Dukhovni <[e-mail]>]

On Sat, Jul 18, 2015 at 10:30:19AM +0200, Kathleen Moriarty wrote:

> > 2.9: I'm not really a fan of blessing weaker algs for OS, but I lost
> > that argument before. I wonder if we would get consensus if this
> > said that weak algs are better than no encryption but still MUST be
> > deprecated as soon as feasible?
> 
> I don't think we've really debated this enough to get consensus.  I don't
> think weaker algs fit into our agreed definitions for OS.  I just recall
> your debate with Pete on another draft, but think a wider debate is needed
> to see what the consensus is.  I don't think weaker algorithms should fit
> into the definition.

What fits into OS is due consideration of interoperability constraints.
When clear text is sufficient, encryption is "desirable" and
authentication is "icing on the cake", it is a shame to resort to
cleartext, (or hard fail and ultimately lead the user to abandon
OS as too much pain for too little gain) just because encryption
might involve the use of tarnished algorithms.

What that all boils down to, is that with existing application
protocols, that are already doing OS (be it by another name), one
should be willing to tolerate tarnished algorithms that are "the
best" that some non-trivial fraction of peers can support at any
given time.

No tarnished algorithm needed for interop should be kept on
life-support in perpetuity.  The expectation is that over time
(somewhat lagging similar changes in mandatory security protocols)
tarnished algorithms also disappear from opportunistic protocols.

For example, opportunistic TLS in Postfix (by default) no longer 
includes support for "export" ciphers, SSLv2, SSLv3 or 1DES.

If and when OS is introduced in new applications or protocols, with
no legacy installed base setting interoperability constraints, no
tarnished algorithms should be accepted.  New protocols should,
if possible, start with a clean slate.  That is, from inception
start by satisfying as many as possible of:

	TLS 1.2 or higher (of course no SSLv2/SSLv3)
	No "export" ciphers
	No 1DES, RC4, IDEA, RC2, ...
	No MD5 or SHA1,
	...

Then as the protocol ages, and more things are deprecated,
interoperability constraints may at a later date mean that
newly tarnished crypto is kept around longer with OS than
otherwise, but only long enough to allow for an orderly
phasing out of the algorithm to the point where negligibly
few peers require continued support.

-- 
	Viktor.