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:48 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 618E33A0B50 for <tls@ietfa.amsl.com>; Mon, 30 Nov 2020 05:48:11 -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 XJRnD_A_s6VJ for <tls@ietfa.amsl.com>; Mon, 30 Nov 2020 05:48:09 -0800 (PST)
Received: from implementers.org (implementers.org [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A11D3A0B4E for <tls@ietf.org>; Mon, 30 Nov 2020 05:48:09 -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) client-signature RSA-PSS (2048 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 42F3FAE21E; Mon, 30 Nov 2020 14:48:05 +0100 (CET)
To: "Olle E. Johansson" <oej@edvina.net>
Cc: Eric Rescorla <ekr@rtfm.com>, 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> <ee7f584b-810e-a5ab-6e50-6d6558329a54@petit-huguenin.org> <650AF155-7433-4C35-BFCD-1B6E08999158@edvina.net>
From: Marc Petit-Huguenin <marc@petit-huguenin.org>
Message-ID: <dbadd699-44b8-73f6-c8f6-ce04ff4dd855@petit-huguenin.org>
Date: Mon, 30 Nov 2020 05:48:03 -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: <650AF155-7433-4C35-BFCD-1B6E08999158@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/hJT_2a6VTQIeYDXkwHh5TnfjqC4>
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:48:11 -0000

On 11/30/20 5:43 AM, Olle E. Johansson wrote:
> 
> 
>> On 30 Nov 2020, at 14:35, Marc Petit-Huguenin <marc@petit-huguenin.org> wrote:
>>
>> 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.
> 
> So in your world, any device implementing TLS 1.0 will not be "SIP compliant" after the publication
> of this document. Nice.

Yes.

> 
> This confusion will of course apply to all other specifications updated by this document - and that’s
> quite a lot.
> 
> /O
> 


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