From nobody Wed Jun 1 03:46:25 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9830912B059 for ; Wed, 1 Jun 2016 03:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.348 X-Spam-Level: X-Spam-Status: No, score=-8.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 1x6T01-e0ocj for ; Wed, 1 Jun 2016 03:46:21 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C65512B027 for ; Wed, 1 Jun 2016 03:46:21 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D236737E72; Wed, 1 Jun 2016 10:46:20 +0000 (UTC) Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.128.7]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u51AkIZe026672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2016 06:46:20 -0400 To: Nico Williams References: <1463500163.2432.9.camel@redhat.com> <20160519162545.GB19530@localhost> <1463676437.31173.36.camel@redhat.com> <9533fb26-6513-caca-efbc-158ebf6ca408@redhat.com> <20160520150629.GH19530@localhost> From: Petr Spacek Organization: Red Hat Message-ID: <15d233ce-0c10-f13e-b87c-8b942163736d@redhat.com> Date: Wed, 1 Jun 2016 12:46:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160520150629.GH19530@localhost> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 01 Jun 2016 10:46:20 +0000 (UTC) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 10:46:23 -0000 On 20.5.2016 17:06, Nico Williams wrote: > On Fri, May 20, 2016 at 09:26:42AM +0200, Petr Spacek wrote: >> On 19.5.2016 18:47, Nathaniel McCallum wrote: >>> On Thu, 2016-05-19 at 11:25 -0500, Nico Williams wrote: >>>> - Perhaps we should have our own RR type. In principle it's easy to >>>> add them, but: >> >> Any new RR type will be in worse position than URI because of reasons you >> stated below. > > Exactly. For the record, opinions of DNS gurus from dnsop list can be found in dnsop archives: http://www.ietf.org/mail-archive/web/dnsop/current/msg17526.html Message http://www.ietf.org/mail-archive/web/dnsop/current/msg17527.html indicates that it might be possible to standardize TXT if you try it. Message http://www.ietf.org/mail-archive/web/dnsop/current/msg17534.html argues that URI is good enough and that TXT is a bad practice. Pick an answer which suits you the best :-) > >>>> - If new RR types are the answer, then the DNS community needs to do >>>> something about UIs. For example, there could be an XML schema >>>> defining RR types' RDATA contents and UI elements. Then >>>> implementors could automatically translate those to code to >>>> implement UIs for new RR types. >> >> Oh yes, this is my plan for some time already but it always gets lower >> priority than something else ... I would not wait for it :-) > > Er, OK, how do we help you implement it? :) Personally I think that this can be solved by some clever usage of an existing bidirectional language + some metadata. My experience with Augeas shows that it works quite well and that people ironed out a lot of details and difficult corner cases so might be worth investigating this direction. If you do not like bidirectional languages look at https://datatracker.ietf.org/doc/draft-levine-dnsextlang/ and implement it :-) Have a nice day! Petr Spacek @ Red Hat >> More importantly, there was literally no usage & demand for the URI >> record up to now. Adding new RR types to UI is trivial as soon as you >> have justification for the management, so the demand could simply >> solve the UI problem for the URI RR type. > > Well, I hope so! The UI for URI is going to be very similar to the UI > for SRV. > > A machine-readable description of what the UI should be for each RR type > would have made this problem a non-problem, and might yet. > >>>> - Can you ask some DNS hosters to inveigh as to whether they would >>>> be willing to add arbitrary new RR types? (Presumably with a UI >>>> that requires the user to paste base64-/hex-encoded RDATA.) >> >> We have a standard for Handling of Unknown DNS RR Types: >> https://tools.ietf.org/html/rfc3597 >> >> It says that RDATA for unknown types should be typed in using hexadecimal >> notation: >> https://tools.ietf.org/html/rfc3597#section-5 > > Thanks. > >> Also, some servers/services simply lack UI (e.g. Windows Server 2003) >> but allow adding the record using standard DNS UPDATE protocol RFC >> 2136, which is also behavior mandated by RFC 3597. > > That's nice, but the services that Nathaniel is concerned about probably > don't support DNS UPDATEs. > > That's another thing. Implementations that support DNS UPDATE often > don't have useful authorization models, leading enterprises often to > having to write proxies [that invariably do not themselves speak DNS > UPDATE]. I'm not sure that a standard can help there, but I think it > might. One idea would be to associate authorization attributes to each > RR type and RRset name pattern so that the DNS server could evaluate the > DNS UPDATE client's authorization to perform a given operation. E.g., > the owner(s) of a given domainname (should ownership and/or ACLs be > expressible within DNS?) might get to manage associated SRV RRsets, and > maybe (subject to site-local policy) add/delete CNAMEs pointing to that > name, but maybe not modify the A/AAAA RRsets -- the "associated" bit > would be nice if it were expressed in a standard, while which operations > are allowed should be locally expressible based on simple labels for > each association, say. > > Nico > -- Petr Spacek @ Red Hat From nobody Thu Jun 2 10:22:18 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A61412D777 for ; Thu, 2 Jun 2016 10:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 xLGlEPrYoBQ3 for ; Thu, 2 Jun 2016 10:22:15 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97BD412B057 for ; Thu, 2 Jun 2016 10:22:13 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 7B709768083; Thu, 2 Jun 2016 10:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=4qHpMaybvpHtp+ BvRJHoWuMcwWc=; b=MTnK7kydBeKGSGPEgw715KiELxqHsoFAdmYZvgo68xMglB Y7zkNM1DYQGNZRRoMlgGI1vdIGJHSAH4jn51LM09yvP63iAmpns/vDA/vcHGuC5B m04oIMStAA582sItNP8XbfrFAPz41wGRDkU6LYunNOOSpzKNvQcfbXR8+6yu0= Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 69D8F768094; Thu, 2 Jun 2016 10:21:12 -0700 (PDT) Date: Thu, 2 Jun 2016 12:21:01 -0500 From: Nico Williams To: Petr Spacek Message-ID: <20160602172059.GA4935@localhost> References: <1463500163.2432.9.camel@redhat.com> <20160519162545.GB19530@localhost> <1463676437.31173.36.camel@redhat.com> <9533fb26-6513-caca-efbc-158ebf6ca408@redhat.com> <20160520150629.GH19530@localhost> <15d233ce-0c10-f13e-b87c-8b942163736d@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15d233ce-0c10-f13e-b87c-8b942163736d@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 17:22:17 -0000 On Wed, Jun 01, 2016 at 12:46:18PM +0200, Petr Spacek wrote: > On 20.5.2016 17:06, Nico Williams wrote: > > Er, OK, how do we help you implement it? :) > > Personally I think that this can be solved by some clever usage of an existing > bidirectional language + some metadata. I'm not sure what you mean. "Bi-directional language", to me, refers to natural languages where writing is done in two directions. > My experience with Augeas shows that it works quite well and that people > ironed out a lot of details and difficult corner cases so might be worth > investigating this direction. The configuration editing tool?? > If you do not like bidirectional languages look at > https://datatracker.ietf.org/doc/draft-levine-dnsextlang/ > and implement it :-) My preference would be to use XML (I know, I know[*]), mostly because people could (and almost certainly would) then write XSLs to generate client- and maybe server-side code for dealing with unknown RR types. Mostly you just need to generate a tiny bit of HTML and JavaScript to present a UI specific to any given RR type, type-check user inputs, provide help bubbles and such, format the RDATA with valid user inputs, and produce hex-encoded RDATA that the server can then use (the server doesn't need to validate the RDATA, but it could do that too, also with generated code). [*] XSLT is what makes XML tolerable and even desirable for this task. I suppose one would have to... design an XML schema for this, write an I-D and sample XSLs, submit, and see if dnsop has interest. I don't have the cycles for this :( Nico -- From nobody Fri Jun 3 09:34:08 2016 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E58412D719; Fri, 3 Jun 2016 09:34:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160603163406.1406.70036.idtracker@ietfa.amsl.com> Date: Fri, 03 Jun 2016 09:34:06 -0700 Archived-At: Cc: kitten@ietf.org, kitten-chairs@ietf.org, linuxwolf@outer-planes.net Subject: [kitten] kitten - Not having a session at IETF 96 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 16:34:06 -0000 Matthew Miller, a chair of the kitten working group, indicated that the kitten working group does not plan to hold a session at IETF 96. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Mon Jun 6 06:38:37 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0153312D79F for ; Mon, 6 Jun 2016 06:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.328 X-Spam-Level: X-Spam-Status: No, score=-8.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 D4D_F6Vh9RLs for ; Mon, 6 Jun 2016 06:38:34 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82DBE12D095 for ; Mon, 6 Jun 2016 06:38:34 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4E76B64089 for ; Mon, 6 Jun 2016 13:38:33 +0000 (UTC) Received: from pspacek.brq.redhat.com (ovpn-204-43.brq.redhat.com [10.40.204.43]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u56DcVE0002846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 6 Jun 2016 09:38:32 -0400 To: kitten@ietf.org References: <1463500163.2432.9.camel@redhat.com> <20160519162545.GB19530@localhost> <1463676437.31173.36.camel@redhat.com> <9533fb26-6513-caca-efbc-158ebf6ca408@redhat.com> <20160520150629.GH19530@localhost> <15d233ce-0c10-f13e-b87c-8b942163736d@redhat.com> From: Petr Spacek Organization: Red Hat Message-ID: Date: Mon, 6 Jun 2016 15:38:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <15d233ce-0c10-f13e-b87c-8b942163736d@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 06 Jun 2016 13:38:33 +0000 (UTC) Archived-At: Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 13:38:36 -0000 On 1.6.2016 12:46, Petr Spacek wrote: > On 20.5.2016 17:06, Nico Williams wrote: >> > On Fri, May 20, 2016 at 09:26:42AM +0200, Petr Spacek wrote: >>> >> On 19.5.2016 18:47, Nathaniel McCallum wrote: >>>> >>> On Thu, 2016-05-19 at 11:25 -0500, Nico Williams wrote: >>>>> >>>> - Perhaps we should have our own RR type. In principle it's easy to >>>>> >>>> add them, but: >>> >> >>> >> Any new RR type will be in worse position than URI because of reasons you >>> >> stated below. >> > >> > Exactly. > For the record, opinions of DNS gurus from dnsop list can be found in dnsop > archives: > http://www.ietf.org/mail-archive/web/dnsop/current/msg17526.html > > Message > http://www.ietf.org/mail-archive/web/dnsop/current/msg17527.html > indicates that it might be possible to standardize TXT if you try it. > > Message > http://www.ietf.org/mail-archive/web/dnsop/current/msg17534.html > argues that URI is good enough and that TXT is a bad practice. > > Pick an answer which suits you the best :-) BTW the discussion continues on krbdev mailing list and wiki, for some reason people there gave up on kitten... http://mailman.mit.edu/pipermail/krbdev/2016-June/012605.html -- Petr Spacek @ Red Hat From nobody Mon Jun 6 06:45:18 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4C112D7A8 for ; Mon, 6 Jun 2016 06:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.328 X-Spam-Level: X-Spam-Status: No, score=-8.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 3SC_LTDDxi00 for ; Mon, 6 Jun 2016 06:45:11 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CAA412D7A9 for ; Mon, 6 Jun 2016 06:45:11 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 20946112772; Mon, 6 Jun 2016 13:45:11 +0000 (UTC) Received: from pspacek.brq.redhat.com (ovpn-204-43.brq.redhat.com [10.40.204.43]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u56Dj8X7017180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jun 2016 09:45:10 -0400 To: Nico Williams References: <1463500163.2432.9.camel@redhat.com> <20160519162545.GB19530@localhost> <1463676437.31173.36.camel@redhat.com> <9533fb26-6513-caca-efbc-158ebf6ca408@redhat.com> <20160520150629.GH19530@localhost> <15d233ce-0c10-f13e-b87c-8b942163736d@redhat.com> <20160602172059.GA4935@localhost> From: Petr Spacek Organization: Red Hat Message-ID: <2cfa33ef-1a6c-ed8b-5707-20e355bab522@redhat.com> Date: Mon, 6 Jun 2016 15:45:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160602172059.GA4935@localhost> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 06 Jun 2016 13:45:11 +0000 (UTC) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 13:45:17 -0000 On 2.6.2016 19:21, Nico Williams wrote: > On Wed, Jun 01, 2016 at 12:46:18PM +0200, Petr Spacek wrote: >> On 20.5.2016 17:06, Nico Williams wrote: >>> Er, OK, how do we help you implement it? :) >> >> Personally I think that this can be solved by some clever usage of an existing >> bidirectional language + some metadata. > > I'm not sure what you mean. "Bi-directional language", to me, refers to > natural languages where writing is done in two directions. I'm sorry for being terse but the long answer is here: https://www.cis.upenn.edu/~bcpierce/papers/lenses-etapsslides.pdf "Need to find a way of deriving both functions from a single description" (of RR type in our case). Of course the description could be encoded in any format. The main point is that this conversion should be based on very solid theory to eliminate risk of encode()/decode() inconsistencies. >> My experience with Augeas shows that it works quite well and that people >> ironed out a lot of details and difficult corner cases so might be worth >> investigating this direction. > > The configuration editing tool?? Yes, Augeas is using an bidirectional language. >> If you do not like bidirectional languages look at >> https://datatracker.ietf.org/doc/draft-levine-dnsextlang/ >> and implement it :-) > > My preference would be to use XML (I know, I know[*]), mostly because > people could (and almost certainly would) then write XSLs to generate > client- and maybe server-side code for dealing with unknown RR types. > > Mostly you just need to generate a tiny bit of HTML and JavaScript to > present a UI specific to any given RR type, type-check user inputs, > provide help bubbles and such, format the RDATA with valid > user inputs, and produce hex-encoded RDATA that the server can then use > (the server doesn't need to validate the RDATA, but it could do that > too, also with generated code). > > [*] XSLT is what makes XML tolerable and even desirable for this task. > > I suppose one would have to... design an XML schema for this, write an > I-D and sample XSLs, submit, and see if dnsop has interest. I don't > have the cycles for this :( I share the same problem :-( -- Petr Spacek @ Red Hat From nobody Mon Jun 20 20:58:18 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25E112D8D3 for ; Mon, 20 Jun 2016 20:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham 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 7IyR3b1xJTU2 for ; Mon, 20 Jun 2016 20:58:15 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532A012D6AD for ; Mon, 20 Jun 2016 20:58:15 -0700 (PDT) X-AuditID: 12074422-a8fff70000000173-1c-5768bb54be4f Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 83.11.00371.45BB8675; Mon, 20 Jun 2016 23:58:14 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u5L3wBk5030656 for ; Mon, 20 Jun 2016 23:58:12 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u5L3w9gF003821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 20 Jun 2016 23:58:11 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u5L3w8If012872; Mon, 20 Jun 2016 23:58:08 -0400 (EDT) Date: Mon, 20 Jun 2016 23:58:08 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org Message-ID: 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+NgFtrCIsWRmVeSWpSXmKPExsUixG6nrhu2OyPc4PZPXoujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY9vlPtaC+5IVu17MYW1gfCzSxcjJISFgIrH4wkS2LkYuDiGB NiaJD8dfMUE4xxklPrQtZIFwbjBJnLnXyQ7hNDBKrH6wmRWkn0VAW+L+z3dsIDabgIrEzDcb wWwRAWGJ3VvfMYPYwgKOEmd7LrKD2LxA9oN5P5lAbFEBHYnV+6ewQMQFJU7OfAJmMwtoSSyf vo1lAiPvLCSpWUhSCxiZVjHKpuRW6eYmZuYUpybrFicn5uWlFuma6uVmluilppRuYgQHjovS DsaJ/7wOMQpwMCrx8CroZ4QLsSaWFVfmHmKU5GBSEuVlVgYK8SXlp1RmJBZnxBeV5qQWH2KU 4GBWEuH12A6U401JrKxKLcqHSUlzsCiJ8wZFHgsTEkhPLEnNTk0tSC2CycpwcChJ8PLsAmoU LEpNT61Iy8wpQUgzcXCCDOcBGu4GUsNbXJCYW5yZDpE/xagoJc7rshMoIQCSyCjNg+sFR/Zu JtVXjOJArwjz8oG08wCTAlz3K6DBTECDl/WngwwuSURISTUwRkpMORK5yD/WWNks8JbVbAFp pvK/X5YHnbf7yxtjvU3pa9dbc/+nBpfvf/2TdXuBy1T1/k3LF0b882kv3llWysy1/nH+Ea3U KkY767cBdt/b2Vrlp3xP0b7599bMPfO72rUa2nUrEw+0zPi9J5YnS/CazpWOy6WrxcW/fayY sp4zZ5PAZGcnJZbijERDLeai4kQAtg7zHscCAAA= Archived-At: Subject: [kitten] Proposal for tracking document reviews and skipping WGLC X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 03:58:17 -0000 Hi all, At our IETF 95 session, Stephen pointed out that the chairs do not necessarily need to run a WGLC in order to make an assessment that there is working group consensus for any given document; the WGLC procedure is a customary way to do so but is not enshrined as a formal procedure. Given the [not-so-]recent discussion about document adoption, document backlog, potentially abandoning old documents, and prioritizing upcoming work, it seems reasonable to revisit our processes for finishing documents. In particular, with our WGLCs sometimes being extended to get enough comments and not usually bringing in input from a large body of participants, as well as the behind-the-scenes cajoling that the chairs have beein doing to solicit document reviews, it is attractive to consider a way to be able to move documents forward without needing a WGLC. It seems that some of the difficulty with the traditional WGLC process stems from many WG participants not having regular (weekly or more frequent) time in which to contribute, so the WGLC could stall until participants' availabilities line up. As an attempt to remedy the difficulty of coordinating everyone's schedule, we propose to create a wiki page (or pages) where each document can have a table of who has reviewed what version(s) of that document, with a link to the review. The actual mechanics of doing a review would not necessarily change; mail still needs to go to the list with comments and discussion, but this wiki page would help us (authors, chairs, and participants) to track which documents are getting attention and which might be ready to move on. [0] Once the chairs think that a given document has received sufficient review, we can send a message to the list noting our intention to move it forward, and start on the shepherd writeup. In some sense this would still serve as a WGLC, in that it would be the "last call" for objections from the WG, but we would not have to block for a period of time waiting for comments even if the document was in fact ready; the comments would already be in, and the shepherd writeup could proceed in parallel with asking if there are objections. If this proposal moves forward, there is a question of where to host the wiki page: two choices that came up so far are a github wiki or an IETF-hosted trac wiki, but we are not tied to those two options. My understanding is that either one would require an account tied to that provider in order to edit (to avoid wiki spam), so there would be some barrier to entry in either case. However, perhaps more people already have github accounts than IETF trac accounts, which lends some preference to github; indeed, other WGs are using github for document editing and issue tracking already. Regardless of where the wiki is hosted, a wiki account would not be needed in order to participate in document review; comments can always be sent to the mailing list and the chairs are able to edit the wiki page on behalf of others. Does this proposal seem reasonable? Thanks, Ben for the kitten chairs [0] This also serves as a way for an author to build good will by reviewing other peoples' documents on the principle of "I reviewed yours; please review mine". From nobody Tue Jun 21 02:03:26 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DA412B03E for ; Tue, 21 Jun 2016 02:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 I1Uv_92GlJsv for ; Tue, 21 Jun 2016 02:03:23 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D42CC12B00C for ; Tue, 21 Jun 2016 02:03:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A55ABBDF9; Tue, 21 Jun 2016 10:03:21 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XElTogzEqoYl; Tue, 21 Jun 2016 10:03:17 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D28BFBE38; Tue, 21 Jun 2016 10:03:16 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1466499797; bh=OYiFeExSSAxqIdc3abUe6q5cLU/y+OnHoB6azSRRT2s=; h=Subject:To:References:From:Date:In-Reply-To:From; b=36Qa+hWUP5WR4bZYPX8Uv0G5MMNkTQW8oz/EtlD0KOLOm+LTu3d6Rc/6+/hptiS7m KSXY/B28socCsKMQ6sbc9OZ4KBMHqjGROPDvxONY5zQT3FbVogXX87cyri6/08QzpP oSktUSGUWp2A6LL89mn1fXUaRq8K051xwDqCSWvM= To: Benjamin Kaduk , kitten@ietf.org References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <576902D4.5080303@cs.tcd.ie> Date: Tue, 21 Jun 2016 10:03:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000308080100090501020709" Archived-At: Subject: Re: [kitten] Proposal for tracking document reviews and skipping WGLC X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 09:03:24 -0000 This is a cryptographically signed message in MIME format. --------------ms000308080100090501020709 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Just for the record: I think this is a fine thing to try for a while, and thanks to the chairs for being willing. I hope the WG are also willing to give it a shot as I figure we need to make IETF stuff easier for WGs like kitten that maintain important protocols through what will sometimes be relatively "low energy" periods. S. On 21/06/16 04:58, Benjamin Kaduk wrote: > Hi all, >=20 > At our IETF 95 session, Stephen pointed out that the chairs do not > necessarily need to run a WGLC in order to make an assessment that ther= e > is working group consensus for any given document; the WGLC procedure i= s a > customary way to do so but is not enshrined as a formal procedure. Giv= en > the [not-so-]recent discussion about document adoption, document backlo= g, > potentially abandoning old documents, and prioritizing upcoming work, i= t > seems reasonable to revisit our processes for finishing documents. In > particular, with our WGLCs sometimes being extended to get enough comme= nts > and not usually bringing in input from a large body of participants, as= > well as the behind-the-scenes cajoling that the chairs have beein doing= to > solicit document reviews, it is attractive to consider a way to be able= to > move documents forward without needing a WGLC. It seems that some of t= he > difficulty with the traditional WGLC process stems from many WG > participants not having regular (weekly or more frequent) time in which= to > contribute, so the WGLC could stall until participants' availabilities > line up. >=20 > As an attempt to remedy the difficulty of coordinating everyone's > schedule, we propose to create a wiki page (or pages) where each docume= nt > can have a table of who has reviewed what version(s) of that document, > with a link to the review. The actual mechanics of doing a review woul= d > not necessarily change; mail still needs to go to the list with comment= s > and discussion, but this wiki page would help us (authors, chairs, and > participants) to track which documents are getting attention and which > might be ready to move on. [0] Once the chairs think that a given docum= ent > has received sufficient review, we can send a message to the list notin= g > our intention to move it forward, and start on the shepherd writeup. I= n > some sense this would still serve as a WGLC, in that it would be the "l= ast > call" for objections from the WG, but we would not have to block for a > period of time waiting for comments even if the document was in fact > ready; the comments would already be in, and the shepherd writeup could= > proceed in parallel with asking if there are objections. >=20 > If this proposal moves forward, there is a question of where to host th= e > wiki page: two choices that came up so far are a github wiki or an > IETF-hosted trac wiki, but we are not tied to those two options. My > understanding is that either one would require an account tied to that > provider in order to edit (to avoid wiki spam), so there would be some > barrier to entry in either case. However, perhaps more people already > have github accounts than IETF trac accounts, which lends some preferen= ce > to github; indeed, other WGs are using github for document editing and > issue tracking already. Regardless of where the wiki is hosted, a wiki= > account would not be needed in order to participate in document review;= > comments can always be sent to the mailing list and the chairs are able= to > edit the wiki page on behalf of others. >=20 > Does this proposal seem reasonable? >=20 >=20 > Thanks, >=20 > Ben > for the kitten chairs >=20 >=20 > [0] This also serves as a way for an author to build good will by > reviewing other peoples' documents on the principle of "I reviewed your= s; > please review mine". >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >=20 --------------ms000308080100090501020709 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA2MjEw OTAzMTZaMC8GCSqGSIb3DQEJBDEiBCCZ+XFMn2U3l4Cy/WugRqt7jP60r5eJDJHistrGBgyJ IzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAICPzPqnPJxkSQbrFzf15XF6EbNS1csWAbcx0pn/GG7CaTUMlFrBtn DGC6QuzlGhV0pV3Q7bgEpARW8JGJDtA5ZFSsVU7a8FGcAr9TM4Wu/Rv/DHI6lhYEVpguxb7m kmvPkOcUkNl2Gh89ieL+tDXt5B6CAqahUHYIW4Z1boGuy6ZMBmLd9bAIWQVbIuaskCyV4zmL Fd/BjNk0IpyEBGSELb9I0vVcNIflIeuHyotnmYqe2Pv/yXxrduEREbl38caoBDBcjbxI2r3I Q/zAv4wsUwtAlvh3JoCaO1SQNPN5MN0IiBCtk26QRytQAuLs+8RcyWJxDuMFZMMyjpUMWB6y AAAAAAAA --------------ms000308080100090501020709-- From nobody Tue Jun 21 09:05:47 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CA412D9E9 for ; Tue, 21 Jun 2016 09:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=secure-endpoints.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 uwcjyQAgHzJN for ; Tue, 21 Jun 2016 09:05:44 -0700 (PDT) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91C1612D9C7 for ; Tue, 21 Jun 2016 09:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1466525111; x=1467129911; i=jaltman@secure-endpoints.com; q=dns/txt; h=VBR-Info:Subject:To: References:From:Openpgp:Organization:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type; bh=beuqRkgtk2P/pEtBgYU4oa blstlVD84o72LB968rtRs=; b=LQ8WSa2JO4jn13D0v+avvdArGVCCV2ez/mkOS+ 6hKVbs/IZH31InQLjwpCbWfw5fT8KP7UNAr0HWGMfCS+re7YUwjRg1yXasmiz+6q FJ9b8VaE3+MK4xMsfmlHixQEFlReKB7PORhmkh/emEkn2GbureDLJN8aZKdbPua6 hSLPU= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Tue, 21 Jun 2016 12:05:11 -0400 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Tue, 21 Jun 2016 12:05:09 -0400 Received: from [x.x.x.x] by secure-endpoints.com (Cipher TLSv1:AES-SHA:256) (MDaemon PRO v16.0.2) with ESMTPSA id md50001106672.msg for ; Tue, 21 Jun 2016 12:05:09 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDRemoteIP: 208.125.0.246 X-MDArrival-Date: Tue, 21 Jun 2016 12:05:09 -0400 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=19805b34e8=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org To: Stephen Farrell , kitten@ietf.org References: <576902D4.5080303@cs.tcd.ie> From: Jeffrey Altman Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=http://pgp.mit.edu Organization: Secure Endpoints Inc. Message-ID: Date: Tue, 21 Jun 2016 12:05:05 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <576902D4.5080303@cs.tcd.ie> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090907090305010903090602" Archived-At: Subject: Re: [kitten] Proposal for tracking document reviews and skipping WGLC X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 16:05:46 -0000 This is a cryptographically signed message in MIME format. --------------ms090907090305010903090602 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/21/2016 5:03 AM, Stephen Farrell wrote: >=20 > Just for the record: I think this is a fine thing to try > for a while, and thanks to the chairs for being willing. > I hope the WG are also willing to give it a shot as I figure > we need to make IETF stuff easier for WGs like kitten that > maintain important protocols through what will sometimes > be relatively "low energy" periods. >=20 > S. Stephen, I will point out that even when documents complete WGLC they do not necessarily move forward. For example, https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/ which has been waiting for a write-up for five months. This is a document that not only passed WGLC but has two independent interoperable implementations blocked waiting for assignment of ETYPE and SUMTYPE values by IANA. As a former Kitten chair, the lack of available resources to work on protocol design, documents, and implementations is not new. The GSS/Kerberos community has suffered with resource starvation for decades. Although GSS, Kerberos and other authentication technologies are critical to the functioning of non-web network communications there has never been sufficient funding available to complete even 10% of the work that needs to be accomplished. This is a key factor in the time it takes to get things done. When the WG Chairs and key participants are not funded to work on GSS/Kerberos it is very hard for them to prioritize the work. In the end, none of us are independently wealthy and few of participant's employers pay the participants for this work. As someone who funded one of the independent implementations of https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/ I can tell you that there is little incentive for me to spend those funds in the future if it is going to take 9 months to a year post the expenditure to see the benefits. It makes me appreciate why a company like Microsoft might decide to stop investing in core GSS/Kerberos and instead layer additional complexity on top of what is already standardized. The current development work cycle is well under a year. If we can't standardize a protocol extension in six months it won't be possible to ship products that utilize the functionality. While tooling might help, the underlying issue is lack of qualified developer and reviewer time. In the end, like anything else, that is going to have to be paid for by someone. Thanks for listening. Jeffrey Altman --------------ms090907090305010903090602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DFkwggYVMIIE/aADAgECAhBwEYNf9/MBLeKNZZ697cPvMA0GCSqGSIb3DQEBCwUAMIGmMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5 bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3 MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH NTAeFw0xNTEyMjAwMDAwMDBaFw0xNjEyMjAyMzU5NTlaMIGvMS4wLAYDVQQDDCVQZXJzb25h IE5vdCBWYWxpZGF0ZWQgLSAxNDUwNTc0MTU1Njc5MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFu QHNlY3VyZS1lbmRwb2ludHMuY29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNv bmEgTm90IFZhbGlkYXRlZDEfMB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM0X8uixbo9Tu+sKS20bZeCbN9brFQbtkQ5x /6MrkGsQNTzQ/2WZFJzH89ZoC8auZRFQdA6/yh4wXdCNQ6hBO8Lom26t0LHGhoWtzdkP7MWu YeLMZiuOsC6N6ejHEbtt0KLjphNIUvBVFx5JQzgAwJ1I08LSZg/bIGAVF3SfLOVFu2Iiq5kj psHOv/ECV13fGSvYwBXJN1C1To6wxDgn4pl3m6fFfe4xiVEpc3t6GbKcI+4blK9w76fDaVXw U2uJQAG1UYxbChwocBmb3ka1MlUb2ug3oYBpnufD9zk8u3UqaFlfYyr6/2cr6fqiz1U4+xcb Q3otvVWwzRecpmPEiIcCAwEAAaOCAjIwggIuMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQD AgWgMCAGA1UdJQEB/wQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU2Pc1OxE6 W8hcBZ5L2346cucbFa8wJwYDVR0RBCAwHoEcamFsdG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNv bTBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEWGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20v cnBhMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzU3 ZGU3YTIzOGQ0NWQ4ZDRmYzcxZjhhNWM2YjgxYzkzL0xhdGVzdENSTC5jcmwwTgYIKwYBBQUH AQEEQjBAMD4GCCsGAQUFBzAChjJodHRwOi8vY2FjZXIuc3ltYXV0aC5jb20vbXBraS9zeW1j YzFpbmRzdWJjYWc1LmNydDAfBgNVHSMEGDAWgBRnGbY9pXm7M2DYLVPTjAk9B6wYcDArBgpg hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGt7pITFgUxMDkyMjA5BgpghkgBhvhFARAF BCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3 DQEBCwUAA4IBAQBvO/+L6Tms91Ed1ZJzgT0y9jBK/Armb6Y/EnR1swCDMqRfBzGSGtzOCuN7 PteBvlaB5vmnwEwiZR/FtsDhhORd8Xy5wdmCunhwPbf0ClnBqichI+4UZNS5fCQTciIqHFxq 7EKuHOQm4/ssEH2Xr8yIpCd+Dx9oPEG7MqUno6oxcIDdur4iNKxOBtjWNiXM7rn733qtuFlw 1jIX3eFIsrBALikTU1UbY2KwfewXbiVaFWY0ysl5uOgfWdmj2xBk7aft/L/fnuyWyeeM9IBg 6vdUjPhmJwtFdEdefgP5cRRdYgG8zgJf8Rq84slkea0bwis8PvKVksJ/k2scaDHzKTe2MIIG PDCCBSSgAwIBAgIQBwKiGoW4S2WeGApu5vWjZTANBgkqhkiG9w0BAQsFADCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRo b3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmlt YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMTUxMDAxMDAwMDAwWhcNMjUw OTMwMjM1OTU5WjCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0 aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW+w0x SSLADLrvTi0XuLQw5TTSrAnuyYkAXfSuExGzE45VzyIYqCAGpv0ly2iUtKCCkA5ulpJE7hW5 tOz6z3k9adScH9wgmg4o1Q21xp468dRlGcCEM02O2orx1ie5A6DR+iicgpNs9w2FfVvpTpli /pNC0u4+s3FXhpdGy98N4caEWrMNj/X0EIoFXZ9oRuwIsFhCgva+LRBGpiQLJ/6YFFODk4Lb 6sA/T6JYYbVLcmkSXzNZ9vmzTABkzoXFhpIMbhzrKM9xqZCpdJl0JOtI4Q5daBKoAWbo7pqy L/g9zbd4JM6lYHzoFj1J8Qe6M74yK8JnoxbHb8DSWpQEwmtFAgMBAAGjggI+MIICOjA3Bggr BgEFBQcBAQQrMCkwJwYIKwYBBQUHMAGGG2h0dHA6Ly9wa2ktb2NzcC5zeW1hdXRoLmNvbTAS BgNVHRMBAf8ECDAGAQH/AgEAMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEF BQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDov L3d3dy5zeW1hdXRoLmNvbS9ycGEwLwYDVR0fBCgwJjAkoCKgIIYeaHR0cDovL3Muc3ltY2Iu Y29tL3BjYTEtZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRU3ltYW50ZWNQS0ktMi0yMTcwHQYDVR0OBBYEFGcZtj2lebszYNgtU9OMCT0HrBhwMIHx BgNVHSMEgekwgeahgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5 OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQsFAAOCAQEARhnkJ3U7vq/i 2qIUYI8eRJCBaStjSTWN6Xa6n5iPE4HXy/xlG/gOY96UKHT742/YySp6DlSmg64pSvYrUf09 OBK73WNF+2TMPlSGf05CbSO3HQv9+swNjpM1yuVF+c8vf3k9YxjHRyNK9qkUAK1+WVUaiSfb lKCROMb+QJWjYPZduMjFFu2cZmkURhBKynAqb9FQ4CYa01K0R3KLRdK9A7ml3NkI85CrdHCr yqBO8MBO5OC+T5ARYCcMKxzf52zKdbQl55FIqpK0UXVfKZtHFxy9yerPda11I8/yxd9aq7dr yru4XqvVo3DUaPMXepsLoBQ8++iBVmjoz118c7guvDGCBGIwggReAgEBMIG7MIGmMQswCQYD VQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNQIQ cBGDX/fzAS3ijWWeve3D7zANBglghkgBZQMEAgEFAKCCAncwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNjIxMTYwNTA1WjAvBgkqhkiG9w0BCQQxIgQg Cl6BNmTLdFveeEvbMXRHWdcQeBSXolcakf3Sb/2K6m8wbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7 MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNV BAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHNQIQcBGDX/fzAS3ijWWeve3D7zCBzgYLKoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3lt YW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc1 AhBwEYNf9/MBLeKNZZ697cPvMA0GCSqGSIb3DQEBAQUABIIBAG6LCuriJSGIHHgZWF5jOz4S L6RTcp+rPJf+cJQBTwUON6fjRY2BBsvXVWBM5tvFduYXHqLRRWkio0QomoBH4EchMRwKcWmQ S/0lHqs+ZnEbBuQy/vdPjN3qdCsnnlENru06ujcA2VgoToJ/ccxjeOqKkQwBrkQBmd0mc0l5 wgcYIRuGhjJFqUut8U+YjGcC4fLLTtr4s6rthL7nykIIO6R+2yAW95/zkbLB9+FLkNdr0MSl 7KPgSMhz9H6I68ZTCzJAfR8Lk5s3h+nD9gzo0FKhcsKjUFmeOLfg3xLCWFciShnKatHSc5C5 BAU8dQSb7/6Fzg/eulXgvmmF5LbByN0AAAAAAAA= --------------ms090907090305010903090602-- From nobody Thu Jun 23 12:13:43 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9A812D670 for ; Thu, 23 Jun 2016 12:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.346 X-Spam-Level: X-Spam-Status: No, score=-8.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 7MFeYy00jahJ for ; Thu, 23 Jun 2016 12:13:40 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 128F012D158 for ; Thu, 23 Jun 2016 12:13:40 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C50FE62668 for ; Thu, 23 Jun 2016 19:13:39 +0000 (UTC) Received: from dhcp137-207.rdu.redhat.com (dhcp137-207.rdu.redhat.com [10.13.137.207]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5NJDd9B007137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 23 Jun 2016 15:13:39 -0400 Message-ID: <1466709219.20951.3.camel@redhat.com> From: Nathaniel McCallum To: kitten@ietf.org Date: Thu, 23 Jun 2016 15:13:39 -0400 In-Reply-To: <1463416879.2542.15.camel@redhat.com> References: <20160516161709.16705.29515.idtracker@ietfa.amsl.com> <1463416879.2542.15.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 23 Jun 2016 19:13:39 +0000 (UTC) Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-krb-auth-indicator-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 19:13:42 -0000 I propsed this and hear no response. Can we move this draft forward? On Mon, 2016-05-16 at 12:41 -0400, Nathaniel McCallum wrote: > With this revision, I believe that we are in the home stretch on this > draft. Unless anyone has any objections, I'd like to request that the > chairs begin WGLC. > > On Mon, 2016-05-16 at 09:17 -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Common Authentication Technology > > Next Generation of the IETF. > > > >         Title           : Authentication Indicator in Kerberos > > Tickets > >         Authors         : Anupam Jain > >                           Nathan Kinder > >                           Nathaniel McCallum > > Filename        : draft-ietf-kitten-krb-auth-indicator-02.txt > > Pages           : 5 > > Date            : 2016-05-16 > > > > Abstract: > >    This document specifies an extension in the Kerberos protocol > >    [RFC4120].  It defines a new authorization data type AD- > >    AUTHENTICATION-INDICATOR.  The purpose of introducing this data > > type > >    is to include an indicator of the strength of a client's > >    authentication in the service tickets so that application > > services > >    can use it as an input into policy decisions. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-auth-indicat > > or > > / > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-kitten-krb-auth-indicator-02 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-krb-auth-indica > > to > > r-02 > > > > > > Please note that it may take a couple of minutes from the time of > > submission > > until the htmlized version and diff are available at > > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Kitten mailing list > > Kitten@ietf.org > > https://www.ietf.org/mailman/listinfo/kitten > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Sat Jun 25 20:47:03 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E5012B007 for ; Sat, 25 Jun 2016 20:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham 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 bFoV1r1jZQiy for ; Sat, 25 Jun 2016 20:47:00 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F69012B027 for ; Sat, 25 Jun 2016 20:46:59 -0700 (PDT) X-AuditID: 1209190e-cf3ff70000005fc2-a0-576f5031307a Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id B4.83.24514.1305F675; Sat, 25 Jun 2016 23:46:58 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u5Q3kuJd020775; Sat, 25 Jun 2016 23:46:57 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u5Q3krsU015458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 25 Jun 2016 23:46:56 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u5Q3kr7p013518; Sat, 25 Jun 2016 23:46:53 -0400 (EDT) Date: Sat, 25 Jun 2016 23:46:53 -0400 (EDT) From: Benjamin Kaduk To: Nathaniel McCallum In-Reply-To: <1466709219.20951.3.camel@redhat.com> Message-ID: References: <20160516161709.16705.29515.idtracker@ietfa.amsl.com> <1463416879.2542.15.camel@redhat.com> <1466709219.20951.3.camel@redhat.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="-559023410-1441795010-1466912687=:18480" Content-ID: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsUixG6nomsUkB9u8O6BmsXRzatYLOZ+ncXq wOSxZMlPJo/3+66yBTBFcdmkpOZklqUW6dslcGUcP7afqeCPTMX2vrIGxj6JLkZODgkBE4kr y2+ydzFycQgJtDFJzO5oZYRwNjJK7DzzFso5xCTR/GgvC4TTwCjR8nQBG0g/i4C2xK9//5lB bDYBFYmZbzaCxUUE9CSW7ZvACGIzCwhLrD83A6xGWMBf4tPnRWA1nAJGEvs+7mQCsXkFHCXm L7gPta2XUeLG5QvsIAlRAR2J1funsEAUCUqcnPkEyOYAGhoo8eVQIMR8R4kj/24yT2AUnIWk ahZC1SwkVRC2rsSbVQeZIGxtifs329hgam5OP8eygJFtFaNsSm6Vbm5iZk5xarJucXJiXl5q ka6xXm5miV5qSukmRlAkcEry7WCc1OB9iFGAg1GJh3eFRH64EGtiWXFl7iFGSQ4mJVHebY9y w4X4kvJTKjMSizPii0pzUosPMUpwMCuJ8HJ7A5XzpiRWVqUW5cOkpDlYlMR5GRkYGIQE0hNL UrNTUwtSi2CyMhwcShK86/2AGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGnwep4S0uSMwtzkyHyJ9i 1OXomXBjLZMQS15+XqqUOO8ekCIBkKKM0jy4OeAEtptJ9RWjONBbwrzs/kBVPMDkBzfpFdAS JqAld/uzQZaUJCKkpBoYTZXV9OxFfj2cpCri3H2k7Eh5/Tkpo0jbVZIOTUJ9ujVXfiVVzV/+ foLPtFZPow3fPx1hbBFW2tqso/yWQ+JUi3Fy74SOrx4phs9fi5tu795qrlZ8yZ9PmnfXo69T +U23botWmnNPXsc2fu6CXp01Bj4fGtofbdh+q2UxzyOG5inr78re4J2pxFKckWioxVxUnAgA q7H3PzsDAAA= Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-krb-auth-indicator-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2016 03:47:02 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1441795010-1466912687=:18480 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: Yes, it would be good to move this document forward, especially since it already has implementation experience. Would you be interested in trying out the proposal to manually track reviews and (mostly) skip WGLC for this document? That thread has not gotten many responses yet... -Ben On Thu, 23 Jun 2016, Nathaniel McCallum wrote: > I propsed this and hear no response. Can we move this draft forward? > > On Mon, 2016-05-16 at 12:41 -0400, Nathaniel McCallum wrote: > > With this revision, I believe that we are in the home stretch on this > > draft. Unless anyone has any objections, I'd like to request that the > > chairs begin WGLC. > > > > On Mon, 2016-05-16 at 09:17 -0700, internet-drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > This draft is a work item of the Common Authentication Technology > > > Next Generation of the IETF. > > > > > > =A0=A0=A0=A0=A0=A0=A0=A0Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: Authe= ntication Indicator in Kerberos > > > Tickets > > > =A0=A0=A0=A0=A0=A0=A0=A0Authors=A0=A0=A0=A0=A0=A0=A0=A0=A0: Anupam Ja= in > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0Nathan Kinder > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0Nathaniel McCallum > > > =09Filename=A0=A0=A0=A0=A0=A0=A0=A0: draft-ietf-kitten-krb-auth-indic= ator-02.txt > > > =09Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: 5 > > > =09Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: 2016-05-16 > > > > > > Abstract: > > > =A0=A0=A0This document specifies an extension in the Kerberos protoco= l > > > =A0=A0=A0[RFC4120].=A0=A0It defines a new authorization data type AD- > > > =A0=A0=A0AUTHENTICATION-INDICATOR.=A0=A0The purpose of introducing th= is data > > > type > > > =A0=A0=A0is to include an indicator of the strength of a client's > > > =A0=A0=A0authentication in the service tickets so that application > > > services > > > =A0=A0=A0can use it as an input into policy decisions. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-auth-indicat > > > or > > > / > > > > > > There's also a htmlized version available at: > > > https://tools.ietf.org/html/draft-ietf-kitten-krb-auth-indicator-02 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-krb-auth-indica > > > to > > > r-02 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission > > > until the htmlized version and diff are available at > > > tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > Kitten mailing list > > > Kitten@ietf.org > > > https://www.ietf.org/mailman/listinfo/kitten > > > > _______________________________________________ > > Kitten mailing list > > Kitten@ietf.org > > https://www.ietf.org/mailman/listinfo/kitten > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > ---559023410-1441795010-1466912687=:18480-- From nobody Sat Jun 25 21:11:17 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7593127078 for ; Sat, 25 Jun 2016 21:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham 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 XMN6HQj6_4BH for ; Sat, 25 Jun 2016 21:11:14 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9599B12B011 for ; Sat, 25 Jun 2016 21:11:13 -0700 (PDT) X-AuditID: 12074423-ffbff7000000518a-2b-576f55dfd36e Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id D4.30.20874.FD55F675; Sun, 26 Jun 2016 00:11:12 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u5Q4BAxh023618; Sun, 26 Jun 2016 00:11:10 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u5Q4B6f2020635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 26 Jun 2016 00:11:09 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u5Q4B6fd016641; Sun, 26 Jun 2016 00:11:06 -0400 (EDT) Date: Sun, 26 Jun 2016 00:11:06 -0400 (EDT) From: Benjamin Kaduk To: Jeffrey Altman In-Reply-To: Message-ID: References: <576902D4.5080303@cs.tcd.ie> 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+NgFnrFIsWRmVeSWpSXmKPExsUixCmqrPsgND/cYMlpSYs/KyexWRzdvIrF Yvrea+wOzB5ru6+yeSxZ8pPJ42TfedYA5igum5TUnMyy1CJ9uwSujOmrzrMXdIhUXD/0m6mB 8T9/FyMnh4SAicTb72fZuxi5OIQE2pgkvh+8ygLhbGSU+LHoOCNIlZDAISaJJWf9IRINjBLf T7xlBUmwCGhLLH29gwXEZhNQkZj5ZiMbiC0iYCjR9v8mWA2zgIPEkZaVTCC2sECAxOPJH4Hi HBycAh4Se9+YgYR5BRwldr47wQKxaxajxMIP/iC2qICOxOr9U1ggagQlTs58wgIxUkti+fRt LBMYgYoRUrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdPLzSzRS00p3cQIClJ2F+Ud jC/7vA8xCnAwKvHwrpDIDxdiTSwrrsw9xCjJwaQkyrvtUW64EF9SfkplRmJxRnxRaU5q8SFG CQ5mJRHeZSFA5bwpiZVVqUX5MClpDhYlcV5GBgYGIYH0xJLU7NTUgtQimKwMB4eSBO9lkEbB otT01Iq0zJwShDQTByfIcB6g4U/BhhcXJOYWZ6ZD5E8xKkqJ84aCJARAEhmleXC94CSym0n1 FaM40CvCvKrAlCLEA0xAcN2vgAYzAQ2+258NMrgkESEl1cCob/rF7e38qmdzvjqt0YtWKH+j oP85TCkifFeb4/IVuq5zT3x/FHiGR19uw5sAhjVd3w6efPyK0yPX7Oav9WcTuNLUnn/d9/32 +80hzz6dW9B39uLtr6cc/xzco2ZWMdHvmLOzPHtxpKHQnKtXlli/EOng3da1plk7IPWVVoZc t9/L5v9Wv5TuK7EUZyQaajEXFScCAFdnLhH9AgAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Proposal for tracking document reviews and skipping WGLC X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2016 04:11:16 -0000 On Tue, 21 Jun 2016, Jeffrey Altman wrote: > On 6/21/2016 5:03 AM, Stephen Farrell wrote: > > > > Just for the record: I think this is a fine thing to try > > for a while, and thanks to the chairs for being willing. > > I hope the WG are also willing to give it a shot as I figure > > we need to make IETF stuff easier for WGs like kitten that > > maintain important protocols through what will sometimes > > be relatively "low energy" periods. > > > > S. > > Stephen, > > I will point out that even when documents complete WGLC they do not > necessarily move forward. For example, > > https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/ > > which has been waiting for a write-up for five months. This is a Yes, my personal circumstances have conspired to not leave me a sufficiently large chunk of uninterrupted time in which to do the writeup. I agree that it is unfortunate, and I've come close a couple times, but my situation is improving such that I expect this to be moving forward soon. > document that not only passed WGLC but has two independent interoperable > implementations blocked waiting for assignment of ETYPE and SUMTYPE > values by IANA. Given our recent experiences, it's probably a good idea to have an additional party review those implementations for compliance to the standard. The test vectors help a lot, of course, but there are still some things for which review is useful. > As a former Kitten chair, the lack of available resources to work on > protocol design, documents, and implementations is not new. The > GSS/Kerberos community has suffered with resource starvation for > decades. Although GSS, Kerberos and other authentication technologies > are critical to the functioning of non-web network communications there > has never been sufficient funding available to complete even 10% of the > work that needs to be accomplished. This is a key factor in the time it > takes to get things done. > > When the WG Chairs and key participants are not funded to work on > GSS/Kerberos it is very hard for them to prioritize the work. In the > end, none of us are independently wealthy and few of participant's > employers pay the participants for this work. I'll trim the rest. I do not disagree, but do think it's worth repeating that even when the chairs have support from their employers for that work, documents cannot move forward without review from key participants. But no, I don't have any ideas for where the money could be found. -Ben From nobody Sun Jun 26 20:04:06 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A7012D5B9 for ; Sun, 26 Jun 2016 20:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham 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 0d-RatYbOd_W for ; Sun, 26 Jun 2016 20:04:03 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7692012D5B8 for ; Sun, 26 Jun 2016 20:04:02 -0700 (PDT) X-AuditID: 12074422-e33ff700000005ec-98-5770979f3985 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 00.A3.01516.0A790775; Sun, 26 Jun 2016 23:04:01 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u5R33xLH011705; Sun, 26 Jun 2016 23:03:59 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u5R33t1L014662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 26 Jun 2016 23:03:58 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u5R33t1o007935; Sun, 26 Jun 2016 23:03:55 -0400 (EDT) Date: Sun, 26 Jun 2016 23:03:54 -0400 (EDT) From: Benjamin Kaduk To: Michael Jenkins Message-ID: 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+NgFrrEIsWRmVeSWpSXmKPExsUixG6nrrtwekG4wYZmHYutN78zWhzdvIrF Ytm3q2wOzB47Z91l91iy5CeTx5fLn9kCmKO4bFJSczLLUov07RK4MhoeNDIXLJCrmHJrMmMD 42GJLkYODgkBE4kde4q7GLk4hATamCTW/L7JDOFsZJR49aeNHcI5xCSx8vYHJgingVHi06Nd QA4nB4uAtsTppvWMIDabgIrEzDcb2UBsEQEDiUWT1oHZzALuEtv+72MFsYUFzCTedd1lA1nN K+AoMetgIUhYVEBHYvX+KSwgNq+AoMTJmU9YIFq1JJZP38YygZFvFpLULCSpBYxMqxhlU3Kr dHMTM3OKU5N1i5MT8/JSi3RN9XIzS/RSU0o3MYKDzkVpB+PEf16HGAU4GJV4eDXkC8KFWBPL iitzDzFKcjApifJue5QbLsSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEd+oUoHLelMTKqtSifJiU NAeLkjhvUOSxMCGB9MSS1OzU1ILUIpisDAeHkgTv36lAjYJFqempFWmZOSUIaSYOTpDhPEDD 7aeBDC8uSMwtzkyHyJ9iVJQS570HslUAJJFRmgfXC04Ku5lUXzGKA70izKsD0s4DTChw3a+A BjMBDWatzgcZXJKIkJJqYFz0f5qYzulsCYtu3UW3N3us2xj3w71d2e/T2k/5XtXidcui+3R2 iF5X9jj4X9mJvUvtsO9Ft9y1ZdOkzSv6A/Zt0tc/rpXmaGs6XWFNdEuvi6+Bd1908Ls/R11e n1Qxdw8xT/561lXg180HCi3+znn2+3TvvJg1NZVZQUupwSxJ9PnMvld3lFiKMxINtZiLihMB 25yL8OUCAAA= Archived-At: Cc: kitten@ietf.org, draft-ietf-kitten-aes-cts-hmac-sha2@tools.ietf.org Subject: [kitten] shepherd review of draft-aes-cts-hmac-sha2-09 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 03:04:05 -0000 Hi Michael et al, As I was preparing the shepherd writeup for this document, I noticed some things that do not block the progression of the document but do require changes, and one item that may require further WG input. Can you prepare a new version with the changes mentioned below? The one item which would potentially affect the actual protocol: at the end of Section 5, the pseudo-random function seems to be using a SP800-108 KDF but omits the zero byte between label and context. I think it would be better to have the zero byte -- do you remember whether there was a reason to omit it? (Adding the zero byte would require re-rolling some test vectors, to be clear.) Additionally, all document authors will need to confirm compliance with BCPs 78 and 79 for this document, namely that there are no intellectual property concerns with the document that are not already disclosed. Please add a normative reference to RFC 2104 for HMAC, first mentioned at the end of Section 1. In Section 3, it might aid clarity to mention that the 0x00000001 input to HMAC() is the 'i' parameter from SP800-108 [indicating that this is the first block of output, even though it is the only block of output as well]. In Section 4, it might be worth re-mentioning "where PBKDF2 is the function of that name from RFC 2898" after the algorithm block, since most everything else used there also gets clarified. (It is already cited at the beginning of the section, in the overview paragraph.) The document should be consistent about using "cipher state" as one word or two (RFC 3961 prefers the two-word form). It also makes a rather sudden appearance at the beginning of Section 5 with no explanatory introduction; it might help the reader to instead start with "The RFC 3961 cipher state that maintains cryptographic state across different encryption operations using the same key is used as the formal initialization vector [...]" On the next page, "cipherstate" is defined as "a 128-bit initialization vector derived from the ciphertext", which is potentially misleading, since it can't be both used as the IV for and derived from the same ciphertext! Probably it's better to say "derived from a previous (if any) ciphertext using the same encryption key, as specified below". Still in Section 5, in the definition of the encryption function (well, computing the cipherstate, really), I'm of two minds whether it's worth mentioning that the case of L < 128 is impossible because of the 128-bit confounder. In the decryption function, can you add a note to the right of "(C, H) = ciphertext" that "[H is the last h bits of the ciphertext]"? In the pseudo-random function, please replace "base-key" with "input-key", since the key input to the PRF is not expected to be a kerberos protocol long-term base key. In Section 6, the "associated cryptosystem"s are supposed to be "AES-128-CTS" or "AES-256-CTS", but those strings do not appear elsewhere in the document. While the meaning is pretty clear, it's probably better to just say "aes128-cts-hmac-sha256-128 or aes256-cts-hmac-sha384-192 as appropriate". This does duplicate the preceding text, but we do want to explicitly list the "associated encryption algorithm" as listed in the Checksum Algorithm Profile of Section 4 of RFC 3961. In Section 8.1, the acronym "TGT" is used, the only instance in the document. It's also potentially misleading, since ticket-granting tickets are generally objects that are issued to client principals by the AS. I'd go with "Cross-realm krbtgt keys" instead. The test vectors for key derivation have a parenthetical "constant = 0x...", but the term "constant" does not appear elsewhere in the document. The hex values are the label input for the HMAC, so we should call them that. Thanks, Ben From nobody Mon Jun 27 02:17:52 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F4712D10B for ; Mon, 27 Jun 2016 02:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 t2ePwO_yfv8C for ; Mon, 27 Jun 2016 02:17:49 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A605F12D0EA for ; Mon, 27 Jun 2016 02:17:49 -0700 (PDT) Received: by us.padl.com with ESMTP id u5R9Hh5h023819; Mon, 27 Jun 2016 05:17:46 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Luke Howard In-Reply-To: Date: Mon, 27 Jun 2016 19:17:49 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <5596DB1C-B1AA-4C5B-94B6-3FA033B8161E@padl.com> References: To: Benjamin Kaduk X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "kitten@ietf.org" , draft-ietf-kitten-aes-cts-hmac-sha2@tools.ietf.org Subject: Re: [kitten] shepherd review of draft-aes-cts-hmac-sha2-09 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 09:17:51 -0000 > The one item which would potentially affect the actual protocol: at = the > end of Section 5, the pseudo-random function seems to be using a = SP800-108 > KDF but omits the zero byte between label and context. I think it = would > be better to have the zero byte -- do you remember whether there was a > reason to omit it? (Adding the zero byte would require re-rolling = some > test vectors, to be clear.) The PRF is defined in terms of KDF-HMAC-SHA2() which implicitly inserts = the zero byte when invoking HMAC-SHA-256(), e.g.: PRF =3D KDF-HMAC-SHA2(base-key, "prf" | octet-string, 256) =3D k-truncate(HMAC-SHA-256(key, 0x00000001 | "prf" | = octet-string | 0x00 | 256)) if I=E2=80=99m not mistaken? Pretty sure our implementation passed the = test vectors. =E2=80=94 Luke= From nobody Mon Jun 27 06:21:28 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B308112D1A1 for ; Mon, 27 Jun 2016 06:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.346 X-Spam-Level: X-Spam-Status: No, score=-8.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 reXDSd5X-lVz for ; Mon, 27 Jun 2016 06:21:24 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A9212B047 for ; Mon, 27 Jun 2016 06:21:24 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5E5BE7F6A5; Mon, 27 Jun 2016 13:21:24 +0000 (UTC) Received: from vpn-49-204.rdu2.redhat.com (vpn-49-204.rdu2.redhat.com [10.10.49.204]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5RDLNct014268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Jun 2016 09:21:24 -0400 Message-ID: <1467033683.2592.2.camel@redhat.com> From: Nathaniel McCallum To: Benjamin Kaduk Date: Mon, 27 Jun 2016 09:21:23 -0400 In-Reply-To: References: <20160516161709.16705.29515.idtracker@ietfa.amsl.com> <1463416879.2542.15.camel@redhat.com> <1466709219.20951.3.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Mon, 27 Jun 2016 13:21:24 +0000 (UTC) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-krb-auth-indicator-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 13:21:26 -0000 I'm happy to do so. But, AFAIK, the only review thus far has been yours. There were several other +1's to WG adoption, but no other reviews. On Sat, 2016-06-25 at 23:46 -0400, Benjamin Kaduk wrote: > Yes, it would be good to move this document forward, especially since > it > already has implementation experience.  Would you be interested in > trying > out the proposal to manually track reviews and (mostly) skip WGLC for > this > document?  That thread has not gotten many responses yet... > > -Ben > > On Thu, 23 Jun 2016, Nathaniel McCallum wrote: > > > I propsed this and hear no response. Can we move this draft > forward? > > > > On Mon, 2016-05-16 at 12:41 -0400, Nathaniel McCallum wrote: > > > With this revision, I believe that we are in the home stretch on > this > > > draft. Unless anyone has any objections, I'd like to request that > the > > > chairs begin WGLC. > > > > > > On Mon, 2016-05-16 at 09:17 -0700, internet-drafts@ietf.org wrote > : > > > > A New Internet-Draft is available from the on-line Internet- > Drafts > > > > directories. > > > > This draft is a work item of the Common Authentication > Technology > > > > Next Generation of the IETF. > > > > > > > >         Title           : Authentication Indicator in Kerberos > > > > Tickets > > > >         Authors         : Anupam Jain > > > >                           Nathan Kinder > > > >                           Nathaniel McCallum > > > >   Filename        : draft-ietf-kitten-krb-auth-indicator-02.txt > > > >   Pages           : 5 > > > >   Date            : 2016-05-16 > > > > > > > > Abstract: > > > >    This document specifies an extension in the Kerberos > protocol > > > >    [RFC4120].  It defines a new authorization data type AD- > > > >    AUTHENTICATION-INDICATOR.  The purpose of introducing this > data > > > > type > > > >    is to include an indicator of the strength of a client's > > > >    authentication in the service tickets so that application > > > > services > > > >    can use it as an input into policy decisions. > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-auth-ind > icat > > > > or > > > > / > > > > > > > > There's also a htmlized version available at: > > > > https://tools.ietf.org/html/draft-ietf-kitten-krb-auth-indicato > r-02 > > > > > > > > A diff from the previous version is available at: > > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-krb-auth-in > dica > > > > to > > > > r-02 > > > > > > > > > > > > Please note that it may take a couple of minutes from the time > of > > > > submission > > > > until the htmlized version and diff are available at > > > > tools.ietf.org. > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > _______________________________________________ > > > > Kitten mailing list > > > > Kitten@ietf.org > > > > https://www.ietf.org/mailman/listinfo/kitten > > > > > > _______________________________________________ > > > Kitten mailing list > > > Kitten@ietf.org > > > https://www.ietf.org/mailman/listinfo/kitten > > > > _______________________________________________ > > Kitten mailing list > > Kitten@ietf.org > > https://www.ietf.org/mailman/listinfo/kitten > > From nobody Mon Jun 27 07:15:03 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394D812D505 for ; Mon, 27 Jun 2016 07:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham 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 xXTUYDFCMmiB for ; Mon, 27 Jun 2016 07:14:59 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97B2312D552 for ; Mon, 27 Jun 2016 07:14:48 -0700 (PDT) X-AuditID: 12074425-ebfff70000001189-d8-577134d68e08 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id BF.97.04489.6D431775; Mon, 27 Jun 2016 10:14:47 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u5REEkHk032283; Mon, 27 Jun 2016 10:14:46 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u5REEgrd029443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Jun 2016 10:14:44 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u5REEfkp001417; Mon, 27 Jun 2016 10:14:41 -0400 (EDT) Date: Mon, 27 Jun 2016 10:14:41 -0400 (EDT) From: Benjamin Kaduk To: Luke Howard In-Reply-To: <5596DB1C-B1AA-4C5B-94B6-3FA033B8161E@padl.com> Message-ID: References: <5596DB1C-B1AA-4C5B-94B6-3FA033B8161E@padl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-266937439-1467036881=:18480" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT0b1uUhhusHyOusXWm98ZLY5uXsVi cffSf3aLZd+usjmweOycdZfdY8mSn0wecz9MY/H4cvkzWwBLFJdNSmpOZllqkb5dAlfGx5Un 2Ap+iFWcWrmErYHxiFAXIyeHhICJxJyjK1m6GLk4hATamCQ2TnnBDOFsZJT4vwXGOcQk8fjl SVYIp4FRYtr5P8wg/SwC2hJ9u+YxgthsAioSM99sZAOxRQQUJCbvXwvWzSwwm1Fi3uLz7CAJ YQFniduvusGaOQVsJH49/AHWwCvgKPH0VDsTiC0kUCjRtugqWL2ogI7E6v1TWCBqBCVOznwC ZHMADQ2QmPHTZAKjwCwkmVkIGZAws4C6ROODs2wQtrbE/ZttbAsYWVYxyqbkVunmJmbmFKcm 6xYnJ+blpRbpWujlZpbopaaUbmIEh7qL6g7GOX+9DjEKcDAq8fBqyBeEC7EmlhVX5h5ilORg UhLl3fYoN1yILyk/pTIjsTgjvqg0J7X4EKMEB7OSCK8rMMKEeFMSK6tSi/JhUtIcLErivIwM DAxCAumJJanZqakFqUUwWRkODiUJXj6QRsGi1PTUirTMnBKENBMHJ8hwHqDhimDDiwsSc4sz 0yHypxgVpcR55xgDJQRAEhmleXC94FS0m0n1FaM40CvCvL9BqniAaQyu+xXQYCagwazV+SCD SxIRUlINjF0pmly3jsiJd9/6yfluxvVeWzvP5rqm+lVbf6RueMBz/1CZJ7eUf2/Y9QlTzZ8q +XQVea3yy7kQw3DP829L/v5c3rZlr5R05S1NQ17avgrg426QP2m3kUva90lo4NUpitPVXvh8 zf+z61SajdPbY/MmJjGv3M/D3qf6aRtnrWJzeHbiWtNSJZbijERDLeai4kQAopPi6CADAAA= Archived-At: Cc: "kitten@ietf.org" , draft-ietf-kitten-aes-cts-hmac-sha2@tools.ietf.org Subject: Re: [kitten] shepherd review of draft-aes-cts-hmac-sha2-09 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 14:15:02 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-266937439-1467036881=:18480 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 27 Jun 2016, Luke Howard wrote: > > The one item which would potentially affect the actual protocol: at the > > end of Section 5, the pseudo-random function seems to be using a SP800-= 108 > > KDF but omits the zero byte between label and context. I think it woul= d > > be better to have the zero byte -- do you remember whether there was a > > reason to omit it? (Adding the zero byte would require re-rolling some > > test vectors, to be clear.) > > The PRF is defined in terms of KDF-HMAC-SHA2() which implicitly inserts > the zero byte when invoking HMAC-SHA-256(), e.g.: > > =09PRF =3D KDF-HMAC-SHA2(base-key, "prf" | octet-string, 256) > =09=3D k-truncate(HMAC-SHA-256(key, 0x00000001 | "prf" | octet-string | 0= x00 | 256)) > > if I=E2=80=99m not mistaken? Pretty sure our implementation passed the te= st vectors. I think that SP800-108 would have it be [counter] | [label] | 0x00 | [context] | [output-length] with the NUL between label and context, not between context and output-length. Its definitions are: %%%%%%%%%%% 3) Label A string that identifies the purpose for the derived keying material, which is encoded as a binary string. The encoding method for the Label is defined in a larger context, for example, in the protocol that uses a KDF. 4) Context A binary string containing the information related to the derived keying material. It may include identities of parties who are deriving and/or using the derived keying material and, optionally, a nonce known by the parties who derive the keys. %%%%%%%%%%% For the PRF, the octet-string input is pretty clearly something specifically known to the parties who derive the keys, which seems like a context. For the use of KDF-HMAC-SHA2 elsewhere in the document, e.g. for deriving Kc, Ke, and Ki, the line between label and context is less clear, since we invoke it as (e.g.) Kc =3D KDF-HMAC-SHA2(base-key, usage | 0x99, 128) and the 0x99 is defined by the protocol and would plausibly still be part of the label. As I recall, the PRF was something of a late addition, and if the KDF-HMAC-SHA2 construct was defined originally for password key derivation and deriving Kc/Ke/Ki, that would explain why there was not thought about having a proper SP800-108 context that would also need separation. (SP800-108 has the context as optional ("One or more of these fixed input data fields may be omitted unless required for certain purposes as discussed in Section 7.5 and Section 7.6."), which is fine and would apply for the non-PRF cases here.) -Ben ---559023410-266937439-1467036881=:18480-- From nobody Mon Jun 27 08:00:18 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB13012D89A for ; Mon, 27 Jun 2016 08:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 FieZ5bHloI5A for ; Mon, 27 Jun 2016 08:00:14 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 2C3AB12D80C for ; Mon, 27 Jun 2016 07:53:57 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id f6so157758696lfg.0 for ; Mon, 27 Jun 2016 07:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qSLHeNb8NREEZW9y+4GhLcEQY06jdwrzDVcs0gtcOrE=; b=doZuvF+Ty+a4tV7aVh5wcwkgbOgITCWko/kAJDl88ASMW7GE48/X1JnWCTyNEZ0dkM 7aIcTHFqllyu771bssjncHZbTb+LDNPN10MY7SnGctU5tNzs1LD9AOoycMfwkqemqlEZ BLdobCmTGDXq7LjpKAYUHA0FKLpUXP7YDfy7Fz1XbFEm9BV1YEYq2vHmfagQ3AGcit63 AhEb6rOvuBeJ5+6Ww4wV3CfDOK2r1b97c7DIU3ghWlI0LeeygNTjpulrIxjLmwfAglrJ RTfHPjRmx+FO3rzVngG8VeDSaj9qNgwKDEEn9oIHxKf6TLr0SAulX1f5ZbQUpBOy3B/e b2NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qSLHeNb8NREEZW9y+4GhLcEQY06jdwrzDVcs0gtcOrE=; b=fHNA0tWDJgVoqz5SjcNjJ7URhe+FwqYIfjh5tqI7LlOwe+zW7nCpuOnSjTEQDYhlEK J/rb7sE5+8H6N5qTQAhC4D8f6OoVngzB2BiZfNq7JllJ5LcKEMG/1bij9TqzHdMbu0yr KztcP7JtVVDp/UAqRojIrpTeE6apWcH1uNkzab6uS12g+iY4F4PSZvJh3JYJsh/UD6PC VxhSsNaWX5+16PtzeIkIhCSPcxK5AXR0UTiDaCaZ109/F/CWUMf1EzDc3sMso6hrOD61 BP0X08K1PV5U8+1vYRdN6m+RTQKU0ZjMETKN2czQbpg5L8JpTN69nt3oLI1j8atTnlhg +r2A== X-Gm-Message-State: ALyK8tJWc6c0mhzARYXHLrMxiZpBsY+er0NEf2H7mr5mASouCrdvOA8NcsGAZ0c/muaWYjpBkrtN6gL1rlQl9A== X-Received: by 10.25.21.106 with SMTP id l103mr398546lfi.27.1467039235263; Mon, 27 Jun 2016 07:53:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.141.132 with HTTP; Mon, 27 Jun 2016 07:53:54 -0700 (PDT) In-Reply-To: References: From: Michael Jenkins Date: Mon, 27 Jun 2016 10:53:54 -0400 Message-ID: To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=001a113f17e87d5214053643b0ab Archived-At: Cc: kitten@ietf.org, draft-ietf-kitten-aes-cts-hmac-sha2@tools.ietf.org Subject: Re: [kitten] shepherd review of draft-aes-cts-hmac-sha2-09 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 15:00:17 -0000 --001a113f17e87d5214053643b0ab Content-Type: text/plain; charset=UTF-8 Ben, we'll get started on these. On Sun, Jun 26, 2016 at 11:03 PM, Benjamin Kaduk wrote: > Hi Michael et al, > > As I was preparing the shepherd writeup for this document, I noticed some > things that do not block the progression of the document but do require > changes, and one item that may require further WG input. Can you prepare > a new version with the changes mentioned below? > > The one item which would potentially affect the actual protocol: at the > end of Section 5, the pseudo-random function seems to be using a SP800-108 > KDF but omits the zero byte between label and context. I think it would > be better to have the zero byte -- do you remember whether there was a > reason to omit it? (Adding the zero byte would require re-rolling some > test vectors, to be clear.) > > Additionally, all document authors will need to confirm compliance with > BCPs 78 and 79 for this document, namely that there are no intellectual > property concerns with the document that are not already disclosed. > > Please add a normative reference to RFC 2104 for HMAC, first mentioned at > the end of Section 1. > > In Section 3, it might aid clarity to mention that the 0x00000001 input to > HMAC() is the 'i' parameter from SP800-108 [indicating that this is the > first block of output, even though it is the only block of output as > well]. > > In Section 4, it might be worth re-mentioning "where PBKDF2 is the > function of that name from RFC 2898" after the algorithm block, since most > everything else used there also gets clarified. (It is already cited at > the beginning of the section, in the overview paragraph.) > > The document should be consistent about using "cipher state" as one word > or two (RFC 3961 prefers the two-word form). It also makes a rather > sudden appearance at the beginning of Section 5 with no explanatory > introduction; it might help the reader to instead start with "The RFC 3961 > cipher state that maintains cryptographic state across different > encryption operations using the same key is used as the formal > initialization vector [...]" On the next page, "cipherstate" is defined as > "a 128-bit initialization vector derived from the ciphertext", which is > potentially misleading, since it can't be both used as the IV for and > derived from the same ciphertext! Probably it's better to say "derived > from a previous (if any) ciphertext using the same encryption key, as > specified below". > > Still in Section 5, in the definition of the encryption function (well, > computing the cipherstate, really), I'm of two minds whether it's worth > mentioning that the case of L < 128 is impossible because of the 128-bit > confounder. > > In the decryption function, can you add a note to the right of "(C, H) = > ciphertext" that "[H is the last h bits of the ciphertext]"? > > In the pseudo-random function, please replace "base-key" with "input-key", > since the key input to the PRF is not expected to be a kerberos protocol > long-term base key. > > In Section 6, the "associated cryptosystem"s are supposed to be > "AES-128-CTS" or "AES-256-CTS", but those strings do not appear elsewhere > in the document. While the meaning is pretty clear, it's probably better > to just say "aes128-cts-hmac-sha256-128 or aes256-cts-hmac-sha384-192 as > appropriate". This does duplicate the preceding text, but we do want to > explicitly list the "associated encryption algorithm" as listed in the > Checksum Algorithm Profile of Section 4 of RFC 3961. > > In Section 8.1, the acronym "TGT" is used, the only instance in the > document. It's also potentially misleading, since ticket-granting tickets > are generally objects that are issued to client principals by the AS. > I'd go with "Cross-realm krbtgt keys" instead. > > The test vectors for key derivation have a parenthetical "constant = > 0x...", but the term "constant" does not appear elsewhere in the document. > The hex values are the label input for the HMAC, so we should call them > that. > > > Thanks, > > Ben > -- Mike Jenkins mjjenki@tycho.ncsc.mil - if you want me to read it only at my desk m.jenkins.364706@gmail.com - to read everywhere 443-634-3951 --001a113f17e87d5214053643b0ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ben,

