From lisa.dusseault@gmail.com  Thu Dec 31 07:55:08 2009
Return-Path: <lisa.dusseault@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 961FA3A6A1A; Thu, 31 Dec 2009 07:55:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.507
X-Spam-Level: 
X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3t9039gi4ry; Thu, 31 Dec 2009 07:55:08 -0800 (PST)
Received: from mail-vw0-f193.google.com (mail-vw0-f193.google.com [209.85.212.193]) by core3.amsl.com (Postfix) with ESMTP id BFF7E3A68C2; Thu, 31 Dec 2009 07:55:07 -0800 (PST)
Received: by vws31 with SMTP id 31so4281828vws.29 for <multiple recipients>; Thu, 31 Dec 2009 07:54:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9ptoqeXQNvxnjQSc6hRewaBlOkQAY5+c6EmedZhlk8A=; b=l31bfLCEzosTaSufPias9n82PA0mg+aD7GOEX5HztQ/yz39FAWe6Wlo3iYOeX4lC5I +lG1UY+JDiGdIvEHvI4v5T92tr558+tVYyiJaoOfiElozHVGdGRnMVEx1PfF9nVSzKp5 ruYHZId311s/TRVQU0ec+yovple8KwhCPWDPQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=s0YSmgDzTmTyteGvH7LSlpdUZCwDDopXQ5w6NKqf33dmpTiZUN8jI6VtdOyOeaTKmU lZQPfyoS5TRiL8lEc1qQdB++4/5JUciA+26JVqyWo0GALH0uYFmq22QmSwi3c1gofFbA AK6iktXHXL8usLiiFYLn4jUaM0vfF9C5G6F+E=
MIME-Version: 1.0
Received: by 10.220.65.200 with SMTP id k8mr1407161vci.56.1262274884504; Thu,  31 Dec 2009 07:54:44 -0800 (PST)
In-Reply-To: <Pine.GSO.4.63.0912301730060.23658@sjc-cde-011.cisco.com>
References: <Pine.GSO.4.63.0912301730060.23658@sjc-cde-011.cisco.com>
Date: Thu, 31 Dec 2009 07:54:44 -0800
Message-ID: <ca722a9e0912310754q6d7656d8g261ad2dad050cfbe@mail.gmail.com>
From: Lisa Dusseault <lisa.dusseault@gmail.com>
To: Chris Lonvick <clonvick@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sat, 02 Jan 2010 19:21:49 -0800
Cc: victoriano@uma.es, r.mcduff@uq.edu.au, secdir-secretary@mit.edu, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] SECDIR review of draft-giralt-schac-ns
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Dec 2009 15:55:08 -0000

On Wed, Dec 30, 2009 at 8:33 PM, Chris Lonvick <clonvick@cisco.com> wrote:
> Hi,
...
> First off, can we get the status of the document straightened out? =A0The
> document says that it's STANDARDS TRACK but idtracker says that it's
> INFORMATIONAL.

I believe it should be Informational.  Victoriano, was this a glitch
in producing version 02 of the document?

Thanks,
Lisa

From abegen@cisco.com  Thu Dec 31 13:50:53 2009
Return-Path: <abegen@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 204FA3A6829; Thu, 31 Dec 2009 13:50:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.307
X-Spam-Level: 
X-Spam-Status: No, score=-8.307 tagged_above=-999 required=5 tests=[AWL=2.292,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KeAYbeGRcvW; Thu, 31 Dec 2009 13:50:52 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 579573A67B6; Thu, 31 Dec 2009 13:50:52 -0800 (PST)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEABqrPEurRN+J/2dsb2JhbACDaJY1pXqHAI0tgS2CLlYE
X-IronPort-AV: E=Sophos;i="4.47,483,1257120000"; d="scan'208";a="126922771"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 31 Dec 2009 21:50:31 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nBVLoVd4022320; Thu, 31 Dec 2009 21:50:31 GMT
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 31 Dec 2009 13:50:31 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Thu, 31 Dec 2009 13:50:33 -0800
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540AEEF9F6@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <1262286190.65839253@192.168.2.230>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: secdir review of draft-ietf-fecframe-dvb-al-fec
Thread-Index: AcqKS+ZAvjIymBIfTya5iawFIl1ZHgAFtwgA
References: <1262286190.65839253@192.168.2.230>
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: <scott@hyperthought.com>, <iesg@ietf.org>, <secdir@ietf.org>, <stockhammer@nomor.de>, <fecframe-chairs@tools.ietf.org>
X-OriginalArrivalTime: 31 Dec 2009 21:50:31.0886 (UTC) FILETIME=[4645DEE0:01CA8A63]
X-Mailman-Approved-At: Sat, 02 Jan 2010 19:21:49 -0800
Subject: Re: [secdir] secdir review of draft-ietf-fecframe-dvb-al-fec
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Dec 2009 21:50:53 -0000

SGkgU2NvdHQsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2NvdHRA
aHlwZXJ0aG91Z2h0LmNvbSBbbWFpbHRvOnNjb3R0QGh5cGVydGhvdWdodC5jb21dDQo+IFNlbnQ6
IFRodXJzZGF5LCBEZWNlbWJlciAzMSwgMjAwOSAyOjAzIFBNDQo+IFRvOiBpZXNnQGlldGYub3Jn
OyBzZWNkaXJAaWV0Zi5vcmc7IEFsaSBDLiBCZWdlbiAoYWJlZ2VuKTsgc3RvY2toYW1tZXJAbm9t
b3IuZGU7IGZlY2ZyYW1lLQ0KPiBjaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogc2Vj
ZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLWZlY2ZyYW1lLWR2Yi1hbC1mZWMNCj4gDQo+IEkgaGF2
ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9y
YXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8NCj4gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWlu
ZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4NCj4g
cHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMu
ICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMNCj4gc2hvdWxkIHRyZWF0IHRoZXNlIGNv
bW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpUaGFua3Mg
Zm9yIHRoZSByZXZpZXcuDQogDQo+IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGltcGxlbWVudGF0
aW9uIG9mIGEgZm9yd2FyZCBlcnJvciBjb3JyZWN0aW9uIHByb3RvY29sIG92ZXIgUlRQDQo+IHVz
aW5nIGFscmVhZHktZGVmaW5lZCBwcm90b2NvbCBlbGVtZW50cy4gVGhlIHByb3RvY29sIHdhcyBv
cmlnaW5hbGx5IGRlZmluZWQgYnkgYW4gRVRTSQ0KPiBncm91cC4NCj4gDQo+IFRoZSBzZWN1cml0
eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHNheXMsICJUaGlzIHNwZWNpZmljYXRpb24gYWRkcyBu
byBuZXcgc2VjdXJpdHkNCj4gY29uc2lkZXJhdGlvbnMgdG8gdGhlIERWQi1JUFRWIEFMLUZFQyBw
cm90b2NvbCIsIHdoaWNoIEkgdGFrZSB0byBtZWFuIHRoYXQgdGhlIGF1dGhvcnMgc2VlDQo+IG5v
IHdheSBpbiB3aGljaCB0aGUgcHJvcG9zZWQgYXBwcm9hY2ggY2hhbmdlcyB0aGUgc2VjdXJpdHkg
cHJvcGVydGllcyBvZiB0aGUgb3JpZ2luYWwgRVRTSQ0KPiBzcGVjaWZpY2F0aW9uLiBTaW5jZSB0
aGUgcHJvdG9jb2wgZG9lc24ndCBzZWVtIHRvIGltcGxlbWVudCBhbnkgc2VjdXJpdHkgZmVhdHVy
ZXMsIEkgZ3Vlc3MNCj4gdGhpcyBpcyBwcm9iYWJseSBjb3JyZWN0LiBTdGlsbCwgaXQgbWlnaHQg
YmUgYmV0dGVyIHRvIGFkZCBzb21lIGFkZGl0aW9uYWwgY29tbWVudGFyeSBzdWNoDQo+IGFzIHdo
YXQgaXMgZm91bmQgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gb2YgZHJh
ZnQtaWV0Zi1mZWNmcmFtZS0NCj4gaW50ZXJsZWF2ZWQtZmVjLXNjaGVtZS0wNy50eHQgKG9yLCBw
ZXJoYXBzIHBvaW50IHRvIHRoYXQgYW5kIHRoZSBmcmFtZXdvcmsgZG9jKS4NCg0KV2UgY2FuIGRv
IHRoaXMuIEknZCBwcm9iYWJseSBwcmVmZXIgdG8gZG8gdGhpcyBtaW5vciBhZGRpdGlvbiBhZnRl
ciBhbGwgSUVTRyBjb21tZW50cyBhcmUgcmVjZWl2ZWQuDQogDQo+IExhY2tpbmcgbXVjaCBuZWNl
c3NhcnkgYmFja2dyb3VuZCBpbiB0aGlzIGFyZWEsIEkgZG9uJ3QgZmVlbCBxdWFsaWZpZWQgdG8g
ZnVsbHkgZXZhbHVhdGUNCj4gdGhpcyBkb2N1bWVudC4gV2l0aCB0aGF0IGRlZmljaWVuY3kgbm90
ZWQsIHRoZSBvbmx5IHBvc3NpYmxlIHJlZCBmbGFnIEkgc2F3IGlzIHRoYXQgdGhlDQo+IEZFQyBw
cm90b2NvbCByZXF1aXJlcyB0aGF0IHRoZSBTU1JDIGZpZWxkcyBvZiB0aGUgRkVDIGZyYW1lcyBi
ZSBzZXQgdG8gMCwgd2hpbGUgU1JUUA0KPiByZXF1aXJlcyB1bmlxdWUgU1NSQyB2YWx1ZXMgZm9y
IHNlY3VyaXR5IHJlYXNvbnMuIFdpdGggbXkgdmVyeSBsaW1pdGVkIGJhY2tncm91bmQsIEkgY2Fu
J3QNCj4gYmUgc3VyZSBpZiB0aGVyZSBpcyBhbiBpbXBvcnRhbnQgc2VjdXJpdHkgaW50ZXJhY3Rp
b24gaGVyZSBvciBub3QsIGJ1dCBpdCBzZWVtcyB3b3J0aA0KPiBhc2tpbmcgYWJvdXQuDQoNCkFn
cmVlLCBob3dldmVyLCB0aGF0IGlzIG9uZSBvZiB0aGUgaXNzdWVzIEVUU0kvRFZCIHdhcyBub3Qg
YWJsZSB0byBjaGFuZ2UgZHVlIHRvIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBpbiB0aGUgZmll
bGQuIGRyYWZ0LWlldGYtZmVjZnJhbWUtaW50ZXJsZWF2ZWQtZmVjLXNjaGVtZSBkb2VzIG5vdCBo
YXZlIHRoaXMgYnVnLCBidXQgdGhlIGFsLWZlYyBkcmFmdCBuZWVkcyB0byBzYXkgd2hhdCB0aGUg
RVRTSSBzcGVjIGN1cnJlbnRseSByZXF1aXJlcy4NCg0KQ2hlZXJzIGFuZCBoYXBweSBuZXcgeWVh
ci4NCi1hY2JlZ2VuDQoNCiANCj4gLS1TY290dA0KPiANCg0K

From ekr@networkresonance.com  Tue Jan  5 08:55:38 2010
Return-Path: <ekr@networkresonance.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AD0228C15A; Tue,  5 Jan 2010 08:55:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.318
X-Spam-Level: *
X-Spam-Status: No, score=1.318 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888,  HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXcefa2hlKeu; Tue,  5 Jan 2010 08:55:37 -0800 (PST)
Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 6138128C144; Tue,  5 Jan 2010 08:55:36 -0800 (PST)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 9DE066CBAC8; Tue,  5 Jan 2010 08:57:42 -0800 (PST)
Date: Tue, 05 Jan 2010 08:57:41 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Julian Reschke <julian.reschke@greenbytes.de>
In-Reply-To: <4B40E063.7070605@greenbytes.de>
References: <20100102230208.8346F6CB202@kilo.networkresonance.com> <4B40E063.7070605@greenbytes.de>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20100105165742.9DE066CBAC8@kilo.networkresonance.com>
Cc: iesg@ietf.org, draft-brown-versioning-link-relations@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] Review of draft-brown-versioning-link-relations-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jan 2010 16:55:38 -0000

At Sun, 03 Jan 2010 19:22:27 +0100,
Julian Reschke wrote:
> 
> Eric Rescorla wrote:
> > This document describes a set of link relations which provide
> > information about other versions of a versioned resource.
> > 
> > In general this mechanism seems sound but I'm not sure that
> > the security considerations are entirely adequate. This 
> > mechanism lets you learn information about other versions
> > of a resource even if you potentially don't have permission
> > to view them directly. Consider a limiting case where each
> > version of the resource had a name that contained the
> > change set for that resource. E.g.,
> > 
> > http://example.com/versions/filename/_@line_50_+_FOO;@line_60_+_BAR/;
> > 
> > In this case, seeing other parts of the version tree leaks
> > information about those versions. I don't think that this
> > is a problem for the draft, but it might be useful to
> > mention that this feature has implications for name 
> > construction.
> 
> Yes, we can mention that.
> 
> But, isn't this a general problem with exposing meta data in link 
> relations? 

Yes, probably.


> As such, shouldn't it have been mentioned in RFC 4287, and 
> should it also be mentioned in draft-nottingham-http-link-header?

Probably... I just didn't read these. :) I only did this one as part
of secdir review. 

-Ekr


From mundy@tislabs.com  Tue Jan  5 23:15:33 2010
Return-Path: <mundy@tislabs.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 126C43A680C; Tue,  5 Jan 2010 23:15:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZ--edytJ45N; Tue,  5 Jan 2010 23:15:32 -0800 (PST)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 7CED63A659A; Tue,  5 Jan 2010 23:15:31 -0800 (PST)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o067FSIB014053; Wed, 6 Jan 2010 01:15:28 -0600
Received: from worf.ads.sparta.com (worf.sparta.com [157.185.61.21]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o067FSom026101; Wed, 6 Jan 2010 01:15:28 -0600
Received: from calvin.home.tislabs.com ([69.250.64.147]) by worf.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 Jan 2010 01:15:27 -0600
Received: from calvin.home.tislabs.com (localhost [127.0.0.1]) by calvin.home.tislabs.com (Postfix) with ESMTP id 21C5B17B380F; Wed,  6 Jan 2010 02:15:53 -0500 (EST)
To: iesg@ietf.org, secdir@ietf.org, jari.arkko@piuha.net, yoshihiro.ohba@toshiba.co.jp, alper.yegin@yegin.org
From: Russ Mundy <mundy@sparta.com>
Date: Wed, 06 Jan 2010 02:15:53 -0500
Sender: mundy@tislabs.com
Message-Id: <20100106071553.21C5B17B380F@calvin.home.tislabs.com>
X-OriginalArrivalTime: 06 Jan 2010 07:15:28.0420 (UTC) FILETIME=[063F3E40:01CA8EA0]
Cc: mundy@sparta.com
Subject: [secdir] Secdir review of draft-ohba-pana-pemk-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jan 2010 07:15:33 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

* There are some sections where additional information would make the
  document more clear and complete:

** Section 1. I suggest including Figure 1 from RFC5193 between the
   first and second paragraphs of this section to illustrate the
   relationship of the components being described.  (Although a
   reference to the figure might be sufficient, 5193 is Informational
   so including the diagram would avoid a potentially normative
   reference.)

** Section 2.4 defines the lifetime of the PEMK with respect to the
   MSK.  I believe this means the lifetime of the exact MSK from which
   the particular PEMK is derived.  If this is the intent, I suggest
   adding the following to the end of the current sentence: "from
   which it is derived."

** Since the PEMK does have a specified lifetime, it seems as though
   there should be some information provided about what occurs at the
   end of that lifetime.  If this information is in other related
   specifications then these should be referenced.  

** Similarly, since the PEMK is defined to be a pre-shared key,
   providing information (or reference(s)) to what protocols are
   required to put the PEMK in place would make the specification more
   clear (is the EAP security mechanism required to provide for
   this?).

* Some terminology does not seem consistent with other referenced
  specifications:

** Although the Master Session Key (MSK) provides the basis for the
   PEMK, there is no definition of MSK in this specification and the
   terminology sections of RFCs referenced in the introduction
   (RFC3748 and RFC5191) have different definitions for MSK in their
   terminology sections.

** Making Use of more terminology from RFC5191 would make it easier to
   relate this specification to related RFCs.  For instance, use of
   "PANA Session", "Session Lifetime" and "PANA Security Association
   (PANA SA)" in Sections 2.2, 2.3 & 2.4 might make the sections more
   clear.  It also appears that the Key Name of PEMK (section 2.1)
   should have some relationship to a "PANA Session" or "Session
   Identifier" but it's not clear if or what relationship is
   intended.  The specification should state the relationship (or
   absence of a relationship) or implementers will make different
   (probably incompatible) choices in their implementations.

** To make the scope more clear, I would suggest changing the first
   sentence of section 2.2 to read: "One PEMK is used between one PaC
   and one EP."

I would suggest adding a terminology section to this specification
that referenced the terminology sections of RFC3748 and RFC5191 since
they are both standards track documents.


Regards,

Russ Mundy



From Hannes.Tschofenig@gmx.net  Wed Jan  6 03:44:50 2010
Return-Path: <Hannes.Tschofenig@gmx.net>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CE2528B23E for <secdir@core3.amsl.com>; Wed,  6 Jan 2010 03:44:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jd48087thP7p for <secdir@core3.amsl.com>; Wed,  6 Jan 2010 03:44:49 -0800 (PST)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 93DA23A68C8 for <secdir@ietf.org>; Wed,  6 Jan 2010 03:44:48 -0800 (PST)
Received: (qmail invoked by alias); 06 Jan 2010 11:44:45 -0000
Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO 4FIL42860) [88.115.222.204] by mail.gmx.net (mp008) with SMTP; 06 Jan 2010 12:44:45 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/IpbFWMNHIFVvAmrypD8niX71y8gQtTve4clZrCK Bgcq3ytA1WScsn
From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
To: <secdir@ietf.org>
Date: Wed, 6 Jan 2010 13:48:37 +0200
Message-ID: <005e01ca8ec6$3019dab0$02ffa8c0@nsnintra.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcqOxi6lIVdjFXjoRN6XhquwvXhi9w==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.57
Cc: y.ikejiri@ntt.com, jeanlouis.leroux@orange-ftgroup.com, jpv@cisco.com
Subject: [secdir] Secdir review of draft-ietf-pce-monitoring-07.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jan 2010 11:44:50 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. =C2 These comments were written primarily for the benefit of the
security area directors. =C2 Document editors and WG chairs should treat
these comments just like any other last call comments.

What does the document do?=20

My understanding is that the document defines some payloads for =
obtaining
information about control plane elements (namely about Path =
Computational
Elements). The obtained information includes 'Liveness', 'Processing =
Time',
and 'Overload'. The document does not describe mechanisms for obtaining
information about the data plane elements, as far as I can tell.=20

Collecting information about control plane elements is not uncommon
(although other approaches are typically used, such as SNMP MIBs).=20

There is often a different philosophy when it comes to writing a
specification. Some people believe that it is sufficient to just define =
the
packet on the wire (and a minimum of message processing rules) and then
there are folks who are more interested in defining the behavior and
algorithms. Here the former approach was selected and there might be =
some
problems with doing that (see comments below).=20

(Minor note: A figure or an example would have really helped me to
understand this document.)

-- Technical Issues=20

The Monitoring-id-number is described as:=20

"
   Monitoring-id-number (32 bits): The monitoring-id-number value
   combined with the PCEP-ID of the PCC identifies the monitoring
   request context.  The monitoring-id-number MUST start at a non-zero
   value and MUST be incremented each time a new monitoring request is
   sent to a PCE.  Each increment SHOULD have a value of 1 and may cause
   a wrap back to zero.  If no reply to a monitoring request is received
   from the PCE, and the PCC wishes to resend its path computation
   monitoring request, the same monitoring-id-number MUST be used.
   Conversely, a different monitoring-id-number MUST be used for
   different requests sent to a PCE.  The path computation monitoring
   reply is unambiguously identified by the monitoring-id-number and the
   PCEP-ID of the replying PCE.  A PCEP implementation SHOULD checkpoint
   the Monitoring-id-number of pending monitoring requests in case of
   restart thus avoiding the re-use of a Monitoring-id-number of an in-
   process monitoring request.
"

I understand that a sender may want to match requests against responses =
even
if the responses alone should provide already sufficient information so =
that
the matching to the request becomes irrelevant.=20

But what is the reason to demand a specific way to increment the
Monitoring-id-number? The sender only needs to avoid sending a request =
with
the same monitor-id-# already used in an previously sent request where =
the
response is still pending. Why would someone want to re-send the request
with the same number again? Wouldn't this be largely irrelevant?=20

>From the PROTO writeup I can read that there are three independent
implementations.=20
When I read through the Section 4.1 about the MONITORING object and the
flags that are defined I have some doubts how they can interwork. Just =
to
give you an example. I (PCE element of domain A) send a request for
monitoring and, for example, set the flag "General". This flag is =
defined in
the document as:=20

"
   G (General) - 1 bit: when set, this indicates that the monitoring
   request is a general monitoring request.  When the requested
   performance metric is specific, the G bit MUST be cleared.  The G bit
   MUST always be ignored in a PCMonRep or PCRep message.
"

So, another PCE element in domain B is now receiving this request and is
supposed to include something in the reply message a little later. So, =
what
would this be? Where does an implementer find a precise description of =
what
has to be done to fullfill this request?=20

The same is true for the other flags as well. Another example: =
"Processing
Time" ... is set to indicate that the
   processing times is a metric of interest. Section 4.3 provides a bit =
more
details but stops more or less when it comes to the real meat with =
something
like " out of the scope of this document".=20
  =20
I am not sure how to get meaningful measurement results at different PCE
elements (potentially provided by different vendors). What conclusions =
could
I then draw from the information that comes back with the response =
message?
=20
The same is true for the OVERLOAD Object.=20

So, while the authors (and the group) may believe that they have indeed
developed a standard it will not lead to interoperability without a =
number
of other things happening. I would at least appreciate a discussion in =
the
document (maybe related to operational considerations) that the values =
are
only meaningful if the entities operating the PCEs have a way to agree =
on
the same mechanism to perform the value calculation. Typically, this =
will
not easily work in a multi-vendor fashion. So, I believe that the =
authors
might have had another document in mind in the future that actually =
provides
the algorithms. This would then raise the question of the usefulness of =
the
flags if the calculation of the values are done in many differents. =
Example.
I could imagine that the overload being calculated in, for example, 5
different ways. Vendor A supports only 2 and vendor B supports 4 =
different
algorithms but there is only one flag to indicate "overload".=20


-- Specification Writing Style

Below I list two examples where I had hoped for a stricter style:

"
4.1.  MONITORING Object

   The MONITORING object MUST be present within PCMonReq and PCMonRep
   messages ("out of band" monitoring requests) and MAY be carried
   within PCRep and PCReq messages ("in band" monitoring requests).
   There SHOULD NOT be more than one instance of the MONITORING object
   in a PCMonReq or PCMonRep message: if more than one instance of the
   MONITORING object is present, the recipient MUST process the first
   instance and MUST ignore other instances.
"

Why couldn't you say that there MUST only be one instance of the =
MONITORING=20
object in the message. Everything else is an error (and you already have =
an
error message for that).
Done.=20
  =20
"
  I (Incomplete) - 1 bit: If a PCE supports a received PCMonReq message
   and that message does not trigger any policy violation, but the PCE
   cannot provide any of the set of requested performance metrics for
   unspecified reasons, the PCE MUST set the I bit.  The I bit has no
   meaning in a request and SHOULD be ignored on receipt.
"

If you say "SHOULD" in the last sentence then you have to say what =
happens
otherwise.=20
In this specific case I believe you would just put a MUST in there.=20

Additionally, the document defines multiple ways to accomplish the same
effect on how monitoring takes place (In-band vs. out-of-band requests). =
Is
there some text that could be referenced to give some guides on when to =
use
what?=20

For some reason you decided to re-use the same object for the request =
and
the response. This typically leads to a more complex description because =
the
semantic of the object content is different in the two directions.=20

-- Operations & Management=20

How does the information being collected here related to other =
mechanisms to
potentially collect similar information? For example, network management
systems might collect information already and two systems collect lead =
to
conflicting conclusions.=20

Wouldn't it be good to discuss how the monitoring requests are treated
differently from any other request. Particularly for the overload =
handling
request this would be interesting. You don't want to the monitoring =
starve
because the request is stuck in the queues somewhere.=20

The document does not discuss what is actually being done with the =
collected
information. Obviously, there is a lot of potential for messing up the
network.=20

-- Security=20

The description focuses on securing communication. With the scope of the
document this seems to be fine. However, the real security problems will
show up when an adversary is able to control one of the PCE elements and =
is
therefore able to impact larger parts of the network. On the other hand,
adversaries could have a huge impact already without this specific =
extension
being defined. A PCE represents a single point of failure and a nice =
target.


-- IANA Considerations

To help IANA it is always useful to state whether you enter new values =
into
an existing registry (and where that registry has initially been =
defined) or
whether you create a new registry (and what the policy is).=20

* The new PCEP messages are being added to an existing registry (one =
that
was created with [RFC5440]).=20
* The new PCEP objects are also added to an existing registry. Most =
likely
one that was also created by [RFC5440].
* The same is true for the new Error-Values. Sentences like "A registry =
was
created for the Error-type and Error-value of the PCEP Error Object." =
are
misleading.=20
* Then, you create a new registry for a few other items. You may want to
reference http://tools.ietf.org/html/rfc5226. Are you sure that you =
really
want to put the bar so high for adding new entries to the registry, =
namely
"IETF review"? I would have said that "Specification Required" is more =
than
enough. You might also want to indicate whether bits can be re-assigned, =
the
semantic updated, etc. For example, assume that you revise the RFC to
strengthen the description. Under what conditions would it be OK to just
update the existing registry entries and under what conditions would you
need new entries? Because of the encoding you have chosen you have some
space constraints. You also say that "Each bit should be tracked with =
the
following qualities:". Why "should"? Just indicate what has to be =
included
in the registry. Additionally, I believe the second column isn't really =
a
description but rather a label.=20

-- Editorial

s/section Section 4.1/Section 4.1

In general, always write "Section X" instead of "section X".=20
Capitalize headings. Example: s/Path Computation Monitoring =
messages/Path
Computation Monitoring Messages

Ciao
Hannes


From julian.reschke@greenbytes.de  Wed Jan  6 07:02:26 2010
Return-Path: <julian.reschke@greenbytes.de>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 169C03A6879; Wed,  6 Jan 2010 07:02:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDjnh5EpxS3b; Wed,  6 Jan 2010 07:02:25 -0800 (PST)
Received: from donbot.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by core3.amsl.com (Postfix) with ESMTP id 24E533A63C9; Wed,  6 Jan 2010 07:02:24 -0800 (PST)
Received: from [192.168.1.105] (unknown [192.168.1.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by donbot.greenbytes.de (Postfix) with ESMTPSA id 7E4F3C4CA6C; Wed,  6 Jan 2010 16:02:22 +0100 (CET)
Message-ID: <4B44A5F8.7010103@greenbytes.de>
Date: Wed, 06 Jan 2010 16:02:16 +0100
From: Julian Reschke <julian.reschke@greenbytes.de>
Organization: greenbytes GmbH
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
References: <20100102230208.8346F6CB202@kilo.networkresonance.com>	<4B40E063.7070605@greenbytes.de> <20100105165742.9DE066CBAC8@kilo.networkresonance.com>
In-Reply-To: <20100105165742.9DE066CBAC8@kilo.networkresonance.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: draft-brown-versioning-link-relations@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Review of draft-brown-versioning-link-relations-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jan 2010 15:02:26 -0000

Hi Eric,

for now I have added:

"Care should be applied when versioned resources are subject to 
differing access policies. In this case, exposing links may leak 
information even if the linked resource itself is properly secured. In 
particular, the syntax of the link URI/IRI could expose sensitive 
information (see Section 16.2 of [RFC3253] for a similar consideration 
in WebDAV Versioning). Note that this applies to exposing link metadata 
in general, not only to links related to versioning."

to the Secutiry Considerations 
(<http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-latest.html#rfc.issue.expose-urls>).

Is this sufficient?

Lisa: please let me know whether (and when) to submit a new draft (I'll 
assume post LC end sometimes last week?).

Best regards, Julian


Eric Rescorla wrote:
> At Sun, 03 Jan 2010 19:22:27 +0100,
> Julian Reschke wrote:
>> Eric Rescorla wrote:
>>> This document describes a set of link relations which provide
>>> information about other versions of a versioned resource.
>>>
>>> In general this mechanism seems sound but I'm not sure that
>>> the security considerations are entirely adequate. This 
>>> mechanism lets you learn information about other versions
>>> of a resource even if you potentially don't have permission
>>> to view them directly. Consider a limiting case where each
>>> version of the resource had a name that contained the
>>> change set for that resource. E.g.,
>>>
>>> http://example.com/versions/filename/_@line_50_+_FOO;@line_60_+_BAR/;
>>>
>>> In this case, seeing other parts of the version tree leaks
>>> information about those versions. I don't think that this
>>> is a problem for the draft, but it might be useful to
>>> mention that this feature has implications for name 
>>> construction.
>> Yes, we can mention that.
>>
>> But, isn't this a general problem with exposing meta data in link 
>> relations? 
> 
> Yes, probably.
> 
> 
>> As such, shouldn't it have been mentioned in RFC 4287, and 
>> should it also be mentioned in draft-nottingham-http-link-header?
> 
> Probably... I just didn't read these. :) I only did this one as part
> of secdir review. 
> 
> -Ekr
> 


-- 
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782


From new-work-bounces@ietf.org  Wed Jan  6 11:52:30 2010
Return-Path: <new-work-bounces@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE8F33A68F7; Wed,  6 Jan 2010 11:52:30 -0800 (PST)
X-Original-To: new-work@ietf.org
Delivered-To: new-work@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id D796D28C131; Wed,  6 Jan 2010 11:52:28 -0800 (PST)
From: IESG Secretary <iesg-secretary@ietf.org>
To: new-work@ietf.org
Mime-Version: 1.0
Message-Id: <20100106195228.D796D28C131@core3.amsl.com>
Date: Wed,  6 Jan 2010 11:52:28 -0800 (PST)
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: new-work-bounces@ietf.org
Errors-To: new-work-bounces@ietf.org
X-Mailman-Approved-At: Wed, 06 Jan 2010 12:16:48 -0800
Subject: [secdir] [New-work] WG Review: BiDirectional or Server-Initiated HTTP (hybi)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jan 2010 19:52:31 -0000

A new IETF working group has been proposed in the Applications Area.  The
IESG has not made any determination as yet.  The following draft charter
was submitted, and is provided for informational purposes only.  Please
send your comments to the IESG mailing list (iesg@ietf.org) by Wednesday,
January 13, 2010.

BiDirectional or Server-Initiated HTTP (hybi)
--------------------------------------------------------
Last Modified: 2010-01-05

Current Status: Proposed Working Group

Chairs:
* TBD
* TBD

Applications Area Director(s):
* Lisa Dusseault <lisa.dusseault@gmail.com>
* Alexey Melnikov <alexey.melnikov@isode.com>

Applications Area Advisor:
* Lisa Dusseault <lisa.dusseault@gmail.com>

Mailing Lists:
General Discussion: hybi@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/hybi
Archive: http://www.ietf.org/mail-archive/web/hybi/current/maillist.html

Description of Working Group:

HTTP has most often been used as a request/response protocol, leading to
clients polling for new data, or users hitting the refresh button in their
browsers. Recent web applications are finding ways to communicate with web
servers in realtime, pushing data from the server-side to the client as
soon as it is available. However, these applications at present can only
use a variety of HTTP mechanisms (e.g. long polling requests) to
communicate with web servers bidirectionally.

The Hypertext-Bidirectional (HyBi) working group will seek
standardization
of one approach to maintain bidirectional communications between the HTTP
client, server and intermediate entities, which will provide more
efficiency compared to the current use of hanging requests.

A general approach is preferred, with abstract semantics that can apply
to
a large number of applications.

The Web is the design space into which the solution will be deployed.
Since the existing Web is much more complicated that it seems, the working
group will document how it works first, with special attention to deployed
infrastructure (e.g. web clients, intermediaries, firewalls, NATs, web
servers) and programming environments.

New features will be required of clients, servers, or intermediaries
allowing a more scalable and robust end-to-end experience.

Although multiple protocols exist as starting points, backward
compatibility with these protocols is not a requirement.

In particular, the working group has liaised with the W3C WebApps working
group around the WebSockets protocol and the need to support the WebSocket
API; as agreed by both parties, the HyBi working group will take on prime
responsibility for the specification of the WebSockets protocol, taking
into consideration all the requirements, needs and eventual concerns
raised by the W3C WebApps working group.  The
draft-hixie-thewebsocketprotocol "The Web Socket protocol" is considered
as the input document for the working group.

Wide browser support is a goal for the bidirectional communication
mechanism, however the solution should also be suitable for clients other
than Web Browsers.  The Working Group will work to standardize a generic
solution that can work efficiently in as many of the deployed environments
as possible and in particular in all the elements of the web
infrastructure (e.g. web browser, generic HTTP client, HTTP server and
HTTP-aware intermediaries like proxies, load balancers, caches, etc.) and
it is not specific for just one.

The Working Group should consider:
* Implementer experience
* Impact on existing implementations and deployments
* Ability to achieve broad implementation
* Ability to address broader use cases than those covered in the input
document

The Working Group will produce one or more documents suitable for
consideration as Proposed Standard that will:
* Define a characterization of the design space
* Define a solution for the bidirectional web communication


Goals and Milestones:
---------------------
Apr 2010 - Submit a document as a working group item describing the
Web Socket requirements (draft-hixie-thewebsocketprotocol will be used
as a starting point for further work.)
Apr 2010 - Submit 'The Web Socket protocol' as working group item
(draft-hixie-thewebsocketprotocol will be used as a starting point for
further work.)
Jul 2010 - Start Working Group Last Call on the WebSocket requirements
Jul 2010 - Submit a document as a working group item describing the
Design Space characterization
Sep 2010 - Submit the 'Web Socket requirements' to the IESG for
consideration as an Informational document
Nov 2010 - Start Working Group Last Call on the Design Space
characterization
Nov 2010 - Start of discussion about Web Socket extensions the group
should work on
Dec 2010 - Submit the 'Design Space characterization' to the IESG for
consideration as an Informational document
Mar 2011 - Start Working Group Last Call on 'The Web Socket protocol'
Mar 2011 - Prepare milestone update to start new work within the scope
of the charter
Apr 2011 - Submit the 'The Web Socket protocol' to the IESG for
consideration as a Proposed Standard
May 2011 - Close or recharter


_______________________________________________
New-work mailing list
New-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work

From ekr@networkresonance.com  Wed Jan  6 13:31:49 2010
Return-Path: <ekr@networkresonance.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BF993A6955; Wed,  6 Jan 2010 13:31:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.668
X-Spam-Level: 
X-Spam-Status: No, score=0.668 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888,  HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTydAW-JAHYC; Wed,  6 Jan 2010 13:31:48 -0800 (PST)
Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 3C2CF3A68C7; Wed,  6 Jan 2010 13:31:48 -0800 (PST)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 860CB6CC151; Wed,  6 Jan 2010 13:34:03 -0800 (PST)
Date: Wed, 06 Jan 2010 13:34:03 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Julian Reschke <julian.reschke@greenbytes.de>
In-Reply-To: <4B44A5F8.7010103@greenbytes.de>
References: <20100102230208.8346F6CB202@kilo.networkresonance.com> <4B40E063.7070605@greenbytes.de> <20100105165742.9DE066CBAC8@kilo.networkresonance.com> <4B44A5F8.7010103@greenbytes.de>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20100106213403.860CB6CC151@kilo.networkresonance.com>
Cc: iesg@ietf.org, draft-brown-versioning-link-relations@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] Review of draft-brown-versioning-link-relations-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jan 2010 21:31:49 -0000

This looks fine to me.

-ekr

From stefan@aaa-sec.com  Thu Jan  7 03:19:39 2010
Return-Path: <stefan@aaa-sec.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29D8E3A6816 for <secdir@core3.amsl.com>; Thu,  7 Jan 2010 03:19:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level: 
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+TA-opAxDkO for <secdir@core3.amsl.com>; Thu,  7 Jan 2010 03:19:38 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id 1F5CC3A67B2 for <secdir@ietf.org>; Thu,  7 Jan 2010 03:19:37 -0800 (PST)
Received: from s57.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id E017F2E80AD for <secdir@ietf.org>; Thu,  7 Jan 2010 12:19:37 +0100 (CET)
Received: (qmail 86476 invoked from network); 7 Jan 2010 11:19:33 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO MacBookPro-6.local) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s57.loopia.se (qmail-ldap-1.03) with SMTP for <pcain2@mail2.coopercain.com>; 7 Jan 2010 11:19:33 -0000
Received: from [127.0.0.1] by MacBookPro-6.local (PGP Universal service); Thu, 07 Jan 2010 12:19:34 +0100
X-PGP-Universal: processed; by MacBookPro-6.local on Thu, 07 Jan 2010 12:19:34 +0100
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Thu, 07 Jan 2010 12:19:31 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: pat cain <pcain2@mail2.coopercain.com>, <draft-ietf-pkix-rfc3161-update@tools.ietf.org>, "Pope, Nick" <Nick.Pope@thales-esecurity.com>
Message-ID: <C76B81D3.794B%stefan@aaa-sec.com>
Thread-Topic: [secdir] Security Review of draft-ietf-pkix-rfc3161-update-09.txt
Thread-Index: Acp5zbtpe0AaM7i2RWyyVwO4obpXfwVvYzrV
In-Reply-To: <02f601ca79cd$c433b4e0$4c9b1ea0$@coopercain.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: pkix-chairs@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] Security Review of draft-ietf-pkix-rfc3161-update-09.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2010 11:19:39 -0000

