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

Barry Leiba <barryleiba@computer.org> Thu, 19 February 2015 01:23 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C661A1AE3; Wed, 18 Feb 2015 17:23:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDOxfspy18wV; Wed, 18 Feb 2015 17:23:17 -0800 (PST)
Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9FCD1A2130; Wed, 18 Feb 2015 17:23:16 -0800 (PST)
Received: by lbiz11 with SMTP id z11so4737841lbi.5; Wed, 18 Feb 2015 17:23:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=aLVw7J7Mr1x2Qg7+MQdGyuZY6FwIQtrhmKMVohIkH+4=; b=bI0uTShqXdJ6vsKyooAd2zkH2mn3IElsDCQtq4A4YPG2wZ+7DbfoPm9Z+LbSKz9Ju3 FfFe4i4ZtJGOuXJiNUFK/7RiHU6hxzyMc8nNunR/hrG4iFRMuXiJqimJ19B7GxI61iCw IL2hyRANIsBqOylHbMvnEPi9HXBxAAkVeayknretxEYGntLSBwtLnlzvenatZxAibz7v XEpOmdqbWL7O7mLpsIeLcY9+XPSihKvpeNprjRRv83r8Ph47sQRjOnTuJCSV9vG0LTfa pqrQ0+69fqAMMIS3dtZ16bw6GGPzqJhPmv1aB5Ro+CkJDwL/TrccSVq59J4NQWDcDGM3 3fsw==
MIME-Version: 1.0
X-Received: by 10.152.206.7 with SMTP id lk7mr1722843lac.37.1424308995276; Wed, 18 Feb 2015 17:23:15 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.152.127.165 with HTTP; Wed, 18 Feb 2015 17:23:15 -0800 (PST)
In-Reply-To: <dg9aea9kp9raqqukdloeqfnrfvl8cj26oq@hive.bjoern.hoehrmann.de>
References: <20150218214927.31074.15996.idtracker@ietfa.amsl.com> <54E511BF.1070503@gmx.de> <54E51652.4050301@qti.qualcomm.com> <54E51843.1050307@greenbytes.de> <CALaySJJCzgkUNpONxFdv9-ZUD_Qxa_70rt+3g+U60Ctt80CMAg@mail.gmail.com> <dg9aea9kp9raqqukdloeqfnrfvl8cj26oq@hive.bjoern.hoehrmann.de>
Date: Wed, 18 Feb 2015 17:23:15 -0800
X-Google-Sender-Auth: hpL3rLuhwZM-9yUeNKSotq9j18Q
Message-ID: <CALaySJJZ7UyKULT_XkppotXaxbCfWDkpH4+0PUb9=MsRebQoog@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: <http://mailarchive.ietf.org/arch/msg/http-auth/Fe9RLUDfsMwr5ErsBa_ivj119eU>
Cc: Julian Reschke <julian.reschke@greenbytes.de>, Julian Reschke <julian.reschke@gmx.de>, Pete Resnick <presnick@qti.qualcomm.com>, httpauth-chairs@ietf.org, "http-auth@ietf.org" <http-auth@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-httpauth-basicauth-update.all@ietf.org
Subject: Re: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (with COMMENT)
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-auth/>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2015 01:23:18 -0000

>>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
>>not implementations currently *do* this are irrelevant.  The point is
>>that the right definition of the protocol is that you "MUST NOT have a
>>colon character in the username."
...
> The text suggested by Pete Resnick restricts, in the model above, the
> contents of `$user`, without clear implications for browsers or servers
> or header field value validity. What is it actually that people want
> here? Should browsers be required to check user input for colons? Is it
> okay that the draft requires support for colons in passwords, but does
> not require servers to interpret `b:leiba:plugh` as having a password of
> `leiba:plugh`? Perhaps encoded `user:pass` strings in `Basic` headers
> should be non-conforming if they contain more than one colon?

The bottom line here is that we aren't police, and there are no
consequences for "not conforming".  If, in fact, usernames that
contain colons cause interop problems, what we *should do* in writing
the protocol is to say that usernames MUST NOT contain colons.  If,
despite that, browsers don't check user input, and send usernames with
colons, then the answer is that when they do that they're likely not
to get the results they expect, because that's not valid in the
protocol.  And if someone complains that things broke as a result,
everyone can explain why: having the colon in the username is a
protocol violation.

I don't understand what the argument is about here, because I don't
*think* anyone is arguing that colons *should* be allowed.  I think
the only argument is that sometimes colons *are* sent.  I don't see
that that matters.

Barry