Re: [kitten] [Technical Errata Reported] RFC6680 (4337)

Benjamin Kaduk <kaduk@MIT.EDU> Mon, 20 April 2015 18:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A27751B2CB5 for <>; Mon, 20 Apr 2015 11:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XtfYT9TiOiFS for <>; Mon, 20 Apr 2015 11:03:23 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD1E91B2CB2 for <>; Mon, 20 Apr 2015 11:03:22 -0700 (PDT)
X-AuditID: 1209190e-f79a76d000000d1b-e3-55353f696152
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 37.BA.03355.96F35355; Mon, 20 Apr 2015 14:03:21 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t3KI3KrW026256; Mon, 20 Apr 2015 14:03:20 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t3KI3HCO023379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Apr 2015 14:03:18 -0400
Received: (from kaduk@localhost) by ( id t3KI3GFN021226; Mon, 20 Apr 2015 14:03:16 -0400 (EDT)
Date: Mon, 20 Apr 2015 14:03:16 -0400 (EDT)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Nico Williams <>
In-Reply-To: <20150419230843.GP13041@localhost>
Message-ID: <>
References: <> <> <> <20150419230843.GP13041@localhost>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEKsWRmVeSWpSXmKPExsUixG6nrptpbxpqcHeyhsXXtgdsFg078y2O bl7FYrGgdyuzxeeHt1ktTl07wmbRtP8rm8W9LZfYLabvvcbuwOkx5fdGVo+Xp84xeqztvsrm sXPWXXaPJUt+MnnMPHOR3aOh7Rirx8qpp9k99m7qYw/gjOKySUnNySxLLdK3S+DKOHXyGnvB H4mK+3+fMzcwfhXuYuTkkBAwkTh45TMjhC0mceHeejYQW0hgMZPE1LWFEPZGRokJa8W6GLmA 7ENMEl2PTjNDOA2MEv/3dbCDVLEIaEu83/GIGcRmE1CRmPlmI9gkEQFNievzlrKBNDALLGGW mHAeokhYwFzi/d3HQDYHB6eAvsTUyyUgYV4BR4kXO88wQSxYyihx9tFUsEGiAjoSq/dPYYEo EpQ4OfMJmM0soCWxfPo2lgmMgrOQpGYhSS1gZFrFKJuSW6Wbm5iZU5yarFucnJiXl1qka6yX m1mil5pSuokRFDWcknw7GL8eVDrEKMDBqMTDK2FoEirEmlhWXJl7iFGSg0lJlJfD1DRUiC8p P6UyI7E4I76oNCe1+BCjBAezkgivIDtQjjclsbIqtSgfJiXNwaIkzrvpB1+IkEB6Yklqdmpq QWoRTFaGg0NJgveiLVCjYFFqempFWmZOCUKaiYMTZDgP0PCDIDW8xQWJucWZ6RD5U4yKUuK8 20ASAiCJjNI8uF5YUnvFKA70ijDvP5AqHmBChOt+BTSYCWhw3DYTkMEliQgpqQbGytalOTZp X7TWWV1IOjW5Qn7JrUPyt2XaX+ov15Lfx5Z+de+zTI4dX16duOn+W3HLh5KLG2UVU+fH/Tfe suPlk/O5/11OTJgW0jNXt3LHzJ+8u8SPdO+ZzBK62nyNeM6ee0xNsannzfgX8sqvfJ6cpvL5 xrcrZj2/mlyOtYms/FBjd+gcX8E7MyWW4oxEQy3mouJEAPinm/tFAwAA
Archived-At: <>
Cc: "" <>, Kathleen Moriarty <>, RFC Errata System <>, Sam Hartman <hartmans-ietf@MIT.EDU>, "" <>
Subject: Re: [kitten] [Technical Errata Reported] RFC6680 (4337)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Apr 2015 18:03:24 -0000

On Sun, 19 Apr 2015, Nico Williams wrote:

> On Sun, Apr 19, 2015 at 04:19:40PM -0400, Sam Hartman wrote:
> > I really don't think we considered blocking when developing 6680.
> > I think this is something that if we're going to discuss we need a full
> > IETF consensus to say.
> I did think about it, though I don't recall specific on-the-list
> discussions about it, I'm certain I discussed it with someone.  In
> particular I had wanted to consider UID/GID/SID lookups.  My intention
> was roughly as per-Ben's proposed text.
> > I think that the proposed text would be a good starting point, for this
> > API.
> > My concern is that other APIs in the document might block, and that I
> > think that a WG such as kitten should fully consider the issue rather
> > than using the erata process for this issue.
> I object neither to the erratum, nor to an update.  I think this erratum
> is sufficient for now, and we can work on an update to specify blocking
> behavior in more detail.

It sounds like the main objection to the current proposed erratum text is
in the COMMENT, "Calls which are not explicitly permitted to block are
assumed to be not permitted to block."  Though the new text which
explicitly calls out the attrs output of GSS_Inquire_name() does still
have some implicit implications that some calls do not block, as well.

I am not tied to the comment text; we could remove it and still have an
erratum which stands on its own.  It is a bit harder to excise the
implicit implication from the new text.

> We could update the erratum to add a list of what should be
> non-controversial non-blocking behaviors:
>  - GSS_Inquire_name() (of course, otherwise Ben's text doesn't work)
>  - GSS_Get_name_attribute() for attributes listed by GSS_Inquire_name()
>  - GSS_Export_name_composite()
>    (and any call to GSS_Import_name() to import an exported composite
>    name token)
> We might also want to say that specific attributes not listed by
> GSS_Inquire_name() may yield blocking or non-blocking behavior in
> GSS_Get/Set_name_attribute() according to the attributes'
> specifications.
> > I'll note that we cannot really say that a call never blocks.  An
> > implementation may have network swap or executable segments that are
> > demand page over a network filesystem.  An implementation may use
> > nsswitch resources that consult network databases, etc.
> > The best we can say is that it's reasonable to write applications
> > assuming certain APIs do not generally block.
> Yes.  Defining "non-blocking" and "blocking" is non-trivial.  What kinds
> of I/O are slow (network) or fast (per-Unix: file I/O is fast)?  Does a
> long-running CPU-bound computation count as blocking?

These both are getting to seem like fairly substantial changes which do
not seem appropriate for an erratum, to me.  It's also unclear that the WG
has sufficient energy to do a full 6680bis right now.

I will also note that we can choose to mark the current (small) 6680
erratum as Verified or Hold for Document Update, if we want to accept it;
the latter may be more appropriate given Sam's concerns.