From nobody Thu Nov 1 07:12:49 2018 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 520D2126BED; Thu, 1 Nov 2018 07:12:47 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] 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, 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 UEFEC_t5fYQp; Thu, 1 Nov 2018 07:12:44 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 2B33C124D68; Thu, 1 Nov 2018 07:12:43 -0700 (PDT) X-AuditID: 1209190c-779ff70000001b9d-09-5bdb09d90a67 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 24.F0.07069.9D90BDB5; Thu, 1 Nov 2018 10:12:42 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id wA1ECejZ020979; Thu, 1 Nov 2018 10:12:40 -0400 Received: from kduck.kaduk.org (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 wA1ECYC2008718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 1 Nov 2018 10:12:38 -0400 Date: Thu, 1 Nov 2018 09:12:34 -0500 From: Benjamin Kaduk To: Richard Barnes Cc: radiaperlman@gmail.com, draft-ietf-perc-double.all@ietf.org, The IESG , secdir Message-ID: <20181101141234.GY45914@kduck.kaduk.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA01SbUgTYRznudu5Z8Oz83T4OBPxlBBpplm0DyUVCKMXSioqB9nlnrbpNu1u ioqBRmmaDNNCGwaJpqDmLHr9ENIISrMIKrJTe1GpHEl96J1p3Tl8+fb7/39vPC+QZBsoPbS7 3Fhw8Q4uTKtiNbokg6QZM6cHJcoovck1tgbPk8abbbOU8aJni/Fb+wfVVsp0zzuhNnV2/iFM zde9qr1krnazBTvspVhYl3VUa2v72qouHthWNlMnEVWgN7MeaCBiNqCm6gtUPdBClukj0GzV LTI0DAB0Z+odCA3jBKrzNFGKRcUko9Hhy0DBYTKuOveCVHA0k4CevH6/oCGZSuSpfhSm4Chm E+r45ZP3ENJy3feRAmXNMi0A9ZziFEwzkWjo0rQqZE1Fo/MzhCInmTjUPQ/rgRpqmBx0rUIR 6JgkdN/jVzcCxrvC613h9S57rwCyB8RbnBUGJ293iDjfIObzLhcWDBlpTrs7DVtKboCFK44N vwtGvuzwAwYCLpxO0UtmluJLxXKnH8RCgtPRP1/Kq4hjRZZyGy/a8oQSBxb9AEGSi6abn8sc beHLK7BQtEjFQRUXQzee7jCzjJV340KMi7GwyK6GkEN0EI6Z2UgBW3HZcbvDvUwTUKOEh8vh q+SnZ2mxmHeKdmuIHwaZ8Gz7vxYS3h6payVZlavIhfUxdIQSxyhSW4lrKU35RKhwsDIAYuTD RdHTiipc/mJLeQG5ipCrtOpRpcrNL1P6KnBgLnp9V7vvKsy2HKx+e+jZj6SCie1JwTOfhmzS wzoJTz2WqCN7+hpyX9X0DWdIbK2u7GNNPHHY1JU+FWcLNHS5esd8+zDI63+akNe+0bDzwRq1 OjAeN3kyBQyGJXbv/j0d6cuZZEaSCTSfkniif18L+Lvr81phf21WrzV7jlOJNj4jlRRE/j+X IbCnHwMAAA== Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-perc-double-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: Thu, 01 Nov 2018 14:12:47 -0000 Sorry for top posting; on phone. To ask the obviius question: what kind of hardware was your testing on? Did it include ARM CPUs/mobile devices? Anything without aesni? Thanks, Benjamin On Wed, Oct 31, 2018 at 03:29:58PM -0400, Richard Barnes wrote: > Hi Radia, > > Thanks for the review. Responses to the substantive comments inline. Will > take a look at the editorial ones in a bit. > > > On Wed, Oct 31, 2018 at 2:25 PM Radia Perlman > 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. > > > > This document specifies a syntax for doubly encrypting Secure Real Time > > Protocol (SRTP) packets so that the inner (media) content is encrypted with > > a key known only to the endpoints while some header content is encrypted > > with a separate key known by both the endpoints and network relay points > > called Media Distributors (with the outer encryption key (usually) changing > > on each hop). > > > > Below are details for consideration by the authors and other potential > > security reviewers. > > > > Substantive comments: > > > > Page 2 First paragraph: > > AES-GCM is the only specified cryptographic mode, but may not be the > > appropriate mode to use in distributing this content because there may be > > cases where we want to guarantee the integrity of the data end-to-end while > > allowing intermediaries to see the content. To support this case, it might > > make sense to allow the encryption and integrity protection keys to be > > separate so that an intermediary might be given the encryption key but not > > the integrity protection key. > > > > I think you mean we would give the intermediary the integrity key, not the > encryption key :) Since we want to enable the intermediary to modify > things, but not read the content. Even that wouldn't work, however, > because we do want the payload content to be integrity-protected > end-to-end. So you need to double up at least on the integrity check. > > > > > As noted in section 8, the inner payload ends up being encrypted twice > > (which is a substantial waste of resources). It might make more sense to > > include the inner encrypted payload as additional authenticated data in the > > outer invocation of AES-GCM to avoid that overhead. > > > > You're correct that the second encryption is duplicative, but in the > testing I've done, it is not a substantial waste of resources. As noted > above, you need two integrity checks anyway, so if we're not going to rely > on multiple primitives, that means multiple invocations of AES-GCM. And in > practice, an "integrity only" invocation of GCM, with everything in the > AAD, is not noticeably faster or slower than a normal invocation that also > encrypts. > > Another benefit of the current scheme is that having the outer transform be > identical to the base AES-GCM transform makes implementation easier for > intermediaries. They don't have to change their SRTP stacks, they just > have to adapt packet processing a little bit to add the OHB logic. > > So yes, in principle, it's a little duplicative, but in practice, the > duplication doesn't matter and the symmetry you get from it is advantageous. > > > > > Page 5 section 3.1 Key Derivation: > > This section specifies how the end-to-end and hop-by-hop keys must be > > derived from a single "master key". But this could only be true at the > > source node and would imply the intermediaries are not allowed to see the > > master key and the destination would not need to see the master key > > (because by the time the destination receives the message the key used for > > the outer encryption would be different. > > > > I would expect that the inner and outer keys would be negotiated > > independently and there would be no master key from which they are all > > derived. > > > > The key derivation here is inherent to SRTP; it would be a much more > significant change to SRTP processing logic to specify keys directly, > rather than adapting the KDF. > > The KDF adaptation is needed so that you can give the intermediary the HBH > half of the master key (using something like draft-ietf-perc-dtls-tunnel > ), and it'll > end up KDF'ing that to the right keys / IVs for the HBH transform. > > > > > Page 5 Section 4: > > If the set of RTP header fields is fixed and there is a fixed ordering to > > them, this is OK. But it wasn't obvious to me how to reflect in the OHB the > > difference between a new header field being added. And if fields are > > deleted (and therefore added to the OHB), it's not obvious in what order > > they should be reinserted by the ultimate recipient. > > > > The set of RTP header fields that get E2E protection is fixed, with a fixed > bit layout. There is a variable extension portion at the end, but that > receives no E2E protection, so it's not included in the OHB. > > > > > Page 6 Section 5: > > The second paragraph says the extensions are truncated when computing the > > inner checksum while the third paragraph says there is information in the > > OHB to reconstruct the original extensions to allow verification of the > > inner checksum. Either of these two techniques could be used, but the > > source and destinations must use the same one. Or is this specifying that > > some combination be used? > > > > Where are you seeing a claim that the OHB can help with extensions? It's > not impossible that it's there; earlier versions had this feature, but it > was removed to simplify things. > > If the text you have in mind is "OHB that expresses any changes made > between the inner and outer transforms", then I think it's just > approximation for brevity. The exact changes that the OHB can express are > defined elsewhere. > > > > > Page 9 paragraph 1 says: > > "A Media Distributor that decrypts, modifies, and re-encrypts packets > > in this way MUST use an independent key for each recipient, SHOULD > > use an independent salt for each recipient, ..." > > This represents substantial additional work for the Media Distributor. If > > it is important to use an independent key for each recipient, some > > justification should be noted. The likely one is that it prevents one > > recipient from undetectably modifying the copy of data sent to another > > recipient. This protection is not needed in all scenarios, and so perhaps > > should be optional. > > > > The hard line here is that whenever the plaintext changes (e.g., the PT > header gets sent to a different value), then a different (key, IV) pair > needs to get used. Otherwise you have nonce reuse. > > The requirement as written, however, is probably a bit too strong. It > presumes that each recipient is getting a different packet, which is very > common in conferencing scenarios, but not universal. I'll think about how > to clarify. > > Thanks, > --Richard > > > > > > > > Editorial Comments / Typos: > > > > Page 2 Second paragraph: > > There may be a word missing. What is "the double"? Also, throughout the > > document the protocol is referred to as "double", which if intended should > > probably be listed in section 2. > > > > Page 2 Last line: > > If multiple Media Distributors are allowed, hop by hop also refers to the > > path between two Media Distributors. > > > > Page 8 Section 5.2 bullet 2: > > -> > > > > Page 11 section 7.1 paragraph 1 > > I suspect there is a word or two missing. "it MUST be encrypted the packet > > in repair mode" sounds like something Yoda would say. > > > > Page 13 section 9 last paragraph says: > > "If the MD doesn't modify any header fields, > > then an MD that supports AES-GCM could be unused unmodified." > > This should say something like ...could use the same key and relay packets > > unmodified. > > > > From nobody Thu Nov 1 14:26:03 2018 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 A81E612D4EA for ; Thu, 1 Nov 2018 14:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCzI4qfZN4HE for ; Thu, 1 Nov 2018 14:25:55 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C32312D4E8 for ; Thu, 1 Nov 2018 14:25:52 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id j4-v6so19383828ljc.12 for ; Thu, 01 Nov 2018 14:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=26XH/dhywF1H/An51Jq4GTIaQc+rLwyRRqK1fypiD7Q=; b=nllnAwG7c5pRS7JoWPXgHWppTkLgpuZkjtgv0yh203LX7jUSR+MA4UA0L9aY8W7SOP RJymPeA6L2p45/xEPLwBeyTds1xWyXavHvj50RHkiXX1L96go9pFfOIuF5mBxBZ4zE13 3I9W+bfuOa99VKnAj/J4BQSbn98p1Nm1VtfSvgJElqEEz2Sv++0+x5McpLk9Qv9hjalY ligbK+VQ7+bd3SqpNgbAHoOIFvIscZK8GQ8bG4JedohRQ/pCZVT2G8b6v23vJowbjh7k qIIR5eiUZgPl1ReEuV7xQzZgiXA6gccqd9zAOVqWpw+f3+anPIv/JsCUBvXosTdmjuPg CCiA== 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=26XH/dhywF1H/An51Jq4GTIaQc+rLwyRRqK1fypiD7Q=; b=X5HTh4nCLzrJSOyBfQ1mDxOkFCgMqbMlN6Y2XhY3aH5axNskxkc21/5ZpFcPwqlgsG GZkDBfqPeBVdCp5RJfLmyao1xF1+tC2HVnSEJQ5wGqoth5G4knYwCmMg8+Yc2JwhuSIB oD+O0L0cK/y+7si0QZn+Yw9xQodFjuw1F8HFK72hUkX25Pf9lBRXA4ypsbjQfssFlTQ6 Qj5zPCTt9mHlz+SW6cadrgm1Sl6+iOQgoUCIXta+jBz7NLYpmHVwXWLZcbdIhUaoRoLF 13LoSAtm0tZNjMcsjfbW7FH2ThF/ESd4fYbCCAbfzmpQz5iPV9YKDfju8hwCUsa7UYbq 7+jg== X-Gm-Message-State: AGRZ1gL/T9r8AcR2iX1O3CgouIAA5GFFmExiwbxjKBjebE3IgI82KmHi o5QkyEgZ2A03ynyFbQOSYZqwRx10rMQt6Jc3pu3WGQ== X-Google-Smtp-Source: AJdET5cM+E9D4T0JEng5o9AEn+wUW5LSiw3+Jo9O56ziCemr4Vk83K7zGc3dpssCxXooZznufhcfyImqcuv0G8kaRng= X-Received: by 2002:a2e:1551:: with SMTP id 17-v6mr4681002ljv.68.1541107550713; Thu, 01 Nov 2018 14:25:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Thu, 1 Nov 2018 14:25:14 -0700 Message-ID: To: Radia Perlman Cc: Richard Barnes , draft-ietf-perc-double.all@ietf.org, IESG , secdir@ietf.org Content-Type: multipart/alternative; boundary="0000000000001f07920579a110a0" Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-perc-double-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: Thu, 01 Nov 2018 21:25:57 -0000 --0000000000001f07920579a110a0 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 31, 2018 at 6:45 PM Radia Perlman wrote: > > > On Wed, Oct 31, 2018 at 12:30 PM Richard Barnes wrote: > >> Hi Radia, >> >> Thanks for the review. Responses to the substantive comments inline. >> Will take a look at the editorial ones in a bit. >> >> >> On Wed, Oct 31, 2018 at 2:25 PM Radia Perlman >> 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. >>> >>> This document specifies a syntax for doubly encrypting Secure Real Time >>> Protocol (SRTP) packets so that the inner (media) content is encrypted with >>> a key known only to the endpoints while some header content is encrypted >>> with a separate key known by both the endpoints and network relay points >>> called Media Distributors (with the outer encryption key (usually) changing >>> on each hop). >>> >>> Below are details for consideration by the authors and other potential >>> security reviewers. >>> >>> Substantive comments: >>> >>> Page 2 First paragraph: >>> AES-GCM is the only specified cryptographic mode, but may not be the >>> appropriate mode to use in distributing this content because there may be >>> cases where we want to guarantee the integrity of the data end-to-end while >>> allowing intermediaries to see the content. To support this case, it might >>> make sense to allow the encryption and integrity protection keys to be >>> separate so that an intermediary might be given the encryption key but not >>> the integrity protection key. >>> >> >> I think you mean we would give the intermediary the integrity key, not >> the encryption key :) Since we want to enable the intermediary to modify >> things, but not read the content. >> > > > No, I really mean an intermediary might need the encryption key, so it can > read the contents, but not the integrity key, because it shouldn't modify > the contents. An example is an intermediary scanning for viruses. It > needs to see the contents, but is not going to modify the contents. That > way the integrity check really means that the source is vouching for the > authenticity of the content ("end-to-end integrity") > This is a common thing that people want to do, but it's not a primary design objective of PERC. I can't think of any cases of an intermediary needing to modify encrypted > contents, and therefore needing the integrity key but not the encryption > key. > You don't generally want to modify encrypted contents but rather have some of the contents (the meta-data) only encrypted HBH -Ekr > I'll look at the rest of the comments later.. > > Radia > > > > --0000000000001f07920579a110a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed= , Oct 31, 2018 at 6:45 PM Radia Perlman <radiaperlman@gmail.com> wrote:


On Wed, Oct 31, 2018 at 12:30 PM Richard Barnes <rlb@ipv.sx>= wrote:
Hi Radia,

Thanks for the review.=C2= =A0 Responses to the substantive comments inline.=C2=A0 Will take a look at= the editorial ones in a bit.


On Wed, Oct 31, 2018 at 2:25 PM Radia Per= lman <radiap= erlman@gmail.com> wrote:
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 These comments were written primarily for the benefit of = the security area directors.=C2=A0 Document editors and WG chairs should tr= eat these comments just like any other last call comments.

This document specifies a syntax for doubly encrypting Secure Real= Time Protocol (SRTP) packets so that the inner (media) content is encrypte= d with a key known only to the endpoints while some header content is encry= pted with a separate key known by both the endpoints and network relay poin= ts called Media Distributors (with the outer encryption key (usually) chang= ing on each hop).

Below are details for considerat= ion by the authors and other potential security reviewers.

Substantive comments:

Page 2 First paragr= aph:
AES-GCM is the only specified cryptographic mode, but may no= t be the appropriate mode to use in distributing this content because there= may be cases where we want to guarantee the integrity of the data end-to-e= nd while allowing intermediaries to see the content. To support this case, = it might make sense to allow the encryption and integrity protection keys t= o be separate so that an intermediary might be given the encryption key but= not the integrity protection key.

I think you mean we would give the intermediary the i= ntegrity key, not the encryption key :)=C2=A0 Since we want to enable the i= ntermediary to modify things, but not read the content.=C2=A0
<= /div>
=C2=A0

No, I re= ally mean an intermediary might need the encryption key, so it can read the= contents, but not the integrity key, because it shouldn't modify the c= ontents.=C2=A0 An example is an intermediary scanning for viruses.=C2=A0 It= needs to see the contents, but is not going to modify the contents. That w= ay the integrity check really means that the source is vouching for the aut= henticity of the content ("end-to-end integrity")

This is a common thing that people want = to do, but it's not a primary design objective of PERC.

<= /div>

I can't think of any cases of an intermediary = needing to modify encrypted contents, and therefore needing the integrity k= ey but not the encryption key.=C2=A0
You don't generally want to modify encrypted contents but r= ather have some of the contents (the meta-data) only encrypted HBH

-Ekr


I'll look= at the rest of the comments later..

Radia


