Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Mon, 24 February 2020 23:02 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63CA3A14FF; Mon, 24 Feb 2020 15:02:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 vssfo2Fc1BQb; Mon, 24 Feb 2020 15:02:52 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A873A14F5; Mon, 24 Feb 2020 15:02:51 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01ON2jm0031287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Feb 2020 18:02:47 -0500
Date: Mon, 24 Feb 2020 15:02:44 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Barry Leiba <barryleiba@computer.org>
Cc: "Gould, James" <jgould@verisign.com>, "draft-ietf-regext-login-security@ietf.org" <draft-ietf-regext-login-security@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "regext@ietf.org" <regext@ietf.org>
Message-ID: <20200224230244.GB5814@kduck.mit.edu>
References: <639F7D2A-A0D7-4DB6-B846-2A75589E4466@verisign.com> <CALaySJKiGEJgwurOfEtB_drjF+miiu-SWUvwXGj+i348GBg9jA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CALaySJKiGEJgwurOfEtB_drjF+miiu-SWUvwXGj+i348GBg9jA@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/cjdNtIMTa4y-o4CdQJct_JFV12Q>
Subject: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Feb 2020 23:02:56 -0000

This text regarding internationalization/normalization works for me.

Looking at the diff from -07 to -09, we seem in pretty good shape overall;
were we going to add a note to abstract and/or introduction about "this
extension allows for the use of strong passwords with EPP"?  (I think Jim
had proposed actual text at some point that's better than my paraphrased
version here.)

-Ben

