From nobody Mon May 2 08:28:55 2016 Return-Path: X-Original-To: lager@ietfa.amsl.com Delivered-To: lager@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BAA12D572 for ; Mon, 2 May 2016 08:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=cloudregistry-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dC2QNZ6rllVG for ; Mon, 2 May 2016 08:28:51 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 BC15012D0FE for ; Mon, 2 May 2016 08:28:51 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id n63so75856530qkf.0 for ; Mon, 02 May 2016 08:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudregistry-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=x/VoAL4EQGf/dYETktc4/uh8+tq3NTPMpvr2TBSdEzI=; b=E5EXetRsXfImbCn2lSU3Sg+49e+S0h3sgXXdR6saivtEdzzStqu1AVV1Gw034Mv/Mz Iz283QkA8UZBPT/e09rfytDadpTrat4V5+5gebH2YIJKwoDJuGwp5vCFaPPosP+YuTWB Y6xnRmMm03MFwbDqrPSfuOOal6Yb5VqaQw9ZgY7yYbTYQ7PTMEPkg7TuyNmDma7kVyIR DIINVEg0YjyeQ1ZeP3jcYXbM8l4lTGL3hjtplo0Ayip83lHQq0pxd+WcY42CfzIA5szO A9AoDCSlVxacmHqzfXvOp2OTjliDYheCW8I3w3tBYL8rZ3nrKf4Da1/D2fNOFT04dFzz U/cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=x/VoAL4EQGf/dYETktc4/uh8+tq3NTPMpvr2TBSdEzI=; b=Pwv3lMtZRJmExYWu62D/oa+M0/zhiBwvwXVUEkj07tUscp8AwnbeH4e2M55X3j/N23 5UzL+EoyTP2l4wDgBHGki+KH+2II6fNQcB/SeYTEtEAqIN2g0DuK/UpXyCPmiq33pAId r2gijeqgOWrrYt1DIBq3560EdhNa8KLbPLB/NCqZrF0W5wunjL4JWnr2MeipsfffABdi ObJ3ZXW7HeuVsHPTai5+mGQMhBeglHjv68aPxyhnPlrKW+dLoIMFrUfXOMmIZLRg6JZn aQqqECgIUqlPGJc6J5EWlneWl/c4BVB1WGEBU+gAqg5/ZtXxMD8kd1BGbQO5igwxjnSE 9deQ== X-Gm-Message-State: AOPr4FVuU+Ov7uR2gXubRg//K2Pvzdq+9ZGv0ob3/7kElQ14z2AG2I86FnTKdO6FdfOo45Rtd6V3PZg0ATjheg== X-Received: by 10.233.223.67 with SMTP id t64mr35117509qkf.162.1462202930636; Mon, 02 May 2016 08:28:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.27.37 with HTTP; Mon, 2 May 2016 08:28:11 -0700 (PDT) From: Wil Tan Date: Tue, 3 May 2016 01:28:11 +1000 Message-ID: To: "lager WG (lager@ietf.org)" Content-Type: multipart/alternative; boundary=94eb2c04427a453a040531dda66d Archived-At: Cc: "Asmus Freytag \(c\)" Subject: [Lager] Proposed Schema Change - class-or-set-operator-nested X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 15:28:54 -0000 --94eb2c04427a453a040531dda66d Content-Type: text/plain; charset=UTF-8 On Sat, Apr 30, 2016 at 2:10 AM, Asmus Freytag (c) wrote: > > PS: we do need to pick up Wil's tweak on the schema, which is not merged > yet This is a minor refactor of the "class-or-set-operator-nested" production which I made to get around an error when using libxml2 to validate an LGR document [1]. I have now created a pull request about this. The class-or-set-operator-nested production can be a class-invocation, class-declaration, or set-operator. However, presumably due to class-invocation and class-declaration both having "class" element names, it seems that libxml2 is having trouble validating some documents. This proposed change defines a class-invocation-or-declaration production that encapsulates the alternate sets of attributes allowed in class-invocation and class-declaration. The diff can be seen here: https://github.com/kjd/lgr-specification/pull/4/files [1] https://www.icann.org/en/system/files/files/proposal-khmer-lgr-15apr16-en.xml failed with error message "Element class failed to validate attributes" on line 190 when it encountered a .wil --94eb2c04427a453a040531dda66d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sat, Apr 30, 2016 at 2:10 AM, Asmus Freytag (c) <as= musf@ix.netcom.com> wrote:

PS: we do need to pick up Wil's tweak on the schema, which is not merge= d yet

This is a minor refactor of the "= ;class-or-set-operator-nested" production which I made to get around a= n error when using libxml2 to validate an LGR document [1].

<= /div>
I have now created a pull request about this.

The class-or-set-operator-nested production can be a class-invoc= ation, class-declaration, or set-operator. However, presumably due to class= -invocation and class-declaration both having "class" element nam= es, it seems that libxml2 is having trouble validating some documents.

This proposed change defines a class-invocation-or-dec= laration production that encapsulates the alternate sets of attributes allo= wed in class-invocation and class-declaration.

Th= e diff can be seen here:=C2=A0https://github.com/kjd/lgr-specification/pull/4/files<= /a>

