On Mon, May 22, 2017 at 08:57:30PM -0400, Dave Garrett wrote:
> On Monday, May 22, 2017 08:29:13 pm Viktor Dukhovni wrote:
> > Setting a collision-resistance floor rather than naming some list
> > of algorithms makes more sense to me, but if the WG really feels
> > that naming some "verbotten" algorithms is better, so be it.
>
> My preference would be to do both. Call out the ones we have
> codepoints for by name (MD5/SHA1/SHA224), then have a general
> collision-resistance floor value for everything else.
Sure.
In general I prefer setting floors, as Viktor says. That's because
listing all forbidden algorithms is easy to flub up, and because it's
much easier from an API point of view to specify security levels than to
go listing things that are allowed/forbidden.
I think we should have standard algorithm security profile names that
can be used in multiple protocols. E.g.,
- weak (obsolete weak algorithms allowed)
- interim (certain obsolete weak algorithms allowed during migrations)
- default (default security floors, no obsolete weak algorithms allowed)
- stronger (like standard but with higher security floors)
- <URN?> (local/custom security level, perhaps specified
additively from standard security levels)
The meaning of each of these would be updated over time by updating the
RFCs for the relevant protocols. Thus configurations would not have to
change.
Specifying such a security level to TLS would have it apply that level
to its ciphersuite, PRF, key agreement, PSK, and signature algorithms,
and pass it to PKIX when using PKIX.
Specifying such a security level to PKIX would have it apply that level
to certificate public key and certificate signature algorithms, as well
as to path construction and validation.
Specifying such a security level to Kerberos, SSHv2, ... would ...
And so on.
This would make security level configuration much easier in the common
case. And would avoid periodically having to update configurations to
adjust for recent cryptanalysis advances: just update the meanings of
these standard security levels and update software.
Nico
--
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
