IETF Logo Mail Archive

[dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application)

Ondřej Surý <ondrej.sury@nic.cz> Wed, 30 November 2011 16:59 UTC

Return-Path: <ondrej.sury@nic.cz>
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 2C13421F8BB8 for <dane@ietfa.amsl.com>; Wed, 30 Nov 2011 08:59:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.21
X-Spam-Level:
X-Spam-Status: No, score=-0.21 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3]
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 Mh2rYcEqpVzx for <dane@ietfa.amsl.com>; Wed, 30 Nov 2011 08:59:45 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6295321F8BAD for <dane@ietf.org>; Wed, 30 Nov 2011 08:59:45 -0800 (PST)
Received: from kimac.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 9AF472A2EF7 for <dane@ietf.org>; Wed, 30 Nov 2011 17:59:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1322672383; bh=Hc7lkkw2zf5jLijtWO31RhbgJ2WOSae/P6olVodAk7Y=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-Id:To:Mime-Version; b=sOw083BhxxuPs+ezcYFVNvC140Y+axws1InfcdWtsYeyLE+8pYyqtYY5QWHoFXY4L RCI/qKh7CaHITjJ91UrqsDO5FTTe72GspKbKIKWpN5kBl2vFUza4DoGlpgV0w1DVuE tdMqw/1KUvgvG1EVYw1Px+r5SzwsV/hHhr1JtDM0=
From: Ondřej Surý <ondrej.sury@nic.cz>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 30 Nov 2011 17:59:43 +0100
Message-Id: <F9351D01-9F64-4BCF-84C6-E90825A4F49C@nic.cz>
To: IETF DANE WG list <dane@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1251.1)
X-Mailer: Apple Mail (2.1251.1)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Subject: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application)
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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, 30 Nov 2011 16:59:46 -0000

Hi all,

I would like to set the working group into the motion again.
I will use the RFC4033 language (Section 2 and Section 5),
so please read that before you comment.

Let's assume that the DANE-aware application is using trusted
Validating Security-Aware Recursive Name Server.

How is that achieved is out-of-the-scope for this email (and
for the DANE protocol draft).

It seems to me that from the 'Aiming towards...' thread,
we still have a misunderstanding what should DANE-aware
application do or not do.

In particular, the call for consensus is that DANE-aware
application has to implement (at least) Non-validating
Security-aware Stub Resolver.  As we (Warren) said earlier
there were some concerns in the IESG and we have the DNSSEC
in the charter, so we have to use only Secure TLSA possitive
answers.  Also we cannot ignore the Bogus state, because
then the restrictive option (Usage type 0/1) would be vulnerable
to stripping in-path attack.

Implications:
- DANE-aware client distinguishes three DNSSEC states of the data on the input:
 + TLSA Resource Record Exists and is Secure (RFC4033 Section 5)
   (AD bit set)
 + DNS Response is Bogus
   (RCODE=SERVFAIL)
 + Everything else (catch-all rule)
- When processing it becomes:
 + TLSA Resource Record Exists
  + TLSA Resource Record Matches       => OK
  + TLSA Resource Record Doesn't Match => FAIL
 + DNS Response is Bogus               => FAIL
 + Everything else (catch-all rule)    => NO-INFO (Fallback to PKIX)
- It's harder to implement, because there is not common API for that yet.

I think we already had a quite intensive discussion on this topic,
so please only express your opinion (+1 vs. -1)

Thank you,
--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:ondrej.sury@nic.cz    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

v2.23.0 | Report a Bug | By Email