Subject: [saag] Proposal to Consolidate Algorithms Registries

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Nov 2011 12:16:59 -0500

This issue keeps coming up. I think that events are converging in a way
that forces us to finally do something.

At present the IETF has some tens of protocols that use cryptographic
algorithms. Some use one registry, others use another, some use no registry
at all, some use OIDs and so on. I see the following problems with the
current situation:

1) There is no established process for telling people 'do not use 512 bit
RSA keys with any IETF protocol.'

We have recently had some issues arising from use of 512 bit certificates.
This is a problem that should never have occurred. Browser vendors and CAs
have both known of the security issues relating to 512 bits for a decade.
But we still managed to end up with breaches occurring because everyone was
waiting for someone else to take action.

Some party needs to take action here and say that they are going to decide
when to tell people to stop using obsolete crypto. The actual advice given
being much less important than the decision to take responsibility for
giving it.

Remember that using stronger cryptographic algorithms DOES NOT make you any
more secure. The only way to make yourself more secure is to STOP USING the
insecure ones. Phasing out MD4 and MD5 is much more important than
deploying support for the SHA-2 replacement.

2) There is no process for maintaining algorithms after a WG has closed.

At one point quite a few Security Area groups appeared to be kept going
more or less for the sole purpose of twiddling crypto algorithms. At the
moment the IETF has a process for setting minimum key lengths for PKIX
certs. But when PKIX closes the only mechanism will be a personal
submission to change a standard developed by the WG for over 15 years. That
seems to be a mismatch to me.

3) Duplication of effort.

What point is served by having the same conversation about which algorithms
to use in 10 different WGs? Modern machines are (mostly) pretty capable and
there are almost no cases where an individual WG need be making protocol
specific choices of algorithm to meet performance or space goals.

Back in 1995 we had to consider performance quite closely. 512 bit certs
actually made some sense at that point. We did not have AES. We were
dealing with the FBI and part of the NSA trying to prevent use of strong
crypto. Choice of algorithm was a much harder choice then and often had to
be fitted to the specific protocol.

Today there are still circumstances where performance constraints are
significant. For example, the low performance devices I work with in my
control systems work. But that means a choice between public key and
symmetric key rather than between standards based crypto and some purpose
built homebrew scheme. For most low performance devices, AES is now the
algorithm preferred over all others because it is available in hardware.

We are going to have to have a conversation about which algorithms we are
going to choose somewhere. At the moment we face the choice of either have
that conversation in Jose and then have it again in the next WG or have the
discussion at a Security Area level and re-use those choices in the future.

4) Inconsistency

Using two different crypto algorithms provides the strength of the weakest
one. Inconsistency is almost always worse than a sub-optimal choice. I
don't much care what the RSA signature format used is as long as it is
'good enough' for me and 'everyone' is using it.

We should make these choices once and have the consequences flow out to all
the protocols that use the algorithms.

There have been a few prior attempts to deploy a registry that would cover
more than one protocol. But to date there has been no registry that has
really done what is needed to unify all the registries into one place and
establish a unified process for change control.

5) 'Vanity' Crypto and other non-Mandatory algorithms.

Cryptography has always been a highly politicized technology. In recent
decades it has been as highly politicized as nuclear power and for much the
same reason: Cryptography was one of the principle technologies that
decided the outcome of WWII and was thus a key technology in the cold war.

The politics behind so-called vanity crypto are very complex and I don't
really want to go into them here. What I wat to do instead is to build a
firewall so that the IETF does not need to get dragged into those politics.

For historical reasons, the IETF preferred algorithms are essentially the
NSA/NIST choices. One approach would be for the IETF to only recognize
those and no others. This is probably not sustainable. Registries such as
IANA are only stable so long as they are willing to register code points on
a basis that is acceptable to the parties that need code points to be
defined. If IETF/IANA refuses to assign code points then the refused
parties will simply pick a code point and use it. This has occurred
repeatedly in other venues. That is why there is a hole blocked out in the
MAC address space, the storage providers wanted a globally unique address
and saw no reason to pay IEEE for the numbers. That is why barcodes are
structured as they are.

Another approach is simply first come first served. I do not like that
approach as it means that the IETF ends up 'endorsing' the use of broken
crypto. But it is arguably better for the IETF to have a policy that allows
for anyone to register in a way that ensures that a disclaimer is applied
than to try to weed out the bad ones and not do a good job of it.

One caveat that comes up is that some protocols have limited space for code
points. But this can almost certainly be dealt with by some form of
extension mechanism that allows use of a common code space (e.g. OIDs) for
non mandatory to implement algorithms.

Thus my proposal (which I will write up as an ID if people like the
approach).

IETF requests IANA create three new registries of cryptographic algorithms
as follows:

1) Registry of Cryptographic Algorithm Identifiers.

This would be a registry that is divided up into separate sub-registries
for various types of algorithm (public key signature, public key
encryption, digest, encryption, mac, suites, etc.)

The criteria for inclusion would be expert review and RFC required.

The RFC would start off with a pre-amble that states that the IETF makes no
endorsement of the strength of the cryptographic algorithm and the expert
review would be strictly limited to determining that the format of the
document is correct, the document would not be allowed to specify code
either. The purpose of these requirements being to prevent people from
presenting assignment of code points as an IETF endorsement of the
algorithm strength.

The document would be required to:

1) Specify the code points for ASN.1 OID, text string, URI and optionally
additional code points for IPSEC, DNSSEC, etc.
2) Specify test vectors in a format that ensures that endian-ness issues
are addressed.
3) Specify the location where further documentation is to be found (which
might be another RFC).

2) Registry of Mandatory to Implement Algorithms

This would be a subset of the algorithms specified in the first registry
and would normally consist of exactly one algorithm of each class.

Criteria for changes would be Standards Action required. Each RFC making
changes would specify the full list of required algorithms each time.

Specifying compliance with this would be separate from specifying
compliance with the base specification. So if a vendor was specifying
standards compliance for its Web server it would specify 'Complies with RFC
2616, RFC 5246 & RFC XXXX'

3) Registry of Deprecated Algorithms.

This is the registry of algorithms and key sizes that IETF warns against
using. The warning may be immediate or have some specific action date.

