From nobody Thu May 2 07:46:27 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F113512019C for ; Thu, 2 May 2019 07:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, 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 0xGyA-qHEmev for ; Thu, 2 May 2019 07:46:23 -0700 (PDT) Received: from mail-ot1-f48.google.com (mail-ot1-f48.google.com [209.85.210.48]) (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 D4E1B12013E for ; Thu, 2 May 2019 07:46:22 -0700 (PDT) Received: by mail-ot1-f48.google.com with SMTP id b1so2306401otp.5 for ; Thu, 02 May 2019 07:46:22 -0700 (PDT) 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=QgpzW1ZLOumVwKr7JP4O+7IuJzgqoKZYUmR/q4xvC7k=; b=T9L7gNuWcPuvQcd8GUVaV0k4vga8dlL1z/y/kDKitxevKkl6HT7zRSHKisD7uHzsDH wx0f4R81JCrxYlUFW10wdaFMwJrjNmRYXL7mukh1c58teF3T0nCh0hZabrN/O5dB60np Nh+3KTQYtABXr/BwYKE+emZx3mBr/ZP+uPW9LWh5JOCP0uVl8mNdfSp92LI3SyX2eg1n miB8Cs8mzi6eU/Exbc8igYAUEQfEYOUt5Px8XnBuq47L5IR7B69CmKwlY83UgqOptokf kJEsRva5Bbt4S6mum3priA5L0McDGdAMnxGYPwxTvPe9o5IAxxvEqGKc39MsDpdRCcyi KMdA== X-Gm-Message-State: APjAAAVVv8zQpcf7QxJs3QS01TLuBHNMiT4jwZB6gY8JrvfN5vzrBhUb Z2CRGy/deTslkxi1WBJ5NnxzG5kk1gBSZGcjg68= X-Google-Smtp-Source: APXvYqxkgEogSDshHPdrlEOX4dHubBSfJABCxINDs4aTBaTMxKDCaJ2LbpNBoC265LTlr1jSbOvnQ6I5huzTZoDg1sU= X-Received: by 2002:a9d:5a11:: with SMTP id v17mr2841060oth.150.1556808382162; Thu, 02 May 2019 07:46:22 -0700 (PDT) MIME-Version: 1.0 References: <155618781878.23454.9844389863110194782.idtracker@ietfa.amsl.com> <23750.56385.220502.134039@fireball.acr.fi> In-Reply-To: <23750.56385.220502.134039@fireball.acr.fi> From: Phillip Hallam-Baker Date: Thu, 2 May 2019 10:46:11 -0400 Message-ID: To: Tero Kivinen Cc: secdir-secretary@mit.edu, secdir@ietf.org Content-Type: multipart/alternative; boundary="0000000000009a2d680587e8b206" Archived-At: Subject: Re: [secdir] Assignments 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, 02 May 2019 14:46:25 -0000 --0000000000009a2d680587e8b206 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 29, 2019 at 7:13 AM Tero Kivinen wrote: > Phillip Hallam-Baker writes: > > Ooops. Just noticed that these have not been going into my action items > folder > > and I missed one. My filter must have been relying on a feature that > changed. > > I switched to use emails sent from datatracker two and half years ago, > i.e., end of 2016. Reply to, To and Subject should have been same. > > From address field did change from kivinen@iki.fi to noreply@ietf.org > in the beginning of March, because of some datatracker changes, so > that is the one that most likely caused the issue. Anyways it is > always better to use something else than From address for filtering as > the secdir secretary might change :-) > Yes, that looks like what happened. My fault of course. But what I always try to look for is what an event might tell us about the functioning of the system as a whole. Fixing things for ourselves is useful but the end goal is to improve the Internet for users as a whole. I agree simply doing S/MIME might not be enough. We might well need to engineer a new protocol for the purpose and deploy that in niche intranet environments before attempting internet deployment. For any work flow process to be useful, it would probably have to handle 50% of my tasks at the least. Which is obviously likely to be true of my employer workflow system but not the IETF data tracker except for people like me who have no employer right now. > The reply-to address of secdir-secretary@mit.edu should stay same. > > > Not really a tools team issue or critical. But it is a systemic > > problem with using SMTP mail for workflow. > > You can always see your review requests also in the datatracker by > going to the > > https://datatracker.ietf.org/accounts/review/ > > page, and also the datatracker should send you automatic email when > one is assigned to you in addition to my summary... > > One good thing about mail workflow is that I do get all the > notifications in the same place, I hate the cases where I need to go > and check through few dozen different web pages to see if there is > anything new there for me to do... > > > We have traditionally considered the killer app for S/MIME to be > > confidentiality. What if it was authentication and access control? > Signing > > meeting requests, calendar entries, task items allows people to add > things to > > my work queue. > > That would be nice, but the problem again is that you want to > configure your systems to act on certain requests differently. Whether > it is S/MIME authenticated does not really help there, you still do > not want to accept random S/MIME authenticated request to add new > entries to your calendar, so you are still left with whitelist of > people who can add items to your calendar, and when things change then > those will break... > > > Trying to retrofit might be a case of trying to balance too many > > plates on the stack though. > > Adding generic code to the datatracker that signs emails with S/MIME, > would actually be quite good enhancement, and I did make a new ticket > #2716 about this... > -- > kivinen@iki.fi > --0000000000009a2d680587e8b206 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Apr 29, 2019 at 7:13 AM Tero Kivinen <kivinen@iki.fi> wrote:
Philli= p Hallam-Baker writes:
> Ooops. Just noticed that these have not been going into my action item= s folder
> and I missed one. My filter must have been relying on a feature that c= hanged.

I switched to use emails sent from datatracker two and half years ago,
i.e., end of 2016. Reply to, To and Subject should have been same.

>From address field did change from kivinen@iki.fi to noreply@ietf.org
in the beginning of March, because of some datatracker changes, so
that is the one that most likely caused the issue. Anyways it is
always better to use something else than From address for filtering as
the secdir secretary might change :-)

<= div class=3D"gmail_default" style=3D"font-size:small">Yes, that looks like = what happened. My fault of course.

But what I always try to look for is what an event might tell us= about the functioning of the system as a whole. Fixing things for ourselve= s is useful but the end goal is to improve the Internet for users as a whol= e.

I agree simply doing S= /MIME might not be enough. We might well need to engineer a new protocol fo= r the purpose and deploy that in niche intranet environments before attempt= ing internet deployment.=C2=A0

For any work flow process to be useful, it would probably have to han= dle 50% of my tasks at the least. Which is obviously likely to be true of m= y employer workflow system but not the IETF data tracker except for people = like me who have no employer right now.


= =C2=A0
The reply-to address of secdir-secretary@mit.edu should stay same.

> Not really a tools team issue or critical. But it is a systemic
> problem with using SMTP mail for workflow.

You can always see your review requests also in the datatracker by
going to the

https://datatracker.ietf.org/accounts/review/

page, and also the datatracker should send you automatic email when
one is assigned to you in addition to my summary...

One good thing about mail workflow is that I do get all the
notifications in the same place, I hate the cases where I need to go
and check through few dozen different web pages to see if there is
anything new there for me to do...

> We have traditionally considered the killer app for S/MIME to be
> confidentiality. What if it was authentication and access control? Sig= ning
> meeting requests, calendar entries, task items allows people to add th= ings to
> my work queue.

That would be nice, but the problem again is that you want to
configure your systems to act on certain requests differently. Whether
it is S/MIME authenticated does not really help there, you still do
not want to accept random S/MIME authenticated request to add new
entries to your calendar, so you are still left with whitelist of
people who can add items to your calendar, and when things change then
those will break...

> Trying to retrofit might be a case of trying to balance too many
> plates on the stack though.

Adding generic code to the datatracker that signs emails with S/MIME,
would actually be quite good enhancement, and I did make a new ticket
#2716 about this...
--
kivinen@iki.fi
--0000000000009a2d680587e8b206-- From nobody Thu May 2 20:41: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 0BE401201D5; Thu, 2 May 2019 20:41:03 -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=outlook.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 FFZ5ozJcnMCK; Thu, 2 May 2019 20:41:00 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-oln040092010028.outbound.protection.outlook.com [40.92.10.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63D9D1201D0; Thu, 2 May 2019 20:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ovkTXwXYlRGSQ/YS1FFr2xWQWFuaXqxiNUjypO4m+aA=; b=CkzlpR7zSmenlJkVl7VYZkGUN54FvMZozQXXlP7RdZiyDadyeG5g7Q4z7Zn1WUCj0UMJ9qjoqkOoRkfnWjbSLio0EoZY6mZpe1SaeUstWM90m227bjUL5Pd+dm+ynRPWsD0DYXXyNMzy2Slas+cn9kAQ81KDA9cu/a+i0UrrXXhLJWru5hcg+dpHd9BqHVDfxoqix6y/V8KfJaszNVq26YY0rlmiwQjalSDDW5uOSrsIm/u02K7WfBKN7PZPP1/tpLs59rSq08vvJt+tT431Gz1s6QVhStyXNhcavediGXTLp+lHfN5HTuoS5+XHYCLVmUs+rBUKNaX9QgjDfR8QTg== Received: from CO1NAM04FT028.eop-NAM04.prod.protection.outlook.com (10.152.90.56) by CO1NAM04HT169.eop-NAM04.prod.protection.outlook.com (10.152.90.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1835.13; Fri, 3 May 2019 03:40:59 +0000 Received: from MWHPR04MB0367.namprd04.prod.outlook.com (10.152.90.53) by CO1NAM04FT028.mail.protection.outlook.com (10.152.90.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1835.13 via Frontend Transport; Fri, 3 May 2019 03:40:59 +0000 Received: from MWHPR04MB0367.namprd04.prod.outlook.com ([fe80::30f9:fd17:40d1:98f9]) by MWHPR04MB0367.namprd04.prod.outlook.com ([fe80::30f9:fd17:40d1:98f9%9]) with mapi id 15.20.1856.008; Fri, 3 May 2019 03:40:59 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-trans-rfc6962-bis.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-trans-rfc6962-bis-31 Thread-Index: AQHVAWHdS1kjPoUHZk6rW20pTOXzgw== Date: Fri, 3 May 2019 03:40:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:963111EC8F592F3340B141FEBEDF61E1A82A6ED8F26091F8355C1D15031E59A2; UpperCasedChecksum:A3192B3BE64721D8455D87668AC544CE26D90F5C55C9B0C132990CF214867148; SizeAsReceived:6807; Count:40 x-tmn: [07ggZCwpAJrPx5+dbu7DA4EgyHE6qQZKK8ruxT9wSEorxHYZ4IehnwV0tdiauZVB] x-ms-publictraffictype: Email x-incomingheadercount: 40 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(5050001)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031323274)(2017031324274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:CO1NAM04HT169; x-ms-traffictypediagnostic: CO1NAM04HT169: x-ms-exchange-purlcount: 1 x-microsoft-antispam-message-info: xf2EoGRHCiXv3AnstsTW2B9Y3pHi5OpCqkLu134DpyIKQvXqKgargwJMaNLKxB2WQ9gdoaUIQkq3E2wOimoV15gLLDLIh0Oh4G0QvQOL6FzO4DMxF2YDJJlG+5L+MLbA8qJF749kUSeuanC5iO158qMwx736PChU6zGqV5aQt3j4KtNRSvqBGwTdbJu5zhQP Content-Type: multipart/alternative; boundary="_000_MWHPR04MB03679D2785C09BB3A86BD970DF350MWHPR04MB0367namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 1334b1e0-902d-4742-3ebb-08d6cf79281f X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2019 03:40:59.0022 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT169 Archived-At: Subject: [secdir] Secdir review of draft-ietf-trans-rfc6962-bis-31 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, 03 May 2019 03:41:03 -0000 --_000_MWHPR04MB03679D2785C09BB3A86BD970DF350MWHPR04MB0367namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. [**Note: This review is very late and likely moot. I was a few weeks late b= ecause I was travelling, then noticed I had missed the deadline and asked T= ero whether there was any point in my reviewing this. He said "probably not= " so I didn't, but it appears writing a review is the only way to get it of= f my secdir assignment list. So this will not be up to my usual standard**] I'm a little confused by a procedural issue. RFC6962 is experimental, and t= his revision is also proposed to be experimental. I didn't think that revis= ions to experimental protocols got the designation "bis", but perhaps I was= misinformed. This is an interesting proposal for testing the validity of certificates in= the Internet PKI (in addition to CRLs, OCSP, some DNS extension, and perha= ps some others I'm forgetting), and it has functionality that overlaps with= those. **PEOPLE INTERESTED IN TECHNICAL APPROACHES TO IMPROVING THE SECURI= TY OF THE INTERNET PKI SHOULD TAKE A LOOK AT THIS APPROACH WHETHER OR NOT T= HIS PARTICULAR PROPOSAL SUCCEEDS** The idea may have been inspired by the success of block chain in other cont= exts, and proposes that all certificates that Internet users are expected t= o accept when they are presented should be published for all to see to give= people the opportunity to watch for invalid certificates being issued for = names they control so that they can complain about them. The proposal specifies the actions of a partially trusted logging service t= hat will take certificates as they are issued, sign an acknowledgement that= can optionally be placed in the certificate itself or in the TLS headers d= uring session initialization. The certificates are then placed in a Merkle = hash tree and signed. This both reduces the signing work the log server has= to do and allows it to prove that it has not removed any certificates from= its database once they are posted there. An interesting question that I did not see addressed in the I-D concerns wh= ether the list of all issued certificates is made world-readable. The syste= m assumes that the owners of particular domain names can watch for the issu= ance of bogus certificates for names they own, but many issuers do not want= to make public the complete list of certificates they have issued for the = same reason they would not want to release a complete list of DNS names the= y are using below their arc. DNS allows verification of guessed names but n= ot enumeration of all names (at least optionally). Doing the same with this= system would lose some of its security benefits, but not doing it would ma= ke it unacceptable to some issuers. --Charlie Sent from Outlook --_000_MWHPR04MB03679D2785C09BB3A86BD970DF350MWHPR04MB0367namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate's on= going effort to review all IETF documents being processed by the IESG. = ; These comments were written primarily for the benefit of the security are= a directors.  Document editors and WG chairs should treat these comments just like any other last call comments.=

[**Note: This review is very late and likely moot. I was a few weeks l= ate because I was travelling, then noticed I had missed the deadline and as= ked Tero whether there was any point in my reviewing this. He said "pr= obably not" so I didn't, but it appears writing a review is the only way to get it off my secdir assignment list. = So this will not be up to my usual standard**]

I'm a little confused by a procedural issue. RFC6962 is experimental, = and this revision is also proposed to be experimental. I didn't think that = revisions to experimental protocols got the designation "bis", bu= t perhaps I was misinformed.

This is an interesting proposal for testing the validity of certificat= es in the Internet PKI (in addition to CRLs, OCSP, some DNS extension, and = perhaps some others I'm forgetting), and it has functionality that overlaps= with those. **PEOPLE INTERESTED IN TECHNICAL APPROACHES TO IMPROVING THE SECURITY OF THE INTERNET PKI SHOU= LD TAKE A LOOK AT THIS APPROACH WHETHER OR NOT THIS PARTICULAR PROPOSAL SUC= CEEDS**

The idea may have been inspired by the success of block chain in other= contexts, and proposes that all certificates that Internet users are expec= ted to accept when they are presented should be published for all to see to= give people the opportunity to watch for invalid certificates being issued for names they control so that= they can complain about them.

The proposal specifies the actions of a partially trusted logging serv= ice that will take certificates as they are issued, sign an acknowledgement= that can optionally be placed in the certificate itself or in the TLS head= ers during session initialization. The certificates are then placed in a Merkle hash tree and signed. This bo= th reduces the signing work the log server has to do and allows it to prove= that it has not removed any certificates from its database once they are p= osted there.

An interesting question that I did not see addressed in the I-D concer= ns whether the list of all issued certificates is made world-readable. The = system assumes that the owners of particular domain names can watch for the= issuance of bogus certificates for names they own, but many issuers do not want to make public the comple= te list of certificates they have issued for the same reason they would not= want to release a complete list of DNS names they are using below their ar= c. DNS allows verification of guessed names but not enumeration of all names (at least optionally). Doing the sa= me with this system would lose some of its security benefits, but not doing= it would make it unacceptable to some issuers.

 --Charlie


Sent from Outlook

--_000_MWHPR04MB03679D2785C09BB3A86BD970DF350MWHPR04MB0367namp_-- From nobody Fri May 3 02:53: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 8A4DE1200EF for ; Fri, 3 May 2019 02:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.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, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ozSMziVCMZRX for ; Fri, 3 May 2019 02:53:38 -0700 (PDT) Received: from mail-yw1-xc2f.google.com (mail-yw1-xc2f.google.com [IPv6:2607:f8b0:4864:20::c2f]) (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 57D9512006D for ; Fri, 3 May 2019 02:53:38 -0700 (PDT) Received: by mail-yw1-xc2f.google.com with SMTP id n188so3856278ywe.2 for ; Fri, 03 May 2019 02:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S2yhi0JX8am+SBQhbZsjZusDmN1PRN6+9QrlfL7y1ek=; b=vwvu2vdwwinKKXNXLV2XGcHmVilqDLNufpC45UQoDAd0dCr2SnpbJuWBriNZd3YrkE KLriTexPb1VGwjL4/RRO0FccMb8CfVjcdrML3JnfvFI/NL0Y+q/YEBs3IO9H/k/tP8MG /KeQ2doVbtpyNsSG4pmqUt9TXJchdXVSc9s7GAOpC94Y+33R7yE9hzItXAJDSnYNVSk3 iis9vaIYHwgFa7w9QkaVURCoOkinPLKMbho4lvLQ3Cg9oDOzwMOE+w9Gjr0pywZkd7dN sFNnCnIr5or/F22QkWFxxMDDZ06AH8vylaACJkLt7lJnW2J/83NfAN255m1D3YPctthT /CTg== 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=S2yhi0JX8am+SBQhbZsjZusDmN1PRN6+9QrlfL7y1ek=; b=hXlXfPwrUS7RgjVbWElOAsJi+eMRaCCo59zlZWVHX4SygJv0uEYEKgwMB3gW/tphC9 GyQT3AbOhmXs/+bHz66PSv/l2+jTLdFfMq0R9FMlQdJiY9oblmE4b//zX11BWvydWR3Q 6lCz+HymrgjniOLBTOwMF0ZL/l4Uw36FzSZ3UhmPV3pSwM9hzbiY3ltx0iLpaYVAAmqG ipkMHBgkq62/wPN2XdGBpLtn5CLLcHBM1zrEUm4F+0MqKWiFSzyMsEVkehfKtnW07mu0 hDvxcQpdQ28vILjcJsXw3NAPEXKD+IYTeAu3bkskw+NpxbQUBmEr3fM98Jl2wvp1NUUu Kl+A== X-Gm-Message-State: APjAAAVwiHfxYkmyMqFm9FVAIYqx2ksnxJDmhU5/FYIEYkQthAYZ4aAQ pbpwMZ6Dy2bq+mMO2xVjiCQ97p+bjM6t5Hx2sRKiaA== X-Google-Smtp-Source: APXvYqwelplV3RJ5xTspvXLnIK3KL4Xn9jRzTsPSDrJSwEo1g1cCh1SynEFNgmIfr4p4wWGn3gohl6B19hs33OOh6eQ= X-Received: by 2002:a81:2556:: with SMTP id l83mr6875868ywl.300.1556877217056; Fri, 03 May 2019 02:53:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eran Messeri Date: Fri, 3 May 2019 10:53:11 +0100 Message-ID: To: Charlie Kaufman Cc: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-trans-rfc6962-bis.all@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007beac90587f8b9b5" Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-trans-rfc6962-bis-31 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, 03 May 2019 09:53:43 -0000 --0000000000007beac90587f8b9b5 Content-Type: text/plain; charset="UTF-8" A few comments in-line. On Fri, May 3, 2019 at 4:41 AM Charlie Kaufman wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > [**Note: This review is very late and likely moot. I was a few weeks late > because I was travelling, then noticed I had missed the deadline and asked > Tero whether there was any point in my reviewing this. He said "probably > not" so I didn't, but it appears writing a review is the only way to get it > off my secdir assignment list. So this will not be up to my usual > standard**] > > I'm a little confused by a procedural issue. RFC6962 is experimental, and > this revision is also proposed to be experimental. I didn't think that > revisions to experimental protocols got the designation "bis", but perhaps > I was misinformed. > 6962-bis started its life as a standards-track document, but recently (a year ago?) it was suggested we change it to an experimental-track document due to the lack of existing implementations. > > This is an interesting proposal for testing the validity of certificates > in the Internet PKI (in addition to CRLs, OCSP, some DNS extension, and > perhaps some others I'm forgetting), and it has functionality that overlaps > with those. **PEOPLE INTERESTED IN TECHNICAL APPROACHES TO IMPROVING THE > SECURITY OF THE INTERNET PKI SHOULD TAKE A LOOK AT THIS APPROACH WHETHER OR > NOT THIS PARTICULAR PROPOSAL SUCCEEDS** > FYI, Chrome has required that certificates issued by the public Certificate Authorities be logged in Certificate Transparency logs based on RFC6962 since April 2018 and has been in place for much longer for Extended Validation certificates. > > The idea may have been inspired by the success of block chain in other > contexts, and proposes that all certificates that Internet users are > expected to accept when they are presented should be published for all to > see to give people the opportunity to watch for invalid certificates being > issued for names they control so that they can complain about them. > While it was before my time on the project, to the best of my understanding, the idea was inspired by multiple instances of public CA compromise, resulting in attackers intercepting users' traffic for several high-profile web services (circa 2011), not the recent blockchain popularity. > > The proposal specifies the actions of a partially trusted logging service > that will take certificates as they are issued, sign an acknowledgement > that can optionally be placed in the certificate itself or in the TLS > headers during session initialization. The certificates are then placed in > a Merkle hash tree and signed. This both reduces the signing work the log > server has to do and allows it to prove that it has not removed any > certificates from its database once they are posted there. > > An interesting question that I did not see addressed in the I-D concerns > whether the list of all issued certificates is made world-readable. The > system assumes that the owners of particular domain names can watch for the > issuance of bogus certificates for names they own, but many issuers do not > want to make public the complete list of certificates they have issued for > the same reason they would not want to release a complete list of DNS names > they are using below their arc. DNS allows verification of guessed names > but not enumeration of all names (at least optionally). Doing the same with > this system would lose some of its security benefits, but not doing it > would make it unacceptable to some issuers. > Yes, all certificates in the log are world-readable. The topic of redaction of certain components of the DNS names have been discussed and rejected by the group as mostly too complex and having little benefit, given that there are Enterprise controls for browsers supporting Certificate Transparency to exempt certain domains from the CT enforcement requirement. > > --Charlie > > > Sent from Outlook > --0000000000007beac90587f8b9b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A few comments in-line.

On Fri, May 3, 201= 9 at 4:41 AM Charlie Kaufman <charliekaufman@outlook.com> wrote:
I have reviewed this document as part of the security directorate'= s ongoing effort to review all IETF documents being processed by the IESG.= =C2=A0 These comments were written primarily for the benefit of the securit= y area directors.=C2=A0 Document editors and WG chairs should treat these comments just like any other last call comments.=

[**Note: This review is very late and likely moot. I was a few weeks l= ate because I was travelling, then noticed I had missed the deadline and as= ked Tero whether there was any point in my reviewing this. He said "pr= obably not" so I didn't, but it appears writing a review is the only way to get it off my secdir assignment list. = So this will not be up to my usual standard**]

I'm a little confused by a procedural issue. RFC6962 is experiment= al, and this revision is also proposed to be experimental. I didn't thi= nk that revisions to experimental protocols got the designation "bis&q= uot;, but perhaps I was misinformed.
696= 2-bis started its life as a standards-track document, but recently (a year = ago?) it was suggested we change it to an experimental-track document due t= o the lack of existing implementations.=C2=A0

This is an interesting proposal for testing the validity of certificat= es in the Internet PKI (in addition to CRLs, OCSP, some DNS extension, and = perhaps some others I'm forgetting), and it has functionality that over= laps with those. **PEOPLE INTERESTED IN TECHNICAL APPROACHES TO IMPROVING THE SECURITY OF THE INTERNET PKI SHOU= LD TAKE A LOOK AT THIS APPROACH WHETHER OR NOT THIS PARTICULAR PROPOSAL SUC= CEEDS**
FYI, Chrome has required that ce= rtificates issued by the public Certificate Authorities be logged in Certif= icate Transparency logs based on RFC6962 since April 2018 and has been in p= lace for much longer for Extended Validation certificates.=C2=A0=C2=A0

The idea may have been inspired by the success of block chain in other= contexts, and proposes that all certificates that Internet users are expec= ted to accept when they are presented should be published for all to see to= give people the opportunity to watch for invalid certificates being issued for names they control so that= they can complain about them.
While it = was before my time on the project, to the best of my understanding, the ide= a was inspired by multiple instances of public CA compromise, resulting in = attackers intercepting users' traffic for several high-profile web serv= ices (circa 2011), not the recent blockchain popularity.=C2=A0

The proposal specifies the actions of a partially trusted logging serv= ice that will take certificates as they are issued, sign an acknowledgement= that can optionally be placed in the certificate itself or in the TLS head= ers during session initialization. The certificates are then placed in a Merkle hash tree and signed. This bo= th reduces the signing work the log server has to do and allows it to prove= that it has not removed any certificates from its database once they are p= osted there.

An interesting question that I did not see addressed in the I-D concer= ns whether the list of all issued certificates is made world-readable. The = system assumes that the owners of particular domain names can watch for the= issuance of bogus certificates for names they own, but many issuers do not want to make public the comple= te list of certificates they have issued for the same reason they would not= want to release a complete list of DNS names they are using below their ar= c. DNS allows verification of guessed names but not enumeration of all names (at least optionally). Doing the sa= me with this system would lose some of its security benefits, but not doing= it would make it unacceptable to some issuers.
Yes, all certificates in the log are world-readable. The topic of r= edaction of certain components of the DNS names have been discussed and rej= ected by the group as mostly too complex and having little benefit, given t= hat there are Enterprise controls for browsers supporting Certificate Trans= parency to exempt certain domains from the CT enforcement requirement.

=C2=A0--Charlie


Sent from Outlook=

--0000000000007beac90587f8b9b5-- From nobody Fri May 3 09:36:36 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB971202A6; Fri, 3 May 2019 09:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1556901333; bh=9doR6MIHrpg3cnVOiwOQfUiXnzH0DCz+e44iTZz47BE=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=ZXm0fUPFvH+D14NVptTfMUKpx5dIqyB36z9+AapjIs2Wru3gaw/q9KU0Ta48uYGUJ de3jpYHzLZ3/aEcnYBwuMfGQqzw6t4hW6+XDFKVq3xzC7o+UGYtnNwigwrxSEu6xVb sbiJF2kg8yCN++Og78YDoqshjHWyRMrTcDctVD6A= X-Mailbox-Line: From new-work-bounces@ietf.org Fri May 3 09:35:26 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FDE12028F; Fri, 3 May 2019 09:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1556901326; bh=9doR6MIHrpg3cnVOiwOQfUiXnzH0DCz+e44iTZz47BE=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=rGixNsAX1U/3vS7cApSxPQZXHo4tXjCaMgr9FGRS9cyzt9eLkFeVv7oSYVNi52/11 lwQCuEsEPemDjwTpyteXOd3dCHqdmRO8Kt9RaYgnLjyiRsXH0Mvo7e+l2Sc01qPHON DRIhYLtFefECq56bs+eiHRHpr6XtcbPDqPPKiMGY= 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 A2A94120252 for ; Fri, 3 May 2019 09:35:17 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply_to: MIME-Version: 1.0 Message-ID: <155690131765.7122.6994505699537633938.idtracker@ietfa.amsl.com> Date: Fri, 03 May 2019 09:35:17 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 03 May 2019 09:36:34 -0700 Subject: [secdir] [new-work] WG Review: Limited Additional Mechanisms for PKIX and SMIME (lamps) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 16:35:41 -0000 The Limited Additional Mechanisms for PKIX and SMIME (lamps) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2019-05-13. Limited Additional Mechanisms for PKIX and SMIME (lamps) ----------------------------------------------------------------------- Current status: Active WG Chairs: Russ Housley Tim Hollebeek Assigned Area Director: Roman Danyliw Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: spasm@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/spasm Archive: https://mailarchive.ietf.org/arch/browse/spasm/ Group page: https://datatracker.ietf.org/group/lamps/ Charter: https://datatracker.ietf.org/doc/charter-ietf-lamps/ The PKIX and S/MIME Working Groups have been closed for some time. Some updates have been proposed to the X.509 certificate documents produced by the PKIX Working Group and the electronic mail security documents produced by the S/MIME Working Group. The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working Group is chartered to make updates where there is a known constituency interested in real deployment and there is at least one sufficiently well specified approach to the update so that the working group can sensibly evaluate whether to adopt a proposal. The LAMPS WG is now tackling these topics: 1. Specify a discovery mechanism for CAA records to replace the one described in RFC 6844. Implementation experience has demonstrated an ambiguity in the handling of CNAME and DNAME records during discovery in RFC 6844, and subsequent discussion has suggested that a different discovery approach would resolve limitations inherent in the approach used in RFC 6844. 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME. Unlike the previous hashing standards, the SHA-3 family of functions are the outcome of an open competition. They have a clear design rationale and have received a lot of public analysis, giving great confidence that the SHA-3 family of functions are secure. Also, since SHA-3 uses a very different construction from SHA-2, the SHA-3 family of functions offers an excellent alternative. In particular, SHAKE128/256 and SHAKE256/512 offer security and performance benefits. 3. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority. Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information. As a result, revoking short-lived certificates is unnecessary and pointless. 4. Specify the use of a pre-shared key (PSK) along with other key management techniques with supported by the Cryptographic Message Syntax (CMS) as a mechanism to protect present day communication from the future invention of a large-scale quantum computer. The invention of a large-scale quantum computer poses a serious challenge for the key management algorithms that are widely deployed today, especially the key transport and key agreement algorithms used today with the CMS to protect S/MIME messages. 5. Specify the use of hash-based signatures with the Cryptographic Message Syntax (CMS). Hash-based signature use small private and public keys, and they have low computational cost; however, the signature values are quite large. For this reason they might not be used for signing X.509 certificates or S/MIME messages; however, since hash-based signature algorithms are secure even if a large-scale quantum computer is invented. The low computational cost for signature verification makes hash-based signatures attractive in the Internt of Things environments, and the quantum resistance makes them attractive for the distribution of software updates. 6. Specify a certificate extension that is carried in a self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate, to identify the next public key that will be used by the trust anchor. 7. Update the specification for the cryptographic protection of email headers -- both for signatures and encryption -- to improve the implementation situation with respect to privacy, security, usability and interoperability in cryptographically-protected electronic mail. Most current implementations of cryptographically-protected electronic mail protect only the body of the message, which leaves significant room for attacks against otherwise-protected messages. In addition, the LAMPS WG may investigate other updates to documents produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt any of these potential work items without rechartering. Milestones: Jun 2018 - Adopt a draft for short-lived certificate conventions Jun 2018 - Adopt a draft for the CMS with PSK Jun 2018 - Adopt a draft for hash-based signatures with the CMS Jun 2018 - Adopt a draft for root key rollover certificate extension Jul 2018 - rfc6844bis sent to IESG for standards track publication Aug 2018 - Root key rollover certificate extension sent to IESG for informational publication Sep 2018 - SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for standards track publication Sep 2018 - SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for standards track publication Oct 2018 - Short-lived certificate conventions sent to IESG for BCP publication Oct 2018 - The CMS with PSK sent to IESG for standards track publication Dec 2018 - Hash-based signatures with the CMS sent to IESG for standards track publication _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri May 3 10:14: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 ADAFC12028E; Fri, 3 May 2019 10:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xRuivy7FQxmt; Fri, 3 May 2019 10:14:20 -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 97F101202B1; Fri, 3 May 2019 10:14:16 -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 x43HE7ZD003228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 3 May 2019 13:14:09 -0400 Date: Fri, 3 May 2019 12:14:07 -0500 From: Benjamin Kaduk To: Stephen Farrell Cc: secdir@ietf.org, draft-ietf-dots-signal-channel.all@ietf.org, ietf@ietf.org, dots@ietf.org Message-ID: <20190503171406.GO59871@kduck.mit.edu> References: <155533088202.10777.9128855796755282458@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <155533088202.10777.9128855796755282458@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-dots-signal-channel-31 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, 03 May 2019 17:14:22 -0000 On Mon, Apr 15, 2019 at 05:21:22AM -0700, Stephen Farrell via Datatracker wrote: > Reviewer: Stephen Farrell > Review result: Has Issues > > I took a look at the changes between -30 and -31 and at the mail > following my earlier review of -30. > > To explain the "has issues" status for this review: Generally, I > think this is probably ok, but I (still) have the concerns listed > below that the ADs might wanna think about. The authors already > responded on each of these points, and made some corresponding > changes, so I guess they reckon these are non-issues. (Which is of > course fine - even if I don't quite agree, I'm often wrong:-) > > - p13: The cuid still seems to me to be too static (there's a > SHOULD saying to tie it to the client certificate public key > or an equivalent). I still think recommending a way to generate > an identifier that isn't tied to a key pair would be 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 without mapping 1:1 to possibly long-lived key > pairs. (-31 does say some more about how to change cuid, but still > has the same SHOULD/RECOMMENDED way to generate cuid values.) IIUC, if there are no gateways involved, anything that sees a cuid is also seeing the device's client certificate, so to a large extent the use as a long-lived identifier is pretty similar. Server-domain gateways are supposedly just for the convenience of the operator and considered equally trusted to the actual server, so I think this would only come into play when a client-side gateway is in use. (I don't know how common that will be.) > - I wondered if a bad actor in control of an authorised DOTS > client colluding with the controller of a DDoS attack could use > this protocol to probe the network to see how their attack is > going and change the attack to be more effective. In mail, the > authors stated that this isn't possible, and added text saying > that to -31. That may be true, but I'm not sure (given the > complexity of the protocol). I don't think anyone responded on this yet, so I'd like to get the sense of the authors. My personal take is that the status updates are only for the efficacy of mitigations requested by this client, so (in this scenario) while you can tell how much of your attack is being blocked, you may not be able to learn how much is making through and adapt to increase the amount making it through. I suppose if you didn't know how big of a cannon you have, this could provide a way to get some metrics, but at the cost of rendering the ongoing attack ineffective, and probably revealing the compromised nature of the DOTS client. > A nit: > > - p91: The mention of TCP-AO seems to require suspension of > disbelief (given the lack of deployment of TCP-AO). If we don't > think it'll be used, it'd be better to not pretend it might get > used. The authors should respond to this as well. Thanks for the re-review and follow-up discussion! -Ben From nobody Fri May 3 14:14: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 E34C51200B4 for ; Fri, 3 May 2019 14:14:55 -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.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <155691809592.7249.6781158475387668346.idtracker@ietfa.amsl.com> Date: Fri, 03 May 2019 14:14:55 -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, 03 May 2019 21:14:56 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-05-16 Reviewer LC end Draft Charlie Kaufman R2018-12-24 draft-ietf-6lo-deadline-time-04 Tim Polk 2019-04-17 draft-ietf-isis-segment-routing-extensions-24 Vincent Roca R2019-02-13 draft-ietf-perc-private-media-framework-10 Last calls: Reviewer LC end Draft Derek Atkins 2019-03-03 draft-ietf-netmod-module-tags-08 Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-28 Daniel Franke 2019-03-18 draft-ietf-sidrops-https-tal-08 Daniel Gillmor 2018-03-19 draft-gutmann-scep-13 Catherine Meadows 2019-04-12 draft-ietf-mmusic-rfc4566bis-34 Matthew Miller 2019-04-08 draft-ietf-core-multipart-ct-03 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-08 Stefan Santesson 2019-05-08 draft-ietf-lamps-rfc6844bis-05 Melinda Shore R2019-05-15 draft-ietf-teas-yang-te-topo-20 Valery Smyslov 2019-05-16 draft-ietf-teas-yang-te-types-09 Sean Turner 2019-05-16 draft-ietf-sipbrandy-osrtp-09 Carl Wallace 2019-05-13 draft-ietf-tsvwg-tinymt32-01 David Waltermire 2019-02-15 draft-ietf-rtcweb-ip-handling-11 Samuel Weiler 2019-05-13 draft-ietf-grow-wkc-behavior-03 Klaas Wierenga 2019-02-26 draft-ietf-mpls-sr-over-ip-04 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 Kathleen Moriarty 2019-04-08 draft-ietf-bmwg-ngfw-performance-00 Next in the reviewer rotation: Brian Weis Klaas Wierenga Christopher Wood Paul Wouters Liang Xia Taylor Yu Dacheng Zhang Derek Atkins John Bradley Nancy Cam-Winget From nobody Fri May 3 18:18: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 4D3DE1202F7; Fri, 3 May 2019 18:18: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=outlook.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 XKjjcWEuNGWT; Fri, 3 May 2019 18:18:31 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-oln040092010032.outbound.protection.outlook.com [40.92.10.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6EF4120116; Fri, 3 May 2019 18:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Xrss5aYs9ENmkZJyrCKxnqqC53zAIA5bSoaXbKDnnjs=; b=K46RlXYAXxxTLHvVuWQHUyx7T59wkuaALANaMK3tSig9tQJTIUe34EL5ThqLlpBtR+xGQLXjXSk1i2Qe7nYzsCB0L2qw3jcE0uQdKCKuaGqTK/kvZ3biTnxrKlFQQBe6AfHgmgSf7Y/+gvDXMuX+XziPFtMOYZ+U5EPpfLdRJTPd+QKetYC8zdhy3VmRlC+YbhYWc0xkE9/yY0zCVn61mX/war5bcIcsbRaFX4NKh7dr+MUfnfs6phCf+H7CAUZK41P5H0/kD8qQ4C9i4NC3xf3NvT+3lrm+TljsHu0+2M93VzDumqbR+XXx1MuXJiGsVV+pgAzz939dutMfZIqpfA== Received: from SN1NAM04FT037.eop-NAM04.prod.protection.outlook.com (10.152.88.51) by SN1NAM04HT048.eop-NAM04.prod.protection.outlook.com (10.152.89.42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1835.13; Sat, 4 May 2019 01:18:29 +0000 Received: from MWHPR04MB0367.namprd04.prod.outlook.com (10.152.88.60) by SN1NAM04FT037.mail.protection.outlook.com (10.152.88.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1835.13 via Frontend Transport; Sat, 4 May 2019 01:18:29 +0000 Received: from MWHPR04MB0367.namprd04.prod.outlook.com ([fe80::30f9:fd17:40d1:98f9]) by MWHPR04MB0367.namprd04.prod.outlook.com ([fe80::30f9:fd17:40d1:98f9%9]) with mapi id 15.20.1856.008; Sat, 4 May 2019 01:18:29 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-6lo-deadline-time.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-6lo-deadline-time-04 Thread-Index: AQHVAhcw5kia49XGcEu0uXmSnWTn2g== Date: Sat, 4 May 2019 01:18:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:EB25E3C71EA31E4D2021CC96FBC5F4BF0316F29E5F52A31194FE3A6CC1677713; UpperCasedChecksum:B5FDEA39E31CC2403413D834756A82CE075366D9B509D5788E2D5AB754222822; SizeAsReceived:6798; Count:40 x-tmn: [QnhHKsakoWxzVH3UnkTWztt4d9nl0zHtx/DYFBgfVkZwPoby3XLnRKRfW1FMVGtO] x-ms-publictraffictype: Email x-incomingheadercount: 40 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(5050001)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031323274)(2017031324274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:SN1NAM04HT048; x-ms-traffictypediagnostic: SN1NAM04HT048: x-ms-exchange-purlcount: 1 x-microsoft-antispam-message-info: oY+s7NUclezQK2ryXevdFw/xIyBYm6oNOi3rAEmCqXw64M9rNl+vDIlF6OYNI7GkYQpnIeGyVsjTNO7MqN0WejkP1n5FW6+r6IOeA4KyFdqaG0Xsc7JyXT+ETd/FK9jCGVSBvcCsS17EiwNnNhBcZgXO5uBHHUh1I+XSYqSHUOrPvdoThhC77p3fWXM8Pe0j Content-Type: multipart/alternative; boundary="_000_MWHPR04MB0367E2E63CE45D19F9215119DF360MWHPR04MB0367namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 0db42b88-ef73-41dd-f50e-08d6d02e6ac9 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2019 01:18:29.6996 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM04HT048 Archived-At: Subject: [secdir] Secdir review of draft-ietf-6lo-deadline-time-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, 04 May 2019 01:18:33 -0000 --_000_MWHPR04MB0367E2E63CE45D19F9215119DF360MWHPR04MB0367namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document specifies a new optional header in the routing header of pack= ets carried over LLNs (Low Power and Lossy Networks). This new header speci= fies a delivery deadline for packets, and the spec describes how a router i= s supposed to modify the field when the packet crosses between synchronized= time domains. There really aren't any security implications to a feature like this, thoug= h depending on how routers adjust their scheduling based on the values in t= his field, there might be opportunities for network nodes to mount more eff= ective denial of service attacks or to get themselves better service than t= hey might be entitled to. Since this document does not specify the scheduli= ng algorithms, it's probably not appropriate for it to worry about possible= weaknesses in those algorithms. --Charlie Sent from Outlook --_000_MWHPR04MB0367E2E63CE45D19F9215119DF360MWHPR04MB0367namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate's on= going effort to review all IETF documents being processed by the IESG. = ; These comments were written primarily for the benefit of the security are= a directors.  Document editors and WG chairs should treat these comments just like any other last call comments.=

This document specifies a new optional header in the routing header of= packets carried over LLNs (Low Power and Lossy Networks). This new header = specifies a delivery deadline for packets, and the spec describes how a rou= ter is supposed to modify the field when the packet crosses between synchronized time domains.

There really aren't any security implications to a feature like this, = though depending on how routers adjust their scheduling based on the values= in this field, there might be opportunities for network nodes to mount mor= e effective denial of service attacks or to get themselves better service than they might be entitled to. Since = this document does not specify the scheduling algorithms, it's probably not= appropriate for it to worry about possible weaknesses in those algorithms.=

 --Charlie


Sent from Outlook

--_000_MWHPR04MB0367E2E63CE45D19F9215119DF360MWHPR04MB0367namp_-- From nobody Sat May 4 01:41: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 EC56C12026E; Sat, 4 May 2019 01:40:56 -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 cjEj9LyiaIcL; Sat, 4 May 2019 01:40:54 -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 1349E120269; Sat, 4 May 2019 01:40:53 -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=1556958855; 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-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: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-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=m RnMtrYsr+4HzsgFeS4j5BoRKXJRvftPlAgjoAOc+L o=; b=EjJy1xLFUuJ/U+xrJFqLcNQMCGw1UbnycFsXQbIxXM2K WBytf6sV5VUh5i+3DkoT/eV3hjnMs4rMu5OsrashBTFyVJCazn d2T5eAMGDVyQEEno6+vIJLDsizUeDyuThjMIy6CHTWqPNrQ3y4 chamulHjSddc9RAU5v1Tab5kIyQ= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 14a5_a409_d6cc8eb0_7dc4_496b_a9b2_f1d4be959618; Sat, 04 May 2019 02:34:14 -0600 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 4 May 2019 02:40:34 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Sat, 4 May 2019 02:40:34 -0600 Received: from NAM02-BL2-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; Sat, 4 May 2019 02:40:32 -0600 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2613.namprd16.prod.outlook.com (20.177.227.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.12; Sat, 4 May 2019 08:40:31 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62%5]) with mapi id 15.20.1835.018; Sat, 4 May 2019 08:40:31 +0000 From: "Konda, Tirumaleswar Reddy" To: Benjamin Kaduk , Stephen Farrell CC: "dots@ietf.org" , "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Thread-Topic: [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31 Thread-Index: AQHU84Xn3S97Pb+WW0CNvO8JFIRGL6ZZwC+AgAD4aJA= Date: Sat, 4 May 2019 08:40:30 +0000 Message-ID: References: <155533088202.10777.9128855796755282458@ietfa.amsl.com> <20190503171406.GO59871@kduck.mit.edu> In-Reply-To: <20190503171406.GO59871@kduck.mit.edu> 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.205.191] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0b4c4b61-4e54-4575-690d-08d6d06c2ac7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR16MB2613; x-ms-traffictypediagnostic: BYAPR16MB2613: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0027ED21E7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(39840400004)(136003)(346002)(376002)(32952001)(189003)(199004)(51914003)(13464003)(2906002)(966005)(6306002)(14454004)(6246003)(66446008)(9686003)(305945005)(478600001)(73956011)(66946007)(86362001)(68736007)(76176011)(6436002)(7736002)(5024004)(25786009)(256004)(14444005)(5660300002)(53936002)(55016002)(72206003)(66476007)(66556008)(99286004)(64756008)(7696005)(66066001)(74316002)(2171002)(8676002)(229853002)(76116006)(476003)(110136005)(11346002)(80792005)(486006)(8936002)(54906003)(33656002)(316002)(446003)(102836004)(6116002)(3846002)(6506007)(26005)(52536014)(81156014)(81166006)(4326008)(71200400001)(53546011)(186003)(71190400001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2613; H:BYAPR16MB2790.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: sbf8i6PVa1UyuJRJhFnDYPUu0qyzgSYZR2lGAEsmRXjhrstfncL1Y7GaZNoR0/xDwdvVlQr2uHGhzL5Lswdn5bPt5CIJ4t13mjsF2yH22+ULMvBBu1C81OMUr223nGDCeq5Gc7zQeby0NBadiHaNtA6rUu/YDAuN+oc9X60o3cCAP9WX0eF9TQQefr2CkbLCqKuKlSIxtfLkKSGSwP9kWpbVN/OtdlwkvrmqVGHaMaQLULhk0PoQm00pHT9LFdZllzF86H6NgUTWNfBFnR/0+kRsATsGQb8tSI6jdWjNFuWLtQ7OrRM+d5aCS7Kvs782rMc7JcsUMTF8Z+6FTMid0tSOzwV7kYm2trUAtJpGGsGFGC9RHKs/5tWkNpU1tZnEwh8oCUZYzmfBiyWCgBEN7nQwBOX+UIWS4+vfPjcbzdA= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0b4c4b61-4e54-4575-690d-08d6d06c2ac7 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2019 08:40:31.0879 (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: BYAPR16MB2613 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6539> : inlines <7072> : streams <1820529> : uri <2840373> Archived-At: Subject: Re: [secdir] [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31 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, 04 May 2019 08:40:57 -0000 > -----Original Message----- > From: Dots On Behalf Of Benjamin Kaduk > Sent: Friday, May 3, 2019 10:44 PM > To: Stephen Farrell > Cc: dots@ietf.org; draft-ietf-dots-signal-channel.all@ietf.org; ietf@ietf= .org; > secdir@ietf.org > Subject: Re: [Dots] Secdir telechat review of draft-ietf-dots-signal-chan= nel-31 >=20 > This email originated from outside of the organization. Do not click link= s or > open attachments unless you recognize the sender and know the content is > safe. >=20 > On Mon, Apr 15, 2019 at 05:21:22AM -0700, Stephen Farrell via Datatracker > wrote: > > Reviewer: Stephen Farrell > > Review result: Has Issues > > > > I took a look at the changes between -30 and -31 and at the mail > > following my earlier review of -30. > > > > To explain the "has issues" status for this review: Generally, I think > > this is probably ok, but I (still) have the concerns listed below that > > the ADs might wanna think about. The authors already responded on each > > of these points, and made some corresponding changes, so I guess they > > reckon these are non-issues. (Which is of course fine - even if I > > don't quite agree, I'm often wrong:-) > > > > - p13: The cuid still seems to me to be too static (there's a SHOULD > > saying to tie it to the client certificate public key or an > > equivalent). I still think recommending a way to generate an > > identifier that isn't tied to a key pair would be 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 without mapping 1:1 to possibly long-lived key pairs. (-31 > > does say some more about how to change cuid, but still has the same > > SHOULD/RECOMMENDED way to generate cuid values.) >=20 > IIUC, if there are no gateways involved, anything that sees a cuid is als= o > seeing the device's client certificate, so to a large extent the use as a= long- > lived identifier is pretty similar. Server-domain gateways are supposedl= y just > for the convenience of the operator and considered equally trusted to the > actual server, so I think this would only come into play when a client-si= de > gateway is in use. (I don't know how common that will > be.) As per the discussion with Stephen https://mailarchive.ietf.org/arch/msg/do= ts/H5JG69FJruwN7pM3j92L8wwtn-s, we have added "Appendix A. CUID Generation"= and updated section 10 (please see the diff at=20 https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/wdi= ff%20draft-ietf-dots-signal-channel-31.txt%20draft-ietf-dots-signal-channel= -31.pdf)=20 >=20 > > - I wondered if a bad actor in control of an authorised DOTS client > > colluding with the controller of a DDoS attack could use this protocol > > to probe the network to see how their attack is going and change the > > attack to be more effective. In mail, the authors stated that this > > isn't possible, and added text saying that to -31. That may be true, > > but I'm not sure (given the complexity of the protocol). >=20 > I don't think anyone responded on this yet, so I'd like to get the sense = of the > authors. >=20 > My personal take is that the status updates are only for the efficacy of > mitigations requested by this client, so (in this scenario) while you can= tell > how much of your attack is being blocked, you may not be able to learn ho= w > much is making through and adapt to increase the amount making it through= . > I suppose if you didn't know how big of a cannon you have, this could pro= vide > a way to get some metrics, but at the cost of rendering the ongoing attac= k > ineffective, and probably revealing the compromised nature of the DOTS > client. This comment was discussed and resolved by adding the following lines: A DOTS client is entitled to access only to resources it creates. In=09 particular, a DOTS client cannot retrieve data related to mitigation=09 requests created by other DOTS clients of the same DOTS client=09 domain. Further, the draft points to DOTS security considerations discussed in DOTS= requirements draft which says the following: To detect compromised DOTS agents, DOTS operators should carefully monitor and audit DOTS agents to detect misbehavior and to deter misuse, while employing current secure network communications best practices to reduce attack surface. >=20 > > A nit: > > > > - p91: The mention of TCP-AO seems to require suspension of disbelief > > (given the lack of deployment of TCP-AO). If we don't think it'll be > > used, it'd be better to not pretend it might get used. >=20 > The authors should respond to this as well. We can update the use of TCP-AO as follows: Although not widely adopted, if TCP-AO is used, then any bogus packets inje= cted by an attacker will be rejected by the TCP-AO integrity check and therefore will never reach the TLS layer. Cheers, -Tiru >=20 > Thanks for the re-review and follow-up discussion! >=20 > -Ben >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon May 6 08:35: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 DFECA12006D; Mon, 6 May 2019 08:35:23 -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 1mBQIvQ-DzP7; Mon, 6 May 2019 08:35:21 -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 1E32D120047; Mon, 6 May 2019 08:35:20 -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 x46FZDTI011431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 May 2019 11:35:15 -0400 Date: Mon, 6 May 2019 10:35:13 -0500 From: Benjamin Kaduk To: "Konda, Tirumaleswar Reddy" Cc: Stephen Farrell , "dots@ietf.org" , "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Message-ID: <20190506153513.GD19509@kduck.mit.edu> References: <155533088202.10777.9128855796755282458@ietfa.amsl.com> <20190503171406.GO59871@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) Archived-At: Subject: Re: [secdir] [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31 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, 06 May 2019 15:35:24 -0000 On Sat, May 04, 2019 at 08:40:30AM +0000, Konda, Tirumaleswar Reddy wrote: > > -----Original Message----- > > From: Dots On Behalf Of Benjamin Kaduk > > Sent: Friday, May 3, 2019 10:44 PM > > To: Stephen Farrell > > Cc: dots@ietf.org; draft-ietf-dots-signal-channel.all@ietf.org; ietf@ietf.org; > > secdir@ietf.org > > Subject: Re: [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31 > > > > This email originated from outside of the organization. Do not click links or > > open attachments unless you recognize the sender and know the content is > > safe. > > > > On Mon, Apr 15, 2019 at 05:21:22AM -0700, Stephen Farrell via Datatracker > > wrote: > > > Reviewer: Stephen Farrell > > > Review result: Has Issues > > > > > > I took a look at the changes between -30 and -31 and at the mail > > > following my earlier review of -30. > > > > > > To explain the "has issues" status for this review: Generally, I think > > > this is probably ok, but I (still) have the concerns listed below that > > > the ADs might wanna think about. The authors already responded on each > > > of these points, and made some corresponding changes, so I guess they > > > reckon these are non-issues. (Which is of course fine - even if I > > > don't quite agree, I'm often wrong:-) > > > > > > - p13: The cuid still seems to me to be too static (there's a SHOULD > > > saying to tie it to the client certificate public key or an > > > equivalent). I still think recommending a way to generate an > > > identifier that isn't tied to a key pair would be 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 without mapping 1:1 to possibly long-lived key pairs. (-31 > > > does say some more about how to change cuid, but still has the same > > > SHOULD/RECOMMENDED way to generate cuid values.) > > > > IIUC, if there are no gateways involved, anything that sees a cuid is also > > seeing the device's client certificate, so to a large extent the use as a long- > > lived identifier is pretty similar. Server-domain gateways are supposedly just > > for the convenience of the operator and considered equally trusted to the > > actual server, so I think this would only come into play when a client-side > > gateway is in use. (I don't know how common that will > > be.) > > As per the discussion with Stephen https://mailarchive.ietf.org/arch/msg/dots/H5JG69FJruwN7pM3j92L8wwtn-s, we have added "Appendix A. CUID Generation" and updated section 10 (please see the diff at > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/wdiff%20draft-ietf-dots-signal-channel-31.txt%20draft-ietf-dots-signal-channel-31.pdf) I don't really see Stephen getting convinced, in that linked discussion. (Also, the added Appendix A in the linked diff is past the 50-page boundary that github loads by default, and it's failing to load more, for me.) > > > > > > - I wondered if a bad actor in control of an authorised DOTS client > > > colluding with the controller of a DDoS attack could use this protocol > > > to probe the network to see how their attack is going and change the > > > attack to be more effective. In mail, the authors stated that this > > > isn't possible, and added text saying that to -31. That may be true, > > > but I'm not sure (given the complexity of the protocol). > > > > I don't think anyone responded on this yet, so I'd like to get the sense of the > > authors. > > > > My personal take is that the status updates are only for the efficacy of > > mitigations requested by this client, so (in this scenario) while you can tell > > how much of your attack is being blocked, you may not be able to learn how > > much is making through and adapt to increase the amount making it through. > > I suppose if you didn't know how big of a cannon you have, this could provide > > a way to get some metrics, but at the cost of rendering the ongoing attack > > ineffective, and probably revealing the compromised nature of the DOTS > > client. > > This comment was discussed and resolved by adding the following lines: > A DOTS client is entitled to access only to resources it creates. In > particular, a DOTS client cannot retrieve data related to mitigation > requests created by other DOTS clients of the same DOTS client > domain. This is good to have, but I think Stephen is still within his rights to ask for text that explicitly considers what the scope of damage is when there is a compromised DOTS client. > Further, the draft points to DOTS security considerations discussed in DOTS requirements draft which says the following: > > To detect compromised DOTS agents, DOTS operators should carefully > monitor and audit DOTS agents to detect misbehavior and to deter > misuse, while employing current secure network communications best > practices to reduce attack surface. > > > > > > A nit: > > > > > > - p91: The mention of TCP-AO seems to require suspension of disbelief > > > (given the lack of deployment of TCP-AO). If we don't think it'll be > > > used, it'd be better to not pretend it might get used. > > > > The authors should respond to this as well. > > We can update the use of TCP-AO as follows: > > Although not widely adopted, if TCP-AO is used, then any bogus packets injected by an attacker will be rejected by the > TCP-AO integrity check and therefore will never reach the TLS layer. Okay. -Ben From nobody Tue May 7 00:31: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 BEEE31201EE; Tue, 7 May 2019 00:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 jZThqxwGe2gZ; Tue, 7 May 2019 00:30:43 -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 123AE120228; Tue, 7 May 2019 00:30:41 -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=1557213838; 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-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: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=LZxQKFfR22kU2j4BEnE6hBDFQiJX9o54eisVRe QIW/c=; b=IJi1T9YLxLbMeaFTkPHgZd5FcRj29KunAHe1xHwM Ef11W2X63/HzN7KE62FcDUFFzsdIUb2MWkvzSspPMpMM5vL/+e +0rvKJlfmJXYCcYEAEeNhhE6UuLwv/At8rlKDzPFQgBvTdUNMo 72AxbuDArenAGJI+CcMJff/rHXOpdoE= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5288_0fb3_186ceb79_bfc7_48b4_aef9_763a9779f040; Tue, 07 May 2019 01:23:57 -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; Tue, 7 May 2019 01:30:13 -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; Tue, 7 May 2019 01:30:13 -0600 Received: from NAM05-CO1-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; Tue, 7 May 2019 01:30:12 -0600 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2502.namprd16.prod.outlook.com (20.177.224.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.15; Tue, 7 May 2019 07:30:11 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::8921:8f4d:4710:4379]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::8921:8f4d:4710:4379%2]) with mapi id 15.20.1856.012; Tue, 7 May 2019 07:30:11 +0000 From: "Konda, Tirumaleswar Reddy" To: Benjamin Kaduk CC: Stephen Farrell , "dots@ietf.org" , "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Thread-Topic: [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31 Thread-Index: AQHU84Xn3S97Pb+WW0CNvO8JFIRGL6ZZwC+AgAD4aJCAA6L0gIABAsoQ Date: Tue, 7 May 2019 07:30:11 +0000 Message-ID: References: <155533088202.10777.9128855796755282458@ietfa.amsl.com> <20190503171406.GO59871@kduck.mit.edu> <20190506153513.GD19509@kduck.mit.edu> In-Reply-To: <20190506153513.GD19509@kduck.mit.edu> 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: 6aaafb9c-213b-4943-d7d3-08d6d2bdd6c0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR16MB2502; x-ms-traffictypediagnostic: BYAPR16MB2502: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0030839EEE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(39860400002)(396003)(376002)(136003)(189003)(32952001)(13464003)(199004)(74316002)(3846002)(6116002)(80792005)(9686003)(6306002)(55016002)(316002)(54906003)(14454004)(256004)(71190400001)(73956011)(71200400001)(66446008)(7736002)(66946007)(25786009)(76116006)(66476007)(66556008)(64756008)(478600001)(966005)(11346002)(2906002)(6506007)(81156014)(86362001)(8936002)(81166006)(53546011)(8676002)(6916009)(5660300002)(486006)(68736007)(102836004)(33656002)(2171002)(305945005)(6246003)(66066001)(52536014)(186003)(53936002)(6436002)(99286004)(4326008)(14444005)(5024004)(446003)(26005)(72206003)(7696005)(476003)(76176011)(229853002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2502; H:BYAPR16MB2790.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: Zvm7O4OPHyHhV6a52JQR/4xf5XLzBi9Kd+X3G7rjZphC0uCyTXtM4gv9n5HKMkttk73pez8fRpNKUgK91WZmNN29xLgmcPG91fDFnutno5520keyaLpdJA3wlZMra8I6x1dzcuvhHb+AQM+wUMqxUiJXzEsVKchsPw+vInResEcoOWAF7orLB5XSZP13xBkzwW4QvmfbLkm+Ep4aqzvlhTaqGTlYi0Bs1og5IYk8yOnilEilPqU0O14y//shyLJ5ctpUZsobFYrm4DHw49sOv+VHkmFe8G/DG3N8O4PVauV9s+2UEPy8ZwWyLqPd1/QckvXYp9zM21kxIuXN2bnK3b5sIpjphyYLtm+fnC1lYck6XVEXrMBwUkQm+iS0AnJE6opooLy0hMA8JmIrHArkr1i+bjGnrlExrR2RhlFpJ54= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6aaafb9c-213b-4943-d7d3-08d6d2bdd6c0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2019 07:30:11.1496 (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: BYAPR16MB2502 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 <6540> : inlines <7074> : streams <1820811> : uri <2841470> Archived-At: Subject: Re: [secdir] [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31 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, 07 May 2019 07:30:52 -0000 Hi Ben, Please see inline > -----Original Message----- > From: Benjamin Kaduk > Sent: Monday, May 6, 2019 9:05 PM > To: Konda, Tirumaleswar Reddy > Cc: Stephen Farrell ; dots@ietf.org; draft-iet= f- > dots-signal-channel.all@ietf.org; ietf@ietf.org; secdir@ietf.org > Subject: Re: [Dots] Secdir telechat review of draft-ietf-dots-signal-chan= nel-31 >=20 > This email originated from outside of the organization. Do not click link= s or > open attachments unless you recognize the sender and know the content is > safe. >=20 > On Sat, May 04, 2019 at 08:40:30AM +0000, Konda, Tirumaleswar Reddy > wrote: > > > -----Original Message----- > > > From: Dots On Behalf Of Benjamin Kaduk > > > Sent: Friday, May 3, 2019 10:44 PM > > > To: Stephen Farrell > > > Cc: dots@ietf.org; draft-ietf-dots-signal-channel.all@ietf.org; > > > ietf@ietf.org; secdir@ietf.org > > > Subject: Re: [Dots] Secdir telechat review of > > > draft-ietf-dots-signal-channel-31 > > > > > > This email originated from outside of the organization. Do not click > > > links or open attachments unless you recognize the sender and know > > > the content is safe. > > > > > > On Mon, Apr 15, 2019 at 05:21:22AM -0700, Stephen Farrell via > > > Datatracker > > > wrote: > > > > Reviewer: Stephen Farrell > > > > Review result: Has Issues > > > > > > > > I took a look at the changes between -30 and -31 and at the mail > > > > following my earlier review of -30. > > > > > > > > To explain the "has issues" status for this review: Generally, I > > > > think this is probably ok, but I (still) have the concerns listed > > > > below that the ADs might wanna think about. The authors already > > > > responded on each of these points, and made some corresponding > > > > changes, so I guess they reckon these are non-issues. (Which is of > > > > course fine - even if I don't quite agree, I'm often wrong:-) > > > > > > > > - p13: The cuid still seems to me to be too static (there's a > > > > SHOULD saying to tie it to the client certificate public key or an > > > > equivalent). I still think recommending a way to generate an > > > > identifier that isn't tied to a key pair would be 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 without mapping 1:1 to possibly long-lived key > > > > pairs. (-31 does say some more about how to change cuid, but still > > > > has the same SHOULD/RECOMMENDED way to generate cuid values.) > > > > > > IIUC, if there are no gateways involved, anything that sees a cuid > > > is also seeing the device's client certificate, so to a large extent > > > the use as a long- lived identifier is pretty similar. > > > Server-domain gateways are supposedly just for the convenience of > > > the operator and considered equally trusted to the actual server, so > > > I think this would only come into play when a client-side gateway is > > > in use. (I don't know how common that will > > > be.) > > > > As per the discussion with Stephen > > > https://mailarchive.ietf.org/arch/msg/dots/H5JG69FJruwN7pM3j92L8wwtn- > s > > , we have added "Appendix A. CUID Generation" and updated section 10 > > (please see the diff at > > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/maste > > r/wdiff%20draft-ietf-dots-signal-channel-31.txt%20draft-ietf-dots-sign > > al-channel-31.pdf) >=20 > I don't really see Stephen getting convinced, in that linked discussion. > (Also, the added Appendix A in the linked diff is past the 50-page bounda= ry > that github loads by default, and it's failing to load more, for me.) Appendix A. CUID Generation The document recommends the use of SPKI to generate the 'cuid'. This design choice is motivated by the following reasons: o SPKI is globally unique. o It is deterministic. o It allows to avoid extra cycles that may be induced by 'cuid' collision. o DOTS clients do not need to store the 'cuid' in a persistent storage. o It allows to detect compromised DOTS clients that do not adhere to the 'cuid' generation algorithm. >=20 > > > > > > > > > - I wondered if a bad actor in control of an authorised DOTS > > > > client colluding with the controller of a DDoS attack could use > > > > this protocol to probe the network to see how their attack is > > > > going and change the attack to be more effective. In mail, the > > > > authors stated that this isn't possible, and added text saying > > > > that to -31. That may be true, but I'm not sure (given the complexi= ty of > the protocol). > > > > > > I don't think anyone responded on this yet, so I'd like to get the > > > sense of the authors. > > > > > > My personal take is that the status updates are only for the > > > efficacy of mitigations requested by this client, so (in this > > > scenario) while you can tell how much of your attack is being > > > blocked, you may not be able to learn how much is making through and > adapt to increase the amount making it through. > > > I suppose if you didn't know how big of a cannon you have, this > > > could provide a way to get some metrics, but at the cost of > > > rendering the ongoing attack ineffective, and probably revealing the > > > compromised nature of the DOTS client. > > > > This comment was discussed and resolved by adding the following lines: > > A DOTS client is entitled to access only to resources it creates. In > > particular, a DOTS client cannot retrieve data related to mitigation > > requests created by other DOTS clients of the same DOTS client > > domain. >=20 > This is good to have, but I think Stephen is still within his rights to a= sk for text > that explicitly considers what the scope of damage is when there is a > compromised DOTS client. Okay, I propose to add the following lines: A compromised DOTS client can collude with a DDoS attacker to send mitigati= on request for a target resource, gets the the mitigation efficacy from the= DOTS server, and conveys the mitigation efficacy to the DDoS attacker to p= ossibly change the DDoS attack strategy. This attack can be prevented by=20 monitoring and auditing DOTS clients to detect misbehavior and to deter mis= use, and by authorizing the DOTS client to request mitigation for specific = target resources (e.g. An application server is authorized to request mitig= ation for its IP addresses but an DDoS mitigator can request mitigation for= any target resource in the network). Further, DOTS clients are typically c= o-located on network security services (e.g. DDoS mitigator, firewall etc.)= and a compromised security service potentially can do lot more damage to t= he network. >=20 > > Further, the draft points to DOTS security considerations discussed in = DOTS > requirements draft which says the following: > > > > To detect compromised DOTS agents, DOTS operators should carefully > > monitor and audit DOTS agents to detect misbehavior and to deter > > misuse, while employing current secure network communications best > > practices to reduce attack surface. > > > > > > > > > A nit: > > > > > > > > - p91: The mention of TCP-AO seems to require suspension of > > > > disbelief (given the lack of deployment of TCP-AO). If we don't > > > > think it'll be used, it'd be better to not pretend it might get use= d. > > > > > > The authors should respond to this as well. > > > > We can update the use of TCP-AO as follows: > > > > Although not widely adopted, if TCP-AO is used, then any bogus packets > > injected by an attacker will be rejected by the TCP-AO integrity check = and > therefore will never reach the TLS layer. >=20 > Okay. Thanks, will update draft. Cheers, -Tiru >=20 > -Ben From nobody Tue May 7 10:25: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 577941202E5; Tue, 7 May 2019 10:25:25 -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 f_mSwDcz7tev; Tue, 7 May 2019 10:25:20 -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 CF94C12020A; Tue, 7 May 2019 10:25:18 -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 x47HPAbW032479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 May 2019 13:25:12 -0400 Date: Tue, 7 May 2019 12:25:10 -0500 From: Benjamin Kaduk To: "Konda, Tirumaleswar Reddy" Cc: Stephen Farrell , "dots@ietf.org" , "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Message-ID: <20190507172509.GK19509@kduck.mit.edu> References: <155533088202.10777.9128855796755282458@ietfa.amsl.com> <20190503171406.GO59871@kduck.mit.edu> <20190506153513.GD19509@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) Archived-At: Subject: Re: [secdir] [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31 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, 07 May 2019 17:25:29 -0000 On Tue, May 07, 2019 at 07:30:11AM +0000, Konda, Tirumaleswar Reddy wrote: > Hi Ben, > > Please see inline > > > -----Original Message----- > > From: Benjamin Kaduk > > Sent: Monday, May 6, 2019 9:05 PM > > To: Konda, Tirumaleswar Reddy > > Cc: Stephen Farrell ; dots@ietf.org; draft-ietf- > > dots-signal-channel.all@ietf.org; ietf@ietf.org; secdir@ietf.org > > Subject: Re: [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31 > > > > This email originated from outside of the organization. Do not click links or > > open attachments unless you recognize the sender and know the content is > > safe. > > > > On Sat, May 04, 2019 at 08:40:30AM +0000, Konda, Tirumaleswar Reddy > > wrote: > > > > -----Original Message----- > > > > From: Dots On Behalf Of Benjamin Kaduk > > > > Sent: Friday, May 3, 2019 10:44 PM > > > > To: Stephen Farrell > > > > Cc: dots@ietf.org; draft-ietf-dots-signal-channel.all@ietf.org; > > > > ietf@ietf.org; secdir@ietf.org > > > > Subject: Re: [Dots] Secdir telechat review of > > > > draft-ietf-dots-signal-channel-31 > > > > > > > > This email originated from outside of the organization. Do not click > > > > links or open attachments unless you recognize the sender and know > > > > the content is safe. > > > > > > > > On Mon, Apr 15, 2019 at 05:21:22AM -0700, Stephen Farrell via > > > > Datatracker > > > > wrote: > > > > > Reviewer: Stephen Farrell > > > > > Review result: Has Issues > > > > > > > > > > I took a look at the changes between -30 and -31 and at the mail > > > > > following my earlier review of -30. > > > > > > > > > > To explain the "has issues" status for this review: Generally, I > > > > > think this is probably ok, but I (still) have the concerns listed > > > > > below that the ADs might wanna think about. The authors already > > > > > responded on each of these points, and made some corresponding > > > > > changes, so I guess they reckon these are non-issues. (Which is of > > > > > course fine - even if I don't quite agree, I'm often wrong:-) > > > > > > > > > > - p13: The cuid still seems to me to be too static (there's a > > > > > SHOULD saying to tie it to the client certificate public key or an > > > > > equivalent). I still think recommending a way to generate an > > > > > identifier that isn't tied to a key pair would be 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 without mapping 1:1 to possibly long-lived key > > > > > pairs. (-31 does say some more about how to change cuid, but still > > > > > has the same SHOULD/RECOMMENDED way to generate cuid values.) > > > > > > > > IIUC, if there are no gateways involved, anything that sees a cuid > > > > is also seeing the device's client certificate, so to a large extent > > > > the use as a long- lived identifier is pretty similar. > > > > Server-domain gateways are supposedly just for the convenience of > > > > the operator and considered equally trusted to the actual server, so > > > > I think this would only come into play when a client-side gateway is > > > > in use. (I don't know how common that will > > > > be.) > > > > > > As per the discussion with Stephen > > > > > https://mailarchive.ietf.org/arch/msg/dots/H5JG69FJruwN7pM3j92L8wwtn- > > s > > > , we have added "Appendix A. CUID Generation" and updated section 10 > > > (please see the diff at > > > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/maste > > > r/wdiff%20draft-ietf-dots-signal-channel-31.txt%20draft-ietf-dots-sign > > > al-channel-31.pdf) > > > > I don't really see Stephen getting convinced, in that linked discussion. > > (Also, the added Appendix A in the linked diff is past the 50-page boundary > > that github loads by default, and it's failing to load more, for me.) > > Appendix A. CUID Generation > > The document recommends the use of SPKI to generate the 'cuid'. This > design choice is motivated by the following reasons: > > o SPKI is globally unique. > > o It is deterministic. > > o It allows to avoid extra cycles that may be induced by 'cuid' > collision. > > o DOTS clients do not need to store the 'cuid' in a persistent > storage. > > o It allows to detect compromised DOTS clients that do not adhere to > the 'cuid' generation algorithm. > > > > > > > > > > > > > > > - I wondered if a bad actor in control of an authorised DOTS > > > > > client colluding with the controller of a DDoS attack could use > > > > > this protocol to probe the network to see how their attack is > > > > > going and change the attack to be more effective. In mail, the > > > > > authors stated that this isn't possible, and added text saying > > > > > that to -31. That may be true, but I'm not sure (given the complexity of > > the protocol). > > > > > > > > I don't think anyone responded on this yet, so I'd like to get the > > > > sense of the authors. > > > > > > > > My personal take is that the status updates are only for the > > > > efficacy of mitigations requested by this client, so (in this > > > > scenario) while you can tell how much of your attack is being > > > > blocked, you may not be able to learn how much is making through and > > adapt to increase the amount making it through. > > > > I suppose if you didn't know how big of a cannon you have, this > > > > could provide a way to get some metrics, but at the cost of > > > > rendering the ongoing attack ineffective, and probably revealing the > > > > compromised nature of the DOTS client. > > > > > > This comment was discussed and resolved by adding the following lines: > > > A DOTS client is entitled to access only to resources it creates. In > > > particular, a DOTS client cannot retrieve data related to mitigation > > > requests created by other DOTS clients of the same DOTS client > > > domain. > > > > This is good to have, but I think Stephen is still within his rights to ask for text > > that explicitly considers what the scope of damage is when there is a > > compromised DOTS client. > > Okay, I propose to add the following lines: Thanks, I think this is helpful (and hopefully Stephen can confirm)... > A compromised DOTS client can collude with a DDoS attacker to send mitigation request for a target resource, gets the the mitigation efficacy from the DOTS server, and conveys the mitigation efficacy to the DDoS attacker to possibly change the DDoS attack strategy. This attack can be prevented by > monitoring and auditing DOTS clients to detect misbehavior and to deter > misuse, and by authorizing the DOTS client to request mitigation for ... but perhaps "by only authorizing" would be more clear. -Ben > specific target resources (e.g. An application server is authorized to > request mitigation for its IP addresses but an DDoS mitigator can request > mitigation for any target resource in the network). Further, DOTS clients > are typically co-located on network security services (e.g. DDoS > mitigator, firewall etc.) and a compromised security service potentially > can do lot more damage to the network. > > > > > > Further, the draft points to DOTS security considerations discussed in DOTS > > requirements draft which says the following: > > > > > > To detect compromised DOTS agents, DOTS operators should carefully > > > monitor and audit DOTS agents to detect misbehavior and to deter > > > misuse, while employing current secure network communications best > > > practices to reduce attack surface. > > > > > > > > > > > > A nit: > > > > > > > > > > - p91: The mention of TCP-AO seems to require suspension of > > > > > disbelief (given the lack of deployment of TCP-AO). If we don't > > > > > think it'll be used, it'd be better to not pretend it might get used. > > > > > > > > The authors should respond to this as well. > > > > > > We can update the use of TCP-AO as follows: > > > > > > Although not widely adopted, if TCP-AO is used, then any bogus packets > > > injected by an attacker will be rejected by the TCP-AO integrity check and > > therefore will never reach the TLS layer. > > > > Okay. > > Thanks, will update draft. > > Cheers, > -Tiru > > > > > -Ben From nobody Wed May 8 00:03: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 0B767120153; Wed, 8 May 2019 00:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 tQnqIpz8CX3H; Wed, 8 May 2019 00:03:51 -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 D927912014A; Wed, 8 May 2019 00:03:50 -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=1557298619; 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-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: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-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=n +kokaEkr4m+Zmy3QIQaboG97BTTf46Qx8p1FKH1lT I=; b=JvT2CoS3QQF2Bi72tl/PhF3fiTYR5GhFd6U8oEefhw6x +rjWU1vQXV+Nt1rF3eEsa7jMEwpw9a0djjXY83W54bPPvpVxd+ FXshVYh698m8Lp+KUYDzdWRyYCxYysRx2kbX9GykCOC6GOW4lb VUHxZ7IhBl9Vlv+pj5ZTxA72NmQ= 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 1780_2ad3_69fd744c_7f98_47dc_8631_2be26bba1ccf; Wed, 08 May 2019 00:56:58 -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; Wed, 8 May 2019 01:03:19 -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; Wed, 8 May 2019 01:03:20 -0600 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 8 May 2019 01:03:19 -0600 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2422.namprd16.prod.outlook.com (20.177.225.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.12; Wed, 8 May 2019 07:03:17 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::8921:8f4d:4710:4379]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::8921:8f4d:4710:4379%2]) with mapi id 15.20.1856.012; Wed, 8 May 2019 07:03:17 +0000 From: "Konda, Tirumaleswar Reddy" To: Benjamin Kaduk CC: Stephen Farrell , "dots@ietf.org" , "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Thread-Topic: [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31 Thread-Index: AQHU84Xn3S97Pb+WW0CNvO8JFIRGL6ZZwC+AgAD4aJCAA6L0gIABAsoQgACuQwCAAORcEA== Date: Wed, 8 May 2019 07:03:17 +0000 Message-ID: References: <155533088202.10777.9128855796755282458@ietfa.amsl.com> <20190503171406.GO59871@kduck.mit.edu> <20190506153513.GD19509@kduck.mit.edu> <20190507172509.GK19509@kduck.mit.edu> In-Reply-To: <20190507172509.GK19509@kduck.mit.edu> 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: 21536357-b223-472a-7f5c-08d6d3833f65 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR16MB2422; x-ms-traffictypediagnostic: BYAPR16MB2422: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0031A0FFAF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(136003)(366004)(396003)(39860400002)(32952001)(13464003)(189003)(199004)(11346002)(478600001)(316002)(446003)(14444005)(54906003)(5660300002)(99286004)(256004)(72206003)(86362001)(74316002)(476003)(6116002)(52536014)(33656002)(4326008)(3846002)(305945005)(7736002)(14454004)(229853002)(486006)(6436002)(966005)(7696005)(76116006)(68736007)(26005)(8936002)(9686003)(73956011)(66946007)(102836004)(66066001)(6306002)(55016002)(64756008)(66476007)(66556008)(81166006)(66446008)(81156014)(8676002)(80792005)(5024004)(186003)(76176011)(2906002)(25786009)(71200400001)(6506007)(6916009)(71190400001)(53546011)(2171002)(53936002)(6246003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2422; H:BYAPR16MB2790.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: JE3cYvTUuZr6wLHkLSdW3Qc+LPSu3SAJDT0t3cnniq/tL6k/C8bcYgClz6jGy09fcY7qwlzkEuGvMmfQ8InFzpkWPm5KMCfFwY50gLAYMOPKvL2M9B6IMhVZ+9oIEIcBPQkk/vGcSQJ2ezAJgWrm/Zhi15NYDbRo1VE41YCDrGHyfFz06xcl0e7kMVvAy37oKwfNqSIzJa+KTWjtsNPRAUXFJTOpDss2Dm+u7qbJpmR4o8bQxuvgKzR+yQ7F7cvoi+kzeQzBXAZyrQfac/qPsf+aiJ3Cf7XLk901QNnGzw3SuDc7SO/CEOf2WWhWmW3qFCq9Eopgd3Hg+xfI1FZb0e3xWYp2vonEvvgsVL6yQjNJryceb7OpP6K4lJ3ReN2GYl0FNt0ZS30IqM4ygjw8EfEwplxzO7ftZ5sxLLx9ZRs= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 21536357-b223-472a-7f5c-08d6d3833f65 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2019 07:03:17.5455 (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: BYAPR16MB2422 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6541> : inlines <7074> : streams <1820905> : uri <2841857> Archived-At: Subject: Re: [secdir] [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31 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, 08 May 2019 07:03:54 -0000 > -----Original Message----- > From: Benjamin Kaduk > Sent: Tuesday, May 7, 2019 10:55 PM > To: Konda, Tirumaleswar Reddy > Cc: Stephen Farrell ; dots@ietf.org; draft-iet= f- > dots-signal-channel.all@ietf.org; ietf@ietf.org; secdir@ietf.org > Subject: Re: [Dots] Secdir telechat review of draft-ietf-dots-signal-chan= nel-31 >=20 > This email originated from outside of the organization. Do not click link= s or > open attachments unless you recognize the sender and know the content is > safe. >=20 > On Tue, May 07, 2019 at 07:30:11AM +0000, Konda, Tirumaleswar Reddy > wrote: > > Hi Ben, > > > > Please see inline > > > > > -----Original Message----- > > > From: Benjamin Kaduk > > > Sent: Monday, May 6, 2019 9:05 PM > > > To: Konda, Tirumaleswar Reddy > > > > Cc: Stephen Farrell ; dots@ietf.org; > > > draft-ietf- dots-signal-channel.all@ietf.org; ietf@ietf.org; > > > secdir@ietf.org > > > Subject: Re: [Dots] Secdir telechat review of > > > draft-ietf-dots-signal-channel-31 > > > > > > This email originated from outside of the organization. Do not click > > > links or open attachments unless you recognize the sender and know > > > the content is safe. > > > > > > On Sat, May 04, 2019 at 08:40:30AM +0000, Konda, Tirumaleswar Reddy > > > wrote: > > > > > -----Original Message----- > > > > > From: Dots On Behalf Of Benjamin Kaduk > > > > > Sent: Friday, May 3, 2019 10:44 PM > > > > > To: Stephen Farrell > > > > > Cc: dots@ietf.org; draft-ietf-dots-signal-channel.all@ietf.org; > > > > > ietf@ietf.org; secdir@ietf.org > > > > > Subject: Re: [Dots] Secdir telechat review of > > > > > draft-ietf-dots-signal-channel-31 > > > > > > > > > > This email originated from outside of the organization. Do not > > > > > click links or open attachments unless you recognize the sender > > > > > and know the content is safe. > > > > > > > > > > On Mon, Apr 15, 2019 at 05:21:22AM -0700, Stephen Farrell via > > > > > Datatracker > > > > > wrote: > > > > > > Reviewer: Stephen Farrell > > > > > > Review result: Has Issues > > > > > > > > > > > > I took a look at the changes between -30 and -31 and at the > > > > > > mail following my earlier review of -30. > > > > > > > > > > > > To explain the "has issues" status for this review: Generally, > > > > > > I think this is probably ok, but I (still) have the concerns > > > > > > listed below that the ADs might wanna think about. The authors > > > > > > already responded on each of these points, and made some > > > > > > corresponding changes, so I guess they reckon these are > > > > > > non-issues. (Which is of course fine - even if I don't quite > > > > > > agree, I'm often wrong:-) > > > > > > > > > > > > - p13: The cuid still seems to me to be too static (there's a > > > > > > SHOULD saying to tie it to the client certificate public key > > > > > > or an equivalent). I still think recommending a way to > > > > > > generate an identifier that isn't tied to a key pair would be > > > > > > 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 without mapping 1:1 to > > > > > > possibly long-lived key pairs. (-31 does say some more about > > > > > > how to change cuid, but still has the same SHOULD/RECOMMENDED > > > > > > way to generate cuid values.) > > > > > > > > > > IIUC, if there are no gateways involved, anything that sees a > > > > > cuid is also seeing the device's client certificate, so to a > > > > > large extent the use as a long- lived identifier is pretty simila= r. > > > > > Server-domain gateways are supposedly just for the convenience > > > > > of the operator and considered equally trusted to the actual > > > > > server, so I think this would only come into play when a > > > > > client-side gateway is in use. (I don't know how common that > > > > > will > > > > > be.) > > > > > > > > As per the discussion with Stephen > > > > > > > > https://mailarchive.ietf.org/arch/msg/dots/H5JG69FJruwN7pM3j92L8wwtn > > > - > > > s > > > > , we have added "Appendix A. CUID Generation" and updated section > > > > 10 (please see the diff at > > > > https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/m > > > > aste > > > > r/wdiff%20draft-ietf-dots-signal-channel-31.txt%20draft-ietf-dots- > > > > sign > > > > al-channel-31.pdf) > > > > > > I don't really see Stephen getting convinced, in that linked discussi= on. > > > (Also, the added Appendix A in the linked diff is past the 50-page > > > boundary that github loads by default, and it's failing to load > > > more, for me.) > > > > Appendix A. CUID Generation > > > > The document recommends the use of SPKI to generate the 'cuid'. Thi= s > > design choice is motivated by the following reasons: > > > > o SPKI is globally unique. > > > > o It is deterministic. > > > > o It allows to avoid extra cycles that may be induced by 'cuid' > > collision. > > > > o DOTS clients do not need to store the 'cuid' in a persistent > > storage. > > > > o It allows to detect compromised DOTS clients that do not adhere t= o > > the 'cuid' generation algorithm. > > > > > > > > > > > > > > > > > > > > - I wondered if a bad actor in control of an authorised DOTS > > > > > > client colluding with the controller of a DDoS attack could > > > > > > use this protocol to probe the network to see how their attack > > > > > > is going and change the attack to be more effective. In mail, > > > > > > the authors stated that this isn't possible, and added text > > > > > > saying that to -31. That may be true, but I'm not sure (given > > > > > > the complexity of > > > the protocol). > > > > > > > > > > I don't think anyone responded on this yet, so I'd like to get > > > > > the sense of the authors. > > > > > > > > > > My personal take is that the status updates are only for the > > > > > efficacy of mitigations requested by this client, so (in this > > > > > scenario) while you can tell how much of your attack is being > > > > > blocked, you may not be able to learn how much is making through > > > > > and > > > adapt to increase the amount making it through. > > > > > I suppose if you didn't know how big of a cannon you have, this > > > > > could provide a way to get some metrics, but at the cost of > > > > > rendering the ongoing attack ineffective, and probably revealing > > > > > the compromised nature of the DOTS client. > > > > > > > > This comment was discussed and resolved by adding the following lin= es: > > > > A DOTS client is entitled to access only to resources it creates. > > > > In particular, a DOTS client cannot retrieve data related to > > > > mitigation requests created by other DOTS clients of the same DOTS > > > > client domain. > > > > > > This is good to have, but I think Stephen is still within his rights > > > to ask for text that explicitly considers what the scope of damage > > > is when there is a compromised DOTS client. > > > > Okay, I propose to add the following lines: >=20 > Thanks, I think this is helpful (and hopefully Stephen can confirm)... >=20 > > A compromised DOTS client can collude with a DDoS attacker to send > > mitigation request for a target resource, gets the the mitigation > > efficacy from the DOTS server, and conveys the mitigation efficacy to > > the DDoS attacker to possibly change the DDoS attack strategy. This > > attack can be prevented by monitoring and auditing DOTS clients to > > detect misbehavior and to deter misuse, and by authorizing the DOTS > > client to request mitigation for >=20 > ... but perhaps "by only authorizing" would be more clear. Sure, will update. -Tiru >=20 > -Ben >=20 > > specific target resources (e.g. An application server is authorized to > > request mitigation for its IP addresses but an DDoS mitigator can > > request mitigation for any target resource in the network). Further, > > DOTS clients are typically co-located on network security services > > (e.g. DDoS mitigator, firewall etc.) and a compromised security > > service potentially can do lot more damage to the network. > > > > > > > > > Further, the draft points to DOTS security considerations > > > > discussed in DOTS > > > requirements draft which says the following: > > > > > > > > To detect compromised DOTS agents, DOTS operators should careful= ly > > > > monitor and audit DOTS agents to detect misbehavior and to deter > > > > misuse, while employing current secure network communications > best > > > > practices to reduce attack surface. > > > > > > > > > > > > > > > A nit: > > > > > > > > > > > > - p91: The mention of TCP-AO seems to require suspension of > > > > > > disbelief (given the lack of deployment of TCP-AO). If we > > > > > > don't think it'll be used, it'd be better to not pretend it mig= ht get > used. > > > > > > > > > > The authors should respond to this as well. > > > > > > > > We can update the use of TCP-AO as follows: > > > > > > > > Although not widely adopted, if TCP-AO is used, then any bogus > > > > packets injected by an attacker will be rejected by the TCP-AO > > > > integrity check and > > > therefore will never reach the TLS layer. > > > > > > Okay. > > > > Thanks, will update draft. > > > > Cheers, > > -Tiru > > > > > > > > -Ben From nobody Wed May 8 01:27: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 50B36120041; Wed, 8 May 2019 01:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=smyslov.net 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 Gw4Z3FqQPxvr; Wed, 8 May 2019 01:27:15 -0700 (PDT) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (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 0508412002F; Wed, 8 May 2019 01:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:Cc:To:From:Sender:Reply-To: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=4d/ST0+qP+outbn7SPkB1kB8WPe3utcDQjv8ijwOfwM=; b=y5AnetFnSjrw6oCLHtGC067QNJ Y0OUCzHLLOTbs3Gph7UiGCALUnDkLbXMI/AT9wNhcyV5dP1h/sBhXrkXjuvDwtui2xXNTzgpyAeDR jfGvyEzivCnQoq6FHLVU1uxHWWRFcp7e96jj9WT43lV69Lmpfp2orgfoKK7/tWSyeAoixUQAsJGwq 2vCn+OF+ivboyf8ObK8fEdoHLpTrXZ2ej5E//eAgYS7yY2IzN2eFjHvlJxQK+eQakmPrvcIn2SYGc +DGRfbj2NXIbcZtShtJ9MEaBBLjr7qRe44CkjMHulDemluVVtMnNxFViSKdLxpbNjrvkhTUKwmGrI 2dTOsQXw==; Received: from [82.138.51.4] (port=65518 helo=buildpc) by direct.host-care.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.91) (envelope-from ) id 1hOHux-0005hO-Ej; Wed, 08 May 2019 04:27:11 -0400 From: "Valery Smyslov" To: Cc: , , Date: Wed, 8 May 2019 11:27:10 +0300 Message-ID: <04bd01d50577$d66c5a50$83450ef0$@smyslov.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdUFacYNvqiFABSgQWizPW7jA69YFw== Content-Language: ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [secdir] Secdir Last Call review of draft-ietf-teas-yang-te-types 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, 08 May 2019 08:27:16 -0000 Reviewer: Valery Smyslov 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. The draft defines a set of common YANG elements (typedefs, identities and groupings) that are intended to be used in Traffic Engineering related YANG modules. The draft as such doesn't have security implications. The Security Considerations section contains general advices on using YANG with data management protocols (like NETCONF or RESTCONF), which are applicable when these definitions are imported and used in other YANG modules. The advices include using secure protocols (SSH for NETCONF and TLS1.3 for RESTCONF) and implementing access control for sensitive YANG data nodes. Nit: I don't think that reference to TLS1.3 (RFC8446) should be normative. In my understanding readers of this document are not obliged to read and fully understand the details of TLS to be able to import the definitions and create a TE-related YANG module. From nobody Thu May 9 04:39:32 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F273120134 for ; Thu, 9 May 2019 04:39:29 -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.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <155740196964.16140.42994308525327981.idtracker@ietfa.amsl.com> Date: Thu, 09 May 2019 04:39:29 -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, 09 May 2019 11:39:30 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-05-16 Reviewer LC end Draft Tim Polk 2019-04-17 draft-ietf-isis-segment-routing-extensions-24 Vincent Roca R2019-02-13 draft-ietf-perc-private-media-framework-10 For telechat 2019-05-30 Reviewer LC end Draft Catherine Meadows 2019-04-12 draft-ietf-mmusic-rfc4566bis-35 Rifaat Shekh-Yusef R2019-02-08 draft-ietf-pim-igmp-mld-yang-12 Last calls: Reviewer LC end Draft Derek Atkins 2019-03-03 draft-ietf-netmod-module-tags-08 Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-28 Daniel Franke 2019-03-18 draft-ietf-sidrops-https-tal-08 Daniel Gillmor 2018-03-19 draft-gutmann-scep-13 Matthew Miller 2019-04-08 draft-ietf-core-multipart-ct-03 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-08 Stefan Santesson 2019-05-08 draft-ietf-lamps-rfc6844bis-05 Melinda Shore R2019-05-15 draft-ietf-teas-yang-te-topo-20 Sean Turner 2019-05-16 draft-ietf-sipbrandy-osrtp-09 Carl Wallace 2019-05-13 draft-ietf-tsvwg-tinymt32-01 David Waltermire 2019-02-15 draft-ietf-rtcweb-ip-handling-11 Samuel Weiler 2019-05-13 draft-ietf-grow-wkc-behavior-03 Brian Weis 2019-05-21 draft-ietf-roll-efficient-npdao-10 Klaas Wierenga 2019-02-26 draft-ietf-mpls-sr-over-ip-04 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 Kathleen Moriarty 2019-04-08 draft-ietf-bmwg-ngfw-performance-00 Next in the reviewer rotation: Klaas Wierenga Christopher Wood Paul Wouters Liang Xia Taylor Yu Dacheng Zhang Derek Atkins John Bradley Nancy Cam-Winget Shaun Cooley From nobody Thu May 9 05:54: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 B4E5F120075; Thu, 9 May 2019 05:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uB_2mQa4cnw0; Thu, 9 May 2019 05:53:49 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA1512001E; Thu, 9 May 2019 05:53:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 3DDF6E2044; Thu, 9 May 2019 08:53:47 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 24319-10; Thu, 9 May 2019 08:53:46 -0400 (EDT) Received: from securerf.ihtfp.org (99-46-190-172.lightspeed.tukrga.sbcglobal.net [99.46.190.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id D68D4E2042; Thu, 9 May 2019 08:53:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1557406426; bh=mbmv/rTXx/j/RNfuPtZxBHaLyJGi9MvJLZPEifyaDLU=; h=From:To:Cc:Subject:Date; b=YbAlhQDmUnsNN00Fe657skYzB8LayD/1PCjezi/49sb9A8rzKpXKgZspPt6TO4Hx8 X8FR/jLVBMaSS3OJWBaslCpWwepXO2hIuzKH2xVj2AqlSLt10uvTs0sRxQTxc6ry87 HKTvF5Isv2cfz46MMgLMl3Wv4uVHPVUW7IjQr4ic= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id x49Crfms017985; Thu, 9 May 2019 08:53:41 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Cc: netmod-chairs@ietf.org, chopps@chopps.org, lberger@labn.net, ivandean@gmail.com Date: Thu, 09 May 2019 08:53:40 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: [secdir] sec-dir review of draft-ietf-netmod-module-tags-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: Thu, 09 May 2019 12:53:52 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: * Ready to publish. Details: * I did not verify the YANG code. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Fri May 10 00:37: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 F22C5120177; Fri, 10 May 2019 00:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 cysCKiYwBd7A; Fri, 10 May 2019 00:37:45 -0700 (PDT) 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 23F2D120125; Fri, 10 May 2019 00:37:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,452,1549926000"; d="scan'208,217";a="382520763" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.0.34]) ([82.236.155.50]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2019 09:37:38 +0200 From: Vincent Roca Message-Id: <1CE6DB48-325C-41C2-A526-3F5FD5FA8388@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_004B1C18-D31F-45CC-9E70-6C739D9926DA" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Fri, 10 May 2019 09:37:38 +0200 In-Reply-To: Cc: Vincent Roca , David Benham , draft-ietf-perc-private-media-framework.all@ietf.org, aamelnikov@fastmail.fm, secdir@ietf.org To: "Paul E. Jones" , The IESG References: <155014077570.26619.9407568904769535504@ietfa.amsl.com> <6882A552-80DF-4322-9683-13D8E655F2DB@inria.fr> X-Mailer: Apple Mail (2.3445.104.8) 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, 10 May 2019 07:37:49 -0000 --Apple-Mail=_004B1C18-D31F-45CC-9E70-6C739D9926DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear authors, all, I=E2=80=99ve looked at the new -10 version of your I-D. Summary: Ready with nits ** In section 8.1 it is said: "While confidentiality would not be compromised by failing to implement mutual authentication, employing it helps mitigate against denial of service attacks wherein a false entity sends a stream of packets that the would force a legitimate entity to spend time attempting to decrypt." This is true only if authenticating a received packet is cheap, which is not necessarily the case. And in section 5 =C2=AB Authentication =C2=BB = you say that "details of this are outside the scope of specification", so we are not able to answer the above question: is authenticated really so cheap? With certain authenticated encryption technics (e.g. MAC-then-Encrypt), decrypting is required before checking data authenticity=E2=80=A6 So = please clarify. NB: there's also a typo in above sentence: "that the would". Finally, shouldn't this paragraph appear after the last one "A third party could cause..." since they are both concerning the same DoS issue. In that case you start with simple protections (rate limitation, = heuristics) then continue with (cheap) authentication. ** Section 8.2.3: the following sentence is unnecessarily obscur IMHO: "Within the window from last packet forwarded to the receiver = and the latest received by the Media Distributor,..." Why don't you simply say that the MD can choose, at some point of time, = to delay some packets by an arbitrary duration? Do we really need this = notion of "window =C2=BB? Cheers, Vincent > Le 1 mai 2019 =C3=A0 07:00, Paul E. Jones a = =C3=A9crit : >=20 > Vincent, >=20 > I was finally able to get back to this and prepare an updated draft. = I make changes as outlined below that should appear in -10 shortly. >=20 > Section 8.1: Will add an introductory sentence. > Section 8.1: Good point. That's confusing, as mutual authentication is = required in DTLS-SRTP. The value goes beyond cascading, too, and is = really a tool to help mitigate against DoS. I'll re-word this paragraph = substantially. > Section 8.2.2: You're right. I'll make a clear requirement statement = on replay protection earlier in the body of the document and update that = text. > Section 8.2.3: Good point. And there is a limited mitigation for this, = which is to re-key the conference periodically. I'll add another = paragraph about that, since it might not be obvious. >=20 > Thanks! > Paul >=20 > ------ Original Message ------ > From: "Vincent Roca" > > To: "David Benham" >; = "Paul E. Jones" > > Cc: "Vincent Roca" >; secdir@ietf.org = ; = draft-ietf-perc-private-media-framework.all@ietf.org = ; "The = IESG" > > Sent: 3/4/2019 9:02:16 AM > Subject: Re: Secdir last call review of = draft-ietf-perc-private-media-framework >=20 >> Hello David, Paul, all, >>=20 >> I gave a look at version -09 of your I-D, here are a few comments. >>=20 >> Summary: Almost ready >>=20 >> ** 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. >>=20 >> ** 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. >>=20 >> ** 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. >>=20 >> ** 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. >>=20 >>=20 >> Otherwise, concerning your previous comment: >>=20 >>=20 >>> 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. >>=20 >> [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. >>=20 >> Cheers, >>=20 >> Vincent --Apple-Mail=_004B1C18-D31F-45CC-9E70-6C739D9926DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear authors, all,

I=E2=80=99ve looked at the new -10 = version of your I-D.

Summary: Ready with = nits


** In = section 8.1 it is said:

   "While confidentiality
 =  would not be compromised by failing to implement mutual
   authentication, employing it helps mitigate = against denial of service
   attacks = wherein a false entity sends a stream of packets that the
   would force a legitimate entity to spend time = attempting to decrypt."

This is true only if authenticating a received packet is = cheap, which is
not necessarily the case. And in = section 5 =C2=AB Authentication =C2=BB you say that
"details of this are outside the scope of specification", so = we are not
able to answer the above question: is = authenticated really so cheap?
With certain = authenticated encryption technics (e.g. MAC-then-Encrypt),
decrypting is required before checking data authenticity=E2=80=A6= So please
clarify.

NB: there's also a typo in above = sentence: "that the would".

Finally, shouldn't this paragraph appear after the last one = "A third
party could cause..." since they are both = concerning the same DoS issue.
In that case you = start with simple protections (rate limitation, heuristics)
then continue with (cheap) authentication.


** Section 8.2.3: the following sentence is unnecessarily = obscur IMHO:
        "Within = the window from last packet forwarded to the receiver and the
        latest received by the Media = Distributor,..."
Why don't you simply say that the = MD can choose, at some point of time, to
delay some = packets by an arbitrary duration? Do we really need this = notion
of "window =C2=BB?


Cheers,

  Vincent


Le 1 mai 2019 =C3=A0 07:00, Paul E. Jones = <paulej@packetizer.com> a =C3=A9crit :

Vincent,

I was finally able to get back to this and prepare an = updated draft.  I make changes as outlined below that should appear = in -10 shortly.

Section 8.1: Will add an introductory = sentence.
Section 8.1: Good point. That's = confusing, as mutual authentication is required in DTLS-SRTP. The value = goes beyond cascading, too, and is really a tool to help mitigate = against DoS.  I'll re-word this paragraph substantially.
Section 8.2.2: You're right. I'll make a clear = requirement statement on replay protection earlier in the body of the = document and update that text.
Section 8.2.3: Good point. And there = is a limited mitigation for this, which is to re-key the conference = periodically.  I'll add another paragraph about that, since it = might not be obvious.

Thanks!
Paul

------ Original Message = ------
From: "Vincent Roca" <vincent.roca@inria.fr>
To: = "David Benham" <dabenham@gmail.com>; "Paul E. Jones" <paulej@packetizer.com>
Cc: = "Vincent Roca" <vincent.roca@inria.fr>; secdir@ietf.org; draft-ietf-perc-private-media-framework.all@ietf.org; = "The IESG" <iesg@ietf.org>
Sent: = 3/4/2019 9:02:16 AM
Subject: Re: Secdir last call review = of draft-ietf-perc-private-media-framework

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=_004B1C18-D31F-45CC-9E70-6C739D9926DA-- From nobody Sat May 11 21:35: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 191951200F7; Sat, 11 May 2019 21:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=packetizer.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 jZOA3jbSLOZs; Sat, 11 May 2019 21:35:06 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (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 55B4A12003E; Sat, 11 May 2019 21:35:06 -0700 (PDT) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1557635697; bh=yAnSQ4emBQBwHGC22fewDWw/UOExXZgDOEXVDLXQWHw=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=f6SiLENzottS81fMoyW3Ylu6PKrA8uG2tIdWouJF2xo4JrI+ImmgKnkq0fAbDOW5J obIED2erjiLLBuWKZ/BE6l3yDXcdAznPxZHXJdMsLOJYr4gzW7TGbb7AuPd/QiDRbM uDE7mdwBeKsUFY8O3OG3wh3JqSy2jHTpy/dZ3yVs= From: "Paul E. Jones" To: "Vincent Roca" , "The IESG" Cc: "Vincent Roca" , "David Benham" , draft-ietf-perc-private-media-framework.all@ietf.org, aamelnikov@fastmail.fm, secdir@ietf.org Date: Sun, 12 May 2019 04:34:55 +0000 Message-Id: In-Reply-To: <1CE6DB48-325C-41C2-A526-3F5FD5FA8388@inria.fr> References: <155014077570.26619.9407568904769535504@ietfa.amsl.com> <6882A552-80DF-4322-9683-13D8E655F2DB@inria.fr> <1CE6DB48-325C-41C2-A526-3F5FD5FA8388@inria.fr> Reply-To: "Paul E. Jones" User-Agent: eM_Client/7.2.34711.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBED1EEE47-568A-499C-B659-8ECC720E5B73" 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: Sun, 12 May 2019 04:35:10 -0000 --------=_MBED1EEE47-568A-499C-B659-8ECC720E5B73 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Vincent, Once again, thanks for the feedback. Please allow me to reply inline=20 and, if you're OK with the text, I can prepare a new revision. >** In section 8.1 it is said: > > "While confidentiality > would not be compromised by failing to implement mutual > authentication, employing it helps mitigate against denial of=20 >service > attacks wherein a false entity sends a stream of packets that the > would force a legitimate entity to spend time attempting to=20 >decrypt." > >This is true only if authenticating a received packet is cheap, which=20 >is >not necessarily the case. And in section 5 =C2=AB Authentication =C2=BB yo= u say=20 >that >"details of this are outside the scope of specification", so we are not >able to answer the above question: is authenticated really so cheap? >With certain authenticated encryption technics (e.g. MAC-then-Encrypt), >decrypting is required before checking data authenticity=E2=80=A6 So pleas= e >clarify. Actually, after reading that original text, I think it is even=20 misleading to suggest confidentiality is not compromised. In terms of=20 encryption, that would be true, but in terms of net effect, it would=20 not: without verifying the certificate, an unwanted party could=20 potentially engage in the conference. I think this would be better text=20 (replacing the entire paragraph): Use of mutual DTLS authentication (as required by DTLS-SRTP) ensures=20 that a false endpoint or false Media Distributor cannot interact with a=20 legitimate Media Distributor or endpoint. This helps mitigate against denial of=20 service attacks wherein a false entity sends a stream of packets that would=20 force a legitimate entity to spend time attempting to decrypt. With respect to whether the DoS mitigation is true or not, I think it=20 is. If mutual authentication fails, then no media packets would flow at=20 all, thus no wasted time decrypting packets; packets would likely get=20 rejected without inspection. If mutual authentication succeeds, then=20 the cost isn't at issue here, anyway, since the point of the paragraph=20 is to talk about a side benefit of mutual authentication. While the=20 specifics are outside the scope of the document, the assumption is that=20 some mechanism is employed to enable checking the validity of=20 certificates. >NB: there's also a typo in above sentence: "that the would". Thanks, I fixed that. > > >Finally, shouldn't this paragraph appear after the last one "A third >party could cause..." since they are both concerning the same DoS=20 >issue. >In that case you start with simple protections (rate limitation,=20 >heuristics) >then continue with (cheap) authentication. Agreed, moving it makes more sense. >** Section 8.2.3: the following sentence is unnecessarily obscur IMHO: > "Within the window from last packet forwarded to the receiver=20 >and the > latest received by the Media Distributor,..." >Why don't you simply say that the MD can choose, at some point of time,=20 >to >delay some packets by an arbitrary duration? Do we really need this=20 >notion >of "window =C2=BB? Definitely not essential. I tried to make whole paragraph a little=20 easier to read. How about this: While the Media Distributor can purposely stop forwarding media flows,=20 it can also select an arbitrary starting point to resume forwarding those media flow, perhaps forwarding old packets rather than current packets. As a consequence, what the media source sent can be substantially=20 delayed at the receiver with the receiver believing that newly arriving packets are delayed only by transport delay when the packets may actually be minutes or hours old. The most significant change with this text, I think, (apart from=20 removing "window") is changing "media source said" to "media source=20 sent". If that's less clear, I can try to put "said" back in, but I=20 felt the current wording of "that it is what was said just now" was=20 really hard to parse. Thanks! Paul > > > >Cheers, > > Vincent > > >>Le 1 mai 2019 =C3=A0 07:00, Paul E. Jones a =C3= =A9crit : >> >>Vincent, >> >>I was finally able to get back to this and prepare an updated draft. =20 >>I make changes as outlined below that should appear in -10 shortly. >> >>Section 8.1: Will add an introductory sentence. >>Section 8.1: Good point. That's confusing, as mutual authentication is=20 >>required in DTLS-SRTP. The value goes beyond cascading, too, and is=20 >>really a tool to help mitigate against DoS. I'll re-word this=20 >>paragraph substantially. >>Section 8.2.2: You're right. I'll make a clear requirement statement=20 >>on replay protection earlier in the body of the document and update=20 >>that text. >>Section 8.2.3: Good point. And there is a limited mitigation for this,=20 >>which is to re-key the conference periodically. I'll add another=20 >>paragraph about that, since it might not be obvious. >> >>Thanks! >>Paul >> >>------ Original Message ------ >>From: "Vincent Roca" >>To: "David Benham" ; "Paul E. Jones"=20 >> >>Cc: "Vincent Roca" ; secdir@ietf.org;=20 >>draft-ietf-perc-private-media-framework.all@ietf.org; "The IESG"=20 >> >>Sent: 3/4/2019 9:02:16 AM >>Subject: Re: Secdir last call review of=20 >>draft-ietf-perc-private-media-framework >> >>>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=20 >>>8.1. For instance it is not explicitely >>>explained what is meant by =C2=AB 3rd party attack =C2=BB. I suggest add= ing a=20 >>>sentence. >>> >>>** Section 8.1 >>>You=E2=80=99re saying that "If mutual DTLS authentication is not employe= d=E2=80=A6 =C2=BB.=20 >>>Is it really an optional mechanism? >>>I must admit I haven=E2=80=99t read the rest of your I-D where this is= =20 >>>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=20 >>>Section 3.3.2/[RFC3711] MUST be used. >>>The sentence can be understood as replay protection is mandatory,=20 >>>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=20 >>>attack" is IMHO misleading. >>>Delaying and re-sending a packet already sent are two different=20 >>>attacks (and the fact that replay >>>protection is of no help against delayed packets is a good sign of=20 >>>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=20 >>>>8.2 which we have not yet addressed in -09 ; >>>> >>>> > Attacks of section 8.1 seems more realistic to me than attacks of=20 >>>>section 8.2 >>>> > because of a weaker attacker model: the attacker is outside of the= =20 >>>>systems, >>>> > and not necessarily on the path. >>>> > Therefore I would have liked to see more details in section 8.1,=20 >>>>that=E2=80=99s all. >>>> >>>>You're asking for greater detail in sect 8.1 precisely because you=20 >>>>estimate that third-party attacks (aka outsiders to a given=20 >>>>conference) are more likely/common than the attacks we covered in=20 >>>>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=20 >>>>make it flow better and/or be clearer. But it is not clear to us=20 >>>>what we left out detail-wise, or if we left out other attack=20 >>>>examples. >>>> >>>>With PERC's HBH integrity checks, authentication as well as HBH and=20 >>>>E2E encryption, we can quickly describe in text the=20 >>>>prevention/mitigation of attacks on the confidentiality of the=20 >>>>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=20 >>>>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=20 >>>8.2.2 or 8.2.4 to describe attacks >>>that cannot take place because of the PERC design. That being said, I=20 >>>see that version -09 has a >>>more detailed section 8.1 which is fine. >>> >>>Cheers, >>> >>> Vincent > --------=_MBED1EEE47-568A-499C-B659-8ECC720E5B73 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
= Vincent,

Once again, thanks for the feedback.= =C2=A0Please allow me to reply inline and, if you're OK with the text, I can= prepare a new revision.

** In section 8.1 it is said:
<= br class=3D"" />
=C2=A0 =C2=A0"While confidentiality
=C2=A0 =C2=A0would not be compromised by failing to imp= lement mutual
=C2=A0 =C2=A0authentication, employing i= t helps mitigate against denial of service
=C2=A0 =C2= =A0attacks wherein a false entity sends a stream of packets that the
<= div class=3D"">=C2=A0 =C2=A0would force a legitimate entity to spend time a= ttempting to decrypt."

This is true only if authenticating a received packet is cheap, whi= ch is
not necessarily the case. And in section 5 =C2= =AB=C2=A0Authentication=C2=A0=C2=BB you say that
"deta= ils of this are outside the scope of specification", so we are not
able to answer the above question: is authenticated really so= cheap?
With certain authenticated encryption technics= (e.g. MAC-then-Encrypt),
decrypting is required before = checking data authenticity=E2=80=A6 So please
clarify= .

Actually, after reading= that original text, I think it is even misleading to suggest confidentialit= y is not compromised. =C2=A0In terms of encryption, that would be true, but = in terms of net effect, it would not: without verifying the certificate, a= n unwanted party could potentially engage in the conference. =C2=A0I think= this would be better text (replacing the entire paragraph):

Use of mutual DTLS authentication (as required by DTLS-SRTP) ensures th= at a
false endpoint or false Media Distributor cannot interact with a= legitimate
Media Distributor or endpoint.=C2=A0 This helps mitigate ag= ainst denial of service
attacks wherein a false entity sends a stream= of packets that would force
a legitimate entity to spend time attempti= ng to decrypt.
With respect to whether = the DoS mitigation is true or not, I think it is. =C2=A0If mutual authenti= cation fails, then no media packets would flow at all, thus no wasted time= decrypting packets; packets would likely get rejected without inspection. = =C2=A0If mutual authentication succeeds, then the cost isn't at issue here= , anyway, since the point of the paragraph is to talk about a side benefit= of mutual authentication. =C2=A0While the specifics are outside the scope o= f the document, the assumption is that some mechanism is employed to enable = checking the validity of certificates.


NB: there's also a typo in above sentence: "that the would".

Thanks, I fixed that.


Finally, shouldn't this p= aragraph appear after the last one "A third
party coul= d cause..." since they are both concerning the same DoS issue.
In that case you start with simple protections (rate limitation, h= euristics)
then continue with (cheap) authentication.<= /div>

<= /div>
Agreed, moving it makes mo= re sense.

** Section 8.2.3: = the following sentence is unnecessarily obscur IMHO:
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Within the window from last packet forwarded t= o the receiver and the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 lat= est received by the Media Distributor,..."
Why don't y= ou simply say that the MD can choose, at some point of time, to
delay some packets by an arbitrary duration? Do we really need th= is notion
of "window=C2=A0=C2=BB?

Definitely not essential. =C2=A0I tried to mak= e whole paragraph a little easier to read. =C2=A0How about this:

While the Media Distributor can purposely stop forwarding media fl= ows, it
can also select an ar= bitrary starting point to resume forwarding those
media flow, perhaps forwarding old packets rather than = current packets.
<= font face=3D"Courier New" size=3D"1" style=3D"font-size: 9pt;">As a consequ= ence, what the media source sent can be substantially delayed
<= div id=3D"x90b688ce691e437" style=3D"word-wrap: break-word; -webkit-nbsp-mo= de: space; line-break: after-white-space;">at the receiver with the receiver believin= g that newly arriving packets
= are delayed only by transport delay when the packets may actually be=
minutes or hours old.

The most significant change with this text, I think, = (apart from removing "window") is changing "media source said" to "media s= ource sent". =C2=A0If that's less clear, I can try to put "said" back in, b= ut I felt the current wording of "that it is what was said just=C2=A0now" w= as really hard to parse.
<= br />
Thanks!
Paul





Cheers,

=C2=A0 Vincent


Le 1 mai 2019 =C3=A0 07:= 00, Paul E. Jones <p= aulej@packetizer.com> a =C3=A9crit :

Vincent,

I was finally able to get back to this and prepare an updated draft= . =C2=A0I make changes as outlined below that should appear in -10 shortly.=

Section 8.1:= Will add an introductory sentence.
Section 8.1:=C2=A0Good point. That's confusing, as mutua= l authentication is required in DTLS-SRTP. The value goes beyond cascading, = too, and is really a tool to help mitigate against DoS. =C2=A0I'll re-word = this paragraph substantially.
Section 8.2.2: You're right. I'll make a clear requirement s= tatement on replay protection earlier in the body of the document and updat= e that text.
Sec= tion 8.2.3: Good point. And there is a limited mitigation for this, which i= s to re-key the conference periodically. =C2=A0I'll add another paragraph a= bout that, since it might not be obvious.

Thanks!
Paul

------ Original Message ------
From: "Vincent Roca" <vincent.roca@inria.fr>
To: "David Benham" <dabenham@gmail.com>; "Paul = E. Jones" <paulej@p= acketizer.com>
Cc: "Vincent Roca" <vincent.roca@inria.fr>;= =C2=A0secdir@ietf.org<= /a>;=C2=A0draft-ietf-p= erc-private-media-framework.all@ietf.org; "The IESG" <iesg@ietf.org>
Sent: 3/4/2019 9:02:16 AM
Subject: Re: Secdir last call = review of draft-ietf-perc-private-media-framework

Hello David, Paul, all,

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

Summary:=C2= =A0Almost ready

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

** Section 8.1
You=E2=80=99re saying that "If mu= tual DTLS authentication is not employed=E2=80=A6=C2=A0=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 ju= st a bit surprised here.

** Section 8.2.2
It is sugge= sted but not clearly said that the replay protection of Section 3.3.2/[RFC3= 711] MUST be used.
The sentence can be understood as r= eplay protection is mandatory, Section 3.3.2 of [RFC3711] is an example
of such a mechanism.
I don't think t= his is what you mean.

** Section 8.2.3
Saying that "The delayed playo= ut 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 se= ct 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
> becau= se of a weaker attacker model: the attacker is outside of the systems,=C2=A0
> 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.

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.=C2=A0 =C2=A0Is that=C2=A0correct?

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.=C2=A0 =C2=A0B= ut it is not clear to us what we left out detail-wise, or if we left out ot= her attack examples.

With PERC's HBH=C2=A0integrity checks,=C2=A0authentication as well as HBH and E2E encryption, we can quickly descr= ibe in text the prevention/mitigation of attacks on the=C2=A0confidentialit= y of the media/content - PERCs reason to be - to explain some of the brevit= y.=C2=A0

Could you help point us in the right directi= on with an example or two of the things we should do to detail/elaborate se= ct 8.1.
[VR] I was surprised to see for instan= ce 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 sa= id, I see that version -09 has a
more detailed section = 8.1 which is fine.

Cheers,

= =C2=A0 =C2=A0Vincent

--------=_MBED1EEE47-568A-499C-B659-8ECC720E5B73-- From nobody Mon May 13 02:47: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 320F8120112; Mon, 13 May 2019 02:47:23 -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, 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 b_pVf0nupKe1; Mon, 13 May 2019 02:47:19 -0700 (PDT) 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 E56E512003E; Mon, 13 May 2019 02:47:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,465,1549926000"; d="scan'208,217";a="382870872" Received: from moucherotte.inrialpes.fr ([194.199.28.14]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 May 2019 11:47:17 +0200 From: Vincent Roca Message-Id: <3FB301E0-1E6E-47F1-AB7B-C1194680EEF8@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_9D06126F-DB77-49C6-B6C4-E48AA0614EDD" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Mon, 13 May 2019 11:47:16 +0200 In-Reply-To: Cc: Vincent Roca , The IESG , David Benham , draft-ietf-perc-private-media-framework.all@ietf.org, aamelnikov@fastmail.fm, secdir@ietf.org To: "Paul E. Jones" References: <155014077570.26619.9407568904769535504@ietfa.amsl.com> <6882A552-80DF-4322-9683-13D8E655F2DB@inria.fr> <1CE6DB48-325C-41C2-A526-3F5FD5FA8388@inria.fr> X-Mailer: Apple Mail (2.3445.104.8) 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, 13 May 2019 09:47:24 -0000 --Apple-Mail=_9D06126F-DB77-49C6-B6C4-E48AA0614EDD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Paul, all, > Le 12 mai 2019 =C3=A0 06:34, Paul E. Jones a = =C3=A9crit : >=20 > Vincent, >=20 > Once again, thanks for the feedback. Please allow me to reply inline = and, if you're OK with the text, I can prepare a new revision. >=20 >> ** In section 8.1 it is said: >>=20 >> "While confidentiality >> would not be compromised by failing to implement mutual >> authentication, employing it helps mitigate against denial of = service >> attacks wherein a false entity sends a stream of packets that the >> would force a legitimate entity to spend time attempting to = decrypt." >>=20 >> This is true only if authenticating a received packet is cheap, which = is >> not necessarily the case. And in section 5 =C2=AB Authentication =C2=BB= you say that >> "details of this are outside the scope of specification", so we are = not >> able to answer the above question: is authenticated really so cheap? >> With certain authenticated encryption technics (e.g. = MAC-then-Encrypt), >> decrypting is required before checking data authenticity=E2=80=A6 So = please >> clarify. >=20 > Actually, after reading that original text, I think it is even = misleading to suggest confidentiality is not compromised. In terms of = encryption, that would be true, but in terms of net effect, it would = not: without verifying the certificate, an unwanted party could = potentially engage in the conference. I think this would be better text = (replacing the entire paragraph): >=20 > Use of mutual DTLS authentication (as required by DTLS-SRTP) ensures = that a > false endpoint or false Media Distributor cannot interact with a = legitimate > Media Distributor or endpoint. This helps mitigate against denial of = service > attacks wherein a false entity sends a stream of packets that would = force > a legitimate entity to spend time attempting to decrypt. >=20 > With respect to whether the DoS mitigation is true or not, I think it = is. If mutual authentication fails, then no media packets would flow at = all, thus no wasted time decrypting packets; packets would likely get = rejected without inspection. If mutual authentication succeeds, then = the cost isn't at issue here, anyway, since the point of the paragraph = is to talk about a side benefit of mutual authentication. While the = specifics are outside the scope of the document, the assumption is that = some mechanism is employed to enable checking the validity of = certificates. [VR] Yes for the first aspect. Concerning DoS mitigation, wether DTLS authentication helps reducing = decryption overhead at a receiver really depends on how authentication is achieved. Looking at RFC 5764 (I = imagine this is where DTLS-SRTP is defined), I read in Section 5.1.2. =C2=AB Reception =C2=BB, item 3., = that decryption and authentication are performed at the same step. This is in line, although no technical detail is = provided, with my comment on authenticated encryption (see also = https://en.wikipedia.org/wiki/Authenticated_encryption). In some cases, = decrypting is=20 required before checking data authenticity, so authentication won=E2=80=99= t be of any help if your goal is to avoid =C2=AB spend[ing] time attempting to decrypt =C2=BB, what you're saying.=20= RFC 5764, Section 7.4. =C2=AB Decryption Cost =C2=BB, discusses = decryption cost but does not presents authentication as a solution to mitigate it. What you=E2=80=99re saying in your answer, above (whether or not mutual = authentication fails) is something else. In section 8.1 we are considering 3rd party attacks, from entities that = will never be authenticated. >> NB: there's also a typo in above sentence: "that the would". >=20 > Thanks, I fixed that. >=20 >>=20 >>=20 >> Finally, shouldn't this paragraph appear after the last one "A third >> party could cause..." since they are both concerning the same DoS = issue. >> In that case you start with simple protections (rate limitation, = heuristics) >> then continue with (cheap) authentication. >=20 > Agreed, moving it makes more sense. >=20 >=20 >> ** Section 8.2.3: the following sentence is unnecessarily obscur = IMHO: >> "Within the window from last packet forwarded to the receiver = and the >> latest received by the Media Distributor,..." >> Why don't you simply say that the MD can choose, at some point of = time, to >> delay some packets by an arbitrary duration? Do we really need this = notion >> of "window =C2=BB? >=20 > Definitely not essential. I tried to make whole paragraph a little = easier to read. How about this: >=20 > While the Media Distributor can purposely stop forwarding media flows, = it > can also select an arbitrary starting point to resume forwarding those > media flow, perhaps forwarding old packets rather than current = packets. > As a consequence, what the media source sent can be substantially = delayed > at the receiver with the receiver believing that newly arriving = packets > are delayed only by transport delay when the packets may actually be > minutes or hours old. >=20 > The most significant change with this text, I think, (apart from = removing "window") is changing "media source said" to "media source = sent". If that's less clear, I can try to put "said" back in, but I = felt the current wording of "that it is what was said just now" was = really hard to parse. [VR] okay. >=20 > Thanks! > Paul Cheers, Vincent --Apple-Mail=_9D06126F-DB77-49C6-B6C4-E48AA0614EDD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= Paul, all,


Le 12 mai 2019 =C3=A0 06:34, Paul E. Jones = <paulej@packetizer.com> a =C3=A9crit :

Vincent,

Once again, thanks for the feedback.  Please = allow me to reply inline and, if you're OK with the text, I can prepare = a new revision.

** In section 8.1 it = is said:

   "While confidentiality
 =  would not be compromised by failing to implement mutual
   authentication, employing it helps mitigate = against denial of service
   attacks = wherein a false entity sends a stream of packets that the
   would force a legitimate entity to spend time = attempting to decrypt."

This is true only if authenticating a received packet is = cheap, which is
not necessarily the case. And in = section 5 =C2=AB Authentication =C2=BB you say that
"details of this are outside the scope of specification", so = we are not
able to answer the above question: is = authenticated really so cheap?
With certain = authenticated encryption technics (e.g. MAC-then-Encrypt),
decrypting is required before checking data authenticity=E2=80=A6= So please
clarify.

Actually, after reading that original text, I think it is = even misleading to suggest confidentiality is not compromised.  In = terms of encryption, that would be true, but in terms of net effect, it = would not: without verifying the certificate, an unwanted party could = potentially engage in the conference.  I think this would be better = text (replacing the entire paragraph):

Use = of mutual DTLS authentication (as required by DTLS-SRTP) ensures that = a
false endpoint or false Media Distributor cannot = interact with a legitimate
Media Distributor or = endpoint.  This helps mitigate against denial of service
attacks wherein a false entity sends a stream of packets that = would force
a legitimate entity to spend time attempting = to decrypt.

With respect to whether the DoS = mitigation is true or not, I think it is.  If mutual authentication = fails, then no media packets would flow at all, thus no wasted time = decrypting packets; packets would likely get rejected without = inspection.  If mutual authentication succeeds, then the cost isn't = at issue here, anyway, since the point of the paragraph is to talk about = a side benefit of mutual authentication.  While the specifics are = outside the scope of the document, the assumption is that some mechanism = is employed to enable checking the validity of = certificates.

[VR] Yes for the first aspect.

Concerning DoS mitigation, wether DTLS = authentication helps reducing decryption overhead at a = receiver
really depends on how authentication is achieved. = Looking at RFC 5764 (I imagine this is where DTLS-SRTP
is = defined), I read in Section 5.1.2. =C2=AB Reception =C2=BB, item = 3., that decryption and authentication are performed
at the = same step. This is in line, although no technical detail is provided, = with my comment on authenticated
encryption (see also https://en.wikipedia.org/wiki/Authenticated_encryption). = In some cases, decrypting is 
required before = checking data authenticity, so authentication won=E2=80=99t be of any = help if your goal is to avoid
=C2=AB spend[ing] time = attempting to decrypt =C2=BB, what you're = saying. 
RFC 5764, Section 7.4. =C2=AB Decryption = Cost =C2=BB, discusses decryption cost but does not presents = authentication
as a solution to mitigate it.

What you=E2=80=99re saying in your answer, above = (whether or not mutual authentication fails) is something = else.
In section 8.1 we are considering 3rd party attacks, = from entities that will never be authenticated.


NB: = there's also a typo in above sentence: "that the = would".

Thanks, I fixed that.



Finally, shouldn't this paragraph appear after the last one = "A third
party could cause..." since they are both = concerning the same DoS issue.
In that case you = start with simple protections (rate limitation, heuristics)
then continue with (cheap) = authentication.

Agreed, moving it makes more sense.


** = Section 8.2.3: the following sentence is unnecessarily obscur = IMHO:
        "Within the window from = last packet forwarded to the receiver and the
  =       latest received by the = Media Distributor,..."
Why don't you simply say = that the MD can choose, at some point of time, to
delay some packets by an arbitrary duration? Do we really = need this notion
of = "window =C2=BB?

Definitely not essential.  I tried to make whole = paragraph a little easier to read.  How about this:

While the Media Distributor can purposely stop = forwarding media flows, it
can also select an arbitrary = starting point to resume forwarding those
media flow, perhaps forwarding old packets rather than = current packets.
As a consequence, what the media = source sent can be substantially delayed
at = the receiver with the receiver believing that newly arriving = packets
are delayed only by transport delay when the packets = may actually be
minutes or hours = old.

The most significant change with this = text, I think, (apart from removing "window") is changing "media source = said" to "media source sent".  If that's less clear, I can try to = put "said" back in, but I felt the current wording of "that it is what = was said just now" was really hard to = parse.

[VR] = okay.


Thanks!
Paul

Cheers,

  Vincent

= --Apple-Mail=_9D06126F-DB77-49C6-B6C4-E48AA0614EDD-- From nobody Mon May 13 12:22: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 90AD712023C for ; Mon, 13 May 2019 12:22:41 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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=danielking-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 SwSBaP339QqS for ; Mon, 13 May 2019 12:22:40 -0700 (PDT) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (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 EE5CA1200C5 for ; Mon, 13 May 2019 12:22:39 -0700 (PDT) Received: by mail-wr1-x442.google.com with SMTP id c5so16513939wrs.11 for ; Mon, 13 May 2019 12:22:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielking-net.20150623.gappssmtp.com; s=20150623; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=AN56KssOHU9dO2JLrRY/lBaRCmDeUrk+NIplJQv/4YA=; b=mG3vu42YnQgudlf/ZVrajWSIxxkqUXbG/Uyu8bohgWcXaWsa6TfsC+bqotmGrL5OU7 fO/WsWjx+KNRxGVdrTqwKuyFMbP6qNwEJdnkGcCV2TsB2qfqzeUP2rIfcHhmhnX+A+d4 oDvagyhcEj3YSbZV17Vu4Pa0JwOT7LV3/rJeiVAvsQxNcEXeTDPxxDCg2zONyI2F56Jj qUZpvNr4Gv7VKZKWEDQ2RBsp5mPvfmg4stRqwA65KTB6JhdnBDdQQE69HPfKASntHQzq WAMlJU+9wu01WHGmjl9oLFaL/b76GNrvNNkOwmGX5Ntgr1lx4EIX8huQk0UvFqZ5XhtR YJKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:references:in-reply-to:subject :date:message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=AN56KssOHU9dO2JLrRY/lBaRCmDeUrk+NIplJQv/4YA=; b=dbli1jwQ2ZG2tFPgtuBOmLEVRp5qyhQKbL08ZEeiiCYbi2xj5XfuV/NOeH0PMgdMpB O38BnsPb0N1f0rqBGQsPnj+uCbLogLx3YE2mdj4BakATAqfEsga/fTof3Uju/tWTYrix ZFLXnrRGjMIBTJu4A+FaYyBVz52vINilkd4jqZgUSzcpqY/DObeb8blJrBaMd0gcvL/N dHV8/asjtnLNDtE5Y7PSKVDFT7C6WZm72F22q1L1rvGxUtyV7Oes2XFF1KoB+3Xrbrdd TEXgLuym8viukZeU4tCxqKhnnn9cicZlATz16l6HpbzzvMXmVULE5jXYLDxyQCZzbGq5 aedw== X-Gm-Message-State: APjAAAXG8e0nRBasyipoij+ct14UJ3UNP/+Ug4AWnnj0A/S8dDmjml5k fnA9PFLpJLOyVN0qSUdbHfAWBQ== X-Google-Smtp-Source: APXvYqxq20FeoZnoKnZKR02O3ZiE6PnLF508tszVtQs+z6OPVVQrI3g8rsXPF4cS+l/B/1wn8A95Vw== X-Received: by 2002:adf:8bc5:: with SMTP id w5mr4593047wra.226.1557775358235; Mon, 13 May 2019 12:22:38 -0700 (PDT) Received: from CIPHER ([88.202.231.139]) by smtp.gmail.com with ESMTPSA id b18sm8321723wrx.75.2019.05.13.12.22.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 May 2019 12:22:37 -0700 (PDT) Sender: Daniel King X-Google-Original-Sender: "Daniel King" From: To: "'Kyle Rose'" , Cc: , , References: <155535945259.10773.14556389726269462856@ietfa.amsl.com> In-Reply-To: <155535945259.10773.14556389726269462856@ietfa.amsl.com> Date: Mon, 13 May 2019 20:22:36 +0100 Message-ID: <007701d509c1$39535b80$abfa1280$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIbdTdcm2N8ImEWYCoeoc+jBrkXfKXclcrA Content-Language: en-gb Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-pce-hierarchy-extensions-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: Mon, 13 May 2019 19:22:42 -0000 Hi Kyle,=20 Thank you for the review, it is most appreciated! We have addressed all your comments in the latest version of our I-D = (v11) but were advised to hold off posting until after the IESG = telechat. Comments inline (DK>>) on how we addressed said comments:=20 -----Original Message----- From: Kyle Rose via Datatracker =20 Sent: 15 April 2019 21:18 To: secdir@ietf.org Cc: draft-ietf-pce-hierarchy-extensions.all@ietf.org; pce@ietf.org; = ietf@ietf.org Subject: Secdir last call review of = draft-ietf-pce-hierarchy-extensions-10 Reviewer: Kyle Rose 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 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. For background, Wikipedia has the following to say about PCE: q( Routing can be subject to a set of constraints, such as Quality of = Service (QoS), policy, or price. Constraint-based path computation is a = strategic component of traffic engineering in MPLS, GMPLS and Segment Routing = networks. It is used to determine the path through the network that traffic should follow, and provides the route for each Label Switched Path (LSP) that = is set up. Path computation has previously been performed either in a management = system or at the head end of each LSP. But path computation in large, multi-domain networks may be very complex and may require more computational power = and network information than is typically available at a network element, = yet may still need to be more dynamic than can be provided by a management = system. Thus, a PCE is an entity capable of computing paths for a single or set = of services. A PCE might be a network node, network management station, or dedicated computational platform that is resource-aware and has the = ability to consider multiple constraints for sophisticated path computation. PCE applications compute label switched paths for MPLS and GMPLS traffic engineering. ) The document is nearly ready. In addition to numerous grammatical errors throughout, I see one minor but substantive issue. In section 6.1.2, the = last sentence reads: q( This means that a parent PCE must be configured with the identities and security credentials of all of its child PCEs, or there must be some form of shared secret that allows an unknown child PCE to be authorized by the parent PCE. ) A secret shared by more than two parties cannot be used to establish = identity. If there are two, then assuming exfiltration and reflection attacks are = not part of your threat model, each party knows it is talking to the single = other legitimate possessor of the shared secret. If there are more than two, = this is no longer the case. That said, in this case it's not clear you need to = identify individual child PCEs, and so (notwithstanding potential impersonation = attacks in a shared secret scheme) you may wish to shorten this sentence to: q( This means that a parent PCE MUST* be able to cryptographically = authenticate requests from child PCEs. ) The choice of authentication scheme can then be left to implementors, or recommendations to a different document. You might add a sentence to the security considerations section suggesting that multi-party shared key authentication schemes are not recommended for inter-domain = relationships because of the potential for impersonation and repudiation and for the operational difficulties should revocation be required. DK>> Thanks for the comments and especially the text update! We have = used your suggestion directly, and also expanded the security = discussion. The I-D now includes the following text in Section .1.2. = Parent PCE >> The parent PCE must only accept path computation requests from authorized child PCEs. If a parent PCE receives requests from an unauthorized child PCE, the request should be dropped. This means=20 that a parent PCE MUST be able to cryptographically authenticate=20 requests from child PCEs. =20 Multi-party shared key authentication schemes are not recommended for inter-domain relationships because of the potential for impersonation and repudiation and for the operational difficulties should=20 revocation be required. =20 The choice of authentication schemes to employ may be left to=20 implementers of H-PCE and are not discussed further in this document. << *Whether this "MUST" should be BCP 14 language or not is unclear to me. DK>> We felt we should mandate "MUST" in this document and then pickup = discussion on methods and schemes in a future document as required. =20 BR, Dan and the other authors.=20 From nobody Mon May 13 13:08: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 BB1C712024B for ; Mon, 13 May 2019 13:08: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.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 FjyMoDMwgc_k for ; Mon, 13 May 2019 13:08:32 -0700 (PDT) Received: from mail-yw1-xc36.google.com (mail-yw1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) (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 24E9D120243 for ; Mon, 13 May 2019 13:08:32 -0700 (PDT) Received: by mail-yw1-xc36.google.com with SMTP id n188so12062205ywe.2 for ; Mon, 13 May 2019 13:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+4Mzn1ATYyN24cW5npVhJaDmycO4t8pWFzjcxn2cPVk=; b=kxwvMYk/K9zvX/T8wyfCDlnIFQUt36AMEYX5FM8NfvJEZK+yzUmiL1etKj2vPUOeKy HvyCSHBI53UY8Qh4/eR0nGbdu9ZkiAGr7LWSG6zTJ4QnGC7hpB1eheB2SVojqNgxzpIx 3QwyxHlyKnhWjhA8oDmwztrGu0T9WET/n0ASI= 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=+4Mzn1ATYyN24cW5npVhJaDmycO4t8pWFzjcxn2cPVk=; b=uHZe4tHqrHQZA3l9zl5pGgdoMXw6llo3hT8UGohC7kznk0dhKYJEh+UyxViIomkY1y r/+Z6b49iap0h1im2KB93IvS4gafOQresLN2pAAu3u1Hk7GuPJ/eohhn3ctCTvyxstaS MKXuKwugEPO2Jd0PZu+FX2gdYV7ebrX2z1RjQCe3E7Jz1R1t+GdzrM4U7LBwxFTLqhAw 2jLPdgTHnJvAA4chQc4U0AKkVPho752/yDQJE3DpCNozT5fn4mY5zJylFRo/w8wQRqe6 BWH3hPVFbi8XZe0yJMDJo3gvz+nbdHVniwpJZQB3thdXXsViwi48yd/Y+btmlEgdYFCL Se4g== X-Gm-Message-State: APjAAAXbzDdlwwPWTBCul0vfbWNYokiWB79DffAAwL5QUyEtVpiEYYdW 3zM7LzPhRTrDU43RzDX7TWtiGpSKudCnoI6wFhKPvg== X-Google-Smtp-Source: APXvYqzFKi3PTEoJXg1VXCnSdWHhAb8qnLRV52Xc6cDwyF6FukgAazZfGpbVsIIbuT9TC+kObAvCMcjlTugL3PVtirY= X-Received: by 2002:a0d:d947:: with SMTP id b68mr8249420ywe.464.1557778110947; Mon, 13 May 2019 13:08:30 -0700 (PDT) MIME-Version: 1.0 References: <155535945259.10773.14556389726269462856@ietfa.amsl.com> <007701d509c1$39535b80$abfa1280$@olddog.co.uk> In-Reply-To: <007701d509c1$39535b80$abfa1280$@olddog.co.uk> From: Kyle Rose Date: Mon, 13 May 2019 16:08:19 -0400 Message-ID: To: daniel@olddog.co.uk Cc: IETF SecDir , draft-ietf-pce-hierarchy-extensions.all@ietf.org, pce@ietf.org, oscar.gonzalezdedios@telefonica.com Content-Type: multipart/alternative; boundary="000000000000f13a5f0588ca7a2b" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-pce-hierarchy-extensions-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: Mon, 13 May 2019 20:08:34 -0000 --000000000000f13a5f0588ca7a2b Content-Type: text/plain; charset="UTF-8" Sounds great! I look forward to reviewing the new version. Thanks, Kyle On Mon, May 13, 2019 at 3:22 PM wrote: > Hi Kyle, > > Thank you for the review, it is most appreciated! > > We have addressed all your comments in the latest version of our I-D (v11) > but were advised to hold off posting until after the IESG telechat. > Comments inline (DK>>) on how we addressed said comments: > --000000000000f13a5f0588ca7a2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sounds great! I look forward to revi= ewing the new version.

Thanks,
Kyle
<= /div>

On Mon, May 13, 2019 at 3:22 PM <daniel@olddog.co.uk> wrote:
Hi Kyle,

Thank you for the review, it is most appreciated!

We have addressed all your comments in the latest version of our I-D (v11) = but were advised to hold off posting until after the IESG telechat. Comment= s inline (DK>>) on how we addressed said comments:
--000000000000f13a5f0588ca7a2b-- From nobody Mon May 13 17:22: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 092F8120088; Mon, 13 May 2019 17:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=packetizer.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_-gfGVPWaop; Mon, 13 May 2019 17:22:11 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (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 C69DA120026; Mon, 13 May 2019 17:22:10 -0700 (PDT) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1557793322; bh=4igxHnetA5dO9x6+P+CWjnVzAF8HmszpbAD0TI4snjA=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=T70reiBd9yQMtH7T4ufxugeu77r4kuKgwEF5a0XD3Cvj6ICAd+5BFV7Lh9PPLZ2oQ 7NjL90iMvpmJ0smyUdTodszxE15aOvgx2RtMS5n7Dt6/Iz86rAchckX+XLFfammGD4 DXXVAMqFCQvnY9MZZnoHddRjU4I4BlyuqXKm98lo= From: "Paul E. Jones" To: "Vincent Roca" Cc: "Vincent Roca" , "The IESG" , "David Benham" , draft-ietf-perc-private-media-framework.all@ietf.org, aamelnikov@fastmail.fm, secdir@ietf.org Date: Tue, 14 May 2019 00:21:56 +0000 Message-Id: In-Reply-To: <3FB301E0-1E6E-47F1-AB7B-C1194680EEF8@inria.fr> References: <155014077570.26619.9407568904769535504@ietfa.amsl.com> <6882A552-80DF-4322-9683-13D8E655F2DB@inria.fr> <1CE6DB48-325C-41C2-A526-3F5FD5FA8388@inria.fr> <3FB301E0-1E6E-47F1-AB7B-C1194680EEF8@inria.fr> Reply-To: "Paul E. Jones" User-Agent: eM_Client/7.2.34711.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBEC0B5FCF-A420-4E7C-BC8D-FB2739583C73" 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: Tue, 14 May 2019 00:22:15 -0000 --------=_MBEC0B5FCF-A420-4E7C-BC8D-FB2739583C73 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Vincent, Please see inline below: ------ Original Message ------ From: "Vincent Roca" To: "Paul E. Jones" Cc: "Vincent Roca" ; "The IESG" ;=20 "David Benham" ;=20 draft-ietf-perc-private-media-framework.all@ietf.org;=20 aamelnikov@fastmail.fm; secdir@ietf.org Sent: 5/13/2019 5:47:16 AM Subject: Re: Secdir last call review of=20 draft-ietf-perc-private-media-framework >Hello Paul, all, > > >>Le 12 mai 2019 =C3=A0 06:34, Paul E. Jones a =C3= =A9crit=20 >>: >> >>Vincent, >> >>Once again, thanks for the feedback. Please allow me to reply inline=20 >>and, if you're OK with the text, I can prepare a new revision. >> >>>** In section 8.1 it is said: >>> >>> "While confidentiality >>> would not be compromised by failing to implement mutual >>> authentication, employing it helps mitigate against denial of=20 >>>service >>> attacks wherein a false entity sends a stream of packets that the >>> would force a legitimate entity to spend time attempting to=20 >>>decrypt." >>> >>>This is true only if authenticating a received packet is cheap, which=20 >>>is >>>not necessarily the case. And in section 5 =C2=AB Authentication =C2=BB= you say=20 >>>that >>>"details of this are outside the scope of specification", so we are=20 >>>not >>>able to answer the above question: is authenticated really so cheap? >>>With certain authenticated encryption technics (e.g.=20 >>>MAC-then-Encrypt), >>>decrypting is required before checking data authenticity=E2=80=A6 So ple= ase >>>clarify. >> >>Actually, after reading that original text, I think it is even=20 >>misleading to suggest confidentiality is not compromised. In terms of=20 >>encryption, that would be true, but in terms of net effect, it would=20 >>not: without verifying the certificate, an unwanted party could=20 >>potentially engage in the conference. I think this would be better=20 >>text (replacing the entire paragraph): >> >>Use of mutual DTLS authentication (as required by DTLS-SRTP) ensures=20 >>that a >>false endpoint or false Media Distributor cannot interact with a=20 >>legitimate >>Media Distributor or endpoint. This helps mitigate against denial of=20 >>service >>attacks wherein a false entity sends a stream of packets that would=20 >>force >>a legitimate entity to spend time attempting to decrypt. >> >>With respect to whether the DoS mitigation is true or not, I think it=20 >>is. If mutual authentication fails, then no media packets would flow=20 >>at all, thus no wasted time decrypting packets; packets would likely=20 >>get rejected without inspection. If mutual authentication succeeds,=20 >>then the cost isn't at issue here, anyway, since the point of the=20 >>paragraph is to talk about a side benefit of mutual authentication. =20 >>While the specifics are outside the scope of the document, the=20 >>assumption is that some mechanism is employed to enable checking the=20 >>validity of certificates. > >[VR] Yes for the first aspect. > >Concerning DoS mitigation, wether DTLS authentication helps reducing=20 >decryption overhead at a receiver >really depends on how authentication is achieved. Looking at RFC 5764=20 >(I imagine this is where DTLS-SRTP >is defined), I read in Section 5.1.2. =C2=AB Reception =C2=BB, item 3., th= at=20 >decryption and authentication are performed >at the same step. This is in line, although no technical detail is=20 >provided, with my comment on authenticated >encryption (see also=20 >https://en.wikipedia.org/wiki/Authenticated_encryption). In some cases,=20 >decrypting is >required before checking data authenticity, so authentication won=E2=80=99= t be=20 >of any help if your goal is to avoid >=C2=AB spend[ing] time attempting to decrypt =C2=BB, what you're saying. >RFC 5764, Section 7.4. =C2=AB Decryption Cost =C2=BB, discusses decryption = cost=20 >but does not presents authentication >as a solution to mitigate it. > >What you=E2=80=99re saying in your answer, above (whether or not mutual=20 >authentication fails) is something else. >In section 8.1 we are considering 3rd party attacks, from entities that=20 >will never be authenticated. This paragraph does deal with third parties, so I think it's=20 appropriately placed. But clearly the wording still isn't quite right,=20 as it's not conveying the intended meaning. By using mutual=20 authentication, a receiving endpoint would know if the sender is or is=20 not a valid sender. There is no need to authenticate the media packets=20 received, because the DTLS handshake failed. Receivers could just=20 discard those packets without inspection. So, the receiver never even=20 gets to the point where it's dealing with the authenticated decryption=20 of packets. I revised that paragraph again. Here is the new text Use of mutual DTLS authentication (as required by DTLS-SRTP) also helps=20 to prevent a denial-of-service attack by preventing a false endpoint or=20 false Media Distributor from successfully participating as a perceived valid=20 media sender that could otherwise carry out an on-path attack. When mutual authentication fails, a receiving endpoint would know that it could=20 safely discard media packets received from the endpoint without inspection. How is that? This says nothing about the other forms of attacks, such as a "false"=20 endpoint sending bogus media packets to a receiver that carry the IP=20 address of a valid sender. In that case, the receiver would have no way=20 of knowing if the packet is valid or not until it goes through the=20 authenticated decryption process. PERC (by its use of HBH=20 authentication) would allow the receiver to detect such bogus packets,=20 but that is a valid DoS attack vector addressed in prior paragraphs in=20 that section. Paul --------=_MBEC0B5FCF-A420-4E7C-BC8D-FB2739583C73 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
= Vincent,

Please see inline below:

------ Original Message ------
From: "Vincent Roca" <vinc= ent.roca@inria.fr>
To: "Paul E. Jones" <paule= j@packetizer.com>
Sent: 5/13/2019 5:47:16 AM
Subject: Re: Secdir last call review of draft-ietf-perc-private-media-= framework

Hello Paul, all,

Le 12 mai 2019 =C3=A0 06:34, Paul E. Jones <paulej@packetizer.com> a = =C3=A9crit :

Vincent,

Once again, thanks for t= he feedback. =C2=A0Please allow me to reply inline and, if you're OK with t= he text, I can prepare a new revision.

** In section 8.1 it is said:

=C2=A0 =C2=A0"While confidenti= ality
=C2=A0 =C2=A0would not be compromised by failing = to implement mutual
=C2=A0 =C2=A0authentication, empl= oying it helps mitigate against denial of service
=C2= =A0 =C2=A0attacks wherein a false entity sends a stream of packets that the=
=C2=A0 =C2=A0would force a legitimate entity to spend = time attempting to decrypt."

<= div class=3D"">This is true only if authenticating a received packet is che= ap, which is
not necessarily the case. And in section= 5 =C2=AB=C2=A0Authentication=C2=A0=C2=BB you say that
= "details of this are outside the scope of specification", so we are not
able to answer the above question: is authenticated reall= y so cheap?
With certain authenticated encryption tech= nics (e.g. MAC-then-Encrypt),
decrypting is required b= efore checking data authenticity=E2=80=A6 So please
cl= arify.

Actually, after reading that original text, I think it is eve= n misleading to suggest confidentiality is not compromised. =C2=A0In terms= of encryption, that would be true, but in terms of net effect, it would not= : without verifying the certificate, an unwanted party could potentially en= gage in the conference. =C2=A0I think this would be better text (replacing= the entire paragraph):

Use of mutual DTLS authentication (as required by DTLS-SRTP) ens= ures that a
false endpoint or false Media Distributor canno= t interact with a legitimate
Media Distributor or endpoint.= =C2=A0 This helps mitigate against denial of service
attack= s wherein a false entity sends a stream of packets that would force
a legitimate entity to spend time attempting to decrypt.

=
With respect t= o whether the DoS mitigation is true or not, I think it is. =C2=A0If mutual = authentication fails, then no media packets would flow at all, thus no was= ted time decrypting packets; packets would likely get rejected without insp= ection. =C2=A0If mutual authentication succeeds, then the cost isn't at iss= ue here, anyway, since the point of the paragraph is to talk about a side b= enefit of mutual authentication. =C2=A0While the specifics are outside the= scope of the document, the assumption is that some mechanism is employed to = enable checking the validity of certificates.

[VR] Yes for the first aspect.

Concerning DoS mitigation, wether DTLS authent= ication helps reducing decryption overhead at a receiver
really d= epends on how authentication is achieved. Looking at RFC 5764 (I imagine th= is is where DTLS-SRTP
is defined), I read in Section 5.1.2. =C2= =AB Reception=C2=A0=C2=BB, item 3., that decryption and authentication are= performed
at the same step. This is in line, although no technica= l detail is provided, with my comment on authenticated
encryption = (see also=C2=A0https://en.wikipedia.org/wiki/Authenticated_e= ncryption). In some cases,=C2=A0decrypting is=C2=A0
required= before checking data authenticity, so authentication won=E2=80=99t be of an= y help if your goal is to avoid
=C2=AB=C2=A0spend[ing] time attem= pting to decrypt=C2=A0=C2=BB, what you're saying.=C2=A0
RFC 5764, = Section 7.4. =C2=AB Decryption Cost=C2=A0=C2=BB, discusses decryption cost = but does not presents authentication
as a solution to mitigate i= t.

What you=E2=80=99re saying in your = answer, above (whether or not mutual authentication fails) is something el= se.
In section 8.1 we are considering 3rd party attacks, from ent= ities that will never be authenticated.

This paragraph does deal with third parties, so I think = it's appropriately placed. But clearly the wording still isn't quite right= , as it's not conveying the intended meaning. =C2=A0By using mutual authent= ication, a receiving endpoint would know if the sender is or is not a valid = sender. =C2=A0There is no need to authenticate the media packets received, = because the DTLS handshake failed. =C2=A0Receivers could just discard thos= e packets without inspection. =C2=A0So, the receiver never even gets to the = point where it's dealing with the authenticated decryption of packets.

I revised that paragraph again. =C2=A0Here is th= e new text


Use of mutual DTLS authentication (as required by DTLS-SRTP) also= helps to
prevent a denial-of-service attack by preventing a false endp= oint or false
Media Distributor from successfully participating as a p= erceived valid media
sender that could otherwise carry out an on-path= attack.=C2=A0 When mutual
authentication fails, a receiving endpoint w= ould know that it could safely
discard media packets received from the = endpoint without inspection.

How is that?

This says nothing about the other forms of attacks, s= uch as a "false" endpoint sending bogus media packets to a receiver that ca= rry the IP address of a valid sender. =C2=A0In that case, the receiver woul= d have no way of knowing if the packet is valid or not until it goes throug= h the authenticated decryption process. =C2=A0PERC (by its use of HBH authe= ntication) would allow the receiver to detect such bogus packets, but that= is a valid DoS attack vector addressed in prior paragraphs in that section.=

Paul

--------=_MBEC0B5FCF-A420-4E7C-BC8D-FB2739583C73-- From nobody Tue May 14 06:10: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 D0DA21200B2; Tue, 14 May 2019 06:09:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rifaat Shekh-Yusef via Datatracker To: Cc: ietf@ietf.org, pim@ietf.org, draft-ietf-pim-igmp-mld-yang.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Rifaat Shekh-Yusef Message-ID: <155783939475.30138.17421694804504270662@ietfa.amsl.com> Date: Tue, 14 May 2019 06:09:54 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-pim-igmp-mld-yang-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 13:09:55 -0000 Reviewer: Rifaat Shekh-Yusef 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 defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) devices. The security consideration section seems to follow a well defined template for new YANG models, and lists sensitive subtrees and data nodes accordingly. The data nodes are accessible via well defined network management protocols, e.g. NETCONF and RESTCONF, and NACM is used to restrict access to a pre-configured subset per user. Regards, Rifaat From nobody Tue May 14 11:25:24 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 B935A120168; Tue, 14 May 2019 11:25:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Melinda Shore via Datatracker To: Cc: ietf@ietf.org, teas@ietf.org, draft-ietf-teas-yang-te-topo.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Melinda Shore Message-ID: <155785831655.30214.3189662700783001303@ietfa.amsl.com> Date: Tue, 14 May 2019 11:25:16 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-teas-yang-te-topo-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 18:25:17 -0000 Reviewer: Melinda Shore Review result: Not Ready This review updates my previous review of the -15 draft (see https://datatracker.ietf.org/doc/review-ietf-teas-yang-te-topo-15-secdir-lc-shore-2018-06-07/). I'm pleased to see the update to the security considerations sections, although it's still fairly generic and doesn't describe the threat environment (this may seem like a nit but it's not: describing how changes to individual subtrees may impact the system does not really detail how a malicious actor may subvert or disable the system). I think this section arguably does conform to the yang-security-guidelines template despite the missing detail and modulo the missing mandatory references to 5246 and 6536. I'm torn between marking this has "Has Issues" (because of the lack of threat description in the Security Considerations) and "Not Ready" (because of the missing mandatory references) but am going with the latter, and it's up to the IESG how heavily they'd like to weight the generic descriptions of modified subtree impacts. From nobody Wed May 15 00:26:07 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 1A260120285; Wed, 15 May 2019 00:26:00 -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, 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 FveHRFjWoCSv; Wed, 15 May 2019 00:25:56 -0700 (PDT) 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 9696D1200BA; Wed, 15 May 2019 00:25:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,471,1549926000"; d="scan'208,217";a="383222302" Received: from moucherotte.inrialpes.fr ([194.199.28.14]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 May 2019 09:25:53 +0200 From: Vincent Roca Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0DE6488E-165E-4AC0-A3C5-501162BB6556" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Wed, 15 May 2019 09:25:53 +0200 In-Reply-To: Cc: Vincent Roca , The IESG , David Benham , draft-ietf-perc-private-media-framework.all@ietf.org, aamelnikov@fastmail.fm, secdir@ietf.org To: "Paul E. Jones" References: <155014077570.26619.9407568904769535504@ietfa.amsl.com> <6882A552-80DF-4322-9683-13D8E655F2DB@inria.fr> <1CE6DB48-325C-41C2-A526-3F5FD5FA8388@inria.fr> <3FB301E0-1E6E-47F1-AB7B-C1194680EEF8@inria.fr> X-Mailer: Apple Mail (2.3445.104.8) 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: Wed, 15 May 2019 07:26:00 -0000 --Apple-Mail=_0DE6488E-165E-4AC0-A3C5-501162BB6556 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Paul, Okay, I now get it. I was not considering an attacker stupid enough to = fail authentication but who would continue sending trafic with the same identifiers. So I=E2=80=99= m okay with your explanations and new version of the paragraph. Summary: Ready Thanks, Vincent > Le 14 mai 2019 =C3=A0 02:21, Paul E. Jones a = =C3=A9crit : >=20 > Vincent, >=20 > Please see inline below: >=20 > ------ Original Message ------ > From: "Vincent Roca" > > To: "Paul E. Jones" > > Cc: "Vincent Roca" >; "The IESG" >; "David Benham" >; = draft-ietf-perc-private-media-framework.all@ietf.org = ; = aamelnikov@fastmail.fm ; secdir@ietf.org = > Sent: 5/13/2019 5:47:16 AM > Subject: Re: Secdir last call review of = draft-ietf-perc-private-media-framework >=20 >> Hello Paul, all, >>=20 >>=20 >>> Le 12 mai 2019 =C3=A0 06:34, Paul E. Jones > a =C3=A9crit : >>>=20 >>> Vincent, >>>=20 >>> Once again, thanks for the feedback. Please allow me to reply = inline and, if you're OK with the text, I can prepare a new revision. >>>=20 >>>> ** In section 8.1 it is said: >>>>=20 >>>> "While confidentiality >>>> would not be compromised by failing to implement mutual >>>> authentication, employing it helps mitigate against denial of = service >>>> attacks wherein a false entity sends a stream of packets that = the >>>> would force a legitimate entity to spend time attempting to = decrypt." >>>>=20 >>>> This is true only if authenticating a received packet is cheap, = which is >>>> not necessarily the case. And in section 5 =C2=AB Authentication =C2=BB= you say that >>>> "details of this are outside the scope of specification", so we are = not >>>> able to answer the above question: is authenticated really so = cheap? >>>> With certain authenticated encryption technics (e.g. = MAC-then-Encrypt), >>>> decrypting is required before checking data authenticity=E2=80=A6 = So please >>>> clarify. >>>=20 >>> Actually, after reading that original text, I think it is even = misleading to suggest confidentiality is not compromised. In terms of = encryption, that would be true, but in terms of net effect, it would = not: without verifying the certificate, an unwanted party could = potentially engage in the conference. I think this would be better text = (replacing the entire paragraph): >>>=20 >>> Use of mutual DTLS authentication (as required by DTLS-SRTP) ensures = that a >>> false endpoint or false Media Distributor cannot interact with a = legitimate >>> Media Distributor or endpoint. This helps mitigate against denial = of service >>> attacks wherein a false entity sends a stream of packets that would = force >>> a legitimate entity to spend time attempting to decrypt. >>>=20 >>> With respect to whether the DoS mitigation is true or not, I think = it is. If mutual authentication fails, then no media packets would flow = at all, thus no wasted time decrypting packets; packets would likely get = rejected without inspection. If mutual authentication succeeds, then = the cost isn't at issue here, anyway, since the point of the paragraph = is to talk about a side benefit of mutual authentication. While the = specifics are outside the scope of the document, the assumption is that = some mechanism is employed to enable checking the validity of = certificates. >>=20 >> [VR] Yes for the first aspect. >>=20 >> Concerning DoS mitigation, wether DTLS authentication helps reducing = decryption overhead at a receiver >> really depends on how authentication is achieved. Looking at RFC 5764 = (I imagine this is where DTLS-SRTP >> is defined), I read in Section 5.1.2. =C2=AB Reception =C2=BB, item = 3., that decryption and authentication are performed >> at the same step. This is in line, although no technical detail is = provided, with my comment on authenticated >> encryption (see also = https://en.wikipedia.org/wiki/Authenticated_encryption = ). In some = cases, decrypting is=20 >> required before checking data authenticity, so authentication won=E2=80= =99t be of any help if your goal is to avoid >> =C2=AB spend[ing] time attempting to decrypt =C2=BB, what you're = saying.=20 >> RFC 5764, Section 7.4. =C2=AB Decryption Cost =C2=BB, discusses = decryption cost but does not presents authentication >> as a solution to mitigate it. >>=20 >> What you=E2=80=99re saying in your answer, above (whether or not = mutual authentication fails) is something else. >> In section 8.1 we are considering 3rd party attacks, from entities = that will never be authenticated. >=20 > This paragraph does deal with third parties, so I think it's = appropriately placed. But clearly the wording still isn't quite right, = as it's not conveying the intended meaning. By using mutual = authentication, a receiving endpoint would know if the sender is or is = not a valid sender. There is no need to authenticate the media packets = received, because the DTLS handshake failed. Receivers could just = discard those packets without inspection. So, the receiver never even = gets to the point where it's dealing with the authenticated decryption = of packets. >=20 > I revised that paragraph again. Here is the new text >=20 >=20 > Use of mutual DTLS authentication (as required by DTLS-SRTP) also = helps to > prevent a denial-of-service attack by preventing a false endpoint or = false > Media Distributor from successfully participating as a perceived valid = media > sender that could otherwise carry out an on-path attack. When mutual > authentication fails, a receiving endpoint would know that it could = safely > discard media packets received from the endpoint without inspection. >=20 >=20 > How is that? >=20 > This says nothing about the other forms of attacks, such as a "false" = endpoint sending bogus media packets to a receiver that carry the IP = address of a valid sender. In that case, the receiver would have no way = of knowing if the packet is valid or not until it goes through the = authenticated decryption process. PERC (by its use of HBH = authentication) would allow the receiver to detect such bogus packets, = but that is a valid DoS attack vector addressed in prior paragraphs in = that section. >=20 > Paul >=20 >=20 --Apple-Mail=_0DE6488E-165E-4AC0-A3C5-501162BB6556 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= Paul,

Okay, I now = get it. I was not considering an attacker stupid enough to fail = authentication but
who would continue sending = trafic with the same identifiers. So I=E2=80=99m okay with your = explanations
and new version of the = paragraph.

Summary: Ready

Thanks,

  Vincent


Le 14 mai 2019 =C3=A0 02:21, Paul E. Jones = <paulej@packetizer.com> a =C3=A9crit :

Vincent,

Please see inline below:

------ Original Message = ------
From: "Vincent Roca" <vincent.roca@inria.fr>
To: = "Paul E. Jones" <paulej@packetizer.com>
Cc: = "Vincent Roca" <vincent.roca@inria.fr>; "The IESG" <iesg@ietf.org>; "David = Benham" <dabenham@gmail.com>; draft-ietf-perc-private-media-framework.all@ietf.org; aamelnikov@fastmail.fm; secdir@ietf.org
Sent: 5/13/2019 5:47:16 AM
Subject: Re: Secdir last call review of = draft-ietf-perc-private-media-framework

Hello Paul, all,


Le 12 = mai 2019 =C3=A0 06:34, Paul E. Jones <paulej@packetizer.com> a =C3=A9crit :

Vincent,

Once again, thanks for the feedback.  Please allow me to = reply inline and, if you're OK with the text, I can prepare a new = revision.

** In section 8.1 it = is said:

   "While confidentiality
 =  would not be compromised by failing to implement mutual
   authentication, employing it helps mitigate = against denial of service
   attacks = wherein a false entity sends a stream of packets that the
   would force a legitimate entity to spend time = attempting to decrypt."

This is true only if authenticating a received packet is = cheap, which is
not necessarily the case. And in = section 5 =C2=AB Authentication =C2=BB you say that
"details of this are outside the scope of specification", so = we are not
able to answer the above question: is = authenticated really so cheap?
With certain = authenticated encryption technics (e.g. MAC-then-Encrypt),
decrypting is required before checking data authenticity=E2=80=A6= So please
clarify.

Actually, after reading that original text, I think = it is even misleading to suggest confidentiality is not compromised. =  In terms of encryption, that would be true, but in terms of net = effect, it would not: without verifying the certificate, an unwanted = party could potentially engage in the conference.  I think this = would be better text (replacing the entire paragraph):

Use of mutual DTLS authentication (as required = by DTLS-SRTP) ensures that a
false endpoint or false Media = Distributor cannot interact with a legitimate
Media = Distributor or endpoint.  This helps mitigate against denial of = service
attacks wherein a false entity sends a stream of = packets that would force
a legitimate entity to spend time = attempting to decrypt.

With respect to whether the DoS = mitigation is true or not, I think it is.  If mutual authentication = fails, then no media packets would flow at all, thus no wasted time = decrypting packets; packets would likely get rejected without = inspection.  If mutual authentication succeeds, then the cost isn't = at issue here, anyway, since the point of the paragraph is to talk about = a side benefit of mutual authentication.  While the specifics are = outside the scope of the document, the assumption is that some mechanism = is employed to enable checking the validity of = certificates.

[VR] Yes for the first = aspect.

Concerning DoS mitigation, wether DTLS authentication helps = reducing decryption overhead at a receiver
really = depends on how authentication is achieved. Looking at RFC 5764 (I = imagine this is where DTLS-SRTP
is defined), I read = in Section 5.1.2. =C2=AB Reception =C2=BB, item 3., that decryption = and authentication are performed
at the same step. = This is in line, although no technical detail is provided, with my = comment on authenticated
encryption (see = also https://en.wikipedia.org/wiki/Authenticated_encryption). = In some cases, decrypting is 
required = before checking data authenticity, so authentication won=E2=80=99t be of = any help if your goal is to avoid
=C2=AB spend[i= ng] time attempting to decrypt =C2=BB, what you're = saying. 
RFC 5764, Section 7.4. =C2=AB = Decryption Cost =C2=BB, discusses decryption cost but does not = presents authentication
as a solution to mitigate = it.

What = you=E2=80=99re saying in your answer, above (whether or not mutual = authentication fails) is something else.
In section = 8.1 we are considering 3rd party attacks, from entities that will never = be authenticated.

This paragraph does deal with third parties, so I think it's = appropriately placed. But clearly the wording still isn't quite right, = as it's not conveying the intended meaning.  By using mutual = authentication, a receiving endpoint would know if the sender is or is = not a valid sender.  There is no need to authenticate the media = packets received, because the DTLS handshake failed.  Receivers = could just discard those packets without inspection.  So, the = receiver never even gets to the point where it's dealing with the = authenticated decryption of packets.

I = revised that paragraph again.  Here is the new text


Use of mutual DTLS authentication = (as required by DTLS-SRTP) also helps to
prevent a = denial-of-service attack by preventing a false endpoint or false
Media Distributor from successfully participating as a = perceived valid media
sender that could otherwise carry = out an on-path attack.  When mutual
authentication = fails, a receiving endpoint would know that it could safely
discard media packets received from the endpoint without = inspection.


How is that?

This = says nothing about the other forms of attacks, such as a "false" = endpoint sending bogus media packets to a receiver that carry the IP = address of a valid sender.  In that case, the receiver would have = no way of knowing if the packet is valid or not until it goes through = the authenticated decryption process.  PERC (by its use of HBH = authentication) would allow the receiver to detect such bogus packets, = but that is a valid DoS attack vector addressed in prior paragraphs in = that section.

Paul



= --Apple-Mail=_0DE6488E-165E-4AC0-A3C5-501162BB6556-- From nobody Thu May 16 05:36:29 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 6F3BA12003E for ; Thu, 16 May 2019 05:36:28 -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.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <155801018844.19700.12936606390228032328.idtracker@ietfa.amsl.com> Date: Thu, 16 May 2019 05:36:28 -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, 16 May 2019 12:36:28 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-05-16 Reviewer LC end Draft Tim Polk 2019-04-17 draft-ietf-isis-segment-routing-extensions-24 Vincent Roca R2019-02-13 draft-ietf-perc-private-media-framework-10 For telechat 2019-05-30 Reviewer LC end Draft Catherine Meadows 2019-04-12 draft-ietf-mmusic-rfc4566bis-35 Last calls: Reviewer LC end Draft Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-29 Daniel Franke 2019-03-18 draft-ietf-sidrops-https-tal-08 Daniel Gillmor 2018-03-19 draft-gutmann-scep-13 Matthew Miller 2019-04-08 draft-ietf-core-multipart-ct-03 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-08 Stefan Santesson 2019-05-08 draft-ietf-lamps-rfc6844bis-06 Sean Turner 2019-05-16 draft-ietf-sipbrandy-osrtp-09 Carl Wallace 2019-05-13 draft-ietf-tsvwg-tinymt32-01 David Waltermire 2019-02-15 draft-ietf-rtcweb-ip-handling-11 Samuel Weiler 2019-05-13 draft-ietf-grow-wkc-behavior-03 Brian Weis 2019-05-21 draft-ietf-roll-efficient-npdao-10 Klaas Wierenga 2019-02-26 draft-ietf-mpls-sr-over-ip-05 Christopher Wood 2019-05-28 draft-ietf-tram-turnbis-25 Paul Wouters 2019-05-23 draft-ietf-idr-bgp-ls-segment-routing-ext-14 Liang Xia None draft-ietf-dnssd-push-19 Taylor Yu 2019-02-15 draft-ietf-rtcweb-security-arch-18 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-12 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Kathleen Moriarty 2019-04-08 draft-ietf-bmwg-ngfw-performance-00 Next in the reviewer rotation: Christopher Wood Paul Wouters Liang Xia Taylor Yu Dacheng Zhang Derek Atkins John Bradley Nancy Cam-Winget Shaun Cooley Roman Danyliw From nobody Fri May 17 00:47:35 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 4380312004E; Fri, 17 May 2019 00:47:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liang Xia via Datatracker To: Cc: draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Liang Xia Message-ID: <155807923913.14794.15819590021470228961@ietfa.amsl.com> Date: Fri, 17 May 2019 00:47:19 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-dnssd-push-19 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, 17 May 2019 07:47:20 -0000 Reviewer: Liang Xia Review result: Has Issues Nit: 1. Section 6.1, s/This connection is made to TCP port 853, the default port for DNS-over-TLS DNS over TLS [RFC7858]./This connection is made to TCP port 853, the default port for DNS-over-TLS [RFC7858]. 2. Table 2, RECONFIRM should be C-U TLV type. Comments: 1. why are UNSUBSCRIBE and RECONFIRM the client unidirectional message? 2. In UNSUBSCRIBE message, why do you choose to use SUBSCRIBE MESSAGE ID, not NAME+TYPE+CLASS? 3. In the section of Security Considerations: 1) you should also mention that TLS provides the anti-replay protection service for DNS Push; 2) maybe you need to consider the client authentication to achieve policy control and detect illegal client; 3) TLS WG are specifying the SNI encryption mechanism, will it influence your TLS name authentication? From nobody Fri May 17 02:29: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 2D4EC1200C5; Fri, 17 May 2019 02:28:53 -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=googlemail.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 dBFM-ATbDofz; Fri, 17 May 2019 02:28:49 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 9BAD1120059; Fri, 17 May 2019 02:28:49 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id g16so4941436iom.9; Fri, 17 May 2019 02:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LlIUystNDxQaEemV0dClkVRH4aqUMQEBtyEJE2+6HVk=; b=fLdrgpzQJiGAvAWcNgdOgP2/hgFxGOBb0am2EydMQXpSD3ogtw1cQOUls5Vr5cKl7H ZR7RC/m9r33NHROAeEfO5EDusJTjg6qD9cZUs8ID2vXR+g5feamUnVnfh/1qLmw0i3bd eANpVSRwhmb3KlLs6ZcQ3nof0Kew8hKoez1MA7ctWn02M4UD3kvsbjmPl19TLo1wHTN0 tPehE+Kwb0mwrSvJD7vC+jz29+sOrKR6YBMNwOnP+hcdJbcM1d0yIEGALHh++T+BGliC Wra8uK3nL5Y5L5s+ROSa4858WM5b5U6vpflVAK3kQ1QfPbFyoWLgXeKKb95akLlY9tgW Et9w== 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=LlIUystNDxQaEemV0dClkVRH4aqUMQEBtyEJE2+6HVk=; b=PIIHx825iakub7i18vJAcPNU9PI/PNZMSG7mgjNEI/76L5EJGjhYXA0RSM26KVD0ad YGMFgcVSomylDVNLEVjvAua8nxxgebnBxIs67hL1lvINLU3TstY72b5cR1cV+OjCt/nw H99wXzwmD7S4pwDx/DPH1UVLaY2QhrakunudtNqCDw5X5qIdNYx8wXQZWMFZ4wzG4iux 8zvNQPQRB9t4IvGEup6VIFi+Gaaf3GFgVXWPNct/pwpl+lsjCs41Bi4ptdORMfBVeQWE Xqgi4SlvCTtsFxNMMOFjyQ0yaZ2LK3p78z0s14Vus/IoUxo0ZJwQe7Wgi2OPg5Z69/uh wN4g== X-Gm-Message-State: APjAAAUgZrYXySv9lo+KSxbPp89qN7/1miXq3WAxbO+Jv9nZueP4kkqw jTu7pS6QuFPPz1l2C1SBSdt4O9jnkFAmbJ6DCuw= X-Google-Smtp-Source: APXvYqy7cGYAcyNyWUo5Tr3Q8JQZqRApm9Aw4jzeaGpP3C4eTGI/mhden1e5FYZTVA3Qo1xLO8eT3YNRkJIhA2tas2g= X-Received: by 2002:a5d:9a11:: with SMTP id s17mr3866194iol.267.1558085328507; Fri, 17 May 2019 02:28:48 -0700 (PDT) MIME-Version: 1.0 References: <155492289657.22741.9562291002133198844@ietfa.amsl.com> In-Reply-To: <155492289657.22741.9562291002133198844@ietfa.amsl.com> From: Ines Robles Date: Fri, 17 May 2019 12:28:37 +0300 Message-ID: To: Daniel Migault Cc: secdir@ietf.org, roll , ietf , draft-ietf-roll-useofrplinfo.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000891967058912022d" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-roll-useofrplinfo-25 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, 17 May 2019 09:28:53 -0000 --000000000000891967058912022d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Daniel, Thank you for your review and comments. We have submitted a new version with corrections. Please find answer in-line On Wed, Apr 10, 2019 at 10:01 PM Daniel Migault via Datatracker < noreply@ietf.org> wrote: > Reviewer: Daniel Migault > Review result: Ready > > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The summary of the review is READY > > > nits: > > > > > > ROLL Working Group M. Robles > Internet-Draft Aalto > Updates: 6553, 6550, 8138 (if approved) M. Richardson > Intended status: Standards Track SSW > Expires: September 12, 2019 P. Thubert > Cisco > March 11, 2019 > > > Using RPL Option Type, Routing Header for Source Routes and IPv6-in-IPv6 > encapsulation in the RPL Data Plane > draft-ietf-roll-useofrplinfo-25 > > Abstract > > This document looks at different data flows through LLN (Low-Power > and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power > and Lossy Networks) is used to establish routing. The document > enumerates the cases where RFC 6553 (RPL Option Type), RFC 6554 > (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is > required in data plane. This analysis provides the basis on which to > design efficient compression of these headers. > """ > s/on which// > s/. /. / > """ > This document updates > RFC 6553 adding a change to the RPL Option Type. Additionally, this > document updates RFC 6550 to indicate about this change and updates > RFC8138 as well to consider the new Option Type when RPL Option is > decompressed. > > 1. Introduction > > RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) > [RFC6550] is a routing protocol for constrained networks. RFC 6553 > [RFC6553] defines the "RPL option" (RPI), carried within the IPv6 > Hop-by-Hop header to quickly identify inconsistencies (loops) in the > routing topology. RFC 6554 [RFC6554] defines the "RPL Source Route > Header" (RH3), an IPv6 Extension Header to deliver datagrams within a > > > There is certainly a reason for the RH3 spelling, but from 6554 it seems > to me that the abbreviation of Source Routing Header is SRH. > > [RFC6554 ] defines the type 3 Routing Header for IPv6 (RH3) > > RPL routing domain, particularly in non-storing mode. > > > For my personal knowledge, I do not understand why this is specific to > non-storing mode. Is the reason that in non-storing modes nodes S steer > datagram D via the root node R. The IPv6 packet (S,D) is tunneled from S > to R and then from R to D. The first tunnel from S to R does not need > SRH as nodes are able to steer this to the root (upward routing), while > downward routing needs SRH extension. > > In a storing mode *regular* routing tables are able to steer the traffic > from S, to D. There is no need of tunnel and SRH extension. > > Am I correct, or I am missing something? I apology in advance for the > noise. > > Yes, you are correct > > > > 3. Updates to RFC6553, RFC6550 and RFC 8138 > > 3.1. Updates to RFC 6553 > > This modification is required to be able to send, for example, IPv6 > packets from a RPL-aware-leaf to a not-RPL-aware node through > Internet (see Section 6.2.1), without requiring IPv6-in-IPv6 > encapsulation. > > [RFC6553] states as shown below, that in the Option Type field of the > RPL Option header, the two high order bits must be set to '01' and > the third bit is equal to '1'. The first two bits indicate that the > IPv6 node must discard the packet if it doesn't recognize the option > type, and the third bit indicates that the Option Data may change in > route. The remaining bits serve as the option type. > > > > > > > > > > > Robles, et al. Expires September 12, 2019 [Page 5] > Internet-Draft RPL-data-plane March 2019 > > > Hex Value Binary Value > act chg rest Description Reference > --------- --- --- ------- ----------------- ---------- > 0x63 01 1 00011 RPL Option [RFC6553] > > > Figure 1: Option Type in RPL Option. > > Recent changes in [RFC8200] (section 4, page 8), states: "it is now > expected that nodes along a packet's delivery path only examine and > process the Hop-by-Hop Options header if explicitly configured to do > so". Processing of the Hop-by-Hop Options header (by IPv6 > intermediate nodes) is now optional, but if they are configured to > process the header, and if such nodes encounter an option with the > first two bits set to 01, they will drop the packet (if they conform > to [RFC8200]). Host systems should do the same, irrespective of the > configuration. > > Based on that, if an IPv6 (intermediate) node (RPL-not-capable) > receives a packet with an RPL Option, it should ignore the HBH RPL > option (skip over this option and continue processing the header). > This is relevant, as it was mentioned previously, in the case that > there is a flow from RPL-aware-leaf to Internet (see Section 6.2.1). > > > I might miss something, but it seems to me that 2460 would end up in the > discard of packets with the RPL Option. 8200 introduces some > instability. Typically, packets may reach their destination depending on > the configuration of the intermediary nodes. In both cases communication > between RPL-aware and not-RPL-aware nodes needs to relax the status of > the RPL Option. It seems independent to the update of 2460. > > new text was added for clarification:=E2=80=9DWhen unclear about t= he travel of a packet, it becomes preferable for a source not to encapsulate, accepting the fact that the packet may leave the RPL domain on its way to its destination. In that event, the packet should reach its destination and should not be discarded by the first node that does not recognize the RPL option. But with the current value of the Option Type, if a node in the Internet is configured to process the HbH header, and if such node encounters an option with the first two bits set to 01 and conforms to , it will drop the packet. Host systems should do the same, irrespective of the configuration.=E2=80=9D > > Thus, this document updates the Option Type field to: the two high > order bits MUST be set to '00' and the third bit is equal to '1'. > The first two bits indicate that the IPv6 node MUST skip over this > option and continue processing the header ([RFC8200] Section 4.2) if > it doesn't recognize the option type, and the third bit continues to > be set to indicate that the Option Data may change en route. The > remaining bits serve as the option type and remain as 0x3. This > ensures that a packet that leaves the RPL domain of an LLN (or that > leaves the LLN entirely) will not be discarded when it contains the > [RFC6553] RPL Hop-by-Hop option known as RPI. > > This is a significant update to [RFC6553]. [RFCXXXX] represents this > document. > > > Hex Value Binary Value > act chg rest Description Reference > --------- --- --- ------- ----------------- ---------- > 0x23 00 1 00011 RPL Option [RFCXXXX] > > > Figure 2: Revised Option Type in RPL Option. > > > 5. Use cases > > > NOTE: There is some possible security risk when the RPI information > is released to the Internet. At this point this is a theoretical > situation; no clear attack has been described. At worst, it is clear > that the RPI option would waste some network bandwidth when it > escapes. This is traded off against the savings in the LLN by not > having to encapsulate the packet in order to remove the artifact. > > > I believe that worst means minimal here. One of the risk is at least > marking the packet as originating to/from a LLN. It may reveal the type > of the information carried by the packet in addition to the information > contained in the RPI. Possible information leaked may be related to the > topology of the LLN, but I am not familiar enough to define clearly how > this could be exploited. The information may also reveals information > about the stability of the LLN by observing the rate. IF that is correct > this could eventually provide indication an attack is effective or not. > > My understanding is that with 63 the packet is dropped after the first > non aware router, while this is not the case with 23. > > Now that I have been through the security consideration section, > I believe a sinple reference to the security consideration woudl be > sufficient. > > paragraph deleted in version 28 > > > 11. Security Considerations > > The security considerations covered in [RFC6553] and [RFC6554] apply > when the packets are in the RPL Domain. > > The IPv6-in-IPv6 mechanism described in this document is much more > limited than the general mechanism described in [RFC2473]. The > willingness of each node in the LLN to decapsulate packets and > forward them could be exploited by nodes to disguise the origin of an > attack. > > While a typical LLN may be a very poor origin for attack traffic (as > the networks tend to be very slow, and the nodes often have very low > duty cycles) given enough nodes, they could still have a significant > impact, particularly if the attack was on another LLN! > > maybe it might be clearer - at least to me, but I am not English native. > s/was on another LLN!/is targeting another LLN!/ > > fixed > > Additionally, > some uses of RPL involve large backbone ISP scale equipment > [I-D.ietf-anima-autonomic-control-plane], which may be equipped with > multiple 100Gb/s interfaces. > > Blocking or careful filtering of IPv6-in-IPv6 traffic entering the > LLN as described above will make sure that any attack that is mounted > must originate from compromised nodes within the LLN. The use of > BCP38 filtering at the RPL root on egress traffic will both alert the > operator to the existence of the attack, as well as drop the attack > traffic. As the RPL network is typically numbered from a single > prefix, which is itself assigned by RPL, BCP38 filtering involves a > single prefix comparison and should be trivial to automatically > configure. > > There are some scenarios where IPv6-in-IPv6 traffic should be allowed > to pass through the RPL root, such as the IPv6-in-IPv6 mediated > communications between a new Pledge and the Join Registrar/ > Coordinator (JRC) when using [I-D.ietf-anima-bootstrapping-keyinfra] > and [I-D.ietf-6tisch-dtsecurity-secure-join]. This is the case for > the RPL root to do careful filtering: it occurs only when the Join > Coordinator is not co-located inside the RPL root. > > > > > Robles, et al. Expires September 12, 2019 [Page 45] > Internet-Draft RPL-data-plane March 2019 > > > With the above precautions, an attack using IPv6-in-IPv6 tunnels will > be by a node within the LLN on another node within the LLN. Such an > attack could, of course, be done directly. An attack of this kind is > meaningful only if the source addresses are either fake or if the > point is to amplify return traffic. Such an attack, could also be > done without the use of IPv6-in-IPv6 headers using forged source > addresses. If the attack requires bi-directional communication, then > IPv6-in-IPv6 provides no advantages. > > [RFC2473] suggests that tunnel entry and exit points can be secured, > via the "Use IPsec". The suggested solution has all the problems > that [RFC5406] goes into. In an LLN such a solution would degenerate > into every node having a tunnel with every other node. It would > provide a small amount of origin address authentication at a very > high cost; doing BCP38 at every node (linking layer-3 addresses to > layer-2 addresses, and to already present layer-2 cryptographic > mechanisms) would be cheaper should RPL be run in an environment > where hostile nodes are likely to be a part of the LLN. > > > My understanding is that IPsec SA will be needed between each parent - > children and that a hop-by-hop decapsulation/encapsulation is happening. > If that is correct, we may avoid the situation where each node deals > with 2 * n *(n-1) SA. However without any transit devices IPsec provides > no obvious advantages over L2 security. It might be god to recommend > that one or the other layer implements security. > In addition, I am also wondering if the use of IPsec would not be > recommended as an alternative when LLN are involving communication over > the Internet. > > New text added: "Whenever IPv6-in-IPv6 headers are being proposed, there is a concern about creating security issues. In the security section of [RFC2473], it was suggested that tunnel entry and exit points can be secured, via "Use IPsec". This recommendation is not practical for RPL networks. [RFC5406] goes into some detail on what additional details would be needed in order to "Use IPsec". Use of ESP would prevent RFC8183 compression (compression must occur before encryption), and RFC8183 compression is lossy in a way that prevents use of AH. These are minor issues. The major issue is how to establish trust enough such that IKEv2 could be used. This would require a system of certificates to be present in every single node, including any Internet nodes that might need to communicate with the LLN. Thus, "Use IPsec" requires a global PKI in the general case. More significantly, the use of IPsec tunnels to protect the IPv6-in- IPv6 headers would in the general case scale with the square of the number of nodes. This is a lot of resource for a constrained nodes on a constrained network. In the end, the IPsec tunnels would be providing only BCP38-like origin authentication! Just doing BCP38 origin filtering at the entry and exit of the LLN provides a similar level amount of security without all the scaling and trust problems of using IPsec as RFC2473 suggested. IPsec is not recommended." Have a nice day, Ines, Michael and Pascal. --000000000000891967058912022d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Daniel,

Thank you f= or your review and comments. We have submitted a new version with correctio= ns. Please find answer in-line

On Wed, Apr 10, 2019 at 10:01 PM Daniel= Migault via Datatracker <noreply@ie= tf.org> wrote:
Reviewer: Daniel Migault
Review result: Ready

Hi,

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

The summary of the review is READY


nits:





ROLL Working Group=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0M. Robles
Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Aalto
Updates: 6553, 6550, 8138 (if approved)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 M. Richardson
Intended status: Standards Track=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0SSW
Expires: September 12, 2019=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0P. Thubert
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Cisco
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 March 11, 2019


Using RPL Option Type, Routing Header for Source Routes and IPv6-in-IPv6 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 encapsulatio= n in the RPL Data Plane
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft= -ietf-roll-useofrplinfo-25

Abstract

=C2=A0 =C2=A0This document looks at different data flows through LLN (Low-P= ower
=C2=A0 =C2=A0and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-P= ower
=C2=A0 =C2=A0and Lossy Networks) is used to establish routing.=C2=A0 The do= cument
=C2=A0 =C2=A0enumerates the cases where RFC 6553 (RPL Option Type), RFC 655= 4
=C2=A0 =C2=A0(Routing Header for Source Routes) and IPv6-in-IPv6 encapsulat= ion is
=C2=A0 =C2=A0required in data plane.=C2=A0 This analysis provides the basis= on which to
=C2=A0 =C2=A0design efficient compression of these headers.
"""
s/on which//
s/.=C2=A0 /. /
"""
=C2=A0 =C2=A0This document updates
=C2=A0 =C2=A0RFC 6553 adding a change to the RPL Option Type.=C2=A0 Additio= nally, this
=C2=A0 =C2=A0document updates RFC 6550 to indicate about this change and up= dates
=C2=A0 =C2=A0RFC8138 as well to consider the new Option Type when RPL Optio= n is
=C2=A0 =C2=A0decompressed.

1.=C2=A0 Introduction

=C2=A0 =C2=A0RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) =C2=A0 =C2=A0[RFC6550] is a routing protocol for constrained networks.=C2= =A0 RFC 6553
=C2=A0 =C2=A0[RFC6553] defines the "RPL option" (RPI), carried wi= thin the IPv6
=C2=A0 =C2=A0Hop-by-Hop header to quickly identify inconsistencies (loops) = in the
=C2=A0 =C2=A0routing topology.=C2=A0 RFC 6554 [RFC6554] defines the "R= PL Source Route
=C2=A0 =C2=A0Header" (RH3), an IPv6 Extension Header to deliver datagr= ams within a

<mglt>
There is certainly a reason for the RH3 spelling, but from 6554 it seems to me that the abbreviation of Source Routing Header is SRH.
</mglt>

<author> [RFC= 6554] defines the type= 3 Routing Header for IPv6

=C2=A0=C2=A0(RH3) = =C2=A0</author>


=C2=A0
<author> Yes, you are correct </author>=C2=A0=



3.=C2=A0 Updates to RFC6553, RFC6550 and RFC 8138

3.1.=C2=A0 Updates to RFC 6553

=C2=A0 =C2=A0This modification is required to be able to send, for example,= IPv6
=C2=A0 =C2=A0packets from a RPL-aware-leaf to a not-RPL-aware node through<= br> =C2=A0 =C2=A0Internet (see Section 6.2.1), without requiring IPv6-in-IPv6 =C2=A0 =C2=A0encapsulation.

=C2=A0 =C2=A0[RFC6553] states as shown below, that in the Option Type field= of the
=C2=A0 =C2=A0RPL Option header, the two high order bits must be set to '= ;01' and
=C2=A0 =C2=A0the third bit is equal to '1'.=C2=A0 The first two bit= s indicate that the
=C2=A0 =C2=A0IPv6 node must discard the packet if it doesn't recognize = the option
=C2=A0 =C2=A0type, and the third bit indicates that the Option Data may cha= nge in
=C2=A0 =C2=A0route.=C2=A0 The remaining bits serve as the option type.










Robles, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires September 12, 2019= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 5]
Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RPL-da= ta-plane=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0March 2019


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hex Value=C2=A0 =C2=A0 =C2=A0Binary Valu= e
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 act=C2=A0 chg=C2=A0 rest=C2=A0 =C2=A0 =C2=A0Description=C2=A0 = =C2=A0 =C2=A0 =C2=A0 Reference
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ---------=C2=A0 =C2=A0 =C2=A0---=C2=A0 -= --=C2=A0 -------=C2=A0 -----------------=C2=A0 ----------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x63=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A001=C2=A0 =C2=A0 1=C2=A0 =C2=A000011=C2=A0 =C2=A0RPL Option=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0[RFC6553]


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure= 1: Option Type in RPL Option.

=C2=A0 =C2=A0Recent changes in [RFC8200] (section 4, page 8), states: "= ;it is now
=C2=A0 =C2=A0expected that nodes along a packet's delivery path only ex= amine and
=C2=A0 =C2=A0process the Hop-by-Hop Options header if explicitly configured= to do
=C2=A0 =C2=A0so".=C2=A0 Processing of the Hop-by-Hop Options header (b= y IPv6
=C2=A0 =C2=A0intermediate nodes) is now optional, but if they are configure= d to
=C2=A0 =C2=A0process the header, and if such nodes encounter an option with= the
=C2=A0 =C2=A0first two bits set to 01, they will drop the packet (if they c= onform
=C2=A0 =C2=A0to [RFC8200]).=C2=A0 Host systems should do the same, irrespec= tive of the
=C2=A0 =C2=A0configuration.

=C2=A0 =C2=A0Based on that, if an IPv6 (intermediate) node (RPL-not-capable= )
=C2=A0 =C2=A0receives a packet with an RPL Option, it should ignore the HBH= RPL
=C2=A0 =C2=A0option (skip over this option and continue processing the head= er).
=C2=A0 =C2=A0This is relevant, as it was mentioned previously, in the case = that
=C2=A0 =C2=A0there is a flow from RPL-aware-leaf to Internet (see Section 6= .2.1).

<mglt>
I might miss something, but it seems to me that 2460 would end up in the discard of packets with the RPL Option. 8200 introduces some
instability. Typically, packets may reach their destination depending on the configuration of the intermediary nodes. In both cases communication between RPL-aware and not-RPL-aware nodes needs to relax the status of
the RPL Option. It seems independent to the update of 2460.=C2=A0 =C2=A0 </mglt>

<author> new text was added for clarification:=E2=80=9D= When unclear about the travel of a packet, it becomes preferable for a sour= ce not to encapsulate, accepting the fact that the packet may leave the RPL= domain on its way to its destination. In that event, the packet should rea= ch its destination and should not be discarded by the first node that does = not recognize the RPL option. But with the current value of the Option Type= , if a node in the Internet is configured to process the HbH header, and if= such node encounters an option with the first two bits set to 01 and confo= rms to <xref target=3D"RFC8200"/>, it will drop the packet.= Host systems should do the same, irrespective of the configuration.=E2=80= =9D </author>


=C2=A0

=C2=A0 =C2=A0Thus, this document updates the Option Type field to: the two = high
=C2=A0 =C2=A0order bits MUST be set to '00' and the third bit is eq= ual to '1'.
=C2=A0 =C2=A0The first two bits indicate that the IPv6 node MUST skip over = this
=C2=A0 =C2=A0option and continue processing the header ([RFC8200] Section 4= .2) if
=C2=A0 =C2=A0it doesn't recognize the option type, and the third bit co= ntinues to
=C2=A0 =C2=A0be set to indicate that the Option Data may change en route.= =C2=A0 The
=C2=A0 =C2=A0remaining bits serve as the option type and remain as 0x3.=C2= =A0 This
=C2=A0 =C2=A0ensures that a packet that leaves the RPL domain of an LLN (or= that
=C2=A0 =C2=A0leaves the LLN entirely) will not be discarded when it contain= s the
=C2=A0 =C2=A0[RFC6553] RPL Hop-by-Hop option known as RPI.

=C2=A0 =C2=A0This is a significant update to [RFC6553].=C2=A0 [RFCXXXX] rep= resents this
=C2=A0 =C2=A0document.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hex Value=C2=A0 =C2=A0 =C2=A0Binary Valu= e
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 act=C2=A0 chg=C2=A0 rest=C2=A0 =C2=A0 =C2=A0Description=C2=A0 = =C2=A0 =C2=A0 =C2=A0 Reference
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ---------=C2=A0 =C2=A0 =C2=A0---=C2=A0 -= --=C2=A0 -------=C2=A0 -----------------=C2=A0 ----------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x23=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A000=C2=A0 =C2=A0 1=C2=A0 =C2=A000011=C2=A0 =C2=A0RPL Option=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0[RFCXXXX]


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 2: Revised Op= tion Type in RPL Option.


5.=C2=A0 Use cases


=C2=A0 =C2=A0NOTE: There is some possible security risk when the RPI inform= ation
=C2=A0 =C2=A0is released to the Internet.=C2=A0 At this point this is a the= oretical
=C2=A0 =C2=A0situation; no clear attack has been described.=C2=A0 At worst,= it is clear
=C2=A0 =C2=A0that the RPI option would waste some network bandwidth when it=
=C2=A0 =C2=A0escapes.=C2=A0 This is traded off against the savings in the L= LN by not
=C2=A0 =C2=A0having to encapsulate the packet in order to remove the artifa= ct.

<mglt>
I believe that worst means minimal here. One of the risk is at least
marking the packet as originating to/from a LLN. It may reveal the type
of the information carried by the packet in addition to the information
contained in the RPI. Possible information leaked may be related to the
topology of the LLN, but I am not familiar enough to define clearly how
this could be exploited. The information may also reveals information
about the stability of the LLN by observing the rate. IF that is correct this could eventually provide indication an attack is effective or not.=C2= =A0 =C2=A0

My understanding is that with 63 the packet is dropped after the first
non aware router, while this is not the case with 23.

Now that I have been through the security consideration section,
I believe a sinple reference to the security consideration woudl be
sufficient.
</mglt>
=C2=A0

<author> paragraph deleted in version 28 </author&= gt;


=C2= =A0


11.=C2=A0 Security Considerations

=C2=A0 =C2=A0The security considerations covered in [RFC6553] and [RFC6554]= apply
=C2=A0 =C2=A0when the packets are in the RPL Domain.

=C2=A0 =C2=A0The IPv6-in-IPv6 mechanism described in this document is much = more
=C2=A0 =C2=A0limited than the general mechanism described in [RFC2473].=C2= =A0 The
=C2=A0 =C2=A0willingness of each node in the LLN to decapsulate packets and=
=C2=A0 =C2=A0forward them could be exploited by nodes to disguise the origi= n of an
=C2=A0 =C2=A0attack.

=C2=A0 =C2=A0While a typical LLN may be a very poor origin for attack traff= ic (as
=C2=A0 =C2=A0the networks tend to be very slow, and the nodes often have ve= ry low
=C2=A0 =C2=A0duty cycles) given enough nodes, they could still have a signi= ficant
=C2=A0 =C2=A0impact, particularly if the attack was on another LLN!
<mglt>
maybe it might be clearer - at least to me, but I am not English native. s/was on another LLN!/is targeting another LLN!/=C2=A0 =C2=A0
</mglt>

<author>fixed </author>=C2=A0

Additionally,
=C2=A0 =C2=A0some uses of RPL involve large backbone ISP scale equipment =C2=A0 =C2=A0[I-D.ietf-anima-autonomic-control-plane], which may be equippe= d with
=C2=A0 =C2=A0multiple 100Gb/s interfaces.

=C2=A0 =C2=A0Blocking or careful filtering of IPv6-in-IPv6 traffic entering= the
=C2=A0 =C2=A0LLN as described above will make sure that any attack that is = mounted
=C2=A0 =C2=A0must originate from compromised nodes within the LLN.=C2=A0 Th= e use of
=C2=A0 =C2=A0BCP38 filtering at the RPL root on egress traffic will both al= ert the
=C2=A0 =C2=A0operator to the existence of the attack, as well as drop the a= ttack
=C2=A0 =C2=A0traffic.=C2=A0 As the RPL network is typically numbered from a= single
=C2=A0 =C2=A0prefix, which is itself assigned by RPL, BCP38 filtering invol= ves a
=C2=A0 =C2=A0single prefix comparison and should be trivial to automaticall= y
=C2=A0 =C2=A0configure.

=C2=A0 =C2=A0There are some scenarios where IPv6-in-IPv6 traffic should be = allowed
=C2=A0 =C2=A0to pass through the RPL root, such as the IPv6-in-IPv6 mediate= d
=C2=A0 =C2=A0communications between a new Pledge and the Join Registrar/ =C2=A0 =C2=A0Coordinator (JRC) when using [I-D.ietf-anima-bootstrapping-key= infra]
=C2=A0 =C2=A0and [I-D.ietf-6tisch-dtsecurity-secure-join].=C2=A0 This is th= e case for
=C2=A0 =C2=A0the RPL root to do careful filtering: it occurs only when the = Join
=C2=A0 =C2=A0Coordinator is not co-located inside the RPL root.




Robles, et al.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires September 12, 2019= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 45]
Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RPL-da= ta-plane=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0March 2019


=C2=A0 =C2=A0With the above precautions, an attack using IPv6-in-IPv6 tunne= ls will
=C2=A0 =C2=A0be by a node within the LLN on another node within the LLN.=C2= =A0 Such an
=C2=A0 =C2=A0attack could, of course, be done directly.=C2=A0 An attack of = this kind is
=C2=A0 =C2=A0meaningful only if the source addresses are either fake or if = the
=C2=A0 =C2=A0point is to amplify return traffic.=C2=A0 Such an attack, coul= d also be
=C2=A0 =C2=A0done without the use of IPv6-in-IPv6 headers using forged sour= ce
=C2=A0 =C2=A0addresses.=C2=A0 If the attack requires bi-directional communi= cation, then
=C2=A0 =C2=A0IPv6-in-IPv6 provides no advantages.

=C2=A0 =C2=A0[RFC2473] suggests that tunnel entry and exit points can be se= cured,
=C2=A0 =C2=A0via the "Use IPsec".=C2=A0 The suggested solution ha= s all the problems
=C2=A0 =C2=A0that [RFC5406] goes into.=C2=A0 In an LLN such a solution woul= d degenerate
=C2=A0 =C2=A0into every node having a tunnel with every other node.=C2=A0 I= t would
=C2=A0 =C2=A0provide a small amount of origin address authentication at a v= ery
=C2=A0 =C2=A0high cost; doing BCP38 at every node (linking layer-3 addresse= s to
=C2=A0 =C2=A0layer-2 addresses, and to already present layer-2 cryptographi= c
=C2=A0 =C2=A0mechanisms) would be cheaper should RPL be run in an environme= nt
=C2=A0 =C2=A0where hostile nodes are likely to be a part of the LLN.

<mglt>
My understanding is that IPsec SA will be needed between each parent -
children and that a hop-by-hop decapsulation/encapsulation is happening. If that is correct, we may avoid the situation where each node deals
with 2 * n *(n-1) SA. However without any transit devices IPsec provides no obvious advantages over L2 security. It might be god to recommend
that one or the other layer implements security.=C2=A0 =C2=A0 =C2=A0
In addition, I am also wondering if the use of IPsec would not be
recommended as an alternative when LLN are involving communication over
the Internet.
<mglt>
=C2=A0
<author>
New text add= ed:
"Whenever IPv6-in-IPv6 headers are being proposed, there= is a concern about creating security issues. In the security section of [RFC2473], it was suggested that tunnel entry and exit points can be secured, via "Use IPsec". This recommendation is not practical f= or RPL networks. [RFC5406] goes into some detail on what additional details would be needed in order to "Use IPsec". Use of ESP woul= d prevent RFC8183 compression (compression must occur before encryption), and RFC8183 compression is lossy in a way that prevents use of AH. These are minor issues. The major issue is how to establish trust enough such that IKEv2 could be used. This would require a system of certificates to be present in every single node, including any Internet nodes that might need to communicate with the LLN. Thus, "Use IPsec" requires a global PKI in the general case= .

=C2=A0More significantly, the use of IPsec tunne= ls to protect the IPv6-in- IPv6 headers would in the general case scale with the square of the number of nodes. This is a lot of resource for a constrained nodes on a constrained network. In the end, the IPsec tunnels would be providing only BCP38-like origin authentication! Just doing BCP38 origin filtering at the entry and exit of the LLN provides a similar level amount of security without all the scaling and trust problems of using IPsec as RFC2473 suggested. IPsec is not recommended."=C2=A0=
</author>

Have a nice day,
=
<= span style=3D"font-size:14px;white-space:pre-wrap">Ines, Michael and Pascal= .
--000000000000891967058912022d-- From nobody Fri May 17 08:59: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 F2D6C12026C; Fri, 17 May 2019 08:59:28 -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 tKwZxbo-xNJc; Fri, 17 May 2019 08:59:27 -0700 (PDT) Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1F5B12025E; Fri, 17 May 2019 08:59:23 -0700 (PDT) Received: from [172.16.10.110] (mta-107-13-246-59.nc.rr.com [107.13.246.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id DBDBD2FD85; Fri, 17 May 2019 11:59:22 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Tom Pusateri In-Reply-To: <155807923913.14794.15819590021470228961@ietfa.amsl.com> Date: Fri, 17 May 2019 11:59:22 -0400 Cc: secdir@ietf.org, draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <233D5D9C-F966-4D3D-A06B-841203564C61@bangj.com> References: <155807923913.14794.15819590021470228961@ietfa.amsl.com> To: Liang Xia X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [secdir] [dnssd] Secdir telechat review of draft-ietf-dnssd-push-19 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, 17 May 2019 15:59:29 -0000 Thanks for the review. I can confirm that both nits need fixed. As far as your comments: 1. UNSUBSCRIBE and RECONFIRM are unidirectional because they are already = acknowledged by the transport protocol and there is nothing the client = can do in response to a DNS level Stateful Operations acknowledgement = from the server. If an UNSUBSCRIBE fails, it=E2=80=99s because it=E2=80=99s not = subscribed and the end result either way is that it=E2=80=99s not = subscribed. A RECONFIRM may trigger additional queries from the server which may or = may not result in PUSH notifications but the client has to deal with the = situation the same until a PUSH notification is received. 2. As far as using the DNS header MESSAGE ID in an UNSUBSCRIBE, this is = a consequence of not reusing outstanding message IDs over stateful = operations. This means the server must keep the state of the message id = and so associating it with the subscription is natural. Will also address TLS comments. Thanks, Tom > On May 17, 2019, at 3:47 AM, Liang Xia via Datatracker = wrote: >=20 > Reviewer: Liang Xia > Review result: Has Issues >=20 > Nit: > 1. Section 6.1, s/This connection is made to TCP port 853, the default = port for > DNS-over-TLS DNS over TLS [RFC7858]./This connection is made to TCP = port 853, > the default port for DNS-over-TLS [RFC7858]. 2. Table 2, RECONFIRM = should be > C-U TLV type. >=20 > Comments: > 1. why are UNSUBSCRIBE and RECONFIRM the client unidirectional = message? > 2. In UNSUBSCRIBE message, why do you choose to use SUBSCRIBE MESSAGE = ID, not > NAME+TYPE+CLASS? 3. In the section of Security Considerations: > 1) you should also mention that TLS provides the anti-replay = protection > service for DNS Push; 2) maybe you need to consider the client > authentication to achieve policy control and detect illegal client; = 3) TLS > WG are specifying the SNI encryption mechanism, will it influence = your TLS > name authentication? >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Fri May 17 11:39: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 C43A1120043 for ; Fri, 17 May 2019 11:39:00 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQCp_ab6IDt0 for ; Fri, 17 May 2019 11:38:59 -0700 (PDT) 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 4C98412024B for ; Fri, 17 May 2019 11:38:58 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id k24so9153344qtq.7 for ; Fri, 17 May 2019 11:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-transfer-encoding; bh=u8aKaajIbb4sgiggN9KdEyG8xxXGwQBTa//OpQs03T0=; b=BxEkrhSpYXfAfbJyyf04+uPFdoyFKTudJ0YGaZvehyDT+sxgqcLP/K3GwYCx6H8dsA sHGkRFtVHK2VSuz6DAkH/o2QiYnuFV/vYZK6dF5pApQZ+GhNQbLnxh8YaE9AGXf4VWVQ 3JPjacDjDGyTJ8Ychg1FgvRJMNCIt7BlvDJlM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-transfer-encoding; bh=u8aKaajIbb4sgiggN9KdEyG8xxXGwQBTa//OpQs03T0=; b=qxsZvl9gpvi69LlqHYdILoNdLIfZuzYxQBDDp/GqcAKJJKzShEcUIXvoFS+sQMOWhN 7c9zvKoQbnAFlYL/eQ9Qry8E3t4Dl4OjoOdrRgXgK4e1wke0n9c1TyLl7/jmNzM+ErDY QVFxfA1rhPfFWtotiDiTlei819cKR9OsJKSfrPFPzuVq1tZdTCKbUpAsdh/dnfxUU45/ Y3kkvKSQngplumuEkQXT6nVwrISJh10lVpKnQkuOesAh1cz/JKNEizNG4QNt+EwX64Yi nhspeMS+7WpkqGL9MWDYh30qWLJk86kSLaQ/jYVB1oia7dD2IKB0Mj92PvgE1rdxyNY8 mDpg== X-Gm-Message-State: APjAAAWc4RvhKpo9tjYOqM/ocqLepamekcwIIhlBZYpL/NoGyYUNDg1j udSAQHBGIGsxZZdcv3cc8gcPmpKiy5l1+Q== X-Google-Smtp-Source: APXvYqwLDbMhc8yE5iTW2o+xzq7BxmuC5vNJmO+P54AtAuvpHGiGD+bfGBXIEmj19ejO6TSvK3ZkmQ== X-Received: by 2002:a0c:d917:: with SMTP id p23mr34065911qvj.162.1558118337161; Fri, 17 May 2019 11:38:57 -0700 (PDT) Received: from [192.168.1.2] (137.sub-97-34-198.myvzw.com. [97.34.198.137]) by smtp.googlemail.com with ESMTPSA id h28sm1323621qkh.80.2019.05.17.11.38.52 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 17 May 2019 11:38:56 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.7.6.170621 Date: Fri, 17 May 2019 14:38:46 -0400 From: Carl Wallace To: , , Message-ID: Thread-Topic: secdir review of draft-ietf-tsvwg-tinymt32 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [secdir] secdir review of draft-ietf-tsvwg-tinymt32 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, 17 May 2019 18:39:01 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes the TinyMT32 Pseudo Random Number Generator (PRNG) that produces 32-bit pseudo-random unsigned integers and aims at having a simple-to-use and deterministic solution. The document is well written and the sample code produces the sample output. I am not a mathematician so no comments on the mechanism. I have a few minor nits/comments. The security considerations may benefit from repeating the last sentence of the fourth paragraph in the introduction (I.e., not 'meant to be used for cryptographic applications'). The bibliography should include all of the references cited in the draft. Adding some text or references to expand on the mentioned limitations of RFC5170 or to describe how the parameter set from which the parameters selected in this draft would be nice as well. From nobody Tue May 21 22:31:46 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 67F1D1200F3; Tue, 21 May 2019 22:31:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Brian Weis via Datatracker To: Cc: draft-ietf-roll-efficient-npdao.all@ietf.org, roll@ietf.org, iesg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Brian Weis Message-ID: <155850309037.2348.11704172157194914151@ietfa.amsl.com> Date: Tue, 21 May 2019 22:31:30 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-roll-efficient-npdao-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: Wed, 22 May 2019 05:31:31 -0000 Reviewer: Brian Weis 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. This document addresses a reliability problem with removing routes in RPL. Currently, when a node in the network determines to change the route by which data is delivered to itself, it sends an “add route” message (DAO) to the new upstream adjacency indicating that this its new route. It also sends a “delete route” message (NPDAO) to the old upstream adjacency indicating that the old route is to be torn down. Both the DAO and NPDAO are to be forwarded upstream by the receiving adjacencies until they reach a common ancestor. However, if the NPDAO message gets lost then data sent to the node may fail because the its no longer listening the adjacency beginning the old path. To solve this reliability problem, this document defines a new Destination Cleanup Option (DCO) message that is initiated from a common parent to both the old and new routes. When the common ancestor sees a request to send a DCO come upstream from a node, it creates and sends a DCO down the path where the NPDAO should have come. Thus, the new DCO downsteam message should make up for a loss of a potential lost NPDAO upstream message. RPL is a distance vector protocol. In most distance vector protocols, each node summarizes its routing table and sends the summary to their peers. From a security perspective, the peers receiving these messages can at best validate that the information was provided by a trusted peer but they cannot validate whether the routing summary or any other information in the message (e.g, the message header) is accurate or not. They cannot validate messages sent from a “peer of a peer” or further along the graph. So if any previous node in the graph lied than the lie is propagated. I believe RPL also works this way, although I’d be happy to be corrected and it could change the results of this review. >From a security considerations perspective then, we can’t usually expect more than for a node to validate that a trusted peer has sent this data. RPL can validate this using a MAC (keyed by either a group or pair-wise key, or a digital signature. This document describes these options, and this is good. However, note that there doesn't seem to be a facility for verifying that any part of the message propagated by a "peer of a peer", etc. is accurate. However, I believe that the network flow of this DCO brings in some additional risks in the context of a distance vector protocol. The security considerations does mention that a rogue ancestor could imitate a malicious route invalidation, and that’s a good statement. But I think the risk goes beyond that. This document adds a signal (the “I” bit) to an upstream RPL routing message. This “I” bit indicates that any ancestor should invalidate any previous routes that it has. The intent is for the node initiating a legitimate routing change to request an ancestor having more than one downstream route to that node to send a DCO down the old route. But if any node along the path can create this header, then not only the initiating node can add the "I" bit — any malicious node forwarding the RPL frame upstream can also add it. That would (I think for the first time) allow a malicious node to explicitly cause another off-path route to be destroyed — potentially leaving a target with no routes to it at all. This attack should be described in the security considerations as a risk. It’s at a very least a problem when all of the nodes share a MAC key, and if I’m correct that only neighbor MACs or signatures are verified in RPL then it’s a problem even if the secure version of messages is deployed because a “peer of a peer” or earlier node could have added the “I” bit. Another aspect of this new network flow is that previously a node could have protected itself from attacks deleting routes by only accepting a change of route from an adjacency representing the routed path. Spoofed “delete path” messages could be ignored from other adjacencies. That seems no longer possible with the DCO, since by definition it comes downstream rather than upstream direction from the node (possibly) changing its routes. If there’s any operational mitigation possible by which a node could protect itself against spoofed “delete path” messages then this should be added to security considerations. From nobody Thu May 23 07:07:01 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 4E119120077 for ; Thu, 23 May 2019 07:07:00 -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.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <155862042027.17153.7568596904743446795.idtracker@ietfa.amsl.com> Date: Thu, 23 May 2019 07:07:00 -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, 23 May 2019 14:07:01 -0000 Note, that there are more rereview request than normally, as the review tool system is currently somewhat broken, which makes it very hard for me to check whether I should assign documents for rereview, so I outsourced that to you :-) I.e., if your previous review was Ready and there is nothing major changed in the draft, simply send Still ready review. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-05-30 Reviewer LC end Draft Catherine Meadows 2019-04-12 draft-ietf-mmusic-rfc4566bis-35 Adam Montville R2019-01-10 draft-ietf-lamps-hash-of-root-key-cert-extn-05 Hilarie Orman R2019-04-10 draft-ietf-acme-caa-07 Stefan Santesson 2019-05-08 draft-ietf-lamps-rfc6844bis-06 Sean Turner 2019-05-16 draft-ietf-sipbrandy-osrtp-09 Carl Wallace R2019-05-13 draft-ietf-tsvwg-tinymt32-02 Last calls: Reviewer LC end Draft Derek Atkins 2019-06-06 draft-ietf-pce-association-group-09 Nancy Cam-Winget 2019-06-04 draft-ietf-sipcore-rejected-08 Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-29 Roman Danyliw 2019-06-04 draft-ietf-rtgwg-enterprise-pa-multihoming-08 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Linda Dunbar 2019-06-04 draft-ietf-netvc-requirements-09 Donald Eastlake 2019-05-31 draft-ietf-softwire-map-radius-23 Shawn Emery 2019-05-31 draft-ietf-bfd-vxlan-07 Stephen Farrell 2019-05-30 draft-ietf-pce-inter-area-as-applicability-07 Daniel Franke 2019-03-18 draft-ietf-sidrops-https-tal-08 Daniel Gillmor 2018-03-19 draft-gutmann-scep-13 Phillip Hallam-Baker None draft-ietf-intarea-provisioning-domains-04 Christian Huitema R2019-06-04 draft-ietf-anima-bootstrapping-keyinfra-20 Matthew Miller 2019-04-08 draft-ietf-core-multipart-ct-03 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-08 Tim Polk 2019-04-17 draft-ietf-isis-segment-routing-extensions-25 David Waltermire 2019-02-15 draft-ietf-rtcweb-ip-handling-11 Samuel Weiler 2019-05-13 draft-ietf-grow-wkc-behavior-04 Klaas Wierenga 2019-02-26 draft-ietf-mpls-sr-over-ip-05 Christopher Wood 2019-05-28 draft-ietf-tram-turnbis-25 Paul Wouters 2019-05-23 draft-ietf-idr-bgp-ls-segment-routing-ext-14 Taylor Yu 2019-02-15 draft-ietf-rtcweb-security-arch-18 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-12 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Kathleen Moriarty 2019-04-08 draft-ietf-bmwg-ngfw-performance-00 Next in the reviewer rotation: Steve Hanna Dan Harkins Russ Housley Christian Huitema Leif Johansson Benjamin Kaduk Charlie Kaufman Scott Kelly Stephen Kent Tero Kivinen From nobody Thu May 23 08:10:19 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C4D120111; Thu, 23 May 2019 08:10:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Paul Wouters via Datatracker To: Cc: idr@ietf.org, ietf@ietf.org, draft-ietf-idr-bgp-ls-segment-routing-ext.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Paul Wouters Message-ID: <155862420199.17104.3515279447343748635@ietfa.amsl.com> Date: Thu, 23 May 2019 08:10:02 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-idr-bgp-ls-segment-routing-ext-14 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, 23 May 2019 15:10:03 -0000 Reviewer: Paul Wouters Review result: Has Issues Reviewer: Paul Wouters Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Note: I'm not a segment routing or BGP expert, so I might have misunderstood some things. As far as I can understand the Security Considerations, it seems that it is adequately pointing to other documents and mentions, with solutions, new concerns raised by implememting this document. I do have a number of comments and suggested improvements for the tables and figures layout, and some questions about IANA registries. See below for details. Paul Section 2.1 Can the IANA registry be referenced here so the reader can easilly go to see the entire list of Node Attribute TLVs ? Section 2.1.1 I personally find Figures to have more readable with less -+-+-+-+ symbols eg to change Figure 2 to: 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 +-------------------------------+-------------------------------+ | Type | Length | +-------------------------------+-------------------------------+ ~ SID/Label (variable) ~ +---------------------------------------------------------------+ Note that since the SID/Label is a variable length, I used the "~" symbol as in common to donate that. And important in this case too, as I was thinking it was a fixed size but reading the description found out it was either 3 or 4 bytes. I see the document uses // for this elsewhere, which is also okay. Type: 1161 I would write: Type: set to 1161 denoting a SID/Label Node Attribute Length: Either 3 or 4 depending whether [...] I find this language confusing. It suggests the Length field can be of size 3 or 4, instead of saying the Length field value can be 3 or 4. then the 20 rightmost bits represent a label Should it be specified what to do with the 4 leftmost bits? Are they reserved? used for something else ? Section 2.1.2 I find the split Range Size vs / SID/Label confusing. The table is supposed to give me an idea of the byte stream, but by being split it two it doesn't do that well. How about this: 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 +-------------------------------+-------------------------------+ | Type | Length | +---------------+---------------+-------------------------------+ | Flags | Reserved | Range Size, or | +---------------+---------------+ | ~ SID/Label sub-TLV ~ +---------------------------------------------------------------+ I find this bit a little misleading in our way of writing it: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // SID/Label sub-TLV (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Because I don't think Range Size is really 20 bits and the next 4 bits can be used for another payload. I assume those unspecified 4 bits are reserved and set to 0? Type: 1034 I would write: Type: set to 1034 denoting an SR Capabilities Node Attribute Length: Variable. Minimum length is 12. Again, it find this confusing. The length field itself is not variable length and has no minimum length of 12. I would write: Length: two octects in network order, specifying the length of the Range Size or SID/Label sub-TLV Reserved: 1 octet that SHOULD be set to 0 and MUST be ignored on receipt. Why is that SHOULD not a MUST? One or more entries, each of which have the following format: Is this really "one or more entries"? The table above does not show that at all. Can we only have more entries of the same capabilities or can they be mixed (eg one range size and two SID/Labels ??) If there is more than one entry, how would one know whether these are RAnge Sizes or SID/Labels? If there is only one, then the Length denotes that implicitely. Since the SID/Label sub-TLV is used to indicate the first label of the SRGB range, only label encoding is valid under the SR Capabilities TLV. Does this mean the above "one or more entries" is actually restricted and means "one or more rang sizes, followed by 0 or 1 SID/Labels" ? The ambiguity perceived means I can not fully deducate the field contents as it is currently specified. Section 2.1.3 Similar remarks to the sections above here regarding the field descriptions. I would enclose Algorithm 1, since 1 is the minimum and close the table, since our content description does end (based on the Length field) 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 +-------------------------------+-------------------------------+ | Type | Length | +---------------+---------------+---------------+---------------+ | Algorithm 1 | Algorithm... ~ Algorithm N ~ | +---------------+---- | ~ ~ +---------------------------------------------------------------+ Section 2.1.4 See my similar comments above. Additionally, one Range Size and SID label should be added to the diagram unconditionally, as the minimum is one, and then the block follows of optional additional blocks of range size plus SID/Label. Section 2.1.5 See similar comments above. Section 2.2 These TLVs should only be added to [...] Should that "should" be a SHOULD (or MUST?) Section 2.2.1 See similar comments above that apply to this table and values. Here it is even more important because Length appears even more variable because Flags is described as a static "one octet". And then "weight" isn't given an octet size but the following Reserved field is. Should the SHOULD in the reserved field description be a MUST ? Especially for reserved fields, I see no reason why it is not a MUST. If this is left unchecked by an implementation and possibly filled with bogus data, while that will not break anything NOW, as the document also states "MUST ignore", but once any of these fields get defined in the future, it would break. So it is better to dictate now to not leave it with potential garbage values. [The Following sections all have the same characteristics as the above ones, so I won't mention these further in the review, but I think these should be fixed similarly.] Section 2.2.3 This table seems to extend an existing table in what I hope is some kind of IANA registry? Can that be referenced here? If there is no IANA registry of these, and this seems to extend a list of entries from RFC 7752 and RFC 8571, I would suggest this document creates that new IANA registry and populates it with all those values. Section 2.3 Similar here, should this be a new IANA Registry? Section 2.3.4 If the Prefix NLRI is not considered a "normal routing prefix", what is it considered as? What implications does that have? need to be interpreted accordingly Is that "need to" not a MUST ? or perhaps rephrase this as: The Flags field of this TLV are interpreted accordingly to the respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. Section 3 We normally don't say early code points were assigned. We just say what we request(ed) from IANA. Also, can the registies named be linked to IANA? "should be left empty" -> "is left empty" The table in Section 3.1 seems to extend an existing table/registry. Can it be named and linked so the reader can jump the the IANA registry ? NITS: Abstract: This draft -> This document Introduction: This sentence seems malformed: A segment can represent any instruction, topological or service-based. or global within a domain. -> or a global semantic within a domain. Within IGP topologies an SR path -> Within IGP topologies, an SR path Use of "segement" vs "Segment" in the Introduction is inconsistent Figure 1 describes -> Figure 1 denotes then can -> can Section 2.1.1 as a label or an index/SID. -> as a label or as an index/SID Section 2.2.1 The Protocol-ID of the BGP-LS Link NLRI should be used to determine the underlying protocol specification for parsing these fields. I would change the "should be" to an "is", as there is no chocie here. That is how it is. Similar in other sections, such as 2.3.1 Section 2.3.4 is considered as a normal routing -> is considered a normal routing From nobody Thu May 23 08:28: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 4D627120129; Thu, 23 May 2019 08:28:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Phillip Hallam-Baker via Datatracker To: Cc: draft-ietf-intarea-provisioning-domains.all@ietf.org, int-area@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Phillip Hallam-Baker Message-ID: <155862531425.17228.10846494091656668654@ietfa.amsl.com> Date: Thu, 23 May 2019 08:28:34 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-intarea-provisioning-domains-04 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, 23 May 2019 15:28:35 -0000 Reviewer: Phillip Hallam-Baker Review result: Serious Issues This draft gives some long overdue attention to an issue that has become increasingly problematic in real world contexts. Since this is an early review, I am focusing on the types of issues that need to be addressed during development. One issue that had me somewhat confused at first is the initial sentence. "An increasing number of hosts access the Internet via multiple interfaces". Reading the draft, there appears to be an implicit assumption that the access is sequential (mobile device going from one coffee shop to another) even though the referenced document is very much focused on parallel. It would be helpful if there was some grounding context early on in the document to provide this context, something like: If Alice has a mobile phone provider and a broadband provider in her home, her devices should be capable of seamlessly transitioning from one to the other. So that if the broadband fails, the Internet service can gracefully failover to the mobile and vice versa for upgrades. This draft isn't going to solve that problem but providing the basic information necessary to make this choice intelligently is going to be crucial to any solution. There are similar concerns for IPSEC VPN. This particular proposal is situated at a very low level in the stack but is making use of application level protocols to achieve its effect. I think this is a perfectly valid approach but does mean that the issue of recursive dependencies have to be considered and in particular in the security considerations. At present, the draft is structured to describe an IP packet format and then the data that can be accessed. I suggest reversing these and presenting the PvD schema first and then the IP packet as one choice of binding, we are likely to want to add more. If I am provisioning an IPSEC VPN configuration to a client, it would be logical to either include the PvD in the IPSEC connection description or vice versa. This is particularly the case if we end up signing the data (see later). Turning to the security concerns, it is usually helpful to consider these in terms of Confidentiality, Integrity and Availability and the network layer at which the protocol operates. In this case, the proposal appears to be link layer since it is providing information to a host connecting to a network. But the information provided includes (potentially) DNS services and so it is going to affect the whole stack from the link up to the application layer. Since this is link layer, there is a certain degree of implicit integrity achieved because the host has either a direct physical connection or at least proximity to the network. It is probably prudent to distinguish the cases of hosts connecting wirelessly and physically since a physical connection provides a higher degree of implicit integrity than wireless. Taking the most important consideration first, what is the potential for (ab)using this approach to perform a service attack? Here we should consider the possibility of an attack on the host itself and the use of the mechanism to relay attacks onto other hosts. I have not thought of any attacks of this type yet but this is the area that gives me the most concern. Integrity presents two considerations, first there is the question of whether the data has been modified, the second is where it came from in the first place. The use of TLS does not necessarily provide a strong binding to the domain. At the very least, data would have to be retrieved from a URL in some portion of the address space that is reserved for administrative use. While .well-known is often used for this purpose, it is not always valid. Another issue with TLS is that we start off with a fairly strong implicit integrity from the link and discard that for a repudiable authentication via TLS. I would prefer to keep both if we can. Rather than relying on TLS, a shorter distance between the two points would be to sign the PvD specification with JOSE. This need not be too onerous. A client that wants to rely on just the TLS integrity can simply Base64 decode and trust the data as being implicitly authentic because of the means of retrieval. The bigger payoff from signing the PvD is that we no longer need to worry about how it is retrieved. The killer app for DNSSEC is turning out to be the ability to divorce DNS data from DNS transport. There are certain situations in which the fact that the PvD is delivered over a particular link is significant but there are other situations in which it might not. For example, I have 12 smoke alarms in my ceilings, one of which I can only (safely) reach by erecting scaffolding. These smoke alarms are all connected to a WiFi router that failed and the only option the manufacturer (which I won't name but rhymes with sproogle) gives for updating the SSID is to reconfigure each one in turn. It would be really nice if I could program multiple SSIDs into the devices to provide failover. Contrawise, this capability could be extended to facilitate the initial connection of the devices to my network. While this is not a feature the WG is likely interested in right now, it is one that I am working on for the Mathematical Mesh and it is obviously a good idea if we have as much commonality between the top down and bottom up configs. Confidentiality is not generally a direct concern at the link layer but corruption of the data (i.e. an integrity attack) might allow a disclosure breach. But this should be stated explicitly. Finally, as a gen-art issue, the use of x-options is generally deprecated as it at best ends up with a situation where every client has to accept headers in both the prefixed and unprefixed form. An IANA registry with first-come, first-served registration fulfills the goal of preventing accidental collisions more effectively. From nobody Thu May 23 17:46: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 D08BB12018F; Thu, 23 May 2019 17:45:59 -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 cP6Ib0gAo8t1; Thu, 23 May 2019 17:45:57 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 39B3B120041; Thu, 23 May 2019 17:45:57 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id g16so6410222iom.9; Thu, 23 May 2019 17:45:57 -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=kab1Yvppxj5oDoq19tRC5Tcbkzwwf3pdPKRiBQibWsk=; b=VyR5VXre2dMAOahqKAButsevDNRqtvDXtmMDhI07aYi9ny42BftDFBtDMxyi9F+C5D PT0Ir8PCgsjOe3H1kn+tRXTTBAQOahYi6KCUhV5DLivGjoNJR6AYTGeOUihwEM+slU4U QggvH1PyytJe1LczG1rWA8/juu1JTgFeuC/vtseXRsejs/0uaPJ5L/VifFdUtHiE5wEh FPl5QQ0zSaTZz3q+R7TK9IldsMM2M4aRmF6k4OnjYl/X4ubRwDI8o3eZgLhimjikZnid tGt1viOGMycQsVxJ27hjRDC9eYAB/9aBEVPLb4Okym86kki/mD009j4ZyFJMGdUtlBci Ajrg== 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=kab1Yvppxj5oDoq19tRC5Tcbkzwwf3pdPKRiBQibWsk=; b=mg4XonVqAmojPXNcvO7RUJmDrlqCCdvyh7Veq11hX51kqCz1h37+sd4aWF4YYckFib v8US037KihtU4xySUq8qu4lPrhO7fHM5w1lv4KinzxDGfJwXqUQQeq6sON+GMSqQCXct IUG+358FF3xJG1xZJq527JJc2sP23Zku793v5Ky+LHo0Obm+nNQdgedSPnlWjuvHFHxd 5o1OsP0xsBrHRpMMUSaLBCgu6UtS9VCcjB6rdT0kjrSEDO6OLVL4LXdacDU5t9uQLbyT 9lb4+2BZoOu8+PHPHek8BJ80KvGEbb25Zx2GNFlMkW8t+IhzZgGi1jexeOIpIKXjWLp2 AW3A== X-Gm-Message-State: APjAAAXa7UfFXzqoNUy/E74D8Z9Ov7hQd+GNtwHWhZEO4Fp1UXs4DtI1 bCRgCCX6hdfBWSVgTQvWJ0x/bFTf0NwDE1K0WUDU0t9Y X-Google-Smtp-Source: APXvYqxxEZ0FzfKOdR6lPn+Mpr0mBxXJUXe4V+y6/xZhkYgapuo1yaR89Eq2AFn6BE22MFIULugCaEXZhQde6ewj9pc= X-Received: by 2002:a6b:4e10:: with SMTP id c16mr2030880iob.181.1558658756288; Thu, 23 May 2019 17:45:56 -0700 (PDT) MIME-Version: 1.0 References: <155785831655.30214.3189662700783001303@ietfa.amsl.com> In-Reply-To: <155785831655.30214.3189662700783001303@ietfa.amsl.com> From: Xufeng Liu Date: Thu, 23 May 2019 20:45:45 -0400 Message-ID: To: Melinda Shore Cc: secdir@ietf.org, ietf , TEAS WG , draft-ietf-teas-yang-te-topo.all@ietf.org Content-Type: multipart/alternative; boundary="0000000000007eadbd0589978568" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-teas-yang-te-topo-20 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, 24 May 2019 00:46:00 -0000 --0000000000007eadbd0589978568 Content-Type: text/plain; charset="UTF-8" Hi Melinda, Thanks for the review. We have posted the updated revision https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-21 to address these issues. We have updated the text in the Security Considerations section to describe the possible actions by a malicious attacker. As for the mandatory references to RFC5246 and RFC6536, they were obsoleted by newer RFCs so we replaced them with the newer ones. RFC5246 has been obsoleted by RFC8446, so we now use RFC8446 instead. Do we still need to reference RFC5246? RFC6536 has been obsoleted by RFC8341, so we now use RFC8341 instead. Do we still need to reference RFC6536? Thanks, - Xufeng On Tue, May 14, 2019 at 2:25 PM Melinda Shore via Datatracker < noreply@ietf.org> wrote: > Reviewer: Melinda Shore > Review result: Not Ready > > This review updates my previous review of the -15 draft (see > > https://datatracker.ietf.org/doc/review-ietf-teas-yang-te-topo-15-secdir-lc-shore-2018-06-07/ > ). > I'm pleased to see the update to the security considerations sections, > although it's still fairly generic and doesn't describe the threat > environment > (this may seem like a nit but it's not: describing how changes to > individual > subtrees may impact the system does not really detail how a malicious > actor may > subvert or disable the system). I think this section arguably does > conform to > the yang-security-guidelines template despite the missing detail and > modulo the > missing mandatory references to 5246 and 6536. I'm torn between marking > this > has "Has Issues" (because of the lack of threat description in the Security > Considerations) and "Not Ready" (because of the missing mandatory > references) > but am going with the latter, and it's up to the IESG how heavily they'd > like > to weight the generic descriptions of modified subtree impacts. > > --0000000000007eadbd0589978568 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Melinda,

Thanks for the review. We have posted the updated revis= ion https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-21 to address= these issues. We have updated the text in the Security Considerations sect= ion to describe the possible actions by a malicious attacker. As for the ma= ndatory references to RFC5246 and RFC6536, they were obsoleted by newer RFC= s so we replaced them with the newer ones.
RFC5246 has been obsoleted by= RFC8446, so we now use RFC8446 instead. Do we still need to reference RFC5= 246?
RFC6536 has been obsoleted by RFC8341, so we now use RFC8341 inste= ad. Do we still need to reference RFC6536?

Thanks,
- Xufeng
=
On Tue= , May 14, 2019 at 2:25 PM Melinda Shore via Datatracker <noreply@ietf.org> wrote:
<= /div>
Reviewer: Melinda Sh= ore
Review result: Not Ready

This review updates my previous review of the -15 draft (see
https:/= /datatracker.ietf.org/doc/review-ietf-teas-yang-te-topo-15-secdir-lc-shore-= 2018-06-07/).
=C2=A0I'm pleased to see the update to the security considerations sect= ions,
although it's still fairly generic and doesn't describe the threat = environment
(this may seem like a nit but it's not: describing how changes to indiv= idual
subtrees may impact the system does not really detail how a malicious actor= may
subvert or disable the system).=C2=A0 I think this section arguably does co= nform to
the yang-security-guidelines template despite the missing detail and modulo= the
missing mandatory references to 5246 and 6536.=C2=A0 I'm torn between m= arking this
has "Has Issues" (because of the lack of threat description in th= e Security
Considerations) and "Not Ready" (because of the missing mandatory= references)
but am going with the latter, and it's up to the IESG how heavily they&= #39;d like
to weight the generic descriptions of modified subtree impacts.

--0000000000007eadbd0589978568-- From nobody Fri May 24 19:20: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 CC3111200D6; Fri, 24 May 2019 19:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 klMmgoaOEuvC; Fri, 24 May 2019 19:19:54 -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 E2C421200B2; Fri, 24 May 2019 19:19:53 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 3D658702811EBA2B322A; Sat, 25 May 2019 03:19:52 +0100 (IST) Received: from BLREML701-CAH.china.huawei.com (10.20.4.170) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 25 May 2019 03:19:51 +0100 Received: from BLREML503-MBX.china.huawei.com ([169.254.9.12]) by blreml701-cah.china.huawei.com ([::1]) with mapi id 14.03.0439.000; Sat, 25 May 2019 07:49:41 +0530 From: Rahul Arvind Jadhav To: Brian Weis , "secdir@ietf.org" CC: "draft-ietf-roll-efficient-npdao.all@ietf.org" , "roll@ietf.org" , "iesg@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-roll-efficient-npdao-10 Thread-Index: AQHVEF+kPZOse9hlP0Gpjn3Hi0irHKZ7FCTQ Date: Sat, 25 May 2019 02:19:40 +0000 Message-ID: <982B626E107E334DBE601D979F31785C5DEC4384@BLREML503-MBX.china.huawei.com> References: <155850309037.2348.11704172157194914151@ietfa.amsl.com> In-Reply-To: <155850309037.2348.11704172157194914151@ietfa.amsl.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.157.44] 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 last call review of draft-ietf-roll-efficient-npdao-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: Sat, 25 May 2019 02:19:56 -0000 VGhhbmtzIEJyaWFuIGZvciB0aGUgcmV2aWV3LiBUaGUgY29tbWVudHMgd2lsbCBiZSBhZGRyZXNz ZWQgaW4gdGhlIG5leHQgZHJhZnQgdXBkYXRlLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo6Ojo6DQo+IA0KPiA+RnJvbSBhIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHBlcnNwZWN0 aXZlIHRoZW4sIHdlIGNhbuKAmXQgdXN1YWxseQ0KPiA+ZXhwZWN0IG1vcmUNCj4gdGhhbiBmb3Ig YSBub2RlIHRvIHZhbGlkYXRlIHRoYXQgYSB0cnVzdGVkIHBlZXIgaGFzIHNlbnQgdGhpcyBkYXRh LiBSUEwgY2FuDQo+IHZhbGlkYXRlIHRoaXMgdXNpbmcgYSBNQUMgKGtleWVkIGJ5IGVpdGhlciBh IGdyb3VwIG9yIHBhaXItd2lzZSBrZXksICBvciBhDQo+IGRpZ2l0YWwgc2lnbmF0dXJlLiBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyB0aGVzZSBvcHRpb25zLCBhbmQgdGhpcyBpcyBnb29kLg0KPiBI b3dldmVyLCBub3RlIHRoYXQgdGhlcmUgZG9lc24ndCBzZWVtIHRvIGJlIGEgZmFjaWxpdHkgZm9y IHZlcmlmeWluZyB0aGF0IGFueQ0KPiBwYXJ0IG9mIHRoZSBtZXNzYWdlIHByb3BhZ2F0ZWQgYnkg YSAicGVlciBvZiBhIHBlZXIiLCBldGMuIGlzIGFjY3VyYXRlLg0KPiANCj4gSG93ZXZlciwgSSBi ZWxpZXZlIHRoYXQgdGhlIG5ldHdvcmsgZmxvdyBvZiB0aGlzIERDTyBicmluZ3MgaW4gc29tZQ0K PiBhZGRpdGlvbmFsIHJpc2tzIGluIHRoZSBjb250ZXh0IG9mIGEgZGlzdGFuY2UgdmVjdG9yIHBy b3RvY29sLiAgVGhlIHNlY3VyaXR5DQo+IGNvbnNpZGVyYXRpb25zIGRvZXMgbWVudGlvbiB0aGF0 IGEgcm9ndWUgYW5jZXN0b3IgY291bGQgaW1pdGF0ZSBhIG1hbGljaW91cw0KPiByb3V0ZSBpbnZh bGlkYXRpb24sIGFuZCB0aGF04oCZcyBhIGdvb2Qgc3RhdGVtZW50LiBCdXQgSSB0aGluayB0aGUg cmlzayBnb2VzDQo+IGJleW9uZCB0aGF0Lg0KPiANCj4gVGhpcyBkb2N1bWVudCBhZGRzIGEgc2ln bmFsICh0aGUg4oCcSeKAnSBiaXQpIHRvIGFuIHVwc3RyZWFtIFJQTCByb3V0aW5nIG1lc3NhZ2Uu DQo+IFRoaXMg4oCcSeKAnSBiaXQgaW5kaWNhdGVzIHRoYXQgYW55IGFuY2VzdG9yIHNob3VsZCBp bnZhbGlkYXRlIGFueSBwcmV2aW91cyByb3V0ZXMNCj4gdGhhdCBpdCBoYXMuICBUaGUgaW50ZW50 IGlzIGZvciB0aGUgbm9kZSBpbml0aWF0aW5nIGEgbGVnaXRpbWF0ZSByb3V0aW5nIGNoYW5nZSB0 bw0KPiByZXF1ZXN0IGFuIGFuY2VzdG9yIGhhdmluZyBtb3JlIHRoYW4gb25lIGRvd25zdHJlYW0g cm91dGUgdG8gdGhhdCBub2RlDQo+IHRvIHNlbmQgYSBEQ08gZG93biB0aGUgb2xkIHJvdXRlLiBC dXQgaWYgYW55IG5vZGUgYWxvbmcgdGhlIHBhdGggY2FuIGNyZWF0ZQ0KPiB0aGlzIGhlYWRlciwg dGhlbiBub3Qgb25seSB0aGUgaW5pdGlhdGluZyBub2RlIGNhbiBhZGQgdGhlICJJIiBiaXQg4oCU IGFueQ0KPiBtYWxpY2lvdXMgbm9kZSBmb3J3YXJkaW5nIHRoZSBSUEwgZnJhbWUgdXBzdHJlYW0g Y2FuIGFsc28gYWRkIGl0LiBUaGF0DQo+IHdvdWxkIChJIHRoaW5rIGZvciB0aGUgZmlyc3QgdGlt ZSkgYWxsb3cgYSBtYWxpY2lvdXMgbm9kZSB0byBleHBsaWNpdGx5IGNhdXNlDQo+IGFub3RoZXIg b2ZmLXBhdGggcm91dGUgdG8gYmUgZGVzdHJveWVkIOKAlCBwb3RlbnRpYWxseSBsZWF2aW5nIGEg dGFyZ2V0IHdpdGgNCj4gbm8gcm91dGVzIHRvIGl0IGF0IGFsbC4gVGhpcyBhdHRhY2sgc2hvdWxk IGJlIGRlc2NyaWJlZCBpbiB0aGUgc2VjdXJpdHkNCj4gY29uc2lkZXJhdGlvbnMgYXMgYSByaXNr Lg0KDQpbUkpdIFllcyB0aGlzIHJpc2sgd2lsbCBiZSBhZGRlZCBpbiB0aGUgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMuIFRoYW5rIHlvdSBmb3Igbm90aWNpbmcgdGhpcyBwb2ludC4NCg0KPiBJdOKA mXMgYXQgYSB2ZXJ5IGxlYXN0IGEgcHJvYmxlbSB3aGVuIGFsbCBvZiB0aGUgbm9kZXMgc2hhcmUg YSBNQUMga2V5LCBhbmQgaWYNCj4gSeKAmW0gY29ycmVjdCB0aGF0IG9ubHkgbmVpZ2hib3IgTUFD cyBvciBzaWduYXR1cmVzIGFyZSB2ZXJpZmllZCBpbiBSUEwgdGhlbiBpdOKAmXMNCj4gYSBwcm9i bGVtIGV2ZW4gaWYgdGhlIHNlY3VyZSB2ZXJzaW9uIG9mIG1lc3NhZ2VzIGlzIGRlcGxveWVkIGJl Y2F1c2UgYQ0KPiDigJxwZWVyIG9mIGEgcGVlcuKAnSBvciBlYXJsaWVyIG5vZGUgY291bGQgaGF2 ZSBhZGRlZCB0aGUg4oCcSeKAnSBiaXQuDQo+IA0KPiBBbm90aGVyIGFzcGVjdCBvZiB0aGlzIG5l dyBuZXR3b3JrIGZsb3cgaXMgdGhhdCBwcmV2aW91c2x5IGEgbm9kZSBjb3VsZCBoYXZlDQo+IHBy b3RlY3RlZCBpdHNlbGYgZnJvbSBhdHRhY2tzIGRlbGV0aW5nIHJvdXRlcyBieSBvbmx5IGFjY2Vw dGluZyBhIGNoYW5nZSBvZg0KPiByb3V0ZSBmcm9tIGFuIGFkamFjZW5jeSByZXByZXNlbnRpbmcg dGhlIHJvdXRlZCBwYXRoLiBTcG9vZmVkIOKAnGRlbGV0ZSBwYXRo4oCdDQo+IG1lc3NhZ2VzIGNv dWxkIGJlIGlnbm9yZWQgZnJvbSBvdGhlciBhZGphY2VuY2llcy4gVGhhdCBzZWVtcyBubyBsb25n ZXINCj4gcG9zc2libGUgd2l0aCB0aGUgRENPLCBzaW5jZSBieSBkZWZpbml0aW9uIGl0IGNvbWVz IGRvd25zdHJlYW0gcmF0aGVyIHRoYW4NCj4gdXBzdHJlYW0gZGlyZWN0aW9uIGZyb20gdGhlIG5v ZGUgKHBvc3NpYmx5KSBjaGFuZ2luZyBpdHMgcm91dGVzLiBJZiB0aGVyZeKAmXMNCj4gYW55IG9w ZXJhdGlvbmFsIG1pdGlnYXRpb24gcG9zc2libGUgYnkgd2hpY2ggYSBub2RlIGNvdWxkIHByb3Rl Y3QgaXRzZWxmDQo+IGFnYWluc3Qgc3Bvb2ZlZCDigJxkZWxldGUgcGF0aOKAnSBtZXNzYWdlcyB0 aGVuIHRoaXMgc2hvdWxkIGJlIGFkZGVkIHRvDQo+IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLg0K DQpbUkpdIEV2ZW4gd2l0aCBEQ08gdHJhdmVyc2luZyBkb3duc3RyZWFtLCB0aGUgYWRqYWNlbmNp ZXMgaGF2ZSB0byBiZSB2ZXJpZmllZCBpLmUuLCB0aGUgbm9kZXMgaW4gdGhlIHBhdGggc2VuZGlu ZyB0aGUgRENPIG5lZWRzIHRvIGhhdmUgdGhlIHJvdXRpbmcgZW50cnkgZm9yIHRoZSB0YXJnZXQg bm9kZSBhbG9uZyB3aXRoIHRoZSByaWdodCBzdGF0ZSBpbmZvcm1hdGlvbiAoaW4gdGhlIGZvcm0g b2YgUGF0aCBTZXF1ZW5jZSkuDQoNCg== From nobody Fri May 24 22:45: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 B02A6120123; Fri, 24 May 2019 22:45: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, 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 aM0oJmRTdDTG; Fri, 24 May 2019 22:45:27 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450: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 3E3F612004C; Fri, 24 May 2019 22:45:24 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id j24so10426987ljg.1; Fri, 24 May 2019 22:45:24 -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=UVTC3SDDSDAlGJvwoIFtnShwmSL2pX6Bi/JoeUmKzGY=; b=n/mrNQYEt/jHce3/xwq+MP/Fqhn1LVJ45+PS99kUvx2M8zCJN0wc2PP/qCq7VzEe4z mTYBmgOgeAkduEIJDVA7Gkj34yxhLzdrBh4jJzfs1IrgcGpJtodhDNynuaKbSmUT4aNY OWRuc978JKzEiiFbeO9eGg2vPZFQxaOd01+aC2TL8iNW2OOBQssucsf8kWA2EM3OioA+ hKwx7KUbHQjOWciWo+f8uOWM+kumsVa87PPrgeKAwAC2AM0WdyaCQ7h0AQ0p16QpteZr jKgZ71DRNluFVJipnz5t5DXY5ihz/UlxcMVpXHAN3qQ5YeANTiERGR+1Kb7Kh9KlYGoO euQQ== 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=UVTC3SDDSDAlGJvwoIFtnShwmSL2pX6Bi/JoeUmKzGY=; b=OkX3sZwH4p3AhVvKwIgSBknuovCWj/0rQrunfnaezn9+RSMC4MCryHInD4Q0NuRSLF M2JGjxT6nDcNfnr/dT4MD/uuETYGyJmchu/gkHImqW3yK4RxaqrB8/Qhzj+d1FJydlQI aWcWXp6fVAUZWSVnL+7hpdIUqe3h8LxAEpAywAX7E0u+65jZAgooetbNBlfZBuACIqzt RUxsBQWRGUzCHpmA5DGa0OYAaYmTrcI6c51B8ymzPIJK287WsgowiodDgwGq9rRdAg3e /GGz6pbjbz/QlV2sNQEiz31qsNoHUHK0XxD5wlPPIFEC5Fc6c48c85s/jxTtffAajZjA MYqA== X-Gm-Message-State: APjAAAW55JqIJfmipAu3KD7z46raG7Zd0Rx+0mc75MEzeVgIegIloHNk qNiH4CESyxn9vGoSJsIF63XkJBowhp05QJ9Uvl8ucpn/vhE= X-Google-Smtp-Source: APXvYqzlA3fKldC57A8oN5egu0dR0F8I4EaDF7BSsfpmoZNopJSyKFKCULTMrjFLNbbHn9DSGx78CvkKXbW5V5c3Ta8= X-Received: by 2002:a2e:9496:: with SMTP id c22mr7947655ljh.71.1558763122079; Fri, 24 May 2019 22:45:22 -0700 (PDT) MIME-Version: 1.0 From: Shawn Emery Date: Fri, 24 May 2019 23:45:10 -0600 Message-ID: To: secdir@ietf.org, draft-ietf-bfd-vxlan.all@ietf.org Cc: Shawn Emery Content-Type: multipart/alternative; boundary="0000000000002e3e8c0589afd2df" Archived-At: Subject: [secdir] Review of draft-ietf-bfd-vxlan-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, 25 May 2019 05:45:30 -0000 --0000000000002e3e8c0589afd2df Content-Type: text/plain; charset="UTF-8" Reviewer: Shawn M. Emery Review result: Ready with 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. This draft specifies usage of the Bidirectional Forwarding Detection (BFD) protocol on Virtual eXtensible Local Area Network (VXLAN) tunnels. The security considerations section does exist and discusses the introduction of a possible DDoS attack due to the requirement of the protocol to set the IP TTL to one hop. The prescription outlined is to throttle this traffic. The section continues that BFD sessions should also have an upper limit, but does not give guidance on what is considered reasonable to where it would affect normal traffic vs. some form of DoS. I believe that this section should also document the security impact of deploying BFD on VXLANs for monitoring tunnel traffic. Which additional information, if any, can now be obtained with BFD usage? General comments: This standards track draft makes a normative reference to the base RFC, 7348, which is informational. Are there plans of making the base protocol a standards track specification? Downward references will need to be justified. Editorial comments: NVE is never expanded and not on the RFC Editors Abbreviation List. Echo BFD is out of scope for the document, but does not describe the reason for this or why state this at all? Shawn. -- --0000000000002e3e8c0589afd2df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reviewer: Shawn = M. Emery
Review result:=C2=A0Ready with issues

I have reviewed this document a= s part of the security directorate's
ongoing effort to review all=C2=A0IET= F=C2=A0documents 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 usage of the=C2=A0= Bidirectional Forwarding=C2=A0Detect= ion (BFD) protocol on
Vir= tual eXtensible Local Area Network (VXLAN)=C2=A0tunnels.

The se= curity considerations section does exist and discusses the introduction of = a possible
DDoS=C2=A0attack due to the requirement of the protocol to set the IP= TTL to one hop.=C2=A0 The prescription
outlined is to throttle this traffic.=C2=A0 The section continues = that BFD sessions should also have an
= upper limit, but does not give guidance on what is considered reasonable to= where it would affect
normal traffic = vs. some form of DoS.=C2=A0 I believe that this section should also documen= t the=C2=A0security
impact of=C2=A0deploying BFD on VXLANs for monitoring t= unnel traffic.=C2=A0 Which additional information,
if any,=C2=A0= can now be=C2=A0obtained with BFD usage?

General comments:

This standards track draft makes a normative reference to the base RFC, = 7348, which is informational.
Are there plans of making the bas= e protocol a standards track specification?=C2=A0 Downward references
wi= ll need to be justified.

Editorial comments:

NVE is never expan= ded and not on the RFC Editors Abbreviation List.
Echo BFD is out of s= cope for the document, but does not describe the reason for this or why sta= te
this at all?

Shawn.
--
--0000000000002e3e8c0589afd2df-- From nobody Sat May 25 14:31: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 4D15912003E; Sat, 25 May 2019 14:31:36 -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, 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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DVFZQjSy; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ekyCbaWV 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 yXIl8H7fGm0O; Sat, 25 May 2019 14:31:33 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85691200F3; Sat, 25 May 2019 14:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15198; q=dns/txt; s=iport; t=1558819893; x=1560029493; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BJQqUhRGHBgvxuXHeGmmunEIY/aCUVJXv26ni29qZWw=; b=DVFZQjSyO3Co+vnw8GNt5qrroyyxpS+5tyul110wIP0Rk4FHDL5KQQY1 S9rd8v469UwH4ozdjP3tkMGgUujUaEoRjnOk6LTAVhcT1H7DD4ca7RZKg Ez21HjfQSmGYzn1Czg9u72a5cTKbpKlq734MQDLo6EIxtutErBOQT09T3 M=; IronPort-PHdr: =?us-ascii?q?9a23=3A8K6DPxV9s12Xx8OY9pMA+bo3OE3V8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA92J8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank3AtVEX1xo13q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DmAQCAs+lc/5FdJa1lEwEBCAEBBQE?= =?us-ascii?q?HBQGBVAUBCwGBPSQFJwNpVSAECyiEE4NHA454mgKBQoEQA1QJAQEBDAEBGA8?= =?us-ascii?q?GAgEBhEACF4IoIzcGDgEDAQEEAQECAQRtHAyFSwIBAQIBARAREQwBASwLAQ8?= =?us-ascii?q?CAQgaAhEVAgICJQsVEAIEAQ0FGweDAAGBagMdAQIMm0oCgTiIEBo1cYEvgnk?= =?us-ascii?q?BAQWBMgGDRhiCDwmBDCgBiQmBK4EeF4FAP4ERJx+BTi4iLj6CYQEBAQKBGS8?= =?us-ascii?q?JJCiCSzKCJogzgwsggi6FA4F3kmhpCQKCDYY0hEiDaFGDYBuCH2eFf4lcg2i?= =?us-ascii?q?MbocCjnYCBAIEBQIOAQEFgWUigUMMCHAVOyoBgkEJggYMBRIUbgEOgjwzhCY?= =?us-ascii?q?7hT9yAQuBHYpuglABAQ?= X-IronPort-AV: E=Sophos;i="5.60,512,1549929600"; d="scan'208";a="278278112" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 May 2019 21:31:31 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x4PLVVTg012182 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 25 May 2019 21:31:31 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 25 May 2019 16:31:30 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 25 May 2019 16:31:29 -0500 Received: from NAM05-DM3-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; Sat, 25 May 2019 16:31:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BJQqUhRGHBgvxuXHeGmmunEIY/aCUVJXv26ni29qZWw=; b=ekyCbaWVzejoIBNYpB+JD9FJpghnlUddCvP/O7HsNdmni/4q1t/wlljWNzB2KU+9+NgKrIzfMzb8dadeMZvm53G2lmzkryZU642Ixv2811K+iJkyhWCZ8R94vrO6uLGZ6Yu0g9jcHbG+6qpASSCCSv8LS/eX3wQZDmXuATYJJts= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB3806.namprd11.prod.outlook.com (20.178.254.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.22; Sat, 25 May 2019 21:31:28 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::1990:d953:1387:d1a7]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::1990:d953:1387:d1a7%7]) with mapi id 15.20.1922.021; Sat, 25 May 2019 21:31:28 +0000 From: "Eric Vyncke (evyncke)" To: Phillip Hallam-Baker , "secdir@ietf.org" CC: "draft-ietf-intarea-provisioning-domains.all@ietf.org" , "int-area@ietf.org" , "ietf@ietf.org" Thread-Topic: [Int-area] Secdir last call review of draft-ietf-intarea-provisioning-domains-04 Thread-Index: AQHVEXxLxUEEXxckO0a1Rc8tTtbo4qZ8gPmA Date: Sat, 25 May 2019 21:31:27 +0000 Message-ID: <69466C63-63D5-4A2E-8AF4-F496EAAC841F@cisco.com> References: <155862531425.17228.10846494091656668654@ietfa.amsl.com> In-Reply-To: <155862531425.17228.10846494091656668654@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.19.0.190512 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:bd9b:765:bb4b:f69] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 91b283c0-da5e-4025-d37d-08d6e15858a6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB3806; x-ms-traffictypediagnostic: MN2PR11MB3806: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0048BCF4DA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(396003)(366004)(136003)(346002)(199004)(189003)(446003)(11346002)(561944003)(46003)(966005)(6436002)(6306002)(6486002)(486006)(186003)(36756003)(476003)(71190400001)(53936002)(256004)(14444005)(6512007)(81166006)(478600001)(2616005)(2501003)(14454004)(229853002)(86362001)(71200400001)(54906003)(110136005)(58126008)(8936002)(316002)(83716004)(81156014)(8676002)(7736002)(66946007)(66574012)(4326008)(25786009)(102836004)(76176011)(6246003)(305945005)(99286004)(30864003)(6506007)(5660300002)(6116002)(82746002)(76116006)(2906002)(73956011)(91956017)(66556008)(66446008)(33656002)(68736007)(64756008)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3806; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: 42Zld+0afA6Nk0RrySLjljpt+8QxV1gUhhS7F/CtjenKtd1jBZQF2rZYK3EeBxZUsKS/mgR30cImfAcUrcoHZGnf9eCbg/lov9OesKbyyGZ+KNWNjfFi4qjup1P+DViKqEC70fH8xs29x/rdkw1G/C/TCujJWAjbovXZXwaUCx34pggsNHaRiQokZR99mxMvnL18O9VYrdqo9aMDyvePZN30D3pK0u8gnj6y7+O2moKQseZ/8ri5H650E2Y+5AgA+fC+BYqiOECdkwJPfYvOPtZBKbSp1GvF4lySNbdAz1KyFAEfrVe9aGmWmcW03whX5ORd8bGDh2HtdOaFy9VlUmk/UnPo0a9LSiWG6J5ycL6GHPAjpU7oOr6N4l0u4Dg//YW0H05d7hGXeuTFu1KmTdDAzyV7cVedDFf4avF10OY= Content-Type: text/plain; charset="utf-8" Content-ID: <8A676D1200813741865CC9C864E6583C@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 91b283c0-da5e-4025-d37d-08d6e15858a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2019 21:31:27.8444 (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-CrossTenant-userprincipalname: evyncke@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3806 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [secdir] [Int-area] Secdir last call review of draft-ietf-intarea-provisioning-domains-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, 25 May 2019 21:31:37 -0000 UGhpbGlwLA0KDQpUaGFuayB5b3UgYWdhaW4gZm9yIHRoZSB0aW1lIHNwZW50IG9uIHJldmlld2lu ZyBvdXIgZHJhZnQuIEFmdGVyIHNvbWUgZGlzY3Vzc2lvbiB3aXRoIHRoZSBhdXRob3JzLCBwbGVh c2Ugc2VlIGJlbG93IG91ciBjb21tZW50cywgbG9vayBmb3IgRVY+Lg0KDQpBbHNvLCBleHBlY3Qg YSBuZXh0IHJldmlzaW9uIGluIHRoZSBjb21pbmcgZGF5cyB0YWtpbmcgaW4gdG8gYWNjb3VudCBh IGNvdXBsZSBvZiB5b3VyIGNvbW1lbnRzLg0KDQpSZWdhcmRzDQoNCi3DqXJpYyBmb3IgdGhlIGF1 dGhvcnMNCg0K77u/T24gMjMvMDUvMjAxOSwgMTc6MjksICJJbnQtYXJlYSBvbiBiZWhhbGYgb2Yg UGhpbGxpcCBIYWxsYW0tQmFrZXIgdmlhIERhdGF0cmFja2VyIiA8aW50LWFyZWEtYm91bmNlc0Bp ZXRmLm9yZyBvbiBiZWhhbGYgb2Ygbm9yZXBseUBpZXRmLm9yZz4gd3JvdGU6DQoNCiAgICBSZXZp ZXdlcjogUGhpbGxpcCBIYWxsYW0tQmFrZXINCiAgICBSZXZpZXcgcmVzdWx0OiBTZXJpb3VzIElz c3Vlcw0KICAgIA0KICAgIFRoaXMgZHJhZnQgZ2l2ZXMgc29tZSBsb25nIG92ZXJkdWUgYXR0ZW50 aW9uIHRvIGFuIGlzc3VlIHRoYXQgaGFzIGJlY29tZQ0KICAgIGluY3JlYXNpbmdseSBwcm9ibGVt YXRpYyBpbiByZWFsIHdvcmxkIGNvbnRleHRzLiBTaW5jZSB0aGlzIGlzIGFuIGVhcmx5IHJldmll dywNCiAgICBJIGFtIGZvY3VzaW5nIG9uIHRoZSB0eXBlcyBvZiBpc3N1ZXMgdGhhdCBuZWVkIHRv IGJlIGFkZHJlc3NlZCBkdXJpbmcNCiAgICBkZXZlbG9wbWVudC4NCiAgICANCiAgICBPbmUgaXNz dWUgdGhhdCBoYWQgbWUgc29tZXdoYXQgY29uZnVzZWQgYXQgZmlyc3QgaXMgdGhlIGluaXRpYWwg c2VudGVuY2UuICJBbg0KICAgIGluY3JlYXNpbmcgbnVtYmVyIG9mIGhvc3RzIGFjY2VzcyB0aGUg SW50ZXJuZXQgdmlhIG11bHRpcGxlIGludGVyZmFjZXMiLg0KICAgIFJlYWRpbmcgdGhlIGRyYWZ0 LCB0aGVyZSBhcHBlYXJzIHRvIGJlIGFuIGltcGxpY2l0IGFzc3VtcHRpb24gdGhhdCB0aGUgYWNj ZXNzDQogICAgaXMgc2VxdWVudGlhbCAobW9iaWxlIGRldmljZSBnb2luZyBmcm9tIG9uZSBjb2Zm ZWUgc2hvcCB0byBhbm90aGVyKSBldmVuIHRob3VnaA0KICAgIHRoZSByZWZlcmVuY2VkIGRvY3Vt ZW50IGlzIHZlcnkgbXVjaCBmb2N1c2VkIG9uIHBhcmFsbGVsLg0KICAgIA0KICAgIEl0IHdvdWxk IGJlIGhlbHBmdWwgaWYgdGhlcmUgd2FzIHNvbWUgZ3JvdW5kaW5nIGNvbnRleHQgZWFybHkgb24g aW4gdGhlDQogICAgZG9jdW1lbnQgdG8gcHJvdmlkZSB0aGlzIGNvbnRleHQsIHNvbWV0aGluZyBs aWtlOg0KIA0KRVY+IHRoaXMgaXMgaW5kZWVkIGEgdXNlIGNhc2UgdGhhdCB3ZSBoYXZlIGluIG1p bmQsIGFsbCB0aGUgd29yayBpcyBiYXNlZCBvbiB0aGUgbXVsdGlwbGUgaW50ZXJmYWNlIGRlZnVu Y3QgTUlGIFdHLiBXZSBtYXkgd2FudCB0byBhZGQgbW9yZSBkZXNjcmlwdGl2ZSB0ZXh0IHRvIG91 ciBJLUQuIE5vdCB0byBtZW50aW9uIHRoYXQgdGhlcmUgYXJlIGNhc2Ugd2hlbiBhIHNpbmdsZSBX L0xBTiBoYXMgdXBzdHJlYW0gY29ubmVjdGl2aXR5IHZpYSBtdWx0aXBsZSBwcm92aWRlci4NCg0K RVY+IG91ciBuZXh0IHJldiB3aWxsIGluY2x1ZGUgIGEgdXNlIGNhc2Ugc2VjdGlvbi4NCiAgICAN CiAgICBJZiBBbGljZSBoYXMgYSBtb2JpbGUgcGhvbmUgcHJvdmlkZXIgYW5kIGEgYnJvYWRiYW5k IHByb3ZpZGVyIGluIGhlciBob21lLCBoZXINCiAgICBkZXZpY2VzIHNob3VsZCBiZSBjYXBhYmxl IG9mIHNlYW1sZXNzbHkgdHJhbnNpdGlvbmluZyBmcm9tIG9uZSB0byB0aGUgb3RoZXIuIFNvDQog ICAgdGhhdCBpZiB0aGUgYnJvYWRiYW5kIGZhaWxzLCB0aGUgSW50ZXJuZXQgc2VydmljZSBjYW4g Z3JhY2VmdWxseSBmYWlsb3ZlciB0bw0KICAgIHRoZSBtb2JpbGUgYW5kIHZpY2UgdmVyc2EgZm9y IHVwZ3JhZGVzLiBUaGlzIGRyYWZ0IGlzbid0IGdvaW5nIHRvIHNvbHZlIHRoYXQNCiAgICBwcm9i bGVtIGJ1dCBwcm92aWRpbmcgdGhlIGJhc2ljIGluZm9ybWF0aW9uIG5lY2Vzc2FyeSB0byBtYWtl IHRoaXMgY2hvaWNlDQogICAgaW50ZWxsaWdlbnRseSBpcyBnb2luZyB0byBiZSBjcnVjaWFsIHRv IGFueSBzb2x1dGlvbi4gVGhlcmUgYXJlIHNpbWlsYXINCiAgICBjb25jZXJucyBmb3IgSVBTRUMg VlBOLg0KDQpFVj4gSVBzZWMgVlBOcyBhcmUgYWxyZWFkeSBjb25zaWRlcmVkIEV4cGxpY2l0IFB2 RHMgaW4gUkZDNzU1Ni4gWW91IGFyZSBwZXJmZWN0bHkgY29ycmVjdCBhYm91dCBtdWx0aXBsZSBp bnRlcmZhY2VzIGluY2x1ZGluZyBwc2V1ZG8gVlBOIG9uZXMuIEFuZCwgaW5kZWVkIHRoZSBzY29w ZSBvZiB0aGlzIGRvY3VtZW50IGRvZXMgbm90IGluY2x1ZGUgcmUtcm91dGluZyB0cmFmZmljIGJh c2VkIG9uIHVwc3RyZWFtIGF2YWlsYWJpbGl0eSBidXQgd2hlbiBzZWxlY3RpbmcgYSBuZXcgdXBz dHJlYW0sIHRoZSBQdkQgYWxsb3dzIGZvciBhIGNvbnNpc3RlbnQgc2V0IG9mIGluZm9ybWF0aW9u IChyZWN1cnNpdmUgRE5TIHNlcnZlciwgSVB2NiBwcmVmaXgsIC4uLikgdG8gYmUgdXNlZC4NCiAg ICANCiAgICBUaGlzIHBhcnRpY3VsYXIgcHJvcG9zYWwgaXMgc2l0dWF0ZWQgYXQgYSB2ZXJ5IGxv dyBsZXZlbCBpbiB0aGUgc3RhY2sgYnV0IGlzDQogICAgbWFraW5nIHVzZSBvZiBhcHBsaWNhdGlv biBsZXZlbCBwcm90b2NvbHMgdG8gYWNoaWV2ZSBpdHMgZWZmZWN0LiBJIHRoaW5rIHRoaXMNCiAg ICBpcyBhIHBlcmZlY3RseSB2YWxpZCBhcHByb2FjaCBidXQgZG9lcyBtZWFuIHRoYXQgdGhlIGlz c3VlIG9mIHJlY3Vyc2l2ZQ0KICAgIGRlcGVuZGVuY2llcyBoYXZlIHRvIGJlIGNvbnNpZGVyZWQg YW5kIGluIHBhcnRpY3VsYXIgaW4gdGhlIHNlY3VyaXR5DQogICAgY29uc2lkZXJhdGlvbnMuDQog ICAgDQogICAgQXQgcHJlc2VudCwgdGhlIGRyYWZ0IGlzIHN0cnVjdHVyZWQgdG8gZGVzY3JpYmUg YW4gSVAgcGFja2V0IGZvcm1hdCBhbmQgdGhlbg0KICAgIHRoZSBkYXRhIHRoYXQgY2FuIGJlIGFj Y2Vzc2VkLiBJIHN1Z2dlc3QgcmV2ZXJzaW5nIHRoZXNlIGFuZCBwcmVzZW50aW5nIHRoZSBQdkQN CiAgICBzY2hlbWEgZmlyc3QgYW5kIHRoZW4gdGhlIElQIHBhY2tldCBhcyBvbmUgY2hvaWNlIG9m IGJpbmRpbmcsIHdlIGFyZSBsaWtlbHkgdG8NCiAgICB3YW50IHRvIGFkZCBtb3JlLiBJZiBJIGFt IHByb3Zpc2lvbmluZyBhbiBJUFNFQyBWUE4gY29uZmlndXJhdGlvbiB0byBhIGNsaWVudCwNCiAg ICBpdCB3b3VsZCBiZSBsb2dpY2FsIHRvIGVpdGhlciBpbmNsdWRlIHRoZSBQdkQgaW4gdGhlIElQ U0VDIGNvbm5lY3Rpb24NCiAgICBkZXNjcmlwdGlvbiBvciB2aWNlIHZlcnNhLiBUaGlzIGlzIHBh cnRpY3VsYXJseSB0aGUgY2FzZSBpZiB3ZSBlbmQgdXAgc2lnbmluZw0KICAgIHRoZSBkYXRhIChz ZWUgbGF0ZXIpLiANCg0KRVY+IFdlIGRvIG5vdCBtaW5kIGVpdGhlciB3YXksIG91ciBmbG93IHdh cyBtb3JlIGZvY3VzZWQgb24gdGhlIGNocm9ub2xvZ3kgb2Ygb3BlcmF0aW9ucyAoYm90dG9tLXVw KS4gT3VyIG9yaWdpbmFsIGludGVudCBpcyB0aGF0IHdlIGVtcGhhc2l6ZSB0aGF0IHRoZSBrZXkg cG9pbnQgb2YgdGhlIGRyYWZ0IGlzIGZsZXNoaW5nIG91dCB0aGUgcmVxdWlyZW1lbnRzIGZvciBl eHBsaWNpdCBQdkQgZGlzY292ZXJ5IHZpYSBsb2NhbCByb3V0ZXIgbWVjaGFuaXNtcywgYXMgcHJl ZGljdGVkIGJ5IFJGQyA3NTU2LCBpdCBiZWNvbWVzIG1vcmUgY2xlYXIuIEV4Y2VwdCBpZiBvdGhl ciByZXZpZXdlcnMgd2FudCB0byBjaGFuZ2UgdGhlIG9yZGVyLCB0aGVuIHdlIHByZWZlciB0byBr ZWVwIGl0IHRoZSB3YXkgaXQgaXMuIElmIG1ham9yaXR5IG9mIHJldmlld2VycyB3YW50IHRoZSBv cmRlciByZXZlcnNlLCB0aGVuIGZvciBjbGFyaXR5IHdlIHdpbGwgY2hhbmdlIHRoZSB0ZXh0IG9y ZGVyLiANCiAgICANCiAgICBUdXJuaW5nIHRvIHRoZSBzZWN1cml0eSBjb25jZXJucywgaXQgaXMg dXN1YWxseSBoZWxwZnVsIHRvIGNvbnNpZGVyIHRoZXNlIGluDQogICAgdGVybXMgb2YgQ29uZmlk ZW50aWFsaXR5LCBJbnRlZ3JpdHkgYW5kIEF2YWlsYWJpbGl0eSBhbmQgdGhlIG5ldHdvcmsgbGF5 ZXIgYXQNCiAgICB3aGljaCB0aGUgcHJvdG9jb2wgb3BlcmF0ZXMuDQogICAgDQogICAgSW4gdGhp cyBjYXNlLCB0aGUgcHJvcG9zYWwgYXBwZWFycyB0byBiZSBsaW5rIGxheWVyIHNpbmNlIGl0IGlz IHByb3ZpZGluZw0KICAgIGluZm9ybWF0aW9uIHRvIGEgaG9zdCBjb25uZWN0aW5nIHRvIGEgbmV0 d29yay4gQnV0IHRoZSBpbmZvcm1hdGlvbiBwcm92aWRlZA0KICAgIGluY2x1ZGVzIChwb3RlbnRp YWxseSkgRE5TIHNlcnZpY2VzIGFuZCBzbyBpdCBpcyBnb2luZyB0byBhZmZlY3QgdGhlIHdob2xl DQogICAgc3RhY2sgZnJvbSB0aGUgbGluayB1cCB0byB0aGUgYXBwbGljYXRpb24gbGF5ZXIuDQoN CkVWPiBwcmV0dHkgbXVjaCBsaWtlIHRoZSBSRE5TUyBvcHRpb24gaW4gdGhlIElQdjYgUkEgYXMg c3BlY2lmaWVkIGJ5IFJGQyA4MTA2DQogICAgDQogICAgU2luY2UgdGhpcyBpcyBsaW5rIGxheWVy LCB0aGVyZSBpcyBhIGNlcnRhaW4gZGVncmVlIG9mIGltcGxpY2l0IGludGVncml0eQ0KICAgIGFj aGlldmVkIGJlY2F1c2UgdGhlIGhvc3QgaGFzIGVpdGhlciBhIGRpcmVjdCBwaHlzaWNhbCBjb25u ZWN0aW9uIG9yIGF0IGxlYXN0DQogICAgcHJveGltaXR5IHRvIHRoZSBuZXR3b3JrLiBJdCBpcyBw cm9iYWJseSBwcnVkZW50IHRvIGRpc3Rpbmd1aXNoIHRoZSBjYXNlcyBvZg0KICAgIGhvc3RzIGNv bm5lY3Rpbmcgd2lyZWxlc3NseSBhbmQgcGh5c2ljYWxseSBzaW5jZSBhIHBoeXNpY2FsIGNvbm5l Y3Rpb24gcHJvdmlkZXMNCiAgICBhIGhpZ2hlciBkZWdyZWUgb2YgaW1wbGljaXQgaW50ZWdyaXR5 IHRoYW4gd2lyZWxlc3MuDQoNCkVWPiB0aGVyZSBpcyBpbmRlZWQgc29tZSBpbnRlZ3JpdHkgYW5k IHRydXN0IHdpdGhpbiB0aGUgYWNjZXNzIChlc3Agd2hlbiB1c2luZyBXaUZJICYgV1BBMikgYnV0 IHRoZSBkcmFmdCBkb2VzIG5vdCByZWx5IHRvbyBtdWNoIG9uIHRoaXMgbGV2ZWwgb2YgaW50ZWdy aXR5IHdoZW4gY2hlY2tpbmcgZm9yIHRoZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uICh0aGUgSlNP TiBmaWxlKQ0KICAgIA0KICAgIFRha2luZyB0aGUgbW9zdCBpbXBvcnRhbnQgY29uc2lkZXJhdGlv biBmaXJzdCwgd2hhdCBpcyB0aGUgcG90ZW50aWFsIGZvcg0KICAgIChhYil1c2luZyB0aGlzIGFw cHJvYWNoIHRvIHBlcmZvcm0gYSBzZXJ2aWNlIGF0dGFjaz8gSGVyZSB3ZSBzaG91bGQgY29uc2lk ZXINCiAgICB0aGUgcG9zc2liaWxpdHkgb2YgYW4gYXR0YWNrIG9uIHRoZSBob3N0IGl0c2VsZiBh bmQgdGhlIHVzZSBvZiB0aGUgbWVjaGFuaXNtIHRvDQogICAgcmVsYXkgYXR0YWNrcyBvbnRvIG90 aGVyIGhvc3RzLg0KICAgIA0KICAgIEkgaGF2ZSBub3QgdGhvdWdodCBvZiBhbnkgYXR0YWNrcyBv ZiB0aGlzIHR5cGUgeWV0IGJ1dCB0aGlzIGlzIHRoZSBhcmVhIHRoYXQNCiAgICBnaXZlcyBtZSB0 aGUgbW9zdCBjb25jZXJuLg0KICAgIA0KICAgIEludGVncml0eSBwcmVzZW50cyB0d28gY29uc2lk ZXJhdGlvbnMsIGZpcnN0IHRoZXJlIGlzIHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyDQogICAgdGhl IGRhdGEgaGFzIGJlZW4gbW9kaWZpZWQsIHRoZSBzZWNvbmQgaXMgd2hlcmUgaXQgY2FtZSBmcm9t IGluIHRoZSBmaXJzdA0KICAgIHBsYWNlLiBUaGUgdXNlIG9mIFRMUyBkb2VzIG5vdCBuZWNlc3Nh cmlseSBwcm92aWRlIGEgc3Ryb25nIGJpbmRpbmcgdG8gdGhlDQogICAgZG9tYWluLiBBdCB0aGUg dmVyeSBsZWFzdCwgZGF0YSB3b3VsZCBoYXZlIHRvIGJlIHJldHJpZXZlZCBmcm9tIGEgVVJMIGlu IHNvbWUNCiAgICBwb3J0aW9uIG9mIHRoZSBhZGRyZXNzIHNwYWNlIHRoYXQgaXMgcmVzZXJ2ZWQg Zm9yIGFkbWluaXN0cmF0aXZlIHVzZS4gV2hpbGUNCiAgICAuLndlbGwta25vd24gaXMgb2Z0ZW4g dXNlZCBmb3IgdGhpcyBwdXJwb3NlLCBpdCBpcyBub3QgYWx3YXlzIHZhbGlkLiBBbm90aGVyDQog ICAgaXNzdWUgd2l0aCBUTFMgaXMgdGhhdCB3ZSBzdGFydCBvZmYgd2l0aCBhIGZhaXJseSBzdHJv bmcgaW1wbGljaXQgaW50ZWdyaXR5DQogICAgZnJvbSB0aGUgbGluayBhbmQgZGlzY2FyZCB0aGF0 IGZvciBhIHJlcHVkaWFibGUgYXV0aGVudGljYXRpb24gdmlhIFRMUy4gSSB3b3VsZA0KICAgIHBy ZWZlciB0byBrZWVwIGJvdGggaWYgd2UgY2FuLg0KDQpFVj4gVGhlIGV4dGVuZGVkIGluZm9ybWF0 aW9uIGRvZXMgbm90IHJlcGxhY2UgYW55IGxvY2FsbHkgcHJvdmlzaW9uZWQgaW5mb3JtYXRpb24s IGFuZCBkb2VzIG5vdCBzdXBlcnNlZGUgaXQuDQoNCkVWPiBCZXNpZGUgdGhlIC53ZWxsLWtub3du IHBhdGggd2hpY2ggaXMgd2VsbC1rbm93biBhbmQgZG9lcyBub3QgcHJlc2VudCBhbnkgc2VjdXJp dHkgaXNzdWUsIEkgYW0gdW5zdXJlIHdoZXRoZXIgSSBhbSBmb2xsb3dpbmcgeW91Lg0KDQpFVj4g V2hlbiByZWNlaXZpbmcgYSBSQSBjb250YWluaW5nIHRoZSB0aGUgUHZEIElEIGV4YW1wbGUubmV0 LCB0aGVuIFRMUyBpcyB1c2VkIHRvIGZldGNoIGh0dHBzOi8vZXhhbXBsZS5uZXQvLndlbGwta25v d24vcHZkLmpzb24gYW5kIE5PVCBhbnkgb3RoZXIgVVJMLiBTbywgYXQgbGVhc3QgdGhlIGNsaWVu dCBub2RlIGNhbiBjaGVjayB0aGF0IHRoZSBzZXJ2ZXIgaXMgdGhlIGNvcnJlY3Qgb25lIChhbmQg dHJhbnNpdGl2ZWx5IHRoYXQgdGhlIEpTT04gZmlsZSBpcyBjb3JyZWN0KS4gT2YgY291cnNlLCBp ZiBoYWNrZXIubmV0IGlzIHNlbmRpbmcgUHZEIHByZXRlbmRpbmcgdG8gYmUgZXhhbXBsZS5uZXQg UHZEIHdoaWxlIG9uIGhhY2tlci5uZXQsIHRoZSBUTFMgc2Vzc2lvbiB3aWxsIHdvcmsgdG8gZXhh bXBsZS5uZXQgYW5kIHRoZSBKU09OIHdpbGwgYmUgZG93bmxvYWRlZCBidXQgd2lsbCBOT1QgYmUg dXNlZCBieSB0aGUgUHZEIGNsaWVudCBiZWNhdXNlIHRoZSBKU09OIGluY2x1ZGVzIGEgc2V0IG9m IGNvdmVyaW5nIElQdjYgcHJlZml4IHVuZGVyIHRoZSBrZXkgJ3ByZWZpeGVzJyBhbmQgb2J2aW91 c2x5IHRoZSBwcmVmaXggdXNlZCBieSBoYWNrZXQubmV0IHdpbGwgbm90IGJlIGNvdmVyZWQuIEV2 ZW4gaWYgaGFja2V0Lm5ldCB1c2VzIE5QVHY2IG9yIE5BVDY2IChzaGUvaGUgaXMgZXZpbCBhZnRl ciBhbGwhKSwgdGhlbiBpdCBpcyB1cCB0byB0aGUgZXhhbXBsZS5uZXQgd2ViIHNlcnZlciB0byBy ZWZ1c2UgY29ubmVjdGlvbnMgZnJvbSBhbiB1bmF1dGhvcml6ZWQgcHJlZml4IG91dHNpZGUgb2Yg ZXhhbXBsZS5uZXQgcHJlZml4ZXMuDQoNCkVWPiBRdWl0ZSBhIGxvbmcgZXhwbGFuYXRpb24sIGJ1 dCwgcGxlYXNlIGhhdmUgYSBsb29rIHRvIGh0dHBzOi8vZG93bmxvYWQuZXJudy1pbnNpZ2h0LmRl L3Ryb29wZXJzL3RyMTgvc2xpZGVzL1RSMThfTkdJX0lQdjZfU2VjdXJpdHktYW5kLVByaXZhY3kt TXVsdGktUHJlZml4LnBkZiAoYXQgdGhlIGVuZCBpbiB0aGUgJ1JvZ3VlIFB2RCcgc2VjdGlvbikg Zm9yIGEgYmV0dGVyIGV4cGxhbmF0aW9uLg0KDQpFVj4gaW4gYWxsIGNhc2UsIHdlIG5ldmVyIHN0 YXRlIHRoYXQgdGhpcyBhcHByb2FjaCBpcyAnc2VjdXJlJyBvciBtb3JlIHNlY3VyZSB0aGFuIHBs YWluICdSQScgKHdpdGggUkEgZ3VhcmQgb2YgY291cnNlKS4gSXQgaXMgbWVyZWx5IHNsaWdodGx5 IGltcHJvdmluZyB0aGUgc2VjdXJpdHkgYnV0IG1vcmUgaW1wb3J0YW50IHByb3ZpZGVkIGluZm9y bWF0aW9uIHRvIHRoZSBhcHBsaWNhdGlvbjsgaXQgaXMgdGhlIHNvbGUgb2JqZWN0aXZlLg0KICAg IA0KICAgIFJhdGhlciB0aGFuIHJlbHlpbmcgb24gVExTLCBhIHNob3J0ZXIgZGlzdGFuY2UgYmV0 d2VlbiB0aGUgdHdvIHBvaW50cyB3b3VsZCBiZQ0KICAgIHRvIHNpZ24gdGhlIFB2RCBzcGVjaWZp Y2F0aW9uIHdpdGggSk9TRS4gVGhpcyBuZWVkIG5vdCBiZSB0b28gb25lcm91cy4gQSBjbGllbnQN CiAgICB0aGF0IHdhbnRzIHRvIHJlbHkgb24ganVzdCB0aGUgVExTIGludGVncml0eSBjYW4gc2lt cGx5IEJhc2U2NCBkZWNvZGUgYW5kIHRydXN0DQogICAgdGhlIGRhdGEgYXMgYmVpbmcgaW1wbGlj aXRseSBhdXRoZW50aWMgYmVjYXVzZSBvZiB0aGUgIG1lYW5zIG9mIHJldHJpZXZhbC4NCiAgICAN CiAgICBUaGUgYmlnZ2VyIHBheW9mZiBmcm9tIHNpZ25pbmcgdGhlIFB2RCBpcyB0aGF0IHdlIG5v IGxvbmdlciBuZWVkIHRvIHdvcnJ5IGFib3V0DQogICAgaG93IGl0IGlzIHJldHJpZXZlZC4gVGhl IGtpbGxlciBhcHAgZm9yIEROU1NFQyBpcyB0dXJuaW5nIG91dCB0byBiZSB0aGUgYWJpbGl0eQ0K ICAgIHRvIGRpdm9yY2UgRE5TIGRhdGEgZnJvbSBETlMgdHJhbnNwb3J0LiBUaGVyZSBhcmUgY2Vy dGFpbiBzaXR1YXRpb25zIGluIHdoaWNoDQogICAgdGhlIGZhY3QgdGhhdCB0aGUgUHZEIGlzIGRl bGl2ZXJlZCBvdmVyIGEgcGFydGljdWxhciBsaW5rIGlzIHNpZ25pZmljYW50IGJ1dA0KICAgIHRo ZXJlIGFyZSBvdGhlciBzaXR1YXRpb25zIGluIHdoaWNoIGl0IG1pZ2h0IG5vdC4NCg0KRVY+IFdl IHRob3VnaCBhYm91dCBKT1NFIGFuZCBzaWduYXR1cmUgYXMgd2VsbCBidXQgdGhlbiB3ZSBjYW5u b3QgJ2RlZmVhdCcgZWFzaWx5IHRoZSBhdHRhY2sgb2YgaGFja2VyLm5ldCBhbm5vdW5jZWQgZXhh bXBsZS5uZXQgcHJlZml4ZXMsIGRvaW5nIE5BVDY2LCB3aXRoIGEgY2FjaGVkIEpTT04uDQoNCkVW PiBKT1NFIHdhcyBhdHRyYWN0aXZlIGFzIHdlbGwgYmVjYXVzZSBQdkQgYWRkaXRpb25hbCBpbmZv cm1hdGlvbiBjb3VsZCBiZSBjYWNoZWQgd2l0aG91dCBzaGFyaW5nIHRoZSB3ZWIgc2VydmVyIGtl eXM7IGJ1dCwgaW4gYXV0aG9ycycgb3BpbmlvbiBpcyB0aGF0IHRoZXJlIGFyZSBtYW55IG1vcmUg VExTIGltcGxlbWVudGF0aW9uIHRoYW4gSk9TRS4gTW9yZW92ZXIsIHdpdGggVExTIHRoZXJlIGlz IGEgZGlzdHJpYnV0aW9uICYgY2FjaGluZyBpbmZyYXN0cnVjdHVyZSAnZm9yIGZyZWUnIHdoaWxl IHdpdGggSk9TRSB0aGVyZSBpcyBhIG5lZWQgdG8gYnVpbGQgdGhpcyBpbmZyYXN0cnVjdHVyZSB0 byBkaXN0cmlidXRlIHRoZSBKT1NFIGJsb2JzLg0KICAgIA0KICAgIEZvciBleGFtcGxlLCBJIGhh dmUgMTIgc21va2UgYWxhcm1zIGluIG15IGNlaWxpbmdzLCBvbmUgb2Ygd2hpY2ggSSBjYW4gb25s eQ0KICAgIChzYWZlbHkpIHJlYWNoIGJ5IGVyZWN0aW5nIHNjYWZmb2xkaW5nLiBUaGVzZSBzbW9r ZSBhbGFybXMgYXJlIGFsbCBjb25uZWN0ZWQgdG8NCiAgICBhIFdpRmkgcm91dGVyIHRoYXQgZmFp bGVkIGFuZCB0aGUgb25seSBvcHRpb24gdGhlIG1hbnVmYWN0dXJlciAod2hpY2ggSSB3b24ndA0K ICAgIG5hbWUgYnV0IHJoeW1lcyB3aXRoIHNwcm9vZ2xlKSBnaXZlcyBmb3IgdXBkYXRpbmcgdGhl IFNTSUQgaXMgdG8gcmVjb25maWd1cmUNCiAgICBlYWNoIG9uZSBpbiB0dXJuLiBJdCB3b3VsZCBi ZSByZWFsbHkgbmljZSBpZiBJIGNvdWxkIHByb2dyYW0gbXVsdGlwbGUgU1NJRHMNCiAgICBpbnRv IHRoZSBkZXZpY2VzIHRvIHByb3ZpZGUgZmFpbG92ZXIuIENvbnRyYXdpc2UsIHRoaXMgY2FwYWJp bGl0eSBjb3VsZCBiZQ0KICAgIGV4dGVuZGVkIHRvIGZhY2lsaXRhdGUgdGhlIGluaXRpYWwgY29u bmVjdGlvbiBvZiB0aGUgZGV2aWNlcyB0byBteSBuZXR3b3JrLg0KICAgIFdoaWxlIHRoaXMgaXMg bm90IGEgZmVhdHVyZSB0aGUgV0cgaXMgbGlrZWx5IGludGVyZXN0ZWQgaW4gcmlnaHQgbm93LCBp dCBpcyBvbmUNCiAgICB0aGF0IEkgYW0gd29ya2luZyBvbiBmb3IgdGhlIE1hdGhlbWF0aWNhbCBN ZXNoIGFuZCBpdCBpcyBvYnZpb3VzbHkgYSBnb29kIGlkZWENCiAgICBpZiB3ZSBoYXZlIGFzIG11 Y2ggY29tbW9uYWxpdHkgYmV0d2VlbiB0aGUgdG9wIGRvd24gYW5kIGJvdHRvbSB1cCBjb25maWdz Lg0KICAgIA0KICAgIENvbmZpZGVudGlhbGl0eSBpcyBub3QgZ2VuZXJhbGx5IGEgZGlyZWN0IGNv bmNlcm4gYXQgdGhlIGxpbmsgbGF5ZXIgYnV0DQogICAgY29ycnVwdGlvbiBvZiB0aGUgZGF0YSAo aS5lLiBhbiBpbnRlZ3JpdHkgYXR0YWNrKSBtaWdodCBhbGxvdyBhIGRpc2Nsb3N1cmUNCiAgICBi cmVhY2guIEJ1dCB0aGlzIHNob3VsZCBiZSBzdGF0ZWQgZXhwbGljaXRseS4NCiANCkVWPiBJIGFn cmVlIGludGVncml0eSBhbmQgYXZhaWxhYmlsaXR5IGFyZSBtb3JlIGltcG9ydGFudCBpbiB0aGlz IGNvbnRleHQuIENvbmZpZGVudGlhbGl0eSBpcyBtb3N0bHkgaW1wb3NzaWJsZSB0byBhY2hpZXZl IGluIG91ciBwcm9wb3NhbCBhcyBhbnkgaG9zdCBpbiB0aGUgZXhhbXBsZS5uZXQgbmV0d29yayB3 aXRoIHRoZSByaWdodCBwcmVmaXggY2FuIGFjY2VzcyB0aGUgVExTIHNlcnZlciBhbmQgaXRzIGlu Zm9ybWF0aW9uLg0KICAgDQogICAgRmluYWxseSwgYXMgYSBnZW4tYXJ0IGlzc3VlLCB0aGUgdXNl IG9mIHgtb3B0aW9ucyBpcyBnZW5lcmFsbHkgZGVwcmVjYXRlZCBhcyBpdA0KICAgIGF0IGJlc3Qg ZW5kcyB1cCB3aXRoIGEgc2l0dWF0aW9uIHdoZXJlIGV2ZXJ5IGNsaWVudCBoYXMgdG8gYWNjZXB0 IGhlYWRlcnMgaW4NCiAgICBib3RoIHRoZSBwcmVmaXhlZCBhbmQgdW5wcmVmaXhlZCBmb3JtLiBB biBJQU5BIHJlZ2lzdHJ5IHdpdGggZmlyc3QtY29tZSwNCiAgICBmaXJzdC1zZXJ2ZWQgcmVnaXN0 cmF0aW9uIGZ1bGZpbGxzIHRoZSBnb2FsIG9mIHByZXZlbnRpbmcgYWNjaWRlbnRhbCBjb2xsaXNp b25zDQogICAgbW9yZSBlZmZlY3RpdmVseS4NCiANCkVWPiBpbmRlZWQsIHdlIGdvdCB0aGUgc2Ft ZSBjb21tZW50IGZyb20gRXJpayBLbGluZSBhbmQgdGhlIG5leHQgcmV2IHdpbGwgcmVwbGFjZSB0 aGUgSFRUUCBoZWFkZXIgWC0qIGJ1dCBhIG1vcmUgc3RhbmRhcmQgbWVjaGFuaXNtLg0KICAgDQpU aGFuayB5b3UgYWdhaW4gZm9yIHRoZSBleHRlbnNpdmUgcmV2aWV3DQoNCi3DqXJpYyAgICAgDQog ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBJ bnQtYXJlYSBtYWlsaW5nIGxpc3QNCiAgICBJbnQtYXJlYUBpZXRmLm9yZw0KICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW50LWFyZWENCiAgICANCg0K From nobody Mon May 27 02:02: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 D629912004B; Mon, 27 May 2019 02:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVtWDaCSrd86; Mon, 27 May 2019 02:02:19 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 F1A9D12003E; Mon, 27 May 2019 02:02:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,518,1549926000"; d="scan'208,217";a="307294113" Received: from moucherotte.inrialpes.fr ([194.199.28.14]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 May 2019 11:02:08 +0200 From: Vincent Roca Message-Id: <3B5B0C9F-849C-4EBA-86F0-24172278BEF8@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_E8E2E11C-FE99-43B1-8413-6E7BE460830E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 27 May 2019 11:02:07 +0200 In-Reply-To: Cc: Vincent Roca , secdir@ietf.org, draft-ietf-tsvwg-tinymt32.all@ietf.org, iesg@ietf.org To: Carl Wallace References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-tinymt32 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, 27 May 2019 09:02:22 -0000 --Apple-Mail=_E8E2E11C-FE99-43B1-8413-6E7BE460830E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Carl, all, Thanks a lot for your secdir review. > Le 17 mai 2019 =C3=A0 20:38, Carl Wallace = a =C3=A9crit : >=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 document describes the TinyMT32 Pseudo Random Number Generator = (PRNG) > that produces 32-bit pseudo-random unsigned integers and aims at = having a > simple-to-use and deterministic solution. The document is well written = and > the sample code produces the sample output. I am not a mathematician = so no > comments on the mechanism. I have a few minor nits/comments. > The security > considerations may benefit from repeating the last sentence of the = fourth > paragraph in the introduction (I.e., not 'meant to be used for > cryptographic applications=E2=80=99). [VR] Very good suggestion. Added. NEW: 4. Security Considerations The authors do not believe the present specification generates specific security risks per se. However, neither the TinyMT nor MT PRNG are meant to be used for cryptographic applications. > The bibliography should include all of the > references cited in the draft. [VR] We agree, and we changed all links to a well identified =C2=AB Informative References =C2=BB entry. NEW: [TinyMT-dev] Saito, M. and M. Matsumoto, "Tiny Mersenne Twister (TinyMT) github site", . [TinyMT-params] Rikitake, K., "TinyMT pre-calculated parameter list github site", . [TinyMT-web] Saito, M. and M. Matsumoto, "Tiny Mersenne Twister (TinyMT) web site", . > Adding some text or references to expand on > the mentioned limitations of RFC5170 or to describe how the parameter = set > from which the parameters selected in this draft would be nice as = well.=20 [VR] We agree. I=E2=80=99ve added a mention to the =C2=AB Numerical = Recipes in C =C2=BB 2nd=20 edition for the limits of the Park-Miller PRNG specified in RFC 5170, as = well as the companion RLC I-D where we mention the observations we made with this PRNG. NEW: [=E2=80=A6] TinyMT32 represents a major improvement with respect to = the Park-Miler Linear Congruential PRNG (e.g., as specified in [RFC5170]) that suffers several known limitations (see for instance [PTVF92], section 7.1, pp. 279, and [RLC-ID], Appendix B). Concerning the chosen parameter set, they have been selected among an official list of parameter set values, as explained. It=E2=80=99s a bit = arbitrary (we chose the 1st entry), as explained, but it=E2=80=99s a common parameter set = (there=E2=80=99s a=20 publication based on it listed in the Informative References section). There=E2=80=99s of course a theoretical background but I don=E2=80=99t = think it=E2=80=99s worth entering=20 that kind of details (especially as the two authors didn=E2=80=99t = publish a research paper on TinyMT32). Thanks a lot for your comments. Cheers, Vincent on behalf of the authors= --Apple-Mail=_E8E2E11C-FE99-43B1-8413-6E7BE460830E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= Carl, all,

Thanks a = lot for your secdir review.

Le 17 mai 2019 =C3=A0 20:38, Carl Wallace <carl@redhoundsoftware.com> a =C3=A9crit :

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 describes the TinyMT32 Pseudo Random Number Generator (PRNG)
that produces 32-bit pseudo-random unsigned integers and aims = at having a
simple-to-use and deterministic solution. The = document is well written and
the sample code produces the = sample output. I am not a mathematician so no
comments on = the mechanism. I have a few minor nits/comments. =



The security
considerations may = benefit from repeating the last sentence of the fourth
paragraph in the introduction (I.e., not 'meant to be used = for
cryptographic = applications=E2=80=99).

[VR] Very good suggestion. = Added.

NEW:
4.  Security = Considerations

   The authors do not believe the = present specification generates
  =  specific security risks per se.  However, = neither the TinyMT nor MT
  =  PRNG are meant to be used for cryptographic = applications.

The bibliography should include all of the
references cited in the draft. =

[VR] We agree, = and we changed all <eref target=3D=C2=AB https://=E2=80=A6 =C2= =BB />
links to a well identified =C2=AB Informative = References =C2=BB entry.

NEW:
  =  [TinyMT-dev]
            =   Saito, M. and M. Matsumoto, "Tiny Mersenne = Twister
              = (TinyMT) github site", <https://github.com/
        =       MersenneTwister-Lab/TinyMT>.

   [TinyMT-params]
  =             Rikitake, K., "TinyMT = pre-calculated parameter list github
      =         site", <https://github.com/jj1bdx/tinymtdc-longbatch/>.

   [TinyMT-web]
  =             Saito, M. and M. Matsumoto, = "Tiny Mersenne Twister
          =     (TinyMT) web site",

Adding some text or references to expand = on
the mentioned limitations of RFC5170 or to describe how = the parameter set
from which the parameters selected in = this draft would be nice as well.

[VR] We agree. I=E2=80=99ve added a mention to the = =C2=AB Numerical Recipes in C =C2=BB 2nd 
edition for the limits of the Park-Miller PRNG specified in = RFC 5170, as well
as the companion RLC I-D where we = mention the observations we made with
this = PRNG.

NEW:
   [=E2=80=A6= ] TinyMT32 represents a major improvement with respect to the
   Park-Miler Linear Congruential PRNG (e.g., as = specified in [RFC5170])
   that suffers = several known limitations (see for instance = [PTVF92],
   section = 7.1, pp. 279, and [RLC-ID], Appendix B).


Concerning the chosen parameter set, they have been selected = among an
official list of parameter set values, as = explained. It=E2=80=99s a bit arbitrary (we chose
the= 1st entry), as explained, but it=E2=80=99s a common parameter set = (there=E2=80=99s a 
publication based on it = listed in the Informative References section).
There=E2=80=99s of course a theoretical background but I = don=E2=80=99t think it=E2=80=99s worth entering 
that kind of details (especially as the two authors didn=E2=80=99= t publish a research
paper on TinyMT32).

Thanks a lot for your = comments.

Cheers,

  Vincent on behalf of the = authors
= --Apple-Mail=_E8E2E11C-FE99-43B1-8413-6E7BE460830E-- From nobody Mon May 27 05:59:56 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 52BF412015E; Mon, 27 May 2019 05:59:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Montville via Datatracker To: Cc: spasm@ietf.org, draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Montville Message-ID: <155896198526.742.8687531313314399857@ietfa.amsl.com> Date: Mon, 27 May 2019 05:59:45 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-lamps-hash-of-root-key-cert-extn-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: Mon, 27 May 2019 12:59:46 -0000 Reviewer: Adam Montville Review result: Ready >From a SECDIR perspective, this draft is ready (feel free to see the last review on the 03 draft [1]. Between 03 and 05 some minor changes were made and the operational considerations section has been expanded. [1] https://datatracker.ietf.org/doc/review-ietf-lamps-hash-of-root-key-cert-extn-03-secdir-lc-montville-2019-01-08/ From nobody Mon May 27 19:15:04 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 AC64A120096; Mon, 27 May 2019 19:15:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner via Datatracker To: Cc: sipbrandy@ietf.org, draft-ietf-sipbrandy-osrtp.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Sean Turner Message-ID: <155900970362.650.8194184838834826261@ietfa.amsl.com> Date: Mon, 27 May 2019 19:15:03 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-sipbrandy-osrtp-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: Tue, 28 May 2019 02:15:04 -0000 Reviewer: Sean Turner Review result: Has Issues I had a read of the draft as well as the GENART and TSVART reviews (to avoid duplicating comments). Summary: Ready with (minor) issues Issues: 0) I assume that the mismatch the TSVART refers to in the security considerations has to do with 1) changing 4568 to require encryption but not fail if authentication is not available, 2) pointing out that 4568's requirement is routinely ignore for end-to-end encryption because using TLS with intermediaries won't protect the SDP key, and 3) and reference errors (see the next issue). On 1, that's kind the point of OSRTP - take the encryption you can get. On 2, because it's the security considerations this document is just saying don't expect to get end-to-end. Assuming, I've interpreted this I think this draft is okay. 1) I think these are just reference errors, but it would be good to double check these (and I hadn't seen a response yet - might have missed it): S4: Not sure about these references too RFC7435. Maybe they should be to RFC 4568 instead? s/The security considerations of [RFC7435] apply to OSRTP, /The security considerations of [RFC4568] apply to OSRTP, s/Section 8.3 of [RFC7435]/Section 8.3 of [RFC4568] s/understood that the [RFC7435]/understood that the [RFC4568] Bikesheds: 0) The fact that it's Informational struck me as odd. 1) The fact there are no updates listed also strikes me as odd. Nits: 0) s2: Nits reports an error with the para. I think it's: s/RFC 2119 [RFC2119] RFC 8174 [RFC8174] /RFC 2119 [RFC2119] [RFC8174] 1) s1, 2nd para: s/[RFC5939] ./[RFC5939]. From nobody Tue May 28 03:24: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 602EE1201C9 for ; Tue, 28 May 2019 03:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvO-cXecrj_t for ; Tue, 28 May 2019 03:24:37 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 B9B281201C3 for ; Tue, 28 May 2019 03:24:36 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id p18so21709993qkk.0 for ; Tue, 28 May 2019 03:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=S+kmS8qEsQM+zWPN/vesR2Ri8IqmDnDcUnFf17Lrwfk=; b=dLjX3SyNwqqgHuSEdZeY0d2ohl52gp8FDizW5S3Hk20sCoATeug10giiSuiW+YdrGI EhwlJEDswUHatKR1WBuZhIERrwuBYyW5L+FowlaLaIMlFLiJZ77SY/9WILb9IBDNAlWJ U2kM8joP5JDtxW1888o/mDbb978yOH4F+ApZc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=S+kmS8qEsQM+zWPN/vesR2Ri8IqmDnDcUnFf17Lrwfk=; b=gXplhPicLcYFac3Tn1rBUnYQ02/P8qa81EUeOIKJdGyjIdAFqvj+4FAuxjS4B/r7K+ uUZEU1pfJBftPXqCu0NW13vRycitbPv9dgVaj3IXPciExZkhC1vSCVy88XSzOQb8GYcK RgVobgFk70wFVfF9fnwoUY9Swbi5rqehLe5k0fl34VSRdEc8cgQkFdWULyJ5QzYqKZ95 CDiqY7a2NHlOQ+ia4+E9utLytsHxp8P85ASA2rIaTljTwRrKXSmaizfqgIMBzCkZheMm CljmgxjmMG+EsKEA8702htKX4WoIy7JIp5jlUgo7oTGSy2zPEiuEQ3YXU8d5bJ0IcE1E hovA== X-Gm-Message-State: APjAAAXf/HXE9GkMZJaE9C5GT5ZcZMgHCBg83cBwgK2LcRX+pp3bbH9K zSZDLqun28tMgBucuV2Hb+HvoQ== X-Google-Smtp-Source: APXvYqyU5nm/OfVAx3ObGhGg/hrHysrj+KN+f/yahHLkjR1qbI64NY4l57/+u8vwUOi9miMBvrXZ1g== X-Received: by 2002:a0c:9950:: with SMTP id i16mr93358696qvd.165.1559039075643; Tue, 28 May 2019 03:24:35 -0700 (PDT) Received: from [192.168.2.105] (pool-96-255-231-27.washdc.fios.verizon.net. [96.255.231.27]) by smtp.googlemail.com with ESMTPSA id c32sm5526642qtd.61.2019.05.28.03.24.32 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 28 May 2019 03:24:34 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.7.6.170621 Date: Tue, 28 May 2019 06:24:35 -0400 From: Carl Wallace To: Vincent Roca CC: , , Message-ID: Thread-Topic: secdir review of draft-ietf-tsvwg-tinymt32 References: <3B5B0C9F-849C-4EBA-86F0-24172278BEF8@inria.fr> In-Reply-To: <3B5B0C9F-849C-4EBA-86F0-24172278BEF8@inria.fr> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3641869480_5181310" Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-tsvwg-tinymt32 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, 28 May 2019 10:24:39 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3641869480_5181310 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Great. Thanks.=20 From: Vincent Roca Date: Monday, May 27, 2019 at 5:02 AM To: Carl Wallace Cc: Vincent Roca , , , Subject: Re: secdir review of draft-ietf-tsvwg-tinymt32 > Hello Carl, all, >=20 > Thanks a lot for your secdir review. >=20 >> Le 17 mai 2019 =C3=A0 20:38, Carl Wallace a =C3=A9cr= it : >>=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 ar= ea >> directors. Document editors and WG chairs should treat these comments >> just like any other last call comments. >>=20 >> This document describes the TinyMT32 Pseudo Random Number Generator (PRN= G) >> that produces 32-bit pseudo-random unsigned integers and aims at having = a >> simple-to-use and deterministic solution. The document is well written a= nd >> the sample code produces the sample output. I am not a mathematician so = no >> comments on the mechanism. I have a few minor nits/comments. >=20 >=20 >=20 >> The security >> considerations may benefit from repeating the last sentence of the fourt= h >> paragraph in the introduction (I.e., not 'meant to be used for >> cryptographic applications=E2=80=99). >=20 > [VR] Very good suggestion. Added. >=20 > NEW: > 4. Security Considerations >=20 > The authors do not believe the present specification generates > specific security risks per se. However, neither the TinyMT nor MT > PRNG are meant to be used for cryptographic applications. >=20 >> The bibliography should include all of the >> references cited in the draft. >=20 > [VR] We agree, and we changed all > links to a well identified =C2=AB Informative References =C2=BB entry. >=20 > NEW: > [TinyMT-dev] > Saito, M. and M. Matsumoto, "Tiny Mersenne Twister > (TinyMT) github site", MersenneTwister-Lab/TinyMT>. >=20 > [TinyMT-params] > Rikitake, K., "TinyMT pre-calculated parameter list github > site", . >=20 > [TinyMT-web] > Saito, M. and M. Matsumoto, "Tiny Mersenne Twister > (TinyMT) web site", > . >=20 >> Adding some text or references to expand on >> the mentioned limitations of RFC5170 or to describe how the parameter se= t >> from which the parameters selected in this draft would be nice as well. >=20 > [VR] We agree. I=E2=80=99ve added a mention to the =C2=AB Numerical Recipes in C =C2=BB= 2nd > edition for the limits of the Park-Miller PRNG specified in RFC 5170, as = well > as the companion RLC I-D where we mention the observations we made with > this PRNG. >=20 > NEW: > [=E2=80=A6] TinyMT32 represents a major improvement with respect to the > Park-Miler Linear Congruential PRNG (e.g., as specified in [RFC5170]) > that suffers several known limitations (see for instance [PTVF92], > section 7.1, pp. 279, and [RLC-ID], Appendix B). >=20 >=20 > Concerning the chosen parameter set, they have been selected among an > official list of parameter set values, as explained. It=E2=80=99s a bit arbitra= ry (we > chose > the 1st entry), as explained, but it=E2=80=99s a common parameter set (there=E2=80=99= s a > publication based on it listed in the Informative References section). > There=E2=80=99s of course a theoretical background but I don=E2=80=99t think it=E2=80=99s w= orth > entering=20 > that kind of details (especially as the two authors didn=E2=80=99t publish a re= search > paper on TinyMT32). >=20 > Thanks a lot for your comments. >=20 > Cheers, >=20 > Vincent on behalf of the authors --B_3641869480_5181310 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Great. Thanks. 

From: Vincent Roca <vincent.roca@inria.fr>
Date: Monday, May 27, 2019 at 5:02 AM
To: Carl Wallace <carl@redhoundsoftware.com>
Cc: Vincent Roca <vincent.roca@inria.fr>, <se= cdir@ietf.org>, <draft-ietf-tsvwg-tinymt32.all@ietf.org>, <iesg@ietf.org>
Subjec= t: Re: secdir review of draft-ietf-tsvwg-tinymt32

=
H= ello Carl, all,

Thanks a lot f= or your secdir review.

Le 17 mai 2019 =C3=A0 20:38, Carl Wallace &= lt;carl@redhoundsoftware= .com> a =C3=A9crit :

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

This document describes the Tiny= MT32 Pseudo Random Number Generator (PRNG)
that produces 32-bit = pseudo-random unsigned integers and aims at having a
simple-to-u= se and deterministic solution. The document is well written and
= the sample code produces the sample output. I am not a mathematician so nocomments on the mechanism. I have a few minor nits/comments.



The secur= ity
considerations may benefit from repeating the last sentence = of the fourth
paragraph in the introduction (I.e., not 'meant to= be used for
cryptographic applications’).

[VR] Very good suggestio= n. Added.

NEW:
4.  Security Considerations
=
   The authors do n= ot believe the present specification generates
  &nb= sp;specific security risks per se.  However, neither the Ti= nyMT nor MT
   PRNG are meant t= o be used for cryptographic applications.

The bibliography should include all of the
reference= s cited in the draft.

= [VR] We agree, and we changed all <eref target=3D=C2=AB https://…&nb= sp;=C2=BB />
links to a well identified =C2=AB Informative References&n= bsp;=C2=BB entry.

NEW:
  &= nbsp;[TinyMT-dev]
             = Saito, M. and M. Matsumoto, "Tiny Mersenne Twister
    =           (TinyMT) github site", <https://github.com/
    &nb= sp;         MersenneTwister-Lab/TinyMT>.
   [TinyMT-params]
    &= nbsp;         Rikitake, K., "TinyMT pre-calculated param= eter list github
              = site", <= https://github.com/jj1bdx/tinymtdc-longbatch/>.

   [TinyMT-web]
       =       Saito, M. and M. Matsumoto, "Tiny Mersenne Twister
              (TinyMT) web site",<= /div>

<= blockquote type=3D"cite" class=3D"">
Adding some text= or references to expand on
the mentioned limitations of RFC5170= or to describe how the parameter set
from which the parameters = selected in this draft would be nice as well.

[VR] We agree. I’ve adde= d a mention to the =C2=AB Numerical Recipes in C =C2=BB 2nd 
edition for the limits of the Park-Miller PRNG specified in RFC 5= 170, as well
as the companion RLC I-D where we mention th= e observations we made with
this PRNG.

NEW:
&nbs= p;  […] TinyMT32 represents a major improvement with respect to t= he
   Park-Miler Linear Congruential PRNG (e.g.= , as specified in [RFC5170])
   that suffers se= veral known limitations (see for instance [PTVF92],
   section 7.1, pp. 279, and [RLC-ID], Appe= ndix B).


Concerning the chosen parameter set, they have b= een selected among an
official list of parameter set valu= es, as explained. It’s a bit arbitrary (we chose
th= e 1st entry), as explained, but it’s a common parameter set (thereR= 17;s a 
publication based on it listed in the Inform= ative References section).
There’s of course a theo= retical background but I don’t think it’s worth entering 
that kind of details (especially as the two authors didn&#= 8217;t publish a research
paper on TinyMT32).

Thanks a lot for your comments.

Cheers,
=
  Vincent on behalf of the authors
 --B_3641869480_5181310-- From nobody Tue May 28 10:17: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 B21A7120225; Tue, 28 May 2019 10:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k21vUFw4_PS; Tue, 28 May 2019 10:17:45 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C41D12020A; Tue, 28 May 2019 10:17:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id BB154E2045; Tue, 28 May 2019 13:17:42 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 19497-04; Tue, 28 May 2019 13:17:41 -0400 (EDT) Received: from securerf.ihtfp.org (99-46-190-172.lightspeed.tukrga.sbcglobal.net [99.46.190.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id DB40FE2042; Tue, 28 May 2019 13:17:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1559063861; bh=HJtZTAlywAKH2sfCvvvYNbyhJqv0xcZrAPclCWgYmAg=; h=From:To:Cc:Subject:Date; b=mDR91E7mgP4Fi61tnK/+CiVN7cuGrin9ZkzLZXJRhuDGEWUam8BRp4Dw3Ey6622B0 2r+A4ztsk0RW4R8YQ2EZmfDg+WyADvdc2dUHozZQi4noU3S7Xx1yetjTLkykOGhDTT 8BuGZKNEwv2mKdOy2bZvwU1rjpJjzJSJ2TADVHZI= Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.15.2/Submit) id x4SHHVME023973; Tue, 28 May 2019 13:17:31 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Cc: pce-chairs@ietf.org, yosuke.tanaka@ntt.com, dhruv.ietf@gmail.com, hari@netflix.com, msiva@cisco.com, edward.crabbe@gmail.com, inaminei@google.com Date: Tue, 28 May 2019 13:17:29 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: Subject: [secdir] sec-dir review of draft-ietf-pce-association-group-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, 28 May 2019 17:17:48 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: * Ready to publish Details: * none to report -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From nobody Tue May 28 10:35:24 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 43E3F120198; Tue, 28 May 2019 10:35:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar via Datatracker To: Cc: draft-ietf-netvc-requirements.all@ietf.org, video-codec@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Linda Dunbar Message-ID: <155906492120.25733.13337604572333992432@ietfa.amsl.com> Date: Tue, 28 May 2019 10:35:21 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-netvc-requirements-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: Tue, 28 May 2019 17:35:21 -0000 Reviewer: Linda Dunbar 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 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 describes the overview of internet Video codec applications and the corresponding requirements. However, it doesn't cover any security requirement. Section 5 on Security Consideration description doesn't make sense to me. It stats that not covering worst case of computational complexity/memory bandwidth can be considered as security vulnerability and lead to denial of services (DoS) in the case of attacks. why ? what are "the worst case of computational complexity/memory bandwidth"? why covering them can eliminate the "security vulnerability"? Linda Dunbar From nobody Tue May 28 21:15: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 20A75120105; Tue, 28 May 2019 21:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 YDHNB_NBP_ye; Tue, 28 May 2019 21:15:04 -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 08944120047; Tue, 28 May 2019 21:15:04 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id n5so636736ioc.7; Tue, 28 May 2019 21:15:03 -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=yuxOJK3qbAR7sUpxWAWELnDtL2oml4VOlu9ScL4tGiA=; b=XrChwz/u8gfN13U2+NkDiFT3dXAmQIGJsUwHbb68Sm/vYG7Cz+uGFKHyh7JeMtyCCn u8Ttn/Z3O+HS6lIqfnzJgJ8h03tDcqIbWxpExg8W7miahhBdhkBx3KMmHxx0W3Tr8wN/ xEsd4N5Ebe1rhhOXFRyvX+isIdV3KtGrPENUXE3J5+k5/0OP0+Tm5HUKBFoT+CUWof9s WxJpyly0qA5B9YboL7O2bL//qtO99FzWDvWY3seWHs1X7qm2sGuZ3lWiW+1Y6txtl+kj 2mi3Ydlk2jNgs48zBN0mZeGEZeWQUg3N7t6y/aObv8PM9OC8PJ6ldOvfpQOBlx+x+dDX IRzg== 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=yuxOJK3qbAR7sUpxWAWELnDtL2oml4VOlu9ScL4tGiA=; b=l9x0E4D5TyfggnTaU3NHUeDrsvtQ8V8+o3Cb5YaT6Dq/jIWJJkRxJhOMe2Upd85yrT 4VlXZzhy7YrzSXQ/PjL64FrzA+NjhrSFM1DxlAYsPjHcBXH49ccPumEXERw7sq4b+fqV 9Q1fUfdpaJMo3Yi0hEikhFXE1IPNrWMor7T/EBb8ip6OsTDRIjVIrIKm3OLQkL4A4AEe /68SYQ6yxlFkgDHVsiHV+QyuriCzxodey7ZmTuu69Msd6+nMgbOEwN20kPcRy0xdmjK8 L9JoG5q3xUtqZGfXzE5XOrtk89iX522NeLF1r+DT3hsDsx8L544gw5FlMyVe70iCA3FM 3o6A== X-Gm-Message-State: APjAAAUTYAKy9UPvQfxiSH8hGdFFdjBQJvBGbDPed3eiTTEyIMXz+ZHK pwqw0/yd2nR1on2glPFtzco3f8zp/2EvqJlst7HVHU16 X-Google-Smtp-Source: APXvYqwiv64KNqh9sOFv2MkL+rt/d38ZChd0VnYyqjlDRH0WjtFYDGomXklz4Plf2jDd06XzOynCapcTttACaYf7bpg= X-Received: by 2002:a5d:9306:: with SMTP id l6mr1950083ion.168.1559103302971; Tue, 28 May 2019 21:15:02 -0700 (PDT) MIME-Version: 1.0 From: Donald Eastlake Date: Wed, 29 May 2019 00:14:51 -0400 Message-ID: To: "iesg@ietf.org" , draft-ietf-softwire-map-radius.all@ietf.org Cc: secdir Content-Type: multipart/alternative; boundary="0000000000008ab9050589ff065c" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-softwire-map-radius-23 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, 29 May 2019 04:15:05 -0000 --0000000000008ab9050589ff065c 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. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Almost Ready. This draft specifies new RADIUS attributes that correspond with DHCPv6 Options for a number of IPv4 over IPv6 protocols. The main scenario being supported is that customer equipment connects to a Broadband Network Gateway (BNG). The BNG then authenticates the user with a AAA server using RADIUS. There is also a DHCPv6 server at the BNG and the value of relevant DHCPv6 Options are populated at the BNG from the RADIUS attributes in the response from the AAA server. Section 6 provides Security Considerations. It consists almost entirely in a list of references to security considerations in other RFCs. This seems pretty complete but reading it feels kind of scattered. It would be good if a few sentences could be added and the maybe the material slightly re-organized to make it clearer how the parts of the Security Considerations fit together. Trivia: - Although there isn't much questions here, I think it is usual when creating a registry that goes on an existing web page to identify that web page. - The acronyms BMR and DMR are only used once in the body of the document. Perhaps they could be dispensed with and only the spelled out version used at that one occurrence for each. There may be other acronyms like this. - lwAFTR should be expanded on first use. - There is a slightly awkward thing about the IANA Considerations section. The first sentence of Section 7 talks about requesting IANA to act but then each subsection redundantly requests action and, in fact Section 7.1 request action at the start of each paragraph. Either (1) the first sentence should say something like "IANA is requested to perform the actions described in the subsections below." and all the other "request" wording should go away or (2) the first sentence should omit "request" wording and just say something like "IANA actions are discussed in the subsections below." and the "requests" left in the subsections. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com --0000000000008ab9050589ff065c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security dire= ctorate's ongoing effort to review all IETF documents being processed b= y the IESG.=C2=A0 Document editors and WG chairs should treat these comment= s just like any other last call comments.

The summary of the review = is Almost Ready.

This draft specifies new RADIUS attributes that cor= respond with DHCPv6 Options for a number of IPv4 over IPv6 protocols. The m= ain scenario being supported is that customer equipment connects to a Broad= band Network Gateway (BNG). The BNG then authenticates the user with a AAA = server using RADIUS. There is also a DHCPv6 server at the BNG and the value= of relevant DHCPv6 Options are populated at the BNG from the RADIUS attrib= utes in the response from the AAA server.

Section 6 prov= ides Security Considerations. It consists almost entirely in a list of refe= rences to security considerations in other RFCs.=C2=A0 This seems pretty co= mplete but reading it feels kind of scattered. It would be good if a few se= ntences could be added and the maybe the material slightly re-organized to = make it clearer how the parts of the Security Considerations fit together.<= /div>

Trivia:
  • Although there isn't= much questions here, I think it is usual when creating a registry that goe= s on an existing web page to identify that web page.
  • The acronyms B= MR and DMR are only used once in the body of the document. Perhaps they cou= ld be dispensed with and only the spelled out version used at that one occu= rrence for each. There may be other acronyms like this.
  • lwAFTR shou= ld be expanded on first use.
  • There is a slightly awkward thing abou= t the IANA Considerations section. The first sentence of Section 7 talks ab= out requesting IANA to act but then each subsection redundantly requests ac= tion and, in fact Section 7.1 request action at the start of each paragraph= . Either (1) the first sentence should say something like "IANA is req= uested to perform the actions described in the subsections below." and= all the other "request" wording should go away or (2) the first = sentence should omit "request" wording and just say something lik= e "IANA actions are discussed in the subsections below." and the = "requests" left in the subsections.
Than= ks,
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= +1-508-333-2270 (cell)
=C2=A01424 Pro Shop Court, Davenport, FL 33896 U= SA
=C2=A0d3e3e3@gmail.com
<= /div>
--0000000000008ab9050589ff065c-- From nobody Wed May 29 01:24: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 A714612011C; Wed, 29 May 2019 01:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 scCgoqnTtELP; Wed, 29 May 2019 01:24:30 -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 5E2A91200F9; Wed, 29 May 2019 01:24:30 -0700 (PDT) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id DA1F474E239E11457A1B; Wed, 29 May 2019 09:24:27 +0100 (IST) Received: from fraeml706-chm.china.huawei.com (10.206.15.55) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 29 May 2019 09:24:27 +0100 Received: from fraeml705-chm.china.huawei.com (10.206.15.54) by fraeml706-chm.china.huawei.com (10.206.15.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 29 May 2019 10:24:27 +0200 Received: from fraeml705-chm.china.huawei.com ([10.206.112.183]) by fraeml705-chm.china.huawei.com ([10.206.112.183]) with mapi id 15.01.1713.004; Wed, 29 May 2019 10:24:27 +0200 From: Filippov Alexey To: Linda Dunbar , "secdir@ietf.org" CC: "draft-ietf-netvc-requirements.all@ietf.org" , "video-codec@ietf.org" , "ietf@ietf.org" , Elena Alshina Thread-Topic: Secdir last call review of draft-ietf-netvc-requirements-09 Thread-Index: AQHVFXvB/QOZDB7VaEmRwya5HDEc/qaBpN4Q Date: Wed, 29 May 2019 08:24:27 +0000 Message-ID: <15bb8ab80acd410ba7e22809eb95e727@huawei.com> References: <155906492120.25733.13337604572333992432@ietfa.amsl.com> In-Reply-To: <155906492120.25733.13337604572333992432@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.198.51.251] 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 last call review of draft-ietf-netvc-requirements-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, 29 May 2019 08:24:33 -0000 RGVhciBMaW5kYSwNCg0KVGhhbmsgeW91IGEgbG90IGZvciB5b3VyIGNvbW1lbnRzIGFuZCBxdWVz dGlvbnMuIEJlbG93LCBwbGVhc2UsIGZpbmQgbXkgYW5zd2Vycy4NCj4gd2h5ID8NCkluIHRoZSBj YXNlIG9mIHNvZnR3YXJlIGltcGxlbWVudGF0aW9uLCBkZWNvZGluZyBhIGNvbXByZXNzZWQgc3Ry ZWFtIGNhbiBiZSBhIGNvbXB1dGF0aW9uYWxseSBpbnRlbnNpdmUgcHJvY2VzcyB0aGF0IGNhbiBy ZXF1aXJlIGV4dGVuc2l2ZSBkYXRhIGV4Y2hhbmdlIGJldHdlZW4gaW50ZXJuYWwgYW5kIGV4dGVy bmFsIG1lbW9yeS4gU28sIGlmIGRlY29kaW5nIHNob3VsZCBiZSBwZXJmb3JtZWQgaW4gcmVhbCB0 aW1lLCB0aGlzIHByb2Nlc3MgY2FuIGFsbG9jYXRlIHRvbyBtYW55IGNvbXB1dGF0aW9uYWwgcmVz b3VyY2VzIChzdWNoIGFzIHByb2Nlc3NvciBjb3JlcyBhbmQgbWVtb3J5IHRoYXQgaGFzIGxpbWl0 ZWQgYmFuZHdpZHRoICkgdGhhdCBhcmUgYmVjb21pbmcgdW5hdmFpbGFibGUgZm9yIG90aGVyIHRh c2tzLiBUaGlzIHNpdHVhdGlvbiBjYW4gbGVhZCB0byBkZW5pYWwtb2Ytc2VydmljZXMgaXNzdWVz IChzdWNoIGFzIG1lZGlhIGJsYWNraG9sZSBhdHRhY2sgdGhhdCBpcyBzaW1pbGFyIHRvIHBhY2tl dCBkcm9wIGF0dGFjaywgaHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvUGFja2V0X2Ryb3Bf YXR0YWNrKS4gVGh1cywgZm9yZ2luZyBzdWNoIHN0cmVhbXMgdGhhdCByZXF1aXJlIHRvbyBtYW55 IGNvbXB1dGF0aW9uYWwgcmVzb3VyY2VzIGZvciBkZWNvZGluZyBjYW4gYmUgY29uc2lkZXJlZCBh IERvUyBhdHRhY2suIFRvIGFkZHJlc3MgdGhpcyBzZWN1cml0eSBpc3N1ZSwgY29tcHV0YXRpb25h bCByZXNvdXJjZXMgc2hvdWxkIGJlIGFsbG9jYXRlZCBhY2NvcmRpbmcgdG8gYSBjb2RlYyBsZXZl bCB0aGF0IGluIGZhY3QgZGVmaW5lcyAidGhlIHdvcnN0IGNhc2Ugb2YgY29tcHV0YXRpb25hbCBj b21wbGV4aXR5LCBtZW1vcnkgYmFuZHdpZHRoLCBhbmQgcGh5c2ljYWwgbWVtb3J5IHNpemUiLiBJ dCBzaG91bGQgZ3VhcmFudGVlIHRoYXQgYW55IHBpY3R1cmUgY2FuIGJlIGRlY29kZWQgd2l0aGlu IGEgY2VydGFpbiBtYXhpbXVtIHRpbWUgcGVyaW9kIGZvciBnaXZlbiBjb21wdXRhdGlvbmFsIHJl c291cmNlcy4NCg0KLS0NCkJlc3QgcmVnYXJkcywNCkFsZXhleSBGaWxpcHBvdg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTGluZGEgRHVuYmFyIHZpYSBEYXRhdHJhY2tlciBb bWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmddIA0KU2VudDogVHVlc2RheSwgTWF5IDI4LCAyMDE5IDg6 MzUgUE0NClRvOiBzZWNkaXJAaWV0Zi5vcmcNCkNjOiBkcmFmdC1pZXRmLW5ldHZjLXJlcXVpcmVt ZW50cy5hbGxAaWV0Zi5vcmc7IHZpZGVvLWNvZGVjQGlldGYub3JnOyBpZXRmQGlldGYub3JnDQpT dWJqZWN0OiBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldHZjLXJlcXVp cmVtZW50cy0wOQ0KDQpSZXZpZXdlcjogTGluZGEgRHVuYmFyDQpSZXZpZXcgcmVzdWx0OiBIYXMg Tml0cw0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1 cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1 bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiAgVGhlc2UgY29tbWVudHMgd2VyZSB3 cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGly ZWN0b3JzLg0KIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhl c2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciAgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpU aGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgb3ZlcnZpZXcgb2YgaW50ZXJuZXQgVmlkZW8gY29k ZWMgYXBwbGljYXRpb25zIGFuZCB0aGUgY29ycmVzcG9uZGluZyByZXF1aXJlbWVudHMuIEhvd2V2 ZXIsIGl0IGRvZXNuJ3QgY292ZXIgYW55IHNlY3VyaXR5IHJlcXVpcmVtZW50Lg0KDQpTZWN0aW9u IDUgb24gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbiBkZXNjcmlwdGlvbiBkb2Vzbid0IG1ha2Ugc2Vu c2UgdG8gbWUuIEl0IHN0YXRzIHRoYXQgIG5vdCBjb3ZlcmluZyB3b3JzdCBjYXNlIG9mIGNvbXB1 dGF0aW9uYWwgY29tcGxleGl0eS9tZW1vcnkgYmFuZHdpZHRoIGNhbiBiZSBjb25zaWRlcmVkIGFz IHNlY3VyaXR5IHZ1bG5lcmFiaWxpdHkgYW5kIGxlYWQgdG8gZGVuaWFsIG9mIHNlcnZpY2VzIChE b1MpIGluIHRoZSBjYXNlIG9mIGF0dGFja3MuDQoNCndoeSA/DQoNCndoYXQgYXJlICJ0aGUgd29y c3QgY2FzZSBvZiBjb21wdXRhdGlvbmFsIGNvbXBsZXhpdHkvbWVtb3J5IGJhbmR3aWR0aCI/IHdo eSBjb3ZlcmluZyB0aGVtIGNhbiBlbGltaW5hdGUgdGhlICJzZWN1cml0eSB2dWxuZXJhYmlsaXR5 Ij8NCg0KTGluZGEgRHVuYmFyDQoNCg== From nobody Wed May 29 02:12: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 25E1C12004F; Wed, 29 May 2019 02:12:42 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 QLvAh0cjxtc6; Wed, 29 May 2019 02:12:39 -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 0FCC21200F6; Wed, 29 May 2019 02:12:39 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 45DQ3867Y1z3029; Wed, 29 May 2019 11:12:36 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.98]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 45DQ384vXczBrLm; Wed, 29 May 2019 11:12:36 +0200 (CEST) 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; Wed, 29 May 2019 11:12:36 +0200 From: To: Donald Eastlake , "iesg@ietf.org" , "draft-ietf-softwire-map-radius.all@ietf.org" CC: secdir Thread-Topic: SECDIR review of draft-ietf-softwire-map-radius-23 Thread-Index: AQHVFdUaRMSSr8gmnES7BzA8wGZN6KaBzkBg Date: Wed, 29 May 2019 09:12:35 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA9096E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: 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.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302EA9096EOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-softwire-map-radius-23 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, 29 May 2019 09:12:42 -0000 --_000_787AE7BB302AE849A7480A190F8B93302EA9096EOPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRG9uYWxkLA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuDQoNClBsZWFzZSBzZWUgaW5s aW5lLg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBEb25hbGQgRWFzdGxha2UgW21haWx0bzpkM2Uz ZTNAZ21haWwuY29tXQ0KRW52b3nDqSA6IG1lcmNyZWRpIDI5IG1haSAyMDE5IDA2OjE1DQrDgCA6 IGllc2dAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtc29mdHdpcmUtbWFwLXJhZGl1cy5hbGxAaWV0Zi5v cmcNCkNjIDogc2VjZGlyDQpPYmpldCA6IFNFQ0RJUiByZXZpZXcgb2YgZHJhZnQtaWV0Zi1zb2Z0 d2lyZS1tYXAtcmFkaXVzLTIzDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBh cnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3 IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBEb2N1bWVu dCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3Qg bGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpUaGUgc3VtbWFyeSBvZiB0aGUg cmV2aWV3IGlzIEFsbW9zdCBSZWFkeS4NCg0KVGhpcyBkcmFmdCBzcGVjaWZpZXMgbmV3IFJBRElV UyBhdHRyaWJ1dGVzIHRoYXQgY29ycmVzcG9uZCB3aXRoIERIQ1B2NiBPcHRpb25zIGZvciBhIG51 bWJlciBvZiBJUHY0IG92ZXIgSVB2NiBwcm90b2NvbHMuIFRoZSBtYWluIHNjZW5hcmlvIGJlaW5n IHN1cHBvcnRlZCBpcyB0aGF0IGN1c3RvbWVyIGVxdWlwbWVudCBjb25uZWN0cyB0byBhIEJyb2Fk YmFuZCBOZXR3b3JrIEdhdGV3YXkgKEJORykuIFRoZSBCTkcgdGhlbiBhdXRoZW50aWNhdGVzIHRo ZSB1c2VyIHdpdGggYSBBQUEgc2VydmVyIHVzaW5nIFJBRElVUy4gVGhlcmUgaXMgYWxzbyBhIERI Q1B2NiBzZXJ2ZXIgYXQgdGhlIEJORyBhbmQgdGhlIHZhbHVlIG9mIHJlbGV2YW50IERIQ1B2NiBP cHRpb25zIGFyZSBwb3B1bGF0ZWQgYXQgdGhlIEJORyBmcm9tIHRoZSBSQURJVVMgYXR0cmlidXRl cyBpbiB0aGUgcmVzcG9uc2UgZnJvbSB0aGUgQUFBIHNlcnZlci4NCg0KU2VjdGlvbiA2IHByb3Zp ZGVzIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zLiBJdCBjb25zaXN0cyBhbG1vc3QgZW50aXJlbHkg aW4gYSBsaXN0IG9mIHJlZmVyZW5jZXMgdG8gc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4gb3Ro ZXIgUkZDcy4gIFRoaXMgc2VlbXMgcHJldHR5IGNvbXBsZXRlIGJ1dCByZWFkaW5nIGl0IGZlZWxz IGtpbmQgb2Ygc2NhdHRlcmVkLiBJdCB3b3VsZCBiZSBnb29kIGlmIGEgZmV3IHNlbnRlbmNlcyBj b3VsZCBiZSBhZGRlZCBhbmQgdGhlIG1heWJlIHRoZSBtYXRlcmlhbCBzbGlnaHRseSByZS1vcmdh bml6ZWQgdG8gbWFrZSBpdCBjbGVhcmVyIGhvdyB0aGUgcGFydHMgb2YgdGhlIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zIGZpdCB0b2dldGhlci4NCg0KW01lZF0gU3VyZS4gSSByZW9yZ2FuaXplZCB0 aGUgdGV4dCBhbW9uZyB0aGUgZm9sbG93aW5nIGxpbmVzIDoNCg0KwrcgICAgICAgICBSZW1pbmRl ciBvZiBzZWN1cml0eSBpc3N1ZXMgc3BlY2lmaWMgdG8gZWFjaCBzb2Z0d2lyZSBtZWNoYW5pc20u DQoNCsK3ICAgICAgICAgS25vd24gUkFESVVTIHZ1bG5lcmFiaWxpdGllcyBhcHBseSB0byB0aGlz IHNwZWMuDQoNCsK3ICAgICAgICAgQk5HLUFBQSBzZXJ2ZXI6IFRoZSBkb2N1bWVudCBhc3N1bWVz IHRoYXQgYSB0cnVzdCByZWxhdGlvbnNoaXAgaXMgaW4gcGxhY2UgYmV0d2VlbiB0aGUgUkFESVVT IGNsaWVudCBhbmQgc2VydmVyLiBJUHNlYy90bHMgY2FuIGJlIHVzZWQNCg0KwrcgICAgICAgICBD RS1CTkc6IHBvaW50ZXJzIHRvIHRoZSBleGlzdGluZyBESENQIFJGQ3MuDQoNCllvdSBjYW4gY2hl Y2sgYXQ6IGh0dHBzOi8vZ2l0aHViLmNvbS9ib3VjYWRhaXIvZHJhZnQtaWV0Zi1zb2Z0d2lyZS1t YXAtcmFkaXVzL2Jsb2IvbWFzdGVyL3dkaWZmJTIwZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tYXAtcmFk aXVzLTIzLnR4dCUyMGRyYWZ0LWlldGYtc29mdHdpcmUtbWFwLXJhZGl1cy0yMy5wZGYNCg0KVHJp dmlhOg0KDQogICogICBBbHRob3VnaCB0aGVyZSBpc24ndCBtdWNoIHF1ZXN0aW9ucyBoZXJlLCBJ IHRoaW5rIGl0IGlzIHVzdWFsIHdoZW4gY3JlYXRpbmcgYSByZWdpc3RyeSB0aGF0IGdvZXMgb24g YW4gZXhpc3Rpbmcgd2ViIHBhZ2UgdG8gaWRlbnRpZnkgdGhhdCB3ZWIgcGFnZS4NCltNZWRdIERv bmUuDQoNCiAgKiAgIFRoZSBhY3JvbnltcyBCTVIgYW5kIERNUiBhcmUgb25seSB1c2VkIG9uY2Ug aW4gdGhlIGJvZHkgb2YgdGhlIGRvY3VtZW50LiBQZXJoYXBzIHRoZXkgY291bGQgYmUgZGlzcGVu c2VkIHdpdGggYW5kIG9ubHkgdGhlIHNwZWxsZWQgb3V0IHZlcnNpb24gdXNlZCBhdCB0aGF0IG9u ZSBvY2N1cnJlbmNlIGZvciBlYWNoLiBUaGVyZSBtYXkgYmUgb3RoZXIgYWNyb255bXMgbGlrZSB0 aGlzLg0KW01lZF0gV2lsbCBkb3VibGUgY2hlY2suDQoNCiAgKiAgIGx3QUZUUiBzaG91bGQgYmUg ZXhwYW5kZWQgb24gZmlyc3QgdXNlLg0KW01lZF0gT0suDQoNCiAgKiAgIFRoZXJlIGlzIGEgc2xp Z2h0bHkgYXdrd2FyZCB0aGluZyBhYm91dCB0aGUgSUFOQSBDb25zaWRlcmF0aW9ucyBzZWN0aW9u LiBUaGUgZmlyc3Qgc2VudGVuY2Ugb2YgU2VjdGlvbiA3IHRhbGtzIGFib3V0IHJlcXVlc3Rpbmcg SUFOQSB0byBhY3QgYnV0IHRoZW4gZWFjaCBzdWJzZWN0aW9uIHJlZHVuZGFudGx5IHJlcXVlc3Rz IGFjdGlvbiBhbmQsIGluIGZhY3QgU2VjdGlvbiA3LjEgcmVxdWVzdCBhY3Rpb24gYXQgdGhlIHN0 YXJ0IG9mIGVhY2ggcGFyYWdyYXBoLiBFaXRoZXIgKDEpIHRoZSBmaXJzdCBzZW50ZW5jZSBzaG91 bGQgc2F5IHNvbWV0aGluZyBsaWtlICJJQU5BIGlzIHJlcXVlc3RlZCB0byBwZXJmb3JtIHRoZSBh Y3Rpb25zIGRlc2NyaWJlZCBpbiB0aGUgc3Vic2VjdGlvbnMgYmVsb3cuIiBhbmQgYWxsIHRoZSBv dGhlciAicmVxdWVzdCIgd29yZGluZyBzaG91bGQgZ28gYXdheSBvciAoMikgdGhlIGZpcnN0IHNl bnRlbmNlIHNob3VsZCBvbWl0ICJyZXF1ZXN0IiB3b3JkaW5nIGFuZCBqdXN0IHNheSBzb21ldGhp bmcgbGlrZSAiSUFOQSBhY3Rpb25zIGFyZSBkaXNjdXNzZWQgaW4gdGhlIHN1YnNlY3Rpb25zIGJl bG93LiIgYW5kIHRoZSAicmVxdWVzdHMiIGxlZnQgaW4gdGhlIHN1YnNlY3Rpb25zLg0KW01lZF0g QWdyZWUuIEkgaGF2ZSBhbHJlYWR5IGZpeGVkIHRoaXMgb25lIGluIG15IGxvY2FsIGNvcHkuDQpU aGFua3MsDQpEb25hbGQNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBEb25hbGQg RS4gRWFzdGxha2UgM3JkICAgKzEtNTA4LTMzMy0yMjcwIChjZWxsKQ0KIDE0MjQgUHJvIFNob3Ag Q291cnQsIERhdmVucG9ydCwgRkwgMzM4OTYgVVNBDQogZDNlM2UzQGdtYWlsLmNvbTxtYWlsdG86 ZDNlM2UzQGdtYWlsLmNvbT4NCg== --_000_787AE7BB302AE849A7480A190F8B93302EA9096EOPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1h cmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0 Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9u cyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTcwOTIzOTMyOw0KCW1zby1saXN0LXRlbXBs YXRlLWlkczoxODIyODgyMDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlk aS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo3NDc3Njg0MDY7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjIwOTcwNjUzNjQgLTc5ODEyMjMwIDY3 ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1 Mjk5IDY3ODk1MzAxO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6NjsN Cgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDsNCgltc28tZmFy ZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5IaSBEb25hbGQsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj5UaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlBsZWFzZSBzZWUgaW5saW5lLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBEb25hbGQgRWFzdGxha2UgW21haWx0bzpkM2UzZTNAZ21haWwuY29tXQ0KPGJyPg0KPGI+RW52 b3nDqSZuYnNwOzo8L2I+IG1lcmNyZWRpIDI5IG1haSAyMDE5IDA2OjE1PGJyPg0KPGI+w4AmbmJz cDs6PC9iPiBpZXNnQGlldGYub3JnOyBkcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC1yYWRpdXMuYWxs QGlldGYub3JnPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBzZWNkaXI8YnI+DQo8Yj5PYmpldCZuYnNw Ozo8L2I+IFNFQ0RJUiByZXZpZXcgb2YgZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tYXAtcmFkaXVzLTIz PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg aGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVj dG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWlu ZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuJm5ic3A7IERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNo YWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0 IGNhbGwgY29tbWVudHMuPGJyPg0KPGJyPg0KVGhlIHN1bW1hcnkgb2YgdGhlIHJldmlldyBpcyBB bG1vc3QgUmVhZHkuPGJyPg0KPGJyPg0KVGhpcyBkcmFmdCBzcGVjaWZpZXMgbmV3IFJBRElVUyBh dHRyaWJ1dGVzIHRoYXQgY29ycmVzcG9uZCB3aXRoIERIQ1B2NiBPcHRpb25zIGZvciBhIG51bWJl ciBvZiBJUHY0IG92ZXIgSVB2NiBwcm90b2NvbHMuIFRoZSBtYWluIHNjZW5hcmlvIGJlaW5nIHN1 cHBvcnRlZCBpcyB0aGF0IGN1c3RvbWVyIGVxdWlwbWVudCBjb25uZWN0cyB0byBhIEJyb2FkYmFu ZCBOZXR3b3JrIEdhdGV3YXkgKEJORykuIFRoZSBCTkcgdGhlbiBhdXRoZW50aWNhdGVzIHRoZQ0K IHVzZXIgd2l0aCBhIEFBQSBzZXJ2ZXIgdXNpbmcgUkFESVVTLiBUaGVyZSBpcyBhbHNvIGEgREhD UHY2IHNlcnZlciBhdCB0aGUgQk5HIGFuZCB0aGUgdmFsdWUgb2YgcmVsZXZhbnQgREhDUHY2IE9w dGlvbnMgYXJlIHBvcHVsYXRlZCBhdCB0aGUgQk5HIGZyb20gdGhlIFJBRElVUyBhdHRyaWJ1dGVz IGluIHRoZSByZXNwb25zZSBmcm9tIHRoZSBBQUEgc2VydmVyLjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VjdGlvbiA2IHByb3ZpZGVzIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zLiBJdCBjb25zaXN0cyBhbG1vc3QgZW50aXJlbHkgaW4gYSBsaXN0IG9mIHJl ZmVyZW5jZXMgdG8gc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4gb3RoZXIgUkZDcy4mbmJzcDsg VGhpcyBzZWVtcyBwcmV0dHkgY29tcGxldGUgYnV0IHJlYWRpbmcgaXQgZmVlbHMga2luZCBvZiBz Y2F0dGVyZWQuIEl0IHdvdWxkIGJlIGdvb2QgaWYgYSBmZXcgc2VudGVuY2VzDQogY291bGQgYmUg YWRkZWQgYW5kIHRoZSBtYXliZSB0aGUgbWF0ZXJpYWwgc2xpZ2h0bHkgcmUtb3JnYW5pemVkIHRv IG1ha2UgaXQgY2xlYXJlciBob3cgdGhlIHBhcnRzIG9mIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyBmaXQgdG9nZXRoZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBT dXJlLiBJIHJlb3JnYW5pemVkIHRoZSB0ZXh0IGFtb25nIHRoZSBmb2xsb3dpbmcgbGluZXMmbmJz cDs6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5SZW1pbmRlciBvZiBzZWN1cml0eSBpc3N1ZXMgc3BlY2lmaWMgdG8gZWFjaCBzb2Z0d2ly ZSBtZWNoYW5pc20uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm8y Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5Lbm93biBSQURJVVMgdnVsbmVyYWJpbGl0aWVzIGFwcGx5IHRvIHRoaXMg c3BlYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPkJORy1BQUEgc2VydmVyOiBUaGUgZG9jdW1lbnQgYXNzdW1lcyB0aGF0IGEgdHJ1c3Qg cmVsYXRpb25zaGlwIGlzIGluIHBsYWNlIGJldHdlZW4gdGhlIFJBRElVUyBjbGllbnQgYW5kIHNl cnZlci4gSVBzZWMvdGxzIGNhbiBiZSB1c2VkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0 OmwxIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNrIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5DRS1CTkc6IHBvaW50ZXJzIHRvIHRoZSBleGlz dGluZyBESENQIFJGQ3MuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+WW91IGNhbiBjaGVjayBhdDoNCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNv bS9ib3VjYWRhaXIvZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tYXAtcmFkaXVzL2Jsb2IvbWFzdGVyL3dk aWZmJTIwZHJhZnQtaWV0Zi1zb2Z0d2lyZS1tYXAtcmFkaXVzLTIzLnR4dCUyMGRyYWZ0LWlldGYt c29mdHdpcmUtbWFwLXJhZGl1cy0yMy5wZGYiPg0KaHR0cHM6Ly9naXRodWIuY29tL2JvdWNhZGFp ci9kcmFmdC1pZXRmLXNvZnR3aXJlLW1hcC1yYWRpdXMvYmxvYi9tYXN0ZXIvd2RpZmYlMjBkcmFm dC1pZXRmLXNvZnR3aXJlLW1hcC1yYWRpdXMtMjMudHh0JTIwZHJhZnQtaWV0Zi1zb2Z0d2lyZS1t YXAtcmFkaXVzLTIzLnBkZjwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Ucml2aWE6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+QWx0 aG91Z2ggdGhlcmUgaXNuJ3QgbXVjaCBxdWVzdGlvbnMgaGVyZSwgSSB0aGluayBpdCBpcyB1c3Vh bCB3aGVuIGNyZWF0aW5nIGEgcmVnaXN0cnkgdGhhdCBnb2VzIG9uIGFuIGV4aXN0aW5nIHc8L3Nw YW4+ZWIgcGFnZSB0byBpZGVudGlmeSB0aGF0IHdlYiBwYWdlLjxvOnA+PC9vOnA+PC9saT48L3Vs Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+W01lZF0gRG9u ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClRoZSBhY3JvbnltcyBCTVIgYW5k IERNUiBhcmUgb25seSB1c2VkIG9uY2UgaW4gdGhlIGJvZHkgb2YgdGhlIGRvY3VtZW50LiBQZXJo YXBzIHRoZXkgY291bGQgYmUgZGlzcGVuc2VkIHdpdGggYW5kIG9ubHkgdGhlIHNwZWxsZWQgb3V0 IHZlcnNpb24gdXNlZCBhdCB0aGF0IG9uZSBvY2N1cnJlbmNlIGZvciBlYWNoLiBUaGVyZSBtYXkg YmUgb3RoZXIgYWNyb255bXMgbGlrZSB0aGlzLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRd IFdpbGwgZG91YmxlIGNoZWNrLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRp c2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8 c3BhbiBsYW5nPSJFTi1VUyI+bHdBRlRSIHNob3VsZCBiZSBleHBhbmRlZCBvbiBmaXJzdCB1c2Uu PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIE9LLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPlRoZXJlIGlzIGEgc2xpZ2h0bHkg YXdrd2FyZCB0aGluZyBhYm91dCB0aGUgSUFOQSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLiBUaGUg Zmlyc3Qgc2U8L3NwYW4+bnRlbmNlIG9mIFNlY3Rpb24gNyB0YWxrcyBhYm91dCByZXF1ZXN0aW5n IElBTkEgdG8gYWN0IGJ1dCB0aGVuIGVhY2ggc3Vic2VjdGlvbiByZWR1bmRhbnRseSByZXF1ZXN0 cyBhY3Rpb24gYW5kLCBpbiBmYWN0IFNlY3Rpb24gNy4xIHJlcXVlc3QgYWN0aW9uDQogYXQgdGhl IHN0YXJ0IG9mIGVhY2ggcGFyYWdyYXBoLiBFaXRoZXIgKDEpIHRoZSBmaXJzdCBzZW50ZW5jZSBz aG91bGQgc2F5IHNvbWV0aGluZyBsaWtlICZxdW90O0lBTkEgaXMgcmVxdWVzdGVkIHRvIHBlcmZv cm0gdGhlIGFjdGlvbnMgZGVzY3JpYmVkIGluIHRoZSBzdWJzZWN0aW9ucyBiZWxvdy4mcXVvdDsg YW5kIGFsbCB0aGUgb3RoZXIgJnF1b3Q7cmVxdWVzdCZxdW90OyB3b3JkaW5nIHNob3VsZCBnbyBh d2F5IG9yICgyKSB0aGUgZmlyc3Qgc2VudGVuY2Ugc2hvdWxkIG9taXQNCiAmcXVvdDtyZXF1ZXN0 JnF1b3Q7IHdvcmRpbmcgYW5kIGp1c3Qgc2F5IHNvbWV0aGluZyBsaWtlICZxdW90O0lBTkEgYWN0 aW9ucyBhcmUgZGlzY3Vzc2VkIGluIHRoZSBzdWJzZWN0aW9ucyBiZWxvdy4mcXVvdDsgYW5kIHRo ZSAmcXVvdDtyZXF1ZXN0cyZxdW90OyBsZWZ0IGluIHRoZSBzdWJzZWN0aW9ucy48bzpwPjwvbzpw PjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5bTWVkXSBBZ3JlZS4gSSBoYXZlIGFscmVhZHkgZml4ZWQgdGhpcyBvbmUg aW4gbXkgbG9jYWwgY29weS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyw8YnI+ DQpEb25hbGQ8YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KJm5ic3A7 RG9uYWxkIEUuIEVhc3RsYWtlIDNyZCAmbmJzcDsgJiM0MzsxLTUwOC0zMzMtMjI3MCAoY2VsbCk8 YnI+DQombmJzcDsxNDI0IFBybyBTaG9wIENvdXJ0LCBEYXZlbnBvcnQsIEZMIDMzODk2IFVTQTxi cj4NCiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZDNlM2UzQGdtYWlsLmNvbSI+PHNwYW4g bGFuZz0iRU4tVVMiPmQzZTNlM0BnbWFpbC5jb208L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B93302EA9096EOPEXCAUBMA2corp_-- From nobody Wed May 29 04:15:34 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 2A859120119; Wed, 29 May 2019 04:15:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stephen Farrell via Datatracker To: Cc: pce@ietf.org, ietf@ietf.org, draft-ietf-pce-inter-area-as-applicability.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Stephen Farrell Message-ID: <155912851606.5505.8128704305266794780@ietfa.amsl.com> Date: Wed, 29 May 2019 04:15:16 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-pce-inter-area-as-applicability-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: Wed, 29 May 2019 11:15:16 -0000 Reviewer: Stephen Farrell Review result: Has Nits I'm not sure if this is a nit or not: The draft describes uses of PCE involving multiple domains. But the "domain" concept in this case seems to encompass both/either different administrative domains and/or different technology domains within a single administrative boundary. If it's realistic, wouldn't it be good give recommendations as to what to do at least when administrative boundaries are being crossed? (E.g. "use TLS" in that case.) Other than that the draft appears ready to me. From nobody Wed May 29 08:53: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 819BF120148; Wed, 29 May 2019 08:53:23 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cghSSHRtftK; Wed, 29 May 2019 08:53:22 -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 10090120162; Wed, 29 May 2019 08:53:21 -0700 (PDT) Received: from prolepsis.kaduk.org (c-24-16-119-19.hsd1.wa.comcast.net [24.16.119.19]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4TFrGjE017484 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 May 2019 11:53:19 -0400 Date: Wed, 29 May 2019 08:53:16 -0700 From: Benjamin Kaduk To: Sean Turner Cc: secdir@ietf.org, sipbrandy@ietf.org, draft-ietf-sipbrandy-osrtp.all@ietf.org, ietf@ietf.org Message-ID: <20190529155316.GC1875@prolepsis.kaduk.org> References: <155900970362.650.8194184838834826261@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <155900970362.650.8194184838834826261@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-sipbrandy-osrtp-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, 29 May 2019 15:53:23 -0000 On Mon, May 27, 2019 at 07:15:03PM -0700, Sean Turner via Datatracker wrote: > Reviewer: Sean Turner > Review result: Has Issues > > I had a read of the draft as well as the GENART and TSVART reviews (to avoid > duplicating comments). > > Summary: Ready with (minor) issues > > Issues: > > 0) I assume that the mismatch the TSVART refers to in the security > considerations has to do with 1) changing 4568 to require encryption but not > fail if authentication is not available, 2) pointing out that 4568's > requirement is routinely ignore for end-to-end encryption because using TLS > with intermediaries won't protect the SDP key, and 3) and reference errors (see > the next issue). On 1, that's kind the point of OSRTP - take the encryption > you can get. On 2, because it's the security considerations this document is > just saying don't expect to get end-to-end. Assuming, I've interpreted this I > think this draft is okay. Thanks for doing the cross-reference to the other reviews and thinking about the raised issues. > 1) I think these are just reference errors, but it would be good to double > check these (and I hadn't seen a response yet - might have missed it): > > S4: Not sure about these references too RFC7435. Maybe they should be to RFC > 4568 instead? > > s/The security considerations of [RFC7435] apply to OSRTP, > /The security considerations of [RFC4568] apply to OSRTP, > > s/Section 8.3 of [RFC7435]/Section 8.3 of [RFC4568] > > s/understood that the [RFC7435]/understood that the [RFC4568] > > Bikesheds: > > 0) The fact that it's Informational struck me as odd. > > 1) The fact there are no updates listed also strikes me as odd. > > Nits: > > 0) s2: Nits reports an error with the para. I think it's: > > s/RFC 2119 [RFC2119] RFC 8174 [RFC8174] > /RFC 2119 [RFC2119] [RFC8174] The snippet in RFC 8174 has "BCP 14 [RFC2119] [RFC8174]" in this role. -Ben > > 1) s1, 2nd para: s/[RFC5939] ./[RFC5939]. From nobody Wed May 29 17:37:56 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 0108112010F; Wed, 29 May 2019 17:37:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stefan Santesson via Datatracker To: Cc: spasm@ietf.org, ietf@ietf.org, draft-ietf-lamps-rfc6844bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Stefan Santesson Message-ID: <155917666691.9144.10382733252232760132@ietfa.amsl.com> Date: Wed, 29 May 2019 17:37:46 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-lamps-rfc6844bis-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: Thu, 30 May 2019 00:37:47 -0000 Reviewer: Stefan Santesson Review result: Ready This document is well written and in general I do not have any comment on the content beyond the previous reviews. One thing do come to my mind though. A common aspect of standards documents is that they only are relevant to those who declare compliance to the standard. This document is different as it relies on that all parties (CA:s) are aware of this standard and performs the stipulated checks. In the end I assume that this may affect relying parties and how they determine wether a particular certificate is valid, even if that is not the intention of this standard. I sort of miss a discussion on this in the security considerations section. But that is nothing that should prevent this document from being accepted. From nobody Thu May 30 06:38: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 5265B12014F; Thu, 30 May 2019 06:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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_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=Acv8/9sO; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=CdNW4kmZ 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 8LwV_ktEs3Ff; Thu, 30 May 2019 06:38:14 -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 3E642120113; Thu, 30 May 2019 06:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14377; q=dns/txt; s=iport; t=1559223494; x=1560433094; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oYbcG8Xnt4d0ODh0dbS2GWP0dcDJtaqHxpOQBfdMBPk=; b=Acv8/9sOLB2LHhNRoSRO8/hcuPHA9OlOycwGH3mwMD69IMaaDQqP4ZqO WZ2aCGLM0fmlNFKrlurhfR5D/XH5EMkRM9jNh1YZ6w/is1+GHFrozPwGN FDrSYk24u6Wxw6MLSolT1qNaJNZDAFrmMd4YxOnCZbh8eUUdN5F+jLXh6 U=; IronPort-PHdr: =?us-ascii?q?9a23=3AKn6dOxS7u5fLEe+BJ9Ekum7pC9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESUDNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOi83AM1ESHdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAABq3O9c/51dJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZYE+JCwDaVUgBAsoCodRA45ugld+ljCCUgNUCQEBAQwBARg?= =?us-ascii?q?NCAIBAYRAAoJ9IzgTAQMBAQQBAQIBBG0cDIVKAQEBBAEBEBUTBgEBKQMLAQs?= =?us-ascii?q?EAgEIEQQBAR8QJwsdCAIEAQ0FCBMHgwGBagMdAQ6fDwKBOIhfgW0zgnkBAQW?= =?us-ascii?q?BNgIOQYJ+GIIPAwaBNItWF4FAP4EQAUaCFwcuPoJhAQECAQGBKTYkgxaCJoN?= =?us-ascii?q?Ah3sSh06IDIxlZAkCgg2GO4RLiDiCIYZsiV+CJ4FFjHeHB48CAgQCBAUCDgE?= =?us-ascii?q?BBYFmIYFYcBU7gmyCDwkDFxSDOYUUhT9yAYEojDsBgSABAQ?= X-IronPort-AV: E=Sophos;i="5.60,531,1549929600"; d="scan'208";a="284035648" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 May 2019 13:38:13 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x4UDcDx0001692 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 May 2019 13:38:13 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 30 May 2019 08:38:11 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 30 May 2019 09:38:10 -0400 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 30 May 2019 08:38:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iMtTWoE+AH4kAzJdLLTlvgOuKX0J4Mbc4BShoIxn7HM=; b=CdNW4kmZIKXldmtmJqdfCJ3KMGj+c5zjlp6y/7GnLK0LSr63s3HmVJbiyRpBzYmMrFxhfyCeBZWO9DHXz2skMT45y2a5shpGKbwU06Medl4CDerRCJGHNbAi99JVPhxfg6785xxxOc17oTLGs8OcwRNrr5T8gz3W6ZfkTtk8ycQ= Received: from DM5PR11MB2027.namprd11.prod.outlook.com (10.168.103.22) by DM5PR11MB1660.namprd11.prod.outlook.com (10.172.34.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.15; Thu, 30 May 2019 13:38:08 +0000 Received: from DM5PR11MB2027.namprd11.prod.outlook.com ([fe80::1487:6a62:8e05:d2c4]) by DM5PR11MB2027.namprd11.prod.outlook.com ([fe80::1487:6a62:8e05:d2c4%2]) with mapi id 15.20.1922.021; Thu, 30 May 2019 13:38:08 +0000 From: "Ketan Talaulikar (ketant)" To: Paul Wouters , "secdir@ietf.org" CC: "idr@ietf.org" , "ietf@ietf.org" , "draft-ietf-idr-bgp-ls-segment-routing-ext.all@ietf.org" , Susan Hares Thread-Topic: [Idr] Secdir last call review of draft-ietf-idr-bgp-ls-segment-routing-ext-14 Thread-Index: AQHVEXnID/F1JdXu40uSXZ+c0XRCoKaDW3vQ Date: Thu, 30 May 2019 13:38:07 +0000 Message-ID: References: <155862420199.17104.3515279447343748635@ietfa.amsl.com> In-Reply-To: <155862420199.17104.3515279447343748635@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ketant@cisco.com; x-originating-ip: [72.163.220.17] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8fd508cb-c2b0-4fbe-9a1e-08d6e5040d15 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DM5PR11MB1660; x-ms-traffictypediagnostic: DM5PR11MB1660: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00531FAC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(376002)(346002)(39860400002)(396003)(199004)(189003)(13464003)(68736007)(110136005)(33656002)(6246003)(305945005)(81166006)(478600001)(229853002)(26005)(53936002)(66066001)(6506007)(74316002)(14444005)(76116006)(476003)(30864003)(446003)(81156014)(99286004)(486006)(11346002)(53546011)(5660300002)(8936002)(186003)(76176011)(73956011)(66476007)(8676002)(66946007)(7696005)(6436002)(64756008)(316002)(54906003)(966005)(6306002)(55016002)(102836004)(4326008)(256004)(66446008)(2501003)(52536014)(71190400001)(14454004)(25786009)(71200400001)(86362001)(6116002)(9686003)(7736002)(3846002)(2906002)(66556008); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1660; H:DM5PR11MB2027.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: U9RDuuneBckdddOOcYqFLcKGpC14kExPatlIE5w+n55nc7RgUstywBtvACby0AUiNpew6j/vpXiIYfBfROhPv4D7C3J8cvKDrlA5SRZi79In1mIJKRHBDBIaK72lfno4OAaFE1q8RtvBa5wM1/n52O3VoODohFUYFvggHrhkcCNTEY37c4z+1kj4uimdRrHjaV7Dzipjw5VSerlkexrriIqSQ0Jjvc5jX/2DC5N1N+wN4jYRtSM5t3nn5y/avkSRs1m38Y6d0jiFxvHSDt+YUHStAwdc4OqQJqojPGtfr89iHwvONfogHMFeAIdlo6w2BKHdiha6sleZQLLna6bZs48HszV9dIVXjEfJl56MKvwnSZtzoOLffgBmAGYdjiSFcsjxUU4jxPj0M+mPNFrqboxYYEP5ZUk96QrY613g9dM= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8fd508cb-c2b0-4fbe-9a1e-08d6e5040d15 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 May 2019 13:38:08.0212 (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-CrossTenant-userprincipalname: ketant@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1660 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [secdir] [Idr] Secdir last call review of draft-ietf-idr-bgp-ls-segment-routing-ext-14 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, 30 May 2019 13:38:17 -0000 Hi Paul, Thanks for your review and apologies for the delay in getting back to you o= n this. I've just posted v15 of the draft to address your comments below. https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing= -ext-15 Please also check inline below for more detailed response to all your comme= nts. -----Original Message----- From: Idr On Behalf Of Paul Wouters via Datatracker Sent: 23 May 2019 20:40 To: secdir@ietf.org Cc: idr@ietf.org; ietf@ietf.org; draft-ietf-idr-bgp-ls-segment-routing-ext.= all@ietf.org Subject: [Idr] Secdir last call review of draft-ietf-idr-bgp-ls-segment-rou= ting-ext-14 Reviewer: Paul Wouters Review result: Has Issues Reviewer: Paul Wouters Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These 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. Note: I'm not a segment routing or BGP expert, so I might have misunderstoo= d some things. As far as I can understand the Security Considerations, it s= eems that it is adequately pointing to other documents and mentions, with s= olutions, new concerns raised by implememting this document. I do have a number of comments and suggested improvements for the tables an= d figures layout, and some questions about IANA registries. See below for details. Paul Section 2.1 Can the IANA registry be referenced here so the reader can easilly go to se= e the entire list of Node Attribute TLVs ? [KT] This is the entire list of new Node Attribute TLVs introduced in this = document. There is only a single IANA registry for all TLVs for BGP-LS - ba= sed on your further comments, I've updated the BGP-LS Registry name in the = IANA section 3. I don't think it is required to put IANA references all ove= r the document. FYI - the registry is at https://www.iana.org/assignments/b= gp-ls-parameters/bgp-ls-parameters.xhtml=20 Section 2.1.1 I personally find Figures to have more readable with less -+-+-+-+ symbols = eg to change Figure 2 to: 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 +-------------------------------+-------------------------------+ | Type | Length | +-------------------------------+-------------------------------+ ~ SID/Label (variable) ~ +---------------------------------------------------------------+ [KT] When TLVs are drawn with a reference to a 32 bit scheme, I've always s= een the representation being made as is done in this document (I guess we s= ee the bits better when we do so!). E.g. BGP base spec RFC4271 or BGP-LS ba= se RFC7752 and tons of other RFCs. Note that since the SID/Label is a variable length, I used the "~" symbol as in common to donate that. And important in this case too, as I wa= s thinking it was a fixed size but reading the description found out it was= either 3 or 4 bytes. I see the document uses // for this elsewhere, which = is also okay. [KT] Agree. I've fixed the pictures to use // consistently in the figures f= or variable sizes. Type: 1161 I would write: Type: set to 1161 denoting a SID/Label Node Attribute [KT] This section describes the SID/Label Node TLV and so this is implied. = It goes similar for all other TLVs as well. Length: Either 3 or 4 depending whether [...] I find this language confusing. It suggests the Length field can be of size= 3 or 4, instead of saying the Length field value can be 3 or 4. [KT] The size of type and length fields are fixed in the protocol. It is al= so shown in the pictorial representation. What is being specified is the va= lue in both the cases so there should be no confusion for anyone familiar w= ith BGP/BGP-LS. then the 20 rightmost bits represent a label Should it be specified what to do with the 4 leftmost bits? Are they reserv= ed? used for something else ? [KT] Since the MPLS label is of size 20 bits, this field cannot have a valu= e greater than one represented by those 20 bits. The leftmost 4 bits would = therefore be 0. I have updated the text now to clarify this.=20 Section 2.1.2 I find the split Range Size vs / SID/Label confusing. The table is supposed= to give me an idea of the byte stream, but by being split it two it doesn'= t do that well. How about this: 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 +-------------------------------+-------------------------------+ | Type | Length | +---------------+---------------+-------------------------------+ | Flags | Reserved | Range Size, or | +---------------+---------------+ | ~ SID/Label sub-TLV ~ +---------------------------------------------------------------+ [KT] Please check the explanation in text below the figure. It is split int= o two because there can be one or more sets of "Range + SID/Label sub-TLV".= I have updated the figure to illustrate this better. I find this bit a little misleading in our way of writing it: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Range Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // SID/Label sub-TLV (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Because I don't think Range Size is really 20 bits and the next 4 bits can = be used for another payload. I assume those unspecified 4 bits are reserved= and set to 0? [KT] Range size is 3 octets - i.e. 24 bits. After that is the SID/Label sub= -TLV as described in sec 2.1.1. Type: 1034 I would write: Type: set to 1034 denoting an SR Capabilities Node Attribute Length: Variable. Minimum length is 12. Again, it find this confusing. The length field itself is not variable leng= th and has no minimum length of 12. I would write: Length: two octects in network order, specifying the length of the Range Size or SID/Label sub-TLV [KT] I've clarified in a previous comment and also updated the figure in th= e document to illustrate this better. Reserved: 1 octet that SHOULD be set to 0 and MUST be ignored on receipt. Why is that SHOULD not a MUST? [KT] Because it is ignored by the receiver. Also see further below for a si= milar comment. One or more entries, each of which have the following format: Is this really "one or more entries"? The table above does not show that at= all. Can we only have more entries of the same capabilities or can they be= mixed (eg one range size and two SID/Labels ??) If there is more than one = entry, how would one know whether these are RAnge Sizes or SID/Labels? If there is only one, then the Length denotes that implicitely. Since the SID/Label sub-TLV is used to indicate the first label of the SRGB range, only label encoding is valid under the SR Capabilities TLV. Does this mean the above "one or more entries" is actually restricted and m= eans "one or more rang sizes, followed by 0 or 1 SID/Labels" ? The ambiguity perceived means I can not fully deducate the field contents a= s it is currently specified. [KT] I hope the updated figure and my previous comment will help clarify.=20 Section 2.1.3 Similar remarks to the sections above here regarding the field descriptions= . I would enclose Algorithm 1, since 1 is the minimum and close the table, si= nce our content description does end (based on the Length field) 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 +-------------------------------+-------------------------------+ | Type | Length | +---------------+---------------+---------------+---------------+ | Algorithm 1 | Algorithm... ~ Algorithm N ~ | +---------------+---- | ~ ~ +---------------------------------------------------------------+ [KT] I've updated the figure and the description. I hope it clarifies. Section 2.1.4 See my similar comments above. Additionally, one Range Size and SID label s= hould be added to the diagram unconditionally, as the minimum is one, and t= hen the block follows of optional additional blocks of range size plus SID/= Label. [KT] Updated the figure as in previous section. Section 2.1.5 See similar comments above. [KT] I do not understand this comment but please check the updated draft an= d if this is addressed. Section 2.2 These TLVs should only be added to [...] Should that "should" be a SHOULD (or MUST?) [KT] It was not intended to be normative. Section 2.2.1 See similar comments above that apply to this table and values. Here it is = even more important because Length appears even more variable because Flags= is described as a static "one octet". And then "weight" isn't given an octet size but the following Reserved field is. [KT] I've updated the weight field to indicate it's 1 octet size. Should the SHOULD in the reserved field description be a MUST ? Especially for reserved fields, I see no reason why it is not a MUST. If th= is is left unchecked by an implementation and possibly filled with bogus da= ta, while that will not break anything NOW, as the document also states "MU= ST ignore", but once any of these fields get defined in the future, it woul= d break. So it is better to dictate now to not leave it with potential garb= age values. [KT] This is something that has been used for reserved field and reserved b= its in many IETF RFCs/drafts that I've known. If an implementation is not f= ollowing the SHOULD and instead filing bogus data then it better have a goo= d reason to do so. Perhaps it might be using that reserved field for some p= urpose before it is officially allocated by IANA/IETF action? [The Following sections all have the same characteristics as the above ones= , so I won't mention these further in the review, but I think these should= be fixed similarly.] Section 2.2.3 This table seems to extend an existing table in what I hope is some kind of= IANA registry? Can that be referenced here? If there is no IANA registry o= f these, and this seems to extend a list of entries from RFC 7752 and RFC 8= 571, I would suggest this document creates that new IANA registry and popul= ates it with all those values. [KT] Please refer to my previous comment on IANA registry and the updated t= ext for IANA section in the new version. Also https://www.iana.org/assignme= nts/bgp-ls-parameters/bgp-ls-parameters.xhtml=20 Section 2.3 Similar here, should this be a new IANA Registry? [KT] Sec 3 explains the IANA aspects - there is no new registry being intro= duced. Section 2.3.4 If the Prefix NLRI is not considered a "normal routing prefix", what is it = considered as? What implications does that have? [KT] It is considered as a prefix used for the advertisement of the mapping= range. I've updated the text to clarify this. need to be interpreted accordingly Is that "need to" not a MUST ? or perhaps rephrase this as: The Flags field of this TLV are interpreted accordingly to the respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. =20 [KT] Ack - will rephrase as suggested. Section 3 We normally don't say early code points were assigned. We just say what we request(ed) from IANA. Also, can the registies named be linked to IANA? [KT] These code points were actually assigned via early allocation process = and we've been asked to explicitly clarify the status of assignments as the= document progresses through the WG and IESG. I am not sure what you mean b= y "linked to IANA". Perhaps it was because we did not say that this is from= the BGP-LS Parameter's registry? If so, I've updated the text to indicate = this. "should be left empty" -> "is left empty"=20 [KT] Since this is the request for IANA action, the language is so. The table in Section 3.1 seems to extend an existing table/registry. Can it= be named and linked so the reader can jump the the IANA registry ? [KT] It is named and I've also updated to specifically indicate the BGP-LS = Parameter's top level registry. I've not seen URLs used thus, if that is wh= at you meant by "linked". NITS: Abstract: This draft -> This document [KT] Ack - fixed. Introduction: This sentence seems malformed: A segment can represent any instruction, topological or service-based. [KT] Fixed. Replace "," with ";". or global within a domain. -> or a global semantic within a domain. [KT] Fixed. Within IGP topologies an SR path -> Within IGP topologies, an SR path [KT] Fixed. Use of "segement" vs "Segment" in the Introduction is inconsistent [KT] Fixed. Figure 1 describes -> Figure 1 denotes [KT] Fixed. then can -> can [KT] Fixed. Section 2.1.1 as a label or an index/SID. -> as a label or as an index/SID [KT] fixed. Section 2.2.1 The Protocol-ID of the BGP-LS Link NLRI should be used to determine the underlying protocol specification for parsing these fields. I would change the "should be" to an "is", as there is no chocie here. That= is how it is. Similar in other sections, such as 2.3.1 [KT] Fixed. Section 2.3.4 is considered as a normal routing -> is considered a normal routing [KT] Fixed. Thanks, Ketan _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Thu May 30 11:30: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 B27241202A9; Thu, 30 May 2019 11:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.425 X-Spam-Level: X-Spam-Status: No, score=-7.425 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_HI=-5, RCVD_IN_MSPIKE_H2=-0.415, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.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 5Sf-UGAVzqfR; Thu, 30 May 2019 11:30:13 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (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 409751202A5; Thu, 30 May 2019 11:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=NewEg7y4m7wxlyEbNmIiaAx4tGw92unt3zPiAoebsOs=; b=DxcxGC2zxGLdXGE55RFs0dJ4Cr JiybSESxB3tpXmvTMLIVos3v5mL0hQGZqKvi5AjxbePqjfB6wAbLNHAUr5eKt2R2n9ymCp5A1B5w3 AjFj5NTBIWQJV54CAz7B2W5XMcbmy8P4x71HTpIc7dNJXIErxd1eVtXB+AMe7GJBALIQ=; Received: ; Thu, 30 May 2019 11:30:10 -0700 To: Stefan Santesson , secdir@ietf.org Cc: spasm@ietf.org, ietf@ietf.org, draft-ietf-lamps-rfc6844bis.all@ietf.org References: <155917666691.9144.10382733252232760132@ietfa.amsl.com> From: Jacob Hoffman-Andrews Message-ID: <3f60c58a-7923-d5da-e500-052588a294fb@eff.org> Date: Thu, 30 May 2019 11:30:10 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <155917666691.9144.10382733252232760132@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lamps-rfc6844bis-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: Thu, 30 May 2019 18:30:15 -0000 On 5/29/19 5:37 PM, Stefan Santesson via Datatracker wrote: > A common aspect of standards documents is that they only are relevant to those > who declare compliance to the standard. This document is different as it relies > on that all parties (CA:s) are aware of this standard and performs the > stipulated checks. In practice this has been stipulated for public CAs by the CA/Browser Forum Baseline Requirements since September 2017: https://cabforum.org/2017/03/08/ballot-187-make-caa-checking-mandatory/. In other words, the CP for this particular community of trust incorporates RFC 6844, making it mandatory. The intent is that once RFC6844bis is standardized, CA/Browser Forum will have a followup ballot incorporating it. From nobody Thu May 30 11:40: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 960C812018E for ; Thu, 30 May 2019 11:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com header.b=AEZcuOhr; dkim=pass (1024-bit key) header.d=digicert.com header.b=QYRdKVJd 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 olCb5OEIWWGm for ; Thu, 30 May 2019 11:40:36 -0700 (PDT) Received: from us-smtp-delivery-173.mimecast.com (us-smtp-delivery-173.mimecast.com [216.205.24.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B10651200FD for ; Thu, 30 May 2019 11:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1559241635; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:openpgp:autocrypt; bh=qn399naaTJFl6fhVqLb/IgosntAlBX9A8MH2QVwTi9w=; b=AEZcuOhr8rOIoW6px8Fk9DTwQBBoG1dXeDocWCPg1qpPAJN2tq95zu6C5RbqoaCXNHNgG6 5PULugZ3kHwqo8wALm4ucHCrqElHS1PpKZz5A9ZGZ2OLj3l9M3+UETtqDPablskYCZBcST SpjBBmP6680nDXN3vEIXr8Uj5PKOEsc= Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03lp2052.outbound.protection.outlook.com [104.47.40.52]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-239-lSxmm8jYP66r1u_oz-N1GA-1; Thu, 30 May 2019 14:40:34 -0400 X-MC-Unique: lSxmm8jYP66r1u_oz-N1GA-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qn399naaTJFl6fhVqLb/IgosntAlBX9A8MH2QVwTi9w=; b=QYRdKVJdK1zs6ADQDA233aNLkdP1UsBxMU8OnHp2TCpf3DQ8fbkaT8solixmWo8jQn8+p5lKDJU+MV5LC/HEuweaKwcXpFm+VigqpC8XUQAvo9hxAZyIc94deWhPgP6VC/jvj92YxdRehctbHGIBv4tsmZaajdjMDlVPZ31qt6o= Received: from MWHPR14MB1533.namprd14.prod.outlook.com (10.173.233.145) by MWHPR14MB1229.namprd14.prod.outlook.com (10.173.101.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.17; Thu, 30 May 2019 18:40:30 +0000 Received: from MWHPR14MB1533.namprd14.prod.outlook.com ([fe80::b9aa:dc2e:2670:8d4f]) by MWHPR14MB1533.namprd14.prod.outlook.com ([fe80::b9aa:dc2e:2670:8d4f%7]) with mapi id 15.20.1922.021; Thu, 30 May 2019 18:40:30 +0000 From: Tim Hollebeek To: Jacob Hoffman-Andrews , Stefan Santesson , "secdir@ietf.org" CC: "spasm@ietf.org" , "ietf@ietf.org" , "draft-ietf-lamps-rfc6844bis.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-lamps-rfc6844bis-06 Thread-Index: AQHVFn/sWw2w7u4bbk6vxJcWe04S76aD/m0AgAACRmA= Date: Thu, 30 May 2019 18:40:30 +0000 Message-ID: References: <155917666691.9144.10382733252232760132@ietfa.amsl.com> <3f60c58a-7923-d5da-e500-052588a294fb@eff.org> In-Reply-To: <3f60c58a-7923-d5da-e500-052588a294fb@eff.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tim.hollebeek@digicert.com; x-originating-ip: [98.111.253.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 010612b5-0b23-4ba2-aa68-08d6e52e4af4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:MWHPR14MB1229; x-ms-traffictypediagnostic: MWHPR14MB1229: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2399; x-forefront-prvs: 00531FAC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(396003)(346002)(376002)(136003)(13464003)(199004)(189003)(478600001)(4326008)(55016002)(66066001)(66446008)(74316002)(966005)(102836004)(6246003)(6306002)(186003)(52536014)(229853002)(26005)(25786009)(54906003)(110136005)(66476007)(66616009)(53936002)(64756008)(7736002)(71190400001)(71200400001)(33656002)(66556008)(6436002)(316002)(2501003)(14454004)(305945005)(86362001)(256004)(9686003)(3846002)(73956011)(6116002)(81156014)(81166006)(66946007)(76116006)(2906002)(11346002)(44832011)(476003)(76176011)(7696005)(68736007)(99936001)(8936002)(8676002)(6506007)(53546011)(99286004)(5660300002)(66574012)(486006)(446003)(19400905002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1229; H:MWHPR14MB1533.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: BDy0AtKRXDvgbazWhYvkovbXLEvqZPz7llhc/phKz+AwknuYdo5Jz86lmwt036F8AOYrVVrS+CQg6gtTYbvnTyhG3xgshT9wofRmvYVcQD3WxPgnm7wJTvezwbMboUw/NnFzM6iXwJjYzzSIZxwNP7Bx97tczGPpkzKp0mU87ejeJFZwmQKr7bU9eVLEzJDW1rVSqm5jidG7Mbq8eXNdGvDLyu8PfD6czNf4oEIUr0+u6RZMALJ/lcMDRDYgUvTY9zWTocjxPc4o0SHsMF6umQp69sOFO7eGr/lgQIzN/oQNMfznKVY3BMbpkBf2OC+y4BBuUhp9JzTcBK47e9jNHIf6slVaBC6t+cpfocG/tdmXiYV+N9ush/0FOL3UAw58RyQzX1SWiCkVhu/rReltOCMvidG1kX7e2ACgUS8llJU= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0051_01D516F5.9084D280" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 010612b5-0b23-4ba2-aa68-08d6e52e4af4 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 May 2019 18:40:30.5786 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tim.hollebeek@digicert.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1229 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lamps-rfc6844bis-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: Thu, 30 May 2019 18:40:40 -0000 ------=_NextPart_000_0051_01D516F5.9084D280 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Just to make it official, I'm the chair of the Validation Subcommittee of the Server Certificate Working Group of the CA/Browser Forum, and I intend to submit a ballot to make RFC 6844bis mandatory in the event it is published as an IETF RFC. -Tim > -----Original Message----- > From: Jacob Hoffman-Andrews > Sent: Thursday, May 30, 2019 2:30 PM > To: Stefan Santesson ; secdir@ietf.org > Cc: spasm@ietf.org; ietf@ietf.org; draft-ietf-lamps-rfc6844bis.all@ietf.org > Subject: Re: Secdir last call review of draft-ietf-lamps-rfc6844bis-06 > > On 5/29/19 5:37 PM, Stefan Santesson via Datatracker wrote: > > A common aspect of standards documents is that they only are relevant > > to those who declare compliance to the standard. This document is > > different as it relies on that all parties (CA:s) are aware of this > > standard and performs the stipulated checks. > > In practice this has been stipulated for public CAs by the CA/Browser Forum > Baseline Requirements since September 2017: > https://cabforum.org/2017/03/08/ballot-187-make-caa-checking-mandatory/. > > In other words, the CP for this particular community of trust incorporates > RFC > 6844, making it mandatory. The intent is that once RFC6844bis is > standardized, > CA/Browser Forum will have a followup ballot incorporating it. ------=_NextPart_000_0051_01D516F5.9084D280 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTkwNTMwMTg0MDAyWjAvBgkqhkiG9w0BCQQxIgQgdpS9rtAhf/m7iD9R+WZCFuEp1XlC Nja+4NGnDUXhwLkwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAHL3mfkux/fl8/gAHqYE+L+8bA+/LvbynzFJJlkTyWHNVXX5m6hAYOOAJOWZWxwEmsGXPmgC x2PC/4gsKXYisHkk/HZ84GWWlVcNBVmkvD0isTBzLefwrGlg8tZn64gg67W7Tj7O8uLRJ7e6wSUj PRLUg9zALfmQ2HtLnArHvtPpzr8l6e/BH5hxLiCR35CxrcrMqSeOpIS+NcGM3lvPmhRgD6t7Rp6p zhKX9qbcSw59STNfK05QP537/m0aMoWYWCNdXr1JSqYeI1vpJRd7TfTyIR8HkqIMHfgsm9SPsLcp ON9e2fr14tB8HZYBRe2fxklIfGonaQBQHO6YLEVgsykAAAAAAAA= ------=_NextPart_000_0051_01D516F5.9084D280-- From nobody Fri May 31 17:41:39 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 426551200F8 for ; Fri, 31 May 2019 17:41:38 -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.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <155934969826.28155.1810846186601700861.idtracker@ietfa.amsl.com> Date: Fri, 31 May 2019 17:41:38 -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: Sat, 01 Jun 2019 00:41:38 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-06-13 Reviewer LC end Draft Samuel Weiler 2019-05-13 draft-ietf-grow-wkc-behavior-05 Last calls: Reviewer LC end Draft Nancy Cam-Winget 2019-06-04 draft-ietf-sipcore-rejected-08 Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-29 Roman Danyliw 2019-06-04 draft-ietf-rtgwg-enterprise-pa-multihoming-08 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Daniel Franke 2019-03-18 draft-ietf-sidrops-https-tal-08 Daniel Gillmor 2018-03-19 draft-gutmann-scep-13 Steve Hanna 2019-06-12 draft-ietf-acme-ip-06 Dan Harkins 2019-06-12 draft-ietf-acme-ip-06 Christian Huitema R2019-06-04 draft-ietf-anima-bootstrapping-keyinfra-20 Catherine Meadows 2019-04-12 draft-ietf-mmusic-rfc4566bis-35 Matthew Miller 2019-04-08 draft-ietf-core-multipart-ct-03 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-08 Hilarie Orman R2019-04-10 draft-ietf-acme-caa-08 Tim Polk 2019-04-17 draft-ietf-isis-segment-routing-extensions-25 Carl Wallace R2019-05-13 draft-ietf-tsvwg-tinymt32-03 David Waltermire 2019-02-15 draft-ietf-rtcweb-ip-handling-11 Klaas Wierenga 2019-02-26 draft-ietf-mpls-sr-over-ip-06 Christopher Wood 2019-05-28 draft-ietf-tram-turnbis-25 Taylor Yu 2019-02-15 draft-ietf-rtcweb-security-arch-18 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-12 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Kathleen Moriarty 2019-04-08 draft-ietf-bmwg-ngfw-performance-00 Next in the reviewer rotation: Russ Housley Christian Huitema Leif Johansson Benjamin Kaduk Charlie Kaufman Scott Kelly Stephen Kent Tero Kivinen Watson Ladd Ben Laurie From nobody Fri May 31 19:45:28 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 95D7F1200F8 for ; Fri, 31 May 2019 19:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.366 X-Spam-Level: **** X-Spam-Status: No, score=4.366 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RCVD_IN_PBL=3.335, RCVD_IN_SORBS_DUL=0.001, RDNS_NONE=0.793, SPF_FAIL=0.001, SPF_HELO_NONE=0.001, TO_EQ_FM_DOM_SPF_FAIL=0.053, TO_EQ_FM_SPF_FAIL=0.001, UNPARSEABLE_RELAY=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 r9Z3VSc4NlZS for ; Fri, 31 May 2019 19:45:24 -0700 (PDT) Received: from hopecctv.com (unknown [60.184.207.29]) by ietfa.amsl.com (Postfix) with SMTP id 381351200B3 for ; Fri, 31 May 2019 19:45:22 -0700 (PDT) Received: from hopecctv.com (unknown (77.103.177.183]) by hopecctv.com with SMTP id 1f1ca3c6-34f9-406b-b62e-d7d0a034d9bf; for ;Sat, 01 Jun 2019 10:45:10 +08:00 Message-ID: <689c991b5cb689ba2fd1549b34fd4b4f@ietf.org> From: "=?utf-8?B?5ZSQ6JW+?=" To: Date: Sat, 01 Jun 2019 10:45:10 +0800 MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [secdir] =?utf-8?b?5L2b5oCd5L2z5aSn5ZCJ5aSn5Yip54+g562W5oaOMTg4?= =?utf-8?b?44GI6K+i5LuZ5aWz5bCC5ZGY5LyB5ailMTk1MzcyNTM3MeWcsOWdgDYwNDk4?= =?utf-8?b?MWPDs9C8?= 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, 01 Jun 2019 02:45:26 -0000

=E6=B3=A8=E5=8D=95=E5=8F=B7<=E5=85=AB=E5=8D=81=E5=B2=81=E6=97=A0=E5= =84=BF=E8=AF=B4=E4=B8=8D=E5=87=BA=E8=80=81=E6=9D=A5=E8=8B=A6>=E7=A0= =81=E6=9C=AB<=E5=8F=91=E8=A8=80=E9=A1=BB=E5=8F=A5=E5=8F= =A5=E6=9C=89=E7=9D=80=E8=90=BD=E6=96=B9=E5=A5=BD=E3=80=82=E4=BA=BA=E4=BA=8E= =E5=BF=99=E5=A4=84=EF=BC=8C=E8=A8=80=E6=88=96=E5=A6=84=E5=8F=91=EF=BC=8C=E6= =89=80=E4=BB=A5=E6=9C=89=E6=82=94=E3=80=82=E2=80=94=E2=80=94=E8=96=9B=E7=91= =84=EF=BC=88=E6=98=8E=EF=BC=89=E3=80=8A=E8=AF=BB=E4=B9=A6=E5=BD=95=E3=80=8B= >=E4=B8=89=E4=BD=8D<=E4=BB=8E=E5=B0=8F=E5=B7=AE=E4=B8=80=E5= =B2=81=EF=BC=8C=E5=88=B0=E8=80=81=E4=B8=8D=E5=90=8C=E5=B9=B4=E3=80=82>=E5=87=BA=E7=8E=B0<=E4=B8=A4=E4=B8=AA=E5=93=91=E5=B7=B4=E5=90= =B5=E5=98=B4=E4=B8=8D=E7=9F=A5=E8=B0=81=E6=98=AF=E9=9D=9E>8<=E5=90=8D=E8=AA=89=E6=98=AF=E8=A1=A8=E7=8E= =B0=E5=9C=A8=E5=A4=96=E7=9A=84=E8=89=AF=E5=BF=83=EF=BC=9B=E8=89=AF=E5=BF=83= =E6=98=AF=E9=9A=90=E8=97=8F=E5=9C=A8=E5=86=85=E7=9A=84=E5=90=8D=E8=AA=89=E3= =80=82>88=E4=B8=89<=E5=89=8D=E5=BE=80=E4=BC=9F=E5=A4=A7=E7= =9A=84=E9=A2=A0=E5=B3=B0=E4=B9=8B=E8=B7=AF=EF=BC=8C=E5=BF=85=E5=AE=9A=E5=B4= =8E=E5=B2=96=E3=80=82>=E4=B8=AA=E6=95=B0=E5=AD=97<=E5=86=8D=E4=B8=89=E9=A1=BB=E9=87=8D=E4= =BA=8B=EF=BC=8C=E7=AC=AC=E4=B8=80=E8=8E=AB=E6=AC=BA=E5=BF=83=E3=80=82>=EF=BC=8C<=E4=BD=BF=E4=BB=96=E7=9A=84=E9=A3=8E=E6=A0= =BC=E5=88=B0=E5=A4=84=E5=8F=97=E4=BA=BA=E4=BB=AC=E5=B4=87=E6=8B=9C=E3=80=82= >=E5=8D=B3<=E4=BD=A0=E4=BF=A9=E4=BA=92=E7=9B=B8=E6=89= =BE=E7=9D=80=EF=BC=8C=E8=80=8C=E6=88=91=E5=A4=B1=E6=8E=89=E4=B8=A4=E4=B8=AA= =EF=BC=8C>=E5=8F=AF=E8=8E=B7<=E5=A4=A7=E5=A4=84=E7=9D=80=E7=9C=BC=EF=BC= =8C=E5=B0=8F=E5=A4=84=E7=9D=80=E6=89=8B=E3=80=82>=E5=BE=97=E6=AD=A4= =E7=AC=94<=E4=B8=80=E4=BA=9B=E9=99=88=E6=97=A7=E7= =9A=84=E3=80=81=E4=B8=8D=E7=BB=93=E5=90=88=E5=AE=9E=E9=99=85=E7=9A=84=E4=B8= =9C=E8=A5=BF=EF=BC=8C=E4=B8=8D=E7=AE=A1=E9=82=A3=E4=BA=9B=E4=B8=9C=E8=A5=BF= =E6=98=AF=E6=B4=8B=E6=A1=86=E6=A1=86=EF=BC=8C=E8=BF=98=E6=98=AF=E5=9C=9F=E6= =A1=86=E6=A1=86=EF=BC=8C=E9=83=BD=E8=A6=81=E5=A4=A7=E5=8A=9B=E5=9C=B0=E6=8A= =8A=E5=AE=83=E4=BB=AC=E6=89=93=E7=A0=B4=EF=BC=8C=E5=A4=A7=E8=83=86=E5=9C=B0= =E5=88=9B=E9=80=A0=E6=96=B0=E7=9A=84=E6=96=B9=E6=B3=95=E3=80=81=E6=96=B0=E7= =9A=84=E7=90=86=E8=AE=BA=EF=BC=8C=E6=9D=A5=E8=A7=A3=E5=86=B3=E6=88=91=E4=BB= =AC=E7=9A=84=E9=97=AE=E9=A2=98=E3=80=82=E6=9D=8E=E5=9B=9B=E5=85=89>= =E6=B3=A8<=E4=BA=B2=E4=B8=8D=E8=BF=87=E7=88=B6=E6=AF= =8D=EF=BC=8C=E8=BF=91=E4=B8=8D=E8=BF=87=E5=A4=AB=E5=A6=BB=E3=80=82>= =E5=8D=95=E9=87=91=E9=A2=9D<=E4=BD=BF=E5=8F=A3=E4=B8=8D=E5=A6=82=E8=87= =AA=E8=B5=B0=EF=BC=8C=E6=B1=82=E4=BA=BA=E4=B8=8D=E7=9F=A5=E6=B1=82=E5=B7=B1= =E3=80=82>10=E5=80=8D<=E8=B4=AB=E5=9B=B0=E6=95=99=E4=BC=9A=E8=B4= =AB=E5=9B=B0=E8=80=85=E4=B8=80=E5=88=87=E3=80=82>=E8=B2=A1<=E6=83=B3=E3=80=81=E9=81=93=E5=BE=B7=E3= =80=81=E7=B2=BE=E7=A5=9E=E9=83=BD=E5=B4=87=E9=AB=98=E7=BE=8E=E5=A5=BD=E7=9A= =84=E4=B8=96=E7=95=8C=E3=80=82>=E9=92=85=E3=80=82<=E6=94=B6=E4=B8=8B=E8=BF=99=E4=BB=BD=E8= =8F=B2=E8=96=84=E4=BD=86=E7=94=B1=E8=A1=B7=E7=9A=84=E7=8C=AE=E7=A4=BC=EF=BC= =8C>=E5=A5=96=E9=87=91<=E5=B1=8B=E9=87=8C=E9=A3=8E=E7=AD=9D=E9=A3= =9E=E4=B8=8D=E9=AB=98>=E4=B8=8A<=E8=9E=B3=E8=87=82=E5=BD=93=E8=BD=A6=EF=BC= =9A=E4=B8=8D=E8=87=AA=E9=87=8F >=E9=99=90<=E7=94=9F=E6=B4=BB=E5=B0=B1=E5=83=8F=E6=B5= =B7=E6=B4=8B=EF=BC=8C=E5=8F=AA=E6=9C=89=E6=84=8F=E5=BF=97=E5=9D=9A=E5=BC=BA= =E7=9A=84=E4=BA=BA=EF=BC=8C=E6=89=8D=E8=83=BD=E5=88=B0=E8=BE=BE=E5=BD=BC=E5= =B2=B8>188<=E5=A4=A7=E8=B1=A1=E5=96=9D=E6=B0=B4=E6= =9C=89=E8=82=9A=E9=87=8F >8=E5=9C=9C=E3=80=82<=E8=A1=8C=E8=A1=8C=E4=BC=81=E4=BC=81=EF= =BC=8C=E9=A3=9F=E9=A5=AD=E5=87=A0=E5=91=B3 >