Re: [keyassure] Objective: Restrictive versus Supplementary Models

Martin Rex <mrex@sap.com> Thu, 31 March 2011 00:24 UTC

Return-Path: <mrex@sap.com>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA7063A69AF for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 17:24:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.22
X-Spam-Level:
X-Spam-Status: No, score=-10.22 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hNL6dPXmJ87 for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 17:24:49 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id D03963A67D3 for <keyassure@ietf.org>; Wed, 30 Mar 2011 17:24:48 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p2V0QLgp023492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Mar 2011 02:26:26 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201103310026.p2V0QLQO007637@fs4113.wdf.sap.corp>
To: ekr@rtfm.com (Eric Rescorla)
Date: Thu, 31 Mar 2011 02:26:21 +0200 (MEST)
In-Reply-To: <AANLkTimbPj3iTofAo5ic7E=LS3ZtXyO5Gq=yR8fzB08d@mail.gmail.com> from "Eric Rescorla" at Mar 30, 11 10:17:47 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: keyassure@ietf.org
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Mar 2011 00:24:50 -0000

Eric Rescorla wrote:
> 
> Jay Daley <jay@nzrs.net.nz> wrote:
> >
> > Richard L. Barnes wrote:
> > >
> > > Yes, but as ekr pointed out, injecting fake DANE RRs can only
> > > cause the connection to fail, it won't result in the client
> > > connecting to a bogus server.   That's why it's RECOMMENDED
> > > instead of REQUIRED.
> >
> > That's still potentially a devastating DOS attack if done well and
> > against an important target.  Worthy of a REQUIRED for that alone.
> >
> > There is also the layer 9 interpretation issue here - if we say that
> > DANE in its entirety requires DNSSEC then that message can be shouted
> > loud and clear, reinforced and hopefully entrenched.  If we say that
> > only some parts need it then people, for entirely fallible reasons,
> > get confused, doubt DANE, can use this to attack DANE and so on.
> 
> I think this is an important consideration. However a relevant
> question for a 2119-level MUST seems to be whether we wish to have
> this data rejected if not DNSSEC signed.
> What's your view on that?

I'm much less worried about false positives resulting in DoS, which
can be more easily achieved attacking at the network layer (IP, TCP).

What worries me is the false negatives resulting from a
"successful verification" of an unsigned DANE RR.

The prerequisite for a "successful DANE validation" is that the
DANE TLSA record has been DNSSEC validated.  And my concern is that
some GUIs might get that wrong unless the spec is crystal clear
what constitutes a successful DANE validation (DNSSEC required)
and what not.

I'm OK with interpreting even an unsigned TLSA validation failure
as "something is goofy here, abort the connection", but that causes
the DANE validation result to have 3-states "good/not-obviously-bad/bad"
rather than a boolean "good/bad", and a 3-state may get mapped incorrectly
to binary UI indicators (icon present/absent).

-Martin