From thardjono@mediaone.net  Thu Aug  9 14:42:52 2001
From: thardjono@mediaone.net (Thomas Hardjono)
Date: Thu, 09 Aug 2001 09:42:52 -0400
Subject: [IETF-IDRM] [IDRM] IETF51 slides now on website
Message-ID: <5.0.0.25.2.20010809094111.018f7c88@pop.ne.mediaone.net>

Folks,

The slides from the IETF51/London IDRM meeting are now
on the website www.idrm.org.

Thank you again for all those who presented and attended.

thomas
------



From mbaugher@cisco.com  Sat Aug 11 16:13:48 2001
From: mbaugher@cisco.com (Mark Baugher)
Date: Sat, 11 Aug 2001 08:13:48 -0700
Subject: [IETF-IDRM] Re: [IDRM] IETF51 slides now on website
In-Reply-To: <5.0.0.25.2.20010809094111.018f7c88@pop.ne.mediaone.net>
Message-ID: <4.3.2.7.2.20010811081233.042a58b0@mira-sjc5-6.cisco.com>

The taxonomy presentation is at
http://www.rdrop.com/users/mbaugher/IDRMTaxonomyv1.pdf
A meeting summary is at
http://www.rdrop.com/users/mbaugher/MeetingSummary.txt

Mark
At 09:42 AM 8/9/2001 -0400, Thomas Hardjono wrote:

>Folks,
>
>The slides from the IETF51/London IDRM meeting are now
>on the website www.idrm.org.
>
>Thank you again for all those who presented and attended.
>
>thomas
>------



From thardjono@mediaone.net  Wed Aug 15 02:20:30 2001
From: thardjono@mediaone.net (Thomas Hardjono)
Date: Tue, 14 Aug 2001 21:20:30 -0400
Subject: [IETF-IDRM] [IDRM] IDRM splashes
Message-ID: <5.0.0.25.2.20010814211812.0188f678@pop.ne.mediaone.net>

Folks,

Seems IDRM made some small splashes:

slashdot:  http://slashdot.org/yro/01/08/14/1713234.shtml

and also:

URL: http://www.the451.com/index/1,1169,sectors-6-11143-3,00.html

London - At London's meeting of the Internet Engineering Task Force
(IETF),
one group of delegates tackled a problem that might at first glance seem
inimical to the freewheeling IETF's philosophy: digital rights
management.
There's obviously a demand - at least on the part of copyright owners -
for
technology that controls the way intellectual property is used. That
said,
there are plenty of companies willing to try to meet that demand - from
pure
DRM players like Reciprocal and InterTrust to language vendors like
ContentGuard, IPR Systems and now RealNetworks.





From mbaugher@cisco.com  Wed Aug 15 16:05:21 2001
From: mbaugher@cisco.com (Mark Baugher)
Date: Wed, 15 Aug 2001 08:05:21 -0700
Subject: [IETF-IDRM] Re: [IDRM] IDRM splashes
In-Reply-To: <200108150329.f7F3T6O99295@nic-naa.net>
References: <Your message of "Tue, 14 Aug 2001 21:20:30 EDT."
 <5.0.0.25.2.20010814211812.0188f678@pop.ne.mediaone.net>
Message-ID: <4.3.2.7.2.20010815080143.0264b090@mira-sjc5-6.cisco.com>

--Boundary_(ID_5pJCGJeBsdjwZMOyKHyJew)
Content-type: text/plain; format=flowed; charset=us-ascii

People have complained that the article from the451 about the idrm meeting 
is hard to find. so I asked them if we could post the article and was told 
we could - with attribution: "reproduced with permission of the451 - 
www.the451.com"

return to article
Sectors:Software:News & Analysis
Who defines digital rights management?

Rachel Chalmers GMT Aug 07, 2001, 02:05 PM | ET Aug 07, 2001, 09:05 AM | PT 
Aug 07, 2001, 06:05 AM
URL: http://www.the451.com/index/1,1169,sectors-6-11143-3,00.html

London - At London's meeting of the Internet Engineering Task Force (IETF), 
one group of delegates tackled a problem that might at first glance seem 
inimical to the freewheeling IETF's philosophy: digital rights management. 
There's obviously a demand at least on the part of copyright owners for 
technology that controls the way intellectual property is used. That said, 
there are plenty of companies willing to try to meet that demand from pure 
DRM players like Reciprocal and InterTrust to language vendors like 
ContentGuard, IPR Systems and now RealNetworks.

The IETF's angle is not concern for the sanctity of corporate property, but 
a characteristic interest in the engineering challenge of making DRM 
systems interoperate. Right now the IDRM group is in research mode, mapping 
the landscape and trying to define the IETF's role if it has one. Cisco's 
Mark Baugher, co-chair of the IDRM group, said he hopes an IETF DRM model 
will enable some kind of legal file trading.

One thing the IETF will not do, he said, is endorse tactical prevention 
measures like tamper-proof hardware or watermarks. "No one is naive enough 
to think tactical prevention measures won't be broken," he told the 
standing-room-only audience. "Lawyers say these measures are only there to 
keep the honest people honest." A better way to protect content, though, is 
to provide some kind of service that reduces the incentive to steal. 
"Technical protection measures probably have a role, but that role has been 
over hyped," Baugher argued. "You should compete on the basis of service, 
and not expect that you're going to be able to prosecute or legislate the 
problem out of existence."

Another concern is the way existing DRM systems can be used to violate user 
privacy. "The movie studios seem to be enamored of encryption technology. 
But to deliver an encrypted file, you also have to deliver a key, and the 
recipient of the key has to be authenticated, which means passing personal 
information back to the studio," he explained. "There are a lot of privacy 
implications in that. We want to address this issue, not only in the case 
of Warner Brothers and Disney and so on, but also for individuals. We want 
DRM that works on the small scale as well as on the large scale." This 
humane approach is characteristic of the IETF, but it's a pleasant surprise 
to come across it in a discussion about DRM.

Other speakers told the IETF of projects already under way. Rightscom 
consultant Niels Rump covered MPEG-21. The aim of this proposed standard is 
to enable the all-electronic creation, distribution and trade of digital 
multimedia content. Rump said the team is endeavoring to take a 
"user-centric" view. "I think it's a novel approach," he explained. In the 
DRM world, it is.

Next up was Norman Paskin, director of the International Digital Object 
Identifier Foundation. The idea behind DOI is to make a sort of 
International Standard Book Number or bar code for all digital items. The 
DOI plan builds on existing standards in this case, interoperability of 
data in e-commerce systems (indecs) and Handle, a general-purpose name 
service aimed at enabling secure name resolution over the Net. Handle is 
the brainchild of the Corporation for National Research Initiatives, the 
foundation's technical partner. "Handle is also part of the digital object 
architecture, which maps into MPEG-21 as well," Paskin pointed out.

Hence, MPEG-21 and DOI play reasonably nicely together; the rights markup 
languages that closed the session do not. Brad Gandee, ContentGuard's 
eXtensible Rights Markup Language evangelist, presented the case for this 
Xerox PARC spinoff. "XrML is criticized for being complex," he said. "Our 
answer is that it's a complex world."

By contrast, RealNetworks' shiny new eXtensible Media Commerce Language is 
frequently attacked for being too simple. Real's Rob Lanphier described 
XMCL as an open, standard language to communicate digital media business 
rules. It builds on XML and Dublin Core. "We tried not to be too clever," 
he explained. "We thought we'd take the pieces everyone can agree on, and 
standardize those."

But with the DRM landscape being what it is, even this approach provokes 
controversy. "Dublin Core is just a quick and dirty content-description 
system," the International DOI Foundation's Paskin pointed out. "It was 
never intended for DRM. I think you're in danger of inheriting the over 
simplicity of your components."

"We're not saying Dublin Core is sufficient," Lanphier protested.

Cisco's Baugher asked whether XMCL has any model for protecting user 
privacy, and when Lanphier said that the W3C's Platform for Privacy 
Preferences (P3P) already covered this area, Baugher pointed out that P3P 
is tied to browsers. DRM, he said, needs a privacy standard that is 
divorced from the browser. ContentGuard's Gandee leaped in to point out 
that privacy protection features can be added to XrML. Baugher's concern 
suggests that if the IETF does play a role in defining DRM, it will also 
serve as a watchdog for individual rights. With so many players already 
looking out for corporate interests, that's good news for anyone without a 
movie studio of their own.

