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

"Vishwas Manral" <vishwas.ietf@gmail.com> Tue, 04 March 2008 16:01 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 EA17628C699; Tue, 4 Mar 2008 08:01:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.666
X-Spam-Level:
X-Spam-Status: No, score=-0.666 tagged_above=-999 required=5 tests=[AWL=-0.229, 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 k1gi4ccpjvCB; Tue, 4 Mar 2008 08:01:48 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FEE128C5AF; Tue, 4 Mar 2008 08:00:39 -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 1F1913A6A80 for <sidr@core3.amsl.com>; Tue, 4 Mar 2008 08:00:38 -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 4YT2aqvaEKEN for <sidr@core3.amsl.com>; Tue, 4 Mar 2008 08:00:32 -0800 (PST)
Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.188]) by core3.amsl.com (Postfix) with ESMTP id D3A4328C650 for <sidr@ietf.org>; Tue, 4 Mar 2008 07:59:50 -0800 (PST)
Received: by gv-out-0910.google.com with SMTP id i36so740773gve.15 for <sidr@ietf.org>; Tue, 04 Mar 2008 07:59:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=CmQsPS+7OVCXoNo+J60mpvILcChLxXb+NhnMeHI2lvk=; b=jcJfV5qLYSAxUxNQcbdDYz18jN51Xze08qMi/8gxwlYHRbCSpaKYQRrHv0XiMhOg4rr5MxMSuHBLBUWzSB4in93oh0SRTRXs6kFHQJHZeud23WbVwDkPZLlYZJD0/xYdgqGyDYdq8/N00MmYwHCd/DZbAhZn9XITQ5ojWQs1BKM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=E9pdqV2PF5xqwmb1B5BSyZKIBXv3B40ESj8lSWe1WnPbDbpvg55gD4VQbZAOvie5CrdCZ0/R0Yf7rZnUHNopl1tLzqtmitVvj14e5GxhEQmkz3DLffhO8q/5cTLvu4YNaVnmRUIrkpuwLdpV2+l4VXgAnJxG7Ua5MtqdpEuSHmE=
Received: by 10.142.156.2 with SMTP id d2mr539564wfe.219.1204646379295; Tue, 04 Mar 2008 07:59:39 -0800 (PST)
Received: by 10.143.164.14 with HTTP; Tue, 4 Mar 2008 07:59:39 -0800 (PST)
Message-ID: <77ead0ec0803040759p4fad1726m9e175625a13d04a6@mail.gmail.com>
Date: Tue, 04 Mar 2008 07:59:39 -0800
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Joe Abley <jabley@ca.afilias.info>
In-Reply-To: <6AAD8CE4-1A16-4C8D-A883-EC5D4D80D2FD@ca.afilias.info>
MIME-Version: 1.0
Content-Disposition: inline
References: <47C4E38E.1070105@bogus.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> <6AAD8CE4-1A16-4C8D-A883-EC5D4D80D2FD@ca.afilias.info>
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

Hi Joe,

If you saw the mail exchange between Sandra and I, you will notice she
mentioned the reason they have to go ahead with SIDR even though we
have tools available from RIPE. What I have been trying to do is to
figure out weaknesses. in the current infrastructure to get a secure
behavior. As a first step I found out this weakness and updated RIPE/
Daniel about the same.

As we discussed earlier SIDR does not provide a totally secure
infrastructure. The point here is that SIDR is giving some very basic
improvements in the security, generally in the non-malicious case. The
idea is can we get a similar security with the current infrastructure,
by doing minor improvements. There is a certain cost involved with the
SIDR infrastructure.

I do not think the SSL channel has not been done because it is
unnecessary. I guess there hasn't been an attack on that side of the
infrastructure yet, but these are well known issues/ attacks in other
fields.

Thanks,
Vishwas

On Tue, Mar 4, 2008 at 7:43 AM, Joe Abley <jabley@ca.afilias.info> wrote:
>
>  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