From nobody Wed Jul 1 02:58:10 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946313A0D43; Wed, 1 Jul 2020 02:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSlbLXL2olog; Wed, 1 Jul 2020 02:58:00 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2: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 523DF3A0D42; Wed, 1 Jul 2020 02:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=wdFbj1zO/0301A3qTxa9rbiMhcPJZGzqLS8SPO/dffE=; b=hmTAQ6Uk2YkO/jGgj5RUhb+JHb F31SUseft7+AwcNinsHUDb0lcETbT2pPB8ztgqsdIR9BoXCrKZMPijN3vIaDqButsAKMO6Bfe6DX8 pe6AagoIbm5fEnIShc4y9pLqbfGPtwvAz6V8gmoi13cx3Hxgb4NLSl04DdiJ0EnmLgYMBAAsEbWno reHExwcsy5xMBlENak6W4+xWXxhIBVhtkbFZSA5KDct7lmdktTRRGyR7/Pw55sVVzmxn+XXfKTYVz 53NcxZAnDPkLuTvkwx0utCaxm/Ti3277LcUDRNy9BnFWbnD86Hph1uVAZ1PZtni7XQuF8G5ot4sF3 sXiGzAMQ==; Received: from [81.187.2.149] (port=48839 helo=[192.168.0.80]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jqZV7-0001s7-Vr; Wed, 01 Jul 2020 10:57:58 +0100 From: Colin Perkins Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6375E09E-1002-4D53-B8AF-87253427E200" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Wed, 1 Jul 2020 10:57:54 +0100 In-Reply-To: Cc: "Black, David" , int-area , "tsvwg@ietf.org" , IETF SAAG To: Eric Rescorla References: X-Mailer: Apple Mail (2.3445.104.14) X-BlackCat-Spam-Score: 14 Archived-At: Subject: Re: [saag] [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 09:58:04 -0000 --Apple-Mail=_6375E09E-1002-4D53-B8AF-87253427E200 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 30 Jun 2020, at 01:59, Eric Rescorla wrote: >=20 > >=20 > > This 3rd WGLC is limited to the following two topics: > > =20 > >=20 > > Whether or not to proceed with a request for RFC publication > >=20 > > of the draft. The decision on whether or not to proceed will > > be based on rough consensus of the WG, see RFC 7282. > > During the 2nd WGLC, Eric Rescorla and David Schinazi expressed > > strong views that this draft should not be published =E2=80=93 = those > > concerns have not been resolved and are carried forward to > > this WGLC. This email message was an attempt to summarize > > those concerns: > >=20 > > = https://mailarchive.ietf.org/arch/msg/tsvwg/i4qyY1HRqKwm0Jme9UtEb6DyhXU/ = = > >=20 > > Further explanation from both Eric Rescorla and David Schinazi > > is welcome and encouraged to ensure that their concerns are > > clearly understood. >=20 > Well, I'll try again, but I'm not sure that I can do better than > I have before. >=20 > For reasons that are laid out in RFC 7258, the trend in protocol > design in IETF is towards encrypting more and more. I agree, but also note that RFC 7258 is clear that some network = monitoring can be beneficial and that =E2=80=9Can appropriate balance=E2=80= =9D has to be found between mitigating pervasive monitoring and = supporting network management. This draft is intended to highlight = issues to be considered by transport protocol designers, to help them = find that balance. And, to be clear, if transport protocol designers consider the issues = and decide that all the metadata in their transport protocol must be = encrypted, that=E2=80=99s fine. We're not pushing for a particular = outcome; rather that the issues be considered and discussed when making = a decision on what to encrypt. > The last two > transport protocols that were designed and widely deployed (SCTP over > DTLS and QUIC) both encrypt the vast majority of the protocol > metadata. This document advertises itself as "considerations" > for design of such protocols: >=20 > The transport protocols developed for the Internet are used across = a > wide range of paths across network segments with many different > regulatory, commercial, and engineering considerations. This > document considers some of the costs and changes to network > management and research that are implied by widespread use of > transport protocols that encrypt their transport header = information. > It reviews the implications of developing transport protocols that > use end-to-end encryption to provide confidentiality of their > transport layer headers, and considers the effect of such changes = on > transport protocol design, transport protocol evolution, and = network > operations. It also considers some anticipated implications on > application evolution. This provides considerations relating to = the > design of transport protocols and features where the transport > protocol encrypts some or all of their header information. >=20 > However, as I said above, the new transport protocols that are > actually being designed already feature metadata encryption and as far > as I can tell, there is no prospective protocol new transport protocol > design project for which these issues might be live. The issues highlighted in the draft were certainly considered in the = design of QUIC, especially in the discussions around the spin bit and = operational aspects. I cannot envisage that they won=E2=80=99t also be = considered in the design of future transports. > In that context, > it's hard not to read this document with its long litany of practices > which are impacted by metadata encryption as a critique of the > decisions by SCTP/DTLS and QUIC to encrypt most of the metadata. I tend to regard critiques of protocol design as a good thing, but then = we maybe have a different interpretations of that term. Certainly there = are implications of the decision to encrypt transport metadata. There = are benefits to it, but also costs. It=E2=80=99s important to understand = both, to make an informed judgement on what to encrypt. > This impression is reinforced by the description of the actual > practices themselves, which focuses almost entirely on practices > which appear to be benignly motivated (e.g., performance monitoring, > troubleshooting, etc.) However, we also know that metadata is widely > used for practices in which the network operator is adversarial > to the user, for instance: >=20 > - Blocking traffic based on TCP port, IP address, SNI, etc. >=20 > - Performance-based traffic class discrimination >=20 > - Monitoring the user's behavior via indicia like the ones above > or via traffic analysis (see [0]) >=20 > Yes, I understand that the authors explicitly disclaim judgement on > these practices, and the document does briefly touch on the general > idea, though the "concerns...have been voiced" tends to minimize those > concerns [1] but the selection of practices to focus on is extremely > telling. Focusing on the downsides of encryption for (at least > arguably well-meaning) network players while mostly ignoring the large > class of non-benign behaviors which encryption is intended to protect > against has the effect of overemphasizing the costs of encryption to > those players and minimizing the benefits to the endpoints whom it is > intended to protect. Different communities have different interpretations on what=E2=80=99s = the neutral point of view phrasing here, but I'm comfortable with = further highlighting malicious uses of transport metadata in the draft. = We=E2=80=99d tried to mostly do this by reference, since such things = have been widely discussed in the past, but perhaps that=E2=80=99s not = sufficient. > To be maximally clear: I don't object to this document existing > and I don't think that the opinions implicit in it are ones that > should not be expressed. I merely don't think that it should be > published as an IETF Consensus document. >=20 > -Ekr >=20 > [0] = https://tools.ietf.org/html/draft-wood-pearg-website-fingerprinting-00#sec= tion-5 = > [1] Another motivation stems from increased concerns about privacy = and > surveillance. Users value the ability to protect their identity > and location, and defend against analysis of the traffic. > Revelations about the use of pervasive surveillance [RFC7624] > have, to some extent, eroded trust in the service offered by > network operators and have led to an increased use of encryption > to avoid unwanted eavesdropping on communications. Concerns = have > also been voiced about the addition of information to packets by > third parties to provide analytics, customisation, advertising, > cross-site tracking of users, to bill the customer, or to > selectively allow or block content. Whatever the reasons, the > IETF is designing protocols that include transport header > encryption (e.g., QUIC [I-D.ietf-quic-transport]) to supplement > the already widespread payload encryption, and to further limit > exposure of transport metadata to the network. > =20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_6375E09E-1002-4D53-B8AF-87253427E200 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 30 Jun 2020, at 01:59, Eric Rescorla <ekr@rtfm.com> = wrote:

>
> This 3rd WGLC is limited = to the following two topics:
>  
> =
>     Whether or not to proceed with a = request for RFC publication
>
> of = the draft.   The decision on whether or not to proceed will
> be based on rough consensus of the WG, see RFC 7282.
> During the 2nd WGLC, Eric Rescorla and David Schinazi = expressed
> strong views that this draft should not be = published =E2=80=93  those
> concerns have not = been resolved and are carried forward to
> this = WGLC.  This email message was an attempt to summarize
> those concerns:
>
> = https://mailarchive.ietf.org/arch/msg/tsvwg/i4qyY1HRqKwm0Jme9Ut= Eb6DyhXU/
>
> Further explanation = from both Eric Rescorla and David Schinazi
> is welcome = and encouraged to ensure that their concerns are
> = clearly understood.

Well, I'll try again, = but I'm not sure that I can do better than
I have = before.

For reasons that are laid out in = RFC 7258, the trend in protocol
design in IETF is towards = encrypting more and more.

I agree, but also note that RFC 7258 is clear that = some network monitoring can be beneficial and that =E2=80=9Can = appropriate balance=E2=80=9D has to be found between mitigating = pervasive monitoring and supporting network management. This draft is = intended to highlight issues to be considered by transport protocol = designers, to help them find that balance.

And, to be clear, if transport protocol designers = consider the issues and decide that all the metadata in their transport = protocol must be encrypted, that=E2=80=99s fine. We're not pushing for a = particular outcome; rather that the issues be considered and discussed = when making a decision on what to encrypt.

The = last two
transport protocols that were designed and widely = deployed (SCTP over
DTLS and QUIC) both encrypt the vast = majority of the protocol
metadata. This document = advertises itself as "considerations"
for design of such = protocols:

   The transport = protocols developed for the Internet are used across a
   wide range of paths across network segments with = many different
   regulatory, commercial, and = engineering considerations.  This
  =  document considers some of the costs and changes to network
   management and research that are implied by = widespread use of
   transport protocols that = encrypt their transport header information.
  =  It reviews the implications of developing transport protocols = that
   use end-to-end encryption to provide = confidentiality of their
   transport layer = headers, and considers the effect of such changes on
  =  transport protocol design, transport protocol evolution, and = network
   operations.  It also considers = some anticipated implications on
   application = evolution.  This provides considerations relating to the
   design of transport protocols and features where = the transport
   protocol encrypts some or all = of their header information.

However, as I = said above, the new transport protocols that are
actually = being designed already feature metadata encryption and as far
as I can tell, there is no prospective protocol new transport = protocol
design project for which these issues might be = live.

The issues = highlighted in the draft were certainly considered in the design of = QUIC, especially in the discussions around the spin bit and operational = aspects. I cannot envisage that they won=E2=80=99t also be considered in = the design of future transports.

In = that context,
it's hard not to read this document with its = long litany of practices
which are impacted by metadata = encryption as a critique of the
decisions by SCTP/DTLS and = QUIC to encrypt most of the metadata.

I = tend to regard critiques of protocol design as a good thing, but then we = maybe have a different interpretations of that term. Certainly there are = implications of the decision to encrypt transport metadata. There are = benefits to it, but also costs. It=E2=80=99s important to understand = both, to make an informed judgement on what to encrypt.

This impression is reinforced by the description = of the actual
practices themselves, which focuses almost = entirely on practices
which appear to be benignly = motivated (e.g., performance monitoring,
troubleshooting, = etc.) However, we also know that metadata is widely
used = for practices in which the network operator is adversarial
to the user, for instance:

- = Blocking traffic based on TCP port, IP address, SNI, etc.

- Performance-based traffic class = discrimination

- Monitoring the user's = behavior via indicia like the ones above
  or via = traffic analysis (see [0])

Yes, I = understand that the authors explicitly disclaim judgement on
these practices, and the document does briefly touch on the = general
idea, though the "concerns...have been voiced" = tends to minimize those
concerns [1] but the selection of = practices to focus on is extremely
telling. Focusing on = the downsides of encryption for (at least
arguably = well-meaning) network players while mostly ignoring the large
class of non-benign behaviors which encryption is intended to = protect
against has the effect of overemphasizing the = costs of encryption to
those players and minimizing the = benefits to the endpoints whom it is
intended to = protect.

Different communities have different = interpretations on what=E2=80=99s the neutral point of view phrasing = here, but I'm comfortable with further highlighting malicious uses of = transport metadata in the draft. We=E2=80=99d tried to mostly do this by = reference, since such things have been widely discussed in the past, but = perhaps that=E2=80=99s not sufficient.

To = be maximally clear: I don't object to this document existing
and I don't think that the opinions implicit in it are ones = that
should not be expressed. I merely don't think that it = should be
published as an IETF Consensus document.

-Ekr

[0] https://tools.ietf.org/html/draft-wood-pearg-website-fingerprin= ting-00#section-5
[1]    Another motivation = stems from increased concerns about privacy and
  =     surveillance.  Users value the ability to protect = their identity
      and location, and = defend against analysis of the traffic.
    =   Revelations about the use of pervasive surveillance [RFC7624]
      have, to some extent, eroded trust in = the service offered by
      network = operators and have led to an increased use of encryption
      to avoid unwanted eavesdropping on = communications.  Concerns have
      = also been voiced about the addition of information to packets by
      third parties to provide analytics, = customisation, advertising,
      = cross-site tracking of users, to bill the customer, or to
      selectively allow or block = content.  Whatever the reasons, the
    =   IETF is designing protocols that include transport header
      encryption (e.g., QUIC = [I-D.ietf-quic-transport]) to supplement
    =   the already widespread payload encryption, and to further = limit
      exposure of transport metadata = to the network.
 










-- 
Colin Perkins
https://csperkins.org/




= --Apple-Mail=_6375E09E-1002-4D53-B8AF-87253427E200-- From nobody Wed Jul 1 05:58:19 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903133A0A05; Wed, 1 Jul 2020 05:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 BTy7IWhqfqQw; Wed, 1 Jul 2020 05:58:01 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E41D23A0A02; Wed, 1 Jul 2020 05:58:00 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by opfednr22.francetelecom.fr (ESMTP service) with ESMTPS id 49xh930g91z108j; Wed, 1 Jul 2020 14:57:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1593608279; bh=+jCYGKBn3Y3//Tdee16/RWBj7w/MOP8yoBzqxulUKU4=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=KF6054p1nNP/zpS9WSagppgjFXZSVU9LM6sXheMFmIBlvvorDxZbgcKpSuTqoietr nGJfn4lw+zsJf1FVzcHsRQhvDpGRHbFqGOJU081n8veopt2IU1jDaLuvx/xJzNozWz R+EGWfMex3zIuNpAlvVZ/V4gVBvounQmHLEOlRcW3wT5LALTrL+afJtuULsmWTWwQN CPEC4uWNUQBiqs2exK1YQv9mt+Hu7kCc1cOY1eb7Z71S4EHoqWYwn01H+sQNy0VT/W Wm1jTlz6YbP44wIfyL0lIzgOsbQ/WgnpLSNk3LDW3Ck5lp1hwTKqS6ejd0Qd7jX3gk nvkswEOgW529g== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by opfednr00.francetelecom.fr (ESMTP service) with ESMTPS id 49xh926K67zDq7j; Wed, 1 Jul 2020 14:57:58 +0200 (CEST) From: To: Hannes Tschofenig , "Black, David" CC: int-area , "tsvwg@ietf.org" , IETF SAAG Thread-Topic: [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 Thread-Index: AdY9/kL5KQoLk/CbSKeZ9xMZ8uq3SAQe3d4AAAnHrZAAQX40gA== Date: Wed, 1 Jul 2020 12:57:57 +0000 Message-ID: <21886_1593608278_5EFC8856_21886_470_1_787AE7BB302AE849A7480A190F8B9330314EBA5C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330314EBA5COPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 12:58:04 -0000 --_000_787AE7BB302AE849A7480A190F8B9330314EBA5COPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSGFubmVzLA0KDQpJdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjYW4gZXhwbGljaXQgdGhl IOKAnHdyb25nIG1lc3NhZ2XigJ0geW91IGFyZSByZWZlcnJpbmcgdG8sIGFuZCBwcmVmZXJhYmx5 IHdpdGggdGV4dCBmcm9tIHRoZSBkcmFmdCBjb252ZXlpbmcgdGhhdCBtZXNzYWdlLg0KDQpUaGFu ayB5b3UuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IEludC1hcmVhIFttYWlsdG86aW50LWFyZWEt Ym91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBIYW5uZXMgVHNjaG9mZW5pZw0KRW52b3nD qSA6IG1hcmRpIDMwIGp1aW4gMjAyMCAwNzo1MA0Kw4AgOiBFcmljIFJlc2NvcmxhOyBCbGFjaywg RGF2aWQNCkNjIDogaW50LWFyZWE7IHRzdndnQGlldGYub3JnOyBJRVRGIFNBQUcNCk9iamV0IDog UmU6IFtJbnQtYXJlYV0gW3NhYWddIDNyZCBXR0xDIChsaW1pdGVkLXNjb3BlKTogZHJhZnQtaWV0 Zi10c3Z3Zy10cmFuc3BvcnQtZW5jcnlwdC0xNSwgY2xvc2VzIDI5IEp1bmUgMjAyMA0KDQpJIGJl bGlldmUgdGhpcyBkb2N1bWVudCBzaWduYWxzIGEgd3JvbmcgbWVzc2FnZSB0byB0aGUgd2lkZXIg SW50ZXJuZXQgY29tbXVuaXR5LiBJIGFncmVlIHRoYXQgaXQgc2hvdWxkIG5vdCBiZSBwdWJsaXNo ZWQgYXMgYSBjb25zZW5zdXMgZG9jdW1lbnQuDQoNCkkgdW5kZXJzdGFuZCB0aGF0IHNvbWUgcGVv cGxlIGFyZSB1bmhhcHB5IGFib3V0IGVuY3J5cHRpbmcgbW9yZSBtZXRhLWRhdGEuIFRoaXMgcHJl dmVudHMgdGhlbSBmcm9tIGRvaW5nIHRoaW5ncyB0aGV5IHVzZWQgdG8gZG8gaW4gdGhlIHBhc3Qs IHNvbWUgb2Ygd2hpY2ggdGhleSBzaG91bGQgaGF2ZSBuZXZlciBkb25lIGluIHRoZSBmaXJzdCBw bGFjZS4NCkltcHJvdmluZyB0aGUgcHJvdGVjdGlvbiBvZiBtZXRhLWRhdGEgaXMgaW1wb3J0YW50 IGFuZCB3ZWxsIHN1cHBvcnRlZCBieSBhIGxhcmdlIG51bWJlciBvZiBhY3Rpdml0aWVzIGluIHRo ZSBJRVRGICh0aGUgbm90YWJsZSBleGNlcHRpb24gYmVpbmcgQ29BUCtPU0NPUkUpLg0KDQpDaWFv DQpIYW5uZXMNCg0KDQpGcm9tOiBzYWFnIDxzYWFnLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFs ZiBPZiBFcmljIFJlc2NvcmxhDQpTZW50OiBUdWVzZGF5LCBKdW5lIDMwLCAyMDIwIDM6MDAgQU0N ClRvOiBCbGFjaywgRGF2aWQgPERhdmlkLkJsYWNrQGRlbGwuY29tPg0KQ2M6IGludC1hcmVhIDxp bnQtYXJlYUBpZXRmLm9yZz47IHRzdndnQGlldGYub3JnOyBJRVRGIFNBQUcgPHNhYWdAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW3NhYWddIDNyZCBXR0xDIChsaW1pdGVkLXNjb3BlKTogZHJhZnQt aWV0Zi10c3Z3Zy10cmFuc3BvcnQtZW5jcnlwdC0xNSwgY2xvc2VzIDI5IEp1bmUgMjAyMA0KDQo+ DQo+IFRoaXMgM3JkIFdHTEMgaXMgbGltaXRlZCB0byB0aGUgZm9sbG93aW5nIHR3byB0b3BpY3M6 DQo+DQo+DQo+ICAgICBXaGV0aGVyIG9yIG5vdCB0byBwcm9jZWVkIHdpdGggYSByZXF1ZXN0IGZv ciBSRkMgcHVibGljYXRpb24NCj4NCj4gb2YgdGhlIGRyYWZ0LiAgIFRoZSBkZWNpc2lvbiBvbiB3 aGV0aGVyIG9yIG5vdCB0byBwcm9jZWVkIHdpbGwNCj4gYmUgYmFzZWQgb24gcm91Z2ggY29uc2Vu c3VzIG9mIHRoZSBXRywgc2VlIFJGQyA3MjgyLg0KPiBEdXJpbmcgdGhlIDJuZCBXR0xDLCBFcmlj IFJlc2NvcmxhIGFuZCBEYXZpZCBTY2hpbmF6aSBleHByZXNzZWQNCj4gc3Ryb25nIHZpZXdzIHRo YXQgdGhpcyBkcmFmdCBzaG91bGQgbm90IGJlIHB1Ymxpc2hlZCDigJMgIHRob3NlDQo+IGNvbmNl cm5zIGhhdmUgbm90IGJlZW4gcmVzb2x2ZWQgYW5kIGFyZSBjYXJyaWVkIGZvcndhcmQgdG8NCj4g dGhpcyBXR0xDLiAgVGhpcyBlbWFpbCBtZXNzYWdlIHdhcyBhbiBhdHRlbXB0IHRvIHN1bW1hcml6 ZQ0KPiB0aG9zZSBjb25jZXJuczoNCj4NCj4gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9h cmNoL21zZy90c3Z3Zy9pNHF5WTFIUnFLd20wSm1lOVV0RWI2RHloWFUvDQo+DQo+IEZ1cnRoZXIg ZXhwbGFuYXRpb24gZnJvbSBib3RoIEVyaWMgUmVzY29ybGEgYW5kIERhdmlkIFNjaGluYXppDQo+ IGlzIHdlbGNvbWUgYW5kIGVuY291cmFnZWQgdG8gZW5zdXJlIHRoYXQgdGhlaXIgY29uY2VybnMg YXJlDQo+IGNsZWFybHkgdW5kZXJzdG9vZC4NCg0KV2VsbCwgSSdsbCB0cnkgYWdhaW4sIGJ1dCBJ J20gbm90IHN1cmUgdGhhdCBJIGNhbiBkbyBiZXR0ZXIgdGhhbg0KSSBoYXZlIGJlZm9yZS4NCg0K Rm9yIHJlYXNvbnMgdGhhdCBhcmUgbGFpZCBvdXQgaW4gUkZDIDcyNTgsIHRoZSB0cmVuZCBpbiBw cm90b2NvbA0KZGVzaWduIGluIElFVEYgaXMgdG93YXJkcyBlbmNyeXB0aW5nIG1vcmUgYW5kIG1v cmUuIFRoZSBsYXN0IHR3bw0KdHJhbnNwb3J0IHByb3RvY29scyB0aGF0IHdlcmUgZGVzaWduZWQg YW5kIHdpZGVseSBkZXBsb3llZCAoU0NUUCBvdmVyDQpEVExTIGFuZCBRVUlDKSBib3RoIGVuY3J5 cHQgdGhlIHZhc3QgbWFqb3JpdHkgb2YgdGhlIHByb3RvY29sDQptZXRhZGF0YS4gVGhpcyBkb2N1 bWVudCBhZHZlcnRpc2VzIGl0c2VsZiBhcyAiY29uc2lkZXJhdGlvbnMiDQpmb3IgZGVzaWduIG9m IHN1Y2ggcHJvdG9jb2xzOg0KDQogICBUaGUgdHJhbnNwb3J0IHByb3RvY29scyBkZXZlbG9wZWQg Zm9yIHRoZSBJbnRlcm5ldCBhcmUgdXNlZCBhY3Jvc3MgYQ0KICAgd2lkZSByYW5nZSBvZiBwYXRo cyBhY3Jvc3MgbmV0d29yayBzZWdtZW50cyB3aXRoIG1hbnkgZGlmZmVyZW50DQogICByZWd1bGF0 b3J5LCBjb21tZXJjaWFsLCBhbmQgZW5naW5lZXJpbmcgY29uc2lkZXJhdGlvbnMuICBUaGlzDQog ICBkb2N1bWVudCBjb25zaWRlcnMgc29tZSBvZiB0aGUgY29zdHMgYW5kIGNoYW5nZXMgdG8gbmV0 d29yaw0KICAgbWFuYWdlbWVudCBhbmQgcmVzZWFyY2ggdGhhdCBhcmUgaW1wbGllZCBieSB3aWRl c3ByZWFkIHVzZSBvZg0KICAgdHJhbnNwb3J0IHByb3RvY29scyB0aGF0IGVuY3J5cHQgdGhlaXIg dHJhbnNwb3J0IGhlYWRlciBpbmZvcm1hdGlvbi4NCiAgIEl0IHJldmlld3MgdGhlIGltcGxpY2F0 aW9ucyBvZiBkZXZlbG9waW5nIHRyYW5zcG9ydCBwcm90b2NvbHMgdGhhdA0KICAgdXNlIGVuZC10 by1lbmQgZW5jcnlwdGlvbiB0byBwcm92aWRlIGNvbmZpZGVudGlhbGl0eSBvZiB0aGVpcg0KICAg dHJhbnNwb3J0IGxheWVyIGhlYWRlcnMsIGFuZCBjb25zaWRlcnMgdGhlIGVmZmVjdCBvZiBzdWNo IGNoYW5nZXMgb24NCiAgIHRyYW5zcG9ydCBwcm90b2NvbCBkZXNpZ24sIHRyYW5zcG9ydCBwcm90 b2NvbCBldm9sdXRpb24sIGFuZCBuZXR3b3JrDQogICBvcGVyYXRpb25zLiAgSXQgYWxzbyBjb25z aWRlcnMgc29tZSBhbnRpY2lwYXRlZCBpbXBsaWNhdGlvbnMgb24NCiAgIGFwcGxpY2F0aW9uIGV2 b2x1dGlvbi4gIFRoaXMgcHJvdmlkZXMgY29uc2lkZXJhdGlvbnMgcmVsYXRpbmcgdG8gdGhlDQog ICBkZXNpZ24gb2YgdHJhbnNwb3J0IHByb3RvY29scyBhbmQgZmVhdHVyZXMgd2hlcmUgdGhlIHRy YW5zcG9ydA0KICAgcHJvdG9jb2wgZW5jcnlwdHMgc29tZSBvciBhbGwgb2YgdGhlaXIgaGVhZGVy IGluZm9ybWF0aW9uLg0KDQpIb3dldmVyLCBhcyBJIHNhaWQgYWJvdmUsIHRoZSBuZXcgdHJhbnNw b3J0IHByb3RvY29scyB0aGF0IGFyZQ0KYWN0dWFsbHkgYmVpbmcgZGVzaWduZWQgYWxyZWFkeSBm ZWF0dXJlIG1ldGFkYXRhIGVuY3J5cHRpb24gYW5kIGFzIGZhcg0KYXMgSSBjYW4gdGVsbCwgdGhl cmUgaXMgbm8gcHJvc3BlY3RpdmUgcHJvdG9jb2wgbmV3IHRyYW5zcG9ydCBwcm90b2NvbA0KZGVz aWduIHByb2plY3QgZm9yIHdoaWNoIHRoZXNlIGlzc3VlcyBtaWdodCBiZSBsaXZlLiBJbiB0aGF0 IGNvbnRleHQsDQppdCdzIGhhcmQgbm90IHRvIHJlYWQgdGhpcyBkb2N1bWVudCB3aXRoIGl0cyBs b25nIGxpdGFueSBvZiBwcmFjdGljZXMNCndoaWNoIGFyZSBpbXBhY3RlZCBieSBtZXRhZGF0YSBl bmNyeXB0aW9uIGFzIGEgY3JpdGlxdWUgb2YgdGhlDQpkZWNpc2lvbnMgYnkgU0NUUC9EVExTIGFu ZCBRVUlDIHRvIGVuY3J5cHQgbW9zdCBvZiB0aGUgbWV0YWRhdGEuDQoNCg0KVGhpcyBpbXByZXNz aW9uIGlzIHJlaW5mb3JjZWQgYnkgdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBhY3R1YWwNCnByYWN0 aWNlcyB0aGVtc2VsdmVzLCB3aGljaCBmb2N1c2VzIGFsbW9zdCBlbnRpcmVseSBvbiBwcmFjdGlj ZXMNCndoaWNoIGFwcGVhciB0byBiZSBiZW5pZ25seSBtb3RpdmF0ZWQgKGUuZy4sIHBlcmZvcm1h bmNlIG1vbml0b3JpbmcsDQp0cm91Ymxlc2hvb3RpbmcsIGV0Yy4pIEhvd2V2ZXIsIHdlIGFsc28g a25vdyB0aGF0IG1ldGFkYXRhIGlzIHdpZGVseQ0KdXNlZCBmb3IgcHJhY3RpY2VzIGluIHdoaWNo IHRoZSBuZXR3b3JrIG9wZXJhdG9yIGlzIGFkdmVyc2FyaWFsDQp0byB0aGUgdXNlciwgZm9yIGlu c3RhbmNlOg0KDQotIEJsb2NraW5nIHRyYWZmaWMgYmFzZWQgb24gVENQIHBvcnQsIElQIGFkZHJl c3MsIFNOSSwgZXRjLg0KDQotIFBlcmZvcm1hbmNlLWJhc2VkIHRyYWZmaWMgY2xhc3MgZGlzY3Jp bWluYXRpb24NCg0KLSBNb25pdG9yaW5nIHRoZSB1c2VyJ3MgYmVoYXZpb3IgdmlhIGluZGljaWEg bGlrZSB0aGUgb25lcyBhYm92ZQ0KICBvciB2aWEgdHJhZmZpYyBhbmFseXNpcyAoc2VlIFswXSkN Cg0KWWVzLCBJIHVuZGVyc3RhbmQgdGhhdCB0aGUgYXV0aG9ycyBleHBsaWNpdGx5IGRpc2NsYWlt IGp1ZGdlbWVudCBvbg0KdGhlc2UgcHJhY3RpY2VzLCBhbmQgdGhlIGRvY3VtZW50IGRvZXMgYnJp ZWZseSB0b3VjaCBvbiB0aGUgZ2VuZXJhbA0KaWRlYSwgdGhvdWdoIHRoZSAiY29uY2VybnMuLi5o YXZlIGJlZW4gdm9pY2VkIiB0ZW5kcyB0byBtaW5pbWl6ZSB0aG9zZQ0KY29uY2VybnMgWzFdIGJ1 dCB0aGUgc2VsZWN0aW9uIG9mIHByYWN0aWNlcyB0byBmb2N1cyBvbiBpcyBleHRyZW1lbHkNCnRl bGxpbmcuIEZvY3VzaW5nIG9uIHRoZSBkb3duc2lkZXMgb2YgZW5jcnlwdGlvbiBmb3IgKGF0IGxl YXN0DQphcmd1YWJseSB3ZWxsLW1lYW5pbmcpIG5ldHdvcmsgcGxheWVycyB3aGlsZSBtb3N0bHkg aWdub3JpbmcgdGhlIGxhcmdlDQpjbGFzcyBvZiBub24tYmVuaWduIGJlaGF2aW9ycyB3aGljaCBl bmNyeXB0aW9uIGlzIGludGVuZGVkIHRvIHByb3RlY3QNCmFnYWluc3QgaGFzIHRoZSBlZmZlY3Qg b2Ygb3ZlcmVtcGhhc2l6aW5nIHRoZSBjb3N0cyBvZiBlbmNyeXB0aW9uIHRvDQp0aG9zZSBwbGF5 ZXJzIGFuZCBtaW5pbWl6aW5nIHRoZSBiZW5lZml0cyB0byB0aGUgZW5kcG9pbnRzIHdob20gaXQg aXMNCmludGVuZGVkIHRvIHByb3RlY3QuDQoNCg0KVG8gYmUgbWF4aW1hbGx5IGNsZWFyOiBJIGRv bid0IG9iamVjdCB0byB0aGlzIGRvY3VtZW50IGV4aXN0aW5nDQphbmQgSSBkb24ndCB0aGluayB0 aGF0IHRoZSBvcGluaW9ucyBpbXBsaWNpdCBpbiBpdCBhcmUgb25lcyB0aGF0DQpzaG91bGQgbm90 IGJlIGV4cHJlc3NlZC4gSSBtZXJlbHkgZG9uJ3QgdGhpbmsgdGhhdCBpdCBzaG91bGQgYmUNCnB1 Ymxpc2hlZCBhcyBhbiBJRVRGIENvbnNlbnN1cyBkb2N1bWVudC4NCg0KLUVrcg0KDQpbMF0gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdvb2QtcGVhcmctd2Vic2l0ZS1maW5nZXJw cmludGluZy0wMCNzZWN0aW9uLTUNClsxXSAgICBBbm90aGVyIG1vdGl2YXRpb24gc3RlbXMgZnJv bSBpbmNyZWFzZWQgY29uY2VybnMgYWJvdXQgcHJpdmFjeSBhbmQNCiAgICAgIHN1cnZlaWxsYW5j ZS4gIFVzZXJzIHZhbHVlIHRoZSBhYmlsaXR5IHRvIHByb3RlY3QgdGhlaXIgaWRlbnRpdHkNCiAg ICAgIGFuZCBsb2NhdGlvbiwgYW5kIGRlZmVuZCBhZ2FpbnN0IGFuYWx5c2lzIG9mIHRoZSB0cmFm ZmljLg0KICAgICAgUmV2ZWxhdGlvbnMgYWJvdXQgdGhlIHVzZSBvZiBwZXJ2YXNpdmUgc3VydmVp bGxhbmNlIFtSRkM3NjI0XQ0KICAgICAgaGF2ZSwgdG8gc29tZSBleHRlbnQsIGVyb2RlZCB0cnVz dCBpbiB0aGUgc2VydmljZSBvZmZlcmVkIGJ5DQogICAgICBuZXR3b3JrIG9wZXJhdG9ycyBhbmQg aGF2ZSBsZWQgdG8gYW4gaW5jcmVhc2VkIHVzZSBvZiBlbmNyeXB0aW9uDQogICAgICB0byBhdm9p ZCB1bndhbnRlZCBlYXZlc2Ryb3BwaW5nIG9uIGNvbW11bmljYXRpb25zLiAgQ29uY2VybnMgaGF2 ZQ0KICAgICAgYWxzbyBiZWVuIHZvaWNlZCBhYm91dCB0aGUgYWRkaXRpb24gb2YgaW5mb3JtYXRp b24gdG8gcGFja2V0cyBieQ0KICAgICAgdGhpcmQgcGFydGllcyB0byBwcm92aWRlIGFuYWx5dGlj cywgY3VzdG9taXNhdGlvbiwgYWR2ZXJ0aXNpbmcsDQogICAgICBjcm9zcy1zaXRlIHRyYWNraW5n IG9mIHVzZXJzLCB0byBiaWxsIHRoZSBjdXN0b21lciwgb3IgdG8NCiAgICAgIHNlbGVjdGl2ZWx5 IGFsbG93IG9yIGJsb2NrIGNvbnRlbnQuICBXaGF0ZXZlciB0aGUgcmVhc29ucywgdGhlDQogICAg ICBJRVRGIGlzIGRlc2lnbmluZyBwcm90b2NvbHMgdGhhdCBpbmNsdWRlIHRyYW5zcG9ydCBoZWFk ZXINCiAgICAgIGVuY3J5cHRpb24gKGUuZy4sIFFVSUMgW0ktRC5pZXRmLXF1aWMtdHJhbnNwb3J0 XSkgdG8gc3VwcGxlbWVudA0KICAgICAgdGhlIGFscmVhZHkgd2lkZXNwcmVhZCBwYXlsb2FkIGVu Y3J5cHRpb24sIGFuZCB0byBmdXJ0aGVyIGxpbWl0DQogICAgICBleHBvc3VyZSBvZiB0cmFuc3Bv cnQgbWV0YWRhdGEgdG8gdGhlIG5ldHdvcmsuDQoNCg0KDQoNCg0KDQpJTVBPUlRBTlQgTk9USUNF OiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25m aWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBh bmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2Ug aXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBh bnkgbWVkaXVtLiBUaGFuayB5b3UuDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2Vz IGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxl cyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBl eHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBj ZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRo YXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBh bHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4g bW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_787AE7BB302AE849A7480A190F8B9330314EBA5COPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFj azt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgSGFubmVzLA0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91 IGNhbiBleHBsaWNpdCB0aGUg4oCcd3JvbmcgbWVzc2FnZeKAnSB5b3UgYXJlIHJlZmVycmluZyB0 bywgYW5kIHByZWZlcmFibHkgd2l0aCB0ZXh0IGZyb20gdGhlIGRyYWZ0IGNvbnZleWluZyB0aGF0 IG1lc3NhZ2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PlRoYW5rIHlvdS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEludC1hcmVhIFttYWlsdG86 aW50LWFyZWEtYm91bmNlc0BpZXRmLm9yZ10NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IEhhbm5lcyBU c2Nob2ZlbmlnPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1hcmRpIDMwIGp1aW4gMjAyMCAw Nzo1MDxicj4NCjxiPsOAJm5ic3A7OjwvYj4gRXJpYyBSZXNjb3JsYTsgQmxhY2ssIERhdmlkPGJy Pg0KPGI+Q2MmbmJzcDs6PC9iPiBpbnQtYXJlYTsgdHN2d2dAaWV0Zi5vcmc7IElFVEYgU0FBRzxi cj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtJbnQtYXJlYV0gW3NhYWddIDNyZCBXR0xDIChs aW1pdGVkLXNjb3BlKTogZHJhZnQtaWV0Zi10c3Z3Zy10cmFuc3BvcnQtZW5jcnlwdC0xNSwgY2xv c2VzIDI5IEp1bmUgMjAyMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgYmVsaWV2ZSB0aGlzIGRvY3VtZW50IHNpZ25hbHMgYSB3cm9uZyBtZXNzYWdlIHRv IHRoZSB3aWRlciBJbnRlcm5ldCBjb21tdW5pdHkuIEkgYWdyZWUgdGhhdCBpdCBzaG91bGQgbm90 IGJlIHB1Ymxpc2hlZCBhcyBhIGNvbnNlbnN1cyBkb2N1bWVudC4NCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIHVuZGVyc3RhbmQgdGhhdCBzb21lIHBlb3BsZSBhcmUgdW5oYXBweSBhYm91dCBl bmNyeXB0aW5nIG1vcmUgbWV0YS1kYXRhLiBUaGlzIHByZXZlbnRzIHRoZW0gZnJvbSBkb2luZyB0 aGluZ3MgdGhleSB1c2VkIHRvIGRvIGluIHRoZSBwYXN0LCBzb21lIG9mIHdoaWNoIHRoZXkgc2hv dWxkIGhhdmUgbmV2ZXIgZG9uZSBpbiB0aGUgZmlyc3QgcGxhY2UuDQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkltcHJvdmluZyB0aGUgcHJvdGVjdGlvbiBvZiBtZXRhLWRh dGEgaXMgaW1wb3J0YW50IGFuZCB3ZWxsIHN1cHBvcnRlZCBieSBhIGxhcmdlIG51bWJlciBvZiBh Y3Rpdml0aWVzIGluIHRoZSBJRVRGICh0aGUgbm90YWJsZSBleGNlcHRpb24gYmVpbmcgQ29BUCYj NDM7T1NDT1JFKS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaWFvPGJyPg0KSGFubmVzPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IHNhYWcgJmx0 O3NhYWctYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCkVyaWMgUmVz Y29ybGE8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVuZSAzMCwgMjAyMCAzOjAwIEFNPGJy Pg0KPGI+VG86PC9iPiBCbGFjaywgRGF2aWQgJmx0O0RhdmlkLkJsYWNrQGRlbGwuY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gaW50LWFyZWEgJmx0O2ludC1hcmVhQGlldGYub3JnJmd0OzsgdHN2d2dA aWV0Zi5vcmc7IElFVEYgU0FBRyAmbHQ7c2FhZ0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtzYWFnXSAzcmQgV0dMQyAobGltaXRlZC1zY29wZSk6IGRyYWZ0LWlldGYtdHN2 d2ctdHJhbnNwb3J0LWVuY3J5cHQtMTUsIGNsb3NlcyAyOSBKdW5lIDIwMjA8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4m Z3Q7IDxicj4NCiZndDsgVGhpcyAzcmQgV0dMQyBpcyBsaW1pdGVkIHRvIHRoZSBmb2xsb3dpbmcg dHdvIHRvcGljczo8YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7IFdoZXRoZXIgb3Igbm90IHRvIHByb2NlZWQgd2l0aCBhIHJlcXVlc3QgZm9yIFJGQyBw dWJsaWNhdGlvbjxicj4NCiZndDsgPGJyPg0KJmd0OyBvZiB0aGUgZHJhZnQuICZuYnNwOyBUaGUg ZGVjaXNpb24gb24gd2hldGhlciBvciBub3QgdG8gcHJvY2VlZCB3aWxsPGJyPg0KJmd0OyBiZSBi YXNlZCBvbiByb3VnaCBjb25zZW5zdXMgb2YgdGhlIFdHLCBzZWUgUkZDIDcyODIuPGJyPg0KJmd0 OyBEdXJpbmcgdGhlIDJuZCBXR0xDLCBFcmljIFJlc2NvcmxhIGFuZCBEYXZpZCBTY2hpbmF6aSBl eHByZXNzZWQ8YnI+DQomZ3Q7IHN0cm9uZyB2aWV3cyB0aGF0IHRoaXMgZHJhZnQgc2hvdWxkIG5v dCBiZSBwdWJsaXNoZWQg4oCTICZuYnNwO3Rob3NlPGJyPg0KJmd0OyBjb25jZXJucyBoYXZlIG5v dCBiZWVuIHJlc29sdmVkIGFuZCBhcmUgY2FycmllZCBmb3J3YXJkIHRvPGJyPg0KJmd0OyB0aGlz IFdHTEMuJm5ic3A7IFRoaXMgZW1haWwgbWVzc2FnZSB3YXMgYW4gYXR0ZW1wdCB0byBzdW1tYXJp emU8YnI+DQomZ3Q7IHRob3NlIGNvbmNlcm5zOjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YSBocmVm PSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3RzdndnL2k0cXlZMUhScUt3 bTBKbWU5VXRFYjZEeWhYVS8iPg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21z Zy90c3Z3Zy9pNHF5WTFIUnFLd20wSm1lOVV0RWI2RHloWFUvPC9hPjxicj4NCiZndDsgPGJyPg0K Jmd0OyBGdXJ0aGVyIGV4cGxhbmF0aW9uIGZyb20gYm90aCBFcmljIFJlc2NvcmxhIGFuZCBEYXZp ZCBTY2hpbmF6aTxicj4NCiZndDsgaXMgd2VsY29tZSBhbmQgZW5jb3VyYWdlZCB0byBlbnN1cmUg dGhhdCB0aGVpciBjb25jZXJucyBhcmU8YnI+DQomZ3Q7IGNsZWFybHkgdW5kZXJzdG9vZC48YnI+ DQo8YnI+DQpXZWxsLCBJJ2xsIHRyeSBhZ2FpbiwgYnV0IEknbSBub3Qgc3VyZSB0aGF0IEkgY2Fu IGRvIGJldHRlciB0aGFuPGJyPg0KSSBoYXZlIGJlZm9yZS48YnI+DQo8YnI+DQpGb3IgcmVhc29u cyB0aGF0IGFyZSBsYWlkIG91dCBpbiBSRkMgNzI1OCwgdGhlIHRyZW5kIGluIHByb3RvY29sPGJy Pg0KZGVzaWduIGluIElFVEYgaXMgdG93YXJkcyBlbmNyeXB0aW5nIG1vcmUgYW5kIG1vcmUuIFRo ZSBsYXN0IHR3bzxicj4NCnRyYW5zcG9ydCBwcm90b2NvbHMgdGhhdCB3ZXJlIGRlc2lnbmVkIGFu ZCB3aWRlbHkgZGVwbG95ZWQgKFNDVFAgb3Zlcjxicj4NCkRUTFMgYW5kIFFVSUMpIGJvdGggZW5j cnlwdCB0aGUgdmFzdCBtYWpvcml0eSBvZiB0aGUgcHJvdG9jb2w8YnI+DQptZXRhZGF0YS4gVGhp cyBkb2N1bWVudCBhZHZlcnRpc2VzIGl0c2VsZiBhcyAmcXVvdDtjb25zaWRlcmF0aW9ucyZxdW90 Ozxicj4NCmZvciBkZXNpZ24gb2Ygc3VjaCBwcm90b2NvbHM6PGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwO1RoZSB0cmFuc3BvcnQgcHJvdG9jb2xzIGRldmVsb3BlZCBmb3IgdGhlIEludGVybmV0IGFy ZSB1c2VkIGFjcm9zcyBhPGJyPg0KJm5ic3A7ICZuYnNwO3dpZGUgcmFuZ2Ugb2YgcGF0aHMgYWNy b3NzIG5ldHdvcmsgc2VnbWVudHMgd2l0aCBtYW55IGRpZmZlcmVudDxicj4NCiZuYnNwOyAmbmJz cDtyZWd1bGF0b3J5LCBjb21tZXJjaWFsLCBhbmQgZW5naW5lZXJpbmcgY29uc2lkZXJhdGlvbnMu Jm5ic3A7IFRoaXM8YnI+DQombmJzcDsgJm5ic3A7ZG9jdW1lbnQgY29uc2lkZXJzIHNvbWUgb2Yg dGhlIGNvc3RzIGFuZCBjaGFuZ2VzIHRvIG5ldHdvcms8YnI+DQombmJzcDsgJm5ic3A7bWFuYWdl bWVudCBhbmQgcmVzZWFyY2ggdGhhdCBhcmUgaW1wbGllZCBieSB3aWRlc3ByZWFkIHVzZSBvZjxi cj4NCiZuYnNwOyAmbmJzcDt0cmFuc3BvcnQgcHJvdG9jb2xzIHRoYXQgZW5jcnlwdCB0aGVpciB0 cmFuc3BvcnQgaGVhZGVyIGluZm9ybWF0aW9uLjxicj4NCiZuYnNwOyAmbmJzcDtJdCByZXZpZXdz IHRoZSBpbXBsaWNhdGlvbnMgb2YgZGV2ZWxvcGluZyB0cmFuc3BvcnQgcHJvdG9jb2xzIHRoYXQ8 YnI+DQombmJzcDsgJm5ic3A7dXNlIGVuZC10by1lbmQgZW5jcnlwdGlvbiB0byBwcm92aWRlIGNv bmZpZGVudGlhbGl0eSBvZiB0aGVpcjxicj4NCiZuYnNwOyAmbmJzcDt0cmFuc3BvcnQgbGF5ZXIg aGVhZGVycywgYW5kIGNvbnNpZGVycyB0aGUgZWZmZWN0IG9mIHN1Y2ggY2hhbmdlcyBvbjxicj4N CiZuYnNwOyAmbmJzcDt0cmFuc3BvcnQgcHJvdG9jb2wgZGVzaWduLCB0cmFuc3BvcnQgcHJvdG9j b2wgZXZvbHV0aW9uLCBhbmQgbmV0d29yazxicj4NCiZuYnNwOyAmbmJzcDtvcGVyYXRpb25zLiZu YnNwOyBJdCBhbHNvIGNvbnNpZGVycyBzb21lIGFudGljaXBhdGVkIGltcGxpY2F0aW9ucyBvbjxi cj4NCiZuYnNwOyAmbmJzcDthcHBsaWNhdGlvbiBldm9sdXRpb24uJm5ic3A7IFRoaXMgcHJvdmlk ZXMgY29uc2lkZXJhdGlvbnMgcmVsYXRpbmcgdG8gdGhlPGJyPg0KJm5ic3A7ICZuYnNwO2Rlc2ln biBvZiB0cmFuc3BvcnQgcHJvdG9jb2xzIGFuZCBmZWF0dXJlcyB3aGVyZSB0aGUgdHJhbnNwb3J0 PGJyPg0KJm5ic3A7ICZuYnNwO3Byb3RvY29sIGVuY3J5cHRzIHNvbWUgb3IgYWxsIG9mIHRoZWly IGhlYWRlciBpbmZvcm1hdGlvbi48YnI+DQo8YnI+DQpIb3dldmVyLCBhcyBJIHNhaWQgYWJvdmUs IHRoZSBuZXcgdHJhbnNwb3J0IHByb3RvY29scyB0aGF0IGFyZTxicj4NCmFjdHVhbGx5IGJlaW5n IGRlc2lnbmVkIGFscmVhZHkgZmVhdHVyZSBtZXRhZGF0YSBlbmNyeXB0aW9uIGFuZCBhcyBmYXI8 YnI+DQphcyBJIGNhbiB0ZWxsLCB0aGVyZSBpcyBubyBwcm9zcGVjdGl2ZSBwcm90b2NvbCBuZXcg dHJhbnNwb3J0IHByb3RvY29sPGJyPg0KZGVzaWduIHByb2plY3QgZm9yIHdoaWNoIHRoZXNlIGlz c3VlcyBtaWdodCBiZSBsaXZlLiBJbiB0aGF0IGNvbnRleHQsPGJyPg0KaXQncyBoYXJkIG5vdCB0 byByZWFkIHRoaXMgZG9jdW1lbnQgd2l0aCBpdHMgbG9uZyBsaXRhbnkgb2YgcHJhY3RpY2VzPGJy Pg0Kd2hpY2ggYXJlIGltcGFjdGVkIGJ5IG1ldGFkYXRhIGVuY3J5cHRpb24gYXMgYSBjcml0aXF1 ZSBvZiB0aGU8YnI+DQpkZWNpc2lvbnMgYnkgU0NUUC9EVExTIGFuZCBRVUlDIHRvIGVuY3J5cHQg bW9zdCBvZiB0aGUgbWV0YWRhdGEuPGJyPg0KPGJyPg0KPGJyPg0KVGhpcyBpbXByZXNzaW9uIGlz IHJlaW5mb3JjZWQgYnkgdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBhY3R1YWw8YnI+DQpwcmFjdGlj ZXMgdGhlbXNlbHZlcywgd2hpY2ggZm9jdXNlcyBhbG1vc3QgZW50aXJlbHkgb24gcHJhY3RpY2Vz PGJyPg0Kd2hpY2ggYXBwZWFyIHRvIGJlIGJlbmlnbmx5IG1vdGl2YXRlZCAoZS5nLiwgcGVyZm9y bWFuY2UgbW9uaXRvcmluZyw8YnI+DQp0cm91Ymxlc2hvb3RpbmcsIGV0Yy4pIEhvd2V2ZXIsIHdl IGFsc28ga25vdyB0aGF0IG1ldGFkYXRhIGlzIHdpZGVseTxicj4NCnVzZWQgZm9yIHByYWN0aWNl cyBpbiB3aGljaCB0aGUgbmV0d29yayBvcGVyYXRvciBpcyBhZHZlcnNhcmlhbDxicj4NCnRvIHRo ZSB1c2VyLCBmb3IgaW5zdGFuY2U6PGJyPg0KPGJyPg0KLSBCbG9ja2luZyB0cmFmZmljIGJhc2Vk IG9uIFRDUCBwb3J0LCBJUCBhZGRyZXNzLCBTTkksIGV0Yy48YnI+DQo8YnI+DQotIFBlcmZvcm1h bmNlLWJhc2VkIHRyYWZmaWMgY2xhc3MgZGlzY3JpbWluYXRpb248YnI+DQo8YnI+DQotIE1vbml0 b3JpbmcgdGhlIHVzZXIncyBiZWhhdmlvciB2aWEgaW5kaWNpYSBsaWtlIHRoZSBvbmVzIGFib3Zl PGJyPg0KJm5ic3A7IG9yIHZpYSB0cmFmZmljIGFuYWx5c2lzIChzZWUgWzBdKTxicj4NCjxicj4N ClllcywgSSB1bmRlcnN0YW5kIHRoYXQgdGhlIGF1dGhvcnMgZXhwbGljaXRseSBkaXNjbGFpbSBq dWRnZW1lbnQgb248YnI+DQp0aGVzZSBwcmFjdGljZXMsIGFuZCB0aGUgZG9jdW1lbnQgZG9lcyBi cmllZmx5IHRvdWNoIG9uIHRoZSBnZW5lcmFsPGJyPg0KaWRlYSwgdGhvdWdoIHRoZSAmcXVvdDtj b25jZXJucy4uLmhhdmUgYmVlbiB2b2ljZWQmcXVvdDsgdGVuZHMgdG8gbWluaW1pemUgdGhvc2U8 YnI+DQpjb25jZXJucyBbMV0gYnV0IHRoZSBzZWxlY3Rpb24gb2YgcHJhY3RpY2VzIHRvIGZvY3Vz IG9uIGlzIGV4dHJlbWVseTxicj4NCnRlbGxpbmcuIEZvY3VzaW5nIG9uIHRoZSBkb3duc2lkZXMg b2YgZW5jcnlwdGlvbiBmb3IgKGF0IGxlYXN0PGJyPg0KYXJndWFibHkgd2VsbC1tZWFuaW5nKSBu ZXR3b3JrIHBsYXllcnMgd2hpbGUgbW9zdGx5IGlnbm9yaW5nIHRoZSBsYXJnZTxicj4NCmNsYXNz IG9mIG5vbi1iZW5pZ24gYmVoYXZpb3JzIHdoaWNoIGVuY3J5cHRpb24gaXMgaW50ZW5kZWQgdG8g cHJvdGVjdDxicj4NCmFnYWluc3QgaGFzIHRoZSBlZmZlY3Qgb2Ygb3ZlcmVtcGhhc2l6aW5nIHRo ZSBjb3N0cyBvZiBlbmNyeXB0aW9uIHRvPGJyPg0KdGhvc2UgcGxheWVycyBhbmQgbWluaW1pemlu ZyB0aGUgYmVuZWZpdHMgdG8gdGhlIGVuZHBvaW50cyB3aG9tIGl0IGlzPGJyPg0KaW50ZW5kZWQg dG8gcHJvdGVjdC48YnI+DQo8YnI+DQo8YnI+DQpUbyBiZSBtYXhpbWFsbHkgY2xlYXI6IEkgZG9u J3Qgb2JqZWN0IHRvIHRoaXMgZG9jdW1lbnQgZXhpc3Rpbmc8YnI+DQphbmQgSSBkb24ndCB0aGlu ayB0aGF0IHRoZSBvcGluaW9ucyBpbXBsaWNpdCBpbiBpdCBhcmUgb25lcyB0aGF0PGJyPg0Kc2hv dWxkIG5vdCBiZSBleHByZXNzZWQuIEkgbWVyZWx5IGRvbid0IHRoaW5rIHRoYXQgaXQgc2hvdWxk IGJlPGJyPg0KcHVibGlzaGVkIGFzIGFuIElFVEYgQ29uc2Vuc3VzIGRvY3VtZW50Ljxicj4NCjxi cj4NCi1Fa3I8YnI+DQo8YnI+DQpbMF0gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXdvb2QtcGVhcmctd2Vic2l0ZS1maW5nZXJwcmludGluZy0wMCNzZWN0aW9uLTUi Pg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdvb2QtcGVhcmctd2Vic2l0ZS1m aW5nZXJwcmludGluZy0wMCNzZWN0aW9uLTU8L2E+PGJyPg0KWzFdICZuYnNwOyAmbmJzcDtBbm90 aGVyIG1vdGl2YXRpb24gc3RlbXMgZnJvbSBpbmNyZWFzZWQgY29uY2VybnMgYWJvdXQgcHJpdmFj eSBhbmQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBzdXJ2ZWlsbGFuY2UuJm5ic3A7IFVzZXJz IHZhbHVlIHRoZSBhYmlsaXR5IHRvIHByb3RlY3QgdGhlaXIgaWRlbnRpdHk8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyBhbmQgbG9jYXRpb24sIGFuZCBkZWZlbmQgYWdhaW5zdCBhbmFseXNpcyBv ZiB0aGUgdHJhZmZpYy48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBSZXZlbGF0aW9ucyBhYm91 dCB0aGUgdXNlIG9mIHBlcnZhc2l2ZSBzdXJ2ZWlsbGFuY2UgW1JGQzc2MjRdPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgaGF2ZSwgdG8gc29tZSBleHRlbnQsIGVyb2RlZCB0cnVzdCBpbiB0aGUg c2VydmljZSBvZmZlcmVkIGJ5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgbmV0d29yayBvcGVy YXRvcnMgYW5kIGhhdmUgbGVkIHRvIGFuIGluY3JlYXNlZCB1c2Ugb2YgZW5jcnlwdGlvbjxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRvIGF2b2lkIHVud2FudGVkIGVhdmVzZHJvcHBpbmcgb24g Y29tbXVuaWNhdGlvbnMuJm5ic3A7IENvbmNlcm5zIGhhdmU8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyBhbHNvIGJlZW4gdm9pY2VkIGFib3V0IHRoZSBhZGRpdGlvbiBvZiBpbmZvcm1hdGlvbiB0 byBwYWNrZXRzIGJ5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhpcmQgcGFydGllcyB0byBw cm92aWRlIGFuYWx5dGljcywgY3VzdG9taXNhdGlvbiwgYWR2ZXJ0aXNpbmcsPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgY3Jvc3Mtc2l0ZSB0cmFja2luZyBvZiB1c2VycywgdG8gYmlsbCB0aGUg Y3VzdG9tZXIsIG9yIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgc2VsZWN0aXZlbHkgYWxs b3cgb3IgYmxvY2sgY29udGVudC4mbmJzcDsgV2hhdGV2ZXIgdGhlIHJlYXNvbnMsIHRoZTxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7IElFVEYgaXMgZGVzaWduaW5nIHByb3RvY29scyB0aGF0IGlu Y2x1ZGUgdHJhbnNwb3J0IGhlYWRlcjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGVuY3J5cHRp b24gKGUuZy4sIFFVSUMgW0ktRC5pZXRmLXF1aWMtdHJhbnNwb3J0XSkgdG8gc3VwcGxlbWVudDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSBhbHJlYWR5IHdpZGVzcHJlYWQgcGF5bG9hZCBl bmNyeXB0aW9uLCBhbmQgdG8gZnVydGhlciBsaW1pdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 IGV4cG9zdXJlIG9mIHRyYW5zcG9ydCBtZXRhZGF0YSB0byB0aGUgbmV0d29yay48YnI+DQombmJz cDsgPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBh dHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZQ0K IHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBh bnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5 IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlm ZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl eiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4 cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVz IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwK T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRp c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMg bWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhh dmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+ PC9ib2R5Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B9330314EBA5COPEXCAUBMA2corp_-- From nobody Wed Jul 1 06:20:45 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F713A0AF7; Wed, 1 Jul 2020 06:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=H9Ps5y70; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=H9Ps5y70 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 XpLq86i18fLT; Wed, 1 Jul 2020 06:20:40 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2061.outbound.protection.outlook.com [40.107.21.61]) (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 2BEF03A0AA4; Wed, 1 Jul 2020 06:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=78XuLf3ib3YUQBG3g8aAWxtM/fcBu7eBwSYh/ay0sIA=; b=H9Ps5y70w5aAnlKlAWXCjcycr22HkJAQ/Qf+cno/VGulJKYskG7AGCwMqlz4TFmS6mDV31Oyb8HpNOHvn44dz8biDpvRqGjvYG5iRCJ0swi92iD2Tj8whse2gJoayoZ1iGh7DhTCYlORY52PjockD9G0aEGqM8Nmno9HgPlg64E= Received: from DB6PR0802CA0041.eurprd08.prod.outlook.com (2603:10a6:4:a3::27) by VI1PR08MB3727.eurprd08.prod.outlook.com (2603:10a6:803:b7::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21; Wed, 1 Jul 2020 13:20:36 +0000 Received: from DB5EUR03FT023.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:a3:cafe::a4) by DB6PR0802CA0041.outlook.office365.com (2603:10a6:4:a3::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.20 via Frontend Transport; Wed, 1 Jul 2020 13:20:36 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT023.mail.protection.outlook.com (10.152.20.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Wed, 1 Jul 2020 13:20:36 +0000 Received: ("Tessian outbound a4b10e5b482d:v62"); Wed, 01 Jul 2020 13:20:36 +0000 X-CR-MTA-TID: 64aa7808 Received: from f91e640928f3.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 39B7EC00-81C3-4133-A840-4DA083F2AD3D.1; Wed, 01 Jul 2020 13:20:31 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id f91e640928f3.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 01 Jul 2020 13:20:31 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mOvAbcO+d+V8PNtMpG8PuvHzon5k/zSINU2Kodcnety/fHWujLl6jnmJpahEApDHvKfTqDMCHodakAf4I9xC8mC7pMJg+OCCbNHqJbdUMudbztAny6EK7GhU3p57TmMz/DakFcvO9u7dYR9AX6IyDTYai3MccaDSpNaftODIJDrJcDddlZ6eX9MpnwhOeeV1ONq4kmh2jjKTispHIQW5Z9DMaBeNDFJYLAVfgcN7h4pW/QW8jHFZTcXEdrrjZlbnJVfwblf9Kox7ZP1beiDoFrgJKbY50Mm5EJHnC1Swc60zsl2nBK1ZOrMrRLkQQinbAd9/w1MeyrA81VsLSvuCdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=78XuLf3ib3YUQBG3g8aAWxtM/fcBu7eBwSYh/ay0sIA=; b=M6GehTzEkC5v54hOQz5U5IBYK/4vOhVT+LtmfZnBbO3H3CmpirJgn/3k77FBsl+n10wWv9o7CVzQN1Gd1/1RGQqVkDRNHTDq978H/yw+iPyStCyPb0JirSzOORd7rEtm+n+hITdxJP80FhKbtUI7LmAU0So5jg9vJb/LFmH7ITkFRcY/x1fI+657fola5KvpQa4aydn6VjOLTORpdvp+16Dx6DiaPJx7ZITnxSpcafMHHdmG5izefKNQxwzY3XrHxPNcogLkJz64EfIsuGsmXWj92233CmdUVCdbUkRLAjau+bbY8jDVT7X5IFf7XTl3RG/X7hggPdESdaSjippoGw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=78XuLf3ib3YUQBG3g8aAWxtM/fcBu7eBwSYh/ay0sIA=; b=H9Ps5y70w5aAnlKlAWXCjcycr22HkJAQ/Qf+cno/VGulJKYskG7AGCwMqlz4TFmS6mDV31Oyb8HpNOHvn44dz8biDpvRqGjvYG5iRCJ0swi92iD2Tj8whse2gJoayoZ1iGh7DhTCYlORY52PjockD9G0aEGqM8Nmno9HgPlg64E= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB4977.eurprd08.prod.outlook.com (2603:10a6:208:163::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.21; Wed, 1 Jul 2020 13:20:29 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3131.030; Wed, 1 Jul 2020 13:20:29 +0000 From: Hannes Tschofenig To: "mohamed.boucadair@orange.com" , "Black, David" CC: int-area , "tsvwg@ietf.org" , IETF SAAG Thread-Topic: [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 Thread-Index: AdY9/kL5KQoLk/CbSKeZ9xMZ8uq3SAQe3d4AAAnHrZAAQX40gAAAU19A Date: Wed, 1 Jul 2020 13:20:29 +0000 Message-ID: References: <21886_1593608278_5EFC8856_21886_470_1_787AE7BB302AE849A7480A190F8B9330314EBA5C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <21886_1593608278_5EFC8856_21886_470_1_787AE7BB302AE849A7480A190F8B9330314EBA5C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 71cf9ee7-494e-4a40-bbc7-63e39d5a400a.1 x-checkrecipientchecked: true Authentication-Results-Original: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.121.249] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: ba924e6f-cf52-4836-f219-08d81dc18a98 x-ms-traffictypediagnostic: AM0PR08MB4977:|VI1PR08MB3727: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 04519BA941 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: Fno9NV1gojHFd+XTDhGq/bPqHlu9lI0Nb6r43OQZPeF5iD+ypIz+P970wyjlsQZJyCbsAwCZtpp07WnEZ1gIQ4h5odAeHDJiZNSts1FXGxBz4/4buDkvq2jFlNTWLhHXf+ZyDpwH6lWpszRZeH4AHcaDBNDzJjZBoKEF4xpCiFEkbc4vEfTdsSIiS17fnRTzfEMSD+72a2CHIiaVWOa9n3MqYV0CWCcK3pw26kjJrYA2mb8fkpcCKuWCAZLoYrojvMXhnaXWgPyFRYIJ+UR6u/h+oZNo9+cndNRRXZdoiBBIJpJxuQXYLQWCgb2OX+HasWA0fUBuJBEXUF7GY6sgOODxwqLMjZXHkYFUlnz8Ku9vMy7Xo9GSZv8zwhLK0Qb3GClsze32fI32aWhNlmPJCA== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(39860400002)(366004)(136003)(396003)(6506007)(186003)(83380400001)(166002)(86362001)(66574015)(55016002)(8936002)(8676002)(54906003)(478600001)(316002)(966005)(110136005)(33656002)(9686003)(2906002)(7696005)(26005)(4326008)(53546011)(66476007)(66556008)(71200400001)(76116006)(66446008)(64756008)(52536014)(5660300002)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 3JPFhSH+U2YkhxGr3DfWYOelJokkAfxIBXBVf5XyCaGSNpp9Ulmu2CzHfRPE0ZczoT2+e+GmWweF6DLhqDXDWI1ny7bQ79WJbxot1hdS2r9FBALOGPnGf6QLB/rPRH7XugEe52kUq1rvYSNqKi/B2eV+PlLG9B6LKC/zb3y6HGgxaH+4E4naDbTdUIiBsEK5onxxc6uTURaTxfQiXP4YiYimPegBiqXRq7+KLCpF4tUqTvPNyhaP5WT/sKQg4KI7XzPLlVnWRgDwXaXuVc0vAq3w4mqkUNKnP2fssIe4qcLyavi/YKK6PkgI7eBJ7kHCvXxzZJ0ru0BoZt/GmyjO7AJuVapqDI3HY+EyG21BMQpwxIex3OaF+AFi35/2QW1Lz/NH57jGLU7JOg7qkUVUfXd9Xq4oOyepqQdc0kVO0Zb58ePDgMpffqxSxNik3a4ONCzz5CebOBgBDWPsHnFaBqncCWoaFWySJabGW0N2bwo= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB371604E04179C212341100EEFA6C0AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4977 Original-Authentication-Results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT023.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(376002)(136003)(346002)(396003)(39860400002)(46966005)(478600001)(450100002)(70586007)(8936002)(70206006)(54906003)(336012)(52536014)(33656002)(166002)(82310400002)(83380400001)(4326008)(966005)(9686003)(66574015)(5660300002)(86362001)(356005)(186003)(82740400003)(53546011)(7696005)(33964004)(6506007)(2906002)(47076004)(8676002)(55016002)(30864003)(316002)(81166007)(110136005)(26005); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 2fdf7b8e-d6e8-47f0-c6cd-08d81dc186af X-Forefront-PRVS: 04519BA941 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 4gytnoVnYjxA66B/EnibVzzTI5S5wi9TW1vD3AfMMpByt5veDQyvLuFD1+9mfdTUyPPR6Rh+tdlga7MYgatfUH2m4VG0MN1K5k29o5D1NbchCHGU5bJXfsLKwftIRlGAAsUUOLtw1yfq5hjo+FGQSheQmUnJQ3OxU/r4RwtCBudOsZTAZT2osZqB9iieBgmI1vQ7+NBolW8FPZVwA4lmdJE27AsCUA7YC1YVil64V0pDdA31iNMB+nMLujnOcNb44tITY/SqgQtEO7VlvVnmV5yZ9WNQIyLct3S1r1gu7VETJgfVuzEyEWtXNhYGu6xPdJPJyijhUCT0nko0JwwbqWVhnUi57xKjuGBbD4CFI6B0CANPo92OOecpD83viwCnSTYcA/cgo7H/P7ZTLSfNQ7whhatzPIWw43S+wL7X6MP04ZGY9IqbW2782M+H1EHUpe4xJcXrmRgwbz4dJEhElIajzpQAVI1vKQ7ExVbvDXc= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jul 2020 13:20:36.3968 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ba924e6f-cf52-4836-f219-08d81dc18a98 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT023.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3727 Archived-At: Subject: Re: [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 13:20:44 -0000 --_000_AM0PR08MB371604E04179C212341100EEFA6C0AM0PR08MB3716eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBub3RpY2VkIHRoaXMgaW4gdmFyaW91cyBJRVRGIGRpc2N1c3Npb25zIGFuZCBzbyBJIHdpbGwg ZGVzY3JpYmUgaXQgaW4gdGhlIGFic3RyYWN0Lg0KDQpBIGdyb3VwIG9mIHBlb3BsZSBwcm9wb3Nl IGFuIGlkZWEuIFRob3NlIHdobyBkbyBub3QgbGlrZSB0aGUgaWRlYSBhcmUgdGhlbiBhc2tlZCB0 byBjb252aW5jZSB0aGUgb3JpZ2luYWwgY29udHJpYnV0b3JzIHRoYXQgdGhlaXIgaWRlYSBpcyBu b3Qgc291bmQgb3IgY29udHJpYnV0ZSB0ZXh0IHNvIG1ha2UgaXQgbG9vayBuaWNlci4NCk5vdCBv bmx5IGlzIHRoaXMgcmVxdWlyaW5nIG1lIHRvIHNwZW5kIG15IHRpbWUgb24gc29tZXRoaW5nIEkg ZG9u4oCZdCBhZ3JlZSB3aXRoIGJ1dCBpdCB0dXJucyBvdXQgdGhhdCBubyBkaXNjdXNzaW9ucyB3 aWxsIGNoYW5nZSB0aGUgbWluZCBvZiB0aGUgb3JpZ2luYWwgY29udHJpYnV0b3JzLiBUaGV5IGp1 c3Qgc3Ryb25nbHkgYmVsaWV2ZSBpbiB0aGVpciBpZGVhcy4gVGhleSB3aWxsIGtlZXAgcHJvcG9z aW5nIHRoZSBzYW1lIGlkZWEgb3ZlciBhbmQgb3ZlciBhZ2FpbiAoZm9yIHllYXJzKSB0aWxsIGl0 IGdldHMgcHVibGlzaGVkIGFzIGFuIFJGQy4NCg0KQ2lhbw0KSGFubmVzDQoNCkZyb206IG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQpT ZW50OiBXZWRuZXNkYXksIEp1bHkgMSwgMjAyMCAyOjU4IFBNDQpUbzogSGFubmVzIFRzY2hvZmVu aWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+OyBCbGFjaywgRGF2aWQgPERhdmlkLkJsYWNr QGRlbGwuY29tPg0KQ2M6IGludC1hcmVhIDxpbnQtYXJlYUBpZXRmLm9yZz47IHRzdndnQGlldGYu b3JnOyBJRVRGIFNBQUcgPHNhYWdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW3NhYWddIDNyZCBX R0xDIChsaW1pdGVkLXNjb3BlKTogZHJhZnQtaWV0Zi10c3Z3Zy10cmFuc3BvcnQtZW5jcnlwdC0x NSwgY2xvc2VzIDI5IEp1bmUgMjAyMA0KDQpIaSBIYW5uZXMsDQoNCkl0IHdvdWxkIGJlIGhlbHBm dWwgaWYgeW91IGNhbiBleHBsaWNpdCB0aGUg4oCcd3JvbmcgbWVzc2FnZeKAnSB5b3UgYXJlIHJl ZmVycmluZyB0bywgYW5kIHByZWZlcmFibHkgd2l0aCB0ZXh0IGZyb20gdGhlIGRyYWZ0IGNvbnZl eWluZyB0aGF0IG1lc3NhZ2UuDQoNClRoYW5rIHlvdS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDog SW50LWFyZWEgW21haWx0bzppbnQtYXJlYS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRl IEhhbm5lcyBUc2Nob2ZlbmlnDQpFbnZvecOpIDogbWFyZGkgMzAganVpbiAyMDIwIDA3OjUwDQrD gCA6IEVyaWMgUmVzY29ybGE7IEJsYWNrLCBEYXZpZA0KQ2MgOiBpbnQtYXJlYTsgdHN2d2dAaWV0 Zi5vcmc8bWFpbHRvOnRzdndnQGlldGYub3JnPjsgSUVURiBTQUFHDQpPYmpldCA6IFJlOiBbSW50 LWFyZWFdIFtzYWFnXSAzcmQgV0dMQyAobGltaXRlZC1zY29wZSk6IGRyYWZ0LWlldGYtdHN2d2ct dHJhbnNwb3J0LWVuY3J5cHQtMTUsIGNsb3NlcyAyOSBKdW5lIDIwMjANCg0KSSBiZWxpZXZlIHRo aXMgZG9jdW1lbnQgc2lnbmFscyBhIHdyb25nIG1lc3NhZ2UgdG8gdGhlIHdpZGVyIEludGVybmV0 IGNvbW11bml0eS4gSSBhZ3JlZSB0aGF0IGl0IHNob3VsZCBub3QgYmUgcHVibGlzaGVkIGFzIGEg Y29uc2Vuc3VzIGRvY3VtZW50Lg0KDQpJIHVuZGVyc3RhbmQgdGhhdCBzb21lIHBlb3BsZSBhcmUg dW5oYXBweSBhYm91dCBlbmNyeXB0aW5nIG1vcmUgbWV0YS1kYXRhLiBUaGlzIHByZXZlbnRzIHRo ZW0gZnJvbSBkb2luZyB0aGluZ3MgdGhleSB1c2VkIHRvIGRvIGluIHRoZSBwYXN0LCBzb21lIG9m IHdoaWNoIHRoZXkgc2hvdWxkIGhhdmUgbmV2ZXIgZG9uZSBpbiB0aGUgZmlyc3QgcGxhY2UuDQpJ bXByb3ZpbmcgdGhlIHByb3RlY3Rpb24gb2YgbWV0YS1kYXRhIGlzIGltcG9ydGFudCBhbmQgd2Vs bCBzdXBwb3J0ZWQgYnkgYSBsYXJnZSBudW1iZXIgb2YgYWN0aXZpdGllcyBpbiB0aGUgSUVURiAo dGhlIG5vdGFibGUgZXhjZXB0aW9uIGJlaW5nIENvQVArT1NDT1JFKS4NCg0KQ2lhbw0KSGFubmVz DQoNCg0KRnJvbTogc2FhZyA8c2FhZy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzYWFnLWJvdW5j ZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDogVHVlc2RheSwg SnVuZSAzMCwgMjAyMCAzOjAwIEFNDQpUbzogQmxhY2ssIERhdmlkIDxEYXZpZC5CbGFja0BkZWxs LmNvbTxtYWlsdG86RGF2aWQuQmxhY2tAZGVsbC5jb20+Pg0KQ2M6IGludC1hcmVhIDxpbnQtYXJl YUBpZXRmLm9yZzxtYWlsdG86aW50LWFyZWFAaWV0Zi5vcmc+PjsgdHN2d2dAaWV0Zi5vcmc8bWFp bHRvOnRzdndnQGlldGYub3JnPjsgSUVURiBTQUFHIDxzYWFnQGlldGYub3JnPG1haWx0bzpzYWFn QGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbc2FhZ10gM3JkIFdHTEMgKGxpbWl0ZWQtc2NvcGUp OiBkcmFmdC1pZXRmLXRzdndnLXRyYW5zcG9ydC1lbmNyeXB0LTE1LCBjbG9zZXMgMjkgSnVuZSAy MDIwDQoNCj4NCj4gVGhpcyAzcmQgV0dMQyBpcyBsaW1pdGVkIHRvIHRoZSBmb2xsb3dpbmcgdHdv IHRvcGljczoNCj4NCj4NCj4gICAgIFdoZXRoZXIgb3Igbm90IHRvIHByb2NlZWQgd2l0aCBhIHJl cXVlc3QgZm9yIFJGQyBwdWJsaWNhdGlvbg0KPg0KPiBvZiB0aGUgZHJhZnQuICAgVGhlIGRlY2lz aW9uIG9uIHdoZXRoZXIgb3Igbm90IHRvIHByb2NlZWQgd2lsbA0KPiBiZSBiYXNlZCBvbiByb3Vn aCBjb25zZW5zdXMgb2YgdGhlIFdHLCBzZWUgUkZDIDcyODIuDQo+IER1cmluZyB0aGUgMm5kIFdH TEMsIEVyaWMgUmVzY29ybGEgYW5kIERhdmlkIFNjaGluYXppIGV4cHJlc3NlZA0KPiBzdHJvbmcg dmlld3MgdGhhdCB0aGlzIGRyYWZ0IHNob3VsZCBub3QgYmUgcHVibGlzaGVkIOKAkyAgdGhvc2UN Cj4gY29uY2VybnMgaGF2ZSBub3QgYmVlbiByZXNvbHZlZCBhbmQgYXJlIGNhcnJpZWQgZm9yd2Fy ZCB0bw0KPiB0aGlzIFdHTEMuICBUaGlzIGVtYWlsIG1lc3NhZ2Ugd2FzIGFuIGF0dGVtcHQgdG8g c3VtbWFyaXplDQo+IHRob3NlIGNvbmNlcm5zOg0KPg0KPiBodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvbXNnL3RzdndnL2k0cXlZMUhScUt3bTBKbWU5VXRFYjZEeWhYVS8NCj4NCj4g RnVydGhlciBleHBsYW5hdGlvbiBmcm9tIGJvdGggRXJpYyBSZXNjb3JsYSBhbmQgRGF2aWQgU2No aW5hemkNCj4gaXMgd2VsY29tZSBhbmQgZW5jb3VyYWdlZCB0byBlbnN1cmUgdGhhdCB0aGVpciBj b25jZXJucyBhcmUNCj4gY2xlYXJseSB1bmRlcnN0b29kLg0KDQpXZWxsLCBJJ2xsIHRyeSBhZ2Fp biwgYnV0IEknbSBub3Qgc3VyZSB0aGF0IEkgY2FuIGRvIGJldHRlciB0aGFuDQpJIGhhdmUgYmVm b3JlLg0KDQpGb3IgcmVhc29ucyB0aGF0IGFyZSBsYWlkIG91dCBpbiBSRkMgNzI1OCwgdGhlIHRy ZW5kIGluIHByb3RvY29sDQpkZXNpZ24gaW4gSUVURiBpcyB0b3dhcmRzIGVuY3J5cHRpbmcgbW9y ZSBhbmQgbW9yZS4gVGhlIGxhc3QgdHdvDQp0cmFuc3BvcnQgcHJvdG9jb2xzIHRoYXQgd2VyZSBk ZXNpZ25lZCBhbmQgd2lkZWx5IGRlcGxveWVkIChTQ1RQIG92ZXINCkRUTFMgYW5kIFFVSUMpIGJv dGggZW5jcnlwdCB0aGUgdmFzdCBtYWpvcml0eSBvZiB0aGUgcHJvdG9jb2wNCm1ldGFkYXRhLiBU aGlzIGRvY3VtZW50IGFkdmVydGlzZXMgaXRzZWxmIGFzICJjb25zaWRlcmF0aW9ucyINCmZvciBk ZXNpZ24gb2Ygc3VjaCBwcm90b2NvbHM6DQoNCiAgIFRoZSB0cmFuc3BvcnQgcHJvdG9jb2xzIGRl dmVsb3BlZCBmb3IgdGhlIEludGVybmV0IGFyZSB1c2VkIGFjcm9zcyBhDQogICB3aWRlIHJhbmdl IG9mIHBhdGhzIGFjcm9zcyBuZXR3b3JrIHNlZ21lbnRzIHdpdGggbWFueSBkaWZmZXJlbnQNCiAg IHJlZ3VsYXRvcnksIGNvbW1lcmNpYWwsIGFuZCBlbmdpbmVlcmluZyBjb25zaWRlcmF0aW9ucy4g IFRoaXMNCiAgIGRvY3VtZW50IGNvbnNpZGVycyBzb21lIG9mIHRoZSBjb3N0cyBhbmQgY2hhbmdl cyB0byBuZXR3b3JrDQogICBtYW5hZ2VtZW50IGFuZCByZXNlYXJjaCB0aGF0IGFyZSBpbXBsaWVk IGJ5IHdpZGVzcHJlYWQgdXNlIG9mDQogICB0cmFuc3BvcnQgcHJvdG9jb2xzIHRoYXQgZW5jcnlw dCB0aGVpciB0cmFuc3BvcnQgaGVhZGVyIGluZm9ybWF0aW9uLg0KICAgSXQgcmV2aWV3cyB0aGUg aW1wbGljYXRpb25zIG9mIGRldmVsb3BpbmcgdHJhbnNwb3J0IHByb3RvY29scyB0aGF0DQogICB1 c2UgZW5kLXRvLWVuZCBlbmNyeXB0aW9uIHRvIHByb3ZpZGUgY29uZmlkZW50aWFsaXR5IG9mIHRo ZWlyDQogICB0cmFuc3BvcnQgbGF5ZXIgaGVhZGVycywgYW5kIGNvbnNpZGVycyB0aGUgZWZmZWN0 IG9mIHN1Y2ggY2hhbmdlcyBvbg0KICAgdHJhbnNwb3J0IHByb3RvY29sIGRlc2lnbiwgdHJhbnNw b3J0IHByb3RvY29sIGV2b2x1dGlvbiwgYW5kIG5ldHdvcmsNCiAgIG9wZXJhdGlvbnMuICBJdCBh bHNvIGNvbnNpZGVycyBzb21lIGFudGljaXBhdGVkIGltcGxpY2F0aW9ucyBvbg0KICAgYXBwbGlj YXRpb24gZXZvbHV0aW9uLiAgVGhpcyBwcm92aWRlcyBjb25zaWRlcmF0aW9ucyByZWxhdGluZyB0 byB0aGUNCiAgIGRlc2lnbiBvZiB0cmFuc3BvcnQgcHJvdG9jb2xzIGFuZCBmZWF0dXJlcyB3aGVy ZSB0aGUgdHJhbnNwb3J0DQogICBwcm90b2NvbCBlbmNyeXB0cyBzb21lIG9yIGFsbCBvZiB0aGVp ciBoZWFkZXIgaW5mb3JtYXRpb24uDQoNCkhvd2V2ZXIsIGFzIEkgc2FpZCBhYm92ZSwgdGhlIG5l dyB0cmFuc3BvcnQgcHJvdG9jb2xzIHRoYXQgYXJlDQphY3R1YWxseSBiZWluZyBkZXNpZ25lZCBh bHJlYWR5IGZlYXR1cmUgbWV0YWRhdGEgZW5jcnlwdGlvbiBhbmQgYXMgZmFyDQphcyBJIGNhbiB0 ZWxsLCB0aGVyZSBpcyBubyBwcm9zcGVjdGl2ZSBwcm90b2NvbCBuZXcgdHJhbnNwb3J0IHByb3Rv Y29sDQpkZXNpZ24gcHJvamVjdCBmb3Igd2hpY2ggdGhlc2UgaXNzdWVzIG1pZ2h0IGJlIGxpdmUu IEluIHRoYXQgY29udGV4dCwNCml0J3MgaGFyZCBub3QgdG8gcmVhZCB0aGlzIGRvY3VtZW50IHdp dGggaXRzIGxvbmcgbGl0YW55IG9mIHByYWN0aWNlcw0Kd2hpY2ggYXJlIGltcGFjdGVkIGJ5IG1l dGFkYXRhIGVuY3J5cHRpb24gYXMgYSBjcml0aXF1ZSBvZiB0aGUNCmRlY2lzaW9ucyBieSBTQ1RQ L0RUTFMgYW5kIFFVSUMgdG8gZW5jcnlwdCBtb3N0IG9mIHRoZSBtZXRhZGF0YS4NCg0KDQpUaGlz IGltcHJlc3Npb24gaXMgcmVpbmZvcmNlZCBieSB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIGFjdHVh bA0KcHJhY3RpY2VzIHRoZW1zZWx2ZXMsIHdoaWNoIGZvY3VzZXMgYWxtb3N0IGVudGlyZWx5IG9u IHByYWN0aWNlcw0Kd2hpY2ggYXBwZWFyIHRvIGJlIGJlbmlnbmx5IG1vdGl2YXRlZCAoZS5nLiwg cGVyZm9ybWFuY2UgbW9uaXRvcmluZywNCnRyb3VibGVzaG9vdGluZywgZXRjLikgSG93ZXZlciwg d2UgYWxzbyBrbm93IHRoYXQgbWV0YWRhdGEgaXMgd2lkZWx5DQp1c2VkIGZvciBwcmFjdGljZXMg aW4gd2hpY2ggdGhlIG5ldHdvcmsgb3BlcmF0b3IgaXMgYWR2ZXJzYXJpYWwNCnRvIHRoZSB1c2Vy LCBmb3IgaW5zdGFuY2U6DQoNCi0gQmxvY2tpbmcgdHJhZmZpYyBiYXNlZCBvbiBUQ1AgcG9ydCwg SVAgYWRkcmVzcywgU05JLCBldGMuDQoNCi0gUGVyZm9ybWFuY2UtYmFzZWQgdHJhZmZpYyBjbGFz cyBkaXNjcmltaW5hdGlvbg0KDQotIE1vbml0b3JpbmcgdGhlIHVzZXIncyBiZWhhdmlvciB2aWEg aW5kaWNpYSBsaWtlIHRoZSBvbmVzIGFib3ZlDQogIG9yIHZpYSB0cmFmZmljIGFuYWx5c2lzIChz ZWUgWzBdKQ0KDQpZZXMsIEkgdW5kZXJzdGFuZCB0aGF0IHRoZSBhdXRob3JzIGV4cGxpY2l0bHkg ZGlzY2xhaW0ganVkZ2VtZW50IG9uDQp0aGVzZSBwcmFjdGljZXMsIGFuZCB0aGUgZG9jdW1lbnQg ZG9lcyBicmllZmx5IHRvdWNoIG9uIHRoZSBnZW5lcmFsDQppZGVhLCB0aG91Z2ggdGhlICJjb25j ZXJucy4uLmhhdmUgYmVlbiB2b2ljZWQiIHRlbmRzIHRvIG1pbmltaXplIHRob3NlDQpjb25jZXJu cyBbMV0gYnV0IHRoZSBzZWxlY3Rpb24gb2YgcHJhY3RpY2VzIHRvIGZvY3VzIG9uIGlzIGV4dHJl bWVseQ0KdGVsbGluZy4gRm9jdXNpbmcgb24gdGhlIGRvd25zaWRlcyBvZiBlbmNyeXB0aW9uIGZv ciAoYXQgbGVhc3QNCmFyZ3VhYmx5IHdlbGwtbWVhbmluZykgbmV0d29yayBwbGF5ZXJzIHdoaWxl IG1vc3RseSBpZ25vcmluZyB0aGUgbGFyZ2UNCmNsYXNzIG9mIG5vbi1iZW5pZ24gYmVoYXZpb3Jz IHdoaWNoIGVuY3J5cHRpb24gaXMgaW50ZW5kZWQgdG8gcHJvdGVjdA0KYWdhaW5zdCBoYXMgdGhl IGVmZmVjdCBvZiBvdmVyZW1waGFzaXppbmcgdGhlIGNvc3RzIG9mIGVuY3J5cHRpb24gdG8NCnRo b3NlIHBsYXllcnMgYW5kIG1pbmltaXppbmcgdGhlIGJlbmVmaXRzIHRvIHRoZSBlbmRwb2ludHMg d2hvbSBpdCBpcw0KaW50ZW5kZWQgdG8gcHJvdGVjdC4NCg0KDQpUbyBiZSBtYXhpbWFsbHkgY2xl YXI6IEkgZG9uJ3Qgb2JqZWN0IHRvIHRoaXMgZG9jdW1lbnQgZXhpc3RpbmcNCmFuZCBJIGRvbid0 IHRoaW5rIHRoYXQgdGhlIG9waW5pb25zIGltcGxpY2l0IGluIGl0IGFyZSBvbmVzIHRoYXQNCnNo b3VsZCBub3QgYmUgZXhwcmVzc2VkLiBJIG1lcmVseSBkb24ndCB0aGluayB0aGF0IGl0IHNob3Vs ZCBiZQ0KcHVibGlzaGVkIGFzIGFuIElFVEYgQ29uc2Vuc3VzIGRvY3VtZW50Lg0KDQotRWtyDQoN ClswXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd29vZC1wZWFyZy13ZWJzaXRl LWZpbmdlcnByaW50aW5nLTAwI3NlY3Rpb24tNQ0KWzFdICAgIEFub3RoZXIgbW90aXZhdGlvbiBz dGVtcyBmcm9tIGluY3JlYXNlZCBjb25jZXJucyBhYm91dCBwcml2YWN5IGFuZA0KICAgICAgc3Vy dmVpbGxhbmNlLiAgVXNlcnMgdmFsdWUgdGhlIGFiaWxpdHkgdG8gcHJvdGVjdCB0aGVpciBpZGVu dGl0eQ0KICAgICAgYW5kIGxvY2F0aW9uLCBhbmQgZGVmZW5kIGFnYWluc3QgYW5hbHlzaXMgb2Yg dGhlIHRyYWZmaWMuDQogICAgICBSZXZlbGF0aW9ucyBhYm91dCB0aGUgdXNlIG9mIHBlcnZhc2l2 ZSBzdXJ2ZWlsbGFuY2UgW1JGQzc2MjRdDQogICAgICBoYXZlLCB0byBzb21lIGV4dGVudCwgZXJv ZGVkIHRydXN0IGluIHRoZSBzZXJ2aWNlIG9mZmVyZWQgYnkNCiAgICAgIG5ldHdvcmsgb3BlcmF0 b3JzIGFuZCBoYXZlIGxlZCB0byBhbiBpbmNyZWFzZWQgdXNlIG9mIGVuY3J5cHRpb24NCiAgICAg IHRvIGF2b2lkIHVud2FudGVkIGVhdmVzZHJvcHBpbmcgb24gY29tbXVuaWNhdGlvbnMuICBDb25j ZXJucyBoYXZlDQogICAgICBhbHNvIGJlZW4gdm9pY2VkIGFib3V0IHRoZSBhZGRpdGlvbiBvZiBp bmZvcm1hdGlvbiB0byBwYWNrZXRzIGJ5DQogICAgICB0aGlyZCBwYXJ0aWVzIHRvIHByb3ZpZGUg YW5hbHl0aWNzLCBjdXN0b21pc2F0aW9uLCBhZHZlcnRpc2luZywNCiAgICAgIGNyb3NzLXNpdGUg dHJhY2tpbmcgb2YgdXNlcnMsIHRvIGJpbGwgdGhlIGN1c3RvbWVyLCBvciB0bw0KICAgICAgc2Vs ZWN0aXZlbHkgYWxsb3cgb3IgYmxvY2sgY29udGVudC4gIFdoYXRldmVyIHRoZSByZWFzb25zLCB0 aGUNCiAgICAgIElFVEYgaXMgZGVzaWduaW5nIHByb3RvY29scyB0aGF0IGluY2x1ZGUgdHJhbnNw b3J0IGhlYWRlcg0KICAgICAgZW5jcnlwdGlvbiAoZS5nLiwgUVVJQyBbSS1ELmlldGYtcXVpYy10 cmFuc3BvcnRdKSB0byBzdXBwbGVtZW50DQogICAgICB0aGUgYWxyZWFkeSB3aWRlc3ByZWFkIHBh eWxvYWQgZW5jcnlwdGlvbiwgYW5kIHRvIGZ1cnRoZXIgbGltaXQNCiAgICAgIGV4cG9zdXJlIG9m IHRyYW5zcG9ydCBtZXRhZGF0YSB0byB0aGUgbmV0d29yay4NCg0KDQoNCg0KDQpJTVBPUlRBTlQg Tk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFy ZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh dGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29u LCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlv biBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2Ug ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBj b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMg ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl cg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0K DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5v dCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9y IGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVu dHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5k IG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRp c2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBw dXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBU aGFuayB5b3UuDQo= --_000_AM0PR08MB371604E04179C212341100EEFA6C0AM0PR08MB3716eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAx IDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NDI4MDQ1OTgwOw0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMzAyNDQ5MDUyIC01NjAzMTU1 ODYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1h dDo2MDY3Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJ bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgbm90 aWNlZCB0aGlzIGluIHZhcmlvdXMgSUVURiBkaXNjdXNzaW9ucyBhbmQgc28gSSB3aWxsIGRlc2Ny aWJlIGl0IGluIHRoZSBhYnN0cmFjdC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIGdyb3Vw IG9mIHBlb3BsZSBwcm9wb3NlIGFuIGlkZWEuIFRob3NlIHdobyBkbyBub3QgbGlrZSB0aGUgaWRl YSBhcmUgdGhlbiBhc2tlZCB0byBjb252aW5jZSB0aGUgb3JpZ2luYWwgY29udHJpYnV0b3JzIHRo YXQgdGhlaXIgaWRlYSBpcyBub3Qgc291bmQgb3IgY29udHJpYnV0ZSB0ZXh0IHNvIG1ha2UgaXQg bG9vayBuaWNlci4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90IG9u bHkgaXMgdGhpcyByZXF1aXJpbmcgbWUgdG8gc3BlbmQgbXkgdGltZSBvbiBzb21ldGhpbmcgSSBk b27igJl0IGFncmVlIHdpdGggYnV0IGl0IHR1cm5zIG91dCB0aGF0IG5vIGRpc2N1c3Npb25zIHdp bGwgY2hhbmdlIHRoZSBtaW5kIG9mIHRoZSBvcmlnaW5hbCBjb250cmlidXRvcnMuIFRoZXkganVz dCBzdHJvbmdseSBiZWxpZXZlIGluIHRoZWlyIGlkZWFzLiBUaGV5IHdpbGwga2VlcCBwcm9wb3Np bmcgdGhlDQogc2FtZSBpZGVhIG92ZXIgYW5kIG92ZXIgYWdhaW4gKGZvciB5ZWFycykgdGlsbCBp dCBnZXRzIHB1Ymxpc2hlZCBhcyBhbiBSRkMuIDxvOnA+DQo8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNp YW88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhbm5lczxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8 L2I+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gJmx0O21vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdWx5IDEsIDIwMjAg Mjo1OCBQTTxicj4NCjxiPlRvOjwvYj4gSGFubmVzIFRzY2hvZmVuaWcgJmx0O0hhbm5lcy5Uc2No b2ZlbmlnQGFybS5jb20mZ3Q7OyBCbGFjaywgRGF2aWQgJmx0O0RhdmlkLkJsYWNrQGRlbGwuY29t Jmd0Ozxicj4NCjxiPkNjOjwvYj4gaW50LWFyZWEgJmx0O2ludC1hcmVhQGlldGYub3JnJmd0Ozsg dHN2d2dAaWV0Zi5vcmc7IElFVEYgU0FBRyAmbHQ7c2FhZ0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUkU6IFtzYWFnXSAzcmQgV0dMQyAobGltaXRlZC1zY29wZSk6IGRyYWZ0LWll dGYtdHN2d2ctdHJhbnNwb3J0LWVuY3J5cHQtMTUsIGNsb3NlcyAyOSBKdW5lIDIwMjA8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+SGkgSGFubmVzLA0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkl0IHdvdWxkIGJlIGhl bHBmdWwgaWYgeW91IGNhbiBleHBsaWNpdCB0aGUg4oCcd3JvbmcgbWVzc2FnZeKAnSB5b3UgYXJl IHJlZmVycmluZyB0bywgYW5kIHByZWZlcmFibHkgd2l0aCB0ZXh0IGZyb20gdGhlIGRyYWZ0IGNv bnZleWluZyB0aGF0IG1lc3NhZ2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPlRoYW5rIHlvdS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5EZSZuYnNwOzo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IEludC1hcmVhIFs8YSBocmVmPSJtYWlsdG86aW50 LWFyZWEtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmludC1hcmVhLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gSGFubmVzIFRzY2hvZmVuaWc8YnI+DQo8Yj5FbnZv ecOpJm5ic3A7OjwvYj4gbWFyZGkgMzAganVpbiAyMDIwIDA3OjUwPGJyPg0KPGI+w4AmbmJzcDs6 PC9iPiBFcmljIFJlc2NvcmxhOyBCbGFjaywgRGF2aWQ8YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IGlu dC1hcmVhOyA8YSBocmVmPSJtYWlsdG86dHN2d2dAaWV0Zi5vcmciPnRzdndnQGlldGYub3JnPC9h PjsgSUVURiBTQUFHPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW0ludC1hcmVhXSBbc2Fh Z10gM3JkIFdHTEMgKGxpbWl0ZWQtc2NvcGUpOiBkcmFmdC1pZXRmLXRzdndnLXRyYW5zcG9ydC1l bmNyeXB0LTE1LCBjbG9zZXMgMjkgSnVuZSAyMDIwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBiZWxpZXZlIHRoaXMgZG9jdW1lbnQgc2lnbmFscyBhIHdy b25nIG1lc3NhZ2UgdG8gdGhlIHdpZGVyIEludGVybmV0IGNvbW11bml0eS4gSSBhZ3JlZSB0aGF0 IGl0IHNob3VsZCBub3QgYmUgcHVibGlzaGVkIGFzIGEgY29uc2Vuc3VzIGRvY3VtZW50Lg0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdW5kZXJzdGFuZCB0aGF0IHNvbWUgcGVvcGxlIGFyZSB1 bmhhcHB5IGFib3V0IGVuY3J5cHRpbmcgbW9yZSBtZXRhLWRhdGEuIFRoaXMgcHJldmVudHMgdGhl bSBmcm9tIGRvaW5nIHRoaW5ncyB0aGV5IHVzZWQgdG8gZG8gaW4gdGhlIHBhc3QsIHNvbWUgb2Yg d2hpY2ggdGhleSBzaG91bGQgaGF2ZSBuZXZlciBkb25lIGluIHRoZSBmaXJzdCBwbGFjZS4NCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW1wcm92aW5nIHRoZSBwcm90ZWN0 aW9uIG9mIG1ldGEtZGF0YSBpcyBpbXBvcnRhbnQgYW5kIHdlbGwgc3VwcG9ydGVkIGJ5IGEgbGFy Z2UgbnVtYmVyIG9mIGFjdGl2aXRpZXMgaW4gdGhlIElFVEYgKHRoZSBub3RhYmxlIGV4Y2VwdGlv biBiZWluZyBDb0FQJiM0MztPU0NPUkUpLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNpYW88 YnI+DQpIYW5uZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9t OjwvYj4gc2FhZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhYWctYm91bmNlc0BpZXRmLm9yZyI+c2Fh Zy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXJpYyBSZXNj b3JsYTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDMwLCAyMDIwIDM6MDAgQU08YnI+ DQo8Yj5Ubzo8L2I+IEJsYWNrLCBEYXZpZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkRhdmlkLkJsYWNr QGRlbGwuY29tIj5EYXZpZC5CbGFja0BkZWxsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBp bnQtYXJlYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmludC1hcmVhQGlldGYub3JnIj5pbnQtYXJlYUBp ZXRmLm9yZzwvYT4mZ3Q7OyA8YSBocmVmPSJtYWlsdG86dHN2d2dAaWV0Zi5vcmciPg0KdHN2d2dA aWV0Zi5vcmc8L2E+OyBJRVRGIFNBQUcgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWFnQGlldGYub3Jn Ij5zYWFnQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzYWFnXSAz cmQgV0dMQyAobGltaXRlZC1zY29wZSk6IGRyYWZ0LWlldGYtdHN2d2ctdHJhbnNwb3J0LWVuY3J5 cHQtMTUsIGNsb3NlcyAyOSBKdW5lIDIwMjA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mZ3Q7IDxicj4NCiZndDsgVGhp cyAzcmQgV0dMQyBpcyBsaW1pdGVkIHRvIHRoZSBmb2xsb3dpbmcgdHdvIHRvcGljczo8YnI+DQom Z3Q7ICZuYnNwOzxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IFdoZXRoZXIgb3Ig bm90IHRvIHByb2NlZWQgd2l0aCBhIHJlcXVlc3QgZm9yIFJGQyBwdWJsaWNhdGlvbjxicj4NCiZn dDsgPGJyPg0KJmd0OyBvZiB0aGUgZHJhZnQuICZuYnNwOyBUaGUgZGVjaXNpb24gb24gd2hldGhl ciBvciBub3QgdG8gcHJvY2VlZCB3aWxsPGJyPg0KJmd0OyBiZSBiYXNlZCBvbiByb3VnaCBjb25z ZW5zdXMgb2YgdGhlIFdHLCBzZWUgUkZDIDcyODIuPGJyPg0KJmd0OyBEdXJpbmcgdGhlIDJuZCBX R0xDLCBFcmljIFJlc2NvcmxhIGFuZCBEYXZpZCBTY2hpbmF6aSBleHByZXNzZWQ8YnI+DQomZ3Q7 IHN0cm9uZyB2aWV3cyB0aGF0IHRoaXMgZHJhZnQgc2hvdWxkIG5vdCBiZSBwdWJsaXNoZWQg4oCT ICZuYnNwO3Rob3NlPGJyPg0KJmd0OyBjb25jZXJucyBoYXZlIG5vdCBiZWVuIHJlc29sdmVkIGFu ZCBhcmUgY2FycmllZCBmb3J3YXJkIHRvPGJyPg0KJmd0OyB0aGlzIFdHTEMuJm5ic3A7IFRoaXMg ZW1haWwgbWVzc2FnZSB3YXMgYW4gYXR0ZW1wdCB0byBzdW1tYXJpemU8YnI+DQomZ3Q7IHRob3Nl IGNvbmNlcm5zOjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvbXNnL3RzdndnL2k0cXlZMUhScUt3bTBKbWU5VXRFYjZEeWhYVS8i Pg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy90c3Z3Zy9pNHF5WTFIUnFL d20wSm1lOVV0RWI2RHloWFUvPC9hPjxicj4NCiZndDsgPGJyPg0KJmd0OyBGdXJ0aGVyIGV4cGxh bmF0aW9uIGZyb20gYm90aCBFcmljIFJlc2NvcmxhIGFuZCBEYXZpZCBTY2hpbmF6aTxicj4NCiZn dDsgaXMgd2VsY29tZSBhbmQgZW5jb3VyYWdlZCB0byBlbnN1cmUgdGhhdCB0aGVpciBjb25jZXJu cyBhcmU8YnI+DQomZ3Q7IGNsZWFybHkgdW5kZXJzdG9vZC48YnI+DQo8YnI+DQpXZWxsLCBJJ2xs IHRyeSBhZ2FpbiwgYnV0IEknbSBub3Qgc3VyZSB0aGF0IEkgY2FuIGRvIGJldHRlciB0aGFuPGJy Pg0KSSBoYXZlIGJlZm9yZS48YnI+DQo8YnI+DQpGb3IgcmVhc29ucyB0aGF0IGFyZSBsYWlkIG91 dCBpbiBSRkMgNzI1OCwgdGhlIHRyZW5kIGluIHByb3RvY29sPGJyPg0KZGVzaWduIGluIElFVEYg aXMgdG93YXJkcyBlbmNyeXB0aW5nIG1vcmUgYW5kIG1vcmUuIFRoZSBsYXN0IHR3bzxicj4NCnRy YW5zcG9ydCBwcm90b2NvbHMgdGhhdCB3ZXJlIGRlc2lnbmVkIGFuZCB3aWRlbHkgZGVwbG95ZWQg KFNDVFAgb3Zlcjxicj4NCkRUTFMgYW5kIFFVSUMpIGJvdGggZW5jcnlwdCB0aGUgdmFzdCBtYWpv cml0eSBvZiB0aGUgcHJvdG9jb2w8YnI+DQptZXRhZGF0YS4gVGhpcyBkb2N1bWVudCBhZHZlcnRp c2VzIGl0c2VsZiBhcyAmcXVvdDtjb25zaWRlcmF0aW9ucyZxdW90Ozxicj4NCmZvciBkZXNpZ24g b2Ygc3VjaCBwcm90b2NvbHM6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO1RoZSB0cmFuc3BvcnQg cHJvdG9jb2xzIGRldmVsb3BlZCBmb3IgdGhlIEludGVybmV0IGFyZSB1c2VkIGFjcm9zcyBhPGJy Pg0KJm5ic3A7ICZuYnNwO3dpZGUgcmFuZ2Ugb2YgcGF0aHMgYWNyb3NzIG5ldHdvcmsgc2VnbWVu dHMgd2l0aCBtYW55IGRpZmZlcmVudDxicj4NCiZuYnNwOyAmbmJzcDtyZWd1bGF0b3J5LCBjb21t ZXJjaWFsLCBhbmQgZW5naW5lZXJpbmcgY29uc2lkZXJhdGlvbnMuJm5ic3A7IFRoaXM8YnI+DQom bmJzcDsgJm5ic3A7ZG9jdW1lbnQgY29uc2lkZXJzIHNvbWUgb2YgdGhlIGNvc3RzIGFuZCBjaGFu Z2VzIHRvIG5ldHdvcms8YnI+DQombmJzcDsgJm5ic3A7bWFuYWdlbWVudCBhbmQgcmVzZWFyY2gg dGhhdCBhcmUgaW1wbGllZCBieSB3aWRlc3ByZWFkIHVzZSBvZjxicj4NCiZuYnNwOyAmbmJzcDt0 cmFuc3BvcnQgcHJvdG9jb2xzIHRoYXQgZW5jcnlwdCB0aGVpciB0cmFuc3BvcnQgaGVhZGVyIGlu Zm9ybWF0aW9uLjxicj4NCiZuYnNwOyAmbmJzcDtJdCByZXZpZXdzIHRoZSBpbXBsaWNhdGlvbnMg b2YgZGV2ZWxvcGluZyB0cmFuc3BvcnQgcHJvdG9jb2xzIHRoYXQ8YnI+DQombmJzcDsgJm5ic3A7 dXNlIGVuZC10by1lbmQgZW5jcnlwdGlvbiB0byBwcm92aWRlIGNvbmZpZGVudGlhbGl0eSBvZiB0 aGVpcjxicj4NCiZuYnNwOyAmbmJzcDt0cmFuc3BvcnQgbGF5ZXIgaGVhZGVycywgYW5kIGNvbnNp ZGVycyB0aGUgZWZmZWN0IG9mIHN1Y2ggY2hhbmdlcyBvbjxicj4NCiZuYnNwOyAmbmJzcDt0cmFu c3BvcnQgcHJvdG9jb2wgZGVzaWduLCB0cmFuc3BvcnQgcHJvdG9jb2wgZXZvbHV0aW9uLCBhbmQg bmV0d29yazxicj4NCiZuYnNwOyAmbmJzcDtvcGVyYXRpb25zLiZuYnNwOyBJdCBhbHNvIGNvbnNp ZGVycyBzb21lIGFudGljaXBhdGVkIGltcGxpY2F0aW9ucyBvbjxicj4NCiZuYnNwOyAmbmJzcDth cHBsaWNhdGlvbiBldm9sdXRpb24uJm5ic3A7IFRoaXMgcHJvdmlkZXMgY29uc2lkZXJhdGlvbnMg cmVsYXRpbmcgdG8gdGhlPGJyPg0KJm5ic3A7ICZuYnNwO2Rlc2lnbiBvZiB0cmFuc3BvcnQgcHJv dG9jb2xzIGFuZCBmZWF0dXJlcyB3aGVyZSB0aGUgdHJhbnNwb3J0PGJyPg0KJm5ic3A7ICZuYnNw O3Byb3RvY29sIGVuY3J5cHRzIHNvbWUgb3IgYWxsIG9mIHRoZWlyIGhlYWRlciBpbmZvcm1hdGlv bi48YnI+DQo8YnI+DQpIb3dldmVyLCBhcyBJIHNhaWQgYWJvdmUsIHRoZSBuZXcgdHJhbnNwb3J0 IHByb3RvY29scyB0aGF0IGFyZTxicj4NCmFjdHVhbGx5IGJlaW5nIGRlc2lnbmVkIGFscmVhZHkg ZmVhdHVyZSBtZXRhZGF0YSBlbmNyeXB0aW9uIGFuZCBhcyBmYXI8YnI+DQphcyBJIGNhbiB0ZWxs LCB0aGVyZSBpcyBubyBwcm9zcGVjdGl2ZSBwcm90b2NvbCBuZXcgdHJhbnNwb3J0IHByb3RvY29s PGJyPg0KZGVzaWduIHByb2plY3QgZm9yIHdoaWNoIHRoZXNlIGlzc3VlcyBtaWdodCBiZSBsaXZl LiBJbiB0aGF0IGNvbnRleHQsPGJyPg0KaXQncyBoYXJkIG5vdCB0byByZWFkIHRoaXMgZG9jdW1l bnQgd2l0aCBpdHMgbG9uZyBsaXRhbnkgb2YgcHJhY3RpY2VzPGJyPg0Kd2hpY2ggYXJlIGltcGFj dGVkIGJ5IG1ldGFkYXRhIGVuY3J5cHRpb24gYXMgYSBjcml0aXF1ZSBvZiB0aGU8YnI+DQpkZWNp c2lvbnMgYnkgU0NUUC9EVExTIGFuZCBRVUlDIHRvIGVuY3J5cHQgbW9zdCBvZiB0aGUgbWV0YWRh dGEuPGJyPg0KPGJyPg0KPGJyPg0KVGhpcyBpbXByZXNzaW9uIGlzIHJlaW5mb3JjZWQgYnkgdGhl IGRlc2NyaXB0aW9uIG9mIHRoZSBhY3R1YWw8YnI+DQpwcmFjdGljZXMgdGhlbXNlbHZlcywgd2hp Y2ggZm9jdXNlcyBhbG1vc3QgZW50aXJlbHkgb24gcHJhY3RpY2VzPGJyPg0Kd2hpY2ggYXBwZWFy IHRvIGJlIGJlbmlnbmx5IG1vdGl2YXRlZCAoZS5nLiwgcGVyZm9ybWFuY2UgbW9uaXRvcmluZyw8 YnI+DQp0cm91Ymxlc2hvb3RpbmcsIGV0Yy4pIEhvd2V2ZXIsIHdlIGFsc28ga25vdyB0aGF0IG1l dGFkYXRhIGlzIHdpZGVseTxicj4NCnVzZWQgZm9yIHByYWN0aWNlcyBpbiB3aGljaCB0aGUgbmV0 d29yayBvcGVyYXRvciBpcyBhZHZlcnNhcmlhbDxicj4NCnRvIHRoZSB1c2VyLCBmb3IgaW5zdGFu Y2U6PGJyPg0KPGJyPg0KLSBCbG9ja2luZyB0cmFmZmljIGJhc2VkIG9uIFRDUCBwb3J0LCBJUCBh ZGRyZXNzLCBTTkksIGV0Yy48YnI+DQo8YnI+DQotIFBlcmZvcm1hbmNlLWJhc2VkIHRyYWZmaWMg Y2xhc3MgZGlzY3JpbWluYXRpb248YnI+DQo8YnI+DQotIE1vbml0b3JpbmcgdGhlIHVzZXIncyBi ZWhhdmlvciB2aWEgaW5kaWNpYSBsaWtlIHRoZSBvbmVzIGFib3ZlPGJyPg0KJm5ic3A7IG9yIHZp YSB0cmFmZmljIGFuYWx5c2lzIChzZWUgWzBdKTxicj4NCjxicj4NClllcywgSSB1bmRlcnN0YW5k IHRoYXQgdGhlIGF1dGhvcnMgZXhwbGljaXRseSBkaXNjbGFpbSBqdWRnZW1lbnQgb248YnI+DQp0 aGVzZSBwcmFjdGljZXMsIGFuZCB0aGUgZG9jdW1lbnQgZG9lcyBicmllZmx5IHRvdWNoIG9uIHRo ZSBnZW5lcmFsPGJyPg0KaWRlYSwgdGhvdWdoIHRoZSAmcXVvdDtjb25jZXJucy4uLmhhdmUgYmVl biB2b2ljZWQmcXVvdDsgdGVuZHMgdG8gbWluaW1pemUgdGhvc2U8YnI+DQpjb25jZXJucyBbMV0g YnV0IHRoZSBzZWxlY3Rpb24gb2YgcHJhY3RpY2VzIHRvIGZvY3VzIG9uIGlzIGV4dHJlbWVseTxi cj4NCnRlbGxpbmcuIEZvY3VzaW5nIG9uIHRoZSBkb3duc2lkZXMgb2YgZW5jcnlwdGlvbiBmb3Ig KGF0IGxlYXN0PGJyPg0KYXJndWFibHkgd2VsbC1tZWFuaW5nKSBuZXR3b3JrIHBsYXllcnMgd2hp bGUgbW9zdGx5IGlnbm9yaW5nIHRoZSBsYXJnZTxicj4NCmNsYXNzIG9mIG5vbi1iZW5pZ24gYmVo YXZpb3JzIHdoaWNoIGVuY3J5cHRpb24gaXMgaW50ZW5kZWQgdG8gcHJvdGVjdDxicj4NCmFnYWlu c3QgaGFzIHRoZSBlZmZlY3Qgb2Ygb3ZlcmVtcGhhc2l6aW5nIHRoZSBjb3N0cyBvZiBlbmNyeXB0 aW9uIHRvPGJyPg0KdGhvc2UgcGxheWVycyBhbmQgbWluaW1pemluZyB0aGUgYmVuZWZpdHMgdG8g dGhlIGVuZHBvaW50cyB3aG9tIGl0IGlzPGJyPg0KaW50ZW5kZWQgdG8gcHJvdGVjdC48YnI+DQo8 YnI+DQo8YnI+DQpUbyBiZSBtYXhpbWFsbHkgY2xlYXI6IEkgZG9uJ3Qgb2JqZWN0IHRvIHRoaXMg ZG9jdW1lbnQgZXhpc3Rpbmc8YnI+DQphbmQgSSBkb24ndCB0aGluayB0aGF0IHRoZSBvcGluaW9u cyBpbXBsaWNpdCBpbiBpdCBhcmUgb25lcyB0aGF0PGJyPg0Kc2hvdWxkIG5vdCBiZSBleHByZXNz ZWQuIEkgbWVyZWx5IGRvbid0IHRoaW5rIHRoYXQgaXQgc2hvdWxkIGJlPGJyPg0KcHVibGlzaGVk IGFzIGFuIElFVEYgQ29uc2Vuc3VzIGRvY3VtZW50Ljxicj4NCjxicj4NCi1Fa3I8YnI+DQo8YnI+ DQpbMF0gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdvb2QtcGVh cmctd2Vic2l0ZS1maW5nZXJwcmludGluZy0wMCNzZWN0aW9uLTUiPg0KaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXdvb2QtcGVhcmctd2Vic2l0ZS1maW5nZXJwcmludGluZy0wMCNz ZWN0aW9uLTU8L2E+PGJyPg0KWzFdICZuYnNwOyAmbmJzcDtBbm90aGVyIG1vdGl2YXRpb24gc3Rl bXMgZnJvbSBpbmNyZWFzZWQgY29uY2VybnMgYWJvdXQgcHJpdmFjeSBhbmQ8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyBzdXJ2ZWlsbGFuY2UuJm5ic3A7IFVzZXJzIHZhbHVlIHRoZSBhYmlsaXR5 IHRvIHByb3RlY3QgdGhlaXIgaWRlbnRpdHk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBhbmQg bG9jYXRpb24sIGFuZCBkZWZlbmQgYWdhaW5zdCBhbmFseXNpcyBvZiB0aGUgdHJhZmZpYy48YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyBSZXZlbGF0aW9ucyBhYm91dCB0aGUgdXNlIG9mIHBlcnZh c2l2ZSBzdXJ2ZWlsbGFuY2UgW1JGQzc2MjRdPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgaGF2 ZSwgdG8gc29tZSBleHRlbnQsIGVyb2RlZCB0cnVzdCBpbiB0aGUgc2VydmljZSBvZmZlcmVkIGJ5 PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgbmV0d29yayBvcGVyYXRvcnMgYW5kIGhhdmUgbGVk IHRvIGFuIGluY3JlYXNlZCB1c2Ugb2YgZW5jcnlwdGlvbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7IHRvIGF2b2lkIHVud2FudGVkIGVhdmVzZHJvcHBpbmcgb24gY29tbXVuaWNhdGlvbnMuJm5i c3A7IENvbmNlcm5zIGhhdmU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBhbHNvIGJlZW4gdm9p Y2VkIGFib3V0IHRoZSBhZGRpdGlvbiBvZiBpbmZvcm1hdGlvbiB0byBwYWNrZXRzIGJ5PGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhpcmQgcGFydGllcyB0byBwcm92aWRlIGFuYWx5dGljcywg Y3VzdG9taXNhdGlvbiwgYWR2ZXJ0aXNpbmcsPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgY3Jv c3Mtc2l0ZSB0cmFja2luZyBvZiB1c2VycywgdG8gYmlsbCB0aGUgY3VzdG9tZXIsIG9yIHRvPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgc2VsZWN0aXZlbHkgYWxsb3cgb3IgYmxvY2sgY29udGVu dC4mbmJzcDsgV2hhdGV2ZXIgdGhlIHJlYXNvbnMsIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7IElFVEYgaXMgZGVzaWduaW5nIHByb3RvY29scyB0aGF0IGluY2x1ZGUgdHJhbnNwb3J0IGhl YWRlcjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGVuY3J5cHRpb24gKGUuZy4sIFFVSUMgW0kt RC5pZXRmLXF1aWMtdHJhbnNwb3J0XSkgdG8gc3VwcGxlbWVudDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7IHRoZSBhbHJlYWR5IHdpZGVzcHJlYWQgcGF5bG9hZCBlbmNyeXB0aW9uLCBhbmQgdG8g ZnVydGhlciBsaW1pdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGV4cG9zdXJlIG9mIHRyYW5z cG9ydCBtZXRhZGF0YSB0byB0aGUgbmV0d29yay48YnI+DQombmJzcDsgPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyxzZXJpZiI+SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9m IHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkg YWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCiBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Ns b3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJw b3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFu ayB5b3UuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwcmU+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVz IHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJl dXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+YSBsJ2V4cGVk aXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1l c3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBz aSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86 cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHBy aXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT50aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3Qg bGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBm YWxzaWZpZWQuPG86cD48L286cD48L3ByZT4NCjxwcmU+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9w cmU+DQo8L2Rpdj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWls IGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJp dmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRl bnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsDQogb3Igc3Rv cmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_AM0PR08MB371604E04179C212341100EEFA6C0AM0PR08MB3716eurp_-- From nobody Wed Jul 1 06:56:10 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CF03A05A4; Wed, 1 Jul 2020 06:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=telekom.de 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 K6SBlgdNGHwQ; Wed, 1 Jul 2020 06:56:04 -0700 (PDT) Received: from mailout31.telekom.de (mailout31.telekom.de [194.25.225.143]) (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 7F31D3A0813; Wed, 1 Jul 2020 06:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1593611764; x=1625147764; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8GyhitH691JGocfS3HOI5xTjtLpjblCc6WKzjcv9SHk=; b=ikP9qYs7XO9T96eusjWQXsph281P6pfWuM7/ziJvbZdO3YUyhx1bQFVR yo8MS84B17AcRN5KceEUmzGEdyVXOS+Hjcgs8UEM9bdQb1f7aXCXKvSOH cVfdkr32Oi/TAE2EvBjIzOke7pGeORV97REYOVzs/s21kfElayLiRt9ur BPwsdIb4YHCVgrukUDf3xVGfA0xDn20dZFAk+jwmhpacSUTR9+vLcUhy+ 1H7MIb0YvRMbudMrS10uawwCHF+lg8sCw8QkOZfy9G+McClGJGvyLfgD2 96CMSqe3L0pzN+BB2kkKrDf00lidyffH1sMHkPNfDUoNd6uXb7cCni7mG A==; IronPort-SDR: mDNL4j2aLHkYP3nkM+Nb/d/Dopqe6ZhGuSaYX2ZcFtU4ogUE29TLP0EQKXqsKQyJeJqO1rRR1v g0k8Y8YfvTug== Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2020 15:56:00 +0200 IronPort-SDR: w7wTjtQP3BYpVA36UOHt26rTwBCAv7P3lQO8ttE+xQ1cAabcWGs3HaVkeRIcxRij4XJ+cho8X3 WNI9kNHn39Xb2ng8g8omb8PiM3zp/FQnk= X-IronPort-AV: E=Sophos;i="5.75,300,1589234400"; d="scan'208,217";a="818479383" X-MGA-submission: =?us-ascii?q?MDFw0BvpBE4sc6qocZZrYNMDC7TvJuQ+qTYXKy?= =?us-ascii?q?+74pGlmJ7mpeE+/rzEGnlmxRPpTQagkwcYEre0sNdzIbonmrnwN9l6Ic?= =?us-ascii?q?oA5RX5Op1mTya782MnyUjWE6xhQ5n/iJHjFEXEPXyIV5+iW6VS9KPRUG?= =?us-ascii?q?uQONNUqecSmAmRv75zA8GhZg=3D=3D?= Received: from he105867.emea1.cds.t-internal.com ([10.169.119.44]) by QDE8PP.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 01 Jul 2020 15:56:00 +0200 Received: from HE105864.EMEA1.cds.t-internal.com (10.169.119.41) by HE105867.emea1.cds.t-internal.com (10.169.119.44) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 1 Jul 2020 15:56:00 +0200 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE105864.EMEA1.cds.t-internal.com (10.169.119.41) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 1 Jul 2020 15:56:00 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.16) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 1 Jul 2020 15:55:58 +0200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GIW2uh5IxtTHsIiRBljDTgRHt9efLoh9Uv9Sw8Tzx5udDuIH3dNJFj+4uR9npQ7jVWdH+F3aNS55nhP6iIW2w6WSjNb3ktwJyOS5cZU5aZWsklDp0p7eOVFhDnRLB72wOLpymBFifY236FZxhR233/MUMIwJrUTZ376m5PJ+7TDPGiJzdTgi/Q5iaWhueEk2w5x/tvsrTcLabiVMHDmxhbZJ3OF978n4gN6p/yq59sqLixnUEZ09hOG46sYZotQqN8Z29qdEHa5rTGELLrnDVV1jrDH1TluMbhOoDwZRJFPjMXYxQa+S0Ox56XKWL86rU/f9njT2UmNi5iEVFR10gQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8GyhitH691JGocfS3HOI5xTjtLpjblCc6WKzjcv9SHk=; b=CE5PFqeNJu+UUCLhkghpGKS+aJ/3mWLw0DQzI1a/1B8pi92CKK93YoohqvFm45oUmmPg9A7C6RDy+CNtgLzpIYKOmeuvyU8N2fqiWEZonHRgYUw4ncyrY+olilSzC7SEq6B/gmND9zQSLXbHLmJyPEESDElUgTnim6a2CL2VGgug2rflzBBId1bvWwNhM8gMJdXGtQtTVynZWbqrz+cjjK9opo2N8+gKYWe9LV+bK/RNrJ+/wN2S+IZ/mqUhgoao1uIv8jAoICuQPFrH7/knpgPnBdVHoukZq77Q5HEAXUhBGRzFaiWJXV+HFeE9h3AdBjDY8q3QkSGFNR0+CmmFKg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none Received: from LEXPR01MB1040.DEUPRD01.PROD.OUTLOOK.DE (2a01:4180:c013:10::18) by LEXPR01MB0701.DEUPRD01.PROD.OUTLOOK.DE (2a01:4180:c013:d::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.25; Wed, 1 Jul 2020 13:55:59 +0000 Received: from LEXPR01MB1040.DEUPRD01.PROD.OUTLOOK.DE ([fe80::9570:5376:d64e:6584]) by LEXPR01MB1040.DEUPRD01.PROD.OUTLOOK.DE ([fe80::9570:5376:d64e:6584%8]) with mapi id 15.20.3131.030; Wed, 1 Jul 2020 13:55:59 +0000 From: To: CC: , , Thread-Topic: [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 Thread-Index: AQHWTqKKcYDEsnf9FUGfSu5ndzzjXqjysTaAgAAGTICAAAUUoA== Date: Wed, 1 Jul 2020 13:55:59 +0000 Message-ID: References: <21886_1593608278_5EFC8856_21886_470_1_787AE7BB302AE849A7480A190F8B9330314EBA5C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=telekom.de; x-originating-ip: [164.19.3.232] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7040420d-8d58-48ef-867d-08d81dc67bee x-ms-traffictypediagnostic: LEXPR01MB0701: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04519BA941 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XKS9TKoTwxFdWX8liOx3JRMSkW/Ic8a+L0PhOl7UiBk5h/s1uzSPlECbIxvwG2Kd8uywqX4ZZsFkV+byRfDwSuQ8m6Ym+w6ajlVoyMJBvgNCp02tOuGfY22hnkKtx4BOpGt2hcKc8Zz+yElru5Ukw4bxVTjn5ItKnXmH9EYPiqZ7wGtIxbaWrnSMLD4kBeejuoyif5qE8lqbTltwwqeSNnYaTZNfBg91BnYimjEO2tkgv2JJIPR325Udq/jiFF2aICD/dTYErLSReoA890qm6jwN9hZBSViFaoec/Onx3d2dsnrelTcAXs739BGgFkLrLKx152ITHd7job2r50USYxsTSXLXWeKwmnFIyoHq8ymKpN7VTU+au+YOZXVz3t5qHUsk0s54GtlnowyCmN1TTMxEAxxtHigMtDB4lqDSU9c= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LEXPR01MB1040.DEUPRD01.PROD.OUTLOOK.DE; PTR:; CAT:NONE; SFTY:; SFS:(396003)(346002)(376002)(39860400002)(136003)(366004)(26005)(966005)(8676002)(6916009)(166002)(9326002)(478600001)(53546011)(8936002)(5660300002)(7696005)(9686003)(55016002)(33656002)(186003)(19627235002)(71200400001)(66476007)(66946007)(66574015)(85182001)(316002)(83380400001)(86362001)(85202003)(76116006)(54906003)(66556008)(64756008)(66446008)(4326008)(2906002)(777600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 71N6C4dIjJQ3//SXR8cmZuThte4fwCuB8IKGGkhG3xHf0VDRHK+cY1doYj7tSn0vxw4ZQf1D5SYfg8P7VWCsnz5Izk70x2LrUfCY0EfdInYWe9IiyAjTOJHoZAyRpK92WyyZaav+af8pD3FMeQnUEVrEXU43oG2Jvctq11h9OTnG9mctJif3T+LP9qnkffVOWCGP8WxeIp23NTbwpMHpwg7Zl84+C2Bs7QuvlK0G4S61tI1uLGFLQREcB03+UoauCkQ2IC6+0dhj4sMr3zW2rlyTP0bdXH+iQLeJn/pFeC83DhIQP/v7BxR6yOpwgl4Wkozk65z+Z+Fv9JxzGrF0MFNyAVvxgaySHOgDV0oAl7Za7VD+0R1qQTmRtjsLFszv6C+MZ5CWT8nbRRP3vAUTpQUYyO50xW/4r7gliXpegvkwZ+VuBm9/FrCK4tibA8p3QiY68O6cp7XaQqfW9OYLF87z+lXHlUvGPDiU7PzBrdw= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LEXPR01MB1040C937CACB87CB953E29869C6C0LEXPR01MB1040DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LEXPR01MB1040.DEUPRD01.PROD.OUTLOOK.DE X-MS-Exchange-CrossTenant-Network-Message-Id: 7040420d-8d58-48ef-867d-08d81dc67bee X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2020 13:55:59.2165 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EDSsEVpXeUoPdUAb/bnfXuBbhXGA/oMhFKe69xmCqXluSfzLBJSiPvkxpuj6XRPDDTmGPAwCOrCuNx1woqZWN7bXAY0bO7WoIxvitNezZ/s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB0701 X-TM-SNTS-SMTP: 1B9C38F24E9A3E54780CCE2D6720B825E8010E5A3230BF21EB708244B7B0E3B22000:8 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 13:56:08 -0000 --_000_LEXPR01MB1040C937CACB87CB953E29869C6C0LEXPR01MB1040DEUP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSGFubmVzLA0KDQpkbyBJIHVuZGVyc3RhbmQgeW91IGNvcnJlY3RseSB0aGF0IGV4cG9zaW5n IHRyYW5zcG9ydCBpbmZvcm1hdGlvbiB0byBjYWxjdWxhdGUgYSBmbG93IFJUVCBvciBhIGZsb3cg bG9zcyByYXRlIGJ5IGEgcGFzc2l2ZSBvYnNlcnZlciBhbG9uZyBhIHBhdGggaXMgYSBicmVhayBp biBzZWN1cml0eSB0byB5b3UgKCBzb3JyeSBpZiBJ4oCZbSBhc2tpbmcgc29tZXRoaW5nIHdoZXJl IHlvdeKAmXZlIGV4cHJlc3NlZCB5b3VyIG9waW5pb24gYWxyZWFkeSBlbHNld2hlcmUsIEkgZGlk buKAmXQgZm9sbG93IHRoZSB0cmFuc3BvcnQgZXhwb3N1cmUgdnMgZW5jcnlwdGlvbiBkaXNjdXNz aW9uKSA/DQoNCkp1c3QgdG8gdW5kZXJzdGFuZCB3aGV0aGVyIHRoZXJlIGlzIGFic29sdXRlbHkg bm8gY29tbW9uIGdyb3VuZC4NCg0KUmVnYXJkcywNCg0KUnVlZGlnZXINCg0KVm9uOiB0c3Z3ZyA8 dHN2d2ctYm91bmNlc0BpZXRmLm9yZz4gSW0gQXVmdHJhZyB2b24gSGFubmVzIFRzY2hvZmVuaWcN Ckdlc2VuZGV0OiBNaXR0d29jaCwgMS4gSnVsaSAyMDIwIDE1OjIwDQpBbjogbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbTsgQmxhY2ssIERhdmlkIDxEYXZpZC5CbGFja0BkZWxsLmNvbT4NCkNj OiBpbnQtYXJlYSA8aW50LWFyZWFAaWV0Zi5vcmc+OyB0c3Z3Z0BpZXRmLm9yZzsgSUVURiBTQUFH IDxzYWFnQGlldGYub3JnPg0KQmV0cmVmZjogUmU6IFt0c3Z3Z10gW3NhYWddIDNyZCBXR0xDIChs aW1pdGVkLXNjb3BlKTogZHJhZnQtaWV0Zi10c3Z3Zy10cmFuc3BvcnQtZW5jcnlwdC0xNSwgY2xv c2VzIDI5IEp1bmUgMjAyMA0KDQpJIG5vdGljZWQgdGhpcyBpbiB2YXJpb3VzIElFVEYgZGlzY3Vz c2lvbnMgYW5kIHNvIEkgd2lsbCBkZXNjcmliZSBpdCBpbiB0aGUgYWJzdHJhY3QuDQoNCkEgZ3Jv dXAgb2YgcGVvcGxlIHByb3Bvc2UgYW4gaWRlYS4gVGhvc2Ugd2hvIGRvIG5vdCBsaWtlIHRoZSBp ZGVhIGFyZSB0aGVuIGFza2VkIHRvIGNvbnZpbmNlIHRoZSBvcmlnaW5hbCBjb250cmlidXRvcnMg dGhhdCB0aGVpciBpZGVhIGlzIG5vdCBzb3VuZCBvciBjb250cmlidXRlIHRleHQgc28gbWFrZSBp dCBsb29rIG5pY2VyLg0KTm90IG9ubHkgaXMgdGhpcyByZXF1aXJpbmcgbWUgdG8gc3BlbmQgbXkg dGltZSBvbiBzb21ldGhpbmcgSSBkb27igJl0IGFncmVlIHdpdGggYnV0IGl0IHR1cm5zIG91dCB0 aGF0IG5vIGRpc2N1c3Npb25zIHdpbGwgY2hhbmdlIHRoZSBtaW5kIG9mIHRoZSBvcmlnaW5hbCBj b250cmlidXRvcnMuIFRoZXkganVzdCBzdHJvbmdseSBiZWxpZXZlIGluIHRoZWlyIGlkZWFzLiBU aGV5IHdpbGwga2VlcCBwcm9wb3NpbmcgdGhlIHNhbWUgaWRlYSBvdmVyIGFuZCBvdmVyIGFnYWlu IChmb3IgeWVhcnMpIHRpbGwgaXQgZ2V0cyBwdWJsaXNoZWQgYXMgYW4gUkZDLg0KDQpDaWFvDQpI YW5uZXMNCg0KRnJvbTogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFp bHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+Pg0KU2VudDogV2VkbmVzZGF5LCBKdWx5 IDEsIDIwMjAgMjo1OCBQTQ0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5p Z0Bhcm0uY29tPG1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPj47IEJsYWNrLCBEYXZp ZCA8RGF2aWQuQmxhY2tAZGVsbC5jb208bWFpbHRvOkRhdmlkLkJsYWNrQGRlbGwuY29tPj4NCkNj OiBpbnQtYXJlYSA8aW50LWFyZWFAaWV0Zi5vcmc8bWFpbHRvOmludC1hcmVhQGlldGYub3JnPj47 IHRzdndnQGlldGYub3JnPG1haWx0bzp0c3Z3Z0BpZXRmLm9yZz47IElFVEYgU0FBRyA8c2FhZ0Bp ZXRmLm9yZzxtYWlsdG86c2FhZ0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW3NhYWddIDNyZCBX R0xDIChsaW1pdGVkLXNjb3BlKTogZHJhZnQtaWV0Zi10c3Z3Zy10cmFuc3BvcnQtZW5jcnlwdC0x NSwgY2xvc2VzIDI5IEp1bmUgMjAyMA0KDQpIaSBIYW5uZXMsDQoNCkl0IHdvdWxkIGJlIGhlbHBm dWwgaWYgeW91IGNhbiBleHBsaWNpdCB0aGUg4oCcd3JvbmcgbWVzc2FnZeKAnSB5b3UgYXJlIHJl ZmVycmluZyB0bywgYW5kIHByZWZlcmFibHkgd2l0aCB0ZXh0IGZyb20gdGhlIGRyYWZ0IGNvbnZl eWluZyB0aGF0IG1lc3NhZ2UuDQoNClRoYW5rIHlvdS4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDog SW50LWFyZWEgW21haWx0bzppbnQtYXJlYS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRl IEhhbm5lcyBUc2Nob2ZlbmlnDQpFbnZvecOpIDogbWFyZGkgMzAganVpbiAyMDIwIDA3OjUwDQrD gCA6IEVyaWMgUmVzY29ybGE7IEJsYWNrLCBEYXZpZA0KQ2MgOiBpbnQtYXJlYTsgdHN2d2dAaWV0 Zi5vcmc8bWFpbHRvOnRzdndnQGlldGYub3JnPjsgSUVURiBTQUFHDQpPYmpldCA6IFJlOiBbSW50 LWFyZWFdIFtzYWFnXSAzcmQgV0dMQyAobGltaXRlZC1zY29wZSk6IGRyYWZ0LWlldGYtdHN2d2ct dHJhbnNwb3J0LWVuY3J5cHQtMTUsIGNsb3NlcyAyOSBKdW5lIDIwMjANCg0KSSBiZWxpZXZlIHRo aXMgZG9jdW1lbnQgc2lnbmFscyBhIHdyb25nIG1lc3NhZ2UgdG8gdGhlIHdpZGVyIEludGVybmV0 IGNvbW11bml0eS4gSSBhZ3JlZSB0aGF0IGl0IHNob3VsZCBub3QgYmUgcHVibGlzaGVkIGFzIGEg Y29uc2Vuc3VzIGRvY3VtZW50Lg0KDQpJIHVuZGVyc3RhbmQgdGhhdCBzb21lIHBlb3BsZSBhcmUg dW5oYXBweSBhYm91dCBlbmNyeXB0aW5nIG1vcmUgbWV0YS1kYXRhLiBUaGlzIHByZXZlbnRzIHRo ZW0gZnJvbSBkb2luZyB0aGluZ3MgdGhleSB1c2VkIHRvIGRvIGluIHRoZSBwYXN0LCBzb21lIG9m IHdoaWNoIHRoZXkgc2hvdWxkIGhhdmUgbmV2ZXIgZG9uZSBpbiB0aGUgZmlyc3QgcGxhY2UuDQpJ bXByb3ZpbmcgdGhlIHByb3RlY3Rpb24gb2YgbWV0YS1kYXRhIGlzIGltcG9ydGFudCBhbmQgd2Vs bCBzdXBwb3J0ZWQgYnkgYSBsYXJnZSBudW1iZXIgb2YgYWN0aXZpdGllcyBpbiB0aGUgSUVURiAo dGhlIG5vdGFibGUgZXhjZXB0aW9uIGJlaW5nIENvQVArT1NDT1JFKS4NCg0KQ2lhbw0KSGFubmVz DQoNCg0KRnJvbTogc2FhZyA8c2FhZy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzYWFnLWJvdW5j ZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDogVHVlc2RheSwg SnVuZSAzMCwgMjAyMCAzOjAwIEFNDQpUbzogQmxhY2ssIERhdmlkIDxEYXZpZC5CbGFja0BkZWxs LmNvbTxtYWlsdG86RGF2aWQuQmxhY2tAZGVsbC5jb20+Pg0KQ2M6IGludC1hcmVhIDxpbnQtYXJl YUBpZXRmLm9yZzxtYWlsdG86aW50LWFyZWFAaWV0Zi5vcmc+PjsgdHN2d2dAaWV0Zi5vcmc8bWFp bHRvOnRzdndnQGlldGYub3JnPjsgSUVURiBTQUFHIDxzYWFnQGlldGYub3JnPG1haWx0bzpzYWFn QGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbc2FhZ10gM3JkIFdHTEMgKGxpbWl0ZWQtc2NvcGUp OiBkcmFmdC1pZXRmLXRzdndnLXRyYW5zcG9ydC1lbmNyeXB0LTE1LCBjbG9zZXMgMjkgSnVuZSAy MDIwDQoNCj4NCj4gVGhpcyAzcmQgV0dMQyBpcyBsaW1pdGVkIHRvIHRoZSBmb2xsb3dpbmcgdHdv IHRvcGljczoNCj4NCj4NCj4gICAgIFdoZXRoZXIgb3Igbm90IHRvIHByb2NlZWQgd2l0aCBhIHJl cXVlc3QgZm9yIFJGQyBwdWJsaWNhdGlvbg0KPg0KPiBvZiB0aGUgZHJhZnQuICAgVGhlIGRlY2lz aW9uIG9uIHdoZXRoZXIgb3Igbm90IHRvIHByb2NlZWQgd2lsbA0KPiBiZSBiYXNlZCBvbiByb3Vn aCBjb25zZW5zdXMgb2YgdGhlIFdHLCBzZWUgUkZDIDcyODIuDQo+IER1cmluZyB0aGUgMm5kIFdH TEMsIEVyaWMgUmVzY29ybGEgYW5kIERhdmlkIFNjaGluYXppIGV4cHJlc3NlZA0KPiBzdHJvbmcg dmlld3MgdGhhdCB0aGlzIGRyYWZ0IHNob3VsZCBub3QgYmUgcHVibGlzaGVkIOKAkyAgdGhvc2UN Cj4gY29uY2VybnMgaGF2ZSBub3QgYmVlbiByZXNvbHZlZCBhbmQgYXJlIGNhcnJpZWQgZm9yd2Fy ZCB0bw0KPiB0aGlzIFdHTEMuICBUaGlzIGVtYWlsIG1lc3NhZ2Ugd2FzIGFuIGF0dGVtcHQgdG8g c3VtbWFyaXplDQo+IHRob3NlIGNvbmNlcm5zOg0KPg0KPiBodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvbXNnL3RzdndnL2k0cXlZMUhScUt3bTBKbWU5VXRFYjZEeWhYVS8NCj4NCj4g RnVydGhlciBleHBsYW5hdGlvbiBmcm9tIGJvdGggRXJpYyBSZXNjb3JsYSBhbmQgRGF2aWQgU2No aW5hemkNCj4gaXMgd2VsY29tZSBhbmQgZW5jb3VyYWdlZCB0byBlbnN1cmUgdGhhdCB0aGVpciBj b25jZXJucyBhcmUNCj4gY2xlYXJseSB1bmRlcnN0b29kLg0KDQpXZWxsLCBJJ2xsIHRyeSBhZ2Fp biwgYnV0IEknbSBub3Qgc3VyZSB0aGF0IEkgY2FuIGRvIGJldHRlciB0aGFuDQpJIGhhdmUgYmVm b3JlLg0KDQpGb3IgcmVhc29ucyB0aGF0IGFyZSBsYWlkIG91dCBpbiBSRkMgNzI1OCwgdGhlIHRy ZW5kIGluIHByb3RvY29sDQpkZXNpZ24gaW4gSUVURiBpcyB0b3dhcmRzIGVuY3J5cHRpbmcgbW9y ZSBhbmQgbW9yZS4gVGhlIGxhc3QgdHdvDQp0cmFuc3BvcnQgcHJvdG9jb2xzIHRoYXQgd2VyZSBk ZXNpZ25lZCBhbmQgd2lkZWx5IGRlcGxveWVkIChTQ1RQIG92ZXINCkRUTFMgYW5kIFFVSUMpIGJv dGggZW5jcnlwdCB0aGUgdmFzdCBtYWpvcml0eSBvZiB0aGUgcHJvdG9jb2wNCm1ldGFkYXRhLiBU aGlzIGRvY3VtZW50IGFkdmVydGlzZXMgaXRzZWxmIGFzICJjb25zaWRlcmF0aW9ucyINCmZvciBk ZXNpZ24gb2Ygc3VjaCBwcm90b2NvbHM6DQoNCiAgIFRoZSB0cmFuc3BvcnQgcHJvdG9jb2xzIGRl dmVsb3BlZCBmb3IgdGhlIEludGVybmV0IGFyZSB1c2VkIGFjcm9zcyBhDQogICB3aWRlIHJhbmdl IG9mIHBhdGhzIGFjcm9zcyBuZXR3b3JrIHNlZ21lbnRzIHdpdGggbWFueSBkaWZmZXJlbnQNCiAg IHJlZ3VsYXRvcnksIGNvbW1lcmNpYWwsIGFuZCBlbmdpbmVlcmluZyBjb25zaWRlcmF0aW9ucy4g IFRoaXMNCiAgIGRvY3VtZW50IGNvbnNpZGVycyBzb21lIG9mIHRoZSBjb3N0cyBhbmQgY2hhbmdl cyB0byBuZXR3b3JrDQogICBtYW5hZ2VtZW50IGFuZCByZXNlYXJjaCB0aGF0IGFyZSBpbXBsaWVk IGJ5IHdpZGVzcHJlYWQgdXNlIG9mDQogICB0cmFuc3BvcnQgcHJvdG9jb2xzIHRoYXQgZW5jcnlw dCB0aGVpciB0cmFuc3BvcnQgaGVhZGVyIGluZm9ybWF0aW9uLg0KICAgSXQgcmV2aWV3cyB0aGUg aW1wbGljYXRpb25zIG9mIGRldmVsb3BpbmcgdHJhbnNwb3J0IHByb3RvY29scyB0aGF0DQogICB1 c2UgZW5kLXRvLWVuZCBlbmNyeXB0aW9uIHRvIHByb3ZpZGUgY29uZmlkZW50aWFsaXR5IG9mIHRo ZWlyDQogICB0cmFuc3BvcnQgbGF5ZXIgaGVhZGVycywgYW5kIGNvbnNpZGVycyB0aGUgZWZmZWN0 IG9mIHN1Y2ggY2hhbmdlcyBvbg0KICAgdHJhbnNwb3J0IHByb3RvY29sIGRlc2lnbiwgdHJhbnNw b3J0IHByb3RvY29sIGV2b2x1dGlvbiwgYW5kIG5ldHdvcmsNCiAgIG9wZXJhdGlvbnMuICBJdCBh bHNvIGNvbnNpZGVycyBzb21lIGFudGljaXBhdGVkIGltcGxpY2F0aW9ucyBvbg0KICAgYXBwbGlj YXRpb24gZXZvbHV0aW9uLiAgVGhpcyBwcm92aWRlcyBjb25zaWRlcmF0aW9ucyByZWxhdGluZyB0 byB0aGUNCiAgIGRlc2lnbiBvZiB0cmFuc3BvcnQgcHJvdG9jb2xzIGFuZCBmZWF0dXJlcyB3aGVy ZSB0aGUgdHJhbnNwb3J0DQogICBwcm90b2NvbCBlbmNyeXB0cyBzb21lIG9yIGFsbCBvZiB0aGVp ciBoZWFkZXIgaW5mb3JtYXRpb24uDQoNCkhvd2V2ZXIsIGFzIEkgc2FpZCBhYm92ZSwgdGhlIG5l dyB0cmFuc3BvcnQgcHJvdG9jb2xzIHRoYXQgYXJlDQphY3R1YWxseSBiZWluZyBkZXNpZ25lZCBh bHJlYWR5IGZlYXR1cmUgbWV0YWRhdGEgZW5jcnlwdGlvbiBhbmQgYXMgZmFyDQphcyBJIGNhbiB0 ZWxsLCB0aGVyZSBpcyBubyBwcm9zcGVjdGl2ZSBwcm90b2NvbCBuZXcgdHJhbnNwb3J0IHByb3Rv Y29sDQpkZXNpZ24gcHJvamVjdCBmb3Igd2hpY2ggdGhlc2UgaXNzdWVzIG1pZ2h0IGJlIGxpdmUu IEluIHRoYXQgY29udGV4dCwNCml0J3MgaGFyZCBub3QgdG8gcmVhZCB0aGlzIGRvY3VtZW50IHdp dGggaXRzIGxvbmcgbGl0YW55IG9mIHByYWN0aWNlcw0Kd2hpY2ggYXJlIGltcGFjdGVkIGJ5IG1l dGFkYXRhIGVuY3J5cHRpb24gYXMgYSBjcml0aXF1ZSBvZiB0aGUNCmRlY2lzaW9ucyBieSBTQ1RQ L0RUTFMgYW5kIFFVSUMgdG8gZW5jcnlwdCBtb3N0IG9mIHRoZSBtZXRhZGF0YS4NCg0KDQpUaGlz IGltcHJlc3Npb24gaXMgcmVpbmZvcmNlZCBieSB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIGFjdHVh bA0KcHJhY3RpY2VzIHRoZW1zZWx2ZXMsIHdoaWNoIGZvY3VzZXMgYWxtb3N0IGVudGlyZWx5IG9u IHByYWN0aWNlcw0Kd2hpY2ggYXBwZWFyIHRvIGJlIGJlbmlnbmx5IG1vdGl2YXRlZCAoZS5nLiwg cGVyZm9ybWFuY2UgbW9uaXRvcmluZywNCnRyb3VibGVzaG9vdGluZywgZXRjLikgSG93ZXZlciwg d2UgYWxzbyBrbm93IHRoYXQgbWV0YWRhdGEgaXMgd2lkZWx5DQp1c2VkIGZvciBwcmFjdGljZXMg aW4gd2hpY2ggdGhlIG5ldHdvcmsgb3BlcmF0b3IgaXMgYWR2ZXJzYXJpYWwNCnRvIHRoZSB1c2Vy LCBmb3IgaW5zdGFuY2U6DQoNCi0gQmxvY2tpbmcgdHJhZmZpYyBiYXNlZCBvbiBUQ1AgcG9ydCwg SVAgYWRkcmVzcywgU05JLCBldGMuDQoNCi0gUGVyZm9ybWFuY2UtYmFzZWQgdHJhZmZpYyBjbGFz cyBkaXNjcmltaW5hdGlvbg0KDQotIE1vbml0b3JpbmcgdGhlIHVzZXIncyBiZWhhdmlvciB2aWEg aW5kaWNpYSBsaWtlIHRoZSBvbmVzIGFib3ZlDQogIG9yIHZpYSB0cmFmZmljIGFuYWx5c2lzIChz ZWUgWzBdKQ0KDQpZZXMsIEkgdW5kZXJzdGFuZCB0aGF0IHRoZSBhdXRob3JzIGV4cGxpY2l0bHkg ZGlzY2xhaW0ganVkZ2VtZW50IG9uDQp0aGVzZSBwcmFjdGljZXMsIGFuZCB0aGUgZG9jdW1lbnQg ZG9lcyBicmllZmx5IHRvdWNoIG9uIHRoZSBnZW5lcmFsDQppZGVhLCB0aG91Z2ggdGhlICJjb25j ZXJucy4uLmhhdmUgYmVlbiB2b2ljZWQiIHRlbmRzIHRvIG1pbmltaXplIHRob3NlDQpjb25jZXJu cyBbMV0gYnV0IHRoZSBzZWxlY3Rpb24gb2YgcHJhY3RpY2VzIHRvIGZvY3VzIG9uIGlzIGV4dHJl bWVseQ0KdGVsbGluZy4gRm9jdXNpbmcgb24gdGhlIGRvd25zaWRlcyBvZiBlbmNyeXB0aW9uIGZv ciAoYXQgbGVhc3QNCmFyZ3VhYmx5IHdlbGwtbWVhbmluZykgbmV0d29yayBwbGF5ZXJzIHdoaWxl IG1vc3RseSBpZ25vcmluZyB0aGUgbGFyZ2UNCmNsYXNzIG9mIG5vbi1iZW5pZ24gYmVoYXZpb3Jz IHdoaWNoIGVuY3J5cHRpb24gaXMgaW50ZW5kZWQgdG8gcHJvdGVjdA0KYWdhaW5zdCBoYXMgdGhl IGVmZmVjdCBvZiBvdmVyZW1waGFzaXppbmcgdGhlIGNvc3RzIG9mIGVuY3J5cHRpb24gdG8NCnRo b3NlIHBsYXllcnMgYW5kIG1pbmltaXppbmcgdGhlIGJlbmVmaXRzIHRvIHRoZSBlbmRwb2ludHMg d2hvbSBpdCBpcw0KaW50ZW5kZWQgdG8gcHJvdGVjdC4NCg0KDQpUbyBiZSBtYXhpbWFsbHkgY2xl YXI6IEkgZG9uJ3Qgb2JqZWN0IHRvIHRoaXMgZG9jdW1lbnQgZXhpc3RpbmcNCmFuZCBJIGRvbid0 IHRoaW5rIHRoYXQgdGhlIG9waW5pb25zIGltcGxpY2l0IGluIGl0IGFyZSBvbmVzIHRoYXQNCnNo b3VsZCBub3QgYmUgZXhwcmVzc2VkLiBJIG1lcmVseSBkb24ndCB0aGluayB0aGF0IGl0IHNob3Vs ZCBiZQ0KcHVibGlzaGVkIGFzIGFuIElFVEYgQ29uc2Vuc3VzIGRvY3VtZW50Lg0KDQotRWtyDQoN ClswXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd29vZC1wZWFyZy13ZWJzaXRl LWZpbmdlcnByaW50aW5nLTAwI3NlY3Rpb24tNQ0KWzFdICAgIEFub3RoZXIgbW90aXZhdGlvbiBz dGVtcyBmcm9tIGluY3JlYXNlZCBjb25jZXJucyBhYm91dCBwcml2YWN5IGFuZA0KICAgICAgc3Vy dmVpbGxhbmNlLiAgVXNlcnMgdmFsdWUgdGhlIGFiaWxpdHkgdG8gcHJvdGVjdCB0aGVpciBpZGVu dGl0eQ0KICAgICAgYW5kIGxvY2F0aW9uLCBhbmQgZGVmZW5kIGFnYWluc3QgYW5hbHlzaXMgb2Yg dGhlIHRyYWZmaWMuDQogICAgICBSZXZlbGF0aW9ucyBhYm91dCB0aGUgdXNlIG9mIHBlcnZhc2l2 ZSBzdXJ2ZWlsbGFuY2UgW1JGQzc2MjRdDQogICAgICBoYXZlLCB0byBzb21lIGV4dGVudCwgZXJv ZGVkIHRydXN0IGluIHRoZSBzZXJ2aWNlIG9mZmVyZWQgYnkNCiAgICAgIG5ldHdvcmsgb3BlcmF0 b3JzIGFuZCBoYXZlIGxlZCB0byBhbiBpbmNyZWFzZWQgdXNlIG9mIGVuY3J5cHRpb24NCiAgICAg IHRvIGF2b2lkIHVud2FudGVkIGVhdmVzZHJvcHBpbmcgb24gY29tbXVuaWNhdGlvbnMuICBDb25j ZXJucyBoYXZlDQogICAgICBhbHNvIGJlZW4gdm9pY2VkIGFib3V0IHRoZSBhZGRpdGlvbiBvZiBp bmZvcm1hdGlvbiB0byBwYWNrZXRzIGJ5DQogICAgICB0aGlyZCBwYXJ0aWVzIHRvIHByb3ZpZGUg YW5hbHl0aWNzLCBjdXN0b21pc2F0aW9uLCBhZHZlcnRpc2luZywNCiAgICAgIGNyb3NzLXNpdGUg dHJhY2tpbmcgb2YgdXNlcnMsIHRvIGJpbGwgdGhlIGN1c3RvbWVyLCBvciB0bw0KICAgICAgc2Vs ZWN0aXZlbHkgYWxsb3cgb3IgYmxvY2sgY29udGVudC4gIFdoYXRldmVyIHRoZSByZWFzb25zLCB0 aGUNCiAgICAgIElFVEYgaXMgZGVzaWduaW5nIHByb3RvY29scyB0aGF0IGluY2x1ZGUgdHJhbnNw b3J0IGhlYWRlcg0KICAgICAgZW5jcnlwdGlvbiAoZS5nLiwgUVVJQyBbSS1ELmlldGYtcXVpYy10 cmFuc3BvcnRdKSB0byBzdXBwbGVtZW50DQogICAgICB0aGUgYWxyZWFkeSB3aWRlc3ByZWFkIHBh eWxvYWQgZW5jcnlwdGlvbiwgYW5kIHRvIGZ1cnRoZXIgbGltaXQNCiAgICAgIGV4cG9zdXJlIG9m IHRyYW5zcG9ydCBtZXRhZGF0YSB0byB0aGUgbmV0d29yay4NCg0KDQoNCg0KSU1QT1JUQU5UIE5P VElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUg Y29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwg dXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24g aW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0 IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29u ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0 cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIN Cg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVz c2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9y IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0K dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1 dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3Qg bGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBm YWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBv ZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5 IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xv c2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBv c2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5r IHlvdS4NCg== --_000_LEXPR01MB1040C937CACB87CB953E29869C6C0LEXPR01MB1040DEUP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg Vm9yZm9ybWF0aWVydCBaY2huIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5N c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJp Z2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MVm9yZm9ybWF0aWVydFpjaG4NCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgVm9yZm9ybWF0aWVydCBaY2huIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgVm9yZm9ybWF0aWVydCI7DQoJZm9udC1mYW1pbHk6 Q29uc29sYXM7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpwLkhUTUxQcmVmb3JtYXR0ZWQsIGxpLkhUTUxQcmVmb3JtYXR0ZWQsIGRpdi5I VE1MUHJlZm9ybWF0dGVkDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28t c3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6 Q29uc29sYXM7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdlMjINCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UyNA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo4Njc1Njg3MDE7DQoJbXNvLWxpc3QtdHlwZTpo eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMTM5NDA0ODIyIDY3Njk4NzExIDY3Njk4 NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEz IDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05 LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxp c3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlz dCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpy b21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90 dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgSGFubmVzLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5kbyBJIHVuZGVyc3RhbmQgeW91IGNvcnJlY3RseSB0aGF0IGV4cG9zaW5nIHRy YW5zcG9ydCBpbmZvcm1hdGlvbiB0byBjYWxjdWxhdGUgYSBmbG93IFJUVCBvciBhIGZsb3cgbG9z cyByYXRlIGJ5IGEgcGFzc2l2ZSBvYnNlcnZlciBhbG9uZyBhIHBhdGggaXMgYSBicmVhayBpbiBz ZWN1cml0eSB0byB5b3UgKCBzb3JyeSBpZiBJ4oCZbSBhc2tpbmcgc29tZXRoaW5nIHdoZXJlIHlv deKAmXZlIGV4cHJlc3NlZCB5b3VyIG9waW5pb24NCiBhbHJlYWR5IGVsc2V3aGVyZSwgSSBkaWRu 4oCZdCBmb2xsb3cgdGhlIHRyYW5zcG9ydCBleHBvc3VyZSB2cyBlbmNyeXB0aW9uIGRpc2N1c3Np b24pID88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCB0byB1bmRlcnN0YW5kIHdoZXRoZXIg dGhlcmUgaXMgYWJzb2x1dGVseSBubyBjb21tb24gZ3JvdW5kLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJERSI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJERSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiPlJ1ZWRpZ2VyPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iREUiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJERSI+Vm9uOjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iREUiPiB0c3Z3ZyAmbHQ7dHN2d2ctYm91bmNlc0BpZXRmLm9yZyZndDsN CjxiPkltIEF1ZnRyYWcgdm9uIDwvYj5IYW5uZXMgVHNjaG9mZW5pZzxicj4NCjxiPkdlc2VuZGV0 OjwvYj4gTWl0dHdvY2gsIDEuIEp1bGkgMjAyMCAxNToyMDxicj4NCjxiPkFuOjwvYj4gbW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgQmxhY2ssIERhdmlkICZsdDtEYXZpZC5CbGFja0BkZWxs LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IGludC1hcmVhICZsdDtpbnQtYXJlYUBpZXRmLm9yZyZn dDs7IHRzdndnQGlldGYub3JnOyBJRVRGIFNBQUcgJmx0O3NhYWdAaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+QmV0cmVmZjo8L2I+IFJlOiBbdHN2d2ddIFtzYWFnXSAzcmQgV0dMQyAobGltaXRlZC1zY29w ZSk6IGRyYWZ0LWlldGYtdHN2d2ctdHJhbnNwb3J0LWVuY3J5cHQtMTUsIGNsb3NlcyAyOSBKdW5l IDIwMjA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIG5v dGljZWQgdGhpcyBpbiB2YXJpb3VzIElFVEYgZGlzY3Vzc2lvbnMgYW5kIHNvIEkgd2lsbCBkZXNj cmliZSBpdCBpbiB0aGUgYWJzdHJhY3QuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBncm91 cCBvZiBwZW9wbGUgcHJvcG9zZSBhbiBpZGVhLiBUaG9zZSB3aG8gZG8gbm90IGxpa2UgdGhlIGlk ZWEgYXJlIHRoZW4gYXNrZWQgdG8gY29udmluY2UgdGhlIG9yaWdpbmFsIGNvbnRyaWJ1dG9ycyB0 aGF0IHRoZWlyIGlkZWEgaXMgbm90IHNvdW5kIG9yIGNvbnRyaWJ1dGUgdGV4dCBzbyBtYWtlIGl0 IGxvb2sgbmljZXIuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdCBv bmx5IGlzIHRoaXMgcmVxdWlyaW5nIG1lIHRvIHNwZW5kIG15IHRpbWUgb24gc29tZXRoaW5nIEkg ZG9u4oCZdCBhZ3JlZSB3aXRoIGJ1dCBpdCB0dXJucyBvdXQgdGhhdCBubyBkaXNjdXNzaW9ucyB3 aWxsIGNoYW5nZSB0aGUgbWluZCBvZiB0aGUgb3JpZ2luYWwgY29udHJpYnV0b3JzLiBUaGV5IGp1 c3Qgc3Ryb25nbHkgYmVsaWV2ZSBpbiB0aGVpciBpZGVhcy4gVGhleSB3aWxsIGtlZXAgcHJvcG9z aW5nIHRoZQ0KIHNhbWUgaWRlYSBvdmVyIGFuZCBvdmVyIGFnYWluIChmb3IgeWVhcnMpIHRpbGwg aXQgZ2V0cyBwdWJsaXNoZWQgYXMgYW4gUkZDLiA8bzpwPg0KPC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5D aWFvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IYW5uZXM8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206 PC9iPiA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4gJmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJv dWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsN Cjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bHkgMSwgMjAyMCAyOjU4IFBNPGJyPg0K PGI+VG86PC9iPiBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkhhbm5lcy5U c2Nob2ZlbmlnQGFybS5jb20iPkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208L2E+Jmd0OzsgQmxh Y2ssIERhdmlkICZsdDs8YSBocmVmPSJtYWlsdG86RGF2aWQuQmxhY2tAZGVsbC5jb20iPkRhdmlk LkJsYWNrQGRlbGwuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IGludC1hcmVhICZsdDs8YSBo cmVmPSJtYWlsdG86aW50LWFyZWFAaWV0Zi5vcmciPmludC1hcmVhQGlldGYub3JnPC9hPiZndDs7 IDxhIGhyZWY9Im1haWx0bzp0c3Z3Z0BpZXRmLm9yZyI+DQp0c3Z3Z0BpZXRmLm9yZzwvYT47IElF VEYgU0FBRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhYWdAaWV0Zi5vcmciPnNhYWdAaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3NhYWddIDNyZCBXR0xDIChsaW1pdGVk LXNjb3BlKTogZHJhZnQtaWV0Zi10c3Z3Zy10cmFuc3BvcnQtZW5jcnlwdC0xNSwgY2xvc2VzIDI5 IEp1bmUgMjAyMDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5I aSBIYW5uZXMsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+SXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY2FuIGV4cGxpY2l0IHRoZSDigJx3cm9uZyBt ZXNzYWdl4oCdIHlvdSBhcmUgcmVmZXJyaW5nIHRvLCBhbmQgcHJlZmVyYWJseSB3aXRoIHRleHQg ZnJvbSB0aGUgZHJhZnQgY29udmV5aW5nIHRoYXQgbWVzc2FnZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhhbmsgeW91Lg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkRl Jm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4gSW50LWFyZWEgWzxh IGhyZWY9Im1haWx0bzppbnQtYXJlYS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86aW50LWFyZWEt Ym91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBIYW5uZXMgVHNjaG9m ZW5pZzxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtYXJkaSAzMCBqdWluIDIwMjAgMDc6NTA8 YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IEVyaWMgUmVzY29ybGE7IEJsYWNrLCBEYXZpZDxicj4NCjxi PkNjJm5ic3A7OjwvYj4gaW50LWFyZWE7IDxhIGhyZWY9Im1haWx0bzp0c3Z3Z0BpZXRmLm9yZyI+ dHN2d2dAaWV0Zi5vcmc8L2E+OyBJRVRGIFNBQUc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJl OiBbSW50LWFyZWFdIFtzYWFnXSAzcmQgV0dMQyAobGltaXRlZC1zY29wZSk6IGRyYWZ0LWlldGYt dHN2d2ctdHJhbnNwb3J0LWVuY3J5cHQtMTUsIGNsb3NlcyAyOSBKdW5lIDIwMjA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGJlbGlldmUgdGhpcyBkb2N1 bWVudCBzaWduYWxzIGEgd3JvbmcgbWVzc2FnZSB0byB0aGUgd2lkZXIgSW50ZXJuZXQgY29tbXVu aXR5LiBJIGFncmVlIHRoYXQgaXQgc2hvdWxkIG5vdCBiZSBwdWJsaXNoZWQgYXMgYSBjb25zZW5z dXMgZG9jdW1lbnQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB1bmRlcnN0YW5kIHRoYXQg c29tZSBwZW9wbGUgYXJlIHVuaGFwcHkgYWJvdXQgZW5jcnlwdGluZyBtb3JlIG1ldGEtZGF0YS4g VGhpcyBwcmV2ZW50cyB0aGVtIGZyb20gZG9pbmcgdGhpbmdzIHRoZXkgdXNlZCB0byBkbyBpbiB0 aGUgcGFzdCwgc29tZSBvZiB3aGljaCB0aGV5IHNob3VsZCBoYXZlIG5ldmVyIGRvbmUgaW4gdGhl IGZpcnN0IHBsYWNlLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbXBy b3ZpbmcgdGhlIHByb3RlY3Rpb24gb2YgbWV0YS1kYXRhIGlzIGltcG9ydGFudCBhbmQgd2VsbCBz dXBwb3J0ZWQgYnkgYSBsYXJnZSBudW1iZXIgb2YgYWN0aXZpdGllcyBpbiB0aGUgSUVURiAodGhl IG5vdGFibGUgZXhjZXB0aW9uIGJlaW5nIENvQVAmIzQzO09TQ09SRSkuDQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Q2lhbzxicj4NCkhhbm5lczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPkZyb206PC9iPiBzYWFnICZsdDs8YSBocmVmPSJtYWlsdG86c2FhZy1ib3Vu Y2VzQGlldGYub3JnIj5zYWFnLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGI+T24gQmVoYWxm IE9mIDwvYj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bmUgMzAs IDIwMjAgMzowMCBBTTxicj4NCjxiPlRvOjwvYj4gQmxhY2ssIERhdmlkICZsdDs8YSBocmVmPSJt YWlsdG86RGF2aWQuQmxhY2tAZGVsbC5jb20iPkRhdmlkLkJsYWNrQGRlbGwuY29tPC9hPiZndDs8 YnI+DQo8Yj5DYzo8L2I+IGludC1hcmVhICZsdDs8YSBocmVmPSJtYWlsdG86aW50LWFyZWFAaWV0 Zi5vcmciPmludC1hcmVhQGlldGYub3JnPC9hPiZndDs7IDxhIGhyZWY9Im1haWx0bzp0c3Z3Z0Bp ZXRmLm9yZyI+DQp0c3Z3Z0BpZXRmLm9yZzwvYT47IElFVEYgU0FBRyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNhYWdAaWV0Zi5vcmciPnNhYWdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3NhYWddIDNyZCBXR0xDIChsaW1pdGVkLXNjb3BlKTogZHJhZnQtaWV0Zi10c3Z3 Zy10cmFuc3BvcnQtZW5jcnlwdC0xNSwgY2xvc2VzIDI5IEp1bmUgMjAyMDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZn dDsgPGJyPg0KJmd0OyBUaGlzIDNyZCBXR0xDIGlzIGxpbWl0ZWQgdG8gdGhlIGZvbGxvd2luZyB0 d28gdG9waWNzOjxicj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgV2hldGhlciBvciBub3QgdG8gcHJvY2VlZCB3aXRoIGEgcmVxdWVzdCBmb3IgUkZDIHB1 YmxpY2F0aW9uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IG9mIHRoZSBkcmFmdC4gJm5ic3A7IFRoZSBk ZWNpc2lvbiBvbiB3aGV0aGVyIG9yIG5vdCB0byBwcm9jZWVkIHdpbGw8YnI+DQomZ3Q7IGJlIGJh c2VkIG9uIHJvdWdoIGNvbnNlbnN1cyBvZiB0aGUgV0csIHNlZSBSRkMgNzI4Mi48YnI+DQomZ3Q7 IER1cmluZyB0aGUgMm5kIFdHTEMsIEVyaWMgUmVzY29ybGEgYW5kIERhdmlkIFNjaGluYXppIGV4 cHJlc3NlZDxicj4NCiZndDsgc3Ryb25nIHZpZXdzIHRoYXQgdGhpcyBkcmFmdCBzaG91bGQgbm90 IGJlIHB1Ymxpc2hlZCDigJMgJm5ic3A7dGhvc2U8YnI+DQomZ3Q7IGNvbmNlcm5zIGhhdmUgbm90 IGJlZW4gcmVzb2x2ZWQgYW5kIGFyZSBjYXJyaWVkIGZvcndhcmQgdG88YnI+DQomZ3Q7IHRoaXMg V0dMQy4mbmJzcDsgVGhpcyBlbWFpbCBtZXNzYWdlIHdhcyBhbiBhdHRlbXB0IHRvIHN1bW1hcml6 ZTxicj4NCiZndDsgdGhvc2UgY29uY2VybnM6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxhIGhyZWY9 Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdHN2d2cvaTRxeVkxSFJxS3dt MEptZTlVdEViNkR5aFhVLyI+DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNn L3RzdndnL2k0cXlZMUhScUt3bTBKbWU5VXRFYjZEeWhYVS88L2E+PGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEZ1cnRoZXIgZXhwbGFuYXRpb24gZnJvbSBib3RoIEVyaWMgUmVzY29ybGEgYW5kIERhdmlk IFNjaGluYXppPGJyPg0KJmd0OyBpcyB3ZWxjb21lIGFuZCBlbmNvdXJhZ2VkIHRvIGVuc3VyZSB0 aGF0IHRoZWlyIGNvbmNlcm5zIGFyZTxicj4NCiZndDsgY2xlYXJseSB1bmRlcnN0b29kLjxicj4N Cjxicj4NCldlbGwsIEknbGwgdHJ5IGFnYWluLCBidXQgSSdtIG5vdCBzdXJlIHRoYXQgSSBjYW4g ZG8gYmV0dGVyIHRoYW48YnI+DQpJIGhhdmUgYmVmb3JlLjxicj4NCjxicj4NCkZvciByZWFzb25z IHRoYXQgYXJlIGxhaWQgb3V0IGluIFJGQyA3MjU4LCB0aGUgdHJlbmQgaW4gcHJvdG9jb2w8YnI+ DQpkZXNpZ24gaW4gSUVURiBpcyB0b3dhcmRzIGVuY3J5cHRpbmcgbW9yZSBhbmQgbW9yZS4gVGhl IGxhc3QgdHdvPGJyPg0KdHJhbnNwb3J0IHByb3RvY29scyB0aGF0IHdlcmUgZGVzaWduZWQgYW5k IHdpZGVseSBkZXBsb3llZCAoU0NUUCBvdmVyPGJyPg0KRFRMUyBhbmQgUVVJQykgYm90aCBlbmNy eXB0IHRoZSB2YXN0IG1ham9yaXR5IG9mIHRoZSBwcm90b2NvbDxicj4NCm1ldGFkYXRhLiBUaGlz IGRvY3VtZW50IGFkdmVydGlzZXMgaXRzZWxmIGFzICZxdW90O2NvbnNpZGVyYXRpb25zJnF1b3Q7 PGJyPg0KZm9yIGRlc2lnbiBvZiBzdWNoIHByb3RvY29sczo8YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7VGhlIHRyYW5zcG9ydCBwcm90b2NvbHMgZGV2ZWxvcGVkIGZvciB0aGUgSW50ZXJuZXQgYXJl IHVzZWQgYWNyb3NzIGE8YnI+DQombmJzcDsgJm5ic3A7d2lkZSByYW5nZSBvZiBwYXRocyBhY3Jv c3MgbmV0d29yayBzZWdtZW50cyB3aXRoIG1hbnkgZGlmZmVyZW50PGJyPg0KJm5ic3A7ICZuYnNw O3JlZ3VsYXRvcnksIGNvbW1lcmNpYWwsIGFuZCBlbmdpbmVlcmluZyBjb25zaWRlcmF0aW9ucy4m bmJzcDsgVGhpczxicj4NCiZuYnNwOyAmbmJzcDtkb2N1bWVudCBjb25zaWRlcnMgc29tZSBvZiB0 aGUgY29zdHMgYW5kIGNoYW5nZXMgdG8gbmV0d29yazxicj4NCiZuYnNwOyAmbmJzcDttYW5hZ2Vt ZW50IGFuZCByZXNlYXJjaCB0aGF0IGFyZSBpbXBsaWVkIGJ5IHdpZGVzcHJlYWQgdXNlIG9mPGJy Pg0KJm5ic3A7ICZuYnNwO3RyYW5zcG9ydCBwcm90b2NvbHMgdGhhdCBlbmNyeXB0IHRoZWlyIHRy YW5zcG9ydCBoZWFkZXIgaW5mb3JtYXRpb24uPGJyPg0KJm5ic3A7ICZuYnNwO0l0IHJldmlld3Mg dGhlIGltcGxpY2F0aW9ucyBvZiBkZXZlbG9waW5nIHRyYW5zcG9ydCBwcm90b2NvbHMgdGhhdDxi cj4NCiZuYnNwOyAmbmJzcDt1c2UgZW5kLXRvLWVuZCBlbmNyeXB0aW9uIHRvIHByb3ZpZGUgY29u ZmlkZW50aWFsaXR5IG9mIHRoZWlyPGJyPg0KJm5ic3A7ICZuYnNwO3RyYW5zcG9ydCBsYXllciBo ZWFkZXJzLCBhbmQgY29uc2lkZXJzIHRoZSBlZmZlY3Qgb2Ygc3VjaCBjaGFuZ2VzIG9uPGJyPg0K Jm5ic3A7ICZuYnNwO3RyYW5zcG9ydCBwcm90b2NvbCBkZXNpZ24sIHRyYW5zcG9ydCBwcm90b2Nv bCBldm9sdXRpb24sIGFuZCBuZXR3b3JrPGJyPg0KJm5ic3A7ICZuYnNwO29wZXJhdGlvbnMuJm5i c3A7IEl0IGFsc28gY29uc2lkZXJzIHNvbWUgYW50aWNpcGF0ZWQgaW1wbGljYXRpb25zIG9uPGJy Pg0KJm5ic3A7ICZuYnNwO2FwcGxpY2F0aW9uIGV2b2x1dGlvbi4mbmJzcDsgVGhpcyBwcm92aWRl cyBjb25zaWRlcmF0aW9ucyByZWxhdGluZyB0byB0aGU8YnI+DQombmJzcDsgJm5ic3A7ZGVzaWdu IG9mIHRyYW5zcG9ydCBwcm90b2NvbHMgYW5kIGZlYXR1cmVzIHdoZXJlIHRoZSB0cmFuc3BvcnQ8 YnI+DQombmJzcDsgJm5ic3A7cHJvdG9jb2wgZW5jcnlwdHMgc29tZSBvciBhbGwgb2YgdGhlaXIg aGVhZGVyIGluZm9ybWF0aW9uLjxicj4NCjxicj4NCkhvd2V2ZXIsIGFzIEkgc2FpZCBhYm92ZSwg dGhlIG5ldyB0cmFuc3BvcnQgcHJvdG9jb2xzIHRoYXQgYXJlPGJyPg0KYWN0dWFsbHkgYmVpbmcg ZGVzaWduZWQgYWxyZWFkeSBmZWF0dXJlIG1ldGFkYXRhIGVuY3J5cHRpb24gYW5kIGFzIGZhcjxi cj4NCmFzIEkgY2FuIHRlbGwsIHRoZXJlIGlzIG5vIHByb3NwZWN0aXZlIHByb3RvY29sIG5ldyB0 cmFuc3BvcnQgcHJvdG9jb2w8YnI+DQpkZXNpZ24gcHJvamVjdCBmb3Igd2hpY2ggdGhlc2UgaXNz dWVzIG1pZ2h0IGJlIGxpdmUuIEluIHRoYXQgY29udGV4dCw8YnI+DQppdCdzIGhhcmQgbm90IHRv IHJlYWQgdGhpcyBkb2N1bWVudCB3aXRoIGl0cyBsb25nIGxpdGFueSBvZiBwcmFjdGljZXM8YnI+ DQp3aGljaCBhcmUgaW1wYWN0ZWQgYnkgbWV0YWRhdGEgZW5jcnlwdGlvbiBhcyBhIGNyaXRpcXVl IG9mIHRoZTxicj4NCmRlY2lzaW9ucyBieSBTQ1RQL0RUTFMgYW5kIFFVSUMgdG8gZW5jcnlwdCBt b3N0IG9mIHRoZSBtZXRhZGF0YS48YnI+DQo8YnI+DQo8YnI+DQpUaGlzIGltcHJlc3Npb24gaXMg cmVpbmZvcmNlZCBieSB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIGFjdHVhbDxicj4NCnByYWN0aWNl cyB0aGVtc2VsdmVzLCB3aGljaCBmb2N1c2VzIGFsbW9zdCBlbnRpcmVseSBvbiBwcmFjdGljZXM8 YnI+DQp3aGljaCBhcHBlYXIgdG8gYmUgYmVuaWdubHkgbW90aXZhdGVkIChlLmcuLCBwZXJmb3Jt YW5jZSBtb25pdG9yaW5nLDxicj4NCnRyb3VibGVzaG9vdGluZywgZXRjLikgSG93ZXZlciwgd2Ug YWxzbyBrbm93IHRoYXQgbWV0YWRhdGEgaXMgd2lkZWx5PGJyPg0KdXNlZCBmb3IgcHJhY3RpY2Vz IGluIHdoaWNoIHRoZSBuZXR3b3JrIG9wZXJhdG9yIGlzIGFkdmVyc2FyaWFsPGJyPg0KdG8gdGhl IHVzZXIsIGZvciBpbnN0YW5jZTo8YnI+DQo8YnI+DQotIEJsb2NraW5nIHRyYWZmaWMgYmFzZWQg b24gVENQIHBvcnQsIElQIGFkZHJlc3MsIFNOSSwgZXRjLjxicj4NCjxicj4NCi0gUGVyZm9ybWFu Y2UtYmFzZWQgdHJhZmZpYyBjbGFzcyBkaXNjcmltaW5hdGlvbjxicj4NCjxicj4NCi0gTW9uaXRv cmluZyB0aGUgdXNlcidzIGJlaGF2aW9yIHZpYSBpbmRpY2lhIGxpa2UgdGhlIG9uZXMgYWJvdmU8 YnI+DQombmJzcDsgb3IgdmlhIHRyYWZmaWMgYW5hbHlzaXMgKHNlZSBbMF0pPGJyPg0KPGJyPg0K WWVzLCBJIHVuZGVyc3RhbmQgdGhhdCB0aGUgYXV0aG9ycyBleHBsaWNpdGx5IGRpc2NsYWltIGp1 ZGdlbWVudCBvbjxicj4NCnRoZXNlIHByYWN0aWNlcywgYW5kIHRoZSBkb2N1bWVudCBkb2VzIGJy aWVmbHkgdG91Y2ggb24gdGhlIGdlbmVyYWw8YnI+DQppZGVhLCB0aG91Z2ggdGhlICZxdW90O2Nv bmNlcm5zLi4uaGF2ZSBiZWVuIHZvaWNlZCZxdW90OyB0ZW5kcyB0byBtaW5pbWl6ZSB0aG9zZTxi cj4NCmNvbmNlcm5zIFsxXSBidXQgdGhlIHNlbGVjdGlvbiBvZiBwcmFjdGljZXMgdG8gZm9jdXMg b24gaXMgZXh0cmVtZWx5PGJyPg0KdGVsbGluZy4gRm9jdXNpbmcgb24gdGhlIGRvd25zaWRlcyBv ZiBlbmNyeXB0aW9uIGZvciAoYXQgbGVhc3Q8YnI+DQphcmd1YWJseSB3ZWxsLW1lYW5pbmcpIG5l dHdvcmsgcGxheWVycyB3aGlsZSBtb3N0bHkgaWdub3JpbmcgdGhlIGxhcmdlPGJyPg0KY2xhc3Mg b2Ygbm9uLWJlbmlnbiBiZWhhdmlvcnMgd2hpY2ggZW5jcnlwdGlvbiBpcyBpbnRlbmRlZCB0byBw cm90ZWN0PGJyPg0KYWdhaW5zdCBoYXMgdGhlIGVmZmVjdCBvZiBvdmVyZW1waGFzaXppbmcgdGhl IGNvc3RzIG9mIGVuY3J5cHRpb24gdG88YnI+DQp0aG9zZSBwbGF5ZXJzIGFuZCBtaW5pbWl6aW5n IHRoZSBiZW5lZml0cyB0byB0aGUgZW5kcG9pbnRzIHdob20gaXQgaXM8YnI+DQppbnRlbmRlZCB0 byBwcm90ZWN0Ljxicj4NCjxicj4NCjxicj4NClRvIGJlIG1heGltYWxseSBjbGVhcjogSSBkb24n dCBvYmplY3QgdG8gdGhpcyBkb2N1bWVudCBleGlzdGluZzxicj4NCmFuZCBJIGRvbid0IHRoaW5r IHRoYXQgdGhlIG9waW5pb25zIGltcGxpY2l0IGluIGl0IGFyZSBvbmVzIHRoYXQ8YnI+DQpzaG91 bGQgbm90IGJlIGV4cHJlc3NlZC4gSSBtZXJlbHkgZG9uJ3QgdGhpbmsgdGhhdCBpdCBzaG91bGQg YmU8YnI+DQpwdWJsaXNoZWQgYXMgYW4gSUVURiBDb25zZW5zdXMgZG9jdW1lbnQuPGJyPg0KPGJy Pg0KLUVrcjxicj4NCjxicj4NClswXSA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtd29vZC1wZWFyZy13ZWJzaXRlLWZpbmdlcnByaW50aW5nLTAwI3NlY3Rpb24tNSI+ DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd29vZC1wZWFyZy13ZWJzaXRlLWZp bmdlcnByaW50aW5nLTAwI3NlY3Rpb24tNTwvYT48YnI+DQpbMV0gJm5ic3A7ICZuYnNwO0Fub3Ro ZXIgbW90aXZhdGlvbiBzdGVtcyBmcm9tIGluY3JlYXNlZCBjb25jZXJucyBhYm91dCBwcml2YWN5 IGFuZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHN1cnZlaWxsYW5jZS4mbmJzcDsgVXNlcnMg dmFsdWUgdGhlIGFiaWxpdHkgdG8gcHJvdGVjdCB0aGVpciBpZGVudGl0eTxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7IGFuZCBsb2NhdGlvbiwgYW5kIGRlZmVuZCBhZ2FpbnN0IGFuYWx5c2lzIG9m IHRoZSB0cmFmZmljLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IFJldmVsYXRpb25zIGFib3V0 IHRoZSB1c2Ugb2YgcGVydmFzaXZlIHN1cnZlaWxsYW5jZSBbUkZDNzYyNF08YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyBoYXZlLCB0byBzb21lIGV4dGVudCwgZXJvZGVkIHRydXN0IGluIHRoZSBz ZXJ2aWNlIG9mZmVyZWQgYnk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBuZXR3b3JrIG9wZXJh dG9ycyBhbmQgaGF2ZSBsZWQgdG8gYW4gaW5jcmVhc2VkIHVzZSBvZiBlbmNyeXB0aW9uPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdG8gYXZvaWQgdW53YW50ZWQgZWF2ZXNkcm9wcGluZyBvbiBj b21tdW5pY2F0aW9ucy4mbmJzcDsgQ29uY2VybnMgaGF2ZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7IGFsc28gYmVlbiB2b2ljZWQgYWJvdXQgdGhlIGFkZGl0aW9uIG9mIGluZm9ybWF0aW9uIHRv IHBhY2tldHMgYnk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyB0aGlyZCBwYXJ0aWVzIHRvIHBy b3ZpZGUgYW5hbHl0aWNzLCBjdXN0b21pc2F0aW9uLCBhZHZlcnRpc2luZyw8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyBjcm9zcy1zaXRlIHRyYWNraW5nIG9mIHVzZXJzLCB0byBiaWxsIHRoZSBj dXN0b21lciwgb3IgdG88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBzZWxlY3RpdmVseSBhbGxv dyBvciBibG9jayBjb250ZW50LiZuYnNwOyBXaGF0ZXZlciB0aGUgcmVhc29ucywgdGhlPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgSUVURiBpcyBkZXNpZ25pbmcgcHJvdG9jb2xzIHRoYXQgaW5j bHVkZSB0cmFuc3BvcnQgaGVhZGVyPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgZW5jcnlwdGlv biAoZS5nLiwgUVVJQyBbSS1ELmlldGYtcXVpYy10cmFuc3BvcnRdKSB0byBzdXBwbGVtZW50PGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlIGFscmVhZHkgd2lkZXNwcmVhZCBwYXlsb2FkIGVu Y3J5cHRpb24sIGFuZCB0byBmdXJ0aGVyIGxpbWl0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg ZXhwb3N1cmUgb2YgdHJhbnNwb3J0IG1ldGFkYXRhIHRvIHRoZSBuZXR3b3JrLjxicj4NCiZuYnNw OyA8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5JTVBPUlRBTlQgTk9USUNFOiBUaGUg Y29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRp YWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KIGltbWVkaWF0ZWx5IGFuZCBk byBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBm b3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBt ZWRpdW0uIFRoYW5rIHlvdS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHByZT5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg aW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu dCBkb25jPG86cD48L286cD48L3ByZT4NCjxwcmU+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRl cyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3Nh Z2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2lu dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl cmF0aW9uLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3Bv bnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmll LiBNZXJjaS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K PHByZT5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg bGF3OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGFuayB5b3UuPG86 cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklNUE9SVEFOVCBOT1RJQ0U6IFRo ZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVu dGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBk byBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sDQogdXNlIGl0 IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55 IG1lZGl1bS4gVGhhbmsgeW91Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_LEXPR01MB1040C937CACB87CB953E29869C6C0LEXPR01MB1040DEUP_-- From nobody Wed Jul 1 06:57:55 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90B13A0BA3 for ; Wed, 1 Jul 2020 06:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLFBPWGa4Zoe for ; Wed, 1 Jul 2020 06:57:40 -0700 (PDT) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 F005C3A0B8B for ; Wed, 1 Jul 2020 06:57:39 -0700 (PDT) Received: by mail-ua1-x932.google.com with SMTP id p6so690814uaq.12 for ; Wed, 01 Jul 2020 06:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d5sewHoVOc/a2tOp9qDeMoczKwl/q1FM8/0GEPwNCzA=; b=FjIpy42qrnTUwfwjrqswzd+eBOz1Qz7B1ClFJZmQjhN8XMGBAlOh1kZ1Of0SJaRLf0 LoFRAdeO5gGTGKi8Vefi1pCt7xYuD+j9TdjiJn+62k4r3ORkd78nz5mTBblK+IK69T/3 v+fDGuEH/c59MhL5brw/JM3sQBotFAFrB/bJQ= 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=d5sewHoVOc/a2tOp9qDeMoczKwl/q1FM8/0GEPwNCzA=; b=VZtNunKfNbd2FoW0V7F0L2hzSRIHdmkoW2zfUyjjQ/UP6CW333xD3D3f/5mWzO16TW zBAuKIRScOGaQ8j7fMoOoW1rb8KaHc4PcvB1I2xse2f2tOlSLQrxdh3hxWRJiR8okEg2 Wzt1QNEf4kMh3+pqMRNFXJRd+HxOuF6BIQVw2qNX+ARhvQWpKeowD1N2H6NcBPotE6CF 7e5hP0LpPhivSqHM4Kh96rJUbIrOKHFfkhrF6TL8yF10hm5nLiRrgMbe988tJvj6jcBv OBpqxudDdscdx4G/L/8gR5002xFeRDKmzzvxALirS6pNYKQxidd3sMByuHHH9uD/FmRJ iDrg== X-Gm-Message-State: AOAM5311JF+Sja+FfPzn0Eqej3MXvafwtp8SYgH99Jdm8GxviyxmYr5r CAWAg/mgQuYqYjN9GN/16Di8OcHqs2K7nvIuZ6ykvw== X-Google-Smtp-Source: ABdhPJysicxq5idDc9dpr2qRJFugvhELlC2eaja6zyqGcnNsqYhd/kMXtlIX0MXJ6Zsxjwm4NTQMjlLXnu7dwD+YtAU= X-Received: by 2002:ab0:65c7:: with SMTP id n7mr18874872uaq.30.1593611858816; Wed, 01 Jul 2020 06:57:38 -0700 (PDT) MIME-Version: 1.0 References: <21886_1593608278_5EFC8856_21886_470_1_787AE7BB302AE849A7480A190F8B9330314EBA5C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: From: Kyle Rose Date: Wed, 1 Jul 2020 09:57:27 -0400 Message-ID: To: Hannes Tschofenig Cc: "mohamed.boucadair@orange.com" , "Black, David" , int-area , "tsvwg@ietf.org" , IETF SAAG Content-Type: multipart/alternative; boundary="000000000000c1479605a961ac89" Archived-At: Subject: Re: [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 13:57:50 -0000 --000000000000c1479605a961ac89 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 1, 2020 at 9:20 AM Hannes Tschofenig wrote: > I noticed this in various IETF discussions and so I will describe it in > the abstract. > > > > A group of people propose an idea. Those who do not like the idea are the= n > asked to convince the original contributors that their idea is not sound = or > contribute text so make it look nicer. > > Not only is this requiring me to spend my time on something I don=E2=80= =99t agree > with but it turns out that no discussions will change the mind of the > original contributors. They just strongly believe in their ideas. They wi= ll > keep proposing the same idea over and over again (for years) till it gets > published as an RFC. > I don't understand why so many are opposed to publishing a document that merely describes how operators manage protocols in the absence of header encryption, and how header encryption interferes with those practices. That is, at least, in its original form, before this WG decided it needed to incorporate pro-encryption advocacy, greatly complicating the document and the resulting analysis. For the OG version, I ask myself the following questions: Does the document describe reality? Yes: it tells us what practices operators employ today. Is the document useful? Yes: see above, plus it makes clear that there will be an impact to operators and/or protocol users from this evolution. Does the document establish an IETF position on encryption? No. There are plenty of other published RFCs that embody the spirit "encrypt all the things". This document does not change that. Does the document make normative statements about future protocol development? No. On what basis would I therefore oppose publication? I may or may not have opinions about prioritization of user privacy over manageability, the tussle between manageability and deployability, and what alternatives are available to operators for managing protocols with encrypted headers. I would be happy to help express those in a follow-on document. But this document describing where those conflicts lie is a *prerequisite* to developing those alternatives. And frankly those opinions are irrelevant to the intended content of *this* document. Kyle --000000000000c1479605a961ac89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 1, 2020 at 9:20 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wro= te:

I noticed this in various IETF discussions and so I = will describe it in the abstract.

=C2=A0

A group of people propose an idea. Those who do not = like the idea are then asked to convince the original contributors that the= ir idea is not sound or contribute text so make it look nicer.

Not only is this requiring me to spend my time on so= mething I don=E2=80=99t agree with but it turns out that no discussions wil= l change the mind of the original contributors. They just strongly believe = in their ideas. They will keep proposing the same idea over and over again (for years) till it gets published as an RFC= .


I don't understand why so many are opposed to publi= shing a document that merely describes how operators manage protocols in th= e absence of header encryption, and how header encryption interferes with t= hose practices. That is, at least, in its original form, before this WG dec= ided it needed to incorporate pro-encryption advocacy, greatly complicating= the document and the resulting analysis.

For the OG version, I ask myself the following questions= :

Does the document describe reality? Yes= : it tells us what practices operators employ today.
Is the document useful? Yes= : see above, plus it makes clear that there will be an impact to operators = and/or protocol users from this evolution.
Does the document establish an IETF positio= n on encryption? No. There are plenty of other published RFCs that embody t= he spirit "encrypt all the things". This document does not change= that.
Does= the document make normative statements about future protocol development? = No.

<= div style=3D"font-size:small" class=3D"gmail_default">On what basis would I= therefore oppose publication?

I may or may not have opinions about prioritization= of user privacy over manageability, the tussle between manageability and d= eployability, and what alternatives are available to operators for managing= protocols with encrypted headers. I would be happy to help express those i= n a follow-on document. But this document describing where those conflicts = lie is a *prerequisite* to developing those alternatives. And frankly those= opinions are irrelevant to the intended content of *this* document.

Kyle
--000000000000c1479605a961ac89-- From nobody Wed Jul 1 07:11:37 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7B83A0B1B; Wed, 1 Jul 2020 07:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=telekom.de 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 ZDMrS0SsqQGi; Wed, 1 Jul 2020 07:11:22 -0700 (PDT) Received: from mailout31.telekom.de (mailout31.telekom.de [194.25.225.143]) (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 B0BD93A0849; Wed, 1 Jul 2020 07:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1593612681; x=1625148681; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kv8QEDhJIqfQwSZMVjbmU83WpKuGDrp2SA3dTIjS5+0=; b=0W6z8GXvKvWKZ8tAw1IWwNyRaVtxGy0wZ4SkoflEPNRix8z/AZcUohCm ncT/KGPgOHo6qPQVqO72toiDzbOLmJU/GhcuoAAnEkcL07gxG8lJ7iNru JOsfAt/HF6U7oAJsruO9RDDR/aFswiLZ2JNyj7PVJK44bv/a7OL3eenbO 7ZtQYfilcAB5mDKXPizypwUJKssrGy5h4Uew18cSonjoO7dtdpdbiKATX WTkZYF6Pz0uVh3YoLQzOeXWEX+PRXYQvoI+cLbqvH1XL33c/Lnjo/Giim sk1+OiJ4oVyguDHplEh/HhQGhBe4wkQ1E9pBDBFpQXVpxXfoYLcDK0Sqa A==; IronPort-SDR: O01xHtBJxJzXNqEWQLrmJ1fMegvNQlRZySeq0pKAhBTJ7nx5tv6Ko7OP7d5I9TC3vnuyRzqkKE JnF3rJGm6hcA== Received: from qde9xy.de.t-internal.com ([10.171.254.32]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2020 16:11:18 +0200 IronPort-SDR: dHcX60qnhCX4jdvkUUJtG02lVSTMQZrQ7zUl4nuRPG3tTE4O4UnsGgiOtp6/v9VWbslXMgJIY3 hAFbWVjs2o6M32nkCr+4B3sM2ToDs7qjw= X-IronPort-AV: E=Sophos;i="5.75,300,1589234400"; d="scan'208,217";a="131263765" X-MGA-submission: =?us-ascii?q?MDFU+dIAeBpnfVu5yyKKYZ2RelaOHPIW6X+sKc?= =?us-ascii?q?VT/Shbr8tarf0vNxuOSoLNw6F6HeEY8CwE2CARP+T0L8F3ka6PsJSh+R?= =?us-ascii?q?Hr+Ll2tOWUFtnqZWOd22sythsqinEEGCYXsUnae/7dzEkID2x2lAeKnR?= =?us-ascii?q?YvJbhH6p7Ixin8rFc5TtNNWw=3D=3D?= Received: from he105867.emea1.cds.t-internal.com ([10.169.119.44]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 01 Jul 2020 16:11:18 +0200 Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE105867.emea1.cds.t-internal.com (10.169.119.44) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 1 Jul 2020 16:11:18 +0200 Received: from HE104163.emea1.cds.t-internal.com (10.171.40.38) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 1 Jul 2020 16:11:17 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.17) by O365mail05.telekom.de (172.30.0.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 1 Jul 2020 16:11:17 +0200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kFOE07pwygyu/9DkJ/p+eg8SIDWczFJZ02Lf25SeR6OSnR2tjbw+4SMWrtkQqW6UmTJS5EIEoWAivF1tNHwDIeZHspqRrakJKcRvR1mAc6ypX34tcj9k2ioaLk41Iinc23IYdMrc9ybmfZrTMWsg4LnhbO9hktMH6s6OkIo1rc2QbGdUiw1dHsVYnK39hQxepx+l52pSR7ePfCJGxzEuvEpPIqcxol+jTj8g3Do1UwNOfR6SkoQuf+o9M7O5jirsnJWcsK++p6FpubiJwkRxD2svTqSxHgxcyh6+9Kr9adOnX+Y+o1cpgthPsG/3huvzDnaWVcaaNsvfHLhIDys3Og== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kv8QEDhJIqfQwSZMVjbmU83WpKuGDrp2SA3dTIjS5+0=; b=UW0Am1SoJPj3yWqkIGlI7y+61WKFbdOnZ7pzCgtGy02EXqJ77maj+HOog7898ugmcAfkyjvK01oFgdWGzYTW6R5MQDeM/avmEj3ImnTUFYYP733NffFoVUw4a9Sn1W45u2DaSfubq07FEGhAjEJFaEUjAljVL/RkZjV3+wIMfDjBnHqe8+89sIVmiLzfid1CFP8BEb49ADhMso5HqRIq9Y+dzwXPazJ2f3QrvzRlSbnRd8ad+IPa4cZr+ux4fv25cfCJoZSvPn/XmA8GFiG2PqxjmHp/QMQz5+tOwwiRw89x+3YwlTQw7JvFXPlOH+vJnA9BPaTjEyKSRiVd40j4Tg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none Received: from FRAPR01MB0401.DEUPRD01.PROD.OUTLOOK.DE (2a01:4180:c010:9::10) by FRAPR01MB0739.DEUPRD01.PROD.OUTLOOK.DE (2a01:4180:c010:a::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.25; Wed, 1 Jul 2020 14:11:16 +0000 Received: from FRAPR01MB0401.DEUPRD01.PROD.OUTLOOK.DE ([fe80::8943:6cde:8869:8ba6]) by FRAPR01MB0401.DEUPRD01.PROD.OUTLOOK.DE ([fe80::8943:6cde:8869:8ba6%6]) with mapi id 15.20.3131.030; Wed, 1 Jul 2020 14:11:16 +0000 From: To: , CC: , , Thread-Topic: [Int-area] [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 Thread-Index: AQHWTqJcCWNk2zpnpUqWBMHRx3E5oKjysTeAgAAGS4CAAApUgIAAA75A Date: Wed, 1 Jul 2020 14:11:16 +0000 Message-ID: References: <21886_1593608278_5EFC8856_21886_470_1_787AE7BB302AE849A7480A190F8B9330314EBA5C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: krose.org; dkim=none (message not signed) header.d=none;krose.org; dmarc=none action=none header.from=telekom.de; x-originating-ip: [212.201.104.11] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0010014c-ed37-4cb1-8ad6-08d81dc89eba x-ms-traffictypediagnostic: FRAPR01MB0739: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-forefront-prvs: 04519BA941 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: le6nFQBYltxje6upOufFfTanmXrrNUiARbzZPHX2QV0DTJTaUhx6VG3OtLuAWqGSjk05NneHlPlWHmOiJY3roIYFvquQY+RjzOIJe9DJm5ktNNal0vpmT9Kq1Hz5grLVweAUOPqkStYIVuXKcW9IDk0315MdcQo8f2VbUs8gU13D3/NU6ypjKNeos+grWcSHUJH14qcSbbUZaYGbEaPkxqakZC1aRIAe+RxPcPt1uNlvJ6l2T3RHEeKQmFCFEEeUqRPy5l8xarDfjMZv6bHuZ1zDyG6HszZBomCz14ScIHCzpCArhEUuz8SqFNJZ7/MG7loOMjZBKxsPX8ISwPjjhQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:FRAPR01MB0401.DEUPRD01.PROD.OUTLOOK.DE; PTR:; CAT:NONE; SFTY:; SFS:(39860400002)(136003)(376002)(396003)(346002)(366004)(8676002)(478600001)(33656002)(66476007)(8936002)(26005)(66946007)(76116006)(186003)(5660300002)(66556008)(2906002)(53546011)(64756008)(66446008)(4326008)(54906003)(7696005)(86362001)(316002)(9686003)(83380400001)(110136005)(55016002)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: yOvjCmUF2zT67oOSUWnjytiOdZ1iNAWDXqeOG23y6YzVSTaWR6ASR/h1dq3a73sxuJxFAoSErGmSdw96UtRZKmTSAYrF/MHSbZ4b3u5kWt0+GCOa1FqHQW+TYUun4lJK5eg5k0SCyffpNFj5EoTUoiSmtwhi9tgM4eKlTG7dfrrT00BlNigVAQf9L1JkizzOQZUNHjDZBPrmByeriwV9PrkUhdosV1qSpmPokBMvuW4MW457JupYahTf+1OuF3cV6O/tZz7RwcmKnx2UOCP1CbLzMHYEXRgQSiLxMdJq+A3/aNyYenzcjWCRkTKpGFUcxsqdKIfQPct2b4VQRTN8SnH17RY49cy75VaP80zfWPMGWu2JwuoEPP6Ig9LTnWYXtTf4CcQRN7I4vwp7HdJQ8RCfLKDLpKWpFZCTfGOq91+h2nGbwd1IqaY2sCry0jc0rl/XDlm6G4WyRJmQj0RVMJcX3S8y7ikZzEUVal79Ix339sGniM4HMAUAnPrn12eY x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_FRAPR01MB04015215AF32FC06B8A7184BD16C0FRAPR01MB0401DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: FRAPR01MB0401.DEUPRD01.PROD.OUTLOOK.DE X-MS-Exchange-CrossTenant-Network-Message-Id: 0010014c-ed37-4cb1-8ad6-08d81dc89eba X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2020 14:11:16.5825 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /U7lxMnVRB3KNb+Nir6GkykQOGfYwG0ClGaMv7cueuDNC/q1WVDYVhNNIeTX7JTcp/Vm3JzeOLUNx4S3F6DxvmmgaxSweNZu1D4tO4fMcjI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0739 X-TM-SNTS-SMTP: 2068C7AB359E9FF980974BC6DB10E57F39C42F94BD9A0F48DB6003257803A1B22000:8 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [saag] [Int-area] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 14:11:24 -0000 --_000_FRAPR01MB04015215AF32FC06B8A7184BD16C0FRAPR01MB0401DEUP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENClRoYW5rcywgS3lsZSENCktpbmQgcmVnYXJkcw0KRGlyaw0KDQpGcm9tOiBJbnQtYXJlYSA8 aW50LWFyZWEtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEt5bGUgUm9zZQ0KU2VudDog TWl0dHdvY2gsIDEuIEp1bGkgMjAyMCAxNTo1Nw0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5u ZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPg0KQ2M6IGludC1hcmVhIDxpbnQtYXJlYUBpZXRmLm9yZz47 IHRzdndnQGlldGYub3JnOyBJRVRGIFNBQUcgPHNhYWdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W0ludC1hcmVhXSBbc2FhZ10gM3JkIFdHTEMgKGxpbWl0ZWQtc2NvcGUpOiBkcmFmdC1pZXRmLXRz dndnLXRyYW5zcG9ydC1lbmNyeXB0LTE1LCBjbG9zZXMgMjkgSnVuZSAyMDIwDQoNCk9uIFdlZCwg SnVsIDEsIDIwMjAgYXQgOToyMCBBTSBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVu aWdAYXJtLmNvbTxtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4+IHdyb3RlOg0KSSBu b3RpY2VkIHRoaXMgaW4gdmFyaW91cyBJRVRGIGRpc2N1c3Npb25zIGFuZCBzbyBJIHdpbGwgZGVz Y3JpYmUgaXQgaW4gdGhlIGFic3RyYWN0Lg0KDQpBIGdyb3VwIG9mIHBlb3BsZSBwcm9wb3NlIGFu IGlkZWEuIFRob3NlIHdobyBkbyBub3QgbGlrZSB0aGUgaWRlYSBhcmUgdGhlbiBhc2tlZCB0byBj b252aW5jZSB0aGUgb3JpZ2luYWwgY29udHJpYnV0b3JzIHRoYXQgdGhlaXIgaWRlYSBpcyBub3Qg c291bmQgb3IgY29udHJpYnV0ZSB0ZXh0IHNvIG1ha2UgaXQgbG9vayBuaWNlci4NCk5vdCBvbmx5 IGlzIHRoaXMgcmVxdWlyaW5nIG1lIHRvIHNwZW5kIG15IHRpbWUgb24gc29tZXRoaW5nIEkgZG9u 4oCZdCBhZ3JlZSB3aXRoIGJ1dCBpdCB0dXJucyBvdXQgdGhhdCBubyBkaXNjdXNzaW9ucyB3aWxs IGNoYW5nZSB0aGUgbWluZCBvZiB0aGUgb3JpZ2luYWwgY29udHJpYnV0b3JzLiBUaGV5IGp1c3Qg c3Ryb25nbHkgYmVsaWV2ZSBpbiB0aGVpciBpZGVhcy4gVGhleSB3aWxsIGtlZXAgcHJvcG9zaW5n IHRoZSBzYW1lIGlkZWEgb3ZlciBhbmQgb3ZlciBhZ2FpbiAoZm9yIHllYXJzKSB0aWxsIGl0IGdl dHMgcHVibGlzaGVkIGFzIGFuIFJGQy4uDQoNCkkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgc28gbWFu eSBhcmUgb3Bwb3NlZCB0byBwdWJsaXNoaW5nIGEgZG9jdW1lbnQgdGhhdCBtZXJlbHkgZGVzY3Jp YmVzIGhvdyBvcGVyYXRvcnMgbWFuYWdlIHByb3RvY29scyBpbiB0aGUgYWJzZW5jZSBvZiBoZWFk ZXIgZW5jcnlwdGlvbiwgYW5kIGhvdyBoZWFkZXIgZW5jcnlwdGlvbiBpbnRlcmZlcmVzIHdpdGgg dGhvc2UgcHJhY3RpY2VzLiBUaGF0IGlzLCBhdCBsZWFzdCwgaW4gaXRzIG9yaWdpbmFsIGZvcm0s IGJlZm9yZSB0aGlzIFdHIGRlY2lkZWQgaXQgbmVlZGVkIHRvIGluY29ycG9yYXRlIHByby1lbmNy eXB0aW9uIGFkdm9jYWN5LCBncmVhdGx5IGNvbXBsaWNhdGluZyB0aGUgZG9jdW1lbnQgYW5kIHRo ZSByZXN1bHRpbmcgYW5hbHlzaXMuDQoNCkZvciB0aGUgT0cgdmVyc2lvbiwgSSBhc2sgbXlzZWxm IHRoZSBmb2xsb3dpbmcgcXVlc3Rpb25zOg0KDQpEb2VzIHRoZSBkb2N1bWVudCBkZXNjcmliZSBy ZWFsaXR5PyBZZXM6IGl0IHRlbGxzIHVzIHdoYXQgcHJhY3RpY2VzIG9wZXJhdG9ycyBlbXBsb3kg dG9kYXkuDQpJcyB0aGUgZG9jdW1lbnQgdXNlZnVsPyBZZXM6IHNlZSBhYm92ZSwgcGx1cyBpdCBt YWtlcyBjbGVhciB0aGF0IHRoZXJlIHdpbGwgYmUgYW4gaW1wYWN0IHRvIG9wZXJhdG9ycyBhbmQv b3IgcHJvdG9jb2wgdXNlcnMgZnJvbSB0aGlzIGV2b2x1dGlvbi4NCkRvZXMgdGhlIGRvY3VtZW50 IGVzdGFibGlzaCBhbiBJRVRGIHBvc2l0aW9uIG9uIGVuY3J5cHRpb24/IE5vLiBUaGVyZSBhcmUg cGxlbnR5IG9mIG90aGVyIHB1Ymxpc2hlZCBSRkNzIHRoYXQgZW1ib2R5IHRoZSBzcGlyaXQgImVu Y3J5cHQgYWxsIHRoZSB0aGluZ3MiLiBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGNoYW5nZSB0aGF0 Lg0KRG9lcyB0aGUgZG9jdW1lbnQgbWFrZSBub3JtYXRpdmUgc3RhdGVtZW50cyBhYm91dCBmdXR1 cmUgcHJvdG9jb2wgZGV2ZWxvcG1lbnQ/IE5vLg0KDQpPbiB3aGF0IGJhc2lzIHdvdWxkIEkgdGhl cmVmb3JlIG9wcG9zZSBwdWJsaWNhdGlvbj8NCg0KSSBtYXkgb3IgbWF5IG5vdCBoYXZlIG9waW5p b25zIGFib3V0IHByaW9yaXRpemF0aW9uIG9mIHVzZXIgcHJpdmFjeSBvdmVyIG1hbmFnZWFiaWxp dHksIHRoZSB0dXNzbGUgYmV0d2VlbiBtYW5hZ2VhYmlsaXR5IGFuZCBkZXBsb3lhYmlsaXR5LCBh bmQgd2hhdCBhbHRlcm5hdGl2ZXMgYXJlIGF2YWlsYWJsZSB0byBvcGVyYXRvcnMgZm9yIG1hbmFn aW5nIHByb3RvY29scyB3aXRoIGVuY3J5cHRlZCBoZWFkZXJzLiBJIHdvdWxkIGJlIGhhcHB5IHRv IGhlbHAgZXhwcmVzcyB0aG9zZSBpbiBhIGZvbGxvdy1vbiBkb2N1bWVudC4gQnV0IHRoaXMgZG9j dW1lbnQgZGVzY3JpYmluZyB3aGVyZSB0aG9zZSBjb25mbGljdHMgbGllIGlzIGEgKnByZXJlcXVp c2l0ZSogdG8gZGV2ZWxvcGluZyB0aG9zZSBhbHRlcm5hdGl2ZXMuIEFuZCBmcmFua2x5IHRob3Nl IG9waW5pb25zIGFyZSBpcnJlbGV2YW50IHRvIHRoZSBpbnRlbmRlZCBjb250ZW50IG9mICp0aGlz KiBkb2N1bWVudC4NCg0KS3lsZQ0K --_000_FRAPR01MB04015215AF32FC06B8A7184BD16C0FRAPR01MB0401DEUP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkRFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+JiM0MzsxPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcywgS3lsZSE8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNEU3OSI+S2luZCByZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjRFNzkiPkRpcms8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBJbnQtYXJl YSAmbHQ7aW50LWFyZWEtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+ S3lsZSBSb3NlPGJyPg0KPGI+U2VudDo8L2I+IE1pdHR3b2NoLCAxLiBKdWxpIDIwMjAgMTU6NTc8 YnI+DQo8Yj5Ubzo8L2I+IEhhbm5lcyBUc2Nob2ZlbmlnICZsdDtIYW5uZXMuVHNjaG9mZW5pZ0Bh cm0uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gaW50LWFyZWEgJmx0O2ludC1hcmVhQGlldGYub3Jn Jmd0OzsgdHN2d2dAaWV0Zi5vcmc7IElFVEYgU0FBRyAmbHQ7c2FhZ0BpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJbnQtYXJlYV0gW3NhYWddIDNyZCBXR0xDIChsaW1pdGVk LXNjb3BlKTogZHJhZnQtaWV0Zi10c3Z3Zy10cmFuc3BvcnQtZW5jcnlwdC0xNSwgY2xvc2VzIDI5 IEp1bmUgMjAyMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gV2VkLCBKdWwgMSwgMjAyMCBhdCA5OjIwIEFNIEhhbm5lcyBUc2Nob2ZlbmlnICZs dDs8YSBocmVmPSJtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbSI+SGFubmVzLlRzY2hv ZmVuaWdAYXJtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JIG5vdGljZWQgdGhpcyBpbiB2YXJpb3VzIElFVEYgZGlz Y3Vzc2lvbnMgYW5kIHNvIEkgd2lsbCBkZXNjcmliZSBpdCBpbiB0aGUgYWJzdHJhY3QuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIj5BIGdyb3VwIG9mIHBlb3BsZSBwcm9wb3NlIGFuIGlkZWEuIFRo b3NlIHdobyBkbyBub3QgbGlrZSB0aGUgaWRlYSBhcmUgdGhlbiBhc2tlZCB0byBjb252aW5jZSB0 aGUgb3JpZ2luYWwgY29udHJpYnV0b3JzIHRoYXQgdGhlaXIgaWRlYSBpcyBub3Qgc291bmQgb3Ig Y29udHJpYnV0ZQ0KIHRleHQgc28gbWFrZSBpdCBsb29rIG5pY2VyLiA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5Ob3Qgb25s eSBpcyB0aGlzIHJlcXVpcmluZyBtZSB0byBzcGVuZCBteSB0aW1lIG9uIHNvbWV0aGluZyBJIGRv buKAmXQgYWdyZWUgd2l0aCBidXQgaXQgdHVybnMgb3V0IHRoYXQgbm8gZGlzY3Vzc2lvbnMgd2ls bCBjaGFuZ2UgdGhlIG1pbmQgb2YgdGhlIG9yaWdpbmFsIGNvbnRyaWJ1dG9ycy4NCiBUaGV5IGp1 c3Qgc3Ryb25nbHkgYmVsaWV2ZSBpbiB0aGVpciBpZGVhcy4gVGhleSB3aWxsIGtlZXAgcHJvcG9z aW5nIHRoZSBzYW1lIGlkZWEgb3ZlciBhbmQgb3ZlciBhZ2FpbiAoZm9yIHllYXJzKSB0aWxsIGl0 IGdldHMgcHVibGlzaGVkIGFzIGFuIFJGQy4uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBkb24ndCB1bmRlcnN0YW5kIHdoeSBzbyBtYW55IGFyZSBvcHBvc2VkIHRvIHB1Ymxpc2hpbmcg YSBkb2N1bWVudCB0aGF0IG1lcmVseSBkZXNjcmliZXMgaG93IG9wZXJhdG9ycyBtYW5hZ2UgcHJv dG9jb2xzIGluIHRoZSBhYnNlbmNlIG9mIGhlYWRlciBlbmNyeXB0aW9uLCBhbmQgaG93IGhlYWRl ciBlbmNyeXB0aW9uIGludGVyZmVyZXMgd2l0aCB0aG9zZSBwcmFjdGljZXMuIFRoYXQgaXMsIGF0 IGxlYXN0LA0KIGluIGl0cyBvcmlnaW5hbCBmb3JtLCBiZWZvcmUgdGhpcyBXRyBkZWNpZGVkIGl0 IG5lZWRlZCB0byBpbmNvcnBvcmF0ZSBwcm8tZW5jcnlwdGlvbiBhZHZvY2FjeSwgZ3JlYXRseSBj b21wbGljYXRpbmcgdGhlIGRvY3VtZW50IGFuZCB0aGUgcmVzdWx0aW5nIGFuYWx5c2lzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgdGhl IE9HIHZlcnNpb24sIEkgYXNrIG15c2VsZiB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uczo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRv ZXMgdGhlIGRvY3VtZW50IGRlc2NyaWJlIHJlYWxpdHk/IFllczogaXQgdGVsbHMgdXMgd2hhdCBw cmFjdGljZXMgb3BlcmF0b3JzIGVtcGxveSB0b2RheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgdGhlIGRvY3VtZW50IHVzZWZ1 bD8gWWVzOiBzZWUgYWJvdmUsIHBsdXMgaXQgbWFrZXMgY2xlYXIgdGhhdCB0aGVyZSB3aWxsIGJl IGFuIGltcGFjdCB0byBvcGVyYXRvcnMgYW5kL29yIHByb3RvY29sIHVzZXJzIGZyb20gdGhpcyBl dm9sdXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Eb2VzIHRoZSBkb2N1bWVudCBlc3RhYmxpc2ggYW4gSUVURiBwb3NpdGlvbiBvbiBlbmNy eXB0aW9uPyBOby4gVGhlcmUgYXJlIHBsZW50eSBvZiBvdGhlciBwdWJsaXNoZWQgUkZDcyB0aGF0 IGVtYm9keSB0aGUgc3Bpcml0ICZxdW90O2VuY3J5cHQgYWxsIHRoZSB0aGluZ3MmcXVvdDsuIFRo aXMgZG9jdW1lbnQgZG9lcyBub3QgY2hhbmdlIHRoYXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb2VzIHRoZSBkb2N1bWVudCBtYWtlIG5vcm1h dGl2ZSBzdGF0ZW1lbnRzIGFib3V0IGZ1dHVyZSBwcm90b2NvbCBkZXZlbG9wbWVudD8gTm8uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIHdo YXQgYmFzaXMgd291bGQgSSB0aGVyZWZvcmUgb3Bwb3NlIHB1YmxpY2F0aW9uPzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIG1heSBvciBtYXkgbm90IGhhdmUgb3Bpbmlv bnMgYWJvdXQgcHJpb3JpdGl6YXRpb24gb2YgdXNlciBwcml2YWN5IG92ZXIgbWFuYWdlYWJpbGl0 eSwgdGhlIHR1c3NsZSBiZXR3ZWVuIG1hbmFnZWFiaWxpdHkgYW5kIGRlcGxveWFiaWxpdHksIGFu ZCB3aGF0IGFsdGVybmF0aXZlcyBhcmUgYXZhaWxhYmxlIHRvIG9wZXJhdG9ycyBmb3IgbWFuYWdp bmcgcHJvdG9jb2xzIHdpdGggZW5jcnlwdGVkIGhlYWRlcnMuDQogSSB3b3VsZCBiZSBoYXBweSB0 byBoZWxwIGV4cHJlc3MgdGhvc2UgaW4gYSBmb2xsb3ctb24gZG9jdW1lbnQuIEJ1dCB0aGlzIGRv Y3VtZW50IGRlc2NyaWJpbmcgd2hlcmUgdGhvc2UgY29uZmxpY3RzIGxpZSBpcyBhICpwcmVyZXF1 aXNpdGUqIHRvIGRldmVsb3BpbmcgdGhvc2UgYWx0ZXJuYXRpdmVzLiBBbmQgZnJhbmtseSB0aG9z ZSBvcGluaW9ucyBhcmUgaXJyZWxldmFudCB0byB0aGUgaW50ZW5kZWQgY29udGVudCBvZiAqdGhp cyogZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkt5bGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_FRAPR01MB04015215AF32FC06B8A7184BD16C0FRAPR01MB0401DEUP_-- From nobody Wed Jul 1 08:10:31 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9153A0FC0; Wed, 1 Jul 2020 08:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 Rvj5Tu7ISY4x; Wed, 1 Jul 2020 08:10:26 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 7B1743A0F70; Wed, 1 Jul 2020 08:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding: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=Z2b1oJfMZWhqgpJOAvbJBlITwqpk0odidCMacY9No7w=; b=lM9D8tUghIcJXvx3qSPwNYMHc Nh9llgtNc6TSY2L1xSg91AOQuGqrBJYokzt88L7Cusv80/S5D1yj9i9N7Wy4jcOpxIeHa36sx6iui e2/fmRQgzdSIUGJn6OhkOCuE9B0VvPF8DOk9G/a+UW5/ibqBV3HbFl3qVb9fKCBHeBGMBhV5Z3NsE tEa656DDJ2l2pyJ7Xkd4S6/h2PDtqRqZ4IGXsVnK386nAJ4b795Qg00BKJQwq+wOUUnY+1zcb7rYB 3pRkTOotO8sYUgantflHnEeuYYT4KM5L1osZ9BynecppNne8J6a0e6v42Aii9Jv7PpyHiNb6Rti1+ CkY1F3wnw==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:63836 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jqeNK-000Vug-8H; Wed, 01 Jul 2020 11:10:19 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_4FA01920-6117-43F8-A62F-5ACC54665501" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Joseph Touch In-Reply-To: Date: Wed, 1 Jul 2020 08:10:13 -0700 Cc: krose@krose.org, Hannes.Tschofenig@arm.com, int-area@ietf.org, tsvwg@ietf.org, saag@ietf.org Message-Id: References: <21886_1593608278_5EFC8856_21886_470_1_787AE7BB302AE849A7480A190F8B9330314EBA5C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: Dirk.von-Hugo@telekom.de X-Mailer: Apple Mail (2.3608.80.23.2.2) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [saag] [Int-area] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 15:10:30 -0000 --Apple-Mail=_4FA01920-6117-43F8-A62F-5ACC54665501 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 -1 Although it=E2=80=99s understandable to describe =E2=80=9Cwhat operators = do=E2=80=9D, the IETF isn=E2=80=99t a news service. We typically = summarize these behaviors to take a position on them. The draft provides a good description of the tradeoff between the = privacy rights of endpoints and the rights of operators and the impact = of both on protocol design on that tradeoff. What I seem to be seeing is increasing =E2=80=9Crough consensus=E2=80=9D = that the summary position should be closer to endpoint privacy than in = the current form. Although I don=E2=80=99t feel strongly that the text absolutely needs = revision in that direction, I would oppose changes to relax or shift in = the other direct. Joe > On Jul 1, 2020, at 7:11 AM, Dirk.von-Hugo@telekom.de wrote: >=20 > +1 > Thanks, Kyle! > Kind regards > Dirk > =20 > From: Int-area > On Behalf Of Kyle Rose > Sent: Mittwoch, 1. Juli 2020 15:57 > To: Hannes Tschofenig > > Cc: int-area >; = tsvwg@ietf.org ; IETF SAAG > > Subject: Re: [Int-area] [saag] 3rd WGLC (limited-scope): = draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 > =20 > On Wed, Jul 1, 2020 at 9:20 AM Hannes Tschofenig = > wrote: > I noticed this in various IETF discussions and so I will describe it = in the abstract. > =20 > A group of people propose an idea. Those who do not like the idea are = then asked to convince the original contributors that their idea is not = sound or contribute text so make it look nicer.=20 > Not only is this requiring me to spend my time on something I don=E2=80=99= t agree with but it turns out that no discussions will change the mind = of the original contributors. They just strongly believe in their ideas. = They will keep proposing the same idea over and over again (for years) = till it gets published as an RFC.. > =20 > I don't understand why so many are opposed to publishing a document = that merely describes how operators manage protocols in the absence of = header encryption, and how header encryption interferes with those = practices. That is, at least, in its original form, before this WG = decided it needed to incorporate pro-encryption advocacy, greatly = complicating the document and the resulting analysis. > =20 > For the OG version, I ask myself the following questions: > =20 > Does the document describe reality? Yes: it tells us what practices = operators employ today. > Is the document useful? Yes: see above, plus it makes clear that there = will be an impact to operators and/or protocol users from this = evolution. > Does the document establish an IETF position on encryption? No. There = are plenty of other published RFCs that embody the spirit "encrypt all = the things". This document does not change that. > Does the document make normative statements about future protocol = development? No. > =20 > On what basis would I therefore oppose publication? > =20 > I may or may not have opinions about prioritization of user privacy = over manageability, the tussle between manageability and deployability, = and what alternatives are available to operators for managing protocols = with encrypted headers. I would be happy to help express those in a = follow-on document. But this document describing where those conflicts = lie is a *prerequisite* to developing those alternatives. And frankly = those opinions are irrelevant to the intended content of *this* = document. > =20 > Kyle > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area = --Apple-Mail=_4FA01920-6117-43F8-A62F-5ACC54665501 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 -1

Although= it=E2=80=99s understandable to describe =E2=80=9Cwhat operators do=E2=80=9D= , the IETF isn=E2=80=99t a news service. We typically summarize these = behaviors to take a position on them.

The draft provides a good description = of the tradeoff between the privacy rights of endpoints and the rights = of operators and the impact of both on protocol design on that = tradeoff.

What = I seem to be seeing is increasing =E2=80=9Crough consensus=E2=80=9D that = the summary position should be closer to endpoint privacy than in the = current form.

Although I don=E2=80=99t feel strongly that the text = absolutely needs revision in that direction, I would oppose changes to = relax or shift in the other direct.

Joe

On Jul = 1, 2020, at 7:11 AM, Dirk.von-Hugo@telekom.de wrote:

+1
Thanks, Kyle!
Kind regards
Dirk
 
From: Int-area <int-area-bounces@ietf.org> On Behalf = Of Kyle Rose
Sent: Mittwoch, 1. Juli 2020 = 15:57
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: int-area <int-area@ietf.org>; tsvwg@ietf.org; IETF SAAG <saag@ietf.org>
Subject: Re: [Int-area] [saag] 3rd = WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 = June 2020
 
On Wed, Jul 1, 2020 at 9:20 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> = wrote:
I noticed this in various IETF discussions and = so I will describe it in the abstract.
 
A group of people propose an = idea. Those who do not like the idea are then asked to convince the = original contributors that their idea is not sound or contribute text so = make it look nicer. 
Not only is this requiring me = to spend my time on something I don=E2=80=99t agree with but it turns = out that no discussions will change the mind of the original = contributors. They just strongly believe in their ideas. They will keep = proposing the same idea over and over again (for years) till it gets = published as an RFC..
 
I don't understand why so many are = opposed to publishing a document that merely describes how operators = manage protocols in the absence of header encryption, and how header = encryption interferes with those practices. That is, at least, in its = original form, before this WG decided it needed to incorporate = pro-encryption advocacy, greatly complicating the document and the = resulting analysis.
 
For the OG version, I ask myself the = following questions:
 
Does the document describe reality? Yes: = it tells us what practices operators employ today.
Is the document useful? Yes: see above, = plus it makes clear that there will be an impact to operators and/or = protocol users from this evolution.
Does the = document establish an IETF position on encryption? No. There are plenty = of other published RFCs that embody the spirit "encrypt all the things". = This document does not change that.
Does the = document make normative statements about future protocol development? = No.
 
On what basis would I therefore oppose = publication?
 
I may or may not have = opinions about prioritization of user privacy over manageability, the = tussle between manageability and deployability, and what alternatives = are available to operators for managing protocols with encrypted = headers. I would be happy to help express those in a follow-on document. = But this document describing where those conflicts lie is a = *prerequisite* to developing those alternatives. And frankly those = opinions are irrelevant to the intended content of *this* document.
 
Kyle
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

= --Apple-Mail=_4FA01920-6117-43F8-A62F-5ACC54665501-- From nobody Wed Jul 1 13:33:31 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288753A0D41; Wed, 1 Jul 2020 13:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 bhpxuGgxvDqB; Wed, 1 Jul 2020 13:33:27 -0700 (PDT) Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (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 976C23A0D3F; Wed, 1 Jul 2020 13:33:27 -0700 (PDT) Received: by mail-yb1-xb33.google.com with SMTP id e197so8592538yba.5; Wed, 01 Jul 2020 13:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=FzkA0YeePX3Sc0YD/6msNCy577TqplZnpWOJfvjYMMI=; b=M3qefjN7MuLs+0txrjDlw71iskx7sumy+BQQ/KelPykSMWr8GN58ALC3Es77TqrFIw vSnt2V52u/hyp/sB6S7MVsM44eh9IrNszGkpKGQ549kstEpOIj9y51ZiadHeiy9XE/Ob HgDRxVFRh0XMCkXrxaqpf2s+z55QihdIj8YsUvk+1rDhtHNpSqTL8/OHTkunlfA4DB9c vVx8wKx4VQ1lFDyQD9XG9I66P1U5rK82uHKORnD/gZJ9sMitTDMbsXi6pM9xdv9uGAVZ EHFE70K8ZCfBsk6iimK8tGI9zf7yETAenzsQR2/SOaJNO40wcdhjpbgeYKWmXixK0urp w0ig== 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:reply-to :from:date:message-id:subject:to:cc; bh=FzkA0YeePX3Sc0YD/6msNCy577TqplZnpWOJfvjYMMI=; b=WyErZgOqLjD0+WT0wjXWGFfLLteY1A+++gs73GfqUf+Ino4Q4GVVDKp6XTJ7MT28nW WuI4OmkzChVt5e8x799oF+A1VxL4cp48r0RYFXNxHaoWPCqO1c8Nj5+yVTeSU+zV0/XF FK2pfUODjXsGi+rPPEyKrS1T9GGVyr9MhQLaJtK+6/J9C1RyFzPbG9DVkkE96DVrt+5L dSYXkLZqr1shUg6Qe4/X1T8Ap0NHwC0ndwsXSDZ6YL9Sbe043N0b8sFbrYQugXfSGIsf 7N1xhke4y8Vy8f34l8Q21CfjWCmoULP+YGrvjveJztNNflsObNedUBO+rcHQHb70pPqF fYtQ== X-Gm-Message-State: AOAM531RVU2CQQAHAK0GY9Nfi1HDS/yNVzbAC2D02E15VNUhS2ZhCM+K b6XUsWeiE7jF/egn87mkiDysAEFBwiSgN8gYAq8= X-Google-Smtp-Source: ABdhPJz4aNTcWofgb0WmJyO/2Ue2xDjlRYjFbrzoH2JKAU6USpuuHw146YgtmazEwtrnwTv/Vv/+i/OhfXuIwr3Ns78= X-Received: by 2002:a25:3bca:: with SMTP id i193mr42390533yba.327.1593635606769; Wed, 01 Jul 2020 13:33:26 -0700 (PDT) MIME-Version: 1.0 References: <21886_1593608278_5EFC8856_21886_470_1_787AE7BB302AE849A7480A190F8B9330314EBA5C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Wed, 1 Jul 2020 15:33:15 -0500 Message-ID: To: Joseph Touch Cc: "" , Internet Area , tsvwg@ietf.org, saag@ietf.org Content-Type: multipart/alternative; boundary="0000000000003e36a805a9673480" Archived-At: Subject: Re: [saag] [Int-area] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 20:33:30 -0000 --0000000000003e36a805a9673480 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 I think it is a good draft, out of very hard work, a lot of sweat. Behcet On Wed, Jul 1, 2020 at 10:10 AM Joseph Touch wrote: > -1 > > Although it=E2=80=99s understandable to describe =E2=80=9Cwhat operators = do=E2=80=9D, the IETF > isn=E2=80=99t a news service. We typically summarize these behaviors to t= ake a > position on them. > > The draft provides a good description of the tradeoff between the privacy > rights of endpoints and the rights of operators and the impact of both on > protocol design on that tradeoff. > > What I seem to be seeing is increasing =E2=80=9Crough consensus=E2=80=9D = that the summary > position should be closer to endpoint privacy than in the current form. > > Although I don=E2=80=99t feel strongly that the text absolutely needs rev= ision in > that direction, I would oppose changes to relax or shift in the other > direct. > > Joe > > On Jul 1, 2020, at 7:11 AM, Dirk.von-Hugo@telekom.de wrote: > > +1 > Thanks, Kyle! > Kind regards > Dirk > > *From:* Int-area *On Behalf Of *Kyle Rose > *Sent:* Mittwoch, 1. Juli 2020 15:57 > *To:* Hannes Tschofenig > *Cc:* int-area ; tsvwg@ietf.org; IETF SAAG < > saag@ietf.org> > *Subject:* Re: [Int-area] [saag] 3rd WGLC (limited-scope): > draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 > > On Wed, Jul 1, 2020 at 9:20 AM Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > > I noticed this in various IETF discussions and so I will describe it in > the abstract. > > A group of people propose an idea. Those who do not like the idea are the= n > asked to convince the original contributors that their idea is not sound = or > contribute text so make it look nicer. > Not only is this requiring me to spend my time on something I don=E2=80= =99t agree > with but it turns out that no discussions will change the mind of the > original contributors. They just strongly believe in their ideas. They wi= ll > keep proposing the same idea over and over again (for years) till it gets > published as an RFC.. > > > I don't understand why so many are opposed to publishing a document that > merely describes how operators manage protocols in the absence of header > encryption, and how header encryption interferes with those practices. Th= at > is, at least, in its original form, before this WG decided it needed to > incorporate pro-encryption advocacy, greatly complicating the document an= d > the resulting analysis. > > For the OG version, I ask myself the following questions: > > Does the document describe reality? Yes: it tells us what practices > operators employ today. > Is the document useful? Yes: see above, plus it makes clear that there > will be an impact to operators and/or protocol users from this evolution. > Does the document establish an IETF position on encryption? No. There are > plenty of other published RFCs that embody the spirit "encrypt all the > things". This document does not change that. > Does the document make normative statements about future protocol > development? No. > > On what basis would I therefore oppose publication? > > I may or may not have opinions about prioritization of user privacy over > manageability, the tussle between manageability and deployability, and wh= at > alternatives are available to operators for managing protocols with > encrypted headers. I would be happy to help express those in a follow-on > document. But this document describing where those conflicts lie is a > *prerequisite* to developing those alternatives. And frankly those opinio= ns > are irrelevant to the intended content of *this* document. > > Kyle > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --0000000000003e36a805a9673480 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

I think it is a good draft, out = of very hard work, a lot of sweat.

Behcet

On = Wed, Jul 1, 2020 at 10:10 AM Joseph Touch <touch@strayalpha.com> wrote:
=
-1
Although it=E2=80=99s understandable to describe =E2=80=9Cwhat = operators do=E2=80=9D, the IETF isn=E2=80=99t a news service. We typically = summarize these behaviors to take a position on them.

<= div>The draft provides a good description of the tradeoff between the priva= cy rights of endpoints and the rights of operators and the impact of both o= n protocol design on that tradeoff.

What I seem to= be seeing is increasing =E2=80=9Crough consensus=E2=80=9D that the summary= position should be closer to endpoint privacy than in the current form.

Although I don=E2=80=99t feel strongly that the text= absolutely needs revision in that direction, I would oppose changes to rel= ax or shift in the other direct.

Joe

<= blockquote type=3D"cite">
On Jul 1, 2020, at 7:11 AM, Dirk.von-Hugo@telekom.de w= rote:

+= 1
Thanks, Kyle!<= u>
Kind regards<= /u>
Dirk<= /span>
=C2=A0
From:=C2=A0Int-a= rea <int-area-bounces@ietf.org&= gt;=C2=A0On Behalf Of=C2=A0Kyle Rose
Sent:=C2=A0Mittwoch, 1. Juli 2020 15:57
To:=C2=A0Hannes Tschofenig <H= annes.Tschofenig@arm.com>
Cc:=C2=A0int-area &= lt;int-area@ietf.org>;=C2=A0tsvwg@ietf.org; IETF SAAG <saag@ietf.org>
Subject:=C2=A0Re: = [Int-area] [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encr= ypt-15, closes 29 June 2020
=C2=A0
On We= d, Jul 1, 2020 at 9:20 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:
I noticed this in various IETF discussions and so I will d= escribe it in the abstract.
=C2=A0
A group of people propose an idea. Those who d= o not like the idea are then asked to convince the original contributors th= at their idea is not sound or contribute text so make it look nicer.= =C2=A0
Not only is this requiring me to spend my time on something I do= n=E2=80=99t agree with but it turns out that no discussions will change the= mind of the original contributors. They just strongly believe in their ide= as. They will keep proposing the same idea over and over again (for years) = till it gets published as an RFC..
=C2=A0
I don't understand why so many are opposed = to publishing a document that merely describes how operators manage protoco= ls in the absence of header encryption, and how header encryption interfere= s with those practices. That is, at least, in its original form, before thi= s WG decided it needed to incorporate pro-encryption advocacy, greatly comp= licating the document and the resulting analysis.
=
=C2=A0
For the OG version, I ask myself the following questions:<= u>
=C2=A0
Does the document describe r= eality? Yes: it tells us what practices operators employ today.
Is the document useful? Y= es: see above, plus it makes clear that there will be an impact to operator= s and/or protocol users from this evolution.
=
Does the document establish an IETF position on en= cryption? No. There are plenty of other published RFCs that embody the spir= it "encrypt all the things". This document does not change that.<= u>
Does the document ma= ke normative statements about future protocol development? No.
=C2=A0
=
On what basis would I therefore oppose public= ation?
=C2=A0
I may or may not have opinions about = prioritization of user privacy over manageability, the tussle between manag= eability and deployability, and what alternatives are available to operator= s for managing protocols with encrypted headers. I would be happy to help e= xpress those in a follow-on document. But this document describing where th= ose conflicts lie is a *prerequisite* to developing those alternatives. And= frankly those opinions are irrelevant to the intended content of *this* do= cument.
=C2= =A0
Kyle
__= _____________________________________________
Int-area mailing listInt-area@ietf.org
https://www.ietf.org/mailman/listinfo/int= -area

_________________________= ______________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--0000000000003e36a805a9673480-- From nobody Wed Jul 1 20:48:38 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE823A0BFB; Wed, 1 Jul 2020 20:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cmthD0SPsa0; Wed, 1 Jul 2020 20:48:34 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB4E3A0BF7; Wed, 1 Jul 2020 20:48:33 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0623mTkD007753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 1 Jul 2020 23:48:31 -0400 Date: Wed, 1 Jul 2020 20:48:28 -0700 From: Benjamin Kaduk To: Michael Richardson Cc: draft-foudil-securitytxt@ietf.org, saag@ietf.org Message-ID: <20200702034828.GB16335@kduck.mit.edu> References: <20200630222455.GX58278@kduck.mit.edu> <12504.1593572624@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12504.1593572624@localhost> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [saag] results of IETF LC for draft-foudil-securitytxt-08 and next steps X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 03:48:36 -0000 Hi Michael, On Tue, Jun 30, 2020 at 11:03:44PM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > > The topic of use for reporting compromise vs. vulnerability was raised by > > many reviewers, to the extent that it seems like it would be very > > challenging to craft text that would definitively convince the reader to not > > use the contents of the files for reporting cases of active compromise, > > When you say, "reporting compromise" do you think that reviewers/commenters > were limiting this to talking about reporting that example.com (where you > found security.txt) is compromised, or is it about any part of example.com? My understanding is that that's what was so controversial, yes. (Note that the draft is quite clear that https://example.com/.well-known/security.txt does not apply to *.example.com, and one of the points I'd like further clarifying text on is whether the file on the web is useful for non-web stuff.) > I ask because there is a continuity of things between for instance, > 1) reporting that Example.COM "Smart" refriderators are vulnerable (and > maybe have been compromised already), > 2) to reporting that gitlab.example.com (where the fridge source code is > kept) is running a potentially vulnerable version of gitoris, > 3) to reporting that update.example.com (where the signed images are kept) > is full of trojaned code > 4) to reporting that smtp.example.com seems to forward malware through > the mailing lists maintained there > 5) to reporting that www.example.com has been p0wned. Indeed, and well said. > My observation is that most of the discussion ratholed around (5), > completely ignoring other benefits. I don't think that any amount of text we I agree. Note that I myself was not fully clear on these cases in my writeup -- I mentioned compromise in the context of "systems involved in retrieving security.txt" in one place but just the (presumed broader scope) "compromise" in the high-level summary. > put in will help, because it won't really get read by the *reporter* > I don't think that reporters really will understand any line we might think > we can draw. I think a lot of what we're hoping for relies on human judgment and not blindly trusting something without cause. Call me an optimist, but I think there's at least some of that going around, and possibly even more than average if you limit to the "security researcher" community. > > Finally, I see that (while Section 3 is clear about "MUST be accessed with > > the 'https' scheme"), in Section 6.6 we went from "MUST use HTTPS" to > > "should use HTTPS", and since my review of the LC discussion was > > (unfortunately) spread out in time I have forgotten what comment prompted > > that change. It would probably be worth some mention of the expected > > case(s) where HTTPS would not be used (e.g., when it's local file or other > > non-HTTP access), to strengthen the argument for using HTTPS the rest of the > > time. (Possibly related to > > https://github.com/securitytxt/security-txt/issues/177 ) > > My take: > We can't get publically anchored certificates for devices without DNS names, > such as those that might be found in your home on RFC1918 addresses. The > teddy cam can still have a securitytxt on it to report issues. That seems pretty aligned with my best guess, involving cases where https was not possible (whether because it's going via filesystem access and not web, or the device only has an IP address and not a name, or whatever). > > Michael Richardson noted that the scope of contact information is/can be > > broader than just the website hosting the file -- e.g., it would be very > > useful to have a discoverable way to report vulnerabilities in the products > > produced by a company, not just the company's website. It is probably worth > > a mention that (or disclaimer against) the scope of use is potentially > > broader than just the immediate website hosting the file. (This seems > > related to https://github.com/securitytxt/security-txt/issues/185 and might > > result in some text in Section 3.1.) > > If the IETF *does not* want securitytxt used for reporting vulnerablities, > then the IETF had better say so loudly VERY SOON, and probably communicate through > liason to ETSI, IoTSF and UK NCSC about that... although EN 303 645 does not > mention securitytxt by name, the (not-quite-finished, not released) > educational material around it *does* mention it. Indeed. (That's not the sense I'm getting, though, luckily.) Thanks, Ben From nobody Thu Jul 2 03:59:24 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1587F3A0990; Thu, 2 Jul 2020 03:59:22 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUa-ZwSy3c5j; Thu, 2 Jul 2020 03:59:19 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20131.outbound.protection.outlook.com [40.107.2.131]) (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 73A623A0AA2; Thu, 2 Jul 2020 03:59:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AMBsWoB1NvBXZpL5b7gq/mlAXntZ0HI+ct80cRKrrpjaBeS3e/T8PQGpKjk/U9gLC1Bb4V89/snF5q+coHJ8qUEzjljE7HNQIUr0h4m8Ik5jQQ5Ay7jLZHdYdLFK3ouqjv2BeP+9MTH+C9lqNet7YqijTw2i4H7+bgNqeHeEn+DU9W3QiRKGH+juGx+/UzyXI8er1Zq48VBEIaqnil3EN+r6muzLipxYwZKGgIfUQpdg32qaYRhci09YBPYXf+kEwYxhxcoxIWuQOnz0uRVh/HnR38iE4zkobh0VsbJXbYh1iX3wEK4Um+gg9HUtfUFSacBjBIbpYoUqCBU576Z0YQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X8FZibuGJxZkxmEINmK/9hfnGgct+a33puPgM1RHjWo=; b=Wo8iN7hheZAmYQ9Dd1hS5SPiwts7VgpWNWIqmIEzpg9Uc/S2LxPLmj3XVe5WsXQQF/jFjkwEk1JCgHtmMdXPmJRnaTQeSitotx9ui6QBKXWActd5U3HyTQ9gLK4lObIJybhKFdDdARGm6TK7VbOoNI2biK96rauGFmtIcXoZkzrXVOPyBckElcx1jVV6ovtppKM2+rhz64nNrS3t30tH5flb/MjKZTp33AljEpm/eJElbZ9oaGKJ7crmUtr6thR8oZ8uwZjyen9o/YZ4D2zh4tJ26MWG1u4zJzMNX+b8MVmBjfnAAQ5fqN42jVeCyoD5oIXaruVRAsMOsF/BdixrPg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X8FZibuGJxZkxmEINmK/9hfnGgct+a33puPgM1RHjWo=; b=HAyWsWhbwhP+5UbCgHMCWJZrFjrSJxcto/aJw1SguBoYf4pADz/xhXHHp/O8tO+KfOWbsPJbwzCqYEk6Qgld3UA7sSH+2dAhnXkV0FO7ugEmVjVcoceAWSvNHWNsCuOXg1JkP7l1u8CfvUs9b+TcOoyFGXW/qn2BYzz8HBDvCnM= Received: from DBAPR07MB7016.eurprd07.prod.outlook.com (2603:10a6:10:198::14) by DB7PR07MB6122.eurprd07.prod.outlook.com (2603:10a6:10:85::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.8; Thu, 2 Jul 2020 10:59:16 +0000 Received: from DBAPR07MB7016.eurprd07.prod.outlook.com ([fe80::b09b:5a3b:9735:bf26]) by DBAPR07MB7016.eurprd07.prod.outlook.com ([fe80::b09b:5a3b:9735:bf26%5]) with mapi id 15.20.3174.008; Thu, 2 Jul 2020 10:59:16 +0000 From: tom petch To: Colin Perkins , Eric Rescorla CC: int-area , "tsvwg@ietf.org" , IETF SAAG Thread-Topic: [Int-area] [tsvwg] [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 Thread-Index: AQHWT44kbBS95bNKF0a3Pjb+4nlVs6j0H9Fx Date: Thu, 2 Jul 2020 10:59:15 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: csperkins.org; dkim=none (message not signed) header.d=none;csperkins.org; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [81.131.229.35] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8e02920f-cd48-49fd-da66-08d81e76f64c x-ms-traffictypediagnostic: DB7PR07MB6122: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SKcIbxZIQhlK3rXreKDURKMQCK35Ux4NQlByQgdmyj72pne5e+SpJTfxDAXGsSEf+txjT/PQgx8x9PCyKBdRihI5eDbfTF6sAFFKZ+qis60bDyyO8aJIl2qSfW9CgDNDjxfKyiQSmKPf3iy8ERJZsju6ZYkH25XAbd/t3ZzNSrR1mqNnrevgaUhQ3ySb9+1IgfF+ntYq4VEk2PTzJO9n1O4AQ/HJOcwF7TYUZv9mhlv88mgOxqGqbjCtwFY890mKk/Qefv/GvKpAu35pIgRktEhkj43gftyfV8qCzTNT9SYjDlcmmr1pbQrVY0hzqPkBqoVeXw7ihugBkdi3tqt2KYqICGXi0mAku1kG7vPNSpjWBjOb7XV00aK/PcvbG+mCDOgZCIbBqnYxE6WUfjfEfQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBAPR07MB7016.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(39860400002)(396003)(376002)(346002)(136003)(366004)(2906002)(55016002)(83380400001)(966005)(5660300002)(478600001)(33656002)(86362001)(9686003)(7696005)(4326008)(66476007)(186003)(71200400001)(66556008)(66574015)(64756008)(52536014)(8676002)(66446008)(76116006)(53546011)(54906003)(316002)(8936002)(91956017)(66946007)(6506007)(26005)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 3+TsJshTWVmfhOcv4VcK6geEO77L1vAAJH8E5Q6XNgw/7R4Hj3usmzFWWi7ePqYvcPIljPKnAgkBYDLfTWluoFSF4hLpcuv2+XuJmsM9Nl3IdD6ACefvZmS/xfJ2/rjqMnKfyVkBRW/Fy1vBsScx2zQEmFm6gcxt7PQnrls/QaJwIzeWjEPy1WLF9Nxe0LEJPx07JRHN7PEbk6TyJhJrOOnxVlcOwtDhFo0mRc569q4n/yDr2f02M9J/fhVRBt5Ubk5ZCKShD0nMvdkzN7qlp0eMAE5IAIwK58pqAHz+Xu3fnBV7kCkUSJcmUiXonh07KaFj7A8QQUSMtX1jTquk8dli7IXqgDDWzVBLiEEi00nPxH1WrVMuhIYj1ZoEF5bfyziXlQLgIO8iONzchMvgLwKmWV0NBRWooQS+cjrLoictfJzB+bSh875t4K4l8ekmjR0VEcYkxyRKmDPOwrl8X2jqDqkf8vfJs5aGrKoHeuE= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DBAPR07MB7016.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8e02920f-cd48-49fd-da66-08d81e76f64c X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2020 10:59:15.8478 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4hGMo26jNkw6Wq200iZw+CrZYK2+TvUiTzrSCmYQn+r3jciUzM8p8M6FBB51e7MmjdSaSgVHLgGPoZ7ri06ftg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB6122 Archived-At: Subject: Re: [saag] [Int-area] [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 10:59:22 -0000 From: Int-area on behalf of Colin Perkins =0A= Sent: 01 July 2020 10:57=0A= On 30 Jun 2020, at 01:59, Eric Rescorla >= wrote:=0A= =0A= > This 3rd WGLC is limited to the following two topics:=0A= > Whether or not to proceed with a request for RFC publication=0A= > of the draft. The decision on whether or not to proceed will=0A= > be based on rough consensus of the WG, see RFC 7282.=0A= =0A= Publish.=0A= =0A= Operators need help in understanding the impact of emerging technology on t= heir ability to operate a network. This may not be easy to understand but = it does at least provide something to stick out and alert them.=0A= =0A= Tom Petch=0A= =0A= > During the 2nd WGLC, Eric Rescorla and David Schinazi expressed=0A= > strong views that this draft should not be published =96 those=0A= > concerns have not been resolved and are carried forward to=0A= > this WGLC. This email message was an attempt to summarize=0A= > those concerns:=0A= >=0A= > https://mailarchive.ietf.org/arch/msg/tsvwg/i4qyY1HRqKwm0Jme9UtEb6DyhXU/= =0A= >=0A= > Further explanation from both Eric Rescorla and David Schinazi=0A= > is welcome and encouraged to ensure that their concerns are=0A= > clearly understood.=0A= =0A= Well, I'll try again, but I'm not sure that I can do better than=0A= I have before.=0A= =0A= For reasons that are laid out in RFC 7258, the trend in protocol=0A= design in IETF is towards encrypting more and more.=0A= =0A= I agree, but also note that RFC 7258 is clear that some network monitoring = can be beneficial and that =93an appropriate balance=94 has to be found bet= ween mitigating pervasive monitoring and supporting network management. Thi= s draft is intended to highlight issues to be considered by transport proto= col designers, to help them find that balance.=0A= =0A= And, to be clear, if transport protocol designers consider the issues and d= ecide that all the metadata in their transport protocol must be encrypted, = that=92s fine. We're not pushing for a particular outcome; rather that the = issues be considered and discussed when making a decision on what to encryp= t.=0A= =0A= The last two=0A= transport protocols that were designed and widely deployed (SCTP over=0A= DTLS and QUIC) both encrypt the vast majority of the protocol=0A= metadata. This document advertises itself as "considerations"=0A= for design of such protocols:=0A= =0A= The transport protocols developed for the Internet are used across a=0A= wide range of paths across network segments with many different=0A= regulatory, commercial, and engineering considerations. This=0A= document considers some of the costs and changes to network=0A= management and research that are implied by widespread use of=0A= transport protocols that encrypt their transport header information.=0A= It reviews the implications of developing transport protocols that=0A= use end-to-end encryption to provide confidentiality of their=0A= transport layer headers, and considers the effect of such changes on=0A= transport protocol design, transport protocol evolution, and network=0A= operations. It also considers some anticipated implications on=0A= application evolution. This provides considerations relating to the=0A= design of transport protocols and features where the transport=0A= protocol encrypts some or all of their header information.=0A= =0A= However, as I said above, the new transport protocols that are=0A= actually being designed already feature metadata encryption and as far=0A= as I can tell, there is no prospective protocol new transport protocol=0A= design project for which these issues might be live.=0A= =0A= The issues highlighted in the draft were certainly considered in the design= of QUIC, especially in the discussions around the spin bit and operational= aspects. I cannot envisage that they won=92t also be considered in the des= ign of future transports.=0A= =0A= In that context,=0A= it's hard not to read this document with its long litany of practices=0A= which are impacted by metadata encryption as a critique of the=0A= decisions by SCTP/DTLS and QUIC to encrypt most of the metadata.=0A= =0A= I tend to regard critiques of protocol design as a good thing, but then we = maybe have a different interpretations of that term. Certainly there are im= plications of the decision to encrypt transport metadata. There are benefit= s to it, but also costs. It=92s important to understand both, to make an in= formed judgement on what to encrypt.=0A= =0A= This impression is reinforced by the description of the actual=0A= practices themselves, which focuses almost entirely on practices=0A= which appear to be benignly motivated (e.g., performance monitoring,=0A= troubleshooting, etc.) However, we also know that metadata is widely=0A= used for practices in which the network operator is adversarial=0A= to the user, for instance:=0A= =0A= - Blocking traffic based on TCP port, IP address, SNI, etc.=0A= =0A= - Performance-based traffic class discrimination=0A= =0A= - Monitoring the user's behavior via indicia like the ones above=0A= or via traffic analysis (see [0])=0A= =0A= Yes, I understand that the authors explicitly disclaim judgement on=0A= these practices, and the document does briefly touch on the general=0A= idea, though the "concerns...have been voiced" tends to minimize those=0A= concerns [1] but the selection of practices to focus on is extremely=0A= telling. Focusing on the downsides of encryption for (at least=0A= arguably well-meaning) network players while mostly ignoring the large=0A= class of non-benign behaviors which encryption is intended to protect=0A= against has the effect of overemphasizing the costs of encryption to=0A= those players and minimizing the benefits to the endpoints whom it is=0A= intended to protect.=0A= =0A= Different communities have different interpretations on what=92s the neutra= l point of view phrasing here, but I'm comfortable with further highlightin= g malicious uses of transport metadata in the draft. We=92d tried to mostly= do this by reference, since such things have been widely discussed in the = past, but perhaps that=92s not sufficient.=0A= =0A= To be maximally clear: I don't object to this document existing=0A= and I don't think that the opinions implicit in it are ones that=0A= should not be expressed. I merely don't think that it should be=0A= published as an IETF Consensus document.=0A= =0A= -Ekr=0A= =0A= [0] https://tools.ietf.org/html/draft-wood-pearg-website-fingerprinting-00#= section-5=0A= [1] Another motivation stems from increased concerns about privacy and= =0A= surveillance. Users value the ability to protect their identity=0A= and location, and defend against analysis of the traffic.=0A= Revelations about the use of pervasive surveillance [RFC7624]=0A= have, to some extent, eroded trust in the service offered by=0A= network operators and have led to an increased use of encryption=0A= to avoid unwanted eavesdropping on communications. Concerns have=0A= also been voiced about the addition of information to packets by=0A= third parties to provide analytics, customisation, advertising,=0A= cross-site tracking of users, to bill the customer, or to=0A= selectively allow or block content. Whatever the reasons, the=0A= IETF is designing protocols that include transport header=0A= encryption (e.g., QUIC [I-D.ietf-quic-transport]) to supplement=0A= the already widespread payload encryption, and to further limit=0A= exposure of transport metadata to the network.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= --=0A= Colin Perkins=0A= https://csperkins.org/=0A= =0A= =0A= =0A= =0A= From nobody Thu Jul 2 05:16:13 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6229D3A0C29; Thu, 2 Jul 2020 05:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 CCbfud6EmkvF; Thu, 2 Jul 2020 05:16:09 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 618DF3A0C28; Thu, 2 Jul 2020 05:16:09 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id h19so31679987ljg.13; Thu, 02 Jul 2020 05:16:09 -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=u0vqklFnCMLbgkrJ173zpzJKz7Unquy26bQqdgr/N/E=; b=iwEKmpPBlruYV9MPo53JYSS0NXHxleeCmC/5BmUjCqWq5KkSEQNaUp45sbAptp7JUc ScaaUMVTmxLFBWehDkEq3W/Dg/oBg0uF+EaT0+Zh8d1vYoYn1ud5uKq3XNyk5l8cKwzv DNWQC4XmOHzd8jh1m63y9vhtaC/BErY/vdQBe4MD9U2YI6vqi6zAgE3sM99rhVr/uYuO 48YbiCuiB4rvgpEpU3Rs1NZ7v3d3ak8wJah/3v8w4hIrNDr6XbLnuhmONIouSx92huGp IFx8ptK/g6l9nQuKFxCVST1IT4Hz7p7k1n46D0hB+JYiy86hCkc7pFU1zujQMu72eAUb fq9Q== 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=u0vqklFnCMLbgkrJ173zpzJKz7Unquy26bQqdgr/N/E=; b=GYeEPedS883XGxpjj2WlY15bBFdiL1yiY9oAND3Ok5LrThmNlv0G77oKbUDk57Bmw0 NAltT2UeMAa9SOfJTmI7bch1pXqqO1n8PCiJ00uTFZhLJ25FXY3+iLphmsYStGdqPNpJ rJoNMwj0pJXo+NpLeSjItthJaFdpHnEDFwqXfcGVnTJSL0bM3AdeLjPCracq5jhDLgsm XdyVGM5dbx+49iALJrkVPxMn59cW4sWS1vGteqCvaZ0+hv5lU6SRuRIysEKz55aPJMRg o6gvN0E3ngy4GloonFmfioJq3uqSzywlXjw9z+xV4hvMMEz0Pk02fra835j7/0astwRh ZB7A== X-Gm-Message-State: AOAM5329JynF6P31b9HqWF3gGoZ466jz+Qw/0nIC++Wt5sAQTb7n1IKx xFFcv2SGJp7F7jLWYnZLVriq/0MkdPV0e7Q358E= X-Google-Smtp-Source: ABdhPJx79evoceBuPC9I3gpybvyb1RqgZU+nO+MxwymVTO2x68hOcUtSycHDl0/5i5WdaM6leUo7DvsBq1BuRyeUalE= X-Received: by 2002:a2e:9b42:: with SMTP id o2mr15669853ljj.102.1593692167568; Thu, 02 Jul 2020 05:16:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Spencer Dawkins at IETF Date: Thu, 2 Jul 2020 07:15:40 -0500 Message-ID: To: tom petch Cc: Colin Perkins , Eric Rescorla , int-area , "tsvwg@ietf.org" , IETF SAAG Content-Type: multipart/alternative; boundary="00000000000087814805a9745f95" Archived-At: Subject: Re: [saag] [tsvwg] [Int-area] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 12:16:12 -0000 --00000000000087814805a9745f95 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Top-posting to note that this "WGLC" is now being copied to INT-AREA and SAAG, people are making statements about value to operators (but no operator-area entity is being copied), and people are making statements about whether this could be published in the IETF stream, with the IETF consensus boilerplate. All of these are fine conversations during *IETF* Last Call, and it seems like we're about halfway to including the rest of the IETF in the WGLC anyway, but is this a sign that the discussion has moved beyond WGLC, so the venue for the discussion should move, too? And this isn't remotely my call. I just had to ask. Best, Spencer, not ranting On Thu, Jul 2, 2020 at 6:00 AM tom petch wrote: > From: Int-area on behalf of Colin Perkins < > csp@csperkins.org> > Sent: 01 July 2020 10:57 > On 30 Jun 2020, at 01:59, Eric Rescorla > > wrote: > > > This 3rd WGLC is limited to the following two topics: > > Whether or not to proceed with a request for RFC publication > > of the draft. The decision on whether or not to proceed will > > be based on rough consensus of the WG, see RFC 7282. > > Publish. > > Operators need help in understanding the impact of emerging technology on > their ability to operate a network. This may not be easy to understand b= ut > it does at least provide something to stick out and alert them. > > Tom Petch > > > During the 2nd WGLC, Eric Rescorla and David Schinazi expressed > > strong views that this draft should not be published =E2=80=93 those > > concerns have not been resolved and are carried forward to > > this WGLC. This email message was an attempt to summarize > > those concerns: > > > > https://mailarchive.ietf.org/arch/msg/tsvwg/i4qyY1HRqKwm0Jme9UtEb6DyhXU= / > > > > Further explanation from both Eric Rescorla and David Schinazi > > is welcome and encouraged to ensure that their concerns are > > clearly understood. > > Well, I'll try again, but I'm not sure that I can do better than > I have before. > > For reasons that are laid out in RFC 7258, the trend in protocol > design in IETF is towards encrypting more and more. > > I agree, but also note that RFC 7258 is clear that some network monitorin= g > can be beneficial and that =E2=80=9Can appropriate balance=E2=80=9D has t= o be found between > mitigating pervasive monitoring and supporting network management. This > draft is intended to highlight issues to be considered by transport > protocol designers, to help them find that balance. > > And, to be clear, if transport protocol designers consider the issues and > decide that all the metadata in their transport protocol must be encrypte= d, > that=E2=80=99s fine. We're not pushing for a particular outcome; rather t= hat the > issues be considered and discussed when making a decision on what to > encrypt. > > The last two > transport protocols that were designed and widely deployed (SCTP over > DTLS and QUIC) both encrypt the vast majority of the protocol > metadata. This document advertises itself as "considerations" > for design of such protocols: > > The transport protocols developed for the Internet are used across a > wide range of paths across network segments with many different > regulatory, commercial, and engineering considerations. This > document considers some of the costs and changes to network > management and research that are implied by widespread use of > transport protocols that encrypt their transport header information. > It reviews the implications of developing transport protocols that > use end-to-end encryption to provide confidentiality of their > transport layer headers, and considers the effect of such changes on > transport protocol design, transport protocol evolution, and network > operations. It also considers some anticipated implications on > application evolution. This provides considerations relating to the > design of transport protocols and features where the transport > protocol encrypts some or all of their header information. > > However, as I said above, the new transport protocols that are > actually being designed already feature metadata encryption and as far > as I can tell, there is no prospective protocol new transport protocol > design project for which these issues might be live. > > The issues highlighted in the draft were certainly considered in the > design of QUIC, especially in the discussions around the spin bit and > operational aspects. I cannot envisage that they won=E2=80=99t also be co= nsidered > in the design of future transports. > > In that context, > it's hard not to read this document with its long litany of practices > which are impacted by metadata encryption as a critique of the > decisions by SCTP/DTLS and QUIC to encrypt most of the metadata. > > I tend to regard critiques of protocol design as a good thing, but then w= e > maybe have a different interpretations of that term. Certainly there are > implications of the decision to encrypt transport metadata. There are > benefits to it, but also costs. It=E2=80=99s important to understand both= , to make > an informed judgement on what to encrypt. > > This impression is reinforced by the description of the actual > practices themselves, which focuses almost entirely on practices > which appear to be benignly motivated (e.g., performance monitoring, > troubleshooting, etc.) However, we also know that metadata is widely > used for practices in which the network operator is adversarial > to the user, for instance: > > - Blocking traffic based on TCP port, IP address, SNI, etc. > > - Performance-based traffic class discrimination > > - Monitoring the user's behavior via indicia like the ones above > or via traffic analysis (see [0]) > > Yes, I understand that the authors explicitly disclaim judgement on > these practices, and the document does briefly touch on the general > idea, though the "concerns...have been voiced" tends to minimize those > concerns [1] but the selection of practices to focus on is extremely > telling. Focusing on the downsides of encryption for (at least > arguably well-meaning) network players while mostly ignoring the large > class of non-benign behaviors which encryption is intended to protect > against has the effect of overemphasizing the costs of encryption to > those players and minimizing the benefits to the endpoints whom it is > intended to protect. > > Different communities have different interpretations on what=E2=80=99s th= e neutral > point of view phrasing here, but I'm comfortable with further highlightin= g > malicious uses of transport metadata in the draft. We=E2=80=99d tried to = mostly do > this by reference, since such things have been widely discussed in the > past, but perhaps that=E2=80=99s not sufficient. > > To be maximally clear: I don't object to this document existing > and I don't think that the opinions implicit in it are ones that > should not be expressed. I merely don't think that it should be > published as an IETF Consensus document. > > -Ekr > > [0] > https://tools.ietf.org/html/draft-wood-pearg-website-fingerprinting-00#se= ction-5 > [1] Another motivation stems from increased concerns about privacy and > surveillance. Users value the ability to protect their identity > and location, and defend against analysis of the traffic. > Revelations about the use of pervasive surveillance [RFC7624] > have, to some extent, eroded trust in the service offered by > network operators and have led to an increased use of encryption > to avoid unwanted eavesdropping on communications. Concerns have > also been voiced about the addition of information to packets by > third parties to provide analytics, customisation, advertising, > cross-site tracking of users, to bill the customer, or to > selectively allow or block content. Whatever the reasons, the > IETF is designing protocols that include transport header > encryption (e.g., QUIC [I-D.ietf-quic-transport]) to supplement > the already widespread payload encryption, and to further limit > exposure of transport metadata to the network. > > > > > > > > > > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > > --00000000000087814805a9745f95 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Top-posting to note that this "WGLC" is now= being copied to INT-AREA and SAAG, people are making statements about valu= e to operators (but no operator-area entity is being copied), and people ar= e making statements about whether this could be published in the IETF strea= m, with the IETF consensus boilerplate.=C2=A0

All = of these are fine conversations during *IETF* Last Call, and it seems like = we're about halfway to including the rest of the IETF in the WGLC anywa= y, but is this a sign that the discussion has moved beyond WGLC, so the ven= ue for the discussion should move, too?

And this i= sn't remotely my call. I just had to ask.=C2=A0

Best,

Spencer, not ranting

<= div class=3D"gmail_quote">
On Thu, Jul= 2, 2020 at 6:00 AM tom petch <ie= tfc@btconnect.com> wrote:
From: Int-area <int-area-bounces@ietf.org> on behalf of Coli= n Perkins <csp@cs= perkins.org>
Sent: 01 July 2020 10:57
On 30 Jun 2020, at 01:59, Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>> wrote:

> This 3rd WGLC is limited to the following two topics:
>=C2=A0 =C2=A0 =C2=A0Whether or not to proceed with a request for RFC pu= blication
> of the draft.=C2=A0 =C2=A0The decision on whether or not to proceed wi= ll
> be based on rough consensus of the WG, see RFC 7282.

Publish.

Operators need help in understanding the impact of emerging technology on t= heir ability to operate a network.=C2=A0 This may not be easy to understand= but it does at least provide something to stick out and alert them.

Tom Petch

> During the 2nd WGLC, Eric Rescorla and David Schinazi expressed
> strong views that this draft should not be published =E2=80=93=C2=A0 t= hose
> concerns have not been resolved and are carried forward to
> this WGLC.=C2=A0 This email message was an attempt to summarize
> those concerns:
>
> https://mailarchive.iet= f.org/arch/msg/tsvwg/i4qyY1HRqKwm0Jme9UtEb6DyhXU/
>
> Further explanation from both Eric Rescorla and David Schinazi
> is welcome and encouraged to ensure that their concerns are
> clearly understood.

Well, I'll try again, but I'm not sure that I can do better than I have before.

For reasons that are laid out in RFC 7258, the trend in protocol
design in IETF is towards encrypting more and more.

I agree, but also note that RFC 7258 is clear that some network monitoring = can be beneficial and that =E2=80=9Can appropriate balance=E2=80=9D has to = be found between mitigating pervasive monitoring and supporting network man= agement. This draft is intended to highlight issues to be considered by tra= nsport protocol designers, to help them find that balance.

And, to be clear, if transport protocol designers consider the issues and d= ecide that all the metadata in their transport protocol must be encrypted, = that=E2=80=99s fine. We're not pushing for a particular outcome; rather= that the issues be considered and discussed when making a decision on what= to encrypt.

The last two
transport protocols that were designed and widely deployed (SCTP over
DTLS and QUIC) both encrypt the vast majority of the protocol
metadata. This document advertises itself as "considerations"
for design of such protocols:

=C2=A0 =C2=A0The transport protocols developed for the Internet are used ac= ross a
=C2=A0 =C2=A0wide range of paths across network segments with many differen= t
=C2=A0 =C2=A0regulatory, commercial, and engineering considerations.=C2=A0 = This
=C2=A0 =C2=A0document considers some of the costs and changes to network =C2=A0 =C2=A0management and research that are implied by widespread use of<= br> =C2=A0 =C2=A0transport protocols that encrypt their transport header inform= ation.
=C2=A0 =C2=A0It reviews the implications of developing transport protocols = that
=C2=A0 =C2=A0use end-to-end encryption to provide confidentiality of their<= br> =C2=A0 =C2=A0transport layer headers, and considers the effect of such chan= ges on
=C2=A0 =C2=A0transport protocol design, transport protocol evolution, and n= etwork
=C2=A0 =C2=A0operations.=C2=A0 It also considers some anticipated implicati= ons on
=C2=A0 =C2=A0application evolution.=C2=A0 This provides considerations rela= ting to the
=C2=A0 =C2=A0design of transport protocols and features where the transport=
=C2=A0 =C2=A0protocol encrypts some or all of their header information.

However, as I said above, the new transport protocols that are
actually being designed already feature metadata encryption and as far
as I can tell, there is no prospective protocol new transport protocol
design project for which these issues might be live.

The issues highlighted in the draft were certainly considered in the design= of QUIC, especially in the discussions around the spin bit and operational= aspects. I cannot envisage that they won=E2=80=99t also be considered in t= he design of future transports.

In that context,
it's hard not to read this document with its long litany of practices which are impacted by metadata encryption as a critique of the
decisions by SCTP/DTLS and QUIC to encrypt most of the metadata.

I tend to regard critiques of protocol design as a good thing, but then we = maybe have a different interpretations of that term. Certainly there are im= plications of the decision to encrypt transport metadata. There are benefit= s to it, but also costs. It=E2=80=99s important to understand both, to make= an informed judgement on what to encrypt.

This impression is reinforced by the description of the actual
practices themselves, which focuses almost entirely on practices
which appear to be benignly motivated (e.g., performance monitoring,
troubleshooting, etc.) However, we also know that metadata is widely
used for practices in which the network operator is adversarial
to the user, for instance:

- Blocking traffic based on TCP port, IP address, SNI, etc.

- Performance-based traffic class discrimination

- Monitoring the user's behavior via indicia like the ones above
=C2=A0 or via traffic analysis (see [0])

Yes, I understand that the authors explicitly disclaim judgement on
these practices, and the document does briefly touch on the general
idea, though the "concerns...have been voiced" tends to minimize = those
concerns [1] but the selection of practices to focus on is extremely
telling. Focusing on the downsides of encryption for (at least
arguably well-meaning) network players while mostly ignoring the large
class of non-benign behaviors which encryption is intended to protect
against has the effect of overemphasizing the costs of encryption to
those players and minimizing the benefits to the endpoints whom it is
intended to protect.

Different communities have different interpretations on what=E2=80=99s the = neutral point of view phrasing here, but I'm comfortable with further h= ighlighting malicious uses of transport metadata in the draft. We=E2=80=99d= tried to mostly do this by reference, since such things have been widely d= iscussed in the past, but perhaps that=E2=80=99s not sufficient.

To be maximally clear: I don't object to this document existing
and I don't think that the opinions implicit in it are ones that
should not be expressed. I merely don't think that it should be
published as an IETF Consensus document.

-Ekr

[0] https://tools.ie= tf.org/html/draft-wood-pearg-website-fingerprinting-00#section-5
[1]=C2=A0 =C2=A0 Another motivation stems from increased concerns about pri= vacy and
=C2=A0 =C2=A0 =C2=A0 surveillance.=C2=A0 Users value the ability to protect= their identity
=C2=A0 =C2=A0 =C2=A0 and location, and defend against analysis of the traff= ic.
=C2=A0 =C2=A0 =C2=A0 Revelations about the use of pervasive surveillance [R= FC7624]
=C2=A0 =C2=A0 =C2=A0 have, to some extent, eroded trust in the service offe= red by
=C2=A0 =C2=A0 =C2=A0 network operators and have led to an increased use of = encryption
=C2=A0 =C2=A0 =C2=A0 to avoid unwanted eavesdropping on communications.=C2= =A0 Concerns have
=C2=A0 =C2=A0 =C2=A0 also been voiced about the addition of information to = packets by
=C2=A0 =C2=A0 =C2=A0 third parties to provide analytics, customisation, adv= ertising,
=C2=A0 =C2=A0 =C2=A0 cross-site tracking of users, to bill the customer, or= to
=C2=A0 =C2=A0 =C2=A0 selectively allow or block content.=C2=A0 Whatever the= reasons, the
=C2=A0 =C2=A0 =C2=A0 IETF is designing protocols that include transport hea= der
=C2=A0 =C2=A0 =C2=A0 encryption (e.g., QUIC [I-D.ietf-quic-transport]) to s= upplement
=C2=A0 =C2=A0 =C2=A0 the already widespread payload encryption, and to furt= her limit
=C2=A0 =C2=A0 =C2=A0 exposure of transport metadata to the network.












--
Colin Perkins
htt= ps://csperkins.org/





--00000000000087814805a9745f95-- From nobody Thu Jul 2 09:12:35 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E173A09FD; Thu, 2 Jul 2020 09:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSIfQXOGzJG4; Thu, 2 Jul 2020 09:12:30 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF6423A09FB; Thu, 2 Jul 2020 09:12:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 84265389C2; Thu, 2 Jul 2020 12:09:39 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qqgElXusqr0l; Thu, 2 Jul 2020 12:09:38 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9742B389BD; Thu, 2 Jul 2020 12:09:38 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3533B3DE; Thu, 2 Jul 2020 12:12:27 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: draft-foudil-securitytxt@ietf.org, saag@ietf.org In-Reply-To: <20200702034828.GB16335@kduck.mit.edu> References: <20200630222455.GX58278@kduck.mit.edu> <12504.1593572624@localhost> <20200702034828.GB16335@kduck.mit.edu> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] results of IETF LC for draft-foudil-securitytxt-08 and next steps X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 16:12:33 -0000 --=-=-= Content-Type: text/plain Benjamin Kaduk wrote: >> Benjamin Kaduk wrote: >> > The topic of use for reporting compromise vs. vulnerability was raised by >> > many reviewers, to the extent that it seems like it would be very >> > challenging to craft text that would definitively convince the reader to not >> > use the contents of the files for reporting cases of active compromise, >> >> When you say, "reporting compromise" do you think that reviewers/commenters >> were limiting this to talking about reporting that example.com (where you >> found security.txt) is compromised, or is it about any part of example.com? > My understanding is that that's what was so controversial, yes. (Note that > the draft is quite clear that https://example.com/.well-known/security.txt > does not apply to *.example.com, and one of the points I'd like further > clarifying text on is whether the file on the web is useful for non-web > stuff.) I believe that it is useful as a point of contact for all things related example.com. I don't understand limiting it the way that 3.1 says. It feels like this limitation is the result of some comment. I guess I would like to have a statement that either restricts the scope to where it is found, or not. It might also be worth indicating if it is worth looking for subdomain.example.com/.well-known/security.txt or not. > I think a lot of what we're hoping for relies on human judgment and not > blindly trusting something without cause. Call me an optimist, but I think > there's at least some of that going around, and possibly even more than > average if you limit to the "security researcher" community. I agree with your optimism. >> My take: >> We can't get publically anchored certificates for devices without DNS names, >> such as those that might be found in your home on RFC1918 addresses. The >> teddy cam can still have a securitytxt on it to report issues. > That seems pretty aligned with my best guess, involving cases where https > was not possible (whether because it's going via filesystem access and not > web, or the device only has an IP address and not a name, or whatever). Okay, but if the teddycam at 192.168.1.104, has a security.txt, then it can only apply for reporting vulnerabilities in *that* TeddyCam, since other Teddy Cams would be at different addresses, according to section 3.1. >> > Michael Richardson noted that the scope of contact information is/can be >> > broader than just the website hosting the file -- e.g., it would be very >> > useful to have a discoverable way to report vulnerabilities in the products >> > produced by a company, not just the company's website. It is probably worth >> > a mention that (or disclaimer against) the scope of use is potentially >> > broader than just the immediate website hosting the file. (This seems >> > related to https://github.com/securitytxt/security-txt/issues/185 and might >> > result in some text in Section 3.1.) >> >> If the IETF *does not* want securitytxt used for reporting vulnerablities, >> then the IETF had better say so loudly VERY SOON, and probably communicate through >> liason to ETSI, IoTSF and UK NCSC about that... although EN 303 645 does not >> mention securitytxt by name, the (not-quite-finished, not released) >> educational material around it *does* mention it. > Indeed. (That's not the sense I'm getting, though, luckily.) Please clarify... too many negatives to parse. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7+B2oACgkQgItw+93Q 3WU6hQf/WoyUidlmT543FnQ/NN5CSZgMJ0HBedeptCgCdx7NkJ/1Yui2dKS3MhRu UoKBIH9XPwuqQeOyz5TGzDgc0Adtml5RHFKOfS8eCj17ZUDu+tt9sb0ngshkSpkE 1AA9B7L5tm+PtcxQ2aPc7XduNnRfpmDUZpjcAt9odMIqS7QCh2gMlnY16lAoVYbM 2a6DBpUYmLehKibbcqkzPgFVMc1LTFp0PZhmHA8p4ug5oVXvckG1cycHp9PBUn5S P20S/kV5/irGghtGHb3NqoLtOFFvUr8DKY5iuKrC+cGm09V1jep0Z+V+of3dOKRq E1MND2yP55AgfklzGPaQqvGp1oqfMQ== =rUNZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 2 15:20:42 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAB73A0C34; Thu, 2 Jul 2020 15:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jof8ALagk1_J; Thu, 2 Jul 2020 15:20:38 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8500C3A0C33; Thu, 2 Jul 2020 15:20:37 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 062MKX7i024403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 2 Jul 2020 18:20:35 -0400 Date: Thu, 2 Jul 2020 15:20:32 -0700 From: Benjamin Kaduk To: Michael Richardson Cc: draft-foudil-securitytxt@ietf.org, saag@ietf.org Message-ID: <20200702222032.GG16335@kduck.mit.edu> References: <20200630222455.GX58278@kduck.mit.edu> <12504.1593572624@localhost> <20200702034828.GB16335@kduck.mit.edu> <5953.1593706347@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5953.1593706347@localhost> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [saag] results of IETF LC for draft-foudil-securitytxt-08 and next steps X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 22:20:40 -0000 On Thu, Jul 02, 2020 at 12:12:27PM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > >> Benjamin Kaduk wrote: > >> > The topic of use for reporting compromise vs. vulnerability was raised by > >> > many reviewers, to the extent that it seems like it would be very > >> > challenging to craft text that would definitively convince the reader to not > >> > use the contents of the files for reporting cases of active compromise, > >> > >> When you say, "reporting compromise" do you think that reviewers/commenters > >> were limiting this to talking about reporting that example.com (where you > >> found security.txt) is compromised, or is it about any part of example.com? > > > My understanding is that that's what was so controversial, yes. (Note that > > the draft is quite clear that https://example.com/.well-known/security.txt > > does not apply to *.example.com, and one of the points I'd like further > > clarifying text on is whether the file on the web is useful for non-web > > stuff.) > > I believe that it is useful as a point of contact for all things related example.com. > I don't understand limiting it the way that 3.1 says. > It feels like this limitation is the result of some comment. > I guess I would like to have a statement that either restricts the scope > to where it is found, or not. It might also be worth indicating if it is > worth looking for subdomain.example.com/.well-known/security.txt or not. The authors may remember better than I do, but I think this came up due to corporate scenarios where division A and division B don't talk to each other much, so a single corporate contact point/plan wouldn't work. I also think it would be useful to have the web's /.well-known/security.txt provide a contact point for non-web resources (such as physical devices), but don't want to force my opinion on people if it's not the consensus. > > I think a lot of what we're hoping for relies on human judgment and not > > blindly trusting something without cause. Call me an optimist, but I think > > there's at least some of that going around, and possibly even more than > > average if you limit to the "security researcher" community. > > I agree with your optimism. > > >> My take: > >> We can't get publically anchored certificates for devices without DNS names, > >> such as those that might be found in your home on RFC1918 addresses. The > >> teddy cam can still have a securitytxt on it to report issues. > > > That seems pretty aligned with my best guess, involving cases where https > > was not possible (whether because it's going via filesystem access and not > > web, or the device only has an IP address and not a name, or whatever). > > Okay, but if the teddycam at 192.168.1.104, has a security.txt, then it can > only apply for reporting vulnerabilities in *that* TeddyCam, since other > Teddy Cams would be at different addresses, according to section 3.1. Yes ... but any vulnerabilities in that one would also be expected to be present in other instances of the same model, and if the contact point is at the manufacturer, the manufacturer can do the right thing? I feel like you have a downside in mind that I'm failing to spot... > >> > Michael Richardson noted that the scope of contact information is/can be > >> > broader than just the website hosting the file -- e.g., it would be very > >> > useful to have a discoverable way to report vulnerabilities in the products > >> > produced by a company, not just the company's website. It is probably worth > >> > a mention that (or disclaimer against) the scope of use is potentially > >> > broader than just the immediate website hosting the file. (This seems > >> > related to https://github.com/securitytxt/security-txt/issues/185 and might > >> > result in some text in Section 3.1.) > >> > >> If the IETF *does not* want securitytxt used for reporting vulnerablities, > >> then the IETF had better say so loudly VERY SOON, and probably communicate through > >> liason to ETSI, IoTSF and UK NCSC about that... although EN 303 645 does not > >> mention securitytxt by name, the (not-quite-finished, not released) > >> educational material around it *does* mention it. > > > Indeed. (That's not the sense I'm getting, though, luckily.) > > Please clarify... too many negatives to parse. Sorry to be confusing. I am seeing general support (in the rough consensus sense) in the IETF for using securitytxt to report vulnerabilities, controversy about reporting compromise or what precise scope it should have notwithstanding. -Ben From nobody Thu Jul 2 23:33:05 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725EC3A0D20; Thu, 2 Jul 2020 23:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbeX4H5jSSol; Thu, 2 Jul 2020 23:33:02 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8E963A0D21; Thu, 2 Jul 2020 23:33:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0262E389D6; Fri, 3 Jul 2020 02:30:10 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jIfI6EHrdwsJ; Fri, 3 Jul 2020 02:30:09 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 04EAC389D5; Fri, 3 Jul 2020 02:30:09 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2781A3DE; Fri, 3 Jul 2020 02:32:58 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: draft-foudil-securitytxt@ietf.org, saag@ietf.org In-Reply-To: <20200702222032.GG16335@kduck.mit.edu> References: <20200630222455.GX58278@kduck.mit.edu> <12504.1593572624@localhost> <20200702034828.GB16335@kduck.mit.edu> <5953.1593706347@localhost> <20200702222032.GG16335@kduck.mit.edu> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] results of IETF LC for draft-foudil-securitytxt-08 and next steps X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 06:33:05 -0000 --=-=-= Content-Type: text/plain Benjamin Kaduk wrote: >> >> My take: >> >> We can't get publically anchored certificates for devices without DNS names, >> >> such as those that might be found in your home on RFC1918 addresses. The >> >> teddy cam can still have a securitytxt on it to report issues. >> >> > That seems pretty aligned with my best guess, involving cases where https >> > was not possible (whether because it's going via filesystem access and not >> > web, or the device only has an IP address and not a name, or whatever). >> >> Okay, but if the teddycam at 192.168.1.104, has a security.txt, then it can >> only apply for reporting vulnerabilities in *that* TeddyCam, since other >> Teddy Cams would be at different addresses, according to section 3.1. > Yes ... but any vulnerabilities in that one would also be expected to be > present in other instances of the same model, and if the contact point is > at the manufacturer, the manufacturer can do the right thing? > I feel like you have a downside in mind that I'm failing to spot... If a security.txt applies *only* to the web resource where you found it, then that means it doesn't generalize to the other instances of that device. That sounds dumb, and it is, but that's what I'm reading in section 3.1 >> >> > Michael Richardson noted that the scope of contact information is/can be >> >> > broader than just the website hosting the file -- e.g., it would be very >> >> > useful to have a discoverable way to report vulnerabilities in the products >> >> > produced by a company, not just the company's website. It is probably worth >> >> > a mention that (or disclaimer against) the scope of use is potentially >> >> > broader than just the immediate website hosting the file. (This seems >> >> > related to https://github.com/securitytxt/security-txt/issues/185 and might >> >> > result in some text in Section 3.1.) >> >> >> >> If the IETF *does not* want securitytxt used for reporting vulnerablities, >> >> then the IETF had better say so loudly VERY SOON, and probably communicate through >> >> liason to ETSI, IoTSF and UK NCSC about that... although EN 303 645 does not >> >> mention securitytxt by name, the (not-quite-finished, not released) >> >> educational material around it *does* mention it. >> >> > Indeed. (That's not the sense I'm getting, though, luckily.) >> >> Please clarify... too many negatives to parse. > Sorry to be confusing. > I am seeing general support (in the rough consensus sense) in the IETF for > using securitytxt to report vulnerabilities, controversy about > reporting compromise or what precise scope it should have notwithstanding. Good! We agree then. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT 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----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl7+0RkACgkQgItw+93Q 3WXAJQf+PdXA+erfGPSTAzfVgBCR6+htI+2SGDKpCvxz5rrBlRIT47g87t9ziN08 GcRKdHPJEMblrQLpH/y+KxupOuPS5BgMh1DR7RuVZ+3QVXXfsIeO07Yat5XXOWws mhsgmkUWCL38ZDfb/yEgJfAz/OvY9fkKSmlEG5BC1FmNfoPPf5YYM6DqmNg/HmoW IHFVmRr+BNkfZmRxwSOkVuC6VW8QR72HY1oFpo+cYm1kRwbAJL3+ESHqlxKaslC7 8LrpRG690Zyjhe6HNxYVSufetDQkJTlAXJC76ozC1WxbeMrrkgurHCwSaRUlTvVb iTlI7G2jpA837UyhQlD+JxI9JMh8GA== =9Plv -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 3 17:24:24 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6644E3A0853 for ; Fri, 3 Jul 2020 17:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 G17WB5JtbI8J for ; Fri, 3 Jul 2020 17:24:21 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 D2C783A083D for ; Fri, 3 Jul 2020 17:24:20 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id q3so17799944ilt.8 for ; Fri, 03 Jul 2020 17:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=LxRnWtX4qUj0xmb6YCqFrz48EF59MJUBLCRl1nRYyjQ=; b=ZOiFb4VQyBxtJhJh3/V39BWZO9EPlMbYXzwZfVfcecLp5N9jCxyx70hHfaQol2h2jb XSJPtZpOnLYYWlh4vRQTLlqkR7Vf5XadTCF1xr9juT32yq4JDGPTxyYnjKnChZsX1Gle QGLjFOd+M1A2YsLIBUWmyC/1OimgfXmlWcd/iSYdYS6IMHG3kVD6c+aWZ7jLLUJvL3E6 u4IEboqHWyQlh6wQJqryzNXE4BSBWtGkoKdRp2Znl+2sWrYOiu35TMTfrMiv3M9JSjCj hwpejzw94f2Mw49CpyYNnZiMLiivoa9sRy3JjpqUzcoQHfA2eep6JPuNwR7+QIQi6DYV 3GOw== 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:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=LxRnWtX4qUj0xmb6YCqFrz48EF59MJUBLCRl1nRYyjQ=; b=do/CJS+zdoOS0JSmcweWcbyiz60FyGdaLATiSA+wTmkMCPf0rncAuPh6a67P9pDGRW pVzwLcPUwliTykcP8tovPFPjPIEh/IoY0qAQhaMRPO5DJz0cnWjrAfm0MZil5W5gAheR U2Pf8vbKPw1Obz8PkCZ3PsVzhg/4me74lfCiLC0474vtyKUSw5OosnaYdijrhslAeiOz mZRa+YGjX2UWd5jxIXKhrkpOXO2v5dpmJ8jdgX3VjV3FyKps1MFCgZ/Hh/usDiNknE+p +MLthEoqE//vDJjZ+dT4XTXr8JVA89VD2zWfCsrkH7n/aaf6syKusobdqJdC8UCVu5mO tgEg== X-Gm-Message-State: AOAM533821/TO+SCbrPyMMEAPkJT8B7wootRIk7lUqBOXT1/sySVnpXn T2Plkbp2QfKUzTvZibNVhnKNRbxM3XDiy8KIy/0= X-Google-Smtp-Source: ABdhPJwLuy5wPUlL1gSbZSpYwGEtiESMZ5lTc/oefT2Z2dkh+zAqLi3lp4McBUfnhWEGVlhdjFW4rws6SGqEMYpfC8Y= X-Received: by 2002:a92:bb0b:: with SMTP id w11mr20573028ili.238.1593822260050; Fri, 03 Jul 2020 17:24:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: noloader@gmail.com From: Jeffrey Walton Date: Fri, 3 Jul 2020 20:24:02 -0400 Message-ID: To: trutkowski@netmagic.com Cc: IETF SAAG , Glenn.Deen@nbcuni.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] Anticompetitive use of trademark and IETF activities X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 00:24:22 -0000 On Fri, Jun 12, 2020 at 12:04 PM Tony Rutkowski wrote: > > The term =E2=80=9Clet=E2=80=99s encrypt=E2=80=9D is used countless times = as a generic reference in the IETF, other SDOs and the marketplace. It is = about as generic a term as exists today. However, it appear that the ISRG = is attempting to claim the term as their own in the marketplace through the= US Patent and Trademark Office coupled with complaints about alleged infri= ngements. > > https://www.theregister.com/2020/06/10/lets_encrypt_trademark_complaints= / > > This is preposterous and an abuse of the trademark and standards systems = to create a marketplace monopoly. > > If you use the USPTO online system, you can see the full history. > http://tmsearch.uspto.gov/ > Click on "Basic Word Mark Search" and enter =E2=80=9CLet=E2=80=99s Encryp= t=E2=80=9D > > This was originally Comodo=E2=80=99s mark filed on 16 Oct 2015 and abando= ned 25 June 2016. Thirteen days later, ISRG which exists as a tax-exempt, = non-profit corporation for advancing "educational" objectives, filed for th= e mark. > > A considerable number of entities have used the term Let's Encrypt in the= marketplace for all kinds of purposes, including as a political movement. = Google Search finds about 6,840,00 of them going back almost 20 years. > > It is found 447 times in the IETF alone for advancing all manner of activ= ities without ever disclosing a trademark assertion. > > For the ISRG to threaten some other company for using the term =E2=80=9CL= et=E2=80=99s Encrypt=E2=80=9D with the arguments at the end of The Register= article is beyond inappropriate. The term is generic and used by countles= s others in the marketplace. > > Lastly and most significantly, the actual Let=E2=80=99s Encrypt word mark= =E2=80=93 Serial Number 88828174 was just filed on 10 March 2020, assertin= g first use in commerce on 24 Feb 2020, and is just being published for Opp= osition on 7 July 2020. > > Interested parties should file a USPTO opposition. Those representing th= e ISRG minimally owe the IETF Trust the courtesy of filing an IPR notice. Dell attempted to trademark "cloud computing" 12 years ago but it was declined: https://web.archive.org/web/20081002195739/http://www.techworld.c= om/opsys/news/index.cfm?newsid=3D102279 . I wonder why the trademark was issued in this case. Let's Encrypt was in the vernacular long before the application of the trademark. Jeff From nobody Fri Jul 3 17:52:05 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD6F3A09B8 for ; Fri, 3 Jul 2020 17:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 SiGN9qLninnK for ; Fri, 3 Jul 2020 17:52:03 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 17D1B3A09B5 for ; Fri, 3 Jul 2020 17:52:02 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id c30so26371101qka.10 for ; Fri, 03 Jul 2020 17:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:to:cc:references:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=iuvjRGD9lX7KY/DAqPPc/jL4ipx/+ifl2U/pjPn1rUc=; b=KJmY8J41XACEQqJqKlXPiAJuk4UTFiHRCHVJgGTcrl3cPvdmGvi7qcTfd8cYS8tEYA A4XKQ5dB4vUdOrtjcWrohAciMgbfgZipbpvBlEg3r32d3een7muOIg7Ix6d16C+x74bC Qp+3FB6t9NlbOzFsaijKnMl/w/kCQr69Yp64bmmTtiaKlB2hbzzhJ05dtibTwzZ8xo2i Y/OXOJOI/Tee1Z+Ok+aM4chFfFPfxIQSBqPfWwPTth0ZnVK8knyYp+cOWUwwx7zckcqb WiIiSB+1nBsRy9JmlXqEM6lKd81XoBiu+1j/SHfu1/PkqoAqU8Rac2g3yS1KsnhckX/A i7yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:to:cc:references :organization:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=iuvjRGD9lX7KY/DAqPPc/jL4ipx/+ifl2U/pjPn1rUc=; b=P8wTemAAw9UM/Pu6inADYzR9AWDoRraOAEAyWs5kfnft/H9+u13EjLKsAhY2b87dDP I7tRhdYw4CR1BI4PYF4kbKmxP1N/yqAhHUAAcWTSNp5/uRyXSRdQ8CMEGAJ+Uy5EpGaJ zAE64TQJAGkiRnUi2Uo+HqthYL1wAHkYdo1dqwnlQyABLkL8fHn20sgB6HlURUgILC3W ntHLmGOXJiINR+Zh0UH8x70fiehB/cthaYA67OFR4xYAL0pr3D8tL879Lz55EAQ6TftP xl25kewXIrKlMyslyBoN/GKPrJP3G7VAawZaTMVJrbr7ACArLBk5R896sQU9jeh3IkSQ ubew== X-Gm-Message-State: AOAM530Q0q5d1la2F8N2O6gbjc68lbviESGYJv41/XkMpFfx6eoOuUNy UQnhTl+cugzD5XoscE6xy4Y= X-Google-Smtp-Source: ABdhPJy8Og82FvbSattrgAretLOhWkpFYjjznYvU+KUAtkP0kWNzhKxnALM+DviMF+TRFk+kMkcMGw== X-Received: by 2002:a37:9a12:: with SMTP id c18mr38318752qke.470.1593823921861; Fri, 03 Jul 2020 17:52:01 -0700 (PDT) Received: from [192.168.1.249] (pool-70-106-222-98.clppva.fios.verizon.net. [70.106.222.98]) by smtp.gmail.com with ESMTPSA id t9sm12511582qke.68.2020.07.03.17.52.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Jul 2020 17:52:01 -0700 (PDT) From: Tony Rutkowski X-Google-Original-From: Tony Rutkowski Reply-To: trutkowski@netmagic.com To: noloader@gmail.com Cc: IETF SAAG , Glenn.Deen@nbcuni.com References: Organization: Netmagic Associates LLC Message-ID: <539baccb-4088-01b1-889e-d5da268afa45@netmagic.com> Date: Fri, 3 Jul 2020 20:52:01 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [saag] Anticompetitive use of trademark and IETF activities X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 00:52:05 -0000 Hi Jeff, PTO examiners make mistakes all the time.  Fortunately there are administrative and judicial appeals processes when push comes to shove and the world collectively ignores the trademark holder and the registrant  tries to enforce it. We went through the same process with the trademark INTERNET.  A PTO examiner bought off on registration by a banking consortium for their own internet protocol network supporting ATMs globally. In the early 90s, they started sending out threatening letters. After several years of machinations on appeal, the matter was settled in 2000 when all the parties agreed that the term was generic and couldn't be claimed by anyone. --tony On 7/3/2020 8:24 PM, Jeffrey Walton wrote: > On Fri, Jun 12, 2020 at 12:04 PM Tony Rutkowski > wrote: >> The term “let’s encrypt” is used countless times as a generic reference in the IETF, other SDOs and the marketplace. It is about as generic a term as exists today. However, it appear that the ISRG is attempting to claim the term as their own in the marketplace through the US Patent and Trademark Office coupled with complaints about alleged infringements. >> >> https://www.theregister.com/2020/06/10/lets_encrypt_trademark_complaints/ >> >> This is preposterous and an abuse of the trademark and standards systems to create a marketplace monopoly. >> >> If you use the USPTO online system, you can see the full history. >> http://tmsearch.uspto.gov/ >> Click on "Basic Word Mark Search" and enter “Let’s Encrypt” >> >> This was originally Comodo’s mark filed on 16 Oct 2015 and abandoned 25 June 2016. Thirteen days later, ISRG which exists as a tax-exempt, non-profit corporation for advancing "educational" objectives, filed for the mark. >> >> A considerable number of entities have used the term Let's Encrypt in the marketplace for all kinds of purposes, including as a political movement. Google Search finds about 6,840,00 of them going back almost 20 years. >> >> It is found 447 times in the IETF alone for advancing all manner of activities without ever disclosing a trademark assertion. >> >> For the ISRG to threaten some other company for using the term “Let’s Encrypt” with the arguments at the end of The Register article is beyond inappropriate. The term is generic and used by countless others in the marketplace. >> >> Lastly and most significantly, the actual Let’s Encrypt word mark – Serial Number 88828174 was just filed on 10 March 2020, asserting first use in commerce on 24 Feb 2020, and is just being published for Opposition on 7 July 2020. >> >> Interested parties should file a USPTO opposition. Those representing the ISRG minimally owe the IETF Trust the courtesy of filing an IPR notice. > Dell attempted to trademark "cloud computing" 12 years ago but it was > declined: https://web.archive.org/web/20081002195739/http://www.techworld.com/opsys/news/index.cfm?newsid=102279 > . > > I wonder why the trademark was issued in this case. Let's Encrypt was > in the vernacular long before the application of the trademark. > > Jeff From nobody Fri Jul 3 20:07:00 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4572F3A07E8 for ; Fri, 3 Jul 2020 20:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, PP_MIME_FAKE_ASCII_TEXT=0.999, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=mtHAam6W; dkim=fail (1536-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=alKHPrgg 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 5VYyT4MvAbiY for ; Fri, 3 Jul 2020 20:06:55 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB50C3A07D7 for ; Fri, 3 Jul 2020 20:06:55 -0700 (PDT) Received: (qmail 48855 invoked by uid 100); 4 Jul 2020 03:06:53 -0000 Date: 4 Jul 2020 03:06:53 -0000 Message-ID: From: "John Levine" To: saag@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=bece.5efff24d.k2007; i=news@user.iecc.com; bh=/5Ax1XhMMqVZ9NugBHIrdFsLMXzcHtKvvnP28iIBjW8=; b=mtHAam6WzenvU4xIRlO066sVBG+NGWBWx3j4Eh+apfgASfSxLCwUCPEF93scXK/+v2z/s6HBm3B8FLCpcDfZ1D4yNPFEziPElTtooVAM86aYo19mokxmNlYNTWTbqTwkNj/nTN/UWMWMzfNZXoRl6ktGlJ5NDaih6AsihxywOnt2tTKwnbG2W2I8teCcq/gIGxI/E/xeE8nsqnQkAlPl4ZvBhrV49rXEqDtRMsn6bMR6XqLHE7ZHM2VV75Ewlurv DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=bece.5efff24d.k2007; olt=news@user.iecc.com; bh=/5Ax1XhMMqVZ9NugBHIrdFsLMXzcHtKvvnP28iIBjW8=; b=alKHPrggpzudraax8zI9BSuftsXPi7lq7h7mTd5TtP+cW5lpiA5wl+tCH5JttrJOJpjhTjMLFBVOQOSx2qoDSaf3rBkAg11OdOGrJtjl5LZqNSqmulky1jL/OazoxlDu5IrVoQGQ238PAFW7V3ccCOj7WNB/wqk7PV2Oh+htMYq9XEBJvjGX7f0Lc+dHvboNJIvC5yq8vi+YupSzxS5wXI8oe8Mdf5tuwzVcmvcRpaOgHpM7NwF2pQS1WOLDfRzF Organization: Taughannock Networks References: In-Reply-To: Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@iecc.com (John Levine) Archived-At: Subject: Re: [saag] Anticompetitive use of trademark and IETF activities X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 03:06:58 -0000 In article , Tony Rutkowski wrote: >The term �let�s encrypt� is used countless times as a generic reference >in the IETF, ... I've looked through all of the published RFCs and the only places the phrase "Let's Encrypt" appears in any capitalization is in RFCs 8555 and 8659 to refer to the IRSG as theauthors' workplace. I've looked through all of the active I-D's and find it in draft-ietf-acme-star-11, draft-sheffer-hum-app-req-00, and draft-trammell-optional-security-not-02 where it also refers to the IRSG's project. Could you help us out and specifically identify some of the 447 places it's used in a generic sense in the IETF? Tnx. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Jul 4 04:18:17 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295393A09DF for ; Sat, 4 Jul 2020 04:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.479 X-Spam-Level: X-Spam-Status: No, score=-0.479 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0Ubo7qAGBty for ; Sat, 4 Jul 2020 04:18:13 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 3F6E53A09DE for ; Sat, 4 Jul 2020 04:18:13 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id w27so2574615qtb.7 for ; Sat, 04 Jul 2020 04:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:to:references:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=PzQBX+QRoMfyVejIQFc7iz8QsI89It0XafIHedMpLJM=; b=cpjxBTDAsjyPFWFqJCA8ta5Yo1aLht8r8Ii6K5bTO9OM2N1L+ey9qXkyIojrcSz/Yt UUbFluMp9bh0OtESPEpWIj7YB8R4CoyY97fcvs2s8gefnuwDcm3JgWxnLzGzquMSAgjw aWdxjOnLPVrNBweOsAgF46qzNr+d++hcXSLaiSVFlUXukLNgoHF6eTdaRRcKz25FfAEC Ql+JnYfkboaZEEgpaUGKPHrcSo670PHCssuvjXJ1cItY1rryWETEan4OK+sCrjxHfNKH DpN7sC+NtV0ZsGTV+A8xgO2+s3GYmK3anaNvBcyUVkAMVap9twmRNeijdvXX23SkL/m2 9Ebw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=PzQBX+QRoMfyVejIQFc7iz8QsI89It0XafIHedMpLJM=; b=rC2vlPMyq65gaIjw9qb3mAx/C8JGvbHWYek3+Zi8/MYkysgC1glkh5muxLa2Iah714 Nypek4MRB8K10TdI1oBKswe/X012RmIoYfHAM+kwU0vZHlP/MQfaN9x8ODvHWUnqA5S1 FsE0lXZiKEqz8IsXXcjdNxl+bCH1gTe5KUofxKLByXzVislUdvPCzebV/NlFSl7f94Mk iNSd8Vki8v+hyZHRo1tgJoaMtK3AwTBVXgFhIDRaG5An2zuCLCuUmg3uy1WIqZfsqJV3 EeoOqTJULSizneN7LfCaPZVQrLL3KPHgGWRDBp5TpZYGSJ7Ebf91YO7nuOlqBrRaNVCK 2rGQ== X-Gm-Message-State: AOAM531TsGzkSN35uRr9kYwXw32LwYT2QFUwxQU1+KpFE8XiGRvCogLM GQmGvnVZE8bomW9Z8T0KMSGAz0bD X-Google-Smtp-Source: ABdhPJyGnJFpzV07AtdfPFJxcQwA/ABKzeOgpOgZ0FCKd1H7l6W3PXRt55ZxAitPrSGBlyN84EImeA== X-Received: by 2002:ac8:7a7d:: with SMTP id w29mr12390796qtt.182.1593861491950; Sat, 04 Jul 2020 04:18:11 -0700 (PDT) Received: from [192.168.1.249] (pool-70-106-222-98.clppva.fios.verizon.net. [70.106.222.98]) by smtp.gmail.com with ESMTPSA id d13sm12973502qkc.105.2020.07.04.04.18.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Jul 2020 04:18:11 -0700 (PDT) From: Tony Rutkowski X-Google-Original-From: Tony Rutkowski Reply-To: trutkowski@netmagic.com To: John Levine , saag@ietf.org References: Organization: Netmagic Associates LLC Message-ID: <0ef663f2-bdfd-8fe0-b6b0-07a312a3abf6@netmagic.com> Date: Sat, 4 Jul 2020 07:18:11 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------50C1C00F97D1805AF8A3A18F" Content-Language: en-US Archived-At: Subject: Re: [saag] Anticompetitive use of trademark and IETF activities X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 11:18:15 -0000 This is a multi-part message in MIME format. --------------50C1C00F97D1805AF8A3A18F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit It has plainly been turned into a generic slogan via the IETF to dominate a marketplace and put other companies out of business through what are generally considered anticompetitive practices. There was never an assertion of trademark. This is a matter to be pursued by competition and trademark authorities and the judicial system, not here. --tony On 7/3/2020 11:06 PM, John Levine wrote: > In article , > Tony Rutkowski wrote: >> The term �let�s encrypt� is used countless times as a generic reference >> in the IETF, ... > I've looked through all of the published RFCs and the only places the > phrase "Let's Encrypt" appears in any capitalization is in RFCs 8555 > and 8659 to refer to the IRSG as theauthors' workplace. > > I've looked through all of the active I-D's and find it in > draft-ietf-acme-star-11, draft-sheffer-hum-app-req-00, and > draft-trammell-optional-security-not-02 where it also refers to the > IRSG's project. > > Could you help us out and specifically identify some of the 447 places > it's used in a generic sense in the IETF? Tnx. > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --------------50C1C00F97D1805AF8A3A18F Content-Type: multipart/related; boundary="------------7159FAABAE894770A75197B4" --------------7159FAABAE894770A75197B4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

It has plainly been turned into a generic slogan via the IETF to dominate a marketplace and put other companies out of business through what are generally considered anticompetitive practices.  There was never an assertion of trademark. 

This is a matter to be pursued by competition and trademark authorities and the judicial system, not here.

--tony


On 7/3/2020 11:06 PM, John Levine wrote:
In article <f74a94f4-8936-1bd8-369d-e2d86b996373@netmagic.com>,
Tony Rutkowski  <trutkowski@netmagic.com> wrote:

The term �let�s encrypt� is used countless times as a generic reference 
in the IETF, ...

I've looked through all of the published RFCs and the only places the
phrase "Let's Encrypt" appears in any capitalization is in RFCs 8555
and 8659 to refer to the IRSG as theauthors' workplace.

I've looked through all of the active I-D's and find it in
draft-ietf-acme-star-11, draft-sheffer-hum-app-req-00, and
draft-trammell-optional-security-not-02 where it also refers to the
IRSG's project.

Could you help us out and specifically identify some of the 447 places
it's used in a generic sense in the IETF? Tnx.



_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--------------7159FAABAE894770A75197B4 Content-Type: image/png; name="cmncicmoofmhcmle.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="cmncicmoofmhcmle.png" iVBORw0KGgoAAAANSUhEUgAAAW8AAADTCAYAAABOQ5KuAAAgAElEQVR4nO2d31NUV7r3vch/ cN4r7/o/OBfncGllcsrJRXLmVMnVCeNLccBz2pNxQAW7QO1iQIITdETTDjKIE6AM9oRxIhkN Qd4hBgsTYytGVNRYCEqABpFu5Df4fS/2Xrv3797dNHRv/X6qVlnSu/dee6+1vutZz/Os3Zuw jiwuLmFmZhbPp6YxHn6OkdEwhp+N4cnwzxgcGmFhYWFhSbJsSrVgv5ydw8TkCww/G0v7zbGw sLC8riUl4r2wsIiJyRcGi/rpyDjCE1OYjsxgdm4ei0tLWFlZxatXr1JxWUIIeWNZk3jPzS9g dHxSI9ijYxOIRF9iaWk5VXUkhBCiIynxXlxcwnj4uSLYQ09HMfUiQsEmhJANImHxnnoR1Yj2 dGSGbhBCCNlgHIv34uISfh4NK8L9fCqC1dXV9awbIYQQCxyJ98zMrCLaIz+PY35hcb3rRQgh xIa44v1iOuYmmXw+vRF1IoQQEgdb8X4+Na0IdyT6cqPqRAghJA6W4q0W7pmXsxtZJ0IIIXEw FW+1q2R2bn6j60QIISQOBvFWBydpcRNCSGaiEe/FxSX6uAkhxAVoxFvkcTOrhBBCMhtFvMXO yZGfx9NZH0IIIQ7YBGjdJdyAQwghmc8mAMpLpp5PRdJdH0IIIQ7YNDe/oLxkiu8qIYQQd7BJ vI97OjKT7roQQghxyCZhdfO1roQQ4h42DQ6NYOoFfd2EEOImNg0OjfAXcAghxGVsGh2bSHcd CCGEJMgmboMnhBD3sSktLpObAXg8Hng8AYQAhNu90v8/vICwfIjytxOh1Fwz3IuGEx3K+QEg dMJjuC7ZYEzaRd8flHZKVV/QVgAXPvTA4/Hiwmj8um3o9ZMigkftVWj+0eyjfgQP5GFrlvw8 385D8KdUXJOkg6R+PX7NbLR4hztQaCLSFO80Y9EuGSHeFnXbsOsnSf8fs+DxeBC4qf9kGME8 +TlmbUXO9hzkfFCFbuYquJY3Q7xHL8BL8c48LNplY8U7sbplOuJZGcU7hIDHA4/Hh46pdNSM pJr0iPfdBrzv8cCzPYhhAPjhiDQ4D3RDGAIbId4pd82QxLBol0iXX2qX6l4sABg+L7XT+439 aa9bphNfvCWDibif9Ij3Qi+qVIMTT6WBoh6c9sIawaOvA/B9sBVZHg88nixs/cCHwNePoF8F KlabpsgdWF4BeNt1wzPyCB0nfMh5N0s+fguyP/SjuXvYcH4nhHub4f8wG1vk62/Z5oX/016E V0yOle/b2x5W6pH9tvS9rHfzLL8HAFgJI9Tu4LmohGn4aTeq8rbI9fIhcPlv8HviLOPF999r QL/ufGFEEPrUjzz52VnV2bZdngSR4/Egp3VYOlie3P1dzp++/plnvZsD34kLCBmU2Oi2sK2b zTXs2tWmpvZuk3Avmg94lT7geTsb3gPN6NXfh2gDXfG2d8mibfaZw2nJab8CoJkkZvvRXCh9 J+vdPPjPP9Kcs1fVTzxvZ8N3ogOPZu0mIKImPeKNYQS3qwYnQjji8aCqZ0E5wlK8Z/vRUCBE NQtbP8hBznbVIC1oQL/qB4D6P81Bjuh0wte3vVklOlkIqIM7Ty+gMCs2UCTfoOi0HmRX9yYg 4MPoLs9WBsuWbTnI2Z4TCxht86P7qfYbinj/IQDf26p7VNUh6wO5/prnEkLgA91zUX9nzwWI p60M9O2FKNwWu8+tWdlouLuA3mr7wS3qqEy2ingH0FCyRRFLdbt4tgUQctou8uSu9IenF+D1 5CD4xMkzX0DoRLauf+TExC9LH6Qziqdt3ZJs15io6UXJWryHu/zI9uj6omJQZMPfNaw6TTeq VPcp6lTV1YPm7eq22ILs7eIzB+L9tBv+bULw5e9q+qK2XWP36UXhnizl+WW/nRWbfDV9VT7n ti1KPwmUU7ydkCbxjo+5eEfQfUC26PYE8UitopFHuCAPqCxh0QscL4EX0PtxFjyeLBSeH9Z+ pIj6+2i46+we+hvlAb7tCLrVF14Jo/ePedIAyAtCfSXlvs3uUTWxaK1Qu+cSQkAefHmfD2uf h8cDz4dBDAtLUf53ofeIVDfT5yUCX3kxMdVYfdk4or7ZyCME98h1U7nFNN9LpWviSRB5YrLQ XCwSE/WSDlU9LMTTpm7JtGvC4n23QRZu3fMEEO4NIC9L1wbiKil1m8SCnFtK9P0qZkRl7VFn 5MTu0/PeEfQaLJ0F9Fab99XIg2DMcKJ4x8Vd4i185e8d0c32MgshBN4z6dSORUI1kAyWEzDc moMt23Lgax82fqgn0h1zP5icK3atLBzpNVlxWASWhltzpI7/R5XtLbsZPFlV6DV7LncbkP1u DnI+lsVTEdssiwESQsBCHBRxVIuTSrzzWk2ezWwvqrI88Oit5/UQbxEM/4OJRC30oiprK3K2 NyCkuDYSFO8k29Uas+tH0H1AXv3ojQjxLbmfZH2sNVRSKd7KJP5eACGzW1HaVW3QxMTbdOUm +o9FX13oqVKseoq3Pa4SbyFcdoErkSpVeFHVcRyLRGzQZJcHEXrqZPCZs9BTBX0QVk/4YqFB iJX73mOeXyy+o3kuckAvy2ngVRHbQnRYPJD++ve11rq41ud5xoGpnM9vmXoWOpFlFKP1EG8x wWflIdD9CJG4TZiYeCfbrgldX8SEbJ6nksqYFdC40FIp3qE/SOfKMZuQZfob39eNSXEdnTtS VFs8G8u+2o+G9yjeTnCReMd8sZI/1aIIn6C6cyQgEgs/NiBHtXSTAkQNuNDrRAhiiIlG8VWa FeHnSyRFUliWqs/FgHUcgFLE1mYgCxHULP+lWIVhVaD40PWughim97UuGR1hdMh+95jf24eq zzvQbzoZJybeybarXX0N1xcrKZV/2liED1tb79SJt6iXvYgqmUHKZBbzeZsFYOP31TA69lC8 neAi8Y51JkdlLSIR7kWzeieaUrYgr7oj5iO2wTxjwaJkongrFpDKdSIEPQnf9caJN6BkI23b YnjWWe8WovlHde0TE+9k29Uak+sr+yCclPSKt1JX5V7XKt7MNnGKi8Q75tLQuESckLRILCDy Uwgdn1dphEDvZzRDLCedLZ1jZI54x1wkwnUi7kmdFaQ5n/dCBljeOmaH0d99AQ2ayVjty09M vJNtV2tMrq+4fgLGrKI4pM3yVpIE1iresXFO8bbHReKtGjiJbqpJkUhEeo9Ig8rBAFA6dYLX TEa8lSCm1Xf0gTqH4q0El7YHMSws8awjMMThlPNVGT+TET7v5GIRKWJlGMEP9eKRmHgn267W mFxfHRRNcMt8Sn3ecpvZ+rzrrXze5nVXAq30ea8ZV4l3zCKxyKqQB8KWbTnwJyMScq7s1m0N 5haPU9EDgKkO+AxWnpoFhE68j6x3c5DXGDtbMuId77koEXyRIuf4PlTC0iP5YU0HnSp7xWCV A6qshGSzgJzT/6nkc/Z9bR7pM1p+CWabJNmu1phnm3SUSPU0zd4BsHAzgPeztiKnQJ05k65s E3XWkr14x802uRmQDSSKdzzcJd4Io0PkDBcEtLvMViIINco5tll+dJsF1DxH4nTcWF5r9ole RDS+7ViesCFf2ZQF9P9R5AP7ceFBRPPZ8Nd+JY9XnTeelHjb5Xk/7ZA3WbyPwM0F3fNwsIL4 2ic9j23ZsMxxV+d5ZxUiqL5XVZ73+ydC5vn3cdvFOYrgZBXiwhOd4ih58upnHke8DXVLrl2t Mb/+wo8B5Tz+du1OxoUnHcrGmWxd5pUyORlSDDc6z9tq1WCf5+0Tm6ko3nFxmXjDfCehendb Vk5MpBRE3rLIVLGwJAAs3G2WN0B4oI722++es2JYk/kgdr0pu/08W+C7qB1kyYm3/rnod8Jl Ia+xPyaciawglCW8J7YdXo9yPnlXnXKvqp2ve4J4ZLC0nLeLc8Ka3Y9KZpISs9A9C8sdjnZ1 S7xdk9phedEX26EqsltUsZctJR2GGENsn4DUB3znY7uYLcVb96I4DWvYYWnp8rHZYZn1gQ+F 25NzGb1puE+8AWAlgn7Nu03Euys6tNaBioW7zaqgY5yt1uEQLpzwaQdKUu+tAIAFwzswLN9P Ee++AWvxBmLvoFDqvQXZH1YheFN3oUTEW5WiaZlfrz7fShi99T7VNm2rd2DIZ0+kXRwTwXB3 M/wfqif1rcgpCaDjgb4m1uJpX7fE2jUZ8QaAhVHdu03Ee3bMLwJgGN3VquCsIZCYoHgD0s7R z6u07zYp8KPB9t0mccTX7N0m9b0Ir4h0VIp3PDJWvEmmIMTbyseLBCcDQuwQ4m+9gYxIpOeX dIh7EAE6u6AixZs45ccAtm7LQU5lt3l/EgFNKxcdUeBvWBIjyouqwuj+OBuWWSQCijdxihJD yUZA/9aqqV7FF65/LQMxwl+PJ0Z0O/w0r5M1g+JNEmC4vVATq3ISiCVGNg0OjYCuE6JhtENO 2dqCvANBzfvRzY+neJPEiDzoQENCgViiZ9Pg0AimXvBXSAkhxE1sGhwawdDTUbx69SrddSGE EOKQTaPjkxgcGsF0ZCbddSGEEOKQTXPzCxDW9+rqarrrQwghxAGbAGA8/ByDQyN4PkXfNyGE uIFNALC4uITBoREMDo1gfmEx3XUihBASB2V7/NSLKAaHRjDy83g660MIIcQBmneb/DwaxuDQ CCafT6erPoQQQhygEW+1+4Tb5gkhJHMxvFVwZmZWEfCZl/G21hFCCEkHpq+EfTEdVQR8dm5+ o+tECCEkDpbv834+NU0LnBBCMhTbH2NQCzh94IQQkjnE/SUdtQuFWSiEEJIZOPoZNHUQc+Tn cW7kIYSQNOP4NywXF5eUPHCxlZ7vQiGEkPSQ8A8Qi52Y4mVW05EZvk6WEEI2mKR+PX5xcUl5 mZUQ8akXEf4iDyGEbBBJibdgbn4B4n3gooyOTSASfUkhJ4SQdWRN4i1YWFjExOQLPBn+WSPk T0fGEZ6YwnRkBrNz81hcWsLKyirdLIQQskZSIt5qXs7OYWLyBYafjWmEnIWFhYUldSXl4q1m cXEJMzOzeD41jfHwc4yMhjH8bMxgobOwsLCwJFbWVbwJIYSsDxRvQghxIRRvQghxIRRvQghx IRRvQghxIRRvQghxIRRvQghxIRRvQghxIRRvQghxIRRvQghxIRRvQghxIRRvQghxIRRvQghx IRRvQghxIRRvQghxIRRvQghxIRRvQghxIRRvQghxIRRvQghxIRRvQghxIRRvQghxIRRvQghx IRRvQghxIRRvQghxIRRvQghxIRRvQghxIRRvQghxIRRvQghxIRRvQghxIRRvQghxIRRvQghx IRRvQghxIRRvQghxIRRvQghxIRRvQghxIRRvQghxIRRvQghxIRRvQghxIRRvQghxIRRvQghx IRkh3ss/PcDLpj/hxR4vJv7jHbz91+34n3/48af+IB68GEx39QjJCO4PPMDxQB1y871rKscD dbg/8CDdt0OSIHSzDwfLDyE335t+8Z5r+wzhf/tXTfmXc9lK+cVf/y9aH/w93dV0JbOzszjb +hfs3LU76YG+c9dunG39C2ZnZ9N9O288xz9Zu3ArAv5JXbpvhyTBnn1lShumVbynDxYrgh39 fTmWf5KsgejSS9wY70f5d58oIl7c8/v0VHJ8CgV7x7C5ORL7U+c4Nu8dw/E76amSU862/iVl g/1s61/SfTtvPKIt1mI13x94oJxnPQlfrEJBvhcnuiPxDx69hMp8L3Lrbq5rnV4H1G2XNvEW FvfEr36hiLYZN8b78fZft+NfzmXjswdfprYSq1GcOjCGzSUTuLpgcYyLxdv7G8niHhp+mvQ5 hoafKha4c26iOd+L3PxyfPUszjH7LyGcdO3eLFIluomdZwk3TkjHN4fsjnuM9mIvcvOrcGUK mO4+hoL83WjuW4p/CYq3Y9Iu3ss/PVAsbjvhFtwY71dcKKn0gS/cmMA/7x3D5r1j2Htlzvwg F4t3egY7EBNvL3L3X0B41eYYirdj0taeP7ZgZ74XBSeuw1KK70rH5B7+Bgk72Cjejkm7eL9s +pPiKnGKcKHU3wmmqBaLuNowhs0HxvFh1Rg2/34K42aHvUbirXeFWP3d6nPnqMQ734vKv41a H0Pxdky8dnC6wkq8PQfQusuL3B0B3LBYoT5qklZ5db0OLG09FG/HpF28X+z+H8dWt0BY3//9 /w6mphLTL7B37xh++Zcohr4cx+a94/hsxOQ4infy4l36MY4WWrlPrMR7Dk8663G4cJd0Xe9u HK67jCeKOScLSekF3feG8ZXPi9ziNmibcRRflXqRu6sFj8Sfxq+jtXIfdu6Q7qugsAqNnY8T txg3mHjt4P3NbvRc7V3zecwY+fyAtTiv3pHFvR735FVW+Mtyc1fLxHW0Vu5GQb4Xufm7UHq4 Fbf7LpiL9+oEbrd8jNL/ldvpfw/gaMt1TOtXcqsRbZ/ZIZ93wuRGliZw+0wViuVzGvtXZpN2 8Z741S8Q/rd/Teg70aWXiuskFSiC/QSKQP/yXNR44Bsg3omeJz4xYR7pa8Rv870oKL+kc5+Y ifcc7tXtRm7+LvhrW9HVeQltteXSQC9sxD3Z6rtX50Vu/se4Nq06nbDe8svRpTb0p7/B0Xwv CoQwPLuEyh1e5HrLUddyCVe+bEXdfmnQ//b0HWu3QAYQrx3E5w1nmmyzg5Jyvwy3oTTfi9za q8ZnJLtVdp6JDQhT8Z76Bie8QrTr0Xy6EY1V+1Cwwyu1sVq8V0fRVe5F7o59OHqyDVc626Rj RV9SDhzFtRrJ6t/pD6C98zLaT36M4h1e5O6oQpfaaBDnjNO/Mpm0i/fyN/+E5a63EvrOzPwr vFP1Ev9+JBVT5Aw+qxjD5qrnGAIAzOFi7Rg2l0zihn5Wp3ivSbzDWMK909Lgqvxy1OIYidmr ARTk70ZjrzZDYfb7euzM96L082EAwNLVAHLzvWj8PnbMdGcVcmUR0FwnVI+CfC/qrkqSc++0 F7n5+9D2UHWB1VF8td9kQsgwnIp3br4XB8sPWbpRkvOdR3Cl0vwZSZPpPrQ/jv3NKN4i8Lkb jd9r40vhL6sM4j1y7oC0YhvWThXhv5VrVgDTXR+jIN+L0jMD2pWTmKR9qpVYXyMK8r0o/uyx 6TmPdjnIjEkzaRfvldA7WO56C6+ifY6/0/dkBe9UvcTulvm1V+D+JH65dwwFnbHmjlwJY/Pe MRy+sag99g0Q73VzmwhhXriD5kK9JaQX7wiuHTZze6iOFcEw2Zre2TQgfy5/t/YSug5rg2Yj 5/ZpBEcSGp11DgCzEcxOz2HJNLiaGSQi3rn5UoaQmRsl2cDnbNfHRpFbuI46vUjCRLxXb6J5 h0X7GnzesmvMzMqXj5XafhRd+6198Y/O7EZu/m603pX/EKo3MSIALM1hdjqCWVre8Vl9/Dss d72Flbt5jr9zuH0B71S9RKBzMf7BtiziauMYNu8N46Lagoi+QNneMWyufQHN/EvxXrt4A1gy uE/0x2iDnKZFOVYetEIIFq6iTraupzurkJsvBrN8nEk9cr37cLTlMu49nsBSJvtKVCQq3lY+ 8GTFWxHqyssQQ2epN2Bc7cBEvO2CkvrPFBeYTam7CaXPlF+C6YJJiPVF2fktjAjZ136l7zHC sy5pfJm0i/eraJ/iOnFifQur+9+PzGJ0+tXaLr7wAr8zE2krUX+NxHvjzmPmz9a7TyzEu7IV N76/jttm5cdRxRJTW9SSgMjWtTzw664uKaJefE67TMb4dbQd3icHzaQAV6ULglaJiPeBlLtN gJjrQ8rlNv4/RirE+7cnLpn3g++v4/bjSPwsFTNLe0kOgnpVKxR/Pa48tEgVzjDSLt4AsDp8 HMtdb2H5m/9jK+B9T1bwq6OzeKfqJT79dq1Wd8w9Yld+/eXL2Bco3ikSb+jcJ9fNxdtp6qCc V1x3dU5yheis8oK6m7KPU7Vs1rO6hNnhAVw5I4JWLXj0GrhNGho/TX3AUiAHJyu/HFUmRzP3 Rkos77ipg3Es7+8t3CQySzPDeNTZAr/Xq3WvZDAZId4AsHJ7myTgXW9h5e5/KSI+M/8KfUMr +P2XkqtElP8+PYeZ+bVY3i/xWdUYNu8dR9lnkzhlKBP4dckYNh+YxB0xiF8j8bZdhq6z20QQ c59USQNUOUa7Qy8usg9155k2tO7SDtCRc/uQu6sFX322T5O+hqVRPPr+Om7fN+aQPflsnyQ2 zsMwG068dljPVMEYsj96/yU8kn3gZumDlj5vnwOft5gUdsWbTBPxeS8hfPc6bn8/YEw1fNiK 4nwvCk5n+IBGBok3IFvgsgtFFLVgCz/3joa5tQv4yHP8eu8Y/rlxGuaxiRXcOSdZ36fur0h/ oninVLzV7pNc3TFiwO88eR2z6gG2GsHt08fwlWZpu4QbtaKu2kwHPG5Dcf5u7DQEvWTh2VWP 2zrD1BDcykDitcP6bdLRIuV878ZvC73ayVGFWaqgeMbxs02W5JRRLyr/Oqw98dIwvjpajxvy /Ktkm+gySMyyTaSNRMbrK6mOSgA8c8ko8QYkH/jq499JWSjf/BPeqXqJ/wzMItC5qPi4Z+Zf rVHATYTZDL3Av0bivXHnieMCUQJHumNWR9FVKeVcF+wPoO3Lq7jyeT2O7pGWtc3f61IIZctP swEHgCLS+cb0r9lQvRywLEfd55dx+8oltJrmD2ce6WtPHSLnO1+b263GNM979qYSMPTXNqL5 dCPq/LtQ4N1lzPOevYnmPdI1iqvq0d55FV0tAcnFsaNKlUIYy/NWjjttkeetuX4brnyvO9bc u5JRZJx4O2VNAr4wjcMlY9hcIXK7rZBzvkXg0sXincoXU3l/k8SLqWz810rWh/4Yk91yxZUt uD1ukhWgSRvTIllZJimBAGbvX0ajZodlufnOvQwjY8RbyfnWrXhU2O2wjAWLxU5IOf6h93Ev aXdY5np3w197CU/0Dm6zHZa1bbhntsNyegBX6rQ7LP1WuzEzENeKN5AKC/zNga+Efb0QbeGG V8KS9cHV4g1oBTwlm3ZeU8SPMQgLPJni/Q1/jCFTSOWPMRwoP5Tu2yFJoB7LrhRvQBLw3S3z eDSW4WtdQlLE7Owsjn9St6bJODffiz37ytbkSiPp4/7AA+XXdFwr3oQQ8iZD8SaEEBdC8SaE EBdC8SaEEBdC8SaEEBdC8SaEEBdC8SaEEBdC8SaEEBdC8SaEEBdC8SaEEBdC8SaEEBdC8SaE EBdC8SaEEBdC8SaEEBdC8SaEEBdC8SaEEBdC8SaEEBdC8SaEEBdC8SaEEBeSsHhv3jvGsk6F EEKcQvHOoEIIIU6heGdQIYQQp1C8M6gQQohTKN4ZVAghxCmbJiYmwMLCwsLirkLxZmFhYXFh YZ43IYS4EIo3IYS4EIo3IYS4EIo3IYS4EIo3IYS4EIo3IYS4EIo3IYS4EIo3IYS4EIo3IYS4 EIo3IYS4EIo3IYS4EIo3IYS4EIo3IYS4EIo3IYS4EIo3IYS4EIo3IYS4EIo3IYS4EIo3IYS4 EIo3IYS4EIo3IYS4EIo3IYS4EIo3IYS4EIo3IQ6Y/OEsav4+lO5qkLQwgoufnMW1qXTXQ4tr xPt2SxmKSo6hczzdNSFp4c5ZFJWUofpyeMMvPXfnLEpLylDz9QiWN/zqJFWMXT6GopIynLmT 4BdXw+g5VYGi8rO4PbcuVUuK9Iv3yCVUlpSh6NAlDNoc5nrxHu9GdUkZiiyKQZSWpxA6fwrV 5X75GD9Ka06h7ZbF9C+Lm1VJuMNmGukS79Fu1PjKUNr22PDR3GAPzhyvQLH8jIvLj6H+8mNE V52fPvqT9hxF+2tQe74Pk7pZQur/8Yvr23kdSVq8AWD1Mc6Vl6HoWDfGEmjf9STt4v2wrULu eBU4d9/6uMwS7zA6a8pQVHIWt51+5W5QHpzVOHjIWE5eVYny3ADOHZYF4dApnGkNornpFA76 pL/VmAjY5D8CsoCYn7/N5tm6AgvxXtOAjEsUPSfLUFR+Hg91A3b5bhClJWUo8vlR3RhEc+tZ 1B6SJtriU9cQdXD2saunpXOUVqO2KYjm1iDqj8qTdXkQ9xZjxz7rlT63KrUVZSgqqcEXIyl9 AK8Va+4r98+jtKQMtVedtO76k17xXh3AOX8Zij6qkazvln7LQ10v3rck8an/If7CW0xohmW6 bAUWlZxCj67/jH1dg6KSanzxurpl0yHe8mCt+VY/WEfwxUdSf7w4qvrzahTXGuMbIgCA6DWc 9JWhyH8WIUNbHktslbHYh3pfGYr+3Ee3jg1r7ytRdB8vQ5H/PO5lgPWdVvFeDjVJIvVtWOr0 viaEFs2Pdbt4i47TfDfekY+lCc13FrdNOkioyXx5LD2fADonHVbIbWy4eC8j9OcyFJU04Zq+ T452SsZG4w9GsXwoCX5R64D96eX7OdhuMtuK89sYM2qe/b3G2YTxhpOKvhK9ekoywkLpnybT KN7y4JAFWwi51ZJEEe/BIXS3BFBaKvyMAZzptQgkRR9rji0qrUBNSw8e6i8h/NE13RjTn0P4 klv6ERNtfYkv4pI17WTyGUFPaxDNlwZMl97CKtdOAvLyPpGVgI7Y8x1Am/DBqgVI/ywtfLMA sDzZh7aTNSj22Rzr+Jlr/ybEWwxEW5+v0/Y3Q1izJ01cILds/O+rfThjdV9qlucRjUYxZ2as yBa/mZ/deD2xer2EZ/GPBrCMyVA7aj/yK8+s+KNTaAtNmY4hfVsWlwdw5ltzv77kv6/WHTsE sxifoz4CxPpJS78uxuBH6fHzCJmFgFaleNHBUm09Bi3E23Fd1PUxm7g3mPSJ93QPatQDVHTC 4z2moiUCNsWlZSjafwz1rUE0Nx5THrjBDzzajZpSqZEPnjyL5tYgzpyslhq+NIBO9XLXsZAs Y+x+H0K3enDmkOS+aLvVh9Ctobg+TmEZn2k7hcr9opNUoyZo0UlMkZfrhhWKPKmUn8Y5zcTm PIAm1a8CpeXywDhUjYNtsniLZ6n4d1W+WTdsKloAAAiwSURBVH0A52G75Jv3CT9uzBesOXaN 4r08OoDQrT50N1VLk/4XfQjd6sPgtHz89DWclNvfUGcnWQOyBW1mGYuJw9zQ6JfE238eD+Nc wsDqMiYfduNkucM6QmUJ/jDv6BIPz0vPq6hCFUspNR9Dc3eCUluWGtuytKVfI8pjvXr//VnZ D288VjmvWX+qCGrvW/ST8gqUlvhRerxJ26d0sQGshtF5TIwvnU74TCZ4p/1VYQhfHEqyfVNM 2sQ7+m3AsNQbbK+2DLoI8S5t6dOKUbQPZ/ySMHaLgatYyBU4c0fbqaO3pLQvjaWSqJAk7DZR Wew+vxJEVGZ6hxHsuR+k1UmlQVBkwZCtS+n8sQwG/eAxQ8lmONaJZ5rJRK67v8mQ5yp8szGf 8LLs861G26D6yHmEmiq0y801irdSBwtrSupLZTj5nbb9RZ0r/24f2RMBYLMYhf3yW7RF4i41 xRI+dsnZ6kBM5k59sIs/oL6kDEWH2jGoPn5OHkNqo2CxX/pbTTsGNZ1HtKVq7E5fQ61PmnA0 /vvVKXSf1MUAxHl9OgMKy3j2tfTMNb57JUtLP5bn5b5WhjO3Yn8Vk5lhTEX7cKZcL94J9Ffo v5N+F2WaxFvudPqlnpw2aGbtSOJSow0QyYjOX/MPWV2E39E0gCN8mRU4J6bOdRfvZYzd78EX 569phXF5BBdlK8EYFNMhgpUfXdIOPABAFIPfdaPt8oBxYivXDR4LLJ+vjQWqiIGyhBTuG/1g ADD1GKFbfbg3ujHiLdxLevHG3Aju3epDaMj+eQvxNxPoVIt39G6nnDUSs/oONv2AyTiCLFyN 8Sai2IWuodZMvAFM/tSH0K0BjMniHbPoTZaFQ5dwUNUnlPFn1od1x4rzmtdZBIJVAXnRT5r6 jPcvGzOxPiH6n7kBaGy3BPqrCmmspD85ID3iLTeo0WdoHc21DVgKsZYHu/2y1qTR1128bRB5 7se6YTmRj16TltIGayU+YoDHC6BZPV8r37KmqJ6b2NAiLYnb0fndYzybMxGAdRbvWGaO5Db7 4tsBDE4591KKlchGiLeWedxuqbD2qSvIY8XXhGuON47Ezl20/xjqz3fj2sMRmDWPo7xyuX0S ETPhnjtn4XMwTJoqn7cBQ5+wf/Zm7ea4vxruIf059WkR73vBirgdwzybwkK8dQ0cN6qsb/R0 ine8wT7XL1nPvgAujiQRIrG7NxXxxLvypE2esS64Gn36gzYAVFKG4kNN6PxJddR6izeA5cl+ dKoDlrJonbMIzhmfh714Kys9DWvweQvEisZuQhdBzWCcrBY9q1E8+04bsCwq8eNgY7fGVSNE tubPNu3eO6I61lkmWLxjDe2ZjHhb9HWrvuKovxru4U0UbxHF/+iURac4JVmiOpeHbaOLDTAO LW+xdNsw8V6UMwtMFcNGvOeG8MWxMhT5qtF8xzogtTwXRTQ6j2WzZXaKxDupjQmry5ibHELo 8llU+tboqlpTquAy5qIjePhtO2pkv2e8+7Fzm4hsk8qvTSxjIbzxsk2c9Inydotdx8L1t8ZN OYvzmBzqQ2dTjfS8VZuR4lnIauxcmubHWp9XuLuSE+8BNPvKUOQL4p7JueP2Fbv+msA9bBQb Lt7xUgJjAQHtRhS7DiLlua7B5z3ZLWW+rJd4y5OL6TJYZN3orSwlam4MuuoRwTXTTnnfWd6x 5eQo7t8iC0hDdAAXW4NovmpcPwtXlVKPRJ95QuItp1v+vd9YZ9llZ2vVwj5gaZsu5jDNT5zf dBzEs7yFq80sjdEG4VvvMTTPshL8Eymo4rk6sextfd7jPag9VI3KL6TnkbTP25F4J+jzTqS/ xj55UwOWsp/OZIegGvHg1J3BMttk6gfUG7JNRCcwCp/i49IES+WNMZpzAFidwrXGChvxNtnA YYZYbRjSv2I+SE3HX40i1CJF9E9edbDLTuU310TYVROAs4CliXiLdzqUVKD2W/37V0Zw8U+n 0S3cOSLd08Q3P/fdaRSVqAOfCT7zOOKtFVnRz0wmvsF2Sbzj5enKE65poFbpXzVoG1SdxXKH 5TLm9Fa2aLOPzuPhnPbYZ5fsd1hKbsckNuWIidyQ3TSPa6d0fmuRQVJSg3P3dc8w2ofmT9px L6o7Vt+/Vf04lm0ijwWTPjJ22SbbxJF4J5htklB/FbypqYLCyoxnxQnLQyWwmjzkVOd5Axhs l5eOIk+1Sc7HFn4wXedR8s5rmtDc2o5QnFlYmTRMcma1HW0Z91pl8aqwci0F0dx6TZOpo3R8 8Wxam1C9X0x4TlMFLdxSSvCvDMVHm6Tri/xgnUtHGwAK6p77afSohDqhZ271YiphpZdK9628 uEsXsGzW5PtWoy3eyBN90Mq6VfKDje820T/vaK8kBEWad54s4+F53f3b5c8LxBhyvClHjS5g qctw0b+TRWlLs2eoG0PG97SoMmdaU5Dn7VC8E83zTqS/Aohl7Lxpm3QU90a8tDj18kee+CRx OYvQ4hRCQe0OS8sAVCI77FajeHi5KbaBRj52cNCi88wNoE10uNJT6HGwhDLuQDsm7eTSDFKr XZz6onfZyDvnalRvuauw3uGmJ27QyeRZVp9sR8hkh9HciC4AtL/a/Lkn8swt3yo4j3vnxSTu R636BV9TA9qApU2djdhsjxdHTPbhnK49zTZFLd89j4O+MhwMDhj66eTdbt2bCa13MAKxCS/5 lyPNGwKWUj8xv6Zx96FFW8Kkfyewc9PJDksDVn3CYoflmGyV692LjvsrYl6BN3x7PCEZjuWL qcibCV9MRYhLsH4lLHkDGZLiFHwlLCFuQPadG19JQN4oVsO4WGMTi0gDFG9C4iAFtRxm/pDX j9UpXPszfwaNEFcyeSuIk/wB4jcU/gAxIYSQFEHxJoQQF0LxJoQQF0LxJoQQF0LxJoQQF0Lx JoQQF0LxJoQQF0LxJoQQF0LxJoQQF0LxJoQQF0LxJoQQF0LxJoQQF/L/AUlpLa99c7ryAAAA AElFTkSuQmCC --------------7159FAABAE894770A75197B4-- --------------50C1C00F97D1805AF8A3A18F-- From nobody Sat Jul 4 04:26:04 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39F63A09F6 for ; Sat, 4 Jul 2020 04:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 ZsrRh3KElDrQ for ; Sat, 4 Jul 2020 04:26:01 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 5590E3A09F1 for ; Sat, 4 Jul 2020 04:26:01 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id j80so30928089qke.0 for ; Sat, 04 Jul 2020 04:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:to:references:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=miS6OcwlfPra9n6Ltj9sR2eLz/JN6z5HTzcX5Y2thBQ=; b=YZWTCJmsBfoYgOK+3Fu2ePQJqyCg5KW00BBKJMY8jDid3po+hlnZ/q6MBXLWqMWvgO 52NmwVS3ogsPmhxPKm9ewnMQuLYPIkqd3i/+B4/+pvy/pYRDWb+XBtJGHIgOJ68VJTnI 5DR1MY+H4kG5wAqT6W36HtIuZi7mMLbDpgVjNQJZ5ACSDDTkQCk2cknxxENklnfaI+JK +Yp6WTJupUA7r5ePyyz9k+j1vy7M4JTOKK3hXttqU+SiYetK80Xan3Ty/B1ZjxtkDYwl i16Pq4zF4qbakFAQxJ/YYmjDQAvQE6xz84mLMHaGLE0tOjuC76ELDae+5Of8xeJpMaxL d9tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=miS6OcwlfPra9n6Ltj9sR2eLz/JN6z5HTzcX5Y2thBQ=; b=oLLnQy0UXlK9lW9THXz7QXqk+v11tz/2Z/BBM/4MqkF/2yQOLI+RSXlN5NnIGEYWCO Y4lire+eygBR+cxo+Paj8g/FET2er+4SiXEAEjUsYZDWvUThsPYdOXXnNn9TYM1SEVFC rhsvVijKyhSOwG5XgPb8aJ3KAvT49seFnXTJEVp22udrhOy74AmmTLrCjZDjBJWKasBg 25tk1y9fcZkMnopTzCFUNzbie1y+7L/wB8tGx38pQ9WkblWbTEyZecSMkWn6XqrkIHRV gen/rfD+5gMPHo206eDl9fDyWkzDAjmnqzKDHUXz4abhK6FjNe9is0H8/1m9rchbMbRq uFIg== X-Gm-Message-State: AOAM533shAJarlMA99O22zZjHha8jUEQ0gYgQwtZ7gXD5j3833IgP+jO NT8bdFcj+nGaAmKsS/CKls1dND5J X-Google-Smtp-Source: ABdhPJwGaa4+doJEKeBrBxp+aTv/8TzTdYCR0dlseIGenaaCnPgShwMcwnMtYoa0xSl6Dd+fS3PPjA== X-Received: by 2002:ae9:de02:: with SMTP id s2mr14270018qkf.396.1593861960152; Sat, 04 Jul 2020 04:26:00 -0700 (PDT) Received: from [192.168.1.249] (pool-70-106-222-98.clppva.fios.verizon.net. [70.106.222.98]) by smtp.gmail.com with ESMTPSA id g17sm6325374qto.73.2020.07.04.04.25.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Jul 2020 04:25:59 -0700 (PDT) From: Tony Rutkowski X-Google-Original-From: Tony Rutkowski Reply-To: trutkowski@netmagic.com To: John Levine , saag@ietf.org References: <0ef663f2-bdfd-8fe0-b6b0-07a312a3abf6@netmagic.com> Organization: Netmagic Associates LLC Message-ID: Date: Sat, 4 Jul 2020 07:26:00 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <0ef663f2-bdfd-8fe0-b6b0-07a312a3abf6@netmagic.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [saag] Anticompetitive use of trademark and IETF activities X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 11:26:03 -0000 I should have added...pursued by the law enforcement authorities as well.  See, e.g., https://www.ic3.gov/media/2019/190610.aspx --tony On 7/4/2020 7:18 AM, Tony Rutkowski wrote: > > This is a matter to be pursued by competition and trademark > authorities and the judicial system, not here. > From nobody Sat Jul 4 07:04:01 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3093A0C01 for ; Sat, 4 Jul 2020 07:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=DIw6oRgj; dkim=pass (1536-bit key) header.d=taugh.com header.b=rtiaBa6F 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 Zg-iqude-z4G for ; Sat, 4 Jul 2020 07:03:58 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3772D3A087B for ; Sat, 4 Jul 2020 07:03:57 -0700 (PDT) Received: (qmail 5881 invoked from network); 4 Jul 2020 14:03:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=16f7.5f008c4c.k2007; i=johnl-iecc.com@submit.iecc.com; bh=ub0YL8izScecgreoVkeOssziA/eChw7aRopmQk/zhrM=; b=DIw6oRgjNteWpWIQbLMCq1jqmu6ozaVYrKi0E5JBGRV4mNLENAbI4wd1dRaivondJdRMZw59djTMRzApacQy6I4hN6NiIlHfBlFxYr20UEcaNDGEfI3WfDbvwDX6Z92cS5yxbuX/aQey4YjqDAhRNE803jX0VAobO3K8X1pQ8HFm87HOYN9aNO85+xkRGr4Hm7ksEYbv9xsV2UeYj8wdXQ9lkmkU0gIJRLFMQEJ7XpRJF/dCCPtr4viBv8GZf7nz DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=16f7.5f008c4c.k2007; olt=johnl-iecc.com@submit.iecc.com; bh=ub0YL8izScecgreoVkeOssziA/eChw7aRopmQk/zhrM=; b=rtiaBa6FUEld2vkIoNAXd7wwO0R3/XYSwCvWX0E77BynvEf+iPgc9oPgvaqUE5TEx83VWhCdyq3mXIHzUtHSJ1iBQMBXYp8t3nFTK/yN4Xyh5OqTbncrLi5TiQpeIFuCXCMNAToEpslPO8JWQR/Mdn7lOcDON+G1FqJ1Ty8K6Q6EzFOIkIaqLMv5wDsDJNvla5qFa/xx6Z2x0J/DExto4xYYG16X1ZUCCM62VJDTV3hAJ3tgwn8+zm5tjN2x/hV/ Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 04 Jul 2020 14:03:56 -0000 Date: 4 Jul 2020 10:04:03 -0400 Message-ID: From: "John R Levine" To: trutkowski@netmagic.com, saag@ietf.org In-Reply-To: <0ef663f2-bdfd-8fe0-b6b0-07a312a3abf6@netmagic.com> References: <0ef663f2-bdfd-8fe0-b6b0-07a312a3abf6@netmagic.com> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [saag] Anticompetitive use of trademark and IETF activities X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 14:04:00 -0000 > It has plainly been turned into a generic slogan via the IETF to dominate a > marketplace and put other companies out of business through what are > generally considered anticompetitive practices. There was never an assertion > of trademark. Hi, Tony. If you're not familiar with the way that search enginges work, they can't tell the difference between generic and nominative use. When I type that into Duck Duck Go, I see a lot of nominative use, to refer to the IRSG's service. So I'm concluding that the answer to my question is "No". >> I've looked through all of the published RFCs and the only places the >> phrase "Let's Encrypt" appears in any capitalization is in RFCs 8555 >> and 8659 to refer to the IRSG as theauthors' workplace. >> >> I've looked through all of the active I-D's and find it in >> draft-ietf-acme-star-11, draft-sheffer-hum-app-req-00, and >> draft-trammell-optional-security-not-02 where it also refers to the >> IRSG's project. >> >> Could you help us out and specifically identify some of the 447 places >> it's used in a generic sense in the IETF? Tnx. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Jul 6 04:56:50 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF233A0958 for ; Mon, 6 Jul 2020 04:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoA8W0lhvZ13 for ; Mon, 6 Jul 2020 04:56:47 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 91DFD3A13B5 for ; Mon, 6 Jul 2020 04:56:47 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 066BukW1026660 for ; Mon, 6 Jul 2020 07:56:46 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 066BukW1026660 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1594036606; bh=towWeIXqQS/VeCVLNohHOMBz4zdZHfnk5iC7g1rL3IU=; h=From:To:Subject:Date:From; b=aAxS+CArudvXEFYXatfB7FQRfTrFC1IbCw/Wx3vn+75EkkFSgzFkEBNGAgTynSReM 4n3tHh+hk3B+BOerUHRqJhkL3Q/VdRRvpr3981c2IRiuIIrg0hxIsKOxSF+UEah71M WfKelwPSvHQTY8yeEFzcjO/nqBvduP8g8BeriQVQ= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 066Bufce029611 for ; Mon, 6 Jul 2020 07:56:41 -0400 Received: from MURIEL.ad.sei.cmu.edu (147.72.252.47) by CASCADE.ad.sei.cmu.edu (10.64.28.248) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 6 Jul 2020 07:56:41 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 6 Jul 2020 07:56:40 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Mon, 6 Jul 2020 07:56:40 -0400 From: Roman Danyliw To: "saag@ietf.org" Thread-Topic: Call for IETF 108 agenda items Thread-Index: AdZTjEzm3E53rUwDQVGFnDR/hfIgJA== Date: Mon, 6 Jul 2020 11:56:40 +0000 Message-ID: <2d584d04a9b5487d9afe8201bd583fb7@cert.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [saag] Call for IETF 108 agenda items X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 11:56:49 -0000 Hello! In preparation for the IETF 108, we are putting together the SAAG agenda. = We would appreciate ideas on presentation topics that you believe would be = of interest to the community. If you can identify an appropriate presenter= (not necessarily yourself) that would be helpful. Thanks, Roman and Ben From nobody Mon Jul 6 22:19:23 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396883A0841 for ; Mon, 6 Jul 2020 22:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKiXMUTGFTI4 for ; Mon, 6 Jul 2020 22:19:20 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE9C3A07CE for ; Mon, 6 Jul 2020 22:19:19 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0675JGit016168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 7 Jul 2020 01:19:18 -0400 Date: Mon, 6 Jul 2020 22:19:15 -0700 From: Benjamin Kaduk To: saag@ietf.org Message-ID: <20200707051915.GU16335@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [saag] SAAG IETF 108 call for agenda items X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 05:19:21 -0000 Hi all, We will be having a SAAG session for IETF 108 on Thursday July 30. If you have any topics you would like us to cover please let the ADs know the topic and an estimate of how much time would be needed. Thanks, Ben From nobody Sun Jul 12 17:15:16 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F1F3A0AA2 for ; Sun, 12 Jul 2020 17:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nightwatchcybersecurity-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 nrc8QQ6pxP2j for ; Sun, 12 Jul 2020 17:15:10 -0700 (PDT) Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [IPv6:2607:f8b0:4864:20::642]) (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 4A3E73A0A97 for ; Sun, 12 Jul 2020 17:15:10 -0700 (PDT) Received: by mail-pl1-x642.google.com with SMTP id t6so1545251plo.3 for ; Sun, 12 Jul 2020 17:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oVxnwM1cOK458TjopaM1Jbl03vbGuSpm3qgQ4naFNQs=; b=i5n5pOF+lefjPJ6tyAcgN4hHk1mP1uvEtUY/P8a3vx25R1ex4VBB1jERAKYX72ql7G r2y9+nRNgWFF1UWVr+6lW4t80cNCMprK0b7MBAYXskKUWqxjZwK6j30xmCMAVH4RLn5u kG1e96l1hApNrkaG49jbKhy6r6W4FOROmjoufJ33Zk6HOLsTHCUkQSXLAVn/qW0NMUZc LUkBmdLsRFnxCzuDahHJXbJsqueIfCD/ztLuYHtKRki8lfcvwGXKMAgepggAuvpOI5Bg 65rzXDwOmoQcWn7693bJnSvWNknC2UU/SrF6Asa0QIyq/4K7XlnMeJIjZt2lHf+3OfpO 1Sxw== 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=oVxnwM1cOK458TjopaM1Jbl03vbGuSpm3qgQ4naFNQs=; b=mrCP8p9az8jyzcYMV9mZCiQiFBrThjZUleNEHbKVAQKGuUwEBo7qL0QeCfz4KzgPhp K3qTZ63rjtTVQU2y45AE/St6MEIFDwyLYbH8XNR4YEswPrEm1zDekbmymUUFY8J8DwKf XqkxUupMMJqrzRy9iJTFSUwufRPnsZV3EzOPMyHhyY/HU//5RQngu8jU51CooIkzCyWK Xraejhu4Cq+9oYxrw7E2+vzctw9eDbHuG274nAABk4jikQKD/uZLIOe1dik03eRZHFUA Yqa/jh5+cl0A1NE9yIlKRqGXCzGZI4z5gox3dmSBZd8Gba/EraQ/xtHg/9qsBBaof7LY yrbA== X-Gm-Message-State: AOAM531q7pEOISVGTXPIzVQhRNgZbmDTouejkpshVlWDej1pP2yya82t GHBzNn22Pj9Zy4d+vw2G5BTrDl9mJ+1MtadmAwICXQ== X-Google-Smtp-Source: ABdhPJxvTkWkfWMaLC3WoB6AlySZTKe7/RRQBJK5g1Xn1pT8uIa5E+jXgYB4zX/BtsAFM/m/AGXy1ZUtC56xPMYgGoo= X-Received: by 2002:a17:902:d20c:: with SMTP id t12mr68097172ply.291.1594599309212; Sun, 12 Jul 2020 17:15:09 -0700 (PDT) MIME-Version: 1.0 References: <20200630222455.GX58278@kduck.mit.edu> In-Reply-To: <20200630222455.GX58278@kduck.mit.edu> From: Yakov Shafranovich Date: Sun, 12 Jul 2020 20:14:33 -0400 Message-ID: To: Benjamin Kaduk Cc: draft-foudil-securitytxt@ietf.org, Security Area Advisory Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] results of IETF LC for draft-foudil-securitytxt-08 and next steps X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 00:15:14 -0000 On Tue, Jun 30, 2020 at 6:25 PM Benjamin Kaduk wrote: > > I'm happy to see the updates in the -09 that addressed most of the > discussion and feedback that came out of the IETF LC. What follows are my > takeaways from the last call and discussion of what seems left to do before > the document can progress to IESG Evaluation. > Before commenting on specific issues, I would like to thank Ben and all of the IETF members who contributed to the discussion of our draft. It is much appreciated. Specific comments appear in line below. > One recurring concern during the IETF LC was that deployments of this > mechanism would fail to get updated, eventually becoming so stale so as to > be harmful. I'm happy to see the addition of the "Expires" directive that > mitigates this risk, but I think we should make its presence required, and > additionally give some guidance that the expiration date should not be "too > far" into the future, perhaps capping it (at a "RECOMMENDED" level) to at > most a year in the future. (Note that Section 6.2 has a bit of text that > assumes Expires is not mandatory, in addition to the field definition in > Section 3.5.5.) > I think that makes sense, I am adjusting the language in the -10 draft to match. I assume the one year recommendation is in line with what is being currently done for TLS certificates? > Similarly, the refocusing on having the file be targeted at humans allows > for us to reiterate that human judgment is key in deciding when to use the > contents of a security.txt file vs. seeking other reporting mechanisms. > This applies for old/expired files, of course, but also to the recurring > topic of reporting compromise vs. reporting vulnerability. When reporting > compromise, extra caution is needed, and there is probably some more that > can be said in Section 6.1 (see next paragraph). > > The topic of use for reporting compromise vs. vulnerability was raised by > many reviewers, to the extent that it seems like it would be very > challenging to craft text that would definitively convince the reader to not > use the contents of the files for reporting cases of active compromise, or > even cases of vulnerability that would easily lead to active compromise. > Given that Section 1.1 is entitled "Motivation, Prior Work and Scope", it > seems like a very good place to put a notice that "reporting compromised > resources (e.g., web sites) is related to, but distinct from, reporting > security vulnerabilities; the mechanism defined in this document is intended > for reporting vulnerabilities. If it is used to report cases of active > compromise, or vulnerabilities that would lead to compromise of the > system(s) involved in this mechanism, additional considerations apply, as > discussed in Section 6.1". To expound on the nature of these considerations > a bit more, when there is (the possibility of) active compromise, the > "ambient authority" granted by finding the contents of the file at the given > domain or other location is no longer trustworthy. In such cases, we should > expect there to be an "additional source of authority" (or "trust chain") > that can give a sense of confidence in the reliability of the contents > therein. A PGP cleartext signature is already recommended and can be one > such additional source of authority (provided that there is a trust path to > the key that made the signature); other routes to such additional sources of > authority were posited in the review comments, such as putting a > cryptographic hash of the security.txt contents in the DNS under a DNSSEC > signature. I think that requiring such an additional source of authority > (though not a specific mechanism thereof) would go a long way to alleviating > concerns of misuse of security.txt from compromised systems. However, I'm > not entirely sure how practical it would be to impose such a requirement > given the current state of defined mechanisms. I'm hoping to get some more > feedback from the community on this topic, having framed it in this way -- > the previous discussion seemed focused on other aspects of the problem and > did not get very far towards a concrete resolution. At the very least, we > will need more discussion that specifically in case of compromise, the > "additional source of authority" is the only source of authority. I would > expect this text to go in Section 6.1. > I am adding this to sections 1.1. and 6.1, HOWEVER, my sense of the LC comments is that using this file for incident response is ill advised and should not be done. Perhaps, we should add a disclaimer that it should not be used that way and leave it at that? > Finally, I see that (while Section 3 is clear about "MUST be accessed with > the 'https' scheme"), in Section 6.6 we went from "MUST use HTTPS" to > "should use HTTPS", and since my review of the LC discussion was > (unfortunately) spread out in time I have forgotten what comment prompted > that change. It would probably be worth some mention of the expected > case(s) where HTTPS would not be used (e.g., when it's local file or other > non-HTTP access), to strengthen the argument for using HTTPS the rest of the > time. (Possibly related to > https://github.com/securitytxt/security-txt/issues/177 ) > This was in response to Taro Kivinen's comment regarding reporting an expired certificate: https://mailarchive.ietf.org/arch/msg/last-call/C3MHndMJDDVNVdLQm6y57iPr79g/ I am changing the text below that to read: "In cases where the "security.txt" file cannot be served via HTTPS (such as being located in a filesystem or served from localhost) or is being served with an invalid certificate, additional human triage is recommended since the contents may have been modified while in transit." > > Some other minor comments from the IETF LC that may be worth addressing: > > David Rogers pointed out that by creating a semi-automatable > .well-known/security.txt mechanism, we may be implicitly disincentivizing > public-facing pages like /security that give more robust information or are > accessible to a wider audience. A disclaimer that there is not intent to > discourage such publicly navigatable pages could be useful. > Adding a note around this > Michael Richardson noted that the scope of contact information is/can be > broader than just the website hosting the file -- e.g., it would be very > useful to have a discoverable way to report vulnerabilities in the products > produced by a company, not just the company's website. It is probably worth > a mention that (or disclaimer against) the scope of use is potentially > broader than just the immediate website hosting the file. (This seems > related to https://github.com/securitytxt/security-txt/issues/185 and might > result in some text in Section 3.1.) > I am adding a note to that effect addressing issue #185 > Mark Nottingham also had a late-breaking comment about the .well-known > namespace being "registration required" (and security.txt.sig not being > proposed for registration), suggesting that we add a note to remind people > about this (https://github.com/securitytxt/security-txt/issues/188). > Will do > > And finally, a few additional comments from reading the -09: > > Section 3 > > "field-name" in section 3.6.8 of [RFC5322]. Fields are case- > insensitive (as per section 2.3 of [RFC5234]). The "value" comes > > nit: I think it's just the "Field names" that are case-insensitive. > Can you clarify this? The way I am reading RFC5234, it sounds like any ABNF terminal characters are case-insensitive: "NOTE: ABNF strings are case insensitive and the character set for these strings is US-ASCII." " > Section 3.1 > > For HTTP servers, a "security.txt" file MUST only apply to the domain > or IP address in the URI used to retrieve it, not to any of its > subdomains or parent domains. > > [Depending on how the discussion about "product vs. website vulnerabilities" > resolves, this might need to grow a disclaimer that it's about the HTTP > resources at those domains.] > As per a different comment, I am adding this text: "A "security.txt" file MAY also apply to products and services provided by the organization publishing the file. Implementors SHOULD use the policy directive (as per {{policy}}) to provide additional details regarding scope and details of their vulnerability disclosure process." > Section 4.1 > > Researchers should perform additional triage (as per Section 6.1) to > make sure these redirects are not malicious or point to resources > controlled by an attacker. > > nit: s/point/pointing/ > Will fix > Section 6.6 > > (as per Section 3.4). Also, to protect security reports from being > tampered with or observed while in transit, organizations should > specify encryption keys (as per Section 3.5.4) unless HTTPS is being > used. > > I think we should clarify that this is "HTTPS is being used for report > submission". > Will fix All of the changes I am making are going into this pull request: https://github.com/securitytxt/security-txt/pull/192 From nobody Sun Jul 12 17:56:15 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFFE3A0063 for ; Sun, 12 Jul 2020 17:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nightwatchcybersecurity-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 08IYk8euuhcT for ; Sun, 12 Jul 2020 17:56:13 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 5B4D43A0044 for ; Sun, 12 Jul 2020 17:56:13 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id w2so5267175pgg.10 for ; Sun, 12 Jul 2020 17:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yrBfrlNAn7kodCLF7T0HGjPVsl+YWJu2k6Z/p41MADI=; b=U7uv/v9gQiHnp5kSi+an6WtoQnkLPbmZyiNCs1L2Ud6SwwLOwlEDR94FdBfX4Y5IVr Mfn6Mx0uREjCvc7haomHZCwx6ZiXzy9oJTGFLQ200VGhZMpc0JKdzDQd89iXViUy8A/h QKh7d44u0N5C4e3bFSfHbWf1eMXUqKojqKY8Pjf/fdab/KwmPPZacdhG6+8/q8IXJT07 fYmKyzBe6b9/32jMN572uY8eSkhOcYyUCCsYAR5wn8o+XKCTEmQSBa7PKzmPlEilnu2g 7FMHDyCUceE0OfD4yUNEcOyEdCzDhOW/TDHSStxoSCVH0Hx/+GdWD/lUBThph8wIZEQH X3wA== 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=yrBfrlNAn7kodCLF7T0HGjPVsl+YWJu2k6Z/p41MADI=; b=PEKu/Tfwj+CKU1+npgWdIiBrRQTnfFngjRHxkwORde1yvaIR2V8hpPN8mlLy6IM9vN SD3uSloZ+RC8E9YIS3uAAc0a139K3Oz4SrWdKdkiGLHjjVywXXuYDZBOfLfZkcM5vPWu VFlAzu+a7bwmBe/bqeLeudJKhhihvXYX4YG3BdhoH3mRhMgakkwKN+2/wdwhypeVv5OG B59+v/ZI47r0Rj+UtyF8MIuQdQxPSLwkLqZP7xAVCHuE901UGBjbeO1+Ubggbbr9XZO2 71ULi8sEid7mG1YPKumFZelYEBt1jVOhp0Df2sf3xaaj6aHzyM2hCyxTlNTCMvNl0GWd AfaA== X-Gm-Message-State: AOAM530ycDEWMi8/iWGjMewhr7BT6JJlFoCUk9ze0OexPQ6YRL1tP40s /WowcxH+yzu8xbwPO7K1TEkKFHmszzf/Gc/f3wymUg== X-Google-Smtp-Source: ABdhPJyxdz4pF5fgp1iLDufcx1kPhIiOThdItzffDxmbm35Vlz+Nk73hm+FabSxWxmwJzX6Woz0efPM7G4xV/YxBhKY= X-Received: by 2002:aa7:9630:: with SMTP id r16mr68938466pfg.144.1594601772728; Sun, 12 Jul 2020 17:56:12 -0700 (PDT) MIME-Version: 1.0 References: <20200630222455.GX58278@kduck.mit.edu> <12504.1593572624@localhost> <20200702034828.GB16335@kduck.mit.edu> <5953.1593706347@localhost> <20200702222032.GG16335@kduck.mit.edu> <29760.1593757978@localhost> In-Reply-To: <29760.1593757978@localhost> From: Yakov Shafranovich Date: Sun, 12 Jul 2020 20:55:36 -0400 Message-ID: To: Michael Richardson Cc: Benjamin Kaduk , draft-foudil-securitytxt@ietf.org, Security Area Advisory Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] results of IETF LC for draft-foudil-securitytxt-08 and next steps X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 00:56:14 -0000 On Fri, Jul 3, 2020 at 2:33 AM Michael Richardson wrote: > > > Benjamin Kaduk wrote: > >> >> My take: > >> >> We can't get publically anchored certificates for devices without DNS names, > >> >> such as those that might be found in your home on RFC1918 addresses. The > >> >> teddy cam can still have a securitytxt on it to report issues. > >> > >> > That seems pretty aligned with my best guess, involving cases where https > >> > was not possible (whether because it's going via filesystem access and not > >> > web, or the device only has an IP address and not a name, or whatever). > >> > >> Okay, but if the teddycam at 192.168.1.104, has a security.txt, then it can > >> only apply for reporting vulnerabilities in *that* TeddyCam, since other > >> Teddy Cams would be at different addresses, according to section 3.1. > > > Yes ... but any vulnerabilities in that one would also be expected to be > > present in other instances of the same model, and if the contact point is > > at the manufacturer, the manufacturer can do the right thing? > > I feel like you have a downside in mind that I'm failing to spot... > > If a security.txt applies *only* to the web resource where you found it, > then that means it doesn't generalize to the other instances of that device. > That sounds dumb, and it is, but that's what I'm reading in section 3.1 > The concern was that in a case where different parts of a website may be owned by different customers, we didn't want customer A claiming authority over customer B. This is well illustrated by Amazon's setup for S3 where "domain.s3.amazonaws.com" is the same thing as "s3.amazonaws.com/domain/". With that being said, the intent is that the "Policy" directive can point to an expanded policy document that would add more information about scope. So in the case of the Teddy Cam, the "security.txt" file would provide the absolute minimum but the policy directive can add additional information. Thanks From nobody Sun Jul 12 18:00:25 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8163A00C0 for ; Sun, 12 Jul 2020 18:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nightwatchcybersecurity-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 JoIy68NDE6xj for ; Sun, 12 Jul 2020 18:00:21 -0700 (PDT) Received: from mail-pj1-x1043.google.com (mail-pj1-x1043.google.com [IPv6:2607:f8b0:4864:20::1043]) (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 DE5443A0063 for ; Sun, 12 Jul 2020 18:00:21 -0700 (PDT) Received: by mail-pj1-x1043.google.com with SMTP id t15so5352290pjq.5 for ; Sun, 12 Jul 2020 18:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xGkvPOznVm6Xc3iZofXOyR5qX4nlLKl6hwQQMX0GIfE=; b=b4hl5sWIis1vOqbZxhTrHIZbI4OXW1oMMI9buTMHG6lJY6j+7ALMsQsz7PHbQIr7tG 0wlcVxS/mFgKZn2ttyYIn1gNMiQmZriLEWBwiHqRL+jkeglbblmN/whTDv5y7JmVOtpG 0KV1Kx5DGSwCw+HZbAOka/PwJKx8syRhIlttxJofin4PncgFZ6SNrRNyfKelnChGjy8R yvZVK9jdGE4VI8TAoPZq50DAQBtu8aXibaY2N9tfAA/mYlYunZ1xesklyGz+D2dCK6rg 6L8X7xdSKVgc0Bc0wqILvJeyTRp6Cwm5BPLudTQMISX6WL5OhTw6BDtIqB3o079p4BGr eXvw== 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=xGkvPOznVm6Xc3iZofXOyR5qX4nlLKl6hwQQMX0GIfE=; b=UkO0ajHT/3h3EsagBpl5q7rPIQ3tGb+AT4IbSR1stCKVC+LLKayoOE/BbnEf3sOazk 9x7ozWZhPDKbiZue8vvPy7Fg4zInvbRBZBWItT1gQysTsKejaVWbcpuReemkoSZTwdJr tsHO34zkqS6y0TehcbLwgpeFZQ3sPMEeDYnEKXy6hZaSav49zMf7uGaWUtymJBYAtIUp RV87qbvHGx0hO2773hDJxqrVg8/2jW4cSd/t6ypaGK8ub6DcBxSW9Yv32SVYWdSoeewI Efmw9e6zlCaACjxbCt78kqZDLtYM3N39cPXt+qECgby8bxIhn8G6DghTErVZdRL2knYB DvxQ== X-Gm-Message-State: AOAM533Pxe+MSmspXFRoJkU1kCxtU12reMyqgmiF0RJWD8rzUer7mIQ2 Ds2nSNG272PvqLAn/ZEgtY7WYtN/UUH2rYMR+hZ9gQ== X-Google-Smtp-Source: ABdhPJwZbIafPKI/TSkJqt7u0ASqY0N8JHOsG78R/I+tFiIM7ua+PiExHmsyNLeCd1tcF+Kq7Qmhz06yWEuwgqZsWB0= X-Received: by 2002:a17:90a:fe6:: with SMTP id 93mr16998381pjz.145.1594602021362; Sun, 12 Jul 2020 18:00:21 -0700 (PDT) MIME-Version: 1.0 References: <20200630222455.GX58278@kduck.mit.edu> <12504.1593572624@localhost> <20200702034828.GB16335@kduck.mit.edu> In-Reply-To: <20200702034828.GB16335@kduck.mit.edu> From: Yakov Shafranovich Date: Sun, 12 Jul 2020 20:59:45 -0400 Message-ID: To: Benjamin Kaduk Cc: Michael Richardson , draft-foudil-securitytxt@ietf.org, Security Area Advisory Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] results of IETF LC for draft-foudil-securitytxt-08 and next steps X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 01:00:25 -0000 On Wed, Jul 1, 2020 at 11:48 PM Benjamin Kaduk wrote: > > Hi Michael, > > On Tue, Jun 30, 2020 at 11:03:44PM -0400, Michael Richardson wrote: > > > > Benjamin Kaduk wrote: > > > The topic of use for reporting compromise vs. vulnerability was raised by > > > many reviewers, to the extent that it seems like it would be very > > > challenging to craft text that would definitively convince the reader to not > > > use the contents of the files for reporting cases of active compromise, > > > > When you say, "reporting compromise" do you think that reviewers/commenters > > were limiting this to talking about reporting that example.com (where you > > found security.txt) is compromised, or is it about any part of example.com? > > My understanding is that that's what was so controversial, yes. (Note that > the draft is quite clear that https://example.com/.well-known/security.txt > does not apply to *.example.com, and one of the points I'd like further > clarifying text on is whether the file on the web is useful for non-web > stuff.) > > > I ask because there is a continuity of things between for instance, > > 1) reporting that Example.COM "Smart" refriderators are vulnerable (and > > maybe have been compromised already), > > 2) to reporting that gitlab.example.com (where the fridge source code is > > kept) is running a potentially vulnerable version of gitoris, > > 3) to reporting that update.example.com (where the signed images are kept) > > is full of trojaned code > > 4) to reporting that smtp.example.com seems to forward malware through > > the mailing lists maintained there > > 5) to reporting that www.example.com has been p0wned. > > Indeed, and well said. > > > My observation is that most of the discussion ratholed around (5), > > completely ignoring other benefits. I don't think that any amount of text we > > I agree. Note that I myself was not fully clear on these cases in my > writeup -- I mentioned compromise in the context of "systems involved in > retrieving security.txt" in one place but just the (presumed broader scope) > "compromise" in the high-level summary. > This is why CERT's CVD makes the distinction between "vulnerability response" and "incident response": https://vuls.cert.org/confluence/display/CVD/1.2.+CVD+Context+and+Terminology+Notes "These two concepts are related, but different; Vulnerability Response specifically indicates responding to reports of product vulnerabilities, usually via the CVD process, whereas Incident Response is more general and can also include other security events such as network intrusions." In our case, #1 and #2 and possibly #3 are "vulnerability response", while #4-5 are "incident response". Our proposal is geared towards "vulnerability response", although it can be used for both. I tried to add additional verbiage to the next draft to make that more clear. Thanks From nobody Sun Jul 12 18:05:08 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C25F3A00E4; Sun, 12 Jul 2020 18:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9LWn94M7FmI; Sun, 12 Jul 2020 18:05:02 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71D373A00D6; Sun, 12 Jul 2020 18:05:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8FA3A389BC; Sun, 12 Jul 2020 21:02:02 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LZTzKOv68Yfe; Sun, 12 Jul 2020 21:02:02 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E57683898D; Sun, 12 Jul 2020 21:02:01 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 02ADB795; Sun, 12 Jul 2020 21:05:00 -0400 (EDT) From: Michael Richardson To: Yakov Shafranovich cc: Benjamin Kaduk , draft-foudil-securitytxt@ietf.org, Security Area Advisory Group In-Reply-To: References: <20200630222455.GX58278@kduck.mit.edu> <12504.1593572624@localhost> <20200702034828.GB16335@kduck.mit.edu> <5953.1593706347@localhost> <20200702222032.GG16335@kduck.mit.edu> <29760.1593757978@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] results of IETF LC for draft-foudil-securitytxt-08 and next steps X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 01:05:04 -0000 --=-=-= Content-Type: text/plain Yakov Shafranovich wrote: >> If a security.txt applies *only* to the web resource where you found it, >> then that means it doesn't generalize to the other instances of that device. >> That sounds dumb, and it is, but that's what I'm reading in section 3.1 >> > The concern was that in a case where different parts of a website may > be owned by different customers, we didn't want customer A claiming > authority over customer B. This is well illustrated by Amazon's setup > for S3 where "domain.s3.amazonaws.com" is the same thing as > "s3.amazonaws.com/domain/". I understand. also cf: "geocities" :-) > With that being said, the intent is that the "Policy" directive can > point to an expanded policy document that would add more information > about scope. So in the case of the Teddy Cam, the "security.txt" file > would provide the absolute minimum but the policy directive can add > additional information. okay, thank you, I'm happy with this. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8LszsACgkQgItw+93Q 3WXA3Af/dLb31n+OYtx8pHIL/VrzWL9NwmKfYPOorWcihYn3/BB95XzWdnPySn/W U+dgjzeNvzsx9po1cbZFpk8n2gEcR1a9pnwCxwI7fsvTOFpdvIYNTh6p/nngyCyY 8ve7M2eOmE3esBdPPzM2I6ic1IVt8WlA8fbMbtG68MK/6+I6hRC9DF/qaDZE75vy l0fYblka8HfQJmFSvTffAWnsx8gaaqShWACgMdX/5iKgw9wQgxBvu/75gSROSnc/ b2OqAi+7yYOuqGv3/DlOsF4mqPb8OEMgAlngm6MjBv02ijn/eYL7DV2CkLxWYB8N fyCxRibI2x2N9UjK3p9j/+Sb5j5eAA== =Ft+x -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 17 14:19:32 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DD63A096C for ; Fri, 17 Jul 2020 14:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Dwcs_yjcFec for ; Fri, 17 Jul 2020 14:13:54 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9ED63A07E1 for ; Fri, 17 Jul 2020 14:13:48 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06HLDin1012572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 17 Jul 2020 17:13:46 -0400 Date: Fri, 17 Jul 2020 14:13:44 -0700 From: Benjamin Kaduk To: saag@ietf.org Message-ID: <20200717211344.GX41010@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [saag] draft SAAG agenda for IETF 108 posted X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 21:14:02 -0000 Hi all, A draft agenda for our session at virtual IETF 108 is available at https://datatracker.ietf.org/doc/agenda-108-saag/ . Please let us know if you have any requested changes or comments. Thanks, Ben From nobody Mon Jul 20 21:13:46 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2293A13A0; Mon, 20 Jul 2020 21:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8Uxm3HxlUJ1; Mon, 20 Jul 2020 21:13:43 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13A7B3A139F; Mon, 20 Jul 2020 21:13:42 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06L4Dcgt026279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jul 2020 00:13:41 -0400 Date: Mon, 20 Jul 2020 21:13:38 -0700 From: Benjamin Kaduk To: saag@ietf.org Cc: draft-gont-numeric-ids-sec-considerations@ietf.org Message-ID: <20200721041338.GC41010@kduck.mit.edu> References: <20200717204604.GV41010@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200717204604.GV41010@kduck.mit.edu> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [saag] Fwd: AD evaluation of draft-gont-numeric-ids-sec-considerations-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 04:13:45 -0000 Forwarding my review comments to SAAG since I forgot to put it in the original email... -Ben On Fri, Jul 17, 2020 at 01:46:08PM -0700, Benjamin Kaduk wrote: > Hi Fernando, Ivan, > > While this is nominally just a single AD's evaluation of the document, I > find that the general tone and structure are not a great match for what > I was expecting, given the secdispatch session several IETFs ago. > (Shame on me for taking so long to do the review, yes.) I don't want to > be imposing my own preferences on what should really be a community > document, though, so I'm copying my comments to the SAAG list as well, > to get broader feedback and ensure that I can be reined in when I'm > getting too far from the consensus position. > > I have several points that seem particularly important or potentially > contentious; however, because they will make more sense in the context > of the rest of the document, I am leaving them embedded in the inline > comments, and will mark them with "[*]". > > Abstract > > For more than 30 years, a large number of implementations of the TCP/ > IP protocol suite have been subject to a variety of attacks, with > effects ranging from Denial of Service (DoS) or data injection, to > information leakage that could be exploited for pervasive monitoring. > > This much historical background is probably overkill for an Abstract. > > The root of these issues has been, in many cases, the poor selection > of transient numeric identifiers in such protocols, usually as a > result of insufficient or misleading specifications. This document > formally updates RFC3552, such that RFCs are required to include a > security and privacy analysis of the transient numeric identifiers > they specify. > > I might reformulate the whole thing as something more like: > > % Poor selection of transient numerical identifiers in protocols such as > % the TCP/IP suite has historically led to a number of attacks on > % implementations, ranging from Denial of Service (DoS) to data > % injection and information leakage that can be exploited by pervasive > % monitoring. To prevent such flaws in future protocols and > % implementations, this document updates RFC 3552, requiring future RFCs > % to contain analysis of the security and privacy properties of any > % transient numeric identifiers specified by the protocol. > > Section 1 > > Interface Identifiers (IIDs). These identifiers usually have > specific properties that must be satisfied such that they do not > result in negative interoperability implications (e.g. uniqueness > during a specified period of time), and an associated failure > > nit: comma after "e.g.". > > For more than 30 years, a large number of implementations of the TCP/ > IP protocol suite have been subject to a variety of attacks, with > > (editorial) the transition from the previous paragraph might flow better > if this was something like "The TCP/IP protocol suite alone has been > subject to variety of attacks on its numerical identifiers over the past > 30 years or more, with [...]". > > o Predictable DNS TxIDs > > [DNS TxIDs are pretty hard to argue for being part of the "TCP/IP > protocol suite", so I added a hedge word "alone" in my previous > suggestion] > > Section 2 > > What's wrong with the RFC 4949 definition of "identifier"? > (We'd still want to keep the discussion about "transient", of course.) > > Also, we should pick up the new BCP 14 boilerplate from RFC 8174. > > Section 3 > > [*] Overall, I find this section longer than I expected, spending "too > much time" on examples and evangelizing. I have some specific comments > below, but I'm not sure that just addressing the specific comments would > change the overall impression that the section gives. > > While assessing protocol specifications and implementations regarding > the use of transient numeric identifiers > [I-D.gont-numeric-ids-history], we found that most of the issues > discussed in this document arise as a result of one of the following > conditions: > > (editorial) A potential rewording that hews closer to "typical RFC > style" might be: > > % A recent survey of transient numerical identifier usage in protocol > % specifications and implementations [I-D.gont-numeric-ids-history] > % revealed that most of the issues discussed in this document arise as a > % result of one of the following conditions: > > A number of protocol implementations (too many of them) simply > overlook the security and privacy implications of identifiers. > Examples of them are the specification of TCP port numbers in > [...] > On the other hand, there are a number of protocol specifications that > over-specify some of their associated protocol identifiers. For > example, [RFC4291] essentially results in link-layer addresses being > embedded in the IPv6 Interface Identifiers (IIDs) when the > [...] > > I wonder if the writing would be tighter if we diverged from the "one > bullet point, one paragraph" style. Consider: > > % Both under-specifying and over-specifying identifier contents is > % hazardous. TCP port numbers and sequence numbers [RFC0793] and DNS > % TxID [RFC1035] were under-specified, leading to implementations that > % used predictable values and thus were vulnerable to numberous off-path > % attacks. Over-specification, as for IPv6 Interface Identifiers (IIDs) > % [RFC4291] and Fragment Identification values [RFC2460], leaves > % implementations unable to respond to security and privacy issues > % stemming from the mandated algorithm -- IPv6 IIDs need not expose > % privacy-sensitive link-layer addresses, and predictable Fragment > % Identifiers invite the same off-path attacks that plague TCP. > > Finally, there are protocol implementations that simply fail to > comply with existing protocol specifications. For example, some > popular operating systems (notably Microsoft Windows) still fails to > implement transport-protocol port randomization, as specified in > [RFC6056]. > > It's not clear that this chunk speaks to the third bullet point; from > the IETF perspective, implementation of ("compliance with") our > protocols is optional, and there's not a lever in place to force people > to take updates when we revise/update the spec. Implementing only part > of a spec is a problem, but if we want to lament lack of adoption of > follow-on updates, we should be writing things differently. > > By requiring protocol specifications to clearly specify the > interoperability requirements for the transient numeric identifiers > they specify, the constraints in the possible algorithms to generate > them, as well as possible over-specification of such identifiers, > become evident. Furthermore, requiring specifications to include a > > nit(?): I'm not sure whether "constraints" is the right word here -- > what is being constrained, and by whom? Would "limitations" or "risks" > be workable? > > security and privacy analysis of the transient numeric identifiers > they specify prevents the corresponding considerations from being > overlooked at the time a protocol is specified. > > [*] I really don't think this is an appropriate way to phrase what we're > doing. To specifically *require* authors to include an analysis that > covers these particular points seems to be quite a divergence from RFC > 3552 -- while the presence of a security considerations section in RFCs > is required, what RFC 3552 claims to provide is just guidelines for how > to write such a section. Isn't what we're doing here just an > incremental addition to that guidance, not a new hard requirement on > authors? > > Section 4 > > [*] Similarly to Section 3, this section felt significantly longer than > I was expecting. Could you say something about the motivation for > putting content here as opposed to (e.g.) > draft-irtf-pearg-numeric-ids-generation? (Note, this section currently > references draft-gont-predictable-numeric-ids, which is IIRC the > pre-split consolidated document.) > > [The list itself is good; no complaints about that.] > > Adherence to the one-paragraph-follow-up-per-bullet-point style may be > at the crux of the matter, here, too. Perhaps we could just slightly > expand the elements of the list itself and avoid having large chunks of > text after it entirely. > > When one identifier is employed across contexts where such constancy > is not needed, activity correlation is made made possible. For > example, [RFC4291] essentially results in link-layer addresses being > embedded in the IPv6 Interface Identifiers (IIDs) when the > interoperability requirement of uniqueness could be achieved in other > > (We mentioned the IID+link-layer address before; it's a bit hard for me > to justify having discussion about it in two places in this document.) > > Re-using identifiers across different layers or protocols ties the > security and privacy of the protocol re-using the identifier to the > security and privacy properties of the original identifier (over > which the protocol re-using the identifier may have no control > regarding its generation). Besides, when re-using an identifier > > It's also probably worth noting that this makes the privacy (and, to > some extent, security) analysis harder, since you can no longer just > consider each protoco in isolation and instead have to look at the > combined system. > > Section 5 > > [*] This seems like the meat of the document, but it's at risk of > getting lost due to the size of Sections 3 and 4. Perhaps the > Introduction should specifically say something like "the key guidelines > for protocol designers are found in Section 5" to call it out. > > Protocol specifications that specify transient numeric identifiers > MUST: > > [*] This gets into the same question as above about "RFC 3552 doesn't > require specific things in the security considerations; why should we?". > I think we should rephrase this, perhaps: > > % When a protocol specifies transient numerical identifiers, it is > % critical for the security and privacy considerations to include > % anlysis that: > > (with the corresponding verb tense changes for the list itself). > > 1. Clearly specify the interoperability requirements for the > aforementioned identifiers. > > Hmm, would it be fair to say "interoperability (i.e., functional)"? > > 2. Provide a security and privacy analysis of the aforementioned > identifiers. > > This one is perhaps redundant with the revised lead-in, though. > > Section 7 > > This entire document is about the security and privacy implications > of transient numeric identifiers, and formally updates [RFC3552] such > that the "Security Considerations" sections of RFCs are required to > > [if the other changes go through, the "required" wording will need to be > tweaked] > > Section 9.1 > > We seem to only be using RFCs 793, 2460, 6056, and 8200 as examples, so > they would be okay to relegate to the Informative References section. > > Section 9.2 > > Keeping [I-D.gont-predictable-numeric-ids] around for the > Acknowledgments makes sense, but (as noted above) we should refer to the > appropriate post-split document(s) in the main body text. > > Section 9.3 > > Please consolidate into Section 9.2 > > > Thanks, > > Ben From nobody Mon Jul 20 22:41:30 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AE13A12C7; Mon, 20 Jul 2020 22:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neRcuzcQDNI7; Mon, 20 Jul 2020 22:41:27 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC9643A0EE9; Mon, 20 Jul 2020 22:41:26 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06L5fMTJ012098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jul 2020 01:41:24 -0400 Date: Mon, 20 Jul 2020 22:41:21 -0700 From: Benjamin Kaduk To: Yakov Shafranovich Cc: draft-foudil-securitytxt@ietf.org, Security Area Advisory Group Message-ID: <20200721054121.GE41010@kduck.mit.edu> References: <20200630222455.GX58278@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [saag] results of IETF LC for draft-foudil-securitytxt-08 and next steps X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 05:41:30 -0000 Hi Yakov, Thanks for the extra comments; some notes inline. On Sun, Jul 12, 2020 at 08:14:33PM -0400, Yakov Shafranovich wrote: > On Tue, Jun 30, 2020 at 6:25 PM Benjamin Kaduk wrote: > > > > I'm happy to see the updates in the -09 that addressed most of the > > discussion and feedback that came out of the IETF LC. What follows are my > > takeaways from the last call and discussion of what seems left to do before > > the document can progress to IESG Evaluation. > > > > Before commenting on specific issues, I would like to thank Ben and > all of the IETF members who contributed to the discussion of our > draft. It is much appreciated. Specific comments appear in line below. > > > One recurring concern during the IETF LC was that deployments of this > > mechanism would fail to get updated, eventually becoming so stale so as to > > be harmful. I'm happy to see the addition of the "Expires" directive that > > mitigates this risk, but I think we should make its presence required, and > > additionally give some guidance that the expiration date should not be "too > > far" into the future, perhaps capping it (at a "RECOMMENDED" level) to at > > most a year in the future. (Note that Section 6.2 has a bit of text that > > assumes Expires is not mandatory, in addition to the field definition in > > Section 3.5.5.) > > > > I think that makes sense, I am adjusting the language in the -10 draft > to match. I assume the one year recommendation is in line with what is > being currently done for TLS certificates? It was chosen pretty arbitrarily when I wrote it, actually :) But the underlying reasons for needing to refresh things periodically are similar between the two cases, so in some sense you found the right reason. > > Similarly, the refocusing on having the file be targeted at humans allows > > for us to reiterate that human judgment is key in deciding when to use the > > contents of a security.txt file vs. seeking other reporting mechanisms. > > This applies for old/expired files, of course, but also to the recurring > > topic of reporting compromise vs. reporting vulnerability. When reporting > > compromise, extra caution is needed, and there is probably some more that > > can be said in Section 6.1 (see next paragraph). > > > > The topic of use for reporting compromise vs. vulnerability was raised by > > many reviewers, to the extent that it seems like it would be very > > challenging to craft text that would definitively convince the reader to not > > use the contents of the files for reporting cases of active compromise, or > > even cases of vulnerability that would easily lead to active compromise. > > Given that Section 1.1 is entitled "Motivation, Prior Work and Scope", it > > seems like a very good place to put a notice that "reporting compromised > > resources (e.g., web sites) is related to, but distinct from, reporting > > security vulnerabilities; the mechanism defined in this document is intended > > for reporting vulnerabilities. If it is used to report cases of active > > compromise, or vulnerabilities that would lead to compromise of the > > system(s) involved in this mechanism, additional considerations apply, as > > discussed in Section 6.1". To expound on the nature of these considerations > > a bit more, when there is (the possibility of) active compromise, the > > "ambient authority" granted by finding the contents of the file at the given > > domain or other location is no longer trustworthy. In such cases, we should > > expect there to be an "additional source of authority" (or "trust chain") > > that can give a sense of confidence in the reliability of the contents > > therein. A PGP cleartext signature is already recommended and can be one > > such additional source of authority (provided that there is a trust path to > > the key that made the signature); other routes to such additional sources of > > authority were posited in the review comments, such as putting a > > cryptographic hash of the security.txt contents in the DNS under a DNSSEC > > signature. I think that requiring such an additional source of authority > > (though not a specific mechanism thereof) would go a long way to alleviating > > concerns of misuse of security.txt from compromised systems. However, I'm > > not entirely sure how practical it would be to impose such a requirement > > given the current state of defined mechanisms. I'm hoping to get some more > > feedback from the community on this topic, having framed it in this way -- > > the previous discussion seemed focused on other aspects of the problem and > > did not get very far towards a concrete resolution. At the very least, we > > will need more discussion that specifically in case of compromise, the > > "additional source of authority" is the only source of authority. I would > > expect this text to go in Section 6.1. > > > > I am adding this to sections 1.1. and 6.1, HOWEVER, my sense of the LC > comments is that using this file for incident response is ill advised > and should not be done. Perhaps, we should add a disclaimer that it > should not be used that way and leave it at that? In some abstract sense I agree that it is ill advised, but I do not think that any words we write will stop everyone from trying to use it for incident response. So I think that even if we have such a disclaimer, in order to be doing the responsible thing we'd still need to say something about the risks of using it for incident response and our current best thoughts about mitigating those risks. > > Finally, I see that (while Section 3 is clear about "MUST be accessed with > > the 'https' scheme"), in Section 6.6 we went from "MUST use HTTPS" to > > "should use HTTPS", and since my review of the LC discussion was > > (unfortunately) spread out in time I have forgotten what comment prompted > > that change. It would probably be worth some mention of the expected > > case(s) where HTTPS would not be used (e.g., when it's local file or other > > non-HTTP access), to strengthen the argument for using HTTPS the rest of the > > time. (Possibly related to > > https://github.com/securitytxt/security-txt/issues/177 ) > > > > This was in response to Taro Kivinen's comment regarding reporting an > expired certificate: > https://mailarchive.ietf.org/arch/msg/last-call/C3MHndMJDDVNVdLQm6y57iPr79g/ Ah, thank you for jogging my memory. > I am changing the text below that to read: > "In cases where the "security.txt" file cannot be served via HTTPS > (such as being located in a filesystem or served from localhost) or is > being served with an invalid certificate, additional human triage is > recommended since > the contents may have been modified while in transit." Thanks, that looks to give a good picture of the relevant considerations. > > > > Some other minor comments from the IETF LC that may be worth addressing: > > > > David Rogers pointed out that by creating a semi-automatable > > .well-known/security.txt mechanism, we may be implicitly disincentivizing > > public-facing pages like /security that give more robust information or are > > accessible to a wider audience. A disclaimer that there is not intent to > > discourage such publicly navigatable pages could be useful. > > > > Adding a note around this > > > Michael Richardson noted that the scope of contact information is/can be > > broader than just the website hosting the file -- e.g., it would be very > > useful to have a discoverable way to report vulnerabilities in the products > > produced by a company, not just the company's website. It is probably worth > > a mention that (or disclaimer against) the scope of use is potentially > > broader than just the immediate website hosting the file. (This seems > > related to https://github.com/securitytxt/security-txt/issues/185 and might > > result in some text in Section 3.1.) > > > > I am adding a note to that effect addressing issue #185 > > > Mark Nottingham also had a late-breaking comment about the .well-known > > namespace being "registration required" (and security.txt.sig not being > > proposed for registration), suggesting that we add a note to remind people > > about this (https://github.com/securitytxt/security-txt/issues/188). > > > > Will do > > > > > And finally, a few additional comments from reading the -09: > > > > Section 3 > > > > "field-name" in section 3.6.8 of [RFC5322]. Fields are case- > > insensitive (as per section 2.3 of [RFC5234]). The "value" comes > > > > nit: I think it's just the "Field names" that are case-insensitive. > > > > Can you clarify this? The way I am reading RFC5234, it sounds like any > ABNF terminal characters are case-insensitive: > > "NOTE: > ABNF strings are case insensitive and the character set for these > strings is US-ASCII." > " That's true for ABNF that we write ourselves, but it doesn't seem to be true for all of the fields that we're defining. Specifically, we use the 'uri' construction from RFC 3986 in several places, and as https://tools.ietf.org/html/rfc3986#section-6.2.2.1 points out, in the general case, many of the URI components are assumed to be case-sensitive. While we could try to say something about the bits of field contents that we do specify, it's probably easier to just talk about the Field names and not make things too complicated. > > Section 3.1 > > > > For HTTP servers, a "security.txt" file MUST only apply to the domain > > or IP address in the URI used to retrieve it, not to any of its > > subdomains or parent domains. > > > > [Depending on how the discussion about "product vs. website vulnerabilities" > > resolves, this might need to grow a disclaimer that it's about the HTTP > > resources at those domains.] > > > > As per a different comment, I am adding this text: > "A "security.txt" file MAY also apply to products and services > provided by the organization > publishing the file. Implementors SHOULD use the policy directive (as > per {{policy}}) > to provide additional details regarding scope and details of their > vulnerability disclosure > process." Sounds good, thanks. > > Section 4.1 > > > > Researchers should perform additional triage (as per Section 6.1) to > > make sure these redirects are not malicious or point to resources > > controlled by an attacker. > > > > nit: s/point/pointing/ > > > > Will fix > > > Section 6.6 > > > > (as per Section 3.4). Also, to protect security reports from being > > tampered with or observed while in transit, organizations should > > specify encryption keys (as per Section 3.5.4) unless HTTPS is being > > used. > > > > I think we should clarify that this is "HTTPS is being used for report > > submission". > > > > Will fix > > All of the changes I am making are going into this pull request: > https://github.com/securitytxt/security-txt/pull/192 Thanks for the pointer; I've left that tab open and will try to take a look tomorrow/in the morning. Thanks again for all the updates, Ben From nobody Mon Jul 20 22:43:49 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046B73A140C; Mon, 20 Jul 2020 22:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTjgUTD53xVy; Mon, 20 Jul 2020 22:43:43 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD0823A1408; Mon, 20 Jul 2020 22:43:42 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06L5hc75012569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jul 2020 01:43:40 -0400 Date: Mon, 20 Jul 2020 22:43:37 -0700 From: Benjamin Kaduk To: saag@ietf.org Cc: draft-gont-numeric-ids-sec-considerations@ietf.org, Fernando Gont Message-ID: <20200721054337.GF41010@kduck.mit.edu> References: <20200717204604.GV41010@kduck.mit.edu> <20200721033933.GB41010@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200721033933.GB41010@kduck.mit.edu> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [saag] Fwd: AD evaluation of draft-gont-numeric-ids-sec-considerations-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 05:43:46 -0000 And here's Fernando's responses and my follow-ups. Sorry again for not getting this right the first time. -Ben On Mon, Jul 20, 2020 at 08:39:38PM -0700, Benjamin Kaduk wrote: > Hi Fernando, > > Oops, it looks like I failed to actually cc: SAAG on my initial comments > like I had planned to. [...] > > On Fri, Jul 17, 2020 at 10:41:02PM -0300, Fernando Gont wrote: > > Hello, Benjamin, > > > > On 17/7/20 17:46, Benjamin Kaduk wrote: > > [....] > > > > > > Abstract > > > > > > For more than 30 years, a large number of implementations of the TCP/ > > > IP protocol suite have been subject to a variety of attacks, with > > > effects ranging from Denial of Service (DoS) or data injection, to > > > information leakage that could be exploited for pervasive monitoring. > > > > > > This much historical background is probably overkill for an Abstract. > > > > I agree. We probably kept the Abstract from the time the whole project > > was a single document, so your suggestion makes perfect sense. > > > > > > > The root of these issues has been, in many cases, the poor selection > > > of transient numeric identifiers in such protocols, usually as a > > > result of insufficient or misleading specifications. This document > > > formally updates RFC3552, such that RFCs are required to include a > > > security and privacy analysis of the transient numeric identifiers > > > they specify. > > > > > > I might reformulate the whole thing as something more like: > > > > > > % Poor selection of transient numerical identifiers in protocols such as > > > % the TCP/IP suite has historically led to a number of attacks on > > > % implementations, ranging from Denial of Service (DoS) to data > > > % injection and information leakage that can be exploited by pervasive > > > % monitoring. To prevent such flaws in future protocols and > > > % implementations, this document updates RFC 3552, requiring future RFCs > > > % to contain analysis of the security and privacy properties of any > > > % transient numeric identifiers specified by the protocol. > > > > Unless there are objections, I'll apply your suggested change verbatim. > > Thanks! > > > > > > > > > Section 1 > > > > > > Interface Identifiers (IIDs). These identifiers usually have > > > specific properties that must be satisfied such that they do not > > > result in negative interoperability implications (e.g. uniqueness > > > during a specified period of time), and an associated failure > > > > > > nit: comma after "e.g.". > > > > > > For more than 30 years, a large number of implementations of the TCP/ > > > IP protocol suite have been subject to a variety of attacks, with > > > > > > (editorial) the transition from the previous paragraph might flow better > > > if this was something like "The TCP/IP protocol suite alone has been > > > subject to variety of attacks on its numerical identifiers over the past > > > 30 years or more, with [...]". > > > > > > o Predictable DNS TxIDs > > > > > > [DNS TxIDs are pretty hard to argue for being part of the "TCP/IP > > > protocol suite", so I added a hedge word "alone" in my previous > > > suggestion] > > > > Well, the DNS is the Internet's directory service, so to speak. But your > > suggestion is fine, so I'll apply it. > > > > > > > > > Section 2 > > > > > > What's wrong with the RFC 4949 definition of "identifier"? > > > (We'd still want to keep the discussion about "transient", of course.) > > > > To be honest, we missed there was this definition of "identifier" in the > > RFC series. That said, the definition in RFC4949 also acommodates > > non-numeric identifiers, for which the concept of e.g. "linear" , > > monotonically-increasing, etc. would not apply. > > This is true (and I was not sure whether pulling in 4949 for a single > definition was going to help much -- it doesn't cover any of the other > things we need). > > > I would suggest that we replace this definition of "identifier" with the > > definition of "transient numeric identifier", which is the specific > > identifiers we're concerned with here. > > That seems like a really good approach (especially since we explicitly say > we will use the shorter term to refer to the same thing in this document). > > > draft-irtf-pearg-numeric-ids-history defines them as: > > > > Transient Numeric Identifier: > > A data object in a protocol specification that can be used to > > definitely distinguish a protocol object (a datagram, network > > interface, transport protocol endpoint, session, etc) from all > > other objects of the same type, in a given context. Transient > > This "in a given context" seems to be the only text at present that touches > on the "transient" part. That may well be fine; all the ideas that are > coming to me about "the contest in which the identifier is valid is limited > in scope or time, e.g., a connection lifetime or replay timer" or similar > feel like they are probably too much detail. > > > numeric identifiers are usually defined as a series of bits, and > > represented using integer values. These identifiers are typically > > dynamically selected, as opposed to statically-assigned numeric > > identifiers (see e.g. [IANA-PROT]). We note that different > > identifiers may have additional requirements or properties > > depending on their specific use in a protocol. We use the term > > "transient numeric identifier" (or simply "numeric identifier" or > > "identifier" as short forms) as a generic term to refer to any > > data object in a protocol specification that satisfies the > > identification property stated above. > > > > > > > > > > > Also, we should pick up the new BCP 14 boilerplate from RFC 8174. > > > > Definitely. Will do. > > > > > > > > > Section 3 > > > > > > [*] Overall, I find this section longer than I expected, spending "too > > > much time" on examples and evangelizing. > > > > FWIW, we might keep the bullets in this section, and simply, right after > > the bullets, refer to draft-irtf-pearg-numeric-ids-history and > > draft-irtf-pearg-numeric-ids-generation for further details. Thoughts? > > That would probably work. I think it would be okay to have maybe another > sentence for each bullet, too, but let's see what it looks like. > > > > > > > I have some specific comments > > > below, but I'm not sure that just addressing the specific comments would > > > change the overall impression that the section gives. > > > > > > While assessing protocol specifications and implementations regarding > > > the use of transient numeric identifiers > > > [I-D.gont-numeric-ids-history], we found that most of the issues > > > discussed in this document arise as a result of one of the following > > > conditions: > > > > > > (editorial) A potential rewording that hews closer to "typical RFC > > > style" might be: > > > > > > % A recent survey of transient numerical identifier usage in protocol > > > % specifications and implementations [I-D.gont-numeric-ids-history] > > > % revealed that most of the issues discussed in this document arise as a > > > % result of one of the following conditions: > > > > > > A number of protocol implementations (too many of them) simply > > > overlook the security and privacy implications of identifiers. > > > Examples of them are the specification of TCP port numbers in > > > [...] > > > On the other hand, there are a number of protocol specifications that > > > over-specify some of their associated protocol identifiers. For > > > example, [RFC4291] essentially results in link-layer addresses being > > > embedded in the IPv6 Interface Identifiers (IIDs) when the > > > [...] > > > > > > I wonder if the writing would be tighter if we diverged from the "one > > > bullet point, one paragraph" style. Consider: > > > > > > % Both under-specifying and over-specifying identifier contents is > > > % hazardous. TCP port numbers and sequence numbers [RFC0793] and DNS > > > % TxID [RFC1035] were under-specified, leading to implementations that > > > % used predictable values and thus were vulnerable to numberous off-path > > > % attacks. Over-specification, as for IPv6 Interface Identifiers (IIDs) > > > % [RFC4291] and Fragment Identification values [RFC2460], leaves > > > % implementations unable to respond to security and privacy issues > > > % stemming from the mandated algorithm -- IPv6 IIDs need not expose > > > % privacy-sensitive link-layer addresses, and predictable Fragment > > > % Identifiers invite the same off-path attacks that plague TCP. > > > > FWIW, what we tried to do here was to provide one example regording what > > we meant by "under-specification" (the requirements are to clearly > > spelled out), "over-specification" (a proposed algorithm overloads the > > ID with properties it need not have), etc., such future specs avoid > > incurring into the same error. > > (thanks for making it clear) > > > > Finally, there are protocol implementations that simply fail to > > > comply with existing protocol specifications. For example, some > > > popular operating systems (notably Microsoft Windows) still fails to > > > implement transport-protocol port randomization, as specified in > > > [RFC6056]. > > > > > > It's not clear that this chunk speaks to the third bullet point; from > > > the IETF perspective, implementation of ("compliance with") our > > > protocols is optional, and there's not a lever in place to force people > > > to take updates when we revise/update the spec. > > > > Agreed. What we meant by this bullet is that there are cases where the > > specs do the right thing, but there's a flaw in how the spec is turned > > into an implementation. (or well, the spec wasn't implemented at all). > > > > > > > > > Implementing only part > > > of a spec is a problem, but if we want to lament lack of adoption of > > > follow-on updates, we should be writing things differently. > > > > What we meant here is that this is a case where you might face security > > issues arising from flawed transient numeric IDs, but this has nothing > > to do with suboptimal specs, but rather with suboptimal implementations > > (and in that sense there's not much we (IETF) can do about them). > > Sure. "The right thing to do is properly specified (whether in a given > document or an update to it), but the implementation just didn't do the > right thing." > > > > > > > > > By requiring protocol specifications to clearly specify the > > > interoperability requirements for the transient numeric identifiers > > > they specify, the constraints in the possible algorithms to generate > > > them, as well as possible over-specification of such identifiers, > > > become evident. Furthermore, requiring specifications to include a > > > > > > nit(?): I'm not sure whether "constraints" is the right word here -- > > > what is being constrained, and by whom? Would "limitations" or "risks" > > > be workable? > > > > Probably an issue of "English as second language" here, sorry: I guess > > we could have used "requirements" instead of "constraints". i.e., what > > we meant is that if you spell out the interoperability requirements, two > > things will become evident: > > > > 1) The very "function" the algorithm needs to implement (e.g. if you > > need monotonically-increasing IDs, you better make sure that a new > > transient ID is larger than its predecesario), and, > > > > 2) It would become evident when you are overspecifying things (.e.g, > > monotonically-increasing IDs need not be a global counter that starts at > > 0 -- that's not necessary to achieve monotonically-increasing IDs). > > Thanks for writing this out, it helps a lot. I suspect that what we > actually want is to keep "constraints", but s/in/on/ -- the "constraints on > the possible algorithms" are exactly the "function the algorithm needs to > implement", which leads nicely into the "possible over-specification" that > matches your point (2). > > > > > > > > security and privacy analysis of the transient numeric identifiers > > > they specify prevents the corresponding considerations from being > > > overlooked at the time a protocol is specified. > > > > > > [*] I really don't think this is an appropriate way to phrase what we're > > > doing. To specifically *require* authors to include an analysis that > > > covers these particular points seems to be quite a divergence from RFC > > > 3552 -- while the presence of a security considerations section in RFCs > > > is required, what RFC 3552 claims to provide is just guidelines for how > > > to write such a section. Isn't what we're doing here just an > > > incremental addition to that guidance, not a new hard requirement on > > > authors? > > > > Indeed. > > > > How about changing the paragraph to: > > > > Clear specification of the interoperability requirements for the > > transient numeric identifiers will help identify possible algorithms > > that could be employed to generate them, and also make evident > > if such identifiers are being over-specify. A protocol specification > > ("over-specified") > > > will usually also benefit from a security and privacy analysis of > > the transient numeric identifiers they specify, to prevents the > > ("to prevent") > > > corresponding considerations from being overlooked in the protocol > > specification itself. > > > > ? > > Looks good; just the indicated nits. > > > > > > > > Section 4 > > > > > > [*] Similarly to Section 3, this section felt significantly longer than > > > I was expecting. Could you say something about the motivation for > > > putting content here as opposed to (e.g.) > > > draft-irtf-pearg-numeric-ids-generation? (Note, this section currently > > > references draft-gont-predictable-numeric-ids, which is IIRC the > > > pre-split consolidated document.) > > > > We were not sure if sentences such as "Employing the same identifier > > across contexts in which constancy is not required" or "Employing the > > same increment space across different contexts" would make sense to the > > reader without any context. > > > > I can think of two options to address your comment: > > 1) Keep the list, and point to draft-irtf-pearg-numeric-ids-generation > > right after that. > > > > 2) Strip much of the contents of this section (notably the specific > > examples) as follows: > > > > ---- cut here ---- > > Employing trivial algorithms for generating the identifiers means > > that any node that is able to sample such identifiers can easily > > predict future identifiers employed by the victim node. > > > > When one identifier is employed across contexts where such constancy > > is not needed, activity correlation is made made possible. For > > example, employing an identifier that is constant across networks > > allows for node tracking across networks. > > > > Re-using identifiers across different layers or protocols ties the > > security and privacy of the protocol re-using the identifier to the > > security and privacy properties of the original identifier (over > > which the protocol re-using the identifier may have no control > > regarding its generation). Besides, when re-using an identifier > > across protocols from different layers, the goal of of isolating the > > properties of a layer from that of another layer is broken, and the > > privacy and security analysis may be harder to perform, since the > > combined system, rather than each protocol in isolation will have to > > be assessed. > > I see I made this one longer, but I don't get to complain :) > > > At times, a protocol needs to convey order information (whether > > sequence, timing, etc.). In many cases, there is no reason for the > > corresponding counter or timer to be initialized to any specific > > value e.g. at system bootstrap. > > (Unrelated to previous comments) I wonder if it would be worth also saying > that there may not be a need for the difference between successive counted > values to be a constant increment (e.g., if order is truly the only needed > property, without any "counter" nature). Perhaps adding to the end ", or > even for the difference between successive values to be predictable" would > be a minimal-ish change, though I'm still on the fence as to whether it's > worth saying [in this document]. > > > A node that implements a per-context linear function may share the > > increment space among different contexts (please see the "Simple > > Hash-Based Algorithm" in [I-D.gont-predictable-numeric-ids]). > > Sharing the same increment space allows an attacker that can sample > > identifiers in other context to e.g. learn how many identifiers have > > been generated between two sampled values. > > > > Finally, some implementations have been found to employ flawed PRNGs. > > See e.g.[Klein2007]. > > ---- cut here ---- > > > > The above still gives context for the bullets, but reduces the amount of > > text and the amount of unnecesary details/examples here. > > > > I'd probably prefer addressing your comment with the modified text, but > > I would still be fine with removing the text if you prefer. > > I think we can get the modified text to work; thanks for putting it > together. Would you also be able to stub out what it would look like to > just make this modified text *be* the list itself? E.g., "Employing > trivial algorithms for generating the identifiers, which means [...]", > "Employing the same identifier across contexts in which constancy is not > required -- when one identifier is imployed [...]", etc. I think we might > have to see what that looks like before we can decide whether or not it > will work. > > > > > [....] > > > > > > It's also probably worth noting that this makes the privacy (and, to > > > some extent, security) analysis harder, since you can no longer just > > > consider each protoco in isolation and instead have to look at the > > > combined system. > > > > I've added this one above. Thanks! > > > > > > > > > > > > Section 5 > > > > > > [*] This seems like the meat of the document, but it's at risk of > > > getting lost due to the size of Sections 3 and 4. Perhaps the > > > Introduction should specifically say something like "the key guidelines > > > for protocol designers are found in Section 5" to call it out. > > > > Good grief! I'll add a note to the Intro. > > > > > > > Protocol specifications that specify transient numeric identifiers > > > MUST: > > > > > > [*] This gets into the same question as above about "RFC 3552 doesn't > > > require specific things in the security considerations; why should we?". > > > I think we should rephrase this, perhaps: > > > > > > % When a protocol specifies transient numerical identifiers, it is > > > % critical for the security and privacy considerations to include > > > % anlysis that: > > > > > > (with the corresponding verb tense changes for the list itself). > > > > > > 1. Clearly specify the interoperability requirements for the > > > aforementioned identifiers. > > > > > > Hmm, would it be fair to say "interoperability (i.e., functional)"? > > > > I'm not sure if the two words convey the same meaning. You might > > probably know better than me fore this one (i.e. "English as second > > language"). Not sure if someone might interpret "functional > > requirements" as a vague description of what the transient numeric ID is > > for (e.g. "identifying packets") as opposed to detailed requirements > > such as "monotonically increasing...". > > > > That said, no matter which specific term we employ, I guess it might > > helps to add a parenthesis with something like: > > > > > > "(e.g. required properties such as uniqueness, along with the failure > > mode if such properties are not met)" > > This is good; we should probably take it. > > > Thoughts? > > In light of the discussion here, I think it is okay to stick with > "interoperability". I might consider going with "core interoperability", > in an attempt to emphasize that we are looking for the actual fundamental > requirements, not just the stuff that the protocol authors put in as MUST > because they felt like it, but I think just "interoperability" would work, > too. > > > > > > > > 2. Provide a security and privacy analysis of the aforementioned > > > identifiers. > > > > > > This one is perhaps redundant with the revised lead-in, though. > > > > How about if we remove the redundant text from the lead-in? > > So, just > > % When a protocol specifies transient numerical identifiers, it is > % critical for the security and privacy considerations to: > > ? > > That looks like it would work. > > > My take is that an analysis of any specified numeric IDs is also key for > > the "Privacy Considerations" that are expected in RFCs these days. So, > > while not mandatory, I'd expect that specs that explicitly do this > > homework will have more chances of avoiding these problems. > > Indeed. > > > > > > > Section 7 > > > > > > This entire document is about the security and privacy implications > > > of transient numeric identifiers, and formally updates [RFC3552] such > > > that the "Security Considerations" sections of RFCs are required to > > > > > > [if the other changes go through, the "required" wording will need to be > > > tweaked] > > > > How about changing this to: > > > > This entire document is about the security and privacy implications > > of transient numeric identifiers, and formally updates [RFC3552] such > > that the security and privacy implications of transient numeric > > identifiers are considered when writing the "Security Considerations" > > section of future RFCs. > > > > ? > > Works for me. > > > > > > > > Section 9.1 > > > > > > We seem to only be using RFCs 793, 2460, 6056, and 8200 as examples, so > > > they would be okay to relegate to the Informative References section. > > > > Definitely. > > > > > > > > > Section 9.2 > > > > > > Keeping [I-D.gont-predictable-numeric-ids] around for the > > > Acknowledgments makes sense, but (as noted above) we should refer to the > > > appropriate post-split document(s) in the main body text. > > > > Done. > > > > > > > > > > Section 9.3 > > > > > > Please consolidate into Section 9.2 > > > > Done! > > > > Thanks *a lot* for your comments! They have been really useful. -- > > Please do let us know what you think about the few open issues above > > and, whether we should rev the document after that. > > I think we have gotten as far as we can get just by talking about potential > changes, so please go ahead and rev the document so we can see the changes > and have a chance to change our mind back :) > > Many thanks, > > Ben From nobody Tue Jul 21 07:51:23 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4895F3A09D4; Tue, 21 Jul 2020 07:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uu4AUdQgKwlJ; Tue, 21 Jul 2020 07:51:19 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 2A5D13A09D3; Tue, 21 Jul 2020 07:51:19 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id d14so7775467qke.13; Tue, 21 Jul 2020 07:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=3ilKAhexGKC8qCmOQwlBdfcjluQIW4uB5Hx78Wo6e6s=; b=INdrBaKdBvew2meyuk2sNo+I1W0EXWVfmXJSeec4CsN3XwmKXBiR3PjROVZstM6xJl 3Y275Z/OL0nOLzrcDasrrRTEldkAqo7GiLMRYlTtNcK/ATEHckgZjF8q5U+Mguir7/Xd e5zc9gDFbHsfwPE+tt+EtJLsVMMOyunv/ZlaR5zrgWwil12ymkXwQejDqCYmVAOdNTej ekls8OBr6B7PquKnd0/OsP7fy6MEAsvGR/XwSMtJDg2b0AOOGLdP+dtl4EIkyAkjupnQ nisCx4Evvb9snbvW4W5eO+zIBQ7aCbGrg5qLU+w6zMHRe0YLI2W5P9w6oAXuYoT194do J+OA== 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:reply-to :from:date:message-id:subject:to:cc; bh=3ilKAhexGKC8qCmOQwlBdfcjluQIW4uB5Hx78Wo6e6s=; b=ZST4nXjMFwCCrwqkBy7Wo+p3AqsyCyTAGV0ap6TWvFP4oVIEPjX/NHBkX0KnGdrdAA 7wMt5BPhEyB3Bb5cM3KSy83mUGEsccxTx/fiEpJkuZHwr2SUDWzfyIFBCA3IZzAw+yl4 OVG5RkVDTOfpDTQ34wP+dN08Q3gOSrDsp4M63lm33iHi+CcVCeUc2YRWkziGQP5N5tXY /1HyKN6BcKLRj2GAE6r1swXbiXXTx1Z6c/e2yZ9IYKyum89YaR41ZuJ4xTPtcS9NphSr 0+UCPjlIbVm2aQH/3XN5GTEc2uViYtu74jyGE4NwyXw2Fru1R3hfS23/XvytkNw9tMyt Pxpw== X-Gm-Message-State: AOAM530Wv0fg3o2PX4ICgB0+0958lSajcphn9QgB5u24hnslFh+B+bn2 ApI+gvll7U2XKAMRHuKg//f5ufqv6qFtYUMMQVTMz89WysU= X-Google-Smtp-Source: ABdhPJxzpzD1cVxY1xKyp8560zZF37p7LqzlC5Oco7wlIfXDJyFzrC8fKP/QVthoB1uR0KJbEKctNsvnxJ3xvGxBQaM= X-Received: by 2002:a25:cbce:: with SMTP id b197mr41307120ybg.327.1595343077770; Tue, 21 Jul 2020 07:51:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: sarikaya@ieee.org From: Behcet Sarikaya Date: Tue, 21 Jul 2020 09:51:06 -0500 Message-ID: To: saag@ietf.org, LISP mailing list list Cc: "" , Luigi Iannone , Luigi IANNONE Content-Type: multipart/mixed; boundary="00000000000072222d05aaf4c17a" Archived-At: Subject: [saag] pidloc sidemeeting at IETF 108 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2020 14:51:21 -0000 --00000000000072222d05aaf4c17a Content-Type: multipart/alternative; boundary="00000000000072222a05aaf4c178" --00000000000072222a05aaf4c178 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Folks, We will have a one hour side meeting next week on Tue Jul 28, 2020 11am =E2= =80=93 12pm (CDT) Webex hosting is available with the link: https://dtag.webex.com/dtag/j.php?MTID=3Dm26682b050c983443283d5584b7fe26a5 most of you should be able to get computer audio option. In the agenda we will discuss: the "IoT Edge Challenges and Functions" draft: https://tools.ietf.org/html/draft-hong-t2trg-iot-edge-computing-05 Please read it before attending. Regards, Dirk& Behcet ---------- Forwarded message --------- From: Date: Tue, Jul 14, 2020 at 10:58 AM Subject: pidloc sidemeeting To: Here the link =E2=80=A6 English version below <#m_-3393094098094266818_english> ------------------------------- WICHTIG: DATEN- UND INFORMATIONSSCHUTZ ------------------------------- *WebEx Meetings sind f=C3=BCr die Nutzung bis zur Schutzklasse "VERTRAULICH= " freigegeben.* ------------------------------- Meetingdaten ------------------------------- *Meeting-ID:* 137 102 0224 *Meeting-Passwort:* bA2fvwiPK27 ------------------------------- Web-Konferenz beitreten ------------------------------- Direkteinstieg mit https://dtag.webex.com/dtag/j.php?MTID=3Dm26682b050c983443283d5584b7fe26a5 Als Teilnehmer geben Sie bitte Ihren Namen ein und klicken auf "Dem Meeting beitreten". Alternativ mit https://dtag.webex.com und Eingabe der Meeting-ID. *BITTE BEACHTEN SIE: DIE FREIGABE DER TASTATUR- UND MAUSSTEUERUNG BEI DESKTOPSHARING IST AUS SICHERHEITSGR=C3=9CNDEN AUSSCHLIESSLICH AN DTAG MITARBEITER GESTATTET!* *=C3=9Cber Videoger=C3=A4t oder -anwendung beitreten* W=C3=A4hlen Sie 1371020224@dtag.webex.com Sie k=C3=B6nnen auch 62.109.219.4 w=C3=A4hlen und Ihre Meeting-Nummer einge= ben. *Mit Microsoft Lync oder Microsoft Skype for Business beitreten* W=C3=A4hlen Sie 1371020224.dtag@lync.webex.com ------------------------------- Einwahl in die Audio-Konferenz ------------------------------- 1. Einwahl *+49 69 791 2290* 2. Geben Sie nach Aufforderung die Meeting-ID ein Einwahl mit Cisco Jabber Version 11.0 und h=C3=B6her: tel:+49697912290,,,,1#,,,,1371020224# <+49697912290,,,,1#,,,,1371020224%23> ------------------------------- Internationale Einwahl-Nummern ------------------------------- Wenn Sie Verbindungsprobleme mit einer internationalen Einwahlnummer haben oder es f=C3=BCr Ihr Land keine Einwahlnummer gibt, benutzen Sie bitte die deutsche Einwahlnummer. Germany: +49 69 791 2290 Austria: +43 18909080 Brazil: +55 1125967383 Croatia: +38 514917770 Denmark: +45 78774290 Finland: +358 931579190 France: +33 155941414 Greece: +30 2106112599 Hungary (landline): +36 12659800 Hungary (mobile): +36 309309800 Ireland: +353 212439299 Macedonia: +389 23242046 Malaysia: +603 83133231 Mexico: +52 2222234500 Montenegro: +382 20433795 Poland: +48 224137788 Romania: +40 214006130 Russia: +7 8126776286 Singapore: +65 65106233 Slovakia mobile: +421 557858888 Spain: +34 830830001 Sweden: +46 840311290 Switzerland (for customers): +41 445769990 UK: +44 2036301290 USA (for customers): +1 3312147700 USA (for customers): +1 3312147999 Weitere Informationen zu WebEx finden Sie im DTAG Intranet: http://webex.telekom.de *_ _ _ English version _ _ _* ------------------------------- IMPORTANT: DATA AND INFORMATION PROTECTION ------------------------------- *WebEx Meetings are released for use up to protection class "CONFIDENTIAL".= * ------------------------------- MEETING DATA ------------------------------- *Meeting-ID:* 137 102 0224 *Meeting Password:* bA2fvwiPK27 ------------------------------- Join the WEB CONFERENCE ------------------------------- Click this link: https://dtag.webex.com/dtag/j.php?MTID=3Dm26682b050c983443283d5584b7fe26a5 If you are a participant, please enter your name and press "Join Meeting". Alternatively go to https://dtag.webex.com and enter your Meeting-ID. *PLEASE PAY ATTENTION: KEYBOARD AND MOUSE SHARING IS ONLY PERMITTED FOR DTAG EMPLOYEES!* ------------------------------- Enter the AUDIO CONFERENCE ------------------------------- 1. Dial *+49 69 791 2290* 2. When asked, enter your Meeting-ID Dial in with Cisco Jabber version 11.0 and higher: tel:+49697912290,,,,2#,,,,1371020224# <+49697912290,,,,2#,,,,1371020224%23> ------------------------------- International dial-in numbers ------------------------------- If you have connection problems with an international dial-in number, or if there is no dial-in number for your country, please use the German dial-in number. Germany: +49 69 791 2290 Austria: +43 18909080 Brazil: +55 1125967383 Croatia: +38 514917770 Denmark: +45 78774290 Finland: +358 931579190 France: +33 155941414 Greece: +30 2106112599 Hungary (landline): +36 12659800 Hungary (mobile): +36 309309800 Ireland: +353 212439299 Macedonia: +389 23242046 Malaysia: +603 83133231 Mexico: +52 2222234500 Montenegro: +382 20433795 Poland: +48 224137788 Romania: +40 214006130 Russia: +7 8126776286 Singapore: +65 65106233 Slovakia mobile: +421 557858888 Spain: +34 830830001 Sweden: +46 840311290 Switzerland (for customers): +41 445769990 UK: +44 2036301290 USA (for customers): +1 3312147700 USA (for customers): +1 3312147999 For additional information, please go to DTAG Intranet: http://webex.telekom.de ------------------------------- Cisco Jabber ------------------------------- Germany: tel:+49697912290,,,,1371020224# <+49697912290,,,,1371020224> Austria: tel:+4318909080,,,,1371020224# <+4318909080,,,,1371020224> Brazil: tel:+551125967383,,,,1371020224# <+551125967383,,,,1371020224> Croatia: tel:+38514917770,,,,1371020224# <+38514917770,,,,1371020224> Denmark: tel:+4578774290,,,,1371020224# <+4578774290,,,,1371020224> Finland: tel:+358931579190,,,,1371020224# <+358931579190,,,,1371020224> France: tel:+33155941414,,,,1371020224# <+33155941414,,,,1371020224> Greece: tel:+302106112599,,,,1371020224# <+302106112599,,,,1371020224> Hungary (landline): tel:+3612659800,,,,1371020224# <+3612659800,,,,1371020224> Hungary (mobile): tel:+36309309800,,,,1371020224# <+36309309800,,,,1371020224> Ireland: tel:+353212439299,,,,1371020224# <+353212439299,,,,1371020224> Macedonia: tel:+38923242046,,,,1371020224# <+38923242046,,,,1371020224> Malaysia: tel:+60383133231,,,,1371020224# <+60383133231,,,,1371020224> Mexico: tel:+522222234500,,,,1371020224# <+522222234500,,,,1371020224> Montenegro: tel:+38220433795,,,,1371020224# <+38220433795,,,,1371020224> Poland: tel:+48224137788,,,,1371020224# <+48224137788,,,,1371020224> Romania: tel:+40214006130,,,,1371020224# <+40214006130,,,,1371020224> Russia: tel:+78126776286,,,,1371020224# <+78126776286,,,,1371020224> Singapore: tel:+6565106233,,,,1371020224# <+6565106233,,,,1371020224> Slovakia mobile: tel:+421557858888,,,,1371020224# <+421557858888,,,,1371020224> Spain: tel:+34830830001,,,,1371020224# <+34830830001,,,,1371020224> Sweden: tel:+46840311290,,,,1371020224# <+46840311290,,,,1371020224> Switzerland (for customers): tel:+41445769990,,,,1371020224# <+41445769990,,,,1371020224> UK: tel:+442036301290,,,,1371020224# <+442036301290,,,,1371020224> USA (for customers): tel:+13312147700,,,,1371020224# <+13312147700,,,,1371020224> USA (for customers): tel:+13312147999,,,,1371020224# <+13312147999,,,,1371020224> --00000000000072222a05aaf4c178 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Folks,<= div>We will have a one hour side meeting next week on=C2=A0Tu= e Jul 28, 2020 11am =E2=80=93 12pm (CDT)
=C2=A0Webex hosting is a= vailable with the link:
https://dtag.webex.com/dtag/j.php?MTID=3Dm26= 682b050c983443283d5584b7fe26a5

most of you should be able to get computer audio option.=

In the agenda we will discu= ss:
the "IoT Edge Challenges and Functions" draf= t:
https://tools.ietf.org/html/draft-hong-t2trg-iot-ed= ge-computing-05

Please read it = before attending.

Regards,
Dirk&=C2= =A0Behcet

---------- Forwarded message ---------
From: <Dirk.von-Hugo@tel= ekom.de>
Date: Tue, Jul 14, 2020 at 10:58 AM
Subject: p= idloc sidemeeting
To: <sarikaya= @ieee.org>


Here the link =E2=80=A6

=C2=A0 =
=C2=A0
English version below
=C2=A0
-------------------------------
WICHTIG: DATEN- UND INFORMATIONSSCHUTZ
-------------------------------
=C2=A0
WebEx Meetings sind f=C3=BCr die Nutzung bis zur Schutzklasse "VERT= RAULICH" freigegeben.
=C2=A0
-------------------------------
Meetingdaten
-------------------------------
=C2=A0
Meeting-ID: 137 102 0224
Meeting-Passwort: bA2fvwiPK27=C2=A0
=C2=A0
-------------------------------
Web-Konferenz beitreten
-------------------------------
=C2=A0
Direkteinstieg mit https://dtag.webex.co= m/dtag/j.php?MTID=3Dm26682b050c983443283d5584b7fe26a5
Als Teilnehmer geben Sie bitte Ihren Namen ein und klicken auf "Dem Me= eting beitreten".
=C2=A0
Alternativ mit ht= tps://dtag.webex.com und Eingabe der Meeting-ID.
=C2=A0
BITTE BEACHTEN SIE: DIE FREIGABE DER TASTATUR- UND MAUSSTEUERUNG BEI DES= KTOPSHARING IST AUS SICHERHEITSGR=C3=9CNDEN AUSSCHLIESSLICH AN DTAG MITARBE= ITER GESTATTET!
=C2=A0
=C3=9Cber Videoger=C3=A4t oder -anwendung beitreten
W=C3=A4hlen Sie 1371020224@dtag.webex.com=C2=A0
Sie k=C3=B6nnen auch 62.109.219.4 w=C3=A4hlen un= d Ihre Meeting-Nummer eingeben. =C2=A0
=C2=A0

Mit Microsoft Lync o= der Microsoft Skype for Business beitreten<= /p>

W=C3=A4hlen = Sie 1371020224.dtag@lync.we= bex.com

=C2=A0
-------------------------------
Einwahl in die Audio-Konferenz
-------------------------------
=C2=A0
1. Einwahl +49 69 791 2290
2. Geben Sie nach Aufforderung die Meeting-ID ein
=C2=A0
Einwahl mit Cisco Jabber Version 11.0 und h=C3=B6her: tel:+49697912290,,,,1= #,,,,1371020224#
=C2=A0
-------------------------------
Internationale Einwahl-Nummern
-------------------------------
=C2=A0
Wenn Sie Verbindungsprobleme mit einer internationalen Einwahlnummer haben = oder es f=C3=BCr Ihr Land keine Einwahlnummer gibt, benutzen Sie bitte die = deutsche Einwahlnummer.
=C2=A0
Germany: +49 69 791 2290
Austria: +43 18909080
Brazil: +55 1125967383
Croatia: +38 514917770
Denmark: +45 78774290
Finland: +358 931579190
France: +33 155941414
Greece: +30 2106112599
Hungary (landline): +36 12659800
Hungary (mobile): +36 309309800
Ireland: +353 212439299
Macedonia: +389 23242046
Malaysia: +603 83133231
Mexico: +52 2222234500
Montenegro: +382 20433795
Poland: +48 224137788
Romania: +40 214006130
Russia: +7 8126776286
Singapore: +65 65106233
Slovakia mobile: +421 557858888
Spain: +34 830830001
Sweden: +46 840311290
Switzerland (for customers): +41 445769990
UK: +44 2036301290
USA (for customers): +1 3312147700
USA (for customers): +1 3312147999
=C2=A0
=C2=A0
Weitere Informationen zu WebEx finden Sie im DTAG Intranet: <= a href=3D"http://webex.telekom.de" target=3D"_blank">http://webex.telekom.de<= /span>
=C2=A0
=C2=A0
_ _ _ English version _ _ _
=C2=A0
-------------------------------
IMPORTANT: DATA AND INFORMATION PROTECTION
-------------------------------
=C2=A0
WebEx Meetings are released for use up to protection class "CONFIDE= NTIAL".
=C2=A0
-------------------------------
MEETING DATA
-------------------------------
=C2=A0
Meeting-ID: 137 102 0224
Meeting Password: bA2fvwiPK27=C2=A0
=C2=A0
-------------------------------
Join the WEB CONFERENCE
-------------------------------
=C2=A0
Click this link: https://dtag.webex.com/= dtag/j.php?MTID=3Dm26682b050c983443283d5584b7fe26a5
If you are a participant, please enter your name and press "Join Meeti= ng".
=C2=A0
Alternatively go to https://dtag.webex.com and enter your Meeting-ID.
=C2=A0
PLEASE PAY ATTENTION: KEYBOARD AND MOUSE SHARING IS ONLY PERMITTED FOR D= TAG EMPLOYEES!
=C2=A0
-------------------------------
Enter the AUDIO CONFERENCE
-------------------------------
=C2=A0
1. Dial +49 69 791 2290
2. When asked, enter your Meeting-ID
=C2=A0
Dial in with Cisco Jabber version 11.0 and higher: tel:+49697912290,,,,2#,,= ,,1371020224#
=C2=A0
-------------------------------
International dial-in numbers
-------------------------------
=C2=A0
If you have connection problems with an international dial-in number, or if= there is no dial-in number for your country, please use the German dial-in= number.
=C2=A0
Germany: +49 69 791 2290
Austria: +43 18909080
Brazil: +55 1125967383
Croatia: +38 514917770
Denmark: +45 78774290
Finland: +358 931579190
France: +33 155941414
Greece: +30 2106112599
Hungary (landline): +36 12659800
Hungary (mobile): +36 309309800
Ireland: +353 212439299
Macedonia: +389 23242046
Malaysia: +603 83133231
Mexico: +52 2222234500
Montenegro: +382 20433795
Poland: +48 224137788
Romania: +40 214006130
Russia: +7 8126776286
Singapore: +65 65106233
Slovakia mobile: +421 557858888
Spain: +34 830830001
Sweden: +46 840311290
Switzerland (for customers): +41 445769990
UK: +44 2036301290
USA (for customers): +1 3312147700
USA (for customers): +1 3312147999
=C2=A0
=C2=A0
For additional information, please go to DTAG Intranet: http://webex.telekom.de
=C2=A0
=C2=A0
-------------------------------
Cisco Jabber
-------------------------------
=C2=A0
Germany: = tel:+49697912290,,,,1371020224#
Austria: t= el:+4318909080,,,,1371020224#
Brazil: = tel:+551125967383,,,,1371020224#
Croatia: = tel:+38514917770,,,,1371020224#
Denmark: t= el:+4578774290,,,,1371020224#
Finland: tel:+358931579190,,,,1371020224#
France: t= el:+33155941414,,,,1371020224#
Greece: = tel:+302106112599,,,,1371020224#
Hungary (landline): tel:+3612659800,,,,1371020224#<= br> Hungary (mobile): tel:+36309309800,,,,1371020224#<= br> Ireland: tel:+353212439299,,,,1371020224#
Macedonia: tel:+38923242046,,,,1371020224#
Malaysia: tel:+60383133231,,,,1371020224#
Mexico: = tel:+522222234500,,,,1371020224#
Montenegro: tel:+38220433795,,,,1371020224#
Poland: t= el:+48224137788,,,,1371020224#
Romania: = tel:+40214006130,,,,1371020224#
Russia: t= el:+78126776286,,,,1371020224#
Singapore: tel:+6565106233,,,,1371020224#
Slovakia mobile: tel:+421557858888,,,,1371020224#=
Spain: te= l:+34830830001,,,,1371020224#
Sweden: t= el:+46840311290,,,,1371020224#
Switzerland (for customers): tel:+41445769990,,,,1371020224#
UK: tel:= +442036301290,,,,1371020224#
USA (for customers): tel:+13312147700,,,,1371020224#<= span>
USA (for customers): tel:+13312147999,,,,1371020224#<= span>

=C2=A0

--00000000000072222a05aaf4c178 Content-Type: text/calendar; charset="UTF-8"; method=REQUEST Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft Exchange Server 2010 VERSION:2.0 BEGIN:VTIMEZONE TZID:W. Europe Standard Time BEGIN:STANDARD DTSTART:16010101T030000 TZOFFSETFROM:+0200 TZOFFSETTO:+0100 RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D10 END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T020000 TZOFFSETFROM:+0100 TZOFFSETTO:+0200 RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D3 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ORGANIZER:mailto:Dirk.von-Hugo@telekom.de ATTENDEE;ROLE=3DREQ-PARTICIPANT;PARTSTAT=3DNEEDS-ACTION;RSVP=3DTRUE:mailto:= sarika ya@ieee.org DESCRIPTION;LANGUAGE=3Den-US:Here the link =E2=80=A6\n\n\nEnglish version b= elow\n\n -------------------------------\nWICHTIG: DATEN- UND INFORMATIONSSCHUTZ\n- ------------------------------\n\nWebEx Meetings sind f=C3=BCr die Nutzung= bis zur Schutzklasse "VERTRAULICH" freigegeben.\n\n-------------------------- -----\nMeetingdaten\n-------------------------------\n\nMeeting-ID: 137 10 2 0224\nMeeting-Passwort: bA2fvwiPK27\n\n-------------------------------\n Web-Konferenz beitreten\n-------------------------------\n\nDirekteinstieg mit https://dtag.webex.com/dtag/j.php?MTID=3Dm26682b050c983443283d5584b7f= e2 6a5\nAls Teilnehmer geben Sie bitte Ihren Namen ein und klicken auf "Dem M eeting beitreten".\n\nAlternativ mit https://dtag.webex.com und Eingabe de r Meeting-ID.\n\nBITTE BEACHTEN SIE: DIE FREIGABE DER TASTATUR- UND MAUSST EUERUNG BEI DESKTOPSHARING IST AUS SICHERHEITSGR=C3=9CNDEN AUSSCHLIESSLICH= AN=20 DTAG MITARBEITER GESTATTET!\n\n=C3=9Cber Videoger=C3=A4t oder -anwendung b= eitreten \nW=C3=A4hlen Sie 1371020224@dtag.webex.com= \nSi e k=C3=B6nnen auch 62.109.219.4 w=C3=A4hlen und Ihre Meeting-Nummer eingeb= en.\n\nM it Microsoft Lync oder Microsoft Skype for Business beitreten\nW=C3=A4hlen= Sie 1371020224.dtag@lync.webex.com\n\n--- ----------------------------\nEinwahl in die Audio-Konferenz\n------------ -------------------\n\n1. Einwahl +49 69 791 2290\n2. Geben Sie nach Auffo rderung die Meeting-ID ein\n\nEinwahl mit Cisco Jabber Version 11.0 und h =C3=B6her: tel:+49697912290\,\,\,\,1#\,\,\,\,1371020224#\n\n--------------= ---- -------------\nInternationale Einwahl-Nummern\n--------------------------- ----\n\nWenn Sie Verbindungsprobleme mit einer internationalen Einwahlnumm er haben oder es f=C3=BCr Ihr Land keine Einwahlnummer gibt\, benutzen Sie= bit te die deutsche Einwahlnummer.\n\nGermany: +49 69 791 2290\nAustria: +43 1 8909080\nBrazil: +55 1125967383\nCroatia: +38 514917770\nDenmark: +45 7877 4290\nFinland: +358 931579190\nFrance: +33 155941414\nGreece: +30 21061125 99\nHungary (landline): +36 12659800\nHungary (mobile): +36 309309800\nIre land: +353 212439299\nMacedonia: +389 23242046\nMalaysia: +603 83133231\nM exico: +52 2222234500\nMontenegro: +382 20433795\nPoland: +48 224137788\nR omania: +40 214006130\nRussia: +7 8126776286\nSingapore: +65 65106233\nSlo vakia mobile: +421 557858888\nSpain: +34 830830001\nSweden: +46 840311290\ nSwitzerland (for customers): +41 445769990\nUK: +44 2036301290\nUSA (for= =20 customers): +1 3312147700\nUSA (for customers): +1 3312147999\n\n\nWeitere Informationen zu WebEx finden Sie im DTAG Intranet: http://webex.telekom. de\n\n\n_ _ _ English version _ _ _\n\n-------------------------------\nIM PORTANT: DATA AND INFORMATION PROTECTION\n-------------------------------\ n\nWebEx Meetings are released for use up to protection class "CONFIDENTIA L".\n\n-------------------------------\nMEETING DATA\n-------------------- -----------\n\nMeeting-ID: 137 102 0224\nMeeting Password: bA2fvwiPK27\n\n -------------------------------\nJoin the WEB CONFERENCE\n---------------- ---------------\n\nClick this link: https://dtag.webex.com/dtag/j.php?MTID =3Dm26682b050c983443283d5584b7fe26a5\nIf you are a participant\, please en= te r your name and press "Join Meeting".\n\nAlternatively go to https://dtag. webex.com and enter your Meeting-ID.\n\nPLEASE PAY ATTENTION: KEYBOARD AND MOUSE SHARING IS ONLY PERMITTED FOR DTAG EMPLOYEES!\n\n------------------ -------------\nEnter the AUDIO CONFERENCE\n------------------------------- \n\n1. Dial +49 69 791 2290\n2. When asked\, enter your Meeting-ID\n\nDial in with Cisco Jabber version 11.0 and higher: tel:+49697912290\,\,\,\,2#\ ,\,\,\,1371020224#\n\n-------------------------------\nInternational dial- in numbers\n-------------------------------\n\nIf you have connection prob lems with an international dial-in number\, or if there is no dial-in numb er for your country\, please use the German dial-in number.\n\nGermany: +4 9 69 791 2290\nAustria: +43 18909080\nBrazil: +55 1125967383\nCroatia: +38 514917770\nDenmark: +45 78774290\nFinland: +358 931579190\nFrance: +33 15 5941414\nGreece: +30 2106112599\nHungary (landline): +36 12659800\nHungary (mobile): +36 309309800\nIreland: +353 212439299\nMacedonia: +389 2324204 6\nMalaysia: +603 83133231\nMexico: +52 2222234500\nMontenegro: +382 20433 795\nPoland: +48 224137788\nRomania: +40 214006130\nRussia: +7 8126776286\ nSingapore: +65 65106233\nSlovakia mobile: +421 557858888\nSpain: +34 8308 30001\nSweden: +46 840311290\nSwitzerland (for customers): +41 445769990\n UK: +44 2036301290\nUSA (for customers): +1 3312147700\nUSA (for customers ): +1 3312147999\n\n\nFor additional information\, please go to DTAG Intra net: http://webex.telekom.de\n\n\n-------------------------------\nCisco J abber\n-------------------------------\n\nGermany: tel:+49697912290\,\,\,\ ,1371020224#\nAustria: tel:+4318909080 \,\,\,\,1371020224#\nBrazil: tel:+55112 5967383\,\,\,\,1371020224#\nCroatia:= =20 tel:+38514917770\,\,\,\,1371020224#\nD enmark: tel:+4578774290\,\,\,\,1371020224#\nFinland: tel:+358931579190\,\,\,\,1371020224#\nFrance: tel:+33155941414\,\,\,\,1371020224#\nGreece: tel:+302106112599\,\,\,\,1371020224#\nHungary (landline): tel:+3612659800\,\,\,\, 1371020224#\nHungary (mobile): tel:+363 09309800\,\,\,\,1371020224#\nIreland:= =20 tel:+353212439299\,\,\,\,1371020224#\ nMacedonia: tel:+38923242046\,\,\,\,1371020224#\nMalaysia: tel:+60383133231\,\,\,\,1371020224#\nMexico: tel:+522222234500\,\,\,\,1371020224#\nMontenegro: tel:+38220433795\,\,\,\,137102022 4#\nPoland: tel:+48224137788\,\,\,\,13 71020224#\nRomania: tel:+40214006130\, \,\,\,1371020224#\nRussia: tel:+781267 76286\,\,\,\,1371020224#\nSingapore: t el:+6565106233\,\,\,\,1371020224#\nSlov akia mobile: tel:+421557858888\,\,\,\,1371020224#\nSpain: tel:+34830830001\,\,\,\,1371020224#\nSweden: tel:+46840311290\,\,\,\,1371020224#\nSwitzerland (for customers): tel:+41445769990\, \,\,\,1371020224#\nUK: tel:+4420363012 90\,\,\,\,1371020224#\nUSA (for custo mers): tel:+13312147700\,\,\,\,1371020224#\nUSA (for customers): tel:+13312147999\,\,\,\,1371020224#\n\n UID:040000008200E00074C5B7101A82E008000000008014852E085AD601000000000000000 0100000005A69E3E3149A4B4E82BCED71316C24FF SUMMARY;LANGUAGE=3Den-US:pidloc sidemeeting DTSTART;TZID=3DW. Europe Standard Time:20200728T180000 DTEND;TZID=3DW. Europe Standard Time:20200728T190000 CLASS:PUBLIC PRIORITY:5 DTSTAMP:20200714T155822Z TRANSP:OPAQUE STATUS:CONFIRMED SEQUENCE:0 LOCATION;LANGUAGE=3Den-US:Mobile +49697912290\,\,1371020224# Dial-in +49697= 91 2290 Meeting-ID 1371020224#=20 X-MICROSOFT-CDO-APPT-SEQUENCE:0 X-MICROSOFT-CDO-OWNERAPPTID:315520996 X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-DONOTFORWARDMEETING:FALSE X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MICROSOFT-LOCATIONS:[{"DisplayName":"Mobile +49697912290\,\,1371020224# D ial-in +49697912290 Meeting-ID 1371020224# "\,"LocationAnnotation":""\,"Lo cationUri":""\,"LocationStreet":""\,"LocationCity":""\,"LocationState":""\ ,"LocationCountry":""\,"LocationPostalCode":""\,"LocationFullAddress":""}] BEGIN:VALARM DESCRIPTION:REMINDER TRIGGER;RELATED=3DSTART:-PT15M ACTION:DISPLAY END:VALARM END:VEVENT END:VCALENDAR --00000000000072222a05aaf4c178-- --00000000000072222d05aaf4c17a Content-Type: application/ics; name="invite.ics" Content-Disposition: attachment; filename="invite.ics" Content-Transfer-Encoding: base64 Content-ID: <17371d503df475802341> X-Attachment-Id: 17371d503df475802341 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n ZSBTZXJ2ZXIgMjAxMA0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpXLiBFdXJv cGUgU3RhbmRhcmQgVGltZQ0KQkVHSU46U1RBTkRBUkQNCkRUU1RBUlQ6MTYwMTAxMDFUMDMwMDAw DQpUWk9GRlNFVEZST006KzAyMDANClRaT0ZGU0VUVE86KzAxMDANClJSVUxFOkZSRVE9WUVBUkxZ O0lOVEVSVkFMPTE7QllEQVk9LTFTVTtCWU1PTlRIPTEwDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRB WUxJR0hUDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0KVFpPRkZTRVRGUk9NOiswMTAwDQpUWk9G RlNFVFRPOiswMjAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllN T05USD0zDQpFTkQ6REFZTElHSFQNCkVORDpWVElNRVpPTkUNCkJFR0lOOlZFVkVOVA0KT1JHQU5J WkVSOm1haWx0bzpEaXJrLnZvbi1IdWdvQHRlbGVrb20uZGUNCkFUVEVOREVFO1JPTEU9UkVRLVBB UlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU6bWFpbHRvOnNhcmlrYQ0K IHlhQGllZWUub3JnDQpERVNDUklQVElPTjtMQU5HVUFHRT1lbi1VUzpIZXJlIHRoZSBsaW5rIOKA plxuXG5cbkVuZ2xpc2ggdmVyc2lvbiBiZWxvd1xuXG4NCiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tXG5XSUNIVElHOiBEQVRFTi0gVU5EIElORk9STUFUSU9OU1NDSFVUWlxuLQ0KIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLVxuXG5XZWJFeCBNZWV0aW5ncyBzaW5kIGbDvHIg ZGllIE51dHp1bmcgYmlzDQogIHp1ciBTY2h1dHprbGFzc2UgIlZFUlRSQVVMSUNIIiBmcmVpZ2Vn ZWJlbi5cblxuLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAtLS0tLVxuTWVldGluZ2RhdGVu XG4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tXG5cbk1lZXRpbmctSUQ6IDEzNyAxMA0K IDIgMDIyNFxuTWVldGluZy1QYXNzd29ydDogYkEyZnZ3aVBLMjdcblxuLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLVxuDQogV2ViLUtvbmZlcmVueiBiZWl0cmV0ZW5cbi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS1cblxuRGlyZWt0ZWluc3RpZWcNCiAgbWl0IGh0dHBzOi8vZHRh Zy53ZWJleC5jb20vZHRhZy9qLnBocD9NVElEPW0yNjY4MmIwNTBjOTgzNDQzMjgzZDU1ODRiN2Zl Mg0KIDZhNVxuQWxzIFRlaWxuZWhtZXIgZ2ViZW4gU2llIGJpdHRlIElocmVuIE5hbWVuIGVpbiB1 bmQga2xpY2tlbiBhdWYgIkRlbSBNDQogZWV0aW5nIGJlaXRyZXRlbiIuXG5cbkFsdGVybmF0aXYg bWl0IGh0dHBzOi8vZHRhZy53ZWJleC5jb20gdW5kIEVpbmdhYmUgZGUNCiByIE1lZXRpbmctSUQu XG5cbkJJVFRFIEJFQUNIVEVOIFNJRTogRElFIEZSRUlHQUJFIERFUiBUQVNUQVRVUi0gVU5EIE1B VVNTVA0KIEVVRVJVTkcgQkVJIERFU0tUT1BTSEFSSU5HIElTVCBBVVMgU0lDSEVSSEVJVFNHUsOc TkRFTiBBVVNTQ0hMSUVTU0xJQ0ggQU4gDQogRFRBRyBNSVRBUkJFSVRFUiBHRVNUQVRURVQhXG5c bsOcYmVyIFZpZGVvZ2Vyw6R0IG9kZXIgLWFud2VuZHVuZyBiZWl0cmV0ZW4NCiBcblfDpGhsZW4g U2llIDEzNzEwMjAyMjRAZHRhZy53ZWJleC5jb208c2lwOjEzNzEwMjAyMjRAZHRhZy53ZWJleC5j b20+XG5TaQ0KIGUga8O2bm5lbiBhdWNoIDYyLjEwOS4yMTkuNCB3w6RobGVuIHVuZCBJaHJlIE1l ZXRpbmctTnVtbWVyIGVpbmdlYmVuLlxuXG5NDQogaXQgTWljcm9zb2Z0IEx5bmMgb2RlciBNaWNy b3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzIGJlaXRyZXRlblxuV8OkaGxlbiBTaWUNCiAgMTM3MTAy MDIyNC5kdGFnQGx5bmMud2ViZXguY29tPHNpcDoxMzcxMDIwMjI0LmR0YWdAbHluYy53ZWJleC5j b20+XG5cbi0tLQ0KIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1cbkVpbndhaGwgaW4gZGll IEF1ZGlvLUtvbmZlcmVuelxuLS0tLS0tLS0tLS0tDQogLS0tLS0tLS0tLS0tLS0tLS0tLVxuXG4x LiBFaW53YWhsICs0OSA2OSA3OTEgMjI5MFxuMi4gR2ViZW4gU2llIG5hY2ggQXVmZm8NCiByZGVy dW5nIGRpZSBNZWV0aW5nLUlEIGVpblxuXG5FaW53YWhsIG1pdCBDaXNjbyBKYWJiZXIgVmVyc2lv biAxMS4wIHVuZCBoDQogw7ZoZXI6IHRlbDorNDk2OTc5MTIyOTBcLFwsXCxcLDEjXCxcLFwsXCwx MzcxMDIwMjI0I1xuXG4tLS0tLS0tLS0tLS0tLS0tLS0NCiAtLS0tLS0tLS0tLS0tXG5JbnRlcm5h dGlvbmFsZSBFaW53YWhsLU51bW1lcm5cbi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIC0t LS1cblxuV2VubiBTaWUgVmVyYmluZHVuZ3Nwcm9ibGVtZSBtaXQgZWluZXIgaW50ZXJuYXRpb25h bGVuIEVpbndhaGxudW1tDQogZXIgaGFiZW4gb2RlciBlcyBmw7xyIElociBMYW5kIGtlaW5lIEVp bndhaGxudW1tZXIgZ2lidFwsIGJlbnV0emVuIFNpZSBiaXQNCiB0ZSBkaWUgZGV1dHNjaGUgRWlu d2FobG51bW1lci5cblxuR2VybWFueTogKzQ5IDY5IDc5MSAyMjkwXG5BdXN0cmlhOiArNDMgMQ0K IDg5MDkwODBcbkJyYXppbDogKzU1IDExMjU5NjczODNcbkNyb2F0aWE6ICszOCA1MTQ5MTc3NzBc bkRlbm1hcms6ICs0NSA3ODc3DQogNDI5MFxuRmlubGFuZDogKzM1OCA5MzE1NzkxOTBcbkZyYW5j ZTogKzMzIDE1NTk0MTQxNFxuR3JlZWNlOiArMzAgMjEwNjExMjUNCiA5OVxuSHVuZ2FyeSAobGFu ZGxpbmUpOiArMzYgMTI2NTk4MDBcbkh1bmdhcnkgKG1vYmlsZSk6ICszNiAzMDkzMDk4MDBcbkly ZQ0KIGxhbmQ6ICszNTMgMjEyNDM5Mjk5XG5NYWNlZG9uaWE6ICszODkgMjMyNDIwNDZcbk1hbGF5 c2lhOiArNjAzIDgzMTMzMjMxXG5NDQogZXhpY286ICs1MiAyMjIyMjM0NTAwXG5Nb250ZW5lZ3Jv OiArMzgyIDIwNDMzNzk1XG5Qb2xhbmQ6ICs0OCAyMjQxMzc3ODhcblINCiBvbWFuaWE6ICs0MCAy MTQwMDYxMzBcblJ1c3NpYTogKzcgODEyNjc3NjI4NlxuU2luZ2Fwb3JlOiArNjUgNjUxMDYyMzNc blNsbw0KIHZha2lhIG1vYmlsZTogKzQyMSA1NTc4NTg4ODhcblNwYWluOiArMzQgODMwODMwMDAx XG5Td2VkZW46ICs0NiA4NDAzMTEyOTBcDQogblN3aXR6ZXJsYW5kIChmb3IgY3VzdG9tZXJzKTog KzQxIDQ0NTc2OTk5MFxuVUs6ICs0NCAyMDM2MzAxMjkwXG5VU0EgKGZvciANCiBjdXN0b21lcnMp OiArMSAzMzEyMTQ3NzAwXG5VU0EgKGZvciBjdXN0b21lcnMpOiArMSAzMzEyMTQ3OTk5XG5cblxu V2VpdGVyZQ0KICBJbmZvcm1hdGlvbmVuIHp1IFdlYkV4IGZpbmRlbiBTaWUgaW0gRFRBRyBJbnRy YW5ldDogaHR0cDovL3dlYmV4LnRlbGVrb20uDQogZGVcblxuXG5fIF8gXyBFbmdsaXNoIHZlcnNp b24gXyBfIF9cblxuLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLVxuSU0NCiBQT1JUQU5U OiBEQVRBIEFORCBJTkZPUk1BVElPTiBQUk9URUNUSU9OXG4tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tXA0KIG5cbldlYkV4IE1lZXRpbmdzIGFyZSByZWxlYXNlZCBmb3IgdXNlIHVwIHRv IHByb3RlY3Rpb24gY2xhc3MgIkNPTkZJREVOVElBDQogTCIuXG5cbi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS1cbk1FRVRJTkcgREFUQVxuLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAtLS0t LS0tLS0tLVxuXG5NZWV0aW5nLUlEOiAxMzcgMTAyIDAyMjRcbk1lZXRpbmcgUGFzc3dvcmQ6IGJB MmZ2d2lQSzI3XG5cbg0KIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1cbkpvaW4gdGhl IFdFQiBDT05GRVJFTkNFXG4tLS0tLS0tLS0tLS0tLS0tDQogLS0tLS0tLS0tLS0tLS0tXG5cbkNs aWNrIHRoaXMgbGluazogaHR0cHM6Ly9kdGFnLndlYmV4LmNvbS9kdGFnL2oucGhwP01USUQNCiA9 bTI2NjgyYjA1MGM5ODM0NDMyODNkNTU4NGI3ZmUyNmE1XG5JZiB5b3UgYXJlIGEgcGFydGljaXBh bnRcLCBwbGVhc2UgZW50ZQ0KIHIgeW91ciBuYW1lIGFuZCBwcmVzcyAiSm9pbiBNZWV0aW5nIi5c blxuQWx0ZXJuYXRpdmVseSBnbyB0byBodHRwczovL2R0YWcuDQogd2ViZXguY29tIGFuZCBlbnRl ciB5b3VyIE1lZXRpbmctSUQuXG5cblBMRUFTRSBQQVkgQVRURU5USU9OOiBLRVlCT0FSRCBBTkQN CiAgTU9VU0UgU0hBUklORyBJUyBPTkxZIFBFUk1JVFRFRCBGT1IgRFRBRyBFTVBMT1lFRVMhXG5c bi0tLS0tLS0tLS0tLS0tLS0tLQ0KIC0tLS0tLS0tLS0tLS1cbkVudGVyIHRoZSBBVURJTyBDT05G RVJFTkNFXG4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogXG5cbjEuIERpYWwgKzQ5 IDY5IDc5MSAyMjkwXG4yLiBXaGVuIGFza2VkXCwgZW50ZXIgeW91ciBNZWV0aW5nLUlEXG5cbkRp YWwNCiAgaW4gd2l0aCBDaXNjbyBKYWJiZXIgdmVyc2lvbiAxMS4wIGFuZCBoaWdoZXI6IHRlbDor NDk2OTc5MTIyOTBcLFwsXCxcLDIjXA0KICxcLFwsXCwxMzcxMDIwMjI0I1xuXG4tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tXG5JbnRlcm5hdGlvbmFsIGRpYWwtDQogaW4gbnVtYmVyc1xu LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLVxuXG5JZiB5b3UgaGF2ZSBjb25uZWN0aW9u IHByb2INCiBsZW1zIHdpdGggYW4gaW50ZXJuYXRpb25hbCBkaWFsLWluIG51bWJlclwsIG9yIGlm IHRoZXJlIGlzIG5vIGRpYWwtaW4gbnVtYg0KIGVyIGZvciB5b3VyIGNvdW50cnlcLCBwbGVhc2Ug dXNlIHRoZSBHZXJtYW4gZGlhbC1pbiBudW1iZXIuXG5cbkdlcm1hbnk6ICs0DQogOSA2OSA3OTEg MjI5MFxuQXVzdHJpYTogKzQzIDE4OTA5MDgwXG5CcmF6aWw6ICs1NSAxMTI1OTY3MzgzXG5Dcm9h dGlhOiArMzgNCiAgNTE0OTE3NzcwXG5EZW5tYXJrOiArNDUgNzg3NzQyOTBcbkZpbmxhbmQ6ICsz NTggOTMxNTc5MTkwXG5GcmFuY2U6ICszMyAxNQ0KIDU5NDE0MTRcbkdyZWVjZTogKzMwIDIxMDYx MTI1OTlcbkh1bmdhcnkgKGxhbmRsaW5lKTogKzM2IDEyNjU5ODAwXG5IdW5nYXJ5DQogIChtb2Jp bGUpOiArMzYgMzA5MzA5ODAwXG5JcmVsYW5kOiArMzUzIDIxMjQzOTI5OVxuTWFjZWRvbmlhOiAr Mzg5IDIzMjQyMDQNCiA2XG5NYWxheXNpYTogKzYwMyA4MzEzMzIzMVxuTWV4aWNvOiArNTIgMjIy MjIzNDUwMFxuTW9udGVuZWdybzogKzM4MiAyMDQzMw0KIDc5NVxuUG9sYW5kOiArNDggMjI0MTM3 Nzg4XG5Sb21hbmlhOiArNDAgMjE0MDA2MTMwXG5SdXNzaWE6ICs3IDgxMjY3NzYyODZcDQogblNp bmdhcG9yZTogKzY1IDY1MTA2MjMzXG5TbG92YWtpYSBtb2JpbGU6ICs0MjEgNTU3ODU4ODg4XG5T cGFpbjogKzM0IDgzMDgNCiAzMDAwMVxuU3dlZGVuOiArNDYgODQwMzExMjkwXG5Td2l0emVybGFu ZCAoZm9yIGN1c3RvbWVycyk6ICs0MSA0NDU3Njk5OTBcbg0KIFVLOiArNDQgMjAzNjMwMTI5MFxu VVNBIChmb3IgY3VzdG9tZXJzKTogKzEgMzMxMjE0NzcwMFxuVVNBIChmb3IgY3VzdG9tZXJzDQog KTogKzEgMzMxMjE0Nzk5OVxuXG5cbkZvciBhZGRpdGlvbmFsIGluZm9ybWF0aW9uXCwgcGxlYXNl IGdvIHRvIERUQUcgSW50cmENCiBuZXQ6IGh0dHA6Ly93ZWJleC50ZWxla29tLmRlXG5cblxuLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLVxuQ2lzY28gSg0KIGFiYmVyXG4tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tXG5cbkdlcm1hbnk6IHRlbDorNDk2OTc5MTIyOTBcLFwsXCxc DQogLDEzNzEwMjAyMjQjPHRlbDorNDk2OTc5MTIyOTBcLFwsXCxcLDEzNzEwMjAyMjQ+XG5BdXN0 cmlhOiB0ZWw6KzQzMTg5MDkwODANCiBcLFwsXCxcLDEzNzEwMjAyMjQjPHRlbDorNDMxODkwOTA4 MFwsXCxcLFwsMTM3MTAyMDIyND5cbkJyYXppbDogdGVsOis1NTExMg0KIDU5NjczODNcLFwsXCxc LDEzNzEwMjAyMjQjPHRlbDorNTUxMTI1OTY3MzgzXCxcLFwsXCwxMzcxMDIwMjI0PlxuQ3JvYXRp YTogDQogdGVsOiszODUxNDkxNzc3MFwsXCxcLFwsMTM3MTAyMDIyNCM8dGVsOiszODUxNDkxNzc3 MFwsXCxcLFwsMTM3MTAyMDIyND5cbkQNCiBlbm1hcms6IHRlbDorNDU3ODc3NDI5MFwsXCxcLFws MTM3MTAyMDIyNCM8dGVsOis0NTc4Nzc0MjkwXCxcLFwsXCwxMzcxMDIwMg0KIDI0PlxuRmlubGFu ZDogdGVsOiszNTg5MzE1NzkxOTBcLFwsXCxcLDEzNzEwMjAyMjQjPHRlbDorMzU4OTMxNTc5MTkw XCxcLFwsDQogXCwxMzcxMDIwMjI0PlxuRnJhbmNlOiB0ZWw6KzMzMTU1OTQxNDE0XCxcLFwsXCwx MzcxMDIwMjI0Izx0ZWw6KzMzMTU1OTQxNDENCiA0XCxcLFwsXCwxMzcxMDIwMjI0PlxuR3JlZWNl OiB0ZWw6KzMwMjEwNjExMjU5OVwsXCxcLFwsMTM3MTAyMDIyNCM8dGVsOiszMA0KIDIxMDYxMTI1 OTlcLFwsXCxcLDEzNzEwMjAyMjQ+XG5IdW5nYXJ5IChsYW5kbGluZSk6IHRlbDorMzYxMjY1OTgw MFwsXCxcLFwsDQogMTM3MTAyMDIyNCM8dGVsOiszNjEyNjU5ODAwXCxcLFwsXCwxMzcxMDIwMjI0 PlxuSHVuZ2FyeSAobW9iaWxlKTogdGVsOiszNjMNCiAwOTMwOTgwMFwsXCxcLFwsMTM3MTAyMDIy NCM8dGVsOiszNjMwOTMwOTgwMFwsXCxcLFwsMTM3MTAyMDIyND5cbklyZWxhbmQ6IA0KIHRlbDor MzUzMjEyNDM5Mjk5XCxcLFwsXCwxMzcxMDIwMjI0Izx0ZWw6KzM1MzIxMjQzOTI5OVwsXCxcLFws MTM3MTAyMDIyND5cDQogbk1hY2Vkb25pYTogdGVsOiszODkyMzI0MjA0NlwsXCxcLFwsMTM3MTAy MDIyNCM8dGVsOiszODkyMzI0MjA0NlwsXCxcLFwsMTMNCiA3MTAyMDIyND5cbk1hbGF5c2lhOiB0 ZWw6KzYwMzgzMTMzMjMxXCxcLFwsXCwxMzcxMDIwMjI0Izx0ZWw6KzYwMzgzMTMzMjMxXA0KICxc LFwsXCwxMzcxMDIwMjI0PlxuTWV4aWNvOiB0ZWw6KzUyMjIyMjIzNDUwMFwsXCxcLFwsMTM3MTAy MDIyNCM8dGVsOis1MjIyDQogMjIyMzQ1MDBcLFwsXCxcLDEzNzEwMjAyMjQ+XG5Nb250ZW5lZ3Jv OiB0ZWw6KzM4MjIwNDMzNzk1XCxcLFwsXCwxMzcxMDIwMjINCiA0Izx0ZWw6KzM4MjIwNDMzNzk1 XCxcLFwsXCwxMzcxMDIwMjI0PlxuUG9sYW5kOiB0ZWw6KzQ4MjI0MTM3Nzg4XCxcLFwsXCwxMw0K IDcxMDIwMjI0Izx0ZWw6KzQ4MjI0MTM3Nzg4XCxcLFwsXCwxMzcxMDIwMjI0PlxuUm9tYW5pYTog dGVsOis0MDIxNDAwNjEzMFwsDQogXCxcLFwsMTM3MTAyMDIyNCM8dGVsOis0MDIxNDAwNjEzMFws XCxcLFwsMTM3MTAyMDIyND5cblJ1c3NpYTogdGVsOis3ODEyNjcNCiA3NjI4NlwsXCxcLFwsMTM3 MTAyMDIyNCM8dGVsOis3ODEyNjc3NjI4NlwsXCxcLFwsMTM3MTAyMDIyND5cblNpbmdhcG9yZTog dA0KIGVsOis2NTY1MTA2MjMzXCxcLFwsXCwxMzcxMDIwMjI0Izx0ZWw6KzY1NjUxMDYyMzNcLFws XCxcLDEzNzEwMjAyMjQ+XG5TbG92DQogYWtpYSBtb2JpbGU6IHRlbDorNDIxNTU3ODU4ODg4XCxc LFwsXCwxMzcxMDIwMjI0Izx0ZWw6KzQyMTU1Nzg1ODg4OFwsXCxcLFwNCiAsMTM3MTAyMDIyND5c blNwYWluOiB0ZWw6KzM0ODMwODMwMDAxXCxcLFwsXCwxMzcxMDIwMjI0Izx0ZWw6KzM0ODMwODMw MDAxXA0KICxcLFwsXCwxMzcxMDIwMjI0PlxuU3dlZGVuOiB0ZWw6KzQ2ODQwMzExMjkwXCxcLFws XCwxMzcxMDIwMjI0Izx0ZWw6KzQ2ODQwDQogMzExMjkwXCxcLFwsXCwxMzcxMDIwMjI0PlxuU3dp dHplcmxhbmQgKGZvciBjdXN0b21lcnMpOiB0ZWw6KzQxNDQ1NzY5OTkwXCwNCiBcLFwsXCwxMzcx MDIwMjI0Izx0ZWw6KzQxNDQ1NzY5OTkwXCxcLFwsXCwxMzcxMDIwMjI0PlxuVUs6IHRlbDorNDQy MDM2MzAxMg0KIDkwXCxcLFwsXCwxMzcxMDIwMjI0Izx0ZWw6KzQ0MjAzNjMwMTI5MFwsXCxcLFws MTM3MTAyMDIyND5cblVTQSAoZm9yIGN1c3RvDQogbWVycyk6IHRlbDorMTMzMTIxNDc3MDBcLFws XCxcLDEzNzEwMjAyMjQjPHRlbDorMTMzMTIxNDc3MDBcLFwsXCxcLDEzNzEwMjANCiAyMjQ+XG5V U0EgKGZvciBjdXN0b21lcnMpOiB0ZWw6KzEzMzEyMTQ3OTk5XCxcLFwsXCwxMzcxMDIwMjI0Izx0 ZWw6KzEzMzEyMQ0KIDQ3OTk5XCxcLFwsXCwxMzcxMDIwMjI0PlxuXG4NClVJRDowNDAwMDAwMDgy MDBFMDAwNzRDNUI3MTAxQTgyRTAwODAwMDAwMDAwODAxNDg1MkUwODVBRDYwMTAwMDAwMDAwMDAw MDAwMA0KIDAxMDAwMDAwMDVBNjlFM0UzMTQ5QTRCNEU4MkJDRUQ3MTMxNkMyNEZGDQpTVU1NQVJZ O0xBTkdVQUdFPWVuLVVTOnBpZGxvYyBzaWRlbWVldGluZw0KRFRTVEFSVDtUWklEPVcuIEV1cm9w ZSBTdGFuZGFyZCBUaW1lOjIwMjAwNzI4VDE4MDAwMA0KRFRFTkQ7VFpJRD1XLiBFdXJvcGUgU3Rh bmRhcmQgVGltZToyMDIwMDcyOFQxOTAwMDANCkNMQVNTOlBVQkxJQw0KUFJJT1JJVFk6NQ0KRFRT VEFNUDoyMDIwMDcxNFQxNTU4MjJaDQpUUkFOU1A6T1BBUVVFDQpTVEFUVVM6Q09ORklSTUVEDQpT RVFVRU5DRTowDQpMT0NBVElPTjtMQU5HVUFHRT1lbi1VUzpNb2JpbGUgKzQ5Njk3OTEyMjkwXCxc LDEzNzEwMjAyMjQjIERpYWwtaW4gKzQ5Njk3OTENCiAyMjkwIE1lZXRpbmctSUQgMTM3MTAyMDIy NCMgDQpYLU1JQ1JPU09GVC1DRE8tQVBQVC1TRVFVRU5DRTowDQpYLU1JQ1JPU09GVC1DRE8tT1dO RVJBUFBUSUQ6MzE1NTIwOTk2DQpYLU1JQ1JPU09GVC1DRE8tQlVTWVNUQVRVUzpURU5UQVRJVkUN ClgtTUlDUk9TT0ZULUNETy1JTlRFTkRFRFNUQVRVUzpCVVNZDQpYLU1JQ1JPU09GVC1DRE8tQUxM REFZRVZFTlQ6RkFMU0UNClgtTUlDUk9TT0ZULUNETy1JTVBPUlRBTkNFOjENClgtTUlDUk9TT0ZU LUNETy1JTlNUVFlQRTowDQpYLU1JQ1JPU09GVC1ET05PVEZPUldBUkRNRUVUSU5HOkZBTFNFDQpY LU1JQ1JPU09GVC1ESVNBTExPVy1DT1VOVEVSOkZBTFNFDQpYLU1JQ1JPU09GVC1MT0NBVElPTlM6 W3siRGlzcGxheU5hbWUiOiJNb2JpbGUgKzQ5Njk3OTEyMjkwXCxcLDEzNzEwMjAyMjQjIEQNCiBp YWwtaW4gKzQ5Njk3OTEyMjkwIE1lZXRpbmctSUQgMTM3MTAyMDIyNCMgIlwsIkxvY2F0aW9uQW5u b3RhdGlvbiI6IiJcLCJMbw0KIGNhdGlvblVyaSI6IiJcLCJMb2NhdGlvblN0cmVldCI6IiJcLCJM b2NhdGlvbkNpdHkiOiIiXCwiTG9jYXRpb25TdGF0ZSI6IiJcDQogLCJMb2NhdGlvbkNvdW50cnki OiIiXCwiTG9jYXRpb25Qb3N0YWxDb2RlIjoiIlwsIkxvY2F0aW9uRnVsbEFkZHJlc3MiOiIifV0N CkJFR0lOOlZBTEFSTQ0KREVTQ1JJUFRJT046UkVNSU5ERVINClRSSUdHRVI7UkVMQVRFRD1TVEFS VDotUFQxNU0NCkFDVElPTjpESVNQTEFZDQpFTkQ6VkFMQVJNDQpFTkQ6VkVWRU5UDQpFTkQ6VkNB TEVOREFSDQo= --00000000000072222d05aaf4c17a-- From nobody Sun Jul 26 11:03:55 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEE93A132A for ; Sun, 26 Jul 2020 11:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id La3DMTk_TCaA for ; Sun, 26 Jul 2020 11:03:52 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF5F73A1328 for ; Sun, 26 Jul 2020 11:03:51 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 06QI3o6Y026833 for ; Sun, 26 Jul 2020 14:03:50 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 06QI3o6Y026833 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1595786630; bh=kouoiit2UnJfrxh20G0rwUby+pguOTOmcqiXB22Qnjo=; h=From:To:Subject:Date:From; b=BZaqD/PBssTSJulbTcJe+iM15RMvuNvpt4QbTNCYtGvcFjD2ZctnWyq7oFJJjSrJR Lnfps7iu5joshkVaUsQnrNruy2OOUSZMwjxxA94f5RMY+df10G2uGp/LNWLaJvuDny ymyChwTHd+cjk0OuywCti5fzKoDedMyGOs3svcbk= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 06QI3lV5027747 for ; Sun, 26 Jul 2020 14:03:48 -0400 Received: from MURIEL.ad.sei.cmu.edu (147.72.252.47) by CASCADE.ad.sei.cmu.edu (10.64.28.248) with Microsoft SMTP Server (TLS) id 14.3.487.0; Sun, 26 Jul 2020 14:03:47 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Sun, 26 Jul 2020 14:03:47 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Sun, 26 Jul 2020 14:03:47 -0400 From: Roman Danyliw To: "saag@ietf.org" Thread-Topic: SEC AD Office Hours at IETF 108 Thread-Index: AdZjdsEnm5HH1io3SSy16FFKikjapQ== Date: Sun, 26 Jul 2020 18:03:45 +0000 Message-ID: <18ebb8799c064fb59e32c212e770dcfd@cert.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.64] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [saag] SEC AD Office Hours at IETF 108 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 18:03:53 -0000 Hi! The SEC ADs will be holding office hours during IETF 108 on Monday, 1300 - = 1350 UTC. Please join us via Webex: Meeting link: https://ietf.webex.com/ietf/j.php?MTID=3Dm19d596357f5180a344e= bcdca7163fbfd Meeting number: 161 545 9828 Password: Gg5qtM7B5VV Join by video system Dial 1615459828@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Regards, Roman and Ben From nobody Mon Jul 27 15:07:43 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4AC03A08C6; Mon, 27 Jul 2020 15:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=iTjuGIMn; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=iM3/gC+2 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 b1bhoRhJMzvL; Mon, 27 Jul 2020 15:07:37 -0700 (PDT) Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.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 BD1E13A094B; Mon, 27 Jul 2020 15:07:35 -0700 (PDT) Received: from pps.filterd (m0170393.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06RM7XLk025128; Mon, 27 Jul 2020 18:07:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=smtpout1; bh=DDF3iLdAoOBSAVn+P9jrsQuWDzYk876uKdNIwScprKs=; b=iTjuGIMnB8xH/aWBygY+8ndpMJEZ94zdl2rFX/WaFfX1xMSp695AUNQGagJD2Q30xmdU vjrDjQrce+mjpFwIn5OLCrxqjn7am6j4WuOnGEQTpV9MLNl31EPv5j5CMOE0fpKoJNQ6 5VDa502BkYD8ZbwsF3/HoLa0FIeGJhszPf5K67nzoFxJ3M/xht9orLcJM6m6HuFBgh8A KL8icR/fPzZ/oi9c+46e9pBHxbObdu6xOak5ICwumo8l1iZogsm5eXYBeL8DV10y4Nfo HSbMQpNx7ShZD5kOWEgGkSzY3LGdwg8lHsTp2tXpYBmk1jH4mQ8SgYVxrn0hRATG3Pye og== Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com with ESMTP id 32gg2grq1s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Jul 2020 18:07:35 -0400 Received: from pps.filterd (m0134318.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06RM3xkk169380; Mon, 27 Jul 2020 18:07:34 -0400 Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2176.outbound.protection.outlook.com [104.47.56.176]) by mx0a-00154901.pphosted.com with ESMTP id 32j7d3g1n2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 27 Jul 2020 18:07:34 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nVHRzH6FrU7j7STi5uhl0WOkt61d1V1V4SirkHmXd7hoT0V5Yes1T7XremLVU7Nu+ZPAFXqkF9rq5HXZNWGd9ErwF1z1wUk01BrCKoNTt+5Rb0a2UqbVlYVKtOdBD3zBrs7EG3/DpZPkJSqWJFeiOb+XHtIaRq0JrgMOOtIkmSMi6tjuIe3ruhVeatHzhrxTL1ozEfwKL1pHgeXL7W7PJu5zuMxvOzLOSm90plVPB6yjrNylqXYztGfLZW7IvtUzCKbBietrC4JCw0XvmO4m1NfBFAGbXKS61PEF15xL5ob4vcl8yoj2BrHZRLefUS8aVc7PUMUQNsy+sOA0A8y/9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DDF3iLdAoOBSAVn+P9jrsQuWDzYk876uKdNIwScprKs=; b=S7rOQR1NlZ5mTefEEYwOyOI+QI75NEJfICXBIqNGidqxrvIF92q2hT4FqaLhsMEHNXYL/6063161J+s4LeumROWGiYh+H72q8q9IuO2h9cc1EjnjSpxJjRAtR5FLTIdc2we+WubHUbhL8il2EquJVug3rgyTzp/4fU5xtqdT//BNN0NPaXYtQ0l7UUl/wej//EhNyz1GR/8e7J2WGby7Ed/LSMgSM7sR+9Zl2ZH3J9JOF/ipk0R1LfObaEtqnaefQgf04yn2+GNQ97Sjyzqx3BF0pGnWh2wDEBWksxg/5SwKjIe6xJws1/Su/BmKaYIWaEkutwUzoQhOB5T6CHP1mQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com; s=selector1-Dell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DDF3iLdAoOBSAVn+P9jrsQuWDzYk876uKdNIwScprKs=; b=iM3/gC+2bcEgQKNe2j+OfKMfRlhoSER8mDr5uKo021jCb6MZfDOdYuvmett8UvGcvvOv/vpilBVo29PQjR0rgt1u39G28GtUiCBlw10md0KtF+TZrOUM6TPvnyeb16+AzFlr0rqLQqLdaYgYslVZGDRzalvyQDWYrmTbFv4pZfc= Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by BLAPR19MB4417.namprd19.prod.outlook.com (2603:10b6:208:29f::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.21; Mon, 27 Jul 2020 22:07:32 +0000 Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8933:ed5c:83b7:2a1a]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8933:ed5c:83b7:2a1a%5]) with mapi id 15.20.3216.033; Mon, 27 Jul 2020 22:07:32 +0000 From: "Black, David" To: tsvwg IETF list CC: IETF SAAG , int-area , "Black, David" Thread-Topic: draft-ietf-tsvwg-transport-encrypt-15: Conclusion of 3rd WGLC Thread-Index: AdZkYHo7/1kTpD6dQ7qmHo3hGHn9Kg== Date: Mon, 27 Jul 2020 22:07:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2020-07-27T21:54:18.4152534Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_ActionId=a11ec49e-068a-4917-b2d3-97ee5f40e3ee; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=dell.com; x-originating-ip: [168.159.213.216] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7cfc2db6-9b17-4f71-9461-08d8327975bd x-ms-traffictypediagnostic: BLAPR19MB4417: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4 x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: u2aMfaw6nH0AYCBxLqTUgKxmRPG3DGeasKvE4jH6CoKHmmVFICY3G8JTNxzSPUY1dZ/9c9s1JTGal/6gvhRZXUHf53iuh6BsPy63jJSbyriinSqAgxPdP5qozwpfpeIyf4Gu2+oxlbDdQgZfgbCqFhvMY/H9ICFerk+YPy3XZ8J7qFkL7w9Pq5rtr2wX+nbn+geVDvxfINX4LKF7hbcfMVNa1kW4IvkiuEOu11ijZV0PVH4DsK5tIErdLr1tDAPAKNKdVDvag26zxsJX5igSUvobirNBf0oQA8tzS7OFimhWBxRnRIWYb8SfoCXVry/VQoeXcAqMB0BgyEhFwzkyFzHxaPBG+wBTed3nyF9Gn16kl+fGygFSYMy5F0W453Ge/Kv3HrpVXt/U7Jx1POyuTA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR19MB4045.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(346002)(376002)(366004)(396003)(136003)(39860400002)(26005)(966005)(786003)(55016002)(166002)(186003)(6506007)(2906002)(4326008)(107886003)(316002)(9686003)(66946007)(76116006)(478600001)(64756008)(66446008)(66476007)(66556008)(8936002)(52536014)(83380400001)(5660300002)(33656002)(8676002)(7696005)(6916009)(54906003)(86362001)(71200400001)(66574015)(450100002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: lwv2fpsJR4iSOWwGx5dmpElhkvyRHxeCOf296HtE+5rDs7nqCcvIkRKfPlKBw7+whwEOLffg6sU3bgSPp1WtcQfozGh3nC1uDkyzsVmNV+TL1D7/XiDjCqU0k+GRdOeRIzVaFLNpZM0eoVsQUY02T5vRoHghUcMr7a2Udla/5cPkULCbxM/r0YmDYer5D0GxjcBcvq6hOu2xLmzW5BB2NWo8lG+I0XtzHCNvdc/Ws77DiFHbyA0pER4VQaBY1Iam32xEFWM7CMGIuL8kA7v+OTxEalJoLuOvWhHZUbqFMPkI60UnCf5QhmTEJqPStbDkOdPYC/Vfdh+m6ScnPKe0MMIeP+iItnmQVkpz/uI3L8YmX11DGHkEQijXlHdtcod92n4nD6i7l+2bcYPdM5YdJofofDrkF3LolZRlu6k9nsIRjHYQpUL6roiyKdFwF3l1uuaro8ASc/mAKiKoqUO40fvrXap640nsKLKBpkr0J4Me4zZ3k3H5FuYjrW2TXMfr Content-Type: multipart/alternative; boundary="_000_MN2PR19MB4045C175EB3C3F6E3860B80C83720MN2PR19MB4045namp_" MIME-Version: 1.0 X-OriginatorOrg: Dell.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR19MB4045.namprd19.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7cfc2db6-9b17-4f71-9461-08d8327975bd X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2020 22:07:31.9401 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: b4xgcbtv0dwNLx/UktAejwQaQSw7KyHpKUyBxSSgHvcBPX8o2IELJekDsVSUOhqugEksWksB2JaP5zgTT+gAMQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR19MB4417 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-27_15:2020-07-27, 2020-07-27 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 impostorscore=0 suspectscore=0 clxscore=1011 lowpriorityscore=0 spamscore=0 mlxlogscore=999 bulkscore=0 adultscore=0 priorityscore=1501 mlxscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007270147 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 bulkscore=0 spamscore=0 suspectscore=0 adultscore=0 malwarescore=0 mlxlogscore=999 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007270148 Archived-At: Subject: [saag] draft-ietf-tsvwg-transport-encrypt-15: Conclusion of 3rd WGLC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 22:07:42 -0000 --_000_MN2PR19MB4045C175EB3C3F6E3860B80C83720MN2PR19MB4045namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This email reports the conclusion of the third (limited scope) WGLC on: Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols draft-ietf-tsvwg-transport-encrypt-15 https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/ (https://mailarchive.ietf.org/arch/msg/tsvwg/UIw6tgdSs3AzOc3CFZgwR7HKk7A/) The purpose of the 3rd Working Group Last Call (WGLC) was to deal with two topics: 1. Whether or not to proceed with a request for = RFC publication of the draft. 2. Review of changes made since the -12 version = of the draft that was the subject of the second WGLC. Starting with the second topic, the conclusion of the 3rd WGLC is that the changes since the -12 version are generally ok. A number of editorial comments have been received by the authors and are reflected in the -16 version of the draft. The first topic (publication) is more complex. Including the authors, at least 10 responses to the WGLC have expressed support for publishing this draft as a RFC. That suffices to state that the rough consensus of the TSVWG WG is proceed with publication of this draft in roughly its current form, and in particular the rough consensus is not to add material on encryption recommendations for transport protocol designers, e.g., as requested by David Schinazi: (https://mailarchive.ietf.org/arch/msg/tsvwg/uqEBlJF-T3IiFzECZk-6GE3_-tA/). That leaves the issue of how to publish the draft, in particular, whether to publish it as an Informational RFC in the IETF Stream. RFC 8789 has recently updated RFC 2026 to now require IETF Consensus for IETF Stream Informational RFCs. This issue is solely about IETF consensus, e.g., as Eric Rescorla wrote at the conclusion of his message on this issue: To be maximally clear: I don't object to this document existing and I don't think that the opinions implicit in it are ones that should not be expressed. I merely don't think that it should be published as an IETF Consensus document. (https://mailarchive.ietf.org/arch/msg/tsvwg/AValrZYGcb-n0SNA0niZJ2rW1Zo/) The issue of this draft not being consistent with IETF consensus on encryption usage is long-standing, having been raised at the first WGLC on this draft, and it is also equally long-disputed, likewise since the first WGLC on this draft. Based on that history and the 3rd WGLC, I do not see TSVWG working group rough consensus one way or the other on whether this draft is consistent with IETF consensus. Proceeding further requires determining the IETF consensus on this draft, and the TSVWG working group is not the best choice of forum for determining IETF consensus in this specific situation. In consultation with the responsible Area Director (Martin Duke), the chosen path forward to a conclusion on this issue is to consult the IETF community on IETF consensus via an IETF Last Call. The fact that IETF consensus (or lack thereof) on this draft is unknown and needs to be determined will be explicitly noted in the shepherd writeup for this draft and should be explicitly mentioned in the IETF Last Call announcement for this draft. Thanks, --David (TSVWG co-chair) ---------------------------------------------------------------- David L. Black, Senior Distinguished Engineer Dell Technologies, Infrastructure Systems Group 176 South St., Hopkinton, MA 01748 +1 (774) 350-9323 Mobile: +1 (978) 394-7754 David.Black@dell.com ---------------------------------------------------------------- --_000_MN2PR19MB4045C175EB3C3F6E3860B80C83720MN2PR19MB4045namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This email reports the conclusion of the third (limi= ted scope) WGLC on:

 

    Considerations around Transport H= eader Confidentiality, Network

     Operations, and the Evoluti= on of Internet Transport Protocols

        &nbs= p;        draft-ietf-tsvwg-transport-enc= rypt-15

https://datatracker.ietf.org/doc/draft-ietf-ts= vwg-transport-encrypt/

 

(https://mailarchive.ietf.org/arch/msg/tsv= wg/UIw6tgdSs3AzOc3CFZgwR7HKk7A/)

 

The purpose of the 3rd Working Group Last Call (WGLC= ) was to deal with

two topics:

 

        &nbs= p;       1.     &nbs= p;      Whether or not to proceed with a request f= or RFC publication

        &nbs= p;            &= nbsp;          of the draft.

 

        &nbs= p;       2.     &nbs= p;      Review of changes made since the -12 versi= on of the draft

        &nbs= p;            &= nbsp;          that was the su= bject of the second WGLC.

        &nbs= p;            &= nbsp;         

Starting with the second topic, the conclusion of th= e 3rd WGLC is that

the changes since the -12 version are generally ok.&= nbsp; A number of

editorial comments have been received by the authors= and are reflected

in the -16 version of the draft.

 

The first topic (publication) is more complex. = Including the authors,

at least 10 responses to the WGLC have expressed sup= port for publishing

this draft as a RFC.  That suffices to state th= at the rough consensus

of the TSVWG WG is proceed with publication of this = draft in roughly

its current form, and in particular the rough consen= sus is not to add

material on encryption recommendations for transport= protocol

designers, e.g., as requested by David Schinazi:

(https://mailarchive.ietf.org/arch/msg/tsv= wg/uqEBlJF-T3IiFzECZk-6GE3_-tA/).

 

That leaves the issue of how to publish the draft, i= n particular,

whether to publish it as an Informational RFC in the= IETF Stream.

RFC 8789 has recently updated RFC 2026 to now requir= e IETF Consensus

for IETF Stream Informational RFCs.  This issue= is solely about IETF

consensus, e.g., as Eric Rescorla wrote at the concl= usion of his

message on this issue:

 

   To be maximally clear: I don't object t= o this document existing

   and I don't think that the opinions imp= licit in it are ones that

   should not be expressed. I merely don't= think that it should be

   published as an IETF Consensus document= .

  

(https://mailarchive.ietf.org/arch/msg/tsv= wg/AValrZYGcb-n0SNA0niZJ2rW1Zo/)

  

The issue of this draft not being consistent with IE= TF consensus on

encryption usage is long-standing, having been raise= d at the first

WGLC on this draft, and it is also equally long-disp= uted, likewise

since the first WGLC on this draft.  Based on t= hat history and the

3rd WGLC, I do not see TSVWG working group rough con= sensus one way or

the other on whether this draft is consistent with I= ETF consensus.

Proceeding further requires determining the IETF con= sensus on this

draft, and the TSVWG working group is not the best c= hoice of forum

for determining IETF consensus in this specific situ= ation.

 

In consultation with the responsible Area Director (= Martin Duke), the

chosen path forward to a conclusion on this issue is= to consult the

IETF community on IETF consensus via an IETF Last Ca= ll.  The fact that

IETF consensus (or lack thereof) on this draft is un= known and needs

to be determined will be explicitly noted in the she= pherd writeup

for this draft and should be explicitly mentioned in= the IETF Last

Call announcement for this draft.

 

Thanks, --David (TSVWG co-chair)

----------------------------------------------------= ------------

David L. Black, Senior Distinguished Engineer

Dell Technologies, Infrastructure Systems Group=

176 South St., Hopkinton, MA  01748<= /p>

+1 (774) 350-9323      &nbs= p;    Mobile: +1 (978) 394-775= 4

David.Black@dell.com

----------------------------------------------------= ------------

 

--_000_MN2PR19MB4045C175EB3C3F6E3860B80C83720MN2PR19MB4045namp_-- From nobody Mon Jul 27 17:08:30 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799133A097B for ; Mon, 27 Jul 2020 17:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=UovtUpzx; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=j4SBsC6I 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 IJUUqLxQpMPm for ; Mon, 27 Jul 2020 17:08:22 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1C33A08E9 for ; Mon, 27 Jul 2020 17:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14969; q=dns/txt; s=iport; t=1595894901; x=1597104501; h=from:to:subject:date:message-id:mime-version; bh=3qNkDqEFUyEGZg3mePhxGDscJ0BllobVkBJzizakqco=; b=UovtUpzx6W75PnafpNfgx2ASpVFdXqgUC99F2t3kv4k5B5YFpGWENWm4 w0o6vjych84prO1RbPTs7KjpzIhtLsvpqdo0Utrdmob99mHDHjc4aqbyL YzoacL1gn09NelDzzaQ9kcNNjkwFlykSJAv2DDDKedHq0TwnrzSC8RRcl g=; IronPort-PHdr: =?us-ascii?q?9a23=3ARLKYThQ20biqQ7oPxvqN7xKIp9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBN+J6v9YhazRqa+zEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutZlDOrDu19zFBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DlCQDtax9f/5ldJa1gg3YvUQdvWC8?= =?us-ascii?q?sCoQqg0YDoUuEbIJTA1ULAQEBDAEBGAEMCAIEAQGETBmCEAIkOBMCAwEBCwE?= =?us-ascii?q?BBQEBAQIBBgRthVwBC4YKER0BATgRARoTHQIEMA8IEAQPJoMEAYF+TQMuAQ6?= =?us-ascii?q?kUgKBOYhhdoEygwEBAQWBR0FCglgYgg4DBoE4gm2DWYY3GoIAgREnHIN0gXM?= =?us-ascii?q?CAwGCCIJpM4ItkmCGWZw1CoJeiFaRGAMen2SIJ4lvii6UbAIEAgQFAg4BAQW?= =?us-ascii?q?BaiOBV3AVZQGCPlAXAg2SD4UUhUJ0ECcCBggBAQMJfI4CAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.75,404,1589241600"; d="scan'208,217";a="807145815" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jul 2020 00:08:20 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 06S08Kjl006765 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 28 Jul 2020 00:08:20 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Jul 2020 19:08:19 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Jul 2020 19:08:19 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 27 Jul 2020 20:08:18 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FuCWM2BtnQfs3RVRpVayOdCI8PTiDjY39B7PDpSkPQ4A/Yt4dlnqZ2oIEHVETfHhUtBFKEIJWzod8cNvXvgIxz9Ul9PiQLz9H5nUXE/zTW6drYOYzkcEg/9L8DlfspMQ900sLwg4oc9678VCnsQMzctVqmpXCmXv5OXYeiwLPQPEbUbL73JgnnssZMCczmTTHqrKC4H7mJPVzicp+LOHbvv/oDo58iTtYtyzDfIff1RtM+nojjRy/fdlCcVd7SYkvbnCsLLcg9tJCvKtwbTwZhBM2NOUKnvVGdwHXLkOchFCfPQNvBOcE7t4NOoHuQ09DnZ8cvM8v9IQculKEF3xKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3qNkDqEFUyEGZg3mePhxGDscJ0BllobVkBJzizakqco=; b=a82SraqxTh8t9QsmKe/16oPx42r1N7qQfQX4BVarTg7qZDGglXWfOPuxrHOAUDNUl5lGdyuFGJxqqLaB4lP9ujBkQgvUCWHuV2cexlP+K2sf6DWHVzL/ebDWfvcYwFV8wSLWpdjlfErpJVjWcGfi18GWgVbEoaePp+pBo39w7i16h6sdTvVTT57KMFSxz1g2a6Y7vH51iDtErsGUnHVcFiBcwePjF0aHnJXgblkO+kfUHxRol+YRP8IctIpga3gxSZyiFgtpvbWcyis98hPICo4e8RLzHoib9bR8fS0FlSl+FD5POzZYGk7fGofpl06xZ81/4MEjTpOLq0mr8nnRoQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3qNkDqEFUyEGZg3mePhxGDscJ0BllobVkBJzizakqco=; b=j4SBsC6IK2Y6C6UcW3wn3BSBeFpjRzxZcEpA3wBX1uHWEJ0ShrgRahIFV6noYxxVYp4u4BIAmk9UtEadmYedKCZGN6r64QIBXUddGd1ysIeYwy9f0atL/roxCjm8tPXlngkKTjdNwzoXW+Ed47rR4bH615Eyy8U42P/KGgmyRKo= Received: from BY5PR11MB4070.namprd11.prod.outlook.com (2603:10b6:a03:181::16) by BY5PR11MB4450.namprd11.prod.outlook.com (2603:10b6:a03:1be::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.21; Tue, 28 Jul 2020 00:08:18 +0000 Received: from BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::e42f:216e:af3e:8ce5]) by BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::e42f:216e:af3e:8ce5%7]) with mapi id 15.20.3216.033; Tue, 28 Jul 2020 00:08:18 +0000 From: "Nancy Cam-Winget (ncamwing)" To: "saag@ietf.org" Thread-Topic: RATs report Thread-Index: AQHWZHMyIGz+Pe+tdU65AkmR2f4bnQ== Date: Tue, 28 Jul 2020 00:08:17 +0000 Message-ID: <0343E3DE-EF00-494C-862D-7C0841284F42@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.18.200713 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [73.162.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 44b52458-b23f-4c0f-5766-08d8328a54b1 x-ms-traffictypediagnostic: BY5PR11MB4450: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2512; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gQEPx4hEOZ2UTnmEbdEJTxP7BIkDCDlSbPAB6ruOh/iXGTxHKon6OHVsP1SszgttMLdfzyRRP60OTAqAYQ91L6d1TRyZO/TRctR+jN5XKAKY3E1+vFGrjRPMGQ2vxFQbt8RRTTifLxnLRGokeW2CmGoTl7kODB3pCI+yC0ME+Dk04BTS1/FgrFB2jTY1Bk8MRuKYjRkhX/Q61Tq58OK9zooOr8ZU1vC0PiNu488CnyjTy+cDA2gIdFK/+LgJB9wdCA4a8cQqrYU+TAXuqRIxoZ39nKkFJvSWcKraH3alWAcCGJW8cVB+OP1tgL/38C9TjW9dVkaA7ithkJIeuD/j6JGHDR0LPNUze9zDezjotEUEexOE6jGhX2cfkvTzLsHfbjT6Ze9Zh7BwDaaDYBmfJA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4070.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(366004)(346002)(396003)(136003)(39860400002)(26005)(6486002)(966005)(2616005)(186003)(166002)(2906002)(6506007)(316002)(6512007)(66946007)(3480700007)(76116006)(478600001)(66476007)(66556008)(64756008)(66446008)(8936002)(5660300002)(33656002)(8676002)(4744005)(6916009)(86362001)(7116003)(36756003)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: FnM5j36HXvJxsQTE0EqE6RuH9dMZ0v9NMe8J65olRpeaFYCBpgPbkXJR4Dnz9bhicbP90fJZI2VCb9fT42rbFytf0YY0KpmGrTqjmZ0LfowcmTL6A5vDSQcZlqgsORRnCUgE+oB2g4Xk2uKrKL54ypnAZZhq9oU+1eUq9FoISrPcJzr4B2ZDJpkeneB/1v/jrFyddvYPx8yDsPdgb22/HYNH1X+Jszw83tEZ9RwV+5FWM/3q/9kavXwcpsTqL7Fdjr4VF8uuZYppEr21WJhY+/LVpUTsOykRdz9ujgmUyJX+hHNpjkKozoEMClX3HQAnOF8u0lJq+dNfOPkaqKFrPfzOUkopEsZPrdjl3aUZD6vaH3+8E0TEdTQ72Bms2I5S3E70xtJSPYIFr+TxD/pOYVjKumaQdsySfenrTiPaUGJi9rRpZHz5lPPsNyz7yOo1/cJD7M4uD7H27lS59mT/i6xOamx5vCvr4YG9iHqbd8RC6X4kFNXDhsoLm0nDL64G x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_0343E3DEEF00494C862D7C0841284F42ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4070.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 44b52458-b23f-4c0f-5766-08d8328a54b1 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 00:08:17.8690 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: adKshs4zN/OKPRGK3TFG0sgwmgYESc1Um5m04npUp5U35CXkbb0uOM4oYE67JAMIjmFUTpmty8whb+XsJFmi9g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4450 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: [saag] RATs report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 00:08:27 -0000 --_000_0343E3DEEF00494C862D7C0841284F42ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UkFUcyB3aWxsIG1lZXQgdGhpcyB3ZWVrIG9uIFR1ZXNkYXkgSnVseSAyOCAxMzowMC0xMzo1MCBV VEMgYW5kIFdlZG5lc2RheSBKdWx5IDI5IDExOjAwLTEyOjQwIFVUQw0KV2Ugd2lsbCBiZSBkaXNj dXNzaW5nIHRoZSBmb2xsb3dpbmcgZHJhZnRzOg0KDQogICAgICogICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJhdHMtdHBtLWJhc2VkLW5ldHdvcmstZGV2aWNl LWF0dGVzdC8NCiAgICAgKiAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtcmF0cy15YW5nLXRwbS1jaGFycmEvDQogICAgICogICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1iaXJraG9sei1yYXRzLW5ldHdvcmstZGV2aWNlLXN1YnNjcmlw dGlvbi8NCiAgICAgKiAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJp cmtob2x6LXJhdHMtcmVmZXJlbmNlLWludGVyYWN0aW9uLW1vZGVsLw0KICAgICAqICAgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1yYXRzLWFyY2hpdGVjdHVyZS8N CiAgICAgKiAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcmF0 cy1lYXQvDQogICAgICogICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12 b2l0LXJhdHMtdHJ1c3R3b3J0aHktcGF0aC1yb3V0aW5nLw0KICAgICAqICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmlya2hvbHotcmF0cy1zdWl0LWNsYWltcy8NCiAg ICAgKiAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJpcmtob2x6LXJh dHMtdWNjcy8NCiAgICAgKiAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXNoYXctcmF0cy1yZWFyLw0KDQpXZSB3aWxsIGFsc28gZGlzY3VzcyB1cGRhdGluZyB0aGUgbWls ZXN0b25lcyBhbmQgY2hlY2tpbmcgV0dMQyByZWFkaW5lc3Mgb2YgdGhlIGFyY2hpdGVjdHVyZSBk cmFmdC4NCg0KQmVzdCwgTmFuY3kNCg0KDQo= --_000_0343E3DEEF00494C862D7C0841284F42ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <66793EF776238A49B51E2F6D66C63174@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjIwODk5NTIxNTsNCgltc28t bGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTQ3ODgxMDEzOCAtMTI5 OTEyNjMwOCAyMDU2MTMxNDk2IC0xOTEzNjA2Nzg0IDE5NjM0NjYwNjAgMTczNzI3NjE2OCAtMTE1 Mjg4NzE2MCA0OTk2NDg2ODggLTE4Nzg1MTUxMjIgMTkyMDA3NDc1MDt9DQpAbGlzdCBsMDpsZXZl bDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OuKA ojsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsc2Fucy1z ZXJpZjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBs MDpsZXZlbDINCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OuKAojsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrigKI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkFyaWFsIixzYW5zLXNlcmlmOw0KCW1zby1iaWRpLWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ64oCiOw0KCW1zby1sZXZl bC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsc2Fucy1zZXJpZjsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OuKAojsNCglt c28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDri gKI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkFyaWFsIixzYW5z LXNlcmlmOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0 IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ64oCiOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJBcmlh bCIsc2Fucy1zZXJpZjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0OuKAojsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrigKI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkFyaWFsIixzYW5zLXNlcmlmOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjIwODgxNDA3OTA7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMjMyMDUzODIyIC0y MTk5NjE0OCAxNDQ2NjYwMjc2IC0xNDY0MzMyMDU0IDE2NzUzOTI2MzAgNzE3MjU5MDYwIDEzMjkw OTc0NjggLTQ4NTMxMjA5NiAtMTQ4NjQ2MjMxMCAzODQwNzA3MjA7fQ0KQGxpc3QgbDE6bGV2ZWwx DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrigKI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQXJpYWwiLHNhbnMtc2Vy aWY7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrigKI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkFyaWFsIixz YW5zLXNlcmlmOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBs aXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ64oCiOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJB cmlhbCIsc2Fucy1zZXJpZjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0OuKAojsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiI7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrigKI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkFyaWFsIixzYW5zLXNlcmlmOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ64oCiOw0KCW1zby1sZXZlbC10YWItc3RvcDoz LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsc2Fucy1zZXJpZjsNCgltc28tYmlkaS1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OuKAojsNCgltc28tbGV2ZWwtdGFi LXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJbXNvLWJpZGkt Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrigKI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkFyaWFsIixzYW5zLXNlcmlmOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ64oCiOw0K CW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsc2Fucy1zZXJp ZjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0Rjcy Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UkFUcyB3aWxsIG1lZXQgdGhpcyB3ZWVrIG9uIFR1 ZXNkYXkgSnVseSAyOCAxMzowMC0xMzo1MCBVVEMgYW5kIFdlZG5lc2RheSBKdWx5IDI5IDExOjAw LTEyOjQwIFVUQzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5XZSB3aWxsIGJlIGRpc2N1c3NpbmcgdGhlIGZv bGxvd2luZyBkcmFmdHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4t dG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJk aXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwyIGxm bzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJhdHMtdHBtLWJhc2VkLW5ldHdvcmstZGV2 aWNlLWF0dGVzdC8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt cmF0cy10cG0tYmFzZWQtbmV0d29yay1kZXZpY2UtYXR0ZXN0LzwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwyIGxm bzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJhdHMteWFuZy10cG0tY2hhcnJhLyI+aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1yYXRzLXlhbmctdHBtLWNo YXJyYS88L2E+PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1saXN0OmwxIGxldmVsMiBsZm8xIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmlya2hv bHotcmF0cy1uZXR3b3JrLWRldmljZS1zdWJzY3JpcHRpb24vIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1iaXJraG9sei1yYXRzLW5ldHdvcmstZGV2aWNlLXN1YnNjcmlw dGlvbi88L2E+PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1saXN0OmwxIGxldmVsMiBsZm8xIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmlya2hv bHotcmF0cy1yZWZlcmVuY2UtaW50ZXJhY3Rpb24tbW9kZWwvIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1iaXJraG9sei1yYXRzLXJlZmVyZW5jZS1pbnRlcmFjdGlvbi1t b2RlbC88L2E+PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1saXN0OmwxIGxldmVsMiBsZm8xIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1y YXRzLWFyY2hpdGVjdHVyZS8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtcmF0cy1hcmNoaXRlY3R1cmUvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDIgbGZvMSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtcmF0cy1lYXQvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLXJhdHMtZWF0LzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzEiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC12b2l0LXJhdHMtdHJ1c3R3b3J0aHktcGF0aC1yb3V0aW5nLyI+aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdm9pdC1yYXRzLXRydXN0d29ydGh5LXBh dGgtcm91dGluZy88L2E+PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1saXN0OmwxIGxldmVsMiBsZm8xIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt Ymlya2hvbHotcmF0cy1zdWl0LWNsYWltcy8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWJpcmtob2x6LXJhdHMtc3VpdC1jbGFpbXMvPC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDIgbGZv MSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJpcmtob2x6LXJhdHMtdWNjcy8iPmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJpcmtob2x6LXJhdHMtdWNjcy88L2E+PG86cD48 L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0Omwx IGxldmVsMiBsZm8xIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2hhdy1yYXRzLXJlYXIvIj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zaGF3LXJhdHMtcmVhci88L2E+PG86 cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+V2Ug d2lsbCBhbHNvIGRpc2N1c3MgdXBkYXRpbmcgdGhlIG1pbGVzdG9uZXMgYW5kIGNoZWNraW5nIFdH TEMgcmVhZGluZXNzIG9mIHRoZSBhcmNoaXRlY3R1cmUgZHJhZnQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5CZXN0LCBOYW5jeTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0343E3DEEF00494C862D7C0841284F42ciscocom_-- From nobody Mon Jul 27 17:12:55 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DA03A07D6 for ; Mon, 27 Jul 2020 17:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=baJraxFs; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=SrV7WvI9 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 6Jufehh4JowT for ; Mon, 27 Jul 2020 17:12:51 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B0043A07CA for ; Mon, 27 Jul 2020 17:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9081; q=dns/txt; s=iport; t=1595895171; x=1597104771; h=from:to:subject:date:message-id:mime-version; bh=WrOX4QUtVW3tKKT4A1+5IB/T0rT35jNa3iZ10XiSK7Q=; b=baJraxFsWrtZ06Pa24aCrUlcOVHO5xFD5lTiacRkqocEyHlNe7b9+LCr c1oyeiKGaiEq2yefgjoYmGfTW8zpSft1jQjbRXy9tDyzysy/r2d3riDj3 RjIRgxd1+auHSh1ITc5RUND93Smp1v+aC8ZSfw+pNd8HFcP2NsR7UNNsU M=; IronPort-PHdr: =?us-ascii?q?9a23=3A9WGaAxJsJMBqi2eAIdmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvK8/jVLVU8Pc8f0Xw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoMEVJFoD5fVKB6nG35CQZTx?= =?us-ascii?q?P4Mwc9L+/pG4nU2sKw0e36+5DabwhSwjSnZrYnJxStpgKXvc4T0oY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DkCACJbB9f/5RdJa1gglOBIy9RB29?= =?us-ascii?q?YLywKhCqDRgOhS4RsglMDVQsBAQEMAQEjCgIEAQGETBmCEAIkNwYOAgMBAQs?= =?us-ascii?q?BAQUBAQECAQYEbYVcAQuGChEKEwEBOBEBGjACBDAPCBAENYMEAYF+TQMuAQ6?= =?us-ascii?q?kVAKBOYhhdoEygwEBAQWBR0FCglkYgg4DBoE4gm2DWYY3GoIAgREnHIN0gXM?= =?us-ascii?q?CAwGCCIJpM4ItkmCGWZw1CoJeiFaRGAMegnucaYgniW+BaIhGlGwCBAIEBQI?= =?us-ascii?q?OAQEFgWkkgVdwFWUBgj5QFwINkg+FFIVCdDcCBgEHAQEDCXyOAgGBEAEB?= X-IronPort-AV: E=Sophos;i="5.75,404,1589241600"; d="scan'208,217";a="794824861" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jul 2020 00:12:50 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 06S0CobM027831 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 28 Jul 2020 00:12:50 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Jul 2020 19:12:49 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Jul 2020 19:12:49 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 27 Jul 2020 19:12:49 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xegj+bQqhIdbzAmfk2gp1CYS6MwOdA4Dht9gYjEAiPw38s8nNU7084EY2kNlNB/Xq40AZ3EQDIzc3k1+MhvBL4YBx7xH5/vo1bNdVJhI5G+TgfQYqmM8nCXwUU9HHJrtTNaInuZgTBm6YkhUKLkBEVZGueMfHrosTO6KHCm2NcP8OAF+3xf5nO4R2jC3y/SjwYf23cT12IWcXApptHMoxuo/bQM/Ll1+2Cr24phGolaBhKX2rUhb/Vu9HSdsUw3Af/6PmRmT6TspLmziG3u4a+j+TfcvXId8Zwvjc0MNCIKrO0fj7V/qX1Hn0a/rlloGlazI+qzdMdzi9G/ZffEvuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WrOX4QUtVW3tKKT4A1+5IB/T0rT35jNa3iZ10XiSK7Q=; b=OUzj6sN8DT1nKDqEnIttLh0aej3citO58u+0+q+VN4bXqNcAK8OYO8ZanpGS66JXphGdQ03AcbzMPJQDTjfS6JU8ixgOIbYOhIHDtzxDGKzkTLzvcdjZkStS36NSVdkdqMY7VmnYs4LI2MEO3mxsDUXQki7yGamBi5EjUlzNxO2uyvdDhHWcSQTvYybVIpJvPfc70VjSnXzTxYClP6kaoyl8Ym2GzzDx3ADzOgXRqWEERdNxcVFdPfc58OVU35P5+LmWldP1a+ZYunNmlUHiMJk7d2l+Jc4sjZ5455YubVNetRiDXsMWBW0bO1YqvsXgIWWwcYQNBRKW/6ka+StoRg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WrOX4QUtVW3tKKT4A1+5IB/T0rT35jNa3iZ10XiSK7Q=; b=SrV7WvI95zXDRpY3TfKHSgQ181+Ot1PxWqJgIJSDKvZp7WTqHT3dhH8XmqGwOJBhMPCxSxfDSOMjd+It8xtPD69fCd7fRyT2945j3MaFIKY20Pw8vaJMgAC1APaXD5qnldofx9/d+awZqnERIDuLvqq1jLJPCTO1+3UMhmxUHbs= Received: from BY5PR11MB4070.namprd11.prod.outlook.com (2603:10b6:a03:181::16) by BY5PR11MB3877.namprd11.prod.outlook.com (2603:10b6:a03:186::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.23; Tue, 28 Jul 2020 00:12:48 +0000 Received: from BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::e42f:216e:af3e:8ce5]) by BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::e42f:216e:af3e:8ce5%7]) with mapi id 15.20.3216.033; Tue, 28 Jul 2020 00:12:48 +0000 From: "Nancy Cam-Winget (ncamwing)" To: "saag@ietf.org" Thread-Topic: TEEP report Thread-Index: AQHWZHPTLeLm4WatU0WRj7iEeDtaxw== Date: Tue, 28 Jul 2020 00:12:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.18.200713 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [73.162.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9a67c660-7115-4c08-888d-08d8328af5f8 x-ms-traffictypediagnostic: BY5PR11MB3877: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Bo05uBP84TVnzs24dNoAtjJJnhCotkNG6K764sZs4+N7lgbIAqYg6VyjM7Ey2AWGMKn330cfmrOzf9aSLRKRtyoQhEO40rzrIGOzHeHIRmj00eWgBR2OPsQeOpNjnyZVH+cw35ZTMtELtHJ/n93JFWN3dWj6WQVCihdMaTOrR+uokqbhpaD2BVh6mc9W5poqj3qJrZHYzAp15GcugRLbOUZbL+TWfaqPpQofx/SO9mHtHIgq0ETlNpr7QnlJCI48t8yChIY/EfWMR0iIDge05Z/arNkPV3nW+dS9qg6JXLfrD4YjGE1W6O977+XbJatWy+pWTVftZBmbK+4cKYYjS46yJ5dpcS1CyCPNir/J+SZpv3gNI+CYJ2Ld7TFC2bRk8xo8OOm/vZ9DHZ5QKDdQ9g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4070.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(366004)(39860400002)(396003)(346002)(2906002)(83380400001)(8676002)(33656002)(2616005)(26005)(5660300002)(186003)(6512007)(71200400001)(8936002)(66476007)(6486002)(66556008)(6506007)(66446008)(64756008)(3480700007)(478600001)(7116003)(6916009)(66946007)(966005)(76116006)(36756003)(4744005)(316002)(166002)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: exq4T4mnbclK9+51B9xTl+HuNaPI79ucOoKF1jNX5v6Mgy20UWRBCGFKS5MIDGklsBSJx6Gla8wi/mSd1uorJzxLIDnD98X8N5OsL9LvE99R1DRX8UOR8oCynOSCMCn74z5fx73Eha5APBXiSj255QID7ytuAglJQdf6TbeLPCPhPeMnSGygBxl03yZyDYjb5RXAVxbv0nIZg/E3zHsg/4eLC2cfxCy8lA02dZaf3fwrtC1U33XD1Gd8ykCM+lJ6fJsdRV8UhE8ZUzdDUByuz+gBVVfMLtPs/hhVRJKhEGzfaUm2kYHYDM7Frh3P/Lrvngfut+YCJpPIdRoa26DtLzZFo1J9OH/ERBlQ7g3J0R/Cnw8p1hhiLfYyfcysnZe1VW1EgfRvJpLnz3DbHQ1YH6b+wSFSe6aQARTHVSYCZOY6Ry8RZk6tPqiBoVH3ZEw84sPnGKyX8ItQUIiS8yNtdSG0xMD52iAqWJawgM8KStYQe/VbBGIVm5loUEklW9Mt x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DA60B80BBF1840E491B60C85FE5E9C11ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4070.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9a67c660-7115-4c08-888d-08d8328af5f8 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 00:12:48.4707 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: OObSt7ntu6T4IqagbLFV1yAHMbpLkGIInewD6QgiVPg7y8YaV6H1bknGZwpVkkUXX0BVJki6/waU800jVseceg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB3877 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: [saag] TEEP report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 00:12:53 -0000 --_000_DA60B80BBF1840E491B60C85FE5E9C11ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VEVFUCBtZXQgdGhpcyBtb3JuaW5nIChKdWx5IDI3LCAyMDIwIDExOjAwLTEyOjQwIFVUQykgYW5k IGRpc2N1c3NlZCB1cGRhdGVzIHRvIG91ciBjdXJyZW50IGFkb3B0ZWQgZG9jdW1lbnRzIGFuZCB0 aGUgbGFzdCBIYWNrYXRob24gaGVsZCBpbiBKYW51YXJ5DQoNCsK3ICAgICAgICAgQXJjaGl0ZWN0 dXJlIOKAkyBkcmFmdC1pZXRmLXRlZXAtYXJjaGl0ZWN0dXJlPGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGVlcC1hcmNoaXRlY3R1cmUvPg0KwrcgICAgICAgICBU RUVQIG92ZXIgSFRUUCB1cGRhdGUg4oCTICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLXRlZXAtb3RycC1vdmVyLWh0dHAvDQrCtyAgICAgICAgIFRFRVAgUHJvdG9j b2wg4oCTIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGVlcC1w cm90b2NvbC8NCsK3ICAgICAgICAgSGFja2F0aG9uIHJlcG9ydA0KDQpXZSBhbHNvIHJldmlld2Vk IHRoZSBtaWxlc3RvbmVzIGFzIHdlIGFyZSBjbG9zZSB0byBoYXZpbmcgdGhlIEFyY2hpdGVjdHVy ZSBkcmFmdCByZWFkeSBmb3IgSUVTRyBwdWJsaWNhdGlvbiBhbmQgc2ltaWxhcmx5IGZvciB0aGUg dHJhbnNwb3J0IGRyYWZ0Lg0KDQpCZXN0LCBOYW5jeQ0KDQoNCg== --_000_DA60B80BBF1840E491B60C85FE5E9C11ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjM0MDYyMTAzNTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTk0Njk3ODY4NiA2NzY5ODY4OSAyMTAxNTkzODAgLTExMjY5 MDk2MjggNDk3MDgwNzg2IC05NDQ2MDAxNTQgLTgyMzg3NDQwNiA1OTQzMDM4MjIgMTA3ODA5ODI2 MiAxMTEyNzEwOTYyO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtc3Rh cnQtYXQ6NTA0ODsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ64oCiOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJBcmlh bCIsc2Fucy1zZXJpZjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9 DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo3NjAyMjQzMTE7DQoJbXNvLWxpc3QtdHlwZTpoeWJy aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi03OTU3MzM4NzggLTEyODM5MDI0NiAyMTAxNTkz ODAgLTExMjY5MDk2MjggNDk3MDgwNzg2IC05NDQ2MDAxNTQgLTgyMzg3NDQwNiA1OTQzMDM4MjIg MTA3ODA5ODI2MiAxMTEyNzEwOTYyO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtc3Rh cnQtYXQ6NTA0ODsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ64oCiOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJBcmlh bCIsc2Fucy1zZXJpZjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VEVFUCBtZXQgdGhpcyBtb3Ju aW5nICg8L3NwYW4+SnVseSAyNywgMjAyMCAxMTowMC0xMjo0MCBVVEMpIGFuZCBkaXNjdXNzZWQg dXBkYXRlcyB0byBvdXIgY3VycmVudCBhZG9wdGVkIGRvY3VtZW50cyBhbmQgdGhlIGxhc3QgSGFj a2F0aG9uIGhlbGQgaW4gSmFudWFyeTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QXJjaGl0ZWN0dXJlIOKAkyA8L3NwYW4+DQo8L2I+ PHU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGVlcC1hcmNoaXRlY3R1cmUvIj5kcmFmdC1p ZXRmLXRlZXAtYXJjaGl0ZWN0dXJlPC9hPjwvc3Bhbj48L3U+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZl bDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3 PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VEVF UCBvdmVyIEhUVFAgdXBkYXRlIOKAkzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPiAmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXRlZXAtb3RycC1vdmVyLWh0dHAvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLXRlZXAtb3RycC1vdmVyLWh0dHAvPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3Rl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2wi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VEVFUCBQcm90b2NvbCDigJM8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGVlcC1wcm90b2NvbC8iPmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGVlcC1wcm90b2NvbC88L2E+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IYWNrYXRob24gcmVwb3J0PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5XZSBhbHNvIHJldmlld2VkIHRoZSBtaWxlc3RvbmVz IGFzIHdlIGFyZSBjbG9zZSB0byBoYXZpbmcgdGhlIEFyY2hpdGVjdHVyZSBkcmFmdCByZWFkeSBm b3IgSUVTRyBwdWJsaWNhdGlvbiBhbmQgc2ltaWxhcmx5IGZvciB0aGUgdHJhbnNwb3J0IGRyYWZ0 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QmVzdCwgTmFuY3k8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DA60B80BBF1840E491B60C85FE5E9C11ciscocom_-- From nobody Tue Jul 28 01:53:45 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23143A0913 for ; Tue, 28 Jul 2020 01:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTmOBdRQAPLv for ; Tue, 28 Jul 2020 01:53:41 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 CBAC83A090D for ; Tue, 28 Jul 2020 01:53:39 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id i80so10555008lfi.13 for ; Tue, 28 Jul 2020 01:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet.se; s=google; h=to:cc:from:autocrypt:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=0xbM0XBLOHiJb5rY3c4/8U+gXyYnSySToPF+5UrkHRc=; b=cWMoB8z27SRbg4T/WFxI3Y48p+AUKXscR9f9b/uPABm2z0csPsJGkmGABTmti9RtJc usCTuwbrvmw8qNMksFKfstWGQfVrECscZWgeqG8A0O81Fb/blKE/oDtSasRD3UUz7OoP xSasgh9dObja50XD3q1uQI6CSMkas9h/akoejnoXAHd+avGYmBwFB05AMoicmgaLMT8n zXV5liBLJauPV/wrJYjzLNh+myvPmQUMSY/G8n3WCv5N5KDiwaCgnx6egU1DpcPPR1RC wxgsL7mSqczrIk+b+4cTGat2kZjsxcjGaPdxFtr+PYrCt6Nkso/eMa3Vy90IiWTF/LX4 zBWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:from:autocrypt:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=0xbM0XBLOHiJb5rY3c4/8U+gXyYnSySToPF+5UrkHRc=; b=YYO08q8ciJ9pHX29ZkC4r57W7XTy+WO3R3M6O1d8wAYcB5uS1gWYfarCZz8ld/HyYt cWUJIbSxoAyYu8MS5iALOas/s61YC+/hvQ2yRTU0lLhUOH+qKhTSIkHp0lMmmUvc4GUF eTgKrEEgrGGWJEoCGNRfHgk3mlqilZgM2CIp/KcCL/srHCrcwqqBA1unqnoqeVC5HPC8 tby1MKQ24I7Mk0pRag49pZ1lzSDdKBBZHlADqWvDEl710u1+JlgEaCU/1sHmBLOcJG2H VsixDc1RnO6CR32OZUmOLOIXTwAVsFlgGPD60bEea8J9kpV3Lmw1NN1s/7Hk6uSjgJNp cM6A== X-Gm-Message-State: AOAM530b9JNWESNb4tUNuT8gU2ViAukfZ8VvzPqmTeRXzxYtMEtEABjH jRrDVyduFGcN4FwJo2j2AR5G0Q== X-Google-Smtp-Source: ABdhPJwbYi92JU79GfrVSNBTCOEi6BmbEWDkk9Yg1gFzATiKCO2BFmRgR7hU9INNKUqBZlwZN/sOLw== X-Received: by 2002:a05:6512:2082:: with SMTP id t2mr14420410lfr.142.1595926417694; Tue, 28 Jul 2020 01:53:37 -0700 (PDT) Received: from [10.0.0.129] (h-98-128-228-179.NA.cust.bahnhof.se. [98.128.228.179]) by smtp.gmail.com with ESMTPSA id l4sm2833571ljc.83.2020.07.28.01.53.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jul 2020 01:53:37 -0700 (PDT) To: saag@ietf.org From: Leif Johansson Autocrypt: addr=leifj@sunet.se; prefer-encrypt=mutual; keydata= xsBNBFJK9qIBCACypED81H1N4YmhMJrb4uOtTDzo+lFZDVVOcK11+NhTFl+AZZFnWH/7UPn+ q5ZZBd/IhONfb5QGw5FzTyBWHsbAteXgCvHAIyumwhQzhZnow6myyC6/MwDhomT5rb3MkCKC yQMNfj/yMgL6ZRsXVhlGOLMmOekRfKe2wiC5BhRaQQwPZPwgFS5D0Tro8Xfxjk98u8rNpQXi 9walRAffRY+byhkPiBj0sVA2RXK9Dx2DL3EY0xx07r6Qhs2XkbXNDDCHRuChhHSHwWC16VS9 x7Nhfg2EwKqmMGRNREikjwzDl/aHKz+FXTLONdmc83sRyklqgH90f3na6s/RT5XTb08xABEB AAHNHUxlaWYgSm9oYW5zc29uIDxsZWlmakBtbnQuc2U+wsB+BBMBCAAoAhsDBgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCW7Yg8gUJDw7ExQAKCRDXOtZDCtR41io7CACOVmQcjoS7cfuF 43NhvpfFjSn91qShubrWx/p0+v/1MRyGajeMKcBd9HPDsN/lhMuY6k2zI1Qsrsycv51QQ+d0 +lPFxO3LKcrzaKqfKV3UZP3eVsMQgyP21iFIFAw424aAeBjWRhhnzlvsiP3RzF4NNb7goMWR PLWlld4M+MGqlM+T8M2Jbxl2OejedK5HCGm00IzXS7NojDGdIiXHbx0S0RloNb7ssQdFdHAH M6hO30lCwTM5jnNbejXhFUlMqYdRjWPUAbFwX3Pw9Wpkr5xz5xYbx8xPZBIG6ROp8ExxP31V NTm+DTnwJS5LLMbV1aDLYIzYlEossP2NFhLtwVDEzsBNBFJK9qIBCAC+k1tFOeDS4gMxEgRk fiVLHFemwJWQiGZHYhtDgjh6w6mB8G3WZ+/gD2CMp5DgHFRC1sW2iMj3gOzrfyxzd9AmWbhX YceR6EFkTc6OVsaIb+eHH/Zo3DKyB1Dq9CA5fjjnEQzti+KKSZYWzB0Fkt7qrfOS6YM1zMjE UxUUwsl1qirx5DuByWLDX7ULU7H/xmPVhHUVZO8XEaFV2m+ICx8Y6B98KMeJ0Qz8b8wp2g7v WEkwS2R6IjF0kMrRxnxUvwA6EUiZuFphhuY/lWCJusLl1olgOE+BKMEUStJWEi0s+pd8FL1v OLeNKbIUFro0+oZr9byABpkPNjMxKV36uj1dABEBAAHCwGUEGAEIAA8CGwwFAlu2H5wFCQ8O w3cACgkQ1zrWQwrUeNbSVAgAmRS6XxztiU9pczUwElOnolmnAIUocSXdfllZABxLX1MkZ4Yn 0jEbJKMpPOAMu7cQs4gni/AprnMae23taqJprwWCE6lTcOEhdPNKSFhdL4eE+UCd9Z9S/8PC M0GkjDF9FAWcrIBmySiHmZfAwKbHk3+AhDmY2PzN+mOzgU7t855+OtcoI02PDEXJGTCU9Mcl YtMNAlrmMmbMUApLSIoFluY35nlBVDFD3bDuCb59Nbs9aBJ9bu956G04XUcYt9sTsnkPppzX 82jyCc6Oeg9He8F1ep7AEoscflUKuwn9YF/sblqq27GO4d/BQPtaNw0iGz1H1C1QWKES4tk4 bZRWFA== Message-ID: <012bea39-0dd1-7168-1234-646d525c3b20@sunet.se> Date: Tue, 28 Jul 2020 10:53:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [saag] gnap report IETF-108 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 08:53:44 -0000 gnap met for the first time as a WG yesterday. Its early days for the WG. A design team will be formed to propose a starting point for the WG. The WG will schedule a few interrims in the next few months in order to get up to steam. Cheers Yaron & Leif From nobody Tue Jul 28 03:39:57 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9623A0AB1; Tue, 28 Jul 2020 03:39: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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nqe4UBmLSPBO; Tue, 28 Jul 2020 03:39:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A26A03A0AAC; Tue, 28 Jul 2020 03:39:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6A6DCBE4C; Tue, 28 Jul 2020 11:39:50 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIy8mD4Bw6PR; Tue, 28 Jul 2020 11:39:48 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B26D5BE47; Tue, 28 Jul 2020 11:39:48 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1595932788; bh=PtqPjkoFgWWCErfbQQr2q5/lcr5bas41zp2M7K/7KHQ=; h=To:From:Subject:Date:From; b=r7ehWs6fk33pD+rRfJ7W2Z3AYSbKGcW/Qyd9Y8y1T5R7g3wUbygmDgs9a1djKcd+z aVoy19tlQEqfKzBi19t2L774JdEWNNoezyzTCd2UtqyKEH6pz/Vl/PPGCYpJZzNRkI DtOH9PGZH0dVeUPzvoV5Ni/pFHJP51bG4gs2SlSM= To: "saag@ietf.org" , "lake@ietf.org" From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <3a530edc-33de-c450-6ad1-02b003536d96@cs.tcd.ie> Date: Tue, 28 Jul 2020 11:39:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Qo5xudQqAc1IDxKOuvG1SnqEfHUVFwRlU" Archived-At: Subject: [saag] LAKE WG report for SAAG X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 10:39:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Qo5xudQqAc1IDxKOuvG1SnqEfHUVFwRlU Content-Type: multipart/mixed; boundary="iIfqB7R3FX9bia29rWTNYSVR0wiMuZUCP"; protected-headers="v1" From: Stephen Farrell To: "saag@ietf.org" , "lake@ietf.org" Message-ID: <3a530edc-33de-c450-6ad1-02b003536d96@cs.tcd.ie> Subject: LAKE WG report for SAAG --iIfqB7R3FX9bia29rWTNYSVR0wiMuZUCP Content-Type: multipart/mixed; boundary="------------B270BE7A518D98ECA3A5B78E" Content-Language: en-US This is a multi-part message in MIME format. --------------B270BE7A518D98ECA3A5B78E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The LAKE WG will meet on Friday. The main news since IETF106 is that the WG finalised the requirements (in a draft to be parked and not submitted for publication as an RFC). The TLS WG subsequently adopted the work on cTLS and the LAKE WG adopted the work on edhoc, so both proposals are in-work for the present. Cheers, S. PS: For anyone on the lake list finding this odd: all the security area WGs send a report like this to saag each IETF meeting. --------------B270BE7A518D98ECA3A5B78E Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------B270BE7A518D98ECA3A5B78E-- --iIfqB7R3FX9bia29rWTNYSVR0wiMuZUCP-- --Qo5xudQqAc1IDxKOuvG1SnqEfHUVFwRlU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl8gAHQACgkQWrL68XsX K+olxg/+J94UePxGSdzUa6hlA1A18Lfyy8u7TAREjGcPKnFM8GJVO0EVSlGFJTQs j5nSMS1CrM0lQNJTgS93Hw4HC3OEyVhjDNKd9Y5D3ypxktXH8U6PwXdTuxx1ir7d bHJtfU9FiJv4KBCB+RVpQbsN8FsT7i4O411jMW8iK1i8DJhYsmm3Npgoaaf0P4EO Q7yryDx+S8XAMdiICJC6lzZvr/NhX9i2YNkjpI1KsHTeGG6zyuvcnmgMJqUSLeFO Gy+FRKge2Q5iKz1K+vAerfC3Mz3uoDBD6xzvjHJWxbQDlbI489ZiQ0Q/nBOG6plv MiY2kw/Lq3f/W9wKxz9aU8p4Nlt54d1K4J8ZaVot2ubeufYeriexkF285WgrJpFH bxnm9KkQB81yOcnvuQOW2whqTNcjNVf9Y3D4e+yOge+vJRykJd0MdDuPa3jQf2Rt eJTtf5ry2qbx+zyc9ZCTUrNEnYDJW82NoAqLOTTSDUjDXK4ZdHtUEtgr2+ijhefp 3DqriyvlsD3AGkOTQntUpyk68S14LNrC9ufu3omXJRvFXBXSKEHW1gX/pBwG7U6b ReKSTR9hmidf/odpabZB15+e0vo0i21AQcsrSv8hetnpY0IPiNgbvUtevDI45wLd t2ztowM7KEGU603pTAmjMaGJkuUVmAxWORfHegQ4YSvlFxN5pdo= =V9eU -----END PGP SIGNATURE----- --Qo5xudQqAc1IDxKOuvG1SnqEfHUVFwRlU-- From nobody Tue Jul 28 06:12:09 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3043A0C13 for ; Tue, 28 Jul 2020 06:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL9-MUjlZAra for ; Tue, 28 Jul 2020 06:12:05 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D4443A0C10 for ; Tue, 28 Jul 2020 06:12:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 98AA6300AEC for ; Tue, 28 Jul 2020 09:12:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mNgAYYj4VKH9 for ; Tue, 28 Jul 2020 09:12:01 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 4DB75300A55 for ; Tue, 28 Jul 2020 09:12:01 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Message-Id: <3AFCE10B-E09D-452D-91AA-95CFCDDB6346@vigilsec.com> Date: Tue, 28 Jul 2020 09:12:02 -0400 To: IETF SAAG X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: [saag] LAMPS at IETF 108 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 13:12:07 -0000 Summary of the LAMPS WG Agenda at Virtual IETF 108: 1) draft-ietf-lamps-5480-ku-clarifications: in the RFC Editor queue. 2) draft-ietf-lamps-rfc7030est-clarify: on the IESG Telechat agenda for 2020-08-13. 3) draft-ietf-lamps-cms-update-alg-id-protect: in IETF Last Call. 4) draft-ietf-lamps-ocsp-nonce: just completed AD Review. Once those issues are resolved, it will go into IETF Last Call. 5) draft-ietf-lamps-cmp-updates: needs an updated ASN.1 module, then it will be ready for WG Last Call. 6) draft-ietf-lamps-lightweight-cmp-profile: nearly complete, but depends upon draft-ietf-lamps-cmp-updates, so it will go to WG Last Call after that document. 7) draft-ietf-lamps-header-protection: active discussion. From nobody Tue Jul 28 06:22:47 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD223A0BA8 for ; Tue, 28 Jul 2020 06:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 q0_TZt2E3fNV for ; Tue, 28 Jul 2020 06:22:43 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60077.outbound.protection.outlook.com [40.107.6.77]) (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 821AE3A0C49 for ; Tue, 28 Jul 2020 06:22:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hihvWQoncrtEun1L2MmNFQ/RJXnbigr8gKmQUAbsfUtSXm+WdHz9CEB0NzRp4LmjSXQir4RYaTJlQvVrMgEKrspof6hE5ZSqJEI3ybC24sKy2mDE7RkTc8VclGhSbTeUAA9vX50U6ZREsHfW9PzDJdEQSpTibikE/0ZdqQIEKp32QAz2JLHXyy2ybGXajRhZfSC+jgotYStVRs2kfronVvtqsLIthXj5rDUCNKctwKuCmMyCjTAX+Vx4WWpweqxGl5j2PlObT3a7WOjIIzN7AN7/y4NBcgVFcEca8Qb0KzGTkS7LKLi4y6Ce2gECnL0cuaFi9CpiVO+8wy7pw7iUQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+3jGYEZjBedHGwyhGHnr/mGxpSQAMt6ABMmJjqEjFBQ=; b=ZT1NtDBO0VwE6KrVpNhOO33rgq1L7ou9kqZLER7OPobFZlfqqSylYuewrkqGti1Dj6WMrHv9nxA5u8OxsdMLiITF2pk+ihyQ4AmMw/kJHf0+wHBg32PFCBrueRp/kym5FA0W4vGKJlLgX+rT5d9quRyuRyCskmaJvU92VSHf317XuzDMUVHBl2HYl82aiRxt39kEE4hY0vVQsV9g9kdl2zjLF61LGm/FoNPD09ferVdq/PBcNhSrydhcT3VCt77prd1RiaNFv8WCHOQTw78XffqYMr4MHiAWDdA9uiXhdxXuKRXVOwDC8Ag8WsWFB8EUYqVQpd/8DEkNRgktoFwaHA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+3jGYEZjBedHGwyhGHnr/mGxpSQAMt6ABMmJjqEjFBQ=; b=XYUzg8Q21yjTV5znEWyOdgcF9BBS0vb5agvdeh0/NOyJBZcUIeL2+piuCQiIm9Jtu8J1VmyQcgPOTGGFcBM6RnTZ0Q78/KQq07S364UwYJ8Mz7mHNvAjqhXOFDijwZh5CtFfTpaLyC+LpuPmWcHTvo5IWgfQwLNjbiO6rnt/s5A= Received: from HE1PR07MB3386.eurprd07.prod.outlook.com (2603:10a6:7:2d::25) by HE1PR07MB3145.eurprd07.prod.outlook.com (2603:10a6:7:31::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9; Tue, 28 Jul 2020 13:22:39 +0000 Received: from HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::e01c:9809:43db:67d3]) by HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::e01c:9809:43db:67d3%6]) with mapi id 15.20.3239.015; Tue, 28 Jul 2020 13:22:39 +0000 From: Mohit Sethi M To: "saag@ietf.org" Thread-Topic: EMU @ IETF 108 status Thread-Index: AQHWZOIpWmcBpygglUmfOFr76MlWAw== Date: Tue, 28 Jul 2020 13:22:38 +0000 Message-ID: <4756c190-2d12-a264-1516-323ec54fb043@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:190:b4e:bc35:fff1:5691:3b9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e7a9d0c9-d1b4-4b69-daeb-08d832f94cf1 x-ms-traffictypediagnostic: HE1PR07MB3145: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VHHg0xeYM1FX2GUzDObK5vQ8rMAF6MAkfXkdnq7QX+Ku8BzC7bkli3lE+Mtph07nGulHk8xJvFQNFeSwtlND3WhzVPwZC0Xg8i+6NaJqw6QP4Uo0YMmvToieBZb8ZplI5TBUPRAc0Zd8oZJYU+px60HGJLEE+iWUzMA5CS/FMQZkwhpAhCRLHQlPxT2t5+aYZfyFfNxOx1Dh8EG4rcSYrks0Ub6Qii6CycJ0WDRCLtvpIK2W1hZ4jfDOL8ZxAOrXjEhUT7H3a78E3TE1lsl+BRJxvZI2H8iRbDALccscRTP4d6OVUUappvP+JFovaQ3mlp87cgR4tY69VcZexvJo78W76b0iCE5ZNrNIUtOyZeShpKWBPnvy1h9AyqxUByRn x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(346002)(366004)(136003)(376002)(316002)(8936002)(6512007)(31696002)(31686004)(83380400001)(478600001)(2906002)(186003)(86362001)(6486002)(66556008)(64756008)(66446008)(36756003)(76116006)(66946007)(66476007)(2616005)(8676002)(4744005)(6916009)(5660300002)(71200400001)(6506007)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Hh3ycvmMwVvmFH7F1eDju+HeyzsuuTkQ+z+D95EiCU8ebS7nchpdPszUwgFagwfl0BuAYb2PX7vFyF3xVL1j2IvNE7jAnq9UjA7agLj2iAlC30wDRpOLZ4AI5YFjJQFwyetsdb68DK+xP9LY3nmvO1hl9eU97RiI4SIvVN9l96aYAKGgWh91suJSvCjGquZae9RH3Y2Kcc2l/+pn+eFNfcKTjgqi8AO6qn8eJ7I1KmTvgKLJsj0AUjvwCu1PzhsLR6sY3qfG/1jrEUUKfFA9gImY2J4PAcEFo2K7oA9i6IWz4nTRlCNFW35yacyjfzGf9quKPX9lpbegcUhUMHh/AXj1lDJETToM7xMD3wmAOFHMXfB3Ftqe8c8fJX/USl75qa32F6/UWWshSJO4e/ZiUSWa2JsTtDQNkAj35C94CpSleX/o4aYEqd0UjUIGvwT8AIsIOBs8S5v0JeU56xv600ku5OHytq2ZlbcOYagUzCsjfT61kZu/Vngw6kl/1QW+q6jN1yaplPAKgjSC7hExbQEFhYT+20llOOpghAvJMuSliMKZmHyoyjV+1Lf7UbXDvZHoEEQpLuYM3nzhxTpLdOcypsbEf1m4nvHaaHdC7EkZg0elHSuRGBMLBXXpsICnERUC5MeisR1wloxdgWJi740nYuIkUySNU3ts8uSBLW9IiYL2w1xlMVWjcwp6Hx/4yUszI566wDMd6S+UTzhqvA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <277A4DBFD48B5A41BC6731BB5913BE28@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3386.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e7a9d0c9-d1b4-4b69-daeb-08d832f94cf1 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 13:22:38.7591 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dT2Eu04SQdoLSxpfhh729vIBNOpZNE+r5gZWM1Mz1lvSveOMggomcZZaJz1MfsoT34tu2hSvzQwRJixpvhlabMuQQ2mAf5HmuYjZRinLBis= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3145 Archived-At: Subject: [saag] EMU @ IETF 108 status X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 13:22:47 -0000 VGhlIEVNVSBXRyB3aWxsIG1lZXQgb24gRnJpZGF5IChKdWx5IDMxKSBiZXR3ZWVuIDEzOjAwLTEz OjUwIFVUQy4NCg0KU3RhdHVzIG9mIGNvbXBsZXRlZCB3b3JraW5nIGdyb3VwIGRvY3VtZW50czoN Ci0gZHJhZnQtaWV0Zi1lbXUtZWFwLXNlc3Npb24taWQgKENsZWFyZWQgdGhlIGxhc3QgRElTQ1VT UyBhbmQgd2lsbCBzb29uIA0KZ28gdG8gdGhlIFJGQyBlZGl0b3IpDQotIGRyYWZ0LWlldGYtZW11 LWVhcHRsc2NlcnQgKFdhaXRpbmcgZm9yIHNoZXBoZXJkIHdyaXRldXApDQotIGRyYWZ0LWlldGYt ZW11LXJmYzU0NDhiaXMgKFdhaXRpbmcgZm9yIGF1dGhvcnMgdG8gdXBkYXRlIGJhc2VkIG9uIElF U0cgDQpjb21tZW50cykNCi0gZHJhZnQtaWV0Zi1lbXUtZWFwLXRsczEzIChBRCByZXZpZXcgYWRk cmVzc2VkLiBPbmUgbWlub3IgY2xhcmlmaWNhdGlvbiANCnJlcXVpcmVzIHdvcmtpbmcgZ3JvdXAg Y29uc2Vuc3VzKQ0KDQpVcGRhdGVzIHRvIHRoZSBmb2xsb3dpbmcgd29ya2luZyBncm91cCBkb2N1 bWVudHMgd2lsbCBiZSBwcmVzZW50ZWQ6DQoNCi0gZHJhZnQtaWV0Zi1lbXUtdGxzLWVhcC10eXBl cw0KLSBkcmFmdC1pZXRmLWVtdS1lYXAtbm9vYg0KDQpBZGRpdGlvbmFsbHksIHdlIHdpbGwgZGlz Y3VzcyB0aGUgVEVBUCAoUkZDIDcxNzApIGVycmF0YSBhbmQgdHJ5IHRvIA0KcmVzb2x2ZSByZW1h aW5pbmcgaXNzdWVzLg0KDQpUaGUgZm9sbG93aW5nIG5vbi13b3JraW5nIGdyb3VwIGRvY3VtZW50 cyB3aWxsIGFsc28gYmUgcHJlc2VudGVkOg0KDQotIGRyYWZ0LWZyaWVsLXRscy1lYXAtZHBwDQot IGRyYWZ0LWNoZW4tZW11LWVhcC10bHMtaWJzDQoNCkpvZSBhbmQgTW9oaXQNCg0K From nobody Tue Jul 28 06:29:27 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9D43A0C1C; Tue, 28 Jul 2020 06:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 YObjgmxnE9Ed; Tue, 28 Jul 2020 06:29:23 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA333A0C1B; Tue, 28 Jul 2020 06:29:22 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 4D87E1B00393; Tue, 28 Jul 2020 16:29:20 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1595942960; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=sdyb2jReLnoHCXE42j7tyqRNbd6FepuO9x3SQfBjuxE=; b=Jc7zpefORBWgv5rR05Zt1y6jJpksOM+tjtCm/qjze0e2FXOM4hqC4MrWHbRpHn0gILTa5t uLqJLK25R5SV33kh4X5I0mdgLDnRuPW9Ry0ZVQx67gv/ovPV+HFSyZZr/2NaklEzyRZr+y jQFah/O9RbVyWMfwlzFdaAvzgRBUXyi38Kgsel9MseLd3bDDaI7atslkC+Ku7CPaptbb2r r+ZDQqNPBgw4D0qU0mhjbyrPDvcBCFQ5c8w0evC9dk/iQ56OpEnHsspylimTO4sZEpdNuG LMIhz+iQzGgtn1qXfKjOWlH13ev4UVXjnVkHcPJMZVZ2TCxSHhHk8K8dUxLCGw== Received: by fireball.acr.fi (Postfix, from userid 15204) id 0655125C0E74; Tue, 28 Jul 2020 16:29:20 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24352.10287.977688.473083@fireball.acr.fi> Date: Tue, 28 Jul 2020 16:29:19 +0300 From: Tero Kivinen To: saag@ietf.org CC: ipsec@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 1 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1595942960; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=sdyb2jReLnoHCXE42j7tyqRNbd6FepuO9x3SQfBjuxE=; b=AkBHWXquyV4in+716d570bYryshV9sCfXm+4UqBI8ujNbkRK8AjuRtg9Cqnp3AtLGi4Yz2 6QObOuGWiaJ/sKoibeSwyLjLyBttg54X1bvdah4wPvrIDLDbT8JM25REXSdRmTXY1z3S7d /wZuPjXORM7CUR3lJLPDMP9Sw6kWfytdWmtcjj/F7LRH4OK0OkyhCvbWDlyxruP1ei9w27 iKvjwxvEMUxIGa8hD1kQW1ARTAoT1CHshe6gdEu+DWmQHC5UQwpJECppIpf5IKApZTVLUm 6mDPyUSWs0K3C8cVy6qMEwSyzNk29rpSgTn4nmjPnESqLcZnKS9YqhPDy8vg6A== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1595942960; a=rsa-sha256; cv=none; b=ALfK3j5SU/UVULB6EowIipNDdLa6HT3Cu8BshgSP9Od6t1FVL6uQpgYKLjBv7VYWIWo6B5 XQeP90cjZ3aUIZKLhNghY8sKrDjYeRB8Fw+N4RG9LAkNx5LBSZxvpz1lJRSwNjwZxObh0x xAiPdFsndN+qPih6Ni8AhSFwFbIHDaTc67oK0ng5qkPSWvd8I0O/e2Y7OGv005jb8OaoSE GU2jsG92spnr5yKGaoLRzWgi8uHGf4Je5K4Rr0Ksh2PcIjYsS9o/osOBzNysAnbWR/Mn6k wsFc+do1H2yJFh+tFeLwxvrfAY+5y0i+HqAO39BjdRs2Z1/v1IFEkDjGk50Usg== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: [saag] IPsec WG Report for SAAG X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 13:29:26 -0000 This has also been stored in the datatracker as status update for the IPsecME WG (https://datatracker.ietf.org/group/ipsecme/about/status/). ---------------------------------------------------------------------- Implicit IV was published as RFC8750, and Mixing Preshared Keys in the IKEv2 for Post-quantum Security was published as RFC8784. Publication requested has been issued for IPv6 and IPv4 status codes. For the existing work items, the IKEv2 intermediate is ready for WGLC, and Multiple KE should also be ready for WGLC. The G-IKEv2 draft had major rewrite to make it more inline with IKEv2. The IP traffic flow security draft is getting ready for early transport area review, and it is starting the process of getting protocol number to be allocated for it. Labeled IPsec is mostly waiting to get some implementation experience, there are implementations in the process of being developed. IKE1 IPsec graveyard draft is not yet adopted, and needs for authors to agree with ADs what to do with it, i.e., whether it will be WG item, or AD sponsored document. Clarifications and Implementation guidelines for using TCP encapsulation in IKEv2 has been changed to be RFC8229bis instead of separate clarification document, and is now getting ready for WG adoption. There is new draft for the Announcing Supported Authentication Methods in IKEv2 charter item, which might be adopted as WG item after people have had time to review it. -- kivinen@iki.fi From nobody Tue Jul 28 12:13:40 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0491F3A0B87 for ; Tue, 28 Jul 2020 12:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUY9h7fz9UpD for ; Tue, 28 Jul 2020 12:13:36 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AEBB3A0B85 for ; Tue, 28 Jul 2020 12:13:35 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06SJDW3P027173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 28 Jul 2020 15:13:34 -0400 Date: Tue, 28 Jul 2020 12:13:31 -0700 From: Benjamin Kaduk To: saag@ietf.org Message-ID: <20200728191331.GV41010@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [saag] On PKI vs. Pinning (SAAG 108 preview) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 19:13:38 -0000 Hi all, One of the agenda items for Thursday's SAAG session at IETF 108 is "Discussion on PKI vs. Pinning Applicability". This is intended to be Security Area Advisory Group in its core meaning -- I want to get the sense of the IETF security community. There are some draft slides for SAAG at https://www.ietf.org/proceedings/108/slides/slides-108-saag-chair-slides-pkipinning-bcp-72-00 (starting at slide 33; note to self: change template to include slide numbers), and in true IETF spirit I'm hoping we can get a lot of it covered on the list in advance. As a lead-in, this topic came to mind due to a thread on the NFSv4 list, discussing the RPC-over-TLS work that's in IESG Evaluation. A participant made the claim (see thread at https://mailarchive.ietf.org/arch/msg/nfsv4/SLTNqWbjE-H8JshLk0HwlwxArrI/) that certificate pinning is needed for RPC-TLS, and I did not have the impression that this was the consensus position of the IETF security community ... but I also don't have any data to support that impression (yet?). It's clear that there are benefits and drawbacks of both approaches, relating to scalability, ease of (minimal) deployment, key rotation, need for maintaining highly secure infrastructure to protect high-value secrets, how revocation is handled, whether or not having an enterprise CA is seen as a bug or feature, etc. Similarly, there seem to be some use cases that naturally lean towards one strategy or the other. A banking mobile app surely should pin the bank's known CA, rather than leaving an enterprise CA free to MITM a user's session, whereas something that wants to be part of the Web is largely forced to adopt the Web PKI. This leads to some questions that may be worth discussing (both here on the list and in-person on Thursday): Can we make a classification of what types of protocols are naturally suited for PKI scenarios and what types of protocols are naturally suited for pinning? If you're going to pin, how does it matter if you pin a (raw) public key, a self-signed non-CA cert, an arbitrary cert, an intermediate CA, a root CA, etc? Is there benefit in arranging for a description of the system where the ability to pin is just a degenerate case of a PKI, with a single trust anchor and no real hierarchy? Do we want all protocols that specify one to be usable with the other (and document it that way)? Is there utility in writing a document to cover any of the above topics? Thanks in advance for a lively discussion, Ben From nobody Tue Jul 28 12:36:42 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D06D3A0BCD for ; Tue, 28 Jul 2020 12:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBHyEjSDj4pF for ; Tue, 28 Jul 2020 12:36:38 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F8903A0BC9 for ; Tue, 28 Jul 2020 12:36:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 92028BE56; Tue, 28 Jul 2020 20:36:36 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGsgtof0NpSo; Tue, 28 Jul 2020 20:36:34 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B77CABE53; Tue, 28 Jul 2020 20:36:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1595964994; bh=iN0LRm/RCzreHXKHpYfHI6VOybUTJnXlNgWWZ/eP6yQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=AJ2m2g/I8yce0fJj0henKbKFddQU7tfNopKGA5n/AbF5UFlBhsJfeTbNQz7KMUE98 WPa4V+Wsul+JmOXBBSbn2CL6D0kBUMCBnvBC+9V8Csom05KCvf/jp8iCZEPQH1ZJAV oTcikdlS/jyQLU1u6aawZcvYXDl0SjcbPMhMaxlw= To: Benjamin Kaduk , saag@ietf.org References: <20200728191331.GV41010@kduck.mit.edu> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Tue, 28 Jul 2020 20:36:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200728191331.GV41010@kduck.mit.edu> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Io4bRPPzHSZNWBfGbbZLGfobQKpCXZqda" Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 19:36:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Io4bRPPzHSZNWBfGbbZLGfobQKpCXZqda Content-Type: multipart/mixed; boundary="yrHwBeJSdD8utd28urd1qYzJrvygiNg8l"; protected-headers="v1" From: Stephen Farrell To: Benjamin Kaduk , saag@ietf.org Message-ID: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) References: <20200728191331.GV41010@kduck.mit.edu> In-Reply-To: <20200728191331.GV41010@kduck.mit.edu> --yrHwBeJSdD8utd28urd1qYzJrvygiNg8l Content-Type: multipart/mixed; boundary="------------272690BBBAE5DFCF4100E427" Content-Language: en-US This is a multi-part message in MIME format. --------------272690BBBAE5DFCF4100E427 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Good topic. On 28/07/2020 20:13, Benjamin Kaduk wrote: > Can we make a classification of what types of protocols are naturally > suited for PKI scenarios and what types of protocols are naturally suit= ed > for pinning? FYI, in our survey of covid-tracing Apps most but not all of them do pin. When those apps are uploading keys, it'd not be good for that to be logged in an enterprise security appliance. That seems to generalise to any applications where the relevant entities would not like their data to end up logged like that (by accident or design), and where the application not working when behind a MITM is ok, or where one can expect the application to be whitelisted by such MITMs. ISTM that may be a fairly broad class of applications, certainly enough to be of interest. I'd guess some of the operators of MITMs might prefer to not be able to see some of that application data too. >=20 > If you're going to pin, how does it matter if you pin a (raw) public ke= y, a > self-signed non-CA cert, an arbitrary cert, an intermediate CA, a root = CA, > etc? Raw public key seems too much a foot-gun. Even with pinning, you still need to depend on a CA for TLS, so it seems to make sense to pin to your currently preferred CA(s) plus one other independent CA. We've seen that in at least one of the above apps. I'd guess the choice of root vs. intermediate might depend, not sure there's an obviously correct choice for that, for all cases. >=20 > Is there benefit in arranging for a description of the system where the= > ability to pin is just a degenerate case of a PKI, with a single trust > anchor and no real hierarchy? I don't get the question sorry. > Do we want all protocols that specify one to be usable with the other (= and > document it that way)? >=20 > Is there utility in writing a document to cover any of the above topics= ? I think such a document would be useful. If it doesn't already exist then doing that as an informational RFC or BCP would be useful. If one exists already that's good enough then pointing at that may be fine. Cheers, S. --------------272690BBBAE5DFCF4100E427 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------272690BBBAE5DFCF4100E427-- --yrHwBeJSdD8utd28urd1qYzJrvygiNg8l-- --Io4bRPPzHSZNWBfGbbZLGfobQKpCXZqda Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl8gfkEACgkQWrL68XsX K+r4tQ/+IQQKSy4CxkpCmuj61v6qQdaHBkTmx4M7c+lfmEPiPh7MXxxZkaiVGxr5 tqIDQszLQJOtKHf3GBRfAOe+ABac3d13gPi40cLRuZlrE57q9CoxAZ3r5/F9DnlS 1mYB2kdWP/cLvqtahZJvwAmR7R+upl1hijfbuFIJ4VuY2+lourKd8UypHHtup38X hfnrDMLhL2S/Le4wNmk0jC/jS/Ve1iujEka2zJaY3kslWWuNHyNOOmtpjk4pHIhm 0secbowdvgyf9xCpHGHWUh/REO5WHZK5AJllDc2uB+JJ2IELROKeAlqHhCH7zArD YCIiWOuJ7sH5mybIrWDspTjhVMQO1LxHRxT//TPkXojjp9sTL4bvO88Ive8Mw3jO gSYI2FAQbbipUfAwkrNxrZSImKIlOWBmcCcYFVt14EuBvJjl7etDqAgnfbYTtALd NKg20XkLwv+XCSehsjmhHcoR0N9KZBUf2GhmhHe+ButMOVXtinkvKuNkz+CM05k9 gMEtpjAdMqVAa9FV11Km88fhBUCzU3j15X4WrV4gSN9iNbvVlKeweHmjI66dEo6y 4mD6DUAiXTxsT1EzeqhI/vKNR+tLe+917YLZXaPfL8WAgC3zDkPnobG19bEmeoa9 663dOlztNfG+Pup2dn7TGTo93Vc+vNVrv6TcjyLZDwk7uDMbJWQ= =EYhC -----END PGP SIGNATURE----- --Io4bRPPzHSZNWBfGbbZLGfobQKpCXZqda-- From nobody Tue Jul 28 12:42:57 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF3C3A0BD0 for ; Tue, 28 Jul 2020 12:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlOaw-4XDJA1 for ; Tue, 28 Jul 2020 12:42:52 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1CC53A0BCE for ; Tue, 28 Jul 2020 12:42:51 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06SJgZLW013993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Jul 2020 15:42:38 -0400 Date: Tue, 28 Jul 2020 12:42:35 -0700 From: Benjamin Kaduk To: Stephen Farrell Cc: saag@ietf.org Message-ID: <20200728194235.GY41010@kduck.mit.edu> References: <20200728191331.GV41010@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 19:42:54 -0000 Hi Stephen, Thanks for the quick response :) On Tue, Jul 28, 2020 at 08:36:33PM +0100, Stephen Farrell wrote: > > Hiya, > > Good topic. > > On 28/07/2020 20:13, Benjamin Kaduk wrote: > > Can we make a classification of what types of protocols are naturally > > suited for PKI scenarios and what types of protocols are naturally suited > > for pinning? > > FYI, in our survey of covid-tracing Apps most but not all > of them do pin. When those apps are uploading keys, it'd > not be good for that to be logged in an enterprise security > appliance. That seems to generalise to any applications > where the relevant entities would not like their data to > end up logged like that (by accident or design), and where > the application not working when behind a MITM is ok, or > where one can expect the application to be whitelisted by > such MITMs. ISTM that may be a fairly broad class of > applications, certainly enough to be of interest. I'd > guess some of the operators of MITMs might prefer to not > be able to see some of that application data too. There does seem to be something significant here, yes. I gave an example of a banking app that would pin, and it's not entirely clear to me whether "the application not working when behind a MITM is ok" applies to such an example. So there's some classification work left to do. > > > > If you're going to pin, how does it matter if you pin a (raw) public key, a > > self-signed non-CA cert, an arbitrary cert, an intermediate CA, a root CA, > > etc? > > Raw public key seems too much a foot-gun. Even with > pinning, you still need to depend on a CA for TLS, so > it seems to make sense to pin to your currently > preferred CA(s) plus one other independent CA. We've > seen that in at least one of the above apps. > > I'd guess the choice of root vs. intermediate might > depend, not sure there's an obviously correct choice > for that, for all cases. > > > > > Is there benefit in arranging for a description of the system where the > > ability to pin is just a degenerate case of a PKI, with a single trust > > anchor and no real hierarchy? > > I don't get the question sorry. Sorry for the clumsy description. Basically, if you squint hard, you could claim that at least some types of pinning are actually a PKI, just a degenerate PKI. E.g., in a PKI I have to pin at least one trust anchor as the root of the PKI, and if that pinned trust anchor just happens to also be the certificate directly used in the protocol, it's still a PKI, just a tree of height one. What's not clear to me is whether it's useful to force this kind of thinking on anyone, or to try to insist that all pinning is just a degenerate PKI. > > Do we want all protocols that specify one to be usable with the other (and > > document it that way)? > > > > Is there utility in writing a document to cover any of the above topics? > > I think such a document would be useful. If it doesn't > already exist then doing that as an informational RFC or > BCP would be useful. If one exists already that's good > enough then pointing at that may be fine. Thanks, Ben From nobody Tue Jul 28 12:49:26 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310323A0B1F for ; Tue, 28 Jul 2020 12:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkSGR8dGI9hY for ; Tue, 28 Jul 2020 12:49:22 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC943A0BC8 for ; Tue, 28 Jul 2020 12:49:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DD06CBE56; Tue, 28 Jul 2020 20:49:20 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIqU6Rmpz25m; Tue, 28 Jul 2020 20:49:19 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3167BBE53; Tue, 28 Jul 2020 20:49:19 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1595965759; bh=fOu2RTEtU5QBF1w51zA/f57YbU8RYbXYTt8n7wUbTdY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=21dwcb11YPxKZuW1nQlwBTyogYPiOdv7Uvacr+3kyfo1TxgD7t0NDMuLdNUHqCzDx tIumNdJT+7MXN//M3QWF+3ypx3DjLGI5HmO55S+/hTUpj+ZZDt3WbMh/2woLM1GxIY 8q9IOVaB5SVjYeQUyW6EdFIE3vei8TKAHAr7FHtM= To: Benjamin Kaduk Cc: saag@ietf.org References: <20200728191331.GV41010@kduck.mit.edu> <20200728194235.GY41010@kduck.mit.edu> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <1c4951d6-a67c-47c6-315e-2ad3776c94ec@cs.tcd.ie> Date: Tue, 28 Jul 2020 20:49:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200728194235.GY41010@kduck.mit.edu> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1F2tNN99T0UV1iCIY0qt4kbKFQzLVN6v5" Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 19:49:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1F2tNN99T0UV1iCIY0qt4kbKFQzLVN6v5 Content-Type: multipart/mixed; boundary="KzQOeSVU5Cejk6UUijdcLxcyiW3tV6IwA"; protected-headers="v1" From: Stephen Farrell To: Benjamin Kaduk Cc: saag@ietf.org Message-ID: <1c4951d6-a67c-47c6-315e-2ad3776c94ec@cs.tcd.ie> Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) References: <20200728191331.GV41010@kduck.mit.edu> <20200728194235.GY41010@kduck.mit.edu> In-Reply-To: <20200728194235.GY41010@kduck.mit.edu> --KzQOeSVU5Cejk6UUijdcLxcyiW3tV6IwA Content-Type: multipart/mixed; boundary="------------95D39A6ECF02F37DD0292883" Content-Language: en-US This is a multi-part message in MIME format. --------------95D39A6ECF02F37DD0292883 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 28/07/2020 20:42, Benjamin Kaduk wrote: > Sorry for the clumsy description. Basically, if you squint hard, you c= ould > claim that at least some types of pinning are actually a PKI, just a > degenerate PKI.=20 Ah gotcha. ISTM more useful to treat pinning as an adjunct to whatever PKI is used by the application that can be MITM'd and not bother with pinning as a potential replacement for that PKI. There's nothing wrong with an application being based on it's very-own PKI of course, but seems less useful for the IETF to try describe pinning for custom protocols where we don't know the details. Cheers, S. --------------95D39A6ECF02F37DD0292883 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------95D39A6ECF02F37DD0292883-- --KzQOeSVU5Cejk6UUijdcLxcyiW3tV6IwA-- --1F2tNN99T0UV1iCIY0qt4kbKFQzLVN6v5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl8ggT4ACgkQWrL68XsX K+p7Tw/+M1Yf1ROEJx/1mMAPtwZsRJ26srapQm0JsWgdjAloRfbkj1nWs/przLx0 CUrY2CC7DR5STzE7uMxMFyC4nUuS3N6V8XiuHbFg1uUNuVWEq49P7rre+ekl59sb 6okOULNLe9XB9EKhh4C4EnM1eHGu2wE5w5kQyGDQh3hMTN4x5N/ZwJZF2Csz6zO9 p3MBV15ac/VAPj0FKWaUHKmHJ+Xj7mtrD+Cve2XmfjayeEQHy2+OrXNYmRo8kWDC p6nevMaOVZ0Vl0+JyQNuwSCR/YoFbPuRKzEaXopftWYbv52qzTd/NjFNZrEbD3Id RtL2W+ZbXIXaYx4gKjzW0kr1sKEIcXmtAsuZpYEZEHhOfTRdqKuAJmb6fJ+9E1CK /Kf92pU2Q0D9WRA2ErVG0Hgd1Vjhe+Xx7JV0BoBrte05mb6bH4/H8MBN1JZQakIn azbCSAyn63F1TH5fE+8fdD+MfDnGa8P1fMoiOH2gAwLgzCtGvsHDUpYVzrf62572 K9zon8VC/Nuyykkh26abPWkGu2PlIRF7Xcp47gPGWMfhp5I9C8M0WNl/cUsraLd/ hK9uXfC75bB2ZSFoSrBM/wQ71R36+Vxz0PbapUfsu4VpGMilYFPHlie3aFwJ2WIa 184+RVzRVdSpzwyagukewz+MaSiU00E3gidL/K8YLx2qJQ7i5xY= =5QDv -----END PGP SIGNATURE----- --1F2tNN99T0UV1iCIY0qt4kbKFQzLVN6v5-- From nobody Tue Jul 28 12:56:49 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BAA3A0BF6 for ; Tue, 28 Jul 2020 12:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxZubBW7jtBt for ; Tue, 28 Jul 2020 12:56:45 -0700 (PDT) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) (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 734913A0BF0 for ; Tue, 28 Jul 2020 12:56:45 -0700 (PDT) Received: by mail-io1-f47.google.com with SMTP id k23so22040141iom.10 for ; Tue, 28 Jul 2020 12:56:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qqbI7tA47XstyNGLeMV44CbpHn4TtX/KTdOrfWcPfIU=; b=r6NS5IsQWc3/sTZaZZngWKG3PWmb6yT6cj8I7P8rNGnzKxZUbPOOp5msormxPxUXZt pHJX+kpzpkv+yKvAxrIABAaI+3xmUB8D+LjHw2ZWcV+4GYAQX2EpLnpc51VkXlmxYyyb xtGJ3ikWn5qqwUpMSeHe2RqC21Tu4+mxsnmCNF14zE6n+StCholvwueIuJ58+mDErJu3 dH7ZoZ3z9EhlMFqWDfFJ9QDVdqYpwNIJgTjiwZp6fTQxZOocjQwU+4bxTOoUPbOEZKmb FQL65eErmt840CgxkavRqe/PLdVxhhFZdevNM+hUbPcZWJ/yeD98hhXvwOXzm3rfLzdg Dfzw== X-Gm-Message-State: AOAM533FclfVjz6P+++0JDv7yKdDZvddiGVUll7f1QH25DZeV9VxbHcr i0kFg9AHC+DjkZ6bRsbtyJTOPYI3A3sWZttNRTtrmeB1 X-Google-Smtp-Source: ABdhPJxhcUK3SyFWNm1cLnkA6mdAl32rJJI615hH4nF2LlJf+8oue1DKrOqw0/j/7m/ZDPE5pxnNoZe9vp8N7pgPRkU= X-Received: by 2002:a5d:9a99:: with SMTP id c25mr12587710iom.116.1595966204387; Tue, 28 Jul 2020 12:56:44 -0700 (PDT) MIME-Version: 1.0 References: <20200728191331.GV41010@kduck.mit.edu> <20200728194235.GY41010@kduck.mit.edu> <1c4951d6-a67c-47c6-315e-2ad3776c94ec@cs.tcd.ie> In-Reply-To: <1c4951d6-a67c-47c6-315e-2ad3776c94ec@cs.tcd.ie> From: Ben Laurie Date: Tue, 28 Jul 2020 20:56:33 +0100 Message-ID: To: Stephen Farrell Cc: Benjamin Kaduk , IETF Security Area Advisory Group Content-Type: multipart/alternative; boundary="000000000000afa86105ab85d65f" Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 19:56:48 -0000 --000000000000afa86105ab85d65f Content-Type: text/plain; charset="UTF-8" I'm a little surprised by this conversation. Why would SAAG want to support a practice that flies in the face of everything we know about key management? On Tue, 28 Jul 2020 at 20:49, Stephen Farrell wrote: > > > On 28/07/2020 20:42, Benjamin Kaduk wrote: > > Sorry for the clumsy description. Basically, if you squint hard, you > could > > claim that at least some types of pinning are actually a PKI, just a > > degenerate PKI. > > Ah gotcha. > > ISTM more useful to treat pinning as an adjunct to whatever > PKI is used by the application that can be MITM'd and not > bother with pinning as a potential replacement for that > PKI. There's nothing wrong with an application being based > on it's very-own PKI of course, but seems less useful for > the IETF to try describe pinning for custom protocols where > we don't know the details. > > Cheers, > S. > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --000000000000afa86105ab85d65f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm a little surprised by this conversation. Why would= SAAG want to support a practice that flies in the face of everything we kn= ow about key management?

On Tue, 28 Jul 2020 at 20:49, Stephen Farrell <<= a href=3D"mailto:stephen.farrell@cs.tcd.ie">stephen.farrell@cs.tcd.ie&g= t; wrote:


On 28/07/2020 20:42, Benjamin Kaduk wrote:
> Sorry for the clumsy description.=C2=A0 Basically, if you squint hard,= you could
> claim that at least some types of pinning are actually a PKI, just a > degenerate PKI.

Ah gotcha.

ISTM more useful to treat pinning as an adjunct to whatever
PKI is used by the application that can be MITM'd and not
bother with pinning as a potential replacement for that
PKI. There's nothing wrong with an application being based
on it's very-own PKI of course, but seems less useful for
the IETF to try describe pinning for custom protocols where
we don't know the details.

Cheers,
S.
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--000000000000afa86105ab85d65f-- From nobody Tue Jul 28 13:09:27 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0443A0BF5 for ; Tue, 28 Jul 2020 13:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQZS7EGGpZqC for ; Tue, 28 Jul 2020 13:09:22 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CFA53A0B37 for ; Tue, 28 Jul 2020 13:09:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 49715BE56; Tue, 28 Jul 2020 21:09:20 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2AJlGMygfQv; Tue, 28 Jul 2020 21:09:18 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E87E7BE53; Tue, 28 Jul 2020 21:09:17 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1595966958; bh=MfK3EYMbLk0wDpciWP4edDAfHb0ly+NuH6jv3yZPxGI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=yEkZvEWfBD2qpXSrQGzQar0UtbhZnF1QjmkD+EvUiR63F5Z+97ErRAAfRukkKNGJc DjNyDyWUbAueRgzn0KvHn+7pafazy3q6ZejjnQt5ya2JtoaqwA6BeSZoTseQ0Dx+t+ d3yMeMCf93i/PnHorZSiM5rbJjFvvKXT88GHynVg= To: Ben Laurie Cc: Benjamin Kaduk , IETF Security Area Advisory Group References: <20200728191331.GV41010@kduck.mit.edu> <20200728194235.GY41010@kduck.mit.edu> <1c4951d6-a67c-47c6-315e-2ad3776c94ec@cs.tcd.ie> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Tue, 28 Jul 2020 21:09:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uUluERbpVmxiWJQGw6VciI85YIowj0sBX" Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 20:09:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uUluERbpVmxiWJQGw6VciI85YIowj0sBX Content-Type: multipart/mixed; boundary="YHEKitakhHfzkKAjaXP0s2QJB88GWa2mX"; protected-headers="v1" From: Stephen Farrell To: Ben Laurie Cc: Benjamin Kaduk , IETF Security Area Advisory Group Message-ID: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) References: <20200728191331.GV41010@kduck.mit.edu> <20200728194235.GY41010@kduck.mit.edu> <1c4951d6-a67c-47c6-315e-2ad3776c94ec@cs.tcd.ie> In-Reply-To: --YHEKitakhHfzkKAjaXP0s2QJB88GWa2mX Content-Type: multipart/mixed; boundary="------------B24787BA529FF23F185AF131" Content-Language: en-US This is a multi-part message in MIME format. --------------B24787BA529FF23F185AF131 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 28/07/2020 20:56, Ben Laurie wrote: > I'm a little surprised by this conversation. Why would SAAG want to sup= port > a practice that flies in the face of everything we know about key > management? Sorry if I gave the wrong impression. I agree with you that pinning to application keys is a bad idea. I do think there's a role for pinning to CAs that you already gotta trust, as a way to fail rather than allow a MITM, for the cases where that's better. S >=20 > On Tue, 28 Jul 2020 at 20:49, Stephen Farrell > wrote: >=20 >> >> >> On 28/07/2020 20:42, Benjamin Kaduk wrote: >>> Sorry for the clumsy description. Basically, if you squint hard, you= >> could >>> claim that at least some types of pinning are actually a PKI, just a >>> degenerate PKI. >> >> Ah gotcha. >> >> ISTM more useful to treat pinning as an adjunct to whatever >> PKI is used by the application that can be MITM'd and not >> bother with pinning as a potential replacement for that >> PKI. There's nothing wrong with an application being based >> on it's very-own PKI of course, but seems less useful for >> the IETF to try describe pinning for custom protocols where >> we don't know the details. >> >> Cheers, >> S. >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> >=20 --------------B24787BA529FF23F185AF131 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------B24787BA529FF23F185AF131-- --YHEKitakhHfzkKAjaXP0s2QJB88GWa2mX-- --uUluERbpVmxiWJQGw6VciI85YIowj0sBX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl8ghe0ACgkQWrL68XsX K+rp1xAAoOJm0WB/XlGAOiSoxK0RdrHS3GN81x8PjAjL3erZdr8zm/UtEgAu4e8R dqKhGACRbe83t4vwfg7E4P3FZmPWEbtSJwm6vnrmTf2TPdneGxf/iqeQ51Njwqfk oRfEjFiHj8Hoj9dZJnn19Ba+LhdJSUeCa7PjFxOAfCyTP7Rjm8PgNK4AjkfD/XeH tXc33xohYZm7EE4vX4VV/6cjRphw0ZOJEKsBuKKKmchwwziVNpUnaMIkcMM4DxNQ iz83QsuW9ZuL+ne1DsXfYzrrj/Lusj9o9E1BDPrqaRUuH2IsfeTtmYKdUMG899y6 U4raRXiZHb9uGEJI148qrcNIdRfNYb1JlnuIr2QducNNSop9J3NNAnQDsFWU7FT7 bCTV861hri8iZHC27KNGDvDvBUQ1P4OzFqLNvPXsk7NY+wl3cILoZjSmW+v+1YwF 6y8C+rXjvEi2lwGZwvHmEnob/tH1wbp9EdBGSlO3vh2TbvihcnNTIdo4oTLBrnoM EJ2pL+96GFzYI/JZmQr4yxyCWqWkGngXaWukWjoJHVrrQWACg/27YQX9spswBfdD pgO7NYDkDvZrf59CXF7VZohp8fpUftAXmJacXY+M3nIBuw+SJcDEkRo0V8m/PxY7 RU5iDbdnHDHmre+JZ+TsBy3MJL0MEQubjh3OtT8vRPmGMknq+PA= =x9Bj -----END PGP SIGNATURE----- --uUluERbpVmxiWJQGw6VciI85YIowj0sBX-- From nobody Tue Jul 28 13:17:01 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189763A0C20 for ; Tue, 28 Jul 2020 13:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WugCUwg-dOom for ; Tue, 28 Jul 2020 13:16:52 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E21F3A0C1E for ; Tue, 28 Jul 2020 13:16:52 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06SKBUjI020551; Tue, 28 Jul 2020 21:16:49 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=0CBD/+GotkRcL89ZCSiyJjZYnUan0JoUxyV0oFq98fY=; b=AcWWf46V95cbQXxHkzrRPtN+TP4ohlY4v40TuotsUcJfhx0SI53Qk1P8a+jp5g3hsBof BmP6Txwhfc/6Z6HV14+MrcJxoJOaj96Iz25QedZXZcBdh7GdFJC6K0fJK2cgFvjQl3Qb Fqf/Zz1LVTjCZFpmxhwx5RJIFp7YvSzU/u7KulmZH16IAts4MqvSRlyC85G9eW1sYqAB 96elo253XqFKgHdH0JFVR39TeproiXIL0yQKHiFu+I53mXDE1Ul3a4HViQJb6dJIilA7 PjhRJAqNHGtitClJwdVMMWgYTwdJ2mTazsLWrhybX8Uebo45JfMQhgDfWCnmSXaLEusJ 8A== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 32gcd2pn9v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Jul 2020 21:16:48 +0100 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 06SKGfX2012405; Tue, 28 Jul 2020 13:16:48 -0700 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint5.akamai.com with ESMTP id 32gjqb6njx-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 28 Jul 2020 13:16:47 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 28 Jul 2020 16:14:31 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.006; Tue, 28 Jul 2020 16:14:31 -0400 From: "Salz, Rich" To: Stephen Farrell , Ben Laurie CC: IETF Security Area Advisory Group Thread-Topic: [saag] On PKI vs. Pinning (SAAG 108 preview) Thread-Index: AQHWZRM7mB0sp/K2t0aY7SH/G7K9X6kdpbOAgAABsICAAAHgAIAAAgeAgAADj4D//75nAA== Date: Tue, 28 Jul 2020 20:14:30 +0000 Message-ID: <40050B87-F2B7-4E73-9C16-9A6C9381DC8F@akamai.com> References: <20200728191331.GV41010@kduck.mit.edu> <20200728194235.GY41010@kduck.mit.edu> <1c4951d6-a67c-47c6-315e-2ad3776c94ec@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.52] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-28_16:2020-07-28, 2020-07-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 suspectscore=0 mlxlogscore=618 bulkscore=0 adultscore=0 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007280142 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-28_16:2020-07-28, 2020-07-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 adultscore=0 mlxlogscore=581 priorityscore=1501 phishscore=0 malwarescore=0 lowpriorityscore=0 suspectscore=0 mlxscore=0 bulkscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007280143 Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 20:16:55 -0000 PiAgICBJIGRvIHRoaW5rIHRoZXJlJ3MgYSByb2xlIGZvciBwaW5uaW5nIHRvIENBcyB0aGF0IHlv dQ0KICAgIGFscmVhZHkgZ290dGEgdHJ1c3QsIGFzIGEgd2F5IHRvIGZhaWwgcmF0aGVyIHRoYW4g YWxsb3cNCiAgICBhIE1JVE0sIGZvciB0aGUgY2FzZXMgd2hlcmUgdGhhdCdzIGJldHRlci4NCg0K SSBhZ3JlZSB3aXRoIHRoaXMuDQogDQoNCg== From nobody Tue Jul 28 13:42:08 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90D53A0BB0 for ; Tue, 28 Jul 2020 13:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVNNWHKVcB6o for ; Tue, 28 Jul 2020 13:42:04 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87A843A0CD2 for ; Tue, 28 Jul 2020 13:41:58 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BGT9w65FCzyys; Tue, 28 Jul 2020 22:41:56 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Carsten Bormann In-Reply-To: <20200728191331.GV41010@kduck.mit.edu> Date: Tue, 28 Jul 2020 22:41:56 +0200 Cc: saag@ietf.org X-Mao-Original-Outgoing-Id: 617661716.136989-a84de8f1e828fa569bc6154f4fda778a Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200728191331.GV41010@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 20:42:07 -0000 On 2020-07-28, at 21:13, Benjamin Kaduk wrote: >=20 > Can we make a classification of what types of protocols are naturally > suited for PKI scenarios and what types of protocols are naturally = suited > for pinning? How about some definitions here: PKI =3D the set of root CAs is determined by one of a oligopoly of = entities, based on CA/Browser Forum operations, where the entities = aren=E2=80=99t really justifiable parties to the application? Pinning =3D the set of root CAs is determined by the application, = choosing a set of CAs specifically authorized for the application to aid = in authentication? Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jul 28 14:18:32 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A9F3A086F for ; Tue, 28 Jul 2020 14:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAhIgW5oQ49q for ; Tue, 28 Jul 2020 14:18:28 -0700 (PDT) Received: from mail-il1-f178.google.com (mail-il1-f178.google.com [209.85.166.178]) (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 A47D83A082B for ; Tue, 28 Jul 2020 14:18:28 -0700 (PDT) Received: by mail-il1-f178.google.com with SMTP id c16so5708380ils.8 for ; Tue, 28 Jul 2020 14:18:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XKxr+0P/+hdMsgj9qiERS+hYz5XL/zQhd+OOhtkbcYc=; b=eRL3z8B8Y5hT4MI4r2vM0RBV9+NbEYPa0WRLUyBhxlobDDJYget2A8pSgQ4KzvfKGc O1QKujTsh0Ryuf6WDQp/LjvWNul1vdn8s3hTtkV+yIJ86o4WBl4ljl8kv2xOCb7mfqhM VeiV8jQiPQclqXDAL/LjXJc3GHUiwQkLs+flGZkoYiwWDFCV/jsLf1+J0kR0z9vZl32U aYXgr1c7i9J1g03OTEtQgBPlkRZm3DXOjJaYtPdeVC4ZO1GCT1mjwaBtf8v8Y0GXiYHn zJFpJr0DNYw6z+xLukGvr1df71Cfg25o7HYh9OlQhMFyajOjA4wD+zPoQHt/z41TJNvJ 3yvg== X-Gm-Message-State: AOAM530AUN9Dg7i/CbkFfF+n6QNjsuCjOgvfKvdRvPDPZePgwrX2o94K ve4lgRSLhchlXEm3whA0CZOnBWHARPyJSJgZkZg= X-Google-Smtp-Source: ABdhPJx/TlXztaE7guav7Lp5D8fNS1G5WaT1q24QomsGdrX0DjKBI42QpHbekhfN4aT7q2gAjd9KrmYg9dxlhfH6amQ= X-Received: by 2002:a92:d611:: with SMTP id w17mr8209220ilm.103.1595971108017; Tue, 28 Jul 2020 14:18:28 -0700 (PDT) MIME-Version: 1.0 References: <20200728191331.GV41010@kduck.mit.edu> <20200728194235.GY41010@kduck.mit.edu> <1c4951d6-a67c-47c6-315e-2ad3776c94ec@cs.tcd.ie> In-Reply-To: From: Ben Laurie Date: Tue, 28 Jul 2020 22:18:17 +0100 Message-ID: To: Stephen Farrell Cc: Benjamin Kaduk , IETF Security Area Advisory Group Content-Type: multipart/alternative; boundary="000000000000f71e1805ab86fa99" Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 21:18:31 -0000 --000000000000f71e1805ab86fa99 Content-Type: text/plain; charset="UTF-8" On Tue, 28 Jul 2020 at 21:09, Stephen Farrell wrote: > > > On 28/07/2020 20:56, Ben Laurie wrote: > > I'm a little surprised by this conversation. Why would SAAG want to > support > > a practice that flies in the face of everything we know about key > > management? > > Sorry if I gave the wrong impression. I agree with you > that pinning to application keys is a bad idea. > > I do think there's a role for pinning to CAs With you up to here. > that you > already gotta trust, Why? > as a way to fail rather than allow > a MITM, for the cases where that's better. > Surely this is not what CAs are for? They're for succeeding rather than a MITM, aren't they? That does suppose revocation that actually works (which I would suggest is a more useful thing to work on than pinning). Also, to be clear, pinning CAs is only deferring the problem - and, in fact, without CA blacklisting, is not a great deal better. Well. That escalated fast. > > S > > > > > On Tue, 28 Jul 2020 at 20:49, Stephen Farrell > > > wrote: > > > >> > >> > >> On 28/07/2020 20:42, Benjamin Kaduk wrote: > >>> Sorry for the clumsy description. Basically, if you squint hard, you > >> could > >>> claim that at least some types of pinning are actually a PKI, just a > >>> degenerate PKI. > >> > >> Ah gotcha. > >> > >> ISTM more useful to treat pinning as an adjunct to whatever > >> PKI is used by the application that can be MITM'd and not > >> bother with pinning as a potential replacement for that > >> PKI. There's nothing wrong with an application being based > >> on it's very-own PKI of course, but seems less useful for > >> the IETF to try describe pinning for custom protocols where > >> we don't know the details. > >> > >> Cheers, > >> S. > >> _______________________________________________ > >> saag mailing list > >> saag@ietf.org > >> https://www.ietf.org/mailman/listinfo/saag > >> > > > --000000000000f71e1805ab86fa99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, 28 Jul 2020 at 21:09, Stephen= Farrell <stephen.farrell@c= s.tcd.ie> wrote:


On 28/07/2020 20:56, Ben Laurie wrote:
> I'm a little surprised by this conversation. Why would SAAG want t= o support
> a practice that flies in the face of everything we know about key
> management?

Sorry if I gave the wrong impression. I agree with you
that pinning to application keys is a bad idea.

I do think there's a role for pinning to CAs

With you up to here.
=C2=A0
that you
already gotta trust,

Why?
=C2=A0<= /div>
as a way to fail ra= ther than allow
a MITM, for the cases where that's better.

Surely this is not what CAs are for? They're for succeeding rat= her than a MITM, aren't they? That does suppose revocation that actuall= y works (which I would suggest is a more useful thing to work on than pinni= ng).

Also, to be clear, pinning CAs is only deferr= ing the problem - and, in fact, without CA blacklisting, is not a great dea= l better.

Well. That escalated fast.
=C2= =A0

S

>
> On Tue, 28 Jul 2020 at 20:49, Stephen Farrell <stephen.farrell@cs.tcd.ie>= ;
> wrote:
>
>>
>>
>> On 28/07/2020 20:42, Benjamin Kaduk wrote:
>>> Sorry for the clumsy description.=C2=A0 Basically, if you squi= nt hard, you
>> could
>>> claim that at least some types of pinning are actually a PKI, = just a
>>> degenerate PKI.
>>
>> Ah gotcha.
>>
>> ISTM more useful to treat pinning as an adjunct to whatever
>> PKI is used by the application that can be MITM'd and not
>> bother with pinning as a potential replacement for that
>> PKI. There's nothing wrong with an application being based
>> on it's very-own PKI of course, but seems less useful for
>> the IETF to try describe pinning for custom protocols where
>> we don't know the details.
>>
>> Cheers,
>> S.
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag >>
>
--000000000000f71e1805ab86fa99-- From nobody Tue Jul 28 14:28:54 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBE23A088A for ; Tue, 28 Jul 2020 14:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qMqrH33GNOb for ; Tue, 28 Jul 2020 14:28:49 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 779D93A0883 for ; Tue, 28 Jul 2020 14:28:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8634EBE5B; Tue, 28 Jul 2020 22:28:47 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypTo_lkrOjnb; Tue, 28 Jul 2020 22:28:42 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A0710BE58; Tue, 28 Jul 2020 22:28:42 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1595971722; bh=B//1AtbiYYejPBtI2F3DvYgKO6+s+2Nx6a+UKaFQyv0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=zagNXph8zIKnOcvf//jMopS1E+bQLOSdoD3sjK7dRWNlsCMCCuUrJjCeJcQs8tXzh 7aXx+lRIcy5cUE/gWmTlVOlrQhMM1mZJ7DhIFIqj0XnUKV0MK6O+u/noSN+rdIwauu DDYudUiCuuRfI3gxrVak2VI+KCzzRP0ZMDcXt4oU= To: Ben Laurie Cc: Benjamin Kaduk , IETF Security Area Advisory Group References: <20200728191331.GV41010@kduck.mit.edu> <20200728194235.GY41010@kduck.mit.edu> <1c4951d6-a67c-47c6-315e-2ad3776c94ec@cs.tcd.ie> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Tue, 28 Jul 2020 22:28:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aV7YTOEtD8nhvbaqmshWkexNKemn8c3rW" Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 21:28:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aV7YTOEtD8nhvbaqmshWkexNKemn8c3rW Content-Type: multipart/mixed; boundary="nKe9j8XG7NfFSvd6dRKSgA245QBIBrw8G"; protected-headers="v1" From: Stephen Farrell To: Ben Laurie Cc: Benjamin Kaduk , IETF Security Area Advisory Group Message-ID: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) References: <20200728191331.GV41010@kduck.mit.edu> <20200728194235.GY41010@kduck.mit.edu> <1c4951d6-a67c-47c6-315e-2ad3776c94ec@cs.tcd.ie> In-Reply-To: --nKe9j8XG7NfFSvd6dRKSgA245QBIBrw8G Content-Type: multipart/mixed; boundary="------------E1E7AC2BE6F6A1685F844155" Content-Language: en-US This is a multi-part message in MIME format. --------------E1E7AC2BE6F6A1685F844155 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 28/07/2020 22:18, Ben Laurie wrote: >> that you >> already gotta trust, >=20 > Why? Well, gotta is maybe a tiny bit overstated. I mean the WebPKI CAs mostly for applications using TLS and mostly HTTPS and where the application uses the OS or browser root set or equivalent that's not under the application's control. From the POV of the person deploying such applications they kinda do gotta trust those CAs and picking a subset of those to which they pin doesn't make things worse and can make things better. (Assuming CT logs too of course.) >> as a way to fail rather than allow >> a MITM, for the cases where that's better. >> >=20 > Surely this is not what CAs are for?=20 In theory. But once you can add a local enterprise CA to the relevant root store then the application can be MTIM'd. The application developer can't stop that, but, via pinning to a CA, can cause a fail in such cases. > They're for succeeding rather than a > MITM, aren't they? That does suppose revocation that actually works (wh= ich > I would suggest is a more useful thing to work on than pinning). >=20 > Also, to be clear, pinning CAs is only deferring the problem - and, in > fact, without CA blacklisting, is not a great deal better. I think it has sufficient utility in enough cases to be worth documenting well. (Which could be done in the IETF or elsewhere, but here'd be fine.) > Well. That escalated fast. Must be my neck is so thick already I no longer notice:-) Cheers, S. >=20 >=20 >> >> S >> >>> >>> On Tue, 28 Jul 2020 at 20:49, Stephen Farrell >> >>> wrote: >>> >>>> >>>> >>>> On 28/07/2020 20:42, Benjamin Kaduk wrote: >>>>> Sorry for the clumsy description. Basically, if you squint hard, y= ou >>>> could >>>>> claim that at least some types of pinning are actually a PKI, just = a >>>>> degenerate PKI. >>>> >>>> Ah gotcha. >>>> >>>> ISTM more useful to treat pinning as an adjunct to whatever >>>> PKI is used by the application that can be MITM'd and not >>>> bother with pinning as a potential replacement for that >>>> PKI. There's nothing wrong with an application being based >>>> on it's very-own PKI of course, but seems less useful for >>>> the IETF to try describe pinning for custom protocols where >>>> we don't know the details. >>>> >>>> Cheers, >>>> S. >>>> _______________________________________________ >>>> saag mailing list >>>> saag@ietf.org >>>> https://www.ietf.org/mailman/listinfo/saag >>>> >>> >> >=20 --------------E1E7AC2BE6F6A1685F844155 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------E1E7AC2BE6F6A1685F844155-- --nKe9j8XG7NfFSvd6dRKSgA245QBIBrw8G-- --aV7YTOEtD8nhvbaqmshWkexNKemn8c3rW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl8gmIkACgkQWrL68XsX K+qWkg//TqKACDBwVIW2fVGhrBNQqmptP5t203ESvGh6nBQJx2emxewvbHdzzm+b Yk2O32bvKHqaUD03AldUiafrCtFlWwfyfoc3VG4CVruYM/ImHRedE9QrZ0SYT13X EkOHP7GhIcFb3OAWspF41XX3auyTgCw12iTuJSG84AMgEMrg5NZZwK+os1tMbMkS zBvOQ9pM9Ob46pY43ApCAcWjR00gs4VIofZNV5Y1chF9SHuC7bZ4I5FGg5ufuyM7 SrIiKsrQ2+i2nt8cd9zmHdrC6xnrTOJXUT0ZkhIEufUWdMVhcEJffynCRU5wZ5bq gjZ3Sb4Ls6LJ+vp+dKZYsBPwTB2rMV8Fx6IGyinP8+dvKp3CM3O9zVyhet7x1Ack z7y06lG04pkbg6FvuA51fiAua5ChGCPuZ7r8SCbgff3vqZwP9c4ugs4trd5yhUyj XS0U4Vek+qPzmlGIX8xLeeq8J+gR2TjZeOUCwD1P0F+C7FXSP7SIrmIt3qAYMxQW VV3hOGKFNO93EhvrAOatk7yJ+4W3HeoQqtYa/fURyYE9GnhLDVtBYPrl9KWFxEJE 3LQ65uh6hbaL7zM3LLD5OZCrOKLvHCToujwWRyjUL0qADrYn8grPRNcqQYKtsZY4 Po0JCCxbgZ7bU27SRU/xcrWJAhBSUYpFOBrLzvCAfzObwgPdQZI= =ISO9 -----END PGP SIGNATURE----- --aV7YTOEtD8nhvbaqmshWkexNKemn8c3rW-- From nobody Tue Jul 28 14:43:15 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574E03A0A35 for ; Tue, 28 Jul 2020 14:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 PopfCageRCc2 for ; Tue, 28 Jul 2020 14:43:09 -0700 (PDT) Received: from bird.elm.relay.mailchannels.net (bird.elm.relay.mailchannels.net [23.83.212.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A603A0A49 for ; Tue, 28 Jul 2020 14:43:07 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A6D461E19AB; Tue, 28 Jul 2020 21:43:06 +0000 (UTC) Received: from pdx1-sub0-mail-a26.g.dreamhost.com (100-96-19-29.trex.outbound.svc.cluster.local [100.96.19.29]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id EB9291E10B0; Tue, 28 Jul 2020 21:43:05 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a26.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Tue, 28 Jul 2020 21:43:06 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Cooperative-Dime: 0877407e686f4f0b_1595972586434_2158568069 X-MC-Loop-Signature: 1595972586434:2515054002 X-MC-Ingress-Time: 1595972586434 Received: from pdx1-sub0-mail-a26.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a26.g.dreamhost.com (Postfix) with ESMTP id A33CB7F692; Tue, 28 Jul 2020 14:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=t2kD1Cq7iF4Tdc Gl2nKCTTa7w1g=; b=QWyhtrl3uldv6Fe8E/FABq+abxX2wT/1iWRk9RBdKycevZ wC/TCJC7dCdU1dclkJCeWhc49XwGPOa2uckNZCvvTPNuxL8rX/iPkTSng7yfDtR0 RiMeKMx2SSLHaIvrDvcB19/my8BV8KgqNyRzoLFhY7hi2QnFd1+Qiv6xttKCo= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a26.g.dreamhost.com (Postfix) with ESMTPSA id D67827F694; Tue, 28 Jul 2020 14:43:04 -0700 (PDT) Date: Tue, 28 Jul 2020 16:43:02 -0500 X-DH-BACKEND: pdx1-sub0-mail-a26 From: Nico Williams To: Benjamin Kaduk Cc: saag@ietf.org Message-ID: <20200728214301.GH3100@localhost> References: <20200728191331.GV41010@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200728191331.GV41010@kduck.mit.edu> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedrieefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpeeuffeuheelledtffdukeejiefgfeehgfffffehhfehjeeltedtvdegheejkeevjeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 21:43:14 -0000 On Tue, Jul 28, 2020 at 12:13:31PM -0700, Benjamin Kaduk wrote: > One of the agenda items for Thursday's SAAG session at IETF 108 is > "Discussion on PKI vs. Pinning Applicability". This is intended to be > Security Area Advisory Group in its core meaning -- I want to get the sense > of the IETF security community. There are some draft slides for SAAG at > https://www.ietf.org/proceedings/108/slides/slides-108-saag-chair-slides-pkipinning-bcp-72-00 > (starting at slide 33; note to self: change template to include slide > numbers), and in true IETF spirit I'm hoping we can get a lot of it covered > on the list in advance. > > As a lead-in, this topic came to mind due to a thread on the NFSv4 list, > discussing the RPC-over-TLS work that's in IESG Evaluation. A participant > made the claim (see thread at > https://mailarchive.ietf.org/arch/msg/nfsv4/SLTNqWbjE-H8JshLk0HwlwxArrI/) > that certificate pinning is needed for RPC-TLS, and I did not have the > impression that this was the consensus position of the IETF security > community ... but I also don't have any data to support that impression > (yet?). Speaking as an implementor of credential orchestration systems for corporate networks, the claim that NFSv4-over-TLS requires pinning is wrong. NFSv4-over-TLS, like most applications running over TLS, needs a reasonable management solution for a) conveying trust anchors to relying parties, b) certifying (here: server) keys in those PKIs. In a corporate network I absolutely would not want TOFU. But in any case, as long as the server software lets me configure a credential, and the client software lets me configure TOFU (with or without interactive confirmation), or pre-share keys. I'm ok with the RFC talking about pinning, though I would prefer it leave all details of how the TLS server is authenticated to... the TLS spec. Nico -- From nobody Tue Jul 28 14:46:36 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E733A0914 for ; Tue, 28 Jul 2020 14:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7gM0ilsghsh for ; Tue, 28 Jul 2020 14:46:33 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DEDF3A090D for ; Tue, 28 Jul 2020 14:46:32 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06SLkNnU025105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Jul 2020 17:46:26 -0400 Date: Tue, 28 Jul 2020 14:46:23 -0700 From: Benjamin Kaduk To: Ben Laurie Cc: Stephen Farrell , IETF Security Area Advisory Group Message-ID: <20200728214623.GC41010@kduck.mit.edu> References: <20200728191331.GV41010@kduck.mit.edu> <20200728194235.GY41010@kduck.mit.edu> <1c4951d6-a67c-47c6-315e-2ad3776c94ec@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 21:46:35 -0000 Hi Ben, I suspect that the quoted exchange might make some more sense in the context of the full thread (e.g., https://mailarchive.ietf.org/arch/msg/saag/Md1Yiier0B0WXqN1suRU4r3p9zc/). Consider, for example, the case where I am spinning up a TLS connection between my NFS client and server and running NFS RPCs over it, and I need to decide how to configure the TLS library to authenticate the peer. I feel quite confident that putting the entire Mozilla root set in my trust store is the wrong thing to do for this purpose; the question I'm interested in asking relates to "what is the right thing for this purpose?". Thanks, Ben On Tue, Jul 28, 2020 at 08:56:33PM +0100, Ben Laurie wrote: > I'm a little surprised by this conversation. Why would SAAG want to support > a practice that flies in the face of everything we know about key > management? > > On Tue, 28 Jul 2020 at 20:49, Stephen Farrell > wrote: > > > > > > > On 28/07/2020 20:42, Benjamin Kaduk wrote: > > > Sorry for the clumsy description. Basically, if you squint hard, you > > could > > > claim that at least some types of pinning are actually a PKI, just a > > > degenerate PKI. > > > > Ah gotcha. > > > > ISTM more useful to treat pinning as an adjunct to whatever > > PKI is used by the application that can be MITM'd and not > > bother with pinning as a potential replacement for that > > PKI. There's nothing wrong with an application being based > > on it's very-own PKI of course, but seems less useful for > > the IETF to try describe pinning for custom protocols where > > we don't know the details. > > > > Cheers, > > S. > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > > From nobody Tue Jul 28 15:02:01 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937303A0AA0 for ; Tue, 28 Jul 2020 15:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=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 9bPQ5FdzgYky for ; Tue, 28 Jul 2020 15:01:51 -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 A90F23A09C7 for ; Tue, 28 Jul 2020 15:01:39 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id f5so22844728ljj.10 for ; Tue, 28 Jul 2020 15:01:39 -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=FwMNyTDAQlerMLc2cM/mZEm64zMUBg4X4gbfF74JnFY=; b=q+OdWfikwpfHI7MQUyGFHVaFxEh9s/Xpd6836k+9g4i0uvsJX8j1TwIc5PxmVkNWqh Zy1Jb/l0LTmc4u54y3wOiJK1eEZkCqrHcHdzdEWFk3t+fwKkiBEfsRYZJThkc7JmaqfB eUDTJMvZI0pGasfLvOgjT+1xdVtDQWZMlHZ9giC/IzNQ5PLYmqXMsD43XzZSIHw0ZLy6 JPGkhDzGlK4zU91Qvh20iF9puilBLFWWGrVh62L4AoNvvuBAL1LLhg7aHZiOU3i7WTgk Ym1TAHymV1ESRhSBQAO23oppMXupP4uyc/yHKDTZsyOSzwZcjX961gxedxUZigINCxlj pV4A== 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=FwMNyTDAQlerMLc2cM/mZEm64zMUBg4X4gbfF74JnFY=; b=ratup4WiLLkWAmyAra/sJqXQk+okHS9ibxbHCWunuFBD1sAEPJhhTrMf+kt4qWtz2Q bSLaaGSMD2I5yaNFkRl1ij8Igympcfi9FYi9ZknkaDK4fpH0SGl7KCkfDBgKbP5TU7dl ihu7DvGc6uq7iBkYE9icAWuEsU2JhWHOXEa408XGIqiFsXYbWneky11egYR0FkG7pzif aGC8K/54V9OGBQj0vkUfFfrQ3b7OAYfiiBLaGnEpGz86gbAROcS2zypr2ysvQyWQBogL YTzVdsNZP+GZr02DtPCsqwtcEUh/Udksj9pPbgMi6pN5whJyIEWT/TItcYHW0Q+qG4ZD vmPQ== X-Gm-Message-State: AOAM5313AoI0JLmdWxaK7F9z5CfOWXGXfRKxItWvI/+UoMMz5fZuc5Dg sTwNFSzqILyVTdiES6thXzoAHMHm5HJ99OsV3D67ag== X-Google-Smtp-Source: ABdhPJwDQ60Kp+zAJ98pD/7KqQ3gStI/1TzXKHy3pAQG+TPa5YklDhJIHQWPfoA9RTjXU8VYOjcubzhoYeKLl0JzIIk= X-Received: by 2002:a2e:9f08:: with SMTP id u8mr7194030ljk.265.1595973697744; Tue, 28 Jul 2020 15:01:37 -0700 (PDT) MIME-Version: 1.0 References: <20200728191331.GV41010@kduck.mit.edu> In-Reply-To: <20200728191331.GV41010@kduck.mit.edu> From: Eric Rescorla Date: Tue, 28 Jul 2020 15:01:01 -0700 Message-ID: To: Benjamin Kaduk Cc: IETF SAAG Content-Type: multipart/alternative; boundary="0000000000005369cf05ab87954a" Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 22:02:00 -0000 --0000000000005369cf05ab87954a Content-Type: text/plain; charset="UTF-8" It might be helpful to nail down our terminology here. Traditionally, we have three main approaches to public-key based key management: - Manual configuration and/or TOFU (a la SSH) - DNSSEC with something like TLSA - Deferring to some set of CAs (PKI) [0] As a practical matter, PKIs currently come in two flavors: - Publicly verifiable certificates which are rooted in one of a set of commonly trusted CAs (generally WebPKI). - Non-publicly verifiable certificates which are rooted in some other set of CAs (e.g., enterprise CAs). If you want to be able to talk to any machine on the Internet and you're using PKI [again, you could use DNSSEC/TLSA] then you need to have publicly verifiable certificates. However, there are a large number of such CAs and any of them can issue for a given name. This is where pinning comes in, as a technique for restricting the CAs (or EE keys) which can be used to authenticate a given name. Importantly, pinning only *restricts* the set of keys which can be used with a given domain; it doesn't expand it. IOW, you still need a valid PKI cert. If you're just configuring a key and not using the PKI, that's not pinning. Pinning on the Web [RFC 7469] is now more than five years old and in the intervening period, opinion has shifted, with people increasingly believing that pinning was too brittle a feature to deploy safely. For this reason, Firefox and Chrome have both deprecated pinning (I believe that Safari and IE never had it). So, to the extent to which there is a consensus, its that pinning is not a best practice. I think there's a separate question of what one ought to do when one does not need to connect to any machine on the Internet [1]. In those cases, whether manual configuration or a private CA is most appropriate seems to be a judgement call depending on how complicated the deployment is. I don't know the RPC-over-TLS setting enough to know what is best here. -Ekr [0] One can argue that DNSSEC is a form of PKI, but I've broken it out for convenience here. [1] You call out the special case where an app is talking back to its own site: A banking mobile app surely should pin the bank's known CA, rather than leaving an enterprise CA free to MITM a user's session, whereas something that wants to be part of the Web is largely forced to adopt the Web PKI. I would make two points about this. As a practical matter, it's not uncommmon for this kind of captive app to just use a generic WebPKI certificate, so this isn't really that different from serving up an HPKP header to a generic Web browser. Second, prior to HPKP being deprecated, it was standard practice to exempt locally installed CAs from pin checks because otherwise users would experience failures on networks which had MITM proxies. It seems like a similar set of considerations would apply in this case. On Tue, Jul 28, 2020 at 12:13 PM Benjamin Kaduk wrote: > Hi all, > > One of the agenda items for Thursday's SAAG session at IETF 108 is > "Discussion on PKI vs. Pinning Applicability". This is intended to be > Security Area Advisory Group in its core meaning -- I want to get the sense > of the IETF security community. There are some draft slides for SAAG at > > https://www.ietf.org/proceedings/108/slides/slides-108-saag-chair-slides-pkipinning-bcp-72-00 > (starting at slide 33; note to self: change template to include slide > numbers), and in true IETF spirit I'm hoping we can get a lot of it covered > on the list in advance. > > As a lead-in, this topic came to mind due to a thread on the NFSv4 list, > discussing the RPC-over-TLS work that's in IESG Evaluation. A participant > made the claim (see thread at > https://mailarchive.ietf.org/arch/msg/nfsv4/SLTNqWbjE-H8JshLk0HwlwxArrI/) > that certificate pinning is needed for RPC-TLS, and I did not have the > impression that this was the consensus position of the IETF security > community ... but I also don't have any data to support that impression > (yet?). > > It's clear that there are benefits and drawbacks of both approaches, > relating to scalability, ease of (minimal) deployment, key rotation, need > for maintaining highly secure infrastructure to protect high-value secrets, > how revocation is handled, whether or not having an enterprise CA is seen > as a bug or feature, etc. Similarly, there seem to be some use cases that > naturally lean towards one strategy or the other. A banking mobile app > surely should pin the bank's known CA, rather than leaving an enterprise CA > free to MITM a user's session, whereas something that wants to be part of > the Web is largely forced to adopt the Web PKI. > > This leads to some questions that may be worth discussing (both here on the > list and in-person on Thursday): > > Can we make a classification of what types of protocols are naturally > suited for PKI scenarios and what types of protocols are naturally suited > for pinning? > > If you're going to pin, how does it matter if you pin a (raw) public key, a > self-signed non-CA cert, an arbitrary cert, an intermediate CA, a root CA, > etc? > > Is there benefit in arranging for a description of the system where the > ability to pin is just a degenerate case of a PKI, with a single trust > anchor and no real hierarchy? > > Do we want all protocols that specify one to be usable with the other (and > document it that way)? > > Is there utility in writing a document to cover any of the above topics? > > Thanks in advance for a lively discussion, > > Ben > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --0000000000005369cf05ab87954a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It might be helpful to nail down our terminology here.
=
Traditionally, we have three main approaches to public-key based keymanagement:

- Manual configuration and/or TOFU (a la SSH)
- DNSS= EC with something like TLSA
- Deferring to some set of CAs (PKI) [0]
=
As a practical matter, PKIs currently come in two flavors:

- Pub= licly verifiable certificates which are rooted in one of a set
=C2=A0 of= commonly trusted CAs (generally WebPKI).
- Non-publicly verifiable cert= ificates which are rooted in some other
=C2=A0 set of CAs (e.g., enterpr= ise CAs).

If you want to be able to talk to any machine on the Inter= net and
you're using PKI [again, you could use DNSSEC/TLSA] then you= need to
have publicly verifiable certificates. However, there are a lar= ge
number of such CAs and any of them can issue for a given name. This i= s
where pinning comes in, as a technique for restricting the CAs (or EE<= br>keys) which can be used to authenticate a given name. Importantly,
pi= nning only *restricts* the set of keys which can be used with a
given do= main; it doesn't expand it. IOW, you still need a valid PKI
cert. If= you're just configuring a key and not using the PKI,
that's not= pinning.

Pinning on the Web [RFC 7469] is now more than five years = old and in
the intervening period, opinion has shifted, with people incr= easingly
believing that pinning was too brittle a feature to deploy safe= ly.
For this reason, Firefox and Chrome have both deprecated pinning (I<= br>believe that Safari and IE never had it). So, to the extent to which
= there is a consensus, its that pinning is not a best practice.

I thi= nk there's a separate question of what one ought to do when
one does= not need to connect to any machine on the Internet [1]. In
those cases,= whether manual configuration or a private CA is most
appropriate seems = to be a judgement call depending on how complicated
the deployment is. I= don't know the RPC-over-TLS setting enough
to know what is best her= e.

-Ekr


[0] One can argue that DNSSEC is a form of PKI, b= ut I've broken
it out for convenience here.

[1] You call out = the special case where an app is talking back to
its own site:

= =C2=A0 =C2=A0A banking mobile app
=C2=A0 =C2=A0surely should pin the ban= k's known CA, rather than leaving an enterprise CA
=C2=A0 =C2=A0free= to MITM a user's session, whereas something that wants to be part of=C2=A0 =C2=A0the Web is largely forced to adopt the Web PKI.

I wou= ld make two points about this. As a practical matter, it's not
uncom= mmon for this kind of captive app to just use a generic WebPKI
certifica= te, so this isn't really that different from serving up
an HPKP head= er to a generic Web browser. Second, prior to HPKP being
deprecated, it = was standard practice to exempt locally installed
CAs from pin checks be= cause otherwise users would experience failures
on networks which had MI= TM proxies. It seems like a similar set
of considerations would apply in= this case.











=C2=A0

<= br>

On Tue, Jul 28, 2020 at 12:13 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi all,

One of the agenda items for Thursday's SAAG session at IETF 108 is
"Discussion on PKI vs. Pinning Applicability".=C2=A0 This is inte= nded to be
Security Area Advisory Group in its core meaning -- I want to get the sense=
of the IETF security community.=C2=A0 There are some draft slides for SAAG = at
https:/= /www.ietf.org/proceedings/108/slides/slides-108-saag-chair-slides-pkipinnin= g-bcp-72-00
(starting at slide 33; note to self: change template to include slide
numbers), and in true IETF spirit I'm hoping we can get a lot of it cov= ered
on the list in advance.

As a lead-in, this topic came to mind due to a thread on the NFSv4 list, discussing the RPC-over-TLS work that's in IESG Evaluation.=C2=A0 A par= ticipant
made the claim (see thread at
https://mailarchive.ietf.org= /arch/msg/nfsv4/SLTNqWbjE-H8JshLk0HwlwxArrI/)
that certificate pinning is needed for RPC-TLS, and I did not have the
impression that this was the consensus position of the IETF security
community ... but I also don't have any data to support that impression=
(yet?).

It's clear that there are benefits and drawbacks of both approaches, relating to scalability, ease of (minimal) deployment, key rotation, need for maintaining highly secure infrastructure to protect high-value secrets,=
how revocation is handled, whether or not having an enterprise CA is seen as a bug or feature, etc.=C2=A0 Similarly, there seem to be some use cases = that
naturally lean towards one strategy or the other.=C2=A0 A banking mobile ap= p
surely should pin the bank's known CA, rather than leaving an enterpris= e CA
free to MITM a user's session, whereas something that wants to be part = of
the Web is largely forced to adopt the Web PKI.

This leads to some questions that may be worth discussing (both here on the=
list and in-person on Thursday):

Can we make a classification of what types of protocols are naturally
suited for PKI scenarios and what types of protocols are naturally suited for pinning?

If you're going to pin, how does it matter if you pin a (raw) public ke= y, a
self-signed non-CA cert, an arbitrary cert, an intermediate CA, a root CA,<= br> etc?

Is there benefit in arranging for a description of the system where the
ability to pin is just a degenerate case of a PKI, with a single trust
anchor and no real hierarchy?

Do we want all protocols that specify one to be usable with the other (and<= br> document it that way)?

Is there utility in writing a document to cover any of the above topics?
Thanks in advance for a lively discussion,

Ben

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--0000000000005369cf05ab87954a-- From nobody Tue Jul 28 15:49:45 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C503A09F8 for ; Tue, 28 Jul 2020 15:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.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 cHxISasV-Qw0 for ; Tue, 28 Jul 2020 15:49:40 -0700 (PDT) Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [216.205.24.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6343A09AB for ; Tue, 28 Jul 2020 15:49:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1595976578; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=Ng+wa60eus1NzToTC22jE+3e4Ed972TRfbjbB8+NT+Y=; b=VDQFvnvGz3yuBDTOjr2ahs0tatsVfCn9rEVkAjsesw8DmqgvaK+6CzFt93FKYo4Qgpsn8m zV6wj9hxMDQP0TneS37Hsnw1mtt5ciF/7qsYyqkL6ale/NO5sFz9RGXhOJSn5lzr3vN3u2 QjWGBm+EReeyBvaqrt0XIT8xchT6Jo8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-399-biJJhHk9P1-sGULD1-93iw-1; Tue, 28 Jul 2020 18:49:31 -0400 X-MC-Unique: biJJhHk9P1-sGULD1-93iw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5EA2B1005504; Tue, 28 Jul 2020 22:49:30 +0000 (UTC) Received: from localhost (unknown [10.10.110.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1A09719C71; Tue, 28 Jul 2020 22:49:29 +0000 (UTC) From: Robbie Harwood To: saag@ietf.org Cc: kitten@ietf.org Date: Tue, 28 Jul 2020 18:49:22 -0400 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [saag] Kitten WG report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2020 22:49:43 -0000 --=-=-= Content-Type: text/plain kitten did not meet. pkinit-agility has been published as RFC 8636 [1]. sasl-saml-ec [2] has completed shepherd review and advanced past WGLC. In cooperation with TLS, we have taken on channel-bindings-for-tls13 [3]. We have also adopted gss-sanon [4] and password-storage [5]. Thanks, --Robbie 1: https://datatracker.ietf.org/doc/rfc8636/ 2: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml-ec/ 3: https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/ 4: https://datatracker.ietf.org/doc/draft-ietf-kitten-gss-sanon/ 5: https://datatracker.ietf.org/doc/draft-ietf-kitten-password-storage/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAl8gq3IACgkQJTL5F2qV pELNxRAAu7RRKDXEskdXBpHehfpDvXTtXDy5CJdRI3dYsdp7pFNfkJ6kLTAR/zyK E1ZLxAGmk1XkkKAi2rAGbIOqgcdqe/xEKbA5vtRZ4jgwFA2BZorchybREv5twj4n Ym4D9HPwZoGF8hZDSv/JXWQOrPIaBhlPm3sfX6lF9Ue6jHTGdOJrrm4DgUR8jG69 eghRFEcskcRTYzWKz5i0TrpmAEY0Lr0qMWYIHzAMrVuOxxh5tXXezIIjzcfH2F3t 0W9E9npD4TbjMlyNaYuxnEOlCyZwQQhsXsNl4SY2ZFP5xUkSVtxiPNcD+ybJR3C3 OB+GWomfl/EYMTn/Dsz4PgUu0DjooWZqVzmdYFjzqRUr1wi7RYlfs2sa3dXcul42 m+IIGZ/Z2OSUx4KM1ZwWmGKqxBwuE39R9AL0i7PaoUm6sIrS9ux3FZnRy/yaOIxP eC/SuyRWjN3mPBUQblWHxPgm/Ah/IuT+AC+YqlQAlOFtmFBCYQ6C2BSFJRQzqFAT +7PuTlu+HdzoU+CG0QxXxobi3ap0r52XXrARkndD4QksMF1Cxop3aftnXTE9cB5O OgpUbqc4kPCajnSK3m4zEf8K5gUs8vsINhiHuTda7lhCwo1lZ6aoBUfv2zhCHOoW oZNqbfebQkwxlJZ3nlgOM7DOZqhb5vX1JNAU6WObuwvsN326tGM= =vMMT -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 28 17:37:16 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467FC3A0D1E for ; Tue, 28 Jul 2020 17:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=c423Cqsi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vW7Bpik0 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 A7OpRiin4BcE for ; Tue, 28 Jul 2020 17:37:12 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE053A0D1B for ; Tue, 28 Jul 2020 17:37:12 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7549C5C00F0 for ; Tue, 28 Jul 2020 20:37:10 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Tue, 28 Jul 2020 20:37:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm2; bh=zeMfDBve+9PrO2Va8sZHzAIhTvRCOqKBIuqVdd6hWJ0=; b=c423Cqsi 5dN1bFseYVrP6hvcnIquI+zqKDgXVNb991gYdj+GSQ1lrMGFsAQMAzEKQ5GkAU9Z /htW2N5t8KK4+GGxRxwXYWg4Qu8rJYDMCr6O0znVA3/9anDeotLzB9HHMzIqeBDm fVyq08Qj8m4prQprUIhwL9ibj78LYuD1UOvA4fPxDPCvrw9CjsfhB80Ts7fjQlSh V04kUnA8KwDrGZMFz1e2lWsw06ZtRmfClODRCJ0bmIKtmGstu3yuF7zstw+C0rJJ NdOjPDmgksy6oi4L+v4OsvW8gWkroz/dn9WDPKr7uS1oNvlFt4JhoVD42Xd+wZf1 0/NRmyfr7fcbTQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=zeMfDBve+9PrO2Va8sZHzAIhTvRCO qKBIuqVdd6hWJ0=; b=vW7Bpik0Hq3gejtx4qsIAUT7ZhRXXKoPsG1BzyWDFmMXv 6tPGNl+wHWpa9qIbScZKqknCBh87uPgeGto90aR+HIIGQ8struDO2M7A9Gxn1Ayo VlALBqpURsKak/iPTEtNsA1dc+GULU2hAzj0fpm86MMjfQWKGLG0sSb291A8uzu/ FVJvRQq8Zg+ppYaErELmEJ/Uvr3D6GQLhn22yEwNCqCJ5ANqc/KpON8Vd6VhMpwY N1PiaRJ8Bw1ghaCKAEE8Xaynq3g3Cn63eWP5GENIlU1r0mx3qAgzQHlbnS2FuGBn 5j+/ZtyI+REfenKiu3vANlAmtBdDXMRsMzraGJtYQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrieefgdefiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre ertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfieshhgv rghpihhnghgsihhtshdrnhgvtheqnecuggftrfgrthhtvghrnhepkeejjeelkeefleegtd evieehkeegvdehvdegieevtdelhfdvhfejffekjeffueeunecuffhomhgrihhnpehivght fhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2A6EE3C00A1; Tue, 28 Jul 2020 20:37:10 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-128-gd51a832-fm-20200728.001-gd51a8328 Mime-Version: 1.0 Message-Id: Date: Tue, 28 Jul 2020 17:36:49 -0700 From: "Christopher Wood" To: saag@ietf.org Content-Type: text/plain Archived-At: Subject: [saag] TLS WG report for SAAG X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 00:37:14 -0000 The TLS WG session met Tuesday. We discussed the following adopted drafts: - https://tools.ietf.org/html/draft-ietf-tls-subcerts-09 - https://tools.ietf.org/html/draft-ietf-tls-tlsflags-03 The subcerts draft will move forward with final changes after another WGLC. The TLS flags document requires some additional discussion regarding where flag extensions can appear (in SH, EE, NST, etc.). We also discussed the following I-Ds: - https://tools.ietf.org/html/draft-jhoyla-tls-extended-key-schedule-01 - https://tools.ietf.org/html/draft-vvv-tls-cross-sni-resumption-00 - https://tools.ietf.org/html/draft-vvv-tls-alps-00 - https://tools.ietf.org/html/draft-thomson-tls-snip-00 The extended-key-schedule and cross-sni-resumption received somewhat positive support for adoption. The chairs will confirm this on the list. In contrast, both ALPS and SNIP require more discussion on the list. The meeting surfaced several good questions for both that warrant further investigation. The WG also discussed AD feedback on draft-ietf-tls-oldversions-deprecate and possible changes required in the next revision. Best, Chris, on behalf of the TLS chairs From nobody Tue Jul 28 17:58:53 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C845F3A0DCE for ; Tue, 28 Jul 2020 17:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gM4df42-t80z for ; Tue, 28 Jul 2020 17:58:50 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8F983A0DCD for ; Tue, 28 Jul 2020 17:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1595984330; x=1627520330; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vrorfUhu1/cbRaw7cUza7s9cTQwTtWwoNVwn0fhwmo8=; b=Rqt1ubsR55FmWiD7vwe6mcITw/TAOe+MILESeYx8H+zNOxNn+/1GUKc5 thI6uLAQB016+OqXreqaZSA+NXFovfgffqsdhlq0I9D+5CX/UNwn/M1H4 p/iUuef8TRcX+BKdo+RzljO4++NcA+FBRTY5lspObG/gnrr3EeEPeocBQ GydmEZDUbqq5bEPmKULLlk+Dh6SzkRdAXz8mCFwuihU3cAi5KUXgMrhPY E4E0aJIaUJdxpWIb7XZqGE89q1+qp+cwI5fsPyoR2EvPrbGBr55NLPq+b 1mglv+onLQDUrHGhln3Zqj0RkIsfmpxRK/vnwI8U16KNCdyvtBY3JZpyT A==; X-IronPort-AV: E=Sophos;i="5.75,408,1589198400"; d="scan'208";a="149399619" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from uxcn13-ogg-b.uoa.auckland.ac.nz ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 29 Jul 2020 12:58:46 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.3) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Jul 2020 12:58:45 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1497.006; Wed, 29 Jul 2020 12:58:45 +1200 From: Peter Gutmann To: Carsten Bormann , Benjamin Kaduk CC: "saag@ietf.org" Thread-Topic: [saag] On PKI vs. Pinning (SAAG 108 preview) Thread-Index: AQHWZRNEwnqe/1JfAUmje3SMFOnuNqkcq78AgAEQ0N0= Date: Wed, 29 Jul 2020 00:58:45 +0000 Message-ID: <1595984326876.94034@cs.auckland.ac.nz> References: <20200728191331.GV41010@kduck.mit.edu>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 00:58:52 -0000 Carsten Bormann writes:=0A= =0A= >PKI =3D the set of root CAs is determined by one of a oligopoly of entitie= s,=0A= >based on CA/Browser Forum operations, where the entities aren=92t really= =0A= >justifiable parties to the application?=0A= =0A= While that's an accurate definition (if you substitute "WebPKI" for "PKI",= =0A= although for most of the world the two are the same anyway), good luck gett= ing=0A= anyone to admit that in a document :-).=0A= =0A= Peter.=0A= From nobody Tue Jul 28 22:47:12 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1407B3A0FCB; Tue, 28 Jul 2020 22:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNMXHVULYQW4; Tue, 28 Jul 2020 22:47:09 -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 888A13A0FCA; Tue, 28 Jul 2020 22:47:09 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id q6so23677061ljp.4; Tue, 28 Jul 2020 22:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=j6vrELUp0xUINqKYuqjuJQ/lY9+v3Qn8tzmf2JZ5Sms=; b=QvXOBDqSwm7TnUTnrJxp4N/xx/LaSeCOmJ2VZm/J8uhfteYb00RP+kU3/7kkd2UCXV PMDwsILjrKQd0HaUOBqJRZHuD5yOXiKJnpI11lMvdbCpi3F+atEw7BY5ythfUOPqs/wN vi0ahBva4TlVTlJFxN8LM0RifqeyumdWCA8tW/VuyA9YH1VBdhGbv2bTUz+d5FUUdp4Y brUHCoLj3tjHKGYWJQOPXWTdja5pDPk2E/KRR42LvRlXXi1bxNd8h/Kfut17JK7rbbWD nncM53OC6Qobf1gkMr5xoJLhz3gLCnhwfmMM5XX3DhXzr61V5+jNSZIPgPoU427MaGDu cRhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=j6vrELUp0xUINqKYuqjuJQ/lY9+v3Qn8tzmf2JZ5Sms=; b=V7g/K4JPDZIGoJnRBgH4BnM2RVJtj6x50fE4Z9+jXyLUUwy5HBFMtE0+jpJrPPTLpR sfpvRKznN2DjlXUoUWe6u4QogTabxGv4Z4NmJ7JEfrgUJyorJ5HgfRtw8OMr84hIh1fc Q6SKYyWvJZGkr/mmce3AwcmXTcA5oJC43wW7c6W3p4wgbLv+nQxd9tr9nTlnTdRBbgc5 bTkz74otBoqDlrQHY6rXp8bzfpMnhrikx8j5G+TmrtlS6I2/NDac2avu6xJEkYcHgHus myyWy0iOVHiJGNnNLUtHy0ifPP8IXTb/42wzlkZ+NfiEAyVL+8iC23Fje8djYu7Qvc/Y aocQ== X-Gm-Message-State: AOAM531muhXiSlzb5sTIA3TLBYePZhN6OqoqTowIdBBGuURwiqFx7Ygu gMGzso1zDUhvHqEhWL0qhENpfyun3vZT9wYtv68aiVVy X-Google-Smtp-Source: ABdhPJxDIac7rW6q7Dr/O6T4gOKMiwz8H9BQty7dwq1dDCUwXq5Grcf3hAFWxMPpcsAYSPQD25PURmXn7wZl6DYzLC4= X-Received: by 2002:a2e:9b06:: with SMTP id u6mr13020509lji.24.1596001627441; Tue, 28 Jul 2020 22:47:07 -0700 (PDT) MIME-Version: 1.0 From: "Stanislav V. Smyshlyaev" Date: Wed, 29 Jul 2020 08:47:03 +0300 Message-ID: To: saag@ietf.org Cc: cfrg-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000108d7505ab8e16fe" Archived-At: Subject: [saag] CFRG IETF 108 report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 05:47:11 -0000 --000000000000108d7505ab8e16fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable IRTF CFRG does not have a meeting at IETF 108, it met on the 15th of July for 1.5 hours. There were updates on SPAKE2 and VOPRF drafts, as well as a presentation on usage limits on AEAD (adoption call for the =E2=80=9CAEAD limits=E2=80=9D d= raft started after the interim meeting) and a discussion of NKDF construction (for MLS). --000000000000108d7505ab8e16fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
IRTF=C2=A0CFRG=C2=A0does not have a meeting at IETF 1= 08, it met on the 15th of July for 1.5 hours.

There were updates on = SPAKE2 and VOPRF drafts, as well as a presentation on usage limits on AEAD = (adoption call for the =E2=80=9CAEAD limits=E2=80=9D draft started after th= e interim meeting) and a discussion of NKDF construction (for MLS).


--000000000000108d7505ab8e16fe-- From nobody Wed Jul 29 01:14:01 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FA33A10A9; Wed, 29 Jul 2020 01:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n74jb9Adlpq6; Wed, 29 Jul 2020 01:13:57 -0700 (PDT) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE2043A10A7; Wed, 29 Jul 2020 01:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:In-Reply-To:References:Cc:To:From: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=Eh6n/+nNxvkVlCxK36DlOhFpynwkaYg9w9eEOZjSkaU=; b=ObHebIG263op14OPlQ603h8Ari HAKO7HfZ0QsyUo3lhLJXBz5Xim5ZmnlJtlB3gyuYfpojDf6BurN/UCbDBshcLDCzY0i/puDOaI5Pb H2TvByCUr+lv8JljwqHwXoPh105nL7J6PMnapth4INE6rQLzQHYElgdERmKtzBtKbRMeBV9nK7LYc IRvfhoHAD2WPZKV4H2GcjdnoHpfW/7UvTPO7yzKqlNv0UEiTIoOmPc22eeHRaN/n4JegZPh+DM1nQ sZm2oPmnu4boRxLwKgpPzF+XuykTD2sntVP3rL4bd0yxXBTPdeDphZy8Zp4VhqMETTRtcF/vqCbXe KrWkNrWw==; Received: from [82.138.51.3] (port=1094 helo=buildpc) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1k0hDn-0002py-Ab; Wed, 29 Jul 2020 04:13:55 -0400 From: "Valery Smyslov" To: Cc: References: <122a01d6657c$56c501b0$044f0510$@smyslov.net> In-Reply-To: <122a01d6657c$56c501b0$044f0510$@smyslov.net> Date: Wed, 29 Jul 2020 11:13:54 +0300 Message-ID: <122c01d66580$3556d270$a0047750$@smyslov.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHNzlEIM4/GsRhdsGK4cXm5QgBjMKkvYvvQ Content-Language: ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net Archived-At: Subject: [saag] UTA WG report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 08:13:59 -0000 UTA WG didn't meet at IETF 107 and is not meeting at IETF 108. We had a virtual interim meeting in April. Since IETF 106: - Deprecation of use of TLS 1.1 for Email Submission and Access draft is still in the RFC Editor queue waiting for a missing normative reference to tls-oldversions-deprecate draft. We have adopted 2 new WG documents: - RFC7525-bis draft that would update recommendations based on wider adoption of TLS 1.3 - TLS/DTLS 1.3 Profiles for the Internet of Things that is concerned with IoT specifics of using TLS and DTLS 1.3 Leif & Valery From nobody Wed Jul 29 05:03:41 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686803A09E4 for ; Wed, 29 Jul 2020 05:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=0.116, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 NDVE2Kbqae1i for ; Wed, 29 Jul 2020 05:03:35 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 16C633A0B6C for ; Wed, 29 Jul 2020 05:03:25 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id r4so18420059wrx.9 for ; Wed, 29 Jul 2020 05:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=4DWi5SiGciSkGKP2bZYMWWXGdWJw5fuFCJ+qpMnxI/o=; b=OGvKRBnB6VtT6oc0vmBCS5e4/wvd3THEYmjHCDTRPr2yrvbu5q3n1jOPVefL0jCKIs UUS29nuJT3/2xcqlLQmxkRcmO0mde4C1/hR1cDWP/yJkye0AvZLdtZ6yURjfOy/WtbUr rYeNeN/NCr1H7IZKERDo2roC2GAaJ3uUoTjJheR3UcvIrKVS08ErU+gsCK0BNTa2jjh+ +HS1V6oHVRG3QSKiLly5URnFdLxhw2iBBgy0zKwa0mr36QYRI0YmtE5uCsGQ7hEKkA65 Q3AgMhboEmln7Ic4Q/4j9tsG/vzpiawX1f0Hpdfjm9r4tAO3obzmZJ4MpY3h4OvjCD4u cUhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=4DWi5SiGciSkGKP2bZYMWWXGdWJw5fuFCJ+qpMnxI/o=; b=qsZq0CCCYVNDbYFol/WvnCkRi0ySEYBJ/0M9USZhGyZ0+/m6tNmGVwZOpLc9EwYYI+ xuQiRe0nB4g6+7LbklN5qKt+9yYBkFsszjr+1vZOcqUygq5WQ3eMnzXLMdfNpVruKfqB AGkp9g7Rm7hJC2TH7BBN1cS+UizVgc8K1heEAWiD0bzTdCdTdrOna+17AiXDgKAk6eyh e5Ns2B2bpiVpDWatTWqSRL/U+CqdqQaMDEUNQLfeQdcceafv4bFgLZiHmL89jshdkH4j VTFzPVMKXuhpzIqiGEVGlbjiqPsLfX9h8enGbxe1K7kGOvBUsd8kk3QXOWMqxBh98d+F SYdA== X-Gm-Message-State: AOAM531jOxk0RE6IjS4BHAWl5uaz9NNI87vEoI6Ly7yHoGL7fU7OQ1mR gxQ+ZKShbGsQKkEg+ZdFa3M= X-Google-Smtp-Source: ABdhPJzkd1yPymlHV+4p0GwH5cp5rLhZ+10TiRKnWLtMHXtkH86vR4YlKJcsqdZs4Q5CioyLMrbO7w== X-Received: by 2002:a5d:6992:: with SMTP id g18mr28711995wru.15.1596024203452; Wed, 29 Jul 2020 05:03:23 -0700 (PDT) Received: from [10.0.0.140] (bzq-109-66-125-13.red.bezeqint.net. [109.66.125.13]) by smtp.gmail.com with ESMTPSA id h11sm5433548wrb.68.2020.07.29.05.03.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jul 2020 05:03:22 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.39.20071300 Date: Wed, 29 Jul 2020 15:03:21 +0300 From: Yaron Sheffer To: Stephen Farrell , Benjamin Kaduk CC: Message-ID: <5DFF62E7-6D72-44FC-9B03-2706E1BB7EDF@gmail.com> Thread-Topic: [saag] On PKI vs. Pinning (SAAG 108 preview) References: <20200728191331.GV41010@kduck.mit.edu> <20200728194235.GY41010@kduck.mit.edu> <1c4951d6-a67c-47c6-315e-2ad3776c94ec@cs.tcd.ie> In-Reply-To: <1c4951d6-a67c-47c6-315e-2ad3776c94ec@cs.tcd.ie> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 12:03:39 -0000 Exactly! Daniel Migault and I published an RFC [1] on "identity pinning" in= TLS 1.3. This is TOFU pinning seen as a second factor, where the first fact= or is PKI. It also happens to be very low maintenance and independent of cer= tificate (EE and CA certificate) changes. This solution is especially useful= for enterprise use cases, where certificate transparency doesn't do the job= . Thanks, Yaron [1] https://www.rfc-editor.org/rfc/rfc8672.html =EF=BB=BFOn 7/28/20, 22:49, "saag on behalf of Stephen Farrell" wrote: On 28/07/2020 20:42, Benjamin Kaduk wrote: > Sorry for the clumsy description. Basically, if you squint hard, you= could > claim that at least some types of pinning are actually a PKI, just a > degenerate PKI.=20 Ah gotcha. ISTM more useful to treat pinning as an adjunct to whatever PKI is used by the application that can be MITM'd and not bother with pinning as a potential replacement for that PKI. There's nothing wrong with an application being based on it's very-own PKI of course, but seems less useful for the IETF to try describe pinning for custom protocols where we don't know the details. Cheers, S. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From nobody Wed Jul 29 08:34:02 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681463A0C2D for ; Wed, 29 Jul 2020 08:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5d7dqHYHtgf for ; Wed, 29 Jul 2020 08:33:50 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 A1B9B3A0B9D for ; Wed, 29 Jul 2020 08:33:50 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id 11so22626075qkn.2 for ; Wed, 29 Jul 2020 08:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nB3v4gXSfAMw8v2QCSrwU4zN9abf7h6Xtt44kwCcNE8=; b=oBCOldjl4srhMuwenbVfsEMnbx9kRd0SoKc8/j5bglFgA8Dx+OigdRkY2Za3PB3sFN ZjXRbN/0lmoIPFd2GASB811Podn0leD8d9dmYqk49DhZo33nsshs8FO5UQwgb9IV8h0V +H7ptdmJXHTpmAmN/WrRjKAnOEW8SKaMa7BXd/nq/Xfmo3jN/26Cu2/tqhHrb5kq2io2 vzoUUHeNZsaD97kuEzviULYdIHW9B210Q9RbmJQCKA8w4Pl6YCLWJMDMNJpumUhyRvEt n9OfUjAZsgE5NQrbTk1IQNTYFhla6KYlz2pizjf5HG70IZTyh7n31xSdfuePclOqArI1 /hJQ== 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=nB3v4gXSfAMw8v2QCSrwU4zN9abf7h6Xtt44kwCcNE8=; b=ad0eRH6oNZguPtt3TG/jWYWEkulndmOREpsqHjbLH5YXSt41jQcBGo304E/Xz9KM0D xyhJJhlibs5c0lpLgfrDz0PnwO3Jbar70/U7cVBFr7pUPUNxsiv3r+LnbbbvUhz58n7n 8/PAPNZAeY15J56tlhXLIG+zUTK4Y6wLaQKNVaOgdxQpfZ8fNnCMGxhB81tEUyDtS73K Jn2dWnAmnufJBDWzJcA7rAEZI//WY2r2nryri5vnCB9izquyE/SjfsepBK9QVSa21nsc myz4WzA3hs0x7HgX2Q3L7CLuwsFaO60dcENA1yI/ynlD2oa0tNsceDNYYRrqmvr7OzJA pVeA== X-Gm-Message-State: AOAM533lmYza0Xavw4HUqMAn6tqHBuQ9LUClEbK9S/7ZZO0uCZd4s3kz 6GBUXBAu7FjHTQAnkBsspqjvbxh0dmmebb/WKk44tA== X-Google-Smtp-Source: ABdhPJzWA5h7pLw2/WmzF66KOsj8+DOjOaJlU27ZTqDxL/NT5JKubO7XqlAylREbocz2MQBjvVotPyfQAI7UEi0PnfE= X-Received: by 2002:a05:620a:63a:: with SMTP id 26mr34495437qkv.490.1596036829416; Wed, 29 Jul 2020 08:33:49 -0700 (PDT) MIME-Version: 1.0 References: <20200728191331.GV41010@kduck.mit.edu> In-Reply-To: From: Richard Barnes Date: Wed, 29 Jul 2020 11:33:17 -0400 Message-ID: To: Eric Rescorla Cc: Benjamin Kaduk , IETF SAAG Content-Type: multipart/alternative; boundary="000000000000442c7605ab9648bc" Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 15:33:58 -0000 --000000000000442c7605ab9648bc Content-Type: text/plain; charset="UTF-8" As is often the case, I agree with EKR here. The point I would emphasize is that all of these options have the same protocol footprint. Regardless of where you root trust or how you constrain it, the protocol needs to carry credentials that allow PKI-style chaining/delegation. --Richard On Tue, Jul 28, 2020 at 6:03 PM Eric Rescorla wrote: > It might be helpful to nail down our terminology here. > > Traditionally, we have three main approaches to public-key based key > management: > > - Manual configuration and/or TOFU (a la SSH) > - DNSSEC with something like TLSA > - Deferring to some set of CAs (PKI) [0] > > As a practical matter, PKIs currently come in two flavors: > > - Publicly verifiable certificates which are rooted in one of a set > of commonly trusted CAs (generally WebPKI). > - Non-publicly verifiable certificates which are rooted in some other > set of CAs (e.g., enterprise CAs). > > If you want to be able to talk to any machine on the Internet and > you're using PKI [again, you could use DNSSEC/TLSA] then you need to > have publicly verifiable certificates. However, there are a large > number of such CAs and any of them can issue for a given name. This is > where pinning comes in, as a technique for restricting the CAs (or EE > keys) which can be used to authenticate a given name. Importantly, > pinning only *restricts* the set of keys which can be used with a > given domain; it doesn't expand it. IOW, you still need a valid PKI > cert. If you're just configuring a key and not using the PKI, > that's not pinning. > > Pinning on the Web [RFC 7469] is now more than five years old and in > the intervening period, opinion has shifted, with people increasingly > believing that pinning was too brittle a feature to deploy safely. > For this reason, Firefox and Chrome have both deprecated pinning (I > believe that Safari and IE never had it). So, to the extent to which > there is a consensus, its that pinning is not a best practice. > > I think there's a separate question of what one ought to do when > one does not need to connect to any machine on the Internet [1]. In > those cases, whether manual configuration or a private CA is most > appropriate seems to be a judgement call depending on how complicated > the deployment is. I don't know the RPC-over-TLS setting enough > to know what is best here. > > -Ekr > > > [0] One can argue that DNSSEC is a form of PKI, but I've broken > it out for convenience here. > > [1] You call out the special case where an app is talking back to > its own site: > > A banking mobile app > surely should pin the bank's known CA, rather than leaving an > enterprise CA > free to MITM a user's session, whereas something that wants to be part > of > the Web is largely forced to adopt the Web PKI. > > I would make two points about this. As a practical matter, it's not > uncommmon for this kind of captive app to just use a generic WebPKI > certificate, so this isn't really that different from serving up > an HPKP header to a generic Web browser. Second, prior to HPKP being > deprecated, it was standard practice to exempt locally installed > CAs from pin checks because otherwise users would experience failures > on networks which had MITM proxies. It seems like a similar set > of considerations would apply in this case. > > > > > > > > > > > > > > > > On Tue, Jul 28, 2020 at 12:13 PM Benjamin Kaduk wrote: > >> Hi all, >> >> One of the agenda items for Thursday's SAAG session at IETF 108 is >> "Discussion on PKI vs. Pinning Applicability". This is intended to be >> Security Area Advisory Group in its core meaning -- I want to get the >> sense >> of the IETF security community. There are some draft slides for SAAG at >> >> https://www.ietf.org/proceedings/108/slides/slides-108-saag-chair-slides-pkipinning-bcp-72-00 >> (starting at slide 33; note to self: change template to include slide >> numbers), and in true IETF spirit I'm hoping we can get a lot of it >> covered >> on the list in advance. >> >> As a lead-in, this topic came to mind due to a thread on the NFSv4 list, >> discussing the RPC-over-TLS work that's in IESG Evaluation. A participant >> made the claim (see thread at >> https://mailarchive.ietf.org/arch/msg/nfsv4/SLTNqWbjE-H8JshLk0HwlwxArrI/) >> that certificate pinning is needed for RPC-TLS, and I did not have the >> impression that this was the consensus position of the IETF security >> community ... but I also don't have any data to support that impression >> (yet?). >> >> It's clear that there are benefits and drawbacks of both approaches, >> relating to scalability, ease of (minimal) deployment, key rotation, need >> for maintaining highly secure infrastructure to protect high-value >> secrets, >> how revocation is handled, whether or not having an enterprise CA is seen >> as a bug or feature, etc. Similarly, there seem to be some use cases that >> naturally lean towards one strategy or the other. A banking mobile app >> surely should pin the bank's known CA, rather than leaving an enterprise >> CA >> free to MITM a user's session, whereas something that wants to be part of >> the Web is largely forced to adopt the Web PKI. >> >> This leads to some questions that may be worth discussing (both here on >> the >> list and in-person on Thursday): >> >> Can we make a classification of what types of protocols are naturally >> suited for PKI scenarios and what types of protocols are naturally suited >> for pinning? >> >> If you're going to pin, how does it matter if you pin a (raw) public key, >> a >> self-signed non-CA cert, an arbitrary cert, an intermediate CA, a root CA, >> etc? >> >> Is there benefit in arranging for a description of the system where the >> ability to pin is just a degenerate case of a PKI, with a single trust >> anchor and no real hierarchy? >> >> Do we want all protocols that specify one to be usable with the other (and >> document it that way)? >> >> Is there utility in writing a document to cover any of the above topics? >> >> Thanks in advance for a lively discussion, >> >> Ben >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --000000000000442c7605ab9648bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As is often the case, I agree with EKR here.

The point I would emphasize is that all of these options h= ave the same protocol footprint.=C2=A0 Regardless of where you root trust o= r how you constrain it, the protocol needs to carry credentials that allow = PKI-style chaining/delegation.

--Richard
=

= On Tue, Jul 28, 2020 at 6:03 PM Eric Rescorla <ekr@rtfm.com> wrote:
It might be helpful to nail down our te= rminology here.

Traditionally, we have three main approaches to publ= ic-key based key
management:

- Manual configuration and/or TOFU (= a la SSH)
- DNSSEC with something like TLSA
- Deferring to some set o= f CAs (PKI) [0]

As a practical matter, PKIs currently come in two fl= avors:

- Publicly verifiable certificates which are rooted in one of= a set
=C2=A0 of commonly trusted CAs (generally WebPKI).
- Non-publi= cly verifiable certificates which are rooted in some other
=C2=A0 set of= CAs (e.g., enterprise CAs).

If you want to be able to talk to any m= achine on the Internet and
you're using PKI [again, you could use DN= SSEC/TLSA] then you need to
have publicly verifiable certificates. Howev= er, there are a large
number of such CAs and any of them can issue for a= given name. This is
where pinning comes in, as a technique for restrict= ing the CAs (or EE
keys) which can be used to authenticate a given name.= Importantly,
pinning only *restricts* the set of keys which can be used= with a
given domain; it doesn't expand it. IOW, you still need a va= lid PKI
cert. If you're just configuring a key and not using the PKI= ,
that's not pinning.

Pinning on the Web [RFC 7469] is now mo= re than five years old and in
the intervening period, opinion has shifte= d, with people increasingly
believing that pinning was too brittle a fea= ture to deploy safely.
For this reason, Firefox and Chrome have both dep= recated pinning (I
believe that Safari and IE never had it). So, to the = extent to which
there is a consensus, its that pinning is not a best pra= ctice.

I think there's a separate question of what one ought to = do when
one does not need to connect to any machine on the Internet [1].= In
those cases, whether manual configuration or a private CA is mostappropriate seems to be a judgement call depending on how complicated
t= he deployment is. I don't know the RPC-over-TLS setting enough
to kn= ow what is best here.

-Ekr


[0] One can argue that DNSSEC = is a form of PKI, but I've broken
it out for convenience here.
[1] You call out the special case where an app is talking back to
its = own site:

=C2=A0 =C2=A0A banking mobile app
=C2=A0 =C2=A0surely s= hould pin the bank's known CA, rather than leaving an enterprise CA
= =C2=A0 =C2=A0free to MITM a user's session, whereas something that want= s to be part of
=C2=A0 =C2=A0the Web is largely forced to adopt the Web = PKI.

I would make two points about this. As a practical matter, it&#= 39;s not
uncommmon for this kind of captive app to just use a generic We= bPKI
certificate, so this isn't really that different from serving u= p
an HPKP header to a generic Web browser. Second, prior to HPKP beingdeprecated, it was standard practice to exempt locally installed
CAs f= rom pin checks because otherwise users would experience failures
on netw= orks which had MITM proxies. It seems like a similar set
of consideratio= ns would apply in this case.










=C2=A0



On Tue, Jul 28, 2020 at 12:13 PM Benjamin Kaduk <kaduk@mit.edu> wrote= :
Hi all,

One of the agenda items for Thursday's SAAG session at IETF 108 is
"Discussion on PKI vs. Pinning Applicability".=C2=A0 This is inte= nded to be
Security Area Advisory Group in its core meaning -- I want to get the sense=
of the IETF security community.=C2=A0 There are some draft slides for SAAG = at
https:/= /www.ietf.org/proceedings/108/slides/slides-108-saag-chair-slides-pkipinnin= g-bcp-72-00
(starting at slide 33; note to self: change template to include slide
numbers), and in true IETF spirit I'm hoping we can get a lot of it cov= ered
on the list in advance.

As a lead-in, this topic came to mind due to a thread on the NFSv4 list, discussing the RPC-over-TLS work that's in IESG Evaluation.=C2=A0 A par= ticipant
made the claim (see thread at
https://mailarchive.ietf.org= /arch/msg/nfsv4/SLTNqWbjE-H8JshLk0HwlwxArrI/)
that certificate pinning is needed for RPC-TLS, and I did not have the
impression that this was the consensus position of the IETF security
community ... but I also don't have any data to support that impression=
(yet?).

It's clear that there are benefits and drawbacks of both approaches, relating to scalability, ease of (minimal) deployment, key rotation, need for maintaining highly secure infrastructure to protect high-value secrets,=
how revocation is handled, whether or not having an enterprise CA is seen as a bug or feature, etc.=C2=A0 Similarly, there seem to be some use cases = that
naturally lean towards one strategy or the other.=C2=A0 A banking mobile ap= p
surely should pin the bank's known CA, rather than leaving an enterpris= e CA
free to MITM a user's session, whereas something that wants to be part = of
the Web is largely forced to adopt the Web PKI.

This leads to some questions that may be worth discussing (both here on the=
list and in-person on Thursday):

Can we make a classification of what types of protocols are naturally
suited for PKI scenarios and what types of protocols are naturally suited for pinning?

If you're going to pin, how does it matter if you pin a (raw) public ke= y, a
self-signed non-CA cert, an arbitrary cert, an intermediate CA, a root CA,<= br> etc?

Is there benefit in arranging for a description of the system where the
ability to pin is just a degenerate case of a PKI, with a single trust
anchor and no real hierarchy?

Do we want all protocols that specify one to be usable with the other (and<= br> document it that way)?

Is there utility in writing a document to cover any of the above topics?
Thanks in advance for a lively discussion,

Ben

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--000000000000442c7605ab9648bc-- From nobody Wed Jul 29 09:03:51 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CB73A0C7B for ; Wed, 29 Jul 2020 09:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 fOk4M2O4uLOt for ; Wed, 29 Jul 2020 09:03:48 -0700 (PDT) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 D6DCB3A0C77 for ; Wed, 29 Jul 2020 09:03:47 -0700 (PDT) Received: by mail-vs1-xe33.google.com with SMTP id a17so12346411vsq.6 for ; Wed, 29 Jul 2020 09:03:47 -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=2eURCWa/LUofeY1t4owcVgvc2ggbDcF+EDjxX70P0p4=; b=Fv3ZHJzmL7cWu+WMMFPLL+92Ais5GH0ZL0EpmM8qE7EX5U2WigXfkhoX1Iw52dkifh ER6ZLc9Ia8+A9DlcPsYuwV1N7Eu1iZE5S1RU3aAPxx44rX4JyJxIlP0hFlRzmY1SDSUK V5Ujon754xj5ws959vIWaicpPgJOhgEtVbjTOl9osgDxVnA0OLzvfSpsenLzWZ9b9T+J 9Yd8ym0tp/ljKpSEmDLM1iwFKD4AOAwO5qW88XHWC6qCMkQ+IOjC/RLnfJpzW9+v2Nr5 vqty/k2H6G2Xn5J0sBf2qpVDFICExjXaP1Xw4ixmbc2T+HzY3qT8llffyOT/lYiXqd7I mpJQ== 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=2eURCWa/LUofeY1t4owcVgvc2ggbDcF+EDjxX70P0p4=; b=X/W4prq67TJFw1wl/GmBovFidKYebsQkErYSfEPgkwOzpa/WhdgeIhuHMkeT9WvBn5 tSuPcCThuj5BfCsbAp7TZPTboWt9iiWRZfLK5QFFvcn377NGF+dT+D1/Bf6rTG27b3pK GhmbyKrZ48hKsmiVS9iTXj5YKMAHsISgeDgDEMaFajPTJFsh+aaRWu2JACptw0dv+9XD 58RZNpN1d03/a/vaQkWmAyqlM+bVNJXHm/MToSlKnoXfJSXcttl4REAFqJHZEOYFEpZf aM5/dln8j3xDAtcY05osVHCY8GW6qjKTJOp5aMIS/43zFDFjWZtqaKaMWxfn5VpPJErb t9qA== X-Gm-Message-State: AOAM531R4M7RiGqO7KxPrrJdynsY8sm5vqFgRn/x8RW5qpdSGjdwWf6/ fFwjlm44FVyXcv4+JysHCfC0B6D8lzFGxrjgZpYzBg== X-Google-Smtp-Source: ABdhPJz2S8w2c4QXlMFPNa80BeSvjLc2JbxUmUu2DdkvGAkCnMSPeUIy1Jt8OBwaXvlteM5voZ42pCy6eoVR+cFmx0E= X-Received: by 2002:a67:e28c:: with SMTP id g12mr5498623vsf.31.1596038625840; Wed, 29 Jul 2020 09:03:45 -0700 (PDT) MIME-Version: 1.0 References: <20200728191331.GV41010@kduck.mit.edu> <20200728194235.GY41010@kduck.mit.edu> <1c4951d6-a67c-47c6-315e-2ad3776c94ec@cs.tcd.ie> In-Reply-To: From: Daniel Migault Date: Wed, 29 Jul 2020 12:03:34 -0400 Message-ID: To: Stephen Farrell Cc: Ben Laurie , IETF Security Area Advisory Group Content-Type: multipart/alternative; boundary="00000000000057d30e05ab96b3e6" Archived-At: Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 16:03:49 -0000 --00000000000057d30e05ab96b3e6 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 28, 2020 at 4:09 PM Stephen Farrell wrote: > > > On 28/07/2020 20:56, Ben Laurie wrote: > > I'm a little surprised by this conversation. Why would SAAG want to > support > > a practice that flies in the face of everything we know about key > > management? > > Sorry if I gave the wrong impression. I agree with you > that pinning to application keys is a bad idea. > I am wondering what exactly is an application key. Is-it a sort of self-signed certificate hard coded in the application or would a secret generated by the application on a per session basis is considered as an application key. > > I do think there's a role for pinning to CAs that you > already gotta trust, as a way to fail rather than allow > a MITM, for the cases where that's better. > > One issue I see is that we have CA we do not trust. I suppose here that CA pining is mentioned as opposed to certificate pinning. In both cases, it seems to me that pinning these entities makes it very hard for the application to change CA or certificate. > S > > > > > On Tue, 28 Jul 2020 at 20:49, Stephen Farrell > > > wrote: > > > >> > >> > >> On 28/07/2020 20:42, Benjamin Kaduk wrote: > >>> Sorry for the clumsy description. Basically, if you squint hard, you > >> could > >>> claim that at least some types of pinning are actually a PKI, just a > >>> degenerate PKI. > >> > >> Ah gotcha. > >> > >> ISTM more useful to treat pinning as an adjunct to whatever > >> PKI is used by the application that can be MITM'd and not > >> bother with pinning as a potential replacement for that > >> PKI. There's nothing wrong with an application being based > >> on it's very-own PKI of course, but seems less useful for > >> the IETF to try describe pinning for custom protocols where > >> we don't know the details. > >> > >> Cheers, > >> S. > >> _______________________________________________ > >> saag mailing list > >> saag@ietf.org > >> https://www.ietf.org/mailman/listinfo/saag > >> > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- Daniel Migault Ericsson --00000000000057d30e05ab96b3e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jul 28, 2020 at 4:09 PM Steph= en Farrell <stephen.farrell= @cs.tcd.ie> wrote:


On 28/07/2020 20:56, Ben Laurie wrote:
> I'm a little surprised by this conversation. Why would SAAG want t= o support
> a practice that flies in the face of everything we know about key
> management?

Sorry if I gave the wrong impression. I agree with you
that pinning to application keys is a bad idea.
=C2=A0=
I am wondering what exactly is an application key. Is-it a sort = of self-signed certificate hard coded in the application or would a secret = generated by the application on=C2=A0 a per session basis is considered as = an application key.=C2=A0=C2=A0
=C2=A0

I do think there's a role for pinning to CAs that you
already gotta trust, as a way to fail rather than allow
a MITM, for the cases where that's better.

One issue I see is that we have CA we do not trust. I= suppose here that CA pining is mentioned as opposed to certificate pinning= . In both cases, it seems to me that pinning these entities makes it very h= ard for the application to change CA=C2=A0 or certificate.=C2=A0
= =C2=A0
S

>
> On Tue, 28 Jul 2020 at 20:49, Stephen Farrell <stephen.farrell@cs.tcd.ie>= ;
> wrote:
>
>>
>>
>> On 28/07/2020 20:42, Benjamin Kaduk wrote:
>>> Sorry for the clumsy description.=C2=A0 Basically, if you squi= nt hard, you
>> could
>>> claim that at least some types of pinning are actually a PKI, = just a
>>> degenerate PKI.
>>
>> Ah gotcha.
>>
>> ISTM more useful to treat pinning as an adjunct to whatever
>> PKI is used by the application that can be MITM'd and not
>> bother with pinning as a potential replacement for that
>> PKI. There's nothing wrong with an application being based
>> on it's very-own PKI of course, but seems less useful for
>> the IETF to try describe pinning for custom protocols where
>> we don't know the details.
>>
>> Cheers,
>> S.
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag >>
>
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag


--
Daniel Migault
Ericsson
--00000000000057d30e05ab96b3e6-- From nobody Wed Jul 29 14:29:43 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0273A0F2C for ; Wed, 29 Jul 2020 14:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nightwatchcybersecurity-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 0GCIwstrc72i for ; Wed, 29 Jul 2020 14:29:39 -0700 (PDT) Received: from mail-pl1-x644.google.com (mail-pl1-x644.google.com [IPv6:2607:f8b0:4864:20::644]) (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 56C163A0F0B for ; Wed, 29 Jul 2020 14:29:39 -0700 (PDT) Received: by mail-pl1-x644.google.com with SMTP id m16so12570926pls.5 for ; Wed, 29 Jul 2020 14:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XX6XgurfHL3OQfQVZfXzPIEHAOsONj0wui0ig68pRt0=; b=THIYgHZyvJKoiacwRb1m2tAWV/f7ILlVhWo3KjpyWQafbSXu+hTPtX13qp4xpA6S59 InsWo997QAsJsaCQe04zsap9vdPqKZlllG4uBBTniy4UEBZo1bXRVGvtKdot9cMltM7i ICvWd00WVglb03lBdTMVkXvMonoJt4U67yycKHcVVukccrNCUVxm56wtGnQPSGLIHgXY 7q9zFMZee98ZKxLpgLGj8B4uDhlP1LArZ1Azgk2UgEtuENd4T+oJaJiIXcUnImTjaJYC b+1tN0ZmPtRPb3g91t+CtA6QrdAuWwHYdXPLMIm9JwujTk7QN8hQIGgyovVBEtvpzxkf 8rGQ== 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=XX6XgurfHL3OQfQVZfXzPIEHAOsONj0wui0ig68pRt0=; b=cdKjoPQQbm3TOQJ5OjljBjIytFqc13t6tO6S2WlJrHfpuVircQBLCpkfKIJjy65V+u 5jprMaPgrZ9rLcg3jvkOQ7IqtmECr4Wh+kHfrgMgj7QN6cHKgRCeRrTUTdU6QZyHA7T2 2lBeb6p6twRDqEEeh3IGa7OBsNOFUlfwjJlaD8YmUZHUyNTOi0fU1FMHXnHgWy+ngG+Y YYpwhY2WYxil0Kp/h5sWrINSFjFx+6nEzvD9l/L4BOV5ItsZu3Yfwd54uRHelbXSU4eC TiIXPmAZXUuN0XyimE6QbzebgU03xlE/d65EkLZzi4j4OdCRoeElqvdYGxvBxFVMqKxc gWpg== X-Gm-Message-State: AOAM531yBNeSVD3g5GJrPhIyhAv6N9zLF3ERG1bTp6jpdyZUB++6nLEk cmQqVZekYjy08Gw+bPIoJqU5TGV/eoxWGebCLRWl7w== X-Google-Smtp-Source: ABdhPJwgfF8mO1FDsRLjQcRbK2jAopNJMep4VHX8AFjw4hKc9zb8Ph8QOw5aMx2V35oDB1+vZUZKXg1+ZsBPBoCY0+Q= X-Received: by 2002:a17:90a:fa8c:: with SMTP id cu12mr12108479pjb.229.1596058178671; Wed, 29 Jul 2020 14:29:38 -0700 (PDT) MIME-Version: 1.0 References: <20200630222455.GX58278@kduck.mit.edu> <20200721054121.GE41010@kduck.mit.edu> In-Reply-To: <20200721054121.GE41010@kduck.mit.edu> From: Yakov Shafranovich Date: Wed, 29 Jul 2020 17:29:02 -0400 Message-ID: To: Benjamin Kaduk Cc: draft-foudil-securitytxt@ietf.org, Security Area Advisory Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] results of IETF LC for draft-foudil-securitytxt-08 and next steps X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 21:29:42 -0000 Apologizes for the delayed reply On Tue, Jul 21, 2020 at 1:41 AM Benjamin Kaduk wrote: > On Sun, Jul 12, 2020 at 08:14:33PM -0400, Yakov Shafranovich wrote: > > On Tue, Jun 30, 2020 at 6:25 PM Benjamin Kaduk wrote: > > > > Similarly, the refocusing on having the file be targeted at humans allows > > > for us to reiterate that human judgment is key in deciding when to use the > > > contents of a security.txt file vs. seeking other reporting mechanisms. > > > This applies for old/expired files, of course, but also to the recurring > > > topic of reporting compromise vs. reporting vulnerability. When reporting > > > compromise, extra caution is needed, and there is probably some more that > > > can be said in Section 6.1 (see next paragraph). > > > > > > The topic of use for reporting compromise vs. vulnerability was raised by > > > many reviewers, to the extent that it seems like it would be very > > > challenging to craft text that would definitively convince the reader to not > > > use the contents of the files for reporting cases of active compromise, or > > > even cases of vulnerability that would easily lead to active compromise. > > > Given that Section 1.1 is entitled "Motivation, Prior Work and Scope", it > > > seems like a very good place to put a notice that "reporting compromised > > > resources (e.g., web sites) is related to, but distinct from, reporting > > > security vulnerabilities; the mechanism defined in this document is intended > > > for reporting vulnerabilities. If it is used to report cases of active > > > compromise, or vulnerabilities that would lead to compromise of the > > > system(s) involved in this mechanism, additional considerations apply, as > > > discussed in Section 6.1". To expound on the nature of these considerations > > > a bit more, when there is (the possibility of) active compromise, the > > > "ambient authority" granted by finding the contents of the file at the given > > > domain or other location is no longer trustworthy. In such cases, we should > > > expect there to be an "additional source of authority" (or "trust chain") > > > that can give a sense of confidence in the reliability of the contents > > > therein. A PGP cleartext signature is already recommended and can be one > > > such additional source of authority (provided that there is a trust path to > > > the key that made the signature); other routes to such additional sources of > > > authority were posited in the review comments, such as putting a > > > cryptographic hash of the security.txt contents in the DNS under a DNSSEC > > > signature. I think that requiring such an additional source of authority > > > (though not a specific mechanism thereof) would go a long way to alleviating > > > concerns of misuse of security.txt from compromised systems. However, I'm > > > not entirely sure how practical it would be to impose such a requirement > > > given the current state of defined mechanisms. I'm hoping to get some more > > > feedback from the community on this topic, having framed it in this way -- > > > the previous discussion seemed focused on other aspects of the problem and > > > did not get very far towards a concrete resolution. At the very least, we > > > will need more discussion that specifically in case of compromise, the > > > "additional source of authority" is the only source of authority. I would > > > expect this text to go in Section 6.1. > > > > > > > I am adding this to sections 1.1. and 6.1, HOWEVER, my sense of the LC > > comments is that using this file for incident response is ill advised > > and should not be done. Perhaps, we should add a disclaimer that it > > should not be used that way and leave it at that? > > In some abstract sense I agree that it is ill advised, but I do not think > that any words we write will stop everyone from trying to use it for > incident response. So I think that even if we have such a disclaimer, in > order to be doing the responsible thing we'd still need to say something > about the risks of using it for incident response and our current best > thoughts about mitigating those risks. > This is going to need some thinking - will take a look and get back to you > > > > > > > > And finally, a few additional comments from reading the -09: > > > > > > Section 3 > > > > > > "field-name" in section 3.6.8 of [RFC5322]. Fields are case- > > > insensitive (as per section 2.3 of [RFC5234]). The "value" comes > > > > > > nit: I think it's just the "Field names" that are case-insensitive. > > > > > > > Can you clarify this? The way I am reading RFC5234, it sounds like any > > ABNF terminal characters are case-insensitive: > > > > "NOTE: > > ABNF strings are case insensitive and the character set for these > > strings is US-ASCII." > > " > > That's true for ABNF that we write ourselves, but it doesn't seem to be > true for all of the fields that we're defining. Specifically, we use the > 'uri' construction from RFC 3986 in several places, and as > https://tools.ietf.org/html/rfc3986#section-6.2.2.1 points out, in the > general case, many of the URI components are assumed to be case-sensitive. > While we could try to say something about the bits of field contents that > we do specify, it's probably easier to just talk about the Field names and > not make things too complicated. > I will take a look again > > > Section 3.1 > > > > > > For HTTP servers, a "security.txt" file MUST only apply to the domain > > > or IP address in the URI used to retrieve it, not to any of its > > > subdomains or parent domains. > > > > > > [Depending on how the discussion about "product vs. website vulnerabilities" > > > resolves, this might need to grow a disclaimer that it's about the HTTP > > > resources at those domains.] > > > Will watch this From nobody Wed Jul 29 15:32:07 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C103A08CD for ; Wed, 29 Jul 2020 15:32:06 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFixJLWaAQEE for ; Wed, 29 Jul 2020 15:32:05 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 D28033A08C7 for ; Wed, 29 Jul 2020 15:32:04 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id l27so11541638oti.3 for ; Wed, 29 Jul 2020 15:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=to:from:subject:autocrypt:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=+ihNDsCbXjQP9SfqvqLvTSdvzg7uZxzuTLokEk95ZNA=; b=n/uEZztThOBh+pbL9Rc9gBOD0J/A4zKSGzq89Cd9rNmF8ASD3AoywcHZhKJqpmXEry SfNJg3HOM0xsSHRvyTpmU6+V8gbxmIX+ZvbV3zZ9ltJoybBiOIQNwFa3avDQvdgS61xC aw7Cmb7vEu0MFqCcCXKRKcS348x+/CzH9sq3JxfzpN/tzHSzw3fpJE+hsDG9kBHvbaqg 9L/qD1K/Pe6ZzMgoUv6k3Jo6qh8x5emuFrtU6tseJS43c86tYQRLEGRPY54kNaySVutQ k+Yn98WGfwqLZ2tXFKVjbVjsTV0y/9GfMI0SPwcRMo+63mVRHOYsiNtZ08VzMoozZWBV 5oVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:autocrypt:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=+ihNDsCbXjQP9SfqvqLvTSdvzg7uZxzuTLokEk95ZNA=; b=NWsN1vhlK0AtgB8Yv03nCorf9LmRFoAO44Vzc9MUpbEsf2mCj+x9Uv9L8+AES3s2Jy CHSc5Xl968fSmEd9FFD6YAHMUxF/T1ZHdPSCoV5p2w5a7KuW1jVS7apQPK1Sre4tWkwM 3j4CXteuj7vkmrWKO3EE+nvZaXFqLDCy1FDkXFfGboqLlNPLqZn/OKbc+hkuecYN6kSI Q7SUV/eM+SGGWSwGEfvda4Lm3TI7uRWTNYHgLTdAwwiQY2hje6fN+h6vX2nqR41enOcZ MLIahROfWHKhgio4D/v5M5D1kt/d1hJpfxFeAwG1uA62Ukyr5+/hphnBc066DqeKzvyi PNjA== X-Gm-Message-State: AOAM531MeNb2psoXiwSa2rFLBeGl1Z0Kh/wXtmRyEI3ESPipg6YHrc53 zoNLSxqYGLZIi+nMtBjFAezO0bkEJMc= X-Google-Smtp-Source: ABdhPJwjBH42BpTssGXPvOVqIrCWlgQGx35HAAOuBtXQRi/ln3KbGnrTy/QWBHb9OBHD9iHoD2EUHg== X-Received: by 2002:a9d:24c3:: with SMTP id z61mr114453ota.32.1596061923112; Wed, 29 Jul 2020 15:32:03 -0700 (PDT) Received: from mmiller-44677.local ([2601:280:4f00:14a:6872:603e:2364:c516]) by smtp.gmail.com with ESMTPSA id j2sm643641ooo.6.2020.07.29.15.32.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Jul 2020 15:32:02 -0700 (PDT) To: saag@ietf.org From: "Matthew A. Miller" Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= mQENBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAG0M01hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGYraWV0ZkBvdXRlci1wbGFuZXMubmV0 PokBVAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBDHXWI3skGkNa8yY4Oz0 ck4QngW7BQJeDg4fBQkVMJSlAAoJEOz0ck4QngW7XCcH/RBVW3Nd0ezXtL9XSn5DHJxRTb5q 6ZVIBQgVIMcH2DVzO/aCs3o1ECONHAazVGQ9b6cwHCtPWJpM0ENGx7DERa/Ay4vDeKXc1TEX VuukdGrX2zWOaFHDT/oU1SEg0C+f3JGnaTwYQ7i2KXkFuYNmqROkB+Z0PDaLu4biCYdjhkIm Yu3frzySHhEX2VVMcJA6lcqdBTE3j2+ywQ7icpiWUcvLuhCeuFER1JjTRchcXwtuiOAKPQCZ BM9B70Q73hiKKK4ylNjhLFKGomkWDqsQ6sAENn6YkWyBuXNr5Y66uFxFS0VY938o/ZoXw4tb qUIdBzMnHkHxxiNUUBb6dPkaEGO5AQ0EUmgCigEIAMD+u4fBiVDul2Mljq3CRlwyZ52RA0vq vm00F5CTBWu+K1SMdMoqKmPEHaQSRRmjE+AwjWHv96cOtWUwwyqrpEgnzof7LHXfM0hk0GUl +ZUeAePtNPyylroD+ohxx2IhE2wVW+W8XGkfyxONVsd89h7Ft05HmQellZPNjE3JUtcwrmN6 fQHgr6+NuAUkC+ygt/MtnkHPeRvp2m7FQ3OqEPKGTn9Q9oIgW9lYG2JEqaSo/ASrwbZowmrl nhKvwJGSmgwHbmvEI9LxH4HKIfGmr5TyYq6o9WDUsnNwDuEeaazxoE3qXFKVvIqfMSDwBaCV 37r7GUle7lT9+oMAKVOPmZ8AEQEAAYkBPAQYAQoAJgIbDBYhBDHXWI3skGkNa8yY4Oz0ck4Q ngW7BQJeM+W5BQkPjlg/AAoJEOz0ck4QngW7a+IIANBU7R3t17LKflQo3nSUoqMBLkjxo9/e yzKAb3u0Fjb5md+9ESrFb03w1ZUkKLh/b6leTFq50IJbfxgDlVgkTn/j0XPOmIHpfDtVYPnA /rI5sqMzjb3qFOPFZFX9Til360uv9Zc5mlkJcM57X4aLRl7wSGRXPqh7v356s+JlvLF8rBtZ 7LU5SrCWeoWZu/7NvqW+UNEOOP2xAlOId4BeYWflkpzNcSPkhAkD2Xvw/GmyOm24Im7Ef2O5 scQhEO/dG+3jU4QnSGFtLXHndHpNM20vD6T+uWUpyp5g27KrIHApWq9M3o6KR68pTOLJrMxc th8xmHLOpuWVAKEABNQRDfE= Message-ID: <9d87b0cc-d6bd-cccd-f4ed-a2ead2abde04@outer-planes.net> Date: Wed, 29 Jul 2020 16:32:00 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] COSE WG @ IETF-108 Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 22:32:07 -0000 COSE met second session (13:00 - 13:50 UTC) on Wednesday, 29 July. Since IETF 106, all but one of the working group's documents had progressed to IETF Last Call: * draft-ietf-cose-hash-sig was published as RFC 8778 in April * draft-ietf-cose-webauth-algorithms entered the RFC Editors queue in June * draft-ietf-cose-x509 is awaiting AD evaluation and IETF Last Call * draft-ietf-cose-hash-algs is awaiting AD approval to pubish * draft-ietf-cose-rfc1852bis-alg is awaiting AD approval to pubish * draft-ietf-cose-rfc8152bis-struct has a technical issue to clear The WG spent just about all its meeting time at 108 on how to resolve an issue with countersignatures that came to light during the IETF Last Call. Rough consensus appears to support deprecating the current countersignature algorithm and creating a new one. The details are to be discussed on the list and in interim meetings. The COSE WG did not have time to discuss rechartering, although a presentation on the status of X509 certificate compression work did just barely finish before it could be abruptly ended. - Ivaylo and Matthew From nobody Wed Jul 29 16:34:09 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AD63A0A07 for ; Wed, 29 Jul 2020 16:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=intel.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WqR3udytyPn for ; Wed, 29 Jul 2020 16:34:05 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (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 1829C3A0A06 for ; Wed, 29 Jul 2020 16:34:04 -0700 (PDT) IronPort-SDR: 24kGsY8lFYsXdnPQ611VMd0oOtMOnK7/72HdSee0PRm+MAak5tiwHRjBFAaPBfLg5YdHFsbKWs Wku9FiCsP/Lw== X-IronPort-AV: E=McAfee;i="6000,8403,9697"; a="151494677" X-IronPort-AV: E=Sophos;i="5.75,412,1589266800"; d="txt'?scan'208,217";a="151494677" X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jul 2020 16:34:03 -0700 IronPort-SDR: JmGYHZXtApCzkOS6HLhNe5sUhIx21hw7BJ+6L8CnWMi+Cu1ug+hweaKYMT7xWiv+ib7CgY6sjH nBUYgBMveyiw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,412,1589266800"; d="txt'?scan'208,217";a="272756194" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga007.fm.intel.com with ESMTP; 29 Jul 2020 16:34:02 -0700 Received: from fmsmsx123.amr.corp.intel.com (10.18.125.38) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 29 Jul 2020 16:34:02 -0700 Received: from FMSEDG001.ED.cps.intel.com (10.1.192.133) by fmsmsx123.amr.corp.intel.com (10.18.125.38) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 29 Jul 2020 16:34:02 -0700 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.109) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 29 Jul 2020 16:34:02 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cxOJ8G/dRPaMkc+bYcnIw+bFu/5RbXYpKr+oMY/Xq+ygY32vWm6qoDA6ffTrf32tRAgKTap4Q2m2s4LeDs8zr80R8hBWEXOxXeTz4YoKFQpyALiiAfnJmDNM0olkAS3ZYcVn+T65Q9z1/T+3zcUeHtGUbo+EiWzCTQ/o8j3pPljOgaxgUZqNXRGVlScy4/WeD0tJksYRNIcOsaEGhOByO0YaHbQZlmdJegKUXqZVS8dpaMEHhjDKlYz4K+or/K9DQBuusAewL4KL23yYJQrU42f0ivTTKfaFTE8Shu1ZUzUFb7cGl54fqyhvGoXd2L2tYdkgUg1mP25sr23DyHQ0vA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pcTWB1aAPav1Pj+8p4oZxGmNSKX89xglY04AgZ/SnZ8=; b=iuHWfA7cDokzpSCX7X2B+vLCK1EHbPXrKqz5h45Qkla6TkOud0JE3Va0kWQuyHVT4xeu5TQSr0MgoG16ktYk17M2sXlxE4Epe6NHlwuru6F6nKvvpqgC1IGlrGoOkcgMFtwFJUK3jZgDAhGO4zJzJ9zxXJf2GIgGLCqe9Ljyk/lWmahlsKE2MVY+tGrwa+KGvke/aO71xSpmRDpuqofspVkXw7c+bAbAipNkfdLSaWLwt4do9+Dn2ZrZqN8hrcwRm33tRf3EXywGLhrw3pLM3ftEGo9k2wVU/IxxZAeYb5DRJc1YIXw0I+v8krFqKNUXA0CHidfF02e5FEhG25ToHQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pcTWB1aAPav1Pj+8p4oZxGmNSKX89xglY04AgZ/SnZ8=; b=mEqpgRw9N7qBXPDvs1DExitllypbFbSzjUwJ0rfNYewpPv6slY3kHZl/OYDjySa4F2PFn6MEHRlRAJmEQPTHdGs60fvq85I1LHzedgF/4A1Y2tQZD2SWIMoDpH5XzK6oIa+fg7F2yMXdAUj01qg4XJvKJv8h6KjiMUoZtCM1Xh0= Received: from MWHPR11MB1439.namprd11.prod.outlook.com (2603:10b6:301:9::20) by MW3PR11MB4556.namprd11.prod.outlook.com (2603:10b6:303:5b::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17; Wed, 29 Jul 2020 23:34:01 +0000 Received: from MWHPR11MB1439.namprd11.prod.outlook.com ([fe80::acd1:6189:65ad:9750]) by MWHPR11MB1439.namprd11.prod.outlook.com ([fe80::acd1:6189:65ad:9750%5]) with mapi id 15.20.3239.017; Wed, 29 Jul 2020 23:34:00 +0000 From: "Smith, Ned" To: "saag@ietf.org" Thread-Topic: [saag] RATs report - updated Thread-Index: AQHWZgC8C02pSBkTJEGOBMPfaxXxQg== Date: Wed, 29 Jul 2020 23:34:00 +0000 Message-ID: <567D4A8D-75AA-4794-A4F0-A930C5418ECA@intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=intel.com; x-originating-ip: [50.53.43.22] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4bc1f7da-aeab-4be9-e45e-08d83417df49 x-ms-traffictypediagnostic: MW3PR11MB4556: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ynAZ63Jar8iIFZmeqZRl0UMTKzuvBjbZi+L8okIA1onP7VE71hS/5EuBg3u9AyfRiBGFlTpnlWX5Bd78VHWk3BqXOba7cHu+zxujctSshFdGucN77sjR23mn/Yiv8pitlNnONhOjNsna0VeNqTgKAtR3A2ACA9KrCB3x4z1DIv4nr23UGAXJ5cOC81FKH5f6iqtLSKat1qIu3Ji804eDN0Yu/vSLJ9GLapaXMaFgocg74JuzSU7ImEktmHhxOsoTMnu6jJhuRQP38rh+LJkTYQiDZv5yUsGKoj8mCnQbDJAkWRxIbGqAj1/fP5dZuwDwEI6Rt9MGIsvTOR2R9Ye5qgUH0l4G7m1QUimrLEsqNFx86w8uR2zsUy963PPICHrYGcjlR6WCenmjMdr2aoiNKA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1439.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(346002)(136003)(376002)(39860400002)(396003)(66616009)(66556008)(66476007)(66946007)(966005)(6506007)(64756008)(186003)(478600001)(91956017)(2906002)(8676002)(66446008)(2616005)(8936002)(5660300002)(26005)(76116006)(71200400001)(36756003)(6512007)(33656002)(83380400001)(166002)(316002)(6916009)(6486002)(86362001)(99936003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: fswOGn86M5c2Q1rBHo2JXaMfWM6iAEsfCI9snIUXYgLhnjn1HNDpxVuvT4GVVmXvukI7akW59Z+ESxXCgkzPr/wb4epeHXWKhn3JC9fDvjB+fhvY77+sgjupaHaXL7C2/9WXjjQzHEozpGTFai6yj4yGdtjJ4Umu3ILN+CiNVIH9O4QD2fShyv4v62TUv+Lt7FThFNE9zT0eO9ol9BbTBJGKSmwki+rmLlOBGAi6JWaWx4Erpxb/QB4OlaOulSpYgIAKaESvzfV+vUuUkmxO2q/FCIVZSDRmC6jtk2Xhj+dM3IJZUKKAerbK9JEqA0/NoG5TFhtQOKglIeo/rFo+dxkSE46FltZx6USrbYVRqcAfEZqhlHiXNMrDDToyUyrasLnRb4hsGptTStmjp/jG6a6VlCQIZeVxuCRNw9GnYAdfU5otL3bcZQ/dndNE1TGg6Eou7z6NsXvO3XoQLbhCbxtoftLiRKj9K6ihi4CBufMxFn92DiSE2hkHrEt2gyoZJo8b3KXDhIWnYQIMBLfV5DVCWZyxq+q4U6mrIvVU985Ff7+UXgpv8KrYEk+eIvAGlJw8MkdML8VMa77Gm6hvYz7kiUKvPJYLZ4Rp9clhpVNHtWwWAqo+XTr1zFgiQ/VIvNtmkgJBTJ6WpL9pXwurFw== x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_004_567D4A8D75AA4794A4F0A930C5418ECAintelcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1439.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4bc1f7da-aeab-4be9-e45e-08d83417df49 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2020 23:34:00.6019 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: V+E1nR5G9b/XNWwV+98HAV7hChDaKc5v9l5r68Tw/dtfJFe4HWvzZn/AoIJjNn4aaTk94sARZBQIgdDw/hxGnw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4556 X-OriginatorOrg: intel.com Archived-At: Subject: [saag] FW: RATs report - updated X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 23:34:08 -0000 --_004_567D4A8D75AA4794A4F0A930C5418ECAintelcom_ Content-Type: multipart/alternative; boundary="_000_567D4A8D75AA4794A4F0A930C5418ECAintelcom_" --_000_567D4A8D75AA4794A4F0A930C5418ECAintelcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UkFUcyBtZXQgdGhpcyB3ZWVrIG9uIFR1ZXNkYXkgSnVseSAyOCAxMzowMC0xMzo1MCBVVEMgYW5k IFdlZG5lc2RheSBKdWx5IDI5IDExOjAwLTEyOjQwIFVUQw0KV2UgZGlzY3Vzc2VkIHRoZSBmb2xs b3dpbmcgZHJhZnRzOg0KDQogICAgICogICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLXJhdHMtdHBtLWJhc2VkLW5ldHdvcmstZGV2aWNlLWF0dGVzdC8NCg0KICAq ICAgVGhpcyBJLUQgaXMgbmVhcmluZyBjb21wbGV0aW9uLCBidXQgbmVlZHMgYWRkaXRpb25hbCBl eWViYWxscyB0byByZXZpZXcgLyBjb21tZW50LiBUaHJlZSAoYmVzaWRlcyB0aGUgYXV0aG9ycyBh bmQgY2hhaXJzKSBoYXZlIHJlYWQgaXQgYW5kIDYtNyBtb3JlIHZvbHVudGVlcmVkIHRvIHJldmll dyBpdC4NCiAgKiAgIFRoaXMgSS1EIGJlbG9uZ3MgdG8gYSBjb2xsZWN0aW9uIG9mIEktRHMgaGF2 aW5nIHRvIGRvIHdpdGggVFBNIGNlbnRyaWMgYXR0ZXN0YXRpb24uDQogICogICBUaGUgY2hhaXJz IGJlbGlldmUgV0dMQyB3aWxsIGhhcHBlbiBzb29uLg0KDQogICAgICogICBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJhdHMteWFuZy10cG0tY2hhcnJhLw0KDQog ICogICBUaGlzIEktRCBjaGFuZ2VkIG5hbWVzIHNsaWdodGx5IHRvIGZvY3VzIG9uIGNoYWxsZW5n ZS1yZXNwb25zZS1iYXNlZCByZW1vdGUgYXR0ZXN0YXRpb24gKENIQVJSQSkNCiAgKiAgIFRoZSBh dXRob3JzIGhpZ2hsaWdodGVkIHR3byBpc3N1ZXMgKDEpIFNob3VsZCBhbGdvcml0aG0gc3VwcG9y dCBiZSByZXN0cmljdGVkIHRvIHRob3NlIHN1cHBvcnRlZCBieSBUUE0xLjIgYW5kIFRQTTIuMCBv ciBzaG91bGQgSUVURiBzdXBwb3J0ZWQgYWxnb3JpdGhtcz8gQXV0aG9ycyBsb29raW5nIGZvciBy ZXNwb25zZXMgb24gZW1haWwgbGlzdC4gKDIpIElzIHRoZXJlIGEgbmVlZCBmb3IgYSBuZXcgbG9n IHR5cGUgYXMgVFBNcyB1c2UgUENSIHByb2ZpbGVzIHRoYXQgaW5mbHVlbmNlcyBob3cgbG9nIGVu dHJpZXMgYXJlIGNyZWF0ZWQuDQogICogICBUaGlzIEktRCBiZWxvbmdzIHRvIGEgY29sbGVjdGlv biBvZiBJLURzIGhhdmluZyB0byBkbyB3aXRoIFRQTSBjZW50cmljIGF0dGVzdGF0aW9uLg0KDQog ICAgICogICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iaXJraG9sei1y YXRzLW5ldHdvcmstZGV2aWNlLXN1YnNjcmlwdGlvbi8NCg0KICAqICAgSS1EIGF1dGhvcnMgYXJl IGxvb2tpbmcgZm9yIGZlZWRiYWNrIG9uIHJlYWRpbmVzcyBmb3IgYWRvcHRpb24uIFBsZWFzZSBj b250cmlidXRlIHRvIGxpc3QgZGlzY3Vzc2lvbiB0byB3ZWlnaCBpbi4NCg0KICAgICAqICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmlya2hvbHotcmF0cy1yZWZlcmVu Y2UtaW50ZXJhY3Rpb24tbW9kZWwvDQoNCiAgKiAgIFRoaXMgSS1EIGNvbnRhaW5zIHNldmVyYWwg aW50ZXJhY3Rpb24gbW9kZWxzIGFuZCBpdCBpc27igJl0IGNsZWFyIGhvdyB0aGUgV0cgbWVtYmVy cyB3YW50IHRvIG1vdmUgaXQgZm9yd2FyZC4gT3B0aW9ucyBhcmUgKGEpIHN0YW5kLWFsb25lOyBz ZXBhcmF0ZSBJLURzIGZvciBlYWNoIG1vZGVsLCAoYikgc3RhbmQtYWxvbmU7IGFsbCBtb2RlbHMg aW4gb25lIGRyYWZ0LCAoYykgbW92ZSBpbnRvIFJBVFMgYXJjaGl0ZWN0dXJlIGRyYWZ0LCAoZCkg ZWFjaCBtb2RlbCBmaW5kcyBhIHNvbHV0aW9uIEktRC4NCiAgKiAgIFRoZSBsaXN0IGZlZWRiYWNr IGFuZCBmZWVkYmFjayBpbiB0aGUgcm9vbSBvcHBvc2VzIG9wdGlvbiAoYykgYW5kIHNvbWUgaW50 ZXJlc3QgaW4gKGIpLg0KICAqICAgTW9zdGx5IG5vdCByZWFkeSBmb3IgY2FsbCBmb3IgYWRvcHRp b24uDQoNCiAgICAgKiAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtcmF0cy1hcmNoaXRlY3R1cmUvDQoNCiAgKiAgIE11Y2ggcHJvZ3Jlc3MgaGFzIGJlZW4gbWFk ZSBkaXNwb3NpdGlvbmluZyBpc3N1ZXMsIHRob3VnaCBhIGZldyBzdGlsbCByZW1haW4uIFRoZXNl IGhhdmUgbW9zdGx5IHRvIGRvIHdpdGggY2xhcmlmeWluZyBFbmRvcnNlci9FbmRvcnNlbWVudCBy b2xlIGFuZCBmbG93LiBTb21lIHRoaW5rIGl0IHdvdWxkIGJlIE9LIGZvciB0aGUgYXJjaGl0ZWN0 dXJlIHRvIG1pbmltYWxseSBleHBsYWluIHRoZXNlIGFuZCB3YWl0IGZvciB0aGUgUkFUUyBjaGFy dGVyIHRvIG1vcmUgZGlyZWN0bHkgdGFyZ2V0IHRoaXMgYXJlYSBub3cuIFRoZSBvdGhlciBhcmVh IGhhcyB0byBkbyB3aXRoIGZyZXNobmVzcyBhbmQgdGltaW5nIG9mIHdoZW4gcmVsZXZhbnQgZXZl bnQgb2NjdXIgaW50ZXJuYWxseS4NCiAgKiAgIEFuIElQUiBjb25jZXJuIHdhcyByYWlzZWQgcmVn YXJkaW5nIGNvbXBvc2l0ZSBkZXZpY2Ugc2VjdGlvbiBpbiB0aGUgYXJjaGl0ZWN0dXJlLiBDaGFp cnMgYXNrZWQgdG8gaGF2ZSB0aGUgSVBSIGNvbnNpZGVyYXRpb25zIGNsYXJpZmllZCBpbiB0aGUg SVBSIHJlY29yZC4NCiAgKiAgIFRoZSBmZWVsaW5nIGlzIHRoaXMgSS1EIGlzIGNsb3NlIHRvIFdH TEMuDQoNCiAgICAgKiAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtcmF0cy1lYXQvDQoNCiAgKiAgIERpc2N1c3Npb24gcmVsYXRlZCB0byBFbmRvcnNlci9FbmRv cnNlbWVudCBmbG93IGNvbnRpbnVlZCBhcyBpdCBwZXJ0YWlucyB0byBFQVQuIFNvbWUgY29uY2Vy biB0aGF0IGRlcGVuZGluZyBvbiBob3cgdGhlIGFyY2hpdGVjdHVyZSBkcmFmdCBhZGRyZXNzZXMg dGhpcyB0b3BpYyB3aWxsIGFmZmVjdCB0aGUgRUFUIEktRCBjb250ZW50cy4NCiAgKiAgIEEgc2lk ZSBtZWV0aW5nIHdpbGwgYmUgaGVsZCB0byBhZGRyZXNzIHJlbGF0ZWQgdG9waWNzLg0KICAqICAg VGhlIGF1dGhvcnMgYXJlIG5vdCByZWNvbW1lbmRpbmcgdGhpcyBJLUQgaXMgcmVhZHkgZm9yIFdH TEMuDQoNCiAgICAgKiAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZv aXQtcmF0cy10cnVzdHdvcnRoeS1wYXRoLXJvdXRpbmcvDQoNCiAgKiAgIFRoaXMgSS1EIGJlbG9u Z3MgdG8gYSBjb2xsZWN0aW9uIG9mIEktRHMgaGF2aW5nIHRvIGRvIHdpdGggVFBNIGNlbnRyaWMg YXR0ZXN0YXRpb24uDQogICogICBJLUQgaW5jb3Jwb3JhdGVzIOKAmHRydXN0IGxldmVsc+KAmSBh cyBhIHdheSB0byBidWNrZXQgYXR0ZXN0YXRpb24gcmVzdWx0cyBmb3IgYWxsIHBhcnRpY2lwYXRp bmcgcm91dGVycy4gVGhlcmUgd2FzbuKAmXQgY29uc2Vuc3VzIHRoYXQgdHJ1c3QgbGV2ZWxzIHdv dWxkIGJlIG1lYW5pbmdmdWwgb3V0c2lkZSB0aGUgY29udGV4dCBvZiB0cnVzdGVkIHBhdGggcm91 dGluZy4NCiAgKiAgIFRoZSBhdXRob3JzIGFyZSBpbnRlcmVzdGVkIGlmIHRoZSBXRyBtZW1iZXJz IGFyZSBpbnRlcmVzdGVkIGluIFRQUiBhbmQgaWYgdGhlIFdHIHdvdWxkIHByb2NlZWQgd2l0aCBh ZG9wdGlvbi4NCg0KICAgICAqICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtYmlya2hvbHotcmF0cy1zdWl0LWNsYWltcy8NCg0KICAqICAgSS1EIGludHJvZHVjZXMgaWRl YSBvZiDigJh0cnVzdHdvcnRoaW5lc3MgdmVjdG9yc+KAmSBhIGNvbmNlcHQgc2ltaWxhciB0byDi gJh0cnVzdCBsZXZlbHPigJkgaW4gVFBSIEktRC4gVXNlIHdpdGggU1VJVCBtYW5pZmVzdHMgYW5k IFRFRVAgaXMgdGhlIGV4cGVjdGVkIGNvbnRleHQuIFRoZSBJLUQgaGFzIFJlbHlpbmcgUGFydHkg YXBwbGljYWJpbGl0eSAobW9zdGx5KS4NCiAgKiAgIFRoZSBhdXRob3JzIGFyZSB3b25kZXJpbmcg aWYgdGhlcmUgaXMgV0cgaW50ZXJlc3QuDQoNCiAgICAgKiAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWJpcmtob2x6LXJhdHMtdWNjcy8NCg0KICAqICAgSS1EIGhhc27i gJl0IGNoYW5nZWQgbXVjaCBzaW5jZSB0aGUgbGFzdCBXRyBtZWV0aW5nLiBBdXRob3JzIGFyZSBz b2xpY2l0aW5nIHJldmlldyAvIGZlZWRiYWNrLg0KICAqICAgQ2hhaXJzIGFza2VkIGhvdyBtYW55 IGhhdmUgcmVhZCBpdCAoNSBwZW9wbGUpIGFuZCBob3cgbWFueSB3b3VsZCByZWFkIGl0ICgyIHBl b3BsZSkgYW5kIGlmIHRoZSBXRyB0aG91Z2h0IGl0IHdhcyByZWFkeSBmb3IgYWRvcHRpb24uIEFw cGFyZW50IGNvbnNlbnN1cyB3YXMgWWVzLg0KDQogICAgICogICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1zaGF3LXJhdHMtcmVhci8NCg0KICAqICAgSS1EIGZvY3VzZXMg b24gYnVpbGRpbmcgYSB0b29sYm94IGZvciBSRVNUZnVsIGludGVyYWN0aW9ucyB0aGF0IGluY29y cG9yYXRlcyBhdHRlc3RhdGlvbi4NCiAgKiAgIEF1dGhvcnMgc29saWNpdGluZyBpbnRlcmVzdCBh bmQgc2hvdWxkIHRoaXMgd29yayBtb3ZlIGZvcndhcmQuDQogICogICBDaGFpcnMgcmVxdWVzdGVk IHRoZSBkaXNjdXNzaW9uIG1vdmUgdG8gdGhlIFdHIGVtYWlsIGxpc3QuDQoNCldlIGFsc28gZGlz Y3Vzc2VkIHVwZGF0aW5nIHRoZSBtaWxlc3RvbmVzIGFuZCBjaGVja2luZyBXR0xDIHJlYWRpbmVz cyBvZiB0aGUgYXJjaGl0ZWN0dXJlIGRyYWZ0Lg0KDQogICogICDigJxDaGFycmHigJ0g4oCTIFRh cmdldGluZyBTZXB0ZW1iZXIgZm9yIFdHTEMgLyBNYXJjaCBmb3IgcHVibGljYXRpb24NCiAgKiAg IOKAnEludGVyYWN0aW9uIE1vZGVsc+KAnSDigJMgQ2FsbCBmb3IgYWRvcHRpb24gbmVlZGVkLCBw ZW5kaW5nIGFkZXF1YXRlIHJldmlld2VyIGZlZWRiYWNrDQogICogICDigJxUb2tlbiBiaW5k4oCd IOKAkyB0byBiZSByZW1vdmVkDQogICogICDigJxFQVTigJ0g4oCTIFdHTEMgY2FuIGJlIHBsYW5u ZWQgb25jZSB0aGUgaXNzdWUgd2l0aCBFbmRvcnNlbWVudC9FbmRvcnNlciBkZXNjcmlwdGlvbnMg aW4gdGhlIGFyY2hpdGVjdHVyZSBJLUQgY2FuIGJlIGNsYXJpZmllZC4gVGFyZ2V0aW5nIElFU0cg c3VibWlzc2lvbiBpbiA2IG1vbnRocy4NCiAgKiAgIOKAnFRVREHigJ0g4oCTIE5vIHJlY2VudCBk aXNjdXNzaW9uIG9uIHRoaXMuIEF1dGhvcnMgYXNzZXJ0IHRoYXQgb3RoZXIgSS1EcyBzaG91bGQg Z28gYWhlYWQgc2luY2UgdGhlcmUgYXJlIGRlcGVuZGVuY2llcyBvbiBvdGhlciBJLURzLiBBdXRo b3JzIGZlbHQgdGhleSBkaWRu4oCZdCBoYXZlIGJhbmR3aWR0aCB0byBtb3ZlIGFoZWFkIHJpZ2h0 IG5vdy4NCiAgKiAgIOKAnFJJVuKAnSDigJMgV0dMQyBjYW4gYmUgY29uc2lkZXJlZCBhdCB0aGUg ZW5kIG9mIEF1Z3VzdC4NCg0KDQo= --_000_567D4A8D75AA4794A4F0A930C5418ECAintelcom_ Content-Type: text/html; charset="utf-8" Content-ID: <383AB82FBC4BE946ACDF86695D1AF0DE@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiBcKEJvZHkgQ1NcKSI7DQoJcGFub3NlLTE6MiAxMSA2IDQg MiAyIDIgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQ YXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsN CgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGlu Ow0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOndp bmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRl eHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0 aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NTk0NTU4MzczOw0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo0OTM5MTc5NTYgLTE2NzAwODY0MDgg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo1 Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCW1hcmdpbi1sZWZ0Oi43NWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpTeW1ib2w7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlk aS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIFwoQm9keSBDU1wpIjt9DQpAbGlzdCBsMDps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEuMjVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxl ZnQ6MS43NWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIuMjVpbjsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFy Z2luLWxlZnQ6Mi43NWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozLjI1aW47DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6My43NWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo0LjI1 aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjQuNzVpbjsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlk OjExMjUxOTc0Njc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOjE3OTgxODY4MTAgLTE3MDgzOTA0MDAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2 ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo1Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjY3LjVwdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sOw0KCW1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biBcKEJvZHkgQ1NcKSI7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxMDMuNXB0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxMzkuNXB0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1h cmdpbi1sZWZ0OjE3NS41cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIxMS41cHQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjI0Ny41cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6 MjgzLjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MzE5LjVwdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ bWFyZ2luLWxlZnQ6MzU1LjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjEzNTI4Nzc4Nzg7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjgzMDc5MTM3MDt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwy OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzDQoJe21zby1saXN0 LWlkOjE2MDUwNzQxODM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi0xMjM2MjE5MzEyIDU1MjY1ODI1NiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMzps ZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjU7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEuMjVpbjsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFy ZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMzpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CW1hcmdpbi1sZWZ0OjEuNzVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6Mi4yNWlu Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIuNzVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6 My4yNWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozLjc1aW47DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJbWFyZ2luLWxlZnQ6NC4yNWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo0Ljc1aW47DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDM6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjUuMjVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0DQoJe21zby1saXN0LWlkOjIwODgxNDA3 OTA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMjMy MDUzODIyIC0yMTk5NjE0OCAxNDQ2NjYwMjc2IC0xNDY0MzMyMDU0IDE2NzUzOTI2MzAgNzE3MjU5 MDYwIDEzMjkwOTc0NjggLTQ4NTMxMjA5NiAtMTQ4NjQ2MjMxMCAzODQwNzA3MjA7fQ0KQGxpc3Qg bDQ6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrigKI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQXJpYWwi LHNhbnMtc2VyaWY7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0K QGxpc3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrigKI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkFyaWFsIixzYW5zLXNlcmlmOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iO30NCkBsaXN0IGw0OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ64oCiOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJBcmlhbCIsc2Fucy1zZXJpZjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjt9DQpAbGlzdCBsNDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OuKAojsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrigKI7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkFyaWFsIixzYW5zLXNlcmlmOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGw0OmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ64oCiOw0KCW1zby1sZXZlbC10 YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsc2Fucy1zZXJpZjsNCgltc28tYmlk aS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsNDpsZXZlbDcNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0OuKAojsNCgltc28t bGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDQ6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrigKI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkFyaWFsIixzYW5zLXNl cmlmOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGw0 OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ64oCiOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIs c2Fucy1zZXJpZjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48 L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5r PSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UkFUcyBtZXQgdGhpcyB3ZWVrIG9u IFR1ZXNkYXkgSnVseSAyOCAxMzowMC0xMzo1MCBVVEMgYW5kIFdlZG5lc2RheSBKdWx5IDI5IDEx OjAwLTEyOjQwIFVUQzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5XZSBkaXNjdXNzZWQgdGhlIGZvbGxvd2lu ZyBkcmFmdHM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBp biIgdHlwZT0iZGlzYyI+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4N CjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDQgbGV2ZWwyIGxmbzMiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJhdHMtdHBtLWJhc2VkLW5ldHdvcmstZGV2aWNlLWF0 dGVzdC8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcmF0cy10 cG0tYmFzZWQtbmV0d29yay1kZXZpY2UtYXR0ZXN0LzwvYT48L3NwYW4+PG86cD48L286cD48L2xp PjwvdWw+DQo8L3VsPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8 bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDouNzVpbjttc28t bGlzdDpsMyBsZXZlbDEgbGZvNCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoaXMgSS1EIGlzIG5lYXJpbmcgY29tcGxl dGlvbiwgYnV0IG5lZWRzIGFkZGl0aW9uYWwgZXllYmFsbHMgdG8gcmV2aWV3IC8gY29tbWVudC4g VGhyZWUgKGJlc2lkZXMgdGhlIGF1dGhvcnMgYW5kIGNoYWlycykNCiBoYXZlIHJlYWQgaXQgYW5k IDYtNyBtb3JlIHZvbHVudGVlcmVkIHRvIHJldmlldyBpdC4gPG86cD48L286cD48L3NwYW4+PC9s aT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDouNzVpbjtt c28tbGlzdDpsMyBsZXZlbDEgbGZvNCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoaXMgSS1EIGJlbG9uZ3MgdG8gYSBj b2xsZWN0aW9uIG9mIEktRHMgaGF2aW5nIHRvIGRvIHdpdGggVFBNIGNlbnRyaWMgYXR0ZXN0YXRp b24uPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNzVpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZvNCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PlRoZSBjaGFpcnMgYmVsaWV2ZSBXR0xDIHdpbGwgaGFwcGVuIHNvb24uPG86cD48L286cD48L3Nw YW4+PC9saT48L3VsPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8 dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDQgbGV2ZWwyIGxmbzMiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLXJhdHMteWFuZy10cG0tY2hhcnJhLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1yYXRzLXlhbmctdHBtLWNoYXJyYS88L2E+PC9zcGFuPjxvOnA+PC9v OnA+PC9saT48L3VsPg0KPC91bD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRp c2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Ljc1 aW47bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGlzIEktRCBjaGFuZ2VkIG5h bWVzIHNsaWdodGx5IHRvIGZvY3VzIG9uIGNoYWxsZW5nZS1yZXNwb25zZS1iYXNlZCByZW1vdGUg YXR0ZXN0YXRpb24gKENIQVJSQSk8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi43NWluO21zby1saXN0OmwzIGxldmVs MSBsZm80Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+VGhlIGF1dGhvcnMgaGlnaGxpZ2h0ZWQgdHdvIGlzc3VlcyAoMSkg U2hvdWxkIGFsZ29yaXRobSBzdXBwb3J0IGJlIHJlc3RyaWN0ZWQgdG8gdGhvc2Ugc3VwcG9ydGVk IGJ5IFRQTTEuMiBhbmQgVFBNMi4wIG9yDQogc2hvdWxkIElFVEYgc3VwcG9ydGVkIGFsZ29yaXRo bXM/IEF1dGhvcnMgbG9va2luZyBmb3IgcmVzcG9uc2VzIG9uIGVtYWlsIGxpc3QuICgyKSBJcyB0 aGVyZSBhIG5lZWQgZm9yIGEgbmV3IGxvZyB0eXBlIGFzIFRQTXMgdXNlIFBDUiBwcm9maWxlcyB0 aGF0IGluZmx1ZW5jZXMgaG93IGxvZyBlbnRyaWVzIGFyZSBjcmVhdGVkLg0KPG86cD48L286cD48 L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDouNzVpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZvNCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoaXMgSS1EIGJlbG9u Z3MgdG8gYSBjb2xsZWN0aW9uIG9mIEktRHMgaGF2aW5nIHRvIGRvIHdpdGggVFBNIGNlbnRyaWMg YXR0ZXN0YXRpb24uPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHVsIHN0eWxlPSJtYXJn aW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBl PSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDQgbGV2ZWwy IGxmbzMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1iaXJraG9sei1yYXRzLW5ldHdvcmstZGV2aWNl LXN1YnNjcmlwdGlvbi8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJp cmtob2x6LXJhdHMtbmV0d29yay1kZXZpY2Utc3Vic2NyaXB0aW9uLzwvYT48L3NwYW4+PG86cD48 L286cD48L2xpPjwvdWw+DQo8L3VsPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0i ZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDou NzVpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZvNCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkktRCBhdXRob3JzIGFyZSBs b29raW5nIGZvciBmZWVkYmFjayBvbiByZWFkaW5lc3MgZm9yIGFkb3B0aW9uLiBQbGVhc2UgY29u dHJpYnV0ZSB0byBsaXN0IGRpc2N1c3Npb24gdG8gd2VpZ2ggaW4uPG86cD48L286cD48L3NwYW4+ PC9saT48L3VsPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8dWwg c3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLWxpc3Q6bDQgbGV2ZWwyIGxmbzMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1i aXJraG9sei1yYXRzLXJlZmVyZW5jZS1pbnRlcmFjdGlvbi1tb2RlbC8iPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJpcmtob2x6LXJhdHMtcmVmZXJlbmNlLWludGVyYWN0 aW9uLW1vZGVsLzwvYT48L3NwYW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8L3VsPg0KPHVsIHN0 eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDouNzVpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZvNCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPlRoaXMgSS1EIGNvbnRhaW5zIHNldmVyYWwgaW50ZXJhY3Rpb24gbW9kZWxzIGFu ZCBpdCBpc27igJl0IGNsZWFyIGhvdyB0aGUgV0cgbWVtYmVycyB3YW50IHRvIG1vdmUgaXQgZm9y d2FyZC4gT3B0aW9ucyBhcmUgKGEpDQogc3RhbmQtYWxvbmU7IHNlcGFyYXRlIEktRHMgZm9yIGVh Y2ggbW9kZWwsIChiKSBzdGFuZC1hbG9uZTsgYWxsIG1vZGVscyBpbiBvbmUgZHJhZnQsIChjKSBt b3ZlIGludG8gUkFUUyBhcmNoaXRlY3R1cmUgZHJhZnQsIChkKSBlYWNoIG1vZGVsIGZpbmRzIGEg c29sdXRpb24gSS1ELg0KPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDouNzVpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZv NCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPlRoZSBsaXN0IGZlZWRiYWNrIGFuZCBmZWVkYmFjayBpbiB0aGUgcm9vbSBv cHBvc2VzIG9wdGlvbiAoYykgYW5kIHNvbWUgaW50ZXJlc3QgaW4gKGIpLjxvOnA+PC9vOnA+PC9z cGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 Ljc1aW47bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Nb3N0bHkgbm90IHJlYWR5 IGZvciBjYWxsIGZvciBhZG9wdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8dWwg c3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRv cDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlz dDpsNCBsZXZlbDIgbGZvMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcmF0cy1hcmNoaXRl Y3R1cmUvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJhdHMt YXJjaGl0ZWN0dXJlLzwvYT48L3NwYW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8L3VsPg0KPHVs IHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDouNzVpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZv NCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPk11Y2ggcHJvZ3Jlc3MgaGFzIGJlZW4gbWFkZSBkaXNwb3NpdGlvbmluZyBp c3N1ZXMsIHRob3VnaCBhIGZldyBzdGlsbCByZW1haW4uIFRoZXNlIGhhdmUgbW9zdGx5IHRvIGRv IHdpdGggY2xhcmlmeWluZyBFbmRvcnNlci9FbmRvcnNlbWVudA0KIHJvbGUgYW5kIGZsb3cuIFNv bWUgdGhpbmsgaXQgd291bGQgYmUgT0sgZm9yIHRoZSBhcmNoaXRlY3R1cmUgdG8gbWluaW1hbGx5 IGV4cGxhaW4gdGhlc2UgYW5kIHdhaXQgZm9yIHRoZSBSQVRTIGNoYXJ0ZXIgdG8gbW9yZSBkaXJl Y3RseSB0YXJnZXQgdGhpcyBhcmVhIG5vdy4gVGhlIG90aGVyIGFyZWEgaGFzIHRvIGRvIHdpdGgg ZnJlc2huZXNzIGFuZCB0aW1pbmcgb2Ygd2hlbiByZWxldmFudCBldmVudCBvY2N1ciBpbnRlcm5h bGx5Lg0KPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDouNzVpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZvNCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPkFuIElQUiBjb25jZXJuIHdhcyByYWlzZWQgcmVnYXJkaW5nIGNvbXBvc2l0ZSBkZXZpY2Ug c2VjdGlvbiBpbiB0aGUgYXJjaGl0ZWN0dXJlLiBDaGFpcnMgYXNrZWQgdG8gaGF2ZSB0aGUgSVBS IGNvbnNpZGVyYXRpb25zDQogY2xhcmlmaWVkIGluIHRoZSBJUFIgcmVjb3JkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6Ljc1aW47bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5UaGUgZmVlbGluZyBp cyB0aGlzIEktRCBpcyBjbG9zZSB0byBXR0xDLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4N Cjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPHVsIHN0eWxlPSJtYXJn aW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1saXN0Omw0IGxldmVsMiBsZm8zIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1yYXRzLWVh dC8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcmF0cy1lYXQv PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvdWw+DQo8dWwgc3R5bGU9Im1hcmdp bi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi43NWluO21zby1saXN0OmwzIGxldmVsMSBsZm80Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ RGlzY3Vzc2lvbiByZWxhdGVkIHRvIEVuZG9yc2VyL0VuZG9yc2VtZW50IGZsb3cgY29udGludWVk IGFzIGl0IHBlcnRhaW5zIHRvIEVBVC4gU29tZSBjb25jZXJuIHRoYXQgZGVwZW5kaW5nIG9uIGhv dyB0aGUgYXJjaGl0ZWN0dXJlDQogZHJhZnQgYWRkcmVzc2VzIHRoaXMgdG9waWMgd2lsbCBhZmZl Y3QgdGhlIEVBVCBJLUQgY29udGVudHMuPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDouNzVpbjttc28tbGlzdDpsMyBs ZXZlbDEgbGZvNCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPkEgc2lkZSBtZWV0aW5nIHdpbGwgYmUgaGVsZCB0byBhZGRy ZXNzIHJlbGF0ZWQgdG9waWNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Ljc1aW47bXNvLWxpc3Q6bDMgbGV2ZWwx IGxmbzQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5UaGUgYXV0aG9ycyBhcmUgbm90IHJlY29tbWVuZGluZyB0aGlzIEkt RCBpcyByZWFkeSBmb3IgV0dMQy48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8dWwgc3R5 bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDow aW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDps NCBsZXZlbDIgbGZvMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXZvaXQtcmF0cy10cnVzdHdvcnRo eS1wYXRoLXJvdXRpbmcvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12 b2l0LXJhdHMtdHJ1c3R3b3J0aHktcGF0aC1yb3V0aW5nLzwvYT48L3NwYW4+PG86cD48L286cD48 L2xpPjwvdWw+DQo8L3VsPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+ DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDouNzVpbjtt c28tbGlzdDpsMyBsZXZlbDEgbGZvNCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoaXMgSS1EIGJlbG9uZ3MgdG8gYSBj b2xsZWN0aW9uIG9mIEktRHMgaGF2aW5nIHRvIGRvIHdpdGggVFBNIGNlbnRyaWMgYXR0ZXN0YXRp b24uPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNzVpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZvNCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PkktRCBpbmNvcnBvcmF0ZXMg4oCYdHJ1c3QgbGV2ZWxz4oCZIGFzIGEgd2F5IHRvIGJ1Y2tldCBh dHRlc3RhdGlvbiByZXN1bHRzIGZvciBhbGwgcGFydGljaXBhdGluZyByb3V0ZXJzLiBUaGVyZSB3 YXNu4oCZdCBjb25zZW5zdXMNCiB0aGF0IHRydXN0IGxldmVscyB3b3VsZCBiZSBtZWFuaW5nZnVs IG91dHNpZGUgdGhlIGNvbnRleHQgb2YgdHJ1c3RlZCBwYXRoIHJvdXRpbmcuPG86cD48L286cD48 L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDouNzVpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZvNCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoZSBhdXRob3JzIGFy ZSBpbnRlcmVzdGVkIGlmIHRoZSBXRyBtZW1iZXJzIGFyZSBpbnRlcmVzdGVkIGluIFRQUiBhbmQg aWYgdGhlIFdHIHdvdWxkIHByb2NlZWQgd2l0aCBhZG9wdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48 L2xpPjwvdWw+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjx1bCBz dHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbGlzdDpsNCBsZXZlbDIgbGZvMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJp cmtob2x6LXJhdHMtc3VpdC1jbGFpbXMvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1iaXJraG9sei1yYXRzLXN1aXQtY2xhaW1zLzwvYT48L3NwYW4+PG86cD48L286cD48 L2xpPjwvdWw+DQo8L3VsPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+ DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDouNzVpbjtt c28tbGlzdDpsMyBsZXZlbDEgbGZvNCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkktRCBpbnRyb2R1Y2VzIGlkZWEgb2Yg 4oCYdHJ1c3R3b3J0aGluZXNzIHZlY3RvcnPigJkgYSBjb25jZXB0IHNpbWlsYXIgdG8g4oCYdHJ1 c3QgbGV2ZWxz4oCZIGluIFRQUiBJLUQuIFVzZSB3aXRoIFNVSVQgbWFuaWZlc3RzDQogYW5kIFRF RVAgaXMgdGhlIGV4cGVjdGVkIGNvbnRleHQuIFRoZSBJLUQgaGFzIFJlbHlpbmcgUGFydHkgYXBw bGljYWJpbGl0eSAobW9zdGx5KS48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi43NWluO21zby1saXN0OmwzIGxldmVs MSBsZm80Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+VGhlIGF1dGhvcnMgYXJlIHdvbmRlcmluZyBpZiB0aGVyZSBpcyBX RyBpbnRlcmVzdC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8dWwgc3R5bGU9Im1hcmdp bi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9 ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsNCBsZXZlbDIg bGZvMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJpcmtob2x6LXJhdHMtdWNjcy8iPmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJpcmtob2x6LXJhdHMtdWNjcy88L2E+PC9z cGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC91bD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDow aW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6Ljc1aW47bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JLUQgaGFz buKAmXQgY2hhbmdlZCBtdWNoIHNpbmNlIHRoZSBsYXN0IFdHIG1lZXRpbmcuIEF1dGhvcnMgYXJl IHNvbGljaXRpbmcgcmV2aWV3IC8gZmVlZGJhY2suPG86cD48L286cD48L3NwYW4+PC9saT48bGkg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDouNzVpbjttc28tbGlz dDpsMyBsZXZlbDEgbGZvNCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkNoYWlycyBhc2tlZCBob3cgbWFueSBoYXZlIHJl YWQgaXQgKDUgcGVvcGxlKSBhbmQgaG93IG1hbnkgd291bGQgcmVhZCBpdCAoMiBwZW9wbGUpIGFu ZCBpZiB0aGUgV0cgdGhvdWdodCBpdCB3YXMgcmVhZHkgZm9yDQogYWRvcHRpb24uIEFwcGFyZW50 IGNvbnNlbnN1cyB3YXMgWWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjx1bCBzdHls ZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBp biIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0Omw0 IGxldmVsMiBsZm8zIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2hhdy1yYXRzLXJlYXIvIj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zaGF3LXJhdHMtcmVhci88L2E+PC9z cGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC91bD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDow aW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6Ljc1aW47bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JLUQgZm9j dXNlcyBvbiBidWlsZGluZyBhIHRvb2xib3ggZm9yIFJFU1RmdWwgaW50ZXJhY3Rpb25zIHRoYXQg aW5jb3Jwb3JhdGVzIGF0dGVzdGF0aW9uLg0KPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDouNzVpbjttc28tbGlzdDps MyBsZXZlbDEgbGZvNCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkF1dGhvcnMgc29saWNpdGluZyBpbnRlcmVzdCBhbmQg c2hvdWxkIHRoaXMgd29yayBtb3ZlIGZvcndhcmQuPG86cD48L286cD48L3NwYW4+PC9saT48bGkg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDouNzVpbjttc28tbGlz dDpsMyBsZXZlbDEgbGZvNCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkNoYWlycyByZXF1ZXN0ZWQgdGhlIGRpc2N1c3Np b24gbW92ZSB0byB0aGUgV0cgZW1haWwgbGlzdC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPldlIGFsc28gZGlzY3Vzc2VkIHVwZGF0aW5nIHRoZSBtaWxl c3RvbmVzIGFuZCBjaGVja2luZyBXR0xDIHJlYWRpbmVzcyBvZiB0aGUgYXJjaGl0ZWN0dXJlIGRy YWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5 cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzEuNXB0O21zby1saXN0OmwxIGxldmVsMSBsZm82Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+4oCcQ2hhcnJh4oCd IOKAkyBUYXJnZXRpbmcgU2VwdGVtYmVyIGZvciBXR0xDIC8gTWFyY2ggZm9yIHB1YmxpY2F0aW9u PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDozMS41cHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzYiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7i gJxJbnRlcmFjdGlvbiBNb2RlbHPigJ0g4oCTIENhbGwgZm9yIGFkb3B0aW9uIG5lZWRlZCwgcGVu ZGluZyBhZGVxdWF0ZSByZXZpZXdlciBmZWVkYmFjazxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxp IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzEuNXB0O21zby1s aXN0OmwxIGxldmVsMSBsZm82Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+4oCcVG9rZW4gYmluZOKAnSDigJMgdG8gYmUg cmVtb3ZlZDxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzEuNXB0O21zby1saXN0OmwxIGxldmVsMSBsZm82Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+4oCcRUFU4oCdIOKAkyBXR0xDIGNhbiBiZSBwbGFubmVkIG9uY2UgdGhlIGlzc3VlIHdp dGggRW5kb3JzZW1lbnQvRW5kb3JzZXIgZGVzY3JpcHRpb25zIGluIHRoZSBhcmNoaXRlY3R1cmUg SS1EIGNhbiBiZSBjbGFyaWZpZWQuDQogVGFyZ2V0aW5nIElFU0cgc3VibWlzc2lvbiBpbiA2IG1v bnRocy48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjMxLjVwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvNiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPuKAnFRVREHigJ0g4oCTIE5vIHJlY2VudCBkaXNjdXNzaW9uIG9uIHRoaXMuIEF1dGhvcnMg YXNzZXJ0IHRoYXQgb3RoZXIgSS1EcyBzaG91bGQgZ28gYWhlYWQgc2luY2UgdGhlcmUgYXJlIGRl cGVuZGVuY2llcyBvbiBvdGhlcg0KIEktRHMuIEF1dGhvcnMgZmVsdCB0aGV5IGRpZG7igJl0IGhh dmUgYmFuZHdpZHRoIHRvIG1vdmUgYWhlYWQgcmlnaHQgbm93LjxvOnA+PC9vOnA+PC9zcGFuPjwv bGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzEuNXB0 O21zby1saXN0OmwxIGxldmVsMSBsZm82Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+4oCcUklW4oCdIOKAkyBXR0xDIGNh biBiZSBjb25zaWRlcmVkIGF0IHRoZSBlbmQgb2YgQXVndXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwv bGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_567D4A8D75AA4794A4F0A930C5418ECAintelcom_-- --_004_567D4A8D75AA4794A4F0A930C5418ECAintelcom_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Wed, 29 Jul 2020 23:34:00 GMT"; modification-date="Wed, 29 Jul 2020 23:34:00 GMT" Content-ID: <1C42C85E77CC1249BD4B4DFE7DC0FFDE@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNhYWcgbWFp bGluZyBsaXN0DQpzYWFnQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NhYWcNCg== --_004_567D4A8D75AA4794A4F0A930C5418ECAintelcom_-- From nobody Wed Jul 29 16:41:24 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F543A0945 for ; Wed, 29 Jul 2020 16:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ip1KQNNIA4wO for ; Wed, 29 Jul 2020 16:41:21 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79723A0924 for ; Wed, 29 Jul 2020 16:41:21 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06TNfHkC024003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 29 Jul 2020 19:41:19 -0400 Date: Wed, 29 Jul 2020 16:41:17 -0700 From: Benjamin Kaduk To: saag@ietf.org Message-ID: <20200729234117.GF92412@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [saag] volunteers for SAAG minute taker, jabber relay X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2020 23:41:23 -0000 Hi all, In order to keep the SAAG session running smoothly, it will be good to have a couple minute-takers and a jabber relay lined up in advance, so we don't need to spend time during the session looking for one. If you would like to volunteer, please reply to sec-ads@ietf.org and let us know. Thanks, Ben From nobody Wed Jul 29 17:23:26 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139B73A0AC7 for ; Wed, 29 Jul 2020 17:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDehOyOSE8t2 for ; Wed, 29 Jul 2020 17:23:23 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED94E3A0AC5 for ; Wed, 29 Jul 2020 17:23:22 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06U0NJ0F002946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 29 Jul 2020 20:23:21 -0400 Date: Wed, 29 Jul 2020 17:23:18 -0700 From: Benjamin Kaduk To: saag@ietf.org Message-ID: <20200730002318.GO92412@kduck.mit.edu> References: <20200727230933.GJ41010@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [saag] Fwd: MLS IETF 108 report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 00:23:24 -0000 On Tue, Jul 28, 2020 at 03:23:16PM -0700, Nick Sullivan wrote: > MLS met at IETF 107 and 108, and also held 14 short virtual interim > meetings since IETF 106. There were two new submissions to the Architecture > document (-04, -05) and one major update to the Protocol document (-06). > The progress on the Protocol document has been conducted mostly on Github > with over 20 issues closed and 40 PRs merged, with weekly digests being > sent to the list. The group is moving towards a freeze on the Protocol > document to give the academic community time to do formal analysis. > From nobody Wed Jul 29 17:24:07 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230A13A0AC8 for ; Wed, 29 Jul 2020 17:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqY1wY5-Txfn for ; Wed, 29 Jul 2020 17:24:03 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5C33A0AC7 for ; Wed, 29 Jul 2020 17:24:03 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06U0O03P003130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 29 Jul 2020 20:24:02 -0400 Date: Wed, 29 Jul 2020 17:23:59 -0700 From: Benjamin Kaduk To: saag@ietf.org Message-ID: <20200730002359.GP92412@kduck.mit.edu> References: <20200727230933.GJ41010@kduck.mit.edu> <882C751E-A65F-4FB0-9DC8-D0A48B279F29@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <882C751E-A65F-4FB0-9DC8-D0A48B279F29@akamai.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [saag] Fwd: ACME IETF 108 report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 00:24:05 -0000 On Tue, Jul 28, 2020 at 12:46:50PM +0000, Salz, Rich wrote: > ACME meets after SAAG. > > What happened since 106 is several documents moved down the process for publication; got AD reviews, etc. From nobody Wed Jul 29 19:16:41 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D522C3A0B70 for ; Wed, 29 Jul 2020 19:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4DwG2aSRMVK for ; Wed, 29 Jul 2020 19:16:38 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 BEB463A0BA1 for ; Wed, 29 Jul 2020 19:16:37 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id j23so6920183vsq.7 for ; Wed, 29 Jul 2020 19:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=e9BrPjMC5ZrmZDV0bA/liNgnnRGWKdMMIQcfW02NYCk=; b=TOyAWGrQ1wiDZrydXj0nquL35wO963zW0kKVVUkuquhB56zgdbHBCoYzTDJThrcjWj J3ioyMRrCoQdNYZ+LXVyXhwlXCjTmuqOWei0FBePK8tgbWEa13FtfxZLXbpyDP0A83Zy i40AD1ahk6npp4x0iIQU6rYg7gTTeiW/t+ifkaTP7LYVmPRwLzBpNm6c0qSQg26QB47E ITxViFGVyxL9mFBfEg4gZdCwywnfocONaNbC6fLbOewNfuSU95rNlvcXRO7fnsHPfWA1 /ibHIg6Rk/FOuCUcBmsaCojP6lr7QHXZ50C8I+9B9XA7hyoy9OYBEFK+XbGSvTb8f4it L1xg== 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=e9BrPjMC5ZrmZDV0bA/liNgnnRGWKdMMIQcfW02NYCk=; b=IIUPU+TO91XzvK0X9dSRJc7Vfi98VNVC1pmlw87W7BN/3U3yiTlVWLVRR2wXd+HGDD ZwQbQluDjmDFeudlFimRUbwCufczOBzytZWaoP64XE++g0fea2OyiR8lHIxWDmTg1XIV ckue7P38VTyHmn7dPoLcneDVqDX7GnfwckzBuhdCwYAG0nfg/dFD6GlceW0NGDNCmNXP Z+Wb5ZCxxEBOdxoZwivzPR5C6kOz8ANtEEOA1mMjVo3O8TnRUbwee7mV9GhFNMwfSMnF zqeTNVyyYQ3ccJ2TePW9yA4Q1VNBn6tKQqIOOWpSrPbmKxrR7uEns/2hOY3CZYzD80Ak uKig== X-Gm-Message-State: AOAM532xH5XE+yeM4RT2/+V4TcRfpe3wtxmfACG+mxJpdz8ied0vVOEq YeIOtETAMpD7ty4eOXlDixEdVBG+VADlTJ8ylKCx6Q== X-Google-Smtp-Source: ABdhPJx/iQAuQj7/F7foHPFi5RI0nT+GUHOzSFBu3Eg5ooyxx6HdF0ayYRdbYmJPXpKgfSRmoj+NfZCFu0034pOiSnA= X-Received: by 2002:a05:6102:31bc:: with SMTP id d28mr339238vsh.180.1596075396415; Wed, 29 Jul 2020 19:16:36 -0700 (PDT) MIME-Version: 1.0 From: Daniel Migault Date: Wed, 29 Jul 2020 22:16:25 -0400 Message-ID: To: saag Content-Type: multipart/alternative; boundary="00000000000009c40d05ab9f4328" Archived-At: Subject: [saag] CURDLE IETF108 report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 02:16:40 -0000 --00000000000009c40d05ab9f4328 Content-Type: text/plain; charset="UTF-8" The WG did not met. Yours, Rich and Daniel -- Daniel Migault Ericsson --00000000000009c40d05ab9f4328 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The WG did not met.

Yours,=C2=A0
Ric= h and Daniel

--
Daniel Migault
Ericsson
--00000000000009c40d05ab9f4328-- From nobody Wed Jul 29 19:33:46 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59D43A0BDF; Wed, 29 Jul 2020 19:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLhPbtj7Pi4U; Wed, 29 Jul 2020 19:33:35 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C20F3A0B89; Wed, 29 Jul 2020 19:33:33 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:61d1:782c:89f4:1370] (unknown [IPv6:2800:810:464:1f7:61d1:782c:89f4:1370]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3E5E7281479; Thu, 30 Jul 2020 02:33:29 +0000 (UTC) From: Fernando Gont To: "saag@ietf.org" Cc: Benjamin Kaduk , draft-gont-numeric-ids-sec-considerations@ietf.org References: <20200717204604.GV41010@kduck.mit.edu> <20200721033933.GB41010@kduck.mit.edu> Message-ID: Date: Wed, 29 Jul 2020 23:33:18 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200721033933.GB41010@kduck.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] AD evaluation of draft-gont-numeric-ids-sec-considerations-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 02:33:45 -0000 Hello, Benjamin, In-line.... On 21/7/20 00:39, Benjamin Kaduk wrote: > Hi Fernando, > > Oops, it looks like I failed to actually cc: SAAG on my initial > comments like I had planned to. I will send the responses here > (inline) that I already wrote up, but expect to re-send them to the > saag thread after I forward my initial review there. Sorry about > that! Yep.. I thought I was missing something, cause I couldn't find anything sent or CC'ed to saag. :-) [....] >>> Section 2 >>> >>> What's wrong with the RFC 4949 definition of "identifier"? (We'd >>> still want to keep the discussion about "transient", of course.) >> >> To be honest, we missed there was this definition of "identifier" >> in the RFC series. That said, the definition in RFC4949 also >> acommodates non-numeric identifiers, for which the concept of e.g. >> "linear" , monotonically-increasing, etc. would not apply. > > This is true (and I was not sure whether pulling in 4949 for a > single definition was going to help much -- it doesn't cover any of > the other things we need). > >> I would suggest that we replace this definition of "identifier" >> with the definition of "transient numeric identifier", which is the >> specific identifiers we're concerned with here. > > That seems like a really good approach (especially since we > explicitly say we will use the shorter term to refer to the same > thing in this document). Will do. Thanks! [....] >> >>> Implementing only part of a spec is a problem, but if we want to >>> lament lack of adoption of follow-on updates, we should be >>> writing things differently. >> >> What we meant here is that this is a case where you might face >> security issues arising from flawed transient numeric IDs, but this >> has nothing to do with suboptimal specs, but rather with suboptimal >> implementations (and in that sense there's not much we (IETF) can >> do about them). > > Sure. "The right thing to do is properly specified (whether in a > given document or an update to it), but the implementation just > didn't do the right thing." Will clarify this as suggested. Thanks! >>> By requiring protocol specifications to clearly specify the >>> interoperability requirements for the transient numeric >>> identifiers they specify, the constraints in the possible >>> algorithms to generate them, as well as possible >>> over-specification of such identifiers, become evident. >>> Furthermore, requiring specifications to include a >>> >>> nit(?): I'm not sure whether "constraints" is the right word here >>> -- what is being constrained, and by whom? Would "limitations" >>> or "risks" be workable? >> >> Probably an issue of "English as second language" here, sorry: I >> guess we could have used "requirements" instead of "constraints". >> i.e., what we meant is that if you spell out the interoperability >> requirements, two things will become evident: >> >> 1) The very "function" the algorithm needs to implement (e.g. if >> you need monotonically-increasing IDs, you better make sure that a >> new transient ID is larger than its predecesario), and, >> >> 2) It would become evident when you are overspecifying things >> (.e.g, monotonically-increasing IDs need not be a global counter >> that starts at 0 -- that's not necessary to achieve >> monotonically-increasing IDs). > > Thanks for writing this out, it helps a lot. I suspect that what we > actually want is to keep "constraints", but s/in/on/ -- the > "constraints on the possible algorithms" are exactly the "function > the algorithm needs to implement", which leads nicely into the > "possible over-specification" that matches your point (2). Awesome! Will fix this. >>> security and privacy analysis of the transient numeric >>> identifiers they specify prevents the corresponding >>> considerations from being overlooked at the time a protocol is >>> specified. >>> >>> [*] I really don't think this is an appropriate way to phrase >>> what we're doing. To specifically *require* authors to include >>> an analysis that covers these particular points seems to be quite >>> a divergence from RFC 3552 -- while the presence of a security >>> considerations section in RFCs is required, what RFC 3552 claims >>> to provide is just guidelines for how to write such a section. >>> Isn't what we're doing here just an incremental addition to that >>> guidance, not a new hard requirement on authors? >> >> Indeed. >> >> How about changing the paragraph to: >> >> Clear specification of the interoperability requirements for the >> transient numeric identifiers will help identify possible >> algorithms that could be employed to generate them, and also make >> evident if such identifiers are being over-specify. A protocol >> specification > > ("over-specified") > >> will usually also benefit from a security and privacy analysis of >> the transient numeric identifiers they specify, to prevents the > > ("to prevent") > >> corresponding considerations from being overlooked in the protocol >> specification itself. >> >> ? > > Looks good; just the indicated nits. Great! Will do. >>> Section 4 >>> >>> [*] Similarly to Section 3, this section felt significantly >>> longer than I was expecting. Could you say something about the >>> motivation for putting content here as opposed to (e.g.) >>> draft-irtf-pearg-numeric-ids-generation? (Note, this section >>> currently references draft-gont-predictable-numeric-ids, which is >>> IIRC the pre-split consolidated document.) >> >> We were not sure if sentences such as "Employing the same >> identifier across contexts in which constancy is not required" or >> "Employing the same increment space across different contexts" >> would make sense to the reader without any context. >> >> I can think of two options to address your comment: 1) Keep the >> list, and point to draft-irtf-pearg-numeric-ids-generation right >> after that. >> >> 2) Strip much of the contents of this section (notably the >> specific examples) as follows: >> >> ---- cut here ---- Employing trivial algorithms for generating the >> identifiers means that any node that is able to sample such >> identifiers can easily predict future identifiers employed by the >> victim node. >> >> When one identifier is employed across contexts where such >> constancy is not needed, activity correlation is made made >> possible. For example, employing an identifier that is constant >> across networks allows for node tracking across networks. >> >> Re-using identifiers across different layers or protocols ties the >> security and privacy of the protocol re-using the identifier to >> the security and privacy properties of the original identifier >> (over which the protocol re-using the identifier may have no >> control regarding its generation). Besides, when re-using an >> identifier across protocols from different layers, the goal of of >> isolating the properties of a layer from that of another layer is >> broken, and the privacy and security analysis may be harder to >> perform, since the combined system, rather than each protocol in >> isolation will have to be assessed. > > I see I made this one longer, but I don't get to complain :) ;-) >> At times, a protocol needs to convey order information (whether >> sequence, timing, etc.). In many cases, there is no reason for >> the corresponding counter or timer to be initialized to any >> specific value e.g. at system bootstrap. > > (Unrelated to previous comments) I wonder if it would be worth also > saying that there may not be a need for the difference between > successive counted values to be a constant increment (e.g., if order > is truly the only needed property, without any "counter" nature). > Perhaps adding to the end ", or even for the difference between > successive values to be predictable" would be a minimal-ish change, > though I'm still on the fence as to whether it's worth saying [in > this document]. I'll add it. And will also try to add this to the relevant PEARG document (in case we missed this). >> A node that implements a per-context linear function may share the >> increment space among different contexts (please see the "Simple >> Hash-Based Algorithm" in [I-D.gont-predictable-numeric-ids]). >> Sharing the same increment space allows an attacker that can >> sample identifiers in other context to e.g. learn how many >> identifiers have been generated between two sampled values. >> >> Finally, some implementations have been found to employ flawed >> PRNGs. See e.g.[Klein2007]. ---- cut here ---- >> >> The above still gives context for the bullets, but reduces the >> amount of text and the amount of unnecesary details/examples here. >> >> I'd probably prefer addressing your comment with the modified text, >> but I would still be fine with removing the text if you prefer. > > I think we can get the modified text to work; thanks for putting it > together. Would you also be able to stub out what it would look like > to just make this modified text *be* the list itself? E.g., > "Employing trivial algorithms for generating the identifiers, which > means [...]", "Employing the same identifier across contexts in which > constancy is not required -- when one identifier is imployed [...]", > etc. I think we might have to see what that looks like before we can > decide whether or not it will work. You mean incorporate each piece of text into the corresponding bullets? Or removing the bullets an just keep the text? Or keep the bullets but just try to put the text bellow together in the same para? Or avoid using the bullets, and have something like: ---- cut here ---- This section briefly notes common flaws associated with the generation of transient numeric identifiers. Such common flaws include, but are not limited to: Employing trivial algorithms (e.g. global counters) that result in predictable identifiers, which means that any node that is able to sample such identifiers can easily predict future identifiers employed by the victim node. Employing the same identifier across contexts in which constancy is not required, thus allowing for activity correlation -- as in the case where the use of an identifier that is constant across networks allows for node-tracking. Re-using identifiers across different protocols or layers of the protocol stack, breaking the goal of isolating the properties of a layer from those of another layer, and also making the privacy and security analysis may be harder to perform, since the combined system, rather than each protocol in isolation, will have to be assessed. Initializing counters or timers to constant values, when such initialization is not required, thus unnecessarily leaking information (e.g., "system uptime" if a timer is reset to zero when the system is boot-strapped). Employing the same increment space across different contexts, where a per-context linear function shares the increment space among different contexts, thus allowing an attacker that can sample identifiers in other context to e.g. learn how many identifiers have been generated between two sampled values. Finally, some implementations have been found to employ flawed PRNGs. See e.g.[Klein2007]. ---- cut here ---- I wouldn't mind doing it in this way... although, the very first paragraph of Section 4 kind of introduces a list, so I'd rather make the above list a bulleted list. (Still, I think the stripped-down version with the bullets is a bit more clear) -- I can do two versions of the I-D, with these two options so that we can check how the text looks & feels on the real doc. And then we choose and post the one that looks best... [....] >>> 1. Clearly specify the interoperability requirements for the >>> aforementioned identifiers. >>> >>> Hmm, would it be fair to say "interoperability (i.e., >>> functional)"? >> >> I'm not sure if the two words convey the same meaning. You might >> probably know better than me fore this one (i.e. "English as >> second language"). Not sure if someone might interpret "functional >> requirements" as a vague description of what the transient numeric >> ID is for (e.g. "identifying packets") as opposed to detailed >> requirements such as "monotonically increasing...". >> >> That said, no matter which specific term we employ, I guess it >> might helps to add a parenthesis with something like: >> >> >> "(e.g. required properties such as uniqueness, along with the >> failure mode if such properties are not met)" > > This is good; we should probably take it. > >> Thoughts? > > In light of the discussion here, I think it is okay to stick with > "interoperability". I might consider going with "core > interoperability", in an attempt to emphasize that we are looking for > the actual fundamental requirements, not just the stuff that the > protocol authors put in as MUST because they felt like it, but I > think just "interoperability" would work, too. Good point. Will do. [...all other agreed-upon changes applied...] >> Thanks *a lot* for your comments! They have been really useful. >> -- Please do let us know what you think about the few open issues >> above and, whether we should rev the document after that. > > I think we have gotten as far as we can get just by talking about > potential changes, so please go ahead and rev the document so we can > see the changes and have a chance to change our mind back :) Please let me know what you think e.g. about the above two options.. and I will produce one or two versions of the doc for us to check -- and then, we pick the one we're more comfortable with, and get it posted. Thoughts? Thanks a lot! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Jul 29 23:54:51 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41DB3A0EBE for ; Wed, 29 Jul 2020 23:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J_hmaTZWboNQ for ; Wed, 29 Jul 2020 23:54:47 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739CF3A0EA1 for ; Wed, 29 Jul 2020 23:54:46 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:61d1:782c:89f4:1370] (unknown [IPv6:2800:810:464:1f7:61d1:782c:89f4:1370]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 473D5280470; Thu, 30 Jul 2020 06:54:43 +0000 (UTC) References: <159609107416.27817.11063909245893590356@ietfa.amsl.com> To: "saag@ietf.org" From: Fernando Gont X-Forwarded-Message-Id: <159609107416.27817.11063909245893590356@ietfa.amsl.com> Message-ID: <6df388ea-a611-9413-6511-2fe88cf5a378@si6networks.com> Date: Thu, 30 Jul 2020 03:53:02 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <159609107416.27817.11063909245893590356@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] Fwd: New Version Notification for draft-gont-numeric-ids-sec-considerations-05.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 06:54:50 -0000 Hi, We have posted a rev that means to address Benjamin's feedback. It is available at: https://www.ietf.org/internet-drafts/draft-gont-numeric-ids-sec-considerations-05.txt The diff from the previous version is available at: https://tools.ietf.org/rfcdiff?url2=draft-gont-numeric-ids-sec-considerations-05.txt Thanks! Regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-numeric-ids-sec-considerations-05.txt Date: Wed, 29 Jul 2020 23:37:54 -0700 From: internet-drafts@ietf.org To: Fernando Gont , Ivan Arce A new version of I-D, draft-gont-numeric-ids-sec-considerations-05.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-numeric-ids-sec-considerations Revision: 05 Title: Security Considerations for Transient Numeric Identifiers Employed in Network Protocols Document date: 2020-07-29 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-gont-numeric-ids-sec-considerations-05.txt Status: https://datatracker.ietf.org/doc/draft-gont-numeric-ids-sec-considerations/ Htmlized: https://tools.ietf.org/html/draft-gont-numeric-ids-sec-considerations-05 Htmlized: https://datatracker.ietf.org/doc/html/draft-gont-numeric-ids-sec-considerations Diff: https://www.ietf.org/rfcdiff?url2=draft-gont-numeric-ids-sec-considerations-05 Abstract: Poor selection of transient numerical identifiers in protocols such as the TCP/IP suite has historically led to a number of attacks on implementations, ranging from Denial of Service (DoS) to data injection and information leakage that can be exploited by pervasive monitoring. To prevent such flaws in future protocols and implementations, this document updates RFC 3552, requiring future RFCs to contain analysis of the security and privacy properties of any transient numeric identifiers specified by the protocol. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Jul 30 00:16:21 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8243A0EF4; Thu, 30 Jul 2020 00:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smyslov.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43-MmnweNkIY; Thu, 30 Jul 2020 00:16:18 -0700 (PDT) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24BE23A0EA5; Thu, 30 Jul 2020 00:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:In-Reply-To:References:Cc:To:From: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=2I0G95KgZTIp2z+4RA6iNQLHMm1AmbW7kPQIFcbOgpA=; b=LN+PFfxBX7UGsWjiCMX1paBcik MuS14ND7REnbTvsXopBAi4653EKzwVybTeq1uAy4Q5ofF+1tmi34NG6e+fI+J07/z7tdaMKHpuFlK oSUFt6mr/yOhwyYgcK0DAmPdzDT5YzxEmwnKt7Z7VkzfIWRpyOd9UOG8cmvzWTIGc9yjcE2maaBN3 uuEYo678AHfxgTt0ne/YVMr5V+AmtqpMH2NBeHjqHsfvEZtMBrnaCgkhJpU3HaQTHIjF/JygD7RU2 Q8lRMtSkiOctcRo67FSj3BkqPq8xr1szN5npRXSq983M4aDttU+e5daNOtj0i3+0uJT+XaC9COXG/ VEZHzSDg==; Received: from [82.138.51.3] (port=60112 helo=buildpc) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1k12nW-0007W7-Kv; Thu, 30 Jul 2020 03:16:14 -0400 From: "Valery Smyslov" To: Cc: References: <122901d6657a$34b80920$9e281b60$@smyslov.net> In-Reply-To: <122901d6657a$34b80920$9e281b60$@smyslov.net> Date: Thu, 30 Jul 2020 10:16:14 +0300 Message-ID: <148901d66641$51844a60$f48cdf20$@smyslov.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHYcJwCsygGZcHEmt0fs09zuiAbF6kboQag Content-Language: ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net Archived-At: Subject: [saag] DOTS WG report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 07:16:20 -0000 DOTS WG didn't meet at IETF107 and is not meeting at IETF108. We had a virtual interim meeting in June. Since IETF 106: 1. Two new RFCs that comprise a core of DOTS protocol have been published: - RFC 8782 (DOTS Signal Channel) - RFC 8783 (DOTS Data Channel) 2. A significant progress was done for DOTS Telemetry draft, which will soon be ready for WGLC 3. DOTS Multihoming draft is still under slow development Unfortunately, shortly after RFC 8782 has been published, a problem with its YANG Module has been discovered, which can cause interoperability issues. The decision was made to publish a 8782-bis RFC and an initial draft for it currently ready for adoption. The plan is to quickly publish it as a new Signal Channel RFC and delay processing of DOTS documents that reference Signal Channel YANG Module until it is done. From nobody Thu Jul 30 00:27:45 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779AE3A0F41 for ; Thu, 30 Jul 2020 00:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfZkFVlMg7eg for ; Thu, 30 Jul 2020 00:27:41 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09E523A0F4A for ; Thu, 30 Jul 2020 00:27:41 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:61d1:782c:89f4:1370] (unknown [IPv6:2800:810:464:1f7:61d1:782c:89f4:1370]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3BA01283772; Thu, 30 Jul 2020 07:27:36 +0000 (UTC) To: "saag@ietf.org" From: Fernando Gont Message-ID: <176664f8-c91b-3301-410b-7bd62ea454ad@si6networks.com> Date: Thu, 30 Jul 2020 04:26:12 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] saag meeting X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 07:27:44 -0000 Hi, Benjamin, I see our I-D is on the agenda. Do I need slides or anything? -- If I understand correctly, this would be covered by your chair slides... but just felt like double-checking. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Jul 30 02:36:11 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAD03A1022 for ; Thu, 30 Jul 2020 02:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mL3SsIFoBFMj for ; Thu, 30 Jul 2020 02:36:09 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06EB93A1021 for ; Thu, 30 Jul 2020 02:36:08 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06U9Zwkq029194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Jul 2020 05:36:03 -0400 Date: Thu, 30 Jul 2020 02:35:58 -0700 From: Benjamin Kaduk To: Fernando Gont Cc: "saag@ietf.org" Message-ID: <20200730093558.GS92412@kduck.mit.edu> References: <176664f8-c91b-3301-410b-7bd62ea454ad@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <176664f8-c91b-3301-410b-7bd62ea454ad@si6networks.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [saag] saag meeting X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 09:36:10 -0000 On Thu, Jul 30, 2020 at 04:26:12AM -0300, Fernando Gont wrote: > Hi, Benjamin, > > I see our I-D is on the agenda. Do I need slides or anything? -- If I > understand correctly, this would be covered by your chair slides... but > just felt like double-checking. Hi Fernando, I was expecting this to be covered by the chair slides, but thanks for checking. Mostly it's just intended as a reminder that your work is progressing and a segue into the model-t report. Thanks, Ben From nobody Thu Jul 30 03:57:04 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9C73A1085 for ; Thu, 30 Jul 2020 03:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PThzEbWmpg57 for ; Thu, 30 Jul 2020 03:56:52 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F20A93A108A for ; Thu, 30 Jul 2020 03:56:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7F0A0300B6C for ; Thu, 30 Jul 2020 06:56:31 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id s3Y--Vd5Gz-a for ; Thu, 30 Jul 2020 06:56:30 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 6C8D1300512 for ; Thu, 30 Jul 2020 06:56:30 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Message-Id: Date: Thu, 30 Jul 2020 06:56:31 -0400 To: IETF SAAG X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: [saag] SUIT at IETF 108 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 10:56:59 -0000 SUIT will not meet until Friday. From nobody Thu Jul 30 05:14:10 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD0F3A0BFF for ; Thu, 30 Jul 2020 05:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwXrkBSqTYqL for ; Thu, 30 Jul 2020 05:14:07 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 E02553A0C15 for ; Thu, 30 Jul 2020 05:14:06 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id t23so16977352qto.3 for ; Thu, 30 Jul 2020 05:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=LNSp+KQMB4tYTcarlLjzTZYN+xXH3moLhpdyrvgeoC8=; b=UBl1T0mlaI1fJplqTtX8GwvzcD8XTKHQULAHdulqWxdnx3fniwGUEff9GmkLGGxXVT Q1EX9xuFrNDkRkfN6mw7mmBMGqm7Ta2kaU1y8wrRMmXKc2E03X4pNXgdQk7jL0ALjkE8 GLd3NTDOTD4qsA0vFwoptspZH9UwNff/fMkhAURFp9eyellQOkYlL+2hqCoCDETl/44K 2vmLOf9WcnqHvJ1yHixihwumDy9q5YfqoocqRV4p/1f//DNn5FlFdQqqE7jAMIJs2xcj LOybUVFojlNWTXfDKcb0i6lSA6h83Z14WlqcJFLMl40UKGvcSsvvFirsd1UmR3SiGiVc EOJg== 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=LNSp+KQMB4tYTcarlLjzTZYN+xXH3moLhpdyrvgeoC8=; b=d5YpzgRlgjB3+eO9DlIUnICL32CflfVBOeAmhfMT+DZarbv4yff+xjVcOvlVkT+Fby cqVk2WnlF0wvBwJYIzEbP9v++IE2hwlPmK5KbAIxqRirNfxlYn1AARhMkc6pp3pFHMWO MhGgIpED1IBAqo6g4ekh//YRsWX4+TG9A0METvIgDR084lco9icyxxgM5+xvzvhTYuNJ z3gLlayjoJW3vTi6cpb3j98lwSwT95Wwf8Qux3iNFdqmi+5fAF2ohABmcQLx1TV2JQrd olbLv72OcKnzO1fmD/yPDp2zYx5JWKbWbxIe67ql7MnosXwCdGd6nNTYNnuGJX9WqWDn vWmg== X-Gm-Message-State: AOAM531Svu1FV4ZJtqabbavak4UzHStLBQ6Y3Atv8mCByQQY7cRoeBCi GWRhwKgP1SEvC+5wEf3TXRdNPsodAUpiG2Arn3XqX7LnbL0= X-Google-Smtp-Source: ABdhPJz7ijExrUTB+/nmjqQvta3gIqaY8WK1TAGVghf1ifdJoSjhi9IaZgMr0/V9UcaxO+wf11cad4kFNmQ1w9prMgo= X-Received: by 2002:ac8:1201:: with SMTP id x1mr2345106qti.95.1596111245690; Thu, 30 Jul 2020 05:14:05 -0700 (PDT) MIME-Version: 1.0 From: Joseph Salowey Date: Thu, 30 Jul 2020 05:13:54 -0700 Message-ID: To: saag@ietf.org Content-Type: multipart/alternative; boundary="000000000000d2638705aba79b5c" Archived-At: Subject: [saag] PrivacyPass IETF 108 Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 12:14:09 -0000 --000000000000d2638705aba79b5c Content-Type: text/plain; charset="UTF-8" Privacy Pass will meet for the first time as a newly formed working group on Friday. The goal of the Privacy Pass protocol is to provide a performant, application-layer mechanism for token creation and anonymous redemption. We will discuss drafts that are proposed to be the basis for the architecture, protocol and api working group deliverables. The following drafts will be discussed: - draft-davidson-pp-architecture-01 - draft-davidson-pp-protocol-01 - draft-svaldez-pp-http-api-01 --000000000000d2638705aba79b5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Privacy Pass will meet for the first time as a newly formed wor= king group on Friday.=C2=A0 The goal of the=C2=A0Privacy Pass protocol is t= o provide=C2=A0a performant, application-layer mechanism for token creation= and anonymous redemption. We will discuss drafts that are proposed to be t= he basis for the architecture, protocol and api working group deliverables.= =C2=A0 The following drafts will be discussed: --000000000000d2638705aba79b5c-- From nobody Thu Jul 30 05:29:39 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA683A10DD for ; Thu, 30 Jul 2020 05:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 83P_DX-DdtgP for ; Thu, 30 Jul 2020 05:29:32 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690096.outbound.protection.outlook.com [40.107.69.96]) (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 475823A10D7 for ; Thu, 30 Jul 2020 05:29:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k+ra+b3ycnyM7yqyqHC9aADcPwYFnHgp+sRe8uhmMNVUdWwjdkGs2Y4xQoi4VrQBFcwYSGyCOl1GNWIqH8TH3v0hQuQ5zzKdUh769LvKEyc7/BBP1KzF2iWE6HizXiTeibo+YtqeuUxAO5nvZZvkCoIVjr/yEhB3YAF4f2PBvA1+YT/ZZpuf8gyx3jhem+Nf9GXh4nvIWFro2u9OR1jinLzjGN2MnLBsVHFEUV/DBIUZAL/QrL858DzNp4zMLzGV6X+14sOGgR4RwvD8jlMUH+W6rmhzFjb2GDseQS+rDKBreO07jmsz5iXwC5SMbqE0yY/ZjxoT1vVEtxu+bmTmyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OrPKpYqmZGopY/nGG2j6KgHNbJTeK2w3gLSag8fx9fo=; b=nD8Mxj279pA6jE6zTIbEGSqBhR5WvdtD6rBIGfcbR+dbkX8Jx9JE4k0VHOVqiuB7VsFuKB/FPvuEPuP8UcD4zoP5vjd5HAD6qZB4eOk4MpJr7OHxmegkFWpD0wqTaC/j7v9TcavmPOyyNEhSgTV83Mj8D1KIlB+y1uxp62KEkNIhg7VEGaJj0J8fQOYfXKAvmz1UPzNe5bW3Z+RfjwdRRldcMRLSnUPa/E8ukaGpmIL+NY25unHYuAIgDeNcUGRSW0kpnn4OT0pBmbrq/vN7L8Sg7Ji7/HK7WPIt0GdCrzIBnqfgqTaseB+TFC2S5raabZyw7wFS2SQkj7s4r+vhBg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OrPKpYqmZGopY/nGG2j6KgHNbJTeK2w3gLSag8fx9fo=; b=PP1h88iIqCaGOmJVvw0fqmHYLqcehZ7B0YF7XkWVhOpHmtcBrohv7GgiWlaa2zTuAEYbexpX2cslQuZPA0YaRAqu6ryDATsyL1gp+yRO0JC2q2/GncYAG59rvSBe6GYc+bx2q+vCriFM2d/tNkOIrk1Rtv20wf5nMSPhzJ7T/eI= Received: from DM5PR2101MB1031.namprd21.prod.outlook.com (2603:10b6:4:9e::12) by DM5PR21MB1765.namprd21.prod.outlook.com (2603:10b6:4:a4::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.3; Thu, 30 Jul 2020 12:29:30 +0000 Received: from DM5PR2101MB1031.namprd21.prod.outlook.com ([fe80::b1f3:17d1:db1d:9448]) by DM5PR2101MB1031.namprd21.prod.outlook.com ([fe80::b1f3:17d1:db1d:9448%7]) with mapi id 15.20.3239.017; Thu, 30 Jul 2020 12:29:30 +0000 From: Dave Thaler To: "saag@ietf.org" Thread-Topic: [saag] SUIT at IETF 108 Thread-Index: AQHWZm0S8ZLzQDzL/02zWBL6a/zMgA== Date: Thu, 30 Jul 2020 12:29:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-07-30T12:00:41Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=6c7866f0-2258-463d-8710-93e742a38980; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2601:600:9780:16f0:f83d:3cdb:5a43:f84d] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2487f8ed-cd55-4226-0a1d-08d834843566 x-ms-traffictypediagnostic: DM5PR21MB1765: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: loyPgcvfqxHKEUIY30/+JA7QI4yveVpxks69JteBF5VGvvYHZmawXni5wTs5hrQyufRnddseOaal9QHF0gGZT/WlN891DVJJGRwwzL4wTmbE88+B8dxOrALnyN7/Dt8SJSZ+mOCDFmZGR0mDQTIdCqZDfsAlY2532HnMb9XYLcSmgIThf9qebG11KjnOABQLDxK9PRGIn1pC/ZymoE1++igeKMT7RMlpAnLoecyB51reZO4xFU6ZOUvIpyLr4ly8q8TH+V/NdVkWvOyG51UZNWizzvjhmHG3j4Zft6ZVPNSWqz/M4WNzFydDgRuXsyt3GaxPwbA3A8ghIxa7VZV0Xw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR2101MB1031.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(376002)(396003)(346002)(366004)(66446008)(8990500004)(10290500003)(64756008)(66476007)(66946007)(33656002)(76116006)(66556008)(71200400001)(7696005)(316002)(186003)(2906002)(52536014)(5660300002)(8676002)(2940100002)(6916009)(82950400001)(6506007)(8936002)(9686003)(478600001)(4744005)(55016002)(82960400001)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: GFoBYSYGkfGI8VfVkYuPnzMWc030+DxiHe9CEXOvTNil65u7MVAY3tlaal2/wey6rV03corK/SsTYP3oKRaSJJmORo/z1vLcgt/4Uwv1wX6LhMIRkHhSvNCHjwNh8OA56KRIJo0D89mG71klCu/BufQ5Gljq7sKaYC3fsWTOlM04rUALvA9cTt8P8UnyW3cnEmfE/e55ljaEfMTKl2IyBMvZjrNKC7eHNxPdoKwxp+QDCPj/ZmHu61l6XnD96UcP1C/DCSVl5hrnPelboc7HyQG9orANbL9HwH0B6ZW4TL33vXB8NTiGvukfjwwYs0l6TmpEK2knXRLRd4ZdxIlSRPJms0G+050egkbDwOhND9DeYkRHiUVzFWHfRgqdFqgdLNfj+i9qNxSTKlA3FhTQF7CHdP/a2JoTXCSZkuMLyKLoJCMCMBBI4Q6rBtVEjPIEHolLP14kwrZUjhF8Chm/PDJ8Pq6PB1nHsr+j9Q1W8819FPulEDze5JMo0XZrJDHIeStq5AqPjGdTPkQ4KTiyyzzhZeW53fjMDee6OHUdfGKB/V6WhcYz4T2er3M2uzPv+sUsNKHs0YGT6BKgCNnzPMB3YCQZG6MLNqZOd89z3C6NKp08wY0cVo7fI/8z0eTjZsmM6w75pfQbhiBWCuqpDbNqNwW5wvqEVDPfan0vdULawVo7yyjRVfFEIO3/XZlnBw3xJ5d74zfZQonSMYN27g== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM5PR2101MB103110BBBF668E6D9ADFE703A3710DM5PR2101MB1031_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR2101MB1031.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2487f8ed-cd55-4226-0a1d-08d834843566 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2020 12:29:30.8877 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: R9xxgHmEaESn2rr2M5c25GvSBZOcFTbuJ0JA7tlFKTTxxHeD1uAoQR1k++mCxuJNi2UX3V+2nHw9rZQoim4b7ad14ZkDlgPZnPPJaVcclxw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB1765 Archived-At: Subject: Re: [saag] SUIT at IETF 108 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 12:29:35 -0000 --_000_DM5PR2101MB103110BBBF668E6D9ADFE703A3710DM5PR2101MB1031_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Russ Housley > wrote: > SUIT will not meet until Friday. Since Ben asked for status since IETF 106, here's that report for SUIT. Summary of SUIT activity since IETF 106: * SUIT held a joint hackathon with TEEP and RATS in Berlin in Februar= y, and had a virtual SUIT interim meeting collocated. * Two drafts were submitted to the IESG: draft-ietf-suit-architecture= (currently in Last Call), and draft-suit-information-model (currently in A= D Evaluation) * SUIT had another virtual hackathon on July 13th, to flesh out issue= s with draft-ietf-suit-manifest to discuss at IETF 108 * As Russ noted, SUIT will meet on Friday and will continue discussio= n of the manifest draft Dave --_000_DM5PR2101MB103110BBBF668E6D9ADFE703A3710DM5PR2101MB1031_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Russ Housley <housley@vigilsec.com> wrote:

> SUIT will not meet u= ntil Friday.

 

Since Ben asked for status since IETF 106, here̵= 7;s that report for SUIT.

 

Summary of SUIT activity since IETF 106:<= /p>

·       SUIT held a joint hackathon with TEEP and RA= TS in Berlin in February, and had a virtual SUIT interim meeting collocated= .

·       Two drafts were submitted to the IESG: draft= -ietf-suit-architecture (currently in Last Call), and draft-suit-informatio= n-model (currently in AD Evaluation)

·       SUIT had another virtual hackathon on July 1= 3th, to flesh out issues with draft-ietf-suit-manifest to discus= s at IETF 108

·       As Russ noted, SUIT will meet on Friday and = will continue discussion of the manifest draft

 

Dave

--_000_DM5PR2101MB103110BBBF668E6D9ADFE703A3710DM5PR2101MB1031_-- From nobody Thu Jul 30 05:31:42 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672893A10DD for ; Thu, 30 Jul 2020 05:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=0.5, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4jHxgEEGWaH for ; Thu, 30 Jul 2020 05:31:38 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750077.outbound.protection.outlook.com [40.107.75.77]) (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 5E0763A10D2 for ; Thu, 30 Jul 2020 05:31:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O78IlXFmYqtwlC2DwHOYXc672YE6M1d5wYSrh6g4ZrfToRx/64D3KUm7xdTwPtrqn7ir4qRux9wSokJbroPYxFUrp9QO6fAH0RMlXwxKHuZ5q4mbgCbnFyfQYj5LdCNOX4Lmu24o7UUr3uXnWFWsm1ef2WDpI0AQsf4PcbTB6cTnhQh6YDY+2KYlQ9Hwsrbv9eaP2T/pF4quB/9k/XGu0Lno+2o1RStpZbqtnv5KxgSecM+Gfd7lfy7oc42bMgyF/wx0snKTjLTCV8e4iNnQVv0gr8/McwCEmzZ3oLjTg1w6iYx3bn0j2vBXI16P+V1a6QXhjmQUeULffe4miMB9Rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yuQSXs5wbDKF8mhi45ZbMDTq6PBmnZWdARiPbE0RrpA=; b=QOPfbP4fHf7V0H+2xKxdB+BPM4LzEbVVMPw7TAA9+PezG8mkloem6eqhoUb7LdrJrnOwU6pFKiQfBDCEuAs4Wx6PNs1+B3KOatNohbql3QZb26ojG/mEY0MwkeJ6nWFdsPZqDiPbeSqAyacoH+T9Ntpsn9hUUWZ+rwBRlauY6kk31i1h9Z//onCjkLwyuhOt4nmRc0w/b/raLsIfHZx61FKNFoxJ+EvB/u1tWZ+Q/NFWiWnN9Pc4snwBn2eskouaL0jNQxM7Pnz99nxhpHXOP9+dhcMvGVQ06z/NYaKCDPUD7ijFRBOkbwIjktII3O175z3QP3XUF4yDe2BCCxL0aQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yuQSXs5wbDKF8mhi45ZbMDTq6PBmnZWdARiPbE0RrpA=; b=KXdOYF4wfufD+kQrkwcuTwrjYnaz4Kt0boCtfdsrqTLcHmbI9PEK1AUouaFT6+5V2ID0gfqk7FdpRaiouXnKyektr/RpCEfUwkNo4ysFgp7oMqZizJiFN84aC4Neyrt3hPkWmc2aoQCKOiKz7/k/EnVQDtX+4XrWVw5vcuq4+5c= Received: from DM5PR06MB3018.namprd06.prod.outlook.com (2603:10b6:3:3b::23) by DM5PR06MB3017.namprd06.prod.outlook.com (2603:10b6:3:44::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.18; Thu, 30 Jul 2020 12:31:36 +0000 Received: from DM5PR06MB3018.namprd06.prod.outlook.com ([fe80::2d57:9e6a:77cb:35cf]) by DM5PR06MB3018.namprd06.prod.outlook.com ([fe80::2d57:9e6a:77cb:35cf%9]) with mapi id 15.20.3216.034; Thu, 30 Jul 2020 12:31:36 +0000 From: Karen O'Donoghue To: "saag@ietf.org" Thread-Topic: SACM @ IETF 108 Thread-Index: AQHWZm1dhla6Te2NekCQWYcq5sj2UQ== Date: Thu, 30 Jul 2020 12:31:36 +0000 Message-ID: <7D8F4C99-FC60-4ADE-A066-EF40427510D7@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=isoc.org; x-originating-ip: [173.44.72.18] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dcc213f5-c96e-4c5b-0fd6-08d83484805a x-ms-traffictypediagnostic: DM5PR06MB3017: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GsvEFgO8efES7SGch700dbN6gYcej0+Y0al0pHtADMPNmbFCiglpNscnpNw+e71joHU2yRfQQp9yc0IFyvRou29DYPhZrc8fByzK0a/SqwGndr0efTFWIVGhFXC0sPnWfLYEH0DWj08DwE1eI3mywlWKpSPXeMkX7a34X18bB+azbzHqrEGcSOJsr3PLdbeZbHpbVsn2lJF7GrtielYk9ExJceP6yK4atXY3F7dc/0iv/vDOSs8LrnO5D9kuwLPmpxrfsFl8bay+uhnUr8shGRlcUrqfcQyKn0P6lgHKT/y3jzwbdhn3TjM8NruNngSO9M2wlPmftSsIKwGLOxqkJzNeJ8Hf2aHyVeZVM9E3ZbfD4ACFgxUJP0jjE2GKJcWIFxikFaNnCLHkobAhfKV/0Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR06MB3018.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(366004)(136003)(376002)(346002)(39840400004)(396003)(8936002)(478600001)(6486002)(66946007)(76116006)(91956017)(6506007)(316002)(71200400001)(36756003)(86362001)(8676002)(6512007)(4744005)(33656002)(2616005)(2906002)(66476007)(66556008)(186003)(26005)(6916009)(64756008)(66446008)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: w1QK+Q8teZHHOc04skoFhYH2Ep+aiF+xyV2Hhv3NC2pnJE/+GzserhibNFE3Ypzdvw3qYHyoRpplCEIFlyWFqBFoa4i8kOx7J4D724GtsXJCgMllYDd4RukGmF8yNpiBbLNQ8Yi17lbnhpaoEhxRqRg0/GV16qwMfeMF5u063H6TYMY6bfcS6181+7wRzVgjeolVGZP6fQQiWD0UBVTUb8YjyJm+WHJG/584LeRSYw6K1WfeVTxOnS9pZS1kHZiJCVNwsi+/1RKh5KFeK8LwCUG7IuMHsM1rf74km0QNW8RQPbPSyUE4lrkZ2lhp9cekylA8kMRWkwkrMVlNquKMl+eVREXOtKpWotQI+Kq2ICDmXQF/hz8zYocs5LafdhWneIHR9Yy3GEx4Cs+RCwVzjRW81H6D/jB03joxrlLS6MGtRWym68sQxMYByLVTeA41t+h0uiAJEU319gI9gRyayT++qF13uwqVUrfdWKqAo3X8unVjwUmcHR9u7qmZsg6CFVy6/VJQi2xDsnNyrD4VHQrMpzaOqE5PL0w2JQDL25oet6v7QzUQxQS3D8iqJUNt65abf7RFgU81zDWiArmoi1KZNkV8hV678Q788csQdteFNbV8DGBjUrz62y7fpgDwfh/x4g7MSs+xf1fFTT6xgQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR06MB3018.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dcc213f5-c96e-4c5b-0fd6-08d83484805a X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2020 12:31:36.4749 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Zi09NTEqFPMHpGgVtjfH2cEw/FIGTM0GCaFRj2GY4Suw8Ze3VZvCwH1GdlWi3qmDb2TvDtsQlHfIbKL1fCreIw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR06MB3017 Archived-At: Subject: [saag] SACM @ IETF 108 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 12:31:40 -0000 VGhlIFNBQ00gV0cgbWV0IG9uIE1vbmRhee+7vywgMjcgSnVseSAyMDIwIEAgMTEwMCBVVEMuIA0K DQpTaW5jZSBvdXIgbGFzdCBtZWV0aW5nLCB0d28gZHJhZnRzIGhhdmUgYmVlbiBmb3J3YXJkZWQg dG8gdGhlIEFEL0lFU0c6IA0KRW5kcG9pbnQgUG9zdHVyZSBDb2xsZWN0aW9uIFByb2ZpbGUgKEVQ Q1ApIChodHRwczovL3Rvb2xzLmlldGYub3JnL3dnL3NhY20vZHJhZnQtaWV0Zi1zYWNtLWVwY3Av KTsgYW5kIA0KQ29uY2lzZSBTb2Z0d2FyZSBJZGVudGlmaWNhdGlvbiBUYWdzIChodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNhY20tY29zd2lkLykgLiANCg0KQSBj YWxsIGZvciB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIG9mIHRoZSBEZWZpbml0aW9uIG9mIHRoZSBS T0xJRSBjb25maWd1cmF0aW9uIGNoZWNrbGlzdCAoaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtbWFuZG0tc2FjbS1yb2xpZS1jb25maWd1cmF0aW9uLWNoZWNrbGlzdC8pIHdp bGwgYmUgaW5pdGlhdGVkIHRoaXMgd2Vlay4gDQoNCkZpbmFsbHksIHRoZSBTQUNNIEFyY2hpdGVj dHVyZSBkb2N1bWVudCAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy93Zy9zYWNtL2RyYWZ0LWlldGYt c2FjbS1hcmNoLykgd2FzIGRpc2N1c3NlZC4gVGhlcmUgd2FzIGNvbmNlcm4gYWJvdXQgYSBsYWNr IG9mIGZlZWRiYWNrIG9uIHRoZSBkb2N1bWVudCBhbmQgZ2VuZXJhbCBwYXJ0aWNpcGF0aW9uIGlu IHRoZSB3b3JraW5nIGdyb3VwLiBJdCB3YXMgZGVjaWRlZCB0byBnaXZlIHRoZSB3b3JraW5nIGdy b3VwIHNpeCBtb250aHMgdG8gZGVtb25zdHJhdGUgYSB3aWxsaW5nbmVzcyB0byB3b3JrIG9uIHRo ZSBkb2N1bWVudC4gDQoNCg0K From nobody Thu Jul 30 05:34:29 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CAC3A1118 for ; Thu, 30 Jul 2020 05:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 U0OLvW2n5Ehx for ; Thu, 30 Jul 2020 05:34:27 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 9B0993A1153 for ; Thu, 30 Jul 2020 05:34:03 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id j23so7593279vsq.7 for ; Thu, 30 Jul 2020 05:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=OQNLZL5SpaAeCbdspbB1oysYZfbo+apEEzLSqRrHcT8=; b=QCUcv0gTVL0rRKI6jCN9kAARr4gVOucH1UvzE83eUwvVwmP0rEOWNvlk0c0vl/JD0c 3vZuzUPAtlFJbm5VHooiix7Ag/F9WKPWBYIC8xJuWKAxQ82GR2SRK9fIDoRa16RysnDx rP7TykFay1xsoxyzcRTKoAuBsNuqCDPlH5OxhCjjQ+abrSmA/lpNkzpS0tkp75OYa/cf 7v8u1iZMJHW+HtZ1UAnnhGKBmufV6An/uGO1UNNLs/0MM0KhoJljTGMgV874WjRjak48 Xjhej7rWYiRRHIpi8DgnAZvKEQ4jHRfobImlJYZHiWbS9JrtDcoUSM5BiX+zBjfGHXGh ypsg== 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=OQNLZL5SpaAeCbdspbB1oysYZfbo+apEEzLSqRrHcT8=; b=H0qczQcV/M/A9wr0HWCoa1N4NYExupY+H/C1CjfwkKqrQU4507KykH0oIVLw467z87 +rmC0jpMJop4MJaiFTwJ/yYQktnNNS7D8l9Us38OMTNZbXpgWAfVMU6q48fGruPE+p3A YQDkQdRYGCXvuO9NKHMxq9zNm3wLk0admXpYxi6ccGcRk1FqYGesC6giWSX/W4BUN4+x TCnt9+vzZy1LVZGcNAyvNRSwciLa1sIVPuY8aiowsZvj8LInAai+QNxBxgXF9DldVKIa jTlBJUkbpdLy9oy0+TCXjkC2YRHUV1d2GsSCYgmNIa86RlLIH520YMnWr4KNRZY1j8Lu tuHg== X-Gm-Message-State: AOAM5326/K/MNmNlsVLFEpHPZlozchKLi8oI+Zl8t5dM0Wm4n0xwJPxu RZ3r2keWmffNXLy9kY4mHIVGvS0Dq/C0glxKTl9rXynH X-Google-Smtp-Source: ABdhPJxrHTAnsSInN3bk8dKu3WEf0PUj0Sei2fgnGMQjjVEeNIzvlxw6IagQOwJQ2Ia/Rtz6IjkPmWqW68yHe/OJleU= X-Received: by 2002:a67:e28c:: with SMTP id g12mr1549288vsf.31.1596112442587; Thu, 30 Jul 2020 05:34:02 -0700 (PDT) MIME-Version: 1.0 From: Daniel Migault Date: Thu, 30 Jul 2020 08:33:51 -0400 Message-ID: To: saag Content-Type: multipart/alternative; boundary="00000000000029803505aba7e30a" Archived-At: Subject: [saag] ACE IETF108 report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 12:34:28 -0000 --00000000000029803505aba7e30a Content-Type: text/plain; charset="UTF-8" The ACE WG met during this IETF meeting. The current WG document have been presented during the meeting and are making progress. - draft-ietf-ace-mqtt-tls-profile - draft-ietf-ace-key-groupcomm - draft-ietf-ace-groupcomm-oscore - draft-bormann-ace-aif - draft-tiloca-ace-oscore-gm-admin Yours, Jim and Daniel -- Daniel Migault Ericsson --00000000000029803505aba7e30a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The AC= E WG met during this IETF meeting. The current WG document have been presen= ted during the meeting and are making progress.


--
Daniel Migaul= t
Ericsson
--00000000000029803505aba7e30a-- From nobody Thu Jul 30 05:44:08 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852153A10D3 for ; Thu, 30 Jul 2020 05:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FL_h5LJhuQOk for ; Thu, 30 Jul 2020 05:44:04 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2051.outbound.protection.outlook.com [40.107.92.51]) (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 BA6253A0E13 for ; Thu, 30 Jul 2020 05:44:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hAtHGx9SMLEMjB3qWC09fj2MH1XFOd8xp3u+bN+wYKbz9OF+blumoJXNmkn/TzTIBYDQxynUoMv1+x8bbXTktCCfQ/kupRFiv1dph32m9Xhc/OS45wbiON72/q9w0dp4qkvCYvit8WCerAAMNyex4iSX9RpwgOa5wmycSRmRK6eqXEnCcSYFADjUcwNMR5h3S05DmSKXfF1vVJnmvB2r9U1cZgvNYfTdcTXAlKE41yZMOVlO4fR12A5LaImrvJrSjR67SOY1JefvTCsHKLY0laaEAdqhnyqWQn9Hm6U/Pv0T8POJb8nvYdwQw1J340omdjnO8KornjmvEk2tG432mA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Kq0AexTJtW4YMDMDDDTPJXI/5sNs6E4Y1bDTsjed7ZI=; b=neqiIAAMgM7BOz5/XRmJhYqFncqHSxwWksHitSrNNIVQ0VisO58Et+Cft2CcNcXBR4vPH9Sd74BE7YRc3fYNYxA/aU0uvOXy5MkDxWL17Jdfe5/hGVDI6FdM5rjfBBajAHzPMarvOiXOBm5kcBlpMSeHcLaNH+P8YP0PQPnkZi3GfV9cGxTp86xdSzqM9LqSZ/DlYQoNWZuH98QCXsH4U70opYcwT0bFqYtYPIfTZj+9O5kr17Dze82U2Xi2DdDOvQe5ijx4KDUDSxqyC2cePZ920co7BmakSIIkkueYT+I4M5rTACoWbrBHosUE0YPPtxbsoZoxSF8aZ/eZ6iXLig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Kq0AexTJtW4YMDMDDDTPJXI/5sNs6E4Y1bDTsjed7ZI=; b=zslVsoAcBBS8X7GPnT0wQIbZvldhVY145KXyRPyCDij784cVIykACFFeETTWLMzdWtP3AnOruq0lijR2QyHKjl2XjaO8B5Vq7gf0BXgJbE5ldRLwO7/iqeTXMM3RSrKFIidXuxQqWzU+tziVTmc4PhqScGisCHHgdMY5CX5nn6s= Received: from DM5PR06MB3018.namprd06.prod.outlook.com (2603:10b6:3:3b::23) by DM6PR06MB4716.namprd06.prod.outlook.com (2603:10b6:5:fd::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.21; Thu, 30 Jul 2020 12:44:02 +0000 Received: from DM5PR06MB3018.namprd06.prod.outlook.com ([fe80::2d57:9e6a:77cb:35cf]) by DM5PR06MB3018.namprd06.prod.outlook.com ([fe80::2d57:9e6a:77cb:35cf%9]) with mapi id 15.20.3216.034; Thu, 30 Jul 2020 12:44:01 +0000 From: Karen O'Donoghue To: "saag@ietf.org" Thread-Topic: NTP update for SAAG @ IETF 108 Thread-Index: AQHWZm8akX11adw8P0qrlCPHndzbUw== Date: Thu, 30 Jul 2020 12:44:01 +0000 Message-ID: <177F3F08-AF8A-4867-A010-B5CB70F172EA@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=isoc.org; x-originating-ip: [173.44.72.18] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bac3935f-0628-44ee-475a-08d834863c9a x-ms-traffictypediagnostic: DM6PR06MB4716: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yi1ZDqnue2eT+PtA1STfwuI3fn8WPcNecmSNMn+gZdbYKBXlX4pXFCDnpkpSHDMm23Wjj3bESvykbYLKJxk+CVmysQvSWaeZ5BZHb1Eq+KyagoE6SRsUwIPqbJFql5fEUa1gRuEEhbAaWALqyxUmjEWJIPwD5CzIVlp/8GHYA2huQ4mxd/dxMTZQLEbTXmCKpC4meO8NxhKEl2dQJhzqL+HiCtwccz6CoRZ487dfmn6Bn9RcP1ovyq85A0KhkHlmMr5pMvEGg0otWehSgsshYJIP+AzR54wW0xDio6B8nxNO+bBZM5+RxbQ3tRN13PzfHjmSzy4tw4DK0lc+Be43mzzetJjqbhPJcCeG0ndfxKXyojA1AWH2LwNdEIBz6shFGQ3lIB71LmiSBge4/2G2/Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR06MB3018.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(136003)(366004)(396003)(346002)(376002)(39840400004)(5660300002)(6512007)(4744005)(6506007)(6916009)(91956017)(76116006)(966005)(478600001)(8676002)(316002)(66446008)(64756008)(15650500001)(86362001)(71200400001)(66946007)(66476007)(66556008)(33656002)(8936002)(6486002)(2616005)(26005)(83380400001)(186003)(36756003)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: HSiShRwxbAZBNJpx6qAfv9OE/G27rEvjSiLF8e7vHyQOm0m25+l8NGkvJJtY9UNlHwxQv1+GwNt/J81+1IYO1n1Htct/zlvzy/J0Dzkxa9+kWqIDC6oPbjn22rqmIvEUBVvxU8GGEsvzbiqfvzkt3L4LywGMASboKLNpzHaP0qpUk82xAQX25FPZnBQXlDcYznTK7WW+7aZRyiFU5IK8VmSX/u/2H3hmPG+PmhMZffSSq8MV3bgyrTCmSBiKck72j+CUgj01YvFkELUVjUYA7Jo9DNYSKabEEEDWQtKiHi9pRQ/UTXrhs9h9dt85WT2Imi16jPpz5C8Flb+tUCvbMtFJsLRzx3gi0j3kkOEKOIwaavo73b6B01J8GeRBeGYNVQlOiPbr86yOdFueyp8VqMvYsYRA913GQ781I9C2lqOKWhQEHh2zxD2fTmCyscreucMLJcyb3r1CsOuwU8FzPI/V2gcwtukN/Ve6eHyuR6I= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <15CCBBF163BAC54EBF066C74DA1EB410@namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR06MB3018.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bac3935f-0628-44ee-475a-08d834863c9a X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2020 12:44:01.8521 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: neAqca9DqLxlltAEfJXIR6Kz0AkA58m6DaUii6GFJ0uLaW9O116wNl8TV22uRlZbqV0aAGhuKqTgesWDz5XIdQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR06MB4716 Archived-At: Subject: [saag] NTP update for SAAG @ IETF 108 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 12:44:07 -0000 SGVyZSBhcmUgYSBmZXcgc2VjdXJpdHkgcmVsYXRlZCB1cGRhdGVzIGZyb20gdGhlIE5UUCB3b3Jr aW5nIGdyb3VwLi4uIA0KDQpUaGUgTlRQIHdvcmtpbmcgZ3JvdXAgbWVldGluZyBhdCBJRVRGIDEw OCBpcyB0b21vcnJvdyAoRnJpZGF5LCAzMSBKdWx5IEAgMTEwMCBVVEMpLiANCg0KVGhlIG1vc3Qg cmVsZXZhbnQgc2VjdXJpdHkgcmVsYXRlZCB1cGRhdGUgaXMgdGhhdCB0aGUgDQpOZXR3b3JrIFRp bWUgU2VjdXJpdHkgZm9yIHRoZSBOZXR3b3JrIFRpbWUgUHJvdG9jb2wgKGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbnRwLXVzaW5nLW50cy1mb3ItbnRwLykgd2Fz IGFwcHJvdmVkIGJ5IHRoZSBJRVNHIGluIE1hcmNoIGFuZCBpcyBpbiB0aGUgUkZDIEVkaXRvciBx dWV1ZS4gDQoNCkFkZGl0aW9uYWxseSwgYW4gZXhwZXJpbWVudGFsIGV4dGVuc2lvbiB0byBOVFAg aXMgb24gdGhlIGFnZW5kYSBBIFNlY3VyZSBTZWxlY3Rpb24gYW5kIEZpbHRlcmluZyBNZWNoYW5p c20gZm9yIHRoZSBOZXR3b3JrIFRpbWUgUHJvdG9jb2wgVmVyc2lvbiA0IChodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW50cC1jaHJvbm9zLykNCg0KRmluYWxseSwg c29tZSBpbiB0aGUgc2VjdXJpdHkgY29tbXVuaXR5IG1heSBhbHNvIGJlIGludGVyZXN0ZWQgaW4g Um91Z2h0aW1lICggaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1u dHAtcm91Z2h0aW1lLykNCg0KDQoNCg== From nobody Thu Jul 30 05:53:35 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 853233A10EE for ; Thu, 30 Jul 2020 05:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQtzI4iRK9j5 for ; Thu, 30 Jul 2020 05:53:32 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6DA3A10DC for ; Thu, 30 Jul 2020 05:53:31 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4BHVhV1bdNz3MJ for ; Thu, 30 Jul 2020 14:53:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1596113610; bh=Pe1A+hqeNy8gdzT6bPoHhRJaLtUxOoVUNwlhowrOq0s=; h=Date:From:To:Subject; b=fqRtOUdxTjEgGb1WQr+/0MR4AzhtuvwnWndrrFO8l8qxlNdJIOOHxRcsocAmtxL+4 bQc1+GOcbh3+I1x6pOk8w1BQ9qSgYWZmtA7YWmOaV6ft3jPL7DH55pe4pKYn0QZmlD k1WFWP3kML50jaCk0lswvjEWdSzytRM+++RTW4Ek= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id EOTWc2YJokrL for ; Thu, 30 Jul 2020 14:53:28 +0200 (CEST) Received: from bofh.nohats.ca (unknown [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 30 Jul 2020 14:53:28 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5413B6029A37; Thu, 30 Jul 2020 08:53:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4BEC482C94 for ; Thu, 30 Jul 2020 08:53:27 -0400 (EDT) Date: Thu, 30 Jul 2020 08:53:27 -0400 (EDT) From: Paul Wouters To: saag@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [saag] Trans report - did not meet X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 12:53:34 -0000 We have not met for a number of IETFs while waiting on clearing the last DISCUSSs on the 6962bis document. https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis Paul From nobody Thu Jul 30 10:20:56 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EB63A0FC2; Thu, 30 Jul 2020 10:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 ar2Wo0bj2MQo; Thu, 30 Jul 2020 10:20:49 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00067.outbound.protection.outlook.com [40.107.0.67]) (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 DC0AF3A0FC0; Thu, 30 Jul 2020 10:20:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N1o2HCsufFKKYJEhvjS3XzmRk0kNmTFXnszG5WNg7KCgk2ieLJhBxWWaSwmDM0Iy5GNYlSCSUNRwmwC7HErrZMNdS8ad9as7CA0dwzc07oFVjBJxGL1mX3+6ZRe9JAM36LgJDHFSLJFOKLuerZwOVVY+0OnEGlBhjS/D27HbGLqOUWWe/2H2XVkw8JhTLMgonAMKUOFjyoVU7U3O7fbj7VJXm0ILIGyBtXZB1BXi3zh36Z7PphhrA3pvx4xpeEfHCo3LikM0k+xJxfGcY/nlCan5D8235mlP4uS9MJR2sCjFqo9dG12ZlcgKulT70rib+LZ0fZZLoUU1pa/G+Rl+EA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kt5uG5IrbN7GrcKtQa5SeFtXcIsgLyCzkp4Y05msDO8=; b=iu8HATNQknnJ9zP06zxMBb/GO2wuwNM9gPh39MEEc2ao7Y4IV+Sr7goGZ0V6W+cy3nUoQaiQuTbENvKRUSbp5/fqIXrizxTGNQNKe/yB+Q58eoNhoOVx1StKl4B4EsB4QSwMDb0oHuFIW8pm41aiudb2LV4pFYpAXqqCBk9bD3Ov7/ZYjHqI8OwFCXBVmlAF4b1ACZnGB5fg0PBjGHociwJqpL1yzQAUyehCzWFvaSaEQL1rrMIiXKmahFe/mfluh0OQB+mJLFiTMDCCIdECDGimFz4KZCPmSZ3cKnSfpidNoR5ppxcPCm0oYpO3CJLKLl19cKTIAEvS+s3UifcqTQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kt5uG5IrbN7GrcKtQa5SeFtXcIsgLyCzkp4Y05msDO8=; b=dersTqV2EV0cbfmjipW/O41hDK1JSj62WUtdWGpylCFLjZ2VjTIlJFuYSvYEDi+RVnM3/i+Eik82BT4Lrie7a0IEcrvMJP/7wyTHSRWTSiKs/JycK36E03wuknRVwxI7QSNV/v/iPl8b+zZ/U9ai8XhmJE85aocv7MNmkY9yMnI= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0701MB2332.eurprd07.prod.outlook.com (2603:10a6:3:68::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9; Thu, 30 Jul 2020 17:20:43 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f%7]) with mapi id 15.20.3239.017; Thu, 30 Jul 2020 17:20:43 +0000 From: Francesca Palombini To: "saag@ietf.org" CC: "secdispatch-chairs@ietf.org" Thread-Topic: SecDispatch at IETF108 Thread-Index: AQHWZpXBn9mCUaOD5k+duMfwg9K/YQ== Date: Thu, 30 Jul 2020 17:20:43 +0000 Message-ID: <47C264DC-D59D-49E8-B087-BAF0E23527DD@ericsson.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [79.12.182.121] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2a248d91-b2d0-4937-b2fc-08d834ace3f7 x-ms-traffictypediagnostic: HE1PR0701MB2332: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qef2HvalY/l+2v1hsEvi1K9fgg/oNp3GFqDErtcKayvi8VLHbgmJSYR9RBDJ5RQUvgsGmn7ejNaIp2Vxe8dT2MEnqzavhbRi6tDZahzuGwdJYe30MrVFkpbaM+x7qz7z6CIakOcESx/fyYztmkXzGuJol17kA+tHZJ4jCCMlhjqrW8GfHFBUFyrxq/iSW0j/M/Rau/Ze216Y0oD5OGCAru2BnKIofuVGG5QNe3NaYCoPy5QxcyDkqwrrqA/TxaHBTc7tE+y1bVs+/jpn3RLwN7dTsVfdQlv53K1I5kvPofERNhAvUqMvxrOib8X0CyvHOKeLtrZGfXQ0DdPvRxu5LwZoRWCa2Lkm48miDa2X/7i1zasnW8CvIAvopq+hIz7/x3maeygIfjjCLCQs1eWCdQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(366004)(39860400002)(136003)(396003)(376002)(36756003)(5660300002)(7116003)(6512007)(450100002)(966005)(186003)(6506007)(478600001)(6916009)(26005)(44832011)(83380400001)(4744005)(2616005)(66556008)(71200400001)(33656002)(6486002)(8676002)(86362001)(8936002)(66476007)(76116006)(316002)(66946007)(2906002)(4326008)(64756008)(91956017)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: f5QPRugGJeeHACNI9xuVwMx/e4MnSr2triCKdO/irM+LcG6nXdes64s9w2PcHtPCPamTFhXB62cyB7SzjeK9zKBUEztQTJr1+0BdtQiZxrifbCm6f1pTkr6EG1cPBhwQwP2CJPTN5Q3yaD08C5ow54uep4LqRi8k+A36H7VUtQFaYJCvtgGN1waaG9WROLtAW/9D8bUJA5ktd5Uj7aygdWLL1nEJB23noLeAOzfs1FzygaLmRiEZSRCwXZt4v8/9aqo1h+si4Stx6FaBKjzrmragL49za+JOKVmX8mSTZp+w+jUA4Cvsug4/JWqg5a5h31QOrkRHowFwYPuQUqir2LFY3RTvuXHzsR/UOtJgX0zHiuASSnzhUdsRtTb1sO76ivw0FIrdR0cakeuwXX+MoT5ZezTERkI5QMkZVhRTz7UxfYk0nH2ooxw2vLqYB4XW41qoQCw6BVwRSV2S2vi1l8/KDJ6rFQs0bjulXuccDHp6zg/lIleljm2qFkDoq2QLNeysTY8Uw+eirPXzlXqsKFTPUvhO/TRTgjfg4rs0Al0aTYo0loCH4ayrfTqxjyUjtYWQH5vB2OExAVnyEtj9DrDOQLd2PwnEBxSQZH89kVW0IiaPtTzR44PMwMewL9ldGSHzgB23q/+7q5LnO6v2+Q== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <3D927400D8E77F44BAA95387BEC91A2E@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3818.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2a248d91-b2d0-4937-b2fc-08d834ace3f7 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2020 17:20:43.5606 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 81Myk/qyQrtC/T/1zIL/SaKPXF0MI7NxpSYqaoQYON5zxn1OtP1/r1iSVW6jZDva1N5J5JiiW+mX4JKoniMFN6Renz7lw+dFkOEL/R37COhNc0RDJS81ZrtfBHgHiO/Q X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2332 Archived-At: Subject: [saag] SecDispatch at IETF108 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 17:20:53 -0000 VGhlIFNFQ0RJU1BBVENIIFdHIG1ldCBvbiBUaHVyc2RheSBKdWx5IDMwLiAgVGhlIGFnZW5kYSBp dGVtcyB3ZXJlIGRpc3BhdGNoZWQgYXMgZm9sbG93czoNCiANCigxKSBJRGV2SUQgY29uc2lkZXJh dGlvbnMgKE1pY2hhZWwgUmljaGFyZHNvbikNCiogc3BlY2lmaWNhdGlvbjogaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJpY2hhcmRzb24tc2VjZGlzcGF0Y2gtaWRldmlkLWNvbnNp ZGVyYXRpb25zLTAwIA0KLS0+IE5lZWRzIHZlbmRvciBpbnZvbHZlbWVudCAtIGdldCBtb3JlIHBl b3BsZSBmcm9tIHRoZSBpbmR1c3RyeSBhbmQgdGhlbiBwb3NzaWJseSBicmluZyBpdCBiYWNrLg0K IA0KKDIpIFN0cm9uZyBBc3NlcnRpb25zIG9mIElvVCBOZXR3b3JrIEFjY2VzcyBSZXF1aXJlbWVu dHMgKEJyZW5kYW4gTW9yYW4pDQoqIHNwZWNpZmljYXRpb246IGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1tb3Jhbi1zdWl0LW11ZC0wMCANCi0tPiBEaXNwYXRjaGVkIHRvIFNVSVQu DQogDQooMykgVGhlIEdOVSBOYW1lIFN5c3RlbSAoTWFydGluIFNjaGFuemVuYmFjaCkNCiogc3Bl Y2lmaWNhdGlvbjogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNjaGFuemVuLWdu cy0wMCANCi0tPiBJZiB0aGlzIGlzIHRvIGJlIGRvbmUgdG8gdGhlIElFVEYsIHRoaXMgc2hvdWxk IGJlIGEgQm9GOyBndWlkYW5jZSB0byB0aGUgQURzIGZvciB0aGUgQm9GIHRvIGNvb3JkaW5hdGUv ZGVjb25mbGljdCB3aXRoIERJTlJHLg0KIA0KRHJhZnQgbWludXRlcyBhcmUgcG9zdGVkOiBodHRw czovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy8xMDgvbWludXRlcy9taW51dGVzLTEwOC1zZWNk aXNwYXRjaC0wNA0KDQpGcmFuY2VzY2ENCg0K From nobody Thu Jul 30 12:27:26 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8763A0B8D for ; Thu, 30 Jul 2020 12:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 vYrsEFPXgLCV for ; Thu, 30 Jul 2020 12:27:23 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 060B03A0B88 for ; Thu, 30 Jul 2020 12:27:22 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id j23so8309035vsq.7 for ; Thu, 30 Jul 2020 12:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=6ds/1G9sc98Ae7orxiovdxb0xYXZiWy1zMgTE1YjTbA=; b=feluOpP76WoDqUynKxMrgH3RT/t/XIqMUhaFIKMyDZqInaRdC/iPXsss8kMpLzurgq MSGNYLeej+mM0s+tosI1Xsa19/LkIXNZmK92M+yrJdjz8Pn6Ms5oGKqVqisRCWoKoNHA HEtN6yt3xbmhIUmTcMYI3koY4th6F9aw15Ks8b1kjAnJDMYFIxQFB+brxxRwjp/4KMDd Qr/6RnTKvYhLUONpsiwOQjKr1TaNZBAnmKg+12s9ycUK7LbrJO35DGMS0S5tIDziIcJI hNv4enBMFWRHQ0wbNTtwv6f2hIptNhLLGZjWBhYGpgHNpXp+dPWbmwOklWIsu23WQslR 9BAA== 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=6ds/1G9sc98Ae7orxiovdxb0xYXZiWy1zMgTE1YjTbA=; b=pgTLyzeQhUK2wvCMjz/9ZAGBw1goa7JXZA1gxCD6h1JQ3zICmo1IqvykZq1tuB6qio d3sfUj+B4Pljl5Cd4EJLsHPQgPmeZZ9PKyqxXbnmo//viIsiPo91+iWOFomIpMASbTTO XXVvUOnCJZtQIKhypFz8F6a843F5yLPyUpeiMlgEG/DYwBwUpv6/iBgZCu3FKkAoCLu6 f0Xtx1K8/Gpjq4P50WfcAwUCstM1uVk9S6nT4n83TVDN99KfZzjXFGQqYHmHQ3ACoViT rgitMsIEiNUejBE6GxZbNQ5DmP8xjFpl3MXvVqDsUpbpC8JBfmFK5cHtSdgi4WxdLX4X JT4A== X-Gm-Message-State: AOAM532rLQgn4Am08WbXafvt4rWV3rLNlfjxv6aJbSi105kTU7mlxeho f4xQamkl0+mIEj+0rNpDB/drcAd0Y3aedb9XC1rnbcW4 X-Google-Smtp-Source: ABdhPJwwykOdsG1MRM+imE62fOEYOBoNapNU8ySoVPvEDh+Imv7yoObzG/MSkceBXgHnBFpwxEa6xMgiU0ZPD49fN7Q= X-Received: by 2002:a67:e28c:: with SMTP id g12mr750182vsf.31.1596137241711; Thu, 30 Jul 2020 12:27:21 -0700 (PDT) MIME-Version: 1.0 From: Daniel Migault Date: Thu, 30 Jul 2020 15:27:11 -0400 Message-ID: To: saag Content-Type: multipart/alternative; boundary="0000000000004e158305abada9a6" Archived-At: Subject: [saag] Pining and PKI X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 19:27:25 -0000 --0000000000004e158305abada9a6 Content-Type: text/plain; charset="UTF-8" Regarding the pinning discussion at saag [1], it seemed to me that pinning was mostly seen to come with manual configuration, limited to CA or end entity key. In addition, pinning was also seen as not compatible with PKI. One reason for pinning is to restrict the possibilities for terminating your session to a place you do not believe it is. If you assume that your first connection is terminating to the right place, pinning can be viewed as providing means to be connected to the same place as my first session. Trusting the initial session based on PKI enables to automate the configuration of the pin. Pining session rather than any configuration parameter prevents to interfere with these parameters - such as CA change or server key updates. Using pining as a second factor authentication also avoids any interference with PKI authentication. These are some of the motivations that initiated the design of RFC8672 [2]. Yours, Daniel [1] https://www.ietf.org/proceedings/108/slides/slides-108-saag-chair-slides-pkipinning-bcp-72-00 [2] https://tools.ietf.org/html/rfc8672 -- Daniel Migault Ericsson --0000000000004e158305abada9a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Regarding the pinning discussion at= saag [1], it seemed to me that pinning was mostly seen to come with manual= configuration, limited to CA or end entity key.=C2=A0 In addition, pinning= was also seen as not compatible with PKI.

One rea= son for pinning=C2=A0is to=C2=A0restrict the possibilities=C2=A0for termina= ting your session to=C2=A0a place you do not believe it is.=C2=A0
If you assume that your first connection is terminating to the right place= , pinning can be viewed as providing means to be connected to the same plac= e as my first session.=C2=A0

Trusting the initial = session based on=C2=A0PKI enables to automate the configuration of the pin.= Pining session rather than any configuration parameter prevents=C2=A0to in= terfere with these parameters - such as CA change or server key updates.=C2= =A0
Using pining as a second factor authentication also avoids an= y interference with PKI authentication.

These are = some of the motivations that initiated the design of RFC8672 [2].

Yours,=C2=A0
Daniel

[1]=C2=A0https://www.ietf.org/proceedings/108/slides/sl= ides-108-saag-chair-slides-pkipinning-bcp-72-00


=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0
--
Daniel Mig= ault
Ericsson
--0000000000004e158305abada9a6-- From nobody Fri Jul 31 10:44:49 2020 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0DA3A11CB for ; Fri, 31 Jul 2020 10:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 ye_-D1EQH-gi for ; Fri, 31 Jul 2020 10:44:38 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80043.outbound.protection.outlook.com [40.107.8.43]) (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 54B673A0C52 for ; Fri, 31 Jul 2020 10:43:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BAeR3fgM4uyha62kPb32bjxPfO46NL/Qp9or+782TQ/T+J7t8gvK/qI4gC9eX+egu1MI0MvROxqrEm4HZR+SyvokwOW1GWm2LQM2ao4/2zKPAulsBcg5VIwjvejxa2xPKC+uMV7AnsWz/ZQExyt1zaWmV5PWQ4V+kli8uPeGfHHJyNgsmbwPj2br8Q83saN2pcAC5cYD/LLKcUJqADU2G01G5jYXd7/JpZB0bsTeyP7qY/KRBdGBdg6SWziQuz1JTM0KHWGzdiX3i0WDhqNTWNdVHyFWquHkxO6jzJRP1AoPffUbd6f9iOpAqKTiPz7s1OZxySSA4JTa3EadeSoLcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/PKGxvu7cc48JZA4KSKqXre8SB80bc2jb3AQVVQeDAk=; b=Kl83x72rJICqvoN1Z9M8zlihxY5K463yU7CMNYqZiR22YUIFYrIx6AY04b/fF285j4J5r5fPsygx2scUejqzgBEmCaY2WO4poxwaqSf4aWv92VxaDwOvV+oX/d046HMgOmA0pL/AV3ja6jnVftj8i38yBSkL8+5hDZ3NZJtWECXIrFyx91EBXykRbW9u2xEPncJ64SXWdw2Hi+kifD91K5z1slB9/k7EwgVAhUFuK7sKdQ6NZBcgx4ndVrdiKq+FK1FZhuza+HIAgCInkBxxVgMJJZlh7dRl8gMcwMq24MiWSCSD9luqz2As6m4Z2xb3BwF6GNPN3SRxXLXNWrqptg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/PKGxvu7cc48JZA4KSKqXre8SB80bc2jb3AQVVQeDAk=; b=p9HDOZdLeCgrxF7sU9W/K3dfooTwFVxVOiZ+5aljMHKk7PabN6vT+FOIGRtZcyVqGeXu0zfiY25FFdLMDtnEG3dVfIuged96i8Gau1T0om8tEc9orZMBZYRODTA8Bfsw7X579bwEWDuRR3dTHr9WYZl+YkxeX6Bx3HIN/X5aSGA= Received: from AM0PR0702MB3713.eurprd07.prod.outlook.com (2603:10a6:208:19::10) by AM0PR07MB6258.eurprd07.prod.outlook.com (2603:10a6:20b:155::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9; Fri, 31 Jul 2020 17:43:46 +0000 Received: from AM0PR0702MB3713.eurprd07.prod.outlook.com ([fe80::d1f1:397c:7240:92f1]) by AM0PR0702MB3713.eurprd07.prod.outlook.com ([fe80::d1f1:397c:7240:92f1%7]) with mapi id 15.20.3195.030; Fri, 31 Jul 2020 17:43:46 +0000 From: Mirja Kuehlewind To: "saag@ietf.org" CC: Dave Plonka Thread-Topic: Joint RIPE MATWG / IRTF MAPRG session next Wednesday, Aug 5, 13:00 UTC Thread-Index: AQHWZ2IjEnTfCE28zEq1jfw+oWnpEw== Date: Fri, 31 Jul 2020 17:43:46 +0000 Message-ID: <19AE38BC-4B79-4BB1-8B32-F6AC641BF804@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2003:de:e700:7a00:58fb:54b9:2185:2a13] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ebe2a3b6-e632-4f11-ba19-08d835794698 x-ms-traffictypediagnostic: AM0PR07MB6258: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sA9g5n/9bEnmCa8rkxG3I90HcZJ2EqP8+IjxGGpvd2UsTLhaF64EO/NQ5zQbNm5YEqG8A9sTphUcrTK+FMriInh95Fq/N9/stOMV9iWGST5Cal3sG5J/xgE+fWXxZk5gY5Ro9YEGP+sCx2MUhVoygstwEm5atL1SfqJQ9LW8MMfolYz8Fm9Fg48Jn8Q5BBhrvC0Z8+Hm11rpR3go/kB9A35A2N1KFGhyJMPWNj/l4OWmB3BT07DE0WjGy1JZkNysqzuIz2oaT/49ksSAG/8HNFsJbLxGnhD3q9On81y+atQ+BTPw4i6O4EvRU4Lwi3tnEtUSYpgLEVtGlbITz6Q/qKeQxR3+YOYA/gXzaAEq4+h80ulPfPefTZpfq5OquRgDunYvItXnNTWifnQGo3jxtw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR0702MB3713.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(136003)(346002)(366004)(376002)(6916009)(8676002)(8936002)(5660300002)(4744005)(86362001)(66574015)(4326008)(6486002)(33656002)(66946007)(66476007)(478600001)(76116006)(66556008)(66446008)(64756008)(83380400001)(2906002)(44832011)(6506007)(316002)(186003)(2616005)(966005)(16799955002)(71200400001)(6512007)(36756003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: okzn0XryLvt+L6aaX1+QQAM/au6wdrXfWURbzG+GpXAOOwfPTxn18bnV1CU2W5UboDQLy/oeZnKisfQdi0g0k8YERanNNKk0qexym8HS4byL5ec4tfiITOkW83T+Nkpr37bG+UOgGC32wjWMSp0Xy3rEBoG6E/C8t79lXI366hoc25R46tTWqqmm3NXhTHJdZhLThMP1fw3ELe76ZOaQ1fV5yBoPFdcXdUhuIRo64Flj4fhpLpmia1eV46Uvo/UFPwScl5ekR7aryhRJuNHak/Ljw4vTIQ0SVWI56kRhr8Z6WvtOqRHie9T4vQ7az1+txsiJYDcfEuXF5NA2GrW8o2RLEHcitg1pbd200FjvPrgGE48ShjBxNp9CSYZisXcMacLA4Bpx6NNMk2DvVpaWvFp/2Trn/42XiB/kU0/kLtomy5c6hLPam9nOnE6fYDcK5iJozhvNHhHvy9txj9ShqGE6ShT1IPDUwicySE6s25sBLefCOILv8xWnENO51dwnIQGewaq8pyfhzTe8/+1rfH8LMCb/qBoqingA/LO4eAitCsuY9uVqAN3Cw8o9pHN6/am5uTeEmPuIVzRP0BLdekUMloIY3h4XsxaNRl7Qb2ZopSmhYrDE5fiNPdfbzdKoJ2QXFy4OOZzPIkkEDkK1lpINdoUVLv8o38buG95nWQRQmHCDrKAcSCSWl9VdGfLTvrcazodLpyB68iThWFNF6g== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR0702MB3713.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ebe2a3b6-e632-4f11-ba19-08d835794698 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2020 17:43:46.3554 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jDvW+YLy/g69o5h58MAzuHe5HTAfEhkdw1Gj3DaMjtHA5dE3cgeJvJnU74/hx3HMyPT7dD7DIeknL/IcmuGUt8tGzMeDYhFoGTSXuYeY3c4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6258 Archived-At: Subject: [saag] Joint RIPE MATWG / IRTF MAPRG session next Wednesday, Aug 5, 13:00 UTC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 17:44:48 -0000 IEhpIGFsbCwNCg0KaG9wZSB5b3UgaGFkIGEgZ29vZCBJRVRGIHdlZWsgYnV0IGl0J3Mgbm90IG92 ZXIgeWV0Li4uIHdlIHdpbGwgaGF2ZSBhIGpvaW50IFJJUEUgTUFUV0cgLyBJUlRGIE1BUFJHIHNl c3Npb24gbmV4dCBXZWRuZXNkYXksIEF1ZyA1LCAxMzowMCBVVEMsIG9uIFdlYmV4Lg0KDQpUaGVy ZSBhcmUgYSBjb3VwbGUgb2YgdGFsa3Mgb24gdGhlIGFnZW5kYSB0aGF0IGNvdWxkIGJlIGludGVy ZXN0aW5nIGZvciB0aGlzIGdyb3VwLCBlLmcuOg0KDQotIFRleHR1YWwgQW5hbHlzaXMgTWV0aG9k b2xvZ3kgZm9yIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIFNlY3Rpb25zIC0gTWFyayBNY0ZhZGRl bg0KDQotIEludGVybmV0IE1lYXN1cmVtZW50cyBvZiB0aGUgQ09WSUQtMTkgcGFuZGVtaWMgLSBF bWlsZSBBYmVuLCBWZXNuYSBNYW5vamxvaXZpYywgTGFpIFlpIE9obHNlbg0KDQpIZXJlIGlzIHRo ZSBsaW5rIHRvIHRoZSBmdWxsIGFnZW5kYToNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvaW50ZXJpbS0yMDIwLW1hcHJnLTAxL2FnZW5kYS9hZ2VuZGEtaW50ZXJpbS0yMDIwLW1h cHJnLTAxLXNlc3NhLTAwDQoNCkhlcmUgaXMgYWxzbyB0aGUgV2VibGluayBsaW5rOg0KDQpodHRw czovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tODUwNmY5MWQ1M2ZjNzY5ZjJhZmFh YTgxYzkxN2MwZWYNCg0KSG9wZSB0byBzZWUgeW91IGFsbCBuZXh0IHdlZWshDQoNCk1pcmphDQoN Cg0KDQo=