Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol
draft-ietf-dkim-ssp-requirements-05

[Ballot comment]
From Gen-ART Review by Vijay K. Gurbani.

  The introduction does a good job of introducing the problem
  for which the requirements are being sought.  Having said that,
  a few nits follow primarily to improve readability of the draft.

  1) S1, consider rewriting as follows to impart more clarity:

  OLD:
  This ambiguity can be used to mount a bid down attack
  which is inherent with systems that allow optional
  authentication like email
  NEW:
  This ambiguity can be used to mount a bid-down attack
  that is inherent with systems like email, which allow
  optional authentication

  2) S3, consider rewriting as follows to impart more clarity:

  OLD:
  This section tries to outline some usage scenarios
  that it is expected that DKIM signing/verifying will take place in,
  and how a new protocol might be helpful to clarify the relevance of
  DKIM signed mail.
  NEW:
  This section outlines expected usage scenarios where DKIM
  signaling/verifying will take place, and how a new protocol
  might help to clarify the relevance of DKIM-signed mail.

  3) S3.1, second paragraph: consider rewriting as follows to
  impart more clarity:

  OLD:
  Thus the receiver is at a disadvantage in that it does not know
  if it should ...
  NEW:
  Thus, the receiver is at a disadvantage in not knowing whether
  it should ...

  4) S3.2, list item 3: The first sentence consists of two fragments
  joined by a "but".  It would be more appropriate to join them by
  the phrase ", and furthermore".  The second fragment does not
  contradict the first, thus the "but" appears anomalous.

  5) S5.1, list item 4: Missing closing ']' in "Refs:..."

  6) S5.2, list item 3: s/ala/a la/

[Ballot comment]
The difference between scenario 1 and scenario 2 in section 3 depends on "A" being able to effect a difference in whether or not its signatures get invalidated on transit. Shouldn't there be a reference to how this is possible for A to influence?

Section 5, introduction to this section: I can't understand how "the candidate protocol" for SSP and SSP must both meet the same requirements if they're different things.  I think this could be much clearer. Generally there needs to be a better distinction between "SSP" and "the protocol".

[Ballot comment]
A couple things that could be improved:

1. In some places it says "the [RFC2822].From domain", in another place it says "The domain part of the first address of the RFC2822.From".  The latter is more precise as the "From" header in an RFC2822 message may contain more than one address (if there is more than one author).  The best way to get consistency would be to add a definition for "From domain" (or similar term) as "The domain portion of the first address listed in an RFC 2822 From header" and then use "From domain" in the document.

2. Under "Security Requirements" item 2: "In particular the work and message exchanges involved MUST be order of a constant."  I don't know what this means or is trying to say.

[Ballot comment]
Requirements Language

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in RFC 2119 [RFC2119].

Based on that RFC2119 definitions are not suitable for describing requirements and the abstract already consist of contradicting definitions. Why not write the definitions that actually are included in the document.

[Ballot comment]
Section 2., paragraph 0:
>    2.  In order to limit the cost of its use, any query service
>        supplying SSP's information MUST provide a definitive responsive
>        within a small, deterministic number of query exchanges.

  Given that the Internet is best-effort, this is impossible to
  guarantee in general. I'd suggest to soften the language or at least
  add a "during normal operation" qualifier.

[Ballot discuss]
Section 2., paragraph 0:
>    2.  The query/response in terms of latency time and the number of
>        packets involved MUST be low (order of 1 or 2 exchanges).
>          [Refs: Deployment Consideration 5]

  DISCUSS: This is a "please explain this in more detail" DISCUSS. This
  requirement is very terse, and I hence don't understand what it will
  mean in terms of what transport protocol is envisioned for SSP. Would
  this requirement for example rule out a TCP-based transport, because
  that requires a 3-way handshake at the TCP layer? Or is this saying
  "an SSP exchange should not take more than 1 or 2 SSP messages going
  back and forth"? I also don't quite understand how scenario 5
  motivates this requirement. The scenario is all about the ability to
  cache, which should be independent of what transport protocol is used.