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

Benjamin Kaduk <> Sat, 22 February 2020 06:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7155D120123; Fri, 21 Feb 2020 22:08:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YDJ0rWH9gQn3; Fri, 21 Feb 2020 22:08:48 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1C49312006D; Fri, 21 Feb 2020 22:08:47 -0800 (PST)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 01M68gKs014436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 22 Feb 2020 01:08:44 -0500
Date: Fri, 21 Feb 2020 22:08:42 -0800
From: Benjamin Kaduk <>
To: Barry Leiba <>
Cc: "Gould, James" <>, "" <>, The IESG <>, "" <>
Message-ID: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.12.1 (2019-06-15)
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 06:08:51 -0000

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

> 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.