Re: [precis] Gen-art last call review of draft-ietf-precis-7613bis-07

Peter Saint-Andre - Filament <peter@filament.com> Tue, 27 June 2017 01:41 UTC

Return-Path: <peter@filament.com>
X-Original-To: precis@ietfa.amsl.com
Delivered-To: precis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7E812EB9A for <precis@ietfa.amsl.com>; Mon, 26 Jun 2017 18:41:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=filament-com.20150623.gappssmtp.com
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 0C-ERk14xyl7 for <precis@ietfa.amsl.com>; Mon, 26 Jun 2017 18:41:16 -0700 (PDT)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 CE7621286CA for <precis@ietf.org>; Mon, 26 Jun 2017 18:41:15 -0700 (PDT)
Received: by mail-io0-x22a.google.com with SMTP id h134so10364427iof.2 for <precis@ietf.org>; Mon, 26 Jun 2017 18:41:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filament-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=dFD9Zk6KlY8UN368gfze5cwKU3iepFsuuBSNkFkZ6yU=; b=xMxx7oNdR0r2xNgCiGkCcOTTkfebjJYmN76oDjxWkjcqAolT9Ke1bP71ZyxocgpVSI jRSMecL/fig2aN5WTZrtJgWN4V2HGcybxVwP0aYrDCO5mkUwu2WY44mjskC5pJ21rJCQ j7yZ0R9yimlQpBVDtOoBxRIfzycfLtfjucNBmX8c8BkHh6SFH4bTF5BFJVU9j6vFK4up FWZb55Zlq0JHJn0HOfDppMJGBHaq3VdUyINL2LWhcCgfFkh732qD5n/DE7YOSrUS5co7 6T4yXvJi/RD4EcfFR9wTE3JN+UzRnWADyXbm3dQS/2fbNvHQvYDgijUI+9mjjqAqttPR jlVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=dFD9Zk6KlY8UN368gfze5cwKU3iepFsuuBSNkFkZ6yU=; b=msTyHD5y71+3i9n1XG5bN/+VqMXN5edsInmObvJJYPTliLUFAjfujaob9BqOyZlO/v ftF/sytqUoVHfuQOQw4TIDCo3ZpE8xjwBPtKVyl0KaCTW/WiX9XAuNuW8P5IS1qTi5qQ K65r65WEqrxdeExmsV0widQE5sS0R6yJuimvXrENohY2/vKXheyNVXRima2O7Tv5u0AD FA5qck32wP43O7isWGa8nEK5h8mqpjynBDaI0XVwF8+/Rycca6xr+duy/2Ylp1qSZWfU Df2dWJsX28/2hHTT9RDNrKUVxSmZnjMKsBxPuJ0V8mhmNtvgY7NcpRt6cSnwOK9nW3jP QE9A==
X-Gm-Message-State: AKS2vOx7wvWOcObuG4EF6iwMY5lWm0U9yvAGfVs2/2bB5Lguiw/FpwUW fLbG6g/a/bKz7tUP
X-Received: by 10.107.169.28 with SMTP id s28mr4696808ioe.1.1498527675181; Mon, 26 Jun 2017 18:41:15 -0700 (PDT)
Received: from aither.local ([2601:282:4202:67d3:5c8c:f89e:d54d:fabe]) by smtp.gmail.com with ESMTPSA id z64sm916712iod.55.2017.06.26.18.41.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jun 2017 18:41:11 -0700 (PDT)
To: Peter Saint-Andre - Filament <peter@filament.com>, Linda Dunbar <linda.dunbar@huawei.com>, "gen-art@ietf.org" <gen-art@ietf.org>
References: <4A95BA014132FF49AE685FAB4B9F17F6593D94F9@SJCEML702-CHM.china.huawei.com> <3feb4084-d038-9253-fc48-e739d846102f@filament.com>
Cc: "precis@ietf.org" <precis@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-precis-7613bis@ietf.org" <draft-ietf-precis-7613bis@ietf.org>
From: Peter Saint-Andre - Filament <peter@filament.com>
Message-ID: <f070d840-792d-8447-4e2a-f919019adff1@filament.com>
Date: Mon, 26 Jun 2017 19:41:09 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <3feb4084-d038-9253-fc48-e739d846102f@filament.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/precis/s5GbO6PnlxU-FR_ofUgVK3ZWnQ4>
Subject: Re: [precis] Gen-art last call review of draft-ietf-precis-7613bis-07
X-BeenThere: precis@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Preparation and Comparison of Internationalized Strings <precis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/precis>, <mailto:precis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/precis/>
List-Post: <mailto:precis@ietf.org>
List-Help: <mailto:precis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/precis>, <mailto:precis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Jun 2017 01:41:18 -0000

On 6/26/17 5:48 PM, Peter Saint-Andre - Filament wrote:
> Hi Linda,
> 
> Thanks for your review. Comments inline.
> 
> On 6/26/17 4:53 PM, Linda Dunbar wrote:
>>  
>> Reviewer: Linda Dunbar
>> Review result: Ready
>>  
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed by the
>> IESG for the IETF Chair.  Please treat these comments just like any
>> other last call comments.
>>  
>> For more information, please see the FAQ at
>>  
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>  
>> Document: draft-ietf-precis-7613bis
>> Reviewer: Linda Dunbar
>> Review Date: 2017-06-25
>> IETF LC End Date: 2017-06-27
>> IESG Telechat date: 2017-07-06
>>  
>> Summary:
>> The document is written very clear. Even for a person who is not
>> familiar with the App area, I can follow through the description. The
>> document is ready for publication as standard track document Major issues:
>>  
>> One Minor issue:
>>  
>> Page 6 last paragraph has:
>> /SASL mechanisms SHOULD delay any case////mapping to the last possible
>> moment, such as when doing a lookup////by username, performing username
>> comparisons, or generating a////cryptographic salt from a username (if
>> the last possible moment////happens on the server, then decisions about
>> case mapping can be a////matter of deployment policy). In keeping with
>> [RFC4422], SASL////mechanisms are not to apply this or any other profile
>> to////authorization identifiers, only to authentication identifiers./
>>  
>> What does "last possible moment" mean? When I read it, I thought it
>> meant wait until you got all the characters. But the next sentence
>> mentions "..happens on the server". How is the "server" related to the
>> entity that check the user name & password? 
> 
> Many authentication decisions happen on an application server to which a
> user-oriented client connects (think of an email client connecting to an
> email server). By "last possible moment" we're referring to processing
> within the application server or an authentication module thereof - for
> instance, instead of performing case mapping on first receiving data
> from the client (thus implying that the case information is lost through
> most of the processing stages), it's better to lose that information
> only at the very end. Do you feel it would it help to add a more
> detailed description of the reasoning here?

Here is a proposed adjustment to the text:

OLD

      SASL mechanisms SHOULD delay any case
      mapping to the last possible moment, such as when doing a lookup
      by username...

NEW

      Because case mapping results in
      information loss, in order to retain that information for as long
      as possible during processing, implementations SHOULD delay any
      case mapping to the last possible moment, such as when doing a
      lookup by username...

Peter