Pat,

I think you may have misunderstood the issue this draft is addressing.
Including ESSCertIDv2 does not mean adding another signature with different
strength.

ESSCertID and ESSCertIDv2 are just different certificate identifiers for the
same certificate used to validate the same signature. The only difference is
that the identifier in ESSCertIDv2 is done with a stronger hash (and
includes a hash alg identifier) than the one in ESSCertID.

I don't see any problem with including both. How to deal with that is
defined by, and an issue for, S/MIME rather than this specification.

/Stefan

On 09-12-10 8:19 PM, "pat cain" <pcain2@mail2.coopercain.com> wrote:

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security
> area directors. Document editors and WG chairs should treat these
> comments just like any other last call comments.
> 
> Document Abstract:
> 
>    This document updates RFC 3161 [RFC3161]. It allows the use of
>    ESSCertIDv2 defined in RFC 5035 [ESSV2] to specify the hash of a
>    signer certificate when the hash is calculated with a function other
>    than SHA-1 [SHA1].
> 
> Comment:
> 
> The purpose of this document is laudable.
> My only comment/concern is about the 'note' at the end of Section 2.2.1.
> 
> "Note: For backwards compatibility, in line with RFC 5035, both
>             ESSCertID and ESSCertIDv2 MAY be present. Systems MAY ignore
>             ESSCertIDv2 if RFC 5035 has not been implemented."
> 
> When RFC3161 was undergoing development, there was a robust discussion about
> signing 
> A TST multiple times. I seem to recall the output was not to do it. Since
> the requestor has to verify the TST when the TSA sends it back, I'm unclear
> on how a requestor that "has not implemented RFC5035" is going to do this
> verification if both ESSCertID and ESSCertIDV2 are included.
> I expect more guidance is needed here since the different signature
> algorithms will have differing characteristics and strengths.
> 
> It seems to make more sense that a TSA return a TST with *either* an
> ESSCertID or ESSCertIDV2, but not both. Is there a specific use case that
> was intended here or are we just trying to be polite.
> 
> Pat Cain
> 
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir



From kent@bbn.com  Thu Jan  7 13:01:28 2010
Return-Path: <kent@bbn.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D9AC3A68C5 for <secdir@core3.amsl.com>; Thu,  7 Jan 2010 13:01:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCki5bgMJoD3 for <secdir@core3.amsl.com>; Thu,  7 Jan 2010 13:01:27 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id EAB413A67B3 for <secdir@ietf.org>; Thu,  7 Jan 2010 13:01:26 -0800 (PST)
Received: from dhcp89-089-161.bbn.com ([128.89.89.161]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from <kent@bbn.com>) id 1NSzTw-0008RZ-BO; Thu, 07 Jan 2010 16:01:24 -0500
Mime-Version: 1.0
Message-Id: <p06240810c76be77be756@[128.89.89.161]>
Date: Thu, 7 Jan 2010 14:38:14 -0500
To: secdir@ietf.org
From: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary="============_-949224412==_ma============"
Cc: ajs@shinkuro.com, dol@cryptocom.ru, ogud@ogud.com, Ralph Droms <rdroms@cisco.com>
Subject: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2010 21:01:28 -0000

--============_-949224412==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

I reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

Since several SECDIR members are reviewing 
draft-ietf-dnsext-dnssec-gost-05 I have chosen to focus on one aspect 
of the document, i.e., the statement that support for GOST algorithms 
is a SHOULD (Section 6.1) for all DNSSEC aware implementations. I 
think this is an inappropriate characterization for the level of 
support that ought to be accorded an algorithm of this type. I 
explain my rationale for this assertion below.

GOST is an example of what I would term a "national" crypto 
algorithm. I characterize an algorithm as "national" if use of the 
algorithm is mandated by a government (within its sphere of 
influence, for some or all application contexts), but the algorithm 
otherwise is not widely adopted. The GOST set of algorithms are one 
such example. Others (chosen form the space of symmetric algorithms) 
include Camellia (Japan), SKIPJACK (US), SEED (Korea), and SMS4 
(China, for WAPI). AES and DES are not "national"  algorithms.  Even 
though they were published by NIST as FIPS, both were very widely 
adopted outside of the national context in which use is (was) 
mandated. This illustrates that the designation of an algorithm as 
"national" can change over time.

Other IETF WGs (e.g., IPsec, S/MIME, OPGP, and TLS) have adopted a 
policy of publishing RFCs that describe how to use one or more 
national algorithms in the context of a protocol. However, in these 
WGs, support for the algorithm is optional, i.e., a MAY in RFC 2119 
parlance. These RFCs define how to use a national algorithm IF one 
chooses to implement it. They do not require support for the 
algorithm by making it a SHOULD or MUST. This approach allows the 
IETF to publish RFCs that deal with a wide range of crypto algorithms 
(national and otherwise) without prejudice, without engaging in a 
protracted debate about whether all of these algorithms are equally 
"worthy" etc. These WGs also define a small number of mandatory (MUST 
or SHOULD), non-national algorithms, to promote interoperability.

I think the convention adopted by other WGs is appropriate for DNESEC 
as well. As a result, I suggest that this document be modified to 
specify support for GOST algorithms as a MAY.
--============_-949224412==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>review of
draft-ietf-dnsext-dnssec-gost-05</title></head><body>
<div><font color="#000000">I reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG.&nbsp; These comments were written
primarily for the benefit of the security area directors.&nbsp;
Document editors and WG chairs should treat these comments just like
any other last call comments.</font><br>
<font color="#000000"></font></div>
<div><font color="#000000">Since several SECDIR members are
reviewing<font face="Courier" size="+1">
draft-ietf-dnsext-dnssec-gost-05</font></font><font color="#000000"> I
have chosen to focus on one aspect of the document, i.e., the
statement that support for GOST algorithms is a SHOULD (Section 6.1)
for<u> all</u> DNSSEC aware implementations. I think this is an
inappropriate characterization for the level of support that ought to
be accorded an algorithm of this type. I explain my rationale for this
assertion below.</font></div>
<div><font color="#000000"><br>
GOST is an example of what I would term a &quot;national&quot; crypto
algorithm. I characterize an algorithm as &quot;national&quot; if use
of the algorithm is mandated by a government (within its sphere of
influence, for some or all application contexts), but the algorithm
otherwise is not widely adopted. The GOST set of algorithms are one
such example. Others (chosen form the space of symmetric algorithms)
include Camellia (Japan), SKIPJACK (US), SEED (Korea), and SMS4
(China, for WAPI). AES and DES are not &quot;national&quot;&nbsp;
algorithms.&nbsp; Even though they were published by NIST as FIPS,
both were very widely adopted outside of the national context in which
use is (was) mandated. This illustrates that the designation of an
algorithm as &quot;national&quot; can change over time.<br>
<br>
Other IETF WGs (e.g., IPsec, S/MIME, OPGP, and TLS) have adopted a
policy of publishing RFCs that describe how to use one or more
national algorithms in the context of a protocol. However, in these
WGs, support for the algorithm is optional, i.e., a MAY in RFC 2119
parlance. These RFCs define how to use a national algorithm IF one
chooses to implement it. They do not require support for the algorithm
by making it a SHOULD or MUST. This approach allows the IETF to
publish RFCs that deal with a wide range of crypto algorithms
(national and otherwise) without prejudice, without engaging in a
protracted debate about whether all of these algorithms are equally
&quot;worthy&quot; etc. These WGs also define a small number of
mandatory (MUST or SHOULD), non-national algorithms, to promote
interoperability.<br>
<br>
I think the convention adopted by other WGs is appropriate for DNESEC
as well. As a result, I suggest that this document be modified to
specify support for GOST algorithms as a MAY.</font></div>
</body>
</html>
--============_-949224412==_ma============--

From ajs@shinkuro.com  Thu Jan  7 14:28:17 2010
Return-Path: <ajs@shinkuro.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D121428C112 for <secdir@core3.amsl.com>; Thu,  7 Jan 2010 14:28:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.049
X-Spam-Level: 
X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1966PLiipqZu for <secdir@core3.amsl.com>; Thu,  7 Jan 2010 14:28:17 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id EDDB628C0E6 for <secdir@ietf.org>; Thu,  7 Jan 2010 14:28:16 -0800 (PST)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 646842FE8CA1; Thu,  7 Jan 2010 22:28:14 +0000 (UTC)
Date: Thu, 7 Jan 2010 17:28:09 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: Stephen Kent <kent@bbn.com>
Message-ID: <20100107222809.GA25747@shinkuro.com>
References: <p06240810c76be77be756@[128.89.89.161]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p06240810c76be77be756@[128.89.89.161]>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: Ralph Droms <rdroms@cisco.com>, dol@cryptocom.ru, ogud@ogud.com, secdir@ietf.org
Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2010 22:28:17 -0000

Hi,

I want to emphasise two things, before my question:

    1.  I'm not the shepherd for this document, but I'm asking this
    question in my capacity as co-Chair, such that I might ask
    something (or not ask) of document editors based on the response.

    2.  I super-really-I-mean-it don't have a strong opinion on this
    matter yet.

On Thu, Jan 07, 2010 at 02:38:14PM -0500, Stephen Kent wrote:

> Other IETF WGs (e.g., IPsec, S/MIME, OPGP, and TLS) have adopted a  
> policy of publishing RFCs that describe how to use one or more national 
> algorithms in the context of a protocol. However, in these WGs, support 
> for the algorithm is optional, i.e., a MAY in RFC 2119 parlance. These 
> RFCs define how to use a national algorithm IF one chooses to implement 
> it. They do not require support for the algorithm by making it a SHOULD 
> or MUST. This approach allows the IETF to publish RFCs that deal with a 
> wide range of crypto algorithms (national and otherwise) without 
> prejudice, without engaging in a protracted debate about whether all of 
> these algorithms are equally "worthy" etc. These WGs also define a small 
> number of mandatory (MUST or SHOULD), non-national algorithms, to promote 
> interoperability.

I get this argument.  The worry I have has something to do with either
the protocol environment or the use cases of the analogue protocols
you've picked.

In the case of IPsec and TLS, I believe (and I'm totally prepared to
be corrected) that there is a negotiation mechanism in place between
end points.  If I'm right about that, there's a serious disanalogy
here, because there's no possible way to make that negotiation work in
DNS (because of caches, and the way they might affect results).
That's perhaps unfortunate, but it's the protocol as we have it.

In the case of OPGP and S/MIME, the issue is different: these are
mostly protocols for people communicating with one another inside some
web of trust.  (I know, I know, S/MIME isn't like that, but it
immediately is in case we're using limited-deployment algorithms.)
The disanalogy here is different, but it has a similar force: if we
are going to continue to maintain the position that there's a global
DNS that's a universal service, then we have to discourage
non-implementation of algorithms that will freeze people out.

I've done my best to present above, as succinctly as possible, the
arguments against your argument.  I don't know that I've done their
partisans justice, but I'm trying to weigh each side.  So I'd
appreciate it if

    (1) those who agree with Steve could make their best arguments
    supporting his (do we need the secdir list for this?  Feel free to
    forward this, and you can direct replies to me for summary if
    desired)

and 
    
    (2) those who think I've made a weak case to follow up with
    stronger arguments.

A

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.

From alper.yegin@yegin.org  Thu Jan  7 23:55:33 2010
Return-Path: <alper.yegin@yegin.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA39E3A635F; Thu,  7 Jan 2010 23:55:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.531
X-Spam-Level: 
X-Spam-Status: No, score=-0.531 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SofHLtxj2uN5; Thu,  7 Jan 2010 23:55:33 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id CE32A28C0EA; Thu,  7 Jan 2010 23:55:31 -0800 (PST)
Received: from LENOVO (dsl.static.85-105-43069.ttnet.net.tr [85.105.168.61]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0LaVtv-1OBoQh3Ey7-00lufv; Fri, 08 Jan 2010 02:55:28 -0500
From: "Alper Yegin" <alper.yegin@yegin.org>
To: "'Yoshihiro Ohba'" <yoshihiro.ohba@toshiba.co.jp>, "'Russ Mundy'" <mundy@sparta.com>
References: <20100106071553.21C5B17B380F@calvin.home.tislabs.com> <4B46E06D.4070607@toshiba.co.jp>
In-Reply-To: <4B46E06D.4070607@toshiba.co.jp>
Date: Fri, 8 Jan 2010 09:55:19 +0200
Message-ID: <029001ca9037$f17bbda0$d47338e0$@yegin@yegin.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcqQNU1qjPCdMmnlRQ6jQCQwEN/N8gAAmYjw
Content-Language: en-us
X-Provags-ID: V01U2FsdGVkX18hcMOsIAPmP6qih6y2d1I4qtU2WUz0LDOXLfq EQ08togdO0/BbY1ylHle0ZzrjXlkGWriqevIL4FuZzXULf2NLd yE2syw4ijO9PMlUhpp8kw==
Cc: jari.arkko@piuha.net, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ohba-pana-pemk-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jan 2010 07:55:33 -0000

> > ** To make the scope more clear, I would suggest changing the first
> >    sentence of section 2.2 to read: "One PEMK is used between one =
PaC
> >    and one EP."
>=20
> OK.

There can be multiple PANA sessions between the same PaC and the PAA, =
hence there can also be multiple PEMKs between the same pair of PaC-EP. =
This is currently allowed by the specs, and I don't see a need to =
constrain that with the above sentence.

Alper



From alper.yegin@yegin.org  Fri Jan  8 00:10:12 2010
Return-Path: <alper.yegin@yegin.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72CFC3A6866; Fri,  8 Jan 2010 00:10:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.531
X-Spam-Level: 
X-Spam-Status: No, score=-0.531 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iD-8deAAG3o2; Fri,  8 Jan 2010 00:10:11 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 7F5773A67F4; Fri,  8 Jan 2010 00:10:10 -0800 (PST)
Received: from LENOVO (dsl.static.85-105-43069.ttnet.net.tr [85.105.168.61]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0Md2mA-1NAwXd31gg-00IeKO; Fri, 08 Jan 2010 03:09:58 -0500
From: "Alper Yegin" <alper.yegin@yegin.org>
To: "'Yoshihiro Ohba'" <yoshihiro.ohba@toshiba.co.jp>
References: <20100106071553.21C5B17B380F@calvin.home.tislabs.com> <4B46E06D.4070607@toshiba.co.jp> <029001ca9037$f17bbda0$d47338e0$%yegin@yegin.org> <4B46E5DB.2030706@toshiba.co.jp>
In-Reply-To: <4B46E5DB.2030706@toshiba.co.jp>
Date: Fri, 8 Jan 2010 10:09:49 +0200
Message-ID: <029201ca9039$f83ad020$e8b07060$@yegin@yegin.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcqQOIP2vH4puYFTR2unETUKXlGWYQAAMfNA
Content-Language: en-us
X-Provags-ID: V01U2FsdGVkX19gLJuv7VMUv8kY63eY7UiOmt/Hgq4oZMG3UaA /t7XkY6GdMxOGSTuNBTqkV3tk/alBKYG3LmecxTgddewrBnORR 8EmqELiFJl7yjkJAnS0+A==
Cc: secdir@ietf.org, jari.arkko@piuha.net, iesg@ietf.org, 'Russ Mundy' <mundy@sparta.com>
Subject: Re: [secdir] Secdir review of draft-ohba-pana-pemk-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jan 2010 08:10:12 -0000

Yoshi,

Going back to the baseline text, it says:

   A PEMK is used between a PaC and an EP.  A PEMK MUST NOT be shared
   among multiple PaCs or EPs.


I think the intent of the first sentence is same as the second one.

So, saying "A PEMK is bound to a PaC-EP pair. A PEMK MUST NOT be shared =
among multiple PaCs or EPs." is more accurate.

Alper








> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yoshihiro.ohba@toshiba.co.jp]
> Sent: Friday, January 08, 2010 9:59 AM
> To: Alper Yegin
> Cc: 'Russ Mundy'; iesg@ietf.org; secdir@ietf.org; jari.arkko@piuha.net
> Subject: Re: Secdir review of draft-ohba-pana-pemk-03
>=20
> Alper,
>=20
> Since it does not say "Only one PMK is used ...", I think
> the case you mentioned below is covered.
>=20
> Yoshihiro Ohba
>=20
>=20
> Alper Yegin wrote:
> >>> ** To make the scope more clear, I would suggest changing the =
first
> >>>    sentence of section 2.2 to read: "One PEMK is used between one
> PaC
> >>>    and one EP."
> >> OK.
> >
> > There can be multiple PANA sessions between the same PaC and the =
PAA,
> hence there can also be multiple PEMKs between the same pair of =
PaC-EP.
> This is currently allowed by the specs, and I don't see a need to
> constrain that with the above sentence.
> >
> > Alper
> >
> >
> >



From yoshihiro.ohba@toshiba.co.jp  Thu Jan  7 23:36:24 2010
Return-Path: <yoshihiro.ohba@toshiba.co.jp>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF5BF3A67D3; Thu,  7 Jan 2010 23:36:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.089
X-Spam-Level: 
X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8O2NGOnfh3j; Thu,  7 Jan 2010 23:36:23 -0800 (PST)
Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by core3.amsl.com (Postfix) with ESMTP id 5F2C13A63EB; Thu,  7 Jan 2010 23:36:23 -0800 (PST)
Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp  with ESMTP id o087aJiT026054; Fri, 8 Jan 2010 16:36:19 +0900 (JST)
Received: (from root@localhost) by arc11.toshiba.co.jp  id o087aJsK018208; Fri, 8 Jan 2010 16:36:19 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148]  by arc11.toshiba.co.jp with ESMTP id SAA18194; Fri, 8 Jan 2010 16:36:19 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp  with ESMTP id o087aHNF017107; Fri, 8 Jan 2010 16:36:18 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id o087aErQ018097; Fri, 8 Jan 2010 16:36:16 +0900 (JST)
Received: from [133.196.17.30] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0KVX00HXN3SF4150@mail.po.toshiba.co.jp>; Fri, 08 Jan 2010 16:36:15 +0900 (JST)
Date: Fri, 08 Jan 2010 16:36:13 +0900
From: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
In-reply-to: <20100106071553.21C5B17B380F@calvin.home.tislabs.com>
To: Russ Mundy <mundy@sparta.com>
Message-id: <4B46E06D.4070607@toshiba.co.jp>
MIME-version: 1.0
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7bit
References: <20100106071553.21C5B17B380F@calvin.home.tislabs.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
X-Mailman-Approved-At: Fri, 08 Jan 2010 00:22:14 -0800
Cc: alper.yegin@yegin.org, jari.arkko@piuha.net, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ohba-pana-pemk-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jan 2010 07:36:25 -0000

Thank you for your review of the draft.  Please see my 
response below.

Russ Mundy wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> * There are some sections where additional information would make the
>   document more clear and complete:
> 
> ** Section 1. I suggest including Figure 1 from RFC5193 between the
>    first and second paragraphs of this section to illustrate the
>    relationship of the components being described.  (Although a
>    reference to the figure might be sufficient, 5193 is Informational
>    so including the diagram would avoid a potentially normative
>    reference.)

OK.

> 
> ** Section 2.4 defines the lifetime of the PEMK with respect to the
>    MSK.  I believe this means the lifetime of the exact MSK from which
>    the particular PEMK is derived.  If this is the intent, I suggest
>    adding the following to the end of the current sentence: "from
>    which it is derived."

OK.

> 
> ** Since the PEMK does have a specified lifetime, it seems as though
>    there should be some information provided about what occurs at the
>    end of that lifetime.  If this information is in other related
>    specifications then these should be referenced.  

To address this issue, we have added the following text: "At 
the end of the lifetime, the PEMK and its associated states 
MUST be deleted."

> 
> ** Similarly, since the PEMK is defined to be a pre-shared key,
>    providing information (or reference(s)) to what protocols are
>    required to put the PEMK in place would make the specification more
>    clear (is the EAP security mechanism required to provide for
>    this?).

We provide a guideline for distributing PEMK from PAA to EP 
in Section 3.2.  There was a fair amount of discussion in 
the PANA WG, and AFAIK it was decided not to specify a 
specific key distribution protocol in this document.

> 
> * Some terminology does not seem consistent with other referenced
>   specifications:
> 
> ** Although the Master Session Key (MSK) provides the basis for the
>    PEMK, there is no definition of MSK in this specification and the
>    terminology sections of RFCs referenced in the introduction
>    (RFC3748 and RFC5191) have different definitions for MSK in their
>    terminology sections.

Yes, the two documents do not use the same text for MSK 
definition, but they mean the same key and this should not 
be a problem.  We will follow your below suggestion of use 
of more terms from RFFC 5191.

> 
> ** Making Use of more terminology from RFC5191 would make it easier to
>    relate this specification to related RFCs.  For instance, use of
>    "PANA Session", "Session Lifetime" and "PANA Security Association
>    (PANA SA)" in Sections 2.2, 2.3 & 2.4 might make the sections more
>    clear.  

OK.

>It also appears that the Key Name of PEMK (section 2.1)
>    should have some relationship to a "PANA Session" or "Session
>    Identifier" but it's not clear if or what relationship is
>    intended.  The specification should state the relationship (or
>    absence of a relationship) or implementers will make different
>    (probably incompatible) choices in their implementations.
>

Session identifier is included in the key name as SID.  We 
added the following sentence to address your comment.

"Inclusion of the EPID, SID and KID provides uniqueness of 
PEMK names among multiple PaC-EP pairs under a given PAA."

> ** To make the scope more clear, I would suggest changing the first
>    sentence of section 2.2 to read: "One PEMK is used between one PaC
>    and one EP."

OK.

> 
> I would suggest adding a terminology section to this specification
> that referenced the terminology sections of RFC3748 and RFC5191 since
> they are both standards track documents.
> 

Terminology section has been added.  All reused terms are 
from RFC5191 now.

Those changes are incorporated in to version 04, together 
with the changes based on Pasi and Alexey's comments.

Thank you,
Yoshihiro Ohba


> 
> Regards,
> 
> Russ Mundy
> 
> 
> 


From yoshihiro.ohba@toshiba.co.jp  Thu Jan  7 23:59:29 2010
Return-Path: <yoshihiro.ohba@toshiba.co.jp>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEBDD3A6866; Thu,  7 Jan 2010 23:59:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.089
X-Spam-Level: 
X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxSppDsNWU1F; Thu,  7 Jan 2010 23:59:29 -0800 (PST)
Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by core3.amsl.com (Postfix) with ESMTP id EECA53A635F; Thu,  7 Jan 2010 23:59:28 -0800 (PST)
Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp  with ESMTP id o087xQD0007180; Fri, 8 Jan 2010 16:59:26 +0900 (JST)
Received: (from root@localhost) by arc11.toshiba.co.jp  id o087xQ6b011522; Fri, 8 Jan 2010 16:59:26 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148]  by arc11.toshiba.co.jp with ESMTP id SAA11521; Fri, 8 Jan 2010 16:59:26 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp  with ESMTP id o087xQd0006931; Fri, 8 Jan 2010 16:59:26 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id o087xPmY022305; Fri, 8 Jan 2010 16:59:25 +0900 (JST)
Received: from [133.196.17.30] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0KVX00HVR4V14160@mail.po.toshiba.co.jp>; Fri, 08 Jan 2010 16:59:25 +0900 (JST)
Date: Fri, 08 Jan 2010 16:59:23 +0900
From: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
In-reply-to: <029001ca9037$f17bbda0$d47338e0$%yegin@yegin.org>
To: Alper Yegin <alper.yegin@yegin.org>
Message-id: <4B46E5DB.2030706@toshiba.co.jp>
MIME-version: 1.0
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7bit
References: <20100106071553.21C5B17B380F@calvin.home.tislabs.com> <4B46E06D.4070607@toshiba.co.jp> <029001ca9037$f17bbda0$d47338e0$%yegin@yegin.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
X-Mailman-Approved-At: Fri, 08 Jan 2010 00:22:14 -0800
Cc: secdir@ietf.org, jari.arkko@piuha.net, iesg@ietf.org, 'Russ Mundy' <mundy@sparta.com>
Subject: Re: [secdir] Secdir review of draft-ohba-pana-pemk-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jan 2010 07:59:29 -0000

Alper,

Since it does not say "Only one PMK is used ...", I think 
the case you mentioned below is covered.

Yoshihiro Ohba


Alper Yegin wrote:
>>> ** To make the scope more clear, I would suggest changing the first
>>>    sentence of section 2.2 to read: "One PEMK is used between one PaC
>>>    and one EP."
>> OK.
> 
> There can be multiple PANA sessions between the same PaC and the PAA, hence there can also be multiple PEMKs between the same pair of PaC-EP. This is currently allowed by the specs, and I don't see a need to constrain that with the above sentence.
> 
> Alper
> 
> 
> 


From yoshihiro.ohba@toshiba.co.jp  Fri Jan  8 00:38:59 2010
Return-Path: <yoshihiro.ohba@toshiba.co.jp>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DD993A6821; Fri,  8 Jan 2010 00:38:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.089
X-Spam-Level: 
X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYteeP+IbT-p; Fri,  8 Jan 2010 00:38:58 -0800 (PST)
Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by core3.amsl.com (Postfix) with ESMTP id 8F9F13A67F4; Fri,  8 Jan 2010 00:38:58 -0800 (PST)
Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp  with ESMTP id o088ctIR027713; Fri, 8 Jan 2010 17:38:55 +0900 (JST)
Received: (from root@localhost) by arc11.toshiba.co.jp  id o088ctc3024536; Fri, 8 Jan 2010 17:38:55 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148]  by arc11.toshiba.co.jp with ESMTP id TAA24533; Fri, 8 Jan 2010 17:38:55 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp  with ESMTP id o088css2012540; Fri, 8 Jan 2010 17:38:55 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id o088cocG013120; Fri, 8 Jan 2010 17:38:53 +0900 (JST)
Received: from [133.196.17.30] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0KVX00HP66OM4180@mail.po.toshiba.co.jp>; Fri, 08 Jan 2010 17:38:46 +0900 (JST)
Date: Fri, 08 Jan 2010 17:38:44 +0900
From: Yoshihiro Ohba <yoshihiro.ohba@toshiba.co.jp>
In-reply-to: <029201ca9039$f83ad020$e8b07060$%yegin@yegin.org>
To: Alper Yegin <alper.yegin@yegin.org>
Message-id: <4B46EF14.2060901@toshiba.co.jp>
MIME-version: 1.0
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7bit
References: <20100106071553.21C5B17B380F@calvin.home.tislabs.com> <4B46E06D.4070607@toshiba.co.jp> <029001ca9037$f17bbda0$d47338e0$%yegin@yegin.org> <4B46E5DB.2030706@toshiba.co.jp> <029201ca9039$f83ad020$e8b07060$%yegin@yegin.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
Cc: secdir@ietf.org, jari.arkko@piuha.net, iesg@ietf.org, 'Russ Mundy' <mundy@sparta.com>
Subject: Re: [secdir] Secdir review of draft-ohba-pana-pemk-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jan 2010 08:38:59 -0000

Alper Yegin wrote:
> Yoshi,
> 
> Going back to the baseline text, it says:
> 
>    A PEMK is used between a PaC and an EP.  A PEMK MUST NOT be shared
>    among multiple PaCs or EPs.
> 
> 
> I think the intent of the first sentence is same as the second one.
> 
> So, saying "A PEMK is bound to a PaC-EP pair. A PEMK MUST NOT be shared among multiple PaCs or EPs." is more accurate.

I agree.

Yoshihiro Ohba


> 
> Alper
> 
> 
> 
> 
> 
> 
> 
> 
>> -----Original Message-----
>> From: Yoshihiro Ohba [mailto:yoshihiro.ohba@toshiba.co.jp]
>> Sent: Friday, January 08, 2010 9:59 AM
>> To: Alper Yegin
>> Cc: 'Russ Mundy'; iesg@ietf.org; secdir@ietf.org; jari.arkko@piuha.net
>> Subject: Re: Secdir review of draft-ohba-pana-pemk-03
>>
>> Alper,
>>
>> Since it does not say "Only one PMK is used ...", I think
>> the case you mentioned below is covered.
>>
>> Yoshihiro Ohba
>>
>>
>> Alper Yegin wrote:
>>>>> ** To make the scope more clear, I would suggest changing the first
>>>>>    sentence of section 2.2 to read: "One PEMK is used between one
>> PaC
>>>>>    and one EP."
>>>> OK.
>>> There can be multiple PANA sessions between the same PaC and the PAA,
>> hence there can also be multiple PEMKs between the same pair of PaC-EP.
>> This is currently allowed by the specs, and I don't see a need to
>> constrain that with the above sentence.
>>> Alper
>>>
>>>
>>>
> 
> 
> 


From simon@josefsson.org  Fri Jan  8 04:48:37 2010
Return-Path: <simon@josefsson.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE5783A68A0; Fri,  8 Jan 2010 04:48:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4QrsIkiEbEB; Fri,  8 Jan 2010 04:48:36 -0800 (PST)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 4F1FA3A67FD; Fri,  8 Jan 2010 04:48:34 -0800 (PST)
Received: from mocca (c80-216-24-99.bredband.comhem.se [80.216.24.99]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id o08CmJSX009378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 8 Jan 2010 13:48:25 +0100
From: Simon Josefsson <simon@josefsson.org>
To: "Glen Zorn" <gwz@net-zen.net>
References: <000001ca6a19$665b3320$33119960$@net>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:100108:alexey.melnikov@isode.com::9ZLjKvUmUCn433Qk:E2s
X-Hashcash: 1:22:100108:iesg@ietf.org::aejakOGiLs3gLiBc:c6Z
X-Hashcash: 1:22:100108:kurt.zeilenga@isode.com::bDA6o+IRcr5QhGhT:1fN8
X-Hashcash: 1:22:100108:secdir@ietf.org::/Ow4xjjwvDyGOp31:U0HR
X-Hashcash: 1:22:100108:nicolas.williams@sun.com::BMcrnxbaQ7yowkvS:EKz3
X-Hashcash: 1:22:100108:tlyu@mit.edu::Ioz3NT/9JQBoMHUO:a24o
X-Hashcash: 1:22:100108:gwz@net-zen.net::n0p+WSrRMii6pz6H:e2GL
Date: Fri, 08 Jan 2010 13:48:19 +0100
In-Reply-To: <000001ca6a19$665b3320$33119960$@net> (Glen Zorn's message of "Fri, 20 Nov 2009 14:39:59 -0500")
Message-ID: <87k4vs7ofg.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: clamav-milter 0.95.3 at yxa-v
X-Virus-Status: Clean
X-Mailman-Approved-At: Fri, 08 Jan 2010 04:52:25 -0800
Cc: Nicolas.Williams@sun.com, secdir@ietf.org, 'Kurt Zeilenga' <Kurt.Zeilenga@Isode.com>, iesg@ietf.org, 'Alexey Melnikov' <alexey.melnikov@Isode.com>
Subject: Re: [secdir] secdir review of draft-ietf-sasl-gs2-17
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jan 2010 12:48:37 -0000

"Glen Zorn" <gwz@net-zen.net> writes:

> I have reviewed this document as part of the security directorate's 
> ongoing effort to review all IETF documents being processed by the 
> IESG.  These comments were written primarily for the benefit of the 
> security area directors.  Document editors and WG chairs should treat 
> these comments just like any other last call comments.

Thanks for your review Glen.  I am now merging your comments into the
document.

> GENERAL COMMENTS
> The reference to a document is not the document; for example, in the
> following excerpt from section 2, there are no names defined in the
> reference to RFC 2743:
>    The document uses many terms and function names defined in [RFC2743]
>    as updated by [RFC5554].
> Please change to something like
>    The document uses many terms and function names defined in RFC 2743
> [RFC2743]
>    as updated by RFC 5554 [RFC5554].
> Note that this comment applies globally to all such usages in the document.

I agree with Alexey, Pasi and Nico on this and we'll let the RFC Editor
handle this.

> ABSTRACT
> The last sentence of the Abstract says: "See
> <http://josefsson.org/sasl-gs2-*/> for more information."  Unless the
> referenced URL is intended to be permanently available (and probably even
> then), this line should be removed before publication as an RFC.

I have removed the link..  It was only to aid during development.

> SECTION 3
> Third paragraph, first sentence.
> Old:
>    If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2
>    implementation need some other mechanism to map mechanism OIDs to
>    SASL name internally.  In this case, the implementation can only
> New:
>    If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2
>    implementation needs some other mechanism to map mechanism OIDs to
>    SASL names internally.  In this case, the implementation can only

Fixed.

> SECTION 3.1
> s/characters outside of the base32 alphabet/characters outside of the Base32
> alphabet/

Fixed.

> SECTION 3.2
> s/This obliterate the need/This obliterates the need/

It now reads 'This eliminates the need'.

> The final sentence seems slightly clumsy; suggest the following change:
> Old:
>    The computed mechanism name can be used
>    directly in the implementation, and the implementation need not
>    concern itself with that the mechanism is part of a mechanism family.
> New:
>    The computed mechanism name can be used
>    directly in the implementation, and the implementation need not
>    be concerned if the mechanism is part of a mechanism family.

Fixed.

> SECTION 4
> In the fourth paragraph, s/As this indicate an error condition/As this
> indicates an error condition/

Fixed.

> In paragraph 5, "The [RFC2743] section 3.1 initial context token header" has
> the sound of GSSAPI "code words" ;-).  Suggest changing to "The GSSAPIv2
> initial context token header (see section 3.1 of RFC 2743 [RFC2743])" or
> some such.

I agree with Nico's reply, so I avoided mentioning GSS*API at all here
and used this text:

    The initial context token header (see section 3.1 of [RFC2743]) MUST
    be removed if present.

> A similar comment pertains to the first paragraph on page 9; suggest:
> Old:
>    When the "gs2-nonstd-flag" flag is present, the client did not find/
>    remove a [RFC2743] section 3.1 token header from the initial token
>    returned by GSS_Init_sec_context.  This signals to the server that it
>    MUST NOT re-add the data that is normally removed by the client.
> New:
>    When the "gs2-nonstd-flag" flag is present, the client did not find/
>    remove a GSSAPIv2 token header (RFC 2743, section 3.1) from the initial
> token
>    returned by GSS_Init_sec_context.  This signals to the server that it
>    MUST NOT re-add the data that is normally removed by the client.

As before, I wanted to avoid using the term GSS*API here.  Instead the
text reads:

   When the "gs2-nonstd-flag" flag is present, the client did not find/
   remove a token header ([RFC2743] section 3.1) from the initial token
   returned by GSS_Init_sec_context.

> s/The NUL characters is forbidden/The NUL character is forbidden/

Fixed.

> s/Upon the receipt/Upon receipt/

Fixed.

> s/results in failed authentication exchange/results in a failed
> authentication exchange/

Fixed.

> SECTION 5
> I find this section rather difficult to understand: not all of the possible
> combinations of gs2-cb-flag and server support for channel bindings seem to
> be covered.  A table might help, if not for that the gs2-cb-flag is
> tri-valued & used to signal two different things.

I agree with Nico that I believe we cover all the cases in the text.
Can you point to which case is not covered?  However, for illustration,
I have added Nico's table.

> SECTION 5.1
> First sentence s/The calls to GSS_Init_sec_context and
> GSS_Accept_sec_context takes a/The calls to GSS_Init_sec_context and
> GSS_Accept_sec_context take a/

Fixed.

> SECTION 6
> This section needs a lot of work if it is expected to be understood by
> non-members of the Illuminati ;->.  Just one example (of many possible):
>
>    Example #3: a two round-trip GSS-API context token exchange, no
>    channel binding, no standard token header.
>
>          C: Request authentication exchange
>          S: Empty Challenge
>          C: F,n,,<initial context token without
>                              standard header>
>          S: Send reply context token as is
>          C: Send reply context token as is
>          S: Send reply context token as is
>          C: Empty message
>          S: Outcome of authentication exchange
>
> What does this mean?  What do 'F' & 'n' stand for?  How is it useful?  It
> might be claimed that these questions could be answered by dissecting the
> ABNF for the gs2 header, but I don't think that's a good answer: examples
> should be self-contained.

I agree with Nico that we shouldn't explain this again in the example
section: the meaning of the protocol messages are explained elsewhere in
the document already.

We could use complete verbatim example exchanges though, but they will
be somewhat large due to the unrelated GSS-API tokens which aren't GS2
specific.

> SECTION 8
>
> The first paragraph says:
>
>    GS2 does not use any GSS-API per-message tokens.  Therefore the
>    setting of req_flags related to per-message tokens is irrelevant.
>
> OK, but what should the client and server behavior should be WRT the flags?

It now reads:

   GS2 does not use any GSS-API per-message tokens.  Therefore the per-
   message token ret_flags from GSS_Init_sec_context() and
   GSS_Accept_sec_context() are irrelevant; implementations SHOULD NOT
   set the per-message req_flags.

> SECTION 14.1
> Old:
>    If a client implement GSS-API mechanism X, potentially negotiated
>    through a GSS-API mechanism Y, and the server also implement GSS-API
>    mechanism X negotiated through a GSS-API mechanism Z, the
>    authentication negotiation will fail.
> New:
>    If a client implements GSS-API mechanism X, potentially negotiated
>    through a GSS-API mechanism Y, and the server also implements GSS-API
>    mechanism X negotiated through a GSS-API mechanism Z, the
>    authentication negotiation will fail.

Fixed.

> SECTION 14.2
>
> s/use of GSS-API mechanisms that negotiate other mechanisms are/use of
> GSS-API mechanisms that negotiate other mechanisms is/

Fixed.

Thanks again,
/Simon

From simon@josefsson.org  Fri Jan  8 04:49:59 2010
Return-Path: <simon@josefsson.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C55913A6958; Fri,  8 Jan 2010 04:49:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level: 
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlKtogZAA9gU; Fri,  8 Jan 2010 04:49:59 -0800 (PST)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id A0A313A68A0; Fri,  8 Jan 2010 04:49:58 -0800 (PST)
Received: from mocca (c80-216-24-99.bredband.comhem.se [80.216.24.99]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id o08CnrfR009416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 8 Jan 2010 13:49:55 +0100
From: Simon Josefsson <simon@josefsson.org>
To: Nicolas Williams <Nicolas.Williams@sun.com>
References: <000001ca6a19$665b3320$33119960$@net> <20091123165233.GJ773@Sun.COM>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:100108:iesg@ietf.org::obzvswTmjE55bmxQ:q7q
X-Hashcash: 1:22:100108:secdir@ietf.org::Nh/bQJtKl7AzIZuq:1xtV
X-Hashcash: 1:22:100108:gwz@net-zen.net::Wdt6YuxOurO3KO2J:4vk+
X-Hashcash: 1:22:100108:nicolas.williams@sun.com::L9oY6Aahv3bar4st:5Nwm
X-Hashcash: 1:22:100108:tlyu@mit.edu::mPO/1yu2KI6idTWX:BWXf
X-Hashcash: 1:22:100108:alexey.melnikov@isode.com::FTh+6Dfrlweu6w9X:B77q
X-Hashcash: 1:22:100108:kurt.zeilenga@isode.com::obp1fQLyrZKhUUty:vNit
Date: Fri, 08 Jan 2010 13:49:53 +0100
In-Reply-To: <20091123165233.GJ773@Sun.COM> (Nicolas Williams's message of "Mon, 23 Nov 2009 10:52:34 -0600")
Message-ID: <87fx6g7ocu.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: clamav-milter 0.95.3 at yxa-v
X-Virus-Status: Clean
X-Mailman-Approved-At: Fri, 08 Jan 2010 04:52:25 -0800
Cc: secdir@ietf.org, 'Kurt Zeilenga' <Kurt.Zeilenga@Isode.com>, iesg@ietf.org, 'Alexey Melnikov' <alexey.melnikov@Isode.com>
Subject: Re: [secdir] secdir review of draft-ietf-sasl-gs2-17
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jan 2010 12:49:59 -0000

Nicolas Williams <Nicolas.Williams@sun.com> writes:

>> SECTION 5
>> I find this section rather difficult to understand: not all of the possible
>> combinations of gs2-cb-flag and server support for channel bindings seem to
>> be covered.  A table might help, if not for that the gs2-cb-flag is
>> tri-valued & used to signal two different things.
>
> I believe we handled all cases.  There are three flag values and two
> server support alternatives.  I suppose we can add a table, something
> like:
>
>     FLAG	SERVER CB SUPPORT	DISPOSITION
>     ----	-----------------	-----------
>
>     n		Irrelevant		If server disallows non-channel-
>                                         bound authentication, then fail
>
>     y		CB not supported	Authentication may succeed
>
>     y		CB supported		Authentication must fail
>
>     p		CB supported		Authentication may succeed, with
>                                         CB used
>
>     p		CB not supported	Authentication will fail
>
>     <none>	CB not supported	Client does not even try because
>                                         it insists on CB

I have added this table to section 5.

>> The first paragraph says:
>> 
>>    GS2 does not use any GSS-API per-message tokens.  Therefore the
>>    setting of req_flags related to per-message tokens is irrelevant.
>> 
>> OK, but what should the client and server behavior should be WRT the flags?
>
> There's no actual behavior w.r.t. req_flags and ret_flags.  The GSS-API
> mechanism is free to enable per-msg token features not requested by the
> caller, but they are truly irrelevant: the application won't be using
> per-msg tokens.  It may make things simpler if we explicitly require
> that req_flags not be set:
>
>    GS2 does not use any GSS-API per-message tokens.  Therefore the
>    per-message token ret_flags from GSS_Init_sec_context() and
>    GSS_Accept_sec_context() are irrelevant; implementations SHOULD NOT
>    set the per-message req_flags.

This is in the document now too.

Thanks,
Simon

From kent@bbn.com  Fri Jan  8 06:08:00 2010
Return-Path: <kent@bbn.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63F343A6862 for <secdir@core3.amsl.com>; Fri,  8 Jan 2010 06:08:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNCcVJYV52xG for <secdir@core3.amsl.com>; Fri,  8 Jan 2010 06:07:59 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 3B6313A67B5 for <secdir@ietf.org>; Fri,  8 Jan 2010 06:07:59 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from <kent@bbn.com>) id 1NTFV8-0003vG-9v; Fri, 08 Jan 2010 09:07:42 -0500
Mime-Version: 1.0
Message-Id: <p06240818c76c1a38cbf8@[128.89.89.161]>
In-Reply-To: <20100107222809.GA25747@shinkuro.com>
References: <p06240810c76be77be756@[128.89.89.161]> <20100107222809.GA25747@shinkuro.com>
Date: Fri, 8 Jan 2010 09:07:24 -0500
To: Andrew Sullivan <ajs@shinkuro.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary="============_-949162835==_ma============"
Cc: Ralph Droms <rdroms@cisco.com>, dol@cryptocom.ru, ogud@ogud.com, secdir@ietf.org
Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jan 2010 14:08:00 -0000

--============_-949162835==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Andrew,

I think the arguments I made are not so tightly related to the 
question of the ability of the protocols in question to negotiate 
algorithms, but I do appreciate the questions you posed.

You are correct that IPsec peers and TLS clients & servers perform a 
negotiation prior to establishing a session or secruity association. 
However, TLS is the most widely deployed and used crypto protocol in 
large part because the set of algorithms that MUST be supported to 
ensure very wide interoperability is very small, despite the fact 
that many algorithms have been defined to use with TLS.

For S/MIME and OPGP there is a requirement that, ultimately, the 
receiver has some way to verify the cert associated with the sender. 
However, it is common for senders to sign messages that are send to 
mailing lists where the sender has no way of knowing what algorithms 
all the receivers support. So, your analysis for this case is off the 
mark. (Your analysis is applicable to the case of encrypted e-mail, 
because the sender has to retrieve certs for all recipients first, 
and thus can determine what algorithms, they support. But, signed 
e-mail is MUCH more common than encrypted e-mail in the public 
Internet.)

I understand the arguments you are making, and I agree that there are 
differences between protocols that may be used in closed communities 
vs. ones that are intended to have global scope, like DNSSEC. But, I 
think the argument I made is valid.

My point is that it is unreasonable to require every DNSSEC 
implementation to support every public key signature and hash 
algorithm that anybody chooses to register. This is a classic case of 
what economists call externalization of costs. By calling for such 
support for any national algorithm suite (or any algorithms that 
might be put forth and which are not widely employed), one 
establishes a bad precedent. Rather it makes sense to have a very 
limited number of algorithm suites that MUST (or SHOULD) be 
implemented. My recommendation is to limit mandated (MUST or SHOULD) 
support to just two: current and next.

BTW, we have had this discussion in SIDR, where the RPKI has a 
similar global scope and where Vasily had made a similar request for 
recognition of GOST algorithms. So far, that WG has said no, for the 
reasons I cited in my comments and above. The current plan there is 
to go with the two suite model I described above.

Steve
--============_-949162835==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: review of
draft-ietf-dnsext-dnssec-gost-05</title></head><body>
<div>Andrew,</div>
<div><br></div>
<div>I think the arguments I made are not so tightly related to the
question of the ability of the protocols in question to negotiate
algorithms, but I do appreciate the questions you posed.</div>
<div><br></div>
<div>You are correct that IPsec peers and TLS clients &amp; servers
perform a negotiation prior to establishing a session or secruity
association. However, TLS is the most widely deployed and used crypto
protocol in large part because the set of algorithms that MUST be
supported to ensure very wide interoperability is very small, despite
the fact that many algorithms have been defined to use with TLS.</div>
<div><br></div>
<div>For S/MIME and OPGP there is a requirement that, ultimately, the
receiver has some way to verify the cert associated with the sender.
However, it is common for senders to sign messages that are send to
mailing lists where the sender has no way of knowing what algorithms
all the receivers support. So, your analysis for this case is off the
mark. (Your analysis is applicable to the case of encrypted e-mail,
because the sender has to retrieve certs for all recipients first, and
thus can determine what algorithms, they support. But, signed e-mail
is MUCH more common than encrypted e-mail in the public
Internet.)</div>
<div><br></div>
<div>I understand the arguments you are making, and I agree that there
are differences between protocols that may be used in closed
communities vs. ones that are intended to have global scope, like
DNSSEC. But, I think the argument I made is valid.</div>
<div><br></div>
<div>My point is that it is unreasonable to require<u> every</u>
DNSSEC implementation to support<u> every</u> public key signature and
hash algorithm that anybody chooses to register. This is a classic
case of what economists call externalization of costs. By calling for
such support for<u> any</u> national algorithm suite (or any
algorithms that might be put forth and which are not widely employed),
one establishes a bad precedent. Rather it makes sense to have a very
limited number of algorithm suites that MUST (or SHOULD) be
implemented. My recommendation is to limit mandated (MUST or SHOULD)
support to just two: current and next.</div>
<div><br></div>
<div>BTW, we have had this discussion in SIDR, where the RPKI has a
similar global scope and where Vasily had made a similar request for
recognition of GOST algorithms. So far, that WG has said no, for the
reasons I cited in my comments and above. The current plan there is to
go with the two suite model I described above.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-949162835==_ma============--

From ajs@shinkuro.com  Fri Jan  8 06:44:36 2010
Return-Path: <ajs@shinkuro.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F4E73A6979 for <secdir@core3.amsl.com>; Fri,  8 Jan 2010 06:44:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.985
X-Spam-Level: 
X-Spam-Status: No, score=-2.985 tagged_above=-999 required=5 tests=[AWL=-0.386, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSDv14qzm1Md for <secdir@core3.amsl.com>; Fri,  8 Jan 2010 06:44:35 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 8FAB03A6970 for <secdir@ietf.org>; Fri,  8 Jan 2010 06:44:35 -0800 (PST)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id DEE702FE8CA1; Fri,  8 Jan 2010 14:44:32 +0000 (UTC)
Date: Fri, 8 Jan 2010 09:44:31 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: Stephen Kent <kent@bbn.com>
Message-ID: <20100108144431.GB26259@shinkuro.com>
References: <p06240810c76be77be756@[128.89.89.161]> <20100107222809.GA25747@shinkuro.com> <p06240818c76c1a38cbf8@[128.89.89.161]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p06240818c76c1a38cbf8@[128.89.89.161]>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: Ralph Droms <rdroms@cisco.com>, dol@cryptocom.ru, ogud@ogud.com, secdir@ietf.org
Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jan 2010 14:44:36 -0000

On Fri, Jan 08, 2010 at 09:07:24AM -0500, Stephen Kent wrote:
>
> For S/MIME and OPGP there is a requirement that, ultimately, the  
> receiver has some way to verify the cert associated with the sender.  
> However, it is common for senders to sign messages that are send to  
> mailing lists where the sender has no way of knowing what algorithms all 
> the receivers support. So, your analysis for this case is off the mark. 

This is a good point.  Thanks.

> Rather it makes sense to have a very limited number of algorithm suites 
> that MUST (or SHOULD) be implemented. My recommendation is to limit 
> mandated (MUST or SHOULD) support to just two: current and next.

Hrm.  Well, we already violate this recommendation, I think, but I
take your point.

> BTW, we have had this discussion in SIDR, where the RPKI has a similar 
> global scope and where Vasily had made a similar request for recognition 
> of GOST algorithms. So far, that WG has said no, for the reasons I cited 
> in my comments and above. The current plan there is to go with the two 
> suite model I described above.

Ok.  Thanks for this; it's useful feedback.

Best,

A

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.

From phoffman@imc.org  Fri Jan  8 08:13:15 2010
Return-Path: <phoffman@imc.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6497B28C10E for <secdir@core3.amsl.com>; Fri,  8 Jan 2010 08:13:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.046
X-Spam-Level: 
X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HttUNxjGY3vD for <secdir@core3.amsl.com>; Fri,  8 Jan 2010 08:13:09 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 01B413A677C for <secdir@ietf.org>; Fri,  8 Jan 2010 08:13:07 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o08GCVAw020420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jan 2010 09:12:33 -0700 (MST) (envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06240812c76d0821dd1b@[10.20.30.158]>
In-Reply-To: <20100108144431.GB26259@shinkuro.com>
References: <p06240810c76be77be756@[128.89.89.161]> <20100107222809.GA25747@shinkuro.com> <p06240818c76c1a38cbf8@[128.89.89.161]> <20100108144431.GB26259@shinkuro.com>
Date: Fri, 8 Jan 2010 08:12:29 -0800
To: Andrew Sullivan <ajs@shinkuro.com>, Stephen Kent <kent@bbn.com>
From: Paul Hoffman <phoffman@imc.org>
Content-Type: text/plain; charset="us-ascii"
Cc: secdir@ietf.org, dol@cryptocom.ru, ogud@ogud.com, Ralph Droms <rdroms@cisco.com>
Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jan 2010 16:13:15 -0000

To take it one step further: a signing algorithm that is easily broken opens up a new attack vector. Imagine that all DNSSEC "client" implementations (resolvers) need to support two algorithms, A and B. If A and B are of actual equal strength, an attacker has an equal problem. However, if B is found to have weaknesses that allows an attacker to forge signatures, that attacker then can create a bogus chain to a trust anchor using B in the entire path.

It is for this reason that DNSSEC does not, for example, require that resolvers MUST be able to validate RSA signatures with 256-bit keys. However, by saying that resolvers MUST be able to validate anything other than the widely-agreed-to algorithms, you are opening up such an attack.

GOST signatures use a hash algorithm that has a known academic attack. Thus, even if the GOST asymmetric encryption algorithm is as strong as RSA with the size of keys that people are using, the overall signing algorithm may be weaker. This is *not* an argument that Russia should not use GOST: they have made their own security decisions based on the same knowledge that we have (and possibly more). It is, however, an argument against making everyone else be able to verify GOST signatures as if they were equivalent to other mandatory-to-implement signature algorithms.

From uri@mit.edu  Fri Jan  8 08:45:51 2010
Return-Path: <uri@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 603683A67FE for <secdir@core3.amsl.com>; Fri,  8 Jan 2010 08:45:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiL96uCxDybA for <secdir@core3.amsl.com>; Fri,  8 Jan 2010 08:45:50 -0800 (PST)
Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by core3.amsl.com (Postfix) with ESMTP id 7488A3A67AE for <secdir@ietf.org>; Fri,  8 Jan 2010 08:45:50 -0800 (PST)
X-AuditID: 1209190d-b7b0fae000000ead-aa-4b47613cb2d9
Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by dmz-mailsec-scanner-2.mit.edu (Symantec Brightmail Gateway) with SMTP id F2.FA.03757.C31674B4; Fri,  8 Jan 2010 11:45:48 -0500 (EST)
Received: from outgoing-legacy.mit.edu (OUTGOING-LEGACY.MIT.EDU [18.7.22.104]) by central-city-carrier-station.mit.edu (8.13.6/8.9.2) with ESMTP id o08GkXTY007589 for <secdir@ietf.org>; Fri, 8 Jan 2010 11:46:38 -0500 (EST)
Received: from webmail-7.mit.edu (WEBMAIL-7.MIT.EDU [18.9.23.17]) ) by outgoing-legacy.mit.edu (8.13.6/8.12.4) with ESMTP id o08GjYOj008979 for <secdir@ietf.org>; Fri, 8 Jan 2010 11:45:39 -0500 (EST)
Received: from webmail-7.mit.edu (webmail-7.mit.edu [127.0.0.1]) by webmail-7.mit.edu (8.13.8) with ESMTP id o08GZTVO016533; Fri, 8 Jan 2010 11:35:29 -0500
Received: (from nobody@localhost) by webmail-7.mit.edu (8.13.8/8.13.8/Submit) id o08GZSHp016529 for secdir@ietf.org; Fri, 8 Jan 2010 11:35:28 -0500
X-Authentication-Warning: webmail-7.mit.edu: nobody set sender to uri@mit.edu using -f
Received: from c-24-62-224-140.hsd1.ma.comcast.net (c-24-62-224-140.hsd1.ma.comcast.net [24.62.224.140]) (User authenticated as uri@ATHENA.MIT.EDU) by webmail.mit.edu (Horde MIME library) with HTTP; Fri, 08 Jan 2010 11:35:28 -0500
Message-ID: <20100108113528.gbmbl95nok8gsgwc@webmail.mit.edu>
X-Priority: 3 (Normal)
Date: Fri, 08 Jan 2010 11:35:28 -0500
From: Uri Blumenthal <uri@MIT.EDU>
To: secdir@ietf.org
References: <p06240810c76be77be756@[128.89.89.161]> <20100107222809.GA25747@shinkuro.com> <p06240818c76c1a38cbf8@[128.89.89.161]> <20100108144431.GB26259@shinkuro.com> <p06240812c76d0821dd1b@[10.20.30.158]>
In-Reply-To: <p06240812c76d0821dd1b@[10.20.30.158]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.0.3)
X-Scanned-By: MIMEDefang 2.42
X-Brightmail-Tracker: AAAAAxJXwFoSV8E+ElfC1g==
Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jan 2010 16:45:51 -0000

I am in full agreement with the arguments Paul and Steve have made.

Keep GOST as MAY.

Quoting Paul Hoffman <phoffman@imc.org>:
> To take it one step further: a signing algorithm that is easily 
> broken opens up a new attack vector. Imagine that all DNSSEC "client" 
> implementations (resolvers) need to support two algorithms, A and B. 
> If A and B are of actual equal strength, an attacker has an equal 
> problem. However, if B is found to have weaknesses that allows an 
> attacker to forge signatures, that attacker then can create a bogus 
> chain to a trust anchor using B in the entire path.
>
> It is for this reason that DNSSEC does not, for example, require that 
> resolvers MUST be able to validate RSA signatures with 256-bit keys. 
> However, by saying that resolvers MUST be able to validate anything 
> other than the widely-agreed-to algorithms, you are opening up such 
> an attack.
>
> GOST signatures use a hash algorithm that has a known academic 
> attack. Thus, even if the GOST asymmetric encryption algorithm is as 
> strong as RSA with the size of keys that people are using, the 
> overall signing algorithm may be weaker. This is *not* an argument 
> that Russia should not use GOST: they have made their own security 
> decisions based on the same knowledge that we have (and possibly 
> more). It is, however, an argument against making everyone else be 
> able to verify GOST signatures as if they were equivalent to other 
> mandatory-to-implement signature algorithms.
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
>



From ajs@shinkuro.com  Fri Jan  8 10:22:27 2010
Return-Path: <ajs@shinkuro.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 405523A689A for <secdir@core3.amsl.com>; Fri,  8 Jan 2010 10:22:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.157
X-Spam-Level: 
X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MizV31DozpL4 for <secdir@core3.amsl.com>; Fri,  8 Jan 2010 10:22:25 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 6964E3A688D for <secdir@ietf.org>; Fri,  8 Jan 2010 10:22:25 -0800 (PST)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id DD1542FE8CA1; Fri,  8 Jan 2010 18:22:20 +0000 (UTC)
Date: Fri, 8 Jan 2010 13:22:19 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: Paul Hoffman <phoffman@imc.org>
Message-ID: <20100108182219.GN26259@shinkuro.com>
References: <p06240810c76be77be756@[128.89.89.161]> <20100107222809.GA25747@shinkuro.com> <p06240818c76c1a38cbf8@[128.89.89.161]> <20100108144431.GB26259@shinkuro.com> <p06240812c76d0821dd1b@[10.20.30.158]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p06240812c76d0821dd1b@[10.20.30.158]>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: secdir@ietf.org, dol@cryptocom.ru, ogud@ogud.com, Ralph Droms <rdroms@cisco.com>
Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jan 2010 18:22:27 -0000

On Fri, Jan 08, 2010 at 08:12:29AM -0800, Paul Hoffman wrote:

> It is for this reason that DNSSEC does not, for example, require
> that resolvers MUST be able to validate RSA signatures with 256-bit
> keys. However, by saying that resolvers MUST be able to validate
> anything other than the widely-agreed-to algorithms, you are opening
> up such an attack.

Now, this is an interesting point.  I think if one combines this
argument with Steve's point that a certain baseline of mandatory
algorithms should be required _only_ because you need some common set
for interoperability, one has a pretty good argument that most
algorithms should be MAYs and not stronger.

Thanks,

A

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.

From phoffman@imc.org  Fri Jan  8 10:37:01 2010
Return-Path: <phoffman@imc.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58CC13A68A6 for <secdir@core3.amsl.com>; Fri,  8 Jan 2010 10:37:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.046
X-Spam-Level: 
X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RgV4IwsSqF4 for <secdir@core3.amsl.com>; Fri,  8 Jan 2010 10:37:00 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 844A13A688C for <secdir@ietf.org>; Fri,  8 Jan 2010 10:37:00 -0800 (PST)
Received: from [10.20.30.158] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o08Iana9028426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Jan 2010 11:36:50 -0700 (MST) (envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06240824c76d2b183957@[10.20.30.158]>
In-Reply-To: <20100108182219.GN26259@shinkuro.com>
References: <p06240810c76be77be756@[128.89.89.161]> <20100107222809.GA25747@shinkuro.com> <p06240818c76c1a38cbf8@[128.89.89.161]> <20100108144431.GB26259@shinkuro.com> <p06240812c76d0821dd1b@[10.20.30.158]> <20100108182219.GN26259@shinkuro.com>
Date: Fri, 8 Jan 2010 10:36:48 -0800
To: Andrew Sullivan <ajs@shinkuro.com>
From: Paul Hoffman <phoffman@imc.org>
Content-Type: text/plain; charset="us-ascii"
Cc: secdir@ietf.org, dol@cryptocom.ru, ogud@ogud.com, Ralph Droms <rdroms@cisco.com>
Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jan 2010 18:37:01 -0000

At 1:22 PM -0500 1/8/10, Andrew Sullivan wrote:
>On Fri, Jan 08, 2010 at 08:12:29AM -0800, Paul Hoffman wrote:
>
>> It is for this reason that DNSSEC does not, for example, require
>> that resolvers MUST be able to validate RSA signatures with 256-bit
>> keys. However, by saying that resolvers MUST be able to validate
>> anything other than the widely-agreed-to algorithms, you are opening
>> up such an attack.
>
>Now, this is an interesting point.

Thank you. However, it is far from original.

>I think if one combines this
>argument with Steve's point that a certain baseline of mandatory
>algorithms should be required _only_ because you need some common set
>for interoperability, one has a pretty good argument that most
>algorithms should be MAYs and not stronger.

Bingo. If there is an algorithm that the technical community thinks is the "next" mandatory algorithm, you might want to make it "SHOULD+", but even that proposal is not always clear-cut.

<cue the peanut gallery>

From mcgrew@cisco.com  Fri Jan  8 13:10:18 2010
Return-Path: <mcgrew@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 659D43A687C for <secdir@core3.amsl.com>; Fri,  8 Jan 2010 13:10:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id au48YUPWRvO9 for <secdir@core3.amsl.com>; Fri,  8 Jan 2010 13:10:17 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 64B1D3A686B for <secdir@ietf.org>; Fri,  8 Jan 2010 13:10:17 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEALstR0urR7H+/2dsb2JhbADBPpQKgjmBdgQ
X-IronPort-AV: E=Sophos;i="4.49,244,1262563200"; d="scan'208";a="463875566"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 08 Jan 2010 21:10:15 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o08LAFbK011166 for <secdir@ietf.org>; Fri, 8 Jan 2010 21:10:15 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 8 Jan 2010 13:10:15 -0800
Received: from [10.32.254.210] ([10.32.254.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 8 Jan 2010 13:10:15 -0800
Message-Id: <566303C7-A4F9-48B2-93E4-3F16FA394430@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: secdir@ietf.org
In-Reply-To: <20100108113528.gbmbl95nok8gsgwc@webmail.mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
X-Priority: 3 (Normal)
Date: Fri, 8 Jan 2010 13:10:14 -0800
References: <p06240810c76be77be756@[128.89.89.161]> <20100107222809.GA25747@shinkuro.com> <p06240818c76c1a38cbf8@[128.89.89.161]> <20100108144431.GB26259@shinkuro.com> <p06240812c76d0821dd1b@[10.20.30.158]> <20100108113528.gbmbl95nok8gsgwc@webmail.mit.edu>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 08 Jan 2010 21:10:15.0431 (UTC) FILETIME=[F9421970:01CA90A6]
Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jan 2010 21:10:18 -0000

I also agree with the compelling reasons that Steve and Paul have  
articulated.

I'm confused about one point, though.  The IANA considerations section  
in draft-ietf-dnsext-dnssec-gost-06 asks for GOST R 34.10-2001 and  
GOST R 34.11-94 to be registered as OPTIONAL.  Was there some  
suggestion to make them mandatory?

David

On Jan 8, 2010, at 8:35 AM, Uri Blumenthal wrote:

> I am in full agreement with the arguments Paul and Steve have made.
>
> Keep GOST as MAY.
>
> Quoting Paul Hoffman <phoffman@imc.org>:
>> To take it one step further: a signing algorithm that is easily  
>> broken opens up a new attack vector. Imagine that all DNSSEC  
>> "client" implementations (resolvers) need to support two  
>> algorithms, A and B. If A and B are of actual equal strength, an  
>> attacker has an equal problem. However, if B is found to have  
>> weaknesses that allows an attacker to forge signatures, that  
>> attacker then can create a bogus chain to a trust anchor using B in  
>> the entire path.
>>
>> It is for this reason that DNSSEC does not, for example, require  
>> that resolvers MUST be able to validate RSA signatures with 256-bit  
>> keys. However, by saying that resolvers MUST be able to validate  
>> anything other than the widely-agreed-to algorithms, you are  
>> opening up such an attack.
>>
>> GOST signatures use a hash algorithm that has a known academic  
>> attack. Thus, even if the GOST asymmetric encryption algorithm is  
>> as strong as RSA with the size of keys that people are using, the  
>> overall signing algorithm may be weaker. This is *not* an argument  
>> that Russia should not use GOST: they have made their own security  
>> decisions based on the same knowledge that we have (and possibly  
>> more). It is, however, an argument against making everyone else be  
>> able to verify GOST signatures as if they were equivalent to other  
>> mandatory-to-implement signature algorithms.
>> _______________________________________________
>> secdir mailing list
>> secdir@ietf.org
>> https://www.ietf.org/mailman/listinfo/secdir
>>
>
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir


From Nicolas.Williams@sun.com  Fri Jan  8 13:35:17 2010
Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 343AD3A68DE for <secdir@core3.amsl.com>; Fri,  8 Jan 2010 13:35:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.046
X-Spam-Level: 
X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9hJGeThTYVS for <secdir@core3.amsl.com>; Fri,  8 Jan 2010 13:35:16 -0800 (PST)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id E94A43A686B for <secdir@ietf.org>; Fri,  8 Jan 2010 13:35:15 -0800 (PST)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o08LZDJB020051 for <secdir@ietf.org>; Fri, 8 Jan 2010 21:35:13 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id o08LZD1N054482 for <secdir@ietf.org>; Fri, 8 Jan 2010 14:35:13 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id o08LKEfT001384; Fri, 8 Jan 2010 15:20:14 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id o08LKDpi001383;  Fri, 8 Jan 2010 15:20:13 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Fri, 8 Jan 2010 15:20:13 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: David McGrew <mcgrew@cisco.com>
Message-ID: <20100108212013.GC1061@Sun.COM>
References: <p06240810c76be77be756@[128.89.89.161]> <20100107222809.GA25747@shinkuro.com> <p06240818c76c1a38cbf8@[128.89.89.161]> <20100108144431.GB26259@shinkuro.com> <p06240812c76d0821dd1b@[10.20.30.158]> <20100108113528.gbmbl95nok8gsgwc@webmail.mit.edu> <566303C7-A4F9-48B2-93E4-3F16FA394430@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <566303C7-A4F9-48B2-93E4-3F16FA394430@cisco.com>
User-Agent: Mutt/1.5.7i
Cc: secdir@ietf.org
Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jan 2010 21:35:17 -0000

On Fri, Jan 08, 2010 at 01:10:14PM -0800, David McGrew wrote:
> I also agree with the compelling reasons that Steve and Paul have  
> articulated.

+1

> I'm confused about one point, though.  The IANA considerations section  
> in draft-ietf-dnsext-dnssec-gost-06 asks for GOST R 34.10-2001 and  
> GOST R 34.11-94 to be registered as OPTIONAL.  Was there some  
> suggestion to make them mandatory?

"
6.1.  Support for GOST signatures

   DNSSEC aware implementations SHOULD be able to support RRSIG and
   DNSKEY resource records created with the GOST algorithms as
   defined in this document.
...
8.  IANA Considerations
...
                                     Zone    Trans.
   Value  Algorithm         Mnemonic Signing Sec.  References   Status
   {TBA1} GOST R 34.10-2001 GOST     Y       *     (this memo)  OPTIONAL
...
   Value   Algorithm        Status
   {TBA2}  GOST R 34.11-94  OPTIONAL
"

Section 6.1 and 8 are in conflict.

Nico
-- 

From weiler+secdir@watson.org  Sat Jan  9 07:37:00 2010
Return-Path: <weiler+secdir@watson.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CF763A68CF for <secdir@core3.amsl.com>; Sat,  9 Jan 2010 07:37:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHglOLFSV-IK for <secdir@core3.amsl.com>; Sat,  9 Jan 2010 07:36:59 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 4D3013A68D6 for <secdir@ietf.org>; Sat,  9 Jan 2010 07:36:58 -0800 (PST)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o09FauBm082758 for <secdir@ietf.org>; Sat, 9 Jan 2010 10:36:56 -0500 (EST) (envelope-from weiler+secdir@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o09FatxU082755 for <secdir@ietf.org>; Sat, 9 Jan 2010 10:36:55 -0500 (EST) (envelope-from weiler+secdir@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Sat, 9 Jan 2010 10:36:55 -0500 (EST)
From: Samuel Weiler <weiler+secdir@watson.org>
X-X-Sender: weiler@fledge.watson.org
To: secdir@ietf.org
Message-ID: <alpine.BSF.2.00.1001091032310.77827@fledge.watson.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Sat, 09 Jan 2010 10:36:56 -0500 (EST)
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: secdir-secretary@mit.edu
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Jan 2010 15:37:00 -0000

Carl Wallance is next in the rotation.

Documents on the telechat agenda typically have a last call end date 
before the date shown below; reviews by the end of last call are 
typically more appreciated by the doc editors.

Review instructions and related resources are at:
       http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

-- Sam

For telechat 2010-01-21

Reviewer                 Deadline   Draft
Eric Rescorla          T 2010-01-19 draft-gennai-smime-cnipa-pec-05
Joe Salowey            T 2010-01-19 draft-ietf-pana-preauth-08
Stefan Santesson       T 2010-01-19 draft-ietf-trill-rbridge-protocol-14
Larry Zhu              TR2010-01-19 draft-moriarty-post-inch-rid-09

Last calls and special requests:

Reviewer                 Deadline   Draft
Rob Austein              2009-11-28 draft-ietf-pkix-attr-cert-mime-type-02
Richard Barnes           None       draft-ietf-dnsext-dnssec-gost-06
Dave Cridland            2009-11-25 draft-ietf-nsis-qspec-22
Alan DeKok               2009-10-01 draft-ietf-enum-enumservices-transition-04
Alan DeKok               2009-12-07 draft-ietf-capwap-802dot11-mib-06
Love Hornquist-Astrand   2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05
Love Hornquist-Astrand   2009-10-13 draft-ietf-idnabis-mappings-05
Jeffrey Hutzelman        2009-12-07 draft-ietf-capwap-base-mib-07
David McGrew             None       draft-ietf-dnsext-dnssec-gost-06
Catherine Meadows        2008-01-17 draft-ietf-speechsc-mrcpv2-20
Catherine Meadows        2009-12-22 draft-ietf-sipping-config-framework-16
Russ Mundy               2009-10-21 draft-ietf-hokey-preauth-ps-11
Sandy Murphy            R2009-11-18 draft-ietf-mpls-mpls-and-gmpls-security-framework-07
Sandy Murphy             2010-01-14 draft-turner-ecprivatekey-02
Vidya Narayanan          2008-11-21 draft-ietf-sip-saml-06
Chris Newman             2010-01-07 draft-ietf-krb-wg-preauth-framework-15
Hilarie Orman            2010-01-14 draft-kato-tls-rfc4132bis-04
Eric Rescorla            2010-01-11 draft-brown-versioning-link-relations-05
Joe Salowey              2009-02-08 draft-ietf-geopriv-lis-discovery-13
Hannes Tschofenig        2010-02-05 draft-allbery-afs-srv-records-03
Tina TSOU                2010-02-01 draft-roach-sip-http-subscribe-06
Sean Turner              2010-02-01 draft-jabley-reverse-servers-01
Sam Weiler               2008-08-13 draft-chown-v6ops-rogue-ra-03
Brian Weis               2009-10-20 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05
Nico Williams            2008-08-13 draft-ietf-v6ops-ra-guard-04
Larry Zhu                2008-08-13 draft-thaler-v6ops-teredo-extensions-05
Larry Zhu                2009-05-09 draft-ietf-ecrit-location-hiding-req-02


From ekr@networkresonance.com  Sat Jan  9 08:54:34 2010
Return-Path: <ekr@networkresonance.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB8FE3A689B for <secdir@core3.amsl.com>; Sat,  9 Jan 2010 08:54:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.451
X-Spam-Level: 
X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[AWL=0.433,  BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888,  HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPX9nSq2RqfS for <secdir@core3.amsl.com>; Sat,  9 Jan 2010 08:54:34 -0800 (PST)
Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 2C9753A6846 for <secdir@ietf.org>; Sat,  9 Jan 2010 08:54:33 -0800 (PST)
Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 59F9C6CC90C; Sat,  9 Jan 2010 08:57:02 -0800 (PST)
Date: Sat, 09 Jan 2010 08:57:01 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Uri Blumenthal <uri@MIT.EDU>
In-Reply-To: <20100108113528.gbmbl95nok8gsgwc@webmail.mit.edu>
References: <p06240810c76be77be756@[128.89.89.161]> <20100107222809.GA25747@shinkuro.com> <p06240818c76c1a38cbf8@[128.89.89.161]> <20100108144431.GB26259@shinkuro.com> <p06240812c76d0821dd1b@[10.20.30.158]> <20100108113528.gbmbl95nok8gsgwc@webmail.mit.edu>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20100109165702.59F9C6CC90C@kilo.networkresonance.com>
Cc: secdir@ietf.org
Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Jan 2010 16:54:35 -0000

I agree as well.

-Ekr

At Fri, 08 Jan 2010 11:35:28 -0500,
Uri Blumenthal wrote:
> 
> I am in full agreement with the arguments Paul and Steve have made.
> 
> Keep GOST as MAY.
> 
> Quoting Paul Hoffman <phoffman@imc.org>:
> > To take it one step further: a signing algorithm that is easily 
> > broken opens up a new attack vector. Imagine that all DNSSEC "client" 
> > implementations (resolvers) need to support two algorithms, A and B. 
> > If A and B are of actual equal strength, an attacker has an equal 
> > problem. However, if B is found to have weaknesses that allows an 
> > attacker to forge signatures, that attacker then can create a bogus 
> > chain to a trust anchor using B in the entire path.
> >
> > It is for this reason that DNSSEC does not, for example, require that 
> > resolvers MUST be able to validate RSA signatures with 256-bit keys. 
> > However, by saying that resolvers MUST be able to validate anything 
> > other than the widely-agreed-to algorithms, you are opening up such 
> > an attack.
> >
> > GOST signatures use a hash algorithm that has a known academic 
> > attack. Thus, even if the GOST asymmetric encryption algorithm is as 
> > strong as RSA with the size of keys that people are using, the 
> > overall signing algorithm may be weaker. This is *not* an argument 
> > that Russia should not use GOST: they have made their own security 
> > decisions based on the same knowledge that we have (and possibly 
> > more). It is, however, an argument against making everyone else be 
> > able to verify GOST signatures as if they were equivalent to other 
> > mandatory-to-implement signature algorithms.
> > _______________________________________________
> > secdir mailing list
> > secdir@ietf.org
> > https://www.ietf.org/mailman/listinfo/secdir
> >
> 
> 
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir

From stefan@aaa-sec.com  Sun Jan 10 20:45:37 2010
Return-Path: <stefan@aaa-sec.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D81A28C124 for <secdir@core3.amsl.com>; Sun, 10 Jan 2010 20:45:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.251
X-Spam-Level: 
X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[AWL=-1.998, BAYES_50=0.001, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0Y3ZZ1quIEi for <secdir@core3.amsl.com>; Sun, 10 Jan 2010 20:45:36 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.114]) by core3.amsl.com (Postfix) with ESMTP id 85D4228C125 for <secdir@ietf.org>; Sun, 10 Jan 2010 20:45:35 -0800 (PST)
Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 3B4FD2BB274 for <secdir@ietf.org>; Mon, 11 Jan 2010 00:28:55 +0100 (CET)
Received: (qmail 76672 invoked from network); 10 Jan 2010 23:28:46 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO MacBookPro-6.local) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s29.loopia.se (qmail-ldap-1.03) with SMTP for <iesg@ietf.org>; 10 Jan 2010 23:28:46 -0000
Received: from [127.0.0.1] by MacBookPro-6.local (PGP Universal service); Mon, 11 Jan 2010 00:28:46 +0100
X-PGP-Universal: processed; by MacBookPro-6.local on Mon, 11 Jan 2010 00:28:46 +0100
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Mon, 11 Jan 2010 00:28:44 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: <iesg@ietf.org>, <secdir@ietf.org>, Radia Perlman <Radia.Perlman@sun.com>, Donald Eastlake <d3e3e3@gmail.com>, Dinesh Dutt <ddutt@cisco.com>, Silvano Gai <sgai@cisco.com>, Anoop Ghanwani <anoop@brocade.com>, Erik Nordmark <erik.nordmark@sun.com>, Ralph Droms <rdroms@cisco.com>
Message-ID: <C770213C.7A2C%stefan@aaa-sec.com>
Thread-Topic: secdir review of draft-ietf-trill-rbridge-protocol-14
Thread-Index: AcqSTKZg2dMzVp1nQUGj/T06wjBEeA==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3346014525_17267650"
Subject: [secdir] secdir review of draft-ietf-trill-rbridge-protocol-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jan 2010 04:45:37 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3346014525_17267650
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

I have limited my review to security related issues and whether the document
have a reasonable security considerations section.
I have not reviewed the technical content of the document.

The document seems sound form a security perspective. The security
considerations section is clear on the fact layer 2 bridging is not
inherently secure but appears to make a reasonable job at describing
guidance on how to address various security issues related to this protocol.

I find no major issues that the security ADs should be aware of.

/Stefan 

--B_3346014525_17267650
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>secdir review of draft-ietf-trill-rbridge-protocol-14</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>I have reviewed this document as part of the security directorate's ongoin=
g effort to review all IETF documents being processed by the IESG. &nbsp;The=
se comments were written primarily for the benefit of the security area dire=
ctors. &nbsp;Document editors and WG chairs should treat these comments just=
 like any other last call comments.<BR>
<BR>
I have limited my review to security related issues and whether the documen=
t have a reasonable security considerations section.<BR>
I have not reviewed the technical content of the document.<BR>
<BR>
The document seems sound form a security perspective. The security consider=
ations section is clear on the fact layer 2 bridging is not inherently secur=
e but appears to make a reasonable job at describing guidance on how to addr=
ess various security issues related to this protocol.<BR>
<BR>
I find no major issues that the security ADs should be aware of.<BR>
<BR>
/Stefan </SPAN></FONT>
</BODY>
</HTML>


--B_3346014525_17267650--



From hilarie@purplestreak.com  Sun Jan 10 22:31:27 2010
Return-Path: <hilarie@purplestreak.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30F4B3A6902 for <secdir@core3.amsl.com>; Sun, 10 Jan 2010 22:31:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpI3CbQ4wJOD for <secdir@core3.amsl.com>; Sun, 10 Jan 2010 22:31:26 -0800 (PST)
Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by core3.amsl.com (Postfix) with ESMTP id 67D3D3A688A for <secdir@ietf.org>; Sun, 10 Jan 2010 22:31:26 -0800 (PST)
Received: from mx02.mta.xmission.com ([166.70.13.212]) by out02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1NUDoA-0008LD-1k; Sun, 10 Jan 2010 23:31:22 -0700
Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=fermat.rhmr.com) by mx02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1NUDo7-0003cV-PJ; Sun, 10 Jan 2010 23:31:21 -0700
Received: from fermat.rhmr.com (localhost [127.0.0.1]) by fermat.rhmr.com (8.14.3/8.14.3/Debian-9ubuntu1) with ESMTP id o0B6UDV9008634; Sun, 10 Jan 2010 23:30:13 -0700
Received: (from ho@localhost) by fermat.rhmr.com (8.14.3/8.14.3/Submit) id o0B6UCdj008625; Sun, 10 Jan 2010 23:30:12 -0700
Date: Sun, 10 Jan 2010 23:30:12 -0700
Message-Id: <201001110630.o0B6UCdj008625@fermat.rhmr.com>
X-Authentication-Warning: fermat.rhmr.com: ho set sender to hilarie using -f
From: "Hilarie Orman" <ho@alum.mit.edu>
To: secdir@ietf.org
X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx02.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none
X-XM-DomainKey: sender_domain=alum.mit.edu; ; ; sender=ho@alum.mit.edu; ; ; status=error
X-SA-Exim-Connect-IP: 166.70.57.249
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1 
X-Spam-Combo: ;secdir@ietf.org
X-Spam-Relay-Country: 
X-SA-Exim-Version: 4.2.1 (built Thu, 25 Oct 2007 00:26:12 +0000)
X-SA-Exim-Scanned: Yes (on mx02.mta.xmission.com)
Cc: kanno-s@po.ntts.co.jp, kanda.masayuki@lab.ntt.co.jp, akato@po.ntts.co.jp
Subject: [secdir] Review of
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Hilarie Orman <ho@alum.mit.edu>
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jan 2010 06:31:27 -0000

Camellia Cipher Suites for TLS
draft-kato-tls-rfc4132bis-04

Do not be alarmed.  I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG.  These comments were written primarily
for the benefit of the security area directors.  Document editors and
WG chairs should treat these comments just like any other last call
comments.

The document is intended to define identifiers for 12 new
ciphersuites for TLS.  The suites are duplicates of
existing ones, except that they use HMAC-SHA-256 instead of
HMAC-SHA.  The suites are restricted to implementations
of TLS 1.2 and later.

The only oddity in the document is that the identifiers for the new
suites are TBD.  The document states:

 "IANA is requested to allocate (has allocated) the following numbers
 in the TLS Cipher Suite Registry:"

Are the authors supposed to submit the document and update the numbers
per IANA advice at some later time?  The wording indicates some
confusion over this point.

Hilarie

From d3e3e3@gmail.com  Mon Jan 11 03:46:32 2010
Return-Path: <d3e3e3@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3174B3A69DF; Mon, 11 Jan 2010 03:46:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.293
X-Spam-Level: 
X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.305,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AufwpcaZ9nRF; Mon, 11 Jan 2010 03:46:31 -0800 (PST)
Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id D8F133A685B; Mon, 11 Jan 2010 03:46:30 -0800 (PST)
Received: by ewy6 with SMTP id 6so21838334ewy.29 for <multiple recipients>; Mon, 11 Jan 2010 03:46:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=obxTSWnBYeQ0KasW9kQP1c5lzGDw5PA8jhgiXWaCrMw=; b=ZDDHvLPBLuOOLszl8AqNlH9Wtm69rzjo1h0FsA6jVirq6IegnQdLpbdRC/XDqaa/Gj 9npD9vUX5SqjIFJ+WBrVPtiS351F5SU+WJMWB+muhSfdcTk3QpSRPaWXPhb0TdbYtUoa uOfDmUv1mcx208pmYbckoy8pbmBVh4tY+uUuo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AtgJthwBsHFZGE+n6xBmUHytbGhp3smCQ/Y0oZWLpmDjgis7kXdCIh2aIRd7dEYOYA W7Aw9RiTDM7pwP05BLAQrSV1xHDMOnX6MKBJailq6FnfhEm0c5sgX1nemTpHNrVR9bdI ijxRmcYYzzxOF4MSrYps4Z+82KDH1gBclITWM=
MIME-Version: 1.0
Received: by 10.216.90.21 with SMTP id d21mr1779262wef.85.1263210385374; Mon,  11 Jan 2010 03:46:25 -0800 (PST)
In-Reply-To: <C770213C.7A2C%stefan@aaa-sec.com>
References: <C770213C.7A2C%stefan@aaa-sec.com>
Date: Mon, 11 Jan 2010 06:46:25 -0500
Message-ID: <1028365c1001110346q539ce61ag9515e27d27cb1322@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
To: Stefan Santesson <stefan@aaa-sec.com>
Content-Type: multipart/alternative; boundary=0016e6d77fa04bfdc0047ce216f6
Cc: Silvano Gai <sgai@cisco.com>, secdir@ietf.org, Erik Nordmark <erik.nordmark@sun.com>, Dinesh Dutt <ddutt@cisco.com>, Anoop Ghanwani <anoop@brocade.com>, Radia Perlman <Radia.Perlman@sun.com>, iesg@ietf.org, Ralph Droms <rdroms@cisco.com>
Subject: Re: [secdir] secdir review of draft-ietf-trill-rbridge-protocol-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jan 2010 11:46:32 -0000

--0016e6d77fa04bfdc0047ce216f6
Content-Type: text/plain; charset=ISO-8859-1

Thanks for the review,
Donald
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3@gmail.com


On Sun, Jan 10, 2010 at 6:28 PM, Stefan Santesson <stefan@aaa-sec.com>wrote:

>  I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
>  These comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments just
> like any other last call comments.
>
> I have limited my review to security related issues and whether the
> document have a reasonable security considerations section.
> I have not reviewed the technical content of the document.
>
> The document seems sound form a security perspective. The security
> considerations section is clear on the fact layer 2 bridging is not
> inherently secure but appears to make a reasonable job at describing
> guidance on how to address various security issues related to this protocol.
>
> I find no major issues that the security ADs should be aware of.
>
> /Stefan
>

--0016e6d77fa04bfdc0047ce216f6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks for the review,<div>Donald<br clear=3D"all">=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br> Donald =
E. Eastlake 3rd =A0 +1-508-634-2066 (home)<br> 155 Beaver Street<br> Milfor=
d, MA 01757 USA<br> <a href=3D"mailto:d3e3e3@gmail.com">d3e3e3@gmail.com</a=
><br>

<br><br><div class=3D"gmail_quote">On Sun, Jan 10, 2010 at 6:28 PM, Stefan =
Santesson <span dir=3D"ltr">&lt;<a href=3D"mailto:stefan@aaa-sec.com">stefa=
n@aaa-sec.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">




<div>
<font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-size:=
11pt">I have reviewed this document as part of the security directorate&#39=
;s ongoing effort to review all IETF documents being processed by the IESG.=
 =A0These comments were written primarily for the benefit of the security a=
rea directors. =A0Document editors and WG chairs should treat these comment=
s just like any other last call comments.<br>

<br>
I have limited my review to security related issues and whether the documen=
t have a reasonable security considerations section.<br>
I have not reviewed the technical content of the document.<br>
<br>
The document seems sound form a security perspective. The security consider=
ations section is clear on the fact layer 2 bridging is not inherently secu=
re but appears to make a reasonable job at describing guidance on how to ad=
dress various security issues related to this protocol.<br>

<br>
I find no major issues that the security ADs should be aware of.<br><font c=
olor=3D"#888888">
<br>
/Stefan </font></span></font>
</div>


</blockquote></div><br></div>

--0016e6d77fa04bfdc0047ce216f6--

From derek@ihtfp.com  Mon Jan 11 10:40:14 2010
Return-Path: <derek@ihtfp.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60E4A3A6836 for <secdir@core3.amsl.com>; Mon, 11 Jan 2010 10:40:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level: 
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZN1qP1PWXq4 for <secdir@core3.amsl.com>; Mon, 11 Jan 2010 10:40:13 -0800 (PST)
Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by core3.amsl.com (Postfix) with ESMTP id 51A463A63C9 for <secdir@ietf.org>; Mon, 11 Jan 2010 10:40:13 -0800 (PST)
Received: from pgpdev.ihtfp.org (unknown [208.97.228.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id 2BD848B4005; Mon, 11 Jan 2010 13:40:09 -0500 (EST)
Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.3/8.14.2/Submit) id o0BIe64I025573; Mon, 11 Jan 2010 13:40:06 -0500
To: Hilarie Orman <ho@alum.mit.edu>
References: <201001110630.o0B6UCdj008625@fermat.rhmr.com>
From: Derek Atkins <derek@ihtfp.com>
Date: Mon, 11 Jan 2010 13:40:05 -0500
In-Reply-To: <201001110630.o0B6UCdj008625@fermat.rhmr.com> (Hilarie Orman's message of "Sun\, 10 Jan 2010 23\:30\:12 -0700")
Message-ID: <sjmljg41o56.fsf@pgpdev.ihtfp.org>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: kanno-s@po.ntts.co.jp, kanda.masayuki@lab.ntt.co.jp, akato@po.ntts.co.jp, secdir@ietf.org
Subject: Re: [secdir] Review of
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jan 2010 18:40:14 -0000

"Hilarie Orman" <ho@alum.mit.edu> writes:

> Camellia Cipher Suites for TLS
> draft-kato-tls-rfc4132bis-04
>
> Do not be alarmed.  I have reviewed this document as part of the
> security directorate's ongoing effort to review all IETF documents
> being processed by the IESG.  These comments were written primarily
> for the benefit of the security area directors.  Document editors and
> WG chairs should treat these comments just like any other last call
> comments.
>
> The document is intended to define identifiers for 12 new
> ciphersuites for TLS.  The suites are duplicates of
> existing ones, except that they use HMAC-SHA-256 instead of
> HMAC-SHA.  The suites are restricted to implementations
> of TLS 1.2 and later.
>
> The only oddity in the document is that the identifiers for the new
> suites are TBD.  The document states:
>
>  "IANA is requested to allocate (has allocated) the following numbers
>  in the TLS Cipher Suite Registry:"
>
> Are the authors supposed to submit the document and update the numbers
> per IANA advice at some later time?  The wording indicates some
> confusion over this point.

The IANA Considerations are written so that it reads correctly before
and after IANA processes the request.  The RFC-Editor will work with
IANA and fill in the correct values once it's been processed, so I don't
think this should be a major concern.

> Hilarie

-derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

From catherine.meadows@nrl.navy.mil  Mon Jan 11 13:42:04 2010
Return-Path: <catherine.meadows@nrl.navy.mil>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDA613A682E; Mon, 11 Jan 2010 13:42:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcDRO59nlPz4; Mon, 11 Jan 2010 13:42:03 -0800 (PST)
Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id 9959B3A67F3; Mon, 11 Jan 2010 13:42:03 -0800 (PST)
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.6/8.13.6) with ESMTP id o0BLfqMn020204; Mon, 11 Jan 2010 16:41:56 -0500 (EST)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.6/8.13.6) with SMTP id o0BLflNJ009332; Mon, 11 Jan 2010 16:41:50 -0500 (EST)
Received: from siduri.fw5540.net ([10.0.3.73]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2010011116414621424 ; Mon, 11 Jan 2010 16:41:46 -0500
From: Catherine Meadows <catherine.meadows@nrl.navy.mil>
Content-Type: multipart/alternative; boundary=Apple-Mail-11--676334414
Date: Mon, 11 Jan 2010 16:43:10 -0500
Message-Id: <214A28E5-3DBD-4252-8EF6-7E18CEB441E5@nrl.navy.mil>
To: secdir@ietf.org, dan.ietf@sipez.com, sumanth2cablelabs.com@chacs.nrl.navy.mil, iesg@ietf.org
Mime-Version: 1.0 (Apple Message framework v1077)
X-Mailer: Apple Mail (2.1077)
Subject: [secdir] Secdir review of draft-ietf-sipping-config-framework-16
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jan 2010 21:42:04 -0000

--Apple-Mail-11--676334414
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG.  These comments were written primarily
for the benefit of the security area directors.  Document editors and
WG chairs should treat these comments just like any other last call
comments.

This ID has to do with User Agent profile delivery in SIP.  A profile is =
the configuration data sent to a SIP User Agent so that it can function =
properly.  This information is called a profile, and in SIP the =
maintenance and delivery of this information is the responsibility of =
the Profile Delivery Server (PDS).   This ID describes the protocol used =
to deliver this information.

As would be expected, there are some serious security issues with =
respect to profile delivery.  Profiles may contain sensitive =
information, so they need to be protected and the User Agents to which =
they are sent must be properly authenticated to the PDS.  Likewise, the =
PDS must also be properly authenticated to the User Agent, since a =
fraudulent PDS could send a bogus and possibly harmful profile to the =
User Agent.  This ID recognizes this and describes how the mechanisms of =
SIP should or must be used to support user agent profile delivery.
One key issue here is the case in which a device is requesting a =
profile, but for various reasons (e.g. it is just being initialized), it =
does not have the ability to authenticate itself.  Thus some other =
methods must be used.  These are outlined in Section 5.3.1.

I think that this ID is in general in good shape with respect to =
security, but I was a little confused about some of the discussion of =
bootstrapping.  It is the hardest to pin down, of course, but it is also =
the most important to make clear, because it is the point, I believe, at =
which the network is most vulnerable. Specific comments follow:

1.  The first sentence of Section 5.3.1, which reads=20

When requesting a profile the device can provide an identity (i.e., a
user AoR), and contain associated credentials for authentication. To
do so, the device needs to obtain this information via bootstrapping.

I wasn't quite sure what this means.   Should that "can" be a "must"?  =
That is, the device needs the information, but can only get it through =
bootstrapping.  Or is the
"contain" be "obtain", and bootstrapping is how you get it?

2.  Bootstrapping itself is never explicitly defined.  I'd suggest doing =
that at the beginning of 5.3.1.

3.  The discussion of bootstrapping in 5.3.1 appears to only consider =
the threat to the PDS.  What about the other way around?  This is =
mentioned as a threat in the Security Considerations section, but it's =
not clear to me whether 5.3.1 addresses this threat.

4.  The discussion of the security implications of bootstrapping device =
profiles in Section 9.2 is valuable, and helps the reader understand the =
rationale for the recommendations in 5.3.1 better,  A forward reference =
in the discussion of device profile on page 26 would be helpful.
Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil


--Apple-Mail-11--676334414
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I =
have reviewed this document as part of the<br>security directorate's =
ongoing effort to review all IETF documents<br>being processed by the =
IESG. &nbsp;These comments were written primarily<br>for the benefit of =
the security area directors. &nbsp;Document editors and<br>WG chairs =
should treat these comments just like any other last =
call<br>comments.<div><br></div><div>This ID has to do with User Agent =
profile delivery in SIP.&nbsp;&nbsp;A profile is the configuration data =
sent to a SIP User Agent so that it can function =
properly.&nbsp;&nbsp;This information is called a profile, and in SIP =
the maintenance and delivery of this&nbsp;information is the =
responsibility of the Profile Delivery Server =
(PDS).&nbsp;&nbsp;&nbsp;This ID describes the protocol used to deliver =
this information.<br><br>As would be expected, there are some serious =
security issues with respect to profile delivery.&nbsp;&nbsp;Profiles =
may contain sensitive information, so they need to be protected and the =
User Agents to which they are sent must be properly&nbsp;authenticated =
to the PDS.&nbsp;&nbsp;Likewise, the PDS must also be properly =
authenticated to the User Agent, since a fraudulent PDS could send a =
bogus and possibly harmful profile to the User Agent.&nbsp;&nbsp;This ID =
recognizes this and describes how&nbsp;the mechanisms of SIP should or =
must be used to support user agent profile delivery.<br>One key issue =
here is the case in which a device is requesting a profile, but for =
various reasons (e.g. it is just being initialized), it does not have =
the ability to authenticate itself.&nbsp;&nbsp;Thus some other methods =
must be used.&nbsp;&nbsp;These are outlined&nbsp;in Section =
5.3.1.<br><br>I think that this ID is in general in good shape with =
respect to security, but I was a little confused about some of the =
discussion of bootstrapping.&nbsp;&nbsp;It is the hardest to pin down, =
of course, but it is also the most important to make clear,&nbsp;because =
it is the point, I believe, at which the network is most vulnerable. =
Specific comments follow:<br><br>1.&nbsp;&nbsp;The first sentence of =
Section 5.3.1, which reads&nbsp;<br><br>When requesting a profile the =
device can provide an identity (i.e., a<br>user AoR), and contain =
associated credentials for authentication. To<br>do so, the device needs =
to obtain this information via bootstrapping.<br><br>I wasn't quite sure =
what this means.&nbsp;&nbsp;&nbsp;Should that "can" be a =
"must"?&nbsp;&nbsp;That is, the device needs the information, but can =
only get it through bootstrapping.&nbsp;&nbsp;Or is the<br>"contain" be =
"obtain", and bootstrapping is how you get =
it?<br><br>2.&nbsp;&nbsp;Bootstrapping itself is never explicitly =
defined.&nbsp;&nbsp;I'd suggest doing that at the beginning of =
5.3.1.<br><br>3.&nbsp;&nbsp;The discussion of bootstrapping in 5.3.1 =
appears to only consider the threat to the PDS.&nbsp;&nbsp;What about =
the other way around?&nbsp;&nbsp;This is mentioned as a threat in the =
Security Considerations section, but it's not clear to me whether =
5.3.1&nbsp;addresses this threat.<br><br>4.&nbsp;&nbsp;The discussion of =
the security implications of bootstrapping device profiles in Section =
9.2 is valuable, and helps the reader understand the rationale for the =
recommendations in 5.3.1 better,&nbsp;&nbsp;A forward reference in the =
discussion of&nbsp;device profile on page 26 would be helpful.<br><div>
<span class=3D"Apple-style-span" style=3D"font-size: 12px; =
"><div>Catherine Meadows<br>Naval Research Laboratory<br>Code =
5543<br>4555 Overlook Ave., S.W.<br>Washington DC, 20375<br>phone: =
202-767-3490<br>fax: 202-404-7942<br>email:&nbsp;<a =
href=3D"mailto:catherine.meadows@nrl.navy.mil">catherine.meadows@nrl.navy.=
mil</a></div></span>
</div>
<br></div></body></html>=

--Apple-Mail-11--676334414--

From dpetrie@sipez.com  Mon Jan 11 19:07:26 2010
Return-Path: <dpetrie@sipez.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 542A23A6962 for <secdir@core3.amsl.com>; Mon, 11 Jan 2010 19:07:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZFi10FGerXP for <secdir@core3.amsl.com>; Mon, 11 Jan 2010 19:07:26 -0800 (PST)
Received: from web37102.mail.mud.yahoo.com (web37102.mail.mud.yahoo.com [209.191.85.104]) by core3.amsl.com (Postfix) with SMTP id 2168E3A6812 for <secdir@ietf.org>; Mon, 11 Jan 2010 19:07:26 -0800 (PST)
Received: (qmail 1689 invoked by uid 60001); 12 Jan 2010 03:00:42 -0000
Message-ID: <373981.1666.qm@web37102.mail.mud.yahoo.com>
X-YMail-OSG: V9Ut2j4VM1lLIY8xUWmNJEGUeouum9Ighzgt8K87WSu26t_5In3mXLfrnpl8OpElbbdENXd1S7uxqVHVlc1iNvR.4AhJpdPbXV0Eg11g9NE5Qe1qn.unmR3lspVhue7POLziZKS59RlioUmsdqhqo9nis5_I9J9dJq4ONvTkJjlWFF9vF6MXxbZR4HcDBJeSnANnF154_vOVgCGdtkgTDWAPwOpZqu7jja2OwHCwvv1GhQc6sEoKhIY7_0v1q6FqpeiMqWf8uGw5V88ZuaXvPcg.KZvBEMH.gcczfoIwbJa8EELMVelCsos6baKp3ppxZsjwvjj4WIZlAzGRn46qbsbEmg--
Received: from [24.61.83.127] by web37102.mail.mud.yahoo.com via HTTP; Mon, 11 Jan 2010 19:00:41 PST
X-RocketYMMF: dgpetrie
X-Mailer: YahooMailClassic/9.0.20 YahooMailWebService/0.8.100.260964
Date: Mon, 11 Jan 2010 19:00:41 -0800 (PST)
From: Daniel Petrie <dpetrie@sipez.com>
To: secdir@ietf.org, dan.ietf@sipez.com, sumanth2cablelabs.com@chacs.nrl.navy.mil, iesg@ietf.org, Catherine Meadows <catherine.meadows@nrl.navy.mil>
In-Reply-To: <214A28E5-3DBD-4252-8EF6-7E18CEB441E5@nrl.navy.mil>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 11 Jan 2010 23:16:52 -0800
Subject: Re: [secdir] Secdir review of draft-ietf-sipping-config-framework-16
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: dpetrie@sipez.com
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jan 2010 03:07:26 -0000

Hi Catherine:=0AThank you for the very constructive comments.  I very much =
appreciate your effort of slogging through this draft.  I have to go refres=
h my memory on the issues you have identified.=0A=0ACheers,=0ADan=0A=0A--- =
On Mon, 1/11/10, Catherine Meadows <catherine.meadows@nrl.navy.mil> wrote:=
=0A=0A> From: Catherine Meadows <catherine.meadows@nrl.navy.mil>=0A> Subjec=
t: Secdir review of draft-ietf-sipping-config-framework-16=0A> To: secdir@i=
etf.org, dan.ietf@sipez.com, sumanth2cablelabs.com@chacs.nrl.navy.mil, iesg=
@ietf.org=0A> Cc: "Catherine Meadows" <catherine.meadows@nrl.navy.mil>=0A> =
Date: Monday, January 11, 2010, 4:43 PM=0A> I have reviewed this=0A> docume=
nt as part of the=0A> security directorate's ongoing effort to review all=
=0A> IETF documents=0A> being processed by the IESG. =A0These comments were=
=0A> written primarily=0A> for the benefit of the security area directors.=
=0A> =A0Document editors and=0A> WG chairs should treat these comments just=
 like any other=0A> last call=0A> comments.=0A> This ID has to do with User=
 Agent profile=0A> delivery in SIP.=A0=A0A profile is the configuration=0A>=
 data sent to a SIP User Agent so that it can function=0A> properly.=A0=A0T=
his information is called a profile,=0A> and in SIP the maintenance and del=
ivery of=0A> this=A0information is the responsibility of the Profile=0A> De=
livery Server (PDS).=A0=A0=A0This ID describes=0A> the protocol used to del=
iver this information.=0A> =0A> As would be expected, there are some seriou=
s security=0A> issues with respect to profile delivery.=A0=A0Profiles=0A> m=
ay contain sensitive information, so they need to be=0A> protected and the =
User Agents to which they are sent must be=0A> properly=A0authenticated to =
the PDS.=A0=A0Likewise,=0A> the PDS must also be properly authenticated to =
the User=0A> Agent, since a fraudulent PDS could send a bogus and=0A> possi=
bly harmful profile to the User Agent.=A0=A0This=0A> ID recognizes this and=
 describes how=A0the mechanisms of=0A> SIP should or must be used to suppor=
t user agent profile=0A> delivery.=0A> One key issue here is the case in wh=
ich a device is=0A> requesting a profile, but for various reasons (e.g. it =
is=0A> just being initialized), it does not have the ability to=0A> authent=
icate itself.=A0=A0Thus some other methods must=0A> be used.=A0=A0These are=
 outlined=A0in Section=0A> 5.3.1.=0A> =0A> I think that this ID is in gener=
al in good shape with=0A> respect to security, but I was a little confused =
about some=0A> of the discussion of bootstrapping.=A0=A0It is the=0A> harde=
st to pin down, of course, but it is also the most=0A> important to make cl=
ear,=A0because it is the point, I=0A> believe, at which the network is most=
 vulnerable. Specific=0A> comments follow:=0A> =0A> 1.=A0=A0The first sente=
nce of Section 5.3.1, which=0A> reads=A0=0A> =0A> When requesting a profile=
 the device can provide an=0A> identity (i.e., a=0A> user AoR), and contain=
 associated credentials for=0A> authentication. To=0A> do so, the device ne=
eds to obtain this information via=0A> bootstrapping.=0A> =0A> I wasn't qui=
te sure what this=0A> means.=A0=A0=A0Should that "can" be a=0A> "must"?=A0=
=A0That is, the device needs the=0A> information, but can only get it throu=
gh=0A> bootstrapping.=A0=A0Or is the=0A> "contain" be "obtain", and=0A> boo=
tstrapping is how you get it?=0A> =0A> 2.=A0=A0Bootstrapping itself is neve=
r explicitly=0A> defined.=A0=A0I'd suggest doing that at the=0A> beginning =
of 5.3.1.=0A> =0A> 3.=A0=A0The discussion of bootstrapping in 5.3.1=0A> app=
ears to only consider the threat to the=0A> PDS.=A0=A0What about the other =
way=0A> around?=A0=A0This is mentioned as a threat in the=0A> Security Cons=
iderations section, but it's not clear to=0A> me whether 5.3.1=A0addresses =
this threat.=0A> =0A> 4.=A0=A0The discussion of the security implications=
=0A> of bootstrapping device profiles in Section 9.2 is valuable,=0A> and h=
elps the reader understand the rationale for the=0A> recommendations in 5.3=
.1 better,=A0=A0A forward=0A> reference in the discussion of=A0device profi=
le on page=0A> 26 would be helpful.=0A> =0A> Catherine Meadows=0A> Naval Re=
search Laboratory=0A> Code 5543=0A> 4555 Overlook Ave., S.W.=0A> Washington=
 DC, 20375=0A> phone: 202-767-3490=0A> fax: 202-404-7942=0A> email:=A0cathe=
rine.meadows@nrl.navy.mil=0A> =0A> =0A> 

From kristofer.sandlund@ericsson.com  Wed Jan 13 05:40:26 2010
Return-Path: <kristofer.sandlund@ericsson.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C3A13A68D8; Wed, 13 Jan 2010 05:40:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vIdhRgCHgIt; Wed, 13 Jan 2010 05:40:25 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 98D753A6874; Wed, 13 Jan 2010 05:40:24 -0800 (PST)
X-AuditID: c1b4fb24-b7bb6ae000001052-d1-4b4dcd35e661
Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 1E.53.04178.53DCD4B4; Wed, 13 Jan 2010 14:40:05 +0100 (CET)
Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 13 Jan 2010 14:40:04 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 13 Jan 2010 14:40:03 +0100
Message-ID: <9520E66537CC4941994C518E3E21091C022F0C00@esealmw105.eemea.ericsson.se>
In-Reply-To: <AC6674AB7BC78549BB231821ABF7A9AE8FFA34B821@EMBX01-WF.jnpr.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: secdir review of draft-ietf-rohc-rfc4995bis-01
Thread-Index: Acp4MKAIMZ3QHusWS0yAOB7er4hAdgCe2nhgAAsvEsAAElokIAZMQcYA
References: <AC6674AB7BC78549BB231821ABF7A9AE8FFA34B821@EMBX01-WF.jnpr.net>
From: "Kristofer Sandlund" <kristofer.sandlund@ericsson.com>
To: "Stephen Hanna" <shanna@juniper.net>
X-OriginalArrivalTime: 13 Jan 2010 13:40:04.0824 (UTC) FILETIME=[E9BF4D80:01CA9455]
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Wed, 13 Jan 2010 06:05:09 -0800
Cc: lars-erik@lejonsson.com, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-rohc-rfc4995bis-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jan 2010 13:40:26 -0000

Hi Stephen,

sorry for the extremely late reply. Inlined below are answers to points
2 and 3.

Stephen Hanna wrote:
>>=20
>> 2) Have the editors verified that all contributors to the document
>>    are OK with granting the new rights granted in RFC 5378 on top
>>    of the rights that they originally granted under RFC 3978? This
>>    would include anyone who contributed text that has been held over
>>    from RFC 4995 and RFC 3095 and their employers at the time that
>>    the time of the contribution, or other assignees. I suspect that
>>    the answer is no. If I'm right, the editors should use the text
>>    designed for this situation, which is included in section 6.c.iii
>>    of the IETF Trust Legal Provisions Relating to IETF Documents.
>>=20

Agreed, we've updated this for version -03. Thanks for finding it.

>> 3) The Security Considerations of this document are pretty good.
>>    However, I think that they may ignore a particular risk of
>>    using header compression. Namely, it seems to me that using
>>    header compression would substantially increase the complexity
>>    of the devices that perform the compression and decompression
>>    vs. the complexity without header compression. For example,
>>    a switch or router must now maintain per-flow ROHC state and
>>    implement the ROHC protocols, which are a bit complex. This
>>    complexity may result in implementation bugs that could be
>>    exploited by an attacker sending a packet through the system
>>    with a particular format designed to exploit the flaw. If
>>    any device along the packet's path is vulnerable, the flaw
>>    will be exploited. Depending on the nature of the coding
>>    error, such a vulnerability could result in denial of
>>    service or compromise of the vulnerable device. It could
>>    even result in a cascading failure where all the vulnerable
>>    devices on the path are compromised. The fact that ROHC is
>>    a stateful protocol means that testing will be more complex.
>>    And the fact that application layer protocol headers are
>>    compressed introduces the possibility that an untrusted
>>    application allowed to send application layer data could
>>    exploit vulnerabilities in network devices that implement
>>    ROHC. To address these concerns, I propose adding a new
>>    paragraph in the Security Considerations:
>>=20
>>    Implementing a ROHC compressor or decompressor is not a
>>    trivial task. It can add vulnerabilities to a device.
>>    Implementors should practice safe coding techniques and
>>    recognize that both compressed and uncompressed packets
>>    can come from malicious or compromised sources that may
>>    send malformed packets and otherwise attempt to exploit
>>    vulnerabilities. Regard all packets with care to protect
>>    your implementation from such attacks. Otherwise, the
>>    compromise of one network element may result in a
>>    cascading sequence of compromises.
>>=20

We discussed this comment a bit, and we think it is going a bit too far.
A bad implementation of a protocol is always going to have the potential
to cause more problems than not having the protocol in the first place;
therefore it seems obvious that one should try to make the
implementation "good".
So we're not planning to change the security considerations.

BR,
  Kristofer


From weiler@watson.org  Thu Jan 14 06:10:00 2010
Return-Path: <weiler@watson.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A065C3A6873 for <secdir@core3.amsl.com>; Thu, 14 Jan 2010 06:10:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.099
X-Spam-Level: 
X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJTNjCNeL3ZT for <secdir@core3.amsl.com>; Thu, 14 Jan 2010 06:09:59 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id BF6F93A67D9 for <secdir@ietf.org>; Thu, 14 Jan 2010 06:09:59 -0800 (PST)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o0EE9te3043460; Thu, 14 Jan 2010 09:09:55 -0500 (EST) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o0EE9rC9043454; Thu, 14 Jan 2010 09:09:53 -0500 (EST) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Thu, 14 Jan 2010 09:09:53 -0500 (EST)
From: Samuel Weiler <weiler@watson.org>
To: Hilarie Orman <ho@alum.mit.edu>
In-Reply-To: <201001110630.o0B6UCdj008625@fermat.rhmr.com>
Message-ID: <alpine.BSF.2.00.1001140904580.41024@fledge.watson.org>
References: <201001110630.o0B6UCdj008625@fermat.rhmr.com>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 14 Jan 2010 09:09:55 -0500 (EST)
Cc: kanno-s@po.ntts.co.jp, kanda.masayuki@lab.ntt.co.jp, akato@po.ntts.co.jp, secdir@ietf.org
Subject: Re: [secdir] Review of draft-kato-tls-rfc4132bis-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: secdir-secretary@mit.edu
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jan 2010 14:10:00 -0000

(I'm replying in part to change the Subject line to include the 
draft name, since that's how our ADs and others find these reviews.)

And Derek's right about IANA.  For most IANA registries, IANA isn't 
supposed to give the assignment until the doc is published.  The TBA 
placeholder and future-tense text will get replaced during the 
publication cycle when the assignment is made.  Some docs suggest a 
particular number to IANA, if only implicitly, but that's not 
necessary.

-- Sam

On Sun, 10 Jan 2010, Hilarie Orman wrote:

> Camellia Cipher Suites for TLS
> draft-kato-tls-rfc4132bis-04
>
> Do not be alarmed.  I have reviewed this document as part of the
> security directorate's ongoing effort to review all IETF documents
> being processed by the IESG.  These comments were written primarily
> for the benefit of the security area directors.  Document editors and
> WG chairs should treat these comments just like any other last call
> comments.
>
> The document is intended to define identifiers for 12 new
> ciphersuites for TLS.  The suites are duplicates of
> existing ones, except that they use HMAC-SHA-256 instead of
> HMAC-SHA.  The suites are restricted to implementations
> of TLS 1.2 and later.
>
> The only oddity in the document is that the identifiers for the new
> suites are TBD.  The document states:
>
> "IANA is requested to allocate (has allocated) the following numbers
> in the TLS Cipher Suite Registry:"
>
> Are the authors supposed to submit the document and update the numbers
> per IANA advice at some later time?  The wording indicates some
> confusion over this point.
>
> Hilarie
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
>
>

From weiler+secdir@watson.org  Thu Jan 14 06:18:34 2010
Return-Path: <weiler+secdir@watson.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BFBA3A6902 for <secdir@core3.amsl.com>; Thu, 14 Jan 2010 06:18:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wMZi3hmYNHS for <secdir@core3.amsl.com>; Thu, 14 Jan 2010 06:18:27 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 3B2E73A67D9 for <secdir@ietf.org>; Thu, 14 Jan 2010 06:18:25 -0800 (PST)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o0EEIMVb044467 for <secdir@ietf.org>; Thu, 14 Jan 2010 09:18:22 -0500 (EST) (envelope-from weiler+secdir@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o0EEIMZv044464 for <secdir@ietf.org>; Thu, 14 Jan 2010 09:18:22 -0500 (EST) (envelope-from weiler+secdir@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Thu, 14 Jan 2010 09:18:22 -0500 (EST)
From: Samuel Weiler <weiler+secdir@watson.org>
X-X-Sender: weiler@fledge.watson.org
To: secdir@ietf.org
Message-ID: <alpine.BSF.2.00.1001140914360.41024@fledge.watson.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 14 Jan 2010 09:18:22 -0500 (EST)
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: secdir-secretary@mit.edu
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jan 2010 14:18:34 -0000

Nico Williams is next in the rotation.

Documents on the telechat agenda typically have a last call end date 
before the date shown below; reviews by the end of last call are 
typically more appreciated by the doc editors.

Review instructions and related resources are at:
       http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

-- Sam

For telechat 2010-01-21

Reviewer                 Deadline   Draft
Jeffrey Hutzelman      T 2010-01-19 draft-ietf-capwap-base-mib-08
Eric Rescorla          T 2010-01-19 draft-gennai-smime-cnipa-pec-05
Eric Rescorla          T 2010-01-19 draft-brown-versioning-link-relations-06
Joe Salowey            T 2010-01-19 draft-ietf-pana-preauth-08
Larry Zhu              TR2010-01-19 draft-moriarty-post-inch-rid-09

Last calls and special requests:

Reviewer                 Deadline   Draft
Rob Austein              2009-11-28 draft-ietf-pkix-attr-cert-mime-type-02
Richard Barnes           None       draft-ietf-dnsext-dnssec-gost-06
Dave Cridland            2009-11-25 draft-ietf-nsis-qspec-22
Alan DeKok               2009-10-01 draft-ietf-enum-enumservices-transition-04
Alan DeKok               2009-12-07 draft-ietf-capwap-802dot11-mib-06
Love Hornquist-Astrand   2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05
Love Hornquist-Astrand   2009-10-13 draft-ietf-idnabis-mappings-05
David McGrew             None       draft-ietf-dnsext-dnssec-gost-06
Catherine Meadows        2008-01-17 draft-ietf-speechsc-mrcpv2-20
Russ Mundy               2009-10-21 draft-ietf-hokey-preauth-ps-11
Sandy Murphy            R2009-11-18 draft-ietf-mpls-mpls-and-gmpls-security-framework-07
Sandy Murphy             2010-01-14 draft-turner-ecprivatekey-02
Vidya Narayanan          2008-11-21 draft-ietf-sip-saml-06
Chris Newman             2010-01-07 draft-ietf-krb-wg-preauth-framework-15
Hilarie Orman            2010-01-14 draft-kato-tls-rfc4132bis-04
Joe Salowey              2009-02-08 draft-ietf-geopriv-lis-discovery-13
Hannes Tschofenig        2010-02-05 draft-allbery-afs-srv-records-03
Tina TSOU                2010-02-01 draft-roach-sip-http-subscribe-06
Sean Turner              2010-02-01 draft-jabley-reverse-servers-01
Carl Wallace             2010-01-27 draft-ietf-ccamp-pc-spc-rsvpte-ext-06
Sam Weiler               2008-08-13 draft-chown-v6ops-rogue-ra-03
Sam Weiler               2010-01-27 draft-ietf-sipcore-199-02
Brian Weis               2009-10-20 draft-ietf-l3vpn-e2e-rsvp-te-reqts-05
Brian Weis               2010-01-28 draft-ietf-nsis-y1541-qosm-08
Nico Williams            2008-08-13 draft-ietf-v6ops-ra-guard-04
Larry Zhu                2008-08-13 draft-thaler-v6ops-teredo-extensions-05
Larry Zhu                2009-05-09 draft-ietf-ecrit-location-hiding-req-02



From rbarnes@bbn.com  Thu Jan 14 15:06:14 2010
Return-Path: <rbarnes@bbn.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2FB03A6908 for <secdir@core3.amsl.com>; Thu, 14 Jan 2010 15:06:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDBL17RnkCdo for <secdir@core3.amsl.com>; Thu, 14 Jan 2010 15:06:13 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 9B00D3A6890 for <secdir@ietf.org>; Thu, 14 Jan 2010 15:06:13 -0800 (PST)
Received: from [128.89.253.32] (helo=[192.168.1.45]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1NVYlV-000O32-CO; Thu, 14 Jan 2010 18:06:10 -0500
Message-Id: <E18FB588-FA46-447B-828F-BF98527D6725@bbn.com>
From: "Richard L. Barnes" <rbarnes@bbn.com>
To: secdir <secdir@ietf.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 14 Jan 2010 18:06:02 -0500
X-Mailer: Apple Mail (2.936)
Cc: draft-ietf-dnsext-dnssec-gost@tools.ietf.org, dnsext-chairs@tools.ietf.org
Subject: [secdir] Review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jan 2010 23:06:14 -0000

I reviewed this document as part of the security directorate's ongoing  
effort to review all IETF documents being processed by the IESG.   
These comments were written primarily for the benefit of the security  
area directors.  Document editors and WG chairs should treat these  
comments just like any other last call comments.

This document defines formats for DNSKEY, RRSIG, and DS records that  
use the GOST suite of cryptographic algorithms, namely GOST 34.10-2001  
for signing and GOST 34.11-94 for digest computation.

The document is generally clearly written and usable, but I'm  
concerned about how the document manages algorithm parameters. The  
cryptographic computations described in this document all use a single  
set of parameters, even though RFC 4357 defines at least four other  
sets of signing parameters, and parameter selection is permitted by  
several analogous drafts: RFC 3110 (RSA/SHA1 for DNSSEC) allows the  
RSA modulus to be specified, and RFCs 4490 and 4491 (the analogous  
documents for PKIX and CMS) allow the use of arbitrary GOST  
parameters.  "Hard-wiring" algorithm parameters to an algorithm  
number, as this draft does, increases the burden on the algorithm  
number space because it requires a separate number for each  
combination of parameters that can be used.

I also agree with the comments from Steve and Paul that the "SHOULD  
support GOST" in Section 6.1 should be a "MAY".

Detailed comments follow.

--Richard



Section 1, second paragraph:
It would be helpful to refer to the english versions of the algorithm  
descriptions (draft-dolmatov-cryptocom-gost*) at this point.

Section 1, fourth paragraph:
There should be an "and" before "GOST 28147-89".

Section 2.1:

It would be really helpful if you could explain what this sequence of  
bytes means.  Putting on my ASN.1/DER thinking cap, I managed to  
figure out that it's creating a SubjectPublicKeyInfo structure; I  
would suggest saying that, and maybe including a diagram like the  
following (which makes it even clearer that the algorithm parameters  
are being fixed):

SubjectPublicKeyInfo {
    algorithm: AlgorithmIdentifier {
        algorithm: id-GostR3410-2001
        params: GostR3410-2001-PublicKeyParams {
            publicKeyParamSet: id-Gost3410-2001-CryptoPro-A-ParamSet
            digestParamSet: id-Gost3411-94-CryptoProParamSet
            encryptionParamSet: id-Gost3411-94-CryptoProParamSet  
[default]
        }
    }
    subjectPublicKey: GostR3410-2001-PublicKey [64 key bytes]
}

Of course, if implementations are going to be tied to this data  
structure, the only possible parameters they can use are ones that  
have an OID, e.g., those defined in RFC 4357 (this limitation is due  
to the fact that the GostR3410-2001-PublicKeyParams structure only  
allows parameters to be defined by reference).  However, you could  
still allow any OID to be used in the *ParamSet fields and provide  
some simple instructions on how to patch together a  
SubjectPublicKeyInfo structure out of them.

Section 3, second paragraph:
For clarity, it would be helpful to use the notation of RFC 4034 here,  
e.g.:
  hash = GOST3411( RRSIG_RDATA | RR(1) | RR(2) | ... )

Section 3.1, last paragraph:
In order to let people use this example as a test vector, you should  
include the random value that was used to compute this signature.


Section 5:
This section seems unnecessary, since GOST has only one size for keys,  
signatures, and digests.

Section 6.2:
Should the "required" here be "REQUIRED"?

Section 6.3:
This paragraph contradicts Section 3 (and thus RFC 4490), which says  
the signatures are provided in big-endian order.  I think the general  
point is that you're sticking with the byte orders that have been  
previously defined.

From weiler@watson.org  Thu Jan 14 15:43:26 2010
Return-Path: <weiler@watson.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE6483A6856 for <secdir@core3.amsl.com>; Thu, 14 Jan 2010 15:43:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.799
X-Spam-Level: 
X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndHuQu9vRZI9 for <secdir@core3.amsl.com>; Thu, 14 Jan 2010 15:43:26 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id DD88A3A67AA for <secdir@ietf.org>; Thu, 14 Jan 2010 15:43:25 -0800 (PST)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o0ENhKj9096138; Thu, 14 Jan 2010 18:43:20 -0500 (EST) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o0ENhKkF096135; Thu, 14 Jan 2010 18:43:20 -0500 (EST) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Thu, 14 Jan 2010 18:43:20 -0500 (EST)
From: Samuel Weiler <weiler@watson.org>
To: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <E18FB588-FA46-447B-828F-BF98527D6725@bbn.com>
Message-ID: <alpine.BSF.2.00.1001141826160.70709@fledge.watson.org>
References: <E18FB588-FA46-447B-828F-BF98527D6725@bbn.com>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 14 Jan 2010 18:43:21 -0500 (EST)
Cc: draft-ietf-dnsext-dnssec-gost@tools.ietf.org, dnsext-chairs@tools.ietf.org, secdir <secdir@ietf.org>
Subject: Re: [secdir] Review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: secdir-secretary@mit.edu
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jan 2010 23:43:26 -0000

On Thu, 14 Jan 2010, Richard L. Barnes wrote:

> Section 5:
> This section seems unnecessary, since GOST has only one size for keys, 
> signatures, and digests.

>From the perspective of the DNS world, I think being explicit about 
this is actually pretty handy.  I see benefit in leaving it.

Other than that, I generally concur with the secdir reviews received 
to date, particuarly the lowering of the requirement level.


Also, while I haven't thoroughly reviewed this draft since April 2009 
(when the DNSEXT WG was asking whether to adopt it or not), a couple 
of things jump out, which I'll share now rather than wait for the IETF 
last call:

Section 6.2, on NSEC3 support, is a little vague.  I think the doc 
means "zones signed with the algorithms specified in this document may 
use either NSEC or NSEC3 and validators supporting this algorithm must 
support both NSEC and NSEC3".  I'm not sure my wording is much 
clearer, but a change is needed.

In the IANA considerations, do not use the asterisk.  Just say that 
this algorithm suite isn't being defined for transaction security 
mechanisms.

Also, the IANA considerations section includes the requirement status 
column, which implicitly assumes that we are advancing 
draft-ietf-dnsext-dnssec-registry-fixes-01.  I'm not convinced that's 
going to happen any time soon, particularly given the lackluster 
response to draft-ogud-iana-protocol-maintenance-words, which it 
depends on.  So... that needs to be tracked.  It's not necessary to 
cite registry-fixes, but it probably is necessary to treat it as a 
dependency for publication purposes.

-- Sam


From ogud@ogud.com  Fri Jan 15 07:07:28 2010
Return-Path: <ogud@ogud.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 080A03A6ACE for <secdir@core3.amsl.com>; Fri, 15 Jan 2010 07:07:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.661
X-Spam-Level: 
X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBxvbtHH2LzU for <secdir@core3.amsl.com>; Fri, 15 Jan 2010 07:07:27 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id C23123A690B for <secdir@ietf.org>; Fri, 15 Jan 2010 07:07:25 -0800 (PST)
Received: from valholl.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0FF7KkO085790; Fri, 15 Jan 2010 10:07:20 -0500 (EST) (envelope-from ogud@ogud.com)
Message-Id: <201001151507.o0FF7KkO085790@stora.ogud.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 15 Jan 2010 10:05:51 -0500
To: "Richard L. Barnes" <rbarnes@bbn.com>, secdir <secdir@ietf.org>
From: Olafur Gudmundsson <ogud@ogud.com>
In-Reply-To: <E18FB588-FA46-447B-828F-BF98527D6725@bbn.com>
References: <E18FB588-FA46-447B-828F-BF98527D6725@bbn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20
X-Mailman-Approved-At: Fri, 15 Jan 2010 08:02:23 -0800
Cc: draft-ietf-dnsext-dnssec-gost@tools.ietf.org, dnsext-chairs@tools.ietf.org
Subject: Re: [secdir] Review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jan 2010 15:07:28 -0000

At 18:06 14/01/2010, Richard L. Barnes wrote:
>I reviewed this document as part of the security directorate's ongoing
>effort to review all IETF documents being processed by the IESG.
>These comments were written primarily for the benefit of the security
>area directors.  Document editors and WG chairs should treat these
>comments just like any other last call comments.
>
>This document defines formats for DNSKEY, RRSIG, and DS records that
>use the GOST suite of cryptographic algorithms, namely GOST 34.10-2001
>for signing and GOST 34.11-94 for digest computation.
>
>The document is generally clearly written and usable, but I'm
>concerned about how the document manages algorithm parameters. The
>cryptographic computations described in this document all use a single
>set of parameters, even though RFC 4357 defines at least four other
>sets of signing parameters, and parameter selection is permitted by
>several analogous drafts: RFC 3110 (RSA/SHA1 for DNSSEC) allows the
>RSA modulus to be specified, and RFCs 4490 and 4491 (the analogous
>documents for PKIX and CMS) allow the use of arbitrary GOST
>parameters.  "Hard-wiring" algorithm parameters to an algorithm
>number, as this draft does, increases the burden on the algorithm
>number space because it requires a separate number for each
>combination of parameters that can be used.

Richard
thanks for your excellent review,
As for the hard-wiring of one curve that is intentional.
DNS is a "broadcast" protocol thus the signer can not make any assumptions
about the capabilities of parties that may want to verify the
data. For this reason having explicit curve specified as better from
operational perspective. The only reason to define a new curve is to
either get a better hash algorithm or a stronger/larger curve.
The other options do not provide any of these.


>I also agree with the comments from Steve and Paul that the "SHOULD
>support GOST" in Section 6.1 should be a "MAY".
>
>Detailed comments follow.
>
>--Richard
>
>
>
>Section 1, second paragraph:
>It would be helpful to refer to the english versions of the algorithm
>descriptions (draft-dolmatov-cryptocom-gost*) at this point.

Good point, the document should be updated to refer to both.

>Section 1, fourth paragraph:
>There should be an "and" before "GOST 28147-89".
>
>Section 2.1:
>
>It would be really helpful if you could explain what this sequence of
>bytes means.  Putting on my ASN.1/DER thinking cap, I managed to
>figure out that it's creating a SubjectPublicKeyInfo structure; I
>would suggest saying that, and maybe including a diagram like the
>following (which makes it even clearer that the algorithm parameters
>are being fixed):
>
>SubjectPublicKeyInfo {
>    algorithm: AlgorithmIdentifier {
>        algorithm: id-GostR3410-2001
>        params: GostR3410-2001-PublicKeyParams {
>            publicKeyParamSet: id-Gost3410-2001-CryptoPro-A-ParamSet
>            digestParamSet: id-Gost3411-94-CryptoProParamSet
>            encryptionParamSet: id-Gost3411-94-CryptoProParamSet
>[default]
>        }
>    }
>    subjectPublicKey: GostR3410-2001-PublicKey [64 key bytes]
>}

To DNS people these are simply bytes and we do not really mean,
but your point is taken and I will see about adding this to the
document.

>Of course, if implementations are going to be tied to this data
>structure, the only possible parameters they can use are ones that
>have an OID, e.g., those defined in RFC 4357 (this limitation is due
>to the fact that the GostR3410-2001-PublicKeyParams structure only
>allows parameters to be defined by reference).  However, you could
>still allow any OID to be used in the *ParamSet fields and provide
>some simple instructions on how to patch together a
>SubjectPublicKeyInfo structure out of them.

I think this goes against our intent of tight specification of what
is allowed.

>Section 3, second paragraph:
>For clarity, it would be helpful to use the notation of RFC 4034 here,
>e.g.:
>  hash = GOST3411( RRSIG_RDATA | RR(1) | RR(2) | ... )
>
>Section 3.1, last paragraph:
>In order to let people use this example as a test vector, you should
>include the random value that was used to compute this signature.
>

Good points,

>Section 5:
>This section seems unnecessary, since GOST has only one size for keys,
>signatures, and digests.

I agree but the section is "mostly harmless"

>Section 6.2:
>Should the "required" here be "REQUIRED"?

That should read
"DNSSEC-GOST implementations are REQUIRED to support both NSEC and
NSEC3 for GOST signed zones."


>Section 6.3:
>This paragraph contradicts Section 3 (and thus RFC 4490), which says
>the signatures are provided in big-endian order.  I think the general
>point is that you're sticking with the byte orders that have been
>previously defined.
>

I read this section to only cover the DNSKEY material not the signature.

         Olafur



From ogud@ogud.com  Fri Jan 15 07:16:18 2010
Return-Path: <ogud@ogud.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453893A6A5D for <secdir@core3.amsl.com>; Fri, 15 Jan 2010 07:16:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.659
X-Spam-Level: 
X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eySh30KVxkMU for <secdir@core3.amsl.com>; Fri, 15 Jan 2010 07:16:17 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 3DAE33A6A33 for <secdir@ietf.org>; Fri, 15 Jan 2010 07:16:17 -0800 (PST)
Received: from valholl.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0FFG8aO085884; Fri, 15 Jan 2010 10:16:08 -0500 (EST) (envelope-from ogud@ogud.com)
Message-Id: <201001151516.o0FFG8aO085884@stora.ogud.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 15 Jan 2010 10:16:04 -0500
To: secdir-secretary@mit.edu, "Richard L. Barnes" <rbarnes@bbn.com>
From: Olafur Gudmundsson <ogud@ogud.com>
In-Reply-To: <alpine.BSF.2.00.1001141826160.70709@fledge.watson.org>
References: <E18FB588-FA46-447B-828F-BF98527D6725@bbn.com> <alpine.BSF.2.00.1001141826160.70709@fledge.watson.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20
X-Mailman-Approved-At: Fri, 15 Jan 2010 08:02:23 -0800
Cc: draft-ietf-dnsext-dnssec-gost@tools.ietf.org, dnsext-chairs@tools.ietf.org, secdir <secdir@ietf.org>
Subject: Re: [secdir] Review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jan 2010 15:16:18 -0000

At 18:43 14/01/2010, Samuel Weiler wrote:
>On Thu, 14 Jan 2010, Richard L. Barnes wrote:
>
>>Section 5:
>>This section seems unnecessary, since GOST has only one size for 
>>keys, signatures, and digests.
>
> From the perspective of the DNS world, I think being explicit about 
> this is actually pretty handy.  I see benefit in leaving it.
>
>Other than that, I generally concur with the secdir reviews received 
>to date, particuarly the lowering of the requirement level.
>
>
>Also, while I haven't thoroughly reviewed this draft since April 
>2009 (when the DNSEXT WG was asking whether to adopt it or not), a 
>couple of things jump out, which I'll share now rather than wait for 
>the IETF last call:



>Section 6.2, on NSEC3 support, is a little vague.  I think the doc 
>means "zones signed with the algorithms specified in this document 
>may use either NSEC or NSEC3 and validators supporting this 
>algorithm must support both NSEC and NSEC3".  I'm not sure my 
>wording is much clearer, but a change is needed.
>
>In the IANA considerations, do not use the asterisk.  Just say that 
>this algorithm suite isn't being defined for transaction security mechanisms.

I agree the document should say one way or the other, not supporting
Transaction security is easier on all.


>Also, the IANA considerations section includes the requirement 
>status column, which implicitly assumes that we are advancing 
>draft-ietf-dnsext-dnssec-registry-fixes-01.  I'm not convinced 
>that's going to happen any time soon, particularly given the 
>lackluster response to draft-ogud-iana-protocol-maintenance-words, 
>which it depends on.  So... that needs to be tracked.  It's not 
>necessary to cite registry-fixes, but it probably is necessary to 
>treat it as a dependency for publication purposes.

Good point, will talk to AD about this before the document
goes to the IESG after IETF LC ends.

         Olafur 


From new-work-bounces@ietf.org  Tue Jan 19 12:28:57 2010
Return-Path: <new-work-bounces@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 842BF3A6A26; Tue, 19 Jan 2010 12:28:57 -0800 (PST)
X-Original-To: new-work@ietf.org
Delivered-To: new-work@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 710F53A6A1A; Tue, 19 Jan 2010 12:28:55 -0800 (PST)
From: IESG Secretary <iesg-secretary@ietf.org>
To: new-work@ietf.org
Mime-Version: 1.0
Message-Id: <20100119202856.710F53A6A1A@core3.amsl.com>
Date: Tue, 19 Jan 2010 12:28:56 -0800 (PST)
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: new-work-bounces@ietf.org
Errors-To: new-work-bounces@ietf.org
X-Mailman-Approved-At: Tue, 19 Jan 2010 12:43:08 -0800
Subject: [secdir] [New-work] WG Review: Recharter of Mobility Extensions (netext)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jan 2010 20:28:57 -0000

A modified charter has been submitted for the Mobility Extensions (netext)
working group in the Internet Area of the IETF.  The IESG has not made any
determination as yet.  The modified charter is provided below for
informational purposes only.  Please send your comments to the IESG
mailing list (iesg@ietf.org) by Tuesday, January 26, 2010.

This update of the NETEXT working group's charter involves adding work
items related to cross-interface handover and flow mobility that were
discussed in the NETEXT2 BOF but not adopted by the IETF. After
discussions in the NETEXT WG meeting in Hiroshima, a significantly
reduced scope for the work was adopted, and this work is now being added
to the charter. In addition, one work item on RADIUS support moves from
the NETLMM WG to this WG. The differences to the current charter can be
seen at
http://www.arkko.com/ietf/netext/recharter_new_jari2-from-old.diff.html

Mobility Extensions (netext)
----------------------------
Last Modified: 2010-01-19

Current Status: Active Working Group

Additional information is available at tools.ietf.org/wg/netext

Chair(s):

* Rajeev Koodli <rkoodli@starentnetworks.com>
* Basavaraj Patil <basavaraj.patil@nokia.com>

Internet Area Director(s):

* Ralph Droms <rdroms@cisco.com>
* Jari Arkko <jari.arkko@piuha.net>

Internet Area Advisor:

* Jari Arkko <jari.arkko@piuha.net>

Mailing Lists:
General Discussion: netext@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/netext
Archive: http://www.ietf.org/mail-archive/web/netext/current/maillist.html



Description of Working Group:

Proxy Mobile IPv6, specified in RFC 5213, is a network-based mobility
protocol. It uses a Mobile Access Gateway (MAG) and a Local Mobility
Anchor (LMA) to allow hosts to move around within a domain while keeping
their address or address prefix stable. Proxy Mobile IPv6 has been
incorporated into a number of products and deployments are starting.
Certain deployment considerations, including localized routing and bulk
refresh of lifetime are already emerging.

The working group will focus on the following topics relevant for
network-based mobility:

Localized Routing: a specification for routing traffic between the
MAG(s) without involving the LMA. That is, allow the MAGs to route
traffic between hosts from one MAG to another, without being tunneled
all the way to the LMA. This reduces latency and backhaul load.
Applications such as voice can benefit from the reduced latency.

Bulk Refresh: a specification of improving the signaling load for
binding lifetime refresh. The current specifications call for the
handling of each mobility session independent of each other. When a
large number of hosts are served by a single MAG, a periodic refresh of
the binding lifetimes can lead to a signaling storm. The purpose of the
Bulk Refresh feature is to construct a protocol feature that allows such
refreshes to occur on a per-MAG basis.

LMA Redirection: a specification for allowing an LMA to redirect a MAG
to another LMA. This is primarily needed as a way to perform load
balancing. This functionality is complementary to implementation
techniques that allow distributed MAG implementations to move tasks
around without a visible impact at the protocol level, and the
initial LMA discovery work in the NETLMM WG. An applicability statement
describing the situations where the new functionality is or is not
applicable has to be included in the specification.

Hiding access technology changes from host IP layer: Proxy mobility is
based on the assumption that changes in host IP stacks are
undesirable. However, link layer implementations can hide the
actually used physical interfaces from the IP stack. For instance, a
single interface might transmit packets over different media, as is
common practice in certain radio networks. This can be used to achieve
inter-access handovers or flow mobility, i.e., the movement of
selected flows from one access technology to another. The
specification of any actual link layer mechanisms is outside the scope
of the working group, but the group works on the following:

- Informational applicability statement that analyzes the issues
involved with this approach and characterizes the contexts in which
such use is or is not appropriate.

- The working group will determine if protocol extensions are required
between the Proxy Mobile IPv6 network nodes (MAGs and LMAs) to
support the ability for a single host interface to transmit packets
over different media and the ability to distribute specific traffic
flows on different media components of that single interface. The
relevant protocol extensions will be developed as necessary. The WG
will assume that there the host has an interface that is capable of
employing multiple media.

Radius Extensions to PMIP6: In order to enable network based
mobility using PMIP6, the policy profile needs to signal a set of
attributes and policies to the MAG and LMA. New Radius attributes
need to be specified that are relevant to PMIP6 based
mobility. This work item will specify Radius extensions and
attributes specific to PMIP6.

The work in this charter is entirely internal to the network and does
not affect host IP stack operation in any way (except perhaps through
impacting packet forwarding capacity visible to the hosts). The working
group is not allowed to specify new IP layer protocol mechanisms to signal
mobility related events between the host and the network.

The proposed activity will be complementary to the existing IETF Working
Groups, notably the NETLMM and MEXT WGs. The NETEXT working group will
also act as the primary forum where new extensions on top of the Proxy
Mobile IPv6 protocol can be developed. The addition of such new
extensions to the working group involves addition of the extension to
this charter through the normal rechartering process.

Goals and Milestones:

May 2009 WG chartered
Jul 2009 Initial WG draft on Bulk Refresh
Jul 2009 Decision on the inclusion of possible additional work
items
Sep 2009 Initial WG draft on LMA Redirection
Sep 2009 Initial WG draft on Localized Routing
Dec 2009 Submit Bulk Refresh to IESG for publication as a
Proposed Standard RFC
Jan 2010 Submit LMA Redirection to IESG for publication as a
Proposed Standard RFC
Mar 2010 Initial WG document on RADIUS extensions to PMIP6
Apr 2010 Submit Localized Routing to IESG for publication as a
Proposed Standard RFC
May 2010 Initial WG document on Applicability Statement on
Multiple Media on One Interface
Jun 2010 WG decision on what Proxy Mobile IPv6 support is needed
to support multiple media on one interface
Sep 2010 Initial WG document(s) on Proxy Mobile IPv6 Extensions
to Support Multiple Media on One Interface
Oct 2010 Submit RADIUS extensions to PMIP6 to IESG for
publication as a Proposed Standard
Dec 2010 Submit Applicability Statement on Multiple Media on One
Interface to IESG for publication as Informational RFC
Feb 2011 Submit Proxy Mobile IPv6 Extensions to Support Multiple
Media on One Interface for publication as Proposed Standard RFC(s)

_______________________________________________
New-work mailing list
New-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work

From jsalowey@cisco.com  Wed Jan 20 11:36:55 2010
Return-Path: <jsalowey@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD01C3A681D; Wed, 20 Jan 2010 11:36:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.984
X-Spam-Level: 
X-Spam-Status: No, score=-9.984 tagged_above=-999 required=5 tests=[AWL=0.615,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PGCnUBtm-W1; Wed, 20 Jan 2010 11:36:54 -0800 (PST)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id D158B3A67AA; Wed, 20 Jan 2010 11:36:54 -0800 (PST)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEACrqVkurRN+K/2dsb2JhbADFUZVkhDYE
X-IronPort-AV: E=Sophos;i="4.49,312,1262563200"; d="scan'208";a="77057371"
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 20 Jan 2010 19:36:51 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o0KJaoEF013951; Wed, 20 Jan 2010 19:36:51 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 20 Jan 2010 11:36:50 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 20 Jan 2010 11:36:49 -0800
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE50971A98A@xmb-sjc-225.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: secdir Review of draft-ietf-pana-preauth-08
Thread-Index: AcqaB+ivLuYfxyn5SqyKWg++bb7fJg==
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: <secdir@ietf.org>, <iesg@ietf.org>, <draft-ietf-pana-preauth@tools.ietf.org>, <pana-chairs@tools.ietf.org>
X-OriginalArrivalTime: 20 Jan 2010 19:36:50.0924 (UTC) FILETIME=[E9AB32C0:01CA9A07]
Subject: [secdir] secdir Review of draft-ietf-pana-preauth-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jan 2010 19:36:55 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these as
comments just like any other last call comments.  I apologize for the
late review. =20

I did not find any major issues with the document.  The security
considerations section does describe the additional DOS threat
associated with the operation of the protocol.  I think the potential
mitigations could be described better.  1) it seems that the stateless
PCI should be moved up in the section since it is related to the last
sentence of the first paragraph. 2) it's not clear that "authorized" is
the best word to use here since authentication has not completed yet.
It might be better to say "It is recommended that messages are only
accepted from PACs originating from well known IP networks for a given
PAA."  It's not really clear how effective or practical this restriction
would be, but I'm not very familiar with PANA deployments. =20

Cheers,

Joe

From alper.yegin@yegin.org  Wed Jan 20 11:57:38 2010
Return-Path: <alper.yegin@yegin.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B0F13A681D; Wed, 20 Jan 2010 11:57:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.747
X-Spam-Level: 
X-Spam-Status: No, score=0.747 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_06_12=1.897, MSGID_MULTIPLE_AT=1.449]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBGZEW9J9t7w; Wed, 20 Jan 2010 11:57:37 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 51DF63A63EC; Wed, 20 Jan 2010 11:57:37 -0800 (PST)
Received: from ibm ([12.166.168.227]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MFLUi-1NaySl0sDs-00ESBL; Wed, 20 Jan 2010 14:57:28 -0500
From: "Alper Yegin" <alper.yegin@yegin.org>
To: "'Joseph Salowey \(jsalowey\)'" <jsalowey@cisco.com>, <secdir@ietf.org>, <iesg@ietf.org>, <draft-ietf-pana-preauth@tools.ietf.org>, <pana-chairs@tools.ietf.org>
References: <AC1CFD94F59A264488DC2BEC3E890DE50971A98A@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE50971A98A@xmb-sjc-225.amer.cisco.com>
Date: Wed, 20 Jan 2010 21:57:05 -0800
Message-ID: <04ba01ca9a5e$93c5fd70$bb51f850$@yegin@yegin.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcqaB+ivLuYfxyn5SqyKWg++bb7fJgAVYKaA
Content-Language: en-us
X-Provags-ID: V01U2FsdGVkX1/yFSPR1f96h+9Xn1LIrjX4fChpbLAATI8MIva WONRBCNHVI2jsX3ENCp41b13zqUG5sLwgzd0l0E59/MFj3oAKL Bc2bDd2/xNp5Ik0Teq85RljDTLEavdn
Subject: Re: [secdir] secdir Review of draft-ietf-pana-preauth-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jan 2010 19:57:38 -0000

Thank you Joe.

Let me re-massage the security considerations section using your comments:

6. Security Considerations

   This specification is based on the PANA protocol and it exhibits the
   same security properties, except for one important difference: Pre-
   authenticating PaCs are not physically connected to an access network
   associated with the PAA, but they are connected to some other network
   somewhere else on the Internet.  This distinction can create greater
   DoS vulnerability for systems using PANA pre-authentication if
   appropriate measures are not taken.  An unprotected PAA can be forced
   to create state by an attacker PaC which merely sends PCI messages.

   [RFC5191] describes how PAA can stay stateless while
   responding to incoming PCIs.  PAAs using pre-authentication SHOULD be
   following those guidelines (see [RFC5191] Section 4.1).

   Furthermore, it is recommended that PANA pre-authentication messages are
only
   accepted from PACs originating from well-known IP networks (e.g.,
physically 
   adjacent networks) for a given PAA. These IP networks can be used with a
   white-list implemented either on the firewall protecting the perimeter
around
   the PAA, or on the PAA itself. This prevention measure SHOULD be used
whenever 
   it can be practically applied to a given deployment.






> -----Original Message-----
> From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]
> Sent: Wednesday, January 20, 2010 11:37 AM
> To: secdir@ietf.org; iesg@ietf.org; draft-ietf-pana-
> preauth@tools.ietf.org; pana-chairs@tools.ietf.org
> Subject: secdir Review of draft-ietf-pana-preauth-08
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.
> These comments were written primarily for the benefit of the security
> area directors.  Document editors and WG chairs should treat these as
> comments just like any other last call comments.  I apologize for the
> late review.
> 
> I did not find any major issues with the document.  The security
> considerations section does describe the additional DOS threat
> associated with the operation of the protocol.  I think the potential
> mitigations could be described better.  1) it seems that the stateless
> PCI should be moved up in the section since it is related to the last
> sentence of the first paragraph. 2) it's not clear that "authorized" is
> the best word to use here since authentication has not completed yet.
> It might be better to say "It is recommended that messages are only
> accepted from PACs originating from well known IP networks for a given
> PAA."  It's not really clear how effective or practical this
> restriction
> would be, but I'm not very familiar with PANA deployments.
> 
> Cheers,
> 
> Joe



From phoffman@imc.org  Wed Jan 20 12:32:34 2010
Return-Path: <phoffman@imc.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D724E3A65A6 for <secdir@core3.amsl.com>; Wed, 20 Jan 2010 12:32:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.046
X-Spam-Level: 
X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAXcKaVk1Vty for <secdir@core3.amsl.com>; Wed, 20 Jan 2010 12:32:34 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 25B1C3A697B for <secdir@ietf.org>; Wed, 20 Jan 2010 12:32:34 -0800 (PST)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0KKWN7G074896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jan 2010 13:32:25 -0700 (MST) (envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p0624080bc77d18bca7a1@[10.20.30.158]>
In-Reply-To: <201001151516.o0FFG8aO085884@stora.ogud.com>
References: <E18FB588-FA46-447B-828F-BF98527D6725@bbn.com> <alpine.BSF.2.00.1001141826160.70709@fledge.watson.org> <201001151516.o0FFG8aO085884@stora.ogud.com>
Date: Wed, 20 Jan 2010 12:32:22 -0800
To: Olafur Gudmundsson <ogud@ogud.com>, secdir-secretary@mit.edu, "Richard L. Barnes" <rbarnes@bbn.com>
From: Paul Hoffman <phoffman@imc.org>
Content-Type: text/plain; charset="us-ascii"
Cc: draft-ietf-dnsext-dnssec-gost@tools.ietf.org, dnsext-chairs@tools.ietf.org, secdir <secdir@ietf.org>
Subject: Re: [secdir] Review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jan 2010 20:32:34 -0000

At 10:16 AM -0500 1/15/10, Olafur Gudmundsson wrote:
>At 18:43 14/01/2010, Samuel Weiler wrote:
>>Also, the IANA considerations section includes the requirement status column, which implicitly assumes that we are advancing draft-ietf-dnsext-dnssec-registry-fixes-01.  I'm not convinced that's going to happen any time soon, particularly given the lackluster response to draft-ogud-iana-protocol-maintenance-words, which it depends on.  So... that needs to be tracked.  It's not necessary to cite registry-fixes, but it probably is necessary to treat it as a dependency for publication purposes.
>
>Good point, will talk to AD about this before the document
>goes to the IESG after IETF LC ends.

Will you also bring this to the WG?

From jsalowey@cisco.com  Thu Jan 21 08:22:26 2010
Return-Path: <jsalowey@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F272D28C168; Thu, 21 Jan 2010 08:22:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.052
X-Spam-Level: 
X-Spam-Status: No, score=-10.052 tagged_above=-999 required=5 tests=[AWL=0.547, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmQJZwXritpj; Thu, 21 Jan 2010 08:22:24 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id AB26D3A6989; Thu, 21 Jan 2010 08:22:24 -0800 (PST)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAPcNWEurRN+J/2dsb2JhbADDY5YXhDwE
X-IronPort-AV: E=Sophos;i="4.49,318,1262563200"; d="scan'208";a="137672256"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 21 Jan 2010 16:22:20 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o0LGMKpk017526; Thu, 21 Jan 2010 16:22:20 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 21 Jan 2010 08:22:20 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 21 Jan 2010 08:22:18 -0800
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE509792659@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <04ba01ca9a5e$93c5fd70$bb51f850$@yegin@yegin.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: secdir Review of draft-ietf-pana-preauth-08
Thread-Index: AcqaB+ivLuYfxyn5SqyKWg++bb7fJgAVYKaAABYVcBA=
References: <AC1CFD94F59A264488DC2BEC3E890DE50971A98A@xmb-sjc-225.amer.cisco.com> <04ba01ca9a5e$93c5fd70$bb51f850$@yegin@yegin.org>
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "Alper Yegin" <alper.yegin@yegin.org>, <secdir@ietf.org>, <iesg@ietf.org>,  <draft-ietf-pana-preauth@tools.ietf.org>, <pana-chairs@tools.ietf.org>
X-OriginalArrivalTime: 21 Jan 2010 16:22:20.0688 (UTC) FILETIME=[E8144100:01CA9AB5]
Subject: Re: [secdir] secdir Review of draft-ietf-pana-preauth-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jan 2010 16:22:26 -0000

Thanks Alper,

This looks better.

Cheers,

Joe

> -----Original Message-----
> From: Alper Yegin [mailto:alper.yegin@yegin.org]
> Sent: Wednesday, January 20, 2010 9:57 PM
> To: Joseph Salowey (jsalowey); secdir@ietf.org; iesg@ietf.org;
draft-ietf-
> pana-preauth@tools.ietf.org; pana-chairs@tools.ietf.org
> Subject: RE: secdir Review of draft-ietf-pana-preauth-08
>=20
> Thank you Joe.
>=20
> Let me re-massage the security considerations section using your
comments:
>=20
> 6. Security Considerations
>=20
>    This specification is based on the PANA protocol and it exhibits
the
>    same security properties, except for one important difference: Pre-
>    authenticating PaCs are not physically connected to an access
network
>    associated with the PAA, but they are connected to some other
network
>    somewhere else on the Internet.  This distinction can create
greater
>    DoS vulnerability for systems using PANA pre-authentication if
>    appropriate measures are not taken.  An unprotected PAA can be
forced
>    to create state by an attacker PaC which merely sends PCI messages.
>=20
>    [RFC5191] describes how PAA can stay stateless while
>    responding to incoming PCIs.  PAAs using pre-authentication SHOULD
be
>    following those guidelines (see [RFC5191] Section 4.1).
>=20
>    Furthermore, it is recommended that PANA pre-authentication
messages
> are
> only
>    accepted from PACs originating from well-known IP networks (e.g.,
> physically
>    adjacent networks) for a given PAA. These IP networks can be used
with
> a
>    white-list implemented either on the firewall protecting the
perimeter
> around
>    the PAA, or on the PAA itself. This prevention measure SHOULD be
used
> whenever
>    it can be practically applied to a given deployment.
>=20
>=20
>=20
>=20
>=20
>=20
> > -----Original Message-----
> > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]
> > Sent: Wednesday, January 20, 2010 11:37 AM
> > To: secdir@ietf.org; iesg@ietf.org; draft-ietf-pana-
> > preauth@tools.ietf.org; pana-chairs@tools.ietf.org
> > Subject: secdir Review of draft-ietf-pana-preauth-08
> >
> > I have reviewed this document as part of the security directorate's
> > ongoing effort to review all IETF documents being processed by the
> > IESG.
> > These comments were written primarily for the benefit of the
security
> > area directors.  Document editors and WG chairs should treat these
as
> > comments just like any other last call comments.  I apologize for
the
> > late review.
> >
> > I did not find any major issues with the document.  The security
> > considerations section does describe the additional DOS threat
> > associated with the operation of the protocol.  I think the
potential
> > mitigations could be described better.  1) it seems that the
stateless
> > PCI should be moved up in the section since it is related to the
last
> > sentence of the first paragraph. 2) it's not clear that "authorized"
is
> > the best word to use here since authentication has not completed
yet.
> > It might be better to say "It is recommended that messages are only
> > accepted from PACs originating from well known IP networks for a
given
> > PAA."  It's not really clear how effective or practical this
> > restriction
> > would be, but I'm not very familiar with PANA deployments.
> >
> > Cheers,
> >
> > Joe
>=20


From weiler+secdir@watson.org  Thu Jan 21 21:14:57 2010
Return-Path: <weiler+secdir@watson.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 766763A686E for <secdir@core3.amsl.com>; Thu, 21 Jan 2010 21:14:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDzMhAcK9-SJ for <secdir@core3.amsl.com>; Thu, 21 Jan 2010 21:14:56 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 9D1D63A6864 for <secdir@ietf.org>; Thu, 21 Jan 2010 21:14:56 -0800 (PST)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o0M5Epq1041750 for <secdir@ietf.org>; Fri, 22 Jan 2010 00:14:51 -0500 (EST) (envelope-from weiler+secdir@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o0M5Ep4l041747 for <secdir@ietf.org>; Fri, 22 Jan 2010 00:14:51 -0500 (EST) (envelope-from weiler+secdir@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Fri, 22 Jan 2010 00:14:51 -0500 (EST)
From: Samuel Weiler <weiler+secdir@watson.org>
X-X-Sender: weiler@fledge.watson.org
To: secdir@ietf.org
Message-ID: <alpine.BSF.2.00.1001211541100.72544@fledge.watson.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 22 Jan 2010 00:14:51 -0500 (EST)
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: secdir-secretary@mit.edu
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jan 2010 05:14:57 -0000

Derek Atkins is next in the rotation.

Documents on the telechat agenda typically have a last call end date 
before the date shown below; reviews by the end of last call are 
typically more appreciated by the doc editors.

Review instructions and related resources are at:
       http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

-- Sam

For telechat 2010-02-04

Reviewer                 Deadline   Draft
Alan DeKok             T 2010-02-02 draft-ietf-capwap-802dot11-mib-06
Carl Wallace           T 2010-02-02 draft-ietf-ccamp-pc-spc-rsvpte-ext-06
Tom Yu                 T 2010-02-02 draft-ietf-6man-text-addr-representation-04

Last calls and special requests:

Reviewer                 Deadline   Draft
Rob Austein              2009-11-28 draft-ietf-pkix-attr-cert-mime-type-02
Alan DeKok               2009-10-01 draft-ietf-enum-enumservices-transition-04
Love Hornquist-Astrand   2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05
Love Hornquist-Astrand   2009-10-13 draft-ietf-idnabis-mappings-05
David McGrew             None       draft-ietf-dnsext-dnssec-gost-06
Catherine Meadows        2008-01-17 draft-ietf-speechsc-mrcpv2-20
Sandy Murphy            R2009-11-18 draft-ietf-mpls-mpls-and-gmpls-security-framework-07
Sandy Murphy             2010-01-14 draft-turner-ecprivatekey-02
Vidya Narayanan          2008-11-21 draft-ietf-sip-saml-06
Chris Newman             2010-01-07 draft-ietf-krb-wg-preauth-framework-15
Joe Salowey              2009-02-08 draft-ietf-geopriv-lis-discovery-13
Hannes Tschofenig        2010-02-05 draft-allbery-afs-srv-records-03
Tina TSOU                2010-02-01 draft-roach-sip-http-subscribe-06
Sam Weiler               2008-08-13 draft-chown-v6ops-rogue-ra-03
Sam Weiler               2010-01-27 draft-ietf-sipcore-199-02
Brian Weis               2010-01-28 draft-ietf-nsis-y1541-qosm-08
Nico Williams            2008-08-13 draft-ietf-v6ops-ra-guard-04
Nico Williams            2010-02-16 draft-gould-rfc4310bis-03
Larry Zhu                2008-08-13 draft-thaler-v6ops-teredo-extensions-05
Larry Zhu                2009-05-09 draft-ietf-ecrit-location-hiding-req-02
Larry Zhu                2010-01-29 draft-ietf-pce-p2mp-req-04
Glen Zorn                2010-01-28 draft-ietf-pkix-tamp-05

From simon@josefsson.org  Fri Jan 22 00:29:16 2010
Return-Path: <simon@josefsson.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E51A3A6359; Fri, 22 Jan 2010 00:29:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level: 
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3LPNJ0Xz1+G; Fri, 22 Jan 2010 00:29:15 -0800 (PST)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id CA4FE3A672E; Fri, 22 Jan 2010 00:29:14 -0800 (PST)
Received: from mocca (c80-216-24-99.bredband.comhem.se [80.216.24.99]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0M8T0tv010670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 22 Jan 2010 09:29:02 +0100
From: Simon Josefsson <simon@josefsson.org>
To: Magnus =?iso-8859-1?Q?Nystr=F6m?= <magnusn@gmail.com>
References: <2f57b9e60912231723x12e87864g9c0ad1ce095fc2c2@mail.gmail.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:100122:magnusn@gmail.com::bCvRJ6KDbi3bxkzF:1E9m
X-Hashcash: 1:22:100122:jhutz@cmu.edu::9Ett7qsZcMV4nW4Y:1MaI
X-Hashcash: 1:22:100122:secdir@ietf.org::3Ls98g7aRVFK9ize:GxEC
X-Hashcash: 1:22:100122:iesg@ietf.org::fpHZfEBlVLudMgA8:M/vJ
X-Hashcash: 1:22:100122:larry.zhu@microsoft.com::Cfi0J1hAEKGAcqAO:Lc86
Date: Fri, 22 Jan 2010 09:29:01 +0100
In-Reply-To: <2f57b9e60912231723x12e87864g9c0ad1ce095fc2c2@mail.gmail.com> ("Magnus =?iso-8859-1?Q?Nystr=F6m=22's?= message of "Wed, 23 Dec 2009 17:23:29 -0800")
Message-ID: <87zl46h7aq.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Cc: larry.zhu@microsoft.com, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-josefsson-kerberos5-starttls-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jan 2010 08:29:16 -0000

Magnus Nyström <magnusn@gmail.com> writes:

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.

Thank you for the review!

> This document defines a new Kerberos extension to allow Kerberos
> protocol runs over TLS.
>
> I do not have any general issues with this document but a few
> questions/comments:
>
> Section 1: "The TLS protocol has been studied by many parties.  In
> some threat models, the designer prefer to reduce the number of
> protocols that can hurt the overall system security if they are
> compromised." This statement seems to me like a strange reason to
> motivate this work - Kerberos is equally well studied (at least) as
> TLS and this memo does not reduce the number of protocols in the
> system (c.f. the recent TLS renegotiation vulnerability)

I have removed the paragraph.

That paragraph was intended to contrast with PKINIT which to my
knowledge has not been studied as thoroughly as the core Kerberos
protocol or TLS.

> Section 3: In the packet flow, why are the first two Kerberos
> exchanges ([0x70000000 & STARTTLS-bit] and [0x00000000]) wihtin square
> brackets? Is it because they're seen as a separate protocol, or some
> other reason? A clarification would be helpful.

Good catch -- after studying that part, I noticed that it is also
incorrect.  It should be 0x80000000 | STARTTLS-BIT.  Further, the binary
operator was not explained.  The brackets are indeed not helpful.  Here
is the new text:

   A complete packet flow for a successful AS-REQ/REP exchange protected
   by this mechanism will be as follows.  The "STARTTLS-bit" is a
   4-octet value with only the bit allocated for this extension set, and
   | is the binary OR operation.

       Client                                               Server

        [ Kerberos V5 TCP extension mechanism negotiation starts ]

       0x80000000 | STARTTLS-bit  -------->
                                                       0x00000000
                                    <--------

Further, when reading the protocol explanation in the previous section,
it wasn't clear that the client actually initiates the communication,
and there were no pointer on handling errors at that point.  Here is the
new text:

   The protocol is as follows.  The client requests the extension by
   setting the STARTTLS bit in the TCP extension mechanism bitmask.
   (How to deal with extension negotiation failures at this point is
   described in [RFC5021].)  After the server has sent the 4-octet value
   0x00000000 to indicate support of this extension, the stream will be
   controlled by the TLS protocol and its framing.  The TLS protocol is
   initiated by the client.

> Section 5: "Use of TLS, even without server certificate validation,
> protects against some attacks that Kerberos V5 over UDP/TCP do not.
> Requiring server certificates to be used at all times would enable
> attacks in those situations": a) It would be useful to give examples
> of attacks that unauthenticated TLS protects against that Kerberos V5
> does not protect against.

I have added:

     (For example, passive network sniffing between the user and the KDC
     to track which Kerberos services are used by the user.)

> b) Last sentence is ambigious - if server certs are required and the
> client verifies them I do not see what attacks would be enabled. I
> assume the last sentence intends to say that requiring server certs to
> be used when clients cannot validate will enable some attacks but I am
> not sure.

Good catch, it didn't say what was intended.  I have changed it to:

   To require server certificates to be validated at all times would
   lead to disabling of TLS when clients are unable to validate server
   certificates, and this may have worse security properties than using
   TLS and not validate the server certificate would have.

It feels a bit clumsily, suggestions on easier ways to express the same
intent are welcome.

> Section 5: "When clients have the ability, they need to be able to
> validate the server certificate" I suggest rephrasing to: "When
> clients have the ability, they MUST validate the server certificate"

I have made this change.

Regards,
/Simon

From simon@josefsson.org  Fri Jan 22 00:36:21 2010
Return-Path: <simon@josefsson.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73BC73A685B; Fri, 22 Jan 2010 00:36:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level: 
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgYUu7Ad+sWM; Fri, 22 Jan 2010 00:36:20 -0800 (PST)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 434393A6859; Fri, 22 Jan 2010 00:36:20 -0800 (PST)
Received: from mocca (c80-216-24-99.bredband.comhem.se [80.216.24.99]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id o0M8a8gB010775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 22 Jan 2010 09:36:09 +0100
From: Simon Josefsson <simon@josefsson.org>
To: Magnus =?iso-8859-1?Q?Nystr=F6m?= <magnusn@gmail.com>
References: <2f57b9e60912231723x12e87864g9c0ad1ce095fc2c2@mail.gmail.com> <87zl46h7aq.fsf@mocca.josefsson.org>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:100122:iesg@ietf.org::Y976eEVjTjtrRm9f:0aie
X-Hashcash: 1:22:100122:magnusn@gmail.com::P4r2GfVldE/I4JaL:CuT6
X-Hashcash: 1:22:100122:secdir@ietf.org::OZFnzSUla9Dt2B/L:D37d
X-Hashcash: 1:22:100122:larry.zhu@microsoft.com::UelYeZDTjLj0Q30Y:PcvW
X-Hashcash: 1:22:100122:jhutz@cmu.edu::FLXzRXcMU9EXIXE8:w3+E
Date: Fri, 22 Jan 2010 09:36:08 +0100
In-Reply-To: <87zl46h7aq.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri, 22 Jan 2010 09:29:01 +0100")
Message-ID: <87k4vafsef.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: larry.zhu@microsoft.com, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-josefsson-kerberos5-starttls-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jan 2010 08:36:21 -0000

I have published -08 to fix these comments, see:

http://www.ietf.org/id/draft-josefsson-kerberos5-starttls-08.txt

The tools.ietf.org service does not yet provide a diff to compare -07
with -08, meanwhile I have created a page for that:

http://josefsson.org/krb5starttls/draft-josefsson-kerberos5-starttls-08-from-7.diff.html

Let me know if this doesn't solve your concerns.

Thanks,
/Simon

From kent@bbn.com  Sun Jan 24 11:14:12 2010
Return-Path: <kent@bbn.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 611E33A68BD for <secdir@core3.amsl.com>; Sun, 24 Jan 2010 11:14:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=-0.001,  BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXD2J40IGGPC for <secdir@core3.amsl.com>; Sun, 24 Jan 2010 11:14:11 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 0E99F3A6824 for <secdir@ietf.org>; Sun, 24 Jan 2010 11:14:11 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.242.22.104]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from <kent@bbn.com>) id 1NZ7uV-0006M8-Ae; Sun, 24 Jan 2010 14:14:11 -0500
Mime-Version: 1.0
Message-Id: <p0624080bc78249fa2c22@[10.242.22.104]>
In-Reply-To: <4B5B40FB.8060007@cryptocom.ru>
References: <p06240810c76be77be756@[128.89.89.161]> <20100107222809.GA25747@shinkuro.com> <p06240818c76c1a38cbf8@[128.89.89.161]> <20100108144431.GB26259@shinkuro.com> <4B5B40FB.8060007@cryptocom.ru>
Date: Sun, 24 Jan 2010 14:14:07 -0500
To: Basil Dolmatov <dol@cryptocom.ru>
From: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary="============_-947762045==_ma============"
Cc: Andrew Sullivan <ajs@shinkuro.com>, Ralph Droms <rdroms@cisco.com>, ogud@ogud.com, secdir@ietf.org
Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Jan 2010 19:14:12 -0000

--============_-947762045==_ma============
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: quoted-printable

At 9:33 PM +0300 1/23/10, Basil Dolmatov wrote:
>Andrew Sullivan =D4=CB=AF=C2=DA:
>>
>>>BTW, we have had this discussion in SIDR,=20
>>>where the RPKI has a similar global scope and=20
>>>where Vasily had made a similar request for=20
>>>recognition of GOST algorithms. So far, that=20
>>>WG has said no, for the reasons I cited in my=20
>>>comments and above. The current plan there is=20
>>>to go with the two suite model I described=20
>>>above.
>>>
>>
>>Ok.  Thanks for this; it's useful feedback.
>>
>Andrew, I, being the participant in the quoted=20
>process, want to share my description of what=20
>had happened and I think that it will differ to=20
>some extent.
>
>I noted that RPKI and SIDR implementations=20
>having exactly no possibility to support=20
>different protocols will definitely meet the=20
>problems, which DNSSec is overcoming simply by=20
>its design.
>
>Steve, in his presentation showed the technology=20
>which gives possibility to given AS (or group of=20
>ASes) to build entirely independent system of=20
>distribution of routing information from the=20
>outer world. That was _the_other_way_ to handle=20
>possible protocol problems, just to present=20
>mechanism, which allows to split whole system=20
>into several entirely independent protocol=20
>domains.
>
>Comparing to DNS the IDR ideology is entirely=20
>different: DNS is wholistic and united service,=20
>but main IDR principle is the independence of=20
>routing decisions for any given AS.
>
>I also noted then that from my point of view the=20
>DNSSec protocol approach seems much more=20
>productive for the development of the network as=20
>a whole and maintaining its integrity, SIDR=20
>approach from that perspective seems a=20
>restrictive one and leading to the dead end in=20
>the near future.
>
>I would be very cautious when considering the=20
>borrowing of the technologies and approaches=20
>from SIDR to any other protocols and services,=20
>these technologies though allowing to "overcome"=20
>possible protocol problems in fact will lead to=20
>the network split.
>
>dol@

Basil,

I agree that there are differences between the=20
DNS and RPKI contexts, but we disagree on the=20
principle common aspects associated with how to=20
accommodate multiple algorithms in both=20
environments.

The question for both DNSSEC and SIDR/RPKI is how=20
many algorithms relying parties MUST/SHOULD be=20
required to implement, and how do we. The=20
approach adopted (so far) in the SIDR context is=20
to minimize such requirements, to not burden RPs,=20
and to avoid creating the sort of potential=20
security problems cited by Paul Hoffman. Thus the=20
plan is to mandate support for two sets of=20
algorithms (we have only one set so far), a=20
current MUST implement and a next MUST implement.

I believe that the situation for DNESEC is=20
equivalent, i.e., imposing a requirement (via=20
MUST or SHOULD) to support more than a current=20
and next set of algorithms is not justifiable. It=20
imposes unacceptable costs on resolvers=20
(analogous to RPs in the RPKI context) and may=20
have adverse secruity implications. Such=20
externalization of costs is a fundamentally bad=20
approach, one that the IETF tries to avoid in=20
analogous contexts in all areas.

It is fine for DNSEXT to allocate algorithm IDs=20
to national algorithms like GOST, but it is not=20
appropriate to mandate their support, for the=20
reasons cited in my review.

Steve

--============_-947762045==_ma============
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type=3D"text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: review of
draft-ietf-dnsext-dnssec-gost-05</title></head><body>
<div>At 9:33 PM +0300 1/23/10, Basil Dolmatov wrote:</div>
<blockquote type=3D"cite" cite>Andrew Sullivan =D4=CB=AF=C2=DA:
<blockquote type=3D"cite" cite><br>
<blockquote type=3D"cite" cite>BTW, we have had this discussion in SIDR,
where the RPKI has a similar global scope and where Vasily had made a
similar request for recognition of GOST algorithms. So far, that WG
has said no, for the reasons I cited in my comments and above. The
current plan there is to go with the two suite model I described
above.<br>
&nbsp;&nbsp; </blockquote>
</blockquote>
<blockquote type=3D"cite" cite><br>
Ok.&nbsp; Thanks for this; it's useful feedback.</blockquote>
<blockquote type=3D"cite" cite>&nbsp;</blockquote>
</blockquote>
<blockquote type=3D"cite" cite>Andrew, I, being the participant in the
quoted process, want to share my description of what had happened and
I think that it will differ to some extent.<br>
<br>
I noted that RPKI and SIDR implementations having exactly no
possibility to support different protocols will definitely meet the
problems, which DNSSec is overcoming simply by its design.<br>
<br>
Steve, in his presentation showed the technology which gives
possibility to given AS (or group of ASes) to build entirely
independent system of distribution of routing information from the
outer world. That was _the_other_way_ to handle possible protocol
problems, just to present mechanism, which allows to split whole
system into several entirely independent protocol domains.<br>
<br>
Comparing to DNS the IDR ideology is entirely different: DNS is
wholistic and united service, but main IDR principle is the
independence of routing decisions for any given AS.<br>
<br>
I also noted then that from my point of view the DNSSec protocol
approach seems much more productive for the development of the network
as a whole and maintaining its integrity, SIDR approach from that
perspective seems a restrictive one and leading to the dead end in the
near future.<br>
<br>
I would be very cautious when considering the borrowing of the
technologies and approaches from SIDR to any other protocols and
services, these technologies though allowing to &quot;overcome&quot;
possible protocol problems in fact will lead to the network split.<br>
</blockquote>
<blockquote type=3D"cite" cite>dol@</blockquote>
<div><br></div>
<div>Basil,</div>
<div><br></div>
<div>I agree that there are differences between the DNS and RPKI
contexts, but we disagree on the principle common aspects associated
with how to accommodate multiple algorithms in both
environments.</div>
<div><br></div>
<div>The question for both DNSSEC and SIDR/RPKI is how many algorithms
relying parties MUST/SHOULD be required to implement, and how do we.
The approach adopted (so far) in the SIDR context is to minimize such
requirements, to not burden RPs, and to avoid creating the sort of
potential security problems cited by Paul Hoffman. Thus the plan is to
mandate support for two sets of algorithms (we have only one set so
far), a current MUST implement and a next MUST implement.</div>
<div><br></div>
<div>I believe that the situation for DNESEC is equivalent, i.e.,
imposing a requirement (via MUST or SHOULD) to support more than a
current and next set of algorithms is not justifiable. It imposes
unacceptable costs on resolvers (analogous to RPs in the RPKI context)
and may have adverse secruity implications. Such externalization of
costs is a fundamentally bad approach, one that the IETF tries to
avoid in analogous contexts in all areas.</div>
<div><br></div>
<div>It is fine for DNSEXT to allocate algorithm IDs to national
algorithms like GOST, but it is not appropriate to mandate their
support, for the reasons cited in my review.</div>
<div><br></div>
<div>Steve</div>
<div><br></div>
</body>
</html>
--============_-947762045==_ma============--

From dol@cryptocom.ru  Sat Jan 23 10:33:40 2010
Return-Path: <dol@cryptocom.ru>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932BA3A6962 for <secdir@core3.amsl.com>; Sat, 23 Jan 2010 10:33:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.285
X-Spam-Level: *
X-Spam-Status: No, score=1.285 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViIHV3GKM8m9 for <secdir@core3.amsl.com>; Sat, 23 Jan 2010 10:33:39 -0800 (PST)
Received: from mx.cryptocom.ru (mx.cryptocom.ru [89.188.97.107]) by core3.amsl.com (Postfix) with ESMTP id 7CAF93A692D for <secdir@ietf.org>; Sat, 23 Jan 2010 10:33:38 -0800 (PST)
Received: from [192.168.63.201] (ppp91-76-185-255.pppoe.mtu-net.ru [91.76.185.255]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id 2765C46501; Sat, 23 Jan 2010 21:33:31 +0300 (MSK)
Message-ID: <4B5B40FB.8060007@cryptocom.ru>
Date: Sat, 23 Jan 2010 21:33:31 +0300
From: Basil Dolmatov <dol@cryptocom.ru>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Andrew Sullivan <ajs@shinkuro.com>
References: <p06240810c76be77be756@[128.89.89.161]> <20100107222809.GA25747@shinkuro.com> <p06240818c76c1a38cbf8@[128.89.89.161]> <20100108144431.GB26259@shinkuro.com>
In-Reply-To: <20100108144431.GB26259@shinkuro.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Sun, 24 Jan 2010 22:57:34 -0800
Cc: Ralph Droms <rdroms@cisco.com>, ogud@ogud.com, secdir@ietf.org
Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Jan 2010 18:33:40 -0000

Andrew Sullivan пишет:
>
>> BTW, we have had this discussion in SIDR, where the RPKI has a similar 
>> global scope and where Vasily had made a similar request for recognition 
>> of GOST algorithms. So far, that WG has said no, for the reasons I cited 
>> in my comments and above. The current plan there is to go with the two 
>> suite model I described above.
>>     
>
> Ok.  Thanks for this; it's useful feedback.
>   
Andrew, I, being the participant in the quoted process, want to share my 
description of what had happened and I think that it will differ to some 
extent.

I noted that RPKI and SIDR implementations having exactly no possibility 
to support different protocols will definitely meet the problems, which 
DNSSec is overcoming simply by its design.

Steve, in his presentation showed the technology which gives possibility 
to given AS (or group of ASes) to build entirely independent system of 
distribution of routing information from the outer world. That was 
_the_other_way_ to handle possible protocol problems, just to present 
mechanism, which allows to split whole system into several entirely 
independent protocol domains.

Comparing to DNS the IDR ideology is entirely different: DNS is 
wholistic and united service, but main IDR principle is the independence 
of routing decisions for any given AS.

I also noted then that from my point of view the DNSSec protocol 
approach seems much more productive for the development of the network 
as a whole and maintaining its integrity, SIDR approach from that 
perspective seems a restrictive one and leading to the dead end in the 
near future.

I would be very cautious when considering the borrowing of the 
technologies and approaches from SIDR to any other protocols and 
services, these technologies though allowing to "overcome" possible 
protocol problems in fact will lead to the network split.


dol@




> Best,
>
> A
>
>   


From new-work-bounces@ietf.org  Sat Jan 23 13:21:54 2010
Return-Path: <new-work-bounces@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3E723A684D; Sat, 23 Jan 2010 13:21:54 -0800 (PST)
X-Original-To: new-work@core3.amsl.com
Delivered-To: new-work@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18F0D3A6948 for <new-work@core3.amsl.com>; Wed, 20 Jan 2010 14:37:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJ9eK2MqtU1k for <new-work@core3.amsl.com>; Wed, 20 Jan 2010 14:37:09 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by core3.amsl.com (Postfix) with ESMTP id B8FD23A6943 for <new-work@ietf.org>; Wed, 20 Jan 2010 14:37:09 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <public-new-work-request@listhub.w3.org>) id 1NXjAe-0001Jw-FH for public-new-work-dist@listhub.w3.org; Wed, 20 Jan 2010 22:37:04 +0000
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <ij@w3.org>) id 1NXjAd-0001Im-MZ for public-new-work@listhub.w3.org; Wed, 20 Jan 2010 22:37:03 +0000
Received: from jay.w3.org ([128.30.52.169]) by lisa.w3.org with esmtp (Exim 4.69) (envelope-from <ij@w3.org>) id 1NXjAc-0000RT-Ct; Wed, 20 Jan 2010 22:37:03 +0000
Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from <ij@w3.org>) id 1NXjAc-0004aJ-62; Wed, 20 Jan 2010 17:37:02 -0500
Message-Id: <D310397D-8ECC-481C-99A0-B13878D5BED2@w3.org>
From: Ian Jacobs <ij@w3.org>
To: public-new-work@w3.org
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 20 Jan 2010 16:37:01 -0600
X-Mailer: Apple Mail (2.936)
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1.8, BAYES_00=-2.599
X-W3C-Scan-Sig: lisa.w3.org 1NXjAc-0000RT-Ct f0c1c5bc03287540ef5fda7ac29b6cb7
X-Original-To: public-new-work@w3.org
Archived-At: <http://www.w3.org/mid/D310397D-8ECC-481C-99A0-B13878D5BED2@w3.org>
Resent-From: public-new-work@w3.org
X-Mailing-List: <public-new-work@w3.org> archive/latest/52
X-Loop: public-new-work@w3.org
Resent-Sender: public-new-work-request@w3.org
Precedence: list
Resent-Message-Id: <E1NXjAe-0001Jw-FH@frink.w3.org>
Resent-Date: Wed, 20 Jan 2010 22:37:04 +0000
X-Mailman-Approved-At: Sat, 23 Jan 2010 13:21:54 -0800
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Sender: new-work-bounces@ietf.org
Errors-To: new-work-bounces@ietf.org
X-Mailman-Approved-At: Sun, 24 Jan 2010 22:57:34 -0800
Subject: [secdir] [New-work] W3C Workshop: RDF Next Steps (Call for Participation)
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Jan 2010 21:21:54 -0000

Dear Colleagues

I am pleased to announce an upcoming W3C Workshop:

   RDF Next Steps
   Exact dates and location not yet decided, but approximately June 2010
   http://www.w3.org/2009/12/rdf-ws/cfp

Some important dates, though these may change slightly:

   * 09 March 2010: Position papers due
   * 07 May 2010: Acceptance notification sent.
   * 28 May 2010: Deadline for final version for submissions
   * mid June 2010: Workshop

We will inform you of the precise dates and locations as soon as
possible.

The Resource Description Framework (RDF), was published in 2004. Since
then, RDF has become the core architectural block of the  Semantic
Web, with significant deployment in terms of tools and applications.

As a result of R&D activities and the publication of newer standards
like SPARQL[1], OWL[2], POWDER[3], or SKOS[4], but also due to the
large scale deployment and applications, a number of issues regarding
RDF have come to the fore. Some of those are related to features that
are not present in the current version of RDF but which became
necessary in practice (eg, the concept of =93Named Graphs=94[5]). Others
result from the difficulties caused by the design decisions taken in
the course of defining the 2004 version of RDF (eg, restrictions
whereby literals cannot appear as subjects). Definition of newer
standards have also revealed difficulties when applying the semantics
of RDF. New serializations formats (eg, Turtle[6]) have gained a
significant support by the community. Finally, at present there is no
standard programming API to manage RDF data; the need may arise to
define such a standard either in a general, programming language
independent way or for some of the important languages (ECMAscript,
Java, Python,=85) It is therefore time to consider whether a revision of
the 2004 version of RDF is necessary or whether the community can
continue developing with the
current version.

The goal of the Workshop is to gather feedback from the Semantic Web
community on whether and, if yes, in which direction RDF should
evolve. One of the main issues the Workshop should help deciding is
whether it is timely for W3C to start a new RDF Working Group to
define and standardize a next version of RDF.

The main outcome of the Workshop will be the publication of
proceedings and, in case there is a consensus on moving forward, a
draft for a charter for a new RDF Working Group.

The Workshop will be co-chaired by David Wood (Zepheira), Stefan
Decker (DERI), and Ivan Herman (W3C). The Program Committee has key
persons from the Semantic Web community, both from industry and
academia. We
look forward to your participation and contributions to this Workshop.

If you have any questions, please contact Ivan Herman <ivan@w3.org>,
Semantic Web Activity Lead.

More information is available in the Call for Participation:
   http://www.w3.org/2009/12/rdf-ws/cfp.html

Ian Jacobs, Head of W3C Communications

[1] http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/
[2] http://www.w3.org/TR/2009/REC-owl2-overview-20091027/
[3] http://www.w3.org/TR/2009/NOTE-powder-primer-20090901/
[4] http://www.w3.org/TR/2009/REC-skos-reference-20090818
[5]
http://sites.wiwiss.fu-berlin.de/suhl/bizer/SWTSGuide/carroll-ISWC2004.pdf
[6] http://www.w3.org/TeamSubmission/2008/SUBM-turtle-20080114/


--
Ian Jacobs (ij@w3.org)    http://www.w3.org/People/Jacobs/
Tel:                                      +1 718 260 9447


_______________________________________________
New-work mailing list
New-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work

From dol@cryptocom.ru  Sun Jan 24 20:35:18 2010
Return-Path: <dol@cryptocom.ru>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60F8D3A6856 for <secdir@core3.amsl.com>; Sun, 24 Jan 2010 20:35:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.807
X-Spam-Level: **
X-Spam-Status: No, score=2.807 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkDJo6f5GRAb for <secdir@core3.amsl.com>; Sun, 24 Jan 2010 20:35:17 -0800 (PST)
Received: from mx.cryptocom.ru (mx.cryptocom.ru [89.188.97.107]) by core3.amsl.com (Postfix) with ESMTP id 1D62E3A6358 for <secdir@ietf.org>; Sun, 24 Jan 2010 20:35:15 -0800 (PST)
Received: from [192.168.63.201] (unknown [91.78.157.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.cryptocom.ru (Postfix) with ESMTP id B615E46466; Mon, 25 Jan 2010 07:35:18 +0300 (MSK)
Message-ID: <4B5D1F85.1070900@cryptocom.ru>
Date: Mon, 25 Jan 2010 07:35:17 +0300
From: Basil Dolmatov <dol@cryptocom.ru>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
References: <p06240810c76be77be756@[128.89.89.161]> <20100107222809.GA25747@shinkuro.com> <p06240818c76c1a38cbf8@[128.89.89.161]> <20100108144431.GB26259@shinkuro.com> <4B5B40FB.8060007@cryptocom.ru> <p0624080bc78249fa2c22@[10.242.22.104]>
In-Reply-To: <p0624080bc78249fa2c22@[10.242.22.104]>
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Sun, 24 Jan 2010 22:57:34 -0800
Cc: Andrew Sullivan <ajs@shinkuro.com>, Ralph Droms <rdroms@cisco.com>, ogud@ogud.com, secdir@ietf.org
Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jan 2010 04:35:18 -0000

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Stephen Kent пишет:
<blockquote cite="mid:p0624080bc78249fa2c22@%5B10.242.22.104%5D"
 type="cite">
  <style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style>
  <title>Re: review of
draft-ietf-dnsext-dnssec-gost-05</title>
  <div>At 9:33 PM +0300 1/23/10, Basil Dolmatov wrote:</div>
  <blockquote type="cite" cite="">Andrew Sullivan Ô˯ÂÚ:
    <blockquote type="cite" cite=""><br>
      <blockquote type="cite" cite="">BTW, we have had this discussion
in SIDR,
where the RPKI has a similar global scope and where Vasily had made a
similar request for recognition of GOST algorithms. So far, that WG
has said no, for the reasons I cited in my comments and above. The
current plan there is to go with the two suite model I described
above.<br>
   </blockquote>
    </blockquote>
    <blockquote type="cite" cite=""><br>
Ok.  Thanks for this; it's useful feedback.</blockquote>
    <blockquote type="cite" cite=""> </blockquote>
  </blockquote>
  <blockquote type="cite" cite="">Andrew, I, being the participant in
the
quoted process, want to share my description of what had happened and
I think that it will differ to some extent.<br>
    <br>
I noted that RPKI and SIDR implementations having exactly no
possibility to support different protocols will definitely meet the
problems, which DNSSec is overcoming simply by its design.<br>
    <br>
Steve, in his presentation showed the technology which gives
possibility to given AS (or group of ASes) to build entirely
independent system of distribution of routing information from the
outer world. That was _the_other_way_ to handle possible protocol
problems, just to present mechanism, which allows to split whole
system into several entirely independent protocol domains.<br>
    <br>
Comparing to DNS the IDR ideology is entirely different: DNS is
wholistic and united service, but main IDR principle is the
independence of routing decisions for any given AS.<br>
    <br>
I also noted then that from my point of view the DNSSec protocol
approach seems much more productive for the development of the network
as a whole and maintaining its integrity, SIDR approach from that
perspective seems a restrictive one and leading to the dead end in the
near future.<br>
    <br>
I would be very cautious when considering the borrowing of the
technologies and approaches from SIDR to any other protocols and
services, these technologies though allowing to "overcome"
possible protocol problems in fact will lead to the network split.<br>
  </blockquote>
  <blockquote type="cite" cite="">dol@</blockquote>
  <div><br>
  </div>
  <div>Basil,</div>
  <div><br>
  </div>
  <div>I agree that there are differences between the DNS and RPKI
contexts, but we disagree on the principle common aspects associated
with how to accommodate multiple algorithms in both
environments.</div>
  <div><br>
  </div>
</blockquote>
Yes, we do disagree in principles (see below).<br>
<blockquote cite="mid:p0624080bc78249fa2c22@%5B10.242.22.104%5D"
 type="cite">
  <div>The question for both DNSSEC and SIDR/RPKI is how many
algorithms
relying parties MUST/SHOULD be </div>
</blockquote>
I wondered why MUST and SHOULD are quoted together. I thought that it
is two _different_ modal verbs with _different_ meaning and _different_
implementation demands.<br>
<blockquote cite="mid:p0624080bc78249fa2c22@%5B10.242.22.104%5D"
 type="cite">
  <div>required to implement, and how do we.
The approach adopted (so far) in the SIDR context is to minimize such
requirements, to not burden RPs, and to avoid creating the sort of
potential security problems cited by Paul Hoffman. Thus the plan is to
mandate support for two sets of algorithms (we have only one set so
far), a current MUST implement and a next MUST implement.</div>
</blockquote>
<br>
<blockquote cite="mid:p0624080bc78249fa2c22@%5B10.242.22.104%5D"
 type="cite">
  <div>I believe that the situation for DNESEC is equivalent, i.e.,
imposing a requirement (via MUST or SHOULD) to support more than a
current and next set of algorithms is not justifiable. </div>
</blockquote>
The situation in DNSSec is entirely different from SIDR:<br>
<blockquote type="cite">Comparing to DNS the IDR ideology is entirely
different: DNS is
wholistic and united service, but main IDR principle is the
independence of routing decisions for any given AS.</blockquote>
The way that was chosen by SIDR developers is demanding to invent some
methods and technologies to prevent network from being split. <br>
Thank you, Steve, you proposed one of the possible technologies which
makes that possible (at least makes a forthcoming split more or less
implicit).<br>
That does not mean that this technology is the _good_ one. It means
that for the given set of circumstances this solution is
_the_only_possible_ one.<br>
<br>
So, I quit the discussion in SIDR, not because of I was satisfied with
the technology and solutions, but because of I have understood how I
could maintain network interoperability even with this rigid technology
and have had more urgent tasks to perform.<br>
<br>
I kindly ask to all participating parties do not try to castrate
flexible protocol design of DNSSec to the SIDR/RPKI rigid approach.<br>
<blockquote cite="mid:p0624080bc78249fa2c22@%5B10.242.22.104%5D"
 type="cite">
  <div>It imposes
unacceptable costs on resolvers (analogous to RPs in the RPKI context)
  </div>
</blockquote>
RPs - are not resolver analogues, but this is for another discussion.<br>
<blockquote cite="mid:p0624080bc78249fa2c22@%5B10.242.22.104%5D"
 type="cite">
  <div>and may have adverse secruity implications. Such externalization
of
costs is a fundamentally bad approach, one that the IETF tries to
avoid in analogous contexts in all areas.</div>
  <div><br>
  </div>
</blockquote>
Here is another difference od DNSSec from SIDR - most of the software
is open-source in DNSSec, so costs have been already distributed evenly.<br>
As for proprietary realisations it seems to me the maintaining of the
cost/profit balance is the task of the management of the given
enterprise, and I am sure that they will do their work well.<br>
<br>
<blockquote cite="mid:p0624080bc78249fa2c22@%5B10.242.22.104%5D"
 type="cite">
  <div>It is fine for DNSEXT to allocate algorithm IDs to national
algorithms like GOST, but it is not appropriate to mandate their
support, for the reasons cited in my review.</div>
</blockquote>
I do agree that MUST set of algorithms should be very narrow and
limited generally speaking to those algorithms by which root zone is
signed.<br>
<br>
As for the other algorithms, it seems to me that the main goal of DNS
system is the providing integral name service resolution. If one have
to perform some additional steps (install different resolver software,
include something and something) just to get access to the network
names on some part of the world, then the obvious next step will be to
point this different resolver to another root of the tree.<br>
<br>
Maybe this is the way the DNS system will develop, but now I think that
the some effort to keep the DNS system united is justified.<br>
<br>
dol@<br>
<blockquote cite="mid:p0624080bc78249fa2c22@%5B10.242.22.104%5D"
 type="cite">
  <div><br>
  </div>
  <div>Steve</div>
  <div><br>
  </div>
</blockquote>
<br>
</body>
</html>

From uri@mit.edu  Mon Jan 25 05:37:58 2010
Return-Path: <uri@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6964D3A69DC for <secdir@core3.amsl.com>; Mon, 25 Jan 2010 05:37:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.068
X-Spam-Level: **
X-Spam-Status: No, score=2.068 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zb5Lzb+PdGNt for <secdir@core3.amsl.com>; Mon, 25 Jan 2010 05:37:57 -0800 (PST)
Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by core3.amsl.com (Postfix) with ESMTP id 36A2A3A69C2 for <secdir@ietf.org>; Mon, 25 Jan 2010 05:37:57 -0800 (PST)
X-AuditID: 1209190d-b7b0fae000000ead-c4-4b5d9eba50f5
Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by dmz-mailsec-scanner-2.mit.edu (Symantec Brightmail Gateway) with SMTP id 8E.6B.03757.ABE9D5B4; Mon, 25 Jan 2010 08:38:02 -0500 (EST)
Received: from outgoing-legacy.mit.edu (OUTGOING-LEGACY.MIT.EDU [18.7.22.104]) by grand-central-station.mit.edu (8.13.6/8.9.2) with ESMTP id o0PDcTal028812 for <secdir@ietf.org>; Mon, 25 Jan 2010 08:38:29 -0500 (EST)
Received: from webmail-9.mit.edu (WEBMAIL-9.MIT.EDU [18.9.23.19]) ) by outgoing-legacy.mit.edu (8.13.6/8.12.4) with ESMTP id o0PDcKoC027692 for <secdir@ietf.org>; Mon, 25 Jan 2010 08:38:20 -0500 (EST)
Received: from webmail-9.mit.edu (webmail-9.mit.edu [127.0.0.1]) by webmail-9.mit.edu (8.13.8) with ESMTP id o0PDMaAE008586; Mon, 25 Jan 2010 08:22:36 -0500
Received: (from nobody@localhost) by webmail-9.mit.edu (8.13.8/8.13.8/Submit) id o0PDMaQH008585 for secdir@ietf.org; Mon, 25 Jan 2010 08:22:36 -0500
X-Authentication-Warning: webmail-9.mit.edu: nobody set sender to uri@mit.edu using -f
Received: from 206.53.147.102 ([206.53.147.102])   (User authenticated as uri@ATHENA.MIT.EDU) by webmail.mit.edu (Horde MIME library) with HTTP; Mon, 25 Jan 2010 08:22:35 -0500
Message-ID: <20100125082235.uaq0dh6twos8so4w@webmail.mit.edu>
X-Priority: 3 (Normal)
Date: Mon, 25 Jan 2010 08:22:35 -0500
From: Uri Blumenthal <uri@MIT.EDU>
To: secdir@ietf.org
References: <p06240810c76be77be756@[128.89.89.161]> <20100107222809.GA25747@shinkuro.com> <p06240818c76c1a38cbf8@[128.89.89.161]> <20100108144431.GB26259@shinkuro.com> <4B5B40FB.8060007@cryptocom.ru> <p0624080bc78249fa2c22@[10.242.22.104]> <4B5D1F85.1070900@cryptocom.ru>
In-Reply-To: <4B5D1F85.1070900@cryptocom.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.0.3)
X-Scanned-By: MIMEDefang 2.42
X-Brightmail-Tracker: AAAAAhKHxpgSh8kU
Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jan 2010 13:37:58 -0000

My humble opinion: GOST "MUST NOT" be "SHOULD", but "SHOULD" be "MAY". For
reasons Steve explained.


Quoting Basil Dolmatov <dol@cryptocom.ru>:
>       Stephen Kent =D0=BF=D0=B8=D1=88=D0=B5=D1=82:   Re: review of
> draft-ietf-dnsext-dnssec-gost-05 At 9:33 PM +0300 1/23/10, Basil
> Dolmatov wrote: Andrew Sullivan =C3=94=C3=8B=C2=AF=C3=82=C3=9A:
> BTW, we have had this discussion in SIDR, where the RPKI has a
> similar global scope and where Vasily had made a similar request for
> recognition of GOST algorithms. So far, that WG has said no, for the
> reasons I cited in my comments and above. The current plan there is
> to go with the two suite model I described above.
> =C2=A0=C2=A0
> Ok.=C2=A0 Thanks for this; it's useful feedback. =C2=A0  Andrew, I, being=
 the
> participant in the quoted process, want to share my description of
> what had happened and I think that it will differ to some extent.
>
> I noted that RPKI and SIDR implementations having exactly no
> possibility to support different protocols will definitely meet the
> problems, which DNSSec is overcoming simply by its design.
>
> Steve, in his presentation showed the technology which gives
> possibility to given AS (or group of ASes) to build entirely
> independent system of distribution of routing information from the
> outer world. That was _the_other_way_ to handle possible protocol
> problems, just to present mechanism, which allows to split whole
> system into several entirely independent protocol domains.
>
> Comparing to DNS the IDR ideology is entirely different: DNS is
> wholistic and united service, but main IDR principle is the
> independence of routing decisions for any given AS.
>
> I also noted then that from my point of view the DNSSec protocol
> approach seems much more productive for the development of the
> network as a whole and maintaining its integrity, SIDR approach from
> that perspective seems a restrictive one and leading to the dead end
> in the near future.
>
> I would be very cautious when considering the borrowing of the
> technologies and approaches from SIDR to any other protocols and
> services, these technologies though allowing to "overcome" possible
> protocol problems in fact will lead to the network split.
> dol@
> Basil,
> I agree that there are differences between the DNS and RPKI
> contexts, but we disagree on the principle common aspects associated
> with how to accommodate multiple algorithms in both environments.
>  Yes, we do disagree in principles (see below).
> The question for both DNSSEC and SIDR/RPKI is how many algorithms
> relying parties MUST/SHOULD be   I wondered why MUST and SHOULD are
> quoted together. I thought that it is two _different_ modal verbs
> with _different_ meaning and _different_ implementation demands.
> required to implement, and how do we. The approach adopted (so far)
> in the SIDR context is to minimize such requirements, to not burden
> RPs, and to avoid creating the sort of potential security problems
> cited by Paul Hoffman. Thus the plan is to mandate support for two
> sets of algorithms (we have only one set so far), a current MUST
> implement and a next MUST implement.
> I believe that the situation for DNESEC is equivalent, i.e.,
> imposing a requirement (via MUST or SHOULD) to support more than a
> current and next set of algorithms is not justifiable.   The
> situation in DNSSec is entirely different from SIDR:
> Comparing to DNS the IDR ideology is entirely different: DNS is
> wholistic and united service, but main IDR principle is the
> independence of routing decisions for any given AS. The way that was
> chosen by SIDR developers is demanding to invent some methods and
> technologies to prevent network from being split.
> Thank you, Steve, you proposed one of the possible technologies which
> makes that possible (at least makes a forthcoming split more or less
> implicit).
> That does not mean that this technology is the _good_ one. It means
> that for the given set of circumstances this solution is
> _the_only_possible_ one.
>
> So, I quit the discussion in SIDR, not because of I was satisfied
> with the technology and solutions, but because of I have understood
> how I could maintain network interoperability even with this rigid
> technology and have had more urgent tasks to perform.
>
> I kindly ask to all participating parties do not try to castrate
> flexible protocol design of DNSSec to the SIDR/RPKI rigid approach.
> It imposes unacceptable costs on resolvers (analogous to RPs in the
> RPKI context)   RPs - are not resolver analogues, but this is for
> another discussion.
> and may have adverse secruity implications. Such externalization of
> costs is a fundamentally bad approach, one that the IETF tries to
> avoid in analogous contexts in all areas.
>  Here is another difference od DNSSec from SIDR - most of the
> software is open-source in DNSSec, so costs have been already
> distributed evenly.
> As for proprietary realisations it seems to me the maintaining of the
> cost/profit balance is the task of the management of the given
> enterprise, and I am sure that they will do their work well.
>
> It is fine for DNSEXT to allocate algorithm IDs to national
> algorithms like GOST, but it is not appropriate to mandate their
> support, for the reasons cited in my review.  I do agree that MUST
> set of algorithms should be very narrow and limited generally
> speaking to those algorithms by which root zone is signed.
>
> As for the other algorithms, it seems to me that the main goal of DNS
> system is the providing integral name service resolution. If one have
> to perform some additional steps (install different resolver
> software, include something and something) just to get access to the
> network names on some part of the world, then the obvious next step
> will be to point this different resolver to another root of the tree.
>
> Maybe this is the way the DNS system will develop, but now I think
> that the some effort to keep the DNS system united is justified.
>
> dol@
>
> Steve
>
>



From Sandra.Murphy@cobham.com  Mon Jan 25 14:18:21 2010
Return-Path: <Sandra.Murphy@cobham.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C5D33A68EF for <secdir@core3.amsl.com>; Mon, 25 Jan 2010 14:18:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9RBPJZLVzTi for <secdir@core3.amsl.com>; Mon, 25 Jan 2010 14:18:20 -0800 (PST)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 2D9673A68E1 for <secdir@ietf.org>; Mon, 25 Jan 2010 14:18:20 -0800 (PST)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o0PMIESW008351; Mon, 25 Jan 2010 16:18:15 -0600
Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o0PMIBY7007179; Mon, 25 Jan 2010 16:18:12 -0600
Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.114]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 17:18:11 -0500
Date: Mon, 25 Jan 2010 17:18:11 -0500 (Eastern Standard Time)
From: Sandra Murphy <sandy@sparta.com>
To: Basil Dolmatov <dol@cryptocom.ru>
In-Reply-To: <4B5B40FB.8060007@cryptocom.ru>
Message-ID: <Pine.WNT.4.64.1001251653100.2224@SANDYM-LT.columbia.ads.sparta.com>
References: <p06240810c76be77be756@[128.89.89.161]> <20100107222809.GA25747@shinkuro.com> <p06240818c76c1a38cbf8@[128.89.89.161]> <20100108144431.GB26259@shinkuro.com> <4B5B40FB.8060007@cryptocom.ru>
X-X-Sender: sandy@nemo.columbia.sparta.com
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="281994304-17170-1264457891=:2224"
X-OriginalArrivalTime: 25 Jan 2010 22:18:11.0306 (UTC) FILETIME=[47B104A0:01CA9E0C]
Cc: Andrew Sullivan <ajs@shinkuro.com>, secdir@ietf.org, ogud@ogud.com, Ralph Droms <rdroms@cisco.com>
Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jan 2010 22:18:21 -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.

--281994304-17170-1264457891=:2224
Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE



On Sat, 23 Jan 2010, Basil Dolmatov wrote:

> Andrew Sullivan =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
>>
>>> BTW, we have had this discussion in SIDR, where the RPKI has a similar=
=20
>>> global scope and where Vasily had made a similar request for recognitio=
n=20
>>> of GOST algorithms. So far, that WG has said no, for the reasons I cite=
d=20
>>> in my comments and above. The current plan there is to go with the two=
=20
>>> suite model I described above.
>>>=20
>>
>> Ok.  Thanks for this; it's useful feedback.
>>=20
> Andrew, I, being the participant in the quoted process, want to share my=
=20
> description of what had happened and I think that it will differ to some=
=20
> extent.
>
> I noted that RPKI and SIDR implementations having exactly no possibility=
=20
> to support different protocols will definitely meet the problems, which=
=20
> DNSSec is overcoming simply by its design.
>
> Steve, in his presentation showed the technology which gives possibility=
=20
> to given AS (or group of ASes) to build entirely independent system of=20
> distribution of routing information from the outer world. That was=20
> _the_other_way_ to handle possible protocol problems, just to present=20
> mechanism, which allows to split whole system into several entirely=20
> independent protocol domains.


I disagree with this characterization of Steve's presentation.  He=20
presented a technique to allow a local determination of the authorization=
=20
of routing information.  His technique was not a technique for=20
distribution of routing information and was not independent from the=20
outside world.  Note also that locally originated routing information and=
=20
RPKI information would flow to the outside world without effect.

--Sandy
   (sidr chair)


>
> Comparing to DNS the IDR ideology is entirely different: DNS is=20
> wholistic and united service, but main IDR principle is the independence=
=20
> of routing decisions for any given AS.
>
> I also noted then that from my point of view the DNSSec protocol=20
> approach seems much more productive for the development of the network=20
> as a whole and maintaining its integrity, SIDR approach from that=20
> perspective seems a restrictive one and leading to the dead end in the=20
> near future.
>
> I would be very cautious when considering the borrowing of the=20
> technologies and approaches from SIDR to any other protocols and=20
> services, these technologies though allowing to "overcome" possible=20
> protocol problems in fact will lead to the network split.
>
>
> dol@
>
>
>
>
>> Best,
>>
>> A
>>
>>=20
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
>
--281994304-17170-1264457891=:2224--

From Sandra.Murphy@cobham.com  Mon Jan 25 14:44:42 2010
Return-Path: <Sandra.Murphy@cobham.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 151433A67D7 for <secdir@core3.amsl.com>; Mon, 25 Jan 2010 14:44:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5mCIfpu3cHP for <secdir@core3.amsl.com>; Mon, 25 Jan 2010 14:44:40 -0800 (PST)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 99A3A3A6452 for <secdir@ietf.org>; Mon, 25 Jan 2010 14:44:40 -0800 (PST)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o0PMiYsY008849; Mon, 25 Jan 2010 16:44:34 -0600
Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o0PMiXp4008402; Mon, 25 Jan 2010 16:44:33 -0600
Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.114]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 17:44:32 -0500
Date: Mon, 25 Jan 2010 17:44:32 -0500 (Eastern Standard Time)
From: Sandra Murphy <sandy@sparta.com>
To: Basil Dolmatov <dol@cryptocom.ru>
In-Reply-To: <4B5D1F85.1070900@cryptocom.ru>
Message-ID: <Pine.WNT.4.64.1001251719550.2224@SANDYM-LT.columbia.ads.sparta.com>
References: <p06240810c76be77be756@[128.89.89.161]> <20100107222809.GA25747@shinkuro.com> <p06240818c76c1a38cbf8@[128.89.89.161]> <20100108144431.GB26259@shinkuro.com> <4B5B40FB.8060007@cryptocom.ru> <p0624080bc78249fa2c22@[10.242.22.104]> <4B5D1F85.1070900@cryptocom.ru>
X-X-Sender: sandy@nemo.columbia.sparta.com
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="283575587-17756-1264459472=:2224"
X-OriginalArrivalTime: 25 Jan 2010 22:44:32.0635 (UTC) FILETIME=[F63CACB0:01CA9E0F]
Cc: Andrew Sullivan <ajs@shinkuro.com>, secdir@ietf.org, ogud@ogud.com, Ralph Droms <rdroms@cisco.com>
Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jan 2010 22:44:42 -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.

--283575587-17756-1264459472=:2224
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

A few comments and requests for clarification in line.

--Sandy

On Mon, 25 Jan 2010, Basil Dolmatov wrote:

> Stephen Kent =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
>       At 9:33 PM +0300 1/23/10, Basil Dolmatov wrote:
>       Andrew Sullivan =C3=94=C3=8B=C2=AF=C3=82=C3=9A:
>
>                   BTW, we have had this discussion in SIDR, where the RPK=
I has a similar
>                   global scope and where Vasily had made a similar reques=
t for
>                   recognition of GOST algorithms. So far, that WG has sai=
d no, for the
>                   reasons I cited in my comments and above. The current p=
lan there is to
>                   go with the two suite model I described above.
>                   =C2=A0=C2=A0
>=20
>
>             Ok.=C2=A0 Thanks for this; it's useful feedback.
>
>             =C2=A0
>
>       Andrew, I, being the participant in the quoted process, want to sha=
re my description of what
>       had happened and I think that it will differ to some extent.
>
>       I noted that RPKI and SIDR implementations having exactly no possib=
ility to support different
>       protocols will definitely meet the problems, which DNSSec is overco=
ming simply by its design.
>
>       Steve, in his presentation showed the technology which gives possib=
ility to given AS (or group
>       of ASes) to build entirely independent system of distribution of ro=
uting information from the
>       outer world. That was _the_other_way_ to handle possible protocol p=
roblems, just to present
>       mechanism, which allows to split whole system into several entirely=
 independent protocol
>       domains.
>
>       Comparing to DNS the IDR ideology is entirely different: DNS is who=
listic and united service,
>       but main IDR principle is the independence of routing decisions for=
 any given AS.
>
>       I also noted then that from my point of view the DNSSec protocol ap=
proach seems much more
>       productive for the development of the network as a whole and mainta=
ining its integrity, SIDR
>       approach from that perspective seems a restrictive one and leading =
to the dead end in the near
>       future.
>
>       I would be very cautious when considering the borrowing of the tech=
nologies and approaches from
>       SIDR to any other protocols and services, these technologies though=
 allowing to "overcome"
>       possible protocol problems in fact will lead to the network split.
>
>       dol@
>=20
>=20
> Basil,
>=20
> I agree that there are differences between the DNS and RPKI contexts, but=
 we disagree on the principle
> common aspects associated with how to accommodate multiple algorithms in =
both environments.
>=20
> Yes, we do disagree in principles (see below).
>       The question for both DNSSEC and SIDR/RPKI is how many algorithms r=
elying parties MUST/SHOULD be
>=20
> I wondered why MUST and SHOULD are quoted together. I thought that it is =
two _different_ modal verbs with
> _different_ meaning and _different_ implementation demands.
>       required to implement, and how do we. The approach adopted (so far)=
 in the SIDR context is to
>       minimize such requirements, to not burden RPs, and to avoid creatin=
g the sort of potential security
>       problems cited by Paul Hoffman. Thus the plan is to mandate support=
 for two sets of algorithms (we
>       have only one set so far), a current MUST implement and a next MUST=
 implement.
>=20
>
>       I believe that the situation for DNESEC is equivalent, i.e., imposi=
ng a requirement (via MUST or
>       SHOULD) to support more than a current and next set of algorithms i=
s not justifiable.
>=20
> The situation in DNSSec is entirely different from SIDR:
>       Comparing to DNS the IDR ideology is entirely different: DNS is who=
listic and united service, but
>       main IDR principle is the independence of routing decisions for any=
 given AS.

I'm not certain of your comparison here.  Certainly the independence of=20
local decisions is a fundamental principal in BGP.  Do not DNS name=20
servers make local decisions?  And DNS resolvers?

>=20
> The way that was chosen by SIDR developers is demanding to invent some me=
thods and technologies to prevent
> network from being split.

You will have to explain this further as I see nothing undertaken in sidr=
=20
that would produce a network split or whose sole purpose is to prevent a=20
network split.

> Thank you, Steve, you proposed one of the possible technologies which mak=
es that possible (at least makes a
> forthcoming split more or less implicit).

Steve's approach demonstrated how it was possible to provide for a local=20
determination of authorization for routing information.

It had nothing to do with algorithm support, which I thought was your=20
focus.


> That does not mean that this technology is the _good_ one. It means that =
for the given set of circumstances this
> solution is _the_only_possible_ one.
>=20
> So, I quit the discussion in SIDR, not because of I was satisfied with th=
e technology and solutions, but because
> of I have understood how I could maintain network interoperability even w=
ith this rigid technology and have had
> more urgent tasks to perform.
>=20
> I kindly ask to all participating parties do not try to castrate flexible=
 protocol design of DNSSec to the
> SIDR/RPKI rigid approach.
>       It imposes unacceptable costs on resolvers (analogous to RPs in the=
 RPKI context)
>=20
> RPs - are not resolver analogues, but this is for another discussion.
>       and may have adverse secruity implications. Such externalization of=
 costs is a fundamentally bad
>       approach, one that the IETF tries to avoid in analogous contexts in=
 all areas.
>=20
> Here is another difference od DNSSec from SIDR - most of the software is =
open-source in DNSSec, so costs have
> been already distributed evenly.

You will have to explain this point more.  What does open source=20
development have to do with the cost of operating a secure system?  Part=20
of the cost being externallized is the need to multiply sign and multiply=
=20
verify the same information in multiple algorithms.  Each new globally=20
mandated algorithm is a burden on all users, whether they are paying=20
development costs or not.


> As for proprietary realisations it seems to me the maintaining of the cos=
t/profit balance is the task of the
> management of the given enterprise, and I am sure that they will do their=
 work well.
>
>       It is fine for DNSEXT to allocate algorithm IDs to national algorit=
hms like GOST, but it is not
>       appropriate to mandate their support, for the reasons cited in my r=
eview.
>=20
> I do agree that MUST set of algorithms should be very narrow and limited =
generally speaking to those algorithms
> by which root zone is signed.
>=20
> As for the other algorithms, it seems to me that the main goal of DNS sys=
tem is the providing integral name
> service resolution. If one have to perform some additional steps (install=
 different resolver software, include
> something and something) just to get access to the network names on some =
part of the world, then the obvious next
> step will be to point this different resolver to another root of the tree=
=2E

I don't understand this argument either.  You agree that the algorithm set=
=20
needs to be limited to those used by the roots.  If that is done, why then=
=20
would it be necessary to point to a different root?

A limited mandated algorithm set exists, you agree that a limited set is=20
good - what exactly is your complaint?

--Sandy

>=20
> Maybe this is the way the DNS system will develop, but now I think that t=
he some effort to keep the DNS system
> united is justified.
>=20
> dol@
>=20
> Steve
>=20
>=20
>=20
>
--283575587-17756-1264459472=:2224--

From tena@huawei.com  Tue Jan 26 01:13:01 2010
Return-Path: <tena@huawei.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 439463A68F5; Tue, 26 Jan 2010 01:13:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.299
X-Spam-Level: 
X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lVSPDakYq23; Tue, 26 Jan 2010 01:12:59 -0800 (PST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 4A50E3A6818; Tue, 26 Jan 2010 01:12:55 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWU00K1XK78VB@szxga03-in.huawei.com>; Tue, 26 Jan 2010 17:11:33 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWU00EUHK788W@szxga03-in.huawei.com>; Tue, 26 Jan 2010 17:11:32 +0800 (CST)
Received: from ms-106432.blue.itu.ch ([156.106.224.41]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPA id <0KWU00BU8K75JG@szxml02-in.huawei.com>; Tue, 26 Jan 2010 17:11:32 +0800 (CST)
Date: Tue, 26 Jan 2010 10:11:28 +0100
From: Tina TSOU <tena@huawei.com>
To: secdir@ietf.org, iesg@ietf.org
Message-id: <90041D6C-0B96-482D-9CCC-C552481A187F@huawei.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.936)
Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-transfer-encoding: 7BIT
Subject: [secdir] secdir review of draft-roach-sip-http-subscribe-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2010 09:13:01 -0000

Hi,
I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG.  These comments were written primarily
for the benefit of the security area directors.  Document editors and
WG chairs should treat these comments just like any other last call
comments.

Comments follow:
1) It is possible that the message/http NOTIFY message bodies may  
contain sensitive information. This is related to the statement at the  
end of the existing Security Considerations text that care should be  
taken to apply the same controls over access to entity information to  
SIP/SIPS subscribers as to users using other protocols. Additional  
text in the Security Considerations section should point out that if  
the NOTIFY requests may return sensitive information, that information  
should be protected in transit by, for example, requiring that the  
subscription use SIPS rather than SIP.

2) Along with this, some reference to RFC 5630 might be valuable, both  
to indicate the limitations of SIPS and to indicate how it should be  
implemented.




B. R.
Tina
http://tinatsou.weebly.com/contact.html







From new-work-bounces@ietf.org  Tue Jan 26 11:00:08 2010
Return-Path: <new-work-bounces@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BA653A69B8; Tue, 26 Jan 2010 11:00:08 -0800 (PST)
X-Original-To: new-work@ietf.org
Delivered-To: new-work@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 74B3D3A6999; Tue, 26 Jan 2010 11:00:01 -0800 (PST)
From: IESG Secretary <iesg-secretary@ietf.org>
To: new-work@ietf.org
Mime-Version: 1.0
Message-Id: <20100126190001.74B3D3A6999@core3.amsl.com>
Date: Tue, 26 Jan 2010 11:00:01 -0800 (PST)
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: new-work-bounces@ietf.org
Errors-To: new-work-bounces@ietf.org
X-Mailman-Approved-At: Tue, 26 Jan 2010 12:18:03 -0800
Subject: [secdir] [New-work] WG Review: Recharter of Audio/Video Transport (avt)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2010 19:00:08 -0000

A modified charter has been submitted for the Audio/Video Transport (avt)
working group in the Real-time Applications and Infrastructure Area of the
IETF.  The IESG has not made any determination as yet.  The modified
charter is provided below for informational purposes only.  Please send
your comments to the IESG mailing list (iesg@ietf.org) by Tuesday,
February 2, 2010.

Audio/Video Transport (avt)
----------------------------
Last Modified: 2010-01-21
Additional information is available at tools.ietf.org/wg/avt

Chair(s):
 Roni Even <even.roni@huawei.com>
 Tom Taylor <tom111.taylor@bell.net>

Real-time Applications and Infrastructure Area Director(s):
 Robert Sparks <rjsparks@nostrum.com>
 Cullen Jennings <fluffy@cisco.com>

Real-time Applications and Infrastructure Area Advisor:
 Robert Sparks <rjsparks@nostrum.com>

Mailing Lists:
 General Discussion: avt@ietf.org
 To Subscribe: https://www.ietf.org/mailman/listinfo/avt
 Archive: http://www.ietf.org/mail-archive/web/avt/index.html

Description of Working Group:

The Audio/Video Transport Working Group was formed to specify
a protocol for real-time transmission of audio and video over
unicast and multicast UDP/IP. This is the Real-time Transport
Protocol, RTP, along with its associated profiles and payload
formats.

RTP itself has been shepherded to Full Standard. Its associated
profiles, extensions, and payload formats are currently at various
levels of stardards maturity. This working group's current work
centers in four areas:

1) Maintenance of the core RTP/RTCP protocols
and the AVP, SAVP, AVPF, and SAVPF profiles