It would also be possible to state that an algorithm is deprecated for
specific purposes or with certain protocols. For example, MD5 should not be
used for any purpose that requires protection against collision attack.
There are certainly cases where use of MD5 does not raise a security issue,
though the cost of going through the necessary justification is almost
never going to be worthwhile unless there is a major legacy deployment
issue.

Criteria for changes would be Standards Action required. This would also be
cumulative.

To be in compliance with this specification, applications MUST NOT permit
the use of those algorithms (even if the user requests them).

So to specify compliance, a product would state 'Complies with RFC 2616,
RFC 5246, RFC XXXX & RFC YYYY'

The task of ongoing maintenance would be left to the IETF SAAG and SECDIR.
Actually making these decisions is much less difficult than deciding on
having one place to make them.

Although the bar is set at 'standards action required', this would normally
be something I would see being done on an individual submission basis
rather than requiring a Working Group to be formed.

-- 
Website: http://hallambaker.com/

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 Nov 2011 12:06:09 -0600

> 2) There is no process for maintaining algorithms after a WG has closed.

Sure there is!  It's whatever process that WG's core documents outline
for registration, else the IETF process (individual submissions, find
another suitable WG, start a new WG)

> specific choices of algorithm to meet performance or space goals.

But different WGs will have different perspectives on certain matters.
 Should Camellia be specified for TLS, Kerberos, SSH, ...?  Should it
be mandatory-to-implement?  If not, should it be published on the
Informational track, or the Standards Track?

Answers to these sorts of questions are allowed to vary by WG right
now.  Perhaps that is a problem, but if not, do we want to lose
whatever value we get from being able to answer those questions on a
WG-by-WG basis?

And if you propose that things like "mandatory-to-implement" be
protocol-specific, but all in the same registration entry, should
registration be held up until we have consensus for each protocol, or
should registrations be updated lazily for each protocol?  (I would
hope the latter.)  Would we have a single list/WG for consensus, or
would we still need to do whatever is appropriate for each protocol
(e.g., use concluded WG lists)?

(I'm not nay-saying here.  These are questions to which I see
potentially satisfactory answers.)

It might make sense to limit this new registry to just a few protocols
(PKIX, TLS, CMS, leaving out Kerberos, SSH?), then add the remaining
protocols as we gain experience with the new registry.  But even so, I
think we want some idea of what the registry and registration process
will look like when we're done.

Also, it'd be nice if we always had an explicit sequence number in all
*new* cipher suites, even when a given protocol only requires an octet
stream, as TLS and SSH do.  DTLS obviously needs this, but it wouldn't
hurt SSH, and we really want to never again have modes like chained-IV
CBC.  This wouldn't be a big change for SSH as it already has this for
counter-mode ciphers, basically.  It wouldn't be much of a change for
GSS-API mechanisms either.  But this would be a much more disruptive
change for Kerberos.  Perhaps the thing to do would be to leave our
Kerberos...

The one thing we don't want is to make addition of crypto algorithms
so difficult that it takes years [more than now] or worse: never
happens.  This is the biggest scare factor for me regarding your
unified registry proposal.

> one. Inconsistency is almost always worse than a sub-optimal choice. I don't
> much care what the RSA signature format used is as long as it is 'good
> enough' for me and 'everyone' is using it.

The security of the whole is certainly affected by the strength of
individual algorithms, but the way in which the whole is put together
is critical as well.  SHA-1 may suck now, but HMAC-SHA-1 is still
considered secure enough.  That's one example.  The 'whole' consists
of key exchange, authentication, KDF/PRF, ciphers, cipher modes, and
integrity protection algorithms (except when an AE/AEAD cipher mode
takes care of the last), and the way in which these are all combined.

> the protocols that use the algorithms.

The 'whole' does vary significantly by protocol because, sadly, the
protocols themselves vary so much (or have protocol-specific details
that are difficult to abstract).  Thus I have a hard time imagining
that a shared registry will be enough to allow us to easily analyze
and/or ensure the security of our protocols, say.

I'm not saying that I don't want a unified theory of crypto protocol,
complete with unified algorithm registry.  Quite the contrary, I do.
I just think there's a lot of work to do to get there.  Again, maybe
if you start small?

Or perhaps start with an informative registry and see if we can
eventually get each protocol to switch to it as their normative
registry as we gain experience?

> same reason: Cryptography was one of the principle technologies that decided
> the outcome of WWII and was thus a key technology in the cold war.

Making vanity crypto decisions global to a set of protocols will
probably complicate the politics of selecting mandatory-to-implement
algorithms.  Or perhaps I'm wrong and implementors (and therefore, the
IETF) will throw in the towel and accept a large number of
mandatory-to-implement algorithms.  We probably can't tell without
trying.

However, though we have lots of deja vu moments today in each
protocol/WG, we do benefit from being able to make different MTI
decisions in each case (i.e., implementors for each protocol are only
affected by consensus for that protocol, not global consensus).

> NSA/NIST choices. One approach would be for the IETF to only recognize those
> and no others. This is probably not sustainable. Registries such as IANA are
> [...]

Our preferred algorithms are historical accidents, yes, but ultimately
they have to do with consensus and available choices at the time that
the choices had to be made.  I.e., we have a bit of an accidental
first-com-first-served policy, and that implicit policy has been
becoming much more of an explicit policy recently (it's convenient
that we can interpret the past this way, I know).  If we were to have
too many algorithms to choose from when we need to choose we'd simply
have more interesting discussions -- or are you saying we might then
fail to reach consensus?  But how would a single registry make it more
possible to reach consensus in such a situation??

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Nov 2011 16:09:00 -0500

> Informational track, or the Standards Track?

I do not think that is actually true.

In what circumstances would we want to endorse an algorithm for protocol A
knowing that it is not suitable for protocol B?

The IETF is in the standards business and one of the things that you do in
a standard is you decide what is not part of the standard. I cannot see any
argument for any of the following:

* Adding Camellia to the mandatory to implement suite for any IETF protocol
* Prohibiting use of Camellia for any protocol
* In general, adding an algorithm for use with protocol X knowing that it
is inappropriate for use in other protocols.

