Re: [TLS] Missing updates in our RFCS? - what does update mean (modified topic)

Marc Petit-Huguenin <marc@petit-huguenin.org> Mon, 30 November 2020 13:35 UTC

Return-Path: <marc@petit-huguenin.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808D93A0AB8 for <tls@ietfa.amsl.com>; Mon, 30 Nov 2020 05:35:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9azvt26YZ3nZ for <tls@ietfa.amsl.com>; Mon, 30 Nov 2020 05:35:51 -0800 (PST)
Received: from implementers.org (implementers.org [92.243.22.217]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 602793A0AC5 for <tls@ietf.org>; Mon, 30 Nov 2020 05:35:50 -0800 (PST)
Received: from [IPv6:2601:648:8400:8e7d:2d7:a332:d302:a2cf] (unknown [IPv6:2601:648:8400:8e7d:2d7:a332:d302:a2cf]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 8EFC8AE21E; Mon, 30 Nov 2020 14:35:47 +0100 (CET)
From: Marc Petit-Huguenin <marc@petit-huguenin.org>
To: "Olle E. Johansson" <oej@edvina.net>, Eric Rescorla <ekr@rtfm.com>
Cc: TLS List <tls@ietf.org>
References: <CACsn0cmzJ_1u5481P4Odr=L6A6mUw5NiB4zR_mwrkdJF1dSZSA@mail.gmail.com> <C190C488-57EB-47CA-A1E3-36CD183BF1E0@edvina.net> <CABcZeBOkxh9BPN1aSHA8gVww--j7tunH+mqa5J85H9=c9ZKHaA@mail.gmail.com> <5CB58D08-19FB-4CCA-AF5A-B676AF3FC5A7@edvina.net>
Message-ID: <ee7f584b-810e-a5ab-6e50-6d6558329a54@petit-huguenin.org>
Date: Mon, 30 Nov 2020 05:35:45 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <5CB58D08-19FB-4CCA-AF5A-B676AF3FC5A7@edvina.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/z3Rl1Nf4awkgYf6hnoPnLhnReaI>
Subject: Re: [TLS] Missing updates in our RFCS? - what does update mean (modified topic)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Nov 2020 13:35:55 -0000

On 11/30/20 5:12 AM, Olle E. Johansson wrote:
> 
> 
>> On 30 Nov 2020, at 14:08, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>>
>>
>> On Sun, Nov 29, 2020 at 10:36 PM Olle E. Johansson <oej@edvina.net <mailto:oej@edvina.net>> wrote:
>>
>>
>>> On 30 Nov 2020, at 01:51, Watson Ladd <watsonbladd@gmail.com <mailto:watsonbladd@gmail.com>> wrote:
>>>
>>> Dear TLS WG,
>>>
>>> I think RFC 7627 should update 5056, 5705, and maybe a few more.
>>>
>>> I noticed these omissions when looking at the kitten draft to use TLS
>>> 1.3 exporters. Having these updates would hopefully make clear what
>>> uses need to be updated, or at least show where there might be a
>>> problem.
>>
>> On that topic I have to repeat an earlier question that I did not see any response to.
>>
>> SIP is declared in RFC 3261. This draft updates 3261. Does this mean
>> that the SIP standard is modified? To be SIP compliant, do one has to
>> follow this document too (after publication)?
>>
>> I’ve gotten a few pointers earlier that ended up with “It’s unclear what an
>> RFC update means”.
>>
>> I would really like it to mean that in order to be SIP compliant, you can not
>> use deprecated versions of TLS.
>>
>> Me too. Unfortunately, my understanding of the way things work is that there's
>> no formal thing meaning "SIP Compliant". Rather, one complies with a bunch of
>> RFCs and so people wouldn't be "RFC XXXX compliant", which isn't really what
>> is wanted here.
> 
> Ok - but does this change the meaning of being “RFC 3261” compliant?
> 
> Or do we have to say “RFC3261 compliant with the addition of RFC XXXX” where XXXX is this document?
> 
> Sorry to be picky, but I’m interested in understanding the effect of these updates to a long list of RFCs.
> 

I use the short-hand "SIP Compliant" to mean compliant with RFC3261 and the parts of the following RFCs that update RFC 3261: RFC 3265, RFC 3853, RFC 4320, RFC 4916, RFC 5393, RFC 5621, RFC 5626, RFC 5630, RFC 5922, RFC 5954, RFC 6026, RFC 6141, RFC 6665, RFC 6878, RFC 7462, RFC 7463, RFC 7621, RFC 8217, RFC 8262, RFC 8591, RFC 8760, RFC 8898.

-- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug