Re: Admission Control to the IETF 78 and IETF 79 Networks

Phillip Hallam-Baker <hallam@gmail.com> Mon, 12 July 2010 19:54 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 539B23A687E for <ietf@core3.amsl.com>; Mon, 12 Jul 2010 12:54:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.088
X-Spam-Level:
X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_40=-0.185, J_CHICKENPOX_64=0.6]
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 Js39yzVthFvR for <ietf@core3.amsl.com>; Mon, 12 Jul 2010 12:54:07 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 3B46A3A680B for <ietf@ietf.org>; Mon, 12 Jul 2010 12:54:07 -0700 (PDT)
Received: by iwn38 with SMTP id 38so5213065iwn.31 for <ietf@ietf.org>; Mon, 12 Jul 2010 12:54:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NYrD2VKHg+fG6KpMcVYvRp9FRvdZu5oUWUSI1FSaZy4=; b=hPoo/+lYmQXmg4bX7OKBZ/qesopM+J//Q0ewEC9JYtxqJ4elczaj8HJb0IpJY6FKgM JB/urK8wBa3MNMgWjvDb9GyvGnJj4vwmncdAFCjLVeAOLWA+4Z4uqRzSmEGyPnGh9/H6 fScs9INnn1Ib3Cju5T9fR2LXY+qk/VUrXjoh8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Uma7DMvkTS65NgmIZJECpLA70WH+SAynDCe56vULKiurOBnhR2+3fJWkJ1zOIqz9RJ rIJ/cgT8lC7alUwQ0EpuYWIaZLaqhpcZXfvCR+7C6YALFQe5BuPGzmse1QKAuaQexzuS /0djXmkmMr3Lm2SJGl+sOIz8ZJAokv6wKISM4=
MIME-Version: 1.0
Received: by 10.231.166.9 with SMTP id k9mr12377032iby.127.1278964455218; Mon, 12 Jul 2010 12:54:15 -0700 (PDT)
Received: by 10.231.32.8 with HTTP; Mon, 12 Jul 2010 12:54:15 -0700 (PDT)
In-Reply-To: <201007121839.o6CIdSRq011779@fs4113.wdf.sap.corp>
References: <AANLkTil357pxy8tD49Q9ds9QVlSjo9h3p3akSN9UF1XS@mail.gmail.com> <201007121839.o6CIdSRq011779@fs4113.wdf.sap.corp>
Date: Mon, 12 Jul 2010 15:54:15 -0400
Message-ID: <AANLkTimlqodEVKRhqome4LSsioEhwKYAuR_XsPBilNnd@mail.gmail.com>
Subject: Re: Admission Control to the IETF 78 and IETF 79 Networks
From: Phillip Hallam-Baker <hallam@gmail.com>
To: mrex@sap.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 13 Jul 2010 08:33:23 -0700
Cc: iljitsch@muada.com, tytso@mit.edu, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jul 2010 19:54:08 -0000

Intel got a bloody nose on that one because they were incompetent and lied.

A few weeks before the launch an Intel person told me about the serial
number scheme as a means of tracking down CPUs stolen during
distribution. Then at the launch we were told how the serial number
was going to enable a new generation of DRM systems (which it did
not). When asked the PR flacks denied the purpose was preventing
theft. Afterward I was told that the history was that some VP was
going to give a keynote and decided they needed something to announce
and so marketing repackaged the anti-theft scheme.

It was a pointless argument as every PC has at least ten unique
machine readable identifiers. From the point of view of enabling DRM
schemes, any identifier is acceptable, even if it is fairly soft and
easily changed. So the objections do not prevent the outcome they wish
to prevent while preventing outcomes that might be beneficial.

Any security scheme that is worth having is going to change the
accessibility of information. That is intrinsic to the function.



On Mon, Jul 12, 2010 at 2:39 PM, Martin Rex <mrex@sap.com> wrote:
> Phillip Hallam-Baker wrote:
>>
>> The simplest, cleanest solution to this problem is to either have a
>> device cert installed during manufacture or to employ my alternative
>> scheme designed for low performance devices that does not require them
>> to perform public key cryptography on the end point device (patent
>> pending, all rights reserved).
>
> Personally, I'm heavily opposed to an approach along these lines.
> It is a big plus that MAC addresses can be trivially changed,
> and I regularly connect with random MACs in public places.
>
> Several years ago, Intel came out with a unique identifier in their
> Pentium CPU.  The market did not take it very well, at least here
> in Europe.  I remember BIOS options to enable/disable the unique
> CPU ID, and it was disabled on all the machines I have been using
> (and AFAIK, it was disabled on all PCs distributed by my companies
> IT department).  Talking about it, I do not remember having seen such
> a bios option for many year -- may I assume that the unique identifier
> was removed from Intel CPUs entirely?
>
>
> Personally, I'm somewhat less concerned about a unique or fixed ID in
> my DSL-router.  I have only one DSL subscription with one single ISP,
> and I need to authenticate to my ISP with userid&pass -- which makes
> we wonder why should there be a unique/fixed ID in that device,
> it is absolutely unnecessary.
>
>
> -Martin
>



-- 
Website: http://hallambaker.com/