From nobody Mon Jun 8 18:41: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 725B83A08EC; Mon, 8 Jun 2020 18:41:46 -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=RP8jzjtG; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=UI/90lLL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrZR06BMJb3A; Mon, 8 Jun 2020 18:41:44 -0700 (PDT) Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.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 4A8323A08EB; Mon, 8 Jun 2020 18:41:43 -0700 (PDT) Received: from pps.filterd (m0170396.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0591dHCf030968; Mon, 8 Jun 2020 21:41:43 -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=hsQM+tM+W1oypHMVxvId9nnnZr32DVMFFoaIGaLvRpQ=; b=RP8jzjtGDyejH1GSzMsrjoh6YMNbrciQ+qXxXXAMW8RmiEt/Cly5Pyp1KXcYOO1Md56o hCYQ1WjexafD5/ylArMwMgZ7Ws73fONb7qo3dAIZ9M6oXkZL2kJcDPgPgw559LMqi1TH bcRg9tmx9ugjCkO7XTnhCF7APwuU1RtKIyUT4eT4nCCwFi075duwXpsLHSWygJg+RvFi kbY7SfuxLEHztlsg+rNXs3Bs8aUqRiQUPOwWNpPtf34YhhUc2h70+jNkVM+blo3HOnFx 8lUB0OkRWLxybwvq7WAytRU7fVjzZOvT5hUyyv4Ic+N4vx4Dul30RzkkGxRyvPkMEODa 9g== Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 31g6yxxv39-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Jun 2020 21:41:43 -0400 Received: from pps.filterd (m0144104.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0591btlY144287; Mon, 8 Jun 2020 21:41:42 -0400 Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2100.outbound.protection.outlook.com [104.47.55.100]) by mx0b-00154901.pphosted.com with ESMTP id 31gft4merh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 08 Jun 2020 21:41:42 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TI6xxfJhL4TYTaYw7W/lytXiDP3dcCs8jNBztoqbQfuLfVDqtbnSNPn0a9EnjIItdxtZPIZDJs6MOv4XvQhaqnyj6GNDPVpHK5zUdX1JnvPY5dmCkeCr3kWcd3C0e8gRqSOwZAXawUi0d7LgCR2LuYknk9RLUUg1crgYughththKLnlPA1ItqmlsuJNknswqd4IOHNqIMh56T9ddD6awbPiWdZXPE8CcN27iog5YfKlsGlNyP8WwiEgvHMJK+SAlD3FNg/I1lPQWySroZ2JOGZj7pXwu8H/083T8QkMK856KE6zu+VMOIdMQ8WsAwinbFpehZafWvnoYymVjsRgzBQ== 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=hsQM+tM+W1oypHMVxvId9nnnZr32DVMFFoaIGaLvRpQ=; b=n0ZLQdHoP1qQOl9cE8XNjEP0XhZ4kOTcP6tvo8yxErJTxMXxTiu7zyY8qfChkUZENe7DY2mgq8KpG+799Dbzp7SEVdA/VINlU6UWcH4f5K1MAmFtkS0bcZs5NBkei8ttAiwlWK000S2cesDzfHBK3FrFbEopsORmWfTlDyP31yFagstq9is5fuoJQYbcYzCCtkAvKruqmz7nLBwZwiOjZp02te+o8D7RmpD98I4hnjb5vG5XPcriCtfaKFkZBQu+H5m7b0QKbVNak9juathm5hkdV3HmLUkbLsOx10x0RmGQF13i5bCyyiAt3H1tsqtgaLEB9wxw+bpzWI4FoPu1Aw== 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=hsQM+tM+W1oypHMVxvId9nnnZr32DVMFFoaIGaLvRpQ=; b=UI/90lLLkJhZRcYYCa58TXPNr8HSHZ5iK4NTgZ66Ggrw1P1pjhuZyholRw2yCltlM7wyRepkBXB8g5QWt4QfpYTO2nwvkbiX+kHjquuxjtldPC+BHOgHTxc2n9plkDgcqhDiF7NGZX7HdVcLtjvXvbjKCbitZNs9AlvuG90kKvQ= Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by MN2PR19MB3007.namprd19.prod.outlook.com (2603:10b6:208:108::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.20; Tue, 9 Jun 2020 01:41:40 +0000 Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::3574:5511:eec9:567]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::3574:5511:eec9:567%9]) with mapi id 15.20.3066.023; Tue, 9 Jun 2020 01:41:40 +0000 From: "Black, David" To: "tsvwg@ietf.org" CC: IETF SAAG , int-area , "Black, David" Thread-Topic: 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 Thread-Index: AdY9/kL5KQoLk/CbSKeZ9xMZ8uq3SA== Date: Tue, 9 Jun 2020 01:41:40 +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-06-09T01:13:48.9131894Z; 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=75fd0d51-f741-4e65-9459-4a66bc578de9; 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.210] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0e8b9b76-407d-4de2-79c7-08d80c1641b5 x-ms-traffictypediagnostic: MN2PR19MB3007: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4 x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 042957ACD7 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ljpVd6AnCpgtwZre/kDI0H3v9JKTHr2ffSM08jYhWTST48vrteMOYLukROTOwiG3+QIo9fDrgAv6ZlPW2Y/ao/dS97kRlSIxkml7utvDoUGbFo5NGuAdCqoECu67y9qOIdeTpgSbtHE0YVHG6UUvhCaXXpms6uNhzcF3cierQFasJoU4DyPKSaksizQP8OSOhbklTXJkoYKgOZnrHTHFTlB/7aNpGYxOxZBOIxrgVLWhQen//HSVPBZgBLzVmUwTCgSRbKKTexBVQITaSHUovkyvP9vI+dGmNqZQBkEOOI+SZucjNT4Q6OGZkhKNgNlpT436rxyJ6GIVKOTSpufX9EIeTcdFLqtIFctdd/CsgJAAOgXgW7qsciS6/B65k9wkB61FOLUkSSd7RyoY6I3ILg== 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:(366004)(136003)(39860400002)(376002)(396003)(346002)(5660300002)(7696005)(316002)(2906002)(786003)(8676002)(52536014)(8936002)(33656002)(107886003)(86362001)(450100002)(66556008)(54906003)(26005)(6916009)(186003)(6506007)(66574014)(64756008)(966005)(76116006)(66446008)(66476007)(66946007)(166002)(4326008)(71200400001)(83380400001)(55016002)(9686003)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 1BonpJP7XWdPAYN/RvoZorRdGmtwAI5F14x3tqzo1KhTQRLC4946cw6zv7sSfJUWcK0NhwhqZ76KERIPhnNMrmwLQj+/JHVs1Lp0jPEgLdrM7FYOoXQNunUhGuk/i50pfnRDkIA/mpfH8jSL0PrCoNseueziSIl/BTGP12ng0m8TVZp3iK/MkeBx6Y2EOJsgR8BZjsLMn3xxQWHQwNV5cfKhvoB6W5DBqWizG8SwX0khWipGDMIa0nV7axDoi6q6GeK8LnpZCA+7HzAvQyBc/ICFFhjOEFkU3dBYvRy4KNsQD5FQfxsN++bF2xtco3ABmIIwKMTLK2OXx+7550spKmsVrLiVx1qXqjs8WHITZlImsIhNrtguhBRkaz4vpCWgMY2pf7uDSmx1jO5ZCRqWYHtbhAD6Sf2fqekwevEssUeoN7wdlNpDnEovIlJa7/t5BCERDxQG5CIZzQSvi130bjFI2QGvnwL9/mPK/0STsrTIKxMpTjLN4G7rHj2eyLiV Content-Type: multipart/alternative; boundary="_000_MN2PR19MB40450EE357BEECD723AB06F183820MN2PR19MB4045namp_" MIME-Version: 1.0 X-OriginatorOrg: Dell.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0e8b9b76-407d-4de2-79c7-08d80c1641b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2020 01:41:40.3026 (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: TwqSOq/dJODP0NbRQI3AWFfsEL17pVTr8HMDbzfLizhRZIsVT+lrgxFIxOj88nABHVUY24ZlVZ/Kd3sKsbeGwg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB3007 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-08_18:2020-06-08, 2020-06-08 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 mlxscore=0 phishscore=0 spamscore=0 priorityscore=1501 impostorscore=0 suspectscore=0 cotscore=-2147483648 malwarescore=0 adultscore=0 bulkscore=0 mlxlogscore=999 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006090010 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 mlxscore=0 adultscore=0 bulkscore=0 mlxlogscore=999 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006090010 Archived-At: Subject: [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: Tue, 09 Jun 2020 01:41:47 -0000 --_000_MN2PR19MB40450EE357BEECD723AB06F183820MN2PR19MB4045namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This email announces a limited-scope 3rd TSVWG Working Group Last Call (WGL= C) 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/ This draft is intended to become an Informational RFC. This WGLC has been cc:'d to the SAAG and INT-AREA lists courtesy of the breadth of interest in this draft, but WGLC discussion will take place on the TSVWG list (tsvwg@ietf.org) - please don't remove that lis= t address if/when replying with WGLC comments. This 3rd WGLC will run through the end of the day on Monday, June 29, 2 weeks before the draft submission cutoff for IETF 108. This 3rd WGLC is limited to the following two topics: 1. 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 - 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. 1. Review of changes made since the -12 version of the draft that was the subject of the second WGLC (e.g., whether or not they suffice to resolve concerns raised during that WGLC, other than overall objections to publishing this draft as an RFC): https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tsvwg-transport-encrypt-12&u= rl2=3Ddraft-ietf-tsvwg-transport-encrypt-15 Comments should be sent to the tsvwg@ietf.org list, = although purely editorial comments may be sent directly to the authors. Please cc: the WG chairs at tsvwg-chairs@ietf.org if you wo= uld like the chairs to track such editorial comments as part of the WGLC process. No IPR disclosures have been submitted directly on this draft. Thanks, David and Wes (TSVWG Co-Chairs - Gorry is recused as a draft author) --_000_MN2PR19MB40450EE357BEECD723AB06F183820MN2PR19MB4045namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This email announces a limited-scope 3rd TSVWG Wo= rking Group Last Call (WGLC) on:

 

    Considerations around Transpor= t Header Confidentiality, Network

     Operations, and the Evol= ution of Internet Transport Protocols

        &= nbsp;        draft-ietf-tsvwg-transport-= encrypt-15

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

 

This draft is intended to become an Informational= RFC.  This WGLC has

been cc:’d to the SAAG and INT-AREA lists c= ourtesy of the breadth of

interest in this draft, but WGLC discussion will = take place on the TSVWG

list (tsvwg@iet= f.org) – please don’t remove that list address if/when=

replying with WGLC comments.

 

This 3rd WGLC will run through the end of the day= on Monday, June 29,

2 weeks before the draft submission cutoff for IE= TF 108.

 

This 3rd WGLC is limited to the following two top= ics:

 

  1. Whether or not= to proceed with a request for RFC publication

of the draft. &nb= sp; The decision on whether or not to proceed will

be based on rough cons= ensus 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 –  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/t= svwg/i4qyY1HRqKwm0Jme9UtEb6DyhXU/

Further explanation fr= om both Eric Rescorla and David Schinazi

is welcome and encoura= ged to ensure that their concerns are

clearly understood.

 

  1. Review of chan= ges made since the -12 version of the draft that
    was the subject of the second WGLC (e.g., whether or not they
    suffice to resolve concerns raised during that WGLC, other
    than overall objections to publishing this draft as an RFC):

https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tsvwg-transport-e= ncrypt-12&url2=3Ddraft-ietf-tsvwg-transport-encrypt-15

 

Comments should be sent to the tsvwg@ietf.org list, although purely

editorial comments may be sent directly to the au= thors.  Please cc: the

WG chairs at tsvwg-chairs@ietf.org  if you would like the chairs to

track such editorial comments as part of the WGLC= process.

 

No IPR disclosures have been submitted directly o= n this draft.

 

Thanks,

David and Wes (TSVWG Co-Chairs – Gorry is r= ecused as a draft author)

 

