This specification adds = new secure algorithms to be used with the Digest mechanism to authenticate users. The obsolete MD5 algorithm remains only for backward compatibility with [RFC2617], but its use is NOT RECOMMENDED. This opens the system to the potential for a downgrade attack by an on-path attacker. The most effective way of dealing with this type of attack is to either validate the client and challenge it accordingly or remove the support for backward compatibility by not supporting MD5. See Section 5 of [RFC7616] for a detailed security = discussion of the Digest Access Authentication scheme.
I = suggest that we get rid of MD5 and select *ONE* algorithm, sha-512, to = select somethingOn 10 Mar 2021, at 21:36, Brian Rosen <br@brianrosen.net> = wrote:MD5 is insecure, full = stop, for any current application. Base RFC3261 uses MD5 and does = not allow any other digest algorithm.RFC8760 update RFC3261 to support = SHA-256. Actually what it does is allow negotiation of the digest = algorithm, and specifically allows MD5, SHA-256, and SHA-512 to be = negotiated.There really isn=E2=80=99t any defensible reason to support = MD5. It=E2=80=99s insecure. But nearly the entire universe = of SIP only supports MD5 today.It was suggested to mandate support of = RFC8760. The issue is whether to mandate support for ONLY SHA-256 = or higher (meaning not allow MD5 to be used).RFC8760 says = this:This specification adds = new secure algorithms to be used with the Digest mechanism to authenticate users. The obsolete MD5 algorithm remains only for backward compatibility with [RFC2617], but its use is NOT RECOMMENDED. This opens the system to the potential for a downgrade attack by an on-path attacker. The most effective way of dealing with this type of attack is to either validate the client and challenge it accordingly or remove the support for backward compatibility by not supporting MD5. See Section 5 of [RFC7616] for a detailed security = discussion of the Digest Access Authentication scheme.We don=E2=80=99t really have a = way to validate the client; the algorithm is used for digest = authentication!So what do we want to do?
On 10 Mar 2021, at 22:08, Brian Rosen <br@brianrosen.net> = wrote:We=E2=80=99re still having discussions on IPv6 mandatory to = support.
ISTM that since some very = important systems are IPv6 only, and most ISPs are supporting both, that = it=E2=80=99s hard to not require support for it. In the meeting = Adam discussed using gateways and 4-in-6 support. We need to = decide what to do. I point out that many SBCs are capable of being = a fully functional B2BUA and media relay with IPv4 or IPv6 on either = side. Since it already rewrites addresses for both signaling and = media it has no issues supporting IPv6 on one side and IPv4 on the other = side. I am checking on support for IPv6 addresses in US = auditing/reporting CDRs and will report my findings shortly. I = would like to just require both sides to support IPv6, without saying = how.
Other thoughts?