Re: [tsvwg] Protocol ossification in draft-ietf-tsvwg-transport-encrypt-07.txt

Tom Herbert <> Tue, 09 July 2019 23:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C08D1200F6 for <>; Tue, 9 Jul 2019 16:17:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.602
X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ny9cp1TUALKp for <>; Tue, 9 Jul 2019 16:17:05 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F33C3120075 for <>; Tue, 9 Jul 2019 16:17:04 -0700 (PDT)
Received: by with SMTP id k8so114425eds.7 for <>; Tue, 09 Jul 2019 16:17:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=cHMuWr7T61a2o5h/HCxi8x4HxUVZvgn18HvH/1s5vrU=; b=AoXcJCuod2tagyPcKdduikXpQkXGpyqCTvfZvCHZ/Ind+uJUghJM+88mnTr6+VrCTK VdOCFo+1moKeUNckJ7ifTPh/oVFDx1nUNOL73/M67sqzvMKF5mwtZgtXpwNe8jAC/7Kf 1jyy5mJ/8h+K73SSnljRNcK2Tk/RubNbG3XC+kjJegsV9X0qDObOsimQRFKRLj4gKJ00 2iOEMH5K6ZXeXFym+aTe562EPN7d1g6Z83+UpzhwV6rhn7ZZ/L+kaFI7ZjBh6iKiP07T qncXbwGvVggfSlU6Ye7Ll1fmD5ItJcpFCGRTLl7MZiLRs+r5CGX85jJz3fXAt32SIK8T SejA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=cHMuWr7T61a2o5h/HCxi8x4HxUVZvgn18HvH/1s5vrU=; b=Ogb0p54N9kN66wYo+WrZa7+hDC57mLx9tutujtC31IMtbigT05MTN8tyRqfz092KI3 Mpuk7GZbM/YkN0pf7YeoCxTRuWehN/NJ5q951QkKfrLvbc8nN8OBYAfvuFV1K9R0n4Uh 9m4kYSflyfYng8ZHoXyQsTlHnet2aY1sAT4mgZG1eyG8UB0OORgz40njypkoch3kl+N2 5Pqx8C+x29foD2/nSPMlHw2l2XVuR1isX6uzePxbrBENA0xssH9mDLFQuAnvcUB24zNd ArMxCHyXeb2+kczqguimAfW94iFmbSn7gxNVz+OQGNWVrmX2bw0Cxn9+X72F2WAJWe5f zvMQ==
X-Gm-Message-State: APjAAAUrVS0oNRBOdTWRCZPiUU8mSLF9h1A7MSQUZKrgBWKhkl80i0ys mwIN6v4Rx8v6DC9tLnrIaFRMe9Cqj+Mzw4+ry0AFfGa1aSs=
X-Google-Smtp-Source: APXvYqxmRd/ENilqwuX23CR6Y6gD0+4njG3JG+TenHtgPDIOCunJH9MYfSc/SyLr+NSwpM2eGx5kZI5nnmlHe4VRQeI=
X-Received: by 2002:a17:906:fcb8:: with SMTP id qw24mr23639671ejb.239.1562714223360; Tue, 09 Jul 2019 16:17:03 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Tue, 9 Jul 2019 16:16:51 -0700
Message-ID: <>
To: Colin Perkins <>
Cc: Joe Touch <>, tsvwg <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [tsvwg] Protocol ossification in draft-ietf-tsvwg-transport-encrypt-07.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Jul 2019 23:17:06 -0000

On Tue, Jul 9, 2019 at 3:35 PM Colin Perkins <> wrote:
> On 9 Jul 2019, at 05:35, Joe Touch <> wrote:
> On Jul 8, 2019, at 8:05 AM, Tom Herbert <> wrote:
> "A reliance on the presence and semantics of specific header
> information  leads to ossification…"
> Relying on the semantics of a protocol header is also called a standard.
> “...In some case this could be benign or advantageous to
> the protocol”
> I am dubious about any statement that protocol ossification of
> transport layer by middleboxes is a good thing.
> Ossification and stability are two sides of exactly the same coin.
> It’s called ossification when the variation of a standard is no longer supported, e.g., because of middleboxes assumptions beyond that defined by the standard.
> It’s called stability when we can rely on a set of definitions that constrain arbitrary variation in controlled ways.
> Exactly.
> We might choose to declare certain properties of a protocol as invariant, because we want a stable substrate on which others can build, including middlebox vendors. That is, we might choose to intentionally accept and encourage ossification, because we believe the benefits of stability for those features outweigh the benefits of flexibility.


Who is "we" in this description? Is this is IETF or an open community
that has diligently evaluated the effects of ossification of some
feature and has achieved consensus that too much flexibility in a
protocol was a mistake; or is it random vendors or network operators
that decide what they support per their convenience or that of their
marketing department with the side effect that the Internet is driven
to support only the least common denominator of protocols and protocol

> The problem is not ossification as such. It’s ossification of things that we intended to be changeable.
Not sure I see the difference. In any case, the irony of this
discussion is that ossification of the transport layer by middleboxes
is precisley a major motivation driving encryption the transport
layer. E.g. a principle of QUIC protocol design is "Beyond the obvious
privacy benefits, encryption prevents ossification of the protocol by
middleboxes, which can't make routing decisions based on information
they can't understand." I doubt that a one-off statement that
ossification could be a good thing will much effect on those building
new transport protocols for widescale deployment. For that matter, I'm
still doubtful that any of the purported benefits listed in the draft
are sufficient rationale to convince any transport layer and
application developers not to encrypt the transport layer.


> --
> Colin Perkins