There is no shortage of cryptographic algorithms. I can't see why TLS
should even spend the time considering Camellia if there was any doubt
about the ability to use it in IPSEC. The only algorithms I can ever see
being worth consideration at this point would be ones that are sufficiently
general purpose that they can be used in multiple protocols.

What I am proposing instead is a low bar to making Camellia an option in
any IETF protocol. I believe this to be a Pareto improvement as follows:

* The developers of Camellia can get their algorithm enabled as an option
in all IETF protocols in a single operation.

* Parties who might be willing to consider use of Camellia are much more
likely to do so if it is an option in all protocols.

* WGs do not need to spend time discussing algorithm choice unless they are
one of the rare WGs where the problem itself is actually special.

IPSEC, CMS, TLS and Jose are all general purpose cryptographic building
blocks that are intended for use building other applications. There is
really no reason that any of those WGs should ever need to discuss
algorithms because it is the applications (e.g. HTTPS, S/MIME) that those
arise in.

> whatever value we get from being able to answer those questions on a

I think a WG should be allowed to vary if a case is made to allow that and
the AD, IESG etc. accept it.

But by default, choice of algorithms should be considered a rat hole.

> (e.g., use concluded WG lists)?

No, I see changing mandatory to implement as being something that should
happen so infrequently as that this is not an issue. The two drivers for
the mandatory to implement set are developments in cryptanalysis/hardware
and expiry of IPR claims.

We have already done this with the move to AES and the SHA-1 to SHA-2
transition. that required a lot of work because many of the protocols had
really not had sufficient thought given to the transition issue. I do not
expect to have to go through the same level of effort for the SHA3
transition.

Barring some major unexpected cryptanalytic result, the transitions I would
anticipate in 'mandatory to implement' over the next decade are :

* Define the initial set [RSA, DH, AES, SHA-2, HMAC-SHA2]

* Deprecate RSA1024 / Mandate RSA 2048
* Mandate SHA-3 (in parallel with SHA-2)

After there is confidence that all remaining EC claims have expired:

* Mandate an EC set with a named curve.

I don't see that any of those changes would be particularly controversial.
we all move in pretty much the same direction anyway. In theory a WG could
choose to use something other than AES as its mandatory to implement
symmetric encryption algorithm. In practice the only algorithm that there
is going to be a consensus for is AES.

> will look like when we're done.

That would work for me. The key thing though would be to avoid having to
discuss this afresh for new WGs that start.

> unified registry proposal.

The idea was to divide the task into three parts so that the barrier to
registration can be made very, very low.

I do not want there to be any IETF review of the strength of the
algorithms. All that would be required is to state:

1) This document ONLY assigns identifiers, it does not imply any endorsement
2) Specify the code points
3) Specify the test vectors in a predefined format

The only 'speed bump' here would be the third part and waiting for the
expert review.

> don't

HMAC-SHA-1 is certainly secure for pretty much all known cryptographic
purposes. But as I pointed out for MD5, the cost of using HMAC-SHA-1 is now
greater than that of using HMAC-SHA-2 because every system that uses SHA-1
in any capacity creates a need for someone like me to periodically (1)
determine that SHA1 is sufficient, (2) write up a report explaining that
the system is still secure (3) invoice them for the 4-8 hours work
resulting.

> and/or ensure the security of our protocols, say.

Another reason why I only want to analyze the security of the small
mandatory-to-implement subset.

> registry as we gain experience?

That would work.

> decided
> algorithms.

We cannot stop the Russian federation from passing a law to make GOST
mandatory to implement. But nor can they force us to make GOST mandatory to
implement.

> Or perhaps I'm wrong and implementors (and therefore, the

The number of mandatory to implement algorithms should usually be one and
never more than two. Everyone else just gets their code points assigned and
nothing else.

Having a choice of algorithms means that you get the security of the
weakest one, not the strongest one. The only case in which it is desirable
to have two algorithms that are mandatory to implement is when you have one
algorithm that is in widespread use that you are looking to phase out in
favor of a new one long before that change is forced by an announcement at
Crypto or RSA.

[OK the SHA-1 / 2/ 3/ change might end up requiring three but that is the
type of situation we are looking to avoid in the future]

> possible to reach consensus in such a situation??

Consensus would only be required for the Mandatory To Implement (MTI) and
Prohibited To Implement (PTI) registries. The unified registry would be
almost first come first served.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 15 Nov 2011 17:16:23 -0500

On Tue, 2011-11-15 at 16:09 -0500, Phillip Hallam-Baker wrote:

> In what circumstances would we want to endorse an algorithm for
> protocol A knowing that it is not suitable for protocol B?

Easy: when protocol A and protocol B have different requirements.

> What I am proposing instead is a low bar to making Camellia an option
> in any IETF protocol. I believe this to be a Pareto improvement as
> follows:
> 
> 
> * The developers of Camellia can get their algorithm enabled as an
> option in all IETF protocols in a single operation.

No, it's not that easy.  "Use Camellia" is not a protocol specification,
and cipher suite specifications for TLS and CMS are so vague that
frankly I'm surprised there is any interoperability at all.  In the rest
of the IETF, there is per-protocol technical specification work that
needs to be done in order to use a new algorithm.

> I think a WG should be allowed to vary if a case is made to allow
> that and the AD, IESG etc. accept it.

Ah, so you are proposing to change process.  Right now, those decisions
are primarily up to each WG; you are proposing that we instead require
someone to "approve" some sort of "exception" before a WG is allowed to
make such decisions for itself.

That's not necessarily bad, but it is a change.

> No, I see changing mandatory to implement as being something that
> should happen so infrequently as that this is not an issue. The two
> drivers for the mandatory to implement set are developments in
> cryptanalysis/hardware and expiry of IPR claims. 

And changes in requirements, and implementation considerations, and
performance considerations, and defending against _future_ changes in
any of those.

> The number of mandatory to implement algorithms should usually be one

People keep saying that, but in fact I think that's a horrible idea.  If
you only have one MTI algorithm, then when that algorithm is suddenly,
spectacularly broken, everyone is screwed.  You can't just declare some
new algorithm MTI, because that _doesn't solve the problem_.  What
solves the problem is _deploying_ the new algorithm, and having to wait
three years for the IETF to choose a new MTI algorithm and then for
vendors to implement, test, and ship it just doesn't cut it.

