IETF Logo Mail Archive

Re: [TLS] Recommending ALPN / backwards compatibility

Stefan Hagen <stefan@dilettant.eu> Sat, 08 May 2021 14:53 UTC

Return-Path: <stefan@dilettant.eu>
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 2323F3A1A86 for <tls@ietfa.amsl.com>; Sat, 8 May 2021 07:53:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.115
X-Spam-Level:
X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dilettant.eu
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 3ws4dQgbRuHA for <tls@ietfa.amsl.com>; Sat, 8 May 2021 07:53:47 -0700 (PDT)
Received: from mailrelay1-3.pub.mailoutpod1-cph3.one.com (mailrelay1-3.pub.mailoutpod1-cph3.one.com [46.30.212.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753FD3A1A84 for <tls@ietf.org>; Sat, 8 May 2021 07:53:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dilettant.eu; s=20191106; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version:from: content-transfer-encoding:content-type:from; bh=6WRnjJIumhrfL9lyRciAN+Le9PM6cOeFy36TVfGN5Zg=; b=KXUXT6Z+DkoPRcc7GKLccW61ETKMwZb7LBe+Ld4Arck4bTBWOw+i03dapJbXIKLDZ+t9vTyl0GyYa bzt2iIthMWmeXURXsZPAPawSKY216IUwEafYBtdYCVZJXSA5t/XAVnswqlVrqORTSZsQYB2ONr5Fb1 4zjqpxv+XyxPseSrCPtfHR7XWnd0fWfPeGzkGHTImvaRZzbKyyH5YfLW5VsteI8fpOx+d3PcUxNtSk dOqZeiAS6bbSNFuJRDIw2iL47C4H6jyi64pz9QYQ5YoENUbQm8Hc5coAUEGIzXC9X6V5XjTgOfE1+S y7q6pYMBybQYD/jgqWEpabLHMwM+GxA==
X-HalOne-Cookie: 658ffb338f2d0e9639666244869ff7961bb12f56
X-HalOne-ID: 2dc3f22f-b00d-11eb-9251-d0431ea8a283
Received: from [192.168.1.112] (37.249.197.178.dynamic.dsl-lte-bonding.lssmb00p-msn.res.cust.swisscom.ch [178.197.249.37]) by mailrelay1.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 2dc3f22f-b00d-11eb-9251-d0431ea8a283; Sat, 08 May 2021 14:53:42 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail-FC7BEFF7-070D-4225-BC0A-1F849679EFED"
Content-Transfer-Encoding: 7bit
From: Stefan Hagen <stefan@dilettant.eu>
Mime-Version: 1.0 (1.0)
Date: Sat, 08 May 2021 16:53:40 +0200
Message-Id: <851F480E-A2D5-4B52-B2B2-20194F7BF0A1@dilettant.eu>
References: <8c1dfcad-040d-4fdc-ac25-5e4fe0b0f39b@www.fastmail.com>
Cc: tls@ietf.org
In-Reply-To: <8c1dfcad-040d-4fdc-ac25-5e4fe0b0f39b@www.fastmail.com>
To: Filippo Valsorda <filippo@ml.filippo.io>
X-Mailer: iPad Mail (18D70)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/vtSLtmeVtj9u-IAAMa8P8ffNkeA>
Subject: Re: [TLS] Recommending ALPN / backwards compatibility
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: Sat, 08 May 2021 14:53:53 -0000

> Am 08.05.2021 um 15:27 schrieb Filippo Valsorda <filippo@ml.filippo.io>:
> 2021-05-08 05:11 GMT-04:00 ml+ietf-tls@esmtp.org:
>> On Fri, Apr 30, 2021, Martin Thomson wrote::
>> [...]
>> IMHO this would be useful for backwards compatibility/ migrating a
>> protocol to support ALPN.  RFC 7301 states the server "SHALL" abort
>> in this case:
>> 
>> 3.2.  Protocol Selection
>> ...  In the event that the server supports no
>>    protocols that the client advertises, then the server SHALL respond
>>    with a fatal "no_application_protocol" alert.
>> 
>> but that might not be a good way to support migration, which probably
>> is why is just "SHALL" not "MUST"?
> 
> SHALL means MUST per RFC 2119. It's unfortunate we use a word that sounds like SHOULD to mean MUST, but that's a requirement, not a suggestion.
> 
The equivalence is true for the IETF bubble we discuss in. Outside - or in other bubbles like ISO - SHALL is a requirement on an active participant while MUST is more an environmental condition where no single responsibility is easily assigned for all cases (or that single power is outside of scope and reach for the prose).

In OASiS specs we try to either adhere to the IETF conventions and do not differentiate between SHALL and MUST or - when targeting ISO standardization beyond OASIS Standard stage adhere to the ISO terms, which may also fit the ITU/ETSI bubble terms.

I would not consider the phonetic similarity unfortunate, as long as words like too occur in the surrounding language ;-)

All the best,
Stefan

v2.23.0 | Report a Bug | By Email