Re: https at ietf.org

Douglas Otis <doug.mtview@gmail.com> Wed, 11 December 2013 06:26 UTC

Return-Path: <doug.mtview@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5761AE20E for <ietf@ietfa.amsl.com>; Tue, 10 Dec 2013 22:26:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 L39mZ6v8GT0w for <ietf@ietfa.amsl.com>; Tue, 10 Dec 2013 22:26:46 -0800 (PST)
Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8428C1AE1E6 for <ietf@ietf.org>; Tue, 10 Dec 2013 22:26:46 -0800 (PST)
Received: by mail-pd0-f179.google.com with SMTP id r10so8870381pdi.24 for <ietf@ietf.org>; Tue, 10 Dec 2013 22:26:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cUDLXBLm3thm6GkUUpm65cWt4WheZLNAn/IINI+xixM=; b=KpfySI8PmkC/vcGgTpWqbXJkzcH+PcgvpGHW2n5OTvqHkXvQ1g6JdmEPlP07izINmb jUE5fyBtwtpsd0kyFORwSauLZWkwcSESlqyTzw/snMqEsUIqPO3MINJDI23nZlSdooti svITdVPuVlYXuTzDebZI0znBoAMNe7i22q0CHyyUpyAByEz2dT9WPzSrsxB3rlepMYzQ BSayukFOjkcOGiEcwmHpxl3T5HOpBn89TKMRKWkrD4E338gIfnmNFhQ2xaekpvATIQ11 00Te1j3kAdXPVDonY/2B0f0KjZnyonxnO1mQi+h02FpEp2VXsIgQ8jAzDI0mmqpHgSDa aS2g==
X-Received: by 10.68.113.130 with SMTP id iy2mr32254042pbb.2.1386743201064; Tue, 10 Dec 2013 22:26:41 -0800 (PST)
Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id qv8sm30070821pbc.31.2013.12.10.22.26.38 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Dec 2013 22:26:39 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Subject: Re: https at ietf.org
From: Douglas Otis <doug.mtview@gmail.com>
In-Reply-To: <E4EC4C3190EA749BAE7898DF@JcK-HP8200.jck.com>
Date: Tue, 10 Dec 2013 22:26:36 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <B3A14601-CDEB-4529-B142-80AF252ACE3B@gmail.com>
References: <20131125180608.55454.qmail@joyce.lan> <E5836934-317D-4E73-80CC-B8847047852A@virtualized.org> <CAMm+LwhXb6uYJLie1FmJE34aC0EO39_t7331X1O0iD=-gmSEvw@mail.gmail.com> <38B94CB1-C62A-4BAC-85D4-B08FB7315CE9@virtualized.org> <CAMm+LwhF5-nEdM0Rjh1XtK1X=_xo6GkqPnZgfGaCEJ19g8ULrg@mail.gmail.com> <52A176E0.1050708@dougbarton.us> <CAMm+LwiH=1446tXZLKxUyz+jpMHy573aAd5zg1_+Z4kEbVc33A@mail.gmail.com> <52A52972.3020601@dougbarton.us> <CAMm+LwiHwKkK1C7K+DG-LTBS=Edsn=AjH5hCe+9LOukVZbPjmQ@mail.gmail.com> <52A64A1A.2020000@dougbarton.us> <CAMm+LwgptxAAmCxqP9g8-+EOjwapwb2PJjVvvSe=N6A79WZqXA@mail.gmail.com> <20131210005259.169F9B6E2F1@rock.dv.isc.org> <CAMm+LwhyXaOP8k8tZ6-cPrmmyXXjfgO=Jr5Jyf4S+WAZus1CWQ@mail.gmail.com> <E4EC4C3190EA749BAE7898DF@JcK-HP8200.jck.com>
To: John C Klensin <john-ietf@jck.com>
X-Mailer: Apple Mail (2.1822)
Cc: IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Dec 2013 06:26:48 -0000

On Dec 10, 2013, at 6:00 AM, John C Klensin <john-ietf@jck.com> wrote:

> While the integrity checks of DNSSEC provide some protection
> against some types of attacks on the "data quality" part of the
> DNS environment, the attacks they protect against are very
> difficult.  An attacker with the resources to apply them would
> almost certainly find it easier, less resource-expensive, and
> harder to detect to attack registry databases (before data are
> entered into DNS zones and signed), registrar practices, or
> post-validation servers.  Non-technical attacks, such as the
> oft-cited hypothetical NSL, are easily applied at those points
> as well -- much more easily than tampering with keys or
> signatures.

Dear John,

The opacity of CAs, DNS, and BGP place all forms of security at risk!  These mechanisms are never stronger than their weakest link.  Without burdensome cryptographic checking, no Internet service should be trusted.  DANE in conjunction with DNSSEC affords a much needed transparency to expose exchanges at risk.

TLS should be considered a two-way certificate exchange resolving domains rather than individuals.  For example, a federated service like email lacking two-way certificate checks can not be defended from abuse, nor can privacy of those using such a service be assured.  Transparency in the security mechanism should fully illuminate domains, not individuals.  TLS and StartTLS contain elements for two-way certificate exchange and can make a needed transition from CAs to DANE while providing a verifiable chain of trust to the controlling domain.

Of course, websites have adopted synthetic domains as an alternative for web cookies. When naughty synthetic domains are used, no amount of encryption protects individuals when metadata remains fully apparent.  Perpass documents should have included stronger statements about protecting services as apposed to suggesting shortcuts in the guise of affording privacy.  No conversation should ever be considered private without first ensuring the controlling domain at each end of the exchange.

Regards,
Douglas Otis