In most cases we should have _at least two_ MTI algorithms whenever
possible, so that if one is broken we (operators) can simply turn it off
and everything continues to work.

That said...

>  and never more than two. Everyone else just gets their code points
> assigned and nothing else.

... I mostly agree with this point, modulo the observation that for some
protocols, some protocol-specific technical specification work is
required.  For such protocols, code points should not be assigned until
the needed specification is available.  Of course, this is in most cases
separate from the question of the extent to which the algorithm itself
is documented.

> Consensus would only be required for the Mandatory To Implement (MTI)
> and Prohibited To Implement (PTI) registries. The unified registry
> would be almost first come first served.

A "Prohibited to Implement" registry makes no sense; people would simply
choose not to comply.  And really, what customer is going to demand that
a vendor comply with a standard whose sole purpose is to restrict the
choices available to the customer?  Besides, it wouldn't help, because
_existing_ versions of products wouldn't magically lose capabilities
just because something was added to such a registry.

What you really want is a registry of algorithms that the IETF
recommends no longer be _deployed_.

-- Jeff

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 Nov 2011 16:58:13 -0600

> knowing that it is not suitable for protocol B?

We currently let each WG decide on its own.

> The IETF is in the standards business and one of the things that you do in a
> standard is you decide what is not part of the standard. I cannot see any
> * In general, adding an algorithm for use with protocol X knowing that it is
> inappropriate for use in other protocols.

We certainly do the last w.r.t. cipher *modes*.  For example, counter
modes are not appropriate for use in Kerberos PDUs other than
KRB-PRIV, KRB-SAFE, and KRB-CRED, but that doesn't stop us using
counter modes elsewhere.

As to whether Camellia (for example) can ever get made MTI for any
IETF protocols, I can certainly imagine situations that might lead us
to doing so (e.g., serious cryptanalytic advances against AES).  In
the meantime, I agree, but we're still letting each WG decide this on
its own.

> What I am proposing instead is a low bar to making Camellia an option in any
> IETF protocol. I believe this to be a Pareto improvement as follows:
> * The developers of Camellia can get their algorithm enabled as an option in
> all IETF protocols in a single operation.

The last item is likely unavoidable for any protocol where a given
cipher or cipher mode presents any challenges.  Camellia is NOT such a
cipher for any Internet protocol that I can think of, so it's not a
good example.

> But by default, choice of algorithms should be considered a rat hole.

I agree, but it is easier, politically, for the IETF and IESG to let
WGs have more freedom.

..
> happen so infrequently as that this is not an issue. The two drivers for the
> mandatory to implement set are developments in cryptanalysis/hardware and
> expiry of IPR claims.

I agree, though I'd add significant performance improvements as
another potential driver (particularly for hash functions and ECC
curves).

> * Mandate an EC set with a named curve.

Yes.

> discuss this afresh for new WGs that start.

OK.  The more we can fit in this initially the better, provided we
don't make it too hard to make progress.  I'm still not sure what the
right set of initial protocols for the new registry would be.

> I do not want there to be any IETF review of the strength of the algorithms.
> All that would be required is to state:

My concern is about the time to get the new registry off the ground.

> mandatory-to-implement subset.

The problem is not the size of the MTI set, but the size of the
protocol set for which we're doing this.

>> registry as we gain experience?

OK.  Something to keep in mind if we have trouble obtaining consensus
for a normative registry.

> mandatory to implement. But nor can they force us to make GOST mandatory to

The sooner every government gets this, the better.

So, for me the main thing left is the schema for the registry entries,
so to speak, given the need to cover disparate protocols.  There's a
fair bit of detail to get into a registry entry, enough that an RFC
seems better for every detail other than the code point allocations.

Nico
--

---

From: David McGrew <[email-masked]>
Date: Tue, 15 Nov 2011 15:29:16 -0800

Hi Philip,

On Nov 15, 2011, at 9:16 AM, Phillip Hallam-Baker wrote:

> This issue keeps coming up. I think that events are converging in a  
> way that forces us to finally do something.
>
> At present the IETF has some tens of protocols that use  
> cryptographic algorithms. Some use one registry, others use another,  
> some use no registry at all, some use OIDs and so on.

that's absolutely right, but it is worth mentioning that there is an  
IETF registry for crypto algorithms that is used across several  
different protocols: the Authenticated Encryption registry defined in  
RFC 5116 <http://www.iana.org/assignments/aead-parameters/aead-parameters.xml 
 > that is used in TLS 1.2 (RFC 5246), IKEv2 (RFC 5282), SSH (RFC  
5647), SRTP (draft-ietf-avt-srtp-aes-gcm-02), and JSMS (draft-rescorla- 
jsms-00).   (ESP is compatible, but not formally specified, as is IEEE  
MACsec for that matter.)

> I see the following problems with the current situation:
>
>
> 1) There is no established process for telling people 'do not use  
> 512 bit RSA keys with any IETF protocol.'
>
> We have recently had some issues arising from use of 512 bit  
> certificates. This is a problem that should never have occurred.  
> Browser vendors and CAs have both known of the security issues  
> relating to 512 bits for a decade. But we still managed to end up  
> with breaches occurring because everyone was waiting for someone  
> else to take action.
>
> Some party needs to take action here and say that they are going to  
> decide when to tell people to stop using obsolete crypto. The actual  
> advice given being much less important than the decision to take  
> responsibility for giving it.
>
> Remember that using stronger cryptographic algorithms DOES NOT make  
> you any more secure. The only way to make yourself more secure is to  
> STOP USING the insecure ones. Phasing out MD4 and MD5 is much more  
> important than deploying support for the SHA-2 replacement.

Standards action setting minimal key sizes would be good.  I'm not  
sure that we need a registry to do that, though; we could use an  
approach like RFC 6150.  But a registry could help.

> At one point quite a few Security Area groups appeared to be kept  
> going more or less for the sole purpose of twiddling crypto  
> algorithms. At the moment the IETF has a process for setting minimum  
> key lengths for PKIX certs. But when PKIX closes the only mechanism  
> will be a personal submission to change a standard developed by the  
> WG for over 15 years. That seems to be a mismatch to me.
>
>

Agreed.

