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

Barry Leiba <> Sat, 22 February 2020 23:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1AAB63A0A4E; Sat, 22 Feb 2020 15:15:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hJl6OztuWRZU; Sat, 22 Feb 2020 15:15:52 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A90CB3A0A4D; Sat, 22 Feb 2020 15:15:52 -0800 (PST)
Received: by with SMTP id g12so4737639ild.2; Sat, 22 Feb 2020 15:15:52 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xmUfXqJLal86qh9/tsS//WdiKJ1dOJYnGz3lIr2BE1k=; b=pN0UBGHx4o2L70Hm1J4JKNP9qmSArc1QqR8ftz7wvj1pJH8XFijHhBl0SeAD9e0vot QNhy7TFvYC070QrX36ZifCXP8yjHMBlZY8+GO2Sf7sXAXsqLgJRkFo149hmaJXrIfJQu 3X9KTpUdsIavDkW5sWgSwTMHfJzKe8MCZhpaXek7eGG8pGBHWYQabRDAOh8UpuoJLqMz 5GWWd+jIyWIIVvQgcyCRCghFelKaSpO/gNVHsg2Y1ESVXO1JvOjb5Cz/3RoYptDU7a4P Cv+EiXb75r8MaJXMCpMdRNDSHp1N02VRmGamCBIF+lZ0+JuZ5myhXUE97me1qYGdu6Tg Su9A==
X-Gm-Message-State: APjAAAXWpnM8+c+LE5es4nAy1crGM6089bbihhvbdXz8Q6D56+mVSCLX 2rEb602tnFXE4b2hMTXzwb5299BJ5oipSM/V4sZ2GA==
X-Google-Smtp-Source: APXvYqzSJaaDAk8cjSuZ0/MEo/AwgX0MS25M122u3sdabd1dxW/81btwFbBhUNw6U4MZzF6+kkW3iTT8t/XY89jXoTs=
X-Received: by 2002:a92:2907:: with SMTP id l7mr47377189ilg.140.1582413351721; Sat, 22 Feb 2020 15:15:51 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Barry Leiba <>
Date: Sat, 22 Feb 2020 15:15:40 -0800
Message-ID: <>
To: Benjamin Kaduk <>
Cc: "Gould, James" <>, "" <>, The IESG <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 22 Feb 2020 23:15:54 -0000

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.


On Fri, Feb 21, 2020 at 10:08 PM Benjamin Kaduk <> 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