Re: [Patient] [saag] Internet Draft posted as requested -

Melinda Shore <> Mon, 18 December 2017 19:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A462712D870 for <>; Mon, 18 Dec 2017 11:32:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8jumTqp4hBGO for <>; Mon, 18 Dec 2017 11:32:51 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8619212D86B for <>; Mon, 18 Dec 2017 11:32:47 -0800 (PST)
Received: by with SMTP id q20so9557366pgv.2 for <>; Mon, 18 Dec 2017 11:32:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=hyJKGCJCVpBVM0RU+KTR7ao7VK8Nilat0DUbB1cp+RI=; b=A1cfPNT2kGctOzqwz/fqE5nswFoGAERSSwqjO0pppPg3X0mXXpg84cjRsNS2utBt8a z7OgXw1f/QjMWlh4p4Plkm2QZwtgYcr7OSRboHbp7jm4iwykKc4YN+N9VQwg/0Ni3BtQ 2jibgCHnCieUswJ8/v6WxrnZhHBbZXd3OC4hF2+LJw44UkF9IZHkDnT6Hi6uTSVC091K /biA6Vrh+vuz5KcVSwQ1PfN2ahi5BtObC6livlGAHRP1VVWk2nLNFbCQV5F4MN02AvIU s4f9r8qjrmabSTGkzcV7b5/FemDuPIgOTAEnkBN6JRDCFKC9dewV6DMr9xwyaFd+EPF3 uy4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=hyJKGCJCVpBVM0RU+KTR7ao7VK8Nilat0DUbB1cp+RI=; b=P86vNZSb6n5owkgklR9cWwOG2jpZ4LZeOLHp94seY1tT+zswgSH5S+nmITZDVo9ixs 2ijJvWq5ke7ANNrccSK2bXBVljtSVTf6NDq11O48gusWEmW3D/UDQjUAttGMWFgEmryL 2+9AMuArpWmCJlL/wxfohvrhmiJKEFC9gF+6VlIQR3QDkMWaword5bunkwPtEZfgY/zV 1EzzJMIbGVQ9rGuESExlAFWvbOz9QwC3KdvzvS557nYBFhLwf6hnzoRHykmSjbHM1q+J ObbyMzRwcuXAUsU2EYPNUUiVX87ia2A7FTDcchpGKUHChDOBOu39DXOEvaPkVzMyH+Hm wSEQ==
X-Google-Smtp-Source: ACJfBotHKszbaaLX1F5Q/5TWML8w/3i7ELNkmI/QNSZoaXsJonWEUh8tPwIIM0oBcUnmuBUgom0Y2g==
X-Received: by with SMTP id j125mr644985pgc.241.1513625566722; Mon, 18 Dec 2017 11:32:46 -0800 (PST)
Received: from aspen.local ( []) by with ESMTPSA id y79sm25550974pfb.113.2017. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Dec 2017 11:32:45 -0800 (PST)
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Melinda Shore <>
Message-ID: <>
Date: Mon, 18 Dec 2017 10:32:43 -0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="e1itlc1155ipuLG6puHQJVviivMMAwgS0"
Archived-At: <>
Subject: Re: [Patient] [saag] Internet Draft posted as requested -
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Protecting against Attacks Tunneling In Encrypted Network Tunnels <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Dec 2017 19:32:52 -0000

On 12/18/17 10:15 AM, Paul Wouters wrote:
> I also detect a culture clash where I see a lot of praise to proponents
> and opponents without technical backing. At the IETF, we try to
> reach consensus based on technical merit, for example by stating you
> agree or disagree with certain items and why, and don't do "me too"
> messages to get a count.

Right, this is not how we do consensus.  Consensus is not voting
without formal votes.

At any rate I'm not sure that business models and technical decisions
are that cleanly separable.  We've decided, for example, that the
IETF is not going to develop "walled garden" technologies, and so

This particular discussion is one we've been having for several
decades.  When the problem of getting encrypted session signaling
(i.e. VoIP) protocols through firewalls and NATs came up there
was a similar tension between what people concerned about application
security wanted and what middlebox vendors wanted, since middlebox
vendors had established a lot of value in their products and
were concerned that moving application logic outside of the
middlebox (through a middlebox signaling protocol) would undermine
that value.  There were proposals for session key sharing at that
time but the IETF made the decision that this was terrible security
practice and instead took an approach that ultimately didn't get
any traction because middlebox vendors wouldn't implement it.

So, we've been here before.  That said, I think the decision not
to share session keys was a sound one at that time and remains
a sound one today.  We can't avoid having business model impacts,
and the work being brought to the IETF typically reflects someone's
business needs, but I do think we can continue to draw firm lines
around clearly unsound security practices.


Software longa, hardware brevis

PGP fingerprint: 795A 714B CD08 F996 AEFE
                 AB36 FE18 57E9 6B9D A293