The Atom Publishing Protocol
draft-ietf-atompub-protocol-17

[Ballot discuss]
First, I'd like to thank the atompub working group and the chairs and
authors for working with me to help expand the security considerations
section.  I think this expansion significantly helps me understand the
security implications of the protocol.

Unfortunately now that I understand the protocol, I think that we need
to ask for wider review of the decision not to support end-to-end
signatures between the original content provider and the consumer.
Both atompub's security advisor and I believe that this is something
that needs wider review.  Phrasing this is going to be a bit tricky.
We want to encourage serious review, but we also don't want a bunch of
people to pop up and simply say that more security is required when it
costs them nothing to do so and they are not involved in the solution.

In particular, I believe that this is an area where as described in
section 3.1 of the discuss criteria document, the IETF as a whole may
not have consensus behind this approach even though the atompub
working group does.  To that end, I propose that we discover whether
the IETF has such a consensus and if not forge a consensus behind this
technical approach or another.

but I think we want to be careful about how we phrase the question.

Ultimately I think we want a second focused last call on this issue

[Ballot discuss]
First, I'd like to thank the atompub working group and the chairs and
authors for working with me to help expand the security considerations
section.  I think this expansion significantly helps me understand the
security implications of the protocol.

Unfortunately now that I understand the protocol, I think that we need
to ask for wider review of the decision not to support end-to-end
signatures between the original content provider and the consumer.
Both atompub's security advisor and I believe that this is something
that needs wider review.  Phrasing this is going to be a bit tricky.
We want to encourage serious review, but we also don't want a bunch of
people to pop up and simply say that more security is required when it
costs them nothing to do so and they are not involved in the solution.

Ultimately I think we want a second focused last call on this issue  but I think we want to be careful about how we phrase the question.

[Ballot comment]
Review from Christian Vogt:

This I-D specifies a simple, HTTP-based protocol for publishing and
editing data on the Web.  I did not find any technical nits with this
protocol, which is good.

Two substantial editorial comments, though:

(2)  The Terminology section includes circular definitions, which
actually makes some definitions completely useless.  For instance, a
"resource" is defined in terms of "resources" and "member resource".  A
"member resource, in turn, is a "resource" with special properties...

(1)  The document has no introduction.  (The text in the Introduction
section does not suffice in this regard.)

[Ballot discuss]
Section 14 says:
  >
  > The type of authentication deployed is a local decision made by the
  > server operator.  Clients are likely to face authentication schemes
  > that vary across server deployments.  At a minimum, client and server
  > implementations MUST be capable of being configured to use HTTP Basic
  > Authentication [RFC2617] in conjunction with a TLS [RFC2246]
  > connection as defined in [RFC2818] (but note that [RFC2246] has been
  > superseded by [RFC4346]).  See [RFC4346] for more information on TLS.
  >
  The specification ought to say that it MUST support TLS 1.0 [RFC2246]
  or a sunsequent standards-track version of TLS, and that it MUST
  also support the conventions for using HTTP over TLS [RFC2818].

[Ballot discuss]
Section 15 documents a number of security threats without any
justification of why these threats are acceptable or why mechanisms
were not included to address these threats.  The entire section needs
to be fixed to include descriptions of how to avoid the threats or why
the threats are reasonable residual threats.  Of particular concern is
replays and the mangling of digitally signed content.

[Ballot comment]
Section 14., paragraph 3:
>    At a minimum, client and server
>    implementations MUST be capable of being configured to use HTTP Basic
>    Authentication [RFC2617] in conjunction with a TLS [RFC2246]
>    connection as defined in [RFC2818] (but note that [RFC2246] has been
>    superseded by [RFC4346]).

  RFC2246 shouldn't be cited anymore, if it's been obsoleted.

[Ballot discuss]
This is a blocking "this needs to be fixed" discuss.

Our media type registration process (BCP 13) presently requires
standards track media types to be sent to the ietf-types mailing list
for review:
  http://www.alvestrand.no/mailman/listinfo/ietf-types

Using a google search, I was unable to find reference to "atomcat+xml" or
"atomsvc+xml" in the mailing list archive.  If this analysis is in error
and the types were reviewed on that list, I will immediately clear this
discuss.

Note that I'm not a fan of this particular procedure and would gladly
sponsor a document which amended BCP 13 to simplify or drop this
requirement for IESG reviewed documents.  However, as the apps area
director who is watching media type issues it is unfortunately my job
to enforce this rule.  My apologies for any delay this causes.

[Ballot comment]
While I'm deferring to my co-AD who is more of an expert on HTTP issues
than I am, I'm concerned by the fact this protocol runs over port 80
by default.  The litmus test in BCP 57 section 3 for reuse of port 80
is murky for this protocol (the first bullet is probably acceptable, but
I'm unsure of the second and third bullets).  Do organizations that punch
a hole in their firewall for port 80 always intend to have atom
publishing occurring?

Let me explain why I care about this issue.  In the email world, a large
number of SMTP servers with dubious security properties were widely
deployed.  As a result, the network security community decided to
run application-level firewalls on port 25.  Such proxies are the most
common cause of interoperability problems with SMTP, especially with
respect to options negotiation and in particular they often defeat
SMTP-level security features such as STARTTLS.

Furthermore, port 25 is now widely used for submission of spam,
something that was not considered at the time the protocol was designed.
The email community has been trying to separate submission from
transfer with port 587 so that separate security policies can be applied
to transfer and submission easily.  While this has had some success, it
is very difficult to introduce a new port later, but it's not difficult
to say "MUST try port X first, but feel free to use port 80 as a
fallback" when the protocol is first deployed.

I'm concerned that the extensive reuse of port 80 could lead to the
widespread deployment of disruptive application-level proxies that
could negatively impact all protocols on port 80.  Hopefully I'm wrong
that this is the likely outcome of the present reuse-port-80 trend, but
my concern is informed by past experience with port 25.

[Ballot comment]
While I'm deferring to my co-AD who is more of an expert on HTTP issues
than I am, I'm concerned by the fact this protocol runs over port 80
by default.  The litmus test in BCP 57 section 3 for reuse of port 80
is murky for this protocol (the first bullet is probably acceptable, but
I'm unsure of the second and third bullets).  Do organizations that punch
a whole in their firewall for port 80 always intend to have atom
publishing occuring?

Let me explain why I care about this issue.  In the email world, a large
number of SMTP servers with dubious security properties were widely
deployed.  As a result, the network security community decided to
run application-level firewalls on port 25.  Such proxies are the most
common cause of interoperability problems with SMTP, especially with
respect to options negotiation and in particiular they often defeat
SMTP-level security features such as STARTTLS.

Furthermore, port 25 is now widely used for submission of spam,
something that was not considered at the time the protocol was designed.
The email community has been trying to separate submission from
transfer with port 587 so that separate security policies can be applied
to transfer and submission easily.  While this has had some success, it
is very difficult to introduce a new port later, but it's not difficult
to say "MUST try port X first, but feel free to use port 80 as a
fallback" when the protocol is first deployed.

I'm concerned that the extensive reuse of port 80 could lead to the
widespread deployment of destruptive application-level proxies that
could negatively impact all protocols on port 80.  Hopefully I'm wrong
that this is the likely outcome of the present reuse-port-80 trend, but
my concern is informed by past experience with port 25.

[Ballot comment]
I have no idea how to implement the statement "It is RECOMMENDED that clients be implemented in such a way that new authentication schemes can be deployed".

Requiring TLS+Basic is going to make it much harder for some embedded devices to support this protocol. Did the WG include designers of such systems and did they feel that TLS+Basic was better than HTTP Digest for clients?

[Ballot discuss]
This is a discuss discuss and I will clear this part of it after the call. In section 6.1, I don't understand why the name are the way they are or who is going to make the PURL registration or why we would need this instead of the normal way we deal with XML namespace names. Should the IANA section tell IANA to go do this?  Does this require one to name the namespace "app:" in the document?

Give this is a an IETF standards track document, the change controller for the Media Type registrations should be the "The IETF".

PROTO writeup based on the RFC 4858 guide.

(1.a)  Who is the Document Shepherd for this document?  Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this
      version is ready for forwarding to the IESG for publication?
Paul Hoffman. Yes.

(1.b)  Has the document had adequate review both from key WG members
      and from key non-WG members?  Does the Document Shepherd have
      any concerns about the depth or breadth of the reviews that
      have been performed?
Yes. No.

(1.c)  Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective,
      e.g., security, operational complexity, someone familiar with
      AAA, internationalization, or XML?
No.

(1.d)  Does the Document Shepherd have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of?  For example, perhaps he
      or she is uncomfortable with certain parts of the document, or
      has concerns whether there really is a need for it.  In any
      event, if the WG has discussed those issues and has indicated
      that it still wishes to advance the document, detail those
      concerns here.  Has an IPR disclosure related to this document
      been filed?  If so, please include a reference to the
      disclosure and summarize the WG discussion and conclusion on
      this issue.
Yes: we don't know whether the security considerations section will
cause the document to be rejected by the Security ADs.

(1.e)  How solid is the WG consensus behind this document?  Does it
      represent the strong concurrence of a few individuals, with
      others being silent, or does the WG as a whole understand and
      agree with it?
Fairly strong across the WG; in fact, it seems stronger since the IETF
Last Call. There is lots of positive feelings for the overall
document. We have seen multiple implementations already, and the
informal workshop showed that many of them interoperate quite well.

(1.f)  Has anyone threatened an appeal or otherwise indicated extreme
      discontent?  If so, please summarize the areas of conflict in
      separate email messages to the Responsible Area Director.  (It
      should be in a separate email because this questionnaire is
      entered into the ID Tracker.)
Rob Sayre has already appealed the theory behind what has become the
Security Considerations section. This has been discussed on the
ietf-general list and the WG mailing list.

(1.g)  Has the Document Shepherd personally verified that the
      document satisfies all ID nits?  (See
      http://www.ietf.org/ID-Checklist.html and
      http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
      not enough; this check needs to be thorough.  Has the document
      met all formal review criteria it needs to, such as the MIB
      Doctor, media type, and URI type reviews?  If the document
      does not already indicate its intended status at the top of
      the first page, please indicate the intended status here.
Yes

(1.h)  Has the document split its references into normative and
      informative?  Are there normative references to documents that
      are not ready for advancement or are otherwise in an unclear
      state?  If such normative references exist, what is the
      strategy for their completion?  Are there normative references
      that are downward references, as described in [RFC3967]?  If
      so, list these downward references to support the Area
      Director in the Last Call procedure for them [RFC3967].
Yes. No. N/A. No. N/A.

(1.i)  Has the Document Shepherd verified that the document's IANA
      Considerations section exists and is consistent with the body
      of the document?  If the document specifies protocol
      extensions, are reservations requested in appropriate IANA
      registries?  Are the IANA registries clearly identified?  If
      the document creates a new registry, does it define the
      proposed initial contents of the registry and an allocation
      procedure for future registrations?  Does it suggest a
      reasonable name for the new registry?  See [RFC2434].  If the
      document describes an Expert Review process, has the Document
      Shepherd conferred with the Responsible Area Director so that
      the IESG can appoint the needed Expert during IESG Evaluation?
Yes. Hopefully. Yes. Yes. N/A.

(1.j)  Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML
      code, BNF rules, MIB definitions, etc., validate correctly in
      an automated checker?
No, but many others have.

(1.k)  The IESG approval announcement includes a Document
      Announcement Write-Up.  Please provide such a Document
      Announcement Write-Up.  Recent examples can be found in the
      "Action" announcements for approved documents.  The approval
      announcement contains the following sections:

IANA Last Call Comments:

Action #1: (Sections 16.1 & 16.2)
Upon approval of this document, the IANA will make
the following assignments in the
"Application Media-Types" registry located at

http://www.iana.org/assignments/media-types/application/

atomsvc+xml [RFC-atompub-protocol-14]
atomcat+xml [RFC-atompub-protocol-14]


Action #2: (Section 16.3)
Upon approval of this document, the IANA will make
the following assignments in the "Permanent Message
Header Field Names" registry located at

http://www.iana.org/assignments/message-headers/perm-headers.html


Header Field Name Protocol Status Reference

SLUG http standard [RFC-atompub-protocol-14]


Action #3: (Section 16.4 & 16.5)
Upon approval of this document, the IANA will make
the following assignments in the
"Link Relations - per [RFC4287]" registry located at

http://www.iana.org/assignments/link-relations.html

Value Reference Registration Date (if applicable)
edit [RFC-atompub-protocol-14] 
edit-media [RFC-atompub-protocol-14] 


Action #4: (Section 16.6)

Upon approval of this document, the IANA will update
the following assignments in the
"Application Media-Types" registry located at

http://www.iana.org/assignments/media-types/application/

OLD:
atom+xml [RFC4287]

NEW:
atom+xml [RFC4287,RFC-atompub-protocol-14]

We understand the above to be the only IANA Action
for this document.

PROTO write-up


(1.a)  Who is the Document Shepherd for this document?  Has the Document
Shepherd personally reviewed this version of the document and, in
particular, does he or she believe this version is ready for forwarding
to the IESG for publication?

Paul Hoffman. Yes and yes.

(1.b)  Has the document had adequate review both from key WG members and
from key non-WG members?  Does the Document Shepherd have any concerns
about the depth or breadth of the reviews that have been performed?

Yes and yes. No (God no...).

(1.c)  Does the Document Shepherd have concerns that the document needs
more review from a particular or broader perspective, e.g., security,
operational complexity, someone familiar with AAA, internationalization
or XML?

No.

(1.d)  Does the Document Shepherd have any specific concerns or issues
with this document that the Responsible Area Director and/or the IESG
should be aware of?  For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it.  In any event, if the WG has discussed those issues
and has indicated that it still wishes to advance the document, detail
those concerns here.  Has an IPR disclosure related to this document
been filed?  If so, please include a reference to the disclosure and
summarize the WG discussion and conclusion on this issue.

No

(1.e)  How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

Fairly strong. There is lots of positive feelings for the overall
document. We are also seeing multiple implementations already.

(1.f)  Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is entered into the ID
Tracker.)

Rob Sayre has already appealed the theory behind what has become the
Security Considerations section.

(1.g)  Has the Document Shepherd personally verified that the document
satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/).  Boilerplate checks are not
enough; this check needs to be thorough.  Has the document met all
formal review criteria it needs to, such as the MIB Doctor, media type
and URI type reviews?

Yes. Yes.

(1.h)  Has the document split its references into normative and
informative?  Are there normative references to documents that are not
ready for advancement or are otherwise in an unclear state?  If such
normative references exist, what is the strategy for their completion?
Are there normative references that are downward references, as
described in [RFC3967]?  If so, list these downward references to
support the Area Director in the Last Call procedure for them [RFC3967].

Yes. No. N/A. No. N/A.

(1.i)  Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of the
document?  If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries?  Are the IANA
registries clearly identified?  If the document creates a new registry,
does it define the proposed initial contents of the registry and an
allocation procedure for future registrations?  Does it suggest a
reasonable name for the new registry?  See [RFC2434].  If the document
describes an Expert Review process has Shepherd conferred with the
Responsible Area Director so that the IESG can appoint the needed Expert
during the IESG Evaluation?

Yes. Yes. Yes. N/A. N/A. N/A.

(1.j)  Has the Document Shepherd verified that sections of the document
that are written in a formal language, such as XML code, BNF rules, MIB
definitions, etc., validate correctly in an automated checker?

No, but I trust that the editors have.

(1.k)  The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up?

Technical Summary

The Atom Publishing Protocol HTTP-based protocol for publishing and
editing web resources, and is particularly useful for (but not limited
to) blogs. It supports ideas such as collections of multimedia items and
categorization of items. It uses the Atom format (RFC 4287) for its
messages.

Working Group Summary

The document went through many revisions and was discussed actively.
It had a few WG Last Calls.

Document Quality

There are multiple implementations of the spec and active
interoperability testing among them. There are additional implementers
who have said they want to implement when it is clear that this is going
to Standards Track.

Personnel

Paul Hoffman is the Document Shepherd. Lisa Dusseault is the Responsible
Area Director.