we'll get started on these.

On Sun, Ju= n 26, 2016 at 11:03 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi Michael et al,

As I was preparing the shepherd writeup for this document, I noticed some things that do not block the progression of the document but do require
changes, and one item that may require further WG input.=C2=A0 Can you prep= are
a new version with the changes mentioned below?

The one item which would potentially affect the actual protocol: at the
end of Section 5, the pseudo-random function seems to be using a SP800-108<= br> KDF but omits the zero byte between label and context.=C2=A0 I think it wou= ld
be better to have the zero byte -- do you remember whether there was a
reason to omit it?=C2=A0 (Adding the zero byte would require re-rolling som= e
test vectors, to be clear.)

Additionally, all document authors will need to confirm compliance with
BCPs 78 and 79 for this document, namely that there are no intellectual
property concerns with the document that are not already disclosed.

Please add a normative reference to RFC 2104 for HMAC, first mentioned at the end of Section 1.

In Section 3, it might aid clarity to mention that the 0x00000001 input to<= br> HMAC() is the 'i' parameter from SP800-108 [indicating that this is= the
first block of output, even though it is the only block of output as
well].

In Section 4, it might be worth re-mentioning "where PBKDF2 is the
function of that name from RFC 2898" after the algorithm block, since = most
everything else used there also gets clarified.=C2=A0 (It is already cited = at
the beginning of the section, in the overview paragraph.)

The document should be consistent about using "cipher state" as o= ne word
or two (RFC 3961 prefers the two-word form).=C2=A0 It also makes a rather sudden appearance at the beginning of Section 5 with no explanatory
introduction; it might help the reader to instead start with "The RFC = 3961
cipher state that maintains cryptographic state across different
encryption operations using the same key is used as the formal
initialization vector [...]" On the next page, "cipherstate"= is defined as
"a 128-bit initialization vector derived from the ciphertext", wh= ich is
potentially misleading, since it can't be both used as the IV for and derived from the same ciphertext!=C2=A0 Probably it's better to say &qu= ot;derived
from a previous (if any) ciphertext using the same encryption key, as
specified below".

Still in Section 5, in the definition of the encryption function (well,
computing the cipherstate, really), I'm of two minds whether it's w= orth
mentioning that the case of L < 128 is impossible because of the 128-bit=
confounder.

In the decryption function, can you add a note to the right of "(C, H)= =3D
ciphertext" that "[H is the last h bits of the ciphertext]"?=

In the pseudo-random function, please replace "base-key" with &qu= ot;input-key",
since the key input to the PRF is not expected to be a kerberos protocol long-term base key.

In Section 6, the "associated cryptosystem"s are supposed to be "AES-128-CTS" or "AES-256-CTS", but those strings do no= t appear elsewhere
in the document.=C2=A0 While the meaning is pretty clear, it's probably= better
to just say "aes128-cts-hmac-sha256-128 or aes256-cts-hmac-sha384-192 = as
appropriate".=C2=A0 This does duplicate the preceding text, but we do = want to
explicitly list the "associated encryption algorithm" as listed i= n the
Checksum Algorithm Profile of Section 4 of RFC 3961.

