Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)
Barry Leiba <barryleiba@computer.org> Mon, 24 February 2020 15:44 UTC
Return-Path: <barryleiba@gmail.com>
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 A37763A0D83; Mon, 24 Feb 2020 07:44:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 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, URIBL_BLOCKED=0.001] autolearn=no 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 W3YlI-VK45Om; Mon, 24 Feb 2020 07:44:01 -0800 (PST)
Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) (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 B4A5B3A0D86; Mon, 24 Feb 2020 07:43:59 -0800 (PST)
Received: by mail-io1-f54.google.com with SMTP id z1so10684952iom.9; Mon, 24 Feb 2020 07:43:59 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=n/iE9O3feQhSl9plZ6gRRFBTBVHQNDxe4VK3y5XfxVA=; b=R+fv/0GV1Qt8MfQf2U5041DxNK9ECK2KjYh8JJhfg+ay7EY1k6boHiTcXHfne0aw0l 8k5hN00k1Bb4Amvnmf2Q80oIWHySNTKv7PExMR6uh7PkaAOakYcLzUkgCXnkCZ3d9F7D CeraxBZEZMAthWcDzxEh1h0jU7CyfYYjtTywf+oRjWrCtaha3EavTAje70S+zPGXibN0 gxckv9S8OHIQPvW/AQn7G/51XVgX7n4RtttnwVo+Bm2a/9ufQOe29vK/+/X1jwOSCUAa n0hS8ndw6C0YJceG2OPxtZf7pp18zed7getYdsWQoTh/1i+17u/jrd9wyPxOMHIjSzRx 9bwg==
X-Gm-Message-State: APjAAAUg/V7j6BhSAL69hPVROkFqzDLFI/lI6JHQfgeE1Vql0EjYR7qr 0xjCl2uFc+QwvBkeVKfDe7X0BssCk4fRmpbdYU8=
X-Google-Smtp-Source: APXvYqy/rXtEbtP69hLNkPVWCvlU68REyE6uanGk3FxKADN/7U1Ieyhc/s6HBOsbNulVUPaP0qS6XbZ9ov4T0x3Yxj0=
X-Received: by 2002:a5d:9b94:: with SMTP id r20mr21584963iom.140.1582559038650; Mon, 24 Feb 2020 07:43:58 -0800 (PST)
MIME-Version: 1.0
References: <639F7D2A-A0D7-4DB6-B846-2A75589E4466@verisign.com>
In-Reply-To: <639F7D2A-A0D7-4DB6-B846-2A75589E4466@verisign.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Mon, 24 Feb 2020 07:43:47 -0800
Message-ID: <CALaySJKiGEJgwurOfEtB_drjF+miiu-SWUvwXGj+i348GBg9jA@mail.gmail.com>
To: "Gould, James" <jgould@verisign.com>
Cc: "kaduk@mit.edu" <kaduk@mit.edu>, "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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/LrfE4WxpzDZpKPsFQMxyfQM4ed8>
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 15:44:03 -0000
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 > >
- [regext] Benjamin Kaduk's Discuss on draft-ietf-r… Benjamin Kaduk via Datatracker
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Gould, James
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Gould, James
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Gould, James
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Barry Leiba
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Gould, James
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Barry Leiba
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Gould, James
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Barry Leiba
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Gould, James
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Benjamin Kaduk
- Re: [regext] Benjamin Kaduk's Discuss on draft-ie… Gould, James