From nobody Fri Mar 1 12:46:25 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 AF729130EBC; Fri, 1 Mar 2019 12:46:23 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 31D6MPZEMyXn; Fri, 1 Mar 2019 12:46:21 -0800 (PST) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 2CAF212D4F2; Fri, 1 Mar 2019 12:46:20 -0800 (PST) Received: by mail-qt1-x835.google.com with SMTP id o6so29381473qtk.6; Fri, 01 Mar 2019 12:46:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3gGb0dbXY8AojA+UtKtQ65o+1kx1cYEp4uhNf/OrAYI=; b=YG3NU4glWGJRUOlQLJ6zHEPzgqgvy7aNLEPHSlE14EGI1eSfInmS06GN0sKj5FaBVe casofDL09Jpb7oW5MF022OqiN409MhBawk5Dek2a2tvXN3VUCOvLwxMMFqfiWktzZww0 9h5Isx4u9GOm95gAC/OfTwVP4WBkNI9casrHe2JUrij/aFrVZXWzbk3OWvwUDvTaOgNg NBK4bCwfh96LLkWBPZVZ8vO7iPR5d8sR5vO2PYd6vZEyGrl3UkE6W1nCXjZDnnduwWwt QXAlD5qbSLS6iHsxvytd8aG9k46hglVGRIr3MdkGgaLM0R5DkZAfZRfB5C0HmigNQkAa IsXQ== 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=3gGb0dbXY8AojA+UtKtQ65o+1kx1cYEp4uhNf/OrAYI=; b=QTrocc8W1a2wDu7y36hodWga6T8AJFp3O1zak+i6mHSjynyrU7SI6oWDtY9IyTR6yQ NaThPSp7BTBggMS1+1yvu6DKvXoJUZsRiPUAp6CYGrYpVSKGlBAg2u+ooOt0KDkW152U qcRYlcr+TgaFiUrmWIVYD9Gc4zHhkwYfyNIrah3EOZf2dSUO3RQR994UBiPhbFN2KzbG irLLi4PlCUZ1Pk3r2IEnUCogPKjj3+z4VyW0SFc9Glei9wCHrcG/0tGPh+MvnYtL1up5 N8CHQr2Yfz3s1awQvy5h+Kiok70Wh8q34NAPxj3n6FOI+c2u8MVeNLCVYswB4Q8njzTa Li9Q== X-Gm-Message-State: APjAAAVhZTR6Pd4KUQzC1utetgZrflNiqy8yNgeoMUIyQdrzQ981kp+A FpGLTEAhSe4ghwNQTCLedD59e0tAzdCujdigcBE= X-Google-Smtp-Source: APXvYqxM08URHzYjFTk7wvMEr2Lk0JYpeuXDcT8qNF6dQWBdEnjEh2Y+rJ4B2f9empazNfnVwrpyWF0c5fNgwoeMmG8= X-Received: by 2002:a0c:d196:: with SMTP id e22mr5287857qvh.181.1551473179867; Fri, 01 Mar 2019 12:46:19 -0800 (PST) MIME-Version: 1.0 References: <155014077570.26619.9407568904769535504@ietfa.amsl.com> <6882A552-80DF-4322-9683-13D8E655F2DB@inria.fr> In-Reply-To: From: David Benham Date: Fri, 1 Mar 2019 12:46:08 -0800 Message-ID: To: Vincent Roca Cc: "Paul E. Jones" , secdir@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000c3bd9605830e7fb0" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-perc-private-media-framework 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 Mar 2019 20:46:24 -0000 --000000000000c3bd9605830e7fb0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Vincent Follow up question regarding your general comments on sect 8.1 and 8.2 which we have not yet addressed in -09 ; > Attacks of section 8.1 seems more realistic to me than attacks of section 8.2 > because of a weaker attacker model: the attacker is outside of the systems, > and not necessarily on the path. > Therefore I would have liked to see more details in section 8.1, that=E2= =80=99s all. You're asking for greater detail in sect 8.1 precisely because you estimate that third-party attacks (aka outsiders to a given conference) are more likely/common than the attacks we covered in the subsequent 8.2 section. Is that correct? If so, I think we could restate some of what we have in sect 8.1 to make it flow better and/or be clearer. But it is not clear to us what we left out detail-wise, or if we left out other attack examples. With PERC's HBH integrity checks, authentication as well as HBH and E2E encryption, we can quickly describe in text the prevention/mitigation of attacks on the confidentiality of the media/content - PERCs reason to be - to explain some of the brevity. Could you help point us in the right direction with an example or two of the things we should do to detail/elaborate sect 8.1. > ** General comments about 8.1 and 8.2 > Insider attacks are a powerful form of attacker model with severe consequences. > This is not a big surprise. I'd be more interesting in a detailed 8.1 section, > more likely to happen (weaker attacker model). https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/ On Tue, Feb 19, 2019 at 11:13 PM Vincent Roca wrote= : > Hello Paul, > > Thanks for your answer and long explanations on the use of term > =C2=AB picture =C2=BB. I was not aware of this > evolution of vocabulary. Yes, please submit -09 version and I=E2=80=99ll = have a > new look at it. > > Cheers, > > Vincent > --000000000000c3bd9605830e7fb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Vincent
Follow up qu= estion regarding your general comments on sect 8.1 and 8.2 which we have no= t yet addressed in -09 ;

> Attacks of section 8= .1 seems more realistic to me than attacks of section 8.2
> because o= f a weaker attacker model: the attacker is outside of the systems,
>= and not necessarily on the path.=C2=A0=C2=A0
> Therefore = I would have liked to see more details in section 8.1, that=E2=80=99s all.<= /div>

You're asking for greater detail i= n sect 8.1 precisely because you estimate that third-party attacks (aka out= siders to a given conference) are more likely/common than the attacks we co= vered in the subsequent 8.2 section.=C2=A0 =C2=A0Is that=C2=A0correct?

If so, I think we could restate some of what we have i= n sect 8.1 to make it flow better and/or be clearer.=C2=A0 =C2=A0But it is = not clear to us what we left out detail-wise, or if we left out other attac= k examples.

With PERC's HBH=C2=A0integrity checks,=C2=A0authentication as well as= HBH and E2E encryption, we can quickly describe in text the prevention/mit= igation of attacks on the=C2=A0confidentiality of the media/content - PERCs= reason to be - to explain some of the brevity.=C2=A0

Could you help point us in= the right direction with an example or two of the things we should do to d= etail/elaborate sect 8.1.

> ** General comments about 8.= 1 and 8.2
> Insider attacks are a powerful form of attacker model wit= h severe consequences.
> This is not a big surprise. I'd be more = interesting in a detailed 8.1 section,
> more likely to happen (weake= r attacker model).



<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Feb 19, 2019 at 11:13 PM Vince= nt Roca <vincent.roca@inria.fr<= /a>> wrote:
<= div style=3D"overflow-wrap: break-word;">Hello Paul,

Tha= nks for your answer and long explanations on the use of term =C2=AB=C2=A0pi= cture=C2=A0=C2=BB. I was not aware of this
evolution of vocabular= y. Yes, please submit -09 version and I=E2=80=99ll have a new look at it.

=C2=A0 Cheers,

=C2=A0 Vinc= ent
--000000000000c3bd9605830e7fb0-- From nobody Mon Mar 4 06:02:24 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 3D9A013106B; Mon, 4 Mar 2019 06:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 bQ80I31_iIJs; Mon, 4 Mar 2019 06:02:19 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 DBE5B12D4EF; Mon, 4 Mar 2019 06:02:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.58,440,1544482800"; d="scan'208,217";a="371808139" Received: from moucherotte.inrialpes.fr ([194.199.28.14]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Mar 2019 15:02:16 +0100 From: Vincent Roca Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_AB4E3043-79C5-4E56-B443-0063ED209835" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 4 Mar 2019 15:02:16 +0100 In-Reply-To: Cc: Vincent Roca , secdir@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org, The IESG To: David Benham , "Paul E. Jones" References: <155014077570.26619.9407568904769535504@ietfa.amsl.com> <6882A552-80DF-4322-9683-13D8E655F2DB@inria.fr> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-perc-private-media-framework 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 Mar 2019 14:02:23 -0000 --Apple-Mail=_AB4E3043-79C5-4E56-B443-0063ED209835 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello David, Paul, all, I gave a look at version -09 of your I-D, here are a few comments. Summary: Almost ready ** Section 8.1 There is a sentence introducing section 8.2, but none for section 8.1. = For instance it is not explicitely explained what is meant by =C2=AB 3rd party attack =C2=BB. I suggest = adding a sentence. ** Section 8.1 You=E2=80=99re saying that "If mutual DTLS authentication is not = employed=E2=80=A6 =C2=BB. Is it really an optional mechanism? I must admit I haven=E2=80=99t read the rest of your I-D where this is = probably explained, I=E2=80=99m just a bit surprised here. ** Section 8.2.2 It is suggested but not clearly said that the replay protection of = Section 3.3.2/[RFC3711] MUST be used. The sentence can be understood as replay protection is mandatory, = Section 3.3.2 of [RFC3711] is an example of such a mechanism. I don't think this is what you mean. ** Section 8.2.3 Saying that "The delayed playout attack is a variant of the replay = attack" is IMHO misleading. Delaying and re-sending a packet already sent are two different attacks = (and the fact that replay protection is of no help against delayed packets is a good sign of these = differences). I'd remove this sentence altogether. Otherwise, concerning your previous comment: > Follow up question regarding your general comments on sect 8.1 and 8.2 = which we have not yet addressed in -09 ; >=20 > > Attacks of section 8.1 seems more realistic to me than attacks of = section 8.2 > > because of a weaker attacker model: the attacker is outside of the = systems,=20 > > and not necessarily on the path. =20 > > Therefore I would have liked to see more details in section 8.1, = that=E2=80=99s all. >=20 > You're asking for greater detail in sect 8.1 precisely because you = estimate that third-party attacks (aka outsiders to a given conference) = are more likely/common than the attacks we covered in the subsequent 8.2 = section. Is that correct? >=20 > If so, I think we could restate some of what we have in sect 8.1 to = make it flow better and/or be clearer. But it is not clear to us what = we left out detail-wise, or if we left out other attack examples. >=20 > With PERC's HBH integrity checks, authentication as well as HBH and = E2E encryption, we can quickly describe in text the = prevention/mitigation of attacks on the confidentiality of the = media/content - PERCs reason to be - to explain some of the brevity.=20 >=20 > Could you help point us in the right direction with an example or two = of the things we should do to detail/elaborate sect 8.1. [VR] I was surprised to see for instance 8 lines of text in section = 8.2.2 or 8.2.4 to describe attacks that cannot take place because of the PERC design. That being said, I = see that version -09 has a more detailed section 8.1 which is fine. Cheers, Vincent= --Apple-Mail=_AB4E3043-79C5-4E56-B443-0063ED209835 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= David, Paul, all,

I = gave a look at version -09 of your I-D, here are a few = comments.

Summary: Almost = ready

** Section 8.1
 There= is a sentence introducing section 8.2, but none for section 8.1. For = instance it is not explicitely
explained what is = meant by =C2=AB 3rd party attack =C2=BB. I suggest adding a = sentence.

** Section 8.1
You=E2=80=99re saying = that "If mutual DTLS authentication is not employed=E2=80=A6 =C2=BB. = Is it really an optional mechanism?
I must admit I = haven=E2=80=99t read the rest of your I-D where this is probably = explained, I=E2=80=99m just a bit surprised here.
** Section = 8.2.2
It is suggested but not clearly said that the = replay protection of Section 3.3.2/[RFC3711] MUST be used.
The sentence can be understood as replay protection is = mandatory, Section 3.3.2 of [RFC3711] is an example
of such a mechanism.
I don't think this = is what you mean.

** Section 8.2.3
Saying that "The = delayed playout attack is a variant of the replay attack" is IMHO = misleading.
Delaying and re-sending a packet = already sent are two different attacks (and the fact that = replay
protection is of no help against delayed = packets is a good sign of these differences).
I'd = remove this sentence altogether.


Otherwise, concerning your previous comment:


Follow up question regarding your general = comments on sect 8.1 and 8.2 which we have not yet addressed in -09 = ;

> Attacks = of section 8.1 seems more realistic to me than attacks of section 8.2
> because of a weaker attacker model: the attacker is = outside of the systems,
> and not necessarily on the = path.  
> Therefore I = would have liked to see more details in section 8.1, that=E2=80=99s = all.

You're asking for greater detail in sect 8.1 precisely = because you estimate that third-party attacks (aka outsiders to a given = conference) are more likely/common than the attacks we covered in the = subsequent 8.2 section.   Is that correct?

If so, I think we could = restate some of what we have in sect 8.1 to make it flow better and/or = be clearer.   But it is not clear to us what we left out = detail-wise, or if we left out other attack examples.

With PERC's = HBH integrity = checks, authentication as well as HBH and E2E encryption, we can = quickly describe in text the prevention/mitigation of attacks on = the confidentiality of the media/content - PERCs reason to be - to = explain some of the brevity. 

Could you help point us in the right direction = with an example or two of the things we should do to detail/elaborate = sect 8.1.

[VR] I was surprised to see for instance 8 lines = of text in section 8.2.2 or 8.2.4 to describe attacks
that = cannot take place because of the PERC design. That being said, I see = that version -09 has a
more detailed section 8.1 which is = fine.

Cheers,

  =  Vincent
= --Apple-Mail=_AB4E3043-79C5-4E56-B443-0063ED209835-- From nobody Mon Mar 4 15:00:44 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 3C67B1311EC; Mon, 4 Mar 2019 15:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=R/6d3DEu; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=OaWNoioa 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 0jTuNSS3-6-R; Mon, 4 Mar 2019 15:00:26 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B3EC131130; Mon, 4 Mar 2019 15:00:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4656; q=dns/txt; s=iport; t=1551740426; x=1552950026; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nvraGNZ7bQG3Z+hLG2ws8px90DW7T9npBw0zqBQ4lUw=; b=R/6d3DEuBMyrk25PAy7R7cud39cp/McBqICMYtnHiiKdd6ORPSyrVH6Z Y6Z7n3+2Rt83nZM2c1YXAqfwwxVwWzXC2k9v6+b5BvjYjS6wi7Z1i8UF+ vKhi3D7EwIIIy9FxYfgKfI6ToH/yhXWNkcmhjrpwBC2Nhh5rerThDCX/9 A=; IronPort-PHdr: =?us-ascii?q?9a23=3AiaSt6RNU0IuyDa37xtEl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj9J/fvcC08E+xJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAABMrX1c/5xdJa1lGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYE8UAOBXAQLJ4QIg0cDhFCLAIIyJZghgSQDVAsBASy?= =?us-ascii?q?EQAIXhA4iNAkNAQEDAQEDAQMCbRwMhUsGIxEMAQE3AQ8CAQgSAgYCCB4CAgI?= =?us-ascii?q?wFQIOAgQBDQWDIoFeAxUBnioCihRxgS+CeAEBBYUDGIILCIELJAGLJxeBf4E?= =?us-ascii?q?RJwwTgkyICzGCJoxEl0IJApJyGYF0hWKILoMeimSSIwIEAgQFAg0BAQWBRzi?= =?us-ascii?q?BVnAVZQGCQYIKDBeDS4pTcoEoj20BAQ?= X-IronPort-AV: E=Sophos;i="5.58,441,1544486400"; d="scan'208";a="532056475" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Mar 2019 23:00:20 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x24N0IuL031424 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Mar 2019 23:00:19 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 4 Mar 2019 17:00:17 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 4 Mar 2019 17:00:17 -0600 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 4 Mar 2019 17:00:17 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nvraGNZ7bQG3Z+hLG2ws8px90DW7T9npBw0zqBQ4lUw=; b=OaWNoioaHl5SAEv50tvZ9h/OOHobwElN2i+PRLP4ASxf+SvE/lPhWCiTkw/1bruDmal63ISAd+UIGJNiDtCdeyH6W2Qz2RP34VbsEFRA9HMsacYIxxXlsQlSHwepGpl1BJV6WU9B9df018Hds0mB7E3E7ym7X5418bzfJ01H4h8= Received: from BN6PR11MB1732.namprd11.prod.outlook.com (10.175.99.7) by BN6PR11MB1569.namprd11.prod.outlook.com (10.172.24.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.18; Mon, 4 Mar 2019 23:00:16 +0000 Received: from BN6PR11MB1732.namprd11.prod.outlook.com ([fe80::3df6:de14:447c:4146]) by BN6PR11MB1732.namprd11.prod.outlook.com ([fe80::3df6:de14:447c:4146%3]) with mapi id 15.20.1665.019; Mon, 4 Mar 2019 23:00:16 +0000 From: "Nancy Cam-Winget (ncamwing)" To: Matthew Miller , "secdir@ietf.org" CC: "mile@ietf.org" , "draft-ietf-mile-xmpp-grid.all@ietf.org" , "ietf@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-mile-xmpp-grid-09 Thread-Index: AQHUs0W2aSPmnUhDtUaqYfWjQfdJQaX7z2mA Date: Mon, 4 Mar 2019 23:00:16 +0000 Message-ID: <5CFE429E-31EA-4261-B1CD-17181200F394@cisco.com> References: <154826649938.7505.11018194912932133243@ietfa.amsl.com> In-Reply-To: <154826649938.7505.11018194912932133243@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.7.190210 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ncamwing@cisco.com; x-originating-ip: [2001:420:292:1260:1dfe:3a6c:3efe:7107] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d7212739-8ab2-4db5-e55d-08d6a0f52af8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BN6PR11MB1569; x-ms-traffictypediagnostic: BN6PR11MB1569: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCTjZQUjExTUIxNTY5OzIzOmNBazZmTGhQVnpKRU5TT05ydDlralFpRGt0?= =?utf-8?B?T2owbk9PWkdSMnRVOFAvMGZiNVVyeUNmVGx3RUdmOEVMTHJLZXJsbzBDSmpH?= =?utf-8?B?ZjE1RFQvRWp6RGpOS000a2pZcDZtR1I1QWRsRG03TFZQbjRZaEI3STNaVmZP?= =?utf-8?B?cnBXa1JKSUtFUkE2NDN5Zkt1aGo3alhFM1MyVW9pbm0yMGFacFlLQjBlcHp4?= =?utf-8?B?L2NJVVRPQjRBTkN6bXB3cFJ3OWdkUk8wREM5Nk54blA4ZTI1UXdRQ2orMDF5?= =?utf-8?B?eEFHMFBnSzVsWVNUNXg2b3R6UWFXNDk5ay9jRmYxaEErWmp4Y2RpVXU0OUFD?= =?utf-8?B?a2hlaFY4d09XRTlIWldaa1I4RnY5Sm5EMVZMcHdZemp1V2x4N0czbGhFNWJJ?= =?utf-8?B?KzQwUDBkck1tN0hFVEhtMWdONmdSOTk2NEN4NEY2c3YyeGpxb2VMQ2xkOVNT?= =?utf-8?B?ZnJXSzhqekRndzlzdmtyYXF0WjZTUWFoYy9kUk1rUW9DT1lhWHhTYjFGZFA0?= =?utf-8?B?amlOdU45cGZRd0N0cFdoWVJIWFZHR053OXFDcmxhY0Y3d25IbDJ6TVNnS0U1?= =?utf-8?B?RHMrK0lpSTg5ZkJ5MmMzZ25MOGY4Ym5XZEVjVmt0dDRlektaWXMvaEVPUlNk?= =?utf-8?B?b09UTGNQRVRJT1dRbGdWRGZoaTNHVVVhM01ScENPN2JzazIvRytXbHo5UkxU?= =?utf-8?B?TmpybEs2VUVGMW9WVWJMekIzTXJNRHRXWnlKUHFTSG9oUzU4YXBkOG1EYzNL?= =?utf-8?B?UUFRbUxHbnFoZkU1eS91MUdKejVhTDgrM2M5UnhSL2svZXBGY3IwVDFuNVRS?= =?utf-8?B?eVZOVldBUTd5Z05yMFV4ZGZGcU5Xa243OXpFbE0xTVdCU1A4c2lNdXBwa01P?= =?utf-8?B?aXM2NUZjZFRlZXFsYzBkM1pSU2dsblVOUVcrRFdiWHdxbS9sUmYwRUROT2VS?= =?utf-8?B?WGgrUVdVc0FFc1owUmJpMmxrYWt1Q2g3NitmcS9YeVdkeUU5RmZLbHhwNzJR?= =?utf-8?B?b2RUc2xRVkdWWEhBbGdFdDBIbHA0alliQWJ1ZkxKRThwSk10UVZocmdtc3BC?= =?utf-8?B?cllhcDVhU0VRb3FnMUcxTVJNcUsyMDViYkdtMk96TXZIUExOYk11eTBjZ3Zn?= =?utf-8?B?UnduYmcwUlM3V0NRWkVOQTRBcndBRHAxQm5ZTDRIZUhjbktKYmxHcHVSS05E?= =?utf-8?B?akpiZm5QSURDRXEyWi9TcnJNdE9LSHpQRDNzUGxsRURVZmZkcWhtbXlybzhw?= =?utf-8?B?SUxocC9wY1F1VXc3NEptVUg5eHMxcy9hcnh0YXROUDdDOUxkTzYzcldjeHF0?= =?utf-8?B?eWVmNVNuVWlGY0c1akhLUDF2NUlLd2NiRDIrZnZXbmJ2S2FjU3diMXpFOUxJ?= =?utf-8?B?eFExUkltY3RuNUFIUlJpbnBXZXFQajJuenM5Ri92RGd6NDVmRkhJWXpHVXlG?= =?utf-8?B?L3IvVTdnejhLZlMrWGFJV09sY0JoTytselltbFJKeXQ2YzFjUkk2MEhRUHVt?= =?utf-8?B?WkI4emdqaU9XT3ozZGJ5OFVnMmZkYklaWXUrWjYxVkZEbEsrdzRaSHN2T0pm?= =?utf-8?B?dWtYSis4aE80YVZFUHhhS1VRSzJFUC9VTW5WTW5YTnRXYWppSzZUUkFzejhL?= =?utf-8?B?dEpZZmZnWFYxTFdPbExiaklrNWZOWmg5ZnVTNGU5V21yVDhVeUVIclEyeCtt?= =?utf-8?Q?cSEfQnN6otySGoAtU0OOfBTTeeMGUcSsWr4WKiZ?= x-microsoft-antispam-prvs: x-forefront-prvs: 09669DB681 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(136003)(346002)(376002)(396003)(189003)(199004)(51914003)(81156014)(102836004)(81166006)(8676002)(6116002)(46003)(97736004)(229853002)(68736007)(8936002)(6246003)(256004)(14444005)(6436002)(11346002)(446003)(2616005)(186003)(105586002)(476003)(106356001)(486006)(58126008)(6512007)(305945005)(82746002)(76176011)(25786009)(54906003)(14454004)(86362001)(7736002)(110136005)(2906002)(2501003)(6486002)(71190400001)(71200400001)(33656002)(53936002)(36756003)(4326008)(6506007)(83716004)(5660300002)(99286004)(478600001)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR11MB1569; H:BN6PR11MB1732.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: i6PenAnT2+IUiw+QTsQY1/4Xr5D7gWJDP+KDAtQwtm4EQgXcwuOGmThAcngAu7+adtAYNFU1dje2U95nf9azggSDgIaz/UZtRCL6G2lRDbcRLKLEr6j8J1XCEPCk6kMre9KN8Bz+ecuZjPgOo2c/UXSFb4RIrlquudevaXaEhKxj3I7sYl+3rJUfDbyyfyAEqU3QZuqRVsV7fJ3Nm8peYmSSoxU8i7MVG3MPUtqaRI1enqHOMSuE0UHVgeKq033tImeAqtbQbFZAluJDMX6LrxkLAlOlNdhpiYwUtBUgSikq2fs6Lj+oABNvXJpLkA4K30JnOfHeKP82HggzM0kuTJ0v3d3FzgJDlnHqdPpuRHoyx3+j1UB3l28QU71YfqEPOx4F3zmE+rnWdPYJ7cLAJppiHlaJIyQUXEtyhOFh7Ew= Content-Type: text/plain; charset="utf-8" Content-ID: <4D59E790B8B98F409B47FE7E88C18155@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d7212739-8ab2-4db5-e55d-08d6a0f52af8 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2019 23:00:16.5658 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1569 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.26, xch-rcd-016.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mile-xmpp-grid-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 Mar 2019 23:00:30 -0000 SGkgTWF0dCwgdGhhbmtzIGZvciB0aGUgcmV2aWV3LiAgUGxlYXNlIHNlZSBiZWxvdyBmb3IgY29t bWVudHM6DQoNCu+7v09uIDEvMjMvMTksIDEwOjAxLCAiTWF0dGhldyBNaWxsZXIiIDxsaW51eHdv bGYraWV0ZkBvdXRlci1wbGFuZXMubmV0PiB3cm90ZToNCg0KICAgIFJldmlld2VyOiBNYXR0aGV3 IE1pbGxlcg0KICAgIFJldmlldyByZXN1bHQ6IEhhcyBJc3N1ZXMNCiAgICANCiAgICBJIGhhdmUg cmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0 ZSdzDQogICAgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWlu ZyBwcm9jZXNzZWQgYnkgdGhlDQogICAgSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRl biBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZQ0KICAgIHNlY3VyaXR5IGFyZWEgZGly ZWN0b3JzLiAgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZA0KICAgIHRyZWF0 IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0K ICAgIA0KICAgIERvY3VtZW50OiBkcmFmdC1pZXRmLW1pbGUteG1wcC1ncmlkLTA5DQogICAgUmV2 aWV3ZXI6IE1hdHRoZXcgQS4gTWlsbGVyDQogICAgUmV2aWV3IERhdGU6IDIwMTgtMDEtMjMNCiAg ICBJRVRGIExDIEVuZCBEYXRlOiAyMDE5LTAxLTE0DQogICAgSUVTRyBUZWxlY2hhdCBkYXRlOiAy MDE5LTAxLTI0DQogICAgDQogICAgU3VtbWFyeToNCiAgICANCiAgICBUaGlzIGRvY3VtZW50IGRl ZmluZXMgYW4gYXJjaGl0ZWN0dXJlIGZvciBkaXN0cmlidXRpbmcgc2VjdXJpdHkNCiAgICBpbmZv cm1hdGlvbiB1c2luZyBwdWJsaXNoLXN1YnNjcmliZSBzZW1hbnRpY3Mgb3ZlciBYTVBQLiAgSXQg aXMNCiAgICB3ZWxsIHdyaXR0ZW4gYW5kIGFkZHJlc3NlZCBtYW55IChidXQgbm90IGFsbCkga25v d24gY29uY2VybnMNCiAgICBvZiBhIHB1Ymxpc2gtc3Vic2NyaWJlIA0KICAgIA0KICAgIFRoaXMg ZG9jdW1lbnQgaGFzIGlzc3VlcyB0aGF0IHNob3VsZCBiZSBhZGRyZXNzZWQgYmVmb3JlIGl0IGlz DQogICAgcmVhZHkgdG8gYmUgcHVibGlzaGVkIGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQuDQogICAg DQogICAgDQogICAgTWFqb3IgSXNzdWVzOg0KICAgIA0KICAgIFRoZSBkb2N1bWVudCBkb2VzIG5v dCBleHBsaWNpdGx5IGRpc2N1c3MgdGhlIGltcGxpY2F0aW9ucyBvZiB0aGUNCiAgICBDb250cm9s bGVyIGFuZCBCcm9rZXIgaGF2aW5nIHBsYWludGV4dCBhY2Nlc3MgYW5kIGNvbnRyb2wgb2YgdGhl DQogICAgcHVibGlzaGVkIGRhdGEuICBJdCBzZWVtcyB0byBiZSBpbXBsaWVkIGluIHRoZSBzZWN0 aW9uIDguMi4zIGZvcg0KICAgIHRoZSBDb250cm9sbGVyIChhbmQsIGZvciB0aG9zZSBwcm9maWNp ZW50IHdpdGggWE1QUCwgdGhlIEJyb2tlcikuDQogICAgSSBhbSBub3Qgc3Ryb25nbHkgcmVjb21t ZW5kaW5nIGFueSBzb3J0IG9mIGVuZC10by1lbmQgcHJvdGVjdGlvbnMNCiAgICBiZSBwcm9zY3Jp YmVkIChzaW5jZSBleGlzdGluZyBwcm90ZWN0aW9ucyBhcmUgbGlrZWx5IHVuc3VpdGFibGUNCiAg ICBmb3IgdGhpcyBhcmNoaXRlY3R1cmUpLg0KW05DV10gV2UgaGF2ZSBhZGRlZCBhIHNlbnRlbmNl IGluIDguMy4zIHRvIGFkZHJlc3MgcHJvdGVjdGlvbiANCmFnYWluc3QgY29udHJvbGxlci9icm9r ZXIgdG8gZW1wbG95IGVuZC10by1lbmQgZW5jcnlwdGlvbi4NCiAgICANCiAgICBUaGUgZG9jdW1l bnQgZG9lcyBub3QgaGF2ZSBhbnkgcmVhbCBkaXNjdXNzaW9uIGFyb3VuZCBwZXJzaXN0ZW5jZQ0K ICAgIG9mIG5vZGUgaXRlbXMuICBpZiB0aGV5IGFyZSBleHBlY3RlZCBvciBkZXNpcmVkIHRvIGJl IHBlcnNpc3RlZCwNCiAgICB0aGVuIHRoZXJlIHNob3VsZCBiZSBzb21lIGRpc2N1c3Npb24gYWJv dXQgcmV0ZW50aW9uIHBvbGljaWVzDQogICAgKG1lYW5pbmc6IGRlcGxveW1lbnRzIG91Z2h0IHRv IGhhdmUgb25lKSwgYW5kIGJlaGF2aW9ycyB3aGVuIGENCiAgICBQbGF0Zm9ybSBzdWJzY3JpYmVz IHRvIHRoZSBUb3BpYyAoZS5nLiwgc2hvdWxkIG9yIG1heSBhdXRvbWF0aWNhbGx5DQogICAgc2Vu ZCB0aGUgbGFzdCBwdWJsaXNoZWQgaXRlbSB0byB0aGUgcmVjZW50IHN1YnNjcmliZXIpLiAgSWYg bm90LA0KICAgIHRoZW4gc29tZSBkaXNjdXNzaW9uIG9uIHRoZSBpbXBsaWNhdGlvbnMgb2YgZXhp c3RpbmcvaGlzdG9yaWMNCiAgICBkYXRhIGJlaW5nIHVuYXZhaWxhYmxlIHRocm91Z2ggdGhpcyBt ZWNoYW5pc20uDQpbTkNXXSBGYWlyIHBvaW50LiBXZSBhZGRlZCB0aGUgZm9sbG93aW5nIHN0YXRl bWVudHMgdG8gdGhlIGRvY3VtZW50IHRvIGFkZHJlc3MgdGhpcyAtDQpOb3RlIHRoYXQgdGhlIGNv bnRyb2wgcGxhbmUgbWF5IG9wdGlvbmFsbHkgYWxzbyBpbXBsZW1lbnQgWEVQLTAyMDMgdG8gZmFj aWxpdGF0ZSBkZWxheWVkDQpkZWxpdmVyeSBvZiBtZXNzYWdlcyB0byB0aGUgY29ubmVjdGVkIGNv bnN1bWVyIGFzIGRlc2NyaWJlZCBpbiBYRVAtMDA2MC4gU2luY2UgaW5mb3JtYXRpb24NCm1heSBi ZSB0aW1lbHkgYW5kIHNlbnNpdGl2ZSwgY2FwYWJpbGl0eSBwcm92aWRlcnMgc2hvdWxkIGNvbW11 bmljYXRlIHRvIHRoZSBjb250cm9sbGVyDQp3aGV0aGVyIGl0cyBtZXNzYWdlcyBjYW4gYmUgY2Fj aGVkIGZvciBkZWxheWVkIGRlbGl2ZXJ5IGR1cmluZyBjb25maWd1cmF0aW9uOyBzdWNoIGZ1bmN0 aW9uDQppcyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgZG9jdW1lbnQuICAgIA0KDQogICAgTWlub3Ig SXNzdWVzOg0KICAgIA0KICAgIFhNUFAgcHVic3ViIGlzIGNvbXBsZXgsIGFuZCBub2RlIGNvbmZp Z3VyYXRpb24gcmVmbGVjdHMgdGhhdC4NCiAgICBSZWx5aW5nIG9uIFhFUC0wMDYwIGlzIHNvbWV0 aGluZyBvZiBhIGRpc3NlcnZpY2UgdG8gaW1wbGVtZW50ZXJzLA0KICAgIGluIG15IG9waW5pb24u ICAgSSBzdWdnZXN0IHRoYXQgYW4gYWRkaXRpb24gVG9waWMgY3JlYXRpb24NCiAgICBleGFtcGxl IGJlIGFkZGVkIHRoYXQgZGVtb25zdHJhdGVzIHRoZSByZWNvbW1lbmRlZCBjb25maWd1cmF0aW9u Og0KICAgICogcHVic3ViI2FjY2Vzcy1hdXRob3JpemUgb3IgYWNjZXNzLXdoaXRlbGlzdA0KICAg ICogcHVic3ViI3BlcnNpc3RfaXRlbXMgPSA/PyAoMSBvciAwKQ0KICAgICogcHVic3ViI3NlbmRf bGFzdF9wdWJsaXNoZWRfaXRlbSA9ID8/IChvbl9zdWI/IG5ldmVyPykgDQpbTkNXXSBUaGF0IHNl ZW1zIHJlYXNvbmFibGUsIEkgd2lsbCBhZGQgaXQgYXMgYW4gb3B0aW9uIChhcyB0aGUgY3VycmVu dCBzZWN0aW9uIGRvZXMgc3RhdGUgaXQgaXMgdGhlIG1pbmltYWwgZm9yIHRvcGljIGNyZWF0aW9u KS4NCiAgICANCiAgICBOaXRzOiBOL0ENCiAgICANCiAgICANCg0K From nobody Mon Mar 4 18:37:15 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 0FC8A130E92; Mon, 4 Mar 2019 18:34:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1551753279; bh=lEVNr8EL8uUqnSOP2G0xUV3+ANiMtC2j832jEHRBAHM=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=K1sBn4BSbEnxvgy+KHmay9YLRZ+2E91zR3dbomS8JXqEjNkpNR+ZZOmjgm9XhuZUo Y0WQJNayC/3EMj8dEd5R/MbP4BS9/fm3ZEmkJ5EW5NfcnPjklvvC4fZ6rCKGb9MMdu z0AWPvncz4rGH82lBnVegeI1weu6FLrWqnHcr81c= X-Mailbox-Line: From new-work-bounces@ietf.org Mon Mar 4 18:34:38 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 718FD130E89; Mon, 4 Mar 2019 18:34:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1551753278; bh=lEVNr8EL8uUqnSOP2G0xUV3+ANiMtC2j832jEHRBAHM=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=JHklKaKqJKXbG/AQCI8/2Q7BDBzVfNlST8vcT8GBQjH0rqT/lGF8hcRoffKkODWXO 1G6/lPMyLP6hQlI6aGnpQpCHI19Bs/9LgK+D6TOUo94RXeDAmMTLBm7tcQKMvb+0YG nl4B/kaDHYHWz5JPdv4LspMNKMrPU68bdGxhDbB4= 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 2E8C3130E81 for ; Mon, 4 Mar 2019 18:34:36 -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, HK_RANDOM_ENVFROM=0.001, 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 MlXOtoNpQMeM for ; Mon, 4 Mar 2019 18:34:34 -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 E79B9130E6F for ; Mon, 4 Mar 2019 18:34:33 -0800 (PST) Received: from [42.100.6.160] (helo=[192.168.1.3]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1h0zuZ-0002Qr-OJ for new-work@ietf.org; Tue, 05 Mar 2019 02:34:32 +0000 To: new-work@ietf.org From: xueyuan Message-ID: Date: Tue, 5 Mar 2019 10:34:24 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.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: Mon, 04 Mar 2019 18:37:14 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Web Applications Working Group (until 2019-04-05) 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, 05 Mar 2019 02:34:42 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgV2ViIEFw cGxpY2F0aW9ucyBXb3JraW5nIEdyb3VwOgogwqAgaHR0cHM6Ly93d3cudzMub3JnLzIwMTkvMDMv d2ViYXBwcy1jaGFydGVyLmh0bWwKCkFzIHBhcnQgb2YgZW5zdXJpbmcgdGhhdCB0aGUgY29tbXVu aXR5IGlzIGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsKYXQgVzNDLCB0aGlzIGRyYWZ0IGNoYXJ0ZXIg aXMgcHVibGljIGR1cmluZyB0aGUgQWR2aXNvcnkKQ29tbWl0dGVlIHJldmlldyBwZXJpb2QuCgpX M0MgaW52aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAyMDE5LTA0LTA1IG9uIHRoZQpwcm9w b3NlZCBjaGFydGVyLiBQbGVhc2Ugc2VuZCBjb21tZW50cyB0bwpwdWJsaWMtbmV3LXdvcmtAdzMu b3JnLCB3aGljaCBoYXMgYSBwdWJsaWMgYXJjaGl2ZToKIMKgIGh0dHA6Ly9saXN0cy53My5vcmcv QXJjaGl2ZXMvUHVibGljL3B1YmxpYy1uZXctd29yay8KCk90aGVyIHRoYW4gY29tbWVudHMgc2Vu dCBpbiBmb3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZpc29yeQpDb21taXR0ZWUgUmVwcmVzZW50 YXRpdmVzLCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJlc3BvbnNlIHRvCmNvbW1lbnRzLiBJZiB5 b3Ugd29yayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNvb3JkaW5hdGUKeW91ciBjb21t ZW50cyB3aXRoIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlLiBGb3IKZXhh bXBsZSwgeW91IG1heSB3aXNoIHRvIG1ha2UgcHVibGljIGNvbW1lbnRzIHZpYSB0aGlzIGxpc3Qg YW5kCmhhdmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUgcmVmZXIgdG8g aXQgZnJvbSBoaXMKb3IgaGVyIGZvcm1hbCByZXZpZXcgY29tbWVudHMuCgpJZiB5b3Ugc2hvdWxk IGhhdmUgYW55IHF1ZXN0aW9ucyBvciBuZWVkIGZ1cnRoZXIgaW5mb3JtYXRpb24sIHBsZWFzZQpj b250YWN0IFhpYW9xaWFuIFd1IDx4aWFvcWlhbkB3My5vcmc+IG9yIFl2ZXMgTGFmb24gPHlsYWZv bkB3My5vcmc+LApXM0MgU3RhZmYgQ29udGFjdHMuCgpUaGFuayB5b3UsCgpYdWV5dWFuIEppYSwg VzNDIE1hcmtldGluZyAmIENvbW11bmljYXRpb25zCgpbMV0gaHR0cDovL3d3dy53My5vcmcvQ29u c29ydGl1bS9NZW1iZXIvTGlzdAoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCm5ldy13b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0BpZXRmLm9yZwpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Mon Mar 4 18:40:15 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 83A7F12D4E7 for ; Mon, 4 Mar 2019 18:40:02 -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_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=mozilla.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 bO2lUvpKZM6l for ; Mon, 4 Mar 2019 18:40:00 -0800 (PST) Received: from mail-it1-x135.google.com (mail-it1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 1BBCA130E81 for ; Mon, 4 Mar 2019 18:39:58 -0800 (PST) Received: by mail-it1-x135.google.com with SMTP id w18so2007407itj.4 for ; Mon, 04 Mar 2019 18:39:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Kas9j4JkT/8905atQMrTvdov1dlERaZNuPG2AAUuLh0=; b=MZlSGp4KFUIlWRHzE3zflC3qyKEo5WJL15NfFFHYb1ZNjqHs6feCPCyg34e/97WH+W x8BO5J31QoroDLBZ3Cwt47J5racQhTq9pnIllXguG7uzdAketS4jfdDoArW22834pCoI qJWUeP0Xn13i7gNFlcYQ3B79jeOmglCzAsyhE= 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:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Kas9j4JkT/8905atQMrTvdov1dlERaZNuPG2AAUuLh0=; b=oSIPyPkT6pVMUKP7PQfZciaj0W1nJCb5mzZGbdYsYHdmwxNU5l+EZZAXoMeL1c4iD7 a1qU0hpCfVUSfI4evGOkW11LFInoR6A5SaLWkh+9pgGOjuRB/3VLCyXzHyUFZLMoI4UR L1wgkBXanAbHqMWJDOrS/AAcI4uHrIL+iE4Xj7zLKcDKHemca3zHhg0asx+0OFwyq6p+ HQxjkFUKVL+aXKx2W4IN8V9fMwPwbnMx8S55cPZA0wC3uhF3tJZ5Z6L6ZhYiSKNkMDWs mCjayYBTVEKKLwpwLhMcPRWLjx9PUdAfb/IRCG2S9csSKnM1Lbpwx4umqJ1KNEeOWMcr AWkg== X-Gm-Message-State: APjAAAXyn5+6ZBzgatLAK9vEVhELCRvYv/wM2TrYj1jh6Jt+C4AR5Pdr kfRG0kzIZUjAXFz5zEv+y/t6jQ== X-Google-Smtp-Source: APXvYqyq//BGSQul7bp9J+2IHvavyVKgRXrEJJ3lBmNzAUM1/8UzUntBgnuEnAc3n9hau21gprRJ1A== X-Received: by 2002:a24:dd1:: with SMTP id 200mr1411808itx.65.1551753597247; Mon, 04 Mar 2019 18:39:57 -0800 (PST) Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id s12sm3804184itj.41.2019.03.04.18.39.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Mar 2019 18:39:56 -0800 (PST) To: "Nancy Cam-Winget (ncamwing)" , Matthew Miller , "secdir@ietf.org" Cc: "mile@ietf.org" , "draft-ietf-mile-xmpp-grid.all@ietf.org" , "ietf@ietf.org" References: <154826649938.7505.11018194912932133243@ietfa.amsl.com> <5CFE429E-31EA-4261-B1CD-17181200F394@cisco.com> From: Peter Saint-Andre Openpgp: preference=signencrypt Autocrypt: addr=stpeter@mozilla.com; prefer-encrypt=mutual; keydata= mQINBFonEf4BEADvZ+RGsJoOyZaw2rKedB9pBb2nNXVGgymNS9+FAL/9SsfcrKaGYSiWEz7P Lvc97hWH3LACFAHvnzoktv+4IWHjItvhdi9kUQ3Gcbahe55OcdZuSXXH3w5cHF0rKz9aYRpN jENqXM5dA8x4zIymJraqYvHlFsuuPB8rcRIV9SKsvcy14w9iRqu770NjXfE/aIsyRwwmTPiU FQ0fOSDPA/x2DLjed/GYHem90C5vF4Er9InMqH5KAMLnjIYZ9DbPx5c5EME4zW/d648HOvPB bm+roZs4JTHBhjlrTtzDDpMcxHq1e8YPvSdDLPvgFXDcTD4+ztkdO5rvDkbc61QFcLlidU8H 3KBiOVMA/5Rgl4lcWZzGfJBnwvSrKVPsxzpuCYDg01Y/7TH4AuVkv5Na6jKymJegjxEuJUNw CBzAhxOb0H9dXROkvxnRdYS9f0slcNDBrq/9h9dIBOqLhoIvhu+Bhz6L/NP5VunQWsEleGaO 3gxGh9PP/LMyjweDjPz74+7pbyOW0b5VnIDFcvCTJKP0sBJjRU/uqmQ25ckozuYrml0kqVGp EfxhSKVqCFoAS4Q7ux99yT4re2X1kmlHh3xntzmOaRpcZsS8mJEnVyhJZBMOhqE280m80ZbS CYghd2K0EIuRbexd+lfdjZ+t8ROMMdW5L51CJVigF0anyYTcAwARAQABtCdQZXRlciBTYWlu dC1BbmRyZSA8c3RwZXRlckBtb3ppbGxhLmNvbT6JAlQEEwEIAD4WIQQ1VSPTuPTvyWCdvvRl YYwYf2gUqQUCWicR/gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBlYYwY f2gUqdaREAChG8qU1853mP0sv2Mersns8TLG1ztgoKHvMXFlMUpNz6Oi6CjjaMNFhP7eUY4T D43+yQs7f4qCkOAPWuuqO8FbNWQ+yUoVkqF8NUrrVkZUlZ1VZBMQHNlaEwwu1CGoHsLoRohP SiZ0hpmGTWB3V6cDDK4KN6nl610WJbzE9LeKY1AxtePdJi2KM281U0Fz8ntij1jWu0gF2xU4 Sez46JDogHLWKgd0srauhcCVzZjAhiWrXp1+ryzSWYaZO8Kh8SnF1f4o6jtYikMqkxUaI5nX wvD3kNX4AMSkCAZfG7Jcfj/SLDojTcREgO87g7B9bcOOsHN4lj3lHoFV0aXpgPmjfIvAjJHu fHkXZAQAH8w0u9bgJqRn703+A4NPfLopnjegyhlNi7fQ3cMQV1H7Oj7WrB/pCcprx+1u/6Uq oTtDwWh1U5uVthVAI0QojpNWR08zABDX19TlGtVoeygaQV3CAEolxTiYQtCfVavUzUplCZ/t 3v4YiRov+NylflJd+1akyOs1IAgARf444BnoH1fotkpfXNOpp9wUXXwsQcFRdP7vpMkSCkc0 sxPNTVX3ei0QImp4NsrFdaep7LV3zEb3wkAp6KE5Qno4hVVEypULbvB0G6twNZbeRfcs2Rjp jnPb2fofvg2WhAKB20dnRfIfK8OKTD/P+JDcauJANjmekLkCDQRaJxH+ARAApPwkbOTChAQu jMvteb/xcwuL5JZElmLxIqvJhqybV7JknM+3ATyN0CTYQFvPTgIrhpk4zSn0A6pEePdK8mKK 5/aHyd7pr7rLEi1sI/X3UE8ld/E83MExksKrYbs0UX1wSQwYXU6g64KicnuP2Abqg+8wrQ18 1nPcZci9jJI75XVPnTdUpZD5aaQWGp7IJ06NTbiOk30I50ORfulgKoe4m3UfsMALFxIx3pJk oy76xC2tjxYGf+4Uq1M0iK3Wy655GrcwXq/5ieODNUcAZzvK5hsUVRodBq0Lq3g1ivQF4ba7 RQayDzlW6XgoeU49xnCr9XdZYnTnj4iaPmr2NtY6AacBwRz+bJsyugeSyGgHsnVGyUSMk8YN wZHvUykMjH21LLzIUX5NFlcumLUXDOECELCJwewui4W81sI5Sq/WDJet+iJwwylUX22TSulG VwDS+j66TLZpk1hEwPanGLwFBSosafqSNBMDVWegKWvZZVyoNHIaaQbrTIoAwuAGvdVncSQz ttC6KkaFlAtlZt3+eUFWlMUOQ9jxQKTWymyliWKrx+S6O1cr4hwVRbg7RQkpfA8E2Loa13oO vRSQy/M2YBRZzRecTKY6nslJo6FWTftpGO7cNcvbmQ6I++5cBG1B1eNy2RFGJUzGh1vlYo51 pdfSg0U1oPHBPCHNvPYCJ7UAEQEAAYkCPAQYAQgAJhYhBDVVI9O49O/JYJ2+9GVhjBh/aBSp BQJaJxH+AhsMBQkJZgGAAAoJEGVhjBh/aBSpAw0P/1tEcEaZUO1uLenNtqysi3mQ6qAHYALR Df3p2z/RBKRVx0DJlzDfDvJ2R/GRwoo+vyCviecuG2RNKmJbf1vSm/QTtbQMUjwut9mx6KCY CyKwniqdhaMBmjCfV2DB2MxxZLYMtDfx/2mY7vzAci7AkjC+RkSUByMEOkyscUydKC/ETdf9 tvI8GhTY/8Q7JSylS3lQA5pMUHiIf+KpSmqKZeBPkGc7nSKM1w1UKUvFAsyyVsiG6A/hWrTr 7tTQAl7YfjtOGE8n4IKGktvrT99bbh9wdWKZ5FdHUN9hx2Q8VP8+0lR1CH2laVFbEwCOv1vM W4cgQDLxwwpo1iOTdHBVtQDxlQ9hPMKVlB1KP9KjchxuiLc24wLmCjP3pDMml4LQxOYB34Eq cgPZ3uHvJZG309sb2wTMTWaXobWNI++ZrsRD5GTmuzF3kkx3krtrq6HI5NSaemxK6MTDTjDN Rj/OwTl0yU35eJXuuryB20GFOSUsxiw00I2hMGQ1Cy9L/+IW6Dvotd8O3LmKh2tFArzXaKLx /rZyGNurS/Go5YjHp8wdJOs7Ka2p1U31js24PMWO6hf6hIiY2WRUsnE6xZNhvBTgKOY6u0KT V6hTevFqEw7OAZDCWUoE2Ob2/oHGZCCMW5SLAMgp7eihF0kGf2S2CmpIFYXGb61hAD8SqSY7 Fn7V Message-ID: <8eaa83e6-5218-9584-ad4e-5e2e7f8e80ad@mozilla.com> Date: Mon, 4 Mar 2019 19:39:55 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <5CFE429E-31EA-4261-B1CD-17181200F394@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mile-xmpp-grid-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, 05 Mar 2019 02:40:03 -0000 A few further thoughts from a co-author but not primary author. On 3/4/19 4:00 PM, Nancy Cam-Winget (ncamwing) wrote: > Hi Matt, thanks for the review. Please see below for comments: > > On 1/23/19, 10:01, "Matthew Miller" wrote: > > Reviewer: Matthew Miller > 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. > > Document: draft-ietf-mile-xmpp-grid-09 > Reviewer: Matthew A. Miller > Review Date: 2018-01-23 > IETF LC End Date: 2019-01-14 > IESG Telechat date: 2019-01-24 > > Summary: > > This document defines an architecture for distributing security > information using publish-subscribe semantics over XMPP. It is > well written and addressed many (but not all) known concerns > of a publish-subscribe > > This document has issues that should be addressed before it is > ready to be published as a Proposed Standard. > > > Major Issues: > > The document does not explicitly discuss the implications of the > Controller and Broker having plaintext access and control of the > published data. It seems to be implied in the section 8.2.3 for > the Controller (and, for those proficient with XMPP, the Broker). > I am not strongly recommending any sort of end-to-end protections > be proscribed (since existing protections are likely unsuitable > for this architecture). > [NCW] We have added a sentence in 8.3.3 to address protection > against controller/broker to employ end-to-end encryption. Matt's point about "this architecture" is relevant. We should make it clearer in the document that the XMPP-Grid is not intended to be an open system that any arbitrary entity can join; instead, it is a private network (not connected to the public XMPP network) to which only authorized entities are allowed access. > The document does not have any real discussion around persistence > of node items. if they are expected or desired to be persisted, > then there should be some discussion about retention policies > (meaning: deployments ought to have one), and behaviors when a > Platform subscribes to the Topic (e.g., should or may automatically > send the last published item to the recent subscriber). If not, > then some discussion on the implications of existing/historic > data being unavailable through this mechanism. > [NCW] Fair point. We added the following statements to the document to address this - > Note that the control plane may optionally also implement XEP-0203 to facilitate delayed > delivery of messages to the connected consumer as described in XEP-0060. Since information > may be timely and sensitive, capability providers should communicate to the controller > whether its messages can be cached for delayed delivery during configuration; such function > is out of scope for this document. In addition, we should mention the "pubsub#last-published" configuration option. Preservation or reconstruction of the history of messages sent to a Topic strikes me as a service that a Broker isn't required to provide (e.g., because the history might become quite large), just as a message archive for an email discussion list might be provided by an entity other than the delivery service. > Minor Issues: > > XMPP pubsub is complex, and node configuration reflects that. > Relying on XEP-0060 is something of a disservice to implementers, > in my opinion. Given the generic publish-subscribe pattern required here, it felt more appropriate to re-use an existing XMPP extension (of which there are numerous implementations) than to invent something new. > I suggest that an addition Topic creation > example be added that demonstrates the recommended configuration: > * pubsub#access-authorize or access-whitelist > * pubsub#persist_items = ?? (1 or 0) > * pubsub#send_last_published_item = ?? (on_sub? never?) > [NCW] That seems reasonable, I will add it as an option (as the current section does state it is the minimal for topic creation). Yes, on_sub ('When a new subscription is processed') seems appropriate. Peter From nobody Tue Mar 5 15:28:13 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 D004F12F1AC; Tue, 5 Mar 2019 15:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 2XxTbBheoFRh; Tue, 5 Mar 2019 15:28:09 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82AA512F1A5; Tue, 5 Mar 2019 15:28:05 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 8231728B0041; Tue, 5 Mar 2019 18:28:04 -0500 (EST) Received: from [127.0.0.1] (nova.tislabs.com [10.66.1.77]) by nova.tislabs.com (Postfix) with ESMTP id 2B4461F804E; Tue, 5 Mar 2019 18:28:04 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_55B868CF-FF3B-44D1-9148-C251E98359DB" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Russ Mundy In-Reply-To: <303AF160-B911-4B70-83B1-583BB96CEB19@tislabs.com> Date: Tue, 5 Mar 2019 18:28:04 -0500 Cc: Russ Mundy , ietf@ietf.org, adrian@olddog.co.uk X-Mao-Original-Outgoing-Id: 573521279.9898731-a6fa24b2dbeabd42f5b516c821b388e3 Message-Id: References: <5920C065-DDDB-4C1A-83FB-E0436C467D3B@tislabs.com> <055301d4b953$0044f3d0$00cedb70$@olddog.co.uk> <303AF160-B911-4B70-83B1-583BB96CEB19@tislabs.com> To: draft-ietf-mpls-sfc.all@ietf.org, secdir@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [secdir] secdir last call review of draft-ietf-mpls-sfc-05 [was: Re: secdir last call review of draft-ietf-mpls-sfc-04] 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, 05 Mar 2019 23:28:11 -0000 --Apple-Mail=_55B868CF-FF3B-44D1-9148-C251E98359DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Reviewer: Russ Mundy Review result: Has Issues (improved over 04 version) I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Document: draft-ietf-mpls-sfc-05 Reviewer: Russ Mundy Review Date: 2019-03-05 IETF LC End Date: 2019-03-05 Thanks for the changes incorporated into the 05 version of the document, = they have made portions of the document, including the Security = Considerations clearer and easier to understand. Issue: Although the Security Considerations is certainly improved, = stating that =E2=80=9Cthe classifier is a trusted resource=E2=80=9D yet = not having the spec say what it is =E2=80=9Ctrusted=E2=80=9D to do (or = not do) remains a an issue. It does seem that more information is needed = to know what =E2=80=9Ctrust=E2=80=9D expectations are and how can one = determine if they have been met. Issue: Since the spec is silent on whether or not it=E2=80=99s use is = appropriate for an InterCarrier Interconnect (ICI) environment (as = defined in RFC5920), the spec could well be used in a multi carrier = environment. Without further specification of security characteristics = (such as =E2=80=9Ctrust=E2=80=9D) it would seem appropriate to say that = this specification SHOULD NOT be used in an ICI environment unless = additional security vulnerability definitions as well as additional = specifications of security requirements are developed. Russ > On Feb 1, 2019, at 3:22 PM, Russ Mundy > wrote: >=20 >=20 >=20 >> On Jan 31, 2019, at 5:52 AM, Adrian Farrel > wrote: >>=20 >> Hi Russ, >=20 > Hi Adrian, >=20 >>=20 >> Thanks for reviewing. >=20 > You=E2=80=99re welcome. >=20 >>=20 >> A few responses ... >>=20 >>> Summary: >>>=20 >>> This document defines defines a methods to achieve Service Function = Chaining (SFC)=20 >>> using Network Service Header (NSH) in Multiprotocol Label Switching = (MPLS) networks. >>=20 >> No, it absolutely does not. >> To quote from the Abstract... >>=20 >> This document describes how Service Function Chaining can be = achieved >> in an MPLS network by means of a logical representation of the NSH = in >> an MPLS label stack. >>=20 >> The point of this document is exactly that it does not use the NSH. = Instead it encodes the fields of the NSH in MPLS headers. This is = crucially important because if one wanted to use the NSH in an MPLS = network one would apply RFC 8300 and draft-ietf-mpls-sfc-encapsulation. >=20 > Okay, thanks for the clarification, I obviously misread what is meant = by 'a logical representation of the NSH'. >=20 >>=20 >>> Issues: >>>=20 >>> First, the document and in particular the Security Considerations = section points to published RFCs >>> for discussions of the security properties. In particular, RFC7665 = and RFC8300 are referenced=20 >>> however each of these documents left some significant security = descriptions & definitions to be >>> addressed by implementation documents such as this one. = Additionally, the SECDIR reviews of >>> the IDs prior to publication of these RFCs point out several = security related issues that, as far as >>> I could tell, were primarily addressed by saying that future = implementation specifications will >>> address them. Since this ID is such an implementation = specification, referring to the earlier RFCs >>> for the security properties results in essentially no security = properties provided in either the=20 >>> earlier RFCs or this implementation document - security properties = need to be identified avoided >>> via circular references. >>=20 >> I think you have a good point here that, although the aspects of = security related to SFC are inherited from whatever documents the SFC WG = produces (complete with whatever flaws exist in that set of documents = that need to be patched by that WG), *this* document needs to talk about = the security of the mechanisms that it defines. >>=20 >> That means some discussion of the security of the MPLS forwarding = plane (with references) and some discussion about what would happen if = someone was able to tamper with a packet (noting that if someone can = successfully tamper with an MPLS packet in flight then they can do a lot = of other bad things as well). >=20 > I agree, it's important for the WG to think about security aspects of = functions for each of the documents it produces. It's also important to = be able to describe how a documents' security aspects relate to the = security aspects of related other technologies, e.g., RFC5920 describes = an overall security framework - it might contain useful information = (even though it's status is Informational). =20 >=20 >>=20 >>> Next, the Security Considerations section identifies that the = certain elements of the design must >>> be a =E2=80=98trusted resource=E2=80=99 and that some functions must = also be trusted. The term =E2=80=9Ctrusted=E2=80=9D in=20 >>> relationship to computing and software has a wide range of different = meanings (as shown by >>> many years of research in the CS field). In the context of this = document, my guess is that it >>> means that some unidentified (but not defined) entity believes = (=E2=80=9Ctrusts=E2=80=9D) that the software >>> will do the =E2=80=9Cright thing=E2=80=9D - to me (from a security = perspective) it also means trusting that the >>> software will not do the wrong thing. All of this is very abstract = (both the Security=20 >>> Considerations text & this critique) which in my view is why the = 'trust' section is very >>> inadequate for an implementation document. >>=20 >> If there is an IETF security definition of "trust" that we could look = at, that would help. >=20 > Are you referring to RFC4949 or another definition? 4949 might = provide a useful definition, it's worth checking to see if there=E2=80=99s= something useful there or elsewhere. >=20 >>=20 >> "Do the right thing" is probably not quite what we mean.=20 >> I think we mean "Not act maliciously so as to wilfully break the = network or send traffic to/via the wrong places.=E2=80=9D >=20 > This certainly sounds reasonable but I'm not sure where the concept is = described - I wasn't able to find it in RFC5920, RFC7665, or RFC8300. >=20 >>=20 >> But this is all a little like how we "trust" a router.=20 >> A malign router could drop or redirect packets contrary to the = routing information it has received. We typically test for that in the = lab, and maybe watch for it in the field, but other procedures (such as = checking software images) are generally out of scope for protocol = documents. >=20 > I agree that this is a difficult concept to describe. Even though = protocol documents don't describe testing requirements and such, section = 14 (Implementation Notes) does lead one to think about what should be = done to implement the specification. Having some security related = implementation notes there would be helpful and appears to be consistent = with information already in the section. >=20 > WRT the Security Considerations section, it would be useful to review = sections 5 - 12 of the document to identify if there are particular = structures or functions that must work correctly or the SFC design will = "fail" (for some value of "fail"). If there are specific functions or = structures that are crucial to the design, it would be appropriate to = identify them in the Security Considerations section. =20 >=20 >>=20 >>> Additionally, the last paragraph of the Security Considerations = section asserts: >>>=20 >>> Thus the security vulnerabilities are addressed (or should be >>> addressed) in all the underlying technologies used by this design, >>> which itself does not introduce any new security vulnerabilities. >>>=20 >>> As far as I could see, the assertion is not supported anywhere in = the document >>> itself or other referenced documents, i.e., what vulnerabilities = should the=20 >>> implementation be concerned with (e.g. passive monitoring, active = attacks >>> on metadata, etc??) that result from this implementation. Since the=20= >>> document does not provide a clear identification of it's security = requirement, >>> any security services it does (or might) provide nor require from = underlying >>> technologies, the assertion should be clarified, supported by = additional=20 >>> information or removed from the section. >>=20 >> I *do* understand where you are coming from on this, but I'm not sure = where we go with it. >>=20 >> Let's consider for a moment the case of email being carried over an = MPLS network. There is a security vulnerability that passive monitoring = of MPLS packets would allow inspection of the contents of the email. = There are a number of ways to protect against this including encryption = at the application layer (i.e. of the email) and encryption at the = transport layer, and encryption at the IP layer. There is also the = possibility to encrypt the underlying transport (such as MACsec).=20 >>=20 >> Now, you are asking about whether this document should discuss the = security of any metadata carried in the MPLS encoding of an SFC system = (I realise this is just one example of the concerns you are raising). = And I would say that it should not. It should observe that metadata is = an SFC concept (SFC is the application using MPLS) and encryption of = that data is a function of the "SFC layer=E2=80=9D. >=20 > Thanks for these examples, they do clarify how the pieces fit together = (terminology is always hard) - prior to the examples, it was not clear = that the SFC was roughly an application using MPLS. I think that this = also means that every SFC system deployment must determine their own = security requirements and how they will be met _within_ (or by) the = particular SFC system, i.e., neither MPLS nor the Service Function = Chaining provide confidentiality, integrity or other security services = often required by applications. >=20 >>=20 >> So maybe a bolder statement could be added to the document=E2=80=A6 >=20 > I think text of this nature is much better than the current paragraph. = If my i.e. text above is correct, it should also be part of the = introductory portion (e.g., neither MPLS or SFC provide security = services application functions require). >=20 >>=20 >> "The MPLS forwarding plane does not include any security mechanisms. = That means that procedures described in this document rely on three = basic principles: >>=20 >> - The MPLS network is often considered to be a closed network such = that insertion, >> Modification, or inspection of packets by an outside party is not = possible. >=20 > Since RFC5920 includes InterCarrier Interconnect (ICI), that seems = difficult to assert that MPLS is a "closed network". Perhaps I'm = misinterpreting 5920 but having different/multiple carriers involved = with MPLS forwarding does not seem to be a "closed network" or perhaps = the functions defined in this document should not be used with MPLS ICI. = I do agree with the sentiment of the statement but think it needs a bit = more clarification. > =20 >>=20 >> - The underlying transport mechanisms (such as Ethernet) between = adjacent MPLS >> Nodes may offer security mechanisms that can be used to defend = packets "on the >> Wire" >>=20 >> - The SFC-capable devices participating in the network are = responsible for verifying >> And protecting packets and their contents. >=20 > Would it be clearer if it read: > - The SFC-capable devices participating in an SFC system are = responsible for verifying and protecting packets and their contents as = well as providing other security capabilities that might be required in = the particular system. >=20 >>=20 >> Deployments of any SFC system will need to consider these issues, = especially the last point. It is expected that a deployment of the = techniques defined in this document would benefit from the more general = security mechanisms defined for SFC." >>=20 >> Thanks, >> Adrian >=20 > Thank you for the prompt response, clarifications and explanations.. >=20 > Russ --Apple-Mail=_55B868CF-FF3B-44D1-9148-C251E98359DB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Reviewer: Russ Mundy
Review result: Has Issues = (improved over 04 version)

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

Document: draft-ietf-mpls-sfc-05
Reviewer: Russ Mundy
Review Date: = 2019-03-05
IETF LC End Date: 2019-03-05


Thanks for the changes incorporated into the 05 version of = the document, they have made portions of the document, including the = Security Considerations clearer and easier to understand.

Issue: Although the = Security Considerations is certainly improved, stating that =E2=80=9Cthe = classifier is a trusted resource=E2=80=9D yet not having the spec say = what it is =E2=80=9Ctrusted=E2=80=9D to do (or not do) remains a an = issue. It does seem that more information is needed to know what = =E2=80=9Ctrust=E2=80=9D expectations are and how can one determine if = they have been met.

Issue: Since the spec is silent on whether or not it=E2=80=99s = use is appropriate for an InterCarrier Interconnect (ICI) environment = (as defined in RFC5920), the spec could well be used in a multi carrier = environment.  Without further specification of security = characteristics (such as =E2=80=9Ctrust=E2=80=9D) it would seem = appropriate to say that this specification SHOULD NOT be used in an ICI = environment unless additional security vulnerability definitions as well = as additional specifications of security requirements are = developed.

Russ

On Feb 1, 2019, at 3:22 PM, Russ Mundy <mundy@tislabs.com> = wrote:



On Jan 31, 2019, at 5:52 AM, Adrian Farrel = <adrian@olddog.co.uk> wrote:

Hi = Russ,

Hi Adrian,


Thanks for = reviewing.

You=E2=80=99re welcome.


A few = responses ...

Summary:

This document defines = defines a methods to achieve Service Function Chaining (SFC) 
using = Network Service Header (NSH) in Multiprotocol Label Switching (MPLS) = networks.

No, it absolutely does not.
To quote from the Abstract...

  This document describes how Service Function = Chaining can be achieved
  in an MPLS network by means of a logical = representation of the NSH in
  an MPLS label stack.

The point of = this document is exactly that it does not use the NSH. Instead it = encodes the fields of the NSH in MPLS headers. This is crucially = important because if one wanted to use the NSH in an MPLS network one = would apply RFC 8300 and draft-ietf-mpls-sfc-encapsulation.

Okay, thanks for the clarification, I = obviously misread what is meant by 'a logical representation of the = NSH'.


Issues:

First, the document and = in particular the Security Considerations section points to published = RFCs
for discussions of the security properties. In = particular, RFC7665 and RFC8300 are referenced 
however each = of these documents left some significant security descriptions & = definitions to be
addressed by implementation documents = such as this one.  Additionally, the SECDIR reviews of
the IDs prior to publication of these RFCs point out several = security related issues that, as far as
I could tell, were = primarily addressed by saying that future implementation specifications = will
address them.  Since this ID is such an = implementation specification, referring to the earlier RFCs
for the security properties results in essentially no = security properties provided in either the 
earlier RFCs = or this  implementation document - security properties need to be = identified avoided
via circular references.

I think you have a good point here that, although the aspects = of security related to SFC are inherited from whatever documents the SFC = WG produces (complete with whatever flaws exist in that set of documents = that need to be patched by that WG), *this* document needs to talk about = the security of the mechanisms that it defines.

That means = some discussion of the security of the MPLS forwarding plane (with = references) and some discussion about what would happen if someone was = able to tamper with a packet (noting that if someone can successfully = tamper with an MPLS packet in flight then they can do a lot of other bad = things as well).

I agree, it's important = for the WG to think about security aspects of functions for each of the = documents it produces. It's also important to be able to describe how a = documents' security aspects relate to the security aspects of related = other technologies, e.g., RFC5920 describes an overall security = framework - it might contain useful information (even though it's status = is Informational).  


Next, = the Security Considerations section identifies that the certain elements = of the design must
be a =E2=80=98trusted resource=E2=80=99 = and that some functions must also be trusted.  The term = =E2=80=9Ctrusted=E2=80=9D in 
relationship = to computing and software has a wide range of different meanings (as = shown by
many years of research in the CS field).  In = the context of this document, my guess is that it
means = that some unidentified (but not defined) entity believes (=E2=80=9Ctrusts=E2= =80=9D) that the software
will do the =E2=80=9Cright = thing=E2=80=9D - to me (from a security perspective) it also means = trusting that the
software will not do the wrong thing. =  All of this is very abstract (both the Security 
Considerations= text & this critique) which in my view is why the 'trust' section = is very
inadequate for an implementation document.

If there is an IETF security definition of "trust" that we = could look at, that would help.

Are you referring to RFC4949 or another = definition?  4949 might provide a useful definition, it's worth = checking to see if there=E2=80=99s something useful there or = elsewhere.


"Do the right = thing" is probably not quite what we mean. 
I think we = mean "Not act maliciously so as to wilfully break the network or send = traffic to/via the wrong places.=E2=80=9D

This certainly sounds = reasonable but I'm not sure where the concept is described - I wasn't = able to find it in RFC5920, RFC7665, or RFC8300.


But this is = all a little like how we "trust" a router. 
A malign = router could drop or redirect packets contrary to the routing = information it has received. We typically test for that in the lab, and = maybe watch for it in the field, but other procedures (such as checking = software images) are generally out of scope for protocol = documents.

I agree that this is a = difficult concept to describe.  Even though protocol documents = don't describe testing requirements and such, section 14 (Implementation = Notes) does lead one to think about what should be done to implement the = specification.  Having some security related implementation notes = there would be helpful and appears to be consistent with information = already in the section.

WRT the Security Considerations section, it would be useful = to review sections 5 - 12 of the document to identify if there are = particular structures or functions that must work correctly or the SFC = design will "fail" (for some value of "fail"). If there are specific = functions or structures that are crucial to the design, it would be = appropriate to identify them in the Security Considerations section. =   


Additionally, the last paragraph of = the Security Considerations section asserts:

Thus the security vulnerabilities are addressed (or should = be
addressed) in all the underlying technologies used by = this design,
which itself does not introduce any new = security vulnerabilities.

As far as I could = see, the assertion is not supported anywhere in the document
itself or other referenced documents, i.e., what = vulnerabilities should the 
implementation= be concerned with (e.g. passive monitoring, active attacks
on metadata, etc??) that result from this implementation. =  Since the 
document does not provide a clear identification of it's = security requirement,
any security services it does (or = might) provide nor require from underlying
technologies, = the assertion should be clarified, supported by additional 
information = or removed from the section.

I *do* = understand where you are coming from on this, but I'm not sure where we = go with it.

Let's = consider for a moment the case of email being carried over an MPLS = network. There is a security vulnerability that passive monitoring of = MPLS packets would allow inspection of the contents of the email. There = are a number of ways to protect against this including encryption at the = application layer (i.e. of the email) and encryption at the transport = layer, and encryption at the IP layer. There is also the possibility to = encrypt the underlying transport (such as MACsec). 

Now, you are = asking about whether this document should discuss the security of any = metadata carried in the MPLS encoding of an SFC system (I realise this = is just one example of the concerns you are raising). And I would say = that it should not. It should observe that metadata is an SFC concept = (SFC is the application using MPLS) and encryption of that data is a = function of the "SFC layer=E2=80=9D.

Thanks for these examples, they do = clarify how the pieces fit together (terminology is always hard) - prior = to the examples, it was not clear that the SFC was roughly an = application using MPLS.  I think that this also means that every = SFC system deployment must determine their own security requirements and = how they will be met _within_ (or by) the particular SFC system, i.e., = neither MPLS nor the Service Function Chaining provide confidentiality, = integrity or other security services often required by = applications.


So maybe a bolder statement could be added to the = document=E2=80=A6

I think text of this = nature is much better than the current paragraph. If my i.e. text above = is correct, it should also be part of the introductory portion (e.g., = neither MPLS or SFC provide security services application functions = require).


"The MPLS forwarding plane does not include any security = mechanisms. That means that procedures described in this document rely = on three basic principles:

- The MPLS network is often considered to be a closed network = such that insertion,
 Modification, or inspection of packets by an outside = party is not possible.

Since RFC5920 includes = InterCarrier Interconnect (ICI), that seems difficult to assert that = MPLS is a "closed network".  Perhaps I'm misinterpreting 5920 but = having different/multiple carriers involved with MPLS forwarding does = not seem to be a "closed network" or perhaps the functions defined in = this document should not be used with MPLS ICI.  I do agree with = the sentiment of the statement but think it needs a bit more = clarification.
 

- The underlying transport mechanisms (such as Ethernet) = between adjacent MPLS
  Nodes may offer security mechanisms that can be = used to defend packets "on the
  Wire"

- The SFC-capable devices participating in the network are = responsible for verifying
  And protecting packets and their = contents.

Would it be clearer if = it read:
- The SFC-capable devices participating in = an SFC system are responsible for verifying and protecting packets and = their contents as well as providing other security capabilities that = might be required in the particular system.


Deployments = of any SFC system will need to consider these issues, especially the = last point. It is expected that a deployment of the techniques defined = in this document would benefit from the more general security mechanisms = defined for SFC."

Thanks,
Adrian

Thank you for the prompt response, = clarifications and explanations..

Russ

= --Apple-Mail=_55B868CF-FF3B-44D1-9148-C251E98359DB-- From nobody Tue Mar 5 17:28:34 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 D9D4A130DD3 for ; Tue, 5 Mar 2019 17:28:14 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=outer-planes-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 WEaAbKNSzlrz for ; Tue, 5 Mar 2019 17:28:12 -0800 (PST) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 5C6DF12F1A5 for ; Tue, 5 Mar 2019 17:28:09 -0800 (PST) Received: by mail-vs1-xe32.google.com with SMTP id n14so1234376vsp.12 for ; Tue, 05 Mar 2019 17:28:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8zudjt73tXrpFrEPGKciRneIYnozOUoORewfhwnvB+c=; b=hRdkNMCfpx2GidQmCr3N0MInrXGKWrhcgWCqlnzw5X0LOqtejTY+KAPIbm8CGCLvip z3fWbFc/XukIcg6XIt5LLo8W//NYZR1ZKHIRh6t5k/jwVyiGZlFcJV7LZWeWDyV7m39Y kylA3gFBQw9hq9lhQVZOx1rO825y8O+q6Z4z+VKOvPzuprPpcsecfQBY9alYpog94hdX STq4H37H1nasyuOqZAp2Bb2bQ7HSsUfYIsRg2FipmfnEJqgPZc6MgHZWgdL3U5+KT4Tz i49Oj9P9KuMDBwSkqN/6BDSnV5Xwe8uj4sLwOAnmxA1YBaEAl9er8zpUutU0DxugADit FxJA== 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=8zudjt73tXrpFrEPGKciRneIYnozOUoORewfhwnvB+c=; b=lgTO9y0UP2x4liJ4Oo4eFV+KIk7Wg7TPaHaSmF1MZFFq1505wn6kIGInsHMEsdq/fc j7Yb42a0x0agpVb1qMUi4pIeevF4uVMKWacYP7+UCm5xnVLmizvfRmtuu5eQSE+LkD7N Z/16oxaCVcl7RVvpR4zkVROMi5YUTLcwrqwA2YZDK2EO2Nv/RIQWYDr2HOyqvBU4Mzsa 0Rk+VpCVWnq/mi5CEKXtXj6QPkURUfHWL+BN0eUVaOoCg+wY7CMLPS0wXKaELkkzWB85 HP8/qYfWGzrhcsBFtNOFVSsWkjLrHOFHi/K+eSOPAtF9rHwKOerIAVESghNwIarOUWEe yIxA== X-Gm-Message-State: APjAAAUSOHeKgu9PFVntpuL5ETyLQpe9ubw6T04Cp1Vi1OEbyxOZbiE/ BixumTPiCf8+JuTg7xAfZDOLJihyxVgyqKLMhGJXRA== X-Google-Smtp-Source: APXvYqx3Gi6SzMKj22QZWnuafPvG7GZLteFAuYdMyBhFo9TSHSTdb3Ycwyu8RIkF//VplIedqkCLXKQzRZsl5SkkX18= X-Received: by 2002:a05:6102:9a:: with SMTP id t26mr2786382vsp.178.1551835688075; Tue, 05 Mar 2019 17:28:08 -0800 (PST) MIME-Version: 1.0 References: <154826649938.7505.11018194912932133243@ietfa.amsl.com> <5CFE429E-31EA-4261-B1CD-17181200F394@cisco.com> <8eaa83e6-5218-9584-ad4e-5e2e7f8e80ad@mozilla.com> In-Reply-To: <8eaa83e6-5218-9584-ad4e-5e2e7f8e80ad@mozilla.com> From: Matthew Miller Date: Tue, 5 Mar 2019 18:27:57 -0700 Message-ID: To: Peter Saint-Andre Cc: "Nancy Cam-Winget (ncamwing)" , "secdir@ietf.org" , "mile@ietf.org" , "draft-ietf-mile-xmpp-grid.all@ietf.org" , "ietf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f019dd058362e602" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mile-xmpp-grid-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: Wed, 06 Mar 2019 01:28:15 -0000 --000000000000f019dd058362e602 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you Nancy and Peter for your replies. I look forward to the next revision. On Mon, Mar 4, 2019 at 7:39 PM Peter Saint-Andre wrote: > A few further thoughts from a co-author but not primary author. > > On 3/4/19 4:00 PM, Nancy Cam-Winget (ncamwing) wrote: > > Hi Matt, thanks for the review. Please see below for comments: > > > > =EF=BB=BFOn 1/23/19, 10:01, "Matthew Miller" > wrote: > > > > Reviewer: Matthew Miller > > 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. > > > > Document: draft-ietf-mile-xmpp-grid-09 > > Reviewer: Matthew A. Miller > > Review Date: 2018-01-23 > > IETF LC End Date: 2019-01-14 > > IESG Telechat date: 2019-01-24 > > > > Summary: > > > > This document defines an architecture for distributing security > > information using publish-subscribe semantics over XMPP. It is > > well written and addressed many (but not all) known concerns > > of a publish-subscribe > > > > This document has issues that should be addressed before it is > > ready to be published as a Proposed Standard. > > > > > > Major Issues: > > > > The document does not explicitly discuss the implications of the > > Controller and Broker having plaintext access and control of the > > published data. It seems to be implied in the section 8.2.3 for > > the Controller (and, for those proficient with XMPP, the Broker). > > I am not strongly recommending any sort of end-to-end protections > > be proscribed (since existing protections are likely unsuitable > > for this architecture). > > [NCW] We have added a sentence in 8.3.3 to address protection > > against controller/broker to employ end-to-end encryption. > > Matt's point about "this architecture" is relevant. We should make it > clearer in the document that the XMPP-Grid is not intended to be an open > system that any arbitrary entity can join; instead, it is a private > network (not connected to the public XMPP network) to which only > authorized entities are allowed access. > Thanks, I think both clarifications will be very helpful. > > The document does not have any real discussion around persistence > > of node items. if they are expected or desired to be persisted, > > then there should be some discussion about retention policies > > (meaning: deployments ought to have one), and behaviors when a > > Platform subscribes to the Topic (e.g., should or may automatically > > send the last published item to the recent subscriber). If not, > > then some discussion on the implications of existing/historic > > data being unavailable through this mechanism. > > [NCW] Fair point. We added the following statements to the document to > address this - > > Note that the control plane may optionally also implement XEP-0203 to > facilitate delayed > > delivery of messages to the connected consumer as described in XEP-0060= . > Since information > > may be timely and sensitive, capability providers should communicate to > the controller > > whether its messages can be cached for delayed delivery during > configuration; such function > > is out of scope for this document. > > In addition, we should mention the "pubsub#last-published" configuration > option. > > Preservation or reconstruction of the history of messages sent to a > Topic strikes me as a service that a Broker isn't required to provide > (e.g., because the history might become quite large), just as a message > archive for an email discussion list might be provided by an entity > other than the delivery service. > I think all of that will help. > > > Minor Issues: > > > > XMPP pubsub is complex, and node configuration reflects that. > > Relying on XEP-0060 is something of a disservice to implementers, > > in my opinion. > > Given the generic publish-subscribe pattern required here, it felt more > appropriate to re-use an existing XMPP extension (of which there are > numerous implementations) than to invent something new. > I could have phrased this concern better; my intent was to try to pave the path for implementers a little better. I absolutely agree using pubsub is the right choice. > > I suggest that an addition Topic creation > > example be added that demonstrates the recommended configuration: > > * pubsub#access-authorize or access-whitelist > > * pubsub#persist_items =3D ?? (1 or 0) > > * pubsub#send_last_published_item =3D ?? (on_sub? never?) > > [NCW] That seems reasonable, I will add it as an option (as the current > section does state it is the minimal for topic creation). > > Yes, on_sub ('When a new subscription is processed') seems appropriate. > > Thanks for this. - m&m Matthew A. Miller --000000000000f019dd058362e602 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Nancy and Peter for your replies.=C2=A0 I l= ook forward to the next revision.

On Mon, Mar 4, 2019 at 7:39 PM Peter Saint= -Andre <stpeter= @mozilla.com> wrote:
A few further thoughts from a co-author but not primary author.=

On 3/4/19 4:00 PM, Nancy Cam-Winget (ncamwing) wrote:
> Hi Matt, thanks for the review.=C2=A0 Please see below for comments: >
> =EF=BB=BFOn 1/23/19, 10:01, "Matthew Miller" <linuxwolf+ietf@= outer-planes.net> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Reviewer: Matthew Miller
>=C2=A0 =C2=A0 =C2=A0Review result: Has Issues
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0I have reviewed this document as part of the securi= ty directorate's
>=C2=A0 =C2=A0 =C2=A0ongoing effort to review all IETF documents being p= rocessed by the
>=C2=A0 =C2=A0 =C2=A0IESG.=C2=A0 These comments were written primarily f= or the benefit of the
>=C2=A0 =C2=A0 =C2=A0security area directors.=C2=A0 Document editors and= WG chairs should
>=C2=A0 =C2=A0 =C2=A0treat these comments just like any other last call = comments.
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0Document: draft-ietf-mile-xmpp-grid-09
>=C2=A0 =C2=A0 =C2=A0Reviewer: Matthew A. Miller
>=C2=A0 =C2=A0 =C2=A0Review Date: 2018-01-23
>=C2=A0 =C2=A0 =C2=A0IETF LC End Date: 2019-01-14
>=C2=A0 =C2=A0 =C2=A0IESG Telechat date: 2019-01-24
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0Summary:
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0This document defines an architecture for distribut= ing security
>=C2=A0 =C2=A0 =C2=A0information using publish-subscribe semantics over = XMPP.=C2=A0 It is
>=C2=A0 =C2=A0 =C2=A0well written and addressed many (but not all) known= concerns
>=C2=A0 =C2=A0 =C2=A0of a publish-subscribe
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0This document has issues that should be addressed b= efore it is
>=C2=A0 =C2=A0 =C2=A0ready to be published as a Proposed Standard.
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0Major Issues:
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0The document does not explicitly discuss the implic= ations of the
>=C2=A0 =C2=A0 =C2=A0Controller and Broker having plaintext access and c= ontrol of the
>=C2=A0 =C2=A0 =C2=A0published data.=C2=A0 It seems to be implied in the= section 8.2.3 for
>=C2=A0 =C2=A0 =C2=A0the Controller (and, for those proficient with XMPP= , the Broker).
>=C2=A0 =C2=A0 =C2=A0I am not strongly recommending any sort of end-to-e= nd protections
>=C2=A0 =C2=A0 =C2=A0be proscribed (since existing protections are likel= y unsuitable
>=C2=A0 =C2=A0 =C2=A0for this architecture).
> [NCW] We have added a sentence in 8.3.3 to address protection
> against controller/broker to employ end-to-end encryption.

Matt's point about "this architecture" is relevant. We should= make it
clearer in the document that the XMPP-Grid is not intended to be an open system that any arbitrary entity can join; instead, it is a private
network (not connected to the public XMPP network) to which only
authorized entities are allowed access.

Thanks, I think both clarifications will be very helpful.


>=C2=A0 =C2=A0 =C2=A0The document does not have any real discussion arou= nd persistence
>=C2=A0 =C2=A0 =C2=A0of node items.=C2=A0 if they are expected or desire= d to be persisted,
>=C2=A0 =C2=A0 =C2=A0then there should be some discussion about retentio= n policies
>=C2=A0 =C2=A0 =C2=A0(meaning: deployments ought to have one), and behav= iors when a
>=C2=A0 =C2=A0 =C2=A0Platform subscribes to the Topic (e.g., should or m= ay automatically
>=C2=A0 =C2=A0 =C2=A0send the last published item to the recent subscrib= er).=C2=A0 If not,
>=C2=A0 =C2=A0 =C2=A0then some discussion on the implications of existin= g/historic
>=C2=A0 =C2=A0 =C2=A0data being unavailable through this mechanism.
> [NCW] Fair point. We added the following statements to the document to= address this -
> Note that the control plane may optionally also implement XEP-0203 to = facilitate delayed
> delivery of messages to the connected consumer as described in XEP-006= 0. Since information
> may be timely and sensitive, capability providers should communicate t= o the controller
> whether its messages can be cached for delayed delivery during configu= ration; such function
> is out of scope for this document.

In addition, we should mention the "pubsub#last-published" config= uration
option.

Preservation or reconstruction of the history of messages sent to a
Topic strikes me as a service that a Broker isn't required to provide (e.g., because the history might become quite large), just as a message
archive for an email discussion list might be provided by an entity
other than the delivery service.

I thin= k all of that will help.
=C2=A0

>=C2=A0 =C2=A0 =C2=A0Minor Issues:
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0XMPP pubsub is complex, and node configuration refl= ects that.
>=C2=A0 =C2=A0 =C2=A0Relying on XEP-0060 is something of a disservice to= implementers,
>=C2=A0 =C2=A0 =C2=A0in my opinion.

Given the generic publish-subscribe pattern required here, it felt more
appropriate to re-use an existing XMPP extension (of which there are
numerous implementations) than to invent something new.
=C2=A0
I could have phrased this concern better; my intent = was to try to pave the path for implementers a little better.=C2=A0 I absol= utely agree using pubsub is the right choice.


>=C2=A0 I suggest that an addition Topic creation
>=C2=A0 =C2=A0 =C2=A0example be added that demonstrates the recommended = configuration:
>=C2=A0 =C2=A0 =C2=A0* pubsub#access-authorize or access-whitelist
>=C2=A0 =C2=A0 =C2=A0* pubsub#persist_items =3D ?? (1 or 0)
>=C2=A0 =C2=A0 =C2=A0* pubsub#send_last_published_item =3D ?? (on_sub? n= ever?)
> [NCW] That seems reasonable, I will add it as an option (as the curren= t section does state it is the minimal for topic creation).

Yes, on_sub ('When a new subscription is processed') seems appropri= ate.


Thanks for this.
=C2=A0
- m&m
Matthew A. Mil= ler

--000000000000f019dd058362e602-- From nobody Wed Mar 6 00:56:37 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 193F7130ED4 for ; Wed, 6 Mar 2019 00:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, 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=ericsson.com header.b=dWdWFXZm; dkim=pass (1024-bit key) header.d=ericsson.com header.b=kHBA5qPn 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 qn_3wXhGgvCk for ; Wed, 6 Mar 2019 00:56:25 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 6D64E130ECA for ; Wed, 6 Mar 2019 00:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551862581; x=1554454581; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xJUqlH2jef1uFI/GmaoO8nNdvnWkxP3wOmzWCbkqbec=; b=dWdWFXZmwD94+E085P/oiXdFM3y3YF6/wYRzEpYqket2FGS2dk+0ifMuUFcOGAMV OjajX7/B5Agy+plJ77pWbq4mlujvesyrNNs3nER1UC8PEW9WBpVlxXJiYBWR87ga ijN4cuKNJrG4nPAMfN9RD4cWdaUiZwMvBFc5A2LYuFE=; X-AuditID: c1b4fb30-fabff7000000355c-25-5c7f8b35b74e Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 02.98.13660.53B8F7C5; Wed, 6 Mar 2019 09:56:21 +0100 (CET) Received: from ESESBMR504.ericsson.se (153.88.183.139) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Mar 2019 09:56:21 +0100 Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESBMR504.ericsson.se (153.88.183.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Mar 2019 09:56:21 +0100 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 6 Mar 2019 09:56:20 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xJUqlH2jef1uFI/GmaoO8nNdvnWkxP3wOmzWCbkqbec=; b=kHBA5qPnDnFcKI/bQsKXeUJPmK+l/yEQBaAo5QbLbz6COePJReDdqAYs4dBHbbxpfWibEKr4YBTr4V1WBZ5BDBgyltpChVY69L4h3oDdKBWrJJHfn2m5hBXYvgDYilVenPPl5XYhoBBkZNrQuBKPMRj/oiWspUvw0wSsF8mosz8= Received: from DB6PR0701MB2438.eurprd07.prod.outlook.com (10.168.72.151) by DB6PR0701MB2711.eurprd07.prod.outlook.com (10.169.215.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.11; Wed, 6 Mar 2019 08:56:20 +0000 Received: from DB6PR0701MB2438.eurprd07.prod.outlook.com ([fe80::ac69:ffe9:c4ad:2567]) by DB6PR0701MB2438.eurprd07.prod.outlook.com ([fe80::ac69:ffe9:c4ad:2567%12]) with mapi id 15.20.1686.016; Wed, 6 Mar 2019 08:56:20 +0000 From: Miika Komu To: David Waltermire , "secdir@ietf.org" CC: "hipsec@ietf.org" , "draft-ietf-hip-dex.all@ietf.org" , "ietf@ietf.org" Thread-Topic: [Hipsec] Secdir last call review of draft-ietf-hip-dex-06 Thread-Index: AQHTrEpTSI+7rWzwMU+YynlMP3PA0qYAnFMA Date: Wed, 6 Mar 2019 08:56:19 +0000 Message-ID: References: <151935130185.22539.7608018209255295739@ietfa.amsl.com> In-Reply-To: <151935130185.22539.7608018209255295739@ietfa.amsl.com> Accept-Language: fi-FI, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: HE1PR05CA0373.eurprd05.prod.outlook.com (2603:10a6:7:94::32) To DB6PR0701MB2438.eurprd07.prod.outlook.com (2603:10a6:4:5b::23) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [192.176.1.92] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9818d095-5981-4fc3-415b-08d6a21199b4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:DB6PR0701MB2711; x-ms-traffictypediagnostic: DB6PR0701MB2711: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtEQjZQUjA3MDFNQjI3MTE7MjM6b25BU2RzbGFXQWkvMngraG45Wmw1U2dV?= =?utf-8?B?bWhGS05hLzlKL3RZdTFPN3dYTGZvamRhbW43R09xaTNoL3d0TktweCtYUlhk?= =?utf-8?B?eFFlZjBvN2ZYcEhzdWF2OUIzTzliZm5yWHJhaUc2R0gvRTBOWjdpT3M2SmlF?= =?utf-8?B?OVVjbnlISm5qcFNFeW5rME9rSlNYbWFjK0h2RnVBa2I1Um5aWklidEVSMzRF?= =?utf-8?B?VCtiUHg0OVhHb0RiNDVKNm5scnN6T3RjRm12clNkU1MvOHozdEhjUzYxckdP?= =?utf-8?B?TDdRYWg3amRoc1BwVVVvUnVxM0k0eHpEV2FyQ3ZDR1ZNTzdnSC8ya2lsSUlW?= =?utf-8?B?UjJETFpvZlhQZGt6d0RzeVNtTkFBZGFiM3JmUTVKay9rdVJzRng5VlRrQlFR?= =?utf-8?B?SG0vYnN6MkUyb2FIWFZ3R0x4L1Vrc0paVlY2UFArcG9DK2Y4S3g4RmduOVU4?= =?utf-8?B?cEF3cm1WTEZGZUFzRVNQeGtEOXJXS3djVHQ3cEdQdXNsRHdlTWZBalNzdS9l?= =?utf-8?B?SkltdXpHUVNoME1WTE5BMEFzU0tRRS96RGhaUG1zSFlYc0ZoZUNsRTl3cWc1?= =?utf-8?B?dVNTMi9NelUxMnpWZGF5Q3ZYZTZkRmNFT3pONjZ4eDJqakU2dDRQalNLSzBD?= =?utf-8?B?aEE3R0lFUCtNeDlwaU0xNUZBdVhBTUVJaHFqRDNCdXlLZS8xc2xuNTVndWc0?= =?utf-8?B?NDRldy96VzYzSEtsZXdkTFBYbGJRdUg4ejg4SlpRMUlHSkF1NHkyN29JK0xo?= =?utf-8?B?SnNNbDdaVndiVkNCdzJmenMwUWFNbW1GWmM1UjVVTit0MmhVaVBWN3VxcEpW?= =?utf-8?B?OE1nVjM2UkMrR21KRUJNUXpkL0daNXRaTFZTckEweXZIVVNielVrK0hIU2Nm?= =?utf-8?B?ZkhBc3NmZ1lkRTh2MjdvcWJ2MlduUHNsN2Q2cUtmcGMxaTlBNDh0REJIUWN5?= =?utf-8?B?bUpSNElhZkIrRTlDd3JIL3FueWxzclVQQ3dLYjAyN3FkUXIzVEFCOGtCZmRO?= =?utf-8?B?S3N5cW1JeUVzbjZEYVVQaE9ZVXd0bzRXZnRJYzYrWjlNaWcwMWg1Q2FrOHV2?= =?utf-8?B?eUtKeGV0K204bTFDVzBTWFcxZDBRaW5Xc0Ivd2wzSmN3Y2JqZDR3azNmOG5E?= =?utf-8?B?OGRtdE9OT1VPWEZVYUdxcVp0aW9yRDFXZzR2RXVLZUR1ZzByR0J6bTkwZkxi?= =?utf-8?B?VmRLelZ4RUhUYmhnN1dwOWp3cmlxUXhIU01BWmdpZmpVL2dIcU9ZVFZRTURO?= =?utf-8?B?N2llRk91blRER3ZCNFNqMVhqWnBRU1hSQk84MUc0YjFMVVUzYTNpdVQ0YzAy?= =?utf-8?B?QWlmUitmcHhNWGdNQ1pEcll2Q3dDWEZCeXJlakdTc3BqUjk3QXZTeEN1R1Va?= =?utf-8?B?ZDV1djk3Yzc5MkN6TnlpakxkYkQzbXNqVzVXVnNzWnF0dlZIaldiTkovQjFN?= =?utf-8?B?OEZabGhicUlsemZUWFU1SWpNZ0ZFRktBNWNQTjJzdk9uTmEvMGdGTFM5dGMz?= =?utf-8?B?OERPbUdyY0VOaXFpajhWS29VZS9idE1SMElYcy9GS2NxYWhaRmVEUmwxQ1E0?= =?utf-8?B?cUZsSlU5b096NVhPZnMyUWptWEtnVzhybVhvYjViWm45bU50NE83WkptMy9P?= =?utf-8?B?TjhPWnpETDZJT29MRndVNXJ1NlFUNHgrc05pcG5FR0REN1R6VTd6N0hJT0g4?= =?utf-8?B?ejNvU29PZkNZMmpJV1lhaTU1dDdCVUZjaXNGUkNWL1BZUGVxY09GWVA1UGth?= =?utf-8?B?b1F0MTB5ZXdrSHFTVE41bGIva2h5Tk9uUWpXVXdOcmREUkJFV1VYM0x2ZGJw?= =?utf-8?B?MlJkOFJYUnNhcWFHNzFZcHdtVzB4OS9sd0hXWEVqNktUeGk2UmpwQXpSQ0p3?= =?utf-8?Q?Hd/TnnPP1zTivQmdOvmJJinZWeDJl/ou3i?= x-microsoft-antispam-prvs: x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(366004)(39860400002)(376002)(346002)(85644002)(199004)(189003)(81156014)(6436002)(71200400001)(6512007)(76176011)(36756003)(97736004)(66066001)(6486002)(2906002)(5660300002)(14444005)(6116002)(3846002)(52116002)(256004)(71190400001)(6306002)(99286004)(68736007)(86362001)(110136005)(6506007)(102836004)(386003)(31696002)(8936002)(53546011)(53936002)(305945005)(316002)(229853002)(6346003)(54906003)(478600001)(486006)(446003)(11346002)(2501003)(476003)(2616005)(7736002)(44832011)(26005)(4326008)(186003)(106356001)(25786009)(966005)(31686004)(105586002)(14454004)(6246003)(81166006)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0701MB2711; H:DB6PR0701MB2438.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=miika.komu@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: PrKbwUdmvXrJeLm8+zAWHtuIsEef1PY0CS/B1EEfux7xeC9ORCxZGzgAgmlkAbgvKtvSUmyGcdSjBpT2wszhgx7dlAnuBq7xBDqG4sLGfW/qgZYZgJk+Cn5zxAGozgNArvCR5Y7Ug/6uVTveK4uqdo6Pp635Gkoegh3kmcMVuhJoQEzWk6zJWr05GF5XIPb5cZejZ0tVdvIPqYAFMFbdsQ5PxjFe1mumoTwKhcOUx7rQL3VFUoqnZEe/ZH8LDppp6li+94s2BK6OkpmgAue621AnNoH7YiIJTk3aalsT5WWW1VbWeBO20azgJnnFxrqzWAmz5NeRZxYexbN4R5N4fZGdzeyZGhY8UF/kDaBGTKgr1+0vFaiYkOYEN6t9TK1HZmTNoOTrqwLLkE5mRV6RUZZpWOQq41iFQ9ObsjfmMus= Content-Type: text/plain; charset="utf-8" Content-ID: <9ABC0562EE854049AC80F5D2FD2B27F9@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9818d095-5981-4fc3-415b-08d6a21199b4 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2019 08:56:19.9417 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2711 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHfd733fZuNHhcigdFyyGEVmrDYkVUkpQW2vqklJFL33Repm3T 1D54ISy80MJWTZfLKyVCXvFCmQ0LBopopnmJNS8TMdG8IJJabq9F337/8z//55wDD02KKjnu tEKpYVRKebKYK6D0Ue33jh4vyokO7M3zkTYV73ClY/rPSKqrKiWltiYjJV2utFLnOKE1NZtE 6Ih5myMjrglOxzHJigxGFXAmRpCgbzyUtpOcaXo/yM1FzxMLEZ8GHARLxnGqEAloEe5F8Fvb TLBiHUHXu0H0T1i+j+851QR8m8rl2QWFtSRYFoa5rPOUgNXHWyQrbAi+Fq8S9jFc7Af1k6Ok nV1wJLQXzzriJH6EoHvYTNmN/fgCzA3nc9imi9C6rUcsS6Dn1ZzjIQr7gK6ki2tnIT4Lg6Vr jqwIn4e+5ZHdLE3zcQgUGBznIewJr1t2HHNJ7AbjM0aCPRtDzdsBkmVXmJ/e4dj3AaxDMKWt 22s6Av2jM4jlg7A1NMVl2ROGjEV79XAwV42QbHgCwYp2nWdfwh6+P+HF9rjDxvRPHtszK4L+ zXIOa6TCSu0AoUWSsv8WLNuNk9gX3nQFsOVQ+FJt4LHsDU+KrA4WYmcw62eol4hTj1zVjPpW SrxE4s+oFLFqdarSX8lomtHux/nQ+iuwA83PBZsQppF4n/Bufk60iCPPUGelmBDQpNhFqM/b LQnj5FnZjCr1pio9mVGbkAdNid2EWyLnaBGOl2uYJIZJY1R/XYLmu+ciH9+elkWNV7zllNMJ 7yuFP154zOgaGivqo5bqalOLjE5jQSc7esLCfakDk8oI29WIxIKQzDsNWZFWz4wxQ4gwVrby rPNTiSW9XNY9r0Up1hsTgphLbdlhix87uWtJSQUby5O29cOXHwoeTLY5WQwVTq59VZu62z7B 1/kKWdvQgphSJ8iP+ZEqtfwPZYb3szQDAAA= Archived-At: Subject: Re: [secdir] [Hipsec] Secdir last call review of draft-ietf-hip-dex-06 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, 06 Mar 2019 08:56:28 -0000 SGkgRGF2aWQsDQoNCkkgYW0gc3RlcHBpbmcgaW4gYW5kIGhlbHBpbmcgdGhlIGF1dGhvcnMgdG8g ZmluaXNoIHRoZSBkcmFmdCBhcyBhZ3JlZWQgDQp3aXRoIHRoZSBhdXRob3JzIGFuZCBISVAgV0cg Y2hhaXIuIEkgYW0gbm90IGFjdGl2ZWx5IHdvcmtpbmcgb24gdGhlIA0KdG9waWMsIHNvIEkgaGF2 ZSB2ZXJ5IGxpbWl0ZWQgdGltZSBmb3IgdGhpcyBidXQgSSBoYXZlIGVhcmxpZXIgDQpiYWNrZ3Jv dW5kIGluIEhJUC4gUGxlYXNlIGxldCBtZSBrbm93IGlmIHRoZSBmb2xsb3dpbmcgY29tbWVudHMg YW5kIA0KZWRpdHMgYWRkcmVzcyB5b3VyIGNvbmNlcm5zPw0KDQpPbiAyLzIzLzE4IDA0OjAxLCBE YXZpZCBXYWx0ZXJtaXJlIHdyb3RlOg0KPiBSZXZpZXdlcjogRGF2aWQgV2FsdGVybWlyZQ0KPiBS ZXZpZXcgcmVzdWx0OiBIYXMgSXNzdWVzDQo+IA0KPiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1 bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcNCj4gZWZm b3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJ RVNHLiAgVGhlc2UNCj4gY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJl bmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLg0KPiAgIERvY3VtZW50IGVkaXRv cnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFu eSBvdGhlcg0KPiBsYXN0IGNhbGwgY29tbWVudHMuDQo+IA0KPiBUaGUgc3VtbWFyeSBvZiB0aGUg cmV2aWV3IGlzIFJlYWR5IHdpdGggaXNzdWVzLg0KPiANCj4gSW4gZ2VuZXJhbCB0aGlzIGRvY3Vt ZW50IGlzIGNsZWFybHktd3JpdHRlbiBhbmQgd2VsbC1vcmdhbml6ZWQuIEl0IHdhcyBhIGZ1bg0K PiByZWFkIG92ZXJhbGwuDQo+IA0KPiBJIGhhdmUgdGhlIGZvbGxvd2luZyBjb25jZXJucyB3aXRo IHRoZSBkcmFmdDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFNlY3Rpb24gMi4xOg0KPiANCj4gWW91IHNob3VsZCB1 c2UgdGV4dCBmcm9tIFJGQzgxNzQgdG8gaW5kaWNhdGUgdGhhdCBsb3dlcmNhc2UgdmVyc2lvbnMg b2YgdGhlDQo+IGtleXdvcmRzIGFyZSBub3Qgbm9ybWF0aXZlLg0KPiANCj4gU29tZXRoaW5nIGxp a2UgdGhlIGZvbGxvd2luZyB3b3VsZCB3b3JrOg0KPiANCj4gICAgIFRoZSBrZXkgd29yZHMgIk1V U1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCj4gICAg ICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJOT1QgUkVDT01NRU5ERUQi LCAiTUFZIiwgYW5kDQo+ICAgICAiT1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIHRvIGJl IGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBCQ1ANCj4gICAgIDE0IFtSRkMyMTE5XSBbUkZD ODE3NF0gd2hlbiwgYW5kIG9ubHkgd2hlbiwgdGhleSBhcHBlYXIgaW4gYWxsDQo+ICAgICBjYXBp dGFscywgYXMgc2hvd24gaGVyZS4NCg0KZml4ZWQuDQoNCj4gU2VjdGlvbiA0LjEuMy4xOg0KPiAN Cj4gIml0IGNhbiBiZSBsb25nLWxpdmVkIHdpdGggbm8gbmVlZCBmb3IgcmVrZXlpbmciIFNtYWxs IGlzIG9wZW4gdG8NCj4gaW50ZXJwcmV0YXRpb24uIEl0IHdvdWxkIGJlIHVzZWZ1bCB0byBpbmNs dWRlIHNvbWUgZ3VpZGFuY2Ugb24gdGhlIGV4cGVjdGVkDQo+IGFtb3VudCBvZiBkYXRhIHRvIGJl IGV4Y2hhbmdlZCBiZWZvcmUgcmVrZXlpbmcgd291bGQgYmUgbmVlZGVkLCBvciB3aHkgdGhpcyBp cw0KPiBhIHByYWN0aWNhbCBpbXBvc3NpYmlsaXR5Lg0KDQpyZWtleWluZyBpcyBzdWJqZWN0IHRv IGxvY2FsIHBvbGljaWVzLCBidXQgYSBoYXJkIGxpbWl0IGV4aXN0cy4gSSBhZGRlZCANCnRoZSBm b2xsb3dpbmcgc2VudGVuY2U6DQoNCkF0IHRoZSBsYXRlc3QsIHRoZSBzeXN0ZW0gTVVTVCBpbml0 aWF0ZQ0KcmVrZXlpbmcgd2hlbiBpdHMgaW5jb21pbmcgRVNQIHNlcXVlbmNlIGNvdW50ZXIgaXMg Z29pbmcgdG8gb3ZlcmZsb3csDQphbmQgaGUgc3lzdGVtIE1VU1QgTk9UIHJlcGxhY2UgaXRzIGtl eWluZyBtYXRlcmlhbCB1bnRpbCB0aGUgcmVrZXlpbmcNCnBhY2tldCBleGNoYW5nZSBzdWNjZXNz ZnVsbHkgY29tcGxldGVzIGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDYuOCBpbg0KW1JGQzc0MDJd Lg0KDQo+IFNlY3Rpb24gNS4zLjIgYW5kIDUuMy4zOg0KPiANCj4gSW4gdGhlIHBhcmFncmFwaCBv biBUUkFOU1BPUlRfRk9STUFUX0xJU1QsIGl0IHdvdWxkIGJlIGdvb2QgdG8gZG9jdW1lbnQgdGhl DQo+IHNwZWNpZmljIEVTUCBwYXJhbWV0ZXIgdmFsdWUgdG8gYmUgdXNlZCBmcm9tOg0KPiBodHRw czovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9oaXAtcGFyYW1ldGVycy9oaXAtcGFyYW1ldGVy cy54bWwjdHJhbnNwb3J0LW1vZGVzLg0KPiBUaGlzIHdpbGwgcmVtb3ZlIGFueSBhbWJpZ3VpdHku DQoNCkkgY2hhbmdlZCB0aGUgc2VudGVuY2UgcmVmZXJyaW5nIHRvIHRoZSBwYXJhbWV0ZXIgdmFs dWUgdG8gYmUgbW9yZSBzcGVjaWZpYzoNCg0KVGhlIGRpZmZlcmVudCBmb3JtYXQgdHlwZXMgYXJl IERFRkFVTFQsIEVTUCBhbmQgRVNQLVRDUCBhcyBleHBsYWluZWQgaW4gDQpTZWN0aW9uIDMuMSBp biBbUkZDNjI2MV0uDQoNClRoZSBhY3R1YWwgY2hvaWNlKHMpIGRlcGVuZCBvbiBsb2NhbCBwb2xp Y3ksIEkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIA0KbWFuZGF0ZSBhIHNwZWNpZmljIG9uZSBoZXJl Lg0KDQo+IFNlY3Rpb24gNi42Og0KPiANCj4gSW4gaXRlbXMgIzUgYW5kICM2LCB3aGF0IGlzICJh biBhY2NlcHRhYmxlIHRpbWUgc3BhbiI/IFNvbWUgZ3VpZGFuY2UgaGVyZSB3b3VsZA0KPiBiZSBo ZWxwZnVsLiBJIGJlbGlldmUgdGhpcyBpcyBkaXNjdXNzZWQgZWFybGllciBpbiB0aGUgZHJhZnQu IFBlcmhhcHMgYQ0KPiByZWZlcmVuY2UgYmFjayBtYXkgcHJvdmlkZSBzb21lIGNsYXJpdHk/DQoN CnRoaXMgZXh0ZW5zaW9uIGJ1aWxkcyBvbiBSRkM3NDAxIHdoaWNoIGRvZXMgZ2l2ZSBhbnkgZXhw bGljaXQgdGltZSANCnZhbHVlcyBlaXRoZXI6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM3NDAxI3NlY3Rpb24tNi44DQoNClNvIEkgYW0gYSBiaXQgaGVzaXRhbnQgdG8gYWRkIGV4 cGxpY2l0IHRpbWVvdXRzIGhlcmUuDQoNCj4gU2VjdGlvbiA2Ljk6DQo+IA0KPiBJbiAjMSwgdW5k ZXIgd2hhdCBjaXJjdW1zdGFuY2VzIHdvdWxkIHRoZSBOT1RJRlkgcGFja2V0IG5vdCBiZSBkcm9w cGVkDQo+IHNpbGVudGx5PyBXaHkgaXMgdGhpcyBub3QgYSBNVVNUPyBTb21lIGV4cGxhbmF0aW9u IHdvdWxkIGJlIHVzZWZ1bCBoZXJlLiBJbg0KPiBnZW5lcmFsLCBtYW55IG9mIHRoZSBTSE9VTERz IGluIHRoZSBzZWN0aW9uIDYgc3Vic2VjdGlvbnMsIGNvdWxkIHVzZSBmdXJ0aGVyDQo+IGp1c3Rp ZmljYXRpb24uDQoNCmdvb2QgcG9pbnQsIEkgY2hhbmdlZCB0aGUgZXhwbGljaXRseSBtZW50aW9u ZWQgU0hPVUxEIHRvIE1VU1QuDQoNClNvbWUgb2YgU0hPVUxEcyBpbiBzZWN0aW9uIDYgYXJlIGlu aGVyaXRlZCBmcm9tIFJGQzc0MDEuIEkgd291bGQgbGlrZSB0byANCmdvIHRocm91Z2ggYWxsIG9m IHRoZSBTSE9VTERzIGluIHNlY3Rpb24gNiBidXQgaXQgd2lsbCBkZWxheSB0aGUgYWxyZWFkeSAN CmRlbGF5ZWQgcHJvY2VzcyBmb3IgdGhpcyBkcmFmdC4gSWYgd2UgY2hhbmdlIHNvbWUgb2YgdGhl IFNIT1VMRHMgdG8gDQpNVVNUcywgSSBiZWxpZXZlIHdlIG5lZWQgYWxzbyBXRyBjb25jZW5zdXMu IFNvLCBhcyBhIHF1aWNrIHJlc29sdXRpb24gSSANCmp1c3QgYWRkZWQgdGhlIGZvbGxvd2luZyBu b3RlIHRvIHNlY3Rpb24gNiBpbnRybzoNCg0KSXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgbWFueSBv ZiB0aGUgcGFja2V0IHByb2Nlc3NpbmcgcnVsZXMgYXJlIGRlbm90ZWQgDQpoZXJlIHdpdGggIlNI T1VMRCIgYnV0IG1heSBiZSB1cGRhdGVkIHRvICJNVVNUIiB3aGVuIGZ1cnRoZXIgDQppbXBsZW1l bnRhdGlvbiBleHBlcmllbmNlIHByb3ZpZGVzIGJldHRlciBndWlkYW5jZS4NCg0KLi4ud2hpY2gg SSBiZWxpZXZlIHJlZmxlY3RzIHRoZSBjdXJyZW50IHJlYWxpdHkuDQoNCj4gU2VjdGlvbiA4Og0K PiANCj4gV2hhdCBpcyAiYSByZWFzb25hYmxlIGRlbHRhIHRpbWUiPyBTb21lIGd1aWRhbmNlIGhl cmUgd291bGQgYmUgdXNlZnVsLg0KDQpnb29kIGNhdGNoLiBUaGUgc2l0dWF0aW9uIGlzIGFjdHVh bGx5IHJlbGF0ZWQgdG8gc2VuZGluZyBvZiBJMSBwYWNrZXRzLCANCnNvIEkgd291bGQgYWN0dWFs bHkgY2hhbmdlIHRoZSB0aW1lIGRlbHRhIHRvIGEgcGFja2V0IGNvdW50ZXIgc2ltaWxhcmx5IA0K YXMgaW4gUkZDNzQwMToNCg0KQXMgYW4gYWR2ZXJzYXJ5IGNvdWxkIGFsc28gc2VuZCBzdWNoIGFu IElDTVANCnBhY2tldCBpbiBhIG1hbi1pbi10aGUtbWlkZGxlIGF0dGFjayB3aXRoIHRoZSBhaW0g dG8gcHJldmVudCB0aGUgSElQDQpERVggaGFuZHNoYWtlIGZyb20gY29tcGxldGluZywgdGhlIElu aXRpYXRvciBTSE9VTEQgTk9UIHJlYWN0IHRvIGFuDQpJQ01QIG1lc3NhZ2UgYmVmb3JlIHJldHJh bnNtaXNzaW9uIGNvdW50ZXIgcmVhY2hlcyBJMV9SRVRSSUVTX01BWCBpbg0KaXRzIHN0YXRlIG1h Y2hpbmUgKHNlZSBUYWJsZSAzIGluIFtSRkM3NDAxXSkuDQoNCj4gU2VjdGlvbiA5IChTZWN1cml0 eSBDb25zaWRlcmF0aW9ucyk6DQo+IA0KPiAiVGhlIHB1enpsZSBtZWNoYW5pc20gdXNpbmcgQ01B QyBtYXkgbmVlZCBmdXJ0aGVyIHN0dWR5IHJlZ2FyZGluZyB0aGUgbGV2ZWwgb2YNCj4gZGlmZmlj dWx0eS4iIFN0dWR5IG9mIHdoYXQ/IElzIHRoZSBjb25jZXJuIGhlcmUgdGhhdCB0aGUgaW1wYWN0 IG9uIGNvbnN0cmFpbmVkDQo+IGRldmljZXMgYXQgYSBoaWdoZXIgbGV2ZWwgb2YgZGlmZmljdWx0 eSBpcyBub3Qgd2VsbCB1bmRlcnN0b29kPyBPciBpcyB0aGlzDQo+IGNvbmNlcm4gYXJvdW5kIGlk ZW50aWZ5aW5nIGJlc3QgcHJhY3RpY2VzIGFyb3VuZCByYWlzaW5nIHRoZSBkaWZmaWN1bHR5IHVu ZGVyDQo+IHNwZWNpZmljIGNvbmRpdGlvbnM/IEEgc2VudGVuY2Ugb3IgdHdvIG9uIHRoaXMgd291 bGQgYmUgaGVscGZ1bCBmb3IgdGhlIHJlYWRlcg0KPiB0byBiZXR0ZXIgdW5kZXJzdGFuZCB0aGUg aXNzdWUuDQoNCkl0IG1lYW5zIGZpbmRpbmcgcHV6emxlIHZhbHVlcyB0aGF0IGRvbid0IGV4aGF1 c3QgY29tcHV0YXRpb25hbCANCnJlc291cmNlcyB3aXRoIHNlbnNvcnMuIEkgY2hhbmdlZCB0aGUg c2VudGVuY2UgdG86DQoNCiJUaGUgcHV6emxlIG1lY2hhbmlzbSB1c2luZyBDTUFDIG1heSBuZWVk IGZ1cnRoZXIgc3R1ZHkgcmVnYXJkaW5nIHRoZQ0KDQpsZXZlbCBvZiBkaWZmaWN1bHR5IGluIG9y ZGVyIHRvIGVzdGFibGlzaCBiZXN0IHByYWN0aWNlcyB3aXRoIGN1cnJlbnQNCg0KZ2VuZXJhdGlv biBvZiBjb25zdHJhaW5lZCBkZXZpY2VzLiINCg0KPiBJIGRvbid0IHNlZSBhIG1lbnRpb24gb2Yg dGhlIG5vbi1wcm90ZWN0ZWQgSG9zdCBJZGVudGl0eSBpc3N1ZSBmcm9tIHNlY3Rpb24gMS4xDQo+ IGhlcmUuDQoNCkkgYWRkZWQgYW4gZXh0cmEgYnVsbGV0Og0KDQpDb250cmFyeSB0byBISVB2Miwg SElQIERFWCBkb2VzIG5vdCBwcm92aWRlIGZvciBlbmQtcG9pbnQNCmFub255bWl0eSBmb3IgdGhl IEluaXRpYXRvciBvciBSZXNwb25kZXIuICBUaHVzLCBhbnkgc2lnbmFsaW5nDQp0aGF0IGluZGlj YXRlcyBzdWNoIGFub255bWl0eSBzaG91bGQgYmUgaWdub3JlZCBhcyBleHBsYWluZWQgaW4NClNl Y3Rpb24gMS4xLg0KDQo+IFdpdGggcmVnYXJkcyB0byB0aGUgNHRoIGJ1bGxldCwgdGhlIHRleHQg aW4gc2VjdGlvbiAzIHNob3VsZCBiZSByZWZlcmVuY2VkDQo+IHJlZ2FyZGluZyBISVQgY29sbGlz aW9ucy4gKG5pdCktPiBSZWZlcmVuY2luZyBiYWNrIHRvIHRoZSByZWxldmFudCBzZWN0aW9ucyBm b3INCj4gdGhlIG90aGVyIGJ1bGxldHMgbWF5IGFsc28gYmUgdXNlZnVsLg0KDQpEb25lIQ0KDQo+ PkZyb20gc2VjdGlvbiA1LjMuMSwgSSBkb24ndCBzZWUgYSBtZW50aW9uIG9mIHRoZSBpc3N1ZXMg YXJvdW5kIGRlYWxpbmcgd2l0aCBJMQ0KPiBzdG9ybXMgYWRkcmVzc2VkIGhlcmUuDQoNCkFkZGVk Og0KDQogICAgU2VjdGlvbiA1LjMuMSBtZW50aW9ucyB0aGF0IGltcGxlbWVudGF0aW9ucyBuZWVk IHRvIGJlIGFibGUgdG8gaGFuZGxlDQogICAgc3Rvcm1zIG9mIEkxIHBhY2tldHMuICBDb250cmFy eSB0byBISVB2MiwgUjEgcGFja2V0cyBjYW5ub3QgYmUgcHJlLQ0KICAgIGNvbXB1dGF0ZWQgaW4g SElQIERFWCBhbmQgYWxzbyB0aGUgc3RhdGUgbWFjaGluZSBkb2VzIG5vdCBpbmNsdWRlIGFuDQog ICAgIlIxX1NFTlQiIHN0YXRlICh0aGF0IHdvdWxkIGVuYWJsZSBjYWNoaW5nIG9mIFIxIHBhY2tl dHMpLg0KICAgIFRoZXJlZm9yZSwgYW4gaW1wbGVtZW50YXRpb24gaGFzIHRvIGNhY2hlIGluZm9y bWF0aW9uIChlLmcuLCBhdCBsZWFzdA0KICAgIHRoZSBISVRzKSBmcm9tIGluY29taW5nIEkxIHBh Y2tldHMgYW5kIHJhdGUgY29udHJvbCB0aGUgaW5jb21pbmcgSTENCiAgICBwYWNrZXRzIHRvIGF2 b2lkIHVubmVjZXNzYXJ5IHBhY2tldCBwcm9jZXNzaW5nIGR1cmluZyBJMSBwYWNrZXQNCiAgICBz dG9ybXMuDQoNCj4gU2VjdGlvbiAxMDoNCj4gDQo+IEl0IGNhbiBiZSB1c2VmdWwgZm9yIElBTkEg dG8gcmVmZXJlbmNlIHRoZSBzcGVjaWZpYyByZWdpc3RyeSBieSBuYW1lIGFuZCBVUkwgaW4NCj4g dGhlIElBTkEgY29uc2lkZXJhdGlvbnMuIEl0IGNhbiBhbHNvIGJlIHVzZWZ1bCB0byBpbmNsdWRl IHRoZSBhY3R1YWwgdGFibGUgaW4NCj4gdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbi4g VGhlc2UgYXJlIGVtYmVkZGVkIGluIHNlY3Rpb24gNSBpbiB0aGUgY3VycmVudA0KPiBkb2N1bWVu dC4gU3VnZ2VzdCBtb3ZpbmcgdGhlc2UgdGFibGVzIHRvIHRoZSBJQU5BIGNvbnNpZGVyYXRpb24g c2VjdGlvbi4NCg0KSSB0aGluayBpdCB3b3VsZCBicmVhayB0aGUgZmxvdyBvZiB0aGUgdGV4dC4g SW5zdGVhZCwgSSBkb3VibGUgY2hlY2tlZCANCnRoYXQgYWxsIG5ldyBwYXJhbWV0ZXJzIGFyZSBs aXN0ZWQgaW4gdGhlIElBTkEgc2VjdGlvbiBhbmQgcmVwbGljYXRlZCANCnRoZSB0eXBlIHZhbHVl cyB0aGVyZS4NCg0KPiBJIGZvdW5kIHRoZSBmb2xsb3dpbmcgbml0cyBpbiB0aGUgZHJhZnQ6DQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+ IFNlY3Rpb24gMS4xOg0KPiANCj4gSW4gdGhlIHRleHQgImFueSBzaWduYWxpbmcgdGhhdCBpbmRp Y2F0ZXMgc3VjaCBhbm9ueW1pdHkgc2hvdWxkIGJlIGlnbm9yZWQiIGl0DQo+IHdvdWxkIGJlIHVz ZWZ1bCB0byBwcm92aWRlIGFuIGV4YW1wbGUgb2Ygc3VjaCBzaWduYWxpbmcuDQoNCmdvb2QgcG9p bnQsIEkgbW9kaWZpZWQgdGhlIGRlc2NyaXB0aW9uIGFzIGZvbGxvd3M6DQoNCi4uLmFuZCBhbnkg c2lnbmFsaW5nIChpLmUuLCBIT1NUX0lEIHBhcmFtZXRlciBjb250YWluZWQgd2l0aCBhbiANCkVO Q1JZUFRFRCBwYXJhbWV0ZXIpIHRoYXQuLi4NCg0KPiAvbWF5IGNhcnJ5IGRhdGEgcGF5bG9hZC9t YXkgY2FycnkgYSBkYXRhIHBheWxvYWQvDQoNCmZpeGVkDQoNCj4gVGhlIHBhY2tldHMgYXJlIHJl ZmVycmVkIHRvIGFzIDFzdCwgMm5kLCAzcmQsIGFuZCA0dGggaGVyZSwgYW5kIGFzIEkxLCBSMSwg STIsDQo+IGFuZCBSMiBpbiBzZWN0aW9uIDQuIENvbnNpZGVyIHVzZSBhIGNvbnNpc3RlbnQgbmFt aW5nIGFwcHJvYWNoIHRocm91Z2hvdXQgdGhpcw0KPiBkb2N1bWVudCB0byBpbXByb3ZlIGNsYXJp dHkuDQoNCkFncmVlZCwgZml4ZWQuDQoNCj4gU2VjdGlvbiAxLjI6DQo+IA0KPiBTZWN0aW9uIDgg aXMgbm90IGluY2x1ZGVkIGluIHRoaXMgc3VtbWFyeS4gU3VnZ2VzdCBhZGRpbmcgYSBzZW50ZW5j ZSBhYm91dCBpdC4NCj4NCj4gKG5pdCkgU2VjdGlvbiAxMCBpcyBub3QgbGlua2VkIGFzIHdlbGwu DQoNCnRoYW5rcywgZml4ZWQuDQoNCj4gU2VjdGlvbiAyOg0KPiANCj4gL1Rlcm1zIGFuZCBEZWZp bml0aW9ucy9UZXJtcywgTm90YXRpb24sIGFuZCBEZWZpbml0aW9ucy8NCg0KZml4ZWQNCg0KPiBT ZWN0aW9uIDM6DQo+IA0KPiAib3RoZXIgbWV0aG9kcyBhcmUgdXNlZCB0byBtYXAgdGhlIGRhdGEg cGFja2V0cyB0byB0aGUgY29ycmVzcG9uZGluZyBISXMiIFdoYXQNCj4gYXJlIHRoZXNlIG90aGVy IG1ldGhvZHM/IFdoYXQgaWYgRVNQIGlzIG5vdCB1c2VkIGFuZCB0aGUgU1BJIGlzIG5vdCBhbiBv cHRpb24/DQoNCkkgYWRkZWQgdG8gdGhlIGVuZCBvZiB0aGlzIHBhcmFncmFwaDoNCg0KV2hlbiBv dGhlciB1c2VyIGRhdGEgcGFja2V0IGZvcm1hdHMgYXJlIHVzZWQsIHRoZQ0KY29ycmVzcG9uZGlu ZyBleHRlbnNpb25zIG5lZWQgdG8gZGVmaW5lIGEgcmVwbGFjZW1lbnQgZm9yIHRoZQ0KRVNQX1RS QU5TRk9STSBbUkZDNzQwMl0gcGFyYW1ldGVyIGFsb25nIHdpdGggYXNzb2NpYXRlZCBzZW1hbnRp Y3MsDQpidXQgdGhpcyBwcm9jZWR1cmUgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1 bWVudC4NCg0KPiBTZWN0aW9uIDQuMS4yLjM6DQo+IA0KPiBJbiB0aGUgZGlhZ3JhbSwgSSB0aGlu ayB0aGVyZSBpcyBhIG1pc3NpbmcgYXJyb3cgYmV0d2VlbiBJMi1TRU5UIGFuZCBSMi1TRU5ULg0K PiBQbGVhc2UgZG91YmxlIGNoZWNrLiBBbHNvLCB0aGlzIGRpYWdyYW0gaXMgZmFyIGZyb20gc2lt cGxlLiBNYXliZSBuYW1lIHRoaXMNCj4gc2VjdGlvbiAiSElQIFN0YXRlIERpYWdyYW0iPw0KDQpU aGVyZSBpcyBhbiBhcnJvdyBmcm9tIEkyLVNFTlQgdG8gUjItU0VOVCBhbmQgdGhlIHN0YXRlIGRp YWdyYW0gaXMgDQppZGVudGljYWwgdG8gUkZDNzQwMS4gSSB3b3VsZCBwcmVmZXIgdG8ga2VlcCB0 aGUgdGl0bGUgdGhlIHNhbWUgYXMgaW4gDQpSRkM3NDAxLCAiU2ltcGxpZmllZCBTdGF0ZSBEaWFn cmFtIiwgYWx0aG91Z2ggSSBhZ3JlZSBpdCBpcyBub3Qgc28gc2ltcGxlIDopDQoNCj4gU2VjdGlv biA0LjEuMy4yOg0KPiANCj4gIkV2ZW4gdGhvdWdoIHRoaXMgaW5wdXQiIFBsZWFzZSBjbGFyaWZ5 IHRoZSAidGhpcyIgaW5kZWZpbml0ZSBhcnRpY2xlLg0KDQpmaXhlZCAoLi4udGhlIGNvbmNhdGVu YXRlZCBpbnB1dC4uLikNCg0KPiBTZWN0aW9uIDQuMS40Og0KPiANCj4gL1RoaXMgd2lsbCBsaW1p dCBzdGF0ZS9Vc2luZyBub24tdm9sYXRpbGUgc3RvcmFnZSB3aWxsIGxpbWl0IHN0YXRlLw0KPiAN Cj4gVGhpcyBzZWN0aW9uIHNob3VsZCByZWZlcmVuY2Ugc2VjdGlvbiA2LjExLCBzaW5jZSBzb21l IG9mIHRoZSBjb250ZW50IGlzDQo+IGR1cGxpY2F0ZWQgdGhlcmUuDQoNCnRoYW5rcywgZml4ZWQg YXMgc3VnZ2VzdGVkDQoNCj4gU2VjdGlvbiA1LjIuMzoNCj4gDQo+IC9JdCBpcyBkZWZpbmVkIGlu L1RoZSBIT1NUX0lEIHBhcmFtZXRlciBpcyBkZWZpbmVkIGluLw0KDQp0aGFua3MsIGZpeGVkDQoN Cj4gU2VjdGlvbiA1LjIuNToNCj4gDQo+IC9hdCBsZWFzdCA2NCBiaXQvYXQgbGVhc3QgNjQgYml0 cy8NCj4gDQo+IFVwZGF0ZSB0aGUgcmVmZXJlbmNlICIjSSBhbmQgdGhlIHB1enpsZSBzb2x1dGlv biAjSiAoc2VlIFtSRkM3NDAxXSkiIHRvIHBvaW50DQo+IHRvIHNlY3Rpb24gNC4xLjIgaW4gUkZD NzQwMS4NCg0KZG9uZQ0KDQo+IFNlY3Rpb24gNS4zLjI6DQo+IA0KPiBUaGUgZGlzY3Vzc2lvbiBv ZiBkaWZmaWN1bHR5IEsgdG91Y2hlcyBvbiBhIGxvY2FsIHBvbGljeSBpc3N1ZSB0aGF0IGlzDQo+ IGRpc2N1c3NlZCBpbiBzZWN0aW9uIDcuIEl0IGNvdWxkIGJlIHVzZWZ1bCB0byByZWZlcmVuY2Ug c2VjdGlvbiA3IGZyb20gaGVyZS4NCj4gDQo+IFVwZGF0ZSAiKHNlZSBbUkZDNzQwMV0pIiB0byBw b2ludCB0byBzZWN0aW9uIDQuMS4yIGluIFJGQzc0MDEuDQo+IA0KPiAvYmFzZWQgb24gd2hpY2gg aXQgY2hvc2UgdGhlIEVDREgvYmFzZWQgb24gd2hpY2ggdGhlIFJlc3BvbmRlciBjaG9zZSB0aGUg RUNESC8NCg0KZml4ZWQgYm90aCBvZiB0aGVzZS4NCg0KVGhhbmtzIGZvciBpbnNpZ2h0ZnVsIGFu ZCB2ZXJ5IHRlY2huaWNhbGx5IGRldGFpbGVkIGNvbW1lbnRzISBQbGVhc2UgbGV0IA0KbWUga25v dyBpZiB0aGlzIGRpc2N1c3Npb24gcmVzb2x2ZXMgeW91ciBjb25jZXJucy4NCg== From nobody Wed Mar 6 06:19:34 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 AFF06127982; Wed, 6 Mar 2019 05:34:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1551879283; bh=AOVmIR0Rx1mjq3l94YWNthBaBEJ4vFfTizg1YbCb2kg=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=fyQssv2MeEvVPVSF7gQUSsYJ9eveFax+wC7z5FZpN8uBU4Gje460rwyFjh2GdBQ1B RrycpSXh7h3BSiF8DxP2GamhrC/py/77PHLfw0L6Y7Frn8+Y2ibAq5N2FcDykA6FCO 2cyrx7BJ4qvUvWec3xAPgOGX1LiNTWzC/AX53asc= X-Mailbox-Line: From new-work-bounces@ietf.org Wed Mar 6 05:34:39 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6746E12865E; Wed, 6 Mar 2019 05:34:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1551879269; bh=AOVmIR0Rx1mjq3l94YWNthBaBEJ4vFfTizg1YbCb2kg=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=OzJpWBYRcGu6M6TExXs8cNRrdpCXrWK5z37Tg9HbU6ycTx3ZQC6lc172fswI84WUJ L4Y8GeSVWKdqeUU8/irXghAeskEoPr0Ar/YDMJfmAl0tRKWVvQYFaoSiycMZr5z4In U+i9H8JInFIp+TK6nlF5QA8+nqnQnAhwx62Q+4x8= 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 0FA4E1278CF for ; Wed, 6 Mar 2019 05:34:23 -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, HK_RANDOM_ENVFROM=0.001, 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 ss55ThwaZAnY for ; Wed, 6 Mar 2019 05:34:20 -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 48F981277E6 for ; Wed, 6 Mar 2019 05:34:20 -0800 (PST) Received: from [42.100.6.160] (helo=[192.168.1.3]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1h1Wgc-0007P9-6X for new-work@ietf.org; Wed, 06 Mar 2019 13:34:18 +0000 To: new-work@ietf.org From: xueyuan Message-ID: <280880fb-6d73-beab-a258-3158bf5058d0@w3.org> Date: Wed, 6 Mar 2019 21:34:14 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.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: Wed, 06 Mar 2019 06:19:33 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Patents and Standards Interest Group (PSIG) (until 2019-04-03) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 13:34:49 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgUGF0ZW50 cyBhbmQgU3RhbmRhcmRzIEludGVyZXN0IEdyb3VwIAooUFNJRyk6CiDCoCBodHRwczovL3czYy5n aXRodWIuaW8vY2hhcnRlci1kcmFmdHMvcHNpZy1jaGFydGVyLmh0bWwKCkFzIHBhcnQgb2YgZW5z dXJpbmcgdGhhdCB0aGUgY29tbXVuaXR5IGlzIGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsKYXQgVzND LCB0aGlzIGRyYWZ0IGNoYXJ0ZXIgaXMgcHVibGljIGR1cmluZyB0aGUgQWR2aXNvcnkKQ29tbWl0 dGVlIHJldmlldyBwZXJpb2QuCgpXM0MgaW52aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAy MDE5LTA0LTAzIG9uIHRoZQpwcm9wb3NlZCBjaGFydGVyLiBQbGVhc2Ugc2VuZCBjb21tZW50cyB0 bwpwdWJsaWMtbmV3LXdvcmtAdzMub3JnLCB3aGljaCBoYXMgYSBwdWJsaWMgYXJjaGl2ZToKIMKg IGh0dHA6Ly9saXN0cy53My5vcmcvQXJjaGl2ZXMvUHVibGljL3B1YmxpYy1uZXctd29yay8KCk90 aGVyIHRoYW4gY29tbWVudHMgc2VudCBpbiBmb3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZpc29y eQpDb21taXR0ZWUgUmVwcmVzZW50YXRpdmVzLCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJlc3Bv bnNlIHRvCmNvbW1lbnRzLiBJZiB5b3Ugd29yayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNl IGNvb3JkaW5hdGUKeW91ciBjb21tZW50cyB3aXRoIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJl cHJlc2VudGF0aXZlLiBGb3IKZXhhbXBsZSwgeW91IG1heSB3aXNoIHRvIG1ha2UgcHVibGljIGNv bW1lbnRzIHZpYSB0aGlzIGxpc3QgYW5kCmhhdmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVw cmVzZW50YXRpdmUgcmVmZXIgdG8gaXQgZnJvbSBoaXMKb3IgaGVyIGZvcm1hbCByZXZpZXcgY29t bWVudHMuCgpJZiB5b3Ugc2hvdWxkIGhhdmUgYW55IHF1ZXN0aW9ucyBvciBuZWVkIGZ1cnRoZXIg aW5mb3JtYXRpb24sIHBsZWFzZQpjb250YWN0IFdlbmR5IFNlbHR6ZXIgPHdzZWx0emVyQHczLm9y Zz4gb3IgUmlnbyBXZW5uaW5nIDxyaWdvQHczLm9yZz4sClBTSUcgU3RhZmYgQ29udGFjdHPCoCAu CgpUaGFuayB5b3UsClh1ZXl1YW4gSmlhLCBXM0MgTWFya2V0aW5nICYgQ29tbXVuaWNhdGlvbnMK ClsxXSBodHRwOi8vd3d3LnczLm9yZy9Db25zb3J0aXVtL01lbWJlci9MaXN0CgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXctd29yayBtYWlsaW5nIGxp c3QKbmV3LXdvcmtAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXctd29yawo= From nobody Wed Mar 6 15:04:09 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 0B7E7130DC4; Wed, 6 Mar 2019 15:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 N_NZXbMH9P0U; Wed, 6 Mar 2019 15:04:00 -0800 (PST) Received: from mail-yw1-xc32.google.com (mail-yw1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (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 CD78B124B0C; Wed, 6 Mar 2019 15:04:00 -0800 (PST) Received: by mail-yw1-xc32.google.com with SMTP id r188so11652422ywb.12; Wed, 06 Mar 2019 15:04:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2o8ZDDhhjWCM9hveehfUm4sVX9c2xNenVhDL3/RUAQU=; b=t2Cqn/ZM081EGzAWhTkzaYf43ejkRj/0C4adqZChFD0P8NkBEdPCHbsO0rNjiXY4m8 yzseWxlCXDN0tX6BckGYuO4LoB2x6kMqFr2Vf7LFaIvoAwxfzqGtYPseA2S2acU0xIl6 K4GQN5qgo0S+2YPywLwgqSGhw9Hk9WbwUb4hkpNu0wv2tM2+Hjfd8oSil34KVZxhYRJV MJEO0qwcbillyU4J3LewN/ganWPbA2+SpNeDOW35ZsUVaDAYapIyfKtGDUuWUHDUEK2S 2g8BA7b9AwiYfHZiM8VGwVAcJ1L4M1nvarIF0UC6FO3sra4OEABBvh8wLBR9Ta0+DW26 ERig== 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:content-transfer-encoding; bh=2o8ZDDhhjWCM9hveehfUm4sVX9c2xNenVhDL3/RUAQU=; b=crM54Rw818fKkUkN8/+f8UDweyOvzS9Olv97cLbF7bVhukVOYfrneiRt4sOWWf08Z+ Gvm7+Pr+45yJcD5KdbPQpPI+PM3hiyJKu/eRyLsbHQOx++XYzmIzBS0eYOaFfB1MROh+ LodFbvAb3y1Jnlzu7v0UXhnoSEEDZQdjhDC9dBdV5mozXZk85JHzfrVyw5Ig9zQmjeqy /YsKoRdL/BH9URkbaUCLF9OAxHqcHqKyAoZi5uzf91lNUy7I9dTBTH7CGzpmvRBK97dR PwLR74+eZthTuPXb5c3skW2D0KElHAzND5C0k8QTnUOAMthtxUn/Hiu8yOFls3FT2xLg Gbig== X-Gm-Message-State: APjAAAWnUq0lxSBBTOANlqVumt//VoSwQ5nbAfPsAVeDyW8vBjfL9EF0 qxohjU/VJV08OB7vbyrfMRwExJMAxlM4y6/ZCdKMo/zr X-Google-Smtp-Source: APXvYqweQRhmr3So+YJ/WI7Zunhrw1XZBgM1c9LdAseAQipkYnTMm7pVyoFxr8IFtmgNTClNkkoZzMWUorBG/G+/Ijo= X-Received: by 2002:a0d:edc3:: with SMTP id w186mr7665413ywe.301.1551913439808; Wed, 06 Mar 2019 15:03:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Wood Date: Wed, 6 Mar 2019 15:03:49 -0800 Message-ID: To: William Denniss Cc: The IESG , draft-ietf-oauth-device-flow.all@ietf.org, secdir Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-oauth-device-flow 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, 06 Mar 2019 23:04:02 -0000 On Tue, Jan 15, 2019 at 1:43 PM William Denniss wrote= : > > > > On Sun, Aug 26, 2018 at 7:30 PM Christopher Wood wrote: >> >> Hi William, >> >> Please see inline below. >> >> On Wed, Aug 1, 2018 at 5:03 PM William Denniss wro= te: >>> >>> >>> On Tue, Jun 12, 2018 at 5:55 PM, Christopher Wood wrote: >>>> >>>> Hello, >>>> >>>> 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 my review is: Ready with nits. >>>> >>>> Overall, the document is in fine shape. I have a few general comments = (not quite nits, >>>> though not quite issues either), listed below: >>>> >>>> - Section 3.5, fifth paragraph: Requiring clients to poll at a =E2=80= =9Creasonable=E2=80=9D polling interval >>>> without a suggestion of what is reasonable seems strange. Could you su= ggest a value that=E2=80=99s >>>> within reason, e.g., every second? >>> >>> >>> We documented a default of 5s in version 12. >>> >>>> >>>> - Section 5.1, first paragraph: It might be useful to point to Section= 6.1 wherein User Code >>>> generation is discussed. Right now minimum entropy =E2=80=9Crequiremen= ts=E2=80=9D are listed without further >>>> details regarding viable mechanisms. >>> >>> >>> The authors are still considering this feedback, along with Benjamin Ka= duk's DISCUSS. >>> >>>> >>>> - Section 5.2, second paragraph: The text claims that an end user woul= d end up =E2=80=9Con the >>>> authorization page of the wrong service.=E2=80=9D Can you provide more= details here? What stops >>>> the malicious MITM from serving an authorization page that=E2=80=99s i= ndistinguishable from the >>>> legitimate service page? >>> >>> >>>> >>>> - Section 5.3, first paragraph: How specifically does the authorizatio= n service prevent >>>> devices from lying when providing =E2=80=9Cinformation about the devic= e=E2=80=9D? Or, alternatively, how >>>> does the authorization service learn this information? >>> >>> >>> These 2 also pending. >>> >>>> >>>> - Section 5.4: Would it be useful to suggest that clients SHOULD use a= secure (encrypted >>>> and authenticated) channel when communicating to the user device? >>> >>> >>> This section is actually referring to real-world spying, i.e. someone i= n the same room as you who can see the TV. Perhaps we need to make that mor= e clear? >> >> >> That might help. It seems to be only a matter of clarity, not correctnes= s. > > > Thank you for the suggestion, a clarification has been added and will be = published in -14. > > As currently drafted it now reads: > > While the device is pending authorization, it may be possible= for a > malicious user to physically spy on the device user interface > (by viewing the screen on which it's displayed, for example) = and hijack the > session by completing the authorization faster than the user = that > initiated it. > >>> >>> >>>> >>>> >>>> The remainder of my comments, listed below, are editorial in nature, a= imed towards improving >>>> readability of the document. >>>> >>>> - Section 1, step (E): This is the first time client polling is mentio= ned without >>>> discussion of timeouts or server-generated errors. The draft provides = such details later >>>> on, so it would be helpful to allude or point to them here. >>> >>> >>> I believe this is covered in detail in the document, this section is in= tending to just be a high-level overview. >>> >>>> >>>> - Section 3.3, second paragraph: Please cite TLS upon use (=E2=80=9C= =E2=80=A6 in a secure TLS-protected >>>> session.=E2=80=9D). >>> >>> >>> Done, thanks! >>> >>>> >>>> - Section 3.3, second paragraph: The text suggests that the server inf= orms the user to >>>> =E2=80=9Creturn to their device.=E2=80=9D Perhaps this should be prefa= ced with a MAY, as the client will >>>> eventually learn that authorization is complete upon polling. >>> >>> >>> MAY was added, thanks! >>> >>>> >>>> - Section 3.3.1, first paragraph: Should it be required that =E2=80=9C= verification_uri_complete=E2=80=9D >>>> is constructed in part from the =E2=80=9Cverification_uri=E2=80=9D and= =E2=80=9Cuser_code=E2=80=9D? I=E2=80=99m not sure this is >>>> necessary, though the example given is constructed this way. If not re= quired, this might be >>>> worth noting. >>> >>> >>> The working group considered this, in fact originally we were not going= to have verification_uri_complete and it would just be defined as a compos= ition of those two values. In the end, the work group decided to make it se= parate. The authorization server can combine them to create the complete ve= rification URI, or may use something else. >>> >>> The text currently states the following which I believe covers this: >>> >>> "A verification URI that includes the "user_code" (or >>> other information with the same function as the "user_code"), >>> designed for non-textual transmission." >>> >>>> - Section 3.5, first paragraph: s/token endpoint/authentication server= ? >>> >>> >>> This section does actually relate to the token endpoint. >> >> >> Ah, okay. I misunderstood. Thanks! >> >>> >>>> >>>> - Section 5.1, third paragraph: This text is mostly redundant with the= preceding paragraphs. >>>> I would remove or merge it with the paragraphs above. >>> >>> >>> I don't agree that it's redundant. Willing to review text if you have a= concrete proposal. >> >> >> My only recommendation is to remove the paragraph. I think it=E2=80=99s = already covered by the preceding paragraphs. That said, I don=E2=80=99t thi= nk this is necessary. It=E2=80=99s merely a suggestion. >> > > Note that this paragraph was significantly reworked in -13 and has a long= er discussion on entropy now. > >>> >>> >>> >>>> Please let me know if you=E2=80=99ve further questions, comments, or c= oncerns. I hope this helps. >> >> >> It does indeed. Thanks for your changes! >> >> Best, >> Chris > > > Thanks again for your review! My pleasure, William! Best, Chris From nobody Thu Mar 7 05:36:16 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 85902127917 for ; Thu, 7 Mar 2019 05:36:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Datatracker on behalf of Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <155196577454.15959.6191926239612173823.idtracker@ietfa.amsl.com> Date: Thu, 07 Mar 2019 05:36:14 -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, 07 Mar 2019 13:36:15 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-03-07 Reviewer LC end Draft Nancy Cam-Winget 2019-02-15 draft-ietf-rtcweb-security-11 Tim Polk 2019-02-13 draft-ietf-sipcore-reason-q850-loc-06 David Waltermire 2019-02-15 draft-ietf-rtcweb-ip-handling-11 Taylor Yu 2019-02-15 draft-ietf-rtcweb-security-arch-18 For telechat 2019-03-14 Reviewer LC end Draft Linda Dunbar R2018-12-11 draft-ietf-mpls-lsp-ping-lag-multipath-06 Leif Johansson 2018-12-24 draft-ietf-6lo-nfc-13 Charlie Kaufman 2019-03-14 draft-ietf-trans-rfc6962-bis-31 Samuel Weiler 2019-03-05 draft-faltstrom-unicode11-07 Klaas Wierenga 2019-02-26 draft-ietf-mpls-sr-over-ip-03 For telechat 2019-04-11 Reviewer LC end Draft Stefan Santesson 2019-02-11 draft-ietf-extra-imap-fetch-preview-03 Last calls: Reviewer LC end Draft Derek Atkins 2019-03-03 draft-ietf-netmod-module-tags-06 Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-27 Donald Eastlake 2019-03-20 draft-ietf-pce-stateful-pce-p2mp-12 Shawn Emery 2019-03-20 draft-ietf-ccamp-alarm-module-07 Stephen Farrell 2019-03-19 draft-ietf-dots-signal-channel-30 Daniel Franke 2019-03-18 draft-ietf-sidrops-https-tal-07 Daniel Gillmor 2018-03-19 draft-gutmann-scep-13 Phillip Hallam-Baker 2019-03-18 draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04 Dan Harkins 2019-03-18 draft-ietf-mmusic-data-channel-sdpneg-24 Russ Housley 2019-03-15 draft-ietf-regext-bundling-registration-09 Christian Huitema 2019-03-18 draft-ietf-iasa2-rfc4071bis-08 Leif Johansson 2019-03-14 draft-ietf-dmarc-eaiauth-03 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Vincent Roca R2019-02-13 draft-ietf-perc-private-media-framework-09 Stefan Santesson R2018-11-20 draft-wilde-service-link-rel-10 Takeshi Takahashi R2018-08-31 draft-ietf-lisp-rfc6833bis-24 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-11 Early review requests: Reviewer Due Draft Alan DeKok 2019-03-18 draft-cel-nfsv4-rpc-tls-02 Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Scott Kelly 2019-03-22 draft-ietf-rift-rift-04 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 Thu Mar 7 08:34:51 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 8F475131475; Thu, 7 Mar 2019 08:34:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Leif Johansson via Datatracker To: Cc: draft-ietf-6lo-nfc.all@ietf.org, ietf@ietf.org, 6lo@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155197648051.24840.16459568633516212522@ietfa.amsl.com> Date: Thu, 07 Mar 2019 08:34:40 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-6lo-nfc-13 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 Mar 2019 16:34:50 -0000 Reviewer: Leif Johansson 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. I am not a subject matter expert but overall I find the document well written and readable. The issue I have is in the security considerations section where I really think there should be normative language around the use of permanent identifiers. In particular: "Thus, every single touch connection can use a different short address of NFC link with an extremely short-lived link. This can mitigate address scanning as well as location tracking and device-specific vulnerability exploitation." This is imo too weak. I suggest reformulating this and related text to normative language. Given the possible consequences of NFC correlation attacks I would have thought that a mandatory requirement on generating different short addresses for every link would be a good idea. From nobody Thu Mar 7 17:29: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 8AC04131162 for ; Thu, 7 Mar 2019 17:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, 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 nbotRgvM4e1H for ; Thu, 7 Mar 2019 17:29:38 -0800 (PST) Received: from mscreen.etri.re.kr (mscreen.etri.re.kr [129.254.9.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5851D131131 for ; Thu, 7 Mar 2019 17:29:34 -0800 (PST) Received: from unknown (HELO smtpeg.etri.re.kr) (129.254.27.141) by 129.254.9.16 with ESMTP; 8 Mar 2019 10:02:47 +0900 X-Original-SENDERIP: 129.254.27.141 X-Original-MAILFROM: yhc@etri.re.kr X-Original-RCPTTO: ietf@ietf.org, 6lo@ietf.org, draft-ietf-6lo-nfc.all@ietf.org, noreply@ietf.org, secdir@ietf.org Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 8 Mar 2019 10:02:51 +0900 Received: from SMTP2.etri.info ([169.254.2.66]) by SMTP4.etri.info ([10.2.6.33]) with mapi id 14.03.0319.002; Fri, 8 Mar 2019 10:02:49 +0900 From: =?utf-8?B?7LWc7JiB7ZmY?= To: Leif Johansson via Datatracker , "secdir@ietf.org" CC: "draft-ietf-6lo-nfc.all@ietf.org" , "ietf@ietf.org" , "6lo@ietf.org" <6lo@ietf.org>, =?utf-8?B?6rmA7ZiV7KSA?= , =?utf-8?B?7J206rCV7LCs?= Thread-Topic: Secdir last call review of draft-ietf-6lo-nfc-13 Thread-Index: AQHU1QO0oFBvvJOIJUa2ksNtJ2E2Z6YA58CA Date: Fri, 8 Mar 2019 01:02:48 +0000 Message-ID: References: <155197648051.24840.16459568633516212522@ietfa.amsl.com> In-Reply-To: <155197648051.24840.16459568633516212522@ietfa.amsl.com> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.170.124] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-6lo-nfc-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, 08 Mar 2019 01:29:40 -0000 RGVhciBMZWlmIEpvaGFuc3Nvbi4NCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLg0KUGxlYXNl IGZpbmQgdGhlIGFuc3dlciBpbmxpbmUgYmVsbG93czoNCg0KQlJzLA0KWW91bmdod2FuIENob2kN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExlaWYgSm9oYW5zc29uIHZpYSBE YXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz4gDQpTZW50OiBGcmlkYXksIE1hcmNoIDgsIDIw MTkgMTozNSBBTQ0KVG86IHNlY2RpckBpZXRmLm9yZw0KQ2M6IGRyYWZ0LWlldGYtNmxvLW5mYy5h bGxAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IDZsb0BpZXRmLm9yZw0KU3ViamVjdDogU2VjZGly IGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi02bG8tbmZjLTEzDQoNClJldmlld2VyOiBM ZWlmIEpvaGFuc3Nvbg0KUmV2aWV3IHJlc3VsdDogSGFzIElzc3Vlcw0KDQogSSBoYXZlIHJldmll d2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBv bmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3Nl ZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9y IHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVk aXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtl IGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNCkkgYW0gbm90IGEgc3ViamVjdCBtYXR0 ZXIgZXhwZXJ0IGJ1dCBvdmVyYWxsIEkgZmluZCB0aGUgZG9jdW1lbnQgd2VsbCB3cml0dGVuIGFu ZCByZWFkYWJsZS4gDQoNCllIPj4gVGhhbmtzIGEgbG90Lg0KDQpUaGUgaXNzdWUgSSBoYXZlIGlz IGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHdoZXJlIEkgcmVhbGx5IHRo aW5rIHRoZXJlIHNob3VsZCBiZSBub3JtYXRpdmUgbGFuZ3VhZ2UgYXJvdW5kIHRoZSB1c2Ugb2Yg cGVybWFuZW50IGlkZW50aWZpZXJzLiBJbiBwYXJ0aWN1bGFyOg0KDQoiVGh1cywgZXZlcnkgc2lu Z2xlIHRvdWNoIGNvbm5lY3Rpb24gY2FuIHVzZSBhIGRpZmZlcmVudCBzaG9ydCBhZGRyZXNzIG9m IE5GQyBsaW5rIHdpdGggYW4gZXh0cmVtZWx5IHNob3J0LWxpdmVkIGxpbmsuICBUaGlzIGNhbiBt aXRpZ2F0ZSBhZGRyZXNzIHNjYW5uaW5nIGFzIHdlbGwgYXMgbG9jYXRpb24gdHJhY2tpbmcgYW5k IGRldmljZS1zcGVjaWZpYyB2dWxuZXJhYmlsaXR5IGV4cGxvaXRhdGlvbi4iDQoNClRoaXMgaXMg aW1vIHRvbyB3ZWFrLiBJIHN1Z2dlc3QgcmVmb3JtdWxhdGluZyB0aGlzIGFuZCByZWxhdGVkIHRl eHQgdG8gbm9ybWF0aXZlIGxhbmd1YWdlLiBHaXZlbiB0aGUgcG9zc2libGUgY29uc2VxdWVuY2Vz IG9mIE5GQyBjb3JyZWxhdGlvbiBhdHRhY2tzIEkgd291bGQgaGF2ZSB0aG91Z2h0IHRoYXQgYSBt YW5kYXRvcnkgcmVxdWlyZW1lbnQgb24gZ2VuZXJhdGluZyBkaWZmZXJlbnQgc2hvcnQgYWRkcmVz c2VzIGZvciBldmVyeSBsaW5rIHdvdWxkIGJlIGEgZ29vZCBpZGVhLg0KDQpZSD4+IEkgYWdyZWUg d2l0aCB5b3VyIGNvbW1lbnQsIHNvIEkgd291bGQgbGlrZSB0byByZWZvcm11bGF0ZSB0aGUgc2Vu dGVuY2VzIGxpa2UgZm9sbG93aW5nczoNCg0KWUg+PiAiVGh1cywgY29ubmVjdGlvbnMgd2l0aCBl dmVyeSBzaW5nbGUgdG91Y2ggYmV0d2VlbiBORkMtZW5hYmxlZCBkZXZpY2VzIE1VU1QgdXNlIGRp ZmZlcmVudCBzaG9ydCBhZGRyZXNzZXMgd2l0aCBleHRyZW1lbHkgc2hvcnQtbGl2ZWQgbGlua3Mu IFRoaXMgYWxzbyBTSE9VTEQgbWl0aWdhdGUgdGhlIE5GQyBjb3JyZWxhdGlvbiBhdHRhY2tzLCBz dWNoIGFzIGFkZHJlc3Mgc2Nhbm5pbmcsIGxvY2F0aW9uIHRyYWNraW5nLCBhbmQgZGV2aWNlLXNw ZWNpZmljIHZ1bG5lcmFiaWxpdHkgZXhwbG9pdGF0aW9uLiINCg0KWUg+PiBJIHdpbGwgdXBkYXRl IHRoZSBkcmFmdCAoLTEzKSB3aXRoIHRoZSBuZXcgc2VudGVuY2VzIGlmIGl0J3Mgb2suDQpZSD4+ IFRoYW5rcyBhZ2Fpbi4NCg== From nobody Fri Mar 8 09:20:29 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 408F5130F01; Fri, 8 Mar 2019 09:20:21 -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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 DDyfy_LtbyP1; Fri, 8 Mar 2019 09:20:20 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B9E71312AF; Fri, 8 Mar 2019 09:20:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id B6B1F1C3F65; Fri, 8 Mar 2019 09:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJdK9FEosOFS; Fri, 8 Mar 2019 09:20:16 -0800 (PST) Received: from www.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 8F69B1C3F62; Fri, 8 Mar 2019 09:20:16 -0800 (PST) Received: from 87.112.237.8 (SquirrelMail authenticated user rfcpise) by www.amsl.com with HTTP; Fri, 8 Mar 2019 09:20:16 -0800 Message-ID: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> Date: Fri, 8 Mar 2019 09:20:16 -0800 From: "RFC ISE (Adrian Farrel)" To: cfrg@irtf.org, secdir@ietf.org Cc: "Adrian Farrel" , sec-ads@ietf.org Reply-To: rfc-ise@rfc-editor.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: [secdir] ISE seeks help with some crypto drafts 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, 08 Mar 2019 17:20:21 -0000 Hi CFRG and SecDir, Ted Krovetz has asked for publication of ... https://datatracker.ietf.org/doc/draft-krovetz-ocb-wideblock/ ...and... https://datatracker.ietf.org/doc/draft-krovetz-rc6-rc5-vectors/ ...in the Independent Stream. These are both currently in expired state, but available in the archive. At this stage I am looking to know whether anyone feels that publication would be a bad thing: - at this stage - ever Please send me your opinions direct (I am not subscribed to this list, but will check the archives). Please also let me know if you would be willing to be a detailed reviewer of this work. Thanks, Adrian -- Adrian Farrel (ISE), rfc-ise@rfc-editor.org From nobody Fri Mar 8 09:21: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 D7B23131375; Fri, 8 Mar 2019 09:21:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar via Datatracker To: Cc: mpls@ietf.org, draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155206570582.3202.12517909943780959477@ietfa.amsl.com> Date: Fri, 08 Mar 2019 09:21:45 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-mpls-lsp-ping-lag-multipath-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: Fri, 08 Mar 2019 17:21:46 -0000 Reviewer: Linda Dunbar 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. The document provides the detailed explanation of SR-MPLS processing in addition to RFC 8402. Since SR-MPLS are in the trusted domain, it is assumed that there is no malicious attacks to the nodes for the data plane and control plane. RFC8402 already has the good description on the Security Consideration for both SR-MPLS & SRv6. Best Regards, Linda Dunbar From nobody Fri Mar 8 09:52:38 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 ABBD21313FC for ; Fri, 8 Mar 2019 09:52:36 -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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 O3XZp6H6Rv8M for ; Fri, 8 Mar 2019 09:52:34 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 51BB01313FB for ; Fri, 8 Mar 2019 09:52:34 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44GFSv4Tmlz3FX; Fri, 8 Mar 2019 18:52:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1552067551; bh=vkHYbBtHSCZRc+1fHDomfSZ+nogu/C5BTd6Or9UuxCc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=kzTCpDwg6kq+JKG6GS/1ForAzwtiujZpGvj1SOhC+gN0ztu0OlsRaLcKnoeDByfk9 9Fxu9nTvWwtIQuxv3b8dq1PiAnqGggw41AC7zjitZFLAAana4xCKR3gvxh0nxkgnww CLKQSJjNKVXbaThFbnZXDsMjShWhmFpPzXG6P8Ms= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id fGgMdu0jpCce; Fri, 8 Mar 2019 18:52:28 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 8 Mar 2019 18:52:27 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id A18425C856; Fri, 8 Mar 2019 12:52:26 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca A18425C856 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 99A42411602B; Fri, 8 Mar 2019 12:52:26 -0500 (EST) Date: Fri, 8 Mar 2019 12:52:26 -0500 (EST) From: Paul Wouters To: "RFC ISE (Adrian Farrel)" cc: cfrg@irtf.org, secdir In-Reply-To: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> Message-ID: References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [secdir] ISE seeks help with some crypto drafts 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, 08 Mar 2019 17:52:37 -0000 On Fri, 8 Mar 2019, RFC ISE (Adrian Farrel) wrote: > Hi CFRG and SecDir, > > Ted Krovetz has asked for publication of ... > > https://datatracker.ietf.org/doc/draft-krovetz-ocb-wideblock/ > ....and... > https://datatracker.ietf.org/doc/draft-krovetz-rc6-rc5-vectors/ > > ....in the Independent Stream. > > These are both currently in expired state, but available in the archive. > > At this stage I am looking to know whether anyone feels that publication > would be a bad thing: > - at this stage > - ever I have strong reservations about the ocb draft. Rogaway has patents on OCB, and has put constrains on its use and there is no generic IPR statement that the IETF normally likes to see for work published as RFC. Until such a time, I do not think publishing RFC's with OCB is advised. A few years ago I asked the TLS OCB authors about extending their allowed usage to IKE/IPsec and they told me this use was not covered by Rogaway's license to them. While this has since changed a bit, and there is no longer a specific TLS-only license, other constrains are still in place. Specifying OCB documents that cannot be implemented or deployed indiscriminatory is troublesome. Patents: http://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#patent:phil "I license OCB under fair, reasonable, and non-discriminatory terms, with licensees paying a modest one-time fee." "I freely license OCB for most (but not all) settings." And just before that, discriminatory terms are cited for current use: "there is one license grant for open-source software; one for non-military software; and a third done just for OpenSSL." See also http://web.cs.ucdavis.edu/~rogaway/ocb/offer.htm Second, I'm not a cryptographer, but it seems OCB has recently seen some attacks that might impact the security of OCB: Cryptanalysis of OCB2 https://eprint.iacr.org/2018/1040 Breaking the confidentiality of OCB2 https://eprint.iacr.org/2018/1087 Plaintext Recovery Attack of OCB2 https://eprint.iacr.org/2018/1090 Note these publications are newer than the publication date of the draft, so it would be good to discuss this with the draft author or with CFRG to see how applicable these attacks are to the draft document. I have no specific remarks about the rc5-rc6 document. It seems useful to have test vectors, but I am not aware of any IETF protocol using RC5 or RC6, in which case it might not make sense for the IETF to publish these test vectors and another standards body might be more appropriate. Paul From nobody Fri Mar 8 09:56:22 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 7AC0612782C; Fri, 8 Mar 2019 09:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 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, KHOP_DYNAMIC=1.468, RCVD_IN_DNSWL_LOW=-0.7, 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=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 eOB8zPnY1ENy; Fri, 8 Mar 2019 09:56:12 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 F07FF1277CE; Fri, 8 Mar 2019 09:56:11 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x28HqZJY032056; Fri, 8 Mar 2019 17:56:10 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=xuxmLIgintyfufYpgqsItGblKBcGP/0JztDAwDd56S0=; b=XPtuKdA/ndl+ZqiJLTdCYUAltpeOu7CujIEpVljkDiTa1L1irZNMNzOUFdFfUxF5bDyW 18mi+/WPE36x/rWKP23bLLXQL5XK+kbR5RcoeoXkUYLFVqjqqr9SkPBw04t6w8g82Fbf M8PFjw2e2zYsUSo5Qgl7P0zy5mUxNzc4iuLKxhNzP7ItQhtvYL9jpaX4UPg6PZhTR0WV 88bDCzTr+OJ/Ib7YVFGzhYRJX+zsBeifXnqJvEHhGh1Ck6zMw7HNsSevS5r9bDNMMDDA 6n0J2/uW/ELihMSM5BHpM9Vj79D/aVeDc1Xdtq8oWSVtnd3qGV2adow0ShmY4K7fCcPj Eg== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2r3rn7h099-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 08 Mar 2019 17:56:10 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x28Hl6qZ019906; Fri, 8 Mar 2019 12:56:09 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2qyp2376ts-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 08 Mar 2019 12:56:09 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 8 Mar 2019 11:56:08 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1473.003; Fri, 8 Mar 2019 11:56:08 -0600 From: "Salz, Rich" To: "rfc-ise@rfc-editor.org" , "cfrg@irtf.org" , "secdir@ietf.org" CC: "sec-ads@ietf.org" Thread-Topic: [Cfrg] ISE seeks help with some crypto drafts Thread-Index: AQHU1dNDDSpWZUpQzUmtXhFlPEPmqKYCFYcA Date: Fri, 8 Mar 2019 17:56:08 +0000 Message-ID: References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> In-Reply-To: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.0.190303 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.75] Content-Type: text/plain; charset="utf-8" Content-ID: <897D6307C3ECF049BAE1DB90C8CE95EF@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-08_15:, , 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=751 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903080124 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-08_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=765 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903080125 Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 08 Mar 2019 17:56:14 -0000 ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtyb3ZldHotb2NiLXdp ZGVibG9jay8NCg0KSSB3b3VsZCByYXRoZXIgc2VlIHRoaXMgcmV3cml0dGVuIHRvIGNvbXBsZXRl bHkgcmVwbGFjZSA3NTIzIChhbmQgaW5jbHVkZSBpdHMgdGVzdCB2ZWN0b3JzIG9mIGNvdXJzZSkg IFdvdWxkIHJldmlldy4NCg0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWtyb3ZldHotcmM2LXJjNS12ZWN0b3JzLw0KDQpJIGRvbid0IHNlZSBhIGNvbXBlbGxpbmcg bmVlZCBmb3IgdGhpcywgYnV0IEkgYW0gbm90IHN0cm9uZ2x5IG9wcG9zZWQgZWl0aGVyLg0KDQo= From nobody Fri Mar 8 10:11:06 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 1312A1277CE; Fri, 8 Mar 2019 10:10: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 opBTdBul27Z1; Fri, 8 Mar 2019 10:10:56 -0800 (PST) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 C53EE124184; Fri, 8 Mar 2019 10:10:56 -0800 (PST) Received: by mail-pg1-x52c.google.com with SMTP id j3so14731523pgm.11; Fri, 08 Mar 2019 10:10:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cwsPrcFcRPBy+F+Q9AJhNPeTnIk/OvgBB/mEDLh/iz8=; b=naZcl3YqzYbExv40AktTBJW0GFpevJGUO5yJk/aVGILSv8oib3+kGdUFCwSHqb2Tn6 9p3pi4A7LG+T7l9f/p3CZfYcTLy+R+HRC72PIpyyAdqx2ZjAksgAROPGWScy8M1An1Y6 NXb2PimjDsOr+X/PCDsdrtopFbAoXszvRynRcHwi9FzVrHvaLoFQwHc9UnArNzdMFmp7 Br9uL8xjVpQ9vD6rtJJSoBRnaZHFv3ZAdZM1/0WqrspDouhVHl2kPZG6Dd7BgirVD+wf ZOnugYBMbIRg3SuxrntF7Gk4rInxngakvRH8GK1PhOvS5+2vJ1R9u6vQySNcJ4nUgITQ JChg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cwsPrcFcRPBy+F+Q9AJhNPeTnIk/OvgBB/mEDLh/iz8=; b=jN7FyaRiBwQyzNb56SvHvpD4KF49T2VhguugzizcD2oj83H1BJIAo+tfqf3CTqYzU6 q8gbxCf8J6jmbIin5brjPZmVWPd1lsBJ36DKUZx/e5PLZKHYiK6LGY3F/PT2Yntxi3lB YctWv0CxGMONoMV83pSPshtwfCHU0VZ9cuJJADsn4qLWd+H+rsX/UilkHItqJnfn9XyF SBfDGovDuG5nGm2FAyQmE/MaSR+CwVPbTceD4+AnOdDY6bVMowLDvw0J6YPug3I2xPxP 8KLWSZiO+vLKrq+exEP/5teOKWa7dRjC2FzNpgF6QVDf0FzHNyvKP9GgkbRPnHWPNC5z hoqQ== X-Gm-Message-State: APjAAAVlgiIDZC/uIYKF2RwASFTLehRHRQY8iWs4dHV78pRnXiaIOD3I gkPoivbXjGt/eudWpHq4teI= X-Google-Smtp-Source: APXvYqxC7Y+E997lOfsHHsO5l0RMJzox6VCZq2P206ivjJSXPL69xe67pXTjtrupIBeUtMQmGoaWCg== X-Received: by 2002:a62:18d8:: with SMTP id 207mr20012847pfy.57.1552068656222; Fri, 08 Mar 2019 10:10:56 -0800 (PST) Received: from ?IPv6:2601:645:4000:7a8a:7d56:4665:6503:3e1c? ([2601:645:4000:7a8a:7d56:4665:6503:3e1c]) by smtp.gmail.com with ESMTPSA id g80sm14718087pfd.72.2019.03.08.10.10.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Mar 2019 10:10:55 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: David Wong In-Reply-To: Date: Fri, 8 Mar 2019 10:10:54 -0800 Cc: "rfc-ise@rfc-editor.org" , "cfrg@irtf.org" , "secdir@ietf.org" , "sec-ads@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 08 Mar 2019 18:10:59 -0000 Note that OCB was chose as a finalist in the CAESAR competition. Knowing = that, it sounds like a good idea to standardize it. On the other hand, if I understand correctly you need to pay a one-time = fee to use the algorithm in a commercial product? I think that=E2=80=99s = a big no-no considering we want everybody to use good open source = libraries. David > On Mar 8, 2019, at 9:56 AM, Salz, Rich wrote: >=20 > https://datatracker.ietf.org/doc/draft-krovetz-ocb-wideblock/ >=20 > I would rather see this rewritten to completely replace 7523 (and = include its test vectors of course) Would review. >=20 > https://datatracker.ietf.org/doc/draft-krovetz-rc6-rc5-vectors/ >=20 > I don't see a compelling need for this, but I am not strongly opposed = either. >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg From nobody Fri Mar 8 10:46:00 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 8F7431295D8 for ; Fri, 8 Mar 2019 10:45:52 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 JOv07WzY0qNz for ; Fri, 8 Mar 2019 10:45:49 -0800 (PST) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E32412958B for ; Fri, 8 Mar 2019 10:45:48 -0800 (PST) Received: by mail-oi1-x22c.google.com with SMTP id t206so16644266oib.3 for ; Fri, 08 Mar 2019 10:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Cp+dEMQ/IerEvC2cXX+Xzy+lMQEJRxsa79kjOmZxP8M=; b=oJ+vE5R43ajKDY3v+woxeDoirEme/9+1EgZcEY3ZoWBBzB/BdiZBuTGk5kwstojupT HoWJAuXLSCgOQ3lcMVFwJY0eulra8phLqmHIe8v+6OXK55eO4w38Pz4/YGonZTuroPPh Miw9foVMbMmuQ5y190VDuQEJtjTpwYDRlXhWigtHi/n8L/SvjAOZQzsHvtIT1i5BLNOO eQaP5sAObBp7kmGUk2wLNYN2CWrkOfh/k3NB6RIri/Wfy6WX76lmgemo6odQwMqqGotU p5BFonAwq1yWs5lFyGIL+1vRajcbgp0IT0De0kAd4XmDROdP/7knydxhnnk5DptZ1Z/l YObA== 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=Cp+dEMQ/IerEvC2cXX+Xzy+lMQEJRxsa79kjOmZxP8M=; b=gUmBLAt0F/DdnTI73ojKXGPe1df4lxhKdmHd/Gh1THTWIa2gDxxV3Buclwqi4+ODH8 foVBlc+LrDnFKVkbxa4vZC+bkPSZ6qx++ag/GKH5wT/lch2GLBhf+eyMCo5A21dCbbkf RMgmgC8npxpBSzpBxHtAxaV8i66BD4m7+8CiL8ZKugMzUUA6Qwsgc8OVxnv259aKNa3P x9NQ7OauWER8xFsG5EAHe+Ad5yJDfi69M+hx6NgpfMogZvqpJFyVGsNZkQrlD0kAKjN2 aoushUQzY6lqCMZMyntoj/zGYTshDcsK4RKh+BwKyw9UW8OwWj1Vo2FZfxzaGgz4RNFK 8YIw== X-Gm-Message-State: APjAAAWXIwJcXRwE4Mj/YYVwM6v9IvmCup0PrrM4LUKc1AGmECM0mhtQ 40hUFr7c8G2eL+PIRXJ3LpttL6xe5BNLyqyHaqMksQ== X-Google-Smtp-Source: APXvYqyM8N39B/IrWKshBmpzk1lwsa2a1CAhYxlI6LW+jv4fyMMMikZnctgBsaFR9JfA6DCUw82GwkgwF81suYkwOHE= X-Received: by 2002:aca:c745:: with SMTP id x66mr8831365oif.44.1552070747605; Fri, 08 Mar 2019 10:45:47 -0800 (PST) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> In-Reply-To: From: Tony Arcieri Date: Fri, 8 Mar 2019 10:45:36 -0800 Message-ID: To: Paul Wouters Cc: "RFC ISE (Adrian Farrel)" , CFRG , secdir Content-Type: multipart/alternative; boundary="00000000000093d233058399a1dc" Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 08 Mar 2019 18:45:53 -0000 --00000000000093d233058399a1dc Content-Type: text/plain; charset="UTF-8" On Fri, Mar 8, 2019 at 9:53 AM Paul Wouters wrote: > I have strong reservations about the ocb draft. Rogaway has patents > on OCB, and has put constrains on its use and there is no generic IPR > statement that the IETF normally likes to see for work published as > RFC. Until such a time, I do not think publishing RFC's with OCB is > advised. A few years ago I asked the TLS OCB authors about extending > their allowed usage to IKE/IPsec and they told me this use was not > covered by Rogaway's license to them. While this has since changed a bit, > and there is no longer a specific TLS-only license, other constrains are > still in place. Specifying OCB documents that cannot be implemented or > deployed indiscriminatory is troublesome. > I would agree the IPR story for OCB is presently bad. Rogaway had previously voiced interest in completely resolving the patent situation (i.e. disavowing the patents, with an attorney's assistance) however sadly it seems he never completed this work. Perhaps I can attempt to get the ball rolling on that again... Second, I'm not a cryptographer, but it seems OCB has recently seen some > attacks that might impact the security of OCB: > > Cryptanalysis of OCB2 > https://eprint.iacr.org/2018/1040 > > Breaking the confidentiality of OCB2 > https://eprint.iacr.org/2018/1087 > > Plaintext Recovery Attack of OCB2 > https://eprint.iacr.org/2018/1090 There are three variants of OCB: OCB1, OCB2, and OCB3. These attacks apply to OCB2. They do not apply to OCB1 or OCB3. OCB3 is realistically what we should be using provided the IPR story can be cleared up. -- Tony Arcieri --00000000000093d233058399a1dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Mar 8, 2019 at 9:53 AM Paul Woute= rs <paul@nohats.ca> wrote:
<= /div>
I have strong reservations about the ocb draft. Rogaway has patents<= br> on OCB, and has put constrains on its use and there is no generic IPR
statement that the IETF normally likes to see for work published as
RFC. Until such a time, I do not think publishing RFC's with OCB is
advised. A few years ago I asked the TLS OCB authors about extending
their allowed usage to IKE/IPsec and they told me this use was not
covered by Rogaway's license to them. While this has since changed a bi= t,
and there is no longer a specific TLS-only license, other constrains are still in place.=C2=A0 Specifying OCB documents that cannot be implemented o= r
deployed indiscriminatory is troublesome.

I would agree the IPR story for OCB is presently bad.

Rogaway had previously voiced interest in completely resolving the p= atent situation (i.e. disavowing the patents, with an attorney's assist= ance) however sadly it seems he never completed this work. Perhaps I can at= tempt to get the ball rolling on that again...

Second, I'm not a cryptographer, but it seems OCB has recently seen som= e
attacks that might impact the security of OCB:

Cryptanalysis of OCB2
https://eprint.iacr.org/2018/1040

Breaking the confidentiality of OCB2
https://eprint.iacr.org/2018/1087

Plaintext Recovery Attack of OCB2
https://eprint.iacr.org/2018/1090

There are three variants of OCB: OCB1, OCB2, and OCB3.

These attacks apply to OCB2. They do not apply to OCB1 or OCB3.

OCB3 is realistically what we should be using provide= d the IPR story can be cleared up.
=C2=A0
--
Tony Arcieri
--00000000000093d233058399a1dc-- From nobody Fri Mar 8 10:51:25 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 B929C12958B; Fri, 8 Mar 2019 10:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=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 zsyl_MZ4fmG4; Fri, 8 Mar 2019 10:51:12 -0800 (PST) Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) by ietfa.amsl.com (Postfix) with ESMTP id C80A912796D; Fri, 8 Mar 2019 10:51:11 -0800 (PST) Received: from LLE2K16-MBX02.mitll.ad.local (LLE2K16-MBX02.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTP id x28Ip9cT039541; Fri, 8 Mar 2019 13:51:09 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: Tony Arcieri CC: Paul Wouters , CFRG , "RFC ISE (Adrian Farrel)" , secdir Thread-Topic: [Cfrg] [secdir] ISE seeks help with some crypto drafts Thread-Index: AQHU1dfKaGvRJ+lOIkiULgQ1w8/ZA6YCZl4AgAABjAA= Date: Fri, 8 Mar 2019 18:51:08 +0000 Message-ID: References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 Content-Type: multipart/signed; boundary="Apple-Mail-AD8B3CE8-3F23-4841-9436-30710D2C2E48"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-08_16:, , 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903080130 Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 08 Mar 2019 18:51:16 -0000 --Apple-Mail-AD8B3CE8-3F23-4841-9436-30710D2C2E48 Content-Type: multipart/alternative; boundary=Apple-Mail-3C54267F-2BD4-477E-9FC5-D9DC8E91BECC Content-Transfer-Encoding: 7bit --Apple-Mail-3C54267F-2BD4-477E-9FC5-D9DC8E91BECC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable +1 to Tony, and I am for publishing OCB3.=20 Also, I didn't keep track of the OCB IPR, but I think it improved in the las= t few years. Anyway, let's get the ball rolling. Regards, Uri Sent from my iPhone > On Mar 8, 2019, at 13:46, Tony Arcieri wrote: >=20 >> On Fri, Mar 8, 2019 at 9:53 AM Paul Wouters wrote: >=20 >> I have strong reservations about the ocb draft. Rogaway has patents >> on OCB, and has put constrains on its use and there is no generic IPR >> statement that the IETF normally likes to see for work published as >> RFC. Until such a time, I do not think publishing RFC's with OCB is >> advised. A few years ago I asked the TLS OCB authors about extending >> their allowed usage to IKE/IPsec and they told me this use was not >> covered by Rogaway's license to them. While this has since changed a bit,= >> and there is no longer a specific TLS-only license, other constrains are >> still in place. Specifying OCB documents that cannot be implemented or >> deployed indiscriminatory is troublesome. >=20 > I would agree the IPR story for OCB is presently bad. >=20 > Rogaway had previously voiced interest in completely resolving the patent s= ituation (i.e. disavowing the patents, with an attorney's assistance) howeve= r sadly it seems he never completed this work. Perhaps I can attempt to get t= he ball rolling on that again... >=20 >> Second, I'm not a cryptographer, but it seems OCB has recently seen some >> attacks that might impact the security of OCB: >>=20 >> Cryptanalysis of OCB2 >> https://eprint.iacr.org/2018/1040 >>=20 >> Breaking the confidentiality of OCB2 >> https://eprint.iacr.org/2018/1087 >>=20 >> Plaintext Recovery Attack of OCB2 >> https://eprint.iacr.org/2018/1090 >=20 > There are three variants of OCB: OCB1, OCB2, and OCB3. >=20 > These attacks apply to OCB2. They do not apply to OCB1 or OCB3. >=20 > OCB3 is realistically what we should be using provided the IPR story can b= e cleared up. > =20 > --=20 > Tony Arcieri > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail-3C54267F-2BD4-477E-9FC5-D9DC8E91BECC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPisxIHRvIFRvbnks IGFuZCBJIGFtIGZvciBwdWJsaXNoaW5nIE9DQjMuJm5ic3A7PGRpdj48YnI+PC9kaXY+PGRpdj5B bHNvLCBJIGRpZG4ndCBrZWVwIHRyYWNrIG9mIHRoZSBPQ0IgSVBSLCBidXQgSSB0aGluayBpdCBp bXByb3ZlZCBpbiB0aGUgbGFzdCBmZXcgeWVhcnMuIEFueXdheSwgbGV0J3MgZ2V0IHRoZSBiYWxs IHJvbGxpbmcuPGJyPjxicj48ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPlJlZ2FyZHMsPGRp dj5Vcmk8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlNlbnQgZnJvbSBteSBpUGhvbmU8L2Rpdj48 L2Rpdj48ZGl2Pjxicj5PbiBNYXIgOCwgMjAxOSwgYXQgMTM6NDYsIFRvbnkgQXJjaWVyaSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmJhc2N1bGVAZ21haWwuY29tIj5iYXNjdWxlQGdtYWlsLmNvbTwvYT4m Z3Q7IHdyb3RlOjxicj48YnI+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48bWV0 YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11 dGYtOCI+PGRpdiBkaXI9Imx0ciI+PGRpdiBkaXI9Imx0ciI+T24gRnJpLCBNYXIgOCwgMjAxOSBh dCA5OjUzIEFNIFBhdWwgV291dGVycyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBhdWxAbm9oYXRzLmNh Ij5wYXVsQG5vaGF0cy5jYTwvYT4mZ3Q7IHdyb3RlOjxicj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFp bF9xdW90ZSI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBw eCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3Bh ZGRpbmctbGVmdDoxZXgiPkkgaGF2ZSBzdHJvbmcgcmVzZXJ2YXRpb25zIGFib3V0IHRoZSBvY2Ig ZHJhZnQuIFJvZ2F3YXkgaGFzIHBhdGVudHM8YnI+DQpvbiBPQ0IsIGFuZCBoYXMgcHV0IGNvbnN0 cmFpbnMgb24gaXRzIHVzZSBhbmQgdGhlcmUgaXMgbm8gZ2VuZXJpYyBJUFI8YnI+DQpzdGF0ZW1l bnQgdGhhdCB0aGUgSUVURiBub3JtYWxseSBsaWtlcyB0byBzZWUgZm9yIHdvcmsgcHVibGlzaGVk IGFzPGJyPg0KUkZDLiBVbnRpbCBzdWNoIGEgdGltZSwgSSBkbyBub3QgdGhpbmsgcHVibGlzaGlu ZyBSRkMncyB3aXRoIE9DQiBpczxicj4NCmFkdmlzZWQuIEEgZmV3IHllYXJzIGFnbyBJIGFza2Vk IHRoZSBUTFMgT0NCIGF1dGhvcnMgYWJvdXQgZXh0ZW5kaW5nPGJyPg0KdGhlaXIgYWxsb3dlZCB1 c2FnZSB0byBJS0UvSVBzZWMgYW5kIHRoZXkgdG9sZCBtZSB0aGlzIHVzZSB3YXMgbm90PGJyPg0K Y292ZXJlZCBieSBSb2dhd2F5J3MgbGljZW5zZSB0byB0aGVtLiBXaGlsZSB0aGlzIGhhcyBzaW5j ZSBjaGFuZ2VkIGEgYml0LDxicj4NCmFuZCB0aGVyZSBpcyBubyBsb25nZXIgYSBzcGVjaWZpYyBU TFMtb25seSBsaWNlbnNlLCBvdGhlciBjb25zdHJhaW5zIGFyZTxicj4NCnN0aWxsIGluIHBsYWNl LiZuYnNwOyBTcGVjaWZ5aW5nIE9DQiBkb2N1bWVudHMgdGhhdCBjYW5ub3QgYmUgaW1wbGVtZW50 ZWQgb3I8YnI+DQpkZXBsb3llZCBpbmRpc2NyaW1pbmF0b3J5IGlzIHRyb3VibGVzb21lLjxicj48 L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5JIHdvdWxkIGFncmVlIHRoZSBJUFIgc3Rv cnkgZm9yIE9DQiBpcyBwcmVzZW50bHkgYmFkLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Um9n YXdheSBoYWQgcHJldmlvdXNseSB2b2ljZWQgaW50ZXJlc3QgaW4gY29tcGxldGVseSByZXNvbHZp bmcgdGhlIHBhdGVudCBzaXR1YXRpb24gKGkuZS4gZGlzYXZvd2luZyB0aGUgcGF0ZW50cywgd2l0 aCBhbiBhdHRvcm5leSdzIGFzc2lzdGFuY2UpIGhvd2V2ZXIgc2FkbHkgaXQgc2VlbXMgaGUgbmV2 ZXIgY29tcGxldGVkIHRoaXMgd29yay4gUGVyaGFwcyBJIGNhbiBhdHRlbXB0IHRvIGdldCB0aGUg YmFsbCByb2xsaW5nIG9uIHRoYXQgYWdhaW4uLi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7 Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCI+ DQpTZWNvbmQsIEknbSBub3QgYSBjcnlwdG9ncmFwaGVyLCBidXQgaXQgc2VlbXMgT0NCIGhhcyBy ZWNlbnRseSBzZWVuIHNvbWU8YnI+DQphdHRhY2tzIHRoYXQgbWlnaHQgaW1wYWN0IHRoZSBzZWN1 cml0eSBvZiBPQ0I6PGJyPg0KPGJyPg0KQ3J5cHRhbmFseXNpcyBvZiBPQ0IyPGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly9lcHJpbnQuaWFjci5vcmcvMjAxOC8xMDQwIiByZWw9Im5vcmVmZXJyZXIiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL2VwcmludC5pYWNyLm9yZy8yMDE4LzEwNDA8L2E+PGJyPg0K PGJyPg0KQnJlYWtpbmcgdGhlIGNvbmZpZGVudGlhbGl0eSBvZiBPQ0IyPGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly9lcHJpbnQuaWFjci5vcmcvMjAxOC8xMDg3IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2VwcmludC5pYWNyLm9yZy8yMDE4LzEwODc8L2E+PGJyPg0KPGJy Pg0KUGxhaW50ZXh0IFJlY292ZXJ5IEF0dGFjayBvZiBPQ0IyPGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly9lcHJpbnQuaWFjci5vcmcvMjAxOC8xMDkwIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL2VwcmludC5pYWNyLm9yZy8yMDE4LzEwOTA8L2E+PC9ibG9ja3F1b3RlPjxk aXY+PGJyPjwvZGl2PjxkaXY+VGhlcmUgYXJlIHRocmVlIHZhcmlhbnRzIG9mIE9DQjogT0NCMSwg T0NCMiwgYW5kIE9DQjMuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGVzZSBhdHRhY2tzIGFw cGx5IHRvIE9DQjIuIFRoZXkgZG8gbm90IGFwcGx5IHRvIE9DQjEgb3IgT0NCMy48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2Pk9DQjMgaXMgcmVhbGlzdGljYWxseSB3aGF0IHdlIHNob3VsZCBiZSB1 c2luZyBwcm92aWRlZCB0aGUgSVBSIHN0b3J5IGNhbiBiZSBjbGVhcmVkIHVwLjwvZGl2PjxkaXY+ Jm5ic3A7PC9kaXY+PC9kaXY+LS0gPGJyPjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9zaWdu YXR1cmUiPlRvbnkgQXJjaWVyaTxicj48L2Rpdj48L2Rpdj4NCjwvZGl2PjwvYmxvY2txdW90ZT48 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxzcGFuPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj48c3Bhbj5DZnJnIG1haWxpbmcgbGlz dDwvc3Bhbj48YnI+PHNwYW4+PGEgaHJlZj0ibWFpbHRvOkNmcmdAaXJ0Zi5vcmciPkNmcmdAaXJ0 Zi5vcmc8L2E+PC9zcGFuPjxicj48c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pcnRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NmcmciPmh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY2ZyZzwvYT48L3NwYW4+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48L2JvZHk+PC9o dG1sPg== --Apple-Mail-3C54267F-2BD4-477E-9FC5-D9DC8E91BECC-- --Apple-Mail-AD8B3CE8-3F23-4841-9436-30710D2C2E48 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITojCCBLww ggOkoAMCAQICASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe Fw0xMzEyMTcwMDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gc KS9SlQRfqMW8F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUif Semk671G+mNZKLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NP Js/oW6YpHF5gmNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICa HIHO+VBDlA01Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFll Q5F/AgMBAAGjggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN /c9G3sjHEofKvzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMC AYYwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8/TExSQ0EwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8E LDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYow gYcwDQYLKoZIhvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcS AgEDAQkwDQYLKoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZI hvcSAgEDAQ8wDQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFqu MBzuLKeFwMSBbB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF /M+H3h1v9kneqXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsT kfrbLLErVY8+BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCi pAwj3wzMNh4s6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+Dba vUxXxFHU+S2Myw06w98wggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNV BAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcNMjAxMjMxMjM1OTU5WjBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw EQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18 tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jFvBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5o vvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8li hUixePbxWad1m7ZMKKagvm9zTybP6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+ yDz8Jzk6sP9iilgP3iXSGoCAmhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9 dtb05cy1gXAFSP3Z/iUkxyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHQ4EFgQU12BmDntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3y EMND7SkwDgYDVR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov L2NybC5sbC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t aXQuZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0GCyqG SIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0G CyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBBQUA A4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/LTCxqULjOd+H+HTqM JXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZcEEgOWC9bHcrElzU6Nni gahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbTiHe7DqfWQ2tVMLUf23XYhIua 94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r/aMsPAKx6nMaOvRL7Cy0Pjp51i2q FkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPfMIIE7TCCA9WgAwIBAgIKMziUjwAAAABu ljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAz OVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh Ym9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1 ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9 AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIws l5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK 1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpK SFq80SEh6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGe kpQVubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0G CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGG G2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiD g+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVy aUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBTAFcwDQYJ KoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaF H5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lc osfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4i vIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/p HKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mLMLqGNX3azAkwggUtMIIEFaADAgEC AgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwHhcN MTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSswKQYDVQQDEyJCbHVtZW50aGFs LlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA g+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oLToMnJQ6phCIkQGplPsM+9Ppz Icw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSNAB8WG3L+6a3mHcp9yYumPkdt M20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p6umBCLGxZi0cGhBI/7ZyJmJU Uo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857MF4OcehpG7LuxufD0p+g02uX7 Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCCAeYwHQYDVR0OBBYEFPbiFDP7 1vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBTXYGYOe0mNdUwN/c9G 3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3AwPQYJKwYB BAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhYHgQIbXxk0CAWQCAQkw LAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsGAQUFBwMCMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5lZHWgJgYKKwYBBAGCNxQCA6AY DBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQgHh4ATABMAE0AbwBiAGkAbABl AFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1DkfqhBA4LYklB+i49k6dh7L+n DEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1RjH8vLNFOEV8ZVcNxbWC5DiA 6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AOLm42Gn4lLeNrY4Ex8nq2Ah3x jB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G/HyJg9MUukKq23qm6Ys0VJQc JsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9Dszxz7LQECXI0KrPpM7x32Su lMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBM YWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCChp0xCAAAAAArQMw CQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTkwMzA4MTg1MTA4WjAjBgkqhkiG9w0BCQQxFgQUrmzfZRaS6aHrDVejO73eFTgfBGcwbgYJKwYB BAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgozOJSPAAAAAG6WMHAGCyqGSIb3 DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgozOJSPAAAAAG6WMA0GCSqGSIb3 DQEBAQUABIIBAAARGr3PVD6j52bSoZMCuZHsn2/l0k0SoHam8Q+KkkJZFdFP/XD5ySvoDyYu6ouM uSdJQWEXsB6TI9QgsR45tpIDW4m/beu+CNcMJccRuobhxx9sWoYgywcjaXD8vs6VMMDED3NBtzcf jD5itnKJv9Qf99XoYXn+jT4mC2+zAqnpWsQt4nXlpAqjsNasvRSjfnhDXNzm5RcDHzK1VWuWuIEd g8Pmt7yZ1MUQfMix06xfh4dWOZejHMVqGVeOm++1XExvbIeC5AZcRQOTWarbLUTk+oAJl4BRCrhp Aq0gBiDUWuuhBrhqlmDk1vq6qzwBb/JFSVDkRyCKTrI3tD99Ke0AAAAAAAA= --Apple-Mail-AD8B3CE8-3F23-4841-9436-30710D2C2E48-- From nobody Fri Mar 8 11:15:10 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 962D91313FE for ; Fri, 8 Mar 2019 11:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IM7clntyvSZv for ; Fri, 8 Mar 2019 11:15:01 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 250471313FD for ; Fri, 8 Mar 2019 11:15:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3320CBE5F; Fri, 8 Mar 2019 19:14:59 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgUS7HejLo54; Fri, 8 Mar 2019 19:14:58 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CFA3FBE5C; Fri, 8 Mar 2019 19:14:57 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1552072497; bh=7Vz6XevX72eNb9jf7/TIQZqRjEM5uR/UBjibwudS4u0=; h=Cc:References:To:From:Subject:Date:In-Reply-To:From; b=iMUypRVIL1UBnUBSCu1/9R8hChuwtcjTdfiUBrmg46iRjGwj3B92KX23X7bXzG9p9 PqZvm20h9LfK8WBnDNM9FETSO/DTb6l23dvyTn3vos4sUxMDnxWU8VcsBqQWyPlVib qrBEDCXpcaRdPrEghz4O/AN+5rOjxyb/OU7pwsdA= Cc: "RFC ISE (Adrian Farrel)" , secdir References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> To: CFRG From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Fri, 8 Mar 2019 19:14:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="llDKYEIo6ySFDzyl9AspndiGaAjFICApI" Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 08 Mar 2019 19:15:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --llDKYEIo6ySFDzyl9AspndiGaAjFICApI Content-Type: multipart/mixed; boundary="wERMYqu7LuyGlwTh101cQ7EfSmQOs7DT8"; protected-headers="v1" From: Stephen Farrell To: CFRG Cc: "RFC ISE (Adrian Farrel)" , secdir Message-ID: Subject: Re: [Cfrg] [secdir] ISE seeks help with some crypto drafts References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> In-Reply-To: --wERMYqu7LuyGlwTh101cQ7EfSmQOs7DT8 Content-Type: multipart/mixed; boundary="------------3201245AE9E009C7B308BCFF" Content-Language: en-GB This is a multi-part message in MIME format. --------------3201245AE9E009C7B308BCFF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable FWIW, I'd prefer have fewer and not more modes of operation documented. I'm not aware of a need for what this draft appears to specify (based on reading just the abstract). I also agree the OCB IPR situation isn't clear (IIRC more than just Rogaway's IPR was involved). I also don't see a need to document rc5/6 test vectors in an RFC as they're not really used in Internet protocols afaik. (If that last was wrong my position on that one could change.) For those reasons I'd suggest that the world would be better if the ISE decided not to publish either. I'd also argue that the IETF will be generally better off if we route crypto algorithm/mode and related RFCs via CFRG. That way we can be more confident of the level of scrutiny and openness associated with the set of such RFCs. That is a change from what we (the IETF) used do, which was to send such stuff to the ISE. I think it'd be great if we(*) came to consensus that via-CFRG is a better route for all/almost-all such RFCs than via-ISE. Cheers, S. (*) "we" would I guess need to include the ISE, sec-ads and CFRG. --------------3201245AE9E009C7B308BCFF Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------3201245AE9E009C7B308BCFF-- --wERMYqu7LuyGlwTh101cQ7EfSmQOs7DT8-- --llDKYEIo6ySFDzyl9AspndiGaAjFICApI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyCvzAACgkQWrL68XsX K+qJnA/+MFeKXMSMd3R/7P64W3bhVaBYkLxRx+TpEjyrecMnmTJ82tSTWVuIHO7r UGgpFnq7WlgW846zQvBT1hN/r40xOL5GRcRH/Ykl0TqrbwfzBNcuK5yAQPAO0sHk E1B3SW1sVvtyJHQJenCtA9X8SRfam4ZKQ9YUYyNo0+0CGZ3fv//+XJKu0cksGn4q u2FUlV9EvMH/0On6UgLcjpdRKWA3hVSYNiBDwaQLyPRo2sIUCWf5eTK/ZV+a09Za UFeTGpFefAeQKWzH8xqbU7S4xaY/qFiagva8/PEP/GrXSIjNTeMCgwxSvO93LatT 4cpLBAYwDPOEGGV3iAByFZliiLR1o7/01ym4krROEAyYd5Z7AxNxxZRflwdOg1Wt /XIg10De9VGnuQzt5qZB0oiEZ9yGlWTrZb7VbdHI832JO1idX8tr9NfqHwWpal+2 TawEQ1eYn0nQttPOAQfEQ+tLMfTREic77QqbSUrR8rbyWTNt6KkX0u571psURpUt w36EyEhyfwUwRCpKggHZVunzv7RAQmU4OlsjnPWljLLfmkZ2zjIfZTzUehyrbDt8 jb2jtoh4xvKs4+Z/N0JlwspyNeJHrcoRvDantzwD/wQ2z4Z5xUUq0NOgBMxxqzC/ V/a7GO/L7tv6ZzhZ13MhC8obNTOtofndcMf+TqhNBxSkQ6I0yVI= =P9s/ -----END PGP SIGNATURE----- --llDKYEIo6ySFDzyl9AspndiGaAjFICApI-- From nobody Fri Mar 8 12:34:09 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 D97381274A1 for ; Fri, 8 Mar 2019 12:34:07 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 a64oMX3zWfeQ for ; Fri, 8 Mar 2019 12:34:05 -0800 (PST) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 6C281124BA8 for ; Fri, 8 Mar 2019 12:34:05 -0800 (PST) Received: by mail-ot1-x331.google.com with SMTP id n71so18474124ota.10 for ; Fri, 08 Mar 2019 12:34:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sNjUcz00a+guYv+wGUl7cMnb1LwIB6q1ElbqSbkEzkE=; b=l/56LE6e6+W8jYjs9Z3+17ViowZfGOtrW4urMjbdK7IzLZhfc/C1qZAmOdTb1M5+JQ wllMTbs7Gig9HPrsUbwOrQ1xIW9T2ObwFQ5cDPRIBzvNf6QOr7ChP9VjLTVlKUiqNxUy HZhrTPdgsgnwx5Gyn0fgdLVyXMxlK/w8BzsZdFbK5oTLCD8OSHkFRbZZpA85FM6gze7g RKw50YQ0DJ8Kbqh3TNqNiHpUyCb0uT0WDzk7XoI8u2VEqRHRv11M9wVgOWGdhCSE28y3 UDOabZvTNBHBB1rfTzY4ZBdVoqbtnNB2nqX7isjIC6k+qmVNQnaUgRUJcEFhPzlL/DW6 zlMg== 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=sNjUcz00a+guYv+wGUl7cMnb1LwIB6q1ElbqSbkEzkE=; b=hpIGuwqmgw1lI8+iQBb/6rhz4EEg0/B4UFZCBR+q+d0xh1/XAn0MyrUwWusCEt1Mtn uwVyzyjlyfY3YycMHbNL4pqzRjtrxc8g2YVxpy1+nosRCauWykKCyQI0iJgB3ZUOOrVR XnKjot1hOsSrtYo+UuLkHsleYBfGiRUzKjuQFO4o2ZEB2/lR/5ugJN3xxA6mp1mC4DOn yF78R/re5UJ21D9smnbK9mcPMPhFqdofkUmcrzRWLt1grEDiz0w604sVdCd7ymkIMUAo H7MJsTVpEFZbWqzRB4RgXBMAcNRNGUvtK+l99Hm38RCihVBQSdhA/bQowhQW9LMI0CK/ AMCw== X-Gm-Message-State: APjAAAUdMC6vFAjfr3SsLpVxJGe8aX6y5ZP5XPcUXjCmD3r9nw1vq3DC uaN9uW87J8rxuHeKb7xwBAw0BzfE1mjfB90Dj2E= X-Google-Smtp-Source: APXvYqxsjRS8OU59xyx4mvGMOeNzS7VJyQnQTZxGgow/ZVjIbkMWL3t9lUWy5TLE9FksmEjKchuf/8/HOuP/lI2u/fw= X-Received: by 2002:a9d:4d0c:: with SMTP id n12mr13187519otf.176.1552077244095; Fri, 08 Mar 2019 12:34:04 -0800 (PST) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> In-Reply-To: From: Tony Arcieri Date: Fri, 8 Mar 2019 12:33:53 -0800 Message-ID: To: Stephen Farrell Cc: CFRG , "RFC ISE (Adrian Farrel)" , secdir Content-Type: multipart/alternative; boundary="000000000000cc600605839b243e" Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 08 Mar 2019 20:34:08 -0000 --000000000000cc600605839b243e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 8, 2019 at 11:15 AM Stephen Farrell wrote: > > FWIW, I'd prefer have fewer and not more modes of operation > documented. I'm not aware of a need for what this draft > appears to specify (based on reading just the abstract). I > also agree the OCB IPR situation isn't clear (IIRC more than > just Rogaway's IPR was involved). > Rogaway has a pretty detailed description of the IPR situation on the OCB site: http://web.cs.ucdavis.edu/~rogaway/ocb/ocb-back.htm =E2=80=94 snip =E2=80=94 Does Phil have a patent on OCB? Yes, I did file patent applications covering the new techniques used in OCB. There was a filing on 12 October 2000, and a filing on 9 February 2001. If you want to use OCB in a commercial product, you'll need to get a license from me. But I'll license this IP under fair, reasonable, and non-discriminatory terms. All companies will be offered the same license agreement. I expect licensees to pay a modest, one-time fee. Here is a patent-assurance letter I wrote for the IEEE, which mandates OCB in a *draft*802.11 (Wireless LAN) standard, as part of the WEP ("Wired Equivalent Privacy") protocol. How much will a license cost? Not much. I intend that no solvent company should find licensing from me to be a significant issue in their cost of doing business. Here is an offer letter indicating how I am licensing OCB.Has OCB already been licensed? Yes, it has. But, unfortunately, I am not at liberty to say more.Will anyone else come to have a valid patent that covers OCB? Unfortunately, this question is impossible to answer at this point. IBM has indicated that it has a patent filing that covers Jutla's authenticated-encryption work. They indicate that this was filed on 14 April 2000. Gligor has indicated that he has three patent filings that cover his authenticated-encryption and parallelizable MAC work. He indicates that these were filed on 31 January 2000, 31 March 2000, and 24 August 2000. All of these filings were provisional patent filings. One can only conjecture who will have what enforceable rights. As for Jutla/IBM, I have been clear all along that OCB retains similarities to Jutla's IAPM. Intellectually, OCB owes much to Jutla's work. But whether or not IBM's patent covers OCB may depend on how broadly IBM's claims were crafted. As for Gligor/VDG, I am unaware of any idea from [Gligor, Donescu; 18 August 2000] that I used in OCB. I believe that any utility patent filed after Jutla's work and my work appeared but based on a provisional patent filed before Jutla's work and my work appeared will need to be examined with care, comparing the contents of the utility patent to the contents of the provisional patent, and paying attention to what was published in the interval. Such an exercise is currently impossible, because provisional patents are not made available before utility patents issue. I start to think that I have been too talkative and too concerned about what IP other parties could come to hold. In truth, nobody ever knows the answer to this question. --=20 Tony Arcieri --000000000000cc600605839b243e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Mar 8, 2019 at 11:15 AM Stephen Farrell <stephen.farrell@cs.tcd.ie> wro= te:

FWIW, I'd prefer have fewer and not more modes of operation
documented. I'm not aware of a need for what this draft
appears to specify (based on reading just the abstract). I
also agree the OCB IPR situation isn't clear (IIRC more than
just Rogaway's IPR was involved).

Rogaway has a pr= etty detailed description of the IPR situation on the OCB site:


=E2= =80=94 snip =E2=80=94

Does Phil have a patent on OCB?=C2=A0<= /a>

Yes, I did file patent applications covering the new techniques used in= OCB. There was a filing on 12 October 2000, and a filing on 9 February 200= 1. If you want to use OCB in a commercial product, you'll need to get a= license from me. But I'll license this IP under fair, reasonable, and = non-discriminatory terms. All companies will be offered the same license ag= reement. I expect licensees to pay a modest, one-time fee.

Here is a=C2=A0patent-assurance letter=C2=A0I wrote = for the IEEE, which mandates OCB in a=C2=A0draft802.11 (Wireless LAN= ) standard, as part of the WEP ("Wired Equivalent Privacy") proto= col.=C2=A0

How much will a license cost?=C2=A0

= Not much. I i= ntend that no solvent company should find licensing from me to be a signifi= cant issue in their cost of doing business. Here is an=C2=A0offer letter=C2=A0indicating how I am licensing OCB.Has OCB already been licensed?=C2=A0Yes, it has. But, unfortunately, I am not= at liberty to say more.

Will anyone else come to have a v= alid patent that covers OCB?=C2=A0

Unfortunately, this question is impossible to= answer at this point. IBM has indicated that it has a patent filing that c= overs Jutla's authenticated-encryption work. They indicate that this wa= s filed on 14 April 2000. Gligor has indicated that he has three patent fil= ings that cover his authenticated-encryption and parallelizable MAC work. H= e indicates that these were filed on 31 January 2000, 31 March 2000, and 24= August 2000. All of these filings were provisional patent filings.<= p style=3D"font-family:-webkit-standard">One can only conjecture who will h= ave what enforceable rights. As for Jutla/IBM, I have been clear all along = that OCB retains similarities to Jutla's IAPM. Intellectually, OCB owes= much to Jutla's work. But whether or not IBM's patent covers OCB m= ay depend on how broadly IBM's claims were crafted.

As for Gligor/VDG, I am unaware of any idea from = [Gligor, Donescu; 18 August 2000] that I used in OCB. I believe that any ut= ility patent filed after Jutla's work and my work appeared but based on= a provisional patent filed before Jutla's work and my work appeared wi= ll need to be examined with care, comparing the contents of the utility pat= ent to the contents of the provisional patent, and paying attention to what= was published in the interval. Such an exercise is currently impossible, b= ecause provisional patents are not made available before utility patents is= sue.

I start to think that I h= ave been too talkative and too concerned about what IP other parties could = come to hold. In truth, nobody ever knows the answer to this question.

<= /div>
--
Tony Arcieri
--000000000000cc600605839b243e-- From nobody Fri Mar 8 14:00:33 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 567A3127988; Fri, 8 Mar 2019 13:16:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1552079815; bh=TulXgqHUov9avtA9CKLfFi6HciOhltkqeCUE1tusMpw=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=VQWOamHK5Fowxrg2qmPP+eTd7D83iAGqTlxSuKb1iytBiunuE8omfq16ENJgFAdc3 D9JgvsjhdXt+YUA59GbJukIoyPw1BHsa02OUu6T+j96v7mLPwJcgqXL8zLUNWpAcET 64U1uF7lWpW8i1UWtrarhoemrl0mHsiCteMc+EBw= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Mar 8 13:16:49 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A94BD130F04; Fri, 8 Mar 2019 13:16:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1552079808; bh=TulXgqHUov9avtA9CKLfFi6HciOhltkqeCUE1tusMpw=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=kqy5RWh9epiJKaLIx632CQ5cgBgXtEceRIwXKLg+09GgFhAB5cikykQjzxF4XNlwS JRLVrLEJpSBpCjOHsJMlbz8eVSmqCax3wCxiS3FNrsmPaF/kuTBlXhY5U3l6YvL4fP raj7gOCFh4X+Hc8b7pjJ7A+f42jh3zsc0MW0uT/Q= 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 9A0011277E7 for ; Fri, 8 Mar 2019 13:16:39 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <155207979962.3197.9894300550021556677.idtracker@ietfa.amsl.com> Date: Fri, 08 Mar 2019 13:16:39 -0800 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, 08 Mar 2019 14:00:32 -0800 Subject: [secdir] [new-work] WG Review: Relay User Machine (rum) 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, 08 Mar 2019 21:17:02 -0000 QSBuZXcgSUVURiBXRyBoYXMgYmVlbiBwcm9wb3NlZCBpbiB0aGUgQXBwbGljYXRpb25zIGFuZCBS ZWFsLVRpbWUgQXJlYS4gVGhlCklFU0cgaGFzIG5vdCBtYWRlIGFueSBkZXRlcm1pbmF0aW9uIHll dC4gVGhlIGZvbGxvd2luZyBkcmFmdCBjaGFydGVyIHdhcwpzdWJtaXR0ZWQsIGFuZCBpcyBwcm92 aWRlZCBmb3IgaW5mb3JtYXRpb25hbCBwdXJwb3NlcyBvbmx5LiBQbGVhc2Ugc2VuZCB5b3VyCmNv bW1lbnRzIHRvIHRoZSBJRVNHIG1haWxpbmcgbGlzdCAoaWVzZ0BpZXRmLm9yZykgYnkgMjAxOS0w My0xOC4KClJlbGF5IFVzZXIgTWFjaGluZSAocnVtKQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpDdXJyZW50IHN0 YXR1czogUHJvcG9zZWQgV0cKCkNoYWlyczoKICBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5u ZXQ+CiAgUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+CgpBc3NpZ25lZCBBcmVh IERpcmVjdG9yOgogIEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb20+CgpBcHBsaWNhdGlvbnMg YW5kIFJlYWwtVGltZSBBcmVhIERpcmVjdG9yczoKICBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0u Y29tPgogIEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPgogIEFsZXhleSBNZWxuaWtvdiA8 YWFtZWxuaWtvdkBmYXN0bWFpbC5mbT4KCk1haWxpbmcgbGlzdDoKICBBZGRyZXNzOiBydW1AaWV0 Zi5vcmcKICBUbyBzdWJzY3JpYmU6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnVtCiAgQXJjaGl2ZTogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL2Jyb3dz ZS9ydW0vCgpHcm91cCBwYWdlOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2dyb3VwL3J1 bS8KCkNoYXJ0ZXI6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0 Zi1ydW0vCgpNYW55IGN1cnJlbnQgaW5zdGFuY2VzIG9mIFZpZGVvIFJlbGF5IFNlcnZpY2UgKFZS UyksIHNvbWV0aW1lcyBjYWxsZWQgVmlkZW8KSW50ZXJwcmV0YXRpb24gU2VydmljZSwgdXNlIHRo ZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkgYW5kIG90aGVyCklFVEYgbXVsdGlt ZWRpYSBwcm90b2NvbHMuIFZSUyBpcyB1c2VkIGJ5IGRlYWYvaGFyZC1vZi1oZWFyaW5nIHBlcnNv bnMgYW5kIGJ5CnBlcnNvbnMgd2l0aCBzcGVlY2ggaW1wYWlybWVudHMgdG8gY29tbXVuaWNhdGUg d2l0aCBoZWFyaW5nIHBlcnNvbnMuICBUaGUKZGVhZiwgaGFyZC1vZi1oZWFyaW5nLCBvciBzcGVl Y2gtaW1wYWlyZWQgcGVyc29uIChELUhPSC1TSSkgdXNlcyBhIFNJUC1iYXNlZAp2aWRlbyBwaG9u ZSB0byBjb25uZWN0IHdpdGggYW4gaW50ZXJwcmV0ZXIsIGFuZCB0aGUgaW50ZXJwcmV0ZXIgcGxh Y2VzIGEKcGhvbmUgY2FsbCB0byB0aGUgaGVhcmluZyBwZXJzb24uIFRoZSBoZWFyaW5nIHBlcnNv biBjYW4gYWxzbyByZWFjaCBELUhPSC1TSQppbmRpdmlkdWFscyBpbiB0aGUgc2FtZSBtYW5uZXIg YXMgY2FsbGluZyBhbnkgaGVhcmluZyB1c2VyLiAgVGhlIEQtSE9ILVNJCnBlcnNvbiB1c2VzIHNp Z24gbGFuZ3VhZ2UgYW5kIHBvc3NpYmx5IHJlYWwtdGltZSB0ZXh0IHdpdGggdGhlIGludGVycHJl dGVyCmFuZCB0aGUgaW50ZXJwcmV0ZXIgdXNlcyBzcG9rZW4gbGFuZ3VhZ2Ugd2l0aCB0aGUgaGVh cmluZyBwZXJzb24sIHByb3ZpZGluZwpvbi1saW5lLCByZWFsLXRpbWUsIHR3by13YXkgY29tbXVu aWNhdGlvbi4KCkhhdmluZyBhIHN0YW5kYXJkIGludGVyZmFjZSBiZXR3ZWVuIHRoZSBlbmQtdXNl ciBkZXZpY2UgYW5kIHRoZSBWUlMgcHJvdmlkZXIKYWxsb3dzIHZlbmRvcnMgYW5kIG9wZW4tc291 cmNlIGRldmVsb3BlcnMgdG8gYnVpbGQgZGV2aWNlcyB0aGF0IHdvcmsgd2l0aAptdWx0aXBsZSBz ZXJ2aWNlIHByb3ZpZGVyczsgZGV2aWNlcyBjYW4gYWxzbyBiZSByZXRhaW5lZCB3aGVuIGNoYW5n aW5nCnByb3ZpZGVycy4gIEluIHRoaXMgaW5zdGFuY2UsIOKAnGRldmljZeKAnSBjb3VsZCBiZSBh IHB1cnBvc2UtYnVpbHQgdmlkZW9waG9uZSBvcgpjb3VsZCBiZSBkb3dubG9hZGFibGUgc29mdHdh cmUgb24gYSBnZW5lcmFsIHB1cnBvc2UgY29tcHV0aW5nIHBsYXRmb3JtIG9yCm1vYmlsZSBwaG9u ZS4gVG8gZW5zdXJlIGludGVyb3BlcmFiaWxpdHkgb2YgdGhlIGtleSBmZWF0dXJlcyBvZiB0aGlz IHNlcnZpY2UsCmNlcnRhaW4gYXNwZWN0cyAoZS5nLiwgY29kZWNzLCBtZWRpYSB0cmFuc3BvcnQs IGFkZHJlc3NpbmcgYW5kIFNJUCBmZWF0dXJlcykKbXVzdCBiZSBzcGVjaWZpZWQgYXMgbWFuZGF0 b3J5LXRvLWltcGxlbWVudCBmb3IgU0lQLWJhc2VkIFZSUyBkZXZpY2VzLiBUaGVzZQpzcGVjaWZp ZWQgZmVhdHVyZXMgZWZmZWN0aXZlbHkgZm9ybSBhIHByb2ZpbGUgZm9yIFNJUCBhbmQgdGhlIG1l ZGlhIGl0Cm5lZ290aWF0ZXMuCgpUaGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBwcm9kdWNlIGEgc2lu Z2xlIGRvY3VtZW50OiBhIHByb2ZpbGUgb2YgU0lQIGFuZCBtZWRpYQpmZWF0dXJlcyBmb3IgdXNl IHdpdGggdmlkZW8gcmVsYXkgc2VydmljZXMgKHdoaWNoIGluY2x1ZGVzIHZpZGVvLCByZWFsIHRp bWUKdGV4dCwgYW5kIGF1ZGlvKSwgYW5kIG90aGVyIHNpbWlsYXIgaW50ZXJwcmV0YXRpb24gc2Vy dmljZXMgdGhhdCByZXF1aXJlCm11bHRpbWVkaWEuICBJdCB3aWxsIHJlZmVyZW5jZSB0aGUgSUVU RuKAmXMgY3VycmVudCB0aGlua2luZyBvbiBtdWx0aW1lZGlhCmNvbW11bmljYXRpb24sIGluY2x1 ZGluZyByZWZlcmVuY2VzIHRvIHdvcmsgYmV5b25kIFNJUCAoZS5nLiwgV2ViUlRDIGFuZApTTElN KS4gIE5vIHByb3RvY29sIGNoYW5nZXMgYXJlIGFudGljaXBhdGVkIGJ5IHRoaXMgd29yay4KCk9m dGVuLCB0aGUgaGVhcmluZyB1c2VyIGlzIG9uIHRoZSBQU1ROLCBhbmQgUlVNIHdpbGwgaW5jbHVk ZSBpbnRlcm9wZXJhYmlsaXR5CnNwZWNpZmljYXRpb25zIGZvciB0aGF0IHVzZSwgaW5jbHVkaW5n IHRoZSB1c2Ugb2YgdGVsZXBob25lIG51bWJlcnMuICBSVU0Kd2lsbCBub3QgYXNzdW1lIGhlYXJp bmcgdXNlcnMgYXJlIG9uIHRoZSBQU1ROLgoKV2hpbGUgV2ViUlRDIGNvdWxkIGJlIHVzZWQgdG8g aW1wbGVtZW50IGEgcHJvZmlsZSB0byBmdWxmaWxsIFJVTSdzCnJlcXVpcmVtZW50cywgdGhlIGdy b3Vw4oCZcyB3b3JrIHdpbGwgZm9jdXMgb24gdGhlIGRldmljZS10by1wcm92aWRlcgppbnRlcmZh Y2UuICBUaGUgd29ya2luZyBncm91cCB3aWxsIGNvbnNpZGVyIHdheXMgZm9yIFdlYlJUQyBiYXNl ZCBzZXJ2aWNlcyB0bwppbnRlcndvcmsgd2l0aCBhIFJVTS1jb21wbGlhbnQgcHJvdmlkZXIsIGJ1 dCBpcyBub3QgcmVxdWlyZWQgdG8gbWFrZSBzdWNoCmludGVyd29yayBwb3NzaWJsZS4KClJVTSBk ZXZpY2VzIHdpbGwgYmUgZXhwZWN0ZWQgdG8gYmUgYWJsZSB0byBwbGFjZSBlbWVyZ2VuY3kgY2Fs bHMgY29uZm9ybWluZwp0byB0aGUgY3VycmVudCBJRVRGIGVtZXJnZW5jeSBjYWxsIHJlY29tbWVu ZGF0aW9ucy4KClRoZSBzY29wZSBvZiB0aGUgd29yayBpbmNsdWRlcyBtZWNoYW5pc21zIHRvIHBy b3Zpc2lvbiB0aGUgdXNlcuKAmXMgZGV2aWNlIHdpdGgKY29tbW9uIGZlYXR1cmVzIHN1Y2ggYXMg c3BlZWQgZGlhbCBsaXN0cywgcHJvdmlkZXIgdG8gY29udGFjdCwgdmlkZW9tYWlsCnNlcnZpY2Ug aW50ZXJmYWNlIHBvaW50IGFuZCBzaW1pbGFyIGl0ZW1zLiAgVGhlc2UgZmVhdHVyZXMgYWxsb3cg dXNlcnMgdG8KbW9yZSBlYXNpbHkgc3dpdGNoIHByb3ZpZGVycyB0ZW1wb3JhcmlseSAoYSBmZWF0 dXJlIGtub3duIGFzIOKAnGRpYWwgYXJvdW5k4oCdKQpvciBwZXJtYW5lbnRseSwgd2hpbGUgcmV0 YWluaW5nIHRoZWlyIGRhdGEuCgpEZXZpY2VzIHVzZWQgaW4gVlJTIGNhbiBiZSB1c2VkIHRvIHBs YWNlIHBvaW50LXRvLXBvaW50IGNhbGxzIHdoZXJlIGJvdGgKY29tbXVuaWNhdGluZyBwYXJ0aWVz IHVzZSBzaWduIGxhbmd1YWdlLiAgV2hlbiB1c2VkIGZvciBwb2ludC10by1wb2ludApjYWxsaW5n IHdoZXJlIHRoZSBwYXJ0aWNpcGFudHMgYXJlIG5vdCBzZXJ2ZWQgYnkgdGhlIHNhbWUgVlJTIHBy b3ZpZGVyLCBvcgp3aGVuIG9uZSBwcm92aWRlciBwcm92aWRlcyB0aGUgb3JpZ2luYXRpbmcgbXVs dGltZWRpYSB0cmFuc3BvcnQgZW52aXJvbm1lbnQsCmJ1dCBhbm90aGVyIHByb3ZpZGVzIHRoZSBp bnRlcnByZXRlciAo4oCcZGlhbC1hcm91bmQgY2FsbOKAnSksIHRoZSBjYWxsIHRyYXZlcnNlcwp0 d28gcHJvdmlkZXJzLiAgQm90aCBvZiB0aGVzZSB1c2VzIGltcG9zZSBhZGRpdGlvbmFsIHJlcXVp cmVtZW50cyBvbiBhIFJVTQpkZXZpY2UgYW5kIGFyZSBpbiBzY29wZSBmb3IgdGhpcyB3b3JrLgoK QWx0aG91Z2ggdGhlIGludGVyZmFjZSBiZXR3ZWVuIHByb3ZpZGVycyBhbHNvIHJlcXVpcmVzIHN0 YW5kYXJkaXphdGlvbiB0bwplbmFibGUgbXVsdGktcHJvdmlkZXIgcG9pbnQtdG8tcG9pbnQgYW5k IGRpYWwtYXJvdW5kIGNhbGxzLCB0aGF0ICBpbnRlcmZhY2UKaGFzIGFscmVhZHkgYmVlbiBkZWZp bmVkIGluIGEgU0lQIEZvcnVtIGRvY3VtZW50IGFuZCBpcyB0aHVzIG91dCBvZiBzY29wZSBmb3IK UlVNLgoKTWlsZXN0b25lczoKCiAgRGVjIDIwMTkgLSBTdWJtaXQgYSBwcm9maWxlIG9mIFNJUCBh bmQgbWVkaWEgZmVhdHVyZXMgZm9yIHVzZSB3aXRoIHZpZGVvCiAgcmVsYXkgc2VydmljZXMgdG8g dGhlIElFU0cgZm9yIHB1YmxpY2F0aW9uCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KbmV3LXdvcmsgbWFpbGluZyBsaXN0Cm5ldy13b3JrQGlldGYub3Jn Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV3LXdvcmsK From nobody Fri Mar 8 14:04:36 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 78FEE1277CD; Fri, 8 Mar 2019 14:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 omFypDYDZ5_u; Fri, 8 Mar 2019 14:04:27 -0800 (PST) Received: from mail-yw1-xc31.google.com (mail-yw1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (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 42D131277C9; Fri, 8 Mar 2019 14:04:24 -0800 (PST) Received: by mail-yw1-xc31.google.com with SMTP id x20so3203272ywd.5; Fri, 08 Mar 2019 14:04:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hZSupaQe1WLHGbrrpdU3hhjMwHTcOT8Vyal5hjlZJaY=; b=giyGmXX3aXS7k4/3OchR3MfWmzNwAGx5/eCcXlyIPEc187wBzl6tJNMmzm7u4XKJ77 mEeDanC72NdTy/cHjf5O+OSmRT/1cGPsLp3LSBgwH6uP/RmDbVbN/c7nhTG6dOIYCwO8 iekabOoOb9fRpvA96XPuMCC4D9oPHq7RuSRpAQmQ9gM7PNfETfEGy+YQR2VSawerI/iR ULdMu87SWnrcJ2QMppJzO2yvD/7Qp2C1MKp8Btdp4tkrxODQNzjgoA5B/WzXb+UpG8OP t5zAbwmXL53eGHU696vz2xJU3xSy+aeow+cc8L9y/f/b6Jrk9cqwfkcVjRgq5BCVSOcv /rTg== 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:content-transfer-encoding; bh=hZSupaQe1WLHGbrrpdU3hhjMwHTcOT8Vyal5hjlZJaY=; b=aJJU+fzmJoHmRRooW9ncVijvm/0xMbxwMs/KY8MrFjyZJMYc9+xSSNDkLU/7Sd6HAx l9K6fqNKyMnLK4D2c1oXkeIaAYPIdLxqm35Bq/fp5o92hcQ9KfbNqiJSq/KGLp4U73kN rKirEPnHBHEUf3e7zfbuLAqvJAphbAkq9BOVWXtSRTRCx0TfqYULKz5GyysP/eKO2XnK ptiXsNUiGooWis4KaBi5gYpE1tNQtrJwbgMn5ttFxvN56hQFUrOES6Aj2J2Re/oszIHw VkOucT6+PfzhRSqoqwotTUMtmdXmn6tAH+KeOBOFWkpT7FsAUECzGIWNk+BtMxziea+S zCNA== X-Gm-Message-State: APjAAAVEpQzVi9d4DzaDsf1wJe0kMFLIfr86r9m0NWq8479inuUN5mHe 0QrGHutNXQP5TfYiKk6uPe+z0TyUayMHQ57KZ9k= X-Google-Smtp-Source: APXvYqwLj8kt/38KllZ8PucCzLbhHmvCHTvc2DhJyRcYe/AcbkR+kS8kvXY//942SDyV7Tfp5CId15gcqXOPrebx9p0= X-Received: by 2002:a81:2544:: with SMTP id l65mr16477828ywl.263.1552082663123; Fri, 08 Mar 2019 14:04:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Christopher Wood Date: Fri, 8 Mar 2019 14:04:12 -0800 Message-ID: To: Chuck Lever Cc: draft-ietf-nfsv4-mv0-trunking-update@ietf.org, secdir , The IESG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-nfsv4-mv0-trunking-update-02 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, 08 Mar 2019 22:04:29 -0000 On Thu, Dec 27, 2018 at 10:52 AM Chuck Lever wrote= : > > > > > On Dec 20, 2018, at 11:14 AM, Spencer Dawkins at IETF wrote: > > > > Hi, Authors, > > > > On Tue, Dec 11, 2018 at 8:16 AM Christopher Wood wrote: > > Hello, > > > > 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 my review is: Ready with nits. > > > > I believe these are the only Last Call comments I've seen on your draft= , and the Last Call period has ended. > > > > Could you respond to Christopher, and (if necessary) submit a revised d= raft? > > > > Thanks! > > > > Spencer (D) > > > > This document is in great shape and very well written. Most of my > > comments are editorial in nature aimed at helping improve readability o= f > > the document. Please let me know if you=E2=80=99ve further questions, > > comments, or concerns. > > Hello Chris- > > Thanks for your review, and my apologies for the delayed response. > > > > - Section 3, fourth bullet: Regarding =E2=80=9C[NFSv4.1] distinguishes = two > > (see [RFC5661]),=E2=80=9D would it be possible to provide the two types= of > > trunking relationships inline? Although this document is meant to > > supplement existing work, I do think it would help improve readability > > and minimize cross-referencing. > > After discussion, Dave and I removed the text that mentions NFSv4.1- > specific features in this paragraph. They are an unnecessary > digression. > > > > - Section 5.1, fifth bullet: Rather than specify that addresses =E2=80= =9CMUST > > provide a way of connecting to a single server,=E2=80=9D could we speci= fy > > desired client behavior if this does not happen? I do not know how ofte= n > > such misconfigurations occur, though it seems prudent to provide > > guidance in case it does. > > Dave and I agree that specifying client behavior here is a better > approach. Dave provided new text. > > > > - Section 5.2, sixth bullet: It might be worth pointing to the amended > > Security Considerations section, which contains relevant text regarding > > DNSSEC validation for host name entries. I left a note here while > > reading only to discover it was addressed later on. > > We assume you meant Section 5.1, sixth bullet. A reference to Section > 7 "Security Considerations" was added at the end of this paragraph. > > > > - Section 5.2.3: Are clients allowed to race connection attempts across > > all types available? The text implies that this must be done > > sequentially, which seems unnecessarily prohibitive. > > We introduced a couple of paragraphs of implementation guidance that > compares sequential and parallel connection approaches. > > > > - Section 5.2.5, third paragraph, first sentence: Perhaps a simpler way > > to write this is something akin to =E2=80=9Cfs_locations cannot point t= o > > alternate locations until data propagation occurs=E2=80=9D? > > We updated the text to clarify the ordering requirements. > > > Because you feel the document is "ready with nits" I've taken the > liberty of submitting draft-ietf-nfsv4-mv0-trunking-update-03 > with these changes. rfcdiff will show the exact text that has > changed. Let us know if any further changes are necessary. No further changes needed. Thanks for the updates! Best, Chris From nobody Fri Mar 8 14:45:50 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 A02BF127876; Fri, 8 Mar 2019 14:45:48 -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_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 Yos0_6JmSp-q; Fri, 8 Mar 2019 14:45:46 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 A1D4D1277E7; Fri, 8 Mar 2019 14:45:46 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 16812D6118D746E1CF55; Fri, 8 Mar 2019 22:45:44 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 8 Mar 2019 22:45:43 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.29]) by SJCEML702-CHM.china.huawei.com ([169.254.4.10]) with mapi id 14.03.0415.000; Fri, 8 Mar 2019 14:45:41 -0800 From: Linda Dunbar To: Linda Dunbar via Datatracker , "secdir@ietf.org" CC: "mpls@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org" , "ietf@ietf.org" Thread-Topic: Secdir telechat review of draft-ietf-mpls-lsp-ping-lag-multipath-06 Thread-Index: AQHU1dNnxc5hRAyYl0CHKWsrtsDdC6YCUnoQ Date: Fri, 8 Mar 2019 22:45:40 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B2EE17E@sjceml521-mbs.china.huawei.com> References: <155206570582.3202.12517909943780959477@ietfa.amsl.com> In-Reply-To: <155206570582.3202.12517909943780959477@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.125.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-mpls-lsp-ping-lag-multipath-06 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, 08 Mar 2019 22:45:49 -0000 TmVlZCB0byBtb2RpZnkgbXkgcmV2aWV3IGNvbW1lbnRzOg0KDQpSZXZpZXdlcjogTGluZGEgRHVu YmFyDQpSZXZpZXcgcmVzdWx0OiBSZWFkeQ0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVu dCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRv IHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiAg VGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2Yg dGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLg0KIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNo YWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0 IGNhbGwgY29tbWVudHMuDQoNClRoZSBkZXNjcmliZWQgbWVjaGFuaXNtIGZvciBMU1AgTXVsdGlw YXRoIFBpbmcgaXMgdmVyeSBjbGVhci4NClRoZSBhdXRob3JzIGhhdmUgYWRkZWQgdGhlIHRleHQg dG8gYWRkcmVzcyBteSBjb21tZW50cyB0byB0aGUgMDUgdmVyc2lvbiBvbiB3aHkgdGhlcmUgaXMg bm8gc2VjdXJpdHkgcmlza3Mgb2YgaW50ZXJtZWRpYXRlIExTUnMgdGFtcGVyaW5nIGRhdGEgd2hl biB0aGUgTFNQIE11bHRpcGF0aCBQaW5nICYgcmVzcG9uc2UgYXJlIHRyYXZlcnNpbmcgdGhyb3Vn aC4gDQoNCkxpbmRhIER1bmJhcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog aWV0ZiBbbWFpbHRvOmlldGYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExpbmRhIER1 bmJhciB2aWEgRGF0YXRyYWNrZXINClNlbnQ6IEZyaWRheSwgTWFyY2ggMDgsIDIwMTkgMTE6MjIg QU0NClRvOiBzZWNkaXJAaWV0Zi5vcmcNCkNjOiBtcGxzQGlldGYub3JnOyBkcmFmdC1pZXRmLW1w bHMtbHNwLXBpbmctbGFnLW11bHRpcGF0aC5hbGxAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmcNClN1 YmplY3Q6IFNlY2RpciB0ZWxlY2hhdCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5n LWxhZy1tdWx0aXBhdGgtMDYNCg0KUmV2aWV3ZXI6IExpbmRhIER1bmJhcg0KUmV2aWV3IHJlc3Vs dDogUmVhZHkNCg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUg c2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYg ZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdl cmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVh IGRpcmVjdG9ycy4NCiBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0 IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0K DQpUaGUgZG9jdW1lbnQgcHJvdmlkZXMgdGhlIGRldGFpbGVkIGV4cGxhbmF0aW9uIG9mIFNSLU1Q TFMgcHJvY2Vzc2luZyBpbiBhZGRpdGlvbiB0byBSRkMgODQwMi4gU2luY2UgU1ItTVBMUyBhcmUg aW4gdGhlIHRydXN0ZWQgZG9tYWluLCBpdCBpcyBhc3N1bWVkIHRoYXQgdGhlcmUgaXMgbm8gbWFs aWNpb3VzIGF0dGFja3MgdG8gdGhlIG5vZGVzIGZvciB0aGUgZGF0YSBwbGFuZSBhbmQgY29udHJv bCBwbGFuZS4gIFJGQzg0MDIgYWxyZWFkeSBoYXMgdGhlIGdvb2QgZGVzY3JpcHRpb24gb24gdGhl IFNlY3VyaXR5IENvbnNpZGVyYXRpb24gZm9yIGJvdGggU1ItTVBMUyAmIFNSdjYuDQoNCkJlc3Qg UmVnYXJkcywNCkxpbmRhIER1bmJhcg0KDQo= From nobody Fri Mar 8 15:53: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 77F8F12788F; Fri, 8 Mar 2019 15:52:50 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 gVvMd907AOTP; Fri, 8 Mar 2019 15:52:46 -0800 (PST) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (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 F2D56126DFA; Fri, 8 Mar 2019 15:52:45 -0800 (PST) Received: by mail-oi1-x232.google.com with SMTP id t82so17239719oie.12; Fri, 08 Mar 2019 15:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pTFDMWtIKHuM1Hmsmz5hpGhCqwN7HwGOoA9vQoJGzYU=; b=gWuW/zaGNcgqtWIt/dGuTj/uTFLVVvTLr9Z7Kiu/1yYTuJW1f25EuJaF2M3sCpv7kt HRw0s5XgeGNcL6enx+2K8zqnMpAK0fX22StZ2uOzviSsww0oNKJzZbnmwFFMRbkBSLrp lAu+VsT8I7EsNpV2XHwfnne2zGOBGaewVHl12RhILy3zltRXKsIR93JWYZI07P0hrmAa 7gVa+2DDlhaBbN8mLju/FyOq8N6hPUbw959wxrYdP21f8SKHExgUV7LMRbvXRlj3Ex9h 9PJfBcfDWvO2Fj2ub/6F0ilFEhgMY1PcZt5V03O2LPYm1EzAvGumOt7C8NS127plp3TK r16Q== 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=pTFDMWtIKHuM1Hmsmz5hpGhCqwN7HwGOoA9vQoJGzYU=; b=UHkPhTzKukSjvC/JlEttKjxeB/FkpIt9TNTQjnqMHBRPzyRkNcVr232ciTT8Y6HDLU tmD2RDIeDckw8DGPxYPDJiSR8BY+0rIbcAD8O4zAY0fZJM5HKwRbz1ffW8zr7CKTHDvO FH5taEginG26uMd8QVP5pAzDKdpj/BpNFQMZ8HiDlmkFgsc4cawsVvxmpJd+pwMdZvlW 2dMrh4aVBmecd/VHVbhEpJfKQyoyB6YwRPRv6juDzBYD56xK84bTjk3p54d2Y9dF4Wod wo50ySZ66xp9TngKOzmLNAyj0o53se7TdrNmA+/1ylcTa+tZqw7MxQZs3Ox1Yt6xrcFB 7CMQ== X-Gm-Message-State: APjAAAU7hRFjjVsstu39yd1gBlg6Be5TGM4DNf86EZQ5rtddAC+ycY9n RjQVfGkt7vVTVaPzICkoj58/uNvabpixUT8QOzA= X-Google-Smtp-Source: APXvYqxmJCYd29Vb5KuqtuegyYpxaVqoCeutcNYnYlDfovlDGYyCtopEthpoDo8vVf3/MlJww21BnIeDnrsTnuAwKwo= X-Received: by 2002:aca:f0c3:: with SMTP id o186mr9312874oih.101.1552089164963; Fri, 08 Mar 2019 15:52:44 -0800 (PST) MIME-Version: 1.0 References: <155128908237.14053.17188619727012241844@ietfa.amsl.com> In-Reply-To: From: David Noveck Date: Fri, 8 Mar 2019 18:52:33 -0500 Message-ID: To: Sean Turner Cc: secdir@ietf.org, ietf@ietf.org, NFSv4 , draft-ietf-nfsv4-mv1-msns-update.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000566aac05839debbf" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-nfsv4-mv1-msns-update-04 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, 08 Mar 2019 23:52:51 -0000 --000000000000566aac05839debbf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I previously said: > Will address nits 0)-4) and 6)-10) in -05. However when I looked more closely at 9), I've found that I cannot make the requested change. > 9) s12.2.3: replace ietf.org with example.org (not supposed to use > real domains even if it is =E2=80=9Cours=E2=80=9D). This is not an example. The use of ietf,org is intentional and is intended as a way to provide the ability to define globally usable variable definition as well as domain-specific ones. This is specified in section 22.5 of RFC5661. I'm not sure about the details of the prohibition of the use of real domain names but I can;t see how it would apply in this case where this form of vatibl specification, including a real domain name has already been adopted. On Thu, Feb 28, 2019 at 8:30 PM David Noveck wrote: > > These > > instructions will really help when work on a fully revised NFS RFC gets > > going. > > That's the intention. The working group is now discussing the possibilit= y > of an rfc5661bis > that would use those instructions. Note that the current document would > be the source of > a large set of the changes but there are also others: The > internationalization section needs to > be updated as it was in RFC7530. Section 12 needs to be updated to > reflect the work done by > RFC8434. Also, there are a lot of erratta that would need to be applied. > > > 0) The big issue being addressed in the security considerations is the > fact > > that RPSEC_GSS is must support not must use > > That reflects choices made for RFC3530 and carried over until now. This > has resulted in > a situation in which AUTH_SYS is very commonly used despite its obvious > security weaknesses. > > > So what do you do when RFC 5661 says: > > > The fetching of attributes containing file system location > > information SHOULD be performed using RPCSEC_GSS with integrity > > protection, > > Not much, since there is not much I can do about that. > > > And, you don=E2=80=99t now change to MUST use RPSEC_GSS? > > No I don't. Currently use of AUTH_SYS is allowed and the working > group has not made any decision to change that. > > > Well I think at a minimum you should do some 2119 language: > > OK, but note that this is a widely-deployed protocol and we are not > in a position to invalidate deployment choices made in line with RFC5661, > even if we think they were ill-advised. > > > 0) s16 (after the bullets): 2119 this should: > > If you are suggesting changing "should" to "SHOULD" in this parapgraph, > I'm OK with making that change in -05, although I will raise the issue wi= th > the working group to check about existing implemtations. > > > 1) s16 (2nd para after the bullets): 2199 this SHOULD NOT: > > I intend to shift this to "SHOULD NOT" in -05. > > > 2) s16 (last bullet): 2119 this should: > > Given that this bullet appears in a summary, I think the "should" is > misleading. Converting it to "SHOULD" would lead to recommemmending > filtering without specifying the filtering to be done. What I propose to > do in -05 is replace "should be subect to filtering" by "is made subject = to > filtering as described above". > > > The use of requests issued without RPCSEC_GSS (i.e. using > > the known to be insecure AUTH_SYS), while undesirable and > > Insecure, may not be avoidable in all cases. > > While I approve of drawing more attention to the weaknesses of > AUTH_SYS, I feel the use of the word "insecure" is too vague. > "Insecure" covers a range of problems whereby traffic is either > exposed to prying eyes, subject to corruption in transit, or acted > upon without authentiction. Given the context, I think we need to > be clear about what the actual problem is even though AUTH_SYS, > in what has to be considered a virtuoso performance :-), manages > to acomplish the hat trick of protocol insecurity. > > So I propose writing this as follows: > > The use of requests issued without RPCSEC_GSS (i.e. using AUTH_SYS which > has no provision to avoid corruption of data in flight), while undesirabl= e > and a potential security exposure, may not be avoidable in all cases. > > > > It=E2=80=99s probably also worth discussing whether s14.3 should drop > > support for includes id-sha1 > > The text you are referring to was carried over from RFC5661 as-is since > there was no issue known with it. > > Regarding the potential deletion of id-sha1, the issue, given that server > support is currently REQUIRED, is whether there are clients using this wh= o > might be impacted by a change. I'll check with the working group. > > > 4) s4.3 (1st sentence): Not sure the 2119-RECOMMENDED is needed. > > These are really OPTIONAL althouh the word "RECOMMENDED" is (confusingly) > used. > Will delete. > > > 5) s4.3 (penultimate para): Seems like r/should/SHOULD. > > It is probably the case that RFC5661 made a poor choice here. However, I > don't think we can change it now. > > > 10) s16 (3rd bullet): Why is requirement is caps? > > It's because I was under the misapprehension that statement that things > were REQUIRED or RECOMMENDED could be referred to as "REQUIREMENTS" or > "RECOMMENDATIONS". It turns out not to be so. > > Will address nits 0)-4) and 6)-10) in -05. > > On Wed, Feb 27, 2019 at 12:38 PM Sean Turner wrote: > >> Reviewer: Sean Turner >> Review result: Has Issues >> >> This draft updates NFSv4.1 to correct handling of the fs_locations and >> fs_locations_info attributes; NFSv4.1 weighs in at 617 pages and this >> draft weighs in a relatively spry 106; let=E2=80=99s say I was really, r= eally >> hoping >> for some multi-page ASCII art, but also no pretty much all text. The >> draft does a good job of explaining what=E2=80=99s being replaced and wh= y, but >> I have to say that I did not check all of section pointers. These >> instructions will really help when work on a fully revised NFS RFC gets >> going. Unfortunately for me, I do not have NFSv4.1 in my head so let=E2= =80=99s >> just say that I did my best =E2=80=A6 >> >> Summary: This draft is probably worthy of some type of DISCUSS based >> on the following: >> >> 0) The big issue being addressed in the security considerations is the >> fact >> that RPSEC_GSS is must support not must use and the other mechanism >> referred to by RFC 5661 are: >> >> - AUTH_NONE - nada authentication >> >> - AUTH_SYS as described in Appendix A is known to be insecure due to >> the lack of a verifier to permit the credential to be validated. >> AUTH_SYS SHOULD NOT be used for services that permit clients to >> modify data. AUTH_SYS MUST NOT be specified as RECOMMENDED or >> REQUIRED for any Standards Track RPC service. >> >> - AUTH_DH as mentioned in Sections 8.2 and 13.4.2 is considered >> obsolete and insecure; see [RFC2695]. AUTH_DH SHOULD NOT be used for >> services that permit clients to modify data. AUTH_DH MUST NOT be >> specified as RECOMMENDED or REQUIRED for any Standards Track RPC >> service. >> >> So what do you do when RFC 5661 says: >> The fetching of attributes containing file system location >> information SHOULD be performed using RPCSEC_GSS with integrity >> protection, >> And, you don=E2=80=99t now change to MUST use RPSEC_GSS? Well I think a= t a >> minimum you should do some 2119 language: >> >> 0) s16 (after the bullets): 2119 this should: >> >> In light of the above, a server should present file system >> location entries that correspond to file systems on other servers >> using a host name. >> >> 1) s16 (2nd para after the bullets): 2199 this SHOULD NOT: >> >> As a >> result, the client should not use such unverified location entries >> as a basis for migration, even though RPCSEC_GSS might be >> available on the destination. >> >> 2) s16 (last bullet): 2119 this should: >> >> Where the use of the returned information cannot be >> avoided, it should be subject to filtering to eliminate the >> possibility that the client would treat an invalid address as >> if it were a NFSv4 server. >> >> And, I guess since AUTH_SYS is insecure can I suggest a friendly >> amendment to the following sentence: >> >> OLD: >> The use of requests issued without RPCSEC_GSS (i.e. using >> AUTH_SYS), while undesirable, may not be avoidable in all >> cases. >> >> NEW: >> >> The use of requests issued without RPCSEC_GSS (i.e. using >> the known to be insecure AUTH_SYS), while undesirable and >> Insecure, may not be avoidable in all cases. >> >> It=E2=80=99s probably also worth discussing whether s14.3 should drop >> support for includes id-sha1. >> >> >> These are the nits: >> >> 0) Update to use new 2119 paragraph: >> >> 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. >> >> 1) s3.1 (wordy): r/since the >> ports to be used for various types of connections might be >> required to be different/since the >> ports to be used for various types of connections might be >> different. >> >> 2) s3.1 (missing period): r/Two such addresses support the use of client= id >> ID trunking, as described in [RFC5661]/Two such addresses support the >> use of clientid >> ID trunking, as described in [RFC5661]. >> >> 3) s4.2 (missing word): r/which may accessed/which may be accessed >> >> 4) s4.3 (1st sentence): Not sure the 2119-RECOMMENDED is needed. >> >> 5) s4.3 (penultimate para): Seems like r/should/SHOULD. >> >> 6) s4.5: r/present , is/present, is >> >> 7) s4.5: Note sure you need the parenthetical in the following: >> a server may (but is not required to) >> >> 8) s4.5.4: r/In the event that server failures,/In the event that >> server fails, >> or >> r/In the event that server failures,/In the event of server failures, >> >> 9) s12.2.3: replace ietf.org with example.org (not supposed to use >> real domains even if it is =E2=80=9Cours=E2=80=9D). >> >> 10) s16 (3rd bullet): Why is requirement is caps? >> >> --000000000000566aac05839debbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I previously said:
> Will address nits 0)-4) and 6)= -10) in -05.

However when I looked more closely at= 9), I've found that I cannot make the requested change.

=
> 9) s12.2.3: replace=C2=A0ietf.org=C2=A0with=C2=A0example.org=C2= =A0(not supposed to use
> real domains even if it is =E2=80=9Cours=E2= =80=9D).

This is not an example.=C2=A0 =C2=A0The u= se of ietf,org is intentional and is intended as a way
to provide= the ability to define globally usable variable definition as well as domai= n-specific
ones.=C2=A0 This is specified in section 22.5 of RFC56= 61.=C2=A0 =C2=A0I'm not sure about the details of
the prohibi= tion of the use of real domain names but I can;t see how it would apply in = this
case where this form of vatibl specification, including a re= al domain name has already
been adopted.=C2=A0 =C2=A0=C2=A0
=
=C2=A0

On Thu, Feb 28, 2019 at 8:30 PM David Noveck <davenoveck@gmail.com> wrote:
> = These
> instructions will really help when work on a fully revised NF= S RFC gets
> going.

That's the intention.=C2= =A0 The working group is now discussing the possibility of an rfc5661bis
that would use those instructions.=C2=A0 =C2=A0Note that the curren= t document would be the source of
a large set of the changes but = there are also others: The internationalization section needs to
= be updated as it was in RFC7530.=C2=A0 Section 12 needs to be updated to re= flect the work done by=C2=A0
RFC8434.=C2=A0 Also, there are a lot= of erratta that would need to be applied.

> 0)= The big issue being addressed in the security considerations is the fact> that RPSEC_GSS is must support not must use

That reflects choices made for RFC3530 and carried over until now.=C2=A0 = =C2=A0This has resulted in
a situation in which AUTH_SYS is very = commonly used despite its obvious security weaknesses.

=
> So what do you do when RFC 5661 says:

>=C2=A0 Th= e fetching of attributes containing file system location
>=C2=A0 info= rmation SHOULD be performed using RPCSEC_GSS with integrity
>=C2=A0 p= rotection,

Not much, since there is not much I can= do about that.

> And, you don=E2=80=99t now change to MUS= T use RPSEC_GSS?=C2=A0

No I don't.=C2=A0 =C2= =A0Currently use of AUTH_SYS is allowed and the working
group has= not made any decision to change that.=C2=A0 =C2=A0=C2=A0

> Well I think at a minimum you should do some 2119 language:

OK, but note that this is a widely-deployed protocol= and we are not
in a position to invalidate deployment choices ma= de in line with RFC5661,
even if we think they were ill-advised.<= /div>

> 0) s16 (after the bullets): 2119 this should:=

If you are suggesting changing "should"= to "SHOULD" in this parapgraph,
I'm OK with making= that change in -05, although I will raise the issue with
the= working group to check about existing implemtations.

<= div>> 1) s16 (2nd para after the bullets): 2199 this SHOULD NOT:=C2=A0= =C2=A0

I intend to shift this to "SHOULD = NOT"=C2=A0 in -05.

> 2) s16 (last bullet):= 2119 this should:

Given that this bullet appe= ars in a summary, I think the "should" is misleading.=C2=A0 =C2= =A0Converting it to "SHOULD" would lead to recommemmending filter= ing without specifying the filtering to be done.=C2=A0 What I propose to do= in -05 is replace "should be subect to filtering" by "is ma= de subject to filtering as described above".

= > The use of requests issued without RPCSEC_GSS (i.e. using
>=C2= =A0 the known to be insecure AUTH_SYS), while undesirable and
>=C2=A0= Insecure, may not be avoidable in all cases.=C2=A0=C2=A0
While I approve of drawing more attention to the weaknesses of= =C2=A0
AUTH_SYS, I feel the use of the word "insecure" = is too vague.=C2=A0 =C2=A0
"Insecure" covers a range of= problems whereby traffic is either=C2=A0
exposed to prying eyes,= subject to corruption in transit, or acted=C2=A0
upon without au= thentiction.=C2=A0 =C2=A0Given the context, I think we need to=C2=A0
<= div>be clear about what the actual problem is even though AUTH_SYS,=C2=A0
in what has to be considered a virtuoso performance :-), manages= =C2=A0
to acomplish the hat trick of protocol insecurity.

So I propose writing this as follows:

The use of requests issued without RPCSEC_GSS (i.e. using AUTH_SYS wh= ich has no provision to avoid corruption of data in flight), while undesira= ble and a potential security exposure, may not be avoidable in all cases.= =C2=A0=C2=A0=C2=A0

> It= =E2=80=99s probably also worth discussing whether s14.3 should drop
> support for includes id-sha1

The text you a= re referring to was carried over from RFC5661 as-is since there was no issu= e known with it.

Regarding the potential deletion = of id-sha1, the issue, given that server support is currently REQUIRED, is = whether there are clients using this who might be impacted by a change.=C2= =A0 =C2=A0I'll check with the working group.

&= gt; 4) s4.3 (1st sentence): Not sure the 2119-RECOMMENDED is needed.
<= div>
These are really OPTIONAL althouh the word "RECOMME= NDED" is (confusingly) used.
Will delete.

> 5) s4.3 (penultimate para): Seems like r/should/SHOULD.

It is probably the case that RFC5661 made a poor choice h= ere.=C2=A0 However, I don't think we can change it now.

<= /div>
> 10) s16 (3rd bullet): Why is requirement is caps?=C2=A0=

It's because I was under the misapprehension = that statement that things were REQUIRED or RECOMMENDED could be referred t= o as "REQUIREMENTS" or "RECOMMENDATIONS".=C2=A0 It turn= s out not to be so.=C2=A0
=C2=A0=C2=A0
Will a= ddress nits 0)-4) and 6)-10) in -05.

On Wed, Feb 27, 2019 at 12:38 PM = Sean Turner <sean@sn= 3rd.com> wrote:
Reviewer: Sean Turner
Review result: Has Issues

This draft updates NFSv4.1 to correct handling of the fs_locations and
fs_locations_info attributes; NFSv4.1 weighs in at 617 pages and this
draft weighs in a relatively spry 106; let=E2=80=99s say I was really, real= ly hoping
for some multi-page ASCII art, but also no pretty much all text.=C2=A0 The<= br> draft does a good job of explaining what=E2=80=99s being replaced and why, = but
I have to say that I did not check all of section pointers.=C2=A0 These
instructions will really help when work on a fully revised NFS RFC gets
going.=C2=A0 Unfortunately for me, I do not have NFSv4.1 in my head so let= =E2=80=99s
just say that I did my best =E2=80=A6

Summary: This draft is probably worthy of some type of DISCUSS based
on the following:

0) The big issue being addressed in the security considerations is the fact=
that RPSEC_GSS is must support not must use and the other mechanism
referred to by RFC 5661 are:

- AUTH_NONE - nada authentication

- AUTH_SYS as described in Appendix A is known to be insecure due to
=C2=A0 =C2=A0the lack of a verifier to permit the credential to be validate= d.
=C2=A0 =C2=A0AUTH_SYS SHOULD NOT be used for services that permit clients t= o
=C2=A0 =C2=A0modify data.=C2=A0 AUTH_SYS MUST NOT be specified as RECOMMEND= ED or
=C2=A0 =C2=A0REQUIRED for any Standards Track RPC service.

- AUTH_DH as mentioned in Sections 8.2 and 13.4.2 is considered
=C2=A0 =C2=A0obsolete and insecure; see [RFC2695].=C2=A0 AUTH_DH SHOULD NOT= be used for
=C2=A0 =C2=A0services that permit clients to modify data.=C2=A0 AUTH_DH MUS= T NOT be
=C2=A0 =C2=A0specified as RECOMMENDED or REQUIRED for any Standards Track R= PC
=C2=A0 =C2=A0service.

So what do you do when RFC 5661 says:
=C2=A0 The fetching of attributes containing file system location
=C2=A0 information SHOULD be performed using RPCSEC_GSS with integrity
=C2=A0 protection,
And, you don=E2=80=99t now change to MUST use RPSEC_GSS?=C2=A0 Well I think= at a
minimum you should do some 2119 language:

0) s16 (after the bullets): 2119 this should:

=C2=A0 In light of the above, a server should present file system
=C2=A0 location entries that correspond to file systems on other servers =C2=A0 using a host name.

1) s16 (2nd para after the bullets): 2199 this SHOULD NOT:

=C2=A0 =C2=A0As a
=C2=A0 =C2=A0result, the client should not use such unverified location ent= ries
=C2=A0 =C2=A0as a basis for migration, even though RPCSEC_GSS might be
=C2=A0 =C2=A0available on the destination.

2) s16 (last bullet): 2119 this should:

=C2=A0 Where the use of the returned information cannot be
=C2=A0 avoided, it should be subject to filtering to eliminate the
=C2=A0 possibility that the client would treat an invalid address as
=C2=A0 if it were a NFSv4 server.

And, I guess since AUTH_SYS is insecure can I suggest a friendly
amendment to the following sentence:

OLD:=E2=80=A8
=C2=A0 The use of requests issued without RPCSEC_GSS (i.e. using
=C2=A0 AUTH_SYS), while undesirable, may not be avoidable in all
=C2=A0 cases.

NEW:

=C2=A0 The use of requests issued without RPCSEC_GSS (i.e. using
=C2=A0 the known to be insecure AUTH_SYS), while undesirable and
=C2=A0 Insecure, may not be avoidable in all cases.

It=E2=80=99s probably also worth discussing whether s14.3 should drop
support for includes id-sha1.


These are the nits:

0) Update to use new 2119 paragraph:

=C2=A0 The key words "MUST", "MUST NOT", "REQUIRED= ", "SHALL", "SHALL NOT",
=C2=A0 "SHOULD", "SHOULD NOT", "RECOMMENDED",= "NOT RECOMMENDED", "MAY", and
=C2=A0 "OPTIONAL" in this document are to be interpreted as descr= ibed in BCP
=C2=A0 14 [RFC2119] [RFC8174] when, and only when, they appear in all
=C2=A0 capitals, as shown here.

1) s3.1 (wordy): r/since the
=C2=A0 ports to be used for various types of connections might be
=C2=A0 required to be different/since the
=C2=A0 ports to be used for various types of connections might be
=C2=A0 different.

2) s3.1 (missing period): r/Two such addresses support the use of clientid<= br> =C2=A0 ID trunking, as described in [RFC5661]/Two such addresses support th= e use of clientid
=C2=A0 ID trunking, as described in [RFC5661].

3) s4.2 (missing word): r/which may accessed/which may be accessed

4) s4.3 (1st sentence): Not sure the 2119-RECOMMENDED is needed.

5) s4.3 (penultimate para): Seems like r/should/SHOULD.

6) s4.5: r/present , is/present, is

7) s4.5: Note sure you need the parenthetical in the following:
=C2=A0 a server may (but is not required to)

8) s4.5.4: r/In the event that server failures,/In the event that
server fails,
or
r/In the event that server failures,/In the event of server failures,

9) s12.2.3: replace ietf.org with example.org (not supposed to use
real domains even if it is =E2=80=9Cours=E2=80=9D).

10) s16 (3rd bullet): Why is requirement is caps?

--000000000000566aac05839debbf-- From nobody Fri Mar 8 16:11: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 599DA126DFA for ; Fri, 8 Mar 2019 16:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, 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=ericsson.com header.b=AjGZKFr8; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Y16YiXk/ 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 QzwRLftKmycG for ; Fri, 8 Mar 2019 16:11:10 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 545EF127918 for ; Fri, 8 Mar 2019 16:11:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1552090268; x=1554682268; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=m/hedsTSOV14pKA7758W6+6yLZAhymT2gkupBjCUIrU=; b=AjGZKFr8TkLAuHGAphMgdKnl2Gh1N4WXalZM5I8cpabmySJd2hYbcbBD+tUPVsUg 2RiWWpvlWxLigYdPQUNRYzeSK8wiRIb2nQqVlFDv0+g7IuWb41hGpgE3kYml7FpN qh4FQZF8ydImlIAaCXP77PsJpRmh9960aAZYRBNkAOM=; X-AuditID: c1b4fb2d-db5ff7000000062f-d6-5c83049ce3d8 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CF.03.01583.C94038C5; Sat, 9 Mar 2019 01:11:08 +0100 (CET) Received: from ESESSMR506.ericsson.se (153.88.183.128) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 9 Mar 2019 01:11:08 +0100 Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSMR506.ericsson.se (153.88.183.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 9 Mar 2019 01:11:08 +0100 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sat, 9 Mar 2019 01:11:08 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m/hedsTSOV14pKA7758W6+6yLZAhymT2gkupBjCUIrU=; b=Y16YiXk/16ApIHOZo26gezi2ZQItpCgsm6mqTLi80bYHAp5XTTkQ3LY2MsXmNoPXAv3YMPm84amQFWPyPNlPe7K5brrJHljCmsY5JG7ZdO/sdn3Tdrk2M81PJm3BCtXm5sj/JyiLLTcPPsAzrN5xukEFU35QwS3aihlmUGgJYdI= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB4394.eurprd07.prod.outlook.com (20.176.167.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.9; Sat, 9 Mar 2019 00:11:03 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::ace2:9258:766:85a8]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::ace2:9258:766:85a8%3]) with mapi id 15.20.1709.010; Sat, 9 Mar 2019 00:11:03 +0000 From: John Mattsson To: David Wong , "Salz, Rich" CC: "sec-ads@ietf.org" , "cfrg@irtf.org" , "rfc-ise@rfc-editor.org" , "secdir@ietf.org" Thread-Topic: [Cfrg] ISE seeks help with some crypto drafts Thread-Index: AQHU1dNJB9nt0JnBP0Ouu0tIZhoDw6YCBMMAgAAEIACAAHViAA== Date: Sat, 9 Mar 2019 00:11:03 +0000 Message-ID: References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f4a20019-697c-4dfc-78b7-08d6a423b7be x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4394; x-ms-traffictypediagnostic: HE1PR07MB4394: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 0971922F40 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(366004)(39860400002)(346002)(136003)(51444003)(199004)(189003)(13464003)(5660300002)(53936002)(6246003)(99286004)(6306002)(82746002)(76176011)(26005)(6346003)(102836004)(53546011)(6506007)(8936002)(68736007)(229853002)(97736004)(6486002)(6436002)(3846002)(6116002)(25786009)(6512007)(486006)(66066001)(476003)(2616005)(44832011)(4326008)(54906003)(71200400001)(83716004)(71190400001)(256004)(58126008)(316002)(14454004)(36756003)(2906002)(11346002)(186003)(305945005)(106356001)(105586002)(478600001)(86362001)(8676002)(81166006)(7736002)(966005)(81156014)(446003)(33656002)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4394; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: gz3YxZEcOwaVT670jhYSpLtfS4mb8u+uc1PO1ubxzSs3bk6isGC83ljJiaiAnHFfRfoyxh03e/04WDmvypHLuEdHBeiszp1SqNOVwRCQ0KZPetnEkZocA2lTRX17iZoN8xH88KdmRsng3Ce6XZJP93POdfc9ZEPkOOSIxdG9SvsAvYrIjDFtqBPIrVuNGJEJ8X36bzuzGRiEvRsGuFTIjLlYCFKJid5JbzmbQFWRXZCjsHDG5EeBcrzEyXOzlOSPD4lLgE7gE5NbzypSOhzgvOZjvxw4Bl1RIfrIYziMLtlW+S0CYWjCCPf8lkE/y+mxo99VANw+6/1dSnfNcVrkc3RKuLTF01RQ+lrDmKhhw3+HdpSA3bphcbrub+Bfke5biCJDBUoNDx00ceErAbC9+AR0+GkyoVCmx0L92jEX6FM= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f4a20019-697c-4dfc-78b7-08d6a423b7be X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2019 00:11:03.1276 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4394 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHe3cuno0mr1PzYWnkCkLDS6W1LmZGwYqEIpEQu4w8qXllxzQl wgys1EJTEzdFJW+p5bShecnykiON1BQvoU3RL0vJIDNL07Ydi779nv/zf24vL0NIGigpEx4d x6qilZEyWkTmn2tMcCsgbwd79g9tlacvtQvkeQUPafnccCqSr+nukfLavAVS/rVkijxCK7K7 iglFk3rCSlFa+lOgyK7rpBXJqd3UaSpIdCiEjQyPZ1Uehy+JwrrmZlHsot31wYonKBlp7dKQ kAHsBaM5BjoNiRgJ7kIwVlhP8MF3BNrM54J/wWBPwbrtsQAmDC2UOSBxJgElQxWIz2QJYLwg dd1mQND4spgyj6GxJxS2JtNmtsOnYGFeaykncDmCkWyNxWSLD8DvOSPFmw7CwEAdyfNR6BrV WpjE26Ehc83SSIx9oaqTbyTB1abdF/IJc0KIfWBCq7eYEN4EP3pqBGYmsAN8nCkS8IdjKG3t I3i2B+P0qmWwPfYA3YNJktedobetct3jBB+K0hHP/vBeU2V5J8BjCIyGrPWEK0xql2iepVDS t2DFcwTk6l+bChgTO0LTmDcv59CQW3EjE3mq/1tPbXIR2AVqmz14WQHDhnmKZ2fISZ+yUlvO t4G3+TNkMaKqkD3HclxU6O497qwq/DLHxUS7R7Nx9cj0m9p1y24vUPWsXwfCDJJtFAtXUoIl lDKeS4zqQMAQMjtxw7RJEocoE5NYVcxF1bVIlutAmxlS5iBekdgES3CoMo6NYNlYVvU3K2CE 0mTkflfa0+J7K8Q/I8rarzgg8Kpc5TIVkFTuKX4q/uxS8+5OkObCyPLNbW3TZT6sW8oXffWW dq9VLuPsySv5lVk7npWdOKbesLckwdrJer77/q83pPdAzaLtKy9G16YJ2/fpfHba/m+2GVK9 zLH/jE6pLnp0vNl1Z30gGh23N/aKxwplJBem3OVKqDjlH8EN0jpJAwAA Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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 Mar 2019 00:11:13 -0000 R2l2ZW4gdGhhdCBDRlJHIGhhcyBhbHJlYWR5IHB1Ymxpc2hlZCBPQ0IzIGluIFJGQyA3MjUzLCB3 aGljaCB3YXMgcmVjZW50bHkgaW5jbHVkZWQgaW4gdGhlIENFQVNBUiBmaW5hbCBwb3J0Zm9saW8s IEkgd291bGQgbGlrZSB0byBzZWUgdGhlIE9DQjMgd2lkZWJsb2NrIGRyYWZ0IHB1Ymxpc2hlZCBz b21ld2hlcmUuIEkgYWdyZWUgd2l0aCBSaWNoIHRoYXQgaXQgd291bGQgYmUgYmV0dGVyIHRvIHJl cGxhY2UgUkZDIDc1MjMuDQoNClJlYWRpbmcgUkZDIDc1MjMgYWdhaW4sIGl0IGRvZXMgbm90IGZl ZWwgb3B0aW1hbCB0aGF0IHRoZSB0d28gc2xpZ2h0bHkgZGlmZmVyZW50IG1vZGVzIGRlZmluZWQg aW4gUkZDIDc1MjMgYW5kIHRoZSBGU0UgMjAxMSBwYXBlciBhcmUgYm90aCBjYWxsZWQgT0NCMy4N Cg0KVGhlIE9DQiB3aWRlYmxvY2sgZG9jdW1lbnQgc2VlbXMgdG8gbWVldCB0aGUgcmVxdWlyZW1l bnRzIGluIFJGQyA0ODQ2Lg0KDQovSm9obg0KDQrvu78tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogQ2ZyZyA8Y2ZyZy1ib3VuY2VzQGlydGYub3JnPiBvbiBiZWhhbGYgb2YgRGF2aWQg V29uZyA8ZGF2aWR3b25nLmNyeXB0b0BnbWFpbC5jb20+DQpEYXRlOiBGcmlkYXksIDggTWFyY2gg MjAxOSBhdCAxOToxMQ0KVG86ICJTYWx6LCBSaWNoIiA8cnNhbHpAYWthbWFpLmNvbT4NCkNjOiAi c2VjLWFkc0BpZXRmLm9yZyIgPHNlYy1hZHNAaWV0Zi5vcmc+LCAiY2ZyZ0BpcnRmLm9yZyIgPGNm cmdAaXJ0Zi5vcmc+LCAicmZjLWlzZUByZmMtZWRpdG9yLm9yZyIgPHJmYy1pc2VAcmZjLWVkaXRv ci5vcmc+LCAic2VjZGlyQGlldGYub3JnIiA8c2VjZGlyQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtDZnJnXSBJU0Ugc2Vla3MgaGVscCB3aXRoIHNvbWUgY3J5cHRvIGRyYWZ0cw0KDQpOb3RlIHRo YXQgT0NCIHdhcyBjaG9zZSBhcyBhIGZpbmFsaXN0IGluIHRoZSBDQUVTQVIgY29tcGV0aXRpb24u IEtub3dpbmcgdGhhdCwgaXQgc291bmRzIGxpa2UgYSBnb29kIGlkZWEgdG8gc3RhbmRhcmRpemUg aXQuDQoNCk9uIHRoZSBvdGhlciBoYW5kLCBpZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5IHlvdSBu ZWVkIHRvIHBheSBhIG9uZS10aW1lIGZlZSB0byB1c2UgdGhlIGFsZ29yaXRobSBpbiBhIGNvbW1l cmNpYWwgcHJvZHVjdD8gSSB0aGluayB0aGF04oCZcyBhIGJpZyBuby1ubyBjb25zaWRlcmluZyB3 ZSB3YW50IGV2ZXJ5Ym9keSB0byB1c2UgZ29vZCBvcGVuIHNvdXJjZSBsaWJyYXJpZXMuDQoNCkRh dmlkDQoNCj4gT24gTWFyIDgsIDIwMTksIGF0IDk6NTYgQU0sIFNhbHosIFJpY2ggPHJzYWx6QGFr YW1haS5jb20+IHdyb3RlOg0KPiANCj4gICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQta3JvdmV0ei1vY2Itd2lkZWJsb2NrLw0KPiANCj4gSSB3b3VsZCByYXRoZXIgc2Vl IHRoaXMgcmV3cml0dGVuIHRvIGNvbXBsZXRlbHkgcmVwbGFjZSA3NTIzIChhbmQgaW5jbHVkZSBp dHMgdGVzdCB2ZWN0b3JzIG9mIGNvdXJzZSkgIFdvdWxkIHJldmlldy4NCj4gDQo+ICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtyb3ZldHotcmM2LXJjNS12ZWN0b3Jz Lw0KPiANCj4gSSBkb24ndCBzZWUgYSBjb21wZWxsaW5nIG5lZWQgZm9yIHRoaXMsIGJ1dCBJIGFt IG5vdCBzdHJvbmdseSBvcHBvc2VkIGVpdGhlci4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IENmcmcgbWFpbGluZyBsaXN0DQo+IENmcmdA aXJ0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZnJnDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDZnJnIG1h aWxpbmcgbGlzdA0KQ2ZyZ0BpcnRmLm9yZw0KaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jZnJnDQoNCg== From nobody Fri Mar 8 17:11: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 67EEE124B0C; Fri, 8 Mar 2019 17:11:44 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 HqKGkX7LXXqz; Fri, 8 Mar 2019 17:11:40 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 1ADCB1279B1; Fri, 8 Mar 2019 17:11:40 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id w6so18921838ljd.7; Fri, 08 Mar 2019 17:11:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SklxfuhSBYQDEADLWTM2mIuFUYGHLGT9CWlTCCyPn04=; b=aNpV9tvZYGGzW8kQlTSw4nLCzrrckul/Q4zpDAS0Mr0mR+Z4A4TsEMOyylVXwNFhWC a9aI9NSlnojJur3Obx4JvUS6+yfLJFP2qEQz/teeYCHHitEyVktCuSn4u6Hdh3617hZB 8+aoVt98ox5QLm2DvkAZaUu1tAFPYWZTWw4q9SH+NniJmko9Uf4R6RrcHZ3Zqu0EuYXm Z1v+V7bFoX+JHp1q4bhl5BENbsno1dbabE0F6bgzioAMbf9YkJ+AfHWbl3ERBZFKYdQ9 azDeoXoAvPQr1WlKxQulrylzEhidLvaLX1oh3LNDV1HH49DNKmv16jvPs1Lf7QAuVhoN 5MQw== 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=SklxfuhSBYQDEADLWTM2mIuFUYGHLGT9CWlTCCyPn04=; b=i/Ex9BEcagnmLTpL7KkLDj30aqTPrgWwJ/vkNQu4pblY1I+14P5tqhTL0cz/OiZYAZ ulLIGRKDNL3Ala7Pq61Pz2gt7LikZ9xkSigkal6QF+qtlezVjI4YjPFare/d+nptm4Hy TKIW92ply+Dc7J6Fa/BAwSk0XL8Vu1592UQlGNUqiOIYKNiw5GnZ5z+FJfWMILDttNqL fZIlwQWYo4jY/RHuMYhpRhR+3zXyzTc61kDvko3luVUUulCuT4M/wjDmwoMePUPb9fk1 T7PCbBa/YoOpFvF4Xd5i9of/0R7hEa9fslH3KayGlemIpLlu4P+uSDNzpIVRBhQt49g9 NwJg== X-Gm-Message-State: APjAAAXIkxps04815Isoj/rdnqeZ/1Ek7+o2/RbYXvA6e84VRvV30EvD KZhbBm87vcdwfei0xlESt0FuPTsU3NjH7XZheFE= X-Google-Smtp-Source: APXvYqxvP+/btVLy67WtUFsivbwSF67XEqReH/MUcrw4wHDDuIbpN9jG/3T6m030fEuhk9YysF3QjUm1CadJE/D2FuA= X-Received: by 2002:a2e:719:: with SMTP id 25mr10673189ljh.122.1552093898081; Fri, 08 Mar 2019 17:11:38 -0800 (PST) MIME-Version: 1.0 References: <155128908237.14053.17188619727012241844@ietfa.amsl.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Fri, 8 Mar 2019 19:11:27 -0600 Message-ID: To: David Noveck Cc: Sean Turner , secdir@ietf.org, IETF list , NFSv4 , draft-ietf-nfsv4-mv1-msns-update.all@ietf.org Content-Type: multipart/alternative; boundary="0000000000007409b905839f0591" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-nfsv4-mv1-msns-update-04 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 Mar 2019 01:11:44 -0000 --0000000000007409b905839f0591 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, David, On Fri, Mar 8, 2019 at 5:52 PM David Noveck wrote: > I previously said: > > Will address nits 0)-4) and 6)-10) in -05. > > However when I looked more closely at 9), I've found that I cannot make > the requested change. > > > 9) s12.2.3: replace ietf.org with example.org (not supposed to use > > real domains even if it is =E2=80=9Cours=E2=80=9D). > > This is not an example. The use of ietf,org is intentional and is > intended as a way > to provide the ability to define globally usable variable definition as > well as domain-specific > ones. This is specified in section 22.5 of RFC5661. I'm not sure about > the details of > the prohibition of the use of real domain names but I can;t see how it > would apply in this > case where this form of vatibl specification, including a real domain nam= e > has already > been adopted. > Soon, I will not be the IESG Whisperer for this document, but we defined test and documentation domains in https://tools.ietf.org/html/rfc2606, a LONG time ago. If I'm reading https://tools.ietf.org/html/rfc2606#section-2 and https://tools.ietf.org/html/rfc2606#section-3 correctly, the use of .example, or .example.com, is intended to avoid people copying a domain name from documentation that someone is actually using now, or starts or stops using in the future, along with all the possible paths through confusion that could result. ISTM that ietf.org is in use now, so, picking a name that someone starts using later isn't a problem, and if ietf.org stops working or starts referring to the International Egret Trading Federation, we may have bigger problems than this draft not using example.com ... But do the right thing, of course. Spencer > On Thu, Feb 28, 2019 at 8:30 PM David Noveck wrote= : > >> > These >> > instructions will really help when work on a fully revised NFS RFC get= s >> > going. >> >> That's the intention. The working group is now discussing the >> possibility of an rfc5661bis >> that would use those instructions. Note that the current document woul= d >> be the source of >> a large set of the changes but there are also others: The >> internationalization section needs to >> be updated as it was in RFC7530. Section 12 needs to be updated to >> reflect the work done by >> RFC8434. Also, there are a lot of erratta that would need to be applied= . >> >> > 0) The big issue being addressed in the security considerations is the >> fact >> > that RPSEC_GSS is must support not must use >> >> That reflects choices made for RFC3530 and carried over until now. Thi= s >> has resulted in >> a situation in which AUTH_SYS is very commonly used despite its obvious >> security weaknesses. >> >> > So what do you do when RFC 5661 says: >> >> > The fetching of attributes containing file system location >> > information SHOULD be performed using RPCSEC_GSS with integrity >> > protection, >> >> Not much, since there is not much I can do about that. >> >> > And, you don=E2=80=99t now change to MUST use RPSEC_GSS? >> >> No I don't. Currently use of AUTH_SYS is allowed and the working >> group has not made any decision to change that. >> >> > Well I think at a minimum you should do some 2119 language: >> >> OK, but note that this is a widely-deployed protocol and we are not >> in a position to invalidate deployment choices made in line with RFC5661= , >> even if we think they were ill-advised. >> >> > 0) s16 (after the bullets): 2119 this should: >> >> If you are suggesting changing "should" to "SHOULD" in this parapgraph, >> I'm OK with making that change in -05, although I will raise the issue >> with >> the working group to check about existing implemtations. >> >> > 1) s16 (2nd para after the bullets): 2199 this SHOULD NOT: >> >> I intend to shift this to "SHOULD NOT" in -05. >> >> > 2) s16 (last bullet): 2119 this should: >> >> Given that this bullet appears in a summary, I think the "should" is >> misleading. Converting it to "SHOULD" would lead to recommemmending >> filtering without specifying the filtering to be done. What I propose t= o >> do in -05 is replace "should be subect to filtering" by "is made subject= to >> filtering as described above". >> >> > The use of requests issued without RPCSEC_GSS (i.e. using >> > the known to be insecure AUTH_SYS), while undesirable and >> > Insecure, may not be avoidable in all cases. >> >> While I approve of drawing more attention to the weaknesses of >> AUTH_SYS, I feel the use of the word "insecure" is too vague. >> "Insecure" covers a range of problems whereby traffic is either >> exposed to prying eyes, subject to corruption in transit, or acted >> upon without authentiction. Given the context, I think we need to >> be clear about what the actual problem is even though AUTH_SYS, >> in what has to be considered a virtuoso performance :-), manages >> to acomplish the hat trick of protocol insecurity. >> >> So I propose writing this as follows: >> >> The use of requests issued without RPCSEC_GSS (i.e. using AUTH_SYS which >> has no provision to avoid corruption of data in flight), while undesirab= le >> and a potential security exposure, may not be avoidable in all cases. >> >> >> > It=E2=80=99s probably also worth discussing whether s14.3 should drop >> > support for includes id-sha1 >> >> The text you are referring to was carried over from RFC5661 as-is since >> there was no issue known with it. >> >> Regarding the potential deletion of id-sha1, the issue, given that serve= r >> support is currently REQUIRED, is whether there are clients using this w= ho >> might be impacted by a change. I'll check with the working group. >> >> > 4) s4.3 (1st sentence): Not sure the 2119-RECOMMENDED is needed. >> >> These are really OPTIONAL althouh the word "RECOMMENDED" is (confusingly= ) >> used. >> Will delete. >> >> > 5) s4.3 (penultimate para): Seems like r/should/SHOULD. >> >> It is probably the case that RFC5661 made a poor choice here. However, = I >> don't think we can change it now. >> >> > 10) s16 (3rd bullet): Why is requirement is caps? >> >> It's because I was under the misapprehension that statement that things >> were REQUIRED or RECOMMENDED could be referred to as "REQUIREMENTS" or >> "RECOMMENDATIONS". It turns out not to be so. >> >> Will address nits 0)-4) and 6)-10) in -05. >> >> On Wed, Feb 27, 2019 at 12:38 PM Sean Turner wrote: >> >>> Reviewer: Sean Turner >>> Review result: Has Issues >>> >>> This draft updates NFSv4.1 to correct handling of the fs_locations and >>> fs_locations_info attributes; NFSv4.1 weighs in at 617 pages and this >>> draft weighs in a relatively spry 106; let=E2=80=99s say I was really, = really >>> hoping >>> for some multi-page ASCII art, but also no pretty much all text. The >>> draft does a good job of explaining what=E2=80=99s being replaced and w= hy, but >>> I have to say that I did not check all of section pointers. These >>> instructions will really help when work on a fully revised NFS RFC gets >>> going. Unfortunately for me, I do not have NFSv4.1 in my head so let= =E2=80=99s >>> just say that I did my best =E2=80=A6 >>> >>> Summary: This draft is probably worthy of some type of DISCUSS based >>> on the following: >>> >>> 0) The big issue being addressed in the security considerations is the >>> fact >>> that RPSEC_GSS is must support not must use and the other mechanism >>> referred to by RFC 5661 are: >>> >>> - AUTH_NONE - nada authentication >>> >>> - AUTH_SYS as described in Appendix A is known to be insecure due to >>> the lack of a verifier to permit the credential to be validated. >>> AUTH_SYS SHOULD NOT be used for services that permit clients to >>> modify data. AUTH_SYS MUST NOT be specified as RECOMMENDED or >>> REQUIRED for any Standards Track RPC service. >>> >>> - AUTH_DH as mentioned in Sections 8.2 and 13.4.2 is considered >>> obsolete and insecure; see [RFC2695]. AUTH_DH SHOULD NOT be used fo= r >>> services that permit clients to modify data. AUTH_DH MUST NOT be >>> specified as RECOMMENDED or REQUIRED for any Standards Track RPC >>> service. >>> >>> So what do you do when RFC 5661 says: >>> The fetching of attributes containing file system location >>> information SHOULD be performed using RPCSEC_GSS with integrity >>> protection, >>> And, you don=E2=80=99t now change to MUST use RPSEC_GSS? Well I think = at a >>> minimum you should do some 2119 language: >>> >>> 0) s16 (after the bullets): 2119 this should: >>> >>> In light of the above, a server should present file system >>> location entries that correspond to file systems on other servers >>> using a host name. >>> >>> 1) s16 (2nd para after the bullets): 2199 this SHOULD NOT: >>> >>> As a >>> result, the client should not use such unverified location entries >>> as a basis for migration, even though RPCSEC_GSS might be >>> available on the destination. >>> >>> 2) s16 (last bullet): 2119 this should: >>> >>> Where the use of the returned information cannot be >>> avoided, it should be subject to filtering to eliminate the >>> possibility that the client would treat an invalid address as >>> if it were a NFSv4 server. >>> >>> And, I guess since AUTH_SYS is insecure can I suggest a friendly >>> amendment to the following sentence: >>> >>> OLD: >>> The use of requests issued without RPCSEC_GSS (i.e. using >>> AUTH_SYS), while undesirable, may not be avoidable in all >>> cases. >>> >>> NEW: >>> >>> The use of requests issued without RPCSEC_GSS (i.e. using >>> the known to be insecure AUTH_SYS), while undesirable and >>> Insecure, may not be avoidable in all cases. >>> >>> It=E2=80=99s probably also worth discussing whether s14.3 should drop >>> support for includes id-sha1. >>> >>> >>> These are the nits: >>> >>> 0) Update to use new 2119 paragraph: >>> >>> 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. >>> >>> 1) s3.1 (wordy): r/since the >>> ports to be used for various types of connections might be >>> required to be different/since the >>> ports to be used for various types of connections might be >>> different. >>> >>> 2) s3.1 (missing period): r/Two such addresses support the use of >>> clientid >>> ID trunking, as described in [RFC5661]/Two such addresses support the >>> use of clientid >>> ID trunking, as described in [RFC5661]. >>> >>> 3) s4.2 (missing word): r/which may accessed/which may be accessed >>> >>> 4) s4.3 (1st sentence): Not sure the 2119-RECOMMENDED is needed. >>> >>> 5) s4.3 (penultimate para): Seems like r/should/SHOULD. >>> >>> 6) s4.5: r/present , is/present, is >>> >>> 7) s4.5: Note sure you need the parenthetical in the following: >>> a server may (but is not required to) >>> >>> 8) s4.5.4: r/In the event that server failures,/In the event that >>> server fails, >>> or >>> r/In the event that server failures,/In the event of server failures, >>> >>> 9) s12.2.3: replace ietf.org with example.org (not supposed to use >>> real domains even if it is =E2=80=9Cours=E2=80=9D). >>> >>> 10) s16 (3rd bullet): Why is requirement is caps? >>> >>> --0000000000007409b905839f0591 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, David,=C2=A0

On Fri, Mar 8, 2019 at 5:52 PM David Noveck <<= a href=3D"mailto:davenoveck@gmail.com">davenoveck@gmail.com> wrote:<= br>
I previously said:
> Will address nits 0)-4) and 6)-10) in -05.

However when I looked more closely at 9), I've fo= und that I cannot make the requested change.

> = 9) s12.2.3: replace=C2=A0ietf.org=C2=A0with=C2=A0example.org=C2=A0(not supposed to= use
> real domains even if it is =E2=80=9Cours=E2=80=9D).
=
This is not an example.=C2=A0 =C2=A0The use of ietf,org is i= ntentional and is intended as a way
to provide the ability to def= ine globally usable variable definition as well as domain-specific
ones.=C2=A0 This is specified in section 22.5 of RFC5661.=C2=A0 =C2=A0I&#= 39;m not sure about the details of
the prohibition of the use of = real domain names but I can;t see how it would apply in this
case= where this form of vatibl specification, including a real domain name has = already
been adopted.=C2=A0 =C2=A0=C2=A0
=

Soon, I will not be the IESG Whisperer for this documen= t, but we defined test and documentation domains in=C2=A0https://tools.ietf.org/html/rfc2606, a LO= NG time=C2=A0ago. If I'm reading=C2=A0https://tools.ietf.org/html/rfc2606#section-2 = and=C2=A0https://= tools.ietf.org/html/rfc2606#section-3 correctly, the use of .example, o= r .example.com, is intended to avoid peo= ple copying a domain name from documentation that someone is actually using= now, or starts or stops using in the future, along with all the possible p= aths through confusion that could result.=C2=A0

IS= TM that ietf.org is in use now, so, picking= a name that someone starts using later isn't a problem, and if ietf.org stops working or starts referring to the = International Egret Trading Federation, we may have bigger problems than th= is draft not using example.com ...
=

But do the right thing, of course.=C2=A0

=
Spencer
=C2=A0
On Thu, Feb 28, 2019 at 8:30 PM David Nove= ck <davenoveck= @gmail.com> wrote:
> These
> in= structions will really help when work on a fully revised NFS RFC gets
&g= t; going.

That's the intention.=C2=A0 The working gr= oup is now discussing the possibility of an rfc5661bis
that would= use those instructions.=C2=A0 =C2=A0Note that the current document would b= e the source of
a large set of the changes but there are also oth= ers: The internationalization section needs to
be updated as it w= as in RFC7530.=C2=A0 Section 12 needs to be updated to reflect the work don= e by=C2=A0
RFC8434.=C2=A0 Also, there are a lot of erratta that w= ould need to be applied.

> 0) The big issue bei= ng addressed in the security considerations is the fact
> that RPSEC_= GSS is must support not must use

That reflects cho= ices made for RFC3530 and carried over until now.=C2=A0 =C2=A0This has resu= lted in
a situation in which AUTH_SYS is very commonly used despi= te its obvious security weaknesses.

> So what d= o you do when RFC 5661 says:

>=C2=A0 The fetching of attri= butes containing file system location
>=C2=A0 information SHOULD be p= erformed using RPCSEC_GSS with integrity
>=C2=A0 protection,

Not much, since there is not much I can do about that.

> And, you don=E2=80=99t now change to MUST use RPSEC_GSS?=C2= =A0

No I don't.=C2=A0 =C2=A0Currently use of A= UTH_SYS is allowed and the working
group has not made any decisio= n to change that.=C2=A0 =C2=A0=C2=A0

> Well I t= hink at a minimum you should do some 2119 language:

OK, but note that this is a widely-deployed protocol and we are not
=
in a position to invalidate deployment choices made in line with RFC56= 61,
even if we think they were ill-advised.

<= div>> 0) s16 (after the bullets): 2119 this should:

=
If you are suggesting changing "should" to "SHOULD"= ; in this parapgraph,
I'm OK with making that change in -05, = although I will raise the issue with
the working group to che= ck about existing implemtations.

> 1) s16 (2nd = para after the bullets): 2199 this SHOULD NOT:=C2=A0=C2=A0
I intend to shift this to "SHOULD NOT"=C2=A0 in -05.=

> 2) s16 (last bullet): 2119 this should:
<= /div>

Given that this bullet appears in a summary, I thi= nk the "should" is misleading.=C2=A0 =C2=A0Converting it to "= ;SHOULD" would lead to recommemmending filtering without specifying th= e filtering to be done.=C2=A0 What I propose to do in -05 is replace "= should be subect to filtering" by "is made subject to filtering a= s described above".

> The use of requests = issued without RPCSEC_GSS (i.e. using
>=C2=A0 the known to be insecur= e AUTH_SYS), while undesirable and
>=C2=A0 Insecure, may not be avoid= able in all cases.=C2=A0=C2=A0

While I approve= of drawing more attention to the weaknesses of=C2=A0
AUTH_SYS, I= feel the use of the word "insecure" is too vague.=C2=A0 =C2=A0
"Insecure" covers a range of problems whereby traffic is= either=C2=A0
exposed to prying eyes, subject to corruption in tr= ansit, or acted=C2=A0
upon without authentiction.=C2=A0 =C2=A0Giv= en the context, I think we need to=C2=A0
be clear about what the = actual problem is even though AUTH_SYS,=C2=A0
in what has to be c= onsidered a virtuoso performance :-), manages=C2=A0
to acomplish = the hat trick of protocol insecurity.

So I propose= writing this as follows:

The use of requests issu= ed without RPCSEC_GSS (i.e. using AUTH_SYS which has no provision to avoid = corruption of data in flight), while undesirable and a potential security e= xposure, may not be avoidable in all cases.=C2=A0=C2=A0=C2=A0

> It=E2=80=99s probably also worth d= iscussing whether s14.3 should drop
> support for includes id-s= ha1

The text you are referring to was carried over= from RFC5661 as-is since there was no issue known with it.

<= /div>
Regarding the potential deletion of id-sha1, the issue, given tha= t server support is currently REQUIRED, is whether there are clients using = this who might be impacted by a change.=C2=A0 =C2=A0I'll check with the= working group.

> 4) s4.3 (1st sentence): Not s= ure the 2119-RECOMMENDED is needed.

These are real= ly OPTIONAL althouh the word "RECOMMENDED" is (confusingly) used.=
Will delete.

> 5) s4.3 (penultimate = para): Seems like r/should/SHOULD.

It is probably = the case that RFC5661 made a poor choice here.=C2=A0 However, I don't t= hink we can change it now.

> 10) s16 (3rd = bullet): Why is requirement is caps?=C2=A0

It'= s because I was under the misapprehension that statement that things were R= EQUIRED or RECOMMENDED could be referred to as "REQUIREMENTS" or = "RECOMMENDATIONS".=C2=A0 It turns out not to be so.=C2=A0
=C2=A0=C2=A0
Will address nits 0)-4) and 6)-10) in -= 05.

On Wed, Feb 27, 2019 at 12:38 PM Sean Turner <sean@sn3rd.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Reviewer: Sean Turner
Review result: Has Issues

This draft updates NFSv4.1 to correct handling of the fs_locations and
fs_locations_info attributes; NFSv4.1 weighs in at 617 pages and this
draft weighs in a relatively spry 106; let=E2=80=99s say I was really, real= ly hoping
for some multi-page ASCII art, but also no pretty much all text.=C2=A0 The<= br> draft does a good job of explaining what=E2=80=99s being replaced and why, = but
I have to say that I did not check all of section pointers.=C2=A0 These
instructions will really help when work on a fully revised NFS RFC gets
going.=C2=A0 Unfortunately for me, I do not have NFSv4.1 in my head so let= =E2=80=99s
just say that I did my best =E2=80=A6

Summary: This draft is probably worthy of some type of DISCUSS based
on the following:

0) The big issue being addressed in the security considerations is the fact=
that RPSEC_GSS is must support not must use and the other mechanism
referred to by RFC 5661 are:

- AUTH_NONE - nada authentication

- AUTH_SYS as described in Appendix A is known to be insecure due to
=C2=A0 =C2=A0the lack of a verifier to permit the credential to be validate= d.
=C2=A0 =C2=A0AUTH_SYS SHOULD NOT be used for services that permit clients t= o
=C2=A0 =C2=A0modify data.=C2=A0 AUTH_SYS MUST NOT be specified as RECOMMEND= ED or
=C2=A0 =C2=A0REQUIRED for any Standards Track RPC service.

- AUTH_DH as mentioned in Sections 8.2 and 13.4.2 is considered
=C2=A0 =C2=A0obsolete and insecure; see [RFC2695].=C2=A0 AUTH_DH SHOULD NOT= be used for
=C2=A0 =C2=A0services that permit clients to modify data.=C2=A0 AUTH_DH MUS= T NOT be
=C2=A0 =C2=A0specified as RECOMMENDED or REQUIRED for any Standards Track R= PC
=C2=A0 =C2=A0service.

So what do you do when RFC 5661 says:
=C2=A0 The fetching of attributes containing file system location
=C2=A0 information SHOULD be performed using RPCSEC_GSS with integrity
=C2=A0 protection,
And, you don=E2=80=99t now change to MUST use RPSEC_GSS?=C2=A0 Well I think= at a
minimum you should do some 2119 language:

0) s16 (after the bullets): 2119 this should:

=C2=A0 In light of the above, a server should present file system
=C2=A0 location entries that correspond to file systems on other servers =C2=A0 using a host name.

1) s16 (2nd para after the bullets): 2199 this SHOULD NOT:

=C2=A0 =C2=A0As a
=C2=A0 =C2=A0result, the client should not use such unverified location ent= ries
=C2=A0 =C2=A0as a basis for migration, even though RPCSEC_GSS might be
=C2=A0 =C2=A0available on the destination.

2) s16 (last bullet): 2119 this should:

=C2=A0 Where the use of the returned information cannot be
=C2=A0 avoided, it should be subject to filtering to eliminate the
=C2=A0 possibility that the client would treat an invalid address as
=C2=A0 if it were a NFSv4 server.

And, I guess since AUTH_SYS is insecure can I suggest a friendly
amendment to the following sentence:

OLD:=E2=80=A8
=C2=A0 The use of requests issued without RPCSEC_GSS (i.e. using
=C2=A0 AUTH_SYS), while undesirable, may not be avoidable in all
=C2=A0 cases.

NEW:

=C2=A0 The use of requests issued without RPCSEC_GSS (i.e. using
=C2=A0 the known to be insecure AUTH_SYS), while undesirable and
=C2=A0 Insecure, may not be avoidable in all cases.

It=E2=80=99s probably also worth discussing whether s14.3 should drop
support for includes id-sha1.


These are the nits:

0) Update to use new 2119 paragraph:

=C2=A0 The key words "MUST", "MUST NOT", "REQUIRED= ", "SHALL", "SHALL NOT",
=C2=A0 "SHOULD", "SHOULD NOT", "RECOMMENDED",= "NOT RECOMMENDED", "MAY", and
=C2=A0 "OPTIONAL" in this document are to be interpreted as descr= ibed in BCP
=C2=A0 14 [RFC2119] [RFC8174] when, and only when, they appear in all
=C2=A0 capitals, as shown here.

1) s3.1 (wordy): r/since the
=C2=A0 ports to be used for various types of connections might be
=C2=A0 required to be different/since the
=C2=A0 ports to be used for various types of connections might be
=C2=A0 different.

2) s3.1 (missing period): r/Two such addresses support the use of clientid<= br> =C2=A0 ID trunking, as described in [RFC5661]/Two such addresses support th= e use of clientid
=C2=A0 ID trunking, as described in [RFC5661].

3) s4.2 (missing word): r/which may accessed/which may be accessed

4) s4.3 (1st sentence): Not sure the 2119-RECOMMENDED is needed.

5) s4.3 (penultimate para): Seems like r/should/SHOULD.

6) s4.5: r/present , is/present, is

7) s4.5: Note sure you need the parenthetical in the following:
=C2=A0 a server may (but is not required to)

8) s4.5.4: r/In the event that server failures,/In the event that
server fails,
or
r/In the event that server failures,/In the event of server failures,

9) s12.2.3: replace ietf.org with example.org (not supposed to use
real domains even if it is =E2=80=9Cours=E2=80=9D).

10) s16 (3rd bullet): Why is requirement is caps?

--0000000000007409b905839f0591-- From nobody Fri Mar 8 17:32:58 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 50B39126C15; Fri, 8 Mar 2019 17:32:51 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 l-Ts7rDBWioP; Fri, 8 Mar 2019 17:32:48 -0800 (PST) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (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 AC40D1274D0; Fri, 8 Mar 2019 17:32:48 -0800 (PST) Received: by mail-oi1-x22b.google.com with SMTP id i8so17366465oib.10; Fri, 08 Mar 2019 17:32:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BkO5y5lK0mJBl7dd4GfnbdGRtMeH2Xf/02HDz6r2WmI=; b=ITO8cUjmJI+5a9Zr2vDP2HBWOFO/+65BE35kjYbJYXNffxhCggNEpQ8NZ9Y8vxwdAb pMQ0Au5KVSBPwEeYQr95we2Ce3neiQHkMPE0GuBF/SVPRxpkonnFLidmBqgkBHlclhFb VyUAIHRV3+X++rOeEEXjqlW9JnsKxWd+m8zduJnYttltL5B4NCuMyj/rvaqJB7UCkKlL FfCTtpHBenymm3w7iHaXoY6cnC6gulSkXRn9/dNMXtOBYO64T6N6JAbycmpP8yRJptvK /WPrjbWsN/5aY/yBY/TY5zqdnqHgWtUx4ooQxRI4qQNVZMxnWiPHLS2klkOZT0Jfl1tv uijA== 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=BkO5y5lK0mJBl7dd4GfnbdGRtMeH2Xf/02HDz6r2WmI=; b=FORj0RocYrAxnxe+OzRCGbpFaTeWXrVPZmesy0zpaHFtynl+zxMzRZgeqkvjAXPBUv Xhkf9huNVJ7SqvwI8kcATe1fAfvUyZ8M7FAHz2W2lnDLBmSbocxgupwoAnfhmOgn8Y9v SH2r0IUOGtuPFXLrf1tAv3zSxUM5Nc1LsjSYYuRPY9TMvXJVEkkk5ALu8VlxfD3MBVrX p8fRe+fzb6dLVbDeNzA/RE9OdcrElyeVQxGf5ujso4kslVuyjGpEtLD4CVgSZrJS+A9c A22bLeZpyLHd+TnwRVMPHJtA1A77bG8KQx1siZrgWmsmUTR+5unC07LXsxCJd9uMSwex ta6A== X-Gm-Message-State: APjAAAUpnNi/4d/zDAXVr8h1Tj7MP7Yd/C2g8WWujCUvDg6mP5BNjrcx YYJ2hCNnD3Ulp1zfTYLY9+ygeT7O8TVaiPTEzhw= X-Google-Smtp-Source: APXvYqx9++hl7UI62rzY9neTgKiHs5e/ZCchl8mrst9wmRS0qaOnKIfH6sPZPbYs8ZJ32Uj7Cz56bBowuKtkmoynTAY= X-Received: by 2002:aca:59d7:: with SMTP id n206mr10260368oib.26.1552095167734; Fri, 08 Mar 2019 17:32:47 -0800 (PST) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> In-Reply-To: From: Tony Arcieri Date: Fri, 8 Mar 2019 17:32:36 -0800 Message-ID: To: John Mattsson Cc: David Wong , "Salz, Rich" , "sec-ads@ietf.org" , "cfrg@irtf.org" , "rfc-ise@rfc-editor.org" , "secdir@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002169cc05839f5173" Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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 Mar 2019 01:32:51 -0000 --0000000000002169cc05839f5173 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Given this, and perhaps temporarily suspending discussion of the Jutla and Grigor patents, I'm curious what kind of IPR statement would be needed from Rogaway to alleviate concerns about his specific patents. On Fri, Mar 8, 2019 at 4:11 PM John Mattsson wrote: > Given that CFRG has already published OCB3 in RFC 7253, which was recentl= y > included in the CEASAR final portfolio, I would like to see the OCB3 > wideblock draft published somewhere. I agree with Rich that it would be > better to replace RFC 7523. > > Reading RFC 7523 again, it does not feel optimal that the two slightly > different modes defined in RFC 7523 and the FSE 2011 paper are both calle= d > OCB3. > > The OCB wideblock document seems to meet the requirements in RFC 4846. > > /John > > =EF=BB=BF-----Original Message----- > From: Cfrg on behalf of David Wong < > davidwong.crypto@gmail.com> > Date: Friday, 8 March 2019 at 19:11 > To: "Salz, Rich" > Cc: "sec-ads@ietf.org" , "cfrg@irtf.org" , > "rfc-ise@rfc-editor.org" , "secdir@ietf.org" < > secdir@ietf.org> > Subject: Re: [Cfrg] ISE seeks help with some crypto drafts > > Note that OCB was chose as a finalist in the CAESAR competition. Knowing > that, it sounds like a good idea to standardize it. > > On the other hand, if I understand correctly you need to pay a one-time > fee to use the algorithm in a commercial product? I think that=E2=80=99s = a big > no-no considering we want everybody to use good open source libraries. > > David > > > On Mar 8, 2019, at 9:56 AM, Salz, Rich wrote: > > > > https://datatracker.ietf.org/doc/draft-krovetz-ocb-wideblock/ > > > > I would rather see this rewritten to completely replace 7523 (and > include its test vectors of course) Would review. > > > > https://datatracker.ietf.org/doc/draft-krovetz-rc6-rc5-vectors/ > > > > I don't see a compelling need for this, but I am not strongly opposed > either. > > > > _______________________________________________ > > Cfrg mailing list > > Cfrg@irtf.org > > https://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --=20 Tony Arcieri --0000000000002169cc05839f5173 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Given this, and perhaps temporarily suspending discus= sion of the Jutla and Grigor patents, I'm curious what kind of IPR stat= ement would be needed from Rogaway to alleviate concerns about his specific= patents.

On Fri, Mar 8, 2019 at 4:11 PM John Mattsson <john.mattsson@ericsson.com> wrote:
<= /div>
Given that CFRG has = already published OCB3 in RFC 7253, which was recently included in the CEAS= AR final portfolio, I would like to see the OCB3 wideblock draft published = somewhere. I agree with Rich that it would be better to replace RFC 7523.
Reading RFC 7523 again, it does not feel optimal that the two slightly diff= erent modes defined in RFC 7523 and the FSE 2011 paper are both called OCB3= .

The OCB wideblock document seems to meet the requirements in RFC 4846.

/John

=EF=BB=BF-----Original Message-----
From: Cfrg <c= frg-bounces@irtf.org> on behalf of David Wong <davidwong.crypto@gmail.com>
Date: Friday, 8 March 2019 at 19:11
To: "Salz, Rich" <rsalz@akamai.com>
Cc: "sec-ads@iet= f.org" <s= ec-ads@ietf.org>, "cfrg@irtf.org" <cfrg@irtf.org>, "rfc-ise@rfc-editor.org" <rfc-ise@rfc-editor.org&= gt;, "secdir@ietf= .org" <sec= dir@ietf.org>
Subject: Re: [Cfrg] ISE seeks help with some crypto drafts

Note that OCB was chose as a finalist in the CAESAR competition. Knowing th= at, it sounds like a good idea to standardize it.

On the other hand, if I understand correctly you need to pay a one-time fee= to use the algorithm in a commercial product? I think that=E2=80=99s a big= no-no considering we want everybody to use good open source libraries.

David

> On Mar 8, 2019, at 9:56 AM, Salz, Rich <rsalz@akamai.com> wrote:
>
>=C2=A0 =C2=A0 https://datatracker.i= etf.org/doc/draft-krovetz-ocb-wideblock/
>
> I would rather see this rewritten to completely replace 7523 (and incl= ude its test vectors of course)=C2=A0 Would review.
>
>=C2=A0 =C2=A0 https://datatracker= .ietf.org/doc/draft-krovetz-rc6-rc5-vectors/
>
> I don't see a compelling need for this, but I am not strongly oppo= sed either.
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg


--
Tony Arcieri
--0000000000002169cc05839f5173-- From nobody Fri Mar 8 17:38:23 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 5F4C11274D0; Fri, 8 Mar 2019 17:37: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 k-KGQ4bSeG9V; Fri, 8 Mar 2019 17:37:34 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 67924126C15; Fri, 8 Mar 2019 17:37:34 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id h8so15484428pgp.6; Fri, 08 Mar 2019 17:37:34 -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-language:content-transfer-encoding; bh=RbBsuFG9cS51hZ2NDcjZ75YUZ/YhWT76190VcvX7MFU=; b=uxWdqQHI8DIGfYNwuMc+u9O5X5ImgCLisFZeeamOaE8NCO+ftJKPf5XbwJwuh+pU7u C1+8VU8bgWLtRkwcq9RdZBOvFmgzMF+Su886pqA+Ez6Z1X26EvZxLEJryA5iRlN+wicg XxpVcGTM7b6MZw/fiFH+mpuMy48Yi70d+iIAZOsbB5QKU/7aiY6NZYgAr+Z/7Wh6Cmos S0P/2vrxWLowD0MkFn7KcywdeYCskQORcz03WT0N2DkyyqDd0Dg+n4aU8B2s7+Z6zS/t bKBxoFrigpkpoDG18u+0fv98zp18G35k37tRFtAvmVYfF21yjZ0jdIeIy+MAGmSK97dY SodQ== 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-language :content-transfer-encoding; bh=RbBsuFG9cS51hZ2NDcjZ75YUZ/YhWT76190VcvX7MFU=; b=kSrh+Ojbc3GWymGFyEmZ7WoOmBjC0RafJDWQJkXEUHItQJZsGd/2UoZWuqaHL2h7+8 ZmyOvBB3d9kRUAmyUcdqQ8U/QkrioCQg1SkxHtcbkegs2PdCzhiDzVEC1IZg7M1sP/Zx 6wPl7nEoxv/kdEu16dRiQeNnuIaMyPurdF8DHr/A9PARjcf3oly2VUvex4FAXdVU83wv 475CATwdEPy1jBnlCgLmnbeGhGUHUasxJ4qJ73nnWmWBlZW2SQdShUAIO2WYweKRIkBh taxjGtdP+Gyon8coyn6a7XRRNlLZa++joWdj1LBcKUJRFwMxqZ3ov055uvqmmfjfaEhm 7aJw== X-Gm-Message-State: APjAAAUGFpcT9876Hzx1+kMAszXM/GN4gav5IrKZiOanNP4PgHYWTa00 x3ZXwOISaeZPILkokAiwsjjabSPv X-Google-Smtp-Source: APXvYqxHTvAysb7kUHA4AnrOTVff5uMgg4MK2Ys2TLAxUpwYsGe1Y7xxwq1u/8JRrs4k1d5ap4p8Og== X-Received: by 2002:a65:438a:: with SMTP id m10mr19542979pgp.191.1552095453388; Fri, 08 Mar 2019 17:37:33 -0800 (PST) Received: from [192.168.178.30] (211.231.69.111.dynamic.snap.net.nz. [111.69.231.211]) by smtp.gmail.com with ESMTPSA id h6sm488759pgn.59.2019.03.08.17.37.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Mar 2019 17:37:32 -0800 (PST) To: Spencer Dawkins at IETF , David Noveck Cc: draft-ietf-nfsv4-mv1-msns-update.all@ietf.org, NFSv4 , IESG , secdir@ietf.org References: <155128908237.14053.17188619727012241844@ietfa.amsl.com> From: Brian E Carpenter Message-ID: Date: Sat, 9 Mar 2019 14:37:28 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-nfsv4-mv1-msns-update-04 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 Mar 2019 01:37:37 -0000 (reducing the CCs by several thousand) In line... On 09-Mar-19 14:11, Spencer Dawkins at IETF wrote: > Hi, David, >=20 > On Fri, Mar 8, 2019 at 5:52 PM David Noveck wrot= e: >=20 >> I previously said: >>> Will address nits 0)-4) and 6)-10) in -05. >> >> However when I looked more closely at 9), I've found that I cannot mak= e >> the requested change. >> >>> 9) s12.2.3: replace ietf.org with example.org (not supposed to use >>> real domains even if it is =E2=80=9Cours=E2=80=9D). >> >> This is not an example. The use of ietf,org is intentional and is >> intended as a way >> to provide the ability to define globally usable variable definition a= s >> well as domain-specific >> ones. This is specified in section 22.5 of RFC5661. I'm not sure ab= out >> the details of >> the prohibition of the use of real domain names but I can;t see how it= >> would apply in this >> case where this form of vatibl specification, including a real domain = name >> has already >> been adopted. >> >=20 > Soon, I will not be the IESG Whisperer for this document, but we define= d > test and documentation domains in https://tools.ietf.org/html/rfc2606, = a > LONG time ago. If I'm reading https://tools.ietf.org/html/rfc2606#secti= on-2 > and https://tools.ietf.org/html/rfc2606#section-3 correctly, the use of= > ..example, or .example.com, is intended to avoid people copying a domai= n > name from documentation that someone is actually using now, or starts o= r > stops using in the future, along with all the possible paths through > confusion that could result. >=20 > ISTM that ietf.org is in use now, so, picking a name that someone start= s > using later isn't a problem, and if ietf.org stops working or starts > referring to the International Egret Trading Federation, we may have bi= gger > problems than this draft not using example.com ... >=20 > But do the right thing, of course. I'm commenting only because I spent a little time with this draft as Gen-= ART reviewer. Of course this draft can't change the domain name used in RFC5661 for the= same purpose, which is already embedded in the IANA registry: https://www.iana.org/assignments/nfsv4-path-variables/nfsv4-path-variable= s.xhtml It isn't used for documentation; I think it's used to provide uniqueness = in a naming structure. You could possibly argue that would be better done usin= g something in .arpa (like IN-ADDR.ARPA and IP6.ARPA) but you'd have needed to argue = that about ten years ago. So the right thing to do in this case is nothing ;-) Unintended side effect: such use of ietf.org ought to trigger the additio= n of ietf.org to the "technical" assignments referred to in note (a) on clause 4.3 of https://tools.ietf.org/html/rfc2860. Which incidentally mea= ns that our domain name is pretty well protected. Brian >=20 > Spencer >=20 >=20 >> On Thu, Feb 28, 2019 at 8:30 PM David Noveck wr= ote: >> >>>> These >>>> instructions will really help when work on a fully revised NFS RFC g= ets >>>> going. >>> >>> That's the intention. The working group is now discussing the >>> possibility of an rfc5661bis >>> that would use those instructions. Note that the current document w= ould >>> be the source of >>> a large set of the changes but there are also others: The >>> internationalization section needs to >>> be updated as it was in RFC7530. Section 12 needs to be updated to >>> reflect the work done by >>> RFC8434. Also, there are a lot of erratta that would need to be appl= ied.. >>> >>>> 0) The big issue being addressed in the security considerations is t= he >>> fact >>>> that RPSEC_GSS is must support not must use >>> >>> That reflects choices made for RFC3530 and carried over until now. = This >>> has resulted in >>> a situation in which AUTH_SYS is very commonly used despite its obvio= us >>> security weaknesses. >>> >>>> So what do you do when RFC 5661 says: >>> >>>> The fetching of attributes containing file system location >>>> information SHOULD be performed using RPCSEC_GSS with integrity >>>> protection, >>> >>> Not much, since there is not much I can do about that. >>> >>>> And, you don=E2=80=99t now change to MUST use RPSEC_GSS? >>> >>> No I don't. Currently use of AUTH_SYS is allowed and the working >>> group has not made any decision to change that. >>> >>>> Well I think at a minimum you should do some 2119 language: >>> >>> OK, but note that this is a widely-deployed protocol and we are not >>> in a position to invalidate deployment choices made in line with RFC5= 661, >>> even if we think they were ill-advised. >>> >>>> 0) s16 (after the bullets): 2119 this should: >>> >>> If you are suggesting changing "should" to "SHOULD" in this parapgrap= h, >>> I'm OK with making that change in -05, although I will raise the issu= e >>> with >>> the working group to check about existing implemtations. >>> >>>> 1) s16 (2nd para after the bullets): 2199 this SHOULD NOT: >>> >>> I intend to shift this to "SHOULD NOT" in -05. >>> >>>> 2) s16 (last bullet): 2119 this should: >>> >>> Given that this bullet appears in a summary, I think the "should" is >>> misleading. Converting it to "SHOULD" would lead to recommemmending= >>> filtering without specifying the filtering to be done. What I propos= e to >>> do in -05 is replace "should be subect to filtering" by "is made subj= ect to >>> filtering as described above". >>> >>>> The use of requests issued without RPCSEC_GSS (i.e. using >>>> the known to be insecure AUTH_SYS), while undesirable and >>>> Insecure, may not be avoidable in all cases. >>> >>> While I approve of drawing more attention to the weaknesses of >>> AUTH_SYS, I feel the use of the word "insecure" is too vague. >>> "Insecure" covers a range of problems whereby traffic is either >>> exposed to prying eyes, subject to corruption in transit, or acted >>> upon without authentiction. Given the context, I think we need to >>> be clear about what the actual problem is even though AUTH_SYS, >>> in what has to be considered a virtuoso performance :-), manages >>> to acomplish the hat trick of protocol insecurity. >>> >>> So I propose writing this as follows: >>> >>> The use of requests issued without RPCSEC_GSS (i.e. using AUTH_SYS wh= ich >>> has no provision to avoid corruption of data in flight), while undesi= rable >>> and a potential security exposure, may not be avoidable in all cases.= >>> >>> >>>> It=E2=80=99s probably also worth discussing whether s14.3 should dro= p >>>> support for includes id-sha1 >>> >>> The text you are referring to was carried over from RFC5661 as-is sin= ce >>> there was no issue known with it. >>> >>> Regarding the potential deletion of id-sha1, the issue, given that se= rver >>> support is currently REQUIRED, is whether there are clients using thi= s who >>> might be impacted by a change. I'll check with the working group. >>> >>>> 4) s4.3 (1st sentence): Not sure the 2119-RECOMMENDED is needed. >>> >>> These are really OPTIONAL althouh the word "RECOMMENDED" is (confusin= gly) >>> used. >>> Will delete. >>> >>>> 5) s4.3 (penultimate para): Seems like r/should/SHOULD. >>> >>> It is probably the case that RFC5661 made a poor choice here. Howeve= r, I >>> don't think we can change it now. >>> >>>> 10) s16 (3rd bullet): Why is requirement is caps? >>> >>> It's because I was under the misapprehension that statement that thin= gs >>> were REQUIRED or RECOMMENDED could be referred to as "REQUIREMENTS" o= r >>> "RECOMMENDATIONS". It turns out not to be so. >>> >>> Will address nits 0)-4) and 6)-10) in -05. >>> >>> On Wed, Feb 27, 2019 at 12:38 PM Sean Turner wrote: >>> >>>> Reviewer: Sean Turner >>>> Review result: Has Issues >>>> >>>> This draft updates NFSv4.1 to correct handling of the fs_locations a= nd >>>> fs_locations_info attributes; NFSv4.1 weighs in at 617 pages and thi= s >>>> draft weighs in a relatively spry 106; let=E2=80=99s say I was reall= y, really >>>> hoping >>>> for some multi-page ASCII art, but also no pretty much all text. Th= e >>>> draft does a good job of explaining what=E2=80=99s being replaced an= d why, but >>>> I have to say that I did not check all of section pointers. These >>>> instructions will really help when work on a fully revised NFS RFC g= ets >>>> going. Unfortunately for me, I do not have NFSv4.1 in my head so le= t=E2=80=99s >>>> just say that I did my best =E2=80=A6 >>>> >>>> Summary: This draft is probably worthy of some type of DISCUSS based= >>>> on the following: >>>> >>>> 0) The big issue being addressed in the security considerations is t= he >>>> fact >>>> that RPSEC_GSS is must support not must use and the other mechanism >>>> referred to by RFC 5661 are: >>>> >>>> - AUTH_NONE - nada authentication >>>> >>>> - AUTH_SYS as described in Appendix A is known to be insecure due to= >>>> the lack of a verifier to permit the credential to be validated. >>>> AUTH_SYS SHOULD NOT be used for services that permit clients to >>>> modify data. AUTH_SYS MUST NOT be specified as RECOMMENDED or >>>> REQUIRED for any Standards Track RPC service. >>>> >>>> - AUTH_DH as mentioned in Sections 8.2 and 13.4.2 is considered >>>> obsolete and insecure; see [RFC2695]. AUTH_DH SHOULD NOT be used= for >>>> services that permit clients to modify data. AUTH_DH MUST NOT be= >>>> specified as RECOMMENDED or REQUIRED for any Standards Track RPC >>>> service. >>>> >>>> So what do you do when RFC 5661 says: >>>> The fetching of attributes containing file system location >>>> information SHOULD be performed using RPCSEC_GSS with integrity >>>> protection, >>>> And, you don=E2=80=99t now change to MUST use RPSEC_GSS? Well I thi= nk at a >>>> minimum you should do some 2119 language: >>>> >>>> 0) s16 (after the bullets): 2119 this should: >>>> >>>> In light of the above, a server should present file system >>>> location entries that correspond to file systems on other servers >>>> using a host name. >>>> >>>> 1) s16 (2nd para after the bullets): 2199 this SHOULD NOT: >>>> >>>> As a >>>> result, the client should not use such unverified location entrie= s >>>> as a basis for migration, even though RPCSEC_GSS might be >>>> available on the destination. >>>> >>>> 2) s16 (last bullet): 2119 this should: >>>> >>>> Where the use of the returned information cannot be >>>> avoided, it should be subject to filtering to eliminate the >>>> possibility that the client would treat an invalid address as >>>> if it were a NFSv4 server. >>>> >>>> And, I guess since AUTH_SYS is insecure can I suggest a friendly >>>> amendment to the following sentence: >>>> >>>> OLD: >>>> The use of requests issued without RPCSEC_GSS (i.e. using >>>> AUTH_SYS), while undesirable, may not be avoidable in all >>>> cases. >>>> >>>> NEW: >>>> >>>> The use of requests issued without RPCSEC_GSS (i.e. using >>>> the known to be insecure AUTH_SYS), while undesirable and >>>> Insecure, may not be avoidable in all cases. >>>> >>>> It=E2=80=99s probably also worth discussing whether s14.3 should dro= p >>>> support for includes id-sha1. >>>> >>>> >>>> These are the nits: >>>> >>>> 0) Update to use new 2119 paragraph: >>>> >>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT"= , >>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", a= nd >>>> "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. >>>> >>>> 1) s3.1 (wordy): r/since the >>>> ports to be used for various types of connections might be >>>> required to be different/since the >>>> ports to be used for various types of connections might be >>>> different. >>>> >>>> 2) s3.1 (missing period): r/Two such addresses support the use of >>>> clientid >>>> ID trunking, as described in [RFC5661]/Two such addresses support = the >>>> use of clientid >>>> ID trunking, as described in [RFC5661]. >>>> >>>> 3) s4.2 (missing word): r/which may accessed/which may be accessed >>>> >>>> 4) s4.3 (1st sentence): Not sure the 2119-RECOMMENDED is needed. >>>> >>>> 5) s4.3 (penultimate para): Seems like r/should/SHOULD. >>>> >>>> 6) s4.5: r/present , is/present, is >>>> >>>> 7) s4.5: Note sure you need the parenthetical in the following: >>>> a server may (but is not required to) >>>> >>>> 8) s4.5.4: r/In the event that server failures,/In the event that >>>> server fails, >>>> or >>>> r/In the event that server failures,/In the event of server failures= , >>>> >>>> 9) s12.2.3: replace ietf.org with example.org (not supposed to use >>>> real domains even if it is =E2=80=9Cours=E2=80=9D). >>>> >>>> 10) s16 (3rd bullet): Why is requirement is caps? >>>> >>>> >=20 From nobody Fri Mar 8 21:24:58 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 432BC12D4F2; Fri, 8 Mar 2019 21:24:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley via Datatracker To: Cc: draft-ietf-regext-bundling-registration.all@ietf.org, ietf@ietf.org, regext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155210908621.26593.15343460778938123458@ietfa.amsl.com> Date: Fri, 08 Mar 2019 21:24:46 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-regext-bundling-registration-09 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, 09 Mar 2019 05:24:46 -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-regext-bundling-registration-09 Reviewer: Russ Housley Review Date: 2019-03-09 IETF LC End Date: 2019-03-15 IESG Telechat date: unknown Summary: Has Issues Major Concerns: If this document is going to be published on the IETF Stream, then the IANA registrations should point to the IESG, not the document authors. Minor Concerns: Section 2: Please update the first paragraph to 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. Nits: The document has many grammer errors. For example, the first paragraph of the Introduction has three things that need to be corrected: - s/which has identical/which have identical/ - s/labels(LABEL)/labels (LABEL)/ - s/(V-tld);/(V-tld)./ In addition, there are several places in the document with arbitrary extra white space. For example, in Section 8, it says: Please correct the grammar and eliminate the extra white space. Ins Section 7.2.2, some of the lines in the examples do not begin with "S:". Please correct. From nobody Sat Mar 9 03:36:17 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 B9F81124C04 for ; Sat, 9 Mar 2019 03:36:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 4GW_rCQKiwUS for ; Sat, 9 Mar 2019 03:36:08 -0800 (PST) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 C69511277DE for ; Sat, 9 Mar 2019 03:36:06 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id w2so104976wrt.11 for ; Sat, 09 Mar 2019 03:36:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SRYHJN3eBoTs51yhunPGCL100kSu/55MsyUMJim7n2E=; b=Weji2LG5oUPcV7h4L/VFIDq73NSCKZSC5ZexWQJRCX682OaLMxeVJdLYx29fyLErfH HFMpBetpokUfiR9Pf+y+9aGmQl4Q/GrLzvYDCrsivcZOqpEyGsYnFI7w5eu7ud5/xp/W arpKhbIL+TpMjP4PdR8KL6Ih+Mr+mqKzdliBM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SRYHJN3eBoTs51yhunPGCL100kSu/55MsyUMJim7n2E=; b=L/uYRxwIk7lbkO2UhUcj0uMXBSQDIBnq1Qtcsk1Ubrj1vheCWu45xyYxug3+Gbw8zb fdhXpBGYMiy37YYZGkku+G4i49+m0mMJ6t7FaO/aEF2trbOKxZbDeQlLrJXzt57JmlSt Q2xymDKLl728PSHbR6m0Zqf3xykgHBJgDFcRYc/TmRHY7MbSEO6PwNRiVs+NISQ1KXPg MAr7NwZx0keTMGkRYCVBzE6UHrq05smYews/wHen+M4ZdH26lHws+Vt09ScPjMCZaePC ScWaBmfumvWRzfgKSrhwp7k0EHXL9Tm0V9Onoo5kGPsI9vZI1GbEbZO4ssLAzNtIgVJv ymmw== X-Gm-Message-State: APjAAAWxGVlFwKrNSvbCWvvGnSkBPVJon1jOH+7ZMsxxEmEG67yBMGiR 1IQMrlCwjS2JMfbkM+SyM/crew== X-Google-Smtp-Source: APXvYqwBdffRG/efpjn28ifjGC7SCl/j3zMV6V268eAVL1NU0yj5cPTVVXVW66s3j8PEIh/uSTcAiA== X-Received: by 2002:adf:f410:: with SMTP id g16mr14867297wro.246.1552131365093; Sat, 09 Mar 2019 03:36:05 -0800 (PST) Received: from aarons-macbook.lan ([62.178.33.149]) by smtp.gmail.com with ESMTPSA id d21sm1558752wrc.44.2019.03.09.03.36.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Mar 2019 03:36:03 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Aaron Zauner In-Reply-To: Date: Sat, 9 Mar 2019 12:36:01 +0100 Cc: John Mattsson , "secdir@ietf.org" , "cfrg@irtf.org" , "rfc-ise@rfc-editor.org" , "sec-ads@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <38FEBE5B-B60E-49DD-B048-A8A08EBF7FB4@azet.org> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> To: Tony Arcieri X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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 Mar 2019 11:36:10 -0000 Hi, I see some really misinformed comments in this thread. There=E2=80=99s a general IPR exemption for OCB(3) for IETF by Rogaway = and the IBM Corporation (Jutla), which is everything that=E2=80=99s = necessary to go ahead and stanardize and use that mode. I=E2=80=99ve = previously spent quite some time cultivating a AES-OCB ciphersuite = draft* for TLS 1.2 (not necessary for 1.3 IMO) as an alternative to GCM. = Unfortunately back very few people really seemed to understand why I=E2=80= =99m working on this and only a handful were really interested with the = whole standardidzation of TLS 1.3 going on and lots of custom $vendor = extensions being discussed. I was thinking to pick this up again as = it=E2=80=99d make sense for TLS 1.2 still and as OCB3 is a CEASAR = finalist there=E2=80=99s something new to add to the paper (and the = security section w.r.t. OCB2 attacks - where I agree with Tony - have = nothing to do with OCB3 from what I could tell reading them), anyway. = The IPR exemptions are over here: = https://datatracker.ietf.org/ipr/search/?id=3Ddraft-zauner-tls-aes-ocb&sub= mit=3Ddraft It took IBM lawyers quite a while working this out but after I contacted = Rogaway he was very forthcoming and came up with that exemption within a = few weeks of initially talking to him about the topic in general, as was = Jutla once contacted by Rogaway (working at IBM, he had to contact legal = and go through all kinds of bureaucracy from what I understood). Hope that helps to clear things up a bit. Greetings, Aaron=20 * https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/= From nobody Sat Mar 9 03:59:34 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 77CFE1277DE for ; Sat, 9 Mar 2019 03:59:32 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 L1dH9IFEyyHU for ; Sat, 9 Mar 2019 03:59:30 -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 72AE1126D00 for ; Sat, 9 Mar 2019 03:59:30 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id t18so174816wrx.2 for ; Sat, 09 Mar 2019 03:59:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lkX08Xu0MNubE4kAECMT063h62wk9PCtdngPMZUnm7E=; b=O2l9ljSWXPDFjxI/Bwm3XtUbUSN13WbAdwKjWeFWCGMgFpMZ6Ofi4eGR/Oib0J0thi B+8E1SZYa44PbbvKDSdz9L/IA0ZXdg1Cg0ZTV2vDM1NjqddVGFofwroRJv4+TXVB+tGt 4c5PL+wnbUaRYna1rp9qLUlQpSogZlhmmtBCU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lkX08Xu0MNubE4kAECMT063h62wk9PCtdngPMZUnm7E=; b=M5TvY8KqMF5KC8SAUEzg/YnBb1vOAIj/Z+S9IM/7j6QzUpx+Za0J7cpTxfsBQ8max4 rh52HSVtd5NOBF1yCh3IGC0UxflyyTW3ANzm3GyOqS8bcXwJh9ym1HgRIhfhAqs43+2O 8U6JZc+oYk/OIPvNby/Vjm3Iu5CVpT/NB38n4uOaIBjik3oVA/uhZC/xCmxW1jZt9FeY fGyeHgTVta2xpn6cWwpp7nW4cAOGk5QMEkw4qAVv78wMxlXYTnoWCZYjIURpT+lLUa8i Io3BZPNB5o/qX5+AGA8NGG07gj50NRwAp7VV5HK8ROGzOxRz3XSkG7KqjELXazxOswF7 ikOA== X-Gm-Message-State: APjAAAVRi9uSUUvsTdXHYWeEwunKR81zNcwvbZVSDVFBwYBKg5aD8DlT Hi4vR9AthVTIaAzP5P8Ze02HXA== X-Google-Smtp-Source: APXvYqzLIC5IO1iJmMdLwNyuT0AqeWGO+qPc8qU/bp1oHQeAPodx1h4c82zj8TAYGvisiyweNnl1hA== X-Received: by 2002:adf:a10b:: with SMTP id o11mr13455344wro.91.1552132769000; Sat, 09 Mar 2019 03:59:29 -0800 (PST) Received: from aarons-macbook.lan ([62.178.33.149]) by smtp.gmail.com with ESMTPSA id y66sm16379945wmd.37.2019.03.09.03.59.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Mar 2019 03:59:28 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Aaron Zauner In-Reply-To: <38FEBE5B-B60E-49DD-B048-A8A08EBF7FB4@azet.org> Date: Sat, 9 Mar 2019 12:59:27 +0100 Cc: John Mattsson , "secdir@ietf.org" , "cfrg@irtf.org" , "rfc-ise@rfc-editor.org" , "sec-ads@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <38FEBE5B-B60E-49DD-B048-A8A08EBF7FB4@azet.org> To: Tony Arcieri X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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 Mar 2019 11:59:32 -0000 Hi, PS: I forgot to mention that OCB3 is standardized within IETF in RFC7253 = (https://tools.ietf.org/html/rfc7253). Aaron= From nobody Sat Mar 9 04:53: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 D467312796C for ; Sat, 9 Mar 2019 04:53:52 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 cnEpTObj-Fex for ; Sat, 9 Mar 2019 04:53:51 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 4ACB7127963 for ; Sat, 9 Mar 2019 04:53:51 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id f14so275378wrg.1 for ; Sat, 09 Mar 2019 04:53:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1QZW1PyK5rQpo3P4QZcpeVMrvi36PJ4VypoVpcRW5X4=; b=Idh2GEkr1dlEIHihXO5guEyTxgrld8tpqbgXd8I7mvMV4GMzw6X0Zm1jUL+ucLGz8Z gv3IZAc1Diyt5LgvWK9I1NnH8heEjKXAL/2AGmR2CWm/1OaW3o+uJbwBl6noXfljb4vO M4UG0WBwYaRao/NCTJX1fDhfsXFtIgdYkdb/Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1QZW1PyK5rQpo3P4QZcpeVMrvi36PJ4VypoVpcRW5X4=; b=UhPTFic2LIQPtN9Z7zGDs6tKfuGcRlhbukXH1zMZ2rCYL3FW2IcC5s/l9pxKumdAS2 K/nqKlDh73CJ5CkhdDzYvo5OHk/qEO48NfsgZhw/7douRYBWdz0C+hMAu8Ftkc0F09qY dVXYsq06CFgt5WoJc6coQfuou5Mw2OT4CWbdTy9rraJgWEoNcew6yg/2BnSZCvZzuMLi zAvTcY1UQOaRnkrst2fzAdc7fb8CE0fEYEQ1+nztBRltNbVzVbfkULrhKYNF5si6RaJ5 pNNFpuVOYCAZSUrW1l4NHjBbl6rXMjuysQiQLauUw/emHXNPEbP9jF4KOrcIpV7CZLV7 bIqA== X-Gm-Message-State: APjAAAVT/UKw56e1sXxRJezn6CGYuySf7PoCKYFnUe0yogzEvslcgXnR vV79uXtkp6XPRtk0dqjMX3c7Hg== X-Google-Smtp-Source: APXvYqxVnbPFtzikTnIwA1hg1jNqKqKu94qQ0UYI6rNjjOAV25WuLixKDzkXx1w+IoqwXwWGAfZN8w== X-Received: by 2002:a5d:6207:: with SMTP id y7mr14007387wru.60.1552136029743; Sat, 09 Mar 2019 04:53:49 -0800 (PST) Received: from aarons-macbook.lan (62-178-33-149.cable.dynamic.surfer.at. [62.178.33.149]) by smtp.gmail.com with ESMTPSA id j41sm2384029wre.9.2019.03.09.04.53.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Mar 2019 04:53:49 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Aaron Zauner In-Reply-To: Date: Sat, 9 Mar 2019 13:53:48 +0100 Cc: John Mattsson , "secdir@ietf.org" , "cfrg@irtf.org" , "rfc-ise@rfc-editor.org" , "sec-ads@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <00B4F2E8-DFF4-43C6-B5BF-D5CCCF9414FC@azet.org> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> To: Tony Arcieri X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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 Mar 2019 12:53:53 -0000 > On 09.03.2019, at 02:32, Tony Arcieri wrote: >=20 > Given this, and perhaps temporarily suspending discussion of the Jutla = and Grigor patents, I'm curious what kind of IPR statement would be = needed from Rogaway to alleviate concerns about his specific patents. As far as I can remember the Grigor patents were only very very vaguely = related to OCB with Rogaway filing a similar patent even before they = did. So that=E2=80=99s something patent lawyers would have to fight over = and work out, Rogaway told me back then that he isn=E2=80=99t worried = about these patents. Also they expire in 2021. Aaron= From nobody Sat Mar 9 05:25:50 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 A4ED2127968; Sat, 9 Mar 2019 05:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 NIPsF7qGyJnO; Sat, 9 Mar 2019 05:25:46 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1646A12798D; Sat, 9 Mar 2019 05:25:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3009; q=dns/txt; s=iport; t=1552137946; x=1553347546; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=qfeYLkBjQG9TzbImbk5IH9/0PcOSpNy7r1bOvzcFvo8=; b=IaSC3nPX4bgKirH0o4T5JwBgOFcJ0DSSudkGTmYEC7Q2pfsm6rtSfL8s pGaCcP8EWxZMoS+EUg++doA5O9HDczpWcEusumOaElNuol7S2RdFUhQfu l9O/xh8sJaZsWF/HbkeUpRqwPsYscfwZkNCjQsNublbD+DH/jaBjseGrd s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAB/voNc/49dJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgWAvaIEDJwqDf4gaizCBaCWYJoF7CwE?= =?us-ascii?q?BGA+ERQKENSI0CQ0BAQMBAQcBAwJtHAyFSgEBAQECAQEBIUsLBQsLCQUKAgI?= =?us-ascii?q?mAgInIBAGDgWDIgGBbQgPrwiBL4REQYUHHQWBCyQBiWmBQxeBP0CBOAwTgh4?= =?us-ascii?q?ugx4BAQIBARaBR4MKMYImA4pLgVUqhDl0kioJgzmEGIs7GYF5hWaLW5BdiXS?= =?us-ascii?q?CbgIRFYFHOIFWcBU7KgGCQT6KToVdIQEBMQ6PWAGBHgEB?= X-IronPort-AV: E=Sophos;i="5.58,459,1544486400"; d="scan'208";a="529358204" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2019 13:25:44 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x29DPifl027256 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 9 Mar 2019 13:25:44 GMT Received: from rtp-mcgrew-nitro3.cisco.com (10.117.145.148) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 9 Mar 2019 07:25:42 -0600 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: mcgrew In-Reply-To: <38FEBE5B-B60E-49DD-B048-A8A08EBF7FB4@azet.org> Date: Sat, 9 Mar 2019 08:25:26 -0500 CC: Tony Arcieri , "sec-ads@ietf.org" , "secdir@ietf.org" , "cfrg@irtf.org" , "rfc-ise@rfc-editor.org" Content-Transfer-Encoding: quoted-printable Message-ID: <768D0A7A-F365-4748-B3E2-06824715BC1F@cisco.com> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <38FEBE5B-B60E-49DD-B048-A8A08EBF7FB4@azet.org> To: Aaron Zauner X-Mailer: Apple Mail (2.3445.102.3) X-Originating-IP: [10.117.145.148] X-ClientProxiedBy: xch-aln-017.cisco.com (173.36.7.27) To XCH-ALN-004.cisco.com (173.36.7.14) X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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 Mar 2019 13:25:49 -0000 Hi Aaron, The IPR statements for your draft seem to only cover the use of OCB in = TLS, and not its use outside that context. I am not a lawyer, but that = is how I would understand the phrase =E2=80=9Ca royalty-free = non-exclusive license to all claims of the referenced patents needed to = realize a fully compliant implementation of TLS (Transport Layer = Security) supporting AES-OCB (RFC 7253)=E2=80=9D. This point might not = matter to the implementers of your draft, but it might matter a lot to = other people. =20 For anyone researching the IPR status of RFC 7253, please note that Phil = submitted several IPR statements IPR statements related to (the draft = version of) that specification, which can be found with this search: = https://datatracker.ietf.org/ipr/search/?draft=3D&rfc=3D7253&submit=3Drfc&= doctitle=3D&group=3D&holder=3D&iprtitle=3D&patent=3D =20 Aaron, let me also take the time to thank you for working with the = patent holders to get the IPR statements issued for your draft (and = thanks are due to the patent holders as well). =20 Best, David > On Mar 9, 2019, at 6:36 AM, Aaron Zauner wrote: >=20 > Hi, >=20 > I see some really misinformed comments in this thread. >=20 > There=E2=80=99s a general IPR exemption for OCB(3) for IETF by Rogaway = and the IBM Corporation (Jutla), which is everything that=E2=80=99s = necessary to go ahead and stanardize and use that mode. I=E2=80=99ve = previously spent quite some time cultivating a AES-OCB ciphersuite = draft* for TLS 1.2 (not necessary for 1.3 IMO) as an alternative to GCM. = Unfortunately back very few people really seemed to understand why I=E2=80= =99m working on this and only a handful were really interested with the = whole standardidzation of TLS 1.3 going on and lots of custom $vendor = extensions being discussed. I was thinking to pick this up again as = it=E2=80=99d make sense for TLS 1.2 still and as OCB3 is a CEASAR = finalist there=E2=80=99s something new to add to the paper (and the = security section w.r.t. OCB2 attacks - where I agree with Tony - have = nothing to do with OCB3 from what I could tell reading them), anyway. = The IPR exemptions are over here: = https://datatracker.ietf.org/ipr/search/?id=3Ddraft-zauner-tls-aes-ocb&sub= mit=3Ddraft >=20 > It took IBM lawyers quite a while working this out but after I = contacted Rogaway he was very forthcoming and came up with that = exemption within a few weeks of initially talking to him about the topic = in general, as was Jutla once contacted by Rogaway (working at IBM, he = had to contact legal and go through all kinds of bureaucracy from what I = understood). >=20 > Hope that helps to clear things up a bit. >=20 > Greetings, > Aaron=20 >=20 > * https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/ > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg From nobody Sat Mar 9 07:26: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 ACA78127598 for ; Sat, 9 Mar 2019 07:25:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.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 yMrtQtcs5Kv1 for ; Sat, 9 Mar 2019 07:25:53 -0800 (PST) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (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 5E16D12798C for ; Sat, 9 Mar 2019 07:25:51 -0800 (PST) Received: by mail-wr1-x443.google.com with SMTP id d17so502142wre.10 for ; Sat, 09 Mar 2019 07:25:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CaMRmc0xmLAEyRqWJr2aEzuu1NWISA4CARC5CzYILN8=; b=GV5pobJr4SPfu1uyk0yJHkPCgAl53ROq7mFJeXx6L+WLZ53WOEqzYDewdB/YQxM0HR F+//IyzIzYmy57+P6y28umIctGpEYaOWVaUN7JWUioj9BvcflQxawl/HXs6VCjKygY5T l5droZo20G6HQfupgRv3dxZOc1q3WeiI4MSr8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CaMRmc0xmLAEyRqWJr2aEzuu1NWISA4CARC5CzYILN8=; b=LNBMFO8tzBw9YjxAUTxEYbXuTsMicyJ6xW9juACn67hXvKUgjjFEayvLgSa0iEoRJ+ DVrZL9+RvdKXjpJ9JUeI5+n7FhbRuCBSd8QsPfJfXsjbFnKRxbcxX+ICNDX3775AF98I 0IYO/7hZT42fqx5z/h6mNzlRh5LBF+zeWm0ot05R1NDpoC2kqRUOqnVpGQHnoajwoWRc RsFt10qP/H1TPzxwFWI5OtFr33etO4S0uezmYy3rPiDESPTk17rNR5AO3Lc6Dhu1yLYG HkbaD8PEWrvRFpobx+/n0WkCeFzpc57VnaFhbjei/tDF/rr8JOxngLa3ijbmSm4EiV29 FPVA== X-Gm-Message-State: APjAAAUojcNdaDuC0fZsTz9aQhOJPk1u9o3x1I/9v/Xh5ckiw3ccRntq Z+ZkMDlaGHbU/nXSGOyW8Ps5vg== X-Google-Smtp-Source: APXvYqzdvL8g1S1tpK+47SfZzL4mFIlis9Ma9AWBK0+9N5xl65gxPimR9UN6fx9VXJjQex+00A7wcQ== X-Received: by 2002:adf:e304:: with SMTP id b4mr15195320wrj.123.1552145149705; Sat, 09 Mar 2019 07:25:49 -0800 (PST) Received: from aarons-macbook.lan ([62.178.33.149]) by smtp.gmail.com with ESMTPSA id q5sm784883wrn.43.2019.03.09.07.25.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Mar 2019 07:25:49 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Aaron Zauner In-Reply-To: <768D0A7A-F365-4748-B3E2-06824715BC1F@cisco.com> Date: Sat, 9 Mar 2019 16:25:47 +0100 Cc: Tony Arcieri , "sec-ads@ietf.org" , "secdir@ietf.org" , "cfrg@irtf.org" , "rfc-ise@rfc-editor.org" Content-Transfer-Encoding: quoted-printable Message-Id: <471653B0-C734-4C5F-905C-682646FE6387@azet.org> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <38FEBE5B-B60E-49DD-B048-A8A08EBF7FB4@azet.org> <768D0A7A-F365-4748-B3E2-06824715BC1F@cisco.com> To: mcgrew X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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 Mar 2019 15:25:55 -0000 Hi David, > On 09.03.2019, at 14:25, mcgrew wrote: >=20 > Hi Aaron, >=20 > The IPR statements for your draft seem to only cover the use of OCB in = TLS, and not its use outside that context. I am not a lawyer, but that = is how I would understand the phrase =E2=80=9Ca royalty-free = non-exclusive license to all claims of the referenced patents needed to = realize a fully compliant implementation of TLS (Transport Layer = Security) supporting AES-OCB (RFC 7253)=E2=80=9D. This point might not = matter to the implementers of your draft, but it might matter a lot to = other people. =20 That=E2=80=99s correct. My bad, the initial text was supposed to say = "general IPR exemption for OCB(3) in TLS for IETF=E2=80=9D. I wrote & = edited that mail right after getting up and must have removed that = editing this message and moving sentences around in an attempt to make = it more coherent :) >=20 > For anyone researching the IPR status of RFC 7253, please note that = Phil submitted several IPR statements IPR statements related to (the = draft version of) that specification, which can be found with this = search: = https://datatracker.ietf.org/ipr/search/?draft=3D&rfc=3D7253&submit=3Drfc&= doctitle=3D&group=3D&holder=3D&iprtitle=3D&patent=3D =20 Yes, you can find all of Rogaway=E2=80=99s IPR claims pertaining IETF = documents via: = https://datatracker.ietf.org/ipr/search/?draft=3D&rfc=3D&doctitle=3D&group= =3D&holder=3DPhillip+Rogaway&submit=3Dholder&iprtitle=3D&patent=3D > Aaron, let me also take the time to thank you for working with the = patent holders to get the IPR statements issued for your draft (and = thanks are due to the patent holders as well). =20 It was quite an interesting experience and I hope that writing it up can = serve others in the future. My impression is that it=E2=80=99s not = difficult to get an IPR exemption if the people behind the original work = are intrested in it being used. I think Rogaway had just the best = intentions at heart with the original licensing, but may have missed = that it=E2=80=99ll cause issues with standardization processes in the = future/real world that may have an adverse impact on the use of OCB3. = He=E2=80=99s granted free licenses to Open-source implementations and = other projects and organizations since. OCB3 (and my draft) were also = implemented in various libraries, among them OpenSSL (C), Botan (C++) = and BouncyCastle (Java). Back when they optimized it OCB even beat GCM = w.r.t. performance in OpenSSL on Haswell Intel x86_64 processors and has = since kept up pretty well consindering AESNI is aimed at GCM/GHASH (see = head comment on performance in = https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aesni-x86_64= .pl). ``` *) Added support for OCB mode. OpenSSL has been granted a patent = license compatible with the OpenSSL license for use of OCB. Details are = available at https://www.openssl.org/source/OCB-patent-grant-OpenSSL.pdf. = Support for OCB can be removed by calling config with no-ocb. [Matt Caswell] ``` =E2=80=94 https://www.openssl.org/news/cl111.txt (in "Changes = between 1.0.2h and 1.1.0 [25 Aug 2016]=E2=80=9D) Aaron= From nobody Sat Mar 9 10:26: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 55A47130E9E; Sat, 9 Mar 2019 10:26:31 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 3NhDTyzUXr_2; Sat, 9 Mar 2019 10:26:29 -0800 (PST) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 6601A130E9B; Sat, 9 Mar 2019 10:26:29 -0800 (PST) Received: by mail-ot1-x335.google.com with SMTP id q24so641050otk.0; Sat, 09 Mar 2019 10:26:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M5XwU+7UeL3NSyj0e189r5eLyOyKB281w/IEZdGh1c4=; b=ru8BrAffmbvJUtydg1EIrrU7x1pJ+DESb+sekZ1CCeKSIX8E3UFXAE5wAGjgW+RN/H iF1rXmZup9xhQMAcSED9gg5DWaRUnNpMOsbQfWG26Hy2NQNcUWq8hN9eHqD/RvzAsJmA Cjpb0SIt13xXALJjdcSk1/Z7RMApY0DIbV/kcm884kMaO+/L0ihLTWD+Dv8ELQIvlZ9R 4yi2nltOKQ322G+Jg4kPUAfvzdCwCn2ChwsE4gfcruQAAoSJxoGXLltLGhcCHca8yAuI by5ql66vxzXj5WPNYFkgco3j/Lhy9VTkYlputqNeLJLuB+eOgcHxJxfp9YYI98JGhia+ 1Wdg== 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=M5XwU+7UeL3NSyj0e189r5eLyOyKB281w/IEZdGh1c4=; b=BVAG78qJo/KdsY2iup0k52BkckViMF0DPR44oB4Y0UrfziW+TPf9/pV0TWCtvhu3Rj umPkdd3M1eWMu/AuemFSZoXUjP1ncPO6fJTD9HB6J00mbx/fyCU5Fq9f9zreIVsQZFpi bBniEyRkP+6Y/KRacb4JCWxBqE36tQQbag2PTgGaUslz9xZhVcnMZ9mx/LaOOaP7CZ9B DukkOIB0FZbTrf12mDNX9hddzNC3W+a3NpCRivPyXtlymwW2uvu5y6r0PY3WSG3kYQlk IC/y8qM5RxKjacprOKFK7+15tt575F2aTDxTTp+KAA59kXFscQatilC2tIPhfuQI7bRq y1vw== X-Gm-Message-State: APjAAAWcazifmz7NpX2HnzQabfR1jP2RNb9WZltvoPh6wJSNtH3I9bEb 2hq02lzWB7HkEagD4QOaAB8gvvW02hRiRb6ttqE= X-Google-Smtp-Source: APXvYqyHYNExtGmYgY6I4kx8oQuROeO+4RTVuKk6Siw7UB7CTc6Y6thEsJJOohtMolDg2A/fG9RAgLVW4QN9XvA0iFU= X-Received: by 2002:a9d:3e41:: with SMTP id h1mr16510505otg.170.1552155988688; Sat, 09 Mar 2019 10:26:28 -0800 (PST) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <38FEBE5B-B60E-49DD-B048-A8A08EBF7FB4@azet.org> <768D0A7A-F365-4748-B3E2-06824715BC1F@cisco.com> <471653B0-C734-4C5F-905C-682646FE6387@azet.org> In-Reply-To: <471653B0-C734-4C5F-905C-682646FE6387@azet.org> From: Tony Arcieri Date: Sat, 9 Mar 2019 10:26:17 -0800 Message-ID: To: Aaron Zauner Cc: mcgrew , "sec-ads@ietf.org" , "secdir@ietf.org" , "cfrg@irtf.org" , "rfc-ise@rfc-editor.org" Content-Type: multipart/alternative; boundary="0000000000005784d40583ad7a55" Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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 Mar 2019 18:26:32 -0000 --0000000000005784d40583ad7a55 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Mar 9, 2019 at 7:25 AM Aaron Zauner wrote: > > The IPR statements for your draft seem to only cover the use of OCB in > TLS, and not its use outside that context. I am not a lawyer, but that = is > how I would understand the phrase =E2=80=9Ca royalty-free non-exclusive l= icense to > all claims of the referenced patents needed to realize a fully compliant > implementation of TLS (Transport Layer Security) supporting AES-OCB (RFC > 7253)=E2=80=9D. This point might not matter to the implementers of your= draft, > but it might matter a lot to other people. > > That=E2=80=99s correct. My bad, the initial text was supposed to say "gen= eral IPR > exemption for OCB(3) in TLS for IETF=E2=80=9D. I wrote & edited that mail= right > after getting up and must have removed that editing this message and movi= ng > sentences around in an attempt to make it more coherent :) I asked Rogaway about this... How would people feel if he extended this IPR exemption to any standards track protocol developed by the IETF? Would that be sufficient? --0000000000005784d40583ad7a55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Mar 9, 2019 at 7:25 AM Aaron Zaun= er <azet@azet.org> wrote:
> The IPR statements for your draft seem to only cover the use of O= CB in TLS, and not its use outside that context.=C2=A0 =C2=A0I am not a law= yer, but that is how I would understand the phrase =E2=80=9Ca royalty-free = non-exclusive license to all claims of the referenced patents needed to rea= lize a fully compliant implementation of TLS (Transport Layer Security) sup= porting AES-OCB (RFC 7253)=E2=80=9D.=C2=A0 =C2=A0This point might not matte= r to the implementers of your draft, but it might matter a lot to other peo= ple.=C2=A0

That=E2=80=99s correct. My bad, the initial text was supposed to say "= general IPR exemption for OCB(3) in TLS for IETF=E2=80=9D. I wrote & ed= ited that mail right after getting up and must have removed that editing th= is message and moving sentences around in an attempt to make it more cohere= nt :)

I asked Rogaway about this...

How would people feel if he extended this IPR exemption t= o any standards track protocol developed by the IETF? Would that be suffici= ent?=C2=A0
--0000000000005784d40583ad7a55-- From nobody Sat Mar 9 13:05: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 83F9612797A for ; Sat, 9 Mar 2019 13:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=krovetz-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 3gvm6oUoFj2D for ; Sat, 9 Mar 2019 13:05:51 -0800 (PST) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (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 B725C127598 for ; Sat, 9 Mar 2019 13:05:49 -0800 (PST) Received: by mail-oi1-x22a.google.com with SMTP id t82so803637oie.12 for ; Sat, 09 Mar 2019 13:05:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krovetz-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7W/xifbX4+awDKW6z52frALc2+mXRPFB8CjGXVCs86k=; b=RdsbaZQV/6uH7VTcGFScZTs2OwWA+jqhCGilrtP1I4gg4HjiHV/HqC+XYrYFcpRxfe s8MV8Tax5hvPggvoAvVALj6svHgjPTzwjaX5Vc4lA9/Ug+rk3Qj96hsiSXnVp5PAdx2E 2aqvPYUlX8Q6sMkC/xjRTF1a95jmh9maHAAWtjGLOWdB6EGXA4Ve09VMhAvx8k0cAnvl xrsuME3xMbBXf/hTxvTYcj2JlMdD3/oev8VYeoQ5JouQPct44w3JmwPdzHpJpGieNU+/ V0n3Piy/MTOVvwXdZRuzmrt66UHg2zBmVhIgs8bMGkToJUcAM4jhZjb4UHF740FSMSD0 RA2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7W/xifbX4+awDKW6z52frALc2+mXRPFB8CjGXVCs86k=; b=oqJdRYZTMAea2tdDhD+Hs6TstMNXHfIFfj8UycUT7cGj+bWXDOt1PPR5weVfvT4MD9 OxPaTR3yKXUSKpzpFc1gB+SJfHsUN25MKrGOeGbaF0CQZWAPsmkRYon5HqwMQ35cSufr /ttFyQRtowPAgIASm3ZVuqxdzxKDEp2qjE9wor3EVigpvN3RWuz7bhNYE7+mDv3S0vSf ds+iOool1uMMLJ1uyvRjXi+1R+GHUcZi7FehGd9d3NNGyy6DboeS7Z7JJWiu68bCPBKM 6JjKVRhMARcobiZ8ovQf8fTYEE4J/V7yXpTJEwpa+8jK5690G06nWMIRCmJaeZQy0MpR mMjg== X-Gm-Message-State: APjAAAW+o0wTTaTv9jTJVEAA5t40aPqTVRoUjS2HgVaBuwTqINRjNKp+ sbr5vfVg7/7RPqBsxZwIByXWlw== X-Google-Smtp-Source: APXvYqzb4CQJzGIQUZFLsrL2o/+ER5XARKdnNf0iLNHk7APcYI56O5Q281CKUn11YIwtSxqvVxH0MQ== X-Received: by 2002:aca:be88:: with SMTP id o130mr11501748oif.50.1552165549023; Sat, 09 Mar 2019 13:05:49 -0800 (PST) Received: from ?IPv6:2600:1700:7c70:16a0:7979:a882:df33:e263? ([2600:1700:7c70:16a0:7979:a882:df33:e263]) by smtp.gmail.com with ESMTPSA id w22sm538752oth.45.2019.03.09.13.05.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Mar 2019 13:05:48 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Ted Krovetz In-Reply-To: Date: Sat, 9 Mar 2019 13:05:46 -0800 Cc: "sec-ads@ietf.org" , "cfrg@irtf.org" , "rfc-ise@rfc-editor.org" , "secdir@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> To: John Mattsson , "Salz, Rich" X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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 Mar 2019 21:05:52 -0000 > On Mar 8, 2019, at 4:11 PM, John Mattsson = wrote: >=20 > Given that CFRG has already published OCB3 in RFC 7253, which was = recently included in the CEASAR final portfolio, I would like to see the = OCB3 wideblock draft published somewhere. I agree with Rich that it = would be better to replace RFC 7523. > On Mar 8, 2019, at 9:56 AM, Salz, Rich wrote: >=20 > https://datatracker.ietf.org/doc/draft-krovetz-ocb-wideblock/ >=20 > I would rather see this rewritten to completely replace 7523 (and = include its test vectors of course) Would review. >=20 > https://datatracker.ietf.org/doc/draft-krovetz-rc6-rc5-vectors/ >=20 > I don't see a compelling need for this, but I am not strongly opposed = either. I would be happy to merge the wideblock modifications into RFC 7253. I = was unaware that such changes were allowed for RFCs after publication, = but if it is allowed it seems like a sensible approach. I am currently = half-way through a busy semester so would not be able to get to it until = May though. As for the RC5/RC6 draft, I introduced it so that I would have a simple = example block cipher for generating test vectors of different lengths. = If it's not useful as a stand alone RFC, I could fold it into an = appendix of a revised RFC 7253 or take suggestions for other applicable = block ciphers with stable normative references. A more compact = alternative to using a real block cipher for test vectors is to use a = toy stand-in such as E(k,x) =3D x*k over GF(2^n). Thank you for all of your feedback, Ted= From nobody Sat Mar 9 14:08:18 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 BFD521277D9; Sat, 9 Mar 2019 14:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 z2sDqFnZxeyl; Sat, 9 Mar 2019 14:08:09 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 5D3D912705F; Sat, 9 Mar 2019 14:08:09 -0800 (PST) Received: from [10.32.60.82] (1-197.icannmeeting.org [199.91.197.1]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id x29M6PwB056310 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 9 Mar 2019 15:06:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 1-197.icannmeeting.org [199.91.197.1] claimed to be [10.32.60.82] From: "Paul Hoffman" To: "Aaron Zauner" Cc: secdir@ietf.org, cfrg@irtf.org, rfc-ise@rfc-editor.org, sec-ads@ietf.org Date: Sun, 10 Mar 2019 07:07:58 +0900 X-Mailer: MailMate (1.12.4r5594) Message-ID: In-Reply-To: References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <38FEBE5B-B60E-49DD-B048-A8A08EBF7FB4@azet.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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 Mar 2019 22:08:12 -0000 On 9 Mar 2019, at 20:59, Aaron Zauner wrote: > PS: I forgot to mention that OCB3 is standardized within IETF in > RFC7253 (https://tools.ietf.org/html/rfc7253). RFC 7253 is not a standard: it is an Informational document. This is not just another "that's just semantics" statement because Tony Arcieri then followed with: > How would people feel if he extended this IPR exemption to any > standards track protocol developed by the IETF? Would that be > sufficient? The answer to "is TLS 1.3 (a standard) using OCB3 (no a standard) a standards-track protocol" is not obvious. Well, some people would say it is obvious, but would disagree on the value of the boolean response. --Paul Hoffman From nobody Sat Mar 9 14:18:05 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 E100B12705F; Sat, 9 Mar 2019 14:17:58 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 jCQJiPYyOlAp; Sat, 9 Mar 2019 14:17:57 -0800 (PST) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (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 EEE581277D9; Sat, 9 Mar 2019 14:17:56 -0800 (PST) Received: by mail-oi1-x229.google.com with SMTP id t82so868812oie.12; Sat, 09 Mar 2019 14:17:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0HVMdbb2BOZ/JtHo1r9byUULIzYYMM//D2aXQZ4ldBY=; b=KCp+Nmdv1FO5Nr5nHQwN25fhVUj64e6Vljxra0K5EQ74wd6Or5ZHq+3ZpH3AE6/bp8 BEfail3ca+ZB384rAglVXCYKYWTqliCwgVy5L1zhiUKxqviTDPkHu3E/9DooE/MIQofG n01Egvnus1E9CetfOBFJ4d6R/FidVgd2j9JgNY/r1dmFW1bISn4YTJ3S5/1HZruE5k5f B0Z0rJ+eB+b37gg6TVRzNr5oxC3FPz8F2Jzgt9yn8Tc5/RA9nmDjjHc4YK0i1v9DfRK5 lHt1Yi324UJWb5shLR09fCa/II8GDI4O3rx0AkslZG+T2XYxsKGLs2DoNPLPOHETB+4R QVNg== 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=0HVMdbb2BOZ/JtHo1r9byUULIzYYMM//D2aXQZ4ldBY=; b=ZpOAKvx+qayvuHXZlZJnOzq3ESfrrdB1jaao8gy05HVgI4EcTHHzZTsGj1Puif5QeN 181PQscPG296NomdN0L20YrP5PaO94zTqOlCwax/edgAfjRaA8Ws2zy1l2bRqneABGAY Ywo0ynrgfpX0ZEGyG/utrhxW1EIzqtQ+J7c3vvzikI+nAcGrVtvgynu0FABbrIkHUF64 lxhbrUNEZctCSJDVDHcF1ur7iL/vFMyoepdi0uia5mXCBaijHZfL14UszF0n67zx3mwC G1KFCva3+i2EBafXyocCKjH/TY0j6oQbnUwtaPBEyxFuZqbDLgOdrcQrW6CGj0ypBwc6 Erzg== X-Gm-Message-State: APjAAAX1nzpqQQoW87rTXErL3UuF+YLzFvl/gY14NIefuirs2Xyo2gHU gS6a5oUF+LzbIs5bpG//8gM7e2unD0DBRcxO7So= X-Google-Smtp-Source: APXvYqxd4bLXQ1R09a3AlPqwEg0saeBFlXFeO1S/hSXaV2w6/NGBe45HMkNWEvwwDdZ/SyRGG5fGjy3aHzE9kEBLb1M= X-Received: by 2002:aca:f546:: with SMTP id t67mr11992171oih.152.1552169876215; Sat, 09 Mar 2019 14:17:56 -0800 (PST) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <38FEBE5B-B60E-49DD-B048-A8A08EBF7FB4@azet.org> In-Reply-To: From: Tony Arcieri Date: Sat, 9 Mar 2019 14:17:45 -0800 Message-ID: To: Paul Hoffman Cc: Aaron Zauner , sec-ads@ietf.org, CFRG , "RFC ISE (Adrian Farrel)" , secdir Content-Type: multipart/alternative; boundary="0000000000001a606a0583b0b672" Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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 Mar 2019 22:17:59 -0000 --0000000000001a606a0583b0b672 Content-Type: text/plain; charset="UTF-8" On Sat, Mar 9, 2019 at 2:08 PM Paul Hoffman wrote: > The answer to "is TLS 1.3 (a standard) using OCB3 (no a standard) a > standards-track protocol" is not obvious. Well, some people would say it > is obvious, but would disagree on the value of the boolean response. Here is the specific wording he is suggesting: "Phillip Rogaway offers a royalty-free non-exclusive license to all claims of the referenced patents needed to realize a fully compliant implementation of any IETF standards-track protocol supporting AES-OCB (RFC 7253)." I think he's looking for guidance around how to properly phrase that if anyone has a more concrete suggestion for how to put it in the form of an IPR statement. -- Tony Arcieri --0000000000001a606a0583b0b672 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Mar 9, 2019 at 2:08 PM Paul Hoffm= an <paul.hoffman@vpnc.org&g= t; wrote:
The answer to "is TLS 1.3 (a standard) using OCB3= (no a standard) a
standards-track protocol" is not obvious. Well, some people would say = it
is obvious, but would disagree on the value of the boolean response.

Here is the specific wording he is suggesting:

=C2=A0"Phillip Rogaway offers a royalty-free no= n-exclusive license to all claims of the referenced patents needed to reali= ze a fully compliant implementation of any IETF standards-track protocol su= pporting AES-OCB (RFC 7253)."

I think he'= s looking for guidance around how to properly phrase that if anyone has a m= ore concrete suggestion for how to put it in the form of an IPR statement.<= /div>
=C2=A0
--
Tony Arcieri
--0000000000001a606a0583b0b672-- From nobody Sat Mar 9 18:17:44 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 E03301277D2; Sat, 9 Mar 2019 18:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=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 w5HQ8YO84h8f; Sat, 9 Mar 2019 18:17:35 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id AE2ED1275E9; Sat, 9 Mar 2019 18:17:35 -0800 (PST) Received: from LLE2K16-MBX03.mitll.ad.local (LLE2K16-MBX03.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id x2A2HW0N032507; Sat, 9 Mar 2019 21:17:32 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: Tony Arcieri , Paul Hoffman CC: "sec-ads@ietf.org" , CFRG , "RFC ISE (Adrian Farrel)" , secdir Thread-Topic: [Cfrg] ISE seeks help with some crypto drafts Thread-Index: AQHU1dNTVBBNlvC7XkWW3z1y4bZa2qYCWJUAgAAEIACAAGSggIAAFskAgACol4CAAAaMgIAAqgUAgAACvID//+8rgA== Date: Sun, 10 Mar 2019 02:17:31 +0000 Message-ID: <21B00151-36FA-40A9-8F8A-5425FC887C8A@ll.mit.edu> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <38FEBE5B-B60E-49DD-B048-A8A08EBF7FB4@azet.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.0.190211 x-originating-ip: [172.25.1.90] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3635011051_985199062" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-09_20:, , 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903100016 Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 10 Mar 2019 02:17:38 -0000 --B_3635011051_985199062 Content-type: multipart/alternative; boundary="B_3635011051_516283581" --B_3635011051_516283581 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit I would be OK with that statement. -- Regards, Uri From: Cfrg on behalf of Tony Arcieri Date: Saturday, March 9, 201910 at 17:18 To: Paul Hoffman Cc: "sec-ads@ietf.org" , CFRG , "RFC ISE (Adrian Farrel)" , secdir Subject: Re: [Cfrg] ISE seeks help with some crypto drafts On Sat, Mar 9, 2019 at 2:08 PM Paul Hoffman wrote: The answer to "is TLS 1.3 (a standard) using OCB3 (no a standard) a standards-track protocol" is not obvious. Well, some people would say it is obvious, but would disagree on the value of the boolean response. Here is the specific wording he is suggesting: "Phillip Rogaway offers a royalty-free non-exclusive license to all claims of the referenced patents needed to realize a fully compliant implementation of any IETF standards-track protocol supporting AES-OCB (RFC 7253)." I think he's looking for guidance around how to properly phrase that if anyone has a more concrete suggestion for how to put it in the form of an IPR statement. -- Tony Arcieri --B_3635011051_516283581 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I would be OK with = that statement.

 

--

Regards,

Uri

<= p class=3DMsoNormal> 

From: Cfrg <cfrg-bounces@irtf.org> on behalf of Tony Arcieri <bascul= e@gmail.com>
Date: Saturday, March 9, 201910 at 17:18
To:= Paul Hoffman <paul.hoffman@vpnc.org>
Cc: "sec-ads@= ietf.org" <sec-ads@ietf.org>, CFRG <cfrg@irtf.org>, "R= FC ISE (Adrian Farrel)" <rfc-ise@rfc-editor.org>, secdir <secd= ir@ietf.org>
Subject: Re: [Cfrg] ISE seeks help with some crypt= o drafts

 

On Sat, Mar 9, 2019 at 2:08 PM Paul Hoffman <paul.hoffman@vpnc.org> wrote:

=

The answer to "is TLS 1.3 (a standard) usin= g OCB3 (no a standard) a
standards-track protocol" is not obvious. = Well, some people would say it
is obvious, but would disagree on the val= ue of the boolean response.

 

Here is the specific wording he is suggesting:

&nb= sp;

 &q= uot;Phillip Rogaway offers a royalty-free non-exclusive license to all claim= s of the referenced patents needed to realize a fully compliant implementati= on of any IETF standards-track protocol supporting AES-OCB (RFC 7253)."=

&= nbsp;

I thin= k he's looking for guidance around how to properly phrase that if anyone has= a more concrete suggestion for how to put it in the form of an IPR statemen= t.

&nbs= p;

-- =

Tony Arcieri=

--B_3635011051_516283581-- --B_3635011051_985199062 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQADhvrZHqbUs3XjIgAAAAOG+jANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTE5MDEwODE0MjgyMloXDTIyMDEw NzE0MjgyMlowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRtVpCB2qzc1ia4sI2Dq+YEUHS29Ca pM5d0jBAdvQgFnXmTe4Ur0onMJkqYpatbmJAKl9lHMYDMvwemI3DG+0ebyXkVan3lPbawoba Zy7yQzAPvbQ/KSqemihH1SrGp3jF522kmW8o64wzHGaZRgo4LK8xO2TiwdebuBLA+MUh6NqS 3hBVPZ3xb9nVynJ5EIq8XWb/LYpfvgovs5kUL1m1Cl62NQ8+lW6qEUMfgmgY/Sx5DR9Uo9mC DS4IurVXijIK5E4NhYDmkI6KhxgnB0A2iyD/afGlqiIXs2dfOK28smGfFry9HEO5O8n1JI+5 QdzkBce3h/P3i5VE1zCOaF9RAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUhatfAqb0g782Agbd cbDwogD9b+MwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCDAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBACRKYQxz VfdiOo93iNBw7krEv7svK30nqiiMQhPDEuSTUcLUyvEeBT29w+vKil/y6TQ/0LDoKAB0zH+k YPKanaWec44CLyccDyEqUqdIy+GC24JTnGldjc+9sUgKrNWB7dP6pU7jc8o1KC3XJr1al8gf F3qIGk3A0r2zZK8/dOfAGKbDLJAxw5uMwYjqQA61Qt8H428AKVEluGGgNxwGRwt3E8mPmDD2 cr4bl3b2rZTZNRTha8kvsvgh/u1SWfFWutPi26pIsXiJ10ysySW6qeZ2WNPnyIwKFdrvt4W0 AJc2CtcJCZrkfHjkHWARI/JDPln9ZdzxDGYOrpOXDbO40SgwggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAA7OX5fo0OiIK0RAAAAADs5MA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMTgwODI4MjE0NTI5WhcNMjEwODI3 MjE0NTI5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI5Vc19RKc/69lmwhogDOjjzPQbmc8s6 Z6rzP6oUHAswDICqZWwPt+FTbKr0YTAqRNsTEN4YiW0fORK+fNRvClo0pdiCqj3DwDQZLRI4 Dak1yTsUtVe35oomQbXtO+0A0L/CowYri/UKeRG1i1/0cXSf4mAx0ed9wh2SordAb8o2FuOU 0B2ppnqjro1VFugHHX6QOggaeLFOprT5gnTZUmqM37/d4DGB9XDdTQi144zQSwSWKkaUThsy D9CHSRNcB79HBvlZGSM+BkIbayPdhQAuz4yKsOZEWPx/6LnMotzBevSswnCDf+u9ajCgMnje WbrZRN+xoYEuhycXyK2b8/MCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBTZUpq7Rsccv42yU9UQ 4wvojOl4pzAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgEJMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEACyN6 Yhi9LApOPpf60ypSV2WmV3sqnrsrdlPTW+am4wMK/M/5PZmt5jFVtXaErkWYdrbMdjeo2o/G 9N2DnrFOhz7kDYM9HC9AH/rWCfoSkI/C2N6Rq/uDnRJfao61wyv37qKtanNdkp+reyLxdVPn foVrD/VZli4UV28u4XBuYDkjXPyyiH+bb395FnxOtTA3Uz41Ohpdvr6oLPEuy0IP4MPfK5wD mS6GXcB+ze9sYEp+DJxE7WAbkW5Y536WPl/rfWm/k6ZC1KPVSRM7mS+atk44VOgzPLXkl6Tu 6zY8tMczfr5F0om1JfN8G50s4QDUGtsMgzW+LXVDhFD24xnUojGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQADhvrZHqbUs3XjIgAAAAOG+jANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCCGbxD4r6WfnOLCcDgR2YpJ5b1+OGL3iQ7Cc6/W GgD6nTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTAzMTAw MjE3MzFaMA0GCSqGSIb3DQEBAQUABIIBAF0y1+s5FaAaIU/Na+0B1vd0T5eYPDhqgcZJLd3S GGhjHNsPZUWquPlAdU561zG5YNHvxB4ZiDnuV3HQghP3ATdVFcorUeHQKksawo1MLVgeSt7s o4cpa1/j0nR44cPpu7wVkANfM8wqBK7WRzNbea3apDqo6xwIZWYCsus4eQNn/KzIUuEARE+0 51SWSRWlxJ76sZ2piUka4KmcW7QgZ90/m1h2qdBdyhQJVLKG6gFr3I2mLq6mtCZevpZ3Mxfs FgK3ca072ta5C/3mA8FmT9qqC3Utkyy9j1ZtipM1lwjTs9qsqo/aeKKk46meUjLnoXfhhfF9 /yonPEWKl4x3QEA= --B_3635011051_985199062-- From nobody Sat Mar 9 18:47: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 2EBFF1275E9; Sat, 9 Mar 2019 18:47:11 -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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 YyulcNNqX-IK; Sat, 9 Mar 2019 18:47:08 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 7B5CC127962; Sat, 9 Mar 2019 18:47:08 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44H5HF5W7Hz20h; Sun, 10 Mar 2019 03:47:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1552186025; bh=Rp6VNcxzgOt2SfhJKZhfoM+dpu16eb3RXAwrs5OG6V4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MnontxGCl6gqSsmhk6suAv3Q/rBhRTMU7SeUGrWn28wNQG/7yjdnaCl27k2zRxJnF rt+Lioa56FpIugNajqZGutlfBPGH++eFAcblWAeM0lW03miwNzBCTzOjd8Jfz267r0 dtBKAhltlMDQer6MQiTg7XPZ4XJ4CF1FicFTOXVE= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id m-Tpa1_v6AEX; Sun, 10 Mar 2019 03:47:04 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 10 Mar 2019 03:47:03 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 81F095E4BAB; Sat, 9 Mar 2019 21:47:02 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 81F095E4BAB Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7C3B14116028; Sat, 9 Mar 2019 21:47:02 -0500 (EST) Date: Sat, 9 Mar 2019 21:47:02 -0500 (EST) From: Paul Wouters To: Tony Arcieri cc: CFRG , trustees@ietf.org, "RFC ISE (Adrian Farrel)" , secdir In-Reply-To: Message-ID: References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <38FEBE5B-B60E-49DD-B048-A8A08EBF7FB4@azet.org> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 10 Mar 2019 02:47:11 -0000 On Sat, 9 Mar 2019, Tony Arcieri wrote: > Here is the specific wording he is suggesting: > > "Phillip Rogaway offers a royalty-free non-exclusive license to all claims of the referenced patents needed to realize a fully compliant > implementation of any IETF standards-track protocol supporting AES-OCB (RFC 7253)." > > I think he's looking for guidance around how to properly phrase that if anyone has a more concrete suggestion for how to put it in the > form of an IPR statement. While this phrasing would solve the issues for some protocols, such as IKE and IPsec, it is still a request that the IETF publish a cryptographic standard that cannot be freely used. The IETF normally does not do that unless there are exceptional reasons to do so. It would be good to see thse reasons written up for evaluation. It would be problematic too if someone using an RFC wouldn't realise their use of this standard would be in violation of Mr. Rogaway's IPR. I also believe allowing OCB for only TLs in the past was a mistake we should not repeat in a slightly different form by covering a few more protocols. Note also RFC 3979: https://tools.ietf.org/html/rfc3979#section-8 Over the last few years the IETF has adopted stricter requirements for some security technologies. It has become common to have a mandatory-to-implement security technology in IETF technology specifications. This is to ensure that there will be at least one common security technology present in all implementations of such a specification that can be used in all cases. This does not limit the specification from including other security technologies, the use of which could be negotiated between implementations. An IETF consensus has developed that no mandatory-to-implement security technology can be specified in an IETF specification unless it has no known IPR claims against it or a royalty-free license is available to implementers of the specification unless there is a very good reason to do so. As the IETF has been moving towards reducing the number of algorithms, it would not make sense to promote a new algorithm that can never become mandatory-to-implement. Maybe it would be good to involve the IETF Trust in this matter? Paul From nobody Sat Mar 9 18:56:24 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 3777512008A; Sat, 9 Mar 2019 18:56:16 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 SOlRRSn0UFpn; Sat, 9 Mar 2019 18:56:12 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 613BB1275E9; Sat, 9 Mar 2019 18:56:12 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id p1so989311lfk.9; Sat, 09 Mar 2019 18:56:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+70s/FrxjUFD9qkdn4BQ4W3R67SG3FLltUeWgaSsaSY=; b=BnUmXVKFpSTRprFC50+igtE+VEMrGJ8EFxCmlmAaPWHmvgZt+gj+W2w3GjDSYzl0eF 9i+b5BAGFqfrnuMOzZe7NwtlS3OxsRmHWKWFc8CbYpbMP0tGlW0CVQhAYCEYFwjfomea uuLDoe8VRv69gNRbsRmZk8Qgnpmy0ZymqU1CwyHgY79jhkPs8Uh4ZKFgobweiIfJ/858 ixWv7qrnixJYZdoSkjEnwLEcjyHlIh/cQTyJrr5+CeKvcvwCg/lTcej1eIGX2Dl5/ZxO cnKhUXup2RKkH+uPcrDTwujWzUMeYFZrQtkfw5CEqTMN8VEQFgZu48k8S2Y4E4kVtOYG 6LnQ== 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=+70s/FrxjUFD9qkdn4BQ4W3R67SG3FLltUeWgaSsaSY=; b=mpU+6cEH59oPMTNfy9EU/cVa1g9BSCEKSapjOPB5SHQUOHIdYgZxQqLcxwpwKXfVBj x0t3TK0Y5lZp3N9ikEEsvu3Ws6GKXlssymv+vt+eNtIxrXimY1deU96DF11dIqaqnUqb YaE+HUSzWmnBfwMFMSMFILdKx+DpDIKc75Y6bfnL1P3PyoIFHFJPwdv+G+nXxmfO6aZv qsoDDSX9xgtR50u4x0puJIwaM/7DWUNTwE3M8m8XTZB5dPNK7Wl7/SNTJzvb39Aoc5TR gTiuNqvua7OceOWH4Zw2vv7H0oZ8TfSczKT5dESZXdUX68sSFZ6aXh0boxzdAOgmGDPD O86g== X-Gm-Message-State: APjAAAUZovi26DXGuX5KWRCMyArpLFIuEJj3L6C3Y2i4swR+pEs3QzrQ 5LovjWwZxOqaEietxdls8Kwsc5YgdTp+4IOBGkE= X-Google-Smtp-Source: APXvYqwOKpz13brzh4jHwHKn68SxoDgymaJvcC8Warv+UBqLVHc0nDNeTxjTHDZHUbhlxZFZG2SceTlJHU5OD83blwg= X-Received: by 2002:a19:2c52:: with SMTP id s79mr14089399lfs.32.1552186570362; Sat, 09 Mar 2019 18:56:10 -0800 (PST) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <38FEBE5B-B60E-49DD-B048-A8A08EBF7FB4@azet.org> In-Reply-To: From: Watson Ladd Date: Sat, 9 Mar 2019 18:55:58 -0800 Message-ID: To: Paul Wouters Cc: Tony Arcieri , trustees@ietf.org, CFRG , "RFC ISE (Adrian Farrel)" , secdir Content-Type: multipart/alternative; boundary="00000000000026d63d0583b499d6" Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 10 Mar 2019 02:56:16 -0000 --00000000000026d63d0583b499d6 Content-Type: text/plain; charset="UTF-8" On Sat, Mar 9, 2019, 6:47 PM Paul Wouters wrote: > On Sat, 9 Mar 2019, Tony Arcieri wrote: > > > Here is the specific wording he is suggesting: > > > > "Phillip Rogaway offers a royalty-free non-exclusive license to all > claims of the referenced patents needed to realize a fully compliant > > implementation of any IETF standards-track protocol supporting AES-OCB > (RFC 7253)." > > > > I think he's looking for guidance around how to properly phrase that if > anyone has a more concrete suggestion for how to put it in the > > form of an IPR statement. > > While this phrasing would solve the issues for some protocols, such as IKE > and IPsec, it is still a request that the IETF publish a cryptographic > standard that cannot be freely used. The IETF normally does not do that > unless there are exceptional reasons to do so. It would be good to see > thse reasons written up for evaluation. > > It would be problematic too if someone using an RFC wouldn't realise > their use of this standard would be in violation of Mr. Rogaway's IPR. > > I also believe allowing OCB for only TLs in the past was a mistake we > should not repeat in a slightly different form by covering a few more > protocols. > > Note also RFC 3979: > > https://tools.ietf.org/html/rfc3979#section-8 > > Over the last few years the IETF has adopted stricter requirements > for some security technologies. It has become common to have a > mandatory-to-implement security technology in IETF technology > specifications. This is to ensure that there will be at least one > common security technology present in all implementations of such a > specification that can be used in all cases. This does not limit the > specification from including other security technologies, the use of > which could be negotiated between implementations. An IETF consensus > has developed that no mandatory-to-implement security technology can > be specified in an IETF specification unless it has no known IPR > claims against it or a royalty-free license is available to > implementers of the specification unless there is a very good reason > to do so. > > As the IETF has been moving towards reducing the number of algorithms, > it would not make sense to promote a new algorithm that can never become > mandatory-to-implement. > I read the above differently: the specification it refers to is not of OCB but the IETF protocol which the IP statement clearly permits royalty free usage and hence OCB is acceptable. > > Maybe it would be good to involve the IETF Trust in this matter? > Paul > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --00000000000026d63d0583b499d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Mar 9, 2019, 6:47 PM Paul Wouters <paul@nohats.ca> wrote:
On Sat, 9 Mar 2019, Tony Arcieri wrote:

> Here is the specific wording he is suggesting:
>
> =C2=A0"Phillip Rogaway offers a royalty-free non-exclusive licens= e to all claims of the referenced patents needed to realize a fully complia= nt
> implementation of any IETF standards-track protocol supporting AES-OCB= (RFC 7253)."
>
> I think he's looking for guidance around how to properly phrase th= at if anyone has a more concrete suggestion for how to put it in the
> form of an IPR statement.

While this phrasing would solve the issues for some protocols, such as IKE<= br> and IPsec, it is still a request that the IETF publish a cryptographic
standard that cannot be freely used. The IETF normally does not do that
unless there are exceptional reasons to do so. It would be good to see
thse reasons written up for evaluation.

It would be problematic too if someone using an RFC wouldn't realise their use of this standard would be in violation of Mr. Rogaway's IPR.<= br>
I also believe allowing OCB for only TLs in the past was a mistake we
should not repeat in a slightly different form by covering a few more
protocols.

Note also RFC 3979:

https://tools.ietf.org/html/rfc3979#section-= 8

=C2=A0 =C2=A0 Over the last few years the IETF has adopted stricter require= ments
=C2=A0 =C2=A0 for some security technologies.=C2=A0 It has become common to= have a
=C2=A0 =C2=A0 mandatory-to-implement security technology in IETF technology=
=C2=A0 =C2=A0 specifications.=C2=A0 This is to ensure that there will be at= least one
=C2=A0 =C2=A0 common security technology present in all implementations of = such a
=C2=A0 =C2=A0 specification that can be used in all cases.=C2=A0 This does = not limit the
=C2=A0 =C2=A0 specification from including other security technologies, the= use of
=C2=A0 =C2=A0 which could be negotiated between implementations.=C2=A0 An I= ETF consensus
=C2=A0 =C2=A0 has developed that no mandatory-to-implement security technol= ogy can
=C2=A0 =C2=A0 be specified in an IETF specification unless it has no known = IPR
=C2=A0 =C2=A0 claims against it or a royalty-free license is available to =C2=A0 =C2=A0 implementers of the specification unless there is a very good= reason
=C2=A0 =C2=A0 to do so.

As the IETF has been moving towards reducing the number of algorithms,
it would not make sense to promote a new algorithm that can never become mandatory-to-implement.

<= /div>
I read the above differently: the specification it r= efers to is not of OCB but the IETF protocol which the IP statement clearly= permits royalty free usage and hence OCB is acceptable.

Maybe it would be good to involve the IETF Trust in this matter?

Paul

_______________________________________________
Cfrg mailing list
Cfrg@= irtf.org
https://www.irtf.org/mailman/listinfo/cfrg<= br>
--00000000000026d63d0583b499d6-- From nobody Sat Mar 9 18:59:34 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 3C1231275E9; Sat, 9 Mar 2019 18:59:28 -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, UNPARSEABLE_RELAY=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 2VTjou2NtBvE; Sat, 9 Mar 2019 18:59:26 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3F44012008A; Sat, 9 Mar 2019 18:59:25 -0800 (PST) Received: from LLE2K16-MBX02.mitll.ad.local (LLE2K16-MBX02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id x2A2xOnC011142; Sat, 9 Mar 2019 21:59:24 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: Paul Wouters , Tony Arcieri CC: CFRG , "RFC ISE (Adrian Farrel)" , secdir Thread-Topic: [Cfrg] [secdir] ISE seeks help with some crypto drafts Thread-Index: AQHU1uuzAFfmxWjKQkGCoWAteDfnZaYELK4A Date: Sun, 10 Mar 2019 02:59:23 +0000 Message-ID: <7F8EC29C-6EA0-4BC1-8D42-C95342465131@ll.mit.edu> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <38FEBE5B-B60E-49DD-B048-A8A08EBF7FB4@azet.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.0.190211 x-originating-ip: [172.25.1.85] Content-Type: text/plain; charset="utf-8" Content-ID: <1F3F8852EF9E9D46BE607E99EA5C59E1@ll.mit.edu> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-10_01:, , 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903100021 Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 10 Mar 2019 02:59:28 -0000 T24gMy85LzIwMTksIDIxOjQ4LCAiQ2ZyZyBvbiBiZWhhbGYgb2YgUGF1bCBXb3V0ZXJzIiA8Y2Zy Zy1ib3VuY2VzQGlydGYub3JnIG9uIGJlaGFsZiBvZiBwYXVsQG5vaGF0cy5jYT4gd3JvdGU6DQog ICAgPiBIZXJlIGlzIHRoZSBzcGVjaWZpYyB3b3JkaW5nIGhlIGlzIHN1Z2dlc3Rpbmc6DQogICAg PiANCiAgICA+ICAiUGhpbGxpcCBSb2dhd2F5IG9mZmVycyBhIHJveWFsdHktZnJlZSBub24tZXhj bHVzaXZlIGxpY2Vuc2UgdG8gYWxsIGNsYWltcyBvZiB0aGUgcmVmZXJlbmNlZCBwYXRlbnRzIG5l ZWRlZCB0byByZWFsaXplIGEgZnVsbHkgY29tcGxpYW50DQogICAgPiBpbXBsZW1lbnRhdGlvbiBv ZiBhbnkgSUVURiBzdGFuZGFyZHMtdHJhY2sgcHJvdG9jb2wgc3VwcG9ydGluZyBBRVMtT0NCIChS RkMgNzI1MykuIg0KICAgID4gDQogICAgPiBJIHRoaW5rIGhlJ3MgbG9va2luZyBmb3IgZ3VpZGFu Y2UgYXJvdW5kIGhvdyB0byBwcm9wZXJseSBwaHJhc2UgdGhhdCBpZiBhbnlvbmUgaGFzIGEgbW9y ZSBjb25jcmV0ZSBzdWdnZXN0aW9uIGZvciBob3cgdG8gcHV0IGl0IGluIHRoZQ0KICAgID4gZm9y bSBvZiBhbiBJUFIgc3RhdGVtZW50Lg0KICAgIA0KICAgIFdoaWxlIHRoaXMgcGhyYXNpbmcgd291 bGQgc29sdmUgdGhlIGlzc3VlcyBmb3Igc29tZSBwcm90b2NvbHMsIHN1Y2ggYXMgSUtFDQogICAg YW5kIElQc2VjLCBpdCBpcyBzdGlsbCBhIHJlcXVlc3QgdGhhdCB0aGUgSUVURiBwdWJsaXNoIGEg Y3J5cHRvZ3JhcGhpYw0KICAgIHN0YW5kYXJkIHRoYXQgY2Fubm90IGJlIGZyZWVseSB1c2VkLiBU aGUgSUVURiBub3JtYWxseSBkb2VzIG5vdCBkbyB0aGF0DQogICAgdW5sZXNzIHRoZXJlIGFyZSBl eGNlcHRpb25hbCByZWFzb25zIHRvIGRvIHNvLiBJdCB3b3VsZCBiZSBnb29kIHRvIHNlZQ0KICAg IHRoc2UgcmVhc29ucyB3cml0dGVuIHVwIGZvciBldmFsdWF0aW9uLg0KDQpJdCAqY2FuKiBiZSAi ZnJlZWx5IHVzZWQiLiBUaGF0J3MgdGhlIHBvaW50IG9mIHVwZGF0aW5nIHRoZSBJUFIgdG8gbWFr ZSBzdXJlIGl0IGlzIHNvLg0KDQpXaGF0IGhhcHBlbnMgdG8gT0NCIHVzZSAqb3V0c2lkZSogb2Yg dGhlIElFVEYgc3RhbmRhcmRzIGlzIGEgc2VwYXJhdGUgcXVlc3Rpb24sIHdoaWNoIEkgZG9uJ3Qg Y2FyZSB0byBlbnRlcnRhaW4gaGVyZSBhbmQgbm93Lg0KLS0NClJlZ2FyZHMsDQpVcmkNCjxTdGFu ZGFyZCBEaXNjbGFpbWVyPg0KDQoNCg== From nobody Sat Mar 9 19:39:48 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 555F61274D0 for ; Sat, 9 Mar 2019 19:39:41 -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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 eggdh4yCMDLF for ; Sat, 9 Mar 2019 19:39:39 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 D7F0512008A for ; Sat, 9 Mar 2019 19:39:38 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44H6Rq5fDBz33S; Sun, 10 Mar 2019 04:39:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1552189175; bh=dlNhUqDuSuJ2T87wqLtKzWHH22iIj/KvLYVIIaQHrFM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=fYGmQ9DJ10AM8SM+ngW0jbkfTZuWpzu/g/mOEi9KFTbO8xTwf9rTYzAhoFxESrszc ZnyDFQJ5AUV8wVQeZf7IQ15wIccmAY/uPEYDDnug/QJIOsfbcIWTc2VkTK/D+lLqrd Pi+zSDntxymkTfEkz59/oKZcPCRQMVhIABVI8Tzg= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id IlRJJxXqXOAk; Sun, 10 Mar 2019 04:39:34 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 10 Mar 2019 04:39:33 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 998455E4BAB; Sat, 9 Mar 2019 22:39:32 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 998455E4BAB Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8B6A24116026; Sat, 9 Mar 2019 22:39:32 -0500 (EST) Date: Sat, 9 Mar 2019 22:39:32 -0500 (EST) From: Paul Wouters To: "Blumenthal, Uri - 0553 - MITLL" cc: CFRG , "RFC ISE (Adrian Farrel)" , secdir In-Reply-To: <7F8EC29C-6EA0-4BC1-8D42-C95342465131@ll.mit.edu> Message-ID: References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <38FEBE5B-B60E-49DD-B048-A8A08EBF7FB4@azet.org> <7F8EC29C-6EA0-4BC1-8D42-C95342465131@ll.mit.edu> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 10 Mar 2019 03:39:41 -0000 On Sun, 10 Mar 2019, Blumenthal, Uri - 0553 - MITLL wrote: > While this phrasing would solve the issues for some protocols, such as IKE > and IPsec, it is still a request that the IETF publish a cryptographic > standard that cannot be freely used. The IETF normally does not do that > unless there are exceptional reasons to do so. It would be good to see > thse reasons written up for evaluation. > > It *can* be "freely used". That's the point of updating the IPR to make sure it is so. > > What happens to OCB use *outside* of the IETF standards is a separate question, which I don't care to entertain here and now. But what does "outside the IETF" mean with respect to draft-krovetz-ocb-wideblock ? It defines a cryptographic blockcipher method, not an internet protocol. Does this mean this cryptographic blockcipher method used in a proprietary or non-IETF standards or IETF experiments falls within or outside the IETF for the purpose of licensing? note I just realised Rich wasn't to blame when pointing me to RFC 7523, instead of 7253, as the actual draft-krovetz-ocb-wideblock-00 makes that mistake) Paul From nobody Sat Mar 9 21:53:42 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 7FBE4127962; Sat, 9 Mar 2019 21:53:34 -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] 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 yqqFGKjExE-w; Sat, 9 Mar 2019 21:53:33 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 0E7B71274D0; Sat, 9 Mar 2019 21:53:33 -0800 (PST) Received: from [10.32.60.82] (1-197.icannmeeting.org [199.91.197.1]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id x2A5prnG094955 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 9 Mar 2019 22:51:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 1-197.icannmeeting.org [199.91.197.1] claimed to be [10.32.60.82] From: "Paul Hoffman" To: "Paul Wouters" Cc: CFRG , trustees@ietf.org, "RFC ISE" , secdir Date: Sun, 10 Mar 2019 14:53:26 +0900 X-Mailer: MailMate (1.12.4r5594) Message-ID: <2D2D04A1-8C54-4DDA-BD5F-84F048C839BE@vpnc.org> In-Reply-To: References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <38FEBE5B-B60E-49DD-B048-A8A08EBF7FB4@azet.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 10 Mar 2019 05:53:35 -0000 On 10 Mar 2019, at 11:47, Paul Wouters wrote: > While this phrasing would solve the issues for some protocols, such as > IKE > and IPsec, it is still a request that the IETF publish a cryptographic > standard that cannot be freely used. That's a fine request, but not really relevant to a thread that is a request from the ISE. --Paul Hoffman From nobody Sat Mar 9 22:09:58 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 C41EC127962; Sat, 9 Mar 2019 22:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=AsaBzclL; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=EoQni3tH 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 3WigKqdoXXPR; Sat, 9 Mar 2019 22:09:55 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C550C126DFA; Sat, 9 Mar 2019 22:09:55 -0800 (PST) Received: from sm-THINK.elandsys.com (50-39-226-71.bvtn.or.frontiernet.net [50.39.226.71]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id x2A69jok022151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Mar 2019 22:09:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1552198192; x=1552284592; bh=2J+JfkULm6izWfnRjBiOhNgdfGwoDDXHdfrImaOuUXs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=AsaBzclLwo4BKnXb6sQj+01FQs8+ALpMxTR4dso5xhZSRj7JUzhaXxLzoxJhRnnY5 bicuhThyir3CzY2CgwbqDUiQjH98kuJuhEZ28/MH2f7IuOC4ux0R67+dW6VSG1tsMl HlfUotEGEzuDBroBvtByPVxZOxkZFwUGERkHYhPs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1552198192; x=1552284592; i=@elandsys.com; bh=2J+JfkULm6izWfnRjBiOhNgdfGwoDDXHdfrImaOuUXs=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=EoQni3tH6bAWATnF8jvJDwri5HgpDyxReUS9nZSiKDiX/ok8JrL1RZpk9kYGFNpLF G1o4oF5qfrjMc1Dw+zi7i4VaZEnXdkaSXHavGO2ZRiknLsBjZHenG3eMstoTPCpEvk R9+iceg6PQLiqo1DzctFYV1jafup4hN/mF6TspVg= Message-Id: <6.2.5.6.2.20190309215613.09d49088@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 09 Mar 2019 22:08:49 -0800 To: Paul Wouters , cfrg@irtf.org From: S Moonesamy Cc: "RFC ISE (Adrian Farrel)" , secdir@ietf.org In-Reply-To: References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <38FEBE5B-B60E-49DD-B048-A8A08EBF7FB4@azet.org> <7F8EC29C-6EA0-4BC1-8D42-C95342465131@ll.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 10 Mar 2019 06:09:57 -0000 Hi Paul, At 07:39 PM 3/9/2019, Paul Wouters wrote: >But what does "outside the IETF" mean with respect to >draft-krovetz-ocb-wideblock ? > >It defines a cryptographic blockcipher method, not an internet protocol. > >Does this mean this cryptographic blockcipher method used in a proprietary >or non-IETF standards or IETF experiments falls within or outside the >IETF for the purpose of licensing? draft-krovetz-ocb-wideblock-00 extends RFC 7253. Both documents are not (IETF) standards. >note I just realised Rich wasn't to blame when pointing me to RFC 7523, >instead of 7253, as the actual draft-krovetz-ocb-wideblock-00 makes that >mistake) The draft should reference RFC 7253 instead of RFC 7523. Regards, S. Moonesamy From nobody Sun Mar 10 11:29:48 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 7F993127873 for ; Sun, 10 Mar 2019 11:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu 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 Z35Mtx8gmRDg for ; Sun, 10 Mar 2019 11:29:43 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780097.outbound.protection.outlook.com [40.107.78.97]) (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 BF9C31240D3 for ; Sun, 10 Mar 2019 11:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o+1pZCFL1qTKMGZuWZbGRWkbcGAYmZkTBsw+2mCgtIc=; b=HPCz3WM1P/SgYOOgLvlTy07jt/gPr8/xfygMdhQc9dVWlnxqrW5s2jttnliJmTazh3I9mZYYaS7jQOGpp5YU8F6n1t/K3ttGMXPCy9wtW2vG8ultVLmFrdRpqkCF5x5ZV2+1RqIQDOEHx1BFpfQfIoRPOx7jjotx4Qjk4nHXLSA= Received: from BL0PR01CA0023.prod.exchangelabs.com (2603:10b6:208:71::36) by MW2PR0102MB3594.prod.exchangelabs.com (2603:10b6:302:6::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.20; Sun, 10 Mar 2019 18:29:42 +0000 Received: from BY2NAM03FT015.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::205) by BL0PR01CA0023.outlook.office365.com (2603:10b6:208:71::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.16 via Frontend Transport; Sun, 10 Mar 2019 18:29:41 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT015.mail.protection.outlook.com (10.152.84.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.19 via Frontend Transport; Sun, 10 Mar 2019 18:29:40 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2AITZ0k007298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 10 Mar 2019 14:29:38 -0400 Date: Sun, 10 Mar 2019 13:29:35 -0500 From: Benjamin Kaduk To: Stephen Farrell CC: CFRG , "RFC ISE (Adrian Farrel)" , secdir Message-ID: <20190310182935.GE8182@kduck.mit.edu> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(136003)(346002)(39860400002)(376002)(2980300002)(199004)(189003)(4326008)(426003)(446003)(336012)(956004)(14444005)(97756001)(8936002)(50466002)(186003)(26005)(104016004)(305945005)(6916009)(86362001)(2906002)(33656002)(8676002)(246002)(6666004)(356004)(229853002)(75432002)(46406003)(36906005)(55016002)(5660300002)(58126008)(316002)(478600001)(16586007)(106466001)(47776003)(53416004)(23726003)(786003)(93886005)(88552002)(26826003)(106002)(486006)(7696005)(476003)(6246003)(126002)(1076003)(76176011)(54906003)(4744005)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR0102MB3594; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9a059f19-9a07-4d15-9d31-08d6a5865c25 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:MW2PR0102MB3594; X-MS-TrafficTypeDiagnostic: MW2PR0102MB3594: X-Microsoft-Exchange-Diagnostics: 1; MW2PR0102MB3594; 20:74wV2+QF2sOOnvKB25XN27gvQEBADJPYzyW9poaDEP+PGwzoTAIuqAVUcMUAPAGHUjjSMMEaUtsCrSWoY8OfuzPXP5Lw1gOn8pq7Unc0rO3o/AgUJLDXi1yTlrE1A4AXGu0RjfYLilc/0GrSx28d5vGGWeYpKnFKNudJgqb06MWmnWAIhlgq0VhP9SHMr+p71yPRHtg6xB2lcrOjTcWEPRCswbRVQbr7gAp27EIiITathbu46Fc7VVURV0orpielJ97wbo7BXCWZkziw0VUVTAQUvtuWJSg9RzsfPlHsjbhbQPCdweMrZa85F9cuAnSzGnRybiEfWolODTR50ChzDT+GAs+w61aNX8AJVqR6SrijYQOElu1kbv5RwaAHT5jha2ZYIG6nuSzUxHspX6b1u5mXW1+zKqdrwLYTI5N7g92sONKpaEuYVgZlv8rxtjKr1kwUMClYeiEXiSzk0kHR4YPq73jNcoNt7d24HuqRqlB06R3yXxsZyzHB1rLLZiOTH9zis6TcGMt0FwuPhHi4ouskHXAbmtMIVs4dm2V8xs11KAzFaR+xlLR4pFNniF/SW1/fZWCCa8ez5sDE+9Mb2S95NZQJCbiZr6zTFbzRNUM= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0972DEC1D9 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MW2PR0102MB3594; 23:HZ+Pj/uDW97wMua1aPXH/74RgT3z8eKF6jinlOn?= =?us-ascii?Q?9GjeD9/C5rBY+XNF+EBBr70dKvyFoysCfJDqGPSXROMQ/ISTGlbJsGSjESN3?= =?us-ascii?Q?y1SOmD2+byT5kJBgLPxY2/ZrFaU/yINuArHMqr3vp0Pq/qRBvnYqiuFOJGNu?= =?us-ascii?Q?Ym3TF+/3ZvU1uKqIKpn0IfaHxnWlUdTg/MWuxz9eWhT24SCD66yihswnVx0s?= =?us-ascii?Q?TuE1gfBGv4nYUqsovSgED99B6UkFnPdMGdtC9KeKdx5rxAeezSoCzSyt4ACr?= =?us-ascii?Q?q+VoHXY6kI5Qf3Wt41cLuCls7XDbWQO2+ogX9VwxrGQ7J6MMreiMK+6OHNm8?= =?us-ascii?Q?4DP22Mgq3II5frZcttKv679Ff4a2Hui7YtHQnmmpm6c5WiJ661WGEN9ykMS8?= =?us-ascii?Q?2WVFvqU9engYnfeEijnLTAF2fkLGYztyAWdhUxsZsNtydtQFR2cpNHNNH9eD?= =?us-ascii?Q?sclH6GmEKEyTexu80Zs6PNsvsDJWpAaciymfowxY+CG8HQxFKb+B0TsGOprF?= =?us-ascii?Q?2I3V5aAg5wA+R9l81aCBsxvz5uI7ja1sEdhF9LeZhpFuYzBtsOdPJNrYn4uF?= =?us-ascii?Q?2eofP57rNuRX+2NekIV5JIpA7CghnaKGxPkmx2xlFo8m2N6zb+rBuTCIomfc?= =?us-ascii?Q?mcQk3aqXbEQFESO4enEm0eAlc0KZvHZmO6txys3X2KxyqdNeOjrYoC03XV7/?= =?us-ascii?Q?N8e/sXio7+NGafw/Ej8JCnt0atOhn9bp/xUpXIDIE70AYWL/lqfCsGvgsDaO?= =?us-ascii?Q?ZgCbLGzQc04IvwcQ+6x7X7DVGN5sX5iZvmv1m01SYHF/X3sEVcaBcscNKbsT?= =?us-ascii?Q?D+lIZHNYJqt9q+6p8CA+rfETutgckLL9ucCgt9Mq4dLNdll4yIkK+bcfIpVS?= =?us-ascii?Q?hAC2QZAsVcKrL6WZj8XQgK2QURYj/94wgfbJdyPRYUxHb5Znot1w/FRyCXPb?= =?us-ascii?Q?EgaooYruzTfcVpiQ7dKWgxI2I7TAa1h+ZX/kfGanfvmcCBEEnvqJIBI/qPq6?= =?us-ascii?Q?wmKkZpOkURFtVet9zxOBM31KBhuMhetuLoxsEnw1EfdSWea6s+lgH04uKUgf?= =?us-ascii?Q?eUw4/7sum6KgARpk/czYVHmdXahoOdnHibGEidYiAm5wm5mUL4RVyDLvnUHP?= =?us-ascii?Q?CO/TW4Ba1SPSRcp2zrIE5XuHIeDlM/9WIj4lgllw5+kvtI147rdLRIPr/FM1?= =?us-ascii?Q?MAHChkZ+vpVw+AN7iCQAk5V4LTkGyoZlTS4MtFw0JWk5iy2TMtxWTRMREM13?= =?us-ascii?Q?yevHZIAuYRye/chGxVKI=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: NtFEvYDKQObT3OCupEF44EPp8vB83hQHFblN/XtAgXL0/ioX7XlCWyTs1TJLpkKDlOTP7Zqy4cTUDViw/b4THZ+G10ikhKWcV65nyJGJcX2jWPdYhQvx3+GSUZpmiPR59RLStbN1YWKXknYnILzhpHmNaz7aHTg4bHwe3w7fUOMohpHQUWwrNhfJcm7whgImbRWHUWlJ1mzjYApXADlRCa0kFpAGMr/gCyjFRKShzgCUyZsf3gk8bA1YFXe7GGTFxsQeldNy1SieFEp8aGLI0Vb/5oiw6z2aA/l8xeYTpaFD/+rXRCzqItg0mjuUp1hN/av2b9K2lK9kY15XoOCbaC2KQMHTA0XPj1gnrVDEAPomQY/vTnyIliK+8oklevuV/QENNYbLJ46mJZpRNQVITEf3GIM9OB8ZUTlNzWEf7ws= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2019 18:29:40.4639 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9a059f19-9a07-4d15-9d31-08d6a5865c25 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR0102MB3594 Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 10 Mar 2019 18:29:46 -0000 On Fri, Mar 08, 2019 at 07:14:56PM +0000, Stephen Farrell wrote: > > FWIW, I'd prefer have fewer and not more modes of operation > documented. I'm not aware of a need for what this draft > appears to specify (based on reading just the abstract). I > also agree the OCB IPR situation isn't clear (IIRC more than > just Rogaway's IPR was involved). > My reading also failed to find a great deal of motivation for needing the new modes. I also found it interesting that the "wideblock" draft also specifies narrow blocks, and that we've had some contentious discussions in the I*TF in the past about narrow-block ciphers. We always need to balance the flexibility of having specifications for new modes against the risk to interoperability of having too many modes. Given what's in these documents at present, my personal sense is that the tradeoff weighs slightly against publishing, but there are many things that could shift that balance. -Ben From nobody Sun Mar 10 11:33:50 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 15292127873; Sun, 10 Mar 2019 11:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7ED0BN97_NhK; Sun, 10 Mar 2019 11:33:47 -0700 (PDT) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) (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 3A3911200ED; Sun, 10 Mar 2019 11:33:46 -0700 (PDT) Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id x2AIXnsa005317; Sun, 10 Mar 2019 14:33:49 -0400 Received: from OC11EXHUB12.exchange.mit.edu (18.9.3.26) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Sun, 10 Mar 2019 14:32:43 -0400 Received: from OC11EXPO28.exchange.mit.edu ([169.254.1.251]) by OC11EXHUB12.exchange.mit.edu ([18.9.3.26]) with mapi id 14.03.0439.000; Sun, 10 Mar 2019 14:33:08 -0400 From: Uri Blumenthal To: Benjamin J Kaduk CC: Stephen Farrell , CFRG , "RFC ISE (Adrian Farrel)" , secdir Thread-Topic: [secdir] [Cfrg] ISE seeks help with some crypto drafts Thread-Index: AQHU1d8we5ehKkr/YUmHIR9Gehv2BKYCboEAgAMHO4CAAAD7AA== Date: Sun, 10 Mar 2019 18:33:07 +0000 Message-ID: <2DBD5391-B8A5-4BDE-AAAB-2ABD89F11DA5@mit.edu> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> In-Reply-To: <20190310182935.GE8182@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-CECB6C4B-3165-4F4A-8270-EC06A0B860B8"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 10 Mar 2019 18:33:49 -0000 --Apple-Mail-CECB6C4B-3165-4F4A-8270-EC06A0B860B8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable For practical use blocks wider than 128 (and probably wider than 256) bits a= re necessary. For analytical work, narrow blocks are needed. Sent from my test iPhone > On Mar 10, 2019, at 14:29, Benjamin Kaduk wrote: >=20 >> On Fri, Mar 08, 2019 at 07:14:56PM +0000, Stephen Farrell wrote: >>=20 >> FWIW, I'd prefer have fewer and not more modes of operation >> documented. I'm not aware of a need for what this draft >> appears to specify (based on reading just the abstract). I >> also agree the OCB IPR situation isn't clear (IIRC more than >> just Rogaway's IPR was involved). >>=20 >=20 > My reading also failed to find a great deal of motivation for needing the > new modes. >=20 > I also found it interesting that the "wideblock" draft also specifies > narrow blocks, and that we've had some contentious discussions in the I*TF > in the past about narrow-block ciphers. >=20 > We always need to balance the flexibility of having specifications for new= > modes against the risk to interoperability of having too many modes. Give= n > what's in these documents at present, my personal sense is that the > tradeoff weighs slightly against publishing, but there are many things tha= t > could shift that balance. >=20 > -Ben >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --Apple-Mail-CECB6C4B-3165-4F4A-8270-EC06A0B860B8 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCGsw ggQkMIICjKADAgECAgRbkXGgMA0GCSqGSIb3DQEBDAUAMBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBS U0EgNDAeFw0xODA5MDYxODI3NDRaFw0yMTA5MDYxODI3NDRaMA4xDDAKBgNVBAMMA1VyaTCCAaIw DQYJKoZIhvcNAQEBBQADggGPADCCAYoCggGBANJi8+lfrSCcWThbn0vQzXsW7AYTyTZSo/pv/274 xD/t1rpn/X/vegP2lSfr+SRJ4oJ+51MFJvRl/sAveroDN8gGrFyYaCg5ZsOMqksCmLha4Ttgk04L I/aqrPGuzF1OVgjhi6WrnFr80KS6sy3MWzYIYV6G1FycKEup5snMr1B1WWzFKOwSslnJwvCuHu2W Tc5OzJKPtxMcDIS9y6VOZTzsJUFe0bRiw0LICDBcB3fgKCvYMcDfke0pw13I4O7wEG40s9E6rTIj Q0H1LVk69pSo1ikzpikl5W8pXUQQrSmjHqhFn/Q+PwSzHSOralN0p1UMziUv57lgvvZbTaH1ooqq MZBuTed0xLye3w+h9+/iqDY4B7lFqbegzseBh7/Q6KdtfpkwwI7xSpZEME/V77KAMw+ipb+Itbij Bi3r/t81fDW8eitIAbVtalpFROlYIaZnIIohOZRyVjn2unZ+lj3jDKsDq53g+oleo+Ruszlt8nju 6uKhzE7bdX1xJuvCtwIDAQABo34wfDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFIDAWBgNV HREEDzANgQt1cmlAbWl0LmVkdTAdBgNVHQ4EFgQU2p+nwSyQFM6byFBhc7oIZephJbcwJQYDVR0l BB4wHAYIKwYBBQUHAwQGCisGAQQBgjcKAwQGBFUdJQAwDQYJKoZIhvcNAQEMBQADggGBAH/zzG9P gU+ogFbc75JpUK0amUUtmtSsGDe4599GolCDiuPHrnbCGcaNc9aQjRaP3Q3aU7BB3aOjwssjQSN0 tsfZD8p+XPny/odhDSwS/25jCg0dVasd8q+Jd1S1g34RGUqPQ+5ofTrBSEkHBdLdJOnxBGo9GRzA yiDg34r6zK6BXNYv2GdqRk+GGGvL/w3CDR+ih36ZDBxw/EO19oH/aV4+mVlcRI6aoj4KMb+h4zMY S8jLDArIZSce4EWzJqxKVcX6Q7CE/0Br/7R8Ixs+vt5YKPUVpEbFM6koH624GDQYKM2kzXBnwYgS /jvl02KUx6uNmIgo+ufK2l7sc83vRLxBTJKhT0/USVkwu9uzg2zHJeGBZ4pmDhkIVkGcamW7KPYZ dgOz8zAOy8Ntk7GebPn85XuPcQS9UntdO61X1EyEXg4Ixl/qapidfJQfdCqEeZZXpaV3WKWE8u1l fNB00mC0/xhG3bikQxl3O20nyPjXvl6VZFzglsPRy1Xh5L//rzCCBD8wggKnoAMCAQICBFuRckIw DQYJKoZIhvcNAQEMBQAwGjEYMBYGA1UEAwwPRm9yZXN0IENBIFJTQSA0MB4XDTE4MDkwNjE4MzAy NloXDTIxMDkwNjE4MzAyNlowDjEMMAoGA1UEAwwDVXJpMIIBojANBgkqhkiG9w0BAQEFAAOCAY8A MIIBigKCAYEAtZvms8stf9xj5w7pjYzgmHe7TH0eX/q3buMBqdLufhFuqCizZPhXJmSbue8WHm8H HO7SHQPUqIqbPOMIQfAL8nwWhuTfsN5nrtFW77eiNsEexRNkbhw/U6RzamCGl6xQmUxOD0nabEmd Xdces+rjtzlvjpNHI7xrR32ee4JuGTjwAWlAHPtBC8TqiOR/ysR2K2umk5BkjCEWV9kDfGklfKmu IhuCzzpTvN3AnLMX9kP9IY6E9B8OsLOhkOFBbAMzyqkXibtPWluqOnYW3V3MVc9H1ir6sGLF5onW lHLEorI51WuHlfVO8WJRYwhrzQIIAWAYheZaH2wdb87Kw6o4JbHDLTDJHHrBDwfqa5OtFTeQNWCD JPdHa4xfFpjnMTzP18POa5C6QN5XBpTFsfccWyEdt+ykGB2FMzhB3GgMVRfWPgo8TgxVwU9MHt8s vmxj8KMUd7afSJBOjMIRPZ6gi8Vja9SR9+Hj/YWgpKZMHhI7irJVpWF++7hhfxxDbgDBAgMBAAGj gZgwgZUwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0RBA8wDYELdXJpQG1pdC5l ZHUwHQYDVR0OBBYEFK3WLENy4CH330dGZEWchN+L1r28MD4GA1UdJQQ3MDUGCCsGAQUFBwMCBggr BgEFBQcDAwYKKwYBBAGCNwoDDAYJKoZIhvcvAQEFBggrBgEFBQcDBDANBgkqhkiG9w0BAQwFAAOC AYEACYbThcFo+JTQNP5UacMtYogWU/yOx5GBLSNNa5cpvoRrOJc9CUDfzfnrd7IhDLXvnFUYNt3i oyU13LKRoPsp/YYuZ2CBI1om9g27SSqqEcOom0eojIKkPNw+sJzYVl7Dz2I7f9DHN6nEC9BeT8Do rjuq67UOlZZw0YvlvCmtMI4xJ7CUM8NrphoeRN18OnbwmkHWIYnYwdxipTJ8oLWi5EbKaUEYyLlC JWd6o9vH8cFNzsViPUl9POxBtX++o5KxtW7/JQwrQt3uFubF6rHQag6HDeXcXSyI0DmL8MrfVtHi Ma2bN+7z8N9Wnuvx8v0qlqfwd+uhmP7OvD32PuzjQxuGyPd43DZazlMhY9IRpSSCPhdbxzS3YwKr jnTZlKGwPiYCmiQ0XSEW3K64Exe4t+jrkBReocr9ccslB4d4XhxQPdAvUdI43xGMbnFea7pyTDyP b0z1vMrYt6dAguU0QTgRZsPFoIldK70ILvncq9amhxuQ4Uw+u2WUXiYba2R1MYICoTCCAp0CAQEw IjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRckIwDQYJYIZIAWUDBAIBBQCggdEwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwMzEwMTgzMzA2WjAvBgkq hkiG9w0BCQQxIgQgH7R3695IwD55VuAieYwpvLFz4NatvqDhstFcdttIYG0wMQYJKwYBBAGCNxAE MSQwIjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRcaAwMwYLKoZIhvcNAQkQAgsxJKAi MBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBSU0EgNAIEW5FxoDANBgkqhkiG9w0BAQEFAASCAYCXYfDa zAwu0rvTLvpOqaIR56l7oLeJrPnLRM2Pu7VrFtjRhLELb5tvqdvMNkMRucKoEFiZLUBDW5jvIuQ4 85kv8TakqRx72d8S3nx5fIX/fjWyoDA98NX55HFj7evrX5SgwnAH7EJD99xi3DqlhnqLiubYlRIL 3P0StZayD9Gcm2DQbgBbDrO/92xXYswxC2JDJl45Exbr96MTQZLElfwl3J9XgPo657Wr+98vFNl7 8Yf+uiUvdnCoelfEN07XaoN9Ok8UcpQ4HqPTSW0xjfKaATXaGg6XsLu2n+GkKF91OmPg4OiJBAN3 7+ZbQenQlJ7oZkyDO1YJ+R0zQ+9CHyZjk3N+R/lFcEwT//z48N/PwoiF6hf0jkrYGRzSiZz3MsVc a0zYLjGF1eEmK/5OPA0ibF7GSQQvGHYTB2kYEg5zTZTSCuDQMbbjLroD0RTBTCmjbmK86r2tSxor 2YcvI+N0sGn6i028I+d0kw51nSHZBzJ3gto0PFWF+TdziXHP3BkAAAAAAAA= --Apple-Mail-CECB6C4B-3165-4F4A-8270-EC06A0B860B8-- From nobody Sun Mar 10 12:05:29 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 C6136127873 for ; Sun, 10 Mar 2019 12:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=krovetz-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 PQ-dyn_lqlyq for ; Sun, 10 Mar 2019 12:05:26 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 C37CC120106 for ; Sun, 10 Mar 2019 12:05:25 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id t82so1947494oie.12 for ; Sun, 10 Mar 2019 12:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krovetz-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=i7/gRWBUbu2n9NQBJob4gZbCI8RHfpyMpeOKomPNssQ=; b=cNDsR6uBRFOrQ0V7A9vMJigiFqqqmCeu36rJ0s9B4kluNaQHU3H7MotzYIlGmrzx5/ NezztXcXoq0FDad0ZYxl2uhc7tYTwSNuHqOLH75wi2lG3DiLhfMTp4RONl/Qu6D6YGde GTIKUsP4loAFj/9U2TSfIgJUTf1tfxJzQbA2dbmeArM3rtNvtvqIJp6XIPvB3ARMrakA yI8i+KhHWk+5fe4vECcRF9yoNTUj6InwEx7RRttTPVUDJB7eLas+ZJv0dvx+NiW+qGqH sVi5EnX+lQKMpGklScDO7ZoFpomyv27MIWpgw78bL2J5LjJ7aY3M/UkR97930KFXO0eB AhdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=i7/gRWBUbu2n9NQBJob4gZbCI8RHfpyMpeOKomPNssQ=; b=Vr46S2zidQqrhSw6FhTzYXZTqNLzQuBvOg7cGz3tHRfD0wVCUJtjun7tPyrSz01KV3 BydDkXtvHsa5vEObu8rJdVwxGQRzA1vN+LTsdNCmyKOoHVmn2/C4m2JZ6vFvsxMeLOeR zZL/rZcN4aBGR/ZSHJJmRNqPhMJIdtNBeNEnybuyXgbhLahmZKW4Gf6j/ZSPo7LBLy01 vaA7qYaXlTwRlET83JjdgiFZkORcS1N81ahJPH/XsrVw47C6d2C5N9H9X87zN/oWAtT+ ICmIAr7KdQ26Kn0iVKTcTTEfaiTaD43CyDX9HOySU4fx6VaaUy+zhkISxANsq5M352AQ Kf5g== X-Gm-Message-State: APjAAAUV4h24/Xf7eQcWcKbC95YG6X75xWwQ4EghAnoh/Gn44O3xnVAF fuqzPQsYeiUdbQAm+fq+2UqEBoqSqtcQ1w== X-Google-Smtp-Source: APXvYqzzssdgpN60v/BBa1oranSeI9yBtO6si1Gp0HVX121qUN8OUtD7j6kv8uEmUK+YF641laZ7HQ== X-Received: by 2002:aca:e608:: with SMTP id d8mr15292964oih.59.1552244725265; Sun, 10 Mar 2019 12:05:25 -0700 (PDT) Received: from ?IPv6:2600:1700:7c70:16a0:250b:88d8:ac6a:95b3? ([2600:1700:7c70:16a0:250b:88d8:ac6a:95b3]) by smtp.gmail.com with ESMTPSA id p187sm1464232oif.17.2019.03.10.12.05.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Mar 2019 12:05:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Ted Krovetz In-Reply-To: <20190310182935.GE8182@kduck.mit.edu> Date: Sun, 10 Mar 2019 12:05:23 -0700 Cc: "RFC ISE (Adrian Farrel)" , secdir Content-Transfer-Encoding: quoted-printable Message-Id: References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> To: CFRG X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 10 Mar 2019 19:05:28 -0000 > On Mar 10, 2019, at 11:29 AM, Benjamin Kaduk wrote: >=20 > failed to find a great deal of motivation for needing the new modes I would like to remind everyone that OCB is not a "new mode". It is = specified in RFC 7253. This work generalizes the specification -- = without changing the 128-bit block case -- to allow other block cipher = block lengths.= From nobody Sun Mar 10 12:10:38 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 74AFF1271FF for ; Sun, 10 Mar 2019 12:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu 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 8AgKBhPN1CQ8 for ; Sun, 10 Mar 2019 12:10:34 -0700 (PDT) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730124.outbound.protection.outlook.com [40.107.73.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A2F126CFF for ; Sun, 10 Mar 2019 12:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xgw82dxv+o9bGt9sU4xXfBb1Zl+C5r+wbejDTNZ0AZI=; b=Cwmf7ZXVt0nQijwc8o8GBULoiXpisHFWIihSmYjUXFD8K60udPv0kgw3tun1Z8Di35bbfOEdKjO1ylqbPHEWJUfPrHpR48MFyQBPERq1AnFEPWUBlRzuEbtSweGtSZgHRv41uhsVnAdfx9+/jbDyW4XoGw13Mea1BFZSMUgJwGw= Received: from SN2PR01CA0021.prod.exchangelabs.com (2603:10b6:804:2::31) by MWHPR01MB2478.prod.exchangelabs.com (2603:10b6:300:3e::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.19; Sun, 10 Mar 2019 19:10:31 +0000 Received: from BY2NAM03FT007.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::206) by SN2PR01CA0021.outlook.office365.com (2603:10b6:804:2::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.17 via Frontend Transport; Sun, 10 Mar 2019 19:10:31 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT007.mail.protection.outlook.com (10.152.84.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.19 via Frontend Transport; Sun, 10 Mar 2019 19:10:30 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2AJARME017299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 10 Mar 2019 15:10:29 -0400 Date: Sun, 10 Mar 2019 14:10:27 -0500 From: Benjamin Kaduk To: Ted Krovetz CC: CFRG , "RFC ISE (Adrian Farrel)" , secdir Message-ID: <20190310191026.GF8182@kduck.mit.edu> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(39860400002)(376002)(346002)(136003)(2980300002)(189003)(199004)(6916009)(8676002)(97756001)(106466001)(58126008)(47776003)(76176011)(7696005)(106002)(476003)(55016002)(478600001)(126002)(316002)(93886005)(88552002)(16586007)(2906002)(486006)(246002)(86362001)(53546011)(229853002)(46406003)(53416004)(54906003)(104016004)(33656002)(23726003)(26005)(1076003)(4326008)(4744005)(356004)(6246003)(50466002)(186003)(5660300002)(75432002)(26826003)(426003)(446003)(786003)(956004)(305945005)(11346002)(8936002)(336012)(36906005); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR01MB2478; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: aad04fc7-d154-4641-f9b9-08d6a58c1088 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4608103)(4709054)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060); SRVR:MWHPR01MB2478; X-MS-TrafficTypeDiagnostic: MWHPR01MB2478: X-Microsoft-Exchange-Diagnostics: 1; MWHPR01MB2478; 20:dNAtkqPArJJ23fbFpUd+t+443S9cBomVtshykXo9Sz5BdWb67CHTk+o7GBfIWXwoXItbTc+wTwxySTyBA06KqAj/knQ9HRWTkwLI+LCNKMD5ydnVTGW1hg3vh7HydElWeFjxJL8LaxB51SOCIntp0dhYshhJsfkbXWWomDLfC0c+SHul/gRLQxMkvBgOdxotYDe5OIVFhTkkdVcXjRuEDH2Ufqy/RBrW+pcSEypVClm+6R/K5rkLY89qAhXFRGGFG03tHwoCUiatfw8aq2zemo6nzKqVzGh9hFQbnenkl7QL1CMRWZR+rEB/+PiQGEfBxh3yjvQ+YaoqopUGle5HuPEd3FeUJ5FbCPm1p9vD9kfcW/RIT930odCv4P7ESCksJEJdfdn2sdBK7DhtkgNiofA7gYW2A7M5hYFdpIN3UgIhtNaWBUbcgRVAsW3XKYa9dfVGAb8NGkI0jec6+GwxPzs5s/0NLoCu7nY83+ez38G0yo+JSONfRi+2lwmyIzXJo/pBNrxcmfowAjxmCLttTiXFFse/F37TTIjF4kRG8odnzEtOcky9jy3vGYGFcrzJs39CcY4xzplzFbwfd181Ig1gh6BevwE7qgWI9DgzOeE= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0972DEC1D9 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR01MB2478; 23:UR21fv7r0svtRAscMkv3NlqIrBmEnNx/Z4T/eWcho?= =?us-ascii?Q?+FwhRCNoFzYG3mrtNkBPP7ytEFi9rmBGA/N/RlJKHkJYFF11UT2jLyzzxP6w?= =?us-ascii?Q?45Eo5inPc9b8wTCs4j91OxYhsFDFJNuTX1aHrI8mLLyp7imtsm1C4IzsStEy?= =?us-ascii?Q?ixH8h0Fun5p0AkMIiNWPvm6ixaaWQvcd30s+6WHtrQ7bPveZ7HSndiI9KG9T?= =?us-ascii?Q?Ah2ggjYrTj6zqwBME3+lkroHSyxCFx9ZpGzVa21EyWFkqnZvx30Tzu1m8fin?= =?us-ascii?Q?aVYEe2aOsci0YKfrvfVPXrme0O+hdXoJ3pSJBoxAiPLuY+Qvt4V9eWv4svuX?= =?us-ascii?Q?Ag71ahV6fDXCXFRVlFcemRtVZV337N612nSzg3klpnnl5nAZziewGsxacyZ6?= =?us-ascii?Q?63P+uq5ulV7Ce+FgNfTF3bvRT8M82BJqNDEEWMJMvSkCT56FLunPVNa3ufmh?= =?us-ascii?Q?tL4EA8YUwHl6vDjsuO2JpvGCCUeiz2SQXId1m6Yn7sPkpTM/ge5F8Yxm2p3Q?= =?us-ascii?Q?7hS0XD9ZNhghWtas0rn6ku26Ka/uzRwni5kkBIaYrSuIVsKPrO2dMvk0q0Ek?= =?us-ascii?Q?I2Ik2whmgFjVd3GEGV3nCU5AUkw4rRC6EAf0KZS55lyUkiyQpYtDPu9GAdE4?= =?us-ascii?Q?TaciIpMDvJQaDwF3Uw+qkufZdTmGamC7sO3+t1Xtp7xjLLivaQDtogCifCQL?= =?us-ascii?Q?mRzX6vJlpQ9uaUvlqg7Qxuz8FyT2BT/Kir31khGu5QdJZ2RlFdMGud0psUbl?= =?us-ascii?Q?H9dprvYZ0zSdbKxPcT1Bho/M628B+6w44odpsi2Etg1eHE//6KBWVLhUCHH8?= =?us-ascii?Q?0ZGeL8rpCe3WECunvsZFO4JOq5CbrzFVHtakQgYk0iOgPCubDx+QRXTbVcx2?= =?us-ascii?Q?hwIGWNTsb2sN3i9gCEjX8Qv4O8tjTyNjZYw/Q/0iLMgEZnR4XWs5lc202g0s?= =?us-ascii?Q?lNw2K/YHR1OP5m1tJ1nQutlS0m23YB7QIA7pzkwWZcIfgsSE3GEDO6epTGyC?= =?us-ascii?Q?Gdzi/sdXF9OQwZC9ya4WsQQx3vs9tScqq2JBSnaaKz0PiabE0vk2H6hLxKXI?= =?us-ascii?Q?xF/CCU3lwbqm/OiaUksDkVe3eDKCFHoyyCa8JCd3Q1pNbBJtv5xjQWjkvIcW?= =?us-ascii?Q?8yLK+wFyOd2u/mvAnyHKBp/L3p20MkIy3kjObFcnQmiLnFi89p0JlNUX8xOL?= =?us-ascii?Q?8+mrDVO36uNITixa0uXDMYDq+gK1hrKJLxWuSfRKmV9jDJgsSuOkQUf+LUDJ?= =?us-ascii?Q?0xxv44rULH4IAStG04=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: 4OUxIPb6D+t4a9uqcvp7/fvYezNnttYYbV5lx2J+XoLd5jgydJYHq6Mfa5ZLVg30ZVsafqLjZdTOi7tkK75+a9W519of40G5QQtmKmHnnEUz1TAKDNBeurHmrQDfvjV5XzTcXbArnfhXHn1ufqYUyHJSdBEtGCY8KN4TbPtnov64znKuBPhBDokDv5ZS8Hkw/N0INrsQie6GRvyRltYh8ufahK7NaiGLWOLJLpntRX1DUSF+RuU9n6O8NgcswQ0u1SHNxSoj2A3xnpIsxeDrgBIJeS78OcggMYAUofXg2R/zyJe1SDpcYeSqRl17kKke0T/dP8wfvVYvoVN/uxs5BzgH7DQNBPt37sUzKosZ2gcsllhx0RzrEqm+lAT3hTrty1kGR4LKQ8FNXdPNCFPDIyGxdea4cFunEkx4TJx68Ws= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Mar 2019 19:10:30.6672 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: aad04fc7-d154-4641-f9b9-08d6a58c1088 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR01MB2478 Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 10 Mar 2019 19:10:37 -0000 On Sun, Mar 10, 2019 at 12:05:23PM -0700, Ted Krovetz wrote: > > > > On Mar 10, 2019, at 11:29 AM, Benjamin Kaduk wrote: > > > > failed to find a great deal of motivation for needing the new modes > > I would like to remind everyone that OCB is not a "new mode". It is specified in RFC 7253. This work generalizes the specification -- without changing the 128-bit block case -- to allow other block cipher block lengths. It's still a "distinct choice that a protocol designer (or user) picking a cipher has available to choose from", which is where the perceived downside of new things comes from. My apologies for conflating the technical term with the generic. -Ben From nobody Sun Mar 10 13:58:09 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 EEC59128664 for ; Sun, 10 Mar 2019 13:58:06 -0700 (PDT) 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, 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 (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 9udZhLBxc2m1 for ; Sun, 10 Mar 2019 13:58:05 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0: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 1F751127B50 for ; Sun, 10 Mar 2019 13:58:05 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id t7so2237269otk.8 for ; Sun, 10 Mar 2019 13:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b/05oVhudrIJR1Bl6fNddF80sKaiBb6hl2/IBVEeirY=; b=aWCLO87OlNYtxDAHqKZRuOHtA2hEwzfS7Up9ZvG+FFLu4FSyQ0STfjO6jMW8wEO89G x6QT1ddgizjobQrWRCtzXPmCPmzpnN1mnLIyd0k1RrfDMD6zlfbEWKoLByVnLimYcir3 oW9dL5veLNH7/wxOkC4BT9guQ62QN8VCGHdFDcPW0MWB32LRVGnzxQT9ebE3cqWz9uDv bdFDunVdBAg1QejJC2B+pdzBKuS2GXGy+IVI+4gbU1FkQ0jbPhUbnK5vg8Hu1HaBnajd DtdbDGjjSgslJc0v7fWlOPUWV0+pZrr7AOdnHFMRuWdOANJ9gkIT5EH75csGsqW2HpxL chpg== 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=b/05oVhudrIJR1Bl6fNddF80sKaiBb6hl2/IBVEeirY=; b=JAr7TCUFXrY83S3SPErneY/4k5aJ0Q/0yGy3ZFW0BHolyaHvP0ESE9H+fPWV8esQAs TEdCt//q0X+kw31B6nmzW+lyHGrwkb+Lq/BclxEZhfj/zS8ifyd17ponLxHgM9R/Dxq2 mhU2CLURoTV4VhEvuqp8xrJ3VCiisFnOq2D7IBdbQFZFOcpPdfhBTkrwQV2cPY/zOfQi tcSM5dKPCZA4xPtBcyE75RYgerb0uI6lW03i8qeNjqj/cKnnBpfEjL+npKOsbz97eru/ 8EBG4cDXFpew8BKrghegivs+T4ililkl33F2wceU7AtnLj7D0USPrE8PrEBCCgfgQJAK ysEg== X-Gm-Message-State: APjAAAWflQwngEhiV6lF0qvIQ6OI9nGBH1rGUHfPGVpeKrYRTMqVcT/S pBqxeZfm73XJIeybzrUOjRDAFDRUS3xYxFv0xc8= X-Google-Smtp-Source: APXvYqwPjCFKm5apVlEr9f2P4s4h98rmAqKJawxlHIgScHePn2yNH8oA5MV1fj9rhsk8E7UcMO2QrV33K3hRrLfaTC0= X-Received: by 2002:a9d:5616:: with SMTP id e22mr18834204oti.365.1552251484139; Sun, 10 Mar 2019 13:58:04 -0700 (PDT) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> In-Reply-To: <20190310191026.GF8182@kduck.mit.edu> From: Tony Arcieri Date: Sun, 10 Mar 2019 13:57:53 -0700 Message-ID: To: Benjamin Kaduk Cc: Ted Krovetz , CFRG , "RFC ISE (Adrian Farrel)" , secdir Content-Type: multipart/alternative; boundary="0000000000005076370583c3b665" Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 10 Mar 2019 20:58:07 -0000 --0000000000005076370583c3b665 Content-Type: text/plain; charset="UTF-8" On Sun, Mar 10, 2019 at 12:10 PM Benjamin Kaduk wrote: > > I would like to remind everyone that OCB is not a "new mode". It is > specified in RFC 7253. This work generalizes the specification -- without > changing the 128-bit block case -- to allow other block cipher block > lengths. > > It's still a "distinct choice that a protocol designer (or user) picking a > cipher has available to choose from", which is where the perceived downside > of new things comes from. My apologies for conflating the technical term > with the generic. I think there are significant compelling reasons to prefer OCB mode over pretty much all other existing modes: - Recent CAESAR winner (one of many in the portfolio, but) - Fast anywhere AES is fast. No CLMUL required (good for embedded) - Well-studied: IMO OCB is more likely than not be covered in classes/textbooks on symmetric cryptography I think the IPR concerns are the main reason it has not seen more widespread adoption. If you were to ask me "Is it better than AES-GCM?", my answer is yes. OCB hits the sweet spot of being a construction which is "fast everywhere", as opposed to the split between AES-GCM and AES-CCM we see between desktops/servers/high-end mobile vs embedded devices. The wide block modes are a different question. I think they're potentially interesting in use cases I'm not particularly familiar with (e.g. mixnets). I'm not going to be the one to champion those through the CFRG, though. That said, the inability to use OCB mode in IETF protocols (due to IPR concerns) is a travesty, and hopefully one we can clear up. -- Tony Arcieri --0000000000005076370583c3b665 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Mar 10, 2019 at 12:10 PM Benjamin= Kaduk <kaduk@mit.edu> wrote:
> I would like to remind everyone that OCB is not a "new= mode". It is specified in RFC 7253. This work generalizes the specifi= cation -- without changing the 128-bit block case -- to allow other block c= ipher block lengths.

It's still a "distinct choice that a protocol designer (or user) p= icking a
cipher has available to choose from", which is where the perceived dow= nside
of new things comes from.=C2=A0 My apologies for conflating the technical t= erm
with the generic.

I think there are signifi= cant compelling reasons to prefer OCB mode over pretty much all other exist= ing modes:

- Recent CAESAR winner (one of many in = the portfolio, but)
- Fast anywhere AES is fast. No CLMUL require= d (good for embedded)
- Well-studied: IMO OCB is more likely than= not be covered in classes/textbooks on symmetric cryptography
I think the IPR concerns are the main reason it has not seen m= ore widespread adoption.

If you were to ask me &qu= ot;Is it better than AES-GCM?", my answer is yes. OCB hits the sweet s= pot of being a construction which is "fast everywhere", as oppose= d to the split between AES-GCM and AES-CCM we see between desktops/servers/= high-end mobile vs embedded devices.

The wide bloc= k modes are a different question. I think they're potentially interesti= ng in use cases I'm not particularly familiar with (e.g. mixnets). I= 9;m not going to be the one to champion those through the CFRG, though.

That said, the inability to use OCB mode in IETF prot= ocols (due to IPR concerns) is a travesty, and hopefully one we can clear u= p.

--
Tony Arcieri
--0000000000005076370583c3b665-- From nobody Sun Mar 10 14:42:49 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 7AE081277E6; Sun, 10 Mar 2019 14:42:47 -0700 (PDT) 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, HTML_MESSAGE=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 cXxBBSP72AV7; Sun, 10 Mar 2019 14:42:45 -0700 (PDT) Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.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 5AADA127287; Sun, 10 Mar 2019 14:42:45 -0700 (PDT) Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id x2ALhFC1027022; Sun, 10 Mar 2019 17:43:36 -0400 Received: from W92EXHUB14.exchange.mit.edu (18.7.73.25) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Sun, 10 Mar 2019 17:41:28 -0400 Received: from OC11EXPO28.exchange.mit.edu ([169.254.1.251]) by W92EXHUB14.exchange.mit.edu ([18.7.73.25]) with mapi id 14.03.0439.000; Sun, 10 Mar 2019 17:41:53 -0400 From: Uri Blumenthal To: Tony Arcieri CC: Benjamin J Kaduk , Ted Krovetz , CFRG , "RFC ISE (Adrian Farrel)" , secdir Thread-Topic: [secdir] [Cfrg] ISE seeks help with some crypto drafts Thread-Index: AQHU1d8we5ehKkr/YUmHIR9Gehv2BKYCboEAgAMHO4CAAAoAgIAAAWuAgAAeBICAAAxIgA== Date: Sun, 10 Mar 2019 21:41:52 +0000 Message-ID: <2B472CCB-4414-41FB-8806-E18D916C73F7@mit.edu> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-ECEB2413-2B79-4DBA-B8F4-90B00E4DB708"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 10 Mar 2019 21:42:47 -0000 --Apple-Mail-ECEB2413-2B79-4DBA-B8F4-90B00E4DB708 Content-Type: multipart/alternative; boundary=Apple-Mail-75C04E4A-6B51-4374-B3DB-4E674A9944E5 Content-Transfer-Encoding: 7bit --Apple-Mail-75C04E4A-6B51-4374-B3DB-4E674A9944E5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Completely agree with your OCB points. It looks like the IPR issues would be= resolved fairly quickly. As for the wideblock mods - I'm perfectly willing to champion it at CFRG, if= a champion is needed. As I said, while it's not likely to apply to, e g., T= LS 1.4 - there are use cases today, and I expect to see more in the future.= Sent from my test iPhone > On Mar 10, 2019, at 16:58, Tony Arcieri wrote: >=20 >> On Sun, Mar 10, 2019 at 12:10 PM Benjamin Kaduk wrote: >=20 >> > I would like to remind everyone that OCB is not a "new mode". It is spe= cified in RFC 7253. This work generalizes the specification -- without chang= ing the 128-bit block case -- to allow other block cipher block lengths. >>=20 >> It's still a "distinct choice that a protocol designer (or user) picking a= >> cipher has available to choose from", which is where the perceived downsi= de >> of new things comes from. My apologies for conflating the technical term= >> with the generic. >=20 > I think there are significant compelling reasons to prefer OCB mode over p= retty much all other existing modes: >=20 > - Recent CAESAR winner (one of many in the portfolio, but) > - Fast anywhere AES is fast. No CLMUL required (good for embedded) > - Well-studied: IMO OCB is more likely than not be covered in classes/text= books on symmetric cryptography >=20 > I think the IPR concerns are the main reason it has not seen more widespre= ad adoption. >=20 > If you were to ask me "Is it better than AES-GCM?", my answer is yes. OCB h= its the sweet spot of being a construction which is "fast everywhere", as op= posed to the split between AES-GCM and AES-CCM we see between desktops/serve= rs/high-end mobile vs embedded devices. >=20 > The wide block modes are a different question. I think they're potentially= interesting in use cases I'm not particularly familiar with (e.g. mixnets).= I'm not going to be the one to champion those through the CFRG, though. >=20 > That said, the inability to use OCB mode in IETF protocols (due to IPR con= cerns) is a travesty, and hopefully one we can clear up. >=20 > -- > Tony Arcieri > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --Apple-Mail-75C04E4A-6B51-4374-B3DB-4E674A9944E5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPkNvbXBsZXRlbHkg YWdyZWUgd2l0aCB5b3VyIE9DQiBwb2ludHMuIEl0IGxvb2tzIGxpa2UgdGhlIElQUiBpc3N1ZXMg d291bGQgYmUgcmVzb2x2ZWQgZmFpcmx5IHF1aWNrbHkuPGRpdj48YnI+PC9kaXY+PGRpdj5BcyBm b3IgdGhlIHdpZGVibG9jayBtb2RzIC0gSSdtIHBlcmZlY3RseSB3aWxsaW5nIHRvIGNoYW1waW9u IGl0IGF0IENGUkcsIGlmIGEgY2hhbXBpb24gaXMgbmVlZGVkLiAmbmJzcDtBcyBJIHNhaWQsIHdo aWxlIGl0J3Mgbm90IGxpa2VseSB0byBhcHBseSB0bywgZSBnLiwgVExTICZuYnNwOzEuNCAtIHRo ZXJlIGFyZSB1c2UgY2FzZXMgdG9kYXksIGFuZCBJIGV4cGVjdCB0byBzZWUgbW9yZSBpbiB0aGUg ZnV0dXJlLjxicj48YnI+PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIiBkaXI9Imx0ciI+U2Vu dCBmcm9tIG15IHRlc3QgaVBob25lPC9kaXY+PGRpdiBkaXI9Imx0ciI+PGJyPk9uIE1hciAxMCwg MjAxOSwgYXQgMTY6NTgsIFRvbnkgQXJjaWVyaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJhc2N1bGVA Z21haWwuY29tIj5iYXNjdWxlQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+PC9kaXY+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdiBkaXI9Imx0ciI+PG1ldGEgaHR0cC1lcXVpdj0i Q29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxkaXYgZGly PSJsdHIiPjxkaXYgZGlyPSJsdHIiPk9uIFN1biwgTWFyIDEwLCAyMDE5IGF0IDEyOjEwIFBNIEJl bmphbWluIEthZHVrICZsdDs8YSBocmVmPSJtYWlsdG86a2FkdWtAbWl0LmVkdSI+a2FkdWtAbWl0 LmVkdTwvYT4mZ3Q7IHdyb3RlOjxicj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAu OGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDox ZXgiPiZndDsgSSB3b3VsZCBsaWtlIHRvIHJlbWluZCBldmVyeW9uZSB0aGF0IE9DQiBpcyBub3Qg YSAibmV3IG1vZGUiLiBJdCBpcyBzcGVjaWZpZWQgaW4gUkZDIDcyNTMuIFRoaXMgd29yayBnZW5l cmFsaXplcyB0aGUgc3BlY2lmaWNhdGlvbiAtLSB3aXRob3V0IGNoYW5naW5nIHRoZSAxMjgtYml0 IGJsb2NrIGNhc2UgLS0gdG8gYWxsb3cgb3RoZXIgYmxvY2sgY2lwaGVyIGJsb2NrIGxlbmd0aHMu PGJyPg0KPGJyPg0KSXQncyBzdGlsbCBhICJkaXN0aW5jdCBjaG9pY2UgdGhhdCBhIHByb3RvY29s IGRlc2lnbmVyIChvciB1c2VyKSBwaWNraW5nIGE8YnI+DQpjaXBoZXIgaGFzIGF2YWlsYWJsZSB0 byBjaG9vc2UgZnJvbSIsIHdoaWNoIGlzIHdoZXJlIHRoZSBwZXJjZWl2ZWQgZG93bnNpZGU8YnI+ DQpvZiBuZXcgdGhpbmdzIGNvbWVzIGZyb20uJm5ic3A7IE15IGFwb2xvZ2llcyBmb3IgY29uZmxh dGluZyB0aGUgdGVjaG5pY2FsIHRlcm08YnI+DQp3aXRoIHRoZSBnZW5lcmljLjwvYmxvY2txdW90 ZT48ZGl2Pjxicj48L2Rpdj48ZGl2PkkgdGhpbmsgdGhlcmUgYXJlIHNpZ25pZmljYW50IGNvbXBl bGxpbmcgcmVhc29ucyB0byBwcmVmZXIgT0NCIG1vZGUgb3ZlciBwcmV0dHkgbXVjaCBhbGwgb3Ro ZXIgZXhpc3RpbmcgbW9kZXM6PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4tIFJlY2VudCBDQUVT QVIgd2lubmVyIChvbmUgb2YgbWFueSBpbiB0aGUgcG9ydGZvbGlvLCBidXQpPC9kaXY+PGRpdj4t IEZhc3QgYW55d2hlcmUgQUVTIGlzIGZhc3QuIE5vIENMTVVMIHJlcXVpcmVkIChnb29kIGZvciBl bWJlZGRlZCk8L2Rpdj48ZGl2Pi0gV2VsbC1zdHVkaWVkOiBJTU8gT0NCIGlzIG1vcmUgbGlrZWx5 IHRoYW4gbm90IGJlIGNvdmVyZWQgaW4gY2xhc3Nlcy90ZXh0Ym9va3Mgb24gc3ltbWV0cmljIGNy eXB0b2dyYXBoeTwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSB0aGluayB0aGUgSVBSIGNvbmNl cm5zIGFyZSB0aGUgbWFpbiByZWFzb24gaXQgaGFzIG5vdCBzZWVuIG1vcmUgd2lkZXNwcmVhZCBh ZG9wdGlvbi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PklmIHlvdSB3ZXJlIHRvIGFzayBtZSAi SXMgaXQgYmV0dGVyIHRoYW4gQUVTLUdDTT8iLCBteSBhbnN3ZXIgaXMgeWVzLiBPQ0IgaGl0cyB0 aGUgc3dlZXQgc3BvdCBvZiBiZWluZyBhIGNvbnN0cnVjdGlvbiB3aGljaCBpcyAiZmFzdCBldmVy eXdoZXJlIiwgYXMgb3Bwb3NlZCB0byB0aGUgc3BsaXQgYmV0d2VlbiBBRVMtR0NNIGFuZCBBRVMt Q0NNIHdlIHNlZSBiZXR3ZWVuIGRlc2t0b3BzL3NlcnZlcnMvaGlnaC1lbmQgbW9iaWxlIHZzIGVt YmVkZGVkIGRldmljZXMuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgd2lkZSBibG9jayBt b2RlcyBhcmUgYSBkaWZmZXJlbnQgcXVlc3Rpb24uIEkgdGhpbmsgdGhleSdyZSBwb3RlbnRpYWxs eSBpbnRlcmVzdGluZyBpbiB1c2UgY2FzZXMgSSdtIG5vdCBwYXJ0aWN1bGFybHkgZmFtaWxpYXIg d2l0aCAoZS5nLiBtaXhuZXRzKS4gSSdtIG5vdCBnb2luZyB0byBiZSB0aGUgb25lIHRvIGNoYW1w aW9uIHRob3NlIHRocm91Z2ggdGhlIENGUkcsIHRob3VnaC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2PlRoYXQgc2FpZCwgdGhlIGluYWJpbGl0eSB0byB1c2UgT0NCIG1vZGUgaW4gSUVURiBwcm90 b2NvbHMgKGR1ZSB0byBJUFIgY29uY2VybnMpIGlzIGEgdHJhdmVzdHksIGFuZCBob3BlZnVsbHkg b25lIHdlIGNhbiBjbGVhciB1cC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pi0tPGJyPjwvZGl2 PjwvZGl2PjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9zaWduYXR1cmUiPlRvbnkgQXJjaWVy aTxicj48L2Rpdj48L2Rpdj4NCjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJj aXRlIj48ZGl2IGRpcj0ibHRyIj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+PHNwYW4+c2VjZGlyIG1haWxpbmcgbGlzdDwvc3Bh bj48YnI+PHNwYW4+PGEgaHJlZj0ibWFpbHRvOnNlY2RpckBpZXRmLm9yZyI+c2VjZGlyQGlldGYu b3JnPC9hPjwvc3Bhbj48YnI+PHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zZWNkaXIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2VjZGlyPC9hPjwvc3Bhbj48YnI+PHNwYW4+d2lraTogPGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL2FyZWEvc2VjL3RyYWMvd2lraS9TZWNEaXJSZXZpZXciPmh0dHA6Ly90b29scy5p ZXRmLm9yZy9hcmVhL3NlYy90cmFjL3dpa2kvU2VjRGlyUmV2aWV3PC9hPjwvc3Bhbj48YnI+PC9k aXY+PC9ibG9ja3F1b3RlPjwvZGl2PjwvYm9keT48L2h0bWw+ --Apple-Mail-75C04E4A-6B51-4374-B3DB-4E674A9944E5-- --Apple-Mail-ECEB2413-2B79-4DBA-B8F4-90B00E4DB708 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCGsw ggQkMIICjKADAgECAgRbkXGgMA0GCSqGSIb3DQEBDAUAMBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBS U0EgNDAeFw0xODA5MDYxODI3NDRaFw0yMTA5MDYxODI3NDRaMA4xDDAKBgNVBAMMA1VyaTCCAaIw DQYJKoZIhvcNAQEBBQADggGPADCCAYoCggGBANJi8+lfrSCcWThbn0vQzXsW7AYTyTZSo/pv/274 xD/t1rpn/X/vegP2lSfr+SRJ4oJ+51MFJvRl/sAveroDN8gGrFyYaCg5ZsOMqksCmLha4Ttgk04L I/aqrPGuzF1OVgjhi6WrnFr80KS6sy3MWzYIYV6G1FycKEup5snMr1B1WWzFKOwSslnJwvCuHu2W Tc5OzJKPtxMcDIS9y6VOZTzsJUFe0bRiw0LICDBcB3fgKCvYMcDfke0pw13I4O7wEG40s9E6rTIj Q0H1LVk69pSo1ikzpikl5W8pXUQQrSmjHqhFn/Q+PwSzHSOralN0p1UMziUv57lgvvZbTaH1ooqq MZBuTed0xLye3w+h9+/iqDY4B7lFqbegzseBh7/Q6KdtfpkwwI7xSpZEME/V77KAMw+ipb+Itbij Bi3r/t81fDW8eitIAbVtalpFROlYIaZnIIohOZRyVjn2unZ+lj3jDKsDq53g+oleo+Ruszlt8nju 6uKhzE7bdX1xJuvCtwIDAQABo34wfDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFIDAWBgNV HREEDzANgQt1cmlAbWl0LmVkdTAdBgNVHQ4EFgQU2p+nwSyQFM6byFBhc7oIZephJbcwJQYDVR0l BB4wHAYIKwYBBQUHAwQGCisGAQQBgjcKAwQGBFUdJQAwDQYJKoZIhvcNAQEMBQADggGBAH/zzG9P gU+ogFbc75JpUK0amUUtmtSsGDe4599GolCDiuPHrnbCGcaNc9aQjRaP3Q3aU7BB3aOjwssjQSN0 tsfZD8p+XPny/odhDSwS/25jCg0dVasd8q+Jd1S1g34RGUqPQ+5ofTrBSEkHBdLdJOnxBGo9GRzA yiDg34r6zK6BXNYv2GdqRk+GGGvL/w3CDR+ih36ZDBxw/EO19oH/aV4+mVlcRI6aoj4KMb+h4zMY S8jLDArIZSce4EWzJqxKVcX6Q7CE/0Br/7R8Ixs+vt5YKPUVpEbFM6koH624GDQYKM2kzXBnwYgS /jvl02KUx6uNmIgo+ufK2l7sc83vRLxBTJKhT0/USVkwu9uzg2zHJeGBZ4pmDhkIVkGcamW7KPYZ dgOz8zAOy8Ntk7GebPn85XuPcQS9UntdO61X1EyEXg4Ixl/qapidfJQfdCqEeZZXpaV3WKWE8u1l fNB00mC0/xhG3bikQxl3O20nyPjXvl6VZFzglsPRy1Xh5L//rzCCBD8wggKnoAMCAQICBFuRckIw DQYJKoZIhvcNAQEMBQAwGjEYMBYGA1UEAwwPRm9yZXN0IENBIFJTQSA0MB4XDTE4MDkwNjE4MzAy NloXDTIxMDkwNjE4MzAyNlowDjEMMAoGA1UEAwwDVXJpMIIBojANBgkqhkiG9w0BAQEFAAOCAY8A MIIBigKCAYEAtZvms8stf9xj5w7pjYzgmHe7TH0eX/q3buMBqdLufhFuqCizZPhXJmSbue8WHm8H HO7SHQPUqIqbPOMIQfAL8nwWhuTfsN5nrtFW77eiNsEexRNkbhw/U6RzamCGl6xQmUxOD0nabEmd Xdces+rjtzlvjpNHI7xrR32ee4JuGTjwAWlAHPtBC8TqiOR/ysR2K2umk5BkjCEWV9kDfGklfKmu IhuCzzpTvN3AnLMX9kP9IY6E9B8OsLOhkOFBbAMzyqkXibtPWluqOnYW3V3MVc9H1ir6sGLF5onW lHLEorI51WuHlfVO8WJRYwhrzQIIAWAYheZaH2wdb87Kw6o4JbHDLTDJHHrBDwfqa5OtFTeQNWCD JPdHa4xfFpjnMTzP18POa5C6QN5XBpTFsfccWyEdt+ykGB2FMzhB3GgMVRfWPgo8TgxVwU9MHt8s vmxj8KMUd7afSJBOjMIRPZ6gi8Vja9SR9+Hj/YWgpKZMHhI7irJVpWF++7hhfxxDbgDBAgMBAAGj gZgwgZUwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0RBA8wDYELdXJpQG1pdC5l ZHUwHQYDVR0OBBYEFK3WLENy4CH330dGZEWchN+L1r28MD4GA1UdJQQ3MDUGCCsGAQUFBwMCBggr BgEFBQcDAwYKKwYBBAGCNwoDDAYJKoZIhvcvAQEFBggrBgEFBQcDBDANBgkqhkiG9w0BAQwFAAOC AYEACYbThcFo+JTQNP5UacMtYogWU/yOx5GBLSNNa5cpvoRrOJc9CUDfzfnrd7IhDLXvnFUYNt3i oyU13LKRoPsp/YYuZ2CBI1om9g27SSqqEcOom0eojIKkPNw+sJzYVl7Dz2I7f9DHN6nEC9BeT8Do rjuq67UOlZZw0YvlvCmtMI4xJ7CUM8NrphoeRN18OnbwmkHWIYnYwdxipTJ8oLWi5EbKaUEYyLlC JWd6o9vH8cFNzsViPUl9POxBtX++o5KxtW7/JQwrQt3uFubF6rHQag6HDeXcXSyI0DmL8MrfVtHi Ma2bN+7z8N9Wnuvx8v0qlqfwd+uhmP7OvD32PuzjQxuGyPd43DZazlMhY9IRpSSCPhdbxzS3YwKr jnTZlKGwPiYCmiQ0XSEW3K64Exe4t+jrkBReocr9ccslB4d4XhxQPdAvUdI43xGMbnFea7pyTDyP b0z1vMrYt6dAguU0QTgRZsPFoIldK70ILvncq9amhxuQ4Uw+u2WUXiYba2R1MYICoTCCAp0CAQEw IjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRckIwDQYJYIZIAWUDBAIBBQCggdEwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwMzEwMjE0MTUxWjAvBgkq hkiG9w0BCQQxIgQgTrsMNEddm+jYx2KMr7KA57kHjczOdrkmEggHDZtIJI0wMQYJKwYBBAGCNxAE MSQwIjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRcaAwMwYLKoZIhvcNAQkQAgsxJKAi MBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBSU0EgNAIEW5FxoDANBgkqhkiG9w0BAQEFAASCAYAKx/vR KCoThkNqsDZ+YdVL3OyJkFx5qSIpmrmpdJEcr0bOrg6jz50sbnjiAjnDxACNpEwswnyCQZwOg3vR X/EvJlpRkX75YSyF72nNPUY6S7RdAKyywzbNyqNSJrmZ0UvqxlfQfOp/fav38//30ND1A8yERlhH 2Up22tn1VelA6L/XALRSW+WeKP1l/gCfT9WBVVG7DQz5Z2K5M92KaX/6/3TyzssqyQkw9kuorkbp o0uqVjPqSfRjZWt0jJCf0XTA6Fkw8jfDlriWjWJ6BZyWw3my5sFO0CDVZvw3QY4Cc65QFf8MhNdq PWzL0i31o1S/Md24jAViM7vkUg4Gdg1jw6nXh60jhgje2XJJu/N1bNdF0IeyuLGi5dkhAMbjwe73 AYbPyV9pUzLFT5QhKORx+jEyxipo7akQF+Xbf467Mbc+7xcv7S3ISpvh1L/rka6sAuD0RYoezLcT L6V5oKQGDZpnorymmJN2LjYXeIV0AsLsMRKMLrlV0EOtpoTSWHUAAAAAAAA= --Apple-Mail-ECEB2413-2B79-4DBA-B8F4-90B00E4DB708-- From nobody Sun Mar 10 14:47:37 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 0213E127287 for ; Sun, 10 Mar 2019 14:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjIOuwDHg08W for ; Sun, 10 Mar 2019 14:47:28 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E451127978 for ; Sun, 10 Mar 2019 14:47:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 45967BE3E; Sun, 10 Mar 2019 21:47:25 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3SxyhPCIyxz; Sun, 10 Mar 2019 21:47:23 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B4AAFBE38; Sun, 10 Mar 2019 21:47:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1552254443; bh=iYUDwpwPyu5lwIfWzNP0arL25PEU3l61boOHkxigq8g=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=blyXF57cL/sKU4kwEeigk+afCO8WR4D0jjentfZQeS10Eg1aboISu82j+Uyph1I0B YqRLseaz76ZTUoaB59H4LKEXXlHErG+E15w0p1X8DQmZzwFNNqUmlM2BHWfK/jx61z IHQ/uTqOCTzqdZ6GWhtstMQObsofYa+wrgCB8EA4= To: Tony Arcieri , Benjamin Kaduk Cc: CFRG , "RFC ISE (Adrian Farrel)" , secdir References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> Date: Sun, 10 Mar 2019 21:47:22 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AQMoB7MdZnkIr7Lpd3nOItAb2XiVBfEdQ" Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 10 Mar 2019 21:47:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AQMoB7MdZnkIr7Lpd3nOItAb2XiVBfEdQ Content-Type: multipart/mixed; boundary="K7lNEVyMSzfxEdgugZd26nPcH0MI0qzyL"; protected-headers="v1" From: Stephen Farrell To: Tony Arcieri , Benjamin Kaduk Cc: CFRG , "RFC ISE (Adrian Farrel)" , secdir Message-ID: <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> Subject: Re: [Cfrg] [secdir] ISE seeks help with some crypto drafts References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> In-Reply-To: --K7lNEVyMSzfxEdgugZd26nPcH0MI0qzyL Content-Type: multipart/mixed; boundary="------------7DACC8CBADA45462A5C4D49A" Content-Language: en-GB This is a multi-part message in MIME format. --------------7DACC8CBADA45462A5C4D49A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 10/03/2019 20:57, Tony Arcieri wrote: >=20 > I think there are significant compelling reasons to prefer OCB mode=20 > over pretty much all other existing modes: FWIW, I don't, because we're not dealing with a clean slate. In the IETF context, whether or not OCB is a bit better then currently deployed modes is not an interesting question. One interesting question might be: is OCB so much better that it could we displace uses of some existing mode with OCB. That seems unlikely to me for the widely used modes. Another interesting question might be: is OCB so much better that we want to deploy it alongside current modes. I don't see the overall benefit of that myself. So even though I'm happy to accept that OCB has better properties than e.g. GCM, I don't think it's so much better that RFCs for it are that useful. That said, if the RFC for such a thing said "this is nice for brand new stuff (although library support will be less comprehensive) but is not worth the costs associated with adding it to existing protocols" then I'd be less against such RFCs being produced. Understandably enough, that kind of statement doesn't get added to such RFCs;-) S. PS: In case the ISE is still listening, the above is a reason why I think having CFRG produce this kind of RFC (instead of routing 'em via the ISE) would be a better plan. CFRG could (I think) likely reach better informed judgements (in the open) as to whether or not some crypto technique is really worth documenting in an RFC. --------------7DACC8CBADA45462A5C4D49A Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------7DACC8CBADA45462A5C4D49A-- --K7lNEVyMSzfxEdgugZd26nPcH0MI0qzyL-- --AQMoB7MdZnkIr7Lpd3nOItAb2XiVBfEdQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyFheoACgkQWrL68XsX K+pf1Q/+Pe5R0dNepkMWw1GT6uVxEmpboDYdE/nHuRN+LB9836cDcQqvXYhELAOA nNbd/s8RtSlxoj+vb3TfjXPUxsvxLqZMSvtvEaq8lBAQdI2UAfvLKgXV7YtngyHq g/Ow2xYkdXYnzOAvAfg/Y7W2nk3dDyxkA+iQ6YJjuYBq38lSX/Z57l+Qi2EY6I0P G83odmGYjeR5hFxTa7viyT81NfTZxYPb6Orrivqg0HOxVaUGCF5PAbrwsTk21Ki/ B92/Q1lAzGhaklgyxkHhayMxq26iAXob3noeJoOx70WhPgvkZSzCH0PolofgCL7A dw352r4j4uGIv81Msuhoe/EqQHD1bwLj18+mO92APWlQlojJ2WxKHZ6coLz9zVuB BTQB/j71P/XIAqnilE/Hjrxaubs8goZ62Stv1fccYSdab8JUYwWK0bZs6ZjeaRsF JKLef0YCGdL3MD/26xTa7u0Fu7M1OeOHgs0t1wB64oK8+AJZUufCuWlXwmtJb38X d6RacmAh40nuFmHUBpfCyjXxo1h5RjTRF8flW40tzs85hOrjG9in8Ud+ygXUbD5T pkZ8w71BgqcD7Iy+Q9URBiUW1Y4nWTakviiZqSrCF484z/OyUhA8oD3f8DyKTT6m cDZyR6B+QlDdGnOc5WEo12K7Mkw72/GHNn1D9z+uqorpSC232pc= =0TQE -----END PGP SIGNATURE----- --AQMoB7MdZnkIr7Lpd3nOItAb2XiVBfEdQ-- From nobody Sun Mar 10 15:30:35 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 9BA9F1277E2; Sun, 10 Mar 2019 15:30:26 -0700 (PDT) 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, UNPARSEABLE_RELAY=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 EdZij2-URTX0; Sun, 10 Mar 2019 15:30:24 -0700 (PDT) Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) by ietfa.amsl.com (Postfix) with ESMTP id 00A0F124408; Sun, 10 Mar 2019 15:30:23 -0700 (PDT) Received: from LLE2K16-MBX01.mitll.ad.local (LLE2K16-MBX01.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTP id x2AMUIKD001502; Sun, 10 Mar 2019 18:30:18 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Stephen Farrell CC: Tony Arcieri , Benjamin Kaduk , CFRG , "RFC ISE (Adrian Farrel)" , secdir Thread-Topic: [Cfrg] [secdir] ISE seeks help with some crypto drafts Thread-Index: AQHU14QevAW3fcLXj0aQOImPmtGJg6YFqbQAgAAL/QA= Date: Sun, 10 Mar 2019 22:30:17 +0000 Message-ID: References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> In-Reply-To: <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 Content-Type: multipart/signed; boundary="Apple-Mail-F1FD1687-15BF-4297-B98B-9F84CA24E00E"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-10_19:, , 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903100173 Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 10 Mar 2019 22:30:27 -0000 --Apple-Mail-F1FD1687-15BF-4297-B98B-9F84CA24E00E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Stephen, I think the answer to all of your "interesting questions" is yes, IMHO.=20 IMHO, the main reason it did not fly high back then was it's IPR - but that'= s been addressed for some protocols (e.g., TLS), and is being addressed now f= or wider IETF adoption. Regards, Uri Sent from my iPhone > On Mar 10, 2019, at 17:48, Stephen Farrell wro= te: >=20 >=20 > Hiya, >=20 >> On 10/03/2019 20:57, Tony Arcieri wrote: >>=20 >> I think there are significant compelling reasons to prefer OCB mode=20 >> over pretty much all other existing modes: >=20 > FWIW, I don't, because we're not dealing with a clean slate. >=20 > In the IETF context, whether or not OCB is a bit better > then currently deployed modes is not an interesting > question. >=20 > One interesting question might be: is OCB so much better > that it could we displace uses of some existing mode with > OCB. That seems unlikely to me for the widely used modes. >=20 > Another interesting question might be: is OCB so much > better that we want to deploy it alongside current modes. > I don't see the overall benefit of that myself. >=20 > So even though I'm happy to accept that OCB has better > properties than e.g. GCM, I don't think it's so much > better that RFCs for it are that useful. >=20 > That said, if the RFC for such a thing said "this is nice > for brand new stuff (although library support will be less > comprehensive) but is not worth the costs associated > with adding it to existing protocols" then I'd be less > against such RFCs being produced. Understandably enough, > that kind of statement doesn't get added to such RFCs;-) >=20 > S. >=20 > PS: In case the ISE is still listening, the above is a > reason why I think having CFRG produce this kind of RFC > (instead of routing 'em via the ISE) would be a better > plan. CFRG could (I think) likely reach better informed > judgements (in the open) as to whether or not some crypto > technique is really worth documenting in an RFC. >=20 >=20 > <0x5AB2FAF17B172BEA.asc> > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail-F1FD1687-15BF-4297-B98B-9F84CA24E00E Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITojCCBLww ggOkoAMCAQICASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe Fw0xMzEyMTcwMDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gc KS9SlQRfqMW8F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUif Semk671G+mNZKLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NP Js/oW6YpHF5gmNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICa HIHO+VBDlA01Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFll Q5F/AgMBAAGjggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN /c9G3sjHEofKvzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMC AYYwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8/TExSQ0EwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8E LDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYow gYcwDQYLKoZIhvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcS AgEDAQkwDQYLKoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZI hvcSAgEDAQ8wDQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFqu MBzuLKeFwMSBbB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF /M+H3h1v9kneqXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsT kfrbLLErVY8+BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCi pAwj3wzMNh4s6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+Dba vUxXxFHU+S2Myw06w98wggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNV BAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcNMjAxMjMxMjM1OTU5WjBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw EQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18 tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jFvBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5o vvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8li hUixePbxWad1m7ZMKKagvm9zTybP6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+ yDz8Jzk6sP9iilgP3iXSGoCAmhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9 dtb05cy1gXAFSP3Z/iUkxyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHQ4EFgQU12BmDntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3y EMND7SkwDgYDVR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov L2NybC5sbC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t aXQuZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0GCyqG SIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0G CyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBBQUA A4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/LTCxqULjOd+H+HTqM JXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZcEEgOWC9bHcrElzU6Nni gahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbTiHe7DqfWQ2tVMLUf23XYhIua 94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r/aMsPAKx6nMaOvRL7Cy0Pjp51i2q FkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPfMIIE7TCCA9WgAwIBAgIKMziUjwAAAABu ljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAz OVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh Ym9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1 ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9 AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIws l5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK 1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpK SFq80SEh6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGe kpQVubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0G CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGG G2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiD g+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVy aUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBTAFcwDQYJ KoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaF H5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lc osfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4i vIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/p HKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mLMLqGNX3azAkwggUtMIIEFaADAgEC AgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwHhcN MTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSswKQYDVQQDEyJCbHVtZW50aGFs LlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA g+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oLToMnJQ6phCIkQGplPsM+9Ppz Icw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSNAB8WG3L+6a3mHcp9yYumPkdt M20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p6umBCLGxZi0cGhBI/7ZyJmJU Uo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857MF4OcehpG7LuxufD0p+g02uX7 Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCCAeYwHQYDVR0OBBYEFPbiFDP7 1vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBTXYGYOe0mNdUwN/c9G 3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3AwPQYJKwYB BAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhYHgQIbXxk0CAWQCAQkw LAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsGAQUFBwMCMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5lZHWgJgYKKwYBBAGCNxQCA6AY DBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQgHh4ATABMAE0AbwBiAGkAbABl AFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1DkfqhBA4LYklB+i49k6dh7L+n DEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1RjH8vLNFOEV8ZVcNxbWC5DiA 6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AOLm42Gn4lLeNrY4Ex8nq2Ah3x jB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G/HyJg9MUukKq23qm6Ys0VJQc JsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9Dszxz7LQECXI0KrPpM7x32Su lMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBM YWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCChp0xCAAAAAArQMw CQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTkwMzEwMjIzMDE2WjAjBgkqhkiG9w0BCQQxFgQUfr8RtoUTgwHhcuIJARCF/JK2D4YwbgYJKwYB BAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgozOJSPAAAAAG6WMHAGCyqGSIb3 DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgozOJSPAAAAAG6WMA0GCSqGSIb3 DQEBAQUABIIBAAvj6emi6vJaIj6ENLmWZOtwpMXdMQpIr7vSAHWYXm0IkL7e8Poxd2X5eqPuIfnT AAge3CzTScFHR7i+DGEhUKz4NGkjzPv0BP8vqppKpDFvEEmXeAmUWzMTAvdu0lM7oVEOLmRbnRuz XgTKoBEyxMOkkX+PPTuEm3uhwp5phnqsYb3IUIKRBrz/mh1RVppdL5NhM4BiyIwXcSYEdW4nY8mN 2j6bNLLlvjd2+eAMRm2B2pjCe6pMktgX783iGS5AGHp1PL8/Wh1fqfyws1AVyC4VZFGNYGGynVDI V+k28/uHgsqTOF4mmo7fp01CW/4ktoxEWUirEAabeYz5TjtNIMYAAAAAAAA= --Apple-Mail-F1FD1687-15BF-4297-B98B-9F84CA24E00E-- From nobody Sun Mar 10 15:31: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 C2578130DF6 for ; Sun, 10 Mar 2019 15:31:27 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 Kd60A9Oqn37i for ; Sun, 10 Mar 2019 15:31:25 -0700 (PDT) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (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 2E7DC12AF7D for ; Sun, 10 Mar 2019 15:31:25 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id t206so2179115oib.3 for ; Sun, 10 Mar 2019 15:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XMICp+NbPh2S4La/ri43Q8T3NLbQXZHSdF7ISVBTgQ0=; b=PMP+C+RSLd1zMyzbbxmVM5NaCx4QRfJxllQ2smHqXSSgeCGPTUvcci4O7muCE+KumG e6lxrn8udE+ZKwfx4pCgGQj/SjRyYyno0Wm9a14HA3YMKQ2HGL0KADEE84nc6pRe8f41 d/KuoCZZjFI+sgC5SM8BkjcAkoocQjrPThIXpa16onOW4FaRSuBWl5tmoRUHHUmZ+QUm 3qFUXw40jy+DCOLkMYwcXmsq+GKIXa5kubuZVpZHO/KwGbMS3eP3xhT6rG8W39NT5sS9 +xuxMIox+GDLD7/b9a4oG93PegU9IYwZTBTpfdXWZPm5TxX8vT1rk/NioJ/YPg6E8hrk cWRQ== 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=XMICp+NbPh2S4La/ri43Q8T3NLbQXZHSdF7ISVBTgQ0=; b=MJEj/iSOzUgbvyT8Sbzmlf4Pv1TxqqCKhkgQaRpT17BHgp5zX9JShdqq5OGzxEl8s0 OpjQj2skflgu0D1K33MNWEe4Wzj6Y+h3aT1yyRyhvkIHlZa4r4WnQRb+9f2KDt+XsDav wRj6fMgZ9dRwCMUCMOa8ed9JLOTLBhQN6MTM95DmpP+fzaicjiI8YG16FBnmxYIL9w+f qs51LaFoOqEaFdnrPZY6nWLbniCXaiwoamKmXJuAvPui61aT8K+b7kFmiMUT6QYIQahP /pgvtEQGnZp38EOoSwuBn1CmI3ikEh3ZlCyIioYIJ0J9HAm6Ec289wy6QhWUy+ltQEmv 2DpA== X-Gm-Message-State: APjAAAXL3oVACwoeEB30DlEa7Dv7DjFZMrB10ikPub7haXxDRr/88o7Z jGjP6W3n8hSxPfQe038yOLkIT9aq1KS38+O07ZmjCQ== X-Google-Smtp-Source: APXvYqyIAk/mVXiM7WBxckV690df8cP3d8o9aoA/hPhe/FZzF1ZaMzFCMk3TItA4P0ObANrToHjHjtzRhFWtpxRqpeo= X-Received: by 2002:aca:f546:: with SMTP id t67mr14464643oih.152.1552257084378; Sun, 10 Mar 2019 15:31:24 -0700 (PDT) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> In-Reply-To: <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> From: Tony Arcieri Date: Sun, 10 Mar 2019 15:31:12 -0700 Message-ID: To: Stephen Farrell Cc: Benjamin Kaduk , CFRG , "RFC ISE (Adrian Farrel)" , secdir Content-Type: multipart/alternative; boundary="0000000000001d55a60583c50402" Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 10 Mar 2019 22:31:34 -0000 --0000000000001d55a60583c50402 Content-Type: text/plain; charset="UTF-8" On Sun, Mar 10, 2019 at 2:47 PM Stephen Farrell wrote: > One interesting question might be: is OCB so much better > that it could we displace uses of some existing mode with > OCB. That seems unlikely to me for the widely used modes. > > Another interesting question might be: is OCB so much > better that we want to deploy it alongside current modes. > I don't see the overall benefit of that myself. > > So even though I'm happy to accept that OCB has better > properties than e.g. GCM, I don't think it's so much > better that RFCs for it are that useful. Let me provide some context here with a survey of existing modes and explain why OCB is interesting: - AES-GCM: exceedingly common on desktop/laptop/server-class computers and high-end mobile phones. Provides performance roughly equivalent to the underlying AES function on these devices, provided they have a superscalar architecture and have (P)CLMUL(QDQ) units which can be used in parallel with the units that perform AES - AES-CCM: exceedingly common in the embedded space. This is due in part to two things: FIPS regulations and the number of embedded devices they apply to (smartcards and other security tokens, as well as things like HSMs), but also because embedded CPUs/uCs generally will perform quite poorly at AES-GCM - ChaCha20+Poly1305: extremely simple authenticated encryption based in a tiny core ARX primitive for encryption and universal hashing for authentication. Extremely fast in software, but slower than hardware accelerated primitives These modes have a sort of triangle of tradeoffs: - AES-GCM is fast if and only if you have a superscalar CPU with both hardware AES and CLMUL - AES-CCM is fast (faster than ChaCha20Poly1305) if you have hardware accelerated AES, but runs the AES encryption twice as many times as AES-GCM, and has a non-parallelizable encryption function - ChaCha20Poly1305 is faster than AES-GCM on devices that do not have CLMUL support, but slower than AES-CCM on devices which have hardware AES support Hardware AES support has been steadfastly improving over many years and is available in all but the cheapest microcontrollers (i.e. even where there are cheap uCs without it, there is often a "crypto accelerator" model of the same uC which does). When hardware AES is available, OCB "squares the triangle" so to speak, and provides a sort of force multiplier where the other modes have tradeoffs. For new protocols which are shooting for "ubiquitous deployment", i.e. targeting servers/laptops/desktops, mobile phones, *and* the embedded space, and want one mode that "works well everywhere", this makes OCB an ideal candidate. It'd be good to handle the cases that hardware AES isn't available, and also have a "fallback cipher" on the outside chance some horrible cryptanalysis disaster befalls OCB, so you'd still want to pair it with ChaCha20+Poly1305 as a backup cipher. That said, for those protocols who would rather simplify cipher selection rather than having a backup card in their pocket, OCB is a particularly attractive mode for "One True Ciphersuite" (a.k.a. 1TCS) protocols. --0000000000001d55a60583c50402 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Mar 10, 2019 at 2:47 PM Stephen F= arrell <stephen.farrell@cs.= tcd.ie> wrote:
One interesting question might be: is OCB so much better
that it could we displace uses of some existing mode with
OCB. That seems unlikely to me for the widely used modes.

Another interesting question might be: is OCB so much
better that we want to deploy it alongside current modes.
I don't see the overall benefit of that myself.

So even though I'm happy to accept that OCB has better
properties than e.g. GCM, I don't think it's so much
better that RFCs for it are that useful.

Le= t me provide some context here with a survey of existing modes and explain = why OCB is interesting:

- AES-GCM: exceedingly com= mon on desktop/laptop/server-class computers and high-end mobile phones. Pr= ovides performance roughly equivalent to the underlying AES function on the= se devices, provided they have a superscalar architecture and have (P)CLMUL= (QDQ) units which can be used in parallel with the units that perform AES
- AES-CCM: exceedingly common in the embedded space. This is due i= n part to two things: FIPS regulations and the number of embedded devices t= hey apply to (smartcards and other security tokens, as well as things like = HSMs), but also because embedded CPUs/uCs generally will perform quite poor= ly at AES-GCM
- ChaCha20+Poly1305: extremely simple authenticated= encryption based in a tiny core ARX primitive for encryption and universal= hashing for authentication. Extremely fast in software, but slower than ha= rdware accelerated primitives

These modes have a s= ort of triangle of tradeoffs:

- AES-GCM is fast if= and only if you have a superscalar CPU with both hardware AES and CLMUL
- AES-CCM is fast (faster than ChaCha20Poly1305) if you have hardwa= re accelerated AES, but runs the AES encryption twice as many times as AES-= GCM, and has a non-parallelizable encryption function
- ChaCha20P= oly1305 is faster than AES-GCM on devices that do not have CLMUL support, b= ut slower than AES-CCM on devices which have hardware AES support

Hardware AES support has been steadfastly improving over ma= ny years and is available in all but the cheapest microcontrollers (i.e. ev= en where there are cheap uCs without it, there is often a "crypto acce= lerator" model of the same uC which does).

Wh= en hardware AES is available, OCB "squares the triangle" so to sp= eak, and provides a sort of force multiplier where the other modes have tra= deoffs.

For new protocols which are shooting for &= quot;ubiquitous deployment", i.e. targeting servers/laptops/desktops, = mobile phones, *and* the embedded space, and want one mode that "works= well everywhere", this makes OCB an ideal candidate.

It'd be good to handle the cases that hardware AES isn't a= vailable, and also have a "fallback cipher" on the outside chance= some horrible cryptanalysis disaster befalls OCB, so you'd still want = to pair it with ChaCha20+Poly1305 as a backup cipher. That said, for those = protocols who would rather simplify cipher selection rather than having a b= ackup card in their pocket, OCB is a particularly attractive mode for "= ;One True Ciphersuite" (a.k.a. 1TCS) protocols.
--0000000000001d55a60583c50402-- From nobody Sun Mar 10 15:45:45 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 3604512782C for ; Sun, 10 Mar 2019 15:45:30 -0700 (PDT) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.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 VY1EHPGNVKEq for ; Sun, 10 Mar 2019 15:45:27 -0700 (PDT) Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) (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 6FBDC12AF7A for ; Sun, 10 Mar 2019 15:45:21 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id y15so1236468wro.4 for ; Sun, 10 Mar 2019 15:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wJhMqChnBhqc7zoQW5WYQGjKAZVIrV5WmUJv1MXuHh4=; b=bX4VKKsmbBnSp5ici9miN+kOoACzK8gvW5CLx0pSw6n8oJoN5fAG08ZCq6zpjIidRE A2vLWPQrz3t4jMPawC9VyjkgAlIwa400la32VFo1+7HbVWFXaJBMOuA3E+E2GBduBGVL HwrW7NNnph3tHi2ohHL7QvVfSn37zwA9InufrW6sc9vQACSr0QPjNkP+UC3KsxotbAK1 qsvobHq0UHzYbPRKJis4Ei5rURAetVVc3Xi1HcigjS2zsS5+OcpWXB5lFt/puYffr0/1 lidzhkeBx0Vz17W81anw7JNKjbr4grwJHro7Q3w+MNppRV4BCpHnukXyhzYtXpkeErZJ 7W2w== 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=wJhMqChnBhqc7zoQW5WYQGjKAZVIrV5WmUJv1MXuHh4=; b=pf3OtrZhL7EIFl+KwEjdDlpAOQY6TkaC6VWpDH/JvjYKwHjfi//CJB5WbutpzNqhxu NWpRzoJd2IY6FJRONaWhYimc92I1RXljV3nWOLoiOVlS0p5lxdIV10eRVK9xBnP3rFNc WN8w03zVGKPILsdA0vjgEddKIa54bTe08tZxlXk0aQkiEGCH2nEDaWII0w+7twC0Qbeo CokpclCqZUuxmNDHV6fVsjD7iKdXTMsrvW0Lu3gxL17ZjFvY6Bp5PC+SN52QCjrRP2ps olkdQtgIAp0lQ2pOJ3mhq4Dqot8a5guq9UDDSqjwNw8areR3/s1PcqBSLGEMnYlout6Q /Ynw== X-Gm-Message-State: APjAAAUi0VQRe6Tk+pTc/gTAI+6dj4KtRwF3rm933tdBWzmS3g9bjcX7 Kcj9i5YsgLHxaENb1VK2/jitcyex4/LgLrgUjAgvWA== X-Google-Smtp-Source: APXvYqwXAk6M8lC2GdkneJzRcEKE83JejQK60iFqOAGY1CFntlYk9JvyBr5V1yRzvYb/3KKg/5c9g+/aRbcYq98fLnE= X-Received: by 2002:adf:812a:: with SMTP id 39mr18482132wrm.48.1552257919821; Sun, 10 Mar 2019 15:45:19 -0700 (PDT) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> In-Reply-To: <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> From: "StJohns, Michael" Date: Sun, 10 Mar 2019 18:45:08 -0400 Message-ID: To: Stephen Farrell Cc: CFRG , "RFC ISE (Adrian Farrel)" , secdir Content-Type: multipart/alternative; boundary="000000000000e939280583c535ba" Archived-At: Subject: [secdir] Time to recharter CFRG as a working group? Was: Re: [Cfrg] ISE seeks help with some crypto drafts 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, 10 Mar 2019 22:45:42 -0000 --000000000000e939280583c535ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99ve been wondering for a while now whether it=E2=80=99s time to mo= ve the CFRG over to the IETF as a working group. Stephen=E2=80=99s comment on routing stuff directly to the CFRG suggests to me that it=E2=80=99s probably time or RSN. In recent years, the CFRG has produced documents that are for lack of a better phrase de facto standards. The rate of document production of the CFRG mimics more closely that of a WG than the other extant RGs AFAICT. As an RG the CFRG isn=E2=80=99t permitted to publish standards track docume= nts, nor is the IESG or the ISE permitted or constrained to require a conflict review on the documents the CFRG does produce. [the latter comment is my understanding of the rules of the research stream - it may be flawed, but the purpose of RGs is supposed to be looking at futures and that by definition shouldn=E2=80=99t be conflicting with the nows]. An alternative might be to charter a crypto standards WG and try to keep the CFRG focused on years out - say how the heck do we deal with the quantum apocalypse? Or keep the math in CFRG and the on the wire specs for using in a WG. Discuss! Mike On Sun, Mar 10, 2019 at 17:48 Stephen Farrell wrote: > > Hiya, > > On 10/03/2019 20:57, Tony Arcieri wrote: > > > > I think there are significant compelling reasons to prefer OCB mode > > over pretty much all other existing modes: > > FWIW, I don't, because we're not dealing with a clean slate. > > In the IETF context, whether or not OCB is a bit better > then currently deployed modes is not an interesting > question. > > One interesting question might be: is OCB so much better > that it could we displace uses of some existing mode with > OCB. That seems unlikely to me for the widely used modes. > > Another interesting question might be: is OCB so much > better that we want to deploy it alongside current modes. > I don't see the overall benefit of that myself. > > So even though I'm happy to accept that OCB has better > properties than e.g. GCM, I don't think it's so much > better that RFCs for it are that useful. > > That said, if the RFC for such a thing said "this is nice > for brand new stuff (although library support will be less > comprehensive) but is not worth the costs associated > with adding it to existing protocols" then I'd be less > against such RFCs being produced. Understandably enough, > that kind of statement doesn't get added to such RFCs;-) > > S. > > PS: In case the ISE is still listening, the above is a > reason why I think having CFRG produce this kind of RFC > (instead of routing 'em via the ISE) would be a better > plan. CFRG could (I think) likely reach better informed > judgements (in the open) as to whether or not some crypto > technique is really worth documenting in an RFC. > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --000000000000e939280583c535ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I=E2=80=99ve been wondering for a while now whether = it=E2=80=99s time to move the CFRG over to the IETF as a working group.=C2= =A0 Stephen=E2=80=99s comment on routing stuff directly to the CFRG suggest= s to me that it=E2=80=99s probably time or RSN.=C2=A0

=C2=A0 =C2=A0In recent years, the CFRG has pr= oduced documents that are for lack of a better phrase de facto standards.= =C2=A0 The rate of document production of the CFRG mimics more closely that= of a WG than the other extant RGs AFAICT. =C2=A0 As an RG the CFRG isn=E2= =80=99t permitted to publish standards track documents, nor is the IESG or = the ISE permitted or constrained to require a conflict review on the docume= nts the CFRG does produce. =C2=A0[the latter comment is my understanding of= the rules of the research stream - it may be flawed, but the purpose of RG= s is supposed to be looking at futures and that by definition shouldn=E2=80= =99t be conflicting with the nows]. =C2=A0
An alternative might be to charter a crypto standa= rds WG and try to keep the CFRG focused on years out - say how the heck do = we deal with the quantum apocalypse?

Or keep the math in CFRG and the on the wire specs for using i= n a WG. =C2=A0



Discuss!

Mike

On Sun, Mar 10, 2019 at 17:48 Step= hen Farrell <stephen.farrel= l@cs.tcd.ie> wrote:

Hiya,

On 10/03/2019 20:57, Tony Arcieri wrote:
>
> I think there are significant compelling reasons to prefer OCB mode > over pretty much all other existing modes:

FWIW, I don't, because we're not dealing with a clean slate.

In the IETF context, whether or not OCB is a bit better
then currently deployed modes is not an interesting
question.

One interesting question might be: is OCB so much better
that it could we displace uses of some existing mode with
OCB. That seems unlikely to me for the widely used modes.

Another interesting question might be: is OCB so much
better that we want to deploy it alongside current modes.
I don't see the overall benefit of that myself.

So even though I'm happy to accept that OCB has better
properties than e.g. GCM, I don't think it's so much
better that RFCs for it are that useful.

That said, if the RFC for such a thing said "this is nice
for brand new stuff (although library support will be less
comprehensive) but is not worth the costs associated
with adding it to existing protocols" then I'd be less
against such RFCs being produced. Understandably enough,
that kind of statement doesn't get added to such RFCs;-)

S.

PS: In case the ISE is still listening, the above is a
reason why I think having CFRG produce this kind of RFC
(instead of routing 'em via the ISE) would be a better
plan. CFRG could (I think) likely reach better informed
judgements (in the open) as to whether or not some crypto
technique is really worth documenting in an RFC.


_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
--000000000000e939280583c535ba-- From nobody Sun Mar 10 16:20:22 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 10B901275F3 for ; Sun, 10 Mar 2019 16:20:15 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 2Ze0fG_oQCuR for ; Sun, 10 Mar 2019 16:20:12 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 9C945126C87 for ; Sun, 10 Mar 2019 16:20:12 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id e15so2394915otk.6 for ; Sun, 10 Mar 2019 16:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ay02M+MW3ApP58/RV9kiAGFzjxMmoMPTxlAa4WB6vdo=; b=SxJvxLE9bw3f2LKhleCjKBeU0y6wGHX+lDzC7Tuz1ER5w00Cj1Zsuo6ABmavGXGTo0 XZcXyNeBUbsU8AEOcJF/XErNVN5R7ErfrlVz/fWg5HxbzlMfnlBQ3x7RFjh6U0sLJa+o 24HAS2Anozy282IfEw8sejqbJ2q34JHtpJEU0B2tZHqKV+rVhEMXN0ogBsER/h0sQHMb TvGabO3GNrikoQGxU/VbMT3zhPK9EpP1LCGbjfax+gzGUVM9S4GVTnXSOZ3YeFLvJAPQ W3REwcDbbDDPhMWKaXtU/eBmyhV53n3j6r+Ka3cAZ8AuKQzNtD37/o1PH3epz1yLU6m1 qtSQ== 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=ay02M+MW3ApP58/RV9kiAGFzjxMmoMPTxlAa4WB6vdo=; b=c0m/3iaBL6lIc+l+F5kQjKgJYa2ZAb7OIT73TPrIaAHFEtlzbeuc4PkBVGA2rRF1m8 4GxSYtkq4vUb9CuNUwBVmyaWOqqQPCdWTzOgw17U8XrDozRM2LpfBslkL/gfA7gbz+ye BwQAswn75iXKufF2fkvT39itDP9cjKIpwCVkYCVn8sK01BR6VbOcy4iifiwvhTPzxRrw 6qymDMOeWjpXkr1add72FKhcDhg6245kYFQCisTAvYdjxFlpBl/Uf+pyaUGBY914mS7J BnWxNsOMqRHkO9aotRZIQgYYYkbhAUP0acWXpD5y60e5UHPMQAAT5eowO/SLSyHKKTZM yO3A== X-Gm-Message-State: APjAAAVEST0b30/iGfGnsX6sC6rjLyoFjVDxl8nf07ydk531iK2ON9pi YjZ4KZWdE9YByeGDJUQ09eT9BI3eQWSoL0DKZAJusPll X-Google-Smtp-Source: APXvYqxcpyHhjyp5qr9sjQQRsxJaU+SMAjKehOejLdpTF0SJlP9v91RnUndizHNjP38ZNUqsBMM86y9qB0JJ+5k3QWc= X-Received: by 2002:a9d:3e41:: with SMTP id h1mr20104682otg.170.1552260011798; Sun, 10 Mar 2019 16:20:11 -0700 (PDT) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> In-Reply-To: From: Tony Arcieri Date: Sun, 10 Mar 2019 16:20:01 -0700 Message-ID: To: "StJohns, Michael" Cc: Stephen Farrell , CFRG , "RFC ISE (Adrian Farrel)" , secdir Content-Type: multipart/alternative; boundary="0000000000009a36c10583c5b26d" Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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, 10 Mar 2019 23:20:15 -0000 --0000000000009a36c10583c5b26d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Mar 10, 2019 at 3:46 PM StJohns, Michael wrote: > In recent years, the CFRG has produced documents that are for lack of a > better phrase de facto standards. The rate of document production of the > CFRG mimics more closely that of a WG than the other extant RGs AFAICT. > As an RG the CFRG isn=E2=80=99t permitted to publish standards track docu= ments, nor > is the IESG or the ISE permitted or constrained to require a conflict > review on the documents the CFRG does produce. [the latter comment is my > understanding of the rules of the research stream - it may be flawed, but > the purpose of RGs is supposed to be looking at futures and that by > definition shouldn=E2=80=99t be conflicting with the nows]. > An interesting datapoint on this is Dragonfly key exchange, published as RFC 7664, has now been incorporated into the Wifi Alliance's WPA3 standard: https://sarwiki.informatik.hu-berlin.de/WPA3_Dragonfly_Handshake I will preface the following statement by saying that my criticisms of Dragonfly on the CFRG list at the time were misinformed and due to a lack of understanding, and would now call it "okay" (and many of my concerns were assuaged after it received a security proof). However, I think it's fair to say that as a non-standards document, it has something of a sordid history: https://arstechnica.com/information-technology/2013/12/critics-nsa-agent-co= -chairing-key-crypto-standards-body-should-be-removed/ I think if there were a WG chartered specifically with a standards-track document for what the next generation key exchange to be used for use cases similar to and including, but not limited to WiFi were, my best guess is we could've done better than Dragonfly. I'm not sure why the Wifi Alliance chose it specifically, but it seems the CFRG was treated at least in part as a bar the algorithm must pass for incorporation into their standards, and for a standard of such importance I guess what I'm saying is I wish that bar were higher. --=20 Tony Arcieri --0000000000009a36c10583c5b26d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun,= Mar 10, 2019 at 3:46 PM StJohns, Michael <msj@nthpermutation.com> wrote:
In recent years, the CFRG has produced documents that are for lac= k of a better phrase de facto standards.=C2=A0 The rate of document product= ion of the CFRG mimics more closely that of a WG than the other extant RGs = AFAICT. =C2=A0 As an RG the CFRG isn=E2=80=99t permitted to publish standar= ds track documents, nor is the IESG or the ISE permitted or constrained to = require a conflict review on the documents the CFRG does produce. =C2=A0[th= e latter comment is my understanding of the rules of the research stream - = it may be flawed, but the purpose of RGs is supposed to be looking at futur= es and that by definition shouldn=E2=80=99t be conflicting with the nows].<= /div>

An interesting datapoint on thi= s is Dragonfly key exchange, published as RFC 7664, has now been incorporat= ed into the Wifi Alliance's WPA3 standard:


I will preface the following statement by saying th= at my criticisms of Dragonfly on the CFRG list at the time were misinformed= and due to a lack of understanding, and would now call it "okay"= (and many of my concerns were assuaged after it received a security proof)= . However, I think it's fair to say that as a non-standards document, i= t has something of a sordid history:


I think = if there were a WG chartered specifically with a standards-track document f= or what the next generation key exchange to be used for use cases similar t= o and including, but not limited to WiFi were, my best guess is we could= 9;ve done better than Dragonfly. I'm not sure why the Wifi Alliance cho= se it specifically, but it seems the CFRG was treated at least in part as a= bar the algorithm must pass for incorporation into their standards, and fo= r a standard of such importance I guess what I'm saying is I wish that = bar were higher.

--
Tony Arcieri
--0000000000009a36c10583c5b26d-- From nobody Sun Mar 10 16:38: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 CDF931277CD; Sun, 10 Mar 2019 16:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=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 5Q40Lbx3A58j; Sun, 10 Mar 2019 16:38:33 -0700 (PDT) Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7B171126C87; Sun, 10 Mar 2019 16:38:32 -0700 (PDT) Received: from LLE2K16-MBX02.mitll.ad.local (LLE2K16-MBX02.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTP id x2ANcUFr043370; Sun, 10 Mar 2019 19:38:30 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "StJohns, Michael" CC: Stephen Farrell , CFRG , "RFC ISE (Adrian Farrel)" , secdir Thread-Topic: [Cfrg] Time to recharter CFRG as a working group? Was: Re: [secdir] ISE seeks help with some crypto drafts Thread-Index: AQHU15MRh5fmrRoU9kWbbFEvG0YyAKYFyJ4A Date: Sun, 10 Mar 2019 23:38:29 +0000 Message-ID: <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 Content-Type: multipart/signed; boundary="Apple-Mail-54D6C62B-D817-43FC-A107-6E41328022A4"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-10_20:, , 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903100182 Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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, 10 Mar 2019 23:38:37 -0000 --Apple-Mail-54D6C62B-D817-43FC-A107-6E41328022A4 Content-Type: multipart/alternative; boundary=Apple-Mail-B51E5205-9544-4377-B5E5-567AA7717281 Content-Transfer-Encoding: 7bit --Apple-Mail-B51E5205-9544-4377-B5E5-567AA7717281 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSBkbyBub3QgdGhpbmsgQ0ZSRyBzaG91bGQgbW92ZSB0byBiZWNvbWUgYSBwYXJ0IG9mIHRoZSBJ RVRGLiANCg0KV2hpbGUgKHNvbWUgb2YpIHRoZSBDRlJHLXByb2R1Y2VkIGRvY3VtZW50cyBtYXkg YmUgZGUtZmFjdG8gc3RhbmRhcmRzLCB0aGV5IGFyZW4ndCBvZiB0aGUga2luZCB0aGF0IElFVEYg aXMgZXhwZWN0ZWQgdG8gZGVmaW5lLCBhbmQgZGVhbCB3aXRoIHNvbWV3aGF0IGRpZmZlcmVudCB0 aGluZ3MuDQoNClJlZ2FyZHMsDQpVcmkNCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQo+IE9uIE1h ciAxMCwgMjAxOSwgYXQgMTg6NDYsIFN0Sm9obnMsIE1pY2hhZWwgPG1zakBudGhwZXJtdXRhdGlv bi5jb20+IHdyb3RlOg0KPiANCj4gSeKAmXZlIGJlZW4gd29uZGVyaW5nIGZvciBhIHdoaWxlIG5v dyB3aGV0aGVyIGl04oCZcyB0aW1lIHRvIG1vdmUgdGhlIENGUkcgb3ZlciB0byB0aGUgSUVURiBh cyBhIHdvcmtpbmcgZ3JvdXAuICBTdGVwaGVu4oCZcyBjb21tZW50IG9uIHJvdXRpbmcgc3R1ZmYg ZGlyZWN0bHkgdG8gdGhlIENGUkcgc3VnZ2VzdHMgdG8gbWUgdGhhdCBpdOKAmXMgcHJvYmFibHkg dGltZSBvciBSU04uIA0KPiANCj4gICAgSW4gcmVjZW50IHllYXJzLCB0aGUgQ0ZSRyBoYXMgcHJv ZHVjZWQgZG9jdW1lbnRzIHRoYXQgYXJlIGZvciBsYWNrIG9mIGEgYmV0dGVyIHBocmFzZSBkZSBm YWN0byBzdGFuZGFyZHMuICBUaGUgcmF0ZSBvZiBkb2N1bWVudCBwcm9kdWN0aW9uIG9mIHRoZSBD RlJHIG1pbWljcyBtb3JlIGNsb3NlbHkgdGhhdCBvZiBhIFdHIHRoYW4gdGhlIG90aGVyIGV4dGFu dCBSR3MgQUZBSUNULiAgIEFzIGFuIFJHIHRoZSBDRlJHIGlzbuKAmXQgcGVybWl0dGVkIHRvIHB1 Ymxpc2ggc3RhbmRhcmRzIHRyYWNrIGRvY3VtZW50cywgbm9yIGlzIHRoZSBJRVNHIG9yIHRoZSBJ U0UgcGVybWl0dGVkIG9yIGNvbnN0cmFpbmVkIHRvIHJlcXVpcmUgYSBjb25mbGljdCByZXZpZXcg b24gdGhlIGRvY3VtZW50cyB0aGUgQ0ZSRyBkb2VzIHByb2R1Y2UuICBbdGhlIGxhdHRlciBjb21t ZW50IGlzIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIHJ1bGVzIG9mIHRoZSByZXNlYXJjaCBzdHJl YW0gLSBpdCBtYXkgYmUgZmxhd2VkLCBidXQgdGhlIHB1cnBvc2Ugb2YgUkdzIGlzIHN1cHBvc2Vk IHRvIGJlIGxvb2tpbmcgYXQgZnV0dXJlcyBhbmQgdGhhdCBieSBkZWZpbml0aW9uIHNob3VsZG7i gJl0IGJlIGNvbmZsaWN0aW5nIHdpdGggdGhlIG5vd3NdLiAgDQo+IA0KPiBBbiBhbHRlcm5hdGl2 ZSBtaWdodCBiZSB0byBjaGFydGVyIGEgY3J5cHRvIHN0YW5kYXJkcyBXRyBhbmQgdHJ5IHRvIGtl ZXAgdGhlIENGUkcgZm9jdXNlZCBvbiB5ZWFycyBvdXQgLSBzYXkgaG93IHRoZSBoZWNrIGRvIHdl IGRlYWwgd2l0aCB0aGUgcXVhbnR1bSBhcG9jYWx5cHNlPw0KPiANCj4gT3Iga2VlcCB0aGUgbWF0 aCBpbiBDRlJHIGFuZCB0aGUgb24gdGhlIHdpcmUgc3BlY3MgZm9yIHVzaW5nIGluIGEgV0cuICAN Cj4gDQo+IA0KPiANCj4gRGlzY3VzcyENCj4gDQo+IE1pa2UNCj4gDQo+PiBPbiBTdW4sIE1hciAx MCwgMjAxOSBhdCAxNzo0OCBTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2Qu aWU+IHdyb3RlOg0KPj4gDQo+PiBIaXlhLA0KPj4gDQo+PiBPbiAxMC8wMy8yMDE5IDIwOjU3LCBU b255IEFyY2llcmkgd3JvdGU6DQo+PiA+IA0KPj4gPiBJIHRoaW5rIHRoZXJlIGFyZSBzaWduaWZp Y2FudCBjb21wZWxsaW5nIHJlYXNvbnMgdG8gcHJlZmVyIE9DQiBtb2RlIA0KPj4gPiBvdmVyIHBy ZXR0eSBtdWNoIGFsbCBvdGhlciBleGlzdGluZyBtb2RlczoNCj4+IA0KPj4gRldJVywgSSBkb24n dCwgYmVjYXVzZSB3ZSdyZSBub3QgZGVhbGluZyB3aXRoIGEgY2xlYW4gc2xhdGUuDQo+PiANCj4+ IEluIHRoZSBJRVRGIGNvbnRleHQsIHdoZXRoZXIgb3Igbm90IE9DQiBpcyBhIGJpdCBiZXR0ZXIN Cj4+IHRoZW4gY3VycmVudGx5IGRlcGxveWVkIG1vZGVzIGlzIG5vdCBhbiBpbnRlcmVzdGluZw0K Pj4gcXVlc3Rpb24uDQo+PiANCj4+IE9uZSBpbnRlcmVzdGluZyBxdWVzdGlvbiBtaWdodCBiZTog aXMgT0NCIHNvIG11Y2ggYmV0dGVyDQo+PiB0aGF0IGl0IGNvdWxkIHdlIGRpc3BsYWNlIHVzZXMg b2Ygc29tZSBleGlzdGluZyBtb2RlIHdpdGgNCj4+IE9DQi4gVGhhdCBzZWVtcyB1bmxpa2VseSB0 byBtZSBmb3IgdGhlIHdpZGVseSB1c2VkIG1vZGVzLg0KPj4gDQo+PiBBbm90aGVyIGludGVyZXN0 aW5nIHF1ZXN0aW9uIG1pZ2h0IGJlOiBpcyBPQ0Igc28gbXVjaA0KPj4gYmV0dGVyIHRoYXQgd2Ug d2FudCB0byBkZXBsb3kgaXQgYWxvbmdzaWRlIGN1cnJlbnQgbW9kZXMuDQo+PiBJIGRvbid0IHNl ZSB0aGUgb3ZlcmFsbCBiZW5lZml0IG9mIHRoYXQgbXlzZWxmLg0KPj4gDQo+PiBTbyBldmVuIHRo b3VnaCBJJ20gaGFwcHkgdG8gYWNjZXB0IHRoYXQgT0NCIGhhcyBiZXR0ZXINCj4+IHByb3BlcnRp ZXMgdGhhbiBlLmcuIEdDTSwgSSBkb24ndCB0aGluayBpdCdzIHNvIG11Y2gNCj4+IGJldHRlciB0 aGF0IFJGQ3MgZm9yIGl0IGFyZSB0aGF0IHVzZWZ1bC4NCj4+IA0KPj4gVGhhdCBzYWlkLCBpZiB0 aGUgUkZDIGZvciBzdWNoIGEgdGhpbmcgc2FpZCAidGhpcyBpcyBuaWNlDQo+PiBmb3IgYnJhbmQg bmV3IHN0dWZmIChhbHRob3VnaCBsaWJyYXJ5IHN1cHBvcnQgd2lsbCBiZSBsZXNzDQo+PiBjb21w cmVoZW5zaXZlKSBidXQgaXMgbm90IHdvcnRoIHRoZSBjb3N0cyBhc3NvY2lhdGVkDQo+PiB3aXRo IGFkZGluZyBpdCB0byBleGlzdGluZyBwcm90b2NvbHMiIHRoZW4gSSdkIGJlIGxlc3MNCj4+IGFn YWluc3Qgc3VjaCBSRkNzIGJlaW5nIHByb2R1Y2VkLiBVbmRlcnN0YW5kYWJseSBlbm91Z2gsDQo+ PiB0aGF0IGtpbmQgb2Ygc3RhdGVtZW50IGRvZXNuJ3QgZ2V0IGFkZGVkIHRvIHN1Y2ggUkZDczst KQ0KPj4gDQo+PiBTLg0KPj4gDQo+PiBQUzogSW4gY2FzZSB0aGUgSVNFIGlzIHN0aWxsIGxpc3Rl bmluZywgdGhlIGFib3ZlIGlzIGENCj4+IHJlYXNvbiB3aHkgSSB0aGluayBoYXZpbmcgQ0ZSRyBw cm9kdWNlIHRoaXMga2luZCBvZiBSRkMNCj4+IChpbnN0ZWFkIG9mIHJvdXRpbmcgJ2VtIHZpYSB0 aGUgSVNFKSB3b3VsZCBiZSBhIGJldHRlcg0KPj4gcGxhbi4gQ0ZSRyBjb3VsZCAoSSB0aGluaykg bGlrZWx5IHJlYWNoIGJldHRlciBpbmZvcm1lZA0KPj4ganVkZ2VtZW50cyAoaW4gdGhlIG9wZW4p IGFzIHRvIHdoZXRoZXIgb3Igbm90IHNvbWUgY3J5cHRvDQo+PiB0ZWNobmlxdWUgaXMgcmVhbGx5 IHdvcnRoIGRvY3VtZW50aW5nIGluIGFuIFJGQy4NCj4+IA0KPj4gDQo+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gQ2ZyZyBtYWlsaW5nIGxpc3QN Cj4+IENmcmdAaXJ0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY2ZyZw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBDZnJnIG1haWxpbmcgbGlzdA0KPiBDZnJnQGlydGYub3JnDQo+IGh0dHBzOi8vd3d3Lmly dGYub3JnL21haWxtYW4vbGlzdGluZm8vY2ZyZw0K --Apple-Mail-B51E5205-9544-4377-B5E5-567AA7717281 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPkkgZG8gbm90IHRo aW5rIENGUkcgc2hvdWxkIG1vdmUgdG8gYmVjb21lIGEgcGFydCBvZiB0aGUgSUVURi4mbmJzcDs8 ZGl2Pjxicj48L2Rpdj48ZGl2PldoaWxlIChzb21lIG9mKSB0aGUgQ0ZSRy1wcm9kdWNlZCBkb2N1 bWVudHMgbWF5IGJlIGRlLWZhY3RvIHN0YW5kYXJkcywgdGhleSBhcmVuJ3Qgb2YgdGhlIGtpbmQg dGhhdCBJRVRGIGlzIGV4cGVjdGVkIHRvIGRlZmluZSwgYW5kIGRlYWwgd2l0aCBzb21ld2hhdCBk aWZmZXJlbnQgdGhpbmdzLjxicj48YnI+PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj5SZWdh cmRzLDxkaXY+VXJpPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5TZW50IGZyb20gbXkgaVBob25l PC9kaXY+PC9kaXY+PGRpdj48YnI+T24gTWFyIDEwLCAyMDE5LCBhdCAxODo0NiwgU3RKb2hucywg TWljaGFlbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1zakBudGhwZXJtdXRhdGlvbi5jb20iPm1zakBu dGhwZXJtdXRhdGlvbi5jb208L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxkaXY+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxkaXY+PGRpdiBkaXI9ImF1dG8iPknigJl2ZSBi ZWVuIHdvbmRlcmluZyBmb3IgYSB3aGlsZSBub3cgd2hldGhlciBpdOKAmXMgdGltZSB0byBtb3Zl IHRoZSBDRlJHIG92ZXIgdG8gdGhlIElFVEYgYXMgYSB3b3JraW5nIGdyb3VwLiZuYnNwOyBTdGVw aGVu4oCZcyBjb21tZW50IG9uIHJvdXRpbmcgc3R1ZmYgZGlyZWN0bHkgdG8gdGhlIENGUkcgc3Vn Z2VzdHMgdG8gbWUgdGhhdCBpdOKAmXMgcHJvYmFibHkgdGltZSBvciBSU04uJm5ic3A7PC9kaXY+ PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+Jm5ic3A7ICZuYnNwO0lu IHJlY2VudCB5ZWFycywgdGhlIENGUkcgaGFzIHByb2R1Y2VkIGRvY3VtZW50cyB0aGF0IGFyZSBm b3IgbGFjayBvZiBhIGJldHRlciBwaHJhc2UgZGUgZmFjdG8gc3RhbmRhcmRzLiZuYnNwOyBUaGUg cmF0ZSBvZiBkb2N1bWVudCBwcm9kdWN0aW9uIG9mIHRoZSBDRlJHIG1pbWljcyBtb3JlIGNsb3Nl bHkgdGhhdCBvZiBhIFdHIHRoYW4gdGhlIG90aGVyIGV4dGFudCBSR3MgQUZBSUNULiAmbmJzcDsg QXMgYW4gUkcgdGhlIENGUkcgaXNu4oCZdCBwZXJtaXR0ZWQgdG8gcHVibGlzaCBzdGFuZGFyZHMg dHJhY2sgZG9jdW1lbnRzLCBub3IgaXMgdGhlIElFU0cgb3IgdGhlIElTRSBwZXJtaXR0ZWQgb3Ig Y29uc3RyYWluZWQgdG8gcmVxdWlyZSBhIGNvbmZsaWN0IHJldmlldyBvbiB0aGUgZG9jdW1lbnRz IHRoZSBDRlJHIGRvZXMgcHJvZHVjZS4gJm5ic3A7W3RoZSBsYXR0ZXIgY29tbWVudCBpcyBteSB1 bmRlcnN0YW5kaW5nIG9mIHRoZSBydWxlcyBvZiB0aGUgcmVzZWFyY2ggc3RyZWFtIC0gaXQgbWF5 IGJlIGZsYXdlZCwgYnV0IHRoZSBwdXJwb3NlIG9mIFJHcyBpcyBzdXBwb3NlZCB0byBiZSBsb29r aW5nIGF0IGZ1dHVyZXMgYW5kIHRoYXQgYnkgZGVmaW5pdGlvbiBzaG91bGRu4oCZdCBiZSBjb25m bGljdGluZyB3aXRoIHRoZSBub3dzXS4gJm5ic3A7PC9kaXY+PC9kaXY+PGRpdiBkaXI9ImF1dG8i Pjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+QW4gYWx0ZXJuYXRpdmUgbWlnaHQgYmUgdG8gY2hh cnRlciBhIGNyeXB0byBzdGFuZGFyZHMgV0cgYW5kIHRyeSB0byBrZWVwIHRoZSBDRlJHIGZvY3Vz ZWQgb24geWVhcnMgb3V0IC0gc2F5IGhvdyB0aGUgaGVjayBkbyB3ZSBkZWFsIHdpdGggdGhlIHF1 YW50dW0gYXBvY2FseXBzZT88L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGly PSJhdXRvIj5PciBrZWVwIHRoZSBtYXRoIGluIENGUkcgYW5kIHRoZSBvbiB0aGUgd2lyZSBzcGVj cyBmb3IgdXNpbmcgaW4gYSBXRy4gJm5ic3A7PC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rp dj48ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRp diBkaXI9ImF1dG8iPkRpc2N1c3MhPC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2 IGRpcj0iYXV0byI+TWlrZTwvZGl2PjxkaXY+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48 ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gU3VuLCBNYXIgMTAsIDIwMTkgYXQg MTc6NDggU3RlcGhlbiBGYXJyZWxsICZsdDs8YSBocmVmPSJtYWlsdG86c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZSI+c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZTwvYT4mZ3Q7IHdyb3RlOjxicj48 L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAg LjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48YnI+DQpI aXlhLDxicj4NCjxicj4NCk9uIDEwLzAzLzIwMTkgMjA6NTcsIFRvbnkgQXJjaWVyaSB3cm90ZTo8 YnI+DQomZ3Q7IDxicj4NCiZndDsgSSB0aGluayB0aGVyZSBhcmUgc2lnbmlmaWNhbnQgY29tcGVs bGluZyByZWFzb25zIHRvIHByZWZlciBPQ0IgbW9kZSA8YnI+DQomZ3Q7IG92ZXIgcHJldHR5IG11 Y2ggYWxsIG90aGVyIGV4aXN0aW5nIG1vZGVzOjxicj4NCjxicj4NCkZXSVcsIEkgZG9uJ3QsIGJl Y2F1c2Ugd2UncmUgbm90IGRlYWxpbmcgd2l0aCBhIGNsZWFuIHNsYXRlLjxicj4NCjxicj4NCklu IHRoZSBJRVRGIGNvbnRleHQsIHdoZXRoZXIgb3Igbm90IE9DQiBpcyBhIGJpdCBiZXR0ZXI8YnI+ DQp0aGVuIGN1cnJlbnRseSBkZXBsb3llZCBtb2RlcyBpcyBub3QgYW4gaW50ZXJlc3Rpbmc8YnI+ DQpxdWVzdGlvbi48YnI+DQo8YnI+DQpPbmUgaW50ZXJlc3RpbmcgcXVlc3Rpb24gbWlnaHQgYmU6 IGlzIE9DQiBzbyBtdWNoIGJldHRlcjxicj4NCnRoYXQgaXQgY291bGQgd2UgZGlzcGxhY2UgdXNl cyBvZiBzb21lIGV4aXN0aW5nIG1vZGUgd2l0aDxicj4NCk9DQi4gVGhhdCBzZWVtcyB1bmxpa2Vs eSB0byBtZSBmb3IgdGhlIHdpZGVseSB1c2VkIG1vZGVzLjxicj4NCjxicj4NCkFub3RoZXIgaW50 ZXJlc3RpbmcgcXVlc3Rpb24gbWlnaHQgYmU6IGlzIE9DQiBzbyBtdWNoPGJyPg0KYmV0dGVyIHRo YXQgd2Ugd2FudCB0byBkZXBsb3kgaXQgYWxvbmdzaWRlIGN1cnJlbnQgbW9kZXMuPGJyPg0KSSBk b24ndCBzZWUgdGhlIG92ZXJhbGwgYmVuZWZpdCBvZiB0aGF0IG15c2VsZi48YnI+DQo8YnI+DQpT byBldmVuIHRob3VnaCBJJ20gaGFwcHkgdG8gYWNjZXB0IHRoYXQgT0NCIGhhcyBiZXR0ZXI8YnI+ DQpwcm9wZXJ0aWVzIHRoYW4gZS5nLiBHQ00sIEkgZG9uJ3QgdGhpbmsgaXQncyBzbyBtdWNoPGJy Pg0KYmV0dGVyIHRoYXQgUkZDcyBmb3IgaXQgYXJlIHRoYXQgdXNlZnVsLjxicj4NCjxicj4NClRo YXQgc2FpZCwgaWYgdGhlIFJGQyBmb3Igc3VjaCBhIHRoaW5nIHNhaWQgInRoaXMgaXMgbmljZTxi cj4NCmZvciBicmFuZCBuZXcgc3R1ZmYgKGFsdGhvdWdoIGxpYnJhcnkgc3VwcG9ydCB3aWxsIGJl IGxlc3M8YnI+DQpjb21wcmVoZW5zaXZlKSBidXQgaXMgbm90IHdvcnRoIHRoZSBjb3N0cyBhc3Nv Y2lhdGVkPGJyPg0Kd2l0aCBhZGRpbmcgaXQgdG8gZXhpc3RpbmcgcHJvdG9jb2xzIiB0aGVuIEkn ZCBiZSBsZXNzPGJyPg0KYWdhaW5zdCBzdWNoIFJGQ3MgYmVpbmcgcHJvZHVjZWQuIFVuZGVyc3Rh bmRhYmx5IGVub3VnaCw8YnI+DQp0aGF0IGtpbmQgb2Ygc3RhdGVtZW50IGRvZXNuJ3QgZ2V0IGFk ZGVkIHRvIHN1Y2ggUkZDczstKTxicj4NCjxicj4NClMuPGJyPg0KPGJyPg0KUFM6IEluIGNhc2Ug dGhlIElTRSBpcyBzdGlsbCBsaXN0ZW5pbmcsIHRoZSBhYm92ZSBpcyBhPGJyPg0KcmVhc29uIHdo eSBJIHRoaW5rIGhhdmluZyBDRlJHIHByb2R1Y2UgdGhpcyBraW5kIG9mIFJGQzxicj4NCihpbnN0 ZWFkIG9mIHJvdXRpbmcgJ2VtIHZpYSB0aGUgSVNFKSB3b3VsZCBiZSBhIGJldHRlcjxicj4NCnBs YW4uIENGUkcgY291bGQgKEkgdGhpbmspIGxpa2VseSByZWFjaCBiZXR0ZXIgaW5mb3JtZWQ8YnI+ DQpqdWRnZW1lbnRzIChpbiB0aGUgb3BlbikgYXMgdG8gd2hldGhlciBvciBub3Qgc29tZSBjcnlw dG88YnI+DQp0ZWNobmlxdWUgaXMgcmVhbGx5IHdvcnRoIGRvY3VtZW50aW5nIGluIGFuIFJGQy48 YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCkNmcmcgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkNmcmdA aXJ0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5DZnJnQGlydGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vY2ZyZyIgcmVsPSJub3JlZmVy cmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jZnJnPC9hPjxicj4NCjwvYmxvY2txdW90ZT48L2Rpdj48L2Rpdj4NCjwvZGl2PjwvYmxvY2tx dW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxzcGFuPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxicj48c3Bhbj5DZnJnIG1haWxp bmcgbGlzdDwvc3Bhbj48YnI+PHNwYW4+PGEgaHJlZj0ibWFpbHRvOkNmcmdAaXJ0Zi5vcmciPkNm cmdAaXJ0Zi5vcmc8L2E+PC9zcGFuPjxicj48c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pcnRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NmcmciPmh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4v bGlzdGluZm8vY2ZyZzwvYT48L3NwYW4+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48L2Jv ZHk+PC9odG1sPg== --Apple-Mail-B51E5205-9544-4377-B5E5-567AA7717281-- --Apple-Mail-54D6C62B-D817-43FC-A107-6E41328022A4 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITojCCBLww ggOkoAMCAQICASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe Fw0xMzEyMTcwMDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gc KS9SlQRfqMW8F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUif Semk671G+mNZKLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NP Js/oW6YpHF5gmNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICa HIHO+VBDlA01Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFll Q5F/AgMBAAGjggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN /c9G3sjHEofKvzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMC AYYwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8/TExSQ0EwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8E LDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYow gYcwDQYLKoZIhvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcS AgEDAQkwDQYLKoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZI hvcSAgEDAQ8wDQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFqu MBzuLKeFwMSBbB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF /M+H3h1v9kneqXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsT kfrbLLErVY8+BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCi pAwj3wzMNh4s6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+Dba vUxXxFHU+S2Myw06w98wggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNV BAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcNMjAxMjMxMjM1OTU5WjBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw EQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18 tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jFvBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5o vvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8li hUixePbxWad1m7ZMKKagvm9zTybP6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+ yDz8Jzk6sP9iilgP3iXSGoCAmhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9 dtb05cy1gXAFSP3Z/iUkxyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHQ4EFgQU12BmDntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3y EMND7SkwDgYDVR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov L2NybC5sbC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t aXQuZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0GCyqG SIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0G CyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBBQUA A4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/LTCxqULjOd+H+HTqM JXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZcEEgOWC9bHcrElzU6Nni gahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbTiHe7DqfWQ2tVMLUf23XYhIua 94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r/aMsPAKx6nMaOvRL7Cy0Pjp51i2q FkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPfMIIE7TCCA9WgAwIBAgIKMziUjwAAAABu ljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAz OVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh Ym9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1 ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9 AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIws l5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK 1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpK SFq80SEh6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGe kpQVubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0G CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGG G2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiD g+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVy aUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBTAFcwDQYJ KoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaF H5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lc osfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4i vIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/p HKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mLMLqGNX3azAkwggUtMIIEFaADAgEC AgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwHhcN MTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSswKQYDVQQDEyJCbHVtZW50aGFs LlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA g+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oLToMnJQ6phCIkQGplPsM+9Ppz Icw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSNAB8WG3L+6a3mHcp9yYumPkdt M20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p6umBCLGxZi0cGhBI/7ZyJmJU Uo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857MF4OcehpG7LuxufD0p+g02uX7 Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCCAeYwHQYDVR0OBBYEFPbiFDP7 1vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBTXYGYOe0mNdUwN/c9G 3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3AwPQYJKwYB BAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhYHgQIbXxk0CAWQCAQkw LAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsGAQUFBwMCMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5lZHWgJgYKKwYBBAGCNxQCA6AY DBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQgHh4ATABMAE0AbwBiAGkAbABl AFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1DkfqhBA4LYklB+i49k6dh7L+n DEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1RjH8vLNFOEV8ZVcNxbWC5DiA 6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AOLm42Gn4lLeNrY4Ex8nq2Ah3x jB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G/HyJg9MUukKq23qm6Ys0VJQc JsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9Dszxz7LQECXI0KrPpM7x32Su lMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBM YWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCChp0xCAAAAAArQMw CQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTkwMzEwMjMzODI2WjAjBgkqhkiG9w0BCQQxFgQUf+1jI3sEpyK7hLhbncJtpNICjSwwbgYJKwYB BAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgozOJSPAAAAAG6WMHAGCyqGSIb3 DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgozOJSPAAAAAG6WMA0GCSqGSIb3 DQEBAQUABIIBABaijiSn9YclSr1KePZ09LbjMPsZSa9waHtkorBrilIx/oSxfL2bpmvSSereIa65 DOUesGJicOECEmeUpeaOTjsr24c+l9Qq5gd8XU968W8aGbLov2GxKEYrEMxZP5ZWKxwbIuxvQpcf mBmkJj/hcUheqqFTIiGI9WGI386IVCasAtVC79LE/jh9W485i1fVNU2Wn10n6GDn9dKYPWzxsBQM GAMGW3kqeuK6u05lAZ55X16AoxlFkf/czvyCCPGBPNx7OK/V+WIpxZoQ5+4sXywfkZgwSxukyT3W 0kHbu5Yz8XW7JB1ExV8bV27dqI7vqtgRFVdLpafXl7jI84SAPjUAAAAAAAA= --Apple-Mail-54D6C62B-D817-43FC-A107-6E41328022A4-- From nobody Sun Mar 10 17:08:14 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 5FAC11277CD; Sun, 10 Mar 2019 17:08:06 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 Aa0vCxyA77SV; Sun, 10 Mar 2019 17:08:03 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 99BB31275F3; Sun, 10 Mar 2019 17:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1552262883; x=1583798883; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ok0WQIlVtiI8/sXlk+2IXa4N92pryHwEkABBQdxIsQ4=; b=e3neCqgJLM3Q3CQkDd6/wfBz8KrWfX/q0zhXZbnwxvAy06yxKZikZvsH xyJZfXycR7e+t02Miu9YJOQt6ZRuVfK6afoDZTo8WmoGbrpIkdRzOxPao 4hcH+/iip39ONDycG3xJmlmLVGF/TfawEI0nOPNUBQp/L0QGhtOeDtWU6 bRJ8ozPbReurM14PQcBS9NeOoIOQsmEutpSq1zY1YoD+bJ9XBweMMVhix JJ9BXkpGS5lVRDxTh6NSJp2OwosNlyVbhNBx9d51XhXbW+QBSiP55Jq4m g29Sdwn0DNXxLOKfEOsFljKVeLD/fJfN2MdRBmQhl+anQG3WG1m7ntF9j Q==; X-IronPort-AV: E=Sophos;i="5.58,466,1544439600"; d="scan'208";a="51162501" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-d.UoA.auckland.ac.nz) ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Mar 2019 13:07:57 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 11 Mar 2019 13:07:57 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Mon, 11 Mar 2019 13:07:57 +1300 From: Peter Gutmann To: Tony Arcieri , Paul Hoffman CC: "sec-ads@ietf.org" , CFRG , "RFC ISE (Adrian Farrel)" , secdir Thread-Topic: [Cfrg] ISE seeks help with some crypto drafts Thread-Index: AQHU1dNDCBNdVgHjrEegvYcYB1zY5aYBKtUAgAAEIACAAGSggIAAFskAgAComICAAAaMgIAAqgQAgAACvICAAomNCQ== Date: Mon, 11 Mar 2019 00:07:57 +0000 Message-ID: <1552262834078.2554@cs.auckland.ac.nz> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <38FEBE5B-B60E-49DD-B048-A8A08EBF7FB4@azet.org> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 11 Mar 2019 00:08:07 -0000 Tony Arcieri writes:=0A= =0A= >"Phillip Rogaway offers a royalty-free non-exclusive license to all claims= of=0A= >the referenced patents needed to realize a fully compliant implementation = of=0A= >any IETF standards-track protocol supporting AES-OCB (RFC 7253)."=0A= =0A= That's still not going to work, for two reasons. This first is that it=0A= misunderstands how an implementation of, say, TLS works. Virtually all TLS= =0A= implementations aren't a monolithic TLS-only code block but are built on to= p=0A= of a general-purpose crypto library, for Windows CryptoAPI, for everything= =0A= else OpenSSL, Crypto++, mbedTLS, PKCS #11, my own cryptlib, etc. Taking the= =0A= vendor-neutral PKCS #11 as an example, what the above is requiring is an=0A= implementation of Maxwell's demon in software, that a PKCS #11 library be a= ble=0A= to tell whether the handle from C_CreateObject( &handle, { CKA_KEY_TYPE, ke= y,=0A= CKK_AES_OCB } ) will be used to encrypt TLS data (OK) or non-TLS data (not= =0A= OK).=0A= =0A= The second is legal. Any commercial user of whatever the crypto library is= is=0A= going to get their lawyers to look at that requirement and have a fit, not= =0A= even because of the above very technical problem but just from the knowledg= e=0A= that they'll be running code that, at the slightest glitch, will potentiall= y=0A= expose them to a patent lawsuit. I've seen companies spend 1-2 years debat= ing=0A= whether using generic permissive BSD-licensed code is safe, and now they'll= be=0A= asked to decide whether the risk in the above is worthwhile because blah bl= ah=0A= geekspeak geekspeak, for which the answer will most likely be "no".=0A= =0A= I'd love to use OCB, it's a really nice, elegant mode, but unfortunately=0A= unless the usage conditions are "freely available without restrictions" I= =0A= can't. And that's not from rabid freetardism, it's from pragmatism, it's t= oo=0A= risky legally.=0A= =0A= Peter.=0A= From steve01@hannas.com Sun Mar 10 17:41:20 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 85DD61275F3; Sun, 10 Mar 2019 17:41:20 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001] 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 DAzvkDCN-x1C; Sun, 10 Mar 2019 17:41:19 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0188.hostedemail.com [216.40.44.188]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A9D126C87; Sun, 10 Mar 2019 17:41:18 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay05.hostedemail.com (Postfix) with ESMTP id 41B571803045B; Mon, 11 Mar 2019 00:41:17 +0000 (UTC) X-Session-Marker: 737465766530314068616E6E61732E636F6D X-Spam-Summary: 40, 2.5, 0, , d41d8cd98f00b204, steve01@hannas.com, :::::, RULES_HIT:10:41:355:379:541:542:973:982:988:989:1155:1260:1277:1311:1313:1314:1345:1381:1437:1515:1516:1518:1534:1541:1587:1593:1594:1711:1730:1747:1777:1792:2198:2199:2393:2559:2562:2894:2911:3138:3139:3140:3141:3142:3352:3865:3866:3867:3868:3870:3872:3874:4250:4425:5007:6119:7903:8660:10011:10400:10848:11658:11914:11984:12109:12114:12679:12760:13069:13148:13161:13229:13230:13311:13357:13439:14040:14096:14097:14195:14721:21080:21212:21324:21433:21627:30006:30045:30054, 0, RBL:184.88.10.175:@hannas.com:.lbl8.mailshell.net-62.8.0.186 64.201.201.201, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:1:0, LFtime:28, LUA_SUMMARY:none X-HE-Tag: group11_7f8dee4a51c00 X-Filterd-Recvd-Size: 2163 Received: from DESKTOP1IV8FA2 (184-088-010-175.res.spectrum.com [184.88.10.175]) (Authenticated sender: steve01@hannas.com) by omf18.hostedemail.com (Postfix) with ESMTPA; Mon, 11 Mar 2019 00:41:16 +0000 (UTC) Reply-To: From: "Steve Hanna" To: , , Date: Sun, 10 Mar 2019 20:41:16 -0400 Message-ID: <03dd01d4d7a3$23a209d0$6ae61d70$@hannas.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: AdTXot6upCK+Lt3iTkODqB4rHpbPhg== Archived-At: X-Mailman-Approved-At: Sun, 10 Mar 2019 17:56:39 -0700 Subject: [secdir] Secdir Last Call Review of draft-ietf-mmusic-data-channel-sdpneg-24 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, 11 Mar 2019 00:47:24 -0000 Review result: Ready with nits Reviewer: Steve Hanna 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. This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve an out-of-band non-DCEP negotiation for establishing a data channel. Major Concerns: None Minor Concerns: The last sentence in the Security Considerations section says: Error cases like the use of unknown parameter values or violation the odd/even rule must be handled by closing the corresponding Data Channel. I suspect that the "must" in this sentence should be "MUST". Nothing else in the document seems to state this requirement but it does seem necessary. Nits: This document has many small English language errors. For example, the first paragraph of the Introduction has three things that need to be corrected: - s/a bi-directional data channels/bi-directional data channels/ - s/prtocols/protocols/ - s/an endpoint applications/endpoint applications/ Please enlist a native English speaker as a proofreader. From nobody Sun Mar 10 18:38:30 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 CB20F12EB11; Sun, 10 Mar 2019 18:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 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, KHOP_DYNAMIC=1.468, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 n9vE4ygaCtNB; Sun, 10 Mar 2019 18:38:21 -0700 (PDT) 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 E055712D4ED; Sun, 10 Mar 2019 18:38:20 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x2B1c6uK029805; Mon, 11 Mar 2019 01:38:19 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=RfF10QA223C5XYyuHCVjX8KMpzpGaybqZOsY/wc7k88=; b=XzNlKla4nSXMB6lYjsQG695Inc+nbSFi1pEtGu08xSZsx0TrfkVAPY2l37jv2E2DwUET LT2aGgpkjxl//pB/+w7zbVTn3IDDtCa0p6FENZ8pAGG5rHD47JozUUJt86eLy3ESVvfY 4uvEgjCoDzNw6ME0UxwOdlBfpdrpQWEAvd3dxb2rcC11sXrQfjQs5Rz+V6NOR9RrWDwt 2WkjmuA+uuBDvxFr9EhfEams9FPnTMwMAxoWzyqF92Gk1Ym24KwML97JVAQdodQk8i9b dzeQkSHkq59XArKHm56Kxh7BwnHqS1WznPdCkv6DQqFQaOQHpkY3TT4VtI1Cs3AF1ske WA== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2r43ej716r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Mar 2019 01:38:18 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x2B1VocE028693; Sun, 10 Mar 2019 21:38:17 -0400 Received: from email.msg.corp.akamai.com ([172.27.27.21]) by prod-mail-ppoint3.akamai.com with ESMTP id 2r49q0pgj3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 10 Mar 2019 21:38:17 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 10 Mar 2019 18:38:11 -0700 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1473.003; Sun, 10 Mar 2019 20:38:11 -0500 From: "Salz, Rich" To: Paul Hoffman , Aaron Zauner CC: "sec-ads@ietf.org" , "cfrg@irtf.org" , "rfc-ise@rfc-editor.org" , "secdir@ietf.org" Thread-Topic: [Cfrg] ISE seeks help with some crypto drafts Thread-Index: AQHU1sSh5Bp4IJfpFEWgtYnjGORBDqYFuWUA Date: Mon, 11 Mar 2019 01:38:10 +0000 Message-ID: References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <38FEBE5B-B60E-49DD-B048-A8A08EBF7FB4@azet.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.0.190303 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.106] Content-Type: text/plain; charset="utf-8" Content-ID: <2E1A07EE9FB43649AD4D59C31B212C89@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-10_20:, , 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=597 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903110009 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-11_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=617 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903110010 Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 11 Mar 2019 01:38:22 -0000 PiAgICBUaGUgYW5zd2VyIHRvICJpcyBUTFMgMS4zIChhIHN0YW5kYXJkKSB1c2luZyBPQ0IzIChu byBhIHN0YW5kYXJkKSBhIA0KICAgIHN0YW5kYXJkcy10cmFjayBwcm90b2NvbCIgaXMgbm90IG9i dmlvdXMuIFdlbGwsIHNvbWUgcGVvcGxlIHdvdWxkIHNheSBpdCANCiAgICBpcyBvYnZpb3VzLCBi dXQgd291bGQgZGlzYWdyZWUgb24gdGhlIHZhbHVlIG9mIHRoZSBib29sZWFuIHJlc3BvbnNlLg0K ICANCkFueSBjb2RlcG9pbnRzIGZvciB0aG9zZSBjaXBoZXJzIHdpbGwgZ290IGFuICJOIiBpbiB0 aGUgcmVjb21tZW5kZWQgIGNvbHVtbiwgYmVjYXVzZSB0aGUgZGVmaW5pdGlvbnMgYXJlIHBhcnQg b2YgYSBzdGFuZGFyZHMtdHJhY2sgUkZDLg0KDQoNCg0K From nobody Sun Mar 10 18:40:57 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 D283F12F19D; Sun, 10 Mar 2019 18:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 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, KHOP_DYNAMIC=1.468, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 VAeOGchudXHm; Sun, 10 Mar 2019 18:40:46 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 965381286CD; Sun, 10 Mar 2019 18:40:46 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x2B1cRp8005795; Mon, 11 Mar 2019 01:40:45 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=H+fnffgAK2E+yXPuYtDOExhyx36Uka5eHrDKWBrmkxs=; b=oOUSOZyhy2p/NCT78BEOx5g5KcVGR7sPV14Ni7K6PLc+lCPapUcnhNE8OLQ8rkkqJtKn QxWW5xUsSoa3SfYK1N/6DNquL5rhQrv3HGfafvcSevStcGMnCfdJimxZ2ALFi0kOq7sc Q/X2RA80l07wxFh8r/kloOLiCPb6NWuHC8kQ9kF7ZEwNDf4VE/h75VsDmAcjH8FOf/eJ F6K8bkD9qc0X/7ZqqO3/xlGkZ4KCosTHWw9EqS//MG/PbrSQAbEXDLNwyvgzF5CYI57j kNOS8XNKFQVd4X1BAiwdFsD0mW04s4BmomqMARggVMHeWmA8udYpYMRJ6Ok5EjKJaBv8 Tg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050095.ppops.net-00190b01. with ESMTP id 2r45w6xda7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Mar 2019 01:40:45 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x2B1Vks8024998; Sun, 10 Mar 2019 21:40:44 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2r49pyecgf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 10 Mar 2019 21:40:44 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 10 Mar 2019 20:40:43 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1473.003; Sun, 10 Mar 2019 20:40:43 -0500 From: "Salz, Rich" To: "Blumenthal, Uri - 0553 - MITLL" , Tony Arcieri , Paul Hoffman CC: "sec-ads@ietf.org" , CFRG , "RFC ISE (Adrian Farrel)" , secdir Thread-Topic: [Cfrg] ISE seeks help with some crypto drafts Thread-Index: AQHU1sSh5Bp4IJfpFEWgtYnjGORBDqYEQuOAgABC/YCAATQ6AA== Date: Mon, 11 Mar 2019 01:40:42 +0000 Message-ID: <27DE1190-B3D9-4A47-8316-6BD7778AD302@akamai.com> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <38FEBE5B-B60E-49DD-B048-A8A08EBF7FB4@azet.org> <21B00151-36FA-40A9-8F8A-5425FC887C8A@ll.mit.edu> In-Reply-To: <21B00151-36FA-40A9-8F8A-5425FC887C8A@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.0.190303 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.106] Content-Type: multipart/alternative; boundary="_000_27DE1190B3D94A4783166BD7778AD302akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-10_20:, , 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=698 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903110009 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-11_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=714 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903110010 Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 11 Mar 2019 01:40:48 -0000 --_000_27DE1190B3D94A4783166BD7778AD302akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGUgSUVTRyBzaG91bGQgYXNrIG91ciBsZWdhbCBjb3Vuc2VsIGZvciB3b3JkaW5n IGFkdmljZS4NCg0K --_000_27DE1190B3D94A4783166BD7778AD302akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSB0aGluayB0aGUgSUVTRyBzaG91bGQgYXNrIG91ciBsZWdhbCBjb3Vuc2VsIGZvciB3b3JkaW5n IGFkdmljZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_27DE1190B3D94A4783166BD7778AD302akamaicom_-- From nobody Mon Mar 11 00:07: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 CC77B13115A for ; Mon, 11 Mar 2019 00:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, 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=ericsson.com header.b=WtCrmBgX; dkim=pass (1024-bit key) header.d=ericsson.com header.b=N4OIrOgV 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 TKrbpfHchClF for ; Mon, 11 Mar 2019 00:07:29 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 8A3D41310FC for ; Mon, 11 Mar 2019 00:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1552288046; x=1554880046; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rxwroBgfwy6/IfYu1+Y7GHgn/I8uRVeSeZKZN23Mt6c=; b=WtCrmBgXBfj8iZ5QZo5v3yJRmW1YtL7S1v+uzowCY/SLS9QJRtgGZRh+Pw2fv6oc YGRWHlwtsOtm0LAbsz54TY0pXHMs6gIMoXNbvNjSmmahIPFvsbavCBaSUyAZplz0 dQmEEfUMHCpn24t0t9EjG6zOELnaAAwfIeD9ZTNeO2w=; X-AuditID: c1b4fb2d-d9dff7000000062f-7f-5c86092ea25e Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A9.36.01583.E29068C5; Mon, 11 Mar 2019 08:07:26 +0100 (CET) Received: from ESESSMR505.ericsson.se (153.88.183.127) by ESESBMB502.ericsson.se (153.88.183.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 11 Mar 2019 08:07:26 +0100 Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSMR505.ericsson.se (153.88.183.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 11 Mar 2019 08:07:26 +0100 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 11 Mar 2019 08:07:26 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rxwroBgfwy6/IfYu1+Y7GHgn/I8uRVeSeZKZN23Mt6c=; b=N4OIrOgVqlbjaTwylPpywicAhLdwDrtSHs6gqx6ApkJa//mw2pB8MERwsHMSJzPvGufDu8KutnMhucB1fRcA6dGFzLbNOZBl555NKUvDW9F/I5VcYovKYalbcywxmUT2xZM6d0/m57LZC3YUMRUEDjrkbBBjsyOd7sDOa6UGMZU= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB4362.eurprd07.prod.outlook.com (20.176.167.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.10; Mon, 11 Mar 2019 07:07:24 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::ace2:9258:766:85a8]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::ace2:9258:766:85a8%3]) with mapi id 15.20.1709.011; Mon, 11 Mar 2019 07:07:24 +0000 From: John Mattsson To: "Blumenthal, Uri - 0553 - MITLL" , "StJohns, Michael" CC: secdir , CFRG , "RFC ISE (Adrian Farrel)" Thread-Topic: [Cfrg] Time to recharter CFRG as a working group? Was: Re: [secdir] ISE seeks help with some crypto drafts Thread-Index: AQHU15MtIGehcZNHGkecAa4HNmm/SaYFhZSAgACOL4A= Date: Mon, 11 Mar 2019 07:07:24 +0000 Message-ID: <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> In-Reply-To: <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8ae28e38-a8be-4454-f95d-08d6a5f036bb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4362; x-ms-traffictypediagnostic: HE1PR07MB4362: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(39860400002)(376002)(136003)(396003)(199004)(189003)(966005)(11346002)(446003)(478600001)(105586002)(106356001)(44832011)(486006)(2616005)(476003)(2906002)(53546011)(26005)(6346003)(6506007)(99286004)(76176011)(606006)(14454004)(102836004)(8936002)(5660300002)(316002)(6436002)(54896002)(6306002)(86362001)(71190400001)(58126008)(54906003)(6486002)(83716004)(71200400001)(110136005)(6246003)(6512007)(93886005)(2171002)(82746002)(8676002)(81156014)(81166006)(236005)(25786009)(53936002)(68736007)(33656002)(6116002)(97736004)(66066001)(36756003)(14444005)(256004)(186003)(7736002)(229853002)(4326008)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4362; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: BhlRzgHj4TqW37ZxRYczO5cGygZANn8d62zrVVlG0nVK9f3DtSwu2j96Ob9iwLjOMxtdc4+Ra9slWPzVk4OCfcZ2p0GO91K7bwzRQQZI8rEhmVXRUcvSXbS6uUE9WShLvQPH8JWjRqVBEwPXE8FgS9PuRZ2GTnK1Q7nlkaCEX4/0N8NWBWB75aJqcTmY/yMiVOX4d6dz69BxUZSxzhJLtnvj668XzFoNfMOWg/Sk3udUP4qIO+PlBwKvmTT0R6n4fz9N/WKjgnbX5j5MkM3jIydsfg2bUm8ZrcEX6/EQUtQ0ZxxNt50CtfM42FczPmBIFPQ8MIYXIjJ01vui2uACVeLHJOG3h/eH6/20X2H4mNNXtSH7TC6/drL/vqFXp4gRTOq3RRdkKSdZ+tF2n19/SxJJvlSmxRSLwk/hsNId3Xo= Content-Type: multipart/alternative; boundary="_000_2935C6E33AE84447BA018DAE0410E5C6ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8ae28e38-a8be-4454-f95d-08d6a5f036bb X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2019 07:07:24.6875 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4362 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa1CMURjH57yX3bfNcmy3Z5JoZ9yiNjRmiQrDrA+NfGAak8tqX2q6zr6J YmjQDi0rNGiVamYVyW3dmnTRhYkITZehwaao7apxqWiid99l+vY7z/P/n//znDkMKXtNuzNR cYmsNk4dIxdJqKywh5yPr4Mu3C+7bp5SP1JFKPs/eyj7WnRI+TW/nVK2/dwXTKtMplFCde5O jUhltnaKVI8HWsSqVN1TOpTeKlmpYWOiklitInCnJHKw1EgljJxC+weOHEep6HQ6SkcODGB/ MLYVETzLcC2Cjop16UgywT8R1N7oJ/8fGs8aRILKRMCnD5v4BoUzSBi/PWy3nyNgrJwVHBYE X+qGxHxDhP0gpyx1ws0wzlgDTQ+c+DKJI6G2OZvk2Qknw9CxPzTPzjgFekZ0dl4BJztKbEzh OdBiqbSxFAdBUV+rPXeQAlNrKM8OOBCs107YVkPYFYafFxNClhu868wlhJUxmMpekQK7gLVj 3HanC1bAPYOFEupeUF9x1a6ZCY25esSPDzgELqfF8ysCfovgvdVgf0ZvsBR+FAvsDnVvntAC R8Otuy/tdQ8wXrKIBXOxCC50niIzkK9x0nwCR8DT7ms2luLp8CyrkzJOZJN4AdwqVQgSL8jU t4sFng9p2Tl2VoFh7JtosiYPMUXIhWM5LnbPkqW+rDYqguPi43zj2EQzmvhnVfd++5Sg672r qxFmkHyKdMFQWriMVidxybHVCBhS7iwtp3ThMqlGnZzCauN3aPfGsFw1msFQcjfpmGx6uAzv USey0SybwGr/dQnGwT0VJZ//VV65aioVEEx2L9/s3RO25UfHocBFV7IysyyOrQeC7s4NOuu5 1rrNdZrf7IL8lK4MWa9+d1NeQ/PBm10Boy8MjrtSYtP71p+5Tycs/KY53FMfVl1YFK9jGc/i Rxslnl03XLf7Z5MNCjOxfdaGNSOZejdzomIZrR+vKbh49HtdiJziItWLvUktp/4LaMkf4WMD AAA= Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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, 11 Mar 2019 07:07:33 -0000 --_000_2935C6E33AE84447BA018DAE0410E5C6ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBpdCBpcyBtdWNoIG1vcmUgaW1wb3J0YW50IHRoYXQgQ0ZSRyBzdGF5cyBhIFJlc2Vh cmNoIEdyb3VwLCB0aGFuIGl0IGlzIHRoYXQgQ0ZSRyBjYW4gcHJvZHVjZSBzdGFuZGFyZHMgdHJh Y2sgZG9jdW1lbnRzLiBDRlJHIGlzIHVuaXF1ZSBhbmQgZmlsbHMgYSB2ZXJ5IGltcG9ydGFudCBy b2xsLiBUaGUgZmFjdCB0aGF0IENGUkcgZG9jdW1lbnRzIGFyZSB1c2VkIHNvIG11Y2ggaW5kaWNh dGVzIHRvIG1lIHRoYXQgQ0ZSRyBpcyB3b3JraW5nIHZlcnkgd2VsbC4gSSB3b3VsZCBiZSB2ZXJ5 IGhlc2l0YW50IGluIGNoYW5naW5nIHNvbWV0aGluZyB0aGF0IHdvcmtzLg0KDQpDaGVlcnMsDQpK b2huDQoNCkZyb206IENmcmcgPGNmcmctYm91bmNlc0BpcnRmLm9yZz4gb24gYmVoYWxmIG9mICJC bHVtZW50aGFsLCBVcmkgLSAwNTUzIC0gTUlUTEwiIDx1cmlAbGwubWl0LmVkdT4NCkRhdGU6IE1v bmRheSwgMTEgTWFyY2ggMjAxOSBhdCAwMDozOQ0KVG86ICJTdEpvaG5zLCBNaWNoYWVsIiA8bXNq QG50aHBlcm11dGF0aW9uLmNvbT4NCkNjOiBzZWNkaXIgPHNlY2RpckBpZXRmLm9yZz4sIENGUkcg PGNmcmdAaXJ0Zi5vcmc+LCAiUkZDIElTRSAoQWRyaWFuIEZhcnJlbCkiIDxyZmMtaXNlQHJmYy1l ZGl0b3Iub3JnPg0KU3ViamVjdDogUmU6IFtDZnJnXSBUaW1lIHRvIHJlY2hhcnRlciBDRlJHIGFz IGEgd29ya2luZyBncm91cD8gV2FzOiBSZTogW3NlY2Rpcl0gSVNFIHNlZWtzIGhlbHAgd2l0aCBz b21lIGNyeXB0byBkcmFmdHMNCg0KSSBkbyBub3QgdGhpbmsgQ0ZSRyBzaG91bGQgbW92ZSB0byBi ZWNvbWUgYSBwYXJ0IG9mIHRoZSBJRVRGLg0KDQpXaGlsZSAoc29tZSBvZikgdGhlIENGUkctcHJv ZHVjZWQgZG9jdW1lbnRzIG1heSBiZSBkZS1mYWN0byBzdGFuZGFyZHMsIHRoZXkgYXJlbid0IG9m IHRoZSBraW5kIHRoYXQgSUVURiBpcyBleHBlY3RlZCB0byBkZWZpbmUsIGFuZCBkZWFsIHdpdGgg c29tZXdoYXQgZGlmZmVyZW50IHRoaW5ncy4NClJlZ2FyZHMsDQpVcmkNCg0KU2VudCBmcm9tIG15 IGlQaG9uZQ0KDQpPbiBNYXIgMTAsIDIwMTksIGF0IDE4OjQ2LCBTdEpvaG5zLCBNaWNoYWVsIDxt c2pAbnRocGVybXV0YXRpb24uY29tPG1haWx0bzptc2pAbnRocGVybXV0YXRpb24uY29tPj4gd3Jv dGU6DQpJ4oCZdmUgYmVlbiB3b25kZXJpbmcgZm9yIGEgd2hpbGUgbm93IHdoZXRoZXIgaXTigJlz IHRpbWUgdG8gbW92ZSB0aGUgQ0ZSRyBvdmVyIHRvIHRoZSBJRVRGIGFzIGEgd29ya2luZyBncm91 cC4gIFN0ZXBoZW7igJlzIGNvbW1lbnQgb24gcm91dGluZyBzdHVmZiBkaXJlY3RseSB0byB0aGUg Q0ZSRyBzdWdnZXN0cyB0byBtZSB0aGF0IGl04oCZcyBwcm9iYWJseSB0aW1lIG9yIFJTTi4NCg0K ICAgSW4gcmVjZW50IHllYXJzLCB0aGUgQ0ZSRyBoYXMgcHJvZHVjZWQgZG9jdW1lbnRzIHRoYXQg YXJlIGZvciBsYWNrIG9mIGEgYmV0dGVyIHBocmFzZSBkZSBmYWN0byBzdGFuZGFyZHMuICBUaGUg cmF0ZSBvZiBkb2N1bWVudCBwcm9kdWN0aW9uIG9mIHRoZSBDRlJHIG1pbWljcyBtb3JlIGNsb3Nl bHkgdGhhdCBvZiBhIFdHIHRoYW4gdGhlIG90aGVyIGV4dGFudCBSR3MgQUZBSUNULiAgIEFzIGFu IFJHIHRoZSBDRlJHIGlzbuKAmXQgcGVybWl0dGVkIHRvIHB1Ymxpc2ggc3RhbmRhcmRzIHRyYWNr IGRvY3VtZW50cywgbm9yIGlzIHRoZSBJRVNHIG9yIHRoZSBJU0UgcGVybWl0dGVkIG9yIGNvbnN0 cmFpbmVkIHRvIHJlcXVpcmUgYSBjb25mbGljdCByZXZpZXcgb24gdGhlIGRvY3VtZW50cyB0aGUg Q0ZSRyBkb2VzIHByb2R1Y2UuICBbdGhlIGxhdHRlciBjb21tZW50IGlzIG15IHVuZGVyc3RhbmRp bmcgb2YgdGhlIHJ1bGVzIG9mIHRoZSByZXNlYXJjaCBzdHJlYW0gLSBpdCBtYXkgYmUgZmxhd2Vk LCBidXQgdGhlIHB1cnBvc2Ugb2YgUkdzIGlzIHN1cHBvc2VkIHRvIGJlIGxvb2tpbmcgYXQgZnV0 dXJlcyBhbmQgdGhhdCBieSBkZWZpbml0aW9uIHNob3VsZG7igJl0IGJlIGNvbmZsaWN0aW5nIHdp dGggdGhlIG5vd3NdLg0KDQpBbiBhbHRlcm5hdGl2ZSBtaWdodCBiZSB0byBjaGFydGVyIGEgY3J5 cHRvIHN0YW5kYXJkcyBXRyBhbmQgdHJ5IHRvIGtlZXAgdGhlIENGUkcgZm9jdXNlZCBvbiB5ZWFy cyBvdXQgLSBzYXkgaG93IHRoZSBoZWNrIGRvIHdlIGRlYWwgd2l0aCB0aGUgcXVhbnR1bSBhcG9j YWx5cHNlPw0KDQpPciBrZWVwIHRoZSBtYXRoIGluIENGUkcgYW5kIHRoZSBvbiB0aGUgd2lyZSBz cGVjcyBmb3IgdXNpbmcgaW4gYSBXRy4NCg0KDQoNCkRpc2N1c3MhDQoNCk1pa2UNCg0KT24gU3Vu LCBNYXIgMTAsIDIwMTkgYXQgMTc6NDggU3RlcGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllPG1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPj4gd3JvdGU6DQoNCkhp eWEsDQoNCk9uIDEwLzAzLzIwMTkgMjA6NTcsIFRvbnkgQXJjaWVyaSB3cm90ZToNCj4NCj4gSSB0 aGluayB0aGVyZSBhcmUgc2lnbmlmaWNhbnQgY29tcGVsbGluZyByZWFzb25zIHRvIHByZWZlciBP Q0IgbW9kZQ0KPiBvdmVyIHByZXR0eSBtdWNoIGFsbCBvdGhlciBleGlzdGluZyBtb2RlczoNCg0K RldJVywgSSBkb24ndCwgYmVjYXVzZSB3ZSdyZSBub3QgZGVhbGluZyB3aXRoIGEgY2xlYW4gc2xh dGUuDQoNCkluIHRoZSBJRVRGIGNvbnRleHQsIHdoZXRoZXIgb3Igbm90IE9DQiBpcyBhIGJpdCBi ZXR0ZXINCnRoZW4gY3VycmVudGx5IGRlcGxveWVkIG1vZGVzIGlzIG5vdCBhbiBpbnRlcmVzdGlu Zw0KcXVlc3Rpb24uDQoNCk9uZSBpbnRlcmVzdGluZyBxdWVzdGlvbiBtaWdodCBiZTogaXMgT0NC IHNvIG11Y2ggYmV0dGVyDQp0aGF0IGl0IGNvdWxkIHdlIGRpc3BsYWNlIHVzZXMgb2Ygc29tZSBl eGlzdGluZyBtb2RlIHdpdGgNCk9DQi4gVGhhdCBzZWVtcyB1bmxpa2VseSB0byBtZSBmb3IgdGhl IHdpZGVseSB1c2VkIG1vZGVzLg0KDQpBbm90aGVyIGludGVyZXN0aW5nIHF1ZXN0aW9uIG1pZ2h0 IGJlOiBpcyBPQ0Igc28gbXVjaA0KYmV0dGVyIHRoYXQgd2Ugd2FudCB0byBkZXBsb3kgaXQgYWxv bmdzaWRlIGN1cnJlbnQgbW9kZXMuDQpJIGRvbid0IHNlZSB0aGUgb3ZlcmFsbCBiZW5lZml0IG9m IHRoYXQgbXlzZWxmLg0KDQpTbyBldmVuIHRob3VnaCBJJ20gaGFwcHkgdG8gYWNjZXB0IHRoYXQg T0NCIGhhcyBiZXR0ZXINCnByb3BlcnRpZXMgdGhhbiBlLmcuIEdDTSwgSSBkb24ndCB0aGluayBp dCdzIHNvIG11Y2gNCmJldHRlciB0aGF0IFJGQ3MgZm9yIGl0IGFyZSB0aGF0IHVzZWZ1bC4NCg0K VGhhdCBzYWlkLCBpZiB0aGUgUkZDIGZvciBzdWNoIGEgdGhpbmcgc2FpZCAidGhpcyBpcyBuaWNl DQpmb3IgYnJhbmQgbmV3IHN0dWZmIChhbHRob3VnaCBsaWJyYXJ5IHN1cHBvcnQgd2lsbCBiZSBs ZXNzDQpjb21wcmVoZW5zaXZlKSBidXQgaXMgbm90IHdvcnRoIHRoZSBjb3N0cyBhc3NvY2lhdGVk DQp3aXRoIGFkZGluZyBpdCB0byBleGlzdGluZyBwcm90b2NvbHMiIHRoZW4gSSdkIGJlIGxlc3MN CmFnYWluc3Qgc3VjaCBSRkNzIGJlaW5nIHByb2R1Y2VkLiBVbmRlcnN0YW5kYWJseSBlbm91Z2gs DQp0aGF0IGtpbmQgb2Ygc3RhdGVtZW50IGRvZXNuJ3QgZ2V0IGFkZGVkIHRvIHN1Y2ggUkZDczst KQ0KDQpTLg0KDQpQUzogSW4gY2FzZSB0aGUgSVNFIGlzIHN0aWxsIGxpc3RlbmluZywgdGhlIGFi b3ZlIGlzIGENCnJlYXNvbiB3aHkgSSB0aGluayBoYXZpbmcgQ0ZSRyBwcm9kdWNlIHRoaXMga2lu ZCBvZiBSRkMNCihpbnN0ZWFkIG9mIHJvdXRpbmcgJ2VtIHZpYSB0aGUgSVNFKSB3b3VsZCBiZSBh IGJldHRlcg0KcGxhbi4gQ0ZSRyBjb3VsZCAoSSB0aGluaykgbGlrZWx5IHJlYWNoIGJldHRlciBp bmZvcm1lZA0KanVkZ2VtZW50cyAoaW4gdGhlIG9wZW4pIGFzIHRvIHdoZXRoZXIgb3Igbm90IHNv bWUgY3J5cHRvDQp0ZWNobmlxdWUgaXMgcmVhbGx5IHdvcnRoIGRvY3VtZW50aW5nIGluIGFuIFJG Qy4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Q2ZyZyBtYWlsaW5nIGxpc3QNCkNmcmdAaXJ0Zi5vcmc8bWFpbHRvOkNmcmdAaXJ0Zi5vcmc+DQpo dHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NmcmcNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDZnJnIG1haWxpbmcgbGlzdA0KQ2Zy Z0BpcnRmLm9yZzxtYWlsdG86Q2ZyZ0BpcnRmLm9yZz4NCmh0dHBzOi8vd3d3LmlydGYub3JnL21h aWxtYW4vbGlzdGluZm8vY2ZyZw0K --_000_2935C6E33AE84447BA018DAE0410E5C6ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJTViIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkkgdGhpbmsgaXQgaXMgbXVjaCBt b3JlIGltcG9ydGFudCB0aGF0IENGUkcgc3RheXMgYSBSZXNlYXJjaCBHcm91cCwgdGhhbiBpdCBp cyB0aGF0IENGUkcgY2FuIHByb2R1Y2Ugc3RhbmRhcmRzIHRyYWNrIGRvY3VtZW50cy4gQ0ZSRyBp cyB1bmlxdWUgYW5kIGZpbGxzIGEgdmVyeSBpbXBvcnRhbnQgcm9sbC4gVGhlIGZhY3QgdGhhdCBD RlJHIGRvY3VtZW50cyBhcmUgdXNlZCBzbw0KIG11Y2ggaW5kaWNhdGVzIHRvIG1lIHRoYXQgQ0ZS RyBpcyB3b3JraW5nIHZlcnkgd2VsbC4gSSB3b3VsZCBiZSB2ZXJ5IGhlc2l0YW50IGluIGNoYW5n aW5nIHNvbWV0aGluZyB0aGF0IHdvcmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Q2hlZXJzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC Ij5Kb2huPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5DZnJnICZsdDtjZnJnLWJvdW5jZXNAaXJ0Zi5vcmcm Z3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDtCbHVtZW50aGFsLCBVcmkgLSAwNTUzIC0gTUlUTEwmcXVv dDsgJmx0O3VyaUBsbC5taXQuZWR1Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIDExIE1h cmNoIDIwMTkgYXQgMDA6Mzk8YnI+DQo8Yj5UbzogPC9iPiZxdW90O1N0Sm9obnMsIE1pY2hhZWwm cXVvdDsgJmx0O21zakBudGhwZXJtdXRhdGlvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5zZWNk aXIgJmx0O3NlY2RpckBpZXRmLm9yZyZndDssIENGUkcgJmx0O2NmcmdAaXJ0Zi5vcmcmZ3Q7LCAm cXVvdDtSRkMgSVNFIChBZHJpYW4gRmFycmVsKSZxdW90OyAmbHQ7cmZjLWlzZUByZmMtZWRpdG9y Lm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtDZnJnXSBUaW1lIHRvIHJlY2hhcnRl ciBDRlJHIGFzIGEgd29ya2luZyBncm91cD8gV2FzOiBSZTogW3NlY2Rpcl0gSVNFIHNlZWtzIGhl bHAgd2l0aCBzb21lIGNyeXB0byBkcmFmdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkbyBub3QgdGhpbmsgQ0ZSRyBzaG91bGQgbW92ZSB0 byBiZWNvbWUgYSBwYXJ0IG9mIHRoZSBJRVRGLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPldo aWxlIChzb21lIG9mKSB0aGUgQ0ZSRy1wcm9kdWNlZCBkb2N1bWVudHMgbWF5IGJlIGRlLWZhY3Rv IHN0YW5kYXJkcywgdGhleSBhcmVuJ3Qgb2YgdGhlIGtpbmQgdGhhdCBJRVRGIGlzIGV4cGVjdGVk IHRvIGRlZmluZSwgYW5kIGRlYWwgd2l0aCBzb21ld2hhdCBkaWZmZXJlbnQgdGhpbmdzLjxvOnA+ PC9vOnA+PC9wPg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlJlZ2FyZHMsIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlVyaTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TZW50IGZyb20gbXkgaVBob25lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KT24gTWFyIDEwLCAyMDE5LCBhdCAxODo0NiwgU3RKb2hucywgTWljaGFlbCAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1zakBudGhwZXJtdXRhdGlvbi5jb20iPm1zakBudGhwZXJtdXRhdGlvbi5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZdmUgYmVlbiB3b25kZXJpbmcgZm9yIGEg d2hpbGUgbm93IHdoZXRoZXIgaXTigJlzIHRpbWUgdG8gbW92ZSB0aGUgQ0ZSRyBvdmVyIHRvIHRo ZSBJRVRGIGFzIGEgd29ya2luZyBncm91cC4mbmJzcDsgU3RlcGhlbuKAmXMgY29tbWVudCBvbiBy b3V0aW5nIHN0dWZmIGRpcmVjdGx5IHRvIHRoZSBDRlJHIHN1Z2dlc3RzIHRvIG1lIHRoYXQgaXTi gJlzIHByb2JhYmx5IHRpbWUgb3IgUlNOLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7SW4gcmVjZW50IHllYXJz LCB0aGUgQ0ZSRyBoYXMgcHJvZHVjZWQgZG9jdW1lbnRzIHRoYXQgYXJlIGZvciBsYWNrIG9mIGEg YmV0dGVyIHBocmFzZSBkZSBmYWN0byBzdGFuZGFyZHMuJm5ic3A7IFRoZSByYXRlIG9mIGRvY3Vt ZW50IHByb2R1Y3Rpb24gb2YgdGhlIENGUkcgbWltaWNzIG1vcmUgY2xvc2VseSB0aGF0IG9mIGEg V0cgdGhhbiB0aGUgb3RoZXIgZXh0YW50IFJHcyBBRkFJQ1QuICZuYnNwOyBBcyBhbiBSRyB0aGUN CiBDRlJHIGlzbuKAmXQgcGVybWl0dGVkIHRvIHB1Ymxpc2ggc3RhbmRhcmRzIHRyYWNrIGRvY3Vt ZW50cywgbm9yIGlzIHRoZSBJRVNHIG9yIHRoZSBJU0UgcGVybWl0dGVkIG9yIGNvbnN0cmFpbmVk IHRvIHJlcXVpcmUgYSBjb25mbGljdCByZXZpZXcgb24gdGhlIGRvY3VtZW50cyB0aGUgQ0ZSRyBk b2VzIHByb2R1Y2UuICZuYnNwO1t0aGUgbGF0dGVyIGNvbW1lbnQgaXMgbXkgdW5kZXJzdGFuZGlu ZyBvZiB0aGUgcnVsZXMgb2YgdGhlIHJlc2VhcmNoIHN0cmVhbQ0KIC0gaXQgbWF5IGJlIGZsYXdl ZCwgYnV0IHRoZSBwdXJwb3NlIG9mIFJHcyBpcyBzdXBwb3NlZCB0byBiZSBsb29raW5nIGF0IGZ1 dHVyZXMgYW5kIHRoYXQgYnkgZGVmaW5pdGlvbiBzaG91bGRu4oCZdCBiZSBjb25mbGljdGluZyB3 aXRoIHRoZSBub3dzXS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW4gYWx0ZXJuYXRpdmUgbWlnaHQgYmUgdG8gY2hh cnRlciBhIGNyeXB0byBzdGFuZGFyZHMgV0cgYW5kIHRyeSB0byBrZWVwIHRoZSBDRlJHIGZvY3Vz ZWQgb24geWVhcnMgb3V0IC0gc2F5IGhvdyB0aGUgaGVjayBkbyB3ZSBkZWFsIHdpdGggdGhlIHF1 YW50dW0gYXBvY2FseXBzZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T3Iga2VlcCB0aGUgbWF0aCBpbiBDRlJHIGFuZCB0aGUgb24gdGhlIHdp cmUgc3BlY3MgZm9yIHVzaW5nIGluIGEgV0cuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGlzY3VzcyE8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlrZTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwgTWFyIDEw LCAyMDE5IGF0IDE3OjQ4IFN0ZXBoZW4gRmFycmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZXBo ZW4uZmFycmVsbEBjcy50Y2QuaWUiPnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCkhpeWEsPGJyPg0KPGJyPg0KT24gMTAvMDMvMjAxOSAyMDo1NywgVG9ueSBB cmNpZXJpIHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHRoaW5rIHRoZXJlIGFyZSBzaWdu aWZpY2FudCBjb21wZWxsaW5nIHJlYXNvbnMgdG8gcHJlZmVyIE9DQiBtb2RlIDxicj4NCiZndDsg b3ZlciBwcmV0dHkgbXVjaCBhbGwgb3RoZXIgZXhpc3RpbmcgbW9kZXM6PGJyPg0KPGJyPg0KRldJ VywgSSBkb24ndCwgYmVjYXVzZSB3ZSdyZSBub3QgZGVhbGluZyB3aXRoIGEgY2xlYW4gc2xhdGUu PGJyPg0KPGJyPg0KSW4gdGhlIElFVEYgY29udGV4dCwgd2hldGhlciBvciBub3QgT0NCIGlzIGEg Yml0IGJldHRlcjxicj4NCnRoZW4gY3VycmVudGx5IGRlcGxveWVkIG1vZGVzIGlzIG5vdCBhbiBp bnRlcmVzdGluZzxicj4NCnF1ZXN0aW9uLjxicj4NCjxicj4NCk9uZSBpbnRlcmVzdGluZyBxdWVz dGlvbiBtaWdodCBiZTogaXMgT0NCIHNvIG11Y2ggYmV0dGVyPGJyPg0KdGhhdCBpdCBjb3VsZCB3 ZSBkaXNwbGFjZSB1c2VzIG9mIHNvbWUgZXhpc3RpbmcgbW9kZSB3aXRoPGJyPg0KT0NCLiBUaGF0 IHNlZW1zIHVubGlrZWx5IHRvIG1lIGZvciB0aGUgd2lkZWx5IHVzZWQgbW9kZXMuPGJyPg0KPGJy Pg0KQW5vdGhlciBpbnRlcmVzdGluZyBxdWVzdGlvbiBtaWdodCBiZTogaXMgT0NCIHNvIG11Y2g8 YnI+DQpiZXR0ZXIgdGhhdCB3ZSB3YW50IHRvIGRlcGxveSBpdCBhbG9uZ3NpZGUgY3VycmVudCBt b2Rlcy48YnI+DQpJIGRvbid0IHNlZSB0aGUgb3ZlcmFsbCBiZW5lZml0IG9mIHRoYXQgbXlzZWxm Ljxicj4NCjxicj4NClNvIGV2ZW4gdGhvdWdoIEknbSBoYXBweSB0byBhY2NlcHQgdGhhdCBPQ0Ig aGFzIGJldHRlcjxicj4NCnByb3BlcnRpZXMgdGhhbiBlLmcuIEdDTSwgSSBkb24ndCB0aGluayBp dCdzIHNvIG11Y2g8YnI+DQpiZXR0ZXIgdGhhdCBSRkNzIGZvciBpdCBhcmUgdGhhdCB1c2VmdWwu PGJyPg0KPGJyPg0KVGhhdCBzYWlkLCBpZiB0aGUgUkZDIGZvciBzdWNoIGEgdGhpbmcgc2FpZCAm cXVvdDt0aGlzIGlzIG5pY2U8YnI+DQpmb3IgYnJhbmQgbmV3IHN0dWZmIChhbHRob3VnaCBsaWJy YXJ5IHN1cHBvcnQgd2lsbCBiZSBsZXNzPGJyPg0KY29tcHJlaGVuc2l2ZSkgYnV0IGlzIG5vdCB3 b3J0aCB0aGUgY29zdHMgYXNzb2NpYXRlZDxicj4NCndpdGggYWRkaW5nIGl0IHRvIGV4aXN0aW5n IHByb3RvY29scyZxdW90OyB0aGVuIEknZCBiZSBsZXNzPGJyPg0KYWdhaW5zdCBzdWNoIFJGQ3Mg YmVpbmcgcHJvZHVjZWQuIFVuZGVyc3RhbmRhYmx5IGVub3VnaCw8YnI+DQp0aGF0IGtpbmQgb2Yg c3RhdGVtZW50IGRvZXNuJ3QgZ2V0IGFkZGVkIHRvIHN1Y2ggUkZDczstKTxicj4NCjxicj4NClMu PGJyPg0KPGJyPg0KUFM6IEluIGNhc2UgdGhlIElTRSBpcyBzdGlsbCBsaXN0ZW5pbmcsIHRoZSBh Ym92ZSBpcyBhPGJyPg0KcmVhc29uIHdoeSBJIHRoaW5rIGhhdmluZyBDRlJHIHByb2R1Y2UgdGhp cyBraW5kIG9mIFJGQzxicj4NCihpbnN0ZWFkIG9mIHJvdXRpbmcgJ2VtIHZpYSB0aGUgSVNFKSB3 b3VsZCBiZSBhIGJldHRlcjxicj4NCnBsYW4uIENGUkcgY291bGQgKEkgdGhpbmspIGxpa2VseSBy ZWFjaCBiZXR0ZXIgaW5mb3JtZWQ8YnI+DQpqdWRnZW1lbnRzIChpbiB0aGUgb3BlbikgYXMgdG8g d2hldGhlciBvciBub3Qgc29tZSBjcnlwdG88YnI+DQp0ZWNobmlxdWUgaXMgcmVhbGx5IHdvcnRo IGRvY3VtZW50aW5nIGluIGFuIFJGQy48YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkNmcmcgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOkNmcmdAaXJ0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5DZnJnQGly dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlz dGluZm8vY2ZyZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4v bGlzdGluZm8vY2ZyZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K Q2ZyZyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Q2ZyZ0BpcnRmLm9yZyI+Q2Zy Z0BpcnRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2NmcmciPmh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Zy ZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2935C6E33AE84447BA018DAE0410E5C6ericssoncom_-- From nobody Mon Mar 11 01:07:30 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 19F9A131110 for ; Mon, 11 Mar 2019 01:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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, RCVD_IN_SORBS_WEB=1.5, 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 oAmb_q3Amg8r for ; Mon, 11 Mar 2019 01:07:27 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 831A612E7C1 for ; Mon, 11 Mar 2019 01:07:27 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id z20so3141054ljj.10 for ; Mon, 11 Mar 2019 01:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=93A8QmO/CgdE2hxXTI7PUD6idlJsNSQuI2+Qx9/1iGQ=; b=PALEblpUFBGkc+ALcUGHZSAI5KwrephEUTdCTptEJ51mNRz3szrmObUueFRsQnqYN1 1HcefODNioPHoyHdhJkKZHIIb0Peowtbfc3zWJ8b+9ez49S8wIZfhdzdHFbl/MnDiZ/v VMbLlydCzTXAsdfk/KYHixwwCZBj/49MS1j9Qg8R1NZ/RDFwZykv+OF8bx5xZJ02hu1Q oMm8d3JaoitGja7lDz19n03uW0fQaPTG16EoYl3diiaYWEE3VIQF4F0tLH/ByyZj9dGY Y4d4raUvECGlopRnZ0onWJzIF1Ws0dYyodqiMDIBdv41bCeUT7mxie3Vn4+zuYf2CrR7 uALQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=93A8QmO/CgdE2hxXTI7PUD6idlJsNSQuI2+Qx9/1iGQ=; b=kzqs8pcrjKMVW68yzcqxVHgqCk1t7R5qgAZVi8xCs0ZCa2jGT2BHZMPfur9jBRwHO/ VZsGv+ZhEnYMZZ+5JvkbvhgNUcSlCktD9AJUipr++Ma7I+l/XIUwKEvsHVQWrXav8iV8 1THZ+r5qulUL4usroXXnnLQ2ZnXsjGPqMXPNDXwotmsPdKhuYvmNDwpMnnNcIG8BiN86 wm6k7u8ohvCqh6/9aCByGNeu0r0U2Pf4l80EfRSV1qTeNbzV6HUCDTtU6oOflubcexA4 5R37TmhhLEn5JRNJamipgeuVQ4iFLJySI4V9U58GDLhZro+D0GgPNVpTrMN+sfMsDCPX o2pw== X-Gm-Message-State: APjAAAUzIfOLeiWRLMievJlqQHPW32QbZim3jb3ZTXCQba87hj/fJ7Vm J4MQcv7Z1y0RUfaQDngJlvvHU31yvRo= X-Google-Smtp-Source: APXvYqwAxMASxmizo7qnOj2MnH7S32anMD6OpUsmTaWSdG4iXElaTrFCHrimYoOVo/bs2O+NS3OAOA== X-Received: by 2002:a2e:680e:: with SMTP id c14mr15892177lja.51.1552291645632; Mon, 11 Mar 2019 01:07:25 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id v11sm988558lfb.46.2019.03.11.01.07.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 11 Mar 2019 01:07:24 -0700 (PDT) From: "Valery Smyslov" To: "'Benjamin Kaduk'" , "'Ted Krovetz'" Cc: "'CFRG'" , "'RFC ISE \(Adrian Farrel\)'" , "'secdir'" References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> In-Reply-To: <20190310191026.GF8182@kduck.mit.edu> Date: Mon, 11 Mar 2019 11:07:22 +0300 Message-ID: <000f01d4d7e1$754d9860$5fe8c920$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFR7KiXFNK9itpDJGz5yYnU0UYjRAItmKofAywlCAUCaJN77wIn2QiWAZXTQ3gCOjM0MKaeFUAg Content-Language: ru Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts 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, 11 Mar 2019 08:07:29 -0000 Hi Ben, > > I would like to remind everyone that OCB is not a "new mode". It is specified in RFC 7253. This work > generalizes the specification -- without changing the 128-bit block case -- to allow other block cipher block > lengths. > > It's still a "distinct choice that a protocol designer (or user) picking a > cipher has available to choose from", which is where the perceived downside > of new things comes from. My apologies for conflating the technical term > with the generic. I agree that having more options generally complicates protocol designer's life. Unless the choices have really different properties (it terms of security, performance, resources consumption etc.) which are clearly explained, so that the designer can make a conscious choice. Regards, Valery. > -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 Mar 11 02:27: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 DFC5E130F39 for ; Mon, 11 Mar 2019 02:27:35 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 XpGkHiNNIUrV for ; Mon, 11 Mar 2019 02:27:33 -0700 (PDT) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 076B51310BE for ; Mon, 11 Mar 2019 02:27:33 -0700 (PDT) Received: by mail-oi1-x236.google.com with SMTP id g16so3062829oib.1 for ; Mon, 11 Mar 2019 02:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eoMwbqPNW35+PvN9l6eZGxLgGb381umfC5+L4jASYR8=; b=ZkCv561e71OuTB3pWFV9aRHgwNaorPYZMJNZ2nzzrTtb+Qslnsth86g2yfl5+s4ZoV 08BF4dYe50gxQOj1fDXShtt8sQbakKKEeZbe8vJfTMbCK7/g82ZAI8Z0N82As5nZh1+z EE56dl2Pba5i1hLkESKVMatZ9u/E9DtCNOlXoAe6y41tZ53hJH4Hy7CLUl3lxuHxTVV7 +WXXwqZpmwvnTPsd5SK5Lu+bSqJPWko940YE53Jlpm5WmGquU0R5WRSIH4UzHhfHw/bt M1qXjKGg8waFZiCUITqlMfkkMqTfQgBzU0fB+yzRzeQi1hUSWS0CR8MZo0fnSuCYNLJf laJg== 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=eoMwbqPNW35+PvN9l6eZGxLgGb381umfC5+L4jASYR8=; b=P6/mItluOcSDkASJlHGa1iDhGMUNpd0eFqGCxEjXtDoW5MHwGFHFFj4AHJqU2UbhAb Ix8CuHL9zUeJJt2x2BKEbGjMAAqMs4rxnmhnq3pTmiS1F1yGa4v/eglUVOUvmKMp6maQ Kzaol6l6gry4wd/zHMCLAbArqpO6dk+/sogtwKbJBWpTa/RCP9K7tWIe5ag2/rzWsmcF Arf/p6Y9R+TelARA54/koWjzn1TjKCBm2dDHRkLLGNPrVn49Rk5ZtgdIIzrA4tZXMz+L 7izeY14X6TYVMysPc+w78l7t7CmhDbYEiWmLw/UVP6besIRfL4AYYsQDcpP/QWcGW6jr +X4g== X-Gm-Message-State: APjAAAU5XbLa6LwXFj2shEWOGcG331xe2xggJSc6lijH5tdph3r6Ib1f KrQxecS2P9lxO+jrFE7mkyzjvFhqJEa4MyySTdM= X-Google-Smtp-Source: APXvYqxGRYTuo4ilsrdxHdKSexWTpv/uFSB/eRW2fxR+OgVgCJXgCizZ6Kw90/cKY5c/Liphk8scrQYA3PzAj76A76w= X-Received: by 2002:aca:ecd5:: with SMTP id k204mr15360692oih.153.1552296452223; Mon, 11 Mar 2019 02:27:32 -0700 (PDT) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> In-Reply-To: From: Mathy Vanhoef Date: Mon, 11 Mar 2019 13:27:21 +0400 Message-ID: To: Tony Arcieri Cc: "StJohns, Michael" , secdir , CFRG , "RFC ISE (Adrian Farrel)" Content-Type: multipart/alternative; boundary="0000000000009ef9580583ce2ed2" Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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, 11 Mar 2019 09:27:45 -0000 --0000000000009ef9580583ce2ed2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Regarding the Dragonfly datapoint: this protocol already got added to the 802.11 standard in 2011 under the 802.11s amendment. As far as I know, I only got discussed by the CFRG after this. On Mon, Mar 11, 2019 at 3:20 AM Tony Arcieri wrote: > On Sun, Mar 10, 2019 at 3:46 PM StJohns, Michael > wrote: > >> In recent years, the CFRG has produced documents that are for lack of a >> better phrase de facto standards. The rate of document production of th= e >> CFRG mimics more closely that of a WG than the other extant RGs AFAICT. >> As an RG the CFRG isn=E2=80=99t permitted to publish standards track doc= uments, nor >> is the IESG or the ISE permitted or constrained to require a conflict >> review on the documents the CFRG does produce. [the latter comment is m= y >> understanding of the rules of the research stream - it may be flawed, bu= t >> the purpose of RGs is supposed to be looking at futures and that by >> definition shouldn=E2=80=99t be conflicting with the nows]. >> > > An interesting datapoint on this is Dragonfly key exchange, published as > RFC 7664, has now been incorporated into the Wifi Alliance's WPA3 standar= d: > > https://sarwiki.informatik.hu-berlin.de/WPA3_Dragonfly_Handshake > > I will preface the following statement by saying that my criticisms of > Dragonfly on the CFRG list at the time were misinformed and due to a lack > of understanding, and would now call it "okay" (and many of my concerns > were assuaged after it received a security proof).. However, I think it's > fair to say that as a non-standards document, it has something of a sordi= d > history: > > > https://arstechnica.com/information-technology/2013/12/critics-nsa-agent-= co-chairing-key-crypto-standards-body-should-be-removed/ > > I think if there were a WG chartered specifically with a standards-track > document for what the next generation key exchange to be used for use cas= es > similar to and including, but not limited to WiFi were, my best guess is = we > could've done better than Dragonfly. I'm not sure why the Wifi Alliance > chose it specifically, but it seems the CFRG was treated at least in part > as a bar the algorithm must pass for incorporation into their standards, > and for a standard of such importance I guess what I'm saying is I wish > that bar were higher. > > -- > Tony Arcieri > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --0000000000009ef9580583ce2ed2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Regarding the Dragonfly datapoint: this protocol alre= ady got added to the 802.11 standard in 2011 under the 802.11s amendment. A= s far as I know, I only got discussed by the CFRG after this.

On M= on, Mar 11, 2019 at 3:20 AM Tony Arcieri <bascule@gmail.com> wrote:
=
On Sun, Mar 10, 2019 at 3:46 PM StJohns, Michael <msj@nthpermutation.c= om> wrote:
In recent years, the CFRG has produced = documents that are for lack of a better phrase de facto standards.=C2=A0 Th= e rate of document production of the CFRG mimics more closely that of a WG = than the other extant RGs AFAICT. =C2=A0 As an RG the CFRG isn=E2=80=99t pe= rmitted to publish standards track documents, nor is the IESG or the ISE pe= rmitted or constrained to require a conflict review on the documents the CF= RG does produce. =C2=A0[the latter comment is my understanding of the rules= of the research stream - it may be flawed, but the purpose of RGs is suppo= sed to be looking at futures and that by definition shouldn=E2=80=99t be co= nflicting with the nows].

An in= teresting datapoint on this is Dragonfly key exchange, published as RFC 766= 4, has now been incorporated into the Wifi Alliance's WPA3 standard:


I will = preface the following statement by saying that my criticisms of Dragonfly o= n the CFRG list at the time were misinformed and due to a lack of understan= ding, and would now call it "okay" (and many of my concerns were = assuaged after it received a security proof).. However, I think it's fa= ir to say that as a non-standards document, it has something of a sordid hi= story:


I think if there wer= e a WG chartered specifically with a standards-track document for what the = next generation key exchange to be used for use cases similar to and includ= ing, but not limited to WiFi were, my best guess is we could've done be= tter than Dragonfly. I'm not sure why the Wifi Alliance chose it specif= ically, but it seems the CFRG was treated at least in part as a bar the alg= orithm must pass for incorporation into their standards, and for a standard= of such importance I guess what I'm saying is I wish that bar were hig= her.

--
Tony Arcieri
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
--0000000000009ef9580583ce2ed2-- From nobody Mon Mar 11 06:07:00 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 A934C127984; Mon, 11 Mar 2019 06:06:58 -0700 (PDT) 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_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 vhd97e9bCT6j; Mon, 11 Mar 2019 06:06:56 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 F3702124BF6; Mon, 11 Mar 2019 06:06:55 -0700 (PDT) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id E89C651763996A64A8C0; Mon, 11 Mar 2019 13:06:53 +0000 (GMT) Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 11 Mar 2019 13:06:53 +0000 Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.251]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0415.000; Mon, 11 Mar 2019 21:06:45 +0800 From: "Roni Even (A)" To: "steve@hannas.com" , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-mmusic-data-channel-sdpneg.all@ietf.org" Thread-Topic: Secdir Last Call Review of draft-ietf-mmusic-data-channel-sdpneg-24 Thread-Index: AdTXot6upCK+Lt3iTkODqB4rHpbPhgAZ6ftg Date: Mon, 11 Mar 2019 13:06:45 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18CC58D1@dggemm526-mbx.china.huawei.com> References: <03dd01d4d7a3$23a209d0$6ae61d70$@hannas.com> In-Reply-To: <03dd01d4d7a3$23a209d0$6ae61d70$@hannas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [secdir] Secdir Last Call Review of draft-ietf-mmusic-data-channel-sdpneg-24 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, 11 Mar 2019 13:06:59 -0000 HI Steve, Thanks for the review. I will update the document. As for the nits, it is m= y fault for not noticing these nits, will fix all of them and some of the c= o-authors are native English speakers. Roni -----Original Message----- From: Steve Hanna [mailto:steve01@hannas.com]=20 Sent: Monday, March 11, 2019 2:41 AM To: iesg@ietf.org; secdir@ietf.org; draft-ietf-mmusic-data-channel-sdpneg.a= ll@ietf.org Subject: Secdir Last Call Review of draft-ietf-mmusic-data-channel-sdpneg-2= 4 Review result: Ready with nits Reviewer: Steve Hanna I reviewed this document as part of the Security Directorate's ongoing effo= rt to review all IETF documents being processed by the IESG. These comment= s were written primarily for the benefit of the Security Area Directors. D= ocument authors, document editors, and WG chairs should treat these comment= s just like any other IETF Last Call comments. This document specifies how the SDP (Session Description Protocol) offer/an= swer exchange can be used to achieve an out-of-band non-DCEP negotiation fo= r establishing a data channel. Major Concerns: None Minor Concerns: The last sentence in the Security Considerations section says: Error cases like the use of unknown parameter values or violation the odd/even rule must be handled by closing the corresponding Data Channel. I suspect that the "must" in this sentence should be "MUST". Nothing else i= n the document seems to state this requirement but it does seem necessary. Nits: This document has many small English language errors. For example, the fir= st paragraph of the Introduction has three things that need to be corrected: - s/a bi-directional data channels/bi-directional data channels/ - s/prtocols/protocols/ - s/an endpoint applications/endpoint applications/ Please enlist a native English speaker as a proofreader. From nobody Mon Mar 11 08:20:24 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 E6378131188; Mon, 11 Mar 2019 08:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 o802RQMfWe3Q; Mon, 11 Mar 2019 08:20:08 -0700 (PDT) Received: from smtprelay.hostedemail.com (smtprelay0105.hostedemail.com [216.40.44.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35C7E13119B; Mon, 11 Mar 2019 08:19:58 -0700 (PDT) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay05.hostedemail.com (Postfix) with ESMTP id D50281803A126; Mon, 11 Mar 2019 15:19:56 +0000 (UTC) X-Session-Marker: 737465766530314068616E6E61732E636F6D X-Spam-Summary: 40, 2.5, 0, , d41d8cd98f00b204, steve01@hannas.com, :::::::::, RULES_HIT:10:41:355:379:541:542:599:800:960:973:982:988:989:1155:1260:1277:1311:1313:1314:1345:1359:1381:1437:1515:1516:1518:1534:1543:1587:1593:1594:1711:1730:1747:1777:1792:2198:2199:2393:2551:2553:2559:2562:2692:2693:2894:2895:2906:2911:2924:2926:3138:3139:3140:3141:3142:3355:3622:3865:3866:3867:3868:3870:3871:3872:3874:4250:4362:4425:5007:6119:7576:7903:8660:9545:10011:10400:10848:11658:11914:11984:12043:12048:12050:12109:12114:12663:12679:12760:12895:13019:13071:13095:13148:13161:13163:13229:13230:13439:13846:14040:14096:14097:14180:14181:14195:14721:21060:21080:21212:21324:21433:21451:21627:30006:30045:30054:30063:30070:30090:30091, 0, RBL:error, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:1:0, LFtime:33, LUA_SUMMARY:none X-HE-Tag: map49_56b97d027765d X-Filterd-Recvd-Size: 4184 Received: from DESKTOP1IV8FA2 (184-088-010-175.res.spectrum.com [184.88.10.175]) (Authenticated sender: steve01@hannas.com) by omf10.hostedemail.com (Postfix) with ESMTPA; Mon, 11 Mar 2019 15:19:55 +0000 (UTC) Reply-To: From: "Steve Hanna" To: "'Roni Even \(A\)'" , , , , References: <03dd01d4d7a3$23a209d0$6ae61d70$@hannas.com> <6E58094ECC8D8344914996DAD28F1CCD18CC58D1@dggemm526-mbx.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD18CC58D1@dggemm526-mbx.china.huawei.com> Date: Mon, 11 Mar 2019 11:19:55 -0400 Message-ID: <049c01d4d81d$e3549750$a9fdc5f0$@hannas.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: AQKBpg92gi45b3wQuPvusgxbCadv6wFksx+TpKHIPIA= Archived-At: Subject: Re: [secdir] Secdir Last Call Review of draft-ietf-mmusic-data-channel-sdpneg-24 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, 11 Mar 2019 15:20:16 -0000 Roni, Thanks for taking my feedback in such a positive manner. That's just how I intended it. The document is well written and pretty easy to understand. I especially appreciated Appendix A, which helped me avoid needing to read many other documents. I can't provide any technical feedback because I'm not an expert in your domain. But I can say that from a security perspective, your explanation makes sense to me. As for the English language nits, there seem to be 1-2 in every paragraph. If your co-authors don't see many, please invite someone who does copyediting or proofreading to review the document. They'll find lots more like the ones that I cited. These don't substantially impeded the comprehension of the document but they slow down the reader and in some cases could lead to confusion (especially with agreement errors like the first and third nit that I cited). Thanks, Steve -----Original Message----- From: Roni Even (A) Sent: Monday, March 11, 2019 9:07 AM To: steve@hannas.com; iesg@ietf.org; secdir@ietf.org; draft-ietf-mmusic-data-channel-sdpneg.all@ietf.org Subject: RE: Secdir Last Call Review of draft-ietf-mmusic-data-channel-sdpneg-24 HI Steve, Thanks for the review. I will update the document. As for the nits, it is my fault for not noticing these nits, will fix all of them and some of the co-authors are native English speakers. Roni -----Original Message----- From: Steve Hanna [mailto:steve01@hannas.com] Sent: Monday, March 11, 2019 2:41 AM To: iesg@ietf.org; secdir@ietf.org; draft-ietf-mmusic-data-channel-sdpneg.all@ietf.org Subject: Secdir Last Call Review of draft-ietf-mmusic-data-channel-sdpneg-24 Review result: Ready with nits Reviewer: Steve Hanna 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. This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve an out-of-band non-DCEP negotiation for establishing a data channel. Major Concerns: None Minor Concerns: The last sentence in the Security Considerations section says: Error cases like the use of unknown parameter values or violation the odd/even rule must be handled by closing the corresponding Data Channel. I suspect that the "must" in this sentence should be "MUST". Nothing else in the document seems to state this requirement but it does seem necessary. Nits: This document has many small English language errors. For example, the first paragraph of the Introduction has three things that need to be corrected: - s/a bi-directional data channels/bi-directional data channels/ - s/prtocols/protocols/ - s/an endpoint applications/endpoint applications/ Please enlist a native English speaker as a proofreader. From nobody Tue Mar 12 10:33: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 1F57313129D; Tue, 12 Mar 2019 10:33:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Samuel Weiler via Datatracker To: Cc: draft-faltstrom-unicode11.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155241199508.20149.7171940003511163585@ietfa.amsl.com> Date: Tue, 12 Mar 2019 10:33:15 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-faltstrom-unicode11-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, 12 Mar 2019 17:33:15 -0000 Reviewer: Samuel Weiler Review result: Has Nits I feel like there ought to be more to say about the specific cases handled in this doc, but they look sufficiently similar to others that I'm content with the reference to other docs' security considerations. I reviewed -08, which has been updated in response to other LC comments. There are some nits - I'll send those to the editor separately, though RFC Editor will also catch them. From nobody Tue Mar 12 11:11:43 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 D79591277E7 for ; Tue, 12 Mar 2019 11:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.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 6MGeasXJlrQF for ; Tue, 12 Mar 2019 11:11:34 -0700 (PDT) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (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 61DCA131184 for ; Tue, 12 Mar 2019 11:11:34 -0700 (PDT) Received: by mail-qt1-x842.google.com with SMTP id v10so3640816qtp.8 for ; Tue, 12 Mar 2019 11:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=RpLxjaj1Ab0IMDAlmYGmLBBWIJWCn+uZI1xSu5SsEIg=; b=P36CLjAUEU+vCtCRE55KSGFR2/vUc7wwwLId6XxBD2jXCh6O/hHakineieTNmguQEb ai3WK8OxBzDqX4cBPg8DR3JheCdCJZbAGq5CIHoVfxJdyR70NfqTrneauL+BbPOrJlgw InN3mD6qSbnlm5KiATdVRPFYqXWEV1PNahQfJPUYTX0Ih/zae2+BFS1ZymXX/m7PgQv2 5Jr1iZBqsIXknNiFdof4/15UzPIBx0ubapf/sJTkTSTwSXHgoS/GBeLjUuwHtrk+7OF2 pWcTrzFeLx5oGpL9eoBLht3EcHHhHVrFystEJCk5xJO6z1MO0bo/XnoLQHxRR8UApwDI OFfQ== 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-language; bh=RpLxjaj1Ab0IMDAlmYGmLBBWIJWCn+uZI1xSu5SsEIg=; b=AZwhTXRimyZt/hF/Vd25M7mlGcxy57XutXaP0Y1in4Y9aoaOoRYRm6TBk1O/C5KSaz CZMT6UQkA/ojLGtweJplD/Li688NraYhfUr1z2RykDKoKNT8p1PgZIr6Rzl/Ij+Z+2r9 KsSi5CF6JaLJaoIJckIdqxm1xG/bQ4SlXfRFEHFgsZg+2AYFswgbJPxucfrKQzfyWX9V cDG/7tEkFIXnA/27xD6xB4/pwNdl1kTvpdqEFODO6s9jWepGrB3hkoVvs4SbYxnKHBxK p1pihOljfAHTfn+O+cJyA02HTiiemZUfGMms/Q0dNXEJCNUgmvqaS536jFkMaYZX2e+Q 9jEw== X-Gm-Message-State: APjAAAUVWF9KIOMNq1WEI+N9jYQBsUCBOAIIbJ9PA2iXWBegrNE/OJnF i1IxJIYT0oWAlG09zkkAlOO1GY7InSc= X-Google-Smtp-Source: APXvYqy4r+LEhSqXczKWNXjOASE5k++/hfrKFAff5dlUV1sRLec646L1CBt9sqL1sxPIzwNnGqOF2w== X-Received: by 2002:ac8:3f46:: with SMTP id w6mr32036162qtk.175.1552414293067; Tue, 12 Mar 2019 11:11:33 -0700 (PDT) Received: from ?IPv6:2601:152:4400:4013:44d2:dbe7:595a:139? ([2601:152:4400:4013:44d2:dbe7:595a:139]) by smtp.gmail.com with ESMTPSA id g123sm13114863qkg.0.2019.03.12.11.11.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Mar 2019 11:11:32 -0700 (PDT) To: "Blumenthal, Uri - 0553 - MITLL" Cc: Stephen Farrell , CFRG , "RFC ISE (Adrian Farrel)" , secdir References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> From: Michael StJohns Message-ID: <68429ea0-cc13-4c39-8c4c-cb741befa590@nthpermutation.com> Date: Tue, 12 Mar 2019 14:11:30 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> Content-Type: multipart/alternative; boundary="------------C64163497402539D2C0169DA" Content-Language: en-US Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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, 12 Mar 2019 18:11:37 -0000 This is a multi-part message in MIME format. --------------C64163497402539D2C0169DA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 3/10/2019 7:38 PM, Blumenthal, Uri - 0553 - MITLL wrote: > I do not think CFRG should move to become a part of the IETF. > > While (some of) the CFRG-produced documents may be de-facto standards, > they aren't of the kind that IETF is expected to define, and deal with > somewhat different things. My point is that the CFRG is behaving more like a WG and should be following WG rules and not RG rules.    The charter for the CFRG basically says it can bring stuff that's been published elsewhere ("... via Informational RFCs (in the tradition of, e.g., RFC 1321 (MD5) and RFC 2104 (HMAC)."), but has become the first publisher for a few things that weren't mere republications but involved setting on-the-wire/on disk formats (e.g., Curve25519 and related) that have been accepted as de-facto standards.  Then there's the requirements setting documents.  If these were just math publications with the bits and bytes formats published in the IETF, that would be fine - but that doesn't appear to be what's happening. Now Stephen is suggesting that the CFRG become the filter through which all crypto related things are brought to the IETF or independent stream.  Two things - CFRG is not in the IETF, and that's not the general purpose of a research group.   Rechartering the CFRG (or part of it) as a WG following WG rules would at least fix that problem. A third possibility (the first was rechartering, the second was splitting into a IETF WG and an IRTF RG), is dual chartering the CFRG as both a RG and a WG. It would allow/require the group to produce actual standards, but also to keep on with it's more researchy tasks. The fourth possibility is doing a better job of referring the less research/more practical bit and byte on the wire documents to the IETF rather than keeping them and also leave the filtering to the IETF groups such as secdispatch or saag. Later, Mike > > Regards, > Uri > > Sent from my iPhone > > On Mar 10, 2019, at 18:46, StJohns, Michael > wrote: > >> I’ve been wondering for a while now whether it’s time to move the >> CFRG over to the IETF as a working group.  Stephen’s comment on >> routing stuff directly to the CFRG suggests to me that it’s probably >> time or RSN. >> >>    In recent years, the CFRG has produced documents that are for lack >> of a better phrase de facto standards.  The rate of document >> production of the CFRG mimics more closely that of a WG than the >> other extant RGs AFAICT.   As an RG the CFRG isn’t permitted to >> publish standards track documents, nor is the IESG or the ISE >> permitted or constrained to require a conflict review on the >> documents the CFRG does produce.  [the latter comment is my >> understanding of the rules of the research stream - it may be flawed, >> but the purpose of RGs is supposed to be looking at futures and that >> by definition shouldn’t be conflicting with the nows]. >> >> An alternative might be to charter a crypto standards WG and try to >> keep the CFRG focused on years out - say how the heck do we deal with >> the quantum apocalypse? >> >> Or keep the math in CFRG and the on the wire specs for using in a WG. >> >> >> >> Discuss! >> >> Mike >> >> On Sun, Mar 10, 2019 at 17:48 Stephen Farrell >> > wrote: >> >> >> >> PS: In case the ISE is still listening, the above is a >> reason why I think having CFRG produce this kind of RFC >> (instead of routing 'em via the ISE) would be a better >> plan. CFRG could (I think) likely reach better informed >> judgements (in the open) as to whether or not some crypto >> technique is really worth documenting in an RFC. >> --------------C64163497402539D2C0169DA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 3/10/2019 7:38 PM, Blumenthal, Uri - 0553 - MITLL wrote:
I do not think CFRG should move to become a part of the IETF. 

While (some of) the CFRG-produced documents may be de-facto standards, they aren't of the kind that IETF is expected to define, and deal with somewhat different things.

My point is that the CFRG is behaving more like a WG and should be following WG rules and not RG rules.    The charter for the CFRG basically says it can bring stuff that's been published elsewhere ("... via Informational RFCs (in the tradition of, e.g., RFC 1321 (MD5) and RFC 2104 (HMAC)."), but has become the first publisher for a few things that weren't mere republications but involved setting on-the-wire/on disk formats (e.g., Curve25519 and related) that have been accepted as de-facto standards.  Then there's the requirements setting documents.  If these were just math publications with the bits and bytes formats published in the IETF, that would be fine - but that doesn't appear to be what's happening.

Now Stephen is suggesting that the CFRG become the filter through which all crypto related things are brought to the IETF or independent stream.  Two things - CFRG is not in the IETF, and that's not the general purpose of a research group.   Rechartering the CFRG (or part of it) as a WG following WG rules would at least fix that problem. 

A third possibility (the first was rechartering, the second was splitting into a IETF WG and an IRTF RG), is dual chartering the CFRG as both a RG and a WG. It would allow/require the group to produce actual standards, but also to keep on with it's more researchy tasks.

The fourth possibility is doing a better job of referring the less research/more practical bit and byte on the wire documents to the IETF rather than keeping them and also leave the filtering to the IETF groups such as secdispatch or saag.

Later, Mike


Regards,
Uri

Sent from my iPhone

On Mar 10, 2019, at 18:46, StJohns, Michael <msj@nthpermutation.com> wrote:

I’ve been wondering for a while now whether it’s time to move the CFRG over to the IETF as a working group.  Stephen’s comment on routing stuff directly to the CFRG suggests to me that it’s probably time or RSN. 

   In recent years, the CFRG has produced documents that are for lack of a better phrase de facto standards.  The rate of document production of the CFRG mimics more closely that of a WG than the other extant RGs AFAICT.   As an RG the CFRG isn’t permitted to publish standards track documents, nor is the IESG or the ISE permitted or constrained to require a conflict review on the documents the CFRG does produce.  [the latter comment is my understanding of the rules of the research stream - it may be flawed, but the purpose of RGs is supposed to be looking at futures and that by definition shouldn’t be conflicting with the nows].  

An alternative might be to charter a crypto standards WG and try to keep the CFRG focused on years out - say how the heck do we deal with the quantum apocalypse?

Or keep the math in CFRG and the on the wire specs for using in a WG.  



Discuss!

Mike

On Sun, Mar 10, 2019 at 17:48 Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


PS: In case the ISE is still listening, the above is a
reason why I think having CFRG produce this kind of RFC
(instead of routing 'em via the ISE) would be a better
plan. CFRG could (I think) likely reach better informed
judgements (in the open) as to whether or not some crypto
technique is really worth documenting in an RFC.


--------------C64163497402539D2C0169DA-- From nobody Tue Mar 12 11:57:18 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 C4B1A1312F0 for ; Tue, 12 Mar 2019 11:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 7eEoPAqxrlxK for ; Tue, 12 Mar 2019 11:57:07 -0700 (PDT) Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) (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 255511312F4 for ; Tue, 12 Mar 2019 11:57:07 -0700 (PDT) Received: by mail-oi1-x243.google.com with SMTP id j10so2971465oij.13 for ; Tue, 12 Mar 2019 11:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sFmBZEM/zuqQP2E1gfp5ze5nbOG0R95fZceBCRQ5ipo=; b=p+amasmqmBLCBj/U8/4idsxuvfpj/gO7UtM/czOucHfRX78AURkxQnotby6Tdwmiw9 RW9g3JYjQmk0DEhNE86AVqPp5A1TY+RmAUDaxdnOE+w5x3lfhqR3O74yhWLqSTEd7G9w 0XPajoR58Qm1ETyZ3MHHnq76HkdOWJsLkz2iXGBSpI6jtf9hiAFwxvVaoJ/Low7BuUc4 JnWpstcvUCPUhJUTYtGp/paxRZkSzpUJ1NrJ7Z7Kcdgh8fdC1odLjY/KqrdAY9VWU3+o +OAwE6JklW7zOpHfsr88QAZ74VBKhLvcMcVr9NgZe3xs/tr85xsBu5KFO/Cahi2uVXsb 851w== 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=sFmBZEM/zuqQP2E1gfp5ze5nbOG0R95fZceBCRQ5ipo=; b=jE0bpRIBtwL4rWItERS0XCflxSFovV7AHz1LpHbl71UmgyqVkPXLmCfLc+Yu/3OXiv cAH4XxMY+E+MVx7KrIXstwsaRny2lmpQmbXO333RK+k7NV6XJ5hTlt2iJqdFSuVO1J9g MG+k6HlKfsceZA2rziR4YbG85t9cFHBkxa6vRG9Q5eARXC9mSk9u+1ZpANZ5HAMhuxuX Ymtbtt+KDcLWPshqlnnDGJUHRQ7avxTJv+htPxZqHF2Z/Ia88Ap73gnyeRtk0rVRTv9u XolKlpqFUhGDOQwtSXk86eJzCBOBiZ8nEA9JnYdrK7uRwsv29j78iiQkflNErX9FXxeR 7zmA== X-Gm-Message-State: APjAAAVnAyQ2Mv9iLKeGDkYH7c+mHqGWOIwCaq7/kIVsFQCXGmYdGZzM 0WQuhJOUCXNXmWVYLYjh39pujJd8HhOiedPwSYbGIA== X-Google-Smtp-Source: APXvYqzJVkJZbDu0D/LtWy68ps0iN3FyDYP2Qt+ljXPCRMvlVABQJjyeSFEgmQRoGPbcVtHxMYERPLSBEuj0PF2d7VQ= X-Received: by 2002:aca:f5c2:: with SMTP id t185mr2463201oih.135.1552417026274; Tue, 12 Mar 2019 11:57:06 -0700 (PDT) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> In-Reply-To: <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> From: Richard Barnes Date: Tue, 12 Mar 2019 14:56:38 -0400 Message-ID: To: John Mattsson Cc: "Blumenthal, Uri - 0553 - MITLL" , "StJohns, Michael" , CFRG , "RFC ISE (Adrian Farrel)" , secdir Content-Type: multipart/alternative; boundary="0000000000006512ba0583ea41cb" Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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, 12 Mar 2019 18:57:10 -0000 --0000000000006512ba0583ea41cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Big +1 here. It's not broke, so let's not fix it, especially for purely process-wonk reasons. On Mon, Mar 11, 2019 at 3:08 AM John Mattsson wrote: > I think it is much more important that CFRG stays a Research Group, than > it is that CFRG can produce standards track documents. CFRG is unique and > fills a very important roll. The fact that CFRG documents are used so muc= h > indicates to me that CFRG is working very well. I would be very hesitant = in > changing something that works. > > > > Cheers, > > John > > > > *From: *Cfrg on behalf of "Blumenthal, Uri - 0553 > - MITLL" > *Date: *Monday, 11 March 2019 at 00:39 > *To: *"StJohns, Michael" > *Cc: *secdir , CFRG , "RFC ISE (Adrian > Farrel)" > *Subject: *Re: [Cfrg] Time to recharter CFRG as a working group? Was: Re: > [secdir] ISE seeks help with some crypto drafts > > > > I do not think CFRG should move to become a part of the IETF. > > > > While (some of) the CFRG-produced documents may be de-facto standards, > they aren't of the kind that IETF is expected to define, and deal with > somewhat different things. > > Regards, > > Uri > > > > Sent from my iPhone > > > On Mar 10, 2019, at 18:46, StJohns, Michael > wrote: > > I=E2=80=99ve been wondering for a while now whether it=E2=80=99s time to = move the CFRG > over to the IETF as a working group. Stephen=E2=80=99s comment on routin= g stuff > directly to the CFRG suggests to me that it=E2=80=99s probably time or RS= N. > > > > In recent years, the CFRG has produced documents that are for lack of = a > better phrase de facto standards. The rate of document production of the > CFRG mimics more closely that of a WG than the other extant RGs AFAICT. > As an RG the CFRG isn=E2=80=99t permitted to publish standards track docu= ments, nor > is the IESG or the ISE permitted or constrained to require a conflict > review on the documents the CFRG does produce. [the latter comment is my > understanding of the rules of the research stream - it may be flawed, but > the purpose of RGs is supposed to be looking at futures and that by > definition shouldn=E2=80=99t be conflicting with the nows]. > > > > An alternative might be to charter a crypto standards WG and try to keep > the CFRG focused on years out - say how the heck do we deal with the > quantum apocalypse? > > > > Or keep the math in CFRG and the on the wire specs for using in a WG. > > > > > > > > Discuss! > > > > Mike > > > > On Sun, Mar 10, 2019 at 17:48 Stephen Farrell > wrote: > > > Hiya, > > On 10/03/2019 20:57, Tony Arcieri wrote: > > > > I think there are significant compelling reasons to prefer OCB mode > > over pretty much all other existing modes: > > FWIW, I don't, because we're not dealing with a clean slate. > > In the IETF context, whether or not OCB is a bit better > then currently deployed modes is not an interesting > question. > > One interesting question might be: is OCB so much better > that it could we displace uses of some existing mode with > OCB. That seems unlikely to me for the widely used modes. > > Another interesting question might be: is OCB so much > better that we want to deploy it alongside current modes. > I don't see the overall benefit of that myself. > > So even though I'm happy to accept that OCB has better > properties than e.g. GCM, I don't think it's so much > better that RFCs for it are that useful. > > That said, if the RFC for such a thing said "this is nice > for brand new stuff (although library support will be less > comprehensive) but is not worth the costs associated > with adding it to existing protocols" then I'd be less > against such RFCs being produced. Understandably enough, > that kind of statement doesn't get added to such RFCs;-) > > S. > > PS: In case the ISE is still listening, the above is a > reason why I think having CFRG produce this kind of RFC > (instead of routing 'em via the ISE) would be a better > plan. CFRG could (I think) likely reach better informed > judgements (in the open) as to whether or not some crypto > technique is really worth documenting in an RFC. > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --0000000000006512ba0583ea41cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Big +1 here.=C2=A0 It's not broke, so let's not fi= x it, especially for purely process-wonk reasons.

On Mon, Mar 11, 2019= at 3:08 AM John Mattsson <john.mattsson@ericsson.com> wrote:

I think it is much more importa= nt that CFRG stays a Research Group, than it is that CFRG can produce stand= ards track documents. CFRG is unique and fills a very important roll. The f= act that CFRG documents are used so much indicates to me that CFRG is working very well. I would be very hesit= ant in changing something that works.

=C2=A0

Cheers,

John

=C2=A0

From: = Cfrg <cfrg-bounces@irtf.org>= ; on behalf of "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
Date: Monday, 11 March 2019 at 00:39
To: "StJohns, Michael" <msj@nthpermutation.com>
Cc: secdir <= secdir@ietf.org>, CFRG <cfrg@irtf.org>, "RFC ISE (Adrian Farrel)" <= rfc-ise@rfc-edi= tor.org>
Subject: Re: [Cfrg] Time to recharter CFRG as a working group? Was: = Re: [secdir] ISE seeks help with some crypto drafts

=C2=A0

I do not think CFRG should move to become a part of = the IETF.=C2=A0

=C2=A0

While (some of) the CFR= G-produced documents may be de-facto standards, they aren't of the kind= that IETF is expected to define, and deal with somewhat different things.<= u>

Regards,

Uri

=C2=A0

Sent from my iPhone


On Mar 10, 2019, at 18:46, StJohns, Michael <msj@nthpermutation.com> wrote:

I=E2=80=99ve been wondering for a while now whether = it=E2=80=99s time to move the CFRG over to the IETF as a working group.=C2= =A0 Stephen=E2=80=99s comment on routing stuff directly to the CFRG suggest= s to me that it=E2=80=99s probably time or RSN.=C2=A0

=C2=A0

=C2=A0 =C2=A0In recent years, the CFRG has produced = documents that are for lack of a better phrase de facto standards.=C2=A0 Th= e rate of document production of the CFRG mimics more closely that of a WG = than the other extant RGs AFAICT. =C2=A0 As an RG the CFRG isn=E2=80=99t permitted to publish standards track documents, nor is = the IESG or the ISE permitted or constrained to require a conflict review o= n the documents the CFRG does produce. =C2=A0[the latter comment is my unde= rstanding of the rules of the research stream - it may be flawed, but the purpose of RGs is supposed to be looking at fu= tures and that by definition shouldn=E2=80=99t be conflicting with the nows= ]. =C2=A0

=C2=A0

An alternative might be to charter a crypto standard= s WG and try to keep the CFRG focused on years out - say how the heck do we= deal with the quantum apocalypse?

=C2=A0

Or keep the math in CFRG and the on the wire specs f= or using in a WG. =C2=A0

=C2=A0

=C2=A0

=C2=A0

Discuss!

=C2=A0

Mike

=C2=A0

On Sun, Mar 10, 2019 at 17:48 Stephen Farrell <stephen.farrel= l@cs.tcd.ie> wrote:


Hiya,

On 10/03/2019 20:57, Tony Arcieri wrote:
>
> I think there are significant compelling reasons to prefer OCB mode > over pretty much all other existing modes:

FWIW, I don't, because we're not dealing with a clean slate.

In the IETF context, whether or not OCB is a bit better
then currently deployed modes is not an interesting
question.

One interesting question might be: is OCB so much better
that it could we displace uses of some existing mode with
OCB. That seems unlikely to me for the widely used modes.

Another interesting question might be: is OCB so much
better that we want to deploy it alongside current modes.
I don't see the overall benefit of that myself.

So even though I'm happy to accept that OCB has better
properties than e.g. GCM, I don't think it's so much
better that RFCs for it are that useful.

That said, if the RFC for such a thing said "this is nice
for brand new stuff (although library support will be less
comprehensive) but is not worth the costs associated
with adding it to existing protocols" then I'd be less
against such RFCs being produced. Understandably enough,
that kind of statement doesn't get added to such RFCs;-)

S.

PS: In case the ISE is still listening, the above is a
reason why I think having CFRG produce this kind of RFC
(instead of routing 'em via the ISE) would be a better
plan. CFRG could (I think) likely reach better informed
judgements (in the open) as to whether or not some crypto
technique is really worth documenting in an RFC.


_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
ht= tps://www.irtf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
ht= tps://www.irtf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
--0000000000006512ba0583ea41cb-- From nobody Tue Mar 12 12:03:49 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 DD8CD1278CF for ; Tue, 12 Mar 2019 12:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 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, KHOP_DYNAMIC=1.468, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 ZuqP2PqSX1zI for ; Tue, 12 Mar 2019 12:03:46 -0700 (PDT) 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 65380126F72 for ; Tue, 12 Mar 2019 12:03:46 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x2CJ20Rv016528; Tue, 12 Mar 2019 19:03:43 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=U59VsHORENegbmQ7zs7/cCdgwu29zGF9veWT83L7jyA=; b=j64lWuP7eQOixL3p0jxcYz1UQrX/ylvy9lnIhAEfHWTmWJEeNyieI0txgeQrkypAcBZX EpjaI74aTDJAeLVeGdipJ+NyQ9NIYaqrjlxbwhsIQ8LNFsqBSld7n8eWLVIgEtu4OUBm 2gmQID1+bwcY27JDlERXFASDeSnM8JkvzZuehMkupb1EiyYYLEpDo4RLtb3yKzH+RGHz yehiU72/hXUina5EA3Y3DW0QjgYtrRQ7T+PiKj/rRE93otBN7KsoNn664ZDMMxkIa5Yi HGli5l/JpdYPgGxjZIMouFfGY31uRXBs/QAcEE7fKdSBXnJ00bmyz7lUpon0IYkx1ekW 9w== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2r5vw1vsbp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Mar 2019 19:03:42 +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 x2CJ1uU5023390; Tue, 12 Mar 2019 15:03:42 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2r49q0pabc-7 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 12 Mar 2019 15:03:41 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 12 Mar 2019 14:02:18 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1473.003; Tue, 12 Mar 2019 14:02:18 -0500 From: "Salz, Rich" To: Richard Barnes , John Mattsson CC: secdir , CFRG , "RFC ISE (Adrian Farrel)" Thread-Topic: [Cfrg] Time to recharter CFRG as a working group? Was: Re: [secdir] ISE seeks help with some crypto drafts Thread-Index: AQHU15pvBg+QBzPYkUyJ8PFSg5+S9qYGVsQAgAJYfQD//76GgA== Date: Tue, 12 Mar 2019 19:02:17 +0000 Message-ID: <758B596B-EB0B-4DC4-BB33-07F42FA321A3@akamai.com> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.0.190309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.17] Content-Type: multipart/alternative; boundary="_000_758B596BEB0B4DC4BB3307F42FA321A3akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-12_10:, , 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=716 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903120129 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-12_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=745 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903120129 Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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, 12 Mar 2019 19:03:48 -0000 --_000_758B596BEB0B4DC4BB3307F42FA321A3akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgQmlnICsxIGhlcmUuICBJdCdzIG5vdCBicm9rZSwgc28gbGV0J3Mgbm90IGZpeCBpdCwg ZXNwZWNpYWxseSBmb3IgcHVyZWx5IHByb2Nlc3Mtd29uayByZWFzb25zLg0KDQpTdXBlci1zaW5n dWxhci1pc29nZW55LXN0cm9uZyBhZ3JlZW1lbnQuDQo= --_000_758B596BEB0B4DC4BB3307F42FA321A3akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxOTYzMDc3Mzk3Ow0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxOTMxMDg3MzYyIDg5NzY0NjM1MCA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjE0 NTsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OY Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8dWwgc3R5bGU9Im1hcmdpbi10 b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+QmlnICYjNDM7MSBoZXJl LiZuYnNwOyBJdCdzIG5vdCBicm9rZSwgc28gbGV0J3Mgbm90IGZpeCBpdCwgZXNwZWNpYWxseSBm b3IgcHVyZWx5IHByb2Nlc3Mtd29uayByZWFzb25zLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TdXBlci1zaW5ndWxhci1pc29nZW55LXN0cm9uZyBhZ3JlZW1lbnQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_758B596BEB0B4DC4BB3307F42FA321A3akamaicom_-- From nobody Tue Mar 12 13:31:45 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 D31631310F4 for ; Tue, 12 Mar 2019 13:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA3TikAA2Mcm for ; Tue, 12 Mar 2019 13:31:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27F4C128B14 for ; Tue, 12 Mar 2019 13:31:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F01E6BE5C; Tue, 12 Mar 2019 20:31:36 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63kghlkw8Xq2; Tue, 12 Mar 2019 20:31:35 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 185D4BE3E; Tue, 12 Mar 2019 20:31:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1552422695; bh=TKgtdZXLVeyhnsoj58v1AbtuyUrJf/RW+1ULhioqcI8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=QWk4Pv+FaaoWwjfyHOCZqKPi1Mv/txW7qmqaci128CgpRYsqjmCduU8WA+fRlhIC1 629mk6ZmeAHV0/9PGQfoap4rHB7K0xzI4st+O0tlGIaaIpRV+ZpNJztrjQuv1SZhrS 1ArvXIYOh1I6kIKB4iA/BbRnzutHkNDHVtQfPjg8= To: "Salz, Rich" , Richard Barnes , John Mattsson Cc: CFRG , "RFC ISE (Adrian Farrel)" , secdir References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <758B596B-EB0B-4DC4-BB33-07F42FA321A3@akamai.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <137c6717-7230-9aa8-30b9-f3515b421fee@cs.tcd.ie> Date: Tue, 12 Mar 2019 20:31:33 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <758B596B-EB0B-4DC4-BB33-07F42FA321A3@akamai.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KHG99iYNdoETSYaJVn5sP9GwQLBXB0PlT" Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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, 12 Mar 2019 20:31:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KHG99iYNdoETSYaJVn5sP9GwQLBXB0PlT Content-Type: multipart/mixed; boundary="kHOf73rOY7rOGGPcMXaUSYTWNZ2X1jE0L"; protected-headers="v1" From: Stephen Farrell To: "Salz, Rich" , Richard Barnes , John Mattsson Cc: CFRG , "RFC ISE (Adrian Farrel)" , secdir Message-ID: <137c6717-7230-9aa8-30b9-f3515b421fee@cs.tcd.ie> Subject: Re: [Cfrg] Time to recharter CFRG as a working group? Was: Re: [secdir] ISE seeks help with some crypto drafts References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <758B596B-EB0B-4DC4-BB33-07F42FA321A3@akamai.com> In-Reply-To: <758B596B-EB0B-4DC4-BB33-07F42FA321A3@akamai.com> --kHOf73rOY7rOGGPcMXaUSYTWNZ2X1jE0L Content-Type: multipart/mixed; boundary="------------F9C34159F6F0B647CB78C0DE" Content-Language: en-GB This is a multi-part message in MIME format. --------------F9C34159F6F0B647CB78C0DE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/03/2019 19:02, Salz, Rich wrote: > * Big +1 here. It's not broke, so let's not fix it, especially for= purely process-wonk reasons. >=20 > Super-singular-isogeny-strong agreement. FWIW, I also agree. CFRG's doing well. I see no need for it to be a WG and I think there are advantages in it being an RG, e.g. it may smooth interaction with academic cryptographers a bit. (If there were a groundswell for such a change I'd not object but it doesn't look like it so far.) I would still like to see almost all crypto mechanism related RFCs come via CFRG though and not the ISE. (There'll always be the potential for exceptions so I think "almost all" is about right.) The kind of review one can reasonably expect for ISE publications is no longer sufficient given that we now actually use and depend on this crypto stuff to a far greater extent than say 10 years ago. No disrespect to the ISE, nor the folks who volunteer to help the ISE review stuff, but I'd be happier if we had a more open and transparent process with broader/deeper expertise available for reviewing. (And in fact CFRG does have such a process already.) S. >=20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg >=20 --------------F9C34159F6F0B647CB78C0DE Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------F9C34159F6F0B647CB78C0DE-- --kHOf73rOY7rOGGPcMXaUSYTWNZ2X1jE0L-- --KHG99iYNdoETSYaJVn5sP9GwQLBXB0PlT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyIFyUACgkQWrL68XsX K+rm5g/8DC5BB4d6enswS/2JuNlzizkwWxOIObMOENI+8jjKt498XwAK5HgXNlro gtdU6kzPc92Yi6LuLLsSNjV1HQD21NvBF5J07Rh+TpcSumXyi4Dk/p9Ts6UoXO/Z 4u+rXqROaeFM+iNWIOTba5lJ36hx6ndCXXkdW+nIt8eav4KZ2cT2ZdMZnUKJxkfN GOHEE5QMaAIN/bUaeK2nbXgZNJ7lktFkFz105dal0TjJp2zXUd06CfRbJkL3x0Af g8HsSgfpzCUP2NJBY+C6u46MgkGzuMD7r6RQjMPG+8aZt5V5xtR/HmmsZIplL8g2 DD4kOwMVrI8NGsoDaaXlKxUj+S+0soiOmuAJ87c/Jc94yL5QwZxoZxAz1uMA4pBm LQzyUjKdUl12VEAJDneFfle70pgcN7CFbMvB8unBStHZh7O+FCdtqiuK5D7q3PWP HNYn9vw/vhn0nvYhKDcSzJG+D2cAjKbEGUIa3jU/pSTUn86PqA+B6VuBCeRtv3zE nA5u84Q2RJR4KjYf6JZ1bMPCVzHo+VELBIKXHnC0agG/IHhI3Dy/ni2VEVjcoHvz C7es7f5IzenTSKak7SabUAl5N1f/g+9rQiyuV9T4op5CW1IJwjjPkM14uDpoMhhd /8RfqeYfNXNOu2MdgDve93pZSESPYhN942Km6YgzmEQebwpN5+U= =LxNL -----END PGP SIGNATURE----- --KHG99iYNdoETSYaJVn5sP9GwQLBXB0PlT-- From nobody Tue Mar 12 13:43:15 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 9915A127963 for ; Tue, 12 Mar 2019 13:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.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 cy3Ey6eOwk2x for ; Tue, 12 Mar 2019 13:43:07 -0700 (PDT) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 39292127985 for ; Tue, 12 Mar 2019 13:43:07 -0700 (PDT) Received: by mail-qt1-x844.google.com with SMTP id d2so4188428qti.11 for ; Tue, 12 Mar 2019 13:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=aaSZufDgxjbe8WzxehqBCrac4FotMFDLAxNV1Kny6zw=; b=Zr13Zn9xsuQHVWIBWPyB4LVAQAN4xadyFnqZilrNDtU2nL1oOI8PkyfP3oN4dzJe2x 6yOmW7sZKiVbDFdPKgUvEF3JqO5Lt/J4ejd6AuJcNVKDPevrfUeUVxW2KEamhJgRfxcF 0bY1UPG8/A5VNBRm38KWZujU37Mwe3JNMxSJBrVxTzXiMSQDeyzGbjdiMErY2gn6Pfea CjSp8YKimiEhUVbJCsXS+QoJzs1V0IK3XZ5wPStFqlbyk0vdmcqfMYeo8ECGvMhDeQ3C VmLV/7vjUnGU2WRAW9tFwP+bsVMJRxHv0xJadjGo7ZTZA28quBaBjMFi4IxwbmWeGJpp JF0g== 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-language; bh=aaSZufDgxjbe8WzxehqBCrac4FotMFDLAxNV1Kny6zw=; b=Zm7acxZ1k/8BsgIvBUUeG6FBL3nHCMUpDjpA6iV5gLKvQ3sLzlh6U4ieGw4TkfXg8c osYcXp8KPd/SOLxxWBYehiS4los8gylGSqB9EhmJ1Rss+dOou5yyiiD2ZNEj5eWq9j3i dQEoROEO2gIVkXoUSgT2WvKadD7v8VdBbjNS3OYQg5ePxQ0d2HDDAm0juaTxReBd6XcT wj7PjIAkBXbtYxdPsdb5veJPV4YywX78P94Mk8EYZDYMftCrfaQjIaC73QDESJ8f6FQS +Z0oGOeiv6NLkx981HqcYohwejmJIBy8Fwc+95u2/RAYwLf0MBH0bu0T4rkleqtBi331 OuCQ== X-Gm-Message-State: APjAAAXf91epoNr1IIqxG09LlmlrqkjnMzDV0OBsKLigGPK4gckOIFZO xHqE5Weo5X+hdO8duzEflp+RUwEWp1M= X-Google-Smtp-Source: APXvYqyN+kI2Xz5e//hetq/IdnwzzG9TgscAxQgUIxTVl11kxF9hJ2G25HBsOC6RCq7wMLixgnpv0g== X-Received: by 2002:a0c:b90d:: with SMTP id u13mr30869108qvf.66.1552423385914; Tue, 12 Mar 2019 13:43:05 -0700 (PDT) Received: from ?IPv6:2601:152:4400:4013:44d2:dbe7:595a:139? ([2601:152:4400:4013:44d2:dbe7:595a:139]) by smtp.gmail.com with ESMTPSA id r11sm6067133qtj.70.2019.03.12.13.43.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Mar 2019 13:43:05 -0700 (PDT) To: Richard Barnes , John Mattsson Cc: "Blumenthal, Uri - 0553 - MITLL" , CFRG , "RFC ISE (Adrian Farrel)" , secdir References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> From: Michael StJohns Message-ID: <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> Date: Tue, 12 Mar 2019 16:43:04 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4190BFE5809BAB371F3A40BD" Content-Language: en-US Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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, 12 Mar 2019 20:43:09 -0000 This is a multi-part message in MIME format. --------------4190BFE5809BAB371F3A40BD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 3/12/2019 2:56 PM, Richard Barnes wrote: > Big +1 here.  It's not broke, so let's not fix it, especially for > purely process-wonk reasons. Except its not quite just for process-wonk reasons.  The last couple of discussions have been about the IPR related to OCB and whether the CFRG should work on it because of that.   That's a perfectly fine set of discussions for a standards WG especially when considering which modes to include under recommended and mandatory to implement, but is probably out of place for an RG.     The RG ought to be answering the question "does this proposal have security flaws" and not "has the patent expired on this" but we seem to be getting far past the "discussing and analyzing" part of the CFRG charter? > Our goal is to provide a forum for discussing and analyzing general > cryptographic aspects of security protocols, and to offer guidance on the use > of emerging mechanisms and new uses of existing mechanisms. I'd really like the CFRG to continue to be a place where anything cryptographic can be brought to be evaluated on its merits - but that - IMHO - doesn't seem to be the recent trend. I note that the CFRG has already published RFC7253 on OCB and the IETF published an RFC on MD5 many many years ago, so unless there are new security flaws in this set of documents, the answer to the ISE should be a no brainer of "we don't see any problems with the publication".    And at some point the patents *will* expire even if its not the 1-2 years that one poster suggested. In any event, I'm not going to push for this at this time, but I'm still confused about what would have to change if the charter were turned into a WG charter. Later, Mike > > On Mon, Mar 11, 2019 at 3:08 AM John Mattsson > > wrote: > > I think it is much more important that CFRG stays a Research > Group, than it is that CFRG can produce standards track documents. > CFRG is unique and fills a very important roll. The fact that CFRG > documents are used so much indicates to me that CFRG is working > very well. I would be very hesitant in changing something that works. > > Cheers, > > John > --------------4190BFE5809BAB371F3A40BD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 3/12/2019 2:56 PM, Richard Barnes wrote:
Big +1 here.  It's not broke, so let's not fix it, especially for purely process-wonk reasons.

Except its not quite just for process-wonk reasons.  The last couple of discussions have been about the IPR related to OCB and whether the CFRG should work on it because of that.   That's a perfectly fine set of discussions for a standards WG especially when considering which modes to include under recommended and mandatory to implement, but is probably out of place for an RG.     The RG ought to be answering the question "does this proposal have security flaws" and not "has the patent expired on this" but we seem to be getting far past the "discussing and analyzing" part of the CFRG charter?

Our goal is to provide a forum for discussing and analyzing general
cryptographic aspects of security protocols, and to offer guidance on the use
of emerging mechanisms and new uses of existing mechanisms.

I'd really like the CFRG to continue to be a place where anything cryptographic can be brought to be evaluated on its merits - but that - IMHO - doesn't seem to be the recent trend.

I note that the CFRG has already published RFC7253 on OCB and the IETF published an RFC on MD5 many many years ago, so unless there are new security flaws in this set of documents, the answer to the ISE should be a no brainer of "we don't see any problems with the publication".    And at some point the patents *will* expire even if its not the 1-2 years that one poster suggested.

In any event, I'm not going to push for this at this time, but I'm still confused about what would have to change if the charter were turned into a WG charter.

Later, Mike



On Mon, Mar 11, 2019 at 3:08 AM John Mattsson <john.mattsson@ericsson.com> wrote:

I think it is much more important that CFRG stays a Research Group, than it is that CFRG can produce standards track documents. CFRG is unique and fills a very important roll. The fact that CFRG documents are used so much indicates to me that CFRG is working very well. I would be very hesitant in changing something that works.

 

Cheers,

John



--------------4190BFE5809BAB371F3A40BD-- From nobody Tue Mar 12 18:37:14 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 92AB513116E for ; Tue, 12 Mar 2019 18:37:08 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 SO0WgFSoTMO9 for ; Tue, 12 Mar 2019 18:37:05 -0700 (PDT) Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) (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 2BD4D1311BC for ; Tue, 12 Mar 2019 18:37:05 -0700 (PDT) Received: by mail-oi1-x243.google.com with SMTP id g16so165403oib.1 for ; Tue, 12 Mar 2019 18:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5ss7/RWKH9xqfogH7igMbtpThl7B48BzsdKJmUATPGw=; b=m0qWTEUVu30LlYPYwzfDkyurmChwBKnV+O83Dm0BJEqTY3jqLCZCLtOFKw4D6rrsrk BUO5zheWU/1QdZYLRC6yIwcP+pR+SGEWHNcIRR1kmwi55S0tea5pDiBrOqHIJVRioDep 0ow5N2pAPZRiWbx+5+8um21yc3eVPp8NFmMD2BLByv5pIOyupvXnPVPxwxh+XVAHi162 +zVCWA3YXETT14ArDU/JaEMPENxawb5Um2QTQK1EXwCW6c4HMLMfTk013oX/rB+xwhaq AN1VVFTb4l+7C63pURNPcIR4X5lBec63tR6b9oplfBTIXVJOhkO3DeL8OrQwuXRfQgHm pQEA== 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=5ss7/RWKH9xqfogH7igMbtpThl7B48BzsdKJmUATPGw=; b=WvNtnbPNdfmQ3yTw7puSMrrYyd3LtYesjvnm+ZmG0+722rxAY/cxPhhiqVH+jb6k6n RFcD5iZEzmeXdXrO04L9l6+CqA8cfB34K338Vnrnj464RUc+I3TKc9QhKmZVCpvQ9Ie5 UK4czK8HlAtfQIYTGcmZbCuGKq+odlGjgLRWIUCnJAcqdTg9XDU9+euIOVqFTPIC+5WR 3iCmDBu+B7a2/e3eeQiHqmhM+ZvuxsDfKlhMV9czhBTqQ53Udou6EdnbB1+Zlv3gEe2X DnBZx+nRH1vlOmCxhdgv+rM2iDYNaD4wnqqyfTrPMKXWoHr84Ur1pdGxAUIOEmP9Q3m5 KmFQ== X-Gm-Message-State: APjAAAWEPaniKtSHVVroUrEkzlbwGv7stHVoDGmXrUBCymmtGWmYW6M5 ymSRrN+mhwbTseBMyyxZj1Yeku5uQ6jqezVG110= X-Google-Smtp-Source: APXvYqw3cOv+LSnQKPlMRtUVv/FPRD8uzapCrDk2iykcHFUwrN8xT9C7rMIRYbXA9bF1uTkLndiY3U7W8z5q0zD1PN8= X-Received: by 2002:aca:3081:: with SMTP id w123mr192367oiw.141.1552441024507; Tue, 12 Mar 2019 18:37:04 -0700 (PDT) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> In-Reply-To: <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> From: denis bider Date: Tue, 12 Mar 2019 20:36:52 -0500 Message-ID: To: Michael StJohns Cc: Richard Barnes , John Mattsson , CFRG , "RFC ISE (Adrian Farrel)" , secdir Content-Type: multipart/alternative; boundary="000000000000ccf3430583efd72b" Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 01:37:12 -0000 --000000000000ccf3430583efd72b Content-Type: text/plain; charset="UTF-8" For what it's worth, I think the counterpoint to "don't fix it if it isn't broken" is "it's going to have to break before it's fixed". It is not generally advisable to wait with fixing bridges until they're actually broken, for example. I think Michael is raising a legitimate issue and intuitively, it sounds like the proper answer might be a dual charter as WG + RG. Perhaps this is unusual, but it is an unusual group. I think it would be appropriate for this group. denis On Tue, Mar 12, 2019 at 3:43 PM Michael StJohns wrote: > On 3/12/2019 2:56 PM, Richard Barnes wrote: > > Big +1 here. It's not broke, so let's not fix it, especially for purely > process-wonk reasons. > > Except its not quite just for process-wonk reasons. The last couple of > discussions have been about the IPR related to OCB and whether the CFRG > should work on it because of that. That's a perfectly fine set of > discussions for a standards WG especially when considering which modes to > include under recommended and mandatory to implement, but is probably out > of place for an RG. The RG ought to be answering the question "does > this proposal have security flaws" and not "has the patent expired on this" > but we seem to be getting far past the "discussing and analyzing" part of > the CFRG charter? > > Our goal is to provide a forum for discussing and analyzing general > cryptographic aspects of security protocols, and to offer guidance on the use > of emerging mechanisms and new uses of existing mechanisms. > > > I'd really like the CFRG to continue to be a place where anything > cryptographic can be brought to be evaluated on its merits - but that - > IMHO - doesn't seem to be the recent trend. > > I note that the CFRG has already published RFC7253 on OCB and the IETF > published an RFC on MD5 many many years ago, so unless there are new > security flaws in this set of documents, the answer to the ISE should be a > no brainer of "we don't see any problems with the publication". And at > some point the patents *will* expire even if its not the 1-2 years that one > poster suggested. > > In any event, I'm not going to push for this at this time, but I'm still > confused about what would have to change if the charter were turned into a > WG charter. > > Later, Mike > > > > On Mon, Mar 11, 2019 at 3:08 AM John Mattsson > wrote: > >> I think it is much more important that CFRG stays a Research Group, than >> it is that CFRG can produce standards track documents. CFRG is unique and >> fills a very important roll. The fact that CFRG documents are used so much >> indicates to me that CFRG is working very well. I would be very hesitant in >> changing something that works. >> >> >> >> Cheers, >> >> John >> > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --000000000000ccf3430583efd72b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For what it's worth, I think the counterpoint to = "don't fix it if it isn't broken" is "it's going= to have to break before it's fixed".

It = is not generally advisable to wait with fixing bridges until they're ac= tually broken, for example.

I think Michael is rai= sing a legitimate issue and intuitively, it sounds like the proper answer m= ight be a dual charter as WG=C2=A0+ RG. Perhaps this is unusual, but it is = an unusual group. I think it would be appropriate for this group.

denis


On Tue, Mar 12, 2019 at 3:43 PM M= ichael StJohns <msj@nthpermuta= tion.com> wrote:
=20 =20 =20
On 3/12/2019 = 2:56 PM, Richard Barnes wrote:
=20
Big +1 here.=C2=A0 It's not broke, so let's = not fix it, especially for purely process-wonk reasons.

Except its not quite just for process-wonk reasons.=C2=A0 The last couple of discussions have been about the IPR related to OCB and whether the CFRG should work on it because of that.=C2=A0=C2=A0 That&= #39;s a perfectly fine set of discussions for a standards WG especially when considering which modes to include under recommended and mandatory to implement, but is probably out of place for an RG.=C2=A0=C2=A0=C2=A0=C2=A0 The RG ought to be answering the question= "does this proposal have security flaws" and not "has the patent expir= ed on this" but we seem to be getting far past the "discussing an= d analyzing" part of the CFRG charter?

Our goal is to provide a forum for discussing and analyzing ge=
neral
cryptographic aspects of security protocols, and to offer guidance on the u=
se
of emerging mechanisms and new uses of existing mechanisms.

I'd really like the CFRG to continue to be a place where anythin= g cryptographic can be brought to be evaluated on its merits - but that - IMHO - doesn't seem to be the recent trend.

I note that the CFRG has already published RFC7253 on OCB and the IETF published an RFC on MD5 many many years ago, so unless there are new security flaws in this set of documents, the answer to the ISE should be a no brainer of "we don't see any problems wit= h the publication".=C2=A0=C2=A0=C2=A0 And at some point the patents *w= ill* expire even if its not the 1-2 years that one poster suggested.

In any event, I'm not going to push for this at this time, but I'm still confused about what would have to change if the charter were turned into a WG charter.

Later, Mike



On Mon, Mar 11, 2019 at 3:08 AM John Mattsson <john.mattsson@ericsson.com> wrote:

I think it is muc= h more important that CFRG stays a Research Group, than it is that CFRG can produce standards track documents. CFRG is unique and fills a very important roll. The fact that CFRG documents are used so much indicates to me that CFRG is working very well. I would be very hesitant in changing something that works.

=C2=A0

Cheers,

John



_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
--000000000000ccf3430583efd72b-- From nobody Tue Mar 12 18:45:26 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 7A2B3127887; Tue, 12 Mar 2019 18:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=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 iAMJnG-Lxnli; Tue, 12 Mar 2019 18:45:12 -0700 (PDT) Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8E07312705F; Tue, 12 Mar 2019 18:45:12 -0700 (PDT) Received: from LLE2K16-MBX03.mitll.ad.local (LLE2K16-MBX03.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTP id x2D1jA6P037349; Tue, 12 Mar 2019 21:45:10 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: denis bider , Michael StJohns CC: secdir , CFRG , "RFC ISE (Adrian Farrel)" Thread-Topic: [Cfrg] Time to recharter CFRG as a working group? Was: Re: [secdir] ISE seeks help with some crypto drafts Thread-Index: AQHU15MRh5fmrRoU9kWbbFEvG0YyAKYFyJ4AgAB9cQCAAlh9AIAAHb0AgABSFgD//79BAA== Date: Wed, 13 Mar 2019 01:45:09 +0000 Message-ID: References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.0.190211 x-originating-ip: [172.25.1.84] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3635271908_534907953" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-13_01:, , 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903130010 Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 01:45:16 -0000 --B_3635271908_534907953 Content-type: multipart/alternative; boundary="B_3635271908_640367973" --B_3635271908_640367973 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Again, I respectfully disagree.=20 =20 I see the charters of IETF WG and of IRTF RG different enough, with differe= nt goals, different milestones and measurements of success, so that molding = one into the other IMHO would be counterproductive and won=E2=80=99t make sense (I= =E2=80=99ve been with IETF since 1992, and co-chaired an RG group for a couple of = years =E2=80=93 so I think I have at least some practical appreciation for the dif= ferences). =20 Feel free to create another group =E2=80=93 say, Crypto WG in IETF, draft a chart= er for it, and see where people would prefer to participate. Let one of the = two wither, and the other one prosper. =F0=9F=98=89 -- Regards, Uri=20 =20 From: Cfrg on behalf of denis bider Date: Tuesday, March 12, 201911 at 21:38 To: Michael StJohns Cc: secdir , CFRG , "RFC ISE (Adrian Farrel= )" Subject: Re: [Cfrg] Time to recharter CFRG as a working group? Was: Re: [se= cdir] ISE seeks help with some crypto drafts =20 For what it's worth, I think the counterpoint to "don't fix it if it isn't = broken" is "it's going to have to break before it's fixed". =20 It is not generally advisable to wait with fixing bridges until they're act= ually broken, for example. =20 I think Michael is raising a legitimate issue and intuitively, it sounds li= ke the proper answer might be a dual charter as WG + RG. Perhaps this is unu= sual, but it is an unusual group. I think it would be appropriate for this g= roup. =20 denis =20 =20 On Tue, Mar 12, 2019 at 3:43 PM Michael StJohns wr= ote: On 3/12/2019 2:56 PM, Richard Barnes wrote: Big +1 here. It's not broke, so let's not fix it, especially for purely pr= ocess-wonk reasons. Except its not quite just for process-wonk reasons. The last couple of dis= cussions have been about the IPR related to OCB and whether the CFRG should = work on it because of that. That's a perfectly fine set of discussions for= a standards WG especially when considering which modes to include under rec= ommended and mandatory to implement, but is probably out of place for an RG.= The RG ought to be answering the question "does this proposal have secu= rity flaws" and not "has the patent expired on this" but we seem to be getti= ng far past the "discussing and analyzing" part of the CFRG charter? Our goal is to provide a forum for discussing and analyzing general cryptographic aspects of security protocols, and to offer guidance on the u= se of emerging mechanisms and new uses of existing mechanisms. =20 I'd really like the CFRG to continue to be a place where anything cryptogra= phic can be brought to be evaluated on its merits - but that - IMHO - doesn'= t seem to be the recent trend. I note that the CFRG has already published RFC7253 on OCB and the IETF publ= ished an RFC on MD5 many many years ago, so unless there are new security fl= aws in this set of documents, the answer to the ISE should be a no brainer o= f "we don't see any problems with the publication". And at some point the= patents *will* expire even if its not the 1-2 years that one poster suggest= ed. In any event, I'm not going to push for this at this time, but I'm still co= nfused about what would have to change if the charter were turned into a WG = charter. Later, Mike =20 =20 On Mon, Mar 11, 2019 at 3:08 AM John Mattsson = wrote: I think it is much more important that CFRG stays a Research Group, than it= is that CFRG can produce standards track documents. CFRG is unique and fill= s a very important roll. The fact that CFRG documents are used so much indic= ates to me that CFRG is working very well. I would be very hesitant in chang= ing something that works. =20 Cheers, John =20 =20 _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg --B_3635271908_640367973 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Again, I respectful= ly disagree.

 

I see the charters of IETF WG and of IRTF RG different enough, wi= th different goals, different milestones and measurements of success, so tha= t molding one into the other IMHO would be counterproductive and won=E2= =80=99t make sense (I=E2=80=99ve been with IETF since 1992, and co-chaired an RG group= for a couple of years =E2=80=93 so I think I have at least some practical = appreciation for the differences).

<= span style=3D'font-size:12.0pt'> 

Feel free to create another group =E2=80=93= say, Crypto WG in IETF, draft a charter for it, and see where people would = prefer to participate. Let one of the two wither, and the other one prosper.= €= 521;

--

Regards,

Uri

 

= From: Cfrg <cfrg-bounces@irtf.org> on behalf o= f denis bider <denisbider.ietf@gmail.com>
Date: Tuesday, Mar= ch 12, 201911 at 21:38
To: Michael StJohns <msj@nthpermutation.= com>
Cc: secdir <secdir@ietf.org>, CFRG <cfrg@irtf.org= >, "RFC ISE (Adrian Farrel)" <rfc-ise@rfc-editor.org>
= Subject: Re: [Cfrg] Time to recharter CFRG as a working group? Was: R= e: [secdir] ISE seeks help with some crypto drafts

 

For what it's worth,= I think the counterpoint to "don't fix it if it isn't broken" is = "it's going to have to break before it's fixed".

 

It is not generally advi= sable to wait with fixing bridges until they're actually broken, for example= .

=  

I thi= nk Michael is raising a legitimate issue and intuitively, it sounds like the= proper answer might be a dual charter as WG + RG. Perhaps this is unus= ual, but it is an unusual group. I think it would be appropriate for this gr= oup.

 

de= nis

 

 

On = Tue, Mar 12, 2019 at 3:43 PM Michael StJohns <msj@nthpermutation.com> wrote:

On 3/12/2019 2:56 PM, Richard Barnes wrote:=

Big +1 here.  It's not broke, s= o let's not fix it, especially for purely process-wonk reasons.

Except its not quite just f= or process-wonk reasons.  The last couple of discussions have been abou= t the IPR related to OCB and whether the CFRG should work on it because of t= hat.   That's a perfectly fine set of discussions for a standards = WG especially when considering which modes to include under recommended and = mandatory to implement, but is probably out of place for an RG.  &= nbsp;  The RG ought to be answering the question "does this propos= al have security flaws" and not "has the patent expired on this&qu= ot; but we seem to be getting far past the "discussing and analyzing&qu= ot; part of the CFRG charter?

Our goal is to provid=
e a forum for discussing and analyzing general
cryptographic aspects of security protocols, and to offer g=
uidance on the use
of emerging=
 mechanisms and new uses of existing mechanisms.

 

I'd really like the CFRG to continue to be a place where = anything cryptographic can be brought to be evaluated on its merits - but th= at - IMHO - doesn't seem to be the recent trend.

I note that the CFRG has already published RFC7253 on OCB and= the IETF published an RFC on MD5 many many years ago, so unless there are n= ew security flaws in this set of documents, the answer to the ISE should be = a no brainer of "we don't see any problems with the publication".&= nbsp;   And at some point the patents *will* expire even if its no= t the 1-2 years that one poster suggested.

In any event, I'm not going to push for this at this time, but I'm = still confused about what would have to change if the charter were turned in= to a WG charter.

Later, Mike<= /o:p>

 

 

On Mon, Mar 11, 2019 at 3:08 AM John Mattsson <john.mattsson@ericsson.com> w= rote:

<= div>

I think it is much more importa= nt that CFRG stays a Research Group, than it is that CFRG can produce standa= rds track documents. CFRG is unique and fills a very important roll. The fac= t that CFRG documents are used so much indicates to me that CFRG is working = very well. I would be very hesitant in changing something that works.=

&nbs= p;

Cheers,

John

 <= /p>

 

_______________________________________________Cfrg mailing list
Cfrg@ir= tf.org
https://www.irtf.org/mailman/listinfo/cfrg

--B_3635271908_640367973-- --B_3635271908_534907953 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQADhvrZHqbUs3XjIgAAAAOG+jANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTE5MDEwODE0MjgyMloXDTIyMDEw NzE0MjgyMlowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDRtVpCB2qzc1ia4sI2Dq+YEUHS29Ca pM5d0jBAdvQgFnXmTe4Ur0onMJkqYpatbmJAKl9lHMYDMvwemI3DG+0ebyXkVan3lPbawoba Zy7yQzAPvbQ/KSqemihH1SrGp3jF522kmW8o64wzHGaZRgo4LK8xO2TiwdebuBLA+MUh6NqS 3hBVPZ3xb9nVynJ5EIq8XWb/LYpfvgovs5kUL1m1Cl62NQ8+lW6qEUMfgmgY/Sx5DR9Uo9mC DS4IurVXijIK5E4NhYDmkI6KhxgnB0A2iyD/afGlqiIXs2dfOK28smGfFry9HEO5O8n1JI+5 QdzkBce3h/P3i5VE1zCOaF9RAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUhatfAqb0g782Agbd cbDwogD9b+MwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCDAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBACRKYQxz VfdiOo93iNBw7krEv7svK30nqiiMQhPDEuSTUcLUyvEeBT29w+vKil/y6TQ/0LDoKAB0zH+k YPKanaWec44CLyccDyEqUqdIy+GC24JTnGldjc+9sUgKrNWB7dP6pU7jc8o1KC3XJr1al8gf F3qIGk3A0r2zZK8/dOfAGKbDLJAxw5uMwYjqQA61Qt8H428AKVEluGGgNxwGRwt3E8mPmDD2 cr4bl3b2rZTZNRTha8kvsvgh/u1SWfFWutPi26pIsXiJ10ysySW6qeZ2WNPnyIwKFdrvt4W0 AJc2CtcJCZrkfHjkHWARI/JDPln9ZdzxDGYOrpOXDbO40SgwggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAA7OX5fo0OiIK0RAAAAADs5MA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMTgwODI4MjE0NTI5WhcNMjEwODI3 MjE0NTI5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI5Vc19RKc/69lmwhogDOjjzPQbmc8s6 Z6rzP6oUHAswDICqZWwPt+FTbKr0YTAqRNsTEN4YiW0fORK+fNRvClo0pdiCqj3DwDQZLRI4 Dak1yTsUtVe35oomQbXtO+0A0L/CowYri/UKeRG1i1/0cXSf4mAx0ed9wh2SordAb8o2FuOU 0B2ppnqjro1VFugHHX6QOggaeLFOprT5gnTZUmqM37/d4DGB9XDdTQi144zQSwSWKkaUThsy D9CHSRNcB79HBvlZGSM+BkIbayPdhQAuz4yKsOZEWPx/6LnMotzBevSswnCDf+u9ajCgMnje WbrZRN+xoYEuhycXyK2b8/MCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBTZUpq7Rsccv42yU9UQ 4wvojOl4pzAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgEJMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEACyN6 Yhi9LApOPpf60ypSV2WmV3sqnrsrdlPTW+am4wMK/M/5PZmt5jFVtXaErkWYdrbMdjeo2o/G 9N2DnrFOhz7kDYM9HC9AH/rWCfoSkI/C2N6Rq/uDnRJfao61wyv37qKtanNdkp+reyLxdVPn foVrD/VZli4UV28u4XBuYDkjXPyyiH+bb395FnxOtTA3Uz41Ohpdvr6oLPEuy0IP4MPfK5wD mS6GXcB+ze9sYEp+DJxE7WAbkW5Y536WPl/rfWm/k6ZC1KPVSRM7mS+atk44VOgzPLXkl6Tu 6zY8tMczfr5F0om1JfN8G50s4QDUGtsMgzW+LXVDhFD24xnUojGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQADhvrZHqbUs3XjIgAAAAOG+jANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCAJThBn+TSGQqXTnjAe4IwGcTHstROu3XBbY6vO CW4agjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTAzMTMw MTQ1MDhaMA0GCSqGSIb3DQEBAQUABIIBAKL7dMvF5XEBdrOvqbyZLkuJmf6ZhUwMrm98UnVP 9csKtL8R1LfbjMsI/WQUZ1zayNPENYeZLSPWprQshujyJkex6ghP1MykjGnKA2XKMc3WZeKz 1OeYAxIOX249VHRMHt4Q/CPsprSrw34D9LRQFXHS2vgQUadEGYcGt3FurenO8wER+I/pqh+e TEYmPwq6tLj4zScIIkRuhuU7Nfiy7uf/vNsU/zohyen60/mr+rCDMRLsbLHqNKKLnhCq6vrJ HbFeSY1R9GDMdK0qsx0tZdjoE/4FjV9lIy+CIZdTqXOHc8GuLifQ64c05BiQkz0gc4HL93/O URWC3G8IO7Se7P0= --B_3635271908_534907953-- From nobody Wed Mar 13 04:32:50 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 49769130EDE for ; Wed, 13 Mar 2019 04:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 q96lYhqkS8_G for ; Wed, 13 Mar 2019 04:32:45 -0700 (PDT) Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) (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 E6F01130EC8 for ; Wed, 13 Mar 2019 04:32:44 -0700 (PDT) Received: by mail-ot1-x343.google.com with SMTP id d22so389977otk.10 for ; Wed, 13 Mar 2019 04:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C6e7yDjH+34MahjlT8s8xfnAwpFZKHASfA5VK0a62E0=; b=Ye0qjjvMhOha6qhMPU/gsIlyNdGmgbiVvHXVF0hpCfHkO7GFl4EyqJpGs7YHTp94aq UUCaTW0sH2DOWpUTQJPdPtHhUI3V20Nng3hAJDV1nzHQ71SX2/CYoqaEYE7l+rSs27/v wae27c5pf/BjyTwrtu4QAAV6Tuh8xUA/mqQP2oC1yIUgCLT1Dz5uinALai262YxObIif mUi5Y1CCdNrAbvhkEDYf6eBXA7akf0vGOiyKN/LoTPOYMTCI0+j+i9EgC+UIh9i3ku9p mF4WCJ/mXY3ju9f1kTlsIcc724LyOPUj2bLd8B68xmoSPvoT3vig6vHNK3mf6vT/1yfm piGw== 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=C6e7yDjH+34MahjlT8s8xfnAwpFZKHASfA5VK0a62E0=; b=E0NTaa4XAf7dTrjumUow9FI9AevHECqsqDdrI0sAYsiI6TXgaKyW3jtfEELewT7if5 TImsBVmXXizPlOVkK+HQQe7gXp/Cmyoogxvexpuaj8aTbNgphgGpFbLr7T/mqqwr9hcy Vp3BnnePxj1a+jUwTDk3CFZJhf3I0AfUaQ/bPnm6EOdqEGFGsI/hBMbdd73fCYpzW+xT mWicgs5rt9hQ2u+/iqd7UjmESMgMdldDqtuvjFvCSZR9e69PXpblnaBRDTivBgPmdqC3 1QKoi4Hvmtrq1iA8G6fBtSAQgQOEnLF1IE2JtPmY8W/th/DZLlezWS5wfeyVHnLQVXPm C8vw== X-Gm-Message-State: APjAAAXdcwMMwTsNuXEv1vFDfm2Os0caOOpSbwVGe7WKF6r7ZmjXdBJC O1ZkStxEyIDTfoAR5yegu8T4M3qxwXuGBrxrtBvu1A== X-Google-Smtp-Source: APXvYqxbnTXw5lW52uLPB2nsvF3vsEPAJfw3pcGOK5FO7XSLXrMzFCQToZMyphpcNZgczXzRRg9mUdWoyXPu3E4PvFA= X-Received: by 2002:a05:6830:15c7:: with SMTP id j7mr26002723otr.331.1552476764064; Wed, 13 Mar 2019 04:32:44 -0700 (PDT) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> In-Reply-To: <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> From: Richard Barnes Date: Wed, 13 Mar 2019 07:32:15 -0400 Message-ID: To: Michael StJohns Cc: John Mattsson , "Blumenthal, Uri - 0553 - MITLL" , CFRG , "RFC ISE (Adrian Farrel)" , secdir Content-Type: multipart/alternative; boundary="0000000000000b5f8d0583f82a2d" Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 11:32:49 -0000 --0000000000000b5f8d0583f82a2d Content-Type: text/plain; charset="UTF-8" Mike, are your concerns here primarily IPR related? If that's so, then maybe that's the level at which we should address them, as opposed to flipping the bigger RG->WG switch. On Tue, Mar 12, 2019 at 4:43 PM Michael StJohns wrote: > On 3/12/2019 2:56 PM, Richard Barnes wrote: > > Big +1 here. It's not broke, so let's not fix it, especially for purely > process-wonk reasons. > > Except its not quite just for process-wonk reasons. The last couple of > discussions have been about the IPR related to OCB and whether the CFRG > should work on it because of that. That's a perfectly fine set of > discussions for a standards WG especially when considering which modes to > include under recommended and mandatory to implement, but is probably out > of place for an RG. The RG ought to be answering the question "does > this proposal have security flaws" and not "has the patent expired on this" > but we seem to be getting far past the "discussing and analyzing" part of > the CFRG charter? > > Our goal is to provide a forum for discussing and analyzing general > cryptographic aspects of security protocols, and to offer guidance on the use > of emerging mechanisms and new uses of existing mechanisms. > > > I'd really like the CFRG to continue to be a place where anything > cryptographic can be brought to be evaluated on its merits - but that - > IMHO - doesn't seem to be the recent trend. > > I note that the CFRG has already published RFC7253 on OCB and the IETF > published an RFC on MD5 many many years ago, so unless there are new > security flaws in this set of documents, the answer to the ISE should be a > no brainer of "we don't see any problems with the publication". And at > some point the patents *will* expire even if its not the 1-2 years that one > poster suggested. > > In any event, I'm not going to push for this at this time, but I'm still > confused about what would have to change if the charter were turned into a > WG charter. > > Later, Mike > > > > On Mon, Mar 11, 2019 at 3:08 AM John Mattsson > wrote: > >> I think it is much more important that CFRG stays a Research Group, than >> it is that CFRG can produce standards track documents. CFRG is unique and >> fills a very important roll. The fact that CFRG documents are used so much >> indicates to me that CFRG is working very well. I would be very hesitant in >> changing something that works. >> >> >> >> Cheers, >> >> John >> > > > --0000000000000b5f8d0583f82a2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mike, are your concerns here primarily IPR related?= =C2=A0 If that's so, then maybe that's the level at which we should= address them, as opposed to flipping the bigger RG->WG switch.


On Tue, Mar 12, 2019 at 4:43 PM Michael StJohns <msj@nthpermutation.com> wrote:
=20 =20 =20
On 3/12/2019 = 2:56 PM, Richard Barnes wrote:
=20
Big +1 here.=C2=A0 It's not broke, so let's = not fix it, especially for purely process-wonk reasons.

Except its not quite just for process-wonk reasons.=C2=A0 The last couple of discussions have been about the IPR related to OCB and whether the CFRG should work on it because of that.=C2=A0=C2=A0 That&= #39;s a perfectly fine set of discussions for a standards WG especially when considering which modes to include under recommended and mandatory to implement, but is probably out of place for an RG.=C2=A0=C2=A0=C2=A0=C2=A0 The RG ought to be answering the question= "does this proposal have security flaws" and not "has the patent expir= ed on this" but we seem to be getting far past the "discussing an= d analyzing" part of the CFRG charter?

Our goal is to provide a forum for discussing and analyzing ge=
neral
cryptographic aspects of security protocols, and to offer guidance on the u=
se
of emerging mechanisms and new uses of existing mechanisms.

I'd really like the CFRG to continue to be a place where anythin= g cryptographic can be brought to be evaluated on its merits - but that - IMHO - doesn't seem to be the recent trend.

I note that the CFRG has already published RFC7253 on OCB and the IETF published an RFC on MD5 many many years ago, so unless there are new security flaws in this set of documents, the answer to the ISE should be a no brainer of "we don't see any problems wit= h the publication".=C2=A0=C2=A0=C2=A0 And at some point the patents *w= ill* expire even if its not the 1-2 years that one poster suggested.

In any event, I'm not going to push for this at this time, but I'm still confused about what would have to change if the charter were turned into a WG charter.

Later, Mike



On Mon, Mar 11, 2019 at 3:08 AM John Mattsson <john.mattsson@ericsson.com> wrote:

I think it is muc= h more important that CFRG stays a Research Group, than it is that CFRG can produce standards track documents. CFRG is unique and fills a very important roll. The fact that CFRG documents are used so much indicates to me that CFRG is working very well. I would be very hesitant in changing something that works.

=C2=A0

Cheers,

John



--0000000000000b5f8d0583f82a2d-- From nobody Wed Mar 13 22:45:58 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 243AB1279A5 for ; Wed, 13 Mar 2019 22:45:56 -0700 (PDT) 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, 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 (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 3n7MfSz_LVNp for ; Wed, 13 Mar 2019 22:45:54 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 B243C127988 for ; Wed, 13 Mar 2019 22:45:53 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id d18so3280544lfn.3 for ; Wed, 13 Mar 2019 22:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=QuCAiLVVe0tm21MuUtNqmiOFjQZASWy1bZH4SpMXTkU=; b=rg7NyqqF2QZsvhs016uQ/zD93rha1bPqaxLQlu9NW0R08PiXHSkoWVBWIRrY10IL6/ 4RdMtaMC1sSZXtPzUyX4FPgR81g8yyCi+jhOONz0m15WyuXiU1Bh4uDZ8BmZeFUk2Opw iPwo9LUnmPXYAfOmlHnf2KPPySFs0hAZdeuvwpvjnzLZ8hVA+mLPzo1MHd/tRNGjQ1m8 zhYNBvF+Z+lHGSskJYsav2XYeBNdGQLYTYBQhHVx0hagOgRNTfpxFmEIEwusyACEKKbO qIRc9jzATtY82pcAjRCX6AkG9Ft5W8zzjgwyMWJMLuA7HTYos4rNHk6Eia1GrMiE48PT ML+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=QuCAiLVVe0tm21MuUtNqmiOFjQZASWy1bZH4SpMXTkU=; b=faSzxDq4ZMWa732iFo84ZZ0Hn8Cb0Rj6wg3XZDXqER3vU2TWJ0VLdNjjelJFK4PjPf Ooftbj+qPZeU5cAp7iGRSRgDR5TCDSgFTN7s7CHBZPH4OXRoNFMfAsKZj2aUkpnhlohW qG/AMs6ICfjsVRsIHFJfTooyf6GIjzH2na5TTN0uDvnoD+IJayA3vhmOzy8EYChJGpDe TeynImOIR1mH6Iptkf1o+canWi1eVCqi4V2UMebfXINbUsCwdgl7DmF+4aj1+mLWRihc GqR/XWbsS+E0sHAQ8hlzLA2czcpCGDuBK+nJhMc2xhMBBpvXVyjzYCuvtl9bX5Sloz4n cO/Q== X-Gm-Message-State: APjAAAUtDH6iBvAgA9WhOp5zD9JdXTtZf2OenC02BVgSRRkW+PQ9T4EW XsgLP30TgCbaVqEPg+Kvqt1gjZzznHb7iFb9BBmoso6YYeI= X-Google-Smtp-Source: APXvYqx5Gyzxcsxvm1opYb6Y5wl/FB5fpupMOw6wx2HQRAlaAVKaaIPRbruOkwOAcy9inonKxlCjBpuR/IZ/LE69jB4= X-Received: by 2002:a19:238f:: with SMTP id j137mr13914423lfj.79.1552542351396; Wed, 13 Mar 2019 22:45:51 -0700 (PDT) MIME-Version: 1.0 From: Shawn Emery Date: Wed, 13 Mar 2019 23:45:40 -0600 Message-ID: To: secdir@ietf.org, draft-ietf-ccamp-alarm-module.all@tools.ietf.org Content-Type: multipart/alternative; boundary="0000000000005a93940584076fff" Archived-At: Subject: [secdir] Review of draft-ietf-ccamp-alarm-module-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, 14 Mar 2019 05:45:56 -0000 --0000000000005a93940584076fff 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 module for the purpose of network device alarm management. The security considerations section does exist and follows the yang-security-guidelines. I believe the data nodes and operations of concern are covered in this section, but it seems that alarm-profiles could also be sensitive if an attacker were to downgrade the severity of an alarm by changing the alarm-severity-assignment-profile. General comments: None. Editorial comments: s/northbound/north-bound/ s/definition also focus/definition also focuses/ s/an hierarchy/a hierarchy/ s/raised again etc/raised again, etc/ s/sent Notifications/sent. Notifications/ s/alarn/alarm/ s/The NETCONF access control model/The Network Configuration Access Control Model (NACM)/ s/notify-status-change:/notify-status-changes:/ OLD: This leaf controls whether an alarm should notify only raise and clear or all severity level changes. Unauthorized access to leaf could have a negative impact on operational procedures relying on fine-grained alarm state change reporting. NEW: This leaf controls whether an alarm should notify based on various state changes. Unauthorized access to this leaf could have a negative impact on operational procedures relying on fine-grained alarm state change reporting. Shawn. -- --0000000000005a93940584076fff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reviewer: Shawn M. E= mery
= Review result:=C2=A0Ready with nits

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

This draft specifies a YANG module for the purpose of network device ala= rm management.

The security considerations section does exist and follo= ws the yang-security-guidelines.
I bel= ieve=C2=A0the data nodes and operations of= concern are covered in this section, but it seems
that alarm-profiles = could also be sensitive if an attacker were to downgrade the=C2=A0severity of
an alarm=C2=A0by changing the alarm-severity-assignment-profile.<= /span>

General comments:

None.

Editorial comments:
<= div style=3D"font-size:12.8px">
s/= northbound/north-bound/
s/defini= tion also focus/definition also focuses/
s/an hierarchy/a hierarchy/
s/raised again etc/raised again, etc/
<= span style=3D"font-size:12.8px">s/sent Notifications/sent.=C2=A0 Notificati= ons/
s/alarn/alarm/
s/The NETCONF access control model/The Network Configuration Acce= ss Control Model (NACM)/
= s/notify-status-change:/notify-status-changes:/

OLD:
This leaf control= s whether an=C2=A0alarm should noti= fy only raise and clear or all severity level
changes.=C2=A0 Unauthorized access to leaf could have= a negative impact=C2=A0on operatio= nal procedures
relying on= fine-grained alarm state=C2=A0chan= ge reporting.

=
NEW:
= This leaf controls whether an=C2=A0= alarm should notify based on various=C2=A0= state changes.=C2=A0 Unauthorized
access to this leaf could = have a negative impact=C2=A0on oper= ational procedures relying on
fine-grained alarm state=C2=A0= change reporting.
<= br>
Shawn.
--
=
--0000000000005a93940584076fff-- From nobody Thu Mar 14 08:33:50 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 E477C130E89; Thu, 14 Mar 2019 08:33:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stephen Farrell via Datatracker To: Cc: draft-ietf-dots-signal-channel.all@ietf.org, ietf@ietf.org, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Stephen Farrell Message-ID: <155257761487.2625.10003476313108979036@ietfa.amsl.com> Date: Thu, 14 Mar 2019 08:33:34 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dots-signal-channel-30 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 Mar 2019 15:33:35 -0000 Reviewer: Stephen Farrell Review result: Has Issues I think there's one issue with this draft that'd be well worth discussion and/or fixing: - p12: Why does the cuid need to be so static? I would have thought that an identifier that can change more often than a key pair would have been better, esp if this could be used in a CPE. (Creating a new long-lived identifier for a CPE seems like a bad plan if it's not really needed.) For example, one could use both the SPKI and a timestamp as input for a recommended way to generate a cuid and that should be as unique, but much more easily changed. That could also mitigate the possible TLS1.2 client-cert snooping issue mentioned on p90. nits: - (Not really a nit, but probably too much to ask, so...) The protocol here seems very complex. Has anyone tried to prove anything about the state machine, e.g. that's it's safe in some senses? It'd be fair to say that that is a good task to do after the initial RFC is published in this case, I guess. OTOH, could be some of the theorem-proving tools used in the development of TLS1.3 could be useful here. (And those tools usually do turn up some issues worth fixing - I'd bet a beer they would in this case:-) - p18: "Only single-valued 'cdid' are defined in this document." That confused me given the text 3 paras before about multiple cdid values. Maybe clarifying that some could be useful? - p77 has a few lowercase "should" and "must" statements. Not sure if that's on purpose or by accident. - p90: Is the mention of TCP-AO there for real? I'd be happy it it were but if it's merely aspirational and you don't think it'll be used, it'd be better to not pretend it might get used. - Couldn't a bad actor in control of an authorised DOTS client colluding with the controller of a DDoS attack use this to probe the system to see how their attack is going and change the attack to be more effective? I don't think any protocol change could help there, but perhaps you could give some guidance to implementers to try catch such cases (e.g., if the probing DOTS client's local n/w doesn't actually appear to be under attack). From nobody Thu Mar 14 09:17: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 2024B130ECD; Thu, 14 Mar 2019 09:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 7OV39uFmU85D; Thu, 14 Mar 2019 09:17:16 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD908130E58; Thu, 14 Mar 2019 09:17:12 -0700 (PDT) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 44Kv466g6Vz2xlr; Thu, 14 Mar 2019 17:17:10 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.95]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 44Kv465PZFz3wbJ; Thu, 14 Mar 2019 17:17:10 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM24.corporate.adroot.infra.ftgroup ([fe80::b43f:9973:861e:42af%21]) with mapi id 14.03.0439.000; Thu, 14 Mar 2019 17:17:10 +0100 From: To: Stephen Farrell , "secdir@ietf.org" CC: "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-dots-signal-channel-30 Thread-Index: AQHU2ntKiSfaP6506UeavLvIGqIf7KYLQyKg Date: Thu, 14 Mar 2019 16:17:10 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA3DFC8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <155257761487.2625.10003476313108979036@ietfa.amsl.com> In-Reply-To: <155257761487.2625.10003476313108979036@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dots-signal-channel-30 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, 14 Mar 2019 16:17:18 -0000 SGkgU3RlcGhlbiwgDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy4gDQoNClBsZWFzZSBzZWUg aW5saW5lLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t DQo+IERlwqA6IFN0ZXBoZW4gRmFycmVsbCB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5 QGlldGYub3JnXQ0KPiBFbnZvecOpwqA6IGpldWRpIDE0IG1hcnMgMjAxOSAxNjozNA0KPiDDgMKg OiBzZWNkaXJAaWV0Zi5vcmcNCj4gQ2PCoDogZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVs LmFsbEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsNCj4gZG90c0BpZXRmLm9yZw0KPiBPYmpldMKg OiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5u ZWwtMzANCj4gDQo+IFJldmlld2VyOiBTdGVwaGVuIEZhcnJlbGwNCj4gUmV2aWV3IHJlc3VsdDog SGFzIElzc3Vlcw0KPiANCj4gDQo+IEkgdGhpbmsgdGhlcmUncyBvbmUgaXNzdWUgd2l0aCB0aGlz IGRyYWZ0IHRoYXQnZCBiZSB3ZWxsDQo+IHdvcnRoIGRpc2N1c3Npb24gYW5kL29yIGZpeGluZzoN Cj4gDQo+IC0gcDEyOiBXaHkgZG9lcyB0aGUgY3VpZCBuZWVkIHRvIGJlIHNvIHN0YXRpYz8gSSB3 b3VsZA0KPiBoYXZlIHRob3VnaHQgdGhhdCBhbiBpZGVudGlmaWVyIHRoYXQgY2FuIGNoYW5nZSBt b3JlDQo+IG9mdGVuIHRoYW4gYSBrZXkgcGFpciB3b3VsZCBoYXZlIGJlZW4gYmV0dGVyLCBlc3Ag aWYgdGhpcw0KPiBjb3VsZCBiZSB1c2VkIGluIGEgQ1BFLiAoQ3JlYXRpbmcgYSBuZXcgbG9uZy1s aXZlZA0KPiBpZGVudGlmaWVyIGZvciBhIENQRSBzZWVtcyBsaWtlIGEgYmFkIHBsYW4gaWYgaXQn cyBub3QNCj4gcmVhbGx5IG5lZWRlZC4pIEZvciBleGFtcGxlLCBvbmUgY291bGQgdXNlIGJvdGgg dGhlIFNQS0kNCj4gYW5kIGEgdGltZXN0YW1wIGFzIGlucHV0IGZvciBhIHJlY29tbWVuZGVkIHdh eSB0byBnZW5lcmF0ZQ0KPiBhIGN1aWQgYW5kIHRoYXQgc2hvdWxkIGJlIGFzIHVuaXF1ZSwgYnV0 IG11Y2ggbW9yZSBlYXNpbHkNCj4gY2hhbmdlZC4gIFRoYXQgY291bGQgYWxzbyBtaXRpZ2F0ZSB0 aGUgcG9zc2libGUgVExTMS4yDQo+IGNsaWVudC1jZXJ0IHNub29waW5nIGlzc3VlIG1lbnRpb25l ZCBvbiBwOTAuDQoNCltNZWRdIGN1aWQgaXMgdXNlZCBmb3IgYXZvaWRhbmNlIGRldGVjdGlvbiBi dXQgYWxzbyBhcyBhIHN0YWJsZSBrZXkgdG8gaWRlbnRpZnkgcmVzb3VyY2VzIGF0IHRoZSBzZXJ2 ZXIgc2lkZS4gQW55IGNoYW5nZSBvZiB0aGUgY3VpZCB3aWxsIGxlYWQgdG8gYSBmYWlsdXJlIGlu IGFjY2Vzc2luZyB0aGUgcmVzb3VyY2VzLg0KRnVydGhlcm1vcmUsIHRoaXMgaWRlbnRpZmllciBp cyB1c2VkIHRvICJnbHVlIiB0aGUgc2lnbmFsIGFuZCBkYXRhIGNoYW5uZWxzLiAgDQoNClRoZSBz cGVjIGRvZXMgbm90IGZvcmJpZCB0aGUgY2xpZW50cyB0byBjaGFuZ2UgaXRzIGN1aWQsIGJ1dCB0 byBkbyBzbywgdGhlIGNsaWVudCB3aWxsIG5lZWQgdG8gbWFuYWdlIHN0YXRlIG1pZ3JhdGlvbi4g DQoNCj4gDQo+IG5pdHM6DQo+IA0KPiAtIChOb3QgcmVhbGx5IGEgbml0LCBidXQgcHJvYmFibHkg dG9vIG11Y2ggdG8gYXNrLCBzby4uLikNCj4gVGhlIHByb3RvY29sIGhlcmUgc2VlbXMgdmVyeSBj b21wbGV4LiBIYXMgYW55b25lDQo+IHRyaWVkIHRvIHByb3ZlIGFueXRoaW5nIGFib3V0IHRoZSBz dGF0ZSBtYWNoaW5lLCBlLmcuDQo+IHRoYXQncyBpdCdzIHNhZmUgaW4gc29tZSBzZW5zZXM/IEl0 J2QgYmUgZmFpciB0byBzYXkgdGhhdA0KPiB0aGF0IGlzIGEgZ29vZCB0YXNrIHRvIGRvIGFmdGVy IHRoZSBpbml0aWFsIFJGQyBpcw0KPiBwdWJsaXNoZWQgaW4gdGhpcyBjYXNlLCBJIGd1ZXNzLiAg T1RPSCwgY291bGQgYmUgc29tZSBvZg0KPiB0aGUgdGhlb3JlbS1wcm92aW5nIHRvb2xzIHVzZWQg aW4gdGhlIGRldmVsb3BtZW50IG9mDQo+IFRMUzEuMyBjb3VsZCBiZSB1c2VmdWwgaGVyZS4gKEFu ZCB0aG9zZSB0b29scyB1c3VhbGx5DQo+IGRvIHR1cm4gdXAgc29tZSBpc3N1ZXMgd29ydGggZml4 aW5nIC0gSSdkIGJldCBhIGJlZXIgdGhleQ0KPiB3b3VsZCBpbiB0aGlzIGNhc2U6LSkNCg0KW01l ZF0gVGhlIHNwZWNpZmljYXRpb24gd2FzIGVkaXRlZCBmb2xsb3dpbmcgYW4gaW5jcmVtZW50YWwg YXBwcm9hY2ggaW4gd2hpY2ggbmV3IHBpZWNlcyBhcmUgdmFsaWRhdGVkIHRocm91Z2ggYXQgbGVh c3QgdHdvIGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb25zLiBXZSBob3BlIHRoYXQgbW9yZSBm ZWVkYmFjayB3aWxsIGJlIHJlY2VpdmVkIGFmdGVyIHRoZSBpbml0aWFsIFJGQy4gICANCg0KPiAN Cj4gLSBwMTg6ICJPbmx5IHNpbmdsZS12YWx1ZWQgJ2NkaWQnIGFyZSBkZWZpbmVkIGluIHRoaXMN Cj4gZG9jdW1lbnQuIiBUaGF0IGNvbmZ1c2VkIG1lIGdpdmVuIHRoZSB0ZXh0IDMgcGFyYXMNCj4g YmVmb3JlIGFib3V0IG11bHRpcGxlIGNkaWQgdmFsdWVzLiBNYXliZSBjbGFyaWZ5aW5nIHRoYXQN Cj4gc29tZSBjb3VsZCBiZSB1c2VmdWw/DQoNCltNZWRdIFdoYXQgaXMgbWVhbnQgaGVyZSBpcyB0 aGUgY2FzZSB3aGVyZSBtdWx0aXBsZSBHV3MgYXJlIGludm9sdmVkIGluIHRoZSBwYXRoOyBlYWNo IGluc2VydHMgYSBjZGlkIHZhbHVlLiANCg0KV2lsbCBjbGFyaWZ5IHRoZSB0ZXh0LiAgIA0KDQo+ IA0KPiAtIHA3NyBoYXMgYSBmZXcgbG93ZXJjYXNlICJzaG91bGQiIGFuZCAibXVzdCIgc3RhdGVt ZW50cy4NCj4gTm90IHN1cmUgaWYgdGhhdCdzIG9uIHB1cnBvc2Ugb3IgYnkgYWNjaWRlbnQuDQoN CltNZWRdIEkgY29uZmlybSBpdCB3YXMgb24gcHVycG9zZS4gVGhlc2UgYXJlIG5vdCBuZXcgcmVx dWlyZW1lbnRzIChzZWUgU2VjdGlvbiA3LjIpLiAgDQoNCj4gDQo+IC0gcDkwOiBJcyB0aGUgbWVu dGlvbiBvZiBUQ1AtQU8gdGhlcmUgZm9yIHJlYWw/IEknZCBiZQ0KPiBoYXBweSBpdCBpdCB3ZXJl IGJ1dCBpZiBpdCdzIG1lcmVseSBhc3BpcmF0aW9uYWwgYW5kIHlvdQ0KPiBkb24ndCB0aGluayBp dCdsbCBiZSB1c2VkLCBpdCdkIGJlIGJldHRlciB0byBub3QgcHJldGVuZA0KPiBpdCBtaWdodCBn ZXQgdXNlZC4NCj4gDQoNCltNZWRdIFdlIGFyZSBwcm92aWRpbmcgYW4gZXhhbXBsZSBvZiBob3cg dGhlIGlzc3VlIGNhbiBiZSBzb2x2ZWQuIFRoYXQgaXMgZmluZSwgSU1PLg0KDQo+IC0gQ291bGRu J3QgYSBiYWQgYWN0b3IgaW4gY29udHJvbCBvZiBhbiBhdXRob3Jpc2VkIERPVFMNCj4gY2xpZW50 IGNvbGx1ZGluZyB3aXRoIHRoZSBjb250cm9sbGVyIG9mIGEgRERvUyBhdHRhY2sNCj4gdXNlIHRo aXMgdG8gcHJvYmUgdGhlIHN5c3RlbSB0byBzZWUgaG93IHRoZWlyIGF0dGFjayBpcw0KPiBnb2lu ZyBhbmQgY2hhbmdlIHRoZSBhdHRhY2sgdG8gYmUgbW9yZSBlZmZlY3RpdmU/DQoNCltNZWRdIFRo ZSBjbGllbnQgd2lsbCBvbmx5IHNlZSB0aGUgcmVwb3J0cyBmb3IgYXR0YWNrcyBpdCBkZXRlY3Rl ZCBhbmQgc2lnbmFsZWQuIFRoYXQgYmFkIGFjdG9yIHdvbid0IHNpZ25hbCB0aGUgYXR0YWNrIGlu IHRoZSBmaXJzdCBwbGFjZSENCg0KICBJIGRvbid0DQo+IHRoaW5rIGFueSBwcm90b2NvbCBjaGFu Z2UgY291bGQgaGVscCB0aGVyZSwgYnV0IHBlcmhhcHMNCj4geW91IGNvdWxkIGdpdmUgc29tZSBn dWlkYW5jZSB0byBpbXBsZW1lbnRlcnMgdG8gdHJ5IGNhdGNoDQo+IHN1Y2ggY2FzZXMgKGUuZy4s IGlmIHRoZSBwcm9iaW5nIERPVFMgY2xpZW50J3MgbG9jYWwgbi93DQo+IGRvZXNuJ3QgYWN0dWFs bHkgYXBwZWFyIHRvIGJlIHVuZGVyIGF0dGFjaykuDQo+IA0KDQo= From nobody Thu Mar 14 09:19:10 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 B70901312A5 for ; Thu, 14 Mar 2019 09:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=UOQoXcjA; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=JId7qiDP 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 bUR7IrG6epZ7 for ; Thu, 14 Mar 2019 09:18:43 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD1201312B2 for ; Thu, 14 Mar 2019 09:18:42 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1552580321; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=FCFfj7MTVRW8VXrUkW7phOEGZr6sXzv2cu7sGdGGJRY=; b=UOQoXcjAeiF+t26269dGfnJCWxOYKZ6L1kAPsylMt8LKsTUox2vcEObW taxOCSiqiUlrtPzlf2i9HdMN4zdVBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1552580321; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=FCFfj7MTVRW8VXrUkW7phOEGZr6sXzv2cu7sGdGGJRY=; b=JId7qiDPGtp72X+qORf8to4iUOJjkWYHibrgeb87ijST5sy573CQfw8r UnXSikMvy46AQeUOt+rh8UPsC2M+5lgMCBkrnVrkQF8J2YQab/yY1zE7wc XRXKsyfjQT4f4yCghE3SJioxHsXACT9KZusMvG9hDMDdi/ZCSuYzQplKHP v6knNIsJTwBg2fYkT+7sON+Lk7cPTOVuwIBF70RhpoPjeeDzVNQsYq+Jn0 p2HIXbNLPYgu8PUJMPxM2papyn60zBhwaoBks5AUfnhK+QZqHTM2Dfra95 8Ad8FzFg2xyeJgyqgXvxWH1VH7RZhTWSKd26vIHPNGZmn66UV49Yuw== Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 2DF58F99D; Thu, 14 Mar 2019 12:18:40 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 08BCE203A5; Thu, 14 Mar 2019 09:58:33 -0400 (EDT) From: Daniel Kahn Gillmor To: Michael StJohns , Richard Barnes , John Mattsson Cc: CFRG , "RFC ISE \(Adrian Farrel\)" , secdir In-Reply-To: <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Thu, 14 Mar 2019 09:58:32 -0400 Message-ID: <87bm2dimlz.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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, 14 Mar 2019 16:18:59 -0000 On Tue 2019-03-12 16:43:04 -0400, Michael StJohns wrote: > The last couple of discussions have been about the IPR related to OCB > and whether the CFRG should work on it because of that. That's a > perfectly fine set of discussions for a standards WG especially when > considering which modes to include under recommended and mandatory to > implement, but is probably out of place for an RG. The RG ought to be > answering the question "does this proposal have security flaws" and > not "has the patent expired on this" but we seem to be getting far > past the "discussing and analyzing" part of the CFRG charter? I'm not convinced by this line of argument. This group answers not only "does this proposal have security flaws?" but also "can it/will it be deployed effectively, with the security properties we want?" See Tony Arcieri's excellent analysis of the tradeoffs between different modes earlier in this thread for an example. That kind of question is not out of place for a research group -- that's exactly the kind of practical, useful analysis we'd like to see, and i wish all research groups were so productive. Sadly, we live in a world where "IPR" concerns also have an impact on this latter question, and the CFRG happens to have a pool of people with a significant amount of knowledge about the history of cryptographic development and deployment, some of which is occasionally useful in analyzing IPR issues, frustrating though they may be. It's not out of place for the CFRG to include that aspect in its analysis. The CFRG is working well, and has had a significant, positive impact on the IETF over the last several years. If adding the ability to make "standards track" documents would help the CFRG further help the IETF, or could encourage additional useful participation in the CFRG, let's discuss how to do that, but i there's no need to make a constitutional change to the CFRG just because IPR issues come up occasionally here. --dkg From nobody Thu Mar 14 09:40: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 B2C92130E58; Thu, 14 Mar 2019 09:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlUB_8SJr5f8; Thu, 14 Mar 2019 09:40:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F584130E16; Thu, 14 Mar 2019 09:40:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5F1DEBEC6; Thu, 14 Mar 2019 16:40:21 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZtprDUaBJBu; Thu, 14 Mar 2019 16:40:21 +0000 (GMT) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 190DABEC3; Thu, 14 Mar 2019 16:40:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1552581621; bh=DqETg5CMahx9/l4zD3t8PJZH5INuFzH/+k4NOqR+kio=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=PEu74475Jh2dxBbBYjjn7zAbCqx+ui0nsE50KH6rvMRTd+DSblg3LZVigkfvGyH5U MJ7Qql5bJHTNz8YUGo0y9NcM/75C5UDDKNuWkDEpJqfC/9yc1O1H3JiOBKTpFGeQt8 G6E5hBn1ou/thvK0G97ubyNTJqUKchdy9LtvDXKQ= To: mohamed.boucadair@orange.com, "secdir@ietf.org" Cc: "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" References: <155257761487.2625.10003476313108979036@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA3DFC8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <72f7b85c-74fb-0f79-8211-50043c2b4b47@cs.tcd.ie> Date: Thu, 14 Mar 2019 16:40:16 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA3DFC8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="X0q8R5GWBBmyzSMJ9z3TxaHqWNpzvEIqh" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dots-signal-channel-30 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, 14 Mar 2019 16:40:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --X0q8R5GWBBmyzSMJ9z3TxaHqWNpzvEIqh Content-Type: multipart/mixed; boundary="JNfyjY6aVRYdKeqOT6YquQnCiQdsTAheE"; protected-headers="v1" From: Stephen Farrell To: mohamed.boucadair@orange.com, "secdir@ietf.org" Cc: "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" Message-ID: <72f7b85c-74fb-0f79-8211-50043c2b4b47@cs.tcd.ie> Subject: Re: Secdir last call review of draft-ietf-dots-signal-channel-30 References: <155257761487.2625.10003476313108979036@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA3DFC8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA3DFC8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> --JNfyjY6aVRYdKeqOT6YquQnCiQdsTAheE Content-Type: multipart/mixed; boundary="------------C8FF466762B1695E3CC8DE31" Content-Language: en-GB This is a multi-part message in MIME format. --------------C8FF466762B1695E3CC8DE31 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Just on two bits below... I'm happy to chat more but also fine that you and the ADs can sort this out according to however the ADs see this. On 14/03/2019 16:17, mohamed.boucadair@orange.com wrote: >> I think there's one issue with this draft that'd be well worth >> discussion and/or fixing: >>=20 >> - p12: Why does the cuid need to be so static? I would have thought >> that an identifier that can change more often than a key pair would >> have been better, esp if this could be used in a CPE. (Creating a >> new long-lived identifier for a CPE seems like a bad plan if it's >> not really needed.) For example, one could use both the SPKI and a >> timestamp as input for a recommended way to generate a cuid and >> that should be as unique, but much more easily changed. That could >> also mitigate the possible TLS1.2 client-cert snooping issue >> mentioned on p90. >=20 > [Med] cuid is used for avoidance detection but also as a stable key > to identify resources at the server side. Any change of the cuid will > lead to a failure in accessing the resources. Furthermore, this > identifier is used to "glue" the signal and data channels. >=20 > The spec does not forbid the clients to change its cuid, but to do > so, the client will need to manage state migration. Yep, I get that. But the current alg that's described for cuid calculation has the effect of creating an identifier with the same lifetime as a key pair. Assuming keys are harder to change than cuids it seems better to encourage clients to not make such a tight linkage between cuid and keys, esp. if the client is on a CPE. (And it avoids the TLS1.2 snooping issue as noted.) I'd encourage you to consider maybe saying some more about how clients can change cuid, but even if not, to provide a cuid calculation example that doesn't link only to the key pair. >> - Couldn't a bad actor in control of an authorised DOTS client >> colluding with the controller of a DDoS attack use this to probe >> the system to see how their attack is going and change the attack >> to be more effective? >=20 > [Med] The client will only see the reports for attacks it detected > and signaled. That bad actor won't signal the attack in the first > place! Perhaps I wasn't clear. ISTM that all clients can get information about how an attack is being seen at other clients, isn't that right? (The spec does talk about that IIRC.) The colluding client might or might not be under attack but non-compromised clients will presumably ask for the attack to be mitigated. So the colluding client could use this protocol to probe and see how well or badly the DDoS-mitigation infrastructure is handling an ongoing attack. I'm basically saying that that may be noteworthy as a security consideration. Cheers, S. >=20 > I don't >> think any protocol change could help there, but perhaps you could >> give some guidance to implementers to try catch such cases (e.g., >> if the probing DOTS client's local n/w doesn't actually appear to >> be under attack). >>=20 >=20 --------------C8FF466762B1695E3CC8DE31 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------C8FF466762B1695E3CC8DE31-- --JNfyjY6aVRYdKeqOT6YquQnCiQdsTAheE-- --X0q8R5GWBBmyzSMJ9z3TxaHqWNpzvEIqh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyKg/EACgkQWrL68XsX K+ofwA/6AmnxxXRwVee3EbjZFVZpLvJ6MeTvgnBKZ09cLRb253QCSQO2nqB6oJzZ DmtVtydNpyc40s6OSqDXeJSba6RbvMQxWwpxTcPAXXB9TWVv6JtroqqGsOMEKBbh j/YBeUrELPQtz6j9y8BcY6qjf47oL9xO5wxrcu03Au/vaJPH7i7BJ0wz9BN2st2a uZ7G7lWLC0yiHX8S1QuQZhz1Jczbs6cT3zkVE134KvkIrGH7L6JG3VrE7eAOt4mG 4IBFfhJGM3hgYX6Mqlat/Pehpo9pjKSkkgM8DbLLrUYL/aj351kh85AMFr8HPRJv /GS+eX8xwDwCjJISAnKJv1HzALUQxYv5ZCDV/pAl13r52gjgsMeTuy37cDTYOD4i qSA9Vjp2xpRhxrQLIDS/YGzW+LJz6M0thxszvjjkDwIJgM3Zgni2WxNvYRznCjII etGB5j8wV+EYBynUj9hJGRJno13DWx249xHVKy0J/ccOzZU5Kl5r7GjAPKXpZqN+ n+la6uDFAdSLSI8myE7qtIbF+jn1wOl1sm+50y3vOODpfWA0Uwler550ReQSwTOc sTa5DcUkED+467AYqj73zFLaoJbWBSqP7izLlkmfrCM2e9wsXPLk/CSXvoYH8xoH DlSLP2GpNZdUZb9VkKIkhlRLw//CqlWHJJw0FMplRtb2DkKRgfo= =Ziif -----END PGP SIGNATURE----- --X0q8R5GWBBmyzSMJ9z3TxaHqWNpzvEIqh-- From nobody Thu Mar 14 10:58:25 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 388741279AD for ; Thu, 14 Mar 2019 10:58:23 -0700 (PDT) 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.94.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <155258630322.2687.16915853360619872180.idtracker@ietfa.amsl.com> Date: Thu, 14 Mar 2019 10:58:23 -0700 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 Mar 2019 17:58:23 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-03-14 Reviewer LC end Draft Charlie Kaufman 2019-03-14 draft-ietf-trans-rfc6962-bis-31 Klaas Wierenga 2019-02-26 draft-ietf-mpls-sr-over-ip-03 For telechat 2019-04-11 Reviewer LC end Draft Christian Huitema 2019-03-18 draft-ietf-iasa2-rfc4071bis-08 Tero Kivinen 2019-04-01 draft-ietf-iasa2-consolidated-upd-07 Stefan Santesson 2019-02-11 draft-ietf-extra-imap-fetch-preview-03 Last calls: Reviewer LC end Draft Derek Atkins 2019-03-03 draft-ietf-netmod-module-tags-07 Nancy Cam-Winget 2019-02-15 draft-ietf-rtcweb-security-11 Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-27 Donald Eastlake 2019-03-20 draft-ietf-pce-stateful-pce-p2mp-12 Daniel Franke 2019-03-18 draft-ietf-sidrops-https-tal-07 Daniel Gillmor 2018-03-19 draft-gutmann-scep-13 Phillip Hallam-Baker 2019-03-18 draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04 Leif Johansson 2019-03-14 draft-ietf-dmarc-eaiauth-03 Stephen Kent 2019-04-03 draft-ietf-manet-dlep-pause-extension-05 Watson Ladd 2019-04-01 draft-ietf-bess-bgp-vpls-control-flags-07 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Tim Polk 2019-02-13 draft-ietf-sipcore-reason-q850-loc-06 Vincent Roca R2019-02-13 draft-ietf-perc-private-media-framework-09 Stefan Santesson R2018-11-20 draft-wilde-service-link-rel-10 Takeshi Takahashi R2018-08-31 draft-ietf-lisp-rfc6833bis-24 David Waltermire 2019-02-15 draft-ietf-rtcweb-ip-handling-11 Taylor Yu 2019-02-15 draft-ietf-rtcweb-security-arch-18 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-11 Early review requests: Reviewer Due Draft Alan DeKok 2019-03-18 draft-cel-nfsv4-rpc-tls-02 Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Scott Kelly 2019-03-22 draft-ietf-rift-rift-04 Next in the reviewer rotation: Stephen Kent Tero Kivinen Watson Ladd Ben Laurie Barry Leiba Chris Lonvick Aanchal Malhotra David Mandelberg Catherine Meadows Alexey Melnikov From nobody Thu Mar 14 18:48: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 D1ECD1289FA; Thu, 14 Mar 2019 18:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZW0b5MAaCQY6; Thu, 14 Mar 2019 18:47:48 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB911275E9; Thu, 14 Mar 2019 18:47:44 -0700 (PDT) Received: from healthyao-PC (unknown [218.241.103.187]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0ApMLg8BItcFfdQAA--.27733S2; Fri, 15 Mar 2019 09:47:41 +0800 (CST) Date: Fri, 15 Mar 2019 09:47:42 +0800 From: "Jiankang Yao" To: "Russ Housley via Datatracker" , "secdir@ietf.org" Cc: draft-ietf-regext-bundling-registration.all , ietf , regext Reply-To: yaojk References: <155210908621.26593.15343460778938123458@ietfa.amsl.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <2019031509471945798644@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart556568281058_=----" X-CM-TRANSID: AQAAf0ApMLg8BItcFfdQAA--.27733S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Ww4DJF1Dur1UKF4fuw4xtFb_yoW5JrWDpa n5Ww43Grn5Aw48Gws7AF18uryFk3s3ta17Arn8W34jvay5GF1vgFWa9390v3WkAr1fZFWY qw1jkrZ0qr15ZFDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUdSb7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40Eb7x2 x7xS6r4j6ryUMc02F40E57IF67AEF4xIwI1l5I8CrVAKz4kIr2xC04v26r4j6ryUMc02F4 0E42I26xC2a48xMc02F40Ex7xS67I2xxkvbII20VAazxkCjI0Eb7x7McIj6xIIjxv20xvE 14v26r106r15McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2 IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07MxkIecxE wVAFwVWkMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrV AFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCI c40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267 AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_ Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JwCE64xvF2IEb7IF0Fy7YxBIdaVFxh VjvjDU0xZFpf9x07j0rWrUUUUU= X-CM-SenderInfo: x1dryyw6fq0xffof0/ Archived-At: Subject: Re: [secdir] [regext] Secdir last call review of draft-ietf-regext-bundling-registration-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: Fri, 15 Mar 2019 01:47:51 -0000 This is a multi-part message in MIME format. ------=_001_NextPart556568281058_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCjwgICAgICAgICAgIEZyb206IFJ1c3MgSG91c2xleSB2aWEgRGF0YXRyYWNrZXINCjwgICAg ICAgICAgIERhdGU6IDIwMTktMDMtMDkgMTM6MjQNCjwgICAgICAgICAgIFRvOiBzZWNkaXJAaWV0 Zi5vcmcNCjwgICAgICAgICAgIENDOiBkcmFmdC1pZXRmLXJlZ2V4dC1idW5kbGluZy1yZWdpc3Ry YXRpb24uYWxsOyBpZXRmOyByZWdleHQNCjwgICAgICAgICAgIFN1YmplY3Q6IFtyZWdleHRdIFNl Y2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcmVnZXh0LWJ1bmRsaW5nLXJlZ2lz dHJhdGlvbi0wOQ0KPCAgICAgICAgICAgUmV2aWV3ZXI6IFJ1c3MgSG91c2xleQ0KPCAgICAgICAg ICAgUmV2aWV3IHJlc3VsdDogSGFzIElzc3Vlcw0KPCAgICAgICAgICAgSSByZXZpZXdlZCB0aGlz IGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIFNlY3VyaXR5IERpcmVjdG9yYXRlJ3Mgb25nb2luZw0K PCAgICAgICAgICAgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJv Y2Vzc2VkIGJ5IHRoZSBJRVNHLiBUaGVzZQ0KPCAgICAgICAgICAgY29tbWVudHMgd2VyZSB3cml0 dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIFNlY3VyaXR5IEFyZWENCjwgICAg ICAgICAgIERpcmVjdG9ycy4gRG9jdW1lbnQgYXV0aG9ycywgZG9jdW1lbnQgZWRpdG9ycywgYW5k IFdHIGNoYWlycyBzaG91bGQNCjwgICAgICAgICAgIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3Qg bGlrZSBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMuDQo8ICAgICAgICAgICBEb2N1 bWVudDogZHJhZnQtaWV0Zi1yZWdleHQtYnVuZGxpbmctcmVnaXN0cmF0aW9uLTA5DQo8ICAgICAg ICAgICBSZXZpZXdlcjogUnVzcyBIb3VzbGV5DQo8ICAgICAgICAgICBSZXZpZXcgRGF0ZTogMjAx OS0wMy0wOQ0KPCAgICAgICAgICAgSUVURiBMQyBFbmQgRGF0ZTogMjAxOS0wMy0xNQ0KPCAgICAg ICAgICAgSUVTRyBUZWxlY2hhdCBkYXRlOiB1bmtub3duDQoNClRoYW5rcyBmb3IgeW91ciBraW5k IHJldmlldy4NCg0KPCAgICAgICAgICAgU3VtbWFyeTogSGFzIElzc3Vlcw0KPCAgICAgICAgICAg TWFqb3IgQ29uY2VybnM6DQo8ICAgICAgICAgICBJZiB0aGlzIGRvY3VtZW50IGlzIGdvaW5nIHRv IGJlIHB1Ymxpc2hlZCBvbiB0aGUgSUVURiBTdHJlYW0sIHRoZW4gdGhlDQo8ICAgICAgICAgICBJ QU5BIHJlZ2lzdHJhdGlvbnMgc2hvdWxkIHBvaW50IHRvIHRoZSBJRVNHLCBub3QgdGhlIGRvY3Vt ZW50IGF1dGhvcnMuDQoNCldlIHdpbGwgdXBkYXRlIGl0LiBJQU5BIHJlZ2lzdHJhdGlvbnMgd2ls bCBwb2ludCB0byB0aGUgSUVTRy4NCg0KDQo8ICAgICAgICAgICBNaW5vciBDb25jZXJuczoNCjwg ICAgICAgICAgIFNlY3Rpb24gMjogUGxlYXNlIHVwZGF0ZSB0aGUgZmlyc3QgcGFyYWdyYXBoIHRv IHJlZmVyZW5jZSBSRkMgODE3NA0KPCAgICAgICAgICAgaW4gYWRkaXRpb24gdG8gUkZDIDIxMTks IGFzIGZvbGxvd3M6IA0KPCAgICAgICAgICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5P VCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KPCAgICAgICAgICAgIlNIT1VM RCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk5PVCBSRUNPTU1FTkRFRCIsICJNQVki LCBhbmQNCjwgICAgICAgICAgICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUg aW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluDQo8ICAgICAgICAgICBCQ1AgMTQgW1JGQzIxMTld IFtSRkM4MTc0XSB3aGVuLCBhbmQgb25seSB3aGVuLCB0aGV5IGFwcGVhciBpbiBhbGwNCjwgICAg ICAgICAgIGNhcGl0YWxzLCBhcyBzaG93biBoZXJlLg0KDQpUaGFua3MsIHdpbGwgdXBkYXRlIGl0 LiANCg0KPCAgICAgICAgICAgTml0czoNCjwgICAgICAgICAgIFRoZSBkb2N1bWVudCBoYXMgbWFu eSBncmFtbWVyIGVycm9ycy4gRm9yIGV4YW1wbGUsIHRoZSBmaXJzdCBwYXJhZ3JhcGgNCjwgICAg ICAgICAgIG9mIHRoZSBJbnRyb2R1Y3Rpb24gaGFzIHRocmVlIHRoaW5ncyB0aGF0IG5lZWQgdG8g YmUgY29ycmVjdGVkOg0KLSAgICAgICAgICBzL3doaWNoIGhhcyBpZGVudGljYWwvd2hpY2ggaGF2 ZSBpZGVudGljYWwvDQotICAgICAgICAgIHMvbGFiZWxzKExBQkVMKS9sYWJlbHMgKExBQkVMKS8N Ci0gICAgICAgICAgcy8oVi10bGQpOy8oVi10bGQpLi8NCjwgICAgICAgICAgIEluIGFkZGl0aW9u LCB0aGVyZSBhcmUgc2V2ZXJhbCBwbGFjZXMgaW4gdGhlIGRvY3VtZW50IHdpdGggYXJiaXRyYXJ5 DQo8ICAgICAgICAgICBleHRyYSB3aGl0ZSBzcGFjZS4gRm9yIGV4YW1wbGUsIGluIFNlY3Rpb24g OCwgaXQgc2F5czoNCjwgICAgICAgICAgIDwhLS0NCjwgICAgICAgICAgIENoaWxkIGVsZW1lbnRz IG9mIHRoZSA8Yi1kbjpjcmVhdGU+IGNvbW1hbmQNCjwgICAgICAgICAgIEFsbCBlbGVtZW50cyBt dXN0IGJlIHByZXNlbnQgYXQgdGltZSBvZiBjcmVhdGlvbg0KPCAgICAgICAgICAgLS0+DQo8ICAg ICAgICAgICBQbGVhc2UgY29ycmVjdCB0aGUgZ3JhbW1hciBhbmQgZWxpbWluYXRlIHRoZSBleHRy YSB3aGl0ZSBzcGFjZS4NCjwgICAgICAgICAgIElucyBTZWN0aW9uIDcuMi4yLCBzb21lIG9mIHRo ZSBsaW5lcyBpbiB0aGUgZXhhbXBsZXMgZG8gbm90IGJlZ2luDQo8ICAgICAgICAgICB3aXRoICJT OiIuIFBsZWFzZSBjb3JyZWN0Lg0KPCAgICAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCg0KVGhhbmtzLCB3ZSB3aWxsIGhhdmUgYSBkZXRhaWxl ZCByZXZpZXcgYW5kIHVwZGF0ZSBpdCBpbiB0aGUgbmV3IHZlcnNpb24uDQoNCg0KSmlhbmthbmcg WWFvDQoNCg0KPCAgICAgICAgICAgcmVnZXh0IG1haWxpbmcgbGlzdA0KPCAgICAgICAgICAgcmVn ZXh0QGlldGYub3JnDQo8ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3JlZ2V4dA0KIA== ------=_001_NextPart556568281058_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
 
<      =     =20 From: Russ Housley via=20 Datatracker

<      =     =20 Date: 2019-03-09 13:24

<      =     =20 To: secdir@ietf.org

<      =     =20 CC: draft-ietf-regext-bundli= ng-registration.all;=20 ietf; regext

<      =     =20 Subject: [regext] Secdir last call review of=20 draft-ietf-regext-bundling-registration-09

<      =     =20 Reviewer: Russ Housley

<      =     =20 Review result: Has Issues

<      =     =20 I reviewed this document as part of the Security Directorate'= s=20 ongoing

<      =     =20 effort to review all IETF documents being processed by the IE= SG.=20 These

<      =     =20 comments were written primarily for the benefit of the Securi= ty=20 Area

<      =     =20 Directors. Document authors, document editors, and WG chairs=20 should

<      =     =20 treat these comments just like any other IETF Last Call=20 comments.

<      =     =20 Document:=20 draft-ietf-regext-bundling-registration-09

<      =     =20 Reviewer: Russ Housley

<      =     =20 Review Date: 2019-03-09

<      =     =20 IETF LC End Date: 2019-03-15

<      =     =20 IESG Telechat date: unknown

 

Thanks for your kind review.

 

<      =     =20 Summary: Has Issues

<      =     =20 Major Concerns:

<      =     =20 If this document is going to be published on the IETF Stream,= then=20 the

<      =     =20 IANA registrations should point to the IESG, not the document= =20 authors.

 

We will update it. IANA registrations will point to the IESG.=

 

 

<      =     =20 Minor Concerns:

<      =     =20 Section 2: Please update the first paragraph to reference RFC= =20 8174

<      =     =20 in addition to RFC 2119, as follows:

<      =     =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL= =20 NOT",

<      =     =20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MA= Y",=20 and

<      =     =20 "OPTIONAL" in this document are to be interpreted as describe= d=20 in

<      =     =20 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear i= n=20 all

<      =     =20 capitals, as shown here.

 

Thanks, will update it.

 

<      =     =20 Nits:

<      =     =20 The document has many grammer errors. For example, the first=20 paragraph

<      =     =20 of the Introduction has three things that need to be=20 corrected:

-      =    =20 s/which has identical/which have identical/=

-      =    =20 s/labels(LABEL)/labels (LABEL)/

-      =    =20 s/(V-tld);/(V-tld)./

<      =     =20 In addition, there are several places in the document with=20 arbitrary

<      =     =20 extra white space. For example, in Section 8, it=20 says:

<      =     =20 <!--

<      =     =20 Child elements of the <b-dn:create>=20 command

<      =     =20 All elements must be present at time of=20 creation

<      =     =20 -->

<      =     =20 Please correct the grammar and eliminate the extra white=20 space.

<      =     =20 Ins Section 7.2.2, some of the lines in the examples do not=20 begin

<      =     =20 with "S:". Please correct.

<      =     =20 _______________________________________________

 

Thanks, we will have a detailed review and update it in the n= ew=20 version.

 

 

Jiankang Yao

 

 

<      =     =20 regext mailing list

<      =     =20 regext@ietf.org

<      =     =20 https://www.ietf.org/mailman/listinfo/regext

 

------=_001_NextPart556568281058_=------ From nobody Thu Mar 14 21:30:42 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 02D721311B9; Thu, 14 Mar 2019 21:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, 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=mcafee.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 yb2x6QsZkviN; Thu, 14 Mar 2019 21:30:24 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 9221F1287C2; Thu, 14 Mar 2019 21:30:23 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1552624009; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:x-originating-ip: x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-forefront-prvs:x-forefront-antispam-report: received-spf:authentication-results:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=GECLkYsbxZnEPdjQfZZFYoEOBWz7GgNUOBRtv2 a6Vuc=; b=JHjtUPv2C08drjoHRTRWKgnsevB8N53hGwioqDTc 86dEePTkVL5PuvzW6kAN2RAx1qILTmaL7CXSaPUTEJYDP3gkgg 2cDwkoiu5kSYWwDyDVkE7yC7Du+Qo22bH1vByC1lRIJv8GYty6 5STPAphBEf2hGb960wtwiPo+V3oOki8= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 4fb3_4565_5cc339cc_a699_4e22_bf9c_1d641836ee56; Thu, 14 Mar 2019 22:26:49 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 14 Mar 2019 22:30:09 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 14 Mar 2019 22:30:09 -0600 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 14 Mar 2019 22:30:08 -0600 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2968.namprd16.prod.outlook.com (20.178.235.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.13; Fri, 15 Mar 2019 04:30:07 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1709.011; Fri, 15 Mar 2019 04:30:07 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "Stephen Farrell" , "secdir@ietf.org" CC: "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-dots-signal-channel-30 Thread-Index: AQHU2oF5bx6+d1T5QkC+CtJqzs0JZ6YMGWiw Date: Fri, 15 Mar 2019 04:30:07 +0000 Message-ID: References: <155257761487.2625.10003476313108979036@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA3DFC8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA3DFC8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1b477aee-341e-44d3-58e1-08d6a8fee784 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2968; x-ms-traffictypediagnostic: BYAPR16MB2968: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 09778E995A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(376002)(39860400002)(366004)(346002)(32952001)(199004)(13464003)(189003)(71190400001)(110136005)(71200400001)(54906003)(97736004)(229853002)(476003)(966005)(186003)(478600001)(68736007)(52536014)(6246003)(9686003)(8936002)(6506007)(72206003)(4326008)(7736002)(74316002)(305945005)(6306002)(81156014)(80792005)(81166006)(53546011)(446003)(8676002)(11346002)(5660300002)(7696005)(5024004)(105586002)(33656002)(3846002)(102836004)(86362001)(256004)(6116002)(14444005)(316002)(66066001)(486006)(6346003)(2906002)(26005)(2501003)(25786009)(14454004)(76176011)(55016002)(53936002)(99286004)(106356001)(6436002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2968; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: AuThYxsKoZLy0koF2nfX5kZVWq+KKw4IX3SS+rWkOELuKhbBfupWNCHGK155gt/dNqS9tNnHS0RvjP6MGvwScB1YsipBapFUJ6CyMM+1D8OMAsGF5TG8jWiQWy6VeEqV2HATDCPTtrP8fXjHIKr+v2RY9JliCu1WrG3Cbd+ss9ar/uZ0kygGxm4teTfJykZ+dqrAZoAbx3CmzRcgxFIfMzG3pGMMZXnAVWmSkICxHBM8CH+EjiynwiBPZV7nkRZD2xJLZYlSW7crJXNtWlD+o4sJx7BmJM5aPL47mG/KxVw+xBq0hBxgz1OXEyHUbLEZl1cSUYYG+nPAwyrq8/TPDoatvGlySTpHl7pmusT9KD3u5JDYvSdfAlZsCY5sqo5CnZ4Z8mY+W9r4wxD/9tuIGvSGzlVylZeLdoV37g/wQWE= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1b477aee-341e-44d3-58e1-08d6a8fee784 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2019 04:30:07.7352 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR16MB2968 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6503> : inlines <7034> : streams <1815743> : uri <2813012> Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dots-signal-channel-30 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, 15 Mar 2019 04:30:27 -0000 UGxlYXNlIHNlZSBpbmxpbmUgDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogRG90cyA8ZG90cy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YNCj4gbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiBTZW50OiBUaHVyc2RheSwgTWFyY2ggMTQsIDIwMTkgOTo0 NyBQTQ0KPiBUbzogU3RlcGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPjsg c2VjZGlyQGlldGYub3JnDQo+IENjOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwuYWxs QGlldGYub3JnOyBpZXRmQGlldGYub3JnOyBkb3RzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBb RG90c10gU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1j aGFubmVsLTMwDQo+IA0KPiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRo ZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvcg0KPiBvcGVuIGF0dGFjaG1lbnRz IHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMN Cj4gc2FmZS4NCj4gDQo+IEhpIFN0ZXBoZW4sDQo+IA0KPiBUaGFuayB5b3UgZm9yIHRoZSByZXZp ZXcuDQo+IA0KPiBQbGVhc2Ugc2VlIGlubGluZS4NCj4gDQo+IENoZWVycywNCj4gTWVkDQo+IA0K PiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+IERlwqA6IFN0ZXBoZW4gRmFycmVs bCB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5QGlldGYub3JnXSBFbnZvecOpDQo+ID4g OiBqZXVkaSAxNCBtYXJzIDIwMTkgMTY6MzQgw4DCoDogc2VjZGlyQGlldGYub3JnIENjwqA6DQo+ ID4gZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLmFsbEBpZXRmLm9yZzsgaWV0ZkBpZXRm Lm9yZzsNCj4gPiBkb3RzQGlldGYub3JnIE9iamV0wqA6IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3 IG9mDQo+ID4gZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLTMwDQo+ID4NCj4gPiBSZXZp ZXdlcjogU3RlcGhlbiBGYXJyZWxsDQo+ID4gUmV2aWV3IHJlc3VsdDogSGFzIElzc3Vlcw0KPiA+ DQo+ID4NCj4gPiBJIHRoaW5rIHRoZXJlJ3Mgb25lIGlzc3VlIHdpdGggdGhpcyBkcmFmdCB0aGF0 J2QgYmUgd2VsbCB3b3J0aA0KPiA+IGRpc2N1c3Npb24gYW5kL29yIGZpeGluZzoNCj4gPg0KPiA+ IC0gcDEyOiBXaHkgZG9lcyB0aGUgY3VpZCBuZWVkIHRvIGJlIHNvIHN0YXRpYz8gSSB3b3VsZCBo YXZlIHRob3VnaHQNCj4gPiB0aGF0IGFuIGlkZW50aWZpZXIgdGhhdCBjYW4gY2hhbmdlIG1vcmUg b2Z0ZW4gdGhhbiBhIGtleSBwYWlyIHdvdWxkDQo+ID4gaGF2ZSBiZWVuIGJldHRlciwgZXNwIGlm IHRoaXMgY291bGQgYmUgdXNlZCBpbiBhIENQRS4gKENyZWF0aW5nIGEgbmV3DQo+ID4gbG9uZy1s aXZlZCBpZGVudGlmaWVyIGZvciBhIENQRSBzZWVtcyBsaWtlIGEgYmFkIHBsYW4gaWYgaXQncyBu b3QNCj4gPiByZWFsbHkgbmVlZGVkLikgRm9yIGV4YW1wbGUsIG9uZSBjb3VsZCB1c2UgYm90aCB0 aGUgU1BLSSBhbmQgYQ0KPiA+IHRpbWVzdGFtcCBhcyBpbnB1dCBmb3IgYSByZWNvbW1lbmRlZCB3 YXkgdG8gZ2VuZXJhdGUgYSBjdWlkIGFuZCB0aGF0DQo+ID4gc2hvdWxkIGJlIGFzIHVuaXF1ZSwg YnV0IG11Y2ggbW9yZSBlYXNpbHkgY2hhbmdlZC4gIFRoYXQgY291bGQgYWxzbw0KPiA+IG1pdGln YXRlIHRoZSBwb3NzaWJsZSBUTFMxLjIgY2xpZW50LWNlcnQgc25vb3BpbmcgaXNzdWUgbWVudGlv bmVkIG9uDQo+ID4gcDkwLg0KPiANCj4gW01lZF0gY3VpZCBpcyB1c2VkIGZvciBhdm9pZGFuY2Ug ZGV0ZWN0aW9uIGJ1dCBhbHNvIGFzIGEgc3RhYmxlIGtleSB0bw0KPiBpZGVudGlmeSByZXNvdXJj ZXMgYXQgdGhlIHNlcnZlciBzaWRlLiBBbnkgY2hhbmdlIG9mIHRoZSBjdWlkIHdpbGwgbGVhZCB0 byBhDQo+IGZhaWx1cmUgaW4gYWNjZXNzaW5nIHRoZSByZXNvdXJjZXMuDQo+IEZ1cnRoZXJtb3Jl LCB0aGlzIGlkZW50aWZpZXIgaXMgdXNlZCB0byAiZ2x1ZSIgdGhlIHNpZ25hbCBhbmQgZGF0YSBj aGFubmVscy4NCj4gDQo+IFRoZSBzcGVjIGRvZXMgbm90IGZvcmJpZCB0aGUgY2xpZW50cyB0byBj aGFuZ2UgaXRzIGN1aWQsIGJ1dCB0byBkbyBzbywgdGhlDQo+IGNsaWVudCB3aWxsIG5lZWQgdG8g bWFuYWdlIHN0YXRlIG1pZ3JhdGlvbi4NCj4gDQo+ID4NCj4gPiBuaXRzOg0KPiA+DQo+ID4gLSAo Tm90IHJlYWxseSBhIG5pdCwgYnV0IHByb2JhYmx5IHRvbyBtdWNoIHRvIGFzaywgc28uLi4pIFRo ZSBwcm90b2NvbA0KPiA+IGhlcmUgc2VlbXMgdmVyeSBjb21wbGV4LiBIYXMgYW55b25lIHRyaWVk IHRvIHByb3ZlIGFueXRoaW5nIGFib3V0IHRoZQ0KPiA+IHN0YXRlIG1hY2hpbmUsIGUuZy4NCj4g PiB0aGF0J3MgaXQncyBzYWZlIGluIHNvbWUgc2Vuc2VzPyBJdCdkIGJlIGZhaXIgdG8gc2F5IHRo YXQgdGhhdCBpcyBhDQo+ID4gZ29vZCB0YXNrIHRvIGRvIGFmdGVyIHRoZSBpbml0aWFsIFJGQyBp cyBwdWJsaXNoZWQgaW4gdGhpcyBjYXNlLCBJDQo+ID4gZ3Vlc3MuICBPVE9ILCBjb3VsZCBiZSBz b21lIG9mIHRoZSB0aGVvcmVtLXByb3ZpbmcgdG9vbHMgdXNlZCBpbiB0aGUNCj4gPiBkZXZlbG9w bWVudCBvZg0KPiA+IFRMUzEuMyBjb3VsZCBiZSB1c2VmdWwgaGVyZS4gKEFuZCB0aG9zZSB0b29s cyB1c3VhbGx5IGRvIHR1cm4gdXAgc29tZQ0KPiA+IGlzc3VlcyB3b3J0aCBmaXhpbmcgLSBJJ2Qg YmV0IGEgYmVlciB0aGV5IHdvdWxkIGluIHRoaXMgY2FzZTotKQ0KPiANCj4gW01lZF0gVGhlIHNw ZWNpZmljYXRpb24gd2FzIGVkaXRlZCBmb2xsb3dpbmcgYW4gaW5jcmVtZW50YWwgYXBwcm9hY2gg aW4NCj4gd2hpY2ggbmV3IHBpZWNlcyBhcmUgdmFsaWRhdGVkIHRocm91Z2ggYXQgbGVhc3QgdHdv IGludGVyb3BlcmFibGUNCj4gaW1wbGVtZW50YXRpb25zLiBXZSBob3BlIHRoYXQgbW9yZSBmZWVk YmFjayB3aWxsIGJlIHJlY2VpdmVkIGFmdGVyIHRoZQ0KPiBpbml0aWFsIFJGQy4NCj4gDQo+ID4N Cj4gPiAtIHAxODogIk9ubHkgc2luZ2xlLXZhbHVlZCAnY2RpZCcgYXJlIGRlZmluZWQgaW4gdGhp cyBkb2N1bWVudC4iIFRoYXQNCj4gPiBjb25mdXNlZCBtZSBnaXZlbiB0aGUgdGV4dCAzIHBhcmFz IGJlZm9yZSBhYm91dCBtdWx0aXBsZSBjZGlkIHZhbHVlcy4NCj4gPiBNYXliZSBjbGFyaWZ5aW5n IHRoYXQgc29tZSBjb3VsZCBiZSB1c2VmdWw/DQo+IA0KPiBbTWVkXSBXaGF0IGlzIG1lYW50IGhl cmUgaXMgdGhlIGNhc2Ugd2hlcmUgbXVsdGlwbGUgR1dzIGFyZSBpbnZvbHZlZCBpbg0KPiB0aGUg cGF0aDsgZWFjaCBpbnNlcnRzIGEgY2RpZCB2YWx1ZS4NCg0KJ2NkaWQnIGlzIG9ubHkgaW5zZXJ0 ZWQgYnkgdGhlIHNlcnZlci1kb21haW4gRE9UUyBnYXRld2F5LiBGaWd1cmUgOCBuZWVkcyB0byBi ZSBjb3JyZWN0ZWQsICdjdWlkJyBpcyBtaXNzaW5nIGluIHRoZSBGaWd1cmUuDQoNCkNoZWVycywN Ci1UaXJ1DQoNCj4gDQo+IFdpbGwgY2xhcmlmeSB0aGUgdGV4dC4NCj4gDQo+ID4NCj4gPiAtIHA3 NyBoYXMgYSBmZXcgbG93ZXJjYXNlICJzaG91bGQiIGFuZCAibXVzdCIgc3RhdGVtZW50cy4NCj4g PiBOb3Qgc3VyZSBpZiB0aGF0J3Mgb24gcHVycG9zZSBvciBieSBhY2NpZGVudC4NCj4gDQo+IFtN ZWRdIEkgY29uZmlybSBpdCB3YXMgb24gcHVycG9zZS4gVGhlc2UgYXJlIG5vdCBuZXcgcmVxdWly ZW1lbnRzIChzZWUNCj4gU2VjdGlvbiA3LjIpLg0KPiANCj4gPg0KPiA+IC0gcDkwOiBJcyB0aGUg bWVudGlvbiBvZiBUQ1AtQU8gdGhlcmUgZm9yIHJlYWw/IEknZCBiZSBoYXBweSBpdCBpdA0KPiA+ IHdlcmUgYnV0IGlmIGl0J3MgbWVyZWx5IGFzcGlyYXRpb25hbCBhbmQgeW91IGRvbid0IHRoaW5r IGl0J2xsIGJlDQo+ID4gdXNlZCwgaXQnZCBiZSBiZXR0ZXIgdG8gbm90IHByZXRlbmQgaXQgbWln aHQgZ2V0IHVzZWQuDQo+ID4NCj4gDQo+IFtNZWRdIFdlIGFyZSBwcm92aWRpbmcgYW4gZXhhbXBs ZSBvZiBob3cgdGhlIGlzc3VlIGNhbiBiZSBzb2x2ZWQuIFRoYXQgaXMNCj4gZmluZSwgSU1PLg0K PiANCj4gPiAtIENvdWxkbid0IGEgYmFkIGFjdG9yIGluIGNvbnRyb2wgb2YgYW4gYXV0aG9yaXNl ZCBET1RTIGNsaWVudA0KPiA+IGNvbGx1ZGluZyB3aXRoIHRoZSBjb250cm9sbGVyIG9mIGEgRERv UyBhdHRhY2sgdXNlIHRoaXMgdG8gcHJvYmUgdGhlDQo+ID4gc3lzdGVtIHRvIHNlZSBob3cgdGhl aXIgYXR0YWNrIGlzIGdvaW5nIGFuZCBjaGFuZ2UgdGhlIGF0dGFjayB0byBiZQ0KPiA+IG1vcmUg ZWZmZWN0aXZlPw0KPiANCj4gW01lZF0gVGhlIGNsaWVudCB3aWxsIG9ubHkgc2VlIHRoZSByZXBv cnRzIGZvciBhdHRhY2tzIGl0IGRldGVjdGVkIGFuZCBzaWduYWxlZC4NCj4gVGhhdCBiYWQgYWN0 b3Igd29uJ3Qgc2lnbmFsIHRoZSBhdHRhY2sgaW4gdGhlIGZpcnN0IHBsYWNlIQ0KPiANCj4gICBJ IGRvbid0DQo+ID4gdGhpbmsgYW55IHByb3RvY29sIGNoYW5nZSBjb3VsZCBoZWxwIHRoZXJlLCBi dXQgcGVyaGFwcyB5b3UgY291bGQgZ2l2ZQ0KPiA+IHNvbWUgZ3VpZGFuY2UgdG8gaW1wbGVtZW50 ZXJzIHRvIHRyeSBjYXRjaCBzdWNoIGNhc2VzIChlLmcuLCBpZiB0aGUNCj4gPiBwcm9iaW5nIERP VFMgY2xpZW50J3MgbG9jYWwgbi93IGRvZXNuJ3QgYWN0dWFsbHkgYXBwZWFyIHRvIGJlIHVuZGVy DQo+ID4gYXR0YWNrKS4NCj4gPg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gRG90cyBtYWlsaW5nIGxpc3QNCj4gRG90c0BpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCg== From nobody Thu Mar 14 23:47:48 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 37AF7130E2F; Thu, 14 Mar 2019 23:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 TGevkOQFHN2O; Thu, 14 Mar 2019 23:47:30 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C768A127887; Thu, 14 Mar 2019 23:47:29 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 44LGNJ006bz8st3; Fri, 15 Mar 2019 07:47:27 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.98]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 44LGNH5sLtzCqkX; Fri, 15 Mar 2019 07:47:27 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7F.corporate.adroot.infra.ftgroup ([fe80::d9:d3cd:85bd:d331%21]) with mapi id 14.03.0439.000; Fri, 15 Mar 2019 07:47:27 +0100 From: To: Stephen Farrell , "secdir@ietf.org" CC: "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-dots-signal-channel-30 Thread-Index: AQHU2oSfRsTGH2X350i3IMDpwuRCCqYMOY8A Date: Fri, 15 Mar 2019 06:47:27 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA3E475@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <155257761487.2625.10003476313108979036@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA3DFC8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <72f7b85c-74fb-0f79-8211-50043c2b4b47@cs.tcd.ie> In-Reply-To: <72f7b85c-74fb-0f79-8211-50043c2b4b47@cs.tcd.ie> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dots-signal-channel-30 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, 15 Mar 2019 06:47:33 -0000 SGkgU3RlcGhlbiwgDQoNClBsZWFzZSBzZWUgaW5saW5lLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IFN0ZXBoZW4gRmFycmVsbCBbbWFp bHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWVdDQo+IEVudm95w6nCoDogamV1ZGkgMTQgbWFy cyAyMDE5IDE3OjQwDQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE47IHNlY2RpckBp ZXRmLm9yZw0KPiBDY8KgOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwuYWxsQGlldGYu b3JnOyBpZXRmQGlldGYub3JnOw0KPiBkb3RzQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBTZWNk aXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMzAN Cj4gDQo+IA0KPiBIaXlhLA0KPiANCj4gSnVzdCBvbiB0d28gYml0cyBiZWxvdy4uLg0KPiANCj4g SSdtIGhhcHB5IHRvIGNoYXQgbW9yZSBidXQgYWxzbyBmaW5lIHRoYXQgeW91IGFuZCB0aGUgQURz IGNhbg0KPiBzb3J0IHRoaXMgb3V0IGFjY29yZGluZyB0byBob3dldmVyIHRoZSBBRHMgc2VlIHRo aXMuDQo+IA0KPiBPbiAxNC8wMy8yMDE5IDE2OjE3LCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tIHdyb3RlOg0KPiANCj4gPj4gSSB0aGluayB0aGVyZSdzIG9uZSBpc3N1ZSB3aXRoIHRoaXMg ZHJhZnQgdGhhdCdkIGJlIHdlbGwgd29ydGgNCj4gPj4gZGlzY3Vzc2lvbiBhbmQvb3IgZml4aW5n Og0KPiA+Pg0KPiA+PiAtIHAxMjogV2h5IGRvZXMgdGhlIGN1aWQgbmVlZCB0byBiZSBzbyBzdGF0 aWM/IEkgd291bGQgaGF2ZSB0aG91Z2h0DQo+ID4+IHRoYXQgYW4gaWRlbnRpZmllciB0aGF0IGNh biBjaGFuZ2UgbW9yZSBvZnRlbiB0aGFuIGEga2V5IHBhaXIgd291bGQNCj4gPj4gaGF2ZSBiZWVu IGJldHRlciwgZXNwIGlmIHRoaXMgY291bGQgYmUgdXNlZCBpbiBhIENQRS4gKENyZWF0aW5nIGEN Cj4gPj4gbmV3IGxvbmctbGl2ZWQgaWRlbnRpZmllciBmb3IgYSBDUEUgc2VlbXMgbGlrZSBhIGJh ZCBwbGFuIGlmIGl0J3MNCj4gPj4gbm90IHJlYWxseSBuZWVkZWQuKSBGb3IgZXhhbXBsZSwgb25l IGNvdWxkIHVzZSBib3RoIHRoZSBTUEtJIGFuZCBhDQo+ID4+IHRpbWVzdGFtcCBhcyBpbnB1dCBm b3IgYSByZWNvbW1lbmRlZCB3YXkgdG8gZ2VuZXJhdGUgYSBjdWlkIGFuZA0KPiA+PiB0aGF0IHNo b3VsZCBiZSBhcyB1bmlxdWUsIGJ1dCBtdWNoIG1vcmUgZWFzaWx5IGNoYW5nZWQuICBUaGF0IGNv dWxkDQo+ID4+IGFsc28gbWl0aWdhdGUgdGhlIHBvc3NpYmxlIFRMUzEuMiBjbGllbnQtY2VydCBz bm9vcGluZyBpc3N1ZQ0KPiA+PiBtZW50aW9uZWQgb24gcDkwLg0KPiA+DQo+ID4gW01lZF0gY3Vp ZCBpcyB1c2VkIGZvciBhdm9pZGFuY2UgZGV0ZWN0aW9uIGJ1dCBhbHNvIGFzIGEgc3RhYmxlIGtl eQ0KPiA+IHRvIGlkZW50aWZ5IHJlc291cmNlcyBhdCB0aGUgc2VydmVyIHNpZGUuIEFueSBjaGFu Z2Ugb2YgdGhlIGN1aWQgd2lsbA0KPiA+IGxlYWQgdG8gYSBmYWlsdXJlIGluIGFjY2Vzc2luZyB0 aGUgcmVzb3VyY2VzLiBGdXJ0aGVybW9yZSwgdGhpcw0KPiA+IGlkZW50aWZpZXIgaXMgdXNlZCB0 byAiZ2x1ZSIgdGhlIHNpZ25hbCBhbmQgZGF0YSBjaGFubmVscy4NCj4gPg0KPiA+IFRoZSBzcGVj IGRvZXMgbm90IGZvcmJpZCB0aGUgY2xpZW50cyB0byBjaGFuZ2UgaXRzIGN1aWQsIGJ1dCB0byBk bw0KPiA+IHNvLCB0aGUgY2xpZW50IHdpbGwgbmVlZCB0byBtYW5hZ2Ugc3RhdGUgbWlncmF0aW9u Lg0KPiANCj4gWWVwLCBJIGdldCB0aGF0LiBCdXQgdGhlIGN1cnJlbnQgYWxnIHRoYXQncyBkZXNj cmliZWQgZm9yDQo+IGN1aWQgY2FsY3VsYXRpb24gaGFzIHRoZSBlZmZlY3Qgb2YgY3JlYXRpbmcg YW4gaWRlbnRpZmllcg0KPiB3aXRoIHRoZSBzYW1lIGxpZmV0aW1lIGFzIGEga2V5IHBhaXIuIEFz c3VtaW5nIGtleXMgYXJlDQo+IGhhcmRlciB0byBjaGFuZ2UgdGhhbiBjdWlkcyBpdCBzZWVtcyBi ZXR0ZXIgdG8gZW5jb3VyYWdlDQo+IGNsaWVudHMgdG8gbm90IG1ha2Ugc3VjaCBhIHRpZ2h0IGxp bmthZ2UgYmV0d2VlbiBjdWlkIGFuZA0KPiBrZXlzLCBlc3AuIGlmIHRoZSBjbGllbnQgaXMgb24g YSBDUEUuIChBbmQgaXQgYXZvaWRzIHRoZQ0KPiBUTFMxLjIgc25vb3BpbmcgaXNzdWUgYXMgbm90 ZWQuKQ0KPiANCj4gSSdkIGVuY291cmFnZSB5b3UgdG8gY29uc2lkZXIgbWF5YmUgc2F5aW5nIHNv bWUgbW9yZSBhYm91dA0KPiBob3cgY2xpZW50cyBjYW4gY2hhbmdlIGN1aWQsIGJ1dCBldmVuIGlm IG5vdCwgdG8gcHJvdmlkZQ0KPiBhIGN1aWQgY2FsY3VsYXRpb24gZXhhbXBsZSB0aGF0IGRvZXNu J3QgbGluayBvbmx5IHRvIHRoZQ0KPiBrZXkgcGFpci4NCg0KW01lZF0gVGhlIHRleHQgYWxyZWFk eSBjaXRlcyBSRkMgNDEyMiBhcyBhbiBhbHRlcm5hdGUgc2NoZW1lLiANCg0KV2lsbCBjb25zaWRl ciBob3cgdG8gZW5oYW5jZSB0aGUgdGV4dC4gVGhhbmtzLg0KDQo+IA0KPiA+PiAtIENvdWxkbid0 IGEgYmFkIGFjdG9yIGluIGNvbnRyb2wgb2YgYW4gYXV0aG9yaXNlZCBET1RTIGNsaWVudA0KPiA+ PiBjb2xsdWRpbmcgd2l0aCB0aGUgY29udHJvbGxlciBvZiBhIEREb1MgYXR0YWNrIHVzZSB0aGlz IHRvIHByb2JlDQo+ID4+IHRoZSBzeXN0ZW0gdG8gc2VlIGhvdyB0aGVpciBhdHRhY2sgaXMgZ29p bmcgYW5kIGNoYW5nZSB0aGUgYXR0YWNrDQo+ID4+IHRvIGJlIG1vcmUgZWZmZWN0aXZlPw0KPiA+ DQo+ID4gW01lZF0gVGhlIGNsaWVudCB3aWxsIG9ubHkgc2VlIHRoZSByZXBvcnRzIGZvciBhdHRh Y2tzIGl0IGRldGVjdGVkDQo+ID4gYW5kIHNpZ25hbGVkLiBUaGF0IGJhZCBhY3RvciB3b24ndCBz aWduYWwgdGhlIGF0dGFjayBpbiB0aGUgZmlyc3QNCj4gPiBwbGFjZSENCj4gDQo+IFBlcmhhcHMg SSB3YXNuJ3QgY2xlYXIuIElTVE0gdGhhdCBhbGwgY2xpZW50cyBjYW4gZ2V0IGluZm9ybWF0aW9u DQo+IGFib3V0IGhvdyBhbiBhdHRhY2sgaXMgYmVpbmcgc2VlbiBhdCBvdGhlciBjbGllbnRzLCBp c24ndCB0aGF0DQo+IHJpZ2h0PyANCg0KW01lZF0gTm8uIEEgY2xpZW50IGNhbiBvbmx5IGdldCBp bmZvcm1hdGlvbiB0aGF0IGlzIGJvdW5kIHRvIGl0LiANCg0KKFRoZSBzcGVjIGRvZXMgdGFsayBh Ym91dCB0aGF0IElJUkMuKSBUaGUgY29sbHVkaW5nIGNsaWVudA0KPiBtaWdodCBvciBtaWdodCBu b3QgYmUgdW5kZXIgYXR0YWNrIGJ1dCBub24tY29tcHJvbWlzZWQgY2xpZW50cyB3aWxsDQo+IHBy ZXN1bWFibHkgYXNrIGZvciB0aGUgYXR0YWNrIHRvIGJlIG1pdGlnYXRlZC4gU28gdGhlIGNvbGx1 ZGluZw0KPiBjbGllbnQgY291bGQgdXNlIHRoaXMgcHJvdG9jb2wgdG8gcHJvYmUgYW5kIHNlZSBo b3cgd2VsbCBvciBiYWRseQ0KPiB0aGUgRERvUy1taXRpZ2F0aW9uIGluZnJhc3RydWN0dXJlIGlz IGhhbmRsaW5nIGFuIG9uZ29pbmcgYXR0YWNrLg0KPiBJJ20gYmFzaWNhbGx5IHNheWluZyB0aGF0 IHRoYXQgbWF5IGJlIG5vdGV3b3J0aHkgYXMgYSBzZWN1cml0eQ0KPiBjb25zaWRlcmF0aW9uLg0K PiANCj4gQ2hlZXJzLA0KPiBTLg0KPiANCj4gDQo+ID4NCj4gPiBJIGRvbid0DQo+ID4+IHRoaW5r IGFueSBwcm90b2NvbCBjaGFuZ2UgY291bGQgaGVscCB0aGVyZSwgYnV0IHBlcmhhcHMgeW91IGNv dWxkDQo+ID4+IGdpdmUgc29tZSBndWlkYW5jZSB0byBpbXBsZW1lbnRlcnMgdG8gdHJ5IGNhdGNo IHN1Y2ggY2FzZXMgKGUuZy4sDQo+ID4+IGlmIHRoZSBwcm9iaW5nIERPVFMgY2xpZW50J3MgbG9j YWwgbi93IGRvZXNuJ3QgYWN0dWFsbHkgYXBwZWFyIHRvDQo+ID4+IGJlIHVuZGVyIGF0dGFjayku DQo+ID4+DQo+ID4NCg== From nobody Fri Mar 15 00:39:31 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 51E041311EC; Fri, 15 Mar 2019 00:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 XecqrQmYxhL0; Fri, 15 Mar 2019 00:39:26 -0700 (PDT) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEF6A12797C; Fri, 15 Mar 2019 00:39:25 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 44LHXD0996zCrqD; Fri, 15 Mar 2019 08:39:24 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.70]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 44LHXC5qlKzDq7S; Fri, 15 Mar 2019 08:39:23 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM33.corporate.adroot.infra.ftgroup ([fe80::c911:d24e:cc19:afa7%21]) with mapi id 14.03.0439.000; Fri, 15 Mar 2019 08:39:23 +0100 From: To: "Konda, Tirumaleswar Reddy" , "Stephen Farrell" , "secdir@ietf.org" CC: "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-dots-signal-channel-30 Thread-Index: AQHU2oF5RsTGH2X350i3IMDpwuRCCqYMGWiwgAA0gEA= Date: Fri, 15 Mar 2019 07:39:22 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA3E549@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <155257761487.2625.10003476313108979036@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA3DFC8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dots-signal-channel-30 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, 15 Mar 2019 07:39:28 -0000 SGkgVGlydSwgDQoNClBsZWFzZSBzZWUgaW5saW5lLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVk ZHkgW21haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tXQ0KPiBFbnZvecOp wqA6IHZlbmRyZWRpIDE1IG1hcnMgMjAxOSAwNTozMA0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1l ZCBUR0kvT0xOOyBTdGVwaGVuIEZhcnJlbGw7IHNlY2RpckBpZXRmLm9yZw0KPiBDY8KgOiBkcmFm dC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwuYWxsQGlldGYub3JnOyBpZXRmQGlldGYub3JnOw0K PiBkb3RzQGlldGYub3JnDQo+IE9iamV0wqA6IFJFOiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBv ZiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMzANCj4gDQo+IFBsZWFzZSBzZWUgaW5s aW5lDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogRG90cyA8 ZG90cy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YNCj4gPiBtb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tDQo+ID4gU2VudDogVGh1cnNkYXksIE1hcmNoIDE0LCAyMDE5IDk6NDcgUE0N Cj4gPiBUbzogU3RlcGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPjsgc2Vj ZGlyQGlldGYub3JnDQo+ID4gQ2M6IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC5hbGxA aWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7DQo+IGRvdHNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBS ZTogW0RvdHNdIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZG90cy1zaWdu YWwtDQo+IGNoYW5uZWwtMzANCj4gPg0KPiA+IFRoaXMgZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91 dHNpZGUgb2YgdGhlIG9yZ2FuaXphdGlvbi4gRG8gbm90IGNsaWNrIGxpbmtzDQo+IG9yDQo+ID4g b3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93 IHRoZSBjb250ZW50IGlzDQo+ID4gc2FmZS4NCj4gPg0KPiA+IEhpIFN0ZXBoZW4sDQo+ID4NCj4g PiBUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuDQo+ID4NCj4gPiBQbGVhc2Ugc2VlIGlubGluZS4N Cj4gPg0KPiA+IENoZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+ID4gLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tDQo+ID4gPiBEZcKgOiBTdGVwaGVuIEZhcnJlbGwgdmlhIERhdGF0cmFja2VyIFtt YWlsdG86bm9yZXBseUBpZXRmLm9yZ10gRW52b3nDqQ0KPiA+ID4gOiBqZXVkaSAxNCBtYXJzIDIw MTkgMTY6MzQgw4DCoDogc2VjZGlyQGlldGYub3JnIENjwqA6DQo+ID4gPiBkcmFmdC1pZXRmLWRv dHMtc2lnbmFsLWNoYW5uZWwuYWxsQGlldGYub3JnOyBpZXRmQGlldGYub3JnOw0KPiA+ID4gZG90 c0BpZXRmLm9yZyBPYmpldMKgOiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZg0KPiA+ID4gZHJh ZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLTMwDQo+ID4gPg0KPiA+ID4gUmV2aWV3ZXI6IFN0 ZXBoZW4gRmFycmVsbA0KPiA+ID4gUmV2aWV3IHJlc3VsdDogSGFzIElzc3Vlcw0KPiA+ID4NCj4g PiA+DQo+ID4gPiBJIHRoaW5rIHRoZXJlJ3Mgb25lIGlzc3VlIHdpdGggdGhpcyBkcmFmdCB0aGF0 J2QgYmUgd2VsbCB3b3J0aA0KPiA+ID4gZGlzY3Vzc2lvbiBhbmQvb3IgZml4aW5nOg0KPiA+ID4N Cj4gPiA+IC0gcDEyOiBXaHkgZG9lcyB0aGUgY3VpZCBuZWVkIHRvIGJlIHNvIHN0YXRpYz8gSSB3 b3VsZCBoYXZlIHRob3VnaHQNCj4gPiA+IHRoYXQgYW4gaWRlbnRpZmllciB0aGF0IGNhbiBjaGFu Z2UgbW9yZSBvZnRlbiB0aGFuIGEga2V5IHBhaXIgd291bGQNCj4gPiA+IGhhdmUgYmVlbiBiZXR0 ZXIsIGVzcCBpZiB0aGlzIGNvdWxkIGJlIHVzZWQgaW4gYSBDUEUuIChDcmVhdGluZyBhIG5ldw0K PiA+ID4gbG9uZy1saXZlZCBpZGVudGlmaWVyIGZvciBhIENQRSBzZWVtcyBsaWtlIGEgYmFkIHBs YW4gaWYgaXQncyBub3QNCj4gPiA+IHJlYWxseSBuZWVkZWQuKSBGb3IgZXhhbXBsZSwgb25lIGNv dWxkIHVzZSBib3RoIHRoZSBTUEtJIGFuZCBhDQo+ID4gPiB0aW1lc3RhbXAgYXMgaW5wdXQgZm9y IGEgcmVjb21tZW5kZWQgd2F5IHRvIGdlbmVyYXRlIGEgY3VpZCBhbmQgdGhhdA0KPiA+ID4gc2hv dWxkIGJlIGFzIHVuaXF1ZSwgYnV0IG11Y2ggbW9yZSBlYXNpbHkgY2hhbmdlZC4gIFRoYXQgY291 bGQgYWxzbw0KPiA+ID4gbWl0aWdhdGUgdGhlIHBvc3NpYmxlIFRMUzEuMiBjbGllbnQtY2VydCBz bm9vcGluZyBpc3N1ZSBtZW50aW9uZWQgb24NCj4gPiA+IHA5MC4NCj4gPg0KPiA+IFtNZWRdIGN1 aWQgaXMgdXNlZCBmb3IgYXZvaWRhbmNlIGRldGVjdGlvbiBidXQgYWxzbyBhcyBhIHN0YWJsZSBr ZXkgdG8NCj4gPiBpZGVudGlmeSByZXNvdXJjZXMgYXQgdGhlIHNlcnZlciBzaWRlLiBBbnkgY2hh bmdlIG9mIHRoZSBjdWlkIHdpbGwgbGVhZCB0bw0KPiBhDQo+ID4gZmFpbHVyZSBpbiBhY2Nlc3Np bmcgdGhlIHJlc291cmNlcy4NCj4gPiBGdXJ0aGVybW9yZSwgdGhpcyBpZGVudGlmaWVyIGlzIHVz ZWQgdG8gImdsdWUiIHRoZSBzaWduYWwgYW5kIGRhdGENCj4gY2hhbm5lbHMuDQo+ID4NCj4gPiBU aGUgc3BlYyBkb2VzIG5vdCBmb3JiaWQgdGhlIGNsaWVudHMgdG8gY2hhbmdlIGl0cyBjdWlkLCBi dXQgdG8gZG8gc28sIHRoZQ0KPiA+IGNsaWVudCB3aWxsIG5lZWQgdG8gbWFuYWdlIHN0YXRlIG1p Z3JhdGlvbi4NCj4gPg0KPiA+ID4NCj4gPiA+IG5pdHM6DQo+ID4gPg0KPiA+ID4gLSAoTm90IHJl YWxseSBhIG5pdCwgYnV0IHByb2JhYmx5IHRvbyBtdWNoIHRvIGFzaywgc28uLi4pIFRoZSBwcm90 b2NvbA0KPiA+ID4gaGVyZSBzZWVtcyB2ZXJ5IGNvbXBsZXguIEhhcyBhbnlvbmUgdHJpZWQgdG8g cHJvdmUgYW55dGhpbmcgYWJvdXQgdGhlDQo+ID4gPiBzdGF0ZSBtYWNoaW5lLCBlLmcuDQo+ID4g PiB0aGF0J3MgaXQncyBzYWZlIGluIHNvbWUgc2Vuc2VzPyBJdCdkIGJlIGZhaXIgdG8gc2F5IHRo YXQgdGhhdCBpcyBhDQo+ID4gPiBnb29kIHRhc2sgdG8gZG8gYWZ0ZXIgdGhlIGluaXRpYWwgUkZD IGlzIHB1Ymxpc2hlZCBpbiB0aGlzIGNhc2UsIEkNCj4gPiA+IGd1ZXNzLiAgT1RPSCwgY291bGQg YmUgc29tZSBvZiB0aGUgdGhlb3JlbS1wcm92aW5nIHRvb2xzIHVzZWQgaW4gdGhlDQo+ID4gPiBk ZXZlbG9wbWVudCBvZg0KPiA+ID4gVExTMS4zIGNvdWxkIGJlIHVzZWZ1bCBoZXJlLiAoQW5kIHRo b3NlIHRvb2xzIHVzdWFsbHkgZG8gdHVybiB1cCBzb21lDQo+ID4gPiBpc3N1ZXMgd29ydGggZml4 aW5nIC0gSSdkIGJldCBhIGJlZXIgdGhleSB3b3VsZCBpbiB0aGlzIGNhc2U6LSkNCj4gPg0KPiA+ IFtNZWRdIFRoZSBzcGVjaWZpY2F0aW9uIHdhcyBlZGl0ZWQgZm9sbG93aW5nIGFuIGluY3JlbWVu dGFsIGFwcHJvYWNoIGluDQo+ID4gd2hpY2ggbmV3IHBpZWNlcyBhcmUgdmFsaWRhdGVkIHRocm91 Z2ggYXQgbGVhc3QgdHdvIGludGVyb3BlcmFibGUNCj4gPiBpbXBsZW1lbnRhdGlvbnMuIFdlIGhv cGUgdGhhdCBtb3JlIGZlZWRiYWNrIHdpbGwgYmUgcmVjZWl2ZWQgYWZ0ZXIgdGhlDQo+ID4gaW5p dGlhbCBSRkMuDQo+ID4NCj4gPiA+DQo+ID4gPiAtIHAxODogIk9ubHkgc2luZ2xlLXZhbHVlZCAn Y2RpZCcgYXJlIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4iIFRoYXQNCj4gPiA+IGNvbmZ1c2Vk IG1lIGdpdmVuIHRoZSB0ZXh0IDMgcGFyYXMgYmVmb3JlIGFib3V0IG11bHRpcGxlIGNkaWQgdmFs dWVzLg0KPiA+ID4gTWF5YmUgY2xhcmlmeWluZyB0aGF0IHNvbWUgY291bGQgYmUgdXNlZnVsPw0K PiA+DQo+ID4gW01lZF0gV2hhdCBpcyBtZWFudCBoZXJlIGlzIHRoZSBjYXNlIHdoZXJlIG11bHRp cGxlIEdXcyBhcmUgaW52b2x2ZWQgaW4NCj4gPiB0aGUgcGF0aDsgZWFjaCBpbnNlcnRzIGEgY2Rp ZCB2YWx1ZS4NCj4gDQo+ICdjZGlkJyBpcyBvbmx5IGluc2VydGVkIGJ5IHRoZSBzZXJ2ZXItZG9t YWluIERPVFMgZ2F0ZXdheS4NCg0KW01lZF0gSSBhZGRlZCB0aGlzIE5FVyB0ZXh0IHRvIGNsYXJp ZnkgdGhlIGNvbW1lbnQgZnJvbSBTdGVwaGVuOg0KDQpPTEQ6DQogICAgICBPbmx5IHNpbmdsZS12 YWx1ZWQgJ2NkaWQnIGFyZSBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuICANCg0KTkVXOg0KICAg ICAgT25seSBzaW5nbGUtdmFsdWVkICdjZGlkJyBhcmUgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50 LiAgVGhhdCBpcywNCiAgICAgIG9ubHkgdGhlIGZpcnN0IHNlcnZlci1kb21haW4gRE9UUyBnYXRl d2F5IGNhbiBpbnNlcnQgYSAnY2RpZCcNCiAgICAgIHZhbHVlLiAgVGhpcyBzcGVjaWZpY2F0aW9u IGRvZXMgbm90IGFsbG93IG11bHRpcGxlIHNlcnZlci1kb21haW4NCiAgICAgIERPVFMgZ2F0ZXdh eXMsIHdoZW5ldmVyIGludm9sdmVkIGluIHRoZSBwYXRoLCB0byBpbnNlcnQgYSAnY2RpZCcNCiAg ICAgIHZhbHVlIGZvciBlYWNoLg0KDQogRmlndXJlIDggbmVlZHMgdG8NCj4gYmUgY29ycmVjdGVk LCAnY3VpZCcgaXMgbWlzc2luZyBpbiB0aGUgRmlndXJlLg0KDQpbTWVkXSBGaWd1cmUgOCBpcyBj b3JyZWN0LiANCg== From nobody Fri Mar 15 01:35: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 12AED12D4F3; Fri, 15 Mar 2019 01:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, 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=mcafee.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 pWNcTUMyd1pX; Fri, 15 Mar 2019 01:35:27 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 97FB7128709; Fri, 15 Mar 2019 01:35:26 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1552638715; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=zGd7AVK9rW/VyA8cngVGkySTTJx3I53XcT5T+B PLra4=; b=QdKYMx74VaPLYmRxqG/ff4+5x5LQdBCR0PtaFKNX biOdQ/v+LH8eIrkrkxjJxDNpFJ7yBxUPGADwjM81GOJQO+frNB OguHpjj/4slMWgGF8DXHwkFOvP4BdK5U0dVoH4sgT2dQSzT/k5 K1Pnv8aUt44F6VLeB94JRjvEK5gdBnA= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 3ffc_422d_3a2559ae_f791_4b5a_bcf1_d6c72b593f1d; Fri, 15 Mar 2019 02:31:54 -0600 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 15 Mar 2019 02:35:16 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 15 Mar 2019 02:35:16 -0600 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 15 Mar 2019 02:35:16 -0600 Received: from DM6PR16MB2794.namprd16.prod.outlook.com (20.178.225.219) by DM6PR16MB3050.namprd16.prod.outlook.com (10.255.61.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.13; Fri, 15 Mar 2019 08:35:13 +0000 Received: from DM6PR16MB2794.namprd16.prod.outlook.com ([fe80::a948:401e:299e:4550]) by DM6PR16MB2794.namprd16.prod.outlook.com ([fe80::a948:401e:299e:4550%6]) with mapi id 15.20.1686.021; Fri, 15 Mar 2019 08:35:13 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "Stephen Farrell" , "secdir@ietf.org" CC: "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-dots-signal-channel-30 Thread-Index: AQHU2oF5bx6+d1T5QkC+CtJqzs0JZ6YMGWiwgAA1/gCAAA6ycA== Date: Fri, 15 Mar 2019 08:35:13 +0000 Message-ID: References: <155257761487.2625.10003476313108979036@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA3DFC8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA3E549@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA3E549@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4b749e58-13fb-4983-5165-08d6a9212504 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:DM6PR16MB3050; x-ms-traffictypediagnostic: DM6PR16MB3050: x-microsoft-antispam-prvs: x-forefront-prvs: 09778E995A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(366004)(376002)(346002)(136003)(32952001)(13464003)(189003)(199004)(8676002)(9686003)(6116002)(110136005)(6246003)(229853002)(11346002)(446003)(33656002)(106356001)(99286004)(52536014)(71200400001)(256004)(476003)(105586002)(5024004)(14444005)(55016002)(486006)(71190400001)(66066001)(5660300002)(7696005)(86362001)(72206003)(53546011)(6436002)(316002)(93886005)(8936002)(25786009)(4326008)(305945005)(76176011)(7736002)(6506007)(26005)(3846002)(2501003)(2906002)(478600001)(74316002)(81156014)(81166006)(68736007)(54906003)(102836004)(186003)(14454004)(53936002)(80792005)(97736004)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR16MB3050; H:DM6PR16MB2794.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: PCxjd7UxPj5vT3WQEJDFhMVxEgPQtugjuLcPyU0vbwZHtAQx17ZHWMm0XXenD5xbHFYJBGxplgy8Q6kM8zpMh2oP3bVqiyIBDEVEwHUL4JcbnjrOnV5MiS7txtEodsMCo/Vm/+WStguu6pFTjbBS/zXoZhktjhhJEPGDaUB9Wl3wNlKG+jZlB++wlI+PBNfxJ1LTAAxTuPeVQlj7ybysZ4662+fV9RfxTkg+OxevpEC5Cxe4HmllpfBC0zV/kzUSnjugwPLoIOZb/aROIU7e5w/R7Kp2Qj2jIUNWGv2dafRt38FVj+oeK817NFiYtfGgz5tfcKSxNL4CyWUKjkmyz9uWVf6eieA8NHS+eo5d+hIWxJ1g64oVigtrjQGZZlrI806DlmNtVRPbshJHtRyWzd/+p/oaYhMMmPOFdh8NQ0E= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4b749e58-13fb-4983-5165-08d6a9212504 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2019 08:35:13.8467 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR16MB3050 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6503> : inlines <7034> : streams <1815760> : uri <2813108> Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dots-signal-channel-30 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, 15 Mar 2019 08:35:30 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPiBTZW50OiBGcmlkYXks IE1hcmNoIDE1LCAyMDE5IDE6MDkgUE0NCj4gVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkg PFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+Ow0KPiBTdGVwaGVuIEZhcnJlbGwg PHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+OyBzZWNkaXJAaWV0Zi5vcmcNCj4gQ2M6IGRyYWZ0 LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC5hbGxAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IGRv dHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRy YWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC0zMA0KPiANCj4gVGhpcyBlbWFpbCBvcmlnaW5h dGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mg b3INCj4gb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFu ZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQo+IA0KPiBIaSBUaXJ1LA0KPiANCj4gUGxlYXNl IHNlZSBpbmxpbmUuDQo+IA0KPiBDaGVlcnMsDQo+IE1lZA0KPiANCj4gPiAtLS0tLU1lc3NhZ2Ug ZCdvcmlnaW5lLS0tLS0NCj4gPiBEZcKgOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQo+ID4g W21haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tXQ0KPiA+IEVudm95w6nC oDogdmVuZHJlZGkgMTUgbWFycyAyMDE5IDA1OjMwDQo+ID4gw4DCoDogQk9VQ0FEQUlSIE1vaGFt ZWQgVEdJL09MTjsgU3RlcGhlbiBGYXJyZWxsOyBzZWNkaXJAaWV0Zi5vcmcgQ2PCoDoNCj4gPiBk cmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwuYWxsQGlldGYub3JnOyBpZXRmQGlldGYub3Jn Ow0KPiA+IGRvdHNAaWV0Zi5vcmcgT2JqZXTCoDogUkU6IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3 IG9mDQo+ID4gZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLTMwDQo+ID4NCj4gPiBQbGVh c2Ugc2VlIGlubGluZQ0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ ID4gRnJvbTogRG90cyA8ZG90cy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YNCj4gPiA+ IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gPiA+IFNlbnQ6IFRodXJzZGF5LCBNYXJj aCAxNCwgMjAxOSA5OjQ3IFBNDQo+ID4gPiBUbzogU3RlcGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZh cnJlbGxAY3MudGNkLmllPjsgc2VjZGlyQGlldGYub3JnDQo+ID4gPiBDYzogZHJhZnQtaWV0Zi1k b3RzLXNpZ25hbC1jaGFubmVsLmFsbEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsNCj4gPiBkb3Rz QGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW0RvdHNdIFNlY2RpciBsYXN0IGNhbGwgcmV2 aWV3IG9mDQo+ID4gPiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLQ0KPiA+IGNoYW5uZWwtMzANCj4g PiA+DQo+ID4gPiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdh bml6YXRpb24uIERvIG5vdCBjbGljaw0KPiA+ID4gbGlua3MNCj4gPiBvcg0KPiA+ID4gb3BlbiBh dHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZQ0K PiA+ID4gY29udGVudCBpcyBzYWZlLg0KPiA+ID4NCj4gPiA+IEhpIFN0ZXBoZW4sDQo+ID4gPg0K PiA+ID4gVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3Lg0KPiA+ID4NCj4gPiA+IFBsZWFzZSBzZWUg aW5saW5lLg0KPiA+ID4NCj4gPiA+IENoZWVycywNCj4gPiA+IE1lZA0KPiA+ID4NCj4gPiA+ID4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gPiA+IERlwqA6IFN0ZXBoZW4gRmFycmVs bCB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5QGlldGYub3JnXQ0KPiA+ID4gPiBFbnZv ecOpDQo+ID4gPiA+IDogamV1ZGkgMTQgbWFycyAyMDE5IDE2OjM0IMOAwqA6IHNlY2RpckBpZXRm Lm9yZyBDY8KgOg0KPiA+ID4gPiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwuYWxsQGll dGYub3JnOyBpZXRmQGlldGYub3JnOw0KPiA+ID4gPiBkb3RzQGlldGYub3JnIE9iamV0wqA6IFNl Y2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mDQo+ID4gPiA+IGRyYWZ0LWlldGYtZG90cy1zaWduYWwt Y2hhbm5lbC0zMA0KPiA+ID4gPg0KPiA+ID4gPiBSZXZpZXdlcjogU3RlcGhlbiBGYXJyZWxsDQo+ ID4gPiA+IFJldmlldyByZXN1bHQ6IEhhcyBJc3N1ZXMNCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ ID4gSSB0aGluayB0aGVyZSdzIG9uZSBpc3N1ZSB3aXRoIHRoaXMgZHJhZnQgdGhhdCdkIGJlIHdl bGwgd29ydGgNCj4gPiA+ID4gZGlzY3Vzc2lvbiBhbmQvb3IgZml4aW5nOg0KPiA+ID4gPg0KPiA+ ID4gPiAtIHAxMjogV2h5IGRvZXMgdGhlIGN1aWQgbmVlZCB0byBiZSBzbyBzdGF0aWM/IEkgd291 bGQgaGF2ZQ0KPiA+ID4gPiB0aG91Z2h0IHRoYXQgYW4gaWRlbnRpZmllciB0aGF0IGNhbiBjaGFu Z2UgbW9yZSBvZnRlbiB0aGFuIGEga2V5DQo+ID4gPiA+IHBhaXIgd291bGQgaGF2ZSBiZWVuIGJl dHRlciwgZXNwIGlmIHRoaXMgY291bGQgYmUgdXNlZCBpbiBhIENQRS4NCj4gPiA+ID4gKENyZWF0 aW5nIGEgbmV3IGxvbmctbGl2ZWQgaWRlbnRpZmllciBmb3IgYSBDUEUgc2VlbXMgbGlrZSBhIGJh ZA0KPiA+ID4gPiBwbGFuIGlmIGl0J3Mgbm90IHJlYWxseSBuZWVkZWQuKSBGb3IgZXhhbXBsZSwg b25lIGNvdWxkIHVzZSBib3RoDQo+ID4gPiA+IHRoZSBTUEtJIGFuZCBhIHRpbWVzdGFtcCBhcyBp bnB1dCBmb3IgYSByZWNvbW1lbmRlZCB3YXkgdG8NCj4gPiA+ID4gZ2VuZXJhdGUgYSBjdWlkIGFu ZCB0aGF0IHNob3VsZCBiZSBhcyB1bmlxdWUsIGJ1dCBtdWNoIG1vcmUgZWFzaWx5DQo+ID4gPiA+ IGNoYW5nZWQuICBUaGF0IGNvdWxkIGFsc28gbWl0aWdhdGUgdGhlIHBvc3NpYmxlIFRMUzEuMiBj bGllbnQtY2VydA0KPiA+ID4gPiBzbm9vcGluZyBpc3N1ZSBtZW50aW9uZWQgb24gcDkwLg0KPiA+ ID4NCj4gPiA+IFtNZWRdIGN1aWQgaXMgdXNlZCBmb3IgYXZvaWRhbmNlIGRldGVjdGlvbiBidXQg YWxzbyBhcyBhIHN0YWJsZSBrZXkNCj4gPiA+IHRvIGlkZW50aWZ5IHJlc291cmNlcyBhdCB0aGUg c2VydmVyIHNpZGUuIEFueSBjaGFuZ2Ugb2YgdGhlIGN1aWQNCj4gPiA+IHdpbGwgbGVhZCB0bw0K PiA+IGENCj4gPiA+IGZhaWx1cmUgaW4gYWNjZXNzaW5nIHRoZSByZXNvdXJjZXMuDQo+ID4gPiBG dXJ0aGVybW9yZSwgdGhpcyBpZGVudGlmaWVyIGlzIHVzZWQgdG8gImdsdWUiIHRoZSBzaWduYWwg YW5kIGRhdGENCj4gPiBjaGFubmVscy4NCj4gPiA+DQo+ID4gPiBUaGUgc3BlYyBkb2VzIG5vdCBm b3JiaWQgdGhlIGNsaWVudHMgdG8gY2hhbmdlIGl0cyBjdWlkLCBidXQgdG8gZG8NCj4gPiA+IHNv LCB0aGUgY2xpZW50IHdpbGwgbmVlZCB0byBtYW5hZ2Ugc3RhdGUgbWlncmF0aW9uLg0KPiA+ID4N Cj4gPiA+ID4NCj4gPiA+ID4gbml0czoNCj4gPiA+ID4NCj4gPiA+ID4gLSAoTm90IHJlYWxseSBh IG5pdCwgYnV0IHByb2JhYmx5IHRvbyBtdWNoIHRvIGFzaywgc28uLi4pIFRoZQ0KPiA+ID4gPiBw cm90b2NvbCBoZXJlIHNlZW1zIHZlcnkgY29tcGxleC4gSGFzIGFueW9uZSB0cmllZCB0byBwcm92 ZQ0KPiA+ID4gPiBhbnl0aGluZyBhYm91dCB0aGUgc3RhdGUgbWFjaGluZSwgZS5nLg0KPiA+ID4g PiB0aGF0J3MgaXQncyBzYWZlIGluIHNvbWUgc2Vuc2VzPyBJdCdkIGJlIGZhaXIgdG8gc2F5IHRo YXQgdGhhdCBpcw0KPiA+ID4gPiBhIGdvb2QgdGFzayB0byBkbyBhZnRlciB0aGUgaW5pdGlhbCBS RkMgaXMgcHVibGlzaGVkIGluIHRoaXMgY2FzZSwNCj4gPiA+ID4gSSBndWVzcy4gIE9UT0gsIGNv dWxkIGJlIHNvbWUgb2YgdGhlIHRoZW9yZW0tcHJvdmluZyB0b29scyB1c2VkIGluDQo+ID4gPiA+ IHRoZSBkZXZlbG9wbWVudCBvZg0KPiA+ID4gPiBUTFMxLjMgY291bGQgYmUgdXNlZnVsIGhlcmUu IChBbmQgdGhvc2UgdG9vbHMgdXN1YWxseSBkbyB0dXJuIHVwDQo+ID4gPiA+IHNvbWUgaXNzdWVz IHdvcnRoIGZpeGluZyAtIEknZCBiZXQgYSBiZWVyIHRoZXkgd291bGQgaW4gdGhpcw0KPiA+ID4g PiBjYXNlOi0pDQo+ID4gPg0KPiA+ID4gW01lZF0gVGhlIHNwZWNpZmljYXRpb24gd2FzIGVkaXRl ZCBmb2xsb3dpbmcgYW4gaW5jcmVtZW50YWwgYXBwcm9hY2gNCj4gPiA+IGluIHdoaWNoIG5ldyBw aWVjZXMgYXJlIHZhbGlkYXRlZCB0aHJvdWdoIGF0IGxlYXN0IHR3byBpbnRlcm9wZXJhYmxlDQo+ ID4gPiBpbXBsZW1lbnRhdGlvbnMuIFdlIGhvcGUgdGhhdCBtb3JlIGZlZWRiYWNrIHdpbGwgYmUg cmVjZWl2ZWQgYWZ0ZXINCj4gPiA+IHRoZSBpbml0aWFsIFJGQy4NCj4gPiA+DQo+ID4gPiA+DQo+ ID4gPiA+IC0gcDE4OiAiT25seSBzaW5nbGUtdmFsdWVkICdjZGlkJyBhcmUgZGVmaW5lZCBpbiB0 aGlzIGRvY3VtZW50LiINCj4gPiA+ID4gVGhhdCBjb25mdXNlZCBtZSBnaXZlbiB0aGUgdGV4dCAz IHBhcmFzIGJlZm9yZSBhYm91dCBtdWx0aXBsZSBjZGlkIHZhbHVlcy4NCj4gPiA+ID4gTWF5YmUg Y2xhcmlmeWluZyB0aGF0IHNvbWUgY291bGQgYmUgdXNlZnVsPw0KPiA+ID4NCj4gPiA+IFtNZWRd IFdoYXQgaXMgbWVhbnQgaGVyZSBpcyB0aGUgY2FzZSB3aGVyZSBtdWx0aXBsZSBHV3MgYXJlIGlu dm9sdmVkDQo+ID4gPiBpbiB0aGUgcGF0aDsgZWFjaCBpbnNlcnRzIGEgY2RpZCB2YWx1ZS4NCj4g Pg0KPiA+ICdjZGlkJyBpcyBvbmx5IGluc2VydGVkIGJ5IHRoZSBzZXJ2ZXItZG9tYWluIERPVFMg Z2F0ZXdheS4NCj4gDQo+IFtNZWRdIEkgYWRkZWQgdGhpcyBORVcgdGV4dCB0byBjbGFyaWZ5IHRo ZSBjb21tZW50IGZyb20gU3RlcGhlbjoNCj4gDQo+IE9MRDoNCj4gICAgICAgT25seSBzaW5nbGUt dmFsdWVkICdjZGlkJyBhcmUgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50Lg0KPiANCj4gTkVXOg0K PiAgICAgICBPbmx5IHNpbmdsZS12YWx1ZWQgJ2NkaWQnIGFyZSBkZWZpbmVkIGluIHRoaXMgZG9j dW1lbnQuICBUaGF0IGlzLA0KPiAgICAgICBvbmx5IHRoZSBmaXJzdCBzZXJ2ZXItZG9tYWluIERP VFMgZ2F0ZXdheSBjYW4gaW5zZXJ0IGEgJ2NkaWQnDQoNClJlcGxhY2UgIm9ubHkgdGhlIGZpcnN0 IHNlcnZlci1kb21haW4iIHdpdGggIm9ubHkgdGhlIGZpcnN0IG9uLXBhdGggc2VydmVyLWRvbWFp biINCg0KPiAgICAgICB2YWx1ZS4gIFRoaXMgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBhbGxvdyBt dWx0aXBsZSBzZXJ2ZXItZG9tYWluDQo+ICAgICAgIERPVFMgZ2F0ZXdheXMsIHdoZW5ldmVyIGlu dm9sdmVkIGluIHRoZSBwYXRoLCB0byBpbnNlcnQgYSAnY2RpZCcNCj4gICAgICAgdmFsdWUgZm9y IGVhY2guDQoNCkxvb2tzIGdvb2QuIA0KDQo+IA0KPiAgRmlndXJlIDggbmVlZHMgdG8NCj4gPiBi ZSBjb3JyZWN0ZWQsICdjdWlkJyBpcyBtaXNzaW5nIGluIHRoZSBGaWd1cmUuDQo+IA0KPiBbTWVk XSBGaWd1cmUgOCBpcyBjb3JyZWN0Lg0KDQpZZXMuDQoNCkNoZWVycywNCi1UaXJ1DQoNCg== From nobody Fri Mar 15 03:29: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 984551277C9; Fri, 15 Mar 2019 03:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUodBhYFw0r8; Fri, 15 Mar 2019 03:29:24 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E68EB1200D7; Fri, 15 Mar 2019 03:29:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A211DBE64; Fri, 15 Mar 2019 10:19:49 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsXkTRnQGmJa; Fri, 15 Mar 2019 10:19:48 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1E0F3BE2F; Fri, 15 Mar 2019 10:19:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1552645188; bh=4DUlrRQj+1I2OoaidU2MFIEgnj3HAQIXJTaS/t6Drkc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=WQHN2V+e1/hgT0Cr52CvO3wGCt0puwkfLMscHIE/oxZd25F6FYH1s+JInFYcmlpMs jbCH2Nyg22HZqCDNm1bg+JDbVIOkIeJNhd9L+Qp26R3QlPQB34P4Ji1hvfgl+M4q5M nGD+4OsImn+CpEU8SnO+YfTN9cUoMNsq0Rwn2wnk= To: mohamed.boucadair@orange.com, "secdir@ietf.org" Cc: "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" References: <155257761487.2625.10003476313108979036@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA3DFC8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <72f7b85c-74fb-0f79-8211-50043c2b4b47@cs.tcd.ie> <787AE7BB302AE849A7480A190F8B93302EA3E475@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Fri, 15 Mar 2019 10:19:46 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA3E475@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OcXCoFKm9TVvJwrQcAxLmBzpu94tZct4D" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dots-signal-channel-30 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, 15 Mar 2019 10:29:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OcXCoFKm9TVvJwrQcAxLmBzpu94tZct4D Content-Type: multipart/mixed; boundary="w4Cg8akEmAm3Zicc3wDePsYhvnIVJuOtr"; protected-headers="v1" From: Stephen Farrell To: mohamed.boucadair@orange.com, "secdir@ietf.org" Cc: "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" Message-ID: Subject: Re: Secdir last call review of draft-ietf-dots-signal-channel-30 References: <155257761487.2625.10003476313108979036@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA3DFC8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <72f7b85c-74fb-0f79-8211-50043c2b4b47@cs.tcd.ie> <787AE7BB302AE849A7480A190F8B93302EA3E475@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA3E475@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> --w4Cg8akEmAm3Zicc3wDePsYhvnIVJuOtr Content-Type: multipart/mixed; boundary="------------52064FC41B35FBE73FC71E2E" Content-Language: en-GB This is a multi-part message in MIME format. --------------52064FC41B35FBE73FC71E2E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 15/03/2019 06:47, mohamed.boucadair@orange.com wrote: >> ISTM that all clients can get information >> about how an attack is being seen at other clients, isn't that >> right?=20 > [Med] No. A client can only get information that is bound to it.=20 Where does the spec say that? I don't recall the term "bound" used that way but may have missed it. And it still seems a bit hard to enforce. If two clients (one ok, one zombied) ask the same server/network how many packets targetted at 10.0.0/24 were dropped won't they get the same answer? (Assuming both clients are within that /24.) Thanks, S. --------------52064FC41B35FBE73FC71E2E Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------52064FC41B35FBE73FC71E2E-- --w4Cg8akEmAm3Zicc3wDePsYhvnIVJuOtr-- --OcXCoFKm9TVvJwrQcAxLmBzpu94tZct4D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyLfEIACgkQWrL68XsX K+r/FxAAr9nEmQuO54XF2fu7iMzZ6zJ5kXaic9EbXd3K2CD8UJLSaKC8ObhTDXFP 0bs+N+icYf7Hgol1Qj0U75K8UXZp7lbOrlKoaMsOJPgwGinVIQBVpPCsVX3acy0S CvUn1LsKsg+vyb40ftJapPUKZNN22quejctUQePT9LUuh17Zfqfgns2RoWQ8ZEDN WxO1djBZuqanSPmX4nn/0fT857fiUKVYBHeZAqR8ohAxbUDrpKgISVQvMvVqCSwz rrXSBjQkzCRoAjQZ6KR9lHwCylJG/3T6+SSFXPN7xdUv7letpcIEFk+eZKD4UJRB P3uDuu6mb5XXSiNzu61yezEZFbxfHYv0pM6spAyK+LXQpUtEG05h3mwZek6Dgkjf iEixRVXtBOg5dPDtGDXxaZB1M3KDLJW0ORCPXw026q3sHNQ1pmY0rN9IF1Zw7s3x tVFM6lFgnP7PQQVNNVktxNkLkcMNbNfHw8H1CLvrsc5CgctGUW+GhVXZqy9YvEQ4 f1fcJ1RNmkCE2V66zriNjC5oQwd/KkWrSxh8w5IeJyyolhkiD6l6iYLpwWjUGxN/ jphcwHkb8vdI3pelqASKATe7o7acP9At0weI2YCcGnHfkup3sFyczDCjL/j0JQcY qMX/IJrz2CtB9dkrXTGwNPPJxLIxUnAxPehgy0C4YmyWSwLPQ18= =syOD -----END PGP SIGNATURE----- --OcXCoFKm9TVvJwrQcAxLmBzpu94tZct4D-- From nobody Fri Mar 15 03:45: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 59301127887; Fri, 15 Mar 2019 03:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 gihtNhkiCtWD; Fri, 15 Mar 2019 03:45:16 -0700 (PDT) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A7312423B; Fri, 15 Mar 2019 03:45:16 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 44LMfd6VSJzym8; Fri, 15 Mar 2019 11:45:13 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 44LMfd5jwkzDq7T; Fri, 15 Mar 2019 11:45:13 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM42.corporate.adroot.infra.ftgroup ([fe80::1c8e:403e:fbea:5835%21]) with mapi id 14.03.0439.000; Fri, 15 Mar 2019 11:45:13 +0100 From: To: Stephen Farrell , "secdir@ietf.org" CC: "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-dots-signal-channel-30 Thread-Index: AQHU2xicRsTGH2X350i3IMDpwuRCCqYMe/AA Date: Fri, 15 Mar 2019 10:45:12 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA3E6E1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <155257761487.2625.10003476313108979036@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA3DFC8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <72f7b85c-74fb-0f79-8211-50043c2b4b47@cs.tcd.ie> <787AE7BB302AE849A7480A190F8B93302EA3E475@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dots-signal-channel-30 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, 15 Mar 2019 10:45:18 -0000 UmUtLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVz c2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBTdGVwaGVuIEZhcnJlbGwgW21haWx0bzpzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllXQ0KPiBFbnZvecOpwqA6IHZlbmRyZWRpIDE1IG1hcnMgMjAx OSAxMToyMA0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOOyBzZWNkaXJAaWV0Zi5v cmcNCj4gQ2PCoDogZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLmFsbEBpZXRmLm9yZzsg aWV0ZkBpZXRmLm9yZzsNCj4gZG90c0BpZXRmLm9yZw0KPiBPYmpldMKgOiBSZTogU2VjZGlyIGxh c3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLTMwDQo+IA0K PiANCj4gSGl5YSwNCj4gDQo+IE9uIDE1LzAzLzIwMTkgMDY6NDcsIG1vaGFtZWQuYm91Y2FkYWly QG9yYW5nZS5jb20gd3JvdGU6DQo+ID4+IElTVE0gdGhhdCBhbGwgY2xpZW50cyBjYW4gZ2V0IGlu Zm9ybWF0aW9uDQo+ID4+IGFib3V0IGhvdyBhbiBhdHRhY2sgaXMgYmVpbmcgc2VlbiBhdCBvdGhl ciBjbGllbnRzLCBpc24ndCB0aGF0DQo+ID4+IHJpZ2h0Pw0KPiA+IFtNZWRdIE5vLiBBIGNsaWVu dCBjYW4gb25seSBnZXQgaW5mb3JtYXRpb24gdGhhdCBpcyBib3VuZCB0byBpdC4NCj4gV2hlcmUg ZG9lcyB0aGUgc3BlYyBzYXkgdGhhdD8gSSBkb24ndCByZWNhbGwgdGhlIHRlcm0gImJvdW5kIg0K PiB1c2VkIHRoYXQgd2F5IGJ1dCBtYXkgaGF2ZSBtaXNzZWQgaXQuDQo+IA0KDQpbTWVkXSBUaGUg c3BlY2lmaWNhdGlvbiBzYXlzOiANCg0KICAgSWYgYSBET1RTIGNsaWVudCBpcyBlbnRpdGxlZCB0 byBzb2xpY2l0IHRoZSBET1RTIHNlcnZpY2UsIHRoZSBET1RTDQogICBzZXJ2ZXIgZW5hYmxlcyBt aXRpZ2F0aW9uIG9uIGJlaGFsZiBvZiB0aGUgRE9UUyBjbGllbnQgYnkNCiAgIGNvbW11bmljYXRp bmcgdGhlIERPVFMgY2xpZW50J3MgcmVxdWVzdCB0byBhIG1pdGlnYXRvciAod2hpY2ggbWF5IGJl DQogICBjb2xvY2F0ZWQgd2l0aCB0aGUgRE9UUyBzZXJ2ZXIpIGFuZCByZWxheWluZyB0aGUgZmVl ZGJhY2sgb2YgdGhlDQogICB0aHVzLXNlbGVjdGVkIG1pdGlnYXRvciB0byB0aGUgcmVxdWVzdGlu ZyBET1RTIGNsaWVudC4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgIF5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXg0KQW5kIA0KDQogICAnY3VpZCcgaXMgYSBtYW5kYXRvcnkgVXJpLVBh dGggcGFyYW1ldGVyIGZvciBHRVQgcmVxdWVzdHMuDQoNCg0KPiBBbmQgaXQgc3RpbGwgc2VlbXMg YSBiaXQgaGFyZCB0byBlbmZvcmNlLiBJZiB0d28gY2xpZW50cyAob25lDQo+IG9rLCBvbmUgem9t YmllZCkgYXNrIHRoZSBzYW1lIHNlcnZlci9uZXR3b3JrIGhvdyBtYW55IHBhY2tldHMNCj4gdGFy Z2V0dGVkIGF0IDEwLjAuMC8yNCB3ZXJlIGRyb3BwZWQgd29uJ3QgdGhleSBnZXQgdGhlIHNhbWUN Cj4gYW5zd2VyPyAoQXNzdW1pbmcgYm90aCBjbGllbnRzIGFyZSB3aXRoaW4gdGhhdCAvMjQuKQ0K DQpbTWVkXSBBdHRhY2sgc3RhdHVzIGluZm9ybWF0aW9uIGlzIGJvdW5kIHRvIGEgRE9UUyBjbGll bnQgYXMgc2hvd24gaW4gdGhlIFlBTkcgdHJlZSBtb2R1bGU6IA0KDQogICAgICAgICAgICstLToo bWl0aWdhdGlvbi1zY29wZSkNCiAgICAgICAgICAgfCAgKy0tcncgc2NvcGUqIFtjdWlkIG1pZF0N CiAgICAgICAgICAgfCAgICAgKy0tcncgY2RpZD8gICAgICAgICAgICAgICAgICAgc3RyaW5nDQog ICAgICAgICAgIHwgICAgICstLXJ3IGN1aWQgICAgICAgICAgICAgICAgICAgIHN0cmluZw0KICAg ICAgICAgICB8ICAgICArLS1ydyBtaWQgICAgICAgICAgICAgICAgICAgICB1aW50MzINCiAgICAg ICAgICAgICAgICAuLi4NCiAgICAgICAgICAgfCAgICAgKy0tcm8gc3RhdHVzPyAgICAgICAgICAg ICAgICAgaWFuYS1zaWduYWw6c3RhdHVzDQogICAgICAgICAgICAgICAgLi4uDQogICAgICAgICAg IHwgICAgICstLXJvIGJ5dGVzLWRyb3BwZWQ/ICAgICAgICAgIHlhbmc6emVyby1iYXNlZC1jb3Vu dGVyNjQNCiAgICAgICAgICAgfCAgICAgKy0tcm8gYnBzLWRyb3BwZWQ/ICAgICAgICAgICAgeWFu Zzp6ZXJvLWJhc2VkLWNvdW50ZXI2NA0KICAgICAgICAgICB8ICAgICArLS1ybyBwa3RzLWRyb3Bw ZWQ/ICAgICAgICAgICB5YW5nOnplcm8tYmFzZWQtY291bnRlcjY0DQogICAgICAgICAgIHwgICAg ICstLXJvIHBwcy1kcm9wcGVkPyAgICAgICAgICAgIHlhbmc6emVyby1iYXNlZC1jb3VudGVyNjQN CiAgICAgICAgICAgfCAgICAgKy0tcncgYXR0YWNrLXN0YXR1cz8gICAgICAgICAgaWFuYS1zaWdu YWw6YXR0YWNrLXN0YXR1cyANCg0KKiBJZiBjbGllbnQgMSBhc2tlZCBmb3IgbWl0aWdhdGlvbiBm b3IgMTAuMC4wLzI0LCB0aGVuIG9ubHkgdGhhdCBjbGllbnQgY2FuIGFjY2VzcyB0byBhdHRhY2sg c3RhdHVzIGluZm9ybWF0aW9uLiANCiogSWYgYW5vdGhlciBjbGllbnQgMiBhc2tzIGZvciBtaXRp Z2F0aW9uIGZvciB0aGUgc2FtZSBwcmVmaXgsIHRoZSBzZXJ2ZXIgYXBwbGllcyBhIGNvbmZsaWN0 IGhhbmRsaW5nIHByb2NlZHVyZSBhbmQgZGVjaWRlcyB3aGljaCByZXF1ZXN0IHRvIG1haW50YWlu IGFzIGFjdGl2ZS4gT25seSBvbmUgbWl0aWdhdGlvbiBmb3IgYSBnaXZlbiBzY29wZSBjYW4gYmUg bWFpbnRhaW5lZC4gT25seSB0aGF0IHNlbGVjdGVkIGNsaWVudCBjYW4gYWNjZXNzIHRvIHRoZSBh dHRhY2sgc3RhdHVzIGluZm9ybWF0aW9uLg0KDQo= From nobody Fri Mar 15 03:57: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 C94D8128701; Fri, 15 Mar 2019 03:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, 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=mcafee.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 j92N4SipWthp; Fri, 15 Mar 2019 03:56:56 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 65E161311F2; Fri, 15 Mar 2019 03:56:54 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1552647196; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:x-originating-ip: x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-forefront-prvs:x-forefront-antispam-report: received-spf:authentication-results:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=mB6Ty01bzvZ/vEWVa8ZJOy/b9aqkNBlPRwIANQ 0EwZc=; b=d/9qVEZ5LlmvzdLsleBsbClVhm1SqQp1o+iSccL8 YsB7fOVVBvH+pG+K1ukcN7ukrXUeN9Ze/8+Q0wFmx46lQv5QUh 1ntXFjMaL/xV5MfFkXaC3SDGQvQNqzGH8WMCjyziw0lFv1kMCT jm9l0wt8zLbSxIu9XSVimGzSkdGB8+w= Received: from DNVEXAPP1N04.corpzone.internalzone.com (DNVEXAPP1N04.corpzone.internalzone.com [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 4013_9745_5e12782d_caf8_441f_8535_535430ee911e; Fri, 15 Mar 2019 04:53:16 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 15 Mar 2019 04:56:22 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 15 Mar 2019 04:56:22 -0600 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 15 Mar 2019 04:56:14 -0600 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2696.namprd16.prod.outlook.com (20.178.197.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.13; Fri, 15 Mar 2019 10:56:13 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1709.011; Fri, 15 Mar 2019 10:56:13 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "Stephen Farrell" , "secdir@ietf.org" CC: "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-dots-signal-channel-30 Thread-Index: AQHU2xxjG8gRJA7b406ek86bI9y+AKYMhIbg Date: Fri, 15 Mar 2019 10:56:13 +0000 Message-ID: References: <155257761487.2625.10003476313108979036@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA3DFC8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <72f7b85c-74fb-0f79-8211-50043c2b4b47@cs.tcd.ie> <787AE7BB302AE849A7480A190F8B93302EA3E475@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA3E6E1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA3E6E1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 580e43f9-9fb3-41e3-40b3-08d6a934d72d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2696; x-ms-traffictypediagnostic: BYAPR16MB2696: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 09778E995A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(396003)(376002)(346002)(39860400002)(32952001)(13464003)(199004)(189003)(93886005)(53936002)(476003)(2906002)(102836004)(446003)(5660300002)(97736004)(6346003)(6116002)(3846002)(81156014)(6506007)(486006)(53546011)(316002)(26005)(33656002)(76176011)(11346002)(52536014)(81166006)(7696005)(8676002)(71200400001)(71190400001)(110136005)(54906003)(186003)(4326008)(68736007)(55016002)(72206003)(99286004)(6306002)(305945005)(7736002)(86362001)(80792005)(6246003)(9686003)(74316002)(25786009)(6436002)(5024004)(14444005)(2501003)(14454004)(106356001)(256004)(478600001)(66066001)(105586002)(8936002)(966005)(229853002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2696; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: h1AvKL9MIo05TiPqPeUbeuOcytyXgdllcLJp3Md2efz7KXZXpdwskpLA9OtIXJOlMi2grXaOqFgqwEar5G/fhaSs9XyxHRjFTy4HlMUDsai22owXMwBMuDuDvLW/ZQHoXIzLijZgpG2Mp7xIMqIUla/BpM7nZetNp5y4njRrGp6Cxyg5nIIrBl6SbGnkmilV9Sn8AZUpJYWvP5iv5bIg1ZfkGfWDrY04mCNCcIDISf8s6WexfiFf/8x09qOO4f/9owHoY3kJH8IVdJN3vJPEeofJnkNHRDnbUXpW2fNFWcnY/ORc+SIUcbZ9HRM/4qkIX4BKSxJ2We1362yUjx/0dNYLiWrImlYRxVti6qufIz53196yJ21FVzz0ReDhjXB5C85MURgO/QdaBG0RzLbONUr3yoPE+9iqVx6C3klBLBg= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 580e43f9-9fb3-41e3-40b3-08d6a934d72d X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2019 10:56:13.1323 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR16MB2696 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.5 X-NAI-Spam-Version: 2.3.0.9418 : core <6503> : inlines <7034> : streams <1815769> : uri <2813174> Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dots-signal-channel-30 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, 15 Mar 2019 10:57:01 -0000 SGkgTWVkLA0KDQpTdGVwaGVuIGlzIHJlZmVycmluZyB0byBhbiBhdHRhY2sgd2hlcmUgYSBjb21w cm9taXNlZCBET1RTIGNsaWVudCBpbml0aWF0ZXMgbWl0aWdhdGlvbiByZXF1ZXN0IGZvciBhIHRh cmdldCByZXNvdXJjZSB0aGF0IGlzIGF0dGFja2VkIGFuZCBsZWFybnMgdGhlIG1pdGlnYXRpb24g ZWZmaWNhY3kgb2YgdGhlIERPVFMgc2VydmVyLCBpbmZvcm1zIHRoZSBtaXRpZ2F0aW9uIGVmZmlj YWN5IHRvIEREb1MgYXR0YWNrZXIgdG8gY2hhbmdlIHRoZSBERG9TIGF0dGFjayBzdHJhdGVneS4g IA0KDQpXZSBjYW4gYWRkIHRoZSBmb2xsb3dpbmcgbGluZXMgdG8gYWRkcmVzcyBoaXMgY29tbWVu dDoNCg0KQSBjb21wcm9taXNlZCBET1RTIGNsaWVudCBjYW4gY29sbHVkZSB3aXRoIGEgRERvUyBh dHRhY2tlciB0byBzZW5kIG1pdGlnYXRpb24gcmVxdWVzdCBmb3IgYSB0YXJnZXQgcmVzb3VyY2Us IGxlYXJucyB0aGUgbWl0aWdhdGlvbiBlZmZpY2FjeSBmcm9tIHRoZSBET1RTIHNlcnZlciwgYW5k IGNvbnZleXMgdGhlIGVmZmljYWN5IHRvIHRoZSBERG9TIGF0dGFja2VyIHRvIGxlYXJuIHRoZSBt aXRpZ2F0aW9uIGNhcGFiaWxpdGllcyBvZiB0aGUgRERvUyBtaXRpZ2F0aW9uIGFuZCB0byBwb3Nz aWJseSBjaGFuZ2UgdGhlIEREb1MgYXR0YWNrIHN0cmF0ZWd5LiBUaGlzIGF0dGFjayBjYW4gYmUg cHJldmVudGVkIGJ5IGF1ZGl0aW5nIHRoZSBiZWhhdmlvciBvZiBET1RTIGNsaWVudHMgYW5kIGF1 dGhvcml6aW5nIHRoZSBET1RTIGNsaWVudCB0byByZXF1ZXN0IG1pdGlnYXRpb24gZm9yIHNwZWNp ZmljIHRhcmdldCByZXNvdXJjZXMuDQoNCkNoZWVycywNCi1UaXJ1DQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRG90cyA8ZG90cy1ib3VuY2VzQGlldGYub3JnPiBPbiBC ZWhhbGYgT2YNCj4gbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbQ0KPiBTZW50OiBGcmlkYXks IE1hcmNoIDE1LCAyMDE5IDQ6MTUgUE0NCj4gVG86IFN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbi5m YXJyZWxsQGNzLnRjZC5pZT47IHNlY2RpckBpZXRmLm9yZw0KPiBDYzogZHJhZnQtaWV0Zi1kb3Rz LXNpZ25hbC1jaGFubmVsLmFsbEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgZG90c0BpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSZTogW0RvdHNdIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0 LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC0zMA0KPiANCj4gVGhpcyBlbWFpbCBvcmlnaW5hdGVk IGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QgY2xpY2sgbGlua3Mgb3IN Cj4gb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBr bm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQo+IA0KPiBSZS0sDQo+IA0KPiBQbGVhc2Ugc2VlIGlu bGluZS4NCj4gDQo+IENoZWVycywNCj4gTWVkDQo+IA0KPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdp bmUtLS0tLQ0KPiA+IERlwqA6IFN0ZXBoZW4gRmFycmVsbCBbbWFpbHRvOnN0ZXBoZW4uZmFycmVs bEBjcy50Y2QuaWVdDQo+ID4gRW52b3nDqcKgOiB2ZW5kcmVkaSAxNSBtYXJzIDIwMTkgMTE6MjAN Cj4gPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOOyBzZWNkaXJAaWV0Zi5vcmcgQ2PC oDoNCj4gPiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwuYWxsQGlldGYub3JnOyBpZXRm QGlldGYub3JnOw0KPiA+IGRvdHNAaWV0Zi5vcmcgT2JqZXTCoDogUmU6IFNlY2RpciBsYXN0IGNh bGwgcmV2aWV3IG9mDQo+ID4gZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLTMwDQo+ID4N Cj4gPg0KPiA+IEhpeWEsDQo+ID4NCj4gPiBPbiAxNS8wMy8yMDE5IDA2OjQ3LCBtb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0KPiA+ID4+IElTVE0gdGhhdCBhbGwgY2xpZW50cyBj YW4gZ2V0IGluZm9ybWF0aW9uIGFib3V0IGhvdyBhbiBhdHRhY2sgaXMNCj4gPiA+PiBiZWluZyBz ZWVuIGF0IG90aGVyIGNsaWVudHMsIGlzbid0IHRoYXQgcmlnaHQ/DQo+ID4gPiBbTWVkXSBOby4g QSBjbGllbnQgY2FuIG9ubHkgZ2V0IGluZm9ybWF0aW9uIHRoYXQgaXMgYm91bmQgdG8gaXQuDQo+ ID4gV2hlcmUgZG9lcyB0aGUgc3BlYyBzYXkgdGhhdD8gSSBkb24ndCByZWNhbGwgdGhlIHRlcm0g ImJvdW5kIg0KPiA+IHVzZWQgdGhhdCB3YXkgYnV0IG1heSBoYXZlIG1pc3NlZCBpdC4NCj4gPg0K PiANCj4gW01lZF0gVGhlIHNwZWNpZmljYXRpb24gc2F5czoNCj4gDQo+ICAgIElmIGEgRE9UUyBj bGllbnQgaXMgZW50aXRsZWQgdG8gc29saWNpdCB0aGUgRE9UUyBzZXJ2aWNlLCB0aGUgRE9UUw0K PiAgICBzZXJ2ZXIgZW5hYmxlcyBtaXRpZ2F0aW9uIG9uIGJlaGFsZiBvZiB0aGUgRE9UUyBjbGll bnQgYnkNCj4gICAgY29tbXVuaWNhdGluZyB0aGUgRE9UUyBjbGllbnQncyByZXF1ZXN0IHRvIGEg bWl0aWdhdG9yICh3aGljaCBtYXkgYmUNCj4gICAgY29sb2NhdGVkIHdpdGggdGhlIERPVFMgc2Vy dmVyKSBhbmQgcmVsYXlpbmcgdGhlIGZlZWRiYWNrIG9mIHRoZQ0KPiAgICB0aHVzLXNlbGVjdGVk IG1pdGlnYXRvciB0byB0aGUgcmVxdWVzdGluZyBET1RTIGNsaWVudC4NCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eIEFuZA0KPiANCj4g ICAgJ2N1aWQnIGlzIGEgbWFuZGF0b3J5IFVyaS1QYXRoIHBhcmFtZXRlciBmb3IgR0VUIHJlcXVl c3RzLg0KPiANCj4gDQo+ID4gQW5kIGl0IHN0aWxsIHNlZW1zIGEgYml0IGhhcmQgdG8gZW5mb3Jj ZS4gSWYgdHdvIGNsaWVudHMgKG9uZSBvaywgb25lDQo+ID4gem9tYmllZCkgYXNrIHRoZSBzYW1l IHNlcnZlci9uZXR3b3JrIGhvdyBtYW55IHBhY2tldHMgdGFyZ2V0dGVkIGF0DQo+ID4gMTAuMC4w LzI0IHdlcmUgZHJvcHBlZCB3b24ndCB0aGV5IGdldCB0aGUgc2FtZSBhbnN3ZXI/IChBc3N1bWlu ZyBib3RoDQo+ID4gY2xpZW50cyBhcmUgd2l0aGluIHRoYXQgLzI0LikNCj4gDQo+IFtNZWRdIEF0 dGFjayBzdGF0dXMgaW5mb3JtYXRpb24gaXMgYm91bmQgdG8gYSBET1RTIGNsaWVudCBhcyBzaG93 biBpbiB0aGUNCj4gWUFORyB0cmVlIG1vZHVsZToNCj4gDQo+ICAgICAgICAgICAgKy0tOihtaXRp Z2F0aW9uLXNjb3BlKQ0KPiAgICAgICAgICAgIHwgICstLXJ3IHNjb3BlKiBbY3VpZCBtaWRdDQo+ ICAgICAgICAgICAgfCAgICAgKy0tcncgY2RpZD8gICAgICAgICAgICAgICAgICAgc3RyaW5nDQo+ ICAgICAgICAgICAgfCAgICAgKy0tcncgY3VpZCAgICAgICAgICAgICAgICAgICAgc3RyaW5nDQo+ ICAgICAgICAgICAgfCAgICAgKy0tcncgbWlkICAgICAgICAgICAgICAgICAgICAgdWludDMyDQo+ ICAgICAgICAgICAgICAgICAuLi4NCj4gICAgICAgICAgICB8ICAgICArLS1ybyBzdGF0dXM/ICAg ICAgICAgICAgICAgICBpYW5hLXNpZ25hbDpzdGF0dXMNCj4gICAgICAgICAgICAgICAgIC4uLg0K PiAgICAgICAgICAgIHwgICAgICstLXJvIGJ5dGVzLWRyb3BwZWQ/ICAgICAgICAgIHlhbmc6emVy by1iYXNlZC1jb3VudGVyNjQNCj4gICAgICAgICAgICB8ICAgICArLS1ybyBicHMtZHJvcHBlZD8g ICAgICAgICAgICB5YW5nOnplcm8tYmFzZWQtY291bnRlcjY0DQo+ICAgICAgICAgICAgfCAgICAg Ky0tcm8gcGt0cy1kcm9wcGVkPyAgICAgICAgICAgeWFuZzp6ZXJvLWJhc2VkLWNvdW50ZXI2NA0K PiAgICAgICAgICAgIHwgICAgICstLXJvIHBwcy1kcm9wcGVkPyAgICAgICAgICAgIHlhbmc6emVy by1iYXNlZC1jb3VudGVyNjQNCj4gICAgICAgICAgICB8ICAgICArLS1ydyBhdHRhY2stc3RhdHVz PyAgICAgICAgICBpYW5hLXNpZ25hbDphdHRhY2stc3RhdHVzDQo+IA0KPiAqIElmIGNsaWVudCAx IGFza2VkIGZvciBtaXRpZ2F0aW9uIGZvciAxMC4wLjAvMjQsIHRoZW4gb25seSB0aGF0IGNsaWVu dCBjYW4gYWNjZXNzDQo+IHRvIGF0dGFjayBzdGF0dXMgaW5mb3JtYXRpb24uDQo+ICogSWYgYW5v dGhlciBjbGllbnQgMiBhc2tzIGZvciBtaXRpZ2F0aW9uIGZvciB0aGUgc2FtZSBwcmVmaXgsIHRo ZSBzZXJ2ZXIgYXBwbGllcyBhDQo+IGNvbmZsaWN0IGhhbmRsaW5nIHByb2NlZHVyZSBhbmQgZGVj aWRlcyB3aGljaCByZXF1ZXN0IHRvIG1haW50YWluIGFzIGFjdGl2ZS4NCj4gT25seSBvbmUgbWl0 aWdhdGlvbiBmb3IgYSBnaXZlbiBzY29wZSBjYW4gYmUgbWFpbnRhaW5lZC4gT25seSB0aGF0IHNl bGVjdGVkDQo+IGNsaWVudCBjYW4gYWNjZXNzIHRvIHRoZSBhdHRhY2sgc3RhdHVzIGluZm9ybWF0 aW9uLg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gRG90cyBtYWlsaW5nIGxpc3QNCj4gRG90c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCg== From nobody Fri Mar 15 05:27:16 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 1CBCE131229; Fri, 15 Mar 2019 05:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 pE-OLvFrrRVM; Fri, 15 Mar 2019 05:26:55 -0700 (PDT) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47CD1130E62; Fri, 15 Mar 2019 05:26:55 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 44LPvx1Zgnz2y5T; Fri, 15 Mar 2019 13:26:53 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 44LPvx0rgrz2xCC; Fri, 15 Mar 2019 13:26:53 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM5C.corporate.adroot.infra.ftgroup ([fe80::393d:418c:3f1d:991d%21]) with mapi id 14.03.0439.000; Fri, 15 Mar 2019 13:26:53 +0100 From: To: "Konda, Tirumaleswar Reddy" , "Stephen Farrell" , "secdir@ietf.org" CC: "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-dots-signal-channel-30 Thread-Index: AQHU2xxjRsTGH2X350i3IMDpwuRCCqYMhIbggAAWifA= Date: Fri, 15 Mar 2019 12:26:52 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA3E789@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <155257761487.2625.10003476313108979036@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA3DFC8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <72f7b85c-74fb-0f79-8211-50043c2b4b47@cs.tcd.ie> <787AE7BB302AE849A7480A190F8B93302EA3E475@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA3E6E1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dots-signal-channel-30 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, 15 Mar 2019 12:26:58 -0000 VGlydSwgDQoNCkknbSBub3Qgc3VyZSBpZiB0aGlzIGlzIHRoZSBjYXNlIFN0ZXBoZW4gaXMgcmVm ZXJyaW5nIHRvLCBidXQgdGhpcyBmYWxscyB1bmRlciB0aGUgZ2VuZXJpYyBjb25zaWRlcmF0aW9u czogDQoNCiAgIEhpZ2gtbGV2ZWwgRE9UUyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhcmUgZG9j dW1lbnRlZCBpbg0KICAgW0ktRC5pZXRmLWRvdHMtcmVxdWlyZW1lbnRzXSBhbmQgW0ktRC5pZXRm LWRvdHMtYXJjaGl0ZWN0dXJlXS4NCg0KQW5kIHRoZW4gSS1ELmlldGYtZG90cy1yZXF1aXJlbWVu dHM6IA0KDQogICBUbyBkZXRlY3QgY29tcHJvbWlzZWQgRE9UUyBhZ2VudHMsIERPVFMgb3BlcmF0 b3JzIHNob3VsZCBjYXJlZnVsbHkNCiAgIG1vbml0b3IgYW5kIGF1ZGl0IERPVFMgYWdlbnRzIHRv IGRldGVjdCBtaXNiZWhhdmlvciBhbmQgdG8gZGV0ZXINCiAgIG1pc3VzZSwgd2hpbGUgZW1wbG95 aW5nIGN1cnJlbnQgc2VjdXJlIG5ldHdvcmsgY29tbXVuaWNhdGlvbnMgYmVzdA0KICAgcHJhY3Rp Y2VzIHRvIHJlZHVjZSBhdHRhY2sgc3VyZmFjZS4NCg0KU3RpbGwsIGEgZ29vZCBzdHJhdGVneSBm b3IgYW4gYXR0YWNrIHRvIHN1Y2NlZWQgaXMgdG8gbm90IHNpZ25hbCB0aGUgYXR0YWNrISANCg0K Q2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEtv bmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgW21haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBN Y0FmZWUuY29tXQ0KPiBFbnZvecOpwqA6IHZlbmRyZWRpIDE1IG1hcnMgMjAxOSAxMTo1Ng0KPiDD gMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOOyBTdGVwaGVuIEZhcnJlbGw7IHNlY2RpckBp ZXRmLm9yZw0KPiBDY8KgOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwuYWxsQGlldGYu b3JnOyBpZXRmQGlldGYub3JnOw0KPiBkb3RzQGlldGYub3JnDQo+IE9iamV0wqA6IFJFOiBTZWNk aXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMzAN Cj4gDQo+IEhpIE1lZCwNCj4gDQo+IFN0ZXBoZW4gaXMgcmVmZXJyaW5nIHRvIGFuIGF0dGFjayB3 aGVyZSBhIGNvbXByb21pc2VkIERPVFMgY2xpZW50IGluaXRpYXRlcw0KPiBtaXRpZ2F0aW9uIHJl cXVlc3QgZm9yIGEgdGFyZ2V0IHJlc291cmNlIHRoYXQgaXMgYXR0YWNrZWQgYW5kIGxlYXJucyB0 aGUNCj4gbWl0aWdhdGlvbiBlZmZpY2FjeSBvZiB0aGUgRE9UUyBzZXJ2ZXIsIGluZm9ybXMgdGhl IG1pdGlnYXRpb24gZWZmaWNhY3kgdG8NCj4gRERvUyBhdHRhY2tlciB0byBjaGFuZ2UgdGhlIERE b1MgYXR0YWNrIHN0cmF0ZWd5Lg0KPiANCj4gV2UgY2FuIGFkZCB0aGUgZm9sbG93aW5nIGxpbmVz IHRvIGFkZHJlc3MgaGlzIGNvbW1lbnQ6DQo+IA0KPiBBIGNvbXByb21pc2VkIERPVFMgY2xpZW50 IGNhbiBjb2xsdWRlIHdpdGggYSBERG9TIGF0dGFja2VyIHRvIHNlbmQgbWl0aWdhdGlvbg0KPiBy ZXF1ZXN0IGZvciBhIHRhcmdldCByZXNvdXJjZSwgbGVhcm5zIHRoZSBtaXRpZ2F0aW9uIGVmZmlj YWN5IGZyb20gdGhlIERPVFMNCj4gc2VydmVyLCBhbmQgY29udmV5cyB0aGUgZWZmaWNhY3kgdG8g dGhlIEREb1MgYXR0YWNrZXIgdG8gbGVhcm4gdGhlIG1pdGlnYXRpb24NCj4gY2FwYWJpbGl0aWVz IG9mIHRoZSBERG9TIG1pdGlnYXRpb24gYW5kIHRvIHBvc3NpYmx5IGNoYW5nZSB0aGUgRERvUyBh dHRhY2sNCj4gc3RyYXRlZ3kuIFRoaXMgYXR0YWNrIGNhbiBiZSBwcmV2ZW50ZWQgYnkgYXVkaXRp bmcgdGhlIGJlaGF2aW9yIG9mIERPVFMNCj4gY2xpZW50cyBhbmQgYXV0aG9yaXppbmcgdGhlIERP VFMgY2xpZW50IHRvIHJlcXVlc3QgbWl0aWdhdGlvbiBmb3Igc3BlY2lmaWMNCj4gdGFyZ2V0IHJl c291cmNlcy4NCj4gDQo+IENoZWVycywNCj4gLVRpcnUNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBEb3RzIDxkb3RzLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJl aGFsZiBPZg0KPiA+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gPiBTZW50OiBGcmlk YXksIE1hcmNoIDE1LCAyMDE5IDQ6MTUgUE0NCj4gPiBUbzogU3RlcGhlbiBGYXJyZWxsIDxzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllPjsgc2VjZGlyQGlldGYub3JnDQo+ID4gQ2M6IGRyYWZ0LWll dGYtZG90cy1zaWduYWwtY2hhbm5lbC5hbGxAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7DQo+IGRv dHNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW0RvdHNdIFNlY2RpciBsYXN0IGNhbGwgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtZG90cy1zaWduYWwtDQo+IGNoYW5uZWwtMzANCj4gPg0KPiA+IFRo aXMgZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9yZ2FuaXphdGlvbi4gRG8g bm90IGNsaWNrIGxpbmtzDQo+IG9yDQo+ID4gb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJl Y29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzDQo+IHNhZmUuDQo+ID4N Cj4gPiBSZS0sDQo+ID4NCj4gPiBQbGVhc2Ugc2VlIGlubGluZS4NCj4gPg0KPiA+IENoZWVycywN Cj4gPiBNZWQNCj4gPg0KPiA+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gPiBE ZcKgOiBTdGVwaGVuIEZhcnJlbGwgW21haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllXQ0K PiA+ID4gRW52b3nDqcKgOiB2ZW5kcmVkaSAxNSBtYXJzIDIwMTkgMTE6MjANCj4gPiA+IMOAwqA6 IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE47IHNlY2RpckBpZXRmLm9yZyBDY8KgOg0KPiA+ID4g ZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLmFsbEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9y ZzsNCj4gPiA+IGRvdHNAaWV0Zi5vcmcgT2JqZXTCoDogUmU6IFNlY2RpciBsYXN0IGNhbGwgcmV2 aWV3IG9mDQo+ID4gPiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMzANCj4gPiA+DQo+ ID4gPg0KPiA+ID4gSGl5YSwNCj4gPiA+DQo+ID4gPiBPbiAxNS8wMy8yMDE5IDA2OjQ3LCBtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0KPiA+ID4gPj4gSVNUTSB0aGF0IGFsbCBj bGllbnRzIGNhbiBnZXQgaW5mb3JtYXRpb24gYWJvdXQgaG93IGFuIGF0dGFjayBpcw0KPiA+ID4g Pj4gYmVpbmcgc2VlbiBhdCBvdGhlciBjbGllbnRzLCBpc24ndCB0aGF0IHJpZ2h0Pw0KPiA+ID4g PiBbTWVkXSBOby4gQSBjbGllbnQgY2FuIG9ubHkgZ2V0IGluZm9ybWF0aW9uIHRoYXQgaXMgYm91 bmQgdG8gaXQuDQo+ID4gPiBXaGVyZSBkb2VzIHRoZSBzcGVjIHNheSB0aGF0PyBJIGRvbid0IHJl Y2FsbCB0aGUgdGVybSAiYm91bmQiDQo+ID4gPiB1c2VkIHRoYXQgd2F5IGJ1dCBtYXkgaGF2ZSBt aXNzZWQgaXQuDQo+ID4gPg0KPiA+DQo+ID4gW01lZF0gVGhlIHNwZWNpZmljYXRpb24gc2F5czoN Cj4gPg0KPiA+ICAgIElmIGEgRE9UUyBjbGllbnQgaXMgZW50aXRsZWQgdG8gc29saWNpdCB0aGUg RE9UUyBzZXJ2aWNlLCB0aGUgRE9UUw0KPiA+ICAgIHNlcnZlciBlbmFibGVzIG1pdGlnYXRpb24g b24gYmVoYWxmIG9mIHRoZSBET1RTIGNsaWVudCBieQ0KPiA+ICAgIGNvbW11bmljYXRpbmcgdGhl IERPVFMgY2xpZW50J3MgcmVxdWVzdCB0byBhIG1pdGlnYXRvciAod2hpY2ggbWF5IGJlDQo+ID4g ICAgY29sb2NhdGVkIHdpdGggdGhlIERPVFMgc2VydmVyKSBhbmQgcmVsYXlpbmcgdGhlIGZlZWRi YWNrIG9mIHRoZQ0KPiA+ICAgIHRodXMtc2VsZWN0ZWQgbWl0aWdhdG9yIHRvIHRoZSByZXF1ZXN0 aW5nIERPVFMgY2xpZW50Lg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIF5eXl5eXl5e Xl5eXl5eXl5eXl5eXl5eXl5eXl5eXiBBbmQNCj4gPg0KPiA+ICAgICdjdWlkJyBpcyBhIG1hbmRh dG9yeSBVcmktUGF0aCBwYXJhbWV0ZXIgZm9yIEdFVCByZXF1ZXN0cy4NCj4gPg0KPiA+DQo+ID4g PiBBbmQgaXQgc3RpbGwgc2VlbXMgYSBiaXQgaGFyZCB0byBlbmZvcmNlLiBJZiB0d28gY2xpZW50 cyAob25lIG9rLCBvbmUNCj4gPiA+IHpvbWJpZWQpIGFzayB0aGUgc2FtZSBzZXJ2ZXIvbmV0d29y ayBob3cgbWFueSBwYWNrZXRzIHRhcmdldHRlZCBhdA0KPiA+ID4gMTAuMC4wLzI0IHdlcmUgZHJv cHBlZCB3b24ndCB0aGV5IGdldCB0aGUgc2FtZSBhbnN3ZXI/IChBc3N1bWluZyBib3RoDQo+ID4g PiBjbGllbnRzIGFyZSB3aXRoaW4gdGhhdCAvMjQuKQ0KPiA+DQo+ID4gW01lZF0gQXR0YWNrIHN0 YXR1cyBpbmZvcm1hdGlvbiBpcyBib3VuZCB0byBhIERPVFMgY2xpZW50IGFzIHNob3duIGluIHRo ZQ0KPiA+IFlBTkcgdHJlZSBtb2R1bGU6DQo+ID4NCj4gPiAgICAgICAgICAgICstLToobWl0aWdh dGlvbi1zY29wZSkNCj4gPiAgICAgICAgICAgIHwgICstLXJ3IHNjb3BlKiBbY3VpZCBtaWRdDQo+ ID4gICAgICAgICAgICB8ICAgICArLS1ydyBjZGlkPyAgICAgICAgICAgICAgICAgICBzdHJpbmcN Cj4gPiAgICAgICAgICAgIHwgICAgICstLXJ3IGN1aWQgICAgICAgICAgICAgICAgICAgIHN0cmlu Zw0KPiA+ICAgICAgICAgICAgfCAgICAgKy0tcncgbWlkICAgICAgICAgICAgICAgICAgICAgdWlu dDMyDQo+ID4gICAgICAgICAgICAgICAgIC4uLg0KPiA+ICAgICAgICAgICAgfCAgICAgKy0tcm8g c3RhdHVzPyAgICAgICAgICAgICAgICAgaWFuYS1zaWduYWw6c3RhdHVzDQo+ID4gICAgICAgICAg ICAgICAgIC4uLg0KPiA+ICAgICAgICAgICAgfCAgICAgKy0tcm8gYnl0ZXMtZHJvcHBlZD8gICAg ICAgICAgeWFuZzp6ZXJvLWJhc2VkLWNvdW50ZXI2NA0KPiA+ICAgICAgICAgICAgfCAgICAgKy0t cm8gYnBzLWRyb3BwZWQ/ICAgICAgICAgICAgeWFuZzp6ZXJvLWJhc2VkLWNvdW50ZXI2NA0KPiA+ ICAgICAgICAgICAgfCAgICAgKy0tcm8gcGt0cy1kcm9wcGVkPyAgICAgICAgICAgeWFuZzp6ZXJv LWJhc2VkLWNvdW50ZXI2NA0KPiA+ICAgICAgICAgICAgfCAgICAgKy0tcm8gcHBzLWRyb3BwZWQ/ ICAgICAgICAgICAgeWFuZzp6ZXJvLWJhc2VkLWNvdW50ZXI2NA0KPiA+ICAgICAgICAgICAgfCAg ICAgKy0tcncgYXR0YWNrLXN0YXR1cz8gICAgICAgICAgaWFuYS1zaWduYWw6YXR0YWNrLXN0YXR1 cw0KPiA+DQo+ID4gKiBJZiBjbGllbnQgMSBhc2tlZCBmb3IgbWl0aWdhdGlvbiBmb3IgMTAuMC4w LzI0LCB0aGVuIG9ubHkgdGhhdCBjbGllbnQgY2FuDQo+IGFjY2Vzcw0KPiA+IHRvIGF0dGFjayBz dGF0dXMgaW5mb3JtYXRpb24uDQo+ID4gKiBJZiBhbm90aGVyIGNsaWVudCAyIGFza3MgZm9yIG1p dGlnYXRpb24gZm9yIHRoZSBzYW1lIHByZWZpeCwgdGhlIHNlcnZlcg0KPiBhcHBsaWVzIGENCj4g PiBjb25mbGljdCBoYW5kbGluZyBwcm9jZWR1cmUgYW5kIGRlY2lkZXMgd2hpY2ggcmVxdWVzdCB0 byBtYWludGFpbiBhcw0KPiBhY3RpdmUuDQo+ID4gT25seSBvbmUgbWl0aWdhdGlvbiBmb3IgYSBn aXZlbiBzY29wZSBjYW4gYmUgbWFpbnRhaW5lZC4gT25seSB0aGF0IHNlbGVjdGVkDQo+ID4gY2xp ZW50IGNhbiBhY2Nlc3MgdG8gdGhlIGF0dGFjayBzdGF0dXMgaW5mb3JtYXRpb24uDQo+ID4NCj4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IERv dHMgbWFpbGluZyBsaXN0DQo+ID4gRG90c0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0K From nobody Fri Mar 15 06:21:38 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 1304A131244; Fri, 15 Mar 2019 06:21:37 -0700 (PDT) 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_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 pt-3tN36Ie7u; Fri, 15 Mar 2019 06:21:35 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5BE13124B; Fri, 15 Mar 2019 06:21:34 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 21C533826B; Fri, 15 Mar 2019 09:21:12 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 6326119BE; Fri, 15 Mar 2019 09:21:32 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6090312A4; Fri, 15 Mar 2019 09:21:32 -0400 (EDT) From: Michael Richardson To: "Konda\, Tirumaleswar Reddy" cc: "mohamed.boucadair\@orange.com" , "Stephen Farrell" , "secdir\@ietf.org" , "draft-ietf-dots-signal-channel.all\@ietf.org" , "ietf\@ietf.org" , "dots\@ietf.org" In-Reply-To: References: <155257761487.2625.10003476313108979036@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA3DFC8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <72f7b85c-74fb-0f79-8211-50043c2b4b47@cs.tcd.ie> <787AE7BB302AE849A7480A190F8B93302EA3E475@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA3E6E1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dots-signal-channel-30 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, 15 Mar 2019 13:21:37 -0000 --=-=-= Content-Type: text/plain Konda, Tirumaleswar Reddy wrote: > Stephen is referring to an attack where a compromised DOTS client > initiates mitigation request for a target resource that is attacked and > learns the mitigation efficacy of the DOTS server, informs the > mitigation efficacy to DDoS attacker to change the DDoS attack > strategy. Is there a word for an an infantry troup who goes behind enemy lines in order to communicate how will the artilery is? I guess a modern form is these laser targetted missiles, where the target is "painted". I don't know if there are words for this kind of thing, but this would seem to describe the situation. > We can add the following lines to address his comment: > A compromised DOTS client can collude with a DDoS attacker to send > mitigation request for a target resource, learns the mitigation > efficacy from the DOTS server, and conveys the efficacy to the DDoS > attacker to learn the mitigation capabilities of the DDoS mitigation > and to possibly change the DDoS attack strategy. This attack can be > prevented by auditing the behavior of DOTS clients and authorizing the > DOTS client to request mitigation for specific target resources. If a resource is already under attack, there are already mitigation requests for that target, can a compromised DOTS client leaern anything by requesting mitigation on the same target? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlyLptwACgkQgItw+93Q 3WVUegf/ZToxRCUEMrHnWSdIZqNMXvWR3DO4OQCcdRl5R+K1D6xlfSmZ2ka7vv3t JBhhdq+QFvBpSWpmnYNOXi3QTqn2yHW3/UhLP7vPGFYqJF3tY+NcHKfsWzzVy7+q JQrDKYmEm5msZx4DnLsqy3FdiC740YrWjmrZihpWuBegrRKgVCwQ6+J18wYqz6Vf l6pfPoIdKJPttRBzqpKCOoAPq4r0fttlNP14+1FCAUK7NRpMrtBl8QejkevhQzKK 4y32UnyJUuosq8WFKSl3BY7E6lEycbWqxoKj+CHXqPGskclPVrddqVE4TndYEe4o MxZFRziSFpp1zEhYJvIJ/7auIpdoDQ== =Fg0J -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 15 07:01: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 D71B2130D7A; Fri, 15 Mar 2019 07:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, 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=mcafee.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 Xp6vZgyx9vNe; Fri, 15 Mar 2019 07:01:14 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 1F4AA12D4E9; Fri, 15 Mar 2019 07:01:13 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1552658255; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=1CZUKChQNFLpwSDqeUEpbS3AFBxme4LBv6hKh5 Hs1rU=; b=KKXTyjJRU/xIsYEosDkZaAPwqRxaOT/uzcfW+aVU vmb6O+58C2smbQOmTmpN35ZdtY/wjM4wLgmr0ByqYgVYxEcCvL +FaI8vOsO6hEYSqtokxlfv9hl3iYcki317noB04miOrGzBGA81 H79DGJLBqIonskwKva97irabgXQcWN0= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 3ff9_3e56_dea83516_35b0_4840_beeb_27a60e9feec3; Fri, 15 Mar 2019 07:57:34 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 15 Mar 2019 08:00:56 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 15 Mar 2019 08:00:56 -0600 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 15 Mar 2019 08:00:55 -0600 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2982.namprd16.prod.outlook.com (20.178.235.208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.14; Fri, 15 Mar 2019 14:00:54 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::9c48:452b:e39c:ef39%2]) with mapi id 15.20.1709.011; Fri, 15 Mar 2019 14:00:54 +0000 From: "Konda, Tirumaleswar Reddy" To: Michael Richardson CC: "mohamed.boucadair@orange.com" , "Stephen Farrell" , "secdir@ietf.org" , "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-dots-signal-channel-30 Thread-Index: AQHU2xxjG8gRJA7b406ek86bI9y+AKYMhIbggAApRACAAAhfcA== Date: Fri, 15 Mar 2019 14:00:54 +0000 Message-ID: References: <155257761487.2625.10003476313108979036@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA3DFC8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <72f7b85c-74fb-0f79-8211-50043c2b4b47@cs.tcd.ie> <787AE7BB302AE849A7480A190F8B93302EA3E475@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA3E6E1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <10751.1552656092@localhost> In-Reply-To: <10751.1552656092@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [49.37.203.5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4a6728d5-ae64-43a9-2159-08d6a94ea435 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR16MB2982; x-ms-traffictypediagnostic: BYAPR16MB2982: x-microsoft-antispam-prvs: x-forefront-prvs: 09778E995A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(396003)(39860400002)(366004)(136003)(32952001)(13464003)(199004)(189003)(14454004)(9686003)(68736007)(53546011)(6506007)(76176011)(55016002)(105586002)(8936002)(6246003)(106356001)(186003)(25786009)(8676002)(26005)(53936002)(305945005)(81156014)(81166006)(478600001)(97736004)(93886005)(7736002)(72206003)(54906003)(102836004)(316002)(2906002)(66066001)(33656002)(256004)(99286004)(7696005)(80792005)(3846002)(6116002)(5660300002)(71190400001)(4326008)(71200400001)(14444005)(229853002)(52536014)(486006)(446003)(6436002)(74316002)(11346002)(476003)(86362001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2982; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: QJAj2f0OGKV1fe3zV6w9WPc6HhcDzhlhNI6f9ByCXLfpQLwYzWEacZNCYmmm5wqJDvlwwhbddrHxng/TeLss4Hn8j1+m7+9c7lDzaffFioxAKBooj0zqALzGHufTi9/tHXp0tECf5Kuk9E5Eo/bUUza1157cRXOn9rWkRkl+FssAj4sI/mMAaqXZbX8VlmzHJEpG3/RpOPu2JKNGx3HlISjXrZH7dPYWIabz/nBKF0w8QUJv4lGwh0tMsCDZDUDbnPvntSx6vOBgXqagtpwj/7fw+X00305Zu7mJCUWhTumQYoU3NA4VULwwboVC5AT1F6aD3hrnHN2+2erwUd5KYOPOYk8jppd2Ol/WV/2ejcJIeew3w+Nfj/YusVOSIWeAsZJy72/D0IyHpoFzj5LdGGosbdg3O1LIg9pBUA0kejY= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4a6728d5-ae64-43a9-2159-08d6a94ea435 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2019 14:00:54.5551 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR16MB2982 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6504> : inlines <7034> : streams <1815781> : uri <2813263> Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dots-signal-channel-30 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, 15 Mar 2019 14:01:17 -0000 > -----Original Message----- > From: Michael Richardson > Sent: Friday, March 15, 2019 6:52 PM > To: Konda, Tirumaleswar Reddy > Cc: mohamed.boucadair@orange.com; Stephen Farrell > ; secdir@ietf.org; draft-ietf-dots-signal- > channel.all@ietf.org; ietf@ietf.org; dots@ietf.org > Subject: Re: Secdir last call review of draft-ietf-dots-signal-channel-30 >=20 >=20 > Konda, Tirumaleswar Reddy wrote: > > Stephen is referring to an attack where a compromised DOTS client > > initiates mitigation request for a target resource that is attacked= and > > learns the mitigation efficacy of the DOTS server, informs the > > mitigation efficacy to DDoS attacker to change the DDoS attack > > strategy. >=20 > Is there a word for an an infantry troup who goes behind enemy lines in o= rder > to communicate how will the artilery is? I guess a modern form is these = laser > targetted missiles, where the target is "painted". >=20 > I don't know if there are words for this kind of thing, but this would se= em to > describe the situation. >=20 > > We can add the following lines to address his comment: >=20 > > A compromised DOTS client can collude with a DDoS attacker to send > > mitigation request for a target resource, learns the mitigation > > efficacy from the DOTS server, and conveys the efficacy to the DDoS > > attacker to learn the mitigation capabilities of the DDoS mitigatio= n > > and to possibly change the DDoS attack strategy. This attack can be > > prevented by auditing the behavior of DOTS clients and authorizing = the > > DOTS client to request mitigation for specific target resources. >=20 > If a resource is already under attack, there are already mitigation reque= sts for > that target, can a compromised DOTS client leaern anything by requesting > mitigation on the same target ? I meant the scenario where the compromised DOTS client initiates the mitiga= tion request before the legitimate DOTS client sends the mitigation request= to the DOTS server. DOTS clients are typically trusted devices like Firewa= lls/IPS, DDoS mitigators/detectors. In future, application servers and endp= oints can act as DOTS clients. -Tiru >=20 > -- > Michael Richardson , Sandelman Software Works - > =3D IPv6 IoT consulting =3D- From nobody Fri Mar 15 07:06:48 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 B3D9B131259; Fri, 15 Mar 2019 07:06:40 -0700 (PDT) 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, HTML_MESSAGE=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=antoin.nl 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 WYnbgxnD7Siw; Fri, 15 Mar 2019 07:06:37 -0700 (PDT) Received: from walhalla.antoin.nl (walhalla.antoin.nl [62.251.108.8]) (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 02C84131280; Fri, 15 Mar 2019 07:06:37 -0700 (PDT) Received: by walhalla.antoin.nl (Postfix, from userid 5001) id BDFF7280474; Fri, 15 Mar 2019 15:06:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=antoin.nl; s=walhalla; t=1552658794; bh=Xg+BA6wyw3d5YIGi9rlEEH78pkyHDurXDNS8Jpf1alI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=YWdvzwr31PVdApio/j8NwZl6kWgtFUS6IM9dtiPBSWKJxqp4CbyMNW3Swsy7jWnXr 5wTqzQsgBoI9lidSgSYhInpuDB+2XnuUEJNcAJWGGe3o0dvgSv6T9VqjKofJ9IY/Kl g/Aq1SqKBkumEijehtlBStjMzGCNAI/gRhY490yQ= Received: from [IPv6:2001:985:b3c0:1:7018:41f0:aa2b:35f3] (unknown [IPv6:2001:985:b3c0:1:7018:41f0:aa2b:35f3]) by walhalla.antoin.nl (Postfix) with ESMTPSA id 359D028024D; Fri, 15 Mar 2019 15:06:32 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_9DABDF2A-DE9A-4648-9AD8-8DAF5D81E620" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Antoin Verschuren X-Priority: 3 In-Reply-To: <2019031509471945798644@cnnic.cn> Date: Fri, 15 Mar 2019 15:06:31 +0100 Cc: Russ Housley via Datatracker , "secdir@ietf.org" , "draft-ietf-regext-bundling-registration.all" , ietf , regext Message-Id: <2CF4FE5E-4A04-4ED8-AC38-32763CD3992E@antoin.nl> References: <155210908621.26593.15343460778938123458@ietfa.amsl.com> <2019031509471945798644@cnnic.cn> To: yaojk X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] [regext] Secdir last call review of draft-ietf-regext-bundling-registration-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: Fri, 15 Mar 2019 14:06:41 -0000 --Apple-Mail=_9DABDF2A-DE9A-4648-9AD8-8DAF5D81E620 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Op 15 mrt. 2019, om 02:47 heeft Jiankang Yao het = volgende geschreven: >=20 >=20 > Thanks for your kind review. > =20 > < Summary: Has Issues > < Major Concerns: > < If this document is going to be published on the IETF = Stream, then the > < IANA registrations should point to the IESG, not the = document authors. > =20 > We will update it. IANA registrations will point to the IESG. I think there is a slight misunderstanding here about the document = status and IANA registration. The EPP extension registry has 2 types of registrations: (see https://datatracker.ietf.org/doc/rfc7451/ = ) 1. EPP standard track registrations: These extensions have had thorough review and have consensus that these = are standard extensions. These EPP extensions will point to the IESG in the IANA registry (RFC = 7451 section 2.2.1) 2. Proprietary EPP extensions Extensions that seek registration in the IANA EPP extensions registry, = but are only supported by one or few registries. These extensions should be documented and one way of documenting them is = to write an informational RFC describing how the proprietary extension = works. These EPP extensions will have the Registrant information in the IANA = registry, which is NOT the IESG! draft-ietf-regext-bundling-registration is of type 2 since the REGEXT WG = could not reach consensus that this extension should become the standard = way of bundling. Hence the informational status of the document and the = Registrant should be in the IANA registration as mandated bij RFC 7451. - --=20 Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 --Apple-Mail=_9DABDF2A-DE9A-4648-9AD8-8DAF5D81E620 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Op = 15 mrt. 2019, om 02:47 heeft Jiankang Yao <yaojk@cnnic.cn> het = volgende geschreven:


Thanks = for your kind review.
 
<           Summary: Has Issues
<           Major = Concerns:
<           If = this document is going to be published on the IETF Stream, then the
<           IANA = registrations should point to the IESG, not the document = authors.

 

We will update = it. IANA = registrations will point to the IESG.


I think there is a slight misunderstanding = here about the document status and IANA registration.
The EPP extension registry has 2 types of = registrations:
(see https://datatracker.ietf.org/doc/rfc7451/)

1. EPP standard track = registrations:
These extensions have had thorough = review and have consensus that these are standard extensions.
These EPP extensions will point to the IESG in the IANA = registry (RFC 7451 section 2.2.1)

2. Proprietary EPP extensions
Extensions that seek registration in the IANA EPP extensions = registry, but are only supported by one or few registries.
These extensions should be documented and one way of = documenting them is to write an informational RFC describing how the = proprietary extension works.
These EPP extensions = will have the Registrant information in the IANA registry, which is NOT = the IESG!

draft-ietf-regext-bundling-registration is of type 2 since = the REGEXT WG could not reach consensus that this extension should = become the standard way of bundling. Hence the informational status of = the document and the Registrant should be in the IANA registration as = mandated bij RFC 7451.

- -- 
Antoin = Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 = 37682392



= --Apple-Mail=_9DABDF2A-DE9A-4648-9AD8-8DAF5D81E620-- From nobody Fri Mar 15 11:52: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 84B6D130E86 for ; Fri, 15 Mar 2019 11:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.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 r79QwTYQkkTu for ; Fri, 15 Mar 2019 11:52:43 -0700 (PDT) Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) (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 B8761130E89 for ; Fri, 15 Mar 2019 11:52:43 -0700 (PDT) Received: by mail-qt1-x843.google.com with SMTP id h39so11290661qte.2 for ; Fri, 15 Mar 2019 11:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=vKJyHBFmH3ZLMY70Yql21kR3cBYbJSVfQ0yWqP4Udp0=; b=DgeWNQY1ZM1NxdsX5aZBthMklIxHIcOdQfREugky1LDCpj5KhDE1rKRcyMhdNIQJ87 IsxKMcu2XuiMDoT3YPIIuBUcAe+/6kO2Tq30jdnL4YvYJK2tL3lONhnYN2e/4mD6tIVN nhpL+396LsJS2qBqHbsp6Q+uJphXslDIP1hD99Q2dUHtI/cI+F57H99LUXBXXBN/ppVY 8H6VH8FoNs60gAseQXbUht72h/fqIWlTg+4d78S9gkIRfnZtI5CBT5vT6a/oHtCym/uO M+uXhjXyXJXMFkN+sWrzXtl5rNKk2ZpRnkuuD8MRhBXQlMznTPHhZZRdkwefz/Wg3feJ RGwQ== 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=vKJyHBFmH3ZLMY70Yql21kR3cBYbJSVfQ0yWqP4Udp0=; b=jXLzip9NOI2b+YZO1AVGlOoWNDvLaUd7BoofVEPCx5Dg6AJ6efYAMfgX2AKUW6yGJw X1e5uVnhtMrQBb4PepOAgoEqsHcyt5KU8bNC/T3xbW2bmUsrUzSCjHlsMiZn0r5w3fKl NmSr4XfNswbOu4VdV6pqHkNfUFIVyByp94hyMWyKeAWkn/NXvRfpHIHToeMztqam8hFe IA3t/KFermoAcX1E+6ZDDcl6FoXGIgqGvGI/sAfrJrkS8Xn98RyNo3Tpf6IjHVLc/STL 4tQQYsDtYieVrKJb4bMFDAYkqpBs92VSOo5sCk48hYAQMPkiQmgRftNEipxp+7ac5Q/2 8/+g== X-Gm-Message-State: APjAAAX7/rRbkugF77afRZ3OZ7XbII34zFQFYfSbPxk1X9V+nln4WVNL HyPUON8R9u6fSjlk8n30pL9XvWX3020= X-Google-Smtp-Source: APXvYqzu8L2HVRPkYs21RNKmpYBMXylCYJt7Q6P2UGkUDA2OoCYOoOdMVvmGUVvFMN0fGRILDeFJHw== X-Received: by 2002:ac8:21bc:: with SMTP id 57mr2113629qty.51.1552675962149; Fri, 15 Mar 2019 11:52:42 -0700 (PDT) Received: from ?IPv6:2601:152:4400:4013:15bf:7fe9:5be3:d288? ([2601:152:4400:4013:15bf:7fe9:5be3:d288]) by smtp.gmail.com with ESMTPSA id u64sm2980851qki.24.2019.03.15.11.52.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Mar 2019 11:52:41 -0700 (PDT) To: Richard Barnes Cc: John Mattsson , "Blumenthal, Uri - 0553 - MITLL" , CFRG , "RFC ISE (Adrian Farrel)" , secdir References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> From: Michael StJohns Message-ID: <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> Date: Fri, 15 Mar 2019 14:52:40 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 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] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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, 15 Mar 2019 18:52:46 -0000 On 3/13/2019 7:32 AM, Richard Barnes wrote: > Mike, are your concerns here primarily IPR related?  If that's so, > then maybe that's the level at which we should address them, as > opposed to flipping the bigger RG->WG switch. > Hi Richard - Like I said, I'm not going to push this at this time.  But I think its more than just IPR - avoiding technology because of IPR is more a symptom (and in fact is IETF guidance rather than IRTF policy). The CFRG has a unique position in that - unlike ANY other RG as far as I can tell - it's looked at as an immediate feeder for technology for the IETF.  If it were agnostically evaluating the crypto properties of any offered technology, I'd say we're good and I'd move on.  But, with the publication of Curve25519 and its related ... standards ..., the CFRG has moved from evaluation and re-publication of cryptographic standards developed and produced elsewhere into being the first publisher of what could only be characterized as standards, even if published as an Informational RFC in the IRTF stream. Ultimately, I think it comes down to fairness and transparency. As an RG, the publications of the RG are not subject to the standards appeals process.  In an WG, the decision not to work on an IPR encumbered technology (or others such as national cryptography) MAY be appealed and overturned (or might not) or sponsored by an AD if there's no applicable or agreeable WG. There's a process for showing such decisions were made transparently, and with a broader audience than just the CFRG having a say. Later, Mike Ps - hmm... Note that the CFRG charter only mentions the IETF and not the IRTF.... From nobody Sat Mar 16 02:36:18 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 C4C30127970 for ; Sat, 16 Mar 2019 02:36:15 -0700 (PDT) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wallan-se.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 6-CaPwtrYx4v for ; Sat, 16 Mar 2019 02:36:13 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 3CDBF127598 for ; Sat, 16 Mar 2019 02:36:11 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id a17so9980409ljd.4 for ; Sat, 16 Mar 2019 02:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wallan-se.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OHJkbuUDTpbVNlXEs083cPx9DUwTqOm6RaQ3NhzNSz8=; b=OsScMeC3Btp0p3pj6nM+dFxr7HIHAxvIoI9SJUW1xaRv6kAv1qC8ybUiFqqK2BenSp NFFuyvqKEbwGus5bd6KzQldWGi6l1JxrnwowWHp23pLzmdywQh9bqruq904LlOJWS159 JdYS97N21gl5Yav3H+O0RaynMLBtPeC9Bh0s8cPgWZjSM4gi1G7LKy8hEr1cdTpdDTkd pF+sRJZrl+89pMVMNLhCYouyrjdaz2T6GsrzUic9nWvzIhvJtaMfVJPptsjZCHihgn7H 1slbf8BrP3DVDXT6+JK2G7X+v2SW6tQiS1W78TDaxgXyDFXRnQBNSolAMZwP0I6MEYD/ cYsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=OHJkbuUDTpbVNlXEs083cPx9DUwTqOm6RaQ3NhzNSz8=; b=AsTom+ZKnKp8jmhgOea0IfpHFmcdq1+dg+VFUv0qsWn4XrhOE7IO7WKw4O2kboUBVF IDOwCjJJwW8asugN0rrayvVjZhn6maGO6/z4bG+qMojMztiBenu6VTICcl3NS85kn60s jgV7ahFE2aECVFVklAuNngIgNLm+LoBhONaXPvaXP9ZmL+molvw0x2WcQGqx0fVMyNE4 Lnk5yVQ/4fpLr/itayRfalesT8N2ovMjk+dicWhuVTKXlnp5+32Y5vJVyahiFEI2wMWP 0Y23KU7mLfFXvXj19vgdhGZGajQl2HyfsSxL0xFsYx0LE6ZzZjQGPTXm24xeVir1yzCI Ve7w== X-Gm-Message-State: APjAAAVjeBCv1YCIVIT9DzjPsRxmqKEOtatzz30EOoa8KrTfc33Lui4J eCJSLiRAmm5/FMyhywT9SLSF2w== X-Google-Smtp-Source: APXvYqz/X5sGX10xe+JvvnMCh+/FhzEllf6F/7aaLWFJGP0AR0XoMC/pejFZuVMkLi9Cp3VIescfRw== X-Received: by 2002:a2e:9594:: with SMTP id w20mr4713679ljh.173.1552728970108; Sat, 16 Mar 2019 02:36:10 -0700 (PDT) Received: from [192.168.72.11] (h95-155-237-105.cust.a3fiber.se. [95.155.237.105]) by smtp.gmail.com with ESMTPSA id a22sm904022lfg.37.2019.03.16.02.36.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Mar 2019 02:36:09 -0700 (PDT) From: stefan vallin Message-Id: <33D6DF4B-883B-46A4-B412-7AA87CE58ECA@wallan.se> Content-Type: multipart/alternative; boundary="Apple-Mail=_200113A8-1F63-40F3-9D5A-F03CECBBAB2C" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Sat, 16 Mar 2019 10:36:06 +0100 In-Reply-To: Cc: secdir@ietf.org, draft-ietf-ccamp-alarm-module.all@tools.ietf.org To: Shawn Emery References: X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [secdir] Review of draft-ietf-ccamp-alarm-module-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: Sat, 16 Mar 2019 09:36:16 -0000 --Apple-Mail=_200113A8-1F63-40F3-9D5A-F03CECBBAB2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks Shawn! Next version will include fixes to your comments /s > On 14 Mar 2019, at 06:45, Shawn Emery wrote: >=20 > Reviewer: Shawn M. Emery > Review result: Ready with nits >=20 > 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. >=20 > This draft specifies a YANG module for the purpose of network device = alarm management. >=20 > The security considerations section does exist and follows the = yang-security-guidelines. > I believe the data nodes and operations of concern are covered in this = section, but it seems > that alarm-profiles could also be sensitive if an attacker were to = downgrade the severity of > an alarm by changing the alarm-severity-assignment-profile. >=20 > General comments: >=20 > None. >=20 > Editorial comments: >=20 > s/northbound/north-bound/ > s/definition also focus/definition also focuses/ > s/an hierarchy/a hierarchy/ > s/raised again etc/raised again, etc/ > s/sent Notifications/sent. Notifications/ > s/alarn/alarm/ > s/The NETCONF access control model/The Network Configuration Access = Control Model (NACM)/ > s/notify-status-change:/notify-status-changes:/ >=20 > OLD: > This leaf controls whether an alarm should notify only raise and clear = or all severity level > changes. Unauthorized access to leaf could have a negative impact on = operational procedures > relying on fine-grained alarm state change reporting. >=20 > NEW: > This leaf controls whether an alarm should notify based on various = state changes. Unauthorized > access to this leaf could have a negative impact on operational = procedures relying on > fine-grained alarm state change reporting. >=20 > Shawn. > -- --Apple-Mail=_200113A8-1F63-40F3-9D5A-F03CECBBAB2C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thanks Shawn!
Next version will include fixes = to your comments
/s


On 14 Mar 2019, at 06:45, Shawn Emery <shawn.emery@gmail.com> 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 module = for the purpose of network device alarm management.

The security considerations = section does exist and follows the yang-security-guidelines.
I believe the data nodes and operations of = concern are covered in this section, but it seems
that alarm-profiles could also be sensitive if an attacker = were to downgrade the severity of
an = alarm by = changing the alarm-severity-assignment-profile.

General comments:

None.

Editorial = comments:

s/northbound/north-bound/
s/definition also focus/definition = also focuses/
s/an hierarchy/a hierarchy/
s/raised again etc/raised again, = etc/
s/sent Notifications/sent.  = Notifications/
s/alarn/alarm/
s/The NETCONF = access control model/The Network Configuration Access Control Model = (NACM)/
s/notify-status-change:/notify-status-changes:/

OLD:
This leaf controls whether = an alarm should = notify only raise and clear or all severity level
changes.  = Unauthorized access to leaf could have a negative = impact on = operational procedures
relying on fine-grained alarm = state change = reporting.

NEW:
This leaf controls whether an alarm should notify based on = various state = changes.  Unauthorized
access to this leaf could have a = negative impact on= operational procedures relying on
fine-grained alarm = state change = reporting.

Shawn.
--
=

= --Apple-Mail=_200113A8-1F63-40F3-9D5A-F03CECBBAB2C-- From nobody Sat Mar 16 04:31:18 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 EF8161277C9 for ; Sat, 16 Mar 2019 04:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=unavailable 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 HPnQp78Uw8AY for ; Sat, 16 Mar 2019 04:31:15 -0700 (PDT) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA6812423B for ; Sat, 16 Mar 2019 04:31:15 -0700 (PDT) Received: from CAS20.d.ethz.ch (172.31.51.110) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.439.0; Sat, 16 Mar 2019 12:30:05 +0100 Received: from MBX117.d.ethz.ch ([fe80::c1d4:d225:fabf:1974]) by CAS20.d.ethz.ch ([fe80::2cd8:4907:7776:c56d%10]) with mapi id 14.03.0439.000; Sat, 16 Mar 2019 12:30:01 +0100 From: "Paterson Kenneth" To: Michael StJohns , Richard Barnes CC: secdir , CFRG , "RFC ISE (Adrian Farrel)" Thread-Topic: [Cfrg] Time to recharter CFRG as a working group? Was: Re: [secdir] ISE seeks help with some crypto drafts Thread-Index: AQHU15MqFmRhH7D8Pkm+dJStft64bKYFdNCAgAB9bQCAAlh9AIAAHb0AgAD4b4CAA5+3AIABFZaA Date: Sat, 16 Mar 2019 11:30:00 +0000 Message-ID: <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> In-Reply-To: <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> Accept-Language: de-CH, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.139.4] Content-Type: text/plain; charset="utf-8" Content-ID: <6EAD34D8800A6844AE607CE481A46818@intern.ethz.ch> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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, 16 Mar 2019 11:31:17 -0000 RGVhciBNaWtlLA0KDQpUaGFua3MgZm9yIHNwYXJraW5nIHRoaXMgZGlzY3Vzc2lvbiAoYW5kIHRo YW5rcyB0byBldmVyeW9uZSBlbHNlIGZvciBlbmdhZ2luZykuIFRoZSBjaGFpcnMgaGF2ZSBiZWVu IGZvbGxvd2luZyB3aXRoIGludGVyZXN0LCBhbmQgaGF2ZSB3ZWxjb21lZCB0aGUgb3Bwb3J0dW5p dHkgZm9yIHF1ZXN0aW9ucyBhYm91dCB0aGUgZnV0dXJlIGNvbnN0aXR1dGlvbiBvZiBDRlJHIHRv IGJlIGFpcmVkLg0KDQpUaGUgcm91Z2ggY29uc2Vuc3VzIG9mIHRob3NlIHdobyBqb2luZWQgdGhl IGRpc2N1c3Npb24gaXMgdGhhdCB3ZSBzaG91bGQgbGVhdmUgdGhlIHN0YXR1cyBvZiBDRlJHIGFz IGl0IGlzIGZvciBub3cuIA0KDQpPZiBjb3Vyc2UsIHRoaXMga2luZCBvZiBxdWVzdGlvbiBjYW4g YW5kIHNob3VsZCBiZSByZXZpc2l0ZWQgaW4gZnV0dXJlLiBUcmlnZ2VycyBmb3IgdGhhdCBtaWdo dCBpbmNsdWRlOiB0aGUgd29ya2xvYWQgb2YgdGhlIFJHIGluY3JlYXNlcyBzaWduaWZpY2FudGx5 OyBhIHNwYXRlIG9mIElQUiBpc3N1ZXMgYXJpc2VzOyAgdGhlIG5hdHVyZSBvZiB0aGUgd29yayBi ZWluZyBkb25lIGluIHRoZSBSRyBjaGFuZ2VzIGZ1cnRoZXIuIChUaGlzIGxpc3QgaXMgaW50ZW5k ZWQgdG8gYmUgaWxsdXN0cmF0aXZlIHJhdGhlciB0aGFuIGV4aGF1c3RpdmUuKSBBdCBzdWNoIGEg cG9pbnQsIHdlIGNhbiBkaXNjdXNzIGFnYWluIGFuZCBpbnZva2UgdGhlIGZvcm1hbCBwcm9jZWR1 cmVzIG9mIHRoZSBJUlRGIGFuZCBJRVRGIHRvIGVmZmVjdCBjaGFuZ2VzLg0KDQpSZWdhcmRzLA0K DQpLZW5ueSAoZm9yIHRoZSBjaGFpcnMpDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBDZnJnIDxjZnJnLWJvdW5jZXNAaXJ0Zi5vcmc+IG9uIGJlaGFsZiBvZiBNaWNoYWVs IFN0Sm9obnMgPG1zakBudGhwZXJtdXRhdGlvbi5jb20+DQpEYXRlOiBGcmlkYXksIDE1IE1hcmNo IDIwMTkgYXQgMTg6NTMNClRvOiBSaWNoYXJkIEJhcm5lcyA8cmxiQGlwdi5zeD4NCkNjOiBzZWNk aXIgPHNlY2RpckBpZXRmLm9yZz4sICJjZnJnQGlydGYub3JnIiA8Y2ZyZ0BpcnRmLm9yZz4sICJS RkMgSVNFIChBZHJpYW4gRmFycmVsKSIgPHJmYy1pc2VAcmZjLWVkaXRvci5vcmc+DQpTdWJqZWN0 OiBSZTogW0NmcmddIFRpbWUgdG8gcmVjaGFydGVyIENGUkcgYXMgYSB3b3JraW5nIGdyb3VwPyBX YXM6IFJlOiBbc2VjZGlyXSBJU0Ugc2Vla3MgaGVscCB3aXRoIHNvbWUgY3J5cHRvIGRyYWZ0cw0K DQogICAgT24gMy8xMy8yMDE5IDc6MzIgQU0sIFJpY2hhcmQgQmFybmVzIHdyb3RlOg0KICAgID4g TWlrZSwgYXJlIHlvdXIgY29uY2VybnMgaGVyZSBwcmltYXJpbHkgSVBSIHJlbGF0ZWQ/ICBJZiB0 aGF0J3Mgc28sIA0KICAgID4gdGhlbiBtYXliZSB0aGF0J3MgdGhlIGxldmVsIGF0IHdoaWNoIHdl IHNob3VsZCBhZGRyZXNzIHRoZW0sIGFzIA0KICAgID4gb3Bwb3NlZCB0byBmbGlwcGluZyB0aGUg YmlnZ2VyIFJHLT5XRyBzd2l0Y2guDQogICAgPg0KICAgIA0KICAgIEhpIFJpY2hhcmQgLQ0KICAg IA0KICAgIExpa2UgSSBzYWlkLCBJJ20gbm90IGdvaW5nIHRvIHB1c2ggdGhpcyBhdCB0aGlzIHRp bWUuICBCdXQgSSB0aGluayBpdHMgDQogICAgbW9yZSB0aGFuIGp1c3QgSVBSIC0gYXZvaWRpbmcg dGVjaG5vbG9neSBiZWNhdXNlIG9mIElQUiBpcyBtb3JlIGEgDQogICAgc3ltcHRvbSAoYW5kIGlu IGZhY3QgaXMgSUVURiBndWlkYW5jZSByYXRoZXIgdGhhbiBJUlRGIHBvbGljeSkuDQogICAgDQog ICAgVGhlIENGUkcgaGFzIGEgdW5pcXVlIHBvc2l0aW9uIGluIHRoYXQgLSB1bmxpa2UgQU5ZIG90 aGVyIFJHIGFzIGZhciBhcyBJIA0KICAgIGNhbiB0ZWxsIC0gaXQncyBsb29rZWQgYXQgYXMgYW4g aW1tZWRpYXRlIGZlZWRlciBmb3IgdGVjaG5vbG9neSBmb3IgdGhlIA0KICAgIElFVEYuICBJZiBp dCB3ZXJlIGFnbm9zdGljYWxseSBldmFsdWF0aW5nIHRoZSBjcnlwdG8gcHJvcGVydGllcyBvZiBh bnkgDQogICAgb2ZmZXJlZCB0ZWNobm9sb2d5LCBJJ2Qgc2F5IHdlJ3JlIGdvb2QgYW5kIEknZCBt b3ZlIG9uLiAgQnV0LCB3aXRoIHRoZSANCiAgICBwdWJsaWNhdGlvbiBvZiBDdXJ2ZTI1NTE5IGFu ZCBpdHMgcmVsYXRlZCAuLi4gc3RhbmRhcmRzIC4uLiwgdGhlIENGUkcgDQogICAgaGFzIG1vdmVk IGZyb20gZXZhbHVhdGlvbiBhbmQgcmUtcHVibGljYXRpb24gb2YgY3J5cHRvZ3JhcGhpYyBzdGFu ZGFyZHMgDQogICAgZGV2ZWxvcGVkIGFuZCBwcm9kdWNlZCBlbHNld2hlcmUgaW50byBiZWluZyB0 aGUgZmlyc3QgcHVibGlzaGVyIG9mIHdoYXQgDQogICAgY291bGQgb25seSBiZSBjaGFyYWN0ZXJp emVkIGFzIHN0YW5kYXJkcywgZXZlbiBpZiBwdWJsaXNoZWQgYXMgYW4gDQogICAgSW5mb3JtYXRp b25hbCBSRkMgaW4gdGhlIElSVEYgc3RyZWFtLg0KICAgIA0KICAgIFVsdGltYXRlbHksIEkgdGhp bmsgaXQgY29tZXMgZG93biB0byBmYWlybmVzcyBhbmQgdHJhbnNwYXJlbmN5LiBBcyBhbiANCiAg ICBSRywgdGhlIHB1YmxpY2F0aW9ucyBvZiB0aGUgUkcgYXJlIG5vdCBzdWJqZWN0IHRvIHRoZSBz dGFuZGFyZHMgYXBwZWFscyANCiAgICBwcm9jZXNzLiAgSW4gYW4gV0csIHRoZSBkZWNpc2lvbiBu b3QgdG8gd29yayBvbiBhbiBJUFIgZW5jdW1iZXJlZCANCiAgICB0ZWNobm9sb2d5IChvciBvdGhl cnMgc3VjaCBhcyBuYXRpb25hbCBjcnlwdG9ncmFwaHkpIE1BWSBiZSBhcHBlYWxlZCBhbmQgDQog ICAgb3ZlcnR1cm5lZCAob3IgbWlnaHQgbm90KSBvciBzcG9uc29yZWQgYnkgYW4gQUQgaWYgdGhl cmUncyBubyBhcHBsaWNhYmxlIA0KICAgIG9yIGFncmVlYWJsZSBXRy4gVGhlcmUncyBhIHByb2Nl c3MgZm9yIHNob3dpbmcgc3VjaCBkZWNpc2lvbnMgd2VyZSBtYWRlIA0KICAgIHRyYW5zcGFyZW50 bHksIGFuZCB3aXRoIGEgYnJvYWRlciBhdWRpZW5jZSB0aGFuIGp1c3QgdGhlIENGUkcgaGF2aW5n IGEgc2F5Lg0KICAgIA0KICAgIA0KICAgIExhdGVyLCBNaWtlDQogICAgDQogICAgUHMgLSBobW0u Li4gTm90ZSB0aGF0IHRoZSBDRlJHIGNoYXJ0ZXIgb25seSBtZW50aW9ucyB0aGUgSUVURiBhbmQg bm90IA0KICAgIHRoZSBJUlRGLi4uLg0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQogICAgQ2ZyZyBtYWlsaW5nIGxpc3QNCiAgICBDZnJn QGlydGYub3JnDQogICAgaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZnJn DQogICAgDQoNCg== From nobody Sun Mar 17 02:25:36 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 1E4B712AF83 for ; Sun, 17 Mar 2019 02:25:29 -0700 (PDT) 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 9ngtZc7qZdP7 for ; Sun, 17 Mar 2019 02:25:26 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 9240D127978 for ; Sun, 17 Mar 2019 02:25:26 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44MYnb2X5xz313; Sun, 17 Mar 2019 10:25:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1552814723; bh=+lPudWBrWLJZa7z7LpxIkdQj29MD3SWL5KnzJsMcjts=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=XiLpfVof/LZUF/iXP1RXgaLp4oepGFUw997IJSEjsPhffOvRIBK4qzkS0/Q+dc3Uu /TzA5sO9og4xK+VihK5M+aLqmvisGSwDkeAzL27i/YNhPqNxbQXkMRhK7PEBNxvDm/ HPz0+GNOBnWDccnxUBsw4IxNO0m1pQO+q9/YA0Ew= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id c3UonG61Zvgt; Sun, 17 Mar 2019 10:25:22 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 17 Mar 2019 10:25:22 +0100 (CET) Received: from [192.168.1.131] (unknown [185.8.185.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 42A5631941D; Sun, 17 Mar 2019 05:25:21 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 42A5631941D Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16D57) In-Reply-To: <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> Date: Sun, 17 Mar 2019 10:25:19 +0100 Cc: Michael StJohns , Richard Barnes , CFRG , "RFC ISE (Adrian Farrel)" , secdir Content-Transfer-Encoding: quoted-printable Message-Id: References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> To: Paterson Kenneth Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 09:25:29 -0000 > On Mar 16, 2019, at 12:30, Paterson Kenneth w= rote: > The rough consensus of those who joined the discussion is that we should l= eave the status of CFRG as it is for now.=20 I wasn=E2=80=99t aware we were gathering consensus already and thought we we= re just having a discussion. So seeing this cut short all of a sudden with a= tally seems wrong to me. So for consensus, I think that what CFRG is doing matches a WG more than an R= G, and it would be more formally correct to change it. Paul From nobody Sun Mar 17 05:10: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 43F50129A87 for ; Sun, 17 Mar 2019 05:10:50 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 dmXb8C1aUk3m for ; Sun, 17 Mar 2019 05:10:45 -0700 (PDT) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) (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 6CCD41275E9 for ; Sun, 17 Mar 2019 05:10:45 -0700 (PDT) Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-3.mit.edu (8.14.7/8.12.4) with ESMTP id x2HCAnff006813; Sun, 17 Mar 2019 08:10:51 -0400 Received: from W92EXHUB11.exchange.mit.edu (18.7.73.20) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Sun, 17 Mar 2019 08:10:26 -0400 Received: from OC11EXPO28.exchange.mit.edu ([169.254.1.251]) by W92EXHUB11.exchange.mit.edu ([18.7.73.20]) with mapi id 14.03.0439.000; Sun, 17 Mar 2019 08:10:40 -0400 From: Uri Blumenthal To: Paul Wouters CC: Paterson Kenneth , secdir , CFRG , "RFC ISE (Adrian Farrel)" , Michael StJohns Thread-Topic: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts Thread-Index: AQHU15pu4C8HN59tNkSSeRcv6kg8BqYGRgAAgAJYfQCAAB29AIAA+HCAgAOftgCAARanAIABb3+AgAAuMwA= Date: Sun, 17 Mar 2019 12:10:40 +0000 Message-ID: <679B6759-5AD3-4F28-9EF4-8794F383468B@mit.edu> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-6CD442D2-EDB4-4C56-89D6-4FA7193ADF8D"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 12:10:50 -0000 --Apple-Mail-6CD442D2-EDB4-4C56-89D6-4FA7193ADF8D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SWYgQ0ZSRyBpcyBkb2luZyB3aGF0IGEgV0cgaXMgc3VwcG9zZWQgdG8gLSB3aGF0J3MgdGhlIHBy b2R1Y3QgaXMgc3VwcG9zZWQgdG8gcHJvZHVjZSwgd2hhdCBhcmUgdGhlIG1pbGVzdG9uZXMsIGFu ZCB3aGVuIGlzIGl0IHN1cHBvc2VkIHRvIHdpbmQgZG93biwgYXMgYW55IG5vcm1hbCBXRyBzaG91 bGQgd2hlbiBpdCdzIGRvbmUgdGhlIGpvYiBpdCB3YXMgY2hhcnRlcmVkIGZvcj8NCg0KU2VudCBm cm9tIG15IHRlc3QgaVBob25lDQoNCj4gT24gTWFyIDE3LCAyMDE5LCBhdCAwNToyNSwgUGF1bCBX b3V0ZXJzIDxwYXVsQG5vaGF0cy5jYT4gd3JvdGU6DQo+IA0KPiANCj4+PiBPbiBNYXIgMTYsIDIw MTksIGF0IDEyOjMwLCBQYXRlcnNvbiBLZW5uZXRoIDxrZW5ueS5wYXRlcnNvbkBpbmYuZXRoei5j aD4gd3JvdGU6DQo+PiANCj4+IFRoZSByb3VnaCBjb25zZW5zdXMgb2YgdGhvc2Ugd2hvIGpvaW5l ZCB0aGUgZGlzY3Vzc2lvbiBpcyB0aGF0IHdlIHNob3VsZCBsZWF2ZSB0aGUgc3RhdHVzIG9mIENG UkcgYXMgaXQgaXMgZm9yIG5vdy4gDQo+IA0KPiBJIHdhc27igJl0IGF3YXJlIHdlIHdlcmUgZ2F0 aGVyaW5nIGNvbnNlbnN1cyBhbHJlYWR5IGFuZCB0aG91Z2h0IHdlIHdlcmUganVzdCBoYXZpbmcg YSBkaXNjdXNzaW9uLiBTbyBzZWVpbmcgdGhpcyBjdXQgc2hvcnQgYWxsIG9mIGEgc3VkZGVuIHdp dGggYSB0YWxseSBzZWVtcyB3cm9uZyB0byBtZS4NCj4gDQo+IFNvIGZvciBjb25zZW5zdXMsIEkg dGhpbmsgdGhhdCB3aGF0IENGUkcgaXMgZG9pbmcgbWF0Y2hlcyBhIFdHIG1vcmUgdGhhbiBhbiBS RywgYW5kIGl0IHdvdWxkIGJlIG1vcmUgZm9ybWFsbHkgY29ycmVjdCB0byBjaGFuZ2UgaXQuDQo+ IA0KPiBQYXVsDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gc2VjZGlyIG1haWxpbmcgbGlzdA0KPiBzZWNkaXJAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXINCj4gd2lraTogaHR0 cDovL3Rvb2xzLmlldGYub3JnL2FyZWEvc2VjL3RyYWMvd2lraS9TZWNEaXJSZXZpZXcNCg== --Apple-Mail-6CD442D2-EDB4-4C56-89D6-4FA7193ADF8D Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCGsw ggQkMIICjKADAgECAgRbkXGgMA0GCSqGSIb3DQEBDAUAMBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBS U0EgNDAeFw0xODA5MDYxODI3NDRaFw0yMTA5MDYxODI3NDRaMA4xDDAKBgNVBAMMA1VyaTCCAaIw DQYJKoZIhvcNAQEBBQADggGPADCCAYoCggGBANJi8+lfrSCcWThbn0vQzXsW7AYTyTZSo/pv/274 xD/t1rpn/X/vegP2lSfr+SRJ4oJ+51MFJvRl/sAveroDN8gGrFyYaCg5ZsOMqksCmLha4Ttgk04L I/aqrPGuzF1OVgjhi6WrnFr80KS6sy3MWzYIYV6G1FycKEup5snMr1B1WWzFKOwSslnJwvCuHu2W Tc5OzJKPtxMcDIS9y6VOZTzsJUFe0bRiw0LICDBcB3fgKCvYMcDfke0pw13I4O7wEG40s9E6rTIj Q0H1LVk69pSo1ikzpikl5W8pXUQQrSmjHqhFn/Q+PwSzHSOralN0p1UMziUv57lgvvZbTaH1ooqq MZBuTed0xLye3w+h9+/iqDY4B7lFqbegzseBh7/Q6KdtfpkwwI7xSpZEME/V77KAMw+ipb+Itbij Bi3r/t81fDW8eitIAbVtalpFROlYIaZnIIohOZRyVjn2unZ+lj3jDKsDq53g+oleo+Ruszlt8nju 6uKhzE7bdX1xJuvCtwIDAQABo34wfDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFIDAWBgNV HREEDzANgQt1cmlAbWl0LmVkdTAdBgNVHQ4EFgQU2p+nwSyQFM6byFBhc7oIZephJbcwJQYDVR0l BB4wHAYIKwYBBQUHAwQGCisGAQQBgjcKAwQGBFUdJQAwDQYJKoZIhvcNAQEMBQADggGBAH/zzG9P gU+ogFbc75JpUK0amUUtmtSsGDe4599GolCDiuPHrnbCGcaNc9aQjRaP3Q3aU7BB3aOjwssjQSN0 tsfZD8p+XPny/odhDSwS/25jCg0dVasd8q+Jd1S1g34RGUqPQ+5ofTrBSEkHBdLdJOnxBGo9GRzA yiDg34r6zK6BXNYv2GdqRk+GGGvL/w3CDR+ih36ZDBxw/EO19oH/aV4+mVlcRI6aoj4KMb+h4zMY S8jLDArIZSce4EWzJqxKVcX6Q7CE/0Br/7R8Ixs+vt5YKPUVpEbFM6koH624GDQYKM2kzXBnwYgS /jvl02KUx6uNmIgo+ufK2l7sc83vRLxBTJKhT0/USVkwu9uzg2zHJeGBZ4pmDhkIVkGcamW7KPYZ dgOz8zAOy8Ntk7GebPn85XuPcQS9UntdO61X1EyEXg4Ixl/qapidfJQfdCqEeZZXpaV3WKWE8u1l fNB00mC0/xhG3bikQxl3O20nyPjXvl6VZFzglsPRy1Xh5L//rzCCBD8wggKnoAMCAQICBFuRckIw DQYJKoZIhvcNAQEMBQAwGjEYMBYGA1UEAwwPRm9yZXN0IENBIFJTQSA0MB4XDTE4MDkwNjE4MzAy NloXDTIxMDkwNjE4MzAyNlowDjEMMAoGA1UEAwwDVXJpMIIBojANBgkqhkiG9w0BAQEFAAOCAY8A MIIBigKCAYEAtZvms8stf9xj5w7pjYzgmHe7TH0eX/q3buMBqdLufhFuqCizZPhXJmSbue8WHm8H HO7SHQPUqIqbPOMIQfAL8nwWhuTfsN5nrtFW77eiNsEexRNkbhw/U6RzamCGl6xQmUxOD0nabEmd Xdces+rjtzlvjpNHI7xrR32ee4JuGTjwAWlAHPtBC8TqiOR/ysR2K2umk5BkjCEWV9kDfGklfKmu IhuCzzpTvN3AnLMX9kP9IY6E9B8OsLOhkOFBbAMzyqkXibtPWluqOnYW3V3MVc9H1ir6sGLF5onW lHLEorI51WuHlfVO8WJRYwhrzQIIAWAYheZaH2wdb87Kw6o4JbHDLTDJHHrBDwfqa5OtFTeQNWCD JPdHa4xfFpjnMTzP18POa5C6QN5XBpTFsfccWyEdt+ykGB2FMzhB3GgMVRfWPgo8TgxVwU9MHt8s vmxj8KMUd7afSJBOjMIRPZ6gi8Vja9SR9+Hj/YWgpKZMHhI7irJVpWF++7hhfxxDbgDBAgMBAAGj gZgwgZUwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0RBA8wDYELdXJpQG1pdC5l ZHUwHQYDVR0OBBYEFK3WLENy4CH330dGZEWchN+L1r28MD4GA1UdJQQ3MDUGCCsGAQUFBwMCBggr BgEFBQcDAwYKKwYBBAGCNwoDDAYJKoZIhvcvAQEFBggrBgEFBQcDBDANBgkqhkiG9w0BAQwFAAOC AYEACYbThcFo+JTQNP5UacMtYogWU/yOx5GBLSNNa5cpvoRrOJc9CUDfzfnrd7IhDLXvnFUYNt3i oyU13LKRoPsp/YYuZ2CBI1om9g27SSqqEcOom0eojIKkPNw+sJzYVl7Dz2I7f9DHN6nEC9BeT8Do rjuq67UOlZZw0YvlvCmtMI4xJ7CUM8NrphoeRN18OnbwmkHWIYnYwdxipTJ8oLWi5EbKaUEYyLlC JWd6o9vH8cFNzsViPUl9POxBtX++o5KxtW7/JQwrQt3uFubF6rHQag6HDeXcXSyI0DmL8MrfVtHi Ma2bN+7z8N9Wnuvx8v0qlqfwd+uhmP7OvD32PuzjQxuGyPd43DZazlMhY9IRpSSCPhdbxzS3YwKr jnTZlKGwPiYCmiQ0XSEW3K64Exe4t+jrkBReocr9ccslB4d4XhxQPdAvUdI43xGMbnFea7pyTDyP b0z1vMrYt6dAguU0QTgRZsPFoIldK70ILvncq9amhxuQ4Uw+u2WUXiYba2R1MYICoTCCAp0CAQEw IjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRckIwDQYJYIZIAWUDBAIBBQCggdEwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwMzE3MTIxMDQwWjAvBgkq hkiG9w0BCQQxIgQgqhHChXm/Y0rMpj5FqjCEqawSoCiKF4I5ZiUHgvxDriMwMQYJKwYBBAGCNxAE MSQwIjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRcaAwMwYLKoZIhvcNAQkQAgsxJKAi MBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBSU0EgNAIEW5FxoDANBgkqhkiG9w0BAQEFAASCAYCh8CED 3X9acmttsjlzv2OqgAYbYDPRZUjhdA5ZfvHvvXH3jxdMFCB8oy4OQ2+d142r/Jx8CJLWdxohIY4C IMK0CRpbIQqnYLYpziYt0e3zSZGFVlncXxRy5mhkQxR8ZDgJTKC0uGTeTwLbP+Jgznnf/PC71ear ZzA21wtJ99o6JxxyacDrX9EHaqrwDQ1s+ubHVw+/bstzd0nhmA8ZvmcLGbRswZnztR2EqC5ZFtxb WIBZyzFMnvuvEp+OeqAhsRd+12dqa0YQHQgsU/0JBvY5rCMhr7vXYuL9Itin8M+rV5W7C+FRLqxz w8imcT+d0HL0ANfgmJgcnOpXdnMuDKv1KWebCaBaFlCoZWyMLRJG6JGJVzpgQGAEmSbVRpKbs6dl g7vvGL2PHth6JmqPRBmd9qTs5LvGVulZXng0ibCFFRpLti3WEvb2f8D88oVGpFcikrRmXZ2fPlz3 XD16l6i9fznCoOnjM3f2dBeeo9z+nfEcW/bUkInUWZ1XXfXBoYgAAAAAAAA= --Apple-Mail-6CD442D2-EDB4-4C56-89D6-4FA7193ADF8D-- From nobody Sun Mar 17 06:39: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 B0D281279E6 for ; Sun, 17 Mar 2019 06:39:17 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 Fzv8KmDMvdXc for ; Sun, 17 Mar 2019 06:39:16 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 DC7451277DE for ; Sun, 17 Mar 2019 06:39:15 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id j10so10923206oij.13 for ; Sun, 17 Mar 2019 06:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F3mbRpSnAYd0G9DRd+YbI6xhVtJoXUfXjriB5cNlw5w=; b=ZrRwddJPL6gqOID4CYxMLttELfLRY/5tfNL1d3s2OO94qVEdsHaRHq1oGoky6gazm8 XBkpjs5qVvFuxmnocRd1Czwn5MMSXYhWFxI63kvJ1k35oOTvpvBolMPwVK9p05oghSP/ U54EBIfMjzY36MObI2UilXviBPyM9EQDme0/d/+pKNStGnx2/GJEwBhppYP0TE1EE79h X10nDBdTgu1Td5J0SnVAO1b1v0USiMKQO5h/okbtEW8LkhcCvR63Xr3ObdjEVWm893Yr c08a9mNYxlRHtL7g+oUkl9u+D7SQeM8HrI+gHXSf5f9q6NEfKYyBm94d1IbOsRKDioI9 gU0w== 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=F3mbRpSnAYd0G9DRd+YbI6xhVtJoXUfXjriB5cNlw5w=; b=jcM89QvfwXjZdQZ9PhcnFfH+NMxssTCcJRA6w2SUllkOFEP8/ZxbIjPRjbgul8aofa 6JV1DfzDajcxzuAG9LZjIUTN9GvfBQXoIJShV2WrF0uw21qaNKmVmT5QA9/e8DXBEtPP obMPBZ1buNNpK9DBO+1gU22hJjl4HDEmz+Ks6/lKWo/5Rm+dYiigWBgsu7IHqHD1jQ9i VhXbKU2200SwmW6Gi56HQjtUVNh2zfNe3UwHwHt0MIYOcwNrwHjfwNP8vvk1GDu87eXs K8ADSABfiSvI/0Rc6k2BmuVIpGu3SUW0Kd3zOMa6oOxMU3KXWDkIRvp7S2piAKl2ptSx 2kiA== X-Gm-Message-State: APjAAAVaB1MzZ6nG1VwuWst20u7xAKPk30ErZdKQ3VTNpI+Nlh8D7Xya /ZwrUzfMxkTiXLrT6dPM7OPu0SgLr/nIJAFACUiKSw== X-Google-Smtp-Source: APXvYqwy+bNyLTxg21qbmuaEUMTngsE8kHlAjGrXvLVUgBOVWRLfatyR2m9p203J67jTTOokqQP+bcL/8XuSzZh6i6w= X-Received: by 2002:a54:4013:: with SMTP id x19mr6843267oie.152.1552829954888; Sun, 17 Mar 2019 06:39:14 -0700 (PDT) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> In-Reply-To: From: Tony Arcieri Date: Sun, 17 Mar 2019 06:39:04 -0700 Message-ID: To: Paul Wouters Cc: Paterson Kenneth , secdir , CFRG , "RFC ISE (Adrian Farrel)" Content-Type: multipart/alternative; boundary="000000000000db99d005844a652a" Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 13:39:18 -0000 --000000000000db99d005844a652a Content-Type: text/plain; charset="UTF-8" On Sun, Mar 17, 2019 at 2:25 AM Paul Wouters wrote: > So for consensus, I think that what CFRG is doing matches a WG more than > an RG, and it would be more formally correct to change it. I think the CFRG is doing certain activities which would better fall under a WG, but the question is a bit of a false dichotomy to begin with. I think it would make sense to form perhaps 1 or 2 WGs for the biggest questions that keep coming up over and over. Some form of "lightweight key exchange" seems to be a popular one (see also my previous references to Dragonfly). This is definitely an interest area of mine, and something I'd like to participate in, but alas something I lack to motivation and time to spearhead myself... --000000000000db99d005844a652a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Mar 17, 2019 at 2:25 AM Paul Wout= ers <paul@nohats.ca> wrote:
=
So for consensus, I think that what CFRG is doing matches a WG more= than an RG, and it would be more formally correct to change it.

I think the CFRG is doing certain activities which wo= uld better fall under a WG, but the question is a bit of a false dichotomy = to begin with.

I think it would make sense to form= perhaps 1 or 2 WGs for the biggest questions that keep coming up over and = over. Some form of "lightweight key exchange" seems to be a popul= ar one (see also my previous references to Dragonfly).

=
This is definitely an interest area of mine, and something I'd lik= e to participate in, but alas something I lack to motivation and time to sp= earhead myself...=C2=A0
--000000000000db99d005844a652a-- From nobody Sun Mar 17 06:40:35 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 28BAE1279E6 for ; Sun, 17 Mar 2019 06:40:33 -0700 (PDT) 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, 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 (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 KtwtB7fJjGtX for ; Sun, 17 Mar 2019 06:40:31 -0700 (PDT) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (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 BE5CA126F72 for ; Sun, 17 Mar 2019 06:40:31 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id i21so7553099oib.11 for ; Sun, 17 Mar 2019 06:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zXPsoR04hAVE5SDTnpvQz0B6koXniTKH4GxM9oJgK1U=; b=HdP3ZG1OjPwnj2zji2mKZ/M56LMP5hSBCifldDBLsHaeK4kyx5L8MBgt60Ra530rOv Fz+bwfPvKMfaG0i8ep/k4aayByYtogDLSRddbeaqTn/zm2bgPKCGiFK6bZODrbnQ4Gms 72PWpwyrGGCkQTYhOrbvKEadln5HNZKG0TWj5wOKP5Mtc3kF9I37zBus8pR5EDMNca+x QWloXsN2P/ZkeCow6W7Y5GksRzForhLp6OcsCV9ZNJ4d9lIZudLEaKCJLmfDeSSeWuvZ AFEMhn2wYwu5iyN77Hzlc6whYxumsHEyDLIgdfOmgY31enZ0V9CNCUjNZIXAFDMCTvX7 bUkA== 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=zXPsoR04hAVE5SDTnpvQz0B6koXniTKH4GxM9oJgK1U=; b=IVURFTR7BV4D3n/pcE6nugFCbH+dWbyJ0bVos/JxVKYyeckPyVp0IXbC2O0g8qZp43 CoYTdH4FAnnz9E56pc9ZkbUrdPA/xTif47pFITkGrNwOLuK1dyDir9Jh0HJdn+Iw6Ruo XdMTKUedkC5LjglaMW0oNOLvUmK8mQlfC+oluAXNAJDOqo+u9vBdkDCNRyGZcvIG23FJ DJg/C3vanSOSgWqIooWNPRojFKbFvCPKrhWBkXlrzw+W/sXst2kwC07qZIfyYvHvtfeO xdX8zKkMimY2n5jFbvktniyOCvakybNv9E45JRaGDx2UqX+3e3TQABM5a5LpNJJNlIdG /0Sg== X-Gm-Message-State: APjAAAU4DqWkiijmfopTTcVCwvR2bRL7K8U908CCroDsndrfLMRMZRw2 dhpttcGf9ZgClpUY0F9rdPI9XaJ9NCF5SOK2kKY= X-Google-Smtp-Source: APXvYqxV5Ai9ws7CZ6agbYmsiMjyEbkLXrGqgIxrlZA3ty9F4uPHwv+zaTPD/iEaDwyZPKlxSR6K82P9oqz6rvbem54= X-Received: by 2002:aca:59d7:: with SMTP id n206mr7167203oib.26.1552830031133; Sun, 17 Mar 2019 06:40:31 -0700 (PDT) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> In-Reply-To: From: Tony Arcieri Date: Sun, 17 Mar 2019 06:40:20 -0700 Message-ID: To: Paul Wouters Cc: Paterson Kenneth , secdir , CFRG , "RFC ISE (Adrian Farrel)" Content-Type: multipart/alternative; boundary="00000000000067029005844a6a4f" Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 13:40:33 -0000 --00000000000067029005844a6a4f Content-Type: text/plain; charset="UTF-8" On Sun, Mar 17, 2019 at 6:39 AM Tony Arcieri wrote: > I think the CFRG is doing certain activities which would better fall under > a WG, but the question is a bit of a false dichotomy to begin with. > ...and sorry, to complete this thought, other than these repeat topics that have major engineering implications for standards, I think the CFRG is fine as an RG. --00000000000067029005844a6a4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Mar 17, 2019 at 6:39 AM Tony Arci= eri <bascule@gmail.com> wrot= e:
I think the CFRG is doing c= ertain activities which would better fall under a WG, but the question is a= bit of a false dichotomy to begin with.

<= /div>
...and sorry, to complete this thought, other than these repeat t= opics that have major engineering implications for standards, I think the C= FRG is fine as an RG.=C2=A0
--00000000000067029005844a6a4f-- From nobody Sun Mar 17 07:29: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 12C971277DE for ; Sun, 17 Mar 2019 07:29:38 -0700 (PDT) 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, 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 UFT9lU5aJoB6 for ; Sun, 17 Mar 2019 07:29:36 -0700 (PDT) Received: from edge10.ethz.ch (edge10.ethz.ch [82.130.75.186]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DA191200B3 for ; Sun, 17 Mar 2019 07:29:34 -0700 (PDT) Received: from CAS22.d.ethz.ch (172.31.51.112) by edge10.ethz.ch (82.130.75.186) with Microsoft SMTP Server (TLS) id 14.3.439.0; Sun, 17 Mar 2019 15:29:19 +0100 Received: from MBX117.d.ethz.ch ([fe80::c1d4:d225:fabf:1974]) by CAS22.d.ethz.ch ([fe80::dd0e:466a:b055:c090%10]) with mapi id 14.03.0439.000; Sun, 17 Mar 2019 15:29:20 +0100 From: "Paterson Kenneth" To: Paul Wouters CC: Michael StJohns , Richard Barnes , CFRG , "RFC ISE (Adrian Farrel)" , secdir Thread-Topic: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts Thread-Index: AQHU3KN0usLgCnMiA0yIdejQ5lPLV6YP0ZEA Date: Sun, 17 Mar 2019 14:29:18 +0000 Message-ID: <41245147-8673-4680-B62B-B277DA2CBC3A@inf.ethz.ch> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> In-Reply-To: Accept-Language: de-CH, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.132.139.34] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 14:29:38 -0000 SGkgUGF1bCwNCg0KSSB3YXNuJ3QgdXNpbmcgImNvbnNlbnN1cyIgaW4gYW55IGZvcm1hbCBJUlRG IHByb2Nlc3Mgc2Vuc2UsIHNvcnJ5OyBJIHNob3VsZCBoYXZlIHBpY2tlZCBhIGRpZmZlcmVudCB3 b3JkIHRvIGF2b2lkIGdpdmluZyB0aGF0IGltcHJlc3Npb24uIA0KDQpXaGF0IEkgc2F3IHdhcyBh IGRpc2N1c3Npb24gdGhhdCBoYWQgZ29uZSBvbiBmb3IgYSBwZXJpb2Qgb2YgdGltZSBhbmQgd2hl cmUgdGhlIGluaXRpYXRvciBoYWQgc2FpZCBoZSB3YXMgbm90IGdvaW5nIHRvIHB1c2ggdGhlIGlz c3VlIGFueSBmdXJ0aGVyLiBUaGF0IGZlbHQgbGlrZSBhIGdvb2QgdGltZSB0byBzdGVwIGluLCBz dW1tYXJpc2Ugd2hhdCBJJ2Qgc2VlbiwgYW5kIHN1Z2dlc3Qgd2UgbW92ZSBvbiB0byBvdGhlciBp c3N1ZXMuIEFwb2xvZ2llcyBpZiBteSB0aW1pbmcgd2FzIGJhZCBvciB0aGlzIHNlZW1lZCBoZWF2 eS1oYW5kZWQuIA0KDQpDaGVlcnMsDQoNCktlbm55DQoNCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IFBhdWwgV291dGVycyA8cGF1bEBub2hhdHMuY2E+DQpEYXRlOiBTdW5k YXksIDE3IE1hcmNoIDIwMTkgYXQgMDk6MjYNClRvOiBQYXRlcnNvbiAgS2VubmV0aCA8a2Vubnku cGF0ZXJzb25AaW5mLmV0aHouY2g+DQpDYzogTWljaGFlbCBTdEpvaG5zIDxtc2pAbnRocGVybXV0 YXRpb24uY29tPiwgUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g+LCAiY2ZyZ0BpcnRmLm9yZyIg PGNmcmdAaXJ0Zi5vcmc+LCAiUkZDIElTRSAoQWRyaWFuIEZhcnJlbCkiIDxyZmMtaXNlQHJmYy1l ZGl0b3Iub3JnPiwgc2VjZGlyIDxzZWNkaXJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NlY2Rp cl0gW0NmcmddIFRpbWUgdG8gcmVjaGFydGVyIENGUkcgYXMgYSB3b3JraW5nIGdyb3VwPyBXYXM6 IFJlOiBJU0Ugc2Vla3MgaGVscCB3aXRoIHNvbWUgY3J5cHRvIGRyYWZ0cw0KDQogICAgDQogICAg PiBPbiBNYXIgMTYsIDIwMTksIGF0IDEyOjMwLCBQYXRlcnNvbiBLZW5uZXRoIDxrZW5ueS5wYXRl cnNvbkBpbmYuZXRoei5jaD4gd3JvdGU6DQogICAgDQogICAgPiBUaGUgcm91Z2ggY29uc2Vuc3Vz IG9mIHRob3NlIHdobyBqb2luZWQgdGhlIGRpc2N1c3Npb24gaXMgdGhhdCB3ZSBzaG91bGQgbGVh dmUgdGhlIHN0YXR1cyBvZiBDRlJHIGFzIGl0IGlzIGZvciBub3cuIA0KICAgIA0KICAgIEkgd2Fz buKAmXQgYXdhcmUgd2Ugd2VyZSBnYXRoZXJpbmcgY29uc2Vuc3VzIGFscmVhZHkgYW5kIHRob3Vn aHQgd2Ugd2VyZSBqdXN0IGhhdmluZyBhIGRpc2N1c3Npb24uIFNvIHNlZWluZyB0aGlzIGN1dCBz aG9ydCBhbGwgb2YgYSBzdWRkZW4gd2l0aCBhIHRhbGx5IHNlZW1zIHdyb25nIHRvIG1lLg0KICAg IA0KICAgIFNvIGZvciBjb25zZW5zdXMsIEkgdGhpbmsgdGhhdCB3aGF0IENGUkcgaXMgZG9pbmcg bWF0Y2hlcyBhIFdHIG1vcmUgdGhhbiBhbiBSRywgYW5kIGl0IHdvdWxkIGJlIG1vcmUgZm9ybWFs bHkgY29ycmVjdCB0byBjaGFuZ2UgaXQuDQogICAgDQogICAgUGF1bA0KICAgIA0KICAgIA0KICAg IA0KDQo= From nobody Sun Mar 17 18:28:48 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 BE6561277E0 for ; Sun, 17 Mar 2019 18:28:38 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 GT_QhQCtq6iX for ; Sun, 17 Mar 2019 18:28:36 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 33E93126CFF for ; Sun, 17 Mar 2019 18:28:36 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id u15so2912298otq.10 for ; Sun, 17 Mar 2019 18:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hx1cjdwu1XP/dyOwtvs0XbC2OhsoVqIAzPUG5uB7+Bg=; b=ANwli+AKpn7tqE0b+BySI2dPg6G0leh0U38qZP0K6huEcu8CyWYocRKUt0LdqxP9kF 5XNWnBo+/lM+0Z0y4m5/n6ybK2tEbNnAMBaRBirJS7rXglwI1CTLyOqnKcV7UTtfmcD1 GZWKtIeFkxPuBJLI2MRRnkCpXwF/Hvu34nGr15YEExH9AEDGr6jwOPPML31mKwTgOO3i PudVomLNLG+PMIHhAgrQrRG7dCRyKiOkoaUwpY0Nv3nXu9r6hEJRggklQ0ZQ7eZzANnq I8wopNqehQkNKAlgCaXw1SCmzWXbigsztrPf1C5RYg+/v31yJw8/6MSwepzFdhlr55Ix 5FLQ== 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=hx1cjdwu1XP/dyOwtvs0XbC2OhsoVqIAzPUG5uB7+Bg=; b=BKazU7egXAwL4xBV6tFN3E22HXQryATp/n1lBB1wln5CjF8+c8XQQNnp0A7QcElmuX b8ad0Q4Ge0Ptsp/rF/0I2I6xwdt0Z+c5Oj9S6K6DrOwEved6arELyYveF6PkfyRXUblB RK62nWfR9mSC1XfFtFwgUVr0SCjA7wVs3OLUFO5eQ8RqS+w8iLSubA5/6p/43gQGClaz ARyDUDbEYqGNFXcceVDQrmUCtoDy1Bx5M6hSkzSYEH0tXlYeX0w7St7+c135fiXVFgN0 VyBYZGAXIMcidpYRqzh6Kyl3cp3dqQQB6u+axIZDfgb0qm2BqEVqTEmVAlN9CF4EVMsr 1g7Q== X-Gm-Message-State: APjAAAUQtgHNRZ81/ebR8HMsp/itbszLubeR8u/bUYkfRZSmjDCQ1EcN QQVEmDBm0/MHp/u7M2C2VL/tMl4/Mrf28tH48WI= X-Google-Smtp-Source: APXvYqxjNeveWR9E+5aRRYMXWp70whfFjDSfbi0M8P0excp1QbpGh6UApBA54KydoMEG173DDY6DMRq8FwITns2ne9M= X-Received: by 2002:a9d:61c5:: with SMTP id h5mr331704otk.330.1552872515594; Sun, 17 Mar 2019 18:28:35 -0700 (PDT) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> <679B6759-5AD3-4F28-9EF4-8794F383468B@mit.edu> In-Reply-To: <679B6759-5AD3-4F28-9EF4-8794F383468B@mit.edu> From: denis bider Date: Sun, 17 Mar 2019 20:28:24 -0500 Message-ID: To: Uri Blumenthal Cc: Paul Wouters , CFRG , "RFC ISE (Adrian Farrel)" , secdir Content-Type: multipart/alternative; boundary="000000000000ac6de90584544e96" Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 01:28:39 -0000 --000000000000ac6de90584544e96 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable With regard to shutting down - I think that policy is doing an incredible disservice to the internet, to both developers and users of protocols. The IETF needs the concept of permanent working groups and a bunch of protocols need them. The way it works right now is, a group forms around standardizing a protocol, the RFCs are done and the group disbands. Just like that, an entire community that formed around that protocol disappears. When people want to introduce extensions, there's no longer anywhere to turn to. So development of extensions happens haphazardly, without discussion, without feedback, without coordination. I think this policy (of shutting down WGs) is braindead, personally. Working groups should shut down only for things that are actually dead. Not when there's a temporary hiatus before the next version. On Sun, Mar 17, 2019 at 7:11 AM Uri Blumenthal wrote: > If CFRG is doing what a WG is supposed to - what's the product is suppose= d > to produce, what are the milestones, and when is it supposed to wind down= , > as any normal WG should when it's done the job it was chartered for? > > Sent from my test iPhone > > > On Mar 17, 2019, at 05:25, Paul Wouters wrote: > > > > > >>> On Mar 16, 2019, at 12:30, Paterson Kenneth < > kenny.paterson@inf.ethz.ch> wrote: > >> > >> The rough consensus of those who joined the discussion is that we > should leave the status of CFRG as it is for now. > > > > I wasn=E2=80=99t aware we were gathering consensus already and thought = we were > just having a discussion. So seeing this cut short all of a sudden with a > tally seems wrong to me. > > > > So for consensus, I think that what CFRG is doing matches a WG more tha= n > an RG, and it would be more formally correct to change it. > > > > Paul > > > > > > _______________________________________________ > > secdir mailing list > > secdir@ietf.org > > https://www.ietf.org/mailman/listinfo/secdir > > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --000000000000ac6de90584544e96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
With regard to shutting down - I think that policy is= doing an incredible disservice to the internet, to both developers and use= rs of protocols.

The IETF needs the concept of per= manent working groups and a bunch of protocols need them.

The way it works right now is, a group forms around standardizing a= protocol, the RFCs are done and the group disbands. Just like that, an ent= ire community that formed around that protocol disappears. When people want= to introduce extensions, there's no longer anywhere to turn to. So dev= elopment of extensions happens haphazardly, without discussion, without fee= dback, without coordination.

I think this policy (= of shutting down WGs) is braindead, personally. Working groups should shut = down only for things that are actually dead. Not when there's a tempora= ry hiatus before the next version.


On Sun, Mar 17, 2019= at 7:11 AM Uri Blumenthal <uri@mit.edu> wrote:
If CFRG is doing what a WG is suppo= sed to - what's the product is supposed to produce, what are the milest= ones, and when is it supposed to wind down, as any normal WG should when it= 's done the job it was chartered for?

Sent from my test iPhone

> On Mar 17, 2019, at 05:25, Paul Wouters <paul@nohats.ca> wrote:
>
>
>>> On Mar 16, 2019, at 12:30, Paterson Kenneth <kenny.paterson@inf.ethz.c= h> wrote:
>>
>> The rough consensus of those who joined the discussion is that we = should leave the status of CFRG as it is for now.
>
> I wasn=E2=80=99t aware we were gathering consensus already and thought= we were just having a discussion. So seeing this cut short all of a sudden= with a tally seems wrong to me.
>
> So for consensus, I think that what CFRG is doing matches a WG more th= an an RG, and it would be more formally correct to change it.
>
> Paul
>
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/= wiki/SecDirReview
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
--000000000000ac6de90584544e96-- From nobody Sun Mar 17 18:34:42 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 61C51130F20 for ; Sun, 17 Mar 2019 18:34:33 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 xiahSAouZLQ7 for ; Sun, 17 Mar 2019 18:34:30 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 1EF13130F1C for ; Sun, 17 Mar 2019 18:34:30 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id v10so12535319lji.3 for ; Sun, 17 Mar 2019 18:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ztjEVXEmPbqD5zh+T0r9rzVeIZNTCcfp4rhgq+j7DP0=; b=O7MYHwlPLDWQMNy3RQVOugnbUazBlGzHRGR9JqD3BcAlFYQ2QDXPbM/iYapLlfPNL6 UhhEH3cKkHuXC37db3buuiAsWTUtbSratJaCnAjijY5R2aA0IAB3g9wYcU/+pXqA8Td3 smrZgAMS9HQChfw5AHFRslXYPyFrffYs98vfkT5X9zEZQxuJPYlVPtJA18pKmJ1eHrL7 4ZrOmym7dyjMdqSZQYIZg6rpA/+Ez1N433lwDxyJ9v+gOb+8E/WRX07r9eIciHJMppXk 1+paSXBU2YyPIZbB/dOeO6Tkk5EcxzOlC8ogfMqQfmvf1kw+aY3xdiGvW2U+cxVj+0vh Xfyw== 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=ztjEVXEmPbqD5zh+T0r9rzVeIZNTCcfp4rhgq+j7DP0=; b=EsaLOuICainh3WDntDh8/U/FDUb4udQOudUyacfVFOvp+uojibWIeAO5LA6tr/6D2T fdGv2rwATl7VryUdIADg0OOrwLffYm/tPF59+cEJmWWY5U4489K5aXjuyeXuZKx9chJQ 8LdlGA3H3kpYAYXDFHr7fNIRPEDj0tSg2dlvWBmZDNpgOW82rEO7D2peLb8gcd6AyTGG Y9LhyHNk85u+4Tulv6DKhimHQJaNWNghBDWd8u0ljXqvWeWvjT3LU3FKEmSfqp4obYA5 wbXoKrGRgoMqkSOLR/75DiHncYVawtsTYBYN+98z9++zpQkBQ/SatBx4iO/sUOdoWA/1 FJ5g== X-Gm-Message-State: APjAAAVhHDT06rR/uJJ+2ygluFhEuYUP4qsklXxh2AsTBswrRpATg7bN ZfHnpdfFTsJ2O6+zQ/qgeztNPsNhLyYojedXuE0= X-Google-Smtp-Source: APXvYqzTTVeBuzLpYyZD83tZYtsWnpoDLm3gpCJPwcCWM1DXjgIbDYvmcpN4p+xTxeJ9OpudzGxSA0+BUm10IdHLQj8= X-Received: by 2002:a2e:9a83:: with SMTP id p3mr7995364lji.35.1552872868296; Sun, 17 Mar 2019 18:34:28 -0700 (PDT) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> <679B6759-5AD3-4F28-9EF4-8794F383468B@mit.edu> In-Reply-To: From: Watson Ladd Date: Sun, 17 Mar 2019 18:34:16 -0700 Message-ID: To: denis bider Cc: Uri Blumenthal , Paul Wouters , CFRG , "RFC ISE (Adrian Farrel)" , secdir Content-Type: multipart/alternative; boundary="000000000000b23cc60584546398" Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 01:34:34 -0000 --000000000000b23cc60584546398 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable And the issues the CFRG deals with a perennial. On Sun, Mar 17, 2019, 6:29 PM denis bider wrote= : > With regard to shutting down - I think that policy is doing an incredible > disservice to the internet, to both developers and users of protocols. > > The IETF needs the concept of permanent working groups and a bunch of > protocols need them. > > The way it works right now is, a group forms around standardizing a > protocol, the RFCs are done and the group disbands. Just like that, an > entire community that formed around that protocol disappears. When people > want to introduce extensions, there's no longer anywhere to turn to. So > development of extensions happens haphazardly, without discussion, withou= t > feedback, without coordination. > > I think this policy (of shutting down WGs) is braindead, personally. > Working groups should shut down only for things that are actually dead. N= ot > when there's a temporary hiatus before the next version. > > > On Sun, Mar 17, 2019 at 7:11 AM Uri Blumenthal wrote: > >> If CFRG is doing what a WG is supposed to - what's the product is >> supposed to produce, what are the milestones, and when is it supposed to >> wind down, as any normal WG should when it's done the job it was charter= ed >> for? >> >> Sent from my test iPhone >> >> > On Mar 17, 2019, at 05:25, Paul Wouters wrote: >> > >> > >> >>> On Mar 16, 2019, at 12:30, Paterson Kenneth < >> kenny.paterson@inf.ethz.ch> wrote: >> >> >> >> The rough consensus of those who joined the discussion is that we >> should leave the status of CFRG as it is for now. >> > >> > I wasn=E2=80=99t aware we were gathering consensus already and thought= we were >> just having a discussion. So seeing this cut short all of a sudden with = a >> tally seems wrong to me. >> > >> > So for consensus, I think that what CFRG is doing matches a WG more >> than an RG, and it would be more formally correct to change it. >> > >> > Paul >> > >> > >> > _______________________________________________ >> > secdir mailing list >> > secdir@ietf.org >> > https://www.ietf.org/mailman/listinfo/secdir >> > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >> > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --000000000000b23cc60584546398 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And the issues the CFRG deals with a perennial.=C2= =A0

On Sun, Mar 17, 2019, 6:29 PM denis bider <denisbider.ietf@gmail.com> wrote:
With regard to shutting down -= I think that policy is doing an incredible disservice to the internet, to = both developers and users of protocols.

The IETF n= eeds the concept of permanent working groups and a bunch of protocols need = them.

The way it works right now is, a group forms= around standardizing a protocol, the RFCs are done and the group disbands.= Just like that, an entire community that formed around that protocol disap= pears. When people want to introduce extensions, there's no longer anyw= here to turn to. So development of extensions happens haphazardly, without = discussion, without feedback, without coordination.

I think this policy (of shutting down WGs) is braindead, personally. Work= ing groups should shut down only for things that are actually dead. Not whe= n there's a temporary hiatus before the next version.


On Sun, Mar 17, 2019 at 7:11 AM Uri Blumenthal <uri@mit.edu> wrote:
If CFRG is doing what a WG is supposed to - what&#= 39;s the product is supposed to produce, what are the milestones, and when = is it supposed to wind down, as any normal WG should when it's done the= job it was chartered for?

Sent from my test iPhone

> On Mar 17, 2019, at 05:25, Paul Wouters <paul@nohats.ca> wrote:<= br> >
>
>>> On Mar 16, 2019, at 12:30, Paterson Kenneth <kenny.= paterson@inf.ethz.ch> wrote:
>>
>> The rough consensus of those who joined the discussion is that we = should leave the status of CFRG as it is for now.
>
> I wasn=E2=80=99t aware we were gathering consensus already and thought= we were just having a discussion. So seeing this cut short all of a sudden= with a tally seems wrong to me.
>
> So for consensus, I think that what CFRG is doing matches a WG more th= an an RG, and it would be more formally correct to change it.
>
> Paul
>
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/se= cdir
> wiki: http://tools.ietf.org/are= a/sec/trac/wiki/SecDirReview
_______________________________________________
Cfrg mailing list
Cfrg@= irtf.org
https://www.irtf.org/mailman/listinfo/cfrg<= br>
_______________________________________________
Cfrg mailing list
Cfrg@= irtf.org
https://www.irtf.org/mailman/listinfo/cfrg<= br>
--000000000000b23cc60584546398-- From nobody Sun Mar 17 18:53:12 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 DD46F131213 for ; Sun, 17 Mar 2019 18:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 sm2lW82Jf4vo for ; Sun, 17 Mar 2019 18:53:10 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 063AB127982 for ; Sun, 17 Mar 2019 18:53:09 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id i7so7040161pgq.0 for ; Sun, 17 Mar 2019 18:53:09 -0700 (PDT) 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-language:content-transfer-encoding; bh=a88h5dOj4ZSbVEkLiwFHnl027UBroeTaT52eU7ZDuVU=; b=VA0V37YdUjqXr+7VfNdHkcTfJ2ULLDjYT9oYIWlI9RAoluhz9DkyDeuzSNWKjZDLqf FXaxzHaf15PyKsIj87v8OQ/sUyJ+Zws1E+D/XfQM084dnwe1dh5zcsjrV7HEOwpawhXx +m4K+Wfe16yrlaS+dXCVVi4EdE0GnQNCPEcJbo7QAwTMjUwbaQmMMHlCSUzboHXyTOS0 XdAPydv/jCV9sM/Rpeg8KRKu+4VGk89QFjR/yucQ2LJNz175owI0Sgjm7TD/Q2lwOfms 9anzWc0HESt/+0fl9QGNdYhYQQZd51UkVWgLWPzGm/FP2TtMeWe7/nSLY2nLMYkj/chh TjQA== 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-language :content-transfer-encoding; bh=a88h5dOj4ZSbVEkLiwFHnl027UBroeTaT52eU7ZDuVU=; b=e4R4mw/LGiwHAjhbNtUV93UUCljK0CDx1ZCEB+UEMOIvKhKsA99Lges3679CgvIWml APdx5cwyGn9WUU35boyi5l+nPlbyyq3NwKZOiOC3AO/gfOgIHcScvVCTAAVoBc7HjtVn cn2/5elTxzXwS2UOL8IuMasynrMhtgSqUHvr+bjzVclYu9ERSAp3TSPuh2bcVUgYokfj 9xemGZoyag0g7OtpVJDAdmVNfjQcm+oozg73AGRAkuArhteyX10yP7r/b+dOiZFnT1QF TuO8uQv062GjK2+lX4agrjtsCjSzpkcFcKVFwhWq9PARxsRUjxj9CJQ2ta3OzFW2urqV G1/Q== X-Gm-Message-State: APjAAAVEwEHAbrmHlymtxVHoCUS2rA4qKztInqzpYfxEBPfZeNXJv3Yz dnYamOfRuRCBHMGkQ7BhIfeVsaij X-Google-Smtp-Source: APXvYqwqeN7Y/dJKZw9/EFPpscEcL+Vr88jlQHC25RFUnqHqu1mU6zZDVubcPcNWkRj4aJtJ1ejvWQ== X-Received: by 2002:a62:b415:: with SMTP id h21mr16647076pfn.26.1552873988987; Sun, 17 Mar 2019 18:53:08 -0700 (PDT) Received: from aspen.local ([216.67.81.206]) by smtp.gmail.com with ESMTPSA id 20sm13462844pfs.182.2019.03.17.18.53.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Mar 2019 18:53:08 -0700 (PDT) To: denis bider , Uri Blumenthal Cc: CFRG , "RFC ISE (Adrian Farrel)" , secdir References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> <679B6759-5AD3-4F28-9EF4-8794F383468B@mit.edu> From: Melinda Shore Message-ID: Date: Sun, 17 Mar 2019 17:53:06 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 01:53:12 -0000 On 3/17/19 5:28 PM, denis bider wrote: > When > people want to introduce extensions, there's no longer anywhere to turn > to. So development of extensions happens haphazardly, without > discussion, without feedback, without coordination. That's actually not what happens - new work on old protocols has to go through the chartering process, which is, in practice, more rigorous than rechartering and tends, in my experience, to produce more focused results. The IETF produces a pretty good number of -bis documents and extensions through the working group process. (Currently we've got groups like lamps, curdle, kitten, and so on updating old standards.) At any rate, I'd like to see CFRG remain where it is, in part because of structural reasons but mostly because it's been productive and useful and it's not clear that there's any practical advantage to changing it to an IETF working group, while there are several clear disadvantages (I think that potentially removing incentives for participation by academics is a huge deal, myself). Melinda -- Melinda Shore melinda.shore@gmail.com Software longa, hardware brevis From nobody Sun Mar 17 20:01:00 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 CE69E131222; Sun, 17 Mar 2019 20:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 td2Dsj-_xxVe; Sun, 17 Mar 2019 20:00:57 -0700 (PDT) Received: from outgoing-exchange-7.mit.edu (outgoing-exchange-7.mit.edu [18.9.28.58]) (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 D602C131225; Sun, 17 Mar 2019 20:00:56 -0700 (PDT) Received: from OC11EXEDGE3.EXCHANGE.MIT.EDU (OC11EXEDGE3.EXCHANGE.MIT.EDU [18.9.3.21]) by outgoing-exchange-7.mit.edu (8.14.7/8.12.4) with ESMTP id x2I30sAI021151; Sun, 17 Mar 2019 23:00:55 -0400 Received: from OC11EXHUB11.exchange.mit.edu (18.9.3.25) by OC11EXEDGE3.EXCHANGE.MIT.EDU (18.9.3.21) with Microsoft SMTP Server (TLS) id 14.3.439.0; Sun, 17 Mar 2019 23:00:42 -0400 Received: from OC11EXPO28.exchange.mit.edu ([169.254.1.251]) by OC11EXHUB11.exchange.mit.edu ([18.9.3.25]) with mapi id 14.03.0439.000; Sun, 17 Mar 2019 23:00:52 -0400 From: Uri Blumenthal To: Melinda Shore CC: denis bider , CFRG , "RFC ISE (Adrian Farrel)" , secdir Thread-Topic: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts Thread-Index: AQHU3S1XekOBSzUeY0uWx2KO3WTmfKYQ9kqA Date: Mon, 18 Mar 2019 03:00:51 +0000 Message-ID: <446ABCA7-7AAD-4F0C-9A69-CA02B2CA46C3@mit.edu> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> <679B6759-5AD3-4F28-9EF4-8794F383468B@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail-10FAAA9E-E4DD-438B-BF13-1F80A7DCB0BA"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 03:00:59 -0000 --Apple-Mail-10FAAA9E-E4DD-438B-BF13-1F80A7DCB0BA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit +1 to Melinda. Sent from my test iPhone > On Mar 17, 2019, at 21:53, Melinda Shore wrote: > >> On 3/17/19 5:28 PM, denis bider wrote: >> When >> people want to introduce extensions, there's no longer anywhere to turn >> to. So development of extensions happens haphazardly, without >> discussion, without feedback, without coordination. > > That's actually not what happens - new work on old > protocols has to go through the chartering process, which > is, in practice, more rigorous than rechartering and tends, > in my experience, to produce more focused results. The > IETF produces a pretty good number of -bis documents and > extensions through the working group process. (Currently > we've got groups like lamps, curdle, kitten, and so on > updating old standards.) > > At any rate, I'd like to see CFRG remain where it is, in > part because of structural reasons but mostly because it's > been productive and useful and it's not clear that there's > any practical advantage to changing it to an IETF working > group, while there are several clear disadvantages (I think > that potentially removing incentives for participation by > academics is a huge deal, myself). > > Melinda > > -- > Melinda Shore > melinda.shore@gmail.com > > Software longa, hardware brevis --Apple-Mail-10FAAA9E-E4DD-438B-BF13-1F80A7DCB0BA Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCGsw ggQkMIICjKADAgECAgRbkXGgMA0GCSqGSIb3DQEBDAUAMBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBS U0EgNDAeFw0xODA5MDYxODI3NDRaFw0yMTA5MDYxODI3NDRaMA4xDDAKBgNVBAMMA1VyaTCCAaIw DQYJKoZIhvcNAQEBBQADggGPADCCAYoCggGBANJi8+lfrSCcWThbn0vQzXsW7AYTyTZSo/pv/274 xD/t1rpn/X/vegP2lSfr+SRJ4oJ+51MFJvRl/sAveroDN8gGrFyYaCg5ZsOMqksCmLha4Ttgk04L I/aqrPGuzF1OVgjhi6WrnFr80KS6sy3MWzYIYV6G1FycKEup5snMr1B1WWzFKOwSslnJwvCuHu2W Tc5OzJKPtxMcDIS9y6VOZTzsJUFe0bRiw0LICDBcB3fgKCvYMcDfke0pw13I4O7wEG40s9E6rTIj Q0H1LVk69pSo1ikzpikl5W8pXUQQrSmjHqhFn/Q+PwSzHSOralN0p1UMziUv57lgvvZbTaH1ooqq MZBuTed0xLye3w+h9+/iqDY4B7lFqbegzseBh7/Q6KdtfpkwwI7xSpZEME/V77KAMw+ipb+Itbij Bi3r/t81fDW8eitIAbVtalpFROlYIaZnIIohOZRyVjn2unZ+lj3jDKsDq53g+oleo+Ruszlt8nju 6uKhzE7bdX1xJuvCtwIDAQABo34wfDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIFIDAWBgNV HREEDzANgQt1cmlAbWl0LmVkdTAdBgNVHQ4EFgQU2p+nwSyQFM6byFBhc7oIZephJbcwJQYDVR0l BB4wHAYIKwYBBQUHAwQGCisGAQQBgjcKAwQGBFUdJQAwDQYJKoZIhvcNAQEMBQADggGBAH/zzG9P gU+ogFbc75JpUK0amUUtmtSsGDe4599GolCDiuPHrnbCGcaNc9aQjRaP3Q3aU7BB3aOjwssjQSN0 tsfZD8p+XPny/odhDSwS/25jCg0dVasd8q+Jd1S1g34RGUqPQ+5ofTrBSEkHBdLdJOnxBGo9GRzA yiDg34r6zK6BXNYv2GdqRk+GGGvL/w3CDR+ih36ZDBxw/EO19oH/aV4+mVlcRI6aoj4KMb+h4zMY S8jLDArIZSce4EWzJqxKVcX6Q7CE/0Br/7R8Ixs+vt5YKPUVpEbFM6koH624GDQYKM2kzXBnwYgS /jvl02KUx6uNmIgo+ufK2l7sc83vRLxBTJKhT0/USVkwu9uzg2zHJeGBZ4pmDhkIVkGcamW7KPYZ dgOz8zAOy8Ntk7GebPn85XuPcQS9UntdO61X1EyEXg4Ixl/qapidfJQfdCqEeZZXpaV3WKWE8u1l fNB00mC0/xhG3bikQxl3O20nyPjXvl6VZFzglsPRy1Xh5L//rzCCBD8wggKnoAMCAQICBFuRckIw DQYJKoZIhvcNAQEMBQAwGjEYMBYGA1UEAwwPRm9yZXN0IENBIFJTQSA0MB4XDTE4MDkwNjE4MzAy NloXDTIxMDkwNjE4MzAyNlowDjEMMAoGA1UEAwwDVXJpMIIBojANBgkqhkiG9w0BAQEFAAOCAY8A MIIBigKCAYEAtZvms8stf9xj5w7pjYzgmHe7TH0eX/q3buMBqdLufhFuqCizZPhXJmSbue8WHm8H HO7SHQPUqIqbPOMIQfAL8nwWhuTfsN5nrtFW77eiNsEexRNkbhw/U6RzamCGl6xQmUxOD0nabEmd Xdces+rjtzlvjpNHI7xrR32ee4JuGTjwAWlAHPtBC8TqiOR/ysR2K2umk5BkjCEWV9kDfGklfKmu IhuCzzpTvN3AnLMX9kP9IY6E9B8OsLOhkOFBbAMzyqkXibtPWluqOnYW3V3MVc9H1ir6sGLF5onW lHLEorI51WuHlfVO8WJRYwhrzQIIAWAYheZaH2wdb87Kw6o4JbHDLTDJHHrBDwfqa5OtFTeQNWCD JPdHa4xfFpjnMTzP18POa5C6QN5XBpTFsfccWyEdt+ykGB2FMzhB3GgMVRfWPgo8TgxVwU9MHt8s vmxj8KMUd7afSJBOjMIRPZ6gi8Vja9SR9+Hj/YWgpKZMHhI7irJVpWF++7hhfxxDbgDBAgMBAAGj gZgwgZUwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwFgYDVR0RBA8wDYELdXJpQG1pdC5l ZHUwHQYDVR0OBBYEFK3WLENy4CH330dGZEWchN+L1r28MD4GA1UdJQQ3MDUGCCsGAQUFBwMCBggr BgEFBQcDAwYKKwYBBAGCNwoDDAYJKoZIhvcvAQEFBggrBgEFBQcDBDANBgkqhkiG9w0BAQwFAAOC AYEACYbThcFo+JTQNP5UacMtYogWU/yOx5GBLSNNa5cpvoRrOJc9CUDfzfnrd7IhDLXvnFUYNt3i oyU13LKRoPsp/YYuZ2CBI1om9g27SSqqEcOom0eojIKkPNw+sJzYVl7Dz2I7f9DHN6nEC9BeT8Do rjuq67UOlZZw0YvlvCmtMI4xJ7CUM8NrphoeRN18OnbwmkHWIYnYwdxipTJ8oLWi5EbKaUEYyLlC JWd6o9vH8cFNzsViPUl9POxBtX++o5KxtW7/JQwrQt3uFubF6rHQag6HDeXcXSyI0DmL8MrfVtHi Ma2bN+7z8N9Wnuvx8v0qlqfwd+uhmP7OvD32PuzjQxuGyPd43DZazlMhY9IRpSSCPhdbxzS3YwKr jnTZlKGwPiYCmiQ0XSEW3K64Exe4t+jrkBReocr9ccslB4d4XhxQPdAvUdI43xGMbnFea7pyTDyP b0z1vMrYt6dAguU0QTgRZsPFoIldK70ILvncq9amhxuQ4Uw+u2WUXiYba2R1MYICoTCCAp0CAQEw IjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRckIwDQYJYIZIAWUDBAIBBQCggdEwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwMzE4MDMwMDUxWjAvBgkq hkiG9w0BCQQxIgQg46/WCpdcbQ5vnuhw6LnP5EaerJCDsdH+SzxgF2HAoewwMQYJKwYBBAGCNxAE MSQwIjAaMRgwFgYDVQQDDA9Gb3Jlc3QgQ0EgUlNBIDQCBFuRcaAwMwYLKoZIhvcNAQkQAgsxJKAi MBoxGDAWBgNVBAMMD0ZvcmVzdCBDQSBSU0EgNAIEW5FxoDANBgkqhkiG9w0BAQEFAASCAYCCE7G/ lbq4sxEg+HnGtSya6rVQvrxxQSyrjs6fM/fkYNY2docgO34nGjGLqvqKwlQHkyzlKB4ax5XqQ50e RtwTXfE130wALndivdDlA9Dsj2I/9u+gDuBE62DyaFMh40+5QZfzISTC+matYjpAz1j0YHDAWuPh 4dA6QtSHmq2zuGEj/gvxJpwgMoabcI3MPv3BhpUylYzGau7rFqWtAv3DHTkopNSBMpZPJJAYGot2 /s8R1ISwSIoi0WAqNDwcvvhjD0GKAnxBZQDaMYpnuVvyTC86/l1tIIUfGUFkdLWxXfQYBVrn8NC4 tsDfAmv2HYkDmLmtlDX/0vqxBnHvNxZPo7W4cLvs45morzAyKjGJjc/igi2FMojKO8K5yzwdM0LM c7xEXE6Bz/G7G7YKwtL+eHa8sKlzd/mJxBLmlhXCbP0vlAhJawevgK+ppScZ9t9VgJisvz2VCY0M IwM/c6DkDrPbXBsXFS8Qs/PWw/Jf83+d/9JxXLp6OVVgr5WacTMAAAAAAAA= --Apple-Mail-10FAAA9E-E4DD-438B-BF13-1F80A7DCB0BA-- From nobody Sun Mar 17 20:11:26 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 CEFEA1288BD for ; Sun, 17 Mar 2019 20:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 36Uu17U0-umH for ; Sun, 17 Mar 2019 20:11:19 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0: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 5A3C0130EA5 for ; Sun, 17 Mar 2019 20:11:19 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id o74so311191ota.3 for ; Sun, 17 Mar 2019 20:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=51gtCVWFE0uHHNWY2tWrF2ax6JVTVdattrC62gZLnjU=; b=Sx562S4ngmTPtF7qpwYioT1QiQRWHaLlDHCFMRViCh+jK5xeQMMTAjOguBJ/PsZmqm O3d94PLAWb1BdKjX704DelGDo5Zf+Hz80GgprdG9AOzw69uJE5ir584fI2uiNM8BBEYo tZW0REiHhGj9C0s/lME6BClAL5xyTVkCbr3rhEOtGL2+UX0UTKoTBGfEXb9QLvZIVxEm V5BJRLCKloRYoIAjQNOVr8reA/1kiH9eTSn4eRgjj7xo8lo56loDY/NzSw6TUzPhQtMz 3haIi7eIiRq7Wp65jYRLYB6oKtid/GQ98SJELnSsf9SXIxpX4+VunkkclJwo1za7jRQA pu1A== 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=51gtCVWFE0uHHNWY2tWrF2ax6JVTVdattrC62gZLnjU=; b=DIm3wVgze5vkZh6ugU4Jqsr6xVeNclNExuoMc6+uxy2VGAsrMzBOiflR/W6JCfbtt0 w1s/kAmXmWy2Exri15cPw6bTgpHXhRevpEy6wl9Uq+nu8hcmuxOz2Y3N45qYVrlV3cAi vk9Ak1jHK/8tdifE2MPDo1ovxGin79eiTinEM+WQrR4Nidux9OQcY1MSp0rab4m8ZanH VGHzBzLIEFmZ1gSG8VqEOvzj2HO/dJXMuUv40Gznz/zhomnuTywEpW01o74kBSP85W+A h6jgcr7dzA2OzBRzcKpr+COAudiuQ2/bJAqDjg5dfIhCwX+6/EUFZWAzLqR422SVSO2z NEiw== X-Gm-Message-State: APjAAAUdykW1h+omk3nwR6bFeOvDNHiA+yXL76v/XWHsW5/isRwQPQBp RCTQdgxfxeK4nkRH8RpX24yieQSCjKVuqM4x4eY= X-Google-Smtp-Source: APXvYqyUR+hISgb4leqk3YeNZfZF4LwI4tORCZyIRfJy+qe7Zl/79iuCW+Qqo/oZMU8rsZjyr0/bApVWMoLUjA/aqt0= X-Received: by 2002:a9d:53c8:: with SMTP id i8mr2980136oth.60.1552878678616; Sun, 17 Mar 2019 20:11:18 -0700 (PDT) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> <679B6759-5AD3-4F28-9EF4-8794F383468B@mit.edu> In-Reply-To: From: denis bider Date: Sun, 17 Mar 2019 22:11:06 -0500 Message-ID: To: Melinda Shore Cc: Uri Blumenthal , CFRG , "RFC ISE (Adrian Farrel)" , secdir Content-Type: multipart/alternative; boundary="00000000000004afac058455be9c" Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 03:11:21 -0000 --00000000000004afac058455be9c Content-Type: text/plain; charset="UTF-8" > That's actually not what happens - new work on old > protocols has to go through the chartering process, > which is, in practice, more rigorous than rechartering > and tends, in my experience, to produce more focused > results. The IETF produces a pretty good number of > -bis documents and extensions through the working > group process. You are pointing out the lucky situations where that happens, I'm pointing out the unlucky ones where it doesn't. SSH is full of underdocumented, partly functional custom extensions (to cryptography, compression, SFTP, port forwarding, host key synchronization, VPN, and more), most of which *could* be better designed, better documented and standardized - if only there was a continuing forum and people did not have to go through this "rigorous" chartering process. You point out the handful of documents produced as a success. I point out a mountain of documents NOT produced, problems NOT solved, discussions NOT had as a failure. This same situation now arises in the context of CFRG, which would make sense as a permanent WG. But nope, that option has to not be available. On Sun, Mar 17, 2019 at 8:53 PM Melinda Shore wrote: > On 3/17/19 5:28 PM, denis bider wrote: > > When > > people want to introduce extensions, there's no longer anywhere to turn > > to. So development of extensions happens haphazardly, without > > discussion, without feedback, without coordination. > > That's actually not what happens - new work on old > protocols has to go through the chartering process, which > is, in practice, more rigorous than rechartering and tends, > in my experience, to produce more focused results. The > IETF produces a pretty good number of -bis documents and > extensions through the working group process. (Currently > we've got groups like lamps, curdle, kitten, and so on > updating old standards.) > > At any rate, I'd like to see CFRG remain where it is, in > part because of structural reasons but mostly because it's > been productive and useful and it's not clear that there's > any practical advantage to changing it to an IETF working > group, while there are several clear disadvantages (I think > that potentially removing incentives for participation by > academics is a huge deal, myself). > > Melinda > > -- > Melinda Shore > melinda.shore@gmail.com > > Software longa, hardware brevis > --00000000000004afac058455be9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0That's actually not what happens - new work on old
> protocols has to go = through the chartering process,
> which is, in practice, more rigorous than rechartering
=
> and tends, in my experience, to prod= uce more focused
> results.=C2=A0 The IETF produces a pretty good number of
> -bis documents and extensions through the working=
> group process.

You are p= ointing out the lucky situations where that happens, I'm pointing out t= he unlucky ones where it doesn't.

SSH is full = of underdocumented, partly functional custom extensions (to cryptography, c= ompression, SFTP, port forwarding, host key synchronization, VPN, and more)= , most of which could be better designed, better documented and stan= dardized - if only there was a continuing forum and people did not have to = go through this "rigorous" chartering process.

You point out the handful of documents produced as a success. I poin= t out a mountain of documents NOT produced, problems NOT solved, discussion= s NOT had as a failure.

This same situation now ar= ises in the context of CFRG, which would make sense as a permanent WG. But = nope, that option has to not be available.

=

= On Sun, Mar 17, 2019 at 8:53 PM Melinda Shore <melinda.shore@gmail.com> wrote:
On 3/17/19 5:28 PM, denis bider wrote:
> When
> people want to introduce extensions, there's no longer anywhere to= turn
> to. So development of extensions happens haphazardly, without
> discussion, without feedback, without coordination.

That's actually not what happens - new work on old
protocols has to go through the chartering process, which
is, in practice, more rigorous than rechartering and tends,
in my experience, to produce more focused results.=C2=A0 The
IETF produces a pretty good number of -bis documents and
extensions through the working group process.=C2=A0 (Currently
we've got groups like lamps, curdle, kitten, and so on
updating old standards.)

At any rate, I'd like to see CFRG remain where it is, in
part because of structural reasons but mostly because it's
been productive and useful and it's not clear that there's
any practical advantage to changing it to an IETF working
group, while there are several clear disadvantages (I think
that potentially removing incentives for participation by
academics is a huge deal, myself).

Melinda

--
Melinda Shore
melinda.shore@= gmail.com

Software longa, hardware brevis
--00000000000004afac058455be9c-- From nobody Sun Mar 17 20:39: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 A3028131047; Sun, 17 Mar 2019 20:39:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema via Datatracker To: Cc: draft-ietf-iasa2-rfc4071bis.all@ietf.org, iasa20@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Christian Huitema Message-ID: <155288034847.13672.14199489874309036711@ietfa.amsl.com> Date: Sun, 17 Mar 2019 20:39:08 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-iasa2-rfc4071bis-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: Mon, 18 Mar 2019 03:39:09 -0000 Reviewer: Christian Huitema Review result: Ready I have reviewed this draft-ietf-iasa2-rfc4071bis-08 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 Ready. As stated in the introduction, this draft "describes the structure of the IETF Administrative Support Activity, version 2 (IASA 2.0). It defines the roles and responsibilities of the IETF LLC Board, the IETF Executive Director, and ISOC in the fiscal and administrative support of the IETF standards process. It also defines the membership and selection rules for the IETF LLC Board." The document is well written and easy to read. It does not describe any specific technology or propose standard, and the security consideration as just pro-forma, stating that "This document ... introduces no security considerations for the Internet." Which appears true. Security impact, if any, would be indirect. One could imagine that some malevolent third party might apply pressure on the LLC staff, the board members, or ISOC, with a goal of compromising the standard process and allowing publication of insecure standards. But this hypothetical pressures could probably happen just as well in the current structure. In fact, the draft's emphasis on clear process and transparency provides additional protection, which confirms the assessment that this document "introduces no security considerations for the Internet." From nobody Sun Mar 17 23:27: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 020501310EF for ; Sun, 17 Mar 2019 23:23:52 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 jPegklDRDlnD for ; Sun, 17 Mar 2019 23:23:49 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 7E0901277CD for ; Sun, 17 Mar 2019 23:23:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1552890228; x=1584426228; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=r31yifZ/3KbW5M5qpfHFrTZmZFen+oENCVo12aERorg=; b=LnIdUlHUzaFNHbEi59STNU4N+wpNZi83VrZpFJMqRDY04T3GD5xqe9gI WEsghFwCyVPZTUBt2aN6VCybTIWdWNk+PU0XNPFX4Yt2QoFozl/uRHYQO 7JYkF5y94A3iEarDcq/YBhXvLIHWVzbipjLnLrmqKcRxdr4YtlTxCY00l T/H8fM1PZgBIcvMBzyYULYDEDQ0LoHpQgSgLKpaLpiOx8K1ftRgxASkT7 j8sNM3WLe0vnISW5PyDPlN0Mk6nnIDOkFL0nqNymULVGYOIatcZ1jzBKx H6KlwH9+IBTlwXb4aSbnNCm2eBrisMtKoh36h9lcAureVPaNNBaeNCu28 g==; X-IronPort-AV: E=Sophos;i="5.58,492,1544439600"; d="scan'208";a="52114652" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from uxcn13-tdc-e.uoa.auckland.ac.nz ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 18 Mar 2019 19:23:44 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 18 Mar 2019 19:23:43 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Mon, 18 Mar 2019 19:23:43 +1300 From: Peter Gutmann To: denis bider , Melinda Shore CC: Uri Blumenthal , CFRG , "RFC ISE (Adrian Farrel)" , secdir Thread-Topic: [Cfrg] [secdir] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts Thread-Index: AQHU3KN7/iAYTjlOe029ckclYOzjQaYO4aoAgADe4wCAAAbmAIAAFcsAgAEPmFw= Date: Mon, 18 Mar 2019 06:23:43 +0000 Message-ID: <1552890164140.4569@cs.auckland.ac.nz> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> <679B6759-5AD3-4F28-9EF4-8794F383468B@mit.edu> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 06:23:52 -0000 denis bider writes:=0A= =0A= >SSH is full of underdocumented, partly functional custom extensions (to=0A= >cryptography, compression, SFTP, port forwarding, host key synchronization= ,=0A= >VPN, and more), most of which could be better designed, better documented = and=0A= >standardized=0A= =0A= +1. Mind you given the hassle in setting up a WG for it and getting things= =0A= through the IETF, it might be easier to just set up a Github repository for= =0A= documentation on what does what and how and rely on Google to point people = to=0A= it.=0A= =0A= Peter.=0A= From nobody Sun Mar 17 23:53:43 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 811BE1310E5 for ; Sun, 17 Mar 2019 23:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 ISndTmZ6u6K4 for ; Sun, 17 Mar 2019 23:53:31 -0700 (PDT) Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) (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 78E591310F1 for ; Sun, 17 Mar 2019 23:53:31 -0700 (PDT) Received: by mail-pf1-x444.google.com with SMTP id s23so10602493pfe.13 for ; Sun, 17 Mar 2019 23:53:31 -0700 (PDT) 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-language:content-transfer-encoding; bh=ISfMpLHNUosTlRXkcWWPqsq2YaNh1qQh65WrC6Vgo14=; b=bdbDEPLTWkIaaNfwATg7Bo6jufgaZBFYsjzw6pXZ1PkbpargZn8vysQZdUPfYFjGuy c8DmyM9IpHeJdWtn1SjdsMvEK8gVba3fpBKeAKxEyj9LKkWiIst5uW+u1v6ywQymcgzZ JHQIXxQcUbXaAX2QfhQV60Cnq0MZk+s2/ujjyieW7Z6BxCxXgDV+qLvau0BY7JPEzboP G1tOf1ifqeai4F56Y90zWxLf8kPHRncdWGeccPrLLzbzc81qjrhKBVwQ6zZjZpIS9D/M IN+u6IKTSJQNtIN5TnQDNymR/WZqQxun6NbAy3qBxuiwVNIgYjJLklY3hQEkHGwEybT6 404g== 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-language :content-transfer-encoding; bh=ISfMpLHNUosTlRXkcWWPqsq2YaNh1qQh65WrC6Vgo14=; b=TAaHhR/OGqCsCKgjXPfW+hXhvBTDnlh7jFzKXejIKcIeZWE3c3StJ/3uZ0gmrNYA7E e+j6VtOi6TeBDpKarqkkAmVj16e5LSEViwNZb4eG+lqA6lN5QMEyZeeRDR4eCN2JQD7V sOwUJ7yjoQZz00wx0WpYPS1w86kaT0MyrQptrKqSbQ2bla6twngfqsJzDtTgQRi3ZnSV LytOPAwb34B1tlSbZJFqOu34sxkac/TA0E+lX20d7A0ynMxGNPG4DZ0zI/PUDChJEVbF X7gRQESvL0H6O5y24X7gNz5kygHwALRIPIW8KDQlK1NCv87coU8fo3uoueyio17Bs1Cy YH4g== X-Gm-Message-State: APjAAAXnIG9bTm3uJlkNnKtsx+FkiaWN/sTkIpn1KEVWA9fnhxifqNZo iWr67ibe9VDvoWDrYOA8TCjXOlYl X-Google-Smtp-Source: APXvYqxLqBLFj1vKgmaxZYgEwz1QqJ/XKDRaAGotd3gLOM1gUMjcal4AT0hDrBldByPPRuP2KQmHYA== X-Received: by 2002:a65:47cb:: with SMTP id f11mr16354086pgs.18.1552892010612; Sun, 17 Mar 2019 23:53:30 -0700 (PDT) Received: from aspen.local ([216.67.81.206]) by smtp.gmail.com with ESMTPSA id i72sm18795142pfj.147.2019.03.17.23.53.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Mar 2019 23:53:30 -0700 (PDT) To: Peter Gutmann , denis bider Cc: Uri Blumenthal , CFRG , "RFC ISE (Adrian Farrel)" , secdir References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> <679B6759-5AD3-4F28-9EF4-8794F383468B@mit.edu> <1552890164140.4569@cs.auckland.ac.nz> From: Melinda Shore Message-ID: <674d964f-46c6-ee67-9e33-5cb480c2a6ef@gmail.com> Date: Sun, 17 Mar 2019 22:53:28 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <1552890164140.4569@cs.auckland.ac.nz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 06:53:34 -0000 On 3/17/19 10:23 PM, Peter Gutmann wrote: > +1. Mind you given the hassle in setting up a WG for it and getting things > through the IETF, it might be easier to just set up a Github repository for > documentation on what does what and how and rely on Google to point people to > it. I think this may be closer to the core issue ("the hassle in setting up a WG"). Moving something from the IRTF to the IETF is likely to slow down the publication process, frankly. IRTF RFCs do require review by the IRSG and the IESG but they are not IETF consensus documents (see RFC 5743 for details on the IRTF document stream process). Second, note that CFRG does not typically work on protocols, per se, and when it does it's limited to things like specific key exchange mechanisms rather than all-the-things-missing-from-pgp. I agree there's a broader problem here but I don't see how it would be addressed by moving CFRG, which doesn't work on most of the problem areas mentioned, anyway, to a body with weightier process requirements and slower processes. I'll note that we haven't seen that many drafts addressing these proposed ssh extensions and given that we're a document-driven organization that also makes progress difficult. I'm personally very interested in lowering barriers to contribution. That's a tough one to address because tautology, but seems related to your concerns. Melinda -- Melinda Shore melinda.shore@gmail.com Software longa, hardware brevis From nobody Mon Mar 18 06:27:18 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 EA3631279AB for ; Mon, 18 Mar 2019 06:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 oYL_LZhnlUCC for ; Mon, 18 Mar 2019 06:27:02 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53EFA131106 for ; Mon, 18 Mar 2019 06:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3002; q=dns/txt; s=iport; t=1552915622; x=1554125222; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=b7PmDkUODLVKFLuMBlJo/24B0DzXk1ztFDxHmEb2H/c=; b=mhGUd0qxCN0dgxXJoUBAdE7tyTXOREZGiY0wpf3Q2cJQ/TcH4iF9SNsr rwWXqAhogmA528TCaEl0fuMqAoVQQTw6ORb2Cp9Ojg/vGeArhisX49LKH sxYOXm2vvaf4MGvWOaZI/WAyFjdBPXbUqp1ED6ja0BAwNYclr5IxK41Ct U=; IronPort-Data: A9a23:/M2sxqi8bWvWumHMnCpIA3BsX17brhtdw9mghKucQGNkapYi63mVu1 su/5QZ51z+c2MlfchyVmY9+werCh0bVsz+/M7NbGE5zI/selH/B+d7M0Qc+ht6Bx4f6ZL3xt YqgjsSL41aKXUK9U4IidBaHR4pcWp4TmJJyGDDohhKhlPitsO8zt6fLItoUf/CNjA8u6FLUu 0E1nQJyT+JxdevdE9LdT3qWDBbeOXb9herdlGNhd4foAv0Phv6xngnlx6dQaWVHRnQmPIN2y 1Hm3IQxDpZ7sfVbRop0srbu0zV+26viW9ywscn3El6Cnva7wTs3UBdhlNhnwcgeReT3Lu7k9 nGw2SfUg6V+fFXMlINnWYcPYGK6hdp2etMuAFLyl2yUDRsgBjDzlCEuxZsHuzYMpsAqDYkwJ Yu7zuXPse0oG4njBl2LW5wKCmkjbLzSNG2O/hCWpPppYJ3OYbO4FdjG5iio9RzFb+vXK7kkm pn2Pg/bY+EiTJIIkxW0taK6mP7bWXtnsXImgx5ICQNDVtsnPIwjQxc6qEluwhJa6CwotJLPf 8/2zZb/ve/b7DofzDd6VRVZ8EQxbB0J26obehmQ0b3WqZxI5+JomK5ZmhWE5jffUj9a3UxSv SXfjRw/XOV/V4h2Nt9mhilbPkje9pP18osINL4YLyiQv5arCxodUaK8GqSG6ZyN7Biu8ApP+ CRhOUf9ZtBBklbbViiKR46FpaEo7/57ZmdMne6JtGmiB6mvNQ5Qv//c034+EUix2DJ4WQi6U biOkD7ok0sWKVjvw== X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAACFm49c/4kNJK1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUgMBAQEBAQsBgWYqaIEDJwqXPoFoJZgxgXsLAQEYC4R?= =?us-ascii?q?JAoRYIjUIDQEBAwEBCQECAQJtHAyFSgEBAQMBAQElEzQLBQsLCQ8eBQsnMAY?= =?us-ascii?q?OBYMiAYFtCA+qbDOEREGFHAWBLwGJbIFDF4E/QIERJwwTgh4ugx4BAQMBgT0?= =?us-ascii?q?BAR6DO4ImA4oDMx+aAAmDQIQbi0oZk1eDS400ihOCcAIRFYFJATWBVnAVOyo?= =?us-ascii?q?Bgg0BMz6BWBcTbQEBh12FWyMBATGMFoEfAYEeAQE?= X-IronPort-AV: E=Sophos;i="5.58,494,1544486400"; d="scan'208";a="246451413" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Mar 2019 13:27:01 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x2IDR1OH004145 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Mar 2019 13:27:01 GMT Received: from rtp-mcgrew-nitro3.cisco.com (10.117.145.148) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Mar 2019 08:27:00 -0500 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: mcgrew In-Reply-To: <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> Date: Mon, 18 Mar 2019 09:26:47 -0400 CC: Richard Barnes , secdir , CFRG , "RFC ISE (Adrian Farrel)" Content-Transfer-Encoding: quoted-printable Message-ID: <5D247CD2-710E-4C78-8495-085C70D4CFAB@cisco.com> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> To: Michael StJohns X-Mailer: Apple Mail (2.3445.102.3) X-Originating-IP: [10.117.145.148] X-ClientProxiedBy: xch-rcd-015.cisco.com (173.37.102.25) To XCH-ALN-004.cisco.com (173.36.7.14) X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 13:27:11 -0000 Hi Mike, Let me add few data points from a CFRG-historical perspective. CFRG has = been the first publisher of a number of specifications (for instance, = XMSS, Poly1305, and HBS are in this category - = https://datatracker.ietf.org/rg/cfrg/documents/) and has done essential = review for some ISE-published crypto like UMAC (RFC 4418). For UMAC, = it is worth noting that the ISE reviewers asked for changes around IPR = language, and CFRG reviewers made important improvements to the = technical content as well = (https://datatracker.ietf.org/doc/rfc4418/history/ and CFRG mail threads = from fall 2005). So the issues we are dealing with today are not really = new. =20 You have started a good, healthy discussion with the points that you = have raised. My thinking is that CFRG (including Kenny, Alexy, and the = many contributors) is doing really good, really important work, and the = IRTF and IETF should avoid changes that would disrupt it. =20 Best, David > On Mar 15, 2019, at 2:52 PM, Michael StJohns = wrote: >=20 > On 3/13/2019 7:32 AM, Richard Barnes wrote: >> Mike, are your concerns here primarily IPR related? If that's so, = then maybe that's the level at which we should address them, as opposed = to flipping the bigger RG->WG switch. >>=20 >=20 > Hi Richard - >=20 > Like I said, I'm not going to push this at this time. But I think its = more than just IPR - avoiding technology because of IPR is more a = symptom (and in fact is IETF guidance rather than IRTF policy). >=20 > The CFRG has a unique position in that - unlike ANY other RG as far as = I can tell - it's looked at as an immediate feeder for technology for = the IETF. If it were agnostically evaluating the crypto properties of = any offered technology, I'd say we're good and I'd move on. But, with = the publication of Curve25519 and its related ... standards ..., the = CFRG has moved from evaluation and re-publication of cryptographic = standards developed and produced elsewhere into being the first = publisher of what could only be characterized as standards, even if = published as an Informational RFC in the IRTF stream. >=20 > Ultimately, I think it comes down to fairness and transparency. As an = RG, the publications of the RG are not subject to the standards appeals = process. In an WG, the decision not to work on an IPR encumbered = technology (or others such as national cryptography) MAY be appealed and = overturned (or might not) or sponsored by an AD if there's no applicable = or agreeable WG. There's a process for showing such decisions were made = transparently, and with a broader audience than just the CFRG having a = say. >=20 >=20 > Later, Mike >=20 > Ps - hmm... Note that the CFRG charter only mentions the IETF and not = the IRTF.... >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg From nobody Mon Mar 18 08:51: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 0DE5A130E63 for ; Mon, 18 Mar 2019 08:51:36 -0700 (PDT) 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, 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 (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 Vg7K0_u3ykYQ for ; Mon, 18 Mar 2019 08:51:33 -0700 (PDT) Received: from mail-ot1-x343.google.com (mail-ot1-x343.google.com [IPv6:2607:f8b0:4864:20::343]) (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 BDCA7128B36 for ; Mon, 18 Mar 2019 08:51:33 -0700 (PDT) Received: by mail-ot1-x343.google.com with SMTP id u15so4723884otq.10 for ; Mon, 18 Mar 2019 08:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VLRIhXj7M4aCNmugYsTogJXlQiQH0SFuVQJeqExiQdo=; b=IojMhzCW0KYOYe9m3/o6puBn/XWVrFknA+rlBHUM7zt1p5A0H/xae2yL5Klt1/Jv/f kh8OIqpcHb9YeyVe/7/jizfIEJg9plPr7q8t7+/KAhlM9SQ+Tk3pAZK07J4ZT1MKTudT jwn7X03fUGPozDcxhqMR0duevBZyCJDOKXOmWClSWdqLcG0dqge6JB5UqmxkfB6uxcXy gBxL1yiYEaPkNH/FpcGAGSwt9OQvWQuBCrkclH3lXMQdPjakgpbrodcFCGbSpx/VPB28 MILMWt1Ja6o9LJZXXRzS5ncAwFbGWsJ8EhYO3EXTrQ3JqED+ZrUnXT6nSTWQAsCfaPDq i42w== 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=VLRIhXj7M4aCNmugYsTogJXlQiQH0SFuVQJeqExiQdo=; b=lzOk1GmpgQXojrcSAN3Flq/VpySY+tYiba2nMlRwugL05dk43y7lvYCVGgcGPPJlOU kCAj/EHc6efKUQy3QBBmW2owFgzj9dE9OAVyn+fVKq8XrFOAsBXcdwImGca7B6WqrxjJ BAWWgmExZ66fluk53eRPw/iL/XB7RjKPeZOB1VhvTsl3vlf872v/m638Q/RAD7wg2qIq Als4aGpFs9GbA3s89HioTz6u9O+aOXO/C1Sca0lte2RIJwBfNNasz0n8ma1RKtbjzUBf udDNUAhxv8Dm8wv99ZK0IkZOFy4ohctfJDdsxgMgXL5MYUnaaWtpYJHpnpulRL/biNbO bkjA== X-Gm-Message-State: APjAAAXVPKP7pNzL26cqAOeqFSXkqe/lJdvNN5QnxChXVlv8G/rPSbl0 pdDsBMRZpnNLfyHhvFPDaFDGLwSx7cROzDnZyJI= X-Google-Smtp-Source: APXvYqwNZTPmFMreOwlIF9UARYIqE5eagWUz8z9lQYvQDZkm7TGxIax1dcWA9wr+3VW8rjcJcA1NnIW1kA3M3RSfg3g= X-Received: by 2002:a9d:7697:: with SMTP id j23mr10690910otl.344.1552924293107; Mon, 18 Mar 2019 08:51:33 -0700 (PDT) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> <679B6759-5AD3-4F28-9EF4-8794F383468B@mit.edu> <1552890164140.4569@cs.auckland.ac.nz> In-Reply-To: <1552890164140.4569@cs.auckland.ac.nz> From: denis bider Date: Mon, 18 Mar 2019 10:51:20 -0500 Message-ID: To: Peter Gutmann Cc: Melinda Shore , Uri Blumenthal , "RFC ISE (Adrian Farrel)" , secdir , Martin Thomson Content-Type: multipart/alternative; boundary="000000000000da935b0584605c1e" Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 15:51:36 -0000 --000000000000da935b0584605c1e Content-Type: text/plain; charset="UTF-8" (removed CFRG from CC since not directly relevant) Exactly. Currently, the direction of SSH is dictated by OpenSSH, which is the de facto standard (in a loose alliance with other open source implementations like libssh and PuTTY). I'm not sure about the personal circumstances of each individual involved with these projects, but the requirements of IETF's "rigorous" processes are "rigorous"; and the motivation for volunteers to participate is approximately none. Yet these volunteers, as a group, determine the protocol's direction. As a standards organization, IETF is not competing with ISO (which requires anyone who wants to achieve something to travel to places like Hawaii), it is competing with GitHub. When OpenSSH wants to do something, they don't start a WG, they just publish stuff in their PROTOCOL file: https://github.com/openssh/openssh-portable/blob/master/PROTOCOL Currently: - The dominant encryption mechanism in SSH is not specified by IETF. It is " aes128-gcm@openssh.com" and "aes256-gcm@openssh.com", documented in that PROTOCOL file. - Encrypt-then-MAC in SSH is not specified by IETF. It is vaguely documented in that PROTOCOL file. - Host key synchronization (an extremely useful feature) is not specified by IETF - it's in that PROTOCOL file. This is just the tip of the iceberg. The PROTOCOL file contains a bunch of other things that are underspecified and under-standardized, but IMPLEMENTED, because no one wants to follow the IETF's "rigorous" process to charter a WG for every change. What makes this tragic is that it's unnecessary. SSH version 2 was standardized as an IETF WG. Then, because of the IETF rules, the WG disbanded. The IETF is literally handing off standardization to be done half-assedly at GitHub, and treating this as a success. On Mon, Mar 18, 2019 at 1:23 AM Peter Gutmann wrote: > denis bider writes: > > >SSH is full of underdocumented, partly functional custom extensions (to > >cryptography, compression, SFTP, port forwarding, host key > synchronization, > >VPN, and more), most of which could be better designed, better documented > and > >standardized > > +1. Mind you given the hassle in setting up a WG for it and getting things > through the IETF, it might be easier to just set up a Github repository for > documentation on what does what and how and rely on Google to point people > to > it. > > Peter. > --000000000000da935b0584605c1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(removed CFRG from CC since not dire= ctly relevant)

Exactly. Currently, the direction o= f SSH is dictated by OpenSSH, which is the de facto standard (in a loose al= liance with other open source implementations like libssh and PuTTY).
=

I'm not sure about the personal circumstances of ea= ch individual involved with these projects, but the requirements of IETF= 9;s "rigorous" processes are "rigorous"; and the motiva= tion for volunteers to participate is approximately none. Yet these volunte= ers, as a group, determine the protocol's direction.

As a standards organization, IETF is not competing with ISO (which r= equires anyone who wants to achieve something to travel to places like Hawa= ii), it is competing with GitHub. When OpenSSH wants to do something, they = don't start a WG, they just publish stuff in their PROTOCOL file:
=


Currently:

- The dominant encryption mechanism in SSH is not specified by IETF. It i= s "aes128-gcm@openssh.com" and "aes256-gcm@open= ssh.com", documented in that PROTOCOL file.

- Encrypt-then-MAC in SSH is not specified by IETF. It is vaguely docume= nted in that PROTOCOL file.

- Host key synchroniza= tion (an extremely useful feature) is not specified by IETF - it's in t= hat PROTOCOL file.

This is just the tip of the ice= berg. The PROTOCOL file contains a bunch of other things that are underspec= ified and under-standardized, but IMPLEMENTED, because no one wants to foll= ow the IETF's "rigorous" process to charter a WG for every ch= ange.

What makes this tragic is that it's unne= cessary. SSH version 2 was standardized as an IETF WG. Then, because of the= IETF rules, the WG disbanded.

The IETF is literal= ly handing off standardization to be done half-assedly at GitHub, and treat= ing this as a success.


On Mon, Mar 18, 2019 at 1:= 23 AM Peter Gutmann <pgut00= 1@cs.auckland.ac.nz> wrote:
denis bider &l= t;denisbider= .ietf@gmail.com> writes:

>SSH is full of underdocumented, partly functional custom extensions (to=
>cryptography, compression, SFTP, port forwarding, host key synchronizat= ion,
>VPN, and more), most of which could be better designed, better document= ed and
>standardized

+1.=C2=A0 Mind you given the hassle in setting up a WG for it and getting t= hings
through the IETF, it might be easier to just set up a Github repository for=
documentation on what does what and how and rely on Google to point people = to
it.

Peter.
--000000000000da935b0584605c1e-- From nobody Mon Mar 18 09:07:40 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 1F45213129E for ; Mon, 18 Mar 2019 09:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 gXN5LdehI5jC for ; Mon, 18 Mar 2019 09:07:30 -0700 (PDT) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (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 C9A7D1311D2 for ; Mon, 18 Mar 2019 09:07:29 -0700 (PDT) Received: by mail-lj1-x242.google.com with SMTP id j89so3135636ljb.1 for ; Mon, 18 Mar 2019 09:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eQc+SRPE05oziKYsI7uXShnAHcfOifr8BEHXPhLiaOA=; b=u3tugVewUpY4ucZQmGO8KfawlnmBZLtMTA2xffAZm2lvfbENpf5/ISX1hBU4BMuyYX lQKcMETEHpZSFVjfQ9I6M1h9NH5tfHcDI1HR+XATSTLaJSR3agnJTfJDd9LU68bBuL+L qvzJEJoRCEFL9cB7oCww+sP416gIL/ohedU3n6KHoxDIIW9KI7PXIymTmqRbAhlJlw81 H5Jq1FKL4/Cor6DOAEKT5+10aozZtdz/9rq2oMw7ZgBMXjE0LdlYdstytcuQV6rXZm2K OPwY58gNF4/tYHFna0MRH3UUxRL2/fbu4ofgJVvGqpcbdIe3j7YptnUUAWoO8PtQGAu8 OMkQ== 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=eQc+SRPE05oziKYsI7uXShnAHcfOifr8BEHXPhLiaOA=; b=VCmhylju/WqVFVy+GY674ZoFC826yQPmqYeUwvxReIr2XhcyM1I0LleN/8bPDJB/11 vaIRJ9FjhKWegmeTaZzgwhtzmBly2V0teN8LagJwR6d5twR8u+0+z/CC0xiFCrBVCJIY s0ugnw7RdLWSUjeoNeMP5hh98AobDogN4TDtLWMGiYax/h1KzlmEWRjwWo65wroykic0 TbfuMlM8WolJIl955V40QPRSitSdFoip0BgLTILNpL0y54HqWMa3qF4xx4ze+UhUOFH3 IF8ZeKQil/76c+xPuZgJmRZurTXmvIHiTg2cTIhjZNitd/Vy5yBdvPK9LuWHjhdpHMoq 15wg== X-Gm-Message-State: APjAAAWtf1/WY+N1eS8ixl2hcmYTm1pLLmZ1QMFqcWhLVh3ycybqFuGS j73EWS6183PHQx0K7evhwdmfjeds5mTVW0VzAEk= X-Google-Smtp-Source: APXvYqzLUFhawMd1xZgztgdvi7rNafDoGkJHhIRN2PpTFrCWPYSpaRW9xI6whi2NMG2SYZKAKPJ/D+xlkxBX97JxPxk= X-Received: by 2002:a2e:312:: with SMTP id 18mr11805325ljd.114.1552925248043; Mon, 18 Mar 2019 09:07:28 -0700 (PDT) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> <679B6759-5AD3-4F28-9EF4-8794F383468B@mit.edu> <1552890164140.4569@cs.auckland.ac.nz> In-Reply-To: From: Watson Ladd Date: Mon, 18 Mar 2019 09:07:16 -0700 Message-ID: To: denis bider Cc: Peter Gutmann , Martin Thomson , "RFC ISE (Adrian Farrel)" , secdir Content-Type: multipart/alternative; boundary="000000000000c5c1c30584609547" Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 16:07:38 -0000 --000000000000c5c1c30584609547 Content-Type: text/plain; charset="UTF-8" On Mon, Mar 18, 2019, 8:51 AM denis bider wrote: > (removed CFRG from CC since not directly relevant) > > Exactly. Currently, the direction of SSH is dictated by OpenSSH, which is > the de facto standard (in a loose alliance with other open source > implementations like libssh and PuTTY). > > I'm not sure about the personal circumstances of each individual involved > with these projects, but the requirements of IETF's "rigorous" processes > are "rigorous"; and the motivation for volunteers to participate is > approximately none. Yet these volunteers, as a group, determine the > protocol's direction. > > As a standards organization, IETF is not competing with ISO (which > requires anyone who wants to achieve something to travel to places like > Hawaii), it is competing with GitHub. When OpenSSH wants to do something, > they don't start a WG, they just publish stuff in their PROTOCOL file: > > https://github.com/openssh/openssh-portable/blob/master/PROTOCOL > > Currently: > > - The dominant encryption mechanism in SSH is not specified by IETF. It is > "aes128-gcm@openssh.com" and "aes256-gcm@openssh.com", documented in that > PROTOCOL file. > > - Encrypt-then-MAC in SSH is not specified by IETF. It is vaguely > documented in that PROTOCOL file. > > - Host key synchronization (an extremely useful feature) is not specified > by IETF - it's in that PROTOCOL file. > > This is just the tip of the iceberg. The PROTOCOL file contains a bunch of > other things that are underspecified and under-standardized, but > IMPLEMENTED, because no one wants to follow the IETF's "rigorous" process > to charter a WG for every change. > > What makes this tragic is that it's unnecessary. SSH version 2 was > standardized as an IETF WG. Then, because of the IETF rules, the WG > disbanded. > > The IETF is literally handing off standardization to be done half-assedly > at GitHub, and treating this as a success. > Forgive me for thinking this represents running code and rough consensus. What is the benefit of turning these enhancements into RFCs to the OpenSSH project? Also other streams then the IETF one exist. So what actually is the problem that needs solving with SSH? > > > On Mon, Mar 18, 2019 at 1:23 AM Peter Gutmann > wrote: > >> denis bider > >> writes: >> >> >SSH is full of underdocumented, partly functional custom extensions (to >> >cryptography, compression, SFTP, port forwarding, host key >> synchronization, >> >VPN, and more), most of which could be better designed, better >> documented and >> >standardized >> >> +1. Mind you given the hassle in setting up a WG for it and getting >> things >> through the IETF, it might be easier to just set up a Github repository >> for >> documentation on what does what and how and rely on Google to point >> people to >> it. >> >> Peter. >> > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > --000000000000c5c1c30584609547 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Mar 18, 2019, 8:51 AM denis bider <= denisbider.ietf@gmail.com> wrote:
(removed CFRG from CC since no= t directly relevant)

Exactly. Currently, the direc= tion of SSH is dictated by OpenSSH, which is the de facto standard (in a lo= ose alliance with other open source implementations like libssh and PuTTY).=

I'm not sure about the personal circumstances= of each individual involved with these projects, but the requirements of I= ETF's "rigorous" processes are "rigorous"; and the = motivation for volunteers to participate is approximately none. Yet these v= olunteers, as a group, determine the protocol's direction.
As a standards organization, IETF is not competing with ISO (w= hich requires anyone who wants to achieve something to travel to places lik= e Hawaii), it is competing with GitHub. When OpenSSH wants to do something,= they don't start a WG, they just publish stuff in their PROTOCOL file:=

=

Currently:

- The dominant encr= yption mechanism in SSH is not specified by IETF. It is "aes128-gcm@openssh.com" and "aes256-gcm@open= ssh.com", documented in that PROTOCOL file.

- Encrypt-then-MAC in SSH is not specified by IETF. It is vaguely docume= nted in that PROTOCOL file.

- Host key synchroniza= tion (an extremely useful feature) is not specified by IETF - it's in t= hat PROTOCOL file.

This is just the tip of the ice= berg. The PROTOCOL file contains a bunch of other things that are underspec= ified and under-standardized, but IMPLEMENTED, because no one wants to foll= ow the IETF's "rigorous" process to charter a WG for every ch= ange.

What makes this tragic is that it's unne= cessary. SSH version 2 was standardized as an IETF WG. Then, because of the= IETF rules, the WG disbanded.

The IETF is literal= ly handing off standardization to be done half-assedly at GitHub, and treat= ing this as a success.

Forgive me for thinking this represen= ts running code and rough consensus. What is the benefit of turning=C2=A0 t= hese enhancements into RFCs to the OpenSSH project?
=
Also other streams then the IETF one exist. So = what actually is the problem that needs solving with SSH?


On Mon, Mar 18, 2019 at 1:23 AM= Peter Gutmann <pgut001@cs.auckland.ac.nz> wrot= e:
denis bider <denisbider..= ietf@gmail.com> writes:

>SSH is full of underdocumented, partly functional custom extensions (to=
>cryptography, compression, SFTP, port forwarding, host key synchronizat= ion,
>VPN, and more), most of which could be better designed, better document= ed and
>standardized

+1.=C2=A0 Mind you given the hassle in setting up a WG for it and getting t= hings
through the IETF, it might be easier to just set up a Github repository for=
documentation on what does what and how and rely on Google to point people = to
it.

Peter.
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listi= nfo/secdir
wiki: http://tools.ietf.o= rg/area/sec/trac/wiki/SecDirReview
--000000000000c5c1c30584609547-- From nobody Mon Mar 18 09:48:25 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 0238A131135; Mon, 18 Mar 2019 09:48:24 -0700 (PDT) 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] 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 2OTjvVftbSrY; Mon, 18 Mar 2019 09:48:20 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 7D24E13111D; Mon, 18 Mar 2019 09:48:20 -0700 (PDT) Received: from 200116b82c0c770005beac1cb9537e4d.dip.versatel-1u1.de ([2001:16b8:2c0c:7700:5be:ac1c:b953:7e4d]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1h5vQv-0004Di-BF; Mon, 18 Mar 2019 17:48:17 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Mirja Kuehlewind In-Reply-To: <04aace0d-805a-406a-b44b-ffdb44a4e9df@gmail.com> Date: Mon, 18 Mar 2019 17:48:16 +0100 Cc: Zaheduzzaman Sarker , "gen-art@ietf.org" , "rmcat@ietf.org" , "ietf@ietf.org" , "draft-ietf-rmcat-eval-test.all@ietf.org" , "secdir@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <21441EC1-01EB-482E-810F-9A9AC223D7CB@kuehlewind.net> References: <154930852182.28785.5364082865560557648@ietfa.amsl.com> <104FE636-0A18-4E3B-B7BD-F2DA3748161B@ericsson.com> <04aace0d-805a-406a-b44b-ffdb44a4e9df@gmail.com> To: Stewart Bryant X-Mailer: Apple Mail (2.3445.101.1) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1552927700;4d7683ef; X-HE-SMSGID: 1h5vQv-0004Di-BF Archived-At: Subject: Re: [secdir] Genart last call review of draft-ietf-rmcat-eval-test-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: Mon, 18 Mar 2019 16:48:24 -0000 Hi Stewart, Thanks for your review and your careful consideration of potential = risks. I wasn=E2=80=99t aware of RFC6815 and it=E2=80=99s an interesting = reference, however, in the case of rmcat testing, I think it=E2=80=99s = actually not similarity applicable. While benchmarking is designed to = test extreme cases, in congestion control testing we are aiming for = =E2=80=9Crealistic cases=E2=80=9D that emulate real traffic as you will = find it on the Internet today. It=E2=80=99s important to make clear in = the draft that these tests are designed for lab tests or simulations and = not to be run over the Internet, and I think the authors can add more = wording for this, but the risks are lower than for RFC6815 and therefore = I don=E2=80=99t think we need to have that reference here. Mirja > On 15. Feb 2019, at 12:45, Stewart Bryant = wrote: >=20 > Hi Zahed >=20 > The work that made me particularly conscious of the security issue in = this draft was RFC6815, and although RFC6815 applies to RFC2544, I would = imagine that the same considerations apply here. Perhaps a reference to = RFC6815 would help the reader of this draft better appreciate the danger = of running these tests outside the lab. >=20 > I note that a statement on the need to run these tests in a controlled = environment was not added to the Abstract, something which might be = useful in highlighting the danger to someone supervising a lab, but not = involved in the detail. >=20 > It is really for the security directorate to decide their position, = but I would have thought that it was better to emphasis (with RFC2119 = language) the real danger to production networks (of all flavours, not = just the Internet) of this test traffic leaking and causing disruption. >=20 > I will leave this issue with the security reviewer from here on and = take a look at the other text changes. >=20 > - Stewart >=20 >=20 > On 07/02/2019 13:27, Zaheduzzaman Sarker wrote: >> Hi Stewart, >>=20 >> Thanks for a good review. >>=20 >> For the security consideration section, we can use stronger words if = that is required. This document merely specifies test cases when people = are testing their algorithm in a controlled environment and does not = specify protocol usage. I was wondering if using normative language is = an overkill here. For those reasons we are actually thinking of taking = out 2119 usage completely. I have a modified text proposal below. >>=20 >> Please see inline below for more. >>=20 >> BR >> Zahed >> =20 >> =EF=BB=BFOn 2019-02-04, 20:29, "Stewart Bryant" = wrote: >>=20 >> Reviewer: Stewart Bryant >> Review result: Almost Ready >> I am the assigned Gen-ART reviewer for this draft. The = General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >> For more information, please see the FAQ at >> . >> Document: draft-ietf-rmcat-eval-test-08 >> Reviewer: Stewart Bryant >> Review Date: 2019-02-04 >> IETF LC End Date: 2019-02-11 >> IESG Telechat date: Not scheduled for a telechat >> Summary: >> A well written documents an close to being ready for = publication. >> I am concerned that the Security section is weak on use = outside a >> controlled environment. >> There are a fair number of minor issues and nits that need = attention, >> but most of them are simple to fix. >> One concern that I have that I doubt is readily fixable is = that long >> multi-nested lists do not work well in paginated ASCII with line = spaces >> and sometimes it is difficult to be sure of the context of a test = element note. >>=20 >> [ZS] I share the concern here, but I don=E2=80=99t think I have a = better alternative now. >> Major issues: >> 8. Security Considerations >> The security considerations in = [I-D.ietf-rmcat-eval-criteria] and the >> relevant congestion control algorithms apply. The principles = for >> congestion control are described in [RFC2914], and in = particular any >> new method MUST implement safeguards to avoid congestion = collapse of >> the Internet. >> The evaluation of the test cases are intended to be run = in a >> controlled lab environment. >> SB> I wonder if there shouldn't me a MUST in that sentence? >> SB> There have been issues on SP networks with users running = unsuitable >> SB> performance benchmarks on live networks, including complaints = to the >> SB> operators concerning the results achieved. >> Hence, the applications, simulators and >> network nodes ought to be well-behaved and should not impact = the >> desired results. It is important to take appropriate caution = to >> avoid leaking non-responsive traffic from unproven congestion >> avoidance techniques onto the open Internet. >> SB> Again I am surprised this is not much stronger in = prohibiting >> SB> use on the Internet. >>=20 >> [ZS] what about : >>=20 >> " The evaluation of the test cases are intended to be run in a >> controlled lab environment. Hence, the applications, simulators = and >> network nodes must be well-behaved and should not impact the >> desired results. Moreover, proper measures must be taken to >> avoid leaking non-responsive traffic from unproven congestion >> avoidance techniques onto the open Internet. " >> =3D=3D=3D=3D=3D=3D=3D=3D >> Minor issues: >> This memo describes a set of test cases for evaluating = congestion >> control algorithm proposals for real-time interactive media. >> SB> It would be useful to add here the statement in the = abstract that >> SB> these tests should be done in a controlled environment. >> [ZS] The abstract mentions the this "This document describes >> the test cases to be used in the performance evaluation of such >> congestion control algorithms in a controlled environment." >>=20 >> We can repeat that in the intro as well. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Expected behavior: depending on the convergence observed = in test case >> 5.1 and 5.2, the candidate algorithm may be able to avoid = congestion >> collapse. In the worst case, the media stream will fall to = the >> minimum media bit rate. >> SB> Do you need to specify the variant of TCP? You do state = it later, but some >> comment here would be useful. >>=20 >> [ZS] Not sure what would be useful to describe here more, the = expected behaviour is not really coupled to what TCP congestion control = is used, the general demand is to avoid congestion collapse here. >> SB> What behaviour do you expect the TCP to show. >> It would be bad if SB> an aggressive media application kill the = TCP completely. >>=20 >> [ZS] I don=E2=80=99t think we should say anything about TCP behaviour = here. The idea is to test the new congestion control behaviour with = available TCP behaviours not vice versa. But TCP can certainly improve = its performance from the test results (. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> the first flow >> (S1) MUST arrive at a steady-state rate approximately twice of = that >> of the other two flows (S2 and S3). >> SB> I am not sure what you mean by priority I assume that = you mean >> SB> QoS ranking in the routing system. In which case I don't see >> SB> how you can expect the result you specify. >>=20 >> [ZS] no this is not about routing priority on the network nodes, this = is at the media sender. When a media sender has multiple flows that = shares the same bottleneck then the media sender can use techniques to = distribute the available bandwidth to the multiple flows that it is = sending. The point here is the media flows should get their share of the = available bandwidth as per the priority set by the application. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Expected behavior: the candidate algorithm is expected to = achieve >> full utilization at both bottleneck links without starving any = of the >> three congestion controlled media flows. >> SB> I am not sure what you mean by this. Do you mean that = the bottlenecks >> SB> will saturate, but make no comment about how much of the = bottleneck >> SB> capacity each flow gets for itself? >>=20 >> [ZS] bottlenecks will saturate -- yes. The success criteria --- the = existence of multiple bottleneck should not result in flow starvation to = any flows that is sharing those bottlenecks. Yes, there is no comment on = fairness here explicitly. Not sure we need one here, do we? >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Nits/editorial comments: >> [ZS] thanks for those nits. will take care of them. >> Checking nits according to = https://www.ietf.org/id-info/checklist : >> = --------------------------------------------------------------------------= -- >> ** There are 9 instances of too long lines in the = document, the longest one >> being 4 characters in excess of 72. >> =3D=3D Outdated reference: A later version (-06) exists of >> draft-ietf-rmcat-wireless-tests-05 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> 3. Structure of Test cases >> SB> In the text below it was sometimes hard to get the = context right in the >> SB> triple (or more) nested list. Please consider using = subsections or some >> other SB> demarcation. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> + Bottleneck queue type: for example, Droptail, = FQ-CoDel, or >> PIE. >> SB> There need references, and by convention expansion on = first use. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> + Path loss ratio: characterizes the = non-congested, additive, >> losses to be generated on the end-to-end path. MUST >> SB> s/MUST/This MUST/ ? >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> B. Variation in sending bit rate and goodput. = Mainly observing >> the frequency and magnitude of oscillations. >> SB> goodput needs a reference or a definition. I don't think = it is a >> universally known term. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Expected behavior: the candidate algorithm is expected to = detect the >> path capacity constraint, converges to the bottleneck link's = capacity >> SB> s/converges/converge/ >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Due to asymmetric nature of the link >> SB> s/Due to/Due to the/ >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> SB> Is there a diagram error in the figure above? >> Figure 6: Testbed Topology for TCP vs congestion = controlled media >> Flows >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> have the same bandwidth share on the link. It has to = make it's way >> SB>s/it's/its/ >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> The candidate algorithm MUST reflect the relative priorities >> assigned to each media flow. In the previous example, >> SB> An explicit reference to the test would help the reader >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> =20 >=20 From nobody Mon Mar 18 10:20:29 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 B5BCB13111D for ; Mon, 18 Mar 2019 10:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 53uKsUjILBHE for ; Mon, 18 Mar 2019 10:20:24 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 F1C6D130E94 for ; Mon, 18 Mar 2019 10:20:23 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44NNH92CXzzDfX; Mon, 18 Mar 2019 18:20:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1552929621; bh=GoHOeFW3ZhNCTWrvP1bzPC3AQCtvImGSVzvF+4pG7J4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=DDlpQToQqVU2j/wa7ERbmmwe6w7GRxa0ivXRVV/Z/fmEFROrlJIvIHv+76P0e9bxv JnVaXxHb4FYemhS5ryRVFgClvheDnhA4qamaC2t436m1I1OCyjZbRX1txLnv/07Txr SGFP7BG9JGPH1tSOE0DhBHZHNzX6IqsUlgE3OgbI= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id f0CYBK3SDNqz; Mon, 18 Mar 2019 18:20:20 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 18 Mar 2019 18:20:19 +0100 (CET) Received: from [10.0.3.59] (unknown [62.168.35.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 9FC232FCD9; Mon, 18 Mar 2019 13:20:18 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 9FC232FCD9 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Mon, 18 Mar 2019 18:20:16 +0100 Cc: denis bider , secdir , "RFC ISE (Adrian Farrel)" , Martin Thomson , Peter Gutmann Content-Transfer-Encoding: quoted-printable Message-Id: References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> <679B6759-5AD3-4F28-9EF4-8794F383468B@mit.edu> <1552890164140.4569@cs.auckland.ac.nz> To: Watson Ladd Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 17:20:27 -0000 > On Mar 18, 2019, at 17:07, Watson Ladd wrote: >=20 >=20 >=20 >=20 > Forgive me for thinking this represents running code and rough consensus. Consensus is not =E2=80=9Cvague stuff from the PROTOCOLS file=E2=80=9D > What is the benefit of turning these enhancements into RFCs to the OpenSS= H project? Improved interoperability, more eyes looking at the protocols, facilitating a= n open internet without implicit vendor lock. > Also other streams then the IETF one exist. So what actually is the proble= m that needs solving with SSH? The standard should not be =E2=80=9Cbug compatible with the dominant impleme= ntation=E2=80=9D Paul= From nobody Mon Mar 18 10:50: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 6841D129AB8 for ; Mon, 18 Mar 2019 10:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 wC3XcZ1wqrTS for ; Mon, 18 Mar 2019 10:50:23 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 CD22712F1AB for ; Mon, 18 Mar 2019 10:50:14 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id b6so15425410iog.0 for ; Mon, 18 Mar 2019 10:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Oy8CweFbhgDwM7pncYDD15/XQOZous5p8gDCfoDrt44=; b=T7ms4zarBaeMMJFtcqezui4cJEIxRdPhgs6kiWfpG2XY03TqrBzuVLPwpgyPYtyMZw IJWQm31uv12tEDsqJq5cAFmekqaCzeOSFYbLfWsROFhWshDAuWHHsSaIgSn6Y/j4D9iT TWF5X2jprAtgsMG1m7bJpxKnCHQeD7d2sArHCmtUSyl1KZnT8LpPBwdRDVYU46u5Q12W AcuZI7QJvpwdF+ZCTxmBiNgE6SYWDs93bJCdnZMVOollKWeXBaTNnQunKcK53gKET4uR nO5Yjsw6/7w/tzm3pIRKkimoWZrvXUr4v6633EpBDKXwwYyrhQlZpJ+JU4xl/+vOmXxV r5RA== 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:content-transfer-encoding; bh=Oy8CweFbhgDwM7pncYDD15/XQOZous5p8gDCfoDrt44=; b=htVo7uwwssKsSmHd7LUX6vonQ/zODslHf7XvqR4urXjEfy8DeBn6svFcLHylQUxdvk oiwucglRG799MqD2dOMaG1wei7lcWM1nmoJG9mBjQm1uVgMizVuIuDDwUrOrXABr9zPl 6uwZYv1hvBYkazzdXsEMxB3Z+tINlZfZ5AOO+EF/GEDSIgrbHX6QrQ98z0WDRjm7EmVg xM6IfEf3qlINcTS+F0KvhlpnPWzrjpE6++rFyB1kr3LSsLHFa3e9t10YnIBj/D8Q6cZ7 ZxRGuXs5usN2qiXpOfJJFPEPgZaSm5tYCdoxAac0M1HVIMI7zXnY8RF/RA/vXng40iKg P7Rw== X-Gm-Message-State: APjAAAXLmD1BeaVF3l4aTnQLUA+3g5AqPEl/bJGOSSGcmAGtHEBSLvQy NLPOm1BV7HKBwhVug8lS/6Fd0yUqXsGTI7RFE54= X-Google-Smtp-Source: APXvYqyoGM2t9AlIoh/7+M8kCvqZAcm2stJxvK/3/nWpbKt/Hr/KIszwg4AKb9XqV0e1fmwGgDgG/DtfhC9BH6F0mo4= X-Received: by 2002:a6b:fd0f:: with SMTP id c15mr12398885ioi.132.1552931414008; Mon, 18 Mar 2019 10:50:14 -0700 (PDT) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> <679B6759-5AD3-4F28-9EF4-8794F383468B@mit.edu> In-Reply-To: From: Donald Eastlake Date: Mon, 18 Mar 2019 13:50:02 -0400 Message-ID: To: denis bider Cc: Uri Blumenthal , CFRG , "RFC ISE (Adrian Farrel)" , secdir Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 17:50:24 -0000 On Sun, Mar 17, 2019 at 9:29 PM denis bider wro= te: > > With regard to shutting down - I think that policy is doing an incredible= disservice to the internet, to both developers and users of protocols. There can also be inactive WGs that stop meeting (if they were having meetings) and don't have any active milestones they are working on but are still around. Or a WG's charter could be changed so that all it has to do it review related documents that come up. For example, for a while, PPPEXT was such a WG that existed just to review new documents that came along related to PPP. > ... > The way it works right now is, a group forms around standardizing a proto= col, the RFCs are done and the group disbands. Just like that, an entire co= mmunity that formed around that protocol disappears. When people want to in= troduce extensions, there's no longer anywhere to turn to. So development o= f extensions happens haphazardly, without discussion, without feedback, wit= hout coordination. The real community in the IETF is the mailing list which is normally continued when a WG terminates. So, in the cases I am familiar with, the community is still around. Although the PPPEXT WG was eventually terminated, the pppext@ietf.org mailing list still exists with PPP experts on it. > I think this policy (of shutting down WGs) is braindead, personally. Work= ing groups should shut down only for things that are actually dead. Not whe= n there's a temporary hiatus before the next version. What makes something "actually dead"? In any case, the IETF is what it is. It evolves slowly. There are always protocol/technical areas moving into the IETF and others moving out of the IETF. There are usually around 150 WGs these days. Presumably you would prefer this number to be much larger but that would imply more than changing philosophy on WG termination, such changes in management structure and funding. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com > On Sun, Mar 17, 2019 at 7:11 AM Uri Blumenthal wrote: >> >> If CFRG is doing what a WG is supposed to - what's the product is suppos= ed to produce, what are the milestones, and when is it supposed to wind dow= n, as any normal WG should when it's done the job it was chartered for? >> >> Sent from my test iPhone >> >> > On Mar 17, 2019, at 05:25, Paul Wouters wrote: >> > >> > >> >>> On Mar 16, 2019, at 12:30, Paterson Kenneth wrote: >> >> >> >> The rough consensus of those who joined the discussion is that we sho= uld leave the status of CFRG as it is for now. >> > >> > I wasn=E2=80=99t aware we were gathering consensus already and thought= we were just having a discussion. So seeing this cut short all of a sudden= with a tally seems wrong to me. >> > >> > So for consensus, I think that what CFRG is doing matches a WG more th= an an RG, and it would be more formally correct to change it. >> > >> > Paul >> > >> > >> > _______________________________________________ >> > secdir mailing list >> > secdir@ietf.org >> > https://www.ietf.org/mailman/listinfo/secdir >> > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg From nobody Mon Mar 18 12:57:54 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 EA05A12798C; Mon, 18 Mar 2019 12:57:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alan DeKok via Datatracker To: Cc: ietf@ietf.org, draft-cel-nfsv4-rpc-tls.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alan DeKok Message-ID: <155293906683.26184.494210804985115598@ietfa.amsl.com> Date: Mon, 18 Mar 2019 12:57:46 -0700 Archived-At: Subject: [secdir] Secdir early review of draft-cel-nfsv4-rpc-tls-02 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, 18 Mar 2019 19:57:47 -0000 Reviewer: Alan DeKok Review result: Not Ready I think that the document is fairly good, but could use additional text. It would a good idea for the authors to review RFC 6614 (RADIUS over TLS) and RFC 7360 (RADIUS over DTLS). Those documents both "patch" RADIUS to allow for TLS / DTLS transport. The RADIUS bits are perhaps uninteresting, but it is useful to learn from previous approaches to patching legacy protocols. e.g. Section 1 of RFC 7360 says: The DTLS protocol does not add reliable or in-order transport to RADIUS. DTLS also does not support fragmentation of application-layer messages, or of the DTLS messages themselves. It may be worth using similar text in this document. Also, Section 2.1 of RFC 7360 clarifies that the standad does not change anything existing in the legacy protocol, but adding a DTLS layer may affect PMTU: We note that the DTLS encapsulation of RADIUS means that RADIUS packets have an additional overhead due to DTLS. Implementations MUST support sending and receiving encapsulated RADIUS packets of 4096 octets in length, with a corresponding increase in the maximum size of the encapsulated DTLS packets. This larger packet size may cause the packet to be larger than the Path MTU (PMTU), where a RADIUS/UDP packet may be smaller. See Section 5.2, below, for more discussion. RFC 7360 also mandates support for particular TLS cipher suites, which is lacking from this document. I suggest adding text to address this issue. There may be other TLS / DTLS issues in the RADIUS documents which apply here. For this document: 4.3.2 ... However, once encryption of the transport connection is established, the server MUST NOT utilize TLS identity for the purpose of authorizing RPC requests. It may be worth reiterating that the protocols are independent. i.e. This document does not define the *combination* of TLS and RPC, so much as RPC carried over TLS. The underlying RPC protocol is largely unaware of the encapsulating TLS information. Section 5: ... In circumstances where the users on that NFS client belong to multiple distinct security domains, it may be necessary to establish separate TLS-protected connections that do not share the same encryption parameters. IMHO that's not a "may be necessary", but a hard requirement. And the last bit of that sentence should be clearer. The users will each have their own encryption credentials and profiles, I suspect. Section 5.1: Therefore, the RECOMMENDED deployment mode is that both servers and clients have certificate material available Perhaps "configured and used" is better than "available". An certificate which is "available" may, in fact, be unused. From nobody Mon Mar 18 13:44:02 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 D2406130DE3 for ; Mon, 18 Mar 2019 13:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.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 XF1D7HZx995S for ; Mon, 18 Mar 2019 13:43:58 -0700 (PDT) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 CF42F130DD3 for ; Mon, 18 Mar 2019 13:43:57 -0700 (PDT) Received: by mail-qt1-x844.google.com with SMTP id w30so14333379qta.8 for ; Mon, 18 Mar 2019 13:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=ZuTEAbvvmEL2qFskWskEGPDDPaGO8gxppJDC5dY0Cyg=; b=X0sksdQ1ppMjvc5cUMG9bM1xta0zUqLeN8uhFf6z8yiR+S2wM6MxXeMVnArWrSP1Yj IlDuuvjoGdchUsjvqqZFd6OSDq/a4loOWhhjZ/6OAtYeoEIcsORU3235vIFxIQaCsP1F fBuZpm+bPCuG5IeaiB7eK+n21X109WqKJsMrptDxNuLMb/raSCcHmr4LUe9wIbaZxgpB GYH5ltLvCHpdt9BZkhycBsbpgnIeORXzQSCGF7zwukGztafgsMIPaptpwH0+3/6Ftezb 9NKYEg9mu2sb7PfU07YCq0MaNYkI1goDKPzBaM4jt0dq3GXDGibwQgg0/OmpOC2wkxOY uVnQ== 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=ZuTEAbvvmEL2qFskWskEGPDDPaGO8gxppJDC5dY0Cyg=; b=K4CIvhqCrdF0QUyIUVA4tcH+hke7dDaGXw/rkr4pDN+pULzl2CkQH7qbmYGC5BUA5k N0Ne72nYjIAFC+qWxMa+dcw9fMbJFk9dVKkLMToUuR3Z7f9BZLq1pesN9WRMg7qY0lv0 Ia5d7pCzyR5M06V39CdI4aZVdf0INZN/7/GnuNgOkVxZyPMPJtBQsj+bt4HTEUcpM2Vv +IkH9UpGRqbfaHbUTsry2t7Y6RQGKw/RlezlKV9Xw9H+fQ9HIjDMc0Al6eMxFX0sy5f0 +XmdRNeHSyv6hxkhBFAO53z/9Y1fcbJHxCp+iYqdom0ppOZrOE4LN+0lrwIdWBvu6fLK wnEg== X-Gm-Message-State: APjAAAUjx6UtFZtAktlM5oESIQ1h1/Lrk60vDeT7DoYDdak2cWTMri08 elYuh9lXY54WDwdnGUQpiC0goA== X-Google-Smtp-Source: APXvYqy/yT6NY1aZ+Gv4uXU1MoZq3ILZFJkSE4Ig4j3omL5ZOjYNcaWBoo91+hxhf0M/IFy4GTnvyg== X-Received: by 2002:ac8:16c5:: with SMTP id y5mr15420061qtk.117.1552941836707; Mon, 18 Mar 2019 13:43:56 -0700 (PDT) Received: from ?IPv6:2601:152:4400:4013:9578:5f7f:3a98:d37c? ([2601:152:4400:4013:9578:5f7f:3a98:d37c]) by smtp.gmail.com with ESMTPSA id w127sm6481235qka.46.2019.03.18.13.43.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Mar 2019 13:43:55 -0700 (PDT) To: mcgrew Cc: Richard Barnes , secdir , CFRG , "RFC ISE (Adrian Farrel)" References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5D247CD2-710E-4C78-8495-085C70D4CFAB@cisco.com> From: Michael StJohns Message-ID: <9b192f26-8c19-494f-7430-7d1ca24872a3@nthpermutation.com> Date: Mon, 18 Mar 2019 16:43:53 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <5D247CD2-710E-4C78-8495-085C70D4CFAB@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 20:44:00 -0000 I don't understand - usually when I say "I'm fine with the status quo for now" people stop arguing with me.   Oh well. And thanks David for making some points for me.  See below. On 3/18/2019 9:26 AM, mcgrew wrote: > Hi Mike, > > Let me add few data points from a CFRG-historical perspective. CFRG has been the first publisher of a number of specifications (for instance, XMSS, Poly1305, and HBS are in this category - https://datatracker.ietf.org/rg/cfrg/documents/) and has done essential review for some ISE-published crypto like UMAC (RFC 4418). My point was that becoming a first publisher puts the CFRG into the position of being the standardizer.  XMSS, Poly1305 and HBS (not yet published) are all 2018 and 2019 documents.  EDDSA was 2017.  In fact the set of documents currently attributed to the CFRG only goes back to 2014 while the CFRG has been around a lot longer than that.  Something changed and now we're getting standards-like production out of the CFRG.  Note that I don't think its a bad thing per se, just that you need to be following different rules than those that are applicable to RGs. For example, why does an informational document in the research stream need a registry?  (e.g. RFC8391)   That's about as obvious a standardization requirement as any I've seen in CFRG documents. > For UMAC, it is worth noting that the ISE reviewers asked for changes around IPR language, I don't think I even recall seeing anything that wants to use UMAC - I may have missed a protocol or two though.  In any event, the request was to REMOVE claims about IPR language from the document and direct the authors to make a normal IPR disclosure. Again - pretty consistent with what we do with standards and IETF stream documents. > and CFRG reviewers made important improvements to the technical content as well (https://datatracker.ietf.org/doc/rfc4418/history/ and CFRG mail threads from fall 2005). So the issues we are dealing with today are not really new. But again, that's normal for any document that comes in through any stream - specifically - people review it and usually irrespective of association with a specific WG/RG/directorate, etc.  The fact that the document author, the ISE and the IESG reached out the the CFRG is pretty much an example of looking for the experts in a pile of experts.  I'm not sure why this wouldn't happen if the CFRG were chartered as a WG? > > You have started a good, healthy discussion with the points that you have raised. My thinking is that CFRG (including Kenny, Alexy, and the many contributors) is doing really good, really important work, and the IRTF and IETF should avoid changes that would disrupt it. I don't want to change the people, I don't even want to change the work flow (much - except that moving it to a WG would actually remove the IRTF from the approval process for an RFC), I just want this to be appropriately categorized and managed as a WG and subject to the same rules as any other WG.   I think its gone well past the normal rules for an RG at this point. Again - I've indicated my concerns and I'm happy the discussion is happening.  Unfortunately what I keep hearing is "we like it the way it is, now go and leave us alone" rather than "we're really a RG because we do things X, Y and Z so we really don't need to be a WG".  I'd really like to hear more commentary on that latter - especially how the CFRG in fact differs from the behavior of a WG. Thanks - Mike > > Best, > > David > >> On Mar 15, 2019, at 2:52 PM, Michael StJohns wrote: >> >> On 3/13/2019 7:32 AM, Richard Barnes wrote: >>> Mike, are your concerns here primarily IPR related? If that's so, then maybe that's the level at which we should address them, as opposed to flipping the bigger RG->WG switch. >>> >> Hi Richard - >> >> Like I said, I'm not going to push this at this time. But I think its more than just IPR - avoiding technology because of IPR is more a symptom (and in fact is IETF guidance rather than IRTF policy). >> >> The CFRG has a unique position in that - unlike ANY other RG as far as I can tell - it's looked at as an immediate feeder for technology for the IETF. If it were agnostically evaluating the crypto properties of any offered technology, I'd say we're good and I'd move on. But, with the publication of Curve25519 and its related ... standards ..., the CFRG has moved from evaluation and re-publication of cryptographic standards developed and produced elsewhere into being the first publisher of what could only be characterized as standards, even if published as an Informational RFC in the IRTF stream. >> >> Ultimately, I think it comes down to fairness and transparency. As an RG, the publications of the RG are not subject to the standards appeals process. In an WG, the decision not to work on an IPR encumbered technology (or others such as national cryptography) MAY be appealed and overturned (or might not) or sponsored by an AD if there's no applicable or agreeable WG. There's a process for showing such decisions were made transparently, and with a broader audience than just the CFRG having a say. >> >> >> Later, Mike >> >> Ps - hmm... Note that the CFRG charter only mentions the IETF and not the IRTF.... >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg From nobody Mon Mar 18 18:08:15 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 46F9B124B0C for ; Mon, 18 Mar 2019 18:08:13 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 rAQzK2DNNXZk for ; Mon, 18 Mar 2019 18:08:11 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 12F09130E69 for ; Mon, 18 Mar 2019 18:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1552957691; x=1584493691; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dK/SDxJJt26DPL1+4wuaT5rI7+erXjlpwK1HqA3TMwA=; b=BYw34+62LULrux7xLAkyqS1+wN0A28tDWu010ac9URRr/4m2pJe6gOzX xG+/xKCGQh+NLajThsOJuTM7Y6NVdIt8ERKDUi0yHip86THUPaA1s6MAe 4hKTzc69X+Yvhc/h71pGiUGq+JIYTBr3Gr1EolBqMET/tG86s3ysYy6cn NuGU7WJockosIgQFG22jfxSeURWm6n9IAyCxUFP/fTGfrhuX80ZTvWETo FrCpFpIspEPHgAWGdyEeVpTOkYSgwhOQkcYygho5g8euxCPle5G6+EGuW pOu6T/vR7vBC5SQFOIogZWb+liuOSMpRAWW3QA4z6lVURNBmkxP9XDXh0 Q==; X-IronPort-AV: E=Sophos;i="5.58,495,1544439600"; d="scan'208";a="52224439" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.4 - Outgoing - Outgoing Received: from uxcn13-ogg-c.uoa.auckland.ac.nz ([10.6.2.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Mar 2019 14:08:09 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-c.UoA.auckland.ac.nz (10.6.2.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 19 Mar 2019 14:08:08 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Tue, 19 Mar 2019 14:08:08 +1300 From: Peter Gutmann To: Paul Wouters , Watson Ladd CC: denis bider , secdir , "RFC ISE (Adrian Farrel)" , Martin Thomson Thread-Topic: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts Thread-Index: AQHU3aTDUNM95/0j6k6IffzkMJOWPaYQyH0AgAFcYn0= Date: Tue, 19 Mar 2019 01:08:07 +0000 Message-ID: <1552957626423.33373@cs.auckland.ac.nz> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> <679B6759-5AD3-4F28-9EF4-8794F383468B@mit.edu> <1552890164140.4569@cs.auckland.ac.nz> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 01:08:13 -0000 Paul Wouters writes:=0A= =0A= >The standard should not be =93bug compatible with the dominant implementat= ion=94=0A= =0A= Just an additional note to this, the standard currently literally is "bug= =0A= compatible with the dominant implementation". If you implement SSH as per = the=0A= core RFCs, sticking to all the MUSTs and whatnot, it won't talk to OpenSSH,= =0A= which means it de facto won't work.=0A= =0A= Also, expanding on Denis' comment about the PROTOOCOL doc:=0A= =0A= Note that OpenSSH's sftp and sftp-server implement revision 3 of the SSH= =0A= filexfer protocol described in:=0A= =0A= https://www.openssh.com/txt/draft-ietf-secsh-filexfer-02.txt=0A= =0A= Newer versions of the draft will not be supported, though some features= =0A= are individually implemented as extensions described below.=0A= =0A= I don't know if much, or even anything, supports any of draft-ietf-secsh-= =0A= filexfer-03.txt through to draft-ietf-secsh-filexfer-13.txt. So the standa= rd=0A= in this case is "use a 17-year-old expired draft, but not any newer version= of=0A= the same document".=0A= =0A= Peter.=0A= From nobody Tue Mar 19 06:23:29 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 75E85130F05 for ; Tue, 19 Mar 2019 06:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 NWfeW_VYKYkX for ; Tue, 19 Mar 2019 06:23:24 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D432A127978 for ; Tue, 19 Mar 2019 06:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6406; q=dns/txt; s=iport; t=1553001803; x=1554211403; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=fUpzD/o58rbIjGgrgHFMfaqdFmAibQ1/t6ZpSlpuW6g=; b=Kj/sqIMDWUBtuMsAiw5luQgP3ZIMXBKjl/mfOOrbiQz8DAyuPaE7Efn0 QLuJUi8JZv+kmOrPfx2LvrDierG3LfF6KrM1lIp8sgMriiozpLGAfOr57 m9dBz+wzbRwfc6N3rMCQ3HT/ikhp/Rf7L2bPKO/Ag1hMocjcze5D7bGAp k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAADf7JBc/4gNJK1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBgWYqaIEDJwqEY5JkgWglmi0LAQEYC4R?= =?us-ascii?q?JAoRrIjcGDQEBAwEBCQEDAm0cDIVKAQEBAQIBAQElEzEDCwULCwkPHgULJzA?= =?us-ascii?q?GDgWCV0sBgW0ID6pHM4REQYU0BYEvAYlsgUQXgT9AgREnDBOCHi6DHgEBAwG?= =?us-ascii?q?BPQEBHoM7giYDigozH5ktYAmDQIQdi08ZgXyFcohIgyiDTI07ihiCcAIRFYF?= =?us-ascii?q?dIoFWcBU7KgGCDQEzPoFYFxNtAQGHXYVbIwEBMYd3gR8BgR4BAQ?= X-IronPort-AV: E=Sophos;i="5.58,498,1544486400"; d="scan'208";a="537244422" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Mar 2019 13:23:17 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x2JDNGpj002584 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Mar 2019 13:23:16 GMT Received: from rtp-mcgrew-nitro3.cisco.com (10.117.145.148) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Mar 2019 08:23:15 -0500 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: mcgrew In-Reply-To: <9b192f26-8c19-494f-7430-7d1ca24872a3@nthpermutation.com> Date: Tue, 19 Mar 2019 09:23:03 -0400 CC: Richard Barnes , secdir , CFRG , "RFC ISE (Adrian Farrel)" Content-Transfer-Encoding: quoted-printable Message-ID: References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5D247CD2-710E-4C78-8495-085C70D4CFAB@cisco.com> <9b192f26-8c19-494f-7430-7d1ca24872a3@nthpermutation.com> To: Michael StJohns X-Mailer: Apple Mail (2.3445.102.3) X-Originating-IP: [10.117.145.148] X-ClientProxiedBy: xch-rtp-012.cisco.com (64.101.220.152) To XCH-ALN-004.cisco.com (173.36.7.14) X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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 Mar 2019 13:23:27 -0000 Hi Mike, Please see inline: > On Mar 18, 2019, at 4:43 PM, Michael StJohns = wrote: >=20 > I don't understand - usually when I say "I'm fine with the status quo = for now" people stop arguing with me. Oh well. >=20 > And thanks David for making some points for me. See below. >=20 >=20 > On 3/18/2019 9:26 AM, mcgrew wrote: >> Hi Mike, >>=20 >> Let me add few data points from a CFRG-historical perspective. CFRG = has been the first publisher of a number of specifications (for = instance, XMSS, Poly1305, and HBS are in this category - = https://datatracker.ietf.org/rg/cfrg/documents/) and has done essential = review for some ISE-published crypto like UMAC (RFC 4418). >=20 > My point was that becoming a first publisher puts the CFRG into the = position of being the standardizer. XMSS, Poly1305 and HBS (not yet = published) are all 2018 and 2019 documents. EDDSA was 2017. In fact = the set of documents currently attributed to the CFRG only goes back to = 2014 while the CFRG has been around a lot longer than that. Something = changed The RG shifted from discussing and reviewing independent documents = towards producing its own documents. =20 > and now we're getting standards-like production out of the CFRG. Note = that I don't think its a bad thing per se, just that you need to be = following different rules than those that are applicable to RGs. >=20 > For example, why does an informational document in the research stream = need a registry? (e.g. RFC8391) That's about as obvious a = standardization requirement as any I've seen in CFRG documents. The registry and the interface and extensibility it provides is = essential to making a crypto specification future-proof. That is clearly = best practice in cryptography, and as such is totally appropriate for = the output of an IRTF RG document. Some independent documents that = were reviewed by CFRG also had registries.=20 David >=20 >> For UMAC, it is worth noting that the ISE reviewers asked for = changes around IPR language, >=20 > I don't think I even recall seeing anything that wants to use UMAC - I = may have missed a protocol or two though. In any event, the request was = to REMOVE claims about IPR language from the document and direct the = authors to make a normal IPR disclosure. Again - pretty consistent with = what we do with standards and IETF stream documents. >=20 >> and CFRG reviewers made important improvements to the technical = content as well (https://datatracker.ietf.org/doc/rfc4418/history/ and = CFRG mail threads from fall 2005). So the issues we are dealing with = today are not really new. >=20 > But again, that's normal for any document that comes in through any = stream - specifically - people review it and usually irrespective of = association with a specific WG/RG/directorate, etc. The fact that the = document author, the ISE and the IESG reached out the the CFRG is pretty = much an example of looking for the experts in a pile of experts. I'm = not sure why this wouldn't happen if the CFRG were chartered as a WG? >=20 >=20 >>=20 >> You have started a good, healthy discussion with the points that you = have raised. My thinking is that CFRG (including Kenny, Alexy, and the = many contributors) is doing really good, really important work, and the = IRTF and IETF should avoid changes that would disrupt it. >=20 > I don't want to change the people, I don't even want to change the = work flow (much - except that moving it to a WG would actually remove = the IRTF from the approval process for an RFC), I just want this to be = appropriately categorized and managed as a WG and subject to the same = rules as any other WG. I think its gone well past the normal rules for = an RG at this point. >=20 > Again - I've indicated my concerns and I'm happy the discussion is = happening. Unfortunately what I keep hearing is "we like it the way it = is, now go and leave us alone" rather than "we're really a RG because we = do things X, Y and Z so we really don't need to be a WG". I'd really = like to hear more commentary on that latter - especially how the CFRG in = fact differs from the behavior of a WG. >=20 > Thanks - Mike >=20 >=20 >=20 >>=20 >> Best, >>=20 >> David >>=20 >>> On Mar 15, 2019, at 2:52 PM, Michael StJohns = wrote: >>>=20 >>> On 3/13/2019 7:32 AM, Richard Barnes wrote: >>>> Mike, are your concerns here primarily IPR related? If that's so, = then maybe that's the level at which we should address them, as opposed = to flipping the bigger RG->WG switch. >>>>=20 >>> Hi Richard - >>>=20 >>> Like I said, I'm not going to push this at this time. But I think = its more than just IPR - avoiding technology because of IPR is more a = symptom (and in fact is IETF guidance rather than IRTF policy). >>>=20 >>> The CFRG has a unique position in that - unlike ANY other RG as far = as I can tell - it's looked at as an immediate feeder for technology for = the IETF. If it were agnostically evaluating the crypto properties of = any offered technology, I'd say we're good and I'd move on. But, with = the publication of Curve25519 and its related ... standards ..., the = CFRG has moved from evaluation and re-publication of cryptographic = standards developed and produced elsewhere into being the first = publisher of what could only be characterized as standards, even if = published as an Informational RFC in the IRTF stream. >>>=20 >>> Ultimately, I think it comes down to fairness and transparency. As = an RG, the publications of the RG are not subject to the standards = appeals process. In an WG, the decision not to work on an IPR = encumbered technology (or others such as national cryptography) MAY be = appealed and overturned (or might not) or sponsored by an AD if there's = no applicable or agreeable WG. There's a process for showing such = decisions were made transparently, and with a broader audience than just = the CFRG having a say. >>>=20 >>>=20 >>> Later, Mike >>>=20 >>> Ps - hmm... Note that the CFRG charter only mentions the IETF and = not the IRTF.... >>>=20 >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> https://www.irtf.org/mailman/listinfo/cfrg >=20 >=20 From nobody Tue Mar 19 09:54: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 99DD7128CF2; Tue, 19 Mar 2019 09:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, 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=oracle.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 9kxmI4iNKJoe; Tue, 19 Mar 2019 09:54:38 -0700 (PDT) Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (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 428DC131106; Tue, 19 Mar 2019 09:54:35 -0700 (PDT) Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x2JGsAOG182979; Tue, 19 Mar 2019 16:54:31 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=Urfl3xyTjnDHl7hF3XinuFQqtgORL1tCkDbpf2sXabM=; b=Mkqo+x75l9R/YGwvEMo6udUzGy/s+WBkMg6Pr8GB4uN1hg7teu0Oj8FaLHZEpAsmmiwj D0SUthMByG9c2vCdiy3V7T00ZCaTUTMIRvL406umVWWXqskqdWE+guNwYiwky83CDXdf xQTSxdxQxghSGzvCx5hweJ648PF3f7+hwIaoxM1R9ahvpn5e3hEdJTxzGUBu4jW23kWr zHNwHZNgzQ8HYGqpqZ1gOTtGBnaDfSDqhKtGSEJw56k+gg81KfUfjcpfq35aRWezoJ91 nncsMPJgK9ar9BRVtHv1NaUOMxBaNmh4nhpTfFTk2v66wy0jlGuzQVHOZq+6C+ZoROvX ZQ== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2120.oracle.com with ESMTP id 2r8ssrdwy4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 19 Mar 2019 16:54:31 +0000 Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x2JGsPNd031259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 19 Mar 2019 16:54:25 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x2JGsOSC004586; Tue, 19 Mar 2019 16:54:24 GMT Received: from [100.66.188.10] (/198.214.85.110) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 19 Mar 2019 09:54:24 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Chuck Lever In-Reply-To: <155293906683.26184.494210804985115598@ietfa.amsl.com> Date: Tue, 19 Mar 2019 11:54:24 -0500 Cc: secdir@ietf.org, ietf@ietf.org, draft-cel-nfsv4-rpc-tls.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <60B01F34-8041-4A6A-8479-6F19F9BFCDBE@oracle.com> References: <155293906683.26184.494210804985115598@ietfa.amsl.com> To: Alan DeKok X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9200 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1810050000 definitions=main-1903190124 Archived-At: Subject: Re: [secdir] Secdir early review of draft-cel-nfsv4-rpc-tls-02 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 Mar 2019 16:54:41 -0000 > On Mar 18, 2019, at 2:57 PM, Alan DeKok via Datatracker = wrote: >=20 > Reviewer: Alan DeKok > Review result: Not Ready >=20 > I think that the document is fairly good, but could use additional > text. Alan, thank you for your comments. We will review the RADIUS documents and try to integrate these comments into the next revision of draft-cel-nfsv4-rpc-tls. One question below: > It would a good idea for the authors to review RFC 6614 (RADIUS over > TLS) and RFC 7360 (RADIUS over DTLS). Those documents both "patch" > RADIUS to allow for TLS / DTLS transport. The RADIUS bits are perhaps > uninteresting, but it is useful to learn from previous approaches to > patching legacy protocols. >=20 > e.g. Section 1 of RFC 7360 says: >=20 > The DTLS protocol does not add reliable > or in-order transport to RADIUS. DTLS also does not support > fragmentation of application-layer messages, or of the DTLS messages > themselves. >=20 > It may be worth using similar text in this document. Also, Section > 2.1 of RFC 7360 clarifies that the standad does not change anything > existing in the legacy protocol, but adding a DTLS layer may affect = PMTU: >=20 > We note that the DTLS encapsulation of RADIUS means that RADIUS > packets have an additional overhead due to DTLS. Implementations > MUST support sending and receiving encapsulated RADIUS packets of > 4096 octets in length, with a corresponding increase in the maximum > size of the encapsulated DTLS packets. This larger packet size may > cause the packet to be larger than the Path MTU (PMTU), where a > RADIUS/UDP packet may be smaller. See Section 5.2, below, for more > discussion. >=20 > RFC 7360 also mandates support for particular TLS cipher suites, which = is > lacking from this document. I suggest adding text to address this = issue. >=20 > There may be other TLS / DTLS issues in the RADIUS documents which = apply here. >=20 > For this document: >=20 > 4.3.2 >=20 > ... However, once encryption of the > transport connection is established, the server MUST NOT utilize TLS > identity for the purpose of authorizing RPC requests. >=20 > It may be worth reiterating that the protocols are independent. > i.e. This document does not define the *combination* of TLS and RPC, > so much as RPC carried over TLS. The underlying RPC protocol is > largely unaware of the encapsulating TLS information. It is true that the RPC protocol is unchanged (except for the addition of AUTH_TLS). However, I'm not clear what triggered your comment. Can you expand a bit? > Section 5: >=20 > ... In circumstances where > the users on that NFS client belong to multiple distinct security > domains, it may be necessary to establish separate TLS-protected > connections that do not share the same encryption parameters. >=20 > IMHO that's not a "may be necessary", but a hard requirement. And the > last bit of that sentence should be clearer. The users will each have > their own encryption credentials and profiles, I suspect. >=20 > Section 5.1: >=20 > Therefore, the RECOMMENDED deployment mode is that both servers and > clients have certificate material available=20 >=20 > Perhaps "configured and used" is better than "available". An > certificate which is "available" may, in fact, be unused. >=20 >=20 -- Chuck Lever From nobody Tue Mar 19 14:33:06 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 9C55A12B001; Tue, 19 Mar 2019 14:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FFFr02OhPPXD; Tue, 19 Mar 2019 14:32:56 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id C504E1289FA; Tue, 19 Mar 2019 14:32:56 -0700 (PDT) Received: from [192.168.46.58] (198-84-237-221.cpe.teksavvy.com [198.84.237.221]) by mail.networkradius.com (Postfix) with ESMTPSA id BF0FB30; Tue, 19 Mar 2019 21:32:54 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Alan DeKok In-Reply-To: <60B01F34-8041-4A6A-8479-6F19F9BFCDBE@oracle.com> Date: Tue, 19 Mar 2019 17:32:53 -0400 Cc: secdir@ietf.org, ietf@ietf.org, draft-cel-nfsv4-rpc-tls.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <011CB47A-63D5-42FA-97A7-84A2EBEDB75C@deployingradius.com> References: <155293906683.26184.494210804985115598@ietfa.amsl.com> <60B01F34-8041-4A6A-8479-6F19F9BFCDBE@oracle.com> To: Chuck Lever X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] Secdir early review of draft-cel-nfsv4-rpc-tls-02 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 Mar 2019 21:32:58 -0000 > On Mar 19, 2019, at 12:54 PM, Chuck Lever = wrote: >>=20 >> It may be worth reiterating that the protocols are independent. >> i.e. This document does not define the *combination* of TLS and RPC, >> so much as RPC carried over TLS. The underlying RPC protocol is >> largely unaware of the encapsulating TLS information. >=20 > It is true that the RPC protocol is unchanged (except for the > addition of AUTH_TLS). However, I'm not clear what triggered > your comment. Can you expand a bit? I'm a proponent of making explicit statements. Otherwise the reader = may be left with questions as to what, exactly "TLS + RPC" means. Having an explicit statement is clearer IMHO than assuming that the = reader knows this implicitly. Alan DeKok. From nobody Tue Mar 19 14:39:17 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 BCFA71311B4; Tue, 19 Mar 2019 14:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 nuEMGqh1X-et; Tue, 19 Mar 2019 14:39:05 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 329C21311AC; Tue, 19 Mar 2019 14:39:05 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id v4so100228ioj.5; Tue, 19 Mar 2019 14:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=MydL6D3yzTpa1+aIR1EzPW+E9u6Ah1H//1qFHiqkR0I=; b=I4jkZBODwDiBpkL4gEN14tW3bTvMdUfYL2vE2zfmjRhaHdHt6IJTH7mFjF65+PgD8w jLsk+g5np2Nn1R4rRBu/6kP3FghMf/Jv15VWVbZzqu+ZIqbUfwfVXTTYyZrJYJgqn8pi Kzo03hGmTPuWO67UTILpwNpYJAx2vPzyKBwy2HD0ANkrl6YOz164K85xj27Lgm4AoFW8 /BSmBxnI45Ge9iGUEFwDUxQJ0B7oBIOr8IhdJ/EjPtHpiMVVHB0zZKGlk44piDgXvXbn phmvZVdXDAFJ51EwrOp14g2HEVz5A7zLhOncVMKe2ST+uOxVou8g4TZ//3pJ1SOGnxJv ktVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=MydL6D3yzTpa1+aIR1EzPW+E9u6Ah1H//1qFHiqkR0I=; b=i6QeqWXF4tYD1fPhASQ8Leh5zxkcXvz6UsxXf0OgA2izF+NUeKx8qYrS+OrdsWENyy VwP63cffnCLK9VbkUelaBuZB4Toq+5AT5UB4Lym9JyI1IgDXxdtF5/K+ETF8v4S7D3+Q iprBrm5rc1Hx9e2AduWnKeVLQwKJOPpRoVabTOo6D1AXYsuW8sPHRbFx5imJKLceZ6qZ nKEfU8s/+ChrqrKRe9Bpn0ef3OXChx4dDW8S0YOiBFpF4vO//YoiyR6s6juPGsOm28mJ laDr/sDxiCRIJI1kqGEuqHlG4g0eIgwiloyszO/qvE3z4BBfG09O6H+RQCfc75oqeMMI kbCA== X-Gm-Message-State: APjAAAV7mj5LxyWRfUPXI6flkfdI1eTVD5VjhiQKAN6N8z0EIpUVb/Zt 63ZjptkDtiOUDqYMd++6a+bqqvfa8Tic2n6JNHQwr7e6 X-Google-Smtp-Source: APXvYqzMcNbaUNcxVl5BLerpdc0qHhGIYp+oQSPADl7l8OCs6HHDH1QlxK0ILx6DVFd6N4e5pKgaIuSLp9LzzzWWa5c= X-Received: by 2002:a5e:8f04:: with SMTP id c4mr2991476iok.131.1553031544225; Tue, 19 Mar 2019 14:39:04 -0700 (PDT) MIME-Version: 1.0 From: Donald Eastlake Date: Tue, 19 Mar 2019 17:38:52 -0400 Message-ID: To: "iesg@ietf.org" , draft-ietf-pce-stateful-pce-p2mp.all@ietf.org Cc: secdir Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-pce-stateful-pce-p2mp-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: Tue, 19 Mar 2019 21:39:07 -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. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready. Although the Security Considerations section is fairly short, it has references to a number of relevant earlier RFCs that have quite extensive Security Considerations sections. Furthermore PCEP was previous extended to cover P2MP Traffic Engineered Label Switched Paths and separately extended to be stateful. This draft's addition of support for stateful P2MP TE LSPs is not that big of a change in Security Considerations from those in the earlier RFCs. Editorial Section 3.2, Page 5, "are same as" -> "are the same as" Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com From nobody Tue Mar 19 22:02:12 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 D9AAA130F62; Tue, 19 Mar 2019 22:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 KoZZkKdVdeSz; Tue, 19 Mar 2019 22:02:02 -0700 (PDT) Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 7ABBA130F34; Tue, 19 Mar 2019 22:02:02 -0700 (PDT) Received: by mail-it1-x12f.google.com with SMTP id z126so26871605itd.5; Tue, 19 Mar 2019 22:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lgj6IUrNgfq7IfzUjQlCuE8IfBp1syH0hDH0Mjo5lCQ=; b=A5B0thVWSm15ZnEDnBb+paLMNP0ciCLeuEqY5dTxE54S/gzCxDhFtSYHbfs6s0+mlo Zc9lIxylw/bIO2dWliN1Fxy3kB5nnWH8RVuDbaBEe0j6gJZdgL+o7YTKju7SB6o//OYV fsZE3WueyHUHL/0bRRfygxRasZBfMHSvmWfK/DDqskI/5VTyh9RSKhXoGqrQWkUYqay2 ex2Por0RQgoR+x+7t7Tum4r3XGxZI4jwbSem/CS001fF0SA+HtGn9A8We7hmSakIkdg1 XFPFPyeK2+YaW5ot0N1gTz/KmZDkpdL2Xn8WC8vig2eHWMryBcgEd1PGpkWU7+9KpQOM Vx0A== 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=Lgj6IUrNgfq7IfzUjQlCuE8IfBp1syH0hDH0Mjo5lCQ=; b=IRkjc2LnALcB1OH/FhaP0D7r5zFLVdQOk8V/lVD9QbwFtRcFgs4n033pE/8EcXScwH 75p7AIHXg82y8SwobjvbrDadM1+nDxrs2iYRNPKWcr5QMrEPv0BUe+ylH9mdAvkSvDbi 0dA8TSdagU8Lx/m1dCRctV65QUM4XyZ+aC1Shhs4iRPi+zHt2V+PjYRbDyMRJUpWN4M+ kWEVJwaXaVbsoKLqFPehh6J0KweXntqc6R1LfIBe/zVctngMaFeDbQAdxDxaS15AQjQj dD8MlxFd8nsrIvbobUj+i36PmWYBSq9n1jPSb0jXkcD20/InK1iwPbp35H9g37ifx9BE JMsg== X-Gm-Message-State: APjAAAX1K8Oi/y6iklO9UkGUMaDhgH6ZUHvsMv0x2SuNq8LYbaJqSLdD Pt6Knx4mSQohEBUFruSe2JKTrKdXVBnUCFpUJNA= X-Google-Smtp-Source: APXvYqwOnhHp8gEmxj4w481XudUSqV/Z+P9cVe3Wcg6OE8SeOWDTiEnkoiP/S/hpjCNn23fCrW3x45qVWunPfQ+dIiU= X-Received: by 2002:a24:978c:: with SMTP id k134mr3640963ite.67.1553058121663; Tue, 19 Mar 2019 22:02:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dhruv Dhody Date: Wed, 20 Mar 2019 10:31:25 +0530 Message-ID: To: Donald Eastlake Cc: "iesg@ietf.org" , draft-ietf-pce-stateful-pce-p2mp.all@ietf.org, secdir , pce@ietf.org Content-Type: multipart/alternative; boundary="000000000000a84d6505847f8563" Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-pce-stateful-pce-p2mp-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: Wed, 20 Mar 2019 05:02:04 -0000 --000000000000a84d6505847f8563 Content-Type: text/plain; charset="UTF-8" Hi Donald, Thanks for your review, updated in the working copy. Thanks! Dhruv On Wed, Mar 20, 2019 at 3:09 AM Donald Eastlake wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. Document editors and WG chairs should treat these comments just > like any other last call comments. > > The summary of the review is Ready. > > Although the Security Considerations section is fairly short, it has > references to a number of relevant earlier RFCs that have quite > extensive Security Considerations sections. Furthermore PCEP was > previous extended to cover P2MP Traffic Engineered Label Switched > Paths and separately extended to be stateful. This draft's addition of > support for stateful P2MP TE LSPs is not that big of a change in > Security Considerations from those in the earlier RFCs. > > Editorial > > Section 3.2, Page 5, "are same as" -> "are the same as" > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 1424 Pro Shop Court, Davenport, FL 33896 USA > d3e3e3@gmail.com > --000000000000a84d6505847f8563 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Donald,=C2=A0

Thanks for your review, updated in the= working copy.=C2=A0

Thanks!=C2=A0
Dhruv


On Wed, Mar 20,= 2019 at 3:09 AM Donald Eastlake <d3= e3e3@gmail.com> wrote:
I have reviewed this document as part of the security directo= rate's
ongoing effort to review all IETF documents being processed by the
IESG. Document editors and WG chairs should treat these comments just
like any other last call comments.

The summary of the review is Ready.

Although the Security Considerations section is fairly short, it has
references to a number of relevant earlier RFCs that have quite
extensive Security Considerations sections. Furthermore PCEP was
previous extended to cover P2MP Traffic Engineered Label Switched
Paths and separately extended to be stateful. This draft's addition of<= br> support for stateful P2MP TE LSPs is not that big of a change in
Security Considerations from those in the earlier RFCs.

Editorial

Section 3.2, Page 5, "are same as" -> "are the same as&qu= ot;

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
=C2=A01424 Pro Shop Court, Davenport, FL 33896 USA
=C2=A0d3e3e3@gmail.co= m
--000000000000a84d6505847f8563-- From nobody Wed Mar 20 07:16:45 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 498C812799B for ; Wed, 20 Mar 2019 07:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] 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 LL7Ocxww1pxu for ; Wed, 20 Mar 2019 07:16:40 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 1F62B12787F for ; Wed, 20 Mar 2019 07:16:39 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x2KEFrSX011847 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 20 Mar 2019 16:15:53 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x2KEFp3X014618; Wed, 20 Mar 2019 16:15:51 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <23698.19223.566447.639174@fireball.acr.fi> Date: Wed, 20 Mar 2019 16:15:51 +0200 From: Tero Kivinen To: Peter Gutmann Cc: Paul Wouters , Watson Ladd , Martin Thomson , denis bider , secdir In-Reply-To: <1552957626423.33373@cs.auckland.ac.nz> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> <679B6759-5AD3-4F28-9EF4-8794F383468B@mit.edu> <1552890164140.4569@cs.auckland.ac.nz> <1552957626423.33373@cs.auckland.ac.nz> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 11 min Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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, 20 Mar 2019 14:16:43 -0000 Peter Gutmann writes: > Paul Wouters writes: >=20 > >The standard should not be =E2=80=9Cbug compatible with the dominant= > >implementation=E2=80=9D=20 >=20 > Just an additional note to this, the standard currently literally is = "bug > compatible with the dominant implementation". If you implement SSH a= s per the > core RFCs, sticking to all the MUSTs and whatnot, it won't talk to Op= enSSH, > which means it de facto won't work. >=20 > Also, expanding on Denis' comment about the PROTOOCOL doc: >=20 > Note that OpenSSH's sftp and sftp-server implement revision 3 of th= e SSH > filexfer protocol described in: >=20 > https://www.openssh.com/txt/draft-ietf-secsh-filexfer-02.txt >=20 > Newer versions of the draft will not be supported, though some feat= ures > are individually implemented as extensions described below. >=20 > I don't know if much, or even anything, supports any of draft-ietf-se= csh- > filexfer-03.txt through to draft-ietf-secsh-filexfer-13.txt. So the = standard > in this case is "use a 17-year-old expired draft, but not any newer v= ersion of > the same document". Secsh WG was active between 1997-2006. The filexfer-02 was published in 2001 and final filexfer-13 was published in 2006, i.e., the -13 version is what the working group was working on. My understanding was that the issue was that openssh did not want to implement what was specified in the working group because of the issues with trademarks, personalities and things not at all relevant to the actual protocol development or IETF work. Those things practically killed the group and there was not that much work ongoing after that. This does not mean that IETF working groups do not work, it just mean that one group did fail. In the IPsec we had similar situation where we did finish the base specifications closed up the working at 2005. Created a new working group IPsecME (IP Security Maintenance and Extensions) in 2008 to create place for working extensions and fixes for IPsec protocol suite. We have rechartered several times since, every time checking out our current set of extensions proposed for us and taken those which had enough interest. So I do not think that forming working group raises the bar too high, or makes things too difficult, the issues with secsh was (and I think is) not related to IETF processes. Jan 9 2001 draft-ietf-secsh-filexfer-00.txt Mar 5 2001 draft-ietf-secsh-filexfer-01.txt Nov 21 2001 draft-ietf-secsh-filexfer-02.txt Oct 17 2002 draft-ietf-secsh-filexfer-03.txt Dec 20 2002 draft-ietf-secsh-filexfer-04.txt Feb 12 2004 draft-ietf-secsh-filexfer-05.txt Oct 27 2004 draft-ietf-secsh-filexfer-06.txt Mar 25 2005 draft-ietf-secsh-filexfer-07.txt Apr 6 2005 draft-ietf-secsh-filexfer-08.txt Jun 13 2005 draft-ietf-secsh-filexfer-09.txt Oct 6 2005 draft-ietf-secsh-filexfer-10.txt Jan 18 2006 draft-ietf-secsh-filexfer-11.txt Jan 26 2006 draft-ietf-secsh-filexfer-12.txt Jul 18 2006 draft-ietf-secsh-filexfer-13.txt --=20 kivinen@iki.fi From nobody Wed Mar 20 07:39:56 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 EFFB91279A8 for ; Wed, 20 Mar 2019 07:39:54 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 3hf9eAnFKjkw for ; Wed, 20 Mar 2019 07:39:52 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 F02B2127988 for ; Wed, 20 Mar 2019 07:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1553092792; x=1584628792; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=r/Me8D5nPkFjsG6pKPove5Y6QFvdciqvRCn9h/1YyUw=; b=FlpqM0IRN1S7Hb0BHiFxn6WOwdt5obGmwTz+UYAZtSAGVHXYnF2p130u vD+DF9pswYtlU3eUEGefyrj023pBPfeN3MwNODTQVe0+55Jr1zVbrSwer tUXMCgGm0omr01G/y0hYQOFvgAC8buq5KNeEX0JBeWU8XEzW8hcwfOhFi lD2AXA231zJh2AKOm4nUnpZjqURE6AufTnkqqVl3rZiWh9LsnMPAAlLD6 rtdWeMJk12ORUXbZMKOOFtnmnVXwGxXmh6siB+4bNOsNPglPU4sXmkaIu TrZONkT51Ax1/dxkMQMNxmBNYR38QJrPjusv+8JKdCTfUKJG5BUBS3KyH w==; X-IronPort-AV: E=Sophos;i="5.60,249,1549882800"; d="scan'208";a="52434794" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-ogg-b.UoA.auckland.ac.nz) ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 21 Mar 2019 03:39:48 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.3) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 21 Mar 2019 03:39:48 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Thu, 21 Mar 2019 03:39:48 +1300 From: Peter Gutmann To: Tero Kivinen CC: Paul Wouters , Watson Ladd , "Martin Thomson" , denis bider , secdir Thread-Topic: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts Thread-Index: AQHU3aTDUNM95/0j6k6IffzkMJOWPaYQyH0AgAFcYn2AAZTBgIAA4CSJ Date: Wed, 20 Mar 2019 14:39:47 +0000 Message-ID: <1553092722905.88359@cs.auckland.ac.nz> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> <679B6759-5AD3-4F28-9EF4-8794F383468B@mit.edu> <1552890164140.4569@cs.auckland.ac.nz> <1552957626423.33373@cs.auckland.ac.nz>, <23698.19223.566447.639174@fireball.acr.fi> In-Reply-To: <23698.19223.566447.639174@fireball.acr.fi> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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, 20 Mar 2019 14:39:55 -0000 Tero Kivinen writes:=0A= =0A= >Secsh WG was active between 1997-2006. The filexfer-02 was published in 20= 01=0A= >and final filexfer-13 was published in 2006, i.e., the -13 version is what= =0A= >the working group was working on. My understanding was that the issue was= =0A= >that openssh did not want to implement what was specified in the working= =0A= >group because of the issues with trademarks, personalities and things not = at=0A= >all relevant to the actual protocol development or IETF work.=0A= =0A= I think it was more than just that, if you look at what you'd need to do fo= r=0A= an -02 client, so "General Packet Format" to the end of "Requests From the= =0A= Client to the Server" that's fifteen pages. In -13 the same thing is forty= -=0A= two pages (!!), and also draws in chunks of NFSv4 by reference. It's gone= =0A= from being a means of getting a file from A to B to trying to reinvent NFS,= =0A= with all the attendant complexity.=0A= =0A= I can see why an implementer would want to stop at -02, which is exactly wh= at=0A= I did when I had to do an SFTP implementation, -13 had reached the point wh= ere=0A= it was growing without bounds with little to no benefit from the massive=0A= complexity being added to it.=0A= =0A= Peter.=0A= From nobody Wed Mar 20 08:21: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 04F6C129AB8; Wed, 20 Mar 2019 08:21:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Stephen Kent via Datatracker To: Cc: draft-ietf-manet-dlep-pause-extension.all@ietf.org, manet@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Stephen Kent Message-ID: <155309526492.14741.18141095676597911076@ietfa.amsl.com> Date: Wed, 20 Mar 2019 08:21:05 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-manet-dlep-pause-extension-05 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: Wed, 20 Mar 2019 15:21:05 -0000 Reviewer: Stephen Kent Review result: Has 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 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. Review Summary: Ready with nits This brief document defines and extension to DLEP That enables a modem to use DLEP to pause and resume inbound traffic from a specific peer. DLEP (RFC 8175) cites GTSM as a security mechanism, which is rather weak, but it says that implementations SHOULD use TLS (1.2), which is fine. The text states that “An example of when a modem might send this data item is when an internal queue length exceeds a particular threshold.” However, all of details of this data item seem to focus exclusively on queues. Thus it seems likely that this is not just an example, but, rather, the primary motivation for introducing the pause extension. A slight rewording of the text here seems appropriate, or the authors could describe other (not-queue-based) examples. The Security Considerations section of 8175 addresses a reasonable range of concerns. Thus it is appropriate that this document’s Security Considerations section is very brief, as it cites the corresponding section in 8175. I suggest a couple of minor change to the wording here: “The extension does not inherently introduce any additional threats … -> “The extension does not inherently introduce any additional vulnerabilities …” “ … but this is not a substantively different threat by …” -> “ … but this is not a substantively different attack by …” There are numerous examples of awkward/poor phrasing throughout the document, which I hope the RFC Editor will correct, e.g., Abstract: “…to the DLEP protocol …” -> “… to DLEP …” page 7: “A modem can indicate that traffic is to be suppressed on a device wide or destination specific basis.” “A modem can indicate that traffic is to be suppressed on a device- wide or destination-specific basis.” “This includes that to indicate that transmission can resume to all destinations …” “Thus, to indicate that transmission can resume to all destinations, …” From nobody Wed Mar 20 09:06: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 36E191310D6 for ; Wed, 20 Mar 2019 09:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 PNEZ2XYkK_JF for ; Wed, 20 Mar 2019 09:06:15 -0700 (PDT) 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 46F5C1310F7 for ; Wed, 20 Mar 2019 09:06:14 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2KG6AhK028659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 20 Mar 2019 12:06:13 -0400 Date: Wed, 20 Mar 2019 11:06:10 -0500 From: Benjamin Kaduk To: secdir@ietf.org Message-ID: <20190320160610.GH80498@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [secdir] No secdir lunch in Prague 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, 20 Mar 2019 16:06:18 -0000 Hi folks, Due to the Wednesday scheudle experiment, the WG Chairs' Forum got scheduled on Tuesday, opposite our usual secdir lunch timeslot. Since the topics on the WG Chairs' agenda [1] seem more important than what we've got lined up for secdir, it seems best to just cancel the secdir lunch and let everyone go to the WG Chairs' forum this time. Hopefully Tero can send out a link to the statistics page so we can all see how we're doing. And of course, always feel free to bring up topics of interest here or with the ADs directly. -Ben [1] https://datatracker.ietf.org/meeting/104/materials/agenda-104-edu-sessc From nobody Fri Mar 22 01:29:10 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 BE635130EB5 for ; Fri, 22 Mar 2019 01:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 szHgPlo8dmJj for ; Fri, 22 Mar 2019 01:29:06 -0700 (PDT) Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [194.9.95.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF234130EA1 for ; Fri, 22 Mar 2019 01:29:05 -0700 (PDT) Received: from s554.loopia.se (localhost [127.0.0.1]) by s554.loopia.se (Postfix) with ESMTP id 6BFC01F17C1E for ; Fri, 22 Mar 2019 09:29:00 +0100 (CET) Received: from s645.loopia.se (unknown [172.21.200.108]) by s554.loopia.se (Postfix) with ESMTP id 4DF5379474F for ; Fri, 22 Mar 2019 09:29:00 +0100 (CET) Received: from s473.loopia.se (unknown [172.21.200.35]) by s645.loopia.se (Postfix) with ESMTP id 3F30F13BF33B for ; Fri, 22 Mar 2019 09:29:00 +0100 (CET) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s498.loopia.se ([172.22.191.5]) by s473.loopia.se (s473.loopia.se [172.22.190.13]) (amavisd-new, port 10024) with UTF8LMTP id s1zFGhT7CyVW for ; Fri, 22 Mar 2019 09:28:59 +0100 (CET) X-Loopia-Auth: user X-Loopia-User: mailstore2@aaa-sec.com X-Loopia-Originating-IP: 85.235.7.89 Received: from [192.168.1.9] (gw.aaa-sec.ideon.se [85.235.7.89]) (Authenticated sender: mailstore2@aaa-sec.com) by s498.loopia.se (Postfix) with ESMTPSA id A42B3449422 for ; Fri, 22 Mar 2019 09:28:59 +0100 (CET) User-Agent: Microsoft-MacOutlook/10.17.0.190309 Date: Fri, 22 Mar 2019 09:28:58 +0100 From: Stefan Santesson To: Message-ID: Thread-Topic: Issue with XML Encryption standards from W3C and the use of ECDH Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [secdir] Issue with XML Encryption standards from W3C and the use of ECDH 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, 22 Mar 2019 08:29:09 -0000 Hi, I'm looking for anyone with an insight in this issue, anyone experiencing interop issues or anyone willing to seek a solution. The XML Encryption standard has some errors and lack of specification with regard to the use of the Key Derivation Function ConcatKDF The example on ECDH use at: https://www.w3.org/TR/xmlenc-core1/#sec-ECDH-ES express the ConcatKDF parameters as AlgorithmID="00" PartyUInfo="" PartyVInfo="" This is inconsistent with the same specification definition of how to use ConcatKDF and how to specify its parameters: https://www.w3.org/TR/xmlenc-core1/#sec-ConcatKDF Further. ConcatKDF parameters stors bit strings of arbitrary length in chunks of byte data. The bitstring length may not be devisable by 8. Implementers are supposed to strip padding bytes and send the actual bit strings as ConcatKDF input. Current implementations of ConcatKDF, in particular from Bouncycastle can only handle ConcatKDF input in the form of byte array. Implementations I have seen have fed ConcatKDF parameters from XML enc directly into ConcatKDF without attempting to strip padding bits and length byte from the data. All implementations must have this right or nothing will work. There are some serious issues threaten interoperability here: - Implementers may be tricked to send illegal parameter values following the example in 5.6.4 - Implementers are supposed to strip out padding bits, but if they do, they may end up with data they can't use because the result can't be stored in bytes. Apparently there is a need for further clarifications here, but the XML Security group of W3C is closed and I have found no way to send them feedback. Is there anyone here who have insights in this issue or know how to solve it? Stefan Santesson From nobody Fri Mar 22 01:43:56 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 219C3130E8F for ; Fri, 22 Mar 2019 01:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Cm80nxpX7_2u for ; Fri, 22 Mar 2019 01:43:53 -0700 (PDT) Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [194.9.95.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE803127287 for ; Fri, 22 Mar 2019 01:43:52 -0700 (PDT) Received: from s554.loopia.se (localhost [127.0.0.1]) by s554.loopia.se (Postfix) with ESMTP id 71BBA1F19808 for ; Fri, 22 Mar 2019 09:43:40 +0100 (CET) Received: from s499.loopia.se (unknown [172.21.200.97]) by s554.loopia.se (Postfix) with ESMTP id 39D9B794786 for ; Fri, 22 Mar 2019 09:43:40 +0100 (CET) Received: from s549.loopia.se (unknown [172.21.200.35]) by s499.loopia.se (Postfix) with ESMTP id 34C331349BB0 for ; Fri, 22 Mar 2019 09:43:40 +0100 (CET) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s499.loopia.se ([172.22.191.6]) by s549.loopia.se (s549.loopia.se [172.22.190.9]) (amavisd-new, port 10024) with LMTP id 2mU6TMJWsvC4 for ; Fri, 22 Mar 2019 09:43:39 +0100 (CET) X-Loopia-Auth: user X-Loopia-User: mailstore2@aaa-sec.com X-Loopia-Originating-IP: 85.235.7.89 Received: from [192.168.1.9] (gw.aaa-sec.ideon.se [85.235.7.89]) (Authenticated sender: mailstore2@aaa-sec.com) by s499.loopia.se (Postfix) with ESMTPSA id 8A0381349B8F for ; Fri, 22 Mar 2019 09:43:39 +0100 (CET) User-Agent: Microsoft-MacOutlook/10.17.0.190309 Date: Fri, 22 Mar 2019 09:43:38 +0100 From: Stefan Santesson To: Message-ID: Thread-Topic: [secdir] Issue with XML Encryption standards from W3C and the use of ECDH Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [secdir] Issue with XML Encryption standards from W3C and the use of ECDH 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, 22 Mar 2019 08:43:55 -0000 Just for reference. ConcatKDF is defined in NIST SP 800-56A. Here is Bouncycastle implementatio= n of ConcatKDF: https://github.com/bcgit/bc-java/blob/master/core/src/main/j= ava/org/bouncycastle/crypto/agreement/kdf/ConcatenationKDFGenerator.java OtherInfo is the concatenation of all ConcatKDF parameters =3D=3D> AlgorithmID = || PartyUInfo || PartyVInfo {|| SuppPubInfo }{|| SuppPrivInfo } As you can see, OtherInfo is a byteArray and all bits of its content is use= d in the ConcatKDF key generation process. IMO XML Enc should limit the use of ConcatKDF to use only full bytes of dat= a without padding as parameters. The addition of a padding counter byte is a= mistake that will cause interop issues, but that is too late to change now. Stefan Santesson=20 =EF=BB=BFOn 2019-03-22, 09:29, "secdir on behalf of Stefan Santesson" wrote: Hi, =20 I'm looking for anyone with an insight in this issue, anyone experienci= ng interop issues or anyone willing to seek a solution. =20 =20 The XML Encryption standard has some errors and lack of specification w= ith regard to the use of the Key Derivation Function ConcatKDF =20 The example on ECDH use at: https://www.w3.org/TR/xmlenc-core1/#sec-ECD= H-ES express the ConcatKDF parameters as AlgorithmID=3D"00" PartyUInfo=3D"" Part= yVInfo=3D"" This is inconsistent with the same specification definition of how to u= se ConcatKDF and how to specify its parameters: https://www.w3.org/TR/xmlenc= -core1/#sec-ConcatKDF =20 Further. ConcatKDF parameters stors bit strings of arbitrary length in = chunks of byte data. The bitstring length may not be devisable by 8. Impleme= nters are supposed to strip padding bytes and send the actual bit strings as= ConcatKDF input. Current implementations of ConcatKDF, in particular from Bouncycastle c= an only handle ConcatKDF input in the form of byte array. =20 Implementations I have seen have fed ConcatKDF parameters from XML enc = directly into ConcatKDF without attempting to strip padding bits and length = byte from the data. All implementations must have this right or nothing will= work. =20 There are some serious issues threaten interoperability here: =20 - Implementers may be tricked to send illegal parameter values followi= ng the example in 5.6.4 - Implementers are supposed to strip out padding bits, but if they do,= they may end up with data they can't use because the result can't be stored= in bytes. =20 Apparently there is a need for further clarifications here, but the XML= Security group of W3C is closed and I have found no way to send them feedba= ck. =20 =20 Is there anyone here who have insights in this issue or know how to sol= ve it? =20 =20 Stefan Santesson=20 =20 =20 =20 =20 =20 _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview =20 From nobody Fri Mar 22 02:17:18 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 3C614130EC1; Fri, 22 Mar 2019 02:17:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stefan Santesson via Datatracker To: Cc: draft-wilde-service-link-rel.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Stefan Santesson Message-ID: <155324623015.23003.17581075186850679270@ietfa.amsl.com> Date: Fri, 22 Mar 2019 02:17:10 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-wilde-service-link-rel-10 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, 22 Mar 2019 09:17:11 -0000 Reviewer: Stefan Santesson Review result: Has Nits This document seems to be ready and well written. The security considerations section seems reasonable. However, I do agree with previous review that the requirements language boilerplate may be redundant. There are only 2 capital SHOULD requirements in the document and they both appear in the security considerations section. None of them are referring to things that can be tested for compliance and they could both be downgraded to "should". From nobody Fri Mar 22 02:22:10 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 1BF4C130EC2; Fri, 22 Mar 2019 02:22:02 -0700 (PDT) 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, 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 7JBPu4DtpD6J; Fri, 22 Mar 2019 02:21:59 -0700 (PDT) Received: from postoffice.gristmillmedia.com (dret.net [209.188.86.86]) (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 A67C6130EC1; Fri, 22 Mar 2019 02:21:56 -0700 (PDT) Received: from 73.10.0.85.dynamic.wline.res.cust.swisscom.ch ([85.0.10.73]:56355 helo=dretpro.home) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h7GN7-00086O-KA; Fri, 22 Mar 2019 05:21:54 -0400 To: Stefan Santesson , secdir@ietf.org Cc: draft-wilde-service-link-rel.all@ietf.org, ietf@ietf.org References: <155324623015.23003.17581075186850679270@ietfa.amsl.com> From: Erik Wilde Message-ID: <76e93d92-a580-11a5-62a5-6467fadae52f@dret.net> Date: Fri, 22 Mar 2019 10:21:51 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.0 MIME-Version: 1.0 In-Reply-To: <155324623015.23003.17581075186850679270@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-wilde-service-link-rel-10 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, 22 Mar 2019 09:22:02 -0000 hello stefan. thanks a lot for the review! On 2019-03-22 10:17, Stefan Santesson via Datatracker wrote: > Reviewer: Stefan Santesson > Review result: Has Nits > > This document seems to be ready and well written. The security considerations > section seems reasonable. > > However, I do agree with previous review that the requirements language > boilerplate may be redundant. There are only 2 capital SHOULD requirements in > the document and they both appear in the security considerations section. None > of them are referring to things that can be tested for compliance and they > could both be downgraded to "should". that sounds reasonable. if everybody agrees on that, i'd be more than happy to make this change: - lowercase the two capitalized requirements. - remove RFC 2119 and RFC 8174 section and references. thanks and kind regards, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Fri Mar 22 03:45:06 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 453D71315F2; Fri, 22 Mar 2019 03:44:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stefan Santesson via Datatracker To: Cc: extra@ietf.org, ietf@ietf.org, draft-ietf-extra-imap-fetch-preview.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Stefan Santesson Message-ID: <155325148211.23112.1549884159837912898@ietfa.amsl.com> Date: Fri, 22 Mar 2019 03:44:42 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-extra-imap-fetch-preview-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, 22 Mar 2019 10:44:54 -0000 Reviewer: Stefan Santesson Review result: Has Issues This document seems to provide a reasonable contribution and I have no opinion on the subject matter of this document. However the security consideration section seems to lack relevant information. The current security considerations section raise the threat of DOS attacks. It is, however, not clear to me how the risk of DOS is affected or mitigated by the fact that request for preview data is restricted to authenticated clients. A discussion of this seems at least to be relevant for the context. From nobody Fri Mar 22 14:09: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 14C3C131582 for ; Fri, 22 Mar 2019 14:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, 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 g0Xacch1amVy for ; Fri, 22 Mar 2019 14:09:54 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 4CB6513157D for ; Fri, 22 Mar 2019 14:09:54 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x2ML9K2O023971 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 22 Mar 2019 23:09:20 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x2ML9IAV025639; Fri, 22 Mar 2019 23:09:18 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23701.20222.800709.83035@fireball.acr.fi> Date: Fri, 22 Mar 2019 23:09:18 +0200 From: Tero Kivinen To: Peter Gutmann Cc: Paul Wouters , Watson Ladd , "Martin Thomson" , denis bider , secdir In-Reply-To: <1553092722905.88359@cs.auckland.ac.nz> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> <679B6759-5AD3-4F28-9EF4-8794F383468B@mit.edu> <1552890164140.4569@cs.auckland.ac.nz> <1552957626423.33373@cs.auckland.ac.nz> <23698.19223.566447.639174@fireball.acr.fi> <1553092722905.88359@cs.auckland.ac.nz> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 14 min X-Total-Time: 21 min Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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, 22 Mar 2019 21:09:57 -0000 Peter Gutmann writes: > Tero Kivinen writes: > I think it was more than just that, if you look at what you'd need to do for > an -02 client, so "General Packet Format" to the end of "Requests From the > Client to the Server" that's fifteen pages. In -13 the same thing is forty- > two pages (!!), and also draws in chunks of NFSv4 by reference. It's gone > from being a means of getting a file from A to B to trying to reinvent NFS, > with all the attendant complexity. All this work and changes was done in the secsh wg and did nt require any rechartering or wg forming. Different people do have different opinions who things should be done, and it seems the new editors of the draft added quite a lot of stuff, most likely by the request of the working group. > I can see why an implementer would want to stop at -02, which is exactly what > I did when I had to do an SFTP implementation, -13 had reached the point where > it was growing without bounds with little to no benefit from the massive > complexity being added to it. And most likely the issue there was that the implementors did not want to come to the WG meetings anymore because of the personal conflicts between people. I did hear some people saying to me that they do not want to go to the secsh wg meetings at all because going there will cause them to get shitstorm destined to you and they did not want to receive such things. So in the end there was not enough people working on the protocol and thats why it got where it ended up. None of this is failure is because of "hassle in setting up WG", or "rigorous rechartering" issues. There was existing working group that was workin on the document, it was just failure of people working in the existing wg and failure to reach consensus on filexfer draft. It was not setting up wg would be too hard, or that the ietf process would be broken in general. -- kivinen@iki.fi From nobody Fri Mar 22 14:20:38 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 7228312D550 for ; Fri, 22 Mar 2019 14:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, 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 RzLiMqg86Jsv for ; Fri, 22 Mar 2019 14:20:34 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 526EF127873 for ; Fri, 22 Mar 2019 14:20:34 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x2MLKUeE024237 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 22 Mar 2019 23:20:30 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x2MLKU4B018539; Fri, 22 Mar 2019 23:20:30 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23701.20894.682242.277408@fireball.acr.fi> Date: Fri, 22 Mar 2019 23:20:30 +0200 From: Tero Kivinen To: Benjamin Kaduk Cc: secdir@ietf.org In-Reply-To: <20190320160610.GH80498@kduck.mit.edu> References: <20190320160610.GH80498@kduck.mit.edu> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 11 min Archived-At: Subject: [secdir] No secdir lunch in Prague 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, 22 Mar 2019 21:20:36 -0000 Benjamin Kaduk writes: > Hopefully Tero can send out a link to the statistics page so we can all see > how we're doing. I think the statistics pages are limited to secretary and perhaps ADs, so I cannot really send out link. But I think the statistics are about same than before, meaning slowing getting better. During the last year, we have finished 113 reviews in time, and 77 late. 35 reviews was not finished at all. This is out of 225 closed reviews in total making it so that we finish 50% of reviews in time, and 34% late, and miss 15% of reviews. We used to have more of dropped reviews but as we have been removing reviewers missing several review request in a row, that will improve our statistics too. Te statistics for review results are so that 29% of documents have issues, 28% have nits and 42% are ready. For about 1% the result has been "Not Ready". -- kivinen@iki.fi From nobody Fri Mar 22 14:37:44 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 D95FF1311A9; Fri, 22 Mar 2019 14:37:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: Cc: draft-ietf-iasa2-consolidated-upd.all@ietf.org, iasa20@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Tero Kivinen Message-ID: <155329064880.23067.2004007621291938619@ietfa.amsl.com> Date: Fri, 22 Mar 2019 14:37:28 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-iasa2-consolidated-upd-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, 22 Mar 2019 21:37:29 -0000 Reviewer: Tero Kivinen 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 has security considerations section which says: The changes specified in this document are matters of terminology and organizational structure derived from documents it references. It should have no effect on Internet security. I agree on that and do not think there are any effect on the security, so I think this document is ready From nobody Fri Mar 22 14:55:03 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 A25C4131585 for ; Fri, 22 Mar 2019 14:55:01 -0700 (PDT) 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.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <155329170165.23063.11614169642740227341.idtracker@ietfa.amsl.com> Date: Fri, 22 Mar 2019 14:55:01 -0700 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, 22 Mar 2019 21:55:02 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-04-11 Reviewer LC end Draft Daniel Franke 2019-03-18 draft-ietf-sidrops-https-tal-07 Phillip Hallam-Baker 2019-03-18 draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04 Leif Johansson 2019-03-14 draft-ietf-dmarc-eaiauth-03 Sandra Murphy R2019-01-31 draft-ietf-ccamp-rsvp-te-bandwidth-availability-14 Vincent Roca R2018-10-29 draft-ietf-pce-gmpls-pcep-extensions-13 Last calls: Reviewer LC end Draft Derek Atkins 2019-03-03 draft-ietf-netmod-module-tags-07 Nancy Cam-Winget 2019-02-15 draft-ietf-rtcweb-security-11 Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-27 Daniel Gillmor 2018-03-19 draft-gutmann-scep-13 Charlie Kaufman 2019-03-14 draft-ietf-trans-rfc6962-bis-31 Watson Ladd 2019-04-01 draft-ietf-bess-bgp-vpls-control-flags-07 Chris Lonvick 2019-04-12 draft-ietf-netconf-subscribed-notifications-23 Aanchal Malhotra 2019-04-12 draft-ietf-netconf-restconf-notif-13 David Mandelberg 2019-04-12 draft-ietf-netconf-netconf-event-notifications-17 Catherine Meadows 2019-04-12 draft-ietf-mmusic-rfc4566bis-34 Alexey Melnikov 2019-04-11 draft-ietf-sidrops-lta-use-cases-05 Daniel Migault 2019-04-11 draft-ietf-roll-useofrplinfo-25 Matthew Miller 2019-04-08 draft-ietf-core-multipart-ct-03 Adam Montville 2019-04-05 draft-ietf-manet-dlep-multi-hop-extension-06 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Tim Polk 2019-02-13 draft-ietf-sipcore-reason-q850-loc-07 Vincent Roca R2019-02-13 draft-ietf-perc-private-media-framework-09 Takeshi Takahashi R2019-04-12 draft-ietf-netconf-yang-push-22 Takeshi Takahashi R2018-08-31 draft-ietf-lisp-rfc6833bis-24 David Waltermire 2019-02-15 draft-ietf-rtcweb-ip-handling-11 Klaas Wierenga 2019-02-26 draft-ietf-mpls-sr-over-ip-03 Taylor Yu 2019-02-15 draft-ietf-rtcweb-security-arch-18 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-11 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Scott Kelly 2019-03-22 draft-ietf-rift-rift-04 Kathleen Moriarty 2019-04-08 draft-ietf-bmwg-ngfw-performance-00 Next in the reviewer rotation: Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman Radia Perlman Derrell Piper Tim Polk Vincent Roca Kyle Rose From nobody Fri Mar 22 22:01:37 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 6A090130E5E for ; Fri, 22 Mar 2019 22:01:35 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 pDPzt-JOifud for ; Fri, 22 Mar 2019 22:01:33 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 9EFCC130E64 for ; Fri, 22 Mar 2019 22:01:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1553317292; x=1584853292; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wI0mUY8Ww8AqmQk/ik27Chx8/d9bQZi/XRXoq8bQ3Q4=; b=iBVPJ1CspK1SkJGVYse3D6JkR9FmttyQqAKPjUvunL38LEBkmXS5Ax54 XGXJsz9h8p/KN2NbkHltM1mS+UuBXY9TymG841hNk1z1mTTU42ArQNJxV jgei1K200hh6hvpEy58ET6D/uA+0FOEUFgQkoeXyM3PBL4H/DvYIW+6k4 TP1EoMa3anL4DKmVXAJFGOSfX5BASZ8IhXt6WtGZDPIPnxz3EZ5oO63sn ZnmEkWEOBrPYb7IpLbS9UAjJPV2eFv9MLLLxEoikcFkXGkg2FbLMmBIy+ qw+sADMJM1YbsPlRDN/ZzScm6jxyix4tgXgeSGBivi4T+S66znYZRnSqR g==; X-IronPort-AV: E=Sophos;i="5.60,256,1549882800"; d="scan'208";a="52780419" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-d.UoA.auckland.ac.nz) ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 23 Mar 2019 18:01:23 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 23 Mar 2019 18:01:23 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Sat, 23 Mar 2019 18:01:23 +1300 From: Peter Gutmann To: Tero Kivinen CC: Paul Wouters , Watson Ladd , "Martin Thomson" , denis bider , secdir Thread-Topic: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts Thread-Index: AQHU3aTDUNM95/0j6k6IffzkMJOWPaYQyH0AgAFcYn2AAZTBgIAA4CSJgAK4CgCAAV2QYw== Date: Sat, 23 Mar 2019 05:01:23 +0000 Message-ID: <1553317213454.59159@cs.auckland.ac.nz> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5FAC333B-38EF-4F58-89FB-3DF3F774DD2C@inf.ethz.ch> <679B6759-5AD3-4F28-9EF4-8794F383468B@mit.edu> <1552890164140.4569@cs.auckland.ac.nz> <1552957626423.33373@cs.auckland.ac.nz> <23698.19223.566447.639174@fireball.acr.fi> <1553092722905.88359@cs.auckland.ac.nz>, <23701.20222.800709.83035@fireball.acr.fi> In-Reply-To: <23701.20222.800709.83035@fireball.acr.fi> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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, 23 Mar 2019 05:01:35 -0000 Tero Kivinen writes:=0A= =0A= >Different people do have different opinions who things should be done, and= it=0A= >seems the new editors of the draft added quite a lot of stuff, most likely= by=0A= >the request of the working group.=0A= =0A= It'd be interesting to get comments from people involved as to why all the = new=0A= stuff was added, it's far enough in the past that I don't think it matters = any=0A= more if people comment on it. The two major client and server=0A= implementations, OpenSSH and Putty, don't do the stuff from the newer draft= s,=0A= and I know of several other implementations that also don't do it, so who/w= hat=0A= was driving it?=0A= =0A= >I did hear some people saying to me that they do not want to go to the sec= sh=0A= >wg meetings at all because going there will cause them to get shitstorm=0A= >destined to you and they did not want to receive such things.=0A= =0A= Hmm, interesting, hadn't heard that about the SSH WG specifically, although= =0A= I've heard it about one or two others. So the SFTP work stopped because of= =0A= infighting, not because people lost interest/V3 was good enough?=0A= =0A= Peter.=0A= From nobody Sat Mar 23 16:53:02 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 AFDC2130D7A for ; Sat, 23 Mar 2019 16:52:59 -0700 (PDT) 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_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mandelberg.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 35AX_PdEpMbN for ; Sat, 23 Mar 2019 16:52:57 -0700 (PDT) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 8421612D550 for ; Sat, 23 Mar 2019 16:52:57 -0700 (PDT) X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=B6n766lM c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=KGjhK52YXX0A:10 a=kqfrNJGqfZkA:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=NTGMnVQrEZIA:10 a=bmmO2AaSJ7QA:10 a=iiazv-oawmH03g7Men8A:9 a=QEXdDO2ut3YA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZHNlb21uQHJjbi5jb20= Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=david@mandelberg.org; spf=softfail; sender-id=softfail Authentication-Results: smtp01.rcn.cmh.synacor.com header.DKIM-Signature=@mandelberg.org; dkim=pass Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=david@mandelberg.org; sender-id=softfail Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN) Received: from [209.6.43.168] ([209.6.43.168:56654] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384) id 53/6F-23993-7D6C69C5; Sat, 23 Mar 2019 19:52:55 -0400 Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 428871C604F; Sat, 23 Mar 2019 19:52:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; s=201903; t=1553385174; bh=lPAAUdv3XwYdJtZrdUkVtOTL/k/Z7lfoLODIrcZVpbk=; h=To:From:Subject:Date:From; b=Sz1/5iUl5T5uNQrI5nicsmfSE81NdIVLiaLDhpj6hIvKtznzkX5nnNV28SbPG635L fNWTCduztSjoSJOZU7WzvEotbp6Aghht7CMriI9uhpwypubQLjAKbsYR29CKdGr6Iz 0qAFg4chwNGRTCFzums0uRXxZdIHnEG6P4wtSICs/Watvz08bfI9c6BSZdDRxN0dpc PJjYrBDYiyiA27Ze0zGyFYco+ijPwUGOwU8Jc/i62F/OP39zkFhZc3kNuTjFviE2ZN c0BflrxhMIEaC34yyJ8csH3ziaMn7J0QDqRD0s2P+g9+zqigJfQmkOH5lsBtjwKbyI VqLYKKbAsLgOQ== To: secdir@ietf.org, iesg@ietf.org, draft-ietf-netconf-netconf-event-notifications.all@ietf.org From: David Mandelberg Message-ID: <7ca1df82-7fec-4f91-8bbc-e2c3e9f58f64@mandelberg.org> Date: Sat, 23 Mar 2019 19:52:51 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] secdir review of draft-ietf-netconf-netconf-event-notifications-17 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, 23 Mar 2019 23:53:00 -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. The summary of the review is Ready. I don't know much about NETCONF or YANG, but this document looks reasonable. From nobody Sun Mar 24 03:02:49 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 527C012785F for ; Sun, 24 Mar 2019 03:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.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 W4UuzQqGyn2n for ; Sun, 24 Mar 2019 03:02:37 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 EF2CC130E79 for ; Sun, 24 Mar 2019 03:02:36 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id q66so5342197ljq.7 for ; Sun, 24 Mar 2019 03:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aBHHqINkO99X6L3iyRPNaWNvcb0Rkk/q5KSDYvSVm5Y=; b=TuM9y6ZwgDm8vgBOI2Q2IargMTdjzzPohD/M5/Q6KntxwuNj7DrjLdQ6QMYVKu3jRR xL/K73Q2AAW4cqqEEU8oM9QSRSh2Ua6ZnXHPhcoI1/tzPEKpmpQ6UR192WiI/BquLMuZ tIAAlqZxeICswtBuKo7ebZbRLltzkph5XMvxWgOgBcN2D8A/w0/YS/n8vfv87h6atPDv 0B4NgTaCS0Sp7Y8DJq/90ZysewXJEUZYy623n+JCaFEFMNcTEyxdUJ74Ntl+c2VaPjsQ k/VxVt9rp+jE46Dhnoel/5b4viMmYGt4Ky65DeDhiXUXQIx1MIAUDe5qMuNLl8TGloho xy/Q== 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=aBHHqINkO99X6L3iyRPNaWNvcb0Rkk/q5KSDYvSVm5Y=; b=b6CHQsyojpgTffIkS//qw6bSiOgO7KT0eabpyjrI8d9ttAWugXPRZ3O4zzuEoR/60P Nr4+D++Y90pzJb+zksArywwS4d+AeZoQsrckoC1RYxQEZizXC0Q7x5gX/fv55VUlQZBm YZr47ChRLCdz7Ll/haVhxdjGvkhMCjkzMgb7MV3jVp2SVjoVxm4GxDhNE3J/E9/HIpsU 583DU7lXCtJksxYu+zogljj5IXvmv6rPzbPMQYZntdK7kWPpzOp8ZO9NonDpMfmmAIwo LBjc6avTCmpyONtiaG7ID/h6iW6vEGR9KnXxGHE90oWq3aRPCg03LsyQHtRm+VmEG4Ku dRKg== X-Gm-Message-State: APjAAAX06CyWqORqIQ5J3qdXVoCIm/Rfyqp0byDPc3NtgsZkogk1DRzw 8wQ378E3BdYa/V4IABmQ/f8D69LGEo6PfVB8vT35og== X-Google-Smtp-Source: APXvYqyEJMulXcx+s/ibADtJeKmFaRvgO+AsvcwFDmavZRuEBkPOMA4QhW7RUwcjjUxnjIF4Vq+7zdpJTmwOsMr190g= X-Received: by 2002:a2e:3204:: with SMTP id y4mr9981754ljy.90.1553421754974; Sun, 24 Mar 2019 03:02:34 -0700 (PDT) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5D247CD2-710E-4C78-8495-085C70D4CFAB@cisco.com> <9b192f26-8c19-494f-7430-7d1ca24872a3@nthpermutation.com> In-Reply-To: From: "StJohns, Michael" Date: Sun, 24 Mar 2019 11:02:24 +0100 Message-ID: To: mcgrew Cc: CFRG , "RFC ISE (Adrian Farrel)" , Richard Barnes , secdir Content-Type: multipart/alternative; boundary="000000000000e453a70584d42fd5" Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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, 24 Mar 2019 10:02:42 -0000 --000000000000e453a70584d42fd5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry for the top post - it=E2=80=99s hard to get a coherent edit using an = iPad. Basically, you=E2=80=99ve confirmed what I said - that the CFRG is doing st= andards like stuff, and that it just chose to do so. I note that the change in behavior was not accompanied by a change in the charter. I=E2=80=99d expec= t that going through a recharterng exercise to bring in line the documentation with the group behavior would lend more credence to the idea that the charter should be written for a WG. WRT the registry - registries are usually created as a result of a standards action and I was quite surprised to find that this one had been created. You used the phrase =E2=80=9Cmake the specification future proof= =E2=80=9D which again is more IETF than IRTF IMHOand suggests that the IETF should have change control. Later, Mike On Tue, Mar 19, 2019 at 14:23 mcgrew wrote: > Hi Mike, > > Please see inline: > > > On Mar 18, 2019, at 4:43 PM, Michael StJohns > wrote: > > > > I don't understand - usually when I say "I'm fine with the status quo > for now" people stop arguing with me. Oh well. > > > > And thanks David for making some points for me. See below. > > > > > > On 3/18/2019 9:26 AM, mcgrew wrote: > >> Hi Mike, > >> > >> Let me add few data points from a CFRG-historical perspective. CFRG > has been the first publisher of a number of specifications (for instance, > XMSS, Poly1305, and HBS are in this category - > https://datatracker.ietf.org/rg/cfrg/documents/) and has done essential > review for some ISE-published crypto like UMAC (RFC 4418). > > > > My point was that becoming a first publisher puts the CFRG into the > position of being the standardizer. XMSS, Poly1305 and HBS (not yet > published) are all 2018 and 2019 documents. EDDSA was 2017. In fact the > set of documents currently attributed to the CFRG only goes back to 2014 > while the CFRG has been around a lot longer than that. Something changed > > The RG shifted from discussing and reviewing independent documents toward= s > producing its own documents. > > > and now we're getting standards-like production out of the CFRG. Note > that I don't think its a bad thing per se, just that you need to be > following different rules than those that are applicable to RGs. > > > > For example, why does an informational document in the research stream > need a registry? (e.g. RFC8391) That's about as obvious a > standardization requirement as any I've seen in CFRG documents. > > The registry and the interface and extensibility it provides is essential > to making a crypto specification future-proof. That is clearly best > practice in cryptography, and as such is totally appropriate for the outp= ut > of an IRTF RG document. Some independent documents that were reviewed b= y > CFRG also had registries. > > David > > > > >> For UMAC, it is worth noting that the ISE reviewers asked for changes > around IPR language, > > > > I don't think I even recall seeing anything that wants to use UMAC - I > may have missed a protocol or two though. In any event, the request was = to > REMOVE claims about IPR language from the document and direct the authors > to make a normal IPR disclosure. Again - pretty consistent with what we d= o > with standards and IETF stream documents. > > > >> and CFRG reviewers made important improvements to the technical conten= t > as well (https://datatracker.ietf.org/doc/rfc4418/history/ and CFRG mail > threads from fall 2005). So the issues we are dealing with today are not > really new. > > > > But again, that's normal for any document that comes in through any > stream - specifically - people review it and usually irrespective of > association with a specific WG/RG/directorate, etc. The fact that the > document author, the ISE and the IESG reached out the the CFRG is pretty > much an example of looking for the experts in a pile of experts. I'm not > sure why this wouldn't happen if the CFRG were chartered as a WG? > > > > > >> > >> You have started a good, healthy discussion with the points that you > have raised. My thinking is that CFRG (including Kenny, Alexy, and the > many contributors) is doing really good, really important work, and the > IRTF and IETF should avoid changes that would disrupt it. > > > > I don't want to change the people, I don't even want to change the work > flow (much - except that moving it to a WG would actually remove the IRTF > from the approval process for an RFC), I just want this to be appropriate= ly > categorized and managed as a WG and subject to the same rules as any othe= r > WG. I think its gone well past the normal rules for an RG at this point= . > > > > Again - I've indicated my concerns and I'm happy the discussion is > happening. Unfortunately what I keep hearing is "we like it the way it i= s, > now go and leave us alone" rather than "we're really a RG because we do > things X, Y and Z so we really don't need to be a WG". I'd really like t= o > hear more commentary on that latter - especially how the CFRG in fact > differs from the behavior of a WG. > > > > Thanks - Mike > > > > > > > >> > >> Best, > >> > >> David > >> > >>> On Mar 15, 2019, at 2:52 PM, Michael StJohns > wrote: > >>> > >>> On 3/13/2019 7:32 AM, Richard Barnes wrote: > >>>> Mike, are your concerns here primarily IPR related? If that's so, > then maybe that's the level at which we should address them, as opposed t= o > flipping the bigger RG->WG switch. > >>>> > >>> Hi Richard - > >>> > >>> Like I said, I'm not going to push this at this time. But I think it= s > more than just IPR - avoiding technology because of IPR is more a symptom > (and in fact is IETF guidance rather than IRTF policy). > >>> > >>> The CFRG has a unique position in that - unlike ANY other RG as far a= s > I can tell - it's looked at as an immediate feeder for technology for the > IETF. If it were agnostically evaluating the crypto properties of any > offered technology, I'd say we're good and I'd move on. But, with the > publication of Curve25519 and its related ... standards ..., the CFRG has > moved from evaluation and re-publication of cryptographic standards > developed and produced elsewhere into being the first publisher of what > could only be characterized as standards, even if published as an > Informational RFC in the IRTF stream. > >>> > >>> Ultimately, I think it comes down to fairness and transparency. As an > RG, the publications of the RG are not subject to the standards appeals > process. In an WG, the decision not to work on an IPR encumbered > technology (or others such as national cryptography) MAY be appealed and > overturned (or might not) or sponsored by an AD if there's no applicable = or > agreeable WG. There's a process for showing such decisions were made > transparently, and with a broader audience than just the CFRG having a sa= y. > >>> > >>> > >>> Later, Mike > >>> > >>> Ps - hmm... Note that the CFRG charter only mentions the IETF and not > the IRTF.... > >>> > >>> _______________________________________________ > >>> Cfrg mailing list > >>> Cfrg@irtf.org > >>> https://www.irtf.org/mailman/listinfo/cfrg > > > > > > --000000000000e453a70584d42fd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for the top post - it=E2=80=99s hard to get a = coherent edit using an iPad. =C2=A0

=
Basically, you=E2=80=99ve confirmed what I said - that th= e CFRG is doing standards like stuff, and that it just chose to do so.=C2= =A0 I note that the change in behavior was not accompanied by a change in t= he charter.=C2=A0 I=E2=80=99d expect that going through a recharterng exerc= ise to bring in line the documentation with the group behavior would lend m= ore credence to the idea that the charter should be written for a WG.=C2=A0=

WRT the registry - regi= stries are usually created as a result of a standards action and I was quit= e surprised to find that this one had been created.=C2=A0 You used the phra= se =E2=80=9Cmake the specification future proof=E2=80=9D which again is mor= e IETF than IRTF IMHOand suggests that the IETF should have change control.= =C2=A0=C2=A0

Later, Mik= e


=C2=A0

On Tue, Mar 19, 2019 at 14:23 mcgrew <mcgrew@cisco.com> wrote:
Hi Mike,

Please see inline:

> On Mar 18, 2019, at 4:43 PM, Michael StJohns <msj@nthpermutation.com> wrote= :
>
> I don't understand - usually when I say "I'm fine with th= e status quo for now" people stop arguing with me.=C2=A0 =C2=A0Oh well= .
>
> And thanks David for making some points for me.=C2=A0 See below.
>
>
> On 3/18/2019 9:26 AM, mcgrew wrote:
>> Hi Mike,
>>
>> Let me add few data points from a CFRG-historical perspective.=C2= =A0 CFRG has been the first publisher of a number of specifications (for in= stance, XMSS, Poly1305, and HBS are in this category -=C2=A0 https://datatracker.ietf.org/rg/cfrg/documents/) and has done e= ssential review for some ISE-published crypto like UMAC (RFC 4418).
>
> My point was that becoming a first publisher puts the CFRG into the po= sition of being the standardizer.=C2=A0 XMSS, Poly1305 and HBS (not yet pub= lished) are all 2018 and 2019 documents.=C2=A0 EDDSA was 2017.=C2=A0 In fac= t the set of documents currently attributed to the CFRG only goes back to 2= 014 while the CFRG has been around a lot longer than that.=C2=A0 Something = changed

The RG shifted from discussing and reviewing independent documents towards = producing its own documents.=C2=A0

> and now we're getting standards-like production out of the CFRG.= =C2=A0 Note that I don't think its a bad thing per se, just that you ne= ed to be following different rules than those that are applicable to RGs. >
> For example, why does an informational document in the research stream= need a registry?=C2=A0 (e.g. RFC8391)=C2=A0 =C2=A0That's about as obvi= ous a standardization requirement as any I've seen in CFRG documents.
The registry and the interface and extensibility it provides is essential t= o making a crypto specification future-proof. That is clearly best practice= in cryptography, and as such is totally appropriate for the output of an I= RTF RG document.=C2=A0 =C2=A0Some independent documents that were reviewed = by CFRG also had registries.

David

>
>>=C2=A0 For UMAC, it is worth noting that the ISE reviewers asked fo= r changes around IPR language,
>
> I don't think I even recall seeing anything that wants to use UMAC= - I may have missed a protocol or two though.=C2=A0 In any event, the requ= est was to REMOVE claims about IPR language from the document and direct th= e authors to make a normal IPR disclosure. Again - pretty consistent with w= hat we do with standards and IETF stream documents.
>
>> and CFRG reviewers made important improvements to the technical co= ntent as well (https://datatracker.ietf.org/doc/rfc= 4418/history/ and CFRG mail threads from fall 2005).=C2=A0 So the issue= s we are dealing with today are not really new.
>
> But again, that's normal for any document that comes in through an= y stream - specifically - people review it and usually irrespective of asso= ciation with a specific WG/RG/directorate, etc.=C2=A0 The fact that the doc= ument author, the ISE and the IESG reached out the the CFRG is pretty much = an example of looking for the experts in a pile of experts.=C2=A0 I'm n= ot sure why this wouldn't happen if the CFRG were chartered as a WG? >
>
>>
>> You have started a good, healthy discussion with the points that y= ou have raised.=C2=A0 My thinking is that CFRG (including Kenny, Alexy, and= the many contributors) is doing really good, really important work, and th= e IRTF and IETF should avoid changes that would disrupt it.
>
> I don't want to change the people, I don't even want to change= the work flow (much - except that moving it to a WG would actually remove = the IRTF from the approval process for an RFC), I just want this to be appr= opriately categorized and managed as a WG and subject to the same rules as = any other WG.=C2=A0 =C2=A0I think its gone well past the normal rules for a= n RG at this point.
>
> Again - I've indicated my concerns and I'm happy the discussio= n is happening.=C2=A0 Unfortunately what I keep hearing is "we like it= the way it is, now go and leave us alone" rather than "we're= really a RG because we do things X, Y and Z so we really don't need to= be a WG".=C2=A0 I'd really like to hear more commentary on that l= atter - especially how the CFRG in fact differs from the behavior of a WG.<= br> >
> Thanks - Mike
>
>
>
>>
>> Best,
>>
>> David
>>
>>> On Mar 15, 2019, at 2:52 PM, Michael StJohns <msj@nthpermutation.com&g= t; wrote:
>>>
>>> On 3/13/2019 7:32 AM, Richard Barnes wrote:
>>>> Mike, are your concerns here primarily IPR related?=C2=A0 = If that's so, then maybe that's the level at which we should addres= s them, as opposed to flipping the bigger RG->WG switch.
>>>>
>>> Hi Richard -
>>>
>>> Like I said, I'm not going to push this at this time.=C2= =A0 But I think its more than just IPR - avoiding technology because of IPR= is more a symptom (and in fact is IETF guidance rather than IRTF policy).<= br> >>>
>>> The CFRG has a unique position in that - unlike ANY other RG a= s far as I can tell - it's looked at as an immediate feeder for technol= ogy for the IETF.=C2=A0 If it were agnostically evaluating the crypto prope= rties of any offered technology, I'd say we're good and I'd mov= e on.=C2=A0 But, with the publication of Curve25519 and its related ... sta= ndards ..., the CFRG has moved from evaluation and re-publication of crypto= graphic standards developed and produced elsewhere into being the first pub= lisher of what could only be characterized as standards, even if published = as an Informational RFC in the IRTF stream.
>>>
>>> Ultimately, I think it comes down to fairness and transparency= . As an RG, the publications of the RG are not subject to the standards app= eals process.=C2=A0 In an WG, the decision not to work on an IPR encumbered= technology (or others such as national cryptography) MAY be appealed and o= verturned (or might not) or sponsored by an AD if there's no applicable= or agreeable WG. There's a process for showing such decisions were mad= e transparently, and with a broader audience than just the CFRG having a sa= y.
>>>
>>>
>>> Later, Mike
>>>
>>> Ps - hmm... Note that the CFRG charter only mentions the IETF = and not the IRTF....
>>>
>>> _______________________________________________
>>> Cfrg mailing list
>>> Cfrg@irtf.o= rg
>>> https://www.irtf.org/mailman/listinfo/cfrg
>
>

--000000000000e453a70584d42fd5-- From nobody Sun Mar 24 07:50:15 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 801E112797D for ; Sun, 24 Mar 2019 07:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AaIEBkgMKiq for ; Sun, 24 Mar 2019 07:50:07 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77024130DEA for ; Sun, 24 Mar 2019 07:50:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 24EB5BEFA; Sun, 24 Mar 2019 14:50:04 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8qm-gvM17r4; Sun, 24 Mar 2019 14:49:57 +0000 (GMT) Received: from [31.133.147.198] (dhcp-93c6.meeting.ietf.org [31.133.147.198]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DFD29BEE5; Sun, 24 Mar 2019 14:49:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1553438997; bh=zDKaPY9BTCir0fx9hzhIXIR8xiO8okrUcjKrqIO2bdM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=lphmzbUog8Bbdd34Cp+hQdeTgxda/tArZUY5MznXC1Fa/71cEcB4jHUW3gG5pd/NZ y/pCfhKFBd+be8nFDb0Ro9Kafv2t8bR2kfF97Nb30KK8V0u+OiNfiEaLoTr4Ujfdix NwzKHLH0xVEWYHt1q6XEFNSUEpZtWQ1yaaFyIsgs= To: "StJohns, Michael" , mcgrew Cc: CFRG , "RFC ISE (Adrian Farrel)" , secdir References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5D247CD2-710E-4C78-8495-085C70D4CFAB@cisco.com> <9b192f26-8c19-494f-7430-7d1ca24872a3@nthpermutation.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <3d242ab6-9b86-d86e-0613-1426c3a5838a@cs.tcd.ie> Date: Sun, 24 Mar 2019 14:49:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Afy7dbzRKERSbsmJbHDp1vOPKRXZGp3bv" Archived-At: Subject: Re: [secdir] [Cfrg] Time to recharter CFRG as a working group? Was: Re: ISE seeks help with some crypto drafts 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, 24 Mar 2019 14:50:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Afy7dbzRKERSbsmJbHDp1vOPKRXZGp3bv Content-Type: multipart/mixed; boundary="sh3IC7OoWJnLkrRKXgmi88w2bf8rv5mIk"; protected-headers="v1" From: Stephen Farrell To: "StJohns, Michael" , mcgrew Cc: CFRG , "RFC ISE (Adrian Farrel)" , secdir Message-ID: <3d242ab6-9b86-d86e-0613-1426c3a5838a@cs.tcd.ie> Subject: Re: [Cfrg] Time to recharter CFRG as a working group? Was: Re: [secdir] ISE seeks help with some crypto drafts References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <20190310182935.GE8182@kduck.mit.edu> <20190310191026.GF8182@kduck.mit.edu> <042b3f13-7d5a-12d7-e604-9f8cad197608@cs.tcd.ie> <3FA4B2DD-334E-4C7C-A01E-6C370CAE4C00@ll.mit.edu> <2935C6E3-3AE8-4447-BA01-8DAE0410E5C6@ericsson.com> <0d38eabd-6f90-2d19-3b45-f1ce19ba9b73@nthpermutation.com> <829ca608-8d47-083e-e0a6-e7276525b080@nthpermutation.com> <5D247CD2-710E-4C78-8495-085C70D4CFAB@cisco.com> <9b192f26-8c19-494f-7430-7d1ca24872a3@nthpermutation.com> In-Reply-To: --sh3IC7OoWJnLkrRKXgmi88w2bf8rv5mIk Content-Type: multipart/mixed; boundary="------------DFCFED01E3498AA5F827E009" Content-Language: en-GB This is a multi-part message in MIME format. --------------DFCFED01E3498AA5F827E009 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 24/03/2019 10:02, StJohns, Michael wrote: > I=E2=80=99d expect that > going through a recharterng exercise to bring in line the documentation= > with the group behavior would lend more credence to the idea that the > charter should be written for a WG. I'm not at all convinced that that'd be worthwhile TBH. ISTM that cfrg is functioning well, so a re-charter seems like it'd not be so useful, and possibly worse (being distracting). cfrg's credibility comes from it's output, not it's charter, for me at least. S. --------------DFCFED01E3498AA5F827E009 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------DFCFED01E3498AA5F827E009-- --sh3IC7OoWJnLkrRKXgmi88w2bf8rv5mIk-- --Afy7dbzRKERSbsmJbHDp1vOPKRXZGp3bv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAlyXmREACgkQWrL68XsX K+qBSBAAgzb9Oeey467c456ZRuXMzIvRdPhP494KDAaALwtFop0u9c4yUvtntMAT AQeEmVola8vjva3kfSu5mVBZzS4bhx2h1Ihl8Mm1TVLy5DDeKdWIKz72J6ljxLja axnIwmWnxMxcJNy96xS+lJncvK4EV27bCpv4NH0jKozO9Ko4s5EjKC2sA15G1upH FyNg2O0SOzRCiMENYU009kPXi2sQwZChsV1cu56deLOzHJBEbqBek19vxcuowN0C V8wT9YZ5QL9Gxb2j65Ch2hQ6wMDsnwnZzLiCoPlHKOSP+TGJjU8fyGmOKUTRcesj Iu0Oa4SM1UBE/PAJefxYUazdPTGRNbpDF8mZcls6QHaxnUJ+JtvQ1yT6gPTIEQ1s a7S3qdVIAjBHWeeRmF9+fwCTtxCPHrMKivxgx4sRfwNuCXCylfaWifUVV8eu+KCd YB3bRSZde6Yb7mzGTvzXYUQzEeLkizjcHAG6sSMVmdtd8S4CH+1n496LgY3/8j3P ZM6e6FXP0RlINwyjQ9xa6gl9uwG+AZe64QOeQ5EhOP6S6GCZkwDCLUG0sqHmVdZp JnFO3YMvyW2Pndqr1fwjPi5cfT6jLZr30gik27reSlK335ZHv1CQC+S7Anmrx29T 8dyRWf1nNw6l+NVgGziULPrH7AO3qWe7E+Wn9yFVVYZyzkmU7fo= =+W+s -----END PGP SIGNATURE----- --Afy7dbzRKERSbsmJbHDp1vOPKRXZGp3bv-- From nobody Mon Mar 25 02:11: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 BE9B8120373; Mon, 25 Mar 2019 02:11:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Leif Johansson via Datatracker To: Cc: dmarc@ietf.org, draft-ietf-dmarc-eaiauth.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Leif Johansson Message-ID: <155350506670.22297.2525928721965597003@ietfa.amsl.com> Date: Mon, 25 Mar 2019 02:11:06 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dmarc-eaiauth-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: Mon, 25 Mar 2019 09:11:07 -0000 Reviewer: Leif Johansson 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 document is mostly ready. The one issue I have is that the security considerations section claims that the proposed changes attempts to mitigate some security issues in email involving SPF, DMARC and/or DKIM but it is not obvious (at least not to me) exactly what this amounts to. Additional text in the document to clarify this point seems like a good idea. Cheers Leif From nobody Mon Mar 25 03:58:00 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 1BAD012039D for ; Mon, 25 Mar 2019 03:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=yJiL7U8K; dkim=pass (1536-bit key) header.d=taugh.com header.b=eQW5jnU3 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 9UeKolBaeudv for ; Mon, 25 Mar 2019 03:57:55 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 54EBB1203A4 for ; Mon, 25 Mar 2019 03:57:55 -0700 (PDT) Received: (qmail 28700 invoked from network); 25 Mar 2019 10:57:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=701a.5c98b430.k1903; bh=ZQffTIX3WZyloAzFprOPBBSO++oiTCMQb4K2nAU3C14=; b=yJiL7U8KOlItfUCZLryxqBaLPzXAPuchYoQ3mQ3OqCO9uD+95oPNG8Ich1TVKT45vCz7uRoKhbE5U0IbySNPZyl4t7oLRTlYgHZ2Kpb6MWpSMrVZQXO7dkv7uqPVQBazdPuX6+Kk/0TFgX6X0M1vpg7bUX/KxlzMb69tAJ0dIW0D/gQvEIZxFvw9v0IXmhGn7px+0jeaX36iyBpY85kyvZv8wPnPzMMISqPjbtX184dxsdo0j8TkQxu5vh/eiwpW DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=701a.5c98b430.k1903; bh=ZQffTIX3WZyloAzFprOPBBSO++oiTCMQb4K2nAU3C14=; b=eQW5jnU3ZdwTCutK5rhRs4fvxVS5zQOKkj4KyjUorN5Hd7vusCIbg/MtuzqMYxnvprXxmM8Zl4KXyvVst5Z8YyN/JtNLXCPlVNhyjLPx+hp/xvHpnpN2bI8CDfrP9lHH4JK5OYWHXK8ir3M5t2VPPurq4/51UYXRaly+Dk4x77czsqUqz+2cJyEOfoSgwD8XQDKmWQVFMPgVd0UgNc/MqAVlBy41L/1fq0rv2ATOQyUHj3ellWguuiqrDGMtbcoe Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 25 Mar 2019 10:57:52 -0000 Date: 25 Mar 2019 10:57:49 +0000 Message-ID: From: "John R Levine" To: "Leif Johansson" Cc: secdir@ietf.org, dmarc@ietf.org, "Tim Wicinski" , "Murray Kucherawy" , alexey.melnikov@isode.com, ben@nostrum.com, "Barry Leiba" , adam@nostrum.com, "Kurt Andersen" In-Reply-To: <155350506670.22297.2525928721965597003@ietfa.amsl.com> References: <155350506670.22297.2525928721965597003@ietfa.amsl.com> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [secdir] [taugh.com-standards] Secdir last call review of draft-ietf-dmarc-eaiauth-03 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 Mar 2019 10:57:57 -0000 On Mon, 25 Mar 2019, Leif Johansson via Datatracker wrote: > The one issue I have is that the security considerations section claims > that the proposed changes attempts to mitigate some security issues > in email involving SPF, DMARC and/or DKIM but it is not obvious (at > least not to me) exactly what this amounts to. > > Additional text in the document to clarify this point seems like a good idea. Maybe I should just take that out. The only issue it mitigates is that it makes DKIM and DMARC checks on EAI mail more reliable. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Mar 25 03:59:24 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 5DB8C1203E0; Mon, 25 Mar 2019 03:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 KjIG4osKjbi3; Mon, 25 Mar 2019 03:59:11 -0700 (PDT) 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 84735120408; Mon, 25 Mar 2019 03:59:11 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2PAx3p6001666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 25 Mar 2019 06:59:05 -0400 Date: Mon, 25 Mar 2019 05:59:03 -0500 From: Benjamin Kaduk To: John R Levine Cc: Leif Johansson , Tim Wicinski , ben@nostrum.com, adam@nostrum.com, secdir@ietf.org, dmarc@ietf.org, Murray Kucherawy , Barry Leiba , Kurt Andersen Message-ID: <20190325105902.GC77890@kduck.mit.edu> References: <155350506670.22297.2525928721965597003@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [secdir] [taugh.com-standards] Secdir last call review of draft-ietf-dmarc-eaiauth-03 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 Mar 2019 10:59:21 -0000 On Mon, Mar 25, 2019 at 10:57:49AM +0000, John R Levine wrote: > On Mon, 25 Mar 2019, Leif Johansson via Datatracker wrote: > > The one issue I have is that the security considerations section claims > > that the proposed changes attempts to mitigate some security issues > > in email involving SPF, DMARC and/or DKIM but it is not obvious (at > > least not to me) exactly what this amounts to. > > > > Additional text in the document to clarify this point seems like a good idea. > > Maybe I should just take that out. The only issue it mitigates is that > it makes DKIM and DMARC checks on EAI mail more reliable. That seems important enough to state explicitly. -Ben From nobody Mon Mar 25 04:03:58 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 EA0CD1203B9 for ; Mon, 25 Mar 2019 04:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=v8IV5Xll; dkim=pass (1536-bit key) header.d=taugh.com header.b=puTi7+ni 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 pTiZkgd680cE for ; Mon, 25 Mar 2019 04:03:52 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 04BEB1203CF for ; Mon, 25 Mar 2019 04:03:51 -0700 (PDT) Received: (qmail 30611 invoked from network); 25 Mar 2019 11:03:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=778d.5c98b596.k1903; bh=w0pOjR0NHBc6bv2F/2yDSVptd1QDCv5DhfdFWIhUWWQ=; b=v8IV5Xllk/kg88R15nAmE592CMFj8cAs9fUJ6AlgkjNIt4p5OvzHb2lxxpYyXPqHuwwYu2BdYEHbdIXI48X8a2Vxv8i9dYG4v3tqGCsoz2iG5HJgKXRbX2wiwF51MYhQdVDvGIob8uXSIs7xa1n6lfv7RDCCfmZf19oBLDCb7uQ9IJTa6f7QLQGpUHhW1sVHAhlGLU4GK0bG3q/jK2CUF6LrhHt3gy4i/Yr/LTfvsK5sr3wu+sKmNabmCNinDcKJ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=778d.5c98b596.k1903; bh=w0pOjR0NHBc6bv2F/2yDSVptd1QDCv5DhfdFWIhUWWQ=; b=puTi7+niCLd67DciTIa2tDMbXneQM5X2yNw3MkHVOUIMjtMitrbFtngqUFPwRoatMDgVFUV887dGBmjMMIzAv+qJ+SYVvaWEi87DSfPYIOvKY8CTjG67yEy6IZodt/UEsLju7D33+FvZEVPEoVmT055+p8yr9oGqSFjvlXv/EDXmd8ZXP9ZVwROlWrhZjeTzMX9rwZ1a0GpucxaYh4ZJ2REb0x/GEOwZcyAt2iusnEunFMXYEyRK6GnMNlFdWMMO Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 25 Mar 2019 11:03:50 -0000 Date: 25 Mar 2019 11:03:47 +0000 Message-ID: From: "John R Levine" To: "Benjamin Kaduk" Cc: "Leif Johansson" , "Tim Wicinski" , ben@nostrum.com, adam@nostrum.com, secdir@ietf.org, dmarc@ietf.org, "Murray Kucherawy" , "Barry Leiba" , "Kurt Andersen" In-Reply-To: <20190325105902.GC77890@kduck.mit.edu> References: <155350506670.22297.2525928721965597003@ietfa.amsl.com> <20190325105902.GC77890@kduck.mit.edu> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [secdir] [taugh.com-standards] Secdir last call review of draft-ietf-dmarc-eaiauth-03 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 Mar 2019 11:03:56 -0000 On Mon, 25 Mar 2019, Benjamin Kaduk wrote: >> Maybe I should just take that out. The only issue it mitigates is that >> it makes DKIM and DMARC checks on EAI mail more reliable. > > That seems important enough to state explicitly. OK, added a sentence. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Mar 25 06:09:06 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 385AD120381 for ; Mon, 25 Mar 2019 06:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet.se 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 cBq1ChmuRy0u for ; Mon, 25 Mar 2019 06:09:02 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 59C9C1203EF for ; Mon, 25 Mar 2019 06:09:02 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id v14so9012203wmf.2 for ; Mon, 25 Mar 2019 06:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet.se; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r/uEUXBJC20H4BxLHKlnamceB/hsskYcgjBpREXU2S4=; b=KH8mixXXbFjjvo2xpNMIrrszGy+Tsys6qluUFuklZsFTfafz+h8uSNTdyoalxetMf7 SOoWO924ZmngE4XLB0byJF0FtkqtLam+dom9WJmwRKQWePJnxJrVp3t3JzLPVxrPE8uO x5svMWgntZkaYw5zZHoWSvZJUx4Ms9MJGQm8kcBp5j6YWX/cCvQjni3WWLE2qCUdzZ3d 5nqp8pr1Lnksb/ap7BnJyuhWi8vscUwbcUun9detBUxCBdaUxvODomhYkGHpWOlDNwgu egpNmlvqz+kYgS5BhPlg/M7ozpmj9tP3F8sqYLSW+s7gbJmiS6fAa29S7b4FSwHn90H0 XDIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r/uEUXBJC20H4BxLHKlnamceB/hsskYcgjBpREXU2S4=; b=sw/prTVyFl2IpadoeCr2JS6UL/UQE0whlApHcUgilBGvgN8nfSpGOMWAXpfcFMYFne Xb8ntBfxJHrqpau+OQ5v37fbg7y/6LwhcdFdK3LWoq+rzBgbgCBx2gNmys5vjw6dxAuL O2qmNY1eZiac9vgeETyEsBDs3F9ikLACgwsahSuWQBxXEJUPkPi2/aY/oyQMJQrW+v9V iqhuWOxfI7v3P0t0/pmaB43nDxa3ZJkQVM8b59GrH9wWdKXdQ3KZE1ncsFfCUic+LNug D3oQ9qf1/dtrpduoRg3dgf0ZjGkwXdlXGD7W5tDKtD+1Rx0YCN/8OxIhaD3SvWoVb7l4 QZWA== X-Gm-Message-State: APjAAAXKTj1oHi2ROSzhsdSRBHem2865h1qdfNvKdCYN+eb9RcAGb/E/ v4oLHdxnEc599JuwjrS28LjTFw== X-Google-Smtp-Source: APXvYqz9P2SbyEoPZH2XLp91KQS3Ycm8nd/bZDqIE+qf4vdPYVcoXsHvtP2LI8kDAgoXTgUhxTIKXA== X-Received: by 2002:a05:600c:2294:: with SMTP id 20mr5200247wmf.56.1553519340747; Mon, 25 Mar 2019 06:09:00 -0700 (PDT) Received: from ?IPv6:2001:67c:1232:144:945e:2fb5:247c:75e? ([2001:67c:1232:144:945e:2fb5:247c:75e]) by smtp.gmail.com with ESMTPSA id y5sm14674568wrw.23.2019.03.25.06.08.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Mar 2019 06:08:59 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Leif Johansson X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Mon, 25 Mar 2019 14:08:59 +0100 Cc: Benjamin Kaduk , Tim Wicinski , ben@nostrum.com, adam@nostrum.com, secdir@ietf.org, dmarc@ietf.org, Murray Kucherawy , Barry Leiba , Kurt Andersen Content-Transfer-Encoding: quoted-printable Message-Id: References: <155350506670.22297.2525928721965597003@ietfa.amsl.com> <20190325105902.GC77890@kduck.mit.edu> To: John R Levine Archived-At: Subject: Re: [secdir] [taugh.com-standards] Secdir last call review of draft-ietf-dmarc-eaiauth-03 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 Mar 2019 13:09:05 -0000 Skickat fr=C3=A5n min iPhone > 25 mars 2019 kl. 12:03 skrev John R Levine : >=20 > On Mon, 25 Mar 2019, Benjamin Kaduk wrote: >>> Maybe I should just take that out. The only issue it mitigates is that >>> it makes DKIM and DMARC checks on EAI mail more reliable. >>=20 >> That seems important enough to state explicitly. >=20 > OK, added a sentence. Thx! >=20 > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Mar 25 18:32: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 234AA12019F; Mon, 25 Mar 2019 18:32:50 -0700 (PDT) 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, 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 (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 q7ElKtvdKsHt; Mon, 25 Mar 2019 18:32:48 -0700 (PDT) Received: from mail-yw1-xc31.google.com (mail-yw1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (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 27BA8120193; Mon, 25 Mar 2019 18:32:48 -0700 (PDT) Received: by mail-yw1-xc31.google.com with SMTP id z9so5019621ywd.6; Mon, 25 Mar 2019 18:32:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=gCx5+1cUo0j1TmAOqIJrVI6zsFf9SMD0rk6YTl6bCi0=; b=qnaAnr+CXExtegDVvom+CElwXvWY7h8imDHhtLwL3fseIuIJBpAazl1QZDRSjoa4o0 I2BIJ7X4wXNW5SgNnA0aFJkNAEJARIh6QFsfFVESEZEbfaBEKj6NCi6XTjWApWFSuDax cE7b0WICMkQpsE0t10LdVlfltUzU6sJ71iNT13xBH5aNWPxoY27s7P1ckk0w3/2slLmu VJJ8FtubaqjRn2VD6ynzkELKN+RZlf39ZrfJHtKgzso+ccorRo3gMDQGsAygPsrm/3Cw JtSIIuTInYNeQXaFKzY2VyFs/L25Xh+fZoDOB2M/G2z+9wOlwQjq1uzCHkBWfiBQv1Qz D6Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=gCx5+1cUo0j1TmAOqIJrVI6zsFf9SMD0rk6YTl6bCi0=; b=m4zpa742RO+TDFXzP2cS2TpGADqSr7MAcE8sOLRfkSEceqQcLfAD7Ub/AVFMaw/KJo VQ+Em3SNlbpwexXDK/7vDmgbNOgMq0N/rzL8W7tyPOuXOrV7eS+iNQB8+8iVIsz0ClXb GGTE752cxNL4pzV/cz2UmbxNEMUVL0VxbHCk01GOqdDWO6UXqnC186LYnkNNuN9nhDuD nCxmEBkQTERPwecD//dsLHB54Ke8bJSZelw1P6Am9U00tPMciMoCORkLZVwgffFl7FHw eF3w8+TlPdHsqzieKq/WuGeluOyLnB4W2IfA/Vj+lq3L6J1vR7mJ/C8oiaY1QrFNvpKr JvRg== X-Gm-Message-State: APjAAAUdQCcfATixxlI08IG3fdf41C8xev1NtwPKzojzpFqbUQ2ZJxeU ro5ilAiT4PG9T1pNQb0wYwLTb9XI X-Google-Smtp-Source: APXvYqz7GWreWaqUrV9l54MpJ5ahzKRd4aGsLuT1Lmj9IpVFOILY/4EVYS8SQQgJhme3xSP8Uwki8A== X-Received: by 2002:a81:2257:: with SMTP id i84mr24293541ywi.394.1553563967045; Mon, 25 Mar 2019 18:32:47 -0700 (PDT) Received: from Chriss-Air.attlocal.net ([2600:1700:12b0:adf0:993a:88b0:80cf:2de1]) by smtp.googlemail.com with ESMTPSA id 142sm6013712ywl.31.2019.03.25.18.32.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Mar 2019 18:32:46 -0700 (PDT) To: draft-ietf-netconf-subscribed-notifications.all@ietf.org, "secdir@ietf.org" , "iesg@ietf.org" From: Chris Lonvick Message-ID: <5C99813D.9070401@gmail.com> Date: Mon, 25 Mar 2019 20:32:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------060709000504010808020407" Archived-At: Subject: [secdir] SECDIR Review of draft-ietf-netconf-subscribed-notifications 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 Mar 2019 01:32:50 -0000 This is a multi-part message in MIME format. --------------060709000504010808020407 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello, 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 Ready With Nits. This is not an area that I'm very familiar with so I skimmed the draft and reviewed the Security Considerations section. Overall, the document appears to be well constructed and well written. RFC 3552 (BCP 72) is very thorough, but kind'a long. So my succinct thought about a Security Considerations section is that it should describe threats to the protocol and/or the implementation, and either ways to thwart them, or state that some threats are beyond the scope of the threat model. While the authors of the ID have been thorough in the rest of the specification, they may have gone a bit outside what is needed for a Security Considerations section. Below are some comments that the authors may wish to consider. And it's OK with me if they disregard my comments as I think the document is Ready anyway. 5.4. Security Considerations CML>>> I'm not sure that the following paragraph is describing a threat or mitigation. While it is good information, perhaps it belongs elsewhere? Or, if there's a threat there, could it be specifically described? One subscription "id" can be used for two or more receivers of the same configured subscription. But due to the possibility of different access control permissions per receiver, it cannot be assumed that each receiver is getting identical updates. CML>>> In the following paragraph, I think you're describing a threat and a remedy tactic. Perhaps you could delineate them by adding, "To counter this," as the start to the second sentence. With configured subscriptions, one or more publishers could be used to overwhelm a receiver. Notification messages SHOULD NOT be sent to any receiver which does not support this specification. Receivers that do not want notification messages need only terminate or refuse any transport sessions from the publisher. CML>>> Again, I'm not sure that the following paragraph is describing a threat or a remedy. When a receiver of a configured subscription gets a new "subscription-started" message for a known subscription where it is already consuming events, the receiver SHOULD retrieve any event records generated since the last event record was received. This can be accomplish by establishing a separate dynamic replay subscription with the same filtering criteria with the publisher, assuming the publisher supports the "replay" feature. The rest of the security considerations section is appropriately describing protections for data nodes that may be susceptible to misuse. Best regards, Chris --------------060709000504010808020407 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hello,

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 Ready With Nits.

This is not an area that I'm very familiar with so I skimmed the draft and reviewed the Security Considerations section. Overall, the document appears to be well constructed and well written.

RFC 3552 (BCP 72) is very thorough, but kind'a long. So my succinct thought about a Security Considerations section is that it should describe threats to the protocol and/or the implementation, and either ways to thwart them, or state that some threats are beyond the scope of the threat model. While the authors of the ID have been thorough in the rest of the specification, they may have gone a bit outside what is needed for a Security Considerations section. Below are some comments that the authors may wish to consider. And it's OK with me if they disregard my comments as I think the document is Ready anyway.

5.4.  Security Considerations
CML>>> I'm not sure that the following paragraph is describing a threat or mitigation. While it is good information, perhaps it belongs elsewhere? Or, if there's a threat there, could it be specifically described? 
   One subscription "id" can be used for two or more receivers of the
   same configured subscription.  But due to the possibility of
   different access control permissions per receiver, it cannot be
   assumed that each receiver is getting identical updates.
CML>>> In the following paragraph, I think you're describing a threat and a remedy tactic. Perhaps you could delineate them by adding, "To counter this," as the start to the second sentence. 
   With configured subscriptions, one or more publishers could be used
   to overwhelm a receiver.  Notification messages SHOULD NOT be sent to
   any receiver which does not support this specification.  Receivers
   that do not want notification messages need only terminate or refuse
   any transport sessions from the publisher.
CML>>> Again, I'm not sure that the following paragraph is describing a threat or a remedy. 
   When a receiver of a configured subscription gets a new
   "subscription-started" message for a known subscription where it is
   already consuming events, the receiver SHOULD retrieve any event
   records generated since the last event record was received.  This can
   be accomplish by establishing a separate dynamic replay subscription
   with the same filtering criteria with the publisher, assuming the
   publisher supports the "replay" feature.
The rest of the security considerations section is appropriately describing protections for data nodes that may be susceptible to misuse. Best regards, Chris --------------060709000504010808020407-- From nobody Mon Mar 25 23:26:51 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 3E6621202DE; Mon, 25 Mar 2019 23:24:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Watson Ladd via Datatracker To: Cc: ietf@ietf.org, draft-ietf-bess-bgp-vpls-control-flags.all@ietf.org, bess@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Watson Ladd Message-ID: <155358145610.24260.5779080758656360403@ietfa.amsl.com> Date: Mon, 25 Mar 2019 23:24:16 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-bess-bgp-vpls-control-flags-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: Tue, 26 Mar 2019 06:24:23 -0000 Reviewer: Watson Ladd 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. The summary of the review is Ready. This document fixes a corner case where some features were not being negotiated properly. It's quite clear and concise, and fixes what seems to be a real problem. From nobody Tue Mar 26 06:35:40 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 01CD012006A; Tue, 26 Mar 2019 06:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.49 X-Spam-Level: X-Spam-Status: No, score=-14.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 GaJWBeJIa3p7; Tue, 26 Mar 2019 06:35:35 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5D012035F; Tue, 26 Mar 2019 06:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23154; q=dns/txt; s=iport; t=1553607328; x=1554816928; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=avGmFQzK3CPfjNf6dxf69QE0oOow5hoP4NGGc+2OBBk=; b=iHwJO92mSD1MQYjl46obo+bVkm37IKznEEnMcoGLHamSvat6DF9OJ4+c QXup1ZNKj2i228nxkdHrYDOAwbCpqhc8CaR8S4g48qTuX+0XCelfzR57S htsF4oZ6caCm8kM3KNRq1EbzibKgwF7hQnhfO9Vzs1zrOWzwSwMv2FTSN w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAC2KZpc/5ldJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDlgqaIEDJwqEBIgcjTKJOIkMhXeBew0BAYR?= =?us-ascii?q?sAheFCyI0CQ0BAQMBAQkBAwJtKIVKAQEBBCMKSgIQAgEIEQQBAQ4dAgICHxE?= =?us-ascii?q?dCAIEDgUIgk9MgRFMAxWtKYEvH4dpDYIfgS8BhFyGVReBQD+BEYMSPoIahTS?= =?us-ascii?q?CVwOKRYIrhCGTUjYJAocYiGODNiGUApJdi3ICERWBLh84gVZwFYMnkEoBQTG?= =?us-ascii?q?PHYEfAQE?= X-IronPort-AV: E=Sophos;i="5.60,271,1549929600"; d="scan'208,217";a="539584417" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 13:35:26 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x2QDZQ8H025142 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Mar 2019 13:35:26 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 09:35:25 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Tue, 26 Mar 2019 09:35:25 -0400 From: "Eric Voit (evoit)" To: Chris Lonvick CC: "draft-ietf-netconf-subscribed-notifications.all@ietf.org" , "secdir@ietf.org" , "iesg@ietf.org" Thread-Topic: SECDIR Review of draft-ietf-netconf-subscribed-notifications Thread-Index: AQHU43PW5soMZq4crkeR6IEFuDhoW6Yd3mfg Date: Tue, 26 Mar 2019 13:35:25 +0000 Message-ID: <56b8c323f2284ce1bee2d6083898b017@XCH-RTP-013.cisco.com> References: <5C99813D.9070401@gmail.com> In-Reply-To: <5C99813D.9070401@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.163.70] Content-Type: multipart/alternative; boundary="_000_56b8c323f2284ce1bee2d6083898b017XCHRTP013ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.153, xch-rtp-013.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [secdir] SECDIR Review of draft-ietf-netconf-subscribed-notifications 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 Mar 2019 13:35:38 -0000 --_000_56b8c323f2284ce1bee2d6083898b017XCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2hyaXMsDQoNClRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHRoZSByZXZpZXcgYW5kIGNvbW1lbnRz LiAgU29tZSB0aG91Z2h0cyBpbi1saW5lLi4uDQoNCkZyb206IENocmlzIExvbnZpY2sgPGxvbnZp Y2suaWV0ZkBnbWFpbC5jb20+DQpTZW50OiBNb25kYXksIE1hcmNoIDI1LCAyMDE5IDk6MzMgUE0N ClRvOiBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zLmFsbEBpZXRm Lm9yZzsgc2VjZGlyQGlldGYub3JnOyBpZXNnQGlldGYub3JnDQpTdWJqZWN0OiBTRUNESVIgUmV2 aWV3IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMNCg0KSGVs bG8sDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3Vy aXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3Vt ZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3Jp dHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVj dG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBj b21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCg0KVGhlIHN1 bW1hcnkgb2YgdGhlIHJldmlldyBpcyBSZWFkeSBXaXRoIE5pdHMuDQoNClRoaXMgaXMgbm90IGFu IGFyZWEgdGhhdCBJJ20gdmVyeSBmYW1pbGlhciB3aXRoIHNvIEkgc2tpbW1lZCB0aGUgZHJhZnQg YW5kIHJldmlld2VkIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLiBPdmVyYWxs LCB0aGUgZG9jdW1lbnQgYXBwZWFycyB0byBiZSB3ZWxsIGNvbnN0cnVjdGVkIGFuZCB3ZWxsIHdy aXR0ZW4uDQoNClJGQyAzNTUyIChCQ1AgNzIpIGlzIHZlcnkgdGhvcm91Z2gsIGJ1dCBraW5kJ2Eg bG9uZy4gU28gbXkgc3VjY2luY3QgdGhvdWdodCBhYm91dCBhIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zIHNlY3Rpb24gaXMgdGhhdCBpdCBzaG91bGQgZGVzY3JpYmUgdGhyZWF0cyB0byB0aGUgcHJv dG9jb2wgYW5kL29yIHRoZSBpbXBsZW1lbnRhdGlvbiwgYW5kIGVpdGhlciB3YXlzIHRvIHRod2Fy dCB0aGVtLCBvciBzdGF0ZSB0aGF0IHNvbWUgdGhyZWF0cyBhcmUgYmV5b25kIHRoZSBzY29wZSBv ZiB0aGUgdGhyZWF0IG1vZGVsLiBXaGlsZSB0aGUgYXV0aG9ycyBvZiB0aGUgSUQgaGF2ZSBiZWVu IHRob3JvdWdoIGluIHRoZSByZXN0IG9mIHRoZSBzcGVjaWZpY2F0aW9uLCB0aGV5IG1heSBoYXZl IGdvbmUgYSBiaXQgb3V0c2lkZSB3aGF0IGlzIG5lZWRlZCBmb3IgYSBTZWN1cml0eSBDb25zaWRl cmF0aW9ucyBzZWN0aW9uLiBCZWxvdyBhcmUgc29tZSBjb21tZW50cyB0aGF0IHRoZSBhdXRob3Jz IG1heSB3aXNoIHRvIGNvbnNpZGVyLiBBbmQgaXQncyBPSyB3aXRoIG1lIGlmIHRoZXkgZGlzcmVn YXJkIG15IGNvbW1lbnRzIGFzIEkgdGhpbmsgdGhlIGRvY3VtZW50IGlzIFJlYWR5IGFueXdheS4N Cg0KDQoNCjUuNC4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQpDTUw+Pj4gSSdtIG5vdCBzdXJl IHRoYXQgdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGggaXMgZGVzY3JpYmluZyBhIHRocmVhdCBvciBt aXRpZ2F0aW9uLiBXaGlsZSBpdCBpcyBnb29kIGluZm9ybWF0aW9uLCBwZXJoYXBzIGl0IGJlbG9u Z3MgZWxzZXdoZXJlPyBPciwgaWYgdGhlcmUncyBhIHRocmVhdCB0aGVyZSwgY291bGQgaXQgYmUg c3BlY2lmaWNhbGx5IGRlc2NyaWJlZD8NCg0KICAgT25lIHN1YnNjcmlwdGlvbiAiaWQiIGNhbiBi ZSB1c2VkIGZvciB0d28gb3IgbW9yZSByZWNlaXZlcnMgb2YgdGhlDQoNCiAgIHNhbWUgY29uZmln dXJlZCBzdWJzY3JpcHRpb24uICBCdXQgZHVlIHRvIHRoZSBwb3NzaWJpbGl0eSBvZg0KDQogICBk aWZmZXJlbnQgYWNjZXNzIGNvbnRyb2wgcGVybWlzc2lvbnMgcGVyIHJlY2VpdmVyLCBpdCBjYW5u b3QgYmUNCg0KICAgYXNzdW1lZCB0aGF0IGVhY2ggcmVjZWl2ZXIgaXMgZ2V0dGluZyBpZGVudGlj YWwgdXBkYXRlcy4NCjxlcmljPiBJdCBpcyBuZWl0aGVyIGEgdGhyZWF0LCBub3IgYSBtaXRpZ2F0 aW9uLiAgSXQgaXMgYWN0dWFsbHkgaW1wbGVtZW50YXRpb24gZ3VpZGFuY2UgdGhhdCBkaWZmZXJl bnQgYWNjZXNzIGNvbnRyb2wgcGVybWlzc2lvbnMgZm9yIGRpZmZlcmVudCBjb25maWd1cmVkIHJl Y2VpdmVycyB3aWxsIHJlc3VsdCBpbiBhIGRpZmZlcmVudCBleHBlcmllbmNlIGZvciBlYWNoIHJl Y2VpdmVyLiAgSWYgeW91IHRoaW5rIHRoYXQgdGhpcyBndWlkYW5jZSBpcyBwcmVmZXJhYmxlIHdp dGhpbiBTZWN0aW9uIDUuMiDigJxJbXBsZW1lbnRhdGlvbiBDb25zaWRlcmF0aW9uc+KAnSwgd2Ug Y2FuIG1vdmUgaXQgdGhlcmUuDQoNCg0KQ01MPj4+IEluIHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBo LCBJIHRoaW5rIHlvdSdyZSBkZXNjcmliaW5nIGEgdGhyZWF0IGFuZCBhIHJlbWVkeSB0YWN0aWMu IFBlcmhhcHMgeW91IGNvdWxkIGRlbGluZWF0ZSB0aGVtIGJ5IGFkZGluZywgIlRvIGNvdW50ZXIg dGhpcywiIGFzIHRoZSBzdGFydCB0byB0aGUgc2Vjb25kIHNlbnRlbmNlLg0KDQogICBXaXRoIGNv bmZpZ3VyZWQgc3Vic2NyaXB0aW9ucywgb25lIG9yIG1vcmUgcHVibGlzaGVycyBjb3VsZCBiZSB1 c2VkDQoNCiAgIHRvIG92ZXJ3aGVsbSBhIHJlY2VpdmVyLiAgTm90aWZpY2F0aW9uIG1lc3NhZ2Vz IFNIT1VMRCBOT1QgYmUgc2VudCB0bw0KDQogICBhbnkgcmVjZWl2ZXIgd2hpY2ggZG9lcyBub3Qg c3VwcG9ydCB0aGlzIHNwZWNpZmljYXRpb24uICBSZWNlaXZlcnMNCg0KICAgdGhhdCBkbyBub3Qg d2FudCBub3RpZmljYXRpb24gbWVzc2FnZXMgbmVlZCBvbmx5IHRlcm1pbmF0ZSBvciByZWZ1c2UN Cg0KICAgYW55IHRyYW5zcG9ydCBzZXNzaW9ucyBmcm9tIHRoZSBwdWJsaXNoZXIuDQo8ZXJpYz4g VGhpcyBpcyBhIGdvb2Qgc3VnZ2VzdGlvbi4gIFRoZSBwcm9wb3NlZCB0ZXh0IGhhcyBiZWVuIGFk ZGVkLg0KDQoNCkNNTD4+PiBBZ2FpbiwgSSdtIG5vdCBzdXJlIHRoYXQgdGhlIGZvbGxvd2luZyBw YXJhZ3JhcGggaXMgZGVzY3JpYmluZyBhIHRocmVhdCBvciBhIHJlbWVkeS4NCg0KICAgV2hlbiBh IHJlY2VpdmVyIG9mIGEgY29uZmlndXJlZCBzdWJzY3JpcHRpb24gZ2V0cyBhIG5ldw0KDQogICAi c3Vic2NyaXB0aW9uLXN0YXJ0ZWQiIG1lc3NhZ2UgZm9yIGEga25vd24gc3Vic2NyaXB0aW9uIHdo ZXJlIGl0IGlzDQoNCiAgIGFscmVhZHkgY29uc3VtaW5nIGV2ZW50cywgdGhlIHJlY2VpdmVyIFNI T1VMRCByZXRyaWV2ZSBhbnkgZXZlbnQNCg0KICAgcmVjb3JkcyBnZW5lcmF0ZWQgc2luY2UgdGhl IGxhc3QgZXZlbnQgcmVjb3JkIHdhcyByZWNlaXZlZC4gIFRoaXMgY2FuDQoNCiAgIGJlIGFjY29t cGxpc2ggYnkgZXN0YWJsaXNoaW5nIGEgc2VwYXJhdGUgZHluYW1pYyByZXBsYXkgc3Vic2NyaXB0 aW9uDQoNCiAgIHdpdGggdGhlIHNhbWUgZmlsdGVyaW5nIGNyaXRlcmlhIHdpdGggdGhlIHB1Ymxp c2hlciwgYXNzdW1pbmcgdGhlDQoNCiAgIHB1Ymxpc2hlciBzdXBwb3J0cyB0aGUgInJlcGxheSIg ZmVhdHVyZS4NCjxlcmljPiBIb3cgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0IHRvIGFkZHJlc3Mg eW91ciB0aHJlYXQvcmVtZWR5IGNvbW1lbnQuLi4NCg0KV2hlbiBhIHJlY2VpdmVyIG9mIGEgY29u ZmlndXJlZCBzdWJzY3JpcHRpb24gZ2V0cyBhIG5ldyAic3Vic2NyaXB0aW9uLXN0YXJ0ZWQiIG1l c3NhZ2UgZm9yIGEga25vd24gc3Vic2NyaXB0aW9uIHdoZXJlIGl0IGlzIGFscmVhZHkgY29uc3Vt aW5nIGV2ZW50cywgaXQgbWF5IGluZGljYXRlIHRoYXQgYW4gYXR0YWNrZXIgaGFzIGRpc3J1cHRl ZCByZWNlaXZlciBjb25uZWN0aXZpdHkuIFRvIGFjcXVpcmUgZXZlbnRzIGxvc3QgZHVyaW5nIHRo aXMgaW50ZXJ2YWwsIHRoZSByZWNlaXZlciBTSE9VTEQgcmV0cmlldmUgYW55IGV2ZW50IHJlY29y ZHMgZ2VuZXJhdGVkIHNpbmNlIHRoZSBsYXN0IGV2ZW50IHJlY29yZCB3YXMgcmVjZWl2ZWQuICBU aGlzIGNhbiBiZSBhY2NvbXBsaXNoZWQgYnkgZXN0YWJsaXNoaW5nIGEgc2VwYXJhdGUgZHluYW1p YyByZXBsYXkgc3Vic2NyaXB0aW9uIHdpdGggdGhlIHNhbWUgZmlsdGVyaW5nIGNyaXRlcmlhIHdp dGggdGhlIHB1Ymxpc2hlciwgYXNzdW1pbmcgdGhlIHB1Ymxpc2hlciBzdXBwb3J0cyB0aGUgInJl cGxheSIgZmVhdHVyZS4NCg0KRXJpYw0KDQoNClRoZSByZXN0IG9mIHRoZSBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyBzZWN0aW9uIGlzIGFwcHJvcHJpYXRlbHkgZGVzY3JpYmluZyBwcm90ZWN0aW9u cyBmb3IgZGF0YSBub2RlcyB0aGF0IG1heSBiZSBzdXNjZXB0aWJsZSB0byBtaXN1c2UuIEJlc3Qg cmVnYXJkcywgQ2hyaXMNCg== --_000_56b8c323f2284ce1bee2d6083898b017XCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJY29sb3I6YmxhY2s7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9y bWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLm1oDQoJe21zby1zdHlsZS1u YW1lOm1faDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4t VVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dCI+SGkgQ2hyaXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5U aGFua3MgdmVyeSBtdWNoIGZvciB0aGUgcmV2aWV3IGFuZCBjb21tZW50cy4mbmJzcDsgU29tZSB0 aG91Z2h0cyBpbi1saW5lLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndp bmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+ IENocmlzIExvbnZpY2sgJmx0O2xvbnZpY2suaWV0ZkBnbWFpbC5jb20mZ3Q7DQo8YnI+DQo8Yj5T ZW50OjwvYj4gTW9uZGF5LCBNYXJjaCAyNSwgMjAxOSA5OjMzIFBNPGJyPg0KPGI+VG86PC9iPiBk cmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zLmFsbEBpZXRmLm9yZzsg c2VjZGlyQGlldGYub3JnOyBpZXNnQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFNFQ0RJ UiBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9uczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvLDxicj4N Cjxicj4NCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3Vy aXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3Vt ZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3Jp dHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVj dG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzDQogc2hvdWxkIHRyZWF0IHRoZXNl IGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLiA8YnI+DQo8 YnI+DQpUaGUgc3VtbWFyeSBvZiB0aGUgcmV2aWV3IGlzIFJlYWR5IFdpdGggTml0cy48YnI+DQo8 YnI+DQpUaGlzIGlzIG5vdCBhbiBhcmVhIHRoYXQgSSdtIHZlcnkgZmFtaWxpYXIgd2l0aCBzbyBJ IHNraW1tZWQgdGhlIGRyYWZ0IGFuZCByZXZpZXdlZCB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnMgc2VjdGlvbi4gT3ZlcmFsbCwgdGhlIGRvY3VtZW50IGFwcGVhcnMgdG8gYmUgd2VsbCBjb25z dHJ1Y3RlZCBhbmQgd2VsbCB3cml0dGVuLg0KPGJyPg0KPGJyPg0KUkZDIDM1NTIgKEJDUCA3Mikg aXMgdmVyeSB0aG9yb3VnaCwgYnV0IGtpbmQnYSBsb25nLiBTbyBteSBzdWNjaW5jdCB0aG91Z2h0 IGFib3V0IGEgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpcyB0aGF0IGl0IHNob3Vs ZCBkZXNjcmliZSB0aHJlYXRzIHRvIHRoZSBwcm90b2NvbCBhbmQvb3IgdGhlIGltcGxlbWVudGF0 aW9uLCBhbmQgZWl0aGVyIHdheXMgdG8gdGh3YXJ0IHRoZW0sIG9yIHN0YXRlIHRoYXQgc29tZSB0 aHJlYXRzIGFyZQ0KIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhlIHRocmVhdCBtb2RlbC4gV2hpbGUg dGhlIGF1dGhvcnMgb2YgdGhlIElEIGhhdmUgYmVlbiB0aG9yb3VnaCBpbiB0aGUgcmVzdCBvZiB0 aGUgc3BlY2lmaWNhdGlvbiwgdGhleSBtYXkgaGF2ZSBnb25lIGEgYml0IG91dHNpZGUgd2hhdCBp cyBuZWVkZWQgZm9yIGEgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbi4gQmVsb3cgYXJl IHNvbWUgY29tbWVudHMgdGhhdCB0aGUgYXV0aG9ycyBtYXkgd2lzaA0KIHRvIGNvbnNpZGVyLiBB bmQgaXQncyBPSyB3aXRoIG1lIGlmIHRoZXkgZGlzcmVnYXJkIG15IGNvbW1lbnRzIGFzIEkgdGhp bmsgdGhlIGRvY3VtZW50IGlzIFJlYWR5IGFueXdheS48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvcD4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDguMHB0O2JhY2tn cm91bmQ6I0ZGRkRGNSI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91 bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+ PHNwYW4gY2xhc3M9Im1oIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+NS40LiZuYnNw OyBTZWN1cml0eSBDb25zaWRlcmF0aW9uczwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5DTUwmZ3Q7Jmd0OyZndDsgSSdtIG5vdCBzdXJlIHRoYXQgdGhlIGZvbGxvd2lu ZyBwYXJhZ3JhcGggaXMgZGVzY3JpYmluZyBhIHRocmVhdCBvciBtaXRpZ2F0aW9uLiBXaGlsZSBp dCBpcyBnb29kIGluZm9ybWF0aW9uLCBwZXJoYXBzIGl0IGJlbG9uZ3MgZWxzZXdoZXJlPyBPciwg aWYgdGhlcmUncyBhIHRocmVhdCB0aGVyZSwgY291bGQgaXQgYmUgc3BlY2lmaWNhbGx5IGRlc2Ny aWJlZD8NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1lbnQ6cGFyYS1ib3Jk ZXItZGl2O2JvcmRlcjpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6OC4wcHQgOC4wcHQgOC4w cHQgOC4wcHQ7YmFja2dyb3VuZDojRkZGREY1Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206 Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25l O3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7T25lIHN1YnNjcmlwdGlvbiAmcXVvdDtpZCZxdW90OyBjYW4gYmUgdXNlZCBmb3IgdHdv IG9yIG1vcmUgcmVjZWl2ZXJzIG9mIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpi cmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0Ij4mbmJzcDsmbmJzcDsgc2FtZSBjb25maWd1cmVkIHN1YnNjcmlwdGlvbi4mbmJzcDsg QnV0IGR1ZSB0byB0aGUgcG9zc2liaWxpdHkgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJl YWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IGRpZmZlcmVudCBhY2Nlc3MgY29udHJvbCBwZXJtaXNz aW9ucyBwZXIgcmVjZWl2ZXIsIGl0IGNhbm5vdCBiZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1i cmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsgYXNzdW1lZCB0aGF0IGVhY2ggcmVjZWl2ZXIgaXMg Z2V0dGluZyBpZGVudGljYWwgdXBkYXRlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiZs dDtlcmljJmd0OyBJdCBpcyBuZWl0aGVyIGEgdGhyZWF0LCBub3IgYSBtaXRpZ2F0aW9uLiZuYnNw OyBJdCBpcyBhY3R1YWxseSBpbXBsZW1lbnRhdGlvbiBndWlkYW5jZSB0aGF0IGRpZmZlcmVudCBh Y2Nlc3MgY29udHJvbCBwZXJtaXNzaW9ucyBmb3IgZGlmZmVyZW50IGNvbmZpZ3VyZWQgcmVjZWl2 ZXJzIHdpbGwgcmVzdWx0IGluIGEgZGlmZmVyZW50IGV4cGVyaWVuY2UgZm9yDQogZWFjaCByZWNl aXZlci4mbmJzcDsgSWYgeW91IHRoaW5rIHRoYXQgdGhpcyBndWlkYW5jZSBpcyBwcmVmZXJhYmxl IHdpdGhpbiBTZWN0aW9uIDUuMiDigJxJbXBsZW1lbnRhdGlvbiBDb25zaWRlcmF0aW9uc+KAnSwg d2UgY2FuIG1vdmUgaXQgdGhlcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5DTUwmZ3Q7Jmd0OyZndDsgSW4gdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGgsIEkgdGhpbmsgeW91 J3JlIGRlc2NyaWJpbmcgYSB0aHJlYXQgYW5kIGEgcmVtZWR5IHRhY3RpYy4gUGVyaGFwcyB5b3Ug Y291bGQgZGVsaW5lYXRlIHRoZW0gYnkgYWRkaW5nLCAmcXVvdDtUbyBjb3VudGVyIHRoaXMsJnF1 b3Q7IGFzIHRoZSBzdGFydCB0byB0aGUgc2Vjb25kIHNlbnRlbmNlLg0KPG86cD48L286cD48L3A+ DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzo4LjBwdCA4LjBwdCA4LjBwdCA4LjBwdDtiYWNrZ3JvdW5kOiNG RkZERjUiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZE RjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsmbmJzcDtXaXRoIGNvbmZpZ3VyZWQg c3Vic2NyaXB0aW9ucywgb25lIG9yIG1vcmUgcHVibGlzaGVycyBjb3VsZCBiZSB1c2VkPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tn cm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyB0byBvdmVyd2hl bG0gYSByZWNlaXZlci4mbmJzcDsgTm90aWZpY2F0aW9uIG1lc3NhZ2VzIFNIT1VMRCBOT1QgYmUg c2VudCB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRv bTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5v bmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJz cDsgYW55IHJlY2VpdmVyIHdoaWNoIGRvZXMgbm90IHN1cHBvcnQgdGhpcyBzcGVjaWZpY2F0aW9u LiZuYnNwOyBSZWNlaXZlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxs O2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+ Jm5ic3A7Jm5ic3A7IHRoYXQgZG8gbm90IHdhbnQgbm90aWZpY2F0aW9uIG1lc3NhZ2VzIG5lZWQg b25seSB0ZXJtaW5hdGUgb3IgcmVmdXNlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJy ZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQiPiZuYnNwOyZuYnNwOyBhbnkgdHJhbnNwb3J0IHNlc3Npb25zIGZyb20gdGhlIHB1Ymxp c2hlci48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiZsdDtlcmljJmd0OyBUaGlzIGlzIGEg Z29vZCBzdWdnZXN0aW9uLiZuYnNwOyBUaGUgcHJvcG9zZWQgdGV4dCBoYXMgYmVlbiBhZGRlZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNNTCZndDsmZ3Q7Jmd0OyBBZ2Fp biwgSSdtIG5vdCBzdXJlIHRoYXQgdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGggaXMgZGVzY3JpYmlu ZyBhIHRocmVhdCBvciBhIHJlbWVkeS4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0ibXNv LWVsZW1lbnQ6cGFyYS1ib3JkZXItZGl2O2JvcmRlcjpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6OC4wcHQgOC4wcHQgOC4wcHQgOC4wcHQ7YmFja2dyb3VuZDojRkZGREY1Ij4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJl YWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7V2hlbiBhIHJlY2VpdmVyIG9mIGEgY29uZmlndXJlZCBz dWJzY3JpcHRpb24gZ2V0cyBhIG5ldzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVh ay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0Ij4mbmJzcDsmbmJzcDsgJnF1b3Q7c3Vic2NyaXB0aW9uLXN0YXJ0ZWQmcXVvdDsgbWVzc2Fn ZSBmb3IgYSBrbm93biBzdWJzY3JpcHRpb24gd2hlcmUgaXQgaXM8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1 O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IGFscmVhZHkgY29uc3VtaW5nIGV2ZW50 cywgdGhlIHJlY2VpdmVyIFNIT1VMRCByZXRyaWV2ZSBhbnkgZXZlbnQ8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZG REY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGluIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7IHJlY29yZHMgZ2VuZXJhdGVkIHNp bmNlIHRoZSBsYXN0IGV2ZW50IHJlY29yZCB3YXMgcmVjZWl2ZWQuJm5ic3A7IFRoaXMgY2FuPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2Jh Y2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5n OjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyBiZSBhY2Nv bXBsaXNoIGJ5IGVzdGFibGlzaGluZyBhIHNlcGFyYXRlIGR5bmFtaWMgcmVwbGF5IHN1YnNjcmlw dGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3 LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7 cGFkZGluZzowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsg d2l0aCB0aGUgc2FtZSBmaWx0ZXJpbmcgY3JpdGVyaWEgd2l0aCB0aGUgcHVibGlzaGVyLCBhc3N1 bWluZyB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0 b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpu b25lO3BhZGRpbmc6MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5i c3A7IHB1Ymxpc2hlciBzdXBwb3J0cyB0aGUgJnF1b3Q7cmVwbGF5JnF1b3Q7IGZlYXR1cmUuPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4mbHQ7ZXJpYyZndDsgSG93IGFib3V0IHRoZSBmb2xs b3dpbmcgdGV4dCB0byBhZGRyZXNzIHlvdXIgdGhyZWF0L3JlbWVkeSBjb21tZW50Li4uDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPldoZW4gYSByZWNlaXZlciBv ZiBhIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIGdldHMgYSBuZXcgJnF1b3Q7c3Vic2NyaXB0aW9u LXN0YXJ0ZWQmcXVvdDsgbWVzc2FnZSBmb3IgYSBrbm93biBzdWJzY3JpcHRpb24gd2hlcmUgaXQg aXMgYWxyZWFkeSBjb25zdW1pbmcgZXZlbnRzLCBpdCBtYXkgaW5kaWNhdGUgdGhhdCBhbiBhdHRh Y2tlciBoYXMgZGlzcnVwdGVkIHJlY2VpdmVyDQogY29ubmVjdGl2aXR5LiBUbyBhY3F1aXJlIGV2 ZW50cyBsb3N0IGR1cmluZyB0aGlzIGludGVydmFsLCB0aGUgcmVjZWl2ZXIgU0hPVUxEIHJldHJp ZXZlIGFueSBldmVudCByZWNvcmRzIGdlbmVyYXRlZCBzaW5jZSB0aGUgbGFzdCBldmVudCByZWNv cmQgd2FzIHJlY2VpdmVkLiZuYnNwOyBUaGlzIGNhbiBiZSBhY2NvbXBsaXNoZWQgYnkgZXN0YWJs aXNoaW5nIGEgc2VwYXJhdGUgZHluYW1pYyByZXBsYXkgc3Vic2NyaXB0aW9uIHdpdGggdGhlIHNh bWUgZmlsdGVyaW5nDQogY3JpdGVyaWEgd2l0aCB0aGUgcHVibGlzaGVyLCBhc3N1bWluZyB0aGUg cHVibGlzaGVyIHN1cHBvcnRzIHRoZSAmcXVvdDtyZXBsYXkmcXVvdDsgZmVhdHVyZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkVyaWM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSByZXN0IG9mIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyBzZWN0aW9uIGlzIGFwcHJvcHJpYXRlbHkgZGVzY3JpYmluZyBwcm90ZWN0aW9ucyBmb3Ig ZGF0YSBub2RlcyB0aGF0IG1heSBiZSBzdXNjZXB0aWJsZSB0byBtaXN1c2UuIEJlc3QgcmVnYXJk cywgQ2hyaXMNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_56b8c323f2284ce1bee2d6083898b017XCHRTP013ciscocom_-- From nobody Thu Mar 28 01:51:02 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 B2F3B120074 for ; Thu, 28 Mar 2019 01:50:59 -0700 (PDT) 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.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <155376305972.1414.15547340907791214207.idtracker@ietfa.amsl.com> Date: Thu, 28 Mar 2019 01:50:59 -0700 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 Mar 2019 08:51:00 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-04-11 Reviewer LC end Draft Daniel Franke 2019-03-18 draft-ietf-sidrops-https-tal-07 Phillip Hallam-Baker 2019-03-18 draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04 Sandra Murphy R2019-01-31 draft-ietf-ccamp-rsvp-te-bandwidth-availability-14 Vincent Roca R2018-10-29 draft-ietf-pce-gmpls-pcep-extensions-13 Last calls: Reviewer LC end Draft Derek Atkins 2019-03-03 draft-ietf-netmod-module-tags-07 Nancy Cam-Winget 2019-02-15 draft-ietf-rtcweb-security-11 Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-27 Daniel Gillmor 2018-03-19 draft-gutmann-scep-13 Charlie Kaufman 2019-03-14 draft-ietf-trans-rfc6962-bis-31 Aanchal Malhotra 2019-04-12 draft-ietf-netconf-restconf-notif-13 Catherine Meadows 2019-04-12 draft-ietf-mmusic-rfc4566bis-34 Alexey Melnikov 2019-04-11 draft-ietf-sidrops-lta-use-cases-05 Daniel Migault 2019-04-11 draft-ietf-roll-useofrplinfo-25 Matthew Miller 2019-04-08 draft-ietf-core-multipart-ct-03 Russ Mundy 2019-04-22 draft-housley-hkdf-oids-01 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Yoav Nir 2019-04-10 draft-ietf-lamps-pkix-shake-08 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-08 Hilarie Orman 2019-04-10 draft-ietf-acme-caa-06 Radia Perlman 2019-04-08 draft-ietf-oauth-jwt-bcp-04 Derrell Piper 2019-04-05 draft-ietf-manet-dlep-multi-hop-extension-06 Vincent Roca R2019-02-13 draft-ietf-perc-private-media-framework-09 Takeshi Takahashi R2019-04-12 draft-ietf-netconf-yang-push-22 Takeshi Takahashi R2018-08-31 draft-ietf-lisp-rfc6833bis-24 David Waltermire 2019-02-15 draft-ietf-rtcweb-ip-handling-11 Klaas Wierenga 2019-02-26 draft-ietf-mpls-sr-over-ip-03 Taylor Yu 2019-02-15 draft-ietf-rtcweb-security-arch-18 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-11 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Scott Kelly 2019-03-22 draft-ietf-rift-rift-04 Kathleen Moriarty 2019-04-08 draft-ietf-bmwg-ngfw-performance-00 Next in the reviewer rotation: Tim Polk Vincent Roca Kyle Rose Joseph Salowey Rich Salz Stefan Santesson Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore Valery Smyslov From nobody Thu Mar 28 04:33: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 68FBC120424; Thu, 28 Mar 2019 04:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665, 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 rmPzuRlJhZbL; Thu, 28 Mar 2019 04:32:55 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE193120331; Thu, 28 Mar 2019 04:32:51 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 00E9628B0041; Thu, 28 Mar 2019 07:32:50 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id DC8C71F804E; Thu, 28 Mar 2019 07:32:48 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sandra Murphy In-Reply-To: <9C5FD3EFA72E1740A3D41BADDE0B461FCFB598CD@DGGEMM528-MBX.china.huawei.com> Date: Thu, 28 Mar 2019 12:32:47 +0100 Cc: Sandra Murphy , "secdir@ietf.org" , "ccamp@ietf.org" , "draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3DCE5D1E-DBF1-4293-8FA1-FD6E975E24FC@tislabs.com> References: <154908012600.28521.5714645741731093529@ietfa.amsl.com> <9C5FD3EFA72E1740A3D41BADDE0B461FCFB598CD@DGGEMM528-MBX.china.huawei.com> To: "Yemin (Amy)" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-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: Thu, 28 Mar 2019 11:33:10 -0000 I see that a new version was posted on Mar 6. I thank the authors for = their attention to my comments and for the explanations for cases where = I was confused. I have one suggestion. The authors changed the text to say =E2=80=9Cfloat= ing point=E2=80=9D, but I did not make clear that I think a reference to = IEEE 754 is needed. I found one reference to an IESG comment during the review of = draft-ietf-isis-pcr =E2=80=A2 Jari Arkko: Comment [2016-01-07 04:51 PST]:=20 This comment from Suresh Krishnan's Gen-ART review seems relevant: There = is no reference for the format of the Bandwidth fields in Sections 6.3 = and 6.4. I am assuming this refers to the Single Precision format = (binary32) from IEEE 754. If so, please add an explicit reference to = this. So the reference to the IEEE standard has been considered a good idea in = past draft IESG reviews. I found three RFCs that contained a reference to the IEEE 754 standard. = The first is the RFC that resulted from draft-ietf-isis-pcr RFC 7813 IS-IS PCR June 2016 11.2. Informative References [IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE 754-2008, DOI 10.1109/IEEESTD.2008.4610935, 2008, . the second is an OSPF RFC RFC 7471 OSPF TE Metric Extensions March 2015 13.1. Normative References [IEEE754] Institute of Electrical and Electronics Engineers, "Standard for Floating-Point Arithmetic", IEEE Standard 754, August 2008. and the third is a CCAMP RFC: RFC 8330 Availability Extension to OSPF-TE February 2018 7.1. Normative References [IEEE754-2008] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE 754-2008, DOI 10.1109/IEEESTD.2008.4610935. Note that one reference is informative, two are normative. The authors = should decide whether the format is a requirement and therefore the = reference should be normative. In conversation with the RFC-Editor, there are some IEEE requests as to = how the reference should be phrased. The authors may wish to consult = the RFC-Editor to decide how this reference should be phrased. There = are evidently considerations of whether you wish this document to follow = the IEEE standard as it changes, or whether you want to point to the = current version explicitly. Something I did not notice before: Page 6: Optionally, a higher availability bandwidth can be allocated to lower availability request when the lower availability bandwidth cannot satisfy the request. Does this make the order of looking at availability bandwidth requests = important? If a lower availability requirement bandwidth request is = allocated from the higher availability bandwidth before all higher = availability bandwidth requests are satisfied, might that prevent a = higher availability bandwidth request from being satisfied?=20 Appendix Page 9 and 10=20 I am afraid that even after review of the authors' comments and another = time over the Appendix, I still do not understand the table in the = Appendix. To my reading of page 9 and 10: 400Mbps (level 3 modulation) is available except for the 52 minutes a = year when the modulation drops to level 2 =3D=3D> (525600-52)/525600 =3D = 99.99% of the time 400Mbps is available 200Mbps (level 2 modulation) is available except for the 26 minutes a = year when the modulation drops to level 1 =3D=3D> (525600-26)/525600 =3D = 99.995% of the time 200Mbps is available 100Mbps (level 1 modulation) is available except for the 5 minutes a = year when the whole system is unavailable =3D=3D> (525600-5)/252600 =3D = 99.999% of the time 100Mbps is available. (There=E2=80=99s another interpretation of your example text - that the = 400Mbgp is not available in the light rain that drops the modulation to = level2 -or- the 26 minutes of heavy rain that drops the modulation to = level 1 -or- when the whole system is unavailable, so 400Mbps is = unavailable 52+26+5 minutes each year, which is more like 99.98%.) That would make the table say: Sub-bandwidth (Mbps) Availability ------------------ ------------ 400 99.99% 200 99.995% 100 99.999% Even if I am still am interpreting this incorrectly, I would like to = point out that the text has two statements on page 10 that seem to = conflict: Then the dropped 100 Mbps bandwidth has 99.995% availability. and So the 100 Mbps bandwidth of the modulation level 1 owns the availability of 99.999%. You might want to do the readers a favor and clear up the conflict. Some nits are below. =E2=80=94Sandy In light of the RFC-Editor request during the IETF104 plenary on = Wednesday, here are some nits the RFC-Editor would probably catch, but = to make their task easier, I note them here. Page 3: When a video application requests for 120 Mbps without bandwidth availability requirement requests for 120 Mbps =E2=80=94> =E2=80=9Cmakes a request for 120Mbps=E2=80= =9D or =E2=80=9Crequests 120Mbps=E2=80=9D without bandwidth =E2=80=94> without a bandwidth Page 5: Availability (4 octets): a 32-bit floating point number describes This would be a good place to put a cite to the IEEE 754 reference. the decimal value of availability requirement for this bandwidth request. The value MUST be less than 1and is usually expressed in of availability requirement =E2=80=94> =E2=80=9Cof the availability = requirement=E2=80=9D 1and =E2=80=94> =E2=80=9C1 and=E2=80=9D Page 6: allocated to lower availability request when the lower to lower availability request =E2=80=94> to a lower availability request When a node receives Availability TLVs which mixed of zero index and =E2=80=9Cwhich mixed of=E2=80=9D =E2=80=94> =E2=80=9Cwhich are a mix of" several pairs, but there're are extra =E2=80=9Cthere=E2=80=99re are=E2=80=9D =E2=80=94> =E2=80=9Cthere are=E2=80= =9D bandwidth-TLVs without matching index Availability-TLV, the extra could be =E2=80=9Cwithout matching the index of any Availability-TLV=E2=80= =9D or =E2=80=9Cwithout any Availability-TLV with a matching index=E2=80=9D= Page 7: RSVP-TE signaling used in GMPLS network. in GMPLS network =E2=80=94> =E2=80=9Cin a GMPLS network=E2=80=9D or = =E2=80=9Cin GMPLS networks" > On Feb 22, 2019, at 4:58 AM, Yemin (Amy) wrote: >=20 > Hi Sandra, > =20 > Many thanks for the detail review comments, please see reply inline = below. > And I=E2=80=99m very sorry for the late reply. > =20 > BR, > Amy > -----Original Message----- > From: Sandra Murphy [mailto:sandy@tislabs.com]=20 > Sent: Saturday, February 02, 2019 12:02 PM > To: secdir@ietf.org > Cc: ccamp@ietf.org; ietf@ietf.org; = draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org > Subject: Secdir last call review of = draft-ietf-ccamp-rsvp-te-bandwidth-availability-13 > =20 > Reviewer: Sandra Murphy > Review result: Has Issues > =20 > I have reviewed this document = draft-ietf-ccamp-rsvp-te-bandwidth-availability > as part of the security directorate=E2=80=99s 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. > =20 > This draft provides a new TLV for the Ethernet SENDER_TSPEC object = that will carry availability requirements for RSVP-TE signaling of GMPLS = LSPs. > =20 > The draft is thorough. I do have some comments. I reviewed the = normative references RFCs 2205, 3209, 3473, 6003, as well as RFC3945 and = RFC5920. I can=E2=80=99t claim that I understood everything in that = stack, so the following could easily be wrong. > =20 > Computing the LSP path: > =20 > Page 4, section 2 discusses obtaining network topology, calculating = the LSP route, RFC8330=E2=80=99s extensions for availability in OSPF TE = LSA messages. Does this draft assume that this extension will always be = used with an EXPLICIT_ROUTE object? Is this draft not applicable = without that explicit LSP route calculation? > [Amy] No, there's no assumption that the extension can be only used = with an EXPLICIT_ROUTE object. The node who obtains network topology, = calculates the LSP route, could be a source node and intermediate nodes.=20= > Availability TLV vs CLASSTYPE objects: > =20 > The definition in RFC6003 of the Bandwidth Profile TLV has certain = constraints on the values of the Index: > The Index field value MUST correspond to at = least one > of the Class-Type values included either in the CLASSTYPE object > [RFC4124] or in the EXTENDED_CLASSTYPE object [MCOS]. > =20 > I am not certain if this means that the presence of an Ethernet = SENDER_TSPEC Object with a Bandwidth Profile TLV means there must be a = CLASSTYPE object in the RSVP-TE message as well, or that the Index field = values are taken from the set of defined Class-Type values. > =20 > But if the first, does this induce requirements by inclusion of the = Availability TLV that these other CLASSTYPE objects must be included as = well? > Or are you intending to update RFC6003 to eliminate that constraint? = If the second, does the RFC6003 constraint also constrain the index = values used in the Availability TLV? Should that be mentioned? (Or am = I just confused?) > [Amy] It=E2=80=99s the second case. The RFC6003 constraint should also = apply to the index values used in the Availability TLV. The current text = states that =E2=80=9Chaving the same value of Index field=E2=80=9D, = which implies the same constraint.=20 > =20 > Bandwidth TLV to Availability TLV association: > =20 > Page 4, Section 3.1 says > =20 > When the Availability TLV is included, it MUST be present along > with the Ethernet Bandwidth Profile TLV. If the bandwidth > requirements in the multiple Ethernet Bandwidth Profile TLVs = have > different Availability requirements, multiple Availability TLVs > SHOULD be carried. In such a case, the Availability TLV has a = one > to one correspondence with the Ethernet Bandwidth Profile TLV by > having the same value of Index field. If all the bandwidth > requirements in the Ethernet Bandwidth Profile have the same > Availability requirement, one Availability TLV SHOULD be = carried. > In this case, the Index field is set to 0. > =20 > I find that the description is not clear in all cases. I found a = message in the working group discussion of this association that the = association is either =E2=80=9Cn:n=E2=80=9D or =E2=80=9Cn:1=E2=80=9D. I = think this description sounds more like n 1:1 associations > or a n:1 association. Is that what is intended? Can the = associations be > mixed in the same message? Suppose there were 3 Bandwidth TLVs that = needed the same availability and one that had a different availability = need, could there be 3 Bandwidth TLVs with index 0 and one = Availability-TLV with index 0 and also a Bandwidth TLVs - Availability = TLV pair with matching index values? > [Amy] Thanks for looking into the past discussion. The intension was = n*(1:1) association or n:1 association. It was not so accurate by using = =E2=80=9Cn:n=E2=80=9D association in the past. > Regarding the example you list, if the four Bandwidth TLVs are sent in = the same message, it=E2=80=99s better to use four different index values = as they are =E2=80=9Cmultiple Ethernet Bandwidth Profile TLVs have = different Availability requirements=E2=80=9D. > Of course what you proposed could also work technically. > =20 > error checking: > =20 > Other documents in the references (RFC2205, 3209, 3473, 6003, etc) = have made a point of explicitly describing the error handling - when = PathErr and ResvErr and Notify messages are sent, to whom, the error = codes, the error value sub-codes, etc. I don=E2=80=99t see that here = for the bandwidth-tlv-to-availability-tlv associations. > [Amy] Thanks for the comment, I agree the error process should be = clearer. > Is a mix of index-zero and index-non-zero = bandwidth-tlv-to-availability-tlv associations (like above) an error? is = the message dropped? is an error sent? > if the message is not dropped, are any of the bandwidth-tlv, = availability-tlv associations retained? > [Amy] The message MAY be ignored and SHOULD NOT be propagated. > If there are availability-tlvs with non-zero indexes with no matching = index value among the bandwidth-tlvs, that surely is an error? Is the = message dropped? Or is the availability tlv dropped? Is a = PathErr/ResvErr message sent? > [Amy] yes, this is an error. It=E2=80=99s preferred to drop the = availability tlv. =20 > Suppose all availability-tlvs have a matching (zero or non-zero) index = value among the bandwidth-tlvs, but there are extra bandwidth-tlvs (no = availability-tlv with a matching index value). Is that an error? Are = the extra bandwidth-tlvs dropped? ignored? propagated? > [Amy]The extra bandwidth-tlvs MAY be ignored and SHOULD NOT be = propagated. > (RFC3209 has several cases where there might be extra objects or = sub-objects and the language is =E2=80=9Ccan be/MAY be/SHOULD be/are = ignored and SHOULD NOT be /are not/need not be propagated=E2=80=9D ) > =20 > =20 > multiplicity: > =20 > RFC3209 says it does not apply to multicast, but it does talk about = multiple parallel LSP tunnels between two nodes, and about = multipoint-to-point LSPs for WF and SE style reservations when there are = multiple senders, and about the merging rules of WF reservations. Does = availability work in those style reservations? > [Amy] Considering that the traffic from senders is more likely to be = concurrent and independent, the availability TLV can be limited to Fixed = Filter (FF) Style only. > availability vs =E2=80=9Cvariable discrete bandwidth=E2=80=9D: > =20 > I believe I understood the discussion of the need to signal = availability requirements in order for the system to determine when an = LSP was feasible. I can dimly understand that there might be links have = =E2=80=9Cvariable discrete bandwidth=E2=80=9D. Section 2 says =E2=80=9CTh= e Availability TLV can be applicable to any kind of physical links with = variable discrete bandwidth, such as microwave or DSL.=E2=80=9D > Why not other link types? Do only =E2=80=9Cvariable discrete = bandwidth=E2=80=9D links support availability? > [Amy] To our current knowledge, only=E2=80=9Cvariable discrete = bandwidth=E2=80=9D links support availability. > =20 > calculating availability: > =20 > In page 9, Appendix A: > =20 > Perhaps I don=E2=80=99t understand how the availability metric is = used. In the > following: > =20 > On a sunny day, the modulation level 3 can be used to achieve 400 > Mbps link bandwidth. > =20 > A light rain with X mm/h rate triggers the system to change the > modulation level from level 3 to level 2, with bandwidth changing > from 400 Mbps to 200 Mbps. The probability of X mm/h rain in the > local area is 52 minutes in a year. Then the dropped 200 Mbps > bandwidth has 99.99% availability. > =20 > I would say that the 400Mbps bandwidth is available whenever it is not = raining. > It lightly rains 52 min year, which means it is not raining 99.99% of = the time, so the 400Mbps availability is 99.99%. The 200Mbps is = available during that 52 min, so 99.99% is not the 200Mbps availability. = Right? > =20 > The analogous comment applies to the next two paragraphs. > =20 > Does that explain why the table shows the 100Mbps bandwidth having two = different availabilities? > [Amy]Your understanding is also correct. That is just a different way = to present the result. Take the values from the table, 100Mbps with = 99.995% and 100Mbps with 99.999% can be also considered as bandwidth = with 99.99% availability.=20 > Thus it will result the total bw with 99.99% availability =3D = 200+100+100=3D400Mbps > =20 > =20 > security: > =20 > The draft (*) security consideration points to RSVP-TE, but without an = RFC reference, and to RFC5920. Because this is a GMPLS related feature, = it should refer to the GMPLS extensions to RSVP-TE in RFC3473. As an = extension to RFC6003, it could refer to that RFC=E2=80=99s security = considerations section, but that only gets the reader to RFC3473, = RFC3209, and RFC5920. > =20 > The security considerations for RSVP-TE itself (RFC3209) points to = RFC2205. > RFC2205 defines an Integrity object (defined in RFC2747) that carries = a keyed cryptographic digest based on a shared key, providing hop-by-hop = protection between two RSVP nodes. However, PATH messages are directed = toward the traffic destination address, not the next RSVP node. There = could be clouds of non-RSVP nodes between two RSVP nodes that the PATH = encounters. This makes it difficult to share a key between individual = pairs of RSVP nodes, and could motivate operators to configure the same = key in large numbers of RSVP nodes. > =20 > RFC3473 points to RFC2747=E2=80=99s protection of RSVP messages. It = also notes that it introduces a Notify message that is not sent to the = traffic destination address but instead to a node that requested = notification. One transmission option is that the NOTIFY is = encapsulated in an IP packet and forwarded directly to the requesting = node. That complicates the Integrity object protection, unless the = shared key is widely shared. > =20 > RFC3945 notes that authentication in GMPLS systems may use the = authentication mechanisms of the component protocols, pointing to = RFC2747 (as well as others for LDP, LMP, etc that don=E2=80=99t apply = here). > =20 > RFC5920 discusses threats, attacks, and protections for MPLS/GMPLS = data and control planes. Section 7.1.2 in particular talks about = =E2=80=9CControl-Plane Protection with RSVP-TE=E2=80=9D, and could be = mentioned here explicitly. It talks about network border configuration = to limit external attacks, and mentions > RFC2747 authentication protections, making some of the same points = about non-RSVP clouds and shared keys configuration. It also points to = RFC4230, which is a very detailed look at RSVP security, and probably = deserves to be mentioned here. > =20 > So all told, at the end of all the reference chains, the only defined = authentication and integrity protection in 2205, 3209, and 3473 is based = on shared keys that are very difficult to configure with fine = granularity. > =20 > However, as was said in reply to a different MPLS related draft review > yesterday: > =20 > The MPLS network is often considered to be a closed network such = that > insertion, modification, or inspection of packets by an outside = party is > not possible. > =20 > So maybe that is accepted as sufficient in deployment. > =20 > MPLS documents are also typically granted an exception from more = rigorous security requirements because MPLS is used only within one = routing domain / ISP / provider / etc, under a single administrative = control, so errors made would not be global in impact. In particular, = errors that might result from one legitimate but = faulty/mis-configured/subverted/malicious MPLS node should not propagate = out to the general Internet. (**) > [Amy] Thanks for the detail explanation on the security consideration, = it=E2=80=99s quiet educational. As the operating environment of GMPLS is = similar to MPLS network, we will adopt the similar text. > =20 > Nits: > =20 > floating numbers > =20 > Page 5, Section 3.1, says =E2=80=9Ca 32-bit floating number=E2=80=9D. = I believe you mean a floating-point number. I checked other IETF RFCs = (e.g., RFC8330), and it is common to mention the IEEE 754-2008 standard = when including a floating point value in the spec. > =20 > But is a floating point value needed? The draft says that the values = are typically in a small set of known values. The intro sounds like a = small set of classes are used for =E2=80=9Cefficient planning=E2=80=9D. = Just curious. OTOH, RFC8330 uses floating point, and the ITU = documents=E2=80=99 calculation of availability make it seem like full = floating point is needed. > [Amy] will update to =E2=80=9Cfloating-point number=E2=80=9D. > =20 > the Availability TLV format: > =20 > page 5, section 3.1 says: > =20 > The Availability TLV = has > the following format: > =20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Index | Reserved = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Availability = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =20 > Figure 1: Availability TLV > =20 > I presume that this is just the Value portion of the TLV format that = is defined for the Ethernet SENDER_TSPEC Object in Section 4 of RFC6003. > [Amy] Yes, it is.=20 > =20 > Page 1, Abstract: > =20 > typically used for describing these links when during network > planning > =20 > =E2=80=9Cwhen during=E2=80=9D - is that deliberate? It sounds = redundant, maybe due to editing. > Or maybe it was supposed to be =E2=80=9Cwhen doing=E2=80=9D? > [Amy] Will update to =E2=80=9Cwhen doing=E2=80=9D. > =20 > signaling. This extension can be used to set up a Generalized = Multi- > Protocol Label Switching (GMPLS) Label Switched Path (LSP) using = the > Ethernet SENDER_TSPEC object. > =20 > not sure - what is using the SENDER_TSPEC - the LSP or this extension? > [Amy] How about change to =E2=80=9Cin conjunction with = SENDER_TSPEC=E2=80=9D. > =20 > Page 3, Section 1: > =20 > bandwidth availability. For example, the bandwidth with 99.999% > availability of a link is 100 Mbps; the bandwidth with 99.99% > availability is 200 Mbps. > =20 > maybe: > =20 > bandwidth availability. Suppose, for example, the bandwidth with = 99.999% > [Amy] will update the text.=20 > =20 > Page 5, section 3.2: > =20 > TLVs and one or more Availability TLVs. Each Ethernet Bandwidth > Profile TLV corresponds to an availability parameter in the > Availability TLV. > =20 > =E2=80=A6 =E2=80=9Cin an Availability TLV=E2=80=9D? or =E2=80=9Cin the = associated Availability TLV=E2=80=9D? There=E2=80=99s more than one. > [Amy] will update to =E2=80=9Cin the associated Availability TLV=E2=80=9D= . > =20 > Page 6, section 3.2 > =20 > link), it SHOULD reserve the bandwidth resource from each > =20 > =E2=80=9Cit=E2=80=9D -> =E2=80=9Cthe node=E2=80=9D > =20 > this LSP. Optionally, the higher availability bandwidth can be > =20 > =E2=80=9Cthe higher=E2=80=9D -> =E2=80=9Ca higher=E2=80=9D (there=E2=80= =99s more than one, right?) > =20 > request cannot be satisfied, it SHOULD generate PathErr = message > =20 > =E2=80=9Cit=E2=80=9D -> =E2=80=9Cthe node=E2=80=9D > =20 > generate PathErr message with the error code "Extended Class-Type > =20 > =E2=80=9CPathErr=E2=80=9D -> =E2=80=9Ca PathErr=E2=80=9D or =E2=80=9CPat= hErr messages=E2=80=9D > [Amy] will update the draft accordingly. > postscripts: > =20 > (**) [[[ I will note that RFC3209 includes an AS number subject among = the subobjects of the EXPLICIT_ROUTE object. With the idea that you = might set up explicit routes that go through multiple ASNs. Ouch. I = know there are providers who have different ASNs under single = administrative control, from acquisitions or business use cases, but = this just makes it possible for an explicit route for an LSP to be = misconfigured to include your (external) neighbor ASN. And RFC5920 = talks about =E2=80=9CASBR-ASBR communication for inter-AS LSPs=E2=80=9D. = Better have good outbound filters on your border routers. ]]] > =20 > (*)As is typical for specifications that extend other published RFCs, = this draft says it =E2=80=9Cdoes not introduce any new security = considerations=E2=80=9D. > =20 > In general, I am skeptical of extension drafts that = make such claims. Surely the existing security considerations should be = examined to see how they apply to this new feature or object being = introduced? Do current protections adequately protect the new = feature/object? Does the new feature/object carry new information, = produce new behaviors? etc. But this is so very common I could hardly = request that more be said here. Just saying. soapbox> > [Amy] Thanks again for the detail review. From nobody Thu Mar 28 07:40:21 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 7E3B01204A9; Thu, 28 Mar 2019 06:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1553780321; bh=UClEsNh/w4GZofDjybfUg+QHMxxXP+6yndyKC9dmdpA=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=RL51O1CGCWx2310rhSL9+BLDu3koS+vee9P3oAPp0MivDHuf/3rvbgUJ1OiOhhTke u4qHUOM8HXRtGnpSWVZFVjGMSman54Q3y3xYhTOiOgcE4WdLHlQayqhlVcsJKwgUtQ I7gBuFfA2fTgcg9IHrxPkSf8S1yohmh+zTAAUwaY= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Mar 28 06:38:32 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B0447120457; Thu, 28 Mar 2019 06:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1553780298; bh=UClEsNh/w4GZofDjybfUg+QHMxxXP+6yndyKC9dmdpA=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=rZTyi9trH/pu3tuzUxlyEhilWF3DuY2j90d3OkHCctGkcUP5HBuI4SczCToDYuiv4 YetU0pd1Ecwpae2fYdmT4RIW65jdAuqIKzQ7m5xzv0sgnEjakIvhhyuSFlWzd8/pJ7 R32DT612tWY80W09Ep7pHaDkLfeiNfoKFkCctI5E= 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 0AD0812049E for ; Thu, 28 Mar 2019 06:38:06 -0700 (PDT) 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, HK_RANDOM_ENVFROM=0.001, 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 sJRBLOiOLRE4 for ; Thu, 28 Mar 2019 06:38:04 -0700 (PDT) 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 2A0C21204BB for ; Thu, 28 Mar 2019 06:38:04 -0700 (PDT) Received: from [42.100.5.31] (helo=jiaxueyuandeMacBook-Pro.local) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1h9VEG-0005LB-EL for new-work@ietf.org; Thu, 28 Mar 2019 13:38:01 +0000 To: new-work@ietf.org From: xueyuan Message-ID: <414ff11a-c25a-ff6b-aeb4-d3a1fbd15f10@w3.org> Date: Thu, 28 Mar 2019 21:37:55 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.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 Mar 2019 07:40:20 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Web & Networks Interest Group (until 2019-04-26) 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 Mar 2019 13:38:51 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgV2ViICYg TmV0d29ya3MgSW50ZXJlc3QgR3JvdXA6CiDCoCBodHRwczovL3d3dy53My5vcmcvMjAxOS8wMy93 ZWItbmV0d29ya3MtY2hhcnRlci1kcmFmdC5odG1sCgpBcyBwYXJ0IG9mIGVuc3VyaW5nIHRoYXQg dGhlIGNvbW11bml0eSBpcyBhd2FyZSBvZiBwcm9wb3NlZCB3b3JrCmF0IFczQywgdGhpcyBkcmFm dCBjaGFydGVyIGlzIHB1YmxpYyBkdXJpbmcgdGhlIEFkdmlzb3J5CkNvbW1pdHRlZSByZXZpZXcg cGVyaW9kLgoKVzNDIGludml0ZXMgcHVibGljIGNvbW1lbnRzIHRocm91Z2ggMjAxOS0wNC0yNiBv biB0aGUKcHJvcG9zZWQgY2hhcnRlci4gUGxlYXNlIHNlbmQgY29tbWVudHMgdG8KcHVibGljLW5l dy13b3JrQHczLm9yZywgd2hpY2ggaGFzIGEgcHVibGljIGFyY2hpdmU6CiDCoCBodHRwOi8vbGlz dHMudzMub3JnL0FyY2hpdmVzL1B1YmxpYy9wdWJsaWMtbmV3LXdvcmsvCgpPdGhlciB0aGFuIGNv bW1lbnRzIHNlbnQgaW4gZm9ybWFsIHJlc3BvbnNlcyBieSBXM0MgQWR2aXNvcnkKQ29tbWl0dGVl IFJlcHJlc2VudGF0aXZlcywgVzNDIGNhbm5vdCBndWFyYW50ZWUgYSByZXNwb25zZSB0bwpjb21t ZW50cy4gSWYgeW91IHdvcmsgZm9yIGEgVzNDIE1lbWJlciBbMV0sIHBsZWFzZSBjb29yZGluYXRl CnlvdXIgY29tbWVudHMgd2l0aCB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2 ZS4gRm9yCmV4YW1wbGUsIHlvdSBtYXkgd2lzaCB0byBtYWtlIHB1YmxpYyBjb21tZW50cyB2aWEg dGhpcyBsaXN0IGFuZApoYXZlIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZl IHJlZmVyIHRvIGl0IGZyb20gaGlzCm9yIGhlciBmb3JtYWwgcmV2aWV3IGNvbW1lbnRzLgoKSWYg eW91IHNob3VsZCBoYXZlIGFueSBxdWVzdGlvbnMgb3IgbmVlZCBmdXJ0aGVyIGluZm9ybWF0aW9u LCBwbGVhc2UKY29udGFjdCBEb21pbmlxdWUgSGF6YWVsLU1hc3NpZXV4LCBXM0MgU3RhZmYgQ29u dGFjdCA8b21AdzMub3JnPi4KClRoYW5rIHlvdSwKWHVleXVhbiBKaWEsIFczQyBNYXJrZXRpbmcg JiBDb21tdW5pY2F0aW9ucwoKWzFdIGh0dHA6Ly93d3cudzMub3JnL0NvbnNvcnRpdW0vTWVtYmVy L0xpc3QKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5l dy13b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Thu Mar 28 07:40:26 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 C98F61204AA; Thu, 28 Mar 2019 06:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1553781242; bh=27+BsWWK7V5pW19obvvKZr8xKAEgD9/MPl2xlBsWrGU=; h=From:To:References:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=d+Yi5kxTL3bHwubceNARsVy2WCp5C1POgegjtHJ7NU8+REuFyJ7gLnKVY0hRXlR0p UyyC5vvo5ywBHpo7I7jlcjfzqDeM+L3r0cY5D2WDtoWRnHL46bxBG7yAUw0Knnb7Mq Bm+DpGMKbeAYMRM5UeDhUQEfBYfFETdq43GKiOOw= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Mar 28 06:53:52 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC271204F8; Thu, 28 Mar 2019 06:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1553781223; bh=27+BsWWK7V5pW19obvvKZr8xKAEgD9/MPl2xlBsWrGU=; h=From:To:References:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; b=KnkpLaQmlAdlc+mNSGw+UtJLryJRA7sOnpvzVuLO9S4/6Cv7aqa30BW2JLg8N+zog +0v6B39nfeDiYJ3DY5agvs2xdQKxyEppL1uhxwp0VJDRsW8aK3OORQf4utqmzcpZBo KMCottSez8m/HtKtVpiOufWSr0K1SS1ntssDM2bU= 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 1ED681204FA for ; Thu, 28 Mar 2019 06:53:29 -0700 (PDT) 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, HK_RANDOM_ENVFROM=0.001, 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 eh6Vwsi13r4B for ; Thu, 28 Mar 2019 06:53:25 -0700 (PDT) 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 0940D120508 for ; Thu, 28 Mar 2019 06:53:25 -0700 (PDT) Received: from [42.100.5.31] (helo=jiaxueyuandeMacBook-Pro.local) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1h9VT8-0005fT-01 for new-work@ietf.org; Thu, 28 Mar 2019 13:53:22 +0000 From: xueyuan To: new-work@ietf.org References: <414ff11a-c25a-ff6b-aeb4-d3a1fbd15f10@w3.org> Message-ID: Date: Thu, 28 Mar 2019 21:53:07 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <414ff11a-c25a-ff6b-aeb4-d3a1fbd15f10@w3.org> 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 Mar 2019 07:40:20 -0700 Subject: [secdir] [new-work] correction [Re: Proposed W3C Charter: Web & Networks Interest Group (until 2019-04-26)] 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 Mar 2019 13:54:12 -0000 ClBsZWFzZSBmaW5kIGNvcnJlY3Rpb24gb2YgdGhlIGNvbnRhY3QgZW1haWwgYmVsb3cuCgpPbiAz LzI4LzE5IDk6MzcgUE0sIHh1ZXl1YW4gd3JvdGU6Cj4KPiBIZWxsbywKPgo+IFRvZGF5IFczQyBB ZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmVzIHJlY2VpdmVkIGEgUHJvcG9zYWwKPiB0 byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgV2ViICYgTmV0d29ya3MgSW50ZXJlc3Qg R3JvdXA6Cj4gwqAgaHR0cHM6Ly93d3cudzMub3JnLzIwMTkvMDMvd2ViLW5ldHdvcmtzLWNoYXJ0 ZXItZHJhZnQuaHRtbAo+Cj4gQXMgcGFydCBvZiBlbnN1cmluZyB0aGF0IHRoZSBjb21tdW5pdHkg aXMgYXdhcmUgb2YgcHJvcG9zZWQgd29yawo+IGF0IFczQywgdGhpcyBkcmFmdCBjaGFydGVyIGlz IHB1YmxpYyBkdXJpbmcgdGhlIEFkdmlzb3J5Cj4gQ29tbWl0dGVlIHJldmlldyBwZXJpb2QuCj4K PiBXM0MgaW52aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAyMDE5LTA0LTI2IG9uIHRoZQo+ IHByb3Bvc2VkIGNoYXJ0ZXIuIFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvCj4gcHVibGljLW5ldy13 b3JrQHczLm9yZywgd2hpY2ggaGFzIGEgcHVibGljIGFyY2hpdmU6Cj4gwqAgaHR0cDovL2xpc3Rz LnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvcHVibGljLW5ldy13b3JrLwo+Cj4gT3RoZXIgdGhhbiBj b21tZW50cyBzZW50IGluIGZvcm1hbCByZXNwb25zZXMgYnkgVzNDIEFkdmlzb3J5Cj4gQ29tbWl0 dGVlIFJlcHJlc2VudGF0aXZlcywgVzNDIGNhbm5vdCBndWFyYW50ZWUgYSByZXNwb25zZSB0bwo+ IGNvbW1lbnRzLiBJZiB5b3Ugd29yayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNvb3Jk aW5hdGUKPiB5b3VyIGNvbW1lbnRzIHdpdGggeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVz ZW50YXRpdmUuIEZvcgo+IGV4YW1wbGUsIHlvdSBtYXkgd2lzaCB0byBtYWtlIHB1YmxpYyBjb21t ZW50cyB2aWEgdGhpcyBsaXN0IGFuZAo+IGhhdmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVw cmVzZW50YXRpdmUgcmVmZXIgdG8gaXQgZnJvbSBoaXMKPiBvciBoZXIgZm9ybWFsIHJldmlldyBj b21tZW50cy4KPgo+IElmIHlvdSBzaG91bGQgaGF2ZSBhbnkgcXVlc3Rpb25zIG9yIG5lZWQgZnVy dGhlciBpbmZvcm1hdGlvbiwgcGxlYXNlCj4gY29udGFjdCBEb21pbmlxdWUgSGF6YWVsLU1hc3Np ZXV4LCBXM0MgU3RhZmYgQ29udGFjdCA8b21AdzMub3JnPi4KLi4gcGxlYXNlIGNvbnRhY3QgRG9t aW5pcXVlIEhhemFlbC1NYXNzaWV1eCwgVzNDIFN0YWZmIENvbnRhY3QgPGRvbUB3My5vcmc+LgoK QmVzdCBSZWdhcmRzLApYdWV5dWFuLCB3aXRoIGFwb2xvZ2llcyBmb3IgdGhlIG92ZXJzaWdodAoK Pgo+IFRoYW5rIHlvdSwKPiBYdWV5dWFuIEppYSwgVzNDIE1hcmtldGluZyAmIENvbW11bmljYXRp b25zCj4KPiBbMV0gaHR0cDovL3d3dy53My5vcmcvQ29uc29ydGl1bS9NZW1iZXIvTGlzdAo+Cgpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXctd29yayBt YWlsaW5nIGxpc3QKbmV3LXdvcmtAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXctd29yawo= From nobody Thu Mar 28 22:52:42 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 1A850120190; Thu, 28 Mar 2019 22:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 4xx81YOPL2wA; Thu, 28 Mar 2019 22:52:31 -0700 (PDT) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 600BB12008F; Thu, 28 Mar 2019 22:52:31 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 44VrVP4BfGz4wlk; Fri, 29 Mar 2019 06:52:29 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 44VrVP3SCPzDq78; Fri, 29 Mar 2019 06:52:29 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM41.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Fri, 29 Mar 2019 06:52:29 +0100 From: To: Stephen Farrell , "secdir@ietf.org" CC: "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-dots-signal-channel-30 Thread-Index: AQHU2xicRsTGH2X350i3IMDpwuRCCqYiMDAw Date: Fri, 29 Mar 2019 05:52:28 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA4F608@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <155257761487.2625.10003476313108979036@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA3DFC8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <72f7b85c-74fb-0f79-8211-50043c2b4b47@cs.tcd.ie> <787AE7BB302AE849A7480A190F8B93302EA3E475@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dots-signal-channel-30 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, 29 Mar 2019 05:52:33 -0000 SGkgU3RlcGhlbiwgDQoNCkZXSVcsIGEgbmV3IHZlcnNpb24gdGhhdCBpbnRlZ3JhdGVzIHlvdXIg Y29tbWVudHMgaXMgYXZhaWxhYmxlIG9ubGluZS4gVGhlIGRpZmYgY2FuIGJlIHRyYWNrZWQgYXQ6 DQpodHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRvdHMtc2ln bmFsLWNoYW5uZWwtMzEudHh0IA0KDQpQbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91IGhhdmUgZnVy dGhlciBjb21tZW50cy4gDQoNClRoYW5rIHlvdS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1N ZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IFN0ZXBoZW4gRmFycmVsbCBbbWFpbHRvOnN0 ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWVdDQo+IEVudm95w6nCoDogdmVuZHJlZGkgMTUgbWFycyAy MDE5IDExOjIwDQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE47IHNlY2RpckBpZXRm Lm9yZw0KPiBDY8KgOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwuYWxsQGlldGYub3Jn OyBpZXRmQGlldGYub3JnOw0KPiBkb3RzQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBTZWNkaXIg bGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMzANCj4g DQo+IA0KPiBIaXlhLA0KPiANCj4gT24gMTUvMDMvMjAxOSAwNjo0NywgbW9oYW1lZC5ib3VjYWRh aXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gPj4gSVNUTSB0aGF0IGFsbCBjbGllbnRzIGNhbiBnZXQg aW5mb3JtYXRpb24NCj4gPj4gYWJvdXQgaG93IGFuIGF0dGFjayBpcyBiZWluZyBzZWVuIGF0IG90 aGVyIGNsaWVudHMsIGlzbid0IHRoYXQNCj4gPj4gcmlnaHQ/DQo+ID4gW01lZF0gTm8uIEEgY2xp ZW50IGNhbiBvbmx5IGdldCBpbmZvcm1hdGlvbiB0aGF0IGlzIGJvdW5kIHRvIGl0Lg0KPiBXaGVy ZSBkb2VzIHRoZSBzcGVjIHNheSB0aGF0PyBJIGRvbid0IHJlY2FsbCB0aGUgdGVybSAiYm91bmQi DQo+IHVzZWQgdGhhdCB3YXkgYnV0IG1heSBoYXZlIG1pc3NlZCBpdC4NCj4gDQo+IEFuZCBpdCBz dGlsbCBzZWVtcyBhIGJpdCBoYXJkIHRvIGVuZm9yY2UuIElmIHR3byBjbGllbnRzIChvbmUNCj4g b2ssIG9uZSB6b21iaWVkKSBhc2sgdGhlIHNhbWUgc2VydmVyL25ldHdvcmsgaG93IG1hbnkgcGFj a2V0cw0KPiB0YXJnZXR0ZWQgYXQgMTAuMC4wLzI0IHdlcmUgZHJvcHBlZCB3b24ndCB0aGV5IGdl dCB0aGUgc2FtZQ0KPiBhbnN3ZXI/IChBc3N1bWluZyBib3RoIGNsaWVudHMgYXJlIHdpdGhpbiB0 aGF0IC8yNC4pDQo+IA0KPiBUaGFua3MsDQo+IFMuDQo= From nobody Fri Mar 29 04:37:03 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 80FC4120251; Fri, 29 Mar 2019 04:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.247 X-Spam-Level: X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, 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=btconnect.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 wUeqf3la52Bg; Fri, 29 Mar 2019 04:36:50 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150102.outbound.protection.outlook.com [40.107.15.102]) (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 4990D12024B; Fri, 29 Mar 2019 04:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VhrmWOm1O6wE5A8fl10AOF8lWYUVp+bKAhDnanpsqT4=; b=i2ez9/O7oT76tl/ogIlKn3jDs1ycK05QfvOXvF9hbwQ+30e0FEko6ddhq4jcAArxfqft4RPt/vgzpQRIwbo+FOJWfMc1zysovamymvbd/z5IP1JhKxKNX45ZuBG4tF4EjKB94RFvzKRSJTTPYgQiF6s8UZl2CupoE7Au0rIiKUo= Received: from DB7PR07MB5562.eurprd07.prod.outlook.com (20.178.46.212) by DB7PR07MB5045.eurprd07.prod.outlook.com (20.177.194.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.13; Fri, 29 Mar 2019 11:36:47 +0000 Received: from DB7PR07MB5562.eurprd07.prod.outlook.com ([fe80::b5b0:a479:a08:54d9]) by DB7PR07MB5562.eurprd07.prod.outlook.com ([fe80::b5b0:a479:a08:54d9%4]) with mapi id 15.20.1750.014; Fri, 29 Mar 2019 11:36:47 +0000 From: tom petch To: Sandra Murphy , "Yemin (Amy)" CC: "ccamp@ietf.org" , "secdir@ietf.org" , "draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org" , Sandra Murphy Thread-Topic: [CCAMP] Secdir last call review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-13 Thread-Index: AQHU5iOw1RlCGSGeXUO+py3YX8oOsA== Date: Fri, 29 Mar 2019 11:36:46 +0000 Message-ID: <02db01d4e623$51e9aee0$4001a8c0@gateway.2wire.net> References: <154908012600.28521.5714645741731093529@ietfa.amsl.com> <9C5FD3EFA72E1740A3D41BADDE0B461FCFB598CD@DGGEMM528-MBX.china.huawei.com> <3DCE5D1E-DBF1-4293-8FA1-FD6E975E24FC@tislabs.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0478.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a2::34) To DB7PR07MB5562.eurprd07.prod.outlook.com (2603:10a6:10:7b::20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.215.234] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 11b1e5a9-633d-4818-e793-08d6b43ad30c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7193020); SRVR:DB7PR07MB5045; x-ms-traffictypediagnostic: DB7PR07MB5045: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0991CAB7B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(376002)(396003)(39860400002)(346002)(199004)(189003)(37854004)(51914003)(13464003)(6116002)(316002)(6246003)(6436002)(66066001)(53936002)(54906003)(50226002)(68736007)(4326008)(86152003)(6306002)(53946003)(14454004)(9686003)(62236002)(44716002)(25786009)(97736004)(71200400001)(71190400001)(99286004)(4720700003)(5660300002)(84392002)(186003)(66574012)(2906002)(110136005)(486006)(44736005)(76176011)(81686011)(6486002)(14496001)(53546011)(81816011)(256004)(966005)(446003)(52116002)(305945005)(6512007)(81156014)(14444005)(30864003)(8676002)(229853002)(476003)(7736002)(81166006)(386003)(86362001)(1556002)(105586002)(8936002)(26005)(6506007)(478600001)(102836004)(61296003)(106356001)(3846002)(74416001)(7726001)(559001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB5045; H:DB7PR07MB5562.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: jGtc4j9Sxec82eMB5OwEmM0rtcixEQ6/X/gIUHwvgzNs2wekYCBYoliD0Baf9A9hA4szaNMi5moWLtyqO8NdFldA4z4kvHY5UUJ0Tu4ADcDItNHrX1jUNRnpjjhPt319tusyBb9/iy77FRPhYAVzvf4qRogImLYEiU2uv6qo7Bf7EBPS09fOaVaMbwGAx2+r+SdnohnE/+YTamQajl/oLxwWb3HrPvDBt74CkF/R7UZOqxOkfQ6F85b+PrVptLLdBxvCF+hRoOsKbeJ1trmsqR6fwVFlQRr7oWy/H0ix9fxYV5bfRfkCEAbC9U3KPu+0usxtTAq1QS4D5ePo5Y2Y76Vb92q0Nn9ouo1BadeqtaB6z/2yJ1+wcKiAhwopQGD05pI0OIyfEOnbSJQdE8wMM9h+DRjKIC3n3GoDzdJkO1E= Content-Type: text/plain; charset="utf-8" Content-ID: <8C57B162AA30CA47A0E1AF41C2600084@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 11b1e5a9-633d-4818-e793-08d6b43ad30c X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2019 11:36:46.9840 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5045 Archived-At: Subject: Re: [secdir] [CCAMP] Secdir last call review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-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, 29 Mar 2019 11:36:55 -0000 U2FuZHJhDQoNCk9uIGp1c3QgdGhlIHF1ZXN0aW9uIG9mIHRoZSByZWZlcmVuY2UgZm9yIGZsb2F0 aW5nIHBvaW50LCBJIHdvdWxkIGRyYXcNCnlvdXIgYXR0dGVudGlvbiB0byBZQU5HLCBSRkM3OTUw LHdoaWNoIGhhcw0KICAgW0lFRUU3NTQtMjAwOF0NCiAgICAgICAgICAgICAgSUVFRSwgIklFRUUg U3RhbmRhcmQgZm9yIEZsb2F0aW5nLVBvaW50IEFyaXRobWV0aWMiLA0KICAgICAgICAgICAgICBJ RUVFIDc1NC0yMDA4LCBET0kgMTAuMTEwOS9JRUVFU1RELjIwMDguNDYxMDkzNSwgMjAwOCwNCiAg ICAgICAgICAgICAgPGh0dHA6Ly9zdGFuZGFyZHMuaWVlZS5vcmcvZmluZHN0ZHMvDQogICAgICAg ICAgICAgIHN0YW5kYXJkLzc1NC0yMDA4Lmh0bWw+Lg0KVGhlcmUgaGFzIGJlZW4gYSBsb3Qgb2Yg ZGlzY3Vzc2lvbiBpbiB0aGUgSUVURiBPQU0gYXJlbmEgYXJvdW5kIHRoaXMNCnRvcGljIGFuZCBJ IHdvdWxkIHJlZ2FyZCB0aGF0IHJlZmVyZW5jZSBhcyB0aGUgYmVzdCBjb25zaWRlcmVkIGFuZA0K cGVyaGFwcyB0aGUgbW9zdCBpbmZsdWVudGlhbC4uDQoNClRvbSBQZXRjaA0KDQotLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiAiU2FuZHJhIE11cnBoeSIgPHNhbmR5QHRpc2xhYnMu Y29tPg0KVG86ICJZZW1pbiAoQW15KSIgPGFteS55ZW1pbkBodWF3ZWkuY29tPg0KQ2M6IDxjY2Ft cEBpZXRmLm9yZz47IDxzZWNkaXJAaWV0Zi5vcmc+Ow0KPGRyYWZ0LWlldGYtY2NhbXAtcnN2cC10 ZS1iYW5kd2lkdGgtYXZhaWxhYmlsaXR5LmFsbEBpZXRmLm9yZz47ICJTYW5kcmENCk11cnBoeSIg PHNhbmR5QHRpc2xhYnMuY29tPg0KU2VudDogVGh1cnNkYXksIE1hcmNoIDI4LCAyMDE5IDExOjMy IEFNDQpTdWJqZWN0OiBSZTogW0NDQU1QXSBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZg0KZHJh ZnQtaWV0Zi1jY2FtcC1yc3ZwLXRlLWJhbmR3aWR0aC1hdmFpbGFiaWxpdHktMTMNCg0KDQo+IEkg c2VlIHRoYXQgYSBuZXcgdmVyc2lvbiB3YXMgcG9zdGVkIG9uIE1hciA2LiAgSSB0aGFuayB0aGUg YXV0aG9ycyBmb3INCnRoZWlyIGF0dGVudGlvbiB0byBteSBjb21tZW50cyBhbmQgZm9yIHRoZSBl eHBsYW5hdGlvbnMgZm9yIGNhc2VzIHdoZXJlDQpJIHdhcyBjb25mdXNlZC4NCj4NCj4gSSBoYXZl IG9uZSBzdWdnZXN0aW9uLiAgVGhlIGF1dGhvcnMgY2hhbmdlZCB0aGUgdGV4dCB0byBzYXkg4oCc ZmxvYXRpbmcNCnBvaW504oCdLCBidXQgSSBkaWQgbm90IG1ha2UgY2xlYXIgdGhhdCBJIHRoaW5r IGEgcmVmZXJlbmNlIHRvIElFRUUgNzU0IGlzDQpuZWVkZWQuDQo+DQo+IEkgZm91bmQgb25lIHJl ZmVyZW5jZSB0byBhbiBJRVNHIGNvbW1lbnQgZHVyaW5nIHRoZSByZXZpZXcgb2YNCmRyYWZ0LWll dGYtaXNpcy1wY3INCj4NCj4g4oCiIEphcmkgQXJra286IENvbW1lbnQgWzIwMTYtMDEtMDcgMDQ6 NTEgUFNUXToNCj4gVGhpcyBjb21tZW50IGZyb20gU3VyZXNoIEtyaXNobmFuJ3MgR2VuLUFSVCBy ZXZpZXcgc2VlbXMgcmVsZXZhbnQ6DQpUaGVyZSBpcyBubyByZWZlcmVuY2UgZm9yIHRoZSBmb3Jt YXQgb2YgdGhlIEJhbmR3aWR0aCBmaWVsZHMgaW4gU2VjdGlvbnMNCjYuMyBhbmQgNi40LiBJIGFt IGFzc3VtaW5nIHRoaXMgcmVmZXJzIHRvIHRoZSBTaW5nbGUgUHJlY2lzaW9uIGZvcm1hdA0KKGJp bmFyeTMyKSBmcm9tIElFRUUgNzU0LiBJZiBzbywgcGxlYXNlIGFkZCBhbiBleHBsaWNpdCByZWZl cmVuY2UgdG8NCnRoaXMuDQo+DQo+IFNvIHRoZSByZWZlcmVuY2UgdG8gdGhlIElFRUUgc3RhbmRh cmQgaGFzIGJlZW4gY29uc2lkZXJlZCBhIGdvb2QgaWRlYQ0KaW4gcGFzdCBkcmFmdCBJRVNHIHJl dmlld3MuDQo+DQo+IEkgZm91bmQgdGhyZWUgUkZDcyB0aGF0IGNvbnRhaW5lZCBhIHJlZmVyZW5j ZSB0byB0aGUgSUVFRSA3NTQNCnN0YW5kYXJkLiAgVGhlIGZpcnN0IGlzIHRoZSBSRkMgdGhhdCBy ZXN1bHRlZCBmcm9tIGRyYWZ0LWlldGYtaXNpcy1wY3INCj4NCj4gUkZDIDc4MTMgICAgICAgICAg ICAgICAgICAgICAgICBJUy1JUyBQQ1IgICAgICAgICAgICAgICAgICAgICAgSnVuZQ0KMjAxNg0K Pg0KPiAxMS4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0KPg0KPiAgICBbSUVFRTc1NF0gIElF RUUsICJJRUVFIFN0YW5kYXJkIGZvciBGbG9hdGluZy1Qb2ludCBBcml0aG1ldGljIiwNCj4gICAg ICAgICAgICAgICBJRUVFIDc1NC0yMDA4LCBET0kgMTAuMTEwOS9JRUVFU1RELjIwMDguNDYxMDkz NSwgMjAwOCwNCj4gICAgICAgICAgICAgICA8aHR0cDovL3N0YW5kYXJkcy5pZWVlLm9yZy9maW5k c3Rkcy8NCj4gICAgICAgICAgICAgICBzdGFuZGFyZC83NTQtMjAwOC5odG1sPi4NCj4NCj4gdGhl IHNlY29uZCBpcyBhbiBPU1BGIFJGQw0KPg0KPiBSRkMgNzQ3MSAgICAgICAgICAgICAgICBPU1BG IFRFIE1ldHJpYyBFeHRlbnNpb25zICAgICAgICAgICAgIE1hcmNoDQoyMDE1DQo+DQo+IDEzLjEu ICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KPg0KPiAgICBbSUVFRTc1NF0gIEluc3RpdHV0ZSBvZiBF bGVjdHJpY2FsIGFuZCBFbGVjdHJvbmljcyBFbmdpbmVlcnMsDQo+ICAgICAgICAgICAgICAgIlN0 YW5kYXJkIGZvciBGbG9hdGluZy1Qb2ludCBBcml0aG1ldGljIiwgSUVFRSBTdGFuZGFyZA0KPiAg ICAgICAgICAgICAgIDc1NCwgQXVndXN0IDIwMDguDQo+DQo+IGFuZCB0aGUgdGhpcmQgaXMgYSBD Q0FNUCBSRkM6DQo+DQo+DQo+IFJGQyA4MzMwICAgICAgICAgICAgQXZhaWxhYmlsaXR5IEV4dGVu c2lvbiB0byBPU1BGLVRFICAgICAgRmVicnVhcnkNCjIwMTgNCj4NCj4gNy4xLiAgTm9ybWF0aXZl IFJlZmVyZW5jZXMNCj4NCj4gICAgW0lFRUU3NTQtMjAwOF0NCj4gICAgICAgICAgICAgICBJRUVF LCAiSUVFRSBTdGFuZGFyZCBmb3IgRmxvYXRpbmctUG9pbnQgQXJpdGhtZXRpYyIsDQo+ICAgICAg ICAgICAgICAgSUVFRSA3NTQtMjAwOCwgRE9JIDEwLjExMDkvSUVFRVNURC4yMDA4LjQ2MTA5MzUu DQo+DQo+DQo+IE5vdGUgdGhhdCBvbmUgcmVmZXJlbmNlIGlzIGluZm9ybWF0aXZlLCB0d28gYXJl IG5vcm1hdGl2ZS4gIFRoZQ0KYXV0aG9ycyBzaG91bGQgZGVjaWRlIHdoZXRoZXIgdGhlIGZvcm1h dCBpcyBhIHJlcXVpcmVtZW50IGFuZCB0aGVyZWZvcmUNCnRoZSByZWZlcmVuY2Ugc2hvdWxkIGJl IG5vcm1hdGl2ZS4NCj4NCj4gSW4gY29udmVyc2F0aW9uIHdpdGggdGhlIFJGQy1FZGl0b3IsIHRo ZXJlIGFyZSBzb21lIElFRUUgcmVxdWVzdHMgYXMNCnRvIGhvdyB0aGUgcmVmZXJlbmNlIHNob3Vs ZCBiZSBwaHJhc2VkLiAgVGhlIGF1dGhvcnMgbWF5IHdpc2ggdG8gY29uc3VsdA0KdGhlIFJGQy1F ZGl0b3IgdG8gZGVjaWRlIGhvdyB0aGlzIHJlZmVyZW5jZSBzaG91bGQgYmUgcGhyYXNlZC4gIFRo ZXJlDQphcmUgZXZpZGVudGx5IGNvbnNpZGVyYXRpb25zIG9mIHdoZXRoZXIgeW91IHdpc2ggdGhp cyBkb2N1bWVudCB0byBmb2xsb3cNCnRoZSBJRUVFIHN0YW5kYXJkIGFzIGl0IGNoYW5nZXMsIG9y IHdoZXRoZXIgeW91IHdhbnQgdG8gcG9pbnQgdG8gdGhlDQpjdXJyZW50IHZlcnNpb24gZXhwbGlj aXRseS4NCj4NCj4gU29tZXRoaW5nIEkgZGlkIG5vdCBub3RpY2UgYmVmb3JlOg0KPg0KPiBQYWdl IDY6DQo+DQo+ICAgICAgICAgT3B0aW9uYWxseSwgYSBoaWdoZXIgYXZhaWxhYmlsaXR5IGJhbmR3 aWR0aCBjYW4gYmUNCj4gICAgICAgICBhbGxvY2F0ZWQgdG8gbG93ZXIgYXZhaWxhYmlsaXR5IHJl cXVlc3Qgd2hlbiB0aGUgbG93ZXINCj4gICAgICAgICBhdmFpbGFiaWxpdHkgYmFuZHdpZHRoIGNh bm5vdCBzYXRpc2Z5IHRoZSByZXF1ZXN0Lg0KPg0KPg0KPiBEb2VzIHRoaXMgbWFrZSB0aGUgb3Jk ZXIgb2YgbG9va2luZyBhdCBhdmFpbGFiaWxpdHkgYmFuZHdpZHRoIHJlcXVlc3RzDQppbXBvcnRh bnQ/ICBJZiBhIGxvd2VyIGF2YWlsYWJpbGl0eSByZXF1aXJlbWVudCBiYW5kd2lkdGggcmVxdWVz dCBpcw0KYWxsb2NhdGVkIGZyb20gdGhlIGhpZ2hlciBhdmFpbGFiaWxpdHkgYmFuZHdpZHRoIGJl Zm9yZSBhbGwgaGlnaGVyDQphdmFpbGFiaWxpdHkgYmFuZHdpZHRoIHJlcXVlc3RzIGFyZSBzYXRp c2ZpZWQsIG1pZ2h0IHRoYXQgcHJldmVudCBhDQpoaWdoZXIgYXZhaWxhYmlsaXR5IGJhbmR3aWR0 aCByZXF1ZXN0IGZyb20gYmVpbmcgc2F0aXNmaWVkPw0KPg0KPiBBcHBlbmRpeCBQYWdlIDkgYW5k IDEwDQo+DQo+IEkgYW0gYWZyYWlkIHRoYXQgZXZlbiBhZnRlciByZXZpZXcgb2YgdGhlIGF1dGhv cnMnIGNvbW1lbnRzIGFuZA0KYW5vdGhlciB0aW1lIG92ZXIgdGhlIEFwcGVuZGl4LCBJIHN0aWxs IGRvIG5vdCB1bmRlcnN0YW5kIHRoZSB0YWJsZSBpbg0KdGhlIEFwcGVuZGl4LiAgVG8gbXkgcmVh ZGluZyBvZiBwYWdlIDkgYW5kIDEwOg0KPg0KPiA0MDBNYnBzIChsZXZlbCAzIG1vZHVsYXRpb24p IGlzIGF2YWlsYWJsZSBleGNlcHQgZm9yIHRoZSA1MiBtaW51dGVzIGENCnllYXIgd2hlbiB0aGUg bW9kdWxhdGlvbiBkcm9wcyB0byBsZXZlbCAyID09PiAoNTI1NjAwLTUyKS81MjU2MDAgPQ0KOTku OTklIG9mIHRoZSB0aW1lIDQwME1icHMgaXMgYXZhaWxhYmxlDQo+DQo+IDIwME1icHMgKGxldmVs IDIgbW9kdWxhdGlvbikgaXMgYXZhaWxhYmxlIGV4Y2VwdCBmb3IgdGhlIDI2IG1pbnV0ZXMgYQ0K eWVhciB3aGVuIHRoZSBtb2R1bGF0aW9uIGRyb3BzIHRvIGxldmVsIDEgPT0+ICg1MjU2MDAtMjYp LzUyNTYwMCA9DQo5OS45OTUlIG9mIHRoZSB0aW1lIDIwME1icHMgaXMgYXZhaWxhYmxlDQo+DQo+ IDEwME1icHMgKGxldmVsIDEgbW9kdWxhdGlvbikgaXMgYXZhaWxhYmxlIGV4Y2VwdCBmb3IgdGhl IDUgbWludXRlcyBhDQp5ZWFyIHdoZW4gdGhlIHdob2xlIHN5c3RlbSBpcyB1bmF2YWlsYWJsZSA9 PT4gKDUyNTYwMC01KS8yNTI2MDAgPQ0KOTkuOTk5JSBvZiB0aGUgdGltZSAxMDBNYnBzIGlzIGF2 YWlsYWJsZS4NCj4NCj4gKFRoZXJl4oCZcyBhbm90aGVyIGludGVycHJldGF0aW9uIG9mIHlvdXIg ZXhhbXBsZSB0ZXh0IC0gdGhhdCB0aGUNCjQwME1iZ3AgaXMgbm90IGF2YWlsYWJsZSBpbiB0aGUg bGlnaHQgcmFpbiB0aGF0IGRyb3BzIHRoZSBtb2R1bGF0aW9uIHRvDQpsZXZlbDIgLW9yLSAgdGhl IDI2IG1pbnV0ZXMgb2YgaGVhdnkgcmFpbiB0aGF0IGRyb3BzIHRoZSBtb2R1bGF0aW9uIHRvDQps ZXZlbCAxIC1vci0gd2hlbiB0aGUgd2hvbGUgc3lzdGVtIGlzIHVuYXZhaWxhYmxlLCBzbyA0MDBN YnBzIGlzDQp1bmF2YWlsYWJsZSA1MisyNis1IG1pbnV0ZXMgZWFjaCB5ZWFyLCB3aGljaCBpcyBt b3JlIGxpa2UgOTkuOTglLikNCj4NCj4gVGhhdCB3b3VsZCBtYWtlIHRoZSB0YWJsZSBzYXk6DQo+ DQo+IFN1Yi1iYW5kd2lkdGggKE1icHMpICAgQXZhaWxhYmlsaXR5DQo+DQo+ICAgIC0tLS0tLS0t LS0tLS0tLS0tLSAgICAgLS0tLS0tLS0tLS0tDQo+DQo+ICAgIDQwMCAgICAgICAgICAgICAgICAg ICAgOTkuOTklDQo+DQo+ICAgIDIwMCAgICAgICAgICAgICAgICAgICAgOTkuOTk1JQ0KPg0KPiAg ICAxMDAgICAgICAgICAgICAgICAgICAgIDk5Ljk5OSUNCj4NCj4gRXZlbiBpZiBJIGFtIHN0aWxs IGFtIGludGVycHJldGluZyB0aGlzIGluY29ycmVjdGx5LCBJIHdvdWxkIGxpa2UgdG8NCnBvaW50 IG91dCB0aGF0IHRoZSB0ZXh0IGhhcyB0d28gc3RhdGVtZW50cyBvbiBwYWdlIDEwIHRoYXQgc2Vl bSB0bw0KY29uZmxpY3Q6DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgVGhlbiB0aGUgZHJvcHBlZCAxMDAgTWJwcw0KPiAgICBiYW5kd2lkdGggaGFzIDk5Ljk5NSUg YXZhaWxhYmlsaXR5Lg0KPg0KPiBhbmQNCj4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBTbyB0aGUgMTAwIE1icHMNCj4gICAgYmFuZHdpZHRoIG9mIHRo ZSBtb2R1bGF0aW9uIGxldmVsIDEgb3ducyB0aGUgYXZhaWxhYmlsaXR5IG9mDQo+ICAgIDk5Ljk5 OSUuDQo+DQo+IFlvdSBtaWdodCB3YW50IHRvIGRvIHRoZSByZWFkZXJzIGEgZmF2b3IgYW5kIGNs ZWFyIHVwIHRoZSBjb25mbGljdC4NCj4NCj4NCj4gU29tZSBuaXRzIGFyZSBiZWxvdy4NCj4NCj4g 4oCUU2FuZHkNCj4NCj4gSW4gbGlnaHQgb2YgdGhlIFJGQy1FZGl0b3IgcmVxdWVzdCBkdXJpbmcg dGhlIElFVEYxMDQgcGxlbmFyeSBvbg0KV2VkbmVzZGF5LCBoZXJlIGFyZSBzb21lIG5pdHMgdGhl IFJGQy1FZGl0b3Igd291bGQgcHJvYmFibHkgY2F0Y2gsIGJ1dA0KdG8gbWFrZSB0aGVpciB0YXNr IGVhc2llciwgSSBub3RlIHRoZW0gaGVyZS4NCj4NCj4gUGFnZSAzOg0KPg0KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgV2hlbiBhIHZpZGVvIGFwcGxpY2F0aW9uIHJlcXVl c3RzDQo+ICAgIGZvciAxMjAgTWJwcyB3aXRob3V0IGJhbmR3aWR0aCBhdmFpbGFiaWxpdHkgcmVx dWlyZW1lbnQNCj4NCj4gcmVxdWVzdHMgZm9yIDEyMCBNYnBzIOKAlD4g4oCcbWFrZXMgYSByZXF1 ZXN0IGZvciAxMjBNYnBz4oCdIG9yIOKAnHJlcXVlc3RzDQoxMjBNYnBz4oCdDQo+IHdpdGhvdXQg YmFuZHdpZHRoIOKAlD4gd2l0aG91dCBhIGJhbmR3aWR0aA0KPg0KPiBQYWdlIDU6DQo+DQo+ICAg ICAgIEF2YWlsYWJpbGl0eSAoNCBvY3RldHMpOiBhIDMyLWJpdCBmbG9hdGluZyBwb2ludCBudW1i ZXINCmRlc2NyaWJlcw0KPg0KPiBUaGlzIHdvdWxkIGJlIGEgZ29vZCBwbGFjZSB0byBwdXQgYSBj aXRlIHRvIHRoZSBJRUVFIDc1NCByZWZlcmVuY2UuDQo+DQo+ICAgICAgIHRoZSBkZWNpbWFsIHZh bHVlIG9mIGF2YWlsYWJpbGl0eSByZXF1aXJlbWVudCBmb3IgdGhpcyBiYW5kd2lkdGgNCj4gICAg ICAgcmVxdWVzdC4gVGhlIHZhbHVlIE1VU1QgYmUgbGVzcyB0aGFuIDFhbmQgaXMgdXN1YWxseSBl eHByZXNzZWQNCmluDQo+DQo+IG9mIGF2YWlsYWJpbGl0eSByZXF1aXJlbWVudCDigJQ+IOKAnG9m IHRoZSBhdmFpbGFiaWxpdHkgcmVxdWlyZW1lbnTigJ0NCj4gMWFuZCDigJQ+IOKAnDEgYW5k4oCd DQo+DQo+IFBhZ2UgNjoNCj4NCj4gICAgICAgICBhbGxvY2F0ZWQgdG8gbG93ZXIgYXZhaWxhYmls aXR5IHJlcXVlc3Qgd2hlbiB0aGUgbG93ZXINCj4NCj4gdG8gbG93ZXIgYXZhaWxhYmlsaXR5IHJl cXVlc3Qg4oCUPiB0byBhIGxvd2VyIGF2YWlsYWJpbGl0eSByZXF1ZXN0DQo+DQo+ICAgIFdoZW4g YSBub2RlIHJlY2VpdmVzIEF2YWlsYWJpbGl0eSBUTFZzIHdoaWNoIG1peGVkIG9mIHplcm8gaW5k ZXgNCmFuZA0KPg0KPiDigJx3aGljaCBtaXhlZCBvZuKAnSDigJQ+IOKAnHdoaWNoIGFyZSBhIG1p eCBvZiINCj4NCj4gICAgc2V2ZXJhbCA8YmFuZHdpZHRoLCBhdmFpbGFiaWxpdHk+IHBhaXJzLCBi dXQgdGhlcmUncmUgYXJlIGV4dHJhDQo+DQo+IOKAnHRoZXJl4oCZcmUgYXJl4oCdIOKAlD4g4oCc dGhlcmUgYXJl4oCdDQo+DQo+ICAgIGJhbmR3aWR0aC1UTFZzIHdpdGhvdXQgbWF0Y2hpbmcgaW5k ZXggQXZhaWxhYmlsaXR5LVRMViwgdGhlIGV4dHJhDQo+DQo+IGNvdWxkIGJlIOKAnHdpdGhvdXQg bWF0Y2hpbmcgdGhlIGluZGV4IG9mIGFueSBBdmFpbGFiaWxpdHktVExW4oCdIG9yDQrigJx3aXRo b3V0IGFueSBBdmFpbGFiaWxpdHktVExWIHdpdGggYSBtYXRjaGluZyBpbmRleOKAnQ0KPg0KPiBQ YWdlIDc6DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBSU1ZQLVRFIHNpZ25hbGluZyB1c2VkDQo+ICAgIGluIEdNUExTIG5ldHdvcmsuDQo+DQo+IGlu IEdNUExTIG5ldHdvcmsg4oCUPiDigJxpbiBhIEdNUExTIG5ldHdvcmvigJ0gb3Ig4oCcaW4gR01Q TFMgbmV0d29ya3MiDQo+DQo+DQo+ID4gT24gRmViIDIyLCAyMDE5LCBhdCA0OjU4IEFNLCBZZW1p biAoQW15KSA8YW15LnllbWluQGh1YXdlaS5jb20+DQp3cm90ZToNCj4gPg0KPiA+IEhpIFNhbmRy YSwNCj4gPg0KPiA+IE1hbnkgdGhhbmtzIGZvciB0aGUgZGV0YWlsIHJldmlldyBjb21tZW50cywg cGxlYXNlIHNlZSByZXBseSBpbmxpbmUNCmJlbG93Lg0KPiA+IEFuZCBJ4oCZbSB2ZXJ5IHNvcnJ5 IGZvciB0aGUgbGF0ZSByZXBseS4NCj4gPg0KPiA+IEJSLA0KPiA+IEFteQ0KPiA+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogU2FuZHJhIE11cnBoeSBbbWFpbHRvOnNhbmR5 QHRpc2xhYnMuY29tXQ0KPiA+IFNlbnQ6IFNhdHVyZGF5LCBGZWJydWFyeSAwMiwgMjAxOSAxMjow MiBQTQ0KPiA+IFRvOiBzZWNkaXJAaWV0Zi5vcmcNCj4gPiBDYzogY2NhbXBAaWV0Zi5vcmc7IGll dGZAaWV0Zi5vcmc7DQpkcmFmdC1pZXRmLWNjYW1wLXJzdnAtdGUtYmFuZHdpZHRoLWF2YWlsYWJp bGl0eS5hbGxAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBv Zg0KZHJhZnQtaWV0Zi1jY2FtcC1yc3ZwLXRlLWJhbmR3aWR0aC1hdmFpbGFiaWxpdHktMTMNCj4g Pg0KPiA+IFJldmlld2VyOiBTYW5kcmEgTXVycGh5DQo+ID4gUmV2aWV3IHJlc3VsdDogSGFzIElz c3Vlcw0KPiA+DQo+ID4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQNCmRyYWZ0LWlldGYt Y2NhbXAtcnN2cC10ZS1iYW5kd2lkdGgtYXZhaWxhYmlsaXR5DQo+ID4gYXMgcGFydCBvZiB0aGUg c2VjdXJpdHkgZGlyZWN0b3JhdGXigJlzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwNCklF VEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gVGhlc2UgY29tbWVudHMg d2VyZSB3cml0dGVuDQpwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBh cmVhIGRpcmVjdG9ycy4gIERvY3VtZW50DQplZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRy ZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXINCmxhc3QgY2FsbCBjb21tZW50 cy4NCj4gPg0KPiA+IFRoaXMgZHJhZnQgcHJvdmlkZXMgYSBuZXcgVExWIGZvciB0aGUgRXRoZXJu ZXQgU0VOREVSX1RTUEVDIG9iamVjdA0KdGhhdCB3aWxsIGNhcnJ5IGF2YWlsYWJpbGl0eSByZXF1 aXJlbWVudHMgZm9yIFJTVlAtVEUgc2lnbmFsaW5nIG9mIEdNUExTDQpMU1BzLg0KPiA+DQo+ID4g VGhlIGRyYWZ0IGlzIHRob3JvdWdoLiAgSSBkbyBoYXZlIHNvbWUgY29tbWVudHMuICBJIHJldmll d2VkIHRoZQ0Kbm9ybWF0aXZlIHJlZmVyZW5jZXMgUkZDcyAyMjA1LCAzMjA5LCAzNDczLCA2MDAz LCBhcyB3ZWxsIGFzIFJGQzM5NDUgYW5kDQpSRkM1OTIwLiAgSSBjYW7igJl0IGNsYWltIHRoYXQg SSB1bmRlcnN0b29kIGV2ZXJ5dGhpbmcgaW4gdGhhdCBzdGFjaywgc28NCnRoZSBmb2xsb3dpbmcg Y291bGQgZWFzaWx5IGJlIHdyb25nLg0KPiA+DQo+ID4gQ29tcHV0aW5nIHRoZSBMU1AgcGF0aDoN Cj4gPg0KPiA+IFBhZ2UgNCwgc2VjdGlvbiAyIGRpc2N1c3NlcyBvYnRhaW5pbmcgbmV0d29yayB0 b3BvbG9neSwgY2FsY3VsYXRpbmcNCnRoZSBMU1Agcm91dGUsIFJGQzgzMzDigJlzIGV4dGVuc2lv bnMgZm9yIGF2YWlsYWJpbGl0eSBpbiBPU1BGIFRFIExTQQ0KbWVzc2FnZXMuICBEb2VzIHRoaXMg ZHJhZnQgYXNzdW1lIHRoYXQgdGhpcyBleHRlbnNpb24gd2lsbCBhbHdheXMgYmUNCnVzZWQgd2l0 aCBhbiBFWFBMSUNJVF9ST1VURSBvYmplY3Q/ICBJcyB0aGlzIGRyYWZ0IG5vdCBhcHBsaWNhYmxl DQp3aXRob3V0IHRoYXQgZXhwbGljaXQgTFNQIHJvdXRlIGNhbGN1bGF0aW9uPw0KPiA+IFtBbXld IE5vLCB0aGVyZSdzIG5vIGFzc3VtcHRpb24gdGhhdCB0aGUgZXh0ZW5zaW9uIGNhbiBiZSBvbmx5 IHVzZWQNCndpdGggYW4gRVhQTElDSVRfUk9VVEUgb2JqZWN0LiAgVGhlIG5vZGUgd2hvIG9idGFp bnMgbmV0d29yayB0b3BvbG9neSwNCmNhbGN1bGF0ZXMgdGhlIExTUCByb3V0ZSwgY291bGQgYmUg YSBzb3VyY2Ugbm9kZSBhbmQgaW50ZXJtZWRpYXRlIG5vZGVzLg0KPiA+IEF2YWlsYWJpbGl0eSBU TFYgdnMgQ0xBU1NUWVBFIG9iamVjdHM6DQo+ID4NCj4gPiBUaGUgZGVmaW5pdGlvbiBpbiBSRkM2 MDAzIG9mIHRoZSBCYW5kd2lkdGggUHJvZmlsZSBUTFYgaGFzIGNlcnRhaW4NCmNvbnN0cmFpbnRz IG9uIHRoZSB2YWx1ZXMgb2YgdGhlIEluZGV4Og0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAg ICBUaGUgSW5kZXggZmllbGQgdmFsdWUgTVVTVCBjb3JyZXNwb25kIHRvIGF0DQpsZWFzdCBvbmUN Cj4gPiAgICAgICBvZiB0aGUgQ2xhc3MtVHlwZSB2YWx1ZXMgaW5jbHVkZWQgZWl0aGVyIGluIHRo ZSBDTEFTU1RZUEUNCm9iamVjdA0KPiA+ICAgICAgIFtSRkM0MTI0XSBvciBpbiB0aGUgRVhURU5E RURfQ0xBU1NUWVBFIG9iamVjdCBbTUNPU10uDQo+ID4NCj4gPiBJIGFtIG5vdCBjZXJ0YWluIGlm IHRoaXMgbWVhbnMgdGhhdCB0aGUgcHJlc2VuY2Ugb2YgYW4gRXRoZXJuZXQNClNFTkRFUl9UU1BF QyBPYmplY3Qgd2l0aCBhIEJhbmR3aWR0aCBQcm9maWxlIFRMViBtZWFucyB0aGVyZSBtdXN0IGJl IGENCkNMQVNTVFlQRSBvYmplY3QgaW4gdGhlIFJTVlAtVEUgbWVzc2FnZSBhcyB3ZWxsLCBvciB0 aGF0IHRoZSBJbmRleCBmaWVsZA0KdmFsdWVzIGFyZSB0YWtlbiBmcm9tIHRoZSBzZXQgb2YgZGVm aW5lZCBDbGFzcy1UeXBlIHZhbHVlcy4NCj4gPg0KPiA+IEJ1dCBpZiB0aGUgZmlyc3QsIGRvZXMg dGhpcyBpbmR1Y2UgcmVxdWlyZW1lbnRzIGJ5IGluY2x1c2lvbiBvZiB0aGUNCkF2YWlsYWJpbGl0 eSBUTFYgdGhhdCB0aGVzZSBvdGhlciBDTEFTU1RZUEUgb2JqZWN0cyBtdXN0IGJlIGluY2x1ZGVk IGFzDQp3ZWxsPw0KPiA+IE9yIGFyZSB5b3UgaW50ZW5kaW5nIHRvIHVwZGF0ZSBSRkM2MDAzIHRv IGVsaW1pbmF0ZSB0aGF0IGNvbnN0cmFpbnQ/DQpJZiB0aGUgc2Vjb25kLCBkb2VzIHRoZSBSRkM2 MDAzIGNvbnN0cmFpbnQgYWxzbyBjb25zdHJhaW4gdGhlIGluZGV4DQp2YWx1ZXMgdXNlZCBpbiB0 aGUgQXZhaWxhYmlsaXR5IFRMVj8gIFNob3VsZCB0aGF0IGJlIG1lbnRpb25lZD8gIChPciBhbQ0K SSBqdXN0IGNvbmZ1c2VkPykNCj4gPiBbQW15XSBJdOKAmXMgdGhlIHNlY29uZCBjYXNlLiBUaGUg UkZDNjAwMyBjb25zdHJhaW50IHNob3VsZCBhbHNvIGFwcGx5DQp0byB0aGUgaW5kZXggdmFsdWVz IHVzZWQgaW4gdGhlIEF2YWlsYWJpbGl0eSBUTFYuIFRoZSBjdXJyZW50IHRleHQNCnN0YXRlcyB0 aGF0IOKAnGhhdmluZyB0aGUgc2FtZSB2YWx1ZSBvZiBJbmRleCBmaWVsZOKAnSwgd2hpY2ggaW1w bGllcyB0aGUNCnNhbWUgY29uc3RyYWludC4NCj4gPg0KPiA+IEJhbmR3aWR0aCBUTFYgdG8gQXZh aWxhYmlsaXR5IFRMViBhc3NvY2lhdGlvbjoNCj4gPg0KPiA+IFBhZ2UgNCwgU2VjdGlvbiAzLjEg c2F5cw0KPiA+DQo+ID4gICAgICAgV2hlbiB0aGUgQXZhaWxhYmlsaXR5IFRMViBpcyBpbmNsdWRl ZCwgaXQgTVVTVCBiZSBwcmVzZW50DQphbG9uZw0KPiA+ICAgICAgIHdpdGggdGhlIEV0aGVybmV0 IEJhbmR3aWR0aCBQcm9maWxlIFRMVi4gSWYgdGhlIGJhbmR3aWR0aA0KPiA+ICAgICAgIHJlcXVp cmVtZW50cyBpbiB0aGUgbXVsdGlwbGUgRXRoZXJuZXQgQmFuZHdpZHRoIFByb2ZpbGUgVExWcw0K aGF2ZQ0KPiA+ICAgICAgIGRpZmZlcmVudCBBdmFpbGFiaWxpdHkgcmVxdWlyZW1lbnRzLCBtdWx0 aXBsZSBBdmFpbGFiaWxpdHkNClRMVnMNCj4gPiAgICAgICBTSE9VTEQgYmUgY2FycmllZC4gSW4g c3VjaCBhIGNhc2UsIHRoZSBBdmFpbGFiaWxpdHkgVExWIGhhcyBhDQpvbmUNCj4gPiAgICAgICB0 byBvbmUgY29ycmVzcG9uZGVuY2Ugd2l0aCB0aGUgRXRoZXJuZXQgQmFuZHdpZHRoIFByb2ZpbGUg VExWDQpieQ0KPiA+ICAgICAgIGhhdmluZyB0aGUgc2FtZSB2YWx1ZSBvZiBJbmRleCBmaWVsZC4g SWYgYWxsIHRoZSBiYW5kd2lkdGgNCj4gPiAgICAgICByZXF1aXJlbWVudHMgaW4gdGhlIEV0aGVy bmV0IEJhbmR3aWR0aCBQcm9maWxlIGhhdmUgdGhlIHNhbWUNCj4gPiAgICAgICBBdmFpbGFiaWxp dHkgcmVxdWlyZW1lbnQsIG9uZSBBdmFpbGFiaWxpdHkgVExWIFNIT1VMRCBiZQ0KY2FycmllZC4N Cj4gPiAgICAgICBJbiB0aGlzIGNhc2UsIHRoZSBJbmRleCBmaWVsZCBpcyBzZXQgdG8gMC4NCj4g Pg0KPiA+IEkgZmluZCB0aGF0IHRoZSBkZXNjcmlwdGlvbiBpcyBub3QgY2xlYXIgaW4gYWxsIGNh c2VzLiAgSSBmb3VuZCBhDQptZXNzYWdlIGluIHRoZSB3b3JraW5nIGdyb3VwIGRpc2N1c3Npb24g b2YgdGhpcyBhc3NvY2lhdGlvbiB0aGF0IHRoZQ0KYXNzb2NpYXRpb24gaXMgZWl0aGVyIOKAnG46 buKAnSBvciDigJxuOjHigJ0uICBJIHRoaW5rIHRoaXMgZGVzY3JpcHRpb24gc291bmRzDQptb3Jl IGxpa2UgbiAxOjEgYXNzb2NpYXRpb25zDQo+ID4gb3IgYSAgbjoxIGFzc29jaWF0aW9uLiAgIElz IHRoYXQgd2hhdCBpcyBpbnRlbmRlZD8gIENhbiB0aGUNCmFzc29jaWF0aW9ucyBiZQ0KPiA+IG1p eGVkIGluIHRoZSBzYW1lIG1lc3NhZ2U/ICBTdXBwb3NlIHRoZXJlIHdlcmUgMyBCYW5kd2lkdGgg VExWcyB0aGF0DQpuZWVkZWQgdGhlIHNhbWUgYXZhaWxhYmlsaXR5IGFuZCBvbmUgdGhhdCBoYWQg YSBkaWZmZXJlbnQgYXZhaWxhYmlsaXR5DQpuZWVkLCBjb3VsZCB0aGVyZSBiZSAzIEJhbmR3aWR0 aCBUTFZzIHdpdGggaW5kZXggMCBhbmQgb25lDQpBdmFpbGFiaWxpdHktVExWIHdpdGggaW5kZXgg MCBhbmQgYWxzbyBhIEJhbmR3aWR0aCBUTFZzIC0gQXZhaWxhYmlsaXR5DQpUTFYgcGFpciB3aXRo IG1hdGNoaW5nIGluZGV4IHZhbHVlcz8NCj4gPiBbQW15XSBUaGFua3MgZm9yIGxvb2tpbmcgaW50 byB0aGUgcGFzdCBkaXNjdXNzaW9uLiBUaGUgaW50ZW5zaW9uIHdhcw0KbiooMToxKSBhc3NvY2lh dGlvbiBvciBuOjEgYXNzb2NpYXRpb24uIEl0IHdhcyBub3Qgc28gYWNjdXJhdGUgYnkgdXNpbmcN CuKAnG46buKAnSBhc3NvY2lhdGlvbiBpbiB0aGUgcGFzdC4NCj4gPiBSZWdhcmRpbmcgdGhlIGV4 YW1wbGUgeW91IGxpc3QsIGlmIHRoZSBmb3VyIEJhbmR3aWR0aCBUTFZzIGFyZSBzZW50DQppbiB0 aGUgc2FtZSBtZXNzYWdlLCBpdOKAmXMgYmV0dGVyIHRvIHVzZSBmb3VyIGRpZmZlcmVudCBpbmRl eCB2YWx1ZXMgYXMNCnRoZXkgYXJlIOKAnG11bHRpcGxlIEV0aGVybmV0IEJhbmR3aWR0aCBQcm9m aWxlIFRMVnMgaGF2ZSBkaWZmZXJlbnQNCkF2YWlsYWJpbGl0eSByZXF1aXJlbWVudHPigJ0uDQo+ ID4gT2YgY291cnNlIHdoYXQgeW91IHByb3Bvc2VkIGNvdWxkIGFsc28gd29yayB0ZWNobmljYWxs eS4NCj4gPg0KPiA+IGVycm9yIGNoZWNraW5nOg0KPiA+DQo+ID4gT3RoZXIgZG9jdW1lbnRzIGlu IHRoZSByZWZlcmVuY2VzIChSRkMyMjA1LCAzMjA5LCAzNDczLCA2MDAzLCBldGMpDQpoYXZlIG1h ZGUgYSBwb2ludCBvZiBleHBsaWNpdGx5IGRlc2NyaWJpbmcgdGhlIGVycm9yIGhhbmRsaW5nIC0g d2hlbg0KUGF0aEVyciBhbmQgUmVzdkVyciBhbmQgTm90aWZ5IG1lc3NhZ2VzIGFyZSBzZW50LCB0 byB3aG9tLCB0aGUgZXJyb3INCmNvZGVzLCB0aGUgZXJyb3IgdmFsdWUgc3ViLWNvZGVzLCBldGMu ICBJIGRvbuKAmXQgc2VlIHRoYXQgaGVyZSBmb3IgdGhlDQpiYW5kd2lkdGgtdGx2LXRvLWF2YWls YWJpbGl0eS10bHYgYXNzb2NpYXRpb25zLg0KPiA+IFtBbXldIFRoYW5rcyBmb3IgdGhlIGNvbW1l bnQsIEkgYWdyZWUgdGhlIGVycm9yIHByb2Nlc3Mgc2hvdWxkIGJlDQpjbGVhcmVyLg0KPiA+IElz IGEgbWl4IG9mIGluZGV4LXplcm8gYW5kIGluZGV4LW5vbi16ZXJvDQpiYW5kd2lkdGgtdGx2LXRv LWF2YWlsYWJpbGl0eS10bHYgYXNzb2NpYXRpb25zIChsaWtlIGFib3ZlKSBhbiBlcnJvcj8gaXMN CnRoZSBtZXNzYWdlIGRyb3BwZWQ/ICBpcyBhbiBlcnJvciBzZW50Pw0KPiA+IGlmIHRoZSBtZXNz YWdlIGlzIG5vdCBkcm9wcGVkLCBhcmUgYW55IG9mIHRoZSBiYW5kd2lkdGgtdGx2LA0KYXZhaWxh YmlsaXR5LXRsdiBhc3NvY2lhdGlvbnMgcmV0YWluZWQ/DQo+ID4gW0FteV0gVGhlIG1lc3NhZ2Ug TUFZIGJlIGlnbm9yZWQgYW5kIFNIT1VMRCBOT1QgYmUgcHJvcGFnYXRlZC4NCj4gPiBJZiB0aGVy ZSBhcmUgYXZhaWxhYmlsaXR5LXRsdnMgd2l0aCBub24temVybyBpbmRleGVzIHdpdGggbm8NCm1h dGNoaW5nIGluZGV4IHZhbHVlIGFtb25nIHRoZSBiYW5kd2lkdGgtdGx2cywgdGhhdCBzdXJlbHkg aXMgYW4gZXJyb3I/DQpJcyB0aGUgbWVzc2FnZSBkcm9wcGVkPyAgT3IgaXMgdGhlIGF2YWlsYWJp bGl0eSB0bHYgZHJvcHBlZD8gIElzIGENClBhdGhFcnIvUmVzdkVyciBtZXNzYWdlIHNlbnQ/DQo+ ID4gW0FteV0geWVzLCB0aGlzIGlzIGFuIGVycm9yLiBJdOKAmXMgcHJlZmVycmVkIHRvIGRyb3Ag dGhlIGF2YWlsYWJpbGl0eQ0KdGx2Lg0KPiA+IFN1cHBvc2UgYWxsIGF2YWlsYWJpbGl0eS10bHZz IGhhdmUgYSBtYXRjaGluZyAoemVybyBvciBub24temVybykNCmluZGV4IHZhbHVlIGFtb25nIHRo ZSBiYW5kd2lkdGgtdGx2cywgYnV0IHRoZXJlIGFyZSBleHRyYSBiYW5kd2lkdGgtdGx2cw0KKG5v IGF2YWlsYWJpbGl0eS10bHYgd2l0aCBhIG1hdGNoaW5nIGluZGV4IHZhbHVlKS4gIElzIHRoYXQg YW4gZXJyb3I/DQpBcmUgdGhlIGV4dHJhIGJhbmR3aWR0aC10bHZzIGRyb3BwZWQ/IGlnbm9yZWQ/ IHByb3BhZ2F0ZWQ/DQo+ID4gW0FteV1UaGUgZXh0cmEgYmFuZHdpZHRoLXRsdnMgTUFZIGJlIGln bm9yZWQgYW5kIFNIT1VMRCBOT1QgYmUNCnByb3BhZ2F0ZWQuDQo+ID4gKFJGQzMyMDkgaGFzIHNl dmVyYWwgY2FzZXMgd2hlcmUgdGhlcmUgbWlnaHQgYmUgZXh0cmEgb2JqZWN0cyBvcg0Kc3ViLW9i amVjdHMgYW5kIHRoZSBsYW5ndWFnZSBpcyDigJxjYW4gYmUvTUFZIGJlL1NIT1VMRCBiZS9hcmUg aWdub3JlZCBhbmQNClNIT1VMRCBOT1QgYmUgL2FyZSBub3QvbmVlZCBub3QgYmUgcHJvcGFnYXRl ZOKAnSApDQo+ID4NCj4gPg0KPiA+IG11bHRpcGxpY2l0eToNCj4gPg0KPiA+IFJGQzMyMDkgc2F5 cyBpdCBkb2VzIG5vdCBhcHBseSB0byBtdWx0aWNhc3QsIGJ1dCBpdCBkb2VzIHRhbGsgYWJvdXQN Cm11bHRpcGxlIHBhcmFsbGVsIExTUCB0dW5uZWxzIGJldHdlZW4gdHdvIG5vZGVzLCBhbmQgYWJv dXQNCm11bHRpcG9pbnQtdG8tcG9pbnQgTFNQcyBmb3IgV0YgYW5kIFNFIHN0eWxlIHJlc2VydmF0 aW9ucyB3aGVuIHRoZXJlIGFyZQ0KbXVsdGlwbGUgc2VuZGVycywgYW5kIGFib3V0IHRoZSBtZXJn aW5nIHJ1bGVzIG9mIFdGIHJlc2VydmF0aW9ucy4gIERvZXMNCmF2YWlsYWJpbGl0eSB3b3JrIGlu IHRob3NlIHN0eWxlIHJlc2VydmF0aW9ucz8NCj4gPiBbQW15XSBDb25zaWRlcmluZyB0aGF0IHRo ZSB0cmFmZmljIGZyb20gc2VuZGVycyBpcyBtb3JlIGxpa2VseSB0byBiZQ0KY29uY3VycmVudCBh bmQgaW5kZXBlbmRlbnQsIHRoZSBhdmFpbGFiaWxpdHkgVExWIGNhbiBiZSBsaW1pdGVkIHRvIEZp eGVkDQpGaWx0ZXIgKEZGKSBTdHlsZSBvbmx5Lg0KPiA+IGF2YWlsYWJpbGl0eSB2cyDigJx2YXJp YWJsZSBkaXNjcmV0ZSBiYW5kd2lkdGjigJ06DQo+ID4NCj4gPiBJIGJlbGlldmUgSSB1bmRlcnN0 b29kIHRoZSBkaXNjdXNzaW9uIG9mIHRoZSBuZWVkIHRvIHNpZ25hbA0KYXZhaWxhYmlsaXR5IHJl cXVpcmVtZW50cyBpbiBvcmRlciBmb3IgdGhlIHN5c3RlbSB0byBkZXRlcm1pbmUgd2hlbiBhbg0K TFNQIHdhcyBmZWFzaWJsZS4gIEkgY2FuIGRpbWx5IHVuZGVyc3RhbmQgdGhhdCB0aGVyZSBtaWdo dCBiZSBsaW5rcyBoYXZlDQrigJx2YXJpYWJsZSBkaXNjcmV0ZSBiYW5kd2lkdGjigJ0uICBTZWN0 aW9uIDIgc2F5cyDigJxUaGUgQXZhaWxhYmlsaXR5IFRMViBjYW4NCmJlIGFwcGxpY2FibGUgdG8g YW55IGtpbmQgb2YgcGh5c2ljYWwgbGlua3Mgd2l0aCB2YXJpYWJsZSBkaXNjcmV0ZQ0KYmFuZHdp ZHRoLCBzdWNoIGFzIG1pY3Jvd2F2ZSBvciBEU0wu4oCdDQo+ID4gV2h5IG5vdCBvdGhlciBsaW5r IHR5cGVzPyBEbyBvbmx5IOKAnHZhcmlhYmxlIGRpc2NyZXRlIGJhbmR3aWR0aOKAnQ0KbGlua3Mg c3VwcG9ydCBhdmFpbGFiaWxpdHk/DQo+ID4gW0FteV0gVG8gb3VyIGN1cnJlbnQga25vd2xlZGdl LCBvbmx54oCcdmFyaWFibGUgZGlzY3JldGUgYmFuZHdpZHRo4oCdDQpsaW5rcyBzdXBwb3J0IGF2 YWlsYWJpbGl0eS4NCj4gPg0KPiA+IGNhbGN1bGF0aW5nIGF2YWlsYWJpbGl0eToNCj4gPg0KPiA+ IEluIHBhZ2UgOSwgQXBwZW5kaXggQToNCj4gPg0KPiA+IFBlcmhhcHMgSSBkb27igJl0IHVuZGVy c3RhbmQgaG93IHRoZSBhdmFpbGFiaWxpdHkgbWV0cmljIGlzIHVzZWQuICBJbg0KdGhlDQo+ID4g Zm9sbG93aW5nOg0KPiA+DQo+ID4gICAgT24gYSBzdW5ueSBkYXksIHRoZSBtb2R1bGF0aW9uIGxl dmVsIDMgY2FuIGJlIHVzZWQgdG8gYWNoaWV2ZSA0MDANCj4gPiAgICBNYnBzIGxpbmsgYmFuZHdp ZHRoLg0KPiA+DQo+ID4gICAgQSBsaWdodCByYWluIHdpdGggWCBtbS9oIHJhdGUgdHJpZ2dlcnMg dGhlIHN5c3RlbSB0byBjaGFuZ2UgdGhlDQo+ID4gICAgbW9kdWxhdGlvbiBsZXZlbCBmcm9tIGxl dmVsIDMgdG8gbGV2ZWwgMiwgd2l0aCBiYW5kd2lkdGggY2hhbmdpbmcNCj4gPiAgICBmcm9tIDQw MCBNYnBzIHRvIDIwMCBNYnBzLiBUaGUgcHJvYmFiaWxpdHkgb2YgWCBtbS9oIHJhaW4gaW4gdGhl DQo+ID4gICAgbG9jYWwgYXJlYSBpcyA1MiBtaW51dGVzIGluIGEgeWVhci4gVGhlbiB0aGUgZHJv cHBlZCAyMDAgTWJwcw0KPiA+ICAgIGJhbmR3aWR0aCBoYXMgOTkuOTklIGF2YWlsYWJpbGl0eS4N Cj4gPg0KPiA+IEkgd291bGQgc2F5IHRoYXQgdGhlIDQwME1icHMgYmFuZHdpZHRoIGlzIGF2YWls YWJsZSB3aGVuZXZlciBpdCBpcw0Kbm90IHJhaW5pbmcuDQo+ID4gSXQgbGlnaHRseSByYWlucyA1 MiBtaW4geWVhciwgd2hpY2ggbWVhbnMgaXQgaXMgbm90IHJhaW5pbmcgOTkuOTklDQpvZiB0aGUg dGltZSwgc28gdGhlIDQwME1icHMgYXZhaWxhYmlsaXR5IGlzIDk5Ljk5JS4gIFRoZSAyMDBNYnBz IGlzDQphdmFpbGFibGUgZHVyaW5nIHRoYXQgNTIgbWluLCBzbyA5OS45OSUgaXMgbm90IHRoZSAy MDBNYnBzIGF2YWlsYWJpbGl0eS4NClJpZ2h0Pw0KPiA+DQo+ID4gVGhlIGFuYWxvZ291cyBjb21t ZW50IGFwcGxpZXMgdG8gdGhlIG5leHQgdHdvIHBhcmFncmFwaHMuDQo+ID4NCj4gPiBEb2VzIHRo YXQgZXhwbGFpbiB3aHkgdGhlIHRhYmxlIHNob3dzIHRoZSAxMDBNYnBzIGJhbmR3aWR0aCBoYXZp bmcNCnR3byBkaWZmZXJlbnQgYXZhaWxhYmlsaXRpZXM/DQo+ID4gW0FteV1Zb3VyIHVuZGVyc3Rh bmRpbmcgaXMgYWxzbyBjb3JyZWN0LiBUaGF0IGlzIGp1c3QgYSBkaWZmZXJlbnQNCndheSB0byBw cmVzZW50IHRoZSByZXN1bHQuIFRha2UgdGhlIHZhbHVlcyBmcm9tIHRoZSB0YWJsZSwgMTAwTWJw cyB3aXRoDQo5OS45OTUlIGFuZCAxMDBNYnBzIHdpdGggOTkuOTk5JSBjYW4gYmUgYWxzbyBjb25z aWRlcmVkIGFzIGJhbmR3aWR0aA0Kd2l0aCA5OS45OSUgYXZhaWxhYmlsaXR5Lg0KPiA+IFRodXMg aXQgd2lsbCByZXN1bHQgdGhlIHRvdGFsIGJ3IHdpdGggOTkuOTklIGF2YWlsYWJpbGl0eSA9DQoy MDArMTAwKzEwMD00MDBNYnBzDQo+ID4NCj4gPg0KPiA+IHNlY3VyaXR5Og0KPiA+DQo+ID4gVGhl IGRyYWZ0ICgqKSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIHBvaW50cyB0byBSU1ZQLVRFLCBidXQg d2l0aG91dA0KYW4gUkZDIHJlZmVyZW5jZSwgYW5kIHRvIFJGQzU5MjAuICBCZWNhdXNlIHRoaXMg aXMgYSBHTVBMUyByZWxhdGVkDQpmZWF0dXJlLCBpdCBzaG91bGQgcmVmZXIgdG8gdGhlIEdNUExT IGV4dGVuc2lvbnMgdG8gUlNWUC1URSBpbiBSRkMzNDczLg0KQXMgYW4gZXh0ZW5zaW9uIHRvIFJG QzYwMDMsIGl0IGNvdWxkIHJlZmVyIHRvIHRoYXQgUkZD4oCZcyBzZWN1cml0eQ0KY29uc2lkZXJh dGlvbnMgc2VjdGlvbiwgYnV0IHRoYXQgb25seSBnZXRzIHRoZSByZWFkZXIgdG8gUkZDMzQ3MywN ClJGQzMyMDksIGFuZCBSRkM1OTIwLg0KPiA+DQo+ID4gVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIGZvciBSU1ZQLVRFIGl0c2VsZiAoUkZDMzIwOSkgcG9pbnRzIHRvDQpSRkMyMjA1Lg0KPiA+ IFJGQzIyMDUgZGVmaW5lcyBhbiBJbnRlZ3JpdHkgb2JqZWN0IChkZWZpbmVkIGluIFJGQzI3NDcp IHRoYXQNCmNhcnJpZXMgYSBrZXllZCBjcnlwdG9ncmFwaGljIGRpZ2VzdCBiYXNlZCBvbiBhIHNo YXJlZCBrZXksIHByb3ZpZGluZw0KaG9wLWJ5LWhvcCBwcm90ZWN0aW9uIGJldHdlZW4gdHdvIFJT VlAgbm9kZXMuICBIb3dldmVyLCBQQVRIIG1lc3NhZ2VzDQphcmUgZGlyZWN0ZWQgdG93YXJkIHRo ZSB0cmFmZmljIGRlc3RpbmF0aW9uIGFkZHJlc3MsIG5vdCB0aGUgbmV4dCBSU1ZQDQpub2RlLiAg VGhlcmUgY291bGQgYmUgY2xvdWRzIG9mIG5vbi1SU1ZQIG5vZGVzIGJldHdlZW4gdHdvIFJTVlAg bm9kZXMNCnRoYXQgdGhlIFBBVEggZW5jb3VudGVycy4gIFRoaXMgbWFrZXMgaXQgZGlmZmljdWx0 IHRvIHNoYXJlIGEga2V5DQpiZXR3ZWVuIGluZGl2aWR1YWwgcGFpcnMgb2YgUlNWUCBub2Rlcywg YW5kIGNvdWxkIG1vdGl2YXRlIG9wZXJhdG9ycyB0bw0KY29uZmlndXJlIHRoZSBzYW1lIGtleSBp biBsYXJnZSBudW1iZXJzIG9mIFJTVlAgbm9kZXMuDQo+ID4NCj4gPiBSRkMzNDczIHBvaW50cyB0 byBSRkMyNzQ34oCZcyBwcm90ZWN0aW9uIG9mIFJTVlAgbWVzc2FnZXMuICBJdCBhbHNvDQpub3Rl cyB0aGF0IGl0IGludHJvZHVjZXMgYSBOb3RpZnkgbWVzc2FnZSB0aGF0IGlzIG5vdCBzZW50IHRv IHRoZQ0KdHJhZmZpYyBkZXN0aW5hdGlvbiBhZGRyZXNzIGJ1dCBpbnN0ZWFkIHRvIGEgbm9kZSB0 aGF0IHJlcXVlc3RlZA0Kbm90aWZpY2F0aW9uLiAgT25lIHRyYW5zbWlzc2lvbiBvcHRpb24gaXMg dGhhdCB0aGUgTk9USUZZIGlzDQplbmNhcHN1bGF0ZWQgaW4gYW4gSVAgcGFja2V0IGFuZCBmb3J3 YXJkZWQgZGlyZWN0bHkgdG8gdGhlIHJlcXVlc3RpbmcNCm5vZGUuICBUaGF0IGNvbXBsaWNhdGVz IHRoZSBJbnRlZ3JpdHkgb2JqZWN0IHByb3RlY3Rpb24sIHVubGVzcyB0aGUNCnNoYXJlZCBrZXkg aXMgd2lkZWx5IHNoYXJlZC4NCj4gPg0KPiA+IFJGQzM5NDUgbm90ZXMgdGhhdCBhdXRoZW50aWNh dGlvbiBpbiBHTVBMUyBzeXN0ZW1zIG1heSB1c2UgdGhlDQphdXRoZW50aWNhdGlvbiBtZWNoYW5p c21zIG9mIHRoZSBjb21wb25lbnQgcHJvdG9jb2xzLCBwb2ludGluZyB0bw0KUkZDMjc0NyAoYXMg d2VsbCBhcyBvdGhlcnMgZm9yIExEUCwgTE1QLCBldGMgdGhhdCBkb27igJl0IGFwcGx5IGhlcmUp Lg0KPiA+DQo+ID4gUkZDNTkyMCBkaXNjdXNzZXMgdGhyZWF0cywgYXR0YWNrcywgYW5kIHByb3Rl Y3Rpb25zIGZvciBNUExTL0dNUExTDQpkYXRhIGFuZCBjb250cm9sIHBsYW5lcy4gIFNlY3Rpb24g Ny4xLjIgaW4gcGFydGljdWxhciB0YWxrcyBhYm91dA0K4oCcQ29udHJvbC1QbGFuZSBQcm90ZWN0 aW9uIHdpdGggUlNWUC1UReKAnSwgYW5kIGNvdWxkIGJlIG1lbnRpb25lZCBoZXJlDQpleHBsaWNp dGx5LiAgSXQgdGFsa3MgYWJvdXQgbmV0d29yayBib3JkZXIgY29uZmlndXJhdGlvbiB0byBsaW1p dA0KZXh0ZXJuYWwgYXR0YWNrcywgYW5kIG1lbnRpb25zDQo+ID4gUkZDMjc0NyBhdXRoZW50aWNh dGlvbiBwcm90ZWN0aW9ucywgbWFraW5nIHNvbWUgb2YgdGhlIHNhbWUgcG9pbnRzDQphYm91dCBu b24tUlNWUCBjbG91ZHMgYW5kIHNoYXJlZCBrZXlzIGNvbmZpZ3VyYXRpb24uICBJdCBhbHNvIHBv aW50cyB0bw0KUkZDNDIzMCwgd2hpY2ggaXMgYSB2ZXJ5IGRldGFpbGVkIGxvb2sgYXQgUlNWUCBz ZWN1cml0eSwgYW5kIHByb2JhYmx5DQpkZXNlcnZlcyB0byBiZSBtZW50aW9uZWQgaGVyZS4NCj4g Pg0KPiA+IFNvIGFsbCB0b2xkLCBhdCB0aGUgZW5kIG9mIGFsbCB0aGUgcmVmZXJlbmNlIGNoYWlu cywgdGhlIG9ubHkNCmRlZmluZWQgYXV0aGVudGljYXRpb24gYW5kIGludGVncml0eSBwcm90ZWN0 aW9uIGluIDIyMDUsIDMyMDksIGFuZCAzNDczDQppcyBiYXNlZCBvbiBzaGFyZWQga2V5cyB0aGF0 IGFyZSB2ZXJ5IGRpZmZpY3VsdCB0byBjb25maWd1cmUgd2l0aCBmaW5lDQpncmFudWxhcml0eS4N Cj4gPg0KPiA+IEhvd2V2ZXIsIGFzIHdhcyBzYWlkIGluIHJlcGx5IHRvIGEgZGlmZmVyZW50IE1Q TFMgcmVsYXRlZCBkcmFmdA0KcmV2aWV3DQo+ID4geWVzdGVyZGF5Og0KPiA+DQo+ID4gICAgIFRo ZSBNUExTIG5ldHdvcmsgaXMgb2Z0ZW4gY29uc2lkZXJlZCB0byBiZSBhIGNsb3NlZCBuZXR3b3Jr IHN1Y2gNCnRoYXQNCj4gPiAgICAgaW5zZXJ0aW9uLCBtb2RpZmljYXRpb24sIG9yIGluc3BlY3Rp b24gb2YgcGFja2V0cyBieSBhbiBvdXRzaWRlDQpwYXJ0eSBpcw0KPiA+ICAgICBub3QgcG9zc2li bGUuDQo+ID4NCj4gPiBTbyBtYXliZSB0aGF0IGlzIGFjY2VwdGVkIGFzIHN1ZmZpY2llbnQgaW4g ZGVwbG95bWVudC4NCj4gPg0KPiA+IE1QTFMgZG9jdW1lbnRzIGFyZSBhbHNvIHR5cGljYWxseSBn cmFudGVkIGFuIGV4Y2VwdGlvbiBmcm9tIG1vcmUNCnJpZ29yb3VzIHNlY3VyaXR5IHJlcXVpcmVt ZW50cyBiZWNhdXNlIE1QTFMgaXMgdXNlZCBvbmx5IHdpdGhpbiBvbmUNCnJvdXRpbmcgZG9tYWlu IC8gSVNQIC8gcHJvdmlkZXIgLyBldGMsIHVuZGVyIGEgc2luZ2xlIGFkbWluaXN0cmF0aXZlDQpj b250cm9sLCBzbyBlcnJvcnMgbWFkZSB3b3VsZCBub3QgYmUgZ2xvYmFsIGluIGltcGFjdC4gIElu IHBhcnRpY3VsYXIsDQplcnJvcnMgdGhhdCBtaWdodCByZXN1bHQgZnJvbSBvbmUgbGVnaXRpbWF0 ZSBidXQNCmZhdWx0eS9taXMtY29uZmlndXJlZC9zdWJ2ZXJ0ZWQvbWFsaWNpb3VzIE1QTFMgbm9k ZSBzaG91bGQgbm90IHByb3BhZ2F0ZQ0Kb3V0IHRvIHRoZSBnZW5lcmFsIEludGVybmV0LiAgKCoq KQ0KPiA+IFtBbXldIFRoYW5rcyBmb3IgdGhlIGRldGFpbCBleHBsYW5hdGlvbiBvbiB0aGUgc2Vj dXJpdHkNCmNvbnNpZGVyYXRpb24sIGl04oCZcyBxdWlldCBlZHVjYXRpb25hbC4gQXMgdGhlIG9w ZXJhdGluZyBlbnZpcm9ubWVudCBvZg0KR01QTFMgaXMgc2ltaWxhciB0byBNUExTIG5ldHdvcmss IHdlIHdpbGwgYWRvcHQgdGhlIHNpbWlsYXIgdGV4dC4NCj4gPg0KPiA+IE5pdHM6DQo+ID4NCj4g PiBmbG9hdGluZyBudW1iZXJzDQo+ID4NCj4gPiBQYWdlIDUsIFNlY3Rpb24gMy4xLCBzYXlzIOKA nGEgMzItYml0IGZsb2F0aW5nIG51bWJlcuKAnS4gIEkgYmVsaWV2ZSB5b3UNCm1lYW4gYSBmbG9h dGluZy1wb2ludCBudW1iZXIuICBJIGNoZWNrZWQgb3RoZXIgSUVURiBSRkNzIChlLmcuLA0KUkZD ODMzMCksIGFuZCBpdCBpcyBjb21tb24gdG8gbWVudGlvbiB0aGUgSUVFRSA3NTQtMjAwOCBzdGFu ZGFyZCB3aGVuDQppbmNsdWRpbmcgYSBmbG9hdGluZyBwb2ludCB2YWx1ZSBpbiB0aGUgc3BlYy4N Cj4gPg0KPiA+IEJ1dCBpcyBhIGZsb2F0aW5nIHBvaW50IHZhbHVlIG5lZWRlZD8gIFRoZSBkcmFm dCBzYXlzIHRoYXQgdGhlDQp2YWx1ZXMgYXJlIHR5cGljYWxseSBpbiBhIHNtYWxsIHNldCBvZiBr bm93biB2YWx1ZXMuICBUaGUgaW50cm8gc291bmRzDQpsaWtlIGEgc21hbGwgc2V0IG9mIGNsYXNz ZXMgYXJlIHVzZWQgZm9yIOKAnGVmZmljaWVudCBwbGFubmluZ+KAnS4gIEp1c3QNCmN1cmlvdXMu ICBPVE9ILCBSRkM4MzMwIHVzZXMgZmxvYXRpbmcgcG9pbnQsIGFuZCB0aGUgSVRVIGRvY3VtZW50 c+KAmQ0KY2FsY3VsYXRpb24gb2YgYXZhaWxhYmlsaXR5IG1ha2UgaXQgc2VlbSBsaWtlIGZ1bGwg ZmxvYXRpbmcgcG9pbnQgaXMNCm5lZWRlZC4NCj4gPiBbQW15XSB3aWxsIHVwZGF0ZSB0byDigJxm bG9hdGluZy1wb2ludCBudW1iZXLigJ0uDQo+ID4NCj4gPiB0aGUgQXZhaWxhYmlsaXR5IFRMViBm b3JtYXQ6DQo+ID4NCj4gPiBwYWdlIDUsIHNlY3Rpb24gMy4xIHNheXM6DQo+ID4NCj4gPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRoZSBBdmFpbGFiaWxp dHkgVExWDQpoYXMNCj4gPiAgICB0aGUgZm9sbG93aW5nIGZvcm1hdDoNCj4gPg0KPiA+ICAgICAg ICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAg ICAgICAzDQo+ID4gICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDgg OSAwIDEgMiAzIDQgNSA2IDcgOCA5IDANCjENCj4gPg0KKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gPiAgICAgICB8ICAg IEluZGV4ICAgICAgfCAgICAgICAgICAgICAgICAgUmVzZXJ2ZWQNCnwNCj4gPg0KKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN Cj4gPiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICBBdmFpbGFiaWxpdHkNCnwNCj4g Pg0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDE6 IEF2YWlsYWJpbGl0eSBUTFYNCj4gPg0KPiA+IEkgcHJlc3VtZSB0aGF0IHRoaXMgaXMganVzdCB0 aGUgVmFsdWUgcG9ydGlvbiBvZiB0aGUgVExWIGZvcm1hdCB0aGF0DQppcyBkZWZpbmVkIGZvciB0 aGUgRXRoZXJuZXQgU0VOREVSX1RTUEVDIE9iamVjdCBpbiBTZWN0aW9uIDQgb2YgUkZDNjAwMy4N Cj4gPiBbQW15XSBZZXMsIGl0IGlzLg0KPiA+DQo+ID4gUGFnZSAxLCBBYnN0cmFjdDoNCj4gPg0K PiA+ICAgIHR5cGljYWxseSB1c2VkIGZvciBkZXNjcmliaW5nIHRoZXNlIGxpbmtzIHdoZW4gZHVy aW5nIG5ldHdvcmsNCj4gPiAgICBwbGFubmluZw0KPiA+DQo+ID4g4oCcd2hlbiBkdXJpbmfigJ0g LSBpcyB0aGF0IGRlbGliZXJhdGU/ICBJdCBzb3VuZHMgcmVkdW5kYW50LCBtYXliZSBkdWUNCnRv IGVkaXRpbmcuDQo+ID4gT3IgbWF5YmUgaXQgd2FzIHN1cHBvc2VkIHRvIGJlIOKAnHdoZW4gZG9p bmfigJ0/DQo+ID4gW0FteV0gV2lsbCB1cGRhdGUgdG8g4oCcd2hlbiBkb2luZ+KAnS4NCj4gPg0K PiA+ICAgIHNpZ25hbGluZy4gVGhpcyBleHRlbnNpb24gY2FuIGJlIHVzZWQgdG8gc2V0IHVwIGEg R2VuZXJhbGl6ZWQNCk11bHRpLQ0KPiA+ICAgIFByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoR01Q TFMpIExhYmVsIFN3aXRjaGVkIFBhdGggKExTUCkgdXNpbmcNCnRoZQ0KPiA+ICAgIEV0aGVybmV0 IFNFTkRFUl9UU1BFQyBvYmplY3QuDQo+ID4NCj4gPiBub3Qgc3VyZSAtIHdoYXQgaXMgdXNpbmcg dGhlIFNFTkRFUl9UU1BFQyAtIHRoZSBMU1Agb3IgdGhpcw0KZXh0ZW5zaW9uPw0KPiA+IFtBbXld IEhvdyBhYm91dCBjaGFuZ2UgdG8g4oCcaW4gY29uanVuY3Rpb24gd2l0aCBTRU5ERVJfVFNQRUPi gJ0uDQo+ID4NCj4gPiBQYWdlIDMsIFNlY3Rpb24gMToNCj4gPg0KPiA+ICAgIGJhbmR3aWR0aCBh dmFpbGFiaWxpdHkuIEZvciBleGFtcGxlLCB0aGUgYmFuZHdpZHRoIHdpdGggOTkuOTk5JQ0KPiA+ ICAgIGF2YWlsYWJpbGl0eSBvZiBhIGxpbmsgaXMgMTAwIE1icHM7IHRoZSBiYW5kd2lkdGggd2l0 aCA5OS45OSUNCj4gPiAgICBhdmFpbGFiaWxpdHkgaXMgMjAwIE1icHMuDQo+ID4NCj4gPiBtYXli ZToNCj4gPg0KPiA+ICAgIGJhbmR3aWR0aCBhdmFpbGFiaWxpdHkuIFN1cHBvc2UsIGZvciBleGFt cGxlLCB0aGUgYmFuZHdpZHRoIHdpdGgNCjk5Ljk5OSUNCj4gPiBbQW15XSB3aWxsIHVwZGF0ZSB0 aGUgdGV4dC4NCj4gPg0KPiA+IFBhZ2UgNSwgc2VjdGlvbiAzLjI6DQo+ID4NCj4gPiAgICBUTFZz IGFuZCBvbmUgb3IgbW9yZSBBdmFpbGFiaWxpdHkgVExWcy4gRWFjaCBFdGhlcm5ldCBCYW5kd2lk dGgNCj4gPiAgICBQcm9maWxlIFRMViBjb3JyZXNwb25kcyB0byBhbiBhdmFpbGFiaWxpdHkgcGFy YW1ldGVyIGluIHRoZQ0KPiA+ICAgIEF2YWlsYWJpbGl0eSBUTFYuDQo+ID4NCj4gPiDigKYg4oCc aW4gYW4gQXZhaWxhYmlsaXR5IFRMVuKAnT8gb3Ig4oCcaW4gdGhlIGFzc29jaWF0ZWQgQXZhaWxh YmlsaXR5IFRMVuKAnT8NClRoZXJl4oCZcyBtb3JlIHRoYW4gb25lLg0KPiA+IFtBbXldIHdpbGwg dXBkYXRlIHRvIOKAnGluIHRoZSBhc3NvY2lhdGVkIEF2YWlsYWJpbGl0eSBUTFbigJ0uDQo+ID4N Cj4gPiBQYWdlIDYsIHNlY3Rpb24gMy4yDQo+ID4NCj4gPiAgICAgICAgIGxpbmspLCBpdCBTSE9V TEQgcmVzZXJ2ZSB0aGUgYmFuZHdpZHRoIHJlc291cmNlIGZyb20gZWFjaA0KPiA+DQo+ID4g4oCc aXTigJ0gLT4g4oCcdGhlIG5vZGXigJ0NCj4gPg0KPiA+ICAgICAgICB0aGlzIExTUC4gT3B0aW9u YWxseSwgdGhlIGhpZ2hlciBhdmFpbGFiaWxpdHkgYmFuZHdpZHRoIGNhbg0KYmUNCj4gPg0KPiA+ IOKAnHRoZSBoaWdoZXLigJ0gLT4g4oCcYSBoaWdoZXLigJ0gICh0aGVyZeKAmXMgbW9yZSB0aGFu IG9uZSwgcmlnaHQ/KQ0KPiA+DQo+ID4gICAgICAgICByZXF1ZXN0IGNhbm5vdCBiZSBzYXRpc2Zp ZWQsIGl0IFNIT1VMRCBnZW5lcmF0ZSBQYXRoRXJyDQptZXNzYWdlDQo+ID4NCj4gPiDigJxpdOKA nSAtPiDigJx0aGUgbm9kZeKAnQ0KPiA+DQo+ID4gICAgZ2VuZXJhdGUgUGF0aEVyciBtZXNzYWdl IHdpdGggdGhlIGVycm9yIGNvZGUgIkV4dGVuZGVkIENsYXNzLVR5cGUNCj4gPg0KPiA+IOKAnFBh dGhFcnLigJ0gLT4g4oCcYSBQYXRoRXJy4oCdIG9yIOKAnFBhdGhFcnIgbWVzc2FnZXPigJ0NCj4g PiBbQW15XSB3aWxsIHVwZGF0ZSB0aGUgZHJhZnQgYWNjb3JkaW5nbHkuDQo+ID4gcG9zdHNjcmlw dHM6DQo+ID4NCj4gPiAoKiopIFtbWyBJIHdpbGwgbm90ZSB0aGF0IFJGQzMyMDkgaW5jbHVkZXMg YW4gQVMgbnVtYmVyIHN1YmplY3QNCmFtb25nIHRoZSBzdWJvYmplY3RzIG9mIHRoZSBFWFBMSUNJ VF9ST1VURSBvYmplY3QuICBXaXRoIHRoZSBpZGVhIHRoYXQNCnlvdSBtaWdodCBzZXQgdXAgZXhw bGljaXQgcm91dGVzIHRoYXQgZ28gdGhyb3VnaCBtdWx0aXBsZSBBU05zLiAgT3VjaC4NCkkga25v dyB0aGVyZSBhcmUgcHJvdmlkZXJzIHdobyBoYXZlIGRpZmZlcmVudCBBU05zIHVuZGVyIHNpbmds ZQ0KYWRtaW5pc3RyYXRpdmUgY29udHJvbCwgZnJvbSBhY3F1aXNpdGlvbnMgb3IgYnVzaW5lc3Mg dXNlIGNhc2VzLCBidXQNCnRoaXMganVzdCBtYWtlcyBpdCBwb3NzaWJsZSBmb3IgYW4gZXhwbGlj aXQgcm91dGUgZm9yIGFuIExTUCB0byBiZQ0KbWlzY29uZmlndXJlZCB0byBpbmNsdWRlIHlvdXIg KGV4dGVybmFsKSBuZWlnaGJvciBBU04uICBBbmQgUkZDNTkyMA0KdGFsa3MgYWJvdXQg4oCcQVNC Ui1BU0JSIGNvbW11bmljYXRpb24gZm9yIGludGVyLUFTIExTUHPigJ0uICBCZXR0ZXIgaGF2ZQ0K Z29vZCBvdXRib3VuZCBmaWx0ZXJzIG9uIHlvdXIgYm9yZGVyIHJvdXRlcnMuIF1dXQ0KPiA+DQo+ ID4gKCopQXMgaXMgdHlwaWNhbCBmb3Igc3BlY2lmaWNhdGlvbnMgdGhhdCBleHRlbmQgb3RoZXIg cHVibGlzaGVkDQpSRkNzLCB0aGlzIGRyYWZ0IHNheXMgaXQg4oCcZG9lcyBub3QgaW50cm9kdWNl IGFueSBuZXcgc2VjdXJpdHkNCmNvbnNpZGVyYXRpb25z4oCdLg0KPiA+DQo+ID4gPGJlZ2luIHNv YXBib3g+IEluIGdlbmVyYWwsIEkgYW0gc2tlcHRpY2FsIG9mIGV4dGVuc2lvbiBkcmFmdHMgdGhh dA0KbWFrZSBzdWNoIGNsYWltcy4gIFN1cmVseSB0aGUgZXhpc3Rpbmcgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgc2hvdWxkIGJlDQpleGFtaW5lZCB0byBzZWUgaG93IHRoZXkgYXBwbHkgdG8gdGhp cyBuZXcgZmVhdHVyZSBvciBvYmplY3QgYmVpbmcNCmludHJvZHVjZWQ/ICBEbyBjdXJyZW50IHBy b3RlY3Rpb25zIGFkZXF1YXRlbHkgcHJvdGVjdCB0aGUgbmV3DQpmZWF0dXJlL29iamVjdD8gIERv ZXMgdGhlIG5ldyBmZWF0dXJlL29iamVjdCBjYXJyeSBuZXcgaW5mb3JtYXRpb24sDQpwcm9kdWNl IG5ldyBiZWhhdmlvcnM/ICBldGMuIEJ1dCB0aGlzIGlzIHNvIHZlcnkgY29tbW9uIEkgY291bGQg aGFyZGx5DQpyZXF1ZXN0IHRoYXQgbW9yZSBiZSBzYWlkIGhlcmUuIEp1c3Qgc2F5aW5nLiA8ZW5k DQo+ID4gc29hcGJveD4NCj4gPiBbQW15XSBUaGFua3MgYWdhaW4gZm9yIHRoZSBkZXRhaWwgcmV2 aWV3Lg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4gQ0NBTVBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPg0KDQo= From nobody Fri Mar 29 12:51:37 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 CE20C1203AD; Fri, 29 Mar 2019 12:51:35 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 FApI1OUg3Mru; Fri, 29 Mar 2019 12:51:33 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 135F3120391; Fri, 29 Mar 2019 12:51:33 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id s24so3088280otk.13; Fri, 29 Mar 2019 12:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=JZtgMe8oIM21WOVX0kDMGuGg7IlJRZhfC+q7A3WSOeo=; b=OnaUibBkWOmUlcNzmXWCYhQOUGMrOsIJDH7OYTevA7OvpsYRxIJnERS4L9iQ1lbjgj dNHwIXtiCUicAKnmp4e370MS5BL6jgUhRxkWuECB9DxTJggsYFyWjMPvCMqa+Njz+Ynm 4YyrYTmgfQbZ6srqSh4klM3+uJmdhoBq437tDPxllwpG+nSfGjLKHR4XHWPxrU5LoBA4 vccdUxeEWo050IznQkNZJPifwGJEiBSVwl/BOZoEoLUy+y8urmuCePvC38ht/181Dcgi pB9gCEA2gO45NNBnKMRPaZcKSRBiU0qnEUoGzvnDHYMRHhVRtGD4FFdub1eqoHL5LGBk vBcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=JZtgMe8oIM21WOVX0kDMGuGg7IlJRZhfC+q7A3WSOeo=; b=VCmjQu/WR0lfV6S5y5PumSO9f43TNRrTvnKJC934xNA+jPtwSuuXt9sIiIst6RB8ie VLYxAg2AQ1X9dSMmVMzp3H3WmigFF4DKY7O481yWieV8BBjh/Vw0IBPM5otum5QH53Ak nFL4juzFAI9Z/Fujsmqm/OBW1k0ZTB3H4C64chT5+bHWgpedRRZJQVrGCGR1tqjuFCEN FGHB8gQ03eHcyiVHGIcRJffRaxi1/YSWbq7gbXGym0vv1JLMxAqjmrqbo257OwZ09rMr MC9JDfV0qNbgfym0mW1ABD7cWnRc1dt1qrrPZZ7RLmsvRZMvwDI8Mm7rgo0JJYk5yY2T HpQA== X-Gm-Message-State: APjAAAXwww48xpV91LmSgk7hkQ3vPvK0EMRaqFJNO4LBXv1Be0LK38iO Bhq3MgOHwSLN1iw3dVJ0UIjU0xzP X-Google-Smtp-Source: APXvYqzFTc2vM6LuU6WGjMC/kA2QijGV1sL90U1G3y2vLnU3dXcFsYabOIotHDiDmzquAcNW22CKTQ== X-Received: by 2002:a9d:3db4:: with SMTP id l49mr15289461otc.131.1553889092182; Fri, 29 Mar 2019 12:51:32 -0700 (PDT) Received: from Chriss-Air.attlocal.net ([2600:1700:12b0:adf0:6cff:1df5:e5b8:6de5]) by smtp.googlemail.com with ESMTPSA id c136sm1342040oih.14.2019.03.29.12.51.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Mar 2019 12:51:31 -0700 (PDT) To: "Eric Voit (evoit)" References: <5C99813D.9070401@gmail.com> <56b8c323f2284ce1bee2d6083898b017@XCH-RTP-013.cisco.com> Cc: "draft-ietf-netconf-subscribed-notifications.all@ietf.org" , "secdir@ietf.org" , "iesg@ietf.org" From: Chris Lonvick Message-ID: <5C9E7742.2080701@gmail.com> Date: Fri, 29 Mar 2019 14:51:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <56b8c323f2284ce1bee2d6083898b017@XCH-RTP-013.cisco.com> Content-Type: multipart/alternative; boundary="------------000405090900050700080604" Archived-At: Subject: Re: [secdir] SECDIR Review of draft-ietf-netconf-subscribed-notifications 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, 29 Mar 2019 19:51:36 -0000 This is a multi-part message in MIME format. --------------000405090900050700080604 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Eric, On 3/26/19 8:35 AM, Eric Voit (evoit) wrote: > > Hi Chris, > > Thanks very much for the review and comments. Some thoughts in-line... > > *From:*Chris Lonvick > *Sent:* Monday, March 25, 2019 9:33 PM > *To:* draft-ietf-netconf-subscribed-notifications.all@ietf.org; > secdir@ietf.org; iesg@ietf.org > *Subject:* SECDIR Review of draft-ietf-netconf-subscribed-notifications > > Hello, > > 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 Ready With Nits. > > This is not an area that I'm very familiar with so I skimmed the draft > and reviewed the Security Considerations section. Overall, the > document appears to be well constructed and well written. > > RFC 3552 (BCP 72) is very thorough, but kind'a long. So my succinct > thought about a Security Considerations section is that it should > describe threats to the protocol and/or the implementation, and either > ways to thwart them, or state that some threats are beyond the scope > of the threat model. While the authors of the ID have been thorough in > the rest of the specification, they may have gone a bit outside what > is needed for a Security Considerations section. Below are some > comments that the authors may wish to consider. And it's OK with me if > they disregard my comments as I think the document is Ready anyway. > > > 5.4. Security Considerations > > CML>>> I'm not sure that the following paragraph is describing a > threat or mitigation. While it is good information, perhaps it belongs > elsewhere? Or, if there's a threat there, could it be specifically > described? > > One subscription "id" can be used for two or more receivers of the > same configured subscription. But due to the possibility of > different access control permissions per receiver, it cannot be > assumed that each receiver is getting identical updates. > > It is neither a threat, nor a mitigation. It is actually > implementation guidance that different access control permissions for > different configured receivers will result in a different experience > for each receiver. If you think that this guidance is preferable > within Section 5.2 “Implementation Considerations”, we can move it there. > CML>>> I think it would be better there. > > CML>>> In the following paragraph, I think you're describing a threat > and a remedy tactic. Perhaps you could delineate them by adding, "To > counter this," as the start to the second sentence. > > With configured subscriptions, one or more publishers could be used > to overwhelm a receiver. Notification messages SHOULD NOT be sent to > any receiver which does not support this specification. Receivers > that do not want notification messages need only terminate or refuse > any transport sessions from the publisher. > > This is a good suggestion. The proposed text has been added. > > CML>>> Again, I'm not sure that the following paragraph is describing > a threat or a remedy. > > When a receiver of a configured subscription gets a new > "subscription-started" message for a known subscription where it is > already consuming events, the receiver SHOULD retrieve any event > records generated since the last event record was received. This can > be accomplish by establishing a separate dynamic replay subscription > with the same filtering criteria with the publisher, assuming the > publisher supports the "replay" feature. > > How about the following text to address your threat/remedy > comment... > CML>>> Very small changes to the below just for clarification. > > When a receiver of a configured subscription gets a new > "subscription-started" message for a known subscription where it is > already consuming events, it may indicate that an attacker has done > something that has momentarily disrupted receiver connectivity. To > acquire events lost during this interval, the receiver SHOULD retrieve > any event records generated since the last event record was received. > This can be accomplished by establishing a separate dynamic replay > subscription with the same filtering criteria with the publisher, > assuming the publisher supports the "replay" feature. > Looks good. Best regards, Chris > Eric > > The rest of the security considerations section is appropriately > describing protections for data nodes that may be susceptible to > misuse. Best regards, Chris > --------------000405090900050700080604 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Eric,

On 3/26/19 8:35 AM, Eric Voit (evoit) wrote:

Hi Chris,

 

Thanks very much for the review and comments.  Some thoughts in-line...

 

From: Chris Lonvick <lonvick.ietf@gmail.com>
Sent: Monday, March 25, 2019 9:33 PM
To: draft-ietf-netconf-subscribed-notifications.all@ietf.org; secdir@ietf.org; iesg@ietf.org
Subject: SECDIR Review of draft-ietf-netconf-subscribed-notifications

 

Hello,

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 Ready With Nits.

This is not an area that I'm very familiar with so I skimmed the draft and reviewed the Security Considerations section. Overall, the document appears to be well constructed and well written.

RFC 3552 (BCP 72) is very thorough, but kind'a long. So my succinct thought about a Security Considerations section is that it should describe threats to the protocol and/or the implementation, and either ways to thwart them, or state that some threats are beyond the scope of the threat model. While the authors of the ID have been thorough in the rest of the specification, they may have gone a bit outside what is needed for a Security Considerations section. Below are some comments that the authors may wish to consider. And it's OK with me if they disregard my comments as I think the document is Ready anyway.


5.4.  Security Considerations

CML>>> I'm not sure that the following paragraph is describing a threat or mitigation. While it is good information, perhaps it belongs elsewhere? Or, if there's a threat there, could it be specifically described? 

   One subscription "id" can be used for two or more receivers of the
   same configured subscription.  But due to the possibility of
   different access control permissions per receiver, it cannot be
   assumed that each receiver is getting identical updates.

<eric> It is neither a threat, nor a mitigation.  It is actually implementation guidance that different access control permissions for different configured receivers will result in a different experience for each receiver.  If you think that this guidance is preferable within Section 5.2 “Implementation Considerations”, we can move it there.

CML>>> I think it would be better there.

 

 

CML>>> In the following paragraph, I think you're describing a threat and a remedy tactic. Perhaps you could delineate them by adding, "To counter this," as the start to the second sentence. 

   With configured subscriptions, one or more publishers could be used
   to overwhelm a receiver.  Notification messages SHOULD NOT be sent to
   any receiver which does not support this specification.  Receivers
   that do not want notification messages need only terminate or refuse
   any transport sessions from the publisher.

<eric> This is a good suggestion.  The proposed text has been added.

 

 

CML>>> Again, I'm not sure that the following paragraph is describing a threat or a remedy. 

   When a receiver of a configured subscription gets a new
   "subscription-started" message for a known subscription where it is
   already consuming events, the receiver SHOULD retrieve any event
   records generated since the last event record was received.  This can
   be accomplish by establishing a separate dynamic replay subscription
   with the same filtering criteria with the publisher, assuming the
   publisher supports the "replay" feature.

<eric> How about the following text to address your threat/remedy comment...

 

CML>>> Very small changes to the below just for clarification.

When a receiver of a configured subscription gets a new "subscription-started" message for a known subscription where it is already consuming events, it may indicate that an attacker has done something that has momentarily disrupted receiver connectivity. To acquire events lost during this interval, the receiver SHOULD retrieve any event records generated since the last event record was received.  This can be accomplished by establishing a separate dynamic replay subscription with the same filtering criteria with the publisher, assuming the publisher supports the "replay" feature.

 

Looks good.
Best regards,
Chris

Eric

 

 

The rest of the security considerations section is appropriately describing protections for data nodes that may be susceptible to misuse. Best regards, Chris


--------------000405090900050700080604-- From nobody Fri Mar 29 13:28:53 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 7163C1202FF; Fri, 29 Mar 2019 13:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.49 X-Spam-Level: X-Spam-Status: No, score=-14.49 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_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 QhjbxQKQ-raA; Fri, 29 Mar 2019 13:28:40 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68840120302; Fri, 29 Mar 2019 13:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18336; q=dns/txt; s=iport; t=1553891320; x=1555100920; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5JRmgXGZmbGv3arILk2CFNWYChescsmd8UbQY355ZEw=; b=LHUJRi6JndHWiZLPy/kT/5SSJ9uOTgS2eY7aOwjqLYeEKaJQ7ffyT4FI wVkA5NmFvaZNp/iMI06S8UgPVX5UJ9dVu4CkUYeko2K5O2Av1dAycbi7E ZNqrhECwtIBd/nWogH1iQ/PY+t3zpqp27o0V6zkd/ZYicXmLSBxgqIrU4 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAAXf55c/49dJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDlgqgWsnjCqKe4IOCCWJOYkNhXeBew4BAYR?= =?us-ascii?q?sAoU3IjQJDQEBAwEBCQEDAm0ohUoBAQEBA3cCEAIBCBEEAQEOGgchERQJCAI?= =?us-ascii?q?EDgWCV0uBEkwDFapwH4dhDYIfgS8BhF2GVReBQD+BEScMgWF+PoIagmCFKwO?= =?us-ascii?q?KUoZPk2s2CQKHIYhygzkGGpQokwOLfQIRFYEuHziBVnAVgyeQSgFBMZBbAQE?= X-IronPort-AV: E=Sophos;i="5.60,285,1549929600"; d="scan'208,217";a="254754552" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Mar 2019 20:28:37 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x2TKSY4c002722 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Mar 2019 20:28:36 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 29 Mar 2019 16:28:33 -0400 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Fri, 29 Mar 2019 16:28:33 -0400 From: "Eric Voit (evoit)" To: Chris Lonvick CC: "draft-ietf-netconf-subscribed-notifications.all@ietf.org" , "secdir@ietf.org" , "iesg@ietf.org" Thread-Topic: SECDIR Review of draft-ietf-netconf-subscribed-notifications Thread-Index: AQHU43PW5soMZq4crkeR6IEFuDhoW6Yd3mfggAVvWgD//8dN9Q== Date: Fri, 29 Mar 2019 20:28:33 +0000 Message-ID: <1e8e012b-4917-482e-bfad-8c834e1cb503@email.android.com> References: <5C99813D.9070401@gmail.com> <56b8c323f2284ce1bee2d6083898b017@XCH-RTP-013.cisco.com>, <5C9E7742.2080701@gmail.com> In-Reply-To: <5C9E7742.2080701@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_1e8e012b4917482ebfad8c834e1cb503emailandroidcom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.152, xch-rtp-012.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [secdir] SECDIR Review of draft-ietf-netconf-subscribed-notifications 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, 29 Mar 2019 20:28:44 -0000 --_000_1e8e012b4917482ebfad8c834e1cb503emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Chris, I will make the two tweaks as you requested. Eric On Mar 29, 2019 3:51 PM, Chris Lonvick wrote: Hi Eric, On 3/26/19 8:35 AM, Eric Voit (evoit) wrote: Hi Chris, Thanks very much for the review and comments. Some thoughts in-line... From: Chris Lonvick Sent: Monday, March 25, 2019 9:33 PM To: draft-ietf-netconf-subscribed-notifications.all@ietf.org; secdir@ietf.org; iesg@ietf.org Subject: SECDIR Review of draft-ietf-netconf-subscribed-notifications Hello, 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 com= ments 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 Ready With Nits. This is not an area that I'm very familiar with so I skimmed the draft and = reviewed the Security Considerations section. Overall, the document appears= to be well constructed and well written. RFC 3552 (BCP 72) is very thorough, but kind'a long. So my succinct thought= about a Security Considerations section is that it should describe threats= to the protocol and/or the implementation, and either ways to thwart them,= or state that some threats are beyond the scope of the threat model. While= the authors of the ID have been thorough in the rest of the specification,= they may have gone a bit outside what is needed for a Security Considerati= ons section. Below are some comments that the authors may wish to consider.= And it's OK with me if they disregard my comments as I think the document = is Ready anyway. 5.4. Security Considerations CML>>> I'm not sure that the following paragraph is describing a threat or = mitigation. While it is good information, perhaps it belongs elsewhere? Or,= if there's a threat there, could it be specifically described? One subscription "id" can be used for two or more receivers of the same configured subscription. But due to the possibility of different access control permissions per receiver, it cannot be assumed that each receiver is getting identical updates. It is neither a threat, nor a mitigation. It is actually implementa= tion guidance that different access control permissions for different confi= gured receivers will result in a different experience for each receiver. I= f you think that this guidance is preferable within Section 5.2 "Implementa= tion Considerations", we can move it there. CML>>> I think it would be better there. CML>>> In the following paragraph, I think you're describing a threat and a= remedy tactic. Perhaps you could delineate them by adding, "To counter thi= s," as the start to the second sentence. With configured subscriptions, one or more publishers could be used to overwhelm a receiver. Notification messages SHOULD NOT be sent to any receiver which does not support this specification. Receivers that do not want notification messages need only terminate or refuse any transport sessions from the publisher. This is a good suggestion. The proposed text has been added. CML>>> Again, I'm not sure that the following paragraph is describing a thr= eat or a remedy. When a receiver of a configured subscription gets a new "subscription-started" message for a known subscription where it is already consuming events, the receiver SHOULD retrieve any event records generated since the last event record was received. This can be accomplish by establishing a separate dynamic replay subscription with the same filtering criteria with the publisher, assuming the publisher supports the "replay" feature. How about the following text to address your threat/remedy comment..= . CML>>> Very small changes to the below just for clarification. When a receiver of a configured subscription gets a new "subscription-start= ed" message for a known subscription where it is already consuming events, = it may indicate that an attacker has done something that has momentarily di= srupted receiver connectivity. To acquire events lost during this interval,= the receiver SHOULD retrieve any event records generated since the last ev= ent record was received. This can be accomplished by establishing a separa= te dynamic replay subscription with the same filtering criteria with the pu= blisher, assuming the publisher supports the "replay" feature. Looks good. Best regards, Chris Eric The rest of the security considerations section is appropriately describing= protections for data nodes that may be susceptible to misuse. Best regards= , Chris --_000_1e8e012b4917482ebfad8c834e1cb503emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Chris,
I will make the two tweaks as you requested.
Eric

On Mar 29, 2019 3:51 PM, Chris Lonvick <lonvi= ck.ietf@gmail.com> wrote:
Hi Eric,

On 3/26/19 8:35 AM, Eric Voit (evoit) wrote:=

Hi Chris,

 

Thanks very much fo= r the review and comments.  Some thoughts in-line...

 

From:= Chris Lonvick &= lt;lonvick.ietf@gmail.com>
Sent: Monday, March 25, 2019 9:33 PM
To: draft-ietf-netconf-subscribed-notifications.all@ietf.org; secdir@ietf.org; iesg@ietf.org
Subject: SECDIR Review of draft-ietf-netconf-subscribed-notification= s

 

Hello,

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 com= ments 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 Ready With Nits.

This is not an area that I'm very familiar with so I skimmed the draft and = reviewed the Security Considerations section. Overall, the document appears= to be well constructed and well written.

RFC 3552 (BCP 72) is very thorough, but kind'a long. So my succinct thought= about a Security Considerations section is that it should describe threats= to the protocol and/or the implementation, and either ways to thwart them,= or state that some threats are beyond the scope of the threat model. While the authors of the ID have bee= n thorough in the rest of the specification, they may have gone a bit outsi= de what is needed for a Security Considerations section. Below are some com= ments that the authors may wish to consider. And it's OK with me if they disregard my comments as I think = the document is Ready anyway.


5.4.  Security Considerations

CML>>> I'm not sure that the following para= graph is describing a threat or mitigation. While it is good information, p= erhaps it belongs elsewhere? Or, if there's a threat there, could it be spe= cifically described? 

  &n=
bsp;One subscription "id" can be used for two or more receivers o=
f the
   s=
ame configured subscription.  But due to the possibility of

   d=
ifferent access control permissions per receiver, it cannot be


   a=
ssumed that each receiver is getting identical updates.

<eric> It is = neither a threat, nor a mitigation.  It is actually implementation gui= dance that different access control permissions for different configured re= ceivers will result in a different experience for each receiver.  If you think that this guidance is preferable within = Section 5.2 “Implementation Considerations”, we can move it the= re.

CML>>> I think it would be better there.

 

 

CML>>> In the following paragraph, I think = you're describing a threat and a remedy tactic. Perhaps you could delineate= them by adding, "To counter this," as the start to the second se= ntence. 

  &n=
bsp;With configured subscriptions, one or more publishers could be used
   t=
o overwhelm a receiver.  Notification messages SHOULD NOT be sent to
   a=
ny receiver which does not support this specification.  Receivers
   t=
hat do not want notification messages need only terminate or refuse<=
/pre>

   a=
ny transport sessions from the publisher.

<eric> This i= s a good suggestion.  The proposed text has been added.

 

 

CML>>> Again, I'm not sure that the followi= ng paragraph is describing a threat or a remedy. 

  &n=
bsp;When a receiver of a configured subscription gets a new
   &=
quot;subscription-started" message for a known subscription where it i=
s
   a=
lready consuming events, the receiver SHOULD retrieve any event

   r=
ecords generated since the last event record was received.  This can


   b=
e accomplish by establishing a separate dynamic replay subscription<=
/pre>

   w=
ith the same filtering criteria with the publisher, assuming the

   p=
ublisher supports the "replay" feature.

<eric> How ab= out the following text to address your threat/remedy comment...

 

CML>>> Very small changes to the below just for clarification.

When a receiver of = a configured subscription gets a new "subscription-started" messa= ge for a known subscription where it is already consuming events, it may in= dicate that an attacker has done something that has momentarily disrupted receiver connectivity. To acquire events lost du= ring this interval, the receiver SHOULD retrieve any event records generate= d since the last event record was received.  This can be accomplished = by establishing a separate dynamic replay subscription with the same filtering criteria with the publisher, assuming= the publisher supports the "replay" feature.

 

Looks good.
Best regards,
Chris

Eric

 

 

The rest of the security considerations section is a= ppropriately describing protections for data nodes that may be susceptible = to misuse. Best regards, Chris


--_000_1e8e012b4917482ebfad8c834e1cb503emailandroidcom_-- From nobody Sat Mar 30 22:27:48 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 B79A212016C; Sat, 30 Mar 2019 22:27:37 -0700 (PDT) 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, 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 (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 cU1u_bA95oSm; Sat, 30 Mar 2019 22:27:36 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 C37D3120133; Sat, 30 Mar 2019 22:27:35 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id d18so4008682lfn.3; Sat, 30 Mar 2019 22:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=z5DG7a51QWX+so7e7QHZyQtXPPFB+yforpFxgmviSTM=; b=NoKlkpBrQvYY3+U5GbmLAez+qTExcLaSfIanJTUpwtO+4l0v6FT7h+qGuq6MXsqc0j oCfdzjpdrO6Kp3Zfh7OoA4R/RYlobUIRYP95MCBUDPIP4nlTvpwQzjPn0n1p+Ai0/vKE daZUXHbUHoACichI0LQuA5KHgrnpp3bAFkolwIBgEP29WYS6Z+9R/ZfAenQhR8ug8w8P CZY0IfE1ix7pCXIi1qoRxuuf4nFvwtZ1HOyOMWnKJDuneLZyxJq9bCTYsLQ3HtXle9Hc K5CW/VlYGbvEIcTqLe0NAniqgvskG20EBm1bUpX5VfRXZVEDQzlcHpXtK2JJOl+64Qyc 9ZUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=z5DG7a51QWX+so7e7QHZyQtXPPFB+yforpFxgmviSTM=; b=P439fOjZ45dB4aUuns0oyHEQt1F0yKbsB/IErVPM1lzFhGoy1Wvo3g1N32MW6rMh2e JzSLRaBoQZnvVy6ckAKLxZGd6EJ502gWHgQfxRDYXqjTBHeZXt7D73cVdnSxP0lZJM5T CgADVeVoD/8C/ycQ+e1YF3AziHPGcbf2lSEt49B+D55U2fh/PQnWftLVa1vKPAIxE7FW IBR8HP92yclUQD0kXSKQNkOA5+43bVH20bJl55ncDrDbJQugNfYuI+S5+VGsWNAt7zAj 7rbpH4aON4w6v2ybx70KPpQ683PpPVoBHlmJS2lM4IOApCWwZRI5fkJr8OfWDqDgGBJk FQsw== X-Gm-Message-State: APjAAAXHsSORWmaPTVpXik7tf8RWQgA0yxpd8TMjx/7R0c/jHWbsw3Wd zXk+DLW0QnO9k5NYWPZkNlShi3fBHET6nI7e8GHFQG/fkUg= X-Google-Smtp-Source: APXvYqxsJI1qFlPl6/hzoiRrYliAqe8RmdTabTntqWTnfy45tGCiKNPbWayE6Y6aBuz+SZvhCaxk5G8hleu/hygrNs8= X-Received: by 2002:ac2:44a6:: with SMTP id c6mr21228938lfm.31.1554010053845; Sat, 30 Mar 2019 22:27:33 -0700 (PDT) MIME-Version: 1.0 From: Radia Perlman Date: Sat, 30 Mar 2019 22:27:22 -0700 Message-ID: To: draft-ietf-draft-sheffer-oauth-jwt-bcp.all@ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003ca91c05855d2939" Archived-At: Subject: [secdir] Secdir review of draft-ietf-oauth-jwt-bcp-04 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, 31 Mar 2019 05:27:38 -0000 --0000000000003ca91c05855d2939 Content-Type: text/plain; charset="UTF-8" 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 is READY This document is a well-written and well-thought-through listing of best practices for using JSON web tokens. I could not find any of the advice that I disagreed with, nor could I think of any more issues that the draft could have addressed. Radia --0000000000003ca91c05855d2939 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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

The summary is READY

This document is a well-written and well-thought= -through listing of=C2=A0best practices for using JSON web tokens.=C2=A0 I = could not find any of the advice that I disagreed with, nor could I think o= f any more issues that the draft could have addressed.


Rad= ia

--0000000000003ca91c05855d2939-- From nobody Sat Mar 30 22:34:16 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 AD47412016D; Sat, 30 Mar 2019 22:34:04 -0700 (PDT) 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, 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 (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 stfBCqiLZkuN; Sat, 30 Mar 2019 22:34:03 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 95DFD120169; Sat, 30 Mar 2019 22:34:02 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id f18so5228909lja.10; Sat, 30 Mar 2019 22:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Zf+Wt3zG42Mfb+Oxxt0rCbfk7l+YA4NsvIsUiCKje6M=; b=pFVkD+wPYFOjGMPHGv1Hs323HP4z8HQCvPdq19M8qg3LFAdhcNmGyWuHNwKxSvYYz0 B5+Qr8u8R1HS/UcJEr4HXpKxJONpo2iDIROTEUdxhv1866sqpfbaNHRl5ejzz/BRIOH6 /hsAOPlPVUzY5R8OM9ncLnxfINBpi0e6JMCikvBRivyzcZYcYaoQ1WlbBgrEqnKelpf2 SACbLHJOCWXsB3Z08Lt1HEpOHSkpL/uTmmVwAziOVjsgRvVAr3wkSS8q8v4037WyrjmG cKb+gs+IHXVc7ZcQeCm1XhWwwSV+nikQMDiJSDCX8F2YjQqa4D0/0TXpeDDDI3R0XEKU Af4g== 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; bh=Zf+Wt3zG42Mfb+Oxxt0rCbfk7l+YA4NsvIsUiCKje6M=; b=p6FZY4x5yAgLI4HdZgE00zFD+o9haDmaYGDPybpghqXoda5JUp0WBEAZNXZp5xeHIl 5pmWpvTJnJFUp0lLf8wUkyIfBhlnUXxzwnW3GPMfnhWCBLzWkwpmezJQ6tUVDLi9kpyV ptMepPE2kPOM0L9ekKvuc5b9xR8z5mjz/+KU6oZd9mch5Q6zUuMbTbx7NUfMYcs3lN9d Vua5Ch2fR3WLeSesbEQvf3n/dmDVP1DI+oKNsqHBm1lSccov2LGCgnNU4/9Ha5OZGClC HF+WkBCZvm9fgAIhPklgAQeK8nP3aeynQPRjikcABcAsxhPeaZOA6RK/E3XMMlLFT58V emKA== X-Gm-Message-State: APjAAAXN3i4cEbpc6IJLR0EEX675RmcevOF2PpQ2CB55dWiXSd62Uogv 8y4o/14wRkp0d6uTswgAtuENYg5UP6CZAxjqdl4iVrek X-Google-Smtp-Source: APXvYqyq7DSsDAfJ257uG7ZY6orZjdsnEVpPvYaQUY+4iKFIAZI3ayMh4MqijmxzhS4yMg5ccte4lL2er5GyulnOW8I= X-Received: by 2002:a2e:2b04:: with SMTP id q4mr734035lje.175.1554010440739; Sat, 30 Mar 2019 22:34:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Radia Perlman Date: Sat, 30 Mar 2019 22:33:49 -0700 Message-ID: To: draft-ietf-sheffer-oauth-jwt-bcp.all@ietf.org, The IESG , secdir@ietf.org Content-Type: multipart/alternative; boundary="0000000000004c311b05855d4001" Archived-At: Subject: [secdir] Secdir review of draft-ietf-oauth-jwt-bcp-04 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, 31 Mar 2019 05:34:05 -0000 --0000000000004c311b05855d4001 Content-Type: text/plain; charset="UTF-8" Sorry...mistyped the recipients, so I'm resending ---------- Forwarded message --------- From: Radia Perlman Date: Sat, Mar 30, 2019 at 10:27 PM Subject: Secdir review of draft-ietf-oauth-jwt-bcp-04 To: , iesg@ietf.org < iesg@ietf.org>, secdir@ietf.org 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 is READY This document is a well-written and well-thought-through listing of best practices for using JSON web tokens. I could not find any of the advice that I disagreed with, nor could I think of any more issues that the draft could have addressed. Radia --0000000000004c311b05855d4001 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry...mistyped the recipients, so I'm resending
<= br>
-------= --- Forwarded message ---------
From: Radia Perlman <radiaperlman@gmail.com>
Date: Sa= t, Mar 30, 2019 at 10:27 PM
Subject: Secdir review of draft-ietf-oauth-j= wt-bcp-04
To: <draft-ietf-draft-sheffer-oauth-jwt-bcp.all@ietf.org&g= t;, iesg@ietf.org <iesg@ietf.org>, = secdir@ietf.org <secdir@ietf.org<= /a>>


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

The summary is READY

This document is a well-written and well-thought= -through listing of=C2=A0best practices for using JSON web tokens.=C2=A0 I = could not find any of the advice that I disagreed with, nor could I think o= f any more issues that the draft could have addressed.


Rad= ia

--0000000000004c311b05855d4001-- From nobody Sun Mar 31 13:02:09 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 12E7912008A; Sun, 31 Mar 2019 13:02:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir via Datatracker To: Cc: spasm@ietf.org, ietf@ietf.org, draft-ietf-lamps-pkix-shake.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Yoav Nir Message-ID: <155406252797.12369.12070204875103995275@ietfa.amsl.com> Date: Sun, 31 Mar 2019 13:02:08 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-lamps-pkix-shake-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: Sun, 31 Mar 2019 20:02:08 -0000 Reviewer: Yoav Nir 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 document is almost ready. The intent is clear and the IANA instructions are good. I have two issues with the Security Considerations section. That section has two paragraphs, and I'll start with the second one. The second paragraph has a SHOULD-level requirement to choose an ECDSA curve with an appropriate strength to match that of the hash function (SHAKE128 vs SHAKE256). This seems to me like a compliance requirement. While this is not a hard-and-fast rule, these should usually go in the body of the document, such as in section 5 rather than in security considerations. It's also puzzling why there are no similar recommendations for the strength of the RSA key. The first paragraph I find confusing. It states that the SHAKE functions are deterministic, and goes on to explain that this means that executing them on the same input will result in the same output, and that users should not expect this to be the case. Why does this need to be said? Is this not the same for any hash function? The paragraph than goes on to tell the reader that with different output lengths, the shorter ones are prefixes of the longer ones, and that this is like hash function truncation. Why do we need any of this information and why is this related to security? This is especially puzzling considering that the document fixes the output length to a specific value for each of the two functions.