--Boundary_(ID_5pJCGJeBsdjwZMOyKHyJew)
Content-type: text/html; charset=us-ascii

<html>
People have complained that the article from the451 about the idrm
meeting is hard to find. so I asked them if we could post the article and
was told we could - with attribution: &quot;reproduced with permission of
the451 - www.the451.com&quot;<br>
<br>
<font size=2>return to article <br>
Sectors:Software:<b>News &amp; Analysis</b> <br>
<b>Who defines digital rights management?<br>
<br>
</b>Rachel Chalmers GMT Aug 07, 2001, 02:05 PM | ET Aug 07, 2001, 09:05
AM | PT Aug 07, 2001, 06:05 AM <br>
URL:
<a href="http://www.the451.com/index/1,1169,sectors-6-11143-3,00.html" eudora="autourl">http://www.the451.com/index/1,1169,sectors-6-11143-3,00.html</a><br>
<br>
<b>London -</b> At London's meeting of the Internet Engineering Task
Force (IETF), one group of delegates tackled a problem that might at
first glance seem inimical to the freewheeling IETF's philosophy: digital
rights management. There's obviously a demand at least on the part of
copyright owners for technology that controls the way intellectual
property is used. That said, there are plenty of companies willing to try
to meet that demand from pure DRM players like Reciprocal and InterTrust
to language vendors like ContentGuard, IPR Systems and now RealNetworks.
<br>
<br>
The IETF's angle is not concern for the sanctity of corporate property,
but a characteristic interest in the engineering challenge of making DRM
systems interoperate. Right now the IDRM group is in research mode,
mapping the landscape and trying to define the IETF's role if it has one.
Cisco's Mark Baugher, co-chair of the IDRM group, said he hopes an IETF
DRM model will enable some kind of legal file trading. <br>
<br>
One thing the IETF will not do, he said, is endorse tactical prevention
measures like tamper-proof hardware or watermarks. &quot;No one is naive
enough to think tactical prevention measures won't be broken,&quot; he
told the standing-room-only audience. &quot;Lawyers say these measures
are only there to keep the honest people honest.&quot; A better way to
protect content, though, is to provide some kind of service that reduces
the incentive to steal. &quot;Technical protection measures probably have
a role, but that role has been over hyped,&quot; Baugher argued.
&quot;You should compete on the basis of service, and not expect that
you're going to be able to prosecute or legislate the problem out of
existence.&quot; <br>
<br>
Another concern is the way existing DRM systems can be used to violate
user privacy. &quot;The movie studios seem to be enamored of encryption
technology. But to deliver an encrypted file, you also have to deliver a
key, and the recipient of the key has to be authenticated, which means
passing personal information back to the studio,&quot; he explained.
&quot;There are a lot of privacy implications in that. We want to address
this issue, not only in the case of Warner Brothers and Disney and so on,
but also for individuals. We want DRM that works on the small scale as
well as on the large scale.&quot; This humane approach is characteristic
of the IETF, but it's a pleasant surprise to come across it in a
discussion about DRM. <br>
<br>
Other speakers told the IETF of projects already under way. Rightscom
consultant Niels Rump covered MPEG-21. The aim of this proposed standard
is to enable the all-electronic creation, distribution and trade of
digital multimedia content. Rump said the team is endeavoring to take a
&quot;user-centric&quot; view. &quot;I think it's a novel approach,&quot;
he explained. In the DRM world, it is. <br>
<br>
Next up was Norman Paskin, director of the International Digital Object
Identifier Foundation. The idea behind DOI is to make a sort of
International Standard Book Number or bar code for all digital items. The
DOI plan builds on existing standards in this case, interoperability of
data in e-commerce systems (indecs) and Handle, a general-purpose name
service aimed at enabling secure name resolution over the Net. Handle is
the brainchild of the Corporation for National Research Initiatives, the
foundation's technical partner. &quot;Handle is also part of the digital
object architecture, which maps into MPEG-21 as well,&quot; Paskin
pointed out. <br>
<br>
Hence, MPEG-21 and DOI play reasonably nicely together; the rights markup
languages that closed the session do not. Brad Gandee, ContentGuard's
eXtensible Rights Markup Language evangelist, presented the case for this
Xerox PARC spinoff. &quot;XrML is criticized for being complex,&quot; he
said. &quot;Our answer is that it's a complex world.&quot; <br>
<br>
By contrast, RealNetworks' shiny new eXtensible Media Commerce Language
is frequently attacked for being too simple. Real's Rob Lanphier
described XMCL as an open, standard language to communicate digital media
business rules. It builds on XML and Dublin Core. &quot;We tried not to
be too clever,&quot; he explained. &quot;We thought we'd take the pieces
everyone can agree on, and standardize those.&quot; <br>
<br>
But with the DRM landscape being what it is, even this approach provokes
controversy. &quot;Dublin Core is just a quick and dirty
content-description system,&quot; the International DOI Foundation's
Paskin pointed out. &quot;It was never intended for DRM. I think you're
in danger of inheriting the over simplicity of your components.&quot;
<br>
<br>
&quot;We're not saying Dublin Core is sufficient,&quot; Lanphier
protested. <br>
<br>
Cisco's Baugher asked whether XMCL has any model for protecting user
privacy, and when Lanphier said that the W3C's Platform for Privacy
Preferences (P3P) already covered this area, Baugher pointed out that P3P
is tied to browsers. DRM, he said, needs a privacy standard that is
divorced from the browser. ContentGuard's Gandee leaped in to point out
that privacy protection features can be added to XrML. Baugher's concern
suggests that if the IETF does play a role in defining DRM, it will also
serve as a watchdog for individual rights. With so many players already
looking out for corporate interests, that's good news for anyone without
a movie studio of their own. <br>
</font></html>

--Boundary_(ID_5pJCGJeBsdjwZMOyKHyJew)--


From nicko@ncipher.com  Wed Aug 15 19:47:47 2001
From: nicko@ncipher.com (Nicko van Someren)
Date: Wed, 15 Aug 2001 19:47:47 +0100
Subject: [IETF-IDRM] [IDRM] Will the DMCA make our work more difficult?
Message-ID: <3B7AC3D3.CBB5088@ncipher.com>

A very capable and well respected cryptographer, Neils Ferguson, has just
put out this essay: http://www.macfergus.com/niels/dmca/index.html
In it he states that he has come up with an efficient attack on the
High-bandwidth Digital Content Protection (HDCP) system and then goes on
to detail why he does not feel able to publish the results.  In short, his
lawyers have told him that publishing research in this area will leave him
open to both civil and criminal proceedings under the Digital Millennium
Copyright Act and, while his right to publish should be protected by the
various laws in place to protect freedoms of speech he would expect to be
made bankrupt in the process due to legal costs.

It seems that if this group is to be useful to the IETF we are going to
need to publish analysis of various DRM systems, some of which might
already be in use.  The DMCA seems likely to hamper this and it may leave
us as individuals, and the IETF, open to legal action.

Given the above, it would seem prudent to come up with a policy on how to
deal with the DMCA now, before the problem comes back in the form of a writ.

	Nicko


From thardjono@verisign.com  Wed Aug 15 20:22:15 2001
From: thardjono@verisign.com (Thomas Hardjono)
Date: Wed, 15 Aug 2001 15:22:15 -0400
Subject: [IETF-IDRM] Re: [IDRM] Will the DMCA make our work more difficult?
In-Reply-To: <3B7AC3D3.CBB5088@ncipher.com>
Message-ID: <5.0.0.25.2.20010815151515.01943c98@vhqpostal.verisign.com>

Nicko,

This issue with the DMCA is an interesting one, and one which came-up
when we were drafting the charter of the IDRM group.

Thus, if you read the fourth paragraph of the Charter, you'll see that
"IDRM will not pursue research into the legal and social issues of
DRM". We had to specifically put that line before the Charter
would be approved.

But your question about dealing with the DCMA is an interesting one.
Perhaps its something that could be brought to the larger IETF community
and the IAB/IESG.

thomas
------


At 8/15/2001||07:47 PM, Nicko van Someren wrote:
>A very capable and well respected cryptographer, Neils Ferguson, has just
>put out this essay: http://www.macfergus.com/niels/dmca/index.html
>In it he states that he has come up with an efficient attack on the
>High-bandwidth Digital Content Protection (HDCP) system and then goes on
>to detail why he does not feel able to publish the results.  In short, his
>lawyers have told him that publishing research in this area will leave him
>open to both civil and criminal proceedings under the Digital Millennium
>Copyright Act and, while his right to publish should be protected by the
>various laws in place to protect freedoms of speech he would expect to be
>made bankrupt in the process due to legal costs.
>
>It seems that if this group is to be useful to the IETF we are going to
>need to publish analysis of various DRM systems, some of which might
>already be in use.  The DMCA seems likely to hamper this and it may leave
>us as individuals, and the IETF, open to legal action.
>
>Given the above, it would seem prudent to come up with a policy on how to
>deal with the DMCA now, before the problem comes back in the form of a writ.
>
>         Nicko



From nicko@ncipher.com  Wed Aug 15 20:35:51 2001
From: nicko@ncipher.com (Nicko van Someren)
Date: Wed, 15 Aug 2001 20:35:51 +0100
Subject: [IETF-IDRM] Re: [IDRM] Will the DMCA make our work more difficult?
References: <5.0.0.25.2.20010815151515.01943c98@vhqpostal.verisign.com>
Message-ID: <3B7ACF18.F3D9FDF6@ncipher.com>

Thomas Hardjono wrote:

> This issue with the DMCA is an interesting one, and one which came-up
> when we were drafting the charter of the IDRM group.
> 
> Thus, if you read the fourth paragraph of the Charter, you'll see that
> "IDRM will not pursue research into the legal and social issues of
> DRM". We had to specifically put that line before the Charter
> would be approved.

I had read the charter, and had seen that line.  I think, however, that it
addressed a different issue.  There are clearly legal and social issues
regarding the implementation of DRM and I agree that research into these
should be outside the scope of IDRM.  That said, there is a difference
between engaging in research into the legal issues of DRM, and carrying
out DRM research that turns out to fall foul to legislation such as the
DMCA.

> But your question about dealing with the DCMA is an interesting one.
> Perhaps its something that could be brought to the larger IETF community
> and the IAB/IESG.

Indeed, my point was that we need to know how to deal with the DMCA,
rather than saying that we need to debate the rights and wrongs of the
act itself.  The act is here and IETF is not (usually) a political lobby
group.  It directly effects two out of three IEFT meetings each year and,
as Niels Ferguson describes, indirectly effects the papers that can be
submitted to the third.  I think we need a policy as to how to work
around this.

	Nicko


From mbaugher@cisco.com  Wed Aug 15 21:50:56 2001
From: mbaugher@cisco.com (Mark Baugher)
Date: Wed, 15 Aug 2001 13:50:56 -0700
Subject: [IETF-IDRM] Re: [IDRM] Will the DMCA make our work more difficult?
In-Reply-To: <3B7ACF18.F3D9FDF6@ncipher.com>
References: <5.0.0.25.2.20010815151515.01943c98@vhqpostal.verisign.com>
Message-ID: <4.3.2.7.2.20010815134250.01ed1a98@mira-sjc5-6.cisco.com>

Hi Nicko

At 08:35 PM 8/15/2001 +0100, Nicko van Someren wrote:
>Thomas Hardjono wrote:
>
> > This issue with the DMCA is an interesting one, and one which came-up
> > when we were drafting the charter of the IDRM group.
> >
> > Thus, if you read the fourth paragraph of the Charter, you'll see that
> > "IDRM will not pursue research into the legal and social issues of
> > DRM". We had to specifically put that line before the Charter
> > would be approved.
>
>I had read the charter, and had seen that line.  I think, however, that it
>addressed a different issue.  There are clearly legal and social issues
>regarding the implementation of DRM and I agree that research into these
>should be outside the scope of IDRM.  That said, there is a difference
>between engaging in research into the legal issues of DRM, and carrying
>out DRM research that turns out to fall foul to legislation such as the
>DMCA.
>
> > But your question about dealing with the DCMA is an interesting one.
> > Perhaps its something that could be brought to the larger IETF community
> > and the IAB/IESG.
>
>Indeed, my point was that we need to know how to deal with the DMCA,
>rather than saying that we need to debate the rights and wrongs of the
>act itself.  The act is here and IETF is not (usually) a political lobby
>group.  It directly effects two out of three IEFT meetings each year and,
>as Niels Ferguson describes, indirectly effects the papers that can be
>submitted to the third.  I think we need a policy as to how to work
>around this.

If we're going to investigate technical protection systems such as
HDCP, CPRM, or some vendor's implementation of an IPMP tool,
then this is a problem for us.  I never imagined IDRM will want to
do that.  Individual participants of the RG may want to do so, but
not under the auspices of IDRM.  I don't expect anyone to craft a
technical protection measure that gets embedded in some home
computing device that is invulnerable to compromise (e.g., lose one or
more secret keys).  So I don't see the point of engaging in this
kind of work.

Mark

>         Nicko



From nicko@ncipher.com  Wed Aug 15 22:24:30 2001
From: nicko@ncipher.com (Nicko van Someren)
Date: Wed, 15 Aug 2001 22:24:30 +0100
Subject: [IETF-IDRM] Re: [IDRM] Will the DMCA make our work more difficult?
References: <5.0.0.25.2.20010815151515.01943c98@vhqpostal.verisign.com>
 <4.3.2.7.2.20010815134250.01ed1a98@mira-sjc5-6.cisco.com>
Message-ID: <3B7AE88D.267C264D@ncipher.com>

Mark Baugher wrote:
...
> If we're going to investigate technical protection systems such as
> HDCP, CPRM, or some vendor's implementation of an IPMP tool,
> then this is a problem for us.  I never imagined IDRM will want to
> do that.  Individual participants of the RG may want to do so, but
> not under the auspices of IDRM.

Mark,
	Your own slides from London say that we must carry out this
sort of investigation.  You say things like "understand the landscape"
and "evolve the internet infrastructure".  How on earth can we do
these without exposing issues surrounding what's already there?  If,
for instance, XrML or XMCL had accidentally chosen to sign the wrong
parts of their message structures then the act of standing up and
saying so at an IDRM meeting could, based on the action against Prof.
Felton and USENIX, leave the IETF as liable at the person presenting.

>                              I don't expect anyone to craft a
> technical protection measure that gets embedded in some home
> computing device that is invulnerable to compromise (e.g., lose one or
> more secret keys). 

Nor do I, but is it not a goal to come up with a sound framework
into which others can insert their systems?  If so, do we not need
to understand the systems that might be fitted in?  If we find a
fundamental flaw in those third party's systems must we not say so,
so that those flaws are not perpetuated in whatever the IETF turn
into an RFC?

> So I don't see the point of engaging in this
> kind of work.

In security it does not matter if the flaw lies in the framework or
in the implementation, either way it weakens the system.  I understand
that IDRM aims are oriented towards frameworks at this stage but you
said we need to "Identify useful component technologies" and I don't
see any reliable way of doing this without pointing out the useLESS
ones.

	Nicko


From mbaugher@cisco.com  Wed Aug 15 23:13:19 2001
From: mbaugher@cisco.com (Mark Baugher)
Date: Wed, 15 Aug 2001 15:13:19 -0700
Subject: [IETF-IDRM] Re: [IDRM] Will the DMCA make our work more difficult?
In-Reply-To: <3B7AE88D.267C264D@ncipher.com>
References: <5.0.0.25.2.20010815151515.01943c98@vhqpostal.verisign.com>
 <4.3.2.7.2.20010815134250.01ed1a98@mira-sjc5-6.cisco.com>
Message-ID: <4.3.2.7.2.20010815145806.026c0ed8@mira-sjc5-6.cisco.com>

Hi Nicko
At 10:24 PM 8/15/2001 +0100, Nicko van Someren wrote:
>Mark Baugher wrote:
>...
> > If we're going to investigate technical protection systems such as
> > HDCP, CPRM, or some vendor's implementation of an IPMP tool,
> > then this is a problem for us.  I never imagined IDRM will want to
> > do that.  Individual participants of the RG may want to do so, but
> > not under the auspices of IDRM.
>
>Mark,
>         Your own slides from London say that we must carry out this
>sort of investigation.  You say things like "understand the landscape"

Either you misunderstood what I said or I misunderstood what I said.

>and "evolve the internet infrastructure".  How on earth can we do
>these without exposing issues surrounding what's already there?  If,
>for instance, XrML or XMCL had accidentally chosen to sign the wrong
>parts of their message structures then the act of standing up and
>saying so at an IDRM meeting could, based on the action against Prof.
>Felton and USENIX, leave the IETF as liable at the person presenting.

I don't think so.  At any rate, I'd rather leave DMCA issues to the EFF
and organizations that are competent in this area.  The IETF is not.


> >                              I don't expect anyone to craft a
> > technical protection measure that gets embedded in some home
> > computing device that is invulnerable to compromise (e.g., lose one or
> > more secret keys).
>
>Nor do I, but is it not a goal to come up with a sound framework
>into which others can insert their systems?  If so, do we not need
>to understand the systems that might be fitted in?  If we find a
>fundamental flaw in those third party's systems must we not say so,
>so that those flaws are not perpetuated in whatever the IETF turn
>into an RFC?

I am saying that I don't expect that we will be specifying technology
that will encounter problems in the DMCA.  Perhaps I'm wrong.
Perhaps we'll revisit this topic when we have something real to
consider.  I'm open to that.


> > So I don't see the point of engaging in this
> > kind of work.
>
>In security it does not matter if the flaw lies in the framework or

I don't think we are talking about security.  Once you put secrets on
a device and put that device in the home of a determined attacker
trying to reveal those secrets, we are no longer talking about security.

>in the implementation, either way it weakens the system.  I understand
>that IDRM aims are oriented towards frameworks at this stage but you
>said we need to "Identify useful component technologies" and I don't
>see any reliable way of doing this without pointing out the useLESS
>ones.

I don't see any problem with pointing out useless technologies.  Nor
do I see any value of describing how to alter the verance watermark
or defeat CPRM in an RFC.

If you have something you wish to publish under the auspices of IDRM
that may have DMCA issues associated with it, then please let me
know.  I don't see the point of debating this in the abstract.  What else
can we do?

thanks, Mark


>         Nicko



From mbaugher@cisco.com  Thu Aug 16 02:44:55 2001
From: mbaugher@cisco.com (Mark Baugher)
Date: Wed, 15 Aug 2001 18:44:55 -0700
Subject: [IETF-IDRM] Fwd: Re: [IDRM] Will the DMCA make our work more difficult?
Message-ID: <4.3.2.7.2.20010815184408.025c6ab8@mira-sjc5-6.cisco.com>

I used "DMCA" in this note when I meant "DMCA anti-circumvention provisions."

Mark
>Date: Wed, 15 Aug 2001 15:13:19 -0700
>To: Nicko van Someren <nicko@ncipher.com>
>From: Mark Baugher <mbaugher@cisco.com>
>Subject: Re: [IDRM] Will the DMCA make our work more difficult?
>Cc: Thomas Hardjono <thardjono@verisign.com>, ietf-idrm@lists.elistx.com
>
>Hi Nicko
>At 10:24 PM 8/15/2001 +0100, Nicko van Someren wrote:
>>Mark Baugher wrote:
>>...
>> > If we're going to investigate technical protection systems such as
>> > HDCP, CPRM, or some vendor's implementation of an IPMP tool,
>> > then this is a problem for us.  I never imagined IDRM will want to
>> > do that.  Individual participants of the RG may want to do so, but
>> > not under the auspices of IDRM.
>>
>>Mark,
>>         Your own slides from London say that we must carry out this
>>sort of investigation.  You say things like "understand the landscape"
>
>Either you misunderstood what I said or I misunderstood what I said.
>
>>and "evolve the internet infrastructure".  How on earth can we do
>>these without exposing issues surrounding what's already there?  If,
>>for instance, XrML or XMCL had accidentally chosen to sign the wrong
>>parts of their message structures then the act of standing up and
>>saying so at an IDRM meeting could, based on the action against Prof.
>>Felton and USENIX, leave the IETF as liable at the person presenting.
>
>I don't think so.  At any rate, I'd rather leave DMCA issues to the EFF
>and organizations that are competent in this area.  The IETF is not.
>
>
>> >                              I don't expect anyone to craft a
>> > technical protection measure that gets embedded in some home
>> > computing device that is invulnerable to compromise (e.g., lose one or
>> > more secret keys).
>>
>>Nor do I, but is it not a goal to come up with a sound framework
>>into which others can insert their systems?  If so, do we not need
>>to understand the systems that might be fitted in?  If we find a
>>fundamental flaw in those third party's systems must we not say so,
>>so that those flaws are not perpetuated in whatever the IETF turn
>>into an RFC?
>
>I am saying that I don't expect that we will be specifying technology
>that will encounter problems in the DMCA.  Perhaps I'm wrong.
>Perhaps we'll revisit this topic when we have something real to
>consider.  I'm open to that.
>
>
>> > So I don't see the point of engaging in this
>> > kind of work.
>>
>>In security it does not matter if the flaw lies in the framework or
>
>I don't think we are talking about security.  Once you put secrets on
>a device and put that device in the home of a determined attacker
>trying to reveal those secrets, we are no longer talking about security.
>
>>in the implementation, either way it weakens the system.  I understand
>>that IDRM aims are oriented towards frameworks at this stage but you
>>said we need to "Identify useful component technologies" and I don't
>>see any reliable way of doing this without pointing out the useLESS
>>ones.
>
>I don't see any problem with pointing out useless technologies.  Nor
>do I see any value of describing how to alter the verance watermark
>or defeat CPRM in an RFC.
>
>If you have something you wish to publish under the auspices of IDRM
>that may have DMCA issues associated with it, then please let me
>know.  I don't see the point of debating this in the abstract.  What else
>can we do?
>
>thanks, Mark
>
>
>>         Nicko



From n.paskin@doi.org  Thu Aug 16 14:24:09 2001
From: n.paskin@doi.org (Paskin, Norman (DOI-ELS))
Date: Thu, 16 Aug 2001 14:24:09 +0100
Subject: [IETF-IDRM] [IDRM] Further information on DOI
Message-ID: <97A4BBFAC1B9D211B2620008C71EF88104B660D3@ELSOXFS12305>

Further to the posting of the London IETF IDRM meeting slides, including the
presentation on DOI, you may wish to know that you can subscribe to a news
list for more information on DOI.  To do so, visit www.doi.org and click on
the "Subscribe to DOI News to receive monthly announcements" line near the
foot of the page.    We keep this to a single mailing announcement monthly,
so you will not be inundated with unwanted mail. 

There are other more specific lists of varying levels of activity  (details
are on our web page under Mauiling Lists) but the general news one will give
you a quick regular update.

Happy to answer any specific questions directly too.  Thanks for the
opportunity to talk with you in London.  

Dr Norman Paskin
Director
The International DOI Foundation
PO Box 233
Kidlington, Oxford
OX5 1XU
UK

n.paskin@doi.org
web site: http://www.doi.org
Tel: (+44) 1865 843798
Fax: (+44) 1865 843446

Administrative offices: 

US: The International DOI Foundation
c/o Blumenfeld & Cohen
1625 Massachusetts Avenue. N.W.
Suite 300
Washington, DC 20036
Tel: (+1) 202 483 4973
Fax: (+1) 202 955 6460

The International DOI Foundation
C/o International Publishers Association
3, avenue de Miremont
CH-1206 Geneva
Switzerland
Tel: (+41) 22 830 1080
Fax: (+41) 22 830 1081
 


From thardjono@verisign.com  Thu Aug 16 17:47:50 2001
From: thardjono@verisign.com (Thomas Hardjono)
Date: Thu, 16 Aug 2001 12:47:50 -0400
Subject: [IETF-IDRM] Re: [IDRM] Will the DMCA make our work more difficult?
In-Reply-To: <3B7ACF18.F3D9FDF6@ncipher.com>
References: <5.0.0.25.2.20010815151515.01943c98@vhqpostal.verisign.com>
Message-ID: <5.0.0.25.2.20010816123709.01890020@vhqpostal.verisign.com>