> What point is served by having the same conversation about which  
> algorithms to use in 10 different WGs? Modern machines are (mostly)  
> pretty capable and there are almost no cases where an individual WG  
> need be making protocol specific choices of algorithm to meet  
> performance or space goals.
>
> Back in 1995 we had to consider performance quite closely. 512 bit  
> certs actually made some sense at that point. We did not have AES.  
> We were dealing with the FBI and part of the NSA trying to prevent  
> use of strong crypto. Choice of algorithm was a much harder choice  
> then and often had to be fitted to the specific protocol.
>
> Today there are still circumstances where performance constraints  
> are significant. For example, the low performance devices I work  
> with in my control systems work. But that means a choice between  
> public key and symmetric key rather than between standards based  
> crypto and some purpose built homebrew scheme. For most low  
> performance devices, AES is now the algorithm preferred over all  
> others because it is available in hardware.
>
> We are going to have to have a conversation about which algorithms  
> we are going to choose somewhere. At the moment we face the choice  
> of either have that conversation in Jose and then have it again in  
> the next WG or have the discussion at a Security Area level and re- 
> use those choices in the future.

Agreed.

>
>
> 4) Inconsistency
>
> Using two different crypto algorithms provides the strength of the  
> weakest one. Inconsistency is almost always worse than a sub-optimal  
> choice. I don't much care what the RSA signature format used is as  
> long as it is 'good enough' for me and 'everyone' is using it.
>
> We should make these choices once and have the consequences flow out  
> to all the protocols that use the algorithms.
>
> There have been a few prior attempts to deploy a registry that would  
> cover more than one protocol. But to date there has been no registry  
> that has really done what is needed to unify all the registries into  
> one place and establish a unified process for change control.
>
>

I'm not sure I completely understand this point.

> Cryptography has always been a highly politicized technology. In  
> recent decades it has been as highly politicized as nuclear power  
> and for much the same reason: Cryptography was one of the principle  
> technologies that decided the outcome of WWII and was thus a key  
> technology in the cold war.
>
> The politics behind so-called vanity crypto are very complex and I  
> don't really want to go into them here. What I wat to do instead is  
> to build a firewall so that the IETF does not need to get dragged  
> into those politics.
>
> For historical reasons, the IETF preferred algorithms are  
> essentially the NSA/NIST choices. One approach would be for the IETF  
> to only recognize those and no others. This is probably not  
> sustainable. Registries such as IANA are only stable so long as they  
> are willing to register code points on a basis that is acceptable to  
> the parties that need code points to be defined. If IETF/IANA  
> refuses to assign code points then the refused parties will simply  
> pick a code point and use it. This has occurred repeatedly in other  
> venues. That is why there is a hole blocked out in the MAC address  
> space, the storage providers wanted a globally unique address and  
> saw no reason to pay IEEE for the numbers. That is why barcodes are  
> structured as they are.
>
> Another approach is simply first come first served. I do not like  
> that approach as it means that the IETF ends up 'endorsing' the use  
> of broken crypto. But it is arguably better for the IETF to have a  
> policy that allows for anyone to register in a way that ensures that  
> a disclaimer is applied than to try to weed out the bad ones and not  
> do a good job of it.
>
> One caveat that comes up is that some protocols have limited space  
> for code points. But this can almost certainly be dealt with by some  
> form of extension mechanism that allows use of a common code space  
> (e.g. OIDs) for non mandatory to implement algorithms.
>
>
>
> IETF requests IANA create three new registries of cryptographic  
> algorithms as follows:
>
>
> This would be a registry that is divided up into separate sub- 
> registries for various types of algorithm (public key signature,  
> public key encryption, digest, encryption, mac, suites, etc.)
>
> The RFC would start off with a pre-amble that states that the IETF  
> makes no endorsement of the strength of the cryptographic algorithm  
> and the expert review would be strictly limited to determining that  
> the format of the document is correct, the document would not be  
> allowed to specify code either. The purpose of these requirements  
> being to prevent people from presenting assignment of code points as  
> an IETF endorsement of the algorithm strength.
>
> 1) Specify the code points for ASN.1 OID, text string, URI and  
> optionally additional code points for IPSEC, DNSSEC, etc.
> 2) Specify test vectors in a format that ensures that endian-ness  
> issues are addressed.
> 3) Specify the location where further documentation is to be found  
> (which might be another RFC).
>

The AEAD registry essentially meets these requirements (for symmetric  
authenticated encryption).   This is a good thing, both because it is  
proof that the goal is achievable, and because AEAD is exactly what  
the IETF should be promoting for symmetric encryption.

> This would be a subset of the algorithms specified in the first  
> registry and would normally consist of exactly one algorithm of each  
> class.
>
> Criteria for changes would be Standards Action required. Each RFC  
> making changes would specify the full list of required algorithms  
> each time.
>
> compliance with the base specification. So if a vendor was  
> specifying standards compliance for its Web server it would specify  
> 'Complies with RFC 2616, RFC 5246 & RFC XXXX'
>
>
> This is the registry of algorithms and key sizes that IETF warns  
> against using. The warning may be immediate or have some specific  
> action date.
>
> It would also be possible to state that an algorithm is deprecated  
> for specific purposes or with certain protocols. For example, MD5  
> should not be used for any purpose that requires protection against  
> collision attack. There are certainly cases where use of MD5 does  
> not raise a security issue, though the cost of going through the  
> necessary justification is almost never going to be worthwhile  
> unless there is a major legacy deployment issue.
>
> Criteria for changes would be Standards Action required. This would  
> also be cumulative.
>
> To be in compliance with this specification, applications MUST NOT  
> permit the use of those algorithms (even if the user requests them).
>
> So to specify compliance, a product would state 'Complies with RFC  
> 2616, RFC 5246, RFC XXXX & RFC YYYY'
>
>
> The task of ongoing maintenance would be left to the IETF SAAG and  
> SECDIR. Actually making these decisions is much less difficult than  
> deciding on having one place to make them.
>
> Although the bar is set at 'standards action required', this would  
> normally be something I would see being done on an individual  
> submission basis rather than requiring a Working Group to be formed.
>

This is an interesting approach.   It is ambitious to use registries,  
rather than relying on an RFC that defines the MUST implement  
algorithms.

