Re: [Sidr] [OPSEC] pccw as17557 leak...

Joe Abley <jabley@ca.afilias.info> Tue, 04 March 2008 15:43 UTC

Return-Path: <sidr-bounces@ietf.org>
X-Original-To: ietfarch-sidr-archive@core3.amsl.com
Delivered-To: ietfarch-sidr-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B09F928C536; Tue, 4 Mar 2008 07:43:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.806
X-Spam-Level:
X-Spam-Status: No, score=-0.806 tagged_above=-999 required=5 tests=[AWL=-0.369, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
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 7fReXdDE+tWC; Tue, 4 Mar 2008 07:43:43 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008B528C481; Tue, 4 Mar 2008 07:43:40 -0800 (PST)
X-Original-To: sidr@core3.amsl.com
Delivered-To: sidr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48FBE28C116; Tue, 4 Mar 2008 07:43:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 r+xFREIN-mHx; Tue, 4 Mar 2008 07:43:34 -0800 (PST)
Received: from monster.hopcount.ca (monster.hopcount.ca [199.212.90.4]) by core3.amsl.com (Postfix) with ESMTP id CFDEA3A6D2E; Tue, 4 Mar 2008 07:43:33 -0800 (PST)
Received: from [199.212.90.17] (helo=yxu1a17.hopcount.ca) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68 (FreeBSD)) (envelope-from <jabley@ca.afilias.info>) id 1JWZIY-000B37-Tu; Tue, 04 Mar 2008 15:43:23 +0000
Message-Id: <6AAD8CE4-1A16-4C8D-A883-EC5D4D80D2FD@ca.afilias.info>
From: Joe Abley <jabley@ca.afilias.info>
To: Vishwas Manral <vishwas.ietf@gmail.com>
In-Reply-To: <77ead0ec0803040736t55871ebex445e6fe31d6ac129@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Tue, 04 Mar 2008 10:43:21 -0500
References: <47C4E38E.1070105@bogus.com> <Pine.WNT.4.64.0802281259530.2416@SANDYM-LT.columbia.ads.sparta.com> <77ead0ec0802281056y2862d71dt8b753f5f3f3b0df9@mail.gmail.com> <77ead0ec0802281102o3e2efedl479ff6351dca0f63@mail.gmail.com> <Pine.WNT.4.64.0802281604190.2416@SANDYM-LT.columbia.ads.sparta.com> <77ead0ec0803020837s16bccee8ledbc9ae1bb60e117@mail.gmail.com> <7C9DBE28-7B7A-4053-85AE-4B954FFEEC57@ca.afilias.info> <77ead0ec0803040714v4235cff2u65bd247694e30570@mail.gmail.com> <5B7F4259-8CAB-4895-8F26-8BFD0CE7C56B@ca.afilias.info> <77ead0ec0803040727n24b68e0fm5650e8fb6c1b1dc@mail.gmail.com> <77ead0ec0803040736t55871ebex445e6fe31d6ac129@mail.gmail.com>
X-Mailer: Apple Mail (2.919.2)
Cc: opsec wg mailing list <opsec@ietf.org>, sidr@ietf.org
Subject: Re: [Sidr] [OPSEC] pccw as17557 leak...
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sidr-bounces@ietf.org
Errors-To: sidr-bounces@ietf.org

On 4-Mar-2008, at 10:36, Vishwas Manral wrote:

> To further explain it. In my view SSL is the right protocol for this
> kind of transaction (we could use IPSec with BTNS too though). As the
> idea is to get the information from the right server, the client
> itself could be any one.

That seems like a feasible band-aid over the deficiencies of the  
existing service, although it's clearly no panacea. It also has the  
practical problem that existing scripts that use whois would need  
modification, although the whois "protocol" and client are so trivial  
that it would presumably be straightforward for someone to implement a  
change to the (say) BSD client to implement an SSL wrapper with server- 
side certificate verification.

Allowing the integrity of the data itself to be trusted (e.g. using  
the resource certification work) seems like a more appropriate  
direction than worrying about the security of data retrieval, though,  
which perhaps explains why SSL-wrapping whois has not already been  
done by anybody.


Joe

_______________________________________________
Sidr mailing list
Sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr