From nobody Fri Nov 1 05:07:01 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCE21208BD for ; Fri, 1 Nov 2019 05:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAsPwzYbokPa for ; Fri, 1 Nov 2019 05:06:53 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5460120899 for ; Fri, 1 Nov 2019 05:06:52 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id w3so5049730edt.2 for ; Fri, 01 Nov 2019 05:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rkqrna1NRQzfybbehKYGNKR/ie9lLXXCu31++a01xuc=; b=nPeLau0GgxYK/XllG3csHguXH7Pd1O2MygDySl4P0r9vYJ3ANXtU8+hyydSb8la97z WM6dTdz5LmQxF5QYTbQi4RMTm1LkQhBtK+fvgB7D6BXsWq85dTtDWIPckC0fxpGGWxhs rIBLelhQiWXQllMczeMX3mPpJZtRwlbouPSidMKBOZyowwGazmHeM/RHfHjVBKORLO/g EhqG38iNb6ogurpolUzwpIxPjgR642rsZtYqeFTfYV0A6dUCZL2ma/d8t/Q15IoN5yV+ b7zj2Y1qZN16bOZHrhcEf2arSA9ypvNdZflrrAbKB1zqNd/AM3mS7icHXqdEEk7ToqjY WutA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rkqrna1NRQzfybbehKYGNKR/ie9lLXXCu31++a01xuc=; b=s72gf38ji283T9Vl4Dg44Rmg3CVGsscH07FZ2TUSlLPtgy/w+P7PUchNOFBVMacA1s NoYsayL3f/dQXabnAPGjJpR9HklFAVylGIr1NeweURlmJwKeCNnmmDawUlAlLPvBXkC0 zClcUwGuNi2nQbtJZpcPKFA9+N8xSWQhCf36UroHFt1vI5uVQM1shr5vwvd0chRORzWB M5jcuI6NdHeVWMJEWTL+wAq8FEIk7DgF8spGqNT3KshdkPdMwpI3Gyk/K1HPM8u1GO8k gsjv5oX+bbP38PKd/1S07SFXMMwHZ7S3/VoplCb6W/kA0LErof8OeTyIu/yFXqmEKNf5 Y5ZQ== X-Gm-Message-State: APjAAAVtRJxyg9v2qwuSNG3JtfADpcGOnSUiYkf5WWMTYP1i8qIvMSRz 0R9rVtL/PpER0LLlHQpbsvwZJGPDFOBt06J0Au7xyDT0WkyWrQ== X-Google-Smtp-Source: APXvYqw/+GqscUBUqrdkILmvsg6AmJHIEGXiHIVQgbTlJsPMm4TQ9wEWx8B1lufM2QcKE9tZApJYO4LAcV2liLSB204= X-Received: by 2002:a50:fd03:: with SMTP id i3mr12315823eds.70.1572610011254; Fri, 01 Nov 2019 05:06:51 -0700 (PDT) MIME-Version: 1.0 References: <157100555733.20750.5488529297693995498@ietfa.amsl.com> In-Reply-To: From: CARLOS JESUS BERNARDOS CANO Date: Fri, 1 Nov 2019 13:06:35 +0100 Message-ID: To: Joseph Salowey Cc: secdir@ietf.org, draft-ietf-dmm-distributed-mobility-anchoring.all@ietf.org, The IESG , dmm Content-Type: multipart/alternative; boundary="000000000000176dcc059647cd56" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dmm-distributed-mobility-anchoring-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 12:07:00 -0000 --000000000000176dcc059647cd56 Content-Type: text/plain; charset="UTF-8" Dear Joseph, We've just posted a new revision (-14) addressing all your comments. Thanks! Carlos On Fri, Oct 18, 2019 at 1:12 PM CARLOS JESUS BERNARDOS CANO wrote: > Dear Joseph, > > Thanks a lot for the review. We will improve the security consideration > section by including also some of the considerations mentioned in draft- > ietf-dmm-deployment-models-04, and also by better scoping current text. > We believe we don't need much more in terms of text, as the document is > informational, and the actual security mechanisms for a distributed > anchoring solution would depend on the specifics of that solution. We can > also better reflect that rational in the text. > > Thanks, > > Carlos > > On Mon, Oct 14, 2019 at 12:25 AM Joseph Salowey via Datatracker < > noreply@ietf.org> wrote: > >> Reviewer: Joseph Salowey >> Review result: Has Issues >> >> 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 summary of the review is the document has issues with the security >> considerations section. >> >> The security consideration section is extremely light. It mainly >> contains text >> from RFC 7333. It seems that there should be more discussion of security >> as it >> relates to the different configurations and different cases. Do each of >> these >> cases have the same security properties and require the same types of >> security >> controls? >> >> Are the IPSEC recommendations mentioned in the security considerations of >> draft-ietf-dmm-deployment-models-04 applicable for all the cases? Should >> these be pointed out in the security considerations section? >> >> >> > > -- > Special Issue "Beyond 5G Evolution": > https://www.mdpi.com/journal/electronics/special_issues/beyond_5g > > -- Special Issue "Beyond 5G Evolution": https://www.mdpi.com/journal/electronics/special_issues/beyond_5g --000000000000176dcc059647cd56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Joseph,

We've just posted a ne= w revision (-14) addressing all your comments.

Tha= nks!

Carlos

On Fri, Oct 18, 2019 at 1:12 PM C= ARLOS JESUS BERNARDOS CANO <cjbc@it.u= c3m.es> wrote:
Dear Joseph,

Thanks a lot for the= review. We will improve the security consideration section by including al= so some of the considerations mentioned in=C2=A0draft-ie= tf-dmm-deployment-models-04, and also by better scoping= current text. We believe we don't need much more in terms of text, as = the document is informational, and the actual security mechanisms for a dis= tributed anchoring solution would depend on the specifics of that solution.= We can also better reflect that rational in the text.

=
Thanks,

Carlos

On Mon, Oct 14, 2019 at 1= 2:25 AM Joseph Salowey via Datatracker <noreply@ietf.org> wrote:
Reviewer: Joseph Salowey
Review result: Has Issues

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=A0 These comments were written primarily for the benefit of the security area directors.=C2=A0 Document editors and WG chairs should treat<= br> these comments just like any other last call comments.

The summary of the review is the document has issues with the security
considerations section.

The security consideration section is extremely light.=C2=A0 It mainly cont= ains text
from RFC 7333.=C2=A0 It seems that there should be more discussion of secur= ity as it
relates to the different configurations and different cases.=C2=A0 =C2=A0Do= each of these
cases have the same security properties and require the same types of secur= ity
controls?

Are the IPSEC recommendations mentioned in the security considerations of draft-ietf-dmm-deployment-models-04 applicable for all the cases?=C2=A0 =C2= =A0Should
these be pointed out in the security considerations section?




--


--
--000000000000176dcc059647cd56-- From nobody Fri Nov 1 06:12:47 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98483120125; Fri, 1 Nov 2019 06:12:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Paul Wouters via Datatracker To: Cc: last-call@ietf.org, draft-ietf-ippm-initial-registry.all@ietf.org, ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Paul Wouters Message-ID: <157261395653.31839.392742976360807570@ietfa.amsl.com> Date: Fri, 01 Nov 2019 06:12:36 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-ippm-initial-registry-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 13:12:37 -0000 Reviewer: Paul Wouters Review result: Has Issues 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. As this document populates an IANA registry with metrics values, no security considerations apply. This is stated in the Security Section. Normally, the IANA considerations are within one section and all other sections are written as if this has already been done, except with a [TBD] for any value IANA needs to put in. But this document uses text outside the Iana Considerations section like: "IANA is asked to assign different numeric identifiers to each of the two Named Metrics." It is better to rewrite this with clear text stating Name X is assigned value [TBD] Similarly, the document has "Change Controller", but the way this is normally phrased is to be part of the new Registry definition of "Registration Procedure(s)" which has defined values like "Expert review", "Specification Required", "First Come First Serve", etc. The document should be changed to reflect these standard types of policies, and ask IANA to create the Registries with the standarized procedure terms for updating those registries. From nobody Fri Nov 1 09:25:15 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E81481209CE; Fri, 1 Nov 2019 09:25:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir via Datatracker To: Cc: last-call@ietf.org, ace@ietf.org, draft-ietf-ace-cwt-proof-of-possession.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Yoav Nir Message-ID: <157262550387.31812.4531851658668957424@ietfa.amsl.com> Date: Fri, 01 Nov 2019 09:25:03 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-ace-cwt-proof-of-possession-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 16:25:04 -0000 Reviewer: Yoav Nir Review result: Ready This is the second secdir review of this document. I'm reviewing version -11. The previous review was of version -08. All my concerns were addressed, except one: I still think it's strange that the Introduction section is an exact repeat of the Abstract. From nobody Fri Nov 1 09:38:30 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E598120A70; Fri, 1 Nov 2019 09:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1572625366; bh=cevAp+dIUnwL7SwqHwkD0a+ZdgwrBdSnluoATCAISO4=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=xNj/drGBDPzNYsu/ifGvUpWOlI42iRoWgoY+YPNiH6I3ClpjwXyQ+rRHhuJYLwwAa EwLVQFovKFoH1u45wfLTCIWTmjnT9DlB2w/L8NThtnpn7ILEWhrv0VOByu2pZ8zXzS x8zIxmproELI7hX124IAVRHJ9eZl6zP1DNrZ7RVE= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Nov 1 09:22:41 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DEF1209FE; Fri, 1 Nov 2019 09:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1572625360; bh=cevAp+dIUnwL7SwqHwkD0a+ZdgwrBdSnluoATCAISO4=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=wR327wfoFQvIhASNQWXLazFR4kqUcwOa7tkENWqLh+cpZbwJiiRHTJwwscfJOw8kE WqeeckMTvfW4/60i2kkAgLZSu56uKletUM7k2Jh8GUIZzvOv3oZATYnwneLuJAN7o9 HyonMGhQ6DM5q4STn7eVYwIwNll2snPzNEMgiQs4= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE0E120A59 for ; Fri, 1 Nov 2019 09:22:27 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply_to: MIME-Version: 1.0 Message-ID: <157262534738.31915.12306452498342992134.idtracker@ietfa.amsl.com> Date: Fri, 01 Nov 2019 09:22:27 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 01 Nov 2019 09:38:28 -0700 Subject: [secdir] [new-work] WG Review: EAP Method Update (emu) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 16:22:53 -0000 VGhlIEVBUCBNZXRob2QgVXBkYXRlIChlbXUpIFdHIGluIHRoZSBTZWN1cml0eSBBcmVhIG9mIHRo ZSBJRVRGIGlzIHVuZGVyZ29pbmcKcmVjaGFydGVyaW5nLiBUaGUgSUVTRyBoYXMgbm90IG1hZGUg YW55IGRldGVybWluYXRpb24geWV0LiBUaGUgZm9sbG93aW5nCmRyYWZ0IGNoYXJ0ZXIgd2FzIHN1 Ym1pdHRlZCwgYW5kIGlzIHByb3ZpZGVkIGZvciBpbmZvcm1hdGlvbmFsIHB1cnBvc2VzIG9ubHku ClBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIElFU0cgbWFpbGluZyBsaXN0IChpZXNn QGlldGYub3JnKSBieQoyMDE5LTExLTExLgoKRUFQIE1ldGhvZCBVcGRhdGUgKGVtdSkKLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0KQ3VycmVudCBzdGF0dXM6IEFjdGl2ZSBXRwoKQ2hhaXJzOgogIEpvc2VwaCBTYWxv d2V5IDxqb2VAc2Fsb3dleS5uZXQ+CiAgTW9oaXQgU2V0aGkgPG1vaGl0Lm0uc2V0aGlAZXJpY3Nz b24uY29tPgoKQXNzaWduZWQgQXJlYSBEaXJlY3RvcjoKICBSb21hbiBEYW55bGl3IDxyZGRAY2Vy dC5vcmc+CgpTZWN1cml0eSBBcmVhIERpcmVjdG9yczoKICBCZW5qYW1pbiBLYWR1ayA8a2FkdWtA bWl0LmVkdT4KICBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+CgpNYWlsaW5nIGxpc3Q6CiAg QWRkcmVzczogZW11QGlldGYub3JnCiAgVG8gc3Vic2NyaWJlOiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2VtdQogIEFyY2hpdmU6IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0 Zi5vcmcvYXJjaC9zZWFyY2gvP2VtYWlsX2xpc3Q9ZW11CgpHcm91cCBwYWdlOiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2dyb3VwL2VtdS8KCkNoYXJ0ZXI6IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1lbXUvCgpUaGUgRXh0ZW5zaWJsZSBBdXRoZW50 aWNhdGlvbiBQcm90b2NvbCAoRUFQKSBbUkZDIDM3NDhdIGlzIGEgbmV0d29yayBhY2Nlc3MKYXV0 aGVudGljYXRpb24gZnJhbWV3b3JrIHVzZWQsIGZvciBpbnN0YW5jZSwgaW4gVlBOIGFuZCBtb2Jp bGUgbmV0d29ya3MuCkVBUCBpdHNlbGYgaXMgYSBzaW1wbGUgcHJvdG9jb2wgYW5kIGFjdHVhbCBh dXRoZW50aWNhdGlvbiBoYXBwZW5zIGluIEVBUAptZXRob2RzLiBTZXZlcmFsIEVBUCBtZXRob2Rz IGhhdmUgYmVlbiBkZXZlbG9wZWQgYXQgdGhlIElFVEYgYW5kCnN1cHBvcnQgZm9yIEVBUCBleGlz dHMgaW4gYSBicm9hZCBzZXQgb2YgZGV2aWNlcy4gUHJldmlvdXMgbGFyZ2VyIEVBUC1yZWxhdGVk CmVmZm9ydHMgYXQgdGhlIElFVEYgaW5jbHVkZWQgcmV3cml0aW5nIHRoZSBiYXNlIEVBUCBwcm90 b2NvbCBzcGVjaWZpY2F0aW9uIGFuZAp0aGUgZGV2ZWxvcG1lbnQgb2Ygc2V2ZXJhbCBzdGFuZGFy ZHMgdHJhY2sgRUFQIG1ldGhvZHMuCgpFQVAgbWV0aG9kcyBhcmUgZ2VuZXJhbGx5IGJhc2VkIG9u IGV4aXN0aW5nIHNlY3VyaXR5IHRlY2hub2xvZ2llcyBzdWNoIGFzClRyYW5zcG9ydCBMYXllciBT ZWN1cml0eSAoVExTKSBhbmQgbW9iaWxlIG5ldHdvcmsgQXV0aGVudGljYXRpb24gYW5kIEtleQpB Z3JlZW1lbnQgKEFLQSkuIE91ciB1bmRlcnN0YW5kaW5nIG9mIHNlY3VyaXR5IHRocmVhdHMgaXMg Y29udGludW91c2x5CmV2b2x2aW5nLiBUaGlzIGhhcyBkcml2ZW4gdGhlIGV2b2x1dGlvbiBvZiBz ZXZlcmFsIG9mIHRoZXNlIHVuZGVybHlpbmcKdGVjaG5vbG9naWVzLiBBcyBhbiBleGFtcGxlLCBJ RVRGIGhhcyBzdGFuZGFyZGl6ZWQgYSBuZXcgYW5kIGltcHJvdmVkCnZlcnNpb24gb2YgVExTICh2 MS4zKSBpbiBSRkMgODQ0Ni4gVGhlIGdyb3VwIHdpbGwgdGhlcmVmb3JlIHByb3ZpZGUgZ3VpZGFu Y2UKYW5kIHVwZGF0ZSBFQVAgbWV0aG9kIHNwZWNpZmljYXRpb25zIHdoZXJlIG5lY2Vzc2FyeSB0 byBlbmFibGUgdGhlIHVzZSBvZgpuZXcgdmVyc2lvbnMgb2YgdGhlc2UgdW5kZXJseWluZyB0ZWNo bm9sb2dpZXMuCgpBdCB0aGUgc2FtZSB0aW1lLCBzb21lIG5ldyB1c2UgY2FzZXMgZm9yIEVBUCBo YXZlIGJlZW4gaWRlbnRpZmllZC4gRUFQIGlzCm5vdyBtb3JlIGJyb2FkbHkgdXNlZCBpbiBtb2Jp bGUgbmV0d29yayBhdXRoZW50aWNhdGlvbi4gVGhlIGdyb3VwIHdpbGwKdXBkYXRlIGV4aXN0aW5n IEVBUCBtZXRob2RzIHN1Y2ggYXMgRUFQLUFLQScgdG8gc3RheSBpbiBzeW5jIHdpdGggdXBkYXRl cwp0byB0aGUgcmVmZXJlbmNlZCAzR1BQIHNwZWNpZmljYXRpb25zLiBSRkMgNzI1OCBub3RlcyB0 aGF0IHBlcnZhc2l2ZQptb25pdG9yaW5nIGlzIGFuIGF0dGFjay4gUGVyZmVjdCBGb3J3YXJkIFNl Y3JlY3kgKFBGUykgaXMgYW4gaW1wb3J0YW50CnNlY3VyaXR5IHByb3BlcnR5IGZvciBtb2Rlcm4g cHJvdG9jb2xzIHRvIHRod2FydCBwZXJ2YXNpdmUgbW9uaXRvcmluZy4gVGhlCmdyb3VwIHdpbGwg d29yayBvbiBhbiBleHRlbnNpb24gdG8gRUFQLUFLQScgZm9yIHByb3ZpZGluZyBQRlMuCgpPdXQt b2YtYmFuZCAoT09CKSByZWZlcnMgdG8gYSBzZXBhcmF0ZSBjb21tdW5pY2F0aW9uIGNoYW5uZWwK aW5kZXBlbmRlbnQgb2YgdGhlIHByaW1hcnkgaW4tYmFuZCBjaGFubmVsIG92ZXIgd2hpY2ggdGhl IGFjdHVhbCBuZXR3b3JrCmNvbW11bmljYXRpb24gdGFrZXMgcGxhY2UuIE9PQiBjaGFubmVscyBh cmUgbm93IHVzZWQgZm9yIGF1dGhlbnRpY2F0aW9uCmluIGEgdmFyaWV0eSBvZiBwcm90b2NvbHMg YW5kIGRldmljZXMgKGRyYWZ0LWlldGYtb2F1dGgtZGV2aWNlLWZsb3ctMTMsCldoYXRzQXBwIFdl YiwgZXRjLikuIE1hbnkgdXNlcnMgYXJlIGFjY3VzdG9tZWQgdG8gdGFwcGluZyBORkMgb3IKc2Nh bm5pbmcgUVIgY29kZXMuIEhvd2V2ZXIsIEVBUCBjdXJyZW50bHkgZG9lcyBub3QgaGF2ZSBhbnkg c3RhbmRhcmQKbWV0aG9kcyB0aGF0IHN1cHBvcnQgYXV0aGVudGljYXRpb24gYmFzZWQgb24gT09C IGNoYW5uZWxzLiBUaGUgZ3JvdXAKd2lsbCB0aGVyZWZvcmUgd29yayBvbiBhbiBFQVAgbWV0aG9k IHdoZXJlIGF1dGhlbnRpY2F0aW9uIGlzIGJhc2VkIG9uIGFuCm91dC1vZi1iYW5kIGNoYW5uZWwg YmV0d2VlbiB0aGUgcGVlciBhbmQgdGhlIHNlcnZlci4KCkVBUCBhdXRoZW50aWNhdGlvbiBpcyBi YXNlZCBvbiBjcmVkZW50aWFscyBhdmFpbGFibGUgb24gdGhlIHBlZXIgYW5kIHRoZQpzZXJ2ZXIu IEhvd2V2ZXIsIHNvbWUgRUFQIG1ldGhvZHMgdXNlIGNyZWRlbnRpYWxzIHRoYXQgYXJlIHRpbWUg b3IgZG9tYWluCmxpbWl0ZWQgKHN1Y2ggYXMgRUFQLVBPVFApLCBhbmQgdGhlcmUgbWF5IGJlIGEg bmVlZCBmb3IgY3JlYXRpbmcgbG9uZyB0ZXJtCmNyZWRlbnRpYWxzIGZvciByZS1hdXRoZW50aWNh dGluZyB0aGUgcGVlciBpbiBhIG1vcmUgZ2VuZXJhbCBjb250ZXh0LiBUaGUKZ3JvdXAgd2lsbCBp bnZlc3RpZ2F0ZSBtaW5pbWFsIG1lY2hhbmlzbXMgd2l0aCB3aGljaCBsaW1pdGVkLXVzZSBFQVAK YXV0aGVudGljYXRpb24gY3JlZGVudGlhbHMgY2FuIGJlIHVzZWQgZm9yIGNyZWF0aW5nIGdlbmVy YWwtdXNlIGxvbmctdGVybQpjcmVkZW50aWFscy4KCkluIHN1bW1hcnksIHRoZSB3b3JraW5nIGdy b3VwIHNoYWxsIHByb2R1Y2UgdGhlIGZvbGxvd2luZyBkb2N1bWVudHM6CgogICAgICAgICogQW4g dXBkYXRlIHRvIGVuYWJsZSB0aGUgdXNlIG9mIFRMUyAxLjMgaW4gdGhlIGNvbnRleHQgb2YgRUFQ LVRMUwooUkZDIDUyMTYpLiBUaGlzIGRvY3VtZW50IHdpbGwgdXBkYXRlIHRoZSBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyByZWxhdGluZyB0bwpFQVAtVExTLCBkb2N1bWVudCB0aGUgaW1wbGljYXRp b25zIG9mIHVzaW5nIG5ldyB2cy4gb2xkIFRMUyB2ZXJzaW9ucy4gSXQgd2lsbAphZGQgYW55IHJl Y2VudGx5IGdhaW5lZCBuZXcga25vd2xlZGdlIG9uIHZ1bG5lcmFiaWxpdGllcyBhbmQgZGlzY3Vz cyB0aGUKcG9zc2libGUgaW1wbGljYXRpb25zIG9mIHBlcnZhc2l2ZSBzdXJ2ZWlsbGFuY2UuCgog ICAgICAgICogU2V2ZXJhbCBFQVAgbWV0aG9kcyBzdWNoIEVBUC1UVExTIGFuZCBFQVAtRkFTVCB1 c2UgYW4gb3V0ZXIgVExTCnR1bm5lbC4gUHJvdmlkZSBndWlkYW5jZSBvciB1cGRhdGUgdGhlIHJl bGV2YW50IHNwZWNpZmljYXRpb25zIGV4cGxhaW5pbmcKaG93IHRob3NlIEVBUCBtZXRob2RzIChQ RUFQL1RUTFMvVEVBUCkgd2lsbCB3b3JrIHdpdGggVExTIDEuMy4gVGhpcyB3aWxsCmFsc28gaW52 b2x2ZSBtYWludGVuYW5jZSB3b3JrIGJhc2VkIG9uIGVycmF0YSBmb3VuZCBpbiBwdWJsaXNoZWQK c3BlY2lmaWNhdGlvbnMgKHN1Y2ggYXMgRUFQLVRFQVApLgoKICAgICAgICAqIERlZmluZSBzZXNz aW9uIGlkZW50aWZpZXJzIGZvciBmYXN0IHJlLWF1dGhlbnRpY2F0aW9uIGZvciBFQVAtU0lNLApF QVAtQUtBLCBFQVAtUEVBUCBhbmQgRUFQLUFLQeKAmS4gVGhlIGxhY2sgb2YgdGhpcyBkZWZpbml0 aW9uIGlzIGEgcmVjZW50bHkKZGlzY292ZXJlZCBidWcgaW4gdGhlIG9yaWdpbmFsIFJGQ3MuCgog ICAgICAgICogVXBkYXRlIHRoZSBFQVAtQUtBJyBzcGVjaWZpY2F0aW9uIChSRkMgNTQ0OCkgdG8g ZW5zdXJlIHRoYXQgaXRzCmNhcGFiaWxpdHkgdG8gcHJvdmlkZSBhIGNyeXB0b2dyYXBoaWMgYmlu ZGluZyB0byBuZXR3b3JrIGNvbnRleHQgc3RheXMgaW4Kc3luYyB3aXRoIHVwZGF0ZXMgdG8gdGhl IHJlZmVyZW5jZWQgM0dQUCBzcGVjaWZpY2F0aW9ucy4gVGhlIGRvY3VtZW50IHdpbGwKYWxzbyBj b250YWluIGFueSByZWNlbnRseSBnYWluZWQgbmV3IGtub3dsZWRnZSBvbiB2dWxuZXJhYmlsaXRp ZXMgb3IgdGhlCnBvc3NpYmxlIGltcGxpY2F0aW9ucyBvZiBwZXJ2YXNpdmUgc3VydmVpbGxhbmNl LgoKICAgICAgICAqIERldmVsb3AgYW4gZXh0ZW5zaW9uIHRvIEVBUC1BS0EnIHN1Y2ggdGhhdCBQ ZXJmZWN0IEZvcndhcmQKU2VjcmVjeSBjYW4gYmUgcHJvdmlkZWQuIFRoZXJlIG1heSBhbHNvIGJl IHByaXZhY3kgaW1wcm92ZW1lbnRzIHRoYXQgaGF2ZQpiZWNvbWUgZmVhc2libGUgd2l0aCB0aGUg IGludHJvZHVjdGlvbiBvZiByZWNlbnQgaWRlbnRpdHkgcHJpdmFjeQppbXByb3ZlbWVudHMgaW4g M0dQUCBuZXR3b3Jrcy4KCiAgICAgICAgKiBHYXRoZXIgZXhwZXJpZW5jZSByZWdhcmRpbmcgdGhl IHVzZSBvZiBsYXJnZSBjZXJ0aWZpY2F0ZXMgYW5kIGxvbmcKY2VydGlmaWNhdGUgY2hhaW5zIGlu IHRoZSBjb250ZXh0IG9mIFRMUyBiYXNlZCBFQVAgbWV0aG9kcywgYXMgc29tZQppbXBsZW1lbnRh dGlvbnMgYW5kIGFjY2VzcyBuZXR3b3JrcyBtYXkgbGltaXQgdGhlIG51bWJlciBvZiBFQVAgcGFj a2V0CmV4Y2hhbmdlcyB0aGF0IGNhbiBiZSBoYW5kbGVkLiBEb2N1bWVudCBvcGVyYXRpb25hbCBy ZWNvbW1lbmRhdGlvbnMgb3IKb3RoZXIgbWl0aWdhdGlvbiBzdHJhdGVnaWVzIHRvIGF2b2lkIGlz c3Vlcy4KCiAgICAgICAgKiBEZWZpbmUgYSBzdGFuZGFyZCBFQVAgbWV0aG9kIGZvciBtdXR1YWwg YXV0aGVudGljYXRpb24gYmV0d2VlbgphIHBlZXIgYW5kIGEgc2VydmVyIHRoYXQgaXMgYmFzZWQg b24gYW4gb3V0LW9mLWJhbmQgY2hhbm5lbC4gVGhlIG1ldGhvZAppdHNlbGYgc2hvdWxkIGJlIGlu ZGVwZW5kZW50IG9mIHRoZSB1bmRlcmx5aW5nIE9PQiBjaGFubmVsIGFuZCBzaGFsbApzdXBwb3J0 IGEgdmFyaWV0eSBvZiBPT0IgY2hhbm5lbHMgc3VjaCBhcyBORkMsIGR5bmFtaWNhbGx5IGdlbmVy YXRlZCBRUgpjb2RlcywgYXVkaW8sIGFuZCB2aXNpYmxlIGxpZ2h0LgoKICAgICAgICAqIERlZmlu ZSBtZWNoYW5pc21zIGJ5IHdoaWNoIEVBUCBtZXRob2RzIGNhbiBzdXBwb3J0IGNyZWF0aW9uIG9m CmxvbmctdGVybSBjcmVkZW50aWFscyBmb3IgdGhlIHBlZXIgYmFzZWQgb24gaW5pdGlhbCBsaW1p dGVkLXVzZSBjcmVkZW50aWFscy4KClRoZSB3b3JraW5nIGdyb3VwIGlzIGV4cGVjdGVkIHRvIHN0 YXkgaW4gY2xvc2UgY29sbGFib3JhdGlvbiB3aXRoIHRoZSBFQVAKZGVwbG95bWVudCBjb21tdW5p dHksIHRoZSBUTFMgd29ya2luZyBncm91cCAoZm9yIHdvcmsgb24gVExTIGJhc2VkIEVBUAptZXRo b2RzKSwgYW5kIHRoZSAzR1BQIHNlY3VyaXR5IGFyY2hpdGVjdHVyZSBncm91cCAoZm9yIEVBUC1B S0EnIHdvcmspLgoKTWlsZXN0b25lczoKCiAgTm92IDIwMTkgLSBXRyBsYXN0IGNhbGwgb24gb3Bl cmF0aW9uYWwgcmVjb21tZW5kYXRpb25zIGZvciBsYXJnZQogIGNlcnRpZmljYXRlIGFuZCBjaGFp biBzaXplcwoKICBOb3YgMjAxOSAtIFdHIGxhc3QgY2FsbCBvbiBkZWZpbml0aW9uIG9mIHNlc3Np b24gaWRlbnRpZmllcnMgZm9yIGZhc3QgcmUtCiAgYXV0aGVudGljYXRpb24gaW4gRUFQLVNJTSBh bmQgRUFQLUFLQQoKICBOb3YgMjAxOSAtIFdHIGFkb3B0cyBpbml0aWFsIGRyYWZ0IGFkZHJlc3Np bmcgdGhlIGVycmF0YSBmb3VuZCBpbiBFQVAtVEVBUAoKICBOb3YgMjAxOSAtIFdHIGFkb3B0cyBp bml0aWFsIGRyYWZ0IG9uIGFuIEVBUCBtZXRob2QgZm9yIG11dHVhbAogIGF1dGhlbnRpY2F0aW9u IGJhc2VkIG9uIGFuIE9PQiBjaGFubmVsCgogIE5vdiAyMDE5IC0gV0cgYWRvcHRzIGRyYWZ0IHBy b3ZpZGluZyBndWlkYW5jZSBmb3IgdXNlIG9mIFRMUyAxLjMgd2l0aCBUTFMKICBiYXNlZCBFQVAg bWV0aG9kcwoKICBKYW4gMjAyMCAtIFdHIGFkb3B0cyBpbml0aWFsIGRyYWZ0IG9uIGNyZWF0aW9u IG9mIGxvbmctdGVybSBjcmVkZW50aWFscyBmb3IKICBFQVAgcGVlciBiYXNlZCBvbiBpbml0aWFs IGxpbWl0ZWQtdXNlIGNyZWRlbnRpYWxzCgogIE1hciAyMDIwIC0gV0cgbGFzdCBjYWxsIG9uIGV4 dGVuc2lvbiB0byBFQVAtQUtBIHRvIHN1cHBvcnQgZm9yd2FyZCBzZWNyZWN5CgoKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV3LXdvcmsgbWFpbGluZyBs aXN0Cm5ldy13b3JrQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV3LXdvcmsK From nobody Fri Nov 1 09:38:36 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE551209B4; Fri, 1 Nov 2019 09:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1572625618; bh=FHkkwxV9NshlxMPKtHGeCdYUAt6eu+s1eXS1uAiRVIE=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=IKWTfmh2ZJYmTSJ7fcNkAZO0CW5u6jWeJ0hf9qHwR8b0TtJzmozCINy14ax4fQ2ZY L4z22XODS9ThbcvklzUEUyjzwC3MwphgmVBXuIoawDk91Au+QT8HDk1DoorZDVW0eu zV6xgmrWJeJERB3xZ27pyIvLfZoMOIZoyqjSA7nI= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Nov 1 09:26:54 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D88DC120A51; Fri, 1 Nov 2019 09:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1572625613; bh=FHkkwxV9NshlxMPKtHGeCdYUAt6eu+s1eXS1uAiRVIE=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=mPvTRKLbAIgnFrTsAWKTyi87D7PbeRO5nUQX9DW/Z42UNs/xGd34LS2kWW8EtcHl3 bYE7JG9cB58pMyMjQ7A7uMqjTkh5vKomkrnn436DDvYqMR2uezUtbydpNyYa/5KFMm v9sUlgy1/qBssxxlRcAgdo66icE1bHw5wjoIm3do= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5515A1209CE for ; Fri, 1 Nov 2019 09:26:47 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply_to: MIME-Version: 1.0 Message-ID: <157262560734.31927.8933918718174519050.idtracker@ietfa.amsl.com> Date: Fri, 01 Nov 2019 09:26:47 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 01 Nov 2019 09:38:28 -0700 Subject: [secdir] [new-work] WG Review: Limited Additional Mechanisms for PKIX and SMIME (lamps) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 16:27:03 -0000 The Limited Additional Mechanisms for PKIX and SMIME (lamps) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination 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 2019-11-11. Limited Additional Mechanisms for PKIX and SMIME (lamps) ----------------------------------------------------------------------- Current status: Active WG Chairs: Russ Housley Tim Hollebeek Assigned Area Director: Roman Danyliw Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: spasm@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/spasm Archive: https://mailarchive.ietf.org/arch/browse/spasm/ Group page: https://datatracker.ietf.org/group/lamps/ Charter: https://datatracker.ietf.org/doc/charter-ietf-lamps/ The PKIX and S/MIME Working Groups have been closed for some time. Some updates have been proposed to the X.509 certificate documents produced by the PKIX Working Group and the electronic mail security documents produced by the S/MIME Working Group. The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working Group is chartered to make updates where there is a known constituency interested in real deployment and there is at least one sufficiently well specified approach to the update so that the working group can sensibly evaluate whether to adopt a proposal. The LAMPS WG is now tackling these topics: 1. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority. Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information. As a result, revoking short-lived certificates is unnecessary and pointless. 2. Update the specification for the cryptographic protection of email headers -- both for signatures and encryption -- to improve the implementation situation with respect to privacy, security, usability and interoperability in cryptographically-protected electronic mail. Most current implementations of cryptographically-protected electronic mail protect only the body of the message, which leaves significant room for attacks against otherwise-protected messages. 3. The Certificate Management Protocol (CMP) is specified in RFC 4210, and it offers a vast range of certificate management options. CMP is currently being used in many different industrial environments, but it needs to be tailored to the specific needs of some environments. The LAMPS WG will develop a "lightweight" profile of CMP to more efficiently support of these environments and better facilitate interoperable implementation, while preserving cryptographic algorithm agility. In addition, necessary updates and clarifications to CMP will be specified in a separate document. This work will be coordinated with the LWIG WG. In addition, the LAMPS WG may investigate other updates to documents produced by the PKIX and S/MIME WG. The LAMPS WG may produce clarifications where needed, but the LAMPS WG shall not adopt anything beyond clarifications without rechartering. Milestones: Nov 2019 - Adopt a draft for short-lived certificate conventions Dec 2019 - Adopt a draft for header protection conventions Dec 2019 - Adopt a draft for CMP updates Dec 2019 - Adopt a draft for Lightweight CMP profile Nov 2020 - Short-lived certificate conventions sent to IESG for BCP publication Nov 2020 - CMP updates sent to IESG for standards track publication Nov 2020 - Lightweight CMP profile sent to IESG for informational publication Mar 2021 - Header protection conventions sent to IESG for standards track publication _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Nov 1 11:42:33 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF57A120B17; Fri, 1 Nov 2019 11:42:25 -0700 (PDT) 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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1U08ckNmc66; Fri, 1 Nov 2019 11:42:22 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0C3120E25; Fri, 1 Nov 2019 11:42:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 4703EE2042; Fri, 1 Nov 2019 14:42:15 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 31012-09; Fri, 1 Nov 2019 14:42:14 -0400 (EDT) Received: from securerf.ihtfp.org (99-46-190-172.lightspeed.tukrga.sbcglobal.net [99.46.190.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 00BA2E2040; Fri, 1 Nov 2019 14:42:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1572633734; bh=oDH0lBHHCbtQeGthNSfK2fpoljYy8G+9JDeTe3jOcm0=; h=From:To:Cc:Subject:Date; b=WVqXJuFConJL29NATSmMje9ih3R+Yyfam5n/O2BkSu9t095UMhUi0qmtd4vh04Y3x OsizPKUcXcabsWMsCznkexgcxkUd3ArfYP0e93fRP9Rf4pSHdKxM641eVvWcPz184M cFrrhNG7wRynNyihI0LkFPBRCoGyQAZ62jBiOVWg= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id xA1Ig48I013149; Fri, 1 Nov 2019 14:42:04 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Cc: mpls-chairs@ietf.org, luismiguel.contrerasmurillo@telefonica.com, kireeti.kompella@gmail.com Date: Fri, 01 Nov 2019 14:42:04 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: [secdir] sec-dir review of draft-ietf-mpls-rmr-12.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 18:42:26 -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 with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: * Ready to publish from a security analysis PoV, but I think this document Needs work. Details: * I feel that the issue of malicious code claiming a noce to be a Ring Master should be duplicated in the Security Considerations section. Specifically, a malicious node can bring down a ring. * I am wondering if the authors have looked at Radia Perlman's Spanning Tree Protocol when looking to detect loops/rings? The main difference I can see is that in STP the goal is to find and eliminate loops, whereas here the goal is to leverage loops for resiliancy. (NB: STP should also leverage loops for resliancy if a link goes down). If nothing else, STP should be referenced as an informational reference. * How does this protocol handle nodes with more than 2 links? For example, let's assume you have two rings that overlap by 2 nodes. For example: R0 . . . R1 . . R7 R2 Anti- | . Ring . | Clockwise | . . | Clockwise v . RID = 17 . v R6 R3 . . R5 . . . R4 . . R13 R8 Anti- | . Ring . | Clockwise | . . | Clockwise v . RID = 18? . v R12 R9 . . R11. . . R10 When R4 sends messages to R3 and R8, how are R3 and R8 supposed to know that they are in different rings? All I can imagine is that this only works if both R4 and R5 are specifically (and manually) configured, because I don't see how the promiscous mode discovery protocol described here would work. I feel the protocol, as described, is missing something. Perhaps the issue is that a node needs to hear the same RID from neighbors on two different links to know that it is a part of a ring. Also, it needs to ensure it never "sends back" a message. What I mean is that, assume R4 sends R8 a TLV saying R18/CW. R8 can then forward R18/CW to R9, but should not send (yet) R18/AC back to R4. Similarly, R5 sends to R13 R18/AC. Only once the two sets of announcements make their way around does the ring "form". At least, intuitively, I feel that's how it *should* work, but I don't feel this document actually captures this. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Sun Nov 3 11:49:55 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DBA1200C1; Sun, 3 Nov 2019 11:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0mg5KvpioaT; Sun, 3 Nov 2019 11:49:37 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5664F12008C; Sun, 3 Nov 2019 11:49:34 -0800 (PST) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id xA3JjbWT026836; Sun, 3 Nov 2019 14:49:32 -0500 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049295.ppops.net-00191d01. with ESMTP id 2w24xt8chr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 03 Nov 2019 14:49:32 -0500 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id xA3JnVZc091283; Sun, 3 Nov 2019 13:49:31 -0600 Received: from zlp30496.vci.att.com (zlp30496.vci.att.com [135.46.181.157]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id xA3JnQf9091195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 3 Nov 2019 13:49:26 -0600 Received: from zlp30496.vci.att.com (zlp30496.vci.att.com [127.0.0.1]) by zlp30496.vci.att.com (Service) with ESMTP id 3FDD5404B842; Sun, 3 Nov 2019 19:49:26 +0000 (GMT) Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30496.vci.att.com (Service) with ESMTP id 17C75404B841; Sun, 3 Nov 2019 19:49:26 +0000 (GMT) Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id xA3JnPtY029427; Sun, 3 Nov 2019 13:49:25 -0600 Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id xA3JnJ2Y029057; Sun, 3 Nov 2019 13:49:20 -0600 Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-azure.research.att.com (Postfix) with ESMTP id 1E7DDE361F; Sun, 3 Nov 2019 14:48:14 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0468.000; Sun, 3 Nov 2019 14:49:05 -0500 From: "MORTON, ALFRED C (AL)" To: Paul Wouters , "secdir@ietf.org" CC: "last-call@ietf.org" , "draft-ietf-ippm-initial-registry.all@ietf.org" , "ippm@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-ippm-initial-registry-12 Thread-Index: AQHVkLYKwCcaKwXWlEmbpQnFQLyWtKd52uhA Date: Sun, 3 Nov 2019 19:49:05 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CFA0B6B26D@njmtexg5.research.att.com> References: <157261395653.31839.392742976360807570@ietfa.amsl.com> In-Reply-To: <157261395653.31839.392742976360807570@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.141.203.172] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-03_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1911030207 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ippm-initial-registry-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2019 19:49:41 -0000 SGkgUGF1bCwNCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgY29tbWVudHMsIHBsZWFzZSBz ZWUgYmVsb3cuDQoNCkFsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog UGF1bCBXb3V0ZXJzIHZpYSBEYXRhdHJhY2tlciBbbWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmddDQo+ IFNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMSwgMjAxOSA5OjEzIEFNDQo+IFRvOiBzZWNkaXJAaWV0 Zi5vcmcNCj4gQ2M6IGxhc3QtY2FsbEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1pcHBtLWluaXRpYWwt cmVnaXN0cnkuYWxsQGlldGYub3JnOw0KPiBpcHBtQGlldGYub3JnDQo+IFN1YmplY3Q6IFNlY2Rp ciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtaXBwbS1pbml0aWFsLXJlZ2lzdHJ5LTEy DQo+IA0KPiBSZXZpZXdlcjogUGF1bCBXb3V0ZXJzDQo+IFJldmlldyByZXN1bHQ6IEhhcyBJc3N1 ZXMNCj4gDQo+IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNl Y3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZw0KPiBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRG IGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlICBJRVNHLiAgVGhlc2UNCj4gY29tbWVu dHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlICBzZWN1cml0 eSBhcmVhDQo+IGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91 bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdA0KPiBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwg Y29tbWVudHMuDQo+IA0KPiBBcyB0aGlzIGRvY3VtZW50IHBvcHVsYXRlcyBhbiBJQU5BIHJlZ2lz dHJ5IHdpdGggbWV0cmljcyB2YWx1ZXMsIG5vIHNlY3VyaXR5DQo+IGNvbnNpZGVyYXRpb25zIGFw cGx5LiBUaGlzIGlzIHN0YXRlZCBpbiB0aGUgU2VjdXJpdHkgU2VjdGlvbi4NCj4gDQo+IE5vcm1h bGx5LCB0aGUgSUFOQSBjb25zaWRlcmF0aW9ucyBhcmUgd2l0aGluIG9uZSBzZWN0aW9uIGFuZCBh bGwgb3RoZXIgc2VjdGlvbnMNCj4gYXJlIHdyaXR0ZW4gYXMgaWYgdGhpcyBoYXMgYWxyZWFkeSBi ZWVuIGRvbmUsIGV4Y2VwdCB3aXRoIGEgW1RCRF0gZm9yIGFueSB2YWx1ZQ0KPiBJQU5BIG5lZWRz IHRvIHB1dCBpbi4gQnV0IHRoaXMgZG9jdW1lbnQgdXNlcyB0ZXh0IG91dHNpZGUgdGhlIElhbmEN Cj4gQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBsaWtlOg0KPiANCj4gICAgICAgIklBTkEgaXMgYXNr ZWQgdG8gYXNzaWduIGRpZmZlcmVudCBudW1lcmljIGlkZW50aWZpZXJzIHRvIGVhY2ggb2YgdGhl IHR3bw0KPiAgICAgICBOYW1lZCBNZXRyaWNzLiINCj4gDQo+IEl0IGlzIGJldHRlciB0byByZXdy aXRlIHRoaXMgd2l0aCBjbGVhciB0ZXh0IHN0YXRpbmcgTmFtZSBYIGlzIGFzc2lnbmVkIHZhbHVl IFtUQkRdDQpbYWNtXSANClRoYW5rcywgSSdsbCBiZSB3b3JraW5nIHdpdGggSUFOQSByZXBzIHRv IHJlc29sdmUgaXNzdWVzLCB0b28uDQpUaGlzIGhhc24ndCBjb21lIGluIHByZXZpb3VzIElBTkEg cmV2aWV3cywgYnV0IHdlJ2xsIGVuZA0Kd2l0aCB3b3JkaW5nIHRoYXQgaXMgY2xlYXIgYW5kIHlv dXIgc3VnZ2VzdGlvbiBpcyBhIGdvb2Qgb25lLg0KDQo+IA0KPiBTaW1pbGFybHksIHRoZSBkb2N1 bWVudCBoYXMgIkNoYW5nZSBDb250cm9sbGVyIiwgYnV0IHRoZSB3YXkgdGhpcyBpcyBub3JtYWxs eQ0KPiBwaHJhc2VkIGlzIHRvIGJlIHBhcnQgb2YgdGhlIG5ldyBSZWdpc3RyeSBkZWZpbml0aW9u IG9mICJSZWdpc3RyYXRpb24NCj4gUHJvY2VkdXJlKHMpIiB3aGljaCBoYXMgZGVmaW5lZCB2YWx1 ZXMgbGlrZSAiRXhwZXJ0IHJldmlldyIsDQo+ICJTcGVjaWZpY2F0aW9uIFJlcXVpcmVkIiwgIkZp cnN0IENvbWUgRmlyc3QgU2VydmUiLCBldGMuIFRoZSBkb2N1bWVudCBzaG91bGQgYmUgY2hhbmdl ZA0KPiB0byByZWZsZWN0IHRoZXNlIHN0YW5kYXJkIHR5cGVzIG9mIHBvbGljaWVzLCBhbmQgYXNr IElBTkEgdG8gY3JlYXRlIHRoZQ0KPiBSZWdpc3RyaWVzIHdpdGggdGhlIHN0YW5kYXJkaXplZCBw cm9jZWR1cmUgdGVybXMgZm9yIHVwZGF0aW5nIHRob3NlIHJlZ2lzdHJpZXMuDQo+IA0KW2FjbV0g DQpJIHVuZGVyc3RhbmQgdGhhdCB0aGUgcHJlZmVycmVkIGVudHJpZXMgdW5kZXIgQ2hhbmdlIENv bnRyb2xsZXIgDQphcmUgdW5kZXIgZGlzY3Vzc2lvbiwgYW5kIHdlIGFyZSBob2xkaW5nIGZvciBn dWlkYW5jZSB0aGVyZS4NCkluIHRoZSBSZWdpc3RyeSBwcm9jZWR1cmVzLCB3ZSBjdXJyZW50bHkg Y2FsbC1vdXQgRXhwZXJ0IFJldmlldw0KZm9yIHRoZSBSZWdpc3RyYXRpb24gUHJvY2VkdXJlLCBh bmQgaXQgc2VlbXMgd2UgbWF5IGNoYW5nZSB0byANClNwZWNpZmljYXRpb24gUmVxdWlyZWQuICBB Z2FpbiwgZGlzY3Vzc2lvbiB3aXRoIElBTkEgd2lsbCBkZXRlcm1pbmUNCnRoZSBhbnN3ZXIgLSB0 aGUgYXV0aG9ycyB3YW50IHRoaXMgYmUgYXMgSUFOQS1mcmllbmRseSBhcyBwb3NzaWJsZS4NCg0K DQo= From nobody Sun Nov 3 18:50:11 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801DE1208EC for ; Sun, 3 Nov 2019 18:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFUVxGsEwC7i for ; Sun, 3 Nov 2019 18:49:56 -0800 (PST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59AB8120956 for ; Sun, 3 Nov 2019 18:49:54 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id z26so1789945wmi.4 for ; Sun, 03 Nov 2019 18:49:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2IC6GMmbJ7k7u88sWMlQMEKdPS9L3CmYKPj8Fwm3JyU=; b=NIgmuS6rzbh8f6geYJ2YkUnDVCtXFpzp6XdL++0ulJ/Maz48fFmu3UZ1V+RPOE7MPX HyKcXmAwHuWYyJe58oeXIjg2jd5FTU2e3KTFb1Zkf7cxO0+lxeOknGOI8tpt1U8DQaKy INSN6z9f0tvmxRMBKHsMPFj1ZNv20zNqyE7rY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2IC6GMmbJ7k7u88sWMlQMEKdPS9L3CmYKPj8Fwm3JyU=; b=hvwXuLot1dgR9J0fBx7NA6k3W31JADwO9wiwfqJXPkFVetz4sr4Rz9Pc/83LCH+9Ro GvdmTJD+gSdrDYn0r1Yr9EEEsgQrtTVaJ7It9KDla5muXIji5s3g6HKUstiLt6w/+pZx CmwDQt4HtI0kDUzrhzfDspAosrosnQdjdI5H0rCRInwrKUvQYa3QegRlgus0zizx0MX4 f8CO/e1dIf2+INlI4uhKLTErloxtpSk4nd1uONHleibCTYdE4K7hEdgoKEAsA+Y+nh6K 6H2F0hXhwTMvqegkkP96Z5eMj6+XpUES0amwjmx3vLXy3IfgAfoB5gHUgFAt1AOqB92/ xtcQ== X-Gm-Message-State: APjAAAUFCW1qH+5gyXF7/aE2YDeCnqw+pvTd+3lJ7KPP0+XR1MLLww/+ cFfx6vXI0RzsZiXxqh032KYGCsAEz8zZV/qnuS4LJQ== X-Google-Smtp-Source: APXvYqxfPNR2fEA1ymACxfVJMn+s1by5Rms2jMrkYM9/QqrZSCuxkvqAj56tHZ1nUWIA2zFVz1ZnNJhwXg+9ZpGNhGI= X-Received: by 2002:a1c:6a1a:: with SMTP id f26mr14004188wmc.19.1572835792591; Sun, 03 Nov 2019 18:49:52 -0800 (PST) MIME-Version: 1.0 References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> In-Reply-To: From: Nick Sullivan Date: Sun, 3 Nov 2019 18:49:36 -0800 Message-ID: To: Yaron Sheffer Cc: secdir@ietf.org, draft-ietf-tls-exported-authenticator.all@ietf.org, ietf@ietf.org, "" Content-Type: multipart/alternative; boundary="000000000000b54e4905967c5ec3" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-tls-exported-authenticator-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 02:50:03 -0000 --000000000000b54e4905967c5ec3 Content-Type: text/plain; charset="UTF-8" Following up, Yaron, do the responses by myself and Benjamin along with the does the following PR sufficiently address your comments/concerns? https://github.com/tlswg/tls-exported-authenticator/pull/52 On Wed, Sep 18, 2019 at 4:55 PM Nick Sullivan wrote: > Hi Yaron, > > Thank you for your thorough review. My answers will be inline, and I'll > incorporate some of Ben's replies if necessary. Here's a PR with proposed > changes in response to your comments: > https://github.com/tlswg/tls-exported-authenticator/pull/52 > > On Tue, Jul 16, 2019 at 12:59 PM Yaron Sheffer via Datatracker < > noreply@ietf.org> wrote: > >> Reviewer: Yaron Sheffer >> Review result: Has Issues >> >> The document is generally clear in both its motivation and the proposed >> solution. >> >> I think it's playing a bit too liberal with TLS 1.3, in sort-of but not >> quite >> deprecating renegotiation, and in changing the IANA registry in a way that >> actually changes the protocol. Details below. >> >> Other comments: >> >> * Abstract: please reword to make it clear that it's the proof (not the >> cert) >> that is portable. > > > Proposed text here: > This document describes a mechanism in Transport Layer Security (TLS) for > peers to > provide a proof of ownership of a certificate. This proof can be exported > by one peer, transmitted out-of-band to the other peer, and verified by > the receiving peer. > > * Introduction: TLS 1.3 post-handshake auth "has the >> disadvantage of requiring additional state to be stored as part of the TLS >> state machine." Why is that an issue is practice, assuming this feature is >> already supported by TLS libraries? Also, are we in effect deprecating >> this TLS >> 1.3 feature because of the security issue of the mismatched record >> boundaries? >> > > My understanding is that post-handshake authentication as defined in the > TLS 1.3 RFC is not implemented in many (any?) TLS 1.3 libraries and some > implementors would prefer to use exported authenticators. > > * "For simplicity, the mechanisms... require", maybe a normative REQUIRE? > > I'm fine with this. > > >> * Authenticator Request: please clarify that we use the TLS 1.3 format >> even when >> running on TLS 1.2. > > Updated, though it might be a bit unnecessary. > > * Also, I suggest to change "is not encrypted with a >> handshake key" which is too specific to "is sent unencrypted within the >> normal >> TLS-protected data". > > This specific text is meant to differentiate the wire format of this > message from that of the CertificateRequest message, which is encrypted > with the handshake key. The specificity is warranted. > > * Before diving into the detailed messages in Sec. 3, it >> would be nice to include a quick overview of the message sequence. > > There are two message types and three potential sequences. I've added a > short overview. > > >> * Sec. 3: >> "SHOULD use TLS", change to MUST. There's no way it can work otherwise >> anyway. >> > As Ben noted, this could be any secure channel with equivalent security to > TLS, such as QUIC. We shouldn't forbid other secure out-of-band mechanisms. > > >> * "This message reuses the structure to the CertificateRequest message" - >> repeats the preceding paragraph. > > Fixed > > >> * Sec. 4: again, SHOULD use TLS -> MUST. > > Again, I don't see the need for a MUST here. > > >> * Is >> there a requirement for all protocol messages to be sent over a single TLS >> connection? If so, please mention it. Certainly this is true for the >> Authenticator message that must be sent over a single connection and >> cannot be >> multiplexed by the high-level protocol. I think this protocol actually >> assumes >> "nice" transport properties (no message reorder, reliability) that also >> require >> a single, clean TLS connection. > > There is no such requirement. Message ordering is managed by the > application layer protocol that utilizes exported authenticators. > > >> * Why no authenticator request for servers? >> Don't we care about replay? OTOH if the client wants to detect replays, it >> would need to keep state on received authenticators, which would be very >> messy. >> > I'm not sure I understand. It's possible to use authenticator requests for > servers. > > * 4.1: when referencing Exporters, mention this is Sec. 7.5 of [TLS1.3]. > > Added "Sec. 7.5" > > * The >> discussion of Extended Master Secret only applies to TLS 1.2 - please >> clarify >> that, plus I suggest to reword this paragraph which I find hard to parse. > > re-worded > > * >> 4.2: "the extensions are chosen from the TLS handshake." - What does it >> mean >> exactly, and how does an application even know which extensions were used >> at >> the TLS layer? Reading further, we mention "ClientHello extensions." >> Maybe the >> authenticator should also include a ClientHello message to indicate >> supported >> extensions. Assuming we can peek into ClientHello contradicts the hopeful >> "even >> if it is possible to implement it at the application layer" in Sec. 6. > > > This could be clearer. Effectively, the Certificate message in the > Authenticator needs > to be constructed in a similar manner to how a Certificate message would > be created > in a TLS handshake. Namely, it can only contain extensions that were > present in either > the client hello or a preceding CertificateRequest. > > You're right that this makes an assumption that the party creating the > Authenticator > has access to the TLS handshake state. This implies that even if the > Authenticator > is created in the application space, an additional API needs to be exposed > to share > that information. > > * 4.2.1: >> the first sentence of the section is incomplete. > > > Fixed > > >> * Can I use TLS 1.3-specific >> extensions (oid_filters) if I'm running on a TLS 1.2 connection? Is there >> a >> situation where a certificate is acceptable for TLS 1.3 connections but >> not for >> TLS 1.2 connections? > > Yes TLS 1.3-specific extensions are allowed, the CertificateRequest > message is TLS 1.3-compatible. > > >> * "using a value derived from the connection secrets" - I >> think we should recommend a specific construction here to ensure people >> do it >> securely. > > This was a suggestion from the Additional Certificates use case ( > https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-05). > I'm not sure we should get into the details here. > > >> * 4.2.3: Are we computing HMAC(MAC-key, Hash(a || b || c || d))? If >> so, please say so. > > Yes, I'll put that in. > > * 4.2.4: "a constant-time comparison" - why is it actually >> required, what is the threat? An attacker can do very little because each >> authenticator being sent is different. > > As Ben noted, this was a safety note added during review. > > >> * 5: please say explicitly which >> messages are used in this case to construct the authenticator. > > > Re-written. > >> * 6.1: the >> "MUST" is strange in a section that's only supposed to be informative. >> Also, >> the library may provide this extension (and possibly others) without >> requiring >> it as input. > > How else do you propose wording the requirement that this API fail if the > connection doesn't support EAs? > > >> * 6.4: "The API MUST return a failure if the >> certificate_request_context of the authenticator was used in a previously >> validated authenticator." Are we requiring the library to keep previous >> contexts for replay protection? If so, please make it explicit. > > I think this can be a SHOULD based on the burden replay protection places > on the implementation. > > >> * 7.1: this is >> changing TLS 1.3 by allowing this extension in Cert Request! I think it's >> a >> really bad idea. Better to hack special support to existing libraries, >> allowing >> this specific extension for this special case, than to change the base >> protocol. Otherwise, this document should UPDATE 8446. > > > This is a good point and one that we struggled a bit with during design. > We needed to allow SNI in the CertificateRequest message because it can be > client-generated in this context. I'd be ok with creating a different > extension for this, but it's rather elegant to re-use it in this context. *I'd > like to hear some opinions from the working group* on this point > > >> * 8: I think the >> Security Considerations is the right place to talk about interaction >> between >> this protocol and TLS 1.3 (or 1.2) renegotiation. Even if we simply >> RECOMMEND >> not to do it. Or else explain the use cases where renegotiation is still >> useful >> if there are any. >> > > I'm not sure this document should be prescriptive about use cases. This > doc is providing a new capability that may be leveraged at the application > to replace the functionality of existing mechanisms, but I'm not convinced > the evaluation of the trade-offs of different mechanisms should be > contained in this document. > --000000000000b54e4905967c5ec3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Following up,

Yaron, do the responses b= y myself and Benjamin along with the=C2=A0does the following PR sufficientl= y address your comments/concerns?


On Wed, Sep 18= , 2019 at 4:55 PM Nick Sullivan <= nick@cloudflare.com> wrote:
Hi=C2=A0Yaron,

Thank= you for your thorough review. My answers will be inline, and I'll inco= rporate=C2=A0some of Ben's replies if necessary. Here's a PR with p= roposed changes in response to your comments:
<= br>
O= n Tue, Jul 16, 2019 at 12:59 PM Yaron Sheffer via Datatracker <noreply@ietf.org> wro= te:
Reviewer: Ya= ron Sheffer
Review result: Has Issues

The document is generally clear in both its motivation and the proposed
solution.

I think it's playing a bit too liberal with TLS 1.3, in sort-of but not= quite
deprecating renegotiation, and in changing the IANA registry in a way that<= br> actually changes the protocol. Details below.

Other comments:

* Abstract: please reword to make it clear that it's the proof (not the= cert)
that is portable.

Proposed text here:
=
This document describes a mechanism in Transport Layer Security (TLS) = for peers to
provide a proof of ownership of a certificate.=C2=A0 This p= roof can be exported
by one peer, transmitted out-of-band to the other p= eer, and verified by the receiving peer.

* Introduction: TLS 1.3 post-handsh= ake auth "has the
disadvantage of requiring additional state to be stored as part of the TLS<= br> state machine." Why is that an issue is practice, assuming this featur= e is
already supported by TLS libraries? Also, are we in effect deprecating this= TLS
1.3 feature because of the security issue of the mismatched record boundari= es?

My understanding is that post-hands= hake authentication=C2=A0as defined in the TLS 1.3 RFC is not implemented = in many (any?) TLS 1.3 libraries and some implementors=C2=A0would prefer to= use exported authenticators.

* "For simplicity, the mechanisms... require", maybe a normative = REQUIRE?
I'm fine with this.
=C2=A0
* Authenticator Request: ple= ase clarify that we use the TLS 1.3 format even when
running on TLS 1.2.
=C2=A0Updated, though it might be a bi= t unnecessary.

* Also, I suggest to change "is not encrypted with a
handshake key" which is too specific to "is sent unencrypted with= in the normal
TLS-protected data".
This specific text is meant to d= ifferentiate the wire format of this message from that of the CertificateRe= quest message, which is encrypted with the handshake key. The specificity i= s warranted.

* Before diving into the detailed messages in Sec. 3, it
would be nice to include a quick overview of the message sequence.
There are two message types and three potential sequences. I'v= e added a short overview.
=C2=A0
* Sec. 3:
"SHOULD use TLS", change to MUST. There's no way it can work = otherwise anyway.
As Ben noted, this could be any secu= re channel with equivalent security to TLS, such as QUIC. We shouldn't = forbid other secure out-of-band mechanisms.
=C2=A0
* "This message reuses the structure to the CertificateRequest message= " -
repeats the preceding paragraph.
Fixed
=C2=A0
* Sec. 4: again, SHOUL= D use TLS -> MUST.
Again, I don't see the need for = a MUST here.
=C2=A0
* Is
there a requirement for all protocol messages to be sent over a single TLS<= br> connection? If so, please mention it. Certainly this is true for the
Authenticator message that must be sent over a single connection and cannot= be
multiplexed by the high-level protocol. I think this protocol actually assu= mes
"nice" transport properties (no message reorder, reliability) tha= t also require
a single, clean TLS connection.
There is no such requireme= nt. Message ordering is managed by the application layer protocol that util= izes exported authenticators.
=C2=A0
* Why no authenticator request for servers?
Don't we care about replay? OTOH if the client wants to detect replays,= it
would need to keep state on received authenticators, which would be very me= ssy.
I'm not sure I understand. It's possib= le to use authenticator requests for servers.

* 4.1: when referencing Exporters,= mention this is Sec. 7.5 of [TLS1.3].
Added=C2=A0 "S= ec. 7.5"

* The
discussion of Extended Master Secret only applies to TLS 1.2 - please clari= fy
that, plus I suggest to reword this paragraph which I find hard to parse.
re-worded

*
4.2: "the extensions are chosen from the TLS handshake." - What d= oes it mean
exactly, and how does an application even know which extensions were used a= t
the TLS layer? Reading further, we mention "ClientHello extensions.&qu= ot; Maybe the
authenticator should also include a ClientHello message to indicate support= ed
extensions. Assuming we can peek into ClientHello contradicts the hopeful &= quot;even
if it is possible to implement it at the application layer" in Sec. 6.=

This could be clearer. Effectively, the Ce= rtificate message in the Authenticator needs
to be constructed in= a similar manner to how a Certificate message would be created
i= n a TLS handshake. Namely, it can only contain extensions that were present= in either
the client hello or a preceding=C2=A0CertificateReques= t.

You're right that this makes an assumption = that the party creating the Authenticator
has access to the TLS h= andshake state. This implies that even if the Authenticator
is cr= eated in the application space, an additional API needs to be exposed to sh= are
that information.

* 4.2.1:
the first sentence of the section is incomplete.

Fixed
=C2=A0
* Can I use TLS 1.3-specific
extensions (oid_filters) if I'm running on a TLS 1.2 connection? Is the= re a
situation where a certificate is acceptable for TLS 1.3 connections but not= for
TLS 1.2 connections?
Yes TLS 1.3-specific extensions are a= llowed, the CertificateRequest message is TLS 1.3-compatible.
=C2= =A0
* "using a = value derived from the connection secrets" - I
think we should recommend a specific construction here to ensure people do = it
securely.
This was a suggestion from the Additional Certif= icates use case (https://tools.ietf.org/html/= draft-bishop-httpbis-http2-additional-certs-05). I'm not sure we sh= ould get into the details here.
=C2=A0
* 4.2.3: Are we computing HMAC(MAC-key, Hash(a= || b || c || d))? If
so, please say so.
Yes, I'll put that in.
* 4.2.4: "a = constant-time comparison" - why is it actually
required, what is the threat? An attacker can do very little because each authenticator being sent is different.
As Ben noted, this = was a safety note added during review.
=C2=A0
* 5: please say explicitly which
messages are used in this case to construct the authenticator.
=

Re-written.=C2=A0
* 6.1: the
"MUST" is strange in a section that's only supposed to be inf= ormative. Also,
the library may provide this extension (and possibly others) without requir= ing
it as input.
How else do you propose wording the requireme= nt that this API fail if the connection doesn't support EAs?
= =C2=A0
* 6.4: "= The API MUST return a failure if the
certificate_request_context of the authenticator was used in a previously validated authenticator." Are we requiring the library to keep previou= s
contexts for replay protection? If so, please make it explicit.
I think this can be a SHOULD based on the burden replay protection pl= aces on the implementation.=C2=A0
=C2=A0
*=C2=A0 7.1: this is
changing TLS 1.3 by allowing this extension in Cert Request! I think it'= ;s a
really bad idea. Better to hack special support to existing libraries, allo= wing
this specific extension for this special case, than to change the base
protocol. Otherwise, this document should UPDATE 8446.
This is a good point and one that we struggled a bit with durin= g design. We needed to allow SNI in the CertificateRequest message because = it can be client-generated in this context. I'd be ok with creating a d= ifferent extension for this, but it's rather elegant to re-use it in th= is context. I'd like to hear some opinions from the working group on this point
=C2=A0
* 8: I think the
Security Considerations is the right place to talk about interaction betwee= n
this protocol and TLS 1.3 (or 1.2) renegotiation. Even if we simply RECOMME= ND
not to do it. Or else explain the use cases where renegotiation is still us= eful
if there are any.

I'm not sure this= document should be prescriptive about use cases. This doc is providing a n= ew capability that may be leveraged at the application to replace the funct= ionality of existing mechanisms, but I'm not convinced the evaluation o= f the trade-offs of different mechanisms should be contained in this docume= nt.
--000000000000b54e4905967c5ec3-- From nobody Sun Nov 3 19:54:32 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C947120848 for ; Sun, 3 Nov 2019 19:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rOHanQsQyKu for ; Sun, 3 Nov 2019 19:54:21 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1943A120812 for ; Sun, 3 Nov 2019 19:54:21 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id r22so11819489qtt.2 for ; Sun, 03 Nov 2019 19:54:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Pq7nWTH53QfNHeZqya4ydbm0u7cyU4EiK4Uy7pcEDFI=; b=T9Fv4d1FGIlKKuR+BghkmoZt8UJUfoQXyllzJelxchZPcIQjALsmqaR67eD1b1MkEF u5bF6Rtj8w8+rffA2BJTjNudNHPp2iNa850X1qIm8ZiYjWUM++cm4YleO2lqXrDcmyzj 7c5bKO6YMHlA3dhXUc7Oaox43PjY5p/iuJq7ht/ww8Vel87kyPHGHRrADIYa1jfbNWrw iKKO0LJV8CsaZsO8j+mlyAdo6bkHfo4LUROZYdVuji88AmbOWeH9GxO04mLnBn+zycJQ qMguPvgF/7bUHLujqEGxOAHNZxPyuai77znwclMY5mr6/Yer1DjteF/XAs4lMxSZjssK RhPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Pq7nWTH53QfNHeZqya4ydbm0u7cyU4EiK4Uy7pcEDFI=; b=LjMvL4pTWW6eh4e1nSnDjshT26X0cm9wPsLDHCciWxG5dvkvHtHW0P4mvoUFREf6Cq SE9oUtIy06xblxx4ShImrxYB0vbBhs9S5DmdiUjkKxshPJuqIQEDo5ihKYdXV9fHIzQ4 x2feJMQnxyxUKFpoMTfmBCS2tOOHjMrPuTr6IFaWlj4+NPCG2GJ+k/I9R7KmJ8ACXQ2J /4IwV30+91i4O5QnH+Tkbq6GqLtVgIdm9hFfAlZbQwWaJv0EQMT5AGki1unlOUIGETLH wPc/pStSM770tDZ4A76pZiQRkxdruadr1jXV08VTumfmLOpyA5jHUtLo9Z4r/9+eS71o qamA== X-Gm-Message-State: APjAAAUab3xtafI1iDJn8P5MZt9TBMJq5zmwwmE5VRl87X2WnjXc2JRR 7xf/CqGXKiRL4Fs5DfOIqaWYmIiSSUZbTMvFKm7HZg== X-Google-Smtp-Source: APXvYqxWLhOfHUc1tl46FY/aD+dr76XdhOvuPqmx77yMuXSkNM2gU3A0ZMM6JTavE43wfWrRPdxvOUgOaOB4aS5BnYQ= X-Received: by 2002:a0c:9838:: with SMTP id c53mr20760057qvd.250.1572839659936; Sun, 03 Nov 2019 19:54:19 -0800 (PST) MIME-Version: 1.0 References: <157100555733.20750.5488529297693995498@ietfa.amsl.com> In-Reply-To: From: Joseph Salowey Date: Sun, 3 Nov 2019 19:54:09 -0800 Message-ID: To: CARLOS JESUS BERNARDOS CANO Cc: secdir , draft-ietf-dmm-distributed-mobility-anchoring.all@ietf.org, The IESG , dmm Content-Type: multipart/alternative; boundary="00000000000038335805967d4542" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dmm-distributed-mobility-anchoring-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 03:54:24 -0000 --00000000000038335805967d4542 Content-Type: text/plain; charset="UTF-8" Hi Carlos, THanks for addressing my comments. I don't have any further issues with the document. Cheers, Joe On Fri, Nov 1, 2019 at 5:06 AM CARLOS JESUS BERNARDOS CANO wrote: > Dear Joseph, > > We've just posted a new revision (-14) addressing all your comments. > > Thanks! > > Carlos > > On Fri, Oct 18, 2019 at 1:12 PM CARLOS JESUS BERNARDOS CANO < > cjbc@it.uc3m.es> wrote: > >> Dear Joseph, >> >> Thanks a lot for the review. We will improve the security consideration >> section by including also some of the considerations mentioned in draft- >> ietf-dmm-deployment-models-04, and also by better scoping current text. >> We believe we don't need much more in terms of text, as the document is >> informational, and the actual security mechanisms for a distributed >> anchoring solution would depend on the specifics of that solution. We can >> also better reflect that rational in the text. >> >> Thanks, >> >> Carlos >> >> On Mon, Oct 14, 2019 at 12:25 AM Joseph Salowey via Datatracker < >> noreply@ietf.org> wrote: >> >>> Reviewer: Joseph Salowey >>> Review result: Has Issues >>> >>> 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 summary of the review is the document has issues with the security >>> considerations section. >>> >>> The security consideration section is extremely light. It mainly >>> contains text >>> from RFC 7333. It seems that there should be more discussion of >>> security as it >>> relates to the different configurations and different cases. Do each >>> of these >>> cases have the same security properties and require the same types of >>> security >>> controls? >>> >>> Are the IPSEC recommendations mentioned in the security considerations of >>> draft-ietf-dmm-deployment-models-04 applicable for all the cases? >>> Should >>> these be pointed out in the security considerations section? >>> >>> >>> >> >> -- >> Special Issue "Beyond 5G Evolution": >> https://www.mdpi.com/journal/electronics/special_issues/beyond_5g >> >> > > -- > Special Issue "Beyond 5G Evolution": > https://www.mdpi.com/journal/electronics/special_issues/beyond_5g > > --00000000000038335805967d4542 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carlos,

THanks for addressing my com= ments.=C2=A0 I don't have any further issues with the document.=C2=A0= =C2=A0

Cheers,

Joe
<= /div>
O= n Fri, Nov 1, 2019 at 5:06 AM CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> wrote:
Dear Joseph,

=
We've just posted a new revision (-14) addressing all your c= omments.

Thanks!

Carlos

On Fri, Oct 18, 2019 at 1:12 PM CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> wrote= :
Dear Joseph,

Thanks a lot for the review. We will imp= rove the security consideration section by including also some of the consi= derations mentioned in=C2=A0draft-ietf-dmm<= /span>-deployment-models-04, and also by better scoping current text. We be= lieve we don't need much more in terms of text, as the document is info= rmational, and the actual security mechanisms for a distributed anchoring s= olution would depend on the specifics of that solution. We can also better = reflect that rational in the text.

Thanks,

Carlos

On Mon, Oct 14, 2019 at 12:25 AM Joseph Salow= ey via Datatracker <noreply@ietf.org> wrote:
Reviewer: Joseph Salowey
Review result: Has Issues

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=A0 These comments were written primarily for the benefit of the security area directors.=C2=A0 Document editors and WG chairs should treat<= br> these comments just like any other last call comments.

The summary of the review is the document has issues with the security
considerations section.

The security consideration section is extremely light.=C2=A0 It mainly cont= ains text
from RFC 7333.=C2=A0 It seems that there should be more discussion of secur= ity as it
relates to the different configurations and different cases.=C2=A0 =C2=A0Do= each of these
cases have the same security properties and require the same types of secur= ity
controls?

Are the IPSEC recommendations mentioned in the security considerations of draft-ietf-dmm-deployment-models-04 applicable for all the cases?=C2=A0 =C2= =A0Should
these be pointed out in the security considerations section?




--


--
--00000000000038335805967d4542-- From nobody Mon Nov 4 02:20:59 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC6D12096E; Mon, 4 Nov 2019 02:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.159, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WogOAV2_phdv; Mon, 4 Nov 2019 02:20:50 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76622120100; Mon, 4 Nov 2019 02:20:49 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id l10so16353480wrb.2; Mon, 04 Nov 2019 02:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=ipg6iU+jMB5XAKE2RJKv2PW3WR1ODcyvdnHRVdOYAxU=; b=tZrrbM0AOvdQIwHO19lIPT9Yzc+iBtiw2fEk03FIj6dWnRK5rXAt6atAWn8lkMfMrD mpcIhgCduFJnWrOe9fJUULVVZA8Fl9Z7dEWuzH6Ao8lSVd/z0NG435NiSgMCtk9+3xCc 8yaNdEbrGicJyAmxPNO49cB1mKUPTZtibm4TGY5YHUvJwntpDtxX65I3/r+Q9QYF15oC VwdkMuhDkJLajY48ATYJprBCqvNEautTRpORsqwHNjpeRBPKZfJqx0RMTeLldYa4xx03 EkCFctcwRP7ZdEo1l73sF5ptIHuk6AcvZACApcwIitardFWmiGLd5huPOOnu7+yLfZs8 U+yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=ipg6iU+jMB5XAKE2RJKv2PW3WR1ODcyvdnHRVdOYAxU=; b=HIGPzO/UNryFda5GjmwrnpCcgGaBnEhBzD3eHU1+Qr494JayGO22BZ/GLqgFKKf6DI mNPCdRKn8wNTtOBCv1QxicbmPXU/9X/e8++jDCeyo54lhsxfOeVCdBfJVuhjsscm8obx zo8rLAgwT3L6dK2RLVY/Rf2A16k/5AkyTTckWWRDUjpwwAJVQQeY+0sStXUADZGxEFLj 6hBEw+D83YAoveRRCQaD/kJ2FW6r9Z4ITAfcmAKYwQvYkPdjpC4Ej1TPqGeZMF/Fw2r8 uaLjsUWXuHUeQ2f++G+am8B2eUJe1/IumMxjwreJGAeTLURY/Eg+pmH1PyCSH5BLPI2p agyw== X-Gm-Message-State: APjAAAWqkDC0j47h2taI8+CRfr1/YA2bcZff0s+r8xTXivcfwIe5lAXj S1JteVXo96HrNck1kdsEUm92rNEb X-Google-Smtp-Source: APXvYqxXoizjVjo3t133xDZSZMCiHWi3hoQIwfCi/sE7fAIicKWF9YoPzrj41gXKMxyWDSmBM1cFIA== X-Received: by 2002:adf:fd4a:: with SMTP id h10mr20993447wrs.90.1572862847815; Mon, 04 Nov 2019 02:20:47 -0800 (PST) Received: from [172.28.128.176] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id h205sm17923358wmf.35.2019.11.04.02.20.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Nov 2019 02:20:46 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.1e.0.191013 Date: Mon, 04 Nov 2019 12:20:45 +0200 From: Yaron Sheffer To: Nick Sullivan CC: , , , "" Message-ID: Thread-Topic: Secdir last call review of draft-ietf-tls-exported-authenticator-09 References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3655714846_1726106478" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-tls-exported-authenticator-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 10:20:52 -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_3655714846_1726106478 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Nick, =20 Apologies for not responding on time. =20 I may be missing some follow-on discussions, but: =20 Ben suggested that we mention that QUIC is also an option, even if informat= ively, in addition to the =E2=80=9CSHOULD use TLS=E2=80=9D statement. I think we left my question re: back-fitting this protocol into the IANA TL= S registry open. Quoting:=20 =20 YS: 7.1: this is changing TLS 1.3 by allowing this extension in Cert Reques= t! I think it's a really bad idea. Better to hack special support to existin= g libraries, allowing this specific extension for this special case, than to= change the base protocol. Otherwise, this document should UPDATE 8446. =20 NS: This is a good point and one that we struggled a bit with during design= . We needed to allow SNI in the CertificateRequest message because it can be= client-generated in this context. I'd be ok with creating a different exten= sion for this, but it's rather elegant to re-use it in this context. *I'd li= ke to hear some opinions from the working group* on this point =20 BK: Or, since extension codepoints are cheap, just use a new codepoint. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron =20 From: Nick Sullivan Date: Monday, November 4, 2019 at 04:49 To: Yaron Sheffer Cc: , = , , "" Subject: Re: Secdir last call review of draft-ietf-tls-exported-authenticat= or-09 =20 Following up, =20 Yaron, do the responses by myself and Benjamin along with the does the foll= owing PR sufficiently address your comments/concerns? =20 https://github.com/tlswg/tls-exported-authenticator/pull/52 =20 On Wed, Sep 18, 2019 at 4:55 PM Nick Sullivan wrote: Hi Yaron, =20 Thank you for your thorough review. My answers will be inline, and I'll inc= orporate some of Ben's replies if necessary. Here's a PR with proposed chang= es in response to your comments: https://github.com/tlswg/tls-exported-authenticator/pull/52 =20 On Tue, Jul 16, 2019 at 12:59 PM Yaron Sheffer via Datatracker wrote: Reviewer: Yaron Sheffer Review result: Has Issues The document is generally clear in both its motivation and the proposed solution. I think it's playing a bit too liberal with TLS 1.3, in sort-of but not qui= te deprecating renegotiation, and in changing the IANA registry in a way that actually changes the protocol. Details below. Other comments: * Abstract: please reword to make it clear that it's the proof (not the cer= t) that is portable. =20 Proposed text here: This document describes a mechanism in Transport Layer Security (TLS) for p= eers to provide a proof of ownership of a certificate. This proof can be exported by one peer, transmitted out-of-band to the other peer, and verified by the= receiving peer. =20 * Introduction: TLS 1.3 post-handshake auth "has the disadvantage of requiring additional state to be stored as part of the TLS state machine." Why is that an issue is practice, assuming this feature is already supported by TLS libraries? Also, are we in effect deprecating this= TLS 1.3 feature because of the security issue of the mismatched record boundari= es? =20 My understanding is that post-handshake authentication as defined in the TL= S 1.3 RFC is not implemented in many (any?) TLS 1.3 libraries and some imple= mentors would prefer to use exported authenticators. =20 * "For simplicity, the mechanisms... require", maybe a normative REQUIRE? I'm fine with this. =20 * Authenticator Request: please clarify that we use the TLS 1.3 format even= when running on TLS 1.2. Updated, though it might be a bit unnecessary. =20 * Also, I suggest to change "is not encrypted with a handshake key" which is too specific to "is sent unencrypted within the nor= mal TLS-protected data". This specific text is meant to differentiate the wire format of this messag= e from that of the CertificateRequest message, which is encrypted with the h= andshake key. The specificity is warranted. =20 * Before diving into the detailed messages in Sec. 3, it would be nice to include a quick overview of the message sequence. There are two message types and three potential sequences. I've added a sho= rt overview. =20 * Sec. 3: "SHOULD use TLS", change to MUST. There's no way it can work otherwise anyw= ay. As Ben noted, this could be any secure channel with equivalent security to = TLS, such as QUIC. We shouldn't forbid other secure out-of-band mechanisms. =20 * "This message reuses the structure to the CertificateRequest message" - repeats the preceding paragraph. Fixed =20 * Sec. 4: again, SHOULD use TLS -> MUST. Again, I don't see the need for a MUST here. =20 * Is there a requirement for all protocol messages to be sent over a single TLS connection? If so, please mention it. Certainly this is true for the Authenticator message that must be sent over a single connection and cannot= be multiplexed by the high-level protocol. I think this protocol actually assu= mes "nice" transport properties (no message reorder, reliability) that also req= uire a single, clean TLS connection. There is no such requirement. Message ordering is managed by the applicatio= n layer protocol that utilizes exported authenticators. =20 * Why no authenticator request for servers? Don't we care about replay? OTOH if the client wants to detect replays, it would need to keep state on received authenticators, which would be very me= ssy. I'm not sure I understand. It's possible to use authenticator requests for = servers. =20 * 4.1: when referencing Exporters, mention this is Sec. 7.5 of [TLS1.3]. Added "Sec. 7.5" =20 * The discussion of Extended Master Secret only applies to TLS 1.2 - please clari= fy that, plus I suggest to reword this paragraph which I find hard to parse. re-worded =20 * 4.2: "the extensions are chosen from the TLS handshake." - What does it mea= n exactly, and how does an application even know which extensions were used a= t the TLS layer? Reading further, we mention "ClientHello extensions." Maybe = the authenticator should also include a ClientHello message to indicate support= ed extensions. Assuming we can peek into ClientHello contradicts the hopeful "= even if it is possible to implement it at the application layer" in Sec. 6. =20 This could be clearer. Effectively, the Certificate message in the Authenti= cator needs to be constructed in a similar manner to how a Certificate message would be= created in a TLS handshake. Namely, it can only contain extensions that were presen= t in either the client hello or a preceding CertificateRequest. =20 You're right that this makes an assumption that the party creating the Auth= enticator has access to the TLS handshake state. This implies that even if the Authen= ticator is created in the application space, an additional API needs to be exposed = to share that information. =20 * 4.2.1: the first sentence of the section is incomplete. =20 Fixed =20 * Can I use TLS 1.3-specific extensions (oid_filters) if I'm running on a TLS 1.2 connection? Is there a situation where a certificate is acceptable for TLS 1.3 connections but not= for TLS 1.2 connections? Yes TLS 1.3-specific extensions are allowed, the CertificateRequest message= is TLS 1.3-compatible. =20 * "using a value derived from the connection secrets" - I think we should recommend a specific construction here to ensure people do = it securely. This was a suggestion from the Additional Certificates use case (https://to= ols.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-05). I'm not s= ure we should get into the details here. =20 * 4.2.3: Are we computing HMAC(MAC-key, Hash(a || b || c || d))? If so, please say so. Yes, I'll put that in. =20 * 4.2.4: "a constant-time comparison" - why is it actually required, what is the threat? An attacker can do very little because each authenticator being sent is different. As Ben noted, this was a safety note added during review. =20 * 5: please say explicitly which messages are used in this case to construct the authenticator. =20 Re-written.=20 * 6.1: the "MUST" is strange in a section that's only supposed to be informative. Also= , the library may provide this extension (and possibly others) without requir= ing it as input. How else do you propose wording the requirement that this API fail if the c= onnection doesn't support EAs? =20 * 6.4: "The API MUST return a failure if the certificate_request_context of the authenticator was used in a previously validated authenticator." Are we requiring the library to keep previous contexts for replay protection? If so, please make it explicit. I think this can be a SHOULD based on the burden replay protection places o= n the implementation.=20 =20 * 7.1: this is changing TLS 1.3 by allowing this extension in Cert Request! I think it's a really bad idea. Better to hack special support to existing libraries, allo= wing this specific extension for this special case, than to change the base protocol. Otherwise, this document should UPDATE 8446. =20 This is a good point and one that we struggled a bit with during design. We= needed to allow SNI in the CertificateRequest message because it can be cli= ent-generated in this context. I'd be ok with creating a different extension= for this, but it's rather elegant to re-use it in this context. I'd like to= hear some opinions from the working group on this point =20 * 8: I think the Security Considerations is the right place to talk about interaction betwee= n this protocol and TLS 1.3 (or 1.2) renegotiation. Even if we simply RECOMME= ND not to do it. Or else explain the use cases where renegotiation is still us= eful if there are any. =20 I'm not sure this document should be prescriptive about use cases. This doc= is providing a new capability that may be leveraged at the application to r= eplace the functionality of existing mechanisms, but I'm not convinced the e= valuation of the trade-offs of different mechanisms should be contained in t= his document. --B_3655714846_1726106478 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Nick,

&nb= sp;

Apologies for not responding on time.

 

I may be = missing some follow-on discussions, but:

 

  • Ben suggested that we= mention that QUIC is also an option, even if informatively, in addition to = the =E2=80=9CSHOULD use TLS=E2=80=9D statement.
  • I think we left my questio= n re: back-fitting this protocol into the IANA TLS registry open. Quoting: <= o:p>

 

YS: 7.1: this is changing TLS 1.3 by allowing this extension in Cert Requ= est! I think it's a really bad idea. Better to hack special support to exist= ing libraries, allowing this specific extension for this special case, than = to change the base protocol. Otherwise, this document should UPDATE 8446.

 

NS: T= his is a good point and one that we struggled a bit with during design. We n= eeded to allow SNI in the CertificateRequest message because it can be clien= t-generated in this context. I'd be ok with creating a different extension f= or this, but it's rather elegant to re-use it in this context. *I'd like to = hear some opinions from the working group* on this point

 

BK: Or, since extensio= n codepoints are cheap, just use a new codepoint.

 

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

 

From: Nick Sullivan <nick@cloudflare.com>
Date: Monday, Nove= mber 4, 2019 at 04:49
To: Yaron Sheffer <yaronf.ietf@gmail.com&= gt;
Cc: <secdir@ietf.org>, <draft-ietf-tls-exported-authe= nticator.all@ietf.org>, <ietf@ietf.org>, "<tls@ietf.org>= " <tls@ietf.org>
Subject: Re: Secdir last call review o= f draft-ietf-tls-exported-authenticator-09

<= p class=3DMsoNormal> 

Followi= ng up,

 

Yaron, do the responses by myself and Benjamin along wit= h the does the following PR sufficiently address your comments/concerns= ?

 

https://github.com/tlswg/tls-exported-authenticator/pull/52

 

<= p class=3DMsoNormal>On Wed, Sep 18, 2019 at 4:55 PM Nick Sullivan <nick@cloudflare.com> wrote:

Hi Yaron,

 <= /p>

Thank you for your thorough review. My answ= ers will be inline, and I'll incorporate some of Ben's replies if neces= sary. Here's a PR with proposed changes in response to your comments:

 

On Tue, Jul 16, = 2019 at 12:59 PM Yaron Sheffer via Datatracker <noreply@ietf.org> wrote:

Reviewe= r: Yaron Sheffer
Review result: Has Issues

The document is general= ly clear in both its motivation and the proposed
solution.

I think= it's playing a bit too liberal with TLS 1.3, in sort-of but not quite
de= precating renegotiation, and in changing the IANA registry in a way that
= actually changes the protocol. Details below.

Other comments:

= * Abstract: please reword to make it clear that it's the proof (not the cert= )
that is portable.

 

Proposed text here:

This document describes a mechanism in = Transport Layer Security (TLS) for peers to
provide a proof of ownership = of a certificate.  This proof can be exported
by one peer, transmitt= ed out-of-band to the other peer, and verified by the receiving peer.

 

* Introduction: TLS= 1.3 post-handshake auth "has the
disadvantage of requiring addition= al state to be stored as part of the TLS
state machine." Why is that= an issue is practice, assuming this feature is
already supported by TLS = libraries? Also, are we in effect deprecating this TLS
1.3 feature becaus= e of the security issue of the mismatched record boundaries?

<= /blockquote>

 

My understanding is that post-handshake authentication as de= fined in the TLS 1.3 RFC is not implemented in many (any?) TLS 1.3 libraries= and some implementors would prefer to use exported authenticators.

 

* "For simp= licity, the mechanisms... require", maybe a normative REQUIRE?

I'm fine with this.

 

* Authenticator Request: p= lease clarify that we use the TLS 1.3 format even when
running on TLS 1.2= .

 Updated, though i= t might be a bit unnecessary.

 

* Also, I suggest to change "is not encrypted with ahandshake key" which is too specific to "is sent unencrypted wit= hin the normal
TLS-protected data".

=

This specific text is meant to differentiate the wire for= mat of this message from that of the CertificateRequest message, which is en= crypted with the handshake key. The specificity is warranted.

=

 

* Before diving into the de= tailed messages in Sec. 3, it
would be nice to include a quick overview o= f the message sequence.

T= here are two message types and three potential sequences. I've added a short= overview.

 

=

* = Sec. 3:
"SHOULD use TLS", change to MUST. There's no way it can= work otherwise anyway.

A= s Ben noted, this could be any secure channel with equivalent security to TL= S, such as QUIC. We shouldn't forbid other secure out-of-band mechanisms.

 

* "This me= ssage reuses the structure to the CertificateRequest message" -
repe= ats the preceding paragraph.

Fixed

 

<= /div>

* S= ec. 4: again, SHOULD use TLS -> MUST.

Again, I don't see the need for a MUST here.

<= /div>

 

* Is
there a requirement = for all protocol messages to be sent over a single TLS
connection? If so,= please mention it. Certainly this is true for the
Authenticator message = that must be sent over a single connection and cannot be
multiplexed by t= he high-level protocol. I think this protocol actually assumes
"nice= " transport properties (no message reorder, reliability) that also requ= ire
a single, clean TLS connection.

There is no such requirement. Message ordering is managed by t= he application layer protocol that utilizes exported authenticators.

 

* Why no authenticat= or request for servers?
Don't we care about replay? OTOH if the client wa= nts to detect replays, it
would need to keep state on received authentica= tors, which would be very messy.

I'm not sure I understand. It's possible to use authenticator reques= ts for servers.

 

* 4.1: when referencing Exporters, mention this is Sec. 7.5 of [TLS1.3].<= o:p>

Added  "Sec. 7.= 5"

 

* The=
discussion of Extended Master Secret only applies to TLS 1.2 - please cl= arify
that, plus I suggest to reword this paragraph which I find hard to = parse.

re-worded

 

*
4.2: "the e= xtensions are chosen from the TLS handshake." - What does it mean
ex= actly, and how does an application even know which extensions were used atthe TLS layer? Reading further, we mention "ClientHello extensions.&q= uot; Maybe the
authenticator should also include a ClientHello message to= indicate supported
extensions. Assuming we can peek into ClientHello con= tradicts the hopeful "even
if it is possible to implement it at the = application layer" in Sec. 6.

 

This could be c= learer. Effectively, the Certificate message in the Authenticator needs=

to be constructed in a similar manne= r to how a Certificate message would be created

in a TLS handshake. Namely, it can only contain extensions t= hat were present in either

the c= lient hello or a preceding CertificateRequest.

 

You'r= e right that this makes an assumption that the party creating the Authentica= tor

has access to the TLS handsh= ake state. This implies that even if the Authenticator

<= div>

is created in the application space, an additional AP= I needs to be exposed to share

t= hat information.

 

* 4.2.1:
the first sentence of the section is incomplete.<= /p>

 

Fixed

 =

* Can I use TLS 1.3-specific
extensions (oid_filters) if I'm runn= ing on a TLS 1.2 connection? Is there a
situation where a certificate is = acceptable for TLS 1.3 connections but not for
TLS 1.2 connections?<= /o:p>

Yes TLS 1.3-specific extension= s are allowed, the CertificateRequest message is TLS 1.3-compatible.

 

* "using a valu= e derived from the connection secrets" - I
think we should recommend= a specific construction here to ensure people do it
securely.=

This was a suggestion from the Addi= tional Certificates use case (https://tools.ietf.or= g/html/draft-bishop-httpbis-http2-additional-certs-05). I'm not sure we = should get into the details here.

 

 

* 4.2.4: "a constant-time comparison" - why is= it actually
required, what is the threat? An attacker can do very little= because each
authenticator being sent is different.

As Ben noted, this was a safety note added du= ring review.

 

= * 5: please say explicitly which
messages are used in this case to constr= uct the authenticator.

 

Re-written. 

* 6.1: the
"MUST" is strange in a section that's only suppos= ed to be informative. Also,
the library may provide this extension (and p= ossibly others) without requiring
it as input.

How else do you propose wording the requirement tha= t this API fail if the connection doesn't support EAs?

<= div>

 

* 6.4: "The API MUST return a= failure if the
certificate_request_context of the authenticator was used= in a previously
validated authenticator." Are we requiring the libr= ary to keep previous
contexts for replay protection? If so, please make i= t explicit.

I think this = can be a SHOULD based on the burden replay protection places on the implemen= tation. 

 <= /p>

*  7.1: this is
changing TLS 1.3 by allowing this extension in Cert= Request! I think it's a
really bad idea. Better to hack special support = to existing libraries, allowing
this specific extension for this special = case, than to change the base
protocol. Otherwise, this document should U= PDATE 8446.

 

This is a good point and one that we s= truggled a bit with during design. We needed to allow SNI in the Certificate= Request message because it can be client-generated in this context. I'd be o= k with creating a different extension for this, but it's rather elegant to r= e-use it in this context. I'd like to hear some opinions from the working= group on this point

 <= o:p>

* 8: I think the
Security Considerations is the right place t= o talk about interaction between
this protocol and TLS 1.3 (or 1.2) reneg= otiation. Even if we simply RECOMMEND
not to do it. Or else explain the u= se cases where renegotiation is still useful
if there are any.=

 

I'm not sure this document should be prescriptive about use = cases. This doc is providing a new capability that may be leveraged at the a= pplication to replace the functionality of existing mechanisms, but I'm not = convinced the evaluation of the trade-offs of different mechanisms should be= contained in this document.

--B_3655714846_1726106478-- From nobody Mon Nov 4 04:17:21 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E461200FE; Mon, 4 Nov 2019 04:17:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liang Xia via Datatracker To: Cc: last-call@ietf.org, ippm@ietf.org, draft-ietf-ippm-metric-registry.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Liang Xia Message-ID: <157286982914.16495.10027301533569708716@ietfa.amsl.com> Date: Mon, 04 Nov 2019 04:17:09 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-ippm-metric-registry-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 12:17:09 -0000 Reviewer: Liang Xia Review result: Ready 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 document defines the format for the IANA Performance Metrics Registry. This document also gives a set of guidelines for Registered Performance Metric requesters and reviewers. I agree with the statement in Security Considerations that "This draft defines a registry structure, and does not itself introduce any new security considerations for the Internet." So, the specific security consideration for the defined new Performance Metrics Registry should be described in the mandatory references and evaluated and passed by the appointed Performance Metrics Experts. In summary, there is no more security issues left for this document. From nobody Wed Nov 6 17:32:05 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 839FA120121; Wed, 6 Nov 2019 17:31:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christopher Wood via Datatracker To: Cc: last-call@ietf.org, draft-ietf-dtn-tcpclv4.all@ietf.org, dtn@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.110.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Christopher Wood Message-ID: <157309030845.20168.4543125034732217684@ietfa.amsl.com> Date: Wed, 06 Nov 2019 17:31:48 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dtn-tcpclv4-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2019 01:31:49 -0000 Reviewer: Christopher Wood Review result: Has Issues Comments: - Section 1.1, fourth bullet: I assume certificate revocation is also out of scope. If so, listing this explicitly might be useful. If not, why not? Relatedly, is pre-shared key authentication supported? If so, perhaps we should mention that this too is out of scope? - If TLS sits below TCPCL and if resumption is used, what is the definition of a session's lifetime? Is it still bound to the underlying TCP connection lifetime? I would suggest that the definition be generalized to accommodate TLS, e.g., perhaps the lifetime is bound to the underlying transport state lifetime. Relatedly, is TLS session resumption supported (or encouraged)? When discussing TLS session establishment in Section 4, this seems to be omitted. - Section 3.2, first paragraph: What does "initiate TLS security" mean, exactly? Does this mean the initiator sends a TLS ClientHello upon TCP connection establishment, or only after some other TCPCL headers are exchanged? Similarly, is the Node ID transferred used in authenticating such a TLS connection? If so, how? Is the Node ID sent as the TLS SNI, as hinted at in Section 4.4.1 and 4.4.2, is it included in the responder's certificate SAN list, etc? I think specific details are needed here, perhaps with forward pointers to Section 4 as needed. - Section 3.2: It's not clear to me how SESS_TERM translates to graceful TLS termination (to avoid truncation attacks). The state machine diagram outlined in Section 3.3 suggests that SESS_TERM, once negotiated, does imply the end of the data transfer. It therefore seems possible for an attacker to truncate data sent between receipt of SESS_TERM and TCP FIN by simply closing the TCP connection. It would be good to require use of a TLS closure alert when finished to avoid this type of truncation. (Maybe BP prevents this by marking data transfer lengths. However, even if that's the case, proper use of TLS seems prudent.) - Section 4, first paragraph: If entities are encouraged to keep sessions alive for as long as possible, guidance on how to update TLS keying material (via key updates or explicitly tearing down the connection and starting anew) seems prudent. TLS has a bound on how much data can be encrypted under one key. - Section 4: This text: Once a TCP connection is established, each entity MUST immediately transmit a contact header over the TCP connection. suggests that TLS does *not* proceed as normal upon TCP connection establishment. This is quite problematic, since any active attacker can simply muck with the ContactHeader CAN_TLS bit to disable TLS, right? Is this threat not considered in scope? Relatedly, what is the threat model? (SSL stripping is mentioned in Section 8, but without mention of a threat model.) "Secure" sessions subject to active downgrade do not offer much in the way of security, and the document should acknowledge that in the Security Considerations. Concretely, how about the following text to replace the second paragraph in Section 8? TCPCL does not protect against active network attackers. In particular, an active man-in-the-middle attackers to set the CAN_TLS flag to 0 on either side of a TCPCL ContactHeader exchange. This leads to the "SSL Stripping" attack described in [RFC7457]. If TLS is desired for use on any TCPCL network, it is strongly encouraged that the security policy disallow use of TCPCL when "Enable TLS" is negotiated to false. This requires that the TLS handshake occurs, regardless of the policy-driven parameters of the handshake and policy-driven handling of the handshake outcome. - Section 4.4.2: Why is the recommendation that entities "SHOULD terminate the session" if the peer's certificate is untrusted, rather than "MUST terminate the session"? In what circumstances would an entity not want to terminate the connection? (Later text mentions that this may be allowed by "security policy," in which case we should mention that here.) - Section 4.4.2, fourth paragraph: Why is host name validation done *after* TLS completes, rather than during the connection? This seems wrong, though I suspect I'm misunderstanding the details. - 4.7, Enable TLS: If security policy allows the absence of TLS, why not just always use TLS and have that policy tune TLS peer authentication? (See https://tools.ietf.org/html/rfc7858#section-4.1 for an example of this.) It seems strange that opportunistic security is supported (and desired as a feature?) yet not always used. - Section 8: I see no reason why one would want to use TLS for authentication without any form of confidentiality. I would remove text referencing this use case. - Section 8: In describing volumetric DoS attacks, it might help to consider the "opposite" sort of attack, e.g., similar to what the HTTPT/2 data dribble attack exploited? (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9511) Nits: - Section 2.1, TCP Connection: typo in "and other states association" (should be associated?) - Section 2.1, Transmission Intermediate Progress: typo "transferr" (and elsewhere) - Inconsistent notation of SESS_TERM (it's referred to as SESSTERM in lots of places) - Section 3.4, last paragraph: typo "from from" - Section: typo "negotating" From nobody Wed Nov 6 17:57:51 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB4D12008F; Wed, 6 Nov 2019 17:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=DBIQxiPV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PIQ5Zq0R Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6PNQU7bKRYS; Wed, 6 Nov 2019 17:57:40 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C892120045; Wed, 6 Nov 2019 17:57:40 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 7810E529; Wed, 6 Nov 2019 20:57:39 -0500 (EST) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Wed, 06 Nov 2019 20:57:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=C72BMrL6jBquhnXCh742VpbGfDez gMlqrBOXVMSgjsc=; b=DBIQxiPVnwZPs3J13zSIG156vSbKvTgbJG6mSOzynXvp +92SOLIqTipYwXVKqS79jC87XOn7sB8ESoeUybQBYQh9Z7e+4XBNb94ZLBZB9JJv 95yhfCzIUA7+66baGCfdbPYAYZyO15VCBrGMD6sqzhGJbJjavt+xV1NbUADLafVa mP6PQkdnc6XyyNn7eeYXIrQX2eZH4v1MfsRtFH/9IHM/FEWAvCIhAVYGHBCR4L1T uGO8OHGR1V5JhHQuVLAgzHjrCanTqH4OGliQ7J2O229iMo9gG/Bei8Gn0CJpg0A/ EMqDeuEMlBljBKincKAAUgzDKTxnwdT8qN+ZWeNpqQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=C72BMr L6jBquhnXCh742VpbGfDezgMlqrBOXVMSgjsc=; b=PIQ5Zq0RwcfTAnCGuXM+sO ChYOGiT4192y8Gi5eY6KLalnYMzXh264a/0i1r5xjpcKmaDlGyFWgQoqv8aiLG63 IRzsysYNxMH67RNLX9dhRmv0z+G+OD8NF8OqIJzPHERqqSRIlZJNn9czHhmPjxS4 bL0fdk+qxKVJpOmHEnewKmgcwdwPWK8+qt+TVSvCSXixf4HNb7VRKA8bH+kj14U3 2dhmw+p/g7e1vPUa+19+24l75TW3xIOmAvd3WBfgi0ThmNf3fKrQ3+sh5a4VnnMA E/rq+i058xyWXnYysvRU/zZeq+d6FDqJCb7ynAq/lXBiTPqH9q45NPj6lj1QgPKA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddukedggedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepmhhithhrvgdrohhrgh dpihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhi nhhgsghithhsrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A98083C00A1; Wed, 6 Nov 2019 20:57:38 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: <576b4769-ae0f-4821-a127-12a8a3d05de1@www.fastmail.com> In-Reply-To: <157309030845.20168.4543125034732217684@ietfa.amsl.com> References: <157309030845.20168.4543125034732217684@ietfa.amsl.com> Date: Wed, 06 Nov 2019 17:57:18 -0800 From: "Christopher Wood" To: "secdir@ietf.org" Cc: last-call@ietf.org, draft-ietf-dtn-tcpclv4.all@ietf.org, dtn@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-dtn-tcpclv4-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2019 01:57:43 -0000 Oops. Datatracker butchered the formatting. Let's try that again: ~~~ Reviewer: Christopher Wood Review result: Has Issues Comments: - Section 1.1, fourth bullet: I assume certificate revocation is also out of scope. If so, listing this explicitly might be useful. If not, why not? Relatedly, is pre-shared key authentication supported? If so, perhaps we should mention that this too is out of scope? - If TLS sits below TCPCL and if resumption is used, what is the definition of a session's lifetime? Is it still bound to the underlying TCP connection lifetime? I would suggest that the definition be generalized to accommodate TLS, e.g., perhaps the lifetime is bound to the underlying transport state lifetime. Relatedly, is TLS session resumption supported (or encouraged)? When discussing TLS session establishment in Section 4, this seems to be omitted. - Section 3.2, first paragraph: What does "initiate TLS security" mean, exactly? Does this mean the initiator sends a TLS ClientHello upon TCP connection establishment, or only after some other TCPCL headers are exchanged? Similarly, is the Node ID transferred used in authenticating such a TLS connection? If so, how? Is the Node ID sent as the TLS SNI, as hinted at in Section 4.4.1 and 4.4.2, is it included in the responder's certificate SAN list, etc? I think specific details are needed here, perhaps with forward pointers to Section 4 as needed. - Section 3.2: It's not clear to me how SESS_TERM translates to graceful TLS termination (to avoid truncation attacks). The state machine diagram outlined in Section 3.3 suggests that SESS_TERM, once negotiated, does imply the end of the data transfer. It therefore seems possible for an attacker to truncate data sent between receipt of SESS_TERM and TCP FIN by simply closing the TCP connection. It would be good to require use of a TLS closure alert when finished to avoid this type of truncation. (Maybe BP prevents this by marking data transfer lengths. However, even if that's the case, proper use of TLS seems prudent.) - Section 4, first paragraph: If entities are encouraged to keep sessions alive for as long as possible, guidance on how to update TLS keying material (via key updates or explicitly tearing down the connection and starting anew) seems prudent. TLS has a bound on how much data can be encrypted under one key. - Section 4: This text: Once a TCP connection is established, each entity MUST immediately transmit a contact header over the TCP connection. suggests that TLS does *not* proceed as normal upon TCP connection establishment. This is quite problematic, since any active attacker can simply muck with the ContactHeader CAN_TLS bit to disable TLS, right? Is this threat not considered in scope? Relatedly, what is the threat model? (SSL stripping is mentioned in Section 8, but without mention of a threat model.) "Secure" sessions subject to active downgrade do not offer much in the way of security, and the document should acknowledge that in the Security Considerations. Concretely, how about the following text to replace the second paragraph in Section 8? TCPCL does not protect against active network attackers. In particular, an active man-in-the-middle attackers to set the CAN_TLS flag to 0 on either side of a TCPCL ContactHeader exchange. This leads to the "SSL Stripping" attack described in [RFC7457]. If TLS is desired for use on any TCPCL network, it is strongly encouraged that the security policy disallow use of TCPCL when "Enable TLS" is negotiated to false. This requires that the TLS handshake occurs, regardless of the policy-driven parameters of the handshake and policy-driven handling of the handshake outcome. - Section 4.4.2: Why is the recommendation that entities "SHOULD terminate the session" if the peer's certificate is untrusted, rather than "MUST terminate the session"? In what circumstances would an entity not want to terminate the connection? (Later text mentions that this may be allowed by "security policy," in which case we should mention that here.) - Section 4.4.2, fourth paragraph: Why is host name validation done *after* TLS completes, rather than during the connection? This seems wrong, though I suspect I'm misunderstanding the details. - 4.7, Enable TLS: If security policy allows the absence of TLS, why not just always use TLS and have that policy tune TLS peer authentication? (See https://tools.ietf.org/html/rfc7858#section-4.1 for an example of this.) It seems strange that opportunistic security is supported (and desired as a feature?) yet not always used. - Section 8: I see no reason why one would want to use TLS for authentication without any form of confidentiality. I would remove text referencing this use case. - Section 8: In describing volumetric DoS attacks, it might help to consider the "opposite" sort of attack, e.g., similar to what the HTTPT/2 data dribble attack exploited? (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9511) Nits: - Section 2.1, TCP Connection: typo in "and other states association" (should be associated?) - Section 2.1, Transmission Intermediate Progress: typo "transferr" (and elsewhere) - Inconsistent notation of SESS_TERM (it's referred to as SESSTERM in lots of places) - Section 3.4, last paragraph: typo "from from" - Section: typo "negotating" From nobody Thu Nov 7 20:09:00 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D855612008F for ; Thu, 7 Nov 2019 20:08:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.110.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <157318613887.25971.13966793584141272972.idtracker@ietfa.amsl.com> Date: Thu, 07 Nov 2019 20:08:58 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2019 04:08:59 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-12-05 Reviewer LC end Draft Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-04 Sean Turner 2019-11-07 draft-ietf-ospf-ospfv2-hbit-10 Carl Wallace 2019-11-07 draft-ietf-pim-drlb-13 Last calls: Reviewer LC end Draft John Bradley 2019-11-22 draft-schaad-cbor-content-01 Shaun Cooley 2019-11-12 draft-ietf-regext-login-security-05 Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-17 Alan DeKok 2019-11-27 draft-ietf-6man-ra-pref64-07 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Daniel Gillmor 2018-03-19 draft-gutmann-scep-14 Dan Harkins R2019-10-03 draft-ietf-dtn-bpsec-13 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-18 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Stefan Santesson 2019-10-10 draft-ietf-payload-rtp-ttml-05 Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-04 Sean Turner 2019-11-25 draft-ietf-nfsv4-rfc5661sesqui-msns-03 Sean Turner 2019-11-07 draft-ietf-ospf-ospfv2-hbit-10 Carl Wallace 2019-11-07 draft-ietf-pim-drlb-13 David Waltermire R2019-11-14 draft-ietf-hip-dex-11 David Waltermire 2019-08-07 draft-ietf-oauth-jwt-introspection-response-08 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Tim Polk 2019-10-04 draft-ietf-lwig-curve-representations-08 Next in the reviewer rotation: Linda Dunbar Donald Eastlake Shawn Emery Stephen Farrell Daniel Franke Daniel Gillmor Tobias Gondrom Ólafur Guðmundsson Phillip Hallam-Baker Steve Hanna From nobody Fri Nov 8 08:01:51 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B74B712083B; Thu, 7 Nov 2019 06:07:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1573135670; bh=fsu9pfdo0ha5eG8O0hB57DKNPeMSRjaQtlo18JmY768=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=PH5I0VmhhZamrVDAMAwzkF/5ToOusXgOTIMj6uWftnip0O0y1q9Ss3EskaQNX+X1X Jdp/cyj3HltJiSsKq9SLvtGQJH4kBF+EwTt2oFkjL4csPPlxX4x7Vq174i2uylzoj/ h8D4CRhFEkxlLiAjjqj/XCcMWAEhXrWOAv+8vAC4= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Nov 7 06:07:50 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20225120811; Thu, 7 Nov 2019 06:07:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1573135670; bh=fsu9pfdo0ha5eG8O0hB57DKNPeMSRjaQtlo18JmY768=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=PH5I0VmhhZamrVDAMAwzkF/5ToOusXgOTIMj6uWftnip0O0y1q9Ss3EskaQNX+X1X Jdp/cyj3HltJiSsKq9SLvtGQJH4kBF+EwTt2oFkjL4csPPlxX4x7Vq174i2uylzoj/ h8D4CRhFEkxlLiAjjqj/XCcMWAEhXrWOAv+8vAC4= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6C7120811 for ; Thu, 7 Nov 2019 06:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkYwa0pN0RV2 for ; Thu, 7 Nov 2019 06:07:46 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96CEE120219 for ; Thu, 7 Nov 2019 06:07:46 -0800 (PST) Received: from [42.100.7.236] (helo=[192.168.1.5]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1iSiRr-0005Wi-He for new-work@ietf.org; Thu, 07 Nov 2019 14:07:43 +0000 To: new-work@ietf.org From: xueyuan Message-ID: <97028a73-2690-1ae5-2dbb-85ab71ad6cc7@w3.org> Date: Thu, 7 Nov 2019 22:07:31 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 08 Nov 2019 08:01:50 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Second Screen Working Group (until 2019-12-06) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2019 14:07:52 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgU2Vjb25k IFNjcmVlbiBXb3JraW5nIEdyb3VwOgogwqAgaHR0cHM6Ly93M2MuZ2l0aHViLmlvL3NlY29uZHNj cmVlbi1jaGFydGVyLwoKQXMgcGFydCBvZiBlbnN1cmluZyB0aGF0IHRoZSBjb21tdW5pdHkgaXMg YXdhcmUgb2YgcHJvcG9zZWQgd29yawphdCBXM0MsIHRoaXMgZHJhZnQgY2hhcnRlciBpcyBwdWJs aWMgZHVyaW5nIHRoZSBBZHZpc29yeQpDb21taXR0ZWUgcmV2aWV3IHBlcmlvZC4KClczQyBpbnZp dGVzIHB1YmxpYyBjb21tZW50cyB0aHJvdWdoIDIwMTktMTItMDYgb24gdGhlCnByb3Bvc2VkIGNo YXJ0ZXIuIFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvCnB1YmxpYy1uZXctd29ya0B3My5vcmcsIHdo aWNoIGhhcyBhIHB1YmxpYyBhcmNoaXZlOgogwqAgaHR0cDovL2xpc3RzLnczLm9yZy9BcmNoaXZl cy9QdWJsaWMvcHVibGljLW5ldy13b3JrLwoKT3RoZXIgdGhhbiBjb21tZW50cyBzZW50IGluIGZv cm1hbCByZXNwb25zZXMgYnkgVzNDIEFkdmlzb3J5CkNvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMs IFczQyBjYW5ub3QgZ3VhcmFudGVlIGEgcmVzcG9uc2UgdG8KY29tbWVudHMuIElmIHlvdSB3b3Jr IGZvciBhIFczQyBNZW1iZXIgWzFdLCBwbGVhc2UgY29vcmRpbmF0ZQp5b3VyIGNvbW1lbnRzIHdp dGggeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUuIEZvcgpleGFtcGxlLCB5 b3UgbWF5IHdpc2ggdG8gbWFrZSBwdWJsaWMgY29tbWVudHMgdmlhIHRoaXMgbGlzdCBhbmQKaGF2 ZSB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZSByZWZlciB0byBpdCBmcm9t IGhpcwpvciBoZXIgZm9ybWFsIHJldmlldyBjb21tZW50cy4KCklmIHlvdSBzaG91bGQgaGF2ZSBh bnkgcXVlc3Rpb25zIG9yIG5lZWQgZnVydGhlciBpbmZvcm1hdGlvbiwgcGxlYXNlCmNvbnRhY3Qg RnJhbmNvaXMgRGFvdXN0IDxmZEB3My5vcmc+LCBTZWNvbmQgU2NyZWVuCldvcmtpbmcgR3JvdXAg VGVhbSBDb250YWN0IC4KClRoYW5rIHlvdSwKClh1ZXl1YW4gSmlhLCBXM0MgTWFya2V0aW5nICYg Q29tbXVuaWNhdGlvbnMKClsxXSBodHRwOi8vd3d3LnczLm9yZy9Db25zb3J0aXVtL01lbWJlci9M aXN0CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXct d29yayBtYWlsaW5nIGxpc3QKbmV3LXdvcmtAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXctd29yawo= From nobody Fri Nov 8 16:48:21 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC211200A3 for ; Fri, 8 Nov 2019 16:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRnfO26PCHV5 for ; Fri, 8 Nov 2019 16:48:19 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34DE12002F for ; Fri, 8 Nov 2019 16:48:18 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xA90mFVj027939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 8 Nov 2019 19:48:17 -0500 Date: Fri, 8 Nov 2019 16:48:14 -0800 From: Benjamin Kaduk To: secdir@ietf.org Message-ID: <20191109004814.GQ47216@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [secdir] IETF 106 secdir lunch in "Bras Basah" X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2019 00:48:20 -0000 Hi all, We've been allocated the room "Bras Basah" for our tuesday lunch slot. IIRC there are several food options in the (sub)basement of the mall to grab something quick. -Ben From nobody Sat Nov 9 02:49:39 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512C512091E for ; Sat, 9 Nov 2019 02:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FC6ybvZi08BJ for ; Sat, 9 Nov 2019 02:49:36 -0800 (PST) Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEAC2120851 for ; Sat, 9 Nov 2019 02:49:35 -0800 (PST) Received: by mail-yb1-xb30.google.com with SMTP id q18so4191216ybq.6 for ; Sat, 09 Nov 2019 02:49:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-transfer-encoding; bh=3WxnjSmESfcDJjqh83SPcpJxnZsK+jNmy/woDJkAwPM=; b=ib+ga3ekUVdL5vylz1wAsrale0TbxI4AmRj7YQEr70AuAKOydUCXl7yB2nCzW6KNSf 0eLXWDCOrfOT/FsHesL93vBijHG8f87Np63z02u3UYW10V3uAv4JI5ZH3kMOQstfY0sz S67w+He3T6QXvvjYy/Y4bxu++9nRgm0w2vnGI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-transfer-encoding; bh=3WxnjSmESfcDJjqh83SPcpJxnZsK+jNmy/woDJkAwPM=; b=aSUp+3D8NH7igdVDo0jLlcgXJMMfj27KEjIjpylVIYocs0X34G2cMSzK3NP0bvF6lP JdRjf0RGQ09fKvblojb7tUEw7wwe1mhbuDIuBVsaPKk/tXPvzA5PO9wBHm7+qHzfvBHP Fpcnjxm2u8NZQKxhJ7xXZm2yJPfeeuPQPZu7+N7h3JzGO7R6bFEMdfpSMdEMOKCu2Cnl ZYsRAiPR24qzNMxGFCZeQqJal35ETmT0z7P9P9Rx1Jgs31CbZFINuyxI8W61rVzzYKtE Anv58/2tahrPOLzoS7y5N7HOr1ydoQoAX3ETjZFYvTERsOgUE67VSMRXF3wJeR4EIvSZ TUyg== X-Gm-Message-State: APjAAAVf940o4UBAH6ap3ii1/o1vS/baxl4Ss8+tBJncG9WV2S2a7q3E wXDyA70IguxbbQQZXHtavtaFy/ySN1PW/Q== X-Google-Smtp-Source: APXvYqw938lo4Hddy8XsZR1xlL8hj11T3IcDcXxae9gx37yLdwgZL/2SkwB1+sdKI5ogWLoY6QRXgw== X-Received: by 2002:a25:4057:: with SMTP id n84mr12290218yba.435.1573296574825; Sat, 09 Nov 2019 02:49:34 -0800 (PST) Received: from [10.130.0.123] (rrcs-98-101-204-34.midsouth.biz.rr.com. [98.101.204.34]) by smtp.gmail.com with ESMTPSA id p126sm2502296ywc.16.2019.11.09.02.49.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Nov 2019 02:49:33 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.10.f.191014 Date: Sat, 09 Nov 2019 05:49:33 -0500 From: Carl Wallace To: , , Message-ID: <2572EB02-5F21-451B-95EA-B7D8D2207AC8@redhoundsoftware.com> Thread-Topic: Secdir review of draft-ietf-pim-drlb-13 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [secdir] Secdir review of draft-ietf-pim-drlb-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2019 10:49:38 -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. This document defines an extension to the PIM-SM protocol to allow some responsibilities of is Designated Router to be distributed amongst a set of routers instead of the router elected as DR. The document is well written and has clear examples. The security considerations references those of the DR as applicable to the new mechanism. This seems fine. One minor comment, the last sentence in the operational considerations section seemed odd to me. It wasn't clear to me why migration between different hash algorithms is not considered in this document (or why this is much different from changes in DR priority, which is also required to be considered as a GDR candidate). The document is ready to my eye. From nobody Wed Nov 13 07:53:59 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCD9120816; Wed, 13 Nov 2019 07:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rkfeng.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85VjEq8Q0aa3; Wed, 13 Nov 2019 07:53:42 -0800 (PST) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680059.outbound.protection.outlook.com [40.107.68.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4952120073; Wed, 13 Nov 2019 07:53:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g2WOQxPdMC7mxjvNJX7Bwi9jaTEHjarhDd8YWXMr6nS3BwTrb1HImaemoHSJMA5NQyuq2IShm/uKFgg8k28To3BuDc9zX0ks/3BNuF7BXbdILVi7wrOPcjBBhnNChlYD7xbm8vN1wXAXqR0Ch/YcLgz2n85GwmhaOr8y7+prqlHV71LQgzcxIVrtSU5UEGJqzxV4FcVY3p1XNsFt2sZfu53qIjv8OOUETYo7iVXUEcGAzHe4n0i0zofqX+/i6wL7Y4owPrEw+tb9FNTsoP/Ug2V376Rb1Kutu6iBZuRHaCdUDh9VCW/g/+qZDQcfqqhOttwaYR9CI7oQHH8dkAY7Tw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8vkCgtARTqNsP/nlkMgHzxulM8RkzGlWpv4hd44/kxM=; b=ZtOu//rJDdd3dUayuZjH9LMFMrOiIQrqFfD+rW5nTwvsoYmvkV7yV1Qobf5YJTXdSRGU9//VF/iW7qpJzRxEy4QgDnQ7d3i9yZZXDfTw8EKa4I51MFuTkvfCEZDOmwW7eXX1+Fb9ZP8QaqIAaKWkNcwlST19aBkBcXe5SbHowqgwEQphd3yZLudINC6KVvDletWeNrr5DxI0cWA/EhwS47/Wc8GFez3i82J6vdivlNMQm2gOie73FFfyIogOB2xfzIty+hw9RafUpafFPx8kyFNMvdzssP0qBb+AQfvxzqt6HNBWt4sfx2dDReWNJXkYWG11CFK6oKNr8wCxbAkmTQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=rkf-eng.com; dmarc=pass action=none header.from=rkf-eng.com; dkim=pass header.d=rkf-eng.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rkfeng.onmicrosoft.com; s=selector2-rkfeng-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8vkCgtARTqNsP/nlkMgHzxulM8RkzGlWpv4hd44/kxM=; b=CwhItNqSFy9jMKPVdzQ5fBucLkf+are2TGORVztB8L49xT/KJOMtZxpiapI4DpN6Rb+bhAEK32UvhZQTahnfKDV2kV0TuDZhfDXtbMTqgs/TFs7jdyZCrBLStGHewu6sZIN/ryURLYPW+2CKZ8TJyt0reAshB8bhx4M8p1TUQUs= Received: from MN2PR13MB3520.namprd13.prod.outlook.com (10.255.238.221) by MN2PR13MB2990.namprd13.prod.outlook.com (10.255.180.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.21; Wed, 13 Nov 2019 15:53:38 +0000 Received: from MN2PR13MB3520.namprd13.prod.outlook.com ([fe80::701b:4c2c:9db8:7370]) by MN2PR13MB3520.namprd13.prod.outlook.com ([fe80::701b:4c2c:9db8:7370%3]) with mapi id 15.20.2451.023; Wed, 13 Nov 2019 15:53:38 +0000 From: Brian Sipos To: Christopher Wood , "secdir@ietf.org" CC: "last-call@ietf.org" , "draft-ietf-dtn-tcpclv4.all@ietf.org" , "dtn@ietf.org" Thread-Topic: [Last-Call] Secdir last call review of draft-ietf-dtn-tcpclv4-15 Thread-Index: AQHVlQsiZv1NUR8az0SiDiIPZNLET6d+80gAgAKzuko= Date: Wed, 13 Nov 2019 15:53:38 +0000 Message-ID: References: <157309030845.20168.4543125034732217684@ietfa.amsl.com>, <576b4769-ae0f-4821-a127-12a8a3d05de1@www.fastmail.com> In-Reply-To: <576b4769-ae0f-4821-a127-12a8a3d05de1@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=BSipos@rkf-eng.com; x-originating-ip: [66.195.166.226] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6af63337-33e3-490c-f6a2-08d76851a610 x-ms-traffictypediagnostic: MN2PR13MB2990: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0220D4B98D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(39830400003)(136003)(366004)(376002)(15404003)(189003)(199004)(53546011)(105004)(7736002)(74316002)(446003)(486006)(8936002)(19627405001)(11346002)(606006)(229853002)(81166006)(81156014)(8676002)(256004)(14444005)(6506007)(476003)(33656002)(76176011)(7696005)(52536014)(102836004)(99286004)(316002)(80792005)(5660300002)(54906003)(110136005)(86362001)(26005)(186003)(66556008)(64756008)(66476007)(66446008)(66066001)(2906002)(14454004)(6246003)(9686003)(508600001)(54896002)(6306002)(71190400001)(4326008)(966005)(55016002)(71200400001)(3846002)(6116002)(25786009)(236005)(76116006)(66946007)(6436002)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR13MB2990; H:MN2PR13MB3520.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: rkf-eng.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pkLhwadupMqAWSmZQZTg76lyhVfpsmlj2OBuc1ZaTFHNw0MLVZ5XXF9JLgFLCHRi4kJpA8ue1ezekFAr7FVtTRiaPJOqnqWq+gT+JfVpHss+aNM3+KJvDqEx8dYOB5CZMTi7NgKFceqt2Xj8srdeOHzMl89l/VyBVSM0Bd1FnrKMan4ES1k9S0Cet/BNm7sDFROqH2q8ZnEGC8aqBZcro8/bSlhqA5km/pE4l0xL21ggsoJhktv0nTe3/Y2PwPIq/nV/zGIHI/62Wq/AhZn27i0rWxAtHq5T92Smsq+TIVYyexWecHTxsbsYGgh4fcwai10WPQV5f7eT5wblSYWxC+bTo9k1DqpJ8s+CRoge0kjnAghWU+4Hwb/jr2f3iaC1ZkuS+aV6/mrBKFE8tLKtV0XhwuC2kUmMH6d3eXwWZwWri7yB8D9nN5Akzu0C6aSj x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR13MB3520EBCB4F7786ABFDED76EE9F7B0MN2PR13MB3520namp_" MIME-Version: 1.0 X-OriginatorOrg: rkf-eng.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6af63337-33e3-490c-f6a2-08d76851a610 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2019 15:53:38.2794 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4ed8b15b-911f-42bc-8524-d89148858535 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Qnprdu/+NmnjPrrHcGz/RPE9Bg5cldl+Y8Cxs7o9oqazJedvMTWIJ0Y5f7u4ltQz5wSbXL/LIWZ63pakTYnNEg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB2990 Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-dtn-tcpclv4-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 15:53:46 -0000 --_000_MN2PR13MB3520EBCB4F7786ABFDED76EE9F7B0MN2PR13MB3520namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2hyaXN0b3BoZXIsDQpUaGFuayB5b3UgZm9yIHRoZXNlIGNvbW1lbnRzLiBNeSByZXNwb25zZXMg YXJlIGlubGluZSBiZWxvdyB3aXRoIHByZWZpeCAiQlM6ICIuIEkgaGF2ZSBiZWVuIG1ha2luZyBl ZGl0cyB0byBhIGZ1dHVyZSBkcmFmdCB3aGljaCBpcyBub3QgeWV0IHVwbG9hZGVkLg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogQ2hyaXN0b3BoZXIgV29vZCA8Y2F3 QGhlYXBpbmdiaXRzLm5ldD4NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgNiwgMjAxOSAyMDo1 Nw0KVG86IHNlY2RpckBpZXRmLm9yZyA8c2VjZGlyQGlldGYub3JnPg0KQ2M6IGxhc3QtY2FsbEBp ZXRmLm9yZyA8bGFzdC1jYWxsQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1kdG4tdGNwY2x2NC5hbGxA aWV0Zi5vcmcgPGRyYWZ0LWlldGYtZHRuLXRjcGNsdjQuYWxsQGlldGYub3JnPjsgZHRuQGlldGYu b3JnIDxkdG5AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0xhc3QtQ2FsbF0gU2VjZGlyIGxhc3Qg Y2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1kdG4tdGNwY2x2NC0xNQ0KDQpPb3BzLiBEYXRhdHJh Y2tlciBidXRjaGVyZWQgdGhlIGZvcm1hdHRpbmcuIExldCdzIHRyeSB0aGF0IGFnYWluOg0KDQp+ fn4NCg0KUmV2aWV3ZXI6IENocmlzdG9waGVyIFdvb2QNClJldmlldyByZXN1bHQ6IEhhcyBJc3N1 ZXMNCg0KQ29tbWVudHM6DQotIFNlY3Rpb24gMS4xLCBmb3VydGggYnVsbGV0OiBJIGFzc3VtZSBj ZXJ0aWZpY2F0ZSByZXZvY2F0aW9uIGlzIGFsc28gb3V0IG9mIHNjb3BlLiBJZiBzbywgbGlzdGlu ZyB0aGlzIGV4cGxpY2l0bHkgbWlnaHQgYmUgdXNlZnVsLiBJZiBub3QsIHdoeSBub3Q/IFJlbGF0 ZWRseSwgaXMgcHJlLXNoYXJlZCBrZXkgYXV0aGVudGljYXRpb24gc3VwcG9ydGVkPyBJZiBzbywg cGVyaGFwcyB3ZSBzaG91bGQgbWVudGlvbiB0aGF0IHRoaXMgdG9vIGlzIG91dCBvZiBzY29wZT8N CkJTOiBJIGFkZGVkIGV4cGxpY2l0IG91dC1vZi1zY29wZSBpbmRpY2F0aW9uIGZvciBib3RoIHJl dm9jYXRpb24gYW5kIFBTSyAoYW5kIG90aGVyIG5vbi1jZXJ0aWZpY2F0ZSkgdXNlLg0KDQotIElm IFRMUyBzaXRzIGJlbG93IFRDUENMIGFuZCBpZiByZXN1bXB0aW9uIGlzIHVzZWQsIHdoYXQgaXMg dGhlIGRlZmluaXRpb24gb2YgYSBzZXNzaW9uJ3MgbGlmZXRpbWU/IElzIGl0IHN0aWxsIGJvdW5k IHRvIHRoZSB1bmRlcmx5aW5nIFRDUCBjb25uZWN0aW9uIGxpZmV0aW1lPyBJIHdvdWxkIHN1Z2dl c3QgdGhhdCB0aGUgZGVmaW5pdGlvbiBiZSBnZW5lcmFsaXplZCB0byBhY2NvbW1vZGF0ZSBUTFMs IGUuZy4sIHBlcmhhcHMgdGhlIGxpZmV0aW1lIGlzIGJvdW5kIHRvIHRoZSB1bmRlcmx5aW5nIHRy YW5zcG9ydCBzdGF0ZSBsaWZldGltZS4gUmVsYXRlZGx5LCBpcyBUTFMgc2Vzc2lvbiByZXN1bXB0 aW9uIHN1cHBvcnRlZCAob3IgZW5jb3VyYWdlZCk/IFdoZW4gZGlzY3Vzc2luZyBUTFMgc2Vzc2lv biBlc3RhYmxpc2htZW50IGluIFNlY3Rpb24gNCwgdGhpcyBzZWVtcyB0byBiZSBvbWl0dGVkLg0K QlM6IEkgYWRkZWQgdGV4dCB0byBTZWN0aW9uIDQgdG8gaW5kaWNhdGUgYm90aCB0aGUgbGlmZXRp bWUgb2YgVExTIHNlc3Npb25zIGFuZCB0aGUgYWJpbGl0eSB0byBhdHRlbXB0IHRvIHJlc3VtZSBz ZXNzaW9ucy4NCg0KLSBTZWN0aW9uIDMuMiwgZmlyc3QgcGFyYWdyYXBoOiBXaGF0IGRvZXMgImlu aXRpYXRlIFRMUyBzZWN1cml0eSIgbWVhbiwgZXhhY3RseT8gRG9lcyB0aGlzIG1lYW4gdGhlIGlu aXRpYXRvciBzZW5kcyBhIFRMUyBDbGllbnRIZWxsbyB1cG9uIFRDUCBjb25uZWN0aW9uIGVzdGFi bGlzaG1lbnQsIG9yIG9ubHkgYWZ0ZXIgc29tZSBvdGhlciBUQ1BDTCBoZWFkZXJzIGFyZSBleGNo YW5nZWQ/IFNpbWlsYXJseSwgaXMgdGhlIE5vZGUgSUQgdHJhbnNmZXJyZWQgdXNlZCBpbiBhdXRo ZW50aWNhdGluZyBzdWNoIGEgVExTIGNvbm5lY3Rpb24/IElmIHNvLCBob3c/IElzIHRoZSBOb2Rl IElEIHNlbnQgYXMgdGhlIFRMUyBTTkksIGFzIGhpbnRlZCBhdCBpbiBTZWN0aW9uIDQuNC4xIGFu ZCA0LjQuMiwgaXMgaXQgaW5jbHVkZWQgaW4gdGhlIHJlc3BvbmRlcidzIGNlcnRpZmljYXRlIFNB TiBsaXN0LCBldGM/IEkgdGhpbmsgc3BlY2lmaWMgZGV0YWlscyBhcmUgbmVlZGVkIGhlcmUsIHBl cmhhcHMgd2l0aCBmb3J3YXJkIHBvaW50ZXJzIHRvIFNlY3Rpb24gNCBhcyBuZWVkZWQuDQpCUzog SSByZXBocmFzZWQgdGhlIGZpcnN0IHBhcmFncmFwaCBhbmQgYWRkZWQgYSByZWZlcmVuY2UgdG8g U2VjdGlvbiA0LiBUaGUgdGV4dCBpbiBTZWN0aW9uIDMgaXMgc3VwcG9zZWQgdG8gYmUgaGlnaGVy LWxldmVsIGFuZCBpbmZvcm1hdGl2ZSwgd2hlcmUgU2VjdGlvbiA0IGlzIHJlcXVpcmVtZW50cy4N Cg0KLSBTZWN0aW9uIDMuMjogSXQncyBub3QgY2xlYXIgdG8gbWUgaG93IFNFU1NfVEVSTSB0cmFu c2xhdGVzIHRvIGdyYWNlZnVsIFRMUyB0ZXJtaW5hdGlvbiAodG8gYXZvaWQgdHJ1bmNhdGlvbiBh dHRhY2tzKS4gVGhlIHN0YXRlIG1hY2hpbmUgZGlhZ3JhbSBvdXRsaW5lZCBpbiBTZWN0aW9uIDMu MyBzdWdnZXN0cyB0aGF0IFNFU1NfVEVSTSwgb25jZSBuZWdvdGlhdGVkLCBkb2VzIGltcGx5IHRo ZSBlbmQgb2YgdGhlIGRhdGEgdHJhbnNmZXIuIEl0IHRoZXJlZm9yZSBzZWVtcyBwb3NzaWJsZSBm b3IgYW4gYXR0YWNrZXIgdG8gdHJ1bmNhdGUgZGF0YSBzZW50IGJldHdlZW4gcmVjZWlwdCBvZiBT RVNTX1RFUk0gYW5kIFRDUCBGSU4gYnkgc2ltcGx5IGNsb3NpbmcgdGhlIFRDUCBjb25uZWN0aW9u LiBJdCB3b3VsZCBiZSBnb29kIHRvIHJlcXVpcmUgdXNlIG9mIGEgVExTIGNsb3N1cmUgYWxlcnQg d2hlbiBmaW5pc2hlZCB0byBhdm9pZCB0aGlzIHR5cGUgb2YgdHJ1bmNhdGlvbi4gKE1heWJlIEJQ IHByZXZlbnRzIHRoaXMgYnkgbWFya2luZyBkYXRhIHRyYW5zZmVyIGxlbmd0aHMuIEhvd2V2ZXIs IGV2ZW4gaWYgdGhhdCdzIHRoZSBjYXNlLCBwcm9wZXIgdXNlIG9mIFRMUyBzZWVtcyBwcnVkZW50 LikNCuKAi0JTOiBJIGFkZGVkIGEgcmVxdWlyZW1lbnQgdG8gc2VuZCBDbG9zdXJlIEFsZXJ0IGJl Zm9yZSBzaHV0dGluZyBkb3duIHRoZSBUTFMgc2Vzc2lvbi4gVGhlIFRDUENMIG1lc3NhZ2VzIGFy ZSBhbGwgZml4ZWQtbGVuZ3RoIG9yIHNlbGYtaW5kaWNhdGVkIGxlbmd0aCBzbyB0aGVyZSBpcyBu byBwb3NzaWJpbGl0eSBvZiBkYXRhIHRydW5jYXRpb24uDQoNCi0gU2VjdGlvbiA0LCBmaXJzdCBw YXJhZ3JhcGg6IElmIGVudGl0aWVzIGFyZSBlbmNvdXJhZ2VkIHRvIGtlZXAgc2Vzc2lvbnMgYWxp dmUgZm9yIGFzIGxvbmcgYXMgcG9zc2libGUsIGd1aWRhbmNlIG9uIGhvdyB0byB1cGRhdGUgVExT IGtleWluZyBtYXRlcmlhbCAodmlhIGtleSB1cGRhdGVzIG9yIGV4cGxpY2l0bHkgdGVhcmluZyBk b3duIHRoZSBjb25uZWN0aW9uIGFuZCBzdGFydGluZyBhbmV3KSBzZWVtcyBwcnVkZW50LiBUTFMg aGFzIGEgYm91bmQgb24gaG93IG11Y2ggZGF0YSBjYW4gYmUgZW5jcnlwdGVkIHVuZGVyIG9uZSBr ZXkuDQpCUzogSSBhZGRlZCB0ZXh0IHRvIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24g dG8gaW5jbHVkZSBhIHJlZmVyZW5jZSBhYm91dCBrZXkgdXNlIGxpbWl0cyBhbmQga2V5IHVwZGF0 ZXMuDQoNCi0gU2VjdGlvbiA0OiBUaGlzIHRleHQ6DQoNCiAgT25jZSBhIFRDUCBjb25uZWN0aW9u IGlzIGVzdGFibGlzaGVkLCBlYWNoIGVudGl0eSBNVVNUIGltbWVkaWF0ZWx5DQogIHRyYW5zbWl0 IGEgY29udGFjdCBoZWFkZXIgb3ZlciB0aGUgVENQIGNvbm5lY3Rpb24uDQoNCnN1Z2dlc3RzIHRo YXQgVExTIGRvZXMgKm5vdCogcHJvY2VlZCBhcyBub3JtYWwgdXBvbiBUQ1AgY29ubmVjdGlvbiBl c3RhYmxpc2htZW50LiBUaGlzIGlzIHF1aXRlIHByb2JsZW1hdGljLCBzaW5jZSBhbnkgYWN0aXZl IGF0dGFja2VyIGNhbiBzaW1wbHkgbXVjayB3aXRoIHRoZSBDb250YWN0SGVhZGVyIENBTl9UTFMg Yml0IHRvIGRpc2FibGUgVExTLCByaWdodD8gSXMgdGhpcyB0aHJlYXQgbm90IGNvbnNpZGVyZWQg aW4gc2NvcGU/IFJlbGF0ZWRseSwgd2hhdCBpcyB0aGUgdGhyZWF0IG1vZGVsPyAoU1NMIHN0cmlw cGluZyBpcyBtZW50aW9uZWQgaW4gU2VjdGlvbiA4LCBidXQgd2l0aG91dCBtZW50aW9uIG9mIGEg dGhyZWF0IG1vZGVsLikgIlNlY3VyZSIgc2Vzc2lvbnMgc3ViamVjdCB0byBhY3RpdmUgZG93bmdy YWRlIGRvIG5vdCBvZmZlciBtdWNoIGluIHRoZSB3YXkgb2Ygc2VjdXJpdHksIGFuZCB0aGUgZG9j dW1lbnQgc2hvdWxkIGFja25vd2xlZGdlIHRoYXQgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zLiBDb25jcmV0ZWx5LCBob3cgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0IHRvIHJlcGxhY2Ug dGhlIHNlY29uZCBwYXJhZ3JhcGggaW4gU2VjdGlvbiA4Pw0KDQogICBUQ1BDTCBkb2VzIG5vdCBw cm90ZWN0IGFnYWluc3QgYWN0aXZlIG5ldHdvcmsgYXR0YWNrZXJzLiBJbiBwYXJ0aWN1bGFyLCBh bg0KICAgYWN0aXZlIG1hbi1pbi10aGUtbWlkZGxlIGF0dGFja2VycyB0byBzZXQgdGhlIENBTl9U TFMgZmxhZyB0byAwIG9uIGVpdGhlcg0KICAgc2lkZSBvZiBhIFRDUENMIENvbnRhY3RIZWFkZXIg ZXhjaGFuZ2UuICBUaGlzIGxlYWRzIHRvIHRoZSAiU1NMIFN0cmlwcGluZyINCiAgIGF0dGFjayBk ZXNjcmliZWQgaW4gW1JGQzc0NTddLg0KDQogICBJZiBUTFMgaXMgZGVzaXJlZCBmb3IgdXNlIG9u IGFueSBUQ1BDTCBuZXR3b3JrLCBpdCBpcyBzdHJvbmdseSBlbmNvdXJhZ2VkIHRoYXQNCiAgIHRo ZSBzZWN1cml0eSBwb2xpY3kgZGlzYWxsb3cgdXNlIG9mIFRDUENMIHdoZW4gIkVuYWJsZSBUTFMi IGlzDQogICBuZWdvdGlhdGVkIHRvIGZhbHNlLiAgVGhpcyByZXF1aXJlcyB0aGF0IHRoZSBUTFMg aGFuZHNoYWtlIG9jY3VycywNCiAgIHJlZ2FyZGxlc3Mgb2YgdGhlIHBvbGljeS1kcml2ZW4gcGFy YW1ldGVycyBvZiB0aGUgaGFuZHNoYWtlIGFuZA0KICAgcG9saWN5LWRyaXZlbiBoYW5kbGluZyBv ZiB0aGUgaGFuZHNoYWtlIG91dGNvbWUuDQpCUzogWW91ciBzdGF0ZW1lbnRzIGFyZSBkZWZpbml0 ZWx5IHRydWUuIFRoZSBwdXJwb3NlIG9mIHRoZSBDQU5fVExTIGZsYWcgaGFzIGJlZW4gY2xhcmlm aWVkIGluIFNlY3Rpb24gNC4yICJDb250YWN0IEhlYWRlciIsIGFuZCBTZWN0aW9uIDggaXMgdXBk YXRlZCB0byBoYXZlIGEgc3Ryb25nZXIgcmVjb21tZW5kYXRpb24gZm9yIHBvbGljeSB0byByZXF1 aXJlIFRMUyB1c2Ugd2hlbiBUTFMgaXMgYXZhaWxhYmxlLg0KVGhlIHB1cnBvc2Ugb2YgdGhlIENB Tl9UTFMgZmxhZyBpcyB0byBhbGxvdyB0aGUgdXNlIG9mIFRDUENMIG9uIGVudGl0aWVzIHdoaWNo IHNpbXBseSBkbyBub3QgaGF2ZSBhIFRMUyBpbXBsZW1lbnRhdGlvbiBhdmFpbGFibGUuIFRoaXMg d2FzIGEgc3RhdGVkIGdvYWwgb2YgdGhlIERUTiBXRyBkdWUgdG8gdGhlIGRlc2lyZSB0byB1c2Ug VENQQ0wgaW4gZW52aXJvbm1lbnRzIHdoZXJlIHRoZSBlbnRpdGllcyBhcmUgY29uc3RyYWluZWQg KFRMUyBpcyB1bmF2YWlsYWJsZSkgYnV0IHRoZSBuZXR3b3JrIGlzIHRydXN0ZWQuDQpSZWdhcmRp bmcgdGhlIHRocmVhdCBtb2RlbCwgdGhpcyBpcyBzb21ldGhpbmcgSSBuZWVkIHRvIGxvb2sgaW50 byBhbmQgZmluZCBzb21lIGV4YW1wbGVzIG9mIGluIG90aGVyIFJGQ3MuDQoNCi0gU2VjdGlvbiA0 LjQuMjogV2h5IGlzIHRoZSByZWNvbW1lbmRhdGlvbiB0aGF0IGVudGl0aWVzICJTSE9VTEQgdGVy bWluYXRlIHRoZSBzZXNzaW9uIiBpZiB0aGUgcGVlcidzIGNlcnRpZmljYXRlIGlzIHVudHJ1c3Rl ZCwgcmF0aGVyIHRoYW4gIk1VU1QgdGVybWluYXRlIHRoZSBzZXNzaW9uIj8gSW4gd2hhdCBjaXJj dW1zdGFuY2VzIHdvdWxkIGFuIGVudGl0eSBub3Qgd2FudCB0byB0ZXJtaW5hdGUgdGhlIGNvbm5l Y3Rpb24/IChMYXRlciB0ZXh0IG1lbnRpb25zIHRoYXQgdGhpcyBtYXkgYmUgYWxsb3dlZCBieSAi c2VjdXJpdHkgcG9saWN5LCIgaW4gd2hpY2ggY2FzZSB3ZSBzaG91bGQgbWVudGlvbiB0aGF0IGhl cmUuKQ0KQlM6IEkgdXBkYXRlZCB0aGVzZSByZXF1aXJlbWVudHMgdG8gU0hBTEwgYW5kIG1hZGUg c3VyZSB0aGV5IGFyZSBhbGwgY29uZGl0aW9uZWQgb24gcG9saWN5IHJ1bGVzLg0KDQotIFNlY3Rp b24gNC40LjIsIGZvdXJ0aCBwYXJhZ3JhcGg6IFdoeSBpcyBob3N0IG5hbWUgdmFsaWRhdGlvbiBk b25lICphZnRlciogVExTIGNvbXBsZXRlcywgcmF0aGVyIHRoYW4gZHVyaW5nIHRoZSBjb25uZWN0 aW9uPyBUaGlzIHNlZW1zIHdyb25nLCB0aG91Z2ggSSBzdXNwZWN0IEknbSBtaXN1bmRlcnN0YW5k aW5nIHRoZSBkZXRhaWxzLg0KQlM6IEkgdXBkYXRlZCB0aGUgdGV4dCB0byByZWFkICJFaXRoZXIg ZHVyaW5nIG9yIGltbWVkaWF0ZWx5IGFmdGVyIHRoZSBUTFMgaGFuZHNoYWtlLi4uIiBUaGUgb25s eSByZWFzb24gZm9yIHRoaXMgaXMgc29tZSBUTFMgaW1wbGVtZW50YXRpb25zIGFsbG93IGludGVy cnVwdGluZyB0aGUgaGFuZHNoYWtlIGJ1dCBzb21lIG9ubHkgYWxsb3cgaW5zcGVjdGluZyB0aGUg cmVzdWx0cyBvZiB0aGUgaGFuZHNoYWtlLg0KDQotIDQuNywgRW5hYmxlIFRMUzogSWYgc2VjdXJp dHkgcG9saWN5IGFsbG93cyB0aGUgYWJzZW5jZSBvZiBUTFMsIHdoeSBub3QganVzdCBhbHdheXMg dXNlIFRMUyBhbmQgaGF2ZSB0aGF0IHBvbGljeSB0dW5lIFRMUyBwZWVyIGF1dGhlbnRpY2F0aW9u PyAoU2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3ODU4I3NlY3Rpb24tNC4xIGZv ciBhbiBleGFtcGxlIG9mIHRoaXMuKSBJdCBzZWVtcyBzdHJhbmdlIHRoYXQgb3Bwb3J0dW5pc3Rp YyBzZWN1cml0eSBpcyBzdXBwb3J0ZWQgKGFuZCBkZXNpcmVkIGFzIGEgZmVhdHVyZT8pIHlldCBu b3QgYWx3YXlzIHVzZWQuDQpCUzogUGVyIHRoZSBlYXJsaWVyIHJlc3BvbnNlIHRvIFNlY3Rpb24g NCB0ZXh0LCB0aGUgcmVhc29uIHRvIGFsbG93IG5vbi1UTFMgc2Vzc2lvbnMgaXMgcHVyZWx5IGZv ciBjb25zdHJhaW5lZCBlbnRpdGllcy4gVGhlIHRleHQgaW4gU2VjdGlvbiA0LjIgYW5kIFNlY3Rp b24gOCBhcmUgdXBkYXRlZCB0byBjbGFyaWZ5IHRoZSBDQU5fVExTIGZsYWcgdG8gaW5kaWNhdGUg dGhlIHByZXNlbmNlIG9mIFRMUyBpbiB0aGUgbmV0d29yayBzdGFjaywgbm90IHJlYWxseSBhIGNv bmZpZ3VyYXRpb24gcGFyYW1ldGVyLg0KDQotIFNlY3Rpb24gODogSSBzZWUgbm8gcmVhc29uIHdo eSBvbmUgd291bGQgd2FudCB0byB1c2UgVExTIGZvciBhdXRoZW50aWNhdGlvbiB3aXRob3V0IGFu eSBmb3JtIG9mIGNvbmZpZGVudGlhbGl0eS4gSSB3b3VsZCByZW1vdmUgdGV4dCByZWZlcmVuY2lu ZyB0aGlzIHVzZSBjYXNlLg0KQlM6IEkgcmVtb3ZlZCB0aGlzIHRleHQgdG8gYXZvaWQgY29uZnVz aW9uLg0KDQotIFNlY3Rpb24gODogSW4gZGVzY3JpYmluZyB2b2x1bWV0cmljIERvUyBhdHRhY2tz LCBpdCBtaWdodCBoZWxwIHRvIGNvbnNpZGVyIHRoZSAib3Bwb3NpdGUiIHNvcnQgb2YgYXR0YWNr LCBlLmcuLCBzaW1pbGFyIHRvIHdoYXQgdGhlIEhUVFBULzIgZGF0YSBkcmliYmxlIGF0dGFjayBl eHBsb2l0ZWQ/IChodHRwczovL2N2ZS5taXRyZS5vcmcvY2dpLWJpbi9jdmVuYW1lLmNnaT9uYW1l PUNWRS0yMDE5LTk1MTEpDQpCUzogVGhpcyBpcyBhIGdvb2QgY2F0Y2gsIEkgYWRkZWQgU2VjdGlv biA4IHRleHQgdG8gd2FybiBhZ2FpbnN0IGFjY2VwdGluZyB0b28tc21hbGwgU2VnbWVudCBNUlUg b3IgVHJhbnNmZXIgTVJVIHBhcmFtZXRlcnMuDQoNCk5pdHM6DQotIFNlY3Rpb24gMi4xLCBUQ1Ag Q29ubmVjdGlvbjogdHlwbyBpbiAiYW5kIG90aGVyIHN0YXRlcyBhc3NvY2lhdGlvbiIgKHNob3Vs ZCBiZSBhc3NvY2lhdGVkPykNCkJTOiBGaXhlZCB0aGlzIHR5cG8uDQotIFNlY3Rpb24gMi4xLCBU cmFuc21pc3Npb24gSW50ZXJtZWRpYXRlIFByb2dyZXNzOiB0eXBvICJ0cmFuc2ZlcnIiIChhbmQg ZWxzZXdoZXJlKQ0KQlM6IEZpeGVkIHRoaXMgdHlwby4NCi0gSW5jb25zaXN0ZW50IG5vdGF0aW9u IG9mIFNFU1NfVEVSTSAoaXQncyByZWZlcnJlZCB0byBhcyBTRVNTVEVSTSBpbiBsb3RzIG9mIHBs YWNlcykNCkJTOiBUaGUgIlNFU1NfVEVSTSIgd2FzIGEgbWVzc2FnZSB3aGlsZSBhICJTRVNTVEVS TSIgd2FzIGFuIGFjdGl2aXR5LiBJIHJlbmFtZWQgdGhlIGFjdGl2aXR5IHRvICJTVCIgdG8gYmUg Y29uc2lzdGVudCB3aXRoIG90aGVyIGFiYnJldmlhdGVkIGFjdGl2aXR5IG5hbWVzLg0KLSBTZWN0 aW9uIDMuNCwgbGFzdCBwYXJhZ3JhcGg6IHR5cG8gImZyb20gZnJvbSINCkJTOiBGaXhlZCB0aGlz IHR5cG8uDQotIFNlY3Rpb246IHR5cG8gIm5lZ290YXRpbmciDQpCUzogRml4ZWQgc2V2ZXJhbCBv ZiB0aGlzIHR5cG8uDQoNCg== --_000_MN2PR13MB3520EBCB4F7786ABFDED76EE9F7B0MN2PR13MB3520namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPiBQIHttYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO30gPC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmksQXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMnB0OyBjb2xvcjpy Z2IoMCwwLDApIj4NCkNocmlzdG9waGVyLDwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOjEycHQ7IGNvbG9y OnJnYigwLDAsMCkiPg0KVGhhbmsgeW91IGZvciB0aGVzZSBjb21tZW50cy4gTXkgcmVzcG9uc2Vz IGFyZSBpbmxpbmUgYmVsb3cgd2l0aCBwcmVmaXggJnF1b3Q7QlM6ICZxdW90Oy4gSSBoYXZlIGJl ZW4gbWFraW5nIGVkaXRzIHRvIGEgZnV0dXJlIGRyYWZ0IHdoaWNoIGlzIG5vdCB5ZXQgdXBsb2Fk ZWQuPGJyPg0KPC9kaXY+DQo8ZGl2IGlkPSJhcHBlbmRvbnNlbmQiPjwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1z aXplOjEycHQ7IGNvbG9yOnJnYigwLDAsMCkiPg0KPGJyPg0KPC9kaXY+DQo8aHIgdGFiaW5kZXg9 Ii0xIiBzdHlsZT0iZGlzcGxheTppbmxpbmUtYmxvY2s7IHdpZHRoOjk4JSI+DQo8ZGl2IGlkPSJk aXZScGx5RndkTXNnIiBkaXI9Imx0ciI+PGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMXB0IiBmYWNl PSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBjb2xvcj0iIzAwMDAwMCI+PGI+RnJvbTo8L2I+IENocmlz dG9waGVyIFdvb2QgJmx0O2Nhd0BoZWFwaW5nYml0cy5uZXQmZ3Q7PGJyPg0KPGI+U2VudDo8L2I+ IFdlZG5lc2RheSwgTm92ZW1iZXIgNiwgMjAxOSAyMDo1Nzxicj4NCjxiPlRvOjwvYj4gc2VjZGly QGlldGYub3JnICZsdDtzZWNkaXJAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBsYXN0LWNh bGxAaWV0Zi5vcmcgJmx0O2xhc3QtY2FsbEBpZXRmLm9yZyZndDs7IGRyYWZ0LWlldGYtZHRuLXRj cGNsdjQuYWxsQGlldGYub3JnICZsdDtkcmFmdC1pZXRmLWR0bi10Y3BjbHY0LmFsbEBpZXRmLm9y ZyZndDs7IGR0bkBpZXRmLm9yZyAmbHQ7ZHRuQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW0xhc3QtQ2FsbF0gU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0 Zi1kdG4tdGNwY2x2NC0xNTwvZm9udD4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IkJvZHlGcmFnbWVudCI+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMXB0Ij4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+T29wcy4gRGF0YXRyYWNrZXIgYnV0Y2hl cmVkIHRoZSBmb3JtYXR0aW5nLiBMZXQncyB0cnkgdGhhdCBhZ2Fpbjo8YnI+DQo8YnI+DQp+fn48 YnI+DQo8YnI+DQpSZXZpZXdlcjogQ2hyaXN0b3BoZXIgV29vZDxicj4NClJldmlldyByZXN1bHQ6 IEhhcyBJc3N1ZXM8YnI+DQo8YnI+DQpDb21tZW50czo8YnI+DQotIFNlY3Rpb24gMS4xLCBmb3Vy dGggYnVsbGV0OiBJIGFzc3VtZSBjZXJ0aWZpY2F0ZSByZXZvY2F0aW9uIGlzIGFsc28gb3V0IG9m IHNjb3BlLiBJZiBzbywgbGlzdGluZyB0aGlzIGV4cGxpY2l0bHkgbWlnaHQgYmUgdXNlZnVsLiBJ ZiBub3QsIHdoeSBub3Q/IFJlbGF0ZWRseSwgaXMgcHJlLXNoYXJlZCBrZXkgYXV0aGVudGljYXRp b24gc3VwcG9ydGVkPyBJZiBzbywgcGVyaGFwcyB3ZSBzaG91bGQgbWVudGlvbiB0aGF0IHRoaXMg dG9vIGlzIG91dA0KIG9mIHNjb3BlPzwvZGl2Pg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iY29sb3I6cmdiKDEyLDEwMCwxOTIpIj5CUzogSSBhZGRlZCBleHBsaWNpdCBvdXQt b2Ytc2NvcGUgaW5kaWNhdGlvbiBmb3IgYm90aCByZXZvY2F0aW9uIGFuZCBQU0sgKGFuZCBvdGhl ciBub24tY2VydGlmaWNhdGUpIHVzZS48L3NwYW4+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJQ bGFpblRleHQiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij4tIElmIFRMUyBz aXRzIGJlbG93IFRDUENMIGFuZCBpZiByZXN1bXB0aW9uIGlzIHVzZWQsIHdoYXQgaXMgdGhlIGRl ZmluaXRpb24gb2YgYSBzZXNzaW9uJ3MgbGlmZXRpbWU/IElzIGl0IHN0aWxsIGJvdW5kIHRvIHRo ZSB1bmRlcmx5aW5nIFRDUCBjb25uZWN0aW9uIGxpZmV0aW1lPyBJIHdvdWxkIHN1Z2dlc3QgdGhh dCB0aGUgZGVmaW5pdGlvbiBiZSBnZW5lcmFsaXplZCB0byBhY2NvbW1vZGF0ZSBUTFMsIGUuZy4s DQogcGVyaGFwcyB0aGUgbGlmZXRpbWUgaXMgYm91bmQgdG8gdGhlIHVuZGVybHlpbmcgdHJhbnNw b3J0IHN0YXRlIGxpZmV0aW1lLiBSZWxhdGVkbHksIGlzIFRMUyBzZXNzaW9uIHJlc3VtcHRpb24g c3VwcG9ydGVkIChvciBlbmNvdXJhZ2VkKT8gV2hlbiBkaXNjdXNzaW5nIFRMUyBzZXNzaW9uIGVz dGFibGlzaG1lbnQgaW4gU2VjdGlvbiA0LCB0aGlzIHNlZW1zIHRvIGJlIG9taXR0ZWQuPC9kaXY+ DQo8ZGl2IGNsYXNzPSJQbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMTIsMTAwLDE5 MikiPkJTOiBJIGFkZGVkIHRleHQgdG8gU2VjdGlvbiA0IHRvIGluZGljYXRlIGJvdGggdGhlIGxp ZmV0aW1lIG9mIFRMUyBzZXNzaW9ucyBhbmQgdGhlIGFiaWxpdHkgdG8gYXR0ZW1wdCB0byByZXN1 bWUgc2Vzc2lvbnMuPC9zcGFuPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij48 YnI+DQotIFNlY3Rpb24gMy4yLCBmaXJzdCBwYXJhZ3JhcGg6IFdoYXQgZG9lcyAmcXVvdDtpbml0 aWF0ZSBUTFMgc2VjdXJpdHkmcXVvdDsgbWVhbiwgZXhhY3RseT8gRG9lcyB0aGlzIG1lYW4gdGhl IGluaXRpYXRvciBzZW5kcyBhIFRMUyBDbGllbnRIZWxsbyB1cG9uIFRDUCBjb25uZWN0aW9uIGVz dGFibGlzaG1lbnQsIG9yIG9ubHkgYWZ0ZXIgc29tZSBvdGhlciBUQ1BDTCBoZWFkZXJzIGFyZSBl eGNoYW5nZWQ/IFNpbWlsYXJseSwgaXMgdGhlIE5vZGUgSUQgdHJhbnNmZXJyZWQNCiB1c2VkIGlu IGF1dGhlbnRpY2F0aW5nIHN1Y2ggYSBUTFMgY29ubmVjdGlvbj8gSWYgc28sIGhvdz8gSXMgdGhl IE5vZGUgSUQgc2VudCBhcyB0aGUgVExTIFNOSSwgYXMgaGludGVkIGF0IGluIFNlY3Rpb24gNC40 LjEgYW5kIDQuNC4yLCBpcyBpdCBpbmNsdWRlZCBpbiB0aGUgcmVzcG9uZGVyJ3MgY2VydGlmaWNh dGUgU0FOIGxpc3QsIGV0Yz8gSSB0aGluayBzcGVjaWZpYyBkZXRhaWxzIGFyZSBuZWVkZWQgaGVy ZSwgcGVyaGFwcyB3aXRoIGZvcndhcmQNCiBwb2ludGVycyB0byBTZWN0aW9uIDQgYXMgbmVlZGVk LjwvZGl2Pg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6cmdiKDEy LDEwMCwxOTIpIj5CUzogSSByZXBocmFzZWQgdGhlIGZpcnN0IHBhcmFncmFwaCBhbmQgYWRkZWQg YSByZWZlcmVuY2UgdG8gU2VjdGlvbiA0LiBUaGUgdGV4dCBpbiBTZWN0aW9uIDMgaXMgc3VwcG9z ZWQgdG8gYmUgaGlnaGVyLWxldmVsIGFuZCBpbmZvcm1hdGl2ZSwgd2hlcmUgU2VjdGlvbiA0IGlz IHJlcXVpcmVtZW50cy48L3NwYW4+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJQbGFpblRleHQi Pjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij4tIFNlY3Rpb24gMy4yOiBJdCdz IG5vdCBjbGVhciB0byBtZSBob3cgU0VTU19URVJNIHRyYW5zbGF0ZXMgdG8gZ3JhY2VmdWwgVExT IHRlcm1pbmF0aW9uICh0byBhdm9pZCB0cnVuY2F0aW9uIGF0dGFja3MpLiBUaGUgc3RhdGUgbWFj aGluZSBkaWFncmFtIG91dGxpbmVkIGluIFNlY3Rpb24gMy4zIHN1Z2dlc3RzIHRoYXQgU0VTU19U RVJNLCBvbmNlIG5lZ290aWF0ZWQsIGRvZXMgaW1wbHkgdGhlIGVuZCBvZg0KIHRoZSBkYXRhIHRy YW5zZmVyLiBJdCB0aGVyZWZvcmUgc2VlbXMgcG9zc2libGUgZm9yIGFuIGF0dGFja2VyIHRvIHRy dW5jYXRlIGRhdGEgc2VudCBiZXR3ZWVuIHJlY2VpcHQgb2YgU0VTU19URVJNIGFuZCBUQ1AgRklO IGJ5IHNpbXBseSBjbG9zaW5nIHRoZSBUQ1AgY29ubmVjdGlvbi4gSXQgd291bGQgYmUgZ29vZCB0 byByZXF1aXJlIHVzZSBvZiBhIFRMUyBjbG9zdXJlIGFsZXJ0IHdoZW4gZmluaXNoZWQgdG8gYXZv aWQgdGhpcyB0eXBlIG9mIHRydW5jYXRpb24uDQogKE1heWJlIEJQIHByZXZlbnRzIHRoaXMgYnkg bWFya2luZyBkYXRhIHRyYW5zZmVyIGxlbmd0aHMuIEhvd2V2ZXIsIGV2ZW4gaWYgdGhhdCdzIHRo ZSBjYXNlLCBwcm9wZXIgdXNlIG9mIFRMUyBzZWVtcyBwcnVkZW50Lik8L2Rpdj4NCjxkaXYgY2xh c3M9IlBsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigxMiwxMDAsMTkyKSI+4oCLQlM6 IEkgYWRkZWQgYSByZXF1aXJlbWVudCB0byBzZW5kIENsb3N1cmUgQWxlcnQgYmVmb3JlIHNodXR0 aW5nIGRvd24gdGhlIFRMUyBzZXNzaW9uLiBUaGUgVENQQ0wgbWVzc2FnZXMgYXJlIGFsbCBmaXhl ZC1sZW5ndGggb3Igc2VsZi1pbmRpY2F0ZWQgbGVuZ3RoIHNvIHRoZXJlIGlzIG5vIHBvc3NpYmls aXR5IG9mIGRhdGEgdHJ1bmNhdGlvbi48L3NwYW4+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJQ bGFpblRleHQiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij4tIFNlY3Rpb24g NCwgZmlyc3QgcGFyYWdyYXBoOiBJZiBlbnRpdGllcyBhcmUgZW5jb3VyYWdlZCB0byBrZWVwIHNl c3Npb25zIGFsaXZlIGZvciBhcyBsb25nIGFzIHBvc3NpYmxlLCBndWlkYW5jZSBvbiBob3cgdG8g dXBkYXRlIFRMUyBrZXlpbmcgbWF0ZXJpYWwgKHZpYSBrZXkgdXBkYXRlcyBvciBleHBsaWNpdGx5 IHRlYXJpbmcgZG93biB0aGUgY29ubmVjdGlvbiBhbmQgc3RhcnRpbmcgYW5ldykgc2VlbXMNCiBw cnVkZW50LiBUTFMgaGFzIGEgYm91bmQgb24gaG93IG11Y2ggZGF0YSBjYW4gYmUgZW5jcnlwdGVk IHVuZGVyIG9uZSBrZXkuIDxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij48Zm9u dCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpyZ2IoMTIsMTAwLDE5MikiPkJTOiBJIGFkZGVkIHRleHQgdG8gU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMgc2VjdGlvbiB0byBpbmNsdWRlIGEgcmVmZXJlbmNlIGFib3V0IGtleSB1c2UgbGltaXRz IGFuZCBrZXkgdXBkYXRlcy48YnI+DQo8L3NwYW4+PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYg Y2xhc3M9IlBsYWluVGV4dCI+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJQbGFpblRleHQiPi0g U2VjdGlvbiA0OiBUaGlzIHRleHQ6PGJyPg0KPGJyPg0KJm5ic3A7IE9uY2UgYSBUQ1AgY29ubmVj dGlvbiBpcyBlc3RhYmxpc2hlZCwgZWFjaCBlbnRpdHkgTVVTVCBpbW1lZGlhdGVseTxicj4NCiZu YnNwOyB0cmFuc21pdCBhIGNvbnRhY3QgaGVhZGVyIG92ZXIgdGhlIFRDUCBjb25uZWN0aW9uLjxi cj4NCjxicj4NCnN1Z2dlc3RzIHRoYXQgVExTIGRvZXMgKm5vdCogcHJvY2VlZCBhcyBub3JtYWwg dXBvbiBUQ1AgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50LiBUaGlzIGlzIHF1aXRlIHByb2JsZW1h dGljLCBzaW5jZSBhbnkgYWN0aXZlIGF0dGFja2VyIGNhbiBzaW1wbHkgbXVjayB3aXRoIHRoZSBD b250YWN0SGVhZGVyIENBTl9UTFMgYml0IHRvIGRpc2FibGUgVExTLCByaWdodD8gSXMgdGhpcyB0 aHJlYXQgbm90IGNvbnNpZGVyZWQgaW4gc2NvcGU/IFJlbGF0ZWRseSwNCiB3aGF0IGlzIHRoZSB0 aHJlYXQgbW9kZWw/IChTU0wgc3RyaXBwaW5nIGlzIG1lbnRpb25lZCBpbiBTZWN0aW9uIDgsIGJ1 dCB3aXRob3V0IG1lbnRpb24gb2YgYSB0aHJlYXQgbW9kZWwuKSAmcXVvdDtTZWN1cmUmcXVvdDsg c2Vzc2lvbnMgc3ViamVjdCB0byBhY3RpdmUgZG93bmdyYWRlIGRvIG5vdCBvZmZlciBtdWNoIGlu IHRoZSB3YXkgb2Ygc2VjdXJpdHksIGFuZCB0aGUgZG9jdW1lbnQgc2hvdWxkIGFja25vd2xlZGdl IHRoYXQgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLg0KIENvbmNyZXRlbHksIGhvdyBh Ym91dCB0aGUgZm9sbG93aW5nIHRleHQgdG8gcmVwbGFjZSB0aGUgc2Vjb25kIHBhcmFncmFwaCBp biBTZWN0aW9uIDg/PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7IFRDUENMIGRvZXMgbm90IHByb3Rl Y3QgYWdhaW5zdCBhY3RpdmUgbmV0d29yayBhdHRhY2tlcnMuIEluIHBhcnRpY3VsYXIsIGFuPGJy Pg0KJm5ic3A7Jm5ic3A7IGFjdGl2ZSBtYW4taW4tdGhlLW1pZGRsZSBhdHRhY2tlcnMgdG8gc2V0 IHRoZSBDQU5fVExTIGZsYWcgdG8gMCBvbiBlaXRoZXIgPGJyPg0KJm5ic3A7Jm5ic3A7IHNpZGUg b2YgYSBUQ1BDTCBDb250YWN0SGVhZGVyIGV4Y2hhbmdlLiZuYnNwOyBUaGlzIGxlYWRzIHRvIHRo ZSAmcXVvdDtTU0wgU3RyaXBwaW5nJnF1b3Q7IDxicj4NCiZuYnNwOyZuYnNwOyBhdHRhY2sgZGVz Y3JpYmVkIGluIFtSRkM3NDU3XS4mbmJzcDsgPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7IElmIFRM UyBpcyBkZXNpcmVkIGZvciB1c2Ugb24gYW55IFRDUENMIG5ldHdvcmssIGl0IGlzIHN0cm9uZ2x5 IGVuY291cmFnZWQgdGhhdDxicj4NCiZuYnNwOyZuYnNwOyB0aGUgc2VjdXJpdHkgcG9saWN5IGRp c2FsbG93IHVzZSBvZiBUQ1BDTCB3aGVuICZxdW90O0VuYWJsZSBUTFMmcXVvdDsgaXM8YnI+DQom bmJzcDsmbmJzcDsgbmVnb3RpYXRlZCB0byBmYWxzZS4mbmJzcDsgVGhpcyByZXF1aXJlcyB0aGF0 IHRoZSBUTFMgaGFuZHNoYWtlIG9jY3Vycyw8YnI+DQombmJzcDsmbmJzcDsgcmVnYXJkbGVzcyBv ZiB0aGUgcG9saWN5LWRyaXZlbiBwYXJhbWV0ZXJzIG9mIHRoZSBoYW5kc2hha2UgYW5kPGJyPg0K Jm5ic3A7Jm5ic3A7IHBvbGljeS1kcml2ZW4gaGFuZGxpbmcgb2YgdGhlIGhhbmRzaGFrZSBvdXRj b21lLjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij48Zm9udCBzaXplPSIyIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxmb250IHNpemU9IjIiPjxzcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpyZ2IoMTIsMTAwLDE5MikiPkJTOiBZb3VyIHN0YXRlbWVudHMgYXJlIGRlZmlu aXRlbHkgdHJ1ZS4gVGhlIHB1cnBvc2Ugb2YgdGhlIENBTl9UTFMgZmxhZyBoYXMgYmVlbiBjbGFy aWZpZWQgaW4gU2VjdGlvbiA0LjIgJnF1b3Q7Q29udGFjdCBIZWFkZXImcXVvdDssIGFuZCBTZWN0 aW9uDQogOCBpcyB1cGRhdGVkIHRvIGhhdmUgYSBzdHJvbmdlciByZWNvbW1lbmRhdGlvbiBmb3Ig cG9saWN5IHRvIHJlcXVpcmUgVExTIHVzZSB3aGVuIFRMUyBpcyBhdmFpbGFibGUuPC9zcGFuPjwv c3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+ PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48Zm9udCBzaXplPSIy Ij48c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6cmdiKDEyLDEwMCwxOTIpIj48c3Bhbj5UaGUgcHVy cG9zZSBvZiB0aGUgQ0FOX1RMUyBmbGFnIGlzIHRvIGFsbG93IHRoZSB1c2Ugb2YgVENQQ0wgb248 L3NwYW4+PHNwYW4+IGVudGl0aWVzIHdoaWNoIHNpbXBseSBkbyBub3QgaGF2ZSBhIFRMUyBpbXBs ZW1lbnRhdGlvbg0KIGF2YWlsYWJsZS4gVGhpcyB3YXMgYSBzdGF0ZWQgZ29hbCBvZiB0aGUgRFRO IFdHIGR1ZSB0byB0aGUgZGVzaXJlIHRvIHVzZSBUQ1BDTCBpbiBlbnZpcm9ubWVudHMgd2hlcmUg dGhlIGVudGl0aWVzIGFyZSBjb25zdHJhaW5lZCAoVExTIGlzIHVuYXZhaWxhYmxlKSBidXQgdGhl IG5ldHdvcmsgaXMgdHJ1c3RlZC48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwv Zm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+PGZvbnQgc2l6ZT0iMiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48Zm9udCBzaXplPSIyIj48c3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6cmdiKDEyLDEwMCwxOTIpIj48c3Bhbj5SZWdhcmRpbmcgdGhlIHRocmVhdCBtb2RlbCwg dGhpcyBpcyBzb21ldGhpbmcgSSBuZWVkIHRvIGxvb2sgaW50byBhbmQgZmluZCBzb21lIGV4YW1w bGVzIG9mIGluIG90aGVyIFJGQ3MuPC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9mb250Pjwvc3Bhbj48 L2ZvbnQ+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJQbGFpblRleHQiPjxicj4NCi0gU2VjdGlv biA0LjQuMjogV2h5IGlzIHRoZSByZWNvbW1lbmRhdGlvbiB0aGF0IGVudGl0aWVzICZxdW90O1NI T1VMRCB0ZXJtaW5hdGUgdGhlIHNlc3Npb24mcXVvdDsgaWYgdGhlIHBlZXIncyBjZXJ0aWZpY2F0 ZSBpcyB1bnRydXN0ZWQsIHJhdGhlciB0aGFuICZxdW90O01VU1QgdGVybWluYXRlIHRoZSBzZXNz aW9uJnF1b3Q7PyBJbiB3aGF0IGNpcmN1bXN0YW5jZXMgd291bGQgYW4gZW50aXR5IG5vdCB3YW50 IHRvIHRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbj8gKExhdGVyIHRleHQNCiBtZW50aW9ucyB0aGF0 IHRoaXMgbWF5IGJlIGFsbG93ZWQgYnkgJnF1b3Q7c2VjdXJpdHkgcG9saWN5LCZxdW90OyBpbiB3 aGljaCBjYXNlIHdlIHNob3VsZCBtZW50aW9uIHRoYXQgaGVyZS4pPC9kaXY+DQo8ZGl2IGNsYXNz PSJQbGFpblRleHQiPjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+ PGZvbnQgc2l6ZT0iMiI+PHNwYW4+PGZvbnQgc2l6ZT0iMiI+PHNwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOnJnYigxMiwxMDAsMTkyKSI+QlM6IEkgdXBkYXRlZCB0aGVzZSByZXF1aXJlbWVudHMgdG8g U0hBTEwgYW5kIG1hZGUgc3VyZSB0aGV5IGFyZSBhbGwgY29uZGl0aW9uZWQgb24gcG9saWN5IHJ1 bGVzLjwvc3Bhbj48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48YnI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+PGJyPg0KLSBTZWN0aW9uIDQuNC4yLCBm b3VydGggcGFyYWdyYXBoOiBXaHkgaXMgaG9zdCBuYW1lIHZhbGlkYXRpb24gZG9uZSAqYWZ0ZXIq IFRMUyBjb21wbGV0ZXMsIHJhdGhlciB0aGFuIGR1cmluZyB0aGUgY29ubmVjdGlvbj8gVGhpcyBz ZWVtcyB3cm9uZywgdGhvdWdoIEkgc3VzcGVjdCBJJ20gbWlzdW5kZXJzdGFuZGluZyB0aGUgZGV0 YWlscy48L2Rpdj4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+PGZvbnQgc2l6ZT0iMiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48Zm9udCBzaXplPSIyIj48c3Bhbj48Zm9udCBzaXplPSIy Ij48c3Bhbj48Zm9udCBzaXplPSIyIj48c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6cmdiKDEyLDEw MCwxOTIpIj5CUzogSSB1cGRhdGVkIHRoZSB0ZXh0IHRvIHJlYWQgJnF1b3Q7RWl0aGVyIGR1cmlu ZyBvciBpbW1lZGlhdGVseSBhZnRlciB0aGUgVExTIGhhbmRzaGFrZS4uLiZxdW90OyBUaGUNCiBv bmx5IHJlYXNvbiBmb3IgdGhpcyBpcyBzb21lIFRMUyBpbXBsZW1lbnRhdGlvbnMgYWxsb3cgaW50 ZXJydXB0aW5nIHRoZSBoYW5kc2hha2UgYnV0IHNvbWUgb25seSBhbGxvdyBpbnNwZWN0aW5nIHRo ZSByZXN1bHRzIG9mIHRoZSBoYW5kc2hha2UuPC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwv Zm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSJQbGFpblRleHQiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij4tIDQuNywg RW5hYmxlIFRMUzogSWYgc2VjdXJpdHkgcG9saWN5IGFsbG93cyB0aGUgYWJzZW5jZSBvZiBUTFMs IHdoeSBub3QganVzdCBhbHdheXMgdXNlIFRMUyBhbmQgaGF2ZSB0aGF0IHBvbGljeSB0dW5lIFRM UyBwZWVyIGF1dGhlbnRpY2F0aW9uPyAoU2VlDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNzg1OCNzZWN0aW9uLTQuMSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzc4NTgjc2VjdGlvbi00LjE8L2E+IGZvciBhbiBleGFtcGxlIG9mIHRoaXMuKSBJdCBzZWVt cyBzdHJhbmdlIHRoYXQgb3Bwb3J0dW5pc3RpYyBzZWN1cml0eSBpcyBzdXBwb3J0ZWQgKGFuZCBk ZXNpcmVkIGFzIGEgZmVhdHVyZT8pIHlldCBub3QgYWx3YXlzIHVzZWQuPC9kaXY+DQo8ZGl2IGNs YXNzPSJQbGFpblRleHQiPjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFw dCI+PGZvbnQgc2l6ZT0iMiI+PHNwYW4+PGZvbnQgc2l6ZT0iMiI+PHNwYW4+PGZvbnQgc2l6ZT0i MiI+PHNwYW4+PGZvbnQgc2l6ZT0iMiI+PHNwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigxMiwx MDAsMTkyKSI+QlM6IFBlciB0aGUgZWFybGllciByZXNwb25zZSB0byBTZWN0aW9uIDQgdGV4dCwg dGhlIHJlYXNvbiB0byBhbGxvdyBub24tVExTDQogc2Vzc2lvbnMgaXMgcHVyZWx5IGZvciBjb25z dHJhaW5lZCBlbnRpdGllcy4gVGhlIHRleHQgaW4gU2VjdGlvbiA0LjIgYW5kIFNlY3Rpb24gOCBh cmUgdXBkYXRlZCB0byBjbGFyaWZ5IHRoZSBDQU5fVExTIGZsYWcgdG8gaW5kaWNhdGUgdGhlIHBy ZXNlbmNlIG9mIFRMUyBpbiB0aGUgbmV0d29yayBzdGFjaywgbm90IHJlYWxseSBhIGNvbmZpZ3Vy YXRpb24gcGFyYW1ldGVyLjwvc3Bhbj48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9zcGFu PjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PGJyPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSJQbGFpblRleHQiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij4tIFNl Y3Rpb24gODogSSBzZWUgbm8gcmVhc29uIHdoeSBvbmUgd291bGQgd2FudCB0byB1c2UgVExTIGZv ciBhdXRoZW50aWNhdGlvbiB3aXRob3V0IGFueSBmb3JtIG9mIGNvbmZpZGVudGlhbGl0eS4gSSB3 b3VsZCByZW1vdmUgdGV4dCByZWZlcmVuY2luZyB0aGlzIHVzZSBjYXNlLjxicj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExcHQiPjxmb250IHNpemU9IjIiPjxzcGFuPjxmb250IHNpemU9IjIiPjxzcGFuPjxmb250 IHNpemU9IjIiPjxzcGFuPjxmb250IHNpemU9IjIiPjxzcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpy Z2IoMTIsMTAwLDE5MikiPkJTOiBJIHJlbW92ZWQgdGhpcyB0ZXh0IHRvIGF2b2lkIGNvbmZ1c2lv bi48L3NwYW4+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9zcGFu PjwvZm9udD48L3NwYW4+PC9mb250Pjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0 Ij48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+LSBTZWN0aW9uIDg6IEluIGRl c2NyaWJpbmcgdm9sdW1ldHJpYyBEb1MgYXR0YWNrcywgaXQgbWlnaHQgaGVscCB0byBjb25zaWRl ciB0aGUgJnF1b3Q7b3Bwb3NpdGUmcXVvdDsgc29ydCBvZiBhdHRhY2ssIGUuZy4sIHNpbWlsYXIg dG8gd2hhdCB0aGUgSFRUUFQvMiBkYXRhIGRyaWJibGUgYXR0YWNrIGV4cGxvaXRlZD8gKDxhIGhy ZWY9Imh0dHBzOi8vY3ZlLm1pdHJlLm9yZy9jZ2ktYmluL2N2ZW5hbWUuY2dpP25hbWU9Q1ZFLTIw MTktOTUxMSI+aHR0cHM6Ly9jdmUubWl0cmUub3JnL2NnaS1iaW4vY3ZlbmFtZS5jZ2k/bmFtZT1D VkUtMjAxOS05NTExPC9hPik8L2Rpdj4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+PGZvbnQgc2l6 ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48Zm9udCBzaXplPSIyIj48c3Bhbj48 Zm9udCBzaXplPSIyIj48c3Bhbj48Zm9udCBzaXplPSIyIj48c3Bhbj48Zm9udCBzaXplPSIyIj48 c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6cmdiKDEyLDEwMCwxOTIpIj5CUzogVGhpcyBpcyBhIGdv b2QgY2F0Y2gsIEkgYWRkZWQgU2VjdGlvbiA4IHRleHQgdG8gd2FybiBhZ2FpbnN0IGFjY2VwdGlu Zw0KIHRvby1zbWFsbCBTZWdtZW50IE1SVSBvciBUcmFuc2ZlciBNUlUgcGFyYW1ldGVycy48L3Nw YW4+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9u dD48L3NwYW4+PC9mb250Pjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij48YnI+ DQpOaXRzOjxicj4NCi0gU2VjdGlvbiAyLjEsIFRDUCBDb25uZWN0aW9uOiB0eXBvIGluICZxdW90 O2FuZCBvdGhlciBzdGF0ZXMgYXNzb2NpYXRpb24mcXVvdDsgKHNob3VsZCBiZSBhc3NvY2lhdGVk Pyk8L2Rpdj4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMXB0Ij48Zm9udCBzaXplPSIyIj48c3Bhbj48Zm9udCBzaXplPSIyIj48 c3Bhbj48Zm9udCBzaXplPSIyIj48c3Bhbj48Zm9udCBzaXplPSIyIj48c3Bhbj48Zm9udCBzaXpl PSIyIj48c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6cmdiKDEyLDEwMCwxOTIpIj5CUzogRml4ZWQg dGhpcyB0eXBvLjwvc3Bhbj48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9u dD48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48YnI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+LSBTZWN0aW9uIDIuMSwgVHJhbnNtaXNzaW9uIEludGVy bWVkaWF0ZSBQcm9ncmVzczogdHlwbyAmcXVvdDt0cmFuc2ZlcnImcXVvdDsgKGFuZCBlbHNld2hl cmUpPGJyPg0KPGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij4NCjxk aXY+PGZvbnQgc2l6ZT0iMiI+PHNwYW4+PGZvbnQgc2l6ZT0iMiI+PHNwYW4+PGZvbnQgc2l6ZT0i MiI+PHNwYW4+PGZvbnQgc2l6ZT0iMiI+PHNwYW4+PGZvbnQgc2l6ZT0iMiI+PHNwYW4+PGZvbnQg c2l6ZT0iMiI+PHNwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigxMiwxMDAsMTkyKSI+QlM6IEZp eGVkIHRoaXMgdHlwby48L3NwYW4+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj48 L2ZvbnQ+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PGJyPg0KPC9k aXY+DQo8L3NwYW4+PC9mb250Pi0gSW5jb25zaXN0ZW50IG5vdGF0aW9uIG9mIFNFU1NfVEVSTSAo aXQncyByZWZlcnJlZCB0byBhcyBTRVNTVEVSTSBpbiBsb3RzIG9mIHBsYWNlcyk8YnI+DQo8Zm9u dCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPg0KPGRpdj48Zm9udCBzaXpl PSIyIj48c3Bhbj48Zm9udCBzaXplPSIyIj48c3Bhbj48Zm9udCBzaXplPSIyIj48c3Bhbj48Zm9u dCBzaXplPSIyIj48c3Bhbj48Zm9udCBzaXplPSIyIj48c3Bhbj48Zm9udCBzaXplPSIyIj48c3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6cmdiKDEyLDEwMCwxOTIpIj5CUzogVGhlICZxdW90O1NFU1Nf VEVSTSZxdW90OyB3YXMgYSBtZXNzYWdlIHdoaWxlIGEgJnF1b3Q7U0VTU1RFUk0mcXVvdDsgd2Fz IGFuIGFjdGl2aXR5LiBJIHJlbmFtZWQgdGhlIGFjdGl2aXR5DQogdG8gJnF1b3Q7U1QmcXVvdDsg dG8gYmUgY29uc2lzdGVudCB3aXRoIG90aGVyIGFiYnJldmlhdGVkIGFjdGl2aXR5IG5hbWVzLjwv c3Bhbj48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9m b250Pjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48YnI+DQo8L2Rpdj4NCjxkaXY+PC9kaXY+ DQo8L3NwYW4+PC9mb250Pi0gU2VjdGlvbiAzLjQsIGxhc3QgcGFyYWdyYXBoOiB0eXBvICZxdW90 O2Zyb20gZnJvbSZxdW90Ozxicj4NCjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTFwdCI+DQo8ZGl2Pjxmb250IHNpemU9IjIiPjxzcGFuPjxmb250IHNpemU9IjIiPjxzcGFu Pjxmb250IHNpemU9IjIiPjxzcGFuPjxmb250IHNpemU9IjIiPjxzcGFuPjxmb250IHNpemU9IjIi PjxzcGFuPjxmb250IHNpemU9IjIiPjxzcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMTIsMTAw LDE5MikiPkJTOiBGaXhlZCB0aGlzIHR5cG8uPC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwv Zm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9m b250Pjxicj4NCjwvZGl2Pg0KPC9zcGFuPjwvZm9udD4tIFNlY3Rpb246IHR5cG8gJnF1b3Q7bmVn b3RhdGluZyZxdW90OzwvZGl2Pg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij48Zm9udCBzaXplPSIy Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPg0KPGRpdj48Zm9udCBzaXplPSIyIj48c3Bh bj48Zm9udCBzaXplPSIyIj48c3Bhbj48Zm9udCBzaXplPSIyIj48c3Bhbj48Zm9udCBzaXplPSIy Ij48c3Bhbj48Zm9udCBzaXplPSIyIj48c3Bhbj48Zm9udCBzaXplPSIyIj48c3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6cmdiKDEyLDEwMCwxOTIpIj5CUzogRml4ZWQgc2V2ZXJhbCBvZiB0aGlzIHR5 cG8uPC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bh bj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjxicj4NCjwvZGl2Pg0KPGRpdj48 L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+PGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_MN2PR13MB3520EBCB4F7786ABFDED76EE9F7B0MN2PR13MB3520namp_-- From nobody Thu Nov 14 02:28:32 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0981B12022D for ; Thu, 14 Nov 2019 02:28:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <157372731103.11521.7331579785417140408.idtracker@ietfa.amsl.com> Date: Thu, 14 Nov 2019 02:28:31 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 10:28:31 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-12-05 Reviewer LC end Draft Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-04 Sean Turner 2019-11-07 draft-ietf-ospf-ospfv2-hbit-10 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Last calls: Reviewer LC end Draft John Bradley 2019-11-22 draft-schaad-cbor-content-01 Shaun Cooley 2019-11-12 draft-ietf-regext-login-security-05 Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-17 Alan DeKok 2019-11-27 draft-ietf-6man-ra-pref64-07 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Linda Dunbar 2019-12-02 draft-ietf-opsec-v6-21 Daniel Gillmor 2018-03-19 draft-gutmann-scep-14 Dan Harkins R2019-10-03 draft-ietf-dtn-bpsec-13 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-18 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Stefan Santesson 2019-10-10 draft-ietf-payload-rtp-ttml-05 Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-04 Sean Turner 2019-11-25 draft-ietf-nfsv4-rfc5661sesqui-msns-03 Sean Turner 2019-11-07 draft-ietf-ospf-ospfv2-hbit-10 David Waltermire R2019-11-14 draft-ietf-hip-dex-11 David Waltermire 2019-08-07 draft-ietf-oauth-jwt-introspection-response-08 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Tim Polk 2019-10-04 draft-ietf-lwig-curve-representations-08 Next in the reviewer rotation: Donald Eastlake Shawn Emery Stephen Farrell Daniel Franke Daniel Gillmor Tobias Gondrom Ólafur Guðmundsson Phillip Hallam-Baker Steve Hanna Dan Harkins From nobody Thu Nov 14 08:13:24 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 563CB120865; Wed, 13 Nov 2019 23:16:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1573715773; bh=NUS+9c8Chg6sJmObZOhZRWrxveNq9OJmTUs9VS0jui8=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=rXWAV52y20w9gBkadRVdaVt3CUMhJxxgWD7V2+p+RKlUwL3sgM8lFIEHKVFleN6nd bO/yScjXpWYfr8nQCwTDSZiqAOI/eHPtU+/RqvMeNX/uJyxVB+RzpJZs52RlUPk9pH UuAbU0wukXuOf+o3eOkniUVo2W1Wh0RKqWRXH7kU= X-Mailbox-Line: From new-work-bounces@ietf.org Wed Nov 13 23:16:13 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D86291200E7; Wed, 13 Nov 2019 23:16:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1573715772; bh=NUS+9c8Chg6sJmObZOhZRWrxveNq9OJmTUs9VS0jui8=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=NNlxrEp5zmYn4xEWGn4O6UEIvK8B26+OvzfIf4tkJDcAXY07WsS0JpAJhR2tWNxQW D+xnGVGQkfJunroXRbgVhBdmX8gXc4OMJEaIGtDUpfC5GRYevMO2PgmA5bD7k/y1IX SLOiPgoiPsspdpx/5jTRHV8Qxavo3c5urMnOnYDI= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5E71200E7 for ; Wed, 13 Nov 2019 23:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsIG35E2UiFW for ; Wed, 13 Nov 2019 23:16:09 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EC2B1200C7 for ; Wed, 13 Nov 2019 23:16:09 -0800 (PST) Received: from [42.100.7.236] (helo=[192.168.1.5]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1iV9MN-0007QG-67 for new-work@ietf.org; Thu, 14 Nov 2019 07:16:07 +0000 To: new-work@ietf.org From: xueyuan Message-ID: <5b5535a2-7d64-d0e5-6f44-3f56760198ad@w3.org> Date: Thu, 14 Nov 2019 15:16:04 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 14 Nov 2019 08:13:21 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Web Payments Working Group (until 2019-12-13) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 07:16:14 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgV2ViIFBh eW1lbnRzIFdvcmtpbmcgR3JvdXA6CiDCoCBodHRwczovL3d3dy53My5vcmcvUGF5bWVudHMvV0cv Y2hhcnRlci0yMDE5MTAuaHRtbAoKQXMgcGFydCBvZiBlbnN1cmluZyB0aGF0IHRoZSBjb21tdW5p dHkgaXMgYXdhcmUgb2YgcHJvcG9zZWQgd29yawphdCBXM0MsIHRoaXMgZHJhZnQgY2hhcnRlciBp cyBwdWJsaWMgZHVyaW5nIHRoZSBBZHZpc29yeQpDb21taXR0ZWUgcmV2aWV3IHBlcmlvZC4KClcz QyBpbnZpdGVzIHB1YmxpYyBjb21tZW50cyB0aHJvdWdoIDIwMTktMTItMTMgb24gdGhlCnByb3Bv c2VkIGNoYXJ0ZXIuIFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvCnB1YmxpYy1uZXctd29ya0B3My5v cmcsIHdoaWNoIGhhcyBhIHB1YmxpYyBhcmNoaXZlOgogwqAgaHR0cDovL2xpc3RzLnczLm9yZy9B cmNoaXZlcy9QdWJsaWMvcHVibGljLW5ldy13b3JrLwoKT3RoZXIgdGhhbiBjb21tZW50cyBzZW50 IGluIGZvcm1hbCByZXNwb25zZXMgYnkgVzNDIEFkdmlzb3J5CkNvbW1pdHRlZSBSZXByZXNlbnRh dGl2ZXMsIFczQyBjYW5ub3QgZ3VhcmFudGVlIGEgcmVzcG9uc2UgdG8KY29tbWVudHMuIElmIHlv dSB3b3JrIGZvciBhIFczQyBNZW1iZXIgWzFdLCBwbGVhc2UgY29vcmRpbmF0ZQp5b3VyIGNvbW1l bnRzIHdpdGggeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUuIEZvcgpleGFt cGxlLCB5b3UgbWF5IHdpc2ggdG8gbWFrZSBwdWJsaWMgY29tbWVudHMgdmlhIHRoaXMgbGlzdCBh bmQKaGF2ZSB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZSByZWZlciB0byBp dCBmcm9tIGhpcwpvciBoZXIgZm9ybWFsIHJldmlldyBjb21tZW50cy4KCklmIHlvdSBzaG91bGQg aGF2ZSBhbnkgcXVlc3Rpb25zIG9yIG5lZWQgZnVydGhlciBpbmZvcm1hdGlvbiwgcGxlYXNlCmNv bnRhY3QgSWFuIEphY29icywgPGlqQHczLm9yZz4sIFczQyBXZWIgUGF5bWVudHMgV29ya2luZyBH cm91cApUZWFtIENvbnRhY3QgLgoKVGhhbmsgeW91LAoKWHVleXVhbiBKaWEsIFczQyBNYXJrZXRp bmcgJiBDb21tdW5pY2F0aW9ucwoKWzFdIGh0dHA6Ly93d3cudzMub3JnL0NvbnNvcnRpdW0vTWVt YmVyL0xpc3QKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cm5ldy13b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Sun Nov 17 00:42:33 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECC21200C4 for ; Sun, 17 Nov 2019 00:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnQez0E0JZow for ; Sun, 17 Nov 2019 00:42:23 -0800 (PST) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 290ED1200E0 for ; Sun, 17 Nov 2019 00:42:23 -0800 (PST) Received: by mail-ua1-x92b.google.com with SMTP id r13so4290671uan.6 for ; Sun, 17 Nov 2019 00:42:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dUN5K/uWPEaYwQ0C2Gv22N7PUts4dL6dLISFDz4bp6I=; b=dPWOF9qDo4cEg8McBidZKVAAP2P1l2btfuItYgdgGmwK/zfZHzlTzIH/LqL8BvwCBB O5XxO1f/iX7yth2udycVCf9X+etmW0KwRf9CH0LGm5H0aBda5TDdfJBLneRidF5Ks/Tw OairEOc+y+JYoROQivn9/mN0lxgTPjSml31qA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dUN5K/uWPEaYwQ0C2Gv22N7PUts4dL6dLISFDz4bp6I=; b=R4vGKmtUt7SmqOU9TjyAjcfTWqJfGAJLRsOWZx5hGhwpFAECOFoxMaURZ18xJhGcq+ nqr9FJ1VZDASvRfylImhPILLfVh5dEixYQGa+FS0ArL3VFclkqaWjVWR+/cZUtXXYM2Z Y3ZjJsUbOfqEmLJBik8zhjU7SiYneKEzGEstLfBEfjERJe3JtBTXfBYU77xuHOHuGV54 VbnzX5dqtI15qJb5LMcJc6ysR6XIKNZgmd6QHV4COHimUp8d2AW9gxIH1U1YrwLIVdnA Y+T7ROyVvsOpFYECXwWq3piqMUPtFqrhSpKvF68PEerOtM2jDsr2f2yDLeD2MCriu9kr iExQ== X-Gm-Message-State: APjAAAVpUuU2G7/skIO4lKwNUtxvwc/gqboWuwC82FASgwZCIbbVeckA S7dndCFjWZOu+jkHjnnNoD6xCO46Lbvq79jfZJYOzQ== X-Google-Smtp-Source: APXvYqwAtVGIzxxRFGHgqsJBKbwabVRWMe2v1BQxqRc2wtyU/4svgIdeM9r1iRvAKYTk+BOAmZyqRnNk64KaBXbhtZk= X-Received: by 2002:ab0:1431:: with SMTP id b46mr4933191uae.52.1573980141776; Sun, 17 Nov 2019 00:42:21 -0800 (PST) MIME-Version: 1.0 References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> In-Reply-To: From: Nick Sullivan Date: Sun, 17 Nov 2019 16:42:05 +0800 Message-ID: To: Yaron Sheffer Cc: secdir@ietf.org, draft-ietf-tls-exported-authenticator.all@ietf.org, ietf@ietf.org, "" Content-Type: multipart/alternative; boundary="0000000000003c30ec059786cf1e" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-tls-exported-authenticator-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2019 08:42:27 -0000 --0000000000003c30ec059786cf1e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yaron, Thanks for reminding me about the codepoint issue. It's a sticky one. As far as I see it, there are three options: a) Change the document to UPDATE RFC 8446 This feels like a heavyweight option and may complicate things since it will mean that SNI is allowed but undefined for CertificateVerify in the TLS handshake. b) Ask for a new extension point for SNI sent in a client-generated authenticator request. This has the downside of not scaling to future client hello extensions that could be useful in exported authenticator requests -- it forces the definition of a new code point for each new extension. c) Explicitly state that the CertificateRequest-like construction in client-generated exported authenticator requests is a new type of message (analogous to a ClientHello) and clarify the rules about which extensions can be used when it is client-generated (specifically, say that any extension supported in CH is allowed) This is my preferred solution. I'm interested to hear what the working group thinks, and I'll happily present the options at IETF 106 if there's time. Best, Nick On Mon, Nov 4, 2019 at 6:20 PM Yaron Sheffer wrote: > Hi Nick, > > > > Apologies for not responding on time. > > > > I may be missing some follow-on discussions, but: > > > > - Ben suggested that we mention that QUIC is also an option, even if > informatively, in addition to the =E2=80=9CSHOULD use TLS=E2=80=9D sta= tement. > - I think we left my question re: back-fitting this protocol into the > IANA TLS registry open. Quoting: > > > > YS: 7.1: this is changing TLS 1.3 by allowing this extension in Cert > Request! I think it's a really bad idea. Better to hack special support t= o > existing libraries, allowing this specific extension for this special cas= e, > than to change the base protocol. Otherwise, this document should UPDATE > 8446. > > > > NS: This is a good point and one that we struggled a bit with during > design. We needed to allow SNI in the CertificateRequest message because = it > can be client-generated in this context. I'd be ok with creating a > different extension for this, but it's rather elegant to re-use it in thi= s > context. *I'd like to hear some opinions from the working group* on this > point > > > > BK: Or, since extension codepoints are cheap, just use a new codepoint. > > > > Thanks, > > Yaron > > > > *From: *Nick Sullivan > *Date: *Monday, November 4, 2019 at 04:49 > *To: *Yaron Sheffer > *Cc: *, < > draft-ietf-tls-exported-authenticator.all@ietf.org>, , "< > tls@ietf.org>" > *Subject: *Re: Secdir last call review of > draft-ietf-tls-exported-authenticator-09 > > > > Following up, > > > > Yaron, do the responses by myself and Benjamin along with the does the > following PR sufficiently address your comments/concerns? > > > > https://github.com/tlswg/tls-exported-authenticator/pull/52 > > > > On Wed, Sep 18, 2019 at 4:55 PM Nick Sullivan wrote= : > > Hi Yaron, > > > > Thank you for your thorough review. My answers will be inline, and I'll > incorporate some of Ben's replies if necessary. Here's a PR with proposed > changes in response to your comments: > > https://github.com/tlswg/tls-exported-authenticator/pull/52 > > > > On Tue, Jul 16, 2019 at 12:59 PM Yaron Sheffer via Datatracker < > noreply@ietf.org> wrote: > > Reviewer: Yaron Sheffer > Review result: Has Issues > > The document is generally clear in both its motivation and the proposed > solution. > > I think it's playing a bit too liberal with TLS 1.3, in sort-of but not > quite > deprecating renegotiation, and in changing the IANA registry in a way tha= t > actually changes the protocol. Details below. > > Other comments: > > * Abstract: please reword to make it clear that it's the proof (not the > cert) > that is portable. > > > > Proposed text here: > > This document describes a mechanism in Transport Layer Security (TLS) for > peers to > provide a proof of ownership of a certificate. This proof can be exporte= d > by one peer, transmitted out-of-band to the other peer, and verified by > the receiving peer. > > > > * Introduction: TLS 1.3 post-handshake auth "has the > disadvantage of requiring additional state to be stored as part of the TL= S > state machine." Why is that an issue is practice, assuming this feature i= s > already supported by TLS libraries? Also, are we in effect deprecating > this TLS > 1.3 feature because of the security issue of the mismatched record > boundaries? > > > > My understanding is that post-handshake authentication as defined in the > TLS 1.3 RFC is not implemented in many (any?) TLS 1.3 libraries and some > implementors would prefer to use exported authenticators. > > > > * "For simplicity, the mechanisms... require", maybe a normative REQUIRE? > > I'm fine with this. > > > > * Authenticator Request: please clarify that we use the TLS 1.3 format > even when > running on TLS 1.2. > > Updated, though it might be a bit unnecessary. > > > > * Also, I suggest to change "is not encrypted with a > handshake key" which is too specific to "is sent unencrypted within the > normal > TLS-protected data". > > This specific text is meant to differentiate the wire format of this > message from that of the CertificateRequest message, which is encrypted > with the handshake key. The specificity is warranted. > > > > * Before diving into the detailed messages in Sec. 3, it > would be nice to include a quick overview of the message sequence. > > There are two message types and three potential sequences. I've added a > short overview. > > > > * Sec. 3: > "SHOULD use TLS", change to MUST. There's no way it can work otherwise > anyway. > > As Ben noted, this could be any secure channel with equivalent security t= o > TLS, such as QUIC. We shouldn't forbid other secure out-of-band mechanism= s. > > > > * "This message reuses the structure to the CertificateRequest message" - > repeats the preceding paragraph. > > Fixed > > > > * Sec. 4: again, SHOULD use TLS -> MUST. > > Again, I don't see the need for a MUST here. > > > > * Is > there a requirement for all protocol messages to be sent over a single TL= S > connection? If so, please mention it. Certainly this is true for the > Authenticator message that must be sent over a single connection and > cannot be > multiplexed by the high-level protocol. I think this protocol actually > assumes > "nice" transport properties (no message reorder, reliability) that also > require > a single, clean TLS connection. > > There is no such requirement. Message ordering is managed by the > application layer protocol that utilizes exported authenticators. > > > > * Why no authenticator request for servers? > Don't we care about replay? OTOH if the client wants to detect replays, i= t > would need to keep state on received authenticators, which would be very > messy. > > I'm not sure I understand. It's possible to use authenticator requests fo= r > servers. > > > > * 4.1: when referencing Exporters, mention this is Sec. 7.5 of [TLS1.3]. > > Added "Sec. 7.5" > > > > * The > discussion of Extended Master Secret only applies to TLS 1.2 - please > clarify > that, plus I suggest to reword this paragraph which I find hard to parse. > > re-worded > > > > * > 4.2: "the extensions are chosen from the TLS handshake." - What does it > mean > exactly, and how does an application even know which extensions were used > at > the TLS layer? Reading further, we mention "ClientHello extensions." Mayb= e > the > authenticator should also include a ClientHello message to indicate > supported > extensions. Assuming we can peek into ClientHello contradicts the hopeful > "even > if it is possible to implement it at the application layer" in Sec. 6. > > > > This could be clearer. Effectively, the Certificate message in the > Authenticator needs > > to be constructed in a similar manner to how a Certificate message would > be created > > in a TLS handshake. Namely, it can only contain extensions that were > present in either > > the client hello or a preceding CertificateRequest. > > > > You're right that this makes an assumption that the party creating the > Authenticator > > has access to the TLS handshake state. This implies that even if the > Authenticator > > is created in the application space, an additional API needs to be expose= d > to share > > that information. > > > > * 4.2.1: > the first sentence of the section is incomplete. > > > > Fixed > > > > * Can I use TLS 1.3-specific > extensions (oid_filters) if I'm running on a TLS 1.2 connection? Is there= a > situation where a certificate is acceptable for TLS 1.3 connections but > not for > TLS 1.2 connections? > > Yes TLS 1.3-specific extensions are allowed, the CertificateRequest > message is TLS 1.3-compatible. > > > > * "using a value derived from the connection secrets" - I > think we should recommend a specific construction here to ensure people d= o > it > securely. > > This was a suggestion from the Additional Certificates use case ( > https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-0= 5). > I'm not sure we should get into the details here. > > > > * 4.2.3: Are we computing HMAC(MAC-key, Hash(a || b || c || d))? If > so, please say so. > > Yes, I'll put that in. > > > > * 4.2.4: "a constant-time comparison" - why is it actually > required, what is the threat? An attacker can do very little because each > authenticator being sent is different. > > As Ben noted, this was a safety note added during review. > > > > * 5: please say explicitly which > messages are used in this case to construct the authenticator. > > > > Re-written. > > * 6.1: the > "MUST" is strange in a section that's only supposed to be informative. > Also, > the library may provide this extension (and possibly others) without > requiring > it as input. > > How else do you propose wording the requirement that this API fail if the > connection doesn't support EAs? > > > > * 6.4: "The API MUST return a failure if the > certificate_request_context of the authenticator was used in a previously > validated authenticator." Are we requiring the library to keep previous > contexts for replay protection? If so, please make it explicit. > > I think this can be a SHOULD based on the burden replay protection places > on the implementation. > > > > * 7.1: this is > changing TLS 1.3 by allowing this extension in Cert Request! I think it's= a > really bad idea. Better to hack special support to existing libraries, > allowing > this specific extension for this special case, than to change the base > protocol. Otherwise, this document should UPDATE 8446. > > > > This is a good point and one that we struggled a bit with during design. > We needed to allow SNI in the CertificateRequest message because it can b= e > client-generated in this context. I'd be ok with creating a different > extension for this, but it's rather elegant to re-use it in this context.= *I'd > like to hear some opinions from the working group* on this point > > > > * 8: I think the > Security Considerations is the right place to talk about interaction > between > this protocol and TLS 1.3 (or 1.2) renegotiation. Even if we simply > RECOMMEND > not to do it. Or else explain the use cases where renegotiation is still > useful > if there are any. > > > > I'm not sure this document should be prescriptive about use cases. This > doc is providing a new capability that may be leveraged at the applicatio= n > to replace the functionality of existing mechanisms, but I'm not convince= d > the evaluation of the trade-offs of different mechanisms should be > contained in this document. > > --0000000000003c30ec059786cf1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yaron,

Thanks for remindi= ng me about the codepoint issue. It's a sticky one.

As far as I see it, there are three options:

a) Change the document to UPDATE RFC 8446
This feels like a heav= yweight option and may complicate things since it will mean that SNI is all= owed but undefined for CertificateVerify in the TLS handshake.
b) Ask for a new extension point for SNI sent in a client-gene= rated authenticator request.
This has the downside of not scaling= to future client hello extensions that could be useful in exported authent= icator requests -- it forces the definition of a new code point for each ne= w extension.

c) Explicitly state that the Certific= ateRequest-like construction in client-generated exported authenticator req= uests is a new type of message (analogous to a ClientHello) and clarify the= rules about which extensions can be used when it is client-generated (spec= ifically, say that any extension supported in CH is allowed)
= This is my preferred solution.

I'm interested = to hear what the working group=C2=A0thinks, and I'll happily present th= e options=C2=A0at IETF 106 if there's time.

Be= st,
Nick

On Mon, Nov 4, 2019 at 6:20 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
<= /div>
=

Hi Nick,

=C2=A0

Apologies for not responding on time.

=C2=A0

= I may be missing some follow-on discussions, but:

=C2=A0

  • Ben suggested that we mention that QUIC is also an option,= even if informatively, in addition to the =E2=80=9CSHOULD use TLS=E2=80=9D= statement.
  • I think we left my question re: bac= k-fitting this protocol into the IANA TLS registry open. Quoting:

=C2=A0

YS: 7.1: this is changing TLS 1.3 by allowing this extension in C= ert Request! I think it's a really bad idea. Better to hack special sup= port to existing libraries, allowing this specific extension for this speci= al case, than to change the base protocol. Otherwise, this document should = UPDATE 8446.

=C2=A0

NS: This is a good point and one that we struggled= a bit with during design. We needed to allow SNI in the CertificateRequest= message because it can be client-generated in this context. I'd be ok = with creating a different extension for this, but it's rather elegant t= o re-use it in this context. *I'd like to hear some opinions from the w= orking group* on this point

= =C2=A0

BK: Or, since extension codepoints = are cheap, just use a new codepoint.

=C2=A0

Thanks,

<= p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron

=C2=A0

Following up= ,

<= u>=C2=A0

On Wed, Sep 18, 201= 9 at 4:55 PM Nick Sullivan <nick@cloudflare.com> wrote:

Hi=C2=A0Yaron,=

=C2=A0

Thank you for your thorough review. My answers will be inlin= e, and I'll incorporate=C2=A0some of Ben's replies if necessary. He= re's a PR with proposed changes in response to your comments:=

<= p class=3D"MsoNormal">=C2=A0

On Tue, Jul 16, 2019 at 12:59 PM Yaron Sheffer via Datatracker &l= t;noreply@ietf.org> wrote:

Reviewer: Yaron Sheffer
Review result: Has Issues

The docu= ment is generally clear in both its motivation and the proposed
solution= .

I think it's playing a bit too liberal with TLS 1.3, in sort-o= f but not quite
deprecating renegotiation, and in changing the IANA regi= stry in a way that
actually changes the protocol. Details below.

= Other comments:

* Abstract: please reword to make it clear that it&#= 39;s the proof (not the cert)
that is portable.

<= div>

=C2=A0

* Introduction: TLS 1.3 post-handshake auth &q= uot;has the
disadvantage of requiring additional state to be stored as p= art of the TLS
state machine." Why is that an issue is practice, as= suming this feature is
already supported by TLS libraries? Also, are we = in effect deprecating this TLS
1.3 feature because of the security issue= of the mismatched record boundaries?

<= blockquote style=3D"border-top:none;border-right:none;border-bottom:none;bo= rder-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.= 8pt;margin-right:0in">

* "For simplicity, the me= chanisms... require", maybe a normative REQUIRE?

I'm fine with this.<= /p>

=C2=A0

* Authenticator Request: please clari= fy that we use the TLS 1.3 format even when
running on TLS 1.2.

* Also, I suggest to change "is not encrypted with a
handshake= key" which is too specific to "is sent unencrypted within the no= rmal
TLS-protected data".

* Before diving into the detailed me= ssages in Sec. 3, it
would be nice to include a quick overview of the me= ssage sequence.

T= here are two message types and three potential sequences. I've added a = short overview.

=C2=A0

* Sec. = 3:
"SHOULD use TLS", change to MUST. There's no way it can= work otherwise anyway.

As Ben noted, this could be any secure channel with equivalent secur= ity to TLS, such as QUIC. We shouldn't forbid other secure out-of-band = mechanisms.

=C2=A0

* "Thi= s message reuses the structure to the CertificateRequest message" -repeats the preceding paragraph.

Fixed

= =C2=A0

* Sec. 4: again, SHOULD use TLS -> MUST.

=

Again, I don't see the need for a MUST here= .

=C2=A0

* Is
there a requi= rement for all protocol messages to be sent over a single TLS
connection= ? If so, please mention it. Certainly this is true for the
Authenticator= message that must be sent over a single connection and cannot be
multip= lexed by the high-level protocol. I think this protocol actually assumes"nice" transport properties (no message reorder, reliability) th= at also require
a single, clean TLS connection.

There is no such requirement. Message ord= ering is managed by the application layer protocol that utilizes exported a= uthenticators.

=C2=A0=

* Why no= authenticator request for servers?
Don't we care about replay? OTOH= if the client wants to detect replays, it
would need to keep state on r= eceived authenticators, which would be very messy.

I'm not sure I understand. It's p= ossible to use authenticator requests for servers.

<= div>

=C2=A0

* 4.1: when referencing Exporters, mention thi= s is Sec. 7.5 of [TLS1.3].

* The
discussion of Extended Master Secret only appl= ies to TLS 1.2 - please clarify
that, plus I suggest to reword this para= graph which I find hard to parse.

*
4.2: "the extensions are chosen from the TLS handshake."= - What does it mean
exactly, and how does an application even know whic= h extensions were used at
the TLS layer? Reading further, we mention &qu= ot;ClientHello extensions." Maybe the
authenticator should also inc= lude a ClientHello message to indicate supported
extensions. Assuming we= can peek into ClientHello contradicts the hopeful "even
if it is p= ossible to implement it at the application layer" in Sec. 6.=

* 4.2.1:
the first sentence of the= section is incomplete.

=C2=A0

Fixed

=C2=A0

* Can I use TLS 1.3-specifi= c
extensions (oid_filters) if I'm running on a TLS 1.2 connection? I= s there a
situation where a certificate is acceptable for TLS 1.3 connec= tions but not for
TLS 1.2 connections?

Yes TLS 1.3-specific extensions are allowed, the C= ertificateRequest message is TLS 1.3-compatible.

=C2=A0

* "using a value derived from the connection= secrets" - I
think we should recommend a specific construction her= e to ensure people do it
securely.

=C2=A0

* 4.2.3: Are we computing HMAC(MAC-key, Hash(a || b || c || d))? If
s= o, please say so.

Yes, I'll put that in.

=C2=A0

* 4.2.4: "a constant-time comparison" - why is it actuallyrequired, what is the threat? An attacker can do very little because each=
authenticator being sent is different.

As Ben noted, this was a safety note added during= review.

=C2=A0

* 5: please sa= y explicitly which
messages are used in this case to construct the authe= nticator.

= =C2=A0

Re-written.=C2=A0=

* 6.1: the"MUST" is strange in a section that's only supposed to be i= nformative. Also,
the library may provide this extension (and possibly o= thers) without requiring
it as input.

How else do you propose wording the requirement tha= t this API fail if the connection doesn't support EAs?

=C2=A0

* 6.4: "The API MUST return a fail= ure if the
certificate_request_context of the authenticator was used in = a previously
validated authenticator." Are we requiring the library= to keep previous
contexts for replay protection? If so, please make it = explicit.

I think= this can be a SHOULD based on the burden replay protection places on the i= mplementation.=C2=A0

=C2= =A0

*= =C2=A0 7.1: this is
changing TLS 1.3 by allowing this extension in Cert = Request! I think it's a
really bad idea. Better to hack special supp= ort to existing libraries, allowing
this specific extension for this spe= cial case, than to change the base
protocol. Otherwise, this document sh= ould UPDATE 8446.

=C2=A0

This is a good p= oint and one that we struggled a bit with during design. We needed to allow= SNI in the CertificateRequest message because it can be client-generated i= n this context. I'd be ok with creating a different extension for this,= but it's rather elegant to re-use it in this context. I'd like = to hear some opinions from the working group on this point

=C2=A0

* 8: I think the
Security Consid= erations is the right place to talk about interaction between
this proto= col and TLS 1.3 (or 1.2) renegotiation. Even if we simply RECOMMEND
not = to do it. Or else explain the use cases where renegotiation is still useful=
if there are any.

=C2=A0

I'm not = sure this document should be prescriptive about use cases. This doc is prov= iding a new capability that may be leveraged at the application to replace = the functionality of existing mechanisms, but I'm not convinced the eva= luation of the trade-offs of different mechanisms should be contained in th= is document.

--0000000000003c30ec059786cf1e-- From nobody Mon Nov 18 14:50:55 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADCB120B01; Mon, 18 Nov 2019 14:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9ANw21o1tlm; Mon, 18 Nov 2019 14:50:43 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E970412009E; Mon, 18 Nov 2019 14:50:42 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAIMhIcO026647; Mon, 18 Nov 2019 22:50:39 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=+DKP9u1Do2DL4zIlUlpOPjG6xNmMx0iT9o+vtIRubxg=; b=GSScqzdCu2w6ue7BIqTPF+A7T3KJXBzMZfThu8MWVKlzKjXLPfHaTNFkQLtFpj+TrLQm VgfkKHxHCtUiIaWFeZDRgEoxCOpZVAFtKk+GgNBIZlr8cmx0NGzRpGgt3Pj68P0AgZqq DLaWplxpSoGXEDBXxtOALJdDvGTyjgq1L+Xmi/4taTEjiTXZv1hlIQEMX1/bpsYGIBEE xdOm+wvyt3bp7Lihc2brwwrF7TUmW6nPJjJzGHaeio4HZwtpSpM8uZHSRdgouas4PfCu q+DAvjieeZpqnK4mVT3Q2KW42u+pwdCr2cp2v+0y+PVMBEEtoR3Th0/mPzQssBotbD2z CQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2wag31j29e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Nov 2019 22:50:38 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAIMl0PT017939; Mon, 18 Nov 2019 17:50:38 -0500 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2waday63u8-1; Mon, 18 Nov 2019 17:50:37 -0500 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id B12261FCAA; Mon, 18 Nov 2019 22:50:37 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1iWpqu-0005aA-Az; Mon, 18 Nov 2019 14:50:36 -0800 Date: Mon, 18 Nov 2019 14:50:35 -0800 From: Benjamin Kaduk To: Nick Sullivan Cc: Yaron Sheffer , "" , draft-ietf-tls-exported-authenticator.all@ietf.org, ietf@ietf.org, secdir@ietf.org Message-ID: <20191118225035.GS20609@akamai.com> References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-18_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=993 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911180195 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-18_07:2019-11-15,2019-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 priorityscore=1501 malwarescore=0 mlxlogscore=999 adultscore=0 mlxscore=0 bulkscore=0 lowpriorityscore=0 clxscore=1011 spamscore=0 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911180194 Archived-At: Subject: Re: [secdir] [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2019 22:50:48 -0000 On Sun, Nov 17, 2019 at 04:42:05PM +0800, Nick Sullivan wrote: > Hi Yaron, > > Thanks for reminding me about the codepoint issue. It's a sticky one. > > As far as I see it, there are three options: > > a) Change the document to UPDATE RFC 8446 > This feels like a heavyweight option and may complicate things since it > will mean that SNI is allowed but undefined for CertificateVerify in the > TLS handshake. > > b) Ask for a new extension point for SNI sent in a client-generated > authenticator request. > This has the downside of not scaling to future client hello extensions that > could be useful in exported authenticator requests -- it forces the > definition of a new code point for each new extension. > > c) Explicitly state that the CertificateRequest-like construction in > client-generated exported authenticator requests is a new type of message > (analogous to a ClientHello) and clarify the rules about which extensions > can be used when it is client-generated (specifically, say that any > extension supported in CH is allowed) > This is my preferred solution. Just to check: this would be adding a new possible value for the "TLS 1.3" column at https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1 ? Thanks, Ben > I'm interested to hear what the working group thinks, and I'll happily > present the options at IETF 106 if there's time. > From nobody Mon Nov 18 18:06:41 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118D41200B8 for ; Mon, 18 Nov 2019 18:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPUU_TVK-eCK for ; Mon, 18 Nov 2019 18:06:35 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9515412004E for ; Mon, 18 Nov 2019 18:06:35 -0800 (PST) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xAJ26VfF019275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 18 Nov 2019 21:06:33 -0500 Date: Mon, 18 Nov 2019 18:06:31 -0800 From: Benjamin Kaduk To: secdir@ietf.org Message-ID: <20191119020631.GX32847@mit.edu> References: <20191109004814.GQ47216@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191109004814.GQ47216@kduck.mit.edu> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] IETF 106 secdir lunch in "Bras Basah" X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2019 02:06:40 -0000 In case the mail from a couple weeks ago got lost, we're having the secdir lunch in the "Bras Basah" room in a couple hours. (To give people a chance to grab food, we'll try to start around 12:15.) See you soon! -Ben On Fri, Nov 08, 2019 at 04:48:14PM -0800, Benjamin Kaduk wrote: > Hi all, > > We've been allocated the room "Bras Basah" for our tuesday lunch slot. > IIRC there are several food options in the (sub)basement of the mall to > grab something quick. > > -Ben > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Mon Nov 18 18:56:46 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAC21208DD for ; Mon, 18 Nov 2019 18:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IitJ94-tmeQ3 for ; Mon, 18 Nov 2019 18:56:33 -0800 (PST) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07ECC120801 for ; Mon, 18 Nov 2019 18:56:33 -0800 (PST) Received: by mail-vk1-xa36.google.com with SMTP id p78so3525333vkp.8 for ; Mon, 18 Nov 2019 18:56:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LQv/yJUOs3pUDQmlgpAmiyMpmDQXtVVk0ML3PkFLzxk=; b=iUG9q4TtqyjaOWftVHZ/z6Ta4SfmejIIbTZB1eImCTTVKAlAy6MAgNSJy3JQuL42QY WvIeP/Q4iKsQKb/UOXpGKB6jHmnWjv087HWnsdorSESfqpY1h4JzuRdjpBsV9Z1TlhX2 RzRyE7BewVWEmV1WCAxx/7AjiNzXSoPrI1kD0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LQv/yJUOs3pUDQmlgpAmiyMpmDQXtVVk0ML3PkFLzxk=; b=byMr4az3gJ5UnZxtYoJB8d+wwtdAqQ97+lsr7xXOFg4DgWyfS6r2QBn4IpzkZoKXu2 JsiPZu8/Tw03fvJ4rfKEWRnIsxuBU2Te1pcAE0yw9wqmobTsr8VqpqSSapovBnYZJneV PcFWuda2s9muLSOB4mVDK8/O+/+XeazG5RwBth+IzNqtUEbOf6pKUGmsxm9QojRPnm7H jkFK5HcApBnH1m6Dz1u8eOHEkPnvGQD71w4v8nF6MjznSPIPFcb9p4QOr02wLvWh0a73 bn9A99QPyw+Q7+t9uar2FoL10RIr5FVVMbYFg9e8XfkYFVLfJybppUr88NxOMG7f6cwT 9j/g== X-Gm-Message-State: APjAAAURINwR61PvAvCjm6O9B3u6RzJypBVELFb9/r8kCp49z7bYoItS qJKmsy4DVu0H4/PYHswCcLRKIuRZVmgUzVdCy69D5w== X-Google-Smtp-Source: APXvYqwBfDE5Jgmax36ij8KjskPbKiy2ovsGhceV1zkaCDugRDlu1TvGNcQq0BfRzVzzTedFWNw6fHZJ7hHFnSsMjoI= X-Received: by 2002:a1f:2cd:: with SMTP id 196mr10263419vkc.23.1574132191837; Mon, 18 Nov 2019 18:56:31 -0800 (PST) MIME-Version: 1.0 References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> <20191118225035.GS20609@akamai.com> In-Reply-To: <20191118225035.GS20609@akamai.com> From: Nick Sullivan Date: Tue, 19 Nov 2019 10:56:14 +0800 Message-ID: To: Benjamin Kaduk Cc: Yaron Sheffer , "" , draft-ietf-tls-exported-authenticator.all@ietf.org, ietf@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="0000000000001ff5830597aa364c" Archived-At: Subject: Re: [secdir] [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2019 02:56:44 -0000 --0000000000001ff5830597aa364c Content-Type: text/plain; charset="UTF-8" On Tue, Nov 19, 2019 at 6:50 AM Benjamin Kaduk wrote: > On Sun, Nov 17, 2019 at 04:42:05PM +0800, Nick Sullivan wrote: > > Hi Yaron, > > > > Thanks for reminding me about the codepoint issue. It's a sticky one. > > > > As far as I see it, there are three options: > > > > a) Change the document to UPDATE RFC 8446 > > This feels like a heavyweight option and may complicate things since it > > will mean that SNI is allowed but undefined for CertificateVerify in the > > TLS handshake. > > > > b) Ask for a new extension point for SNI sent in a client-generated > > authenticator request. > > This has the downside of not scaling to future client hello extensions > that > > could be useful in exported authenticator requests -- it forces the > > definition of a new code point for each new extension. > > > > c) Explicitly state that the CertificateRequest-like construction in > > client-generated exported authenticator requests is a new type of message > > (analogous to a ClientHello) and clarify the rules about which extensions > > can be used when it is client-generated (specifically, say that any > > extension supported in CH is allowed) > > This is my preferred solution. > > Just to check: this would be adding a new possible value for the "TLS 1.3" > column at > https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1 > ? > Not necessarily. The text could be amended to say something like: "the allowed extensions for client-generated authenticator requests need to have CH listed, and for server-generated authenticator requests need to have CR listed" The only current extension that supports CR, but not CH is oid_filters, which is not relevant to client-initiated authenticator requests. > Thanks, > > Ben > > > I'm interested to hear what the working group thinks, and I'll happily > > present the options at IETF 106 if there's time. > > > --0000000000001ff5830597aa364c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 19, 2019 at 6:50 AM Benja= min Kaduk <bkaduk= @akamai.com> wrote:
On Sun, Nov 17, 2019 at 04:42:05PM +0800, Nick Sullivan wrote: > Hi Yaron,
>
> Thanks for reminding me about the codepoint issue. It's a sticky o= ne.
>
> As far as I see it, there are three options:
>
> a) Change the document to UPDATE RFC 8446
> This feels like a heavyweight option and may complicate things since i= t
> will mean that SNI is allowed but undefined for CertificateVerify in t= he
> TLS handshake.
>
> b) Ask for a new extension point for SNI sent in a client-generated > authenticator request.
> This has the downside of not scaling to future client hello extensions= that
> could be useful in exported authenticator requests -- it forces the > definition of a new code point for each new extension.
>
> c) Explicitly state that the CertificateRequest-like construction in > client-generated exported authenticator requests is a new type of mess= age
> (analogous to a ClientHello) and clarify the rules about which extensi= ons
> can be used when it is client-generated (specifically, say that any > extension supported in CH is allowed)
> This is my preferred solution.

Just to check: this would be adding a new possible value for the "TLS = 1.3"
column at https://www.iana.org/assignments/tls-extensiontype= -values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1 ?
=
Not necessarily. The text could be amended to say somethi= ng like:
=C2=A0 "the allowed extensions for client-generated= authenticator requests need to have=C2=A0CH listed, and for server-generat= ed authenticator requests need to have CR listed"
=C2=A0
The only current extension that supports CR, but not CH is=C2=A0oid_= filters, which is not relevant to client-initiated authenticator requests.<= /div>


Thanks,

Ben

> I'm interested to hear what the working group thinks, and I'll= happily
> present the options at IETF 106 if there's time.
>
--0000000000001ff5830597aa364c-- From nobody Tue Nov 19 01:18:13 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D74E1208F4; Tue, 19 Nov 2019 01:16:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1574154975; bh=3wjcT3c19uwASa9Rw4z/8rYqMSpgWDQhxQJzUx9SJsc=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=imjiGt5LBKBqHlHaMR3vtBi6mwaLUy+DvUBX4T6yASN+m/l6/o45i6LdaqM1ET1tu Rovp7rS93m4XniBzT31TUVwo3BQqHL3GA8iZ+4q6Kl9HtIghNdzdx/B0i7LyNo0oD/ XxxmIHe9V9CvkwQuJmpMBdnaUzcjV4WBx0dmXJOg= X-Mailbox-Line: From new-work-bounces@ietf.org Tue Nov 19 01:16:14 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6F11200C1; Tue, 19 Nov 2019 01:16:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1574154974; bh=3wjcT3c19uwASa9Rw4z/8rYqMSpgWDQhxQJzUx9SJsc=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=ebl27ZAAiwoznI+DeCh4dJvxllV5rJfHTvCJoryp7y2De4VZz3RCbqk8kDPhDKd0X YLg4mFEKYHRfOO86ubzLvUGjm/YkfH9T2o/UBhup3tJgSPK0ch2b1FSrk8/nOhHvCG //2yQ6CvQqv7rxKmrX269zafnJicB8UytnyI9MR4= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96C412081F for ; Tue, 19 Nov 2019 01:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNGhvWA2juxS for ; Tue, 19 Nov 2019 01:16:11 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343861200C1 for ; Tue, 19 Nov 2019 01:16:11 -0800 (PST) Received: from [42.100.6.52] (helo=[192.168.1.4]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1iWzcG-0007iJ-QC for new-work@ietf.org; Tue, 19 Nov 2019 09:16:09 +0000 To: new-work@ietf.org From: xueyuan Message-ID: <3c171fb4-9b3c-7933-265d-c2c7da07cebb@w3.org> Date: Tue, 19 Nov 2019 17:16:05 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 19 Nov 2019 01:18:12 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Service Workers Working Group (until 2019-12-17) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2019 09:16:16 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgU2Vydmlj ZSBXb3JrZXJzIFdvcmtpbmcgR3JvdXA6CiDCoCBodHRwczovL3d3dy53My5vcmcvMjAxOS8xMS9w cm9wb3NlZC1zdy13Zy1jaGFydGVyLTIwMTkuaHRtbAoKQXMgcGFydCBvZiBlbnN1cmluZyB0aGF0 IHRoZSBjb21tdW5pdHkgaXMgYXdhcmUgb2YgcHJvcG9zZWQgd29yawphdCBXM0MsIHRoaXMgZHJh ZnQgY2hhcnRlciBpcyBwdWJsaWMgZHVyaW5nIHRoZSBBZHZpc29yeQpDb21taXR0ZWUgcmV2aWV3 IHBlcmlvZC4KClczQyBpbnZpdGVzIHB1YmxpYyBjb21tZW50cyB0aHJvdWdoIDIwMTktMTItMTcg b24gdGhlCnByb3Bvc2VkIGNoYXJ0ZXIuIFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvCnB1YmxpYy1u ZXctd29ya0B3My5vcmcsIHdoaWNoIGhhcyBhIHB1YmxpYyBhcmNoaXZlOgogwqAgaHR0cDovL2xp c3RzLnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvcHVibGljLW5ldy13b3JrLwoKT3RoZXIgdGhhbiBj b21tZW50cyBzZW50IGluIGZvcm1hbCByZXNwb25zZXMgYnkgVzNDIEFkdmlzb3J5CkNvbW1pdHRl ZSBSZXByZXNlbnRhdGl2ZXMsIFczQyBjYW5ub3QgZ3VhcmFudGVlIGEgcmVzcG9uc2UgdG8KY29t bWVudHMuIElmIHlvdSB3b3JrIGZvciBhIFczQyBNZW1iZXIgWzFdLCBwbGVhc2UgY29vcmRpbmF0 ZQp5b3VyIGNvbW1lbnRzIHdpdGggeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRp dmUuIEZvcgpleGFtcGxlLCB5b3UgbWF5IHdpc2ggdG8gbWFrZSBwdWJsaWMgY29tbWVudHMgdmlh IHRoaXMgbGlzdCBhbmQKaGF2ZSB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2 ZSByZWZlciB0byBpdCBmcm9tIGhpcwpvciBoZXIgZm9ybWFsIHJldmlldyBjb21tZW50cy4KCklm IHlvdSBzaG91bGQgaGF2ZSBhbnkgcXVlc3Rpb25zIG9yIG5lZWQgZnVydGhlciBpbmZvcm1hdGlv biwgcGxlYXNlCmNvbnRhY3QgWXZlcyBMYWZvbiwgU2VydmljZSBXb3JrZXJzIFdvcmtpbmcgR3Jv dXAgVGVhbSBDb250YWN0LAphdCA8eWxhZm9uQHczLm9yZz4uCgpUaGFuayB5b3UsCgpYdWV5dWFu IEppYSwgVzNDIE1hcmtldGluZyAmIENvbW11bmljYXRpb25zCgpbMV0gaHR0cDovL3d3dy53My5v cmcvQ29uc29ydGl1bS9NZW1iZXIvTGlzdAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KbmV3LXdvcmsgbWFpbGluZyBsaXN0Cm5ldy13b3JrQGlldGYub3Jn Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Tue Nov 19 01:18:19 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C45112086A for ; Tue, 19 Nov 2019 01:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, PDS_TONAME_EQ_TOLOCAL_SHORT=1.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpU1yzffZeom for ; Tue, 19 Nov 2019 01:18:08 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B2ED120096 for ; Tue, 19 Nov 2019 01:18:08 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id xAJ9I7KR043565 for ; Tue, 19 Nov 2019 04:18:07 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu xAJ9I7KR043565 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1574155087; bh=c/4zb9er/zR6OdlVQ4+MXz28CYZN3mW5mB21IcmMDuc=; h=From:To:Subject:Date:From; b=QaKGM2vCjIqlTZo/VoNpcvzzGuy5jYxKWOob6K9yxEAIrJkiMe8avuOX49QpqfTUW wqKif+u1sTeS/2XcuawHRS69B8cE0/7e2ChxL6AOdlZDuZcISZvx0KyNcObTqyM4i0 oDCjV8oqaPvt5mTCC1iaOSGz6ZCh4ndWLyb0fKdk= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id xAJ9I7aK040304 for ; Tue, 19 Nov 2019 04:18:07 -0500 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0468.000; Tue, 19 Nov 2019 04:18:06 -0500 From: Roman Danyliw To: secdir Thread-Topic: Pointers to items mentioned at secdir lunch Thread-Index: AdWemsiFftXecOprQ1yN/dLnA2kzXA== Date: Tue, 19 Nov 2019 09:18:06 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01E70B2530@marchand> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [secdir] Pointers to items mentioned at secdir lunch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2019 09:18:12 -0000 Hi! Here are pointers to items discussed during today's secdir lunch: Common Security Issues https://trac.ietf.org/trac/sec/wiki/TypicalSECAreaIssues Evaluation of a Sample of RFC Produced in 2018 https://datatracker.ietf.org/doc/draft-huitema-rfc-eval-project/ Roman From nobody Tue Nov 19 01:38:17 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D7B120BB1; Tue, 19 Nov 2019 01:20:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1574155234; bh=NT/NtX90MPuK9LDn44UP00VGGbQvwud0E5MB4E5DS1g=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=mo/0q5hsfa0lOAd8/sX3weRXcNXAysEEp/H+hbYzfuhyNJrLWmd6ZyngqFOd1xaKN u0s7502LrbF3u8XLVFNWyaqX/h1zCtW1LpwWmpLkgDR2jrHfy6d66uta1CQPwgJFF8 krGuZZfffXvfs0CLttkMjATXQR5nc1o6QAZT8r6U= X-Mailbox-Line: From new-work-bounces@ietf.org Tue Nov 19 01:20:34 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C997120BA2; Tue, 19 Nov 2019 01:20:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1574155234; bh=NT/NtX90MPuK9LDn44UP00VGGbQvwud0E5MB4E5DS1g=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=mo/0q5hsfa0lOAd8/sX3weRXcNXAysEEp/H+hbYzfuhyNJrLWmd6ZyngqFOd1xaKN u0s7502LrbF3u8XLVFNWyaqX/h1zCtW1LpwWmpLkgDR2jrHfy6d66uta1CQPwgJFF8 krGuZZfffXvfs0CLttkMjATXQR5nc1o6QAZT8r6U= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986A9120BA7 for ; Tue, 19 Nov 2019 01:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTduFHAPSRxV for ; Tue, 19 Nov 2019 01:20:31 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75548120EE3 for ; Tue, 19 Nov 2019 01:20:00 -0800 (PST) Received: from [42.100.6.52] (helo=[192.168.1.4]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1iWzfz-0007p8-A7 for new-work@ietf.org; Tue, 19 Nov 2019 09:19:59 +0000 To: new-work@ietf.org From: xueyuan Message-ID: Date: Tue, 19 Nov 2019 17:19:56 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 19 Nov 2019 01:38:15 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Web of Things Working Group (until 2019-12-17) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2019 09:20:36 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgV2ViIG9m IFRoaW5ncyBXb3JraW5nIEdyb3VwOgogwqAgaHR0cHM6Ly93d3cudzMub3JnLzIwMTkvMTEvcHJv cG9zZWQtd290LXdnLWNoYXJ0ZXItMjAxOS5odG1sCgpBcyBwYXJ0IG9mIGVuc3VyaW5nIHRoYXQg dGhlIGNvbW11bml0eSBpcyBhd2FyZSBvZiBwcm9wb3NlZCB3b3JrCmF0IFczQywgdGhpcyBkcmFm dCBjaGFydGVyIGlzIHB1YmxpYyBkdXJpbmcgdGhlIEFkdmlzb3J5CkNvbW1pdHRlZSByZXZpZXcg cGVyaW9kLgoKVzNDIGludml0ZXMgcHVibGljIGNvbW1lbnRzIHRocm91Z2ggMjAxOS0xMi0xNyBv biB0aGUKcHJvcG9zZWQgY2hhcnRlci4gUGxlYXNlIHNlbmQgY29tbWVudHMgdG8KcHVibGljLW5l dy13b3JrQHczLm9yZywgd2hpY2ggaGFzIGEgcHVibGljIGFyY2hpdmU6CiDCoCBodHRwOi8vbGlz dHMudzMub3JnL0FyY2hpdmVzL1B1YmxpYy9wdWJsaWMtbmV3LXdvcmsvCgpPdGhlciB0aGFuIGNv bW1lbnRzIHNlbnQgaW4gZm9ybWFsIHJlc3BvbnNlcyBieSBXM0MgQWR2aXNvcnkKQ29tbWl0dGVl IFJlcHJlc2VudGF0aXZlcywgVzNDIGNhbm5vdCBndWFyYW50ZWUgYSByZXNwb25zZSB0bwpjb21t ZW50cy4gSWYgeW91IHdvcmsgZm9yIGEgVzNDIE1lbWJlciBbMV0sIHBsZWFzZSBjb29yZGluYXRl CnlvdXIgY29tbWVudHMgd2l0aCB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2 ZS4gRm9yCmV4YW1wbGUsIHlvdSBtYXkgd2lzaCB0byBtYWtlIHB1YmxpYyBjb21tZW50cyB2aWEg dGhpcyBsaXN0IGFuZApoYXZlIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZl IHJlZmVyIHRvIGl0IGZyb20gaGlzCm9yIGhlciBmb3JtYWwgcmV2aWV3IGNvbW1lbnRzLgoKSWYg eW91IHNob3VsZCBoYXZlIGFueSBxdWVzdGlvbnMgb3IgbmVlZCBmdXJ0aGVyIGluZm9ybWF0aW9u LCBwbGVhc2UKY29udGFjdCB0aGUgV2ViIG9mIFRoaW5ncyBXb3JraW5nIEdyb3VwIFN0YWZmIENv bnRhY3RzLApLYXogQXNoaW11cmEgPGFzaGltdXJhQHczLm9yZz4gYW5kIERhdmUgUmFnZ2V0dCA8 ZHNyQHczLm9yZz4uCgpUaGFuayB5b3UsClh1ZXl1YW4gSmlhLCBXM0MgTWFya2V0aW5nICYgQ29t bXVuaWNhdGlvbnMKClsxXSBodHRwOi8vd3d3LnczLm9yZy9Db25zb3J0aXVtL01lbWJlci9MaXN0 CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbmV3LXdv cmsgbWFpbGluZyBsaXN0Cm5ldy13b3JrQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Tue Nov 19 12:27:27 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDEC120122 for ; Tue, 19 Nov 2019 12:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.101 X-Spam-Level: *** X-Spam-Status: No, score=3.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgj6tcHqSba4 for ; Tue, 19 Nov 2019 12:27:23 -0800 (PST) Received: from cuda.olm1.com (cuda.olm1.com [72.236.255.32]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43F73120120 for ; Tue, 19 Nov 2019 12:27:23 -0800 (PST) X-ASG-Debug-ID: 1574194463-13786435eb364110001-mFDwdl Received: from host105.olm1.com (host105.olm1.com [72.236.255.15]) by cuda.olm1.com with ESMTP id g6K9FMHGCT8byaQV (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Nov 2019 15:14:23 -0500 (EST) X-Barracuda-Envelope-From: victor.demjanenko@vocal.com X-Barracuda-Effective-Source-IP: host105.olm1.com[72.236.255.15] X-Barracuda-Apparent-Source-IP: 72.236.255.15 Received: from HERTELLT (rrcs-72-43-202-98.nys.biz.rr.com [72.43.202.98]) by host105.olm1.com (Postfix) with ESMTPSA id AF5BAB5D9AC; Tue, 19 Nov 2019 15:14:22 -0500 (EST) From: To: "'Benjamin Kaduk'" , "'Barry Leiba'" Cc: "'Roni Even \(A\)'" , "'The IESG'" , "'Catherine Meadows'" , "'IETF SecDir'" , , "'Ali Begen'" , , , "'Dave Satterlee \(Vocal\)'" , "'IETF discussion list'" , , References: <157007038502.8860.1558861534319247512.idtracker@ietfa.amsl.com> <001601d57af9$405efcf0$c11cf6d0$@vocal.com> <6E58094ECC8D8344914996DAD28F1CCD23D79BC0@DGGEMM506-MBX.china.huawei.com> <034a01d58a73$f4d3a1c0$de7ae540$@vocal.com> <037e01d58a92$72287510$56795f30$@vocal.com> <20191101001153.GQ88302@kduck.mit.edu> In-Reply-To: <20191101001153.GQ88302@kduck.mit.edu> Date: Tue, 19 Nov 2019 15:14:21 -0500 X-ASG-Orig-Subj: RE: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) Message-ID: <06e101d59f15$ee937b30$cbba7190$@vocal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQKF5W0DvD42FGb/qFKkK3bBTKTeXwLglFUwAo/9rkMBQrixDgL+oF71AnDrF6QCpTAEF6W8HORw X-Barracuda-Connect: host105.olm1.com[72.236.255.15] X-Barracuda-Start-Time: 1574194463 X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384 X-Barracuda-URL: https://72.236.255.32:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at olm1.com X-Barracuda-Scan-Msg-Size: 31078 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.78114 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name Archived-At: Subject: Re: [secdir] Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2019 20:27:26 -0000 Hi Ben, Sorry I overlooked sending you a response. I would like to address the two concerns you have by explaining what the speech coders are doing. WRT to 600 bps MELP, there is one TSVCIS mode that uses one bit beyond the 54-bit frame for MELP 600 as a frame sync which alternates between frames. With two or more MELP 600bps frames in one RTP packet, if any frame indicates 600 bps by CODA being 0 and CODB being 1, then we know the stream is 600bps. If there is a single frame in an RTP packet, you can still deduce this by looking at every other RTP packet (every other MELP 600bps frame) and by the timestamp advance. Most likely the two ends would negotiate 600 bps in SDP anyways so there really should not be a problem. I know it's not pretty but its workable. I hope this explanation helps you with the concerns for this issue. As for the TSVCIS parameter packing/unpacking, this is really simple. There is exactly on three bit parameter, exactly one five bit parameter and a variable number of eight bit parameters. In our view, the speech coder itself (or a wrapper for it) is responsible for preparing the block of octets. RTP then just transports it. On receive, the complementary wrapper reverses the packing operation. I hope this clarifies and explains the simplicity. Regards, Victor -----Original Message----- From: Benjamin Kaduk Sent: Thursday, October 31, 2019 8:12 PM To: Barry Leiba Cc: victor.demjanenko@vocal.com; Roni Even (A) ; The IESG ; Catherine Meadows ; IETF SecDir ; draft-ietf-payload-tsvcis@ietf.org; Ali Begen ; avtcore-chairs@ietf.org; avt@ietf.org; Dave Satterlee (Vocal) ; IETF discussion list ; draft-ietf-payload-tsvcis.all@ietf.org Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) I don't think so, unfortunately. I do see the clarification about CODB's potential for deviation from Table 1, that only the 600 bps MELPe is allowed to deviate, and that CODA gets us to "it's one of 2400 or 600 bps" and the RTP timestamp disambiguates that 600 bps is in use. But, it seems that this means that the recipient in general should not rely on CODB to differentiate 600 from 2400 bps, and instead is more robustly implemented by *always* using the RTP timestamp to detect 600 bps, since that will always work and CODB will sometimes not work under conditions not fully specified here. So, if we are unwilling or unable to clarify what those conditions are (e.g., whether at a minimum mutual agreement is required), then I think we need to describe this procedure of consulting the RTP timestamp as the default behavior and avoid giving the impression that CODB should be used to do so. Additionally, I don't see anything to address my concern about TSVCIS parameter decoding. To be clear, the procedure I see this document describing is that: - TSVCIS gives parameters (and their lengths in bits) to the codec described in this document - this document specifies how to densely encode those parameters into a byetstream - RTP transmits that encoded bytestream to the peer - the codec specified by this is responsible for turning that encoded bystream back into a list of TSVCIS parameters (and their length in bits) I don't see how that last step is attainable with only the information provided by this document. I *assume* that one of the TSVCIS specifications has a canonical (ordered) listing of parameters, and that the list of parmeters given to this codec in the first step will always be an initial prefix of that list, but that's just me guessing at how to make sense of the stated procedure given insufficient information. I don't think it's appropriate to make the reader of an RFC guess at what to do; we need to either say how to do it or give a pointer to an external reference that does. -Ben On Tue, Oct 29, 2019 at 02:26:09PM -0400, Barry Leiba wrote: > Ben, does the -04 version address everything? > > Barry > > On Thu, Oct 24, 2019 at 1:42 PM wrote: > > > > I forgot to address security comments in one email. The changes are: > > > > Section 8, second paragraph - Suggested edit by reviewer > > > > (was) > > This RTP payload format and the TSVCIS decoder do not exhibit any > > significant non-uniformity in the receiver-side computational > > complexity for packet processing and thus are unlikely to pose a > > denial-of-service threat due to the receipt of pathological data. > > Additionally, the RTP payload format does not contain any active > > content. > > > > (now) > > This RTP payload format and the TSVCIS decoder, to the best of our > > knowledge, do not exhibit any significant non-uniformity in the > > receiver-side computational complexity for packet processing and thus > > are unlikely to pose a denial-of-service threat due to the receipt of > > pathological data. Additionally, the RTP payload format does not > > contain any active content. > > > > > > Section 8, third paragraph - Suggested edit by reviewer > > > > (was) > > Please see the security considerations discussed in [RFC6562] > > regarding VAD and its effect on bitrates. > > > > (now) > > Please see the security considerations discussed in [RFC6562] > > regarding Voice Activity Detect (VAD) and its effect on bitrates. > > > > Victor > > > > -----Original Message----- > > From: victor.demjanenko@vocal.com > > Sent: Thursday, October 24, 2019 10:05 AM > > To: 'Roni Even (A)' ; 'Benjamin Kaduk' > > ; 'The IESG' > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' > > ; avtcore-chairs@ietf.org; avt@ietf.org; > > 'Dave Satterlee (Vocal)' > > Subject: RE: Benjamin Kaduk's Discuss on > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > Hi Everyone, > > > > First we want to thank everyone for their review and comments for this draft RFC. We believe we reviewed all the comments and suggestions and incorporated them adequately in the next draft (04). We'd like to send out this list of exact changes in case anyone has additional comments or thinks the clarifications are inadequate. We would be most happy to address concerns before publishing draft 04 tomorrow. > > > > With so many emails from a half dozen or more reviewers, we apologize that we cannot address each sender individually. We hope this detail is sufficient for everyone. > > > > Again, many thanks to all. > > > > Victor & Dave > > > > -------------------------------------------------------------------- > > -------------------------- > > > > Section 1.1 - Suggested reference to RFC 8088 added. > > > > (was) > > Best current practices for writing an RTP payload format > > specification were followed [RFC2736]. > > > > (now) > > Best current practices for writing an RTP payload format > > specification were followed [RFC2736] [RFC8088]. > > > > > > Section 2, paragraphs 3 and 4 - Suggested edits by reviewers > > > > (was) > > In addition to the augmented speech data, the TSVCIS specification > > identifies which speech coder and framing bits are to be encrypted, > > and how they are protected by forward error correction (FEC) > > techniques (using block codes). At the RTP transport layer, only the > > speech coder related bits need to be considered and are conveyed in > > unencrypted form. In most IP-based network deployments, standard > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > > 1 Ethernet encryptors) would be used to secure the RTP speech > > contents. Further, it is desirable to support the highest voice > > quality between endpoints which is only possible without the overhead > > of FEC. > > > > TSVCIS augmented speech data is derived from the signal processing > > and data already performed by the MELPe speech coder. For the > > purposes of this specification, only the general parameter nature of > > TSVCIS will be characterized. Depending on the bandwidth available > > (and FEC requirements), a varying number of TSVCIS specific speech > > coder parameters need to be transported. These are first byte-packed > > and then conveyed from encoder to decoder. > > > > (now) > > In addition to the augmented speech data, the TSVCIS specification > > identifies which speech coder and framing bits are to be encrypted, > > and how they are protected by forward error correction (FEC) > > techniques (using block codes). At the RTP transport layer, only the > > speech-coder-related bits need to be considered and are conveyed in > > unencrypted form. In most IP-based network deployments, standard > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > > 1 Ethernet encryptors) would be used to secure the RTP speech > > contents. > > > > TSVCIS augmented speech data is derived from the signal processing > > and data already performed by the MELPe speech coder. For the > > purposes of this specification, only the general parameter nature of > > TSVCIS will be characterized. Depending on the bandwidth available > > (and FEC requirements), a varying number of TSVCIS-specific speech > > coder parameters need to be transported. These are first byte-packed > > and then conveyed from encoder to decoder. > > > > > > Section 3, last sentence paragraph 3 - Suggested edit by reviewer > > > > (was) > > When more than one codec data frame is > > present in a single RTP packet, the timestamp is, as always, that of > > the oldest data frame represented in the RTP packet. > > > > (now) > > When more than one codec data frame is > > present in a single RTP packet, the timestamp specified is that of > > the oldest data frame represented in the RTP packet. > > > > > > Section 3.1, last paragraph - Clarified permission for MELP 600 > > end-to-end framing bit > > > > (was) > > It should be noted that CODB for both the 2400 and 600 bps modes MAY > > deviate from the values in Table 1 when bit 55 is used as an end-to- > > end framing bit. Frame decoding would remain distinct as CODA being > > zero on its own would indicate a 7-byte frame for either rate and the > > use of 600 bps speech coding could be deduced from the RTP timestamp > > (and anticipated by the SDP negotiations). > > > > (now) > > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > > the value in Table 1 when bit 55 is used as an end-to-end framing > > bit. Frame decoding would remain distinct as CODA being zero on its > > own would indicate a 7-byte frame for either 2400 or 600 bps rate and > > the use of 600 bps speech coding could be deduced from the RTP > > timestamp (and anticipated by the SDP negotiations). > > > > > > Section 3.2, first paragraph - Clarifications requested by reviewers > > > > (was) > > The TSVCIS augmented speech data as packed parameters MUST be placed > > immediately after a corresponding MELPe 2400 bps payload in the same > > RTP packet. The packed parameters are counted in octets (TC). In > > the preferred placement, shown in Figure 6, a single trailing octet > > SHALL be appended to include a two-bit rate code, CODA and CODB, > > (both bits set to one) and a six-bit modified count (MTC). The > > special modified count value of all ones (representing a MTC value of > > 63) SHALL NOT be used for this format as it is used as the indicator > > for the alternate packing format shown next. In a standard > > implementation, the TSVCIS speech coder uses a minimum of 15 octets > > for parameters in octet packed form. The modified count (MTC) MUST > > be reduced by 15 from the full octet count (TC). Computed MTC = TC- > > 15. This accommodates a maximum of 77 parameter octets (maximum > > value of MTC is 62, 77 is the sum of 62+15). > > > > (now) > > The TSVCIS augmented speech data as packed parameters MUST be placed > > immediately after a corresponding MELPe 2400 bps payload in the same > > RTP packet. The packed parameters are counted in octets (TC). The > > preferred placement SHOULD be used for TSVCIS payloads with TC less > > than or equal to 77 octets, is shown in Figure 6. In the preferred > > placement, a single trailing octet SHALL be appended to include a > > two-bit rate code, CODA and CODB, (both bits set to one) and a six- > > bit modified count (MTC). The special modified count value of all > > ones (representing a MTC value of 63) SHALL NOT be used for this > > format as it is used as the indicator for the alternate packing > > format shown next. In a standard implementation, the TSVCIS speech > > coder uses a minimum of 15 octets for parameters in octet packed > > form. The modified count (MTC) MUST be reduced by 15 from the full > > octet count (TC). Computed MTC = TC-15. This accommodates a maximum > > of 77 parameter octets (maximum value of MTC is 62, 77 is the sum of > > 62+15). > > > > > > Section 3.3, first paragraph - Suggested edit by reviewer > > > > (was) > > A TSVCIS RTP packet consists of zero or more TSVCIS coder frames > > (each consisting of MELPe and TSVCIS coder data) followed by zero or > > one MELPe comfort noise frame. The presence of a comfort noise frame > > can be determined by its rate code bits in its last octet. > > > > (now) > > A TSVCIS RTP packet payload consists of zero or more consecutive > > TSVCIS coder frames (each consisting of MELPe 2400 and TSVCIS coder > > data), with the oldest frame first, followed by zero or one MELPe > > comfort noise frame. The presence of a comfort noise frame can be > > determined by its rate code bits in its last octet. > > > > > > Section 3.3, fourth paragraph - Clarification requested by reviewers > > > > (was) > > TSVCIS coder frames in a single RTP packet MAY be of different coder > > bitrates. With the exception for the variable length TSVCIS > > parameter frames, the coder rate bits in the trailing byte identify > > the contents and length as per Table 1. > > > > (now) > > TSVCIS coder frames in a single RTP packet MAY have varying TSVCIS > > parameter octet counts. Its packed parameter octet count (length) is > > indicated in the trailing byte(s). All MELPe frames in a single RTP > > packet MUST be of the same coder bitrate. For all MELPe coder > > frames, the coder rate bits in the trailing byte identify the > > contents and length as per Table 1. > > > > > > Section 4.1 - Editor note removed > > > > > > Section 4.1 - Change controller is now > > > > (now) > > Change controller: IETF, contact > > > > > > Section 5, first paragraph - Suggested edits by reviewers > > > > (was) > > A primary application of TSVCIS is for radio communications of voice > > conversations, and discontinuous transmissions are normal. When > > TSVCIS is used in an IP network, TSVCIS RTP packet transmissions may > > cease and resume frequently. RTP synchronization source (SSRC) > > sequence number gaps indicate lost packets to be filled by PLC, while > > abrupt loss of RTP packets indicates intended discontinuous > > transmissions. > > > > (now) > > A primary application of TSVCIS is for radio communications of voice > > conversations, and discontinuous transmissions are normal. When > > TSVCIS is used in an IP network, TSVCIS RTP packet transmissions may > > cease and resume frequently. RTP synchronization source (SSRC) > > sequence number gaps indicate lost packets to be filled by Packet > > Loss Concealment (PLC), while abrupt loss of RTP packets indicates > > intended discontinuous transmissions. Resumption of voice > > transmission SHOULD be indicated by the RTP marker bit (M) set to 1. > > > > > > Section 10 - Added reference > > > > (added) > > [RFC8088] Westerlund, M., "How to Write an RTP Payload Format", > > RFC 8088, DOI 10.17487/RFC8088, May 2017, > > . > > > > -------------------------------------------------------------------- > > ----------------------------- > > > > > > -----Original Message----- > > From: Roni Even (A) > > Sent: Sunday, October 6, 2019 2:09 AM > > To: victor.demjanenko@vocal.com; 'Benjamin Kaduk' ; > > 'The IESG' > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' > > ; avtcore-chairs@ietf.org; avt@ietf.org; > > 'Dave Satterlee (Vocal)' > > Subject: RE: Benjamin Kaduk's Discuss on > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > Hi, > > About the reference to TSVCIS. > > The RTP payload is about how to encapsulate the payload in an RTP packet. The objective is to define how an RTP stack can insert the tsvcis frames and extract the tsvcis frames from the RTP packet. Typically it is not required to understand the payload structure in order to be able to perform the encapsulation. > > This is why the reference to the payload is Informational and we did > > not require to have it publically available. If there is a need to > > understand the payload itself for the encapsulating than we need > > more information in the RTP payload specification and a publically > > available normative reference. I think this is not the case here > > > > Roni Even > > > > AVTCore co-chair (ex Payload) > > > > -----Original Message----- > > From: victor.demjanenko@vocal.com > > [mailto:victor.demjanenko@vocal.com] > > Sent: Saturday, October 05, 2019 12:18 AM > > To: 'Benjamin Kaduk'; 'The IESG' > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen'; avtcore-chairs@ietf.org; avt@ietf.org; 'Victor Demjanenko, Ph.D.'; 'Dave Satterlee (Vocal)' > > Subject: RE: Benjamin Kaduk's Discuss on > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > Everyone, > > > > Thanks for the comments. I think I mis-understood the ambiguity with respect to to changing rates within a RTP packet. That was not plan. An RTP packet must have MELP speech frames of the same rate. What is possible is that the amount of augmented TSVCIS speech data may vary from one speech frame to the next. This allows for a dynamic VDR as suggested by the NRL paper. So an RTP packet may have varying TSVCIS data but must always have MELPe 2400 data. > > > > Again backwards parsing is necessary but the timestamp uniformly increments 22.5msec per combined MELP/TSVCIS speech frame. > > > > The NRL is a good public reference on the VDR aspects. The actual TSVCIS spec we had was FOUO so we could not replicate its detail. (I believe a later spec is public or at least partially public. I am trying to get this.) The opaque data is pretty obvious with the TSVCIS spec in hand. > > > > We will address the issues/concerns raised next week. Other business had priority. > > > > Thank you and enjoy the weekend. > > > > Regards, > > > > Victor & Dave > > > > -----Original Message----- > > From: Benjamin Kaduk via Datatracker > > Sent: Wednesday, October 2, 2019 10:40 PM > > To: The IESG > > Cc: draft-ietf-payload-tsvcis@ietf.org; Ali Begen > > ; avtcore-chairs@ietf.org; > > ali.begen@networked.media; avt@ietf.org > > Subject: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: > > (with DISCUSS and COMMENT) > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-payload-tsvcis-03: Discuss > > > > When responding, please keep the subject line intact and reply to > > all email addresses included in the To and CC lines. (Feel free to > > cut this introductory paragraph, however.) > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-payload-tsvcis/ > > > > > > > > -------------------------------------------------------------------- > > -- > > DISCUSS: > > -------------------------------------------------------------------- > > -- > > > > I support Magnus' point about the time-ordering of adjacent frames in a packet. > > > > Additionally, I am not sure that there's quite enough here to be interoperably implementable. Specifically, we seem to be lacking a description of how an encoder or decoder knows which TSVCIS parameters, and in what order, to byte-pack or unpack, respectively. One might surmise that there is a canonical listing in [TSVCIS], but this document does not say that, and furthermore [TSVCIS] is only listed as an informative reference. (I couldn't get my hands on my copy, at least on short notice.) If we limited ourselves to treating the TSVCIS parameters as an entirely opaque blob (codec, convey these N octets to the peer with the appropriate one- or two-byte trailer for payload type identification and framing), that would be interoperably implementable, since the black-box bits are up to some other codec to interpret. > > > > In a similar vein, we mention but do not completely specify the potential for using CODB as an end-to-end framing bit, in Section 3.1 (see Comment), which is not interoperably implementable without further details. > > > > > > -------------------------------------------------------------------- > > -- > > COMMENT: > > -------------------------------------------------------------------- > > -- > > > > Where is [TSVCIS] available? > > > > Is [NRLVDR] the same as > > https://apps.dtic.mil/dtic/tr/fulltext/u2/a588068.pdf ? A URL in the references would be helpful. > > > > Is additional TSVCIS data only present after 2400bps MELPe and the first thing to get dropped under bandwidth pressure? The abstract and introduction imply this by calling out MELPe 2400 bps speech parameters explicitly, but Section 3 says that TSVCIS augments standard 600, 1200, and 2400 bps MELP frames. > > > > It's helpful that Section 3.3 gives some general guidance for decoding this payload type ("[t]he way to determine the number of TSVCIS/MELPe frames is to identify each frame type and length"), but I think some generic considerations would be very helpful to the reader much earlier, along the lines of "MELPe and TSVCIS data payloads are decoded from the end, using the CODA and CODB (and, if necessary, CODC and others) bits to determine the type of payload. For MELPe payloads the type also indicates the payload length, whereas for TSVCIS data an additional length field is present, in one of two possible formats. A TSVCIS coder frame consists of a MELPe data payload followed by zero or one TSVCIS data payload; after the TSVCIS payload's presence/length is determined, then the preceding MELPe payload can be determined and decoded. Per Section 3.3, multiple TSVCIS frames can be present in a single RTP packet." This (or something like it) would also serve to clarify the role of the COD* bits, which is otherwise only implicitly introduced. > > > > Section 1.1 > > > > RFC 2736 is BCP 36 (but it's updated by RFC 8088 which is for some reason an Informational document and not part of BCP 36?!). > > > > Section 2 > > > > In addition to the augmented speech data, the TSVCIS specification > > identifies which speech coder and framing bits are to be encrypted, > > and how they are protected by forward error correction (FEC) > > techniques (using block codes). At the RTP transport layer, only the > > speech coder related bits need to be considered and are conveyed in > > unencrypted form. In most IP-based network deployments, standard > > > > Am I reading this correctly that this text is just summarizing what's in the TSVCIS spec in terms of what needs to be in unencrypted form, so the "only the speech coder related bits[...]" is not new information from this document? I'm not sure I agree with the conclusion, regardless -- won't the (MELPe) speech coder bits be enough to convey the semantic content of the audio stream, something that one might desire to keep confidential? > > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > > 1 Ethernet encryptors) would be used to secure the RTP speech > > contents. Further, it is desirable to support the highest voice > > quality between endpoints which is only possible without the overhead > > of FEC. > > > > I think I'm missing a step in how this conclusion was reached. > > > > TSVCIS will be characterized. Depending on the bandwidth available > > (and FEC requirements), a varying number of TSVCIS specific speech > > coder parameters need to be transported. These are first byte-packed > > and then conveyed from encoder to decoder. > > > > Per the Discuss point, how do I know which parameters need to be transported, and in what order? > > > > Byte packing of TSVCIS speech data into packed parameters is > > processed as per the following example: > > > > Three-bit field: bits A, B, and C (A is MSB, C is LSB) > > Five-bit field: bits D, E, F, G, and H (D is MSB, H is LSB) > > > > MSB LSB > > 0 1 2 3 4 5 6 7 > > +------+------+------+------+------+------+------+------+ > > | H | G | F | E | D | C | B | A | > > +------+------+------+------+------+------+------+------+ > > > > This packing method places the three-bit field "first" in the lowest > > bits followed by the next five-bit field. Parameters may be split > > between octets with the most significant bits in the earlier octet. > > Any unfilled bits in the last octet MUST be filled with zero. > > > > I agree with Adam that this is very unclear. A is the MSB of the three-bit field but the LSB of the octet overall? > > We probably need an example of splitting a parameter across octets as well, to get the bit ordering right. > > > > Section 3.1 > > > > It should be noted that CODB for both the 2400 and 600 bps modes MAY > > deviate from the values in Table 1 when bit 55 is used as an end-to- > > end framing bit. Frame decoding would remain distinct as CODA > > being > > > > Where is the use of CODB as an end-to-end framing bit defined? If we're going to provide neither a complete description of how to do it nor a reference to a better description, we probably shouldn't mention it at all. > > > > Section 3.2 > > > > RTP packet. The packed parameters are counted in octets (TC). In > > the preferred placement, shown in Figure 6, a single trailing octet > > SHALL be appended to include a two-bit rate code, CODA and CODB, > > > > I'd consider saying something about this being the preferred format > > ("placement") due to its shorter length than the alternative, and say that it "SHOULD be used for TSVCIS payloads with TC less than or equal to 77 octetes". > > > > Section 3.3 > > > > When a longer packetization interval is used, is that indicated by signaling or RTP timestamps or otherwise? > > > > TSVCIS coder frames in a single RTP packet MAY be of different coder > > bitrates. With the exception for the variable length TSVCIS > > parameter frames, the coder rate bits in the trailing byte identify > > the contents and length as per Table 1. > > > > Maybe also note that the penultimate octet gives the length there? > > > > Information describing the number of frames contained in an RTP > > packet is not transmitted as part of the RTP payload. The way to > > determine the number of TSVCIS/MELPe frames is to identify each frame > > type and length thereby counting the total number of octets within > > the RTP packet. > > > > terminology nit: if a frame is the combination of MELPe and TSVCIS payload data units then there are two layres of decoding to get a length for the frame, since we have to get the TSVCIS length and then the MELPe length. > > > > Section 4.2 > > > > Parameter "ptime" cannot be used for the purpose of specifying > > the > > > > nit: missing article ("The parameter") > > > > will be impossible to distinguish which mode is about to be used > > (e.g., when ptime=68, it would be impossible to distinguish if the > > packet is carrying one frame of 67.5 ms or three frames of 22.5 ms). > > > > So how is the operating mode determined, then? > > (I think this is the same question I asked above) > > > > Section 4.4 > > > > For example, if offerer bitrates are "2400,600" and answer bitrates > > are "600,2400", the initial bitrate is 600. If other bitrates are > > provided by the answerer, any common bitrate between the offer and > > answer MAY be used at any time in the future. Activation of these > > other common bitrates is beyond the scope of this document. > > > > It seems important to specify whether this requires a new O/A exchange or can be done "spontaneously" by just encoding different frame types. > > (It seems like the latter is possible, on first glance, and this is > > implied by Section 3.3's discussion of mixing them in a single > > packet.) > > > > Section 5 > > > > Please expand PLC at first use (not second). > > > > Section 6 > > > > I don't understand the PLC usage. Is the idea that a receiver, on seeing an SSRC gap, constructs fictitious PLC frames to "fill the gap" > > and passes the resulting stream to the decoder? > > > > Section 8 > > > > and important considerations in [RFC7201]. Applications SHOULD use > > one or more appropriate strong security mechanisms. The rest of this > > section discusses the security-impacting properties of the payload > > format itself. > > > > I thought we described TSVCIS itself (much earlier in the document) as requiring encryption for some data; wouldn't that translate to a "MUST" > > here and not a "SHOULD"? > > > > > > From nobody Wed Nov 20 22:21:14 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA7A12006F for ; Wed, 20 Nov 2019 22:21:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <157431727344.1104.1577645356594226271.idtracker@ietfa.amsl.com> Date: Wed, 20 Nov 2019 22:21:13 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 06:21:13 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-12-05 Reviewer LC end Draft John Bradley 2019-11-22 draft-schaad-cbor-content-01 Shawn Emery 2019-10-04 draft-ietf-mpls-ldp-yang-07 Watson Ladd R2019-09-17 draft-ietf-stir-oob-06 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-04 Sean Turner 2019-11-07 draft-ietf-ospf-ospfv2-hbit-11 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Last calls: Reviewer LC end Draft John Bradley 2019-11-22 draft-schaad-cbor-content-01 Shaun Cooley 2019-11-12 draft-ietf-regext-login-security-06 Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-17 Alan DeKok 2019-11-27 draft-ietf-6man-ra-pref64-07 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Linda Dunbar 2019-12-02 draft-ietf-opsec-v6-21 Donald Eastlake 2019-12-16 draft-nottingham-rfc7320bis-02 Donald Eastlake 2019-11-14 draft-ietf-hip-dex-11 Shawn Emery 2019-10-04 draft-ietf-mpls-ldp-yang-07 Stephen Farrell 2019-12-02 draft-ietf-dprive-rfc7626-bis-03 Daniel Franke 2019-12-02 draft-ietf-mboned-driad-amt-discovery-09 Tobias Gondrom 2019-12-02 draft-ietf-tls-tls13-cert-with-extern-psk-03 Phillip Hallam-Baker 2019-12-02 draft-ietf-stir-passport-divert-07 Steve Hanna 2019-08-07 draft-ietf-oauth-jwt-introspection-response-08 Dan Harkins R2019-10-03 draft-ietf-dtn-bpsec-13 Watson Ladd R2019-09-17 draft-ietf-stir-oob-06 Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-18 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Stefan Santesson 2019-10-10 draft-ietf-payload-rtp-ttml-06 Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-04 Sean Turner 2019-11-25 draft-ietf-nfsv4-rfc5661sesqui-msns-03 Sean Turner 2019-11-07 draft-ietf-ospf-ospfv2-hbit-11 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Early review requests: Reviewer Due Draft Russ Housley 2019-10-04 draft-ietf-lwig-curve-representations-08 Next in the reviewer rotation: Dan Harkins Russ Housley Christian Huitema Leif Johansson Benjamin Kaduk Charlie Kaufman Scott Kelly Stephen Kent Tero Kivinen Watson Ladd From nobody Sat Nov 23 04:24:08 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D1B12001E; Sat, 23 Nov 2019 04:23:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Watson Ladd via Datatracker To: Cc: last-call@ietf.org, stir@ietf.org, draft-ietf-stir-oob.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Watson Ladd Message-ID: <157451183735.3875.15374676331308138462@ietfa.amsl.com> Date: Sat, 23 Nov 2019 04:23:57 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-stir-oob-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2019 12:23:57 -0000 Reviewer: Watson Ladd Review result: Ready This draft doesn't have anything wrong with it as far as I can see. It describes one way to potentially deploy STIR on the PSTN, but other ways may be needed before a real deployment, so minor quibbles about "this scheme could be more efficient" aren't that important. Sincerely, Watson Ladd From nobody Sun Nov 24 22:46:39 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4189C12080A; Sun, 24 Nov 2019 22:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vy8MPJH1BAfw; Sun, 24 Nov 2019 22:46:29 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C8CB1207FE; Sun, 24 Nov 2019 22:46:29 -0800 (PST) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xAP6k6eu021548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 25 Nov 2019 01:46:08 -0500 Date: Sun, 24 Nov 2019 22:46:06 -0800 From: Benjamin Kaduk To: victor.demjanenko@vocal.com Cc: "'Barry Leiba'" , "'Roni Even (A)'" , "'The IESG'" , "'Catherine Meadows'" , "'IETF SecDir'" , draft-ietf-payload-tsvcis@ietf.org, "'Ali Begen'" , avtcore-chairs@ietf.org, avt@ietf.org, "'Dave Satterlee (Vocal)'" , "'IETF discussion list'" , draft-ietf-payload-tsvcis.all@ietf.org Message-ID: <20191125064606.GL32847@mit.edu> References: <157007038502.8860.1558861534319247512.idtracker@ietfa.amsl.com> <001601d57af9$405efcf0$c11cf6d0$@vocal.com> <6E58094ECC8D8344914996DAD28F1CCD23D79BC0@DGGEMM506-MBX.china.huawei.com> <034a01d58a73$f4d3a1c0$de7ae540$@vocal.com> <037e01d58a92$72287510$56795f30$@vocal.com> <20191101001153.GQ88302@kduck.mit.edu> <06e101d59f15$ee937b30$cbba7190$@vocal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06e101d59f15$ee937b30$cbba7190$@vocal.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2019 06:46:32 -0000 Hi Victor, On Tue, Nov 19, 2019 at 03:14:21PM -0500, victor.demjanenko@vocal.com wrote: > Hi Ben, > > Sorry I overlooked sending you a response. I would like to address the two > concerns you have by explaining what the speech coders are doing. Thanks for the extra clarifications. To supply one of my own: I'm not concerned that the protocol doesn't work as implemented, but just want to make sure that the document includes enough information to admit new implementations without guesswork. That is to say, "either tell me how to do it or tell me where to look that tells me how to do it". > WRT to 600 bps MELP, there is one TSVCIS mode that uses one bit beyond the > 54-bit frame for MELP 600 as a frame sync which alternates between frames. > With two or more MELP 600bps frames in one RTP packet, if any frame > indicates 600 bps by CODA being 0 and CODB being 1, then we know the stream > is 600bps. If there is a single frame in an RTP packet, you can still > deduce this by looking at every other RTP packet (every other MELP 600bps > frame) and by the timestamp advance. Most likely the two ends would > negotiate 600 bps in SDP anyways so there really should not be a problem. I > know it's not pretty but its workable. I hope this explanation helps you > with the concerns for this issue. In this case, the use as an "end-to-end framing bit" (i.e., the alternating behavior you describe above) is not explicitly stated; one might imagine a scheme where the framing usage is to have the bit cycle through 1, 1, 0, and 0, or some other scheme. I'd suggest to note in the document that if any instance of (CODA, CODB) == (0, 1) is observed, then the 600bps mode is in use. It might also be helpful to include the observation that two successive MELPe payloads with CODA == CODB == 0 indicates the 2400bps mode (and that seeing them in a single RTP packet is decisive, whereas additional information about packet non-loss would be needed in the one-MELPe-frame-per-RTP-packet case), but that would be a fair bit of additional text and might be diminishing returns. (Or, of course, the use of CODB as an alternating 1/0 bit as the framing usage could be documented instead.) > As for the TSVCIS parameter packing/unpacking, this is really simple. There > is exactly on three bit parameter, exactly one five bit parameter and a > variable number of eight bit parameters. In our view, the speech coder > itself (or a wrapper for it) is responsible for preparing the block of > octets. RTP then just transports it. On receive, the complementary wrapper > reverses the packing operation. I hope this clarifies and explains the > simplicity. That's exactly what I expected to happen; however, it's not what I believe the current text of the document is describing. Specifically, I think that the current text implies that the "preparing the block of octets" and "complementary wrapper reverses the packing operation" are supposed to be part of the RTP payload format that this document describes, but this document does not have enough information to actually perform those operations reversibly. If the packing is to be done in the speech coder, then this document doesn't need to talk about the packing at all (e.g., at the end of Section 2); if we need to keep the packing/wrapper in this document then we need to indicate that there's a defined priority order for the (8-octet) TSVCIS parameters in the TSVCIS references, to allow the packing/unpacking to be deterministic. Thanks, Ben > > -----Original Message----- > From: Benjamin Kaduk > Sent: Thursday, October 31, 2019 8:12 PM > To: Barry Leiba > Cc: victor.demjanenko@vocal.com; Roni Even (A) ; The > IESG ; Catherine Meadows ; > IETF SecDir ; draft-ietf-payload-tsvcis@ietf.org; Ali Begen > ; avtcore-chairs@ietf.org; avt@ietf.org; Dave > Satterlee (Vocal) ; IETF discussion list > ; draft-ietf-payload-tsvcis.all@ietf.org > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with > DISCUSS and COMMENT) > > I don't think so, unfortunately. > > I do see the clarification about CODB's potential for deviation from Table > 1, that only the 600 bps MELPe is allowed to deviate, and that CODA gets us > to "it's one of 2400 or 600 bps" and the RTP timestamp disambiguates that > 600 bps is in use. But, it seems that this means that the recipient in > general should not rely on CODB to differentiate 600 from 2400 bps, and > instead is more robustly implemented by *always* using the RTP timestamp to > detect 600 bps, since that will always work and CODB will sometimes not work > under conditions not fully specified here. So, if we are unwilling or > unable to clarify what those conditions are (e.g., whether at a minimum > mutual agreement is required), then I think we need to describe this > procedure of consulting the RTP timestamp as the default behavior and avoid > giving the impression that CODB should be used to do so. > > Additionally, I don't see anything to address my concern about TSVCIS > parameter decoding. To be clear, the procedure I see this document > describing is that: > - TSVCIS gives parameters (and their lengths in bits) to the codec > described in this document > - this document specifies how to densely encode those parameters into a > byetstream > - RTP transmits that encoded bytestream to the peer > - the codec specified by this is responsible for turning that encoded > bystream back into a list of TSVCIS parameters (and their length in bits) > > I don't see how that last step is attainable with only the information > provided by this document. I *assume* that one of the TSVCIS specifications > has a canonical (ordered) listing of parameters, and that the list of > parmeters given to this codec in the first step will always be an initial > prefix of that list, but that's just me guessing at how to make sense of the > stated procedure given insufficient information. I don't think it's > appropriate to make the reader of an RFC guess at what to do; we need to > either say how to do it or give a pointer to an external reference that > does. > > -Ben > > On Tue, Oct 29, 2019 at 02:26:09PM -0400, Barry Leiba wrote: > > Ben, does the -04 version address everything? > > > > Barry > > > > On Thu, Oct 24, 2019 at 1:42 PM wrote: > > > > > > I forgot to address security comments in one email. The changes are: > > > > > > Section 8, second paragraph - Suggested edit by reviewer > > > > > > (was) > > > This RTP payload format and the TSVCIS decoder do not exhibit any > > > significant non-uniformity in the receiver-side computational > > > complexity for packet processing and thus are unlikely to pose a > > > denial-of-service threat due to the receipt of pathological data. > > > Additionally, the RTP payload format does not contain any active > > > content. > > > > > > (now) > > > This RTP payload format and the TSVCIS decoder, to the best of our > > > knowledge, do not exhibit any significant non-uniformity in the > > > receiver-side computational complexity for packet processing and thus > > > are unlikely to pose a denial-of-service threat due to the receipt of > > > pathological data. Additionally, the RTP payload format does not > > > contain any active content. > > > > > > > > > Section 8, third paragraph - Suggested edit by reviewer > > > > > > (was) > > > Please see the security considerations discussed in [RFC6562] > > > regarding VAD and its effect on bitrates. > > > > > > (now) > > > Please see the security considerations discussed in [RFC6562] > > > regarding Voice Activity Detect (VAD) and its effect on bitrates. > > > > > > Victor > > > > > > -----Original Message----- > > > From: victor.demjanenko@vocal.com > > > Sent: Thursday, October 24, 2019 10:05 AM > > > To: 'Roni Even (A)' ; 'Benjamin Kaduk' > > > ; 'The IESG' > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' > > > ; avtcore-chairs@ietf.org; avt@ietf.org; > > > 'Dave Satterlee (Vocal)' > > > Subject: RE: Benjamin Kaduk's Discuss on > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > Hi Everyone, > > > > > > First we want to thank everyone for their review and comments for this > draft RFC. We believe we reviewed all the comments and suggestions and > incorporated them adequately in the next draft (04). We'd like to send out > this list of exact changes in case anyone has additional comments or thinks > the clarifications are inadequate. We would be most happy to address > concerns before publishing draft 04 tomorrow. > > > > > > With so many emails from a half dozen or more reviewers, we apologize > that we cannot address each sender individually. We hope this detail is > sufficient for everyone. > > > > > > Again, many thanks to all. > > > > > > Victor & Dave > > > > > > -------------------------------------------------------------------- > > > -------------------------- > > > > > > Section 1.1 - Suggested reference to RFC 8088 added. > > > > > > (was) > > > Best current practices for writing an RTP payload format > > > specification were followed [RFC2736]. > > > > > > (now) > > > Best current practices for writing an RTP payload format > > > specification were followed [RFC2736] [RFC8088]. > > > > > > > > > Section 2, paragraphs 3 and 4 - Suggested edits by reviewers > > > > > > (was) > > > In addition to the augmented speech data, the TSVCIS specification > > > identifies which speech coder and framing bits are to be encrypted, > > > and how they are protected by forward error correction (FEC) > > > techniques (using block codes). At the RTP transport layer, only the > > > speech coder related bits need to be considered and are conveyed in > > > unencrypted form. In most IP-based network deployments, standard > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > > > 1 Ethernet encryptors) would be used to secure the RTP speech > > > contents. Further, it is desirable to support the highest voice > > > quality between endpoints which is only possible without the overhead > > > of FEC. > > > > > > TSVCIS augmented speech data is derived from the signal processing > > > and data already performed by the MELPe speech coder. For the > > > purposes of this specification, only the general parameter nature of > > > TSVCIS will be characterized. Depending on the bandwidth available > > > (and FEC requirements), a varying number of TSVCIS specific speech > > > coder parameters need to be transported. These are first byte-packed > > > and then conveyed from encoder to decoder. > > > > > > (now) > > > In addition to the augmented speech data, the TSVCIS specification > > > identifies which speech coder and framing bits are to be encrypted, > > > and how they are protected by forward error correction (FEC) > > > techniques (using block codes). At the RTP transport layer, only the > > > speech-coder-related bits need to be considered and are conveyed in > > > unencrypted form. In most IP-based network deployments, standard > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > > > 1 Ethernet encryptors) would be used to secure the RTP speech > > > contents. > > > > > > TSVCIS augmented speech data is derived from the signal processing > > > and data already performed by the MELPe speech coder. For the > > > purposes of this specification, only the general parameter nature of > > > TSVCIS will be characterized. Depending on the bandwidth available > > > (and FEC requirements), a varying number of TSVCIS-specific speech > > > coder parameters need to be transported. These are first byte-packed > > > and then conveyed from encoder to decoder. > > > > > > > > > Section 3, last sentence paragraph 3 - Suggested edit by reviewer > > > > > > (was) > > > When more than one codec data frame is > > > present in a single RTP packet, the timestamp is, as always, that of > > > the oldest data frame represented in the RTP packet. > > > > > > (now) > > > When more than one codec data frame is > > > present in a single RTP packet, the timestamp specified is that of > > > the oldest data frame represented in the RTP packet. > > > > > > > > > Section 3.1, last paragraph - Clarified permission for MELP 600 > > > end-to-end framing bit > > > > > > (was) > > > It should be noted that CODB for both the 2400 and 600 bps modes MAY > > > deviate from the values in Table 1 when bit 55 is used as an end-to- > > > end framing bit. Frame decoding would remain distinct as CODA being > > > zero on its own would indicate a 7-byte frame for either rate and the > > > use of 600 bps speech coding could be deduced from the RTP timestamp > > > (and anticipated by the SDP negotiations). > > > > > > (now) > > > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > > > the value in Table 1 when bit 55 is used as an end-to-end framing > > > bit. Frame decoding would remain distinct as CODA being zero on its > > > own would indicate a 7-byte frame for either 2400 or 600 bps rate and > > > the use of 600 bps speech coding could be deduced from the RTP > > > timestamp (and anticipated by the SDP negotiations). > > > > > > > > > Section 3.2, first paragraph - Clarifications requested by reviewers > > > > > > (was) > > > The TSVCIS augmented speech data as packed parameters MUST be placed > > > immediately after a corresponding MELPe 2400 bps payload in the same > > > RTP packet. The packed parameters are counted in octets (TC). In > > > the preferred placement, shown in Figure 6, a single trailing octet > > > SHALL be appended to include a two-bit rate code, CODA and CODB, > > > (both bits set to one) and a six-bit modified count (MTC). The > > > special modified count value of all ones (representing a MTC value of > > > 63) SHALL NOT be used for this format as it is used as the indicator > > > for the alternate packing format shown next. In a standard > > > implementation, the TSVCIS speech coder uses a minimum of 15 octets > > > for parameters in octet packed form. The modified count (MTC) MUST > > > be reduced by 15 from the full octet count (TC). Computed MTC = TC- > > > 15. This accommodates a maximum of 77 parameter octets (maximum > > > value of MTC is 62, 77 is the sum of 62+15). > > > > > > (now) > > > The TSVCIS augmented speech data as packed parameters MUST be placed > > > immediately after a corresponding MELPe 2400 bps payload in the same > > > RTP packet. The packed parameters are counted in octets (TC). The > > > preferred placement SHOULD be used for TSVCIS payloads with TC less > > > than or equal to 77 octets, is shown in Figure 6. In the preferred > > > placement, a single trailing octet SHALL be appended to include a > > > two-bit rate code, CODA and CODB, (both bits set to one) and a six- > > > bit modified count (MTC). The special modified count value of all > > > ones (representing a MTC value of 63) SHALL NOT be used for this > > > format as it is used as the indicator for the alternate packing > > > format shown next. In a standard implementation, the TSVCIS speech > > > coder uses a minimum of 15 octets for parameters in octet packed > > > form. The modified count (MTC) MUST be reduced by 15 from the full > > > octet count (TC). Computed MTC = TC-15. This accommodates a maximum > > > of 77 parameter octets (maximum value of MTC is 62, 77 is the sum of > > > 62+15). > > > > > > > > > Section 3.3, first paragraph - Suggested edit by reviewer > > > > > > (was) > > > A TSVCIS RTP packet consists of zero or more TSVCIS coder frames > > > (each consisting of MELPe and TSVCIS coder data) followed by zero or > > > one MELPe comfort noise frame. The presence of a comfort noise frame > > > can be determined by its rate code bits in its last octet. > > > > > > (now) > > > A TSVCIS RTP packet payload consists of zero or more consecutive > > > TSVCIS coder frames (each consisting of MELPe 2400 and TSVCIS coder > > > data), with the oldest frame first, followed by zero or one MELPe > > > comfort noise frame. The presence of a comfort noise frame can be > > > determined by its rate code bits in its last octet. > > > > > > > > > Section 3.3, fourth paragraph - Clarification requested by reviewers > > > > > > (was) > > > TSVCIS coder frames in a single RTP packet MAY be of different coder > > > bitrates. With the exception for the variable length TSVCIS > > > parameter frames, the coder rate bits in the trailing byte identify > > > the contents and length as per Table 1. > > > > > > (now) > > > TSVCIS coder frames in a single RTP packet MAY have varying TSVCIS > > > parameter octet counts. Its packed parameter octet count (length) is > > > indicated in the trailing byte(s). All MELPe frames in a single RTP > > > packet MUST be of the same coder bitrate. For all MELPe coder > > > frames, the coder rate bits in the trailing byte identify the > > > contents and length as per Table 1. > > > > > > > > > Section 4.1 - Editor note removed > > > > > > > > > Section 4.1 - Change controller is now > > > > > > (now) > > > Change controller: IETF, contact > > > > > > > > > Section 5, first paragraph - Suggested edits by reviewers > > > > > > (was) > > > A primary application of TSVCIS is for radio communications of voice > > > conversations, and discontinuous transmissions are normal. When > > > TSVCIS is used in an IP network, TSVCIS RTP packet transmissions may > > > cease and resume frequently. RTP synchronization source (SSRC) > > > sequence number gaps indicate lost packets to be filled by PLC, while > > > abrupt loss of RTP packets indicates intended discontinuous > > > transmissions. > > > > > > (now) > > > A primary application of TSVCIS is for radio communications of voice > > > conversations, and discontinuous transmissions are normal. When > > > TSVCIS is used in an IP network, TSVCIS RTP packet transmissions may > > > cease and resume frequently. RTP synchronization source (SSRC) > > > sequence number gaps indicate lost packets to be filled by Packet > > > Loss Concealment (PLC), while abrupt loss of RTP packets indicates > > > intended discontinuous transmissions. Resumption of voice > > > transmission SHOULD be indicated by the RTP marker bit (M) set to 1. > > > > > > > > > Section 10 - Added reference > > > > > > (added) > > > [RFC8088] Westerlund, M., "How to Write an RTP Payload Format", > > > RFC 8088, DOI 10.17487/RFC8088, May 2017, > > > . > > > > > > -------------------------------------------------------------------- > > > ----------------------------- > > > > > > > > > -----Original Message----- > > > From: Roni Even (A) > > > Sent: Sunday, October 6, 2019 2:09 AM > > > To: victor.demjanenko@vocal.com; 'Benjamin Kaduk' ; > > > 'The IESG' > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' > > > ; avtcore-chairs@ietf.org; avt@ietf.org; > > > 'Dave Satterlee (Vocal)' > > > Subject: RE: Benjamin Kaduk's Discuss on > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > Hi, > > > About the reference to TSVCIS. > > > The RTP payload is about how to encapsulate the payload in an RTP > packet. The objective is to define how an RTP stack can insert the tsvcis > frames and extract the tsvcis frames from the RTP packet. Typically it is > not required to understand the payload structure in order to be able to > perform the encapsulation. > > > This is why the reference to the payload is Informational and we did > > > not require to have it publically available. If there is a need to > > > understand the payload itself for the encapsulating than we need > > > more information in the RTP payload specification and a publically > > > available normative reference. I think this is not the case here > > > > > > Roni Even > > > > > > AVTCore co-chair (ex Payload) > > > > > > -----Original Message----- > > > From: victor.demjanenko@vocal.com > > > [mailto:victor.demjanenko@vocal.com] > > > Sent: Saturday, October 05, 2019 12:18 AM > > > To: 'Benjamin Kaduk'; 'The IESG' > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen'; > avtcore-chairs@ietf.org; avt@ietf.org; 'Victor Demjanenko, Ph.D.'; 'Dave > Satterlee (Vocal)' > > > Subject: RE: Benjamin Kaduk's Discuss on > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > Everyone, > > > > > > Thanks for the comments. I think I mis-understood the ambiguity with > respect to to changing rates within a RTP packet. That was not plan. An > RTP packet must have MELP speech frames of the same rate. What is possible > is that the amount of augmented TSVCIS speech data may vary from one speech > frame to the next. This allows for a dynamic VDR as suggested by the NRL > paper. So an RTP packet may have varying TSVCIS data but must always have > MELPe 2400 data. > > > > > > Again backwards parsing is necessary but the timestamp uniformly > increments 22.5msec per combined MELP/TSVCIS speech frame. > > > > > > The NRL is a good public reference on the VDR aspects. The actual > TSVCIS spec we had was FOUO so we could not replicate its detail. (I > believe a later spec is public or at least partially public. I am trying to > get this.) The opaque data is pretty obvious with the TSVCIS spec in hand. > > > > > > We will address the issues/concerns raised next week. Other business > had priority. > > > > > > Thank you and enjoy the weekend. > > > > > > Regards, > > > > > > Victor & Dave > > > > > > -----Original Message----- > > > From: Benjamin Kaduk via Datatracker > > > Sent: Wednesday, October 2, 2019 10:40 PM > > > To: The IESG > > > Cc: draft-ietf-payload-tsvcis@ietf.org; Ali Begen > > > ; avtcore-chairs@ietf.org; > > > ali.begen@networked.media; avt@ietf.org > > > Subject: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: > > > (with DISCUSS and COMMENT) > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-payload-tsvcis-03: Discuss > > > > > > When responding, please keep the subject line intact and reply to > > > all email addresses included in the To and CC lines. (Feel free to > > > cut this introductory paragraph, however.) > > > > > > > > > Please refer to > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-payload-tsvcis/ > > > > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > DISCUSS: > > > -------------------------------------------------------------------- > > > -- > > > > > > I support Magnus' point about the time-ordering of adjacent frames in a > packet. > > > > > > Additionally, I am not sure that there's quite enough here to be > interoperably implementable. Specifically, we seem to be lacking a > description of how an encoder or decoder knows which TSVCIS parameters, and > in what order, to byte-pack or unpack, respectively. One might surmise that > there is a canonical listing in [TSVCIS], but this document does not say > that, and furthermore [TSVCIS] is only listed as an informative reference. > (I couldn't get my hands on my copy, at least on short notice.) If we > limited ourselves to treating the TSVCIS parameters as an entirely opaque > blob (codec, convey these N octets to the peer with the appropriate one- or > two-byte trailer for payload type identification and framing), that would be > interoperably implementable, since the black-box bits are up to some other > codec to interpret. > > > > > > In a similar vein, we mention but do not completely specify the > potential for using CODB as an end-to-end framing bit, in Section 3.1 (see > Comment), which is not interoperably implementable without further details. > > > > > > > > > -------------------------------------------------------------------- > > > -- > > > COMMENT: > > > -------------------------------------------------------------------- > > > -- > > > > > > Where is [TSVCIS] available? > > > > > > Is [NRLVDR] the same as > > > https://apps.dtic.mil/dtic/tr/fulltext/u2/a588068.pdf ? A URL in the > references would be helpful. > > > > > > Is additional TSVCIS data only present after 2400bps MELPe and the first > thing to get dropped under bandwidth pressure? The abstract and > introduction imply this by calling out MELPe 2400 bps speech parameters > explicitly, but Section 3 says that TSVCIS augments standard 600, 1200, and > 2400 bps MELP frames. > > > > > > It's helpful that Section 3.3 gives some general guidance for decoding > this payload type ("[t]he way to determine the number of TSVCIS/MELPe frames > is to identify each frame type and length"), but I think some generic > considerations would be very helpful to the reader much earlier, along the > lines of "MELPe and TSVCIS data payloads are decoded from the end, using the > CODA and CODB (and, if necessary, CODC and others) bits to determine the > type of payload. For MELPe payloads the type also indicates the payload > length, whereas for TSVCIS data an additional length field is present, in > one of two possible formats. A TSVCIS coder frame consists of a MELPe data > payload followed by zero or one TSVCIS data payload; after the TSVCIS > payload's presence/length is determined, then the preceding MELPe payload > can be determined and decoded. Per Section 3.3, multiple TSVCIS frames can > be present in a single RTP packet." This (or something like it) would also > serve to clarify the role of the COD* bits, which is otherwise only > implicitly introduced. > > > > > > Section 1.1 > > > > > > RFC 2736 is BCP 36 (but it's updated by RFC 8088 which is for some > reason an Informational document and not part of BCP 36?!). > > > > > > Section 2 > > > > > > In addition to the augmented speech data, the TSVCIS specification > > > identifies which speech coder and framing bits are to be encrypted, > > > and how they are protected by forward error correction (FEC) > > > techniques (using block codes). At the RTP transport layer, only the > > > speech coder related bits need to be considered and are conveyed in > > > unencrypted form. In most IP-based network deployments, standard > > > > > > Am I reading this correctly that this text is just summarizing what's in > the TSVCIS spec in terms of what needs to be in unencrypted form, so the > "only the speech coder related bits[...]" is not new information from this > document? I'm not sure I agree with the conclusion, regardless -- won't the > (MELPe) speech coder bits be enough to convey the semantic content of the > audio stream, something that one might desire to keep confidential? > > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > > > 1 Ethernet encryptors) would be used to secure the RTP speech > > > contents. Further, it is desirable to support the highest voice > > > quality between endpoints which is only possible without the overhead > > > of FEC. > > > > > > I think I'm missing a step in how this conclusion was reached. > > > > > > TSVCIS will be characterized. Depending on the bandwidth available > > > (and FEC requirements), a varying number of TSVCIS specific speech > > > coder parameters need to be transported. These are first byte-packed > > > and then conveyed from encoder to decoder. > > > > > > Per the Discuss point, how do I know which parameters need to be > transported, and in what order? > > > > > > Byte packing of TSVCIS speech data into packed parameters is > > > processed as per the following example: > > > > > > Three-bit field: bits A, B, and C (A is MSB, C is LSB) > > > Five-bit field: bits D, E, F, G, and H (D is MSB, H is LSB) > > > > > > MSB LSB > > > 0 1 2 3 4 5 6 7 > > > +------+------+------+------+------+------+------+------+ > > > | H | G | F | E | D | C | B | A | > > > +------+------+------+------+------+------+------+------+ > > > > > > This packing method places the three-bit field "first" in the lowest > > > bits followed by the next five-bit field. Parameters may be split > > > between octets with the most significant bits in the earlier octet. > > > Any unfilled bits in the last octet MUST be filled with zero. > > > > > > I agree with Adam that this is very unclear. A is the MSB of the > three-bit field but the LSB of the octet overall? > > > We probably need an example of splitting a parameter across octets as > well, to get the bit ordering right. > > > > > > Section 3.1 > > > > > > It should be noted that CODB for both the 2400 and 600 bps modes MAY > > > deviate from the values in Table 1 when bit 55 is used as an end-to- > > > end framing bit. Frame decoding would remain distinct as CODA > > > being > > > > > > Where is the use of CODB as an end-to-end framing bit defined? If we're > going to provide neither a complete description of how to do it nor a > reference to a better description, we probably shouldn't mention it at all. > > > > > > Section 3.2 > > > > > > RTP packet. The packed parameters are counted in octets (TC). In > > > the preferred placement, shown in Figure 6, a single trailing octet > > > SHALL be appended to include a two-bit rate code, CODA and CODB, > > > > > > I'd consider saying something about this being the preferred format > > > ("placement") due to its shorter length than the alternative, and say > that it "SHOULD be used for TSVCIS payloads with TC less than or equal to 77 > octetes". > > > > > > Section 3.3 > > > > > > When a longer packetization interval is used, is that indicated by > signaling or RTP timestamps or otherwise? > > > > > > TSVCIS coder frames in a single RTP packet MAY be of different coder > > > bitrates. With the exception for the variable length TSVCIS > > > parameter frames, the coder rate bits in the trailing byte identify > > > the contents and length as per Table 1. > > > > > > Maybe also note that the penultimate octet gives the length there? > > > > > > Information describing the number of frames contained in an RTP > > > packet is not transmitted as part of the RTP payload. The way to > > > determine the number of TSVCIS/MELPe frames is to identify each frame > > > type and length thereby counting the total number of octets within > > > the RTP packet. > > > > > > terminology nit: if a frame is the combination of MELPe and TSVCIS > payload data units then there are two layres of decoding to get a length for > the frame, since we have to get the TSVCIS length and then the MELPe length. > > > > > > Section 4.2 > > > > > > Parameter "ptime" cannot be used for the purpose of specifying > > > the > > > > > > nit: missing article ("The parameter") > > > > > > will be impossible to distinguish which mode is about to be used > > > (e.g., when ptime=68, it would be impossible to distinguish if the > > > packet is carrying one frame of 67.5 ms or three frames of 22.5 ms). > > > > > > So how is the operating mode determined, then? > > > (I think this is the same question I asked above) > > > > > > Section 4.4 > > > > > > For example, if offerer bitrates are "2400,600" and answer bitrates > > > are "600,2400", the initial bitrate is 600. If other bitrates are > > > provided by the answerer, any common bitrate between the offer and > > > answer MAY be used at any time in the future. Activation of these > > > other common bitrates is beyond the scope of this document. > > > > > > It seems important to specify whether this requires a new O/A exchange > or can be done "spontaneously" by just encoding different frame types. > > > (It seems like the latter is possible, on first glance, and this is > > > implied by Section 3.3's discussion of mixing them in a single > > > packet.) > > > > > > Section 5 > > > > > > Please expand PLC at first use (not second). > > > > > > Section 6 > > > > > > I don't understand the PLC usage. Is the idea that a receiver, on > seeing an SSRC gap, constructs fictitious PLC frames to "fill the gap" > > > and passes the resulting stream to the decoder? > > > > > > Section 8 > > > > > > and important considerations in [RFC7201]. Applications SHOULD use > > > one or more appropriate strong security mechanisms. The rest of this > > > section discusses the security-impacting properties of the payload > > > format itself. > > > > > > I thought we described TSVCIS itself (much earlier in the document) as > requiring encryption for some data; wouldn't that translate to a "MUST" > > > here and not a "SHOULD"? > > > > > > > > > > From nobody Mon Nov 25 13:40:01 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912FF120F93; Mon, 25 Nov 2019 13:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rkfeng.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7O41yUVWCYNW; Mon, 25 Nov 2019 13:39:54 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770047.outbound.protection.outlook.com [40.107.77.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DED7120F6C; Mon, 25 Nov 2019 13:39:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kp8FYqmtZzAJPzM9QXAehx34fwUIl2wtaL4Nu/u0GMlikxVqy7FL7eJntmvf5r1Q2aAc1hkFn965XKmcKpx0XAkKAEVfUAawMdUt+ikNVeVSrSZ7piceJufDvYHE+ooRKvehQdMAMcl8CMrhHHTgM1YDq+Yk6TjLRsgd/UwLJe+EzS5wNPCCBmClKprbx83pyRKquXoWGU5swwyDnkrteVGU5crb+nLrjATAfx/XI7RfTBNaaHx6H4dQWlUcsvyIrwdrDImyWZR7+rj6GolGEE+sn/jpsLUqwDRirTv8eDGl21mSlzS0LDRLc2p4Ol2yk1BP1C1zSNcv4ex9nu97rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tRC7lWWTcaKPgXq+IO95GP7mS/VTRg/Dt1EY2t/7sy0=; b=bqO8PXkLswyQZ2/THJW81COhmVVHFTWNiMZQv+TgW9dxWzB3F3mx2L5fQXhq6r2TxWJxcDz+0/DBOFPSXdoqLsCEDA5yfxOInFadaZGV1yhON29gpR1r8hGa3hItwnk+Tl6Dx0/KhEbsh1E48DB9u8cHYqpOYydcZhtWXt1o4YCm3sqNwkrP5mDP8V94U34LHQGnTMwYPbaHZunfcLMs6o/WiBfoH9MwjTi9DrJkHEVx4OfXUD7KIGu9VlWK/HvJclnQpA6oNc7s3M6szzArICQjjC0cApIJKmSVwxQ8+94iNEglTRAMk3qNk4CyBeOrAvWW5m9LDdR4Ycm2/trmZg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=rkf-eng.com; dmarc=pass action=none header.from=rkf-eng.com; dkim=pass header.d=rkf-eng.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rkfeng.onmicrosoft.com; s=selector2-rkfeng-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tRC7lWWTcaKPgXq+IO95GP7mS/VTRg/Dt1EY2t/7sy0=; b=EUp9FkVpS/G3xJpdhv37H9UbpXwOU9aBkbWeQpzVzteKRJCmhIzgolT8fLMnii4bPNa7q3psa/uFIpW2x2ygX6xoLhHd1wYirryw1sYP9oyMMWRHBU4xyK8LyZy/MtV5KrFWnbGcE9kLKe62fcI3XRPVYhxgX4a2JmwikvnoFoc= Received: from MN2PR13MB3520.namprd13.prod.outlook.com (10.255.238.221) by MN2PR13MB3534.namprd13.prod.outlook.com (10.255.236.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.10; Mon, 25 Nov 2019 21:39:49 +0000 Received: from MN2PR13MB3520.namprd13.prod.outlook.com ([fe80::701b:4c2c:9db8:7370]) by MN2PR13MB3520.namprd13.prod.outlook.com ([fe80::701b:4c2c:9db8:7370%3]) with mapi id 15.20.2495.014; Mon, 25 Nov 2019 21:39:49 +0000 From: Brian Sipos To: Christopher Wood , "secdir@ietf.org" CC: "draft-ietf-dtn-tcpclv4.all@ietf.org" Thread-Topic: [Last-Call] Secdir last call review of draft-ietf-dtn-tcpclv4-15 Thread-Index: AQHVlQsiZv1NUR8az0SiDiIPZNLET6d+80gAgAKzukqAGmlEpw== Date: Mon, 25 Nov 2019 21:39:49 +0000 Message-ID: References: <157309030845.20168.4543125034732217684@ietfa.amsl.com>, <576b4769-ae0f-4821-a127-12a8a3d05de1@www.fastmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=BSipos@rkf-eng.com; x-originating-ip: [66.195.166.226] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 17eb0067-d612-45d5-0d5d-08d771efffbd x-ms-traffictypediagnostic: MN2PR13MB3534: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0232B30BBC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400004)(366004)(376002)(396003)(136003)(346002)(189003)(199004)(15404003)(102836004)(6506007)(53546011)(606006)(186003)(26005)(8936002)(105004)(2906002)(6436002)(7696005)(446003)(11346002)(76176011)(229853002)(4326008)(6306002)(54896002)(9686003)(55016002)(6246003)(236005)(86362001)(25786009)(71200400001)(71190400001)(508600001)(5660300002)(2501003)(66946007)(66446008)(7736002)(19627405001)(966005)(76116006)(14454004)(66556008)(64756008)(66476007)(99286004)(3846002)(6116002)(8676002)(14444005)(256004)(74316002)(81166006)(81156014)(80792005)(110136005)(52536014)(316002)(33656002)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR13MB3534; H:MN2PR13MB3520.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: rkf-eng.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8kWYIvgg9/YabQMod0xlZAey9GetwFYhdzfTpxIawLixTG550ubCfSiDCmA9AbvU9ChILXZ1MixS3J/ndEasX0gEG3IlvNDS7Fd389Nd08rpdlK0B9y1Shwx7rQFhB9dvUFkQyYGySBr5Zyt9b6JmZZ4tsY23FWXCcHKQqq+DzfPWF2TqpuyVM55jfdF9be6kED7waJdoWJsgKy6tQIcvuza4GkH21/PWw0g38ksrsZzrp15JrCE1jpeGrkJPsjfBo8QM6IAslfnWnclqfIxqJpwYFTGuZ2Q377D8qGU1HWoCXN5+BRBr2jjoSF1o1L355yVibS9+pvt9Pmwo0rQGKWdBnMyUoH9Oti6WTlRU33IYtuT5zZN6Ic33czlBPmJyWjEh2igwLMZvJNJihpEXfcH0F8VE5iCmTHXUpqU03GoYZYSaIC65Iox+XbDUAahMOY2oXTgvXBSctcULUcVHRPznr2OEA6YP9JxZ3BO2rY= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR13MB3520A9981F64A77740856D669F4A0MN2PR13MB3520namp_" MIME-Version: 1.0 X-OriginatorOrg: rkf-eng.com X-MS-Exchange-CrossTenant-Network-Message-Id: 17eb0067-d612-45d5-0d5d-08d771efffbd X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2019 21:39:49.5997 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4ed8b15b-911f-42bc-8524-d89148858535 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /HyPSPEFmGAmKYz0N0aTTds5s0gnvacLMYwH69zIvkiekTXxlkURedpefHAwP7kuRWBifBQ7Q+6lvg5KarotXw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB3534 Archived-At: Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-dtn-tcpclv4-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2019 21:39:59 -0000 --_000_MN2PR13MB3520A9981F64A77740856D669F4A0MN2PR13MB3520namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2hyaXN0b3BoZXIsDQpBIG5ldyBkcmFmdCBoYXMgYmVlbiBwb3N0ZWQgWzFdIHdoaWNoIHNob3Vs ZCBhZGRyZXNzIGFsbCBvZiB5b3VyIGNvbW1lbnRzIG9uIHRoZSAtMTUgZHJhZnQuIE1vc3Qgb2Yg dGhlIGNoYW5nZXMgWzJdIGFyZSB0byBlaXRoZXIgZml4IHR5cG9zIGFuZCBpbmNvbnNpc3RlbmNp ZXMgb3IgdG8gYWRkIHJlcXVpcmVtZW50cyBzdXBwb3J0aW5nIFRMUyB1c2UgYW5kIHRocmVhdCBt b2RlbGluZy4NCk91ciBBRCBoYXMgcmVxdWVzdGVkIGEgcmUtcmV2aWV3IG9mIHRoZSBuZXcgZHJh ZnQgdG8gdmVyaWZ5IHRoYXQgdGhlcmUgYXJlIG5vIG1vcmUgaXNzdWVzIHByZXNlbnQuIFdvdWxk IHlvdSBiZSBhYmxlIHRvIHJldmlldyB0aGUgbmV3IGRyYWZ0IHZlcnNpb24/DQpUaGFuayB5b3Us DQpCcmlhbiBTLg0KDQpbMV0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt ZHRuLXRjcGNsdjQtMTYNClsyXSBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJh ZnQtaWV0Zi1kdG4tdGNwY2x2NC0xNSZ1cmwyPWRyYWZ0LWlldGYtZHRuLXRjcGNsdjQtMTYmZGlm ZnR5cGU9LS1odG1sDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogQnJp YW4gU2lwb3MgPEJTaXBvc0Bya2YtZW5nLmNvbT4NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIg MTMsIDIwMTkgMTA6NTMNClRvOiBDaHJpc3RvcGhlciBXb29kIDxjYXdAaGVhcGluZ2JpdHMubmV0 Pjsgc2VjZGlyQGlldGYub3JnIDxzZWNkaXJAaWV0Zi5vcmc+DQpDYzogbGFzdC1jYWxsQGlldGYu b3JnIDxsYXN0LWNhbGxAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWR0bi10Y3BjbHY0LmFsbEBpZXRm Lm9yZyA8ZHJhZnQtaWV0Zi1kdG4tdGNwY2x2NC5hbGxAaWV0Zi5vcmc+OyBkdG5AaWV0Zi5vcmcg PGR0bkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTGFzdC1DYWxsXSBTZWNkaXIgbGFzdCBjYWxs IHJldmlldyBvZiBkcmFmdC1pZXRmLWR0bi10Y3BjbHY0LTE1DQoNCkNocmlzdG9waGVyLA0KVGhh bmsgeW91IGZvciB0aGVzZSBjb21tZW50cy4gTXkgcmVzcG9uc2VzIGFyZSBpbmxpbmUgYmVsb3cg d2l0aCBwcmVmaXggIkJTOiAiLiBJIGhhdmUgYmVlbiBtYWtpbmcgZWRpdHMgdG8gYSBmdXR1cmUg ZHJhZnQgd2hpY2ggaXMgbm90IHlldCB1cGxvYWRlZC4NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkZyb206IENocmlzdG9waGVyIFdvb2QgPGNhd0BoZWFwaW5nYml0cy5uZXQ+ DQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDYsIDIwMTkgMjA6NTcNClRvOiBzZWNkaXJAaWV0 Zi5vcmcgPHNlY2RpckBpZXRmLm9yZz4NCkNjOiBsYXN0LWNhbGxAaWV0Zi5vcmcgPGxhc3QtY2Fs bEBpZXRmLm9yZz47IGRyYWZ0LWlldGYtZHRuLXRjcGNsdjQuYWxsQGlldGYub3JnIDxkcmFmdC1p ZXRmLWR0bi10Y3BjbHY0LmFsbEBpZXRmLm9yZz47IGR0bkBpZXRmLm9yZyA8ZHRuQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtMYXN0LUNhbGxdIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRy YWZ0LWlldGYtZHRuLXRjcGNsdjQtMTUNCg0KT29wcy4gRGF0YXRyYWNrZXIgYnV0Y2hlcmVkIHRo ZSBmb3JtYXR0aW5nLiBMZXQncyB0cnkgdGhhdCBhZ2FpbjoNCg0Kfn5+DQoNClJldmlld2VyOiBD aHJpc3RvcGhlciBXb29kDQpSZXZpZXcgcmVzdWx0OiBIYXMgSXNzdWVzDQoNCkNvbW1lbnRzOg0K LSBTZWN0aW9uIDEuMSwgZm91cnRoIGJ1bGxldDogSSBhc3N1bWUgY2VydGlmaWNhdGUgcmV2b2Nh dGlvbiBpcyBhbHNvIG91dCBvZiBzY29wZS4gSWYgc28sIGxpc3RpbmcgdGhpcyBleHBsaWNpdGx5 IG1pZ2h0IGJlIHVzZWZ1bC4gSWYgbm90LCB3aHkgbm90PyBSZWxhdGVkbHksIGlzIHByZS1zaGFy ZWQga2V5IGF1dGhlbnRpY2F0aW9uIHN1cHBvcnRlZD8gSWYgc28sIHBlcmhhcHMgd2Ugc2hvdWxk IG1lbnRpb24gdGhhdCB0aGlzIHRvbyBpcyBvdXQgb2Ygc2NvcGU/DQpCUzogSSBhZGRlZCBleHBs aWNpdCBvdXQtb2Ytc2NvcGUgaW5kaWNhdGlvbiBmb3IgYm90aCByZXZvY2F0aW9uIGFuZCBQU0sg KGFuZCBvdGhlciBub24tY2VydGlmaWNhdGUpIHVzZS4NCg0KLSBJZiBUTFMgc2l0cyBiZWxvdyBU Q1BDTCBhbmQgaWYgcmVzdW1wdGlvbiBpcyB1c2VkLCB3aGF0IGlzIHRoZSBkZWZpbml0aW9uIG9m IGEgc2Vzc2lvbidzIGxpZmV0aW1lPyBJcyBpdCBzdGlsbCBib3VuZCB0byB0aGUgdW5kZXJseWlu ZyBUQ1AgY29ubmVjdGlvbiBsaWZldGltZT8gSSB3b3VsZCBzdWdnZXN0IHRoYXQgdGhlIGRlZmlu aXRpb24gYmUgZ2VuZXJhbGl6ZWQgdG8gYWNjb21tb2RhdGUgVExTLCBlLmcuLCBwZXJoYXBzIHRo ZSBsaWZldGltZSBpcyBib3VuZCB0byB0aGUgdW5kZXJseWluZyB0cmFuc3BvcnQgc3RhdGUgbGlm ZXRpbWUuIFJlbGF0ZWRseSwgaXMgVExTIHNlc3Npb24gcmVzdW1wdGlvbiBzdXBwb3J0ZWQgKG9y IGVuY291cmFnZWQpPyBXaGVuIGRpc2N1c3NpbmcgVExTIHNlc3Npb24gZXN0YWJsaXNobWVudCBp biBTZWN0aW9uIDQsIHRoaXMgc2VlbXMgdG8gYmUgb21pdHRlZC4NCkJTOiBJIGFkZGVkIHRleHQg dG8gU2VjdGlvbiA0IHRvIGluZGljYXRlIGJvdGggdGhlIGxpZmV0aW1lIG9mIFRMUyBzZXNzaW9u cyBhbmQgdGhlIGFiaWxpdHkgdG8gYXR0ZW1wdCB0byByZXN1bWUgc2Vzc2lvbnMuDQoNCi0gU2Vj dGlvbiAzLjIsIGZpcnN0IHBhcmFncmFwaDogV2hhdCBkb2VzICJpbml0aWF0ZSBUTFMgc2VjdXJp dHkiIG1lYW4sIGV4YWN0bHk/IERvZXMgdGhpcyBtZWFuIHRoZSBpbml0aWF0b3Igc2VuZHMgYSBU TFMgQ2xpZW50SGVsbG8gdXBvbiBUQ1AgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50LCBvciBvbmx5 IGFmdGVyIHNvbWUgb3RoZXIgVENQQ0wgaGVhZGVycyBhcmUgZXhjaGFuZ2VkPyBTaW1pbGFybHks IGlzIHRoZSBOb2RlIElEIHRyYW5zZmVycmVkIHVzZWQgaW4gYXV0aGVudGljYXRpbmcgc3VjaCBh IFRMUyBjb25uZWN0aW9uPyBJZiBzbywgaG93PyBJcyB0aGUgTm9kZSBJRCBzZW50IGFzIHRoZSBU TFMgU05JLCBhcyBoaW50ZWQgYXQgaW4gU2VjdGlvbiA0LjQuMSBhbmQgNC40LjIsIGlzIGl0IGlu Y2x1ZGVkIGluIHRoZSByZXNwb25kZXIncyBjZXJ0aWZpY2F0ZSBTQU4gbGlzdCwgZXRjPyBJIHRo aW5rIHNwZWNpZmljIGRldGFpbHMgYXJlIG5lZWRlZCBoZXJlLCBwZXJoYXBzIHdpdGggZm9yd2Fy ZCBwb2ludGVycyB0byBTZWN0aW9uIDQgYXMgbmVlZGVkLg0KQlM6IEkgcmVwaHJhc2VkIHRoZSBm aXJzdCBwYXJhZ3JhcGggYW5kIGFkZGVkIGEgcmVmZXJlbmNlIHRvIFNlY3Rpb24gNC4gVGhlIHRl eHQgaW4gU2VjdGlvbiAzIGlzIHN1cHBvc2VkIHRvIGJlIGhpZ2hlci1sZXZlbCBhbmQgaW5mb3Jt YXRpdmUsIHdoZXJlIFNlY3Rpb24gNCBpcyByZXF1aXJlbWVudHMuDQoNCi0gU2VjdGlvbiAzLjI6 IEl0J3Mgbm90IGNsZWFyIHRvIG1lIGhvdyBTRVNTX1RFUk0gdHJhbnNsYXRlcyB0byBncmFjZWZ1 bCBUTFMgdGVybWluYXRpb24gKHRvIGF2b2lkIHRydW5jYXRpb24gYXR0YWNrcykuIFRoZSBzdGF0 ZSBtYWNoaW5lIGRpYWdyYW0gb3V0bGluZWQgaW4gU2VjdGlvbiAzLjMgc3VnZ2VzdHMgdGhhdCBT RVNTX1RFUk0sIG9uY2UgbmVnb3RpYXRlZCwgZG9lcyBpbXBseSB0aGUgZW5kIG9mIHRoZSBkYXRh IHRyYW5zZmVyLiBJdCB0aGVyZWZvcmUgc2VlbXMgcG9zc2libGUgZm9yIGFuIGF0dGFja2VyIHRv IHRydW5jYXRlIGRhdGEgc2VudCBiZXR3ZWVuIHJlY2VpcHQgb2YgU0VTU19URVJNIGFuZCBUQ1Ag RklOIGJ5IHNpbXBseSBjbG9zaW5nIHRoZSBUQ1AgY29ubmVjdGlvbi4gSXQgd291bGQgYmUgZ29v ZCB0byByZXF1aXJlIHVzZSBvZiBhIFRMUyBjbG9zdXJlIGFsZXJ0IHdoZW4gZmluaXNoZWQgdG8g YXZvaWQgdGhpcyB0eXBlIG9mIHRydW5jYXRpb24uIChNYXliZSBCUCBwcmV2ZW50cyB0aGlzIGJ5 IG1hcmtpbmcgZGF0YSB0cmFuc2ZlciBsZW5ndGhzLiBIb3dldmVyLCBldmVuIGlmIHRoYXQncyB0 aGUgY2FzZSwgcHJvcGVyIHVzZSBvZiBUTFMgc2VlbXMgcHJ1ZGVudC4pDQrigItCUzogSSBhZGRl ZCBhIHJlcXVpcmVtZW50IHRvIHNlbmQgQ2xvc3VyZSBBbGVydCBiZWZvcmUgc2h1dHRpbmcgZG93 biB0aGUgVExTIHNlc3Npb24uIFRoZSBUQ1BDTCBtZXNzYWdlcyBhcmUgYWxsIGZpeGVkLWxlbmd0 aCBvciBzZWxmLWluZGljYXRlZCBsZW5ndGggc28gdGhlcmUgaXMgbm8gcG9zc2liaWxpdHkgb2Yg ZGF0YSB0cnVuY2F0aW9uLg0KDQotIFNlY3Rpb24gNCwgZmlyc3QgcGFyYWdyYXBoOiBJZiBlbnRp dGllcyBhcmUgZW5jb3VyYWdlZCB0byBrZWVwIHNlc3Npb25zIGFsaXZlIGZvciBhcyBsb25nIGFz IHBvc3NpYmxlLCBndWlkYW5jZSBvbiBob3cgdG8gdXBkYXRlIFRMUyBrZXlpbmcgbWF0ZXJpYWwg KHZpYSBrZXkgdXBkYXRlcyBvciBleHBsaWNpdGx5IHRlYXJpbmcgZG93biB0aGUgY29ubmVjdGlv biBhbmQgc3RhcnRpbmcgYW5ldykgc2VlbXMgcHJ1ZGVudC4gVExTIGhhcyBhIGJvdW5kIG9uIGhv dyBtdWNoIGRhdGEgY2FuIGJlIGVuY3J5cHRlZCB1bmRlciBvbmUga2V5Lg0KQlM6IEkgYWRkZWQg dGV4dCB0byBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIHRvIGluY2x1ZGUgYSByZWZl cmVuY2UgYWJvdXQga2V5IHVzZSBsaW1pdHMgYW5kIGtleSB1cGRhdGVzLg0KDQotIFNlY3Rpb24g NDogVGhpcyB0ZXh0Og0KDQogIE9uY2UgYSBUQ1AgY29ubmVjdGlvbiBpcyBlc3RhYmxpc2hlZCwg ZWFjaCBlbnRpdHkgTVVTVCBpbW1lZGlhdGVseQ0KICB0cmFuc21pdCBhIGNvbnRhY3QgaGVhZGVy IG92ZXIgdGhlIFRDUCBjb25uZWN0aW9uLg0KDQpzdWdnZXN0cyB0aGF0IFRMUyBkb2VzICpub3Qq IHByb2NlZWQgYXMgbm9ybWFsIHVwb24gVENQIGNvbm5lY3Rpb24gZXN0YWJsaXNobWVudC4gVGhp cyBpcyBxdWl0ZSBwcm9ibGVtYXRpYywgc2luY2UgYW55IGFjdGl2ZSBhdHRhY2tlciBjYW4gc2lt cGx5IG11Y2sgd2l0aCB0aGUgQ29udGFjdEhlYWRlciBDQU5fVExTIGJpdCB0byBkaXNhYmxlIFRM UywgcmlnaHQ/IElzIHRoaXMgdGhyZWF0IG5vdCBjb25zaWRlcmVkIGluIHNjb3BlPyBSZWxhdGVk bHksIHdoYXQgaXMgdGhlIHRocmVhdCBtb2RlbD8gKFNTTCBzdHJpcHBpbmcgaXMgbWVudGlvbmVk IGluIFNlY3Rpb24gOCwgYnV0IHdpdGhvdXQgbWVudGlvbiBvZiBhIHRocmVhdCBtb2RlbC4pICJT ZWN1cmUiIHNlc3Npb25zIHN1YmplY3QgdG8gYWN0aXZlIGRvd25ncmFkZSBkbyBub3Qgb2ZmZXIg bXVjaCBpbiB0aGUgd2F5IG9mIHNlY3VyaXR5LCBhbmQgdGhlIGRvY3VtZW50IHNob3VsZCBhY2tu b3dsZWRnZSB0aGF0IGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucy4gQ29uY3JldGVseSwg aG93IGFib3V0IHRoZSBmb2xsb3dpbmcgdGV4dCB0byByZXBsYWNlIHRoZSBzZWNvbmQgcGFyYWdy YXBoIGluIFNlY3Rpb24gOD8NCg0KICAgVENQQ0wgZG9lcyBub3QgcHJvdGVjdCBhZ2FpbnN0IGFj dGl2ZSBuZXR3b3JrIGF0dGFja2Vycy4gSW4gcGFydGljdWxhciwgYW4NCiAgIGFjdGl2ZSBtYW4t aW4tdGhlLW1pZGRsZSBhdHRhY2tlcnMgdG8gc2V0IHRoZSBDQU5fVExTIGZsYWcgdG8gMCBvbiBl aXRoZXINCiAgIHNpZGUgb2YgYSBUQ1BDTCBDb250YWN0SGVhZGVyIGV4Y2hhbmdlLiAgVGhpcyBs ZWFkcyB0byB0aGUgIlNTTCBTdHJpcHBpbmciDQogICBhdHRhY2sgZGVzY3JpYmVkIGluIFtSRkM3 NDU3XS4NCg0KICAgSWYgVExTIGlzIGRlc2lyZWQgZm9yIHVzZSBvbiBhbnkgVENQQ0wgbmV0d29y aywgaXQgaXMgc3Ryb25nbHkgZW5jb3VyYWdlZCB0aGF0DQogICB0aGUgc2VjdXJpdHkgcG9saWN5 IGRpc2FsbG93IHVzZSBvZiBUQ1BDTCB3aGVuICJFbmFibGUgVExTIiBpcw0KICAgbmVnb3RpYXRl ZCB0byBmYWxzZS4gIFRoaXMgcmVxdWlyZXMgdGhhdCB0aGUgVExTIGhhbmRzaGFrZSBvY2N1cnMs DQogICByZWdhcmRsZXNzIG9mIHRoZSBwb2xpY3ktZHJpdmVuIHBhcmFtZXRlcnMgb2YgdGhlIGhh bmRzaGFrZSBhbmQNCiAgIHBvbGljeS1kcml2ZW4gaGFuZGxpbmcgb2YgdGhlIGhhbmRzaGFrZSBv dXRjb21lLg0KQlM6IFlvdXIgc3RhdGVtZW50cyBhcmUgZGVmaW5pdGVseSB0cnVlLiBUaGUgcHVy cG9zZSBvZiB0aGUgQ0FOX1RMUyBmbGFnIGhhcyBiZWVuIGNsYXJpZmllZCBpbiBTZWN0aW9uIDQu MiAiQ29udGFjdCBIZWFkZXIiLCBhbmQgU2VjdGlvbiA4IGlzIHVwZGF0ZWQgdG8gaGF2ZSBhIHN0 cm9uZ2VyIHJlY29tbWVuZGF0aW9uIGZvciBwb2xpY3kgdG8gcmVxdWlyZSBUTFMgdXNlIHdoZW4g VExTIGlzIGF2YWlsYWJsZS4NClRoZSBwdXJwb3NlIG9mIHRoZSBDQU5fVExTIGZsYWcgaXMgdG8g YWxsb3cgdGhlIHVzZSBvZiBUQ1BDTCBvbiBlbnRpdGllcyB3aGljaCBzaW1wbHkgZG8gbm90IGhh dmUgYSBUTFMgaW1wbGVtZW50YXRpb24gYXZhaWxhYmxlLiBUaGlzIHdhcyBhIHN0YXRlZCBnb2Fs IG9mIHRoZSBEVE4gV0cgZHVlIHRvIHRoZSBkZXNpcmUgdG8gdXNlIFRDUENMIGluIGVudmlyb25t ZW50cyB3aGVyZSB0aGUgZW50aXRpZXMgYXJlIGNvbnN0cmFpbmVkIChUTFMgaXMgdW5hdmFpbGFi bGUpIGJ1dCB0aGUgbmV0d29yayBpcyB0cnVzdGVkLg0KUmVnYXJkaW5nIHRoZSB0aHJlYXQgbW9k ZWwsIHRoaXMgaXMgc29tZXRoaW5nIEkgbmVlZCB0byBsb29rIGludG8gYW5kIGZpbmQgc29tZSBl eGFtcGxlcyBvZiBpbiBvdGhlciBSRkNzLg0KDQotIFNlY3Rpb24gNC40LjI6IFdoeSBpcyB0aGUg cmVjb21tZW5kYXRpb24gdGhhdCBlbnRpdGllcyAiU0hPVUxEIHRlcm1pbmF0ZSB0aGUgc2Vzc2lv biIgaWYgdGhlIHBlZXIncyBjZXJ0aWZpY2F0ZSBpcyB1bnRydXN0ZWQsIHJhdGhlciB0aGFuICJN VVNUIHRlcm1pbmF0ZSB0aGUgc2Vzc2lvbiI/IEluIHdoYXQgY2lyY3Vtc3RhbmNlcyB3b3VsZCBh biBlbnRpdHkgbm90IHdhbnQgdG8gdGVybWluYXRlIHRoZSBjb25uZWN0aW9uPyAoTGF0ZXIgdGV4 dCBtZW50aW9ucyB0aGF0IHRoaXMgbWF5IGJlIGFsbG93ZWQgYnkgInNlY3VyaXR5IHBvbGljeSwi IGluIHdoaWNoIGNhc2Ugd2Ugc2hvdWxkIG1lbnRpb24gdGhhdCBoZXJlLikNCkJTOiBJIHVwZGF0 ZWQgdGhlc2UgcmVxdWlyZW1lbnRzIHRvIFNIQUxMIGFuZCBtYWRlIHN1cmUgdGhleSBhcmUgYWxs IGNvbmRpdGlvbmVkIG9uIHBvbGljeSBydWxlcy4NCg0KLSBTZWN0aW9uIDQuNC4yLCBmb3VydGgg cGFyYWdyYXBoOiBXaHkgaXMgaG9zdCBuYW1lIHZhbGlkYXRpb24gZG9uZSAqYWZ0ZXIqIFRMUyBj b21wbGV0ZXMsIHJhdGhlciB0aGFuIGR1cmluZyB0aGUgY29ubmVjdGlvbj8gVGhpcyBzZWVtcyB3 cm9uZywgdGhvdWdoIEkgc3VzcGVjdCBJJ20gbWlzdW5kZXJzdGFuZGluZyB0aGUgZGV0YWlscy4N CkJTOiBJIHVwZGF0ZWQgdGhlIHRleHQgdG8gcmVhZCAiRWl0aGVyIGR1cmluZyBvciBpbW1lZGlh dGVseSBhZnRlciB0aGUgVExTIGhhbmRzaGFrZS4uLiIgVGhlIG9ubHkgcmVhc29uIGZvciB0aGlz IGlzIHNvbWUgVExTIGltcGxlbWVudGF0aW9ucyBhbGxvdyBpbnRlcnJ1cHRpbmcgdGhlIGhhbmRz aGFrZSBidXQgc29tZSBvbmx5IGFsbG93IGluc3BlY3RpbmcgdGhlIHJlc3VsdHMgb2YgdGhlIGhh bmRzaGFrZS4NCg0KLSA0LjcsIEVuYWJsZSBUTFM6IElmIHNlY3VyaXR5IHBvbGljeSBhbGxvd3Mg dGhlIGFic2VuY2Ugb2YgVExTLCB3aHkgbm90IGp1c3QgYWx3YXlzIHVzZSBUTFMgYW5kIGhhdmUg dGhhdCBwb2xpY3kgdHVuZSBUTFMgcGVlciBhdXRoZW50aWNhdGlvbj8gKFNlZSBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNzg1OCNzZWN0aW9uLTQuMSBmb3IgYW4gZXhhbXBsZSBvZiB0 aGlzLikgSXQgc2VlbXMgc3RyYW5nZSB0aGF0IG9wcG9ydHVuaXN0aWMgc2VjdXJpdHkgaXMgc3Vw cG9ydGVkIChhbmQgZGVzaXJlZCBhcyBhIGZlYXR1cmU/KSB5ZXQgbm90IGFsd2F5cyB1c2VkLg0K QlM6IFBlciB0aGUgZWFybGllciByZXNwb25zZSB0byBTZWN0aW9uIDQgdGV4dCwgdGhlIHJlYXNv biB0byBhbGxvdyBub24tVExTIHNlc3Npb25zIGlzIHB1cmVseSBmb3IgY29uc3RyYWluZWQgZW50 aXRpZXMuIFRoZSB0ZXh0IGluIFNlY3Rpb24gNC4yIGFuZCBTZWN0aW9uIDggYXJlIHVwZGF0ZWQg dG8gY2xhcmlmeSB0aGUgQ0FOX1RMUyBmbGFnIHRvIGluZGljYXRlIHRoZSBwcmVzZW5jZSBvZiBU TFMgaW4gdGhlIG5ldHdvcmsgc3RhY2ssIG5vdCByZWFsbHkgYSBjb25maWd1cmF0aW9uIHBhcmFt ZXRlci4NCg0KLSBTZWN0aW9uIDg6IEkgc2VlIG5vIHJlYXNvbiB3aHkgb25lIHdvdWxkIHdhbnQg dG8gdXNlIFRMUyBmb3IgYXV0aGVudGljYXRpb24gd2l0aG91dCBhbnkgZm9ybSBvZiBjb25maWRl bnRpYWxpdHkuIEkgd291bGQgcmVtb3ZlIHRleHQgcmVmZXJlbmNpbmcgdGhpcyB1c2UgY2FzZS4N CkJTOiBJIHJlbW92ZWQgdGhpcyB0ZXh0IHRvIGF2b2lkIGNvbmZ1c2lvbi4NCg0KLSBTZWN0aW9u IDg6IEluIGRlc2NyaWJpbmcgdm9sdW1ldHJpYyBEb1MgYXR0YWNrcywgaXQgbWlnaHQgaGVscCB0 byBjb25zaWRlciB0aGUgIm9wcG9zaXRlIiBzb3J0IG9mIGF0dGFjaywgZS5nLiwgc2ltaWxhciB0 byB3aGF0IHRoZSBIVFRQVC8yIGRhdGEgZHJpYmJsZSBhdHRhY2sgZXhwbG9pdGVkPyAoaHR0cHM6 Ly9jdmUubWl0cmUub3JnL2NnaS1iaW4vY3ZlbmFtZS5jZ2k/bmFtZT1DVkUtMjAxOS05NTExKQ0K QlM6IFRoaXMgaXMgYSBnb29kIGNhdGNoLCBJIGFkZGVkIFNlY3Rpb24gOCB0ZXh0IHRvIHdhcm4g YWdhaW5zdCBhY2NlcHRpbmcgdG9vLXNtYWxsIFNlZ21lbnQgTVJVIG9yIFRyYW5zZmVyIE1SVSBw YXJhbWV0ZXJzLg0KDQpOaXRzOg0KLSBTZWN0aW9uIDIuMSwgVENQIENvbm5lY3Rpb246IHR5cG8g aW4gImFuZCBvdGhlciBzdGF0ZXMgYXNzb2NpYXRpb24iIChzaG91bGQgYmUgYXNzb2NpYXRlZD8p DQpCUzogRml4ZWQgdGhpcyB0eXBvLg0KLSBTZWN0aW9uIDIuMSwgVHJhbnNtaXNzaW9uIEludGVy bWVkaWF0ZSBQcm9ncmVzczogdHlwbyAidHJhbnNmZXJyIiAoYW5kIGVsc2V3aGVyZSkNCkJTOiBG aXhlZCB0aGlzIHR5cG8uDQotIEluY29uc2lzdGVudCBub3RhdGlvbiBvZiBTRVNTX1RFUk0gKGl0 J3MgcmVmZXJyZWQgdG8gYXMgU0VTU1RFUk0gaW4gbG90cyBvZiBwbGFjZXMpDQpCUzogVGhlICJT RVNTX1RFUk0iIHdhcyBhIG1lc3NhZ2Ugd2hpbGUgYSAiU0VTU1RFUk0iIHdhcyBhbiBhY3Rpdml0 eS4gSSByZW5hbWVkIHRoZSBhY3Rpdml0eSB0byAiU1QiIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCBv dGhlciBhYmJyZXZpYXRlZCBhY3Rpdml0eSBuYW1lcy4NCi0gU2VjdGlvbiAzLjQsIGxhc3QgcGFy YWdyYXBoOiB0eXBvICJmcm9tIGZyb20iDQpCUzogRml4ZWQgdGhpcyB0eXBvLg0KLSBTZWN0aW9u OiB0eXBvICJuZWdvdGF0aW5nIg0KQlM6IEZpeGVkIHNldmVyYWwgb2YgdGhpcyB0eXBvLg0KDQo= --_000_MN2PR13MB3520A9981F64A77740856D669F4A0MN2PR13MB3520namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPiBQIHttYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowO30gPC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGRpcj0ibHRyIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBD YWxpYnJpLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNv bG9yOiByZ2IoMCwgMCwgMCk7Ij4NCjxkaXYgc3R5bGU9ImNvbG9yOmJsYWNrOyBmb250LXNpemU6 MTJwdDsgZm9udC1mYW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZiI+DQpD aHJpc3RvcGhlciw8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGli cmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6 IHJnYigwLCAwLCAwKTsiPg0KQSBuZXcgZHJhZnQgaGFzIGJlZW4gcG9zdGVkIFsxXSB3aGljaCBz aG91bGQgYWRkcmVzcyBhbGwgb2YgeW91ciBjb21tZW50cyBvbiB0aGUgLTE1IGRyYWZ0LiBNb3N0 IG9mIHRoZSBjaGFuZ2VzIFsyXSBhcmUgdG8gZWl0aGVyIGZpeCB0eXBvcyBhbmQgaW5jb25zaXN0 ZW5jaWVzIG9yIHRvIGFkZCByZXF1aXJlbWVudHMgc3VwcG9ydGluZyBUTFMgdXNlIGFuZCB0aHJl YXQgbW9kZWxpbmcuPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgQXJp YWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAs IDAsIDApOyI+DQpPdXIgQUQgaGFzIHJlcXVlc3RlZCBhIHJlLXJldmlldyBvZiB0aGUgbmV3IGRy YWZ0IHRvIHZlcmlmeSB0aGF0IHRoZXJlIGFyZSBubyBtb3JlIGlzc3VlcyBwcmVzZW50LiBXb3Vs ZCB5b3UgYmUgYWJsZSB0byByZXZpZXcgdGhlIG5ldyBkcmFmdCB2ZXJzaW9uPzwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KVGhhbmsgeW91LDwv ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2Es IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KQnJp YW4gUy48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBBcmlh bCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiByZ2IoMCwg MCwgMCk7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmks IEFyaWFsLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJn YigwLCAwLCAwKTsiPg0KWzFdIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWR0bi10Y3BjbHY0LTE2IiBpZD0iTFBOb0xQMTMzODY3Ij4NCmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWR0bi10Y3BjbHY0LTE2PC9hPjxicj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIEFyaWFsLCBIZWx2ZXRpY2EsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KWzJdIDxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1pZXRmLWR0bi10 Y3BjbHY0LTE1JmFtcDt1cmwyPWRyYWZ0LWlldGYtZHRuLXRjcGNsdjQtMTYmYW1wO2RpZmZ0eXBl PS0taHRtbCIgaWQ9IkxQbG5rOTI4ODI4Ij4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMT1kcmFmdC1pZXRmLWR0bi10Y3BjbHY0LTE1JmFtcDt1cmwyPWRyYWZ0LWlldGYtZHRuLXRj cGNsdjQtMTYmYW1wO2RpZmZ0eXBlPS0taHRtbDwvYT48YnI+DQo8L2Rpdj4NCjxkaXYgaWQ9ImFw cGVuZG9uc2VuZCI+PC9kaXY+DQo8aHIgc3R5bGU9ImRpc3BsYXk6aW5saW5lLWJsb2NrO3dpZHRo Ojk4JSIgdGFiaW5kZXg9Ii0xIj4NCjxkaXYgaWQ9ImRpdlJwbHlGd2RNc2ciIGRpcj0ibHRyIj48 Zm9udCBmYWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBzdHlsZT0iZm9udC1zaXplOjExcHQiIGNv bG9yPSIjMDAwMDAwIj48Yj5Gcm9tOjwvYj4gQnJpYW4gU2lwb3MgJmx0O0JTaXBvc0Bya2YtZW5n LmNvbSZndDs8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBOb3ZlbWJlciAxMywgMjAxOSAx MDo1Mzxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0b3BoZXIgV29vZCAmbHQ7Y2F3QGhlYXBpbmdiaXRz Lm5ldCZndDs7IHNlY2RpckBpZXRmLm9yZyAmbHQ7c2VjZGlyQGlldGYub3JnJmd0Ozxicj4NCjxi PkNjOjwvYj4gbGFzdC1jYWxsQGlldGYub3JnICZsdDtsYXN0LWNhbGxAaWV0Zi5vcmcmZ3Q7OyBk cmFmdC1pZXRmLWR0bi10Y3BjbHY0LmFsbEBpZXRmLm9yZyAmbHQ7ZHJhZnQtaWV0Zi1kdG4tdGNw Y2x2NC5hbGxAaWV0Zi5vcmcmZ3Q7OyBkdG5AaWV0Zi5vcmcgJmx0O2R0bkBpZXRmLm9yZyZndDs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtMYXN0LUNhbGxdIFNlY2RpciBsYXN0IGNhbGwgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtZHRuLXRjcGNsdjQtMTU8L2ZvbnQ+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPC9kaXY+DQo8c3R5bGUgdHlwZT0idGV4dC9jc3MiIHN0eWxlPSJkaXNwbGF5Om5vbmUiPg0K PCEtLQ0KcA0KCXttYXJnaW4tdG9wOjA7DQoJbWFyZ2luLWJvdHRvbTowfQ0KLS0+DQo8L3N0eWxl Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLEFyaWFs LEhlbHZldGljYSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTJwdDsgY29sb3I6cmdiKDAsMCwwKSI+ DQpDaHJpc3RvcGhlciw8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksQXJp YWwsSGVsdmV0aWNhLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMnB0OyBjb2xvcjpyZ2IoMCwwLDAp Ij4NClRoYW5rIHlvdSBmb3IgdGhlc2UgY29tbWVudHMuIE15IHJlc3BvbnNlcyBhcmUgaW5saW5l IGJlbG93IHdpdGggcHJlZml4ICZxdW90O0JTOiAmcXVvdDsuIEkgaGF2ZSBiZWVuIG1ha2luZyBl ZGl0cyB0byBhIGZ1dHVyZSBkcmFmdCB3aGljaCBpcyBub3QgeWV0IHVwbG9hZGVkLjxicj4NCjwv ZGl2Pg0KPGRpdiBpZD0ieF9hcHBlbmRvbnNlbmQiPjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6Q2FsaWJyaSxBcmlhbCxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsgZm9udC1zaXplOjEycHQ7 IGNvbG9yOnJnYigwLDAsMCkiPg0KPGJyPg0KPC9kaXY+DQo8aHIgdGFiaW5kZXg9Ii0xIiBzdHls ZT0iZGlzcGxheTppbmxpbmUtYmxvY2s7IHdpZHRoOjk4JSI+DQo8ZGl2IGlkPSJ4X2RpdlJwbHlG d2RNc2ciIGRpcj0ibHRyIj48Zm9udCBmYWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBjb2xvcj0i IzAwMDAwMCIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48Yj5Gcm9tOjwvYj4gQ2hyaXN0b3BoZXIg V29vZCAmbHQ7Y2F3QGhlYXBpbmdiaXRzLm5ldCZndDs8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVz ZGF5LCBOb3ZlbWJlciA2LCAyMDE5IDIwOjU3PGJyPg0KPGI+VG86PC9iPiBzZWNkaXJAaWV0Zi5v cmcgJmx0O3NlY2RpckBpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IGxhc3QtY2FsbEBpZXRm Lm9yZyAmbHQ7bGFzdC1jYWxsQGlldGYub3JnJmd0OzsgZHJhZnQtaWV0Zi1kdG4tdGNwY2x2NC5h bGxAaWV0Zi5vcmcgJmx0O2RyYWZ0LWlldGYtZHRuLXRjcGNsdjQuYWxsQGlldGYub3JnJmd0Ozsg ZHRuQGlldGYub3JnICZsdDtkdG5AaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbTGFzdC1DYWxsXSBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWR0bi10 Y3BjbHY0LTE1PC9mb250Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i eF9Cb2R5RnJhZ21lbnQiPjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFw dCI+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+T29wcy4gRGF0YXRyYWNrZXIgYnV0Y2hlcmVk IHRoZSBmb3JtYXR0aW5nLiBMZXQncyB0cnkgdGhhdCBhZ2Fpbjo8YnI+DQo8YnI+DQp+fn48YnI+ DQo8YnI+DQpSZXZpZXdlcjogQ2hyaXN0b3BoZXIgV29vZDxicj4NClJldmlldyByZXN1bHQ6IEhh cyBJc3N1ZXM8YnI+DQo8YnI+DQpDb21tZW50czo8YnI+DQotIFNlY3Rpb24gMS4xLCBmb3VydGgg YnVsbGV0OiBJIGFzc3VtZSBjZXJ0aWZpY2F0ZSByZXZvY2F0aW9uIGlzIGFsc28gb3V0IG9mIHNj b3BlLiBJZiBzbywgbGlzdGluZyB0aGlzIGV4cGxpY2l0bHkgbWlnaHQgYmUgdXNlZnVsLiBJZiBu b3QsIHdoeSBub3Q/IFJlbGF0ZWRseSwgaXMgcHJlLXNoYXJlZCBrZXkgYXV0aGVudGljYXRpb24g c3VwcG9ydGVkPyBJZiBzbywgcGVyaGFwcyB3ZSBzaG91bGQgbWVudGlvbiB0aGF0IHRoaXMgdG9v IGlzIG91dA0KIG9mIHNjb3BlPzwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJjb2xvcjpyZ2IoMTIsMTAwLDE5MikiPkJTOiBJIGFkZGVkIGV4cGxpY2l0IG91dC1v Zi1zY29wZSBpbmRpY2F0aW9uIGZvciBib3RoIHJldm9jYXRpb24gYW5kIFBTSyAoYW5kIG90aGVy IG5vbi1jZXJ0aWZpY2F0ZSkgdXNlLjwvc3Bhbj48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Inhf UGxhaW5UZXh0Ij48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9InhfUGxhaW5UZXh0Ij4tIElmIFRM UyBzaXRzIGJlbG93IFRDUENMIGFuZCBpZiByZXN1bXB0aW9uIGlzIHVzZWQsIHdoYXQgaXMgdGhl IGRlZmluaXRpb24gb2YgYSBzZXNzaW9uJ3MgbGlmZXRpbWU/IElzIGl0IHN0aWxsIGJvdW5kIHRv IHRoZSB1bmRlcmx5aW5nIFRDUCBjb25uZWN0aW9uIGxpZmV0aW1lPyBJIHdvdWxkIHN1Z2dlc3Qg dGhhdCB0aGUgZGVmaW5pdGlvbiBiZSBnZW5lcmFsaXplZCB0byBhY2NvbW1vZGF0ZSBUTFMsDQog ZS5nLiwgcGVyaGFwcyB0aGUgbGlmZXRpbWUgaXMgYm91bmQgdG8gdGhlIHVuZGVybHlpbmcgdHJh bnNwb3J0IHN0YXRlIGxpZmV0aW1lLiBSZWxhdGVkbHksIGlzIFRMUyBzZXNzaW9uIHJlc3VtcHRp b24gc3VwcG9ydGVkIChvciBlbmNvdXJhZ2VkKT8gV2hlbiBkaXNjdXNzaW5nIFRMUyBzZXNzaW9u IGVzdGFibGlzaG1lbnQgaW4gU2VjdGlvbiA0LCB0aGlzIHNlZW1zIHRvIGJlIG9taXR0ZWQuPC9k aXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigxMiwx MDAsMTkyKSI+QlM6IEkgYWRkZWQgdGV4dCB0byBTZWN0aW9uIDQgdG8gaW5kaWNhdGUgYm90aCB0 aGUgbGlmZXRpbWUgb2YgVExTIHNlc3Npb25zIGFuZCB0aGUgYWJpbGl0eSB0byBhdHRlbXB0IHRv IHJlc3VtZSBzZXNzaW9ucy48L3NwYW4+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWlu VGV4dCI+PGJyPg0KLSBTZWN0aW9uIDMuMiwgZmlyc3QgcGFyYWdyYXBoOiBXaGF0IGRvZXMgJnF1 b3Q7aW5pdGlhdGUgVExTIHNlY3VyaXR5JnF1b3Q7IG1lYW4sIGV4YWN0bHk/IERvZXMgdGhpcyBt ZWFuIHRoZSBpbml0aWF0b3Igc2VuZHMgYSBUTFMgQ2xpZW50SGVsbG8gdXBvbiBUQ1AgY29ubmVj dGlvbiBlc3RhYmxpc2htZW50LCBvciBvbmx5IGFmdGVyIHNvbWUgb3RoZXIgVENQQ0wgaGVhZGVy cyBhcmUgZXhjaGFuZ2VkPyBTaW1pbGFybHksIGlzIHRoZSBOb2RlIElEIHRyYW5zZmVycmVkDQog dXNlZCBpbiBhdXRoZW50aWNhdGluZyBzdWNoIGEgVExTIGNvbm5lY3Rpb24/IElmIHNvLCBob3c/ IElzIHRoZSBOb2RlIElEIHNlbnQgYXMgdGhlIFRMUyBTTkksIGFzIGhpbnRlZCBhdCBpbiBTZWN0 aW9uIDQuNC4xIGFuZCA0LjQuMiwgaXMgaXQgaW5jbHVkZWQgaW4gdGhlIHJlc3BvbmRlcidzIGNl cnRpZmljYXRlIFNBTiBsaXN0LCBldGM/IEkgdGhpbmsgc3BlY2lmaWMgZGV0YWlscyBhcmUgbmVl ZGVkIGhlcmUsIHBlcmhhcHMgd2l0aCBmb3J3YXJkDQogcG9pbnRlcnMgdG8gU2VjdGlvbiA0IGFz IG5lZWRlZC48L2Rpdj4NCjxkaXYgY2xhc3M9InhfUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6cmdiKDEyLDEwMCwxOTIpIj5CUzogSSByZXBocmFzZWQgdGhlIGZpcnN0IHBhcmFncmFwaCBh bmQgYWRkZWQgYSByZWZlcmVuY2UgdG8gU2VjdGlvbiA0LiBUaGUgdGV4dCBpbiBTZWN0aW9uIDMg aXMgc3VwcG9zZWQgdG8gYmUgaGlnaGVyLWxldmVsIGFuZCBpbmZvcm1hdGl2ZSwgd2hlcmUgU2Vj dGlvbiA0IGlzIHJlcXVpcmVtZW50cy48L3NwYW4+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4 X1BsYWluVGV4dCI+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+LSBTZWN0 aW9uIDMuMjogSXQncyBub3QgY2xlYXIgdG8gbWUgaG93IFNFU1NfVEVSTSB0cmFuc2xhdGVzIHRv IGdyYWNlZnVsIFRMUyB0ZXJtaW5hdGlvbiAodG8gYXZvaWQgdHJ1bmNhdGlvbiBhdHRhY2tzKS4g VGhlIHN0YXRlIG1hY2hpbmUgZGlhZ3JhbSBvdXRsaW5lZCBpbiBTZWN0aW9uIDMuMyBzdWdnZXN0 cyB0aGF0IFNFU1NfVEVSTSwgb25jZSBuZWdvdGlhdGVkLCBkb2VzIGltcGx5IHRoZSBlbmQgb2YN CiB0aGUgZGF0YSB0cmFuc2Zlci4gSXQgdGhlcmVmb3JlIHNlZW1zIHBvc3NpYmxlIGZvciBhbiBh dHRhY2tlciB0byB0cnVuY2F0ZSBkYXRhIHNlbnQgYmV0d2VlbiByZWNlaXB0IG9mIFNFU1NfVEVS TSBhbmQgVENQIEZJTiBieSBzaW1wbHkgY2xvc2luZyB0aGUgVENQIGNvbm5lY3Rpb24uIEl0IHdv dWxkIGJlIGdvb2QgdG8gcmVxdWlyZSB1c2Ugb2YgYSBUTFMgY2xvc3VyZSBhbGVydCB3aGVuIGZp bmlzaGVkIHRvIGF2b2lkIHRoaXMgdHlwZSBvZiB0cnVuY2F0aW9uLg0KIChNYXliZSBCUCBwcmV2 ZW50cyB0aGlzIGJ5IG1hcmtpbmcgZGF0YSB0cmFuc2ZlciBsZW5ndGhzLiBIb3dldmVyLCBldmVu IGlmIHRoYXQncyB0aGUgY2FzZSwgcHJvcGVyIHVzZSBvZiBUTFMgc2VlbXMgcHJ1ZGVudC4pPC9k aXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigxMiwx MDAsMTkyKSI+4oCLQlM6IEkgYWRkZWQgYSByZXF1aXJlbWVudCB0byBzZW5kIENsb3N1cmUgQWxl cnQgYmVmb3JlIHNodXR0aW5nIGRvd24gdGhlIFRMUyBzZXNzaW9uLiBUaGUgVENQQ0wgbWVzc2Fn ZXMgYXJlIGFsbCBmaXhlZC1sZW5ndGggb3Igc2VsZi1pbmRpY2F0ZWQgbGVuZ3RoIHNvIHRoZXJl IGlzIG5vIHBvc3NpYmlsaXR5IG9mIGRhdGEgdHJ1bmNhdGlvbi48L3NwYW4+PGJyPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X1Bs YWluVGV4dCI+LSBTZWN0aW9uIDQsIGZpcnN0IHBhcmFncmFwaDogSWYgZW50aXRpZXMgYXJlIGVu Y291cmFnZWQgdG8ga2VlcCBzZXNzaW9ucyBhbGl2ZSBmb3IgYXMgbG9uZyBhcyBwb3NzaWJsZSwg Z3VpZGFuY2Ugb24gaG93IHRvIHVwZGF0ZSBUTFMga2V5aW5nIG1hdGVyaWFsICh2aWEga2V5IHVw ZGF0ZXMgb3IgZXhwbGljaXRseSB0ZWFyaW5nIGRvd24gdGhlIGNvbm5lY3Rpb24gYW5kIHN0YXJ0 aW5nIGFuZXcpIHNlZW1zDQogcHJ1ZGVudC4gVExTIGhhcyBhIGJvdW5kIG9uIGhvdyBtdWNoIGRh dGEgY2FuIGJlIGVuY3J5cHRlZCB1bmRlciBvbmUga2V5LiA8YnI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9InhfUGxhaW5UZXh0Ij48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx cHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMTIsMTAwLDE5MikiPkJTOiBJIGFkZGVkIHRleHQg dG8gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiB0byBpbmNsdWRlIGEgcmVmZXJlbmNl IGFib3V0IGtleSB1c2UgbGltaXRzIGFuZCBrZXkgdXBkYXRlcy48YnI+DQo8L3NwYW4+PC9zcGFu PjwvZm9udD48L2Rpdj4NCjxkaXYgY2xhc3M9InhfUGxhaW5UZXh0Ij48YnI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9InhfUGxhaW5UZXh0Ij4tIFNlY3Rpb24gNDogVGhpcyB0ZXh0Ojxicj4NCjxicj4N CiZuYnNwOyBPbmNlIGEgVENQIGNvbm5lY3Rpb24gaXMgZXN0YWJsaXNoZWQsIGVhY2ggZW50aXR5 IE1VU1QgaW1tZWRpYXRlbHk8YnI+DQombmJzcDsgdHJhbnNtaXQgYSBjb250YWN0IGhlYWRlciBv dmVyIHRoZSBUQ1AgY29ubmVjdGlvbi48YnI+DQo8YnI+DQpzdWdnZXN0cyB0aGF0IFRMUyBkb2Vz ICpub3QqIHByb2NlZWQgYXMgbm9ybWFsIHVwb24gVENQIGNvbm5lY3Rpb24gZXN0YWJsaXNobWVu dC4gVGhpcyBpcyBxdWl0ZSBwcm9ibGVtYXRpYywgc2luY2UgYW55IGFjdGl2ZSBhdHRhY2tlciBj YW4gc2ltcGx5IG11Y2sgd2l0aCB0aGUgQ29udGFjdEhlYWRlciBDQU5fVExTIGJpdCB0byBkaXNh YmxlIFRMUywgcmlnaHQ/IElzIHRoaXMgdGhyZWF0IG5vdCBjb25zaWRlcmVkIGluIHNjb3BlPyBS ZWxhdGVkbHksDQogd2hhdCBpcyB0aGUgdGhyZWF0IG1vZGVsPyAoU1NMIHN0cmlwcGluZyBpcyBt ZW50aW9uZWQgaW4gU2VjdGlvbiA4LCBidXQgd2l0aG91dCBtZW50aW9uIG9mIGEgdGhyZWF0IG1v ZGVsLikgJnF1b3Q7U2VjdXJlJnF1b3Q7IHNlc3Npb25zIHN1YmplY3QgdG8gYWN0aXZlIGRvd25n cmFkZSBkbyBub3Qgb2ZmZXIgbXVjaCBpbiB0aGUgd2F5IG9mIHNlY3VyaXR5LCBhbmQgdGhlIGRv Y3VtZW50IHNob3VsZCBhY2tub3dsZWRnZSB0aGF0IGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucy4NCiBDb25jcmV0ZWx5LCBob3cgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0IHRvIHJlcGxh Y2UgdGhlIHNlY29uZCBwYXJhZ3JhcGggaW4gU2VjdGlvbiA4Pzxicj4NCjxicj4NCiZuYnNwOyZu YnNwOyBUQ1BDTCBkb2VzIG5vdCBwcm90ZWN0IGFnYWluc3QgYWN0aXZlIG5ldHdvcmsgYXR0YWNr ZXJzLiBJbiBwYXJ0aWN1bGFyLCBhbjxicj4NCiZuYnNwOyZuYnNwOyBhY3RpdmUgbWFuLWluLXRo ZS1taWRkbGUgYXR0YWNrZXJzIHRvIHNldCB0aGUgQ0FOX1RMUyBmbGFnIHRvIDAgb24gZWl0aGVy IDxicj4NCiZuYnNwOyZuYnNwOyBzaWRlIG9mIGEgVENQQ0wgQ29udGFjdEhlYWRlciBleGNoYW5n ZS4mbmJzcDsgVGhpcyBsZWFkcyB0byB0aGUgJnF1b3Q7U1NMIFN0cmlwcGluZyZxdW90OyA8YnI+ DQombmJzcDsmbmJzcDsgYXR0YWNrIGRlc2NyaWJlZCBpbiBbUkZDNzQ1N10uJm5ic3A7IDxicj4N Cjxicj4NCiZuYnNwOyZuYnNwOyBJZiBUTFMgaXMgZGVzaXJlZCBmb3IgdXNlIG9uIGFueSBUQ1BD TCBuZXR3b3JrLCBpdCBpcyBzdHJvbmdseSBlbmNvdXJhZ2VkIHRoYXQ8YnI+DQombmJzcDsmbmJz cDsgdGhlIHNlY3VyaXR5IHBvbGljeSBkaXNhbGxvdyB1c2Ugb2YgVENQQ0wgd2hlbiAmcXVvdDtF bmFibGUgVExTJnF1b3Q7IGlzPGJyPg0KJm5ic3A7Jm5ic3A7IG5lZ290aWF0ZWQgdG8gZmFsc2Uu Jm5ic3A7IFRoaXMgcmVxdWlyZXMgdGhhdCB0aGUgVExTIGhhbmRzaGFrZSBvY2N1cnMsPGJyPg0K Jm5ic3A7Jm5ic3A7IHJlZ2FyZGxlc3Mgb2YgdGhlIHBvbGljeS1kcml2ZW4gcGFyYW1ldGVycyBv ZiB0aGUgaGFuZHNoYWtlIGFuZDxicj4NCiZuYnNwOyZuYnNwOyBwb2xpY3ktZHJpdmVuIGhhbmRs aW5nIG9mIHRoZSBoYW5kc2hha2Ugb3V0Y29tZS48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Inhf UGxhaW5UZXh0Ij48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPjxm b250IHNpemU9IjIiPjxzcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMTIsMTAwLDE5MikiPkJT OiBZb3VyIHN0YXRlbWVudHMgYXJlIGRlZmluaXRlbHkgdHJ1ZS4gVGhlIHB1cnBvc2Ugb2YgdGhl IENBTl9UTFMgZmxhZyBoYXMgYmVlbiBjbGFyaWZpZWQgaW4gU2VjdGlvbiA0LjIgJnF1b3Q7Q29u dGFjdCBIZWFkZXImcXVvdDssIGFuZCBTZWN0aW9uDQogOCBpcyB1cGRhdGVkIHRvIGhhdmUgYSBz dHJvbmdlciByZWNvbW1lbmRhdGlvbiBmb3IgcG9saWN5IHRvIHJlcXVpcmUgVExTIHVzZSB3aGVu IFRMUyBpcyBhdmFpbGFibGUuPC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48L2Rp dj4NCjxkaXYgY2xhc3M9InhfUGxhaW5UZXh0Ij48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExcHQiPjxmb250IHNpemU9IjIiPjxzcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpy Z2IoMTIsMTAwLDE5MikiPjxzcGFuPlRoZSBwdXJwb3NlIG9mIHRoZSBDQU5fVExTIGZsYWcgaXMg dG8gYWxsb3cgdGhlIHVzZSBvZiBUQ1BDTCBvbjwvc3Bhbj48c3Bhbj4gZW50aXRpZXMgd2hpY2gg c2ltcGx5IGRvIG5vdCBoYXZlIGEgVExTIGltcGxlbWVudGF0aW9uDQogYXZhaWxhYmxlLiBUaGlz IHdhcyBhIHN0YXRlZCBnb2FsIG9mIHRoZSBEVE4gV0cgZHVlIHRvIHRoZSBkZXNpcmUgdG8gdXNl IFRDUENMIGluIGVudmlyb25tZW50cyB3aGVyZSB0aGUgZW50aXRpZXMgYXJlIGNvbnN0cmFpbmVk IChUTFMgaXMgdW5hdmFpbGFibGUpIGJ1dCB0aGUgbmV0d29yayBpcyB0cnVzdGVkLjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9Q bGFpblRleHQiPjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGZv bnQgc2l6ZT0iMiI+PHNwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigxMiwxMDAsMTkyKSI+PHNw YW4+UmVnYXJkaW5nIHRoZSB0aHJlYXQgbW9kZWwsIHRoaXMgaXMgc29tZXRoaW5nIEkgbmVlZCB0 byBsb29rIGludG8gYW5kIGZpbmQgc29tZSBleGFtcGxlcyBvZiBpbiBvdGhlciBSRkNzLjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjxicj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0ieF9QbGFpblRleHQiPjxicj4NCi0gU2VjdGlvbiA0LjQuMjogV2h5IGlzIHRoZSByZWNv bW1lbmRhdGlvbiB0aGF0IGVudGl0aWVzICZxdW90O1NIT1VMRCB0ZXJtaW5hdGUgdGhlIHNlc3Np b24mcXVvdDsgaWYgdGhlIHBlZXIncyBjZXJ0aWZpY2F0ZSBpcyB1bnRydXN0ZWQsIHJhdGhlciB0 aGFuICZxdW90O01VU1QgdGVybWluYXRlIHRoZSBzZXNzaW9uJnF1b3Q7PyBJbiB3aGF0IGNpcmN1 bXN0YW5jZXMgd291bGQgYW4gZW50aXR5IG5vdCB3YW50IHRvIHRlcm1pbmF0ZSB0aGUgY29ubmVj dGlvbj8gKExhdGVyIHRleHQNCiBtZW50aW9ucyB0aGF0IHRoaXMgbWF5IGJlIGFsbG93ZWQgYnkg JnF1b3Q7c2VjdXJpdHkgcG9saWN5LCZxdW90OyBpbiB3aGljaCBjYXNlIHdlIHNob3VsZCBtZW50 aW9uIHRoYXQgaGVyZS4pPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+PGZvbnQgc2l6 ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48Zm9udCBzaXplPSIyIj48c3Bhbj48 Zm9udCBzaXplPSIyIj48c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6cmdiKDEyLDEwMCwxOTIpIj5C UzogSSB1cGRhdGVkIHRoZXNlIHJlcXVpcmVtZW50cyB0byBTSEFMTCBhbmQgbWFkZSBzdXJlIHRo ZXkgYXJlIGFsbCBjb25kaXRpb25lZCBvbiBwb2xpY3kgcnVsZXMuPC9zcGFuPjwvc3Bhbj48L2Zv bnQ+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i eF9QbGFpblRleHQiPjxicj4NCi0gU2VjdGlvbiA0LjQuMiwgZm91cnRoIHBhcmFncmFwaDogV2h5 IGlzIGhvc3QgbmFtZSB2YWxpZGF0aW9uIGRvbmUgKmFmdGVyKiBUTFMgY29tcGxldGVzLCByYXRo ZXIgdGhhbiBkdXJpbmcgdGhlIGNvbm5lY3Rpb24/IFRoaXMgc2VlbXMgd3JvbmcsIHRob3VnaCBJ IHN1c3BlY3QgSSdtIG1pc3VuZGVyc3RhbmRpbmcgdGhlIGRldGFpbHMuPC9kaXY+DQo8ZGl2IGNs YXNzPSJ4X1BsYWluVGV4dCI+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MXB0Ij48Zm9udCBzaXplPSIyIj48c3Bhbj48Zm9udCBzaXplPSIyIj48c3Bhbj48Zm9udCBzaXpl PSIyIj48c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6cmdiKDEyLDEwMCwxOTIpIj5CUzogSSB1cGRh dGVkIHRoZSB0ZXh0IHRvIHJlYWQgJnF1b3Q7RWl0aGVyIGR1cmluZyBvciBpbW1lZGlhdGVseSBh ZnRlciB0aGUgVExTIGhhbmRzaGFrZS4uLiZxdW90Ow0KIFRoZSBvbmx5IHJlYXNvbiBmb3IgdGhp cyBpcyBzb21lIFRMUyBpbXBsZW1lbnRhdGlvbnMgYWxsb3cgaW50ZXJydXB0aW5nIHRoZSBoYW5k c2hha2UgYnV0IHNvbWUgb25seSBhbGxvdyBpbnNwZWN0aW5nIHRoZSByZXN1bHRzIG9mIHRoZSBo YW5kc2hha2UuPC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250 Pjwvc3Bhbj48L2ZvbnQ+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+PGJy Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+LSA0LjcsIEVuYWJsZSBUTFM6IElm IHNlY3VyaXR5IHBvbGljeSBhbGxvd3MgdGhlIGFic2VuY2Ugb2YgVExTLCB3aHkgbm90IGp1c3Qg YWx3YXlzIHVzZSBUTFMgYW5kIGhhdmUgdGhhdCBwb2xpY3kgdHVuZSBUTFMgcGVlciBhdXRoZW50 aWNhdGlvbj8gKFNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc4 NTgjc2VjdGlvbi00LjEiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3ODU4I3NlY3Rp b24tNC4xPC9hPiBmb3IgYW4gZXhhbXBsZSBvZiB0aGlzLikgSXQgc2VlbXMgc3RyYW5nZSB0aGF0 IG9wcG9ydHVuaXN0aWMgc2VjdXJpdHkgaXMgc3VwcG9ydGVkIChhbmQgZGVzaXJlZCBhcyBhIGZl YXR1cmU/KSB5ZXQgbm90IGFsd2F5cyB1c2VkLjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRl eHQiPjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGZvbnQgc2l6 ZT0iMiI+PHNwYW4+PGZvbnQgc2l6ZT0iMiI+PHNwYW4+PGZvbnQgc2l6ZT0iMiI+PHNwYW4+PGZv bnQgc2l6ZT0iMiI+PHNwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigxMiwxMDAsMTkyKSI+QlM6 IFBlciB0aGUgZWFybGllciByZXNwb25zZSB0byBTZWN0aW9uIDQgdGV4dCwgdGhlIHJlYXNvbiB0 byBhbGxvdw0KIG5vbi1UTFMgc2Vzc2lvbnMgaXMgcHVyZWx5IGZvciBjb25zdHJhaW5lZCBlbnRp dGllcy4gVGhlIHRleHQgaW4gU2VjdGlvbiA0LjIgYW5kIFNlY3Rpb24gOCBhcmUgdXBkYXRlZCB0 byBjbGFyaWZ5IHRoZSBDQU5fVExTIGZsYWcgdG8gaW5kaWNhdGUgdGhlIHByZXNlbmNlIG9mIFRM UyBpbiB0aGUgbmV0d29yayBzdGFjaywgbm90IHJlYWxseSBhIGNvbmZpZ3VyYXRpb24gcGFyYW1l dGVyLjwvc3Bhbj48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48L3Nw YW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWlu VGV4dCI+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+LSBTZWN0aW9uIDg6 IEkgc2VlIG5vIHJlYXNvbiB3aHkgb25lIHdvdWxkIHdhbnQgdG8gdXNlIFRMUyBmb3IgYXV0aGVu dGljYXRpb24gd2l0aG91dCBhbnkgZm9ybSBvZiBjb25maWRlbnRpYWxpdHkuIEkgd291bGQgcmVt b3ZlIHRleHQgcmVmZXJlbmNpbmcgdGhpcyB1c2UgY2FzZS48YnI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9InhfUGxhaW5UZXh0Ij48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx cHQiPjxmb250IHNpemU9IjIiPjxzcGFuPjxmb250IHNpemU9IjIiPjxzcGFuPjxmb250IHNpemU9 IjIiPjxzcGFuPjxmb250IHNpemU9IjIiPjxzcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMTIs MTAwLDE5MikiPkJTOiBJIHJlbW92ZWQgdGhpcyB0ZXh0IHRvIGF2b2lkIGNvbmZ1c2lvbi48L3Nw YW4+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9u dD48L3NwYW4+PC9mb250Pjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPjxi cj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPi0gU2VjdGlvbiA4OiBJbiBkZXNj cmliaW5nIHZvbHVtZXRyaWMgRG9TIGF0dGFja3MsIGl0IG1pZ2h0IGhlbHAgdG8gY29uc2lkZXIg dGhlICZxdW90O29wcG9zaXRlJnF1b3Q7IHNvcnQgb2YgYXR0YWNrLCBlLmcuLCBzaW1pbGFyIHRv IHdoYXQgdGhlIEhUVFBULzIgZGF0YSBkcmliYmxlIGF0dGFjayBleHBsb2l0ZWQ/ICg8YSBocmVm PSJodHRwczovL2N2ZS5taXRyZS5vcmcvY2dpLWJpbi9jdmVuYW1lLmNnaT9uYW1lPUNWRS0yMDE5 LTk1MTEiPmh0dHBzOi8vY3ZlLm1pdHJlLm9yZy9jZ2ktYmluL2N2ZW5hbWUuY2dpP25hbWU9Q1ZF LTIwMTktOTUxMTwvYT4pPC9kaXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+PGZvbnQgc2l6 ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0Ij48Zm9udCBzaXplPSIyIj48c3Bhbj48 Zm9udCBzaXplPSIyIj48c3Bhbj48Zm9udCBzaXplPSIyIj48c3Bhbj48Zm9udCBzaXplPSIyIj48 c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6cmdiKDEyLDEwMCwxOTIpIj5CUzogVGhpcyBpcyBhIGdv b2QgY2F0Y2gsIEkgYWRkZWQgU2VjdGlvbiA4IHRleHQgdG8gd2FybiBhZ2FpbnN0IGFjY2VwdGlu Zw0KIHRvby1zbWFsbCBTZWdtZW50IE1SVSBvciBUcmFuc2ZlciBNUlUgcGFyYW1ldGVycy48L3Nw YW4+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9u dD48L3NwYW4+PC9mb250Pjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPjxi cj4NCk5pdHM6PGJyPg0KLSBTZWN0aW9uIDIuMSwgVENQIENvbm5lY3Rpb246IHR5cG8gaW4gJnF1 b3Q7YW5kIG90aGVyIHN0YXRlcyBhc3NvY2lhdGlvbiZxdW90OyAoc2hvdWxkIGJlIGFzc29jaWF0 ZWQ/KTwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPjxmb250IHNpemU9IjIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTFwdCI+PGZvbnQgc2l6ZT0iMiI+PHNwYW4+PGZvbnQgc2l6ZT0i MiI+PHNwYW4+PGZvbnQgc2l6ZT0iMiI+PHNwYW4+PGZvbnQgc2l6ZT0iMiI+PHNwYW4+PGZvbnQg c2l6ZT0iMiI+PHNwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigxMiwxMDAsMTkyKSI+QlM6IEZp eGVkIHRoaXMgdHlwby48L3NwYW4+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj48 L2ZvbnQ+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PGJyPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSJ4X1BsYWluVGV4dCI+LSBTZWN0aW9uIDIuMSwgVHJhbnNtaXNzaW9u IEludGVybWVkaWF0ZSBQcm9ncmVzczogdHlwbyAmcXVvdDt0cmFuc2ZlcnImcXVvdDsgKGFuZCBl bHNld2hlcmUpPGJyPg0KPGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0 Ij4NCjxkaXY+PGZvbnQgc2l6ZT0iMiI+PHNwYW4+PGZvbnQgc2l6ZT0iMiI+PHNwYW4+PGZvbnQg c2l6ZT0iMiI+PHNwYW4+PGZvbnQgc2l6ZT0iMiI+PHNwYW4+PGZvbnQgc2l6ZT0iMiI+PHNwYW4+ PGZvbnQgc2l6ZT0iMiI+PHNwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOnJnYigxMiwxMDAsMTkyKSI+ QlM6IEZpeGVkIHRoaXMgdHlwby48L3NwYW4+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjwv c3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PGJy Pg0KPC9kaXY+DQo8L3NwYW4+PC9mb250Pi0gSW5jb25zaXN0ZW50IG5vdGF0aW9uIG9mIFNFU1Nf VEVSTSAoaXQncyByZWZlcnJlZCB0byBhcyBTRVNTVEVSTSBpbiBsb3RzIG9mIHBsYWNlcyk8YnI+ DQo8Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQiPg0KPGRpdj48Zm9u dCBzaXplPSIyIj48c3Bhbj48Zm9udCBzaXplPSIyIj48c3Bhbj48Zm9udCBzaXplPSIyIj48c3Bh bj48Zm9udCBzaXplPSIyIj48c3Bhbj48Zm9udCBzaXplPSIyIj48c3Bhbj48Zm9udCBzaXplPSIy Ij48c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6cmdiKDEyLDEwMCwxOTIpIj5CUzogVGhlICZxdW90 O1NFU1NfVEVSTSZxdW90OyB3YXMgYSBtZXNzYWdlIHdoaWxlIGEgJnF1b3Q7U0VTU1RFUk0mcXVv dDsgd2FzIGFuIGFjdGl2aXR5LiBJIHJlbmFtZWQgdGhlIGFjdGl2aXR5DQogdG8gJnF1b3Q7U1Qm cXVvdDsgdG8gYmUgY29uc2lzdGVudCB3aXRoIG90aGVyIGFiYnJldmlhdGVkIGFjdGl2aXR5IG5h bWVzLjwvc3Bhbj48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48L3Nw YW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48YnI+DQo8L2Rpdj4NCjxkaXY+ PC9kaXY+DQo8L3NwYW4+PC9mb250Pi0gU2VjdGlvbiAzLjQsIGxhc3QgcGFyYWdyYXBoOiB0eXBv ICZxdW90O2Zyb20gZnJvbSZxdW90Ozxicj4NCjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTFwdCI+DQo8ZGl2Pjxmb250IHNpemU9IjIiPjxzcGFuPjxmb250IHNpemU9IjIi PjxzcGFuPjxmb250IHNpemU9IjIiPjxzcGFuPjxmb250IHNpemU9IjIiPjxzcGFuPjxmb250IHNp emU9IjIiPjxzcGFuPjxmb250IHNpemU9IjIiPjxzcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2Io MTIsMTAwLDE5MikiPkJTOiBGaXhlZCB0aGlzIHR5cG8uPC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PC9z cGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48L3Nw YW4+PC9mb250Pjxicj4NCjwvZGl2Pg0KPC9zcGFuPjwvZm9udD4tIFNlY3Rpb246IHR5cG8gJnF1 b3Q7bmVnb3RhdGluZyZxdW90OzwvZGl2Pg0KPGRpdiBjbGFzcz0ieF9QbGFpblRleHQiPjxmb250 IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdCI+DQo8ZGl2Pjxmb250IHNpemU9 IjIiPjxzcGFuPjxmb250IHNpemU9IjIiPjxzcGFuPjxmb250IHNpemU9IjIiPjxzcGFuPjxmb250 IHNpemU9IjIiPjxzcGFuPjxmb250IHNpemU9IjIiPjxzcGFuPjxmb250IHNpemU9IjIiPjxzcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMTIsMTAwLDE5MikiPkJTOiBGaXhlZCBzZXZlcmFsIG9m IHRoaXMgdHlwby48L3NwYW4+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2Zv bnQ+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+PGJyPg0KPC9kaXY+ DQo8ZGl2PjwvZGl2Pg0KPC9zcGFuPjwvZm9udD48YnI+DQo8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+ PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MN2PR13MB3520A9981F64A77740856D669F4A0MN2PR13MB3520namp_-- From semery@uccs.edu Mon Nov 25 14:31:11 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2410120F44; Mon, 25 Nov 2019 14:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgUfH9EWBMTL; Mon, 25 Nov 2019 14:31:09 -0800 (PST) Received: from exchange.uccs.edu (uccs-ex1.uccs.edu [128.198.1.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730E11208BF; Mon, 25 Nov 2019 14:30:45 -0800 (PST) Received: from mail-ed1-f51.google.com (209.85.208.51) by UCCS-EX1.uccs.edu (128.198.1.101) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 25 Nov 2019 15:30:43 -0700 Received: by mail-ed1-f51.google.com with SMTP id b5so14343965eds.12; Mon, 25 Nov 2019 14:30:44 -0800 (PST) X-Gm-Message-State: APjAAAUKzZWGqatz1iqEOMNQ5r4P0BVS72uT8QVuQblldHGy2nyiQ+SO WjtM44ydQOlE4zWtnMitU7CtFxVajb35CkrXZLM= X-Google-Smtp-Source: APXvYqy62aulwuFm07PFelK+XMq7YptFfnT+rF0PsBs33K92bcFphRGJjJwlKX4cVCdTZobbgRRCucMGzEA5EK8G7uo= X-Received: by 2002:aa7:d496:: with SMTP id b22mr21384248edr.122.1574721042595; Mon, 25 Nov 2019 14:30:42 -0800 (PST) MIME-Version: 1.0 From: "Shawn M. Emery" Date: Mon, 25 Nov 2019 15:30:31 -0700 X-Gmail-Original-Message-ID: Message-ID: To: secdir , Content-Type: multipart/alternative; boundary="0000000000005d465605983350cd" X-Originating-IP: [209.85.208.51] X-ClientProxiedBy: uccs-ex1.uccs.edu (128.198.1.101) To UCCS-EX1.uccs.edu (128.198.1.101) Archived-At: X-Mailman-Approved-At: Mon, 25 Nov 2019 14:35:39 -0800 Subject: [secdir] Review of draft-ietf-mpls-ldp-yang-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2019 22:34:30 -0000 --0000000000005d465605983350cd Content-Type: text/plain; charset="UTF-8" Reviewer: Shawn M. Emery Review result: Ready with nits 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 draft specifies a YANG model for the Multi-Protocol Label Switching (MPLS) Label Distribution Protocol (LDP). Network Configuration Protocol (NETCONF) and RESTCONF is used to mange network devices based on this model. The security considerations section does exist and for security and privacy concerns, discusses that the MTI for NETCONF is SSH and TLS for RESTCONF. For authorization, NETCONF and RESTCONF uses the Network Configuration Access Control Model (NACM). The section goes on to state that some data nodes and RPC operations in the YANG module are considered sensitive to various operations, but does not give guidance on which nodes or subtrees that would be affected. In the past, module specifications that I've reviewed have outlined each of these relevant items. The section finishes with the statement that the security properties of the base specifications, LDP, LDP IPv6, etc., also applies to this draft. I agree with the above assertions. General comments: None. Editorial comments: s/into following/into the following/ s/means and be read/should be read/ s/family"/family"./ s/VPN Forwarding and Routing/VPN Routing and Forwarding/ s/provides a mean/provides a means/ s/Neibgbor/Neighbor/ s/pereference/preference/ s/creatable\/ deletable/creatable\/deletable/ RESTCONF should be expanded on first ocurence. Shawn. -- --0000000000005d465605983350cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reviewer: Shawn M. EmeryReview result= :=C2=A0Ready with nits

I have reviewed this document as part of the secur= ity directorate's
ongoing effort to review all=C2=A0IETF=C2=A0documents bein= g processed by the IESG.
These comments were written primarily for the benefit= of the security
area directors. Document editors and WG chairs should treat the= se
co= mments just like any other last call comments.
<= br>
This draft specifies a= YANG model for the=C2=A0Multi-Protocol Lab= el
Switching (MPLS) Label Distribution Protocol (LDP).=C2=A0=C2=A0<= span style=3D"font-size:small">Network
Configuration Protocol (NETCONF) an= d RESTCONF is used
to mange network=C2=A0devices based on this model.=C2=A0=C2=A0

The security considerations section does = exist and for security
and privacy con= cerns,=C2=A0discusses=C2=A0that the M= TI for NETCONF is
SSH and TLS=C2=A0for RESTCONF.=C2=A0 For authorization, NETCONF
and RESTCONF uses th= e=C2=A0Network Configuration Access = Control
Model (NACM).

The section goes on to state that some data n= odes
and RPC operations in the YANG module are considered sensitive=
to va= rious operations,=C2=A0but does not = give guidance on which nodes
or subtrees that would=C2=A0be affected.=C2=A0 In the past, module specifications=
that I've reviewed have outlin= ed each of these relevant items.

The section finishes with the state= ment that the security
properties of the base specifications, LDP, LDP= IPv6, etc., also applies
to this draft.=C2=A0=C2=A0I agree with the above assertions.

General comments:

None.

Editorial= comments:

s/into following/into the following/
s/means and be read/should be read/
s/family"/family= "./
s/VPN Forwarding and Routing/VPN Routing and Forwar= ding/
s/provides a mean/provides a means/
<= div>s/Neibgbor/Neighbo= r/
s/= pereference/preference/
s/creatable\/ deletable/creatable\= /deletable/

RESTCONF should be expanded on first o= curence.

Shawn.
--
--0000000000005d465605983350cd-- From nobody Tue Nov 26 09:58:23 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8B3120A2D; Tue, 26 Nov 2019 09:58:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley via Datatracker To: Cc: lwip@ietf.org, draft-ietf-lwig-curve-representations.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Russ Housley Message-ID: <157479110201.13605.6894641490219218764@ietfa.amsl.com> Date: Tue, 26 Nov 2019 09:58:22 -0800 Archived-At: Subject: [secdir] Secdir early review of draft-ietf-lwig-curve-representations-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2019 17:58:22 -0000 Reviewer: Russ Housley Review result: Has Issues 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 authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-lwig-curve-representations-08 Reviewer: Russ Housley Review Date: 2019-11-26 IETF LC End Date: unknown IESG Telechat date: unknown Summary: Has Issues Major Concerns: I am confused by the first paragraph in Section 10. It says that "An object identifier is requested ...", but then code points for COSE and JOSE (not object identifiers) are requested in the subsections. I am confused by the second paragraph in Section 10. It says that "There is *currently* no further IANA action required ...". Please delete this paragraph. Minor Concerns: Requirements Language section is out of date. It should reference RFC 8174 in addition to RFC 2119, as follows: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Section 2 says: "... reuse of existing generic code ..."; I do not know what is meant by "generic". It either needs to be defined, reworded, or dropped. I note that elsewhere in the document "existing code" is used. I expected Section 9 to say something about public keys being unique identifiers of the private key holder. Some introduction text at the beginning of each Appendix would be very helpful. Please tell the reader what they will learn by delving into the subsections of the appendix. Nits: Section 4.2 says: "... at the end of hereof ...". This does not tell me anything useful. I suggest deleting this phrase. I suggest turning the numbered paragraphs in Section 5 into subsections. From nobody Tue Nov 26 11:54:47 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4641208E5; Tue, 26 Nov 2019 11:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6_SOE6gowyP; Tue, 26 Nov 2019 11:54:38 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD449120018; Tue, 26 Nov 2019 11:54:35 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id e187so17287608qkf.4; Tue, 26 Nov 2019 11:54:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=BMJHI5pTaajvetCSuv4xiig+mOMWowG7+MzTTFsMLmU=; b=qeobCG2kvpXdZOxHC5UMF1FlySxfXRa83HPcFpM/myiPakg/9Uc+c2nBfK0QqzCotK bti8olbHokcQCwv1jRCGSRJMYU+ImLpzgXytw+FQSqti2efZBOv/bGADxoeKKeIPqXls Qh1+ggvS3STMwN+0rdAEe6bO5QWRVk7i+6n6rfn27KGUS6TzwMvzqRvCqqT+xqxInilB 6Xpjk3wRVBjZsVhaj/5qNXpUzkVdrqFmCA4P1D+7JEa+MOn97yh2ZscHu9jnqWjguSZt lvwc/ATiXWDVxtaU3HxKlV0KUSBlPYtW0hAmSGazG3Z71AZzBXRlci9OG+bbaf6SXC9M grHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=BMJHI5pTaajvetCSuv4xiig+mOMWowG7+MzTTFsMLmU=; b=IHMHHbvKO/FwQYvOB7bTsbMJMHGoEg8sGi6OYcWXmH942yndyYPb8UQzqXKhFkj0k7 OJCdw0ev3z0cpSREV84mKrussQd02cjhI8Fp5xPWRb+W5+jKYVdS5kjYZg2gKeq31b0M hjEPZH9YErErPBQJw1/m9K47H/LXylCb47HWj8nOHZosgb/xiiy3teOvRR5CRQ4xxyLu 7tamquOXLGAU/dYizaJ4Nkna+1JgVdPgySTreq3NyK/zSAzboyuiTfl/8+YQCZ4Xg5sT FQPdFyNX9A5bH6j7zt129wAT06h+gah74eu5VBUKOpA/GnsZY+nBBDkwbIRqY4PjVe/f SbWg== X-Gm-Message-State: APjAAAWlEnp9g7ROw5oPk4ybL4uqfO2KC8EW8/J6b+YADMZdV69e/G4p A9WrTAxpPxwgdXBX8YxDKHDCkKCn X-Google-Smtp-Source: APXvYqwapFtabMQ/8oA3TrbblmbtMdXq/e5/zloL1InLDIvjLUIfDHpSYH1T3ANe3lc1A8AMaAmAeg== X-Received: by 2002:a37:9cd:: with SMTP id 196mr96837qkj.325.1574798074320; Tue, 26 Nov 2019 11:54:34 -0800 (PST) Received: from ?IPv6:2607:fea8:69f:fa3a:fc5f:12b:d173:619a? ([2607:fea8:69f:fa3a:fc5f:12b:d173:619a]) by smtp.gmail.com with ESMTPSA id d15sm5518286qke.55.2019.11.26.11.54.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Nov 2019 11:54:33 -0800 (PST) To: Russ Housley , secdir@ietf.org Cc: lwip@ietf.org, draft-ietf-lwig-curve-representations.all@ietf.org References: <157479110201.13605.6894641490219218764@ietfa.amsl.com> From: Rene Struik Message-ID: Date: Tue, 26 Nov 2019 14:54:30 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <157479110201.13605.6894641490219218764@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-lwig-curve-representations-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2019 19:54:41 -0000 Dear Russ: Thanks for your review (and speedy turn-around). Please find below feedback on how I intend to address all but your last remarks (I will reflect on your suggestion as to introductory text with the appendices when looking over Daniel Migault's earlier "guidance of the reader" remarks). Best regards, Rene On 11/26/2019 12:58 PM, Russ Housley via Datatracker wrote: > Reviewer: Russ Housley > Review result: Has Issues > > 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 authors, document editors, and WG chairs should > treat these comments just like any other IETF Last Call comments. > > Document: draft-ietf-lwig-curve-representations-08 > Reviewer: Russ Housley > Review Date: 2019-11-26 > IETF LC End Date: unknown > IESG Telechat date: unknown > > Summary: Has Issues > > > Major Concerns: > > I am confused by the first paragraph in Section 10. It says that "An > object identifier is requested ...", but then code points for COSE > and JOSE (not object identifiers) are requested in the subsection. > > I am confused by the second paragraph in Section 10. It says that > "There is *currently* no further IANA action required ...". Please > delete this paragraph. RS>> If I remember this correctly, I borrowed this from another draft (but perhaps was somewhat ignorant here about proper formulation). I intend to change the first para to "code points are requested for ....". As to the second para, I believe it has some merit to keep this in, in slightly altered form, e.g.,  as "New object identifiers would be required in case one wishes to specify one or more of the "offspring" protocols exemplified in Section 4.4. Specification hereof is, however, outside scope of the current document." < Minor Concerns: > > Requirements Language section is out of date. It should reference > RFC 8174 in addition to RFC 2119, as follows: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all > capitals, as shown here. RS>> will do. As minor point (from a non-native speaker's perspective): shouldn't the last part of the above sentence read "if, and only if, these appear...."? < Section 2 says: "... reuse of existing generic code ..."; I do not know > what is meant by "generic". It either needs to be defined, reworded, or > dropped. I note that elsewhere in the document "existing code" is used. RS>> I will add a sentence to that effect, e.g., "(Here, generic code refers to an implementation that does not depend on hardcoded domain parameters (see also Section 6).)" < > I expected Section 9 to say something about public keys being unique > identifiers of the private key holder. RS>> I will add an extra paragraph to this effect, e.g., "Use of a public key in any protocol for which successful execution evidences knowledge of the corresponding private key implicitly indicates the entity holding this private key.  Reuse of this public key with more than one protocol or more than one protocol instantiation may, therefore, allow traceability of this entity." < > Some introduction text at the beginning of each Appendix would be very > helpful. Please tell the reader what they will learn by delving into > the subsections of the appendix. RS>> I will reflect on this somewhat more (while also considering "guidance to the reader" remarks in Daniel Migault's Early IoTDir review).  Broadly speaking, though, inclusion of all these appendices makes the entire docment self-contained, including arithmetic, representations, how-to-convert details, etc. < Nits: > > Section 4.2 says: "... at the end of hereof ...". This does not tell > me anything useful. I suggest deleting this phrase. RS>> I will change this to "at the end hereof" (i.e., will remove "of" - a glitch). Here, one can only recover the y-coordinate at the end of the Montgomery ladder, since one needs the x-coordinates of k*G and (k+1)*G to make this work. < I suggest turning the numbered paragraphs in Section 5 into subsections. RS>> Will do. < -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Tue Nov 26 13:11:01 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEB5120AD9 for ; Tue, 26 Nov 2019 13:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbnzpYTktXPy for ; Tue, 26 Nov 2019 13:10:58 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B783120ADC for ; Tue, 26 Nov 2019 13:10:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E1AB2300B24 for ; Tue, 26 Nov 2019 16:10:56 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DrOVtuuB8oVj for ; Tue, 26 Nov 2019 16:10:54 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 41AD530055E; Tue, 26 Nov 2019 16:10:54 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: Date: Tue, 26 Nov 2019 16:10:54 -0500 Cc: IETF SecDir , lwip@ietf.org, draft-ietf-lwig-curve-representations.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <157479110201.13605.6894641490219218764@ietfa.amsl.com> To: Rene Struik X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-lwig-curve-representations-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2019 21:11:00 -0000 > On Nov 26, 2019, at 2:54 PM, Rene Struik = wrote: >=20 > Dear Russ: >=20 > Thanks for your review (and speedy turn-around). >=20 > Please find below feedback on how I intend to address all but your = last remarks (I will reflect on your suggestion as to introductory text = with the appendices when looking over Daniel Migault's earlier "guidance = of the reader" remarks). >=20 > Best regards, Rene >=20 > On 11/26/2019 12:58 PM, Russ Housley via Datatracker wrote: >> Reviewer: Russ Housley >> Review result: Has Issues >>=20 >> 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 authors, document editors, and WG chairs should >> treat these comments just like any other IETF Last Call comments. >>=20 >> Document: draft-ietf-lwig-curve-representations-08 >> Reviewer: Russ Housley >> Review Date: 2019-11-26 >> IETF LC End Date: unknown >> IESG Telechat date: unknown >>=20 >> Summary: Has Issues >>=20 >>=20 >> Major Concerns: >>=20 >> I am confused by the first paragraph in Section 10. It says that "An >> object identifier is requested ...", but then code points for COSE >> and JOSE (not object identifiers) are requested in the subsection. >>=20 >> I am confused by the second paragraph in Section 10. It says that >> "There is *currently* no further IANA action required ...". Please >> delete this paragraph. >=20 > RS>> If I remember this correctly, I borrowed this from another draft = (but perhaps was somewhat ignorant here about proper formulation). I = intend to change the first para to "code points are requested for ....". = As to the second para, I believe it has some merit to keep this in, in = slightly altered form, e.g., as "New object identifiers would be = required in case one wishes to specify one or more of the "offspring" = protocols exemplified in Section 4.4. Specification hereof is, however, = outside scope of the current document." >=20 > <=20 >> Minor Concerns: >>=20 >> Requirements Language section is out of date. It should reference >> RFC 8174 in addition to RFC 2119, as follows: >>=20 >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", = and >> "OPTIONAL" in this document are to be interpreted as described in >> BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all >> capitals, as shown here. >=20 > RS>> will do. As minor point (from a non-native speaker's = perspective): shouldn't the last part of the above sentence read "if, = and only if, these appear...."? <=20 >> Section 2 says: "... reuse of existing generic code ..."; I do not = know >> what is meant by "generic". It either needs to be defined, reworded, = or >> dropped. I note that elsewhere in the document "existing code" is = used. > RS>> I will add a sentence to that effect, e.g., "(Here, generic code = refers to an implementation that does not depend on hardcoded domain = parameters (see also Section 6).)" <>=20 >> I expected Section 9 to say something about public keys being unique >> identifiers of the private key holder. >=20 > RS>> I will add an extra paragraph to this effect, e.g., "Use of a = public key in any protocol for which successful execution evidences = knowledge of the corresponding private key implicitly indicates the = entity holding this private key. Reuse of this public key with more = than one protocol or more than one protocol instantiation may, = therefore, allow traceability of this entity." <=20 >>=20 >> Some introduction text at the beginning of each Appendix would be = very >> helpful. Please tell the reader what they will learn by delving into >> the subsections of the appendix. > RS>> I will reflect on this somewhat more (while also considering = "guidance to the reader" remarks in Daniel Migault's Early IoTDir = review). Broadly speaking, though, inclusion of all these appendices = makes the entire docment self-contained, including arithmetic, = representations, how-to-convert details, etc. <> Nits: >>=20 >> Section 4.2 says: "... at the end of hereof ...". This does not tell >> me anything useful. I suggest deleting this phrase. > RS>> I will change this to "at the end hereof" (i.e., will remove "of" = - a glitch). Here, one can only recover the y-coordinate at the end of = the Montgomery ladder, since one needs the x-coordinates of k*G and = (k+1)*G to make this work. < X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589C8120AF9; Tue, 26 Nov 2019 14:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qkJeFpKbrBd; Tue, 26 Nov 2019 14:21:21 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3233712091B; Tue, 26 Nov 2019 14:21:21 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id e187so17703614qkf.4; Tue, 26 Nov 2019 14:21:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=nAofHPuRBdWUfRpgBi9jJVeIZQ6wraOTvpQ1NnZbGwI=; b=uPBU65JKgTJIEbNgXqdZcbSju1f+F05tRMHCwmHLYWTHmjOk6rA6HKWMUWOLFrz57E jKR1XNpYajYToDO0ZiSG6wL4EmmTdopES3SJQVq2hROLGNqIIdxLsYZp8/CjuLkUg9o6 TGNyqrCgf66ATE5UXRbSI6qevLn9fY+q6Yh3fk+jCuRuFzViKDWqlyO3tKOjaWq3XCrC dqscEh07FVzxVveQxqfGo95/2P18mTm6y6e3CXTl4+9ZBd1u+kGp6OmkbYdR2F4rBHUW KPHo1uju1EedqKFeGw/VGhBdmu0cYJgaBCYTEQYsImF5h8UKnaLlrJwdEKGYDWMFeBuH /ORw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=nAofHPuRBdWUfRpgBi9jJVeIZQ6wraOTvpQ1NnZbGwI=; b=Wm9RHzAMxw0bSmMVEmB8t4SWJi36t6ZFY3gDJ0UyC0f5XamhuCsBLCe3oeod46YoJ3 gowCbOTb3IueaSiuVIYwbjf/+L0geE1iE/p95ENkH8Zsc0VyA4vXfzet8CdKXkm7D16l ArP4EOmOF3PCspDBcBFidcYzX3LLA6vtvg6djCdR/ozu5AsNQYkNaMEHhDYOND3S1HdB TCH9RrXJXGBKj7M5V0BgORw20l5X4haCkS/3k/i+d1PXc2oxC7FfaHjmN4CKd16T03TM X5OVH+u/wZkhs0KmDnuH/xohENta6aL4nEi1FwaQfjBnrrGOiJKwFxyB6CRRS6h49B6B 30eQ== X-Gm-Message-State: APjAAAVuSU7H5rymKHC573UxUkz67riORLpdSHzvUe3QWopdSR6HASPY 2ePLNqHBmaAqTarQDbtlxvKdED0u X-Google-Smtp-Source: APXvYqyzvk9isHlsU5aq3Gu06dnjUaTgPBqTUvUxL+qFxX5eOCl6c/h+CKikJOOwNcNBM1z22Kcp4w== X-Received: by 2002:ae9:f00b:: with SMTP id l11mr833518qkg.141.1574806879876; Tue, 26 Nov 2019 14:21:19 -0800 (PST) Received: from ?IPv6:2607:fea8:69f:fa3a:fc5f:12b:d173:619a? ([2607:fea8:69f:fa3a:fc5f:12b:d173:619a]) by smtp.gmail.com with ESMTPSA id b13sm6365780qtj.64.2019.11.26.14.21.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Nov 2019 14:21:19 -0800 (PST) To: Russ Housley Cc: IETF SecDir , lwip@ietf.org, draft-ietf-lwig-curve-representations.all@ietf.org References: <157479110201.13605.6894641490219218764@ietfa.amsl.com> From: Rene Struik Message-ID: Date: Tue, 26 Nov 2019 17:21:16 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-lwig-curve-representations-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2019 22:21:23 -0000 Hi Russ: Thanks. On 11/26/2019 4:10 PM, Russ Housley wrote: > >> On Nov 26, 2019, at 2:54 PM, Rene Struik wrote: >> >> Dear Russ: >> >> Thanks for your review (and speedy turn-around). >> >> Please find below feedback on how I intend to address all but your last remarks (I will reflect on your suggestion as to introductory text with the appendices when looking over Daniel Migault's earlier "guidance of the reader" remarks). >> >> Best regards, Rene >> >> On 11/26/2019 12:58 PM, Russ Housley via Datatracker wrote: >>> Reviewer: Russ Housley >>> Review result: Has Issues >>> >>> 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 authors, document editors, and WG chairs should >>> treat these comments just like any other IETF Last Call comments. >>> >>> Document: draft-ietf-lwig-curve-representations-08 >>> Reviewer: Russ Housley >>> Review Date: 2019-11-26 >>> IETF LC End Date: unknown >>> IESG Telechat date: unknown >>> >>> Summary: Has Issues >>> >>> >>> Major Concerns: >>> >>> I am confused by the first paragraph in Section 10. It says that "An >>> object identifier is requested ...", but then code points for COSE >>> and JOSE (not object identifiers) are requested in the subsection. >>> >>> I am confused by the second paragraph in Section 10. It says that >>> "There is *currently* no further IANA action required ...". Please >>> delete this paragraph. >> RS>> If I remember this correctly, I borrowed this from another draft (but perhaps was somewhat ignorant here about proper formulation). I intend to change the first para to "code points are requested for ....". As to the second para, I believe it has some merit to keep this in, in slightly altered form, e.g., as "New object identifiers would be required in case one wishes to specify one or more of the "offspring" protocols exemplified in Section 4.4. Specification hereof is, however, outside scope of the current document." >> >> < I do not see how the second paragraph gives any direction regarding the IANA registries. RS>>  The requested algorithm registrations are for co-factor ECDH (Example 4.1) and ECDSA (Example 4.3), where the second para is more a reminder that one would need more registrations if one would like other spin-offs (so it was more to keep parallelism with Example 4.4). As example, one could instantiate e.g., Wei25519 plus, say, MQV (which NIST SP 800-56a + new curve W25519 in draft SP 186 would enable) and, e.g., Wei25519+MQV, Wei25519 + impl cert (for V2V; see IACR 2019-157), etc., but I did not wish to go over the top and that could be to be defined elsewhere. From a Spartan writing perspective, it could indeed be argued that one could guess this oneself. < >>> Minor Concerns: >>> >>> Requirements Language section is out of date. It should reference >>> RFC 8174 in addition to RFC 2119, as follows: >>> >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and >>> "OPTIONAL" in this document are to be interpreted as described in >>> BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all >>> capitals, as shown here. >> RS>> will do. As minor point (from a non-native speaker's perspective): shouldn't the last part of the above sentence read "if, and only if, these appear...."? < RFC 8174 calls for this exact text. RS>> My remark above was more a "Strunk and White" remark. < >>> Section 2 says: "... reuse of existing generic code ..."; I do not know >>> what is meant by "generic". It either needs to be defined, reworded, or >>> dropped. I note that elsewhere in the document "existing code" is used. >> RS>> I will add a sentence to that effect, e.g., "(Here, generic code refers to an implementation that does not depend on hardcoded domain parameters (see also Section 6).)" < Thanks. > >>> I expected Section 9 to say something about public keys being unique >>> identifiers of the private key holder. >> RS>> I will add an extra paragraph to this effect, e.g., "Use of a public key in any protocol for which successful execution evidences knowledge of the corresponding private key implicitly indicates the entity holding this private key. Reuse of this public key with more than one protocol or more than one protocol instantiation may, therefore, allow traceability of this entity." < Also, using the same public key with different addresses allows an observer to correlate them. RS>> Indeed, one can correlate more stuff from meta-info that includes the public key as a common data element (even if the observer would not be able to check whether those are technically bound to this, this would often work in practice). < >>> Some introduction text at the beginning of each Appendix would be very >>> helpful. Please tell the reader what they will learn by delving into >>> the subsections of the appendix. >> RS>> I will reflect on this somewhat more (while also considering "guidance to the reader" remarks in Daniel Migault's Early IoTDir review). Broadly speaking, though, inclusion of all these appendices makes the entire docment self-contained, including arithmetic, representations, how-to-convert details, etc. < Yes, I understand that. Some of the appendicies have introductory text, but other do not. I think they all should have introductory text. > >>> Nits: >>> >>> Section 4.2 says: "... at the end of hereof ...". This does not tell >>> me anything useful. I suggest deleting this phrase. >> RS>> I will change this to "at the end hereof" (i.e., will remove "of" - a glitch). Here, one can only recover the y-coordinate at the end of the Montgomery ladder, since one needs the x-coordinates of k*G and (k+1)*G to make this work. < I think it would be better to say: ... at the end of the Montgomery ladder ..." > > Russ > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Wed Nov 27 23:13:11 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE531120C63; Wed, 27 Nov 2019 23:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4bFSDeifXX8; Wed, 27 Nov 2019 23:13:07 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D56D120C61; Wed, 27 Nov 2019 23:12:42 -0800 (PST) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xAS7CbaF028522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Nov 2019 02:12:40 -0500 Date: Wed, 27 Nov 2019 23:12:37 -0800 From: Benjamin Kaduk To: "Shawn M. Emery" Cc: secdir , draft-ietf-mpls-ldp-yang.all@ietf.org Message-ID: <20191128071237.GR32847@mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] Review of draft-ietf-mpls-ldp-yang-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2019 07:13:10 -0000 Hi Shawn, Thanks for the review! I think the latest version of the template for YANG model security considerations is at https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines (which does want a list of the subtrees and nodes are sensitive, so you are wise to call it out). -Ben On Mon, Nov 25, 2019 at 03:30:31PM -0700, Shawn M. Emery wrote: > Reviewer: Shawn M. Emery > Review result: Ready with nits > > 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 draft specifies a YANG model for the Multi-Protocol Label > Switching (MPLS) Label Distribution Protocol (LDP). Network > Configuration Protocol (NETCONF) and RESTCONF is used > to mange network devices based on this model. > > The security considerations section does exist and for security > and privacy concerns, discusses that the MTI for NETCONF is > SSH and TLS for RESTCONF. For authorization, NETCONF > and RESTCONF uses the Network Configuration Access Control > Model (NACM). > > The section goes on to state that some data nodes > and RPC operations in the YANG module are considered sensitive > to various operations, but does not give guidance on which nodes > or subtrees that would be affected. In the past, module specifications > that I've reviewed have outlined each of these relevant items. > > The section finishes with the statement that the security > properties of the base specifications, LDP, LDP IPv6, etc., also applies > to this draft. I agree with the above assertions. > > General comments: > > None. > > Editorial comments: > > s/into following/into the following/ > s/means and be read/should be read/ > s/family"/family"./ > s/VPN Forwarding and Routing/VPN Routing and Forwarding/ > s/provides a mean/provides a means/ > s/Neibgbor/Neighbor/ > s/pereference/preference/ > s/creatable\/ deletable/creatable\/deletable/ > > RESTCONF should be expanded on first ocurence. > > Shawn. > -- > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Thu Nov 28 09:05:05 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2781200E3; Thu, 28 Nov 2019 01:39:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1574933990; bh=ADkJvTquabVTY0jJjW/a1axR/ofhry+uCodr0qhKW9k=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=bfCBTFmGDa9KS7Zd8bLupqI5AJPyppilwZgySaZmNiiwXVoTv9ggPTdSP5+wAPe+M BX2eqvLrLlkSb7sjeWGztLsua9dVKeYAcywzNz+USLVXLkIBiHeR9w/QC7gy5jZn/+ a8MkQNTufKPQn9Vnu3mRZNEAI/849bCmz20vRhbw= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Nov 28 01:39:49 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EFD120098; Thu, 28 Nov 2019 01:39:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1574933989; bh=ADkJvTquabVTY0jJjW/a1axR/ofhry+uCodr0qhKW9k=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=byDasdD6yiG8Qy3NnnH1M3jRevk/tSMOiOwCSY9Lciac0Tkn3/7LSACEdXTEBHEUq 9En9PQeFvS1zxX13rM5SxmdetBioVqCxj2DP6yKjXtJmF0/TxeL7esy1PPoIkwMVdj MXI3jrDiockdcVzr5dlFPd0OwCY5WA/79hnnG8BI= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F9F120044 for ; Thu, 28 Nov 2019 01:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FROM_FMBLA_NEWDOM=1.499, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAJj7-i6hejw for ; Thu, 28 Nov 2019 01:39:46 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50DA2120098 for ; Thu, 28 Nov 2019 01:39:44 -0800 (PST) Received: from [42.100.7.168] (helo=[192.168.1.4]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1iaGGx-0004wD-31 for new-work@ietf.org; Thu, 28 Nov 2019 09:39:41 +0000 To: new-work@ietf.org From: xueyuan Message-ID: <1dac2c21-a39b-20da-da1a-3408b5552822@w3.org> Date: Thu, 28 Nov 2019 17:39:35 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 28 Nov 2019 09:05:04 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Verifiable Credentials Working Group (until 2020-01-09) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2019 09:39:52 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgVmVyaWZp YWJsZSBDcmVkZW50aWFscyBXb3JraW5nIEdyb3VwOgogwqAgaHR0cHM6Ly93d3cudzMub3JnLzIw MTkvMTEvcHJvcG9zZWQtdmMtd2ctY2hhcnRlci0yMDE5Lmh0bWwKCkFzIHBhcnQgb2YgZW5zdXJp bmcgdGhhdCB0aGUgY29tbXVuaXR5IGlzIGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsKYXQgVzNDLCB0 aGlzIGRyYWZ0IGNoYXJ0ZXIgaXMgcHVibGljIGR1cmluZyB0aGUgQWR2aXNvcnkKQ29tbWl0dGVl IHJldmlldyBwZXJpb2QuCgpXM0MgaW52aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAyMDIw LTAxLTA5IG9uIHRoZQpwcm9wb3NlZCBjaGFydGVyLiBQbGVhc2Ugc2VuZCBjb21tZW50cyB0bwpw dWJsaWMtbmV3LXdvcmtAdzMub3JnLCB3aGljaCBoYXMgYSBwdWJsaWMgYXJjaGl2ZToKIMKgIGh0 dHA6Ly9saXN0cy53My5vcmcvQXJjaGl2ZXMvUHVibGljL3B1YmxpYy1uZXctd29yay8KCk90aGVy IHRoYW4gY29tbWVudHMgc2VudCBpbiBmb3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZpc29yeQpD b21taXR0ZWUgUmVwcmVzZW50YXRpdmVzLCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJlc3BvbnNl IHRvCmNvbW1lbnRzLiBJZiB5b3Ugd29yayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNv b3JkaW5hdGUKeW91ciBjb21tZW50cyB3aXRoIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJl c2VudGF0aXZlLiBGb3IKZXhhbXBsZSwgeW91IG1heSB3aXNoIHRvIG1ha2UgcHVibGljIGNvbW1l bnRzIHZpYSB0aGlzIGxpc3QgYW5kCmhhdmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVz ZW50YXRpdmUgcmVmZXIgdG8gaXQgZnJvbSBoaXMKb3IgaGVyIGZvcm1hbCByZXZpZXcgY29tbWVu dHMuCgpJZiB5b3Ugc2hvdWxkIGhhdmUgYW55IHF1ZXN0aW9ucyBvciBuZWVkIGZ1cnRoZXIgaW5m b3JtYXRpb24sIHBsZWFzZQpjb250YWN0IEl2YW4gSGVybWFuIDxpdmFuQHczLm9yZz4sIFczQyBW ZXJpZmlhYmxlIENyZWRlbnRpYWxzCldvcmtpbmcgR3JvdXAgVGVhbSBDb250YWN0LgoKVGhhbmsg eW91LAoKWHVleXVhbiBKaWEsIFczQyBNYXJrZXRpbmcgJiBDb21tdW5pY2F0aW9ucwoKWzFdIGh0 dHA6Ly93d3cudzMub3JnL0NvbnNvcnRpdW0vTWVtYmVyL0xpc3QKCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldy13b3JrIG1haWxpbmcgbGlzdApuZXct d29ya0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldy13 b3JrCg== From nobody Thu Nov 28 09:05:09 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4578B1200D5; Thu, 28 Nov 2019 01:43:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1574934217; bh=iYcX6TQicdleVw6APjKduH4sgkC4VWckdQUQWxqfHJ4=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=rZcs3dhlZTC8YupKfsylG+E3dGJ6kv4+YqhFkcsleHV9fc96ET/gsmpcylq1bI0+a lHQxysMWuL2rVp8QJm69T7V6ahuPjmL0zZqgTBcQhoSz9CCC5A+xPsoyMQe+s/SDdX dZahcZJNFcEJGSK6MQbP5MLftet0UGv8floR4kdo= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Nov 28 01:43:37 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5982120098; Thu, 28 Nov 2019 01:43:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1574934217; bh=iYcX6TQicdleVw6APjKduH4sgkC4VWckdQUQWxqfHJ4=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=rZcs3dhlZTC8YupKfsylG+E3dGJ6kv4+YqhFkcsleHV9fc96ET/gsmpcylq1bI0+a lHQxysMWuL2rVp8QJm69T7V6ahuPjmL0zZqgTBcQhoSz9CCC5A+xPsoyMQe+s/SDdX dZahcZJNFcEJGSK6MQbP5MLftet0UGv8floR4kdo= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18A91200B6 for ; Thu, 28 Nov 2019 01:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_FMBLA_NEWDOM=1.499, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGWs4RhwJ_Wh for ; Thu, 28 Nov 2019 01:43:33 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92996120098 for ; Thu, 28 Nov 2019 01:43:33 -0800 (PST) Received: from [42.100.7.168] (helo=[192.168.1.4]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1iaGKh-0005EG-Rw for new-work@ietf.org; Thu, 28 Nov 2019 09:43:32 +0000 To: new-work@ietf.org From: xueyuan Message-ID: <7fc74b09-4166-a260-fbf7-9f06b52cd696@w3.org> Date: Thu, 28 Nov 2019 17:43:24 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 28 Nov 2019 09:05:04 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Dataset Exchange Working Group (until 2020-01-09) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2019 09:43:38 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgRGF0YXNl dCBFeGNoYW5nZSBXb3JraW5nIEdyb3VwOgogwqAgaHR0cHM6Ly93d3cudzMub3JnLzIwMTkvMTEv cHJvcG9zZWQtZHgtd2ctY2hhcnRlci0yMDE5Lmh0bWwKCkFzIHBhcnQgb2YgZW5zdXJpbmcgdGhh dCB0aGUgY29tbXVuaXR5IGlzIGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsKYXQgVzNDLCB0aGlzIGRy YWZ0IGNoYXJ0ZXIgaXMgcHVibGljIGR1cmluZyB0aGUgQWR2aXNvcnkKQ29tbWl0dGVlIHJldmll dyBwZXJpb2QuCgpXM0MgaW52aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAyMDIwLTAxLTA5 IG9uIHRoZQpwcm9wb3NlZCBjaGFydGVyLiBQbGVhc2Ugc2VuZCBjb21tZW50cyB0bwpwdWJsaWMt bmV3LXdvcmtAdzMub3JnLCB3aGljaCBoYXMgYSBwdWJsaWMgYXJjaGl2ZToKIMKgIGh0dHA6Ly9s aXN0cy53My5vcmcvQXJjaGl2ZXMvUHVibGljL3B1YmxpYy1uZXctd29yay8KCk90aGVyIHRoYW4g Y29tbWVudHMgc2VudCBpbiBmb3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZpc29yeQpDb21taXR0 ZWUgUmVwcmVzZW50YXRpdmVzLCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJlc3BvbnNlIHRvCmNv bW1lbnRzLiBJZiB5b3Ugd29yayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNvb3JkaW5h dGUKeW91ciBjb21tZW50cyB3aXRoIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0 aXZlLiBGb3IKZXhhbXBsZSwgeW91IG1heSB3aXNoIHRvIG1ha2UgcHVibGljIGNvbW1lbnRzIHZp YSB0aGlzIGxpc3QgYW5kCmhhdmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRp dmUgcmVmZXIgdG8gaXQgZnJvbSBoaXMKb3IgaGVyIGZvcm1hbCByZXZpZXcgY29tbWVudHMuCgpJ ZiB5b3Ugc2hvdWxkIGhhdmUgYW55IHF1ZXN0aW9ucyBvciBuZWVkIGZ1cnRoZXIgaW5mb3JtYXRp b24sIHBsZWFzZQpjb250YWN0IFBoaWxpcHBlIExlIEhlZ2FyZXQgPHBsaEB3My5vcmc+LCBXM0Mg UHJvamVjdCBNYW5hZ2VtZW50IExlYWQuCgpUaGFuayB5b3UsCgpYdWV5dWFuIEppYSwgVzNDIE1h cmtldGluZyAmIENvbW11bmljYXRpb25zCgpbMV0gaHR0cDovL3d3dy53My5vcmcvQ29uc29ydGl1 bS9NZW1iZXIvTGlzdAoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KbmV3LXdvcmsgbWFpbGluZyBsaXN0Cm5ldy13b3JrQGlldGYub3JnCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Thu Nov 28 15:29:57 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A1E120108 for ; Thu, 28 Nov 2019 15:29:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <157498379588.5739.3662712490606104555.idtracker@ietfa.amsl.com> Date: Thu, 28 Nov 2019 15:29:55 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2019 23:29:56 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-12-05 Reviewer LC end Draft John Bradley 2019-11-22 draft-schaad-cbor-content-01 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-04 Sean Turner 2019-11-07 draft-ietf-ospf-ospfv2-hbit-11 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Last calls: Reviewer LC end Draft John Bradley 2019-11-22 draft-schaad-cbor-content-01 Shaun Cooley 2019-11-12 draft-ietf-regext-login-security-06 Roman Danyliw 2019-11-12 draft-ietf-dtn-bpbis-17 Alan DeKok 2019-11-27 draft-ietf-6man-ra-pref64-08 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Linda Dunbar 2019-12-02 draft-ietf-opsec-v6-21 Donald Eastlake 2019-12-16 draft-nottingham-rfc7320bis-02 Donald Eastlake 2019-11-14 draft-ietf-hip-dex-11 Stephen Farrell 2019-12-02 draft-ietf-dprive-rfc7626-bis-03 Daniel Franke 2019-12-02 draft-ietf-mboned-driad-amt-discovery-09 Tobias Gondrom 2019-12-02 draft-ietf-tls-tls13-cert-with-extern-psk-03 Phillip Hallam-Baker 2019-12-02 draft-ietf-stir-passport-divert-07 Dan Harkins R2019-10-03 draft-ietf-dtn-bpsec-13 Christian Huitema 2019-12-09 draft-ietf-tls-certificate-compression-07 Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-18 Sandra Murphy 2019-10-04 draft-ietf-mpls-ldp-yang-06 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-09 Stefan Santesson 2019-10-10 draft-ietf-payload-rtp-ttml-06 Takeshi Takahashi 2019-11-04 draft-ietf-netmod-yang-data-ext-04 Sean Turner 2019-11-25 draft-ietf-nfsv4-rfc5661sesqui-msns-03 Sean Turner 2019-11-07 draft-ietf-ospf-ospfv2-hbit-11 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Leif Johansson Benjamin Kaduk Charlie Kaufman Scott Kelly Stephen Kent Tero Kivinen Watson Ladd Ben Laurie Barry Leiba Chris Lonvick From nobody Thu Nov 28 17:01:53 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A84120801; Thu, 28 Nov 2019 17:01:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema via Datatracker To: Cc: last-call@ietf.org, draft-ietf-tls-certificate-compression.all@ietf.org, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Christian Huitema Message-ID: <157498929764.5575.7815291384505057169@ietfa.amsl.com> Date: Thu, 28 Nov 2019 17:01:37 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-tls-certificate-compression-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2019 01:01:38 -0000 Reviewer: Christian Huitema Review result: Has Issues I have reviewed draft-ietf-tls-certificate-compression-07 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. Draft-ietf-tls-certificate-compression-07 defines two new TLS extensions to negotiate and then apply compression of the Certificate message. The draft is clear and well written, and the extensions are already widely deployed. I would like to say "ready", but I have to say "almost". This document is almost ready, except for one nit and one issue. First, one nit. The draft references the "Certificate message", but there is no formal reference section 4.4.2 of RFC8446. Please add that, maybe at the beginning of section 4. It may seem obvious to members of the TLS WG, but uninformed readers will appreciate. Second, my actual concern. Compression may leak information, because different certificate chains will compress differently. The authors mention that an attacker will not be able to inject data in the certificate chain, and thus that attacks of the CRIME variety are unlikely. That's correct, but that's not the entire story. TLS 1.3 will encrypt the compressed certificate message but the length of that message could be deduced from the length of the server's encrypted message. Attackers might be able to derive from that length the identity of the server, even if the SNI is encrypted. One could say that in the absence of compression the length of the certificate chain is also available. Indeed, the problem is flagged in draft-ietf-tls-esni-05, which states in section 5.3 that "it (the server) SHOULD pad the Certificate message, via padding at the record layer, such that its length equals the size of the largest possible Certificate (message) covered by the same ESNI key." Certificate compression introduces a level of complexity here. If only some servers in the anonymity set support compression, attackers can work with a smaller anonymity subset. If all attackers support compression, the padding should try to match the largest Compressed Certificate. It might be good to discuss this issue in the security consideration section. From nobody Fri Nov 29 07:39:19 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 019081201E3; Fri, 29 Nov 2019 07:39:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stephen Farrell via Datatracker To: Cc: last-call@ietf.org, dns-privacy@ietf.org, draft-ietf-dprive-rfc7626-bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Stephen Farrell Message-ID: <157504194893.4871.5551746255324168227@ietfa.amsl.com> Date: Fri, 29 Nov 2019 07:39:08 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dprive-rfc7626-bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2019 15:39:09 -0000 Reviewer: Stephen Farrell Review result: Ready I might not be the best reviewer for this one as I've read it a few times before. But anyway, I scanned the diff [1] with RFC7626 and figure it seems fine. The only thing that occurred to me that seemed missing was to note that while the new privacy analysis in 3.5.1.1 is already complex, many systems are mobile and hence an analysis that ignores that won't be sufficient. For a mobile device one really needs to analyse all of the possible setups, and hence it's even harder to get to a good answer. (It could be that that's elsewhere in the document but since I only read the diff, I didn't see it:-) Cheers, S. [1] https://tools.ietf.org/rfcdiff?url1=rfc7626&url2=draft-ietf-dprive-rfc7626-bis-03.txt From nobody Sat Nov 30 18:07:11 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D57120047; Sat, 30 Nov 2019 18:07:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Phillip Hallam-Baker via Datatracker To: Cc: draft-ietf-stir-passport-divert.all@ietf.org, last-call@ietf.org, stir@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Phillip Hallam-Baker Message-ID: <157516602555.14564.17709496168683829956@ietfa.amsl.com> Date: Sat, 30 Nov 2019 18:07:05 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-stir-passport-divert-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 02:07:05 -0000 Reviewer: Phillip Hallam-Baker Review result: Has Issues Section 1: Introduction "If Alice calls Bob, for example, Bob might attempt to ..." Alice, Bob and Carol are people. People do not emit JSON strings, create signatures or do any of the things they are described as being engaged in. Only the machines the people might possess can do such things. Anthropomorphising Turing machines results in language that is hard to follow at best and renders any attempt to consider UI issues impossible. Section 12: Security Considerations Is this going to create new means of injecting spam? It looks like it might. Consider the case in which Sue the spammer sets up a single genuine call between X and Y, then creates forwarding associations for 10,000 endpoints Z0-9999. Also consider reflection type attacks in which callers responding to spam have their numbers harvested for spoof source addresses for further spam.