IETF Logo Mail Archive

Re: [Lurk] Lurk: new undetectable backdoor possibility?

"Fossati, Thomas (Nokia - GB)" <thomas.fossati@nokia.com> Thu, 30 June 2016 12:06 UTC

Return-Path: <thomas.fossati@nokia.com>
X-Original-To: lurk@ietfa.amsl.com
Delivered-To: lurk@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 182B112D5CD for <lurk@ietfa.amsl.com>; Thu, 30 Jun 2016 05:06:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmC2OFjoi6aV for <lurk@ietfa.amsl.com>; Thu, 30 Jun 2016 05:06:07 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A8A12D5D2 for <lurk@ietf.org>; Thu, 30 Jun 2016 05:06:05 -0700 (PDT)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 5595E7848CA5F; Thu, 30 Jun 2016 12:06:01 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u5UC63ai007732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Jun 2016 12:06:03 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u5UC60I7007198 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jun 2016 14:06:02 +0200
Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.136]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 30 Jun 2016 14:04:15 +0200
From: "Fossati, Thomas (Nokia - GB)" <thomas.fossati@nokia.com>
To: Dmitry Belyavsky <beldmit@gmail.com>, LURK BoF <lurk@ietf.org>
Thread-Topic: [Lurk] Lurk: new undetectable backdoor possibility?
Thread-Index: AQHR0rmF/E3KuzcL5UutnC++hlajU6AB2MwA
Date: Thu, 30 Jun 2016 12:04:14 +0000
Message-ID: <D39AC438.6B266%thomas.fossati@alcatel-lucent.com>
References: <CADqLbzJfoW2Ta5wUKi35CAn97MoGsDAVkVWSyUu-iEgocA_=qA@mail.gmail.com>
In-Reply-To: <CADqLbzJfoW2Ta5wUKi35CAn97MoGsDAVkVWSyUu-iEgocA_=qA@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.5.160527
x-originating-ip: [135.239.27.38]
Content-Type: multipart/alternative; boundary="_000_D39AC4386B266thomasfossatialcatellucentcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lurk/Nl71a7WUUWdfzSjGGsAgfNbmtyI>
Subject: Re: [Lurk] Lurk: new undetectable backdoor possibility?
X-BeenThere: lurk@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Limited Use of Remote Keys <lurk.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lurk>, <mailto:lurk-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lurk/>
List-Post: <mailto:lurk@ietf.org>
List-Help: <mailto:lurk-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lurk>, <mailto:lurk-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jun 2016 12:06:09 -0000

Hi Dmitry

I think I found a new undetectable LURK-specific backdoor possibility.

The (government-related) attacker installs an extra frontend server and redirects a victim DNS requests to it.

The only thing the attacker needs from the key owner to perform this attack is a certificate to make the attacker's frontend server capable to send requests and obtain responses from the key server.

The attack described does not cause the Key owner's key compromise and does not require to issue a bogus certificate for the Key owner's domain. So if I am not mistaken, the attack is technically undetectable if the Key owner agrees to provide such a possibility.

Please correct me if I am wrong.

Is it an attack on the protocol if you need to collude with the Key owner to run it successfully?

Cheers, t

v2.23.0 | Report a Bug | By Email