IETF Logo Mail Archive

Re: [keyassure] Objective: Restrictive versus Supplementary Models

"Richard L. Barnes" <rbarnes@bbn.com> Thu, 31 March 2011 09:13 UTC

Return-Path: <rbarnes@bbn.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 21E7C3A6919 for <keyassure@core3.amsl.com>; Thu, 31 Mar 2011 02:13:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.551
X-Spam-Level:
X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 9307jSi6KA77 for <keyassure@core3.amsl.com>; Thu, 31 Mar 2011 02:13:57 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 2F01D28C1A7 for <keyassure@ietf.org>; Thu, 31 Mar 2011 02:13:57 -0700 (PDT)
Received: from [128.89.255.123] (port=65125 helo=[130.129.17.55]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1Q5DyZ-0000Dg-9y; Thu, 31 Mar 2011 05:15:35 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <alpine.LFD.1.10.1103310340560.4460@newtla.xelerance.com>
Date: Thu, 31 Mar 2011 11:15:31 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A473B403-50A7-4A8D-973B-64142F1ECE5A@bbn.com>
References: <AANLkTik1Uzd8XSZzopBBDHywrhSjsBQYxC91BZXdkMwg@mail.gmail.com> <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> <m3pqp8fvoz.fsf@jhcloos.com> <F1AC4325-EA91-4570-A423-F14B178B3965@bbn.com> <alpine.LFD.1.10.1103310340560.4460@newtla.xelerance.com>
To: Paul Wouters <paul@xelerance.com>
X-Mailer: Apple Mail (2.1082)
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
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 09:13:58 -0000

>>> If the attacker injects fake dns records pointing to a fake server, they
>>> can include a dane rr.  It only makes the attack slightly harder, doesn't it?
>> 
>> 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.
> 
> Not if you are a MITM on the wire as well (more star bucks wifi use cases) and
> you're directing the user to your own website with a dane rr matching public key.

You're confusing the "Cert Lock" and "Install TA" use cases.  If all the server doing is "Cert Lock", then the bogus DANE record will simply cause the client to reject the server's cert and the connection to fail.  In the "Install TA" case, DNSSEC would be REQUIRED, for exactly the reason you note.

--Richard

v2.23.0 | Report a Bug | By Email