[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    Re: [IPsec] comments on graveyard draft, became Re: Delivery Notification: Delivery has failed
From:       Paul Wouters <paul () nohats ! ca>
Date:       2021-03-08 15:10:50
Message-ID: f331894a-c4b6-182e-634c-f4376b9bdb9d () nohats ! ca
[Download RAW message or body]

On Mon, 8 Mar 2021, Dan Harkins wrote:

> =A0 Oh for gaia's sake....

>>     Recipient address: paul@nohats.ca
>>     Reason: Remote SMTP server has rejected address
>>     Diagnostic code: smtp;550 5.7.1 <dharkins@lounge.org>: Sender address
>>     rejected: Exercising my freedom to not hear you scream

I had put that in after a rather unpleasant email exchange and forgot
about it. I've removed it now.

> =A0 I kind of ran through my comments pretty quickly so let me repeat
> them here so they don't get lost:
>
> =A0 - like the TLS 1.0 to historic, I think this draft should be BCP

Ben said this might not be the best example and was an excepion in the
process? I'm also not sure if a BCP can have IANA Considerations ?

> =A0 - make the title ikev1-to-historic, get rid of cutesy name

That is really only in the draft name, not the title. The title is:

 	Deprecation of IKEv1 and obsoleted algorithms

I'm fine changing the draft name to draft-ipsecme-ikev1-algo-to-historic
and the title to "Moving IKEv1 and obsoleted algorithms to Historic"

> =A0 - remove all the subjective opinion in section 3-- all the "high
> =A0=A0=A0 chance" or "most likely" or "quite often" etc-- and just mention
> =A0=A0=A0 that anything IKEv1 can do IKEv2 can do better, and that the
> =A0=A0=A0 reasons to do IKEv1 in the past-- PQ and labeled IPsec-- are
> =A0=A0=A0 no longer legit due to the advancement of the relevant drafts


It would be nice to keep some of the justifications in there.  I can
look at rephrasing it a bit.

> =A0 - I don't think deprecating the registries is necessary if the
> =A0=A0=A0 RFC goes to historic, as you note, there's been no work on IKEv1
> =A0=A0=A0 for over a decade so leaving the registries alone will not be
> =A0=A0=A0 some backdoor way of sneaking in IKEv1 changes. Other orgs are
> =A0=A0=A0 using the repository so just deprecating is not right.

I thought it would just be a stronger signal to implementers, but if
there are practical concerns, like people still shoehorning things in
there then it can be removed from this document. As Tero said, those
registries cannot really be populated with new stuff without involving
the WG, so we can just count on our regular IKEv1 change pushbacks.

> =A0 - If you're gonna reject any DH groups then reject the weak ones,
> =A0=A0=A0 it doesn't make sense to do 1 and 22 and leave 2 and 5 (and 23
> =A0=A0=A0 and 24!) alone.

DH updates should be done in RFC 8247bis. This document only obsoleted
the algorithms that either had no specifiction to begin with, or have
been stuck in MAY because no one cares about them.

> It didn't look like there was any opposition to adopting this so
> just consider these as comments on the draft as adopted.

Will do, thanks!

Paul

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread]