Subject: #481, was: WGLC: p7 MUSTs

From: Julian Reschke <[email-masked]>
Date: Sun, 09 Jun 2013 18:57:47 +0200

On 2013-05-01 07:09, Alex Rousskov wrote:
> Hello,
>
>      These comments are based on the "latest" snapshot dated Mon 29 Apr
> 2013 03:13:05 PM MDT at
> https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p7-auth.html
>
> I hope these issues are "editorial in nature".
>
>
>> For historical reasons, senders MUST only use the quoted-string syntax.
>
> Perhaps this can be relaxed to "MUST only generate", especially since
> another MUST prohibits proxies from modifying WWW-Authenticate and
> Authorization header fields.

OK.

> And here is a list of requirements that are missing an explicit actor on
> which the requirement is placed. Even though it is often possible to
> guess the actor, most of these should be easy to rephrase to place the
> requirement on the intended actor explicitly (e.g., "A proxy MUST"
> instead of "a header field MUST":
>
>> each parameter name MUST only occur once per challenge

That's a requirement on the validity of a challenge. As such it does not 
depend on the actor.

>> This response MUST include a WWW-Authenticate header
>
>> The 407 (Proxy Authentication Required) response message [...] MUST
>> include a Proxy-Authenticate header field
>
>> information necessary to authenticate a request MUST be provided in
>> the request
>
>> It MUST be included as part of a 407 (Proxy Authentication Required)
>> response.
>
>> It MUST be included in 401 (Unauthorized) response messages

Similar things can be said about these.

What you seem to ask for is information about what a proxy should do 
when it receives a message that already violates a MUST level 
requirement. That's somewhat orthogonal to the discussion about that 
constitutes a valid message.

I can see why guidelines would be good, but watering down the validity 
requirements doesn't seem to be the right approach.

> ...

Best regards, Julian

---

From: Alex Rousskov <[email-masked]>
Date: Sun, 09 Jun 2013 12:49:55 -0600

On 06/09/2013 10:57 AM, Julian Reschke wrote:
> That's a requirement on the validity of a challenge. 

Yes. We need to make clear which actors that requirement applies to.

> As such it does not depend on the actor.

It does. When I originally complained that lots of RFC 2616 MUSTs may be
interpreted as if they apply to proxies when they should not and
suggested a general rule to excuse proxies from policing traffic, I was
told that a better approach is to check each and every MUST to make sure
it is clear whether it applies to blind forwarding situations or not.
The current HTTPbis specs use that overall approach via the introduction
of "sends" vs "generates" difference (thank you!).

However, to enable such checks, each MUST has to have an actor with
"sends", "generates", or another appropriate keyword. Otherwise, it is
not clear whether the proxy is responsible for policing things like
challenges with duplicate parameter names. The overhead of checking and
adjusting each requirement comes with the approach. You cannot have it
both ways.

> Similar things can be said about these.

Yes, the flaw is similar.

> requirement.

No, I am not asking for that. I am asking to make it possible to
determine whether a proxy forwarding a malformed message is in violation
of the specs. As discussed above, each requirement has to be clear on
that by using appropriate actors and verbs.

If you say "server MUST NOT send X", the proxy becomes responsible for
not forwarding X. If you say "server MUST NOT generate X", the proxy
forwarding behavior is not restricted by that specific requirement. When
you say "request MUST NOT have X", the specs become ambiguous: some will
claim that a proxy forwarding X is in violation and some will claim that
the requirement is not applicable to proxies.

Hope this clarifies,

Alex.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 30 Jun 2013 18:48:01 +0200

> the requirement is not applicable to proxies.

Yes, sort of.

The trouble is that what you're asking for a change in requirements, and 
that most definitively is *not* an editorial change. As such, I'm not 
too enthusiastic to make these kind of changes without feedback from the 
working group.

Do people agree that these requirements need to be rephrased? Do we have 
concrete proposals about *how* to change them?

Best regards, Julian

---

From: Alex Rousskov <[email-masked]>
Date: Sun, 30 Jun 2013 13:46:15 -0600

> that most definitively is *not* an editorial change. 

Whether polishing how these ambiguous requirements are worded actually
changes those requirements depends on whether the reader believes that
the proxy must police the given aspect of the message. Some readers may
indeed decide that your polishing is not editorial in nature, depending
on how you change the specs. The very fact that you suspect there will
be protocol changes essentially implies that the current requirements
are ambiguous and ought to be fixed.

> As such, I'm not

On the other hand, it is difficult to provide feedback without seeing
the changes.

> concrete proposals about *how* to change them?

FWIW, I do: Reword them to name the actor (client or server, usually
obvious) and use "generate" instead of "send". When that default does
not seem appropriate to you or others, let's discuss!

Thank you,

Alex.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 30 Jun 2013 22:08:30 +0200

> On the other hand, it is difficult to provide feedback without seeing

Well, you could make a concrete change proposal.

> not seem appropriate to you or others, let's discuss!

I don't think that it's sufficient to do that. What you propose is to 
erase the current language that defines validity of the message format 
and replace it by something else. I don't think we should do that. We 
*can* discuss clarifying what that means for the various actors, though.

Best regards, Julian