If I understand right, your aim is to define a single must-implement  
algorithm, a set of must-not-implement deprecated algorithms, and then  
to allow WGs to choose to mandate or recommend other algorithms?   Is  
that the intent?

There is complexity in the algorithm details that isn't dealt with in  
this proposal (at least not explicitly dealt with).  For symmetric  
crypto, there are issues of block cipher modes of operation (e.g. CBC  
and GCM) and IV generation, and authentication (CBC needs a separate  
authentication algorithm).   Different protocols handle the ordering  
of authentication and encryption differently, and handle IV generation  
differently.   Now, for symmetric crypto, these issues mostly go away  
if we go with AEAD.   But no protocol yet has made an AEAD algorithm  
mandatory to implement, so this would be a significant move for WGs.    
I have not looked into the details for asymmetric crypto, but I would  
expect similar complexity there.   I think this is worth  
investigating, though.

In any consideration of crypto algorithms, IRTF crypto forurm RG  
should provide input on security, performance, and other technical  
issues, and should be consulted.   Which I'm sure the Security ADs  
would do, but I'm mentioning it so that others don't forget about the  
resource ;-)

David

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 15 Nov 2011 18:45:09 -0500

On Tue, 2011-11-15 at 15:29 -0800, David McGrew wrote:
> RFC 5116
> <http://www.iana.org/assignments/aead-parameters/aead-parameters.xml>
> that is used in TLS 1.2 (RFC 5246), IKEv2 (RFC 5282), SSH (RFC 5647),

Um, no.  RFC5647 is not SSH; it is AES-GCM for SSH.  This is indeed an
AEAD mode, and it borrows terminology from RFC5116, but so far as I know
it does not use the AEAD algorithms registry, and SSH itself certainly
does not; it has its own registries for each of the algorithm types it
uses.

-- Jeff

---

From: David McGrew <[email-masked]>
Date: Tue, 15 Nov 2011 17:26:56 -0800

Hi Jeff,

On Nov 15, 2011, at 3:45 PM, Jeffrey Hutzelman wrote:

> Um, no.  RFC5647 is not SSH; it is AES-GCM for SSH.

right.

> This is indeed an

Right, SSH does not define a way to negotiate any AEAD algorithm,  
though it does have an AEAD interface.  Instead, it adds two entries  
from the AEAD registry to the SSH registry.  Future standards work  
could easily extend this by defining a similar binding between entries  
from the AEAD registry and the SSH registry.

I did not mean to imply that there are protocols that negotiate AEAD  
algorithms using entries from the IANA registry.  Not yet anyway,  
though it would be a security improvement and a simplification to do  
away with independent registries and negotiation for authentication  
and encryption.

David

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 Nov 2011 00:41:55 -0500

On Tue, Nov 15, 2011 at 5:58 PM, Nico Williams <[email-masked]>wrote:

> >> On Tue, Nov 15, 2011 at 11:16 AM, Phillip Hallam-Baker <
> [email-masked]>
> >> wrote:

That is true but irrelevant.

In what case would TLS accept Camilla as a preferred or mandatory to
implement algorithm if it was not capable of being used in S/MIME, IPSEC
and the rest?

This is a standards organization and one of the reasons that we work as we
do is that there is an idea that TLS and S/MIME and IPSEC and the rest all
have an overlap that is important. There is a presumption that we are
trying to find a common approach.

If a WG has a really good reason to consider a non IETF standard algorithm
then that is fine. But I have listened to these discussions for years now
and I have yet to ever hear a good reason for an IETF protocol to employ
DIY crypto. The argument has always centered on what the state of the art
is for crypto in general.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 16 Nov 2011 19:52:39 +1300

Phillip Hallam-Baker <[email-masked]> writes:

>There is no shortage of cryptographic algorithms. I can't see why TLS should
>even spend the time considering Camellia if there was any doubt about the
>ability to use it in IPSEC.