At 8/15/2001||08:35 PM, Nicko van Someren wrote:


>Indeed, my point was that we need to know how to deal with the DMCA,
>rather than saying that we need to debate the rights and wrongs of the
>act itself.  The act is here and IETF is not (usually) a political lobby
>group.  It directly effects two out of three IEFT meetings each year and,
>as Niels Ferguson describes, indirectly effects the papers that can be
>submitted to the third.  I think we need a policy as to how to work
>around this.
>
>         Nicko


There are many legal issues that the IETF (and other standards body) finds
easier to remain silent upon, than to address it :)

My concern is that many/most DRM systems are propietary that the vendor
will never publish all the technical details in a body like IETF (let
alone papers describing how to break them).  Thus, there is little use
in publishing how top break DRM system X if we don't even know how
the internal mechanics of system X works.


thomas
------




From thardjono@verisign.com  Thu Aug 16 18:30:05 2001
From: thardjono@verisign.com (Thomas Hardjono)
Date: Thu, 16 Aug 2001 13:30:05 -0400
Subject: [IETF-IDRM] Re: [IDRM] Will the DMCA make our work more difficult?
In-Reply-To: <3B7AE88D.267C264D@ncipher.com>
References: <5.0.0.25.2.20010815151515.01943c98@vhqpostal.verisign.com>
 <4.3.2.7.2.20010815134250.01ed1a98@mira-sjc5-6.cisco.com>
Message-ID: <5.0.0.25.2.20010816130029.01890410@vhqpostal.verisign.com>


Hi Nicko,

Let me try to explain my view of the slides at IDRM.


At 8/15/2001||10:24 PM, Nicko van Someren wrote:
>Mark Baugher wrote:
>...
> > If we're going to investigate technical protection systems such as
> > HDCP, CPRM, or some vendor's implementation of an IPMP tool,
> > then this is a problem for us.  I never imagined IDRM will want to
> > do that.  Individual participants of the RG may want to do so, but
> > not under the auspices of IDRM.
>
>Mark,
>         Your own slides from London say that we must carry out this
>sort of investigation.  You say things like "understand the landscape"
>and "evolve the internet infrastructure".

What I understand as "landscape" is the existing work that has been
published/presented in various organizations/standards-bodies,
conferences and vendor-specific events.


>How on earth can we do
>these without exposing issues surrounding what's already there?  If,
>for instance, XrML or XMCL had accidentally chosen to sign the wrong
>parts of their message structures then the act of standing up and
>saying so at an IDRM meeting could, based on the action against Prof.
>Felton and USENIX, leave the IETF as liable at the person presenting.


My understanding is that the DMCA is targeted to people who
purposely circumvent the copy-protection mechanisms in DRM-enabled
devices/systems.  Yes, granted, the lawyers can stretch it to cover
a vast reach (and they have, as in the case of Felten).
And yes, I do see you point about DMCA's reach to the point of preventing
meaningful technology development.

However, when a technology is presented at the IETF for standardization,
the assumption is that there is no IP/patent restrictions to its use.
The IETF is certainly not going to give a specification "Standards Track"
approval if the IP issues have not been clarified/resolved.
This implies that anyone can stand-up and say that something is broken
in the specification.  If a person cannot do that, then that proposed
specification will simply be thrown out of the IETF.

This is also why technologies such as HDCP and CPRM will not find its
way into the IETF.  The folks behind such technologies are typically
not open to standards over which they have no direct control.

This is also why IDRM is focusing on Infrastructure Support for DRM
systems (e.g. trust, PKIs, key management, etc) as opposed to
bit-level protection.



> >                              I don't expect anyone to craft a
> > technical protection measure that gets embedded in some home
> > computing device that is invulnerable to compromise (e.g., lose one or
> > more secret keys).
>
>Nor do I, but is it not a goal to come up with a sound framework
>into which others can insert their systems?  If so, do we not need
>to understand the systems that might be fitted in?  If we find a
>fundamental flaw in those third party's systems must we not say so,
>so that those flaws are not perpetuated in whatever the IETF turn
>into an RFC?

Well, the IDRM group can develop a framework, but the real question
is wether vendors are going to "insert their system", at which
point they will have to answer the IP issues.  If they cannot even
answer the IP issues, then DMCA will never come up as an issue (as
we would not have made it to that point).



> > So I don't see the point of engaging in this
> > kind of work.
>
>In security it does not matter if the flaw lies in the framework or
>in the implementation, either way it weakens the system.  I understand
>that IDRM aims are oriented towards frameworks at this stage but you
>said we need to "Identify useful component technologies" and I don't
>see any reliable way of doing this without pointing out the useLESS
>ones.

The notion of "component technologies" is a high-level view of the pieces
of a (open) DRM system (assuming an "open" DRM system is even possible,
where "open" means that all the mechanics are published and well-understood).

Initially IDRM is only going to focus on existing technologies in
the IETF and other open organizations.  As usual, the framework
will evolve and we will see if the notion of Infrastructure Support for DRM
is a viable concept (e.g. naming/resolution infrastructure, trust
infrastructure, etc).

Perhaps when the dust settles and enough DRM vendors get de-listed
from Nasdaq, the notion of "open standards as a good thing" will emerge
again.

thomas
------




From thardjono@mediaone.net  Fri Aug 17 15:01:18 2001
From: thardjono@mediaone.net (Thomas Hardjono)
Date: Fri, 17 Aug 2001 10:01:18 -0400
Subject: [IETF-IDRM] [IDRM] Fwd: Matt Blaze's declaration regarding the Felton DMCA case
Message-ID: <5.0.0.25.2.20010817100034.0334f7a8@pop.ne.mediaone.net>

http://www.crypto.com/papers/mab-feltendecl.txt


Grayson Barber (GB 0034)
Grayson Barber, L.L.C.
68 Locust Lane
Princeton, New Jersey 08540
(609) 921-0391

Frank L. Corrado (FLC 9895)
Rossi, Barry, Corrado & Grassi
2700 Pacific Avenue
Wildwood, NJ 08260
(609) 729-1333
Attorneys for Plaintiffs

IN THE UNITED STATES DISTRICT COURT
FOR THE DISTRICT OF NEW JERSEY

EDWARD W. FELTEN; BEDE LIU;
SCOTT A. CRAVER; MIN WU;
DAN S. WALLACH; BEN
SWARTZLANDER; ADAM
STUBBLEFIELD; RICHARD DREWS
DEAN; and USENIX ASSOCIATION,                   Hon. Garrett E. Brown, Jr.
a Delaware non-profit non-stock                 Case No. CV-01-2669 (GEB)
corporation,                                    Civil Action
          Plaintiffs

vs.                                             DECLARATION OF
                                                 MATTHEW BLAZE

RECORDING INDUSTRY ASSOCIATION
OF AMERICA, INC.; SECURE DIGITAL
MUSIC INITIATIVE FOUNDATION;
VERANCE CORPORATION; JOHN
ASHCROFT, in his official capacity as
ATTORNEY GENERAL OF THE
UNITED STATES; DOES 1 through
4, inclusive,
          Defendants.

__________________________________________________________________

I, MATTHEW BLAZE, of full age hereby declare:

1.       I am a research scientist at AT&T Laboratories, where I
study the use of cryptography in computing and network security.
I am also an Adjunct Associate Professor of Computer and Information
Sciences at the University of Pennsylvania.  This declaration is
made on my own behalf, however, and does not necessarily represent
the position of my employer or any other party.

2.      My research focuses on the architecture, design, and analysis
of secure systems and on discovering new cryptologic techniques.
A significant part of this work centers around identifying weaknesses
in existing systems and designs.

3.      I have discovered weaknesses in a number of published and
fielded security systems, including, in 1994, the protocol failure
in the U.S. Government's "Clipper" key escrow system that led to
its abandonment.

4.      In 1995, I invented the field of "trust management," a
unified approach for specifying and controlling security policy in
complex distributed systems, and I lead the KeyNote project at AT&T
Laboratories, which focuses on new trust management languages and
applications.

5.      My research has resulted in a number of  new cryptological
and security concepts, including Remotely-Keyed Encryption, Atomic
Proxy Cryptography, and Master-Key Cryptography.  Other research
I have done has been influential in network-layer encryption (for
example, I co-designed "swIPe," a predecessor of the current
encryption standard for protecting Internet traffic) and computer
file system encryption.

6.      I have testified before Congress several times on encryption
and computer security policy and have led and participated in a
number of public-policy panels and reports.  I hold a Ph.D. in
computer science from Princeton University.

7.      I am active in the review and evaluation of current and
proposed research papers in the areas of computer security and
cryptology, having served on numerous conference program committees,
having reviewed many proposed papers, and having served as a
technical journal editor.  For example, I am the program chair of
the 2002 Financial Cryptography conference, and from 1999-2000 I
was a member of the technical editorial board for the journal
Cryptologia.

8.      The study of the design of secure computing and communication
systems is necessarily a broad one, encompassing a range of
mathematical, computer science, and engineering disciplines.  This
is because security in any particular application might depend on
the soundness of many different components as well as the manner
in which these components interact with one another.  Vulnerabilities
can, and frequently do, arise from weaknesses in cryptographic
algorithms and protocols, incorrect assumptions about the nature
of attack threats, poor overall design, programming errors, operating
system bugs, human factor and user interface problems, and installation
errors, to name but a few.

9.      Unfortunately, although some advances have been made in
the use of rigorous mathematical techniques to prove and verify
the security of some aspects of a system's design, there is not
yet any systematic way to be sure that a proposed system or design
will be secure in practice.  Exploitable vulnerabilities are often
discovered in proposed designs and in systems in actual use.  Worse
still, security is often quite "fragile," in the sense that even
very small and seemingly innocuous changes to a secure design or
implementation can introduce critical and non-obvious new weaknesses
that can compromise an entire system.

10.     A significant focus of ongoing research, therefore, is and
must be concerned with evaluating real-world security systems in
an effort to discover whether they are, in fact, as secure as their
designers wish them to be.  Case studies of proposed and existing
systems and standards form the essential basis for this research.

11.     It is only by a thorough understanding of how real systems
fail in practice that we are able to develop design principles for
more secure systems in the future.  Because there are no systematic
techniques for ensuring the correctness of most aspects of secure
systems architecture, research toward discovering vulnerabilities
in systems as they are actually designed and implemented is absolutely
essential for the advancement of the field.  Scientific progress
in this discipline necessarily depends upon the exploration of
computer system weaknesses and the publication of the knowledge
learned.

12.     Research results on vulnerabilities in existing and proposed
systems can often be generalized to apply to other designs.  The
impact can be far-reaching and can sometimes mean that broad classes
of systems previously thought to be secure have to be abandoned or
re-engineered.  For example, around 1990, two Israeli scientists,
Eli Biham and Adi Shamir, discovered a technique, called "differential
cryptanalysis," that could be used, in theory, to more quickly
"break" messages encrypted under the US Government's Data Encryption
Standard.  Their technique turned out to be applicable to most of
the publicly known secret-key block cipher algorithms in existence
at the time.  The results of this research were dramatic: many
algorithms previously thought to be secure had to be abandoned,
but new algorithms were from then on designed specifically to resist
the technique.  Research leading to such results is not condemned
or discouraged for its potential short-term disruptive effect by
the scientific or academic communities.  On the contrary, such work
is universally admired and valued for its essential contribution
to our knowledge of how to design good systems.

13.     It should not be surprising, as paradoxical as it may seem
at first blush, that researchers and other scientists who study
security and privacy customarily embrace and value openness and
wide publication even of results that expose vulnerabilities.  Such
publication represents the natural advance of knowledge in a
relatively new field of scientific study.

14.     Security researchers are drawn from many different disciplines,
come from a wide range of backgrounds, and enjoy a variety of
employment situations.  Some are mathematicians, others are computer
scientists, while others come from other engineering and science
fields or from different areas entirely.  Many hold advanced degrees,
and a significant number are employed in a traditional academic
environment.  Many work in commercial and government research
laboratories, while some hold employment outside the traditional
research environment.  It is not uncommon for students and
non-academics to make significant contributions to the field.  The
set of individuals with a legitimate need to test systems for
vulnerabilities and publish their results is not at all limited to
those holding academic credentials or advanced educational or
professional status.

15.     Security researchers, like all scientific and engineering
researchers, necessarily rely on open publication of the knowledge
learned as the means for communicating with one another and for
measuring progress in the field.  Publication customarily occurs
across a variety of venues and forums, including refereed journals,
peer-reviewed conferences, workshops, public lectures, "work in
progress" talks, issuance of technical reports, and over the Internet
and email discussion groups.  Researchers are judged, and advance
professionally, largely based on their publication records.  Other
scientists depend upon having access to other researchers' results
to evaluate and build upon the existing base of knowledge.  Many
scientists have come to depend upon the Internet as a primary mode
of distribution because of its speed, low cost, and global reach.

16.     Research papers on security vulnerabilities often reveal
details as to how weaknesses might be exploited.  This is because
such papers, like all scientific publications, are expected (by
reviewers, editors, and readers) to contain enough information to
allow other scientists to duplicate, verify, and improve upon the
results presented.  The demand for rigorous and repeatable detail
is hardly specific to the security research community; indeed, this
is an essential part of the scientific method and is what allows
progress to be made and errors to be detected.  Withholding details
sufficient to allow all claims to be reproduced independently would
generally render any paper unsuitable for scientific publication,
no matter how laudable the reasons for the omission.

17.     Any prohibition of open discussion and publication of
security vulnerabilities therefore greatly harms the ability of
researchers in several areas of science and technology to function,
and indeed has a chilling effect not only on publication, but on
whether certain very important research is even done in the first
place, greatly stifling scientific advancement.

18.     Publication restrictions only encourage vulnerability
research to go overseas and underground.  Discouraging aboveboard,
open research in legitimate institutions leads to a situation where
the people who enjoy the most complete knowledge of the subject
are those working unlawfully in the underground.  Criminal
organizations already have obvious incentives to learn how to defeat
security measures.  The question is whether the open scientific
community and the public will be permitted to study, learn from,
and fix the same vulnerabilities that are visible to criminals.

19.     Provisions of the DMCA are particularly troubling here.
Despite what the drafters of the DMCA might have intended, the
practical and negative effects of the DMCA on security and cryptology
research can be far broader than one might first expect, reaching
far beyond copy protection.

20.     There are strong interrelationships among problem domains
in security, and results from across the spectrum of security
research can potentially be applied to copy protection systems.
Conversely, it is entirely possible that a study of vulnerabilities
in some copy protection system could lead to a more general result
that applies broadly to other areas of security research and that
would advance the field significantly.

21.     Because of the DMCA, I am reluctant to continue engaging
in the study of vulnerabilities in existing and proposed security
systems, despite my having previously enjoyed a number of successes
with my research in this area.  I fear that I would be unable to
publish my work in a timely and relevant manner, should any results
I discover happen to be applicable to copy protection systems.
Professor Felten's case provides a stark and worrisome example of
the chilling effect that I face since the enactment of the DMCA.

I declare under penalty of perjury that the foregoing is true and
correct and was executed at _________________on this the ___ day
of ________, 2001.

                                 ______________________________
                                 Matthew Blaze



From mbaugher@cisco.com  Sat Aug 18 00:00:51 2001
From: mbaugher@cisco.com (Mark Baugher)
Date: Fri, 17 Aug 2001 16:00:51 -0700
Subject: [IETF-IDRM] [IDRM] Fwd: RE: [DC28.4] HDCP penetrated
Message-ID: <4.3.2.7.2.20010817155926.02609610@mira-sjc5-6.cisco.com>

This may be of interest to some of us on this list.

Mark