=C2=A0
--0000000000001f07920579a110a0-- From nobody Thu Nov 1 15:00:14 2018 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 5E46712958B; Thu, 1 Nov 2018 14:59:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: Cc: draft-ietf-babel-hmac.all@ietf.org, ietf@ietf.org, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154110959830.29553.6414151772410048476@ietfa.amsl.com> Date: Thu, 01 Nov 2018 14:59:58 -0700 Archived-At: Subject: [secdir] Secdir early review of draft-ietf-babel-hmac-00 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, 01 Nov 2018 21:59:59 -0000 Reviewer: Robert Sparks Review result: Has Issues This is an early secdir review of draft-ietf-babel-hmac-00 Summary: There are issues in the draft to address Issues: The pseudo-header is IPv4-centric. The protocol allows for multiple HMAC algorithms, but has no mechanism for signaling which one was used. The MUST NOT at the top of page 8 will need to be adjusted after that's worked out. Discussion of what to do at a verifying peer that doesn't implement a chosen algorithm is also needed. Nits: The claim in 1.1 about not requiring persistent storage is contradicted by the definition of the protocol. At the very least, there is the need to persist the most recent (index,PC) seen. The third bullet at the top of page 4 (among different nodes) has its actors confused. As stated, communication between A and C is irrelevant to the communication between B and C. It would be worth building an example of bootstrapping the protocol between two peers that have no previous knowledge of each other. It's concerning to see a document (even a 00) whose point is to secure a protocol have no discussion at all in the Security Considerations section. It will help refine the document to create and maintain a summary of the important security points in this section going forward. From nobody Fri Nov 2 03:11:28 2018 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 A3F2712F1A5; Fri, 2 Nov 2018 03:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcQ11gmQef3G; Fri, 2 Nov 2018 03:11:12 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 D52631288BD; Fri, 2 Nov 2018 03:11:08 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id wA2AAx69030400; Fri, 2 Nov 2018 11:10:59 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id ABC5446DB0; Fri, 2 Nov 2018 11:11:05 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 9f89-qBtIOCy; Fri, 2 Nov 2018 11:11:03 +0100 (CET) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 6543946DA9; Fri, 2 Nov 2018 11:11:03 +0100 (CET) Date: Fri, 02 Nov 2018 11:11:03 +0100 Message-ID: <87ftwjpz60.wl-jch@irif.fr> From: Juliusz Chroboczek To: Robert Sparks Cc: , draft-ietf-babel-hmac.all@ietf.org, ietf@ietf.org, babel@ietf.org In-Reply-To: <154110959830.29553.6414151772410048476@ietfa.amsl.com> References: <154110959830.29553.6414151772410048476@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 02 Nov 2018 11:11:01 +0100 (CET) X-Miltered: at korolev with ID 5BDC22B3.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5BDC22B3.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5BDC22B3.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [secdir] [babel] Secdir early review of draft-ietf-babel-hmac-00 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, 02 Nov 2018 10:11:15 -0000 Dear Robert, Thank you very much for your review. > Issues: > The pseudo-header is IPv4-centric. The diagram in Section 4.1 shows 16-octet addresses, and so, if anything, it is IPv6-centric. I may be missing something, but I don't see any place where we're assuming IPv4. (The intent, of course, is that the pseudo-header is address-family independent -- the diagram shows 16-octet addresses, but we've been careful to avoid mentioning address families in the body text. If you have any advice about how to improve that, we're listening.) > The protocol allows for multiple HMAC algorithms, but has no mechanism for > signaling which one was used. This is the case, and it is the intent -- checking algorithm availability is done at key provisioning time. > The MUST NOT at the top of page 8 will need to be adjusted after that's > worked out. Discussion of what to do at a verifying peer that doesn't > implement a chosen algorithm is also needed. I don't understand. The first point of Section 4.3 looks clear to me -- a node doesn't compute an HMAC for every HMAC TLV it receives, it computes an HMAC for every key it has been provisioned with. Obviously, it knows the algorithm of every key it has been provisioned with (else it would have failed at configuration time), and hence there is no issue computing all required HMACs. Am I missing something? Do you have any suggestions about how to make that clearer? > Nits: > The claim in 1.1 about not requiring persistent storage is contradicted > by the definition of the protocol. At the very least, there is the need > to persist the most recent (index,PC) seen. A node is allowed to lose its state at any time, at the cost of one RTT worth of lost packets (it will need to issue a new challenge to every peer). In particular, it need not persist its state across reboots. You're right, though, that while this is reasonably clear in the Conceptual Overview section ("Consider a peer A that has no information about a pair B (e.g., because it has recently rebooted)"), we need to put an explicit "MAY discard its state at any time" in the normative part. > The third bullet at the top of page 4 (among different nodes) has its actors > confused. As stated, communication between A and C is irrelevant to the > communication between B and C. I have double-checked, and I believe the property is correct as stated. > It would be worth building an example of bootstrapping the protocol between > two peers that have no previous knowledge of each other. We've tried to do that in Section 2: In this situation, A discards the packet and challenges B to prove that it knows the HMAC key. It sends a "challenge request", a TLV containing a unique nonce, a value that has never been used before and will never be used again. B replies to the challenge request with a "challenge reply", a TLV containing a copy of the nonce chosen by A, in a packet protected by HMAC and containing the new value of B's PC. If you have any advice about how to improve this section, we're listening. > It's concerning to see a document (even a 00) whose point is to secure a > protocol have no discussion at all in the Security Considerations section. While we've done our best to describe the claimed security properties of the protocol in Section 1.2, we still need to write up the Security Considerations section. We'll do that as soon as we can spend some time together with my co-authors. Thanks again for your work, -- Juliusz From nobody Fri Nov 2 08:45:55 2018 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 B69C8126BED; Fri, 2 Nov 2018 08:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 c8smLR2ohVud; Fri, 2 Nov 2018 08:45:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 12E83124D68; Fri, 2 Nov 2018 08:45:36 -0700 (PDT) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wA2FjY7L037801 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 2 Nov 2018 10:45:35 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: Juliusz Chroboczek Cc: secdir@ietf.org, draft-ietf-babel-hmac.all@ietf.org, ietf@ietf.org, babel@ietf.org References: <154110959830.29553.6414151772410048476@ietfa.amsl.com> <87ftwjpz60.wl-jch@irif.fr> From: Robert Sparks Message-ID: <492b5149-aaed-6287-afd4-5a265dc8caa8@nostrum.com> Date: Fri, 2 Nov 2018 10:45:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <87ftwjpz60.wl-jch@irif.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [secdir] [babel] Secdir early review of draft-ietf-babel-hmac-00 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, 02 Nov 2018 15:45:38 -0000 On 11/2/18 5:11 AM, Juliusz Chroboczek wrote: > Dear Robert, > > Thank you very much for your review. > >> Issues: >> The pseudo-header is IPv4-centric. > The diagram in Section 4.1 shows 16-octet addresses, and so, if anything, > it is IPv6-centric. I may be missing something, but I don't see any place > where we're assuming IPv4. > > (The intent, of course, is that the pseudo-header is address-family > independent -- the diagram shows 16-octet addresses, but we've been > careful to avoid mentioning address families in the body text. If you > have any advice about how to improve that, we're listening.) Ok - skimming to fast and had a divide-by-4 error. Sorry. I still think you'll need to say something about how you're building the pseudo-header for IPv4 vs IPv6. Are you assuming that the header would be a different size for IPv4, or the same size with some zero-packing? > >> The protocol allows for multiple HMAC algorithms, but has no mechanism for >> signaling which one was used. > This is the case, and it is the intent -- checking algorithm availability > is done at key provisioning time. So this is me being new to babel itself - I'll go read the base documents more carefully. > >> The MUST NOT at the top of page 8 will need to be adjusted after that's >> worked out. Discussion of what to do at a verifying peer that doesn't >> implement a chosen algorithm is also needed. > I don't understand. The first point of Section 4.3 looks clear to me -- > a node doesn't compute an HMAC for every HMAC TLV it receives, it computes > an HMAC for every key it has been provisioned with. Obviously, it knows > the algorithm of every key it has been provisioned with (else it would > have failed at configuration time), and hence there is no issue computing > all required HMACs. > > Am I missing something? Do you have any suggestions about how to make > that clearer? No, that's all moot. > >> Nits: >> The claim in 1.1 about not requiring persistent storage is contradicted >> by the definition of the protocol. At the very least, there is the need >> to persist the most recent (index,PC) seen. > A node is allowed to lose its state at any time, at the cost of one RTT > worth of lost packets (it will need to issue a new challenge to every > peer). In particular, it need not persist its state across reboots. > > You're right, though, that while this is reasonably clear in the > Conceptual Overview section ("Consider a peer A that has no information > about a pair B (e.g., because it has recently rebooted)"), we need to put > an explicit "MAY discard its state at any time" in the normative part. > >> The third bullet at the top of page 4 (among different nodes) has its actors >> confused. As stated, communication between A and C is irrelevant to the >> communication between B and C. > I have double-checked, and I believe the property is correct as stated. I disagree. I think the clause you have in the "then" part of that sentence stands alone, and the "if" part has no bearing on it. Please explain further how A having accepted a packet from C has any influence whatsoever on whether B will accept a packet from C? Maybe the clause just needs restructuring to avoid the "if <> then <>" form. Perhaps this construction would work better: A copy of a valid packet originally sent from C to A and then replayed to B will be detected at B as invalid if... > >> It would be worth building an example of bootstrapping the protocol between >> two peers that have no previous knowledge of each other. > We've tried to do that in Section 2: > > In this situation, A discards the packet and challenges B to prove > that it knows the HMAC key. It sends a "challenge request", a TLV > containing a unique nonce, a value that has never been used before > and will never be used again. B replies to the challenge request > with a "challenge reply", a TLV containing a copy of the nonce chosen > by A, in a packet protected by HMAC and containing the new value of > B's PC. > > If you have any advice about how to improve this section, we're listening. Apologies for asking you to explain what's probably a simple and obvious thing, but, assuming at the beginning of that sentence that neither A nor B knows the other node's current (index, PC), then at the end of the paragraph, B _still_ doesn't know A's (index, PC). I'm assuming the challenge A sent to B is not protected by the basic mechanism in this draft, or B would have to discard it and challenge A so it could learn what A's (index, PC) was before it could even read the challenge. Can you walk me through the parts of the what you have written (or what you're implying by reference) that makes that clear? clear. > >> It's concerning to see a document (even a 00) whose point is to secure a >> protocol have no discussion at all in the Security Considerations section. > While we've done our best to describe the claimed security properties of > the protocol in Section 1.2, we still need to write up the Security > Considerations section. We'll do that as soon as we can spend some time > together with my co-authors. > > Thanks again for your work, > > -- Juliusz From nobody Fri Nov 2 11:22:16 2018 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 BCC331276D0; Fri, 2 Nov 2018 11:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMihIIFhHQNz; Fri, 2 Nov 2018 11:21:58 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 71302124C04; Fri, 2 Nov 2018 11:21:58 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id wA2ILoVV008561; Fri, 2 Nov 2018 19:21:50 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 9780B4BB47; Fri, 2 Nov 2018 19:21:56 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id oLz_D1lh5_0u; Fri, 2 Nov 2018 19:21:54 +0100 (CET) Received: from trurl.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 084D54BB42; Fri, 2 Nov 2018 19:21:50 +0100 (CET) Date: Fri, 02 Nov 2018 19:21:49 +0100 Message-ID: <87a7mrqr0i.wl-jch@irif.fr> From: Juliusz Chroboczek To: Robert Sparks Cc: secdir@ietf.org, draft-ietf-babel-hmac.all@ietf.org, ietf@ietf.org, babel@ietf.org In-Reply-To: <492b5149-aaed-6287-afd4-5a265dc8caa8@nostrum.com> References: <154110959830.29553.6414151772410048476@ietfa.amsl.com> <87ftwjpz60.wl-jch@irif.fr> <492b5149-aaed-6287-afd4-5a265dc8caa8@nostrum.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 02 Nov 2018 19:21:50 +0100 (CET) X-Miltered: at korolev with ID 5BDC95BE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5BDC95BE.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5BDC95BE.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [secdir] [babel] Secdir early review of draft-ietf-babel-hmac-00 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, 02 Nov 2018 18:22:01 -0000 > I still think you'll need to say something about how you're building the > pseudo-header for IPv4 vs IPv6. Are you assuming that the header would > be a different size for IPv4, or the same size with some zero-packing? Noted, will do. >>> The protocol allows for multiple HMAC algorithms, but has no mechanism for >>> signaling which one was used. >> This is the case, and it is the intent -- checking algorithm availability >> is done at key provisioning time. > So this is me being new to babel itself - I'll go read the base documents > more carefully. The point here is that the receiver does not need to know the set of HMAC algorithms implemented by the sender: it just computes its own HMAC of the packet, and compares the result (bytewise) with every HMAC TLV included by the sender; if some of the HMAC TLVs use algorithms that are not understood by the receiver, then the comparison fails, and no harm is done. This is, in my understanding, no different from RFC 2328, Appendix D.5.2, paragraph (2) (which is, as far as I know, unchanged by RFC 5709). >>> The third bullet at the top of page 4 (among different nodes) has its >>> actors confused. >> I have double-checked, and I believe the property is correct as stated. > I disagree. I think the clause you have in the "then" part of that > sentence stands alone, and the "if" part has no bearing on it. That's a subtle point, and one that my colleagues and I have spent a significant amount of time thinking about. I'm not happy with the current formulation, but this is the best I can do right now. More below. > A copy of a valid packet originally sent from C to A and then replayed to > B will be detected at B as invalid if... That's too strong. The protocol is designed to protect *multicast* communication, so a packet sent from C to both A and B will be accepted by both A and B. It does not matter if the packet is sent over a link-layer multicast C->A,B, or twice over link-layer unicast C->A,C->B -- in either case, it is accepted by both A and B. The property we have is that if C->A is accepted by A, then C->B is accepted by B only if both of the following are true: - B has previously accepted A's challenge reply; - B hasn't accepted any later packet from A. I agree that this property is confusing, so if you can point us to comparable protocols and the properties that they provably satisfy, then perhaps it could help us find a better formulation of the security properties that we claim. Thanks, -- Juliusz From nobody Fri Nov 2 19:48:25 2018 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 50FD812777C; Fri, 2 Nov 2018 19:48:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Takeshi Takahashi To: Cc: draft-ietf-stir-passport-shaken.all@ietf.org, stir@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154121328916.19556.15556330091107353459@ietfa.amsl.com> Date: Fri, 02 Nov 2018 19:48:09 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-stir-passport-shaken-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: Sat, 03 Nov 2018 02:48:10 -0000 Reviewer: Takeshi Takahashi Review result: Ready I do not have any particular concerns on the Security Considerations section. As mentioned in the section, the proposed extension will not pose any particular threats to the base specification. Having said that, I have minor comments and clarification questions as an individual who has read this document without prior knowledge of this topic. 1. In the abstract, The sentence "from ATIS .... Joint Task Force" will not be neceaary. For those who are familiar with SHAKEN specification, this sentence is obvious. For those who are not familiar with SHAKEN, this sentence will not provide any information that may facilitate the understanding of the overview of the draft. In either cases, the sentence will not be necessary. "to include information defined as part of ..." had better be refined further. I believe the readers wish to know the details (incl., types) of the information instead of where the specification was once defined. 2. In the abstract and/or introduction, STIR should be spelled out. I guess it is Secure Telephony Identity Revisited. 3. Terminology I feel that you use the terms "claims" and "indicators" for pointing to the same objects. If that's the case, I hope you could choose to use only one of them. Example of the use of two terminologies. 1. In the introduction, you have the sentence "This document specifies these indicators...". 2. In the introduction, you have the sentence "there are two additional claims..." 3. The title of section 4 is "Passport attest claim". and so on. 4. In section 5 "PASSporT origid claim", There is a sentence "There will likely be best practices documents that more precisely guide it's usage in real deployments". If you have such a document (including work-in-progress drafts), having a reference to this sentence will be appreciated. If there is no reference, I do not think we need this sentence here. 5. orig and origid claims If I understood correctly, both orig and origid represent identifies the same objects (including service provider-initiated calls, customers, classes of devices, etc.) In this case, if the object identified by orig and the one identified by origid is not the same, how should the receiver interpret these claims? 6. section 7 I am a bit confused. If the use of "attest" and "origid" is already defined elsewhere, what does this document define? Is the document define the use of those claims for some other protols (other than SIP)? 7. security consideration. As mentioned in this section, the values of the new "attest" and "origid" claims added by this extension are not used in the current validation step. Then, do you think we should encourage people to have another step that validates those claims added by this extension? I would appreciate your answers on these issues. From nobody Fri Nov 2 21:01:03 2018 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 02351130E2A; Fri, 2 Nov 2018 21:00:54 -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 0mjiZrhAfcFL; Fri, 2 Nov 2018 21:00:51 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D44AB130E4E; Fri, 2 Nov 2018 21:00:41 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id u6-v6so3429296ljd.1; Fri, 02 Nov 2018 21:00:41 -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=1rl3Xs6oEoHO2oT6VK69maDgLwtSun2UJlzci2Rl/f0=; b=PqAcz76qpb9iW8LpzkonpHmjs7IvN8oD6ztaFT97BJzL3RsY4H5nSFLjMcfsDMIuJn Bjbr66usOuPx3/5ZCBl20J4cNW26fsM2HaTL4SEMmyypfqXpCDML0eVx65zslBG7Gp1f QTuJg9qhJYLrt95aro0hyVLLjGCNMtkgZXUjr9HatA6zGnSsRgvJV49aUmUU7AjNfgQu nQbbYVEvUtLD+ZP7TJ//ZsZZXDAyGn530umdkHlddAOQ/NUkn2xPTZtedn8NHPO5DrHK as+OhL30sDwEftTOuzIGb+q1xZnqpQKMOGfBoEnDmpQX3YhHEgZVB43YQYpmvtSBgf0S 1DMQ== 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=1rl3Xs6oEoHO2oT6VK69maDgLwtSun2UJlzci2Rl/f0=; b=GuNz5wLB2oVBD754uu+5c2yOjGO8koF4jN2wk/grD1PYjKCA8kjZTcQi0dOlMkerJ6 LQr4zY7Brt0JO7feIqD1684ArYzU+h4V3cjPEiVZHvVjxnjo4BTYlV6dDRsIaif5zM+p 9lw1MGROTTxb0BZMf8h+vspcTQu6uCaXojBhbeRO5z/SI6btaw4b3t8vCDsgqy3ZSFfH bQR7yRTACf7GAXgvaHpLB2prXwKsNabdjKD65vP9TYK0+XQJ/ljd6LzeGIgdBhZtvFTW mR0w27DTQr/UXoEuuhklD/E0LYKUuXUKxon0fdigNPju/03fz/p0Pqx8ERsxcGtJbl8+ EAvQ== X-Gm-Message-State: AGRZ1gJaMKA1XlZK7NJ6mWtfmbLv869zb68RE+XHi3C8TBBvk2C/uUUw rWGIoMU82q3UAVNT3RLzew9yFZwNWcmeLDrXE2Y= X-Google-Smtp-Source: AJdET5faygPzBYA21nG7Q678YA6C+lVW60rX7ESr/lGwb/dIW32ZsCHHm7Nl1aRVN5ukV+xU3vBdS1HMWiclHf2CMFU= X-Received: by 2002:a2e:20f:: with SMTP id 15-v6mr9054104ljc.141.1541217639751; Fri, 02 Nov 2018 21:00:39 -0700 (PDT) MIME-Version: 1.0 References: <154100859354.5360.795312478907721541@ietfa.amsl.com> In-Reply-To: <154100859354.5360.795312478907721541@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Sat, 3 Nov 2018 13:00:27 +0900 Message-ID: To: rifaat.ietf@gmail.com Cc: secdir@ietf.org, IETF DMARC WG , draft-ietf-dmarc-rfc7601bis.all@ietf.org, ietf Content-Type: multipart/alternative; boundary="000000000000f066ad0579bab1da" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dmarc-rfc7601bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 04:00:54 -0000 --000000000000f066ad0579bab1da Content-Type: text/plain; charset="UTF-8" On Thu, Nov 1, 2018 at 2:56 AM Rifaat Shekh-Yusef wrote: > Section 7.1. Forged Header Fields > > In addition to a recommended solution, this section has list a potential > alternative solutions which the document then states that it is not > appropriate > for this document to specify which mechanism should be used. > > Since an implementer is not expected to do anything with this information, > it > might be more appropriate for this to be moved to an appendix at the end > of > document. > Implementers need to be aware of these things in order to make informed handling decisions, but we also acknowledge that we can't propose a single solution that will work for all operational environments. That's what this text means to convey. By my read of RFC3552, that's what this section is for, rather than an appendix. Section 7.2. Misleading Results, First paragraph, last sentence > > "In particular, this issue is not resolved by forged header field > removal > discussed above." > > which seems to be in conflict with the following statement from section 5: > > "For simplicity and maximum security, a border MTA could remove all > instances of this header field on mail crossing into its trust > boundary." > They're not in conflict. Even if I remove all instances of this header field at ingress and then evaluate DKIM (for example), I have no idea if a valid signature from "example.com" should be interpreted such that I trust that message more (or less). The two paragraphs you're talking about solve different problems. > Section 7.2. Misleading Results, Second paragraph > > "Hence, MUAs and downstream filters must take some care with use of > this header even after possibly malicious headers are scrubbed." > > How do you expect an MUA or downstream filter to act on "take some care"? > Can you elaborate on that? > If you are a spammer or malware distributor, you can elicit a DKIM "pass" by simply creating your own domain and signing your bad email with that domain. The fact that you got a "pass" doesn't tell you anything about which domain's signature succeeded, nor does it confirm the message content is safe or trustworthy in any way. "take some care" means "keep this in mind while deciding how to render a message to end users, who might not know to even look at this". 7.3. Header Field Position > > This section explains that headers fields are *not* guaranteed to be in a > specific order. The section then states that "there will be *some* > indication..." > > Since the order is not guaranteed, what do you expect an implementer to > take > away from this? > "in the general case" and "but most do not". So: Most of the time, you can rely on header field ordering to determine the sequence of handling. You are at least certain about whether you can trust the tail end of that, because you know your own environment from the ingress point. 7.8. Intentionally Malformed Header Fields > > This is a general issue with any header. Is there anything specific to > this > header that an implementer should pay attention to? > No, not really, but at the time this text was originally written (see RFC5451; this is about the fourth version of this material), it was felt this was worth adding. -MSK --000000000000f066ad0579bab1da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Nov 1, 2018 at 2:56 AM Rifaat She= kh-Yusef <rifaat.ietf@gmail.com= > wrote:
Section 7.1.=C2=A0 Forged Header Fields

In addition to a recommended solution, this section has list a potential alternative solutions which the document then states that it is not appropr= iate
for this document to specify which mechanism should be used.

Since an implementer is not expected to do anything with this information, = it
might be more appropriate for this to be moved to an appendix at the end of=
document.

Implementers need to be aware= of these things in order to make informed handling decisions, but we also = acknowledge that we can't propose a single solution that will work for = all operational environments.=C2=A0 That's what this text means to conv= ey.

By my read of RFC3552, that's what this section is for, rath= er than an appendix.

Section 7.2.=C2=A0 Misleading Results, First paragraph, last sentence

=C2=A0 =C2=A0"In particular, this issue is not resolved by forged head= er field removal
=C2=A0 =C2=A0discussed above."

which seems to be in conflict with the following statement from section 5:<= br>
=C2=A0 =C2=A0"For simplicity and maximum security, a border MTA could = remove all
=C2=A0 =C2=A0instances of this header field on mail crossing into its trust=
=C2=A0 =C2=A0boundary."

They'r= e not in conflict.=C2=A0 Even if I remove all instances of this header fiel= d at ingress and then evaluate DKIM (for example), I have no idea if a vali= d signature from "example.com"= should be interpreted such that I trust that message more (or less).
The two paragraphs you're talking about solve different pr= oblems.
=C2=A0
Section 7.2.=C2=A0 Misleading Results, Second paragraph

=C2=A0 =C2=A0"Hence, MUAs and downstream filters must take some care w= ith use of
=C2=A0 =C2=A0this header even after possibly malicious headers are scrubbed= ."

How do you expect an MUA or downstream filter to act on "take some car= e"?
Can you elaborate on that?

If you are a= spammer or malware distributor, you can elicit a DKIM "pass" by = simply creating your own domain and signing your bad email with that domain= .=C2=A0 The fact that you got a "pass" doesn't tell you anyth= ing about which domain's signature succeeded, nor does it confirm the m= essage content is safe or trustworthy in any way.

= "take some care" means "keep this in mind while deciding how= to render a message to end users, who might not know to even look at this&= quot;.

7.8.=C2=A0 Intentionally Malformed Header Fields

This is a general issue with any header. Is there anything specific to this=
header that an implementer should pay attention to?
No, not really, but at the time this text was originally writt= en (see RFC5451; this is about the fourth version of this material), it was= felt this was worth adding.

-MSK
--000000000000f066ad0579bab1da-- From nobody Sun Nov 4 05:41:20 2018 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 C4EA8120072 for ; Sun, 4 Nov 2018 05:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-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 9j7WNabX7Bnj for ; Sun, 4 Nov 2018 05:41:10 -0800 (PST) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 E634412D4EC for ; Sun, 4 Nov 2018 05:41:08 -0800 (PST) Received: by mail-pg1-x534.google.com with SMTP id w3-v6so2983039pgs.11 for ; Sun, 04 Nov 2018 05:41:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yol8NjRV9qTBUvNDK22mHJeF6swpMGF3l0UgggoubwA=; b=OfLC7wEGSVCsBpeeeCnLmKiJ6BWxdOtpvV4POWQtc8HQnVULf3UbZ0MW9pKWLlJQQu 3QHUtmKTNRGXPskBZgyPgXQv8W8kDJ8Zud766wUsScPHmnYXaDoA4kY+AtmeIZroaPVl i2HDgnKTSkNFvdzY0lEX0yzaTpifGvyfGO4AD6xEk/LB7PPpTs6UDNdHa98cXxYQanGV I2qyy/zaC3cZAQnnk0t7Lut0y9y1Zidfgj16o6QqEutKllkV9J/B21iO641SulrMd+CQ Qo/eovTj3bilp/sTqwAg75aFppzTooGudtrudHpqJP3oU7XoIpPKdJLQz6cFe9GB2YMm LaCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yol8NjRV9qTBUvNDK22mHJeF6swpMGF3l0UgggoubwA=; b=to14/9DDtLN2lFyPDd9g01dIYK3vr7UQUhggmtb1hyTtRR+lUQk9ZSZj4X6xyJb7qZ h0bq/No2OfvmkFA5lDFrKDS/voIod/9rdL6xRt6uWTJGKEbpwrXVWJfqFvs4FxVsc81V fEzEUBOG+ZfGf8rP5PjLq8QEFah+i5AZfkqYyGr9RqQoC4D1fQyvYGz6zjMdkrLf0Tbm JgE4ezIwNlkborZqs2/M4zBZVBjmt7ZfFl3iOiRbs6rUccXVG7XclJd8g6F3iAfuuszc HTPmuIKZbAUH/nrGTYNbhb2OmJTPXHPTVkOdonQ2L/Rp00thO9XsteFopH6i3L1VZSJf IrCQ== X-Gm-Message-State: AGRZ1gIQxpSK+MwhZ3fgar3LUKlaKFTdEclm7KVA4qOKf0SocnVERG80 Zt1eTebGLuWnaDBfR6Xh+9ge3A== X-Google-Smtp-Source: AJdET5ez7DmB7Yw8MlTXrgLDUzB4GQzH+nlCLEaxrhf5nqTt6ZS+h24iwOqDB3PE3b4a5D+YlzPrfQ== X-Received: by 2002:a63:d048:: with SMTP id s8-v6mr16790339pgi.311.1541338868319; Sun, 04 Nov 2018 05:41:08 -0800 (PST) Received: from [10.64.48.6] ([193.37.254.131]) by smtp.gmail.com with ESMTPSA id 5-v6sm76394690pgt.83.2018.11.04.05.41.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Nov 2018 05:41:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Chris Wendt In-Reply-To: <154121328916.19556.15556330091107353459@ietfa.amsl.com> Date: Sun, 4 Nov 2018 08:41:02 -0500 Cc: secdir@ietf.org, draft-ietf-stir-passport-shaken.all@ietf.org, stir@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7EF1B0D1-60B1-4735-B322-E581BB0539CC@chriswendt.net> References: <154121328916.19556.15556330091107353459@ietfa.amsl.com> To: Takeshi Takahashi X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-stir-passport-shaken-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2018 13:41:12 -0000 Hi Takeshi, Thanks for the review, comments inline. > On Nov 2, 2018, at 10:48 PM, Takeshi Takahashi = wrote: >=20 > Reviewer: Takeshi Takahashi > Review result: Ready >=20 > I do not have any particular concerns on the Security Considerations = section. > As mentioned in the section, the proposed extension will not pose any > particular threats to the base specification. >=20 > Having said that, I have minor comments and clarification questions as = an > individual who has read this document without prior knowledge of this = topic. >=20 > 1. In the abstract, >=20 > The sentence "from ATIS .... Joint Task Force" will not be neceaary. > For those who are familiar with SHAKEN specification, this sentence is = obvious. > For those who are not familiar with SHAKEN, this sentence will not = provide any > information that may facilitate the understanding of the overview of = the draft. > In either cases, the sentence will not be necessary. removed >=20 > "to include information defined as part of ..." had better be refined = further. > I believe the readers wish to know the details (incl., types) of the > information instead of where the specification was once defined. Changed the abstract to this: This document extends PASSporT, which is a token object that conveys = cryptographically-signed information about the participants involved in = communications. The extension is defined, corresponding to the SHAKEN = specification, to provide both a specific set of levels-of-confidence to = the correctness of the originating identity for a SIP based = Communication Service Provider (CSP) telephone network originated call = as well as an identifier that allows the CSP to uniquely identify the = origination of the call within its network. >=20 > 2. In the abstract and/or introduction, >=20 > STIR should be spelled out. I guess it is Secure Telephony Identity = Revisited. removed based on last comments but in either case i received this = comment from Adam as well. >=20 > 3. Terminology >=20 > I feel that you use the terms "claims" and "indicators" for pointing = to the > same objects. If that's the case, I hope you could choose to use only = one of > them. >=20 > Example of the use of two terminologies. > 1. In the introduction, you have the sentence "This document specifies = these > indicators...". 2. In the introduction, you have the sentence "there = are two > additional claims..." 3. The title of section 4 is "Passport attest = claim". and > so on. Claim is a specific term used to identify a key value in a JWT payload = defined in RFC7519, indicator is used in a more generic way That said, i changed that sentence to the following: This document specifies these values as claims to extend the base set of = PASSporT claims. replacing =E2=80=9Cindicators" to =E2=80=9Cvalues as claims..." >=20 > 4. In section 5 "PASSporT origid claim", >=20 > There is a sentence "There will likely be best practices documents = that more > precisely guide it's usage in real deployments". If you have such a = document > (including work-in-progress drafts), having a reference to this = sentence will > be appreciated. If there is no reference, I do not think we need this = sentence > here. removed >=20 > 5. orig and origid claims > If I understood correctly, both orig and origid represent identifies = the same > objects (including service provider-initiated calls, customers, = classes of > devices, etc.) In this case, if the object identified by orig and the = one > identified by origid is not the same, how should the receiver = interpret these > claims? orig and origid are not really related at all (although based on the = name i suppose that might be a natural conclusion) orig is the telephone or URI identity, origid is a unique id that = represents to a service provider where the call was originated in it=E2=80= =99s network. I added some of this detail to the abstract, and i believe it exists in = the document, but to fully appreciate the difference you probably do = need to be familiar with both PASSporT and SHAKEN documents. I feel like if i explained this difference again in any new text, it = would get repetitive. >=20 > 6. section 7 > I am a bit confused. If the use of "attest" and "origid" is already = defined > elsewhere, what does this document define? I started this document originally mostly referring to SHAKEN by = reference, but received WG comments that i needed to provide more = details in this document for the context and security considerations to = be appreciated, so to remove that would conflict with that WG opinion. > Is the document define the use of > those claims for some other protols (other than SIP)? No, SHAKEN will only be used in the context of telephone numbers and = SIP. >=20 > 7. security consideration. >=20 > As mentioned in this section, the values of the new "attest" and = "origid" > claims added by this extension are not used in the current validation = step. > Then, do you think we should encourage people to have another step = that > validates those claims added by this extension? SHAKEN does define how these values should be interpreted, i think in = the security considerations, we are only trying to say that the addition = of these claims does not impact or change the security properties that = are already discussed in the PASSporT document. >=20 > I would appreciate your answers on these issues. >=20 From nobody Sun Nov 4 07:38:31 2018 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 EBF04130E2E; Sun, 4 Nov 2018 07:38:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer To: Cc: lsr@ietf.org, ietf@ietf.org, draft-ietf-ospf-ospfv3-segment-routing-extensions.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154134589488.32046.1179323499664545252@ietfa.amsl.com> Date: Sun, 04 Nov 2018 07:38:14 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2018 15:38:15 -0000 Reviewer: Yaron Sheffer Review result: Has Nits Summary: document has non-security related nits. Details * The definition of "segment" is different here from the one used in the architecture RFC. The RFC is more abstract, quoting: A node steers a packet through an ordered list of instructions, called "segments". Whereas here a segment is simply a sub-path. This is confusing to a non-expert, and perhaps indicates a change in the group's thinking. * SID/Label Sub-TLV: is it Mandatory? If so, please point it out. * "The SR-Algorithm TLV is optional" - I find this sentence confusing. Maybe replace by "The SR-Algorithm TLV is mandatory for routers that implement segment routing"? * The reference under "IGP Algorithm Type" registry should be to the IANA registry itself, not to the I-D that defines it. (In particular since the IANA registry has already been established, https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types). * OSPFv3 Extended Prefix Range TLV Flags octet: add the usual incantation about reserved bits. * In general I agree with the reasoning in the Security Considerations. I would like to raise the question if, in addition to mis-routing, this adds a threat of massive denial-of-service on MPLS endpoints, e.g. by allowing an attacker who has OSPF access to introduce routing loops. (This may be completely bogus, I am far from expert with either of these protocols). From nobody Sun Nov 4 13:59:36 2018 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 D985A128CB7; Sun, 4 Nov 2018 13:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 QflhxqCHAnWi; Sun, 4 Nov 2018 13:59:12 -0800 (PST) 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 DD66E12872C; Sun, 4 Nov 2018 13:59:11 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id t81-v6so5111634iod.10; Sun, 04 Nov 2018 13:59:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f+ecuFMWRqVUOfuBbol6fy+m4+0O4eX7+zBR8z5ZRz0=; b=KDz1euOk8M0blDuE8gOgfrsuBxLPazMim59EUkkyYIHM59xWBplHjHu6n60FDQmfHp cvH8JEQJOlJL1jX6KGt1k1XyyGwoBGLYMu7T8a9W89XvlqgQ/zgs9F/ZWjViNxpTBlIA 6cZ6gYsSaNwRYquZsXtHlZGqlmHnL6DKZCqSqAdIVx0at9AQ5WIwnmP3nwLdoGAXqk1w GBmtAt7fv7wd9N8xKLXG27nVXqZ8nrlgxFmBLNT9+lnavNzL0UY6Im+2cTnW7cbGuEkU WfqQD6ablT9zgaE3im/qg/Mzrv/Y+iRmceAwzDzl7bmfNoYyoMqaRsJ0K3rHlLZG5AH0 ooQQ== 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=f+ecuFMWRqVUOfuBbol6fy+m4+0O4eX7+zBR8z5ZRz0=; b=swrizmZtrj5hbAWRRne08HLp3TC5ETHD8ARwcpEx0rHkgnVhXtjmrfuzr3l2s9qgrS bxyYQBbtPUjY6OgOqFr5roJ6Zub1+kFS947UzqMfvL0bHVt2I2sGDXeEiLZchDzfNZKX HiVTQw7DnTGp1mmys+iHZ5+PikFj/AkT+rwRo7ijjjvXGjjDwVrv2Dicj/bcDBLeRUiz sGHWDg6IfAz8hNoVW3AlTSljhJJZuKn1PVeLhBtk/GGJHKllzCgCt/5E6DrVHQ7wGDgg /Mg03bF7LBSd5EWWytZdf54rqnO/gIGSnf1qr/6nUBwcV8WgWA2fOzrT7QuFpPXWdJAK ilQg== X-Gm-Message-State: AGRZ1gLTkzlu3eRIkGfvuknpxCPUqa/opDpwAgIBmswBCrHav0oMFIuw 51yMNWxBlXQqichxWNcuxeGLtrWf11n95raFYYA= X-Google-Smtp-Source: AJdET5fLp9HD5ATnPratuMl/Ee9W1PC4QWfQhfm9jY0myZ1d785jnqo1LU38FWfLIGNte9q/H8+uDoeA/JcUvsghhfg= X-Received: by 2002:a6b:105:: with SMTP id 5-v6mr16961739iob.0.1541368751163; Sun, 04 Nov 2018 13:59:11 -0800 (PST) MIME-Version: 1.0 References: <154100859354.5360.795312478907721541@ietfa.amsl.com> In-Reply-To: From: Rifaat Shekh-Yusef Date: Sun, 4 Nov 2018 16:59:01 -0500 Message-ID: To: superuser@gmail.com Cc: secdir@ietf.org, dmarc@ietf.org, draft-ietf-dmarc-rfc7601bis.all@ietf.org, IETF-Discussion list Content-Type: multipart/alternative; boundary="000000000000e18fdb0579dde0ec" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dmarc-rfc7601bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2018 21:59:15 -0000 --000000000000e18fdb0579dde0ec Content-Type: text/plain; charset="UTF-8" On Sat, Nov 3, 2018 at 12:00 AM Murray S. Kucherawy wrote: > On Thu, Nov 1, 2018 at 2:56 AM Rifaat Shekh-Yusef > wrote: > >> Section 7.1. Forged Header Fields >> >> In addition to a recommended solution, this section has list a potential >> alternative solutions which the document then states that it is not >> appropriate >> for this document to specify which mechanism should be used. >> >> Since an implementer is not expected to do anything with this >> information, it >> might be more appropriate for this to be moved to an appendix at the end >> of >> document. >> > > Implementers need to be aware of these things in order to make informed > handling decisions, but we also acknowledge that we can't propose a single > solution that will work for all operational environments. That's what this > text means to convey. > > By my read of RFC3552, that's what this section is for, rather than an > appendix. > > Section 7.2. Misleading Results, First paragraph, last sentence >> >> "In particular, this issue is not resolved by forged header field >> removal >> discussed above." >> >> which seems to be in conflict with the following statement from section 5: >> >> "For simplicity and maximum security, a border MTA could remove all >> instances of this header field on mail crossing into its trust >> boundary." >> > > They're not in conflict. Even if I remove all instances of this header > field at ingress and then evaluate DKIM (for example), I have no idea if a > valid signature from "example.com" should be interpreted such that I > trust that message more (or less). > > The two paragraphs you're talking about solve different problems. > I thought the DKIM signature is part of this header, but I now understand that it is a separate header. > > >> Section 7.2. Misleading Results, Second paragraph >> >> "Hence, MUAs and downstream filters must take some care with use of >> this header even after possibly malicious headers are scrubbed." >> >> How do you expect an MUA or downstream filter to act on "take some care"? >> Can you elaborate on that? >> > > If you are a spammer or malware distributor, you can elicit a DKIM "pass" > by simply creating your own domain and signing your bad email with that > domain. The fact that you got a "pass" doesn't tell you anything about > which domain's signature succeeded, nor does it confirm the message content > is safe or trustworthy in any way. > > "take some care" means "keep this in mind while deciding how to render a > message to end users, who might not know to even look at this". > > I guess what I am looking for is a statement about the best case scenario for an MUA to be able to display a message with some confidence given the current state of affair. For example, if there is a valid DKIM, an Authentication-Results header with dkim pass,and the header was provided by a trusted entity? > 7.3. Header Field Position >> >> This section explains that headers fields are *not* guaranteed to be in a >> specific order. The section then states that "there will be *some* >> indication..." >> >> Since the order is not guaranteed, what do you expect an implementer to >> take >> away from this? >> > > "in the general case" and "but most do not". > > So: Most of the time, you can rely on header field ordering to determine > the sequence of handling. You are at least certain about whether you can > trust the tail end of that, because you know your own environment from the > ingress point. > > Fair enough; I think it is worth adding this sentence to make it clear. > 7.8. Intentionally Malformed Header Fields >> >> This is a general issue with any header. Is there anything specific to >> this >> header that an implementer should pay attention to? >> > > No, not really, but at the time this text was originally written (see > RFC5451; this is about the fourth version of this material), it was felt > this was worth adding. > > I guess it does hurt to remind implementer to pay attention to this issue, but I think it might be useful to state that there is nothing special about this header to avoid possible question like this in the future. Regards, Rifaat > -MSK > --000000000000e18fdb0579dde0ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat= , Nov 3, 2018 at 12:00 AM Murray S. Kucherawy <superuser@gmail.com> wrote:
On Thu, N= ov 1, 2018 at 2:56 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Sect= ion 7.1.=C2=A0 Forged Header Fields

In addition to a recommended solution, this section has list a potential alternative solutions which the document then states that it is not appropr= iate
for this document to specify which mechanism should be used.

Since an implementer is not expected to do anything with this information, = it
might be more appropriate for this to be moved to an appendix at the end of=
document.

Implementers need to be aware= of these things in order to make informed handling decisions, but we also = acknowledge that we can't propose a single solution that will work for = all operational environments.=C2=A0 That's what this text means to conv= ey.

By my read of RFC3552, that's what this section is for, rath= er than an appendix.

Section 7.2.=C2=A0 Misleading Results, First paragraph, last sentence

=C2=A0 =C2=A0"In particular, this issue is not resolved by forged head= er field removal
=C2=A0 =C2=A0discussed above."

which seems to be in conflict with the following statement from section 5:<= br>
=C2=A0 =C2=A0"For simplicity and maximum security, a border MTA could = remove all
=C2=A0 =C2=A0instances of this header field on mail crossing into its trust=
=C2=A0 =C2=A0boundary."

They'r= e not in conflict.=C2=A0 Even if I remove all instances of this header fiel= d at ingress and then evaluate DKIM (for example), I have no idea if a vali= d signature from "exa= mple.com" should be interpreted such that I trust that message mor= e (or less).

The two paragraphs you're talking about = solve different problems.

I thought the DKIM signature is part of this header, = but I now understand that it is a separate header.

=C2=A0
=C2=A0
Section 7.2.=C2=A0 Misleading Results, Second paragraph

=C2=A0 =C2=A0"Hence, MUAs and downstream filters must take some care w= ith use of
=C2=A0 =C2=A0this header even after possibly malicious headers are scrubbed= ."

How do you expect an MUA or downstream filter to act on "take some car= e"?
Can you elaborate on that?

If you are a= spammer or malware distributor, you can elicit a DKIM "pass" by = simply creating your own domain and signing your bad email with that domain= .=C2=A0 The fact that you got a "pass" doesn't tell you anyth= ing about which domain's signature succeeded, nor does it confirm the m= essage content is safe or trustworthy in any way.

= "take some care" means "keep this in mind while deciding how= to render a message to end users, who might not know to even look at this&= quot;.

I guess what= I am looking for is a statement about the best case scenario for an MUA to= be able to display a message with some confidence given the current state = of affair.
For example, if there is a valid DKIM, an Authenticati= on-Results header with dkim pass,and the header was provided by a trusted e= ntity?

=C2=A0
=
7.3.=C2=A0 Header Field Position

This section explains that headers fields are *not* guaranteed to be in a <= br> specific order. The section then states that "there will be *some* indication..."

Since the order is not guaranteed, what do you expect an implementer to tak= e
away from this?

"in the general ca= se" and "but most do not".

So: Most of the= time, you can rely on header field ordering to determine the sequence of h= andling.=C2=A0 You are at least certain about whether you can trust the tai= l end of that, because you know your own environment from the ingress point= .

Fair enough; = I think it is worth adding this sentence to make it clear.

=C2=A0
7.8.=C2=A0 Intentionally Malformed Header Fields

This is a general issue with any header. Is there anything specific to this=
header that an implementer should pay attention to?
No, not really, but at the time this text was originally writt= en (see RFC5451; this is about the fourth version of this material), it was= felt this was worth adding.


I guess it does hurt to remind implementer to= pay attention to this issue, but I think it might be useful to state that = there is nothing special about this header to avoid possible question like = this in the future.

Regards,
=C2=A0Rifaa= t

=C2=A0
-MS= K
--000000000000e18fdb0579dde0ec-- From nobody Sun Nov 4 20:04:23 2018 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 68E0A12D4E9; Sun, 4 Nov 2018 20:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 qE0T0v9knHxi; Sun, 4 Nov 2018 20:04:20 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 0E6E9128CF2; Sun, 4 Nov 2018 20:04:20 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id m18-v6so5091210lfl.11; Sun, 04 Nov 2018 20:04:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ktz+KcwiQRmEcp6Z0BswNQhrVaccJ/k8okWO7MoeR60=; b=n4rzJKPnjZafdxiBYPprQosuuzQccyGIAbMWuOt30asaF3qIR7c/K8bcSIfXG/NUCn 2q0Va4KJSKd8skA/K2Q0T85vn4VbPJXUnucEEhSBOqu9kchL2Glx00zk2vuBdV7Fl/Fv 9Gg+GJnz9d8jRlLqaH2liIhuWJCh9c7NAIemS2p40xU5s38GkDipf/480ElWycirbQeo R6m3escXeTH4jHdJTq0UpvLLlnTVMWW2VjAuzE1PT1p/7nfKYUr3IJ/PD2+zyvWbTZlt fuzB0UnE2p2I6229GNvoVg6/B31KSD6K6IjeRzBJy02sBiKwBxhVlDDy080W03idM/Bk Y5iA== 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=ktz+KcwiQRmEcp6Z0BswNQhrVaccJ/k8okWO7MoeR60=; b=TwJfB8djK1lWAgVlsCeUVrkfA2yi1dQVM/m1oPN98PC+l8wC3d7UzoJ6LqTn4Dq3t4 JOx53wT8YNzcdcwk+I2gm8lLOKRsRuyexHilZ7sZhMt7kvPJXehyXnNLHoc6IpkIB9Xg sIxST9z7nlH8ldfNVdfkajKLSRLPVPGp4j5E+uNkAF9sNICY5D/rbDsQNSUOlWKszjej 5OXAls0hJioib1GXODzyHWdt6WjB3zhGRwaf525EYjj4mp5ZBPECWD9ZvNMx2nAFSTwT Hc9o5KGMZVuag10tB4mehAcmWgShWp/Hrl3N4c2t/zcHKILlSWBQoAxWlHDYpMaNBllH 51OA== X-Gm-Message-State: AGRZ1gJ6vYEvaSnmGgoRvzENeHTI6minbZMZSnFaURdC8wWn3w03WTYL ml8ofjnrRjJzZYZlZ50BLrcmxYW3AV7oxfs3Rno= X-Google-Smtp-Source: AJdET5evdvNHfYRumq8IYIaT12bk7fswQ20Kb7sp+vyJhxBA8lAr2eRYYCtNUgPwLnsdWCf7+UOC7+vxyPD2w3giECA= X-Received: by 2002:a19:4948:: with SMTP id l8-v6mr10851228lfj.16.1541390658077; Sun, 04 Nov 2018 20:04:18 -0800 (PST) MIME-Version: 1.0 References: <154100859354.5360.795312478907721541@ietfa.amsl.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Mon, 5 Nov 2018 13:04:04 +0900 Message-ID: To: Rifaat Shekh-Yusef Cc: secdir@ietf.org, IETF DMARC WG , draft-ietf-dmarc-rfc7601bis.all@ietf.org, ietf Content-Type: multipart/alternative; boundary="000000000000a289020579e2fa72" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dmarc-rfc7601bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 04:04:22 -0000 --000000000000a289020579e2fa72 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 5, 2018 at 6:59 AM Rifaat Shekh-Yusef wrote: > Section 7.2. Misleading Results, Second paragraph >>> >>> "Hence, MUAs and downstream filters must take some care with use of >>> this header even after possibly malicious headers are scrubbed." >>> >>> How do you expect an MUA or downstream filter to act on "take some care"? >>> Can you elaborate on that? >>> >> >> If you are a spammer or malware distributor, you can elicit a DKIM "pass" >> by simply creating your own domain and signing your bad email with that >> domain. The fact that you got a "pass" doesn't tell you anything about >> which domain's signature succeeded, nor does it confirm the message content >> is safe or trustworthy in any way. >> >> "take some care" means "keep this in mind while deciding how to render a >> message to end users, who might not know to even look at this". >> > > I guess what I am looking for is a statement about the best case scenario > for an MUA to be able to display a message with some confidence given the > current state of affair. > For example, if there is a valid DKIM, an Authentication-Results header > with dkim pass,and the header was provided by a trusted entity? > I would argue that the text that's there does give the best case scenario: Absent a reputation system (which doesn't exist publicly, so the lowest common denominator doesn't have this), it's dangerous for any component of a mail system to trust a message just because some authentication system passed. The "value" of the attesting domain is what matters, and for the most part you don't know what that value is. Really large operators (e.g., Gmail) do have reputation systems, but your typical home open source installation does not. > 7.3. Header Field Position >>> >>> This section explains that headers fields are *not* guaranteed to be in >>> a >>> specific order. The section then states that "there will be *some* >>> indication..." >>> >>> Since the order is not guaranteed, what do you expect an implementer to >>> take >>> away from this? >>> >> >> "in the general case" and "but most do not". >> >> So: Most of the time, you can rely on header field ordering to determine >> the sequence of handling. You are at least certain about whether you can >> trust the tail end of that, because you know your own environment from the >> ingress point. >> >> > Fair enough; I think it is worth adding this sentence to make it clear. > Doesn't the last sentence of that paragraph already say exactly that? > >> 7.8. Intentionally Malformed Header Fields >>> >>> This is a general issue with any header. Is there anything specific to >>> this >>> header that an implementer should pay attention to? >>> >> >> No, not really, but at the time this text was originally written (see >> RFC5451; this is about the fourth version of this material), it was felt >> this was worth adding. >> >> > I guess it does hurt to remind implementer to pay attention to this issue, > but I think it might be useful to state that there is nothing special about > this header to avoid possible question like this in the future. > Adjusted the text accordingly. -MSK --000000000000a289020579e2fa72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 5, 2018 at 6:59 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote: <= br>
Section 7.2.=C2=A0 Misleading Results, Second paragraph

=C2=A0 =C2=A0"Hence, MUAs and downstream filters must take some care w= ith use of
=C2=A0 =C2=A0this header even after possibly malicious headers are scrubbed= ."

How do you expect an MUA or downstream filter to act on "take some car= e"?
Can you elaborate on that?

If you are a= spammer or malware distributor, you can elicit a DKIM "pass" by = simply creating your own domain and signing your bad email with that domain= .=C2=A0 The fact that you got a "pass" doesn't tell you anyth= ing about which domain's signature succeeded, nor does it confirm the m= essage content is safe or trustworthy in any way.

= "take some care" means "keep this in mind while deciding how= to render a message to end users, who might not know to even look at this&= quot;.

I guess what I am looki= ng for is a statement about the best case scenario for an MUA to be able to= display a message with some confidence given the current state of affair.<= /div>
For example, if there is a valid DKIM, an Authentication-Results = header with dkim pass,and the header was provided by a trusted entity?

I would argue that the text t= hat's there does give the best case scenario: Absent a reputation syste= m (which doesn't exist publicly, so the lowest common denominator doesn= 't have this), it's dangerous for any component of a mail system to= trust a message just because some authentication system passed.=C2=A0 The = "value" of the attesting domain is what matters, and for the most= part you don't know what that value is.=C2=A0 Really large operators (= e.g., Gmail) do have reputation systems, but your typical home open source = installation does not.


7.3.=C2=A0 Header Field Position

This section explains that headers fields are *not* guaranteed to be in a <= br> specific order. The section then states that "there will be *some* indication..."

Since the order is not guaranteed, what do you expect an implementer to tak= e
away from this?

"in the general ca= se" and "but most do not".

So: Most of the= time, you can rely on header field ordering to determine the sequence of h= andling.=C2=A0 You are at least certain about whether you can trust the tai= l end of that, because you know your own environment from the ingress point= .


Fair enou= gh; I think it is worth adding this sentence to make it clear.

Doesn't the last sentence of = that paragraph already say exactly that?

=C2=A0
7.8.=C2=A0 Intentionally Malformed Header Fields

This is a general issue with any header. Is there anything specific to this=
header that an implementer should pay attention to?
No, not really, but at the time this text was originally writt= en (see RFC5451; this is about the fourth version of this material), it was= felt this was worth adding.


I guess it does hurt to remind implementer to= pay attention to this issue, but I think it might be useful to state that = there is nothing special about this header to avoid possible question like = this in the future.

Adjus= ted the text accordingly.

-MSK
--000000000000a289020579e2fa72-- From nobody Mon Nov 5 00:13:01 2018 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 0FECB128CFD; Mon, 5 Nov 2018 00:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.971 X-Spam-Level: X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 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 Yn7-KDV0Q5wz; Mon, 5 Nov 2018 00:12:40 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB23F1274D0; Mon, 5 Nov 2018 00:12:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2584; q=dns/txt; s=iport; t=1541405559; x=1542615159; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=3RuELjpgQ6FBMgNfmr0KL29zO6bV7UatfVy1re84ukE=; b=bO0Z9bHHyMSjOJd/NWfPLXABFDdPYZuVKMVXnYQbYoQJ4MlrorcQcfVz 0zpg4HX7xpfsZsitpAJEocCsICHOTEn+Zu4hZ3dirXOGJWi7nyCa0aM/i ui7JDVLwdOF2jg6PRFmaTtWSTQaaejIMMEOsw8YCdTsL4Xvg7CAtBTeVu A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAADB+t9b/xbLJq1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUgQBAQEBCwGCan8og3aId41Ely2Beg0lhEcCg2Y1DA0BAwE?= =?us-ascii?q?BAgEBAm0cDIU7AQUjFTMNARALEgYCAgUWCwICCQMCAQIBNw4GAQwBBwEBgx6?= =?us-ascii?q?CAQ+nMIEgDoU9hFMFgQuLAoFBP4ERgxKDGwSEY4JXAoh3hkCFUYoqCZERGIF?= =?us-ascii?q?VhQCCfIcPl0aBRQI0gVUzGggbFTuCbYImFxKIS4U/PjABjh4BAQ?= X-IronPort-AV: E=Sophos;i="5.54,467,1534809600"; d="scan'208";a="7813543" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Nov 2018 08:12:35 +0000 Received: from [10.60.140.52] (ams-ppsenak-nitro3.cisco.com [10.60.140.52]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id wA58CY1h007576; Mon, 5 Nov 2018 08:12:34 GMT Message-ID: <5BDFFB72.7010100@cisco.com> Date: Mon, 05 Nov 2018 09:12:34 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Yaron Sheffer , secdir@ietf.org CC: lsr@ietf.org, ietf@ietf.org, draft-ietf-ospf-ospfv3-segment-routing-extensions.all@ietf.org References: <154134589488.32046.1179323499664545252@ietfa.amsl.com> In-Reply-To: <154134589488.32046.1179323499664545252@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.60.140.52, ams-ppsenak-nitro3.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16 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, 05 Nov 2018 08:12:42 -0000 Hi Yaron, thanks for your comments, please see inline: On 04/11/18 16:38 , Yaron Sheffer wrote: > Reviewer: Yaron Sheffer > Review result: Has Nits > > Summary: document has non-security related nits. > > Details > > * The definition of "segment" is different here from the one used in the > architecture RFC. The RFC is more abstract, quoting: A node steers a packet > through an ordered list of instructions, called "segments". Whereas here a > segment is simply a sub-path. This is confusing to a non-expert, and perhaps > indicates a change in the group's thinking. the definition in this draft relates to segment as used by IGPs, in which case a segment represents the sub-path. There are other segments outside of IGPs which can represent other things, but they are not covered by this draft. > > * SID/Label Sub-TLV: is it Mandatory? If so, please point it out. SID/Label Sub-TLV is not advertised on its own. It is advertised as a sub-TLV of the: 3.2. SID/Label Range TLV 3.3. SR Local Block TLV Both of these section specify that SID/Label Sub-TLV MUST be included. > > * "The SR-Algorithm TLV is optional" - I find this sentence confusing. Maybe > replace by "The SR-Algorithm TLV is mandatory for routers that implement > segment routing"? the text says: "If the SR-Algorithm TLV is not advertised by the node, such node is considered as not being segment routing capable." Isn't that sufficient? > > * The reference under "IGP Algorithm Type" registry should be to the IANA > registry itself, not to the I-D that defines it. (In particular since the IANA > registry has already been established, > https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types). I got another comment from Opsdir last call review to include the I-D that defined it. I Added them both, hopefully that satisfy everybody. > > * OSPFv3 Extended Prefix Range TLV Flags octet: add the usual incantation about > reserved bits. Done. > * In general I agree with the reasoning in the Security Considerations. I would > like to raise the question if, in addition to mis-routing, this adds a threat > of massive denial-of-service on MPLS endpoints, e.g. by allowing an attacker > who has OSPF access to introduce routing loops. (This may be completely bogus, > I am far from expert with either of these protocols). above is addressed by usage of the usage of the OSPF authentication as described in the security section. thanks, Peter > > . > From nobody Mon Nov 5 21:22:55 2018 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 381D3129619 for ; Mon, 5 Nov 2018 21:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSjMQ-nAD28r for ; Mon, 5 Nov 2018 21:22:53 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE4B21294D0 for ; Mon, 5 Nov 2018 21:22:52 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id f3-v6so10251700ljk.9 for ; Mon, 05 Nov 2018 21:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=AjwL7cvmgG9QJoUtIwwNAt/tdn38Voe+UTcstCe2Hhk=; b=s0qc6FlKv7owjTsIzXXNgG6W9iQvs5AmSoFTbZ+/J4JqXgiJ7k/YvwIF7rbyNgMUYM kMQ6WjFKffy0E2rflbLSBR6ZHMm8ox0FiOo2zAcaubFf6eKMLe+GnvUkxrmipRPSxtef Zat0lAfvElW9sDsrr4iZYdLBzS8lNsOOHEIB0k+sJHD/lQsqK9j8ozIdZ+og3d13SnSl OKYDQ8yZ6jmeTXdRCJ9OpZ++DdeAUPhAbNgWDY4X1OvqeOvgC0K5r6f2ZPpeTy12yuSE vbP6QQBeGoqpogzui73cI7NAAYWvDrM+3twyXa94ks87fvxb0VuM5D1COYPD/QXoTbM8 oQqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=AjwL7cvmgG9QJoUtIwwNAt/tdn38Voe+UTcstCe2Hhk=; b=uHRgAkR1zxxx4vHus0U2EjaQKiZLXlJHplaLjR6uN8iZPilBd77U1hc7vzOdNNbmvx 0boQpWFmHcSGtRDvTVO7VsYeWebbnlm29rhdSKZEpmJtUjklfsXGdGrl9IlQ5hCwnX/B uE0L5rHgSUbSRJaE78j/Y+8aiPskf+cWZggl+vo1OalzFAcNtX5rRDISBCWjZASB5KMf GkVX8EIwdcMBkfGHPTcT3lP2aVf35uySW8Ma3hyYy38+JltY/yNVaNg8d0sWOqyY+JTk mtnZE/NEKmQy0L4gXxT+4Mle1LHMgBhk/+52DcMpiDdCPK0ZQ+K1ul+2AycPcbyMYFCM MvMw== X-Gm-Message-State: AGRZ1gLKGPRoRHwkBURqXuzd7wFN+9PC5LA/0WN9cNCTolfmAOZA80BL bnDJ5kCkcHRHHVD6GEwGfp6n53NWwhp7ZHVGSaERaKYu X-Google-Smtp-Source: AJdET5fen6/ZbnoqIKq7G2Fpp8H+7RAdtDXulyv5wF6XA0toeVAaUR7aWBNQhZMM/5wkbZxIaZm0+JBKDuY612hqaTE= X-Received: by 2002:a2e:5418:: with SMTP id i24-v6mr17403959ljb.51.1541481770774; Mon, 05 Nov 2018 21:22:50 -0800 (PST) MIME-Version: 1.0 From: Eric Rescorla Date: Mon, 5 Nov 2018 21:22:13 -0800 Message-ID: To: secdir@ietf.org Content-Type: multipart/alternative; boundary="000000000000600d0c0579f83102" Archived-At: Subject: [secdir] Regrets for today 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, 06 Nov 2018 05:22:54 -0000 --000000000000600d0c0579f83102 Content-Type: text/plain; charset="UTF-8" I am going to miss secdir lunch today. I managed to double-book myself and unfortunately, I can't skip the other thing. I'd like to take this opportunity to say thanks to the secdir reviewers. If people were hoping to catch me, I'll be around all week. -Ekr --000000000000600d0c0579f83102 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am going to miss secdir lunch today. I managed to d= ouble-book myself and unfortunately, I can't skip the other thing. I= 9;d like to take this opportunity to say thanks to the secdir reviewers. If= people were hoping to catch me, I'll be around all week.

-Ekr

--000000000000600d0c0579f83102-- From nobody Tue Nov 6 01:00:27 2018 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 C19E1130E1B; Tue, 6 Nov 2018 01:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 hi3h7adPlIlg; Tue, 6 Nov 2018 01:00:13 -0800 (PST) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9E16124BE5; Tue, 6 Nov 2018 01:00:13 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id n10-v6so5513087pgv.10; Tue, 06 Nov 2018 01:00:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2xJMclPpH4J+mNCTzFIylLs1nr9/x/ZD356jp9P582k=; b=FQ7MfcNySjnMLyoHpq1GVAmPsJxwQuXwkL0Yn9L6BttwUZq98mL4wS01Rxrz2ScYxc RW9pyDBfKqKC/1sDBBgqm/vs1abLsm6ZQWQVTAJJgYWUMLXpE4hMEuQmRiCvJ/cMT03P FTJVQ+4AobF/CU2hc5tLLTZsim3EoLnbOcmgd6ZwsuEY6WecenbOsLD2IrHzbcqCzO7N Cl2IUPomxPRCcpjy1GHOHjb5oQlXQ55fhMe1c44NP5ldxg7auFyV5NM/13aiMWsJeq1T yaY2O4hA4Tb8QT/AVEUGfmao3qG7SY0HkeHUPg+/pWdACOmB3TERvD9BaA9OnfKgWvCW uZTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2xJMclPpH4J+mNCTzFIylLs1nr9/x/ZD356jp9P582k=; b=hUL0MOG+8PpAo4KeOLb4qoDNJiZF39NadlL9VMZ1k9apFdjCAPmJL0I/Ojql5j5i21 FEv7xjT7T+gzfOQOvpTvbN8e/1xrGCmPxy486I/rNJnLjg1OoIYr5lVeEAnERyb409pY 4ZuuLjSqYoSJAb40EUCamntnMhn3TzfdsYU9TxT5Bf3Swqji451WWdd9sodfQb5U5oE+ +INj8IMnzFQArRaIzFOAKk3fV9FL7Z5dvy1Q1RBKa9aYLYIWae2pEE5r9LCF4uPzEGu3 35TQg7/GABUt6HuoFBhpk3lHGrWZsfFZvqJeGBzQZaFkWERlP/7ofQzrb6WUULg5hdFY 3obA== X-Gm-Message-State: AGRZ1gKqA9B8wxUKQBYAO0FXGhXPDyVmo/CFr6iyJs/D6Fsux7e7tI5H irVtfwLjIfpRBqQxQ+uV+oWUybGD X-Google-Smtp-Source: AJdET5c8pvj6Bk90bvYKk7lUB2fZFx3HxJRIYCZEvCmPElCCOn0cMRZYzJGhoCHj1s8fZJb6XsmS7A== X-Received: by 2002:a63:2d82:: with SMTP id t124mr22913426pgt.260.1541494812822; Tue, 06 Nov 2018 01:00:12 -0800 (PST) Received: from [172.30.16.28] ([49.231.0.179]) by smtp.gmail.com with ESMTPSA id u6-v6sm25185841pgq.19.2018.11.06.01.00.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Nov 2018 01:00:12 -0800 (PST) To: Peter Psenak , secdir@ietf.org Cc: lsr@ietf.org, ietf@ietf.org, draft-ietf-ospf-ospfv3-segment-routing-extensions.all@ietf.org References: <154134589488.32046.1179323499664545252@ietfa.amsl.com> <5BDFFB72.7010100@cisco.com> From: Yaron Sheffer Message-ID: <09c65027-5352-f783-7cbb-af5f8aa95cec@gmail.com> Date: Tue, 6 Nov 2018 08:13:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <5BDFFB72.7010100@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16 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, 06 Nov 2018 09:00:17 -0000 Thank you Peter, this addresses my comments. Yaron On 05/11/2018 10:12, Peter Psenak wrote: > Hi Yaron, > > thanks for your comments, please see inline: > > > On 04/11/18 16:38 , Yaron Sheffer wrote: >> Reviewer: Yaron Sheffer >> Review result: Has Nits >> >> Summary: document has non-security related nits. >> >> Details >> >> * The definition of "segment" is different here from the one used in the >> architecture RFC. The RFC is more abstract, quoting: A node steers a >> packet >> through an ordered list of instructions, called "segments". Whereas >> here a >> segment is simply a sub-path. This is confusing to a non-expert, and >> perhaps >> indicates a change in the group's thinking. > > the definition in this draft relates to segment as used by IGPs, in > which case a segment represents the sub-path. There are other segments > outside of IGPs which can represent other things, but they are not > covered by this draft. > > >> >> * SID/Label Sub-TLV: is it Mandatory? If so, please point it out. > > SID/Label Sub-TLV is not advertised on its own. It is advertised as a > sub-TLV of the: > > 3.2.  SID/Label Range TLV > 3.3.  SR Local Block TLV > > Both of these section specify that SID/Label Sub-TLV MUST be included. > >> >> * "The SR-Algorithm TLV is optional" - I find this sentence confusing. >> Maybe >> replace by "The SR-Algorithm TLV is mandatory for routers that implement >> segment routing"? > > > the text says: > >    "If the SR-Algorithm TLV >    is not advertised by the node, such node is considered as not being >    segment routing capable." > > Isn't that sufficient? > > >> >> * The reference under "IGP Algorithm Type" registry should be to the IANA >> registry itself, not to the I-D that defines it. (In particular since >> the IANA >> registry has already been established, >> https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types). >> > > I got another comment from Opsdir last call review to include the I-D > that defined it. I Added them both, hopefully that satisfy everybody. > >> >> * OSPFv3 Extended Prefix Range TLV Flags octet: add the usual >> incantation about >> reserved bits. > > Done. > > > > >> * In general I agree with the reasoning in the Security >> Considerations. I would >> like to raise the question if, in addition to mis-routing, this adds a >> threat >> of massive denial-of-service on MPLS endpoints, e.g. by allowing an >> attacker >> who has OSPF access to introduce routing loops. (This may be >> completely bogus, >> I am far from expert with either of these protocols). > > above is addressed by usage of the usage of the OSPF authentication as > described in the security section. > > thanks, > Peter > >> >> . >> > From nobody Tue Nov 6 06:17:38 2018 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 2D282130E3F; Tue, 6 Nov 2018 06:02:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1541512972; bh=Q502H2UsgOFaJHAK2UoOM0upGjnpjngPGEPclma08l0=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=rEhLRMw3I1JOJ5+HFOi8Q7b/r6/b3Wdd7o8gPfdBX9DV3H0eplNA5yCPwZLYhy3c0 QEscLh4pFRrD5fTuokTRfat3gQR5h9mPgC2Mi256guY69XtM1L2Zm6PYS/68AQKzyd 3IS+O1kAM3lPVswGEIJLI0xqADLLiLq9zFTgUC2s= X-Mailbox-Line: From new-work-bounces@ietf.org Tue Nov 6 06:02:51 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A484130E06; Tue, 6 Nov 2018 06:02:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1541512971; bh=Q502H2UsgOFaJHAK2UoOM0upGjnpjngPGEPclma08l0=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=jXp2gmQx8NI75C+ix5Lxf/wlH3IgZnT+C+06Cax0Uo3jpr/SbFD17N9BKoKE9mxmj O3cIwy+j8d1iHLern5GUWlC5w5RG3G8oyjDdBjKvtmK+Rg9QY+zt0cPp2JTQ68fdv9 QP16Ma6pF0C6Y+PJ71ljW+ahJrzDEbAETpTaoJFM= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C56130E06 for ; Tue, 6 Nov 2018 06:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.059 X-Spam-Level: X-Spam-Status: No, score=-4.059 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SBL=0.141, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAh1W2r0tk_X for ; Tue, 6 Nov 2018 06:02:48 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7282112D4F1 for ; Tue, 6 Nov 2018 06:02:48 -0800 (PST) Received: from [112.102.120.179] (helo=jiaxueyuandeMacBook-Pro.local) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1gK1wL-0002DW-B7 for new-work@ietf.org; Tue, 06 Nov 2018 14:02:45 +0000 To: new-work@ietf.org From: xueyuan Message-ID: Date: Tue, 6 Nov 2018 22:02:39 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 06 Nov 2018 06:17:36 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Pointer Events Working Group (until 2018-12-04) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 14:02:54 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgUG9pbnRl ciBFdmVudHMgV29ya2luZyBHcm91cDoKIMKgIGh0dHBzOi8vd3d3LnczLm9yZy8yMDE4LzExL3Bv aW50ZXJldmVudHMtY2hhcnRlci5odG1sCgpBcyBwYXJ0IG9mIGVuc3VyaW5nIHRoYXQgdGhlIGNv bW11bml0eSBpcyBhd2FyZSBvZiBwcm9wb3NlZCB3b3JrCmF0IFczQywgdGhpcyBkcmFmdCBjaGFy dGVyIGlzIHB1YmxpYyBkdXJpbmcgdGhlIEFkdmlzb3J5CkNvbW1pdHRlZSByZXZpZXcgcGVyaW9k LgoKVzNDIGludml0ZXMgcHVibGljIGNvbW1lbnRzIHRocm91Z2ggMjAxOC0xMi0wNCBvbiB0aGUK cHJvcG9zZWQgY2hhcnRlci4gUGxlYXNlIHNlbmQgY29tbWVudHMgdG8KcHVibGljLW5ldy13b3Jr QHczLm9yZywgd2hpY2ggaGFzIGEgcHVibGljIGFyY2hpdmU6CiDCoCBodHRwOi8vbGlzdHMudzMu b3JnL0FyY2hpdmVzL1B1YmxpYy9wdWJsaWMtbmV3LXdvcmsvCgpPdGhlciB0aGFuIGNvbW1lbnRz IHNlbnQgaW4gZm9ybWFsIHJlc3BvbnNlcyBieSBXM0MgQWR2aXNvcnkKQ29tbWl0dGVlIFJlcHJl c2VudGF0aXZlcywgVzNDIGNhbm5vdCBndWFyYW50ZWUgYSByZXNwb25zZSB0bwpjb21tZW50cy4g SWYgeW91IHdvcmsgZm9yIGEgVzNDIE1lbWJlciBbMV0sIHBsZWFzZSBjb29yZGluYXRlCnlvdXIg Y29tbWVudHMgd2l0aCB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZS4gRm9y CmV4YW1wbGUsIHlvdSBtYXkgd2lzaCB0byBtYWtlIHB1YmxpYyBjb21tZW50cyB2aWEgdGhpcyBs aXN0IGFuZApoYXZlIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0aXZlIHJlZmVy IHRvIGl0IGZyb20gaGlzCm9yIGhlciBmb3JtYWwgcmV2aWV3IGNvbW1lbnRzLgoKSWYgeW91IHNo b3VsZCBoYXZlIGFueSBxdWVzdGlvbnMgb3IgbmVlZCBmdXJ0aGVyIGluZm9ybWF0aW9uLCBwbGVh c2UKY29udGFjdCBQaGlsaXBwZSBMZSBIZWdhcmV0LCBXM0MgUHJvamVjdCBNYW5hZ2VtZW50IExl YWQsIDxwbGhAdzMub3JnPi4KClRoYW5rIHlvdSwKClh1ZXl1YW4gSmlhLCBXM0MgTWFya2V0aW5n ICYgQ29tbXVuaWNhdGlvbnMKClsxXSBodHRwOi8vd3d3LnczLm9yZy9Db25zb3J0aXVtL01lbWJl ci9MaXN0CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpu ZXctd29yayBtYWlsaW5nIGxpc3QKbmV3LXdvcmtAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXctd29yawo= From nobody Tue Nov 6 15:05:55 2018 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 02C5F130E09; Tue, 6 Nov 2018 15:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 DVXdHv7Hg3cj; Tue, 6 Nov 2018 15:05:40 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 51A40130E11; Tue, 6 Nov 2018 15:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost2.informatik.uni-bremen.de [134.102.200.7]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id wA6N5R2V024609; Wed, 7 Nov 2018 00:05:32 +0100 (CET) Received: from [IPv6:2001:67c:1232:144:5806:ec29:caf1:467b] (unknown [IPv6:2001:67c:1232:144:5806:ec29:caf1:467b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 42qQBF3Tt3z1Bqf; Wed, 7 Nov 2018 00:05:25 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <5BAE5278.9060005@gmail.com> Date: Wed, 7 Nov 2018 06:05:20 +0700 Cc: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-cbor-cddl.all@ietf.org, cbor@ietf.org X-Mao-Original-Outgoing-Id: 563238319.030874-67ebffb30a8d9e341cbc27ad2556a927 Content-Transfer-Encoding: quoted-printable Message-Id: <7DEE4371-FA16-490B-B148-7E237DA5308E@tzi.org> References: <5BAE5278.9060005@gmail.com> To: Chris Lonvick X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-cbor-cddl-05 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, 06 Nov 2018 23:05:44 -0000 Hi Chris, thank you for this review. > On Sep 28, 2018, at 23:10, Chris Lonvick = wrote: >=20 > Hello, >=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 >=20 > The summary of the review is READY with nits. >=20 > I skimmed through the draft and agree with the author's statement in = the first paragraph of the Security Considerations section: > This document presents a content rules language for expressing CBOR > data structures. As such, it does not bring any security issues on > itself, although specification of protocols that use CBOR naturally > need security analysis when defined. >=20 > (As a very minor nit, I'd suggest using "analyses" rather than = "analysis".) >=20 > Nit 1: The authors have made a good effort at identifying some of the = topics that may be considered in a security considerations section of = specifications that use protocols using CDDL to define CBOR structures. = However, I would recommend that those bullet points be used to = supplement a normative reference to RFC 3552 =E2=80=9CSecurity = Considerations Guidelines".=20 >=20 > Perhaps adding the following between the first and second paragraphs: > Guidelines for writing security considerations are defined in = Security Considerations Guidelines [RFC 3552]=20 > (BCP 72). Implementers using CDDL to define CBOR structures in = protocols must follow those guidelines. >=20 > Then change the start of the second paragraph from =E2=80=9CTopics = that may be..." to "Additional topics that may be..." I think this is a very good idea. It is now addressed (with slightly = different wording) in = https://github.com/cbor-wg/cddl/commit/d3b2483f1b7a94eb9ba9cab22143c43f1be= 8909d (which will be in -06). > Nit 2: I am not very familiar with all of this, but it seems to me = that RFC 8152, "CBOR Object Signing and Encryption (COSE)" should be a = normative reference rather than an informative reference, and some = mention should be made of it in the Security Considerations section. = Reference is made in RFC 8152 to CDDL (4th paragraph in Section 1.3): > As well as the prose description, a version of a CBOR grammar is > presented in CDDL. Since CDDL has not been published in an RFC, = this > grammar may not work with the final version of CDDL. The CDDL > grammar is informational; the prose description is normative. >=20 > I may be off base here, but it just seems that since 8152 has been = published as a Standards Track document, then this draft should = normatively reference it and any subsequent updates to 8152 should = normatively reference the Standards Track RFC issuing from this draft.=20= It is indeed true that COSE (RFC 8152) uses CDDL, and even goes ahead to = quickly define the subset it uses in its section 1.3 (with the slightly = confusing title =E2=80=9CCBOR grammar=E2=80=9D). That does not make the COSE specification a normative reference for CDDL = though =E2=80=94 many protocols specified in CDDL will not make use of = COSE, and those that do will rightly reference COSE as a normative = reference. There is no need to read section 1.3 of RFC 8152 to use the = specification of CDDL. I do agree that a COSEbis (which might be started about now) could use = the specification of CDDL as a normative reference (if the downref is = accepted), but we don=E2=80=99t have to have a position on that now. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Nov 6 19:12:02 2018 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 AA7E9127332; Tue, 6 Nov 2018 19:12:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVV2iHq4Otmo; Tue, 6 Nov 2018 19:11:57 -0800 (PST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (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 14BF0128CE4; Tue, 6 Nov 2018 19:11:57 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2018 19:11:56 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,474,1534834800"; d="scan'208,217";a="278946741" Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by fmsmga006.fm.intel.com with ESMTP; 06 Nov 2018 19:11:56 -0800 Received: from orsmsx115.amr.corp.intel.com (10.22.240.11) by ORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 6 Nov 2018 19:11:55 -0800 Received: from orsmsx116.amr.corp.intel.com ([169.254.7.124]) by ORSMSX115.amr.corp.intel.com ([169.254.4.106]) with mapi id 14.03.0415.000; Tue, 6 Nov 2018 19:11:55 -0800 From: "Ganga, Ilango S" To: =?utf-8?B?TWFnbnVzIE55c3Ryw7Zt?= , "secdir@ietf.org" , "draft-ietf-nvo3-geneve@ietf.org" Thread-Topic: Secdir review (early review) of draft-ietf-nvo3-geneve Thread-Index: AQHUa05O1lkJPkWghUmTeaMFlyPdI6U4khKAgAGdQICACXZEUA== Date: Wed, 7 Nov 2018 03:11:54 +0000 Message-ID: References: <5bd9f599.1c69fb81.4fed7.d7cd@mx.google.com> In-Reply-To: <5bd9f599.1c69fb81.4fed7.d7cd@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzQzOGZkOWEtMDdjNi00ZDEzLTg3MTgtNTU3YzE1OGEyYTRkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoib2d0T2N0bkJJVFhOU3lTU1VsaFE1Y1J2Q3MyVStiZFdCRGNjZ1RtWTV2VmtUVnNzSEsxOVhudHBtSXpjNGlBcCJ9 x-ctpclassification: CTP_NT x-originating-ip: [10.22.254.138] Content-Type: multipart/alternative; boundary="_000_C5A274B25007804B800CB5B289727E3583D11BB5ORSMSX116amrcor_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir review (early review) of draft-ietf-nvo3-geneve 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, 07 Nov 2018 03:12:01 -0000 --_000_C5A274B25007804B800CB5B289727E3583D11BB5ORSMSX116amrcor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFnbnVzLA0KDQpIZXJlIGlzIG91ciBwcm9wb3NlZCB0ZXh0IHRoYXQgd2UgYmVsaWV2ZSB3 aWxsIHNhdGlzZnkgeW91ciBjb21tZW50IG9uIDMuNS4xOg0KDQpJbiBTZWN0aW9uIDIuMi4xIGFk ZCBuZXcgaGlnaGxpZ2h0ZWQgdGV4dCBpbiBwYXJhZ3JhcGggdGhhdCBiZWdhbiB3aXRoIOKAnFRy YW5zaXQgZGV2aWNlcy4u4oCdDQpPcHRpb25zLCBpZiBwcmVzZW50IGluIHRoZSBwYWNrZXQsIE1V U1QgYmUgZ2VuZXJhdGVkIGFuZCB0ZXJtaW5hdGVkIGJ5IGVuZCBwb2ludHMuIFRyYW5zaXQgZGV2 aWNlcyBNQVkgYmUgYWJsZSB0byBpbnRlcnByZXQgdGhlIG9wdGlvbnMsIGhvd2V2ZXIsIGFzDQog ICBub24tdGVybWluYXRpbmcgZGV2aWNlcywgdHJhbnNpdCBkZXZpY2VzIGRvIG5vdCBvcmlnaW5h dGUgb3INCiAgIHRlcm1pbmF0ZSB0aGUgR2VuZXZlIHBhY2tldCwgaGVuY2UgTVVTVCBOT1QgaW5z ZXJ0IG9yIGRlbGV0ZSBvcHRpb25zLA0KICAgd2hpY2ggaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9m IEdlbmV2ZSBlbmRwb2ludHMuICBUaGUgcGFydGljaXBhdGlvbg0KICAgb2YgdHJhbnNpdCBkZXZp Y2VzIGluIGludGVycHJldGluZyBvcHRpb25zIGlzIE9QVElPTkFMLg0KDQoNClNlY3Rpb24gMy41 LjEgLSBSZW1vdmUgdGhlIGhpZ2hsaWdodGVkIHRleHQ6DQpvICBTb21lIG9wdGlvbnMgbWF5IGJl IGRlZmluZWQgaW4gc3VjaCBhIHdheSB0aGF0IHRoZSBwb3NpdGlvbiBpbiB0aGUNCiAgICAgIG9w dGlvbiBsaXN0IGlzIHNpZ25pZmljYW50LiAgT3B0aW9ucyBvciB0aGVpciBvcmRlcmluZywgTVVT VCBOT1QNCiAgICAgIGJlIGNoYW5nZWQgYnkgdHJhbnNpdCBkZXZpY2VzLg0KDQpTZWN0aW9uIDMu NS4xIC0gQWRkIGhpZ2hsaWdodGVkIHRleHQgdG8gdGhlIGxhc3QgYnVsbGV0Og0KICAgbyAgQW4g b3B0aW9uIFNIT1VMRCBOT1QgYmUgZGVwZW5kZW50IHVwb24gYW55IG90aGVyIG9wdGlvbiBpbiB0 aGUgcGFja2V0LA0KIGkuZS4sIG9wdGlvbnMgY2FuIGJlIHByb2Nlc3NlZCBpbmRlcGVuZGVudCBv ZiBvbmUgYW5vdGhlci4gSGVuY2UgYW4gb3B0aW9uIE1VU1QgTk9UIGFmZmVjdCB0aGUgcGFyc2lu ZyBvciBpbnRlcnByZXRhdGlvbiBvZiBhbnkgb3RoZXIgb3B0aW9uLg0KDQpSZW1vdmUgdGhlIGZv bGxvd2luZyBwYXJhZ3JhcGggZnJvbSA2LjI6DQpHZW5ldmUgc3VwcG9ydHMgR2VuZXZlIE9wdGlv bnMsIHNvIGFuIG9wZXJhdG9yIG1heSBjaG9vc2UgdG8gdXNlIGENCiAgIEdlbmV2ZSBvcHRpb24g VExWIHRvIHByb3ZpZGUgYSBjcnlwdG9ncmFwaGljIGRhdGEgcHJvdGVjdGlvbg0KICAgbWVjaGFu aXNtLCB0byB2ZXJpZnkgdGhlIGRhdGEgaW50ZWdyaXR5IG9mIHRoZSBHZW5ldmUgaGVhZGVyLCBH ZW5ldmUNCiAgIG9wdGlvbnMgb3IgdGhlIGVudGlyZSBHZW5ldmUgcGFja2V0IGluY2x1ZGluZyB0 aGUgcGF5bG9hZC4NCiAgIEltcGxlbWVudGF0aW9uIG9mIHN1Y2ggYSBtZWNoYW5pc20gaXMgYmV5 b25kIHRoZSBzY29wZSBvZiB0aGlzDQogICBkb2N1bWVudC4NCg0KSW50cm9kdWNlIG5ldyBzZWN0 aW9uIGFmdGVyIDYuMyBhcyBmb2xsb3dzOg0KNi40ICBPcHRpb25zIEludGVycHJldGF0aW9uIGJ5 IFRyYW5zaXQgRGV2aWNlcw0KDQpPcHRpb25zLCBpZiBwcmVzZW50IGluIHRoZSBwYWNrZXQsIGFy ZSBnZW5lcmF0ZWQgYW5kIHRlcm1pbmF0ZWQgYnkgZW5kIHBvaW50cy4gQXMgaW5kaWNhdGVkIGlu IDIuMi4xLCB0cmFuc2l0IGRldmljZXMgbWF5IGludGVycHJldCB0aGUgb3B0aW9ucy4gSG93ZXZl ciwgaWYgdGhlIHBhY2tldCBpcyBwcm90ZWN0ZWQgYnkgZW5kIHBvaW50IHRvIGVuZCBwb2ludCBl bmNyeXB0aW9uLCBmb3IgZXhhbXBsZSB0aHJvdWdoIElQc2VjLCB0cmFuc2l0IGRldmljZXMgd2ls bCBub3QgaGF2ZSB2aXNpYmlsaXR5IGludG8gdGhlIEdlbmV2ZSBoZWFkZXIgb3Igb3B0aW9ucyBp biB0aGUgcGFja2V0LiBJbiBjYXNlcyB3aGVyZSBvcHRpb25zIGFyZSBpbnRlcnByZXRlZCBieSB0 cmFuc2l0IGRldmljZXMsIHRoZSBvcGVyYXRvciBNVVNUIGVuc3VyZSB0aGF0IHRyYW5zaXQgZGV2 aWNlcyBhcmUgdHJ1c3RlZCBhbmQgbm90IGNvbXByb21pc2VkLiBJbXBsZW1lbnRhdGlvbiBvZiBh IG1lY2hhbmlzbSB0byBlbnN1cmUgdGhpcyB0cnVzdCBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRo aXMgZG9jdW1lbnQuDQoNClBsZWFzZSBsZXQgdXMga25vdyBpZiB0aGlzIGFkZHJlc3NlcyB5b3Vy IGNvbW1lbnQgb24gMy41LjEuICBUaGUgb3RoZXIgdHdvIGNvbW1lbnRzIGhhdmUgYmVlbiBzYXRp c2ZpZWQgYXMgbm90ZWQgYmVsb3cuDQoNClRoYW5rcywNCklsYW5nbw0KDQoNCkZyb206IE1hZ251 cyBOeXN0csO2bSBbbWFpbHRvOm1hZ251c25AZ21haWwuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBP Y3RvYmVyIDMxLCAyMDE4IDExOjM0IEFNDQpUbzogR2FuZ2EsIElsYW5nbyBTIDxpbGFuZ28ucy5n YW5nYUBpbnRlbC5jb20+OyBzZWNkaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbnZvMy1nZW5ldmVA aWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBTZWNkaXIgcmV2aWV3IChlYXJseSByZXZpZXcpIG9mIGRy YWZ0LWlldGYtbnZvMy1nZW5ldmUNCg0KSGkgSWxhbmdvLA0KRm9yIDMuNCwgSSB0aGluayB0aGlz IG1heSBiZSBzdWZmaWNpZW50Lg0KDQpGb3IgNi4yLCBJIHdpbGwgZGVmZXIgdG8gdGhlIElFVEYg ZGlyZWN0b3IvdGVsZWNoYXQgZGlzY3Vzc2lvbiB0aGF0IHdpbGwgb2NjdXIgYXQgc29tZSBwb2lu dCBmb3IgdGhpcyBkcmFmdC4gSWYgdGhlIGludGVudCBpcyBpbnRlcm9wZXJhYmlsaXR5IGFuZCBy b2J1c3RuZXNzIG9mIHN1Y2ggYW4gb3B0aW9uLCB0aGVuIEkgd291bGQgcmVjb21tZW5kIGl0IHRv IGJlIHNwZWNpZmllZCBpbiB0aGUgSUVURiwgYnV0IEkgY2FuIGFsc28gc2VlIGhvdyB5b3Ugd291 bGQgcHJlZmVyIHRoYXQgc3VjaCBzcGVjaWZpY2F0aW9uIHdvcmsgb2NjdXJzIG91dHNpZGUgdGhp cyBwYXJ0aWN1bGFyIGRyYWZ0IOKAkyB3aGljaCBzaG91bGQgYmUgZG9hYmxlLiBQZXJoYXBzIHN0 YXlpbmcgc2lsZW50IG9uIHRoZSBvcHRpb24gYWx0ZXJuYXRpdmUgYW5kIGp1c3QgcmVjb21tZW5k IGxldmVyYWdpbmcgbGF5ZXItcHJvdmlkZWQgaW5mcmFzdHJ1Y3R1cmUgc3VjaCBhcyBpcHNlYyBt YXkgYmUgYmVzdCBmb3Igbm93Pw0KDQpJJ2xsIGF3YWl0IHlvdXIgc3VnZ2VzdGVkIHVwZGF0ZWQg bGFuZ3VhZ2UgZm9yIDMuNS4xLg0KDQpUaGFua3MsDQoNClNlbnQgZnJvbSBteSBXaW5kb3dzIDEw IHBob25lDQoNCkZyb206IEdhbmdhLCBJbGFuZ28gUzxtYWlsdG86aWxhbmdvLnMuZ2FuZ2FAaW50 ZWwuY29tPg0KU2VudDogVHVlc2RheSwgT2N0b2JlciAzMCwgMjAxOCAxODoxMg0KVG86IE1hZ251 cyBOeXN0csO2bTxtYWlsdG86bWFnbnVzbkBnbWFpbC5jb20+OyBzZWNkaXJAaWV0Zi5vcmc8bWFp bHRvOnNlY2RpckBpZXRmLm9yZz47IGRyYWZ0LWlldGYtbnZvMy1nZW5ldmVAaWV0Zi5vcmc8bWFp bHRvOmRyYWZ0LWlldGYtbnZvMy1nZW5ldmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogU2VjZGly IHJldmlldyAoZWFybHkgcmV2aWV3KSBvZiBkcmFmdC1pZXRmLW52bzMtZ2VuZXZlDQoNCkhpIE1h Z251cywNCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgZmVlZGJhY2suIFBsZWFzZSBzZWUg aW5saW5lIGZvciBteSByZXNwb25zZXMuDQoNClJlZ2FyZHMsDQpJbGFuZ28NCg0KDQpGcm9tOiBN YWdudXMgTnlzdHLDtm0gW21haWx0bzptYWdudXNuQGdtYWlsLmNvbV0NClNlbnQ6IFR1ZXNkYXks IE9jdG9iZXIgMjMsIDIwMTggOTowMSBQTQ0KVG86IHNlY2RpckBpZXRmLm9yZzxtYWlsdG86c2Vj ZGlyQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1udm8zLWdlbmV2ZUBpZXRmLm9yZzxtYWlsdG86ZHJh ZnQtaWV0Zi1udm8zLWdlbmV2ZUBpZXRmLm9yZz4NClN1YmplY3Q6IFNlY2RpciByZXZpZXcgKGVh cmx5IHJldmlldykgb2YgZHJhZnQtaWV0Zi1udm8zLWdlbmV2ZQ0KDQpJIGhhdmUgcmV2aWV3ZWQg dGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzDQpvbmdv aW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBi eSB0aGUNCklFU0cuIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRo ZSBiZW5lZml0IG9mIHRoZQ0Kc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuICBEb2N1bWVudCBlZGl0 b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0DQp0aGVzZSBjb21tZW50cyBqdXN0IGxpa2Ug YW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCg0KVGhpcyBkb2N1bWVudCBkZXNjcmliZXMg IkdlbmV2ZSwiIGEgcHJvdG9jb2wgZm9yIEdFbmVyaWMgTkV0d29yayBWaXJ0dWFsaXphdGlvbiBF bmNhcHN1bGF0aW9uLiBUaGUgZG9jdW1lbnQgaXMgd3JpdHRlbiBpbiBhIGNsZWFyIG1hbm5lciBh bmQgd2l0aCBhIHRob3JvdWdoIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24uIEkgaGF2 ZSBqdXN0IGEgZmV3IHF1ZXN0aW9ucy9jb21tZW50czoNCg0KLSBTZWN0aW9uIDMuNDogVGhlICJN VVNUIGlnbm9yZSIgZm9yIHRoZSByZXNlcnZlZCBiaXRzIHNob3VsZCBwcmVzdW1hYmx5IHN0YXRl ICJTSEFMTCBiZSBpZ25vcmVkIGZvciB0aGlzIHZlcnNpb24gb2YgdGhlIEdlbmV2ZSBwcm90b2Nv bC4iIC0gYXMgSSBpbWFnaW5lIHRoYXQgaW4gYSBmdXR1cmUgdmVyc2lvbiwgdGhlc2UgYml0cyBt YXkgbm90IGJlIGlnbm9yZWQ/DQoNCjxJbGFuZ28+IEluIHRoZW9yeSwgYSBmdXR1cmUgdmVyc2lv biBtYXkgY2hhbmdlIHRoZSBiZWhhdmlvciBvZiBhbnkgb2YgdGhlIGhlYWRlciBmaWVsZHMgaW5j bHVkaW5nIHRoZSByZXNlcnZlZCBiaXRzLiAgVGhlIGhlYWRlciBkZWZpbml0aW9uIGlzIGZvciB0 aGlzIHZlcnNpb24gb2YgdGhlIHByb3RvY29sLg0KDQpQbGVhc2Ugc2VlIGlmIHRoZSBmb2xsb3dp bmcgdGV4dCB3b3VsZCBzYXRpc2Z5IHRoZSBpbnRlbnQgb2YgeW91ciBjb21tZW50Lg0K4oCcUmVz ZXJ2ZWQgZmllbGQgd2hpY2ggTVVTVCBiZSB6ZXJvIG9uIHRyYW5zbWlzc2lvbiBhbmQgTVVTVCBi ZSBpZ25vcmVkIG9uIHJlY2VpcHQu4oCdDQoNCk9yIGxldCB1cyBrbm93IGlmIHlvdSBzdGlsbCB3 YW50IHRvIGhhdmUgdGhpcyBxdWFsaWZpZWQgd2l0aCDigJxmb3IgdGhpcyB2ZXJzaW9uIG9mIHRo ZSBwcm90b2NvbOKAnQ0KPC8+DQoNCi0gU2VjdGlvbiAzLjUuMTogSSB3b25kZXIgYWJvdXQgdGhl IHNpbXVsdGFuZW91cyByZXF1aXJlbWVudCB0aGF0IG9uZSBvcHRpb24gbXVzdCBub3QgYWZmZWN0 IHRoZSBwYXJzaW5nIG9yIGludGVycHJldGF0aW9uIG9mIGFub3RoZXIgb3B0aW9uIGJ1dCB0aGF0 IHRoZSBzZXF1ZW5jaW5nIChvcmRlcikgb2Ygb3B0aW9ucyBtYXkgYmUgc2lnbmlmaWNhbnQgLSB0 aGV5IHNlZW0gdG8gYmUgY29udHJhZGljdG9yeSBzaW5jZSBpZiB0aGUgc2VxdWVuY2luZyAqaXMq IHNpZ25pZmljYW50LCB0aGVuIHNvbWUgb3B0aW9uIG11c3QgYmUgaW1wYWN0ZWQgYnkgYSBwcmV2 aW91cyBvbmUncyB2YWx1ZT8gRnJvbSBhIHNlY3VyaXR5IHBlcnNwZWN0aXZlLCBJIGFsc28gd29u ZGVyIGlmIHRoZXJlIGNvdWxkIGJlIHNlY3VyaXR5IGNvbnNlcXVlbmNlcyBvZiByZS1vcmRlcmlu ZyBvcHRpb25zIChhbmQgaG93IHRvIHRlbGwgaWYgc29tZW9uZSBkaWQgcmUtb3JkZXIgLSBzZWUg YmVsb3cpPw0KDQo8SWxhbmdvPiBZb3UgcmFpc2UgYSBnb29kIHBvaW50LiBUaGUgaW50ZW50IG9m IHRoaXMgc3RhdGVtZW50IGlzLCBwYXJzaW5nIGFuZCBpbnRlcnByZXRhdGlvbiBvZiBvcHRpb25z IHNob3VsZCBub3QgYmUgZGVwZW5kZW50IG9uIG9uZSBhbm90aGVyLiBXZSBhcmUgZGlzY3Vzc2lu ZyBhbW9uZyB0aGUgYXV0aG9ycyB0byBzZWUgaG93IHdlIGNhbiBpbmNsdWRlIGFwcHJvcHJpYXRl IGNsYXJpZnlpbmcgc3RhdGVtZW50cyB0byBhZGRyZXNzIHlvdXIgcG9pbnQuIEkgd2lsbCB1cGRh dGUgeW91IHNob3J0bHkuDQo8Lz4NCg0KLSBTZWN0aW9uIDYuMiwgc2hvdWxkbid0IHN1Y2ggYW4g T3B0aW9uIGJlIGRlZmluZWQgdG8gcmVkdWNlIHRoZSByaXNrIG9mIHVuZGVyLXNwZWNpZmllZCBv ciBzdWJwYXIgc3BlY2lmaWNhdGlvbnMgb2Ygc3VjaCBpbnRlZ3JpdHkgbWVjaGFuaXNtcz8gT3Ig YWxzbyBmcm9tIGFuIGludGVyb3AgcGVyc3BlY3RpdmU/DQoNCjxJbGFuZ28+IFVzaW5nIGEgR2Vu ZXZlIG9wdGlvbiBmb3IgdGhlIHB1cnBvc2Ugb2YgZGF0YSBpbnRlZ3JpdHkgaXMgbW9yZSBvZiBh biBvcHRpbWl6YXRpb24uIE90aGVyd2lzZSBkYXRhIGludGVncml0eSBjb3VsZCBiZSBwcm92aWRl ZCBieSB1c2luZyBleGlzdGluZyBtZWNoYW5pc21zIGxpa2UgSVBzZWMgKGFzIHN0YXRlZCBpbiBz ZWNvbmQgcGFyYWdyYXBoIG9mIDYuMikuIFdlIGluY2x1ZGVkIHRoZSBsYXN0IHBhcmFncmFwaCB0 byBzaG93IG90aGVyIHBvc3NpYmlsaXRpZXMuIFdlIGNvdWxkIHJlbW92ZSB0aGlzIHBhcmFncmFw aCBpZiBpdCBtYXkgY2F1c2UgYW55IGNvbmZ1c2lvbi4NCg0KV2Ugd291bGQgbGlrZSB0byBrZWVw IHRoZSBHZW5ldmUgYmFzZSBzcGVjaWZpY2F0aW9uIGluZGVwZW5kZW50IG9mIG9wdGlvbnMgc3Bl Y2lmaWNhdGlvbnMsIG9wdGlvbnMgY291bGQgYmUgYSBkZWZpbmVkIGluIGEgZnV0dXJlIHN0YW5k YXJkcyBhY3Rpb24uDQo8Lz4NCg0KDQpUaGFua3MuDQotLSBNYWdudXMNCg0K --_000_C5A274B25007804B800CB5B289727E3583D11BB5ORSMSX116amrcor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0 RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5IaSBNYWdudXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5IZXJlIGlzIG91ciBwcm9wb3NlZCB0ZXh0IHRoYXQgd2UgYmVsaWV2ZSB3aWxsIHNhdGlzZnkg eW91ciBjb21tZW50IG9uIDMuNS4xOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+SW4gU2VjdGlvbiAyLjIuMSBhZGQgbmV3IGhpZ2hsaWdodGVkIHRleHQgaW4gcGFyYWdy YXBoIHRoYXQgYmVnYW4gd2l0aCDigJxUcmFuc2l0IGRldmljZXMuLuKAnTxvOnA+PC9vOnA+PC9z cGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T3B0aW9ucywgaWYgcHJl c2VudCBpbiB0aGUgcGFja2V0LCBNVVNUIGJlIGdlbmVyYXRlZCBhbmQgdGVybWluYXRlZCBieSBl bmQgcG9pbnRzLiBUcmFuc2l0IGRldmljZXMgTUFZIGJlIGFibGUgdG8gaW50ZXJwcmV0IHRoZSBv cHRpb25zLCBob3dldmVyLCBhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgbm9uLXRlcm1pbmF0aW5nIGRldmljZXMsIHRyYW5z aXQgZGV2aWNlcyBkbyBub3Qgb3JpZ2luYXRlIG9yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyB0ZXJtaW5hdGUgdGhlIEdlbmV2 ZSBwYWNrZXQsIGhlbmNlIE1VU1QgTk9UIGluc2VydCBvciBkZWxldGUgb3B0aW9ucyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 IHdoaWNoIGlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiBHZW5ldmUgZW5kcG9pbnRzLiZuYnNwOyBU aGUgcGFydGljaXBhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgb2YgdHJhbnNpdCBkZXZpY2VzIGluIGludGVycHJldGlu ZyBvcHRpb25zIGlzIE9QVElPTkFMLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNlY3Rpb24gMy41LjEg LSBSZW1vdmUgdGhlIGhpZ2hsaWdodGVkIHRleHQ6PG86cD48L286cD48L3NwYW4+PC9pPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5vJm5ic3A7IFNvbWUgb3B0aW9ucyBtYXkgYmUg ZGVmaW5lZCBpbiBzdWNoIGEgd2F5IHRoYXQgdGhlIHBvc2l0aW9uIGluIHRoZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgb3B0aW9uIGxpc3QgaXMgc2lnbmlmaWNhbnQuJm5ic3A7IE9wdGlvbnMN Cjwvc3Bhbj48cz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6cmVkIj5vciB0aGVpciBvcmRlcmluZyw8L3NwYW4+PC9zPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4gTVVTVCBO T1Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJlIGNoYW5nZWQgYnkgdHJhbnNpdCBkZXZpY2Vz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+U2VjdGlvbiAzLjUuMSAtIEFkZCBoaWdobGlnaHRlZCB0ZXh0 IHRvIHRoZSBsYXN0IGJ1bGxldDo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBvJm5ic3A7IDwvc3Bhbj4NCjx1PjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMDBCMDUw Ij5BbiBvcHRpb24gU0hPVUxEIE5PVCBiZSBkZXBlbmRlbnQgdXBvbiBhbnkgb3RoZXIgb3B0aW9u IGluIHRoZSBwYWNrZXQsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3U+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOiMwMEIwNTAiPiZuYnNwO2kuZS4sIG9wdGlvbnMgY2FuIGJlIHByb2Nlc3NlZCBp bmRlcGVuZGVudCBvZiBvbmUgYW5vdGhlci4gSGVuY2U8L3NwYW4+PC91PjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4gYW4gb3B0 aW9uIE1VU1QgTk9UIGFmZmVjdCB0aGUgcGFyc2luZyBvciBpbnRlcnByZXRhdGlvbg0KIG9mIGFu eSBvdGhlciBvcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5SZW1vdmUgdGhlIGZvbGxvd2luZyBw YXJhZ3JhcGggZnJvbSA2LjI6PG86cD48L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMUY0OTdEIj5HZW5ldmUgc3VwcG9ydHMgR2VuZXZlIE9wdGlvbnMsIHNvIGFu IG9wZXJhdG9yIG1heSBjaG9vc2UgdG8gdXNlIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3M+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHM+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBHZW5ldmUgb3B0aW9u IFRMViB0byBwcm92aWRlIGEgY3J5cHRvZ3JhcGhpYyBkYXRhIHByb3RlY3Rpb248bzpwPjwvbzpw Pjwvc3Bhbj48L3M+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHM+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyBtZWNoYW5pc20sIHRvIHZlcmlmeSB0aGUgZGF0YSBpbnRlZ3JpdHkgb2YgdGhlIEdlbmV2 ZSBoZWFkZXIsIEdlbmV2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcz48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48cz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IG9wdGlvbnMgb3IgdGhlIGVudGlyZSBHZW5l dmUgcGFja2V0IGluY2x1ZGluZyB0aGUgcGF5bG9hZC48bzpwPjwvbzpwPjwvc3Bhbj48L3M+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHM+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBJbXBsZW1lbnRh dGlvbiBvZiBzdWNoIGEgbWVjaGFuaXNtIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpczxvOnA+ PC9vOnA+PC9zcGFuPjwvcz48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48cz48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7IGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcz48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkludHJvZHVjZSBuZXcgc2VjdGlv biBhZnRlciA2LjMgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjYuNCZuYnNwOyBPcHRpb25zIEludGVycHJldGF0aW9uIGJ5 IFRyYW5zaXQgRGV2aWNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+T3B0aW9ucywgaWYgcHJlc2VudCBpbiB0aGUgcGFja2V0LCBhcmUgZ2VuZXJh dGVkIGFuZCB0ZXJtaW5hdGVkIGJ5IGVuZCBwb2ludHMuIEFzIGluZGljYXRlZCBpbiAyLjIuMSwg dHJhbnNpdCBkZXZpY2VzIG1heSBpbnRlcnByZXQgdGhlIG9wdGlvbnMuIEhvd2V2ZXIsIGlmIHRo ZSBwYWNrZXQgaXMgcHJvdGVjdGVkIGJ5DQogZW5kIHBvaW50IHRvIGVuZCBwb2ludCBlbmNyeXB0 aW9uLCBmb3IgZXhhbXBsZSB0aHJvdWdoIElQc2VjLCB0cmFuc2l0IGRldmljZXMgd2lsbCBub3Qg aGF2ZSB2aXNpYmlsaXR5IGludG8gdGhlIEdlbmV2ZSBoZWFkZXIgb3Igb3B0aW9ucyBpbiB0aGUg cGFja2V0LiBJbiBjYXNlcyB3aGVyZSBvcHRpb25zIGFyZSBpbnRlcnByZXRlZCBieSB0cmFuc2l0 IGRldmljZXMsIHRoZSBvcGVyYXRvciBNVVNUIGVuc3VyZSB0aGF0IHRyYW5zaXQgZGV2aWNlcw0K IGFyZSB0cnVzdGVkIGFuZCBub3QgY29tcHJvbWlzZWQuIEltcGxlbWVudGF0aW9uIG9mIGEgbWVj aGFuaXNtIHRvIGVuc3VyZSB0aGlzIHRydXN0IGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBk b2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlBsZWFzZSBsZXQg dXMga25vdyBpZiB0aGlzIGFkZHJlc3NlcyB5b3VyIGNvbW1lbnQgb24gMy41LjEuICZuYnNwO1Ro ZSBvdGhlciB0d28gY29tbWVudHMgaGF2ZSBiZWVuIHNhdGlzZmllZCBhcyBub3RlZCBiZWxvdy4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5JbGFuZ288bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfX19fX3JlcGx5c2VwYXJhdG9yIj48L2E+PGI+ RnJvbTo8L2I+IE1hZ251cyBOeXN0csO2bSBbbWFpbHRvOm1hZ251c25AZ21haWwuY29tXQ0KPGJy Pg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgT2N0b2JlciAzMSwgMjAxOCAxMTozNCBBTTxicj4N CjxiPlRvOjwvYj4gR2FuZ2EsIElsYW5nbyBTICZsdDtpbGFuZ28ucy5nYW5nYUBpbnRlbC5jb20m Z3Q7OyBzZWNkaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbnZvMy1nZW5ldmVAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFNlY2RpciByZXZpZXcgKGVhcmx5IHJldmlldykgb2YgZHJh ZnQtaWV0Zi1udm8zLWdlbmV2ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGkgSWxhbmdvLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIDMu NCwgSSB0aGluayB0aGlzIG1heSBiZSBzdWZmaWNpZW50LiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Rm9yIDYuMiwgSSB3aWxsIGRlZmVyIHRvIHRoZSBJRVRGIGRpcmVjdG9yL3RlbGVjaGF0IGRp c2N1c3Npb24gdGhhdCB3aWxsIG9jY3VyIGF0IHNvbWUgcG9pbnQgZm9yIHRoaXMgZHJhZnQuIElm IHRoZSBpbnRlbnQgaXMgaW50ZXJvcGVyYWJpbGl0eSBhbmQgcm9idXN0bmVzcyBvZiBzdWNoIGFu IG9wdGlvbiwgdGhlbiBJIHdvdWxkIHJlY29tbWVuZCBpdCB0byBiZSBzcGVjaWZpZWQgaW4gdGhl IElFVEYsIGJ1dA0KIEkgY2FuIGFsc28gc2VlIGhvdyB5b3Ugd291bGQgcHJlZmVyIHRoYXQgc3Vj aCBzcGVjaWZpY2F0aW9uIHdvcmsgb2NjdXJzIG91dHNpZGUgdGhpcyBwYXJ0aWN1bGFyIGRyYWZ0 IOKAkyB3aGljaCBzaG91bGQgYmUgZG9hYmxlLiBQZXJoYXBzIHN0YXlpbmcgc2lsZW50IG9uIHRo ZSBvcHRpb24gYWx0ZXJuYXRpdmUgYW5kIGp1c3QgcmVjb21tZW5kIGxldmVyYWdpbmcgbGF5ZXIt cHJvdmlkZWQgaW5mcmFzdHJ1Y3R1cmUgc3VjaCBhcyBpcHNlYyBtYXkgYmUNCiBiZXN0IGZvciBu b3c/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbGwgYXdhaXQgeW91ciBzdWdnZXN0ZWQgdXBk YXRlZCBsYW5ndWFnZSBmb3IgMy41LjEuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VudCBmcm9tIG15IFdpbmRvd3MgMTAgcGhvbmU8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTog PC9iPjxhIGhyZWY9Im1haWx0bzppbGFuZ28ucy5nYW5nYUBpbnRlbC5jb20iPkdhbmdhLCBJbGFu Z28gUzwvYT48YnI+DQo8Yj5TZW50OiA8L2I+VHVlc2RheSwgT2N0b2JlciAzMCwgMjAxOCAxODox Mjxicj4NCjxiPlRvOiA8L2I+PGEgaHJlZj0ibWFpbHRvOm1hZ251c25AZ21haWwuY29tIj5NYWdu dXMgTnlzdHLDtm08L2E+OyA8YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIj4NCnNlY2Rp ckBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW52bzMtZ2VuZXZlQGll dGYub3JnIj5kcmFmdC1pZXRmLW52bzMtZ2VuZXZlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1Ympl Y3Q6IDwvYj5SRTogU2VjZGlyIHJldmlldyAoZWFybHkgcmV2aWV3KSBvZiBkcmFmdC1pZXRmLW52 bzMtZ2VuZXZlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkhpIE1hZ251cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPlRoYW5rcyBmb3IgeW91ciByZXZpZXcgYW5kIGZlZWRiYWNrLiBQbGVhc2Ugc2VlIGlubGlu ZSBmb3IgbXkgcmVzcG9uc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SWxhbmdvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj5Gcm9tOjwvYj4gTWFnbnVzIE55c3Ryw7ZtIFs8YSBocmVmPSJtYWlsdG86bWFnbnVz bkBnbWFpbC5jb20iPm1haWx0bzptYWdudXNuQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gVHVlc2RheSwgT2N0b2JlciAyMywgMjAxOCA5OjAxIFBNPGJyPg0KPGI+VG86PC9iPiA8 YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0Zi5vcmc8L2E+OyA8YSBo cmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1udm8zLWdlbmV2ZUBpZXRmLm9yZyI+DQpkcmFmdC1pZXRm LW52bzMtZ2VuZXZlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBTZWNkaXIgcmV2 aWV3IChlYXJseSByZXZpZXcpIG9mIGRyYWZ0LWlldGYtbnZvMy1nZW5ldmU8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyxzZXJpZiI+SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2Vj dXJpdHkgZGlyZWN0b3JhdGUnczxicj4NCm9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVU RiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZTxicj4NCklFU0cuIFRoZXNlIGNvbW1l bnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZTxicj4NCnNl Y3VyaXR5IGFyZWEgZGlyZWN0b3JzLiZuYnNwOyBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFp cnMgc2hvdWxkIHRyZWF0PGJyPg0KdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBs YXN0IGNhbGwgY29tbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmIj5UaGlzIGRvY3VtZW50IGRlc2NyaWJlcyAmcXVvdDtHZW5ldmUsJnF1b3Q7IGEgcHJvdG9j b2wgZm9yIEdFbmVyaWMgTkV0d29yayBWaXJ0dWFsaXphdGlvbiBFbmNhcHN1bGF0aW9uLiBUaGUg ZG9jdW1lbnQgaXMgd3JpdHRlbiBpbiBhIGNsZWFyIG1hbm5lciBhbmQgd2l0aCBhIHRob3JvdWdo IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQogc2VjdGlvbi4gSSBoYXZlIGp1c3QgYSBmZXcgcXVl c3Rpb25zL2NvbW1lbnRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj4tIFNlY3Rpb24gMy40OiBUaGUgJnF1b3Q7TVVTVCBpZ25vcmUmcXVvdDsgZm9y IHRoZSByZXNlcnZlZCBiaXRzIHNob3VsZCBwcmVzdW1hYmx5IHN0YXRlICZxdW90O1NIQUxMIGJl IGlnbm9yZWQgZm9yIHRoaXMgdmVyc2lvbiBvZiB0aGUgR2VuZXZlIHByb3RvY29sLiZxdW90OyAt IGFzIEkgaW1hZ2luZSB0aGF0IGluIGEgZnV0dXJlDQogdmVyc2lvbiwgdGhlc2UgYml0cyBtYXkg bm90IGJlIGlnbm9yZWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbHQ7 SWxhbmdvJmd0OyBJbiB0aGVvcnksIGEgZnV0dXJlIHZlcnNpb24gbWF5IGNoYW5nZSB0aGUgYmVo YXZpb3Igb2YgYW55IG9mIHRoZSBoZWFkZXIgZmllbGRzIGluY2x1ZGluZyB0aGUgcmVzZXJ2ZWQg Yml0cy4gJm5ic3A7VGhlIGhlYWRlciBkZWZpbml0aW9uIGlzIGZvciB0aGlzIHZlcnNpb24gb2Yg dGhlIHByb3RvY29sLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UGxlYXNl IHNlZSBpZiB0aGUgZm9sbG93aW5nIHRleHQgd291bGQgc2F0aXNmeSB0aGUgaW50ZW50IG9mIHlv dXIgY29tbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFG NDk3RCI+4oCcUmVzZXJ2ZWQgZmllbGQgd2hpY2ggTVVTVCBiZSB6ZXJvIG9uIHRyYW5zbWlzc2lv biBhbmQNCjwvc3Bhbj48dT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6IzAwQjA1MCI+TVVTVCBiZTwvc3Bhbj48L3U+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiBpZ25vcmVk IG9uIHJlY2VpcHQu4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5PciBsZXQgdXMga25vdyBpZiB5b3Ugc3Rp bGwgd2FudCB0byBoYXZlIHRoaXMgcXVhbGlmaWVkIHdpdGgg4oCcZm9yIHRoaXMgdmVyc2lvbiBv ZiB0aGUgcHJvdG9jb2zigJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmx0Oy8mZ3Q7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LSBTZWN0aW9uIDMuNS4xOiBJIHdvbmRlciBh Ym91dCB0aGUgc2ltdWx0YW5lb3VzIHJlcXVpcmVtZW50IHRoYXQgb25lIG9wdGlvbiBtdXN0IG5v dCBhZmZlY3QgdGhlIHBhcnNpbmcgb3IgaW50ZXJwcmV0YXRpb24gb2YgYW5vdGhlciBvcHRpb24g YnV0IHRoYXQgdGhlIHNlcXVlbmNpbmcgKG9yZGVyKQ0KIG9mIG9wdGlvbnMgbWF5IGJlIHNpZ25p ZmljYW50IC0gdGhleSBzZWVtIHRvIGJlIGNvbnRyYWRpY3Rvcnkgc2luY2UgaWYgdGhlIHNlcXVl bmNpbmcgKmlzKiBzaWduaWZpY2FudCwgdGhlbiBzb21lIG9wdGlvbiBtdXN0IGJlIGltcGFjdGVk IGJ5IGEgcHJldmlvdXMgb25lJ3MgdmFsdWU/IEZyb20gYSBzZWN1cml0eSBwZXJzcGVjdGl2ZSwg SSBhbHNvIHdvbmRlciBpZiB0aGVyZSBjb3VsZCBiZSBzZWN1cml0eSBjb25zZXF1ZW5jZXMgb2Yg cmUtb3JkZXJpbmcNCiBvcHRpb25zIChhbmQgaG93IHRvIHRlbGwgaWYgc29tZW9uZSBkaWQgcmUt b3JkZXIgLSBzZWUgYmVsb3cpPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jmx0O0lsYW5nbyZndDsgWW91IHJhaXNlIGEgZ29vZCBwb2ludC4gVGhlIGludGVudCBvZiB0aGlz IHN0YXRlbWVudCBpcywgcGFyc2luZyBhbmQgaW50ZXJwcmV0YXRpb24gb2Ygb3B0aW9ucyBzaG91 bGQgbm90IGJlIGRlcGVuZGVudCBvbiBvbmUgYW5vdGhlci4gV2UgYXJlIGRpc2N1c3NpbmcgYW1v bmcgdGhlIGF1dGhvcnMgdG8gc2VlIGhvdyB3ZSBjYW4gaW5jbHVkZSBhcHByb3ByaWF0ZQ0KIGNs YXJpZnlpbmcgc3RhdGVtZW50cyB0byBhZGRyZXNzIHlvdXIgcG9pbnQuIEkgd2lsbCB1cGRhdGUg eW91IHNob3J0bHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZsdDsvJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi0gU2VjdGlvbiA2LjIsIHNob3VsZG4ndCBzdWNoIGFu IE9wdGlvbiBiZSBkZWZpbmVkIHRvIHJlZHVjZSB0aGUgcmlzayBvZiB1bmRlci1zcGVjaWZpZWQg b3Igc3VicGFyIHNwZWNpZmljYXRpb25zIG9mIHN1Y2ggaW50ZWdyaXR5IG1lY2hhbmlzbXM/IE9y IGFsc28gZnJvbSBhbiBpbnRlcm9wIHBlcnNwZWN0aXZlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jmx0O0lsYW5nbyZndDsgVXNpbmcgYSBHZW5ldmUgb3B0aW9uIGZvciB0 aGUgcHVycG9zZSBvZiBkYXRhIGludGVncml0eSBpcyBtb3JlIG9mIGFuIG9wdGltaXphdGlvbi4g T3RoZXJ3aXNlIGRhdGEgaW50ZWdyaXR5IGNvdWxkIGJlIHByb3ZpZGVkIGJ5IHVzaW5nIGV4aXN0 aW5nIG1lY2hhbmlzbXMgbGlrZSBJUHNlYyAoYXMgc3RhdGVkIGluIHNlY29uZCBwYXJhZ3JhcGgg b2YNCiA2LjIpLiBXZSBpbmNsdWRlZCB0aGUgbGFzdCBwYXJhZ3JhcGggdG8gc2hvdyBvdGhlciBw b3NzaWJpbGl0aWVzLiBXZSBjb3VsZCByZW1vdmUgdGhpcyBwYXJhZ3JhcGggaWYgaXQgbWF5IGNh dXNlIGFueSBjb25mdXNpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5X ZSB3b3VsZCBsaWtlIHRvIGtlZXAgdGhlIEdlbmV2ZSBiYXNlIHNwZWNpZmljYXRpb24gaW5kZXBl bmRlbnQgb2Ygb3B0aW9ucyBzcGVjaWZpY2F0aW9ucywgb3B0aW9ucyBjb3VsZCBiZSBhIGRlZmlu ZWQgaW4gYSBmdXR1cmUgc3RhbmRhcmRzIGFjdGlvbi4gJm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZs dDsvJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyxzZXJpZiI+VGhhbmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi0t IE1hZ251czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_C5A274B25007804B800CB5B289727E3583D11BB5ORSMSX116amrcor_-- From nobody Tue Nov 6 22:14:40 2018 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 319E4130E74; Tue, 6 Nov 2018 21:28:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1541568487; bh=rqG6qJbtJdHd7Slly3c+6UMyxDhGTZdHBCkkdPUQUaI=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=JTA9Xy/Ug6iGngMBNCr5SgBRr38YXqd0KSzaNleLujrJOaQSpyCULQlqKFdALNkME k1VKGMaFMwkQPgS057jgRvQRz3FfNjZeRtgZkafYLOvC+eMoMls4p5rCC9wNmEHovg Zo69ZXCWYZ2TTmvKcozX0qotUuhsZf2fjEEFsifM= X-Mailbox-Line: From new-work-bounces@ietf.org Tue Nov 6 21:28:06 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B49130E5B; Tue, 6 Nov 2018 21:28:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1541568486; bh=rqG6qJbtJdHd7Slly3c+6UMyxDhGTZdHBCkkdPUQUaI=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=VWriSCgcxlfc5EkecgNi7Mmi0umTjpUh2g1lnTkjXaZvTPuHlMNR8C1r06A6yNRcZ 8jPY8N1DCD4Q+lS0j/u1YNleho7tEU7XcP/3JDg9GuZGIkXTnQPPX4fTXQE8J64B9Z MRYZtZlkdhygA00w+u+604xc3eomwMN2RPYnCBVk= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61593130E5B for ; Tue, 6 Nov 2018 21:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e55KrMy4z-6Y for ; Tue, 6 Nov 2018 21:28:03 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 236DF127333 for ; Tue, 6 Nov 2018 21:28:03 -0800 (PST) Received: from [113.0.65.219] (helo=[192.168.1.175]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1gKGNl-00035X-5j for new-work@ietf.org; Wed, 07 Nov 2018 05:28:01 +0000 To: new-work@ietf.org From: xueyuan Message-ID: <23a4c928-4e72-52f3-18c8-ba6cfd524b7d@w3.org> Date: Wed, 7 Nov 2018 13:27:58 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 06 Nov 2018 22:14:39 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Browser Testing and Tools Working Group (until 2018-12-07) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 05:28:10 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgQnJvd3Nl ciBUZXN0aW5nIGFuZCBUb29scyBXb3JraW5nIEdyb3VwOgogwqAgaHR0cHM6Ly93d3cudzMub3Jn LzIwMTgvMTEvYnJvd3Nlci10ZXN0aW5nLXRvb2xzLmh0bWwKCkFzIHBhcnQgb2YgZW5zdXJpbmcg dGhhdCB0aGUgY29tbXVuaXR5IGlzIGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsKYXQgVzNDLCB0aGlz IGRyYWZ0IGNoYXJ0ZXIgaXMgcHVibGljIGR1cmluZyB0aGUgQWR2aXNvcnkKQ29tbWl0dGVlIHJl dmlldyBwZXJpb2QuCgpXM0MgaW52aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAyMDE4LTEy LTA3IG9uIHRoZQpwcm9wb3NlZCBjaGFydGVyLiBQbGVhc2Ugc2VuZCBjb21tZW50cyB0bwpwdWJs aWMtbmV3LXdvcmtAdzMub3JnLCB3aGljaCBoYXMgYSBwdWJsaWMgYXJjaGl2ZToKIMKgIGh0dHA6 Ly9saXN0cy53My5vcmcvQXJjaGl2ZXMvUHVibGljL3B1YmxpYy1uZXctd29yay8KCk90aGVyIHRo YW4gY29tbWVudHMgc2VudCBpbiBmb3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZpc29yeQpDb21t aXR0ZWUgUmVwcmVzZW50YXRpdmVzLCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJlc3BvbnNlIHRv CmNvbW1lbnRzLiBJZiB5b3Ugd29yayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNvb3Jk aW5hdGUKeW91ciBjb21tZW50cyB3aXRoIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2Vu dGF0aXZlLiBGb3IKZXhhbXBsZSwgeW91IG1heSB3aXNoIHRvIG1ha2UgcHVibGljIGNvbW1lbnRz IHZpYSB0aGlzIGxpc3QgYW5kCmhhdmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50 YXRpdmUgcmVmZXIgdG8gaXQgZnJvbSBoaXMKb3IgaGVyIGZvcm1hbCByZXZpZXcgY29tbWVudHMu CgpJZiB5b3Ugc2hvdWxkIGhhdmUgYW55IHF1ZXN0aW9ucyBvciBuZWVkIGZ1cnRoZXIgaW5mb3Jt YXRpb24sIHBsZWFzZQpjb250YWN0IE1pY2hhZWwgU21pdGgsIGF0IDxtaWtlQHczLm9yZz4sIFRl YW0gQ29udGFjdCBmb3IgdGhlCkJyb3dzZXIgVGVzdGluZyBhbmQgVG9vbHMgV29ya2luZyBHcm91 cC4KClRoYW5rIHlvdSwKClh1ZXl1YW4gSmlhLCBXM0MgTWFya2V0aW5nICYgQ29tbXVuaWNhdGlv bnMKClsxXSBodHRwOi8vd3d3LnczLm9yZy9Db25zb3J0aXVtL01lbWJlci9MaXN0CgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXctd29yayBtYWlsaW5n IGxpc3QKbmV3LXdvcmtAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXctd29yawo= From nobody Tue Nov 6 23:20:10 2018 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 8F6A912D4E6; Tue, 6 Nov 2018 23:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 m8_JUCl42ELK; Tue, 6 Nov 2018 23:20:00 -0800 (PST) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 9E242127333; Tue, 6 Nov 2018 23:20:00 -0800 (PST) Received: by mail-pf1-x433.google.com with SMTP id v9-v6so5028780pff.2; Tue, 06 Nov 2018 23:20:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D4HIz/GVcmb8YIqtPZ0SrnXnu3HZVrJkhcrbZymARDU=; b=gIzsIj4GDnOAyVZ3y6qSMBXb3S3IisK+UW5GGrtMuEmPhR02jnrnpjA5b0gNSqA3zq 9NRC7vgur+5pj+hFR5Amrb/0Ez1wz+D4V9328FHWqbPBw+FUv9UeKEJVZJabA9Ch1NA1 2wQd7G7FAFYPSicTfI9w77T48mnFs01nk09snB2lPdsZl1BM8fWNcpah1IbQkz3h2/iH yk5GdIG0rYZxIMejcEVuFBNe1F3clfCSlDYHx2fI2IX57H7ieGwQXdVgThd2XzYVMdKi RrSyePKavYuaW1fbiTUmnrquiBHZT3atI2TewG2TTzQxcqYza3KqSL0+h4ciNMIkPIkk ljhg== 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=D4HIz/GVcmb8YIqtPZ0SrnXnu3HZVrJkhcrbZymARDU=; b=cJNivbRzURm6Jl8Af7TDYYOwm9QCuuxPNC9cVrUTWmhByn2wjw4EGE8mII9hqbT28Y gweuMEyDmpuVCG4eLXYs/tWwUDg/e59/KZQFCVyCMpWAM6MEIcvg/t8RLsUCPo1F9S1N Mb3kkOcUFdn4v8PdaRiPt4/NMwWILxhnG7wMMq3ZDAW3okRDNEjmUysL99Sf62s+TGeT d8AsMG/XSGXUiaduqICmVWKL6py05m9ILC/ZzcZS/TLkihrdkBVlA0TYM3rjHxwrMyG7 YPRixAliEhlFrs2nFIGbulbmiP/P296sJmPwF5P3cVISUJFOG//PvkE2RlmQSYKITDHK zAUg== X-Gm-Message-State: AGRZ1gLI8KYs6BaIo9mMh/OakXbrnpuB+BzbyDEA60bjepHTPTZ/kb5W G9g4OJB+JrBdPxkdICpbNqP0zTBUj8apeNsJa0E= X-Google-Smtp-Source: AJdET5cbX/1WysqV7+a7urlzg/Hll+WHAsm1uF5RwGKZUEZ/QLYhIDB22LOx9+9yyC+c6dA6JcqSyWdQvkchwzQCJ1Y= X-Received: by 2002:a63:1904:: with SMTP id z4mr642827pgl.135.1541575200120; Tue, 06 Nov 2018 23:20:00 -0800 (PST) MIME-Version: 1.0 References: <5bd9f599.1c69fb81.4fed7.d7cd@mx.google.com> In-Reply-To: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Tue, 6 Nov 2018 23:19:49 -0800 Message-ID: To: "Ganga, Ilango S" Cc: secdir@ietf.org, draft-ietf-nvo3-geneve@ietf.org Content-Type: multipart/alternative; boundary="00000000000032a31d057a0df2db" Archived-At: Subject: Re: [secdir] Secdir review (early review) of draft-ietf-nvo3-geneve 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, 07 Nov 2018 07:20:04 -0000 --00000000000032a31d057a0df2db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ilango, Thanks for your thorough follow-up. To me, the new text looks very good. You could shorten (and perhaps add clarity) by replacing "Hence an option..." with just "An option ..." Thanks, /M On Tue, Nov 6, 2018 at 7:11 PM Ganga, Ilango S wrote: > Hi Magnus, > > > > Here is our proposed text that we believe will satisfy your comment on > 3.5.1: > > > > *In Section 2.2.1 add new highlighted text in paragraph that began with > =E2=80=9CTransit devices..=E2=80=9D* > > Options, if present in the packet, MUST be generated and terminated by en= d > points. Transit devices MAY be able to interpret the options, however, as > > non-terminating devices, transit devices do not originate or > > terminate the Geneve packet, hence MUST NOT insert or delete options, > > which is the responsibility of Geneve endpoints. The participation > > of transit devices in interpreting options is OPTIONAL. > > > > > > *Section 3.5.1 - Remove the highlighted text:* > > o Some options may be defined in such a way that the position in the > > option list is significant. Options or their ordering, MUST NOT > > be changed by transit devices. > > > > *Section 3.5.1 - Add highlighted text to the last bullet:* > > o *An option SHOULD NOT be dependent upon any other option in the > packet, * > > * i.e., options can be processed independent of one another. Hence* an > option MUST NOT affect the parsing or interpretation of any other option. > > > > *Remove the following paragraph from 6.2:* > > Geneve supports Geneve Options, so an operator may choose to use a > > Geneve option TLV to provide a cryptographic data protection > > mechanism, to verify the data integrity of the Geneve header, Geneve > > options or the entire Geneve packet including the payload. > > Implementation of such a mechanism is beyond the scope of this > > document. > > > > *Introduce new section after 6.3 as follows:* > > 6.4 Options Interpretation by Transit Devices > > > > Options, if present in the packet, are generated and terminated by end > points. As indicated in 2.2.1, transit devices may interpret the options. > However, if the packet is protected by end point to end point encryption, > for example through IPsec, transit devices will not have visibility into > the Geneve header or options in the packet. In cases where options are > interpreted by transit devices, the operator MUST ensure that transit > devices are trusted and not compromised. Implementation of a mechanism to > ensure this trust is beyond the scope of this document. > > > > Please let us know if this addresses your comment on 3.5.1. The other tw= o > comments have been satisfied as noted below. > > > > Thanks, > > Ilango > > > > > > *From:* Magnus Nystr=C3=B6m [mailto:magnusn@gmail.com] > *Sent:* Wednesday, October 31, 2018 11:34 AM > *To:* Ganga, Ilango S ; secdir@ietf.org; > draft-ietf-nvo3-geneve@ietf.org > *Subject:* RE: Secdir review (early review) of draft-ietf-nvo3-geneve > > > > Hi Ilango, > > For 3.4, I think this may be sufficient. > > > > For 6.2, I will defer to the IETF director/telechat discussion that will > occur at some point for this draft. If the intent is interoperability and > robustness of such an option, then I would recommend it to be specified i= n > the IETF, but I can also see how you would prefer that such specification > work occurs outside this particular draft =E2=80=93 which should be doabl= e. Perhaps > staying silent on the option alternative and just recommend leveraging > layer-provided infrastructure such as ipsec may be best for now? > > > > I'll await your suggested updated language for 3.5.1. > > > > Thanks, > > > > Sent from my Windows 10 phone > > > > *From: *Ganga, Ilango S > *Sent: *Tuesday, October 30, 2018 18:12 > *To: *Magnus Nystr=C3=B6m ; secdir@ietf.org; > draft-ietf-nvo3-geneve@ietf.org > *Subject: *RE: Secdir review (early review) of draft-ietf-nvo3-geneve > > > > Hi Magnus, > > > > Thanks for your review and feedback. Please see inline for my responses. > > > > Regards, > > Ilango > > > > > > *From:* Magnus Nystr=C3=B6m [mailto:magnusn@gmail.com = ] > *Sent:* Tuesday, October 23, 2018 9:01 PM > *To:* secdir@ietf.org; draft-ietf-nvo3-geneve@ietf.org > *Subject:* Secdir review (early review) of draft-ietf-nvo3-geneve > > > > 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 "Geneve," a protocol for GEneric NEtwork > Virtualization Encapsulation. The document is written in a clear manner a= nd > with a thorough Security Considerations section. I have just a few > questions/comments: > > > > - Section 3.4: The "MUST ignore" for the reserved bits should presumably > state "SHALL be ignored for this version of the Geneve protocol." - as I > imagine that in a future version, these bits may not be ignored? > > > > In theory, a future version may change the behavior of any of th= e > header fields including the reserved bits. The header definition is for > this version of the protocol. > > > > Please see if the following text would satisfy the intent of your comment= . > > =E2=80=9CReserved field which MUST be zero on transmission and *MUST be* = ignored > on receipt.=E2=80=9D > > > > Or let us know if you still want to have this qualified with =E2=80=9Cfor= this > version of the protocol=E2=80=9D > > > > > > - Section 3.5.1: I wonder about the simultaneous requirement that one > option must not affect the parsing or interpretation of another option bu= t > that the sequencing (order) of options may be significant - they seem to = be > contradictory since if the sequencing *is* significant, then some option > must be impacted by a previous one's value? From a security perspective, = I > also wonder if there could be security consequences of re-ordering option= s > (and how to tell if someone did re-order - see below)? > > > > You raise a good point. The intent of this statement is, parsing > and interpretation of options should not be dependent on one another. We > are discussing among the authors to see how we can include appropriate > clarifying statements to address your point. I will update you shortly. > > > > > > - Section 6.2, shouldn't such an Option be defined to reduce the risk of > under-specified or subpar specifications of such integrity mechanisms? Or > also from an interop perspective? > > > > Using a Geneve option for the purpose of data integrity is more > of an optimization. Otherwise data integrity could be provided by using > existing mechanisms like IPsec (as stated in second paragraph of 6.2). We > included the last paragraph to show other possibilities. We could remove > this paragraph if it may cause any confusion. > > > > We would like to keep the Geneve base specification independent of option= s > specifications, options could be a defined in a future standards action. > > > > > > > > Thanks. > > -- Magnus > > > --=20 -- Magnus --00000000000032a31d057a0df2db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ilango,
Thanks for your thorough follow-= up. To me, the new text looks very good. You could shorten (and perhaps add= clarity) by replacing "Hence an option..." with just "An op= tion ..."

Thanks,
/M
<= /div>
On Tue, Nov 6, 2018 at= 7:11 PM Ganga, Ilango S <il= ango.s.ganga@intel.com> wrote:

Hi Magnus,

=C2=A0

Here is our proposed t= ext that we believe will satisfy your comment on 3.5.1:

=C2=A0

In Section 2.2.1 ad= d new highlighted text in paragraph that began with =E2=80=9CTransit device= s..=E2=80=9D

Options, if present in the packet, MUST be generated and term= inated by end points. Transit devices MAY be able to interpret the options,= however, as

=C2=A0=C2=A0 non-terminating devices, transit devices do not = originate or

=C2=A0=C2=A0 terminate the Geneve packet, hence MUST NOT inse= rt or delete options,

=C2=A0=C2=A0 which is the responsibility of Geneve endpoints.= =C2=A0 The participation

=C2=A0=C2=A0 of transit devices in interpreting options is OP= TIONAL.

=C2=A0

=C2=A0

Section 3.5.1 - Rem= ove the highlighted text:

o=C2=A0 Some options may be defined in such a way that the po= sition in the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 option list is significant.=C2= =A0 Options or = their ordering, MUST NOT

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 be changed by transit devices.=

=C2=A0

Section 3.5.1 - Add= highlighted text to the last bullet:

=C2=A0=C2=A0 o=C2=A0 An opt= ion SHOULD NOT be dependent upon any other option in the packet,

=C2=A0i.e., options can be processed independent of one an= other. Hence an option MUST NOT affect the parsing or interpretation of any other option.

=C2=A0

Remove the followin= g paragraph from 6.2:

Geneve supports Geneve Options, so an operator may choose = to use a

=C2=A0=C2=A0 Geneve option TLV to provide a cryptographic = data protection

=C2=A0=C2=A0 mechanism, to verify the data integrity of th= e Geneve header, Geneve

=C2=A0=C2=A0 options or the entire Geneve packet including= the payload.

=C2=A0=C2=A0 Implementation of such a mechanism is beyond = the scope of this

=C2=A0=C2=A0 document.

<= span style=3D"color:#1f497d">=C2=A0

Introduce new secti= on after 6.3 as follows:

6.4=C2=A0 Options Interpretation by Transit Devices=

=C2=A0

Options, if present in the packet, are generated and terminat= ed by end points. As indicated in 2.2.1, transit devices may interpret the = options. However, if the packet is protected by end point to end point encryption, for example through IPsec, transit devi= ces will not have visibility into the Geneve header or options in the packe= t. In cases where options are interpreted by transit devices, the operator = MUST ensure that transit devices are trusted and not compromised. Implementation of a mechanism to ensure t= his trust is beyond the scope of this document.

=C2=A0

Please let us know if = this addresses your comment on 3.5.1.=C2=A0 The other two comments have bee= n satisfied as noted below.

=C2=A0

Thanks,<= /span>

Ilango

=C2=A0

=C2=A0

From: Magnus Nystr=C3=B6m [mailto:magnusn@gmail.com]
Sent: Wednesday, October 31, 2018 11:34 AM
To: Ganga, Ilango S <ilango.s.ganga@intel.com>; secdir@ietf.org; draft-ietf-nvo3-geneve@ietf.or= g
Subject: RE: Secdir review (early review) of draft-ietf-nvo3-geneve<= u>

=C2=A0

Hi Ilango,

For 3.4, I think this may be sufficient. <= /u>

=C2=A0

For 6.2, I will defer to the IETF director/telechat = discussion that will occur at some point for this draft. If the intent is i= nteroperability and robustness of such an option, then I would recommend it= to be specified in the IETF, but I can also see how you would prefer that such specification work occurs ou= tside this particular draft =E2=80=93 which should be doable. Perhaps stayi= ng silent on the option alternative and just recommend leveraging layer-pro= vided infrastructure such as ipsec may be best for now?

=C2=A0

I'll await your suggested updated language for 3= .5.1.

=C2=A0

Thanks,

=C2=A0

Sent from my Windows 10 phone

=C2=A0

From: Ganga, Ilango S
Sent: Tuesday, October 30, 2018 18:12
To: Magnus Ny= str=C3=B6m; secdir@ietf.org; draft-ietf-nvo3-geneve@ietf.org
Subject: RE: Secdir review (early review) of draft-ietf-nvo3-geneve<= u>

=C2=A0

Hi Magnus,

=C2=A0

Thanks for your review= and feedback. Please see inline for my responses.

=C2=A0

Regards,=

Ilango

=C2=A0

=C2=A0

From: Magnus Nystr=C3=B6m [mailto:magnusn@gmail.com]
Sent: Tuesday, October 23, 2018 9:01 PM
To: secdir@ietf= .org; draft-ietf-nvo3-geneve@ietf.org
Subject: Secdir review (early review) of draft-ietf-nvo3-geneve

=C2=A0

I have reviewed this document as part of the sec= urity 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.=C2=A0 Document editors and WG chairs should treat<= br> these comments just like any other last call comments.=

=C2=A0

This document describes "Geneve," a pr= otocol for GEneric NEtwork Virtualization Encapsulation. The document is wr= itten in a clear manner and with a thorough Security Considerations section. I have just a few questions/comments:

=C2=A0

- Section 3.4: The "MUST ignore" for t= he reserved bits should presumably state "SHALL be ignored for this ve= rsion of the Geneve protocol." - as I imagine that in a future version, these bits may not be ignored?

=C2=A0

<Ilango> In theo= ry, a future version may change the behavior of any of the header fields in= cluding the reserved bits.=C2=A0 The header definition is for this version = of the protocol.

=C2=A0

Please see if the foll= owing text would satisfy the intent of your comment.

=E2=80=9CReserved field which MUST be zero on transmission an= d MUST be ignored on receipt.=E2=80=9D

=C2=A0

Or let us know if you = still want to have this qualified with =E2=80=9Cfor this version of the pro= tocol=E2=80=9D

</>

=C2=A0

- Section 3.5.1: I wonder about the simultaneous= requirement that one option must not affect the parsing or interpretation = of another option but that the sequencing (order) of options may be significant - they seem to be contradictory since if the= sequencing *is* significant, then some option must be impacted by a previo= us one's value? From a security perspective, I also wonder if there cou= ld be security consequences of re-ordering options (and how to tell if someone did re-order - see below)?

=C2=A0

<Ilango> You rai= se a good point. The intent of this statement is, parsing and interpretatio= n of options should not be dependent on one another. We are discussing amon= g the authors to see how we can include appropriate clarifying statements to address your point. I will update you shortly.=

</>

=C2=A0

- Section 6.2, shouldn't such an Option be d= efined to reduce the risk of under-specified or subpar specifications of su= ch integrity mechanisms? Or also from an interop perspective?=

=C2=A0

<Ilango> Using a= Geneve option for the purpose of data integrity is more of an optimization= . Otherwise data integrity could be provided by using existing mechanisms l= ike IPsec (as stated in second paragraph of 6.2). We included the last paragraph to show other possibilities. We could= remove this paragraph if it may cause any confusion.<= /p>

=C2=A0

We would like to keep = the Geneve base specification independent of options specifications, option= s could be a defined in a future standards action. =C2=A0

</>

=C2=A0

=C2=A0

Thanks.

-- Magnus

=C2=A0



--
-- Magnus
--00000000000032a31d057a0df2db-- From nobody Wed Nov 7 11:30:25 2018 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 B1D1B1200D7; Wed, 7 Nov 2018 11:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cggH8QyPebVT; Wed, 7 Nov 2018 11:30:21 -0800 (PST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) (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 4B0E3127B92; Wed, 7 Nov 2018 11:30:18 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Nov 2018 11:30:18 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.54,476,1534834800"; d="scan'208,217"; a="87460854" Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129]) by orsmga007.jf.intel.com with ESMTP; 07 Nov 2018 11:30:18 -0800 Received: from orsmsx153.amr.corp.intel.com (10.22.226.247) by ORSMSX102.amr.corp.intel.com (10.22.225.129) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 7 Nov 2018 11:30:18 -0800 Received: from orsmsx116.amr.corp.intel.com ([169.254.7.124]) by ORSMSX153.amr.corp.intel.com ([169.254.12.54]) with mapi id 14.03.0415.000; Wed, 7 Nov 2018 11:30:17 -0800 From: "Ganga, Ilango S" To: =?utf-8?B?TWFnbnVzIE55c3Ryw7Zt?= CC: "secdir@ietf.org" , "draft-ietf-nvo3-geneve@ietf.org" , "nvo3-chairs@ietf.org" Thread-Topic: Secdir review (early review) of draft-ietf-nvo3-geneve Thread-Index: AQHUa05O1lkJPkWghUmTeaMFlyPdI6U4khKAgAGdQICACXZEUIAA3nKAgABDMiA= Date: Wed, 7 Nov 2018 19:30:17 +0000 Message-ID: References: <5bd9f599.1c69fb81.4fed7.d7cd@mx.google.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMGMyNDEyMzctOThjZC00NjQ5LTk4MTUtM2VmZDI2YjQ5Y2FhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiXC81cDkzVDRYVVR5Ullrejc2QkkwVjJ3WXI1azhIZ1dFYVV3MkU1eXpnSVwvTGFqSVdqbHFvUDBZb0t2UzJmd2o5In0= x-ctpclassification: CTP_NT x-originating-ip: [10.22.254.139] Content-Type: multipart/alternative; boundary="_000_C5A274B25007804B800CB5B289727E3583D123C0ORSMSX116amrcor_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir review (early review) of draft-ietf-nvo3-geneve 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, 07 Nov 2018 19:30:24 -0000 --_000_C5A274B25007804B800CB5B289727E3583D123C0ORSMSX116amrcor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFnbnVzLA0KVGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgZmVlZGJhY2suIFdlIGhhdmUg YWRkcmVzc2VkIGFsbCAzIG9mIHlvdXIgY29tbWVudHMuIFdlIHdpbGwgYmUgdXBkYXRpbmcgdGhl IGRyYWZ0IHRvIGFkZHJlc3MgdGhlc2UgYW5kIFdHIExDIGNvbW1lbnRzLCBpbiB0aGUgbmV4dCB3 ZWVrIG9yIHR3by4NClJlZ2FyZHMsDQpJbGFuZ28NCg0KRnJvbTogTWFnbnVzIE55c3Ryw7ZtIFtt YWlsdG86bWFnbnVzbkBnbWFpbC5jb21dDQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciA2LCAyMDE4 IDExOjIwIFBNDQpUbzogR2FuZ2EsIElsYW5nbyBTIDxpbGFuZ28ucy5nYW5nYUBpbnRlbC5jb20+ DQpDYzogc2VjZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLW52bzMtZ2VuZXZlQGlldGYub3JnDQpT dWJqZWN0OiBSZTogU2VjZGlyIHJldmlldyAoZWFybHkgcmV2aWV3KSBvZiBkcmFmdC1pZXRmLW52 bzMtZ2VuZXZlDQoNCkhpIElsYW5nbywNClRoYW5rcyBmb3IgeW91ciB0aG9yb3VnaCBmb2xsb3ct dXAuIFRvIG1lLCB0aGUgbmV3IHRleHQgbG9va3MgdmVyeSBnb29kLiBZb3UgY291bGQgc2hvcnRl biAoYW5kIHBlcmhhcHMgYWRkIGNsYXJpdHkpIGJ5IHJlcGxhY2luZyAiSGVuY2UgYW4gb3B0aW9u Li4uIiB3aXRoIGp1c3QgIkFuIG9wdGlvbiAuLi4iDQo8SWxhbmdvPiBZZXMsIHRoaXMgc2hvdWxk IGJlIGZpbmUuDQoNClRoYW5rcywNCi9NDQoNCk9uIFR1ZSwgTm92IDYsIDIwMTggYXQgNzoxMSBQ TSBHYW5nYSwgSWxhbmdvIFMgPGlsYW5nby5zLmdhbmdhQGludGVsLmNvbTxtYWlsdG86aWxhbmdv LnMuZ2FuZ2FAaW50ZWwuY29tPj4gd3JvdGU6DQpIaSBNYWdudXMsDQoNCkhlcmUgaXMgb3VyIHBy b3Bvc2VkIHRleHQgdGhhdCB3ZSBiZWxpZXZlIHdpbGwgc2F0aXNmeSB5b3VyIGNvbW1lbnQgb24g My41LjE6DQoNCkluIFNlY3Rpb24gMi4yLjEgYWRkIG5ldyBoaWdobGlnaHRlZCB0ZXh0IGluIHBh cmFncmFwaCB0aGF0IGJlZ2FuIHdpdGgg4oCcVHJhbnNpdCBkZXZpY2VzLi7igJ0NCk9wdGlvbnMs IGlmIHByZXNlbnQgaW4gdGhlIHBhY2tldCwgTVVTVCBiZSBnZW5lcmF0ZWQgYW5kIHRlcm1pbmF0 ZWQgYnkgZW5kIHBvaW50cy4gVHJhbnNpdCBkZXZpY2VzIE1BWSBiZSBhYmxlIHRvIGludGVycHJl dCB0aGUgb3B0aW9ucywgaG93ZXZlciwgYXMNCiAgIG5vbi10ZXJtaW5hdGluZyBkZXZpY2VzLCB0 cmFuc2l0IGRldmljZXMgZG8gbm90IG9yaWdpbmF0ZSBvcg0KICAgdGVybWluYXRlIHRoZSBHZW5l dmUgcGFja2V0LCBoZW5jZSBNVVNUIE5PVCBpbnNlcnQgb3IgZGVsZXRlIG9wdGlvbnMsDQogICB3 aGljaCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgR2VuZXZlIGVuZHBvaW50cy4gIFRoZSBwYXJ0 aWNpcGF0aW9uDQogICBvZiB0cmFuc2l0IGRldmljZXMgaW4gaW50ZXJwcmV0aW5nIG9wdGlvbnMg aXMgT1BUSU9OQUwuDQoNCg0KU2VjdGlvbiAzLjUuMSAtIFJlbW92ZSB0aGUgaGlnaGxpZ2h0ZWQg dGV4dDoNCm8gIFNvbWUgb3B0aW9ucyBtYXkgYmUgZGVmaW5lZCBpbiBzdWNoIGEgd2F5IHRoYXQg dGhlIHBvc2l0aW9uIGluIHRoZQ0KICAgICAgb3B0aW9uIGxpc3QgaXMgc2lnbmlmaWNhbnQuICBP cHRpb25zIG9yIHRoZWlyIG9yZGVyaW5nLCBNVVNUIE5PVA0KICAgICAgYmUgY2hhbmdlZCBieSB0 cmFuc2l0IGRldmljZXMuDQoNClNlY3Rpb24gMy41LjEgLSBBZGQgaGlnaGxpZ2h0ZWQgdGV4dCB0 byB0aGUgbGFzdCBidWxsZXQ6DQogICBvICBBbiBvcHRpb24gU0hPVUxEIE5PVCBiZSBkZXBlbmRl bnQgdXBvbiBhbnkgb3RoZXIgb3B0aW9uIGluIHRoZSBwYWNrZXQsDQogaS5lLiwgb3B0aW9ucyBj YW4gYmUgcHJvY2Vzc2VkIGluZGVwZW5kZW50IG9mIG9uZSBhbm90aGVyLiBIZW5jZSBhbiBvcHRp b24gTVVTVCBOT1QgYWZmZWN0IHRoZSBwYXJzaW5nIG9yIGludGVycHJldGF0aW9uIG9mIGFueSBv dGhlciBvcHRpb24uDQoNClJlbW92ZSB0aGUgZm9sbG93aW5nIHBhcmFncmFwaCBmcm9tIDYuMjoN CkdlbmV2ZSBzdXBwb3J0cyBHZW5ldmUgT3B0aW9ucywgc28gYW4gb3BlcmF0b3IgbWF5IGNob29z ZSB0byB1c2UgYQ0KICAgR2VuZXZlIG9wdGlvbiBUTFYgdG8gcHJvdmlkZSBhIGNyeXB0b2dyYXBo aWMgZGF0YSBwcm90ZWN0aW9uDQogICBtZWNoYW5pc20sIHRvIHZlcmlmeSB0aGUgZGF0YSBpbnRl Z3JpdHkgb2YgdGhlIEdlbmV2ZSBoZWFkZXIsIEdlbmV2ZQ0KICAgb3B0aW9ucyBvciB0aGUgZW50 aXJlIEdlbmV2ZSBwYWNrZXQgaW5jbHVkaW5nIHRoZSBwYXlsb2FkLg0KICAgSW1wbGVtZW50YXRp b24gb2Ygc3VjaCBhIG1lY2hhbmlzbSBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMNCiAgIGRv Y3VtZW50Lg0KDQpJbnRyb2R1Y2UgbmV3IHNlY3Rpb24gYWZ0ZXIgNi4zIGFzIGZvbGxvd3M6DQo2 LjQgIE9wdGlvbnMgSW50ZXJwcmV0YXRpb24gYnkgVHJhbnNpdCBEZXZpY2VzDQoNCk9wdGlvbnMs IGlmIHByZXNlbnQgaW4gdGhlIHBhY2tldCwgYXJlIGdlbmVyYXRlZCBhbmQgdGVybWluYXRlZCBi eSBlbmQgcG9pbnRzLiBBcyBpbmRpY2F0ZWQgaW4gMi4yLjEsIHRyYW5zaXQgZGV2aWNlcyBtYXkg aW50ZXJwcmV0IHRoZSBvcHRpb25zLiBIb3dldmVyLCBpZiB0aGUgcGFja2V0IGlzIHByb3RlY3Rl ZCBieSBlbmQgcG9pbnQgdG8gZW5kIHBvaW50IGVuY3J5cHRpb24sIGZvciBleGFtcGxlIHRocm91 Z2ggSVBzZWMsIHRyYW5zaXQgZGV2aWNlcyB3aWxsIG5vdCBoYXZlIHZpc2liaWxpdHkgaW50byB0 aGUgR2VuZXZlIGhlYWRlciBvciBvcHRpb25zIGluIHRoZSBwYWNrZXQuIEluIGNhc2VzIHdoZXJl IG9wdGlvbnMgYXJlIGludGVycHJldGVkIGJ5IHRyYW5zaXQgZGV2aWNlcywgdGhlIG9wZXJhdG9y IE1VU1QgZW5zdXJlIHRoYXQgdHJhbnNpdCBkZXZpY2VzIGFyZSB0cnVzdGVkIGFuZCBub3QgY29t cHJvbWlzZWQuIEltcGxlbWVudGF0aW9uIG9mIGEgbWVjaGFuaXNtIHRvIGVuc3VyZSB0aGlzIHRy dXN0IGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCg0KUGxlYXNlIGxldCB1 cyBrbm93IGlmIHRoaXMgYWRkcmVzc2VzIHlvdXIgY29tbWVudCBvbiAzLjUuMS4gIFRoZSBvdGhl ciB0d28gY29tbWVudHMgaGF2ZSBiZWVuIHNhdGlzZmllZCBhcyBub3RlZCBiZWxvdy4NCg0KVGhh bmtzLA0KSWxhbmdvDQoNCg0KRnJvbTogTWFnbnVzIE55c3Ryw7ZtIFttYWlsdG86bWFnbnVzbkBn bWFpbC5jb208bWFpbHRvOm1hZ251c25AZ21haWwuY29tPl0NClNlbnQ6IFdlZG5lc2RheSwgT2N0 b2JlciAzMSwgMjAxOCAxMTozNCBBTQ0KVG86IEdhbmdhLCBJbGFuZ28gUyA8aWxhbmdvLnMuZ2Fu Z2FAaW50ZWwuY29tPG1haWx0bzppbGFuZ28ucy5nYW5nYUBpbnRlbC5jb20+Pjsgc2VjZGlyQGll dGYub3JnPG1haWx0bzpzZWNkaXJAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLW52bzMtZ2VuZXZlQGll dGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW52bzMtZ2VuZXZlQGlldGYub3JnPg0KU3ViamVjdDog UkU6IFNlY2RpciByZXZpZXcgKGVhcmx5IHJldmlldykgb2YgZHJhZnQtaWV0Zi1udm8zLWdlbmV2 ZQ0KDQpIaSBJbGFuZ28sDQpGb3IgMy40LCBJIHRoaW5rIHRoaXMgbWF5IGJlIHN1ZmZpY2llbnQu DQoNCkZvciA2LjIsIEkgd2lsbCBkZWZlciB0byB0aGUgSUVURiBkaXJlY3Rvci90ZWxlY2hhdCBk aXNjdXNzaW9uIHRoYXQgd2lsbCBvY2N1ciBhdCBzb21lIHBvaW50IGZvciB0aGlzIGRyYWZ0LiBJ ZiB0aGUgaW50ZW50IGlzIGludGVyb3BlcmFiaWxpdHkgYW5kIHJvYnVzdG5lc3Mgb2Ygc3VjaCBh biBvcHRpb24sIHRoZW4gSSB3b3VsZCByZWNvbW1lbmQgaXQgdG8gYmUgc3BlY2lmaWVkIGluIHRo ZSBJRVRGLCBidXQgSSBjYW4gYWxzbyBzZWUgaG93IHlvdSB3b3VsZCBwcmVmZXIgdGhhdCBzdWNo IHNwZWNpZmljYXRpb24gd29yayBvY2N1cnMgb3V0c2lkZSB0aGlzIHBhcnRpY3VsYXIgZHJhZnQg 4oCTIHdoaWNoIHNob3VsZCBiZSBkb2FibGUuIFBlcmhhcHMgc3RheWluZyBzaWxlbnQgb24gdGhl IG9wdGlvbiBhbHRlcm5hdGl2ZSBhbmQganVzdCByZWNvbW1lbmQgbGV2ZXJhZ2luZyBsYXllci1w cm92aWRlZCBpbmZyYXN0cnVjdHVyZSBzdWNoIGFzIGlwc2VjIG1heSBiZSBiZXN0IGZvciBub3c/ DQoNCkknbGwgYXdhaXQgeW91ciBzdWdnZXN0ZWQgdXBkYXRlZCBsYW5ndWFnZSBmb3IgMy41LjEu DQoNClRoYW5rcywNCg0KU2VudCBmcm9tIG15IFdpbmRvd3MgMTAgcGhvbmUNCg0KRnJvbTogR2Fu Z2EsIElsYW5nbyBTPG1haWx0bzppbGFuZ28ucy5nYW5nYUBpbnRlbC5jb20+DQpTZW50OiBUdWVz ZGF5LCBPY3RvYmVyIDMwLCAyMDE4IDE4OjEyDQpUbzogTWFnbnVzIE55c3Ryw7ZtPG1haWx0bzpt YWdudXNuQGdtYWlsLmNvbT47IHNlY2RpckBpZXRmLm9yZzxtYWlsdG86c2VjZGlyQGlldGYub3Jn PjsgZHJhZnQtaWV0Zi1udm8zLWdlbmV2ZUBpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1udm8z LWdlbmV2ZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBTZWNkaXIgcmV2aWV3IChlYXJseSByZXZp ZXcpIG9mIGRyYWZ0LWlldGYtbnZvMy1nZW5ldmUNCg0KSGkgTWFnbnVzLA0KDQpUaGFua3MgZm9y IHlvdXIgcmV2aWV3IGFuZCBmZWVkYmFjay4gUGxlYXNlIHNlZSBpbmxpbmUgZm9yIG15IHJlc3Bv bnNlcy4NCg0KUmVnYXJkcywNCklsYW5nbw0KDQoNCkZyb206IE1hZ251cyBOeXN0csO2bSBbbWFp bHRvOm1hZ251c25AZ21haWwuY29tXQ0KU2VudDogVHVlc2RheSwgT2N0b2JlciAyMywgMjAxOCA5 OjAxIFBNDQpUbzogc2VjZGlyQGlldGYub3JnPG1haWx0bzpzZWNkaXJAaWV0Zi5vcmc+OyBkcmFm dC1pZXRmLW52bzMtZ2VuZXZlQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW52bzMtZ2VuZXZl QGlldGYub3JnPg0KU3ViamVjdDogU2VjZGlyIHJldmlldyAoZWFybHkgcmV2aWV3KSBvZiBkcmFm dC1pZXRmLW52bzMtZ2VuZXZlDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBh cnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3MNCm9uZ29pbmcgZWZmb3J0IHRvIHJldmll dyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZQ0KSUVTRy4gVGhlc2Ug Y29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlDQpz ZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBz aG91bGQgdHJlYXQNCnRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxs IGNvbW1lbnRzLg0KDQpUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyAiR2VuZXZlLCIgYSBwcm90b2Nv bCBmb3IgR0VuZXJpYyBORXR3b3JrIFZpcnR1YWxpemF0aW9uIEVuY2Fwc3VsYXRpb24uIFRoZSBk b2N1bWVudCBpcyB3cml0dGVuIGluIGEgY2xlYXIgbWFubmVyIGFuZCB3aXRoIGEgdGhvcm91Z2gg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbi4gSSBoYXZlIGp1c3QgYSBmZXcgcXVlc3Rp b25zL2NvbW1lbnRzOg0KDQotIFNlY3Rpb24gMy40OiBUaGUgIk1VU1QgaWdub3JlIiBmb3IgdGhl IHJlc2VydmVkIGJpdHMgc2hvdWxkIHByZXN1bWFibHkgc3RhdGUgIlNIQUxMIGJlIGlnbm9yZWQg Zm9yIHRoaXMgdmVyc2lvbiBvZiB0aGUgR2VuZXZlIHByb3RvY29sLiIgLSBhcyBJIGltYWdpbmUg dGhhdCBpbiBhIGZ1dHVyZSB2ZXJzaW9uLCB0aGVzZSBiaXRzIG1heSBub3QgYmUgaWdub3JlZD8N Cg0KPElsYW5nbz4gSW4gdGhlb3J5LCBhIGZ1dHVyZSB2ZXJzaW9uIG1heSBjaGFuZ2UgdGhlIGJl aGF2aW9yIG9mIGFueSBvZiB0aGUgaGVhZGVyIGZpZWxkcyBpbmNsdWRpbmcgdGhlIHJlc2VydmVk IGJpdHMuICBUaGUgaGVhZGVyIGRlZmluaXRpb24gaXMgZm9yIHRoaXMgdmVyc2lvbiBvZiB0aGUg cHJvdG9jb2wuDQoNClBsZWFzZSBzZWUgaWYgdGhlIGZvbGxvd2luZyB0ZXh0IHdvdWxkIHNhdGlz ZnkgdGhlIGludGVudCBvZiB5b3VyIGNvbW1lbnQuDQrigJxSZXNlcnZlZCBmaWVsZCB3aGljaCBN VVNUIGJlIHplcm8gb24gdHJhbnNtaXNzaW9uIGFuZCBNVVNUIGJlIGlnbm9yZWQgb24gcmVjZWlw dC7igJ0NCg0KT3IgbGV0IHVzIGtub3cgaWYgeW91IHN0aWxsIHdhbnQgdG8gaGF2ZSB0aGlzIHF1 YWxpZmllZCB3aXRoIOKAnGZvciB0aGlzIHZlcnNpb24gb2YgdGhlIHByb3RvY29s4oCdDQo8Lz4N Cg0KLSBTZWN0aW9uIDMuNS4xOiBJIHdvbmRlciBhYm91dCB0aGUgc2ltdWx0YW5lb3VzIHJlcXVp cmVtZW50IHRoYXQgb25lIG9wdGlvbiBtdXN0IG5vdCBhZmZlY3QgdGhlIHBhcnNpbmcgb3IgaW50 ZXJwcmV0YXRpb24gb2YgYW5vdGhlciBvcHRpb24gYnV0IHRoYXQgdGhlIHNlcXVlbmNpbmcgKG9y ZGVyKSBvZiBvcHRpb25zIG1heSBiZSBzaWduaWZpY2FudCAtIHRoZXkgc2VlbSB0byBiZSBjb250 cmFkaWN0b3J5IHNpbmNlIGlmIHRoZSBzZXF1ZW5jaW5nICppcyogc2lnbmlmaWNhbnQsIHRoZW4g c29tZSBvcHRpb24gbXVzdCBiZSBpbXBhY3RlZCBieSBhIHByZXZpb3VzIG9uZSdzIHZhbHVlPyBG cm9tIGEgc2VjdXJpdHkgcGVyc3BlY3RpdmUsIEkgYWxzbyB3b25kZXIgaWYgdGhlcmUgY291bGQg YmUgc2VjdXJpdHkgY29uc2VxdWVuY2VzIG9mIHJlLW9yZGVyaW5nIG9wdGlvbnMgKGFuZCBob3cg dG8gdGVsbCBpZiBzb21lb25lIGRpZCByZS1vcmRlciAtIHNlZSBiZWxvdyk/DQoNCjxJbGFuZ28+ IFlvdSByYWlzZSBhIGdvb2QgcG9pbnQuIFRoZSBpbnRlbnQgb2YgdGhpcyBzdGF0ZW1lbnQgaXMs IHBhcnNpbmcgYW5kIGludGVycHJldGF0aW9uIG9mIG9wdGlvbnMgc2hvdWxkIG5vdCBiZSBkZXBl bmRlbnQgb24gb25lIGFub3RoZXIuIFdlIGFyZSBkaXNjdXNzaW5nIGFtb25nIHRoZSBhdXRob3Jz IHRvIHNlZSBob3cgd2UgY2FuIGluY2x1ZGUgYXBwcm9wcmlhdGUgY2xhcmlmeWluZyBzdGF0ZW1l bnRzIHRvIGFkZHJlc3MgeW91ciBwb2ludC4gSSB3aWxsIHVwZGF0ZSB5b3Ugc2hvcnRseS4NCjwv Pg0KDQotIFNlY3Rpb24gNi4yLCBzaG91bGRuJ3Qgc3VjaCBhbiBPcHRpb24gYmUgZGVmaW5lZCB0 byByZWR1Y2UgdGhlIHJpc2sgb2YgdW5kZXItc3BlY2lmaWVkIG9yIHN1YnBhciBzcGVjaWZpY2F0 aW9ucyBvZiBzdWNoIGludGVncml0eSBtZWNoYW5pc21zPyBPciBhbHNvIGZyb20gYW4gaW50ZXJv cCBwZXJzcGVjdGl2ZT8NCg0KPElsYW5nbz4gVXNpbmcgYSBHZW5ldmUgb3B0aW9uIGZvciB0aGUg cHVycG9zZSBvZiBkYXRhIGludGVncml0eSBpcyBtb3JlIG9mIGFuIG9wdGltaXphdGlvbi4gT3Ro ZXJ3aXNlIGRhdGEgaW50ZWdyaXR5IGNvdWxkIGJlIHByb3ZpZGVkIGJ5IHVzaW5nIGV4aXN0aW5n IG1lY2hhbmlzbXMgbGlrZSBJUHNlYyAoYXMgc3RhdGVkIGluIHNlY29uZCBwYXJhZ3JhcGggb2Yg Ni4yKS4gV2UgaW5jbHVkZWQgdGhlIGxhc3QgcGFyYWdyYXBoIHRvIHNob3cgb3RoZXIgcG9zc2li aWxpdGllcy4gV2UgY291bGQgcmVtb3ZlIHRoaXMgcGFyYWdyYXBoIGlmIGl0IG1heSBjYXVzZSBh bnkgY29uZnVzaW9uLg0KDQpXZSB3b3VsZCBsaWtlIHRvIGtlZXAgdGhlIEdlbmV2ZSBiYXNlIHNw ZWNpZmljYXRpb24gaW5kZXBlbmRlbnQgb2Ygb3B0aW9ucyBzcGVjaWZpY2F0aW9ucywgb3B0aW9u cyBjb3VsZCBiZSBhIGRlZmluZWQgaW4gYSBmdXR1cmUgc3RhbmRhcmRzIGFjdGlvbi4NCjwvPg0K DQoNClRoYW5rcy4NCi0tIE1hZ251cw0KDQoNCg0KLS0NCi0tIE1hZ251cw0K --_000_C5A274B25007804B800CB5B289727E3583D123C0ORSMSX116amrcor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo0NzE5NTA1ODQ7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE0OTg3NzYyMiAxMzcwMTEzMTE2 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6 NjsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Ko Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sOw0KCW1zby1m YXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDENCgl7bXNvLWxpc3QtaWQ6NjYyNDcwNDk1Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczoxOTM1MzI1ODM4IDk2NTM5ODQ1MCA2NzY5ODY5MSA2NzY5 ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjY7DQoJbXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CqDsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDsNCgltc28tZmFyZWFzdC1mb250LWZh bWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N CkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+SGkgTWFnbnVzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIHlvdXIgcmV2aWV3 IGFuZCBmZWVkYmFjay4gV2UgaGF2ZSBhZGRyZXNzZWQgYWxsIDMgb2YgeW91ciBjb21tZW50cy4g V2Ugd2lsbCBiZSB1cGRhdGluZyB0aGUgZHJhZnQgdG8gYWRkcmVzcyB0aGVzZSBhbmQgV0cgTEMg Y29tbWVudHMsIGluIHRoZSBuZXh0DQogd2VlayBvciB0d28uIDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JbGFuZ288bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX19fX19yZXBseXNlcGFyYXRvciI+PC9hPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE1hZ251cyBO eXN0csO2bSBbbWFpbHRvOm1hZ251c25AZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1 ZXNkYXksIE5vdmVtYmVyIDYsIDIwMTggMTE6MjAgUE08YnI+DQo8Yj5Ubzo8L2I+IEdhbmdhLCBJ bGFuZ28gUyAmbHQ7aWxhbmdvLnMuZ2FuZ2FAaW50ZWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4g c2VjZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLW52bzMtZ2VuZXZlQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBTZWNkaXIgcmV2aWV3IChlYXJseSByZXZpZXcpIG9mIGRyYWZ0LWll dGYtbnZvMy1nZW5ldmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGkgSWxhbmdvLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhhbmtzIGZvciB5b3VyIHRob3JvdWdoIGZvbGxvdy11cC4gVG8gbWUsIHRoZSBu ZXcgdGV4dCBsb29rcyB2ZXJ5IGdvb2QuIFlvdSBjb3VsZCBzaG9ydGVuIChhbmQgcGVyaGFwcyBh ZGQgY2xhcml0eSkgYnkgcmVwbGFjaW5nICZxdW90O0hlbmNlIGFuIG9wdGlvbi4uLiZxdW90OyB3 aXRoIGp1c3QgJnF1b3Q7QW4gb3B0aW9uIC4uLiZxdW90OzxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbHQ7 SWxhbmdvJmd0OyBZZXMsIHRoaXMgc2hvdWxkIGJlIGZpbmUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPi9NPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIFR1ZSwgTm92IDYsIDIwMTggYXQgNzoxMSBQTSBHYW5nYSwgSWxhbmdvIFMg Jmx0OzxhIGhyZWY9Im1haWx0bzppbGFuZ28ucy5nYW5nYUBpbnRlbC5jb20iPmlsYW5nby5zLmdh bmdhQGludGVsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5IaSBNYWdudXMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+SGVyZSBpcyBvdXIgcHJvcG9zZWQgdGV4dCB0aGF0IHdlIGJlbGlldmUgd2ls bCBzYXRpc2Z5IHlvdXIgY29tbWVudCBvbiAzLjUuMTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxpPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5JbiBTZWN0aW9uIDIuMi4xIGFkZCBuZXcgaGlnaGxpZ2h0ZWQg dGV4dCBpbiBwYXJhZ3JhcGggdGhhdCBiZWdhbiB3aXRoIOKAnFRyYW5zaXQgZGV2aWNlcy4u4oCd PC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pk9wdGlvbnMsIGlmIHByZXNlbnQgaW4gdGhlIHBhY2tldCwgTVVTVCBiZSBnZW5lcmF0ZWQgYW5k IHRlcm1pbmF0ZWQgYnkgZW5kIHBvaW50cy4gVHJhbnNpdCBkZXZpY2VzIE1BWSBiZSBhYmxlIHRv IGludGVycHJldA0KIHRoZSBvcHRpb25zLCBob3dldmVyLCBhczwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBub24tdGVybWlu YXRpbmcgZGV2aWNlcywgdHJhbnNpdCBkZXZpY2VzIGRvIG5vdCBvcmlnaW5hdGUgb3I8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsgdGVybWluYXRlIHRoZSBHZW5ldmUgcGFja2V0LCBoZW5jZSBNVVNUIE5PVCBpbnNlcnQgb3Ig ZGVsZXRlIG9wdGlvbnMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IHdoaWNoIGlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiBH ZW5ldmUgZW5kcG9pbnRzLiZuYnNwOyBUaGUgcGFydGljaXBhdGlvbjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBvZiB0cmFu c2l0IGRldmljZXMgaW4gaW50ZXJwcmV0aW5nIG9wdGlvbnMgaXMgT1BUSU9OQUwuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48aT48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+U2VjdGlvbiAzLjUuMSAtIFJlbW92ZSB0aGUgaGlnaGxpZ2h0ZWQg dGV4dDo8L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFG NDk3RCI+byZuYnNwOyBTb21lIG9wdGlvbnMgbWF5IGJlIGRlZmluZWQgaW4gc3VjaCBhIHdheSB0 aGF0IHRoZSBwb3NpdGlvbiBpbiB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3B0aW9u IGxpc3QgaXMgc2lnbmlmaWNhbnQuJm5ic3A7IE9wdGlvbnMNCjwvc3Bhbj48cz48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmVkIj5vciB0aGVp ciBvcmRlcmluZyw8L3NwYW4+PC9zPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4gTVVTVCBOT1Q8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgYmUgY2hhbmdlZCBieSB0cmFuc2l0IGRldmljZXMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+U2VjdGlvbiAzLjUuMSAtIEFkZCBoaWdobGlnaHRlZCB0ZXh0IHRvIHRoZSBsYXN0IGJ1 bGxldDo8L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsNCjwvc3Bhbj48dT48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzAwQjA1MCI+QW4gb3B0aW9uIFNI T1VMRCBOT1QgYmUgZGVwZW5kZW50IHVwb24gYW55IG90aGVyIG9wdGlvbiBpbiB0aGUgcGFja2V0 LA0KPC9zcGFuPjwvdT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHU+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMw MEIwNTAiPiZuYnNwO2kuZS4sIG9wdGlvbnMgY2FuIGJlIHByb2Nlc3NlZCBpbmRlcGVuZGVudCBv ZiBvbmUgYW5vdGhlci4gSGVuY2U8L3NwYW4+PC91PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4NCiBhbiBvcHRpb24gTVVTVCBO T1QgYWZmZWN0IHRoZSBwYXJzaW5nIG9yIGludGVycHJldGF0aW9uIG9mIGFueSBvdGhlciBvcHRp b24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48aT48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVtb3ZlIHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBo IGZyb20gNi4yOjwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj5HZW5ldmUgc3VwcG9ydHMgR2VuZXZlIE9wdGlvbnMsIHNvIGFuIG9wZXJh dG9yIG1heSBjaG9vc2UgdG8gdXNlIGE8L3NwYW4+PC9zPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48cz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IEdlbmV2ZSBvcHRpb24gVExW IHRvIHByb3ZpZGUgYSBjcnlwdG9ncmFwaGljIGRhdGEgcHJvdGVjdGlvbjwvc3Bhbj48L3M+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsgbWVjaGFuaXNtLCB0byB2ZXJpZnkgdGhlIGRhdGEgaW50ZWdyaXR5IG9mIHRoZSBHZW5ldmUg aGVhZGVyLCBHZW5ldmU8L3NwYW4+PC9zPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48cz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IG9wdGlvbnMgb3IgdGhlIGVudGlyZSBHZW5l dmUgcGFja2V0IGluY2x1ZGluZyB0aGUgcGF5bG9hZC48L3NwYW4+PC9zPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48cz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IEltcGxlbWVu dGF0aW9uIG9mIHN1Y2ggYSBtZWNoYW5pc20gaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzPC9z cGFuPjwvcz48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHM+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyBkb2N1bWVudC48L3NwYW4+PC9zPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48YSBuYW1lPSJtXy04NDYyMzY4NDc4NTAyMTMxMTA4X19NYWlsRW5k Q29tcG9zZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2E+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxpPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5JbnRyb2R1Y2UgbmV3IHNlY3Rpb24gYWZ0ZXIgNi4zIGFzIGZvbGxvd3M6PC9z cGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjYu NCZuYnNwOyBPcHRpb25zIEludGVycHJldGF0aW9uIGJ5IFRyYW5zaXQgRGV2aWNlczwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9wdGlvbnMs IGlmIHByZXNlbnQgaW4gdGhlIHBhY2tldCwgYXJlIGdlbmVyYXRlZCBhbmQgdGVybWluYXRlZCBi eSBlbmQgcG9pbnRzLiBBcyBpbmRpY2F0ZWQgaW4gMi4yLjEsIHRyYW5zaXQgZGV2aWNlcyBtYXkg aW50ZXJwcmV0DQogdGhlIG9wdGlvbnMuIEhvd2V2ZXIsIGlmIHRoZSBwYWNrZXQgaXMgcHJvdGVj dGVkIGJ5IGVuZCBwb2ludCB0byBlbmQgcG9pbnQgZW5jcnlwdGlvbiwgZm9yIGV4YW1wbGUgdGhy b3VnaCBJUHNlYywgdHJhbnNpdCBkZXZpY2VzIHdpbGwgbm90IGhhdmUgdmlzaWJpbGl0eSBpbnRv IHRoZSBHZW5ldmUgaGVhZGVyIG9yIG9wdGlvbnMgaW4gdGhlIHBhY2tldC4gSW4gY2FzZXMgd2hl cmUgb3B0aW9ucyBhcmUgaW50ZXJwcmV0ZWQgYnkgdHJhbnNpdCBkZXZpY2VzLA0KIHRoZSBvcGVy YXRvciBNVVNUIGVuc3VyZSB0aGF0IHRyYW5zaXQgZGV2aWNlcyBhcmUgdHJ1c3RlZCBhbmQgbm90 IGNvbXByb21pc2VkLiBJbXBsZW1lbnRhdGlvbiBvZiBhIG1lY2hhbmlzbSB0byBlbnN1cmUgdGhp cyB0cnVzdCBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UGxlYXNlIGxldCB1cyBrbm93IGlmIHRoaXMg YWRkcmVzc2VzIHlvdXIgY29tbWVudCBvbiAzLjUuMS4mbmJzcDsgVGhlIG90aGVyIHR3byBjb21t ZW50cyBoYXZlIGJlZW4gc2F0aXNmaWVkIGFzIG5vdGVkIGJlbG93Lg0KPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPklsYW5n bzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9Im1fLTg0NjIzNjg0Nzg1MDIxMzExMDhfX19fX19yZXBs eXNlcGFyYXQiPjwvYT48Yj5Gcm9tOjwvYj4gTWFnbnVzIE55c3Ryw7ZtIFttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOm1hZ251c25AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFnbnVzbkBnbWFp bC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgT2N0b2JlciAzMSwgMjAx OCAxMTozNCBBTTxicj4NCjxiPlRvOjwvYj4gR2FuZ2EsIElsYW5nbyBTICZsdDs8YSBocmVmPSJt YWlsdG86aWxhbmdvLnMuZ2FuZ2FAaW50ZWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWxhbmdvLnMu Z2FuZ2FAaW50ZWwuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86c2VjZGlyQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+c2VjZGlyQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRy YWZ0LWlldGYtbnZvMy1nZW5ldmVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LWll dGYtbnZvMy1nZW5ldmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBTZWNk aXIgcmV2aWV3IChlYXJseSByZXZpZXcpIG9mIGRyYWZ0LWlldGYtbnZvMy1nZW5ldmU8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBJbGFuZ28sPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkZvciAzLjQsIEkgdGhpbmsgdGhpcyBtYXkg YmUgc3VmZmljaWVudC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Rm9yIDYuMiwgSSB3 aWxsIGRlZmVyIHRvIHRoZSBJRVRGIGRpcmVjdG9yL3RlbGVjaGF0IGRpc2N1c3Npb24gdGhhdCB3 aWxsIG9jY3VyIGF0IHNvbWUgcG9pbnQgZm9yIHRoaXMgZHJhZnQuIElmIHRoZSBpbnRlbnQgaXMg aW50ZXJvcGVyYWJpbGl0eSBhbmQgcm9idXN0bmVzcyBvZiBzdWNoIGFuIG9wdGlvbiwNCiB0aGVu IEkgd291bGQgcmVjb21tZW5kIGl0IHRvIGJlIHNwZWNpZmllZCBpbiB0aGUgSUVURiwgYnV0IEkg Y2FuIGFsc28gc2VlIGhvdyB5b3Ugd291bGQgcHJlZmVyIHRoYXQgc3VjaCBzcGVjaWZpY2F0aW9u IHdvcmsgb2NjdXJzIG91dHNpZGUgdGhpcyBwYXJ0aWN1bGFyIGRyYWZ0IOKAkyB3aGljaCBzaG91 bGQgYmUgZG9hYmxlLiBQZXJoYXBzIHN0YXlpbmcgc2lsZW50IG9uIHRoZSBvcHRpb24gYWx0ZXJu YXRpdmUgYW5kIGp1c3QgcmVjb21tZW5kIGxldmVyYWdpbmcNCiBsYXllci1wcm92aWRlZCBpbmZy YXN0cnVjdHVyZSBzdWNoIGFzIGlwc2VjIG1heSBiZSBiZXN0IGZvciBub3c/PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5JJ2xsIGF3YWl0IHlvdXIgc3VnZ2VzdGVkIHVwZGF0ZWQgbGFuZ3Vh Z2UgZm9yIDMuNS4xLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzLDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+U2VudCBmcm9tIG15IFdpbmRvd3MgMTAgcGhvbmU8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206 DQo8L2I+PGEgaHJlZj0ibWFpbHRvOmlsYW5nby5zLmdhbmdhQGludGVsLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPkdhbmdhLCBJbGFuZ28gUzwvYT48YnI+DQo8Yj5TZW50OiA8L2I+VHVlc2RheSwgT2N0 b2JlciAzMCwgMjAxOCAxODoxMjxicj4NCjxiPlRvOiA8L2I+PGEgaHJlZj0ibWFpbHRvOm1hZ251 c25AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWFnbnVzIE55c3Ryw7ZtPC9hPjsNCjxhIGhy ZWY9Im1haWx0bzpzZWNkaXJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zZWNkaXJAaWV0Zi5v cmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1udm8zLWdlbmV2ZUBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQtaWV0Zi1udm8zLWdlbmV2ZUBpZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+UkU6IFNlY2RpciByZXZpZXcgKGVhcmx5IHJldmlldykgb2YgZHJh ZnQtaWV0Zi1udm8zLWdlbmV2ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkgTWFnbnVzLDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgeW91ciByZXZpZXcgYW5kIGZlZWRiYWNr LiBQbGVhc2Ugc2VlIGlubGluZSBmb3IgbXkgcmVzcG9uc2VzLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SWxhbmdvPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gTWFnbnVzIE55 c3Ryw7ZtIFs8YSBocmVmPSJtYWlsdG86bWFnbnVzbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5tYWlsdG86bWFnbnVzbkBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNk YXksIE9jdG9iZXIgMjMsIDIwMTggOTowMSBQTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFp bHRvOnNlY2RpckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNlY2RpckBpZXRmLm9yZzwvYT47 IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW52bzMtZ2VuZXZlQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+DQpkcmFmdC1pZXRmLW52bzMtZ2VuZXZlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1 YmplY3Q6PC9iPiBTZWNkaXIgcmV2aWV3IChlYXJseSByZXZpZXcpIG9mIGRyYWZ0LWlldGYtbnZv My1nZW5ldmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGhhdmUgcmV2aWV3 ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzPGJy Pg0Kb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9j ZXNzZWQgYnkgdGhlPGJyPg0KSUVTRy4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1h cmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlPGJyPg0Kc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMu Jm5ic3A7IERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQ8YnI+DQp0 aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIGRvY3Vt ZW50IGRlc2NyaWJlcyAmcXVvdDtHZW5ldmUsJnF1b3Q7IGEgcHJvdG9jb2wgZm9yIEdFbmVyaWMg TkV0d29yayBWaXJ0dWFsaXphdGlvbiBFbmNhcHN1bGF0aW9uLiBUaGUgZG9jdW1lbnQgaXMgd3Jp dHRlbiBpbiBhIGNsZWFyIG1hbm5lciBhbmQgd2l0aCBhIHRob3JvdWdoIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zDQogc2VjdGlvbi4gSSBoYXZlIGp1c3QgYSBmZXcgcXVlc3Rpb25zL2NvbW1lbnRz OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+LSBTZWN0aW9uIDMuNDogVGhlICZxdW90O01VU1QgaWdub3JlJnF1b3Q7IGZvciB0aGUgcmVz ZXJ2ZWQgYml0cyBzaG91bGQgcHJlc3VtYWJseSBzdGF0ZSAmcXVvdDtTSEFMTCBiZSBpZ25vcmVk IGZvciB0aGlzIHZlcnNpb24gb2YgdGhlIEdlbmV2ZSBwcm90b2NvbC4mcXVvdDsgLSBhcyBJIGlt YWdpbmUgdGhhdCBpbiBhIGZ1dHVyZSB2ZXJzaW9uLA0KIHRoZXNlIGJpdHMgbWF5IG5vdCBiZSBp Z25vcmVkPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmx0O0lsYW5nbyZndDsg SW4gdGhlb3J5LCBhIGZ1dHVyZSB2ZXJzaW9uIG1heSBjaGFuZ2UgdGhlIGJlaGF2aW9yIG9mIGFu eSBvZiB0aGUgaGVhZGVyIGZpZWxkcyBpbmNsdWRpbmcgdGhlIHJlc2VydmVkIGJpdHMuJm5ic3A7 IFRoZSBoZWFkZXIgZGVmaW5pdGlvbiBpcyBmb3IgdGhpcw0KIHZlcnNpb24gb2YgdGhlIHByb3Rv Y29sLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlBsZWFzZSBzZWUg aWYgdGhlIGZvbGxvd2luZyB0ZXh0IHdvdWxkIHNhdGlzZnkgdGhlIGludGVudCBvZiB5b3VyIGNv bW1lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+4oCcUmVzZXJ2ZWQgZmllbGQgd2hpY2ggTVVTVCBiZSB6ZXJvIG9uIHRyYW5zbWlzc2lvbiBh bmQNCjwvc3Bhbj48dT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6IzAwQjA1MCI+TVVTVCBiZTwvc3Bhbj48L3U+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiBpZ25vcmVkIG9u IHJlY2VpcHQu4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+T3IgbGV0IHVzIGtub3cgaWYgeW91IHN0 aWxsIHdhbnQgdG8gaGF2ZSB0aGlzIHF1YWxpZmllZCB3aXRoIOKAnGZvciB0aGlzIHZlcnNpb24g b2YgdGhlIHByb3RvY29s4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmx0Oy8mZ3Q7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4tIFNlY3Rpb24gMy41LjE6IEkgd29uZGVyIGFib3V0IHRoZSBzaW11 bHRhbmVvdXMgcmVxdWlyZW1lbnQgdGhhdCBvbmUgb3B0aW9uIG11c3Qgbm90IGFmZmVjdCB0aGUg cGFyc2luZyBvciBpbnRlcnByZXRhdGlvbiBvZiBhbm90aGVyIG9wdGlvbiBidXQgdGhhdCB0aGUg c2VxdWVuY2luZyAob3JkZXIpIG9mIG9wdGlvbnMNCiBtYXkgYmUgc2lnbmlmaWNhbnQgLSB0aGV5 IHNlZW0gdG8gYmUgY29udHJhZGljdG9yeSBzaW5jZSBpZiB0aGUgc2VxdWVuY2luZyAqaXMqIHNp Z25pZmljYW50LCB0aGVuIHNvbWUgb3B0aW9uIG11c3QgYmUgaW1wYWN0ZWQgYnkgYSBwcmV2aW91 cyBvbmUncyB2YWx1ZT8gRnJvbSBhIHNlY3VyaXR5IHBlcnNwZWN0aXZlLCBJIGFsc28gd29uZGVy IGlmIHRoZXJlIGNvdWxkIGJlIHNlY3VyaXR5IGNvbnNlcXVlbmNlcyBvZiByZS1vcmRlcmluZyBv cHRpb25zDQogKGFuZCBob3cgdG8gdGVsbCBpZiBzb21lb25lIGRpZCByZS1vcmRlciAtIHNlZSBi ZWxvdyk/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbHQ7SWxhbmdvJmd0OyBZ b3UgcmFpc2UgYSBnb29kIHBvaW50LiBUaGUgaW50ZW50IG9mIHRoaXMgc3RhdGVtZW50IGlzLCBw YXJzaW5nIGFuZCBpbnRlcnByZXRhdGlvbiBvZiBvcHRpb25zIHNob3VsZCBub3QgYmUgZGVwZW5k ZW50IG9uIG9uZSBhbm90aGVyLiBXZSBhcmUNCiBkaXNjdXNzaW5nIGFtb25nIHRoZSBhdXRob3Jz IHRvIHNlZSBob3cgd2UgY2FuIGluY2x1ZGUgYXBwcm9wcmlhdGUgY2xhcmlmeWluZyBzdGF0ZW1l bnRzIHRvIGFkZHJlc3MgeW91ciBwb2ludC4gSSB3aWxsIHVwZGF0ZSB5b3Ugc2hvcnRseS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mbHQ7LyZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gU2Vj dGlvbiA2LjIsIHNob3VsZG4ndCBzdWNoIGFuIE9wdGlvbiBiZSBkZWZpbmVkIHRvIHJlZHVjZSB0 aGUgcmlzayBvZiB1bmRlci1zcGVjaWZpZWQgb3Igc3VicGFyIHNwZWNpZmljYXRpb25zIG9mIHN1 Y2ggaW50ZWdyaXR5IG1lY2hhbmlzbXM/IE9yIGFsc28gZnJvbSBhbiBpbnRlcm9wIHBlcnNwZWN0 aXZlPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmx0O0lsYW5nbyZndDsgVXNp bmcgYSBHZW5ldmUgb3B0aW9uIGZvciB0aGUgcHVycG9zZSBvZiBkYXRhIGludGVncml0eSBpcyBt b3JlIG9mIGFuIG9wdGltaXphdGlvbi4gT3RoZXJ3aXNlIGRhdGEgaW50ZWdyaXR5IGNvdWxkIGJl IHByb3ZpZGVkIGJ5IHVzaW5nIGV4aXN0aW5nDQogbWVjaGFuaXNtcyBsaWtlIElQc2VjIChhcyBz dGF0ZWQgaW4gc2Vjb25kIHBhcmFncmFwaCBvZiA2LjIpLiBXZSBpbmNsdWRlZCB0aGUgbGFzdCBw YXJhZ3JhcGggdG8gc2hvdyBvdGhlciBwb3NzaWJpbGl0aWVzLiBXZSBjb3VsZCByZW1vdmUgdGhp cyBwYXJhZ3JhcGggaWYgaXQgbWF5IGNhdXNlIGFueSBjb25mdXNpb24uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2Ugd291bGQgbGlrZSB0byBrZWVwIHRoZSBHZW5l dmUgYmFzZSBzcGVjaWZpY2F0aW9uIGluZGVwZW5kZW50IG9mIG9wdGlvbnMgc3BlY2lmaWNhdGlv bnMsIG9wdGlvbnMgY291bGQgYmUgYSBkZWZpbmVkIGluIGEgZnV0dXJlIHN0YW5kYXJkcyBhY3Rp b24uICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZsdDsvJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlRoYW5rcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPi0tIE1hZ251czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiciBjbGVhcj0iYWxsIj4NCjxi cj4NCi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIE1h Z251czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C5A274B25007804B800CB5B289727E3583D123C0ORSMSX116amrcor_-- From nobody Fri Nov 9 03:44:41 2018 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 195CF130DE9; Fri, 9 Nov 2018 03:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.971 X-Spam-Level: X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 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 ZKk_ALTuYC-q; Fri, 9 Nov 2018 03:44:25 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C93C130DFD; Fri, 9 Nov 2018 03:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3076; q=dns/txt; s=iport; t=1541763864; x=1542973464; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=FK+tRHRHWqRkwei0x9tKgpcHYoMzCcp6xgNU/L+fj1g=; b=iGZzo9HDWEAEIKUTYvRThmZJqbh+nRub9uG6wXzSJf7shqjNmgjqbLcI QT3GzzHacASl4YSeFX19LIQSyM6UZ++Qqu3rx+gg1WegvNH64yffprze0 x3lheUcPYngKo41+WifqaU97trdZT2/kQzgr3QBwlv8Y7YVjYqRFH/vy/ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAABLcuVb/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBgmlPIRIng3iId40pmSwNJYRHAoNDNwo?= =?us-ascii?q?NAQMBAQIBAQJtHAyFOgEBAQMBIxUzDQEQCxIGAgIFFgsCAgkDAgECATcOBgE?= =?us-ascii?q?MAQcBAYMegXkID6c/gSAOhT2EYAWBC4sIgUE/gRGDEoMbBIRjglcCiH+GRpA?= =?us-ascii?q?HCZEZGIFXhQGCfIcal3GBWSKBVTMaCBsVO4JtgiYXEohMhT8+AzABjUMBAQ?= X-IronPort-AV: E=Sophos;i="5.54,483,1534809600"; d="scan'208";a="7928198" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Nov 2018 11:44:21 +0000 Received: from [10.60.140.52] (ams-ppsenak-nitro3.cisco.com [10.60.140.52]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id wA9BiKPK008187; Fri, 9 Nov 2018 11:44:20 GMT Message-ID: <5BE57314.7060706@cisco.com> Date: Fri, 09 Nov 2018 12:44:20 +0100 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Yaron Sheffer , secdir@ietf.org CC: lsr@ietf.org, ietf@ietf.org, draft-ietf-ospf-ospfv3-segment-routing-extensions.all@ietf.org References: <154134589488.32046.1179323499664545252@ietfa.amsl.com> <5BDFFB72.7010100@cisco.com> <09c65027-5352-f783-7cbb-af5f8aa95cec@gmail.com> In-Reply-To: <09c65027-5352-f783-7cbb-af5f8aa95cec@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.60.140.52, ams-ppsenak-nitro3.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16 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, 09 Nov 2018 11:44:28 -0000 Hi Yaron, On 06/11/18 07:13 , Yaron Sheffer wrote: > Thank you Peter, this addresses my comments. latest version (17) includes your comments. thanks, Peter > > Yaron > > On 05/11/2018 10:12, Peter Psenak wrote: >> Hi Yaron, >> >> thanks for your comments, please see inline: >> >> >> On 04/11/18 16:38 , Yaron Sheffer wrote: >>> Reviewer: Yaron Sheffer >>> Review result: Has Nits >>> >>> Summary: document has non-security related nits. >>> >>> Details >>> >>> * The definition of "segment" is different here from the one used in the >>> architecture RFC. The RFC is more abstract, quoting: A node steers a >>> packet >>> through an ordered list of instructions, called "segments". Whereas >>> here a >>> segment is simply a sub-path. This is confusing to a non-expert, and >>> perhaps >>> indicates a change in the group's thinking. >> >> the definition in this draft relates to segment as used by IGPs, in >> which case a segment represents the sub-path. There are other segments >> outside of IGPs which can represent other things, but they are not >> covered by this draft. >> >> >>> >>> * SID/Label Sub-TLV: is it Mandatory? If so, please point it out. >> >> SID/Label Sub-TLV is not advertised on its own. It is advertised as a >> sub-TLV of the: >> >> 3.2. SID/Label Range TLV >> 3.3. SR Local Block TLV >> >> Both of these section specify that SID/Label Sub-TLV MUST be included. >> >>> >>> * "The SR-Algorithm TLV is optional" - I find this sentence >>> confusing. Maybe >>> replace by "The SR-Algorithm TLV is mandatory for routers that implement >>> segment routing"? >> >> >> the text says: >> >> "If the SR-Algorithm TLV >> is not advertised by the node, such node is considered as not being >> segment routing capable." >> >> Isn't that sufficient? >> >> >>> >>> * The reference under "IGP Algorithm Type" registry should be to the >>> IANA >>> registry itself, not to the I-D that defines it. (In particular since >>> the IANA >>> registry has already been established, >>> https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types). >>> >> >> I got another comment from Opsdir last call review to include the I-D >> that defined it. I Added them both, hopefully that satisfy everybody. >> >>> >>> * OSPFv3 Extended Prefix Range TLV Flags octet: add the usual >>> incantation about >>> reserved bits. >> >> Done. >> >> >> >> >>> * In general I agree with the reasoning in the Security >>> Considerations. I would >>> like to raise the question if, in addition to mis-routing, this adds >>> a threat >>> of massive denial-of-service on MPLS endpoints, e.g. by allowing an >>> attacker >>> who has OSPF access to introduce routing loops. (This may be >>> completely bogus, >>> I am far from expert with either of these protocols). >> >> above is addressed by usage of the usage of the OSPF authentication as >> described in the security section. >> >> thanks, >> Peter >> >>> >>> . >>> >> > . > From nobody Fri Nov 9 04:14:47 2018 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 234F7130DFB for ; Fri, 9 Nov 2018 04:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 IsBD2pqM6hCU for ; Fri, 9 Nov 2018 04:14:43 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 687A4130DE9 for ; Fri, 9 Nov 2018 04:14:43 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id n12so1107889qkh.11 for ; Fri, 09 Nov 2018 04:14:43 -0800 (PST) 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 :mime-version:content-transfer-encoding; bh=qltV9akcC4QpDkKupJ+/j7CzV3WWlLe54/BlV/IYyK4=; b=bUUOBukC06DluSN0G0Kz3A1/L0hpQb8m2B8P4fpTmrPRiWj8rsgErAk7S71iLxcSga eB4KbeumWqNVBFNPlr9Icp0/sChnfE5bly5HnZUwaNKDWn0pNLWxyD7Gb/z83th4sjUs BTx5+pGMsA051Qe2o2h26ohg6O+IGVTSLCWzY= 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:mime-version:content-transfer-encoding; bh=qltV9akcC4QpDkKupJ+/j7CzV3WWlLe54/BlV/IYyK4=; b=bzAN2CyBeK9Ta8IOwT7xCEe9/goISpDlVkhvIankD/Uak+y6Y/kwEIcuJpeM7JB25J ZZJLwpEl7ESYE68wTEgoWUU4QG6vrdYV8xZJlHaGCXcE6n8t78UHJk3/GbRmveqUlsrI hDlTDBSVljUlQYXbdKVf0osGwlFT9SyW/507BeRsF7hUkEjrccTXPoTAjhd+sFY1FdJJ 78xQU7RNBQ63387BVqblp58602o54hQwq9RlyQjgxBO9n2Xt8qiVb5SbfJ6RU6atdWks T+qmAhdBQVQ2K4qfDiXK+fGDp3m2tMLaEHMQVhHGWJdRXEbwcIZ5JaclxqgxluYnrqoE Wn0w== X-Gm-Message-State: AGRZ1gJVTLu2xka7HEZfCTRBdNcULP8l7qCgm0NfCr4TX4QEcXBxt8mP htU+VQq0W9a/EoKRqSY/6ju00LqUwKA= X-Google-Smtp-Source: AJdET5dWUvlX8u35UMKRIuUG4EWuOkpNEs2mOHCjb1UiCORyzUiAG6QHzZDVGCkJRG3hLd3KjdTyjQ== X-Received: by 2002:ac8:3065:: with SMTP id g34mr8549913qte.136.1541765682231; Fri, 09 Nov 2018 04:14:42 -0800 (PST) Received: from [192.168.2.27] (pool-108-28-91-61.washdc.fios.verizon.net. [108.28.91.61]) by smtp.googlemail.com with ESMTPSA id 67sm5184728qku.60.2018.11.09.04.14.38 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 09 Nov 2018 04:14:40 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.7.6.170621 Date: Fri, 09 Nov 2018 07:14:34 -0500 From: Carl Wallace To: CC: , Message-ID: Thread-Topic: secdir review of draft-ietf-idr-bgpls-segment-routing-epe Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: [secdir] secdir review of draft-ietf-idr-bgpls-segment-routing-epe 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, 09 Nov 2018 12:14:46 -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 an extension to BGP Link State (BGP-LS) for advertisement of BGP Peering Segments along with their BGP peering node information so that efficient BGP Egress Peer Engineering (EPE) policies and strategies can be computed based on Segment Routing. As extensions to RFC7752, the security considerations incorporate language from that document by reference in addition to segment routing security considerations from the architecture document (RFC8402). This seems appropriate. I found the document to be well written. One minor comment, reusing the same reference diagram for Figure 5 as in draft-ietf-spring-segment-routing-central-epe-05 Figure 1 may be worthwhile (as would making sure all items in the diagram are described in the test below the diagram). From nobody Fri Nov 9 05:41:49 2018 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 6EA30130E03 for ; Fri, 9 Nov 2018 05:41:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <154177090744.14522.2476436900693279403.idtracker@ietfa.amsl.com> Date: Fri, 09 Nov 2018 05:41:47 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 13:41:48 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2018-11-21 Reviewer LC end Draft Kathleen Moriarty 2018-10-19 draft-ietf-ntp-mac-05 Melinda Shore 2018-11-06 draft-ietf-dmarc-arc-protocol-21 Samuel Weiler 2018-11-13 draft-ietf-dnsop-dns-capture-format-08 Last calls: Reviewer LC end Draft John Bradley 2018-09-25 draft-ietf-dnsop-attrleaf-fix-06 John Bradley 2018-06-18 draft-ietf-bfd-multipoint-active-tail-09 Daniel Gillmor 2018-06-25 draft-ietf-dnsop-session-signal-18 Daniel Gillmor 2018-03-19 draft-gutmann-scep-10 Phillip Hallam-Baker 2018-10-11 draft-ietf-softwire-yang-12 Steve Hanna 2018-10-03 draft-ietf-detnet-problem-statement-07 Matthew Miller 2018-10-12 draft-ietf-httpbis-rand-access-live-03 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Magnus Nystrom 2018-11-13 draft-op3ft-leaptofrogans-uri-scheme-03 Vincent Roca 2018-10-29 draft-ietf-pce-gmpls-pcep-extensions-12 Joseph Salowey 2018-11-20 draft-wilde-sunset-header-07 Stefan Santesson 2018-11-20 draft-wilde-service-link-rel-06 Samuel Weiler 2018-05-21 draft-ietf-bfd-multipoint-18 Brian Weis 2018-11-23 draft-ietf-dots-requirements-16 Christopher Wood 2018-11-27 draft-ietf-nfsv4-mv0-trunking-update-02 Taylor Yu 2018-10-09 draft-murchison-tzdist-tzif-15 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Sean Turner 2018-11-25 draft-ietf-babel-dtls-01 Paul Wouters 2018-12-31 draft-ietf-taps-transport-security-04 Next in the reviewer rotation: Liang Xia Taylor Yu Dacheng Zhang Derek Atkins John Bradley Nancy Cam-Winget Shaun Cooley Roman Danyliw Alan DeKok Linda Dunbar From nobody Tue Nov 13 07:28:32 2018 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 CC8B2130DDD for ; Tue, 13 Nov 2018 07:28:30 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...] 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, 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 TQ3UeBCECg5A for ; Tue, 13 Nov 2018 07:28:29 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 33CA0128CF2 for ; Tue, 13 Nov 2018 07:28:28 -0800 (PST) X-AuditID: 12074422-561ff70000000d71-44-5beaed9aea26 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id DF.8C.03441.A9DEAEB5; Tue, 13 Nov 2018 10:28:27 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.14.7/8.9.2) with ESMTP id wADFSPTr018556 for ; Tue, 13 Nov 2018 10:28:25 -0500 Received: from kduck.kaduk.org (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 wADFSMEA023455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 13 Nov 2018 10:28:24 -0500 Date: Tue, 13 Nov 2018 09:28:22 -0600 From: Benjamin Kaduk To: secdir@ietf.org Message-ID: <20181113152821.GJ99562@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUixCmqrTv77atog8UNwhYfFj5kcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxs2Nr5gLnjNXtG7XbmDsZe5i5OSQEDCRuP3gEFsXIxeHkMAa Jomlpy5COccZJab97WOEcD4zSaxffhKshUVAVWJe9wcwm01ARaKh+zKYLSIgLHH74ANWEFtY wEVi+aR2NhCbF2jF1oPTmCFsQYmTM5+wgNjMAloSN/69ZOpi5ACypSWW/+MACYsKKEvs7TvE PoGRdxaSjllIOmYhdCxgZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6qXm1mil5pSuokRFEjs Lko7GCf+8zrEKMDBqMTDa3H7VbQQa2JZcWXuIUZJDiYlUd60MKAQX1J+SmVGYnFGfFFpTmrx IUYJDmYlEV6FZ0A53pTEyqrUonyYlDQHi5I47x+Rx9FCAumJJanZqakFqUUwWRkODiUJ3g9v gBoFi1LTUyvSMnNKENJMHJwgw3mAhnuA1PAWFyTmFmemQ+RPMSpKifOyA2NVSAAkkVGaB9cL inSJ7P01rxjFgV4R5t0H0s4DTBJw3a+ABjMBDS55+RxkcEkiQkqqgTF4w61V97abxvJzc25Z ccyjL1epIFlenTnzI/fFqoNbFrzbwtqaMyfl/aIHC2TEdb5dfB79XdarxUeA0fSpigxXDHPw q7ki0evUZdNCW/1+hk/Ucdi1v0+W75TuNEOlZKmyDR2fPy7b9lh6pkzLFYGGjftXJe76YKHU pX/j9p0l0Znnl3eWOCqxFGckGmoxFxUnAgB/3tFizwIAAA== Archived-At: Subject: [secdir] early review request for draft-ietf-tsvwg-transport-encrypt 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, 13 Nov 2018 15:28:31 -0000 Hi folks, I put up an early review request at https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/reviewrequest/11283/ for this document, with a comment that a reviewer who has been following the QUIC discussions would be preferred. Feel free to volunteer before Tero runs the assignments queue on Thursday :) (And there's no real harm in having more than one pair of eyes on it at this point, I think, if you want to take a look otherwise.) Thanks, Ben From nobody Tue Nov 13 07:29:37 2018 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 BE14E130DFC for ; Tue, 13 Nov 2018 07:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 tJtAgQg8as03 for ; Tue, 13 Nov 2018 07:29:30 -0800 (PST) Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 F2B4F130E5D for ; Tue, 13 Nov 2018 07:29:29 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.22/8.16.0.22) with SMTP id wADFMLpZ027502; Tue, 13 Nov 2018 07:29:29 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=KkbZDuJqUz7mSp4EZEdxD32yqrqRqYAtCYlRg+wiLXc=; b=m5xdVE51taevjPKj6fE8Yo2mbo4Rcnde/oqnMNGAqQmJrcMsYKCkjYWAxU7Oek2CilNv k9Ct7GuJ74dg16qJ243PCEu2CqPBLhVojrKdPBzQT/nrCHwxHlMLZ9t256F3+dNr9pq1 L1BQI8Wiu/9PpaWDdW6v7WIcT/It0hVwPTyPDiPUYNFPwEaOnD8GogPH9Ksi8s1w2U9u fRlZAB4zntmTZNajzmfIii+aCKjKAPPyxNq335GyiAWVfYAdhM608cxBFBjGI812QvD7 3wTOBMLxf1bxZ4emwr8RLn4Y7A38hWSkZO3MkTU69MgoRoZJZCLQHoIbWIkEydBjbB/q qQ== Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2nny592rvv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 13 Nov 2018 07:29:29 -0800 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PI500FRF1P5JXG0@mr2-mtap-s03.rno.apple.com>; Tue, 13 Nov 2018 07:29:29 -0800 (PST) Received: from process_viserion-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PI500B0015TEC00@nwk-mmpp-sz13.apple.com>; Tue, 13 Nov 2018 07:29:29 -0800 (PST) X-V-A: X-V-T-CD: 1b69ab495d51437eebdc4a59e06348af X-V-E-CD: ee4fc724a3bb0575f147016b1348e177 X-V-R-CD: b297fed395f8c82ffa9f9d0f0a362d14 X-V-CD: 0 X-V-ID: b485dfad-e0f8-4dd1-9ae9-8b908efc2134 Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PI500G001GNEW00@nwk-mmpp-sz13.apple.com>; Tue, 13 Nov 2018 07:29:22 -0800 (PST) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-11-13_09:,, signatures=0 Received: from [17.234.97.95] by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PI50016J1OYCV10@nwk-mmpp-sz13.apple.com>; Tue, 13 Nov 2018 07:29:22 -0800 (PST) Sender: cawood@apple.com From: Christopher Wood In-reply-to: <20181113152821.GJ99562@kduck.kaduk.org> Date: Tue, 13 Nov 2018 07:29:21 -0800 Cc: secdir@ietf.org Content-transfer-encoding: quoted-printable Message-id: <8C3B6A8C-06A8-4295-B565-8D0218E57603@apple.com> References: <20181113152821.GJ99562@kduck.kaduk.org> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3501) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-13_09:, , signatures=0 Archived-At: Subject: Re: [secdir] early review request for draft-ietf-tsvwg-transport-encrypt 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, 13 Nov 2018 15:29:36 -0000 I=E2=80=99m happy to review it. Best, Chris > On Nov 13, 2018, at 7:28 AM, Benjamin Kaduk wrote: >=20 > Hi folks, >=20 > I put up an early review request at > = https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/review= request/11283/ > for this document, with a comment that a reviewer who has been = following > the QUIC discussions would be preferred. Feel free to volunteer = before > Tero runs the assignments queue on Thursday :) > (And there's no real harm in having more than one pair of eyes on it = at > this point, I think, if you want to take a look otherwise.) >=20 > Thanks, >=20 > Ben >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Thu Nov 15 21:55:12 2018 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 7FBF1130E44 for ; Thu, 15 Nov 2018 21:55:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <154234770951.10115.7942052297810326834.idtracker@ietfa.amsl.com> Date: Thu, 15 Nov 2018 21:55:09 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 05:55:10 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2018-11-21 Reviewer LC end Draft Kathleen Moriarty 2018-10-19 draft-ietf-ntp-mac-05 Melinda Shore 2018-11-06 draft-ietf-dmarc-arc-protocol-21 Samuel Weiler 2018-11-13 draft-ietf-dnsop-dns-capture-format-08 For telechat 2018-12-06 Reviewer LC end Draft Steve Hanna 2018-10-03 draft-ietf-detnet-problem-statement-07 Last calls: Reviewer LC end Draft John Bradley 2018-11-26 draft-ietf-ippm-port-twamp-test-03 John Bradley 2018-09-25 draft-ietf-dnsop-attrleaf-fix-06 John Bradley 2018-06-18 draft-ietf-bfd-multipoint-active-tail-09 Daniel Gillmor 2018-06-25 draft-ietf-dnsop-session-signal-18 Daniel Gillmor 2018-03-19 draft-gutmann-scep-10 Phillip Hallam-Baker 2018-10-11 draft-ietf-softwire-yang-12 Matthew Miller 2018-10-12 draft-ietf-httpbis-rand-access-live-03 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Magnus Nystrom 2018-11-13 draft-op3ft-leaptofrogans-uri-scheme-03 Vincent Roca 2018-10-29 draft-ietf-pce-gmpls-pcep-extensions-12 Joseph Salowey 2018-11-20 draft-wilde-sunset-header-07 Stefan Santesson 2018-11-20 draft-wilde-service-link-rel-06 Samuel Weiler 2018-05-21 draft-ietf-bfd-multipoint-18 Brian Weis 2018-11-23 draft-ietf-dots-requirements-16 Christopher Wood 2018-11-27 draft-ietf-nfsv4-mv0-trunking-update-02 Liang Xia 2018-11-28 draft-ietf-alto-xdom-disc-04 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-09 Taylor Yu 2018-10-09 draft-murchison-tzdist-tzif-15 Early review requests: Reviewer Due Draft Derek Atkins 2018-12-05 draft-ietf-dnssd-mdns-relay-01 Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Sean Turner 2018-11-25 draft-ietf-babel-dtls-02 Christopher Wood 2018-12-04 draft-ietf-tsvwg-transport-encrypt-01 Paul Wouters 2018-12-31 draft-ietf-taps-transport-security-04 Next in the reviewer rotation: John Bradley Nancy Cam-Winget Shaun Cooley Roman Danyliw Alan DeKok Linda Dunbar Donald Eastlake Shawn Emery Stephen Farrell Daniel Franke From nobody Fri Nov 16 00:48:27 2018 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 18C1112D4F2; Fri, 16 Nov 2018 00:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 flfoVDu1krnD; Fri, 16 Nov 2018 00:48:24 -0800 (PST) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24CF6124D68; Fri, 16 Nov 2018 00:48:24 -0800 (PST) Received: by mail-pg1-x52c.google.com with SMTP id z10so10310592pgp.7; Fri, 16 Nov 2018 00:48:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=/O+UNyL4EL6NRBBpQItQa0ac22Vj0KpFq/6tvjWTrpc=; b=dENCqoSa+759+DLnqcBnVo3hl9nOKuSXniRoqabbvbejzjou10Jk/HoLbh6k3oOnQj A/wzpR/bc1Wii6AcQG7wM+hOmpPxKmJcGxJ1G0P40flfcKJ/uKsY2dV/G589RbVVRtLr 5TOEdL/fyb4WdUFubR1rSkPTGQA/0w2TmyVHB0UPeQUniMIje3sk00I3ltDMR+Rl8i/F lQcjxj0/9+WiESP+hfBJVhEPihs1AkXnbfb8P/WPrMqzZobdMEPvd7WKuVXBgQG/BDrt bIRyhqzJeAWaB/7cIlo2j4aC8XcaHe3VtxbrErSP60xYKAWubWK9DHfyvOG2z176DJIE eHYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=/O+UNyL4EL6NRBBpQItQa0ac22Vj0KpFq/6tvjWTrpc=; b=RdIcQsC85yvOpLLSRQ09WSBgChsixxWzvt9KY2TC6yd+L9SWTDPKCG5d76uuHrZECT mgFX0tWzwR2ZQlnsF9UFvjQ4QuSqVo/OJzCMtqED5PhD1AihgTDS4X1SWkNngpqoVc38 sm4gU+v1j1lLplMCIAdGtzPdRkQ5OZ08OzVVfExv3hEj7+TbLvEfJpd5P3297vIDdzcp FmENvnEHgV7Ak+pBpJSe7FwgppFNPk0NCc3PeHK7/zlPJebMYui+sxdPK+3tSC5AXhP6 BgzKf5xQ1GZjXy16NgUaBmWsfu611PZ5pJ9LRkO5LX2no229K+mkyMUxl8uOVq7masjD Qisw== X-Gm-Message-State: AGRZ1gKP44fftw/xw5G+CbCj0jpJVyjuUODh4n6EPXXKriDEoJ9dqdL4 S3gE4iAHWODWZvyvsYh/dQwOwT94VJj6SxiPCNmKH86t X-Google-Smtp-Source: AJdET5dj427sEPgXfGpkuMW3orDwHM4pY7Fannh5K1Tux6o3cLxtGWjpXzrCoJawUKu6J9mbuKORcgfXEI0kcqQGt2E= X-Received: by 2002:a62:5003:: with SMTP id e3mr10444734pfb.23.1542358103176; Fri, 16 Nov 2018 00:48:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Thu, 15 Nov 2018 22:47:49 -1000 Message-ID: To: secdir@ietf.org, draft-op3ft-leaptofrogans-uri-scheme@ietf.org Content-Type: multipart/alternative; boundary="000000000000db3be5057ac43a1e" Archived-At: Subject: [secdir] Secdir review of draft-op3ft-leaptofrogans-uri-scheme-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2018 08:48:26 -0000 --000000000000db3be5057ac43a1e Content-Type: text/plain; charset="UTF-8" I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies the "leaptofrogans" URI scheme. Its security considerations section provides a discussion of common URI risks and how they apply to the frogans URIs. I do wonder a bit about the statement that "[the] risk of confusion i[due to the true address being hidden in the link text visible to the user] is mitigated because Frogans Player must always display the real Frogans address contained in the URI" - does this necessarily also apply to "inbound" direction cases - i.e., when a regular browser displays a link which allows the user to launch a frogans site? (Unrelated, the "leaptofrogans" name seems long. The scheme part of URIs is typically the name of a protocol or similar. In the frogans case, "fsdl" comes to mind as iI understand it to be the language used to create frogans sites (I do not know what protocol is used to commuicate with such sites).) Thanks, -- Magnus --000000000000db3be5057ac43a1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate's ong= oing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the=C2=A0 security area directors.=C2=A0 Document editors and WG chairs should treat = these comments just like any other last call comments.

This document specifies the "leaptofrogans" U= RI scheme. Its security considerations section provides a discussion of com= mon URI risks and how they apply to the frogans URIs. I do wonder a bit abo= ut the statement that "[the] risk of confusion i[due to the true add= ress being hidden in the link text visible to the user] is mitigated becaus= e Frogans Player must always display the real Frogans address contained i= n the URI" - does this necessarily also apply to "inbound" d= irection cases - i.e., when a regular browser displays a link which allows = the user to launch a frogans site?

(Unrelated, the "leaptofrogans" name se= ems long. The scheme part of URIs is typically the name of a protocol or si= milar. In the frogans case, "fsdl" comes to mind as iI understand= it to be the language used to create frogans sites (I do not know what pro= tocol is used to commuicate with such sites).)
Thanks,
-- Magnus
--000000000000db3be5057ac43a1e-- From nobody Sun Nov 18 15:57:22 2018 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 D67E7126BED; Sun, 18 Nov 2018 15:57:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey To: Cc: draft-wilde-sunset-header.all@ietf.org, iesg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154258543276.2473.3583674797158875383@ietfa.amsl.com> Date: Sun, 18 Nov 2018 15:57:12 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-wilde-sunset-header-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2018 23:57:13 -0000 Reviewer: Joseph Salowey Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document has some minor issues. Security considerations - in addition to Jari's comment of lifetime may be sensitive I have concerns about linked resource. For example, the link may refer to another site which could compromise privacy or security if the link was followed. The linked resource seems under-defined, which might lead to security issues if implementations make assumptions about the content of the link. From nobody Mon Nov 19 05:07:55 2018 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 7A55E130DC7; Mon, 19 Nov 2018 05:07:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: Cc: ntp@ietf.org, ietf@ietf.org, draft-ietf-ntp-mac.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154263286847.5244.1901741776809018326@ietfa.amsl.com> Date: Mon, 19 Nov 2018 05:07:48 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-ntp-mac-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, 19 Nov 2018 13:07:48 -0000 Reviewer: Kathleen Moriarty Review result: Ready Thank you for your work on this draft. It's a straightforward document to improve security, deprecating MD5 and recommending use of AES-CMAC. From nobody Tue Nov 20 02:42:14 2018 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 00B68128CF2; Tue, 20 Nov 2018 02:42:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stefan Santesson To: Cc: draft-wilde-service-link-rel.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154271053296.18399.13259125328255756754@ietfa.amsl.com> Date: Tue, 20 Nov 2018 02:42:12 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-wilde-service-link-rel-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: Tue, 20 Nov 2018 10:42:13 -0000 Reviewer: Stefan Santesson Review result: Has Issues Even though this document is quite repetitive when describing its fundamental concepts, I still had a problem figuring out whether the link relations defined are applicable to any web resource, or just to "web services" in the context of "service provided to another service". I have no issues with the fundamental concept, but the document lacks security considerations. The content of the section is "..." indicating that something eventually is intended to go here, but has not yet been written. If there are absolutely no security considerations, then the section should say so. I do however think that there are some useful security considerations to document. At least it may be useful to have a small discussion to consider what information about a service that is helpful to a user, and which could be used by an attacker, and find a good balance. As a nit I would suggest shortening some of the fundamental description in the early introduction that is being repeated in the document. The document is rather short and therefore does not benefit from saying the same things many times. From nobody Tue Nov 20 13:06:27 2018 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 760B8130DCC; Tue, 20 Nov 2018 13:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=dret.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 wDcIVgGoj7Cs; Tue, 20 Nov 2018 13:06:13 -0800 (PST) Received: from postoffice.gristmillmedia.com (dret.net [209.188.86.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F424124D68; Tue, 20 Nov 2018 13:06:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dret.net; s=default; 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=qLbDBGoBQv7BtdRQIVVWK5YRVSL9k90aaeCCqIxgt1U=; b=LDtgfCjqmO3f+peTPtXu/w2vK4 8srkI0FKl89rCUuB0CQ/ONJ0WrHofxgxTLT21gn4JOftTspJfkGf5lZbGNOKw3O2szIUXW+/PzKQF WE5wtjF85TO3ccgt/gqAa2PWhjRVnFfVATDyQRFRVLU/GMbaGT+WZpwxQSZVDOop0zJocIORfPR2b 387WDyJESm3rcx71fMoUUWU9opEAWqjfB3xBiyviPD74KW6Cl5tWAxvpMj7kfueCSpzfWyG/BALiz Dvs3SU9OUjizZ2B5xB+HDWRgAJU7YnCCk9UvjNCWQDN2m4xMv4TiEL1aJ6/4T5gJjpJos1FwvhX6V W8uZuEeQ==; Received: from [82.194.106.114] (port=53747 helo=dretbook.local) by postoffice.gristmillmedia.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gPDDj-00078d-0s; Tue, 20 Nov 2018 16:06:07 -0500 To: Stefan Santesson , secdir@ietf.org Cc: draft-wilde-service-link-rel.all@ietf.org, ietf@ietf.org References: <154271053296.18399.13259125328255756754@ietfa.amsl.com> From: Erik Wilde Message-ID: <7010d946-1d16-30c8-23c0-b28d46a7a154@dret.net> Date: Tue, 20 Nov 2018 22:06:05 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <154271053296.18399.13259125328255756754@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - postoffice.gristmillmedia.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dret.net X-Get-Message-Sender-Via: postoffice.gristmillmedia.com: authenticated_id: birdhouse@dret.net X-Authenticated-Sender: postoffice.gristmillmedia.com: birdhouse@dret.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [secdir] Secdir last call review of draft-wilde-service-link-rel-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: Tue, 20 Nov 2018 21:06:15 -0000 hello. thanks, stefan, for the review! On 2018-11-20 11:42, Stefan Santesson wrote: > Even though this document is quite repetitive when describing its fundamental > concepts, I still had a problem figuring out whether the link relations defined > are applicable to any web resource, or just to "web services" in the context of > "service provided to another service". in theory they apply to any web resource, but in practice descriptions and documentation in most cases will only be published for sets of resources, which this draft calls "web services". i myself am not a huge fan of this terminology, but it seems to be what most people are using. > I have no issues with the fundamental concept, but the document lacks security > considerations. The content of the section is "..." indicating that something > eventually is intended to go here, but has not yet been written. If there are > absolutely no security considerations, then the section should say so. > > I do however think that there are some useful security considerations to > document. At least it may be useful to have a small discussion to consider what > information about a service that is helpful to a user, and which could be used > by an attacker, and find a good balance. thanks for this suggestion. i have added this at https://github.com/dret/I-D/commit/3f065e662ccd66419c92246a2bba9bd8c5127ade, which adds security considerations. > As a nit I would suggest shortening some of the fundamental description in the > early introduction that is being repeated in the document. The document is > rather short and therefore does not benefit from saying the same things many > times. i agree that there are repetitions. they are intentional, as the goal has been to make the individual sections as self-contained as possible, so that users looking for the definitions of the individual link relations can look them up and just read the individual definitions. i think with these changes in the draft i have addressed the comments in this review. i have posted a new version of the draft that includes the changes mentioned here. https://tools.ietf.org/html/draft-wilde-service-link-rel-07 thanks again and kind regards, dret. -- erik wilde | mailto:erik.wilde@dret.net | | http://dret.net/netdret | | http://twitter.com/dret | From nobody Wed Nov 21 15:12:41 2018 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 A251B130E62; Wed, 21 Nov 2018 15:00:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1542841203; bh=vg7ay9YUp/IgA4BgDmMc2ya7cMbddfIN40mOECQv+R4=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=OA69+GG5HYuL98pzI8TaAQZw1ngflPVMB7HS4xTl0+Z43nTLgxnW3hcRYVUDnC2su qXbynrblYsuc7cabdhRCpnydRwBHuqh/5PHbb8d9zRdTGaWTSohH2vPT45aXa94eAv wk/7jLALdMcBQyeE6E+J5uSIY/96y+MVEqmHnVkw= X-Mailbox-Line: From new-work-bounces@ietf.org Wed Nov 21 14:59:52 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF392130DD4; Wed, 21 Nov 2018 14:59:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1542841169; bh=vg7ay9YUp/IgA4BgDmMc2ya7cMbddfIN40mOECQv+R4=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=OPkSj0i1LTpoYvi9rqyVHG2uMfKSWOeYOkcJ1S8LBLLFcvtQ+Iu11uTLENU7AYw3V pn7u5QGQZEmPcC8FuHatQi48PUGORICmWiM/E+fgxEg5UEk6XV9YHSsVivO9KwG+cF 6IOjC6xHNLjbsDPn01reLeFNq8Q6Qiw847ULEftY= 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 3C505130DD6 for ; Wed, 21 Nov 2018 14:59:20 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <154284116024.5109.11394459476555840268.idtracker@ietfa.amsl.com> Date: Wed, 21 Nov 2018 14:59:20 -0800 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: Wed, 21 Nov 2018 15:12:39 -0800 Subject: [secdir] [new-work] WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 23:00:10 -0000 The Domain-based Message Authentication, Reporting & Conformance (dmarc) WG in the Applications and Real-Time 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 2018-12-03. Domain-based Message Authentication, Reporting & Conformance (dmarc) ----------------------------------------------------------------------- Current status: Active WG Chairs: Barry Leiba Ned Freed Tim Draegen Assigned Area Director: Alexey Melnikov Applications and Real-Time Area Directors: Adam Roach Ben Campbell Alexey Melnikov Mailing list: Address: dmarc@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/dmarc Archive: https://mailarchive.ietf.org/arch/browse/dmarc/ Group page: https://datatracker.ietf.org/group/dmarc/ Charter: https://datatracker.ietf.org/doc/charter-ietf-dmarc/ Domain-based Message Authentication, Reporting & Conformance (DMARC) uses existing mail authentication technologies (SPF and DKIM) to extend validation to the RFC5322.From field. DMARC uses DNS records to add policy-related requests for receivers and defines a feedback mechanism from receivers back to domain owners. This allows a domain owner to advertise that mail can safely receive differential handling, such as rejection, when the use of the domain name in the From field is not authenticated. Existing deployment of DMARC has demonstrated utility at internet scale, in dealing with significant email abuse, and has permitted simplifying some mail handling processes. However, DMARC is problematic for mail that does not flow from operators having a relationship with the domain owner, directly to receivers operating the destination mailbox (for example, mailing lists, publish-to-friend functionality, mailbox forwarding via ".forward", and third-party services that send on behalf of clients). The working group will explore possible updates and extensions to the specifications in order to address limitations and/or add capabilities. It will also provide technical implementation guidance and review possible enhancements elsewhere in the mail handling sequence that could improve DMARC compatibility. The existing DMARC base specification is published as Informational RFC 7489 in the Independent Stream. Specifications produced by the working group will ensure preservation of DMARC utility for detecting unauthorized use of domain names, while improving the identification of legitimate sources that do not currently conform to DMARC requirements. Issues based on operational experience and/or data aggregated from multiple sources will be given priority. The working group will seek to preserve interoperability with the installed base of DMARC systems, and provide detailed justification for any non-interoperability. As the working group develops solutions to deal with indirect mail flows, it will seek to maintain the end-to-end nature of existing identifier fields in mail, in particular avoiding solutions that require rewriting of originator fields. Working group activities will pursue three tracks: 1. Addressing the issues with indirect mail flows The working group will specify mechanisms for reducing or eliminating the DMARC's effects on indirect mail flows, including deployed behaviors of many different intermediaries, such as mailing list managers, automated mailbox forwarding services, and MTAs that perform enhanced message handling that results in message modification. Among the choices for addressing these issues are: - A form of DKIM signature that is better able to survive transit through intermediaries. - Collaborative or passive transitive mechanisms that enable an intermediary to participate in the trust sequence, propagating authentication directly or reporting its results. - Message modification by an intermediary, to avoid authentication failures, such as by using specified conventions for changing the aligned identity. Consideration also will be given to survivable authentication through sequences of multiple intermediaries. 2. Reviewing and improving the base DMARC specification The working group will not develop additional mail authentication technologies, but may document authentication requirements that are desirable. The base specification relies on the ability of an email receiver to determine the organizational domain responsible for sending mail. An organizational domain is the 'base' name that is allocated from a public registry; examples of registries include ".com" or ".co.uk". While the common practice is to use a "public suffix" list to determine organizational domain, it is widely recognized that this solution will not scale, and that the current list often is inaccurate. The task of defining a standard mechanism for identifying organizational domain is out of scope for this working group. However the working group can consider extending the base DMARC specification to accommodate such a standard, should it be developed during the life of this working group. Improvements in DMARC features (identifier alignment, reporting, policy preferences) will be considered, such as: - Enumeration of data elements required in "Failure" reports (specifically to address privacy issues) - Handling potential reporting abuse - Aggregate reporting to support additional reporting scenarios - Alternate reporting channels - Utility of arbitrary identifier alignment - Utility of a formalized policy exception mechanism 3. DMARC Usage The working group will document operational practices in terms of configuration, installation, monitoring, diagnosis and reporting. It will catalog currently prevailing guidelines as well as developing advice on practices that are not yet well-established but which are believed to be appropriate. The group will consider separating configuration and other deployment information that needs to be in the base spec, from information that should be in a separate guide. Among the topics anticipated to be included in the document are: - Identifier alignment configuration options - Implementation decisions regarding "pct" - Determining effective RUA sending frequency - Leveraging policy caching - Various options for integrating within an existing flow - Defining a useful, common set of options for the addresses to which feedback reports are to be sent - When and how to use local policy override options 4. Related work Extensions to SPF/DKIM/DMARC that do not already fit under the charter of any existing working group can be considered for adoption by DMARC Working Group after consultation with the responsible AD. A prime example is draft-levine-appsarea-eaiauth, which provides EAI-related updates to DMARC and the protocols upon which it depends. Any such work needs to carefully consider interoperability implications. Work Items ---------- Phase I: Draft description of interoperability issues for indirect mail flows and plausible methods for reducing them. This is now complete and published as RFC 7960. Phase II: Specification of DMARC improvements to support indirect mail flows; this is now complete as draft-ietf-dmarc-arc-protocol (ARC). Draft Guide on DMARC Usage. Phase III: Review and refinement of the DMARC specification. Completion of Guide on DMARC and ARC Usage. References ---------- DMARC - http://dmarc.org SPF - RFC7208 Authentication-Results Header Field - RFC7001 DKIM - RFC6376 Internet Message Format - RFC5322 OAR / Original Authentication Results - draft-kucherawy-original-authres Using DMARC - draft-crocker-dmarc-bcp-03 Delegating DKIM Signing Authority - draft-kucherawy-dkim-delegate-00 DKIM Third-Party Authorization Label - draft-otis-dkim-tpa-label-03 Milestones: Done - Complete Authenticated Received Chain (ARC) protocol spec Jan 2019 - Complete EAI update to SPF/DKIM/DMARC Feb 2019 - Complete Authenticated Received Chain (ARC) usage recommendations _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Wed Nov 21 15:12:47 2018 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 AADEA130DD3; Wed, 21 Nov 2018 15:02:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1542841340; bh=ThBBcbYQrixLvzL2ZVe+qlI/PX5NZz+roB3QqtkMw+8=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=DxQamcQQrL4U5Pe45uMtRa7aETa4ESynh2DJJHpKCjF1CwtE8LlbNQhy5+bnr6t+7 s7BKeImEvV5eOcB+Lhy/bFpLOm/Vep7JDJKj7W7g7D4yqmQZVIffWWPSSiPklCEVUg AVxlOed+42prBt2ZMnx0vKobtfE5NlPIO+XpgfeE= X-Mailbox-Line: From new-work-bounces@ietf.org Wed Nov 21 15:02:09 2018 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2913F130DDD; Wed, 21 Nov 2018 15:01:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1542841288; bh=ThBBcbYQrixLvzL2ZVe+qlI/PX5NZz+roB3QqtkMw+8=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=h1Mdm0HO5OIzB6k+lJwo1xdy2sCtRHRPu+UZgDvIEp4uhEquibFJfrxhTGJaGzycp DwgUJpKHjkgHTSYZuyMEoWsZgKn5SJj/D0mNlBDpHA8pOnwsLBFLTc4OoVl1qGc/lM C6WXXlUhRIjPIUnb2E+6lXXO4CYR9MtUSmdmsI5s= 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 739FA130E57 for ; Wed, 21 Nov 2018 15:01:09 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <154284126946.5258.4475194495784671840.idtracker@ietfa.amsl.com> Date: Wed, 21 Nov 2018 15:01:09 -0800 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: Wed, 21 Nov 2018 15:12:39 -0800 Subject: [secdir] [new-work] WG Review: Hypertext Transfer Protocol (httpbis) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 23:02:29 -0000 The Hypertext Transfer Protocol (httpbis) WG in the Applications and Real-Time 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 2018-12-03. Hypertext Transfer Protocol (httpbis) ----------------------------------------------------------------------- Current status: Active WG Chairs: Patrick McManus Tommy Pauly Mark Nottingham Assigned Area Director: Alexey Melnikov Applications and Real-Time Area Directors: Adam Roach Ben Campbell Alexey Melnikov Technical advisors: Allison Mankin Mailing list: Address: ietf-http-wg@w3.org To subscribe: ietf-http-wg-request@w3.org Archive: http://lists.w3.org/Archives/Public/ietf-http-wg/ Group page: https://datatracker.ietf.org/group/httpbis/ Charter: https://datatracker.ietf.org/doc/charter-ietf-httpbis/ This Working Group is charged with maintaining and developing the "core" specifications for HTTP, and generic extensions to it (i.e., those that are not specific to one application). Its current work items are: # HTTP/1.1 Revision After the revision of the core HTTP document set in the RFC723x series, the Working Group published HTTP/2, which defines an alternative mapping of HTTP's semantics to TCP, and introduced new capabilities, like Server Push. Additionally, several ambiguities, interoperability issues and errata have been identified since their publication. The Working Group will refine the "core" HTTP document set (RFC 7230-RFC 7237) to: * Incorporate errata * Address ambiguities * Fix editorial problems which have led to misunderstandings of the specification * Clarify conformance requirements * Remove known ambiguities where they affect interoperability * Clarify existing methods of extensibility * Remove or deprecate those features that are not widely implemented and also unduly affect interoperability * Where necessary, add implementation advice In doing so, it should consider: * Implementer experience * Demonstrated use of HTTP * Impact on existing implementations and deployments # HTTP and QUIC Upon request from the QUIC Working Group, the HTTPBIS Working Group will review the QUIC Working Group's documents regarding the use of HTTP over the transport protocol they define, providing feedback and collaborating where necessary. Once the QUIC Working Group publishes the expression of HTTP semantics in QUIC (HTTP/3), the HTTPBIS Working Group will maintain and develop extensions for HTTP/3 as necessary. This includes ancillary specifications (e.g. QPACK). # Other HTTP-Related Work The Working Group may define extensions and other documents related to HTTP as work items, provided that: * They are generic; i.e., not specific to one application using HTTP. Note that Web browsing by definition is a generic use. * The Working Group Chairs judge that there is consensus to take on the item and believe that it will not interfere with the work described above, and * The Area Director approves the addition and add corresponding milestones. Milestones: May 2016 - Submit the Key HTTP Response Header Field for consideration as a Proposed Standard _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Thu Nov 22 02:21:15 2018 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 E30BC128B14 for ; Thu, 22 Nov 2018 02:21:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <154288207387.9605.5119787664485221779.idtracker@ietfa.amsl.com> Date: Thu, 22 Nov 2018 02:21:13 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 10:21:14 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2018-12-06 Reviewer LC end Draft Steve Hanna 2018-10-03 draft-ietf-detnet-problem-statement-07 Last calls: Reviewer LC end Draft John Bradley 2018-11-26 draft-ietf-ippm-port-twamp-test-03 John Bradley 2018-09-25 draft-ietf-dnsop-attrleaf-fix-07 John Bradley 2018-06-18 draft-ietf-bfd-multipoint-active-tail-09 Nancy Cam-Winget 2018-12-03 draft-ietf-opsec-ipv6-eh-filtering-06 Daniel Gillmor 2018-06-25 draft-ietf-dnsop-session-signal-18 Daniel Gillmor 2018-03-19 draft-gutmann-scep-10 Phillip Hallam-Baker 2018-10-11 draft-ietf-softwire-yang-12 Matthew Miller 2018-10-12 draft-ietf-httpbis-rand-access-live-03 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Vincent Roca 2018-10-29 draft-ietf-pce-gmpls-pcep-extensions-12 Melinda Shore 2018-11-06 draft-ietf-dmarc-arc-protocol-21 Samuel Weiler 2018-11-13 draft-ietf-dnsop-dns-capture-format-08 Samuel Weiler 2018-05-21 draft-ietf-bfd-multipoint-18 Christopher Wood 2018-11-27 draft-ietf-nfsv4-mv0-trunking-update-02 Liang Xia 2018-11-28 draft-ietf-alto-xdom-disc-04 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-09 Taylor Yu 2018-10-09 draft-murchison-tzdist-tzif-15 Early review requests: Reviewer Due Draft Derek Atkins 2018-12-05 draft-ietf-dnssd-mdns-relay-01 Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Sean Turner 2018-11-25 draft-ietf-babel-dtls-02 Christopher Wood 2018-12-04 draft-ietf-tsvwg-transport-encrypt-01 Paul Wouters 2018-12-31 draft-ietf-taps-transport-security-04 Next in the reviewer rotation: Roman Danyliw Alan DeKok Linda Dunbar Donald Eastlake Shawn Emery Stephen Farrell Daniel Franke Daniel Gillmor Tobias Gondrom Ólafur Guðmundsson From nobody Fri Nov 23 01:06:01 2018 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 5EE7F130DE5; Fri, 23 Nov 2018 01:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cF88LueGXS9; Fri, 23 Nov 2018 01:05:58 -0800 (PST) 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 1C242130DC3; Fri, 23 Nov 2018 01:05:53 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.56,269,1539640800"; d="scan'208,217";a="286549580" Received: from ral043r.vpn.inria.fr ([128.93.178.43]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Nov 2018 10:05:51 +0100 From: Vincent Roca Content-Type: multipart/alternative; boundary="Apple-Mail=_692A3B7B-DF6F-480D-9EF5-A4797B31D764" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Message-Id: Date: Fri, 23 Nov 2018 10:05:49 +0100 To: The IESG , secdir@ietf.org, draft-ietf-pce-gmpls-pcep-extensions.all@ietf.org X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: [secdir] Secdir review of draft-ietf-pce-gmpls-pcep-extensions-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2018 09:06:00 -0000 --Apple-Mail=_692A3B7B-DF6F-480D-9EF5-A4797B31D764 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, I have reviewed this document as part of the security directorate=E2=80=99= 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. Summary: Ready with issues The Security Considerations section provides a good introduction to the = risks. However my main concern is the lack of discussion around security = policies. After reading this section, we have the feeling that TLS alone is = sufficient to secure the GMPLS PCE WRT the three attacks described. With scenario 1, a fundamental part of the solution consists in setting up security policies: what is acceptable or not in terms of path? It may be discussed in the two references mentioned in the last = paragraph, but even in that case, the way the current section is written is = misleading. I have two additional comments: ** Ambiguous text: it is said o Message deciphering: As in the previous case, knowledge of an infrastructure can be obtained by sniffing PCEP messages. Message deciphering suggests the message is encrypted but the attacker has enough knowledge to decrypt it. I'm not sure it's what the authors = mean. I think there's a confusion in the use of "deciphering" which in = security explicitely refers to encryption (https://en.wikipedia.org/wiki/Cipher). ** Ambiguous text: it is said "Authentication can provide origin verification, message = integrity and replay protection,..." =C3=80uthentication of the two peers on the one hand, and = integrity/replay protection on the other hand, are different services. There's probably a package where these three services are bundled = together, but that's a design choice. I suggest changing a little bit the sentence to avoid this confusion. Typo: ** Section 6: "A legitimate PCC could requests" : s/requests/request/ Cheers, Vincent --Apple-Mail=_692A3B7B-DF6F-480D-9EF5-A4797B31D764 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

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

Summary: Ready with issues

The = Security Considerations section provides a good introduction to the = risks.
However my main concern is the lack of = discussion around security policies.
After reading = this section, we have the feeling that TLS alone is sufficient = to
secure the GMPLS PCE WRT the three attacks = described.
With scenario 1, a fundamental =  part of the solution consists in setting
up = security policies: what is acceptable or not in terms of path?
It may be discussed in the two references mentioned in the = last paragraph,
but even in that case, the way the = current section is written is misleading.


I = have two additional  comments:

** Ambiguous text: it is said

      =   o  Message deciphering: As in the previous case, knowledge = of an
            =   infrastructure can be obtained by sniffing PCEP = messages.

Message deciphering suggests the message is encrypted but the = attacker
has enough knowledge to decrypt it. I'm = not sure it's what the authors mean.
I think = there's a confusion in the use of "deciphering" which in = security
explicitely refers to encryption (https://en.wikipedia.org/wiki/Cipher).

** Ambiguous text: it is = said

  =       "Authentication can provide origin verification, = message integrity and replay protection,..."

=C3=80uthentication of the two peers on = the one hand, and integrity/replay
protection on = the other hand, are different services.
There's = probably a package where these three services are bundled = together,
but that's a design choice. I suggest = changing a little bit the sentence
to avoid this = confusion.


Typo:
** Section = 6: "A legitimate PCC could requests"  : = s/requests/request/

Cheers,

  Vincent




= --Apple-Mail=_692A3B7B-DF6F-480D-9EF5-A4797B31D764-- From nobody Fri Nov 23 01:37:43 2018 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 E1888130DFC; Fri, 23 Nov 2018 01:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=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 3sGn1CLlIsjE; Fri, 23 Nov 2018 01:37:32 -0800 (PST) Received: from p-mail-ext.rd.orange.com (p-mail-ext.rd.orange.com [161.106.1.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6AED812896A; Fri, 23 Nov 2018 01:37:32 -0800 (PST) Received: from p-mail-ext.rd.orange.com (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 073F156157A; Fri, 23 Nov 2018 10:37:12 +0100 (CET) Received: from p-mail-int.rd.francetelecom.fr (p-mail-int.rd.francetelecom.fr [10.192.117.12]) by p-mail-ext.rd.orange.com (Postfix) with ESMTP id 01E1E561575; Fri, 23 Nov 2018 10:37:12 +0100 (CET) Received: from p-mail-int.rd.francetelecom.fr (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C576D181516; Fri, 23 Nov 2018 10:37:14 +0100 (CET) Received: from [10.193.71.219] (l-at13891.rd.francetelecom.fr [10.193.71.219]) by p-mail-int.rd.francetelecom.fr (Postfix) with ESMTP id 974A01814E5; Fri, 23 Nov 2018 10:37:14 +0100 (CET) From: Julien Meuric To: Vincent Roca Cc: The IESG , secdir@ietf.org, draft-ietf-pce-gmpls-pcep-extensions.all@ietf.org References: Organization: Orange Message-ID: Date: Fri, 23 Nov 2018 10:37:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-PMX-Version: 6.4.6.2792898, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.11.23.93016, AntiVirus-Engine: 5.56.0, AntiVirus-Data: 2018.11.23.5560000 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, REFERENCES 0, SINGLE_URI_IN_BODY 0, URI_WITH_PATH_ONLY 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CP_NOT_1 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __DQ_NEG_HEUR 0, __DQ_NEG_IP 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __HIGHBITS 0, __HTTPS_URI 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MOZILLA_USER_AGENT 0, __MULTIPLE_RCPTS_CC_X2 0, __NO_HTML_TAG_RAW 0, __REFERENCES 0, __SANE_MSGID 0, __SINGLE_URI_TEXT 0, __SUBJ_ALPHA_NEGATE 0, __SUBJ_REPLY 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __URI_IN_BODY 0, __URI_NOT_IMG 0, __URI_NO_MAILTO 0, __URI_NO_WWW 0, __URI_NS , __URI_WITH_PATH 0, __USER_AGENT 0' Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-pce-gmpls-pcep-extensions-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2018 09:37:35 -0000 Merci Vincent ! Your review is appreciated. No doubt the authors will be able to address your comments. Cheers, Julien On 23/11/2018 10:05, Vincent Roca wrote: > Hello, > > I have reviewed this document as part of the security directorate’s > ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors.  Document editors and WG chairs should treat these comments > just > like any other last call comments. > > Summary: *Ready with issues* > > The Security Considerations section provides a good introduction to > the risks. > However my main concern is the lack of discussion around security > policies. > After reading this section, we have the feeling that TLS alone is > sufficient to > secure the GMPLS PCE WRT the three attacks described. > With scenario 1, a fundamental  part of the solution consists in setting > up security policies: what is acceptable or not in terms of path? > It may be discussed in the two references mentioned in the last paragraph, > but even in that case, the way the current section is written is > misleading. > > > I have two additional  comments: > > ** Ambiguous text: it is said > >         o  Message deciphering: As in the previous case, knowledge of an >               infrastructure can be obtained by sniffing PCEP messages. > > Message deciphering suggests the message is encrypted but the attacker > has enough knowledge to decrypt it. I'm not sure it's what the authors > mean. > I think there's a confusion in the use of "deciphering" which in security > explicitely refers to encryption (https://en.wikipedia.org/wiki/Cipher). > > ** Ambiguous text: it is said > >         "Authentication can provide origin verification, message > integrity and replay protection,..." > > Àuthentication of the two peers on the one hand, and integrity/replay > protection on the other hand, are different services. > There's probably a package where these three services are bundled > together, > but that's a design choice. I suggest changing a little bit the sentence > to avoid this confusion. > > > Typo: > ** Section 6: "A legitimate PCC could requests"  : s/requests/request/ > > Cheers, > >   Vincent > > > > From nobody Sun Nov 25 21:40:48 2018 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 2E268128CB7; Sun, 25 Nov 2018 21:40:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Paul Wouters To: Cc: ietf@ietf.org, draft-ietf-taps-transport-security.all@ietf.org, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154321083813.24275.4373340388504093292@ietfa.amsl.com> Date: Sun, 25 Nov 2018 21:40:38 -0800 Archived-At: Subject: [secdir] Secdir early review of draft-ietf-taps-transport-security-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: Mon, 26 Nov 2018 05:40:38 -0000 Reviewer: Paul Wouters Review result: Has Issues Review of draft-ietf-taps-transport-security-04 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 HAS ISSUES. SecDir tools note: The secdir review link refers to an abstract containing the text: This draft summarizes a number of IETF transport security protocols a Note the word "IETF ... protocols". I don't actually see that in any of the revisions 00 to 04? Where did this comment/text come from? Reading the introduction, this draft's goal is: This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog transport services [RFC8095] by describing the interfaces required to add security protocols. My first comment is regarding "commonly used or notable". Especially the latter one is odd. Why should the IETF reader be aware of "notable" but "not commonly used" protocols? And the reason I say this is because it lists CurveCP and MinimalT, which as far as I know are not deployed at all. While openvpn, which has a serious userbase, is not mentioned at all. And openconnect, an open specification compatible with Cisco Anyconnect, which even has a draft, draft-mavrogiannopoulos-openconnect-02, is not mentioned at all. In my opinion, the document would be improved by adding Openvpn and Openconnect, and removing CurveCP and MinimalT. My second comment is regarding IETF vs non-IETF protocols. Or even "specified in a draft or RFC" versus "there is an academic paper and some implementation and it's not clear what's what". The reason I am saying this is that for instance the protocol "specification" of WireGuard keeps changing. Their website lists a "whitepaper" that is changing over time with no changelog, and wild claims that I've spend time in the last few years to counter, upon which it gets rewritten with new misleading or wrong claims. It is kind of hard to do an IETF style summary of protocols when the "specification" includes phrases like: the tunnel simply works. Key exchanges, connections, disconnections, reconnections, discovery, and so forth happen behind the scenes transparently and reliably, and the administrator does not need to worry about these details. In other words, from the perspective of administration, the WireGuard interface appears to be stateless. This is not a white paper but a Public Relations document. None of the other discussed protocols in this document require administrators to "worry" about those "details" either. At the IETF, we recommend IETF protocols. If someone comes up with an alternative protocol that accomplishes the same as an existing one, we tend to tell people to use the existing IETF protocol instead. Or, we think their new protocol merits further standarization, and we ask them to produce either a ISE or IETF stream document that people can reference, comment, improve and discuss openly on its technical merits. It is also clear the white paper is not a good complete formal specification like we do at IETF. For example, if there is packetloss, the "specification" does not at all specify which of the parties (or both?) are responsible for retransmission. Can one spoofed packet lead a WireGuard endpoint to retransmit its response repeatedly? This further weakens their "stateless" claim. (and if it sounds like I am being harsh, I know I am. It is because previously, I had to counter false claims about IPsec speed, and IKE "being noisy" where as having looked again at "the whitepaper" (which keeps changing every time I look at it) it seems to now have a new hobby horse in the word "stateless". the openvpn tun0: is also "stateless", so is the VTI IPsec based interface vti0: Because of these reasons, I am a bit worried that an IETF document is making any claims about WireGuard features, as there is no way to know what the protocol will be like by the time this document is published, and this document cannot even point to a stable reference of te specification at the time of review. If this document wants to mention WireGuard as a protocol to take note of, I would like to see at least some text there urging WireGuard to write up (and version) their protocol in an IETF draft/RFC or other proper/formal specification. Now, having said all of this about WireGuard, I do agree with mentioning WireGuard in this document as it does have an actual userbase. Let's just urge and help them with their specification. (and If the author(s) of WireGuard are reading this, I am more than happy to help you with this) As for CurveCP and MinimalT, as far as I can see, these are just academic exercises with no serious deployment. While the IRTF might be discussing the these, I don't think an IETF document should reference these two proof of concept ideas until they have matured more. Introduction / Abstract: Expand/explain TAPS on first use? Section 4.4.1.1: IKEv2 is a control protocol that runs on UDP port 500 Change to: IKEv2 is a control protocol that runs on UDP or TCP port 4500 and UDP port 500. Note you don't mention the one big drawback, that it cannot be run on any UDP port (although at least now we can run on any TCP port) which is an important problem when networks block IKE/IPsec on purpose compared to non-IETF VPN protocols. It then goes through a phase of authentication in which both peers present blobs signed by a shared secret or private key, after which another set of keys is derived, referred to as the "Child SA". These Child SA keys are used by ESP. This text makes it appear only the blob's are authenticated, but the entire IKE exchange is authenticated. Also sessions keys are not all that is a Child SA. So perhaps: IKE then performs a phase of authentication in which both peers present blobs signed by a shared secret or private key that authenticates the entire IKE exchange and the IKE identities. IKE then derives further sets of keys on demand, which together with traffic policies are referred to as the "Child SA". These Child SA keys are used by ESP. Each proposal may contain an encryption algorithm, an authentication algorithm This is a bit misleading with both the "may" and the lack of AEAD discussion? Perhaps: Each proposal contains an encryption with authentication algorithm or an AEAD algorithm, Any SA used by IKEv2 can be rekeyed upon expiration, Rekeying happens before expiration, not upon (which would imply trafficflow interuption) Similarly to how it is described for tcpcrypt in the document. So perhaps just change "upon" to "before" ? Or go in a little more detail with: Any SA used by IKE/IPsec can be rekeyed before expiration. It does so by negotiating a second SA, and once confirmed up and running, the old SA is deleted. This guarantees there is no slowdown or halt of traffic flow during rekeying. that allows a set of Security Associations to migrate over different addresses and interfaces I would say "different outer IP addresses and interfaces" Each SA is identified by a Security Parameter Index (SPI), which is marked on each encrypted ESP packet. I would avoid the word "mark" here, since to me that more presents internal state inside a kernel (eg iptables MARK) and not something that goes over the wire. So perhaps: The SA of an encrypted packet is identified by its Security Parameter Index (SPI) [which is send as part of the ESP header) an anti-replay service (a form of partial sequence integrity) What is partial about this? Perhaps you meant to say ESP, like UDP, does not provide guaranteed delivery? Anyway, a "partial" security function reads odd :) and limited traffic flow confidentiality. What is "limited" about it? You can generate bogus traffic and pad traffic to any size (most common max mtu). What would you want in additional to make it not "limited" ? One thing I would add to the ESP section is mentioning it acts like UDP. It cannot be reset by a single TCP RST packet, and you don't have two layers of netflows doing retransmission. This feature of ESP (and some UDP based protocols in this document) is fairly important. Section 4.4.2.1: Mutual Authentication It is possible to do server-only or opportunistic/anonymous IKE as well. Maybe add "Usually" ? 4.6.1: Tcpcrypt exposes a universally-unique connection-specific session ID to the application, suitable for application-level endpoint authentication either in-band or out-of-band. This kind of conflicts with the introduction that claims this is only an opportunistic encryption protocol? Maybe merge this part into the description text? 4.6.2: I might say here something about only passive attacker protection? That seems like an important difference compared to the other protocols. Or perhaps make this clear in the introduction text when mentioning opportunistic encryption. 4.7: WireGuard is a layer 3 protocol designed to complement or replace IPsec [WireGuard] for certain use cases. I am confused about how it "complements" IPsec? Perhaps you mean it is an "alternative" (and perhaps a non-IETF alternative) ? I think "replace" is very misleading, as IPsec has a vast number of different use cases compared to WireGuard's "static VPN configuration". WireGuard is designed to be entirely stateless, modulo the CryptoKey routing table, Wouldn't you be able to say the same about the ESP SPD/SAD table? I'm not sure how different the ESP/wireguard statelessness is on a scale or truly stateless to NFS You don't mention anything about port preconfiguartion and the "port knocking" thing? o Record replay prevention (Stateful, timestamp-based). I thought it was stateless module CryptoKey routing? :) You do not mention mobility or session resumption for WireGuard. Since it is all about static inner IP addresses over arbitrary outer addresses, it has mobility. And I guess the 1RTT means it has session resumption? Can you add a description of rekeying for WireGuard similar to IKEv2/ESP? I thought there was an issue there that during rekey, there is no continued data flow possible, so connections briefly slow down or halt when the channel is being rekeyed. Does WireGuard not offer padding or any other kind of Traffic Confidentiality options ? 4.8: The MinimalT section seems to lack some information bullet points compared to the other sections? eg shouldn't it have things like: o Datagram Transport ? Misc: Should tor be added to the list of protocols? Why are MinimalT and CurveCP part of this list? Is there any actual deployment out there? I thought this document described actual transport security protocols people can pick. I don't see CurveCP as a real candidate for this. I don't know about MinimalT. 5: I'm a little confused by the term Application in this section. Is this the enduser application or the userland part of the security protocol (eg IKE). I think you mean the application of the enduser? 5.1: Listed as mandatory feature is: o Public-key certificate based authentication. Yet you have mentioned that neither WireGuard or CurveCP can do authentication based on certificates? 5.2: o Length-hiding padding (LHP): * Application dependency: Knowledge of desired padding policies. This is not (always?) true? For example ESP can do padding after IKE negotiated it, and do it based on MTU ? The (end user) application does not have to be aware of anything? 5.3: The definition of "Mandatory" within this section is confusing. Maybe use another word like "Core" to indicate it is part of the core of the protocol and cannot be disabled? NITS: spelling error: defailt From nobody Wed Nov 28 04:21:57 2018 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 078CD130DCE for ; Wed, 28 Nov 2018 04:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLI8eVbv8cqV for ; Wed, 28 Nov 2018 04:21:52 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6628012D4EF for ; Wed, 28 Nov 2018 04:21:52 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id wASCLm6b014711 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Nov 2018 14:21:48 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id wASCLmH5006451; Wed, 28 Nov 2018 14:21:48 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23550.34907.970599.4320@fireball.acr.fi> Date: Wed, 28 Nov 2018 14:21:47 +0200 From: Tero Kivinen To: Paul Wouters Cc: In-Reply-To: <154321083813.24275.4373340388504093292@ietfa.amsl.com> References: <154321083813.24275.4373340388504093292@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 18 min X-Total-Time: 18 min Archived-At: Subject: [secdir] Secdir early review of draft-ietf-taps-transport-security-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: Wed, 28 Nov 2018 12:21:55 -0000 Paul Wouters writes: > SecDir tools note: The secdir review link refers to an abstract > containing the text: > > This draft summarizes a number of IETF transport security > protocols a > > Note the word "IETF ... protocols". I don't actually see that in any of the > revisions 00 to 04? Where did this comment/text come from? When WG chair etc makes a request for an early review they will have option to include comment that explains what they want the reviewer to concentrate to. So this text you are refering to is the one written by Aaron Falk when he requested to early review and that included also comments like: The TAPS working group would appreciate early review from SecDir focusing on the correctness of the protocol descriptions and whether there are any significant gaps (protocols or features) in the coverage of the draft. The draft is nearing readiness for WGLC and some assurance from SecDir that there are no significant problems would be helpful before finalizing it. Please send comments to the TAPS wg . Thanks!! So that Comment section is not an abstract, it is additional text provided by the requestor... Looking at that comment and your review, I think your point about the openvpn and openconnect are just what they were looking at, i.e., gaps in their protocol list... -- kivinen@iki.fi From nobody Wed Nov 28 19:07:03 2018 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 1CC23130DF5; Wed, 28 Nov 2018 19:07:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liang Xia To: Cc: draft-ietf-alto-xdom-disc.all@ietf.org, ietf@ietf.org, alto@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154346082207.13636.11710948370196493817@ietfa.amsl.com> Date: Wed, 28 Nov 2018 19:07:02 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-alto-xdom-disc-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, 29 Nov 2018 03:07:02 -0000 Reviewer: Liang Xia Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document details applicable scenarios, itemizes requirements, and specifies a procedure for ALTO cross-domain server discovery. Technically, the procedure specified in this document takes one IP address or prefix and a U-NAPTR Service Parameter (typically, "ALTO:https") as parameters. It performs DNS lookups (for NAPTR resource records in the in-addr.arpa. or ip6.arpa. tree) and returns one or more URI(s) of information resources related to that IP address or prefix. In general, this draft is in good shape, including the security considerations part. I just have some general comments or confusions for discussion as below: 1. I don't see the content about the authorization policy for alto server information distribution, is it necessary? 2. If the replied alto server information message is much larger than the request message, the attack can trigger the reflection DDoS attack using it. Does it need to be considered? From nobody Thu Nov 29 03:55:20 2018 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 BB25A127333 for ; Thu, 29 Nov 2018 03:55:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <154349251876.25889.17872616889858345918.idtracker@ietfa.amsl.com> Date: Thu, 29 Nov 2018 03:55:18 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2018 11:55:19 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2018-12-06 Reviewer LC end Draft John Bradley 2018-11-26 draft-ietf-ippm-port-twamp-test-03 Steve Hanna 2018-10-03 draft-ietf-detnet-problem-statement-07 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-09 Last calls: Reviewer LC end Draft John Bradley 2018-06-18 draft-ietf-bfd-multipoint-active-tail-10 Nancy Cam-Winget 2018-12-03 draft-ietf-opsec-ipv6-eh-filtering-06 Roman Danyliw 2018-12-12 draft-ietf-lsr-isis-rfc7810bis-02 Alan DeKok 2018-12-11 draft-ietf-mpls-rsvp-shared-labels-06 Linda Dunbar 2018-12-11 draft-ietf-mpls-lsp-ping-lag-multipath-05 Donald Eastlake 2018-12-11 draft-ietf-httpbis-cdn-loop-01 Daniel Gillmor 2018-06-25 draft-ietf-dnsop-session-signal-18 Daniel Gillmor 2018-03-19 draft-gutmann-scep-10 Phillip Hallam-Baker 2018-10-11 draft-ietf-softwire-yang-12 Matthew Miller 2018-10-12 draft-ietf-httpbis-rand-access-live-03 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Melinda Shore 2018-11-06 draft-ietf-dmarc-arc-protocol-21 Samuel Weiler 2018-11-13 draft-ietf-dnsop-dns-capture-format-08 Samuel Weiler 2018-05-21 draft-ietf-bfd-multipoint-18 Klaas Wierenga 2018-09-06 draft-ietf-softwire-mesh-multicast-23 Christopher Wood 2018-11-27 draft-ietf-nfsv4-mv0-trunking-update-02 Taylor Yu 2018-10-09 draft-murchison-tzdist-tzif-15 Early review requests: Reviewer Due Draft Derek Atkins 2018-12-05 draft-ietf-dnssd-mdns-relay-01 Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Sean Turner 2018-11-25 draft-ietf-babel-dtls-02 Christopher Wood 2018-12-04 draft-ietf-tsvwg-transport-encrypt-03 Next in the reviewer rotation: Shawn Emery Stephen Farrell Daniel Franke Daniel Gillmor Tobias Gondrom Ólafur Guðmundsson Phillip Hallam-Baker Steve Hanna Dan Harkins Russ Housley From nobody Thu Nov 29 14:37:23 2018 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 F36A51276D0; Thu, 29 Nov 2018 14:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.401 X-Spam-Level: X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldjKHNv-v1dP; Thu, 29 Nov 2018 14:37:08 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FEB3128D68; Thu, 29 Nov 2018 14:37:04 -0800 (PST) Received: from dooku.sandelman.ca (unknown [148.122.187.2]) by relay.sandelman.ca (Postfix) with ESMTPS id 2E6AA1F8BD; Thu, 29 Nov 2018 22:37:02 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 98AA82878; Thu, 29 Nov 2018 17:36:14 -0500 (EST) From: Michael Richardson To: Jari Arkko , Christian Huitema cc: gen-art@ietf.org, draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, anima@ietf.org, secdir@ietf.org Reply-To: anima@ietf.org In-Reply-To: <153874289877.989.15433226866680411112@ietfa.amsl.com> References: <153826253306.18743.9250084704876465818@ietfa.amsl.com>, <153874289877.989.15433226866680411112@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [secdir] dealing with many the secdir and genart comments 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, 29 Nov 2018 22:37:10 -0000 --=-=-= Content-Type: text/plain {This is the first of many replies to the various reviews} Jari Arkko wrote: > My first bigger comment is that I believe the security and privacy > considerations section should have provided an actual in-depth > analysis of the characteristics offered by the protocol, perhaps under > several different situations, as the protocol can be operated in > different modes. The authors seriously believe that this will result in an attempt to boil the ocean. Yes, BRSKI is exciting for many and opens many doors, but in the context of the *ANIMA* Charter, we strongly think that this document should leave the oceans alone, and deal only with the ANIMA ACP usage. Other users of BRSKI *SHOULD* write a new profile. Would it be acceptable for us to provide a section that might be entitled: "The ACP mode of operation of BRSKI" or perhaps some other section that would clarify the applicability of this document? We would list the assumptions and maybe even reduce the options for use in the ACP? The authors do not object to writing more documents about more situations where BRSKI might be used, but we think that putting it all into one document is a way for continuing scope creep. In accepting the constrained work into the ANIMA WG, the chairs and area director have already been very generous. > My second comment is that the protocol as defined is quite focused on > manufacturer-controlled situations. As Christian mentioned, there is > some discussion of other situations in the document (Section 6.4), but > not much, and there's little information on what happens if one tries > to use the protocol in this way. The above comments would seem to apply to this as well. As I previously indicated when you first wrote this, we have turned your comments into a series of issues on github, and we will be closing those issues as quickly as we can. Some will come with proposed text changes, but a number will need discussion, and we will start new subject lines in this thread for them. I don't want to innudate you, so I've set the Reply-To. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAlwAad4ACgkQlUzhVv38 QpDB3Af/cSlqfuiNAEf+R4LvmFVAAmnYTerzvqcqZsU3N/k/VLaSTb7yIOM0xkY0 c8OOxAFh7S+b5mpCbyZ6gHoXNFj/EJlw+pL2um4XOHnAomFsYhyG8xaut4xbD8VY Owdq/CwhUrMbI9M+ttss5qHp/7U55ZvtrNtMRVeJIx6ksBpaZjDR4eeZsLFotlbL miSZzoLyLTBebsCeAA4fBCLZ0250ntEXBd586drIkRzq8nDi1HK9YOkfFOwbfuOi vax3/dz4yizcl60FMVX7ekqYGAr6U67kNQdX3an4D38xND56rlm6cDBCNBC9QK+i nVMstJFsO6QM5pNFBqRxhZBfcozF8A== =wBFk -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 29 16:57:37 2018 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 A1E4812D4E7; Thu, 29 Nov 2018 16:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaF5X9a-0Y4y; Thu, 29 Nov 2018 16:57:34 -0800 (PST) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 9AC6F1277C8; Thu, 29 Nov 2018 16:57:34 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id c72so1900789pfc.6; Thu, 29 Nov 2018 16:57:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=5a0maJTMEqEOAmrT5BuQ6H2x37xYy0PLD3XXIifuLwk=; b=O9AJfyUpm7OXMJD8n5MUql0n5pHJKM5+az1s5kBjJnC1RDJhYboPVcumkq1hFZMvSs wYmDZDmE6PfW/oKuyxGwg3lrxFaUUPOC5wxBx089FKTz0D9T/4NxKQFpep1lk7173G00 3XapmexuUw2+a3EnceZZhG/ssIErSdxTwb/dYhCvncg3vVNAmm08cTJuza05kIC2SBGw Hujh2V8nkcx6TarChZPwBv+lRx+q3Eu6t0ldz2Te/K0lyRyQSlUgcO/rYG3VNLmjGGOz wD/B0h7MMlJScSsqW+2XYup+6o4mNrCGHBjAeMPo2I8xOBuzjWx96Jc2SfiKUDGoFniU Wbnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5a0maJTMEqEOAmrT5BuQ6H2x37xYy0PLD3XXIifuLwk=; b=iTjq6KTf0Iz9fZBtpigy+LECgXi39kx2I/I1UeoPdX7gGfZRwAxBRy1wyQMp6y3zmE OfQPXlWoeSOnygJgp6KtXr33lofyWrc82CAY6S1pRFSYKtW/7qIl/khkUM3j5hfLQgWu FHMc6NnKOUh3Qepdtg+LkuP65PoAdzYg/pRvp07uLEkcV9vRGATpLKEdGGX60+q/JVvi 4b2EmP/SJRCEgorQiN50SiJrZfuA9sD4PCLtTMS8ATXOthnNzeix9AdcbfytCRUgQp1V U/syO2YyEV3JCM0XTSV3lcU+d4O+W1sNNiOW+TNT7SpN056o1ZfqHV54CyFKQnvxp+CE d3AQ== X-Gm-Message-State: AA+aEWYzWgmaVxsjj25UfBcu6unrBCAiDmVy1xZKnx02sjZcPh5VTsHs 5lEdxNGLbs+0UCrfqd6EMQyx3JPk X-Google-Smtp-Source: AFSGD/UkjpyqthnB9LABcQS/eUiCmtSr7ezltFVuTBZgiUGIeOq7jmyHa5fKX4gOQwVtY254zliWGw== X-Received: by 2002:a63:da45:: with SMTP id l5mr3168985pgj.111.1543539453774; Thu, 29 Nov 2018 16:57:33 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id v62sm5764239pfd.163.2018.11.29.16.57.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Nov 2018 16:57:32 -0800 (PST) To: anima@ietf.org, Jari Arkko , Christian Huitema Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, gen-art@ietf.org, secdir@ietf.org References: <153826253306.18743.9250084704876465818@ietfa.amsl.com> <153874289877.989.15433226866680411112@ietfa.amsl.com> <24358.1543530974@dooku.sandelman.ca> From: Brian E Carpenter Message-ID: <0b517731-ef11-4484-7bf8-46e313a2ac49@gmail.com> Date: Fri, 30 Nov 2018 13:57:26 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <24358.1543530974@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] [Gen-art] dealing with many the secdir and genart comments [on draft-ietf-anima-bootstrapping-keyinfra] 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, 30 Nov 2018 00:57:37 -0000 On 2018-11-30 11:36, Michael Richardson wrote: > > {This is the first of many replies to the various reviews} > > Jari Arkko wrote: >> My first bigger comment is that I believe the security and privacy >> considerations section should have provided an actual in-depth >> analysis of the characteristics offered by the protocol, perhaps under >> several different situations, as the protocol can be operated in >> different modes. > > The authors seriously believe that this will result in an attempt to boil the > ocean. Yes, BRSKI is exciting for many and opens many doors, but in > the context of the *ANIMA* Charter, we strongly think that this > document should leave the oceans alone, and deal only with the > ANIMA ACP usage. Yes, violent agreement. From all the interest outside ANIMA, the basic idea of BRSKI is a big hit and will be re-used in other contexts. I think a strong statement about the specific scope of *this* document belongs in the Abstract and Introduction, with a comment that variant usages of BRSKI in other scenarios will be documented separately. > Other users of BRSKI *SHOULD* write a new profile. > Would it be acceptable for us to provide a section that might be > entitled: > "The ACP mode of operation of BRSKI" > > or perhaps some other section that would clarify the applicability of this > document? That too, but make sure that the reader gets the point in the first few seconds of reading. > > We would list the assumptions and maybe even reduce the options for use > in the ACP? > > The authors do not object to writing more documents about more situations > where BRSKI might be used, but we think that putting it all into one > document is a way for continuing scope creep. > > In accepting the constrained work into the ANIMA WG, the chairs and area > director have already been very generous. > >> My second comment is that the protocol as defined is quite focused on >> manufacturer-controlled situations. As Christian mentioned, there is >> some discussion of other situations in the document (Section 6.4), but >> not much, and there's little information on what happens if one tries >> to use the protocol in this way. > > The above comments would seem to apply to this as well. Correct. The last call discussion has convinced me for one that we need to tackle the issue of non-MASA scenarios, and I have some ideas about it, but *the scope of this document* is MASA-based scenarios for professionally managed networks. Let's make that clear (see above) but not dilute the present text with it. Brian > > As I previously indicated when you first wrote this, we have turned your > comments into a series of issues on github, and we will be closing those > issues as quickly as we can. > > Some will come with proposed text changes, but a number will need discussion, > and we will start new subject lines in this thread for them. I don't want > to innudate you, so I've set the Reply-To. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art >