Subject: [IPsec] On marking algorithms obsolete in IANA registries

From: Paul Wouters <[email-masked]>
Date: Mon, 17 Dec 2018 23:14:17 -0500 (EST)

Recently we had a discussion about mapping IANA entries to a yang model,
and the question came up whether we sould add a deprecated marker to the
IKE/ESP registries for algorithms.

I thought it was a good idea, but not everyone agreed.

I just stumbled upon RFC 7696: Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms

Section 2.1: Algorithm Identifiers

    In the IPsec protocol suite, the Internet Key Exchange Protocol
    version 2 (IKEv2) [RFC7296] carries the algorithm identifiers for the
    Authentication Header (AH) [RFC4302] and the Encapsulating Security
    Payload (ESP) [RFC4303].  Such separation is a completely fine design
    choice.  [...]

    An IANA registry SHOULD be used for these algorithm or suite
    identifiers.  Once an algorithm identifier is added to the registry,
    it should not be changed or removed.  However, it is desirable to
    mark a registry entry as deprecated when implementation is no longer
    advisable.

So there is even an RFC stating that we should really do this :)

I guess the main question is, can we add these via a request to IANA
based on RFC 8221 and 8247, or do we need to write a short RFC with
requests to IANA?

Paul

---

From: Yoav Nir <[email-masked]>
Date: Tue, 18 Dec 2018 06:29:51 +0200

Hi, Paul

I think we need an RFC to at least categorize the algorithms, unless we want the IANA registry to have stuff like “SHOULD-“ and “MAY+:

> On 18 Dec 2018, at 6:14, Paul Wouters <[email-masked]> wrote:
> 
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Wouters <[email-masked]>
Date: Mon, 17 Dec 2018 23:37:25 -0500 (EST)

> I think we need an RFC to at least categorize the algorithms, unless we want the IANA registry to have stuff like “SHOULD-“ and “MAY+:

We only need to add the SHOULD NOT and MUST NOT's and possibly some
MAY's that are deemed otherwise ancient and deprecated (eg CAST)

Anything with a + would surely not be deprecated as it is still climbing
up. Anything with a - is still in use and we cannot deprecate it yet.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 18 Dec 2018 09:39:11 +0300

Hi Paul,

I think it is a good idea to have some indication in IANA about the current status of the algorithm,
similar to recent changes in the TLS registry (and in fact I initiated this discussion in Bangkok).

> up. Anything with a - is still in use and we cannot deprecate it yet.

Well, I think it's a bit too complex for random implementer.
I'd prefer to classify all algorithms as follows:

1. Secure, required for interoperability
2. Secure, not required for interoperability
3. Insecure (obsoleted)

Regards,
Valery.

---

From: <[email-masked]>
Date: Tue, 18 Dec 2018 14:49:24 +0000

> On Dec 18, 2018, at 1:39 AM, Valery Smyslov <[email-masked]> wrote:
> 
> 
> [EXTERNAL EMAIL] 
> 
> Hi Paul,
> 

Possibly some algorithms are candidates for "obsolete" status not because they are known to be insecure but because they never got traction or security analysis.  I'm not sure if CAST is an example.

On terminology: "secure" is too strong a statement for the non-expert audience.  "Believed to be secure" would be more prudent, but I don't really like those words either.  Can we come up with some words that don't suggest a guarantee we can't make?

	paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 18 Dec 2018 17:58:17 +0300

Hi Paul,

> Possibly some algorithms are candidates for "obsolete" status not because they are known to be insecure but
> because they never got traction or security analysis.  I'm not sure if CAST is an example.
> 
> On terminology: "secure" is too strong a statement for the non-expert audience.  "Believed to be secure"
> would be more prudent, but I don't really like those words either.  Can we come up with some words that
> don't suggest a guarantee we can't make?

I agree that more accurate wording is definitely required here. My point was 
that we need three states for the algorithms - one indicating that the algorithm
is recommended (we believe it is secure and it is recommended choice for
interoperability), second indicating that algorithm is known to be broken or 
having insufficient security, and the third, for all other algorithms without
known security issues, but that are not (yet?) recommended for interoperability.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 18 Dec 2018 10:19:19 -0500 (EST)

> On terminology: "secure" is too strong a statement for the non-expert audience.  "Believed to be secure" would be more prudent, but I don't really like those words either.  Can we come up with some…

When I described the various SHOULD, MAY, MUST and their variants, I was
not suggesting of putting that into the IANA registry. The IANA registry
should only get "deprecated" or "obsolete". In my view (and I think the
RFCs view) deprecrated means "issues found, stop using it" and
"obsolete" means "meh, not harmful but no one else is using it anymore".

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 18 Dec 2018 10:21:28 -0500 (EST)

> similar to recent changes in the TLS registry (and in fact I initiated this discussion in Bangkok).

Indeed. And I agreed and I was reminded of this discussion once I
stumbled on this RFC that tells us to do it for our IKE/ESP registries
:)

Paul

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Dec 2018 10:58:20 -0500

Paul Wouters <[email-masked]> wrote:
    >> I think we need an RFC to at least categorize the algorithms, unless
    >> we want the IANA registry to have stuff like “SHOULD-“ and “MAY+:

    > Anything with a + would surely not be deprecated as it is still
    > climbing up. Anything with a - is still in use and we cannot deprecate
    > it yet.

so... I think that we did this in (spirit at least in) RFC8247?

It seems that maybe we forgot to tell IANA to deprecate anything that was
SHOULD NOT/MUST NOT, or that fell off the list.  Maybe this can be clarified
as an IESG directive rather than as a new document.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Yoav Nir <[email-masked]>
Date: Tue, 18 Dec 2018 22:01:15 +0200

> On 18 Dec 2018, at 17:19, Paul Wouters <[email-masked]> wrote:
> 
> "obsolete" means "meh, not harmful but no one else is using it anymore”.

I think it’s best to copy what TLS is doing and just add a “Recommended” column with a y/n value to all the algorithm lists.

A prudent administrator enables the algorithms marked “Recommended” and none of the others.

An administrator that enables other algorithms will have to explain why he or she did that when things go wrong.

TLS did write a document to change the IANA registries like that.

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Tue, 18 Dec 2018 23:04:17 -0500 (EST)

> TLS did write a document to change the IANA registries like that.

Recommended to implement or recommended for use ?

For instance, it is recommended to implement MODP 1536, but not recommended
to use it. The same is probably true for 3DES?

And what about AES_CTR? It's really a MAY so it is not recommended and
not not recommended.

It's confusing. deprecates/obsolete seems better. It's a negative term
applying to both implementation and using.

Browsers have too much power, so they can stomp on TLS servers. With
IPsec we don't have that much power.

Paul