The situation with Camellia (and several others) is even messier than that.
These are present in protocols purely as fashion statements, so there's no
easy way you can make any technical statements about them ("this algorithm is
used here because ..." or "... not used here because ...").  OTOH it's also
unlikely that their contributors are going to be happy having them listed in
some registry as "present in order to make a fashion statement" (NB: "Present
because the government of Elbonia mandates it for use in Elbonia" is just a
roundabout way of saying that it's a fashion-statement algorithm, so that
doesn't work as an excuse either).

I have no idea how you'd deal with this once you start going beyond the
currently-employed ostrich algorithm.

Peter.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 16 Nov 2011 08:27:16 +0100

> in all IETF protocols in a single operation.

The situation with Camellia has another angle to it: the patent
statements about it only applies to specific protocols, and there are
now statements for (at least) TLS and Kerberos.  If Camellia is to be
considered for any other protocol, a new patent disclosure is required.
So Camellia is not intended to be a general purpose cipher.

Personally, I find this limiting enough that I believe we should not
waste precious review and process time on it.  Time that could be spent
on standardizing non-encumbered algorithms.

/Simon

---

From: David McGrew <[email-masked]>
Date: Wed, 16 Nov 2011 06:05:19 -0800

Hi Phillip,

On Nov 15, 2011, at 11:27 PM, Simon Josefsson wrote:

>> option

This is a good point.   I had not realized all of the IPR nuances  
around this cipher.

NTT declared back in 2001 that it "intends to grant royalty-free  
licenses" for Camellia [1] but apparently on a protocol-by-protocol  
basis, and the IPsec case includes a reciprocity requirement [2].   
Perhaps the Camellia sponsors can prod a broad IPR declaration from  
the IPR holders?

It looks like the IPR situation for Camellia is not captured in the  
datatracker tools.  The only Camellia RFC that I found that has an IPR  
link is the TLS one, RFC 6367, and that link is not about Camellia IPR!

> on standardizing non-encumbered algorithms.

Agreed.  Any algorithm that seeks broad acceptance needs to be  
available royalty-free around the world.  There is an available pool  
of such ciphers that were created during the AES process (serpent,  
twofish, ...) plus some other more modern IPR-free ciphers that could  
be used to achieve algorithm diversity in standards.   The IETF needs  
to be clear and firm in not mandating the implementation of patent- 
encumbered ciphers.

David

[1] "Announcement of Royalty-free Licenses for Essential Patents of  
NTT Encryption and Digital Signature Algorithms" <http://www.ntt.co.jp/news/news01e/0104/010417.html#01 

[2] NTT-Mitsubishi Patent Licensing Statment for Camellia <ftp://ietf.org/ietf/IPR/050425%20NTT-Mitsubishi%20Statement%20for%20Camellia.pdf

---

From: David McGrew <[email-masked]>
Date: Wed, 16 Nov 2011 07:04:34 -0800

Hi Nico,

On Nov 15, 2011, at 10:06 AM, Nico Williams wrote:

> On Tue, Nov 15, 2011 at 11:16 AM, Phillip Hallam-Baker <[email-masked] 
> > wrote:
>> algorithms

That's a practical suggestion.

> CBC.

+1

>  This wouldn't be a big change for SSH as it already has this for

I think that what you mean could be said as: the crypto algorithm  
should be responsible for the IV or nonce, and not the protocol.  I  
think that's a great idea.

> happens.

+1

> This is the biggest scare factor for me regarding your
>> weakest

+1

>> recent

There may be a role for a "global" decision here.  The only important  
technical argument for recommending the implementation of more than  
one cipher is to provide for security through algorithm diversity.  It  
might make sense to select an alternate cipher to the AES to act as a  
standby in case of unanticipated future advances in cryptanalysis.  If  
we do this, it would be best to select a single algorithm, which could  
have a status on Phillip's list somewhere below MUST-implement but  
above MAY-implement.   Any process used for the selection of a standby  
should meet the same stringent criteria for extensive public review  
and analysis as the AES did, and should meet all of the criteria set  
out for the AES: security, computational efficiency, memory  
requirements, hardware and software suitability, simplicity,  
flexibility, and licensing requirements.  In particular, it should be  
available worldwide on a royalty-free basis.  Since the major goal of  
a standby cipher is to be secure even if the AES proves vulnerable to  
future advances in cryptanalysis, the standby algorithm should not  
follow a design strategy that is identical to that of the AES.  Or  
perhaps a better way to state the last requirement is: a standby  
algorithm should have a sound technical argument why it would survive  
advances in cryptanalysis that would be damaging to the AES.

The other technical arguments for multiple ciphers are performance/ 
implementation cost, and interoperability during transitions.  I don't  
think performance and cost should be a determining factor for the  
majority of IETF work.  If those considerations prove to be important  
for constrained environments, say, they can and should be treated as a  
special case (which is consistent with your suggestion to focus on the  
main IETF cryptographic protocols).  Interoperability between  
algorithm transitions (say, from DES to 3DES to AES) clearly isn't  
pertinent to the selection of new algorithms.

David

>> essentially the

---

From: David McGrew <[email-masked]>
Date: Wed, 16 Nov 2011 07:27:16 -0800

Hi Jeffrey,

> and everything continues to work.

You have a valid point, though I am not convinced that two MUST- 
implement algorithms makes sense, considering how unlikely it is that  
AES will need to be replaced in the foreseeable future.  But having an  
alternate algorithm declared SHOULD-implement might be reasonable, and  
that's not far from the direction you suggest here.

An important factor: if an algorithm is selected for use as a standby  
to the AES, that imposes a particular set of technical criteria that  
it should meet.  (My last post set these out, so I won't repeat them  
here.)

David

---

From: Satoru Kanno <[email-masked]>
Date: Thu, 17 Nov 2011 08:54:40 +0900

Hi Simon and Phillip,

(2011/11/16 16:27), Simon Josefsson wrote:
> Phillip Hallam-Baker<[email-masked]>  writes:
>

Up to now, because we proposed adding the Camellia cipher to each
protocols, we filed the Camellia IPRs for the relevant WGs.

If IETF changes the policy of addition of cipher algorithms to new
one, of course, NTT & Mitsubishi intend to file for the revised
general-purpose IPR which permits to use Camellia cipher in any
protocols in IETF.

Thanks,
Satoru

-- 
Satoru Kanno

Security Business Unit
Mobile and Security Solution Business Group
NTT Software Corporation

e-mail: [email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 Nov 2011 21:24:23 -0500

> on standardizing non-encumbered algorithms.

This seems to me to be an argument for having the decision made at the IETF
level. If there are no IPR issues I don't particularly care whether Camilla
is available for use in IPSEC or not. But if there is an IPR issue then I
don't want to see it accepted for IPSEC unless it is available for TLS,
S/MIME and everything else.

I do not object to encumbered technology as an absolute principle but I see
no reason to spend one minute of any WG time considering any encumbered
technology that does not offer a clear and exceptionally compelling
advantage over unencumbered alternatives.

In this case there is a very clear disadvantage to having these
negotiations made piecemeal on a WG by WG basis. I don't want to spend a
minute in IPSEC if the result is going to be free for use in TLS and for
future IETF protocols.

The issue would be rather different if we were talking about a technology
that does not have an unencumbered alternative at present. But we have a
very good unencumbered alternative to Camilla so why spend any time on it
(including the time taken to say 'on your bike').

---

From: Tom Yu <[email-masked]>
Date: Wed, 16 Nov 2011 23:01:40 -0500

> advances in cryptanalysis that would be damaging to the AES.

Are you proposing that the IETF (or CFRG) undertake an evaluation
effort of the same magnitude as the NIST AES competition?  That sounds
expensive and time-consuming.  Would it be useful to instead look at other
cipher evaluation efforts, such as the EU's NESSIE project?

---

From: Tom Yu <[email-masked]>
Date: Thu, 17 Nov 2011 00:05:41 -0500

David McGrew <[email-masked]> writes:

> NTT Encryption and Digital Signature Algorithms"
> <http://www.ntt.co.jp/news/news01e/0104/010417.html#01
>>
>
> [2] NTT-Mitsubishi Patent Licensing Statment for Camellia
> <ftp://ietf.org/ietf/IPR/050425%20NTT-Mitsubishi%20Statement%20for%20Camellia.pdf

Quoting from http://www.ntt.co.jp/news/news06e/0604/060413a.html

"Hereafter, however, in accordance with an agreement between NTT and
Mitsubishi, Camellia essential patents can be used at no charge by any
Camellia user without concluding such royalty-free licensing agreement
hereafter.
Of course, if there is your request, patent execution consent from NTT
and Mitsubishi based on the royalty-free licensing agreement for
essential patents can be obtained in the same way as up to now."

I am not a lawyer, but I read that as declaring that they won't
enforce the Camellia patents, but will provide formal royalty-free
licenses if desired.  However, that's somewhat in conflict with the
wording of their IPR statements, which say things about reciprocity.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 17 Nov 2011 10:50:25 +0100

> wording of their IPR statements, which say things about reciprocity.

And other things, including restricting the license to a particular
protocol.  A 5 year old press release has little weight compared to the
patent disclosures filed with the IETF, in my opinion.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 17 Nov 2011 10:58:44 +0100

> general-purpose IPR which permits to use Camellia cipher in any

I do not believe the IETF has changed any policy in this area.  The
essential policies are described in RFC 3979 [1].  You could file a
general patent disclosure on Camellia instead of a specific disclosure
for each and every draft.

Generally, you are at liberty to use any license you want for your
patent, but the community is at liberty to ignore your work if the
license is considered to "get in the way".

I for one would welcome a new general patent disclosures that says you
permit use of Camellia for any purpose to everyone.

/Simon

[1] https://www.ietf.org/rfc/rfc3979.txt

---

From: David McGrew <[email-masked]>
Date: Thu, 17 Nov 2011 07:29:42 -0800

Hi Tom,

> cipher evaluation efforts, such as the EU's NESSIE project?

good questions.  I'm not proposing that IETF or IRTF manage a cipher  
competition.  As you say, it would be a considerable effort; besides,  
neither of those groups has the needed quorum of expertise.   But I do  
see an important role for the IETF in setting requirements and  
priorities.  Perhaps a good way to do this would be to draft up  
requirements in a format that would be useful input to cipher  
evaluation projects like ECRYPT and CRYPTREC.  This could be very  
positive for the Internet, if it helps to channel the pressure for  
alternative ciphers into a useful direction.

The flip side of this is: within IETF, we should not uncritically  
accept the assertion that a particular cipher should be adopted by a  
particular protocol because it could be useful as a standby cipher.

An aside: there has been a good amount of discussion about alternative  
block ciphers, because of Camellia, SEED, ARIA, and GOST.  There ought  
to be more consideration to other technical aspects, such as the way  
the block cipher is used.  For instance, all of the modes in current  
standards use b invocations of the block cipher to encrypt b blocks of  
data.  There are modes of operation that achieve quantifiably higher  
security levels by using more block cipher invocations (the most  
practical example being Iwata's CENC mode [1] which uses one  
additional invocation).  It is fair to ask: if our goal is to make  
standards that are impervious to future advances in cryptanalysis,  
would it be better to adopt a different mode instead of a different  
block cipher?

David

[1] <http://www.nuee.nagoya-u.ac.jp/labs/tiwata/cenc/cenc.html>

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Nov 2011 12:56:24 -0600

> That's a practical suggestion.

Yes, but my unstated aim was to show that Philip's proposed registry
would be rather complex, complex enough that we'd have to choose to
either make it incomplete or informative.  I don't see enough value in
having a complete and normative registry of crypto algorithms for
Internet protocols to bother with the complexity of such a registry.
There, I've said it :)

>> [...]
>
> I think that what you mean could be said as: the crypto algorithm should be
> responsible for the IV or nonce, and not the protocol.  I think that's a
> great idea.

That's not what I had in mind, but it's important to clarify this now
that you mention it.  The protocol must be responsible for all
parameters of a cryptographic algorithm that the algorithm exposes.
Confounders and nonce IVs for CBC mode ciphers, for example, are NOT /
should NOT be exposed parameters of the cipher in any mode that has
such things (certainly not in Kerberos), thus the application protocol
cannot be responsible for them.  But keys and AEAD message IVs *are*
exposed parameters of the cipher, and must be supplied by the
application protocol.

In any PSK protocol we must be extremely careful about selection of
AEAD message IVs, as IV repetition has extremely negative impact on
the security of the protocol.  ASIDE: the typical AEAD IV size
(between 96- and 128-bit) is too small for comfort for PSK, enough
that I'd propose using additional bits for deriving message keys, thus
yielding an effective message IV of 256 bits -- enough to greatly
reduce chances of accidental IV reuse, to the point where I'd feel
comfortable.  (Kerberos effectively uses PSK, so this applies to
Kerberos.)

> There may be a role for a "global" decision here.  The only important

Maybe, but I think that matter is entirely separable from the proposal
for a common crypto algorithm protocol specification registry.

Nico
--

---

From: David McGrew <[email-masked]>
Date: Thu, 17 Nov 2011 11:14:51 -0800

Hi Nico,

> Internet protocols to bother with the complexity of such a registry.

:-)

>> should be

As an aside, GCM and SIV modes can use arbitrary-length IVs.

Agreed.

David

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Nov 2011 13:26:14 -0600

> As an aside, GCM and SIV modes can use arbitrary-length IVs.

But it's effectively MACed down to 96-bits.  I suppose that makes it
difficult enough to tell when there's been reuse of the effective
96-bits that it's secure.  I'll think about that.

Nico
--

---

From: David McGrew <[email-masked]>
Date: Thu, 17 Nov 2011 12:25:03 -0800

Hi Nico,

> 96-bits that it's secure.  I'll think about that.

actually, in GCM, the IV is MACed to a 128-bit value if the IV is not  
exactly 96 bits long.  I believe that SIV mode is similar and its  
"synthetic" IV value is 128 bits (though Dan Harkins is the person to  
ask).

David

---

From: Satoru Kanno <[email-masked]>
Date: Fri, 18 Nov 2011 10:29:51 +0900

(2011/11/17 18:58), Simon Josefsson wrote:
> Satoru Kanno<[email-masked]>  writes:
> 
>> Hi Simon and Phillip,
>>
>> one, of course, NTT&  Mitsubishi intend to file for the revised

Thanks, Simon.
We understand your useful opinion.
As soon as possible, We start to discuss with our intellectual property
center whether we will revise our present IPRs to a new general-purpose IPR.

Regards,

-- 
Satoru Kanno

Security Business Unit