On Mon, Feb 24, 2020 at 07:43:47AM -0800, Barry Leiba wrote:
> Great; thanks, Jim.  Ben, are you OK with this now?
> 
> Barry
> 
> On Mon, Feb 24, 2020 at 5:28 AM Gould, James <jgould@verisign.com> wrote:
> >
> > Barry & Ben,
> >
> > Thanks for the detailed discussion.  I will change the "recommended" to the normative "RECOMMENDED" and change the PRECIS sentence to match Ben's proposal.  The end result will be:
> >
> > It is RECOMMENDED that the plain text password in the <loginSec:pw> and <loginSec:newPw> elements use printable ASCII characters #x20 (space) - #x7E (~), with high entropy, such as 128 bits. If non-ASCII characters are supported with the plain text password, then use a standard for passwords with international characters; the OpaqueString PRECIS profile in [RFC8265] is recommended in the absence of other considerations.
> >
> > I'll include this change in the posting of draft-ietf-regext-login-security-09.
> >
> > Thanks,
> >
> > --
> >
> > JG
> >
> >
> >
> > James Gould
> > Distinguished Engineer
> > jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>
> >
> > 703-948-3271
> > 12061 Bluemont Way
> > Reston, VA 20190
> >
> > Verisign.com <http://verisigninc.com/>
> >
> > On 2/22/20, 6:15 PM, "Barry Leiba" <barryleiba@computer.org> wrote:
> >
> >     Thanks, Ben; this helps a lot.
> >
> >     Jim, are you good with Ben's suggestion or a variation of that?  It's
> >     just a small update to what you have, and makes it clearer that if you
> >     need I18N, PRECIS is the weay to do it.
> >
> >     Barry
> >
> >     On Fri, Feb 21, 2020 at 10:08 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
> >     >
> >     > Hi Barry,
> >     >
> >     > On Sat, Feb 15, 2020 at 12:12:29AM -0500, Barry Leiba wrote:
> >     > > Hi, all...
> >     > >
> >     > > I'm sorry if I'm not completely clear about where the discussion is,
> >     > > but what Jim's mail system does to the quoting is horrendous (as is
> >     > > the case with most HTML-based mail systems), and I can't easily follow
> >     > > the thread.
> >     >
> >     > I sympathize; I find that with some regularity I end up saving the
> >     > text/html component to a file and opening it in a browser in order to have
> >     > a chance of figuring out what's going on.
> >     >
> >     > > So I'm just picking up this recent bit from Ben:
> >     > >
> >     > > > I think it would probably be helpful for the responsible AD to chime in; my
> >     > > > understanding is still that the PRECIS profiles are to be used as part of a
> >     > > > protocol as opposed to part of a deployment, and that allowing for
> >     > > > different rules to be used in different sites is risky.  I understand that
> >     > > > there's the extra context here of the potential for preexisting deployments
> >     > > > that started using non-ASCII passwords in the absence of any guidance from
> >     > > > the IETF on how to do so, and we have to consider whether what we do will
> >     > > > break them, and so hearing from someone versed in the matter who has
> >     > > > thought about this particular case would help assuage my concerns.  One
> >     > > > possible route (given that, as I understand it, a lot of EPP deployments
> >     > > > involve exchange of configuration and deployment information between peers
> >     > > > out of band) would be to say that the PRECIS profile is used as a default
> >     > > > in the absence of other configuration knowledge for a given deployment,
> >     > > > though I acknowledge that this is not without flaws.
> >     > >
> >     > > I had discussed the PRECIS issue with Jim, which is what resulted in this text:
> >     > >
> >     > >    It is recommended that the plain text password in the <loginSec:pw>
> >     > >    and <loginSec:newPw> elements use printable ASCII characters #x20
> >     > >    (space) - #x7E (~), with high entropy, such as 128 bits.  If non-
> >     > >    ASCII characters are supported with the plain text password, then use
> >     > >    a standard for passwords with international characters, such as the
> >     > >    OpaqueString PRECIS profile in [RFC8265].
> >     > >
> >     > > I think that's adequate, given that (1) we really are expecting that
> >     > > almost all passwords out there are ASCII, and we're recommending
> >     > > keeping it that way, (2) we need to allow, but discourage, non-ASCII
> >     > > UTF-8 passwords for the (expectedly rare) cases where they might be
> >     > > used, and (3) these are stored passwords that are passed around,
> >     > > rather than passwords entered by users and subject to issues created
> >     > > by different input mechanisms and effects on eyeballs.
> >     > >
> >     > > I can see that we might want to change "recommended" to "RECOMMENDED",
> >     > > and I don't object to that (Jim?).  Beyond that, I'm not sure where
> >     > > you're going with "PRECIS profiles are to be used as part of a
> >     > > protocol as opposed to part of a deployment."  It's really both,
> >     > > depending upon the situation.  In this case, it's saying that if your
> >     > > server supports non-ASCII passwords, you'd better use the OpaqueString
> >     > > profile to handle them.  If your server doesn't (it supports only
> >     >
> >     > I'm much happier with your prose description here than the snippet quoted
> >     > from the document -- what's in the document now seems to be weaker than
> >     > what you say ("pick a standard; PRECIS is a standard" vs "you should use
> >     > PRECIS, though here's an out if you can't for some reason").
> >     >
> >     > My primary concern here is that the client and server need to know to use
> >     > the same standard (whatever it is).  Making this RFC say flatly "use
> >     > PRECIS" is IMO the easiest way to do that, though given how much other
> >     > stuff in EPP has to be set by out-of-band configuration I won't raise a
> >     > fuss if this ends up being another one.  If it does need to be known out of
> >     > band, though, my preference is always for that need to be stated in the
> >     > RFC.
> >     >
> >     > > ASCII passwords), we're good.  From a PRECIS point of view, I don't
> >     > > see more that needs to be done with this.
> >     > >
> >     > > I think a large part of the point of the text that Jim added is an
> >     > > acknowledgement that in the common case of ASCII-only passwords, we
> >     > > don't have to worry about normalization/canonicalization of password
> >     > > strings at all, and just doing straight byte-string comparisons works.
> >     > > And the OpaqueString profile is there for cases where it's needed.
> >     > >
> >     > > Now, it's certainly true that if a server *supports* non-ASCII
> >     > > passwords, then *all* password processing on that server has to use
> >     > > the OpaqueString profile, even if there are not any actual non-ASCII
> >     > > passwords present... just in case one might show up.  And I think the
> >     > > text does say that.
> >     >
> >     > (repeating myself, but I think the text says "all password processing on
> >     > that server has to use the chosen standard for non-ASCII passwords" [which
> >     > is not necessarily the OpaqueString PRECIS profile])
> >     >
> >     > > Is there something in this discussion that I'm missing that I need to
> >     > > address?  Is there specific text you might suggest?  Are there other
> >     > > issues beyond this one that are still open?  How close are we to
> >     > > resolving this?
> >     >
> >     > I think just adding the extra background and your sense of what the text is
> >     > trying to convey has been a big help.  I would suggest rewording to:
> >     >
> >     >   [...].  If non-
> >     >   ASCII characters are supported with the plain text password, then use
> >     >   a standard for passwords with international characters; the
> >     >   OpaqueString PRECIS profile in [RFC8265] is recommended in the absence of
> >     >   other considerations.
> >     >
> >     > Your explanation suffices such that I will not require this change to clear
> >     > my Discuss, though.
> >     >
> >     > -Ben
> >
> >