Re: [therightkey] Basically, it's about keeping the CAs honest

Phillip Hallam-Baker <hallam@gmail.com> Thu, 16 February 2012 13:01 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: therightkey@ietfa.amsl.com
Delivered-To: therightkey@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A0D21F877C for <therightkey@ietfa.amsl.com>; Thu, 16 Feb 2012 05:01:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.382
X-Spam-Level:
X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlJNe05s2JM7 for <therightkey@ietfa.amsl.com>; Thu, 16 Feb 2012 05:01:35 -0800 (PST)
Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD1E21F8735 for <therightkey@ietf.org>; Thu, 16 Feb 2012 05:01:34 -0800 (PST)
Received: by obbwd15 with SMTP id wd15so3434507obb.31 for <therightkey@ietf.org>; Thu, 16 Feb 2012 05:01:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PkjllBcKIMHAEaJrMBXdWXe2saGGXXNk5HpgRdq8Wwc=; b=D0E0/8UYS+13bnyfcIiNk6XdPrsMLKqrij2G6vRMBMwhbIdtxt208x5pxbAx+M7+Lj lX9pwMNBNoNmSF9sgDOJ4kSfPLbh9s6CJftmk80bVXK2ZKdy74rbi5lKVNFqOu7covpS zaPaBJOqEIydt573UoVdQ//M9KyQ2zhH2Y5Vs=
MIME-Version: 1.0
Received: by 10.182.75.102 with SMTP id b6mr1902635obw.9.1329397294143; Thu, 16 Feb 2012 05:01:34 -0800 (PST)
Received: by 10.182.75.138 with HTTP; Thu, 16 Feb 2012 05:01:33 -0800 (PST)
In-Reply-To: <201202160524.q1G5ON2p003570@fs4113.wdf.sap.corp>
References: <gym9r33x3m8ydl4xwbjezwJv4X.penango@mail.gmail.com> <201202160524.q1G5ON2p003570@fs4113.wdf.sap.corp>
Date: Thu, 16 Feb 2012 08:01:33 -0500
Message-ID: <CAMm+Lwg0HAVrCQby-7WmLhvh1yeWZ7Lq0-uWiVkO5xQGR4QQGw@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: mrex@sap.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: nico@cryptonector.com, therightkey@ietf.org, adam@cypherspace.org, Kyle Hamilton <aerowolf@gmail.com>
Subject: Re: [therightkey] Basically, it's about keeping the CAs honest
X-BeenThere: therightkey@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <therightkey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/therightkey>, <mailto:therightkey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/therightkey>
List-Post: <mailto:therightkey@ietf.org>
List-Help: <mailto:therightkey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/therightkey>, <mailto:therightkey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Feb 2012 13:01:40 -0000

The purpose of the IETF is to support USERS

USERS !

Not designers.

So the stated design goals have to be taken with a pinch of salt. They
are almost always wrong. Presenting them as immutable statements of
permanent truth is bogus.

TLS and SSH are the only IETF security protocols thus far that have
not turned out to be technical triumphs but deployment failures. It is
really easy for someone to push for a technical perfection that makes
the protocol undeployable or unusable.


Here we are all agreed that it is generally a bad thing for there to
be this particular hole. That is not the issue. The issue is whether
ignoring the fact that there are regulatory requirements for this
capability and not supporting them results in a better or a worse
outcome for users.

So far the evidence suggests that refusal to consider them has
resulted in a worse outcome.






On Thu, Feb 16, 2012 at 12:24 AM, Martin Rex <mrex@sap.com> wrote:
> Kyle,
>
> Kyle H wrote:
>>
>> We MUST permit every use of our protocols.  We MUST describe the
>> computational processes and we MUST define the intended semantics,
>> but we MUST NOT try to sabotage anything that the standards'
>> implementors or consumers try to do.  If we do, we're overstepping
>> the bounds of what authority we can legitimately claim as standards
>> designers.
>
> We seem to be talking about completely different protocols.
>
> *I* am talking about TLS (any version), which has the clearly stated
> design goal:
>
>  http://tools.ietf.org/html/rfc2246
>
>   Abstract
>
>   This document specifies Version 1.0 of the Transport Layer Security
>   (TLS) protocol. The TLS protocol provides communications privacy over
>   the Internet. The protocol allows client/server applications to
>   communicate in a way that is designed to prevent eavesdropping,
>   tampering, or message forgery.
>
>  http://tools.ietf.org/html/rfc5246
>
>   Abstract
>
>   This document specifies Version 1.2 of the Transport Layer Security
>   (TLS) protocol.  The TLS protocol provides communications security
>   over the Internet.  The protocol allows client/server applications to
>   communicate in a way that is designed to prevent eavesdropping,
>   tampering, or message forgery.
>
>
> What these MITM proxies are doing is _completely_and_thoroughly_
> subverting the entire purpose of the TLS protocol.  They're doing
> it not by exploiting weaknesses in the TLS protocol itself
> (at least prior to rfc5746), but instead, by exploiting a long-standing
> fatal design flaw in the security in the existing TLS X.509 PKI trust model.
>
> Those who want a protocol for encrypted communication that can be
> arbitrarily MITMed should design themselves such a protocol.
> Expecting the IETF to support continued exploitation of a serious
> weakness in a security architecture that is the exact opposite of
> its stated design goal is inappropriate for the IETF.
>
>
> -Martin
> _______________________________________________
> therightkey mailing list
> therightkey@ietf.org
> https://www.ietf.org/mailman/listinfo/therightkey



-- 
Website: http://hallambaker.com/