Re: Re-chartering for extension work

"Lubashev, Igor" <ilubashe@akamai.com> Thu, 09 January 2020 14:18 UTC

Return-Path: <ilubashe@akamai.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19F1120026 for <quic@ietfa.amsl.com>; Thu, 9 Jan 2020 06:18:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 D7F4CfDrwHPz for <quic@ietfa.amsl.com>; Thu, 9 Jan 2020 06:18:40 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1AEA12004E for <quic@ietf.org>; Thu, 9 Jan 2020 06:18:40 -0800 (PST)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 009EHSto001183; Thu, 9 Jan 2020 14:18:26 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=Qz9X5DzFRtag2QaclBpP7NbHhiqnitJqDJf37kzRXwM=; b=mYM9L3vJ65/QwROf98yymy5xZ39Tbumx+KKFRxgDO5hXaDn/GvW8PqMrjHkA1loNT1hr xUWrZE6iZWUm3MTS8kYm5xkkVBLuJlmkK08P+ufV1ygfmanaqViG7uMB/nVLHlp6mYn3 5tLSvPhvQL7Px9DuxbIumEeLMVp0n1IyYc5wumFKQO+v703jUo2887eZ8oRqlzirXpI3 un6+MVcq/Xxoqi73aqNcDEBwF9WjfQ3C+azb7ShGVf0b+uTENCUv8d3PTNbFotSgIYqT AjwaG7DL5+lBRFVqfkj53OCXK7e/pZR09aA21+L/mRzoT4xFovvw2Se3snTSDYuFxoAM dw==
Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2xakmnwaxv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Jan 2020 14:18:26 +0000
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 009EH0Fk027261; Thu, 9 Jan 2020 09:18:25 -0500
Received: from email.msg.corp.akamai.com ([172.27.165.117]) by prod-mail-ppoint4.akamai.com with ESMTP id 2xapx4rnwy-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 09 Jan 2020 09:18:22 -0500
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.165.123) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.165.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 Jan 2020 08:18:16 -0600
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.165.123]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.165.123]) with mapi id 15.00.1473.005; Thu, 9 Jan 2020 08:18:16 -0600
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Dmitri Tikhonov <dtikhonov@litespeedtech.com>, Mark Nottingham <mnot@mnot.net>
CC: Magnus Westerlund <magnus.westerlund@ericsson.com>, "Roni Even (A)" <roni.even@huawei.com>, "quic@ietf.org" <quic@ietf.org>, Lars Eggert <lars@eggert.org>
Subject: Re: Re-chartering for extension work
Thread-Topic: Re-chartering for extension work
Thread-Index: AQHVxvehz4hcPwmxz0WVLe+SyklylA==
Date: Thu, 09 Jan 2020 14:18:15 +0000
Message-ID: <c5523893e08e4a30b8d22e5e8b764bc6@ustx2ex-dag1mb5.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_c5523893e08e4a30b8d22e5e8b764bc6ustx2exdag1mb5msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-09_02:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=550 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001090124
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-09_02:2020-01-09, 2020-01-09 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=528 spamscore=0 adultscore=0 lowpriorityscore=0 bulkscore=0 impostorscore=0 mlxscore=0 clxscore=1015 priorityscore=1501 malwarescore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001090124
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/064IvsoeIYXIdVcJxvIS6leJcTc>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2020 14:18:43 -0000

Dmitri, during the last IETF in Singapore, a significant number of people who are active in the WG raised their hands that they would think about and discuss security and privacy implications, once the draft is updated to reflect the WG's request to make this a negotiable extension.  I believe Mark meant that the adoption call would make sense once this discussion happens (assuming nothing unsolvable comes out of it). We are working to get the draft in a good shape within a week or so to share with the WG.

- Igor

-------- Original message --------
From: Dmitri Tikhonov <dtikhonov@litespeedtech.com>
Date: 1/9/20 9:02 AM (GMT-05:00)

On Fri, Dec 13, 2019 at 10:16:45AM +1100, Mark Nottingham wrote:
> > On 13 Dec 2019, at 3:14 am, Lubashev, Igor <ilubashe@akamai.com> wrote:
> > We were planning to present the draft of lossbits as a negotiated
> > extension in Zurich, but given that the time for the inclusion
> > in the Charter is now, we can get the draft out next week.
> > Given the prior discussion and expressed willingness of at
> > least a part of the WG to work on this, would you include
> > that extension draft in the WG adoption call prior to the
> > charter update?  (As usual, adoption != publication, which is
> > subject to the deliberations of the WG, including a positive
> > privacy/security analysis.)
>
> If we performed a Call for Adoption now, I strongly suspect it
> would fail, because the privacy and security evaluation hasn't
> been performed; we went through the same process for the spin bit.

What is the security evaluation process?  Can just anyone do it
(for example, myself sitting down and thinking about it really
hard) or are there designated IETF people or entities that do
this sort of thing?

  - Dmitri.