In Section 8.1, the acronym "TGT" is used, the only instance in t= he
document.=C2=A0 It's also potentially misleading, since ticket-granting= tickets
are generally objects that are issued to client principals by the AS.
I'd go with "Cross-realm krbtgt keys" instead.

The test vectors for key derivation have a parenthetical "constant =3D=
0x...", but the term "constant" does not appear elsewhere in= the document.
The hex values are the label input for the HMAC, so we should call them
that.


Thanks,

Ben



--
Mike Jenkins
mjjenki@tycho.ncsc.mil - if you want me to read it only = at my desk
m.jenkins.364706@gmail.com - to read everywhere
443-634-395= 1
--001a113f17e87d5214053643b0ab-- From nobody Mon Jun 27 10:45:32 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C6012D64F for ; Mon, 27 Jun 2016 10:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham 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 uNYePl4x24ZL for ; Mon, 27 Jun 2016 10:45:29 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E7512D559 for ; Mon, 27 Jun 2016 10:45:29 -0700 (PDT) X-AuditID: 12074424-b0fff70000003c37-11-577166378c13 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 3E.B6.15415.73661775; Mon, 27 Jun 2016 13:45:28 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u5RHjRSJ031938; Mon, 27 Jun 2016 13:45:27 -0400 Received: from [18.101.8.211] (vpn-18-101-8-211.mit.edu [18.101.8.211]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u5RHjO8f004030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Jun 2016 13:45:26 -0400 To: Nathaniel McCallum , Benjamin Kaduk References: <20160516161709.16705.29515.idtracker@ietfa.amsl.com> <1463416879.2542.15.camel@redhat.com> <1466709219.20951.3.camel@redhat.com> <1467033683.2592.2.camel@redhat.com> From: Greg Hudson Message-ID: <57716634.9000207@mit.edu> Date: Mon, 27 Jun 2016 13:45:24 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <1467033683.2592.2.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrWuRVhhusLNBwOLo5lUsFnO/zmJ1 YPJYsuQnk8f7fVfZApiiuGxSUnMyy1KL9O0SuDLOdu1lKuhmqpjcJtPAeIWxi5GTQ0LAROL3 k+nMXYxcHEICbUwSj1e0s0A4Gxkltp7dxAjhHGGSuPj4DAtIi7CAr8S5Y6eYQGwRAT+Jta96 oDreMUpsm9fHCpJgFhCWWL7mLBuIzSagLLF+/1awZl4BNYm951aB1bAIqEpsnz6fHcQWFYiQ mLX9BxNEjaDEyZlPwOo5BQwlth3axwQxU13iz7xLzBC2vMT2t3OYJzAKzELSMgtJ2SwkZQsY mVcxyqbkVunmJmbmFKcm6xYnJ+blpRbpmuvlZpbopaaUbmIEhSq7i8oOxu4e70OMAhyMSjy8 GvIF4UKsiWXFlbmHGCU5mJREebc9yg0X4kvKT6nMSCzOiC8qzUktPsQowcGsJMLbl1wYLsSb klhZlVqUD5OS5mBREudlZGBgEBJITyxJzU5NLUgtgsnKcHAoSfDKpQI1ChalpqdWpGXmlCCk mTg4QYbzAA1nAanhLS5IzC3OTIfIn2LU5Vjw4/ZaJiGWvPy8VClx3tIUoCIBkKKM0jy4OeAU k8px+RWjONBbwrzuIKN4gOkJbtIroCVMQEtYq/NBlpQkIqSkGhg9MmZfcl/5ZO2c6qlL/7sf sVe1+deSvuLjMb3fPrwy808e0ectuP3WsFvAXdLC/Oqi52c3nHKJ4v/645pjx6EgBie/jetE 0uvarl1N1KmJXHE0U8O2Q/rElkrpfFXevgQPoXtSU/fZK2W8TDFj95jDt39JU3lklWSg5PO6 C2aR4dbr6yVjpZRYijMSDbWYi4oTAeo09zMMAwAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-krb-auth-indicator-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 17:45:31 -0000 On 06/27/2016 09:21 AM, Nathaniel McCallum wrote: > I'm happy to do so. But, AFAIK, the only review thus far has been > yours. There were several other +1's to WG adoption, but no other > reviews. I just reviewed the -02 draft and found no significant issues. From nobody Mon Jun 27 14:27:49 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB1D12D95E for ; Mon, 27 Jun 2016 14:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 MiKlUSfOPqBU for ; Mon, 27 Jun 2016 14:27:44 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5176812D982 for ; Mon, 27 Jun 2016 14:27:44 -0700 (PDT) Received: by us.padl.com with ESMTP id u5RLRdNX005832; Mon, 27 Jun 2016 17:27:41 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Luke Howard In-Reply-To: Date: Tue, 28 Jun 2016 07:27:46 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5596DB1C-B1AA-4C5B-94B6-3FA033B8161E@padl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "kitten@ietf.org" , draft-ietf-kitten-aes-cts-hmac-sha2@tools.ietf.org Subject: Re: [kitten] shepherd review of draft-aes-cts-hmac-sha2-09 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 21:27:48 -0000 Our implementation assumes that the context is always empty and only the = label is used. But it=E2=80=99s trivial to change if you update the = draft to use the context for the PRF. =E2=80=94 Luke= From nobody Mon Jun 27 14:42:00 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AFD12DA35 for ; Mon, 27 Jun 2016 14:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham 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 tYo6TgKcAYYn for ; Mon, 27 Jun 2016 14:41:58 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6517E12DA49 for ; Mon, 27 Jun 2016 14:39:43 -0700 (PDT) X-AuditID: 12074423-88bff70000004bf8-5a-57719d1da1a3 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 63.88.19448.D1D91775; Mon, 27 Jun 2016 17:39:42 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u5RLdfFn031075; Mon, 27 Jun 2016 17:39:41 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u5RLdbUT016927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Jun 2016 17:39:40 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u5RLdbQX028339; Mon, 27 Jun 2016 17:39:37 -0400 (EDT) Date: Mon, 27 Jun 2016 17:39:36 -0400 (EDT) From: Benjamin Kaduk To: Luke Howard In-Reply-To: Message-ID: References: <5596DB1C-B1AA-4C5B-94B6-3FA033B8161E@padl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-762128768-1467063576=:18480" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsUixG6nois3tzDcYO58MYutN78zWhzdvIrF 4u6l/+wWy75dZXNg8dg56y67x5IlP5k85n6YxuLx5fJntgCWKC6blNSczLLUIn27BK6Me6fP MRVcYqt4+usGawPjLtYuRk4OCQETie0T3zJ3MXJxCAm0MUm0np7GBOFsZJT4d30ilHOISaL7 0ixGCKeBUWLBsk1g/SwC2hKHP0xlBLHZBFQkZr7ZyAZiiwgoSEzevxZsLrPAbEaJeYvPs4Mk hAWcJW6/6mYGsTkFbCS2bmgHs3kFHCW2PJ/FCrHhOqPEibf7wKaKCuhIrN4/hQWiSFDi5Mwn YDazQIDE4aZVLBMYBWYhSc1CkoKw1SUaH5xlg7C1Je7fbGNbwMiyilE2JbdKNzcxM6c4NVm3 ODkxLy+1SNdMLzezRC81pXQTIzjgXZR3ML7s8z7EKMDBqMTDu6OuMFyINbGsuDL3EKMkB5OS KO+piUAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIryFs4FyvCmJlVWpRfkwKWkOFiVxXkYGBgYh gfTEktTs1NSC1CKYrAwHh5IEbyNIo2BRanpqRVpmTglCmomDE2Q4D9Dw5zNBhhcXJOYWZ6ZD 5E8x6nIs+HF7LZMQS15+XqqUOK8tyCABkKKM0jy4OeBEtZtJ9RWjONBbwrwnQap4gEkObtIr oCVMQEtYq/NBlpQkIqSkGhiVDz6XTlU8e7JO5aCyu3PFld08NoenX9ecLn9Hchb3vgm3XnLv ObNlwYPfk8piq08csPoy+/LdHYfDvn9mnti871z4smT2d1d6Fzvu/nppIVeH9VSuud2XXuVe 3ZRqt6THccOyWYlCYQWthSHGfSGHD99b0VjjwL7sBcNCtpOzjRdfzHhqfu71DCWW4oxEQy3m ouJEAK/AdHUvAwAA Archived-At: Cc: "kitten@ietf.org" , draft-ietf-kitten-aes-cts-hmac-sha2@tools.ietf.org Subject: Re: [kitten] shepherd review of draft-aes-cts-hmac-sha2-09 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 21:42:00 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-762128768-1467063576=:18480 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 27 Jun 2016, Luke Howard wrote: > Our implementation assumes that the context is always empty and only the > label is used. But it=E2=80=99s trivial to change if you update the draft= to use > the context for the PRF. Yeah, I don't expect much trouble for implementations if this does change. A big reason I'm inclined to treat the PRF input as context and not label is that in some scenarios it can be attacker-controlled, so having the forced separation from the prf prefix could be useful. -Ben ---559023410-762128768-1467063576=:18480-- From nobody Mon Jun 27 18:49:58 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C4412DAD4 for ; Mon, 27 Jun 2016 18:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham 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 DgbbKu4zpyln for ; Mon, 27 Jun 2016 18:49:56 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5413712DAD1 for ; Mon, 27 Jun 2016 18:49:55 -0700 (PDT) X-AuditID: 12074423-88bff70000004bf8-79-5771d7c1f58f Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id F4.02.19448.1C7D1775; Mon, 27 Jun 2016 21:49:54 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u5S1nq9S023246; Mon, 27 Jun 2016 21:49:53 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u5S1nntx010281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Jun 2016 21:49:52 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u5S1nnqp000396; Mon, 27 Jun 2016 21:49:49 -0400 (EDT) Date: Mon, 27 Jun 2016 21:49:48 -0400 (EDT) From: Benjamin Kaduk To: Michael Jenkins In-Reply-To: Message-ID: References: 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+NgFnrNIsWRmVeSWpSXmKPExsUixCmqrXvoemG4waf3PBZbb35ntDi6eRWL xbJvV9kcmD12zrrL7rFkyU8mjy+XP7MFMEdx2aSk5mSWpRbp2yVwZeza+Zex4LFaxfWnLxgb GC/JdTFyckgImEicWvKHGcQWEmhjklgyMaeLkQvI3sgoceHAAWYI5xCTxLwfrSwQTgOjxNLr T4EyHBwsAtoSc3+7gnSzCahIzHyzkQ3EFhEwkFg0aR2YzSzgLrHt/z5WEFtYwEpi673p7CA2 p0CgRFPzNrAaXgFHiRPbnrJDzG9jlLi54y4TSEJUQEdi9f4pLBBFghInZz5hgRiqJbF8+jaW CYwCs5CkZiFJLWBkWsUom5JbpZubmJlTnJqsW5ycmJeXWqRrppebWaKXmlK6iREUpuwuyjsY X/Z5H2IU4GBU4uHdUVcYLsSaWFZcmXuIUZKDSUmU99REoBBfUn5KZUZicUZ8UWlOavEhRgkO ZiUR3vyrQDnelMTKqtSifJiUNAeLkjgvIwMDg5BAemJJanZqakFqEUxWhoNDSYL34TWgRsGi 1PTUirTMnBKENBMHJ8hwHqDhbNdBhhcXJOYWZ6ZD5E8xKkqJ83aANAuAJDJK8+B6wWlkN5Pq K0ZxoFeEeW+BVPEAUxBc9yugwUxAg1mr80EGlyQipKQaGBkSL8tcsF7vn+BRzfzk8qP3e0/t TvFLm3Xq1xHRnymBu3Y3L2g8oHSpgC3b6eGelS3++dx7bxaXGPrnKgm+lC54KxG9qD5vauVf Jq7k3w+zgsVKV67Pl/oT9ipsK1tm/Iou78g2hwklCUmJZ282P/LunhFyO/fm088rfYr2fl1V tit+TmzuRCWW4oxEQy3mouJEAELtfXf+AgAA Archived-At: Cc: kitten@ietf.org, draft-ietf-kitten-aes-cts-hmac-sha2@tools.ietf.org Subject: Re: [kitten] shepherd review of draft-aes-cts-hmac-sha2-09 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 01:49:57 -0000 Thanks, Michael. If the WG does want to treat the PRF octet-string input as a SP800-108 context and use a zero-byte separator, it seems like the "quick-and-dirty" patch would be to just stick one in after "prf" and then there would be another (somewhat superfluous) one appended after the octet-string by KDF-HMAC-SHA2. That might be easier than essentially inlining the definitino of KDF-HMAC-SHA2 for just the PRF calculation. -Ben On Mon, 27 Jun 2016, Michael Jenkins wrote: > Ben, > > we'll get started on these. > > On Sun, Jun 26, 2016 at 11:03 PM, Benjamin Kaduk wrote: > > > Hi Michael et al, > > > > As I was preparing the shepherd writeup for this document, I noticed some > > things that do not block the progression of the document but do require > > changes, and one item that may require further WG input. Can you prepare > > a new version with the changes mentioned below? > > > > The one item which would potentially affect the actual protocol: at the > > end of Section 5, the pseudo-random function seems to be using a SP800-108 > > KDF but omits the zero byte between label and context. I think it would > > be better to have the zero byte -- do you remember whether there was a > > reason to omit it? (Adding the zero byte would require re-rolling some > > test vectors, to be clear.) > > > > Additionally, all document authors will need to confirm compliance with > > BCPs 78 and 79 for this document, namely that there are no intellectual > > property concerns with the document that are not already disclosed. > > > > Please add a normative reference to RFC 2104 for HMAC, first mentioned at > > the end of Section 1. > > > > In Section 3, it might aid clarity to mention that the 0x00000001 input to > > HMAC() is the 'i' parameter from SP800-108 [indicating that this is the > > first block of output, even though it is the only block of output as > > well]. > > > > In Section 4, it might be worth re-mentioning "where PBKDF2 is the > > function of that name from RFC 2898" after the algorithm block, since most > > everything else used there also gets clarified. (It is already cited at > > the beginning of the section, in the overview paragraph.) > > > > The document should be consistent about using "cipher state" as one word > > or two (RFC 3961 prefers the two-word form). It also makes a rather > > sudden appearance at the beginning of Section 5 with no explanatory > > introduction; it might help the reader to instead start with "The RFC 3961 > > cipher state that maintains cryptographic state across different > > encryption operations using the same key is used as the formal > > initialization vector [...]" On the next page, "cipherstate" is defined as > > "a 128-bit initialization vector derived from the ciphertext", which is > > potentially misleading, since it can't be both used as the IV for and > > derived from the same ciphertext! Probably it's better to say "derived > > from a previous (if any) ciphertext using the same encryption key, as > > specified below". > > > > Still in Section 5, in the definition of the encryption function (well, > > computing the cipherstate, really), I'm of two minds whether it's worth > > mentioning that the case of L < 128 is impossible because of the 128-bit > > confounder. > > > > In the decryption function, can you add a note to the right of "(C, H) = > > ciphertext" that "[H is the last h bits of the ciphertext]"? > > > > In the pseudo-random function, please replace "base-key" with "input-key", > > since the key input to the PRF is not expected to be a kerberos protocol > > long-term base key. > > > > In Section 6, the "associated cryptosystem"s are supposed to be > > "AES-128-CTS" or "AES-256-CTS", but those strings do not appear elsewhere > > in the document. While the meaning is pretty clear, it's probably better > > to just say "aes128-cts-hmac-sha256-128 or aes256-cts-hmac-sha384-192 as > > appropriate". This does duplicate the preceding text, but we do want to > > explicitly list the "associated encryption algorithm" as listed in the > > Checksum Algorithm Profile of Section 4 of RFC 3961. > > > > In Section 8.1, the acronym "TGT" is used, the only instance in the > > document. It's also potentially misleading, since ticket-granting tickets > > are generally objects that are issued to client principals by the AS. > > I'd go with "Cross-realm krbtgt keys" instead. > > > > The test vectors for key derivation have a parenthetical "constant = > > 0x...", but the term "constant" does not appear elsewhere in the document. > > The hex values are the label input for the HMAC, so we should call them > > that. > > > > > > Thanks, > > > > Ben > > > > > > -- > Mike Jenkins > mjjenki@tycho.ncsc.mil - if you want me to read it only at my desk > m.jenkins.364706@gmail.com - to read everywhere > 443-634-3951 > From nobody Tue Jun 28 00:21:21 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5AC12DB08 for ; Tue, 28 Jun 2016 00:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 h52psYK1ZzwH for ; Tue, 28 Jun 2016 00:21:17 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F05512DB09 for ; Tue, 28 Jun 2016 00:21:16 -0700 (PDT) Received: by us.padl.com with ESMTP id u5S7LAdB018310; Tue, 28 Jun 2016 03:21:14 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Luke Howard X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Tue, 28 Jun 2016 17:21:10 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <677848B0-17A4-47A6-93EB-F9939654DBAC@padl.com> References: To: Benjamin Kaduk Archived-At: Cc: kitten@ietf.org, draft-ietf-kitten-aes-cts-hmac-sha2@tools.ietf.org Subject: Re: [kitten] shepherd review of draft-aes-cts-hmac-sha2-09 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 07:21:20 -0000 I reckon let's do it "properly" even if at the expense of redundant text. Sent from my iPhone > On 28 Jun 2016, at 11:49, Benjamin Kaduk wrote: >=20 > Thanks, Michael. >=20 > If the WG does want to treat the PRF octet-string input as a SP800-108 > context and use a zero-byte separator, it seems like the "quick-and-dirty"= > patch would be to just stick one in after "prf" and then there would be > another (somewhat superfluous) one appended after the octet-string by > KDF-HMAC-SHA2. That might be easier than essentially inlining the > definitino of KDF-HMAC-SHA2 for just the PRF calculation. >=20 > -Ben >=20 >> On Mon, 27 Jun 2016, Michael Jenkins wrote: >>=20 >> Ben, >>=20 >> we'll get started on these. >>=20 >>> On Sun, Jun 26, 2016 at 11:03 PM, Benjamin Kaduk wrote: >>>=20 >>> Hi Michael et al, >>>=20 >>> As I was preparing the shepherd writeup for this document, I noticed som= e >>> things that do not block the progression of the document but do require >>> changes, and one item that may require further WG input. Can you prepar= e >>> a new version with the changes mentioned below? >>>=20 >>> The one item which would potentially affect the actual protocol: at the >>> end of Section 5, the pseudo-random function seems to be using a SP800-1= 08 >>> KDF but omits the zero byte between label and context. I think it would= >>> be better to have the zero byte -- do you remember whether there was a >>> reason to omit it? (Adding the zero byte would require re-rolling some >>> test vectors, to be clear.) >>>=20 >>> Additionally, all document authors will need to confirm compliance with >>> BCPs 78 and 79 for this document, namely that there are no intellectual >>> property concerns with the document that are not already disclosed. >>>=20 >>> Please add a normative reference to RFC 2104 for HMAC, first mentioned a= t >>> the end of Section 1. >>>=20 >>> In Section 3, it might aid clarity to mention that the 0x00000001 input t= o >>> HMAC() is the 'i' parameter from SP800-108 [indicating that this is the >>> first block of output, even though it is the only block of output as >>> well]. >>>=20 >>> In Section 4, it might be worth re-mentioning "where PBKDF2 is the >>> function of that name from RFC 2898" after the algorithm block, since mo= st >>> everything else used there also gets clarified. (It is already cited at= >>> the beginning of the section, in the overview paragraph.) >>>=20 >>> The document should be consistent about using "cipher state" as one word= >>> or two (RFC 3961 prefers the two-word form). It also makes a rather >>> sudden appearance at the beginning of Section 5 with no explanatory >>> introduction; it might help the reader to instead start with "The RFC 39= 61 >>> cipher state that maintains cryptographic state across different >>> encryption operations using the same key is used as the formal >>> initialization vector [...]" On the next page, "cipherstate" is defined a= s >>> "a 128-bit initialization vector derived from the ciphertext", which is >>> potentially misleading, since it can't be both used as the IV for and >>> derived from the same ciphertext! Probably it's better to say "derived >>> from a previous (if any) ciphertext using the same encryption key, as >>> specified below". >>>=20 >>> Still in Section 5, in the definition of the encryption function (well, >>> computing the cipherstate, really), I'm of two minds whether it's worth >>> mentioning that the case of L < 128 is impossible because of the 128-bit= >>> confounder. >>>=20 >>> In the decryption function, can you add a note to the right of "(C, H) =3D= >>> ciphertext" that "[H is the last h bits of the ciphertext]"? >>>=20 >>> In the pseudo-random function, please replace "base-key" with "input-key= ", >>> since the key input to the PRF is not expected to be a kerberos protocol= >>> long-term base key. >>>=20 >>> In Section 6, the "associated cryptosystem"s are supposed to be >>> "AES-128-CTS" or "AES-256-CTS", but those strings do not appear elsewher= e >>> in the document. While the meaning is pretty clear, it's probably bette= r >>> to just say "aes128-cts-hmac-sha256-128 or aes256-cts-hmac-sha384-192 as= >>> appropriate". This does duplicate the preceding text, but we do want to= >>> explicitly list the "associated encryption algorithm" as listed in the >>> Checksum Algorithm Profile of Section 4 of RFC 3961. >>>=20 >>> In Section 8.1, the acronym "TGT" is used, the only instance in the >>> document. It's also potentially misleading, since ticket-granting ticke= ts >>> are generally objects that are issued to client principals by the AS. >>> I'd go with "Cross-realm krbtgt keys" instead. >>>=20 >>> The test vectors for key derivation have a parenthetical "constant =3D >>> 0x...", but the term "constant" does not appear elsewhere in the documen= t. >>> The hex values are the label input for the HMAC, so we should call them >>> that. >>>=20 >>>=20 >>> Thanks, >>>=20 >>> Ben >>=20 >>=20 >>=20 >> -- >> Mike Jenkins >> mjjenki@tycho.ncsc.mil - if you want me to read it only at my desk >> m.jenkins.364706@gmail.com - to read everywhere >> 443-634-3951 >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Tue Jun 28 04:59:00 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A09D12DE3E for ; Tue, 28 Jun 2016 04:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=secure-endpoints.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 LgEExj40LiWH for ; Tue, 28 Jun 2016 04:58:56 -0700 (PDT) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACC8F12DE34 for ; Tue, 28 Jun 2016 04:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1467115113; x=1467719913; i=jaltman@secure-endpoints.com; q=dns/txt; h=VBR-Info:Subject:To: References:Cc:From:Openpgp:Organization:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type; bh=H0PzHdYMGaV 482z1BYCJhUS+/bhpt4tVfIPx/7kZGAw=; b=AsyLy7gizkaUToLnARJrv6hhuqx S6IlpJc1Sytb8MfN+X1sPM1nPC0IvZC8NFb2JIzq2kcmUG7iluhjAWd0sukU+lsU hSRiXlmhX5KEA8IRLZcrryPo5ujhgeGZ1ekp8FAVw10KMxT3NuffP/TAl0lRHSC0 Wp3Re2wSdnoeWFFk= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Tue, 28 Jun 2016 07:58:33 -0400 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Tue, 28 Jun 2016 07:58:32 -0400 Received: from [x.x.x.x] by secure-endpoints.com (Cipher TLSv1:AES-SHA:256) (MDaemon PRO v16.0.3) with ESMTPSA id md50001110180.msg for ; Tue, 28 Jun 2016 07:58:31 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDArrival-Date: Tue, 28 Jun 2016 07:58:31 -0400 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=19870317dd=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org To: Luke Howard , Benjamin Kaduk References: <677848B0-17A4-47A6-93EB-F9939654DBAC@padl.com> From: Jeffrey Altman Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=http://pgp.mit.edu Organization: Secure Endpoints Inc. Message-ID: <12304a67-7cd8-9010-7164-abfd0a47d0d4@secure-endpoints.com> Date: Tue, 28 Jun 2016 07:58:23 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <677848B0-17A4-47A6-93EB-F9939654DBAC@padl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000002040606020708070807" Archived-At: Cc: kitten@ietf.org, draft-ietf-kitten-aes-cts-hmac-sha2@tools.ietf.org Subject: Re: [kitten] shepherd review of draft-aes-cts-hmac-sha2-09 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 11:58:59 -0000 This is a cryptographically signed message in MIME format. --------------ms000002040606020708070807 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 On 6/28/2016 3:21 AM, Luke Howard wrote: > I reckon let's do it "properly" even if at the expense of redundant tex= t. >=20 > Sent from my iPhone >=20 >> On 28 Jun 2016, at 11:49, Benjamin Kaduk wrote: >> >> Thanks, Michael. >> >> If the WG does want to treat the PRF octet-string input as a SP800-108= >> context and use a zero-byte separator, it seems like the "quick-and-di= rty" >> patch would be to just stick one in after "prf" and then there would b= e >> another (somewhat superfluous) one appended after the octet-string by >> KDF-HMAC-SHA2. That might be easier than essentially inlining the >> definitino of KDF-HMAC-SHA2 for just the PRF calculation. >> >> -Ben >> >>> On Mon, 27 Jun 2016, Michael Jenkins wrote: >>> >>> Ben, >>> >>> we'll get started on these. >>> >>>> On Sun, Jun 26, 2016 at 11:03 PM, Benjamin Kaduk wro= te: >>>> >>>> Hi Michael et al, >>>> >>>> As I was preparing the shepherd writeup for this document, I noticed= some >>>> things that do not block the progression of the document but do requ= ire >>>> changes, and one item that may require further WG input. Can you pr= epare >>>> a new version with the changes mentioned below? >>>> >>>> The one item which would potentially affect the actual protocol: at = the >>>> end of Section 5, the pseudo-random function seems to be using a SP8= 00-108 >>>> KDF but omits the zero byte between label and context. I think it w= ould >>>> be better to have the zero byte -- do you remember whether there was= a >>>> reason to omit it? (Adding the zero byte would require re-rolling s= ome >>>> test vectors, to be clear.) >>>> >>>> Additionally, all document authors will need to confirm compliance w= ith >>>> BCPs 78 and 79 for this document, namely that there are no intellect= ual >>>> property concerns with the document that are not already disclosed. >>>> >>>> Please add a normative reference to RFC 2104 for HMAC, first mention= ed at >>>> the end of Section 1. >>>> >>>> In Section 3, it might aid clarity to mention that the 0x00000001 in= put to >>>> HMAC() is the 'i' parameter from SP800-108 [indicating that this is = the >>>> first block of output, even though it is the only block of output as= >>>> well]. >>>> >>>> In Section 4, it might be worth re-mentioning "where PBKDF2 is the >>>> function of that name from RFC 2898" after the algorithm block, sinc= e most >>>> everything else used there also gets clarified. (It is already cite= d at >>>> the beginning of the section, in the overview paragraph.) >>>> >>>> The document should be consistent about using "cipher state" as one = word >>>> or two (RFC 3961 prefers the two-word form). It also makes a rather= >>>> sudden appearance at the beginning of Section 5 with no explanatory >>>> introduction; it might help the reader to instead start with "The RF= C 3961 >>>> cipher state that maintains cryptographic state across different >>>> encryption operations using the same key is used as the formal >>>> initialization vector [...]" On the next page, "cipherstate" is defi= ned as >>>> "a 128-bit initialization vector derived from the ciphertext", which= is >>>> potentially misleading, since it can't be both used as the IV for an= d >>>> derived from the same ciphertext! Probably it's better to say "deri= ved >>>> from a previous (if any) ciphertext using the same encryption key, a= s >>>> specified below". >>>> >>>> Still in Section 5, in the definition of the encryption function (we= ll, >>>> computing the cipherstate, really), I'm of two minds whether it's wo= rth >>>> mentioning that the case of L < 128 is impossible because of the 128= -bit >>>> confounder. >>>> >>>> In the decryption function, can you add a note to the right of "(C, = H) =3D >>>> ciphertext" that "[H is the last h bits of the ciphertext]"? >>>> >>>> In the pseudo-random function, please replace "base-key" with "input= -key", >>>> since the key input to the PRF is not expected to be a kerberos prot= ocol >>>> long-term base key. >>>> >>>> In Section 6, the "associated cryptosystem"s are supposed to be >>>> "AES-128-CTS" or "AES-256-CTS", but those strings do not appear else= where >>>> in the document. While the meaning is pretty clear, it's probably b= etter >>>> to just say "aes128-cts-hmac-sha256-128 or aes256-cts-hmac-sha384-19= 2 as >>>> appropriate". This does duplicate the preceding text, but we do wan= t to >>>> explicitly list the "associated encryption algorithm" as listed in t= he >>>> Checksum Algorithm Profile of Section 4 of RFC 3961. >>>> >>>> In Section 8.1, the acronym "TGT" is used, the only instance in the >>>> document. It's also potentially misleading, since ticket-granting t= ickets >>>> are generally objects that are issued to client principals by the AS= =2E >>>> I'd go with "Cross-realm krbtgt keys" instead. >>>> >>>> The test vectors for key derivation have a parenthetical "constant =3D= >>>> 0x...", but the term "constant" does not appear elsewhere in the doc= ument. >>>> The hex values are the label input for the HMAC, so we should call t= hem >>>> that. >>>> >>>> >>>> Thanks, >>>> >>>> Ben >>> >>> >>> >>> -- >>> Mike Jenkins >>> mjjenki@tycho.ncsc.mil - if you want me to read it only at my desk >>> m.jenkins.364706@gmail.com - to read everywhere >>> 443-634-3951 >> >> _______________________________________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >=20 --------------ms000002040606020708070807 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DFkwggYVMIIE/aADAgECAhBwEYNf9/MBLeKNZZ697cPvMA0GCSqGSIb3DQEBCwUAMIGmMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5 bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3 MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH NTAeFw0xNTEyMjAwMDAwMDBaFw0xNjEyMjAyMzU5NTlaMIGvMS4wLAYDVQQDDCVQZXJzb25h IE5vdCBWYWxpZGF0ZWQgLSAxNDUwNTc0MTU1Njc5MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFu QHNlY3VyZS1lbmRwb2ludHMuY29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNv bmEgTm90IFZhbGlkYXRlZDEfMB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM0X8uixbo9Tu+sKS20bZeCbN9brFQbtkQ5x /6MrkGsQNTzQ/2WZFJzH89ZoC8auZRFQdA6/yh4wXdCNQ6hBO8Lom26t0LHGhoWtzdkP7MWu YeLMZiuOsC6N6ejHEbtt0KLjphNIUvBVFx5JQzgAwJ1I08LSZg/bIGAVF3SfLOVFu2Iiq5kj psHOv/ECV13fGSvYwBXJN1C1To6wxDgn4pl3m6fFfe4xiVEpc3t6GbKcI+4blK9w76fDaVXw U2uJQAG1UYxbChwocBmb3ka1MlUb2ug3oYBpnufD9zk8u3UqaFlfYyr6/2cr6fqiz1U4+xcb Q3otvVWwzRecpmPEiIcCAwEAAaOCAjIwggIuMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQD AgWgMCAGA1UdJQEB/wQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU2Pc1OxE6 W8hcBZ5L2346cucbFa8wJwYDVR0RBCAwHoEcamFsdG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNv bTBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEWGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20v cnBhMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzU3 ZGU3YTIzOGQ0NWQ4ZDRmYzcxZjhhNWM2YjgxYzkzL0xhdGVzdENSTC5jcmwwTgYIKwYBBQUH AQEEQjBAMD4GCCsGAQUFBzAChjJodHRwOi8vY2FjZXIuc3ltYXV0aC5jb20vbXBraS9zeW1j YzFpbmRzdWJjYWc1LmNydDAfBgNVHSMEGDAWgBRnGbY9pXm7M2DYLVPTjAk9B6wYcDArBgpg hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGt7pITFgUxMDkyMjA5BgpghkgBhvhFARAF BCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3 DQEBCwUAA4IBAQBvO/+L6Tms91Ed1ZJzgT0y9jBK/Armb6Y/EnR1swCDMqRfBzGSGtzOCuN7 PteBvlaB5vmnwEwiZR/FtsDhhORd8Xy5wdmCunhwPbf0ClnBqichI+4UZNS5fCQTciIqHFxq 7EKuHOQm4/ssEH2Xr8yIpCd+Dx9oPEG7MqUno6oxcIDdur4iNKxOBtjWNiXM7rn733qtuFlw 1jIX3eFIsrBALikTU1UbY2KwfewXbiVaFWY0ysl5uOgfWdmj2xBk7aft/L/fnuyWyeeM9IBg 6vdUjPhmJwtFdEdefgP5cRRdYgG8zgJf8Rq84slkea0bwis8PvKVksJ/k2scaDHzKTe2MIIG PDCCBSSgAwIBAgIQBwKiGoW4S2WeGApu5vWjZTANBgkqhkiG9w0BAQsFADCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRo b3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmlt YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMTUxMDAxMDAwMDAwWhcNMjUw OTMwMjM1OTU5WjCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0 aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW+w0x SSLADLrvTi0XuLQw5TTSrAnuyYkAXfSuExGzE45VzyIYqCAGpv0ly2iUtKCCkA5ulpJE7hW5 tOz6z3k9adScH9wgmg4o1Q21xp468dRlGcCEM02O2orx1ie5A6DR+iicgpNs9w2FfVvpTpli /pNC0u4+s3FXhpdGy98N4caEWrMNj/X0EIoFXZ9oRuwIsFhCgva+LRBGpiQLJ/6YFFODk4Lb 6sA/T6JYYbVLcmkSXzNZ9vmzTABkzoXFhpIMbhzrKM9xqZCpdJl0JOtI4Q5daBKoAWbo7pqy L/g9zbd4JM6lYHzoFj1J8Qe6M74yK8JnoxbHb8DSWpQEwmtFAgMBAAGjggI+MIICOjA3Bggr BgEFBQcBAQQrMCkwJwYIKwYBBQUHMAGGG2h0dHA6Ly9wa2ktb2NzcC5zeW1hdXRoLmNvbTAS BgNVHRMBAf8ECDAGAQH/AgEAMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEF BQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDov L3d3dy5zeW1hdXRoLmNvbS9ycGEwLwYDVR0fBCgwJjAkoCKgIIYeaHR0cDovL3Muc3ltY2Iu Y29tL3BjYTEtZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRU3ltYW50ZWNQS0ktMi0yMTcwHQYDVR0OBBYEFGcZtj2lebszYNgtU9OMCT0HrBhwMIHx BgNVHSMEgekwgeahgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5 OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQsFAAOCAQEARhnkJ3U7vq/i 2qIUYI8eRJCBaStjSTWN6Xa6n5iPE4HXy/xlG/gOY96UKHT742/YySp6DlSmg64pSvYrUf09 OBK73WNF+2TMPlSGf05CbSO3HQv9+swNjpM1yuVF+c8vf3k9YxjHRyNK9qkUAK1+WVUaiSfb lKCROMb+QJWjYPZduMjFFu2cZmkURhBKynAqb9FQ4CYa01K0R3KLRdK9A7ml3NkI85CrdHCr yqBO8MBO5OC+T5ARYCcMKxzf52zKdbQl55FIqpK0UXVfKZtHFxy9yerPda11I8/yxd9aq7dr yru4XqvVo3DUaPMXepsLoBQ8++iBVmjoz118c7guvDGCBGIwggReAgEBMIG7MIGmMQswCQYD VQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNQIQ cBGDX/fzAS3ijWWeve3D7zANBglghkgBZQMEAgEFAKCCAncwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNjI4MTE1ODI0WjAvBgkqhkiG9w0BCQQxIgQg XRRzYbgltw0GLvlroq1wGh2RBQ6fuIm17c4MKslqKWswbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7 MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNV BAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHNQIQcBGDX/fzAS3ijWWeve3D7zCBzgYLKoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3lt YW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc1 AhBwEYNf9/MBLeKNZZ697cPvMA0GCSqGSIb3DQEBAQUABIIBAEKsdEunQtTFepAOnmUlnL5Q 9HG0dSuuRhE/jD3DbB+CLDhxhRoTS3wbKuyfJdLmlPdnvhP776/mHFli6hlPHrje1lFUct+y hdTjZme/zWxmFLI4l4ezDA/OY0QZMlM05zHJv/Gy6DP36hR8s04GfjECOiPRhZohhrLDqf72 aqYMoalqM7XrEql1bgiFAp1rtcvIx/mtaXzWmHeppYGmTEGmzCa7coyejVfY3WTUkXUpVDr2 ogM1WA8giOHUvPf5duJUtEb1i4K5+jy6JuWt+5AxGbdH4XjJWhXtstHHERh9MKvF/divZW82 2HucCw04j8SL6VDb8Uwy7m8iN8wtcOcAAAAAAAA= --------------ms000002040606020708070807--