IETF Logo Mail Archive

Re: Spin bit decision

Benjamin Kaduk <bkaduk@akamai.com> Tue, 02 October 2018 15:24 UTC

Return-Path: <bkaduk@akamai.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517F41310DA for <quic@ietfa.amsl.com>; Tue, 2 Oct 2018 08:24:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 43DKMNfXv0YL for <quic@ietfa.amsl.com>; Tue, 2 Oct 2018 08:24:19 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 8A38C130FCD for <quic@ietf.org>; Tue, 2 Oct 2018 08:24:14 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w92FM4ii019561; Tue, 2 Oct 2018 16:24:06 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=ae7l5/e926Qy2kkDdDT8W8RWt29qjTLIq3U0I7gSBrY=; b=Py4iJaNbbTw4v9cIXv1PdaSxXu3tzWzDadYXstyF/VPs3h+wk0Pc1Cbz19z3uy8P4bBj DGwEBM2SKKBYdYbM7rEU5oWrAVIvIXzWNUMGoanQnOPpymRR353OoqTiwwghh3UFrQUO A+3i/PwUmWu4L+cBh6QLHaMwVzl/QA4G4mkYPrBUOsgjGMseyontTBfmhwP67cJraMU7 k0mBF+Fb761w2FT+ChFHnuGns7Lnwwsea8mOezBc14KxCEjbpM377KIt/Z2b3i86MEvZ g8i4X0rcBgCAoFgomVPZMsnOAHL6Y6PoNP+9KvU9bRFnbF7Z2i+26PKn/eV+qXNRlLMm mw==
Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2msxfday21-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 02 Oct 2018 16:24:06 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w92FKClR027998; Tue, 2 Oct 2018 11:24:05 -0400
Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2mt4rcvwu2-1; Tue, 02 Oct 2018 11:24:05 -0400
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 1E83781760; Tue, 2 Oct 2018 15:24:05 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1g7MWq-0007JP-9x; Tue, 02 Oct 2018 10:24:04 -0500
Date: Tue, 02 Oct 2018 10:24:04 -0500
From: Benjamin Kaduk <bkaduk@akamai.com>
To: alexandre.ferrieux@orange.com
Cc: Lars Eggert <lars@eggert.org>, IETF QUIC WG <quic@ietf.org>
Subject: Re: Spin bit decision
Message-ID: <20181002152404.GP19845@akamai.com>
References: <14531_1538460420_5BB30B04_14531_237_4_c0f3a391-9897-80b0-575b-aa73edad0d52@orange.com> <9A63F295-5DC5-4992-9A9C-A98F72C8430D@eggert.org> <22440_1538469028_5BB32CA4_22440_292_2_8e00a462-2bbf-acf0-1195-74269a0c2fbd@orange.com> <3E3DBC15-FE42-47CF-AF7A-1F2597ED2390@eggert.org> <24019_1538484216_5BB367F8_24019_26_1_8e6b0d8e-78f0-56c7-e731-da2ff22cb194@orange.com> <08A9C80F-59E6-46EE-A4D4-1F78F5085CF7@eggert.org> <9737_1538485723_5BB36DDB_9737_147_1_82e0e028-b0e8-5e09-7bd5-e66db97c556a@orange.com> <E7479831-9594-444E-9545-A162E8D9B154@eggert.org> <32072_1538492813_5BB3898D_32072_266_1_8380ff40-29fe-269b-8ed7-4331c9e53f4d@orange.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <32072_1538492813_5BB3898D_32072_266_1_8380ff40-29fe-269b-8ed7-4331c9e53f4d@orange.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-02_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=695 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810020148
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-02_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=787 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810020149
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/YJCnDadtGH9qn6U2zmaLHSJe2M4>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Oct 2018 15:24:30 -0000

On Tue, Oct 02, 2018 at 05:05:12PM +0200, alexandre.ferrieux@orange.com wrote:
> On 10/02/18 16:00, Lars Eggert wrote:
> >
> >The point I can't seem to be getting across is that irrespective of what the
> >WG decides to require, there is no penalty for individual stacks at
> >deployment time (or after) to do whatever they wish, since the spin bit by
> >design has no impact on protocol operation and interop.
> 
> It is getting across, but it is a very grim view of the standardization
> process itself. Are there many examples of MUST in RFCs that turned out to
> be ignored by implementations just because they were not part of the core
> semantics and hence not enforced by other peers ?

I guess that this bit of https://tools.ietf.org/html/rfc4120 qualifies:

   Implementations of Kerberos and protocols based on Kerberos MUST NOT
   use insecure DNS queries to canonicalize the hostname components of
   the service principal names (i.e., they MUST NOT use insecure DNS
   queries to map one name to another to determine the host part of the
   principal name with which one is to communicate).

It's a local matter that the remote peer can't enforce, and "everybody"
is doing it, still.

-Ben

v2.23.0 | Report a Bug | By Email