Re: Transparency in Specifications and PRISM-class attacks

John C Klensin <> Fri, 20 September 2013 14:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B6DF21F9A57 for <>; Fri, 20 Sep 2013 07:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.557
X-Spam-Status: No, score=-103.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7KPh2A07WMf1 for <>; Fri, 20 Sep 2013 07:34:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1352321F9A3D for <>; Fri, 20 Sep 2013 07:34:47 -0700 (PDT)
Received: from [] ( by with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <>) id 1VN1nB-000HTU-Aw; Fri, 20 Sep 2013 10:34:45 -0400
Date: Fri, 20 Sep 2013 10:34:40 -0400
From: John C Klensin <>
To: Ted Lemon <>, Harald Alvestrand <>
Subject: Re: Transparency in Specifications and PRISM-class attacks
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: IETF Discussion Mailing List <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Sep 2013 14:34:54 -0000

--On Friday, September 20, 2013 10:15 -0400 Ted Lemon
<> wrote:

> On Sep 20, 2013, at 9:12 AM, Harald Alvestrand
> <> wrote:
>> From the stack I'm currently working on, I find the ICE spec
>> to be convoluted, but the SDP spec is worse, becaue it's
>> spread across so many documents, and there are pieces where
>> people seem to have agreed to ship documents rather than
>> agree on what they meant. I have not found security
>> implications of these issues.
> This sort of thing is a serious problem; people do make
> efforts to address it by writing online guides to protocol
> suites, but this isn't always successful, and for that matter
> isn't always done.   We could certainly do better here.


Based in part on experience with the specs of, and discussions
in, other standards bodies, the problem with guides (online or
not) is 

(1) They may contain errors and almost always have omissions.
The latter are often caused by the perfectly good intention of
simplifying things and making them understandable by covering
only the important cases.

(2) If they are comprehensible and the standard is not, people
tend to refer to them and not the standard.  That ultimately
turns them into the "real" standard as far as the marketplace is
concerned.   FWIW, the same problem can, and has, happened with
good reference implementations.

I don't know of any general solution to those problems, but I
think the community and the IESG have got to be a lot more
willing to push back on a spec because it is incomprehensible or
contains too many options than has been the case in recent years.