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

From: Tero Kivinen <[email-masked]>
Date: Tue, 29 Jan 2019 16:45:36 +0200

Paul Wouters writes:
> 
> 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?

Mostly you would need to convince me as an IANA expert to do that, and
I do think it is wrong place to store that information and will make
registry confusing and messy, so I do not want to do it. If (when?)
you fail to do that then you would need to write draft and try to get
WG consensus on that (and then David would take care of that draft). 

The problem is that to be really usuful we would need to include
similar text we already have in RFC8247 for example, i.e., explain
where ENCR_AES_CCM_8 is useful and why it is SHOULD for some
environments, but not SHOULD for others etc.

I still think adding notes (as I explained in my other email sent few
minutes ago) is better option, and I plan to do that regardless... 
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 29 Jan 2019 10:11:59 -0500 (EST)

> environments, but not SHOULD for others etc.

I explained before that only MUST NOT entries would be marked in the
registry along with SHOULD NOT entries qualifying for deprecation due
to disuse (eg CAST). Anything with a "qualifier" would not be marked
in the registry as obsolete/deprecated.

Paul