>For further information, you can find a paper, "Four Simple Cryptographic
>Attacks on HDCP" at:
>wysiwyg://1/http://angelfire.com/realm/keithirwin/HDCPAttacks.html
>
>
> > ----------
> > From:         Mark Baugher
> > Sent:         Thursday, August 16, 2001 9:59 AM
> > To:   Robert Schumann
> > Cc:   ramizer@wmr.com; 'dc28-ca-list@smpte.vwh.net'
> > Subject:      Re: [DC28.4] HDCP penetrated
> >
> > I don't know the specifics of the HDCP compromise.  Consider a
> > hypothetical
> > example:  A particular solution has been compromised but it requires
> > millions of dollars of equipment and personnel to do so, or something of
> > that order.  I doubt that there are any solutions that will withstand an
> > attack mounted with those sorts of resources.
> >
> > I'm arguing that some criteria need to be applied because every watermark,
> >
> > tamper-resistant hardware, and tamper-resistant software implementation is
> >
> > vulnerable to compromise given the resources, say, of a government or
> > large
> > corporation.  The question is "how" and not "whether."
> >
> > Mark
> >
> > At 11:25 PM 8/15/2001 -0400, Robert Schumann wrote:
> > >While I certainly agree that any potential solution is potentially
> > >hackable/compromised (given enough time and resources) it is not clear to
> >
> > >me how it follows that it makes sense to look at solutions which have
> > >already been compromised.
> > >
> > >Rob
> > >
> > >At 06:43 PM 8/15/2001 -0700, Mark Baugher wrote:
> > >>At 04:42 PM 8/15/2001 -0700, richard mizer wrote:
> > >>>I guess this eliminates this as one of the possible solutions...
> > >>
> > >>My personal opinion is that it does not.  If we limit ourselves to
> > >>solutions that cannot be compromised, we will have no solutions
> > >>at all.  Once a device is under the control of a determined
> > >>attacker, I expect that attacker will be able to obtain its secrets.
> > >>
> > >>Mark
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>> > Amsterdam, Netherlands -- A Dutch programmer who claims to have
> > found
> > >>> > weaknesses in Intel's security technology for digital entertainment
> > >>> > content says he will not publish his findings for fear of
> > prosecution
> > >>> > under the Digital Millennium Copyright Act. Independent cryptography
> > >>> > consultant Niels Ferguson claims to have penetrated Intel's
> > >>> High-bandwidth
> > >>> > Digital Content Protection (HDCP), a specification that protects
> > >>> > copyrights by encrypting content sent in-between digital televisions
> > and
> > >>> > devices such as DVD players and digital camcorders, so that it
> > cannot be
> > >>> > copied. Ferguson said that neither Intel nor the U.S. Justice
> > Department
> > >>> > have threatened any legal action or contacted him, but that he
> > remains
> > >>> > wary because of the threats that Princeton researcher Edward Felten
> > >>> > received and programmer Dmitry Sklyarov arrest for publishing
> > information
> > >>> > on circumventing copy-protection technologies. Ferguson's website,
> > >>> > provided at a link below, further explains his argument.
> > >>> > http://www.macfergus.com/niels/dmca/index.html
> > >>> > http://www.digital-cp.com/
> > >>> >
> > >>>
> > >>>To remove yourself from this mailing list, send mail to
> > >>><Majordomo@smpte.vwh.net> with the following command in the body
> > >>>of your email message:  unsubscribe dc28-ca-list
> > >>
> > >>To remove yourself from this mailing list, send mail to
> > >><Majordomo@smpte.vwh.net> with the following command in the body
> > >>of your email message:  unsubscribe dc28-ca-list
> >
> > To remove yourself from this mailing list, send mail to
> > <Majordomo@smpte.vwh.net> with the following command in the body
> > of your email message:  unsubscribe dc28-ca-list
> >
> >



From nicko@ncipher.com  Sat Aug 18 02:37:28 2001
From: nicko@ncipher.com (Nicko van Someren)
Date: Sat, 18 Aug 2001 02:37:28 +0100
Subject: [IETF-IDRM] Re: [IDRM] Fwd: RE: [DC28.4] HDCP penetrated
References: <4.3.2.7.2.20010817155926.02609610@mira-sjc5-6.cisco.com>
Message-ID: <3B7DC6D8.22DA7AE1@ncipher.com>

I think there are two points being missed in the discussion below.  One
is that the attack on HDCP is swift and total; acording to Neils the
attack takes a couple of weeks if you have four modern PCs to hand, and
the result is that you then have the whole thing wide open and can
compromise any given source at will.  Thus I feel that this attack takes
HDCP out of the running.

The second issue is related; HDCP was fatally flawed from the start by
using encryption based on common secrets.  Thus the fact that the system
has a perfectly decent rights revocation system does you no good since
the attacker does not just get to clone a single device that he has
broken, he can fake any device he wishes.  If the system were designed
using decent public key crypto then the removal of the secret key from
one compromised device would not deal a fatal blow to the system as a whole.
The combination of public key crypto, individual keying of devices and a
devent viral revocation system should allow us to design systems that can
stand up to the successful attacks of individual devices that Robert
Schumann (below) rightly points out are inevitable.

	Nicko

Mark Baugher wrote:
> 
> This may be of interest to some of us on this list.
> 
> Mark
> 
> >For further information, you can find a paper, "Four Simple Cryptographic
> >Attacks on HDCP" at:
> >wysiwyg://1/http://angelfire.com/realm/keithirwin/HDCPAttacks.html
> >
> >
> > > ----------
> > > From:         Mark Baugher
> > > Sent:         Thursday, August 16, 2001 9:59 AM
> > > To:   Robert Schumann
> > > Cc:   ramizer@wmr.com; 'dc28-ca-list@smpte.vwh.net'
> > > Subject:      Re: [DC28.4] HDCP penetrated
> > >
> > > I don't know the specifics of the HDCP compromise.  Consider a
> > > hypothetical
> > > example:  A particular solution has been compromised but it requires
> > > millions of dollars of equipment and personnel to do so, or something of
> > > that order.  I doubt that there are any solutions that will withstand an
> > > attack mounted with those sorts of resources.
> > >
> > > I'm arguing that some criteria need to be applied because every watermark,
> > >
> > > tamper-resistant hardware, and tamper-resistant software implementation is
> > >
> > > vulnerable to compromise given the resources, say, of a government or
> > > large
> > > corporation.  The question is "how" and not "whether."
> > >
> > > Mark
> > >
> > > At 11:25 PM 8/15/2001 -0400, Robert Schumann wrote:
> > > >While I certainly agree that any potential solution is potentially
> > > >hackable/compromised (given enough time and resources) it is not clear to
> > >
> > > >me how it follows that it makes sense to look at solutions which have
> > > >already been compromised.
> > > >
> > > >Rob
> > > >
> > > >At 06:43 PM 8/15/2001 -0700, Mark Baugher wrote:
> > > >>At 04:42 PM 8/15/2001 -0700, richard mizer wrote:
> > > >>>I guess this eliminates this as one of the possible solutions...
> > > >>
> > > >>My personal opinion is that it does not.  If we limit ourselves to
> > > >>solutions that cannot be compromised, we will have no solutions
> > > >>at all.  Once a device is under the control of a determined
> > > >>attacker, I expect that attacker will be able to obtain its secrets.
> > > >>
> > > >>Mark
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>> > Amsterdam, Netherlands -- A Dutch programmer who claims to have
> > > found
> > > >>> > weaknesses in Intel's security technology for digital entertainment
> > > >>> > content says he will not publish his findings for fear of
> > > prosecution
> > > >>> > under the Digital Millennium Copyright Act. Independent cryptography
> > > >>> > consultant Niels Ferguson claims to have penetrated Intel's
> > > >>> High-bandwidth
> > > >>> > Digital Content Protection (HDCP), a specification that protects
> > > >>> > copyrights by encrypting content sent in-between digital televisions
> > > and
> > > >>> > devices such as DVD players and digital camcorders, so that it
> > > cannot be
> > > >>> > copied. Ferguson said that neither Intel nor the U.S. Justice
> > > Department
> > > >>> > have threatened any legal action or contacted him, but that he
> > > remains
> > > >>> > wary because of the threats that Princeton researcher Edward Felten
> > > >>> > received and programmer Dmitry Sklyarov arrest for publishing
> > > information
> > > >>> > on circumventing copy-protection technologies. Ferguson's website,
> > > >>> > provided at a link below, further explains his argument.
> > > >>> > http://www.macfergus.com/niels/dmca/index.html
> > > >>> > http://www.digital-cp.com/
> > > >>> >
> > > >>>
> > > >>>To remove yourself from this mailing list, send mail to
> > > >>><Majordomo@smpte.vwh.net> with the following command in the body
> > > >>>of your email message:  unsubscribe dc28-ca-list
> > > >>
> > > >>To remove yourself from this mailing list, send mail to
> > > >><Majordomo@smpte.vwh.net> with the following command in the body
> > > >>of your email message:  unsubscribe dc28-ca-list
> > >
> > > To remove yourself from this mailing list, send mail to
> > > <Majordomo@smpte.vwh.net> with the following command in the body
> > > of your email message:  unsubscribe dc28-ca-list
> > >
> > >