--_000_MN2PR19MB40450EE357BEECD723AB06F183820MN2PR19MB4045namp_-- From nobody Tue Jun 9 10:45:44 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 1A7D33A0C3A; Tue, 9 Jun 2020 10:45:38 -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 pyGh4iqmW7AF; Tue, 9 Jun 2020 10:45:36 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 071CE3A0C35; Tue, 9 Jun 2020 10:45:34 -0700 (PDT) Received: from linux-9daj.localnet (dhcp-166.access.rits.tisf.net [24.104.150.166]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 64DE5B07D1; Tue, 9 Jun 2020 17:45:34 +0000 (UTC) From: Paul Vixie To: "tsvwg@ietf.org" Cc: int-area , IETF SAAG , "Black, David" Date: Tue, 09 Jun 2020 17:45:33 +0000 Message-ID: <19653098.bRLUaAYVpO@linux-9daj> Organization: none In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: Tue, 09 Jun 2020 17:45:38 -0000 On Tuesday, 9 June 2020 01:41:40 UTC Black, David wrote: > This email announces a limited-scope 3rd TSVWG Working Group Last Call > (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/ > > This draft is intended to become an Informational RFC. This WGLC has > been cc:'d to the SAAG and INT-AREA lists courtesy of the breadth of > interest in this draft, but WGLC discussion will take place on the TSVWG > list (tsvwg@ietf.org) - please don't remove that list > address if/when replying with WGLC comments. the goals of "prevention of network ossification" are incompatible with layering exits such as a router using non-routing header information to guide its operations. this isn't a new constraint collision -- consider OSPF ECMP which needs to examine the TCP or UDP header to find a 5-tuple to hash upon. as this draft is informational, objections of the form "it says something that is untrue or at least confrontational" or "it lacks something essential" are in scope and the answer should be "send a pull request". whereas objections of the form shown in the e-mail summary (archival) thread you referenced: (https://mailarchive.ietf.org/arch/msg/tsvwg/i4qyY1HRqKwm0Jme9UtEb6DyhXU/) > I would like to see this useful content in a BCP document once we have > enough information to actually recommend something. are out of scope because this document isn't making any recommendations, and (ibid) > Having an IETF Consensus RFC that is so heavily weighted on the side of > "this is how encryption inconveniences us" and so light on "these are the > attacks we are preventing" gives a misleading picture of the IETF > community's view of the relative priority of these concerns. are regressive, leading back to the result of "send a pull request" since the consensus being sought isn't about a recommendation but rather a depiction of known considerations. unknown considerations should not concern us, since those always exist and cannot be addressed until they make themselves known. known considerations which are missing, incomplete, or misleading in the text as drafted, should be fixed. i have two objections, both of which are inoperable at this time due to the limited scope of this WGLC. (you're asking for pass/fail, and the time for me to have suggested these changes has passed.) first, section 7.2 could do some real good by enumerating local operating system and local network policy as reasons why a transport protocol should have low-entropy markers. on many endpoints and within many networks, uncharacterized traffic will be dropped. the advance of DoH has caused and will continue to cause broader adoption of required explicit proxies to prevent uncooperative insiders from bypassing DNS policy controls. QUIC is going to cause UDP to become a privileged operation, denied except for classifiable traffic, to prevent similar bypasses. a brief examination of these deployment obstacles to PM-resistant transport deployment would help inform the manageability draft, and may even motivate a secure proxy discovery protocol similar to what the ADD WG is working on for secure RDNS discovery. it's clear that DHCP in its current form will never be used to communicate any endpoint parameter which has security value. a transport protocol which permits an on-path device to authentically deny an unclassifiable flow will be deployed more quickly and more widely, and so a mention of these tensions in section 7.2 might accelerate darwinism here. second, the absence of signaling within the IP and IP6 headers to drive the advancement of congestion management is a form of ossification, and should be blamed here. the needs of L4S or SCE or similar should not have a bearing on QUIC or for that matter even on TCP. so, when discussing anti-ossification as a goal, this document could highlight that previous ossification has created many of the tensions the document will go on to describe in detail. this bit of history won't be known by most readers, and could provoke cognitive dissonance if left untreated. given the inoperable (because: late) nature of my objections, i support publication of this draft. thank you for giving us a chance to comment. vixie From nobody Fri Jun 12 09:03: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 78BDE3A0FDE for ; Fri, 12 Jun 2020 09:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 R3mt_IxyX5UH for ; Fri, 12 Jun 2020 09:03:42 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B0373A0FC4 for ; Fri, 12 Jun 2020 09:03:42 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id y1so7478219qtv.12 for ; Fri, 12 Jun 2020 09:03:42 -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:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=NQSVGPJPDrscpo4/v5J4JJ/krxflc7kCyr10YbKILVM=; b=ubP/ulkvod+d0YSGcZ/woCJ7F1roDqpDe2Qcf5JEMMBIIX9NtJlHQL3CIwEfgpLdtT R4maAbx6XH+Wwc5l2F0TdQRwhHo3MO3jGuwksoZinYUYo+qhFouRDAdVK5V9OL5T3k3U ZpITE7I/gP2F2bYtnMzotBBQo2YOrF2okEmzOkH97uF5ymCY21Y0ZXIn5YTDU9k0F/LS qhGQWV6Lzu1NiqDcXwJukfAD84XMfX7nqj+6EHTWYsoR/zdUtqE8cMJaDsFhkbHkk2DA peysry73wUyezgd8qm1jnSLE2ePvXow3fQZZcI5bGv3Om2hkcmxpjw2A5y5q2v9OMOY0 252Q== 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 :cc:message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=NQSVGPJPDrscpo4/v5J4JJ/krxflc7kCyr10YbKILVM=; b=IYUsosvv11+wf9u9KocLKEPMGdfLf1PnrvW4nloqQpTBbHWpPA9GHr8IHNlynePQdW TDX4Eqfbs9IcpwnyVc7507qihgx7koxDeq41zch270vQ7QDn6VZF+t/i4GcpL71HhjBd kWaCiFq0yFbwdUckQAbyJNcr/7clNxhN5+CBzYEKcP3RwkmIOPM3qskD/J6rwmmn5TN0 5z2jYqnR+pVkzRufNqVcqbbriwbVbA1PfBJn2J8Kt6kFAet1F0ZQCOdT4TZ/Qgq7U/4Z 0kYdpAbdSh+L+WJjbj6IB8xYvP8iTEFYnXBGWZym6hM88cqwVCnvB3KIe3T+rXVtfrO2 U/7A== X-Gm-Message-State: AOAM530Njckqjl0RSi5bBdpaJHkzdDszyJpkaZqr6rtYTMCnhh9XFqc9 mGGRMxCb8lOhR6hZgo88MMg= X-Google-Smtp-Source: ABdhPJz5+FqK9ReOVy3Re+Zn/zhobTBkgp85FwJsL0Uo1+QrJj4QsvWw5X59eOLijIOlJGSaITiOqQ== X-Received: by 2002:ac8:72d1:: with SMTP id o17mr3906079qtp.303.1591977821426; Fri, 12 Jun 2020 09:03:41 -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 p13sm5114969qtk.24.2020.06.12.09.03.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 Jun 2020 09:03:40 -0700 (PDT) From: Tony Rutkowski X-Google-Original-From: Tony Rutkowski Reply-To: trutkowski@netmagic.com To: IETF SAAG References: Organization: Netmagic Associates LLC Cc: Glenn.Deen@nbcuni.com Message-ID: Date: Fri, 12 Jun 2020 12:03:39 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4D4D43044CBA118D131965B6" Content-Language: en-US Archived-At: Subject: [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: Fri, 12 Jun 2020 16:03:45 -0000 This is a multi-part message in MIME format. --------------4D4D43044CBA118D131965B6 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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. LET'S OPPOSE --tony --------------4D4D43044CBA118D131965B6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

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.

LET'S OPPOSE

--tony --------------4D4D43044CBA118D131965B6-- From nobody Wed Jun 17 08:21: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 0E4083A08C1 for ; Wed, 17 Jun 2020 08:21:48 -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 C1NdONnKnS2K for ; Wed, 17 Jun 2020 08:21:45 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 AEA7D3A0855 for ; Wed, 17 Jun 2020 08:21:45 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id i8so882937uak.9 for ; Wed, 17 Jun 2020 08:21:45 -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=YyMqZV4pNuYG9831TurjjwQSwvpR2t5loRgP28juT48=; b=m7JP+qfINPYjxY10HE+lUtEIDZEzrPyelEXFmTz4GQpwYq+SLvsn/oNtgZW99onrmM 6AUHHpH38eSEkEDrqWcHUQG+6w/3xQHfMtL7jnRyJOd03BygbCz6HlZhn7aADtPw7pqs NCkgqipVZMuvuCQYF1s3TMbFBAFduYU2hm33g= 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=YyMqZV4pNuYG9831TurjjwQSwvpR2t5loRgP28juT48=; b=I9Rbk/NAe12wsDa5jBVt9SMGZB4JjxOfoEWXUunwlOKcG9x5RrqKHtqOWoW1BVm9gM QxEWb2QTDbjQ4WqVCutjPwXQTbGaVGzrRAWxADvpqf5doE6a5eEJ2R8IzbDnpUOWN51D uYKuJ3U11L6dgXQn5g0k86Uhgwi2s3jlG04cZF+oimpqixps37NdNs9vXLxzGhG9CrTS pfCOO7qRLWy62mzqQxDLVxYGwJtehYqLvj+QRnKw05evbLBN4qpIcH3dynsPp7AfvZvv CBgKZoLFTU6NOj6X5bb9e/Z7tY28RziRnvzr8GtLVXfH+Ka/dzFeYynoHC1vLjARCgV1 Bf2A== X-Gm-Message-State: AOAM531p+w4ijvzyOpI5SgEEngxC4SLgxgZYaDINgpcAQQfdwtK0g6fM z3XDdsWca55QEsv0BW0TUNIoci/WfSL/8jsH13JbyA== X-Google-Smtp-Source: ABdhPJwUWlyypI1F6lYUlNFypwEhq/IrvWkWM+tQYxpV4NIXBN75pPlSV2wQKkiqDUl/zoZToSjN4oZA2takr+w28e8= X-Received: by 2002:ab0:6445:: with SMTP id j5mr6258721uap.26.1592407304315; Wed, 17 Jun 2020 08:21:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kyle Rose Date: Wed, 17 Jun 2020 11:21:32 -0400 Message-ID: To: "Black, David" Cc: "tsvwg@ietf.org" , int-area , IETF SAAG Content-Type: multipart/alternative; boundary="000000000000b6c76b05a849372b" 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, 17 Jun 2020 15:21:48 -0000 --000000000000b6c76b05a849372b Content-Type: text/plain; charset="UTF-8" On Mon, Jun 8, 2020 at 9:41 PM Black, David wrote: > This email announces a limited-scope 3rd TSVWG Working Group Last Call > (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-tsDo we have machines near IAD > that Asgard can use vwg-transport-encrypt/ > > I support requesting publication of this draft as an informational RFC. There's no reason a draft aimed exclusively at identifying, contextualizing, and offering high-level mitigations for a set of related technical problems (in this case, the operational problems exacerbated by transport header encryption) needs to incorporate advocacy of any kind. It is very clear from other publications and from on-going work that the consensus of the IETF is in favor of measures to combat pervasive surveillance and to limit protocol ossification. The purpose of *this* document seems to be to end the pretense that there is no resulting tradeoff or that by ignoring operational issues related to transport header encryption they'll go away on their own. That said, even then it does not in any way advocate against transport encryption, and is circumspect in its proposals for measures to improve diagnostic visibility. Kyle --000000000000b6c76b05a849372b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jun 8, 2020 at 9:41 PM Black, David <David.Black@dell.com> wrote:

This email announces a limited-scope 3rd TSVWG Working Group Last Call (= WGLC) on:

=C2=A0

=C2=A0=C2=A0=C2=A0 Considerations around Transport Header Confidentialit= y, Network

=C2=A0=C2=A0=C2=A0=C2=A0 Operations, and the Evolution of Internet Trans= port Protocols

=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 draft-ietf-tsvwg-transport-encrypt-15

https://datatracker.ietf.org/doc/draft-ietf-tsDo= we have machines near IAD that Asgard can use vwg-transport-encrypt/

I support requesting publication of this draft as an informational R= FC.

There's no re= ason a draft aimed exclusively at identifying, contextualizing, and offerin= g high-level mitigations for a set of related technical problems (in this c= ase, the operational problems exacerbated by transport header encryption) n= eeds to incorporate advocacy of any kind. It is very clear from other publi= cations and from on-going work that the consensus of the IETF is in favor o= f measures to combat pervasive surveillance and to limit protocol ossificat= ion. The purpose of *this* document seems to be to end the pretense that th= ere is no resulting tradeoff or that by ignoring operational issues related= to transport header encryption they'll go away on their own. That said= , even then it does not in any way advocate against transport encryption, a= nd is circumspect in its proposals for measures to improve diagnostic visib= ility.

=
Kyle

--000000000000b6c76b05a849372b-- From nobody Thu Jun 18 10:37:58 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 22A9C3A0AB7; Thu, 18 Jun 2020 10:37:56 -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 ovt8dcZqUdhF; Thu, 18 Jun 2020 10:37:54 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 F2A683A0A8F; Thu, 18 Jun 2020 10:37:53 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id b6so6929639wrs.11; Thu, 18 Jun 2020 10:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=nAgxOp69E3l7GJqyAgdLA3y5TL7TQov7S35j8sgtDmA=; b=qX8efVLGkj0SDUW8WCgEX2TMWfRdT0JKJKSscJayq2mjNVKIdl2Wzow1cUHyAogIhw m8p5w4inM3bxb9bfM+ncQFEr2vSg9PkgzuRY2JD6XzF73HtEVbfIH97G233CXo9v8Rrn 9qT9cSgcpk1qXI5M43edW14bG2cK0vyvo26JiRerj/V/Hbbx6iR1HQ/thJmvIM7nHGar 49Lv57tr3+FvQ0m8HmTgOHr4ic2RTLD95O8Q23RPCxgd+gwyugMFH2DDlP1QLv+vCPIo ungI8B+/Kb6xFPa77pn1XXPSIsPCNmTNBo1HrddwnyJpP0iyERLHPq8DgZGd9n95SFBr N8Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=nAgxOp69E3l7GJqyAgdLA3y5TL7TQov7S35j8sgtDmA=; b=E7d3tWI2G197mv+eqVmLM/cvUxrr9fUfGgqJK4R+N954gCzJe0Zb3NxGzG0cFuEA/h 7fukvY6Wuew925tQnfzUyylGRy7Z29N1uykMi4ernnIbdwd1vCX1eUhh8hUz1U/WjQ1L 8fBQSJIhloZnI1EHpU4q7JcTd1kJXMhIOcIUR7R0ohEgv3xu1bqoOPLHtxLr3+xjr+7w WN8HBSoopgFM5bLivuirDp21DfwbVjjlzP/tSNwaj+SxpgTUi1MD/ABoHF+ENy+jp0T1 AY04l/4lvMXlFAKq68m7ia2AiesVN/T272WebaK8mKrWvm4OnqTAGxJh/2rF4nK2Wogv FaZQ== X-Gm-Message-State: AOAM530fKhsTild1xEEhpS0gz6nuQhsy4hZdE9wrBttAf2+CP64DA4o0 yQ/8+fRAZRJocWkuCt0iDx0= X-Google-Smtp-Source: ABdhPJyWJmei445YoOGeGJ2z9jWu4EIU15JjxFiXCc5tUx4z45aMQNwAYi7wP7cmpBQTj1Ba7ofUIA== X-Received: by 2002:adf:b348:: with SMTP id k8mr6330198wrd.157.1592501872404; Thu, 18 Jun 2020 10:37:52 -0700 (PDT) Received: from RoniPC (bzq-79-180-107-12.red.bezeqint.net. [79.180.107.12]) by smtp.gmail.com with ESMTPSA id 89sm4430330wrg.56.2020.06.18.10.37.50 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Thu, 18 Jun 2020 10:37:51 -0700 (PDT) From: "Roni Even" To: "'Black, David'" , Cc: "'int-area'" , "'IETF SAAG'" References: In-Reply-To: Date: Thu, 18 Jun 2020 20:37:48 +0300 Message-ID: <0a3701d64597$2f7826f0$8e6874d0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A38_01D645B0.54C6BE80" X-Mailer: Microsoft Outlook 14.0 Content-Language: he Thread-Index: AQIBOutAlmPpEdFzIRk1z7bvh2EGWqiItdTg 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: Thu, 18 Jun 2020 17:37:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0A38_01D645B0.54C6BE80 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, I support the publication of this draft. In my view the concerns were answered and it reflects the view that there are consequences when encryption the transport headers but does not claim that they should not be encrypted. As section 1 mentions it also explains the text in RFC7258 section 2 about when PM is useful and as such I think that the document must be published. Roni Even From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Black, David Sent: Tuesday, June 09, 2020 4:42 AM To: tsvwg@ietf.org Cc: int-area; IETF SAAG Subject: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 This email announces a limited-scope 3rd TSVWG Working Group Last Call (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/ This draft is intended to become an Informational RFC. This WGLC has been cc:'d to the SAAG and INT-AREA lists courtesy of the breadth of interest in this draft, but WGLC discussion will take place on the TSVWG list (tsvwg@ietf.org) - please don't remove that list address if/when replying with WGLC comments. This 3rd WGLC will run through the end of the day on Monday, June 29, 2 weeks before the draft submission cutoff for IETF 108. This 3rd WGLC is limited to the following two topics: 1. 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 - 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. 2. Review of changes made since the -12 version of the draft that was the subject of the second WGLC (e.g., whether or not they suffice to resolve concerns raised during that WGLC, other than overall objections to publishing this draft as an RFC): https://www.ietf.org/rfcdiff?url1=draft-ietf-tsvwg-transport-encrypt-12 &url2=draft-ietf-tsvwg-transport-encrypt-15 Comments should be sent to the tsvwg@ietf.org list, although purely editorial comments may be sent directly to the authors. Please cc: the WG chairs at tsvwg-chairs@ietf.org if you would like the chairs to track such editorial comments as part of the WGLC process. No IPR disclosures have been submitted directly on this draft. Thanks, David and Wes (TSVWG Co-Chairs - Gorry is recused as a draft author) ------=_NextPart_000_0A38_01D645B0.54C6BE80 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

I support the = publication of this draft. In my view the concerns were answered and it = reflects the view that there are consequences when encryption the = transport headers but does not claim that they should not  be = encrypted.

As section 1 mentions it also  explains the = text in RFC7258 section 2 about when PM is useful and as such I think = that the document must be published.

 

Roni = Even

 

From:= = tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Black, = David
Sent: Tuesday, June 09, 2020 4:42 AM
To: = tsvwg@ietf.org
Cc: int-area; IETF SAAG
Subject: = [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, = closes 29 June 2020

 

This = email announces a limited-scope 3rd TSVWG Working Group Last Call (WGLC) = on:

 

    Considerations around Transport = Header Confidentiality, Network

     Operations, and the = Evolution of Internet Transport Protocols

        &nbs= p;        = draft-ietf-tsvwg-transport-encrypt-15

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

 

This draft is intended to become an Informational = RFC.  This WGLC has

been = cc:’d to the SAAG and INT-AREA lists courtesy of the breadth = of

interest in this draft, but = WGLC discussion will take place on the TSVWG

list (tsvwg@ietf.org) – please = don’t remove that list address if/when

replying with WGLC comments.

 

This = 3rd WGLC will run through the end of the day on Monday, June = 29,

2 weeks before the draft = submission cutoff for IETF 108.

 

This = 3rd WGLC is limited to the following two topics:

 

  1. 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 = –  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/i4qyY1HRqKwm0Jme9UtE= b6DyhXU/

Further explanation from both Eric Rescorla = and David Schinazi

is welcome and encouraged to ensure that = their concerns are

clearly understood.

 

  1. Review of changes made since the -12 version of the draft = that
    was the subject of the second WGLC (e.g., whether or not = they
    suffice to resolve concerns raised during that WGLC, = other
    than overall objections to publishing this draft as an = RFC):

https://www.ie= tf.org/rfcdiff?url1=3Ddraft-ietf-tsvwg-transport-encrypt-12&url2=3Ddr= aft-ietf-tsvwg-transport-encrypt-15

 

Comments should be sent to the tsvwg@ietf.org list, although = purely

editorial comments may be = sent directly to the authors.  Please cc: the

WG chairs at tsvwg-chairs@ietf.org  if = you would like the chairs to

track = such editorial comments as part of the WGLC process.

 

No IPR = disclosures have been submitted directly on this draft.

 

Thanks,

David = and Wes (TSVWG Co-Chairs – Gorry is recused as a draft = author)

 

------=_NextPart_000_0A38_01D645B0.54C6BE80-- From nobody Thu Jun 18 10:43: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 754F33A0E2A for ; Thu, 18 Jun 2020 10:43: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=herbertland-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 YrCNFQvLP_RT for ; Thu, 18 Jun 2020 10:43:38 -0700 (PDT) Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (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 04A8D3A0DEB for ; Thu, 18 Jun 2020 10:43:36 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id p20so7263707ejd.13 for ; Thu, 18 Jun 2020 10:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=IG65TX0fNlrAkLVFAKK4SVujE1R+X2+XvNzCrdNOaf0=; b=TiDjvupo1zNmoUUWQDAZqRnAYeZ3dp//aN1d4R6EtNvDeO4d2zKJQw+OecGu2rp2ND 49frCZqlV5c+BjVBqxU2sJxteHcNJzzx99mbZTrVOj6d+rZZul+q8T5XVPXBEB47NPSd aXtuHMiObb8Vzbbg5puMxfsbkQWW0mzXFVCwMotWqPA97WtXXbKYrF+B7Sq2PCZ07vSe mcaJSayi+7StX9ychlLKdKm68Q6HjB/ufPl7A/sekS32MTa6KAFzEFO7lSz9TgliBpJw HLOdvGsX2ODjTVvT6gVZIDdmcU8Q2Oa1AOlV5/JHxLc1Mw/DwCE4MWRqsoDe/vqHlxMN +PhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=IG65TX0fNlrAkLVFAKK4SVujE1R+X2+XvNzCrdNOaf0=; b=WatDC/DujJdH8xAa5k+Brr3S3n8Y3vmT3yn1zH4c1CiFl3qRfbYJ8k6C0ozjmFwWCw RCJCqKj/K8gz0lIrk5sYMCF6IV6WCHgcXRuraKNqLM0xRUE9KfxDMa51r0LGIRPy0l8X 7oMGlISmrdN/ZJhUfLwoVfm+D0HbkW1FQjgo9MabSvzct0l84m/L8zFA08mLXbnsbYGw 9JZ/V11jUTdhjBPjLbTznhnh9PtUPEaR8gurS4D7hDS69hAhnrHZ+kQWj1y7JPrYbvAE l7BG840adFMKob4XNsBMhZ/q62+nPoE+IzW4w/cKs3zQtE033a5K0x5exCH1CRCPyx0l H70A== X-Gm-Message-State: AOAM530kaqOIL+kzdofl9FVPYK5rpEc7wMygt/d1Vi+Jr/oTdm8VJ+wF 9NDVS4dyEJ4MoOnFkrUe2JQ1evZbk3O0VefnJXVxug== X-Google-Smtp-Source: ABdhPJwgJ87Ktc4wt38g0rAMVCSVGoHhkJoATm4ycMhgqKmIr7rRvlD8S/U7mpbfPS2fKGEibWDPEz1+3x0QSgv9FrY= X-Received: by 2002:a17:906:3e15:: with SMTP id k21mr5234669eji.525.1592502215204; Thu, 18 Jun 2020 10:43:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Herbert Date: Thu, 18 Jun 2020 10:43:23 -0700 Message-ID: To: "Black, David" Cc: "tsvwg@ietf.org" , int-area , IETF SAAG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Thu, 18 Jun 2020 17:43:50 -0000 I am neutral on this draft. While the authors certainly have done a good job at improving the draft over time and it is a lot more balanced between the arguments to encrypt or not encrypt transport, there really isn't much in terms of actionable guidance for protocol developers. It seems the best that can be said is that transport protocol designers should consider the issues. The pertinent statement from the draft: "The decision about which transport headers fields are made observable offers trade-offs around header confidentiality versus header observability (including non-encrypted, but authenticated, header fields) for network operations and management, and the implications for ossification and user privacy [Measurement]. Different parties will view the relative importance of these differently." This is true, and the last sentence is telling. Users are one of those parties, and in fact probably the most important party at the end of the day. If a tradeoff is made that exposes some information to the network with the knowledge that the exposure provides more benefits than potential harm to a user then that might be an acceptable tradeoff. However such a tradeoff could only be correctly made at runtime based on assessment of the risks and benefits for the particular circumstances. This really can't be a design decision burned into the transport protocol. For instance, I, as a user, might be willing to expose a lot of information about my packets to my local carrier if I have a contractual agreement that describes security and privacy provided and exactly what benefits I get from the provider for volunteering the information. However if I'm connected to some public random WIFI, I really want the absolute minimum level of information exposed. Generally, we don't know a priori what transport information a particular network might "need", nor that there aren't malicious parties in the path intent on abusing exposed information. So, fundamentally, transport information exposure is discretionary and should be controlled by the user and the only reasonable security default is that no information is exposed (I think this could be normative requirements if the draft offers any). There is also the possibility that the transport protocol developer may expose fields that are considered innocuous to make visible. This is risky since there is precedent that information considered safe turned out to reveal sensitive information (case in point is analysis of TCP options which can reveal the OS and version which can be useful information for a DOS attack). Tom On Mon, Jun 8, 2020 at 6:42 PM Black, David wrote: > > This email announces a limited-scope 3rd TSVWG Working Group Last Call (W= GLC) 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/ > > > > This draft is intended to become an Informational RFC. This WGLC has > > been cc:=E2=80=99d to the SAAG and INT-AREA lists courtesy of the breadth= of > > interest in this draft, but WGLC discussion will take place on the TSVWG > > list (tsvwg@ietf.org) =E2=80=93 please don=E2=80=99t remove that list add= ress if/when > > replying with WGLC comments. > > > > This 3rd WGLC will run through the end of the day on Monday, June 29, > > 2 weeks before the draft submission cutoff for IETF 108. > > > > 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/i4qyY1HRqKwm0Jme9UtEb6DyhXU/ > > Further explanation from both Eric Rescorla and David Schinazi > > is welcome and encouraged to ensure that their concerns are > > clearly understood. > > > > Review of changes made since the -12 version of the draft that > was the subject of the second WGLC (e.g., whether or not they > suffice to resolve concerns raised during that WGLC, other > than overall objections to publishing this draft as an RFC): > > https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tsvwg-transport-encrypt-12= &url2=3Ddraft-ietf-tsvwg-transport-encrypt-15 > > > > Comments should be sent to the tsvwg@ietf.org list, although purely > > editorial comments may be sent directly to the authors. Please cc: the > > WG chairs at tsvwg-chairs@ietf.org if you would like the chairs to > > track such editorial comments as part of the WGLC process. > > > > No IPR disclosures have been submitted directly on this draft. > > > > Thanks, > > David and Wes (TSVWG Co-Chairs =E2=80=93 Gorry is recused as a draft auth= or) > > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Thu Jun 18 11:08:28 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 A5D5B3A0DC3; Thu, 18 Jun 2020 11:08:26 -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 qCDQ4A3XTpu6; Thu, 18 Jun 2020 11:08:25 -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 69D0B3A0DC5; Thu, 18 Jun 2020 11:08:25 -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 05II87ML005419; Thu, 18 Jun 2020 19:08:24 +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=wyFVBcW+8F0IaOFl0t9Lbqi1ByM6XbOsqExgEjbS6EQ=; b=QfBKlHcjnGzHFdInD35g2KhIuEIfWbPRuHwPgqRqNSYGd3ZHsorugZTpdiuSAuvA58ND uwNQrV8tx4PWwMukOZdfQmQB0Nf+EVTTJSLQOd8jHilRra3f7WRUuKpOcnFTkp7k8S9Q MBKOqy0brGp2zkWpvExFtz0Gb0leH1nWSpUls3F2rPFbCXT8AUPThT+zsuPrww+6hmaB 0wMjSm4nTPVFCjqa3pc81ZZoH99XpjAK8GX3GyTlbd9fkRrX9CorOsd1QVgI8l+uQMre B5lHrmVU3SjMSosCZg5GxrjrUpRf/svh7PDYl/pSs0oKbu8brlFc64yEkvD6Crg+6VX6 3g== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 31qre9fcap-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Jun 2020 19:08:23 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 05II5Rvq009377; Thu, 18 Jun 2020 14:08:23 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 31qjmbpnqg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 18 Jun 2020 14:08:23 -0400 Received: from usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 18 Jun 2020 14:08:22 -0400 Received: from usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) by usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) with mapi id 15.00.1497.006; Thu, 18 Jun 2020 14:08:22 -0400 From: "Holland, Jake" To: "Black, David" , "tsvwg@ietf.org" CC: int-area , IETF SAAG Thread-Topic: [tsvwg] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020 Thread-Index: AdY9/kL5KQoLk/CbSKeZ9xMZ8uq3SAHhAr+A Date: Thu, 18 Jun 2020 18:08:22 +0000 Message-ID: <504C4220-D120-45F4-9D51-8E48F63B0ACB@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.93.179] Content-Type: text/plain; charset="utf-8" Content-ID: <42FCB9A54D705142894A67F95ADC2B53@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-18_15:2020-06-18, 2020-06-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 malwarescore=0 bulkscore=0 adultscore=0 mlxlogscore=999 mlxscore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006180138 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-18_15:2020-06-18, 2020-06-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 suspectscore=0 adultscore=0 spamscore=0 cotscore=-2147483648 malwarescore=0 phishscore=0 mlxlogscore=999 bulkscore=0 lowpriorityscore=0 priorityscore=1501 impostorscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006180138 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: Thu, 18 Jun 2020 18:08:27 -0000 KzEgb24gS3lsZSdzIHJlbWFya3NbMV0sIGFuZCB3ZWxsLXB1dC4NCg0KSU1PLCB0aGlzIGRvYyBz ZWVtcyB1c2VmdWwgYW5kIHNob3VsZCBtb3ZlIGZvcndhcmQgYXMgaW5mb3JtYXRpb25hbC4NCg0K V2hpbGUgSSBkbyBhbHNvIHRoaW5rIGEgQkNQIHdvdWxkIGJlIGdyZWF0LCBzaW5jZSB3ZSdyZSBu b3QgdGhlcmUNCnlldCBhbiBpbmZvcm1hdGlvbmFsIFJGQyBhcnRpY3VsYXRpbmcgdGhlIHBvaW50 cyB0aGlzIG9uZSBkb2VzIGlzIGENCnZlcnkgd2VsY29tZSBzdGVwIGZvcndhcmQgYW5kIG11Y2gg YmV0dGVyIHRoYW4gbm90aGluZywgSU1PLg0KDQotSmFrZQ0KDQoNClBTOiBBbHNvICsxIHRvIFBh dWwgVml4aWUncyBzdWdnZXN0aW9uIHRoYXQgdGhlIG9iamVjdGlvbnMgc2hvdWxkDQppZGVhbGx5 IGJlIHBocmFzZWQgYXMgYSBwdWxsIHJlcXVlc3QuICBUaGVyZSdzIHBlcmhhcHMgcm9vbSBmb3IN CnNvbWUgZWRpdG9yaWFsIGltcHJvdmVtZW50cywgYnV0IGFzIGl0IHN0YW5kcyBpdCdzIHByZXR0 eSByZWFkYWJsZSwNCmFuZCBoYXMgc29tZSBjcnVjaWFsIGluZm9ybWF0aW9uIGFib3V0IHRoZSBu ZXcgY2hhbGxlbmdlcyB0aGF0DQp0cmFuc3BvcnQgaGVhZGVyIGVuY3J5cHRpb24gaW50cm9kdWNl cyB0byBleGlzdGluZyBvcGVyYXRpb25hbA0KcHJhY3RpY2VzLg0KDQpTbyBteSArMSBvbiBvYmpl Y3Rpb25zLWFzLXB1bGwtcmVxdWVzdCBpcyBiZWNhdXNlIEknbSBub3QNCnVuZGVyc3RhbmRpbmcg dGhlIHRvbmUgb3IgYmFsYW5jZSBwcm9ibGVtcyB0aGF0IHdlcmUgcmFpc2VkLiAgSQ0KZG9uJ3Qg c2VlIHdoYXQga2luZHMgb2YgZWRpdHMgd291bGQgYWRkcmVzcyB0aGVtIG91dHNpZGUgb2YgInN0 b3ANCmFja25vd2xlZGdpbmcgdGhhdCB0aGVyZSBhcmUgbmV3IGNoYWxsZW5nZXMgcmFpc2VkIGJ5 IHRyYW5zcG9ydA0KaGVhZGVyIGVuY3J5cHRpb24iIG9yICJhZGQgMTQgcGFnZXMgZHVwbGljYXRp bmcgaW5mbyBpbiB0aGUNCnJlZmVyZW5jZWQgUkZDcyBhYm91dCB3aHkgZW5jcnlwdGlvbiBpcyBn b29kIi4gIEJvdGggb2YgdGhlc2Ugc2VlbQ0KY291bnRlcnByb2R1Y3RpdmUgdG8gbWUsIHNvIGFi c2VudCBhIG1vcmUgc3BlY2lmaWMgc2V0IG9mIHByb2R1Y3RpdmUNCnN1Z2dlc3Rpb25zIChvbmVz IHRoYXQgZG9uJ3QgbG9zZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbmV3DQpvcGVyYXRpb25hbCBj aGFsbGVuZ2VzIHRoYXQgYXJlIGludHJvZHVjZWQgYnkgdHJhbnNwb3J0IGhlYWRlcg0KZW5jcnlw dGlvbiksIEkgYW0gYWdhaW5zdCBzdGFsbGluZyBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvYyBhcyBh bg0KUkZDIGJhc2VkIG9uIHRoZSBvYmplY3Rpb25zIHJhaXNlZCBzbyBmYXIuDQoNClsxXSBLeWxl J3MgcmVtYXJrczoNCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdHN2d2cv MFVOSmJFTFRITXc3eGpWOVNJWG9hdkFESzZnLw0KDQoNCg== From nobody Fri Jun 19 01:21: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 4295E3A0807; Fri, 19 Jun 2020 01:21:08 -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 AAlffLvuz4HJ; Fri, 19 Jun 2020 01:21:04 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 943B73A0801; Fri, 19 Jun 2020 01:21:03 -0700 (PDT) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 396A21B00127; Fri, 19 Jun 2020 09:20:56 +0100 (BST) To: Tom Herbert , "Black, David" Cc: int-area , "tsvwg@ietf.org" , IETF SAAG References: From: Gorry Fairhurst Message-ID: <3c63ed33-0bc2-7b69-2618-2b145e585c91@erg.abdn.ac.uk> Date: Fri, 19 Jun 2020 09:20:55 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB 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: Fri, 19 Jun 2020 08:21:08 -0000 Thanks Tom, On 18/06/2020 18:43, Tom Herbert wrote: > I am neutral on this draft. While the authors certainly have done a > good job at improving the draft over time and it is a lot more > balanced between the arguments to encrypt or not encrypt transport, > there really isn't much in terms of actionable guidance for protocol > developers. It seems the best that can be said is that transport > protocol designers should consider the issues. The pertinent statement > from the draft: > > "The decision about which transport headers fields are made observable > offers trade-offs around header confidentiality versus header > observability (including non-encrypted, but authenticated, header > fields) for network operations and management, and the implications > for ossification and user privacy [Measurement]. Different parties > will view the relative importance of these differently." The intention is indeed to document things (as an INFO RFC) and indeed for this draft not to provide actionable guidance for protocol developers. If the IETF can't document the concerns/motivations for using this information, then I would suggest we shouldn't be providing guidelines for use at the Internet or transport layers. However, my hope is that we can agree what exists/existed, and that we can facilitate a way forward. > This is true, and the last sentence is telling. Users are one of those > parties, and in fact probably the most important party at the end of > the day. If a tradeoff is made that exposes some information to the > network with the knowledge that the exposure provides more benefits > than potential harm to a user then that might be an acceptable > tradeoff. However such a tradeoff could only be correctly made at > runtime based on assessment of the risks and benefits for the > particular circumstances. This really can't be a design decision > burned into the transport protocol. For instance, I, as a user, might > be willing to expose a lot of information about my packets to my local > carrier if I have a contractual agreement that describes security and > privacy provided and exactly what benefits I get from the provider for > volunteering the information. However if I'm connected to some public > random WIFI, I really want the absolute minimum level of information > exposed. Generally, we don't know a priori what transport information > a particular network might "need", nor that there aren't malicious > parties in the path intent on abusing exposed information. So, > fundamentally, transport information exposure is discretionary and > should be controlled by the user and the only reasonable security > default is that no information is exposed (I think this could be > normative requirements if the draft offers any). There is also the > possibility that the transport protocol developer may expose fields > that are considered innocuous to make visible. This is risky since > there is precedent that information considered safe turned out to > reveal sensitive information (case in point is analysis of TCP options > which can reveal the OS and version which can be useful information > for a DOS attack). The public wifi example is one case that I expect many to agree upon. There are clearly ways that information can be/is being mis-used. The expectation could perhaps be differnent for a company's enterprise gateway to their network supplier, or a subscription to a cellular provider., etc. This document doesn't try to explore use-cases either, which may well be a part of understanding a way forward. Gorry > Tom > > On Mon, Jun 8, 2020 at 6:42 PM Black, David wrote: >> This email announces a limited-scope 3rd TSVWG Working Group Last Call (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/ >> >> >> >> This draft is intended to become an Informational RFC. This WGLC has >> >> been cc:’d to the SAAG and INT-AREA lists courtesy of the breadth of >> >> interest in this draft, but WGLC discussion will take place on the TSVWG >> >> list (tsvwg@ietf.org) – please don’t remove that list address if/when >> >> replying with WGLC comments. >> >> >> >> This 3rd WGLC will run through the end of the day on Monday, June 29, >> >> 2 weeks before the draft submission cutoff for IETF 108. >> >> >> >> 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 – 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. >> >> >> >> Review of changes made since the -12 version of the draft that >> was the subject of the second WGLC (e.g., whether or not they >> suffice to resolve concerns raised during that WGLC, other >> than overall objections to publishing this draft as an RFC): >> >> https://www.ietf.org/rfcdiff?url1=draft-ietf-tsvwg-transport-encrypt-12&url2=draft-ietf-tsvwg-transport-encrypt-15 >> >> >> >> Comments should be sent to the tsvwg@ietf.org list, although purely >> >> editorial comments may be sent directly to the authors. Please cc: the >> >> WG chairs at tsvwg-chairs@ietf.org if you would like the chairs to >> >> track such editorial comments as part of the WGLC process. >> >> >> >> No IPR disclosures have been submitted directly on this draft. >> >> >> >> Thanks, >> >> David and Wes (TSVWG Co-Chairs – Gorry is recused as a draft author) >> >> >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area From nobody Fri Jun 26 15:02: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 24EAC3A0CE3; Fri, 26 Jun 2020 15:02:39 -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 DPijPFhR4b-B; Fri, 26 Jun 2020 15:02:37 -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 35EAD3A0CDD; Fri, 26 Jun 2020 15:02:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 76C76389A1; Fri, 26 Jun 2020 17:59:49 -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 n3m027bpctID; Fri, 26 Jun 2020 17:59:48 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2E7D3389A0; Fri, 26 Jun 2020 17:59:48 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 908BEF5; Fri, 26 Jun 2020 18:02:31 -0400 (EDT) From: Michael Richardson To: Russ Housley , Toerless Eckert , anima@ietf.org, Ben Kaduk , saag@ietf.org In-Reply-To: References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> 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: [saag] towards using of MUST-/SHOULD+/SHOULD- in draft-ietf-autonomic-control-plane-24 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, 26 Jun 2020 22:02:39 -0000 --=-=-= Content-Type: text/plain Russ Housley wrote: >> ACP nodes MUST NOT support certificates with RSA public keys of >> less than 2048 bits. They MUST support certificates with RSA public keys >> with 2048 bits and SHOULD support longer RSA keys. ACP nodes MUST >> support certificates with ECC public keys using NIST P-256, P-384 and >> P-521 curves. >> >> ACP nodes MUST support SHA-256, SHA-384, SHA-512 signatures for certificates with RSA key and the same RSA signatures plus ECDSA signatures for certificates with ECC key. >> --- >> >> I don't understand whether your note about the key length of the curves is an indication of missing text. When i first reviewed with Ben, i had to enter the curves because thats as specific as necessary AFAIK, but given how the key length is implied, i wouldn't understand why i would need to write those down. I don't remember that i have seen that being done either in other RFCs i read through. >> >> In any case, specific text suggestions always welcome in case this text is not sufficient. russ> I was expecting you to make one of the curves MUST and the others russ> SHOULD. Making all three curves MUST is okay with me, but it will russ> increase implementation size. russ> Likewise, I was expecting you to make one of the hash functions russ> MUST and the others SHOULD. I tried to convince Toerless to go with the MUST-/SHOULD+/SHOULD- terminology from IPsecME's RFC8247. It would be nice if SAAG lifted section 1.1 into a BCP14-like document, as I think that it has widespread applicability throughout documents that want to establish interoperable crypto. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl72cHcACgkQgItw+93Q 3WVgNwf/Yo3HWY/7sxuu8HVimbEV2EI5EWvwrZE6TH7Ngj40wsAyClcBjoZdVDGf +xpXiSj9l7COWxUeKbjzep1uZL4yaQ6j/ywEnSLlLPIGfAzmDIxNpReYvPtDjURq BuODyIU8tGuTmUlDNIFUohrX8ElvPr6Qti9q/uYT6NlRkjcHmE8m6iJJraDqpwM2 rsciYMWEsSlHBJRTKpFjGdyVwyVG6gcFVjn4eSJeV1HuIQaLaY8bRQVGYOAcGHp4 EAqbsSO9mvuAIB8CYcLvNHWywd0yAeUQHtsIKwUQH+abKdAH2LItt4VIXp8smaC0 lsQCczHSzszj9gnmtZGIxuY8TP5FhQ== =IrHI -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 26 15:09: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 BAAFD3A0D12; Fri, 26 Jun 2020 15:09: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, 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 r08X1sTeHBZ4; Fri, 26 Jun 2020 15:08:58 -0700 (PDT) Received: from aye.elm.relay.mailchannels.net (aye.elm.relay.mailchannels.net [23.83.212.6]) (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 1E4953A0D07; Fri, 26 Jun 2020 15:08:57 -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 764E5481008; Fri, 26 Jun 2020 22:08:56 +0000 (UTC) Received: from pdx1-sub0-mail-a15.g.dreamhost.com (100-96-23-5.trex.outbound.svc.cluster.local [100.96.23.5]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 01078480DE4; Fri, 26 Jun 2020 22:08:55 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a15.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); Fri, 26 Jun 2020 22:08:56 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Blushing-Bitter: 7c55c7e929ac9496_1593209336265_1978622880 X-MC-Loop-Signature: 1593209336265:1496277518 X-MC-Ingress-Time: 1593209336265 Received: from pdx1-sub0-mail-a15.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a15.g.dreamhost.com (Postfix) with ESMTP id B63967F05D; Fri, 26 Jun 2020 15:08:55 -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=MAtL7mc1RQlelr tiZ7Dbcty2CPM=; b=Qw3Nenffps3vu5lMBbHNALvon+WfynDAa3hopV8a6J/x8Y 37AKqK2ytu+rd50N9vfUdTizLd9WmyKEtfNB1LLygbuRjJAGTpaaVrIlAQ8mOE5a jlhAhcp0EQNHhOvaMEi1R38YCM0HEo0TG0vL5fQjveUdfd6fFZIprtinIUf8E= 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-a15.g.dreamhost.com (Postfix) with ESMTPSA id 7A90B7F073; Fri, 26 Jun 2020 15:08:52 -0700 (PDT) Date: Fri, 26 Jun 2020 17:08:49 -0500 X-DH-BACKEND: pdx1-sub0-mail-a15 From: Nico Williams To: Michael Richardson Cc: Russ Housley , Toerless Eckert , anima@ietf.org, Ben Kaduk , saag@ietf.org Message-ID: <20200626220847.GX3100@localhost> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <14352.1593208951@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14352.1593208951@localhost> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudelvddgtdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpefftdektefhueetveeigfefgeejteejvdfhhefgvddtfeeujeehleeguefhgffhgfenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: Subject: Re: [saag] towards using of MUST-/SHOULD+/SHOULD- in draft-ietf-autonomic-control-plane-24 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, 26 Jun 2020 22:09:02 -0000 On Fri, Jun 26, 2020 at 06:02:31PM -0400, Michael Richardson wrote: > I tried to convince Toerless to go with the MUST-/SHOULD+/SHOULD- > terminology from IPsecME's RFC8247. > > It would be nice if SAAG lifted section 1.1 into a BCP14-like > document, as I think that it has widespread applicability throughout > documents that want to establish interoperable crypto. Is there are reason that RFC8247's {MUST,SHOULD}[-+] wouldn't be generally applicable beyond crypto? The -/+ thing is about pithily indicating likelihood of future downgrade/upgrade of the requirement/ recommendation -- seems generally applicable to me. So.. just update RFC2119. Nico -- From nobody Fri Jun 26 16:58:44 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 D8F983A0D23 for ; Fri, 26 Jun 2020 16:58:31 -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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMRbuS5hDuPa for ; Fri, 26 Jun 2020 16:58:29 -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 36FF93A0D28 for ; Fri, 26 Jun 2020 16:58:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BF2B7300B40 for ; Fri, 26 Jun 2020 19:58:26 -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 FPfRi9W4AEnD for ; Fri, 26 Jun 2020 19:58:24 -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 F1CC6300A93; Fri, 26 Jun 2020 19:58:23 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_02CA01BA-1A25-4870-BBE0-2E93295B82B6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Fri, 26 Jun 2020 19:58:24 -0400 In-Reply-To: <14352.1593208951@localhost> Cc: Toerless Eckert , anima@ietf.org, Ben Kaduk , IETF SAAG To: Michael Richardson References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <14352.1593208951@localhost> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [saag] towards using of MUST-/SHOULD+/SHOULD- in draft-ietf-autonomic-control-plane-24 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, 26 Jun 2020 23:58:32 -0000 --Apple-Mail=_02CA01BA-1A25-4870-BBE0-2E93295B82B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jun 26, 2020, at 6:02 PM, Michael Richardson = wrote: >=20 >=20 > Russ Housley wrote: >>> ACP nodes MUST NOT support certificates with RSA public keys of >>> less than 2048 bits. They MUST support certificates with RSA public = keys >>> with 2048 bits and SHOULD support longer RSA keys. ACP nodes MUST >>> support certificates with ECC public keys using NIST P-256, P-384 = and >>> P-521 curves. >>>=20 >>> ACP nodes MUST support SHA-256, SHA-384, SHA-512 signatures for = certificates with RSA key and the same RSA signatures plus ECDSA = signatures for certificates with ECC key. >>> --- >>>=20 >>> I don't understand whether your note about the key length of the = curves is an indication of missing text. When i first reviewed with Ben, = i had to enter the curves because thats as specific as necessary AFAIK, = but given how the key length is implied, i wouldn't understand why i = would need to write those down. I don't remember that i have seen that = being done either in other RFCs i read through. >>>=20 >>> In any case, specific text suggestions always welcome in case this = text is not sufficient. >=20 > russ> I was expecting you to make one of the curves MUST and the = others > russ> SHOULD. Making all three curves MUST is okay with me, but it = will > russ> increase implementation size. >=20 > russ> Likewise, I was expecting you to make one of the hash = functions > russ> MUST and the others SHOULD. >=20 > I tried to convince Toerless to go with the MUST-/SHOULD+/SHOULD- = terminology from > IPsecME's RFC8247. >=20 > It would be nice if SAAG lifted section 1.1 into a BCP14-like = document, as I > think that it has widespread applicability throughout documents that = want to > establish interoperable crypto. IPsec ad S/MIME have been using MUST-/SHOULD+/SHOULD- terminology for a = long time. I'd be willing to help with a BCP14-like document for them. Russ --Apple-Mail=_02CA01BA-1A25-4870-BBE0-2E93295B82B6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCXvaLoAAKCRCK5O7Q9ZwR y2BmAJwNvF8oJw08D7VO4EynZHSzAzHJHQCeOFqoyE+Hn68YPzvZYfsSyfZTOmA= =jiQt -----END PGP SIGNATURE----- --Apple-Mail=_02CA01BA-1A25-4870-BBE0-2E93295B82B6-- From nobody Fri Jun 26 18:15: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 0B7E53A081B; Fri, 26 Jun 2020 18:15:26 -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 Om0Q-aw544Ye; Fri, 26 Jun 2020 18:15:23 -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 B09003A07C0; Fri, 26 Jun 2020 18:15:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E21E838995; Fri, 26 Jun 2020 21:12:36 -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 B53N7CRMATJJ; Fri, 26 Jun 2020 21:12:35 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 99FD538991; Fri, 26 Jun 2020 21:12:35 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 24DDE8D; Fri, 26 Jun 2020 21:15:19 -0400 (EDT) From: Michael Richardson To: Nico Williams , Russ Housley , Toerless Eckert , anima@ietf.org, Ben Kaduk , saag@ietf.org In-Reply-To: <20200626220847.GX3100@localhost> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <14352.1593208951@localhost> <20200626220847.GX3100@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] towards using of MUST-/SHOULD+/SHOULD- in draft-ietf-autonomic-control-plane-24 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, 27 Jun 2020 01:15:26 -0000 --=-=-= Content-Type: text/plain Nico Williams wrote: > On Fri, Jun 26, 2020 at 06:02:31PM -0400, Michael Richardson wrote: >> I tried to convince Toerless to go with the MUST-/SHOULD+/SHOULD- >> terminology from IPsecME's RFC8247. >> >> It would be nice if SAAG lifted section 1.1 into a BCP14-like >> document, as I think that it has widespread applicability throughout >> documents that want to establish interoperable crypto. > Is there are reason that RFC8247's {MUST,SHOULD}[-+] wouldn't be > generally applicable beyond crypto? The -/+ thing is about pithily > indicating likelihood of future downgrade/upgrade of the requirement/ > recommendation -- seems generally applicable to me. > So.. just update RFC2119. 1) So, BCPs can point to multiple documents. BCP14 actually is RFC2119 and RFC8174 now, so we can add a third document if desired. That is, it's cheaper to not spin 2119. 2) I'm not claiming others won't use it, I just don't know if they will. Crypto progresses... what other things do that in the same way? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl72naYACgkQgItw+93Q 3WXsoQf+L9M3Ebcm6GI5Ma6zqE4hjTE+Rfv0yvvOjwFCIdQlTdV+1WeyPOxxgZ5a baa0+AEABL579bkC4lgCOPgbOTOFXZ1LcJTHgPAbYRwaQE+BtOkl6uwCJNdy6kfz Dd3CZMt1W9tjtwLPKol4ITlPMAs1FiG9UXWI8qa5TEOxGGZ6Qxmd1iSCggVVa+vc vtogptRIfGQVsZyR19qSFP0b33c0uP+szU11UEDytABCLaCjkYMR8W3xrIqJ4/9o 9/gdJDWS9NpgIam9D0ZKlKC3qtoY5OSaelSsm8w5MB5jLG8g3xyJAhGlvWiF/DSL aclVlf22Xe6LWWYZh0gtgT4eWzBqZA== =7i90 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 26 20:06: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 B87CB3A098C; Fri, 26 Jun 2020 20:06:40 -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 kmK04TAA918v; Fri, 26 Jun 2020 20:06:39 -0700 (PDT) Received: from black.elm.relay.mailchannels.net (black.elm.relay.mailchannels.net [23.83.212.19]) (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 A7CDE3A097F; Fri, 26 Jun 2020 20:06:38 -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 7E5867E14A2; Sat, 27 Jun 2020 03:06:37 +0000 (UTC) Received: from pdx1-sub0-mail-a37.g.dreamhost.com (100-96-19-6.trex.outbound.svc.cluster.local [100.96.19.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id E9EB47E10FA; Sat, 27 Jun 2020 03:06:36 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a37.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); Sat, 27 Jun 2020 03:06:37 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Robust-Cooing: 3b4d6dea220e19b7_1593227197341_2479348239 X-MC-Loop-Signature: 1593227197341:3968239992 X-MC-Ingress-Time: 1593227197341 Received: from pdx1-sub0-mail-a37.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a37.g.dreamhost.com (Postfix) with ESMTP id A5610B2B2E; Fri, 26 Jun 2020 20:06:36 -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=TeAOYnjQ+LfNgP 0rg6wD32hlTeM=; b=JILNocdWuDCvUVd4E0OaEdFVzJSJpurs69E/Pr8PH9m/8p ZkHs40RHqFCenOF2RyyzhAynEiPcU2SRDCXqA3k47gOb3T7HoGEZSRFhcVgIROaf A2HXFw1DnPB7peYuipo8ZNn9YWqcngdBbGIazg6Y+nyYlXVA2gjcN6oFlkoOY= 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-a37.g.dreamhost.com (Postfix) with ESMTPSA id A8F66B2B34; Fri, 26 Jun 2020 20:06:30 -0700 (PDT) Date: Fri, 26 Jun 2020 22:06:24 -0500 X-DH-BACKEND: pdx1-sub0-mail-a37 From: Nico Williams To: Michael Richardson Cc: Russ Housley , Toerless Eckert , anima@ietf.org, Ben Kaduk , saag@ietf.org Message-ID: <20200627030622.GZ3100@localhost> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <14352.1593208951@localhost> <20200626220847.GX3100@localhost> <30682.1593220519@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30682.1593220519@localhost> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudelvddgieekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpefftdektefhueetveeigfefgeejteejvdfhhefgvddtfeeujeehleeguefhgffhgfenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: Subject: Re: [saag] towards using of MUST-/SHOULD+/SHOULD- in draft-ietf-autonomic-control-plane-24 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, 27 Jun 2020 03:06:41 -0000 On Fri, Jun 26, 2020 at 09:15:19PM -0400, Michael Richardson wrote: > 1) So, BCPs can point to multiple documents. > BCP14 actually is RFC2119 and RFC8174 now, so we can add a third document if > desired. That is, it's cheaper to not spin 2119. Sure. Plus, RFC2119 is iconic, and used far and wide outside the IETF. > 2) I'm not claiming others won't use it, I just don't know if they will. > Crypto progresses... what other things do that in the same way? Any time we have a migration from one [sub]protocol to a newer one and need to retain support for the old one for a while, we will need something like SHOULD-. I agree this comes up most often in the context of cryptographic algorithms. Nico -- From nobody Fri Jun 26 21:05: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 EE5603A0B85; Fri, 26 Jun 2020 21:05:49 -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, FREEMAIL_FROM=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 Qc9DdkuM4s4S; Fri, 26 Jun 2020 21:05:48 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 352783A0953; Fri, 26 Jun 2020 21:05:48 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id u8so5503910pje.4; Fri, 26 Jun 2020 21:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tIv/z/6v49g8/FPZgdYr94yCU4plDr13jrNrcDntvaM=; b=YnJe3/vzxFoZgPQhhTn45EIQeYdAHB+5wQdmO1gn0gccyA6fElGnh37PK8aJUCDi8v aVGM4wsSLChYKVadyu5gfZXHK45kulT+Jx8tQKcl9QHYsXtKm28YPQifyq1DFsDwOs5f o3Xe1sNWiU3/nQZIAv7IprBa5/5vRb99JBgz3dX/OCHkMV+V67Aq5f/+RkJLEzqEhJeB EDmCZXiYRff5b5UI95Gz5tDJrFIVY5M2c+UI4iW8KE6K1WK+BFSToMC7kAT472W1LYpc wwZuSxKuoH1p7aB4rPtb3/x/Pt6SWd0jhzYYBI2xar9fGtgx4WiKvzY0nUBvycUFo2SH 6IjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tIv/z/6v49g8/FPZgdYr94yCU4plDr13jrNrcDntvaM=; b=qZVRmDXBLdF9/zKIc/no7ncNRbAx4bG/un+gSdDJFzumxXqoK81mFgBhEf4XYbT7l7 ujmknPgWY37YZYVWwqnHdM565Ls33wllEY3u+sfCpSOj9pWDxXTBMLogf6kwBHHXUYHh dnRXBLJuev1ITiz8rqEY/uDjlyvGrD9e89yGse/NRmsBfvZRjRzYrQC7dz3haBD4Utuc GBlGA4RpdiCgajz0tLQDWXwdezWGhgtKitgcMJbZBxtBjZNfAm9EJGhyhhiGzt/pRyUS xz5OYU4T/rqmDuJJKXvjslJXJ97opr6n5IhByL/Kn337eXuu+nKvdaRpQq83OMKmO4aA 64lA== X-Gm-Message-State: AOAM5311XlRoWLehHhfvZpZHqAoqwpMd3KjUWYPHjK/w78C+1V2qWLGV xMZmo4k5ictM+3i7dONt8sx7D+K1B6Q= X-Google-Smtp-Source: ABdhPJzks4sPVyuC8FxmrQznUw7h1XB9lW4OJNfUztLc8I6UEm+5Fa5kI2/Rnjcihox3JH8Cjw/Fiw== X-Received: by 2002:a17:902:8f83:: with SMTP id z3mr5016064plo.203.1593230747453; Fri, 26 Jun 2020 21:05:47 -0700 (PDT) Received: from [192.168.178.20] (203.90.69.111.dynamic.snap.net.nz. [111.69.90.203]) by smtp.gmail.com with ESMTPSA id c187sm3465174pfc.146.2020.06.26.21.05.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2020 21:05:46 -0700 (PDT) To: Nico Williams , Michael Richardson Cc: Toerless Eckert , Russ Housley , Ben Kaduk , anima@ietf.org, saag@ietf.org References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <14352.1593208951@localhost> <20200626220847.GX3100@localhost> <30682.1593220519@localhost> <20200627030622.GZ3100@localhost> From: Brian E Carpenter Message-ID: Date: Sat, 27 Jun 2020 16:05:41 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200627030622.GZ3100@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] [Anima] towards using of MUST-/SHOULD+/SHOULD- in draft-ietf-autonomic-control-plane-24 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, 27 Jun 2020 04:05:50 -0000 On 27-Jun-20 15:06, Nico Williams wrote: > On Fri, Jun 26, 2020 at 09:15:19PM -0400, Michael Richardson wrote: >> 1) So, BCPs can point to multiple documents. >> BCP14 actually is RFC2119 and RFC8174 now, so we can add a third document if >> desired. That is, it's cheaper to not spin 2119. > > Sure. Plus, RFC2119 is iconic, and used far and wide outside the IETF. > >> 2) I'm not claiming others won't use it, I just don't know if they will. >> Crypto progresses... what other things do that in the same way? > > Any time we have a migration from one [sub]protocol to a newer one and > need to retain support for the old one for a while, we will need > something like SHOULD-. I agree this comes up most often in the context > of cryptographic algorithms. Interesting discussion but I want to see the ACP in the RFC Editor queue, can we just do what is required for that and nothing else? I am about a millimetre away from proposing to recall the GRASP spec from the RFC Editor so that we can amputate its normative dependency on the ACP. I really wish I'd done that a year ago. Grumpy Brian From nobody Fri Jun 26 22:01: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 031863A0CBB; Fri, 26 Jun 2020 22:01:51 -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 mFynQbu-asz7; Fri, 26 Jun 2020 22:01:49 -0700 (PDT) Received: from beige.elm.relay.mailchannels.net (beige.elm.relay.mailchannels.net [23.83.212.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 C61F23A0CB9; Fri, 26 Jun 2020 22:01:48 -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 BF9E148107B; Sat, 27 Jun 2020 05:01:47 +0000 (UTC) Received: from pdx1-sub0-mail-a18.g.dreamhost.com (100-96-23-5.trex.outbound.svc.cluster.local [100.96.23.5]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 37AE8480BDB; Sat, 27 Jun 2020 05:01:47 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a18.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); Sat, 27 Jun 2020 05:01:47 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Keen-Descriptive: 454fd1da55862d3c_1593234107584_3040401124 X-MC-Loop-Signature: 1593234107584:2566361195 X-MC-Ingress-Time: 1593234107584 Received: from pdx1-sub0-mail-a18.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTP id C68C880022; Fri, 26 Jun 2020 22:01:46 -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=2UG8g3ilcgqCNP rrniikSOxzUvA=; b=W2twSAMvdP0HHpl1/B2bMq9Y5/8zemOkW3/93buzYrjL1e siUOXviMbOukrKAMsxFY7NIXKBU3Uomj1sM2APXscm36w27JQmO1zYgqJbfOVlO+ tHcYt8WUgMonQqTdQnJ4nUH08gYmTpVqbbmF2+qEkB2XItCSxZL3JfSSIllnA= 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-a18.g.dreamhost.com (Postfix) with ESMTPSA id 228BA80024; Fri, 26 Jun 2020 22:01:43 -0700 (PDT) Date: Sat, 27 Jun 2020 00:01:38 -0500 X-DH-BACKEND: pdx1-sub0-mail-a18 From: Nico Williams To: Brian E Carpenter Cc: Michael Richardson , Toerless Eckert , Russ Housley , Ben Kaduk , anima@ietf.org, saag@ietf.org Message-ID: <20200627050137.GA3100@localhost> References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <14352.1593208951@localhost> <20200626220847.GX3100@localhost> <30682.1593220519@localhost> <20200627030622.GZ3100@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudelvddgledvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpefftdektefhueetveeigfefgeejteejvdfhhefgvddtfeeujeehleeguefhgffhgfenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: Subject: Re: [saag] [Anima] towards using of MUST-/SHOULD+/SHOULD- in draft-ietf-autonomic-control-plane-24 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, 27 Jun 2020 05:01:51 -0000 On Sat, Jun 27, 2020 at 04:05:41PM +1200, Brian E Carpenter wrote: > Interesting discussion but I want to see the ACP in the RFC Editor > queue, can we just do what is required for that and nothing else? > > I am about a millimetre away from proposing to recall the GRASP spec > from the RFC Editor so that we can amputate its normative dependency > on the ACP. I really wish I'd done that a year ago. I don't follow GRASP, or ACP, so I've no idea what you're talking about, but I don't see how this discussion could keep ACP from progressing. In particular, no one is proposing to update BCP14 and make that a prereq for ACP progressing. Nico -- From nobody Fri Jun 26 22:06: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 213EC3A0CBB; Fri, 26 Jun 2020 22:06:01 -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, FREEMAIL_FROM=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 2vW2izCFK4S5; Fri, 26 Jun 2020 22:05:59 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 688723A0CB9; Fri, 26 Jun 2020 22:05:59 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id 35so5067478ple.0; Fri, 26 Jun 2020 22:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=b3ZGYOfnjzPdp8Fwn/7oQlPe8rw3F2LdzpYL7PkXSDI=; b=Ccqg9hmqvDH0kPmxzKLVVRQ6+zYDOiZ/qF0Kj4bZDCkdOxIEdyxO0bONe3e2mpRLP+ ghvfNWljl/eq923cT4jLNlayq+0BVNMgZx/HhN6m/QiWEAJ/gFQODXR7K+VB9E5lyWAz nw+Ric4FkfLoSVBZ3RRHLoHvg00TjXQwMwU7pvZdida5uj6+QNuGthFYLrFbVeGyU5ZK xyqnMsyYKm/xbF8xKBn0gEg4nwQZcu+vBHFQMdjMmdYwHbbcewr215LDqE1PtLMDugiy oX+raHnr1dCJHLu8IXoqbBknyFjRlfx6aCdV5S3IwtUP8Q05fmv/HxvTMx4jUfhcN46C +rGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=b3ZGYOfnjzPdp8Fwn/7oQlPe8rw3F2LdzpYL7PkXSDI=; b=D0qOlWu31YC5//KwCHHYpQKePB78mozpnceumlVuFHaVvSEear1o11rpOOEoPIJw5g +T1G019v9rIn8riDtqktAHqcgB8UyJEfmHBzGtRnCKPS16n/nHDnR3iimPukt1H0pP4g 7LMcrnRUjuNWkJqwpRgpzYPyukFpELL1/tQTCeTUqy5Scfosa70+8ROEG0UX1Br1jsYV akGR3j8lPv4LtYMDT/vdmtB0GupTWET1OAATt4ZELD7tKKDZidiofSQnr/2Kpg5Fqa8C 5TBhE14Z6KQ8E5RJrbFltf1R6kIEavJQruakT652ccd3kQUHzbTDBc+PHLM0CtwZcfXZ 8Y8A== X-Gm-Message-State: AOAM533q94P2gIfW/D038Mb8TPy20DKajyIT7XRYlrPt4tnnIFiiN7i1 OZz6H/WHdeEjwzcgBW6uwe84O8mCbeg= X-Google-Smtp-Source: ABdhPJxt7AFvc+Ylq05Sh5lDaFN0wluwDnIuF20jA66Wu7IZSEcWXylEvLuotyqOD6Z7r5uFddCN+w== X-Received: by 2002:a17:90a:ac0f:: with SMTP id o15mr6878088pjq.105.1593234358781; Fri, 26 Jun 2020 22:05:58 -0700 (PDT) Received: from [192.168.178.20] (203.90.69.111.dynamic.snap.net.nz. [111.69.90.203]) by smtp.gmail.com with ESMTPSA id gm11sm12864741pjb.9.2020.06.26.22.05.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jun 2020 22:05:58 -0700 (PDT) To: Nico Williams Cc: Michael Richardson , Toerless Eckert , Russ Housley , Ben Kaduk , anima@ietf.org, saag@ietf.org References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <14352.1593208951@localhost> <20200626220847.GX3100@localhost> <30682.1593220519@localhost> <20200627030622.GZ3100@localhost> <20200627050137.GA3100@localhost> From: Brian E Carpenter Message-ID: <41d2ee93-7a2a-ba3c-f527-06a1748444b3@gmail.com> Date: Sat, 27 Jun 2020 17:05:53 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200627050137.GA3100@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] [Anima] towards using of MUST-/SHOULD+/SHOULD- in draft-ietf-autonomic-control-plane-24 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, 27 Jun 2020 05:06:01 -0000 On 27-Jun-20 17:01, Nico Williams wrote: > On Sat, Jun 27, 2020 at 04:05:41PM +1200, Brian E Carpenter wrote: >> Interesting discussion but I want to see the ACP in the RFC Editor >> queue, can we just do what is required for that and nothing else? >> >> I am about a millimetre away from proposing to recall the GRASP spec >> from the RFC Editor so that we can amputate its normative dependency >> on the ACP. I really wish I'd done that a year ago. > > I don't follow GRASP, or ACP, so I've no idea what you're talking about, > but I don't see how this discussion could keep ACP from progressing. In > particular, no one is proposing to update BCP14 and make that a prereq > for ACP progressing. Sorry about my tone, but this seems like a discussion for gendispatch, not anima. Brian From nobody Fri Jun 26 22: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 BA9993A0D29; Fri, 26 Jun 2020 22:12:46 -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 7CbS-8D7RPU8; Fri, 26 Jun 2020 22:12:45 -0700 (PDT) Received: from guinea.birch.relay.mailchannels.net (guinea.birch.relay.mailchannels.net [23.83.209.79]) (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 9D8FF3A0D25; Fri, 26 Jun 2020 22:12:43 -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 8E338181110; Sat, 27 Jun 2020 05:12:42 +0000 (UTC) Received: from pdx1-sub0-mail-a18.g.dreamhost.com (100-96-23-8.trex.outbound.svc.cluster.local [100.96.23.8]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id EDD3E1813A2; Sat, 27 Jun 2020 05:12:37 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a18.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); Sat, 27 Jun 2020 05:12:42 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Troubled-Lonely: 7e1c574b164d39c9_1593234762284_1659966079 X-MC-Loop-Signature: 1593234762284:1693100779 X-MC-Ingress-Time: 1593234762284 Received: from pdx1-sub0-mail-a18.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a18.g.dreamhost.com (Postfix) with ESMTP id A4DED80028; Fri, 26 Jun 2020 22:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=a82ZsXbUVfAcuE q4Ocqgmw64nWA=; b=sPIz4wyq94d06RQTb90qqHnnv6Mwa+yS5993g5UJMW3845 qHU+SD0OCIj5Imhh8jh4r/Pawu96fHP+ISZsJsThSjf+uYR//DUKlF951K2Zrvj/ bWyb+r36JZqPmk9wRLU0ZRIjpwxR1xYAS2PhEF31gFo7iachRrQtvK1SADQH8= 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-a18.g.dreamhost.com (Postfix) with ESMTPSA id 0D04580026; Fri, 26 Jun 2020 22:12:33 -0700 (PDT) Date: Sat, 27 Jun 2020 00:12:30 -0500 X-DH-BACKEND: pdx1-sub0-mail-a18 From: Nico Williams To: Brian E Carpenter Cc: Michael Richardson , Toerless Eckert , Russ Housley , Ben Kaduk , anima@ietf.org, saag@ietf.org Message-ID: <20200627051229.GB3100@localhost> Reply-To: saag@ietf.org References: <20200624023407.GA41244@faui48f.informatik.uni-erlangen.de> <14352.1593208951@localhost> <20200626220847.GX3100@localhost> <30682.1593220519@localhost> <20200627030622.GZ3100@localhost> <20200627050137.GA3100@localhost> <41d2ee93-7a2a-ba3c-f527-06a1748444b3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41d2ee93-7a2a-ba3c-f527-06a1748444b3@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudelvddgleegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhrfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecuggftrfgrthhtvghrnhephedvhfevleefffevheetgeekjeeihefhueeugffhfeevhfettddtiedugfeghefgnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh Archived-At: Subject: Re: [saag] [Anima] towards using of MUST-/SHOULD+/SHOULD- in draft-ietf-autonomic-control-plane-24 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, 27 Jun 2020 05:12:47 -0000 On Sat, Jun 27, 2020 at 05:05:53PM +1200, Brian E Carpenter wrote: > Sorry about my tone, but this seems like a discussion for gendispatch, > not anima. Well, look at the distribution list: Michael clearly meant for SAAG to see this, and for anima to see his post in case anyone there cares. I agree that some other list might be better still, and setting Reply-To: would have helped keep noise down on anima. I'm setting Reply-To: now. From nobody Mon Jun 29 18:00:20 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 7EB233A0EED for ; Mon, 29 Jun 2020 18:00:18 -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 19UZfL5NEJyJ for ; Mon, 29 Jun 2020 18:00:16 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 472EC3A0EEA for ; Mon, 29 Jun 2020 18:00:16 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id 9so20480854ljv.5 for ; Mon, 29 Jun 2020 18:00:16 -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=NkYnxQEum5VCcUYmn4jELm3W207v3ZHJfLLeoCska0Q=; b=tEzrAv7oLirchBe37I+ar9VJ5F8xNR/qyOOiFbp1PJDFVSlHZgM1Hx3Uab/C0Sq9K4 iuhllqAqY661Nw6q06S8JY5zGFpMs7+0tIa5jX70qjc6cdXNbQfc9vXxrQ+JXrDqRfxS J5rNAzV8hoJqLOqnNK9DJ9194rr9zRNsQ7wJtIPfr9Wq3WNtUV7Sb2QYk1WtbUVIs6+y wOAIse9OOy2TdyfP3uv6PQn8ynGnoQ59QBDnW/hrEb+84097MA9/OxDDmKDyq0+xNYH4 G533NZOv4jJNSE/JXjAkuUQ0N0kUV2c0wBozyDotfiUm74Sx+nwlwVr9NscLitJflOQJ 4KWg== 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=NkYnxQEum5VCcUYmn4jELm3W207v3ZHJfLLeoCska0Q=; b=TFZIWtyldmbOxooF2nhhZD/FuysvbwUPqPIq3Of1GLggpRcKCTBzT8Huwha+TRfMrc EmWcvJIm1sSYB86ilcgq1Vrvx5N47CwX7THBQlmLx3/W2isKS9GYPJC7Xsi7wLOY86RA CxC8CPbiELeA3R5w8EVpafDrwFabq0EvojoXLFlrvCEhfokvc3mlM15+4EkEdYXViLi0 fVULDWPMGt+zb32KVU91pclsdqrVkjuQJB7P6oLBKZDOA1y4iidi9TdoR9f+iDDPUWcx 61rHYZQaqbHsel7AN8IkuIVwIg54hk8oBtu1HOFLGsZbMJcm+rfX+aVjzLG75StmIa+7 0PJQ== X-Gm-Message-State: AOAM533VzXzG+G+IpT2Smchf9wQFnhty7LElnmdMBuT2FXunhzoDCgT6 F8BoVP3sReLw485DiikeN8JrsdBI3ErHiERBKXaZFA== X-Google-Smtp-Source: ABdhPJz5CCHE7nJJf2Elo7RQP/IMh4cAdpbvUSE5hPYJeEbbBqABKyB4LkCazUYjfvq1PB+tIHsOYTcoOWnYr7LWv6w= X-Received: by 2002:a2e:8092:: with SMTP id i18mr1258584ljg.265.1593478814391; Mon, 29 Jun 2020 18:00:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Mon, 29 Jun 2020 17:59:38 -0700 Message-ID: To: "Black, David" Cc: "tsvwg@ietf.org" , int-area , IETF SAAG Content-Type: multipart/alternative; boundary="000000000000b0732f05a942b220" 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: Tue, 30 Jun 2020 01:00:19 -0000 --000000000000b0732f05a942b220 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > 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/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. 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. 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. 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. 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#sect= ion-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. --000000000000b0732f05a942b220 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>
> This 3rd WGLC is limited to the following tw= o topics:
> =C2=A0
>
> =C2=A0 =C2=A0 Whether or not to p= roceed with a request for RFC publication
>
> of the draft. = =C2=A0 The decision on whether or not to proceed will
> be based on r= ough consensus of the WG, see RFC 7282.
> During the 2nd WGLC, Eric R= escorla and David Schinazi expressed
> strong views that this draft s= hould not be published =E2=80=93 =C2=A0those
> concerns have not been= resolved and are carried forward to
> this WGLC.=C2=A0 This email me= ssage was an attempt to summarize
> those concerns:
>
> = https://mailarchive.ietf.org/arch/msg/tsvwg/i4qyY1HRqKwm0Jme9UtEb= 6DyhXU/
>
> Further explanation from both Eric Rescorla an= d David Schinazi
> is welcome and encouraged to ensure that their con= cerns are
> clearly understood.

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

For rea= sons that are laid out in RFC 7258, the trend in protocol
design in IETF= is towards encrypting more and more. The last two
transport protocols t= hat were designed and widely deployed (SCTP over
DTLS and QUIC) both enc= rypt the vast majority of the protocol
metadata. This document advertise= s itself as "considerations"
for design of such protocols:
=
=C2=A0 =C2=A0The transport protocols developed for the Internet are use= d across a
=C2=A0 =C2=A0wide range of paths across network segments with= many different
=C2=A0 =C2=A0regulatory, commercial, and engineering con= siderations.=C2=A0 This
=C2=A0 =C2=A0document considers some of the cost= s and changes to network
=C2=A0 =C2=A0management and research that are i= mplied by widespread use of
=C2=A0 =C2=A0transport protocols that encryp= t their transport header information.
=C2=A0 =C2=A0It reviews the implic= ations of developing transport protocols that
=C2=A0 =C2=A0use end-to-en= d encryption to provide confidentiality of their
=C2=A0 =C2=A0transport = layer headers, and considers the effect of such changes on
=C2=A0 =C2=A0= transport protocol design, transport protocol evolution, and network
=C2= =A0 =C2=A0operations.=C2=A0 It also considers some anticipated implications= on
=C2=A0 =C2=A0application evolution.=C2=A0 This provides consideratio= ns relating to the
=C2=A0 =C2=A0design of transport protocols and featur= es where the transport
=C2=A0 =C2=A0protocol encrypts some or all of the= ir header information.

However, as I said above, the new transport p= rotocols that are
actually being designed already feature metadata encry= ption and as far
as I can tell, there is no prospective protocol new tra= nsport protocol
design project for which these issues might be live. In = that context,
it's hard not to read this document with its long lita= ny 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.<= br>

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

- Blocking traffic based on TCP port, IP address, SNI, etc.<= br>
- Performance-based traffic class discrimination

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

Yes, I understand that the authors explici= tly 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 practic= es to focus on is extremely
telling. Focusing on the downsides of encryp= tion for (at least
arguably well-meaning) network players while mostly i= gnoring the large
class of non-benign behaviors which encryption is inte= nded to protect
against has the effect of overemphasizing the costs of e= ncryption to
those players and minimizing the benefits to the endpoints = whom it is
intended to protect.


To be maximally clear: I don&= #39;t object to this document existing
and I don't think that the op= inions implicit in it are ones that
should not be expressed. I merely do= n'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#section-5
[1] =C2=A0 =C2=A0Ano= ther motivation stems from increased concerns about privacy 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 traffic.
=C2=A0 =C2=A0 =C2=A0 Revelations about the use of pervas= ive surveillance [RFC7624]
=C2=A0 =C2=A0 =C2=A0 have, to some extent, er= oded trust in the service offered by
=C2=A0 =C2=A0 =C2=A0 network operat= ors 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, cust= omisation, advertising,
=C2=A0 =C2=A0 =C2=A0 cross-site tracking of user= s, 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 IET= F is designing protocols that include transport header
=C2=A0 =C2=A0 =C2= =A0 encryption (e.g., QUIC [I-D.ietf-quic-transport]) to supplement
=C2= =A0 =C2=A0 =C2=A0 the already widespread payload encryption, and to further= limit
=C2=A0 =C2=A0 =C2=A0 exposure of transport metadata to the networ= k.
=C2=A0








--000000000000b0732f05a942b220-- From nobody Mon Jun 29 22:49: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 1CBAE3A0848; Mon, 29 Jun 2020 22:49:49 -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=3K/D/wdB; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=3K/D/wdB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckp8myi43t53; Mon, 29 Jun 2020 22:49:46 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150049.outbound.protection.outlook.com [40.107.15.49]) (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 D46E83A0843; Mon, 29 Jun 2020 22:49:44 -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=DHNY6e6drQpb5LLjwN3jXSqT+h+DsNJZfOGjk1VjNdU=; b=3K/D/wdBS3cOmeB6fme2sDKnmVBJYrXCRJY3KnpfPofXLFubc4jfCEUO/HoknVL5VnoXHgivD7463EZQglPLuzekCuUkY6P0l3PjgAyHPeyl2lb+t9jO57Wlt4+3651ncn9SM0zvkokxiS6jEZ9oY92qf12eOq+ARwaa6lHaf4c= Received: from AM6P194CA0063.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:84::40) by DB7PR08MB3163.eurprd08.prod.outlook.com (2603:10a6:5:1e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.24; Tue, 30 Jun 2020 05:49:42 +0000 Received: from VE1EUR03FT010.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:84:cafe::22) by AM6P194CA0063.outlook.office365.com (2603:10a6:209:84::40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21 via Frontend Transport; Tue, 30 Jun 2020 05:49:41 +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 VE1EUR03FT010.mail.protection.outlook.com (10.152.18.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Tue, 30 Jun 2020 05:49:41 +0000 Received: ("Tessian outbound 1e00bf306733:v60"); Tue, 30 Jun 2020 05:49:41 +0000 X-CR-MTA-TID: 64aa7808 Received: from b3a7da81ee79.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 7E9EB3E3-3243-4B16-8922-C2FC23E844C6.1; Tue, 30 Jun 2020 05:49:36 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id b3a7da81ee79.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 30 Jun 2020 05:49:36 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Evz9uSOzx1HPapjKRnTDQs10s/oeU4RzhAcmWHYNa3yzOejP51lrNPKTC/mml+os3aWKcdRumNK04Y0TQYHpKrSZPPsNF2XkpfEAvPCCFl7zlYJJpGPa/nFrnsnchwBw+gMRB8o5Mu3fY3BJhOHKHQ6+1QIozjpYyTSDzetc+CgDWf806TV/V9ItJmh5whg9ZLzU7ezb9iYM8O1GAaNBwsoOaNip19syBeAmVfjrNNdxh7aQhAKAuzzj1uf751gKFIGnqgmgrp8DUsLD3yXo7KKcAjoVILwpvOdkk6+MxXfUWLPlqh/UV0ejzah3POCavovUOB3QPrDsdrkft7HAzA== 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=DHNY6e6drQpb5LLjwN3jXSqT+h+DsNJZfOGjk1VjNdU=; b=cTYyrJvwuUMi6BSBced+81h12m+/x8GJZZREf4QPi0BC7X4P1uFVXfSoAr8x5pSi40JZk8dwm4d8tHTyitfSNQIUlfNWt3WfMumP1WsAoivrQ8W1Vwsiw7x+XFRqhEf9n3t7aQqFn0nKKc9ynY0evK6kwRiDjpeQEE6H+N/hhGtQ3IorsX5LWfA9Pg+MtLjHwiTvzYeXPbCjeQniIWzkdXtvwI+tAfilYFB0vfoMHVK04MPCsTfoWU8hJ14zYhW3FoTNaMSf9VR2BFfzNsof99rdXHJmn2iO93FK5Tp9A9hJ5AyXhxHMqlHRWK+NvxkRvGs3+UeN+329UKoSachCjg== 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=DHNY6e6drQpb5LLjwN3jXSqT+h+DsNJZfOGjk1VjNdU=; b=3K/D/wdBS3cOmeB6fme2sDKnmVBJYrXCRJY3KnpfPofXLFubc4jfCEUO/HoknVL5VnoXHgivD7463EZQglPLuzekCuUkY6P0l3PjgAyHPeyl2lb+t9jO57Wlt4+3651ncn9SM0zvkokxiS6jEZ9oY92qf12eOq+ARwaa6lHaf4c= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB4979.eurprd08.prod.outlook.com (2603:10a6:208:15e::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.24; Tue, 30 Jun 2020 05:49:34 +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.027; Tue, 30 Jun 2020 05:49:34 +0000 From: Hannes Tschofenig To: Eric Rescorla , "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/CbSKeZ9xMZ8uq3SAQe3d4AAAnHrZA= Date: Tue, 30 Jun 2020 05:49:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: dad07de4-f3cf-4a4b-ba7b-bc9211a08c0b.1 x-checkrecipientchecked: true Authentication-Results-Original: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.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: 1117347e-e5d2-4c59-b1bd-08d81cb96242 x-ms-traffictypediagnostic: AM0PR08MB4979:|DB7PR08MB3163: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; x-forefront-prvs: 0450A714CB X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: P5kKRKjft1orSy83BGivXVLb3i68w3DoP59wGxpk8jIDAtySok6XrN3HP8RM/V9TmY3aKoX4r+GTW3uMbJON1PSMQ7jNcQ7MY+1hpylnE7T/xbK1wa9w6fL+fTmzGe5nZIuMBovVW/C/co7zvki/QekwNDSB5vGsfMZVE5wKRUQPsp+qc97hbUlMGVbJyHjfE6gOt8yrQX8ha77LzaeVOMyOXz3bf8IStwBf8ecSSmiHZWtgD54b9OXc0YTf8faNVUrelvGibVnwdvjJUxNPDXMxi06NBreDIUHB+Ic2HNjHe+RJ3s9F5hMq4PJHnkeFyXR/VTLdH0n46aiit8Wmr5PAiDrwZruqyaWgo53GqKpEqmjkeMvZd83tirSynd6W6auXyCNZIfwHKdWV64VXZw== 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)(136003)(396003)(39860400002)(346002)(376002)(366004)(86362001)(9686003)(71200400001)(55016002)(478600001)(8936002)(53546011)(26005)(966005)(6506007)(8676002)(186003)(76116006)(66476007)(316002)(7696005)(66946007)(66446008)(54906003)(5660300002)(64756008)(66556008)(83380400001)(66574015)(166002)(52536014)(33656002)(2906002)(110136005)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: JmzwwLeFhHjl659V2ejWuDYtagtgX0WYQdtteWBskMAiYpT2aCSPXcrVHENFtt/mqgryCOxgIELjvbhENGfnEuvFCwc4rX5VKolvZ9plfyhsca55IqDa5nq8BYro1Zk8HlnSAndQO7QCgSr1gg3pXxpaiGrKuBSYkFQrzHy2ZV89+bCHcsHih5/Yo0cFjjRwd08UAVKVT33kc5MgFLTpkMcycFUSQbNotekib5F0Ls50ivHCgCn+mHGnwCWPGgkJ6hRkJOq4uz2l100t/V497uW20AC1rTsbXGl25L1DHrnMzsGAi/mLbENUO0TyWmICkBsaHXTDRVFVFbmXI5vePXUr/9Tn3LcqL2FnRUuWbR33fhTQ9aLwek7vbb/vd85+Ok5zFbue1I8XjZ8vRopCLwIeTV306dl5DNmsUMQGQKQ2YwqhOiHQrxwYLxbWb0uZrMcSjcnRGVyZLrZ+kF5YiL/8yF5ya8hBEYeYNAGX/FAWCxxyHVRCAxANhAu5nfPu x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB3716528B48BCF9447002B551FA6F0AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4979 Original-Authentication-Results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT010.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)(136003)(396003)(39860400002)(346002)(376002)(46966005)(9686003)(166002)(356005)(30864003)(82740400003)(5660300002)(966005)(55016002)(8936002)(81166007)(82310400002)(47076004)(7696005)(336012)(33964004)(2906002)(53546011)(6506007)(86362001)(450100002)(110136005)(33656002)(26005)(186003)(66574015)(8676002)(54906003)(70586007)(70206006)(316002)(36906005)(52536014)(83380400001)(4326008)(478600001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: aecb4ccd-8b76-4d7d-c254-08d81cb95df1 X-Forefront-PRVS: 0450A714CB X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: x8h04QvxD28yGgRQq31JIwlKb53NOTZYZKnZdjbuKcPU5RkaVc82Wv/w/O+CKeVPqSF1WRC4rjZT+LlnjrWWQoCOhecH7yJCOa68MTlb9UwvDhBi0VrkGf+X77Nzq560lBSq2xMLho0gbAz8PWVI9vXKPNsBJ5fNo7BEjdY1PR51x/U+pZGY7otHFHTVQkZmzGEgodPVi+y+4Uynl0pNcpWguxcX5fKCa6S6HSdEX7zve2+n6gGgze0jG1DT0/f9MWD8uFT882rHYfYTEz+G3/O3Q6vqlR+8/vAzlhqexYaB9XSwpfRPaUJ5FR7z9AuoMEfIU7ztLjrfWW8iZBD3aySP/3m7zEFeSkaSUBtEwjPfr/6m2PG9Nhqlh6dtuu5fnKdTY3LrbDIqTUfjdzLyAdnrtFb7Sw1nYbc4XQOK8k5uuhcRsna9eqVrtWsrryrXgqkz1gklST/Y+1pnrerZBmaLoAZ1R0/0+9QrIkuAXJ0= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jun 2020 05:49:41.4141 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1117347e-e5d2-4c59-b1bd-08d81cb96242 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: VE1EUR03FT010.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3163 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: Tue, 30 Jun 2020 05:49:49 -0000 --_000_AM0PR08MB3716528B48BCF9447002B551FA6F0AM0PR08MB3716eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIHRoaXMgZG9jdW1lbnQgc2lnbmFscyBhIHdyb25nIG1lc3NhZ2UgdG8gdGhlIHdp ZGVyIEludGVybmV0IGNvbW11bml0eS4gSSBhZ3JlZSB0aGF0IGl0IHNob3VsZCBub3QgYmUgcHVi bGlzaGVkIGFzIGEgY29uc2Vuc3VzIGRvY3VtZW50Lg0KDQpJIHVuZGVyc3RhbmQgdGhhdCBzb21l IHBlb3BsZSBhcmUgdW5oYXBweSBhYm91dCBlbmNyeXB0aW5nIG1vcmUgbWV0YS1kYXRhLiBUaGlz IHByZXZlbnRzIHRoZW0gZnJvbSBkb2luZyB0aGluZ3MgdGhleSB1c2VkIHRvIGRvIGluIHRoZSBw YXN0LCBzb21lIG9mIHdoaWNoIHRoZXkgc2hvdWxkIGhhdmUgbmV2ZXIgZG9uZSBpbiB0aGUgZmly c3QgcGxhY2UuDQpJbXByb3ZpbmcgdGhlIHByb3RlY3Rpb24gb2YgbWV0YS1kYXRhIGlzIGltcG9y dGFudCBhbmQgd2VsbCBzdXBwb3J0ZWQgYnkgYSBsYXJnZSBudW1iZXIgb2YgYWN0aXZpdGllcyBp biB0aGUgSUVURiAodGhlIG5vdGFibGUgZXhjZXB0aW9uIGJlaW5nIENvQVArT1NDT1JFKS4NCg0K Q2lhbw0KSGFubmVzDQoNCg0KRnJvbTogc2FhZyA8c2FhZy1ib3VuY2VzQGlldGYub3JnPiBPbiBC ZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDogVHVlc2RheSwgSnVuZSAzMCwgMjAyMCAzOjAw IEFNDQpUbzogQmxhY2ssIERhdmlkIDxEYXZpZC5CbGFja0BkZWxsLmNvbT4NCkNjOiBpbnQtYXJl YSA8aW50LWFyZWFAaWV0Zi5vcmc+OyB0c3Z3Z0BpZXRmLm9yZzsgSUVURiBTQUFHIDxzYWFnQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtzYWFnXSAzcmQgV0dMQyAobGltaXRlZC1zY29wZSk6IGRy YWZ0LWlldGYtdHN2d2ctdHJhbnNwb3J0LWVuY3J5cHQtMTUsIGNsb3NlcyAyOSBKdW5lIDIwMjAN Cg0KPg0KPiBUaGlzIDNyZCBXR0xDIGlzIGxpbWl0ZWQgdG8gdGhlIGZvbGxvd2luZyB0d28gdG9w aWNzOg0KPg0KPg0KPiAgICAgV2hldGhlciBvciBub3QgdG8gcHJvY2VlZCB3aXRoIGEgcmVxdWVz dCBmb3IgUkZDIHB1YmxpY2F0aW9uDQo+DQo+IG9mIHRoZSBkcmFmdC4gICBUaGUgZGVjaXNpb24g b24gd2hldGhlciBvciBub3QgdG8gcHJvY2VlZCB3aWxsDQo+IGJlIGJhc2VkIG9uIHJvdWdoIGNv bnNlbnN1cyBvZiB0aGUgV0csIHNlZSBSRkMgNzI4Mi4NCj4gRHVyaW5nIHRoZSAybmQgV0dMQywg RXJpYyBSZXNjb3JsYSBhbmQgRGF2aWQgU2NoaW5hemkgZXhwcmVzc2VkDQo+IHN0cm9uZyB2aWV3 cyB0aGF0IHRoaXMgZHJhZnQgc2hvdWxkIG5vdCBiZSBwdWJsaXNoZWQg4oCTICB0aG9zZQ0KPiBj b25jZXJucyBoYXZlIG5vdCBiZWVuIHJlc29sdmVkIGFuZCBhcmUgY2FycmllZCBmb3J3YXJkIHRv DQo+IHRoaXMgV0dMQy4gIFRoaXMgZW1haWwgbWVzc2FnZSB3YXMgYW4gYXR0ZW1wdCB0byBzdW1t YXJpemUNCj4gdGhvc2UgY29uY2VybnM6DQo+DQo+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5v cmcvYXJjaC9tc2cvdHN2d2cvaTRxeVkxSFJxS3dtMEptZTlVdEViNkR5aFhVLw0KPg0KPiBGdXJ0 aGVyIGV4cGxhbmF0aW9uIGZyb20gYm90aCBFcmljIFJlc2NvcmxhIGFuZCBEYXZpZCBTY2hpbmF6 aQ0KPiBpcyB3ZWxjb21lIGFuZCBlbmNvdXJhZ2VkIHRvIGVuc3VyZSB0aGF0IHRoZWlyIGNvbmNl cm5zIGFyZQ0KPiBjbGVhcmx5IHVuZGVyc3Rvb2QuDQoNCldlbGwsIEknbGwgdHJ5IGFnYWluLCBi dXQgSSdtIG5vdCBzdXJlIHRoYXQgSSBjYW4gZG8gYmV0dGVyIHRoYW4NCkkgaGF2ZSBiZWZvcmUu DQoNCkZvciByZWFzb25zIHRoYXQgYXJlIGxhaWQgb3V0IGluIFJGQyA3MjU4LCB0aGUgdHJlbmQg aW4gcHJvdG9jb2wNCmRlc2lnbiBpbiBJRVRGIGlzIHRvd2FyZHMgZW5jcnlwdGluZyBtb3JlIGFu ZCBtb3JlLiBUaGUgbGFzdCB0d28NCnRyYW5zcG9ydCBwcm90b2NvbHMgdGhhdCB3ZXJlIGRlc2ln bmVkIGFuZCB3aWRlbHkgZGVwbG95ZWQgKFNDVFAgb3Zlcg0KRFRMUyBhbmQgUVVJQykgYm90aCBl bmNyeXB0IHRoZSB2YXN0IG1ham9yaXR5IG9mIHRoZSBwcm90b2NvbA0KbWV0YWRhdGEuIFRoaXMg ZG9jdW1lbnQgYWR2ZXJ0aXNlcyBpdHNlbGYgYXMgImNvbnNpZGVyYXRpb25zIg0KZm9yIGRlc2ln biBvZiBzdWNoIHByb3RvY29sczoNCg0KICAgVGhlIHRyYW5zcG9ydCBwcm90b2NvbHMgZGV2ZWxv cGVkIGZvciB0aGUgSW50ZXJuZXQgYXJlIHVzZWQgYWNyb3NzIGENCiAgIHdpZGUgcmFuZ2Ugb2Yg cGF0aHMgYWNyb3NzIG5ldHdvcmsgc2VnbWVudHMgd2l0aCBtYW55IGRpZmZlcmVudA0KICAgcmVn dWxhdG9yeSwgY29tbWVyY2lhbCwgYW5kIGVuZ2luZWVyaW5nIGNvbnNpZGVyYXRpb25zLiAgVGhp cw0KICAgZG9jdW1lbnQgY29uc2lkZXJzIHNvbWUgb2YgdGhlIGNvc3RzIGFuZCBjaGFuZ2VzIHRv IG5ldHdvcmsNCiAgIG1hbmFnZW1lbnQgYW5kIHJlc2VhcmNoIHRoYXQgYXJlIGltcGxpZWQgYnkg d2lkZXNwcmVhZCB1c2Ugb2YNCiAgIHRyYW5zcG9ydCBwcm90b2NvbHMgdGhhdCBlbmNyeXB0IHRo ZWlyIHRyYW5zcG9ydCBoZWFkZXIgaW5mb3JtYXRpb24uDQogICBJdCByZXZpZXdzIHRoZSBpbXBs aWNhdGlvbnMgb2YgZGV2ZWxvcGluZyB0cmFuc3BvcnQgcHJvdG9jb2xzIHRoYXQNCiAgIHVzZSBl bmQtdG8tZW5kIGVuY3J5cHRpb24gdG8gcHJvdmlkZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlaXIN CiAgIHRyYW5zcG9ydCBsYXllciBoZWFkZXJzLCBhbmQgY29uc2lkZXJzIHRoZSBlZmZlY3Qgb2Yg c3VjaCBjaGFuZ2VzIG9uDQogICB0cmFuc3BvcnQgcHJvdG9jb2wgZGVzaWduLCB0cmFuc3BvcnQg cHJvdG9jb2wgZXZvbHV0aW9uLCBhbmQgbmV0d29yaw0KICAgb3BlcmF0aW9ucy4gIEl0IGFsc28g Y29uc2lkZXJzIHNvbWUgYW50aWNpcGF0ZWQgaW1wbGljYXRpb25zIG9uDQogICBhcHBsaWNhdGlv biBldm9sdXRpb24uICBUaGlzIHByb3ZpZGVzIGNvbnNpZGVyYXRpb25zIHJlbGF0aW5nIHRvIHRo ZQ0KICAgZGVzaWduIG9mIHRyYW5zcG9ydCBwcm90b2NvbHMgYW5kIGZlYXR1cmVzIHdoZXJlIHRo ZSB0cmFuc3BvcnQNCiAgIHByb3RvY29sIGVuY3J5cHRzIHNvbWUgb3IgYWxsIG9mIHRoZWlyIGhl YWRlciBpbmZvcm1hdGlvbi4NCg0KSG93ZXZlciwgYXMgSSBzYWlkIGFib3ZlLCB0aGUgbmV3IHRy YW5zcG9ydCBwcm90b2NvbHMgdGhhdCBhcmUNCmFjdHVhbGx5IGJlaW5nIGRlc2lnbmVkIGFscmVh ZHkgZmVhdHVyZSBtZXRhZGF0YSBlbmNyeXB0aW9uIGFuZCBhcyBmYXINCmFzIEkgY2FuIHRlbGws IHRoZXJlIGlzIG5vIHByb3NwZWN0aXZlIHByb3RvY29sIG5ldyB0cmFuc3BvcnQgcHJvdG9jb2wN CmRlc2lnbiBwcm9qZWN0IGZvciB3aGljaCB0aGVzZSBpc3N1ZXMgbWlnaHQgYmUgbGl2ZS4gSW4g dGhhdCBjb250ZXh0LA0KaXQncyBoYXJkIG5vdCB0byByZWFkIHRoaXMgZG9jdW1lbnQgd2l0aCBp dHMgbG9uZyBsaXRhbnkgb2YgcHJhY3RpY2VzDQp3aGljaCBhcmUgaW1wYWN0ZWQgYnkgbWV0YWRh dGEgZW5jcnlwdGlvbiBhcyBhIGNyaXRpcXVlIG9mIHRoZQ0KZGVjaXNpb25zIGJ5IFNDVFAvRFRM UyBhbmQgUVVJQyB0byBlbmNyeXB0IG1vc3Qgb2YgdGhlIG1ldGFkYXRhLg0KDQoNClRoaXMgaW1w cmVzc2lvbiBpcyByZWluZm9yY2VkIGJ5IHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgYWN0dWFsDQpw cmFjdGljZXMgdGhlbXNlbHZlcywgd2hpY2ggZm9jdXNlcyBhbG1vc3QgZW50aXJlbHkgb24gcHJh Y3RpY2VzDQp3aGljaCBhcHBlYXIgdG8gYmUgYmVuaWdubHkgbW90aXZhdGVkIChlLmcuLCBwZXJm b3JtYW5jZSBtb25pdG9yaW5nLA0KdHJvdWJsZXNob290aW5nLCBldGMuKSBIb3dldmVyLCB3ZSBh bHNvIGtub3cgdGhhdCBtZXRhZGF0YSBpcyB3aWRlbHkNCnVzZWQgZm9yIHByYWN0aWNlcyBpbiB3 aGljaCB0aGUgbmV0d29yayBvcGVyYXRvciBpcyBhZHZlcnNhcmlhbA0KdG8gdGhlIHVzZXIsIGZv ciBpbnN0YW5jZToNCg0KLSBCbG9ja2luZyB0cmFmZmljIGJhc2VkIG9uIFRDUCBwb3J0LCBJUCBh ZGRyZXNzLCBTTkksIGV0Yy4NCg0KLSBQZXJmb3JtYW5jZS1iYXNlZCB0cmFmZmljIGNsYXNzIGRp c2NyaW1pbmF0aW9uDQoNCi0gTW9uaXRvcmluZyB0aGUgdXNlcidzIGJlaGF2aW9yIHZpYSBpbmRp Y2lhIGxpa2UgdGhlIG9uZXMgYWJvdmUNCiAgb3IgdmlhIHRyYWZmaWMgYW5hbHlzaXMgKHNlZSBb MF0pDQoNClllcywgSSB1bmRlcnN0YW5kIHRoYXQgdGhlIGF1dGhvcnMgZXhwbGljaXRseSBkaXNj bGFpbSBqdWRnZW1lbnQgb24NCnRoZXNlIHByYWN0aWNlcywgYW5kIHRoZSBkb2N1bWVudCBkb2Vz IGJyaWVmbHkgdG91Y2ggb24gdGhlIGdlbmVyYWwNCmlkZWEsIHRob3VnaCB0aGUgImNvbmNlcm5z Li4uaGF2ZSBiZWVuIHZvaWNlZCIgdGVuZHMgdG8gbWluaW1pemUgdGhvc2UNCmNvbmNlcm5zIFsx XSBidXQgdGhlIHNlbGVjdGlvbiBvZiBwcmFjdGljZXMgdG8gZm9jdXMgb24gaXMgZXh0cmVtZWx5 DQp0ZWxsaW5nLiBGb2N1c2luZyBvbiB0aGUgZG93bnNpZGVzIG9mIGVuY3J5cHRpb24gZm9yIChh dCBsZWFzdA0KYXJndWFibHkgd2VsbC1tZWFuaW5nKSBuZXR3b3JrIHBsYXllcnMgd2hpbGUgbW9z dGx5IGlnbm9yaW5nIHRoZSBsYXJnZQ0KY2xhc3Mgb2Ygbm9uLWJlbmlnbiBiZWhhdmlvcnMgd2hp Y2ggZW5jcnlwdGlvbiBpcyBpbnRlbmRlZCB0byBwcm90ZWN0DQphZ2FpbnN0IGhhcyB0aGUgZWZm ZWN0IG9mIG92ZXJlbXBoYXNpemluZyB0aGUgY29zdHMgb2YgZW5jcnlwdGlvbiB0bw0KdGhvc2Ug cGxheWVycyBhbmQgbWluaW1pemluZyB0aGUgYmVuZWZpdHMgdG8gdGhlIGVuZHBvaW50cyB3aG9t IGl0IGlzDQppbnRlbmRlZCB0byBwcm90ZWN0Lg0KDQoNClRvIGJlIG1heGltYWxseSBjbGVhcjog SSBkb24ndCBvYmplY3QgdG8gdGhpcyBkb2N1bWVudCBleGlzdGluZw0KYW5kIEkgZG9uJ3QgdGhp bmsgdGhhdCB0aGUgb3BpbmlvbnMgaW1wbGljaXQgaW4gaXQgYXJlIG9uZXMgdGhhdA0Kc2hvdWxk IG5vdCBiZSBleHByZXNzZWQuIEkgbWVyZWx5IGRvbid0IHRoaW5rIHRoYXQgaXQgc2hvdWxkIGJl DQpwdWJsaXNoZWQgYXMgYW4gSUVURiBDb25zZW5zdXMgZG9jdW1lbnQuDQoNCi1Fa3INCg0KWzBd IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13b29kLXBlYXJnLXdlYnNpdGUtZmlu Z2VycHJpbnRpbmctMDAjc2VjdGlvbi01DQpbMV0gICAgQW5vdGhlciBtb3RpdmF0aW9uIHN0ZW1z IGZyb20gaW5jcmVhc2VkIGNvbmNlcm5zIGFib3V0IHByaXZhY3kgYW5kDQogICAgICBzdXJ2ZWls bGFuY2UuICBVc2VycyB2YWx1ZSB0aGUgYWJpbGl0eSB0byBwcm90ZWN0IHRoZWlyIGlkZW50aXR5 DQogICAgICBhbmQgbG9jYXRpb24sIGFuZCBkZWZlbmQgYWdhaW5zdCBhbmFseXNpcyBvZiB0aGUg dHJhZmZpYy4NCiAgICAgIFJldmVsYXRpb25zIGFib3V0IHRoZSB1c2Ugb2YgcGVydmFzaXZlIHN1 cnZlaWxsYW5jZSBbUkZDNzYyNF0NCiAgICAgIGhhdmUsIHRvIHNvbWUgZXh0ZW50LCBlcm9kZWQg dHJ1c3QgaW4gdGhlIHNlcnZpY2Ugb2ZmZXJlZCBieQ0KICAgICAgbmV0d29yayBvcGVyYXRvcnMg YW5kIGhhdmUgbGVkIHRvIGFuIGluY3JlYXNlZCB1c2Ugb2YgZW5jcnlwdGlvbg0KICAgICAgdG8g YXZvaWQgdW53YW50ZWQgZWF2ZXNkcm9wcGluZyBvbiBjb21tdW5pY2F0aW9ucy4gIENvbmNlcm5z IGhhdmUNCiAgICAgIGFsc28gYmVlbiB2b2ljZWQgYWJvdXQgdGhlIGFkZGl0aW9uIG9mIGluZm9y bWF0aW9uIHRvIHBhY2tldHMgYnkNCiAgICAgIHRoaXJkIHBhcnRpZXMgdG8gcHJvdmlkZSBhbmFs eXRpY3MsIGN1c3RvbWlzYXRpb24sIGFkdmVydGlzaW5nLA0KICAgICAgY3Jvc3Mtc2l0ZSB0cmFj a2luZyBvZiB1c2VycywgdG8gYmlsbCB0aGUgY3VzdG9tZXIsIG9yIHRvDQogICAgICBzZWxlY3Rp dmVseSBhbGxvdyBvciBibG9jayBjb250ZW50LiAgV2hhdGV2ZXIgdGhlIHJlYXNvbnMsIHRoZQ0K ICAgICAgSUVURiBpcyBkZXNpZ25pbmcgcHJvdG9jb2xzIHRoYXQgaW5jbHVkZSB0cmFuc3BvcnQg aGVhZGVyDQogICAgICBlbmNyeXB0aW9uIChlLmcuLCBRVUlDIFtJLUQuaWV0Zi1xdWljLXRyYW5z cG9ydF0pIHRvIHN1cHBsZW1lbnQNCiAgICAgIHRoZSBhbHJlYWR5IHdpZGVzcHJlYWQgcGF5bG9h ZCBlbmNyeXB0aW9uLCBhbmQgdG8gZnVydGhlciBsaW1pdA0KICAgICAgZXhwb3N1cmUgb2YgdHJh bnNwb3J0IG1ldGFkYXRhIHRvIHRoZSBuZXR3b3JrLg0KDQoNCg0KDQoNCg0KDQpJTVBPUlRBTlQg Tk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFy ZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh dGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29u LCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlv biBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= --_000_AM0PR08MB3716528B48BCF9447002B551FA6F0AM0PR08MB3716eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt Y29tcG9zZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K 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 OjwvYj4gc2FhZyAmbHQ7c2FhZy1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2Yg PC9iPg0KRXJpYyBSZXNjb3JsYTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDMwLCAy MDIwIDM6MDAgQU08YnI+DQo8Yj5Ubzo8L2I+IEJsYWNrLCBEYXZpZCAmbHQ7RGF2aWQuQmxhY2tA ZGVsbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBpbnQtYXJlYSAmbHQ7aW50LWFyZWFAaWV0Zi5v cmcmZ3Q7OyB0c3Z3Z0BpZXRmLm9yZzsgSUVURiBTQUFHICZsdDtzYWFnQGlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NhYWddIDNyZCBXR0xDIChsaW1pdGVkLXNjb3BlKTog ZHJhZnQtaWV0Zi10c3Z3Zy10cmFuc3BvcnQtZW5jcnlwdC0xNSwgY2xvc2VzIDI5IEp1bmUgMjAy MDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPiZndDsgPGJyPg0KJmd0OyBUaGlzIDNyZCBXR0xDIGlzIGxpbWl0ZWQgdG8g dGhlIGZvbGxvd2luZyB0d28gdG9waWNzOjxicj4NCiZndDsgJm5ic3A7PGJyPg0KJmd0OyA8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgV2hldGhlciBvciBub3QgdG8gcHJvY2VlZCB3aXRoIGEgcmVx dWVzdCBmb3IgUkZDIHB1YmxpY2F0aW9uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IG9mIHRoZSBkcmFm dC4gJm5ic3A7IFRoZSBkZWNpc2lvbiBvbiB3aGV0aGVyIG9yIG5vdCB0byBwcm9jZWVkIHdpbGw8 YnI+DQomZ3Q7IGJlIGJhc2VkIG9uIHJvdWdoIGNvbnNlbnN1cyBvZiB0aGUgV0csIHNlZSBSRkMg NzI4Mi48YnI+DQomZ3Q7IER1cmluZyB0aGUgMm5kIFdHTEMsIEVyaWMgUmVzY29ybGEgYW5kIERh dmlkIFNjaGluYXppIGV4cHJlc3NlZDxicj4NCiZndDsgc3Ryb25nIHZpZXdzIHRoYXQgdGhpcyBk cmFmdCBzaG91bGQgbm90IGJlIHB1Ymxpc2hlZCDigJMgJm5ic3A7dGhvc2U8YnI+DQomZ3Q7IGNv bmNlcm5zIGhhdmUgbm90IGJlZW4gcmVzb2x2ZWQgYW5kIGFyZSBjYXJyaWVkIGZvcndhcmQgdG88 YnI+DQomZ3Q7IHRoaXMgV0dMQy4mbmJzcDsgVGhpcyBlbWFpbCBtZXNzYWdlIHdhcyBhbiBhdHRl bXB0IHRvIHN1bW1hcml6ZTxicj4NCiZndDsgdGhvc2UgY29uY2VybnM6PGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdHN2 d2cvaTRxeVkxSFJxS3dtMEptZTlVdEViNkR5aFhVLyI+DQpodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvbXNnL3RzdndnL2k0cXlZMUhScUt3bTBKbWU5VXRFYjZEeWhYVS88L2E+PGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IEZ1cnRoZXIgZXhwbGFuYXRpb24gZnJvbSBib3RoIEVyaWMgUmVz Y29ybGEgYW5kIERhdmlkIFNjaGluYXppPGJyPg0KJmd0OyBpcyB3ZWxjb21lIGFuZCBlbmNvdXJh Z2VkIHRvIGVuc3VyZSB0aGF0IHRoZWlyIGNvbmNlcm5zIGFyZTxicj4NCiZndDsgY2xlYXJseSB1 bmRlcnN0b29kLjxicj4NCjxicj4NCldlbGwsIEknbGwgdHJ5IGFnYWluLCBidXQgSSdtIG5vdCBz dXJlIHRoYXQgSSBjYW4gZG8gYmV0dGVyIHRoYW48YnI+DQpJIGhhdmUgYmVmb3JlLjxicj4NCjxi cj4NCkZvciByZWFzb25zIHRoYXQgYXJlIGxhaWQgb3V0IGluIFJGQyA3MjU4LCB0aGUgdHJlbmQg aW4gcHJvdG9jb2w8YnI+DQpkZXNpZ24gaW4gSUVURiBpcyB0b3dhcmRzIGVuY3J5cHRpbmcgbW9y ZSBhbmQgbW9yZS4gVGhlIGxhc3QgdHdvPGJyPg0KdHJhbnNwb3J0IHByb3RvY29scyB0aGF0IHdl cmUgZGVzaWduZWQgYW5kIHdpZGVseSBkZXBsb3llZCAoU0NUUCBvdmVyPGJyPg0KRFRMUyBhbmQg UVVJQykgYm90aCBlbmNyeXB0IHRoZSB2YXN0IG1ham9yaXR5IG9mIHRoZSBwcm90b2NvbDxicj4N Cm1ldGFkYXRhLiBUaGlzIGRvY3VtZW50IGFkdmVydGlzZXMgaXRzZWxmIGFzICZxdW90O2NvbnNp ZGVyYXRpb25zJnF1b3Q7PGJyPg0KZm9yIGRlc2lnbiBvZiBzdWNoIHByb3RvY29sczo8YnI+DQo8 YnI+DQombmJzcDsgJm5ic3A7VGhlIHRyYW5zcG9ydCBwcm90b2NvbHMgZGV2ZWxvcGVkIGZvciB0 aGUgSW50ZXJuZXQgYXJlIHVzZWQgYWNyb3NzIGE8YnI+DQombmJzcDsgJm5ic3A7d2lkZSByYW5n ZSBvZiBwYXRocyBhY3Jvc3MgbmV0d29yayBzZWdtZW50cyB3aXRoIG1hbnkgZGlmZmVyZW50PGJy Pg0KJm5ic3A7ICZuYnNwO3JlZ3VsYXRvcnksIGNvbW1lcmNpYWwsIGFuZCBlbmdpbmVlcmluZyBj b25zaWRlcmF0aW9ucy4mbmJzcDsgVGhpczxicj4NCiZuYnNwOyAmbmJzcDtkb2N1bWVudCBjb25z aWRlcnMgc29tZSBvZiB0aGUgY29zdHMgYW5kIGNoYW5nZXMgdG8gbmV0d29yazxicj4NCiZuYnNw OyAmbmJzcDttYW5hZ2VtZW50IGFuZCByZXNlYXJjaCB0aGF0IGFyZSBpbXBsaWVkIGJ5IHdpZGVz cHJlYWQgdXNlIG9mPGJyPg0KJm5ic3A7ICZuYnNwO3RyYW5zcG9ydCBwcm90b2NvbHMgdGhhdCBl bmNyeXB0IHRoZWlyIHRyYW5zcG9ydCBoZWFkZXIgaW5mb3JtYXRpb24uPGJyPg0KJm5ic3A7ICZu YnNwO0l0IHJldmlld3MgdGhlIGltcGxpY2F0aW9ucyBvZiBkZXZlbG9waW5nIHRyYW5zcG9ydCBw cm90b2NvbHMgdGhhdDxicj4NCiZuYnNwOyAmbmJzcDt1c2UgZW5kLXRvLWVuZCBlbmNyeXB0aW9u IHRvIHByb3ZpZGUgY29uZmlkZW50aWFsaXR5IG9mIHRoZWlyPGJyPg0KJm5ic3A7ICZuYnNwO3Ry YW5zcG9ydCBsYXllciBoZWFkZXJzLCBhbmQgY29uc2lkZXJzIHRoZSBlZmZlY3Qgb2Ygc3VjaCBj aGFuZ2VzIG9uPGJyPg0KJm5ic3A7ICZuYnNwO3RyYW5zcG9ydCBwcm90b2NvbCBkZXNpZ24sIHRy YW5zcG9ydCBwcm90b2NvbCBldm9sdXRpb24sIGFuZCBuZXR3b3JrPGJyPg0KJm5ic3A7ICZuYnNw O29wZXJhdGlvbnMuJm5ic3A7IEl0IGFsc28gY29uc2lkZXJzIHNvbWUgYW50aWNpcGF0ZWQgaW1w bGljYXRpb25zIG9uPGJyPg0KJm5ic3A7ICZuYnNwO2FwcGxpY2F0aW9uIGV2b2x1dGlvbi4mbmJz cDsgVGhpcyBwcm92aWRlcyBjb25zaWRlcmF0aW9ucyByZWxhdGluZyB0byB0aGU8YnI+DQombmJz cDsgJm5ic3A7ZGVzaWduIG9mIHRyYW5zcG9ydCBwcm90b2NvbHMgYW5kIGZlYXR1cmVzIHdoZXJl IHRoZSB0cmFuc3BvcnQ8YnI+DQombmJzcDsgJm5ic3A7cHJvdG9jb2wgZW5jcnlwdHMgc29tZSBv ciBhbGwgb2YgdGhlaXIgaGVhZGVyIGluZm9ybWF0aW9uLjxicj4NCjxicj4NCkhvd2V2ZXIsIGFz IEkgc2FpZCBhYm92ZSwgdGhlIG5ldyB0cmFuc3BvcnQgcHJvdG9jb2xzIHRoYXQgYXJlPGJyPg0K YWN0dWFsbHkgYmVpbmcgZGVzaWduZWQgYWxyZWFkeSBmZWF0dXJlIG1ldGFkYXRhIGVuY3J5cHRp b24gYW5kIGFzIGZhcjxicj4NCmFzIEkgY2FuIHRlbGwsIHRoZXJlIGlzIG5vIHByb3NwZWN0aXZl IHByb3RvY29sIG5ldyB0cmFuc3BvcnQgcHJvdG9jb2w8YnI+DQpkZXNpZ24gcHJvamVjdCBmb3Ig d2hpY2ggdGhlc2UgaXNzdWVzIG1pZ2h0IGJlIGxpdmUuIEluIHRoYXQgY29udGV4dCw8YnI+DQpp dCdzIGhhcmQgbm90IHRvIHJlYWQgdGhpcyBkb2N1bWVudCB3aXRoIGl0cyBsb25nIGxpdGFueSBv ZiBwcmFjdGljZXM8YnI+DQp3aGljaCBhcmUgaW1wYWN0ZWQgYnkgbWV0YWRhdGEgZW5jcnlwdGlv biBhcyBhIGNyaXRpcXVlIG9mIHRoZTxicj4NCmRlY2lzaW9ucyBieSBTQ1RQL0RUTFMgYW5kIFFV SUMgdG8gZW5jcnlwdCBtb3N0IG9mIHRoZSBtZXRhZGF0YS48YnI+DQo8YnI+DQo8YnI+DQpUaGlz IGltcHJlc3Npb24gaXMgcmVpbmZvcmNlZCBieSB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIGFjdHVh bDxicj4NCnByYWN0aWNlcyB0aGVtc2VsdmVzLCB3aGljaCBmb2N1c2VzIGFsbW9zdCBlbnRpcmVs eSBvbiBwcmFjdGljZXM8YnI+DQp3aGljaCBhcHBlYXIgdG8gYmUgYmVuaWdubHkgbW90aXZhdGVk IChlLmcuLCBwZXJmb3JtYW5jZSBtb25pdG9yaW5nLDxicj4NCnRyb3VibGVzaG9vdGluZywgZXRj LikgSG93ZXZlciwgd2UgYWxzbyBrbm93IHRoYXQgbWV0YWRhdGEgaXMgd2lkZWx5PGJyPg0KdXNl ZCBmb3IgcHJhY3RpY2VzIGluIHdoaWNoIHRoZSBuZXR3b3JrIG9wZXJhdG9yIGlzIGFkdmVyc2Fy aWFsPGJyPg0KdG8gdGhlIHVzZXIsIGZvciBpbnN0YW5jZTo8YnI+DQo8YnI+DQotIEJsb2NraW5n IHRyYWZmaWMgYmFzZWQgb24gVENQIHBvcnQsIElQIGFkZHJlc3MsIFNOSSwgZXRjLjxicj4NCjxi cj4NCi0gUGVyZm9ybWFuY2UtYmFzZWQgdHJhZmZpYyBjbGFzcyBkaXNjcmltaW5hdGlvbjxicj4N Cjxicj4NCi0gTW9uaXRvcmluZyB0aGUgdXNlcidzIGJlaGF2aW9yIHZpYSBpbmRpY2lhIGxpa2Ug dGhlIG9uZXMgYWJvdmU8YnI+DQombmJzcDsgb3IgdmlhIHRyYWZmaWMgYW5hbHlzaXMgKHNlZSBb MF0pPGJyPg0KPGJyPg0KWWVzLCBJIHVuZGVyc3RhbmQgdGhhdCB0aGUgYXV0aG9ycyBleHBsaWNp dGx5IGRpc2NsYWltIGp1ZGdlbWVudCBvbjxicj4NCnRoZXNlIHByYWN0aWNlcywgYW5kIHRoZSBk b2N1bWVudCBkb2VzIGJyaWVmbHkgdG91Y2ggb24gdGhlIGdlbmVyYWw8YnI+DQppZGVhLCB0aG91 Z2ggdGhlICZxdW90O2NvbmNlcm5zLi4uaGF2ZSBiZWVuIHZvaWNlZCZxdW90OyB0ZW5kcyB0byBt aW5pbWl6ZSB0aG9zZTxicj4NCmNvbmNlcm5zIFsxXSBidXQgdGhlIHNlbGVjdGlvbiBvZiBwcmFj dGljZXMgdG8gZm9jdXMgb24gaXMgZXh0cmVtZWx5PGJyPg0KdGVsbGluZy4gRm9jdXNpbmcgb24g dGhlIGRvd25zaWRlcyBvZiBlbmNyeXB0aW9uIGZvciAoYXQgbGVhc3Q8YnI+DQphcmd1YWJseSB3 ZWxsLW1lYW5pbmcpIG5ldHdvcmsgcGxheWVycyB3aGlsZSBtb3N0bHkgaWdub3JpbmcgdGhlIGxh cmdlPGJyPg0KY2xhc3Mgb2Ygbm9uLWJlbmlnbiBiZWhhdmlvcnMgd2hpY2ggZW5jcnlwdGlvbiBp cyBpbnRlbmRlZCB0byBwcm90ZWN0PGJyPg0KYWdhaW5zdCBoYXMgdGhlIGVmZmVjdCBvZiBvdmVy ZW1waGFzaXppbmcgdGhlIGNvc3RzIG9mIGVuY3J5cHRpb24gdG88YnI+DQp0aG9zZSBwbGF5ZXJz IGFuZCBtaW5pbWl6aW5nIHRoZSBiZW5lZml0cyB0byB0aGUgZW5kcG9pbnRzIHdob20gaXQgaXM8 YnI+DQppbnRlbmRlZCB0byBwcm90ZWN0Ljxicj4NCjxicj4NCjxicj4NClRvIGJlIG1heGltYWxs eSBjbGVhcjogSSBkb24ndCBvYmplY3QgdG8gdGhpcyBkb2N1bWVudCBleGlzdGluZzxicj4NCmFu ZCBJIGRvbid0IHRoaW5rIHRoYXQgdGhlIG9waW5pb25zIGltcGxpY2l0IGluIGl0IGFyZSBvbmVz IHRoYXQ8YnI+DQpzaG91bGQgbm90IGJlIGV4cHJlc3NlZC4gSSBtZXJlbHkgZG9uJ3QgdGhpbmsg dGhhdCBpdCBzaG91bGQgYmU8YnI+DQpwdWJsaXNoZWQgYXMgYW4gSUVURiBDb25zZW5zdXMgZG9j dW1lbnQuPGJyPg0KPGJyPg0KLUVrcjxicj4NCjxicj4NClswXSA8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd29vZC1wZWFyZy13ZWJzaXRlLWZpbmdlcnByaW50aW5n LTAwI3NlY3Rpb24tNSI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd29vZC1w ZWFyZy13ZWJzaXRlLWZpbmdlcnByaW50aW5nLTAwI3NlY3Rpb24tNTwvYT48YnI+DQpbMV0gJm5i c3A7ICZuYnNwO0Fub3RoZXIgbW90aXZhdGlvbiBzdGVtcyBmcm9tIGluY3JlYXNlZCBjb25jZXJu cyBhYm91dCBwcml2YWN5IGFuZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHN1cnZlaWxsYW5j ZS4mbmJzcDsgVXNlcnMgdmFsdWUgdGhlIGFiaWxpdHkgdG8gcHJvdGVjdCB0aGVpciBpZGVudGl0 eTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGFuZCBsb2NhdGlvbiwgYW5kIGRlZmVuZCBhZ2Fp bnN0IGFuYWx5c2lzIG9mIHRoZSB0cmFmZmljLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IFJl dmVsYXRpb25zIGFib3V0IHRoZSB1c2Ugb2YgcGVydmFzaXZlIHN1cnZlaWxsYW5jZSBbUkZDNzYy NF08YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBoYXZlLCB0byBzb21lIGV4dGVudCwgZXJvZGVk IHRydXN0IGluIHRoZSBzZXJ2aWNlIG9mZmVyZWQgYnk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyBuZXR3b3JrIG9wZXJhdG9ycyBhbmQgaGF2ZSBsZWQgdG8gYW4gaW5jcmVhc2VkIHVzZSBvZiBl bmNyeXB0aW9uPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgdG8gYXZvaWQgdW53YW50ZWQgZWF2 ZXNkcm9wcGluZyBvbiBjb21tdW5pY2F0aW9ucy4mbmJzcDsgQ29uY2VybnMgaGF2ZTxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7IGFsc28gYmVlbiB2b2ljZWQgYWJvdXQgdGhlIGFkZGl0aW9uIG9m IGluZm9ybWF0aW9uIHRvIHBhY2tldHMgYnk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyB0aGly ZCBwYXJ0aWVzIHRvIHByb3ZpZGUgYW5hbHl0aWNzLCBjdXN0b21pc2F0aW9uLCBhZHZlcnRpc2lu Zyw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBjcm9zcy1zaXRlIHRyYWNraW5nIG9mIHVzZXJz LCB0byBiaWxsIHRoZSBjdXN0b21lciwgb3IgdG88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBz ZWxlY3RpdmVseSBhbGxvdyBvciBibG9jayBjb250ZW50LiZuYnNwOyBXaGF0ZXZlciB0aGUgcmVh c29ucywgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgSUVURiBpcyBkZXNpZ25pbmcgcHJv dG9jb2xzIHRoYXQgaW5jbHVkZSB0cmFuc3BvcnQgaGVhZGVyPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgZW5jcnlwdGlvbiAoZS5nLiwgUVVJQyBbSS1ELmlldGYtcXVpYy10cmFuc3BvcnRdKSB0 byBzdXBwbGVtZW50PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlIGFscmVhZHkgd2lkZXNw cmVhZCBwYXlsb2FkIGVuY3J5cHRpb24sIGFuZCB0byBmdXJ0aGVyIGxpbWl0PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgZXhwb3N1cmUgb2YgdHJhbnNwb3J0IG1ldGFkYXRhIHRvIHRoZSBuZXR3 b3JrLjxicj4NCiZuYnNwOyA8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUg Y29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRp YWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8g bm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9y IGFueSBwdXJwb3NlLA0KIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBt ZWRpdW0uIFRoYW5rIHlvdS4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AM0PR08MB3716528B48BCF9447002B551FA6F0AM0PR08MB3716eurp_-- From nobody Tue Jun 30 15:25: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 11C863A0958; Tue, 30 Jun 2020 15:25:03 -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 2kSRIy_tWiM2; Tue, 30 Jun 2020 15:25:00 -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 690743A08E6; Tue, 30 Jun 2020 15:25:00 -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 05UMOunk020867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Jun 2020 18:24:58 -0400 Date: Tue, 30 Jun 2020 15:24:55 -0700 From: Benjamin Kaduk To: draft-foudil-securitytxt@ietf.org Cc: saag@ietf.org Message-ID: <20200630222455.GX58278@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] 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, 30 Jun 2020 22:25:11 -0000 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. 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.) 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. 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 ) 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 robus information or are accessible to a wider audience. A disclaimer that there is not intent to discourage such publicly navigatable pages could be useful. 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.) 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). 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. 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.] 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/ 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". Thanks, Ben From nobody Tue Jun 30 20:03:52 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 1F0843A09E5; Tue, 30 Jun 2020 20:03:51 -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_DNSWL_BLOCKED=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 C1u01Le6cTii; Tue, 30 Jun 2020 20:03:48 -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 864A43A09E4; Tue, 30 Jun 2020 20:03:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5C33D389B9; Tue, 30 Jun 2020 23:00:58 -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 0m2V687x38md; Tue, 30 Jun 2020 23:00:57 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6D6AF389B7; Tue, 30 Jun 2020 23:00:57 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9727C476; Tue, 30 Jun 2020 23:03:44 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: draft-foudil-securitytxt@ietf.org, saag@ietf.org In-Reply-To: <20200630222455.GX58278@kduck.mit.edu> References: <20200630222455.GX58278@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: Wed, 01 Jul 2020 03:03:51 -0000 --=-=-= Content-Type: text/plain 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? 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. 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 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. > 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. > 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. -- ] 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+93Q3WUFAl77/RAACgkQgItw+93Q 3WWzwggAoDxR65U/SrRMncchpIcgOiVaCkO4DXBTw2YyGprR26rZMY7TX95rarPU Fi7dhxMAkcO9Y54+X8YUtPBy2X9QuJUFLDrTTs4HMbLtj8qbHIed+PC+OECDFCfE djT6sq6Xn26v6kXPh7ZQXZhkAGu0r93rTKJIYSja0jLjY3JTZDSoVdJCno51gKVY 8cK1I973fgC851lXhEVXg8cPvkGQkBRIquHm9qJxNNlX4fiQbPUv7hdoXEjX/sYD byTJinim1IKLFVeRECTDVtNW2BkahXKzosCJD4OtgnD2/T1As5t3CNWxcFlhyx9q m+m40gCU3o1PwNpwCzwZciFkhjE8TQ== =heUu -----END PGP SIGNATURE----- --=-=-=--