Received: by 2002:a25:2c96:0:0:0:0:0 with SMTP id s144csp206947ybs; Tue, 26 May 2020 07:19:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyvpQW9Ym1BNFWyEZBTgbs2K5rYc+Ip5QJ9DuZwc1LOgmBi6mWgfr70y/bGbvPQ9f/sqdoT X-Received: by 2002:a50:e1c5:: with SMTP id m5mr20351823edl.47.1590502741665; Tue, 26 May 2020 07:19:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590502741; cv=none; d=google.com; s=arc-20160816; b=LizEsKdtl9Je6hWJipvyMTn3kfDWGdu7pEOqN5SV8PNXGfKdXq/Tp6xpSLy7XKDmAG bzqjV8v/zhBhbgrdMZofSbfkewdM4uoCTfPSEBD6gLVNtphVNVkfiOlF6jKtDqnbQFNT IAsmp/t2MvvKm7gSE6lfONwUntzfyEXYzkr6+dSrcEf97SzNiZcyqwxGyjlO82dYrHAK tbYxQxntPCQa4O34XjFLQA17sPxYpYmsHfixOU4VzlIS02ba327MyEF4nc/DRR8AizwE r6qvDCFDJ79s0BlUDNXHuDO0ppB4pw3suZYCpDC2oPwpIY+AAAeixjLaBPjf7pT+TLgX 6CHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version; bh=DCwcnZDtc+vqTzc7okFp78i4+BhkKafbmo08GBkG75k=; b=u/oOIn6KyxD+kHnmqLivIAGlellrHYxqo2Jc/kAWudxu5+fMT5ywMJUM6T+AEsHCeq Hq+sdVw5mz4WZfbEY1UgIQG+NOnE8Z/fVRp/VeWon30TcmFSoXFA2kRsXecWutuT5XGf SvbWlyOIL9xwVtGWheYNpoHZGvyYJJniFdpb3pXEmYaJ/CYYeq6h4wpuUPjzhx53yxJ7 xmRDK54N5K+rSXLQ0s/VFiHwXsZnFhH5nQC+CyIfgQh24q7qYfkqIhbrUjFm/y9kLdyf jeQsqYkUr7k0Z9xVMti3xjqymVN3cp/ivJaMbOiNFUqjI/C//fa20YbKgF8RqAb8xzaS 2AUg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b23si1027044edx.118.2020.05.26.07.18.31; Tue, 26 May 2020 07:19:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726939AbgEZORi convert rfc822-to-8bit (ORCPT + 99 others); Tue, 26 May 2020 10:17:38 -0400 Received: from coyote.holtmann.net ([212.227.132.17]:58906 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726882AbgEZORi (ORCPT ); Tue, 26 May 2020 10:17:38 -0400 Received: from marcel-macpro.fritz.box (p4fefc5a7.dip0.t-ipconnect.de [79.239.197.167]) by mail.holtmann.org (Postfix) with ESMTPSA id A6A2ECECEF; Tue, 26 May 2020 16:27:21 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: [PATCH 2/4] Bluetooth: Fix assuming EIR flags can result in SSP authentication From: Marcel Holtmann In-Reply-To: Date: Tue, 26 May 2020 16:17:35 +0200 Cc: Luiz Augusto von Dentz , BlueZ Content-Transfer-Encoding: 8BIT Message-Id: <23C4DB2B-4C5E-45E7-A777-6F26A675EB92@holtmann.org> References: <20200519202519.219335-1-luiz.dentz@gmail.com> <20200519202519.219335-2-luiz.dentz@gmail.com> To: Alain Michaud X-Mailer: Apple Mail (2.3608.80.23.2.2) Sender: linux-bluetooth-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org Hi Alain, > Starting with the 2.1 specification, it is my interpretation that it > is not valid to support EIR but not SSP. I understand that SSP may be > disabled from BlueZ's point of view, but this doesn't seem to be a > legitimate/qualifiable configuration. Should we instead fail the > legacy pairing if EIR was received as an invalid condition? I know that using EIR requires to also use SSP. However this is just a precaution in case the other device is an attacked and tries to trick us. You might get an inquiry result and not extended inquiry result, but you are still talking to a SSP device. This has to do with the fact that the reception of EIR is not guaranteed. In case of radio interference you might miss one and only get an ordinary inquiry result. If we indeed received an EIR and then get legacy pairing request, we could try to reject the pairing. However keep in mind that our inquiry cache is time limited and we through outdated information away. This might cause some race condition. So I rather read the remote host features to ensure we know the actual host features of the remote device. Regards Marcel