Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (with COMMENT)

[Julian Reschke <[e-mail]>]

On 2015-02-19 17:20, Kathleen Moriarty wrote:
> Hi,
>
> On Thu, Feb 19, 2015 at 2:15 AM, Julian Reschke <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     On 2015-02-19 00:42, Barry Leiba wrote:
>
>                 "MUST NOT" does not mean the Internet Police will come
>                 to take you away.
>                 "MUST NOT" means "this won't work".
>
>
>             Ahem, no, that's not what "MUST NOT" means.
>
>
>         It is, modulo rhetoric.  It's an interoperability requirement.  "You
>         MUST NOT do <x>," means that if you do <x>, you will not
>         interoperate
>         -- something will break.  It seems to me that that's exactly the
>         case
>         here: If my username is "b:leiba", and a client sends
>         "b:leiba:plugh",
>         many servers will think the username is "b" and the password is
>         "leiba:plugh".  That means that allowing ":" in the username breaks
>         interoperability.  Whether or not it works sometimes, and whether or
>
>
>     Allowing colons in usernames when usernames are assigned is a
>     problem. We already say these names are invalid.
>
>     Requiring UAs to reject them is an entirely different story. If a
>     user id *did* contain the colon, and did "work" for some UA A and
>     server B, implementing the "MUST NOT" in the UA would remove the
>     user's ability to log on to the web site. That's a bigger failure.
>
>
> Pete and Barry are making the point that text in this draft can help
> clear this issue up going forward.  If a user id contained a colon, the
> user would need a new id if user agents decided this should not work.
> Since browsers do support this now, there must be some instances where
> this occurred to change their behavior, moving away from standard
> specifications to allow this, is that true?  I haven't seen user ids
> with :s in them, but that could just be me being unaware of this practice.
>
> I'm not reading this discussion as resolved yet.

True.

The problem here is the "long tail". We simply have no information about 
whether these IDs exist in practice. The fact that all UAs I checked 
indeed accept them at least *hints* that they might be used somewhere. 
Or none of the implementers ever thought about rejecting them.

I don't believe we can find out what the reason for this is.

In RFC 2617, the pseudo-ABNF prose production excluded the colon, but no 
additional prose requirements were present.

In the draft, we have replaced that pseudo-ABNF by prose, and that prose 
not only says "invalid" but also explains what common UAs do, and how 
that might affect results. I hope everybody agrees that this is an 
improvement over what we had before.

The discussion that we're having is whether "MUST NOT use colons" is 
better or worse than "colons are invalid". I don't believe it makes a 
difference. I'll also note that I'm very unhappy to include a "MUST NOT" 
when we know that current implementations actually do it anyway, and 
they are extremely unlikely to stop doing that. In the worst case, a 
user who previously could login now won't, and this might switch to a 
different UA. (And that's what scares UA implementors most :-).

Best regards, Julian