Subject: Consensus snapshot, 2005/05/25

From: Tim Bray <[email-masked]>
Date: Wed, 25 May 2005 11:03:46 -0700

The level of traffic in recent days have been ferocious, and reading  
through it, we observe the WG has consensus on changing the format  
draft in a surprisingly small number of areas.  Here they are:

1. The restriction that atom:author can appear only once is removed.

2. The draft should include an explanation that if entry/author is  
absent, then all entry/source/author entries apply if there are any,  
otherwise all feed/author entries apply.

3. Change to previous consensus call.  The phrase that begins "If  
multiple atom:entry elements with the same atom:id value appear in an  
Atom Feed document, they describe the same empty..." loses the  
language about how software MUST treat them as such.

4. atom:id is a compulsory child of atom:feed (or did we already say  
that?)

5. rework the last paragraph of 4.1.3.2.  First of all, the  
description involving "text/" and "+xml" needs fixing per Thomas  
Broyer's work (see http://www.imc.org/atom-syntax/mail-archive/ 
msg15444.html), and second, the SHOULD is gone, see http:// 
www.imc.org/atom-syntax/mail-archive/msg15412.html

Have I missed any?  Yes, there has been high-volume debate on several  
other issues; but have there been any other outcomes where we can  
reasonably claim consensus exists?  -Tim

---

From: Antone Roundy <[email-masked]>
Date: Wed, 25 May 2005 12:35:56 -0600

> draft in a surprisingly small number of areas.  Here they are:

All looks good (or at least entirely acceptable) to me.  One question 

> language about how software MUST treat them as such.

A few of people appeared to support[1][2] this[0]:

* State that multiple entries originating in the same feed with the 
same atom:id are instances of the same entry [yes, they're SUPPOSED to 
be, even "REQUIRED" to be universally unique, but let's live in the 
real world]

...but there was no Pace written (oops), and little or no comment 
directed specifically toward this detail, either for or against.  This 
wording got no response when suggested[3] two days ago:

"If multiple atom:entry elements originating in the same Atom feed have 
the same atom:id value, whether they exist simultaneously in one 
document or in different instances of the feed document, they describe 
the same entry."

I'm going to write a Pace right now, in case that will make any 
difference.  Comments?

Antone

[0] http://www.imc.org/atom-syntax/mail-archive/msg15517.html
[1] http://www.imc.org/atom-syntax/mail-archive/msg15518.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg15526.html
[3] http://www.imc.org/atom-syntax/mail-archive/msg15644.html

---

From: Antone Roundy <[email-masked]>
Date: Wed, 25 May 2005 13:06:19 -0600

On Wednesday, May 25, 2005, at 12:35  PM, Antone Roundy wrote:
> difference.
Here it is--now comments on that particular detail can be directed at a 
proper Pace:

http://www.intertwingly.net/wiki/pie/PaceDuplicateIdsEntryOrigin

== Abstract ==

State the atom:entries from the same feed with the same ID are the same 
entry, whether simulateously in the feed document or not.

== Status ==

New

== Rationale ==

  * The accepted language for allowing duplicate IDs in a feed document 
speaks only multiple atom:entry elements with the same atom:id 
describing the same entry if they exist in the same document--of 
course, we intend for them to describe the same entry whether they're 
simultaneously in the feed document or not
  * The accepted language does not speak of the origin feed of the 
entries. Ideally, an atom:id should be univerally unique to one entry 
resource, and we rightly require publishers to mint them with that 
goal. However, in reality, malicious or undereducted publishers might 
duplicate the IDs of others. Therefore, it is proposed to modify the 
specification to state that the atom:entry elements describe the same 
entry (resource) if they originate in the same feed.
  * Aggregators wishing to protect against DOS attacks are not unlikely 
to perform some sort of safety checks to detect malicious atom:id 
duplication, regardless of whether the specification "authorizes" them 
to or not.

== Proposal ==

in format-08:

1. Remove this bullet point from 4.1.1:

atom:feed elements MUST NOT contain atom:entry elements with identical 
atom:id values.

2. Add the following paragraph, either to atom:entry or atom:feed, at 
the editors' discretion (instead of the first sentence proposed by 
PaceAllowDuplicateIDs, if accepted):

If multiple atom:entry elements originating in the same Atom feed have 
the same atom:id value, whether they exist simultaneously in one 
document or in different instances of the feed document, they describe 
the same entry.

== Impacts ==

  * Aggregators wishing to both perform duplicate detection and protect 
against DOS attacks will be justified by the specification in applying 
their judgement regarding whether entries with the same atom:id come 
from the same source or not.

== Notes ==

  * Because we are unlikely to agree on a method for determining whether 
the atom:entry elements originate in the same feed or not, no 
particular method will be specified.
  * The proposed language does not preclude the possibility of 
aggregators applying their own judgement regarding whether two 
atom:entry elements with the same atom:id which originate in different 
feeds might describe the same entry resource, which they might if 
someone posts the same to entry to, for example, a category feed and a 
feed of all their categories, and doesn't present one as having been 
aggregated from the other by including an atom:source element.

---

From: Graham <[email-masked]>
Date: Wed, 25 May 2005 20:20:43 +0100

On 25 May 2005, at 7:35 pm, Antone Roundy wrote:

> "If multiple atom:entry elements originating in the same Atom feed  
> have the same atom:id value, whether they exist simultaneously in  
> one document or in different instances of the feed document, they  
> describe the same entry."
>

What about when they don't? I don't see any value here. A line saying  
that when two matching entry ids found in different feeds is fine,  
but (apparently) saying it's completely meaningless goes way, way too  
far.

(Also, do we have a definition for "Atom feed" that exists beyond a  
single instance of a "feed document"?)

Graham

---

From: Eric Scheid <[email-masked]>
Date: Thu, 26 May 2005 05:32:44 +1000

> single instance of a "feed document"?)

we should have, but we don't.

similarly for "Atom Entry".

e.

---

From: Antone Roundy <[email-masked]>
Date: Wed, 25 May 2005 14:01:38 -0600

On Wednesday, May 25, 2005, at 01:20  PM, Graham wrote:
>> have the same atom:id value, whether they exist simultaneously in one 
>> document or in different instances of the feed document, they 
> that when two matching entry ids found in different feeds is fine, but 
> (apparently) saying it's completely meaningless goes way, way too far.

In my grand tradition (...I'm sure I've done this before), I've posted 
an alternative to my own proposal.  The following would legitimize 
considering more than just atom:id in doing duplicate detection in 
order to protect against DOS, but without risking anyone thinking we've 
weakened the requirement for universal uniqueness of atom:id.  I'd vote 
for this over PaceDuplicateIdsEntryOrigin, and 
PaceDuplicateIdsEntryOrigin over no change.

http://www.intertwingly.net/wiki/pie/PaceAtomIdDos

== Abstract ==

Point out the potential for denial of service by duplicating others' 
atom:id values.

== Status ==

New

== Rationale ==

  * We want atom:id to be univerally unique to a particular entry 
resource.
  * However, depending on such uniqueness could lead to denial of 
service attacks where the attacker publishes an entry with an atom:id 
value used by someone else.
  * Restricting the uniqueness scope of atom:id entirely to a single 
feed would make it much less valuable, since entries are often copied 
form feed to feed, and sometimes simultaneously published in multiple 
feeds.
  * Only requiring entries with the same atom:id to be considered the 
same if coming from the same feed, but allowing the consuming 
application to exercize judgement with respect to entries originating 
in different feeds is a much better match with reality.
  * Still, pointing out the potential for DOS attacks in the Security 
Considerations section may be preferable to loosening the scope of 
atom:id uniqueness elsewhere in the spec in either of the ways describe 
by the preceding bullet points.

== Proposal ==

Add the following to format-08:

8.5 Denial of Service Attacks

Atom Processors should be aware of the potential for denial of service 
attacks where the attacker publishes an atom:entry with the atom:id 
value of an entry from another feed, and perhaps with a falsified 
atom:source element duplicating the atom:id of the other feed. Atom 
Processors which, for example, suppress display of duplicate entries by 
displaying only one entry with a particular atom:id value or 
combination of atom:id and atom:updated values, might also take steps 
to determine whether the entries originated from the same publisher 
before considering them to be duplicates.

---

From: Walter Underwood <[email-masked]>
Date: Wed, 25 May 2005 13:38:14 -0700

--On Wednesday, May 25, 2005 11:03:46 AM -0700 Tim Bray <[email-masked]> wrote:
> reasonably claim consensus exists?

Changing atom:author to atom:creator? No objections, so far.
I paste together a PACE with the official Dublin Core definition.

Should we mention DC for atom:contributor?

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Robert Sayre <[email-masked]>
Date: Wed, 25 May 2005 16:40:35 -0400

> reasonably claim consensus exists? 

Not in my opinion. Looks good to me.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Wed, 25 May 2005 21:49:04 +0100

On 25 May 2005, at 9:01 pm, Antone Roundy wrote:

> Atom Processors should be aware of the potential for denial of  
> service attacks where the attacker publishes an atom:entry with the  
> atom:id value of an entry from another feed, and perhaps with a  
> falsified atom:source element duplicating the atom:id of the other  
> feed. Atom Processors which, for example, suppress display of  
> duplicate entries by displaying only one entry with a particular  
> atom:id value or combination of atom:id and atom:updated values,  
> might also take steps to determine whether the entries originated  
> from the same publisher before considering them to be duplicates.

How is this a "Denial of service" attack? Isn't it just ordinary  
spoofing/impersonation?

Apart from that, +1.

Graham

---

From: Antone Roundy <[email-masked]>
Date: Wed, 25 May 2005 15:05:32 -0600

> How is this a "Denial of service" attack? Isn't it just ordinary 

I don't particularly care whether we call it a DOS or something else, 
as long as we point it out and give implementers something to point to 
if asked why they're not simply accepting atom:id at face value.

But is it not potentially a DOS?  The Good Guy publishes an entry.  The 
Bad Guy copies the atom:id of that entry into an entry with different 
content, gives it a later atom:updated, and publishes it.  The 
aggregator stops publishing/displaying the Good Guy's entry and instead 
publishes/displays the Bad Guy's entry.  Thus, the subscriber doesn't 
see the Good Guy's entry (unless they saw it before it was replaced).

But you're also right--if they saw it before it was replaced and then, 
when they see the "updated" version, they think it was updated by The 
Good Guy, it becomes a spoof/impersonation.  Perhaps we should say 
"Denial of Service and Spoofing Attacks" and "...potential for denial 
of service and spoofing attacks..."?  How that's worded doesn't really 
matter to me.

---

From: Graham <[email-masked]>
Date: Wed, 25 May 2005 22:55:21 +0100

On 25 May 2005, at 10:05 pm, Antone Roundy wrote:

> But is it not potentially a DOS?  The Good Guy publishes an entry.   
> The Bad Guy copies the atom:id of that entry into an entry with  
> different content, gives it a later atom:updated, and publishes  
> it.  The aggregator stops publishing/displaying the Good Guy's  
> entry and instead publishes/displays the Bad Guy's entry.  Thus,  
> the subscriber doesn't see the Good Guy's entry (unless they saw it  
> before it was replaced).

Technically, yes, it is denial of service. But the term "Denial of  
Service" refers specifically to attacks where the main objective is  
to prevent a service being accessible. Replacing content does deny  
service, yes, but it's also a lot more than that.

Graham

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 25 May 2005 23:35:49 +0100

> reasonably claim consensus exists?  -Tim

Good summary, thank you.

cheers
Bill

---

From: James M Snell <[email-masked]>
Date: Wed, 25 May 2005 17:14:13 -0700

Please forgive me for stepping in here, because of the recent list 
volume I've only been able to partially pay attention to this 
discussion, but I just wanted to make a quick observation..

Ignoring the overhead that it adds for now, isn't this the kind of 
situation digital signatures are designed to handle?  If I put out an 
entry with a given ID and digitally sign it, and someone comes along and 
attempts to publish an entry with a duplicate ID and updated timestamp 
and it is NOT signed with the same key my original was signed with, then 
hey, Houston we've got a problem.  Without any kind of cryptographic 
guarantee of this sort, the best you could do is make an educated 
guess.  Would it make sense to include some language along these lines?

Antone Roundy wrote:

> different content, gives it a later atom:updated, and publishes it.  
> The aggregator stops publishing/displaying the Good Guy's entry and 
> instead publishes/displays the Bad Guy's entry.  Thus, the subscriber 
> doesn't see the Good Guy's entry (unless they saw it before it was 
> replaced).
>

---

From: Tim Bray <[email-masked]>
Date: Wed, 25 May 2005 17:32:40 -0700

On May 25, 2005, at 1:49 PM, Graham wrote:
>> service attacks where the attacker publishes an atom:entry with  
>> the atom:id value of an entry from another feed, and perhaps with  
>> a falsified atom:source element duplicating the atom:id of the  
>> other feed. Atom Processors which, for example, suppress display  
>> of duplicate entries by displaying only one entry with a  
>> particular atom:id value or combination of atom:id and  
>> atom:updated values, might also take steps to determine whether  
>> the entries originated from the same publisher before considering  
>> them to be duplicates.
>

Yeah, it seems like it can't possibly be wrong to highlight this  
risk, which I at least didn't notice until someone pointed it out to  
me, so I bet others will miss it too.  -Tim

---

From: "Thomas Broyer" <[email-masked]>
Date: Thu, 26 May 2005 08:45:36 +0200 (CEST)

Tim Bray wrote:
> msg15444.html), [...]

What about the list items in 4.1.3.3 (see [1])?
Anw how about the "(case-insensitive)" which is used sometimes but not
always?

[1] http://www.imc.org/atom-syntax/mail-archive/msg15357.html

-- 
Thomas Broyer

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 26 May 2005 10:33:49 +0100

James M Snell wrote:

> situation digital signatures are designed to handle?  

Yes. Norm and I have mentioned this as well. I do not think we can solve 
this problem by patching the Atom level, ensuring that the Atom level 
can be ex-canonicalised and signed is sufficient.

> If I put out an 

Belongs in the security sections. I would trust the editors to add the 
text if they were willing.

cheers
Bill

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 26 May 2005 16:04:15 +0200

* Graham <[email-masked]> [2005-05-25 23:00]:
> How is this a "Denial of service" attack? Isn't it just
> ordinary spoofing/impersonation?

Indeed; I’d like to see this reworded to refer to “spoofing,” as
that’s what it is.

> Apart from that, +1.

+1 as well; always a good idea to alert people about issues.

Regards,
-- 
Aristotle

---

From: Antone Roundy <[email-masked]>
Date: Thu, 26 May 2005 08:44:34 -0600

> situation digital signatures are designed to handle?
Sure, but how many publishers are going to be using digital signatures 
in the near term (and more importantly, how many aren't?), and who 
knows how many consuming applications will support them.  Until digital 
signatures start providing more help with this kind of thing, let's 
provide a warning to developers so that they can at least consider what 
they might do to safeguard the quality of their users' experience.

And I just thought of another thing (I don't know how digital 
signatures work in this case, so I may be missing something, but I'm 
pretty sure the following is at least partially valid): if I get an 
entry with a valid digital signature and one with no signature (both 
with the same atom:id, of course), then what?  Do I always accept the 
one with the signature?  If so, then DOSing/spoofing unsigned entries 
will be even easier, because all you'd have to do is sign your fake 
entry.  So even in that case, some extra checking might have to be done 
before concluding that the entries are duplicates, and that the 
unsigned one is the one that's disposable.

> Without any kind of cryptographic guarantee of this sort, the best you 
> could do is make an educated guess.
Wouldn't that be better than nothing until digital signatures become 
more ubiquitous?

> Would it make sense to include some language along these lines?
Sure.

---

From: Antone Roundy <[email-masked]>
Date: Thu, 26 May 2005 08:46:37 -0600

> Indeed; I’d like to see this reworded to refer to “spoofing,” as

I presume the specific wording can be left to the discretion of the 
editors.

---

From: Antone Roundy <[email-masked]>
Date: Thu, 26 May 2005 08:49:12 -0600

On Wednesday, May 25, 2005, at 01:06  PM, Antone Roundy wrote:
> == Abstract ==
>
> State the atom:entries from the same feed with the same ID are the 
> same entry, whether simulateously in the feed document or not.

I'm retracting this proposal in preference for PaceAtomIdDos, which I 
like better and is getting more support.

---

From: James M Snell <[email-masked]>
Date: Thu, 26 May 2005 08:08:11 -0700

Antone Roundy wrote:

> knows how many consuming applications will support them.  Until 
> digital signatures start providing more help with this kind of thing, 
> let's provide a warning to developers so that they can at least 
> consider what they might do to safeguard the quality of their users' 
> experience.
>
Oh, absolutely, I was simply making an observation and thinking a bit 
about whether or not it would make sense to have some language as part 
of the warning that mentioned the potential application of digital 
signatures to solving this problem.  I dunno, just thinking out loud 
here a bit.

> entry.  So even in that case, some extra checking might have to be 
> done before concluding that the entries are duplicates, and that the 
Well, it comes down to whether the signature is trusted by the reader or 
not.  If the signature in the entry is not from the trusted, expected 
source, the user should be able to reject it in favor of the unsigned 
entry. 

>> Without any kind of cryptographic guarantee of this sort, the best 
>> you could do is make an educated guess.
>
Absolutely... see my first response above ;-)

---

From: "Bob Wyman" <[email-masked]>
Date: Thu, 26 May 2005 19:16:54 -0400

James M Snell wrote:
> Well, it comes down to whether the signature is trusted by the
> reader or not.  If the signature in the entry is not from the trusted,
> expected source, the user should be able to reject it in favor of the
> unsigned entry.
	Clearly, we're going to have to put a good bit of thought into how
signatures work in Atom in the future. I think it is great that Atom V1.0
has the signature support that it does, however, my guess is that we'll
probably need to develop some extensions and some "best practices" to really
make this stuff work well.

	One interesting question that I think we should consider is "Who's
signature is it anyway?" In most existing signature based applications, we
seem to assume that a person is the entity that creates a signature.
However, I think it may be appropriate to do something different with feeds.
Specifically, I think that it may make a great deal of sense for the *feed*
to sign things. 
	Today, we trust that an entry came from a specific feed if we
inspect the feed and discover that it contains the entry. For a great many
applications, it doesn't really matter who owns the feed. Thus, it might
make sense in the future to associate signing keys with the feed rather than
with the owner of the feed. Signatures would then be used to make statements
that entries -- even if found in other feeds -- actually came from the
source feed that they are claimed to have come from. This would solve a
great many problems that arise when search engines, intermediaries like
PubSub, LinkBlogs, etc. copy entries around.
	The only mechanism that we would need in order to allow feeds to
sign their content would be a means to associate a signing key with a feed
or set of feeds. This could be done in one of two ways: 
	* The traditional indirect manner of having a certificate authority
create a certificate for someone once they prove administrative control over
a feed.
	* The much simpler method of the feed including an extension element
that identifies its signing keys -- it could either point to a file or to a
key server.
	The second method above has the downside that one would either have
to be familiar with the feed and thus have memory of its statements
concerning keys or one would have to fetch the feed as part of the signature
verification process. However, the fact that the second method dispenses
with the need for a certificate authority may make it appear quite
appealing... Also, the second method allows one to do things like replace,
expire, and cancel keys simply by changing the associations in the feed.
	One of the really interesting side-effects of having feeds, not
people, be the owners of keys is that we might then find that it makes sense
to allow feeds to issue certificates to their owners. (Yes, I know that this
probably sounds odd...) Basically, the idea is that instead of giving keys
to a person and then doing things to associate the feed with the person, we
might turn things around and give keys to the feed and then associate the
person with the feed. An intriguing aspect of doing this is that any
measures of the "authority" of the feed could be passed on to the owner of
the feed. Your personal authority, popularity, identity, etc. might be
derived from your feed... So, instead of having to go through the sometimes
great nuisance of presenting birth certificates, SSNs, and other evidence of
personhood to a certificate authority, we could simply assert our personal
existence by linking to the blogs we own... I blog, therefore I am.

	Another interesting question would be what is that role of
intermediaries like PubSub or search engines in signing things? Some such
services might be "trusted" when they make statements like "I found this
entry in the feed identified in the source element." If this is the case,
there could be value in having such trusted services sign the entries that
that pass on. Then, if you found a copy of an entry that carried such a
signature, you could have just as much faith in its correctness as if you
had retrieved the entry directly from the intermediary rather than from
someone who had copied it from the intermediary.
	There are a number of interesting possibilities here....

		bob wyman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 May 2005 17:06:40 -0700

>that identifies its signing keys -- it could either point to a file or to a

Much simpler, but completely insecure. :-) It's a self-signed 
attestation that has to be verified by out-of-band means that, from a 
security standpoint, are equivalent to the first if done right and 
horribly dangerous if done wrong.

Having said that, I support the latter more than the former, and 
believe that >90% of signed feeds that people actually use will 
follow that model.

>expire, and cancel keys simply by changing the associations in the feed.

And, to do any of those securely, you need to do the same things you 
did to get the keys in the first place, using the same security 
mechanism.

>people, be the owners of keys...

Wait, stop. There is no such thing as an "owner" of a key. There are 
things that control the private key of a key pair. That is *always* a 
computer of some sort, and that computer is *always* controllable by 
at least one person. If you're careful/lucky, everyone who has access 
to the private key is someone who should have access.

It is much better to say "..having feeds, not people, be associated 
with keys...". That is, the identifier that is associated with the 
key is a URI of the feed, not a person or company name.

>  is that we might then find that it makes sense

Stated another way, the anchor of the key hierarchy is identified by 
the URI of a feed, and the leaves might be identified by human names.

A different method would be to have multiple identities associated 
with keys. My key might be identified with "Paul Hoffman" and 
"http://lookit.proper.com" and "http://saladwithsteve.com/osx/" and 
so on.

>someone who had copied it from the intermediary.

Exactly right. Intermediary validation is what drives security folks 
crazy (witness the more-than-five-year history of SCVP in the PKIX 
WG), but it is exactly what most people use every day.

>	There are a number of interesting possibilities here....

+1

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 27 May 2005 01:48:41 -0400

Paul Hoffman wrote:
> It is much better to say "..having feeds, not people, be
> associated with keys...". That is, the identifier that is 
> associated with the key is a URI of the feed, not a person
> or company name.
	You are, of course, correct. My apologies for being sloppy and
letting the "ownership" concept slip in. The correct concept is an
association between things, not ownership.

> A different method would be to have multiple identities
> associated with keys. My key might be identified with "Paul 
> Hoffman" and "http://lookit.proper.com" and
> http://saladwithsteve.com/osx/" and so on.
	This is certainly possible. However, I quite like the idea of
rooting the hierarchy in an association between keys and a verifiable
network resource. Presumably, it will be much easier for us to gather
"reputation" information concerning feeds and having such verifiable
resources at the root of the hierarchy will make it somewhat harder for
people to generate spurious keys. 

> Much simpler, but completely insecure. :-)... Having said that, 
>I support the latter more than the former, and believe that >90% of
> signed feeds that people actually use will follow that model.
	I agree. In many ways, the process of getting keys from a small
number of centralized certificate authorities may be viewed as "more
correct." However, we have decades of experience with "correct" solutions
that are simply not used. They are often elegant, but useless... If we're
ever going to get signatures in wide use, we're going to have to compromise
a bit and focus on what is practical -- not just what is technically
superior. An unimplemented solution is *not* superior, in any useful sense,
to a less elegant but implemented solution that delivers the same result.

		bob wyman