[1]=C2=A0https://www.icann.org/en/sys= tem/files/files/proposal-khmer-lgr-15apr16-en.xml failed with error mes= sage "Element class failed to validate attributes" on line 190 wh= en it encountered a=C2=A0<class from-tag=3D"base-only" />

.wil
--94eb2c04427a453a040531dda66d-- From nobody Mon May 2 09:05:16 2016 Return-Path: X-Original-To: lager@ietfa.amsl.com Delivered-To: lager@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE3012D098 for ; Mon, 2 May 2016 09:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.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 ZhHk3pVZ-vKb for ; Mon, 2 May 2016 09:05:13 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 1897C12B04C for ; Mon, 2 May 2016 09:05:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=OywXVtSIjjly+Roob5MbtcrQsR7YaNXyd0FIFMnOKowAq8RFIQQ2lKLYid2bE2hY; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [71.212.2.16] (helo=[192.168.0.4]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1axGLI-0000KC-2b for lager@ietf.org; Mon, 02 May 2016 12:05:04 -0400 To: lager@ietf.org References: From: "Asmus Freytag (c)" Message-ID: Date: Mon, 2 May 2016 09:05:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7C295838A322B9C3EFF3EF63" X-ELNK-Trace: 464f085de979d7246f36dc87813833b2b484d7840976cb7e7688bcb7a869a32b54e652fa5307ac94350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.212.2.16 Archived-At: Subject: Re: [Lager] Proposed Schema Change - class-or-set-operator-nested X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 16:05:15 -0000 This is a multi-part message in MIME format. --------------7C295838A322B9C3EFF3EF63 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 5/2/2016 8:28 AM, Wil Tan wrote: > > On Sat, Apr 30, 2016 at 2:10 AM, Asmus Freytag (c) > > wrote: > > > PS: we do need to pick up Wil's tweak on the schema, which is not > merged yet > > > This is a minor refactor of the "class-or-set-operator-nested" > production which I made to get around an error when using libxml2 to > validate an LGR document [1]. > > I have now created a pull request about this. I have reviewed and merged this. A./ > > The class-or-set-operator-nested production can be a class-invocation, > class-declaration, or set-operator. However, presumably due to > class-invocation and class-declaration both having "class" element > names, it seems that libxml2 is having trouble validating some documents. > > This proposed change defines a class-invocation-or-declaration > production that encapsulates the alternate sets of attributes allowed > in class-invocation and class-declaration. > > The diff can be seen here: > https://github.com/kjd/lgr-specification/pull/4/files > > [1] > https://www.icann.org/en/system/files/files/proposal-khmer-lgr-15apr16-en.xml > failed with error message "Element class failed to validate > attributes" on line 190 when it encountered a from-tag="base-only" /> > > .wil > > > _______________________________________________ > Lager mailing list > Lager@ietf.org > https://www.ietf.org/mailman/listinfo/lager --------------7C295838A322B9C3EFF3EF63 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/2/2016 8:28 AM, Wil Tan wrote:

On Sat, Apr 30, 2016 at 2:10 AM, Asmus Freytag (c) <asmusf@ix.netcom.com> wrote:

PS: we do need to pick up Wil's tweak on the schema, which is not merged yet

This is a minor refactor of the "class-or-set-operator-nested" production which I made to get around an error when using libxml2 to validate an LGR document [1].

I have now created a pull request about this.

I have reviewed and merged this.

A./

The class-or-set-operator-nested production can be a class-invocation, class-declaration, or set-operator. However, presumably due to class-invocation and class-declaration both having "class" element names, it seems that libxml2 is having trouble validating some documents.

This proposed change defines a class-invocation-or-declaration production that encapsulates the alternate sets of attributes allowed in class-invocation and class-declaration.

The diff can be seen here: https://github.com/kjd/lgr-specification/pull/4/files

[1] https://www.icann.org/en/system/files/files/proposal-khmer-lgr-15apr16-en.xml failed with error message "Element class failed to validate attributes" on line 190 when it encountered a <class from-tag="base-only" />

.wil


_______________________________________________
Lager mailing list
Lager@ietf.org
https://www.ietf.org/mailman/listinfo/lager


--------------7C295838A322B9C3EFF3EF63-- From nobody Sat May 14 09:11:35 2016 Return-Path: X-Original-To: lager@ietf.org Delivered-To: lager@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEED12D143; Sat, 14 May 2016 09:11:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160514161133.2474.10630.idtracker@ietfa.amsl.com> Date: Sat, 14 May 2016 09:11:33 -0700 Archived-At: Cc: lager@ietf.org Subject: [Lager] I-D Action: draft-ietf-lager-specification-12.txt X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.17 List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2016 16:11:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Label Generation Rules of the IETF. Title : Representing Label Generation Rulesets using XML Authors : Kim Davies Asmus Freytag Filename : draft-ietf-lager-specification-12.txt Pages : 78 Date : 2016-05-14 Abstract: This document describes a method of representing rules for validating identifier labels and alternate representations of those labels using Extensible Markup Language (XML). These policies, known as "Label Generation Rulesets" (LGRs), are used for the implementation of Internationalized Domain Names (IDNs), for example. The rulesets are used to implement and share that aspect of policy defining which labels and Unicode code points are permitted for registrations, which alternative code points are considered variants, and what actions may be performed on labels containing those variants. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lager-specification/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lager-specification-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lager-specification-12 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/ From nobody Mon May 16 05:31:31 2016 Return-Path: X-Original-To: lager@ietf.org Delivered-To: lager@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8606212D181; Mon, 16 May 2016 05:31:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160516123129.16749.31677.idtracker@ietfa.amsl.com> Date: Mon, 16 May 2016 05:31:29 -0700 Archived-At: Cc: audric.schiltknecht@viagenie.ca, draft-ietf-lager-specification@ietf.org, lager-chairs@ietf.org, lager@ietf.org Subject: [Lager] Stephen Farrell's Discuss on draft-ietf-lager-specification-12: (with DISCUSS) X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.17 List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 12:31:29 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-lager-specification-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lager-specification/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the changes in -12. I think we're down to one remaining item to discuss. I'll follow up on the earlier email where you answered directly to this point. (4) section 12: I don't think this is at all sufficient. Missing aspects include: Imprecise LGRs could result in registration of identifiers that are unexpected in many other protocols, leading to new vulnerabilities; LGRs could be deliberately manipulated so as to create such imprecision, and if I could feed one such to a registry (e.g. via some nice friendly looking git repo) then I could exploit the vuln later for fun and profit - that seems to call for some interoperable form of data integrity and origin authentication (is the lager WG doing that?) and lastly (for now), the XML language defined here is very flexible as noted earlier - I would expect there to be many implementation bugs in new code that attempts to parse this language. So I think the security considerations needs to be re-done really. From nobody Mon May 16 05:48:20 2016 Return-Path: X-Original-To: lager@ietfa.amsl.com Delivered-To: lager@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B67412D61A; Mon, 16 May 2016 05:48:18 -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 vO950973REcV; Mon, 16 May 2016 05:48:16 -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 8F54B12D615; Mon, 16 May 2016 05:48:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D56EBBE25; Mon, 16 May 2016 13:48:07 +0100 (IST) 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 HmWB8XT-F1qK; Mon, 16 May 2016 13:48:07 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 34AADBDCF; Mon, 16 May 2016 13:48:07 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463402887; bh=DBlbvoIjH6YJPCDQSqPUNc5HNOUu7djQdMoBCNAAnAw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=iZxL6o0eudm8VH6ASBJrODM6r+a2gxJlqMduLh6x48g0vUIOOwsP6yeZLrXLaqeQq vrj77E8O/i8Lti7ejVLw9jo4IIDnrHU+zG/gUebCwYLFATqXZYJD3fYUQxPPYmwlY4 J18zAWaOWdQMuJSQE1e8g61U8UDzO4pFll9bY5W0= To: "Asmus Freytag (c)" , Alexey Melnikov References: <20160421102401.19578.54300.idtracker@ietfa.amsl.com> <1461412191.851961.587365345.53A5CC4C@webmail.messagingengine.com> <571B634F.9070600@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5739C186.9040200@cs.tcd.ie> Date: Mon, 16 May 2016 13:48:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070704040407040701040804" Archived-At: Cc: draft-ietf-lager-specification@ietf.org, audric.schiltknecht@viagenie.ca, The IESG , lager@ietf.org Subject: Re: [Lager] Stephen Farrell's Discuss on draft-ietf-lager-specification-11: (with DISCUSS and COMMENT) X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 12:48:18 -0000 This is a cryptographically signed message in MIME format. --------------ms070704040407040701040804 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, This is the promised (and delayed, sorry;-) follow up... On 28/04/16 20:58, Asmus Freytag (c) wrote: >=20 >> (4) section 12: I don't think this is at all sufficient. >> Missing aspects include: Imprecise LGRs could result in >> registration of identifiers that are unexpected in many other >> protocols, leading to new vulnerabilities; LGRs could be >> deliberately manipulated so as to create such imprecision, and >> if I could feed one such to a registry (e.g. via some nice >> friendly looking git repo) then I could exploit the vuln later >> for fun and profit - that seems to call for some >> interoperable form of data integrity and origin >> authentication (is the lager WG doing that?) and lastly (for >> now), the XML language defined here is very flexible as noted >> earlier - I would expect there to be many implementation bugs >> in new code that attempts to parse this language. So I think >> the security considerations needs to be re-done really. >=20 > My reading of this comment is that it presupposes a particular use-case= =2E Isn't that use-case the reason why this language was developed? The charter says it is "primarily to support" that anyway, so I don't accept that this is just one amongst many use cases, if that's what you mean, but do correct me if I'm getting what you meant wrong. >=20 > The use case we've identified so far is that these will substitute for > IDN tables. >=20 > IDN tables are controlled by registries and define registry policy. As > such it would be up to the registry to have a policy that is well-defin= ed, > and the registries would be in charge of developing or adopting an LGR > that matches their policies. >=20 > The LGR data format (and that's what it is) doesn't change anything in = who > can set and enforce registry policy. Correct. But doesn't this change who is likely to develop the (fragments of) documents that describe those policies and in doing so it could (IMO fairly easily) create unexpected side effects for other protocols. >=20 > I also do not understand what an "imprecise" LGR would be. In contrast > to what they replace (IDN tables), LGRs are way more definite. By "imprecise" I meant an LGR that allows some identifiers to end up in protocols where those identifiers cause problems. If there's a good argument that that can never happen then that'd be a fine counter-argument, but ISTM that the LGR language would allow that. Yes, a registry who did that could be called out for it, but fixing such things afterwards can be hard and some of the subtleties might take a while to get noticed. >=20 > Issues of deployment of LGRs in IDN registration seem out of scope for > this document. I agree the specifics of any given LGR or registry policy aren't in scope but the fact that an "imprecise" (in the sense above) LGR could cause wider trouble in perhaps unexpected ways, is definitely worth noting here I think, unless that's just not really possible. (See above.) As a near-aside, you didn't tell me if the WG are considering issues such as origin authentication or provenance of LGR fragments in some other document. I'm not asking that this one be held up pending development of that, but I'd be interested in knowing. And if the WG aren't ever going to do that, which may be reasonable if nobody would deploy it, then that also argues for recognising the potential threats here. (E.g. that taking a snippet of an LGR from stackexchange might be problematic.) Lastly, I'm sure you're correct that LGRs are probably more likely to be precise, compared to previous technologies such as IDN tables, but that does not mean that there's no need to recognise potential threats arising from LGRs even if those threats existed and were more likely to occur with tables. Cheers, S. --------------ms070704040407040701040804 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTYx MjQ4MDZaMC8GCSqGSIb3DQEJBDEiBCCUJeTMRhUW9F9S7OOr/LvwyygiijVwJnstQ7Pp53Qy XzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBiv9UssN0mGxJPtPHBt2Z9RF5fIKK2bDOQFxdvLIJKzdK/e/y5pZ/S TvIc4v1KrWDoTsYWhx8UH32rlVZWLmvdgCpnx4afuxeILD4XwPq/fPVDtDg3o8XL0yCqVQQf b8G/00pYX//PADthSdT80MQtiVIOuWJk2BNgUUVHsvxCsirNdoYtFjT4gvhkGg07SO8u+oxg aakD4GRZM1MN08F1JaZcp/a9e7F8CyR8cD4oiHbKqa3Oy3pHZuhD1LBiYQGXvSdtlaiNBRY4 boWeQkwi4peUHqzk9wofNJm38f5uWhcIHDCSt9Ud10zmBcqCVYnRPvlzA+P9f8mQhUGWwvP/ AAAAAAAA --------------ms070704040407040701040804-- From nobody Mon May 16 10:21:42 2016 Return-Path: X-Original-To: lager@ietfa.amsl.com Delivered-To: lager@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433E612D807; Mon, 16 May 2016 10:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.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 I4nejwCwLGGf; Mon, 16 May 2016 10:21:36 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 37B3512D7F8; Mon, 16 May 2016 10:21:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=PisVDlnv7bU8pJSx1tAuc4eXbHKz8Y03zeyw2odOTcpT51ks9yZO88kYPAH/zqB3; h=Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [71.35.99.91] (helo=[192.168.0.4]) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1b2MCc-0007t5-0T; Mon, 16 May 2016 13:21:10 -0400 To: Stephen Farrell , Alexey Melnikov References: <20160421102401.19578.54300.idtracker@ietfa.amsl.com> <1461412191.851961.587365345.53A5CC4C@webmail.messagingengine.com> <571B634F.9070600@cs.tcd.ie> <5739C186.9040200@cs.tcd.ie> From: "Asmus Freytag (c)" Message-ID: <0a7a8f7e-6e9f-6341-dcc7-55c5b5b6bd65@ix.netcom.com> Date: Mon, 16 May 2016 10:21:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <5739C186.9040200@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 464f085de979d7246f36dc87813833b2b484d7840976cb7e568c8b3c21060b5e420db38f5576d57d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.35.99.91 Archived-At: Cc: draft-ietf-lager-specification@ietf.org, audric.schiltknecht@viagenie.ca, The IESG , lager@ietf.org Subject: Re: [Lager] Stephen Farrell's Discuss on draft-ietf-lager-specification-11: (with DISCUSS and COMMENT) X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 17:21:38 -0000 On 5/16/2016 5:48 AM, Stephen Farrell wrote: > Hiya, > > This is the promised (and delayed, sorry;-) follow up... > > On 28/04/16 20:58, Asmus Freytag (c) wrote: >>> (4) section 12: I don't think this is at all sufficient. >>> Missing aspects include: Imprecise LGRs could result in >>> registration of identifiers that are unexpected in many other >>> protocols, leading to new vulnerabilities; LGRs could be >>> deliberately manipulated so as to create such imprecision, and >>> if I could feed one such to a registry (e.g. via some nice >>> friendly looking git repo) then I could exploit the vuln later >>> for fun and profit - that seems to call for some >>> interoperable form of data integrity and origin >>> authentication (is the lager WG doing that?) and lastly (for >>> now), the XML language defined here is very flexible as noted >>> earlier - I would expect there to be many implementation bugs >>> in new code that attempts to parse this language. So I think >>> the security considerations needs to be re-done really. >> My reading of this comment is that it presupposes a particular use-case. > Isn't that use-case the reason why this language was developed? > The charter says it is "primarily to support" that anyway, so > I don't accept that this is just one amongst many use cases, > if that's what you mean, but do correct me if I'm getting what > you meant wrong. The use case I was referring to is your scenario of registries "grabbing" random LGR definitions from open source repositories and making them policy without substantial review. I think the more fundamental issue to cover is that the use of the LGR format - by itself - offers no guarantee of suitability of the LGR content (more on that below). That is a fair point. The security issues ultimately stem from the use of unsuitable policies, not from how they are expressed. > >> The use case we've identified so far is that these will substitute for >> IDN tables. >> >> IDN tables are controlled by registries and define registry policy. As >> such it would be up to the registry to have a policy that is well-defined, >> and the registries would be in charge of developing or adopting an LGR >> that matches their policies. >> >> The LGR data format (and that's what it is) doesn't change anything in who >> can set and enforce registry policy. > Correct. But doesn't this change who is likely to develop the > (fragments of) documents that describe those policies and > in doing so it could (IMO fairly easily) create unexpected > side effects for other protocols. > >> I also do not understand what an "imprecise" LGR would be. In contrast >> to what they replace (IDN tables), LGRs are way more definite. > By "imprecise" I meant an LGR that allows some identifiers > to end up in protocols where those identifiers cause problems. Thanks for the clarification. That puts a different spin on things. An "imprecise" statement of label generation rules usually means you can't tell reliably which labels are being generated. However, let's take your definition of "doesn't automatically prevent unsuitable labels". I fully agree. Nothing in the LGR format prevents unsuitable labels. It's just a format. Deciding what labels are suitable or not is the role of the LGR content. The draft makes limited, if any, recommendations for the contents of label generation rules. > If there's a good argument that that can never happen then > that'd be a fine counter-argument, but ISTM that the LGR > language would allow that. Yes, a registry who did that could > be called out for it, but fixing such things afterwards can > be hard and some of the subtleties might take a while to get > noticed. Perhaps it would be useful to spell out that the draft (by specifying a format) does not by itself change what labels are generated. It enables a number of techniques that might increase security: the format guarantees that each label will be definitely associated with a disposition, and many properties of a set of label generation rules can be mechanically verified. In the root zone LGR process we found that having a consistent and unambiguous format greatly helps in understanding and reviewing LGR proposals, arguably a security benefit. >> Issues of deployment of LGRs in IDN registration seem out of scope for >> this document. > I agree the specifics of any given LGR or registry policy > aren't in scope but the fact that an "imprecise" (in the sense > above) LGR could cause wider trouble in perhaps unexpected ways, > is definitely worth noting here I think, unless that's just > not really possible. (See above.) > > As a near-aside, you didn't tell me if the WG are considering > issues such as origin authentication or provenance of LGR > fragments in some other document. I'm not asking that this > one be held up pending development of that, but I'd be > interested in knowing. And if the WG aren't ever going to do > that, which may be reasonable if nobody would deploy it, > then that also argues for recognising the potential threats > here. (E.g. that taking a snippet of an LGR from stackexchange > might be problematic.) I think it's fair to note that the use of the format places very little constraints on what can be expressed as LGR - and, in particular, that the use of the format in and of itself does not guarantee that the results are suitable. However, I would argue that this is not the place to discuss all the unsuitable ways labels can be defined - because there are other, existing formats for label generation rules (aka IDN tables) which also allow the definition of policies that range from good to bad. > > Lastly, I'm sure you're correct that LGRs are probably more > likely to be precise, compared to previous technologies such > as IDN tables, but that does not mean that there's no need to > recognise potential threats arising from LGRs even if those > threats existed and were more likely to occur with tables. For comparison, here is the language used in RFC 3743 (which defines one of the IDN table formats with which this draft is compatible): As discussed in the Introduction, substantially-unrestricted use of international (non-ASCII) characters in domain name labels may cause user confusion and invite various types of attacks. In particular, in the case of CJK languages, an attacker has an opportunity to divert or confuse users as a result of different characters (or, more specifically, assigned code points) with identical or similar semantics. These Guidelines provide a partial remedy for those risks by supplying a framework for prohibiting inappropriate characters from being registered at all and for permitting "variant" characters to be grouped together and reserved, so that they can only be registered in the DNS by the same owner. However, the system it suggests is no better or worse than the per-zone and per-language tables whose format and use this document specifies. Specific tables, and any additional local processing, will reflect per-zone decisions about the balance between risk and flexibility of registrations. And, of course, errors in construction of those tables may significantly reduce the quality of protection provided. We could certainly write equivalent language - but note, that language also does not go into details on what kind of bad tables one can write, only that it is possible. (And unlike RFC 3743 the draft does not contain "guidelines"). Will post suggested language when we have it, A./ > > Cheers, > S. > From nobody Tue May 17 09:16:05 2016 Return-Path: X-Original-To: lager@ietfa.amsl.com Delivered-To: lager@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B71212DA70; Tue, 17 May 2016 09:16:03 -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 U_7v_WqS6hpq; Tue, 17 May 2016 09:16:00 -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 269F412D6EC; Tue, 17 May 2016 09:16:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B75D4BE2D; Tue, 17 May 2016 17:15:57 +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 WZA0Sg3JS5JT; Tue, 17 May 2016 17:15:55 +0100 (IST) Received: from [10.87.48.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 62A6CBE35; Tue, 17 May 2016 17:15:33 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463501733; bh=usIwgPdqzX9gTAnaVYMZ52dLnTLAIQVPeJiPBwZ7yQA=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=gsdvCrjmykokCunzrIwIUcXZ29UAaYDWJVq1giuLyTR3cuztnhcslLCd0XBoKWWrD klnJXYWOI5+e85rwSpts5xKM0pjLPrDCuGFR1AhC4norjsY/7OVfh9kIKT0TfSh+5n hx+Jh8lyXxoNduYlg/mn3KlJHfIE+nDfabIritXI= To: "Asmus Freytag (c)" , Alexey Melnikov References: <20160421102401.19578.54300.idtracker@ietfa.amsl.com> <1461412191.851961.587365345.53A5CC4C@webmail.messagingengine.com> <571B634F.9070600@cs.tcd.ie> <5739C186.9040200@cs.tcd.ie> <0a7a8f7e-6e9f-6341-dcc7-55c5b5b6bd65@ix.netcom.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <573B43A5.3020008@cs.tcd.ie> Date: Tue, 17 May 2016 17:15:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <0a7a8f7e-6e9f-6341-dcc7-55c5b5b6bd65@ix.netcom.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050309020608040805090802" Archived-At: Cc: audric.schiltknecht@viagenie.ca, draft-ietf-lager-specification@ietf.org, The IESG , lager@ietf.org Subject: Re: [Lager] Stephen Farrell's Discuss on draft-ietf-lager-specification-11: (with DISCUSS and COMMENT) X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 16:16:03 -0000 This is a cryptographically signed message in MIME format. --------------ms050309020608040805090802 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Yes, an addition such as you suggest below should be good enough to sort the discuss. Thanks, S. PS: You still didn't tell me if the WG plans to think about origin auth and provenance or not. I guess that means there are no such plans. On 16/05/16 18:21, Asmus Freytag (c) wrote: > On 5/16/2016 5:48 AM, Stephen Farrell wrote: >> Hiya, >> >> This is the promised (and delayed, sorry;-) follow up... >> >> On 28/04/16 20:58, Asmus Freytag (c) wrote: >>>> (4) section 12: I don't think this is at all sufficient. >>>> Missing aspects include: Imprecise LGRs could result in >>>> registration of identifiers that are unexpected in many other >>>> protocols, leading to new vulnerabilities; LGRs could be >>>> deliberately manipulated so as to create such imprecision, and >>>> if I could feed one such to a registry (e.g. via some nice >>>> friendly looking git repo) then I could exploit the vuln later >>>> for fun and profit - that seems to call for some >>>> interoperable form of data integrity and origin >>>> authentication (is the lager WG doing that?) and lastly (for >>>> now), the XML language defined here is very flexible as noted >>>> earlier - I would expect there to be many implementation bugs >>>> in new code that attempts to parse this language. So I think >>>> the security considerations needs to be re-done really. >>> My reading of this comment is that it presupposes a particular use-ca= se. >> Isn't that use-case the reason why this language was developed? >> The charter says it is "primarily to support" that anyway, so >> I don't accept that this is just one amongst many use cases, >> if that's what you mean, but do correct me if I'm getting what >> you meant wrong. >=20 > The use case I was referring to is your scenario of registries > "grabbing" random LGR definitions from open source repositories and > making them policy without substantial review. >=20 > I think the more fundamental issue to cover is that the use of the LGR > format - by itself - offers no guarantee of suitability of the LGR > content (more on that below). That is a fair point. The security issues= > ultimately stem from the use of unsuitable policies, not from how they > are expressed. >> >>> The use case we've identified so far is that these will substitute fo= r >>> IDN tables. >>> >>> IDN tables are controlled by registries and define registry policy. A= s >>> such it would be up to the registry to have a policy that is >>> well-defined, >>> and the registries would be in charge of developing or adopting an LG= R >>> that matches their policies. >>> >>> The LGR data format (and that's what it is) doesn't change anything >>> in who >>> can set and enforce registry policy. >> Correct. But doesn't this change who is likely to develop the >> (fragments of) documents that describe those policies and >> in doing so it could (IMO fairly easily) create unexpected >> side effects for other protocols. >> >>> I also do not understand what an "imprecise" LGR would be. In contras= t >>> to what they replace (IDN tables), LGRs are way more definite. >> By "imprecise" I meant an LGR that allows some identifiers >> to end up in protocols where those identifiers cause problems. >=20 > Thanks for the clarification. That puts a different spin on things. An > "imprecise" statement of label generation rules usually means you can't= > tell reliably which labels are being generated. However, let's take you= r > definition of "doesn't automatically prevent unsuitable labels". >=20 > I fully agree. Nothing in the LGR format prevents unsuitable labels. > It's just a format. Deciding what labels are suitable or not is the rol= e > of the LGR content. The draft makes limited, if any, recommendations fo= r > the contents of label generation rules. >=20 >> If there's a good argument that that can never happen then >> that'd be a fine counter-argument, but ISTM that the LGR >> language would allow that. Yes, a registry who did that could >> be called out for it, but fixing such things afterwards can >> be hard and some of the subtleties might take a while to get >> noticed. >=20 > Perhaps it would be useful to spell out that the draft (by specifying a= > format) does not by itself change what labels are generated. >=20 > It enables a number of techniques that might increase security: the > format guarantees that each label will be definitely associated with a > disposition, and many properties of a set of label generation rules can= > be mechanically verified. >=20 > In the root zone LGR process we found that having a consistent and > unambiguous format greatly helps in understanding and reviewing LGR > proposals, arguably a security benefit. >>> Issues of deployment of LGRs in IDN registration seem out of scope fo= r >>> this document. >> I agree the specifics of any given LGR or registry policy >> aren't in scope but the fact that an "imprecise" (in the sense >> above) LGR could cause wider trouble in perhaps unexpected ways, >> is definitely worth noting here I think, unless that's just >> not really possible. (See above.) >> >> As a near-aside, you didn't tell me if the WG are considering >> issues such as origin authentication or provenance of LGR >> fragments in some other document. I'm not asking that this >> one be held up pending development of that, but I'd be >> interested in knowing. And if the WG aren't ever going to do >> that, which may be reasonable if nobody would deploy it, >> then that also argues for recognising the potential threats >> here. (E.g. that taking a snippet of an LGR from stackexchange >> might be problematic.) >=20 > I think it's fair to note that the use of the format places very little= > constraints on what can be expressed as LGR - and, in particular, that > the use of the format in and of itself does not guarantee that the > results are suitable. >=20 > However, I would argue that this is not the place to discuss all the > unsuitable ways labels can be defined - because there are other, > existing formats for label generation rules (aka IDN tables) which also= > allow the definition of policies that range from good to bad. >> >> Lastly, I'm sure you're correct that LGRs are probably more >> likely to be precise, compared to previous technologies such >> as IDN tables, but that does not mean that there's no need to >> recognise potential threats arising from LGRs even if those >> threats existed and were more likely to occur with tables. >=20 > For comparison, here is the language used in RFC 3743 (which defines on= e > of the IDN table formats with which this draft is compatible): >=20 > As discussed in the Introduction, substantially-unrestricted use of > international (non-ASCII) characters in domain name labels may cause= > user confusion and invite various types of attacks. In particular, > in the case of CJK languages, an attacker has an opportunity to > divert or confuse users as a result of different characters (or, mor= e > specifically, assigned code points) with identical or similar > semantics. These Guidelines provide a partial remedy for those risk= s > by supplying a framework for prohibiting inappropriate characters > from being registered at all and for permitting "variant" characters= > to be grouped together and reserved, so that they can only be > registered in the DNS by the same owner. However, the system it > suggests is no better or worse than the per-zone and per-language > tables whose format and use this document specifies. Specific > tables, and any additional local processing, will reflect per-zone > decisions about the balance between risk and flexibility of > registrations. And, of course, errors in construction of those > tables may significantly reduce the quality of protection provided. >=20 > We could certainly write equivalent language - but note, that language > also does not go into details on what kind of bad tables one can write,= > only that it is possible. (And unlike RFC 3743 the draft does not > contain "guidelines"). >=20 > Will post suggested language when we have it, >=20 > A./ >> >> Cheers, >> S. >> >=20 --------------ms050309020608040805090802 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTcx NjE1MzNaMC8GCSqGSIb3DQEJBDEiBCCG1CigIdZRcRn4YTTwgDEb/EWiIGnSvnf9CaC2CLCK czBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAaHwSJ52HSkPZrAPsdFAj/LegfYEJDN52PvSZuvJ2Pus/Js/7sUy4A XtVm2mFbprEUq/iJi36BnSwc99So3NHbzbtm795qCe3AseOorX/BZ5N7HyCB6jDaGaGgQ84G 7jJ5mgm3iFEpUXUHwNAASFMNTcu7bSZ9XlV1UUBTW9OkfPvs8etKX6FClxrmiId0pMSTaf9I UznafA0XS0pcmxwAoMlGK1JUn7RhdXoF26F7GezktLAwmirDHV1G8kT2p/ZJnbScmzFBY7SB KvL8y84cW30NJ86u6Wq2cE55q1eI/JrEfo/gkiEb2N74BYhOQ46nO45xSHmFc29kVpLVp89s AAAAAAAA --------------ms050309020608040805090802-- From nobody Tue May 17 09:57:32 2016 Return-Path: X-Original-To: lager@ietfa.amsl.com Delivered-To: lager@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B90F12DBA6; Tue, 17 May 2016 09:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=asmusf@ix.netcom.com header.d=ix.netcom.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 0aZ0cI2bXlAM; Tue, 17 May 2016 09:57:29 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 50A2A12D518; Tue, 17 May 2016 09:57:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=axNsuWNDNKvpd5ujPYyhc8gPhc4GPnPXW8P/B3uwNNdI5H96EipTqgnAFqynMp40; h=Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [71.35.99.91] (helo=[192.168.0.4]) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1b2iIl-0005Wr-Gw; Tue, 17 May 2016 12:56:59 -0400 To: Stephen Farrell , Alexey Melnikov References: <20160421102401.19578.54300.idtracker@ietfa.amsl.com> <1461412191.851961.587365345.53A5CC4C@webmail.messagingengine.com> <571B634F.9070600@cs.tcd.ie> <5739C186.9040200@cs.tcd.ie> <0a7a8f7e-6e9f-6341-dcc7-55c5b5b6bd65@ix.netcom.com> <573B43A5.3020008@cs.tcd.ie> From: "Asmus Freytag (c)" Message-ID: <0df35b02-4971-d287-0924-661ca6fea676@ix.netcom.com> Date: Tue, 17 May 2016 09:57:00 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <573B43A5.3020008@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 464f085de979d7246f36dc87813833b2b484d7840976cb7e52a26f2260d50322c3949c6c2f29a568350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.35.99.91 Archived-At: Cc: audric.schiltknecht@viagenie.ca, draft-ietf-lager-specification@ietf.org, The IESG , lager@ietf.org Subject: Re: [Lager] Stephen Farrell's Discuss on draft-ietf-lager-specification-11: (with DISCUSS and COMMENT) X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 16:57:31 -0000 On 5/17/2016 9:15 AM, Stephen Farrell wrote: > Hiya, > > Yes, an addition such as you suggest below should be > good enough to sort the discuss. > > Thanks, > S. > > PS: You still didn't tell me if the WG plans to think > about origin auth and provenance or not. I guess that > means there are no such plans. > Sorry, meant to, but hit send. You are correct, no such plans that I am aware of. A./ From nobody Mon May 23 12:43:41 2016 Return-Path: X-Original-To: lager@ietf.org Delivered-To: lager@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E5612D552; Mon, 23 May 2016 12:43:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160523194340.20983.59300.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2016 12:43:40 -0700 Archived-At: Cc: lager@ietf.org Subject: [Lager] I-D Action: draft-ietf-lager-specification-13.txt X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.17 List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 19:43:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Label Generation Rules of the IETF. Title : Representing Label Generation Rulesets using XML Authors : Kim Davies Asmus Freytag Filename : draft-ietf-lager-specification-13.txt Pages : 79 Date : 2016-05-23 Abstract: This document describes a method of representing rules for validating identifier labels and alternate representations of those labels using Extensible Markup Language (XML). These policies, known as "Label Generation Rulesets" (LGRs), are used for the implementation of Internationalized Domain Names (IDNs), for example. The rulesets are used to implement and share that aspect of policy defining which labels and Unicode code points are permitted for registrations, which alternative code points are considered variants, and what actions may be performed on labels containing those variants. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lager-specification/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lager-specification-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lager-specification-13 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/ From nobody Mon May 23 12:46:33 2016 Return-Path: X-Original-To: lager@ietf.org Delivered-To: lager@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 97CE412D535; Mon, 23 May 2016 12:46:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160523194631.20901.14978.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2016 12:46:31 -0700 Archived-At: Cc: audric.schiltknecht@viagenie.ca, draft-ietf-lager-specification@ietf.org, lager-chairs@ietf.org, lager@ietf.org Subject: [Lager] Stephen Farrell's No Objection on draft-ietf-lager-specification-13: (with COMMENT) X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.17 List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 19:46:31 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-lager-specification-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lager-specification/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the discussion! From nobody Wed May 25 11:37:55 2016 Return-Path: X-Original-To: lager@ietf.org Delivered-To: lager@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFA612D8D9; Wed, 25 May 2016 11:37:44 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160525183744.18313.96941.idtracker@ietfa.amsl.com> Date: Wed, 25 May 2016 11:37:44 -0700 Archived-At: Cc: draft-ietf-lager-specification@ietf.org, lager-chairs@ietf.org, lager@ietf.org, Audric Schiltknecht , The IESG , alexey.melnikov@isode.com, rfc-editor@rfc-editor.org Subject: [Lager] Protocol Action: 'Representing Label Generation Rulesets using XML' to Proposed Standard (draft-ietf-lager-specification-13.txt) X-BeenThere: lager@ietf.org X-Mailman-Version: 2.1.17 List-Id: Label Generation Rules List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 18:37:45 -0000 The IESG has approved the following document: - 'Representing Label Generation Rulesets using XML' (draft-ietf-lager-specification-13.txt) as Proposed Standard This document is the product of the Label Generation Rules Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lager-specification/ Technical Summary This document describes a method of representing rules for validating identifier labels and alternate representations of those labels using Extensible Markup Language (XML). These policies, known as "Label Generation Rulesets" (LGRs), are used for the implementation of Internationalized Domain Names (IDNs), for example. The rulesets are used to implement and share that aspect of policy defining which labels and Unicode code points are permitted for registrations, which alternative code points are considered variants, and what actions may be performed on labels containing those variants. Review and Consensus The document was presented and discussed during at least two IETF meetings. It has the support of the WG, and there are at least three independent implementations of LGR processor with good coverage of WLE processing; the format described is already used in expressing Root Zone LGR for various writing systems. Personnel The document shepherd is Audric Schiltknecht. The responsible Area Director is Alexey Melnikov.