2) Specification and maintenance of payload formats for use with RTP

3) Specification of metric blocks for use with the
RTCP Extended Report (XR) framework

4) Extensions to the core protocols to facilitate joining,
synchronizing, control, and monitoring of RTP multimedia
sessions

In these areas, the group is chartered to focus on the following
tasks. Work supporting those areas, but not reflected in these
tasks must not be accepted by the working group without an explicit
re-chartering. In particular, new items supporting the fourth area
are expected to be reviewed in DISPATCH before being considered new
charter items for this group.

1) Maintenance of the core RTP/SRTP/RTCP protocols
and the AVP, SAVP, AVPF, and SAVPF profiles
- maintain and enhance the SRTP Profile, with review and input
from the Security Area
- specify how to use Explicit Congestion Notification (ECN)
with RTP/RTCP

2) Specification and maintenance of payload formats for use with RTP
- provide guidelines for payload format design
- develop payload formats for new media codecs
- review and revise existing payload formats to advance those
which are useful to Draft Standard or Standard, and to
declare others as Historic.

3) Specification of metric blocks for use with the
RTCP Extended Report (XR) framework
- provide a mechanism allowing identification data for
a set of related metric reports to be carried separately
and identified in those reports by reference
- provide report blocks for delay, delay variation, and discard
- provide report blocks for burst/gap discard and loss
- provide report blocks supporting rapid synchronization
of multiple RTP streams
- provide report blocks for jitter buffer metrics
- provide report blocks for loss concealment metrics

4) Extensions to the core protocols to facilitate joining,
synchronizing, control, and monitoring of RTP multimedia
sessions
- develop tools to support rapid acquisition
of multimedia streams
-specify necessary extensions to support rapid
synchronization of multiple RTP streams


Milestones:

Maintenance of the core RTP/RTCP protocols and the AVP, SAVP, AVPF,
and SAVPF profiles
Jan-10 Submit draft explaining why SRTP need not be mandatory for
media transport, for Informational
Jan-10 Policy for Registering SRTP Transforms for Proposed Standard
Feb-10 Submit Port Mapping Between Unicast and Multicast RTP Sessions
for Proposed Standard
Mar-10 Submit Guidelines for Extending the RTP Control Protocol
(RTCP) for Informational
Mar-10 Submit Monitoring Architecture for RTP for Informational
Apr-10 Submit in band keying mechanism for SRTP draft for Proposed
Standard
May-10 Submit Real-Time Transport Control Protocol (RTCP) in Overlay
Multicast for Proposed Standard
May-10 Submit Explicit Congestion Notification (ECN) for RTP over UDP
for Proposed Standard
Nov-10 Encryption of Header Extensions in the Secure Real-Time
Transport Protocol (SRTP) for Proposed Standard

Specification and maintenance of payload formats for use with RTP
Jan-10 Submit RTP Payload Format for H.264 RCDO Video for Proposed
Standard
Jan-10 RTP Payload Format for GSM-HR for Proposed Standard
Jan-10 RTP Payload Format for DRA Audio for Informational
Feb-10 Submit RTP Payload Format for SVC Video for Proposed Standard
Feb-10 Submit How to Write an RTP Payload Format for Informational
Mar-10 Submit RTP Payload Format for DV (IEC 61834) Video for
Proposed Standard
Mar-10 Submit EVBR/G.718 payload draft for Proposed Standard
Mar-10 RTP Payload Format for MPEG2-TS preamble for Proposed Standard
Mar-10 RTP Payload Format for MPEG-4 Audio/Visual Streams for
Proposed Standard
Apr-10 RTP Payload Format for Enhanced Variable Rate Narrowband-
Wideband Codec (EVRC-NW) for Proposed Standard
Apr-10 RTP Payload Format for Bluetooth's SBC audio codec for
Proposed Standard
Apr-10 RTP Payload Format for the iSAC codec for Proposed Standard
Sep-10 RTP Payload Format for the CELT codec for Proposed Standard
Sep-10 RTP Payload Format for the APTX codec for Proposed Standard
Sep-10 RTP profile for the carriage of SMPTE 336M data for Proposed
Standard
Oct-10 RTP Payload Format for MVC Video for Proposed Standard
Dec-10 Submit RTP Payload Format for MIDI for Proposed Standard

