Re: [dane] Network errors ARE attacks - on the end-to-end-principle

Martin Rex <mrex@sap.com> Wed, 16 May 2012 09:43 UTC

Return-Path: <mrex@sap.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D1321F86C3 for <dane@ietfa.amsl.com>; Wed, 16 May 2012 02:43:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.092
X-Spam-Level:
X-Spam-Status: No, score=-10.092 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 hDLOVT-+Rg9S for <dane@ietfa.amsl.com>; Wed, 16 May 2012 02:43:45 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id B85E221F870B for <dane@ietf.org>; Wed, 16 May 2012 02:43:44 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q4G9hYPP026460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 May 2012 11:43:34 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201205160943.q4G9hXOJ017665@fs4113.wdf.sap.corp>
To: gnu@toad.com (John Gilmore)
Date: Wed, 16 May 2012 11:43:33 +0200 (MEST)
In-Reply-To: <201205160213.q4G2DGcF017008@new.toad.com> from "John Gilmore" at May 15, 12 07:13:16 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: dane@ietf.org
Subject: Re: [dane] Network errors ARE attacks - on the end-to-end-principle
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 May 2012 09:43:49 -0000

John Gilmore wrote:
> 
> > But it's better then disabling TLSA at all in the face
> > of DNS errors (where we assume most errors are genuine network errors
> > and not attacks).
> 
> "Genuine network errors" from buggy proxies or intentional firewalls
> or intentional or accidental censorship systems ARE attacks.  They are
> attacks on the fundamental end-to-end premise of the Internet.

Where have you been during the last 10 years?
There is no such thing an a "fundamental end-to-end premise" on the
Internet.  And if it ever existed, it ceased to exist ~10 years ago.
(and for good, because it would entirely preclude privacy).


> 
> The Internet changed all that, making it clear what a huge benefit the
> public could derive from a system that delivered end-users' data
> end-to-end, unmodified, from anywhere, to anywhere.

That is not the case here.  Telco's providing Internet Access for
mobile devices regulary block traffic to VoiP providers _and_
regularly prevent your smartphone or tablet from forwarding
IP datagrams to other devices ("tethering") unless you pay extra.


>
> Or shipping buggy DNS proxies that mess up Port 53 UDP traffic in
> their subnet.  Most users didn't notice, which allowed the providers
> to often get away with censoring the ones who did notice.

You seem to be unaware of the IETF full Standard "STD-13"

   http://tools.ietf.org/html/std13#section-2.3.4

Those DNS proxies are perfectly Standards-compliant.

Maybe the IETF should come around to merging contents of later documents
with STD-13 and work this successor through document maturity levels to
full standard in order to replace the *CURRENT* STD-13, similar to what
has been done with 821->2821->5321 and 822->2822->5322, so that when
implementations of the *current* STD-13 in the installed base have
died off, one can start complaining about non-support of DNSSEC.


-Martin