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
- Re: https at ietf.org Eric Burger
- https at ietf.org Tim Bray
- Re: https at ietf.org Joe Abley
- Re: https at ietf.org David Morris
- Re: https at ietf.org Paul Wouters
- Re: https at ietf.org Joe Abley
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org Dean Willis
- Re: https at ietf.org Tim Bray
- Re: https at ietf.org Joe Abley
- Re: https at ietf.org Hector Santos
- Re: https at ietf.org Marco Davids (Prive)
- Re: https at ietf.org Hector Santos
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org Yoav Nir
- Re: https at ietf.org Måns Nilsson
- Re: https at ietf.org Eric Burger
- Re: https at ietf.org Dave Cridland
- Re: https at ietf.org Thiago Marinello
- Re: https at ietf.org Bjoern Hoehrmann
- Re: https at ietf.org John C Klensin
- Re: https at ietf.org John C Klensin
- Re: https at ietf.org Ted Lemon
- authentication without https (was Re: https at ie… Dave Crocker
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org ned+ietf
- Re: authentication without https (was Re: https a… Ted Lemon
- Re: https at ietf.org MAISONNEUVE, JULIEN (JULIEN)
- Re: https at ietf.org Eric Burger
- Re: https at ietf.org Marco Davids (Prive)
- Re: https at ietf.org Yoav Nir
- Re: https at ietf.org Måns Nilsson
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org Carsten Bormann
- Re: https at ietf.org Ted Lemon
- Re: https at ietf.org Carsten Bormann
- Re: https at ietf.org Måns Nilsson
- Re: https at ietf.org Måns Nilsson
- Re: https at ietf.org t.p.
- Re: https at ietf.org Dave Cridland
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Arturo Servin
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org Noel Chiappa
- Re: https at ietf.org Dave Cridland
- Re: https at ietf.org Chris Inacio
- Re: https at ietf.org Noel Chiappa
- Re: https at ietf.org Tim Bray
- Re: https at ietf.org Tim Bray
- Re: https at ietf.org Yoav Nir
- Re: https at ietf.org t.p.
- Re: https at ietf.org Noel Chiappa
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Chris Inacio
- Re: https at ietf.org Martin Rex
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org ned+ietf
- Re: https at ietf.org Martin Rex
- Re: https at ietf.org Ted Lemon
- Re: https at ietf.org Måns Nilsson
- Re: https at ietf.org Ted Lemon
- Re: https at ietf.org Douglas Otis
- Re: https at ietf.org Pranesh Prakash
- Re: https at ietf.org Pranesh Prakash
- Re: https at ietf.org Martin Rex
- Re: https at ietf.org Dave Cridland
- Re: https at ietf.org John R Levine
- Re: https at ietf.org Ted Lemon
- Re: https at ietf.org Eric Burger
- Re: https at ietf.org Joe Abley
- Re: https at ietf.org Ted Lemon
- Re: https at ietf.org Joe Abley
- Coercion S Moonesamy
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Ted Lemon
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Ted Lemon
- Re: https at ietf.org John Levine
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Michael Richardson
- Reconstruct the key S Moonesamy
- Re: https at ietf.org Randy Bush
- Re: https at ietf.org Randy Bush
- Re: https at ietf.org Joe Abley
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Sean Turner
- Re: https at ietf.org Phillip Hallam-Baker
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Phillip Hallam-Baker
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Doug Barton
- Re: https at ietf.org Doug Barton
- Re: [IETF] https at ietf.org Warren Kumari
- Re: [IETF] https at ietf.org Michael Richardson
- Re: https at ietf.org Phillip Hallam-Baker
- Re: https at ietf.org David Conrad
- Re: https at ietf.org Doug Barton
- Re: https at ietf.org Phillip Hallam-Baker
- Re: https at ietf.org Doug Barton
- Re: https at ietf.org Phillip Hallam-Baker
- Re: https at ietf.org Mark Andrews
- Re: https at ietf.org Phillip Hallam-Baker
- Re: https at ietf.org John C Klensin
- Re: https at ietf.org Doug Barton
- Re: https at ietf.org Phillip Hallam-Baker
- Re: https at ietf.org Douglas Otis