Subject: [sipcore] Update for 3261

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 28 Apr 2020 09:59:22 +0200

Just FYI

I discovered that https://tools.ietf.org/id/draft-ietf-tls-oldversions-deprecate-02.html aim to update 3261 and a lot of other RFCs.

This means that SIP-compliant implementations will have to deprecate TLS 1.0, 1.1 and earlier versions.

The UTA wg is also upgrading their BCP for TLS, which means that TLS 1.3 will be the recommended version (if their plans go through).

Cheers,
/O

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Apr 2020 08:08:12 +0000

Hi,
    
>  This means that SIP-compliant implementations will have to deprecate TLS 1.0, 1.1 and earlier versions.
  
This has been discussed on an IETF level before, and I don't think what you say is true. 

Just because RFC YYYY updates RFC XXXX, it doesn't mean that implementations of RFC XXXX will suddenly become non-compliant unless it implement RFC YYYY. Such implementations are still compliant to RFC XXXX. 

Implementations that are also compliant to RFC YYYY need to explicitly indicate so: "Application Z is compliant to RFC XXXX and RFC YYYY."

Regards,

Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 28 Apr 2020 10:12:03 +0200

> On 28 Apr 2020, at 10:08, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> Implementations that are also compliant to RFC YYYY need to explicitly indicate so: "Application Z is compliant to RFC XXXX and RFC YYYY.”

That’s interesting. Thanks for the feedback. So what’s the point of “Updating an RFC” and the references?

/O

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Apr 2020 08:24:01 +0000

Hi,

>> Just because RFC YYYY updates RFC XXXX, it doesn't mean that implementations of RFC XXXX will suddenly become non-compliant
>> unless it implement RFC YYYY. Such implementations are still compliant to RFC XXXX. 
>> 
  
The reason you update specs is normally because you improve aspects of the protocol, whether it's the protocol itself, the security mechanisms it uses etc. Often it makes sense to implement the updates, but not doing so does not mean that you suddenly become non-compliant.

Regards,

Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 28 Apr 2020 10:34:45 +0200

> On 28 Apr 2020, at 10:24, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

So in order to really upgrade SIP we need to write a replacement that makes 3261 obsolete? 

/O

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Apr 2020 08:39:25 +0000

Hi,
 
   >> The reason you update specs is normally because you improve aspects of the protocol, whether it's the protocol itself, the
   >> security mechanisms it uses etc. Often it makes sense to implement the updates, but not doing so does not mean that you suddenly become non-compliant.
   > 
    
   You can start writing a 3261bis draft, that would eventually obsolete 3261. But, that would still not make 3261-compliant implementations non-compliant. Sure, they would be compliant to an obsoleted    specification, but they would still be compliant :)

   Regards,

   Christer

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 28 Apr 2020 11:04:16 +0200

> On 28 Apr 2020, at 10:39, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
I agree that it’s actually more unclear than I thought.

Check https://tools.ietf.org/id/draft-kuehlewind-update-tag-02.txt <https://tools.ietf.org/id/draft-kuehlewind-update-tag-02.txt> for a discussion and a proposal to fix the “updated by” meta data tags. I don’t know where that’s going,
but it documents the confusion.

/O