From mbaugher@cisco.com  Sat Aug 18 20:08:26 2001
From: mbaugher@cisco.com (Mark Baugher)
Date: Sat, 18 Aug 2001 12:08:26 -0700
Subject: [IETF-IDRM] Re: [IDRM] Fwd: RE: [DC28.4] HDCP penetrated
In-Reply-To: <3B7DC6D8.22DA7AE1@ncipher.com>
References: <4.3.2.7.2.20010817155926.02609610@mira-sjc5-6.cisco.com>
Message-ID: <4.3.2.7.2.20010818115705.026b5038@mira-sjc5-6.cisco.com>

At 02:37 AM 8/18/2001 +0100, Nicko van Someren wrote:
>i think there are two points being missed in the discussion below.  one
>is that the attack on hdcp is swift and total; acording to neils the
>attack takes a couple of weeks if you have four modern pcs to hand, and
>the result is that you then have the whole thing wide open and can
>compromise any given source at will.  thus i feel that this attack takes
>hdcp out of the running.

For what?  Digital cinema is one thing, home use is another.
One of the most pervasive protection schemes for home use today is
Macrovision, which is easily circumvented.

I raise this issue because I think that many of us are searching
for the holy grail of copy protection.  It is very difficult to say
at which point the complexity of a copy-protection solution
outweighs the benefits.  Two legal representatives
of the studio and consumer electronic industry flatly state that
technical protection measures are only intended to keep honest
people honest (http://www.linux.gr/DeCSS/imp99_3.pdf).
Simple measures will often work best for that.

Mark


>the second issue is related; hdcp was fatally flawed from the start by
>using encryption based on common secrets.  thus the fact that the system
>has a perfectly decent rights revocation system does you no good since
>the attacker does not just get to clone a single device that he has
>broken, he can fake any device he wishes.  if the system were designed
>using decent public key crypto then the removal of the secret key from
>one compromised device would not deal a fatal blow to the system as a whole.
>the combination of public key crypto, individual keying of devices and a
>devent viral revocation system should allow us to design systems that can
>stand up to the successful attacks of individual devices that robert
>schumann (below) rightly points out are inevitable.
>
>         nicko
>
>mark baugher wrote:
> >
> > this may be of interest to some of us on this list.
> >
> > mark
> >
> > >for further information, you can find a paper, "four simple cryptographic
> > >attacks on hdcp" at:
> > >wysiwyg://1/http://angelfire.com/realm/keithirwin/hdcpattacks.html
> > >
> > >
> > > > ----------
> > > > from:         mark baugher
> > > > sent:         thursday, august 16, 2001 9:59 am
> > > > to:   robert schumann
> > > > cc:   ramizer@wmr.com; 'dc28-ca-list@smpte.vwh.net'
> > > > subject:      re: [dc28.4] hdcp penetrated
> > > >
> > > > i don't know the specifics of the hdcp compromise.  consider a
> > > > hypothetical
> > > > example:  a particular solution has been compromised but it requires
> > > > millions of dollars of equipment and personnel to do so, or 
> something of
> > > > that order.  i doubt that there are any solutions that will 
> withstand an
> > > > attack mounted with those sorts of resources.
> > > >
> > > > i'm arguing that some criteria need to be applied because every 
> watermark,
> > > >
> > > > tamper-resistant hardware, and tamper-resistant software 
> implementation is
> > > >
> > > > vulnerable to compromise given the resources, say, of a government or
> > > > large
> > > > corporation.  the question is "how" and not "whether."
> > > >
> > > > mark
> > > >
> > > > at 11:25 pm 8/15/2001 -0400, robert schumann wrote:
> > > > >while i certainly agree that any potential solution is potentially
> > > > >hackable/compromised (given enough time and resources) it is not 
> clear to
> > > >
> > > > >me how it follows that it makes sense to look at solutions which have
> > > > >already been compromised.
> > > > >
> > > > >rob
> > > > >
> > > > >at 06:43 pm 8/15/2001 -0700, mark baugher wrote:
> > > > >>at 04:42 pm 8/15/2001 -0700, richard mizer wrote:
> > > > >>>i guess this eliminates this as one of the possible solutions...
> > > > >>
> > > > >>my personal opinion is that it does not.  if we limit ourselves to
> > > > >>solutions that cannot be compromised, we will have no solutions
> > > > >>at all.  once a device is under the control of a determined
> > > > >>attacker, i expect that attacker will be able to obtain its secrets.
> > > > >>
> > > > >>mark
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>> > amsterdam, netherlands -- a dutch programmer who claims to have
> > > > found
> > > > >>> > weaknesses in intel's security technology for digital 
> entertainment
> > > > >>> > content says he will not publish his findings for fear of
> > > > prosecution
> > > > >>> > under the digital millennium copyright act. independent 
> cryptography
> > > > >>> > consultant niels ferguson claims to have penetrated intel's
> > > > >>> high-bandwidth
> > > > >>> > digital content protection (hdcp), a specification that protects
> > > > >>> > copyrights by encrypting content sent in-between digital 
> televisions
> > > > and
> > > > >>> > devices such as dvd players and digital camcorders, so that it
> > > > cannot be
> > > > >>> > copied. ferguson said that neither intel nor the u.s. justice
> > > > department
> > > > >>> > have threatened any legal action or contacted him, but that he
> > > > remains
> > > > >>> > wary because of the threats that princeton researcher edward 
> felten
> > > > >>> > received and programmer dmitry sklyarov arrest for publishing
> > > > information
> > > > >>> > on circumventing copy-protection technologies. ferguson's 
> website,
> > > > >>> > provided at a link below, further explains his argument.
> > > > >>> > http://www.macfergus.com/niels/dmca/index.html
> > > > >>> > http://www.digital-cp.com/
> > > > >>> >
> > > > >>>
> > > > >>>to remove yourself from this mailing list, send mail to
> > > > >>><majordomo@smpte.vwh.net> with the following command in the body
> > > > >>>of your email message:  unsubscribe dc28-ca-list
> > > > >>
> > > > >>to remove yourself from this mailing list, send mail to
> > > > >><majordomo@smpte.vwh.net> with the following command in the body
> > > > >>of your email message:  unsubscribe dc28-ca-list
> > > >
> > > > to remove yourself from this mailing list, send mail to
> > > > <majordomo@smpte.vwh.net> with the following command in the body
> > > > of your email message:  unsubscribe dc28-ca-list
> > > >
> > > >



From brunner@nic-naa.net  Thu Aug 23 15:25:53 2001
From: brunner@nic-naa.net (Eric Brunner-Williams in Portland Maine)
Date: Thu, 23 Aug 2001 10:25:53 -0400
Subject: [IETF-IDRM] [IDRM] Ads depricated
Message-ID: <200108231425.f7NEPrN30915@nic-naa.net>

No adverts please, and no MSword doc attachments either (please).

TiA,
Eric


From thardjono@mediaone.net  Thu Aug 23 15:34:47 2001
From: thardjono@mediaone.net (Thomas Hardjono)
Date: Thu, 23 Aug 2001 10:34:47 -0400
Subject: [IETF-IDRM] Apologies -- Re: [IDRM] Ads depricated
In-Reply-To: <200108231425.f7NEPrN30915@nic-naa.net>
Message-ID: <5.0.0.25.2.20010823103329.03551c58@pop.ne.mediaone.net>

Apologies, Eric.

That was me who explicitly pressed the OK button.
Usually I do not let through spam or other non-related material.

Again, apologies.

thomas
------



At 8/23/2001||10:25 AM, Eric Brunner-Williams in Portland Maine wrote:
>No adverts please, and no MSword doc attachments either (please).
>
>TiA,
>Eric