Specification of metric blocks for use with the RTCP Extended Report
(XR) framework
Feb-10 Submit Multicast Acquisition Report Block Type for RTCP XR
Mar-10 Submit RTCP XR Report Block for Measurement Identity
Apr-10 Submit RTCP XR Report Block for Burst/Gap Discard metric
Reporting
Apr-10 Submit RTCP XR Report Block for Burst/Gap Loss metric Reporting
Apr-10 Submit RTCP XR Report Block for Concealed Seconds metric
Reporting
Apr-10 Submit RTCP XR Report Block for Delay metric Reporting
Apr-10 Submit RTCP XR Report Block for Discard metric Reporting
Apr-10 Submit RTCP XR Report Block for Jitter Buffer Metric Reporting
Apr-10 Submit RTCP XR Report Block for Loss Concealment metric
Reporting
Apr-10 Submit RTCP XR Report Block for Packet Delay Variation Metric
Reporting
Apr-10 Submit Real-time Transport Control Protocol Extension Report
for Run Length Encoding of Discarded Packets
Apr-10 Submit RTCP XR Report Block for QoE Metrics Reporting

Extensions to the core protocols to facilitate joining,
synchronizing, control, and monitoring of RTP multimedia
Jan-10 Submit Unicast-Based Rapid Acquisition of Multicast RTP
Sessions for Proposed Standard
Jan-10 Submit Rapid Synchronization of RTP Flows for Proposed Standard
Jan-10 Submit Forward-shifted RTP Redundancy Payload Support for
Proposed Standard
Apr-10 Submit Considerations for RAMS Scenarios for Informational
_______________________________________________
New-work mailing list
New-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work

From sumanth@cablelabs.com  Tue Jan 26 21:42:42 2010
Return-Path: <sumanth@cablelabs.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAA823A6A12; Tue, 26 Jan 2010 21:42:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.463
X-Spam-Level: 
X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3Ou64vSCnML; Tue, 26 Jan 2010 21:42:41 -0800 (PST)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 9479E3A6A0B; Tue, 26 Jan 2010 21:42:41 -0800 (PST)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with ESMTP id o0R5gqND016798; Tue, 26 Jan 2010 22:42:53 -0700
Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Tue, 26 Jan 2010 22:42:53 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com)
Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 26 Jan 2010 22:42:53 -0700
From: Sumanth Channabasappa <sumanth@cablelabs.com>
To: Catherine Meadows <catherine.meadows@nrl.navy.mil>, "secdir@ietf.org" <secdir@ietf.org>, "dan.ietf@sipez.com" <dan.ietf@sipez.com>, "iesg@ietf.org" <iesg@ietf.org>
Date: Tue, 26 Jan 2010 22:42:50 -0700
Thread-Topic: Secdir review of draft-ietf-sipping-config-framework-16
Thread-Index: AcqTB0AeRIi9UK+9RQO2UVzuUYUAoAMCgEog
Message-ID: <76AC5FEF83F1E64491446437EA81A61F7CD37AFFA3@srvxchg>
References: <214A28E5-3DBD-4252-8EF6-7E18CEB441E5@nrl.navy.mil> <DD7DFD78-4285-4F8B-9F81-C2F8BCA77768@nrl.navy.mil>
In-Reply-To: <DD7DFD78-4285-4F8B-9F81-C2F8BCA77768@nrl.navy.mil>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Approved: ondar
X-Mailman-Approved-At: Tue, 26 Jan 2010 22:46:50 -0800
Subject: Re: [secdir] Secdir review of draft-ietf-sipping-config-framework-16
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jan 2010 05:42:42 -0000

Catherine,

Thanks again for your keen observations, and the associated comments. Dan a=
nd I discussed them offline, and I am summarizing our responses inline, tag=
ged with [D&S]. Please let us know if they address your questions.

- Dan & Sumanth

=09
	I think that this ID is in general in good shape with respect to security,=
 but I was a little confused about some of the discussion of bootstrapping.=
  It is the hardest to pin down, of course, but it is also the most importa=
nt to make clear, because it is the point, I believe, at which the network =
is most vulnerable. Specific comments follow:
=09
	1.  The first sentence of Section 5.3.1, which reads=20
=09
	When requesting a profile the device can provide an identity (i.e., a
	user AoR), and contain associated credentials for authentication. To
	do so, the device needs to obtain this information via bootstrapping.
=09
	I wasn't quite sure what this means.   Should that "can" be a "must"?  Tha=
t is, the device needs the information, but can only get it through bootstr=
apping.  Or is the
	"contain" be "obtain", and bootstrapping is how you get it?

=3D=3D=3D [D&S] =3D=3D=3D

You raise a good question. Dan suggested the following to solve the confusi=
on (and I concur with him):

Replace the first sentence of 5.3.1:
"When requesting a profile the device can provide an identity (i.e., a user=
 AoR), and contain associated credentials for authentication."

with:

"When requesting a profile the profile delivery server will likely require =
the device to provide an identity (i.e., a user AoR), and associated creden=
tials for authentication."

Does that help?
=3D=3D=3D=3D


=09
	2.  Bootstrapping itself is never explicitly defined.  I'd suggest doing t=
hat at the beginning of 5.3.1.

=3D=3D=3D [D&S] =3D=3D=3D

You are correct. How about the following at the beginning of 5.3.1:

"Bootstrapping is the process  by which a new (or factory reset) device, wi=
th no configuration or minimal "factory" pre-configuration, enrolls with th=
e PDS.  The device may use a temporary identity and credentials to authenti=
cate itself to enroll and receive profiles, which may provide more permanen=
t identities and credentials for future enrollments."

Alternatively, we could add this definition in Section 2 (Terminology).

=3D=3D=3D=3D
=09

	3.  The discussion of bootstrapping in 5.3.1 appears to only consider the =
threat to the PDS.  What about the other way around?  This is mentioned as =
a threat in the Security Considerations section, but it's not clear to me w=
hether 5.3.1 addresses this threat.

=3D=3D=3D [D&S] =3D=3D=3D
This is addressed in Section 5.2.1, for normal profile enrollment. Perhaps =
we should add a reference to these requirements in Section 5.3.1 so that it=
 is clear that the device authenticates the PDS even in the bootstrapping s=
cenario (e.g., during digest authentication)?
=3D=3D=3D=3D

=09
	4.  The discussion of the security implications of bootstrapping device pr=
ofiles in Section 9.2 is valuable, and helps the reader understand the rati=
onale for the recommendations in 5.3.1 better,  A forward reference in the =
discussion of device profile on page 26 would be helpful.
=09
=3D=3D=3D [D&S] =3D=3D=3D
Good suggestion, agree.
=3D=3D=3D=3D


From Pasi.Eronen@nokia.com  Thu Jan 28 04:32:45 2010
Return-Path: <Pasi.Eronen@nokia.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25B833A6845; Thu, 28 Jan 2010 04:32:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.257
X-Spam-Level: 
X-Spam-Status: No, score=-6.257 tagged_above=-999 required=5 tests=[AWL=0.342,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSfnZpYrfX8B; Thu, 28 Jan 2010 04:32:43 -0800 (PST)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 1A2163A6782; Thu, 28 Jan 2010 04:32:42 -0800 (PST)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o0SCWios017539; Thu, 28 Jan 2010 14:32:58 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jan 2010 14:32:57 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 Jan 2010 14:32:56 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Thu, 28 Jan 2010 13:32:55 +0100
From: <Pasi.Eronen@nokia.com>
To: <saag@ietf.org>, <secdir@ietf.org>
Date: Thu, 28 Jan 2010 13:32:54 +0100
Thread-Topic: Pasi's AD Notes for January 2010
Thread-Index: AcqgFgOzf0FBvq55Qt+NAj4azBNe9A==
Message-ID: <808FD6E27AD4884E94820BC333B2DB775841227053@NOK-EUMSG-01.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 28 Jan 2010 12:32:56.0647 (UTC) FILETIME=[04F68570:01CAA016]
X-Nokia-AV: Clean
Subject: [secdir] Pasi's AD Notes for January 2010
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jan 2010 12:32:45 -0000

Here's again a short status update about what things are going on from
my point-of-view. If you notice anything that doesn't look right, let
me know -- miscommunication and mix-ups do happen.

Best regards,
Pasi

MISC NOTES

- New datatracker improvements deployed for wider testing (see=20
  http://www.ietf.org/mail-archive/web/tools-discuss/current/msg02067.html)
- Planning agenda for SAAG meeting in Anaheim with Tim
- Waiting for IETF Trust's reply on how to contribute pre-5378
  rights to the trust [since 2009-11-03]
- (not wearing AD hat) Waiting for Dan Romascanu to process=20
  errata 1955/1956 for RFC 4072 [since 2009-12-09]
- (not wearing AD hat) draft-krawczyk-hkdf went to IETF last
  call (until 2010-02-23)

WORKING GROUPS

DKIM
- draft-ietf-dkim-deployment: the document was updated to address
  IETF last call comments; placed on the agenda of 2010-02-04 IESG
  telechat.
- Sent email about errata 1385; waiting for a while to see
  if anyone has comments [since 2010-01-27]
- I still need to review what to do about errata 1532, 1596,
  and 1942.
- Waiting for Stephen and Barry for new charter text.

EMU
- The WG chairs have the token for doing something about ITU-T=20
  X.1034 liaison statement.

IPSECME
- draft-ietf-ipsecme-ikev2-resumption: published as RFC 5723.
- draft-ietf-ipsecme-traffic-visibility: was approved by IESG;
  now in RFC editor queue.
- draft-ietf-ipsecme-esp-null-heuristics: sent my AD review
  comments; discussion ongoing; waiting for revised ID=20
  [since 2010-01-28]
- draft-ietf-ipsecme-aes-ctr-ikev2: sent my AD review
  comments; waiting for reply/revised ID [since 2010-01-27]
- draft-ietf-ipsecme-ikev2-ipv6-config (not wearing AD hat):=20
  in RFC editor queue.
- I need to look at errata 1937 (for RFC 4307) [since 2009-11-02]

ISMS

KEYPROV
- Apparently waiting for the chairs to send some documents
  my way...

PKIX
- draft-ietf-pkix-sha2-dsa-ecdsa: published as RFC 5758
- draft-ietf-pkix-rfc4055-update: published as RFC 5756.
- Sent email about errata 1909 (for RFC 3279); waiting for
  comments [since 2010-01-27]
- I also need to look at errata 2021 (for RFC 5756) and 2013
  (for RFC 5758) [since 2010-01-26]

SASL
- draft-ietf-sasl-gs2: was approved by IESG; now in RFC editor
  queue.
- draft-ietf-sasl-scram: in RFC editor queue.
- (not WG item) draft-melnikov-sasl-scram-ldap: in RFC editor
  queue.
- (not WG item) draft-altman-tls-channel-bindings: went through
  IETF last call; delayed due to renegotiation discussions;=20
  currently waiting for me to do something (when renegotiation
  is done).

SYSLOG
- draft-ietf-syslog-sign: was approved by IESG; will go to
  RFC editor queue soon.

TLS
- draft-ietf-tls-renegotiation: see mailing list.
- draft-ietf-tls-extractor: waiting for Eric to propose
  text for one small AUTH48 change [since 2010-01-24]
- draft-ietf-tls-rfc4366-bis: it seems we need more text about
  server_name. Currently waiting until the renegotiation fix is done.
- (not WG item) see SASL WG for draft-altman-tls-channel-bindings

OTHER DOCUMENTS

DISCUSSES (active -- something happened within last month)

- draft-bryan-metalink: changes agreed, waiting for the authors
  to submit a revised ID [since 2010-01-26]
- draft-ietf-behave-turn-uri: waiting for the authors to reply
  to my comments [since 2010-01-21]
- draft-ietf-capwap-base-mib: discussion ongoing, changes mostly
  agreed; currently waiting for the authors [since 2010-01-26]
- draft-ietf-pana-preauth: text agreed; waiting for the
  authors to submit a revised ID [since 2010-01-21]

DISCUSSES (stalled -- I haven't heard anything from the authors
or document shepherd for over one month)

- draft-ietf-bmwg-ipsec-meth: waiting for authors to submit
  a revised ID [since 2009-10-22] (some emails around 2009-11-24
  and 2010-01-28)
- draft-ietf-bmwg-ipsec-term: waiting for authors to reply
  to my comments or submit a revised ID [since 2009-10-22] (some=20
  emails around 2009-11-24 and 2010-01-28)
- draft-ietf-rohc-ikev2-extensions-hcoipsec: waiting for the=20
  authors to submit a revised ID [since 2009-12-17] (pinged 2010-01-27)
- draft-ietf-rohc-hcoipsec: waiting for the authors to submit=20
  a revised ID [since 2009-12-17] (pinged 2010-01-27)
- draft-turner-deviceowner-attribute: waiting for the author
  to submit a revised ID [since 2009-11-18] (pinged 2010-01-22)
- draft-turner-clearancesponsor-attribute: waiting for the author
  to submit a revised ID [since 2009-11-18] (pinged 2010-01-22)

DISCUSSES (presumed dead -- I haven't heard anything from the authors
or document shepherd for over three months)

- draft-cheshire-dnsext-nbp: waiting for authors to reply to my
  comments [since 2008-12-03] (pinged again on 2009-04-30,
  2009-06-09, 2009-10-29, 2009-12-28)
- draft-ietf-ntp-autokey: waiting for Ralph's proposal on
  how to proceed [since 2009-10-19]
- draft-ietf-sip-certs: discussion ongoing; currently waiting
  for the authors to reply [since 2009-10-26] (pinged 2010-01-22)
- draft-ietf-sipping-policy-package: waiting for draft-ietf-sipping-
  media-policy-dataset to progress (or more information from Robert)
  [since 2008-10-28]

--end--

From tlyu@mit.edu  Fri Jan 29 19:44:48 2010
Return-Path: <tlyu@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BAC93A6860; Fri, 29 Jan 2010 19:44:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hW-q6hUBf20d; Fri, 29 Jan 2010 19:44:47 -0800 (PST)
Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by core3.amsl.com (Postfix) with ESMTP id 4EE973A6765; Fri, 29 Jan 2010 19:44:47 -0800 (PST)
X-AuditID: 1209190c-b7b6aae000000979-4c-4b63ab47a9d9
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by dmz-mailsec-scanner-1.mit.edu (Symantec Brightmail Gateway) with SMTP id D7.15.02425.74BA36B4; Fri, 29 Jan 2010 22:45:11 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id o0U3iJO5026612; Fri, 29 Jan 2010 22:44:19 -0500 (EST)
Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id o0U3jSdJ017105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Jan 2010 22:45:28 -0500 (EST)
Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id o0U3iwqJ013479; Fri, 29 Jan 2010 22:44:58 -0500 (EST)
To: secdir@ietf.org, iesg@ietf.org, draft-ietf-6man-text-addr-representation@tools.ietf.org, 6man-chairs@tools.ietf.org
From: Tom Yu <tlyu@MIT.EDU>
Date: Fri, 29 Jan 2010 22:44:57 -0500
Message-ID: <ldvhbq4fe86.fsf@cathode-dark-space.mit.edu>
Lines: 22
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Scanned-By: MIMEDefang 2.42
X-Brightmail-Tracker: AAAAAA==
Subject: [secdir] secir review of draft-ietf-6man-text-addr-representation-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Jan 2010 03:44:48 -0000

This draft indicates that it has no security considerations.  I think
that conflicts with Section 3.2.5, which gives an example of
inappropriate (textual) verification of IPv6 addresses in an X.509
certificate.  Although (in my understanding) IPv6 addresses in X.509
certificates are in binary form and probably should be compared as
such, if the authors feel the need to explicitly call out an example
of inappropriate textual verification of addresses, which could have
security consequences if the address values in question are used for
access control.

The text in Section 3.3.3 about network abuse reporting would also
appear to have some operational (but probably not protocol) security
consequences, especially if a network operator would need to respond
rapidly to an ongoing attack.

Editorial:

In Section 3.3.2, I believe the claim that IPv4 addresses cannot be
abbreviated is false.  Historically, BSD implementations of textual
IPv4 address parsing have accepted a number of variant abbreviated
notations.  I think they have generally output canonical dotted-quad
IPv4 addresses though.

From weiler+secdir@watson.org  Sun Jan 31 07:00:20 2010
Return-Path: <weiler+secdir@watson.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D69C03A6876 for <secdir@core3.amsl.com>; Sun, 31 Jan 2010 07:00:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMYnFbJYAKVz for <secdir@core3.amsl.com>; Sun, 31 Jan 2010 07:00:20 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id E065A3A672E for <secdir@ietf.org>; Sun, 31 Jan 2010 07:00:19 -0800 (PST)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o0VF0nYg075126 for <secdir@ietf.org>; Sun, 31 Jan 2010 10:00:49 -0500 (EST) (envelope-from weiler+secdir@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o0VF0mPv075121 for <secdir@ietf.org>; Sun, 31 Jan 2010 10:00:49 -0500 (EST) (envelope-from weiler+secdir@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Sun, 31 Jan 2010 10:00:48 -0500 (EST)
From: Samuel Weiler <weiler+secdir@watson.org>
X-X-Sender: weiler@fledge.watson.org
To: secdir@ietf.org
Message-ID: <alpine.BSF.2.00.1001310957270.74384@fledge.watson.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Sun, 31 Jan 2010 10:00:49 -0500 (EST)
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: secdir-secretary@mit.edu
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Jan 2010 15:00:20 -0000

Eight new docs, several old ones returning following revision (the 
mediactrl docs), and a few things added to the telechat agenda...

Documents on the telechat agenda typically have a last call end date 
before the date shown below; reviews by the end of last call are 
typically more appreciated by the doc editors.

Review instructions and related resources are at:
       http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

-- Sam


For telechat 2010-02-04

Reviewer                 Deadline   Draft
Alan DeKok             T 2010-02-02 draft-ietf-capwap-802dot11-mib-06
Charlie Kaufman        TR2010-02-02 draft-ietf-dkim-deployment-11
Sandy Murphy           T 2010-02-02 draft-turner-ecprivatekey-02
Magnus Nystrom         TR2010-02-02 draft-josefsson-kerberos5-starttls-08
Carl Wallace           T 2010-02-02 draft-ietf-ccamp-pc-spc-rsvpte-ext-06
Sam Weiler             T 2010-02-02 draft-ietf-sipcore-199-02
Brian Weis             T 2010-02-02 draft-ietf-nsis-y1541-qosm-09


For telechat 2010-02-18

Reviewer                 Deadline   Draft
Hannes Tschofenig      T 2010-02-16 draft-allbery-afs-srv-records-03
Nico Williams          T 2010-02-16 draft-gould-rfc4310bis-03
Larry Zhu              T 2010-02-16 draft-ietf-pce-p2mp-req-05

Last calls and special requests:

Reviewer                 Deadline   Draft
Derek Atkins             2010-02-05 draft-ietf-ccamp-gmpls-dcsc-channel-ext-03
Rob Austein              2009-11-28 draft-ietf-pkix-attr-cert-mime-type-02
Rob Austein              2010-02-11 draft-ietf-ipsecme-esp-null-heuristics-05
Richard Barnes           2010-02-08 draft-ietf-mpls-ldp-typed-wildcard-05
Pat Cain                 2010-02-08 draft-ietf-mpls-tp-nm-framework-04
Dave Cridland            2010-02-12 draft-ietf-rmt-flute-revised-10
Alan DeKok               2009-10-01 draft-ietf-enum-enumservices-transition-04
Alan DeKok               2010-02-19 draft-westerlund-mmusic-3gpp-sdp-rtsp-07
Donald Eastlake         R2010-02-11 draft-ietf-mediactrl-ivr-control-package-07
Donald Eastlake          2010-02-23 draft-krawczyk-hkdf-01
Shawn Emery             R2010-02-11 draft-ietf-mediactrl-mixer-control-package-10
Love Hornquist-Astrand   2009-06-29 draft-ietf-opsawg-smi-datatypes-in-xsd-05
Love Hornquist-Astrand   2009-10-13 draft-ietf-idnabis-mappings-05
David McGrew             None       draft-ietf-dnsext-dnssec-gost-06
Catherine Meadows        2008-01-17 draft-ietf-speechsc-mrcpv2-20
Sandy Murphy            R2009-11-18 draft-ietf-mpls-mpls-and-gmpls-security-framework-07
Vidya Narayanan          2008-11-21 draft-ietf-sip-saml-06
Chris Newman             2010-01-07 draft-ietf-krb-wg-preauth-framework-15
Joe Salowey              2009-02-08 draft-ietf-geopriv-lis-discovery-13
Sam Weiler               2008-08-13 draft-chown-v6ops-rogue-ra-03
Brian Weis              R2010-02-11 draft-ietf-mediactrl-sip-control-framework-11
Nico Williams            2008-08-13 draft-ietf-v6ops-ra-guard-04
Larry Zhu                2008-08-13 draft-thaler-v6ops-teredo-extensions-05
Larry Zhu                2009-05-09 draft-ietf-ecrit-location-hiding-req-02
Glen Zorn                2010-01-28 draft-ietf-pkix-tamp-05


From d3e3e3@gmail.com  Sun Jan 31 16:04:55 2010
Return-Path: <d3e3e3@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64BDB3A67CF; Sun, 31 Jan 2010 16:04:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.669
X-Spam-Level: 
X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCWr0v3RgGHW; Sun, 31 Jan 2010 16:04:54 -0800 (PST)
Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 318B93A67B6; Sun, 31 Jan 2010 16:04:54 -0800 (PST)
Received: by ey-out-2122.google.com with SMTP id 22so1057044eye.51 for <multiple recipients>; Sun, 31 Jan 2010 16:05:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=X8sFUf2L1KMynfEaHZgsYJSmmpn+EbgZuHs7xZMEyqU=; b=k/ap9WNG6L9BACA0mYe5uE9SwrNTmRdjDokLUn59IqsWW9lfHe8oWKOAFK+vhTRz6a tMx4OtHVyllCkmev1hpWp5RcGg8F2FQaoXlI/9OAM3aRYNmo/lg75mfFJGeFLjmSD9/u JE2QSePDpo0yFx0uY6+k20AmzGkl61xSJnvhQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=d3I0A2IC9ZSZgDj9MlzIHoWeMoKyj84qPUTuVglIVfBXtWwjsl24OiZsBFi/Jl8Xxd Zi1Ln5/7KVU/Bp7llMNqoRajJS78PFlA9c9uPN3ScVo1j3bXwe5t2QE5DUFjZIx9EJDZ fmxlhC5mvO7UDEK9Soi9YCp03JRTnHX6kc/ys=
MIME-Version: 1.0
Received: by 10.216.86.131 with SMTP id w3mr2008573wee.156.1264982722690; Sun,  31 Jan 2010 16:05:22 -0800 (PST)
Date: Sun, 31 Jan 2010 19:05:22 -0500
Message-ID: <1028365c1001311605i6fdcf00cxdce48ec07a8fa61e@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
To: pasi.eronen@nokia.com, hugo@ee.technion.ac.il,  Tim Polk <tim.polk@nist.gov>
Content-Type: multipart/alternative; boundary=0016e6d7787fd54023047e7ebd9d
Cc: iesg@ietf.org, secdir@ietf.org
Subject: [secdir] SecDir Review of draft-krawczyk-hkdf-01.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Feb 2010 00:04:55 -0000

--0016e6d7787fd54023047e7ebd9d
Content-Type: text/plain; charset=ISO-8859-1

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. Document
editors and WG chairs should treat these comments just like any other last
call comments.

This draft specifies an HMAC key derivation function that is divided into
two steps: an extract step to get a fixed length pseudo-random key from some
inputs and an expand step which expands this pseudo-random key into the
desired output keying material.

It appears to be simple, useful, and, to my very limited cryptographic
judgement, secure.

Editorial:

Section 2.1, page 3, "has always" -> "always has"

Thanks,
Donald
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
d3e3e3@gmail.com

--0016e6d7787fd54023047e7ebd9d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>I have reviewed this document as part of the security directorate&#39;=
s ongoing effort to review all IETF documents being processed by the=A0IESG=
.=A0Document editors and WG chairs should treat=A0these comments just like =
any other last call comments.</div>
<div><br></div><div>This draft specifies an HMAC key derivation function th=
at is divided into two steps: an extract step to get a fixed length pseudo-=
random key from some inputs and an expand step which expands this pseudo-ra=
ndom key into the desired output keying material.</div>
<div><br></div><div>It appears to be simple, useful, and, to my very limite=
d cryptographic judgement, secure.</div><div><br></div><div>Editorial:</div=
><div><br></div><div>Section 2.1, page 3, &quot;has always&quot; -&gt; &quo=
t;always has&quot;</div>
<div><br></div><div>Thanks,</div><div>Donald</div>=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br> Donald =
E. Eastlake 3rd =A0 +1-508-634-2066 (home)<br> 155 Beaver Street<br> Milfor=
d, MA 01757 USA<br> <a href=3D"mailto:d3e3e3@gmail.com">d3e3e3@gmail.com</a=
><br>


--0016e6d7787fd54023047e7ebd9d--