Re: [IPsec] On marking algorithms obsolete in IANA registries
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). > > 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. 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. > Paul > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] On marking algorithms obsolete in IANA registries
On Tue, 18 Dec 2018, Yoav Nir 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+: 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] On marking algorithms obsolete in IANA registries
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 wrote: > > > 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 > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] On marking algorithms obsolete in IANA registries
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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC on draft-ietf-ipsecme-qr-ikev2-04
> > I don't think the proposed change is justified. The requirement language > > (MAY, SHOULD, MUST etc.) it IETF > documents is usually used in > > protocol descriptions when some actions are required (or prohibited) to > > achieve interoperability. Section > "Upgrade procedure" is not > > concerned with the protocol itself, it is just a recommended algorithm for > > upgrading some system for using > PPK. It is not the only algorithm > > possible. And it isn't concerned with interoperability of different > > protocol implementations. So, I'd leave the > text as is. > > We agree with your interpretation that a capital SHOULD might not be > appropriate, but we still feel a > lowercase "should" in place of "may" will encourage more administrators to > complete the upgrade procedure. OK, I think it's a good suggestion. Thank you, Valery. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
