From nobody Fri Nov 1 13:14:04 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23758120828 for ; Fri, 1 Nov 2019 13:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41vjXoST_Icd for ; Fri, 1 Nov 2019 13:14:01 -0700 (PDT) Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) (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 8882D120013 for ; Fri, 1 Nov 2019 13:14:01 -0700 (PDT) Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iQdJ0-0002JZ-3g for tls@ietf.org; Fri, 01 Nov 2019 20:13:58 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1iQdIz-0005MF-VY for tls@ietf.org; Fri, 01 Nov 2019 21:13:57 +0100 From: Florian Weimer To: tls@ietf.org Date: Fri, 01 Nov 2019 21:13:57 +0100 Message-ID: <87zhhfcq2i.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [TLS] Delegated Credentials and Lawful Intercept X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 20:14:03 -0000 Would it be possible to use delegated credentials to address lawful intercept concerns, similar to eTLS? Basically, the server operator would issue a delegated credential to someone who has to decrypt or modify the traffic after intercepting it, without having to disclose that backdoor in certificate transparency logs. And in a data center scenario, perhaps people feel more comfortable loading those short-term credentials into their monitoring equipment. From nobody Fri Nov 1 13:34:16 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCFE12006A for ; Fri, 1 Nov 2019 13:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fb.com header.b=m/zPaoqg; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=fDlFUdAk 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 KzCHlzT7hLQ1 for ; Fri, 1 Nov 2019 13:34:13 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 11450120013 for ; Fri, 1 Nov 2019 13:34:13 -0700 (PDT) Received: from pps.filterd (m0148460.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xA1KXwts030924; Fri, 1 Nov 2019 13:34:07 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=u9vvbBBqMqHE6sTN0TgiiavgSqTfIAl8DLGweGSbk38=; b=m/zPaoqgIFi53y4mmlNLwOpDq24KYWPwjMjTRkUl9212EYxJ9iXt1Ux+C5Yud3RnG6PT qyFBALRGDVew5e/CgUozWZ73i/p+5phdAahFZJ1lwPmkFYf8lRirr3oVbXfzc+fpncH7 UYIXVhMdNF0JJttvvcpYSwSCwp1GrmGydUM= Received: from maileast.thefacebook.com ([163.114.130.16]) by mx0a-00082601.pphosted.com with ESMTP id 2w0rsq917x-9 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 01 Nov 2019 13:34:06 -0700 Received: from ash-exhub103.TheFacebook.com (2620:10d:c0a8:82::c) by ash-exhub204.TheFacebook.com (2620:10d:c0a8:83::4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 1 Nov 2019 13:33:49 -0700 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (100.104.31.183) by o365-in.thefacebook.com (100.104.35.174) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5 via Frontend Transport; Fri, 1 Nov 2019 13:33:49 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iYd7DgEyltZqQ137OU0d7BlO804N2c7QjlV25rsjrToiyIrWSw69rSSmm3IAFEv4ssoxOZs8jeTT9Lsst5Wdz8z25XNmNrf1a9Vy+KzTwBk+d71gYJhts18IrZWoVazktX6gRnaQv46WRcdhXxBWOZmn9Cw2C1wdO3/1LxKYUsXlLKgY2+JkbXIwgpr9I8IvfpUJAdAzEsuBSEZcxIV/4F4NYMtyK6dB2OxOC7o0wQZ/9be7TZCBZ1lDADQM5TpuySOn1X0zgHY5mX70uwDj1RiGYL6SmuZNRRj3PFqUYPr3GrrOsf79oAV1S1MrKIEafpBSUExsd0YHSx6tqhQMkg== 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=u9vvbBBqMqHE6sTN0TgiiavgSqTfIAl8DLGweGSbk38=; b=AQmkGoNb1ipL1wkFMOZDZvtO5dQNH46UcRXGlk9aY8q0mlkh9IcOVcQ4petMHG/6V/BEi+5h5mY2/csfdq2Q6aN5LesKSRBFDLshrJ/T27b7uArYlSxMc9aqq3zYVeWMV6V0100CWkLmkhRWBYXknFbftCLy+qaOT9pnHWoCfv+MSjhtd3JFXGCU0GYJzEPO/ucuDoNtUXhjmsiuDCcVDwnlzLYpm1QaC/OupLHYD+A9bTEtgsIgjt9RPk/1neC26ULPSEbEjRzaqD9Lm2lzuhJs0974vuKtqxCV2nEvC/tfa0PySxdDIK6NjmZfEu/uKoKLwI70owN4vZ6q8gxEYw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=fb.com; dmarc=pass action=none header.from=fb.com; dkim=pass header.d=fb.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector2-fb-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u9vvbBBqMqHE6sTN0TgiiavgSqTfIAl8DLGweGSbk38=; b=fDlFUdAkko4qfb0hRAQm2C4tmnvUBCnT+dfFYPOlab7Qw5IUrY9xKwitooz7yaEg0VLe96sUpmm4p3bLkpRpBPW2fwwTa+byWSVy1edz4iPUpgPikeLDz++Vqh2bUAJ9VaQvQ+AVWyLCjgFyE9MHDQg5tp3GfO1XKqCqb1E/L8k= Received: from MWHPR15MB1821.namprd15.prod.outlook.com (10.174.255.137) by MWHPR15MB1566.namprd15.prod.outlook.com (10.173.234.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.23; Fri, 1 Nov 2019 20:33:48 +0000 Received: from MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::51e5:dfc2:72a1:da9]) by MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::51e5:dfc2:72a1:da9%4]) with mapi id 15.20.2387.028; Fri, 1 Nov 2019 20:33:48 +0000 From: Subodh Iyengar To: Florian Weimer , "tls@ietf.org" Thread-Topic: [TLS] Delegated Credentials and Lawful Intercept Thread-Index: AQHVkPD9+4+EWuIzlkuZhOUV6y7gqKd2xC4T Date: Fri, 1 Nov 2019 20:33:48 +0000 Message-ID: References: <87zhhfcq2i.fsf@mid.deneb.enyo.de> In-Reply-To: <87zhhfcq2i.fsf@mid.deneb.enyo.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::1:7bdb] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 04db2868-a6f5-48ea-3feb-08d75f0acccd x-ms-traffictypediagnostic: MWHPR15MB1566: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 020877E0CB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(136003)(346002)(366004)(39860400002)(189003)(199004)(25786009)(71200400001)(54896002)(71190400001)(186003)(74316002)(102836004)(46003)(6116002)(66446008)(478600001)(229853002)(966005)(99286004)(6506007)(53546011)(19627405001)(6436002)(7696005)(9686003)(8936002)(105004)(2906002)(76176011)(55016002)(66946007)(6246003)(76116006)(66476007)(66556008)(64756008)(6306002)(52536014)(5660300002)(86362001)(14454004)(236005)(316002)(2501003)(7736002)(256004)(81156014)(110136005)(8676002)(33656002)(11346002)(446003)(476003)(486006)(81166006)(606006); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1566; H:MWHPR15MB1821.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XouVdK492pS23aCz6a6S4lISd1h4AXAVwkOTniSfJyBAPY4rew4LYv04I2fpLYrw5+8s3nmL+arVnM7t6JYf9tUEPxWhsX7d+LSYGK6ZkPDDYosfRHoaWoXXGvx1umSFq3iewzn0ckYzTKLHKYnOTs0p+xSSjpIThMNm+Fsk6Dc5eV3n5u0U3Hd7MjxQF32bxKZ7Gbtaamp7f6mElmqGncVcBqYoVetYax9cO3FRHWj8Xl75cz9lus8HErYjQIGhPVRFypLH/rJybdfIoCnU39SPGj3CpWbWFqZC+lYyi5tgdbZQ82tPvYXKz9qtHDKc72S2p/InAds0SOzuDJUskW0oYtqaSbnnXD/4c1oJT1Qs941PDcnHJgtOrrIPzWNu6DdDXlwDcjyLI0tD1s0W9XCKGLVh9gLv4XPCAbrfwt9YGN1X5VXEWdvzIsbh4jwmEDsAgxM4kyKLccUJ26zSu0r4pENR7Q0vQ6Z8KwD9e3E= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR15MB18211790250034085A9E3123B6620MWHPR15MB1821namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 04db2868-a6f5-48ea-3feb-08d75f0acccd X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2019 20:33:48.4880 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /CDHf9t3Az7A7HMUFwJnmI7UlPgJL9E7JO0QI582Vq259Oq0b2fRxvPijDoBZKQI X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1566 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-11-01_07:2019-11-01,2019-11-01 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 mlxlogscore=999 adultscore=0 suspectscore=0 phishscore=0 clxscore=1011 priorityscore=1501 impostorscore=0 spamscore=0 malwarescore=0 bulkscore=0 mlxscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1911010190 X-FB-Internal: deliver Archived-At: Subject: Re: [TLS] Delegated Credentials and Lawful Intercept X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 20:34:15 -0000 --_000_MWHPR15MB18211790250034085A9E3123B6620MWHPR15MB1821namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I do not entirely have context on for the requirements for something like t= hat, I would imagine that the requirements would be significantly different= and would need to be clearly defined. However, at a high level I'm not sure using a DC would be different from a provider obtaining a cert= ificate for a short time duration instead. The DC use case for short durati= on is for increased reliability during normal service operation, however fo= r these kinds of cases, which might be one off use cases, one could obtain = a real certificate. Subodh ________________________________ From: TLS on behalf of Florian Weimer Sent: Friday, November 1, 2019 1:13 PM To: tls@ietf.org Subject: [TLS] Delegated Credentials and Lawful Intercept Would it be possible to use delegated credentials to address lawful intercept concerns, similar to eTLS? Basically, the server operator would issue a delegated credential to someone who has to decrypt or modify the traffic after intercepting it, without having to disclose that backdoor in certificate transparency logs. And in a data center scenario, perhaps people feel more comfortable loading those short-term credentials into their monitoring equipment. _______________________________________________ TLS mailing list TLS@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_tls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-wAyN= 7fQ&m=3Dt6MvhK2KrPUKpEpozCS52kUs5eut_Pp-vjNPUa2R8gw&s=3DB6JEL8LBe1zq0d4EA0G= gjAf8-H3ocB-zBLNnDTFkToM&e=3D --_000_MWHPR15MB18211790250034085A9E3123B6620MWHPR15MB1821namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I do not entirely have context on for the requirements for something like t= hat, I would imagine that the requirements would be significantly different= and would need to be clearly defined.  However, at a high level
I'm not sure using a DC would be different from a provider obtaining a cert= ificate for a short time duration instead. The DC use case for short durati= on is for increased reliability during normal service operation, however fo= r these kinds of cases, which might be one off use cases, one could obtain a real certificate.

Subodh
From: TLS <tls-bounces@i= etf.org> on behalf of Florian Weimer <fw@deneb.enyo.de>
Sent: Friday, November 1, 2019 1:13 PM
To: tls@ietf.org <tls@ietf.org>
Subject: [TLS] Delegated Credentials and Lawful Intercept
 
Would it be possible to use delegated credentials = to address lawful
intercept concerns, similar to eTLS?

Basically, the server operator would issue a delegated credential to
someone who has to decrypt or modify the traffic after intercepting
it, without having to disclose that backdoor in certificate
transparency logs.

And in a data center scenario, perhaps people feel more comfortable
loading those short-term credentials into their monitoring equipment.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://u= rldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo= _tls&d=3DDwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-w= AyN7fQ&m=3Dt6MvhK2KrPUKpEpozCS52kUs5eut_Pp-vjNPUa2R8gw&s=3DB6JEL8LB= e1zq0d4EA0GgjAf8-H3ocB-zBLNnDTFkToM&e=3D
--_000_MWHPR15MB18211790250034085A9E3123B6620MWHPR15MB1821namp_-- From nobody Fri Nov 1 14:28:15 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57FBE120A55 for ; Fri, 1 Nov 2019 14:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 fVLvrufUeL1z for ; Fri, 1 Nov 2019 14:28:08 -0700 (PDT) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 EB0DC12024E for ; Fri, 1 Nov 2019 14:28:02 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id d83so9847849ilk.7 for ; Fri, 01 Nov 2019 14:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=z/tfh+2JQuhkDz76ObINuI/QXJHadBHayS1sRO3MHvY=; b=jpFVm5IYm1P/ysbVdW/faOCb52QzmiQRI8koG+EUm6CowmxIxZHk2QRQrLjjztTwzY J/c03e+lZoI3gOWgV8dMvf8gfF3PSRHv8JMdS4+JQFE/mdNhnmesIRPf074rqrRWgaaK 65wiBIKVEFD/o8pCmuQCHV0ztvZyQujYXbk8StLm9Xg2Vz3VDp35CcqbeN72TN9NyDRW wmzUZxcbzepT4aIskIMqqgyV4xME5nPetn6c45/A5Sq8Yg7qcHLTnbC+BhqBcl5RkyMt gsND6ULahf14ceezbs2n/+PydCAfMfrwK65Ssb/PehMldgw6rabHh1iclkB0bdnJObHD 8gNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=z/tfh+2JQuhkDz76ObINuI/QXJHadBHayS1sRO3MHvY=; b=oJVYv0PCS18SgZuEJ3Foix7m70g37rQeuJ9FtiOy6ruSX7U7zJYGu1TT91n2gj5NP1 ARtoH7WcnzE/nVhTYBqOsv5a2pI/yOrUGv6F2t4XGz3tY4IfPp1sugs9v8MgeWi4mXCA s63wKfzt++GiD/sMkymvJi7ZRvs7LKkVWxVqZlbORjPJN2QYwaB0GUA8ouDa6FX3evi3 z2md/8wX/5xL/pEUsWjbqdP1FKrmMYtHd9llkaohi+DWol8PtugPySwOlMd47Njdc2/g d5ItIIPWc/ACfG4gOCg9mlqqT6dPOKOWIbnVmjM/8+uWDzERdsrvr/ksL3iU56OXSeT8 PvPw== X-Gm-Message-State: APjAAAXsqZSglLP4orcog+HM5x7RAzMawWFPG1ebLs41jN1w2NpwZEeW vCoP9rLC3uLvTsepDNNKbBaLnSwN13xZC1cHw8N5T2WEhdQ= X-Google-Smtp-Source: APXvYqz0rzNif6P9U48Pence8/24Dl+pR+vxPFO6DcLJbn/1u/gAwKgbXZzEyj+QleiKAZxRWst1kga8V+hyfrKMDyc= X-Received: by 2002:a92:db0c:: with SMTP id b12mr15539906iln.49.1572643681798; Fri, 01 Nov 2019 14:28:01 -0700 (PDT) MIME-Version: 1.0 From: Rob Sayre Date: Fri, 1 Nov 2019 14:27:50 -0700 Message-ID: To: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000312ff05964fa4fc" Archived-At: Subject: [TLS] predictability of inputs in ESNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 21:28:15 -0000 --0000000000000312ff05964fa4fc Content-Type: text/plain; charset="UTF-8" Hi, I am not sure how important these findings are, but I've noticed three instances of unnecessarily predictable inputs in ESNI: 1) Trailing padding after domain names are zeros. 2) The checksum calculation seems to start with predictable version bytes in draft -04, and in shipping implementations 3) In practice, NSS inserts 8 bytes of zeros at the beginning of its AAD input () It seems like these values should all be allowed to be opaque, and I am not sure why NSS is prepending zeros to its AAD (although I asked in the github issue). thanks, Rob --0000000000000312ff05964fa4fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I am not sure how important the= se findings are, but I've noticed three instances of unnecessarily pred= ictable inputs in ESNI:

1) Trailing padding after = domain names are zeros.
2) The checksum calculation seems to star= t with predictable version bytes in draft -04, and in shipping implementati= ons
3) In practice, NSS inserts 8 bytes of zeros at the beginning= of its AAD input (<https://github.com/tlswg/draft-ietf-tls-esni/issues/190= >)

It seems like these values should all be all= owed to be opaque, and I am not sure why NSS is prepending zeros to its AAD= (although I asked in the github issue).

thanks,
Rob
--0000000000000312ff05964fa4fc-- From nobody Fri Nov 1 15:09:50 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222A212088B for ; Fri, 1 Nov 2019 15:09:47 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 yJN9TI4ZX4Dm for ; Fri, 1 Nov 2019 15:09:45 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F189C120130 for ; Fri, 1 Nov 2019 15:09:43 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id a6so4848150lfo.3 for ; Fri, 01 Nov 2019 15:09:43 -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=PnywTRhr+G77dnJlvGFqPaTedlPTUmcd+zzUYj/D5tA=; b=Z9DFR6k4VfbPQ2fiTe2jlAtC96fMpp1LmBkbZJ5DXTxdRctFBmGCSfiVOsPy1mP37i d70dxM9AVX4fxVwEPJyRDKQ/2Q0gvvhDkGsvUW1UbbvX7/Tjmce5PscKXL/ZUcamFS0K 476f4HUXIVhDZIJmEozZVHaMzQzT1nIF1hGJC6GqtDRzjQgSXG8MAlo2oGAp4IsHXMSP jZT+JzJMF80Ow7lb/wytcij04EwLcnLGsSMXGKEKSFwFbgdSeBmAN2tM0Nt3HlBDzqvt UC4MmQNFjezQtimve08l/7DiUJJPnbLzWQCfHBT+ToMIyxlC4EKMCsll55Wp6DSTPu/T LfXQ== 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=PnywTRhr+G77dnJlvGFqPaTedlPTUmcd+zzUYj/D5tA=; b=iy4aTAHJwW0HUMLEotnPWMcefpV4kr5dLAeXoEkCYhfYsckSK64HV1aoZDlUjRg1I2 +pN7VOWoyI3rqyKhM9TXOKkmZyaFeQmnZ1EuJjRoOoAcapnIiWLr/2zMsvoQs+jv0bF8 j2sJEUyzm31UwJvU0P6VR8I1/iN1rYY9JhiaqASYypwjy7OyqKsIx5A9diXkiBkjm0D1 tog69U8vjMSxb5zl9Pf/wjSvzdaOcPIYX9Ezgtf40WtN7RiemOoOYr320aCs71bbstAy 1FM1bgIr58Za5oAzS2OEd2ItHPn3u/qej1DfGoRF8O8hFOjhMlDcSUyrd+fLQ0rkcfUs SVXQ== X-Gm-Message-State: APjAAAWC8Zc71SOou4gcZL8nZKe871HPi6KD+rkQMj1gHpNNLIQkIANO 06sB7QuBR8MPhL3PtYcWXd43zHcH0rgP5cIaTffwpw== X-Google-Smtp-Source: APXvYqysUvwWqEdXIjsNloRo74N6tihmRE8etuLeJn9F/a055joEl1AN/XyLiCJPEYuGq31XdY934UKfgfIBXhmsU34= X-Received: by 2002:ac2:4a72:: with SMTP id q18mr8891471lfp.184.1572646182226; Fri, 01 Nov 2019 15:09:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Fri, 1 Nov 2019 15:09:06 -0700 Message-ID: To: Rob Sayre Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000ca068059650397e" Archived-At: Subject: Re: [TLS] predictability of inputs in ESNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 22:09:47 -0000 --0000000000000ca068059650397e Content-Type: text/plain; charset="UTF-8" On Fri, Nov 1, 2019 at 2:28 PM Rob Sayre wrote: > Hi, > > I am not sure how important these findings are, but I've noticed three > instances of unnecessarily predictable inputs in ESNI: > > 1) Trailing padding after domain names are zeros. > 2) The checksum calculation seems to start with predictable version bytes > in draft -04, and in shipping implementations > I'm not aware of any cryptographic reason why these would be a problem. It's reasonably common practice to have partially fixed inputs to the TLS cryptographic functions (see, for instance, HMAC labels and the trailing padding 0s in the record protection). In general, if this sort of thing turns out to be a problem for some algorithm, we consider it to be a problem with the algorithm. 3) In practice, NSS inserts 8 bytes of zeros at the beginning of its AAD > input () > I believe you're misreading the code. For historical reasons, the internal NSS TLS AEAD API prefixes the AAD argument with the sequence number. When we repurposed this code for ESNI, we just passed in a 0 sequence number. That value is stripped off and is not part of the AAD computation. It seems like these values should all be allowed to be opaque, and I am not > sure why NSS is prepending zeros to its AAD (although I asked in the github > issue). > As I said, it's not. -Ekr --0000000000000ca068059650397e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Nov 1, 2019 at 2:28 PM Rob Sa= yre <sayrer@gmail.= com> wrote:
Hi,

I am not sure how important = these findings are, but I've noticed three instances of unnecessarily p= redictable inputs in ESNI:

1) Trailing padding aft= er domain names are zeros.
2) The checksum calculation= seems to start with predictable version bytes in draft -04, and in shippin= g implementations

I'm not a= ware of any cryptographic reason why these would be a problem. It's rea= sonably common practice to have partially fixed inputs to the TLS cryptogra= phic functions (see, for instance, HMAC labels and the trailing padding 0s = in the record protection). In general, if this sort of thing turns out to b= e a problem for some algorithm, we consider it to be a problem with the alg= orithm.


3) In practice, NSS inserts 8 b= ytes of zeros at the beginning of its AAD input (<https://git= hub.com/tlswg/draft-ietf-tls-esni/issues/190>)

I believe you're misreading the code. For histor= ical reasons, the internal NSS TLS AEAD API prefixes the AAD argument with = the sequence number. When we repurposed this code for ESNI, we just passed = in a 0 sequence number. That value is stripped off and is not part of the A= AD computation.


It seems like these val= ues should all be allowed to be opaque, and I am not sure why NSS is prepen= ding zeros to its AAD (although I asked in the github issue).

As I said, it's not.

-Ekr


--0000000000000ca068059650397e-- From nobody Fri Nov 1 15:27:20 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2158120130 for ; Fri, 1 Nov 2019 15:27:19 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 VZEpf7T2gUuL for ; Fri, 1 Nov 2019 15:27:18 -0700 (PDT) Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 4FF9412088B for ; Fri, 1 Nov 2019 15:27:18 -0700 (PDT) Received: by mail-il1-x143.google.com with SMTP id t9so7676979ils.4 for ; Fri, 01 Nov 2019 15:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X+Jm6Rsg5Ri/lP1StGZfuYXQCd9WGz6ldQ1z6dlcfb4=; b=QA4vSI6ayApfwWyU/pGF1LqWg0j5LQZzvx2upDkHHswapPQ/gJyjOIOEawB5hz3IsH S3FonKtLCuxd1MJMLXYy4qnBwxSsO4t7vW9JvOsYAVe97f76L4Z5UU8lXnRbinoQEUxW sXe8AbRErbsKJc2C1YKQLLVB2UG5H9EbdEhNy/MvCZeb7q+ORxTaUPh3NRUpswiq5OXJ 9kdczcjHkOgt2LC9W3I7Exx3zTft/O20n7d0zBuH1gQRj4s4JUiK9gjVfC7DQEqruBBi 1xTW/2wcYSwPSmV9qNn8/JtXFXrvd1LzuI33EKjcPdjvimGEwYcvdzpZ8XHrwIq1AypD MWkw== 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=X+Jm6Rsg5Ri/lP1StGZfuYXQCd9WGz6ldQ1z6dlcfb4=; b=RXmLLr5NvkTT4kV0E1s7Od5tr8cXEf3RD5KJlDWDrwddqOd46+8s3wiTQ4PYBA0cSf Om/nU80WGVaeZ6+/O6t1fVrp5zM+hXxbrk9X3cOGvr1WOGdhsFF3eXWhpgH0soo28Ofs BGxQaZ3qVeocXMEIv07Na3epcmaF2fdWJF32dC6cTS9nvBWB1ycM/fLotmlhQncAD3mE wVlBTF6oL3U12nTbiqWZD5ti0y1S5Z6eQEPJU0i9q8vpaouYxcvJokplQnXW4kNgRcYy ZOByK9iEKRks8LywNTJbJgVyHez/KkEbjtrgwL7TzD/fSgBtJAM+w6Yn2lVFV3QSinPa Dv/A== X-Gm-Message-State: APjAAAW2a5iV37KqIkMW6VlCF39F/j3CzrYcvaWT0eOltW2M6TuGV1Bt NfuHkq7+J6YWPy+PTyUAawtyJ6D2KIYlYwMMqI5q3wY3 X-Google-Smtp-Source: APXvYqyAS42N/e5AWNyjsuN7p/uEjPe7aphI6RvyyvKTtezivPLFzKJZXaTiOiYucW+wJAPbU8vDvNMtGrVlAc/kyT4= X-Received: by 2002:a92:48cf:: with SMTP id j76mr14662359ilg.189.1572647237400; Fri, 01 Nov 2019 15:27:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Fri, 1 Nov 2019 15:27:06 -0700 Message-ID: To: Eric Rescorla Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f13fca059650771d" Archived-At: Subject: Re: [TLS] predictability of inputs in ESNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 22:27:20 -0000 --000000000000f13fca059650771d Content-Type: text/plain; charset="UTF-8" On Fri, Nov 1, 2019 at 3:09 PM Eric Rescorla wrote: > > > On Fri, Nov 1, 2019 at 2:28 PM Rob Sayre wrote: > >> Hi, >> >> I am not sure how important these findings are, but I've noticed three >> instances of unnecessarily predictable inputs in ESNI: >> >> 1) Trailing padding after domain names are zeros. >> > 2) The checksum calculation seems to start with predictable version bytes >> in draft -04, and in shipping implementations >> > > I'm not aware of any cryptographic reason why these would be a problem. > It's reasonably common practice to have partially fixed inputs to the TLS > cryptographic functions (see, for instance, HMAC labels and the trailing > padding 0s in the record protection). In general, if this sort of thing > turns out to be a problem for some algorithm, we consider it to be a > problem with the algorithm. > I see. But is there any reason to make these inputs predictably zero by spec? > > > 3) In practice, NSS inserts 8 bytes of zeros at the beginning of its AAD >> input () >> > > I believe you're misreading the code. For historical reasons, the internal > NSS TLS AEAD API prefixes the AAD argument with the sequence number. When > we repurposed this code for ESNI, we just passed in a 0 sequence number. > That value is stripped off and is not part of the AAD computation. > I see, so you're saying that NSS adds 8 bytes to the AAD input, and then strips it off at some later point? I wouldn't exactly call that misreading. Maybe something to fix? thanks, Rob --000000000000f13fca059650771d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Nov 1, 2019 at 3:09 PM Eric Resco= rla <ekr@rtfm.com> wrote:


On Fri, Nov 1, 2019 at 2:28 PM Ro= b Sayre <sayrer@gm= ail.com> wrote:
Hi,

I am not sure how import= ant these findings are, but I've noticed three instances of unnecessari= ly predictable inputs in ESNI:

1) Trailing padding= after domain names are zeros.
2) The checksum calcula= tion seems to start with predictable version bytes in draft -04, and in shi= pping implementations

I'm n= ot aware of any cryptographic reason why these would be a problem. It's= reasonably common practice to have partially fixed inputs to the TLS crypt= ographic functions (see, for instance, HMAC labels and the trailing padding= 0s in the record protection). In general, if this sort of thing turns out = to be a problem for some algorithm, we consider it to be a problem with the= algorithm.

I see. Bu= t is there any reason to make these inputs predictably zero by spec?
<= div>
=C2=A0


3) In practice, NSS inserts 8 bytes of zeros at the beginning= of its AAD input (<https://github.com/tlswg/draft-ietf-tls-e= sni/issues/190>)

I belie= ve you're misreading the code. For historical reasons, the internal NSS= TLS AEAD API prefixes the AAD argument with the sequence number. When we r= epurposed this code for ESNI, we just passed in a 0 sequence number. That v= alue is stripped off and is not part of the AAD computation.

I see, so you're saying that NSS ad= ds 8 bytes to the AAD input, and then strips it off at some later point? I = wouldn't exactly call that misreading. Maybe something to fix?

thanks,
Rob

--000000000000f13fca059650771d-- From nobody Fri Nov 1 15:40:14 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64916120801 for ; Fri, 1 Nov 2019 15:40:12 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 asIiVUQZbkW6 for ; Fri, 1 Nov 2019 15:40:10 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 0DBCF120828 for ; Fri, 1 Nov 2019 15:40:00 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id y6so8293070lfj.2 for ; Fri, 01 Nov 2019 15:39:59 -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=Y0WchmENDLLHDWq2K4XrxNJ/mJ2KtFSr50yDbUtKpFI=; b=HJq4Dt3ClAoQj3YyB5j55hK4XnVsYin0YoUYiBygNGDqxMEXgfd44Q0OMgqFIDJCjX bTkAyPWNCtp6R7jEkSTzaW916tDtvxFUitry3rbbPJHLG5DZYJOU2+KYK616RS6CfO2X gTDdnI2RJcUshSSiXGlUcaxkazlNTEE4jKRnGAcRoI4hJNXBGmdzxnOnLoACsebGtbFh woQwwR95libhtJ7XW/h768wbWF8uHFfOytr6BUj6UB5ohFXTyMxs9OAKLxz1u+bmv4zP XChb2UvW157HEhfraw7clNTUpHE61KeJQq2lFFMSDrgxGZT4e9W3X9PrFDd+iEr4fm0q d+wg== 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=Y0WchmENDLLHDWq2K4XrxNJ/mJ2KtFSr50yDbUtKpFI=; b=et4L3ONn+SyF3M8/IFDV41/ZAdF2BJ6YAZnHMTac+ISC2sjdoUwZATDH5BU7ET5vZ0 46sQySzBsIiJ4C5lY3WzX+h4XKPzyxXGphVJuXTWjst35wqYM5nqJXXHKRnRSmeSl6en 9nEshBhUA+L3owTvAdsCApKgaDeVKw/OJcJj97VlvGNOUwlEG7AKAYUiVn3hLZeVmj5k xnxyXEYjJcO+wbY0Yq9gcTzh+aYvdp/KmYh7grZfz1MmbxQB9Qo3I8MhjzNaUM/CyPoJ d6wtm+J8qblRI7BNvsC6ugBZZMOFQ8YT4/V2CN7MjVY8KszaClO6n4gKI6VQob57nQbo I+PQ== X-Gm-Message-State: APjAAAW9gWXolZpwYufsweBu0/OG6B9GPn8erDnBhmHp56zYRsFd0E85 LOxqjMsE5AQRrduBtA9gBlGt2coDyXYKVzf5uBOQoQ== X-Google-Smtp-Source: APXvYqzQ5I7Za4cI4rDNti7zbZ6cO7px83hZd9lvs1rVOChDzCnxaaDjSos93x3TkLUL8NZ0KLr99ziwyQACRs9PaQo= X-Received: by 2002:a19:c6d6:: with SMTP id w205mr8036254lff.17.1572647998373; Fri, 01 Nov 2019 15:39:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Fri, 1 Nov 2019 15:39:22 -0700 Message-ID: To: Rob Sayre Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004cd7d6059650a59a" Archived-At: Subject: Re: [TLS] predictability of inputs in ESNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 22:40:12 -0000 --0000000000004cd7d6059650a59a Content-Type: text/plain; charset="UTF-8" On Fri, Nov 1, 2019 at 3:27 PM Rob Sayre wrote: > On Fri, Nov 1, 2019 at 3:09 PM Eric Rescorla wrote: > >> >> >> On Fri, Nov 1, 2019 at 2:28 PM Rob Sayre wrote: >> >>> Hi, >>> >>> I am not sure how important these findings are, but I've noticed three >>> instances of unnecessarily predictable inputs in ESNI: >>> >>> 1) Trailing padding after domain names are zeros. >>> >> 2) The checksum calculation seems to start with predictable version bytes >>> in draft -04, and in shipping implementations >>> >> >> I'm not aware of any cryptographic reason why these would be a problem. >> It's reasonably common practice to have partially fixed inputs to the TLS >> cryptographic functions (see, for instance, HMAC labels and the trailing >> padding 0s in the record protection). In general, if this sort of thing >> turns out to be a problem for some algorithm, we consider it to be a >> problem with the algorithm. >> > > I see. But is there any reason to make these inputs predictably zero by > spec? > Absent some reason not to, this seems like a reasonable design choice. At minimum, it has the advantage that it's easy to detect some classes of implementation errors. 3) In practice, NSS inserts 8 bytes of zeros at the beginning of its AAD >>> input () >>> >> >> I believe you're misreading the code. For historical reasons, the >> internal NSS TLS AEAD API prefixes the AAD argument with the sequence >> number. When we repurposed this code for ESNI, we just passed in a 0 >> sequence number. That value is stripped off and is not part of the AAD >> computation. >> > > I see, so you're saying that NSS adds 8 bytes to the AAD input, and then > strips it off at some later point? > No. I'm saying that the function argument is called |additionalData| but that's not what's used as AAD in the actual cryptographic function. I wouldn't exactly call that misreading. > This seems like a definitional question that is not worth debating. Maybe something to fix? > This is not on topic for this mailing list. This internal interface is quite old and when we wrote the TLS 1.3 code, we considered changing it and decided it wasn't worth it. If you'd like to submit a CL to NSS which improves this, we'll take a look. -Ekr --0000000000004cd7d6059650a59a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Nov 1, 2019 at 3:27 PM Rob Sa= yre <sayrer@gmail.com> wrote:=
On Fri, Nov 1, 2019 at 3:09 PM Eric Rescorla <ekr@rtfm.com> wrote:
<= /div>


On Fri, Nov 1, 2019 at 2:28 PM= Rob Sayre <sayrer= @gmail.com> wrote:
Hi,

I am not sure how im= portant these findings are, but I've noticed three instances of unneces= sarily predictable inputs in ESNI:

1) Trailing pad= ding after domain names are zeros.
2) The checksum cal= culation seems to start with predictable version bytes in draft -04, and in= shipping implementations

I'= ;m not aware of any cryptographic reason why these would be a problem. It&#= 39;s reasonably common practice to have partially fixed inputs to the TLS c= ryptographic functions (see, for instance, HMAC labels and the trailing pad= ding 0s in the record protection). In general, if this sort of thing turns = out to be a problem for some algorithm, we consider it to be a problem with= the algorithm.

I see= . But is there any reason to make these inputs predictably zero by spec?

Absent some reason not to, = this seems like a reasonable design choice. At minimum, it has the advantag= e that it's easy to detect some classes of implementation errors.


<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
3) I= n practice, NSS inserts 8 bytes of zeros at the beginning of its AAD input = (<https://github.com/tlswg/draft-ietf-tls-esni/issues/190= >)

I believe you're misr= eading the code. For historical reasons, the internal NSS TLS AEAD API pref= ixes the AAD argument with the sequence number. When we repurposed this cod= e for ESNI, we just passed in a 0 sequence number. That value is stripped o= ff and is not part of the AAD computation.

I see, so you're saying that NSS adds 8 bytes to the = AAD input, and then strips it off at some later point?

No. I'm saying that the function argumen= t is called |additionalData| but that's not what's used as AAD in t= he actual cryptographic function.


I wouldn't exactly call that misreading.
=

This seems like a definitional quest= ion that is not worth debating.


Maybe something to fix?

This is not on topic for this mailing list. This internal i= nterface is quite old and when we wrote the TLS 1.3 code, we considered cha= nging it and decided it wasn't worth it. If you'd like to submit a = CL to NSS which improves this, we'll take a look.

<= div>-Ekr

--0000000000004cd7d6059650a59a-- From nobody Fri Nov 1 15:54:18 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5E1120828 for ; Fri, 1 Nov 2019 15:54:15 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 aC2k2seHnKHU for ; Fri, 1 Nov 2019 15:54:13 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 6487E120801 for ; Fri, 1 Nov 2019 15:54:13 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id j2so7843032ilc.10 for ; Fri, 01 Nov 2019 15:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o8khKGrX0KYCoNj3Dl45E6gUOVAXvxEsricAtwCQpQA=; b=t6mCSyIQ1zpmUjBFAXXkyzgdsP1rJccqdkSGgBduRmsNVa4TkvhEqMxG+q25Zz9cCt 6cxWggoP0NUXsiiYIEMZjOratQxNttbc5Qop35gOnU4EF95TrXOrXVWpNndxX9j8xLE2 1fUflRBi/GMwSFbGyRUX1ySu84Hm+7bFGn/ZuIuTs+tsEzw20g7b7DR8S8dv5DfMF2z2 bV90ic4vUDcYwTmVlYLVjUhqXGmPfbHpb25BtKFRtQLBz2V3Q7z8OUxCRnXI7hAGwXnr qqOQfrjr3b+mv4/GIvzZcaE8b84NItS23fQ/lO7DZ1ACSRxki89r831dNO/OugL3KkKp LGxg== 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=o8khKGrX0KYCoNj3Dl45E6gUOVAXvxEsricAtwCQpQA=; b=CA00SG1dIhOIqQCd9h/OGhkv22lp2roTiaLALCWoz4Wsr6B0pe6oQLWkN8GR5UBVFH z8dKQF8ZmYm0oLm8zoRv7Sn6LPQ99jP7tjdbXpO0p4ZBP2Zc36/xVhmi0OKBoDkuKgGZ ZxcPHfr5cepg1n4eUf8UAkSkSLA6njZwuct3xRmmWVnDep6XrcJPVGe2X8JoVYC+fn58 Au0EpWmMylMqBvOrv0ZuNmDPwmgl4hxMvYQWRZ6W5OppIoZbmkHgLESlR/7/p9/MerxW BpYypNNCIvvkd4aljeM+e1I2soyeHc4Dz7SyRBHZFZ0EpKYbIrgOGDSzpHOANtqQ8wdB ypOg== X-Gm-Message-State: APjAAAUixvQ7N4JvnwM/yMFnA2CXc/LgNhJjRlmfPfej56k92erNmkC7 qmZ0r3OFdCLUjWjpwLzF96+87G3GczBfjbhLlvhXj5ijP5I= X-Google-Smtp-Source: APXvYqwtRzrTj1gv7xn9WwU4FTDJ6GoZsWKs+MHQ9tZgUkPSHxOQpQl7m+blH8gFCNyd2ZnaBSYTvj9wvAesjKbanDE= X-Received: by 2002:a05:6e02:a:: with SMTP id h10mr15123763ilr.254.1572648852392; Fri, 01 Nov 2019 15:54:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Fri, 1 Nov 2019 15:54:01 -0700 Message-ID: To: Eric Rescorla Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000034128f059650d837" Archived-At: Subject: Re: [TLS] predictability of inputs in ESNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 22:54:16 -0000 --00000000000034128f059650d837 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 1, 2019 at 3:39 PM Eric Rescorla wrote: > >>> >> I see. But is there any reason to make these inputs predictably zero by >> spec? >> > > Absent some reason not to, this seems like a reasonable design choice. At > minimum, it has the advantage that it's easy to detect some classes of > implementation errors. > I don't think the current spec is a good idea. It mandates padding with zeros, and lets servers dictate a length. I think the client should dictate the length, at least. > 3) In practice, NSS inserts 8 bytes of zeros at the beginning of its AAD >>>> input () >>>> >>> >>> I believe you're misreading the code. For historical reasons, the >>> internal NSS TLS AEAD API prefixes the AAD argument with the sequence >>> number. When we repurposed this code for ESNI, we just passed in a 0 >>> sequence number. That value is stripped off and is not part of the AAD >>> computation. >>> >> >> I see, so you're saying that NSS adds 8 bytes to the AAD input, and then >> strips it off at some later point? >> > > No. I'm saying that the function argument is called |additionalData| but > that's not what's used as AAD in the actual cryptographic function. > > > I wouldn't exactly call that misreading. >> > > This seems like a definitional question that is not worth debating. > Hey now, you're the one that wrote "misreading" initially. If "additional data" is not what's used as "additional authenticated data" in the end, fine. > > Maybe something to fix? >> > > This is not on topic for this mailing list. > I think it is, since no one could read any ESNI draft and get the DNS record's checksum right, at the very least. So, there are some issues where it can be hard to tell if the spec is wrong, my implementation is wrong, or another implementation is wrong. thanks, Rob --00000000000034128f059650d837 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Nov 1, 2019 at 3:39 PM Eric R= escorla <ekr@rtfm.com> wrote:
=
=


I see. But is there any rea= son to make these inputs predictably zero by spec?

Absent some reason not to, this seems like a reas= onable design choice. At minimum, it has the advantage that it's easy t= o detect some classes of implementation errors.

I don't think the current spec is a good ide= a. It mandates padding with zeros, and lets servers dictate a length. I thi= nk the client should dictate the length, at least.

=C2=A0
3) In pr= actice, NSS inserts 8 bytes of zeros at the beginning of its AAD input (<= ;https://github.com/tlswg/draft-ietf-tls-esni/issues/190>= )

I believe you're misreadi= ng the code. For historical reasons, the internal NSS TLS AEAD API prefixes= the AAD argument with the sequence number. When we repurposed this code fo= r ESNI, we just passed in a 0 sequence number. That value is stripped off a= nd is not part of the AAD computation.
<= br>
I see, so you're saying that NSS adds 8 bytes to the AAD = input, and then strips it off at some later point?

No. I'm saying that the function argument is= called |additionalData| but that's not what's used as AAD in the a= ctual cryptographic function.


I wouldn't exactly call that misreading.

This seems like a definitional question = that is not worth debating.

Hey now, you're the one that wrote "misreading" initially.= If "additional data" is not what's used as "additional = authenticated data" in the end, fine.

=C2=A0<= /div>

Maybe somet= hing to fix?

This is not = on topic for this mailing list.=C2=A0
I think it is, since no one could read any ESNI draft and get = the DNS record's checksum right, at the very least. So, there are some = issues where it can be hard to tell if the spec is wrong, my implementation= is wrong, or another implementation is wrong.

tha= nks,
Rob

--00000000000034128f059650d837-- From nobody Fri Nov 1 16:04:16 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4FF120A55 for ; Fri, 1 Nov 2019 16:04:13 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 zzAT0JVfVHPq for ; Fri, 1 Nov 2019 16:04:11 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 323B3120ACE for ; Fri, 1 Nov 2019 16:04:11 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id j14so8306763lfb.8 for ; Fri, 01 Nov 2019 16:04:11 -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=9JvmCylMOcXUW1nSYd6NcPbOAo5FsszsY1MdWHt+QqM=; b=A2CXf4fL+Gwc88c9aCa5+JOtQsIhDbcZkiVDvnbgBn/LoI1peQkM6CTsot5cg+GmrT n7z9+5USrWGn/s/I6SNPheHr/hG1C8o+9IKw0h9m9rvHjsuwolVVMVllGdb1iuIJJKWj cXphYTkOzBIqiNaQrnbmmeCcHoOrOJ0+9Ng0UXQgQJY5auOw9O+VNQ/Sa/ancunxLp56 c/uDy0c9RhXdG5ptEvPrs/UHpi1cfoISO1cTPEcCAcwmsn5nIUHNrJxocsgsJ4xALplF zxgcF8Nwc7nrBc90E8UNE0Zdf/zl+P5Bhrsud+nKgVjOinABBqn7bghc3+i0XQw7jtgm 95UA== 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=9JvmCylMOcXUW1nSYd6NcPbOAo5FsszsY1MdWHt+QqM=; b=AuBYR3F41tLw1edDIXBfFUbiR0DNrR52b+5O4C+H3ojxvS4EwEXbtloh39WNVYOMa1 F/hybtPMmMbOG5UsbSnjzKNDgjtaJOhCHnJLBjlGH2VMnHWNeIShqAudARJDk5ZZkwEC pktFkKKnCEGRKJ4HzOu0gsMtxONamzYjbSLxosOqHtIuLZSE1JrbCVbxtsWk6pIM+TI8 VwVxrbLDfFt2YYL6I1rh93bWu5iZLtxr58fw2cal3Sgn5NIWTZbNtL13sC+dts3MeFM9 eYD6AeFf0EyLaqLGrLbuL7+dqh3ktLbJi0faRIQtKFkPj8QxPoeCdDp0X87Qnr+fLoPs xbqQ== X-Gm-Message-State: APjAAAUiyPoM362d1SyAMf7FXkXSYc+pXEkUePCzwxcu6wFz9WGy/L50 CoWi8Z+gmRwt0JMNOxeMxDjxGmbo9LI7jKlYHoDtSg== X-Google-Smtp-Source: APXvYqyJ8p89draNbZ0UAesXhubv9oaHsNlWgwGa8SCXZs9ee9chtSQ5xBMAcHnH6YLK6SsA1R9EFve6AN8DcWACWVo= X-Received: by 2002:a05:6512:75:: with SMTP id i21mr8528700lfo.180.1572649449328; Fri, 01 Nov 2019 16:04:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Fri, 1 Nov 2019 16:03:32 -0700 Message-ID: To: Rob Sayre Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c8b590059650fbb4" Archived-At: Subject: Re: [TLS] predictability of inputs in ESNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 23:04:15 -0000 --000000000000c8b590059650fbb4 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 1, 2019 at 3:54 PM Rob Sayre wrote: > > > On Fri, Nov 1, 2019 at 3:39 PM Eric Rescorla wrote: > >> >>>> >>> I see. But is there any reason to make these inputs predictably zero by >>> spec? >>> >> >> Absent some reason not to, this seems like a reasonable design choice. At >> minimum, it has the advantage that it's easy to detect some classes of >> implementation errors. >> > > I don't think the current spec is a good idea. It mandates padding with > zeros, and lets servers dictate a length. I think the client should dictate > the length, at least. > This is a separate issue from the structure of the padding. >> I wouldn't exactly call that misreading. >>> >> >> This seems like a definitional question that is not worth debating. >> > > Hey now, you're the one that wrote "misreading" initially. If "additional > data" is not what's used as "additional authenticated data" in the end, > fine. > NSS does not include the leading 0s as part of the computation of the AAD that appears on the wire. To the extent to which you may have believed otherwise based on your reading of the code, that is not a correct understanding. -Ekr --000000000000c8b590059650fbb4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Nov 1, 2019 at 3:54 PM Rob Sa= yre <sayrer@gmail.= com> wrote:


On Fri, Nov 1, 2019 at 3:39 PM Eri= c Rescorla <ekr@rtfm.c= om> wrote:


I see.= But is there any reason to make these inputs predictably zero by spec?

Absent some reason not to, t= his seems like a reasonable design choice. At minimum, it has the advantage= that it's easy to detect some classes of implementation errors.

I don't think the curre= nt spec is a good idea. It mandates padding with zeros, and lets servers di= ctate a length. I think the client should dictate the length, at least.

This is a separate issue fro= m the structure of the padding.
=C2=A0


I woul= dn't exactly call that misreading.
<= br>
This seems like a definitional question that is not worth deb= ating.

Hey now, you'r= e the one that wrote "misreading" initially. If "additional = data" is not what's used as "additional authenticated data&qu= ot; in the end, fine.

=C2=A0NSS does not include t= he leading 0s as part of the computation of the AAD that appears on the wir= e. To the extent to which you may have believed otherwise based on your rea= ding of the code, that is not a correct understanding.

-Ekr

--000000000000c8b590059650fbb4-- From nobody Fri Nov 1 16:18:57 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C543A1208A5 for ; Fri, 1 Nov 2019 16:18:55 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 t7siTwkxDHTy for ; Fri, 1 Nov 2019 16:18:54 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 E77FA12082D for ; Fri, 1 Nov 2019 16:18:51 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id b12so9978855ilf.12 for ; Fri, 01 Nov 2019 16:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PSnSyZK6cYzcUwT/K+bqiXUNR7vTNvjBshFDOaONtTk=; b=Nabckga8HC12R497nE1C26hC46JwBUrEJJbSum5jq6SFHzVOeZt1RSjvK8f8HgevKR J9enkigS879N5vNmlvKe34gCeGpt+bL/Gf4cGOUGMcDXvB78y4nb310dCIhxPZVyotHl YqJiJ4xrz845TJ2EmvALpYCzcqzx6Db+PQgFPLobs3j9icbS//rxCKmQNHfEbDRZxMwm d66iYMh1MLUUBFbCu4wxVIcbYCwJR9Y8Iu167ginWGQNW1GjvFQ9NcVJsjh2ILK8xG53 /FtOn1I9RRV2m1E58m5eJoXeklv20A5+riaj8wZAjepjfbCfcjQi+tQ/DjR1Mr1GE1pC U3DA== 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=PSnSyZK6cYzcUwT/K+bqiXUNR7vTNvjBshFDOaONtTk=; b=GLieHT7/vnOsJThN/swVOOU2DJitoW6+mApVgcSk93NWm3F7lGuvwPwww219JCDhAv zQCXUY9FRdhVusvKF4b1fUp3BPQ0FN2TkI6mKkvSI1IsgaIW49sA+pfXDrXojZycDJPy M4JISLS0EJ+ub/Kbr1UNN4V4x0JwjAN4JWnyF82d1gW40FyKFwYmBwiFg47+/iEzbgqj hIVVYIYvybgNdXkw4JaCGaEP0QVVY+vsHFLXY8VLUqwhVXgiAoN+QVwFicd751XiT7Ex cgdAfSxn4d4k2jLEtKtFQd8MY0Z6LkIyCzcLwGVv5o9P3S5GivrOHLDcgRb5Sm4yxuUY ATOQ== X-Gm-Message-State: APjAAAX+ts01b9O9/ZfEOGfsPTsZoR+7p+e1k6+yWNwr435EBTQe1XmG c/aL7b/MbAfA0rzGRAm4OEo5BH7AO9AbE3IMLU0= X-Google-Smtp-Source: APXvYqx3e+gIA0S+WjVMH2I0qzAZHubOxFb2WGSbf/HTrMpJZX9uLo6IaWvshtXXbfcNGVU8x09Mv7eGlxCyEVX8M5k= X-Received: by 2002:a92:8394:: with SMTP id p20mr15693201ilk.73.1572650331078; Fri, 01 Nov 2019 16:18:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Fri, 1 Nov 2019 16:18:39 -0700 Message-ID: To: Eric Rescorla Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005706cb05965130a3" Archived-At: Subject: Re: [TLS] predictability of inputs in ESNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 23:18:56 -0000 --0000000000005706cb05965130a3 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 1, 2019 at 4:04 PM Eric Rescorla wrote: > > > On Fri, Nov 1, 2019 at 3:54 PM Rob Sayre wrote: > >> >> >> On Fri, Nov 1, 2019 at 3:39 PM Eric Rescorla wrote: >> >>> >>>>> >>>> I see. But is there any reason to make these inputs predictably zero by >>>> spec? >>>> >>> >>> Absent some reason not to, this seems like a reasonable design choice. >>> At minimum, it has the advantage that it's easy to detect some classes of >>> implementation errors. >>> >> >> I don't think the current spec is a good idea. It mandates padding with >> zeros, and lets servers dictate a length. I think the client should dictate >> the length, at least. >> > > This is a separate issue from the structure of the padding. > I think the length of the padding might be fairly considered part of the "structure of the padding". > > > >>> I wouldn't exactly call that misreading. >>>> >>> >>> This seems like a definitional question that is not worth debating. >>> >> >> Hey now, you're the one that wrote "misreading" initially. If "additional >> data" is not what's used as "additional authenticated data" in the end, >> fine. >> > > NSS does not include the leading 0s as part of the computation of the AAD > that appears on the wire. To the extent to which you may have believed > otherwise based on your reading of the code, that is not a correct > understanding. > I see, so I should chase down every last obfuscated padding byte? I can't actually read a draft to implement this spec. I also do not think this issue should have been unilaterally closed: https://github.com/tlswg/draft-ietf-tls-esni/issues/190 Maybe it's time for some new TLS editors. thanks, Rob --0000000000005706cb05965130a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Nov 1, 2019 at 4:04 PM Eric R= escorla <ekr@rtfm.com> wrote:
=


On Fri, Nov 1, 2019 at 3:54 PM Rob Sayre <sayrer@gmail.com> wrote:<= br>


On Fri, Nov 1, 2019 at 3:39 PM Eric Rescorla <ekr@rtfm.com> wrote:
=

<= /div>

I see. But is there any r= eason to make these inputs predictably zero by spec?

Absent some reason not to, this seems like a re= asonable design choice. At minimum, it has the advantage that it's easy= to detect some classes of implementation errors.

I don't think the current spec is a good i= dea. It mandates padding with zeros, and lets servers dictate a length. I t= hink the client should dictate the length, at least.

This is a separate issue from the structure of = the padding.

I think the = length of the padding might be fairly considered part of the "structur= e of the padding".

=C2=A0
=C2=A0=C2=A0


I wouldn't exactly call that misreadi= ng.

This seems like a def= initional question that is not worth debating.

Hey now, you're the one that wrote "misreadi= ng" initially. If "additional data" is not what's used a= s "additional authenticated data" in the end, fine.

=C2=A0NSS does not include the leading 0s as part of the comput= ation of the AAD that appears on the wire. To the extent to which you may h= ave believed otherwise based on your reading of the code, that is not a cor= rect understanding.

I see, so I= should chase down every last obfuscated padding byte? I can't actually= read a draft to implement this spec.

I also do no= t think this issue should have been unilaterally closed:

Mayb= e it's time for some new TLS editors.

thanks,<= /div>
Rob
=C2=A0
--0000000000005706cb05965130a3-- From nobody Fri Nov 1 16:30:25 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D3F120964 for ; Fri, 1 Nov 2019 16:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=tn2mdnEk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=A9aJuhi7 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 sP6H49i_HC5O for ; Fri, 1 Nov 2019 16:30:22 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9895A1208CB for ; Fri, 1 Nov 2019 16:29:34 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9D5E8218BB for ; Fri, 1 Nov 2019 19:29:33 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Fri, 01 Nov 2019 19:29:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=Xiq6wOOUWBnLjFEfKHV0d7FPQklq9K8 vaZtGRuLbPg0=; b=tn2mdnEkpKxkJjcCFM7HVtvDYzOJ/8Z8aNS8tvMFkLTee/w LN4gEq8IPMBfhwJL+SoSDkCZy51ZDq7/Nh0uOVhiEKIfP+2+XySqWTHUA9AHEz8K MFkmMFpsPBoE5iQBKPQy8Dm3yXfrgmo5cqCiWYTpEpGZz/+O0uui+tVj7Sg2vv0+ 4OZJ+guvvuFpar1bRj/KnQ10Qb1Vl/SHgreOCxrqkLn2Gv09qkM/GfpYithCfMeJ TDp9+SfrJt5NzPuS/9wnEXrWfzxhRagKBhwAH0wwQMMUvyKYrMW9B198DnGbMaCK CCWtKGD1tdX+kkyLmmErytdm2v/MMpqhrlYw+Gg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Xiq6wO OUWBnLjFEfKHV0d7FPQklq9K8vaZtGRuLbPg0=; b=A9aJuhi7E9VUq4AgmrYDOw iG/iTbeaVjivx8G4Se2ODRrYJAECkQtMNbtypl5NmQ/L6wnBvN9LO2w/X5ZcfpIU MYfPHfLoCLvPgcYzm3hgrAicZCUCaRtK3RSl4Udt1ifXizcOWOVMA9Y+3XEXVpq2 XeOVrAJfPz7s6qbPbMYgjaPUbgOOy+CjnbccIh4PyBJK+vp928d5f+oLgQKHhAmC zu9l+YGIQq1IiHQ0zenTTZ1mjUM2FWuY1txGPe3xY3h8K0JVKR9k91pQdjgXpAS/ it1cShWotj/I77+CAs261w58icUnkL5YcGE79KGJSC/8iwANoGPW+0cJPELSXn+w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtkedgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtoh hmpdhgihhthhhusgdrrdgtohhmnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehh vggrphhinhhgsghithhsrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 43A533C00A1; Fri, 1 Nov 2019 19:29:33 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: <7dd19458-b96a-4ffe-abe5-5731ed956c0a@www.fastmail.com> In-Reply-To: References: Date: Fri, 01 Nov 2019 16:29:11 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] predictability of inputs in ESNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2019 23:30:24 -0000 On Fri, Nov 1, 2019, at 4:18 PM, Rob Sayre wrote: > I also do not think this issue should have been unilaterally closed: > https://github..com/tlswg/draft-ietf-tls-esni/issues/190 > > > Maybe it's time for some new TLS editors. As the issue was filed based on a misunderstanding of the NSS implementation, closing this issue was appropriate. Best, Chris (chair hat on) From nobody Sat Nov 2 17:45:21 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552B312002F for ; Sat, 2 Nov 2019 17:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=u2/k1Mzk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LKyMJ7IB 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 D2nsmWVhvG0b for ; Sat, 2 Nov 2019 17:45:14 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEFA7120020 for ; Sat, 2 Nov 2019 17:45:14 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id BFA1F3E1 for ; Sat, 2 Nov 2019 20:45:13 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 02 Nov 2019 20:45:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=h3xOl6QqSPSW3GgJPLCa4JrEe9bY2/uuuT+A8mktbnk=; b=u2/k1Mzk O5y+TADyTMB+GISzg+JxUQcjL+7KD7peb0M8fzRIi5mV1wL6vgeHB/BiKnqiQVwb ewdf2A6NZ9ojl3kAycQKykfLjhF4IEs43uYGPyuood2nvk5OAtN+TFBzt47wxgkx 5OiRkeVHBW307W0iYFA15t5cNM+plLstd/xp7D33McOq1yIQmfjZEAmrwCE4nluP eRjnc4A1WQZPqEPr+ZmhdwY0s2FpNdNlbLpKZhkRw2L+rT4EM1X0P9jY5kGxYYJH hMuLhs5TNqi+9nSJs6e/ee/yGKUd4SPIb4xVpMVKfHcIGB+9PNIJlSu0PTO8omPS AmgkhOFZNZ+FLQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=h3xOl6QqSPSW3GgJPLCa4JrEe9bY2 /uuuT+A8mktbnk=; b=LKyMJ7IB6sHy7epz8w+EcZb2XVNbW7saJSmCcFk/uwHSL /5UsCb2yl7wmQfGpilinYBWTfLcalb/9THrPaN9q0ztoQPziTY9PyGTG5a+8KC/H SDHVIQyQLrJPn77+FsCAIsOoEMhBVC23vN3+7l/3iLQco+kZu6n5L2P0vVuUJ9YJ TaH5RBvD3viu8joPzXwPeVJfIhpw7Buy6aUOj4uArACiXl8ISaweS8ttrvTagd3Z l8UeTrJ7C2Fg5qHRYjakxM2vqxdkefBIsEeTpiDTbIReV6wsLmZi4TMytk/OpAal NY2NB9f1opvUeHxlSRPIQzDpvyIkXEPV2Pfk1fL5w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddtledgudekjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomhepifhithhhuhgsucfpohhtihhfihgtrghtihhonhhsuceoughopghnohht pghrvghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomh enucfkphepgeehrdejledruddufedrudeiheenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpe dt X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [45.79.113.165]) by mail.messagingengine.com (Postfix) with ESMTPA id 40880306005C for ; Sat, 2 Nov 2019 20:45:12 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 6C57B9E715 for ; Sun, 3 Nov 2019 00:45:11 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============9155814124332975415==" MIME-Version: 1.0 From: Github Notifications To: tls@ietf.org Message-Id: <20191103004511.6C57B9E715@cloud.mnot.net> Date: Sun, 3 Nov 2019 00:45:11 +0000 (UTC) Archived-At: Subject: [TLS] Weekly github digest (TLS Working Group Drafts) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2019 00:45:18 -0000 --===============9155814124332975415== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * tlswg/draft-ietf-tls-esni (+4/-4/=F0=9F=92=AC11) 4 issues created: - Reasoning for 260 (by sayrer) https://github.com/tlswg/draft-ietf-tls-esni/issues/193=20 - How to parse esni_retry_request generically? (by ocheron) https://github.com/tlswg/draft-ietf-tls-esni/issues/192=20 - Why is the PaddedSNI padded with zeros? (by sayrer) https://github.com/tlswg/draft-ietf-tls-esni/issues/191=20 - AAD calculation could use more explanation (by sayrer) https://github.com/tlswg/draft-ietf-tls-esni/issues/190=20 5 issues received 11 new comments: - #190 AAD calculation could use more explanation (6 by ekr, sayrer) https://github.com/tlswg/draft-ietf-tls-esni/issues/190=20 - #189 AEAD-Encrypt definition (2 by nharper, sayrer) https://github.com/tlswg/draft-ietf-tls-esni/issues/189=20 - #180 Use SRV for fronting server selection (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/issues/180=20 - #179 Decouple ESNIKeys and the envelope DNS record (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/issues/179=20 - #110 ESNIInclude (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/issues/110 [needs WG discu= ssion]=20 4 issues closed: - ESNIInclude https://github.com/tlswg/draft-ietf-tls-esni/issues/110 [ne= eds WG discussion]=20 - Decouple ESNIKeys and the envelope DNS record https://github.com/tlswg/= draft-ietf-tls-esni/issues/179=20 - Use SRV for fronting server selection https://github.com/tlswg/draft-ie= tf-tls-esni/issues/180=20 - AAD calculation could use more explanation https://github.com/tlswg/dra= ft-ietf-tls-esni/issues/190=20 * tlswg/tls-subcerts (+0/-2/=F0=9F=92=AC1) 1 issues received 1 new comments: - #33 Consider changing name from "Delegated Credentials" to "Delegated A= uthentication Keys" (1 by siyengar) https://github.com/tlswg/tls-subcerts/issues/33=20 2 issues closed: - ASN.1 Module https://github.com/tlswg/tls-subcerts/issues/37=20 - Consider changing name from "Delegated Credentials" to "Delegated Authe= ntication Keys" https://github.com/tlswg/tls-subcerts/issues/33=20 Pull requests ------------- * tlswg/draft-ietf-tls-esni (+0/-1/=F0=9F=92=AC0) 1 pull requests merged: - Replace ESNIKeys with ESNIConfig, and delegate the publishing container= to HTTPSVC. https://github.com/tlswg/draft-ietf-tls-esni/pull/187=20 * tlswg/draft-ietf-tls-external-psk-importer (+0/-0/=F0=9F=92=AC4) 1 pull requests received 4 new comments: - #22 Addressing selfie attacks (4 by chris-wood, ms-s) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/22=20 * tlswg/tls-subcerts (+1/-1/=F0=9F=92=AC1) 1 pull requests submitted: - Add text for PKCS 1.5 (by siyengar) https://github.com/tlswg/tls-subcerts/pull/39=20 1 pull requests received 1 new comments: - #38 Asn1 module (1 by siyengar) https://github.com/tlswg/tls-subcerts/pull/38=20 1 pull requests merged: - Asn1 module https://github.com/tlswg/tls-subcerts/pull/38=20 * tlswg/sniencryption (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - Edits per Warren Kumari's comments. (by huitema) https://github.com/tlswg/sniencryption/pull/48=20 1 pull requests merged: - Edits per Warren Kumari's comments. https://github.com/tlswg/sniencryption/pull/48=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/tls-flags * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/sniencryption * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/draft-ietf-tls-grease --===============9155814124332975415== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday November 03, 2019

Issues

tlswg/draft-ietf-tls-esni (+4/-4/=F0=9F=92=AC11)

4 issues created:

5 issues received 11 new comments:

4 issues closed:

tlswg/tls-subcerts (+0/-2/=F0=9F=92=AC1)

1 issues received 1 new comments:

2 issues closed:

Pull requests

tlswg/draft-ietf-tls-esni (+0/-1/=F0=9F=92=AC0)

1 pull requests merged:

tlswg/draft-ietf-tls-external-psk-importer (+0/-0/=F0=9F=92=AC4)

1 pull requests received 4 new comments:

tlswg/tls-subcerts (+1/-1/=F0=9F=92=AC1)

1 pull requests submitted:

1 pull requests received 1 new comments:

1 pull requests merged:

tlswg/sniencryption (+1/-1/=F0=9F=92=AC0)

1 pull requests submitted:

1 pull requests merged:

Repositories tracked by this digest:

--===============9155814124332975415==-- From nobody Sun Nov 3 18:50:18 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA55120981 for ; Sun, 3 Nov 2019 18:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 rZC0-TzbviWs for ; Sun, 3 Nov 2019 18:49:55 -0800 (PST) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 59B15120958 for ; Sun, 3 Nov 2019 18:49:54 -0800 (PST) Received: by mail-wm1-x332.google.com with SMTP id q70so14971013wme.1 for ; Sun, 03 Nov 2019 18:49:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2IC6GMmbJ7k7u88sWMlQMEKdPS9L3CmYKPj8Fwm3JyU=; b=NIgmuS6rzbh8f6geYJ2YkUnDVCtXFpzp6XdL++0ulJ/Maz48fFmu3UZ1V+RPOE7MPX HyKcXmAwHuWYyJe58oeXIjg2jd5FTU2e3KTFb1Zkf7cxO0+lxeOknGOI8tpt1U8DQaKy INSN6z9f0tvmxRMBKHsMPFj1ZNv20zNqyE7rY= 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=2IC6GMmbJ7k7u88sWMlQMEKdPS9L3CmYKPj8Fwm3JyU=; b=Lpf7gXnMlWooqocc1LgvJKD6592oNM2TOULWAby0chINPDfHSjnI0xO5YZRsgMk4Y7 gw033qY9WucYt6+rjd4wohgdn5Srx17N6CnsmxUAl/Mr0lH9DE3z3qoVgGuBDQ7NclMM TPyE6DracvDISF51Tvvpwl774VFH+IbM+8qZAfMQHhlh5kECyHaH8ZqNC+xIl6sBTa9J eFC1NyNAT8IJk3tS968JLMkFBh/MGO28TzONvwJHodFjP1pHEw68wo1XDUKS2Wmc1CnD nRIkL38uN9td4mKJqyVwaIjJkeLVOXwWla+PSTTL0uTr1ZGqdgFYTG0eCCMtoLjcfOEo LUdg== X-Gm-Message-State: APjAAAU09thL1Tx52tTxk/dxoGuyra/a+29a213UzlNb4/bml/pkoeo6 l9yPrW2Sd7BBLz5IDOWAyf0zJPp5BP632N67sEhkHQ== X-Google-Smtp-Source: APXvYqxfPNR2fEA1ymACxfVJMn+s1by5Rms2jMrkYM9/QqrZSCuxkvqAj56tHZ1nUWIA2zFVz1ZnNJhwXg+9ZpGNhGI= X-Received: by 2002:a1c:6a1a:: with SMTP id f26mr14004188wmc.19.1572835792591; Sun, 03 Nov 2019 18:49:52 -0800 (PST) MIME-Version: 1.0 References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> In-Reply-To: From: Nick Sullivan Date: Sun, 3 Nov 2019 18:49:36 -0800 Message-ID: To: Yaron Sheffer Cc: secdir@ietf.org, draft-ietf-tls-exported-authenticator.all@ietf.org, ietf@ietf.org, "" Content-Type: multipart/alternative; boundary="000000000000b54e4905967c5ec3" Archived-At: Subject: Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 02:50:04 -0000 --000000000000b54e4905967c5ec3 Content-Type: text/plain; charset="UTF-8" Following up, Yaron, do the responses by myself and Benjamin along with the does the following PR sufficiently address your comments/concerns? https://github.com/tlswg/tls-exported-authenticator/pull/52 On Wed, Sep 18, 2019 at 4:55 PM Nick Sullivan wrote: > Hi Yaron, > > Thank you for your thorough review. My answers will be inline, and I'll > incorporate some of Ben's replies if necessary. Here's a PR with proposed > changes in response to your comments: > https://github.com/tlswg/tls-exported-authenticator/pull/52 > > On Tue, Jul 16, 2019 at 12:59 PM Yaron Sheffer via Datatracker < > noreply@ietf.org> wrote: > >> Reviewer: Yaron Sheffer >> Review result: Has Issues >> >> The document is generally clear in both its motivation and the proposed >> solution. >> >> I think it's playing a bit too liberal with TLS 1.3, in sort-of but not >> quite >> deprecating renegotiation, and in changing the IANA registry in a way that >> actually changes the protocol. Details below. >> >> Other comments: >> >> * Abstract: please reword to make it clear that it's the proof (not the >> cert) >> that is portable. > > > Proposed text here: > This document describes a mechanism in Transport Layer Security (TLS) for > peers to > provide a proof of ownership of a certificate. This proof can be exported > by one peer, transmitted out-of-band to the other peer, and verified by > the receiving peer. > > * Introduction: TLS 1.3 post-handshake auth "has the >> disadvantage of requiring additional state to be stored as part of the TLS >> state machine." Why is that an issue is practice, assuming this feature is >> already supported by TLS libraries? Also, are we in effect deprecating >> this TLS >> 1.3 feature because of the security issue of the mismatched record >> boundaries? >> > > My understanding is that post-handshake authentication as defined in the > TLS 1.3 RFC is not implemented in many (any?) TLS 1.3 libraries and some > implementors would prefer to use exported authenticators. > > * "For simplicity, the mechanisms... require", maybe a normative REQUIRE? > > I'm fine with this. > > >> * Authenticator Request: please clarify that we use the TLS 1.3 format >> even when >> running on TLS 1.2. > > Updated, though it might be a bit unnecessary. > > * Also, I suggest to change "is not encrypted with a >> handshake key" which is too specific to "is sent unencrypted within the >> normal >> TLS-protected data". > > This specific text is meant to differentiate the wire format of this > message from that of the CertificateRequest message, which is encrypted > with the handshake key. The specificity is warranted. > > * Before diving into the detailed messages in Sec. 3, it >> would be nice to include a quick overview of the message sequence. > > There are two message types and three potential sequences. I've added a > short overview. > > >> * Sec. 3: >> "SHOULD use TLS", change to MUST. There's no way it can work otherwise >> anyway. >> > As Ben noted, this could be any secure channel with equivalent security to > TLS, such as QUIC. We shouldn't forbid other secure out-of-band mechanisms. > > >> * "This message reuses the structure to the CertificateRequest message" - >> repeats the preceding paragraph. > > Fixed > > >> * Sec. 4: again, SHOULD use TLS -> MUST. > > Again, I don't see the need for a MUST here. > > >> * Is >> there a requirement for all protocol messages to be sent over a single TLS >> connection? If so, please mention it. Certainly this is true for the >> Authenticator message that must be sent over a single connection and >> cannot be >> multiplexed by the high-level protocol. I think this protocol actually >> assumes >> "nice" transport properties (no message reorder, reliability) that also >> require >> a single, clean TLS connection. > > There is no such requirement. Message ordering is managed by the > application layer protocol that utilizes exported authenticators. > > >> * Why no authenticator request for servers? >> Don't we care about replay? OTOH if the client wants to detect replays, it >> would need to keep state on received authenticators, which would be very >> messy. >> > I'm not sure I understand. It's possible to use authenticator requests for > servers. > > * 4.1: when referencing Exporters, mention this is Sec. 7.5 of [TLS1.3]. > > Added "Sec. 7.5" > > * The >> discussion of Extended Master Secret only applies to TLS 1.2 - please >> clarify >> that, plus I suggest to reword this paragraph which I find hard to parse. > > re-worded > > * >> 4.2: "the extensions are chosen from the TLS handshake." - What does it >> mean >> exactly, and how does an application even know which extensions were used >> at >> the TLS layer? Reading further, we mention "ClientHello extensions." >> Maybe the >> authenticator should also include a ClientHello message to indicate >> supported >> extensions. Assuming we can peek into ClientHello contradicts the hopeful >> "even >> if it is possible to implement it at the application layer" in Sec. 6. > > > This could be clearer. Effectively, the Certificate message in the > Authenticator needs > to be constructed in a similar manner to how a Certificate message would > be created > in a TLS handshake. Namely, it can only contain extensions that were > present in either > the client hello or a preceding CertificateRequest. > > You're right that this makes an assumption that the party creating the > Authenticator > has access to the TLS handshake state. This implies that even if the > Authenticator > is created in the application space, an additional API needs to be exposed > to share > that information. > > * 4.2.1: >> the first sentence of the section is incomplete. > > > Fixed > > >> * Can I use TLS 1.3-specific >> extensions (oid_filters) if I'm running on a TLS 1.2 connection? Is there >> a >> situation where a certificate is acceptable for TLS 1.3 connections but >> not for >> TLS 1.2 connections? > > Yes TLS 1.3-specific extensions are allowed, the CertificateRequest > message is TLS 1.3-compatible. > > >> * "using a value derived from the connection secrets" - I >> think we should recommend a specific construction here to ensure people >> do it >> securely. > > This was a suggestion from the Additional Certificates use case ( > https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-05). > I'm not sure we should get into the details here. > > >> * 4.2.3: Are we computing HMAC(MAC-key, Hash(a || b || c || d))? If >> so, please say so. > > Yes, I'll put that in. > > * 4.2.4: "a constant-time comparison" - why is it actually >> required, what is the threat? An attacker can do very little because each >> authenticator being sent is different. > > As Ben noted, this was a safety note added during review. > > >> * 5: please say explicitly which >> messages are used in this case to construct the authenticator. > > > Re-written. > >> * 6.1: the >> "MUST" is strange in a section that's only supposed to be informative. >> Also, >> the library may provide this extension (and possibly others) without >> requiring >> it as input. > > How else do you propose wording the requirement that this API fail if the > connection doesn't support EAs? > > >> * 6.4: "The API MUST return a failure if the >> certificate_request_context of the authenticator was used in a previously >> validated authenticator." Are we requiring the library to keep previous >> contexts for replay protection? If so, please make it explicit. > > I think this can be a SHOULD based on the burden replay protection places > on the implementation. > > >> * 7.1: this is >> changing TLS 1.3 by allowing this extension in Cert Request! I think it's >> a >> really bad idea. Better to hack special support to existing libraries, >> allowing >> this specific extension for this special case, than to change the base >> protocol. Otherwise, this document should UPDATE 8446. > > > This is a good point and one that we struggled a bit with during design. > We needed to allow SNI in the CertificateRequest message because it can be > client-generated in this context. I'd be ok with creating a different > extension for this, but it's rather elegant to re-use it in this context. *I'd > like to hear some opinions from the working group* on this point > > >> * 8: I think the >> Security Considerations is the right place to talk about interaction >> between >> this protocol and TLS 1.3 (or 1.2) renegotiation. Even if we simply >> RECOMMEND >> not to do it. Or else explain the use cases where renegotiation is still >> useful >> if there are any. >> > > I'm not sure this document should be prescriptive about use cases. This > doc is providing a new capability that may be leveraged at the application > to replace the functionality of existing mechanisms, but I'm not convinced > the evaluation of the trade-offs of different mechanisms should be > contained in this document. > --000000000000b54e4905967c5ec3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Following up,

Yaron, do the responses b= y myself and Benjamin along with the=C2=A0does the following PR sufficientl= y address your comments/concerns?


On Wed, Sep 18= , 2019 at 4:55 PM Nick Sullivan <= nick@cloudflare.com> wrote:
Hi=C2=A0Yaron,

Thank= you for your thorough review. My answers will be inline, and I'll inco= rporate=C2=A0some of Ben's replies if necessary. Here's a PR with p= roposed changes in response to your comments:
<= br>
O= n Tue, Jul 16, 2019 at 12:59 PM Yaron Sheffer via Datatracker <noreply@ietf.org> wro= te:
Reviewer: Ya= ron Sheffer
Review result: Has Issues

The document is generally clear in both its motivation and the proposed
solution.

I think it's playing a bit too liberal with TLS 1.3, in sort-of but not= quite
deprecating renegotiation, and in changing the IANA registry in a way that<= br> actually changes the protocol. Details below.

Other comments:

* Abstract: please reword to make it clear that it's the proof (not the= cert)
that is portable.

Proposed text here:
=
This document describes a mechanism in Transport Layer Security (TLS) = for peers to
provide a proof of ownership of a certificate.=C2=A0 This p= roof can be exported
by one peer, transmitted out-of-band to the other p= eer, and verified by the receiving peer.

* Introduction: TLS 1.3 post-handsh= ake auth "has the
disadvantage of requiring additional state to be stored as part of the TLS<= br> state machine." Why is that an issue is practice, assuming this featur= e is
already supported by TLS libraries? Also, are we in effect deprecating this= TLS
1.3 feature because of the security issue of the mismatched record boundari= es?

My understanding is that post-hands= hake authentication=C2=A0as defined in the TLS 1.3 RFC is not implemented = in many (any?) TLS 1.3 libraries and some implementors=C2=A0would prefer to= use exported authenticators.

* "For simplicity, the mechanisms... require", maybe a normative = REQUIRE?
I'm fine with this.
=C2=A0
* Authenticator Request: ple= ase clarify that we use the TLS 1.3 format even when
running on TLS 1.2.
=C2=A0Updated, though it might be a bi= t unnecessary.

* Also, I suggest to change "is not encrypted with a
handshake key" which is too specific to "is sent unencrypted with= in the normal
TLS-protected data".
This specific text is meant to d= ifferentiate the wire format of this message from that of the CertificateRe= quest message, which is encrypted with the handshake key. The specificity i= s warranted.

* Before diving into the detailed messages in Sec. 3, it
would be nice to include a quick overview of the message sequence.
There are two message types and three potential sequences. I'v= e added a short overview.
=C2=A0
* Sec. 3:
"SHOULD use TLS", change to MUST. There's no way it can work = otherwise anyway.
As Ben noted, this could be any secu= re channel with equivalent security to TLS, such as QUIC. We shouldn't = forbid other secure out-of-band mechanisms.
=C2=A0
* "This message reuses the structure to the CertificateRequest message= " -
repeats the preceding paragraph.
Fixed
=C2=A0
* Sec. 4: again, SHOUL= D use TLS -> MUST.
Again, I don't see the need for = a MUST here.
=C2=A0
* Is
there a requirement for all protocol messages to be sent over a single TLS<= br> connection? If so, please mention it. Certainly this is true for the
Authenticator message that must be sent over a single connection and cannot= be
multiplexed by the high-level protocol. I think this protocol actually assu= mes
"nice" transport properties (no message reorder, reliability) tha= t also require
a single, clean TLS connection.
There is no such requireme= nt. Message ordering is managed by the application layer protocol that util= izes exported authenticators.
=C2=A0
* Why no authenticator request for servers?
Don't we care about replay? OTOH if the client wants to detect replays,= it
would need to keep state on received authenticators, which would be very me= ssy.
I'm not sure I understand. It's possib= le to use authenticator requests for servers.

* 4.1: when referencing Exporters,= mention this is Sec. 7.5 of [TLS1.3].
Added=C2=A0 "S= ec. 7.5"

* The
discussion of Extended Master Secret only applies to TLS 1.2 - please clari= fy
that, plus I suggest to reword this paragraph which I find hard to parse.
re-worded

*
4.2: "the extensions are chosen from the TLS handshake." - What d= oes it mean
exactly, and how does an application even know which extensions were used a= t
the TLS layer? Reading further, we mention "ClientHello extensions.&qu= ot; Maybe the
authenticator should also include a ClientHello message to indicate support= ed
extensions. Assuming we can peek into ClientHello contradicts the hopeful &= quot;even
if it is possible to implement it at the application layer" in Sec. 6.=

This could be clearer. Effectively, the Ce= rtificate message in the Authenticator needs
to be constructed in= a similar manner to how a Certificate message would be created
i= n a TLS handshake. Namely, it can only contain extensions that were present= in either
the client hello or a preceding=C2=A0CertificateReques= t.

You're right that this makes an assumption = that the party creating the Authenticator
has access to the TLS h= andshake state. This implies that even if the Authenticator
is cr= eated in the application space, an additional API needs to be exposed to sh= are
that information.

* 4.2.1:
the first sentence of the section is incomplete.

Fixed
=C2=A0
* Can I use TLS 1.3-specific
extensions (oid_filters) if I'm running on a TLS 1.2 connection? Is the= re a
situation where a certificate is acceptable for TLS 1.3 connections but not= for
TLS 1.2 connections?
Yes TLS 1.3-specific extensions are a= llowed, the CertificateRequest message is TLS 1.3-compatible.
=C2= =A0
* "using a = value derived from the connection secrets" - I
think we should recommend a specific construction here to ensure people do = it
securely.
This was a suggestion from the Additional Certif= icates use case (https://tools.ietf.org/html/= draft-bishop-httpbis-http2-additional-certs-05). I'm not sure we sh= ould get into the details here.
=C2=A0
* 4.2.3: Are we computing HMAC(MAC-key, Hash(a= || b || c || d))? If
so, please say so.
Yes, I'll put that in.
* 4.2.4: "a = constant-time comparison" - why is it actually
required, what is the threat? An attacker can do very little because each authenticator being sent is different.
As Ben noted, this = was a safety note added during review.
=C2=A0
* 5: please say explicitly which
messages are used in this case to construct the authenticator.
=

Re-written.=C2=A0
* 6.1: the
"MUST" is strange in a section that's only supposed to be inf= ormative. Also,
the library may provide this extension (and possibly others) without requir= ing
it as input.
How else do you propose wording the requireme= nt that this API fail if the connection doesn't support EAs?
= =C2=A0
* 6.4: "= The API MUST return a failure if the
certificate_request_context of the authenticator was used in a previously validated authenticator." Are we requiring the library to keep previou= s
contexts for replay protection? If so, please make it explicit.
I think this can be a SHOULD based on the burden replay protection pl= aces on the implementation.=C2=A0
=C2=A0
*=C2=A0 7.1: this is
changing TLS 1.3 by allowing this extension in Cert Request! I think it'= ;s a
really bad idea. Better to hack special support to existing libraries, allo= wing
this specific extension for this special case, than to change the base
protocol. Otherwise, this document should UPDATE 8446.
This is a good point and one that we struggled a bit with durin= g design. We needed to allow SNI in the CertificateRequest message because = it can be client-generated in this context. I'd be ok with creating a d= ifferent extension for this, but it's rather elegant to re-use it in th= is context. I'd like to hear some opinions from the working group on this point
=C2=A0
* 8: I think the
Security Considerations is the right place to talk about interaction betwee= n
this protocol and TLS 1.3 (or 1.2) renegotiation. Even if we simply RECOMME= ND
not to do it. Or else explain the use cases where renegotiation is still us= eful
if there are any.

I'm not sure this= document should be prescriptive about use cases. This doc is providing a n= ew capability that may be leveraged at the application to replace the funct= ionality of existing mechanisms, but I'm not convinced the evaluation o= f the trade-offs of different mechanisms should be contained in this docume= nt.
--000000000000b54e4905967c5ec3-- From nobody Sun Nov 3 20:05:08 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6469C1202A0; Sun, 3 Nov 2019 20:04:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157284029936.13552.5322598753243989324@ietfa.amsl.com> Date: Sun, 03 Nov 2019 20:04:59 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-subcerts-05.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 04:04:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Delegated Credentials for TLS Authors : Richard Barnes Subodh Iyengar Nick Sullivan Eric Rescorla Filename : draft-ietf-tls-subcerts-05.txt Pages : 15 Date : 2019-11-03 Abstract: The organizational separation between the operator of a TLS endpoint and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the certification authority. This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking compatibility with peers that do not support this specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-subcerts-05 https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 4 02:21:05 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC6D12096E; Mon, 4 Nov 2019 02:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.159, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WogOAV2_phdv; Mon, 4 Nov 2019 02:20:50 -0800 (PST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 76622120100; Mon, 4 Nov 2019 02:20:49 -0800 (PST) Received: by mail-wr1-x431.google.com with SMTP id l10so16353480wrb.2; Mon, 04 Nov 2019 02:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=ipg6iU+jMB5XAKE2RJKv2PW3WR1ODcyvdnHRVdOYAxU=; b=tZrrbM0AOvdQIwHO19lIPT9Yzc+iBtiw2fEk03FIj6dWnRK5rXAt6atAWn8lkMfMrD mpcIhgCduFJnWrOe9fJUULVVZA8Fl9Z7dEWuzH6Ao8lSVd/z0NG435NiSgMCtk9+3xCc 8yaNdEbrGicJyAmxPNO49cB1mKUPTZtibm4TGY5YHUvJwntpDtxX65I3/r+Q9QYF15oC VwdkMuhDkJLajY48ATYJprBCqvNEautTRpORsqwHNjpeRBPKZfJqx0RMTeLldYa4xx03 EkCFctcwRP7ZdEo1l73sF5ptIHuk6AcvZACApcwIitardFWmiGLd5huPOOnu7+yLfZs8 U+yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=ipg6iU+jMB5XAKE2RJKv2PW3WR1ODcyvdnHRVdOYAxU=; b=HIGPzO/UNryFda5GjmwrnpCcgGaBnEhBzD3eHU1+Qr494JayGO22BZ/GLqgFKKf6DI mNPCdRKn8wNTtOBCv1QxicbmPXU/9X/e8++jDCeyo54lhsxfOeVCdBfJVuhjsscm8obx zo8rLAgwT3L6dK2RLVY/Rf2A16k/5AkyTTckWWRDUjpwwAJVQQeY+0sStXUADZGxEFLj 6hBEw+D83YAoveRRCQaD/kJ2FW6r9Z4ITAfcmAKYwQvYkPdjpC4Ej1TPqGeZMF/Fw2r8 uaLjsUWXuHUeQ2f++G+am8B2eUJe1/IumMxjwreJGAeTLURY/Eg+pmH1PyCSH5BLPI2p agyw== X-Gm-Message-State: APjAAAWqkDC0j47h2taI8+CRfr1/YA2bcZff0s+r8xTXivcfwIe5lAXj S1JteVXo96HrNck1kdsEUm92rNEb X-Google-Smtp-Source: APXvYqxXoizjVjo3t133xDZSZMCiHWi3hoQIwfCi/sE7fAIicKWF9YoPzrj41gXKMxyWDSmBM1cFIA== X-Received: by 2002:adf:fd4a:: with SMTP id h10mr20993447wrs.90.1572862847815; Mon, 04 Nov 2019 02:20:47 -0800 (PST) Received: from [172.28.128.176] (pub-corp-42-8.intuit.com. [91.102.42.8]) by smtp.gmail.com with ESMTPSA id h205sm17923358wmf.35.2019.11.04.02.20.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Nov 2019 02:20:46 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.1e.0.191013 Date: Mon, 04 Nov 2019 12:20:45 +0200 From: Yaron Sheffer To: Nick Sullivan CC: , , , "" Message-ID: Thread-Topic: Secdir last call review of draft-ietf-tls-exported-authenticator-09 References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3655714846_1726106478" Archived-At: Subject: Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 10:20:52 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3655714846_1726106478 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Nick, =20 Apologies for not responding on time. =20 I may be missing some follow-on discussions, but: =20 Ben suggested that we mention that QUIC is also an option, even if informat= ively, in addition to the =E2=80=9CSHOULD use TLS=E2=80=9D statement. I think we left my question re: back-fitting this protocol into the IANA TL= S registry open. Quoting:=20 =20 YS: 7.1: this is changing TLS 1.3 by allowing this extension in Cert Reques= t! I think it's a really bad idea. Better to hack special support to existin= g libraries, allowing this specific extension for this special case, than to= change the base protocol. Otherwise, this document should UPDATE 8446. =20 NS: This is a good point and one that we struggled a bit with during design= . We needed to allow SNI in the CertificateRequest message because it can be= client-generated in this context. I'd be ok with creating a different exten= sion for this, but it's rather elegant to re-use it in this context. *I'd li= ke to hear some opinions from the working group* on this point =20 BK: Or, since extension codepoints are cheap, just use a new codepoint. =20 Thanks, =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 Yaron =20 From: Nick Sullivan Date: Monday, November 4, 2019 at 04:49 To: Yaron Sheffer Cc: , = , , "" Subject: Re: Secdir last call review of draft-ietf-tls-exported-authenticat= or-09 =20 Following up, =20 Yaron, do the responses by myself and Benjamin along with the does the foll= owing PR sufficiently address your comments/concerns? =20 https://github.com/tlswg/tls-exported-authenticator/pull/52 =20 On Wed, Sep 18, 2019 at 4:55 PM Nick Sullivan wrote: Hi Yaron, =20 Thank you for your thorough review. My answers will be inline, and I'll inc= orporate some of Ben's replies if necessary. Here's a PR with proposed chang= es in response to your comments: https://github.com/tlswg/tls-exported-authenticator/pull/52 =20 On Tue, Jul 16, 2019 at 12:59 PM Yaron Sheffer via Datatracker wrote: Reviewer: Yaron Sheffer Review result: Has Issues The document is generally clear in both its motivation and the proposed solution. I think it's playing a bit too liberal with TLS 1.3, in sort-of but not qui= te deprecating renegotiation, and in changing the IANA registry in a way that actually changes the protocol. Details below. Other comments: * Abstract: please reword to make it clear that it's the proof (not the cer= t) that is portable. =20 Proposed text here: This document describes a mechanism in Transport Layer Security (TLS) for p= eers to provide a proof of ownership of a certificate. This proof can be exported by one peer, transmitted out-of-band to the other peer, and verified by the= receiving peer. =20 * Introduction: TLS 1.3 post-handshake auth "has the disadvantage of requiring additional state to be stored as part of the TLS state machine." Why is that an issue is practice, assuming this feature is already supported by TLS libraries? Also, are we in effect deprecating this= TLS 1.3 feature because of the security issue of the mismatched record boundari= es? =20 My understanding is that post-handshake authentication as defined in the TL= S 1.3 RFC is not implemented in many (any?) TLS 1.3 libraries and some imple= mentors would prefer to use exported authenticators. =20 * "For simplicity, the mechanisms... require", maybe a normative REQUIRE? I'm fine with this. =20 * Authenticator Request: please clarify that we use the TLS 1.3 format even= when running on TLS 1.2. Updated, though it might be a bit unnecessary. =20 * Also, I suggest to change "is not encrypted with a handshake key" which is too specific to "is sent unencrypted within the nor= mal TLS-protected data". This specific text is meant to differentiate the wire format of this messag= e from that of the CertificateRequest message, which is encrypted with the h= andshake key. The specificity is warranted. =20 * Before diving into the detailed messages in Sec. 3, it would be nice to include a quick overview of the message sequence. There are two message types and three potential sequences. I've added a sho= rt overview. =20 * Sec. 3: "SHOULD use TLS", change to MUST. There's no way it can work otherwise anyw= ay. As Ben noted, this could be any secure channel with equivalent security to = TLS, such as QUIC. We shouldn't forbid other secure out-of-band mechanisms. =20 * "This message reuses the structure to the CertificateRequest message" - repeats the preceding paragraph. Fixed =20 * Sec. 4: again, SHOULD use TLS -> MUST. Again, I don't see the need for a MUST here. =20 * Is there a requirement for all protocol messages to be sent over a single TLS connection? If so, please mention it. Certainly this is true for the Authenticator message that must be sent over a single connection and cannot= be multiplexed by the high-level protocol. I think this protocol actually assu= mes "nice" transport properties (no message reorder, reliability) that also req= uire a single, clean TLS connection. There is no such requirement. Message ordering is managed by the applicatio= n layer protocol that utilizes exported authenticators. =20 * Why no authenticator request for servers? Don't we care about replay? OTOH if the client wants to detect replays, it would need to keep state on received authenticators, which would be very me= ssy. I'm not sure I understand. It's possible to use authenticator requests for = servers. =20 * 4.1: when referencing Exporters, mention this is Sec. 7.5 of [TLS1.3]. Added "Sec. 7.5" =20 * The discussion of Extended Master Secret only applies to TLS 1.2 - please clari= fy that, plus I suggest to reword this paragraph which I find hard to parse. re-worded =20 * 4.2: "the extensions are chosen from the TLS handshake." - What does it mea= n exactly, and how does an application even know which extensions were used a= t the TLS layer? Reading further, we mention "ClientHello extensions." Maybe = the authenticator should also include a ClientHello message to indicate support= ed extensions. Assuming we can peek into ClientHello contradicts the hopeful "= even if it is possible to implement it at the application layer" in Sec. 6. =20 This could be clearer. Effectively, the Certificate message in the Authenti= cator needs to be constructed in a similar manner to how a Certificate message would be= created in a TLS handshake. Namely, it can only contain extensions that were presen= t in either the client hello or a preceding CertificateRequest. =20 You're right that this makes an assumption that the party creating the Auth= enticator has access to the TLS handshake state. This implies that even if the Authen= ticator is created in the application space, an additional API needs to be exposed = to share that information. =20 * 4.2.1: the first sentence of the section is incomplete. =20 Fixed =20 * Can I use TLS 1.3-specific extensions (oid_filters) if I'm running on a TLS 1.2 connection? Is there a situation where a certificate is acceptable for TLS 1.3 connections but not= for TLS 1.2 connections? Yes TLS 1.3-specific extensions are allowed, the CertificateRequest message= is TLS 1.3-compatible. =20 * "using a value derived from the connection secrets" - I think we should recommend a specific construction here to ensure people do = it securely. This was a suggestion from the Additional Certificates use case (https://to= ols.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-05). I'm not s= ure we should get into the details here. =20 * 4.2.3: Are we computing HMAC(MAC-key, Hash(a || b || c || d))? If so, please say so. Yes, I'll put that in. =20 * 4.2.4: "a constant-time comparison" - why is it actually required, what is the threat? An attacker can do very little because each authenticator being sent is different. As Ben noted, this was a safety note added during review. =20 * 5: please say explicitly which messages are used in this case to construct the authenticator. =20 Re-written.=20 * 6.1: the "MUST" is strange in a section that's only supposed to be informative. Also= , the library may provide this extension (and possibly others) without requir= ing it as input. How else do you propose wording the requirement that this API fail if the c= onnection doesn't support EAs? =20 * 6.4: "The API MUST return a failure if the certificate_request_context of the authenticator was used in a previously validated authenticator." Are we requiring the library to keep previous contexts for replay protection? If so, please make it explicit. I think this can be a SHOULD based on the burden replay protection places o= n the implementation.=20 =20 * 7.1: this is changing TLS 1.3 by allowing this extension in Cert Request! I think it's a really bad idea. Better to hack special support to existing libraries, allo= wing this specific extension for this special case, than to change the base protocol. Otherwise, this document should UPDATE 8446. =20 This is a good point and one that we struggled a bit with during design. We= needed to allow SNI in the CertificateRequest message because it can be cli= ent-generated in this context. I'd be ok with creating a different extension= for this, but it's rather elegant to re-use it in this context. I'd like to= hear some opinions from the working group on this point =20 * 8: I think the Security Considerations is the right place to talk about interaction betwee= n this protocol and TLS 1.3 (or 1.2) renegotiation. Even if we simply RECOMME= ND not to do it. Or else explain the use cases where renegotiation is still us= eful if there are any. =20 I'm not sure this document should be prescriptive about use cases. This doc= is providing a new capability that may be leveraged at the application to r= eplace the functionality of existing mechanisms, but I'm not convinced the e= valuation of the trade-offs of different mechanisms should be contained in t= his document. --B_3655714846_1726106478 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Nick,

&nb= sp;

Apologies for not responding on time.

 

I may be = missing some follow-on discussions, but:

 

  • Ben suggested that we= mention that QUIC is also an option, even if informatively, in addition to = the =E2=80=9CSHOULD use TLS=E2=80=9D statement.
  • I think we left my questio= n re: back-fitting this protocol into the IANA TLS registry open. Quoting: <= o:p>

 

YS: 7.1: this is changing TLS 1.3 by allowing this extension in Cert Requ= est! I think it's a really bad idea. Better to hack special support to exist= ing libraries, allowing this specific extension for this special case, than = to change the base protocol. Otherwise, this document should UPDATE 8446.

 

NS: T= his is a good point and one that we struggled a bit with during design. We n= eeded to allow SNI in the CertificateRequest message because it can be clien= t-generated in this context. I'd be ok with creating a different extension f= or this, but it's rather elegant to re-use it in this context. *I'd like to = hear some opinions from the working group* on this point

 

BK: Or, since extensio= n codepoints are cheap, just use a new codepoint.

 

Thanks,

=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 Yaron

 

From: Nick Sullivan <nick@cloudflare.com>
Date: Monday, Nove= mber 4, 2019 at 04:49
To: Yaron Sheffer <yaronf.ietf@gmail.com&= gt;
Cc: <secdir@ietf.org>, <draft-ietf-tls-exported-authe= nticator.all@ietf.org>, <ietf@ietf.org>, "<tls@ietf.org>= " <tls@ietf.org>
Subject: Re: Secdir last call review o= f draft-ietf-tls-exported-authenticator-09

<= p class=3DMsoNormal> 

Followi= ng up,

 

Yaron, do the responses by myself and Benjamin along wit= h the does the following PR sufficiently address your comments/concerns= ?

 

https://github.com/tlswg/tls-exported-authenticator/pull/52

 

<= p class=3DMsoNormal>On Wed, Sep 18, 2019 at 4:55 PM Nick Sullivan <nick@cloudflare.com> wrote:

Hi Yaron,

 <= /p>

Thank you for your thorough review. My answ= ers will be inline, and I'll incorporate some of Ben's replies if neces= sary. Here's a PR with proposed changes in response to your comments:

 

On Tue, Jul 16, = 2019 at 12:59 PM Yaron Sheffer via Datatracker <noreply@ietf.org> wrote:

Reviewe= r: Yaron Sheffer
Review result: Has Issues

The document is general= ly clear in both its motivation and the proposed
solution.

I think= it's playing a bit too liberal with TLS 1.3, in sort-of but not quite
de= precating renegotiation, and in changing the IANA registry in a way that
= actually changes the protocol. Details below.

Other comments:

= * Abstract: please reword to make it clear that it's the proof (not the cert= )
that is portable.

 

Proposed text here:

This document describes a mechanism in = Transport Layer Security (TLS) for peers to
provide a proof of ownership = of a certificate.  This proof can be exported
by one peer, transmitt= ed out-of-band to the other peer, and verified by the receiving peer.

 

* Introduction: TLS= 1.3 post-handshake auth "has the
disadvantage of requiring addition= al state to be stored as part of the TLS
state machine." Why is that= an issue is practice, assuming this feature is
already supported by TLS = libraries? Also, are we in effect deprecating this TLS
1.3 feature becaus= e of the security issue of the mismatched record boundaries?

<= /blockquote>

 

My understanding is that post-handshake authentication as de= fined in the TLS 1.3 RFC is not implemented in many (any?) TLS 1.3 libraries= and some implementors would prefer to use exported authenticators.

 

* "For simp= licity, the mechanisms... require", maybe a normative REQUIRE?

I'm fine with this.

 

* Authenticator Request: p= lease clarify that we use the TLS 1.3 format even when
running on TLS 1.2= .

 Updated, though i= t might be a bit unnecessary.

 

* Also, I suggest to change "is not encrypted with ahandshake key" which is too specific to "is sent unencrypted wit= hin the normal
TLS-protected data".

=

This specific text is meant to differentiate the wire for= mat of this message from that of the CertificateRequest message, which is en= crypted with the handshake key. The specificity is warranted.

=

 

* Before diving into the de= tailed messages in Sec. 3, it
would be nice to include a quick overview o= f the message sequence.

T= here are two message types and three potential sequences. I've added a short= overview.

 

=

* = Sec. 3:
"SHOULD use TLS", change to MUST. There's no way it can= work otherwise anyway.

A= s Ben noted, this could be any secure channel with equivalent security to TL= S, such as QUIC. We shouldn't forbid other secure out-of-band mechanisms.

 

* "This me= ssage reuses the structure to the CertificateRequest message" -
repe= ats the preceding paragraph.

Fixed

 

<= /div>

* S= ec. 4: again, SHOULD use TLS -> MUST.

Again, I don't see the need for a MUST here.

<= /div>

 

* Is
there a requirement = for all protocol messages to be sent over a single TLS
connection? If so,= please mention it. Certainly this is true for the
Authenticator message = that must be sent over a single connection and cannot be
multiplexed by t= he high-level protocol. I think this protocol actually assumes
"nice= " transport properties (no message reorder, reliability) that also requ= ire
a single, clean TLS connection.

There is no such requirement. Message ordering is managed by t= he application layer protocol that utilizes exported authenticators.

 

* Why no authenticat= or request for servers?
Don't we care about replay? OTOH if the client wa= nts to detect replays, it
would need to keep state on received authentica= tors, which would be very messy.

I'm not sure I understand. It's possible to use authenticator reques= ts for servers.

 

* 4.1: when referencing Exporters, mention this is Sec. 7.5 of [TLS1.3].<= o:p>

Added  "Sec. 7.= 5"

 

* The=
discussion of Extended Master Secret only applies to TLS 1.2 - please cl= arify
that, plus I suggest to reword this paragraph which I find hard to = parse.

re-worded

 

*
4.2: "the e= xtensions are chosen from the TLS handshake." - What does it mean
ex= actly, and how does an application even know which extensions were used atthe TLS layer? Reading further, we mention "ClientHello extensions.&q= uot; Maybe the
authenticator should also include a ClientHello message to= indicate supported
extensions. Assuming we can peek into ClientHello con= tradicts the hopeful "even
if it is possible to implement it at the = application layer" in Sec. 6.

 

This could be c= learer. Effectively, the Certificate message in the Authenticator needs=

to be constructed in a similar manne= r to how a Certificate message would be created

in a TLS handshake. Namely, it can only contain extensions t= hat were present in either

the c= lient hello or a preceding CertificateRequest.

 

You'r= e right that this makes an assumption that the party creating the Authentica= tor

has access to the TLS handsh= ake state. This implies that even if the Authenticator

<= div>

is created in the application space, an additional AP= I needs to be exposed to share

t= hat information.

 

* 4.2.1:
the first sentence of the section is incomplete.<= /p>

 

Fixed

 =

* Can I use TLS 1.3-specific
extensions (oid_filters) if I'm runn= ing on a TLS 1.2 connection? Is there a
situation where a certificate is = acceptable for TLS 1.3 connections but not for
TLS 1.2 connections?<= /o:p>

Yes TLS 1.3-specific extension= s are allowed, the CertificateRequest message is TLS 1.3-compatible.

 

* "using a valu= e derived from the connection secrets" - I
think we should recommend= a specific construction here to ensure people do it
securely.=

This was a suggestion from the Addi= tional Certificates use case (https://tools.ietf.or= g/html/draft-bishop-httpbis-http2-additional-certs-05). I'm not sure we = should get into the details here.

 

 

* 4.2.4: "a constant-time comparison" - why is= it actually
required, what is the threat? An attacker can do very little= because each
authenticator being sent is different.

As Ben noted, this was a safety note added du= ring review.

 

= * 5: please say explicitly which
messages are used in this case to constr= uct the authenticator.

 

Re-written. 

* 6.1: the
"MUST" is strange in a section that's only suppos= ed to be informative. Also,
the library may provide this extension (and p= ossibly others) without requiring
it as input.

How else do you propose wording the requirement tha= t this API fail if the connection doesn't support EAs?

<= div>

 

* 6.4: "The API MUST return a= failure if the
certificate_request_context of the authenticator was used= in a previously
validated authenticator." Are we requiring the libr= ary to keep previous
contexts for replay protection? If so, please make i= t explicit.

I think this = can be a SHOULD based on the burden replay protection places on the implemen= tation. 

 <= /p>

*  7.1: this is
changing TLS 1.3 by allowing this extension in Cert= Request! I think it's a
really bad idea. Better to hack special support = to existing libraries, allowing
this specific extension for this special = case, than to change the base
protocol. Otherwise, this document should U= PDATE 8446.

 

This is a good point and one that we s= truggled a bit with during design. We needed to allow SNI in the Certificate= Request message because it can be client-generated in this context. I'd be o= k with creating a different extension for this, but it's rather elegant to r= e-use it in this context. I'd like to hear some opinions from the working= group on this point

 <= o:p>

* 8: I think the
Security Considerations is the right place t= o talk about interaction between
this protocol and TLS 1.3 (or 1.2) reneg= otiation. Even if we simply RECOMMEND
not to do it. Or else explain the u= se cases where renegotiation is still useful
if there are any.=

 

I'm not sure this document should be prescriptive about use = cases. This doc is providing a new capability that may be leveraged at the a= pplication to replace the functionality of existing mechanisms, but I'm not = convinced the evaluation of the trade-offs of different mechanisms should be= contained in this document.

--B_3655714846_1726106478-- From nobody Mon Nov 4 06:16:12 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE7C1200A4 for ; Mon, 4 Nov 2019 06:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 sF0SPX5bdFft for ; Mon, 4 Nov 2019 06:16:09 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 F39A0120099 for ; Mon, 4 Nov 2019 06:16:08 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id p20so5824114qtq.5 for ; Mon, 04 Nov 2019 06:16:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=jbO2AyYLQqohwdwsIpwAB5964iqnrYHLgaU/up3Mg90=; b=HJVw/pCLangJuQZB1atkR0kDxeYWGRmsjv4CzlAyKpzhcPnQQFym9OcaXEC+BGflNy DpfkKMBX9iGMCl+MaboeAZvt7kF63GA4JFRPTVdQhulGQNOQXZEtysVl1q/ugj+1qxX2 wQ6ubqkhUWQd8pUPjsseQixXSQhOsFkrhF/HY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=jbO2AyYLQqohwdwsIpwAB5964iqnrYHLgaU/up3Mg90=; b=T6NyQNxallUR5RTLG7BMcEWXfI1u0rcGDxglk+TScs5Ii4xDChTj3kZ67RXTtk8zvx 3g7KYCqJ3jB4F+DcZISbtf+D1wXp4ADfwQES8iYHUVjLEtV6p353wRiwIKjol8lDGGZ8 7sU3uhpnulnOweGoQXfOkkdb4Tk4CB7tjp2mAgDZsSHDAMKmXhrkcn4Hezweq+HkQs3+ g2kZzl+HJaj95XeOLnxsV0eT0xmuROItDPabUpXKJGBsW87v7mnV2g5q82RQDXLAUDjH /Om50jEs+fP6toHvB7sxUv/0HDFDNWvnZEfvi2wLM8+PxQqCda1R8aNl/HPLvsT/8rAs JmZA== X-Gm-Message-State: APjAAAVUbYdJWqQa1e/l0xgS6N6fV0m6z0+OIjmg+LreY8URvSQH7Fj4 yUnvjWzWSDM4H4fIANR7sprwzfhf0fo= X-Google-Smtp-Source: APXvYqwMyCENtk8J9IptRiG12Y8g3UyYw057WR3vPDl1iFSIOtb9Q+1s8hlB4B8svIi+sL0fbTOYcw== X-Received: by 2002:aed:30ac:: with SMTP id 41mr12614596qtf.157.1572876967884; Mon, 04 Nov 2019 06:16:07 -0800 (PST) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id 19sm9040288qkg.89.2019.11.04.06.16.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Nov 2019 06:16:07 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 4 Nov 2019 09:16:06 -0500 References: <586FB0E1-5C8C-474D-952D-A99449F1E54E@sn3rd.com> To: TLS List In-Reply-To: <586FB0E1-5C8C-474D-952D-A99449F1E54E@sn3rd.com> Message-Id: <834F704A-5C6C-4325-9C80-F8C527D8D818@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] Standards Track for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 14:16:11 -0000 November 1st has come and gone. Though silence is not consensus, I will = interpret this particular silence as such because I suspect that this = particular piece of process is not that interesting to most. I = submitted a PR to change the track to =E2=80=9CStandards": https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/8 The authors should feel free to submit a new version (maybe even before = the submission cutoff deadline today). spt > On Oct 25, 2019, at 09:04, Sean Turner wrote: >=20 > During my Shepherd review of draft-ietf-tls-ticketrequests, I noticed = that the intended status of the draft is Informational, but the IANA = Considerations sections indicates that the Recommended column is = =E2=80=9CY=E2=80=9D. RFC 8447 requires Standards Action for an = extension to be marked as Recommended. I went back and looked and the = extension has been marked as Recommended since Chris' and David=E2=80=99s = initial individual draft back in April 2018. I think that this has been = an oversight and believe the intended status should be changed to = Proposed Standard. If you think this change is wrong, please let the = list know why by November 1st. >=20 > Note that this is the final issue before I will issue WGLC. >=20 > Cheers, >=20 > spt From nobody Mon Nov 4 07:40:41 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 462F2120808; Mon, 4 Nov 2019 07:40:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157288203019.16589.3397770416591261142@ietfa.amsl.com> Date: Mon, 04 Nov 2019 07:40:30 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-ticketrequests-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 15:40:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : TLS Ticket Requests Authors : Tommy Pauly David Schinazi Christopher A. Wood Filename : draft-ietf-tls-ticketrequests-04.txt Pages : 6 Date : 2019-11-04 Abstract: TLS session tickets enable stateless connection resumption for clients without server-side, per-client state. Servers vend an arbitrary number of session tickets to clients, at their discretion, upon connection establishment. Clients store and use tickets when resuming future connections. This document describes a mechanism by which clients can specify the desired number of tickets needed for future connections. This extension aims to provide a means for servers to determine the number of tickets to generate in order to reduce ticket waste, while simultaneously priming clients for future connection attempts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-ticketrequests-04 https://datatracker.ietf.org/doc/html/draft-ietf-tls-ticketrequests-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ticketrequests-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 4 07:43:59 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B83120130; Mon, 4 Nov 2019 07:43:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157288223765.16630.8226597046168859366@ietfa.amsl.com> Date: Mon, 04 Nov 2019 07:43:57 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-external-psk-importer-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 15:43:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Importing External PSKs for TLS Authors : David Benjamin Christopher A. Wood Filename : draft-ietf-tls-external-psk-importer-02.txt Pages : 10 Date : 2019-11-04 Abstract: This document describes an interface for importing external PSK (Pre- Shared Key) into TLS 1.3. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-02 https://datatracker.ietf.org/doc/html/draft-ietf-tls-external-psk-importer-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-external-psk-importer-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 4 08:05:57 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDAD120A9D for ; Mon, 4 Nov 2019 08:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 hFi2d5jgi-GM for ; Mon, 4 Nov 2019 08:05:53 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 260FA120118 for ; Mon, 4 Nov 2019 08:05:53 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id r22so14613951qtt.2 for ; Mon, 04 Nov 2019 08:05:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=RCsyBFRHvm2HkhkAShOoxXyD/pzM8hfkarEOP/2NTYs=; b=QdBsL3ivhVVNrzi73Kgf7QEHuNTLhLUnK6N5yqOhML1wkR5eAL10EtUenc3xsSXyO+ otyoU1xrMkVBaER0BVEBiKVF06+MO5tN2V0u2a9r+6GDw8rbiWSv+qZEMcVFZCMnp2bt Jdmgn3NwDf9tGg28ISdj5tgP6ruvbvdKNtfBU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=RCsyBFRHvm2HkhkAShOoxXyD/pzM8hfkarEOP/2NTYs=; b=lhjICEjAJEk92RhdXxTxoKrIaKvQXzAgjtC9ennCX4J4S6n1ZkfVBcQSeqSR5r/7qi v7+saF+5g3qWrCIS5Kgym6GxX6vSprL67fBE7e9YQcXUDvXcglTxURacCpbRI0g2SWaf v0v/HJEIUpkahsNIyXh+1g/B1Ow7wE/cuSHtS8xlNHqGabF3juFcjRBA7/rdzMi3gkcV j+J1AYbJw036gIIPsFo3NaaJBrh+epqSfMF9k/sxiPZBixXcIcVezAWFM0jUCBrrTVyF rkbKzpyj9Xob9SU37d8viksD5lzfvkky9ww65v+1q78J9cKrYojQzWebY8oAuJZ5znOu nAEg== X-Gm-Message-State: APjAAAVX7AuPgdi2UQRIwdeAqwx4gZ8ubkUrEXttBq3GIiVsfHq6Xkia l55TQ9Fj8p4hcilhA50nwZIMK7tF5lQ= X-Google-Smtp-Source: APXvYqxbPP3+rm4hiDaFDkfi4fXW4JTssSdjoPqLmmxcuLc+qAUJF3Up23+1+T2gkuYxJFJkq4zSuw== X-Received: by 2002:ac8:f8d:: with SMTP id b13mr13147231qtk.129.1572883551927; Mon, 04 Nov 2019 08:05:51 -0800 (PST) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id w23sm1490870qtw.87.2019.11.04.08.05.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Nov 2019 08:05:51 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 4 Nov 2019 11:05:50 -0500 References: <157288203019.16589.3397770416591261142@ietfa.amsl.com> To: TLS List In-Reply-To: <157288203019.16589.3397770416591261142@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 16:05:56 -0000 This version makes the track change: informational->standards. Once I = get the BCP 78 and 79 confirmations from the authors I will be = forwarding this to the IESG. spt > On Nov 4, 2019, at 10:40, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Layer Security WG of the = IETF. >=20 > Title : TLS Ticket Requests > Authors : Tommy Pauly > David Schinazi > Christopher A. Wood > Filename : draft-ietf-tls-ticketrequests-04.txt > Pages : 6 > Date : 2019-11-04 >=20 > Abstract: > TLS session tickets enable stateless connection resumption for > clients without server-side, per-client state. Servers vend an > arbitrary number of session tickets to clients, at their discretion, > upon connection establishment. Clients store and use tickets when > resuming future connections. This document describes a mechanism by > which clients can specify the desired number of tickets needed for > future connections. This extension aims to provide a means for > servers to determine the number of tickets to generate in order to > reduce ticket waste, while simultaneously priming clients for future > connection attempts. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-ticketrequests-04 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-ticketrequests-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-ticketrequests-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Nov 4 08:09:02 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB618120A17 for ; Mon, 4 Nov 2019 08:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 m5tM2cVg5sEB for ; Mon, 4 Nov 2019 08:09:00 -0800 (PST) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A7621209F4 for ; Mon, 4 Nov 2019 08:09:00 -0800 (PST) Received: by mail-qt1-x835.google.com with SMTP id o3so24691116qtj.8 for ; Mon, 04 Nov 2019 08:09:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=Oegmr0aXLWEa8m9unYHd9U2HUc3Fn1/dWbCovJ/i4DY=; b=BGfV0a6tRBdKVXhqE9iMSEP3DFA8N1SnEDkSqD3O6OR7UELwDbNQwC3YpvGyjds60P kDEkaMV0Zw63x8TQ2AFodNrsx2WLWpa33U5Min90/kA343/1mKmfgVH66s6Vsi8Th2z/ WlcqGXGeDOJ06TySY1AHkPVPb9DcHmhAVlBQw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=Oegmr0aXLWEa8m9unYHd9U2HUc3Fn1/dWbCovJ/i4DY=; b=JkUp4p5dq12AwiEpcPB9G9aKmxuTX+WyTubfkIhpfmCQ93hWiBwMYI+nOJx6pfD2Qp pD0xjSKvJxV/4FmrcRcVnkLjN3wU8kL4txDhQeZB/y1ZcA0wGJbpF7/WoclD8gJ5lmKZ orPisPVUgPOpkjF/avj4pkKSrN0G2eshSipffejWIReRWlMaizyIUG6N7pHYVavc3yO1 d34FCtklkiJWH2dG1m4RwJOUHQIs5Y9bWOl/nsCBtMLL2nx4JSbOt03cDvFYZFkwMKX/ YKO3A0nGBNdaYE1F0Dri3XOejd0ocggAdTWCVRmvQqInFB94CP48qvNMsC9YwKbozkEU VQhA== X-Gm-Message-State: APjAAAVa+zDsjAK8jWJ2GfyIcMYSMSpe8qL3f+W4DkfkU7WY0nxpm2aR EuhMx4HFwtD348DeLCRetfeJr2/ofLI= X-Google-Smtp-Source: APXvYqyptG8SkSccO2WW3dznk9hNAdw/1FrIDRu5VrTQo/V5cSZRSDl3/XJSMmiLG087UTRGSFJxzQ== X-Received: by 2002:ac8:30dc:: with SMTP id w28mr8644774qta.21.1572883739096; Mon, 04 Nov 2019 08:08:59 -0800 (PST) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id o1sm9744166qtb.82.2019.11.04.08.08.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Nov 2019 08:08:57 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 4 Nov 2019 11:08:56 -0500 References: <12219D44-9FB9-4B55-9B86-6B9AB4FCC5C5@sn3rd.com> To: TLS List In-Reply-To: <12219D44-9FB9-4B55-9B86-6B9AB4FCC5C5@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] 2nd WGLC for draft-ietf-tls-dtls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 16:09:02 -0000 This WGLC has concluded. I will complete my shepherd write-up and = forward this to the IESG once I have received the BCP 78 and 70 = confirmations. spt > On Oct 13, 2019, at 21:13, Sean Turner wrote: >=20 > This is the second working group last call for the "The Datagram = Transport > Layer Security (DTLS) Protocol Version 1.3" draft available at > https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/. Please > review the document and send your comments to the list by 2359 UTC on > 28 October 2019. >=20 > Please note that we are now on at version -33. -30 was the subject of = the > 1st WGLC and the WG should focus on changes introduced since -30 > version. Diffs between -30 and -33 can be found at: > = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tls-dtls13-30&url2=3Ddraft-= ietf-tls-dtls13-33 >=20 > Note the the GH repo for this draft can be found at: > https://github.com/tlswg/dtls13-spec >=20 > Thanks, > Chris, Joe, and Sean From nobody Mon Nov 4 12:16:13 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B955E120018; Mon, 4 Nov 2019 12:16:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157289856571.13916.12337016198537882521@ietfa.amsl.com> Date: Mon, 04 Nov 2019 12:16:05 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-tlsflags-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 20:16:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : A Flags Extension for TLS 1.3 Author : Yoav Nir Filename : draft-ietf-tls-tlsflags-01.txt Pages : 7 Date : 2019-11-04 Abstract: A number of extensions are proposed in the TLS working group that carry no interesting information except the 1-bit indication that a certain optional feature is supported. Such extensions take 4 octets each. This document defines a flags extension that can provide such indications at an average marginal cost of 1 bit each. More precisely, it provides as many flag extensions as needed at 4 + the order of the last set bit divided by 8. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-tlsflags-01 https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tlsflags-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 4 13:21:15 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76290120099 for ; Mon, 4 Nov 2019 13:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 q5-h14mK6wI9 for ; Mon, 4 Nov 2019 13:21:01 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 4E35D1209B7 for ; Mon, 4 Nov 2019 13:20:38 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id 15so19112641qkh.6 for ; Mon, 04 Nov 2019 13:20:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=NZqSNiW0jmzL7W+7mmyXwPs+okGqL4X1iIfDN/70ykY=; b=S3Fc7u+gaEZiwq3isveeTXIgZdVA7yd6uVILunAv21vjQIKYV1bVzURzMnC59tMe12 pp1hJFiqKkodQjpF7YppYqGRZjPCJIoPrfG7DVRYhSQawC3Y27GDAKIjECu5WXjdwAZP B29ih9W7yF2arbWjaUF7oiYCMCTCB/V1cv5KA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=NZqSNiW0jmzL7W+7mmyXwPs+okGqL4X1iIfDN/70ykY=; b=KwYG/h+jIE+7P3SpXBGmbTAqbvo8ykbCWQVmkxkB2ukkiVZc/xddAY5yfGdhbQjfH0 1xPyHSAgigUpv8aon05Vwu/thNbFhy2LckWPTYMyaW/Hck6hHpnoWXenLrrYgcSoKmKE cdKVUC4Mf4V9hV/xpNq1WsziHYCVuRD605vjk8Gj/WfVJW06Ycudem5ytQY2lksp7cwb BC4Fdxgzsmd2IkxCVed8nzFXcmlCh6gD247B1uoMdUEIO8GH8TAGKrrnCWbLpI+dobyO fCh8MEqEa7/Ci0jQSIzQUK2y/WaR3aXXRW9stERSGhTdnBSEoeB702Nwo53dtG8kFyW1 IfVQ== X-Gm-Message-State: APjAAAX+rqjcpCUccsYtUCaoWENkmNnZJ/qx5t4jHC4ySDbdv6bB4qmA S57DSuXlOQUSypDFWtWapbVfDaN21zs= X-Google-Smtp-Source: APXvYqz6R3Gs0VT1pHmGItWGCkW++PDuV/acmrVgjM8bVOZqg56Oak+keUmwWFAxXCrrE3cuRm5AZA== X-Received: by 2002:a05:620a:13c4:: with SMTP id g4mr20247891qkl.391.1572902436976; Mon, 04 Nov 2019 13:20:36 -0800 (PST) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id o2sm9540202qkf.68.2019.11.04.13.20.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Nov 2019 13:20:36 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 4 Nov 2019 16:20:35 -0500 References: <157288203019.16589.3397770416591261142@ietfa.amsl.com> To: TLS List In-Reply-To: Message-Id: <5DF31C34-1EF8-46B5-BB66-287E24FA9503@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 21:21:14 -0000 Sorry folks I was jumping the gun there. I need to kick off the WGLC = before sending it on the IESG. Stay tuned. spt > On Nov 4, 2019, at 11:05, Sean Turner wrote: >=20 > This version makes the track change: informational->standards. Once I = get the BCP 78 and 79 confirmations from the authors I will be = forwarding this to the IESG. >=20 > spt >=20 >> On Nov 4, 2019, at 10:40, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Transport Layer Security WG of the = IETF. >>=20 >> Title : TLS Ticket Requests >> Authors : Tommy Pauly >> David Schinazi >> Christopher A. Wood >> Filename : draft-ietf-tls-ticketrequests-04.txt >> Pages : 6 >> Date : 2019-11-04 >>=20 >> Abstract: >> TLS session tickets enable stateless connection resumption for >> clients without server-side, per-client state. Servers vend an >> arbitrary number of session tickets to clients, at their discretion, >> upon connection establishment. Clients store and use tickets when >> resuming future connections. This document describes a mechanism by >> which clients can specify the desired number of tickets needed for >> future connections. This extension aims to provide a means for >> servers to determine the number of tickets to generate in order to >> reduce ticket waste, while simultaneously priming clients for future >> connection attempts. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-tls-ticketrequests-04 >> = https://datatracker.ietf.org/doc/html/draft-ietf-tls-ticketrequests-04 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-ticketrequests-04 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 From nobody Mon Nov 4 13:46:50 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C151209FF; Mon, 4 Nov 2019 13:46:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157290400459.13859.1364211055594059857@ietfa.amsl.com> Date: Mon, 04 Nov 2019 13:46:44 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-esni-05.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 21:46:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Encrypted Server Name Indication for TLS 1.3 Authors : Eric Rescorla Kazuho Oku Nick Sullivan Christopher A. Wood Filename : draft-ietf-tls-esni-05.txt Pages : 27 Date : 2019-11-04 Abstract: This document defines a simple mechanism for encrypting the Server Name Indication for TLS 1.3. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-esni-05 https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-esni-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 4 14:00:17 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFD3120236 for ; Mon, 4 Nov 2019 14:00:15 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 hUZxfANFJ9Tt for ; Mon, 4 Nov 2019 14:00:08 -0800 (PST) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 0E1B3120AC1 for ; Mon, 4 Nov 2019 14:00:08 -0800 (PST) Received: by mail-vk1-xa2f.google.com with SMTP id e205so4198559vke.2 for ; Mon, 04 Nov 2019 14:00:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=vIUrQCGLm4jpSWMb0D0vnQiedmZbhqTaLSaO1/RSExg=; b=m7jZdn/CQ2RySw/La9x+87vWM/uQSjhFmLQZkQLPX9YzxeFfSl3vdpgDiV75Fxg/li Qmkc93uznVVTu46rg0ugwWtMpC6IbXl+nDxoV5A7Eak8XhlqJ0KxerQLCPhI2Uiidvkh J+sjDd70RoGFspOaDiTkvIh6/0NsqyNf18cqcsv9uUxeOJ2vkAY1IhETqcIS2HYHnGTp InuJLD0YeAsVFlVUdAp4RtZtR/YUFV2neTgpCvlHiALmJjuACXiqyQ9l/naYOKSY2Uft ZXJZqAVpJsKtvTWwBz91a12ItU76C6oGyuQdWQhsnTTJhVnAevdTAev7F6FITGTDT+n/ Hhpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=vIUrQCGLm4jpSWMb0D0vnQiedmZbhqTaLSaO1/RSExg=; b=JFGkXK+mciOFZizi3zKS5iSdhQAQPn+zD3ongS9cXRTFNRkm06S6UuE9/tTVVPSFSu 6sd5g/1GUqEVUUjDZokW2PPfwxxQRa51HDKLzDt/QLvt6x2tyPsvk+Y7CYRl+78fWWRt xXT7MnpOv1sBf/0Wjq9NILqZgF4oy4huuKXZenIg7M4kYBC+v3XNZi90AUoV7YIDbcvM /bHj3X6qPkrlxThQFO7jHjZ8b8R2DC7v1R9zvmBISO+lMGLCZQnqh13n2ZKBJlkzrnYi rAE5kAz17vjsTVS6rrKs4z+GLUtgzmxi3hZ1K9BLkTErgLL0tqeA0q+7COSz6C4RvttD cmSA== X-Gm-Message-State: APjAAAUAcd9vd9n/WjnWamQem4vk/47HU+7ZFGH8fMo7cSXRlljBI6Se Og8Y9LynD87xjf3XLXRiPMd9dd4HJvZXqMPAmlUFhhWkVxk= X-Google-Smtp-Source: APXvYqwna5PsqU24IBmoRuy79OC3b3ztwkZt5RZ5itk9JCtvNd98AFij7p+Ls9FFlKcobyo04uOOKH22msSQiVfAYE4= X-Received: by 2002:a1f:7d88:: with SMTP id y130mr12735650vkc.71.1572904806790; Mon, 04 Nov 2019 14:00:06 -0800 (PST) MIME-Version: 1.0 From: Jonathan Hoyland Date: Mon, 4 Nov 2019 21:59:55 +0000 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000463b4105968c70c7" Archived-At: Subject: [TLS] TLS 1.3 Extended Key Schedule X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 22:00:16 -0000 --000000000000463b4105968c70c7 Content-Type: text/plain; charset="UTF-8" Hi TLSWG, Chris and I have put together a draft for adding extra key material into the TLS 1.3 handshake. There are various drafts that want to inject extra information into the key schedule, so it would be great if we could manage to do this in a generic way. You can have a look here . The usual -00 caveats apply, so feedback and PRs are welcome on Github . Regards, Jonathan --000000000000463b4105968c70c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi TLSWG,

Chris and I have put together= a draft for adding extra key material into the TLS 1.3 handshake.=C2=A0

There are various drafts that want to inject extra i= nformation into the key schedule, so it would be great if we could manage t= o do this in a generic way.=C2=A0

You can have a l= ook here.=C2=A0

The usual -00 caveat= s apply, so feedback and PRs are welcome on Github.=C2=A0
<= br>
Regards,

Jonathan
--000000000000463b4105968c70c7-- From nobody Mon Nov 4 14:14:02 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8442120928 for ; Mon, 4 Nov 2019 14:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 WK5C-zFpF3ao for ; Mon, 4 Nov 2019 14:13:56 -0800 (PST) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 E1C01120AD8 for ; Mon, 4 Nov 2019 14:13:55 -0800 (PST) Received: by mail-il1-x132.google.com with SMTP id m5so7193692ilq.0 for ; Mon, 04 Nov 2019 14:13:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=hc6uR+hhhulw0E3yRw+Iw6owo2i0wKl2f377MKmgIIE=; b=uymYxANAqb8SnkKYMoKXBJ5NCp1iITaLkXtstf+E2jRo4+5qkJ1a2kxtPzuE7VfatT Y5x/CCtN8G+iJp25cYjWmXJ/JFDw/6Fun3rTRdwsRZlLgHi6VHAW8KWIN7zyDfXEQXs6 dO5ZfMd6TtIVLTdYXU5KZfqUxuVMrbdVB6uuw8agPNtkDQUPfiDaGIPtFDHxoVIAG5GK oHIfgqXlCRdMnDyar8YEiq2xQioYp8KnkvpuwPUsC7Yal0AJN3p+hRGDH096T03oF8F6 umRm8hGGgR1AMrZOoEa4N7DFtHXx/fDV3uxyqogNGRRnBylLpdZ2J+mAKWylpa7hRKeq BmjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hc6uR+hhhulw0E3yRw+Iw6owo2i0wKl2f377MKmgIIE=; b=Qd6a/SUWy0M5yne8ELuCUNugcNXQd6TQeXZpkKpRWtLYF//Cn8wvFOrS9aPDvSa/id Yly6/2j1DVBZvt11M2XjZOKHkfvzTPmvnt+Uw8V7EsWYl0TGN2faMMfeFaWZgnnzrfwt UVZhsy5hLRR5Ib4IC0h68NIRDSZDQC75zRFVOT8ikde+SwSONQ7hge0PYMiAtR9bq7HW zl/lC5ebLxES5qcdPZpbO8oVf70sj13W9kzu2rSURvLvdnCYOf/s3M7OqiekI3ji6vR3 hROmJKyUwUKhLPkxH8r9LOdCs68JCRHKjm25WQ9c2XqOH6wedj/hRWU+vqTQghR4U3w6 MZhA== X-Gm-Message-State: APjAAAU2B4aEBDhboaB4Q4t48qs+Ccq/gU2FpeSzOFdGMfWGXOmg9dWD GQZ3++iFUWShZSUY1qFvnIBSlS+niqfXxyS1qjwBJ9fP4Lg= X-Google-Smtp-Source: APXvYqxbUX7eBrfQRdu6ngcySpi85m5hYcRzzNQ/pFKzdCO5xaHUcpOE41vnK+ZQdEoOeCg9T2aNLv1I6/MTR4LTBNE= X-Received: by 2002:a92:3a88:: with SMTP id i8mr14359324ilf.254.1572905634538; Mon, 04 Nov 2019 14:13:54 -0800 (PST) MIME-Version: 1.0 From: Rob Sayre Date: Mon, 4 Nov 2019 14:13:43 -0800 Message-ID: To: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009ca9aa05968ca181" Archived-At: Subject: [TLS] comment on draft-ietf-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 22:14:02 -0000 --0000000000009ca9aa05968ca181 Content-Type: text/plain; charset="UTF-8" Hi, I left a comment wondering how this draft might interact with security issues in the network layer, like the various kinds of BGP hijacking. https://github.com/tlswg/tls-subcerts/issues/42 That's not to say this draft is the place to fix those problems, but it seems like it could make them more difficult to detect in some ways. I was surprised not to see this issue at least mentioned in the Security Considerations section. If I'm wrong to suspect this is a concern, it might be helpful to note why that is. thanks, Rob --0000000000009ca9aa05968ca181 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I left a comment wondering how = this draft might interact with security issues in the network layer, like t= he various kinds of BGP hijacking.


That's not to say th= is draft is the place to fix those problems, but it seems like it could mak= e them more difficult to detect in some ways. I was surprised not to see th= is issue at least mentioned in the Security Considerations section.

If I'm wrong to suspect this is a concern, it might b= e helpful to note why that is.

thanks,
R= ob

--0000000000009ca9aa05968ca181-- From nobody Mon Nov 4 14:25:45 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A782120BA9; Mon, 4 Nov 2019 14:25:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157290634018.13936.3003115900597951412@ietfa.amsl.com> Date: Mon, 04 Nov 2019 14:25:40 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-exported-authenticator-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2019 22:25:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Exported Authenticators in TLS Author : Nick Sullivan Filename : draft-ietf-tls-exported-authenticator-10.txt Pages : 13 Date : 2019-11-04 Abstract: This document describes a mechanism in Transport Layer Security (TLS) for peers to provide a proof of ownership of a certificate. This proof can be exported by one peer, transmitted out-of-band to the other peer, and verified by the receiving peer. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-10 https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticator-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-exported-authenticator-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 5 08:05:14 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7253C12011C for ; Tue, 5 Nov 2019 08:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 I4I8Sk7wL5Er for ; Tue, 5 Nov 2019 08:05:10 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 D1D011200FA for ; Tue, 5 Nov 2019 08:05:08 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id q70so21566019qke.12 for ; Tue, 05 Nov 2019 08:05:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=Mv1aXxxE5PmytHb3MQdFZVxnnhK2ZgknvyhV0vx/3bc=; b=WD7X0sr4sPoJaq+qqlu7jfy2/xMzJQzR+NhClq5joAe5sbhpBrYvs7N97JEaAGNNYK kVYgZuN0RqXoe0Hgl5/+WYbF6FGLzXmTGYxOIQM/TY7QjRvPwLsQ7cOAiNr9zXB/5lfa TxdfEeBftx1l+Caln9HJs4iyeRd+X7KTwjkkY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=Mv1aXxxE5PmytHb3MQdFZVxnnhK2ZgknvyhV0vx/3bc=; b=jcuuAsI1dcacSRXIqQc6KX8pCHoj+LyQXbIoyuWj5uQUeA7OXObYH+zd/m4cA0z6CG 18DDcJ3MaW1bgI76Bek0jgN7owODXbhvAAfOSvtfSV0BJZYVPpNREGfZFWQ8m5Fm+U5N 0w+8xvzKDmJo4YKaArwVuUsigoSehcFE2Dgkad0NpvMR/pNN2STz8tsnbeDHYELvFofl lglJlxVM89YdMhux41CUiGQuKhgNY0LVdImSGbQZhYdyCkQhbaQRxlgiuoi9L6R7R+99 y4FnpLFV00jYe9Eh9+e9ruW1rYGIZeKilr5ryqvjxseDRfK3z8TNMy0Vxh+q3Lw7esLv VxPg== X-Gm-Message-State: APjAAAWYME9rEM8P4ejdllN3nCIDsvsj1lPfUn191oxynmJU13wo3fnq RBoxNj01OrQNUfUIc87yJA2ug+c0Jjg= X-Google-Smtp-Source: APXvYqx5J9gym86GSANQ3nFwqpSueBHEzHOTRC6ukQxo0rb37/5PsWf59CO0/xsPY4R9qXzH+QuaUQ== X-Received: by 2002:a05:620a:2eb:: with SMTP id a11mr3314166qko.265.1572969907370; Tue, 05 Nov 2019 08:05:07 -0800 (PST) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id 32sm3182191qth.16.2019.11.05.08.05.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Nov 2019 08:05:06 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> Date: Tue, 5 Nov 2019 11:05:05 -0500 To: TLS List X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 16:05:12 -0000 All, This is the working group last call for the "TLS Ticket Requests" draft = available at = https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/. Please = review the document and send your comments to the list by 2359 UTC on 19 = November 2019. Note the the GH repo for this draft can be found at: https://github.com/tlswg/draft-ietf-tls-ticketrequest Thanks - J&S= From nobody Tue Nov 5 08:36:20 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFA91200C3 for ; Tue, 5 Nov 2019 08:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 v6MFCjDc8j8F for ; Tue, 5 Nov 2019 08:36:17 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (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 41C6012001A for ; Tue, 5 Nov 2019 08:36:17 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xA5GWsbj012719; Tue, 5 Nov 2019 16:35:14 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=hBYLHzoQXyhvyBjTq/+eJcQx6W5O8SPW1NbqvWLB+xc=; b=PZ5sTPefAnECpaIeFdz3WhLGXfbEYw1bZydrkUznEmufkpuM99hCQTfZmdJ2j1/D6t1g /Un67X9i5QRFt+qrK3T2EVotSYzqv4TEu7ZzHReGhkOCPXQqGOcOVC33PCLBbW45mqrK JUHSYfHnsLUeXjHLARRodERb8JJ4m4OlF2MFZ88kUKcEF5rY67p2uCY7JCPFDgzA8n3w CwVtXrfGG2YIpno/m7JDC8E1ArycmzqVtH8k2/x6+w4+nLosgEiSSkcp4WfM1QtATDQP o6xq9WeG3e3MmLdQ/8TsOEW6VoQ1Nogz2oBpT2SG+ZTqdE17IPLwhi+wMQYTLdE4449g jQ== Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2w0yrmf2vp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 Nov 2019 16:35:14 +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 xA5GWfWs012545; Tue, 5 Nov 2019 11:35:12 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2w1552pbqx-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 05 Nov 2019 11:35:10 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 5 Nov 2019 11:34:09 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Tue, 5 Nov 2019 11:34:09 -0500 From: "Salz, Rich" To: Sean Turner , TLS List Thread-Topic: [TLS] WGLC for draft-ietf-tls-ticketrequests Thread-Index: AQHVk/LV6BLyV6ae/Em3DxCUJPqvVKd8xcsA Date: Tue, 5 Nov 2019 16:34:08 +0000 Message-ID: References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> In-Reply-To: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191103 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.75] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-05_06:, , 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=703 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1911050136 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-11-05_06:2019-11-05,2019-11-05 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 priorityscore=1501 suspectscore=0 phishscore=0 clxscore=1015 spamscore=0 mlxlogscore=707 adultscore=0 malwarescore=0 lowpriorityscore=0 mlxscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1911050136 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 16:36:19 -0000 SSByZWFkIGl0LiAgSSBzdXBwb3J0IGl0LiAgU2hpcCBpdC4NCg0K From nobody Tue Nov 5 12:29:03 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA067120B86 for ; Tue, 5 Nov 2019 12:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=BeLvPKcL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YNuqhF4n 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 kMkPMwGf3ofw for ; Tue, 5 Nov 2019 12:28:59 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FF09120B84 for ; Tue, 5 Nov 2019 12:28:58 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id ACEC521FFC for ; Tue, 5 Nov 2019 15:28:57 -0500 (EST) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Tue, 05 Nov 2019 15:28:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:subject:content-type :content-transfer-encoding; s=fm2; bh=oUCTsBxRKiRqa0Mm6NfYOLSvEf hn5NLf90ArTdpfJ4c=; b=BeLvPKcLKAnWQamMOG7fhEtqSU0FQzUp9MHn08Sm+B ur87Nv8RXW3g2HWvPnwYbUEqzMkFy+ngxdaxp3VEGEIs3woFdTvULITX/EI18izK GBWH1bKzK8R3Gr5C9BYgy0byr6a0dDPogxRixVlCMy/pS5eAQxiDEWn7tK3puRrl to7JRWEH+MoItOWfjSdw5vKFwT7VTq8D157QXn+fo7srv+0PmCEmE9WrAGdW0a+K fpdleoEwprz238WXDXGHdjGCpWuER2KYGwByv1BZGFm6u8f1cjC0GPAGqLaBFFRy O2rJ17NZyE9kYofqc7vfkGra5eSGZL9PCnG6rpBqQF2g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=oUCTsB xRKiRqa0Mm6NfYOLSvEfhn5NLf90ArTdpfJ4c=; b=YNuqhF4nWMIOCPkeWMo7VO mHFI+n49L/7Ab4RY55urhYTEWkwZ3Dgxc4L/J8KZo3TprhhyyE6/ZS6PVL4TyUBg Ysq8Li/c3a1gP0MoQYE1Q5h2KzEbTpFEazFdb5Drdxh+g/FQuH79+m1IsO7ZCjip 6+hfZEYLQkCFwa2ToQ6/EJSw+OSSSeaJUSyoEh9BHTyrIF+QOdcUJKQxPG5MeadX cs6JGjMhtF3JDoKkTUhZeA25ZqwhJxOszcx6FTIXzQpWJiw58CMxP16V0tkQFvcC C2oA+b6jhicuJEWC/3sldwK2RUHcPKqbTkaTFRlSYXvE0DUEol+ONuSfV5KhFKLA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduhedgudefkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepghhuvghsshdrtghomh dpghhithhhuhgsrdgtohhmnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggr phhinhhgsghithhsrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6D7723C00A1; Tue, 5 Nov 2019 15:28:57 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: <304108c8-e8cc-41a6-b931-d5c44cc812e4@www.fastmail.com> Date: Tue, 05 Nov 2019 12:28:24 -0800 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [TLS] Proposals to address ESNI issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 20:29:02 -0000 Hi folks, Since Montreal, a few people have been working on the protocol issues th= at currently exist in draft-ietf-tls-esni-05. To recap, here are the pro= blems we=E2=80=99re aware of: 1. Server Reaction Attacks. Servers that associate SNIs with tickets may= lead to dictionary attacks. An example is shown below. Adv connects to = S with a guess domain guess.com and receives a ticket. Upon receiving a = CH (with ESNI) from a victim client without any PSK, Adv attaches its ti= cket and binder to the CH, and forwards it to S. If S checks whether the= ESNI in the CH matches that of the ticket and proceeds or aborts accord= ingly, Adv can learn whether or not its guess -- the SNI of the ticket -= - matches that of the ESNI.=20 2. HRR Binding Check Failure. If a server decrypts ESNI upon receiving C= H and then stores it even when it sends, HRR, then an on-path attacker c= an intercept theHRR message, and swapping in its own KeyShare and (valid= ) ESNI blob. If the server fails to check that the ESNI value from the s= econd CH matches that of the first CH.=20 3. Probing Attacks. An on-path adversary changes fields in a ClientHello= not bound to the ESNI extension and observes server behavior. If server= s have different cryptographic configurations based on SNI, this lets an= adversary learn the SNI from the server=E2=80=99s choice of parameters.= The attacks on ESNI security above seem to stem from two problems:=20 1. The ESNI contents are not fully bound to the ClientHello contents. If= this were not the case, attackers would not be able to modify ClientHel= lo messages, either by appending ticket (binders) or swapping ciphersuit= es or other parameters. 2. The handshake secrets are not bound to the ESNI contents. If this wer= e not the case, servers could not choose attacker-controlled keying mate= rial yet proceed with victim-controlled parameters (SNIs).=20 We try to capture these problems in the following definitions of =E2=80=9C= forward=E2=80=9D and =E2=80=9Cbackward=E2=80=9D binding. We say ESNI con= tents are forward-bound to a handshake if it is not possible to decrypt = handshake messages without both the handshake shared secret and ESNI sha= red secret (or a value protected by the ESNI shared secret, such as the = nonce). Likewise, we say ESNI contents are backward-bound to a ClientHel= lo if it is not possible to modify a CH in any way without causing ESNI = decryption. To give ourselves confidence that these are indeed necessary for ESNI se= curity (assuming other obvious properties such as =E2=80=9Cconsistent cr= yptographic configuration [2]=E2=80=9D), we worked with Karthik Barghava= n to model a simplified variant of TLS 1.3 with ESNI in ProVerif. A writ= eup of the *preliminary* model and our findings is available at [1].=20 To satisfy these requirements, there are currently four different propos= als on the table: - ESNI encoder/decoder [3]: Add encoding/decoding layer between client a= nd client-facing server that translates a =E2=80=9Cpublic=E2=80=9D CH in= to a =E2=80=9Cprivate=E2=80=9D CH (and back), requiring servers to choos= e one of these CHs to complete the handshake. - Tunnel CH [4]: Encrypt a =E2=80=9Cprivate=E2=80=9D CH under the server= =E2=80=99s ESNI key and include it as an extension in an outer =E2=80=9C= public=E2=80=9D CH, requiring servers to choose one of these CHs to comp= lete the handshake. - ESNI PSK binding with key schedule injection [5]: Bind CH contents to = ESNI via a unique PSK identity (backward binding), and bind the key sche= dule to the ESNI contents (forward binding). - ESNI with external PSK import and key schedule injection [6]: Same as = above, except bind ESNI to the ClientHello using the external PSK import= er API.=20 We modelled #2 (Tunnel CH) and #3 (key schedule injection) and to give u= s confidence in each design. (Note that #1 and #4 are variants of #2 and= #3, respectively.) (And we are actively extending these models to impro= ve our confidence.) Please have a close look at the above PRs and weigh in. We=E2=80=99d lik= e to reach consensus on one design during (or before) Singapore.=20 Thanks, Chris (on behalf of the authors) [1] https://github.com/chris-wood/encrypted-sni-model/blob/master/stable= /esni_analysis_00.pdf [2] https://github.com/tlswg/draft-ietf-tls-esni/issues/178 [3] https://github.com/kazuho/draft-rescorla-tls-esni/pull/1 [4] https://github.com/tlswg/draft-ietf-tls-esni/pull/196 [5] https://github.com/tlswg/draft-ietf-tls-esni/pull/197 [6] https://github.com/chris-wood/draft-ietf-tls-esni/pull/9 From nobody Tue Nov 5 12:35:27 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F4E120B73 for ; Tue, 5 Nov 2019 12:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=AF6c5PcG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cD+5GV9U 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 S5GIautHRKOZ for ; Tue, 5 Nov 2019 12:35:23 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BBF7120B87 for ; Tue, 5 Nov 2019 12:35:21 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 7F04D2206E for ; Tue, 5 Nov 2019 15:35:20 -0500 (EST) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Tue, 05 Nov 2019 15:35:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=sRkkE ZG1i1xzf9iChEcGU24YzeZS+ptlPBBlHkDCjV0=; b=AF6c5PcGaqe9CI9pKKoMw I6o1WMwVuqUx9Ana1w0ngrx4lO1wd6PHOxbC2wTMT8fGTBmZX6cHc58U/9p7UzTl o5Zm+NC2Xh+ivc3yrmCDtGBAX8XQ7kzWN7v1tI1LkAIHtlYRe/EqGd/4uzt2FMEv ls5oYBtDxvgXAp1QHrqt9KUrH3Y3jH3oJu1A+rDMGHo0ugBXv610KjndH8isHLUE TRrUlHpLge2dn8UQMlH0IwX+kPg/oddFQv2izr75pXQrvsCSJrrTXoOJWfOiw5YH RdQAedQuCCkdr1M6hvEZDiQCinnZlZRxSudlOLswbL6Rr/1M35qM5EArUjgptDcP w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=sRkkEZG1i1xzf9iChEcGU24YzeZS+ptlPBBlHkDCj V0=; b=cD+5GV9URV/bgtih8XCZLPgnyWEZZXq7b4LkE/0gO9Vm8TiNlntKlr9Ki ytEnnRQHfYv30M0ahby3hmC4cts6Vqt5p08hDCo+CpiFkGnXl1Bz9Hx0epqX8Vlf IdDHpj4OLgfZAfw55L60g8QjutyXeSDIxAppok+PbOio56tAmiQrlDXw9ZTpapKw 7dpz3O/L8IrWnFVSBxXDbZXeKWsrh4rL171NEHz3RQP+uUe9DfMOMqecwVyQnLsb xEkwb7v54mzf7IjsZAIMYulj9F/xj0Kxt8CqhV6fRHDlAwObLSIUNoJ74YC9qr7q 44Tj50bk5k4/uITtUN5zw3k8JSzDQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduhedgudeflecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgse htqhertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegt rgifsehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepghhuvghsshdrtg homhdpghhithhhuhgsrdgtohhmpdhivghtfhdrohhrghenucfrrghrrghmpehmrghilhhf rhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvthenucevlhhushhtvghrufhiii gvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 43B263C00A2; Tue, 5 Nov 2019 15:35:20 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <304108c8-e8cc-41a6-b931-d5c44cc812e4@www.fastmail.com> References: <304108c8-e8cc-41a6-b931-d5c44cc812e4@www.fastmail.com> Date: Tue, 05 Nov 2019 12:34:59 -0800 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Proposals to address ESNI issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 20:35:26 -0000 On Tue, Nov 5, 2019, at 12:28 PM, Christopher Wood wrote: > Hi folks, >=20 > Since Montreal, a few people have been working on the protocol issues=20= > that currently exist in draft-ietf-tls-esni-05. To recap, here are the= =20 > problems we=E2=80=99re aware of: >=20 > 1. Server Reaction Attacks. Servers that associate SNIs with tickets=20= > may lead to dictionary attacks. An example is shown below. Adv connect= s=20 > to S with a guess domain guess.com and receives a ticket. Upon=20 > receiving a CH (with ESNI) from a victim client without any PSK, Adv=20= > attaches its ticket and binder to the CH, and forwards it to S. If S=20= > checks whether the ESNI in the CH matches that of the ticket and=20 > proceeds or aborts accordingly, Adv can learn whether or not its guess= =20 > -- the SNI of the ticket -- matches that of the ESNI.=20 >=20 > 2. HRR Binding Check Failure. If a server decrypts ESNI upon receiving= =20 > CH and then stores it even when it sends, HRR, then an on-path attacke= r=20 > can intercept theHRR message, and swapping in its own KeyShare and=20 > (valid) ESNI blob. If the server fails to check that the ESNI value=20= > from the second CH matches that of the first CH.=20 >=20 > 3. Probing Attacks. An on-path adversary changes fields in a=20 > ClientHello not bound to the ESNI extension and observes server=20 > behavior. If servers have different cryptographic configurations based= =20 > on SNI, this lets an adversary learn the SNI from the server=E2=80=99s= choice=20 > of parameters. >=20 > The attacks on ESNI security above seem to stem from two problems:=20 >=20 > 1. The ESNI contents are not fully bound to the ClientHello contents.=20= > If this were not the case, attackers would not be able to modify=20 > ClientHello messages, either by appending ticket (binders) or swapping= =20 > ciphersuites or other parameters. > 2. The handshake secrets are not bound to the ESNI contents. If this=20= > were not the case, servers could not choose attacker-controlled keying= =20 > material yet proceed with victim-controlled parameters (SNIs).=20 >=20 > We try to capture these problems in the following definitions of=20 > =E2=80=9Cforward=E2=80=9D and =E2=80=9Cbackward=E2=80=9D binding. We s= ay ESNI contents are=20 > forward-bound to a handshake if it is not possible to decrypt handshak= e=20 > messages without both the handshake shared secret and ESNI shared=20 > secret (or a value protected by the ESNI shared secret, such as the=20= > nonce). Likewise, we say ESNI contents are backward-bound to a=20 > ClientHello if it is not possible to modify a CH in any way without=20= > causing ESNI decryption. >=20 > To give ourselves confidence that these are indeed necessary for ESNI=20= > security (assuming other obvious properties such as =E2=80=9Cconsisten= t=20 > cryptographic configuration [2]=E2=80=9D), we worked with Karthik Barg= havan=20 Correction: Karthik Bhargavan (my sincerest apologies for the typo, Kart= hik!) > to model a simplified variant of TLS 1.3 with ESNI in ProVerif. A writ= eup=20 > of the *preliminary* model and our findings is available at [1].=20 >=20 > To satisfy these requirements, there are currently four different=20 > proposals on the table: >=20 > - ESNI encoder/decoder [3]: Add encoding/decoding layer between client= =20 > and client-facing server that translates a =E2=80=9Cpublic=E2=80=9D CH= into a =E2=80=9Cprivate=E2=80=9D=20 > CH (and back), requiring servers to choose one of these CHs to complet= e=20 > the handshake. > - Tunnel CH [4]: Encrypt a =E2=80=9Cprivate=E2=80=9D CH under the serv= er=E2=80=99s ESNI key and=20 > include it as an extension in an outer =E2=80=9Cpublic=E2=80=9D CH, re= quiring servers=20 > to choose one of these CHs to complete the handshake. > - ESNI PSK binding with key schedule injection [5]: Bind CH contents t= o=20 > ESNI via a unique PSK identity (backward binding), and bind the key=20= > schedule to the ESNI contents (forward binding). > - ESNI with external PSK import and key schedule injection [6]: Same a= s=20 > above, except bind ESNI to the ClientHello using the external PSK=20 > importer API.=20 >=20 > We modelled #2 (Tunnel CH) and #3 (key schedule injection) and to give= =20 > us confidence in each design. (Note that #1 and #4 are variants of #2=20= > and #3, respectively.) (And we are actively extending these models to=20= > improve our confidence.) >=20 > Please have a close look at the above PRs and weigh in. We=E2=80=99d l= ike to=20 > reach consensus on one design during (or before) Singapore.=20 >=20 > Thanks, > Chris (on behalf of the authors) >=20 > [1]=20 > https://github.com/chris-wood/encrypted-sni-model/blob/master/stable/e= sni_analysis_00.pdf > [2] https://github.com/tlswg/draft-ietf-tls-esni/issues/178 > [3] https://github.com/kazuho/draft-rescorla-tls-esni/pull/1 > [4] https://github.com/tlswg/draft-ietf-tls-esni/pull/196 > [5] https://github.com/tlswg/draft-ietf-tls-esni/pull/197 > [6] https://github.com/chris-wood/draft-ietf-tls-esni/pull/9 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Nov 5 13:58:05 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EA912008F for ; Tue, 5 Nov 2019 13:58:04 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 w9phLDba4PXq for ; Tue, 5 Nov 2019 13:58:02 -0800 (PST) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 450A2120018 for ; Tue, 5 Nov 2019 13:57:59 -0800 (PST) Received: by mail-il1-x12f.google.com with SMTP id n18so12731946ilt.9 for ; Tue, 05 Nov 2019 13:57:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+k7fzRulxnryDUypUNmQNOzumN5OhKMyMmfdF7d7JPk=; b=oJ8AioudgJL/qCRuKN588ZNGZV3Y37LcgixebLEBRk2Qh/t55GUY+Br5XbKCdM2OUu qxYZOk8+INI2GRzLz7CplILw0b/F+qLyn19GkfIQjsdrdOQEoXSb59EyynjO1NpHPXr5 WUoDgGJfTpQOblPJtpj1KA7omXex4aRX0OZHtCecUy9/A4vzIsnq2eRtTT9bpoJzJ/7H EMNUzayOqZCFAKFp8/9QG21ACPnOt14fBWCIOpBCqkoBzSSzQp1Noa5avvHobOHbz0Br ZtloLEP64orrPpvxmpoTuq34of08HHX8acnqHxfPqnzwCXJA48feaLMJYIuwYAQTVJPg P62g== 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=+k7fzRulxnryDUypUNmQNOzumN5OhKMyMmfdF7d7JPk=; b=M1UWDeIQlpL0ISIw1Uw4aV7kWZIni+zsLHKS56DZiYjJAEsqHjp+0We6NQzm8nesTQ /fPC8TxeVsgxKA1QDuuujk7qrGxrxjcFazkLYPHSey/rIKPGFV5bBLJJmm+ihStKSlpk nrMCm3z88ChKovKQvHuKbNNAP0HJBIPwb9XB0O87yyki21I8yo3pq0TsgiE8Z2VreaXe Xnuy4C5YO50NmrFrnfqRTtadyUKhViwggOZ8fvHmUPfGzhw/vTML0s5XP2F8jLhqcq2w 0Eq1EA1Qofnv+QXiWk9QbJIPxG1Q3dx7BBcN9/ckNI5TmX5XCAyBM5iC/SW4tYFwZmRV mUhw== X-Gm-Message-State: APjAAAXxG4siVH/fa7ah70AIoNHcf/0jiYJ5YJyJv/xaUV0/Xa6L61c8 0XS49jfSGUxKi26yEpNQTL9N0zz5nIstpOpvjeO1msBD/1U= X-Google-Smtp-Source: APXvYqyP1ggbWfJPiml2TO5sSq0ahgIX/fTcw28wDl6K7kQuIq/xFYkFbzASWr3ZujRMeNdZp1wAVGg1pjLEml9Gh1c= X-Received: by 2002:a92:8388:: with SMTP id p8mr15714070ilk.49.1572991078409; Tue, 05 Nov 2019 13:57:58 -0800 (PST) MIME-Version: 1.0 References: <304108c8-e8cc-41a6-b931-d5c44cc812e4@www.fastmail.com> In-Reply-To: From: Rob Sayre Date: Tue, 5 Nov 2019 13:57:45 -0800 Message-ID: To: Christopher Wood Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000076ac880596a086f2" Archived-At: Subject: Re: [TLS] Proposals to address ESNI issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 21:58:04 -0000 --00000000000076ac880596a086f2 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 5, 2019 at 12:35 PM Christopher Wood wrote: > > > > The attacks on ESNI security above seem to stem from two problems: > > > > 1. The ESNI contents are not fully bound to the ClientHello contents. > This seems right to me. I was surprised that the current ESNI drafts only require the "KeyShareClientHello" as AAD input to the AEAD-Encrypt function. Additionally, I've raised the point that even that arrangement seems to imply that the client's key share message should appear before the ESNI, or that the server must perform some input buffering. Perhaps a variation on the "Tunnel CH" idea is in order: require that an "Encrypted Client Hello" is the last extension in a ClientHello message. > > 2. The handshake secrets are not bound to the ESNI contents. If this > were not the case, servers could not choose attacker-controlled keying > material yet proceed with victim-controlled parameters (SNIs). > I had a hard time parsing this point. Doesn't the current protocol require echoing some encrypted content? I think the draft might need to address the case where servers ignore the SNI and ESNI messages. Maybe that's the idea: build this requirement into the handshake. It wasn't clear to me from the email, though. thanks, Rob --00000000000076ac880596a086f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 5, 2019 at 12:35 PM Christoph= er Wood <caw@heapingbits.net&= gt; wrote:
>
> The attacks on ESNI security above seem to stem from two problems: >
> 1. The ESNI contents are not fully bound to the ClientHello contents. =

This seems right to me. I was surprise= d that the current ESNI drafts only require the "KeyShareClientHello&q= uot; as AAD input to the AEAD-Encrypt function. Additionally, I've rais= ed the point that even that arrangement seems to imply that the client'= s key share message should appear before the ESNI, or that the server must = perform some input buffering.

Perhaps a variation = on the "Tunnel CH" idea is in order: require that an "Encryp= ted Client Hello" is the last extension in a ClientHello message.

=C2=A0
> 2. The handshake secrets are not bound to the ESNI contents.=C2=A0If t= his were not the case, servers could not choose attacker-controlled keying = material yet proceed with victim-controlled parameters (SNIs).

I had a hard time parsing this point. Doesn't t= he current protocol require echoing some encrypted content? I think the dra= ft might need to address the case where servers ignore the SNI and ESNI mes= sages. Maybe that's the idea: build this requirement into the handshake= . It wasn't clear to me from the email, though.

thanks,
Rob

--00000000000076ac880596a086f2-- From nobody Tue Nov 5 14:15:45 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6393A120C69 for ; Tue, 5 Nov 2019 14:15:40 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 EOlx9V6zZ5JV for ; Tue, 5 Nov 2019 14:15:38 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 4E13B120C7E for ; Tue, 5 Nov 2019 14:15:35 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id b20so16367169lfp.4 for ; Tue, 05 Nov 2019 14:15:35 -0800 (PST) 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=VMSz41wThLUi5xA9ABDLJTGF3qxOc9P5nwVdUJikxfI=; b=oHwUVcqabDvof9AH02GtoIQoolihhCSu8VYjGPi04nRO+NRow2NtscIEzQT1alwtBr 3NJh84LEnGAwclTl3FpX9HzOlPmcB4UZZ0jynZLYbQqNe1nOoVgITu5FMsjmFigeeJJ5 13EQzeBnibVD8hdcEUS9VeeplPlsoWkJ4HX146uiZSEmb+IiGeWtiUF8sMJUYXHwCH6p gajppBGaFqgzyl+vrQyUGcqkBMYc4FGNr8mSyaxboD0gRa/Qc/N+QvF1sxElsvjToKKy sooZZ8Xj+Yzxhf3vE0PD7x76dnDWGz76Z0dYqwgg5Dx4gjrbc9F/vyNcpbpTxr8eY75s m2qg== 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=VMSz41wThLUi5xA9ABDLJTGF3qxOc9P5nwVdUJikxfI=; b=F4fewNUKXAOmXq96wsVi7NiXrwTznvQAWHUoR+/A2A526x8fl6OaN2+EmHhcJDLbGi T+fZS8EimhA1JSbxOaeOiaYK8ZYtAA4LSa1D4nvbN1OsPTHHIp5owpDywd6DmE1K/q8w 56Jur/gwrXCKsHU4T1DBwytjCAkASU3G7RE/BelxGgONZeg45BKmMnRXoNnH/+1zV01f QkOMKpEDHxFaCA+kMe69GhKVTPZrFsaq10OpPrWvreeu0mh4EPZED2/Tnnhke0YVqIqe c+b98UPX+tLtnsldQzju7UHiuAKkx7nCPk7PL34h132NDBnSjv1yRC7MvXqEl2A1W3au nY0A== X-Gm-Message-State: APjAAAWBukjTYHHv7xbSZUioB2PL27xBgxREGQ0+lOhFX01ksE5IrO8b H/aXLUvvdg1w/g/eIIH9dQNx/B2/d9YvH6ZS8pKEEA== X-Google-Smtp-Source: APXvYqy1xFEa9CxlxXOxerP+1EgqrsqPTgQmqtQTKn5q0fn7xWeCV+PK20AwnACYo4VRoY/T7smPZzeXw1sbMJ4GMD0= X-Received: by 2002:a05:6512:75:: with SMTP id i21mr6549544lfo.180.1572992133602; Tue, 05 Nov 2019 14:15:33 -0800 (PST) MIME-Version: 1.0 References: <304108c8-e8cc-41a6-b931-d5c44cc812e4@www.fastmail.com> In-Reply-To: From: Eric Rescorla Date: Tue, 5 Nov 2019 14:14:57 -0800 Message-ID: To: Rob Sayre Cc: Christopher Wood , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005bbe480596a0c544" Archived-At: Subject: Re: [TLS] Proposals to address ESNI issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 22:15:44 -0000 --0000000000005bbe480596a0c544 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 5, 2019 at 1:58 PM Rob Sayre wrote: > On Tue, Nov 5, 2019 at 12:35 PM Christopher Wood > wrote: > >> > >> > The attacks on ESNI security above seem to stem from two problems: >> > >> > 1. The ESNI contents are not fully bound to the ClientHello contents. >> > > This seems right to me. I was surprised that the current ESNI drafts only > require the "KeyShareClientHello" as AAD input to the AEAD-Encrypt > function. Additionally, I've raised the point that even that arrangement > seems to imply that the client's key share message should appear before the > ESNI, or that the server must perform some input buffering. > > Perhaps a variation on the "Tunnel CH" idea is in order: require that an > "Encrypted Client Hello" is the last extension in a ClientHello message. > This wouldn't change the situation in the tunnel CH, because ClientHelloInner does not depend at all on the outer part of the CH. > >> > 2. The handshake secrets are not bound to the ESNI contents. If this >> were not the case, servers could not choose attacker-controlled keying >> material yet proceed with victim-controlled parameters (SNIs). >> > > I had a hard time parsing this point. Doesn't the current protocol require > echoing some encrypted content? > Yes, but that doesn't affect the HRR splicing attack. This is laid out in S 2.2 of the document Chris forwarded. I think the draft might need to address the case where servers ignore the > SNI and ESNI messages. > I'm not sure what you mean by "address" this case. The purpose of the nonce checking is to detect when ESNI was not processed. -Ekr > thanks, > Rob > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000005bbe480596a0c544 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 5, 2019 at 1:58 PM Rob Sa= yre <sayrer@gmail.= com> wrote:
On Tue, Nov 5, 2019 at 12:35 PM Christ= opher Wood <caw= @heapingbits.net> wrote:
>
> The attacks on ESNI security above seem to stem from two problems: >
> 1. The ESNI contents are not fully bound to the ClientHello contents. =

This seems right to me. I was surprise= d that the current ESNI drafts only require the "KeyShareClientHello&q= uot; as AAD input to the AEAD-Encrypt function. Additionally, I've rais= ed the point that even that arrangement seems to imply that the client'= s key share message should appear before the ESNI, or that the server must = perform some input buffering.

Perhaps a variation = on the "Tunnel CH" idea is in order: require that an "Encryp= ted Client Hello" is the last extension in a ClientHello message.

This wouldn't change the = situation in the tunnel CH, because ClientHelloInner does not depend at all= on the outer part of the CH.


=C2=A0
> 2. The handshake secrets are not bound to the ESNI contents.=C2=A0If t= his were not the case, servers could not choose attacker-controlled keying = material yet proceed with victim-controlled parameters (SNIs).

I had a hard time parsing this point. Doesn't t= he current protocol require echoing some encrypted content?

Yes, but that doesn't affect the HRR= splicing attack. This is laid out in S 2.2 of the document Chris forwarded= .


I think t= he draft might need to address the case where servers ignore the SNI and ES= NI messages.

I'm not = sure what you mean by "address" this case. The purpose of the non= ce checking is to detect when ESNI was not processed.

<= div>
-Ekr


thanks,
Rob

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000005bbe480596a0c544-- From nobody Tue Nov 5 14:32:20 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DB71200CC for ; Tue, 5 Nov 2019 14:32:18 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 MD5Qzb5fyzap for ; Tue, 5 Nov 2019 14:32:16 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69321120025 for ; Tue, 5 Nov 2019 14:31:25 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id g15so3197471iob.9 for ; Tue, 05 Nov 2019 14:31:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yGci1Y3a123LN8AXnoYUt+V/iNry5GmWAWJ/wlHxIfU=; b=Ktw8eAa2oL93KuOAM7Nu1j033vsaUb8zXlnbykxJxHuC1CfVS7xS9wHkOcF5WHul7Z 8l4nYki674cadUg3k985/WbeKUAqPE4rsUEc0gAjuOrV8wCEqAP+3AFarGJ4iMMQCrwU FPeikllcSWPhjK2Qzbdv/2F43orPitGwCrwEA07h+w4MAbqXnVh89LshnlFU2psyPm9h bJMwWkYA9Z4+kCDuYbq99Sd7IJVWOAH1KggOwD7u7tNHjqQ34nw9nFIXL5pScim3ILJz F+Y+T8Ta7Ir8/qgOqfHWzbgsrgxS/LDMJMtYGiqoBtb2ODI7LNvUfgAtQfpj8eOOJkRu HBVQ== 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=yGci1Y3a123LN8AXnoYUt+V/iNry5GmWAWJ/wlHxIfU=; b=tlTbx8GcOxNwou4x5yvOlVl+QQDog2Zs0Th+mlYSZUX51aJ0t5DtzUH3uwV4/xv2xF HK/+/kJFl0dB6P9z6h3488TsuEsPyLGroKBQHn8uKZYVgS7exP/2n8VwtyeGYCI4Iwlp mOCPbDs6u0lx/L91jZKMmZygz4aX8HgdTWmu/4LJmvlzpzsgbBg8NAWXVo2Q8G2zOV8B J8/AK2inaq9Jx21x+mvZRoce/ZuKMSqUrpI9EgflSaw2PO2T6QvbQpg88vFz7uUP2yI2 kYUTfFW0NWhqRGIIlyb0oi0bEEKGpooIm3G+4xJ3cbDDQSD4M8HNdHV3V6yCzghtT5vp pf3g== X-Gm-Message-State: APjAAAXMTaMNeZjOFmAHw9n3v7PZ9SD1p2nawznRl1L5wUvgmB8vKQL1 OEGJ/kx8V7BH3Qjft5gCztWsGkffPqK+Ia2f91M= X-Google-Smtp-Source: APXvYqyUSKT67ZuqiNKFWHf6h10+A9gqiEDBZGVrvU26pI5YQrr+HkY9X+62nhyEPHL6+2FwUywP+yP0TmECyi9/gVM= X-Received: by 2002:a02:82:: with SMTP id 124mr12341113jaa.131.1572993084511; Tue, 05 Nov 2019 14:31:24 -0800 (PST) MIME-Version: 1.0 References: <304108c8-e8cc-41a6-b931-d5c44cc812e4@www.fastmail.com> In-Reply-To: From: Rob Sayre Date: Tue, 5 Nov 2019 14:31:12 -0800 Message-ID: To: Eric Rescorla Cc: Christopher Wood , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000959320596a0fef1" Archived-At: Subject: Re: [TLS] Proposals to address ESNI issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 22:32:18 -0000 --0000000000000959320596a0fef1 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 5, 2019 at 2:15 PM Eric Rescorla wrote: > > > On Tue, Nov 5, 2019 at 1:58 PM Rob Sayre wrote: > >> On Tue, Nov 5, 2019 at 12:35 PM Christopher Wood >> wrote: >> >>> > >>> > The attacks on ESNI security above seem to stem from two problems: >>> > >>> > 1. The ESNI contents are not fully bound to the ClientHello contents. >>> >> >> This seems right to me. I was surprised that the current ESNI drafts only >> require the "KeyShareClientHello" as AAD input to the AEAD-Encrypt >> function. Additionally, I've raised the point that even that arrangement >> seems to imply that the client's key share message should appear before the >> ESNI, or that the server must perform some input buffering. >> >> Perhaps a variation on the "Tunnel CH" idea is in order: require that an >> "Encrypted Client Hello" is the last extension in a ClientHello message. >> > > This wouldn't change the situation in the tunnel CH, because > ClientHelloInner does not depend at all on the outer part of the CH. > I think my suggestion was that ClientHelloInner should depend on the outer part, by requiring that it be the last extension, and using all of the previous input in the AAD parameter. > > > >> >>> > 2. The handshake secrets are not bound to the ESNI contents. If this >>> were not the case, servers could not choose attacker-controlled keying >>> material yet proceed with victim-controlled parameters (SNIs). >>> >> >> I had a hard time parsing this point. Doesn't the current protocol >> require echoing some encrypted content? >> > > Yes, but that doesn't affect the HRR splicing attack. This is laid out in > S 2.2 of the document Chris forwarded. > Isn't the HRR attack detailed in that section of the PDF (attachment 0 in Chris's message) contingent on using only the "KeyShareClientHello" as input to the AAD? > I think the draft might need to address the case where servers ignore the >> SNI and ESNI messages. >> > > I'm not sure what you mean by "address" this case. The purpose of the > nonce checking is to detect when ESNI was not processed. > I've found that existing clients do not fail when the ESNI is not processed. Unfortunately, I discovered this by writing a buggy client. :) thanks, Rob --0000000000000959320596a0fef1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 5, 2019 at 2:15 PM Eric R= escorla <ekr@rtfm.com> wrote:
=


On Tue, Nov 5, 2019 at 1:58 PM Rob Sayre <sayrer@gmail.com> wrote:<= br>





--0000000000000959320596a0fef1-- From nobody Tue Nov 5 14:43:24 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67228120025 for ; Tue, 5 Nov 2019 14:43:23 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 v2fvtF8ZbS30 for ; Tue, 5 Nov 2019 14:43:21 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2385D120018 for ; Tue, 5 Nov 2019 14:43:21 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id v8so8134004ljh.5 for ; Tue, 05 Nov 2019 14:43:21 -0800 (PST) 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=ulZm1c7emA5NbSZ1APsZRbo775lakPWzJifiBUR9zo0=; b=C4kK+c6CAa2OHFYNCvv5tCiF+7X49s8DmhmWz259vtNskRvXitlw8ECyXqL/loKWMN 8n/pzfIr6YEF/eG5Du7HKZMMv/LvWnuWJDzPoK7J3FgKsHvRzXNQi58fV8QjeRFQCMGy ybDeq/FUu0DX4cTQPt5JpdadD4o/0PDKFqlsTxG8C8U4gr3qGtrQ7QAN3w8drQRbdHIv IogkZ6+hLDT23OKcfrS38CTtRAwWZdcKyckoSWBlybnqlIPk6QVuUedjWjuWnaExGYKF Vd0cPoTfGRNVPyrG+65FPBu/BPMdBz7SMppJXJumGRVRettPS+NVNwOFJNkUDaqiVQTj vXIA== 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=ulZm1c7emA5NbSZ1APsZRbo775lakPWzJifiBUR9zo0=; b=Wwo8uCIpcacSBDNCb6BNa95qkJjblOKBjb0xe7gmWZJjX3MhB4UfRqDhu+dpYEbKlh grv9Ggop4PPKWDQxn3lO92TUW9x1if5xI1z6V3TsCqttJAdCY5zmzSefjSx5zcMHwdam WRYcv0qkS6Dc4YSMGq0eFMf3znKi7b1BMVe9pWsmxtUgzw0qDdMjgNi6GUT8h8NbWMxz oORzbio0zx+T7ykLXvhJDR1dBULBbzDXHUW6wqsyXx4Wt2fpL8suoAMgZOdYyOFhUxJR vr8hWqgnuV/cCQ5wHUk6jO9CAqRE5OpROFhcBz7cYxBvgmHPcJDryPS0PD/DzO+2g/cY xoFg== X-Gm-Message-State: APjAAAUmqz9itTuZ6B274GptnV9sUpv19V7rvurLxoKoeEJ4OtTpUWXZ W4i+x5e+T0hDrH2yZN5S2oHSvwjlx0L3oAQsMUj0cQ== X-Google-Smtp-Source: APXvYqzO93u6FtzBgrR13EIWMmT7kMO2YUdevzxPit5DxoQjdWomee/6ZLtOFV+g0kIzEV9kCWN1JZNqvZB/EvS4aio= X-Received: by 2002:a2e:420a:: with SMTP id p10mr25788712lja.16.1572993799347; Tue, 05 Nov 2019 14:43:19 -0800 (PST) MIME-Version: 1.0 References: <304108c8-e8cc-41a6-b931-d5c44cc812e4@www.fastmail.com> In-Reply-To: From: Eric Rescorla Date: Tue, 5 Nov 2019 14:42:42 -0800 Message-ID: To: Rob Sayre Cc: Christopher Wood , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a4fedb0596a128fe" Archived-At: Subject: Re: [TLS] Proposals to address ESNI issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 22:43:23 -0000 --000000000000a4fedb0596a128fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 5, 2019 at 2:31 PM Rob Sayre wrote: > > > On Tue, Nov 5, 2019 at 2:15 PM Eric Rescorla wrote: > >> >> >> On Tue, Nov 5, 2019 at 1:58 PM Rob Sayre wrote: >> >>> On Tue, Nov 5, 2019 at 12:35 PM Christopher Wood >>> wrote: >>> >>>> > >>>> > The attacks on ESNI security above seem to stem from two problems: >>>> > >>>> > 1. The ESNI contents are not fully bound to the ClientHello contents= . >>>> >>> >>> This seems right to me. I was surprised that the current ESNI drafts >>> only require the "KeyShareClientHello" as AAD input to the AEAD-Encrypt >>> function. Additionally, I've raised the point that even that arrangemen= t >>> seems to imply that the client's key share message should appear before= the >>> ESNI, or that the server must perform some input buffering. >>> >>> Perhaps a variation on the "Tunnel CH" idea is in order: require that a= n >>> "Encrypted Client Hello" is the last extension in a ClientHello message= . >>> >> >> This wouldn't change the situation in the tunnel CH, because >> ClientHelloInner does not depend at all on the outer part of the CH. >> > > I think my suggestion was that ClientHelloInner should depend on the oute= r > part, by requiring that it be the last extension, and using all of the > previous input in the AAD parameter. > That doesn't exactly work because the PSK extension *also* has to be last. That's the reasoning for the injection + PSK approach, which is effectively this, except without duplicating the CH. However, in the tunnelling version, you ignore the outer ClientHello when you use the inner one, and so everything is bound together without requiring any specific ordering. > 2. The handshake secrets are not bound to the ESNI contents. If this were >>>> not the case, servers could not choose attacker-controlled keying mate= rial >>>> yet proceed with victim-controlled parameters (SNIs). >>>> >>> >>> I had a hard time parsing this point. Doesn't the current protocol >>> require echoing some encrypted content? >>> >> >> Yes, but that doesn't affect the HRR splicing attack. This is laid out i= n >> S 2.2 of the document Chris forwarded. >> > > Isn't the HRR attack detailed in that section of the PDF (attachment 0 in > Chris's message) contingent on using only the "KeyShareClientHello" as > input to the AAD? > No. In the HRR attack, the ESNI block is provided by the attacker. This is laid out in S 2.2. " his reveals the basic source of the problem: in order to prevent mix-and- match attacks on the client=E2=80=99s key share, the ESNI encryption binds = in gx. How- ever, if the server uses the SNI from first ClientHello and then the key share from the second ClientHello, which is attacker-controlled, then the attacker is free to generate their own ESNI extension containing a bogus ESNI and nonce. The server correctly verifies that these correspond to ga but because these are all supplied by the attacker, this check succeeds and the server encrypts the certificate to the attacker with a key known to the attacker." -Ekr > >> I think the draft might need to address the case where servers ignore th= e >>> SNI and ESNI messages. >>> >> >> I'm not sure what you mean by "address" this case. The purpose of the >> nonce checking is to detect when ESNI was not processed. >> > > I've found that existing clients do not fail when the ESNI is not > processed. Unfortunately, I discovered this by writing a buggy client. :) > -Ekr > thanks, > Rob > --000000000000a4fedb0596a128fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 5, 2019 at 2:31 PM Rob Sa= yre <sayrer@gmail.com> wrote:=


On Tue, Nov 5, 2019 at 2:15 PM Eric Rescorla <ekr@rtfm.com> wrote:<= br>


On Tue, Nov 5, 2019 at 1:58 PM Rob Sayre <sayrer@gmail.com> wro= te:
On Tue, Nov 5, 2019 at 12:35 PM Christopher Wood <= caw@heapingbits.ne= t> wrote:
>
> The attacks on ESNI security above seem to stem from two problems: >
> 1. The ESNI contents are not fully bound to the ClientHello contents. =

This seems right to me. I was surprise= d that the current ESNI drafts only require the "KeyShareClientHello&q= uot; as AAD input to the AEAD-Encrypt function. Additionally, I've rais= ed the point that even that arrangement seems to imply that the client'= s key share message should appear before the ESNI, or that the server must = perform some input buffering.

Perhaps a variation = on the "Tunnel CH" idea is in order: require that an "Encryp= ted Client Hello" is the last extension in a ClientHello message.

This wouldn't change the = situation in the tunnel CH, because ClientHelloInner does not depend at all= on the outer part of the CH.

I think my suggestion was that=C2=A0ClientHelloInner should depend= on the outer part, by requiring that it be the last extension, and using a= ll of the previous input in the AAD parameter.

That doesn't exactly work because the PSK extensi= on *also* has to be last. That's the reasoning for the injection=C2=A0 = + PSK approach, which is effectively this, except without duplicating the C= H.

However, in the tunnelling version, you ig= nore the outer ClientHello when you use the inner one, and so everything is= bound together without requiring any specific ordering.

=

> 2. The handshake secrets are not bound to the ESNI contents.=C2=A0If t= his were not the case, servers could not choose attacker-controlled keying = material yet proceed with victim-controlled parameters (SNIs).

I had a hard time parsing this point. Doesn't t= he current protocol require echoing some encrypted content?

Yes, but that doesn't affect the HRR= splicing attack. This is laid out in S 2.2 of the document Chris forwarded= .

Isn't the HRR a= ttack detailed in that section of the PDF (attachment 0 in Chris's mess= age) contingent on using only the "KeyShareClientHello" as input = to the AAD?

No. In the HR= R attack, the ESNI block is provided by the attacker. This is laid out in S= 2.2.

" =09 =09 his reveals the basic source = of the problem: in order to prevent mix-and- match attacks on the client=E2=80=99s key share, the ESNI encryption binds = in gx. How- ever, if the server uses the SNI from first ClientHello and then the key sh= are from the second ClientHello, which is attacker-controlled, then the attacke= r is free to generate their own ESNI extension containing a bogus ESNI and nonce= . The server correctly verifies that these correspond to ga but because these are all supplied by the attacker, this check succeeds and the server encrypts t= he certificate to the attacker with a key known to the attacker."<= /span>


-Ekr

= =C2=A0
I think the draft m= ight need to address the case where servers ignore the SNI and ESNI message= s.

I'm not sure what = you mean by "address" this case. The purpose of the nonce checkin= g is to detect when ESNI was not processed.
<= div>
I've found that existing clients do not fail when th= e ESNI is not processed. Unfortunately, I discovered this by writing a bugg= y client. :)



-Ekr


thanks,
Rob
--000000000000a4fedb0596a128fe-- From nobody Tue Nov 5 14:54:37 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13683120025 for ; Tue, 5 Nov 2019 14:54:35 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 4T_CGn1TPXfK for ; Tue, 5 Nov 2019 14:54:33 -0800 (PST) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 F29F8120018 for ; Tue, 5 Nov 2019 14:54:32 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id r144so24670302iod.8 for ; Tue, 05 Nov 2019 14:54:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CE+IuNw+7S5CRzWOOQkdYepSycoVvGpr4lyE7EagOIU=; b=R5h7Yv2I6Bymz+EJ9Y+cqct7k3hkFk3NVIhh6lAooil3EzIwF8LAkAYMrjxw5VbunP wHlv15KTK43iD/7oscWMhsb2gENumCpMNOjwZLtr4+J9o8ajU9opibWL5EuQBXJ/3ibo DDG/rJ+rrHskDultQh8VMI/8HGsEl6Z/8rc1oXWf2iTrEC9t4zxWeaE7Qw+lWu+81Y1c uDAcJE1FoXWm6Xj7hlaIHWiyF2Qng5zEPEAfscXRnBkJlR/Aq2JqpaX9FVK3NVQs+8Wx AKLkBch9QtyNgi/9Ru6bD4HbGCoAbtNPEICuozOknXEoOH5Zp36rFxbq3QADKk741o4m TfyQ== 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=CE+IuNw+7S5CRzWOOQkdYepSycoVvGpr4lyE7EagOIU=; b=X7JhZ7dafh/IQ3ArL8hWJbvcvnDtl1c/SJOAxJpTKkPlRNfY+OYsbhkk9IO9WKZOiZ eVv2ILbdl0l9XgxnW7VY/3XAz5dsE6u05aY2RLL+EE8/qNkhPr3yBCVFr49b1Ngm7b6z v9ohoCuOQdtWljtIuWGydT0ltOzBgl2jzZX7G/6FO+bVvZqg0bdB61+0ZXUqi4hLrc/P oz/paxIlmzDfISp68IVLyiYKLvqPRTSs/3DY72p2csjnVay+GJ7u3qXEtbpDw0gdD6J8 F9m4AWOWkR+brlYQrp1gVvKDypSjB7OkU4ZqOKcNpT/CgZlSTb5WPz0Vk3GmcLMivWbK Ef4Q== X-Gm-Message-State: APjAAAXsIA10GvGVwAnmDNLKSY42wPcs6FFN/Pfi5sg59rMMYXilAIan Mw2OYat26Yo0CJaIQf+XZUX1fRlUZ4ZsvsWpacA= X-Google-Smtp-Source: APXvYqwdPdxE99DprSxHldBqdqpfEl8cj6xSXfkRs7Cnp5EhqbVoO6dkiqGpXyNz8Hmg5i92dBut/iew3AcZDjfZAJg= X-Received: by 2002:a6b:400e:: with SMTP id k14mr6644127ioa.254.1572994472244; Tue, 05 Nov 2019 14:54:32 -0800 (PST) MIME-Version: 1.0 References: <304108c8-e8cc-41a6-b931-d5c44cc812e4@www.fastmail.com> In-Reply-To: From: Rob Sayre Date: Tue, 5 Nov 2019 14:54:19 -0800 Message-ID: To: Eric Rescorla Cc: Christopher Wood , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c079ad0596a1505d" Archived-At: Subject: Re: [TLS] Proposals to address ESNI issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2019 22:54:35 -0000 --000000000000c079ad0596a1505d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 5, 2019 at 2:43 PM Eric Rescorla wrote: > >> Isn't the HRR attack detailed in that section of the PDF (attachment 0 i= n >> Chris's message) contingent on using only the "KeyShareClientHello" as >> input to the AAD? >> > > No. In the HRR attack, the ESNI block is provided by the attacker. This i= s > laid out in S 2.2. > > " his reveals the basic source of the problem: in order to prevent > mix-and- match attacks on the client=E2=80=99s key share, the ESNI encryp= tion binds > in gx. How- ever, if the server uses the SNI from first ClientHello and > then the key share from the second ClientHello, which is > attacker-controlled, then the attacker is free to generate their own ESNI > extension containing a bogus ESNI and nonce. The server correctly verifie= s > that these correspond to ga but because these are all supplied by the > attacker, this check succeeds and the server encrypts the certificate to > the attacker with a key known to the attacker." > > Ok, maybe I have misread this section. It says: "and then the key share from the second ClientHello, which is attacker-controlled". Wouldn't including more of the initial ClientHello in the AAD parameter prevent this= ? thanks, Rob --000000000000c079ad0596a1505d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 5, 2019 at 2:43 PM Eric R= escorla <ekr@rtfm.com> wrote:

Isn't the H= RR attack detailed in that section of the PDF (attachment 0 in Chris's = message) contingent on using only the "KeyShareClientHello" as in= put to the AAD?

No. In th= e HRR attack, the ESNI block is provided by the attacker. This is laid out = in S 2.2.

" =09 =09 his reveals the basic source = of the problem: in order to prevent mix-and- match attacks on the client=E2=80=99s key share, the ESNI encryption binds = in gx. How- ever, if the server uses the SNI from first ClientHello and then the key sh= are from the second ClientHello, which is attacker-controlled, then the attacke= r is free to generate their own ESNI extension containing a bogus ESNI and nonce= . The server correctly verifies that these correspond to ga but because these are all supplied by the attacker, this check succeeds and the server encrypts t= he certificate to the attacker with a key known to the attacker."<= /span>


Ok, mayb= e I have misread this section.=C2=A0 It says: "and then the key share = from the second ClientHello, which is attacker-controlled". Wouldn'= ;t including more of the initial ClientHello in the AAD parameter prevent t= his?

thanks,
Rob=C2=A0
--000000000000c079ad0596a1505d-- From nobody Tue Nov 5 17:32:39 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F78D12022D for ; Tue, 5 Nov 2019 17:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=n1UmFEVF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hdrrWbbG 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 2G90pR69V_Bo for ; Tue, 5 Nov 2019 17:32:36 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09DF7120041 for ; Tue, 5 Nov 2019 17:32:33 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6394121A92 for ; Tue, 5 Nov 2019 20:32:32 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 05 Nov 2019 20:32:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=+IDzNGt4tsWe7Xm8GjsCdcSR1v1E2lM liQ5utTHUvFw=; b=n1UmFEVFHMYLuHBh4bisvrJ0r01fBfr05XOSekXuA24zaCu jQYTORI16p0KSstc3cOhA16cvpH2d3fywWoDNfVEuzA2fK0FKrbb6ggvblBn+JZa MIF0WIPEP/tMcL0XrXkszrcxtI3KxP/BJsA9BCXbZ/szol4/cFUBknUIBjV5w1g4 w7ZXh4BPp4wBnE0qNPpjm9l3zbAimAppomzTC7cMGeC4qs9tgQnQp1k+4t0qJfSo BIhinefyYQjKCDNml9VMyvXstN5mX87I6SEym0ebPqD0RjqSwv8BdKbI20zuw6g6 RlV0epVuMzxz8fwCzMzNVayG29BbWismxGuw2gQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=+IDzNG t4tsWe7Xm8GjsCdcSR1v1E2lMliQ5utTHUvFw=; b=hdrrWbbGLkrZzX046/6ZYL v/Apw9kxRDYXuWshuUY0OEn+g2h2UlUq0dptpWqYH7q4ZqZ4ekKhEoQokDh2WXe2 4kjaCq7qqhLS5ddLHpElxwCf1HVFzlRPyxjic+IrnC7uyek2A1RuHu6oAhozIbf6 HY3j5UlpFw/D01Lb9WBMw/a03bm1ytDVawSta0WwvZv7SpWmjoF7FZjwtTakwErX 17henCKIKYFYY821JN+XwiubqIJdZLlaKBtQP/O13VPv4Hl3Qc8M0p3sXo3hfqyi 8gX9z6iHi0RA/N7dfcMwJsNk7Obw2wHgICjI7zb8aqTgTIJwDmGHZEsp8f1VDzRw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduiedgfeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhivg htfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhp hidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2AF5FE00A3; Tue, 5 Nov 2019 20:32:32 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> In-Reply-To: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> Date: Wed, 06 Nov 2019 12:32:12 +1100 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2019 01:32:38 -0000 There was a lengthy discussion after the last time this was discussed. Can I request that an editor (or a chair) summarize that discussion and the resulting actions (if any)? I was involved in that discussion, but I don't see any changes from that. I'm totally OK with publication as-is, but I want to make sure that nothing got dropped. p.s., it might make sense to include some advisory text on prioritization of tickets vs. application data. I can see a naive implementation of this seriously degrading application performance. For instance, it doesn't take that many tickets to fill an early TCP congestion window. p.p.s., yes, if you keep issuing last calls, I will keep finding new things. On Wed, Nov 6, 2019, at 03:05, Sean Turner wrote: > All, > > This is the working group last call for the "TLS Ticket Requests" draft > available at > https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/. > Please review the document and send your comments to the list by 2359 > UTC on 19 November 2019. > > Note the the GH repo for this draft can be found at: > https://github.com/tlswg/draft-ietf-tls-ticketrequest > > Thanks - J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Nov 5 17:51:47 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67E5120041 for ; Tue, 5 Nov 2019 17:51:45 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=sn3rd.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 saYM7R2_xcxP for ; Tue, 5 Nov 2019 17:51:43 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 21C3F120154 for ; Tue, 5 Nov 2019 17:51:43 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id d13so23203080qko.3 for ; Tue, 05 Nov 2019 17:51:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=mJztGmtBCZT98HD4hYbgW6G3FqlgYFLTZgez9T3qKoI=; b=Ij+O+8cIsX8tLN2xsrRhCHT6RbW1zKJsBIZiYv/YT/HpKbToJ0sjML/VsC4Vlek55J q95Ne0OqPTp3xMI04kShcERa+icNxmmzRDmNciA65y4gZd4mxwWOc3oXyOKTqCFdHZ2n wFuA90OOEQ1XdIopZu4RWKgLcnQor3BI2NoBs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=mJztGmtBCZT98HD4hYbgW6G3FqlgYFLTZgez9T3qKoI=; b=kVXAnayyHWT6Uxy6S1FofshG600MTkjZGn0U4BdBSBPMpPeyT6KntAiyIz+YYEiP7S xrVX6kH0gmwatlUJ1uSyeKoEVRO87xkQ8nHAremePgvGVS64PGd6uEuPWIxEBzosTDAM xwjmPTH3z09ZDuROk1Ld4IAXEcbEo7ArkPoSXzym2JjRviHk03fDc7XXXKAfPAePvrEK vkMJE5z6qUwTJFYr9oEF2MPyP5dqdXZDYNIsAhq6uNqwLfqTN/UAczPy2ISmSMgimpHw Bo5yQmMmGsdhX++GpHhUeOATWaPYQrKxuO5cESjic0Qoz+/KGoxwKzfym6q/mArQO1nO 4EKA== X-Gm-Message-State: APjAAAV4SM6leT7obZe0XvmPMvk4f6SQZpxEw/0u+F86D52d9J7ligT9 V/1ZpYiwqr8IH7vpGdxxVkvjY8Sceiw= X-Google-Smtp-Source: APXvYqx/0gIIdEAfEzoEpYoBxDE1QQgxh8z6PV+B4O8Q5FA+gFgGTRrPIELOYhBP+jNqHvKfgX5pbg== X-Received: by 2002:a37:9782:: with SMTP id z124mr22385qkd.62.1573005101524; Tue, 05 Nov 2019 17:51:41 -0800 (PST) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id l14sm9165838qkj.61.2019.11.05.17.51.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Nov 2019 17:51:40 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 5 Nov 2019 20:51:40 -0500 References: <7675f5ef-c394-4ec5-b0c4-ca59e7b0e2b7@www.fastmail.com> <83b19d14-e03f-467a-9119-148bed049509@www.fastmail.com> To: TLS List In-Reply-To: Message-Id: <433349D9-6B30-47C8-8036-EC3738E2A33F@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] Binder key labels for imported PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2019 01:51:46 -0000 We are obviously going to be discussing this outstanding PRs in = Singapore, but I am kind of hoping that we can knock this out before = then. Do people agree that we want to prevent PSK Importers from being = confused with standard OOB PSKs and that we should do this by changing = the label used in the computation of the PSK binder key? spt > On Oct 11, 2019, at 12:48, Christopher Wood = wrote: >=20 > Hi folks, >=20 > Since #15 has been resolved, we'd like to revisit the proposed key = schedule label modification here: >=20 > = https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/10 >=20 > Please have a look and comment! >=20 > Thanks, > Chris >=20 > On Thu, Sep 5, 2019, at 4:46 PM, Martin Thomson wrote: >> That's a much better answer than I was looking for :) >>=20 >> That makes sense. The gap between theory and practice here is still=20= >> something that is worth spending some time on, but I can see how that=20= >> is something that we might want to keep out of this document. The = goal=20 >> here is simple: take a PSK that is bound to one KDF and apply a=20 >> transform that will allow it to be used with TLS ... in a way where = the=20 >> choice of cipher suite is not constrained by the properties of that = PSK. >>=20 >> Understanding your broader goals better leads me to conclude that = issue=20 >> #15=20 >> = (https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/15) = is more important to resolve. >>=20 >> On Thu, Sep 5, 2019, at 20:56, Jonathan Hoyland wrote: >>> Hi Martin, >>>=20 >>> So I agree that on the micro-scale there is limited practical value = to=20 >>> be gained from adding this binding. >>> The theoretical benefits, which mean that the client and server = agree=20 >>> that PSK Importers are being used are nice, but on their own might = not=20 >>> justify a high-effort change.=20 >>> However, at the macro-scale I think this is an interesting and = useful=20 >>> addition. >>> In particular I think we can use this change to address what I see = as a=20 >>> short-coming of TLS 1.3 in general.=20 >>>=20 >>> Being able to use TLS as a building block for other protocols is = really=20 >>> powerful and useful, but the current mechanisms are unnecessarily=20 >>> restrictive.=20 >>> I have spent a lot of time thinking about exporter keys, and the way=20= >>> they let us combine other protocols with TLS.=20 >>> TLS has really nice, strong, properties, and being able to leverage=20= >>> them in other protocols makes designing complex protocols much = easier,=20 >>> especially from a formal analysis perspective.=20 >>>=20 >>> One limitation of exporter keys, however, is that you need to use = TLS=20 >>> as your first/base protocol.=20 >>> Whilst you can use exporter keys to securely run a protocol over the=20= >>> top of TLS and get the guarantees of both*, you cannot run TLS = inside=20 >>> another protocol and easily get the security guarantees of both*.=20 >>> I think that this restriction is unnecessary.=20 >>>=20 >>> My overarching goal is to make it possible to securely put protocol=20= >>> building blocks before TLS.=20 >>> The way you would achieve this is by allowing such blocks to be = chained=20 >>> together and then bound into the TLS handshake. >>> Ideally, all protocols that wish to use TLS in this way would use = this=20 >>> key-schedule extension, allowing for complex state to be built up = and=20 >>> composed into the TLS handshake. >>>=20 >>> PSK Importers are, to my mind, a good place to start.=20 >>> Agreeing on a change of hash function can be viewed as a very small,=20= >>> very simple protocol.=20 >>> The necessary modifications are small, and the benefits, whilst=20 >>> incremental, are clear.=20 >>> The modification to the key schedule means that both parties can be=20= >>> sure that the other agrees that they are using PSK Importers and=20 >>> further, that they agree on the original hash function and the new = hash=20 >>> function. >>>=20 >>> Other protocols can then also make use of this extension to the key=20= >>> schedule to achieve similar aims.=20 >>> The idea would be that any protocol that uses this label implies = that=20 >>> it is providing a context field (which may or may not be empty).=20 >>> These protocols can then be chained together in an agreed order, and=20= >>> the agreement properties of TLS can be used to verify that both = parties=20 >>> agree on the transcripts of the previous protocols.=20 >>>=20 >>> Making this change allows us to leverage this power in future to = make=20 >>> any number of more useful protocols.=20 >>> However, without a key schedule change, there is no way for a Client=20= >>> and Server to be sure that their peer is actually using TLS as a=20 >>> building block, which kneecaps any ability to compose it with other=20= >>> protocols.=20 >>> In this case it means that a Client cannot be sure that it agrees = with=20 >>> the Server on the status of their relationship, and vice versa. >>> So to directly answer your question, the value of the distinction in=20= >>> this case is incremental, but opens the door for other=20 >>> extensions/protocols to leverage it to provide arbitrarily complex=20= >>> guarantees**.=20 >>>=20 >>> There may be a case for working on a backwards compatible way of = doing=20 >>> this, where a client offers PSK Importers multiple times with = binders=20 >>> computed both ways, but I don't think that it's necessarily a good=20= >>> idea.=20 >>>=20 >>> Regards, >>>=20 >>> Jonathan >>>=20 >>> * The guarantees it is possible to get from this key-schedule change=20= >>> are a little bit nuanced, because a PSK handshake doesn't rely on a=20= >>> long-term asymmetric key, but that's a discussion for another time.=20= >>> ** Modulo limitations on outward compound authentication.=20 >>>=20 >>>=20 >>> On Wed, 4 Sep 2019 at 02:46, Martin Thomson = wrote: >>>> I want to push on this a little harder. Not because I don't think = that more formal protections in the line of key separation are bad (they = are great), but more to dig into the real reasons driving this change. = The justification I've gotten thus far is somewhat superficial, and I = want to see if there is something fundamental that we can point at. >>>>=20 >>>> When we built the ext/res distinction, there was a clear problem = expressed. We had the potential for both to be used by the same servers = at the same time (though not for the same connection) and distinguishing = between them was important. It wasn't so much that agreement about = provenance of keys was important, but more what it meant for that = provenance to be confused. A resumption key implies a number of things = about the new session that extend from the previous session, whereas a = straight external key does not imply the same. If a client and server = were to disagree on these properties, one might assume properties of the = resulting session that the other did not and we would be in a bad place. >>>>=20 >>>> It's true that servers are in complete control over how keys are = identified, and so this could always be addressed by the server by = ensuring that key identifiers clearly distinguish between the two types. = However, that protection would be informal and ad hoc. We wouldn't = guarantee that separation by any mechanism. By applying different labels = to the binder key we produce, disagreement results in interoperability = failure (both client and server could be wrong, but at least they then = agree, which is the property we really need). >>>>=20 >>>> As an aside, we could have used explicit labels in the protocol, = but we decided that an implicit one was better. For the record, I still = think that's a good design paradigm to apply. >>>>=20 >>>> The concern with the ext/res distinction doesn't seem to apply = equally here. For simplicity, I think that we should consider this a = path into the "ext" bucket, so that we have an resumption/other analysis = holding (as above), and an external/imported analysis to perform in = order to arrive at the "other" category. The question then becomes = whether to fully distinguish imported PSKs from "regular" external PSKs. >>>>=20 >>>> I think that the context of use is important to consider. The = imported PSK will enter the key schedule (as shown below) after having = been through a derivation process that includes additional information: = most importantly, the protocol version and the hash function that the = resulting PSK will be bound to. That produces something that could = coexist with other uniformly random PSKs of sufficient entropy (i.e., it = wouldn't collide with "external" PSKs with non-negligible probability). = Because neither imported nor external PSKs come with any different = presumption about the session that is ultimately produced, the same = rationale for ext/res doesn't apply, and I'm struggling to find any = stronger justification. >>>>=20 >>>> The cost of adding more separation is forced changes to code. With = the design prior to this, the importer function was loosely coupled to = the TLS stack. It would be possible to manufacture as many "external" = PSKs as needed from an root "imported" PSK. The resulting outputs could = be fed to endpoints that haven't been updated to support this new = importer stuff. That's obviously less clean than having native support = for this, because the amount and complexity of key provisioning is = higher, but it could have worked. This now requires code changes to = deploy. >>>>=20 >>>> So I'm not seeing strong cause here. >>>>=20 >>>> To me, the relevant question is: Do client and server need to agree = that this is an imported PSK as distinct from another form of external = PSK? Or, what is the value of this distinction? >>>>=20 >>>> On Tue, Sep 3, 2019, at 09:29, Christopher Wood wrote: >>>>> Hi folks, >>>>>=20 >>>>>=20 >>>>> Per Jonathan Hoyland's recommendation, we're considering adding a = new=20 >>>>> binder_key label ("imp binder") for imported PSKs. Specifically, = this=20 >>>>> changes the key schedule from this: >>>>>=20 >>>>> ~~~ >>>>> 0 >>>>> | >>>>> v >>>>> PSK -> HKDF-Extract =3D Early Secret >>>>> | >>>>> +-----> Derive-Secret(., "ext binder" | "res binder", "") >>>>> | =3D binder_key >>>>> ~~~ >>>>>=20 >>>>> to this: >>>>>=20 >>>>> ~~~ >>>>> 0 >>>>> | >>>>> v >>>>> PSK -> HKDF-Extract =3D Early Secret >>>>> | >>>>> +-----> Derive-Secret(., "ext binder" >>>>> | | "res binder" >>>>> | | "imp binder", "") >>>>> | =3D binder_key >>>>> ~~~ >>>>>=20 >>>>> Details can be found in the PR [1].=20 >>>>>=20 >>>>> This does not seem to affect the interoperability story (imported = keys=20 >>>>> are further differentiated from non-imported keys). However, it's = non=20 >>>>> trivial, so we'd like feedback from the group before merging the = change. >>>>>=20 >>>>> Thanks! >>>>> Chris (no hat) >>>>>=20 >>>>> [1] = https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/10 >>>>>=20 >>>>> _______________________________________________ >>>>> TLS mailing list >>>>> TLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tls >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Nov 5 18:03:04 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DF8120236 for ; Tue, 5 Nov 2019 18:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 XI9rIG1-MuNr for ; Tue, 5 Nov 2019 18:02:50 -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 7B636120154 for ; Tue, 5 Nov 2019 18:02:47 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xA622lWc027133; Wed, 6 Nov 2019 02:02:47 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=NtKAvGKDJ3amwPMx4U4bR7TXLNlSXbHfwjDHUZbIHVo=; b=Np1WcI/j+LI+EkkCOPIspH1DYWhKQf7SwNHCe8MXDJyM0hSTYgiw4OXFy8HZyZ+6GHke 4Gj+Tt6MF606VcdDXs3vktRW5fKCIarbuG6f+fo1J34BKI+rBW8gp19s3M3IxGEMP9W8 C9jbCDfkN3kGZCOk6cLSiEZL48cCNFnxpwNyb5ZRYgmK/8QRUwYxov+6WswjPWDBYL8m tZx7n/J+DjpjuixhqaokNFQvwPNsqH1l8jTfwrX2ht2t3pH165fCpzq9Y/tMqQggV/Pc 1jjQs9Vl27ZNGuRJryAhHbeyLYb3QdV2P+jasTBJgjpdQSupdMRN/1BtGJI1GYgPkCdC hg== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2w11xd851c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Nov 2019 02:02:47 +0000 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xA622jO4026897; Tue, 5 Nov 2019 21:02:45 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint6.akamai.com with ESMTP id 2w154uwf4r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 05 Nov 2019 21:02:45 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 5 Nov 2019 21:02:44 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Tue, 5 Nov 2019 21:02:44 -0500 From: "Salz, Rich" To: Sean Turner , TLS List Thread-Topic: [TLS] Binder key labels for imported PSKs Thread-Index: AQHVlETLeHki75CjxEmrbt9Vb6DVTad9ZAQA Date: Wed, 6 Nov 2019 02:02:44 +0000 Message-ID: References: <7675f5ef-c394-4ec5-b0c4-ca59e7b0e2b7@www.fastmail.com> <83b19d14-e03f-467a-9119-148bed049509@www.fastmail.com> <433349D9-6B30-47C8-8036-EC3738E2A33F@sn3rd.com> In-Reply-To: <433349D9-6B30-47C8-8036-EC3738E2A33F@sn3rd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191103 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.80] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-05_09:, , 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=797 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1911060019 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-11-05_09:2019-11-05,2019-11-05 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 clxscore=1011 phishscore=0 spamscore=0 priorityscore=1501 impostorscore=0 malwarescore=0 suspectscore=0 mlxscore=0 mlxlogscore=785 bulkscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1911060019 Archived-At: Subject: Re: [TLS] Binder key labels for imported PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2019 02:02:52 -0000 PiBEbyBwZW9wbGUgYWdyZWUgdGhhdCB3ZSB3YW50IHRvIHByZXZlbnQgUFNLIEltcG9ydGVycyBm cm9tIGJlaW5nIGNvbmZ1c2VkIHdpdGggc3RhbmRhcmQgT09CIFBTS3MgYW5kIHRoYXQgd2Ugc2hv dWxkIGRvIHRoaXMgYnkgY2hhbmdpbmcgdGhlIGxhYmVsIHVzZWQgaW4gdGhlIGNvbXB1dGF0aW9u IG9mIHRoZSBQU0sgYmluZGVyIGtleT8NCiAgDQpPYnZpb3VzbHkuDQogDQoNCg== From nobody Tue Nov 5 18:08:38 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B739A120236 for ; Tue, 5 Nov 2019 18:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 wxz7Oy-ZcuYf for ; Tue, 5 Nov 2019 18:08:32 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 08A5F120274 for ; Tue, 5 Nov 2019 18:08:32 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id x21so9555694iol.2 for ; Tue, 05 Nov 2019 18:08:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FYw3/tSZRqK52Z+Kr17HG+jI1eZy3Bkc1MKij1Iby1Y=; b=oeoIZAbn9kRdFqHy/E2yOlcCk4tE7aIH0J1CpIMGTG8TKfzY0HfgkNXpn1er5LiyEi 4vDjgmjIoz+Ir7Er902y1crQGmIhNLnFL19ayyNjVZmGl6vijIH4dyMilyD3MsWI0rLD ZmVrx3iqTLBSsrJaerTBb7Z6JRV95b7tI9ie9ZR6/IKbb0EbFZbvK9jkx9cXhqOA7obG WElPzLyZM853ekReK3Wnb1MJk8wATLJJEFIleKWPYVfPuwGEsX7xQpbjvImhHMAj2O+T r01dE3gxIiB7xwP/uNoWdofh83W7gOWxJj5yEl853MJouscg5J10U6wUTyGP9RC2+KjK B3sQ== 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=FYw3/tSZRqK52Z+Kr17HG+jI1eZy3Bkc1MKij1Iby1Y=; b=cYPbmmg2Ml3kPzxbb4cfY/sQ1REZPiv8mXNecCfzrTs3zqGy+Xoh2mRyW6x+3J4od6 GHhMO2CGus1it3NgMD98EYyc4zkLoPoESgcyySq8NQyALtbgOqKMWLvjEbg1w4U0YXnK 5L2N4ZevisvZdTrqz8dnDZZZTOHzNKcoXMlnRRF2yCfh+pfJhKn7fs94iWYoJJnP97pU 7bvGAAXsrvF/8QlJtkEUoAi7pQV3JTivkOYXLiCF78k7ueaQ5MB6FciJtu6P8MQSI7My tvZSL46rvXjvUHfeH4iLA6YOTz48z+yJ5IkUZ8XIPbtZ58MCFIY36FIvglf2pWN7rMku mHBg== X-Gm-Message-State: APjAAAVHyD1/awMT7Zy0HqFOoXUjmFRFoJ5CdLWdhgvqibqjCPh4qz06 esy2BsL5FF6WxVzKez2aqby0WrKJWS2Oz1Ru5AA= X-Google-Smtp-Source: APXvYqwHmlDfUjK+mbQ/JxOIVrjjHkVJOynYsiQ+lCPBNb0ypO0XZWMfHUo5ikp97uxoguq1rsPB7SG4ArPHHvpdPd0= X-Received: by 2002:a6b:400e:: with SMTP id k14mr7235468ioa.254.1573006111186; Tue, 05 Nov 2019 18:08:31 -0800 (PST) MIME-Version: 1.0 References: <7675f5ef-c394-4ec5-b0c4-ca59e7b0e2b7@www.fastmail.com> <83b19d14-e03f-467a-9119-148bed049509@www.fastmail.com> <433349D9-6B30-47C8-8036-EC3738E2A33F@sn3rd.com> In-Reply-To: From: Rob Sayre Date: Tue, 5 Nov 2019 18:08:17 -0800 Message-ID: To: "Salz, Rich" Cc: Sean Turner , TLS List Content-Type: multipart/alternative; boundary="0000000000007ca7c10596a40650" Archived-At: Subject: Re: [TLS] Binder key labels for imported PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2019 02:08:35 -0000 --0000000000007ca7c10596a40650 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 5, 2019 at 6:03 PM Salz, Rich wrote: > > Do people agree that we want to prevent PSK Importers from being > confused with standard OOB PSKs and that we should do this by changing the > label used in the computation of the PSK binder key? > > Obviously. > For the slower folks on the list, such as myself, could someone explain why confusing these two types of PSKs would be bad? thanks, Rob --0000000000007ca7c10596a40650 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 5, 2019 at 6:03 PM Salz, Rich= <rsalz@akamai.com> wrote:
> Do people agree that we want to prevent PSK Importers from = being confused with standard OOB PSKs and that we should do this by changin= g the label used in the computation of the PSK binder key?

Obviously.

For the slower folks on the = list, such as myself, could someone explain why confusing these two types o= f PSKs would be bad?

thanks,
Rob
--0000000000007ca7c10596a40650-- From nobody Wed Nov 6 03:20:39 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C91120864 for ; Wed, 6 Nov 2019 03:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 Ktw5IG3QDs9X for ; Wed, 6 Nov 2019 03:20:36 -0800 (PST) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 F20F912085F for ; Wed, 6 Nov 2019 03:20:35 -0800 (PST) Received: by mail-vs1-xe29.google.com with SMTP id q21so15703789vsg.3 for ; Wed, 06 Nov 2019 03:20:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bo2r3S+hamY75dV1gxlyY+r5f95I09Sgu9/vrE77YAk=; b=AwDt33HC71ZeO0ydFcpz+4EQMEqhUA2K62JYcRgBZ/0Uyc6adPNnZB+TXH6MyR6u5C WH6DYxvn2DrNU8Rijimmc2T0iLpRzYEvpyxnE/4aHBoAAMnT4BhEb9RKbwQ716ARwR5T R4R1pRMTm+KpIAeAz0mpUW+wqWFMy9xb5duyNKAwOoLaBTDqOjAEnSm1sgimRmh9PV9i ailfEhnVQl2XmdeXocDOqSOZzw1rwmtccJRJDOyu4iSZlFKbfPr7oUV2KZrl6V3TagRm Mrjcsppud6C3OGr+N3jFx9kaj2Pc/5GNdREU38kQaLdpO1nFvWfk8tsmKqJWTZlYyOYT oNJg== 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=Bo2r3S+hamY75dV1gxlyY+r5f95I09Sgu9/vrE77YAk=; b=rfPDbHCaDHPoG7VhU7i1wuIZi9tbehfLSM4/6C8ohQyaT+tbBWI2+4cccq7c18I6gs ph1+kDGj3AWpfwuFqBXDcdU5xZfm6DFWZaqWb4hg/ETlr5f1meouwvmhgfMNP3TU9PvB K1i5qkoOexneuWzhyPXVqLh28mVMZ6byblBsFBB055RG/oJmKWi9ZwO/i7D4ci417ZbV d8Y+iqIOnR+4J3l55bQ7diav4jPhEGEKg6j6clXtl9xNiZpcg9RUb7CzVtJKs4iD9jns r213LkBgcLZCd75KWyDT1K/JHk5ThZQoV5I4TFV7BW7HdB9Z59gA3vFsKKKB+aJmFdFz 2q8w== X-Gm-Message-State: APjAAAVjYBUTcg+VWaNNHsIlv5Q6DuXa2dYl29ZXtsG/LCgvYXm6pNE7 6CXHZkZ85p407H5Te1TaSmnwU3et67XQRpRLFCM= X-Google-Smtp-Source: APXvYqyhHS6F9SWAiHA3f4DHSoDrZma/iAfUu4gO3owmcHn3woNqyQCxbDCb2iRxGsrGfvB1aLiSJ4z62PbaGWvy+v4= X-Received: by 2002:a67:fc85:: with SMTP id x5mr987050vsp.148.1573039234569; Wed, 06 Nov 2019 03:20:34 -0800 (PST) MIME-Version: 1.0 References: <7675f5ef-c394-4ec5-b0c4-ca59e7b0e2b7@www.fastmail.com> <83b19d14-e03f-467a-9119-148bed049509@www.fastmail.com> <433349D9-6B30-47C8-8036-EC3738E2A33F@sn3rd.com> In-Reply-To: From: Jonathan Hoyland Date: Wed, 6 Nov 2019 11:20:23 +0000 Message-ID: To: Rob Sayre Cc: "Salz, Rich" , TLS List Content-Type: multipart/alternative; boundary="000000000000cb59fd0596abbc6a" Archived-At: Subject: Re: [TLS] Binder key labels for imported PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2019 11:20:38 -0000 --000000000000cb59fd0596abbc6a Content-Type: text/plain; charset="UTF-8" Hi Rob, The situation we are trying to prevent is when both the client and server think they have completed a handshake with each other, but disagree on what happened. In this case, for example, the client might have used a PSK importer, but the server might believe the client has used a vanilla PSK. This type of mismatch can lead to channel synchronization attacks, where an attacker establishes two separate sessions, one with the client and one with the server, that both have the same key. There were attacks on early drafts of TLS 1.3 that you can describe in this way (e.g. the triple handshake attack or the attack on draft-10+ .). Especially if we use later extend this mechanism to chain together different imports we could introduce subtle and difficult to detect flaws. This change reduces the potential for this type of problem. A more direct reason for this change is to do with the goals of TLS 1.3. One of the properties TLS 1.3 tries to provide (see appendix E.1 [p. 143]) is "Uniqueness of the Session Keys". Without this change a client using a vanilla PSK that happens to have the same PSK_ID and key as an imported PSK would produce the same session keys as a client using the equivalent imported PSK. This violates the desired property. Does that make things clearer? Regards, Jonathan On Wed, 6 Nov 2019 at 02:08, Rob Sayre wrote: > On Tue, Nov 5, 2019 at 6:03 PM Salz, Rich wrote: > >> > Do people agree that we want to prevent PSK Importers from being >> confused with standard OOB PSKs and that we should do this by changing the >> label used in the computation of the PSK binder key? >> >> Obviously. >> > > For the slower folks on the list, such as myself, could someone explain > why confusing these two types of PSKs would be bad? > > thanks, > Rob > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000cb59fd0596abbc6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Rob,

The situation we are tryin= g to prevent is when both the client and server think they have completed a= handshake with each other, but disagree on what happened.=C2=A0
= In this case, for example, the client=C2=A0might have used a PSK importer, = but the server might believe the client has used a vanilla PSK.=C2=A0
=

This type of mismatch can lead to channel synchronizati= on attacks, where an attacker establishes two separate sessions, one with t= he client and one with the server, that both have the same key.
T= here were attacks on early drafts of TLS 1.3 that you can describe in this = way (e.g. the triple handshake attack or the attack on draft-10+= .).=C2=A0
Especially if we use later extend this mechanism to cha= in together different imports we could introduce subtle and difficult to de= tect flaws.=C2=A0
This change reduces the potential for this type= of problem.=C2=A0

A more direct reason for this c= hange is to do with the goals of TLS 1.3.=C2=A0
One of the proper= ties TLS 1.3 tries to provide=C2=A0(see appendix E.1 [p. 143]) is "Uni= queness of the Session Keys".=C2=A0
Without this change a cl= ient using a vanilla PSK that happens to have the same PSK_ID and key as an= imported PSK would produce the same session keys as a client using the equ= ivalent imported PSK.
This violates the desired property.=C2=A0= =C2=A0

Does that make things clearer?
Regards,

Jonathan

On Wed, 6 Nov = 2019 at 02:08, Rob Sayre <sayrer@gma= il.com> wrote:
On Tue, Nov 5, 2019 at 6:03 PM Salz= , Rich <rsalz@akam= ai.com> wrote:
> Do people agree that we want to preve= nt PSK Importers from being confused with standard OOB PSKs and that we sho= uld do this by changing the label used in the computation of the PSK binder= key?

Obviously.

For the slower folks on the = list, such as myself, could someone explain why confusing these two types o= f PSKs would be bad?

thanks,
Rob
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000cb59fd0596abbc6a-- From nobody Wed Nov 6 16:02:49 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580EC1200CC for ; Wed, 6 Nov 2019 16:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_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=lowentropy.net header.b=f40BDW4x; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=O3Oq3+Iz 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 yoT_jnO7DS_a for ; Wed, 6 Nov 2019 16:02:45 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67353120025 for ; Wed, 6 Nov 2019 16:02:45 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id A7CD6417 for ; Wed, 6 Nov 2019 19:02:44 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 06 Nov 2019 19:02:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=l4iU1M5vDVDvvS2SLDFqoEbYjt4JBIq d2ADTkIjM3og=; b=f40BDW4xmtqnVPQpgqmHWvhkYUP4c+5to7uC8n4tZsUW/7+ NGhqYJkno5ZTmlgK3JbLVG1ZJaiTWvlQV6NWh/oThfHLIIbKdq/eG2iDEHk9FCLs zi+qoH2nFt78hSdXKCez0P5/qGexlpPfqJO8cbCvWYoWqsufQXslvyVMT1OEpDKa w39UQaqPyvR5O7DrDJh+ijdq6AA+IND1b68xnTPz+v99Lm7cC8nmAY9F1c+xLLeA XK59aoJu0FPvm3mKSJ/SAeIm9gY2Yk+Nf4IDuPWpOS9TnrJ7bCICNsIKx9R8FvWa JGur/aWZ0ytta2QBvtq6LFFqiDU2RjrIZ75Q2bg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=l4iU1M 5vDVDvvS2SLDFqoEbYjt4JBIqd2ADTkIjM3og=; b=O3Oq3+Iz/LfuNkYDVeGg9d 3O6hIdcMrCrZTnKL1L/ibnXOROM/YEnGhQtQw4AIkvmPT5Y/AS2/UIHrCTMnZK8h aU/gEv0JoLL3LFDBuzoNm7Y6St9p4v34DonkOVPrc8PJuDFCYfuiLkZimcyZkJ/b DeirCIMj8gCNlvhAJQvGlJ2Ytarl47vocoub+4Hmw0IU76lRbd2cgrAPQPaf8I32 39u8O/riFAOFtKMSHD1bAWhj1yTPBE43r/aB0wFgqb5Iz3hY6+GpDwjscapR4Gk+ FU1oysxb276YIXEq33bvJAmCHMt70YL2A1xgPQwJCfgUTY5pxuPkOe7KSx3fLgfg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddukedgudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhivg htfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhp hidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DE08EE00A3; Wed, 6 Nov 2019 19:02:43 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: <4aad97cb-80d6-4ba8-87ec-e002bf607bd5@www.fastmail.com> In-Reply-To: References: <12219D44-9FB9-4B55-9B86-6B9AB4FCC5C5@sn3rd.com> Date: Thu, 07 Nov 2019 11:02:24 +1100 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] 2nd WGLC for draft-ietf-tls-dtls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2019 00:02:47 -0000 One belated comment, editorial in nature: The draft now uses the term "packet" in quite a few places. The older text uses datagram. I suggest that this be normalized before the publication request is made. On Tue, Nov 5, 2019, at 03:08, Sean Turner wrote: > This WGLC has concluded. I will complete my shepherd write-up and > forward this to the IESG once I have received the BCP 78 and 70 > confirmations. > > spt > > > On Oct 13, 2019, at 21:13, Sean Turner wrote: > > > > This is the second working group last call for the "The Datagram Transport > > Layer Security (DTLS) Protocol Version 1.3" draft available at > > https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/. Please > > review the document and send your comments to the list by 2359 UTC on > > 28 October 2019. > > > > Please note that we are now on at version -33. -30 was the subject of the > > 1st WGLC and the WG should focus on changes introduced since -30 > > version. Diffs between -30 and -33 can be found at: > > https://www.ietf.org/rfcdiff?url1=draft-ietf-tls-dtls13-30&url2=draft-ietf-tls-dtls13-33 > > > > Note the the GH repo for this draft can be found at: > > https://github.com/tlswg/dtls13-spec > > > > Thanks, > > Chris, Joe, and Sean > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Nov 6 16:09:48 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED17712004A for ; Wed, 6 Nov 2019 16:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_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=lowentropy.net header.b=oUp1HTJF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ia9cJ0O1 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 OMafYIajbWhp for ; Wed, 6 Nov 2019 16:09:45 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4158A120025 for ; Wed, 6 Nov 2019 16:09:45 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 8C1F64E3 for ; Wed, 6 Nov 2019 19:09:44 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 06 Nov 2019 19:09:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm3; bh=jV3ZWBDSSoVD0UoI3lQHVsOXhbBnOuOUXQkLvHXlyho=; b=oUp1HTJF 9RVt+WQVTQ+Hd/V3+Rai3A1jdPcqHiHN489BMg+ukejUH3hH31TNaVtp0Ni4gU+S KNOQ4lNBnrgVGyVD80tgMwYbHdZM4277+uavtFqUwLF3jnioFUADbUdjr9kHpWVM 4j1il1i/oSusQml/SEJjawaJ6G7f/iwRRT3NTddgvrkWnv6OWAfTl/KaNs1s0haR q1XLqQ/AjtG/DLM/OyPvJlFCmRFCwBvuw6ys+CLf4laTAWaiUmnhOtctxquWRrmM q6pHjmy/NjKaw+aJrl61/yEVeoDrFeqWKKnE+o7HPwIwX25gE+Al4D7e0g2AzUDp dJ5IKNFlGN18dQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=jV3ZWBDSSoVD0UoI3lQHVsOXhbBnO uOUXQkLvHXlyho=; b=Ia9cJ0O1dMtdARwOymcrVC6h7EXUy29umLjhizTUokyQU 4Krh82BYcskgOrk/jwBNsmfyySVwV71K4mO7pt6x//EOWjbYZh9pt9+orkYJ3sf2 IKnyhSnrMh61fGSdzVhAVNNsqBwO4PMTlhZlEC6A6NWyYXhhjvxRkH+CFKrplC8W MyCqJ8J2Q5R+6FvN7WN0+gH8KfjrFsgFrJgrXafsq75QhnywpoWnMk0w0oq3DTTQ n+A+R0Ui7PXUGL6ELVTzz3Lbq/iByCm8wIqyL+riLAW60sq9XhWsHdB7a7KNS+9e 00+meo1XP16iBmoMKUG4C3UbtcGsuTAhTXKoWtuYw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddukedgudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertd erredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigv nhhtrhhophihrdhnvghtqeenucffohhmrghinhepqhhuihgtfihgrdhorhhgnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A23A2E00A3; Wed, 6 Nov 2019 19:09:43 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: Date: Thu, 07 Nov 2019 11:09:24 +1100 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: [TLS] DTLS ChaCha20 header protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2019 00:09:47 -0000 It was pointed out to me that the header protection in QUIC and DTLS 1.3 are different in a non-useful way: https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#hp-chacha says that the first 4 bytes of the sample are the counter, i.e., `counter[4] || nonce[12]`. DTLS 1.3 says that the last four are, i.e., `nonce[12] || counter[4]`. This seems like a pointless difference that will only cause pain. I suspect that the right answer is that QUIC is wrong here, but I want to highlight this issue and want to ensure that this doesn't get baked in before we resolve it. From nobody Wed Nov 6 16:19:34 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC9812004A for ; Wed, 6 Nov 2019 16:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=XwCWc6KZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=J78PcJqf 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 bh3JMruQev8t for ; Wed, 6 Nov 2019 16:19:31 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74AE2120025 for ; Wed, 6 Nov 2019 16:19:31 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id D10EB2E3 for ; Wed, 6 Nov 2019 19:19:30 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 06 Nov 2019 19:19:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm3; bh=kjO3E+RodhmmKWkKrT+41CLALsMIMzWZTeiLzp4mbgg=; b=XwCWc6KZ 8Aqlp+lHEq83n8HVnesyL1sqFSBJHt3goY/m9lulsMufKDKr2J0NK8ryhTOzjOC5 uKUEnWSunzy1CQPiLdsLXcvmALXz3B2oXc7XbUlrNWZHxF/9SJ3ztRj7jCGVK0oq lwon6RGZpWhe9D3Fmfe19E4z2yWnYFaozgP6D7NKZtQ71TBUG5gxCvmrU4xTmhaQ OVkkvWn4FgYgkXigPww/+YiuDthdtePm2BwggOHkpRAfZtPt7voOb7GjGo4OZHR4 408Tv5HpnINjO4rP0MNdqdFx4pT77gCtYzpe6T2q+a42/vBBoMGI+hL2m8Jkws0k fpqbVAg1IZ0cYw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=kjO3E+RodhmmKWkKrT+41CLALsMIM zWZTeiLzp4mbgg=; b=J78PcJqftQta3FMqjeaIVlXITQ/JPUJNxkbKOyNApqsSF prgIq19Vk0EJ448ry/JjLwx9+zb8BcLJKbRtfFDiCsSSFkEtnBlGihu0Jav8OMKn XjZB42FZKG8NOTgzxhsb+cghFhULfNoltBWvQtfq2O0jQJ1zCkjUMhqrLLjxHV/q 51bbANke9JfUAdo+i/Nh5PCO/vOvhAIDHxbd0fgfjTdMN9frqRX9NLh4nE7Na8wX YXYl9Vb7i82D2VSiiSP9G5ZidnLAclVrQOaYRHbcvi6+doLjaDvHDsQd5S8qtInV j8QAfMXJviTlAGUd8OtV1VuJAyIysJm9spigZS7OQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddukedgvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertd erredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigv nhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvg hnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F3774E00A3; Wed, 6 Nov 2019 19:19:29 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: <1d6cd21a-73a4-44af-9eac-cc0b50682b24@www.fastmail.com> Date: Thu, 07 Nov 2019 11:18:28 +1100 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: [TLS] Omitting length in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2019 00:19:33 -0000 > Omitting the length field MUST only be used for data which is protected with one of the application_traffic_secret values, and not for messages protected with either [sender]_handshake_traffic_sercret or [sender]_early_traffic_secret values. When using an [sender]_application_traffic_secret for message protection, Implementations MAY include the length field at their discretion. This seems like an unnecessarily strong requirement that I couldn't find any discussion about. I do seem to remember some discussion, but I couldn't find it. QUIC says something different: any packet without a length has to go at the end of the datagram. Why does DTLS not say the same? (QUIC also says something about mixing packets from different connections in the same datagram: don't. That probably an addition worth including.) From nobody Wed Nov 6 17:20:18 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55210120121 for ; Wed, 6 Nov 2019 17:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.249 X-Spam-Level: X-Spam-Status: No, score=-9.249 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, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.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 Xlbc3vRaDXZr for ; Wed, 6 Nov 2019 17:20:12 -0800 (PST) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 C5EE3120801 for ; Wed, 6 Nov 2019 17:20:12 -0800 (PST) Received: by mail-pf1-x42b.google.com with SMTP id n13so916770pff.1 for ; Wed, 06 Nov 2019 17:20:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Dt4UgWcKJNJXRxMvBX2EFiqhkxDOoDoRRyEY7UPFsx4=; b=TAy1TvM1/h5s0d+V/icixJp/39bMLn8CxG5oK5WGr4KdRuk0PTf9Fzqsbsh5AhAGA3 2AAp/EVcz+WZRzifSvnVMhB8F6TYWjAnDEQhUHExE7tSfXhXxhIOIZW+Kn6FYbgdKLVL mNoNWpBkTRbDp1noXtxojuEd+QX577LN4eldQ= 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=Dt4UgWcKJNJXRxMvBX2EFiqhkxDOoDoRRyEY7UPFsx4=; b=XP9sG2wyG87JkPlevtzUauzGUCbCWHlZZbcshuJl0oUJjvmo/X12/ltAX0vfmqqP/n 7dX5EHTET9Qkgd9xzdH49sGjn9Lcg4LafG/wpurWXxS/JwpPGMZWx/CU9i4mCDEmVHRG 0hAIxphMu8oE0FORzShV99kc9R/z17BR9ZSICLRFSa6MOJpIJmlBEVILpyeI1PGr9sIq U5iRkHeQ+noAkvYoomC2slsQhgXrnA9JRrw0wk2NDgFaNLyPZkX+MOethBLyHqueLfo7 H3lSjgmJjA+jbwx/UcLRXxT2QkmTM5XEumQfSZ1wI50AwgzgAM6xtwGWr95B/VCDM0Gy BGwA== X-Gm-Message-State: APjAAAV+/lFeA8wVWu0cLeBKr55L91c9PJ7/BldGPntJyLmWPfVW+QMl QXuio/IlpnrAZTU6PD98v8zZ4xCczg57nQifsPyM X-Google-Smtp-Source: APXvYqzS/zOnv0N9Qg27cF7Tjtjl5kvS8lpj8uozY6yAfvVCUf7fe2L6XHSx9imK/jBTzcChPR8UoY+gCkOBoudgiLg= X-Received: by 2002:a62:830a:: with SMTP id h10mr497835pfe.6.1573089611995; Wed, 06 Nov 2019 17:20:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Wed, 6 Nov 2019 20:19:56 -0500 Message-ID: To: Martin Thomson Cc: "" Content-Type: multipart/alternative; boundary="000000000000865f900596b777cb" Archived-At: Subject: Re: [TLS] DTLS ChaCha20 header protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2019 01:20:15 -0000 --000000000000865f900596b777cb Content-Type: text/plain; charset="UTF-8" I believe DTLS is wrong. ChaCha20 is little-endian with the counter going first and the nonce afterwards. See also RFC 8439, section 2.3, where the block count is placed before the nonce. https://tools.ietf.org/html/rfc8439#section-2.3 (Well, "wrong". Both are perfectly well-defined, but the DTLS construction results in swapping parts of the sample, which is silly.) On Wed, Nov 6, 2019 at 7:09 PM Martin Thomson wrote: > It was pointed out to me that the header protection in QUIC and DTLS 1.3 > are different in a non-useful way: > > https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#hp-chacha says > that the first 4 bytes of the sample are the counter, i.e., `counter[4] || > nonce[12]`. DTLS 1.3 says that the last four are, i.e., `nonce[12] || > counter[4]`. > > This seems like a pointless difference that will only cause pain. I > suspect that the right answer is that QUIC is wrong here, but I want to > highlight this issue and want to ensure that this doesn't get baked in > before we resolve it. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000865f900596b777cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe DTLS is wrong. ChaCha20 is little-endian with th= e counter going first and the nonce afterwards. See also RFC 8439, section = 2.3, where the block count is placed before the nonce.

<= div>(Well, "wrong". Both are perfectly well-defined, but the DTLS= construction results in swapping parts of the sample, which is silly.)

On Wed, Nov 6, 2019 at 7:09 PM Martin Thomson <mt@lowentropy.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">It was pointed out to me t= hat the header protection in QUIC and DTLS 1.3 are different in a non-usefu= l way:

https://quicwg.org/base-drafts/draf= t-ietf-quic-tls.html#hp-chacha says that the first 4 bytes of the sampl= e are the counter, i.e., `counter[4] || nonce[12]`.=C2=A0 DTLS 1.3 says tha= t the last four are, i.e., `nonce[12] || counter[4]`.

This seems like a pointless difference that will only cause pain.=C2=A0 I s= uspect that the right answer is that QUIC is wrong here, but I want to high= light this issue and want to ensure that this doesn't get baked in befo= re we resolve it.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000865f900596b777cb-- From nobody Wed Nov 6 22:28:22 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C2C12009C for ; Wed, 6 Nov 2019 22:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQZjZKeBJUjJ for ; Wed, 6 Nov 2019 22:28:19 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C906412003E for ; Wed, 6 Nov 2019 22:28:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 1590112140; Thu, 7 Nov 2019 08:28:16 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id KIjY0Gid7-MD; Thu, 7 Nov 2019 08:28:15 +0200 (EET) Received: from LK-Perkele-VII (87-100-246-37.bb.dnainternet.fi [87.100.246.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 865057A; Thu, 7 Nov 2019 08:28:13 +0200 (EET) Date: Thu, 7 Nov 2019 08:28:12 +0200 From: Ilari Liusvaara To: Martin Thomson Cc: tls@ietf.org Message-ID: <20191107062812.GA815049@LK-Perkele-VII> References: <1d6cd21a-73a4-44af-9eac-cc0b50682b24@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1d6cd21a-73a4-44af-9eac-cc0b50682b24@www.fastmail.com> User-Agent: Mutt/1.12.2 (2019-09-21) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Omitting length in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2019 06:28:21 -0000 On Thu, Nov 07, 2019 at 11:18:28AM +1100, Martin Thomson wrote: > > Omitting the length field MUST only be used for data which is > > protected with one of the application_traffic_secret values, and > > not for messages protected with either [sender]_handshake_traffic_sercret > > or [sender]_early_traffic_secret values. When using an > > [sender]_application_traffic_secret for message protection, > > Implementations MAY include the length field at their discretion. > > This seems like an unnecessarily strong requirement that I couldn't > find any discussion about. I do seem to remember some discussion, > but I couldn't find it. I actually tried finding rationale for that, and concluded that it was likely a mistake. Originally the requirement was not to use short headers with initial handshake packets. That was sensible back then. However, when unified headers were introduced, that requirement was changed to prohibition of omitting length, which does not make much sense to me. And I could not find any arguments for it. -Ilari From nobody Thu Nov 7 06:09:13 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA2A12081D for ; Thu, 7 Nov 2019 06:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cis-india.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 Snprh0Dwhsnz for ; Thu, 7 Nov 2019 06:09:10 -0800 (PST) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 ED27D120811 for ; Thu, 7 Nov 2019 06:09:09 -0800 (PST) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iSiSP-0008Ql-A5 for tls@ietf.org; Thu, 07 Nov 2019 15:09:07 +0100 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cis-india.org 36BB0580B001A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cis-india.org; s=6F901CFA-19A8-11E9-98F1-CB07954443DB; t=1573135692; bh=ESgOd+at1UXzse91rSQu8OtVFCGvFYBW7BPaeCwponw=; h=To:From:Message-ID:Date:MIME-Version; b=CADOxGR6cRf7NDMIzCw2ay/AYeSOwWYZVmBQ4qJ2idXkQhNdYImjr0lqD0vdTgfsS eLiNxbXaWa92BB2Nb7VLg3Fx+kWHiI8mBmtA4BHhioh6quV2d14dlxcit9cS5vCKgl 8bSyr3B7rJrI28+m0h63BS4Y4nl680Xm65vmCRZ99BQwQteS3KiShSey1YUz5Csgtk p3jtlqf3ToppPJ+V7hM5RIISXkjVI3GCNOqzpkDcr/w20KAk+KQcnhEfV9wIESHDKG kMsOy1CdeMst9UiJsD1YCiGlsGAsHEh1NRMeDvrDDpgxoid7Q3Ss1MYboYhJl8C1zn UM++SDS2NFA+w== To: tls@ietf.org From: Gurshabad Grover Openpgp: preference=signencrypt Autocrypt: addr=gurshabad@cis-india.org; keydata= mQINBFriroIBEADfyDpCD8eborMUMXKtZzjo4t2KzrAlUVYgE/TFtrwUP+4Xw4dzakDIzST8 sVYmlXIWhM5NBBTZSQ190vsxrkbi0xxLcXYM2olZEtqkJ8zONZeZLBeGvcfMymtHqD4jHwYb Zm7OXnS45fWDL+HOoMP/VCwEn098rYfnllIkYQD1Gc28Ig+ywjGg8y5p0qMmmmhm2ckgLjnG MJX8t273MSc8wsn/UYH922yif3MQXmrzqgnRl9hRzf90SKqAw38bw7wccb55pIItloKYsi0r zYBKJSOPXn91Z21TpOSTy21M0MZYEAlDn1zeea+q8TggfHNWxOXoKrIm1pqZFRz0k+8i2siJ AHf8bRm/fhukA6szZ6b2nNPxjkAmOv9zvGu6RZGbmeLvQYVBSSnZ67ayZrkKwn7KIyAV6hQM /bVnD8eEZ2tZ0S8lxoZFYSNeMGt2b6WelFZO97/LbjxaJUHd9K8g5H0MwqN1NXoBxRwllVRC 3sVHVoWTBqnKo8qplzvQEAto69PpvuxxKTOFEJeQqmn1b/fo3sLRb4YiIg8Ax+Np7Huzzjk6 vKKgpIwIN7yEUj/ReWi/UA/W4wSg3XkcqTf7h73crnN/1At0PdgozbDV2UbcApaldStP4DfG UiQl0/7MiYLKapDDuSahmoeH3xrNnrzS9BAfuGHezzDbMyPLXQARAQABtCpHdXJzaGFiYWQg R3JvdmVyIDxndXJzaGFiYWRAY2lzLWluZGlhLm9yZz6JAj0EEwEIACcFAlriroICGyMFCQlm AYAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQrbl/X+ubfC7/bQ//YQv7zqQE433xxsN/ 3GYKoOFccBy3WvV4DxrTskJ3n3k5lfcZolbc8TQksQOTzyerNt2ZA7fsGZa7eFSW+xR4Yq3/ C9o+5FOoHGhyZhb+x17MILhmyvyUNSj7SdKrRISgurMbV2Vv8LxmTcdrK6CdFF6JLH+opzU1 NlRKwZqROPgbYZEB2QFIUbGfgh2I5AXNyV2XbT7fagfkHk+v9AUV7POP2H1+AZ1xq6iFTm2o 9ufNZsp2bInsDohcVBKC3aH2cnFMjvIXpNoUOx8vb5A2xW0aBUTTJDB/uZw53WOg3kehrCNb ZkML3FnDZLRuu1e8DSWmwk5YIoDzt5bMCgfUwb0C6Q+JuM8lC+8CEEa9qamLc+fhvFAzcrWp VWuSaVeLdhe5NxmtlRYNZdGuKy6sRHjwsEWlwzRylhm74fiDR3aA1eIFsfmYLd4z+i1Fp23Y dHJf7/Gor2CmOxphog9DEA9WCuORXfx4De7hoMKwW4gWKw1A8B12Cv4EOkXmCsWsOnfDEarr 2Yl6elxkhQRfKjAesXb0cezRzZgwsWIsbeYsuWFF7Xi6IzUJ27lxU3p5PcyY8O8aDYOn+pu0 YFJ7s3u2VRRgptVZJmkcN3WTApXSHY8fGl5xAakM/bqFJj9uj5zlMnFN2EplC6/mQkfYfy2f siaGTP/GQV4OSuOeuMK5Ag0EWuKuggEQAJ4lAzB72gHw4+rbyxmQNNVmvgYVZPjFtO/MQdYi x1QwRP/gxxqPqTd/ZwQvmPGzXRKw10B7uKSRk6YP12+IG0mXJwHGp9q5CWJE0XNGqX3UWbAc KIzxqPNpsf8e6Bv7jdW0YwLBxJ+RW0NNL6uAxz0sr2frbnS+EZB3cU+zOZzp/9YfTUZO2lxF NzgJoErKe/HLp7aBeJXBBcwO0LQlIT80rTZx2KihBa/Ww/y9E9gV/HacJu/Ncb6E/G3e4xGj 9w9L+UW43q01wy+FSUKy9FLc7D40WqQsj8SXZEpl84SyLcJRoX3mtj59bX2SAN2VB2BAksTu qCh00IcIUGfyHziu5PwUWYM96gOhDSocP4wSeiQ8TwLzaffllz2qhdI296a9lCIYIeWVytEd NU9jJ3RbzXAgE0pnDauNXDaQv1FS5jYi8rlslJUxKnrS69BFNjM5RqQ16Cm0C4rKL7/a8wHC r4VjcjSCM8Lzv8YOOitJ9Yt4Y8SVfO5s3YvxcdSr56nX0W3B1kGbG1GpqWTzOgXzGF5bIsbV 7SPecwUs9ShvmLmZzDUxIQ68n4zj3lMZn5I+pP+Ew6nAAiuSmKdr5cygnCH/NVJzil07t+X4 uR6oKHBhuMFYF1c6Wxk36m+EZz5ZHFaT4rN0WDIJdAEqRzD0Z56V6ansDF8y+ksh0SHlABEB AAGJAiUEGAEIAA8FAlriroICGwwFCQlmAYAACgkQrbl/X+ubfC50rhAAloTaq/fZC1gtiVtU wOB+00gEkjgmzt+rLkW+l2EySTST7tje57W83UZwzCX746B2O//Bqardxz9R1Vr0VFiwHA8g 3qeBqPqiv1WoQch/iZ5d/1MxK4A9xDag1uyqLR8RuGlZ8lATmcP3IabKiuiBV4MlFZ7V2Ib6 5ToPf28xxSyjMzTjQObIG0e009uHlu2z+iQVshLyoyVVAOWWa88D6iuBDC/EtBRjlpjLAjuR YhWVYX6KHdVUijKMHN2RqjpX5O2wPL7NcMY/wsTq7EteUeI75hxFvargRXkEt1XR8t52LC0u IE2OjpzY5re/ROUbfsqL8trjAOrSJ+Fx5H8AYl9JaoVxohhxDZgNtgNtPbh/8Nnlf9daj/bh lZcTBO98XLQwMnyHGPdyhIodpWPq2C09Ys3TkQsbcdMMB1pqnEK5Vz1zIKkEEX7QVsLdrz7C 2CFsauc/9PHj+4njCHslXtzBOiVu5FXTnbCwPrLJs5iEUkUCb6qtE/2mSCTrAanzOTTOmqiM cnNTI1Tj0ht462S9VypppQnKCv8shGxXG7BadZTv+pNCA/WfB2kk1sS3ZwB0wBWX4p41fxs+ ArM9ew2SzQ/vBrEfO7ljPfZZmBqH4t/vgAZBnOtTxCGlPEIJqiMqtGHRqIqpiR20QfxEUuXI MfMfa9QJpisdNmqoUyc= Message-ID: <11f90adf-3499-c5bc-96da-d0cbd6c415ed@cis-india.org> Date: Thu, 7 Nov 2019 19:38:15 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 1a7405c26abe6bf9ec28429b6fddc697 Archived-At: Subject: [TLS] Indian ISP using SNI inspection to block websites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2019 14:09:12 -0000 Hello. A friend and I recently recorded that Reliance Jio (the most popular ISP in India, serves around 331.25 million internet subscribers) is now using SNI inspection to block websites for its users. See Thank you. -Gurshabad From nobody Sat Nov 9 13:56:01 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED59120090 for ; Sat, 9 Nov 2019 13:55:58 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 84cez6JZd577 for ; Sat, 9 Nov 2019 13:55:56 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 6BB34120088 for ; Sat, 9 Nov 2019 13:55:56 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id m9so9815536ljh.8 for ; Sat, 09 Nov 2019 13:55:56 -0800 (PST) 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=uNq9H2eD7SzORT0+iG2874bRZYzWHNC9g1n5QC6p91c=; b=R09qqKq7Y2orMxBqIDwzFYv47+0LZhfgd86okAxMPVQa12fA2eHoH9hjw+WmfcpNan R07LqTiCtNQ/SfOqDs7XRy7U51rTbVQeQMY3gWr455XwNJflP89346TXjrvRi9Jxqz8k w03VkEUx7p8ExegoGZNZpYfLEft351qGSUqgcztg9bEFmqzuB5KoZxD1Y03XNA7RN88u BJl7VcFGtbUOF7K7kC7WsDW8IJuKm90whunBFwPpUBjMTBkxX/bebnlcaRNvG0GHxUc3 GP/Hdy8wFPel6rWSfH7yPJRWgjvb0psIPiVQnj+fKQ4wr4+gKMkcwVBRkgGrMYHQCxxw FgIA== 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=uNq9H2eD7SzORT0+iG2874bRZYzWHNC9g1n5QC6p91c=; b=RY1g+bFcMQcxw62EudrTEkyY1o/jvAf4VQ4wHGT0QH9TPeMjfTiC6tVL65aNs2jHLv FyckoQZXSEH3i23zQ30tjpMlvhuH+khkXPuPxDM5tnVbnWv9245EQBP54zbDycR+4+YQ oQop6sfY3AVJYpe+BuSdYNKCnaENEpEV5fCVGWjzfsdXRtbXObJ+48PUvcw4ffzSZqTy 98ubHrny4FdAFA3G1hj/Gv1nEwMRdzqYS9PItTjR3Q7evOYUXOINvo8O18jz4Qm69ZBR cOnv5yrTn7kdia8/PHB44C3N75TDx6AjQzhT0YWDHAYYp6PdVZhR/5wvZmkK3othSHwP dxZQ== X-Gm-Message-State: APjAAAVhRGI6XGqt7DmZQAnXxS3imz6JTZORWFcuE6iXcqMesx16H5rj VydnxvcRYK0xK66ozuR1PTOQmjHJ3/VAqzRosT3CYA== X-Google-Smtp-Source: APXvYqz/VbJoZxNJ4EQTxY5MjjnQSXZZ98tkByFavKGIn8jiSJebfU8bL2qzGNqIGB+F0M4YwmbWJ0FDgV6+fXUDUgk= X-Received: by 2002:a2e:7013:: with SMTP id l19mr3533899ljc.201.1573336554599; Sat, 09 Nov 2019 13:55:54 -0800 (PST) MIME-Version: 1.0 References: <1d6cd21a-73a4-44af-9eac-cc0b50682b24@www.fastmail.com> <20191107062812.GA815049@LK-Perkele-VII> In-Reply-To: <20191107062812.GA815049@LK-Perkele-VII> From: Eric Rescorla Date: Sat, 9 Nov 2019 13:55:17 -0800 Message-ID: To: Ilari Liusvaara Cc: Martin Thomson , "" Content-Type: multipart/alternative; boundary="0000000000007305560596f0f69c" Archived-At: Subject: Re: [TLS] Omitting length in DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2019 21:55:59 -0000 --0000000000007305560596f0f69c Content-Type: text/plain; charset="UTF-8" I have filed a PR to fix this. On Wed, Nov 6, 2019 at 10:28 PM Ilari Liusvaara wrote: > On Thu, Nov 07, 2019 at 11:18:28AM +1100, Martin Thomson wrote: > > > Omitting the length field MUST only be used for data which is > > > protected with one of the application_traffic_secret values, and > > > not for messages protected with either > [sender]_handshake_traffic_sercret > > > or [sender]_early_traffic_secret values. When using an > > > [sender]_application_traffic_secret for message protection, > > > Implementations MAY include the length field at their discretion. > > > > This seems like an unnecessarily strong requirement that I couldn't > > find any discussion about. I do seem to remember some discussion, > > but I couldn't find it. > > I actually tried finding rationale for that, and concluded that it was > likely a mistake. > > Originally the requirement was not to use short headers with initial > handshake packets. That was sensible back then. > > However, when unified headers were introduced, that requirement was > changed to prohibition of omitting length, which does not make much > sense to me. And I could not find any arguments for it. > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000007305560596f0f69c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have filed a PR to fix this.

On Wed, Nov 6, 2019 at 1= 0:28 PM Ilari Liusvaara <ila= riliusvaara@welho.com> wrote:
On Thu, Nov 07, 2019 at 11:18:28AM +1100, Martin Thoms= on wrote:
> > Omitting the length field MUST only be used for data which is
> > protected with one of the application_traffic_secret values, and<= br> > > not for messages protected with either [sender]_handshake_traffic= _sercret
> > or [sender]_early_traffic_secret values.=C2=A0 When using an
> > [sender]_application_traffic_secret for message protection,
> > Implementations MAY include the length field at their discretion.=
>
> This seems like an unnecessarily strong requirement that I couldn'= t
> find any discussion about.=C2=A0 I do seem to remember some discussion= ,
> but I couldn't find it.

I actually tried finding rationale for that, and concluded that it was
likely a mistake.

Originally the requirement was not to use short headers with initial
handshake packets. That was sensible back then.

However, when unified headers were introduced, that requirement was
changed to prohibition of omitting length, which does not make much
sense to me. And I could not find any arguments for it.



-Ilari

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000007305560596f0f69c-- From nobody Sat Nov 9 16:43:48 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D575512010E; Sat, 9 Nov 2019 16:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 cAYBIfYqQAD9; Sat, 9 Nov 2019 16:43:43 -0800 (PST) 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 344E31200D5; Sat, 9 Nov 2019 16:43:40 -0800 (PST) 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 xAA0hZSb004812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 9 Nov 2019 19:43:38 -0500 Date: Sat, 9 Nov 2019 16:43:35 -0800 From: Benjamin Kaduk To: draft-ietf-tls-tls13-cert-with-extern-psk.all@ietf.org Cc: tls@ietf.org Message-ID: <20191110004335.GV47216@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: [TLS] AD review of draft-ietf-tls-tls13-cert-with-extern-psk-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2019 00:43:46 -0000 Hi all, Thanks for putting this together, and sorry again for the delays in processing. I note inline many places where we essentially repeat preexisting requirements from RFC 8446 but use normative keywords as if they were new requirements being imposed by this document. (There are other places where we repeat or duplicate some narrative descriptions from RFC 8446 as well, though I did not note specific locations.) I think our general preference is to try to only use the normative keywords once, and have either direct quotations or descriptive language for other places where we refer to those requirements, though of course there are always exceptions. Similarly, we may have more duplication of content/requirements between Sections 4 and 5 than is needed. Some other section-by-section notes are included as well, in particular for the IANA Considerations that will need some tweaking. Section 3 The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today, including the digital signature algorithms that are used to authenticate the server in the TLS 1.3 handshake protocol. It is an open question whether or not it is feasible to build a large-scale quantum computer, and if so, when that might happen. However, if such a quantum computer is invented, many of the cryptographic algorithms and the security protocols that use them would become vulnerable. Apparently we don't have an RFC style entry for "the kind of quantum computer that we have to worry about for cryptographic purposes"; I see reference to "sufficiently large quantum computer" (RFC 8080), "large-scale quantum computer" (RFC 8576), "cryptographically relevant quantum computer" (RFC 8603), and there's probably more that didn't jump out at me. (This question did just come up in response to my review of draft-ietf-ipsecme-qr-ikev2, where Scott Fluhrer suggested "cryptographically significant quantum computer", that I was going to lean towards until I did this search just now.) It would be great to normalize our terminology use here, though I don't know that there's a clear winner yet. (I also wonder if "invention" is quite the right word to describe the process in question, but that's probably a side note.) The TLS 1.3 handshake protocol employs key agreement algorithms that could be broken by the invention of a large-scale quantum computer [I-D.hoffman-c2pq]. These algorithms include Diffie-Hellman (DH) [DH1977] and Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363]. As a It might be worth using "also employs" to emphasize that the signature algorithms of the first paragraph and the key-agreement algorithms of the second paragraph are distinct classes of algorithms. Also, do we want to also reference RFC 7748 to get an "I*TF-internal" reference for ECDH technologies? Section 4 The client includes the "tls_cert_with_extern_psk" extension in the ClientHello message. The "tls_cert_with_extern_psk" extension MUST be accompanied by the "key_share", "psk_key_exchange_modes", and Do we need to mandate anything about the contents of "psk_key_exchange_modes" in this case? (I see we do say something later on in Section 5, so maybe not here. But see also the note about duplication of normative requirements between Sections 4 and 5.) "pre_shared_key" extensions. The "pre_shared_key" extension MUST be the last extension in the ClientHello message, and it provides a list of external PSK identifiers that the client is willing to use with this server. [...] I think that the last paragraph of https://tools.ietf.org/html/rfc8446#section-4.2.11 is quite clear that "pre_shared_key" must be the last extension, and we don't need to have new normative language to require it. The successful negotiation of the "tls_cert_with_extern_psk" extension requires the TLS 1.3 key schedule processing to include both the selected external PSK and the (EC)DHE shared secret value. grammar pedant alert: I believe that this construction is parsed such that inclusion of (both external PSK and ECDHE shared secret) in the key schedule is a prerequisite for successful negotiation, whereas the intent is that successful negotiation implies the key schedule change. One plausible "fix" (if any is indeed desired) would be "After successful negotiation [...], it is required to adopt the TLS 1.3 key schedule [...]", but there are probably better ones. As a result, the Early Secret, Handshake Secret, and Master Secret values all depend upon the value of the selected external PSK. (side note) Not that anyone here is likely to be confused, but the Early Secret does not incorporate the (EC)DHE shared secret. I don't really see any reason to include a clarification about this, since the current text isn't really implying that it does, but will mention it in case anyone feels differently. Each external PSK is associated with a single hash algorithm, which is required by Section 4.2.11 of [RFC8446]. The hash algorithm MUST be set when the PSK is established, with a default of SHA-256 if no hash algorithm is specified during establishment. This is likely to get flagged by the IESG -- it's a construction of the form "MUST do X, but if you don't do X, assume Y" that inherently assumes the MUST will not always be adhered to. Section 5 Is there a useful way to group this content into sub-sections? appeared in the preceding ClientHello message. If an implementation recognizes the "tls_cert_with_extern_psk" extension and receives it in any other message, then the implementation MUST abort the handshake with an "illegal_parameter" alert. nit: "abort the handshake" is not quite right, since there are Extensions blocks involved in post-handshake messages (NST, CertificateRequest, etc.) which do not have a handshake to abort. I think "terminate the connection with a alert" is the preferred construction for this situation. ClientHello message. If the server responds with a HelloRetryRequest message, then the client sends another ClientHello message as described in Section 4.1.2 of [RFC8446], and it MUST include the same "tls_cert_with_extern_psk" extension as the original ClientHello message or abort the handshake. (This is another MUST that duplicates an existing requirement from RFC 8446.) Many server extensions are carried in the EncryptedExtensions message; however, the "tls_cert_with_extern_psk" extension is carried in the ServerHello message. It is only present in the ServerHello I suggest adding a brief phrase noting that it's unfeasible to put this extension in the EncryptedExtensions since it affects what key is used to encrypt that message. To use an external PSK with certificates, clients MUST provide the "tls_cert_with_extern_psk" extension, and it MUST be accompanied by the "key_share", "psk_key_exchange_modes", and "pre_shared_key" extensions in the ClientHello. If clients offer a "tls_cert_with_extern_psk" extension without all of these other extensions, servers MUST abort the handshake. The client MAY also This seems redundant with the requirements from Section 4; is the repetition necessary? find it useful to include the "supported_groups" extension. Note that Section 4.2 of [RFC8446] allows extensions to appear in any order, with the exception of the "pre_shared_key" extension, which MUST be the last extension in the ClientHello. Also, there MUST NOT be more than one instance of each extension in the ClientHello message. I'd prefer to either use direct quotations from RFC 8446 or descriptive versions of the requirements (without normative keywords). might supply via a subsequent NewSessionTicket. As a result, clients MUST include the psk_dhe_ke mode, and clients MAY also include the psk_ke mode to support a subsequent NewSessionTicket. Servers MUST select the psk_dhe_ke mode for the initial handshake. Servers MUST select a key exchange mode that is listed by the client for subsequent handshakes that include the resumption PSK from the initial handshake. I suppose it's probably implicit that "MUST select the psk_dhe_ke mode" is contingent on negotiating "tls_cert_with_extern_psk", but maybe there's not any harm in making it explicit as well. The "pre_shared_key" extension is defined in Section 4.2.11 of [RFC8446]. The syntax is repeated below for convenience. All of the listed PSKs MUST be external PSKs. Should we specify that the server must abort the handshake if it detects a resumption PSK present in a ClientHello that contains "tls_cert_with_extern_psk"? (What alert would be best in that case?) The obfuscated_ticket_age is not used for external PSKs; clients SHOULD set this value to 0, and servers MUST ignore the value. (These are the same requirements from RFC 8446, though it's probably reasonable to repeat them here to confirm that they apply.) The selected_identity contains the external PSK identity that the server selected from the list offered by the client. If none of the nit: it's the index of the identity, though it's unclear to what length we need to cover that in this document, since RFC 8446 is pretty clear and available to the reader in case of confusion. The server MUST validate the binder value that corresponds to the selected external PSK as described in Section 4.2.11.2 of [RFC8446]. If the binder does not validate, the server MUST abort the handshake with an "illegal_parameter" alert. Servers SHOULD NOT attempt to validate multiple binders; rather they SHOULD select one of the offered external PSKs and validate only the binder that corresponds to that external PSK. (This chunk also has pretty high overlap with existing RFC 8446 requirements.) TLS 1.3 does not permit the server to send a CertificateRequest message when a PSK is being used. This restriction is removed when the "tls_cert_with_extern_psk" extension is negotiated, allowing certificate-based authentication for both the client and the server. We might get some questions about whether this weakening of an RFC 8446 requirement requires an "Updates:" relationship (problematic given this document is targetting Experimental status), but I don't think it's necessary. (That text is relevant when the server is authenticating solely with a PSK, which is not the case here.) Section 7.1 of [RFC8446] specifies the TLS 1.3 Key Schedule. The successful negotiation of the "tls_cert_with_extern_psk" extension requires the key schedule processing to include both the external PSK and the (EC)DHE shared secret value. Do we want to say "into the PSK and (EC)DHE inputs, respectively"? It seems almost banal to do so, so maybe not... If the client and the server have different values associated with the selected external PSK identifier, then the client and the server will compute different values for every entry in the key schedule, which will lead to the termination of the connection with a "decrypt_error" alert. (side note) this is a case where "abort the handshake" would be appropriate, though the verb tense into which we have to fit probably makes the current wording better :) Section 6 We also should probably say that it gets the "Recommended" value "N" (not that we have any choice about it) and [this document] is the reference. Implementations must protect the external pre-shared key (PSK). Compromise of the external PSK will make the encrypted session content vulnerable to the future invention of a large-scale quantum computer. ("invention" and "large-scale quantum computer" again, if we end up making a pass to change either of those) Implementers should not transmit the same content on a connection that is protected with an external PSK and a connection that is not. Doing so may allow an eavesdropper to correlate the connections, making the content vulnerable to the future invention of a large- scale quantum computer. I think I'm missing a step here. While it's clear that if the same content is sent on two connections, and the attacker can correlate the connections so as to know that fact, then the PSK-less connection can be attacked with the quantum computer and thus reveal the contents of the PSK-protected connection, I'm not sure how just having the same content on the two connection allows the eavesdropper to correlate the connections. Or is this just a more generic risk (e.g., timing/size analysis) that's not particularly enabled by the external PSK (non-)usage? If the external PSK is known to any party other than the client and the server, then the external PSK MUST NOT be the sole basis for authentication. The reasoning is explained in [K2016] (see Section 4.2). When this extension is used, authentication is based on certificates, not the external PSK. Are we talking about [K2016] as https://eprint.iacr.org/2016/711.pdf ? I failed to find anything in Section 4.2 that considers the case when the PSK is shared between more parties than just C and S. 1.2 PRF. Thus, the safest approach is to use a PSK with either TLS 1.2 or TLS 1.3. However, any PSK that might be used with both TLS 1.2 and TLS 1.3 must be used with only one hash function, which is the one that is bound for use in TLS 1.3. This restriction is less nit(?): I suggest rewording "use a PSK with either TLS 1.2 or TLS 1.3", as the current wording can be confusing as to the exclusive nature of the "or", perhaps to "the safest approach is to use any given PSK with at most one of TLS 1.2 and TLS 1.3". What is the origin of the "only one hash function" requirement? (Appendix E.7 of RFC 8446 only has this limitation apply to the TLS 1.3 usage, not the TLS 1.2 usage.) than optimal when users want to provision a single PSK. While the constructions used in TLS 1.2 and TLS 1.3 are both based on HMAC [RFC2104], the constructions are different, and there is no known way in which reuse of the same PSK in TLS 1.2 and TLS 1.3 that would produce related outputs. (This also has pretty high overlap with Appendix E.7 of RFC 8446; do we need to inline it all as opposed to incorporating by reference?) Thanks, Ben From nobody Sat Nov 9 16:45:20 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C9F120104 for ; Sat, 9 Nov 2019 16:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=fxRoQNOn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BssAf03s 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 z8NO13_NSkHS for ; Sat, 9 Nov 2019 16:45:15 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A9F61200D5 for ; Sat, 9 Nov 2019 16:45:15 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 98EA621A09 for ; Sat, 9 Nov 2019 19:45:14 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 09 Nov 2019 19:45:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=6w0OBD0UNS2A8k+d/uCVZswcWjAnC9I3wMXMIyKdGFE=; b=fxRoQNOn 5EKOZ0FmTeiS4vM2dZMYfqVGmsvYP0gLBpJnixjdIzd3csGb20wuxQCk71gMQ+cS XTNTVlX2g0w4rkjEAzUI5FTXvMGJHembqII/iSOUE8gExhaQSlr6SYjPoMwikUrw 52b6Fx+coUG3f3PgX4Fkfww5KyStGr+iyccRL+Z97FNS73hY3U45Y42h7w7Qatoa ARvU1psO2Udrm3SoH9sh0uwNCnNIAs4W5wSSmf9JiYp+43OA74T+sRJKGL12VHLa c9IbXZSYPkhuTecdygwSsCePFm/aYdzZmSlEt/V+YYJCm/RdhGVMWpLde41gEqrC Jd4PoD3RUHY7Vg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=6w0OBD0UNS2A8k+d/uCVZswcWjAnC 9I3wMXMIyKdGFE=; b=BssAf03sjqysabHpo1u2UXlt05aiAWk6piB8lnciQCPJs LdlPNmcJS2eKPfkgyV1AU4N/xBcOCfryheh0ueqVNFfdcuNmG4mlM3Y5Px8PDKDj +A7hNYomgaWvgKJHyDS7MtrHzH83ClxIHJ9id/9hvcyWYQZWb80lSkfVX4L0eceH nHv3eBB5iNEpm0nJYVpFTUcy54fCoIra0SblvpBjI9dqLuTdm9texuSxfWaPbyz1 54QM3Mtxq3MdapjF5VraeLsiI4nZOca7DC7RmHCH7dR15whEBmIMZKMTx5ct9e9t BBd6jqB/0j9qUrRtLIDns2Zc/E80Zu/oo6cSjZCFg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddvgedgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpefiihhthhhusgcupfhothhifhhitggrthhiohhnshcuoeguohgpnhhothgp rhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmne cukfhppeeghedrjeelrdduudefrdduieehnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [45.79.113.165]) by mail.messagingengine.com (Postfix) with ESMTPA id 6B2D980064 for ; Sat, 9 Nov 2019 19:45:13 -0500 (EST) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 97CEF9E70E for ; Sun, 10 Nov 2019 00:45:12 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============0219683576178147441==" MIME-Version: 1.0 From: Github Notifications To: tls@ietf.org Message-Id: <20191110004512.97CEF9E70E@cloud.mnot.net> Date: Sun, 10 Nov 2019 00:45:12 +0000 (UTC) Archived-At: Subject: [TLS] Weekly github digest (TLS Working Group Drafts) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2019 00:45:19 -0000 --===============0219683576178147441== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * tlswg/draft-ietf-tls-esni (+0/-5/=F0=9F=92=AC24) 9 issues received 24 new comments: - #193 Reasoning for 260 (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/issues/193=20 - #192 How to parse esni_retry_request generically? (2 by davidben, ocher= on) https://github.com/tlswg/draft-ietf-tls-esni/issues/192=20 - #191 Why is the PaddedSNI padded with zeros? (11 by chris-wood, ekr, ma= rtinthomson, sayrer) https://github.com/tlswg/draft-ietf-tls-esni/issues/191=20 - #189 AEAD-Encrypt definition (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/issues/189=20 - #188 "HKDF-Extract(0, Z)" (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/issues/188=20 - #183 Clarification on repeated extensions in ESNIRecord and ESNIKeys (1= by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/issues/183=20 - #149 Replay attack and timestamp (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/issues/149 [needs WG discu= ssion]=20 - #118 Is there a debug/development server to test client side implementa= tion (3 by avened, sftcd) https://github.com/tlswg/draft-ietf-tls-esni/issues/118=20 - #116 Compress server name in ClientHello (3 by chris-wood, kazuho) https://github.com/tlswg/draft-ietf-tls-esni/issues/116 [needs WG discu= ssion]=20 5 issues closed: - Compress server name in ClientHello https://github.com/tlswg/draft-ietf= -tls-esni/issues/116 [needs WG discussion]=20 - AEAD-Encrypt definition https://github.com/tlswg/draft-ietf-tls-esni/is= sues/189=20 - Reasoning for 260 https://github.com/tlswg/draft-ietf-tls-esni/issues/1= 93=20 - Cryptographic configuration consistency https://github.com/tlswg/draft-= ietf-tls-esni/issues/178=20 - Why is the PaddedSNI padded with zeros? https://github.com/tlswg/draft-= ietf-tls-esni/issues/191=20 * tlswg/dtls13-spec (+7/-4/=F0=9F=92=AC4) 7 issues created: - Records from different connections in the same datagram (by martinthoms= on) https://github.com/tlswg/dtls13-spec/issues/110=20 - ChaCha20 header encryption (by martinthomson) https://github.com/tlswg/dtls13-spec/issues/109=20 - Omitting length (by martinthomson) https://github.com/tlswg/dtls13-spec/issues/108=20 - "Packet" and "datagram" (by martinthomson) https://github.com/tlswg/dtls13-spec/issues/106=20 - Content Type - 25 taken by CID (by seanturner) https://github.com/tlswg/dtls13-spec/issues/104=20 - IANA Considerations (by seanturner) https://github.com/tlswg/dtls13-spec/issues/102=20 - Editor's draft is ancient (by martinthomson) https://github.com/tlswg/dtls13-spec/issues/101=20 4 issues received 4 new comments: - #106 "Packet" and "datagram" (1 by ekr) https://github.com/tlswg/dtls13-spec/issues/106=20 - #102 IANA Considerations (1 by ekr) https://github.com/tlswg/dtls13-spec/issues/102=20 - #101 Editor's draft is ancient (1 by ekr) https://github.com/tlswg/dtls13-spec/issues/101=20 - #72 Key separation from TLS (1 by seanturner) https://github.com/tlswg/dtls13-spec/issues/72=20 4 issues closed: - Editor's draft is ancient https://github.com/tlswg/dtls13-spec/issues/1= 01=20 - IANA Considerations https://github.com/tlswg/dtls13-spec/issues/102=20 - Key separation from TLS https://github.com/tlswg/dtls13-spec/issues/72 = - Content Type - 25 taken by CID https://github.com/tlswg/dtls13-spec/iss= ues/104=20 * tlswg/tls-subcerts (+2/-1/=F0=9F=92=AC6) 2 issues created: - Security Considerations: network layer (by sayrer) https://github.com/tlswg/tls-subcerts/issues/42=20 - Assign codepoint for delegated_credentials extension (by siyengar) https://github.com/tlswg/tls-subcerts/issues/41=20 2 issues received 6 new comments: - #42 Security Considerations: network layer (5 by ekr, sayrer) https://github.com/tlswg/tls-subcerts/issues/42=20 - #41 Assign codepoint for delegated_credentials extension (1 by siyengar) https://github.com/tlswg/tls-subcerts/issues/41=20 1 issues closed: - PSS https://github.com/tlswg/tls-subcerts/issues/28=20 * tlswg/tls-exported-authenticator (+0/-3/=F0=9F=92=AC2) 2 issues received 2 new comments: - #51 Address Secdir last call comments (1 by grittygrease) https://github.com/tlswg/tls-exported-authenticator/issues/51=20 - #49 Address Genart comments (1 by grittygrease) https://github.com/tlswg/tls-exported-authenticator/issues/49=20 3 issues closed: - Address Secdir last call comments https://github.com/tlswg/tls-exported= -authenticator/issues/51=20 - Explicitly forbid the generation of EAs with early_exporter_master_secr= et https://github.com/tlswg/tls-exported-authenticator/issues/48=20 - Address Genart comments https://github.com/tlswg/tls-exported-authentic= ator/issues/49=20 Pull requests ------------- * tlswg/draft-ietf-tls-esni (+8/-1/=F0=9F=92=AC16) 8 pull requests submitted: - Flatten ESNI negotiation mechanisms (by davidben) https://github.com/tlswg/draft-ietf-tls-esni/pull/201=20 - Advertise multiple ESNIConfigs as a unit (by davidben) https://github.com/tlswg/draft-ietf-tls-esni/pull/200=20 - Unify version/extension and key share negotiation mechanisms (by davidb= en) https://github.com/tlswg/draft-ietf-tls-esni/pull/199=20 - Add a length prefix to ESNIConfig contents. (by davidben) https://github.com/tlswg/draft-ietf-tls-esni/pull/198=20 - Key schedule injection proposal. (by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/pull/197=20 - Tunnel version (by ekr) https://github.com/tlswg/draft-ietf-tls-esni/pull/196=20 - Clarify rules on order and repetition for ESNIConfig extensions (by dmc= ardle) https://github.com/tlswg/draft-ietf-tls-esni/pull/195=20 - Add note about inconsistent cryptographic configurations. (by chris-woo= d) https://github.com/tlswg/draft-ietf-tls-esni/pull/194=20 4 pull requests received 16 new comments: - #200 Advertise multiple ESNIConfigs as a unit (4 by bemasc, davidben) https://github.com/tlswg/draft-ietf-tls-esni/pull/200=20 - #199 Unify version/extension and key share negotiation mechanisms (3 by= davidben, ekr) https://github.com/tlswg/draft-ietf-tls-esni/pull/199=20 - #196 Tunnel version (8 by davidben, ekr, kazuho, martinthomson) https://github.com/tlswg/draft-ietf-tls-esni/pull/196=20 - #175 refer GREASE extension in resolution algorithm & formatting fix (1= by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/pull/175=20 1 pull requests merged: - Add note about inconsistent cryptographic configurations. https://github.com/tlswg/draft-ietf-tls-esni/pull/194=20 * tlswg/draft-ietf-tls-ticketrequest (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - changing track to standards (by seanturner) https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/8=20 1 pull requests merged: - changing track to standards https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/8=20 * tlswg/dtls13-spec (+6/-2/=F0=9F=92=AC3) 6 pull requests submitted: - Issue106 packets (by ekr) https://github.com/tlswg/dtls13-spec/pull/113=20 - Issue109 chacha order (by ekr) https://github.com/tlswg/dtls13-spec/pull/112=20 - Issue110 multiple connections same dg (by ekr) https://github.com/tlswg/dtls13-spec/pull/111=20 - Fix typo (by martinthomson) https://github.com/tlswg/dtls13-spec/pull/107=20 - changing ack content type number (by seanturner) https://github.com/tlswg/dtls13-spec/pull/105=20 - adding DTLS-OK column values (by seanturner) https://github.com/tlswg/dtls13-spec/pull/103=20 3 pull requests received 3 new comments: - #112 Issue109 chacha order (1 by ekr) https://github.com/tlswg/dtls13-spec/pull/112=20 - #111 Issue110 multiple connections same dg (1 by ekr) https://github.com/tlswg/dtls13-spec/pull/111=20 - #103 adding DTLS-OK column values (1 by ekr) https://github.com/tlswg/dtls13-spec/pull/103=20 2 pull requests merged: - changing ack content type number https://github.com/tlswg/dtls13-spec/pull/105=20 - Fix typo https://github.com/tlswg/dtls13-spec/pull/107=20 * tlswg/tls-subcerts (+1/-2/=F0=9F=92=AC1) 1 pull requests submitted: - Fix a formatting issue in changes (by siyengar) https://github.com/tlswg/tls-subcerts/pull/40=20 1 pull requests received 1 new comments: - #40 Fix a formatting issue in changes (1 by siyengar) https://github.com/tlswg/tls-subcerts/pull/40=20 2 pull requests merged: - Fix a formatting issue in changes https://github.com/tlswg/tls-subcerts/pull/40=20 - Add text for PKCS 1.5 https://github.com/tlswg/tls-subcerts/pull/39=20 * tlswg/tls-exported-authenticator (+1/-3/=F0=9F=92=AC2) 1 pull requests submitted: - Explicitly forbid the generation of EAs with early_exporter_master_secr= et (by grittygrease) https://github.com/tlswg/tls-exported-authenticator/pull/53=20 2 pull requests received 2 new comments: - #53 Explicitly forbid the generation of EAs with early_exporter_master_= secret (1 by grittygrease) https://github.com/tlswg/tls-exported-authenticator/pull/53=20 - #52 Address Yaron Sheffer's comments. (1 by grittygrease) https://github.com/tlswg/tls-exported-authenticator/pull/52=20 3 pull requests merged: - Address Yaron Sheffer's comments. https://github.com/tlswg/tls-exported-authenticator/pull/52=20 - Explicitly forbid the generation of EAs with early_exporter_master_secr= et https://github.com/tlswg/tls-exported-authenticator/pull/53=20 - Address comments by Christer Holmberg. https://github.com/tlswg/tls-exported-authenticator/pull/50=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/tls-flags * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/sniencryption * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/draft-ietf-tls-grease --===============0219683576178147441== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday November 10, 2019

Issues

tlswg/draft-ietf-tls-esni (+0/-5/=F0=9F=92=AC24)

9 issues received 24 new comments:

5 issues closed:

tlswg/dtls13-spec (+7/-4/=F0=9F=92=AC4)

7 issues created:

4 issues received 4 new comments:

4 issues closed:

tlswg/tls-subcerts (+2/-1/=F0=9F=92=AC6)

2 issues created:

2 issues received 6 new comments:

1 issues closed:

tlswg/tls-exported-authenticator (+0/-3/=F0=9F=92=AC2)

2 issues received 2 new comments:

3 issues closed:

Pull requests

tlswg/draft-ietf-tls-esni (+8/-1/=F0=9F=92=AC16)

8 pull requests submitted:

4 pull requests received 16 new comments:

1 pull requests merged:

tlswg/draft-ietf-tls-ticketrequest (+1/-1/=F0=9F=92=AC0)

1 pull requests submitted:

1 pull requests merged:

tlswg/dtls13-spec (+6/-2/=F0=9F=92=AC3)

6 pull requests submitted:

3 pull requests received 3 new comments:

2 pull requests merged:

tlswg/tls-subcerts (+1/-2/=F0=9F=92=AC1)

1 pull requests submitted:

1 pull requests received 1 new comments:

2 pull requests merged:

tlswg/tls-exported-authenticator (+1/-3/=F0=9F=92=AC2)

1 pull requests submitted:

2 pull requests received 2 new comments:

3 pull requests merged:

Repositories tracked by this digest:

--===============0219683576178147441==-- From nobody Sun Nov 10 12:42:00 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586CD120133 for ; Sun, 10 Nov 2019 12:41:57 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ImoH6iLKrT9H for ; Sun, 10 Nov 2019 12:41:52 -0800 (PST) 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 6B583120129 for ; Sun, 10 Nov 2019 12:41:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6BDC4300B21 for ; Sun, 10 Nov 2019 15:41:50 -0500 (EST) 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 ofxAfdqKR6Qk for ; Sun, 10 Nov 2019 15:41:45 -0500 (EST) Received: from [5.5.33.28] (unknown [204.194.23.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 7C7643004AF; Sun, 10 Nov 2019 15:41:45 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <20191110004335.GV47216@kduck.mit.edu> Date: Sun, 10 Nov 2019 15:41:44 -0500 Cc: draft-ietf-tls-tls13-cert-with-extern-psk.all@ietf.org, IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: References: <20191110004335.GV47216@kduck.mit.edu> To: Ben Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] AD review of draft-ietf-tls-tls13-cert-with-extern-psk-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2019 20:41:57 -0000 Ben: I have made the edits indicated in my response below. I cannot pot it = until the I-D repository reopens. > Thanks for putting this together, and sorry again for the delays in > processing. >=20 > I note inline many places where we essentially repeat preexisting > requirements from RFC 8446 but use normative keywords as if they were > new requirements being imposed by this document. (There are other = places > where we repeat or duplicate some narrative descriptions from RFC 8446 = as > well, though I did not note specific locations.) I think our general > preference is to try to only use the normative keywords once, and have > either direct quotations or descriptive language for other places = where we > refer to those requirements, though of course there are always = exceptions. >=20 > Similarly, we may have more duplication of content/requirements = between > Sections 4 and 5 than is needed. >=20 > Some other section-by-section notes are included as well, in = particular for > the IANA Considerations that will need some tweaking. >=20 > Section 3 >=20 > The invention of a large-scale quantum computer would pose a serious > challenge for the cryptographic algorithms that are widely deployed > today, including the digital signature algorithms that are used to > authenticate the server in the TLS 1.3 handshake protocol. It is an > open question whether or not it is feasible to build a large-scale > quantum computer, and if so, when that might happen. However, if > such a quantum computer is invented, many of the cryptographic > algorithms and the security protocols that use them would become > vulnerable. >=20 > Apparently we don't have an RFC style entry for "the kind of quantum > computer that we have to worry about for cryptographic purposes"; I = see > reference to "sufficiently large quantum computer" (RFC 8080), > "large-scale quantum computer" (RFC 8576), "cryptographically relevant > quantum computer" (RFC 8603), and there's probably more that didn't = jump > out at me. (This question did just come up in response to my review = of > draft-ietf-ipsecme-qr-ikev2, where Scott Fluhrer suggested > "cryptographically significant quantum computer", that I was going to > lean towards until I did this search just now.) It would be great to > normalize our terminology use here, though I don't know that there's a > clear winner yet. > (I also wonder if "invention" is quite the right word to describe the > process in question, but that's probably a side note.) One of your references is using "large-scale quantum computer" as I do = in this document. I can see that alignment on a single term would be = desirable, but I do not think that a common term has emerged in the = greater research community. I will gladly change "invention" to "development" in the first sentence. > The TLS 1.3 handshake protocol employs key agreement algorithms that > could be broken by the invention of a large-scale quantum computer > [I-D.hoffman-c2pq]. These algorithms include Diffie-Hellman (DH) > [DH1977] and Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363]. As a >=20 > It might be worth using "also employs" to emphasize that the signature > algorithms of the first paragraph and the key-agreement algorithms of > the second paragraph are distinct classes of algorithms. > Also, do we want to also reference RFC 7748 to get an "I*TF-internal" > reference for ECDH technologies? I am using the same reference for ECDH as RFC 8446. This was = intensional. I suggest the following to bring in the signature algorithm concern: The TLS 1.3 handshake protocol employs key agreement algorithms and digital signature algorithms that could be broken by the development of a large-scale quantum computer [I-D.hoffman-c2pq]. The key agreement algorithms include Diffie-Hellman (DH) [DH1977] and Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363]; the digital signature algorithms inclue RSA [RFC8017] and Elliptic Curve Digital Signature Algorithm (ECDSA) [FIPS186]. As a result, an adversary that stores a TLS 1.3 handshake protocol exchange today could decrypt the associated encrypted communications in the future when a large- scale quantum computer becomes available. > Section 4 >=20 > The client includes the "tls_cert_with_extern_psk" extension in the > ClientHello message. The "tls_cert_with_extern_psk" extension MUST > be accompanied by the "key_share", "psk_key_exchange_modes", and >=20 > Do we need to mandate anything about the contents of > "psk_key_exchange_modes" in this case? (I see we do say something = later > on in Section 5, so maybe not here. But see also the note about > duplication of normative requirements between Sections 4 and 5.) I think the discussion in Section 5 covers this extension well. RFC = 8446 defines two values (psk_ke and psk_dhe_ke), and both are discussed = in Section 5. > "pre_shared_key" extensions. The "pre_shared_key" extension MUST be > the last extension in the ClientHello message, and it provides a = list > of external PSK identifiers that the client is willing to use with > this server. [...] >=20 > I think that the last paragraph of > https://tools.ietf.org/html/rfc8446#section-4.2.11 is quite clear that > "pre_shared_key" must be the last extension, and we don't need to have > new normative language to require it. Okay. I'd like to preserve the reminder that the "pre_shared_key" = extension needs to come at the end. I suggest: The client includes the "tls_cert_with_extern_psk" extension in the ClientHello message. The "tls_cert_with_extern_psk" extension MUST be accompanied by the "key_share", "psk_key_exchange_modes", and "pre_shared_key" extensions. The client MAY also find it useful to include the "supported_groups" extension. Since the "tls_cert_with_extern_psk" extension is intended to be used only with initial handshakes, it MUST NOT be sent alongside the "early_data" extension. These extensions are all described in Section 4.2 of [RFC8446], which also requires the "pre_shared_key" extension to be the last extension in the ClientHello message. > The successful negotiation of the "tls_cert_with_extern_psk" > extension requires the TLS 1.3 key schedule processing to include > both the selected external PSK and the (EC)DHE shared secret value. >=20 > grammar pedant alert: I believe that this construction is parsed such > that inclusion of (both external PSK and ECDHE shared secret) in the = key > schedule is a prerequisite for successful negotiation, whereas the > intent is that successful negotiation implies the key schedule change. > One plausible "fix" (if any is indeed desired) would be "After > successful negotiation [...], it is required to adopt the TLS 1.3 key > schedule [...]", but there are probably better ones. I think this is an improvement: When the "tls_cert_with_extern_psk" extension is successfully negotiated, the TLS 1.3 key schedule processing includes both the selected external PSK and the (EC)DHE shared secret value. As a result, the Early Secret, Handshake Secret, and Master Secret values all depend upon the value of the selected external PSK. > As a result, the Early Secret, Handshake Secret, and Master Secret > values all depend upon the value of the selected external PSK. >=20 > (side note) Not that anyone here is likely to be confused, but the = Early > Secret does not incorporate the (EC)DHE shared secret. I don't really > see any reason to include a clarification about this, since the = current > text isn't really implying that it does, but will mention it in case > anyone feels differently. To make sure this is clear, I suggest and additional sentence to the = above: Of course, the Early Secret does not depend upon the (EC)DHE shared secret. > Each external PSK is associated with a single hash algorithm, which > is required by Section 4.2.11 of [RFC8446]. The hash algorithm MUST > be set when the PSK is established, with a default of SHA-256 if no > hash algorithm is specified during establishment. >=20 > This is likely to get flagged by the IESG -- it's a construction of = the > form "MUST do X, but if you don't do X, assume Y" that inherently > assumes the MUST will not always be adhered to. I think this says the same thing with a cleaner construction: Each external PSK is associated with a single hash algorithm, which is required by Section 4.2.11 of [RFC8446]. The hash algorithm MUST be set when the PSK is established, with a default of SHA-256. > Section 5 >=20 > Is there a useful way to group this content into sub-sections? Yes. I have introduces subsections to talk about the companion = extensions, authentication, and keying material. > appeared in the preceding ClientHello message. If an implementation > recognizes the "tls_cert_with_extern_psk" extension and receives it > in any other message, then the implementation MUST abort the > handshake with an "illegal_parameter" alert. >=20 > nit: "abort the handshake" is not quite right, since there are > Extensions blocks involved in post-handshake messages (NST, > CertificateRequest, etc.) which do not have a handshake to abort. I > think "terminate the connection with a alert" is the preferred > construction for this situation. Since the "tls_cert_with_extern_psk" extension MUST NOT appear in any = message other than the ClientHello message and the ServerHello message, = I think this is the correct construction. For example, Section 4.1.1 of = RFC 8446 says: ... If there is no overlap between the received "supported_groups" and the groups supported by the server, then the server MUST abort the handshake with a "handshake_failure" or an "insufficient_security" alert. > ClientHello message. If the server responds with a = HelloRetryRequest > message, then the client sends another ClientHello message as > described in Section 4.1.2 of [RFC8446], and it MUST include the = same > "tls_cert_with_extern_psk" extension as the original ClientHello > message or abort the handshake. >=20 > (This is another MUST that duplicates an existing requirement from RFC > 8446.) Okay. Reworded to remove the MUST: ... If the server responds with a HelloRetryRequest message, then the client sends another ClientHello message as described in Section 4.1.2 of [RFC8446], including the same "tls_cert_with_extern_psk" extension as the original ClientHello message or abort the handshake. > Many server extensions are carried in the EncryptedExtensions > message; however, the "tls_cert_with_extern_psk" extension is = carried > in the ServerHello message. It is only present in the ServerHello >=20 > I suggest adding a brief phrase noting that it's unfeasible to put = this > extension in the EncryptedExtensions since it affects what key is used > to encrypt that message. I suggest: Many server extensions are carried in the EncryptedExtensions message; however, the "tls_cert_with_extern_psk" extension is carried in the ServerHello message. Successful negotiation of the "tls_cert_with_extern_psk" extension affects the key used for encryption, so it cannot be carried in the EncryptedExtensions message. Therefore, the "tls_cert_with_extern_psk" extension is only present in the ServerHello message if the server recognizes the "tls_cert_with_extern_psk" extension and the server possesses one of the external PSKs offered by the client in the "pre_shared_key" extension in the ClientHello message. > To use an external PSK with certificates, clients MUST provide the > "tls_cert_with_extern_psk" extension, and it MUST be accompanied by > the "key_share", "psk_key_exchange_modes", and "pre_shared_key" > extensions in the ClientHello. If clients offer a > "tls_cert_with_extern_psk" extension without all of these other > extensions, servers MUST abort the handshake. The client MAY also >=20 > This seems redundant with the requirements from Section 4; is the > repetition necessary? I moved the one sentence that was not a repeat to Section 4 (as shown = above). With that done, the whole paragraph can be deleted. > find it useful to include the "supported_groups" extension. Note > that Section 4.2 of [RFC8446] allows extensions to appear in any > order, with the exception of the "pre_shared_key" extension, which > MUST be the last extension in the ClientHello. Also, there MUST NOT > be more than one instance of each extension in the ClientHello > message. >=20 > I'd prefer to either use direct quotations from RFC 8446 or = descriptive > versions of the requirements (without normative keywords). Okay. This one was deleted. > might supply via a subsequent NewSessionTicket. As a result, = clients > MUST include the psk_dhe_ke mode, and clients MAY also include the > psk_ke mode to support a subsequent NewSessionTicket. Servers MUST > select the psk_dhe_ke mode for the initial handshake. Servers MUST > select a key exchange mode that is listed by the client for > subsequent handshakes that include the resumption PSK from the > initial handshake. >=20 > I suppose it's probably implicit that "MUST select the psk_dhe_ke = mode" > is contingent on negotiating "tls_cert_with_extern_psk", but maybe > there's not any harm in making it explicit as well. I suggest: The "psk_key_exchange_modes" extension is defined in Section 4.2.9 of [RFC8446]. The "psk_key_exchange_modes" extension restricts both the use of PSKs offered in this ClientHello and those which the server might supply via a subsequent NewSessionTicket. As a result, when the "psk_key_exchange_modes" extension is included in the ClientHello message, clients MUST include psk_dhe_ke mode. In addition, clients MAY also include psk_ke mode to support a subsequent NewSessionTicket. When the "psk_key_exchange_modes" extension is included in the ServerHello message, servers MUST select the psk_dhe_ke mode for the initial handshake. Servers MUST select a key exchange mode that is listed by the client for subsequent handshakes that include the resumption PSK from the initial handshake. > The "pre_shared_key" extension is defined in Section 4.2.11 of > [RFC8446]. The syntax is repeated below for convenience. All of = the > listed PSKs MUST be external PSKs. >=20 > Should we specify that the server must abort the handshake if it = detects > a resumption PSK present in a ClientHello that contains > "tls_cert_with_extern_psk"? (What alert would be best in that case?) I suggest: The "pre_shared_key" extension is defined in Section 4.2.11 of [RFC8446]. The syntax is repeated below for convenience. All of the listed PSKs MUST be external PSKs. If a resumption PSK is listed along with the "tls_cert_with_extern_psk" extension, the server MUST abort the handshake with an "illegal_parameter" alert. > The obfuscated_ticket_age is not used for external PSKs; clients > SHOULD set this value to 0, and servers MUST ignore the value. >=20 > (These are the same requirements from RFC 8446, though it's probably > reasonable to repeat them here to confirm that they apply.) To be clear that these are not new requirements: The obfuscated_ticket_age is not used for external PSKs. As stated in Section 4.2.11 of [RFC8446], clients SHOULD set this value to 0, and servers MUST ignore the value. > The selected_identity contains the external PSK identity that the > server selected from the list offered by the client. If none of the >=20 > nit: it's the index of the identity, though it's unclear to what = length > we need to cover that in this document, since RFC 8446 is pretty clear > and available to the reader in case of confusion. I think that some context is useful, but I suggest getting rid of some = text: The selected_identity contains the index of the external PSK identity that the server selected from the list offered by the client. As described in Section 4.2.11.2 of [RFC8446], the server MUST validate the binder value that corresponds to the selected external PSK, and if the binder does not validate, the server MUST abort the handshake with an "illegal_parameter" alert. >=20 > The server > MUST validate the binder value that corresponds to the selected > external PSK as described in Section 4.2.11.2 of [RFC8446]. If the > binder does not validate, the server MUST abort the handshake with = an > "illegal_parameter" alert. Servers SHOULD NOT attempt to validate > multiple binders; rather they SHOULD select one of the offered > external PSKs and validate only the binder that corresponds to that > external PSK. >=20 > (This chunk also has pretty high overlap with existing RFC 8446 > requirements.) Agreed, and I proposed to reduce the repeated text above. > TLS 1.3 does not permit the server to send a CertificateRequest > message when a PSK is being used. This restriction is removed when > the "tls_cert_with_extern_psk" extension is negotiated, allowing > certificate-based authentication for both the client and the server. >=20 > We might get some questions about whether this weakening of an RFC = 8446 > requirement requires an "Updates:" relationship (problematic given = this > document is targetting Experimental status), but I don't think it's > necessary. (That text is relevant when the server is authenticating > solely with a PSK, which is not the case here.) I would argue that it is not a "weakening" for exactly this reason. The = TLS WG wanted to move forward with an Experimental RFC, so I assume that = it cannot update RFC 8446. > Section 7.1 of [RFC8446] specifies the TLS 1.3 Key Schedule. The > successful negotiation of the "tls_cert_with_extern_psk" extension > requires the key schedule processing to include both the external = PSK > and the (EC)DHE shared secret value. >=20 > Do we want to say "into the PSK and (EC)DHE inputs, respectively"? It > seems almost banal to do so, so maybe not... There are only two variable inputs, and then text says to "include = both", so I am not sure how "respectively" adds clarity. > If the client and the server have different values associated with > the selected external PSK identifier, then the client and the server > will compute different values for every entry in the key schedule, > which will lead to the termination of the connection with a > "decrypt_error" alert. >=20 > (side note) this is a case where "abort the handshake" would be > appropriate, though the verb tense into which we have to fit probably > makes the current wording better :) I suggest: If the client and the server have different values associated with the selected external PSK identifier, then the client and the server will compute different values for every entry in the key schedule, which will lead to the client aborting the handshake with a "decrypt_error" alert. > Section 6 >=20 > We also should probably say that it gets the "Recommended" value "N" > (not that we have any choice about it) and [this document] is the > reference. I suggest: IANA is requested to update the TLS ExtensionType Registry to include "tls_cert_with_extern_psk" with a value of TBD and the list of messages "CH, SH" in which the "tls_cert_with_extern_psk" extension may appear. > Implementations must protect the external pre-shared key (PSK). > Compromise of the external PSK will make the encrypted session > content vulnerable to the future invention of a large-scale quantum > computer. >=20 > ("invention" and "large-scale quantum computer" again, if we end up > making a pass to change either of those) I changed it to "development" as above. > Implementers should not transmit the same content on a connection > that is protected with an external PSK and a connection that is not. > Doing so may allow an eavesdropper to correlate the connections, > making the content vulnerable to the future invention of a large- > scale quantum computer. >=20 > I think I'm missing a step here. While it's clear that if the same > content is sent on two connections, and the attacker can correlate the > connections so as to know that fact, then the PSK-less connection can = be > attacked with the quantum computer and thus reveal the contents of the > PSK-protected connection, I'm not sure how just having the same = content > on the two connection allows the eavesdropper to correlate the > connections. Or is this just a more generic risk (e.g., timing/size > analysis) that's not particularly enabled by the external PSK > (non-)usage? The point is more straightforward than the correlation. if the content = requires protection from the future development of a large-scale quantum = computer, then sending it on a connection with external PSK protection = and one without external PSK protection leave the content vulnerable. > If the external PSK is known to any party other than the client and > the server, then the external PSK MUST NOT be the sole basis for > authentication. The reasoning is explained in [K2016] (see > Section 4.2). When this extension is used, authentication is based > on certificates, not the external PSK. >=20 > Are we talking about [K2016] as https://eprint.iacr.org/2016/711.pdf ? > I failed to find anything in Section 4.2 that considers the case when > the PSK is shared between more parties than just C and S. Yes. Footnote 6 says it, but you need a lot of context from earlier in = the paper to get the full consequences of that short statement. If you are aware of another reference that explains the situation, I'll = be glad to take a look. > 1.2 PRF. Thus, the safest approach is to use a PSK with either TLS > 1.2 or TLS 1.3. However, any PSK that might be used with both TLS > 1.2 and TLS 1.3 must be used with only one hash function, which is > the one that is bound for use in TLS 1.3. This restriction is less >=20 > nit(?): I suggest rewording "use a PSK with either TLS 1.2 or TLS = 1.3", > as the current wording can be confusing as to the exclusive nature of > the "or", perhaps to "the safest approach is to use any given PSK with > at most one of TLS 1.2 and TLS 1.3". I suggest: ... Thus, the safest approach is to use a PSK exclusively with TLS 1.2 or exclusively with TLS 1.3. ... > What is the origin of the "only one hash function" requirement? Section 4.2.11 of RFC 8446 says: Each PSK is associated with a single Hash algorithm. For PSKs established via the ticket mechanism (Section 4.6.1), this is the KDF Hash algorithm on the connection where the ticket was established. For externally established PSKs, the Hash algorithm MUST be set when the PSK is established or default to SHA-256 if no such algorithm is defined. The server MUST ensure that it selects a compatible PSK (if any) and cipher suite. {{Note the wording that you expect the IESG to complain about.}} > (Appendix E.7 of RFC 8446 only has this limitation apply to the TLS = 1.3 > usage, not the TLS 1.2 usage.) Observe that draft-ietf-tls-external-psk-importer is a way to handle = this situation. Given a PSK, one can derive another PSK for use with = TLS 1.2 and a different one for use with TLS 1.3. > than optimal when users want to provision a single PSK. While the > constructions used in TLS 1.2 and TLS 1.3 are both based on HMAC > [RFC2104], the constructions are different, and there is no known = way > in which reuse of the same PSK in TLS 1.2 and TLS 1.3 that would > produce related outputs. >=20 > (This also has pretty high overlap with Appendix E.7 of RFC 8446; do = we > need to inline it all as opposed to incorporating by reference?) I agree, and now that draft-ietf-tls-external-psk-importer is available, = I can suggest a way to handle the situation instead of just warning = about it: TLS 1.3 [RFC8446] takes a conservative approach to PSKs; they are bound to a specific hash function and KDF. By contrast, TLS 1.2 [RFC5246] allows PSKs to be used with any hash function and the TLS 1.2 PRF. Thus, the safest approach is to use a PSK exclusively with TLS 1.2 or exclusively with TLS 1.3. Given one PSK, one can derive a PSK for exclusive use with TLS 1.2 and derive another PSK for exclusive use with TLS 1.3 using the mechanism specified in [I-D.ietf-tls-external-psk-importer]. Thanks, Russ From nobody Mon Nov 11 11:32:47 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4B012084F for ; Mon, 11 Nov 2019 11:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=qqRoT8m3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=d7stDzz7 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 elu0oEKrbgYU for ; Mon, 11 Nov 2019 11:32:43 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BF8C12089C for ; Mon, 11 Nov 2019 11:32:20 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A01A221F8E for ; Mon, 11 Nov 2019 14:32:19 -0500 (EST) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Mon, 11 Nov 2019 14:32:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=3TmSNDI6Lu6UMSo5FCfTdrkPq23BOIz WAeCeRDInAeI=; b=qqRoT8m3PNVCqs1P7WE1KX75SaPZbM3nl7lreES6si56lUR VgIHP4szG6j3Y72G1OYoZ/PP0vrYkcLBmnQkH0P90zNCg+i7oOj3bUPV0FdYn1Cb ES7mE7dPvsWuDuD7rTWiCjzfFOlxLwezuf6eJpEvri4IjmAdSpIzza1HZHJNU4r2 2es4cY5B1Dz+3w1VgbCiFDdNcuHGtLJpc9BGmyqs6eTFd2lB7Dy32eYOFz0Jmt1H rYssCIQDfXOerQQ89YR2D2YEB2uHfID1PTpYbV8kJyrFTyKxhsDEPl+are60ExS4 1vJnvMJ7kIbO/bbSwo7QoCNBnppNGqEqODUwBGA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=3TmSND I6Lu6UMSo5FCfTdrkPq23BOIzWAeCeRDInAeI=; b=d7stDzz7SMAh+6VFSELerW 8+Yi1/haB7DwwAAT5AELDuyWcoy30WH2Ys4AMF0O8aMl6Wo9gbU33tF0WRW8Hvdn iIno66pRi/31emKzb7pisiK7ox6gocco/kTFDm1C/B0cWvEdkLDebPzaOOj6TOT+ T27xh8byylCGuFm7KNKzot+lJRxtkXuIrXG9Eeq9D/BMq38w6P8eKcZluOQSZfHj 6jCKO1Zymm7tnCoXHEm+KMhRPyeMdLSotPbOIhUtWebI2lJZF7xB32bVAuYzxETv UbDZN1ZHUgvENVAsvt4KKcY01TekwJF0bJ1/+McOimnVfZxwXRmwtfwibmBx/FiQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddvjedguddvkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggr fieshhgvrghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrgh enucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgv thenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 64A513C00A1; Mon, 11 Nov 2019 14:32:19 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> Date: Mon, 11 Nov 2019 11:31:59 -0800 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 19:32:46 -0000 The adoption call is now (belatedly) finished. At this time, there's not enough interest to take this on as a WG item. We encourage further discussion on the list, perhaps based on subsequent draft updates, and will revisit adoption in the future if interest grows. Best, Chris (on behalf of the chairs) On Fri, Oct 18, 2019, at 11:44 AM, Christopher Wood wrote: > This email starts a call for adoption of draft-davidben-tls13-pkcs1-00, > which can be found here: > > https://tools.ietf.org/html/draft-davidben-tls13-pkcs1-00 > > It will run until November 1, 2019. Please indicate whether or not you > would like to see this draft adopted and whether you will review and > provide feedback on it going forward. > > Thanks, > Chris, Joe, and Sean > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Mon Nov 11 11:54:08 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DD1120823; Mon, 11 Nov 2019 11:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 AOPGiN-RtKOI; Mon, 11 Nov 2019 11:54:05 -0800 (PST) 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 BCBFD120A0D; Mon, 11 Nov 2019 11:53:30 -0800 (PST) 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 xABJrQ6j016427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Nov 2019 14:53:28 -0500 Date: Mon, 11 Nov 2019 11:53:25 -0800 From: Benjamin Kaduk To: draft-ietf-tls-oldversions-deprecate.all@ietf.org Cc: tls@ietf.org Message-ID: <20191111195325.GE32847@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: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 19:54:07 -0000 Hi all, This is a "preliminary" review only because there's some strangeness relating to the Updates: (and Obsoletes:) headers, and any changes there would make me need to go and recheck the relationship of this document to the ones listed. So, I haven't done any of that yet, in an attempt to only have to do it once. Specifically, there's skew between the list of documents updated in the top header and the list in Section 1.1. Evern more annoyingly, the (tools) HTML version seems to be missing some numbers from the document header, that are present in the TXT version. (Henrik is going to take a look, per https://mailarchive.ietf.org/arch/msg/tools-discuss/Maeh0f_WfOy5sfnGQpwGPs_sYcU .) Additionally, Section 1.1 lists some RFCs that "have been obsoleted", but there is no "Obsoletes:" header at the top of the document. I think nits is right about references (square-bracketed "[RFC6347]") in the Abstract; we should change those to normal textual (parenthesed "(RFC 6347)") before IETF LC. Some other notes from a quick pass over the main text (though I'll probably read it again once the above are addressed) follow. Section 1 It feels a little backwards for a "primary technical reason" to deprecate a protocol version being that "at least one widely-used library has plans to drop [it]". I do appreciate that we give discussion about what we intend "deprecation" to mean and for whom -- thank you for that! Section 2 TLS 1.3, specified in TLSv1.3 [RFC8446], represents a significant change to TLS that aims to address threats that have arisen over the years. Among the changes are a new handshake protocol, a new key derivation process that uses the HMAC-based Extract-and-Expand Key Derivation Function (HKDF), and the removal of cipher suites that use static RSA or DH key exchanges, the CBC mode of operation, or SHA-1. The list of extensions that can be used with TLS 1.3 has been reduced considerably. While it's true that the initial list of extensions usable with TLS 1.3 is smaller than the list of extensions usable at TLS 1.2 taken at the same time, it's also true that the requirements for allocating a new extension codepoint have been reduced dramatically. So I think I'd say that this reflects not a desire to reduce the attack surface (as "measured" by number of extensions) but rather a paradigm shift in how the protocol works, which leaves some existing functionality incompatible with the new model. I don't really get a clear sense of what this current last sentence is trying to say (i.e., whether it's one of those two descriptions I offered above). Section 3 Similarly, the authentication of the handshake depends on signatures made using SHA-1 hash or a not stronger concatenation of MD-5 and SHA-1 hashes, allowing the attacker to impersonate a server when it is able to break the severely weakened SHA-1 hash. My recollection of the WG discussions (which I will go review) is that we don't really have consensus on the "not stronger" portion of this. Is that a key component of the document here? (N.B. this is *not* an invitation to rehash that discussion again! The chairs or I can provide a summary of points not resolved by previous discussion and points believed to be adequately agreed upon, which would be a trigger for any additional discussion that might be needed.) Thanks for putting this document together (I know that getting all the long list of references/updates/etc. right is really tedious and frustrating), and sorry to have been sitting on it for so long. -Ben From nobody Mon Nov 11 12:07:18 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57FFF12022E; Mon, 11 Nov 2019 12:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0NaqUH2INOS; Mon, 11 Nov 2019 12:07:14 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 725BD120105; Mon, 11 Nov 2019 12:07:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 103AEBE39; Mon, 11 Nov 2019 20:07:12 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHhWsKFDaPC2; Mon, 11 Nov 2019 20:07:10 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7D843BE2F; Mon, 11 Nov 2019 20:07:10 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1573502830; bh=v23njZr/lNR6zWX3VbxCZkuPYkl8b1Q9/1brePhP+8g=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=0lthYl0UW5yEayxsNlGl9qP8SGVAdmOIB546sOBtvJV7A0w249AmVAXrMYdP5gBh+ JH19Z/RV13UH+qyz+jtPA+3EV5b8KmMfnxgWi4cbiTO+RkzBT7XF/QhZYXffuDoYCU ZXqHofD8Yezy9bvu1EK/z/VOHBr9TdzxHP+NMBIY= To: Benjamin Kaduk , draft-ietf-tls-oldversions-deprecate.all@ietf.org Cc: tls@ietf.org References: <20191111195325.GE32847@kduck.mit.edu> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <0df737cb-4947-4926-2c6d-dd3583356a2c@cs.tcd.ie> Date: Mon, 11 Nov 2019 20:07:09 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <20191111195325.GE32847@kduck.mit.edu> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RRSXHzUjNijq66llGEpn5BBSmhIiIpndo" Archived-At: Subject: Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 20:07:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RRSXHzUjNijq66llGEpn5BBSmhIiIpndo Content-Type: multipart/mixed; boundary="t5OS9JLs6u1PpifKd6k2oVk0bQMOiwMqQ"; protected-headers="v1" From: Stephen Farrell To: Benjamin Kaduk , draft-ietf-tls-oldversions-deprecate.all@ietf.org Cc: tls@ietf.org Message-ID: <0df737cb-4947-4926-2c6d-dd3583356a2c@cs.tcd.ie> Subject: Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05 References: <20191111195325.GE32847@kduck.mit.edu> In-Reply-To: <20191111195325.GE32847@kduck.mit.edu> --t5OS9JLs6u1PpifKd6k2oVk0bQMOiwMqQ Content-Type: multipart/mixed; boundary="------------0BCCCD05CE6CE26799EADA4D" Content-Language: en-US This is a multi-part message in MIME format. --------------0BCCCD05CE6CE26799EADA4D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 11/11/2019 19:53, Benjamin Kaduk wrote: >=20 > This is a "preliminary" review only because there's some strangeness > relating to the Updates: (and Obsoletes:) headers, and any changes ther= e > would make me need to go and recheck the relationship of this document = to > the ones listed. So, I haven't done any of that yet, in an attempt to = only > have to do it once. >=20 > Specifically, there's skew between the list of documents updated in the= top > header and the list in Section 1.1.=20 Ah, the fun:-) Will take a look when I get some time, but might be whilst in or en-route to Singapore. If you've any examples you noted that might help, Cheers, S. --------------0BCCCD05CE6CE26799EADA4D Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------0BCCCD05CE6CE26799EADA4D-- --t5OS9JLs6u1PpifKd6k2oVk0bQMOiwMqQ-- --RRSXHzUjNijq66llGEpn5BBSmhIiIpndo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl3Jv20ACgkQWrL68XsX K+q56w/6AlKxjYNOqldQiwFF4zB9n7N6aB86thEvT1npuV5mCQtsg7ILuEfZk56j jb9TNfxNxT3670I7Ej1mhSw6KGWTO7Q2lopq8kCc4xEKSmeu5mYoTB8chJhGOgEb rJsdEC3mvmOfcSRukX6WkvyLRo2dtc3IagN7OB7JD2q6EW0PA9jCdmdy4II1GSNO S7G7Q+qbxztmqFUXid5EtjgZA+3wNYybYDA+jPMn9IwtbVTGCtKl8XfT0fQxqix7 h7fYcsTbKf6OZ310AX9rQcseT6Mjl+gtQmIFQxbU1kkPyD6unMF2oUU//zCcS5vX ZdadTzYQAZZ4GhAQGMOAOq+SahOUw8ooA/wlRYLr6KoZzhCHcRzEsbWC6qmuZzqy kc/6oqHGoCHXkEdr48syTm7dECfIIWGN0iDnwypEuGhmpQNopfljlv1jP3kzqc1R HAPqKda0HlKdjsDZNc2gFT+parcSWhOqteOfCwN8CV89NPQNZHIO2YKB41itDA/r xUNzE9NL/UgkUPFJbYlae877lJRJf/HEXOpbcarthyoEIisx47XUOpe0vU1F9l7X bZ5lyRGVKkuh5jFRyfdz9yDmQkPAlsHhDxhUF38uC1YDT30OnbdPlFiksksV7QAm AALx2KLyNSYNmeP4gIzMMiT79/AUWWLEyjJ34HFNf7Ka1GLoM78= =Tack -----END PGP SIGNATURE----- --RRSXHzUjNijq66llGEpn5BBSmhIiIpndo-- From nobody Mon Nov 11 12:27:23 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E98E120105; Mon, 11 Nov 2019 12:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 wL3FaxbXrYFy; Mon, 11 Nov 2019 12:27:21 -0800 (PST) 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 67D08120019; Mon, 11 Nov 2019 12:27:21 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xABKR9Mi019788; Mon, 11 Nov 2019 20:27:11 GMT 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=8uiz4GaYUxeCLWGBXoI6fUiDbQe2U2lW6BI3NYBcaIs=; b=W4mu8E61I7rESojOMGjSxT/MAWKiPWuJBV+hxb7eTzxeI3jMajpoZDpgLI2FlVvlHpxj WkZy27zMQd2xr78MzsiP9SXwQA+Rh4/5UNWPSBCZ6rfQh9/7iTzYZLADuScu52/apRUI eu7/hlMCjo1fyB2QNPccQNyWitb4oPFMeItEAQjACuW8W94LpyFrw9lO0+NmGNdhtdJf vUVpQzkIFVGb3ZqVXbNjD8OfS5itnUq+fDeJADQpfqacfWC5rWwgDaMhmIy2EFbHHx3W CkOJvgN0KDsNX10I4b1W/n8+xUZ34Z2iqccGhVpF/8jWbaOFLSWX37q14XvXc+4K3Io2 Vw== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2w5p6dtmw4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Nov 2019 20:27:11 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xABKGiXX028740; Mon, 11 Nov 2019 12:27:10 -0800 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint5.akamai.com with ESMTP id 2w5vabkch2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 11 Nov 2019 12:27:10 -0800 Received: from usma1ex-dag3mb6.msg.corp.akamai.com (172.27.123.54) by usma1ex-dag3mb4.msg.corp.akamai.com (172.27.123.56) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 11 Nov 2019 15:27:09 -0500 Received: from usma1ex-dag3mb6.msg.corp.akamai.com ([172.27.123.54]) by usma1ex-dag3mb6.msg.corp.akamai.com ([172.27.123.54]) with mapi id 15.00.1473.005; Mon, 11 Nov 2019 15:27:09 -0500 From: "Kaduk, Ben" To: Stephen Farrell , Benjamin Kaduk , "draft-ietf-tls-oldversions-deprecate.all@ietf.org" CC: "tls@ietf.org" Thread-Topic: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05 Thread-Index: AQHVmMnPh/VMWOqsHEmsQErybXbNUaeGuXCA//9/eQA= Date: Mon, 11 Nov 2019 20:27:09 +0000 Message-ID: References: <20191111195325.GE32847@kduck.mit.edu> <0df737cb-4947-4926-2c6d-dd3583356a2c@cs.tcd.ie> In-Reply-To: <0df737cb-4947-4926-2c6d-dd3583356a2c@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.81.18] Content-Type: text/plain; charset="utf-8" Content-ID: <76B605750A4E3E429D0F2059ECE09D44@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-11_06:, , 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911110176 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-11_06:2019-11-11,2019-11-11 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 adultscore=0 lowpriorityscore=0 bulkscore=0 malwarescore=0 priorityscore=1501 impostorscore=0 phishscore=0 mlxscore=0 mlxlogscore=999 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911110178 Archived-At: Subject: Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 20:27:23 -0000 VGhlIG9uZSBjb25jcmV0ZSBvbmUgdGhhdCBJIHJlbWVtYmVyIChhbmQgY2FuJ3QgYXR0cmlidXRl IHRvIHRoZSBIVE1MaXplZCB2ZXJzaW9uIGRyb3BwaW5nIHN0dWZmKSBpcyBSRkMgNzAzMCBvbmx5 IGluIHRoZSBoZWFkZXIuDQoNCkkgZ3Vlc3Mgd2UgY2FuIGNoZWNrIHdoYXQgd2Ugd2FudCB0byBk byB0byBEVExTIGFzIHdlbGwsIGFzIFJGQyA2MzQ3IGlzIGxpc3RlZCBhcyBVcGRhdGVzOi1lZCBi dXQgdGhhdCdzIHRoZSBEVExTIDEuMiBzcGVjLiAgKDYzNDcgaXRzZWxmIGNvbmZ1c2luZ2x5IGNs YWltcyBpbiB0aGUgYm9keSB0ZXh0IHRvICJ1cGRhdGUgRFRMUyAxLjAgdG8gd29yayB3aXRoIFRM UyAxLjIiIGJ1dCBoYXMgYW4gIk9ic29sZXRlczogNDM0NyIgaGVhZGVyLikgIEkgZG9uJ3Qgc2Vl IHdoYXQgc3BlY2lmaWNhbGx5IHdlIHVwZGF0ZSBpbiA2MzQ3Lg0KDQotQmVuDQoNClAuUy4gc29y cnkgZm9yIHRvcC1wb3N0OyBPdXRsb29rJ3MgcXVvdGluZyBvcHRpb25zIGFyZSAiYmFkIiBhbmQg IndvcnNlIg0KDQrvu79PbiAxMS8xMS8xOSwgMTI6MDcsICJTdGVwaGVuIEZhcnJlbGwiIDxzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllPiB3cm90ZToNCg0KICAgIA0KICAgIEhpeWEsDQogICAgDQog ICAgT24gMTEvMTEvMjAxOSAxOTo1MywgQmVuamFtaW4gS2FkdWsgd3JvdGU6DQogICAgPiANCiAg ICA+IFRoaXMgaXMgYSAicHJlbGltaW5hcnkiIHJldmlldyBvbmx5IGJlY2F1c2UgdGhlcmUncyBz b21lIHN0cmFuZ2VuZXNzDQogICAgPiByZWxhdGluZyB0byB0aGUgVXBkYXRlczogKGFuZCBPYnNv bGV0ZXM6KSBoZWFkZXJzLCBhbmQgYW55IGNoYW5nZXMgdGhlcmUNCiAgICA+IHdvdWxkIG1ha2Ug bWUgbmVlZCB0byBnbyBhbmQgcmVjaGVjayB0aGUgcmVsYXRpb25zaGlwIG9mIHRoaXMgZG9jdW1l bnQgdG8NCiAgICA+IHRoZSBvbmVzIGxpc3RlZC4gIFNvLCBJIGhhdmVuJ3QgZG9uZSBhbnkgb2Yg dGhhdCB5ZXQsIGluIGFuIGF0dGVtcHQgdG8gb25seQ0KICAgID4gaGF2ZSB0byBkbyBpdCBvbmNl Lg0KICAgID4gDQogICAgPiBTcGVjaWZpY2FsbHksIHRoZXJlJ3Mgc2tldyBiZXR3ZWVuIHRoZSBs aXN0IG9mIGRvY3VtZW50cyB1cGRhdGVkIGluIHRoZSB0b3ANCiAgICA+IGhlYWRlciBhbmQgdGhl IGxpc3QgaW4gU2VjdGlvbiAxLjEuIA0KICAgIA0KICAgIEFoLCB0aGUgZnVuOi0pDQogICAgDQog ICAgV2lsbCB0YWtlIGEgbG9vayB3aGVuIEkgZ2V0IHNvbWUgdGltZSwgYnV0IG1pZ2h0IGJlIHdo aWxzdA0KICAgIGluIG9yIGVuLXJvdXRlIHRvIFNpbmdhcG9yZS4gSWYgeW91J3ZlIGFueSBleGFt cGxlcyB5b3UNCiAgICBub3RlZCB0aGF0IG1pZ2h0IGhlbHAsDQogICAgDQogICAgQ2hlZXJzLA0K ICAgIFMuDQogICAgDQoNCg== From nobody Mon Nov 11 14:43:12 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141E8120803; Mon, 11 Nov 2019 14:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 7AaoUJ7N9nVB; Mon, 11 Nov 2019 14:43:08 -0800 (PST) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 C45291202A0; Mon, 11 Nov 2019 14:43:08 -0800 (PST) Received: by mail-il1-x12d.google.com with SMTP id i6so13608346ilr.11; Mon, 11 Nov 2019 14:43:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ul/KjuvizhMTBR4OejG+5LweF3UHot/WI12akQvDQQQ=; b=NJcVmXQcTuhgv+61euZglJj2AtYIGqUunEgxVHzIyXMkA2lEUN4xaubvBYFAhF1Q6u SfpAapaLKjMdR0+5kvEScJFHGJNPR9jgv0U/MSSAMYi3jin3huVmTaW/EAhNcFqUzRZg zAiN/xzdI6uUzjSlSvHAvLsPVjDZXG6PAb2zV37WXYCEVCNx0cfKEIB3fNzQfjF30Zob wWWFJULgHpkyIapQuqncUtIMhbCkmjxi/+FpYsychNeBuNMWGKk7cifeo3e/Y8WLbH+3 A5/N3Zu9Vj3QubN8hG0TahA9vMTjJwJKL+l8cUr8gdgzXrZSVEMSiZOMkIfy5+UMP5MF W0xw== 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=ul/KjuvizhMTBR4OejG+5LweF3UHot/WI12akQvDQQQ=; b=PiekC5oC45KmMdmPmNMoooAS/emq3OL9YgDScMt6KBqqshyZkMJFj0RRrytW0Q7GMn IFleOVIxjZdok7h/hnmw8O1woXXKUhUSpwkgjH7rhwkk446JDQ6pEpxicuVCQiNH9Lj1 fuYKc+YOdl6qLJ0H2OuBGCCjXI1nQziZN0mao12+KCNuwXV2mQwDi22L18oLWjr2G2Ja /IK6Gw+bfKT8RsqTjuXA55+L1vYQNAxFgoioNrkK+dlOlwWrPuRZUPD8DCzQnEBq2t70 1z+OvgHh6bmDAvPFtk2qu3s/1Zw8+XwKmGtYwVdO32ySDVyD1c4Jfe639T89xjHVR/MQ wf/Q== X-Gm-Message-State: APjAAAXm5gD3AFaZ5GvW9jc+S2+P4YRffijZrBKtqS9VzxiTzJyaUCNg E6r3Zfon3lSfa1PqTO5LI//jRdwrZL+RAbSbuiY= X-Google-Smtp-Source: APXvYqw9f004v/gIAGuqQfmSD9EofkGHxK3I6PofVeAj21AaN+9hCA1K+uJhXYyUXodZOWXiwebGFE2Ko9slosbBt7E= X-Received: by 2002:a92:8388:: with SMTP id p8mr33751778ilk.49.1573512187893; Mon, 11 Nov 2019 14:43:07 -0800 (PST) MIME-Version: 1.0 References: <20191111195325.GE32847@kduck.mit.edu> <0df737cb-4947-4926-2c6d-dd3583356a2c@cs.tcd.ie> In-Reply-To: From: Rob Sayre Date: Mon, 11 Nov 2019 14:42:56 -0800 Message-ID: To: "Kaduk, Ben" Cc: Stephen Farrell , "draft-ietf-tls-oldversions-deprecate.all@ietf.org" , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000025b1f059719db58" Archived-At: Subject: Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 22:43:11 -0000 --000000000000025b1f059719db58 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 11, 2019 at 12:27 PM Kaduk, Ben wrote: > The one concrete one that I remember (and can't attribute to the HTMLized > version dropping stuff) is RFC 7030 only in the header. > > I guess we can check what we want to do to DTLS as well, as RFC 6347 is > listed as Updates:-ed but that's the DTLS 1.2 spec. (6347 itself > confusingly claims in the body text to "update DTLS 1.0 to work with TLS > 1.2" but has an "Obsoletes: 4347" header.) I don't see what specifically > we update in 6347. > I think the text in question is the last paragraph of RFC 6347's Introduction: "Implementations that speak both DTLS 1.2 and DTLS 1.0 can interoperate with those that speak only DTLS 1.0 (using DTLS 1.0 of course), just as TLS 1.2 implementations can interoperate with previous versions of TLS (see Appendix E.1 of [TLS12] for details), with the exception that there is no DTLS version of SSLv2 or SSLv3, so backward compatibility issues for those protocols do not apply." This draft says "don't interoperate" in this situation. thanks, Rob --000000000000025b1f059719db58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 11, 2019 at 12:27 PM Kaduk, B= en <bkaduk@akamai.com> wrote= :
The one concrete one that I remember (and can't attribute = to the HTMLized version dropping stuff) is RFC 7030 only in the header.

I guess we can check what we want to do to DTLS as well, as RFC 6347 is lis= ted as Updates:-ed but that's the DTLS 1.2 spec.=C2=A0 (6347 itself con= fusingly claims in the body text to "update DTLS 1.0 to work with TLS = 1.2" but has an "Obsoletes: 4347" header.)=C2=A0 I don't= see what specifically we update in 6347.

=C2=A0I think the text in question is the last paragraph of RFC 6347'= ;s Introduction:

"Implementations that speak = both DTLS 1.2 and DTLS 1.0 can
=C2=A0 =C2=A0interoperate with those th= at speak only DTLS 1.0 (using DTLS 1.0 of
=C2=A0 =C2=A0course), just as = TLS 1.2 implementations can interoperate with
=C2=A0 =C2=A0previous vers= ions of TLS (see Appendix E.1 of [TLS12] for details),
=C2=A0 =C2=A0with= the exception that there is no DTLS version of SSLv2 or SSLv3,
=C2=A0 = =C2=A0so backward compatibility issues for those protocols do not apply.&qu= ot;

Th= is draft says "don't interoperate" in this situation.

thanks,
=
Rob

--000000000000025b1f059719db58-- From nobody Mon Nov 11 14:59:12 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD031120143 for ; Mon, 11 Nov 2019 14:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=HJKj1a9Q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KjLapcqx 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 XRj-3eS3aVRz for ; Mon, 11 Nov 2019 14:59:09 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87F2812002E for ; Mon, 11 Nov 2019 14:59:09 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id CB78020A0D for ; Mon, 11 Nov 2019 17:59:08 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 11 Nov 2019 17:59:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=h4NgREl/NfTXapRsmHsst+jELPkAtkw RaMJh8kFa4IQ=; b=HJKj1a9QLfioAX9ac0fc4/HfqGOIDvmtnHHyti073Gp3s6i 8kSMbUhTrXes1pPKspnJronYFyGakm61qcG0/ccJIPmhAxD9k4f5E8PLet41IG+Q 0wdmGxijHIeBbqdhi2wIsm7pQErAeb7L9ThsDO4MoLIx4ioBnempd9ub69DTqPi6 p6rOmMGFux7UZc/V2IUtURG6BgMevp+7tkkX6skEUJjT+eF9dUZOHnVSJ+S6AuBt 7YCzpTF4Krr0BmQ+G8xejKdBlW82HZa+KZjOm7GAbNy0ob7FyEtgvXYLecllOJq8 +1BrtOctjOAfcxFe3zCqij8FPnycCaF/0++lyxA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=h4NgRE l/NfTXapRsmHsst+jELPkAtkwRaMJh8kFa4IQ=; b=KjLapcqxtdITv6xluchTDB yEXlgHukSfcYGqrMdtaQnJSoFsmdXMpuYnRII/iqPrJsBCUvH6EvZ2q8YgUoPl2D Jq307tuxmK/vDw5YE4EZuUbCiMxRejc0lxviFmPtUERB9UBbl59RrntYpVWZPRu+ LUu6iwcrtdkY/abXaBI1VzzYQHDvOTfJhJqajzigMeGaZoDYMleXi9k2iQFQfGNT 3gium7D6PZyG6h37Hl4hsz1Zk63DjjZ6d3QsaHZRLAFRaIaRDcIXAzaUvNEZHiTu PAltnjxtfG7+c9q1zwlVM2+oRQqbmdVtB/a6POXsuswiDzT2z6T9aRP8ymbILrvw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddvjedgudejudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslh hofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7E6B6E00A3; Mon, 11 Nov 2019 17:59:08 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1 Mime-Version: 1.0 Message-Id: <9a090f7e-a408-45e2-8707-c90f1b14a591@www.fastmail.com> In-Reply-To: References: <20191111195325.GE32847@kduck.mit.edu> <0df737cb-4947-4926-2c6d-dd3583356a2c@cs.tcd.ie> Date: Tue, 12 Nov 2019 09:58:48 +1100 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] =?utf-8?q?preliminary_AD_review_of_draft-ietf-tls-oldversi?= =?utf-8?q?ons-deprecate-05?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 22:59:11 -0000 Since Rob quoted this: On Tue, Nov 12, 2019, at 09:42, Rob Sayre wrote: > with the exception that there is no DTLS version of SSLv2 or SSLv3, ...also on this list is TLS 1.0. DTLS 1.0 is TLS 1.1. From nobody Mon Nov 11 19:04:29 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC9F12011B for ; Mon, 11 Nov 2019 19:04:27 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 sOONlzG318t5 for ; Mon, 11 Nov 2019 19:04:25 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 9C7CA120110 for ; Mon, 11 Nov 2019 19:04:24 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id r144so17052560iod.8 for ; Mon, 11 Nov 2019 19:04:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=32EZnCMyJh32XmjOoq/zPwOd6O0IkvmdtVuo+4T1LtY=; b=tEHNEW/f+7ATMy+Cd5846rYnpaVdhPum1l+C8C6nUuwhDQq4tR7hJsa6WqrQZuML8Y JbRXmx7Yn8k5spHqiWnlNTgB9Pxjx1M6+MXdiWSJdRyGjdTZ021LTkYbY3f8lBKHQ7B9 ARCz4B7ifXwPbcfHRU7oRH725fcK+TfWlTKCrZmDjtuEEJRagU4qGxdnbRX7sFlrZquL UL465wrkuetlWRAU4j2651FJK2AGBIDPkWFYWwZ+Xc49Q3B9RwuRQpMFDa8MvBd6tTnG DoGImE5Wz9l1Ctjn/G7da2/aweVCkPd40zaR3/btbYBkt3t5n+DN8TPcdPOPCQKJiDmJ /E8A== 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=32EZnCMyJh32XmjOoq/zPwOd6O0IkvmdtVuo+4T1LtY=; b=U0fpF8zP5kK1GeQ25db3WwdW0kC5IUbetx4qibC2u60Za5HF7D8dG8un6pOVJHtMuY NRDN+ItREIHQ1pqfOMoxUHhzw77okBIUmpxEitZFv4MK0iWDICphIwd2MH6dcQ5uM6WL TJzo0fBneD+A6UgPplclpDkfvDt1bcSUsFg0AoTuk1d6jIB1MCnORA1VCD5JQX88YwA2 jxlx+qucvHdoo28r1npEwqyh7EVDoWCROtgpHQO5pU64/yzIBrEmddy23a03FimUeoTu cYssWTHmZl80hwH2baAlko5keNG0Eg65umKHc9u4dfVhN0Dcc6THW2xjy0Z3z108mtmz 0CPw== X-Gm-Message-State: APjAAAUKWG7VsxLRAU6OQSedySxLj6XEIV19Mb6R0kX1T5bb382m8IOF F/Wfpdl+WG89+D7ys1TdGd+20wzh9pQiIFWnNnOTJ8iVKpX2RQ== X-Google-Smtp-Source: APXvYqyLXcchIGTMrNrfh/vX+oZChWqu84UoZGBi/1cLF9aGD0sw4KdFnJwbOMGgsAKlMwZFcC/HXNTMd18y3q86YjU= X-Received: by 2002:a02:740a:: with SMTP id o10mr3796664jac.106.1573527863638; Mon, 11 Nov 2019 19:04:23 -0800 (PST) MIME-Version: 1.0 References: <20191111195325.GE32847@kduck.mit.edu> <0df737cb-4947-4926-2c6d-dd3583356a2c@cs.tcd.ie> <9a090f7e-a408-45e2-8707-c90f1b14a591@www.fastmail.com> In-Reply-To: <9a090f7e-a408-45e2-8707-c90f1b14a591@www.fastmail.com> From: Rob Sayre Date: Mon, 11 Nov 2019 19:04:12 -0800 Message-ID: To: Martin Thomson Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005b409805971d8127" Archived-At: Subject: Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 03:04:28 -0000 --0000000000005b409805971d8127 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 11, 2019 at 2:59 PM Martin Thomson wrote: > Since Rob quoted this: > > On Tue, Nov 12, 2019, at 09:42, Rob Sayre wrote: > > with the exception that there is no DTLS version of SSLv2 or SSLv3, > > ....also on this list is TLS 1.0. DTLS 1.0 is TLS 1.1. > That passage in RFC 6347 does indeed seem incomplete. However, I think the general point stands, because draft-ietf-tls-oldversions-deprecate-05 deprecates TLS 1.1.* thanks, Rob --0000000000005b409805971d8127 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 11, 2019 at 2:59 PM Martin Th= omson <mt@lowentropy.net> wr= ote:
Since Rob quoted this:

On Tue, Nov 12, 2019, at 09:42, Rob Sayre wrote:
>=C2=A0 with the exception that there is no DTLS version of SSLv2 or SSL= v3,

....also on this list is TLS 1.0.=C2=A0 DTLS 1.0 is TLS 1.1.

That passage in RFC 6347 does indeed seem incomplete.= However, I think the general point stands, because draft-ietf-tls-oldversi= ons-deprecate-05 deprecates TLS 1.1.*

thanks,
Rob
--0000000000005b409805971d8127-- From nobody Tue Nov 12 07:58:45 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0C012006F for ; Tue, 12 Nov 2019 07:58:44 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 uE35jfFp5oAF for ; Tue, 12 Nov 2019 07:58:41 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 E534512007C for ; Tue, 12 Nov 2019 07:58:40 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id p18so18399182ljc.6 for ; Tue, 12 Nov 2019 07:58:40 -0800 (PST) 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=wKYkbWHLJOU9BmnmYLJyARQPVMe2ynxU9WE0npcgiQg=; b=BjRSUA3KQBqQYST8T6yOfOCuEWru0dD0lYR0AAV5byKnARJd+3FvM5Gicd0TI74KAr JhP0y9cdqJTOSY9C1xMuiv0ZC3X+SAxiE5HHYUoC+aYmMDt4cCLZNN2wq2I5w/NOVrO0 9Rbbmjiw4ZN+gWCyQ25RFpwC0/beHzh2/45bNWWZBVeLd3Ixds4EAv0E4kWMqF5KMOro HA4sKNn/YDHCSOA5kZMUiR8yPjHUBCeGkcC7uKcg8/YmE/jMzu8X/yg/NOgYPTrjEZDE w7ifQUqfZaYlIdVhIJCkV/eB0LenUP8xCJewqwtLxBFZR3ekeKxUIhIvgMZR0wmby4tg WI2A== 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=wKYkbWHLJOU9BmnmYLJyARQPVMe2ynxU9WE0npcgiQg=; b=VW/f/H12Bzv5DJ/+lYuicwztdzps6wWvuoImmI7p5I+DkzhcMRwNFgbze53E2uyUwx LC9/lw1VaAFNPn26UIM/LlouCZ+B3QicZf3AKpsnL9Vmx0NJ7k4iPx/DkztrXCpGnIzV D+kbzNX5/Nxm2xMw/8gUSevI0hp9m7PEuCyib7JDiSOV7v/scU7ex/d/LMpGBM+4819q n/mQ8GHD45jBga5kpRIe1IJ+oadop3QFUpDedYbvucZ2ahc5A/xuS7A8ozU9jN4a/Zdx jfBeUcM3MohKuL6XDme2Aq3qtdRnaJYF3fC8wH/k/QIfK68mMi3MAjUHCEVrHQkHheZW n4yg== X-Gm-Message-State: APjAAAXljCqMQ3B3TnCBWLMNUtNGOuBM1lvIeNzgZqvRUNRYU//WkKzq Ljp7oSYsc065Dgc3Oigyca/fTemHPZwGMd18MtyMGw== X-Google-Smtp-Source: APXvYqw9F0Zxz67EAFc7VZ+TCxhPvvjAfmwr47a6xW+BAkJ0IOvti+xae/qeRHw3skVKnCmwTCYzCx+zFvllZSmhsHk= X-Received: by 2002:a2e:9842:: with SMTP id e2mr20699673ljj.93.1573574319185; Tue, 12 Nov 2019 07:58:39 -0800 (PST) MIME-Version: 1.0 References: <20191111195325.GE32847@kduck.mit.edu> <0df737cb-4947-4926-2c6d-dd3583356a2c@cs.tcd.ie> In-Reply-To: From: Eric Rescorla Date: Tue, 12 Nov 2019 07:58:02 -0800 Message-ID: To: Rob Sayre Cc: "Kaduk, Ben" , "tls@ietf.org" , "draft-ietf-tls-oldversions-deprecate.all@ietf.org" Content-Type: multipart/alternative; boundary="00000000000052b36c05972852fb" Archived-At: Subject: Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 15:58:44 -0000 --00000000000052b36c05972852fb Content-Type: text/plain; charset="UTF-8" On Mon, Nov 11, 2019 at 2:43 PM Rob Sayre wrote: > On Mon, Nov 11, 2019 at 12:27 PM Kaduk, Ben wrote: > >> The one concrete one that I remember (and can't attribute to the HTMLized >> version dropping stuff) is RFC 7030 only in the header. >> >> I guess we can check what we want to do to DTLS as well, as RFC 6347 is >> listed as Updates:-ed but that's the DTLS 1.2 spec. (6347 itself >> confusingly claims in the body text to "update DTLS 1.0 to work with TLS >> 1.2" but has an "Obsoletes: 4347" header.) I don't see what specifically >> we update in 6347. >> > > I think the text in question is the last paragraph of RFC 6347's > Introduction: > > "Implementations that speak both DTLS 1.2 and DTLS 1.0 can > interoperate with those that speak only DTLS 1.0 (using DTLS 1.0 of > course), just as TLS 1.2 implementations can interoperate with > previous versions of TLS (see Appendix E.1 of [TLS12] for details), > with the exception that there is no DTLS version of SSLv2 or SSLv3, > so backward compatibility issues for those protocols do not apply." > > This draft says "don't interoperate" in this situation. > I don't typically get too exercised about what appears in these metadata headers, but I don't actually think this updates 6347. The statement there is still true, we just tell you not to do it. -Ekr > thanks, > Rob > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000052b36c05972852fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 11, 2019 at 2:43 PM Rob S= ayre <sayrer@gmail.com> wrote= :
On Mon, Nov 11, 2019 at 12:27 PM Kaduk, Ben <bkaduk@akamai.com> w= rote:
The one concrete one that I remember (and can't attrib= ute to the HTMLized version dropping stuff) is RFC 7030 only in the header.=

I guess we can check what we want to do to DTLS as well, as RFC 6347 is lis= ted as Updates:-ed but that's the DTLS 1.2 spec.=C2=A0 (6347 itself con= fusingly claims in the body text to "update DTLS 1.0 to work with TLS = 1.2" but has an "Obsoletes: 4347" header.)=C2=A0 I don't= see what specifically we update in 6347.

=C2=A0I think the text in question is the last paragraph of RFC 6347'= ;s Introduction:

"Implementations that speak = both DTLS 1.2 and DTLS 1.0 can
=C2=A0 =C2=A0interoperate with those th= at speak only DTLS 1.0 (using DTLS 1.0 of
=C2=A0 =C2=A0course), just as = TLS 1.2 implementations can interoperate with
=C2=A0 =C2=A0previous vers= ions of TLS (see Appendix E.1 of [TLS12] for details),
=C2=A0 =C2=A0with= the exception that there is no DTLS version of SSLv2 or SSLv3,
=C2=A0 = =C2=A0so backward compatibility issues for those protocols do not apply.&qu= ot;

Th= is draft says "don't interoperate" in this situation.

I don't typically get too exercise= d about what appears in these metadata headers, but I don't actually th= ink this updates 6347. The statement there is still true, we just tell you = not to do it.

-Ekr


thanks,
Rob

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000052b36c05972852fb-- From nobody Tue Nov 12 07:58:58 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFA81208BA for ; Tue, 12 Nov 2019 07:58:54 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 p4MzBcg3v0-g for ; Tue, 12 Nov 2019 07:58:52 -0800 (PST) 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 551E91208C6 for ; Tue, 12 Nov 2019 07:58:52 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id d22so6866343lji.8 for ; Tue, 12 Nov 2019 07:58:52 -0800 (PST) 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=vqx8k7Yft+1F75aPw+i8lPoqRUtMxR6SvStcKrteGak=; b=wL96usOyNwr25p7IkT5tuadBNtDbivMkfckkqlau7WMBDQNijuZvPObcpttyBAkSsr MXvn5aXBpvTMD7qC3MPJuW6HPBjnlds4u+W+fjzS9YUC7qEvaZNUJw9tqYXnIQ9VaHNh 6OBTrFt+UM7kY09zYAYHozi56wpsjhlRpnWn6Q47cwsyUx/Z9p7HOkeE2C1h+FZ3ohcM LeK8qoHqAA5IjrN0FG27Wa2BkE7Cg2IpCcCKbWDyg4W3S5HK8sJ9REwsioTcnorSxjy4 tmJdbupvs75KMCDqqGxZ+uJfK9xmIGLjWl5leyJgf1g+2jTRfbGOQr3sp6v1jd7ArsO/ /uvw== 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=vqx8k7Yft+1F75aPw+i8lPoqRUtMxR6SvStcKrteGak=; b=ioU2sPh4OWY2MJoXzc2lODXrk+wuu31bIjk2Mb9qP6IDdjCQ7in7sh91aX3Dnew/8G 9jmD626t8tOo0uhK/uaoDYvYCkf14aI7riYysWdmdUF1IyTICZm74tGHmlsismHo2c4z Sb39MVV/8Vx8nREg1nI0OjjmVyHrMrE3xLnwlZXX9EgpxDKFDyuXuwipUtEmPO3GKj5k SfdYcXsiFqRNGDDe/pslERLUZOcBAMdJn9/VQitgYhIWnZLc6QxXxcVwlWr/ZmFyCasG puIcf6uL/oEboHWbV9/dQqmeuFN3vCuCLGq31lzjaZXulMRQi8x/PfnLn5lPqcNw3bOf MGOQ== X-Gm-Message-State: APjAAAXRiawLLg7iwQNO/Xv0VO6kPaJil1yOaKHY4o5ivMGfvY+eOB4D Uy4eGPu3LDr7oPw90gMS7xH2b1vcMXNEuCQXqk2A9Mok X-Google-Smtp-Source: APXvYqxOcVzt3AeUyr+UnKHEg4LuT762ZfJGWE6QH8khc+dHYj128b7R4TB1Ct+e4ft+Y1LPzq9aH3jBW7HhDCnqIyc= X-Received: by 2002:a05:651c:1196:: with SMTP id w22mr21185445ljo.217.1573574330601; Tue, 12 Nov 2019 07:58:50 -0800 (PST) MIME-Version: 1.0 References: <20191111195325.GE32847@kduck.mit.edu> <0df737cb-4947-4926-2c6d-dd3583356a2c@cs.tcd.ie> <9a090f7e-a408-45e2-8707-c90f1b14a591@www.fastmail.com> In-Reply-To: <9a090f7e-a408-45e2-8707-c90f1b14a591@www.fastmail.com> From: Eric Rescorla Date: Tue, 12 Nov 2019 07:58:14 -0800 Message-ID: To: Martin Thomson Cc: "" Content-Type: multipart/alternative; boundary="00000000000000e7f005972853b4" Archived-At: Subject: Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 15:58:57 -0000 --00000000000000e7f005972853b4 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 11, 2019 at 2:59 PM Martin Thomson wrote: > Since Rob quoted this: > > On Tue, Nov 12, 2019, at 09:42, Rob Sayre wrote: > > with the exception that there is no DTLS version of SSLv2 or SSLv3, > > ....also on this list is TLS 1.0. DTLS 1.0 is TLS 1.1. > Yes, but that's presumably an erratum. -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000000e7f005972853b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 11, 2019 at 2:59 PM Marti= n Thomson <mt@lowentropy.net>= ; wrote:
Since R= ob quoted this:

On Tue, Nov 12, 2019, at 09:42, Rob Sayre wrote:
>=C2=A0 with the exception that there is no DTLS version of SSLv2 or SSL= v3,

....also on this list is TLS 1.0.=C2=A0 DTLS 1.0 is TLS 1.1.

Yes, but that's presumably an erratum.
=
-Ekr


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000000e7f005972853b4-- From nobody Tue Nov 12 09:57:02 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D39612098C; Tue, 12 Nov 2019 09:57:01 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 OPqR1-MW3JXU; Tue, 12 Nov 2019 09:56:58 -0800 (PST) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 548001208F5; Tue, 12 Nov 2019 09:56:58 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id u17so11479634ilq.5; Tue, 12 Nov 2019 09:56:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fwv2VCr6eFbzzOv1FQxw/YFcNkgMSd4Iu9grLzsiUjU=; b=C3Ip84w9E6bEPodzwtBXatvt9S4Xa2Yp5y93zxJanojQq3Nyu/rH/Ys3hvksziI2ao ckjvhy7bGtdxiGXNY4S1/Zj6UVKJ+PC04bzyUyS3art8BbkEFQiWty5E5x+fVpxRCj7j 4xU+R3VwxMIQOL9M0RX3DCwcFQ8rlnN4X0DMYaE7ueYQ/mZ5xFhnPM4JLwaalflauzqU 79kUjLg4mgRIYy0xh6Sel60GbpYOyzCwCfLkr9yI4OCs0yqM+T69oH4E3uz497g++1rv uPOtZ9eMHeilCu75ObIGg1DhCGSWnWzHO/+THG2DUD6xaI4bfq60GqYTY5nH0lc1UEVw ntDA== 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=Fwv2VCr6eFbzzOv1FQxw/YFcNkgMSd4Iu9grLzsiUjU=; b=j/UhdVQRIaE1uDrbZO/Did6VUTWcWWg738TZtUvv+oE0ynDbjSRSqqdXHrnwTbwfp0 UnqmjA3lAblNL5cCYGejCO/cBiQ9OgHHS6Qdk5T9e66hd/Okl1ceuf3W/ATC9Zv41mK+ 9VndRd0SAasefnznRBgRS8qk/ZWUHIEZgRZOXjlJRJyDvrqaIx0Gt8VPwZLtVmOUJADD 8gQsh84hwUGV//+gpd7ibQ88Gi98+fL+1fqHzFobvHCD85m1yFAdMqX/iJnanj6A5FEp bOjHoja4oMWRg/XxsVclTJz8hrs7QJmQoKq1gZASsVHHeEJpt+jUorENyfDF+lhX0hfk zWwA== X-Gm-Message-State: APjAAAWXcKlgeuIegeDtvxYdyv7yM08bf8Z6wflFRFuD+TbFh0ey33Pr 6eSQYxRWtex1mEKuAuLnG64FV1ALVg36n64/ivY= X-Google-Smtp-Source: APXvYqytZ6QuK1nNjRu6CUsxY8Aeyqazjc92ic/j1prS+C7ZtHc8svbr2G73XIeGeBqyNmGGj3NpwbAAEm6WS6UqIQ8= X-Received: by 2002:a92:5d49:: with SMTP id r70mr38631221ilb.257.1573581417505; Tue, 12 Nov 2019 09:56:57 -0800 (PST) MIME-Version: 1.0 References: <20191111195325.GE32847@kduck.mit.edu> <0df737cb-4947-4926-2c6d-dd3583356a2c@cs.tcd.ie> In-Reply-To: From: Rob Sayre Date: Tue, 12 Nov 2019 09:56:46 -0800 Message-ID: To: Eric Rescorla Cc: "Kaduk, Ben" , "tls@ietf.org" , "draft-ietf-tls-oldversions-deprecate.all@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006a6c43059729f95f" Archived-At: Subject: Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 17:57:01 -0000 --0000000000006a6c43059729f95f Content-Type: text/plain; charset="UTF-8" On Tue, Nov 12, 2019 at 7:58 AM Eric Rescorla wrote: > > > On Mon, Nov 11, 2019 at 2:43 PM Rob Sayre wrote: > >> On Mon, Nov 11, 2019 at 12:27 PM Kaduk, Ben wrote: >> >>> The one concrete one that I remember (and can't attribute to the >>> HTMLized version dropping stuff) is RFC 7030 only in the header. >>> >>> I guess we can check what we want to do to DTLS as well, as RFC 6347 is >>> listed as Updates:-ed but that's the DTLS 1.2 spec. (6347 itself >>> confusingly claims in the body text to "update DTLS 1.0 to work with TLS >>> 1.2" but has an "Obsoletes: 4347" header.) I don't see what specifically >>> we update in 6347. >>> >> >> I think the text in question is the last paragraph of RFC 6347's >> Introduction: >> >> "Implementations that speak both DTLS 1.2 and DTLS 1.0 can >> interoperate with those that speak only DTLS 1.0 (using DTLS 1.0 of >> course), just as TLS 1.2 implementations can interoperate with >> previous versions of TLS (see Appendix E.1 of [TLS12] for details), >> with the exception that there is no DTLS version of SSLv2 or SSLv3, >> so backward compatibility issues for those protocols do not apply." >> >> This draft says "don't interoperate" in this situation. >> > > I don't typically get too exercised about what appears in these metadata > headers, but I don't actually think this updates 6347. The statement there > is still true, we just tell you not to do it. > Well... I think the clearest definition of "updates" is in RFC 2223: https://tools.ietf.org/html/rfc2223#section-12 "... e.g., an addendum, or separate, extra information that is to be added to the original document." thanks, Rob --0000000000006a6c43059729f95f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 12, 2019 at 7:58 AM Eric = Rescorla <ekr@rtfm.com> wrote:
<= div dir=3D"ltr">

On Mon, Nov 11, 2019 at 2:43 PM Rob Sayre <sayrer@gmail.com> wro= te:
On Mon, Nov 11, 2019 at 12:27 PM Kaduk, Ben <bkaduk@akamai.com>= wrote:
The one concrete one that I remember (and can't attr= ibute to the HTMLized version dropping stuff) is RFC 7030 only in the heade= r.

I guess we can check what we want to do to DTLS as well, as RFC 6347 is lis= ted as Updates:-ed but that's the DTLS 1.2 spec.=C2=A0 (6347 itself con= fusingly claims in the body text to "update DTLS 1.0 to work with TLS = 1.2" but has an "Obsoletes: 4347" header.)=C2=A0 I don't= see what specifically we update in 6347.

=C2=A0I think the text in question is the last paragraph of RFC 6347'= ;s Introduction:

"Implementations that speak = both DTLS 1.2 and DTLS 1.0 can
=C2=A0 =C2=A0interoperate with those th= at speak only DTLS 1.0 (using DTLS 1.0 of
=C2=A0 =C2=A0course), just as = TLS 1.2 implementations can interoperate with
=C2=A0 =C2=A0previous vers= ions of TLS (see Appendix E.1 of [TLS12] for details),
=C2=A0 =C2=A0with= the exception that there is no DTLS version of SSLv2 or SSLv3,
=C2=A0 = =C2=A0so backward compatibility issues for those protocols do not apply.&qu= ot;

Th= is draft says "don't interoperate" in this situation.

I don't typically get too exercise= d about what appears in these metadata headers, but I don't actually th= ink this updates 6347. The statement there is still true, we just tell you = not to do it.

Well... I t= hink the clearest definition of "updates" is in RFC 2223:


"... e.g., an addendum, or separate, extra information that is to b= e added to the original document."

thanks,
Rob

--0000000000006a6c43059729f95f-- From nobody Tue Nov 12 10:24:32 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26479120A43 for ; Tue, 12 Nov 2019 10:24:31 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 DGnAVovETOi4 for ; Tue, 12 Nov 2019 10:24:26 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 3FEDB120946 for ; Tue, 12 Nov 2019 10:24:25 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id t5so18947975ljk.0 for ; Tue, 12 Nov 2019 10:24:25 -0800 (PST) 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=D08vZjThllY0RvkhROl5KrWAY9XaJwDECW/4zxxQrMU=; b=aG1c9YgwKELpy/0c5iHv6T6yLLwBAWZk2Uq94ihd4aDt7mZ+Hq3D9UzvBVxxDu+tlD ZtDdAqz3X8Lquo5Lik50yiNkn2R4U8ACB/MiA6Etq+X3OI+kpMtVK6Me7hEoI2L2jkQG 3YYGDOa9rMoDVo2Q0vlBtaAThWmBXzSPdh8PHPlMIzWY25HYgz2T+x1fcKhBSEnR1537 EWrudErii58F/q/He+WwuneCScILj0QUSYXHz9OS5WTRLrjdeiIAKiQUJ30zqjDFjlCX wN7zfDuKX06y00tNp2n9eB5kzKqCPpbRWoZY3UZ/7HabHnIcDxLOGk/skSzBOgBg8cxb 1P5w== 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=D08vZjThllY0RvkhROl5KrWAY9XaJwDECW/4zxxQrMU=; b=rBIYlb7DjZDyqD0ssrh2bPfVUEDUdHjUMeQjv1C+/ly/59dHAmD5igeXQvQsoF+Fdn NURWuZ8l775uAqM8ChQkzPUn39EPgNfBYgfmXBmlH3iPI05HQsXAthZSBAcOaH8tFRH2 ibsGmmwgZMB+cdtig+NBVfL6Q4Sl7WplyzUeEIlfynX3/Hq90yh/iVqRJdgSQZHYZ5f4 MdJ8zy/ePY6kCcM1VVoU+ZBIqkuTkvIDVw+j8XaK8cJ307SWV4VGy9cp/6/UNyonct2l 9qb2wF+RjAjO8q/MGLCs1uTs/+XMpxTk4fMWuFKuvm9xnrHJb91KH3BjnHuqVR44BVjJ B7YQ== X-Gm-Message-State: APjAAAWy/jwrQZxfUPl/wxo2xKE+nW1VMQlyV5U/tUKh98kOlOvNDHUl shKWoc8kmMLmUQ1yvGCVL78GKQYn8BWDa0wdgmlUmw== X-Google-Smtp-Source: APXvYqx/HxDfT58y1lKK/crabvbKHhLVJazWAszL4y3x3N66TTH2rVe1T3dbQyL5aM+ig/DVDUBVkKNHkEGQQLtjuvg= X-Received: by 2002:a2e:7301:: with SMTP id o1mr13437111ljc.16.1573583063503; Tue, 12 Nov 2019 10:24:23 -0800 (PST) MIME-Version: 1.0 References: <20191111195325.GE32847@kduck.mit.edu> <0df737cb-4947-4926-2c6d-dd3583356a2c@cs.tcd.ie> In-Reply-To: From: Eric Rescorla Date: Tue, 12 Nov 2019 10:23:46 -0800 Message-ID: To: Rob Sayre Cc: "Kaduk, Ben" , "tls@ietf.org" , "draft-ietf-tls-oldversions-deprecate.all@ietf.org" Content-Type: multipart/alternative; boundary="00000000000086698605972a5b0c" Archived-At: Subject: Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 18:24:31 -0000 --00000000000086698605972a5b0c Content-Type: text/plain; charset="UTF-8" On Tue, Nov 12, 2019 at 9:56 AM Rob Sayre wrote: > > > On Tue, Nov 12, 2019 at 7:58 AM Eric Rescorla wrote: > >> >> >> On Mon, Nov 11, 2019 at 2:43 PM Rob Sayre wrote: >> >>> On Mon, Nov 11, 2019 at 12:27 PM Kaduk, Ben wrote: >>> >>>> The one concrete one that I remember (and can't attribute to the >>>> HTMLized version dropping stuff) is RFC 7030 only in the header. >>>> >>>> I guess we can check what we want to do to DTLS as well, as RFC 6347 is >>>> listed as Updates:-ed but that's the DTLS 1.2 spec. (6347 itself >>>> confusingly claims in the body text to "update DTLS 1.0 to work with TLS >>>> 1.2" but has an "Obsoletes: 4347" header.) I don't see what specifically >>>> we update in 6347. >>>> >>> >>> I think the text in question is the last paragraph of RFC 6347's >>> Introduction: >>> >>> "Implementations that speak both DTLS 1.2 and DTLS 1.0 can >>> interoperate with those that speak only DTLS 1.0 (using DTLS 1.0 of >>> course), just as TLS 1.2 implementations can interoperate with >>> previous versions of TLS (see Appendix E.1 of [TLS12] for details), >>> with the exception that there is no DTLS version of SSLv2 or SSLv3, >>> so backward compatibility issues for those protocols do not apply." >>> >>> This draft says "don't interoperate" in this situation. >>> >> >> I don't typically get too exercised about what appears in these metadata >> headers, but I don't actually think this updates 6347. The statement there >> is still true, we just tell you not to do it. >> > > Well... I think the clearest definition of "updates" is in RFC 2223: > > https://tools.ietf.org/html/rfc2223#section-12 > > "... e.g., an addendum, or separate, extra information that is to be added > to the original document." > Yes, and I don't think that this does that. -Ekr > thanks, > Rob > > --00000000000086698605972a5b0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 12, 2019 at 9:56 AM Rob S= ayre <sayrer@gmail.com> wrote= :


On Tue, Nov 12, 2019 at 7:58 AM Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@rtfm.com> wrote= :


On Mon, Nov 11, 2019 at 2:43 PM Rob Sayre <sayrer@gmail.com> w= rote:
On Mon, Nov 11, 2019 at 12:27 PM Kaduk, Ben <<= a href=3D"mailto:bkaduk@akamai.com" target=3D"_blank">bkaduk@akamai.com= > wrote:
The one concrete one that I remember (and can't = attribute to the HTMLized version dropping stuff) is RFC 7030 only in the h= eader.

I guess we can check what we want to do to DTLS as well, as RFC 6347 is lis= ted as Updates:-ed but that's the DTLS 1.2 spec.=C2=A0 (6347 itself con= fusingly claims in the body text to "update DTLS 1.0 to work with TLS = 1.2" but has an "Obsoletes: 4347" header.)=C2=A0 I don't= see what specifically we update in 6347.

=C2=A0I think the text in question is the last paragraph of RFC 6347'= ;s Introduction:

"Implementations that speak = both DTLS 1.2 and DTLS 1.0 can
=C2=A0 =C2=A0interoperate with those th= at speak only DTLS 1.0 (using DTLS 1.0 of
=C2=A0 =C2=A0course), just as = TLS 1.2 implementations can interoperate with
=C2=A0 =C2=A0previous vers= ions of TLS (see Appendix E.1 of [TLS12] for details),
=C2=A0 =C2=A0with= the exception that there is no DTLS version of SSLv2 or SSLv3,
=C2=A0 = =C2=A0so backward compatibility issues for those protocols do not apply.&qu= ot;

Th= is draft says "don't interoperate" in this situation.

I don't typically get too exercise= d about what appears in these metadata headers, but I don't actually th= ink this updates 6347. The statement there is still true, we just tell you = not to do it.

Well... I t= hink the clearest definition of "updates" is in RFC 2223:

https://tools.ietf.org/html/rfc2223#section-12

"... e.g., an addendum, or separate, extra inform= ation that is to be added to the original document."
=

Yes, and I don't think that this does = that.

-Ekr


thanks,
Rob

--00000000000086698605972a5b0c-- From nobody Tue Nov 12 10:46:51 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF6712080F; Tue, 12 Nov 2019 10:46:50 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 ZGzvZLFq9y13; Tue, 12 Nov 2019 10:46:47 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 7C27C120AE0; Tue, 12 Nov 2019 10:46:47 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id i13so18563420ioj.5; Tue, 12 Nov 2019 10:46:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v9D1mMNvp3vYvGPAo6KQF0hX7WX0OH0tj7Np1+p1vpA=; b=TK2cKDJRE5in1HdxszMBcWHVXQMkG+J5xcUBzfZoPkY7vpV4pjGfUmf4JhdkOnZtjH 9MM8BbskblRrZWCgt2lutIgMYsTEKUC+/2jSU8U4uDUr7XB3V17LSXeJ++oLqEagU1bW vdcPOcUbdMXHWbk3AH0g+kp5h7qBP+OiLAxXaEs1Gq1a4xLDxOL+8aeO8vUiBMntp5QY yw9yvf00q2MuN73v5rPtgL3gL1sKoSx/aB/ADHqCMez0k9bg0EeS98jO2ghIy5ezCpzK GL3aB50T7c3av/0WTQ566iE+7rlY2fn5jR05nGK/DsMMkC5OR9krPvXmV5NWMUo/6ULh xoXw== 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=v9D1mMNvp3vYvGPAo6KQF0hX7WX0OH0tj7Np1+p1vpA=; b=sDyKd8tf+IW3s0PpqUTms63vQ4eUPQiaHgV6LKHSenvKHn/bHKDdiX+Bavd0D0h5sQ S970zxGSBM2oPIEPQh2d1R8gJyBL4++vwS65rTy3pxv9x78oqEAwL8hIH3KL7cHXRkUP I77DYIigscm0LgCc3oySU+nYuJDWH74ExkywHWPDbptasqlghGqGr33NxRGDTwVO+0Xb OC0ZfZJa8zW8yDENfZhRRBJ1zJGnFzyt0Sx7cpuxW96tkweYKoNbmsmH8bq+FtUgm9rD cAoEDDqgvB7niQpfnxzAk7A4kROAawgLpPtjhbvqW+6OFPzOHCLBM7Jgf2l+6CP0In6n T1GQ== X-Gm-Message-State: APjAAAWGSQqbUYJE3z6BUbCEpM1kJWGJZ+EcF9kb9QD6DIf1aI5Cqqy0 FUBOLfWrG3woYpxQM2IH/ztzLkC4i2EzzUv/EWo= X-Google-Smtp-Source: APXvYqx/cfGiNJISv53g14YOfOP4FsoabkUlr2AX3CHDcWgzkMNJ4yxV8QzIt96Dwbblkig1SDpQBoKLS/7Fxcy7KDI= X-Received: by 2002:a5d:8b83:: with SMTP id p3mr387893iol.189.1573584406651; Tue, 12 Nov 2019 10:46:46 -0800 (PST) MIME-Version: 1.0 References: <20191111195325.GE32847@kduck.mit.edu> <0df737cb-4947-4926-2c6d-dd3583356a2c@cs.tcd.ie> In-Reply-To: From: Rob Sayre Date: Tue, 12 Nov 2019 10:46:35 -0800 Message-ID: To: Eric Rescorla Cc: "Kaduk, Ben" , "tls@ietf.org" , "draft-ietf-tls-oldversions-deprecate.all@ietf.org" Content-Type: multipart/alternative; boundary="000000000000952ba105972aabe9" Archived-At: Subject: Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 18:46:50 -0000 --000000000000952ba105972aabe9 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 12, 2019 at 10:24 AM Eric Rescorla wrote: > > > On Tue, Nov 12, 2019 at 9:56 AM Rob Sayre wrote: > >> >> >> On Tue, Nov 12, 2019 at 7:58 AM Eric Rescorla wrote: >> >>> >>> >>> On Mon, Nov 11, 2019 at 2:43 PM Rob Sayre wrote: >>> >>>> On Mon, Nov 11, 2019 at 12:27 PM Kaduk, Ben wrote: >>>> >>>>> The one concrete one that I remember (and can't attribute to the >>>>> HTMLized version dropping stuff) is RFC 7030 only in the header. >>>>> >>>>> I guess we can check what we want to do to DTLS as well, as RFC 6347 >>>>> is listed as Updates:-ed but that's the DTLS 1.2 spec. (6347 itself >>>>> confusingly claims in the body text to "update DTLS 1.0 to work with TLS >>>>> 1.2" but has an "Obsoletes: 4347" header.) I don't see what specifically >>>>> we update in 6347. >>>>> >>>> >>>> I think the text in question is the last paragraph of RFC 6347's >>>> Introduction: >>>> >>>> "Implementations that speak both DTLS 1.2 and DTLS 1.0 can >>>> interoperate with those that speak only DTLS 1.0 (using DTLS 1.0 of >>>> course), just as TLS 1.2 implementations can interoperate with >>>> previous versions of TLS (see Appendix E.1 of [TLS12] for details), >>>> with the exception that there is no DTLS version of SSLv2 or SSLv3, >>>> so backward compatibility issues for those protocols do not apply." >>>> >>>> This draft says "don't interoperate" in this situation. >>>> >>> >>> I don't typically get too exercised about what appears in these metadata >>> headers, but I don't actually think this updates 6347. The statement there >>> is still true, we just tell you not to do it. >>> >> >> Well... I think the clearest definition of "updates" is in RFC 2223: >> >> https://tools.ietf.org/html/rfc2223#section-12 >> >> "... e.g., an addendum, or separate, extra information that is to be >> added to the original document." >> > > Yes, and I don't think that this does that. > OK. I agree with what you wrote: "The statement there is still true, we just tell you not to do it." That seems like new information a reader of RFC 6347 should be made aware of. thanks, Rob --000000000000952ba105972aabe9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Tue, Nov 12, 2019 at 10:24 AM Eric Rescorla <ekr@rtfm.com> wrote:


On Tue, Nov 12, 2019 at 9:56 AM Rob Sayre <sayrer@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">


On Tue, Nov 12, 2019 at 7:58 AM Eric Rescorla <ekr@rtfm.com> wrote:
=


On Mon, Nov 11, 2019 at 2:43 PM Rob Sayre <sayrer@gmail.com> wrote:
On Mon, Nov 11, 2019 at 12:27 PM Kaduk, Ben <bkaduk@akamai.com> wrote:
The one concrete one that I remember (and can't attribute to= the HTMLized version dropping stuff) is RFC 7030 only in the header.

I guess we can check what we want to do to DTLS as well, as RFC 6347 is lis= ted as Updates:-ed but that's the DTLS 1.2 spec.=C2=A0 (6347 itself con= fusingly claims in the body text to "update DTLS 1.0 to work with TLS = 1.2" but has an "Obsoletes: 4347" header.)=C2=A0 I don't= see what specifically we update in 6347.

=C2=A0I think the text in question is the last paragraph of RFC 6347'= ;s Introduction:

"Implementations that speak = both DTLS 1.2 and DTLS 1.0 can
=C2=A0 =C2=A0interoperate with those th= at speak only DTLS 1.0 (using DTLS 1.0 of
=C2=A0 =C2=A0course), just as = TLS 1.2 implementations can interoperate with
=C2=A0 =C2=A0previous vers= ions of TLS (see Appendix E.1 of [TLS12] for details),
=C2=A0 =C2=A0with= the exception that there is no DTLS version of SSLv2 or SSLv3,
=C2=A0 = =C2=A0so backward compatibility issues for those protocols do not apply.&qu= ot;

Th= is draft says "don't interoperate" in this situation.

I don't typically get too exercise= d about what appears in these metadata headers, but I don't actually th= ink this updates 6347. The statement there is still true, we just tell you = not to do it.

Well... I t= hink the clearest definition of "updates" is in RFC 2223:

https://tools.ietf.org/html/rfc2223#section-12

"... e.g., an addendum, or separate, extra inform= ation that is to be added to the original document."
=

Yes, and I don't think that this does = that.

OK. I agree with wh= at you wrote: "The statement there is still true, we just tell you not= to do it."

That seems like new information a= reader of RFC 6347 should be made aware of.

thank= s,
Rob

--000000000000952ba105972aabe9-- From nobody Tue Nov 12 12:43:02 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B65120839 for ; Tue, 12 Nov 2019 12:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 TB8ZoCz1EuIG for ; Tue, 12 Nov 2019 12:42:59 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B578E1200DB for ; Tue, 12 Nov 2019 12:42:59 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 263FDF40713; Tue, 12 Nov 2019 12:42:55 -0800 (PST) To: ekr@rtfm.com, nagendra@cs.stanford.edu, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: mt@lowentropy.net, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20191112204255.263FDF40713@rfc-editor.org> Date: Tue, 12 Nov 2019 12:42:55 -0800 (PST) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC6347 (5903) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2019 20:43:01 -0000 The following errata report has been submitted for RFC6347, "Datagram Transport Layer Security Version 1.2". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5903 -------------------------------------- Type: Editorial Reported by: Martin Thomson Section: 1 Original Text ------------- with the exception that there is no DTLS version of SSLv2 or SSLv3, Corrected Text -------------- with the exception that there is no DTLS version of SSLv2, SSLv3, or TLS 1.0, Notes ----- DTLS has versions that match TLS 1.1, 1.2, and (soon) 1.3. DTLS 1.0 corresponds to TLS 1.1. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6347 (draft-ietf-tls-rfc4347-bis-06) -------------------------------------- Title : Datagram Transport Layer Security Version 1.2 Publication Date : January 2012 Author(s) : E. Rescorla, N. Modadugu Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Nov 12 18:50:38 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8FD120106; Tue, 12 Nov 2019 18:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 Xcv6DkHfaTpN; Tue, 12 Nov 2019 18:50:32 -0800 (PST) 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 E46EF120874; Tue, 12 Nov 2019 18:50:31 -0800 (PST) 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 xAD2oRcs001893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Nov 2019 21:50:29 -0500 Date: Tue, 12 Nov 2019 18:50:26 -0800 From: Benjamin Kaduk To: Russ Housley Cc: draft-ietf-tls-tls13-cert-with-extern-psk.all@ietf.org, IETF TLS Message-ID: <20191113025026.GP32847@kduck.mit.edu> References: <20191110004335.GV47216@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [TLS] AD review of draft-ietf-tls-tls13-cert-with-extern-psk-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 02:50:37 -0000 On Sun, Nov 10, 2019 at 03:41:44PM -0500, Russ Housley wrote: > Ben: > > I have made the edits indicated in my response below. I cannot pot it until the I-D repository reopens. I'm happy to approve a manual posting sooner if you want, though I do not think it would have a huge impact on time-to-end-of-IETF-LC. > > Thanks for putting this together, and sorry again for the delays in > > processing. > > > > I note inline many places where we essentially repeat preexisting > > requirements from RFC 8446 but use normative keywords as if they were > > new requirements being imposed by this document. (There are other places > > where we repeat or duplicate some narrative descriptions from RFC 8446 as > > well, though I did not note specific locations.) I think our general > > preference is to try to only use the normative keywords once, and have > > either direct quotations or descriptive language for other places where we > > refer to those requirements, though of course there are always exceptions. > > > > Similarly, we may have more duplication of content/requirements between > > Sections 4 and 5 than is needed. > > > > Some other section-by-section notes are included as well, in particular for > > the IANA Considerations that will need some tweaking. > > > > Section 3 > > > > The invention of a large-scale quantum computer would pose a serious > > challenge for the cryptographic algorithms that are widely deployed > > today, including the digital signature algorithms that are used to > > authenticate the server in the TLS 1.3 handshake protocol. It is an > > open question whether or not it is feasible to build a large-scale > > quantum computer, and if so, when that might happen. However, if > > such a quantum computer is invented, many of the cryptographic > > algorithms and the security protocols that use them would become > > vulnerable. > > > > Apparently we don't have an RFC style entry for "the kind of quantum > > computer that we have to worry about for cryptographic purposes"; I see > > reference to "sufficiently large quantum computer" (RFC 8080), > > "large-scale quantum computer" (RFC 8576), "cryptographically relevant > > quantum computer" (RFC 8603), and there's probably more that didn't jump > > out at me. (This question did just come up in response to my review of > > draft-ietf-ipsecme-qr-ikev2, where Scott Fluhrer suggested > > "cryptographically significant quantum computer", that I was going to > > lean towards until I did this search just now.) It would be great to > > normalize our terminology use here, though I don't know that there's a > > clear winner yet. > > (I also wonder if "invention" is quite the right word to describe the > > process in question, but that's probably a side note.) > > One of your references is using "large-scale quantum computer" as I do in this document. I can see that alignment on a single term would be desirable, but I do not think that a common term has emerged in the greater research community. > > I will gladly change "invention" to "development" in the first sentence. Understood, and thanks. > > The TLS 1.3 handshake protocol employs key agreement algorithms that > > could be broken by the invention of a large-scale quantum computer > > [I-D.hoffman-c2pq]. These algorithms include Diffie-Hellman (DH) > > [DH1977] and Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363]. As a > > > > It might be worth using "also employs" to emphasize that the signature > > algorithms of the first paragraph and the key-agreement algorithms of > > the second paragraph are distinct classes of algorithms. > > Also, do we want to also reference RFC 7748 to get an "I*TF-internal" > > reference for ECDH technologies? > > I am using the same reference for ECDH as RFC 8446. This was intensional. (I grabbed the RFC 7748 reference from RFC 8446, too.) > I suggest the following to bring in the signature algorithm concern: > > The TLS 1.3 handshake protocol employs key agreement algorithms and > digital signature algorithms that could be broken by the development > of a large-scale quantum computer [I-D.hoffman-c2pq]. The key > agreement algorithms include Diffie-Hellman (DH) [DH1977] and > Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363]; the digital > signature algorithms inclue RSA [RFC8017] and Elliptic Curve Digital > Signature Algorithm (ECDSA) [FIPS186]. As a result, an adversary > that stores a TLS 1.3 handshake protocol exchange today could decrypt > the associated encrypted communications in the future when a large- > scale quantum computer becomes available. Okay, that should work. > > Section 4 > > > > The client includes the "tls_cert_with_extern_psk" extension in the > > ClientHello message. The "tls_cert_with_extern_psk" extension MUST > > be accompanied by the "key_share", "psk_key_exchange_modes", and > > > > Do we need to mandate anything about the contents of > > "psk_key_exchange_modes" in this case? (I see we do say something later > > on in Section 5, so maybe not here. But see also the note about > > duplication of normative requirements between Sections 4 and 5.) > > I think the discussion in Section 5 covers this extension well. RFC 8446 defines two values (psk_ke and psk_dhe_ke), and both are discussed in Section 5. > > > "pre_shared_key" extensions. The "pre_shared_key" extension MUST be > > the last extension in the ClientHello message, and it provides a list > > of external PSK identifiers that the client is willing to use with > > this server. [...] > > > > I think that the last paragraph of > > https://tools.ietf.org/html/rfc8446#section-4.2.11 is quite clear that > > "pre_shared_key" must be the last extension, and we don't need to have > > new normative language to require it. > > Okay. I'd like to preserve the reminder that the "pre_shared_key" extension needs to come at the end. I suggest: > > The client includes the "tls_cert_with_extern_psk" extension in the > ClientHello message. The "tls_cert_with_extern_psk" extension MUST > be accompanied by the "key_share", "psk_key_exchange_modes", and > "pre_shared_key" extensions. The client MAY also find it useful to > include the "supported_groups" extension. Since the > "tls_cert_with_extern_psk" extension is intended to be used only with > initial handshakes, it MUST NOT be sent alongside the "early_data" > extension. These extensions are all described in Section 4.2 of > [RFC8446], which also requires the "pre_shared_key" extension to be > the last extension in the ClientHello message. Thanks. > > The successful negotiation of the "tls_cert_with_extern_psk" > > extension requires the TLS 1.3 key schedule processing to include > > both the selected external PSK and the (EC)DHE shared secret value. > > > > grammar pedant alert: I believe that this construction is parsed such > > that inclusion of (both external PSK and ECDHE shared secret) in the key > > schedule is a prerequisite for successful negotiation, whereas the > > intent is that successful negotiation implies the key schedule change. > > One plausible "fix" (if any is indeed desired) would be "After > > successful negotiation [...], it is required to adopt the TLS 1.3 key > > schedule [...]", but there are probably better ones. > > I think this is an improvement: > > When the "tls_cert_with_extern_psk" extension is successfully > negotiated, the TLS 1.3 key schedule processing includes both the > selected external PSK and the (EC)DHE shared secret value. As a > result, the Early Secret, Handshake Secret, and Master Secret values > all depend upon the value of the selected external PSK. Thanks, I agree that it is an improvement. > > As a result, the Early Secret, Handshake Secret, and Master Secret > > values all depend upon the value of the selected external PSK. > > > > (side note) Not that anyone here is likely to be confused, but the Early > > Secret does not incorporate the (EC)DHE shared secret. I don't really > > see any reason to include a clarification about this, since the current > > text isn't really implying that it does, but will mention it in case > > anyone feels differently. > > To make sure this is clear, I suggest and additional sentence to the above: > > Of course, the Early Secret does not depend upon > the (EC)DHE shared secret. Thanks! > > Each external PSK is associated with a single hash algorithm, which > > is required by Section 4.2.11 of [RFC8446]. The hash algorithm MUST > > be set when the PSK is established, with a default of SHA-256 if no > > hash algorithm is specified during establishment. > > > > This is likely to get flagged by the IESG -- it's a construction of the > > form "MUST do X, but if you don't do X, assume Y" that inherently > > assumes the MUST will not always be adhered to. > > I think this says the same thing with a cleaner construction: > > Each external PSK is associated with a single hash algorithm, which > is required by Section 4.2.11 of [RFC8446]. The hash algorithm MUST > be set when the PSK is established, with a default of SHA-256. I'm happy to go forward with it, but cannot guarantee it will pass IESG review. > > Section 5 > > > > Is there a useful way to group this content into sub-sections? > > Yes. I have introduces subsections to talk about the companion extensions, authentication, and keying material. Thanks. I didn't get a chance to think very hard about what groupings might make sense. > > appeared in the preceding ClientHello message. If an implementation > > recognizes the "tls_cert_with_extern_psk" extension and receives it > > in any other message, then the implementation MUST abort the > > handshake with an "illegal_parameter" alert. > > > > nit: "abort the handshake" is not quite right, since there are > > Extensions blocks involved in post-handshake messages (NST, > > CertificateRequest, etc.) which do not have a handshake to abort. I > > think "terminate the connection with a alert" is the preferred > > construction for this situation. > > Since the "tls_cert_with_extern_psk" extension MUST NOT appear in any message other than the ClientHello message and the ServerHello message, I think this is the correct construction. For example, Section 4.1.1 of RFC 8446 says: > > ... If there is no overlap between the received > "supported_groups" and the groups supported by the server, then the > server MUST abort the handshake with a "handshake_failure" or an > "insufficient_security" alert. I think that's still talking about the server responding to a ClientHello. To be clear, I only called it out because the current text begins with "any other message", which is (to me, at least) calling out NewSessionTicket, CertificateRequest, and friends. > > ClientHello message. If the server responds with a HelloRetryRequest > > message, then the client sends another ClientHello message as > > described in Section 4.1.2 of [RFC8446], and it MUST include the same > > "tls_cert_with_extern_psk" extension as the original ClientHello > > message or abort the handshake. > > > > (This is another MUST that duplicates an existing requirement from RFC > > 8446.) > > Okay. Reworded to remove the MUST: > > ... If the server responds with a HelloRetryRequest > message, then the client sends another ClientHello message as > described in Section 4.1.2 of [RFC8446], including the same > "tls_cert_with_extern_psk" extension as the original ClientHello > message or abort the handshake. Thanks > > Many server extensions are carried in the EncryptedExtensions > > message; however, the "tls_cert_with_extern_psk" extension is carried > > in the ServerHello message. It is only present in the ServerHello > > > > I suggest adding a brief phrase noting that it's unfeasible to put this > > extension in the EncryptedExtensions since it affects what key is used > > to encrypt that message. > > I suggest: > > Many server extensions are carried in the EncryptedExtensions > message; however, the "tls_cert_with_extern_psk" extension is carried > in the ServerHello message. Successful negotiation of the > "tls_cert_with_extern_psk" extension affects the key used for > encryption, so it cannot be carried in the EncryptedExtensions > message. Therefore, the "tls_cert_with_extern_psk" extension is only > present in the ServerHello message if the server recognizes the > "tls_cert_with_extern_psk" extension and the server possesses one of > the external PSKs offered by the client in the "pre_shared_key" > extension in the ClientHello message. Thanks. I might (but might not) s/Therefore/Accordingly/, since we don't do much to present an argument about when/whether to have the server send the extension, just which message it goes in when it is sent. > > To use an external PSK with certificates, clients MUST provide the > > "tls_cert_with_extern_psk" extension, and it MUST be accompanied by > > the "key_share", "psk_key_exchange_modes", and "pre_shared_key" > > extensions in the ClientHello. If clients offer a > > "tls_cert_with_extern_psk" extension without all of these other > > extensions, servers MUST abort the handshake. The client MAY also > > > > This seems redundant with the requirements from Section 4; is the > > repetition necessary? > > I moved the one sentence that was not a repeat to Section 4 (as shown above). With that done, the whole paragraph can be deleted. Cool, thanks. > > find it useful to include the "supported_groups" extension. Note > > that Section 4.2 of [RFC8446] allows extensions to appear in any > > order, with the exception of the "pre_shared_key" extension, which > > MUST be the last extension in the ClientHello. Also, there MUST NOT > > be more than one instance of each extension in the ClientHello > > message. > > > > I'd prefer to either use direct quotations from RFC 8446 or descriptive > > versions of the requirements (without normative keywords). > > Okay. This one was deleted. > > > might supply via a subsequent NewSessionTicket. As a result, clients > > MUST include the psk_dhe_ke mode, and clients MAY also include the > > psk_ke mode to support a subsequent NewSessionTicket. Servers MUST > > select the psk_dhe_ke mode for the initial handshake. Servers MUST > > select a key exchange mode that is listed by the client for > > subsequent handshakes that include the resumption PSK from the > > initial handshake. > > > > I suppose it's probably implicit that "MUST select the psk_dhe_ke mode" > > is contingent on negotiating "tls_cert_with_extern_psk", but maybe > > there's not any harm in making it explicit as well. > > I suggest: > > The "psk_key_exchange_modes" extension is defined in Section 4.2.9 of > [RFC8446]. The "psk_key_exchange_modes" extension restricts both the > use of PSKs offered in this ClientHello and those which the server > might supply via a subsequent NewSessionTicket. As a result, when > the "psk_key_exchange_modes" extension is included in the ClientHello > message, clients MUST include psk_dhe_ke mode. In addition, clients nit: "the psk_dhe_ke mode" > MAY also include psk_ke mode to support a subsequent nit: missing "the" again > NewSessionTicket. When the "psk_key_exchange_modes" extension is > included in the ServerHello message, servers MUST select the > psk_dhe_ke mode for the initial handshake. Servers MUST select a key > exchange mode that is listed by the client for subsequent handshakes > that include the resumption PSK from the initial handshake. but I appreciate the addition; thanks! > > The "pre_shared_key" extension is defined in Section 4.2.11 of > > [RFC8446]. The syntax is repeated below for convenience. All of the > > listed PSKs MUST be external PSKs. > > > > Should we specify that the server must abort the handshake if it detects > > a resumption PSK present in a ClientHello that contains > > "tls_cert_with_extern_psk"? (What alert would be best in that case?) > > I suggest: > > The "pre_shared_key" extension is defined in Section 4.2.11 of > [RFC8446]. The syntax is repeated below for convenience. All of the > listed PSKs MUST be external PSKs. If a resumption PSK is listed > along with the "tls_cert_with_extern_psk" extension, the server MUST > abort the handshake with an "illegal_parameter" alert. Works for me. > > The obfuscated_ticket_age is not used for external PSKs; clients > > SHOULD set this value to 0, and servers MUST ignore the value. > > > > (These are the same requirements from RFC 8446, though it's probably > > reasonable to repeat them here to confirm that they apply.) > > To be clear that these are not new requirements: > > The obfuscated_ticket_age is not used for external PSKs. As stated > in Section 4.2.11 of [RFC8446], clients SHOULD set this value to 0, > and servers MUST ignore the value. Thanks. > > The selected_identity contains the external PSK identity that the > > server selected from the list offered by the client. If none of the > > > > nit: it's the index of the identity, though it's unclear to what length > > we need to cover that in this document, since RFC 8446 is pretty clear > > and available to the reader in case of confusion. > > I think that some context is useful, but I suggest getting rid of some text: > > The selected_identity contains the index of the external PSK identity > that the server selected from the list offered by the client. As > described in Section 4.2.11.2 of [RFC8446], the server MUST validate > the binder value that corresponds to the selected external PSK, and > if the binder does not validate, the server MUST abort the handshake > with an "illegal_parameter" alert. Looks good. > > > > The server > > MUST validate the binder value that corresponds to the selected > > external PSK as described in Section 4.2.11.2 of [RFC8446]. If the > > binder does not validate, the server MUST abort the handshake with an > > "illegal_parameter" alert. Servers SHOULD NOT attempt to validate > > multiple binders; rather they SHOULD select one of the offered > > external PSKs and validate only the binder that corresponds to that > > external PSK. > > > > (This chunk also has pretty high overlap with existing RFC 8446 > > requirements.) > > Agreed, and I proposed to reduce the repeated text above. > > > TLS 1.3 does not permit the server to send a CertificateRequest > > message when a PSK is being used. This restriction is removed when > > the "tls_cert_with_extern_psk" extension is negotiated, allowing > > certificate-based authentication for both the client and the server. > > > > We might get some questions about whether this weakening of an RFC 8446 > > requirement requires an "Updates:" relationship (problematic given this > > document is targetting Experimental status), but I don't think it's > > necessary. (That text is relevant when the server is authenticating > > solely with a PSK, which is not the case here.) > > I would argue that it is not a "weakening" for exactly this reason. The TLS WG wanted to move forward with an Experimental RFC, so I assume that it cannot update RFC 8446. Agreed. > > Section 7.1 of [RFC8446] specifies the TLS 1.3 Key Schedule. The > > successful negotiation of the "tls_cert_with_extern_psk" extension > > requires the key schedule processing to include both the external PSK > > and the (EC)DHE shared secret value. > > > > Do we want to say "into the PSK and (EC)DHE inputs, respectively"? It > > seems almost banal to do so, so maybe not... > > There are only two variable inputs, and then text says to "include both", so I am not sure how "respectively" adds clarity. > > > If the client and the server have different values associated with > > the selected external PSK identifier, then the client and the server > > will compute different values for every entry in the key schedule, > > which will lead to the termination of the connection with a > > "decrypt_error" alert. > > > > (side note) this is a case where "abort the handshake" would be > > appropriate, though the verb tense into which we have to fit probably > > makes the current wording better :) > > I suggest: > > If the client and the server have different values associated with > the selected external PSK identifier, then the client and the server > will compute different values for every entry in the key schedule, > which will lead to the client aborting the handshake with a > "decrypt_error" alert. Excellent, thanks. > > Section 6 > > > > We also should probably say that it gets the "Recommended" value "N" > > (not that we have any choice about it) and [this document] is the > > reference. > > I suggest: > > IANA is requested to update the TLS ExtensionType Registry to include > "tls_cert_with_extern_psk" with a value of TBD and the list of > messages "CH, SH" in which the "tls_cert_with_extern_psk" extension > may appear. I think you copied the OLD text and not the NEW, but am confident that your NEW is something reasonable. > > Implementations must protect the external pre-shared key (PSK). > > Compromise of the external PSK will make the encrypted session > > content vulnerable to the future invention of a large-scale quantum > > computer. > > > > ("invention" and "large-scale quantum computer" again, if we end up > > making a pass to change either of those) > > I changed it to "development" as above. > > > Implementers should not transmit the same content on a connection > > that is protected with an external PSK and a connection that is not. > > Doing so may allow an eavesdropper to correlate the connections, > > making the content vulnerable to the future invention of a large- > > scale quantum computer. > > > > I think I'm missing a step here. While it's clear that if the same > > content is sent on two connections, and the attacker can correlate the > > connections so as to know that fact, then the PSK-less connection can be > > attacked with the quantum computer and thus reveal the contents of the > > PSK-protected connection, I'm not sure how just having the same content > > on the two connection allows the eavesdropper to correlate the > > connections. Or is this just a more generic risk (e.g., timing/size > > analysis) that's not particularly enabled by the external PSK > > (non-)usage? > > The point is more straightforward than the correlation. if the content requires protection from the future development of a large-scale quantum computer, then sending it on a connection with external PSK protection and one without external PSK protection leave the content vulnerable. If that's all you want to say, then why mention correlation at all? (I assumed the correlation was needed so as to be able to attack the nominally-PSK-protected connection.) > > If the external PSK is known to any party other than the client and > > the server, then the external PSK MUST NOT be the sole basis for > > authentication. The reasoning is explained in [K2016] (see > > Section 4.2). When this extension is used, authentication is based > > on certificates, not the external PSK. > > > > Are we talking about [K2016] as https://eprint.iacr.org/2016/711.pdf ? > > I failed to find anything in Section 4.2 that considers the case when > > the PSK is shared between more parties than just C and S. > > Yes. Footnote 6 says it, but you need a lot of context from earlier in the paper to get the full consequences of that short statement. > > If you are aware of another reference that explains the situation, I'll be glad to take a look. Ah, I failed to read (or even notice?) the footnote. I don't know of a particular reference, though the result does seem rather intuitive. > > 1.2 PRF. Thus, the safest approach is to use a PSK with either TLS > > 1.2 or TLS 1.3. However, any PSK that might be used with both TLS > > 1.2 and TLS 1.3 must be used with only one hash function, which is > > the one that is bound for use in TLS 1.3. This restriction is less > > > > nit(?): I suggest rewording "use a PSK with either TLS 1.2 or TLS 1.3", > > as the current wording can be confusing as to the exclusive nature of > > the "or", perhaps to "the safest approach is to use any given PSK with > > at most one of TLS 1.2 and TLS 1.3". > > I suggest: > > ... Thus, the safest approach is to use a PSK exclusively with > TLS 1.2 or exclusively with TLS 1.3. ... Works for me. > > What is the origin of the "only one hash function" requirement? > > Section 4.2.11 of RFC 8446 says: > > Each PSK is associated with a single Hash algorithm. For PSKs > established via the ticket mechanism (Section 4.6.1), this is the KDF > Hash algorithm on the connection where the ticket was established. > For externally established PSKs, the Hash algorithm MUST be set when > the PSK is established or default to SHA-256 if no such algorithm is > defined. The server MUST ensure that it selects a compatible PSK > (if any) and cipher suite. > > {{Note the wording that you expect the IESG to complain about.}} ((It's easy to miss things when they're buried in 100-page documents. Tiny ones are easier to nitpick.)) > > (Appendix E.7 of RFC 8446 only has this limitation apply to the TLS 1.3 > > usage, not the TLS 1.2 usage.) > > Observe that draft-ietf-tls-external-psk-importer is a way to handle this situation. Given a PSK, one can derive another PSK for use with TLS 1.2 and a different one for use with TLS 1.3. I agree that there are lots of reasonable-ish ways to handle the situation, including draft-ietf-tls-external-psk-importer. I think what I'm really trying to get at is whether this (version-agnonstic) "must be used with only one hash function" requirement is coming from some other preexisting document (in which case a reference thereto seems in order), or whether (the TLS 1.2 part of) it is new to this document (in which case we might say something about why). > > than optimal when users want to provision a single PSK. While the > > constructions used in TLS 1.2 and TLS 1.3 are both based on HMAC > > [RFC2104], the constructions are different, and there is no known way > > in which reuse of the same PSK in TLS 1.2 and TLS 1.3 that would > > produce related outputs. > > > > (This also has pretty high overlap with Appendix E.7 of RFC 8446; do we > > need to inline it all as opposed to incorporating by reference?) > > I agree, and now that draft-ietf-tls-external-psk-importer is available, I can suggest a way to handle the situation instead of just warning about it: > > TLS 1.3 [RFC8446] takes a conservative approach to PSKs; they are > bound to a specific hash function and KDF. By contrast, TLS 1.2 > [RFC5246] allows PSKs to be used with any hash function and the TLS > 1.2 PRF. Thus, the safest approach is to use a PSK exclusively with > TLS 1.2 or exclusively with TLS 1.3. Given one PSK, one can derive a > PSK for exclusive use with TLS 1.2 and derive another PSK for > exclusive use with TLS 1.3 using the mechanism specified in > [I-D.ietf-tls-external-psk-importer]. Of course, there's always the third path of removing the need to answer the question at all, which in this case sounds like a fine thing to do :) Thanks, Ben From nobody Wed Nov 13 03:30:24 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F5D120025; Wed, 13 Nov 2019 03:30:23 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Lg6pSWV7VSt1; Wed, 13 Nov 2019 03:30:20 -0800 (PST) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 9F78E12001A; Wed, 13 Nov 2019 03:30:20 -0800 (PST) Received: by mail-ot1-x32e.google.com with SMTP id u13so1320065ote.0; Wed, 13 Nov 2019 03:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CRdD5utyDc3oyKjHScwz9aBxCpxcl79EkTNxD8NPgGE=; b=pfMCJ0fNj3yw+BG6VJyMlj/DUp/xwpRWjmCJRAKmxtujiKYf6wLeIuLqJqBvl3JJ0A SKlcS+lmtiqUMM7SjTjhdjoM1HEEDPuIe7gVPXKpwNRda8Ih13EE5vRwEzklVjt1UZq/ 42AoCFMA3KBzFmwI/2otJPSgOLwIvoyU6r/6gqi5GfbjDb9ErM/2V05CtF56JWxMV68l 7PVyMAzPnKaPUNA+L3Oq+vujI3M/yyZZ+pQEiBpJWrlzg08csVcDICILIsZ+H36rw9qx b8D79ZNjPcr3qXsT9XHYxP6juYuHj/CUR0cbhhWCeyIB5NHgfM8DZQkzU2xOro2Pdk0H 8AOg== 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=CRdD5utyDc3oyKjHScwz9aBxCpxcl79EkTNxD8NPgGE=; b=QXjg0Q3LBAXb9H+EIsma/tlp4tY4VNRTMAE+ZjNZYXfTMq/tpISOtIcNAqohss7/XR ua1PBeKFwyd+Ve2N3w34WwkfUUkh8RWITng7Ezg4uMF1ZuFGyC6/r5hyMBTOtkoekX+7 r8RaBIIi1IsfQX7bEM3zjE0Fg8p8Nmqm+6nF1FlF+5L4nOqL1kdmTW0PqNFpuWz5sYYi F6m8LH9Bh4ALt9uyz75QUASN16/cnbd7DjAH8J/6EDsa1e+odByYu4B4n/dLoJzoCEP1 Nduk/ivQvRumSjyk/g09F8s25TY3ZQtklRLuPnTyxpKVaG98m+aEzmiDMmXmy3qT6CC+ lxsQ== X-Gm-Message-State: APjAAAVGdl158i4MUdvkiBxPnB+6pBqSCTMioN9Orr3JZepEgE6KCdD2 qXoKUGg8z9HCzWQvuprsfL47EXCIuBfCvM1mbxK6YYtP X-Google-Smtp-Source: APXvYqz+Z7ixIi+qVcfri4UL6xhadrKqjS24dvfYVmtoR/2jfMY/kT1ZWXMADDmwCmGyiy31KKW77cGJwXNhKsYC/rs= X-Received: by 2002:a9d:7219:: with SMTP id u25mr2349110otj.342.1573644619971; Wed, 13 Nov 2019 03:30:19 -0800 (PST) MIME-Version: 1.0 References: <20191111195325.GE32847@kduck.mit.edu> In-Reply-To: <20191111195325.GE32847@kduck.mit.edu> From: Kathleen Moriarty Date: Wed, 13 Nov 2019 06:29:44 -0500 Message-ID: To: Benjamin Kaduk Cc: draft-ietf-tls-oldversions-deprecate.all@ietf.org, "" Content-Type: multipart/alternative; boundary="000000000000938306059738b016" Archived-At: Subject: Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2019 11:30:23 -0000 --000000000000938306059738b016 Content-Type: text/plain; charset="UTF-8" Hi Ben, Just replying to the parts of the tread that were not responded to already as Stephen will likely be looking at the headers/updates per his message. Thanks for your careful review. On Mon, Nov 11, 2019 at 2:54 PM Benjamin Kaduk wrote: > Hi all, > > This is a "preliminary" review only because there's some strangeness > relating to the Updates: (and Obsoletes:) headers, and any changes there > would make me need to go and recheck the relationship of this document to > the ones listed. So, I haven't done any of that yet, in an attempt to only > have to do it once. > > Specifically, there's skew between the list of documents updated in the top > header and the list in Section 1.1. Evern more annoyingly, the (tools) > HTML version seems to be missing some numbers from the document header, > that are present in the TXT version. (Henrik is going to take a look, per > > https://mailarchive.ietf.org/arch/msg/tools-discuss/Maeh0f_WfOy5sfnGQpwGPs_sYcU > .) > Thanks. > > Additionally, Section 1.1 lists some RFCs that "have been obsoleted", but > there is no "Obsoletes:" header at the top of the document. > > I think nits is right about references (square-bracketed "[RFC6347]") in > the Abstract; we should change those to normal textual (parenthesed > "(RFC 6347)") before IETF LC. > > Some other notes from a quick pass over the main text (though I'll probably > read it again once the above are addressed) follow. > > Section 1 > > It feels a little backwards for a "primary technical reason" to > deprecate a protocol version being that "at least one widely-used > library has plans to drop [it]". > I see what you are saying. The major library dropping it has to do with the number of versions available and supporting them all is cumbersome and could lead to configuration errors on the part of the user. Would you just like "primary" removed or would you prefer more of a change to the text? > > I do appreciate that we give discussion about what we intend > "deprecation" to mean and for whom -- thank you for that! > > Section 2 > > TLS 1.3, specified in TLSv1.3 [RFC8446], represents a significant > change to TLS that aims to address threats that have arisen over > the years. Among the changes are a new handshake protocol, a new > key derivation process that uses the HMAC-based Extract-and-Expand > Key Derivation Function (HKDF), and the removal of cipher suites > that use static RSA or DH key exchanges, the CBC mode of > operation, or SHA-1. The list of extensions that can be used with > TLS 1.3 has been reduced considerably. > > While it's true that the initial list of extensions usable with TLS 1.3 > is smaller than the list of extensions usable at TLS 1.2 taken at the > same time, it's also true that the requirements for allocating a new > extension codepoint have been reduced dramatically. So I think I'd say > that this reflects not a desire to reduce the attack surface (as > "measured" by number of extensions) but rather a paradigm shift in how > the protocol works, which leaves some existing functionality > incompatible with the new model. I don't really get a clear sense of > what this current last sentence is trying to say (i.e., whether it's one > of those two descriptions I offered above). > Would you prefer "a significant change", be "a paradigm shift"? If not, could you propose text? > Section 3 > > Similarly, the authentication of the handshake depends on signatures > made using SHA-1 hash or a not stronger concatenation of MD-5 and > SHA-1 hashes, allowing the attacker to impersonate a server when it > is able to break the severely weakened SHA-1 hash. > > My recollection of the WG discussions (which I will go review) is that > we don't really have consensus on the "not stronger" portion of this. > Is that a key component of the document here? (N.B. this is *not* an > invitation to rehash that discussion again! The chairs or I can provide > a summary of points not resolved by previous discussion and points > believed to be adequately agreed upon, which would be a trigger for any > additional discussion that might be needed.) > Since you are already looking at the consensus of this with the chairs, we can wait for your guidance. Best regards, Kathleen > > Thanks for putting this document together (I know that getting all the long > list of references/updates/etc. right is really tedious and frustrating), > and sorry to have been sitting on it for so long. > > -Ben > -- Best regards, Kathleen --000000000000938306059738b016 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

Just replying = to the parts of the tread that were not responded to already as Stephen wil= l likely be looking at the headers/updates per his message.=C2=A0 Thanks fo= r your careful review.

On Mon, Nov 11, 2019 at 2:54 PM Benjamin Kadu= k <kaduk@mit.edu> wrote:
Hi all,

This is a "preliminary" review only because there's some stra= ngeness
relating to the Updates: (and Obsoletes:) headers, and any changes there would make me need to go and recheck the relationship of this document to the ones listed.=C2=A0 So, I haven't done any of that yet, in an attemp= t to only
have to do it once.

Specifically, there's skew between the list of documents updated in the= top
header and the list in Section 1.1.=C2=A0 Evern more annoyingly, the (tools= )
HTML version seems to be missing some numbers from the document header,
that are present in the TXT version.=C2=A0 (Henrik is going to take a look,= per
https://mailarchive.i= etf.org/arch/msg/tools-discuss/Maeh0f_WfOy5sfnGQpwGPs_sYcU .)

Thanks.=C2=A0

Additionally, Section 1.1 lists some RFCs that "have been obsoleted&qu= ot;, but
there is no "Obsoletes:" header at the top of the document.

I think nits is right about references (square-bracketed "[RFC6347]&qu= ot;) in
the Abstract; we should change those to normal textual (parenthesed
"(RFC 6347)") before IETF LC.

Some other notes from a quick pass over the main text (though I'll prob= ably
read it again once the above are addressed) follow.

Section 1

It feels a little backwards for a "primary technical reason" to deprecate a protocol version being that "at least one widely-used
library has plans to drop [it]".

I= see what you are saying.=C2=A0 The major library dropping it has to do wit= h the number of versions available and supporting them all is cumbersome an= d could lead to configuration errors on the part of the user.=C2=A0 Would y= ou just like "primary" removed or would you prefer more of a chan= ge to the text?
=C2=A0

I do appreciate that we give discussion about what we intend
"deprecation" to mean and for whom -- thank you for that!

Section 2

=C2=A0 =C2=A0 =C2=A0 TLS 1.3, specified in TLSv1.3 [RFC8446], represents a = significant
=C2=A0 =C2=A0 =C2=A0 change to TLS that aims to address threats that have a= risen over
=C2=A0 =C2=A0 =C2=A0 the years.=C2=A0 Among the changes are a new handshake= protocol, a new
=C2=A0 =C2=A0 =C2=A0 key derivation process that uses the HMAC-based Extrac= t-and-Expand
=C2=A0 =C2=A0 =C2=A0 Key Derivation Function (HKDF), and the removal of cip= her suites
=C2=A0 =C2=A0 =C2=A0 that use static RSA or DH key exchanges, the CBC mode = of
=C2=A0 =C2=A0 =C2=A0 operation, or SHA-1.=C2=A0 The list of extensions that= can be used with
=C2=A0 =C2=A0 =C2=A0 TLS 1.3 has been reduced considerably.

While it's true that the initial list of extensions usable with TLS 1.3=
is smaller than the list of extensions usable at TLS 1.2 taken at the
same time, it's also true that the requirements for allocating a new extension codepoint have been reduced dramatically.=C2=A0 So I think I'= d say
that this reflects not a desire to reduce the attack surface (as
"measured" by number of extensions) but rather a paradigm shift i= n how
the protocol works, which leaves some existing functionality
incompatible with the new model.=C2=A0 I don't really get a clear sense= of
what this current last sentence is trying to say (i.e., whether it's on= e
of those two descriptions I offered above).

=
Would you prefer "a significant change", be "a paradigm= shift"? If not, could you propose text?


=

Section 3

=C2=A0 =C2=A0Similarly, the authentication of the handshake depends on sign= atures
=C2=A0 =C2=A0made using SHA-1 hash or a not stronger concatenation of MD-5 = and
=C2=A0 =C2=A0SHA-1 hashes, allowing the attacker to impersonate a server wh= en it
=C2=A0 =C2=A0is able to break the severely weakened SHA-1 hash.

My recollection of the WG discussions (which I will go review) is that
we don't really have consensus on the "not stronger" portion = of this.
Is that a key component of the document here?=C2=A0 (N.B. this is *not* an<= br> invitation to rehash that discussion again!=C2=A0 The chairs or I can provi= de
a summary of points not resolved by previous discussion and points
believed to be adequately agreed upon, which would be a trigger for any
additional discussion that might be needed.)

Since you are already looking at the consensus of this with the chair= s, we can wait for your guidance.

Best regards,
Kathleen=C2=A0

Thanks for putting this document together (I know that getting all the long=
list of references/updates/etc. right is really tedious and frustrating), and sorry to have been sitting on it for so long.

-Ben


--

Best regards,
Kathleen
--000000000000938306059738b016-- From nobody Thu Nov 14 07:50:41 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37C7120113 for ; Thu, 14 Nov 2019 07:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 GcP2iV6wWzWT for ; Thu, 14 Nov 2019 07:50:36 -0800 (PST) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 94FDE1200BA for ; Thu, 14 Nov 2019 07:50:36 -0800 (PST) Received: by mail-vs1-xe2f.google.com with SMTP id m6so4147390vsn.13 for ; Thu, 14 Nov 2019 07:50:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=adwUv+7W6R5gDLqdmK5diDhyPOpt9RkVJIdpNw9QjBc=; b=uDG/ZNTwiXhFU7RyPFDvLMVLUbQnhRtRMVSFTcCAxvw0lGC15RRiLkOCBvPQJtNm9O 1s4lj1X85YehgzSkwo5ar/6kPSX+ngJukIy9FzbFLtvJreSzWxHYIqqE4FvzH76IFjLi rQ0Lyrd+xkNyIfyP13s1gVM5PADAoZJNKQObEnZKEtvbwQAiBlSurUNqyoifo/FNn8+L j8WpxeXfMXA3OdAwIO1hXRrTiiIXljFLBMKaHDMf72gpiD479rfhd5cPwWol6usSx/CQ DZhdNzoNyPFPx5njugQ741S0k9WUbzsKDOwySK7wqaZ7V2h158OS8USnZQwdMYk5ssKw d8Ag== 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=adwUv+7W6R5gDLqdmK5diDhyPOpt9RkVJIdpNw9QjBc=; b=YOsPkdMvavQ43qQYLQ2nuVX+UxgBp+aTcbx5XxFpYJe6pauatvE98TgG0EyUE5pRs+ /CYz/rzBQdx22JDRA1/J8uUCREirH8m3ttDKrDKaZejHMkXhjchsTlAwCmvLV/BHHRU/ bYE3tXVclIXSHru5Y3OgtlJy/3qj09GLnZYxc1VUFOaR007Lwulx3JFtMHRWTLDPfdmg Aa44JY4r91dcppym028UAFGo9y6/7hQaSwRug7u9WxdP/PgIpK/ZQ3uTp0FKyHB23lve 8k6qDtQuF7+PmLcfgR5j8XhNasbhSUyeaFXhZPg4mF5aXm6dGjEzfa1qzbRJOWePrOkX TQpg== X-Gm-Message-State: APjAAAWCEmJ+bRBbBF5iQ88qx7NgVFiLRbgyj71MMpzSObKP1hwRF46f cVYtCisgLCH9YJCVypn1kotw2Gc63rURP1m7Tvo9oNu/p3M= X-Google-Smtp-Source: APXvYqyGtMkRg9pqctT7HT/gManHNluC3xkdLSHyBhM2b1gPLUGpg8mQB7O15DPLRcWknR/JXRKTenUCDuXxo26VM0Y= X-Received: by 2002:a67:e2d7:: with SMTP id i23mr5747269vsm.31.1573746635475; Thu, 14 Nov 2019 07:50:35 -0800 (PST) MIME-Version: 1.0 References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> In-Reply-To: <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> From: Daniel Migault Date: Thu, 14 Nov 2019 10:50:24 -0500 Message-ID: To: Martin Thomson Cc: tls Content-Type: multipart/alternative; boundary="0000000000002c91e30597507172" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 15:50:39 -0000 --0000000000002c91e30597507172 Content-Type: text/plain; charset="UTF-8" Hi, The current version is clearer than the previous one. However, as I understand the document, it still seems very asymmetric in the sense that it does not provide the client the ability to enforce a number. I believe more guidances/specifications are needed on how to interpret the count value. Interpretation is usually based on implicit assumptions of today's usages, and explicit signaling should, in my opinion, be preferred. In other words, I believe that long term interop will benefit from these additional specifications. The problem stated in the introduction is that the server needs some information from the client in order to generate the appropriated number of tickets. In fact the client is likely to be the one that better knows the number of tickets to be generated, but the current text does not enable the client to enforce that number. Instead this is entirely left to the server. Typically, if a device does not want to have more than one ticket. It should be able to indicate one and be sure it will only receive one ticket. The current specification does not prevent multiple tickets to be sent by the server. The server can ignore the count value (MAY) even though it is known to support the extension. This means that a server could support the extension while still having a hard coded number of tickets. In addition, (SHOULD) let the server determining the number of tickets. Possible ways to address my concerns could be to limit the count value to the number of tickets generated during the KEX, and a server MUST NOT exceed the counter value. The text would need more guidance on how the server SHOULD behave when emitting at different time in the KEX - after the Finished message and after the post handshake authentication. The security consideration should in my opinion consider the fact that a client over UDP/DTLS may use the count value as an amplification factor to have the server flooding a target. The current text only seems to consider the computation aspect, not the bandwidth. If that cannot happen, it might be beneficial to add it. However, when a server sends tickets right after the Finished, it seems to me that can be used as an attack. Yours, Daniel On Tue, Nov 5, 2019 at 8:32 PM Martin Thomson wrote: > There was a lengthy discussion after the last time this was discussed. > Can I request that an editor (or a chair) summarize that discussion and the > resulting actions (if any)? I was involved in that discussion, but I don't > see any changes from that. I'm totally OK with publication as-is, but I > want to make sure that nothing got dropped. > > p.s., it might make sense to include some advisory text on prioritization > of tickets vs. application data. I can see a naive implementation of this > seriously degrading application performance. For instance, it doesn't take > that many tickets to fill an early TCP congestion window. > > p.p.s., yes, if you keep issuing last calls, I will keep finding new > things. > > On Wed, Nov 6, 2019, at 03:05, Sean Turner wrote: > > All, > > > > This is the working group last call for the "TLS Ticket Requests" draft > > available at > > https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/. > > Please review the document and send your comments to the list by 2359 > > UTC on 19 November 2019. > > > > Note the the GH repo for this draft can be found at: > > https://github.com/tlswg/draft-ietf-tls-ticketrequest > > > > Thanks - J&S > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Daniel Migault Ericsson --0000000000002c91e30597507172 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

The current version is clearer than the previou= s one. However, as I
understand the document, it still seems very asymme= tric in the sense
that it does not provide the client the ability to enf= orce a number. I
believe more guidances/specifications are needed on how= to interpret the
count value. Interpretation is usually based on implic= it assumptions of
today's usages, and explicit signaling should, in = my opinion, be preferred. In
other words, I believe that long term inter= op will benefit from these
additional specifications.

The problem= stated in the introduction is that the server needs some
information fr= om the client in order to generate the appropriated number
of tickets. I= n fact the client is likely to be the one that better knows
the number o= f tickets to be generated, but the current text does not
enable the clie= nt to enforce that number. Instead this is entirely left
to the server.<= br>
Typically, if a device does not want to have more than one ticket. I= t
should be able to indicate one and be sure it will only receive oneticket. The current specification does not prevent multiple tickets to
= be sent by the server. The server can ignore the count value (MAY) even though it is known to support the extension. This means that a server
c= ould support the extension while still having a hard coded number of
tic= kets. In addition, (SHOULD) let the server determining the number of
tic= kets.

Possible ways to address my concerns could be to limit the co= unt value
to the number of tickets generated during the KEX, and a serve= r MUST NOT
exceed the counter value. The text would need more guidance o= n how the
server SHOULD behave when emitting at different time in the KE= X - after
the Finished message and after the post handshake authenticati= on.

The security consideration should in my opinion consider the fac= t that a
client over UDP/DTLS may use the count value as an amplificatio= n factor
to have the server flooding a target. The current text only se= ems to
consider the computation aspect, not the bandwidth. If that canno= t
happen, it might be beneficial to add it. However, when a server sends=
tickets right after the Finished, it seems to me that can be used as an=
attack.


Yours,
Daniel


On Tue, Nov 5, 2019 at 8:32 = PM Martin Thomson <mt@lowentropy.ne= t> wrote:
There was a lengthy discussion after the last time this was discussed.=C2= =A0 Can I request that an editor (or a chair) summarize that discussion and= the resulting actions (if any)?=C2=A0 I was involved in that discussion, b= ut I don't see any changes from that.=C2=A0 I'm totally OK with pub= lication as-is, but I want to make sure that nothing got dropped.

p.s., it might make sense to include some advisory text on prioritization o= f tickets vs. application data.=C2=A0 I can see a naive implementation of t= his seriously degrading application performance.=C2=A0 For instance, it doe= sn't take that many tickets to fill an early TCP congestion window.

p.p.s., yes, if you keep issuing last calls, I will keep finding new things= .

On Wed, Nov 6, 2019, at 03:05, Sean Turner wrote:
> All,
>
> This is the working group last call for the "TLS Ticket Requests&= quot; draft
> available at
> https://datatracker.ietf.org/doc= /draft-ietf-tls-ticketrequests/.=C2=A0
> Please review the document and send your comments to the list by 2359 =
> UTC on 19 November 2019.
>
> Note the the GH repo for this draft can be found at:
> https://github.com/tlswg/draft-ietf-tls-t= icketrequest
>
> Thanks - J&S
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--
Daniel Migault
Ericsson
--0000000000002c91e30597507172-- From nobody Thu Nov 14 08:02:01 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A678E120113 for ; Thu, 14 Nov 2019 08:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=ZtmSg+EE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lOTAe4JL 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 QN5lQFbOB5VP for ; Thu, 14 Nov 2019 08:01:58 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E29B4120033 for ; Thu, 14 Nov 2019 08:01:57 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 14B3521A09 for ; Thu, 14 Nov 2019 11:01:55 -0500 (EST) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Thu, 14 Nov 2019 11:01:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=PmzJepTjpdaztXk6Ph2NZNiofbUFhA5 Peeurm/MAq4o=; b=ZtmSg+EEr8z6KBcs48J8t+qlL6/z/oxglbRiDoeupvoyNqi QObLQErwCgFHLEYHsLOKXDP7r6By+e9xSz1vKJo8JZV4mMj0ISzPK+OQBa/gc+ri ANQiULtPb+tFaALze/TMcHGNQFmHaRSonIXjllE/jXwdVaAT5sPhaV61xZ79jfNV n3ydOij2/HojNMKHKIf7Qy5clfnd52fFLgEocsRC6XK0f0TImD85a90zUVdrmykd cIe3OE6/FxA6s+1lMimQNlwD/YHib01pcnssJNU9qLzApuhz09RE/Bqrytg1YeKB Biab67JtgzF4509Kw1J8SMxWnyGsHJMlmbmEcEg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=PmzJep TjpdaztXk6Ph2NZNiofbUFhA5Peeurm/MAq4o=; b=lOTAe4JLQ5lazatbqLJcfM qPh8cioxxxDN4/7cUttPE8+sMS44Fj0r2xjl5feE1b0JhZYvVD6oU+ehJTrXELw/ 7KNmoQ7DGr0M/rDtufUSVgompfxwQl2ZORu5SnZVdjmxMEIOztk5yL0YTC7kUZ5X ibqnq/W1ITaSZ1x8Anv8dFfMoNH3NhFwPw1I/BPmXwkQRwoKuqdPFxvwbaut6Pam +Te2m9D32p1/dYC9RLJxlCKtYN4LBECVOlzPBX0IeC6P9ZXW44URc8qFv32F6Zp5 hzwdQ0b0RPSAbe0vVdF1ng/ZZHV+I2oq6gcmgqH7AvCIDcS1UNcIKqyqoqiGSFaA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeffedgkeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinheptghouhhnthdrrghsne curfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght necuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 587063C00A2; Thu, 14 Nov 2019 11:01:55 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-562-gfd0633a-fmstable-20191114v1 Mime-Version: 1.0 Message-Id: <37ff9a64-2749-4558-a675-5b251f06eb3a@www.fastmail.com> In-Reply-To: References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> Date: Thu, 14 Nov 2019 08:01:34 -0800 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 16:02:00 -0000 On Thu, Nov 14, 2019, at 7:50 AM, Daniel Migault wrote: > Hi, > > The current version is clearer than the previous one. However, as I > understand the document, it still seems very asymmetric in the sense > that it does not provide the client the ability to enforce a number. I > believe more guidances/specifications are needed on how to interpret the > count value. Interpretation is usually based on implicit assumptions of > today's usages, and explicit signaling should, in my opinion, be preferred. In > other words, I believe that long term interop will benefit from these > additional specifications. I disagree with this assessment. The document is clear on this: A supporting server MAY use TicketRequestContents.count when determining how many NewSessionTicket messages to send to a requesting client, and SHOULD place a limit on the number of tickets sent. The number of NewSessionTicket messages sent SHOULD be the minimum of the server's self-imposed limit and TicketRequestContents.count. As has been stated before, the count is a *hint* to the server, nothing more. > The problem stated in the introduction is that the server needs some > information from the client in order to generate the appropriated number > of tickets. In fact the client is likely to be the one that better knows > the number of tickets to be generated, but the current text does not > enable the client to enforce that number. Instead this is entirely left > to the server. As above, I think you're misunderstanding the point of this document. Ticket requests are hints to servers. > Typically, if a device does not want to have more than one ticket. It > should be able to indicate one and be sure it will only receive one > ticket. The current specification does not prevent multiple tickets to > be sent by the server. Right, nor should it. Again, that's not a goal. > The server can ignore the count value (MAY) even > though it is known to support the extension. This means that a server > could support the extension while still having a hard coded number of > tickets. In addition, (SHOULD) let the server determining the number of > tickets. > > Possible ways to address my concerns could be to limit the count value > to the number of tickets generated during the KEX, and a server MUST NOT > exceed the counter value. The text would need more guidance on how the > server SHOULD behave when emitting at different time in the KEX - after > the Finished message and after the post handshake authentication. I don't think any text changes are needed to address these comments. > The security consideration should in my opinion consider the fact that a > client over UDP/DTLS may use the count value as an amplification factor > to have the server flooding a target. The current text only seems to > consider the computation aspect, not the bandwidth. If that cannot > happen, it might be beneficial to add it. However, when a server sends > tickets right after the Finished, it seems to me that can be used as an > attack. I'm not convinced this is useful to add. The target here is the client (attacker) that requested tickets. Best, Chris From nobody Thu Nov 14 08:06:01 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23272120113 for ; Thu, 14 Nov 2019 08:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=TBIL9Ohx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Jubu1dTF 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 TCsvqjtBcMJ2 for ; Thu, 14 Nov 2019 08:05:58 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85E53120033 for ; Thu, 14 Nov 2019 08:05:57 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id BFAA121B2C for ; Thu, 14 Nov 2019 11:05:55 -0500 (EST) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Thu, 14 Nov 2019 11:05:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=AUUMo5ewrv9WsXNgSu+we936igj90n1 ZFThVLl4Hudo=; b=TBIL9OhxTernvulEjP3WTwUH/aYouuiulnSA05QnVG5WqcJ kjmk1j7OxwCw+CcVcIO6yt4e04JKZeXXBtz9Dcp3DNZWxLoSn3cHe8wZkqvY9v7s hU2J8dSxRdrIQSiz/Wg96HP/Qr9CwOey07/en1hUHaQyit2LTi3MJmCnfOfcrL05 NAX98yw0SVdVuHJVpd1yuW/BJPs/A3mGyLSS856Te/ztKoTURgH3eq7fP5OXV75y ryTc5Tx1jGBE04M3IV8OWjwk08/Z08XSsFg4jn9Sn0rPHF/+w92QzkWRcSbOVlBX 3BGDFiswSEyUdKCxsn0lBsNJoMRj7RmDUzt3KZg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=AUUMo5 ewrv9WsXNgSu+we936igj90n1ZFThVLl4Hudo=; b=Jubu1dTFyIO8M2OynN9c5C rbROh/AsbOqqIfE1YGYDkssN/Q2MBr39ZzqxBp4qWAuiC2fMiVkLCSmgjKtwVz66 pywPlurIcaRbFe4U3irWZiCO3unnErP6uXGVmuFVw4h4zER+6Vz8nAACoVxbjPae x6WHyqIgfZFowA9ZpeXonhmgx2y9oqoT0Ux6D8ijwINeoTwgTiBuXsKyb7VZ1DSK hQyuz3V1bmomrMmHOwDy2EC9ktbTeWqCss6s5Vfpf7qSxxTotXiFdlU8YP44cPbt qYje+c78Wp2UAs3/MtmK0sqNfKx9Hvi23nBecVvgu+dNeHyvedKz7gt9i6oXqZmw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeffedgkeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtoh hmpdhivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghp ihhnghgsihhtshdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 43A173C00A1; Thu, 14 Nov 2019 11:05:55 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-562-gfd0633a-fmstable-20191114v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> Date: Thu, 14 Nov 2019 08:05:34 -0800 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 16:06:00 -0000 On Tue, Nov 5, 2019, at 5:32 PM, Martin Thomson wrote: > There was a lengthy discussion after the last time this was discussed. > Can I request that an editor (or a chair) summarize that discussion and > the resulting actions (if any)? I was involved in that discussion, but > I don't see any changes from that. I'm totally OK with publication > as-is, but I want to make sure that nothing got dropped. The only comment that was not integrated was the desire to use the hint to express not only a count, but also a bit indicating whether or not clients will accept a ticket if the server needs to send one (e.g., if its STEK is about to rotate and any old tickets would expire). The authors did not incorporate that into the document since it added complexity and there didn't seem to be much support for it. > p.s., it might make sense to include some advisory text on > prioritization of tickets vs. application data. I can see a naive > implementation of this seriously degrading application performance. > For instance, it doesn't take that many tickets to fill an early TCP > congestion window. Sure, we can add that: https://github.com/tlswg/draft-ietf-tls-ticketrequest/issues/9 > p.p.s., yes, if you keep issuing last calls, I will keep finding new things. :-) Thanks, Chris > > On Wed, Nov 6, 2019, at 03:05, Sean Turner wrote: > > All, > > > > This is the working group last call for the "TLS Ticket Requests" draft > > available at > > https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/. > > Please review the document and send your comments to the list by 2359 > > UTC on 19 November 2019. > > > > Note the the GH repo for this draft can be found at: > > https://github.com/tlswg/draft-ietf-tls-ticketrequest > > > > Thanks - J&S > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu Nov 14 08:20:12 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593CD1201DC for ; Thu, 14 Nov 2019 08:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SejDIIQ_qVJt for ; Thu, 14 Nov 2019 08:20:07 -0800 (PST) Received: from mail-vk1-f182.google.com (mail-vk1-f182.google.com [209.85.221.182]) (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 176A8120113 for ; Thu, 14 Nov 2019 08:20:07 -0800 (PST) Received: by mail-vk1-f182.google.com with SMTP id f27so1597730vkl.11 for ; Thu, 14 Nov 2019 08:20:07 -0800 (PST) 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=8XRJqhihbZtCJd44Cb5kh3PHNZXroLCIluP2QKPH7O0=; b=FKUNuBql3bElXnzFMqMJK3OoT+pLZgphMUYFCNeXNzwBj0HJ8HMOHtKuKDqtkMOQSI C5HemtYwMq76jbO6PmQ4DGgzJyuksjgHbXYTiz+LQeV11LTiXYokP8yjhhtF2LcxnNjb b3jdrme4QtzzxCq3ojdJuYMm5+1j2C/nJo6RBqHtnLc9Z3pxq8PGuwHdwCYR0x2meneD t8PfSb21uXcg1ktJJRRS8iw6HNVy2ZpCo2XVp1I8rZYncH+JGrWlEGXM91l0DcCXQGqG KuOnwu1GwLgHt83Wavza1JIbN348Q5uAVu+6anbn2iq0VXWxlJd5UphC5uRZwAsYijoD 6xdw== X-Gm-Message-State: APjAAAWC0lpEe2r3hAibNrpkNMOjJRdRN6qgvmjmMSaFVAAYdQ8ZjWyv hlKlRVZVK/Mx5eS7srR7WKK/Ls+I06t5HBtsUvfmV4qp X-Google-Smtp-Source: APXvYqx3agQTJQw/JLrLqFO3dgYYTBAaDHQC5RYfdt1Tqj3pkZcif7SKbUT/gPZBzX+QHQ3MVCVZSfxTqS+mSpH4frI= X-Received: by 2002:a1f:a592:: with SMTP id o140mr2003573vke.30.1573748405906; Thu, 14 Nov 2019 08:20:05 -0800 (PST) MIME-Version: 1.0 References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <37ff9a64-2749-4558-a675-5b251f06eb3a@www.fastmail.com> In-Reply-To: <37ff9a64-2749-4558-a675-5b251f06eb3a@www.fastmail.com> From: Daniel Migault Date: Thu, 14 Nov 2019 11:19:55 -0500 Message-ID: To: Christopher Wood Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b33102059750da09" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 16:20:09 -0000 --000000000000b33102059750da09 Content-Type: text/plain; charset="UTF-8" Hi Chris, Thanks for the responses, please see my comments inline. Yours, Daniel On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood wrote: > On Thu, Nov 14, 2019, at 7:50 AM, Daniel Migault wrote: > > Hi, > > > > The current version is clearer than the previous one. However, as I > > understand the document, it still seems very asymmetric in the sense > > that it does not provide the client the ability to enforce a number. I > > believe more guidances/specifications are needed on how to interpret the > > count value. Interpretation is usually based on implicit assumptions of > > today's usages, and explicit signaling should, in my opinion, be > preferred. In > > other words, I believe that long term interop will benefit from these > > additional specifications. > > I disagree with this assessment. The document is clear on this: > > A supporting server MAY use TicketRequestContents.count when > determining how many NewSessionTicket messages to send to a > requesting client, and SHOULD place a limit on the number of tickets > sent. The number of NewSessionTicket messages sent SHOULD be the > minimum of the server's self-imposed limit and > TicketRequestContents.count. > > As has been stated before, the count is a *hint* to the server, nothing > more. > > That is my point, in my opinion a hint is under specified. > > The problem stated in the introduction is that the server needs some > > information from the client in order to generate the appropriated number > > of tickets. In fact the client is likely to be the one that better knows > > the number of tickets to be generated, but the current text does not > > enable the client to enforce that number. Instead this is entirely left > > to the server. > > As above, I think you're misunderstanding the point of this document. > Ticket requests are hints to servers. > > On the contrary, I think I understood it correctly. > > Typically, if a device does not want to have more than one ticket. It > > should be able to indicate one and be sure it will only receive one > > ticket. The current specification does not prevent multiple tickets to > > be sent by the server. > > Right, nor should it. Again, that's not a goal. > > > The server can ignore the count value (MAY) even > > though it is known to support the extension. This means that a server > > could support the extension while still having a hard coded number of > > tickets. In addition, (SHOULD) let the server determining the number of > > tickets. > > > > Possible ways to address my concerns could be to limit the count value > > to the number of tickets generated during the KEX, and a server MUST NOT > > exceed the counter value. The text would need more guidance on how the > > server SHOULD behave when emitting at different time in the KEX - after > > the Finished message and after the post handshake authentication. > > I don't think any text changes are needed to address these comments. > > > The security consideration should in my opinion consider the fact that a > > client over UDP/DTLS may use the count value as an amplification factor > > to have the server flooding a target. The current text only seems to > > consider the computation aspect, not the bandwidth. If that cannot > > happen, it might be beneficial to add it. However, when a server sends > > tickets right after the Finished, it seems to me that can be used as an > > attack. > > I'm not convinced this is useful to add. The target here is the client > (attacker) that requested tickets. > The target is the spoofed source IP address. > > Best, > Chris > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000b33102059750da09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Chris,=C2=A0

Thanks for t= he responses, please see my comments inline.=C2=A0

Yours,=C2=A0
Daniel

On Thu, Nov 14, 2019 at 11:02 AM Christopher = Wood <caw@heapingbits.net>= wrote:
On Thu, = Nov 14, 2019, at 7:50 AM, Daniel Migault wrote:
> Hi,
>
> The current version is clearer than the previous one. However, as I > understand the document, it still seems very asymmetric in the sense > that it does not provide the client the ability to enforce a number. I=
> believe more guidances/specifications are needed on how to interpret t= he
> count value. Interpretation is usually based on implicit assumptions o= f
> today's usages, and explicit signaling should, in my opinion, be p= referred. In
> other words, I believe that long term interop will benefit from these<= br> > additional specifications.

I disagree with this assessment. The document is clear on this:

=C2=A0 =C2=A0A supporting server MAY use TicketRequestContents.count when =C2=A0 =C2=A0determining how many NewSessionTicket messages to send to a =C2=A0 =C2=A0requesting client, and SHOULD place a limit on the number of t= ickets
=C2=A0 =C2=A0sent.=C2=A0 The number of NewSessionTicket messages sent SHOUL= D be the
=C2=A0 =C2=A0minimum of the server's self-imposed limit and
=C2=A0 =C2=A0TicketRequestContents.count.

As has been stated before, the count is a *hint* to the server, nothing mor= e.

That is my point, in my opinion a hint is under speci= fied.=C2=A0
=C2=A0
> The problem stated in the introduction is that the server needs some > information from the client in order to generate the appropriated numb= er
> of tickets. In fact the client is likely to be the one that better kno= ws
> the number of tickets to be generated, but the current text does not > enable the client to enforce that number. Instead this is entirely lef= t
> to the server.

As above, I think you're misunderstanding the point of this document. T= icket requests are hints to servers.

On the contrary, I think I understood it correctly.= =C2=A0
=C2=A0
> Typically, if a device does not want to have more than one ticket. It<= br> > should be able to indicate one and be sure it will only receive one > ticket. The current specification does not prevent multiple tickets to=
> be sent by the server.

Right, nor should it. Again, that's not a goal.

> The server can ignore the count value (MAY) even
> though it is known to support the extension. This means that a server<= br> > could support the extension while still having a hard coded number of<= br> > tickets. In addition, (SHOULD) let the server determining the number o= f
> tickets.
>
> Possible ways to address my concerns could be to limit the count value=
> to the number of tickets generated during the KEX, and a server MUST N= OT
> exceed the counter value. The text would need more guidance on how the=
> server SHOULD behave when emitting at different time in the KEX - afte= r
> the Finished message and after the post handshake authentication.

I don't think any text changes are needed to address these comments.
> The security consideration should in my opinion consider the fact that= a
> client over UDP/DTLS may use the count value as an amplification facto= r
> to have the server flooding a target. The current text only seems to > consider the computation aspect, not the bandwidth. If that cannot
> happen, it might be beneficial to add it. However, when a server sends=
> tickets right after the Finished, it seems to me that can be used as a= n
> attack.

I'm not convinced this is useful to add. The target here is the client = (attacker) that requested tickets.
=C2=A0
The target is the spoofed sou= rce IP address.
=C2=A0
=C2=A0Best,
Chris

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000b33102059750da09-- From nobody Thu Nov 14 08:24:59 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7D112023E for ; Thu, 14 Nov 2019 08:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=aaH53Krf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Xe4nJT1C 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 Gt7pVonMYJfe for ; Thu, 14 Nov 2019 08:24:55 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3623412000F for ; Thu, 14 Nov 2019 08:24:55 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D3F3522063; Thu, 14 Nov 2019 11:24:53 -0500 (EST) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Thu, 14 Nov 2019 11:24:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=ZxYPEUnW2wlQxHsR/JvNu26cRVU8 glCPcaXFn5FfcGQ=; b=aaH53KrfaYIrKHo6mzicpodoTrcuuKOaCoPCBduK8PHZ XfqxL4s3O4eQmeCmf/0JUTPYoGMA7vi2PqhNg/9zz7IkRsqfTjZCCKnafsQzCeOf aGKMvnqM6ND0+KUOVQn91JdUpHfgr3vZLKjBs5t1U/RtZpfYbli/7SLWMzlngJFC hA+D3R2XmTc3SFbCvDRp5H6m/u0H5Wr7EZW4c/lVdSMcTM4Gbo99Ul27Y6B3Qad0 8MxGSEyup4pWVg0YmwAq1mDAVTawZj1XIRJs+QewETPdUV+VaDDnGixaB+ZQqS0z nVpVvMr4UxZTOyQEo3EGZBD7RpfVmLzBz453n7n0vg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ZxYPEU nW2wlQxHsR/JvNu26cRVU8glCPcaXFn5FfcGQ=; b=Xe4nJT1Cg5xqFwoNGtlsrP zFwdRytUsbdmYtahD5M2DYCehnJ5M/OIgi0u5gIDFO8kiXxR+k6qg2qm8Qnp40gf 7+TY5/37qOxFvTKhjrqyIXcILM7HNdXiXK3C61cGrVWOsdPc/5+fxdNiVSfbzckn H823qrtvs4EdeXig6g12GcvNQulyLtIlSkYJv0KZ4h8CAs1Tr/2UZlQN7DtAEm6s W8q3TtdrfZ9OuAGfBqyXFzD4eSPUhOZ82yzmaA4yVm6WJZS/TU1f+M6fGfc7MPW6 py8l/gDjd4QGREee6JXDtr9JZhjxGwNboIDB/hk0uYQX8I/KyDP/xE7jMNgf8YWA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeffedgkeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdevhhhr ihhsthhophhhvghrucghohhougdfuceotggrfieshhgvrghpihhnghgsihhtshdrnhgvth eqnecuffhomhgrihhnpegtohhunhhtrdgrshdpihgvthhfrdhorhhgnecurfgrrhgrmhep mhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvghtnecuvehluhhsth gvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4BC5F3C00A1; Thu, 14 Nov 2019 11:24:52 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-562-gfd0633a-fmstable-20191114v1 Mime-Version: 1.0 Message-Id: <1cd34aff-915e-4f70-8f03-b644dab201c9@www.fastmail.com> In-Reply-To: References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <37ff9a64-2749-4558-a675-5b251f06eb3a@www.fastmail.com> Date: Thu, 14 Nov 2019 08:24:32 -0800 From: "Christopher Wood" To: "Daniel Migault" Cc: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 16:24:58 -0000 On Thu, Nov 14, 2019, at 8:19 AM, Daniel Migault wrote: > Hi Chris, > > Thanks for the responses, please see my comments inline. > > Yours, > Daniel > > On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood wrote: > > On Thu, Nov 14, 2019, at 7:50 AM, Daniel Migault wrote: > > > Hi, > > > > > > The current version is clearer than the previous one. However, as I > > > understand the document, it still seems very asymmetric in the sense > > > that it does not provide the client the ability to enforce a number. I > > > believe more guidances/specifications are needed on how to interpret the > > > count value. Interpretation is usually based on implicit assumptions of > > > today's usages, and explicit signaling should, in my opinion, be preferred. In > > > other words, I believe that long term interop will benefit from these > > > additional specifications. > > > > I disagree with this assessment. The document is clear on this: > > > > A supporting server MAY use TicketRequestContents.count when > > determining how many NewSessionTicket messages to send to a > > requesting client, and SHOULD place a limit on the number of tickets > > sent. The number of NewSessionTicket messages sent SHOULD be the > > minimum of the server's self-imposed limit and > > TicketRequestContents.count. > > > > As has been stated before, the count is a *hint* to the server, nothing more. > > > That is my point, in my opinion a hint is under specified. I acknowledge your opinion, but as I think I've made clear, I don't agree. Sorry! > > > The problem stated in the introduction is that the server needs some > > > information from the client in order to generate the appropriated number > > > of tickets. In fact the client is likely to be the one that better knows > > > the number of tickets to be generated, but the current text does not > > > enable the client to enforce that number. Instead this is entirely left > > > to the server. > > > > As above, I think you're misunderstanding the point of this document. Ticket requests are hints to servers. > > > On the contrary, I think I understood it correctly. > > > Typically, if a device does not want to have more than one ticket. It > > > should be able to indicate one and be sure it will only receive one > > > ticket. The current specification does not prevent multiple tickets to > > > be sent by the server. > > > > Right, nor should it. Again, that's not a goal. > > > > > The server can ignore the count value (MAY) even > > > though it is known to support the extension. This means that a server > > > could support the extension while still having a hard coded number of > > > tickets. In addition, (SHOULD) let the server determining the number of > > > tickets. > > > > > > Possible ways to address my concerns could be to limit the count value > > > to the number of tickets generated during the KEX, and a server MUST NOT > > > exceed the counter value. The text would need more guidance on how the > > > server SHOULD behave when emitting at different time in the KEX - after > > > the Finished message and after the post handshake authentication. > > > > I don't think any text changes are needed to address these comments. > > > > > The security consideration should in my opinion consider the fact that a > > > client over UDP/DTLS may use the count value as an amplification factor > > > to have the server flooding a target. The current text only seems to > > > consider the computation aspect, not the bandwidth. If that cannot > > > happen, it might be beneficial to add it. However, when a server sends > > > tickets right after the Finished, it seems to me that can be used as an > > > attack. > > > > I'm not convinced this is useful to add. The target here is the client (attacker) that requested tickets. > The target is the spoofed source IP address. That would imply the attacker is able to complete a connection with this spoofed address, no? > > Best, > > Chris > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Nov 14 08:43:33 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE361208A0 for ; Thu, 14 Nov 2019 08:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2javZsmHaS3 for ; Thu, 14 Nov 2019 08:43:26 -0800 (PST) Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42]) (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 9EBBC120A36 for ; Thu, 14 Nov 2019 08:43:24 -0800 (PST) Received: by mail-vs1-f42.google.com with SMTP id b16so4288112vso.10 for ; Thu, 14 Nov 2019 08:43:24 -0800 (PST) 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=SMohh9xTf3NEnPfFFhf255rbmt4aTr8CWqDDfNdx3F0=; b=SmWycI4VU2qVu1JwloidROcylLo8c0250Kgg92buUxmRIAjaPNVmezAhaqiq+Ayb1+ DoAeQTMTsTO8IJ2zJkjlIq8o19ed3k/phoDo9fJ88asV0Vip/GRezZ0xrttLX4K82HUW Fdih+zsqzmV3Epp3NLXsY4+BhBXkMxmk8eTtV9DcyJgVI6F5T2H9WHvpoQA0vzSFKxtG olaCCJFo1tNVxWCmZWlGBOwk+ZDW8xFFUIZ9vyO9SV9+e3pfHXAFnAwvx1HISZHWV3NX l7Vs06GWXwWas1KsfItAt9qSr7MYYekwso15Cg2ndDpSkBQTSB8lH8i2NmofaiE5mR4c Pwrg== X-Gm-Message-State: APjAAAW+L2VUrKTkhq+KcFrAxX922o4XArAn0NMqyvm2nKpjjR+xMm23 ofH2srx6ixWnVNkDtFLS0q6byrGv6kx9yz5lKu0= X-Google-Smtp-Source: APXvYqx2AmlhgChEjt5d3gUYZeqZ3RkC0wl9aG/qmOsIGAY6FelnDzmGxtxD02sYRT+tVnzq6129ox8BezRD5Ud9zvw= X-Received: by 2002:a67:7a8d:: with SMTP id v135mr6133354vsc.97.1573749803631; Thu, 14 Nov 2019 08:43:23 -0800 (PST) MIME-Version: 1.0 References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <37ff9a64-2749-4558-a675-5b251f06eb3a@www.fastmail.com> <1cd34aff-915e-4f70-8f03-b644dab201c9@www.fastmail.com> In-Reply-To: <1cd34aff-915e-4f70-8f03-b644dab201c9@www.fastmail.com> From: Daniel Migault Date: Thu, 14 Nov 2019 11:43:12 -0500 Message-ID: To: Christopher Wood Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000002caf30597512edd" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 16:43:31 -0000 --00000000000002caf30597512edd Content-Type: text/plain; charset="UTF-8" Hi, If tickets are sent right after the server Finished, before the the client Finished, these are only triggered by the clientHello - at least this is my understanding. Yours, Daniel On Thu, Nov 14, 2019 at 11:25 AM Christopher Wood wrote: > > > On Thu, Nov 14, 2019, at 8:19 AM, Daniel Migault wrote: > > Hi Chris, > > > > Thanks for the responses, please see my comments inline. > > > > Yours, > > Daniel > > > > On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood > wrote: > > > On Thu, Nov 14, 2019, at 7:50 AM, Daniel Migault wrote: > > > > Hi, > > > > > > > > The current version is clearer than the previous one. However, as I > > > > understand the document, it still seems very asymmetric in the sense > > > > that it does not provide the client the ability to enforce a > number. I > > > > believe more guidances/specifications are needed on how to > interpret the > > > > count value. Interpretation is usually based on implicit > assumptions of > > > > today's usages, and explicit signaling should, in my opinion, be > preferred. In > > > > other words, I believe that long term interop will benefit from > these > > > > additional specifications. > > > > > > I disagree with this assessment. The document is clear on this: > > > > > > A supporting server MAY use TicketRequestContents.count when > > > determining how many NewSessionTicket messages to send to a > > > requesting client, and SHOULD place a limit on the number of tickets > > > sent. The number of NewSessionTicket messages sent SHOULD be the > > > minimum of the server's self-imposed limit and > > > TicketRequestContents.count. > > > > > > As has been stated before, the count is a *hint* to the server, > nothing more. > > > > > That is my point, in my opinion a hint is under specified. > > I acknowledge your opinion, but as I think I've made clear, I don't agree. > Sorry! > > > > > The problem stated in the introduction is that the server needs some > > > > information from the client in order to generate the appropriated > number > > > > of tickets. In fact the client is likely to be the one that better > knows > > > > the number of tickets to be generated, but the current text does not > > > > enable the client to enforce that number. Instead this is entirely > left > > > > to the server. > > > > > > As above, I think you're misunderstanding the point of this document. > Ticket requests are hints to servers. > > > > > On the contrary, I think I understood it correctly. > > > > Typically, if a device does not want to have more than one ticket. > It > > > > should be able to indicate one and be sure it will only receive one > > > > ticket. The current specification does not prevent multiple tickets > to > > > > be sent by the server. > > > > > > Right, nor should it. Again, that's not a goal. > > > > > > > The server can ignore the count value (MAY) even > > > > though it is known to support the extension. This means that a > server > > > > could support the extension while still having a hard coded number > of > > > > tickets. In addition, (SHOULD) let the server determining the > number of > > > > tickets. > > > > > > > > Possible ways to address my concerns could be to limit the count > value > > > > to the number of tickets generated during the KEX, and a server > MUST NOT > > > > exceed the counter value. The text would need more guidance on how > the > > > > server SHOULD behave when emitting at different time in the KEX - > after > > > > the Finished message and after the post handshake authentication. > > > > > > I don't think any text changes are needed to address these comments. > > > > > > > The security consideration should in my opinion consider the fact > that a > > > > client over UDP/DTLS may use the count value as an amplification > factor > > > > to have the server flooding a target. The current text only seems to > > > > consider the computation aspect, not the bandwidth. If that cannot > > > > happen, it might be beneficial to add it. However, when a server > sends > > > > tickets right after the Finished, it seems to me that can be used > as an > > > > attack. > > > > > > I'm not convinced this is useful to add. The target here is the > client (attacker) that requested tickets. > > The target is the spoofed source IP address. > > That would imply the attacker is able to complete a connection with this > spoofed address, no? > > > > Best, > > > Chris > > > > > > _______________________________________________ > > > TLS mailing list > > > TLS@ietf.org > > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000002caf30597512edd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

If tickets are sen= t right after the server Finished, before the the client Finished, these ar= e only triggered by the clientHello - at least this is my understanding.

Yours,=C2=A0
Daniel

On Thu, Nov 14, 2019 at 11:= 25 AM Christopher Wood <caw@heapi= ngbits.net> wrote:


On Thu, Nov 14, 2019, at 8:19 AM, Daniel Migault wrote:
> Hi Chris,
>
> Thanks for the responses, please see my comments inline.
>
> Yours,
> Daniel
>
> On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood <caw@heapingbits.net> wrote:=
> > On Thu, Nov 14, 2019, at 7:50 AM, Daniel Migault wrote:
> >=C2=A0 > Hi,
> >=C2=A0 >
> >=C2=A0 > The current version is clearer than the previous one. = However, as I
> >=C2=A0 > understand the document, it still seems very asymmetri= c in the sense
> >=C2=A0 > that it does not provide the client the ability to enf= orce a number. I
> >=C2=A0 > believe more guidances/specifications are needed on ho= w to interpret the
> >=C2=A0 > count value. Interpretation is usually based on implic= it assumptions of
> >=C2=A0 > today's usages, and explicit signaling should, in = my opinion, be preferred. In
> >=C2=A0 > other words, I believe that long term interop will ben= efit from these
> >=C2=A0 > additional specifications.
> >
> >=C2=A0 I disagree with this assessment. The document is clear on t= his:
> >
> >=C2=A0 A supporting server MAY use TicketRequestContents.count whe= n
> >=C2=A0 determining how many NewSessionTicket messages to send to a=
> >=C2=A0 requesting client, and SHOULD place a limit on the number o= f tickets
> >=C2=A0 sent. The number of NewSessionTicket messages sent SHOULD b= e the
> >=C2=A0 minimum of the server's self-imposed limit and
> >=C2=A0 TicketRequestContents.count.
> >
> >=C2=A0 As has been stated before, the count is a *hint* to the ser= ver, nothing more.
> >
> That is my point, in my opinion a hint is under specified.

I acknowledge your opinion, but as I think I've made clear, I don't= agree. Sorry!

> >=C2=A0 > The problem stated in the introduction is that the ser= ver needs some
> >=C2=A0 > information from the client in order to generate the a= ppropriated number
> >=C2=A0 > of tickets. In fact the client is likely to be the one= that better knows
> >=C2=A0 > the number of tickets to be generated, but the current= text does not
> >=C2=A0 > enable the client to enforce that number. Instead this= is entirely left
> >=C2=A0 > to the server.
> >
> >=C2=A0 As above, I think you're misunderstanding the point of = this document. Ticket requests are hints to servers.
> >
> On the contrary, I think I understood it correctly.
> >=C2=A0 > Typically, if a device does not want to have more than= one ticket. It
> >=C2=A0 > should be able to indicate one and be sure it will onl= y receive one
> >=C2=A0 > ticket. The current specification does not prevent mul= tiple tickets to
> >=C2=A0 > be sent by the server.
> >
> >=C2=A0 Right, nor should it. Again, that's not a goal.
> >
> >=C2=A0 > The server can ignore the count value (MAY) even
> >=C2=A0 > though it is known to support the extension. This mean= s that a server
> >=C2=A0 > could support the extension while still having a hard = coded number of
> >=C2=A0 > tickets. In addition, (SHOULD) let the server determin= ing the number of
> >=C2=A0 > tickets.
> >=C2=A0 >
> >=C2=A0 > Possible ways to address my concerns could be to limit= the count value
> >=C2=A0 > to the number of tickets generated during the KEX, and= a server MUST NOT
> >=C2=A0 > exceed the counter value. The text would need more gui= dance on how the
> >=C2=A0 > server SHOULD behave when emitting at different time i= n the KEX - after
> >=C2=A0 > the Finished message and after the post handshake auth= entication.
> >
> >=C2=A0 I don't think any text changes are needed to address th= ese comments.
> >
> >=C2=A0 > The security consideration should in my opinion consid= er the fact that a
> >=C2=A0 > client over UDP/DTLS may use the count value as an amp= lification factor
> >=C2=A0 > to have the server flooding a target. The current text= only seems to
> >=C2=A0 > consider the computation aspect, not the bandwidth. If= that cannot
> >=C2=A0 > happen, it might be beneficial to add it. However, whe= n a server sends
> >=C2=A0 > tickets right after the Finished, it seems to me that = can be used as an
> >=C2=A0 > attack.
> >
> >=C2=A0 I'm not convinced this is useful to add. The target her= e is the client (attacker) that requested tickets.
> The target is the spoofed source IP address.

That would imply the attacker is able to complete a connection with this sp= oofed address, no?

> >=C2=A0 Best,
> >=C2=A0 Chris
> >
> >=C2=A0 _______________________________________________
> >=C2=A0 TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000002caf30597512edd-- From nobody Thu Nov 14 08:48:30 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7512C120880 for ; Thu, 14 Nov 2019 08:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=gaUsKbId; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mtcFgUIK 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 FPSPGxPdP-6V for ; Thu, 14 Nov 2019 08:48:26 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFAD8120874 for ; Thu, 14 Nov 2019 08:48:26 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E4A2F2129D; Thu, 14 Nov 2019 11:48:25 -0500 (EST) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Thu, 14 Nov 2019 11:48:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=48SwzveNhxaNcUW3pkeXCmqGZizI llfAQhftd/2bDzY=; b=gaUsKbIdY/HJOvvz+/DVw7gkRmN3vDQ3IWo5Qg5u9sxF TBW1aOqYUJteS8KXfGtUUeuTJ727AlKP49bKE+FC7cgM1D3X6V6HmCBGKLEMZAZB 5Z/i6YXEPqR3kRXhhfeHvZbtJ0QmjkHG5SOPqI76YxSuI8I3fmNmRsn9hIRxJz6x bE3BdSffYizBV+g64BT0WzD0AODt+PT2eer/y5J9rMy6Z6TWIDiBVaJSQbOAi5xg 6t9030ZUDVgnl23LTmVGhc1xkRuzXzLmtDetATwuo6r1E9PaVveZvLqQy8FjF3FJ muZTQqeQVMRV8QgiraExiqcnbBuIbGmUxK5PKdKe4Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=48Swzv eNhxaNcUW3pkeXCmqGZizIllfAQhftd/2bDzY=; b=mtcFgUIKaRZ41bx9npmTRm RKNARHuEVwFAta9gGA/lZPqzAJ9oA03izy6aVflEVlU0BpYAqV6UCD8RvP1nPUvC HBWWnKBKz6wYiJnbnXba0FoANP4qg3zrh86gQKFuTD29jNV2i2a1TMuHHcyGHYK1 p2Yv0uvF9vx4iQmTHuBl1zFJGankYP3XVPhs1ZNO7cmjDbEnQ+8+Ht/A8WZYQEEy 0XLU5xMREEksO3woY5uKhmZM1jrFvarSCT8RjU12pGWPoYRNbVnWnfFGgfJ9tL9L l1QGrFRHMOyhQ5yDDzKwqXpll79hVrAtoZe2Sm4o3VLkW4M8Xb+3xrcloBSBr0aw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeffedgleefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdevhhhr ihhsthhophhhvghrucghohhougdfuceotggrfieshhgvrghpihhnghgsihhtshdrnhgvth eqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhn vghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A862E3C00A1; Thu, 14 Nov 2019 11:48:25 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-562-gfd0633a-fmstable-20191114v1 Mime-Version: 1.0 Message-Id: <99300d33-5a29-47e1-88ac-c83d385a9263@www.fastmail.com> In-Reply-To: References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <37ff9a64-2749-4558-a675-5b251f06eb3a@www.fastmail.com> <1cd34aff-915e-4f70-8f03-b644dab201c9@www.fastmail.com> Date: Thu, 14 Nov 2019 08:48:05 -0800 From: "Christopher Wood" To: "Daniel Migault" Cc: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 16:48:29 -0000 On Thu, Nov 14, 2019, at 8:43 AM, Daniel Migault wrote: > If tickets are sent right after the server Finished, before the the > client Finished, these are only triggered by the clientHello - at least > this is my understanding. Yes, that's correct. I thought your comment was about post-handshake tickets (after confirmation from the client). Adding a note about this pre-handshake completion is fine with me. Best, Chris From nobody Thu Nov 14 08:51:36 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC9E120880 for ; Thu, 14 Nov 2019 08:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=ggUAAgjg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cTnvv/Qk 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 HLjrtf4BdM6F for ; Thu, 14 Nov 2019 08:51:32 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B099120874 for ; Thu, 14 Nov 2019 08:51:32 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id AA27020CB3 for ; Thu, 14 Nov 2019 11:51:31 -0500 (EST) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Thu, 14 Nov 2019 11:51:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=sbA1G9wZ/1YLAscalMOnpXcCyUotT8E 9G1IHCnweGsw=; b=ggUAAgjgVR9SBUwGFpanplLgR3idezBxIwRHQNPRjQp7fwP +s5S5va8RFTSEkRnVBEQfqAqtTYtFoXjXP93lmRWBzx1ONFz2GRhzB39Cr5jPxo5 Qq/okgLXJODI1W+jVlgDxOGs4+/ZWBCCtx67Yxct4yp1awwsSfzQ+oAynleI17QM X3OSp7lTiZ9KFQ4nfp8xZ6Yb/cRdL+b9xwAbO3g/AQkG1JVF5l4PLqb2XxuZw1rs vyQ4YxpJaneL3DJpE7/+BiZ4ZbdMLAv4YjkpDbu3R6kfabP7GNlPZlA1nsLrRZsj Bvpvp/nnyIuj8rRHZ3k+gAG2hmNn+Uyb04nF5QQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=sbA1G9 wZ/1YLAscalMOnpXcCyUotT8E9G1IHCnweGsw=; b=cTnvv/QkwvR3QAWeNfmpnO Nn/7heVS9XPG3Mdbr4fuiUp0U0DNO6JE6s1M5U//hLU3/AqosfLcn/9Zx0fefkdz EA73SuOj0w4RiNMgm6sTyOyVyuwTP984OMsz5sCSpo2r4OitwRRwU60fB7/KOoJ9 hf/1taM7Rr8iYPBiWG4gwM8+jWBsrZSy2iNwp2vsjJhIHEDJECvQSWIRNTlnAM2t 9/QabnWqgDGdu5LnSR6H/M8URD9PF/zONiSpu/5OgvJCqNKFfb1LHZdWMU7QesNL 2oT7nnsF1V8gPvCG1MbLgqWvRsjE1SasVjvD5uWdNfitNTQr06UI7YsXQrlUnrLQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeffedgleefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgne curfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght necuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 35BE73C00A1; Thu, 14 Nov 2019 11:51:31 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-562-gfd0633a-fmstable-20191114v1 Mime-Version: 1.0 Message-Id: <895cd06a-a75a-45f4-986d-c1eaa7d4c83d@www.fastmail.com> In-Reply-To: <99300d33-5a29-47e1-88ac-c83d385a9263@www.fastmail.com> References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <37ff9a64-2749-4558-a675-5b251f06eb3a@www.fastmail.com> <1cd34aff-915e-4f70-8f03-b644dab201c9@www.fastmail.com> <99300d33-5a29-47e1-88ac-c83d385a9263@www.fastmail.com> Date: Thu, 14 Nov 2019 08:51:09 -0800 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 16:51:34 -0000 On Thu, Nov 14, 2019, at 8:48 AM, Christopher Wood wrote: > On Thu, Nov 14, 2019, at 8:43 AM, Daniel Migault wrote: > > If tickets are sent right after the server Finished, before the the > > client Finished, these are only triggered by the clientHello - at least > > this is my understanding. > > Yes, that's correct. I thought your comment was about post-handshake > tickets (after confirmation from the client). Adding a note about this > pre-handshake completion is fine with me. Scratch that! I forgot we limited this extension to TLS 1.3, which prohibits sending NSTs until the client finished is received (https://tools.ietf.org/html/rfc8446#section-4.6.1). Best, Chris From nobody Thu Nov 14 08:57:55 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F1C120849 for ; Thu, 14 Nov 2019 08:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBp3cUUo_aej for ; Thu, 14 Nov 2019 08:57:52 -0800 (PST) Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BB1E1202DD for ; Thu, 14 Nov 2019 08:57:52 -0800 (PST) Received: by mail-vs1-f48.google.com with SMTP id m6so4310218vsn.13 for ; Thu, 14 Nov 2019 08:57:52 -0800 (PST) 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=0pWf05pZE1l2ZptVQxdTgsuJlC41DfNDY/gPyLo9Xl8=; b=Mb5a3aUry2Vp/KW6zm2SfhP5yRM2bQP3bRQkIrLXiWYH+DMq6CfQ3rJt+siDYk22n9 tVzYNcKojQtfOu1vHG6wHRPaFcXwL2UTI4prYTENDGPYDha2svCdSqTPgJzA58ffZjO7 9aaXSpp6Wa0WFnawlJQ234RnKKEtN0gnjphMxODYwbTT5gqTKCCz2KHKC4KfHELXBCjy cRH/0ufylUBh0XnUNoSDOX/fcJyp4eJsI+e578Ka+q9l0PXkG+YZxkCW9QFIQT6x5hK7 2oBxhNscxxHQwXF1EzwnM/ta/zoM6EPB5dVErcBZvGxKGx3dRM1TNi6+0uC8bdGPkfsT cTfw== X-Gm-Message-State: APjAAAUEPmnQVCcnf9g6U+jiOPj7XRb5Wcs0f28D/JvBnNeYSbztqFiK 2I0s36D0LqQka433HX6Y6zHkLvY+wRoDg2Pxc0Q= X-Google-Smtp-Source: APXvYqxfERmxu4uGQfbIXg6CwOw4q837pp/OEuW6htUF5OBp+laV54rCHFqBJlFBapJLou0VhI9n/GKjmdVn0wcpBZ0= X-Received: by 2002:a67:bd05:: with SMTP id y5mr6404155vsq.180.1573750671385; Thu, 14 Nov 2019 08:57:51 -0800 (PST) MIME-Version: 1.0 References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <37ff9a64-2749-4558-a675-5b251f06eb3a@www.fastmail.com> <1cd34aff-915e-4f70-8f03-b644dab201c9@www.fastmail.com> <99300d33-5a29-47e1-88ac-c83d385a9263@www.fastmail.com> <895cd06a-a75a-45f4-986d-c1eaa7d4c83d@www.fastmail.com> In-Reply-To: <895cd06a-a75a-45f4-986d-c1eaa7d4c83d@www.fastmail.com> From: Daniel Migault Date: Thu, 14 Nov 2019 11:57:40 -0500 Message-ID: To: Christopher Wood Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bba638059751619b" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 16:57:54 -0000 --000000000000bba638059751619b Content-Type: text/plain; charset="UTF-8" Unless I am missing something, the text below seems to say otherwise. Note: Although the resumption master secret depends on the client's second flight, a server which does not request client authentication MAY compute the remainder of the transcript independently and then send a NewSessionTicket immediately upon sending its Finished rather than waiting for the client Finished. This might be appropriate in cases where the client is expected to open multiple TLS connections in parallel and would benefit from the reduced overhead of a resumption handshake, for example. On Thu, Nov 14, 2019 at 11:52 AM Christopher Wood wrote: > On Thu, Nov 14, 2019, at 8:48 AM, Christopher Wood wrote: > > On Thu, Nov 14, 2019, at 8:43 AM, Daniel Migault wrote: > > > If tickets are sent right after the server Finished, before the the > > > client Finished, these are only triggered by the clientHello - at > least > > > this is my understanding. > > > > Yes, that's correct. I thought your comment was about post-handshake > > tickets (after confirmation from the client). Adding a note about this > > pre-handshake completion is fine with me. > > Scratch that! I forgot we limited this extension to TLS 1.3, which > prohibits sending NSTs until the client finished is received ( > https://tools.ietf.org/html/rfc8446#section-4.6.1). > > Best, > Chris > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000bba638059751619b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
Unless=
 I am missing something, the text below seems to say otherwise. 

Note: Although the resumption master secr=
et depends on the client's
   second flight, a server which does not request client authentication
   MAY compute the remainder of the transcript independently and then
   send a NewSessionTicket immediately upon sending its Finished rather
   than waiting for the client Finished.  This might be appropriate in
   cases where the client is expected to open multiple TLS connections
   in parallel and would benefit from the reduced overhead of a
   resumption handshake, for example.


On Thu, Nov 14, 2019 at= 11:52 AM Christopher Wood <caw@h= eapingbits.net> wrote:
On Thu, Nov 14, 2019, at 8:48 AM, Christopher Wood wrote:
> On Thu, Nov 14, 2019, at 8:43 AM, Daniel Migault wrote:
> > If tickets are sent right after the server Finished, before the t= he
> > client Finished, these are only triggered by the clientHello - at= least
> > this is my understanding.
>
> Yes, that's correct. I thought your comment was about post-handsha= ke
> tickets (after confirmation from the client). Adding a note about this=
> pre-handshake completion is fine with me.

Scratch that! I forgot we limited this extension to TLS 1.3, which prohibit= s sending NSTs until the client finished is received (https://tools.ietf.org/html/rfc8446#section-4.6.1).

Best,
Chris

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000bba638059751619b-- From nobody Thu Nov 14 08:59:10 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EE41208DB for ; Thu, 14 Nov 2019 08:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFAGdYy1vpzP for ; Thu, 14 Nov 2019 08:59:05 -0800 (PST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF97C1208B6 for ; Thu, 14 Nov 2019 08:58:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573750738; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gYwFUE4uGwqnmS6/OP3ltUoDNPwLpWTcNOfzozBrKvo=; b=QNPnM2Ah9LjVBa5y6ccaPeqCNiRbJep4b+1NI/SJQJITq3Keofc2A9Q5ANSk7GasBQSmmv OCy1FLE0MX89GSRWaXez/8JAeHrXhFRMLB6ns1E+ajmWrjcir77CuWNho3koranxVZm/Qx 3bmNqGsgTvpJNSkfpI+PDMhv/nJ0/+E= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-261-vtGRdu3bPi2ApJN8ZBxejA-1; Thu, 14 Nov 2019 11:58:57 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5715F18B9FC1 for ; Thu, 14 Nov 2019 16:58:56 +0000 (UTC) Received: from localhost (unknown [10.43.21.192]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 03A2D6135D for ; Thu, 14 Nov 2019 16:58:55 +0000 (UTC) From: Hubert Kario To: Date: Thu, 14 Nov 2019 17:58:54 +0100 MIME-Version: 1.0 Message-ID: <6fc786f3-9fbe-4f8e-92d3-cd9ceb7f3703@redhat.com> In-Reply-To: References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <37ff9a64-2749-4558-a675-5b251f06eb3a@www.fastmail.com> Organization: Red Hat User-Agent: Trojita/0.7; Qt/5.12.5; xcb; Linux; Fedora release 30 (Thirty) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-MC-Unique: vtGRdu3bPi2ApJN8ZBxejA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 16:59:10 -0000 On Thursday, 14 November 2019 17:19:55 CET, Daniel Migault wrote: > Hi Chris,=20 > > Thanks for the responses, please see my comments inline.=20 > > Yours,=20 > Daniel > > On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood=20 > wrote: > On Thu, Nov 14, 2019, at 7:50 AM, Daniel Migault wrote: >> Hi, >>=20 >> The current version is clearer than the previous one. However, as I >> understand the document, it still seems very asymmetric in the sense >> that it does not provide the client the ability to enforce a number. I >> believe more guidances/specifications are needed on how to interpret the >> count value. Interpretation is usually based on implicit assumptions of >> today's usages, and explicit signaling should, in my opinion,=20 >> be preferred. In >> other words, I believe that long term interop will benefit from these >> additional specifications. > > I disagree with this assessment. The document is clear on this: > > A supporting server MAY use TicketRequestContents.count when > determining how many NewSessionTicket messages to send to a > requesting client, and SHOULD place a limit on the number of tickets > sent. The number of NewSessionTicket messages sent SHOULD be the > minimum of the server's self-imposed limit and > TicketRequestContents.count. > > As has been stated before, the count is a *hint* to the server,=20 > nothing more.=20 > > That is my point, in my opinion a hint is under specified.=20 > =20 >> The problem stated in the introduction is that the server needs some >> information from the client in order to generate the appropriated number >> of tickets. In fact the client is likely to be the one that better knows >> the number of tickets to be generated, but the current text does not >> enable the client to enforce that number. Instead this is entirely left >> to the server. > > As above, I think you're misunderstanding the point of this=20 > document. Ticket requests are hints to servers. > > On the contrary, I think I understood it correctly.=20 we discussed it on the list, and the reason for such phrasing is=20 multi-fold: - the server doesn't have to implement this extension, as such, as per the basic TLS 1.3 RFC, it can send arbitrary number of extensions to client, so clients, to be RFC compliant, need to be able to process abritrary=20 number tickets at arbitrary time after handshake finish - making value in extension the exact number requested by client makes the implementation much more complex: is that number per connection? per session? what about post-handshake authentication? what about Session=20 Ticket Encryption Key rollover? do we really want the client to abort the=20 connection if server misbehaves and sends too many or too few tickets? - while the client may think that it knows how many tickets it requires,= =20 that information may be out of date. If an HTTP server has been brought down,= =20 a connection to a given SNI may lead to a redirection page - in such cases there is no point in server sending tickets. so please, tell: what issue would be solved by making the count requested= =20 by client mandatory? Because I see it only increasing complexity of implementation for no=20 benefit. --=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic From nobody Thu Nov 14 09:02:29 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751DA1208D0 for ; Thu, 14 Nov 2019 09:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=aJkGMihy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iNanT2B5 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 tgroqH6CNzm0 for ; Thu, 14 Nov 2019 09:02:25 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A88412096D for ; Thu, 14 Nov 2019 09:02:24 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id DE50B20355; Thu, 14 Nov 2019 12:02:21 -0500 (EST) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Thu, 14 Nov 2019 12:02:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=Smi2kTT2RDXjYV3H+Q1MaBZNZSrE kMSmR+UzlAhARDQ=; b=aJkGMihyEaEUlp57ly1gDqdn7MJfsXycoU7GhA3CfsOA JNAPFzyC4r1xCo2znL5vU4h/0mEvDVWNzyl9Ew3/HUbLlNbtpEuFYHulRey3u/us 8VrpauvrCdAbGq1WbYKjk1Bb2rDe5BOTOwMx8n0ZuK64nZd60btkd4QPYdL8AL7N 4p5FTPqyczcRJpsuBecOXdhsJ9SSQsYQvV+dQgiQQPwR0m1gC2023QZU9GAwhPeo yjWi5PFARDbBZgW1V/kc7AwzJPdOR7+oWI8UpeCUxFqO6drONJHCe7prbRxAgyHx duzVfuvosbuJ1Q0UwfcwaeQPQAtfCGB4EBzqCCVJHw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Smi2kT T2RDXjYV3H+Q1MaBZNZSrEkMSmR+UzlAhARDQ=; b=iNanT2B5apWT28DrVQ1XKM ner0H9Z3zLAA2eS2KTz3ea76RLs+6VAENb/ORToHqNNYqNLDp24cCcN7LokiviGs VVLw/7bJUZnc0jbbwzK27mU/uayV5RM+9HTz5zJKV/0KGAQ46Pte4KB4qyzCDK57 sTQuOzvJhXXdEvL4roGrjNtm/KTYtzxJbD711+wQo54eBqaepiOGm2PnZS3SnkOx lpuT1RyhVTNEWt3+MuldW1zt3bJ6kycDWM1yEspQWfIWley9dHqdR3PAv8zTKPFv ly93dcEOYwyJoYH4iIDomBt73LOTAqpv9IWomTRzvvVzKr2yzfDraLWJQLvEPO8g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeffedgleehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdevhhhr ihhsthhophhhvghrucghohhougdfuceotggrfieshhgvrghpihhnghgsihhtshdrnhgvth eqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomhep tggrfieshhgvrghpihhnghgsihhtshdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 27DB53C00A2; Thu, 14 Nov 2019 12:02:21 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-562-gfd0633a-fmstable-20191114v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <37ff9a64-2749-4558-a675-5b251f06eb3a@www.fastmail.com> <1cd34aff-915e-4f70-8f03-b644dab201c9@www.fastmail.com> <99300d33-5a29-47e1-88ac-c83d385a9263@www.fastmail.com> <895cd06a-a75a-45f4-986d-c1eaa7d4c83d@www.fastmail.com> Date: Thu, 14 Nov 2019 09:02:00 -0800 From: "Christopher Wood" To: "Daniel Migault" Cc: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 17:02:27 -0000 On Thu, Nov 14, 2019, at 8:57 AM, Daniel Migault wrote: > Unless I am missing something, the text below seems to say otherwise. > Note: Although the resumption master secret depends on the client's > second flight, a server which does not request client authentication > MAY compute the remainder of the transcript independently and then > send a NewSessionTicket immediately upon sending its Finished rather > than waiting for the client Finished. This might be appropriate in > cases where the client is expected to open multiple TLS connections > in parallel and would benefit from the reduced overhead of a > resumption handshake, for example. Oops again. I only read the first sentence and drew the wrong conclusion. At any time after the server has received the client Finished message, it MAY send a NewSessionTicket message. > > > On Thu, Nov 14, 2019 at 11:52 AM Christopher Wood wrote: > > On Thu, Nov 14, 2019, at 8:48 AM, Christopher Wood wrote: > > > On Thu, Nov 14, 2019, at 8:43 AM, Daniel Migault wrote: > > > > If tickets are sent right after the server Finished, before the the > > > > client Finished, these are only triggered by the clientHello - at least > > > > this is my understanding. > > > > > > Yes, that's correct. I thought your comment was about post-handshake > > > tickets (after confirmation from the client). Adding a note about this > > > pre-handshake completion is fine with me. > > > > Scratch that! I forgot we limited this extension to TLS 1.3, which prohibits sending NSTs until the client finished is received (https://tools.ietf.org/html/rfc8446#section-4.6.1). > > > > Best, > > Chris > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Nov 14 09:19:08 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4E112092B for ; Thu, 14 Nov 2019 09:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6PkA9F-oaeK for ; Thu, 14 Nov 2019 09:19:05 -0800 (PST) Received: from mail-vk1-f169.google.com (mail-vk1-f169.google.com [209.85.221.169]) (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 11205120A5B for ; Thu, 14 Nov 2019 09:19:05 -0800 (PST) Received: by mail-vk1-f169.google.com with SMTP id r4so1652806vkf.9 for ; Thu, 14 Nov 2019 09:19:05 -0800 (PST) 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=0oEKGFgBqD2IPNfJtXPCeKJ2iHH61FEm50yLq/DJ6wM=; b=SivWqOQOG0sW11ICegyfBOsCaBF8g6hqjOWyqlzFkm/MQSa4l4190Hrismeerqx6gQ SjlBEfG8J5z9dcs6AR4KC2xMqB1qjdNmcoweoiS4+0e0mKVmwuYbO3g7biUZx3ogSP1Y I/4EQWcAmP1nu5gsIL6HUe6XRpVGd62ceO8/AM9vz/E81LC8ymH1jDaozPTZr46Uf25B B4C4oh3h7KTSauHAdvM1MSSn5PsPp9YCEUkGdbzPc/6uzqru4SH4hCx6IaWiM81O+glQ rEXV0nU5KJ4DgOKv3fKnYXz+lvm46hA65U3T5UNyvonhBSx2/KUz4f4ZBPtA0YhqbD59 JQ+w== X-Gm-Message-State: APjAAAX2Ioosl/qCA2cbgWy804MGXK0Pd7B7tQh3mOP+JnjrDiwIYc/L h54F7oEKVErrU7llHuZyfUL/tiymSzLuOcZwt8w= X-Google-Smtp-Source: APXvYqwv/GeQ97V+/+uXVsv7ZO4f/t3Tk4bRFl51kCL7KGIQfByRl3+cXqReyR9xIp6K/sGQalKsuWTPWhOqxFxRWuY= X-Received: by 2002:a1f:9553:: with SMTP id x80mr6085240vkd.39.1573751943877; Thu, 14 Nov 2019 09:19:03 -0800 (PST) MIME-Version: 1.0 References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <37ff9a64-2749-4558-a675-5b251f06eb3a@www.fastmail.com> <6fc786f3-9fbe-4f8e-92d3-cd9ceb7f3703@redhat.com> In-Reply-To: <6fc786f3-9fbe-4f8e-92d3-cd9ceb7f3703@redhat.com> From: Daniel Migault Date: Thu, 14 Nov 2019 12:18:52 -0500 Message-ID: To: Hubert Kario Cc: tls Content-Type: multipart/alternative; boundary="0000000000009458d5059751ade8" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 17:19:07 -0000 --0000000000009458d5059751ade8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Hubert, The reason I would prefer the client to enforce the count is that if a client has constraints - memory / bandwidth, he wants to make sure its preference is respected, and this independently of the evolution of how the hint will be interpreted in the future or depending on different implementations. I understand the reasons for SHOULD. At least this should be documented. To address your first point, of course the specification applies to the server that support the extension. Your second concern is solved by limiting the NTS of KEX. The third point is addressed by the minimum of the (count, server_nbr). Note that I see count as a maximum. Overall I do not think this would add much complexity. The only complexity I see is when a server sends NTS at different time in the KEX. Yours, Daniel On Thu, Nov 14, 2019 at 11:59 AM Hubert Kario wrote: > On Thursday, 14 November 2019 17:19:55 CET, Daniel Migault wrote: > > Hi Chris, > > > > Thanks for the responses, please see my comments inline. > > > > Yours, > > Daniel > > > > On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood > > wrote: > > On Thu, Nov 14, 2019, at 7:50 AM, Daniel Migault wrote: > >> Hi, > >> > >> The current version is clearer than the previous one. However, as I > >> understand the document, it still seems very asymmetric in the sense > >> that it does not provide the client the ability to enforce a number. I > >> believe more guidances/specifications are needed on how to interpret t= he > >> count value. Interpretation is usually based on implicit assumptions o= f > >> today's usages, and explicit signaling should, in my opinion, > >> be preferred. In > >> other words, I believe that long term interop will benefit from these > >> additional specifications. > > > > I disagree with this assessment. The document is clear on this: > > > > A supporting server MAY use TicketRequestContents.count when > > determining how many NewSessionTicket messages to send to a > > requesting client, and SHOULD place a limit on the number of tickets > > sent. The number of NewSessionTicket messages sent SHOULD be the > > minimum of the server's self-imposed limit and > > TicketRequestContents.count. > > > > As has been stated before, the count is a *hint* to the server, > > nothing more. > > > > That is my point, in my opinion a hint is under specified. > > > >> The problem stated in the introduction is that the server needs some > >> information from the client in order to generate the appropriated numb= er > >> of tickets. In fact the client is likely to be the one that better kno= ws > >> the number of tickets to be generated, but the current text does not > >> enable the client to enforce that number. Instead this is entirely lef= t > >> to the server. > > > > As above, I think you're misunderstanding the point of this > > document. Ticket requests are hints to servers. > > > > On the contrary, I think I understood it correctly. > > we discussed it on the list, and the reason for such phrasing is > multi-fold: > - the server doesn't have to implement this extension, as such, as per t= he > basic TLS 1.3 RFC, it can send arbitrary number of extensions to clien= t, > so clients, to be RFC compliant, need to be able to process abritrary > number > tickets at arbitrary time after handshake finish > - making value in extension the exact number requested by client makes t= he > implementation much more complex: is that number per connection? per > session? what about post-handshake authentication? what about Session > Ticket > Encryption Key rollover? do we really want the client to abort the > connection > if server misbehaves and sends too many or too few tickets? > - while the client may think that it knows how many tickets it requires, > that > information may be out of date. If an HTTP server has been brought > down, > a > connection to a given SNI may lead to a redirection page - in such cas= es > there is no point in server sending tickets. > > so please, tell: what issue would be solved by making the count requested > by > client mandatory? > Because I see it only increasing complexity of implementation for no > benefit. > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000009458d5059751ade8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hubert,=C2=A0

The reason I would=C2=A0pref= er the client to enforce the count is that if a client has constraints - me= mory / bandwidth, he wants to make sure its preference is respected, and th= is independently of the evolution of how the hint will be interpreted in th= e future or depending on different implementations.=C2=A0

I understand the reasons for SHOULD. At least this should be docume= nted. To address your first point, of course the specification applies to t= he server that support the extension. Your second concern is solved by limi= ting the NTS of KEX. The third point is addressed by the minimum of the (co= unt, server_nbr). Note that I see count as a maximum. Overall I do not thin= k this would add much complexity.=C2=A0 The only complexity I see is when a= server sends NTS at different time in the KEX.=C2=A0=C2=A0

<= /div>
Yours,=C2=A0
Daniel

On Thu, Nov 1= 4, 2019 at 11:59 AM Hubert Kario <h= kario@redhat.com> wrote:
On Thursday, 14 November 2019 17:19:55 CET, Daniel Migault = wrote:
> Hi Chris,
>
> Thanks for the responses, please see my comments inline.
>
> Yours,
> Daniel
>
> On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood
> <caw@heapi= ngbits.net> wrote:
> On Thu, Nov 14, 2019, at 7:50 AM, Daniel Migault wrote:
>> Hi,
>>
>> The current version is clearer than the previous one. However, as = I
>> understand the document, it still seems very asymmetric in the sen= se
>> that it does not provide the client the ability to enforce a numbe= r. I
>> believe more guidances/specifications are needed on how to interpr= et the
>> count value. Interpretation is usually based on implicit assumptio= ns of
>> today's usages, and explicit signaling should, in my opinion, =
>> be preferred. In
>> other words, I believe that long term interop will benefit from th= ese
>> additional specifications.
>
> I disagree with this assessment. The document is clear on this:
>
>=C2=A0 =C2=A0 A supporting server MAY use TicketRequestContents.count w= hen
>=C2=A0 =C2=A0 determining how many NewSessionTicket messages to send to= a
>=C2=A0 =C2=A0 requesting client, and SHOULD place a limit on the number= of tickets
>=C2=A0 =C2=A0 sent.=C2=A0 The number of NewSessionTicket messages sent = SHOULD be the
>=C2=A0 =C2=A0 minimum of the server's self-imposed limit and
>=C2=A0 =C2=A0 TicketRequestContents.count.
>
> As has been stated before, the count is a *hint* to the server,
> nothing more.
>
> That is my point, in my opinion a hint is under specified.
>=C2=A0
>> The problem stated in the introduction is that the server needs so= me
>> information from the client in order to generate the appropriated = number
>> of tickets. In fact the client is likely to be the one that better= knows
>> the number of tickets to be generated, but the current text does n= ot
>> enable the client to enforce that number. Instead this is entirely= left
>> to the server.
>
> As above, I think you're misunderstanding the point of this
> document. Ticket requests are hints to servers.
>
> On the contrary, I think I understood it correctly.

we discussed it on the list, and the reason for such phrasing is
multi-fold:
=C2=A0- the server doesn't have to implement this extension, as such, a= s per the
=C2=A0 =C2=A0basic TLS 1.3 RFC, it can send arbitrary number of extensions = to client,
=C2=A0 =C2=A0so clients, to be RFC compliant, need to be able to process ab= ritrary
number
=C2=A0 =C2=A0tickets at arbitrary time after handshake finish
=C2=A0- making value in extension the exact number requested by client make= s the
=C2=A0 =C2=A0implementation much more complex: is that number per connectio= n? per
=C2=A0 =C2=A0session? what about post-handshake authentication? what about = Session
Ticket
=C2=A0 =C2=A0Encryption Key rollover? do we really want the client to abort= the
connection
=C2=A0 =C2=A0if server misbehaves and sends too many or too few tickets? =C2=A0- while the client may think that it knows how many tickets it requir= es,
that
=C2=A0 =C2=A0information may be out of date. If an HTTP server has been bro= ught down,
a
=C2=A0 =C2=A0connection to a given SNI may lead to a redirection page - in = such cases
=C2=A0 =C2=A0there is no point in server sending tickets.

so please, tell: what issue would be solved by making the count requested <= br> by
client mandatory?
Because I see it only increasing complexity of implementation for no
benefit.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic=

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000009458d5059751ade8-- From nobody Thu Nov 14 09:32:54 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948A2120802 for ; Thu, 14 Nov 2019 09:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11FoQwZdAMQa for ; Thu, 14 Nov 2019 09:32:49 -0800 (PST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E725B120074 for ; Thu, 14 Nov 2019 09:32:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573752767; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=u89ANBtVJXxKpAQVHZq0AqZ1qcihcODXk3Apur9Fwzs=; b=DQe7JJbjURqht+4o5DqrubImtIOn2xSLX6hQ0RSYSbtcVRcEBgv+mLLZTlJo6clGnouA/t gqIVOqLdalg/fB5rr+BfygmHWVOlyPz4GzFT5PuvSPH7WlST1MzPOeDfEPf2ulTd1Zv1DF 1fnsoHWzdGtUglss8B2TQRJZJd7dWRw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-368-vZm5-UGoM1-S81rM-2eAgw-1; Thu, 14 Nov 2019 12:32:43 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0441918B6393; Thu, 14 Nov 2019 17:32:43 +0000 (UTC) Received: from localhost (unknown [10.43.21.192]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 355DA60303; Thu, 14 Nov 2019 17:32:41 +0000 (UTC) From: Hubert Kario To: Daniel Migault Cc: tls Date: Thu, 14 Nov 2019 18:32:39 +0100 MIME-Version: 1.0 Message-ID: <07d49b6f-e79d-4058-878f-7a57d5b6f241@redhat.com> In-Reply-To: References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <37ff9a64-2749-4558-a675-5b251f06eb3a@www.fastmail.com> <6fc786f3-9fbe-4f8e-92d3-cd9ceb7f3703@redhat.com> Organization: Red Hat User-Agent: Trojita/0.7; Qt/5.12.5; xcb; Linux; Fedora release 30 (Thirty) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-MC-Unique: vZm5-UGoM1-S81rM-2eAgw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 17:32:52 -0000 On Thursday, 14 November 2019 18:18:52 CET, Daniel Migault wrote: > Hi Hubert, > > The reason I would prefer the client to enforce the count is that if a > client has constraints - memory / bandwidth, he wants to make sure its > preference is respected, and this independently of the evolution of how t= he > hint will be interpreted in the future or depending on different > implementations. bandwidth I sort of understand, but then if client asks for 0 tickets, it's= =20 explicitly stated in the draft that server should understand it as "will=20 not use, don't bother" =E2=80=93 I really don't see how in the future that = can be=20 reinterpreted as "nah, send tickets anyway" =E2=80=93 also, please remember= that=20 the size of the ticket is very variable, so just accepting one ticket may= =20 be a significant size anyway as for memory =E2=80=93 just because server sends them, doesn't mean client= has to=20 remember them finally: ok, so the server misbehaves and sends 4 tickest instead of three,= =20 what the client should do? close the connection? > I understand the reasons for SHOULD. At least this should be documented. = To > address your first point, of course the specification applies to the serv= er > that support the extension.=20 > Your second concern is solved by limiting the > NTS of KEX.=20 by "KEX" you mean handshake? but New Session Ticket messages are not sent= =20 during handshake, they are sent after handshake is finished so how exactly you want to decide when server stopped sending NSTs after=20 handshake finished? > The third point is addressed by the minimum of the (count, > server_nbr). Note that I see count as a maximum. Overall I do not think > this would add much complexity. The only complexity I see is when a serv= er > sends NTS at different time in the KEX. again, and what if the server misbehaves? > Yours, > Daniel > > On Thu, Nov 14, 2019 at 11:59 AM Hubert Kario wrote: > >> On Thursday, 14 November 2019 17:19:55 CET, Daniel Migault wrote: >>> Hi Chris, >>>=20 >>> Thanks for the responses, please see my comments inline. >>>=20 >>> Yours, >>> Daniel >>>=20 >>> On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood ... >>=20 >> we discussed it on the list, and the reason for such phrasing is >> multi-fold: >> - the server doesn't have to implement this extension, as=20 >> such, as per the >> basic TLS 1.3 RFC, it can send arbitrary number of=20 >> extensions to client, >> so clients, to be RFC compliant, need to be able to process abritrary >> number >> tickets at arbitrary time after handshake finish >> - making value in extension the exact number requested by=20 >> client makes the >> implementation much more complex: is that number per connection? per >> session? what about post-handshake authentication? what about Session >> Ticket >> Encryption Key rollover? do we really want the client to abort the >> connection >> if server misbehaves and sends too many or too few tickets? >> - while the client may think that it knows how many tickets it requires= , >> that >> information may be out of date. If an HTTP server has been brought >> down, >> a >> connection to a given SNI may lead to a redirection page -=20 >> in such cases >> there is no point in server sending tickets. >>=20 >> so please, tell: what issue would be solved by making the count requeste= d >> by >> client mandatory? >> Because I see it only increasing complexity of implementation for no >> benefit. >> -- >> Regards, >> Hubert Kario >> Senior Quality Engineer, QE BaseOS Security team >> Web: www.cz.redhat.com >> Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 > > --=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic From nobody Thu Nov 14 12:53:37 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1AE8120921; Thu, 14 Nov 2019 12:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 n2Ku1x2TKUpp; Thu, 14 Nov 2019 12:53:19 -0800 (PST) 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 A139512080D; Thu, 14 Nov 2019 12:53:18 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAEKqNgc001269; Thu, 14 Nov 2019 20:53:16 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=sYaksfaMYU157lOqmn1/OqrbV7ojboMnqG2SK19gF28=; b=Ca0Azfm3jBEUhGxOW67O6o9XsA8k4D4DEkzxRRxaULEzGgdXrRkmVGnyLLo09GePVTrP UlGSkptT/NFRGpQhluYJx0bLaN2rMaSiJt3QH19t+7W/j6O8Ghk8q8NZbnNYj0Tiq63z g2K/iDdeuuIgLVlyAxAewtNkQmbin0yaG/Fu+3amM8pmn9OofvUWZsnp8v1dVHmRzWc+ DOiBE3AqU5p8SHzvT7prv9cfI2vkl4E9dNEpDYQusLSzY9EpegLRjMMCeWusf+EcSiZQ VEQaz1vr495cN8ILjOjoxFq+CDSmqAmurNGqeOmCQkgG6AobAgMN/Qe6QJVQxfBU6uha SA== 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 2w5p6ead1t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Nov 2019 20:53:16 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAEKlPAP017956; Thu, 14 Nov 2019 15:53:15 -0500 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint1.akamai.com with ESMTP id 2w5sp0n73m-1; Thu, 14 Nov 2019 15:53:13 -0500 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id BB0D91FC6A; Thu, 14 Nov 2019 20:53:13 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1iVM76-00058P-CI; Thu, 14 Nov 2019 12:53:12 -0800 Date: Thu, 14 Nov 2019 12:53:11 -0800 From: Benjamin Kaduk To: Kathleen Moriarty Cc: Benjamin Kaduk , draft-ietf-tls-oldversions-deprecate.all@ietf.org, "" Message-ID: <20191114205311.GP20609@akamai.com> References: <20191111195325.GE32847@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-14_05:, , 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911140172 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-14_05:2019-11-14,2019-11-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 adultscore=0 lowpriorityscore=0 bulkscore=0 malwarescore=0 priorityscore=1501 impostorscore=0 phishscore=0 mlxscore=0 mlxlogscore=999 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911140172 Archived-At: Subject: Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 20:53:24 -0000 On Wed, Nov 13, 2019 at 06:29:44AM -0500, Kathleen Moriarty wrote: > Hi Ben, > > Just replying to the parts of the tread that were not responded to already > as Stephen will likely be looking at the headers/updates per his message. > Thanks for your careful review. > > On Mon, Nov 11, 2019 at 2:54 PM Benjamin Kaduk wrote: > > > Hi all, > > > > This is a "preliminary" review only because there's some strangeness > > relating to the Updates: (and Obsoletes:) headers, and any changes there > > would make me need to go and recheck the relationship of this document to > > the ones listed. So, I haven't done any of that yet, in an attempt to only > > have to do it once. > > > > Specifically, there's skew between the list of documents updated in the top > > header and the list in Section 1.1. Evern more annoyingly, the (tools) > > HTML version seems to be missing some numbers from the document header, > > that are present in the TXT version. (Henrik is going to take a look, per > > > > https://mailarchive.ietf.org/arch/msg/tools-discuss/Maeh0f_WfOy5sfnGQpwGPs_sYcU > > .) > > > > Thanks. > > > > > Additionally, Section 1.1 lists some RFCs that "have been obsoleted", but > > there is no "Obsoletes:" header at the top of the document. > > > > I think nits is right about references (square-bracketed "[RFC6347]") in > > the Abstract; we should change those to normal textual (parenthesed > > "(RFC 6347)") before IETF LC. > > > > Some other notes from a quick pass over the main text (though I'll probably > > read it again once the above are addressed) follow. > > > > Section 1 > > > > It feels a little backwards for a "primary technical reason" to > > deprecate a protocol version being that "at least one widely-used > > library has plans to drop [it]". > > > > I see what you are saying. The major library dropping it has to do with > the number of versions available and supporting them all is cumbersome and > could lead to configuration errors on the part of the user. Would you just > like "primary" removed or would you prefer more of a change to the text? The main reason I raised it is that it doesn't feel like a *technical* reason; it's done for expediency and perhaps with a bit of politics, but there's nothing technical about the protocol involved. > > > > > I do appreciate that we give discussion about what we intend > > "deprecation" to mean and for whom -- thank you for that! > > > > Section 2 > > > > TLS 1.3, specified in TLSv1.3 [RFC8446], represents a significant > > change to TLS that aims to address threats that have arisen over > > the years. Among the changes are a new handshake protocol, a new > > key derivation process that uses the HMAC-based Extract-and-Expand > > Key Derivation Function (HKDF), and the removal of cipher suites > > that use static RSA or DH key exchanges, the CBC mode of > > operation, or SHA-1. The list of extensions that can be used with > > TLS 1.3 has been reduced considerably. > > > > While it's true that the initial list of extensions usable with TLS 1.3 > > is smaller than the list of extensions usable at TLS 1.2 taken at the > > same time, it's also true that the requirements for allocating a new > > extension codepoint have been reduced dramatically. So I think I'd say > > that this reflects not a desire to reduce the attack surface (as > > "measured" by number of extensions) but rather a paradigm shift in how > > the protocol works, which leaves some existing functionality > > incompatible with the new model. I don't really get a clear sense of > > what this current last sentence is trying to say (i.e., whether it's one > > of those two descriptions I offered above). > > > > Would you prefer "a significant change", be "a paradigm shift"? If not, > could you propose text? I'm trying to say that the reduced size of the list of extensions is just a side effect, not an end in its own right. But, I seem to have missed that this paragraph is part of a quotation from a NIST document, so I don't get to wordsmith it :) > > > > Section 3 > > > > Similarly, the authentication of the handshake depends on signatures > > made using SHA-1 hash or a not stronger concatenation of MD-5 and > > SHA-1 hashes, allowing the attacker to impersonate a server when it > > is able to break the severely weakened SHA-1 hash. > > > > My recollection of the WG discussions (which I will go review) is that > > we don't really have consensus on the "not stronger" portion of this. > > Is that a key component of the document here? (N.B. this is *not* an > > invitation to rehash that discussion again! The chairs or I can provide > > a summary of points not resolved by previous discussion and points > > believed to be adequately agreed upon, which would be a trigger for any > > additional discussion that might be needed.) > > > > Since you are already looking at the consensus of this with the chairs, we > can wait for your guidance. Okay. That might not happen until after Singapore, though. -Ben From nobody Thu Nov 14 14:43:24 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D693312006E for ; Thu, 14 Nov 2019 14:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8dvZzSW-LEC for ; Thu, 14 Nov 2019 14:43:20 -0800 (PST) Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) (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 19720120058 for ; Thu, 14 Nov 2019 14:43:19 -0800 (PST) Received: by mail-qk1-f177.google.com with SMTP id q70so6518346qke.12 for ; Thu, 14 Nov 2019 14:43:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ITja7Y7d7xJAzpVyjjC6y47EhbLJI8uJcr/etILSglU=; b=h0ywcKPqSF9fSxScIQAd/BpelVZCW39brka1uriSywzmrklVGieV5aOOYW/Ijy06lI kheH5jj7NrMCObzmSNNC7QZaW1AeVopo3WIPfptamwY1WMAmGyYNUtU4YFUbh//Ao5Zx Pf8vAiQwqQ5W8LASlpxXiI459k+6SuFhSWd9a6/VnQJIFZzNDczBQHf53VT/O+Ey/y++ uVFsTZ41H/mw4ZjZRIS82Ic7j+9mIbOTZKuJw10KJzqb4D4I9AALnId/brS//9hEXQDc wG9uYgpoBIcFPBRa6VCToQI2RwsCXoY5aSJgsxBLNsbKMd7gphqXs4o/2OkbgwzcoDHI y+nA== X-Gm-Message-State: APjAAAUGUu3Xnqg75jRP0G3cSGDPsSMj9ccS7XNTNJGMHniPPYLgS3Xx pclgngwiC2zHFlq2R8+uHNN65Qw3MsMV+wkWXS7Cfg== X-Google-Smtp-Source: APXvYqzVufF2Mho8m4lGmF8LkcEt1a416cmX3vf1h/iZwN1Vz/wrW9GQskqunrVb6/UTpaO2AnxKKbmnBwDm0NcRN9E= X-Received: by 2002:a37:491:: with SMTP id 139mr2702886qke.200.1573771398663; Thu, 14 Nov 2019 14:43:18 -0800 (PST) MIME-Version: 1.0 References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> In-Reply-To: From: Adam Langley Date: Thu, 14 Nov 2019 14:43:07 -0800 Message-ID: To: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002cd47b0597563591" Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2019 22:43:22 -0000 --0000000000002cd47b0597563591 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 11, 2019 at 11:33 AM Christopher Wood wrote: > The adoption call is now (belatedly) finished. At this time, there's not > enough interest to take this on as a WG item. We encourage further > discussion on the list, perhaps based on subsequent draft updates, and will > revisit adoption in the future if interest grows. > People on this list who manage large corporate networks may wish to pay attention to this: while you may not have updated servers to TLS 1.3 yet, eventually it'll happen and I suspect some will find a significant amount of things like TPMs, in which you currently have client-certificate keys, which only sign with PKCS#1 v1.5. Without this draft adopted and implemented ahead of time, it's going to be painful. Cheers AGL --0000000000002cd47b0597563591 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 11, 2019 at 11:33 AM Christop= her Wood <caw@heapingbits.net= > wrote:
The adoption call is now (belatedly) finished. At th= is time, there's not enough interest to take this on as a WG item. We e= ncourage further discussion on the list, perhaps based on subsequent draft = updates, and will revisit adoption in the future if interest grows.

People on this list who manage large corporate= networks may wish to pay attention to this: while you may not have updated= servers to TLS 1.3 yet, eventually it'll happen and I suspect some wil= l find a significant amount of things like TPMs, in which you currently hav= e client-certificate keys, which only sign with PKCS#1 v1.5. Without this d= raft adopted and implemented ahead of time, it's going to be painful.


Cheers

AGL<= /div>
--0000000000002cd47b0597563591-- From nobody Fri Nov 15 04:00:31 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4461E120822 for ; Fri, 15 Nov 2019 04:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfQvojSRmgxB for ; Fri, 15 Nov 2019 04:00:27 -0800 (PST) Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3109B120820 for ; Fri, 15 Nov 2019 04:00:27 -0800 (PST) Received: by mail-vs1-f48.google.com with SMTP id m9so6161335vsq.7 for ; Fri, 15 Nov 2019 04:00:27 -0800 (PST) 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=8ib3eXo2YL/TXnuQVKARJCVA0W+IzKTq73RbpdKiXUE=; b=LDhsLCLb64t9bXXr1l36TfP+OFHOTDLwFHNvZPuQH9RXBdj1r3Uh/vGRgWhURQYW0P GZrXtK4mUsXmZ2oiasx+t9uhD1MOWUi5PAejx2KWGf01HkrpYtC9nM/fSS1hpWZAKVZH gjgK43P5ZT/YHexYGkRH0sgGzBqXWfyochKUiLZYTtWSdoDzKzP8/dpNrPJo+Uu5FNDJ Czu+ADhv3spGrpZr+auvg/N2TcsxO+zKKCpLs9HYXdJ+EdDDktU/62yH17Dbe66A/L51 JaFd3Dyhaj3N73zMN7yKCDidDjLOB7hse5FTMFDVG1BUSa17l4cAZRbKCZ1QCRK21lpD e7Gg== X-Gm-Message-State: APjAAAX2RZA555X13FW46ky0KJsgZAik3SBLFbWlAY45rjSQzpOieP4o CUk4oO2Bc1TPIqmPmqsRAgrSRvPPyOllDQVQ/qXSl7IH X-Google-Smtp-Source: APXvYqydpR4w0KlzK7Bo5VWeKEzrDGeOkIzU73tfLdoSzwl+K9Vr4yOXD05AD+yOfEk3tBMEN0V60WlTe3O+eQDW3LU= X-Received: by 2002:a67:e2d7:: with SMTP id i23mr8548835vsm.31.1573819226186; Fri, 15 Nov 2019 04:00:26 -0800 (PST) MIME-Version: 1.0 References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <37ff9a64-2749-4558-a675-5b251f06eb3a@www.fastmail.com> <6fc786f3-9fbe-4f8e-92d3-cd9ceb7f3703@redhat.com> <07d49b6f-e79d-4058-878f-7a57d5b6f241@redhat.com> In-Reply-To: <07d49b6f-e79d-4058-878f-7a57d5b6f241@redhat.com> From: Daniel Migault Date: Fri, 15 Nov 2019 07:00:14 -0500 Message-ID: To: Hubert Kario Cc: tls Content-Type: multipart/alternative; boundary="000000000000eaec2505976157d2" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2019 12:00:29 -0000 --000000000000eaec2505976157d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Hubert, On Thu, Nov 14, 2019 at 12:33 PM Hubert Kario wrote: > On Thursday, 14 November 2019 18:18:52 CET, Daniel Migault wrote: > > Hi Hubert, > > > > The reason I would prefer the client to enforce the count is that if a > > client has constraints - memory / bandwidth, he wants to make sure its > > preference is respected, and this independently of the evolution of how > the > > hint will be interpreted in the future or depending on different > > implementations. > > bandwidth I sort of understand, but then if client asks for 0 tickets, > it's > explicitly stated in the draft that server should understand it as "will > not use, don't bother" =E2=80=93 I really don't see how in the future tha= t can be > reinterpreted as "nah, send tickets anyway" =E2=80=93 also, please rememb= er that > the size of the ticket is very variable, so just accepting one ticket may > be a significant size anyway > I agree the case of count set to 0 is mention. However, the support of the extension does not prevent a server to send 4 tickets with MAY and SHOULD. The reason this might be ignored in the future is that the specification does not prevent the server from doing so and takes what the client provides as an hint which may be overwrite by the server. 0 seems also special, but I believe we can have a common behaviour for any sort of values. > as for memory =E2=80=93 just because server sends them, doesn't mean clie= nt has to > remember them > It still has to process them, which consumes battery. > > finally: ok, so the server misbehaves and sends 4 tickest instead of > three, > what the client should do? close the connection? > > Well, the client will probably discard one. That said with the current specification we cannot report a bug and ask the server to comply with the spec, it is in the spec. On the other hand, if the spec ask for considering that count, we can ask the server to be compliant with the spec. All cases you are raising will need to be implemented and as such will be defined in some ways. In my opinion that should be in the specification. > > I understand the reasons for SHOULD. At least this should be documented= . > To > > address your first point, of course the specification applies to the > server > > that support the extension. > > > Your second concern is solved by limiting the > > NTS of KEX. > > by "KEX" you mean handshake? but New Session Ticket messages are not sent > during handshake, they are sent after handshake is finished > > yes. I would consider the NST as part of the handshake even for those sen= t after the post-handshake authentication. I agree better terms may be used. The rekey aspect seems to me out of the handshake. > so how exactly you want to decide when server stopped sending NSTs after > handshake finished? > That the spec does not mention it does not mean this will not be defined. Instead it means each implementer will have its own logic, definitions and outputs. The same reasoning occurs to the complexity argument,not specifying it does not reduce the complexity but let it to the implementation with all unexpected corner cases. > > > The third point is addressed by the minimum of the (count, > > server_nbr). Note that I see count as a maximum. Overall I do not think > > this would add much complexity. The only complexity I see is when a > server > > sends NTS at different time in the KEX. > > again, and what if the server misbehaves? > Again, it would be a bug but the current spec is very permissive, at least in my opinion. I do not believe that not specifying the expected behaviors will prevent misbehaviors to happen, it, instead simply legitimates them. > > > Yours, > > Daniel > > > > On Thu, Nov 14, 2019 at 11:59 AM Hubert Kario wrote= : > > > >> On Thursday, 14 November 2019 17:19:55 CET, Daniel Migault wrote: > >>> Hi Chris, > >>> > >>> Thanks for the responses, please see my comments inline. > >>> > >>> Yours, > >>> Daniel > >>> > >>> On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood ... > >> > >> we discussed it on the list, and the reason for such phrasing is > >> multi-fold: > >> - the server doesn't have to implement this extension, as > >> such, as per the > >> basic TLS 1.3 RFC, it can send arbitrary number of > >> extensions to client, > >> so clients, to be RFC compliant, need to be able to process abritra= ry > >> number > >> tickets at arbitrary time after handshake finish > >> - making value in extension the exact number requested by > >> client makes the > >> implementation much more complex: is that number per connection? pe= r > >> session? what about post-handshake authentication? what about Sessi= on > >> Ticket > >> Encryption Key rollover? do we really want the client to abort the > >> connection > >> if server misbehaves and sends too many or too few tickets? > >> - while the client may think that it knows how many tickets it > requires, > >> that > >> information may be out of date. If an HTTP server has been brought > >> down, > >> a > >> connection to a given SNI may lead to a redirection page - > >> in such cases > >> there is no point in server sending tickets. > >> > >> so please, tell: what issue would be solved by making the count > requested > >> by > >> client mandatory? > >> Because I see it only increasing complexity of implementation for no > >> benefit. > >> -- > >> Regards, > >> Hubert Kario > >> Senior Quality Engineer, QE BaseOS Security team > >> Web: www.cz.redhat.com > >> Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > >> > > > > > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000eaec2505976157d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0 Hubert,=C2=A0

On Thu, Nov 14, 2019= at 12:33 PM Hubert Kario <hkario@r= edhat.com> wrote:
On Thursday, 14 November 2019 18:18:52 CET, Daniel Migault wrote= :
> Hi Hubert,
>
> The reason I would prefer the client to enforce the count is that if a=
> client has constraints - memory / bandwidth, he wants to make sure its=
> preference is respected, and this independently of the evolution of ho= w the
> hint will be interpreted in the future or depending on different
> implementations.

bandwidth I sort of understand, but then if client asks for 0 tickets, it&#= 39;s
explicitly stated in the draft that server should understand it as "wi= ll
not use, don't bother" =E2=80=93 I really don't see how in the= future that can be
reinterpreted as "nah, send tickets anyway" =E2=80=93 also, pleas= e remember that
the size of the ticket is very variable, so just accepting one ticket may <= br> be a significant size anyway

I agree th= e case of count set to 0 is mention. However, the support of the extension = does not prevent a server to send 4 tickets with MAY and SHOULD. The reason= this might be ignored in the future is that the specification does not pre= vent the server from doing so and takes what the client provides as an hint= which may be overwrite by the server. 0 seems also special, but I believe = we can have a common behaviour for any sort of values.=C2=A0

=

as for memory =E2=80=93 just because server sends them, doesn't mean cl= ient has to
remember them
It still has to process them, which cons= umes battery.=C2=A0

finally: ok, so the server misbehaves and sends 4 tickest instead of three,=
what the client should do? close the connection?

Well, the client will probably discard one. That said= with the current specification we cannot report a bug and ask the server t= o comply with the spec, it is in the spec. On the other hand, if the spec a= sk for considering that count, we can ask the server to be compliant with t= he spec. All cases you are raising will need to be implemented and as such = will be defined in some ways. In my opinion that should be in the specifica= tion.=C2=A0
=C2=A0
> I understand the reasons for SHOULD. At least this should be documente= d. To
> address your first point, of course the specification applies to the s= erver
> that support the extension.

> Your second concern is solved by limiting the
> NTS of KEX.

by "KEX" you mean handshake? but New Session Ticket messages are = not sent
during handshake, they are sent after handshake is finished

yes. I would consider the NST as part of the handshak= e even for those sent after the post-handshake authentication. I agree bett= er terms may be used. The rekey aspect seems to me out of the handshake.=C2= =A0=C2=A0
=C2=A0
so how exactly you want to decide when server stopped sending NSTs after handshake finished?

That the spec does = not mention it does not mean this will not be defined. Instead it means eac= h implementer will have its own logic, definitions and outputs. The same re= asoning occurs to the complexity argument,not specifying it does not reduce= the complexity but let it to the implementation with all unexpected corner= cases.=C2=A0=C2=A0

> The third point is addressed by the minimum of the (count,
> server_nbr). Note that I see count as a maximum. Overall I do not thin= k
> this would add much complexity.=C2=A0 The only complexity I see is whe= n a server
> sends NTS at different time in the KEX.

again, and what if the server misbehaves?

Again, it would be a bug but the current spec is very permissive, at lea= st in my opinion. I do not believe that not specifying the expected behavio= rs will prevent misbehaviors to happen, it, instead simply legitimates them= .=C2=A0

> Yours,
> Daniel
>
> On Thu, Nov 14, 2019 at 11:59 AM Hubert Kario <hkario@redhat.com> wrote:
>
>> On Thursday, 14 November 2019 17:19:55 CET, Daniel Migault wrote:<= br> >>> Hi Chris,
>>>
>>> Thanks for the responses, please see my comments inline.
>>>
>>> Yours,
>>> Daniel
>>>
>>> On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood ...
>>
>> we discussed it on the list, and the reason for such phrasing is >> multi-fold:
>>=C2=A0 - the server doesn't have to implement this extension, a= s
>> such, as per the
>>=C2=A0 =C2=A0 basic TLS 1.3 RFC, it can send arbitrary number of >> extensions to client,
>>=C2=A0 =C2=A0 so clients, to be RFC compliant, need to be able to p= rocess abritrary
>> number
>>=C2=A0 =C2=A0 tickets at arbitrary time after handshake finish
>>=C2=A0 - making value in extension the exact number requested by >> client makes the
>>=C2=A0 =C2=A0 implementation much more complex: is that number per = connection? per
>>=C2=A0 =C2=A0 session? what about post-handshake authentication? wh= at about Session
>> Ticket
>>=C2=A0 =C2=A0 Encryption Key rollover? do we really want the client= to abort the
>> connection
>>=C2=A0 =C2=A0 if server misbehaves and sends too many or too few ti= ckets?
>>=C2=A0 - while the client may think that it knows how many tickets = it requires,
>> that
>>=C2=A0 =C2=A0 information may be out of date. If an HTTP server has= been brought
>> down,
>> a
>>=C2=A0 =C2=A0 connection to a given SNI may lead to a redirection p= age -
>> in such cases
>>=C2=A0 =C2=A0 there is no point in server sending tickets.
>>
>> so please, tell: what issue would be solved by making the count re= quested
>> by
>> client mandatory?
>> Because I see it only increasing complexity of implementation for = no
>> benefit.
>> --
>> Regards,
>> Hubert Kario
>> Senior Quality Engineer, QE BaseOS Security team
>> Web: www.cz.redhat.com
>> Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech= Republic
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org=
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic=

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000eaec2505976157d2-- From nobody Fri Nov 15 05:43:30 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD6112086C for ; Fri, 15 Nov 2019 05:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySnbl20O3U4j for ; Fri, 15 Nov 2019 05:43:26 -0800 (PST) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3851812086E for ; Fri, 15 Nov 2019 05:43:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573825404; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aSa3CudAgbCS7b/1B2QEEXuT94PwbHWmJj80i4CJmzU=; b=SXPJKyfLnx1WFFhWiB4PR3yJgAqQ/uM/KS/SQSRY+qdXzIVrc/3dncSMIBATr1cXa3VH6L 3s9Fpq9lgCJyzbXkliEeHSzpEC6xR+YChIzMnNP+0LY33ezj3EBwDMekkNhZyhzhTAV8+9 rt+TRl8f/OgmhJ6XQIEqkQZiSOAefF4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-431-MqFMVz9mNHeMpGtpMWfVaA-1; Fri, 15 Nov 2019 08:43:21 -0500 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6021C1852E22; Fri, 15 Nov 2019 13:43:20 +0000 (UTC) Received: from localhost (ovpn-200-40.brq.redhat.com [10.40.200.40]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9FBA69302; Fri, 15 Nov 2019 13:43:17 +0000 (UTC) From: Hubert Kario To: Daniel Migault Cc: tls Date: Fri, 15 Nov 2019 14:43:15 +0100 MIME-Version: 1.0 Message-ID: <825db7ba-7b2c-4a4e-ab93-c7792b446463@redhat.com> In-Reply-To: References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <37ff9a64-2749-4558-a675-5b251f06eb3a@www.fastmail.com> <6fc786f3-9fbe-4f8e-92d3-cd9ceb7f3703@redhat.com> <07d49b6f-e79d-4058-878f-7a57d5b6f241@redhat.com> Organization: Red Hat User-Agent: Trojita/0.7; Qt/5.12.5; xcb; Linux; Fedora release 30 (Thirty) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-MC-Unique: MqFMVz9mNHeMpGtpMWfVaA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2019 13:43:30 -0000 On Friday, 15 November 2019 13:00:14 CET, Daniel Migault wrote: > Hi Hubert, > > On Thu, Nov 14, 2019 at 12:33 PM Hubert Kario wrote: > >> On Thursday, 14 November 2019 18:18:52 CET, Daniel Migault wrote: >>> Hi Hubert, >>> I understand the reasons for SHOULD. At least this should be documented= . >>> To >>> address your first point, of course the specification applies to the >>> server >>> that support the extension. >>=20 >>> Your second concern is solved by limiting the >>> NTS of KEX. >>=20 >> by "KEX" you mean handshake? but New Session Ticket messages are not sen= t >> during handshake, they are sent after handshake is finished > > yes. I would consider the NST as part of the handshake even for those sen= t > after the post-handshake authentication. that would make tickets useless for sessions that use PHA > I agree better terms may be used. > The rekey aspect seems to me out of the handshake. rekey also don't impact the keys used for derivation of session ticket secrets... >> so how exactly you want to decide when server stopped sending NSTs after >> handshake finished? >>=20 > > That the spec does not mention it does not mean this will not be defined. > Instead it means each implementer will have its own logic, definitions an= d > outputs. The same reasoning occurs to the complexity argument,not > specifying it does not reduce the complexity but let it to the > implementation with all unexpected corner cases. my point is that there is no good way to define it, if you want the count= =20 to be limited, you need provide a good way to do that I say that there isn't one, so defining it is futile >>> The third point is addressed by the minimum of the (count, >>> server_nbr). Note that I see count as a maximum. Overall I do not think >>> this would add much complexity. The only complexity I see is when a >> server >>> sends NTS at different time in the KEX. >>=20 >> again, and what if the server misbehaves? >>=20 > > Again, it would be a bug but the current spec is very permissive, at leas= t > in my opinion. I do not believe that not specifying the expected behavior= s > will prevent misbehaviors to happen, it, instead simply legitimates them. a MUST requires strict definition, which we can't provide, a SHOULD is=20 already in the draft --=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic From nobody Fri Nov 15 22:01:59 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0208A1200B2 for ; Fri, 15 Nov 2019 22:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HO18ZdgV0K25 for ; Fri, 15 Nov 2019 22:01:56 -0800 (PST) Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) (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 B7D151200CC for ; Fri, 15 Nov 2019 22:01:55 -0800 (PST) Received: by mail-vs1-f54.google.com with SMTP id u18so7071134vsg.5 for ; Fri, 15 Nov 2019 22:01:55 -0800 (PST) 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=vj/MQkjSFExQZYImLhHilmbj2s8LZIZIsvPOTkWS/Yc=; b=frD2NhvuokLq7SWfQfzh0EMdYJlSS/iGAhYuKxALYgxuXM/IGXZjmkPnubNFVmkwLz +7Sj7FA3TCc04ySdgdtLzO9I6ycTbb5sDX37Qhj2eBw4/3BJ24HzvjxOjZiV67Wlq4UH kJTKzrY/dxi/FAnbAjEVv4Nz65c3ilp+8omBGySQ3FADyln2KRYhgHj6IdpN59478geh eyOVInGNKJQFESXFA73RA3USVGPfsj7jXy8Atf+/VtmChqGY3IpeaoG4+ZLpncpM9zCv LVFd+OdYSnccUY89l3/W5WdmQEY8ZDIVcu13UQ5XFppn621iCZ48ZCvxCAMFOE2yzQ75 dxgA== X-Gm-Message-State: APjAAAXy2hMFkADNmauOHG94Tp2aWyHPKEUYHhMGmko8TTtP1MnlITi6 nN6tbkXz3WmXRc+yvmwYR9DlhEcG3bj5GF5NKQo= X-Google-Smtp-Source: APXvYqyNibenIHMommSBywuEqLBAdBKABUo2dbkC0GV8t1YPE3/agL0xP7LDC5k1NqCCpzzY1BWJ190IPI+zRpiD9fg= X-Received: by 2002:a05:6102:810:: with SMTP id g16mr11304235vsb.69.1573884114769; Fri, 15 Nov 2019 22:01:54 -0800 (PST) MIME-Version: 1.0 References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <37ff9a64-2749-4558-a675-5b251f06eb3a@www.fastmail.com> <6fc786f3-9fbe-4f8e-92d3-cd9ceb7f3703@redhat.com> <07d49b6f-e79d-4058-878f-7a57d5b6f241@redhat.com> <825db7ba-7b2c-4a4e-ab93-c7792b446463@redhat.com> In-Reply-To: <825db7ba-7b2c-4a4e-ab93-c7792b446463@redhat.com> From: Daniel Migault Date: Sat, 16 Nov 2019 01:01:43 -0500 Message-ID: To: Hubert Kario Cc: tls Content-Type: multipart/alternative; boundary="000000000000941e9505977073ea" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2019 06:01:58 -0000 --000000000000941e9505977073ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Hubert, I do not understand why tickets sent after PHA would be useless. It is also unclear if not one solution means there are multiple good solutions - in which case we could pick one - or that there is not one. At least I would envisioned something around the lines below. For a given handshake as presented below, here are the NST with associated number (n_0, ..., n_3) without any count value provided by the client. When the client provides count I would expect these number to become (n'_0, ..., n'_3) with n'_u =3D min(max(count- sum(n'_j, j ServerHello {Finished} <-------- [Application Data*] <-------- NST (n_3) {Certificate*} {Finished} --------> <-------- NST (n_2) [Application Data] <-------> [Application Data] <--------- NST (n_1) <-------- CertificateRequest PHA response ---------> <--------- NST (n_0) Yours, Daniel On Fri, Nov 15, 2019 at 8:44 AM Hubert Kario wrote: > On Friday, 15 November 2019 13:00:14 CET, Daniel Migault wrote: > > Hi Hubert, > > > > On Thu, Nov 14, 2019 at 12:33 PM Hubert Kario wrote= : > > > >> On Thursday, 14 November 2019 18:18:52 CET, Daniel Migault wrote: > >>> Hi Hubert, > > >>> I understand the reasons for SHOULD. At least this should be > documented. > >>> To > >>> address your first point, of course the specification applies to the > >>> server > >>> that support the extension. > >> > >>> Your second concern is solved by limiting the > >>> NTS of KEX. > >> > >> by "KEX" you mean handshake? but New Session Ticket messages are not > sent > >> during handshake, they are sent after handshake is finished > > > > yes. I would consider the NST as part of the handshake even for those > sent > > after the post-handshake authentication. > > that would make tickets useless for sessions that use PHA > I agree better terms may be used. > > The rekey aspect seems to me out of the handshake. > > rekey also don't impact the keys used for derivation of session ticket > secrets... > > >> so how exactly you want to decide when server stopped sending NSTs aft= er > >> handshake finished? > >> > > > > That the spec does not mention it does not mean this will not be define= d. > > Instead it means each implementer will have its own logic, definitions > and > > outputs. The same reasoning occurs to the complexity argument,not > > specifying it does not reduce the complexity but let it to the > > implementation with all unexpected corner cases. > > my point is that there is no good way to define it, if you want the count > to be > limited, you need provide a good way to do that > > I say that there isn't one, so defining it is futile > > >>> The third point is addressed by the minimum of the (count, > >>> server_nbr). Note that I see count as a maximum. Overall I do not thi= nk > >>> this would add much complexity. The only complexity I see is when a > >> server > >>> sends NTS at different time in the KEX. > >> > >> again, and what if the server misbehaves? > >> > > > > Again, it would be a bug but the current spec is very permissive, at > least > > in my opinion. I do not believe that not specifying the expected > behaviors > > will prevent misbehaviors to happen, it, instead simply legitimates the= m. > > a MUST requires strict definition, which we can't provide, a SHOULD is > already > in the draft > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000941e9505977073ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hubert,=C2=A0

I do not understand why tickets sent after PHA would be useless. It i= s also unclear if not one solution means there are multiple good solutions = - in which case we could pick one - or that there is not one.=C2=A0 At leas= t I would envisioned=C2=A0something around=C2=A0the lines below.
=
For a given handshake as presented below, here are the NST w= ith associated number (n_0, ..., n_3) without any count value provided by t= he client. When the client provides count I would expect these number to be= come (n'_0, ..., n'_3) with n'_u =3D min(max(count- sum(n'_= j, j<u), 0), n_u). Basically, you send n_0, n_3 until counter is reached= . Other NST are ignored. This seems to ensure that only count NST are sent = while not being overly complex.=C2=A0 I believe that have a deterministic b= ehavior from the server is beneficial.=C2=A0 =C2=A0=C2=A0

Of course this is a first draft, and this may be refined.=C2=A0


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Client=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Server

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ClientHello
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= + key_share=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--------= >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 S= erverHello
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 {Finished}
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <--------=C2=A0 =C2=A0 =C2=A0[App= lication Data*]
=C2=A0 =C2=A0 <-------- =C2=A0 NST (n_3)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {Certificate*}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {Finished}=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -------->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 <--------=C2=A0 =C2=A0 =C2=A0NST (n_2)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Application Data]=C2=A0 = =C2=A0 =C2=A0 =C2=A0 <------->=C2=A0 =C2=A0 =C2=A0[Application Data]<= /font>
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 <---------=C2=A0 =C2=A0 NST (n_1)=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=A0CertificateRequest
<= span style=3D"white-space:pre"> =C2=A0 PHA response=C2=A0 =C2=A0 = =C2=A0 --------->
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <---------=C2=A0 =C2=A0 NST (n= _0) =C2=A0=C2=A0
Y= ours,=C2=A0
Daniel


On Fri, Nov 15, 2019 at 8:44 AM Hubert Kario <hkario@redhat.com> wrote:
<= /div>
On Friday, 15 Novemb= er 2019 13:00:14 CET, Daniel Migault wrote:
> Hi=C2=A0 Hubert,
>
> On Thu, Nov 14, 2019 at 12:33 PM Hubert Kario <hkario@redhat.com> wrote:
>
>> On Thursday, 14 November 2019 18:18:52 CET, Daniel Migault wrote:<= br> >>> Hi Hubert,

>>> I understand the reasons for SHOULD. At least this should be d= ocumented.
>>> To
>>> address your first point, of course the specification applies = to the
>>> server
>>> that support the extension.
>>
>>> Your second concern is solved by limiting the
>>> NTS of KEX.
>>
>> by "KEX" you mean handshake? but New Session Ticket mess= ages are not sent
>> during handshake, they are sent after handshake is finished
>
> yes. I would consider the NST as part of the handshake even for those = sent
> after the post-handshake authentication.

that would make tickets useless for sessions that use PHA
> I agree better terms may be used.
> The rekey aspect seems to me out of the handshake.

rekey also don't impact the keys used for derivation of session ticket<= br> secrets...

>> so how exactly you want to decide when server stopped sending NSTs= after
>> handshake finished?
>>
>
> That the spec does not mention it does not mean this will not be defin= ed.
> Instead it means each implementer will have its own logic, definitions= and
> outputs. The same reasoning occurs to the complexity argument,not
> specifying it does not reduce the complexity but let it to the
> implementation with all unexpected corner cases.

my point is that there is no good way to define it, if you want the count <= br> to be
limited, you need provide a good way to do that

I say that there isn't one, so defining it is futile

>>> The third point is addressed by the minimum of the (count,
>>> server_nbr). Note that I see count as a maximum. Overall I do = not think
>>> this would add much complexity.=C2=A0 The only complexity I se= e is when a
>> server
>>> sends NTS at different time in the KEX.
>>
>> again, and what if the server misbehaves?
>>
>
> Again, it would be a bug but the current spec is very permissive, at l= east
> in my opinion. I do not believe that not specifying the expected behav= iors
> will prevent misbehaviors to happen, it, instead simply legitimates th= em.

a MUST requires strict definition, which we can't provide, a SHOULD is =
already
in the draft

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic=

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000941e9505977073ea-- From nobody Sat Nov 16 02:05:51 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5734E120119 for ; Sat, 16 Nov 2019 02:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 tFNQI1BMkUOc for ; Sat, 16 Nov 2019 02:05:48 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF278120019 for ; Sat, 16 Nov 2019 02:05:47 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id C318332E666; Sat, 16 Nov 2019 05:05:46 -0500 (EST) Date: Sat, 16 Nov 2019 05:05:46 -0500 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20191116100546.GP34850@straasha.imrryr.org> Reply-To: tls@ietf.org References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2019 10:05:50 -0000 On Thu, Nov 14, 2019 at 08:05:34AM -0800, Christopher Wood wrote: > The only comment that was not integrated was the desire to use the hint > to express not only a count, but also a bit indicating whether or not > clients will accept a ticket if the server needs to send one (e.g., if its > STEK is about to rotate and any old tickets would expire). The authors did > not incorporate that into the document since it added complexity and there > didn't seem to be much support for it. I was hoping Matt Caswell would chime in with his perspective on this topic, as he and I together refined the ticket generation logic in OpenSSL 1.1.1. But, it seems he has not been able to find the requisite cycles, so I'll post my summary comments as best I can: 1. The tentative proposal was a client-side indication that new tickets are optional, and only needed when the presented ticket requires replacement. If still re-usable, accept it without issuing a new one. The goal was to make it possible for a client and server to "negotiate" re-use, rather than have that be a static feature of the application or a given implementation. 2. The specific suggestion of reserving a bit is more complex than needed, it would suffice to simply "subtract 1" from the client's hint: 0 - (effectively -1), client unconditionally wants no new tickets. 1 - (effectively 0), client prefers to reuse tickets. Only issue a new ticket if necessary (STEK rotation, ticket expiration, ...), or server does not support any ticket reuse. n - (effectively n - 1), client would like up to n-1 fresh tickets on any full handshake. This looks simple enough to me, and allows the client to clearly communicate that tickets are optional when reusable. 3. As noted previously, servers SHOULD NOT generally issue multiple tickets on successful resumption, at that leads to unbounded oversupply of tickets. Only the server knows whether resumption will happen, or a full handshake, and so clamping of the ticket count to 1 on resumption is best a server-side decision. A client can continue to request the same number of tickets (say hint 3 => 2 wanted, per the above), with the server returning that number on full handshake, but 1 or zero on resumption. When the client's presented ticket is not suitable for resumption, cleary the client needs new tickets (fresh start) and the behaviour should be the same as on an initial connection with no tickets from the client. The -03 draft added a sentence suggesting that clients should ask for just one ticket on resumption, but I would like to suggest that this logic belongs in the server. -- Viktor. From nobody Sat Nov 16 02:39:03 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D26120026 for ; Sat, 16 Nov 2019 02:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 6szPyJo6z8F4 for ; Sat, 16 Nov 2019 02:38:59 -0800 (PST) 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 A81A4120019 for ; Sat, 16 Nov 2019 02:38:59 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xAGAYljQ010484 for ; Sat, 16 Nov 2019 10:38:58 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=kjDKcMTxiUssIxnWru6QiCB/yvubiL16Ss2ODvhWCtI=; b=dKdzEBOkRQzdsFz83OMtJ/eEOnsYjMdxIUqOhKDzL1nysGFssBMdNBSSQEi0bQnaDcM0 DNIKNVJMECVhqfzqOZ65TiIZzmFD9zhVCkMk9UEIt+NPmPwfqok7VAuERWMyYpXqO8xI SA9Cy5BWboE4JCU6l60QesIzKe88ntMRCTg3jvkKMGP2FFlei3Lc4GNrOeOyxnbZvwMh No6s1jMkCgw3cbh935qd9NZdrHlfjmID8NPmYUJm6MlVBgNTnyBi+V/9yBGau9Fkvo2b wjzte/fCn1AyR5+eaY+2WnwwXvtplxM4NRzX/oSyJeHAJ+Wn+1I9B38DvIKmIf6xw4nJ VA== Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2waffv00e4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 16 Nov 2019 10:38:58 +0000 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAGAWg89027969 for ; Sat, 16 Nov 2019 05:38:57 -0500 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint7.akamai.com with ESMTP id 2wadb29evs-1 for ; Sat, 16 Nov 2019 05:38:57 -0500 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 4217580E1D for ; Sat, 16 Nov 2019 10:38:57 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1iVvTk-0004pz-3q for tls@ietf.org; Sat, 16 Nov 2019 02:38:56 -0800 Date: Sat, 16 Nov 2019 02:38:55 -0800 From: Benjamin Kaduk To: tls@ietf.org Message-ID: <20191116103855.GQ20609@akamai.com> References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <20191116100546.GP34850@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191116100546.GP34850@straasha.imrryr.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-16_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=13 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911160097 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-16_02:2019-11-15,2019-11-16 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 mlxscore=0 priorityscore=1501 bulkscore=0 impostorscore=0 spamscore=0 adultscore=0 malwarescore=0 phishscore=0 clxscore=1015 suspectscore=13 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911160098 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2019 10:39:02 -0000 On Sat, Nov 16, 2019 at 05:05:46AM -0500, Viktor Dukhovni wrote: > On Thu, Nov 14, 2019 at 08:05:34AM -0800, Christopher Wood wrote: > > > The only comment that was not integrated was the desire to use the hint > > to express not only a count, but also a bit indicating whether or not > > clients will accept a ticket if the server needs to send one (e.g., if its > > STEK is about to rotate and any old tickets would expire). The authors did > > not incorporate that into the document since it added complexity and there > > didn't seem to be much support for it. > [...] > > The -03 draft added a sentence suggesting that clients should ask for just > one ticket on resumption, but I would like to suggest that this logic > belongs in the server. We should probably be emphasizing that *all* policy belongs on the server, and we are just defining a signal for the client to convey some information as input to the server's decision. In that mindset I'm not sure that the "subtract one" signal is the most satisfying design (though I concede that it is probably the most efficient encoding). -Ben From nobody Sat Nov 16 03:04:31 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCA4120019 for ; Sat, 16 Nov 2019 03:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 OJfC11OfeEGT for ; Sat, 16 Nov 2019 03:04:26 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E8FC120026 for ; Sat, 16 Nov 2019 03:04:26 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 574FF32E6D5; Sat, 16 Nov 2019 06:04:25 -0500 (EST) Date: Sat, 16 Nov 2019 06:04:25 -0500 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20191116110425.GR34850@straasha.imrryr.org> Reply-To: tls@ietf.org References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <20191116100546.GP34850@straasha.imrryr.org> <20191116103855.GQ20609@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191116103855.GQ20609@akamai.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2019 11:04:30 -0000 On Sat, Nov 16, 2019 at 02:38:55AM -0800, Benjamin Kaduk wrote: > > The -03 draft added a sentence suggesting that clients should ask for just > > one ticket on resumption, but I would like to suggest that this logic > > belongs in the server. > > We should probably be emphasizing that *all* policy belongs on the server, and > we are just defining a signal for the client to convey some information as input > to the server's decision. In that mindset I'm not sure that the "subtract one" > signal is the most satisfying design (though I concede that it is probably the > most efficient encoding). Do you have an alternative suggestion? I am indeed optimizing for a minimally invasive change that keeps the encoding simple/efficient, at the cost of some indirection between intended signal and its representation. As with most things, there are trade-offs here. We could indeed have a separate flags field, or separate counts for various conditions: - # to issue on full handshake - # to issue on STEK rollover - # to issue if server supports/does-not-support reuse - ... But ultimately I think it boils down to whether the client: - can keep reusing an existing session with the ticket it already has - needs a single new ticket to keep reusing that session - is establishing a new session (full handshake) and wants to use parallel connections, so may want multiple fresh tickets. Likely the simplest mechanism that handles the above is enough, and I think the "-1" suggestion plus a server cap at 1 ticket on resumption, pretty much handles all three cases. Perhaps I'm missing some important cases, and if so, it would be good to flush those out and understand their trade-offs. -- Viktor. From nobody Sat Nov 16 08:38:27 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C364120103 for ; Sat, 16 Nov 2019 08:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wizmail.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 eC-bIpQYsFtU for ; Sat, 16 Nov 2019 08:38:22 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 AADCD12008C for ; Sat, 16 Nov 2019 08:38:22 -0800 (PST) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=wizmail.org; s=r201803; t=1573922302; b=GS8vco/CTEeAYc8f0GwHTncogjP3xh9m8dSiMyZ7fiT6qZjhwbW3smI80auAFxu+JU2zOwHGE+ SEUlNiWVre5h4+95/r/RWaRlzJnXDvV/5IuKs4v2GJnKh4gpzeOkg4g2k10HkQmrdQnm7E+0LW GtSLOHHZL+anfnOYufsj6R0=; ARC-Authentication-Results: i=1; wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=wizmail.org; s=r201803; t=1573922302; bh=b/PwxY30I/3A4hL4oW4E8oDXEgsfgXEHwj2MP4zk6s0=; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:DKIM-Signature; b=jL48bVOXsBZeM6eyOj3TbyU/hoytiAckzWG/9T1PsUuKtETCvYNPbl+xHkoaFYXBGk+dJX1mdl pU+4QWSUbdxyRbm9g922waVQq2CLpJv5qJ9ObJuQoYtfShi9mCIam6cW5yi0i1Si3JcGhL7kZh O8THForJ7rnqDOJmanUdvpE=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r201803; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=iIqe6kaUd5EZkv3drxcg26N3fuySB0Bzl8/tr4rH78A=; b=A OaoFyi+ixwQxNvJim5Nkg0PtosF4pa6NRYUR9aXG1DTb44qbfkYd3gK8Z0X8Kn/9nKmZN2N4camv4 8d8UDZwyPkmonaSAsmKsn5VmnC5wDASKDcRQka5CGl7YrKSv8enFRqbRnuGdv96cu34NBdmDg8Ihi KE6ao7crixnz4SpM=; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org (Exim 4.92.133) (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) with esmtpsa id 1iW15X-00010Y-Qz for tls@ietf.org (return-path ); Sat, 16 Nov 2019 16:38:19 +0000 To: "tls@ietf.org" References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <20191116100546.GP34850@straasha.imrryr.org> <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> From: Jeremy Harris Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= mQENBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAG0JkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+iQE7BBMBAgAlAhsD BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCVYAYBAIZAQAKCRC85YyM5B8y34iFB/9wozIY RogNdY1aejFFixb6++y4b1riyjMvWEULeEzDlQ0lMT6Z3PxXhZILD4y4aP7Kzx0ozXa5qaKy 41EAPKQoPipnRAH04QytJbIERvz8Tot/LeCVKUc0G9DVxOPBD03czTgqgz4EjV2qvnLF+rTU 0YBevrNCluKosGSd+3RvLWVu0hBhn9pELKfXJNSQXZb+TpHDhSDZ/gCrglBEOhA6YWbDb/4g z+5TFKdk+B++iAQZSHv7zISabjN+BPYgI47A+MU4JycoXaAUnMc0l5ba6fGNaIrzruE4aAZr lP5o+7mlU9Mm0QJqdqYxYPAiplJGrZv+YXH1fp5ueEK3l+NGuQENBFWABsQBCADphLHaKToR uR/E7THerBiCjDatwCaETOKOTY2zRBQpaQ32p/F2XIGLS8Cc27+grZSKQ6ZX0ZN47O+AFyFH F8DH90IXZFpJR3Rb8zgXT8jnLX08DM31eECZHnRzFhGlOmq6WAUlqB3GKCPUCY2c4eTRXyoX LteTxrXCYoj45y/YmvlZrlonBNjPBAyHiO/LNz+V7fZtNsN7N/XGrnLbcdNfNd+SD1ENmbLJ 8RvyymxguTyB/ka9JdjHHIoQEJ6L166B3hhfCHpt8iC0GPZkti9IMl0NoJ029jJm3Jq1qEce EBn5H5QMGn6Fq64iXwTsO1TMNUwpWx8pjvV7wVIxjI8ZABEBAAGJAR8EGAECAAkFAlWABsQC GwwACgkQvOWMjOQfMt9N6Af8CS2CTrMQFdhkGEtBXmL4ifD8UHFkBRBGmM8ZL2fWUBTZXT8m rdRMOK6tcPnKWaCvWvKr0knt970j/DyAgFmH8hgOi3yctigFecVDjjilAeCJMq38s1tYKYiL DbBdHWtdkA9uHZwq3lfd3QxcEEO3QamQF+dO7h8gAOXlG+po87Hm+E0wz4swIB8+S37Jzrx9 uu0LSFDfJCTK+TIKGa5Un8LxPxyq9WnnNDh72zK7BiRidk/s40KcNod83NM4Hn/sbGfyLa8s S0F3ME0S+ocSMOiu/ZHHOiwpLYNbwTJ7stZxGsrguWeT9P+amxbA/YlK95LedstwvN+WcHZ7 d++Arg== Message-ID: <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> Date: Sat, 16 Nov 2019 16:38:17 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <20191116110425.GR34850@straasha.imrryr.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2019 16:38:25 -0000 On 16/11/2019 11:04, Viktor Dukhovni wrote: >> We should probably be emphasizing that *all* policy belongs on the server, and >> we are just defining a signal for the client to convey some information as input >> to the server's decision. In that mindset I'm not sure that the "subtract one" >> signal is the most satisfying design (though I concede that it is probably the >> most efficient encoding). > > Do you have an alternative suggestion? The obvious encoding to me would be to reserve the all-bits-set value to mean "client wants no tickets", all-bits-clear to mean "client prefers to reuse tickets", anything else meaning "please serve up to this many fresh tickets". -- Cheers, Jeremy From nobody Sat Nov 16 13:06:22 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156FF120125 for ; Sat, 16 Nov 2019 13:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Uhatl-5oaX7O for ; Sat, 16 Nov 2019 13:06:19 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1F9120013 for ; Sat, 16 Nov 2019 13:06:17 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 24E4232EAF3; Sat, 16 Nov 2019 16:06:17 -0500 (EST) Date: Sat, 16 Nov 2019 16:06:17 -0500 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20191116210617.GS34850@straasha.imrryr.org> Reply-To: tls@ietf.org References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <20191116100546.GP34850@straasha.imrryr.org> <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2019 21:06:20 -0000 On Sat, Nov 16, 2019 at 04:38:17PM +0000, Jeremy Harris wrote: > > Do you have an alternative suggestion? > > The obvious encoding to me would be to reserve the all-bits-set value > to mean "client wants no tickets", all-bits-clear to mean "client > prefers to reuse tickets", anything else meaning "please serve up > to this many fresh tickets". That also works, effectively treat 0xff as "-1", but all other values as non-negative, with 0 a request for re-use. An isomorphic encoding, but without the "-1". -- Viktor. From nobody Sat Nov 16 16:00:04 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A8912003E for ; Sat, 16 Nov 2019 16:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 X9BDwWTAuxOX for ; Sat, 16 Nov 2019 16:00:02 -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 0A58E120808 for ; Sat, 16 Nov 2019 16:00:01 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xAH001or013808 for ; Sun, 17 Nov 2019 00:00:01 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=EnpXR1rm0c4/4M1ck88aD+LLz008ajHLl0SozvY+DQc=; b=jj07LGXMqIiVqfbjQnzOhtSJ0O0Gl66+QLH+odpgTCuVf/3juPBCLaMvxBxAxQj0l94M kjuuJFJcfK+224WXYZV1PehBs220xn8kHXIu7N7Z+MMd+IgRh+LiUsA1QqjoiAbN0Fdz mc/o1iqA5aKkqrS0XGlWE6dHPooDrVKK0XwSH6pxXFlOjWV59iExGsxf6WMA0iPBx+bV nLCLK/PWic0aPaWtpNSKel7RhFb1dB1gsAz2HKw2shNo56s1FMLcnYGTZ4VgORO6YIow mQ/fAAWU4zjrqTCXb20eXxk0jzBFBKfVq/s9JmKCwckJExi+QnrXeINvLUgZH1ewfBsF ig== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2wafqy26kn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 17 Nov 2019 00:00:00 +0000 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAGNl2qe010988 for ; Sat, 16 Nov 2019 18:59:55 -0500 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint6.akamai.com with ESMTP id 2wadaxgv64-1 for ; Sat, 16 Nov 2019 18:59:54 -0500 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id A70541FC95 for ; Sat, 16 Nov 2019 23:59:54 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1iW7yr-0006rn-MG for tls@ietf.org; Sat, 16 Nov 2019 15:59:53 -0800 Date: Sat, 16 Nov 2019 15:59:53 -0800 From: Benjamin Kaduk To: tls@ietf.org Message-ID: <20191116235952.GR20609@akamai.com> References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <20191116100546.GP34850@straasha.imrryr.org> <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191116210617.GS34850@straasha.imrryr.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-16_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=13 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=587 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911160224 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-16_08:2019-11-15,2019-11-16 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 mlxlogscore=593 clxscore=1015 priorityscore=1501 lowpriorityscore=0 bulkscore=0 mlxscore=0 suspectscore=13 impostorscore=0 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911160225 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2019 00:00:03 -0000 On Sat, Nov 16, 2019 at 04:06:17PM -0500, Viktor Dukhovni wrote: > On Sat, Nov 16, 2019 at 04:38:17PM +0000, Jeremy Harris wrote: > > > > Do you have an alternative suggestion? > > > > The obvious encoding to me would be to reserve the all-bits-set value > > to mean "client wants no tickets", all-bits-clear to mean "client > > prefers to reuse tickets", anything else meaning "please serve up > > to this many fresh tickets". > > That also works, effectively treat 0xff as "-1", but all other > values as non-negative, with 0 a request for re-use. An isomorphic > encoding, but without the "-1". [Jeremy had a more eloquent description of the vague sketch of an idea that I had in my head] -Ben From nobody Sat Nov 16 16:22:54 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523F5120047 for ; Sat, 16 Nov 2019 16:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 DA6obxSdocdW for ; Sat, 16 Nov 2019 16:22:51 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15BB9120043 for ; Sat, 16 Nov 2019 16:22:51 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id D09C732EC60; Sat, 16 Nov 2019 19:22:49 -0500 (EST) Date: Sat, 16 Nov 2019 19:22:49 -0500 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20191117002249.GV34850@straasha.imrryr.org> Reply-To: tls@ietf.org References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <20191116100546.GP34850@straasha.imrryr.org> <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191116235952.GR20609@akamai.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2019 00:22:52 -0000 On Sat, Nov 16, 2019 at 03:59:53PM -0800, Benjamin Kaduk wrote: > > That also works, effectively treat 0xff as "-1", but all other > > values as non-negative, with 0 a request for re-use. An isomorphic > > encoding, but without the "-1". > > [Jeremy had a more eloquent description of the vague sketch of an idea that I had in my head] Jeremy's "isomorphic" encoding works fine for me, and is likely less confusing. So, FWIW, it has my support. Fleshing it out a bit more, I am proposing: - 0xff => send no tickets - 0x00 => reuse requested: + send no tickets if presented ticket is accepted and reusable + send one ticket if presented ticket is accepted, but is not reusable (expired, or reuse is not allowed). + Also send one ticket if session could not be resumed and a full handshake was performed. Clients that reuse tickets don't need a separate one for each session, so one per full handshake should suffice. - 0x01-0xfe => client wants single-use tickets: + send up to that many tickets on full handshake, + however, generally send just 1 ticket on resumption, or when replacing tickets during long-lived connections. This helps to reduce chronic ticket "oversupply". -- Viktor. From nobody Sat Nov 16 16:45:18 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F199A12080D for ; Sat, 16 Nov 2019 16:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=WHeNIboH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=P3uKrkdk 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 QwlSSIKX7S5j for ; Sat, 16 Nov 2019 16:45:13 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49362120043 for ; Sat, 16 Nov 2019 16:45:13 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8145321B10 for ; Sat, 16 Nov 2019 19:45:12 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 16 Nov 2019 19:45:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=fYwIHyrZOau1jXeCDOsbFNNh1lUOnLpdCE6ZWmB3QCE=; b=WHeNIboH 5OoLUvgdlN7+4/syI51ZLPkW1vm4NnEOpzGp38qH1k9M6zjxwX59jygXwhvuTluX g19KjO5q242exNwmZ6iOdJYDc0DgegChlWdd0+T12kcSoAji7tPam+XSN/QYtQmY qTQOwk4GGk6suGAEyzRbsMAvaaY3Kgr0xtGrnXhF3W3TIgJ0hbF/s3TZ4tnmAgNK GC+gqlX3oIAIeRRxsX3JtJOobv8m/lXKoFTCfH1RvODhlFeo7vlOUH5n6kDl1LD2 sPwCac4nytpN0wR7oLaRbx8fwSFAbsDRWnpX78buH8v5ZEGMTKaAOgZ4xCynyC46 2Rj1YD3lqbeL0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=fYwIHyrZOau1jXeCDOsbFNNh1lUOn LpdCE6ZWmB3QCE=; b=P3uKrkdk+A44GI+J2OqWVuuoAVJGJTPQQ6wY6LzFOl/hU AzmGY001TaTNYedUQN1LhRjvkHj9R7FnqBZAEiU/6XFmYWdT6kLaUmEWEoizgrIJ 5ulqfhDxYCAOOgvhuy8r5OU2TX5UFP99Yek+SQpP1G6dfgG71mBztrjYFxn4Vd7L TubveYN3aWKJzOYjuID+mj8QEx71nPiAO+Qly3pqLmf3v+0ByuWZfza1JVMeRZ7T UcTfWSckW16CeUSp0S2ICtWpO32fpBFmoeu1lHzJJwofSeMY2EsdHLUM5aJ5ROe3 NQjcqVZFKC4+AykCOjZd3ZaQMDDj24J5lLFmlhpBg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudegtddgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpefiihhthhhusgcupfhothhifhhitggrthhiohhnshcuoeguohgpnhhothgp rhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmne cukfhppeeghedrjeelrdduudefrdduieehnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [45.79.113.165]) by mail.messagingengine.com (Postfix) with ESMTPA id 9F8658005A for ; Sat, 16 Nov 2019 19:45:11 -0500 (EST) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id BFB519E30F for ; Sun, 17 Nov 2019 00:45:10 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============7246984348477756227==" MIME-Version: 1.0 From: Github Notifications To: tls@ietf.org Message-Id: <20191117004510.BFB519E30F@cloud.mnot.net> Date: Sun, 17 Nov 2019 00:45:10 +0000 (UTC) Archived-At: Subject: [TLS] Weekly github digest (TLS Working Group Drafts) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2019 00:45:16 -0000 --===============7246984348477756227== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * tlswg/draft-ietf-tls-esni (+1/-1/=F0=9F=92=AC1) 1 issues created: - Removing ESNI RRType Considerations (by mrsylerpowers) https://github.com/tlswg/draft-ietf-tls-esni/issues/202=20 1 issues received 1 new comments: - #188 "HKDF-Extract(0, Z)" (1 by sayrer) https://github.com/tlswg/draft-ietf-tls-esni/issues/188=20 1 issues closed: - Removing ESNI RRType Considerations https://github.com/tlswg/draft-ietf= -tls-esni/issues/202=20 * tlswg/draft-ietf-tls-ticketrequest (+1/-0/=F0=9F=92=AC0) 1 issues created: - Add advisory text on prioritization of tickets vs. application data (by= chris-wood) https://github.com/tlswg/draft-ietf-tls-ticketrequest/issues/9=20 * tlswg/dtls13-spec (+0/-2/=F0=9F=92=AC0) 2 issues closed: - ChaCha20 header encryption https://github.com/tlswg/dtls13-spec/issues/= 109 [pr-exists]=20 - "Packet" and "datagram" https://github.com/tlswg/dtls13-spec/issues/106= [pr-exists]=20 Pull requests ------------- * tlswg/draft-ietf-tls-esni (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - Remove ESNI RRType Considerations (by mrsylerpowers) https://github.com/tlswg/draft-ietf-tls-esni/pull/203=20 1 pull requests merged: - Remove ESNI RRType Considerations https://github.com/tlswg/draft-ietf-tls-esni/pull/203=20 * tlswg/draft-ietf-tls-external-psk-importer (+0/-0/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #22 Addressing selfie attacks (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/22=20 * tlswg/dtls13-spec (+0/-2/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #111 Issue110 multiple connections same dg (1 by ekr) https://github.com/tlswg/dtls13-spec/pull/111=20 2 pull requests merged: - Issue109 chacha order https://github.com/tlswg/dtls13-spec/pull/112=20 - Issue106 packets https://github.com/tlswg/dtls13-spec/pull/113=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/tls-flags * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/sniencryption * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/draft-ietf-tls-grease --===============7246984348477756227== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday November 17, 2019

Issues

tlswg/draft-ietf-tls-esni (+1/-1/=F0=9F=92=AC1)

1 issues created:

1 issues received 1 new comments:

1 issues closed:

tlswg/draft-ietf-tls-ticketrequest (+1/-0/=F0=9F=92=AC0)

1 issues created:

tlswg/dtls13-spec (+0/-2/=F0=9F=92=AC0)

2 issues closed:

Pull requests

tlswg/draft-ietf-tls-esni (+1/-1/=F0=9F=92=AC0)

1 pull requests submitted:

1 pull requests merged:

tlswg/draft-ietf-tls-external-psk-importer (+0/-0/=F0=9F=92=AC1)

1 pull requests received 1 new comments:

tlswg/dtls13-spec (+0/-2/=F0=9F=92=AC1)

1 pull requests received 1 new comments:

2 pull requests merged:

Repositories tracked by this digest:

--===============7246984348477756227==-- From nobody Sun Nov 17 00:42:28 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA92E1200D5 for ; Sun, 17 Nov 2019 00:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 EIuJsiuI6sxv for ; Sun, 17 Nov 2019 00:42:23 -0800 (PST) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 2920B1200E3 for ; Sun, 17 Nov 2019 00:42:23 -0800 (PST) Received: by mail-ua1-x92f.google.com with SMTP id 31so4270757uas.9 for ; Sun, 17 Nov 2019 00:42:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dUN5K/uWPEaYwQ0C2Gv22N7PUts4dL6dLISFDz4bp6I=; b=dPWOF9qDo4cEg8McBidZKVAAP2P1l2btfuItYgdgGmwK/zfZHzlTzIH/LqL8BvwCBB O5XxO1f/iX7yth2udycVCf9X+etmW0KwRf9CH0LGm5H0aBda5TDdfJBLneRidF5Ks/Tw OairEOc+y+JYoROQivn9/mN0lxgTPjSml31qA= 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=dUN5K/uWPEaYwQ0C2Gv22N7PUts4dL6dLISFDz4bp6I=; b=sCHbAtXOt8ueinzxekyiFEdqBobylnIrgBtKw3lFSx+9R0tFyZ6FC07dH0VwUMMCuW Nq72mxgwzot0QvVQ4pabBsjet8ncnLhPUuPUcPFnQgO9WZkP+iCvOBAiJc+aCfa5MbqU YhPmAkyqbZ24Brgd1Zo58n9mc2zJo/Dzg0bhDQOodyuO2ulQ/sBe95vOeDhiNxPlmXwj oQ+vBLIi47gA/HnorOmxsgo9Glb6htQGS/Iu7FjdJR1HLQLI7NiHwM4XOM7HvPqKFmVh 1Sh2Vlp/1VQ9PF+WQ/tvJt6j0nWsuDcjZVNMXh2tdY6A5n3qK/kaQSitC+lRBJ/rko8z HBCg== X-Gm-Message-State: APjAAAUgBO6nyN/MHdg7hkgWiD54JLMf1G2dZ35MhR8jB8vejgbB9Sy8 wDZY34hCVXiG8jcpIOKGrC3uifFgR8IhCzXn8pdTUw== X-Google-Smtp-Source: APXvYqwAtVGIzxxRFGHgqsJBKbwabVRWMe2v1BQxqRc2wtyU/4svgIdeM9r1iRvAKYTk+BOAmZyqRnNk64KaBXbhtZk= X-Received: by 2002:ab0:1431:: with SMTP id b46mr4933191uae.52.1573980141776; Sun, 17 Nov 2019 00:42:21 -0800 (PST) MIME-Version: 1.0 References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> In-Reply-To: From: Nick Sullivan Date: Sun, 17 Nov 2019 16:42:05 +0800 Message-ID: To: Yaron Sheffer Cc: secdir@ietf.org, draft-ietf-tls-exported-authenticator.all@ietf.org, ietf@ietf.org, "" Content-Type: multipart/alternative; boundary="0000000000003c30ec059786cf1e" Archived-At: Subject: Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2019 08:42:27 -0000 --0000000000003c30ec059786cf1e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yaron, Thanks for reminding me about the codepoint issue. It's a sticky one. As far as I see it, there are three options: a) Change the document to UPDATE RFC 8446 This feels like a heavyweight option and may complicate things since it will mean that SNI is allowed but undefined for CertificateVerify in the TLS handshake. b) Ask for a new extension point for SNI sent in a client-generated authenticator request. This has the downside of not scaling to future client hello extensions that could be useful in exported authenticator requests -- it forces the definition of a new code point for each new extension. c) Explicitly state that the CertificateRequest-like construction in client-generated exported authenticator requests is a new type of message (analogous to a ClientHello) and clarify the rules about which extensions can be used when it is client-generated (specifically, say that any extension supported in CH is allowed) This is my preferred solution. I'm interested to hear what the working group thinks, and I'll happily present the options at IETF 106 if there's time. Best, Nick On Mon, Nov 4, 2019 at 6:20 PM Yaron Sheffer wrote: > Hi Nick, > > > > Apologies for not responding on time. > > > > I may be missing some follow-on discussions, but: > > > > - Ben suggested that we mention that QUIC is also an option, even if > informatively, in addition to the =E2=80=9CSHOULD use TLS=E2=80=9D sta= tement. > - I think we left my question re: back-fitting this protocol into the > IANA TLS registry open. Quoting: > > > > YS: 7.1: this is changing TLS 1.3 by allowing this extension in Cert > Request! I think it's a really bad idea. Better to hack special support t= o > existing libraries, allowing this specific extension for this special cas= e, > than to change the base protocol. Otherwise, this document should UPDATE > 8446. > > > > NS: This is a good point and one that we struggled a bit with during > design. We needed to allow SNI in the CertificateRequest message because = it > can be client-generated in this context. I'd be ok with creating a > different extension for this, but it's rather elegant to re-use it in thi= s > context. *I'd like to hear some opinions from the working group* on this > point > > > > BK: Or, since extension codepoints are cheap, just use a new codepoint. > > > > Thanks, > > Yaron > > > > *From: *Nick Sullivan > *Date: *Monday, November 4, 2019 at 04:49 > *To: *Yaron Sheffer > *Cc: *, < > draft-ietf-tls-exported-authenticator.all@ietf.org>, , "< > tls@ietf.org>" > *Subject: *Re: Secdir last call review of > draft-ietf-tls-exported-authenticator-09 > > > > Following up, > > > > Yaron, do the responses by myself and Benjamin along with the does the > following PR sufficiently address your comments/concerns? > > > > https://github.com/tlswg/tls-exported-authenticator/pull/52 > > > > On Wed, Sep 18, 2019 at 4:55 PM Nick Sullivan wrote= : > > Hi Yaron, > > > > Thank you for your thorough review. My answers will be inline, and I'll > incorporate some of Ben's replies if necessary. Here's a PR with proposed > changes in response to your comments: > > https://github.com/tlswg/tls-exported-authenticator/pull/52 > > > > On Tue, Jul 16, 2019 at 12:59 PM Yaron Sheffer via Datatracker < > noreply@ietf.org> wrote: > > Reviewer: Yaron Sheffer > Review result: Has Issues > > The document is generally clear in both its motivation and the proposed > solution. > > I think it's playing a bit too liberal with TLS 1.3, in sort-of but not > quite > deprecating renegotiation, and in changing the IANA registry in a way tha= t > actually changes the protocol. Details below. > > Other comments: > > * Abstract: please reword to make it clear that it's the proof (not the > cert) > that is portable. > > > > Proposed text here: > > This document describes a mechanism in Transport Layer Security (TLS) for > peers to > provide a proof of ownership of a certificate. This proof can be exporte= d > by one peer, transmitted out-of-band to the other peer, and verified by > the receiving peer. > > > > * Introduction: TLS 1.3 post-handshake auth "has the > disadvantage of requiring additional state to be stored as part of the TL= S > state machine." Why is that an issue is practice, assuming this feature i= s > already supported by TLS libraries? Also, are we in effect deprecating > this TLS > 1.3 feature because of the security issue of the mismatched record > boundaries? > > > > My understanding is that post-handshake authentication as defined in the > TLS 1.3 RFC is not implemented in many (any?) TLS 1.3 libraries and some > implementors would prefer to use exported authenticators. > > > > * "For simplicity, the mechanisms... require", maybe a normative REQUIRE? > > I'm fine with this. > > > > * Authenticator Request: please clarify that we use the TLS 1.3 format > even when > running on TLS 1.2. > > Updated, though it might be a bit unnecessary. > > > > * Also, I suggest to change "is not encrypted with a > handshake key" which is too specific to "is sent unencrypted within the > normal > TLS-protected data". > > This specific text is meant to differentiate the wire format of this > message from that of the CertificateRequest message, which is encrypted > with the handshake key. The specificity is warranted. > > > > * Before diving into the detailed messages in Sec. 3, it > would be nice to include a quick overview of the message sequence. > > There are two message types and three potential sequences. I've added a > short overview. > > > > * Sec. 3: > "SHOULD use TLS", change to MUST. There's no way it can work otherwise > anyway. > > As Ben noted, this could be any secure channel with equivalent security t= o > TLS, such as QUIC. We shouldn't forbid other secure out-of-band mechanism= s. > > > > * "This message reuses the structure to the CertificateRequest message" - > repeats the preceding paragraph. > > Fixed > > > > * Sec. 4: again, SHOULD use TLS -> MUST. > > Again, I don't see the need for a MUST here. > > > > * Is > there a requirement for all protocol messages to be sent over a single TL= S > connection? If so, please mention it. Certainly this is true for the > Authenticator message that must be sent over a single connection and > cannot be > multiplexed by the high-level protocol. I think this protocol actually > assumes > "nice" transport properties (no message reorder, reliability) that also > require > a single, clean TLS connection. > > There is no such requirement. Message ordering is managed by the > application layer protocol that utilizes exported authenticators. > > > > * Why no authenticator request for servers? > Don't we care about replay? OTOH if the client wants to detect replays, i= t > would need to keep state on received authenticators, which would be very > messy. > > I'm not sure I understand. It's possible to use authenticator requests fo= r > servers. > > > > * 4.1: when referencing Exporters, mention this is Sec. 7.5 of [TLS1.3]. > > Added "Sec. 7.5" > > > > * The > discussion of Extended Master Secret only applies to TLS 1.2 - please > clarify > that, plus I suggest to reword this paragraph which I find hard to parse. > > re-worded > > > > * > 4.2: "the extensions are chosen from the TLS handshake." - What does it > mean > exactly, and how does an application even know which extensions were used > at > the TLS layer? Reading further, we mention "ClientHello extensions." Mayb= e > the > authenticator should also include a ClientHello message to indicate > supported > extensions. Assuming we can peek into ClientHello contradicts the hopeful > "even > if it is possible to implement it at the application layer" in Sec. 6. > > > > This could be clearer. Effectively, the Certificate message in the > Authenticator needs > > to be constructed in a similar manner to how a Certificate message would > be created > > in a TLS handshake. Namely, it can only contain extensions that were > present in either > > the client hello or a preceding CertificateRequest. > > > > You're right that this makes an assumption that the party creating the > Authenticator > > has access to the TLS handshake state. This implies that even if the > Authenticator > > is created in the application space, an additional API needs to be expose= d > to share > > that information. > > > > * 4.2.1: > the first sentence of the section is incomplete. > > > > Fixed > > > > * Can I use TLS 1.3-specific > extensions (oid_filters) if I'm running on a TLS 1.2 connection? Is there= a > situation where a certificate is acceptable for TLS 1.3 connections but > not for > TLS 1.2 connections? > > Yes TLS 1.3-specific extensions are allowed, the CertificateRequest > message is TLS 1.3-compatible. > > > > * "using a value derived from the connection secrets" - I > think we should recommend a specific construction here to ensure people d= o > it > securely. > > This was a suggestion from the Additional Certificates use case ( > https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-0= 5). > I'm not sure we should get into the details here. > > > > * 4.2.3: Are we computing HMAC(MAC-key, Hash(a || b || c || d))? If > so, please say so. > > Yes, I'll put that in. > > > > * 4.2.4: "a constant-time comparison" - why is it actually > required, what is the threat? An attacker can do very little because each > authenticator being sent is different. > > As Ben noted, this was a safety note added during review. > > > > * 5: please say explicitly which > messages are used in this case to construct the authenticator. > > > > Re-written. > > * 6.1: the > "MUST" is strange in a section that's only supposed to be informative. > Also, > the library may provide this extension (and possibly others) without > requiring > it as input. > > How else do you propose wording the requirement that this API fail if the > connection doesn't support EAs? > > > > * 6.4: "The API MUST return a failure if the > certificate_request_context of the authenticator was used in a previously > validated authenticator." Are we requiring the library to keep previous > contexts for replay protection? If so, please make it explicit. > > I think this can be a SHOULD based on the burden replay protection places > on the implementation. > > > > * 7.1: this is > changing TLS 1.3 by allowing this extension in Cert Request! I think it's= a > really bad idea. Better to hack special support to existing libraries, > allowing > this specific extension for this special case, than to change the base > protocol. Otherwise, this document should UPDATE 8446. > > > > This is a good point and one that we struggled a bit with during design. > We needed to allow SNI in the CertificateRequest message because it can b= e > client-generated in this context. I'd be ok with creating a different > extension for this, but it's rather elegant to re-use it in this context.= *I'd > like to hear some opinions from the working group* on this point > > > > * 8: I think the > Security Considerations is the right place to talk about interaction > between > this protocol and TLS 1.3 (or 1.2) renegotiation. Even if we simply > RECOMMEND > not to do it. Or else explain the use cases where renegotiation is still > useful > if there are any. > > > > I'm not sure this document should be prescriptive about use cases. This > doc is providing a new capability that may be leveraged at the applicatio= n > to replace the functionality of existing mechanisms, but I'm not convince= d > the evaluation of the trade-offs of different mechanisms should be > contained in this document. > > --0000000000003c30ec059786cf1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yaron,

Thanks for remindi= ng me about the codepoint issue. It's a sticky one.

As far as I see it, there are three options:

a) Change the document to UPDATE RFC 8446
This feels like a heav= yweight option and may complicate things since it will mean that SNI is all= owed but undefined for CertificateVerify in the TLS handshake.
b) Ask for a new extension point for SNI sent in a client-gene= rated authenticator request.
This has the downside of not scaling= to future client hello extensions that could be useful in exported authent= icator requests -- it forces the definition of a new code point for each ne= w extension.

c) Explicitly state that the Certific= ateRequest-like construction in client-generated exported authenticator req= uests is a new type of message (analogous to a ClientHello) and clarify the= rules about which extensions can be used when it is client-generated (spec= ifically, say that any extension supported in CH is allowed)
= This is my preferred solution.

I'm interested = to hear what the working group=C2=A0thinks, and I'll happily present th= e options=C2=A0at IETF 106 if there's time.

Be= st,
Nick

On Mon, Nov 4, 2019 at 6:20 PM Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
<= /div>
=

Hi Nick,

=C2=A0

Apologies for not responding on time.

=C2=A0

= I may be missing some follow-on discussions, but:

=C2=A0

  • Ben suggested that we mention that QUIC is also an option,= even if informatively, in addition to the =E2=80=9CSHOULD use TLS=E2=80=9D= statement.
  • I think we left my question re: bac= k-fitting this protocol into the IANA TLS registry open. Quoting:

=C2=A0

YS: 7.1: this is changing TLS 1.3 by allowing this extension in C= ert Request! I think it's a really bad idea. Better to hack special sup= port to existing libraries, allowing this specific extension for this speci= al case, than to change the base protocol. Otherwise, this document should = UPDATE 8446.

=C2=A0

NS: This is a good point and one that we struggled= a bit with during design. We needed to allow SNI in the CertificateRequest= message because it can be client-generated in this context. I'd be ok = with creating a different extension for this, but it's rather elegant t= o re-use it in this context. *I'd like to hear some opinions from the w= orking group* on this point

= =C2=A0

BK: Or, since extension codepoints = are cheap, just use a new codepoint.

=C2=A0

Thanks,

<= p class=3D"MsoNormal">=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 Yaron

=C2=A0

Following up= ,

<= u>=C2=A0

On Wed, Sep 18, 201= 9 at 4:55 PM Nick Sullivan <nick@cloudflare.com> wrote:

Hi=C2=A0Yaron,=

=C2=A0

Thank you for your thorough review. My answers will be inlin= e, and I'll incorporate=C2=A0some of Ben's replies if necessary. He= re's a PR with proposed changes in response to your comments:=

<= p class=3D"MsoNormal">=C2=A0

On Tue, Jul 16, 2019 at 12:59 PM Yaron Sheffer via Datatracker &l= t;noreply@ietf.org> wrote:

Reviewer: Yaron Sheffer
Review result: Has Issues

The docu= ment is generally clear in both its motivation and the proposed
solution= .

I think it's playing a bit too liberal with TLS 1.3, in sort-o= f but not quite
deprecating renegotiation, and in changing the IANA regi= stry in a way that
actually changes the protocol. Details below.

= Other comments:

* Abstract: please reword to make it clear that it&#= 39;s the proof (not the cert)
that is portable.

<= div>

=C2=A0

* Introduction: TLS 1.3 post-handshake auth &q= uot;has the
disadvantage of requiring additional state to be stored as p= art of the TLS
state machine." Why is that an issue is practice, as= suming this feature is
already supported by TLS libraries? Also, are we = in effect deprecating this TLS
1.3 feature because of the security issue= of the mismatched record boundaries?

<= blockquote style=3D"border-top:none;border-right:none;border-bottom:none;bo= rder-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.= 8pt;margin-right:0in">

* "For simplicity, the me= chanisms... require", maybe a normative REQUIRE?

I'm fine with this.<= /p>

=C2=A0

* Authenticator Request: please clari= fy that we use the TLS 1.3 format even when
running on TLS 1.2.

* Also, I suggest to change "is not encrypted with a
handshake= key" which is too specific to "is sent unencrypted within the no= rmal
TLS-protected data".

* Before diving into the detailed me= ssages in Sec. 3, it
would be nice to include a quick overview of the me= ssage sequence.

T= here are two message types and three potential sequences. I've added a = short overview.

=C2=A0

* Sec. = 3:
"SHOULD use TLS", change to MUST. There's no way it can= work otherwise anyway.

As Ben noted, this could be any secure channel with equivalent secur= ity to TLS, such as QUIC. We shouldn't forbid other secure out-of-band = mechanisms.

=C2=A0

* "Thi= s message reuses the structure to the CertificateRequest message" -repeats the preceding paragraph.

Fixed

= =C2=A0

* Sec. 4: again, SHOULD use TLS -> MUST.

=

Again, I don't see the need for a MUST here= .

=C2=A0

* Is
there a requi= rement for all protocol messages to be sent over a single TLS
connection= ? If so, please mention it. Certainly this is true for the
Authenticator= message that must be sent over a single connection and cannot be
multip= lexed by the high-level protocol. I think this protocol actually assumes"nice" transport properties (no message reorder, reliability) th= at also require
a single, clean TLS connection.

There is no such requirement. Message ord= ering is managed by the application layer protocol that utilizes exported a= uthenticators.

=C2=A0=

* Why no= authenticator request for servers?
Don't we care about replay? OTOH= if the client wants to detect replays, it
would need to keep state on r= eceived authenticators, which would be very messy.

I'm not sure I understand. It's p= ossible to use authenticator requests for servers.

<= div>

=C2=A0

* 4.1: when referencing Exporters, mention thi= s is Sec. 7.5 of [TLS1.3].

* The
discussion of Extended Master Secret only appl= ies to TLS 1.2 - please clarify
that, plus I suggest to reword this para= graph which I find hard to parse.

*
4.2: "the extensions are chosen from the TLS handshake."= - What does it mean
exactly, and how does an application even know whic= h extensions were used at
the TLS layer? Reading further, we mention &qu= ot;ClientHello extensions." Maybe the
authenticator should also inc= lude a ClientHello message to indicate supported
extensions. Assuming we= can peek into ClientHello contradicts the hopeful "even
if it is p= ossible to implement it at the application layer" in Sec. 6.=

* 4.2.1:
the first sentence of the= section is incomplete.

=C2=A0

Fixed

=C2=A0

* Can I use TLS 1.3-specifi= c
extensions (oid_filters) if I'm running on a TLS 1.2 connection? I= s there a
situation where a certificate is acceptable for TLS 1.3 connec= tions but not for
TLS 1.2 connections?

Yes TLS 1.3-specific extensions are allowed, the C= ertificateRequest message is TLS 1.3-compatible.

=C2=A0

* "using a value derived from the connection= secrets" - I
think we should recommend a specific construction her= e to ensure people do it
securely.

=C2=A0

* 4.2.3: Are we computing HMAC(MAC-key, Hash(a || b || c || d))? If
s= o, please say so.

Yes, I'll put that in.

=C2=A0

* 4.2.4: "a constant-time comparison" - why is it actuallyrequired, what is the threat? An attacker can do very little because each=
authenticator being sent is different.

As Ben noted, this was a safety note added during= review.

=C2=A0

* 5: please sa= y explicitly which
messages are used in this case to construct the authe= nticator.

= =C2=A0

Re-written.=C2=A0=

* 6.1: the"MUST" is strange in a section that's only supposed to be i= nformative. Also,
the library may provide this extension (and possibly o= thers) without requiring
it as input.

How else do you propose wording the requirement tha= t this API fail if the connection doesn't support EAs?

=C2=A0

* 6.4: "The API MUST return a fail= ure if the
certificate_request_context of the authenticator was used in = a previously
validated authenticator." Are we requiring the library= to keep previous
contexts for replay protection? If so, please make it = explicit.

I think= this can be a SHOULD based on the burden replay protection places on the i= mplementation.=C2=A0

=C2= =A0

*= =C2=A0 7.1: this is
changing TLS 1.3 by allowing this extension in Cert = Request! I think it's a
really bad idea. Better to hack special supp= ort to existing libraries, allowing
this specific extension for this spe= cial case, than to change the base
protocol. Otherwise, this document sh= ould UPDATE 8446.

=C2=A0

This is a good p= oint and one that we struggled a bit with during design. We needed to allow= SNI in the CertificateRequest message because it can be client-generated i= n this context. I'd be ok with creating a different extension for this,= but it's rather elegant to re-use it in this context. I'd like = to hear some opinions from the working group on this point

=C2=A0

* 8: I think the
Security Consid= erations is the right place to talk about interaction between
this proto= col and TLS 1.3 (or 1.2) renegotiation. Even if we simply RECOMMEND
not = to do it. Or else explain the use cases where renegotiation is still useful=
if there are any.

=C2=A0

I'm not = sure this document should be prescriptive about use cases. This doc is prov= iding a new capability that may be leveraged at the application to replace = the functionality of existing mechanisms, but I'm not convinced the eva= luation of the trade-offs of different mechanisms should be contained in th= is document.

--0000000000003c30ec059786cf1e-- From nobody Sun Nov 17 04:22:48 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602F91200F5 for ; Sun, 17 Nov 2019 04:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_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=lowentropy.net header.b=UfwQE1+B; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=i/DwpFGR 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 8fdZ3kLiEi_g for ; Sun, 17 Nov 2019 04:22:43 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1681200F8 for ; Sun, 17 Nov 2019 04:22:43 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A96E221B03 for ; Sun, 17 Nov 2019 07:22:42 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sun, 17 Nov 2019 07:22:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm3; bh=eADIH fi3vfCP4tugFX6kTjagoTOGu5xjCyUB+NvPO2o=; b=UfwQE1+B2Ie/QQ8Zj/dAT ER0WnOX47B9EjS83xXUdy9+ONRx9jtSbwWj/AsjSoIs3332sPiD0qz625GFVXIhF fQdsYMZeBeH+LixbvQ1fFZL7VaVsC4XYKDPcfYgSt2WnkTzQQFM/KwLtyAzWbNQW YzOP9/2hV5ex3sjx3iT30di2L6ryUNzr4C/ITasR+Z+SpCxNGUSNSspasF+ODoWV Ucd+rmdSfwHK7te9iCmjDez1MBne7kuPtRn+JfEgbmNWkcM0MhAPTBu1Ll+qTwty gO/PIsaf37ovhrKaPoN/zZuvMGPDOhnFPPyvkVMMgZeStYLPTxfljPVpCeUiXgnq g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=eADIHfi3vfCP4tugFX6kTjagoTOGu5xjCyUB+NvPO 2o=; b=i/DwpFGRWbSDhLc7cd0Ch/BztCrtAXRs5N8hwiWH6q8CtDwUyzOiU2jPW oM0WhZ2qLD9oHlL1XmGaPlHKCBtif5iGKJikhOr8oMWGLd0Lao+U09TWn40ZLiB+ k32JByMx/OiZCDdkBCBKxcWlS7eaZtPNvjEcLZhVYoWW0l8DUPh873ZgxymT0mBk +VhCxaGVzeg+pjRLriqVNe5YqGby1eZypfNpJUO8usYNPl98AmHkneE2EJ1VIXOm GzpU7K4o8nv+Gh1DAhD9kCPIrHt5SCbGGfSIYUh0n/tnSCCF50yM3VUxg2F7kLho HAxfs+Hp/HLvxA88yi/Y61xRd89xA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeguddgudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpih gvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhho phihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 54C1DE00AA; Sun, 17 Nov 2019 07:22:42 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-562-gfd0633a-fmstable-20191114v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> Date: Sun, 17 Nov 2019 20:22:22 +0800 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] =?utf-8?q?Secdir_last_call_review_of_draft-ietf-tls-export?= =?utf-8?q?ed-authenticator-09?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2019 12:22:46 -0000 I think that I am OK with the CertificateRequest-like concept (c). The = idea that CertificateRequest might be used from client to server (a) is = something that I think we might be willing to consider in the fullness o= f time, but for now I think that it is probably best to avoid making ret= roactive changes to 8446. But I really do think that this is really jus= t a narrower representation of ClientHello that only includes just the b= its that apply to certificate selection. (Moved to TLS@) On Sun, Nov 17, 2019, at 16:42, Nick Sullivan wrote: > Hi Yaron, >=20 > Thanks for reminding me about the codepoint issue. It's a sticky one. >=20 > As far as I see it, there are three options: >=20 > a) Change the document to UPDATE RFC 8446 > This feels like a heavyweight option and may complicate things since i= t=20 > will mean that SNI is allowed but undefined for CertificateVerify in=20= > the TLS handshake. >=20 > b) Ask for a new extension point for SNI sent in a client-generated=20= > authenticator request. > This has the downside of not scaling to future client hello extensions= =20 > that could be useful in exported authenticator requests -- it forces=20= > the definition of a new code point for each new extension. >=20 > c) Explicitly state that the CertificateRequest-like construction in=20= > client-generated exported authenticator requests is a new type of=20 > message (analogous to a ClientHello) and clarify the rules about which= =20 > extensions can be used when it is client-generated (specifically, say=20= > that any extension supported in CH is allowed) > This is my preferred solution. >=20 > I'm interested to hear what the working group thinks, and I'll happily= =20 > present the options at IETF 106 if there's time. >=20 > Best, > Nick >=20 > On Mon, Nov 4, 2019 at 6:20 PM Yaron Sheffer w= rote: > > Hi Nick,____ >=20 > > __ __ >=20 > > Apologies for not responding on time.____ >=20 > > __ __ >=20 > > I may be missing some follow-on discussions, but:____ >=20 > > __ __ >=20 > > * Ben suggested that we mention that QUIC is also an option, even i= f informatively, in addition to the =E2=80=9CSHOULD use TLS=E2=80=9D sta= tement.____ > > * I think we left my question re: back-fitting this protocol into t= he IANA TLS registry open. Quoting: ____ > > __ __ >=20 > > YS: 7.1: this is changing TLS 1.3 by allowing this extension in Cert= Request! I think it's a really bad idea. Better to hack special support= to existing libraries, allowing this specific extension for this specia= l case, than to change the base protocol. Otherwise, this document shoul= d UPDATE 8446.____ >=20 > > __ __ >=20 > > NS: This is a good point and one that we struggled a bit with during= design. We needed to allow SNI in the CertificateRequest message becaus= e it can be client-generated in this context. I'd be ok with creating a = different extension for this, but it's rather elegant to re-use it in th= is context. *I'd like to hear some opinions from the working group* on t= his point____ >=20 > > __ __ >=20 > > BK: Or, since extension codepoints are cheap, just use a new codepoi= nt.____ >=20 > > __ __ >=20 > > Thanks,____ >=20 > > Yaron____ >=20 > > __ __ >=20 > > *From: *Nick Sullivan > > *Date: *Monday, November 4, 2019 at 04:49 > > *To: *Yaron Sheffer > > *Cc: *, , , "" > > *Subject: *Re: Secdir last call review of draft-ietf-tls-exported-au= thenticator-09____ >=20 > > __ __ >=20 > > Following up,____ >=20 > > __ __ >=20 > > Yaron, do the responses by myself and Benjamin along with the does t= he following PR sufficiently address your comments/concerns?____ >=20 > > __ __ >=20 > > https://github.com/tlswg/tls-exported-authenticator/pull/52____ >=20 > > __ __ >=20 > > On Wed, Sep 18, 2019 at 4:55 PM Nick Sullivan = wrote:____ >=20 > >> Hi Yaron,____ >=20 > >> __ __ >=20 > >> Thank you for your thorough review. My answers will be inline, and = I'll incorporate some of Ben's replies if necessary. Here's a PR with pr= oposed changes in response to your comments:____ >=20 > >> https://github.com/tlswg/tls-exported-authenticator/pull/52____ >=20 > >> __ __ >=20 > >> On Tue, Jul 16, 2019 at 12:59 PM Yaron Sheffer via Datatracker wrote:____ >=20 > >>> Reviewer: Yaron Sheffer > >>> Review result: Has Issues > >>>=20 > >>> The document is generally clear in both its motivation and the pro= posed > >>> solution.. > >>>=20 > >>> I think it's playing a bit too liberal with TLS 1.3, in sort-of bu= t not quite > >>> deprecating renegotiation, and in changing the IANA registry in a = way that > >>> actually changes the protocol. Details below. > >>>=20 > >>> Other comments: > >>>=20 > >>> * Abstract: please reword to make it clear that it's the proof (no= t the cert) > >>> that is portable.____ >=20 > >> __ __ >=20 > >> Proposed text here:____ >=20 > >> This document describes a mechanism in Transport Layer Security (TL= S) for peers to > >> provide a proof of ownership of a certificate. This proof can be ex= ported > >> by one peer, transmitted out-of-band to the other peer, and verifie= d by the receiving peer.____ >=20 > >> __ __ >=20 > >>> * Introduction: TLS 1.3 post-handshake auth "has the > >>> disadvantage of requiring additional state to be stored as part of= the TLS > >>> state machine." Why is that an issue is practice, assuming this fe= ature is > >>> already supported by TLS libraries? Also, are we in effect depreca= ting this TLS > >>> 1.3 feature because of the security issue of the mismatched record= boundaries?____ >=20 > >> __ __ >=20 > >> My understanding is that post-handshake authentication as defined i= n the TLS 1.3 RFC is not implemented in many (any?) TLS 1.3 libraries an= d some implementors would prefer to use exported authenticators.____ >=20 > >> __ __ >=20 > >>> * "For simplicity, the mechanisms... require", maybe a normative R= EQUIRE?____ >=20 > >> I'm fine with this.____ >=20 > >> ____ >=20 > >>> * Authenticator Request: please clarify that we use the TLS 1.3 fo= rmat even when > >>> running on TLS 1.2.____ >=20 > >> Updated, though it might be a bit unnecessary.____ >=20 > >> __ __ >=20 > >>> * Also, I suggest to change "is not encrypted with a > >>> handshake key" which is too specific to "is sent unencrypted withi= n the normal > >>> TLS-protected data".____ >=20 > >> This specific text is meant to differentiate the wire format of thi= s message from that of the CertificateRequest message, which is encrypte= d with the handshake key. The specificity is warranted.____ >=20 > >> __ __ >=20 > >>> * Before diving into the detailed messages in Sec. 3, it > >>> would be nice to include a quick overview of the message sequence.= ____ >=20 > >> There are two message types and three potential sequences. I've add= ed a short overview.____ >=20 > >> ____ >=20 > >>> * Sec. 3: > >>> "SHOULD use TLS", change to MUST. There's no way it can work other= wise anyway.____ >=20 > >> As Ben noted, this could be any secure channel with equivalent secu= rity to TLS, such as QUIC. We shouldn't forbid other secure out-of-band = mechanisms.____ >=20 > >> ____ >=20 > >>> * "This message reuses the structure to the CertificateRequest mes= sage" - > >>> repeats the preceding paragraph.____ >=20 > >> Fixed____ >=20 > >> ____ >=20 > >>> * Sec. 4: again, SHOULD use TLS -> MUST.____ >=20 > >> Again, I don't see the need for a MUST here..____ >=20 > >> ____ >=20 > >>> * Is > >>> there a requirement for all protocol messages to be sent over a si= ngle TLS > >>> connection? If so, please mention it. Certainly this is true for t= he > >>> Authenticator message that must be sent over a single connection a= nd cannot be > >>> multiplexed by the high-level protocol. I think this protocol actu= ally assumes > >>> "nice" transport properties (no message reorder, reliability) that= also require > >>> a single, clean TLS connection.____ >=20 > >> There is no such requirement. Message ordering is managed by the ap= plication layer protocol that utilizes exported authenticators.____ >=20 > >> ____ >=20 > >>> * Why no authenticator request for servers? > >>> Don't we care about replay? OTOH if the client wants to detect rep= lays, it > >>> would need to keep state on received authenticators, which would b= e very messy.____ >=20 > >> I'm not sure I understand. It's possible to use authenticator reque= sts for servers.____ >=20 > >> __ __ >=20 > >>> * 4.1: when referencing Exporters, mention this is Sec. 7.5 of [TL= S1.3].____ >=20 > >> Added "Sec. 7.5"____ >=20 > >> __ __ >=20 > >>> * The > >>> discussion of Extended Master Secret only applies to TLS 1.2 - ple= ase clarify > >>> that, plus I suggest to reword this paragraph which I find hard to= parse.____ >=20 > >> re-worded____ >=20 > >> __ __ >=20 > >>> * > >>> 4.2: "the extensions are chosen from the TLS handshake." - What do= es it mean > >>> exactly, and how does an application even know which extensions we= re used at > >>> the TLS layer? Reading further, we mention "ClientHello extensions= ." Maybe the > >>> authenticator should also include a ClientHello message to indicat= e supported > >>> extensions. Assuming we can peek into ClientHello contradicts the = hopeful "even > >>> if it is possible to implement it at the application layer" in Sec= . 6.____ >=20 > >> __ __ >=20 > >> This could be clearer. Effectively, the Certificate message in the = Authenticator needs____ >=20 > >> to be constructed in a similar manner to how a Certificate message = would be created____ >=20 > >> in a TLS handshake. Namely, it can only contain extensions that wer= e present in either____ >=20 > >> the client hello or a preceding CertificateRequest.____ >=20 > >> __ __ >=20 > >> You're right that this makes an assumption that the party creating = the Authenticator____ >=20 > >> has access to the TLS handshake state. This implies that even if th= e Authenticator____ >=20 > >> is created in the application space, an additional API needs to be = exposed to share____ >=20 > >> that information.____ >=20 > >> __ __ >=20 > >>> * 4.2.1: > >>> the first sentence of the section is incomplete.____ >=20 > >> __ __ >=20 > >> Fixed____ >=20 > >> ____ >=20 > >>> * Can I use TLS 1.3-specific > >>> extensions (oid_filters) if I'm running on a TLS 1.2 connection? I= s there a > >>> situation where a certificate is acceptable for TLS 1.3 connection= s but not for > >>> TLS 1.2 connections?____ >=20 > >> Yes TLS 1.3-specific extensions are allowed, the CertificateRequest= message is TLS 1.3-compatible.____ >=20 > >> ____ >=20 > >>> * "using a value derived from the connection secrets" - I > >>> think we should recommend a specific construction here to ensure p= eople do it > >>> securely.____ >=20 > >> This was a suggestion from the Additional Certificates use case (ht= tps://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-05= ). I'm not sure we should get into the details here.____ >=20 > >> ____ >=20 > >>> * 4.2.3: Are we computing HMAC(MAC-key, Hash(a || b || c || d))? I= f > >>> so, please say so.____ >=20 > >> Yes, I'll put that in.____ >=20 > >> __ __ >=20 > >>> * 4.2.4: "a constant-time comparison" - why is it actually > >>> required, what is the threat? An attacker can do very little becau= se each > >>> authenticator being sent is different.____ >=20 > >> As Ben noted, this was a safety note added during review.____ >=20 > >> ____ >=20 > >>> * 5: please say explicitly which > >>> messages are used in this case to construct the authenticator.____= >=20 > >> __ __ >=20 > >> Re-written. ____ >=20 > >>> * 6.1: the > >>> "MUST" is strange in a section that's only supposed to be informat= ive. Also, > >>> the library may provide this extension (and possibly others) witho= ut requiring > >>> it as input.____ >=20 > >> How else do you propose wording the requirement that this API fail = if the connection doesn't support EAs?____ >=20 > >> ____ >=20 > >>> * 6.4: "The API MUST return a failure if the > >>> certificate_request_context of the authenticator was used in a pre= viously > >>> validated authenticator." Are we requiring the library to keep pre= vious > >>> contexts for replay protection? If so, please make it explicit.___= _ >=20 > >> I think this can be a SHOULD based on the burden replay protection = places on the implementation. ____ >=20 > >> ____ >=20 > >>> * 7.1: this is > >>> changing TLS 1.3 by allowing this extension in Cert Request! I thi= nk it's a > >>> really bad idea. Better to hack special support to existing librar= ies, allowing > >>> this specific extension for this special case, than to change the = base > >>> protocol. Otherwise, this document should UPDATE 8446.____ >=20 > >> __ __ >=20 > >> This is a good point and one that we struggled a bit with during de= sign. We needed to allow SNI in the CertificateRequest message because i= t can be client-generated in this context. I'd be ok with creating a dif= ferent extension for this, but it's rather elegant to re-use it in this = context. *I'd like to hear some opinions from the working group* on this= point____ >=20 > >> ____ >=20 > >>> * 8: I think the > >>> Security Considerations is the right place to talk about interacti= on between > >>> this protocol and TLS 1.3 (or 1.2) renegotiation. Even if we simpl= y RECOMMEND > >>> not to do it. Or else explain the use cases where renegotiation is= still useful > >>> if there are any.____ >=20 > >> __ __ >=20 > >> I'm not sure this document should be prescriptive about use cases. = This doc is providing a new capability that may be leveraged at the appl= ication to replace the functionality of existing mechanisms, but I'm not= convinced the evaluation of the trade-offs of different mechanisms shou= ld be contained in this document.____ > From nobody Sun Nov 17 17:09:24 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4A6120831; Sun, 17 Nov 2019 17:09:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157403936311.6552.15013973232811122809@ietfa.amsl.com> Date: Sun, 17 Nov 2019 17:09:23 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-tls13-cert-with-extern-psk-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2019 01:09:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key Author : Russ Housley Filename : draft-ietf-tls-tls13-cert-with-extern-psk-03.txt Pages : 12 Date : 2019-11-17 Abstract: This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre- shared key (PSK). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-tls13-cert-with-extern-psk-03 https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-cert-with-extern-psk-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-cert-with-extern-psk-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 17 17:13:39 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7951207FD for ; Sun, 17 Nov 2019 17:13:33 -0800 (PST) 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBVnhpQ4cYNI for ; Sun, 17 Nov 2019 17:13:32 -0800 (PST) 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 1514F12006E for ; Sun, 17 Nov 2019 17:13:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 70F55300B3A for ; Sun, 17 Nov 2019 20:13:30 -0500 (EST) 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 Mjjsr0ukByrG for ; Sun, 17 Nov 2019 20:13:29 -0500 (EST) Received: from [5.5.33.161] (unknown [204.194.23.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 5D3903001CC for ; Sun, 17 Nov 2019 20:13:28 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sun, 17 Nov 2019 20:13:23 -0500 References: <157403936311.6552.15013973232811122809@ietfa.amsl.com> To: IETF TLS In-Reply-To: <157403936311.6552.15013973232811122809@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tls13-cert-with-extern-psk-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2019 01:13:33 -0000 This update is intended to address the comments from Ben's AD review. I = posted all of the changes last week, and I did not hear anyone raise an = issue with any of the proposed text. I think that the document is now = ready for IETF Last Call. Russ > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Layer Security WG of the = IETF. >=20 > Title : TLS 1.3 Extension for Certificate-based = Authentication with an External Pre-Shared Key > Author : Russ Housley > Filename : = draft-ietf-tls-tls13-cert-with-extern-psk-03.txt > Pages : 12 > Date : 2019-11-17 >=20 > Abstract: > This document specifies a TLS 1.3 extension that allows a server to > authenticate with a combination of a certificate and an external = pre- > shared key (PSK). >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk= / >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-tls-tls13-cert-with-extern-psk-03 > = https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-cert-with-exter= n-psk-03 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-tls13-cert-with-extern-= psk-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 18 08:50:12 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E31912097F for ; Mon, 18 Nov 2019 08:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyqYxz8-l0pg for ; Mon, 18 Nov 2019 08:50:08 -0800 (PST) Received: from mta.openssl.org (opentls.org [194.97.150.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E8E12013A for ; Mon, 18 Nov 2019 08:50:07 -0800 (PST) Received: from [IPv6:2a00:23c6:2d80:b900:45b7:ac50:a4f0:46bd] (unknown [IPv6:2a00:23c6:2d80:b900:45b7:ac50:a4f0:46bd]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id BFF91E4F09 for ; Mon, 18 Nov 2019 16:50:04 +0000 (UTC) To: tls@ietf.org From: Matt Caswell Message-ID: Date: Mon, 18 Nov 2019 16:50:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] Is Ed25519/Ed448 ok for use in DTLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2019 16:50:10 -0000 RFC8422 specifies the usage of Ed25519 and Ed448 in TLSv1.2. However there is barely any mention of DTLS. There is one reference which says this: "IANA has assigned one value from the "TLS HashAlgorithm" registry for Intrinsic (8) with DTLS-OK set to true (Y) and this document as reference. This keeps compatibility with TLS 1.3." That's in reference to the IANA TLS HashAlgorithm registry. But for the TLS SignatureAlgorithm registry it says this: "IANA has assigned two values in the "TLS SignatureAlgorithm" registry for ed25519 (7) and ed448 (8) with this document as reference. This keeps compatibility with TLS 1.3." This is in the paragraph before the other one, and there is no reference to ed25519/ed448 being "ok" for DTLS, and in fact there is no mention of DTLS anywhere else in this RFC. However the IANA TLS SignatureAlgorithm registry lists ed25519/ed448 as "ok" for DTLS and cites RFC8422 as a reference: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16 Is this an error in the IANA registry? Or is this an error in the RFC? Or is there some other RFC somewhere that specifies ed25519/ed448 usage in DTLS? I looked to see if there were any errata for RFC8422, but nothing looked relevant. Thanks Matt From nobody Mon Nov 18 14:38:53 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A007A120B66 for ; Mon, 18 Nov 2019 14:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 g5cGTn6oEDVS for ; Mon, 18 Nov 2019 14:38:51 -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 B5F8A120B67 for ; Mon, 18 Nov 2019 14:38:51 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAIMc9Yx012502; Mon, 18 Nov 2019 22:38:51 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Sm3ax0hxt2oVT4kpDYgue09FYeOb3CBmXn3gag2R6oE=; b=BZAkCMa0QXHpvSzztfx2dZicDFLcYPpc/YZj2F6VNEAndRpYHLvcAUjb8Wm1raAlrxfA OC66w95aX1nOIH8pVTJBgjC09KGCgjCCpPcBm/Y7kyJjw7ei7Mc+7DDx+BCuFl/RPnqM aBgeP9E/vipeuvDaZjTMgGk69Xi77NXoW0Q9nhPEiEWjwtMUVg1ZTnYmqPt+vbkSR+fP SOR89butRHWfhcVt/aVYP4OYVuBFzuwXhxxYLjiCDfZ6cao/y9e7xzSuOtvuJ/RQg6S0 j2ToJcQ2fhXf9WACzUl4O8HtrSuNEvCdT6dnr+9JfipUQ0INogbad1WTAmOBCW+i99iw mw== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2wafq025gf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Nov 2019 22:38:51 +0000 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAIMXJWs015575; Mon, 18 Nov 2019 17:38:49 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint6.akamai.com with ESMTP id 2wadaxks95-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 18 Nov 2019 17:38:49 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Nov 2019 17:38:49 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Mon, 18 Nov 2019 17:38:49 -0500 From: "Salz, Rich" To: Matt Caswell , "tls@ietf.org" Thread-Topic: [TLS] Is Ed25519/Ed448 ok for use in DTLS1.2? Thread-Index: AQHVnjBEKs2RQ4j7hkK2gB9KCnqbQ6eRhYCA Date: Mon, 18 Nov 2019 22:38:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191110 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.216.66] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-18_07:, , 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=546 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911180193 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-18_07:2019-11-15,2019-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 phishscore=0 malwarescore=0 spamscore=0 adultscore=0 lowpriorityscore=0 priorityscore=1501 mlxscore=0 bulkscore=0 clxscore=1015 mlxlogscore=536 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911180193 Archived-At: Subject: Re: [TLS] Is Ed25519/Ed448 ok for use in DTLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2019 22:38:53 -0000 RG9lcyBTZXNjdGlvbiAxNSBvZiBSRkMgODQ0NyBoZWxwPw0KDQogDQoNCg== From nobody Mon Nov 18 14:50:59 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADCB120B01; Mon, 18 Nov 2019 14:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 X9ANw21o1tlm; Mon, 18 Nov 2019 14:50:43 -0800 (PST) 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 E970412009E; Mon, 18 Nov 2019 14:50:42 -0800 (PST) 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 xAIMhIcO026647; Mon, 18 Nov 2019 22:50:39 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=+DKP9u1Do2DL4zIlUlpOPjG6xNmMx0iT9o+vtIRubxg=; b=GSScqzdCu2w6ue7BIqTPF+A7T3KJXBzMZfThu8MWVKlzKjXLPfHaTNFkQLtFpj+TrLQm VgfkKHxHCtUiIaWFeZDRgEoxCOpZVAFtKk+GgNBIZlr8cmx0NGzRpGgt3Pj68P0AgZqq DLaWplxpSoGXEDBXxtOALJdDvGTyjgq1L+Xmi/4taTEjiTXZv1hlIQEMX1/bpsYGIBEE xdOm+wvyt3bp7Lihc2brwwrF7TUmW6nPJjJzGHaeio4HZwtpSpM8uZHSRdgouas4PfCu q+DAvjieeZpqnK4mVT3Q2KW42u+pwdCr2cp2v+0y+PVMBEEtoR3Th0/mPzQssBotbD2z CQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2wag31j29e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Nov 2019 22:50:38 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAIMl0PT017939; Mon, 18 Nov 2019 17:50:38 -0500 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2waday63u8-1; Mon, 18 Nov 2019 17:50:37 -0500 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id B12261FCAA; Mon, 18 Nov 2019 22:50:37 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1iWpqu-0005aA-Az; Mon, 18 Nov 2019 14:50:36 -0800 Date: Mon, 18 Nov 2019 14:50:35 -0800 From: Benjamin Kaduk To: Nick Sullivan Cc: Yaron Sheffer , "" , draft-ietf-tls-exported-authenticator.all@ietf.org, ietf@ietf.org, secdir@ietf.org Message-ID: <20191118225035.GS20609@akamai.com> References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-18_07:, , 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=993 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911180195 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-18_07:2019-11-15,2019-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 priorityscore=1501 malwarescore=0 mlxlogscore=999 adultscore=0 mlxscore=0 bulkscore=0 lowpriorityscore=0 clxscore=1011 spamscore=0 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911180194 Archived-At: Subject: Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2019 22:50:48 -0000 On Sun, Nov 17, 2019 at 04:42:05PM +0800, Nick Sullivan wrote: > Hi Yaron, > > Thanks for reminding me about the codepoint issue. It's a sticky one. > > As far as I see it, there are three options: > > a) Change the document to UPDATE RFC 8446 > This feels like a heavyweight option and may complicate things since it > will mean that SNI is allowed but undefined for CertificateVerify in the > TLS handshake. > > b) Ask for a new extension point for SNI sent in a client-generated > authenticator request. > This has the downside of not scaling to future client hello extensions that > could be useful in exported authenticator requests -- it forces the > definition of a new code point for each new extension. > > c) Explicitly state that the CertificateRequest-like construction in > client-generated exported authenticator requests is a new type of message > (analogous to a ClientHello) and clarify the rules about which extensions > can be used when it is client-generated (specifically, say that any > extension supported in CH is allowed) > This is my preferred solution. Just to check: this would be adding a new possible value for the "TLS 1.3" column at https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1 ? Thanks, Ben > I'm interested to hear what the working group thinks, and I'll happily > present the options at IETF 106 if there's time. > From nobody Mon Nov 18 14:53:30 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFDEA1200B5 for ; Mon, 18 Nov 2019 14:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJ-qSlFZ0vuz for ; Mon, 18 Nov 2019 14:53:27 -0800 (PST) Received: from mta.openssl.org (xmpp.openssl.org [IPv6:2001:608:c00:180::1:e6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16AE712009E for ; Mon, 18 Nov 2019 14:53:27 -0800 (PST) Received: from [IPv6:2a00:23c6:2d80:b900:45b7:ac50:a4f0:46bd] (unknown [IPv6:2a00:23c6:2d80:b900:45b7:ac50:a4f0:46bd]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id 13BC8E4EC1; Mon, 18 Nov 2019 22:53:25 +0000 (UTC) To: "Salz, Rich" , "tls@ietf.org" References: From: Matt Caswell Message-ID: <4431e115-64ff-b660-87bb-b8bf3aa4ea15@openssl.org> Date: Mon, 18 Nov 2019 22:53:24 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Is Ed25519/Ed448 ok for use in DTLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2019 22:53:29 -0000 On 18/11/2019 22:38, Salz, Rich wrote: > Does Sesction 15 of RFC 8447 help? Not really, no. It adds some broad statements about the applicability of these registries, i.e. that they're only useful for DTLS1.2 and below, and adds some reserved fields. But it offers no explanation for where the "DTLS-OK" value of "Y" has come from for ed25519/ed448. The only reference those values have against them is RFC 8442 and that RFC does not say anything about DTLS-OK being "Y" for them. My guess is either: 1) The registry is in error and they should not have Y against them or 2) The intent behind RFC 8442 was that it should apply to DTLS but it was missed in error. The third possibility is that there is some other RFC that specifies this (but if so why doesn't the "Reference" column list it). Matt From nobody Mon Nov 18 16:41:25 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7261B120143 for ; Mon, 18 Nov 2019 16:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 5i6xjtkRlQv4 for ; Mon, 18 Nov 2019 16:41:20 -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 80FCE120125 for ; Mon, 18 Nov 2019 16:41:20 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xAJ0bGjT013490; Tue, 19 Nov 2019 00:41:20 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=i+dZHCiuFg0JE9Sq97LLesCG20ZvdfVhIf2knmiPBhs=; b=fMLVu1HryRSimBfyfI4dZi6tdnjQPA2yp3a5xjQIQiVV2Kt9iT4C/4SKNf6UUpxGxm8B lt+aVYKDE2tdtIHIf4nBdjVPHXYveyz8Tl+5jvPAnJ9EDmBtMfTVMnO935rX0TynSlWg b31chigo3wKhaNBw0ipCuyU6jYDBkjpcMZ2/w0MFaEuQ0ZgIUkE2+D/yQSZairoa82T3 d0IoBbiND0aelZUxI09gh0Mxpc8gUzze+GHIHQaQFDPlPkv91ZYXVa5FZWbSRgmT+03x b8FXl7qQ5PnqRkV7/0RsbD8Jm5KxyFG86oSoaDj23cJXyXBBGE4l5SxXfKRGF35JErWa 6A== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2wafwvb7ev-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 Nov 2019 00:41:19 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAJ0WFqs003936; Mon, 18 Nov 2019 16:41:18 -0800 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint5.akamai.com with ESMTP id 2wafybkqka-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 18 Nov 2019 16:41:18 -0800 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Nov 2019 19:41:17 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Mon, 18 Nov 2019 19:41:17 -0500 From: "Salz, Rich" To: Matt Caswell , "tls@ietf.org" Thread-Topic: [TLS] Is Ed25519/Ed448 ok for use in DTLS1.2? Thread-Index: AQHVnjBEKs2RQ4j7hkK2gB9KCnqbQ6eRhYCAgABX6AD//8pQgA== Date: Tue, 19 Nov 2019 00:41:16 +0000 Message-ID: <2D5349E3-D9FE-44B6-8A40-1F1AE1863A46@akamai.com> References: <4431e115-64ff-b660-87bb-b8bf3aa4ea15@openssl.org> In-Reply-To: <4431e115-64ff-b660-87bb-b8bf3aa4ea15@openssl.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191110 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.216.123] Content-Type: text/plain; charset="utf-8" Content-ID: <4F13A019D457834E9CBD820C32156579@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-18_08:, , 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=857 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911190001 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-18_08:2019-11-15,2019-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 lowpriorityscore=0 priorityscore=1501 phishscore=0 clxscore=1015 mlxlogscore=826 impostorscore=0 suspectscore=0 bulkscore=0 malwarescore=0 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911190001 Archived-At: Subject: Re: [TLS] Is Ed25519/Ed448 ok for use in DTLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2019 00:41:24 -0000 QXMgODQyMiBzYXlzICJEVExTLU9LIiBhbmQgc2luY2UgWW9hdiBpcyBib3RoIGFuIGF1dGhvciBv ZiB0aGUgUkZDIGFuZCBvbmUgb2YgdGhlIHJlZ2lzdHJ5IGV4cGVydHMsIEkgdGhpbmsgaGUgbmVl ZHMgdG8gcmVwbHkgaGVyZS4NCg0KPiAgICBNeSBndWVzcyBpcyBlaXRoZXI6ICANCj4gICAgMSkg VGhlIHJlZ2lzdHJ5IGlzIGluIGVycm9yIGFuZCB0aGV5IHNob3VsZCBub3QgaGF2ZSBZIGFnYWlu c3QgdGhlbQ0KPiBvcg0KID4gICAyKSBUaGUgaW50ZW50IGJlaGluZCBSRkMgODQ0MiB3YXMgdGhh dCBpdCBzaG91bGQgYXBwbHkgdG8gRFRMUyBidXQgaXQNCiAgICB3YXMgbWlzc2VkIGluIGVycm9y Lg0KICAgIA0KIzEgaXMgdGhlIHNpbXBsZSBmaXgsIGJ1dCBpdCBzZWVtcyB3cm9uZy4gICMyIGNv dWxkICpwcm9iYWJseSogYmUgZml4ZWQgd2l0aCBhbiBlcnJhdGEsIGJ1dCBoYXJkIHRvIGRvIGlu IGEgd2F5IHRoYXQgZG9lc24ndCBtYWtlIHRoZSBjaGFuZ2VzIGludmFzaXZlLg0KDQpGV0lXLCBh cyBhbm90aGVyIG9uZSBvZiB0aGUgcmVnaXN0cnkgZXhwZXJ0cywgSSBwcmVmZXIgIzIuDQoNCg== From nobody Mon Nov 18 17:34:51 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9BE1201EF for ; Mon, 18 Nov 2019 17:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItaWgWj4Op2q for ; Mon, 18 Nov 2019 17:34:44 -0800 (PST) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (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 6256D120071 for ; Mon, 18 Nov 2019 17:34:44 -0800 (PST) Received: by mail-qt1-x841.google.com with SMTP id t20so22679376qtn.9 for ; Mon, 18 Nov 2019 17:34:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=DyUrre57qpppdw/2ibItS6CrNIjr2ri0gPpC4e4XO+g=; b=DaXht1/ZoeBTyz8/UTX3Gm0bwAsnJFiU0SsdM+9Kpjnta8TEZ4UZv+TDOdRsU0b27j 66oig0hgmlX/xlXNcyHMWlJpRiE1C0ZN3hxVCCV/Daj2pAnqFc3mPdiFgn8oqJ02MimR rchxIVltiRyj0TfGoR2roulBiB2fP4tKUKRSW3r+d+Hpo2qwXyV2oC4e2ejZEcW97zFS f9OBpqxrYB1ZaYtFltpiCUNLpLE05eV8wzY23B641+df5eccnIVsF7jTGBNTEkJkvvQe ovTEf8V8LohnbpyeHe9AVN3UZAFpm5oVCt8oQefbGM8+/YcCY2/MeaXpyxfTOPLTRVIy 1ZsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=DyUrre57qpppdw/2ibItS6CrNIjr2ri0gPpC4e4XO+g=; b=A+FXYD1t4KtHao9E5OfVQz8vEiAsHIyIRrdNYroUBRfji1aS2leyyRVP4nzRX5ypCB 6hbmhu5INmrwGAr/NPN49Q3YJu4iYWW5+5EdmLeG8fxp3XcH+HWhjl/St2QGngiaHMj7 K8iKLfrwfdAp8ldmOPoE6zLD1L32t4O695R5Sipa24bC2VDxYRiij5vRXz0GkakxXv/K jfemx34QbvJNxjRIw8aD2qjDrn+0070bMwxLn2avdIDQpFh3UnSTx1Bz+0qv+wQ88xQ8 KZVxjFGDD8i/6kwMJ2UKxIwLX77I70lFKc2iyCN77qFYLn0mWE7fUcEsu+dyt9D1zRki AjGA== X-Gm-Message-State: APjAAAW6ja1IIcq//CkpLq8pdiDRsyfTOxVBaFbtZxW99r/Ighzbt2W3 0L7jBTCmgO6T2Ao1RmZaLdRYaIKSzrowE0YA23JK9zltUpMSFQ== X-Google-Smtp-Source: APXvYqxfhu+ti8aFGckVJMmzebMlGAGxDdPUITRVVvvPQNoVzvkN1E3HPBCVJ7Cls52RGyaUoHEC26tuon7/uTbVYrQ= X-Received: by 2002:aed:31e7:: with SMTP id 94mr30182797qth.71.1574127283281; Mon, 18 Nov 2019 17:34:43 -0800 (PST) MIME-Version: 1.0 From: Joseph Salowey Date: Tue, 19 Nov 2019 09:34:32 +0800 Message-ID: To: "" , tls-chairs Cc: Eric Rescorla , Richard Barnes , Hannes Tschofenig , Christopher Wood , David Benjamin , Nick Sullivan , Stephen Farrell , jonathan.hoyland@gmail.com Content-Type: multipart/alternative; boundary="0000000000008d3e350597a911a2" Archived-At: Subject: [TLS] Presentations Slides for IETF 106 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2019 01:34:50 -0000 --0000000000008d3e350597a911a2 Content-Type: text/plain; charset="UTF-8" As a reminder presentations for non-working group items must be sent to the chairs (tls-chairs@ietf.org) today. Failing to do this may result in your presentation being removed from the agenda. Presentation guidelines can be found at: https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md#guidance-for-tls-wg-presenters Thanks, Joe --0000000000008d3e350597a911a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As a reminder presentations for non-working group items mu= st be sent to the chairs (tls-chairs= @ietf.org) today.=C2=A0 Failing to do this may result in your presentat= ion being removed from the agenda.=C2=A0 Presentation guidelines can be fou= nd at:=C2=A0=C2=A0https://github.com/tlswg/tlswg-wik= i/blob/master/FAQ.md#guidance-for-tls-wg-presenters=C2=A0

Thanks,

Joe
--0000000000008d3e350597a911a2-- From nobody Mon Nov 18 18:56:55 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13C612080F for ; Mon, 18 Nov 2019 18:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 IXa1GbQ_IIZU for ; Mon, 18 Nov 2019 18:56:33 -0800 (PST) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 0A7D612080E for ; Mon, 18 Nov 2019 18:56:33 -0800 (PST) Received: by mail-vk1-xa2f.google.com with SMTP id o2so4686136vkc.13 for ; Mon, 18 Nov 2019 18:56:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LQv/yJUOs3pUDQmlgpAmiyMpmDQXtVVk0ML3PkFLzxk=; b=iUG9q4TtqyjaOWftVHZ/z6Ta4SfmejIIbTZB1eImCTTVKAlAy6MAgNSJy3JQuL42QY WvIeP/Q4iKsQKb/UOXpGKB6jHmnWjv087HWnsdorSESfqpY1h4JzuRdjpBsV9Z1TlhX2 RzRyE7BewVWEmV1WCAxx/7AjiNzXSoPrI1kD0= 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=LQv/yJUOs3pUDQmlgpAmiyMpmDQXtVVk0ML3PkFLzxk=; b=sJCuYT11JctVnuPfUrZQGEo0sC2bm0BJouzlHicyi5Ue7n+HcSNDtjMmY+RSzEM8vj gUMLjFoF8VNLdbleO9FgoAMNk/4Cy5HW7ZGukQDtKkdxpfOFf+48PL2cAZKJGK/j/wTC RyYkLt44APvEV5IhbeYb3jj1fgr/IWk378QlHdQPHXVkZD4Qg2wWDDdaBNTnjT0nS0CB B/5+FDP5DgVPbkgjAzIEyDKH2KkboVODF2azihsXs9LkC/QA4PYyfbo8UhsUjp1cfbhv ydpev9nONa0cEBLrn0I1KG61ETnx9RpgfNF/lk0F81uGrIdgtJRngM8dHpG73ytpR/bW 5XEQ== X-Gm-Message-State: APjAAAUKFccrNwdYfolouwnpEd6ZlKiyOB6n4X+ktDKzHDACz4jiSB/W 3E3wsCulAW/E59Rub1/dEGL2v5MmuRdq43Qwhh7c3A== X-Google-Smtp-Source: APXvYqwBfDE5Jgmax36ij8KjskPbKiy2ovsGhceV1zkaCDugRDlu1TvGNcQq0BfRzVzzTedFWNw6fHZJ7hHFnSsMjoI= X-Received: by 2002:a1f:2cd:: with SMTP id 196mr10263419vkc.23.1574132191837; Mon, 18 Nov 2019 18:56:31 -0800 (PST) MIME-Version: 1.0 References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> <20191118225035.GS20609@akamai.com> In-Reply-To: <20191118225035.GS20609@akamai.com> From: Nick Sullivan Date: Tue, 19 Nov 2019 10:56:14 +0800 Message-ID: To: Benjamin Kaduk Cc: Yaron Sheffer , "" , draft-ietf-tls-exported-authenticator.all@ietf.org, ietf@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="0000000000001ff5830597aa364c" Archived-At: Subject: Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2019 02:56:45 -0000 --0000000000001ff5830597aa364c Content-Type: text/plain; charset="UTF-8" On Tue, Nov 19, 2019 at 6:50 AM Benjamin Kaduk wrote: > On Sun, Nov 17, 2019 at 04:42:05PM +0800, Nick Sullivan wrote: > > Hi Yaron, > > > > Thanks for reminding me about the codepoint issue. It's a sticky one. > > > > As far as I see it, there are three options: > > > > a) Change the document to UPDATE RFC 8446 > > This feels like a heavyweight option and may complicate things since it > > will mean that SNI is allowed but undefined for CertificateVerify in the > > TLS handshake. > > > > b) Ask for a new extension point for SNI sent in a client-generated > > authenticator request. > > This has the downside of not scaling to future client hello extensions > that > > could be useful in exported authenticator requests -- it forces the > > definition of a new code point for each new extension. > > > > c) Explicitly state that the CertificateRequest-like construction in > > client-generated exported authenticator requests is a new type of message > > (analogous to a ClientHello) and clarify the rules about which extensions > > can be used when it is client-generated (specifically, say that any > > extension supported in CH is allowed) > > This is my preferred solution. > > Just to check: this would be adding a new possible value for the "TLS 1.3" > column at > https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1 > ? > Not necessarily. The text could be amended to say something like: "the allowed extensions for client-generated authenticator requests need to have CH listed, and for server-generated authenticator requests need to have CR listed" The only current extension that supports CR, but not CH is oid_filters, which is not relevant to client-initiated authenticator requests. > Thanks, > > Ben > > > I'm interested to hear what the working group thinks, and I'll happily > > present the options at IETF 106 if there's time. > > > --0000000000001ff5830597aa364c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 19, 2019 at 6:50 AM Benja= min Kaduk <bkaduk= @akamai.com> wrote:
On Sun, Nov 17, 2019 at 04:42:05PM +0800, Nick Sullivan wrote: > Hi Yaron,
>
> Thanks for reminding me about the codepoint issue. It's a sticky o= ne.
>
> As far as I see it, there are three options:
>
> a) Change the document to UPDATE RFC 8446
> This feels like a heavyweight option and may complicate things since i= t
> will mean that SNI is allowed but undefined for CertificateVerify in t= he
> TLS handshake.
>
> b) Ask for a new extension point for SNI sent in a client-generated > authenticator request.
> This has the downside of not scaling to future client hello extensions= that
> could be useful in exported authenticator requests -- it forces the > definition of a new code point for each new extension.
>
> c) Explicitly state that the CertificateRequest-like construction in > client-generated exported authenticator requests is a new type of mess= age
> (analogous to a ClientHello) and clarify the rules about which extensi= ons
> can be used when it is client-generated (specifically, say that any > extension supported in CH is allowed)
> This is my preferred solution.

Just to check: this would be adding a new possible value for the "TLS = 1.3"
column at https://www.iana.org/assignments/tls-extensiontype= -values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1 ?
=
Not necessarily. The text could be amended to say somethi= ng like:
=C2=A0 "the allowed extensions for client-generated= authenticator requests need to have=C2=A0CH listed, and for server-generat= ed authenticator requests need to have CR listed"
=C2=A0
The only current extension that supports CR, but not CH is=C2=A0oid_= filters, which is not relevant to client-initiated authenticator requests.<= /div>


Thanks,

Ben

> I'm interested to hear what the working group thinks, and I'll= happily
> present the options at IETF 106 if there's time.
>
--0000000000001ff5830597aa364c-- From nobody Mon Nov 18 19:10:24 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 086B0120251; Mon, 18 Nov 2019 19:10:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.110.1 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: tls-chairs@ietf.org, Joseph Salowey , tls@ietf.org, draft-ietf-tls-tls13-cert-with-extern-psk@ietf.org, joe@salowey.net, kaduk@mit.edu Content-Transfer-Encoding: 7bit Reply-To: last-call@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157413301602.14126.1966301384910486916.idtracker@ietfa.amsl.com> Date: Mon, 18 Nov 2019 19:10:16 -0800 Archived-At: Subject: [TLS] Last Call: (TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key) to Experimental RFC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2019 03:10:16 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2019-12-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre- shared key (PSK). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Nov 18 19:22:09 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86386120251 for ; Mon, 18 Nov 2019 19:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=wO3NTON/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uvzY27kc 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 fOUYtlISJjSe for ; Mon, 18 Nov 2019 19:22:07 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68A4B12011F for ; Mon, 18 Nov 2019 19:22:07 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7088621FA9 for ; Mon, 18 Nov 2019 22:22:06 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 18 Nov 2019 22:22:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=8GoncGVsQJ5/wv1K640hZocHHgAFcy5 88pAzubnxhjk=; b=wO3NTON/dq/HDVoCEqOQJZCtYtnzJr39Aqpg4I98N2Y67Fp tYHeUi9ai5060api6Uoj9x3ywYmgFJhu23PWYj3pMaZlzcHxQXk3WoLFKWh5J4eO XM0A5NOzV/3S+EinwMWQ5vYGpoNtIutqU7+YOJyp5sxalZnygzInro/TX2LVUrFf /z1wHoqQP9umdr+ckIpoXwUQ2t0nY3s94Bymdx/drpdbAXGRdUyvald5z56m3IVf kcRJDjDFK+2hAo9aVaT119os4h+zTuT4RHhGzHcCvuiTEXwi9j08HGrlf9IyWBZ+ MV29KxtMEs6g6vg3fr1BfUlTNHwioRleU05sUZQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=8GoncG VsQJ5/wv1K640hZocHHgAFcy588pAzubnxhjk=; b=uvzY27kclhVKBJD1OEBrIj vaEbAa+PP4L6xLbl+9V3L0GdS1XZFPaYyrZ48FFSI/4DeXvzqN8ecuqELIdh390O juLartaxaBewEqkiVNEX7Zyy5iCNmkBivncpElYuNjG8ug9wVWw+i9j6hswfgyGK htUvRCiwTbYYClfPTImZrOB6FUY4niPaF4LAGG0AzrE097WYCoLq4drX7saSNZsX FpD0kmNZblTUgG8cdhJdchZPFkypbuQJtHvF7bBlRQlAfUKavMj+zR6goPDkJ2dM kTHW44Yx0lIGOQ1sqE7C778MYxG76fih0zdmKpWoduN5anLEyT707UPKgvLdDDdw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudegjedgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehloh ifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EF954E00A3; Mon, 18 Nov 2019 22:22:05 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: <430940ff-60f0-4ddd-9d71-9fe8b8ca9cae@www.fastmail.com> In-Reply-To: References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> <20191118225035.GS20609@akamai.com> Date: Tue, 19 Nov 2019 11:21:46 +0800 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] =?utf-8?q?Secdir_last_call_review_of_draft-ietf-tls-export?= =?utf-8?q?ed-authenticator-09?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2019 03:22:08 -0000 On Tue, Nov 19, 2019, at 10:56, Nick Sullivan wrote: > The text could be amended to say something like: > "the allowed extensions for client-generated authenticator requests > need to have CH listed, and for server-generated authenticator requests > need to have CR listed" > The only current extension that supports CR, but not CH is oid_filters, > which is not relevant to client-initiated authenticator requests. I like this resolution. From nobody Tue Nov 19 01:17:27 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CA212081F for ; Tue, 19 Nov 2019 01:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8XK0P5q6Tn5 for ; Tue, 19 Nov 2019 01:17:23 -0800 (PST) Received: from mta.openssl.org (xmpp.openssl.org [194.97.150.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98BE11200C1 for ; Tue, 19 Nov 2019 01:17:22 -0800 (PST) Received: from [IPv6:2a00:23c6:2d80:b900:91c2:778c:9546:84af] (unknown [IPv6:2a00:23c6:2d80:b900:91c2:778c:9546:84af]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id C978CE4E44; Tue, 19 Nov 2019 09:17:19 +0000 (UTC) To: "Salz, Rich" , "tls@ietf.org" References: <4431e115-64ff-b660-87bb-b8bf3aa4ea15@openssl.org> <2D5349E3-D9FE-44B6-8A40-1F1AE1863A46@akamai.com> From: Matt Caswell Message-ID: Date: Tue, 19 Nov 2019 09:17:17 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <2D5349E3-D9FE-44B6-8A40-1F1AE1863A46@akamai.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Is Ed25519/Ed448 ok for use in DTLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2019 09:17:25 -0000 On 19/11/2019 00:41, Salz, Rich wrote: > As 8422 says "DTLS-OK" and since Yoav is both an author of the RFC and one of the registry experts, I think he needs to reply here. > >> My guess is either: >> 1) The registry is in error and they should not have Y against them >> or > > 2) The intent behind RFC 8442 was that it should apply to DTLS but it > was missed in error. > > #1 is the simple fix, but it seems wrong. #2 could *probably* be fixed with an errata, but hard to do in a way that doesn't make the changes invasive. Sorry, that should have been RFC 8422 above (not 8442). Looking at 8422 it seems to me that starting from the title and all the way through it is exclusively talking about TLS and not DTLS. So, on reflection, I think fixing it via errata doesn't seem feasible to me. Perhaps a new RFC could be fairly easily written to apply the changes to DTLS too. Either way, it seems to me that the current state of the registry doesn't match what the RFCs state. This is quite confusing - I discovered this issue because of a question to the OpenSSL users list asking why EdDSA certificates could not be used in an OpenSSL DTLS connection when the registry says that they are allowed. Therefore it seems to me that the right answer is to correct the registry - at least for now. Even if there is a subsequent RFC that changes it back again. Is there a formal process for reporting registry errata? Or is it just a case of reporting it direct to the assigned experts? Matt From nobody Tue Nov 19 01:20:49 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C6F12089B for ; Tue, 19 Nov 2019 01:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.405 X-Spam-Level: X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.244, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rN9IofPGz0lq for ; Tue, 19 Nov 2019 01:20:43 -0800 (PST) Received: from mail-vs1-f44.google.com (mail-vs1-f44.google.com [209.85.217.44]) (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 87EA21208D8 for ; Tue, 19 Nov 2019 01:20:16 -0800 (PST) Received: by mail-vs1-f44.google.com with SMTP id m9so13714533vsq.7 for ; Tue, 19 Nov 2019 01:20:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=IYZmEnGepBRO0VX8548IH1b2vVK6on0wNGxT/DnCviM=; b=M194MnFMUfE6/QMawtrhnN5kv1q2L1ovfgCJ1WtLkUr9wl0QK5Pvc0ur0i+2o0ruf0 W+RPoz9EKPT+eB9x/pDC5otj4ZkxQsomGihEx1+u2uJX6FsLnydm1Scnli0hVCbmF6fL eQcdETr7yzCHEdGhqkiwacrmKG215FY9dyiJAh2xGLzI7fHkzVTndrPF658eqcEh9nR3 GFYjDIWKdVPCLz1G1nV4R08Z5jcvqjHHQMoTDOh6kMAw4pLBCPhy8/GGlOKQE+70j8UR RtkPOwGJ8yD9TEotK4nlcKSHSOBNdd7bUAbGlTQPdrvYvC9FEB9i5W5bd1mxDjYbBgxd fOXQ== X-Gm-Message-State: APjAAAUiEehZH+SFEr7vXv2GZD6xcnEmcV3JU0CvAUegQBkEvgDjG4G+ aNMryBU7ADPFK2Hu3ovXT2u/orysYFZO7UXPu0fXS1fd X-Google-Smtp-Source: APXvYqwms/MkXcV3NdVP79Y/XgQMrbeYfdtBY9Q74NSxm1uL9lgCkwto/GuTAjqkzjJXvcH2e7MF8KYLgWsAWVgqYsc= X-Received: by 2002:a67:fd53:: with SMTP id g19mr11045344vsr.169.1574155214971; Tue, 19 Nov 2019 01:20:14 -0800 (PST) MIME-Version: 1.0 References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <20191116100546.GP34850@straasha.imrryr.org> <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> <20191117002249.GV34850@straasha.imrryr.org> In-Reply-To: <20191117002249.GV34850@straasha.imrryr.org> From: Daniel Migault Date: Tue, 19 Nov 2019 17:20:03 +0800 Message-ID: To: tls Content-Type: multipart/alternative; boundary="00000000000068e98c0597af9253" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2019 09:20:47 -0000 --00000000000068e98c0597af9253 Content-Type: text/plain; charset="UTF-8" Hi, Just to followup the discussion. I support Viktor,'s proposal as it provides the ability to the client to specify what it wants rather than let the server guess. What I am wondering is whether we are catching all possible client "policies" or whether we should consider some additional reserved values. Typically I do not see case where 200 tickets may be requested, so we may have some place for reserved bits if needed. I see my comment of how tickets are generated as complementary. Yours, Daniel On Sun, Nov 17, 2019 at 8:23 AM Viktor Dukhovni wrote: > On Sat, Nov 16, 2019 at 03:59:53PM -0800, Benjamin Kaduk wrote: > > > > That also works, effectively treat 0xff as "-1", but all other > > > values as non-negative, with 0 a request for re-use. An isomorphic > > > encoding, but without the "-1". > > > > [Jeremy had a more eloquent description of the vague sketch of an idea > that I had in my head] > > Jeremy's "isomorphic" encoding works fine for me, and is likely less > confusing. > So, FWIW, it has my support. Fleshing it out a bit more, I am proposing: > > - 0xff => send no tickets > > - 0x00 => reuse requested: > + send no tickets if presented ticket is accepted and reusable > + send one ticket if presented ticket is accepted, but is not > reusable > (expired, or reuse is not allowed). > + Also send one ticket if session could not be resumed and a full > handshake was performed. Clients that reuse tickets don't need a > separate one for each session, so one per full handshake should > suffice. > > - 0x01-0xfe => client wants single-use tickets: > + send up to that many tickets on full handshake, > + however, generally send just 1 ticket on resumption, or when > replacing tickets during long-lived connections. This helps to > reduce chronic ticket "oversupply". > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000068e98c0597af9253 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Just to followup t= he discussion. I support Viktor,'s=C2=A0proposal as it provides the abi= lity to the client to specify what it wants rather than let the server gues= s. What I am wondering is whether we are catching all possible client "= ;policies" or whether we should consider some additional reserved valu= es. Typically I do not see case where 200 tickets may be requested, so we m= ay have some place for reserved bits if needed.=C2=A0

<= /div>
I see my comment of how tickets are generated as complementary.

Yours,=C2=A0
Daniel

<= div>

On Sun, Nov 17, 2019 at 8:23 AM Viktor Dukhovni <ietf-dane@dukhovni= .org> wrote:
On Sat, Nov 16, 2019 at 03:59:53PM -0800, Benjamin Kaduk wrote:

> > That also works, effectively treat 0xff as "-1", but al= l other
> > values as non-negative, with 0 a request for re-use.=C2=A0 An iso= morphic
> > encoding, but without the "-1".
>
> [Jeremy had a more eloquent description of the vague sketch of an idea= that I had in my head]

Jeremy's "isomorphic" encoding works fine for me, and is like= ly less confusing.
So, FWIW, it has my support.=C2=A0 Fleshing it out a bit more, I am proposi= ng:

=C2=A0 =C2=A0 - 0xff =3D> send no tickets

=C2=A0 =C2=A0 - 0x00 =3D> reuse requested:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + send no tickets if presented ticket is accept= ed and reusable
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + send one ticket if presented ticket is accept= ed, but is not reusable
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (expired, or reuse is not allowed).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + Also send one ticket if session could not be = resumed and a full
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 handshake was performed.=C2=A0 Clients t= hat reuse tickets don't need a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 separate one for each session, so one pe= r full handshake should
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 suffice.

=C2=A0 =C2=A0 - 0x01-0xfe =3D> client wants single-use tickets:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + send up to that many tickets on full handshak= e,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + however, generally send just 1 ticket on resu= mption, or when
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 replacing tickets during long-lived conn= ections.=C2=A0 This helps to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 reduce chronic ticket "oversupply&q= uot;.

--
=C2=A0 =C2=A0 Viktor.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000068e98c0597af9253-- From nobody Tue Nov 19 01:21:10 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335F312091A for ; Tue, 19 Nov 2019 01:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 C0LFA001SS5m for ; Tue, 19 Nov 2019 01:20:59 -0800 (PST) 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 359101208F7 for ; Tue, 19 Nov 2019 01:20:52 -0800 (PST) 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 xAJ9HPmv027730; Tue, 19 Nov 2019 09:20:51 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=GcWTZqxYs6uaOYsgDuWnsArRS4Bve5B3mZlWdOZgWZ4=; b=UIfgLuP4duh8dCSgS6BAv+XVN4pLf0L36WLtLZBuZvFIzlhTx/v3sw01/dIVHnWjoiyz w9xUpkZop/ogwUvDlkgDuk/WqmV5VeZhFOHaeUYoMDlmkf+RnGAWa9sYde+72LFN5adk 2uKhGMl6+vPgl1YPwRWjC0lNREfhFC1EJUXurnA+thDaC0fvgcjnAev0zNAofV3J1jIZ hXa0QvUmIcaD4FAsDo12WG8euN5Qyzbz1yJF7C7k3yTXhY19kgfBo71VxbmXexNSB8Q0 t87J/50Pydt5AUI4Q8d+eI6PVOx8eJNcDfM0FKCH6rKkKvRuvXu3aUZPkA9+BGFM2yeH Tw== Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2wag31m11s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 Nov 2019 09:20:51 +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 xAJ9HIWR005602; Tue, 19 Nov 2019 04:20:50 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint4.akamai.com with ESMTP id 2wadb39tru-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 19 Nov 2019 04:20:50 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Nov 2019 04:20:43 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Tue, 19 Nov 2019 04:20:43 -0500 From: "Salz, Rich" To: Matt Caswell , "tls@ietf.org" Thread-Topic: [TLS] Is Ed25519/Ed448 ok for use in DTLS1.2? Thread-Index: AQHVnjBEKs2RQ4j7hkK2gB9KCnqbQ6eRhYCAgABX6AD//8pQgIAA4/+AgACHEQA= Date: Tue, 19 Nov 2019 09:20:43 +0000 Message-ID: <9C1F09AE-D563-49A0-8D6E-150937E230E5@akamai.com> References: <4431e115-64ff-b660-87bb-b8bf3aa4ea15@openssl.org> <2D5349E3-D9FE-44B6-8A40-1F1AE1863A46@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191110 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.218.224] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-19_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=600 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911190088 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-19_02:2019-11-15,2019-11-19 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 priorityscore=1501 malwarescore=0 mlxlogscore=569 adultscore=0 mlxscore=0 bulkscore=0 lowpriorityscore=0 clxscore=1015 spamscore=0 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911190087 Archived-At: Subject: Re: [TLS] Is Ed25519/Ed448 ok for use in DTLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2019 09:21:07 -0000 PiAgICBJcyB0aGVyZSBhIGZvcm1hbCBwcm9jZXNzIGZvciByZXBvcnRpbmcgcmVnaXN0cnkgZXJy YXRhPyBPciBpcyBpdCBqdXN0IGENCiAgICBjYXNlIG9mIHJlcG9ydGluZyBpdCBkaXJlY3QgdG8g dGhlIGFzc2lnbmVkIGV4cGVydHM/DQogIA0KUmVwb3J0IGl0IHRvIElBTkEgKGlhbmFAaWFuYS5v cmcpIHdobyB3aWxsIHBhc3MgaXQgdG8gdGhlIGV4cGVydHMuDQoNCkkgd291bGQgc3VnZ2VzdCB3 YWl0aW5nIGZvciBZb2F2IHRvIGNvbW1lbnQgZmlyc3QuICBCZWNhdXNlIEkgcHJvbWlzZSB0aGUg ZXhwZXJ0cyB3aWxsIHdhaXQgZm9yIGhpbSBhbnl3YXkgOikNCg0K From nobody Tue Nov 19 18:40:42 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43048120220 for ; Tue, 19 Nov 2019 18:40:40 -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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJg6jhPKH42Z for ; Tue, 19 Nov 2019 18:40:38 -0800 (PST) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 920D41201E0 for ; Tue, 19 Nov 2019 18:40:38 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id xAK2WKL3014863; Tue, 19 Nov 2019 18:40:35 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=h1YJUCykqHBRCu/rtSfRGwPf39WpOGIny/y99WoGKyY=; b=kcB2p86o4sHHaYwc7bH1VVb/DiPROcGoXDr8JxraOu7TqzW7rAyNoOpYrrBKFbd4U4/s aJsvZLCTLszLjmiBqiwlR0UbBH8S/IIDMGgo3n61YXfizwOqTCptsHY8gbHtq1wJ9Elj GGNGzfegwivvK27bgyCz13kVzpGhX+q5WOdp4fEBv9wKiPxsbwVUWW+cqEtsX2ko8eT9 12uc/cTf+47LNhCq9hpU+b0e4BPeshX5x6Vhtew3QvXqdl9cmn8qNkJqrE7rDP1MaHN0 frXBTJqV7Amh5pJsbXzIo4V/Gu4tW7mCyaF1uDSxekKYT6wnsrDeKanE8+wALBa+F+mN 9w== Received: from sg3-postinop-sz01.asia.apple.com (sg3-postinop-sz01.asia.apple.com [17.84.80.96]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2wagyykm4x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 19 Nov 2019 18:40:35 -0800 Received: from sng-mmpp-sz01.asia.apple.com (sng-mmpp-sz01.asia.apple.com [17.84.80.62]) by sg3-postinop-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q1800LO7Y3LF000@sg3-postinop-sz01.asia.apple.com>; Wed, 20 Nov 2019 10:40:33 +0800 (+08) Received: from process_milters-daemon.sng-mmpp-sz01.asia.apple.com by sng-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q1800D00VMCYJ00@sng-mmpp-sz01.asia.apple.com>; Wed, 20 Nov 2019 10:40:33 +0800 (+08) X-Va-A: X-Va-T-CD: ae695c802e0d396617b4b2b2108e7c6a X-Va-E-CD: 7f7e14a8463c26a765e1ab3769b5d901 X-Va-R-CD: 6a2bc58b15f70a522f15c151e4c2a302 X-Va-CD: 0 X-Va-ID: 0f31403d-b657-4504-84a6-95cf2f09a7e9 X-V-A: X-V-T-CD: ae695c802e0d396617b4b2b2108e7c6a X-V-E-CD: 7f7e14a8463c26a765e1ab3769b5d901 X-V-R-CD: 6a2bc58b15f70a522f15c151e4c2a302 X-V-CD: 0 X-V-ID: 7b958fb2-e44f-4169-a178-618c64a59bce X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-19_08:,, signatures=0 Received: from [17.235.155.28] by sng-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q1800MHIY3DVP80@sng-mmpp-sz01.asia.apple.com>; Wed, 20 Nov 2019 10:40:28 +0800 (+08) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_5F98897B-09E2-4B9A-9863-380306F7FCF8" MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Date: Wed, 20 Nov 2019 10:40:20 +0800 In-reply-to: Cc: tls To: Daniel Migault References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> <0469b84c-3009-427a-99ca-e7f6817f0b6c@www.fastmail.com> <20191116100546.GP34850@straasha.imrryr.org> <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> <20191117002249.GV34850@straasha.imrryr.org> X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-19_08:, , signatures=0 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 02:40:40 -0000 --Apple-Mail=_5F98897B-09E2-4B9A-9863-380306F7FCF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 19, 2019, at 5:20 PM, Daniel Migault = wrote: >=20 > Hi,=20 >=20 > Just to followup the discussion. I support Viktor,'s proposal as it = provides the ability to the client to specify what it wants rather than = let the server guess. What I am wondering is whether we are catching all = possible client "policies" or whether we should consider some additional = reserved values. Typically I do not see case where 200 tickets may be = requested, so we may have some place for reserved bits if needed.=20 >=20 > I see my comment of how tickets are generated as complementary. >=20 > Yours,=20 > Daniel >=20 >=20 >=20 > On Sun, Nov 17, 2019 at 8:23 AM Viktor Dukhovni = > wrote: > On Sat, Nov 16, 2019 at 03:59:53PM -0800, Benjamin Kaduk wrote: >=20 > > > That also works, effectively treat 0xff as "-1", but all other > > > values as non-negative, with 0 a request for re-use. An = isomorphic > > > encoding, but without the "-1". > >=20 > > [Jeremy had a more eloquent description of the vague sketch of an = idea that I had in my head] >=20 > Jeremy's "isomorphic" encoding works fine for me, and is likely less = confusing. > So, FWIW, it has my support. Fleshing it out a bit more, I am = proposing: >=20 > - 0xff =3D> send no tickets >=20 > - 0x00 =3D> reuse requested: > + send no tickets if presented ticket is accepted and reusable > + send one ticket if presented ticket is accepted, but is not = reusable > (expired, or reuse is not allowed). > + Also send one ticket if session could not be resumed and a = full > handshake was performed. Clients that reuse tickets don't = need a > separate one for each session, so one per full handshake = should > suffice. >=20 > - 0x01-0xfe =3D> client wants single-use tickets: > + send up to that many tickets on full handshake, > + however, generally send just 1 ticket on resumption, or when > replacing tickets during long-lived connections. This helps = to > reduce chronic ticket "oversupply". Having a recommendation to generally just send one ticket doesn't = address the motivating use case for the document, which is Happy = Eyeballs (connection racing). Having multiple tickets is required in a = steady state, so we shouldn't recommend against that. Any client that wants to only do the reuse case can just not use this = extension. Thanks, Tommy >=20 > --=20 > Viktor. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_5F98897B-09E2-4B9A-9863-380306F7FCF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Nov 19, 2019, at 5:20 PM, Daniel Migault <daniel.migault=3D40ericsson.com@dmarc.ietf.org> = wrote:

Hi, 

Just to followup the = discussion. I support Viktor,'s proposal as it provides the ability = to the client to specify what it wants rather than let the server guess. = What I am wondering is whether we are catching all possible client = "policies" or whether we should consider some additional reserved = values. Typically I do not see case where 200 tickets may be requested, = so we may have some place for reserved bits if = needed. 

I see my comment of how tickets are generated as = complementary.

Yours, 
Daniel



On Sun, Nov = 17, 2019 at 8:23 AM Viktor Dukhovni <ietf-dane@dukhovni..org> wrote:
On Sat, Nov 16, 2019 at 03:59:53PM = -0800, Benjamin Kaduk wrote:

> > That also works, effectively treat 0xff as "-1", but all = other
> > values as non-negative, with 0 a request for re-use.  An = isomorphic
> > encoding, but without the "-1".
>
> [Jeremy had a more eloquent description of the vague sketch of an = idea that I had in my head]

Jeremy's "isomorphic" encoding works fine for me, and is likely less = confusing.
So, FWIW, it has my support.  Fleshing it out a bit more, I am = proposing:

    - 0xff =3D> send no tickets

    - 0x00 =3D> reuse requested:
        + send no tickets if presented ticket is = accepted and reusable
        + send one ticket if presented ticket is = accepted, but is not reusable
          (expired, or reuse is not = allowed).
        + Also send one ticket if session could not = be resumed and a full
          handshake was performed.  = Clients that reuse tickets don't need a
          separate one for each session, so one = per full handshake should
          suffice.

    - 0x01-0xfe =3D> client wants single-use tickets:
        + send up to that many tickets on full = handshake,
        + however, generally send just 1 ticket on = resumption, or when
          replacing tickets during long-lived = connections.  This helps to
          reduce chronic ticket = "oversupply".
Having a recommendation to generally just send one = ticket doesn't address the motivating use case for the document, which = is Happy Eyeballs (connection racing). Having multiple tickets is = required in a steady state, so we shouldn't recommend against = that.

Any client that wants to only = do the reuse case can just not use this extension.

Thanks,
Tommy

--
    Viktor.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS = mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

= --Apple-Mail=_5F98897B-09E2-4B9A-9863-380306F7FCF8-- From nobody Tue Nov 19 19:48:16 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E840120236 for ; Tue, 19 Nov 2019 19:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 kf8-o6748cg6 for ; Tue, 19 Nov 2019 19:48:13 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686AB120232 for ; Tue, 19 Nov 2019 19:48:13 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id A03EB331A79; Tue, 19 Nov 2019 22:48:12 -0500 (EST) Date: Tue, 19 Nov 2019 22:48:12 -0500 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20191120034812.GQ34850@straasha.imrryr.org> Reply-To: tls@ietf.org References: <20191116100546.GP34850@straasha.imrryr.org> <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> <20191117002249.GV34850@straasha.imrryr.org> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 03:48:15 -0000 On Wed, Nov 20, 2019 at 10:40:20AM +0800, Tommy Pauly wrote: > > - 0x01-0xfe => client wants single-use tickets: > > + send up to that many tickets on full handshake, > > + however, generally send just 1 ticket on resumption, or when > > replacing tickets during long-lived connections. This helps to > > reduce chronic ticket "oversupply". > > Having a recommendation to generally just send one ticket You left out the key qualification: "on resumption". Now perhaps that strategy is only needed in the *absence* of any signal from the client, and with the extension the onus is perhaps on the client to send "1" once it has enough tickets, in which case the server does not need to apply the heuristic that helps it to avoid chronic ticket oversupply. In which case, the "generally send just 1" can be left out, it is a side comment, not essential to the overall proposal. Somebody should try to avoid ending up with N new tickets after every connection, but in could well be the client. > doesn't address the motivating use case for the document, which is Happy > Eyeballs (connection racing). Having multiple tickets is required in a steady > state, so we shouldn't recommend against that. > > Any client that wants to only do the reuse case can just not use this extension. No, the extension is *very* useful to such clients, to signal to the server that that's what they want to do, so that the server then only issues new tickets when necessary. -- Viktor. From nobody Tue Nov 19 19:53:24 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAEF912002E for ; Tue, 19 Nov 2019 19:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHcr2SJUmM1c for ; Tue, 19 Nov 2019 19:53:22 -0800 (PST) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 1B5ED120232 for ; Tue, 19 Nov 2019 19:53:22 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id xAK3lp4l040276 for ; Tue, 19 Nov 2019 19:53:21 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : content-type : content-transfer-encoding : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=lIhk5Ky59lbbjNrYyJ9iue+KsccymC8FNwL6gnHGQ3Y=; b=VTQFoCBXN6xmXISZ+W7te+1jN4mqGlwlFfa89VLcZCVuvqYs/mX0ChS71SWgz6zpw/P8 aibShuf5M7F5XoPMHklOADMlIUet9MIh6lqmmSAcAl9hhBYNg8OGGbt43+zlJc2wDX2G AvKmBuybF31Ufp5xgeeSvhat+KC3rVBuA0IyocvczwCj4yva1v4zXBwq0GbocJssZ+db /2HYARpgsS5zqyJD1dwwM1cOwVee0+I9ANZke6wQLmews0o0tl4k4wktTznh8yscSlHC RRCAhNGrfqTM/NBIyjRCQpXtRB6m6DE7e/nK+tcabTWHaUnunhdmmhFFK8hsK0KYS+rT TQ== Received: from sg3-postinop-sz01.asia.apple.com (sg3-postinop-sz01.asia.apple.com [17.84.80.96]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2wagyymhfa-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 19 Nov 2019 19:53:20 -0800 Received: from sg3-mmpp-sz01.asia.apple.com (sg3-mmpp-sz01.asia.apple.com [17.84.80.93]) by sg3-postinop-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q1900KG21GT4D00@sg3-postinop-sz01.asia.apple.com> for tls@ietf.org; Wed, 20 Nov 2019 11:53:17 +0800 (+08) Received: from process_milters-daemon.sg3-mmpp-sz01.asia.apple.com by sg3-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q1900K0015A4T00@sg3-mmpp-sz01.asia.apple.com> for tls@ietf.org; Wed, 20 Nov 2019 11:53:17 +0800 (+08) X-Va-A: X-Va-T-CD: 3ab6cfbeef9fe0930bcbd49ada4d0cd2 X-Va-E-CD: 7f7e14a8463c26a765e1ab3769b5d901 X-Va-R-CD: 6a2bc58b15f70a522f15c151e4c2a302 X-Va-CD: 0 X-Va-ID: 44859b2b-4836-4899-b4db-3777c0255122 X-V-A: X-V-T-CD: 3ab6cfbeef9fe0930bcbd49ada4d0cd2 X-V-E-CD: 7f7e14a8463c26a765e1ab3769b5d901 X-V-R-CD: 6a2bc58b15f70a522f15c151e4c2a302 X-V-CD: 0 X-V-ID: 2a93f7d2-c5f9-4361-9291-b9f254056437 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-19_08:,, signatures=0 Received: from [17.235.144.89] by sg3-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q19005CQ1GOQP20@sg3-mmpp-sz01.asia.apple.com> for tls@ietf.org; Wed, 20 Nov 2019 11:53:14 +0800 (+08) Sender: tpauly@apple.com From: Tommy Pauly Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Date: Wed, 20 Nov 2019 11:53:08 +0800 References: <20191116100546.GP34850@straasha.imrryr.org> <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> <20191117002249.GV34850@straasha.imrryr.org> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> To: tls@ietf.org In-reply-to: <20191120034812.GQ34850@straasha.imrryr.org> Message-id: <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-19_08:, , signatures=0 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 03:53:24 -0000 > On Nov 20, 2019, at 11:48 AM, Viktor Dukhovni = wrote: >=20 > On Wed, Nov 20, 2019 at 10:40:20AM +0800, Tommy Pauly wrote: >=20 >>> - 0x01-0xfe =3D> client wants single-use tickets: >>> + send up to that many tickets on full handshake, >>> + however, generally send just 1 ticket on resumption, or = when >>> replacing tickets during long-lived connections. This = helps to >>> reduce chronic ticket "oversupply". >>=20 >> Having a recommendation to generally just send one ticket >=20 > You left out the key qualification: "on resumption". Now perhaps > that strategy is only needed in the *absence* of any signal from > the client, and with the extension the onus is perhaps on the client > to send "1" once it has enough tickets, in which case the server > does not need to apply the heuristic that helps it to avoid chronic > ticket oversupply. In which case, the "generally send just 1" can > be left out, it is a side comment, not essential to the overall > proposal. That would be great to leave that out. >=20 > Somebody should try to avoid ending up with N new tickets after > every connection, but in could well be the client. Yes, I think that can and ought to be the client. The client is really = the only party that can know how many tickets have been "consumed" by = potentially failed attempts to connect that the server didn't see in = time or got dropped. Thanks, Tommy >=20 >> doesn't address the motivating use case for the document, which is = Happy >> Eyeballs (connection racing). Having multiple tickets is required in = a steady >> state, so we shouldn't recommend against that. >>=20 >> Any client that wants to only do the reuse case can just not use this = extension. >=20 > No, the extension is *very* useful to such clients, to signal to the = server > that that's what they want to do, so that the server then only issues = new > tickets when necessary. >=20 > --=20 > Viktor. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Nov 19 20:58:53 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6DCF12011E for ; Tue, 19 Nov 2019 20:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 Cz7r12xkU2n3 for ; Tue, 19 Nov 2019 20:58:48 -0800 (PST) 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 CB87C12004F for ; Tue, 19 Nov 2019 20:58:48 -0800 (PST) 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 xAK4vnsd032115; Wed, 20 Nov 2019 04:58:47 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=2XLsIam7uvLaR5FAz+Q6UU58XrSFl9i/7FOUhIDVLRw=; b=FzeV5Y42iE8IRyppYgQrXb/b7olzbQgsN7FjR47dDWGeb4i5cIjHKX6311I9jWrY2hFz K/BoMGk9akI1x5dsi8YBRl/3w+9CYfHxVHQTkW/6b0Lazt6CBm5I2msC1ZNWt28mbagS SWQOyANNATnDeJ48YMgYZwnEJ5Okrp/x6KWFNXrAlBbBrYG0SlQ+F2BRezX8hDvMWAem 71UNO7358QGJNxMoxJf3QEkESRt4o+HvjxxhXd4/kTdT9MMhN2QYCVMveQnoTkJEnHSg eEeh4v+F6jt9SvNd8GDx5VNZz0h5gs/D/3L1IWDVIfF7ibA6/y002T8SxG8l3lTEP0qx 7Q== Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2wag31r02d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Nov 2019 04:58:47 +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 xAK4lJol023775; Tue, 19 Nov 2019 23:58:46 -0500 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2wadb3nbxw-1; Tue, 19 Nov 2019 23:58:46 -0500 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 1E5722006A; Wed, 20 Nov 2019 04:58:46 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1iXI4i-0001YE-K6; Tue, 19 Nov 2019 20:58:44 -0800 Date: Tue, 19 Nov 2019 20:58:44 -0800 From: Benjamin Kaduk To: Matt Caswell Cc: "Salz, Rich" , "tls@ietf.org" Message-ID: <20191120045843.GU20609@akamai.com> References: <4431e115-64ff-b660-87bb-b8bf3aa4ea15@openssl.org> <2D5349E3-D9FE-44B6-8A40-1F1AE1863A46@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-19_08:, , 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=879 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911200043 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-19_08:2019-11-15,2019-11-19 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 priorityscore=1501 malwarescore=0 mlxlogscore=890 adultscore=0 mlxscore=0 bulkscore=0 lowpriorityscore=0 clxscore=1015 spamscore=0 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911200044 Archived-At: Subject: Re: [TLS] Is Ed25519/Ed448 ok for use in DTLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 04:58:51 -0000 On Tue, Nov 19, 2019 at 09:17:17AM +0000, Matt Caswell wrote: > > > On 19/11/2019 00:41, Salz, Rich wrote: > > As 8422 says "DTLS-OK" and since Yoav is both an author of the RFC and one of the registry experts, I think he needs to reply here. > > > >> My guess is either: > >> 1) The registry is in error and they should not have Y against them > >> or > > > 2) The intent behind RFC 8442 was that it should apply to DTLS but it > > was missed in error. > > > > #1 is the simple fix, but it seems wrong. #2 could *probably* be fixed with an errata, but hard to do in a way that doesn't make the changes invasive. > > Sorry, that should have been RFC 8422 above (not 8442). > > Looking at 8422 it seems to me that starting from the title and all the > way through it is exclusively talking about TLS and not DTLS. So, on > reflection, I think fixing it via errata doesn't seem feasible to me. > Perhaps a new RFC could be fairly easily written to apply the changes to > DTLS too. > > Either way, it seems to me that the current state of the registry > doesn't match what the RFCs state. This is quite confusing - I > discovered this issue because of a question to the OpenSSL users list > asking why EdDSA certificates could not be used in an OpenSSL DTLS > connection when the registry says that they are allowed. Therefore it > seems to me that the right answer is to correct the registry - at least Quoting from RFC 6347: DTLS 1.0 [DTLS1] was originally defined as a delta from [TLS11]. This document introduces a new version of DTLS, DTLS 1.2, which is defined as a series of deltas to TLS 1.2 [TLS12]. [...] The presumption should be that anything defined for TLS (1.2) is also defined for DTLS (1.2); if you look at things in any of the IANA registries that are marked as DTLS-OK(N), you'll find that they are few and far between, and that there is some (cryptographic) reason why they are incompatible with DTLS usage, which can involve (e.g.) out-of-order delivery and retransmission. E.g., RC4 is a stream cipher and can't handle out-of-order delivery, so TLS_ECDH_RSA_WITH_RC4_128_SHA is DTLS-OK(N). The two signature algorithms in question are pretty bog standard cryptographic primitives, and only get used in the handshake anyway, so it's pretty clear to me that hey are rightly marked as DTLS-OK(Y). I could only find the AUTHj48 discussions in my mail archives; it's possible that the IANA discussions happened before I was responsible AD. If you're still uncertain after the above, we can try to dig up some more history of where the DTLS-OK(Y) came from. -Ben From nobody Tue Nov 19 22:31:56 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0F7120125; Tue, 19 Nov 2019 22:31:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157423151038.5342.9110084648636660959@ietfa.amsl.com> Date: Tue, 19 Nov 2019 22:31:50 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-34.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 06:31:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 Authors : Eric Rescorla Hannes Tschofenig Nagendra Modadugu Filename : draft-ietf-tls-dtls13-34.txt Pages : 52 Date : 2019-11-19 Abstract: This document specifies Version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection/non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-dtls13-34 https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-34 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-34 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 19 22:34:32 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE864120125 for ; Tue, 19 Nov 2019 22:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 KV3vq3WEWdh0 for ; Tue, 19 Nov 2019 22:34:24 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78EBB12004C for ; Tue, 19 Nov 2019 22:34:24 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id g50so27778463qtb.4 for ; Tue, 19 Nov 2019 22:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=vSsk5Mxmd6nPXV9jXyhrdPMcsaVb8hAuajFLpvJ7Ppk=; b=KY2f0WGHACvPaN+U/gAYOC/+zYgYtaxSacRp+qRzbit4nOvs8JrDtH6A11iL42tvcH +VUR2wZlihkbbyZyRzWgW5zrQfimRVJnPcsz4C+ZLBPowXMtvNbEWMJcmfmQuAW8nGrg GfiZ85Ckh/RCZ9DupkyuNiptz+o7z7Iw5Mp74= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=vSsk5Mxmd6nPXV9jXyhrdPMcsaVb8hAuajFLpvJ7Ppk=; b=Rt8Gc+CclgWQmpAlKdHu8JU8oq8PdTMKg/aLI+QGijpb43EVXd89gYXBEi9/pQEutw M+AQ6hNL+ESpelvGz7Rn1bhtzLrVDrocYdVYuHPcaKK5nh9AI5hzvLIDUq2kcCSycn8O ydbEu19Udl94priKrSBsH7CyVU2Q5GU0EiKlAZz2HIQyFrc8ZKb7hrPs9p6+9TfWrFmO 3t/G2mJvZz/jWgl0jnymCZmo8faNRkZtDlLs5HzKcXfoECq9ZXyMVRVjQML6OU9TZTJ5 rDVH/CGOjen/5VSDfSINrYRsfW7reKWPzhSrmPiPGnhoRhLRre8GfYrKCsnxQKTy95EW Zyzw== X-Gm-Message-State: APjAAAUX++mfT1ohxe7U/oI8DTy8EIT0OVK4o9DYxOk7IEwf6T6tTopc llZSNw85z3gAvfJyRuQ15dcEc7NPPjjw5A== X-Google-Smtp-Source: APXvYqx1mZsf2QnlF1IvWTXSkpgGekT99y8hFFeCGuQlpLbZL17vYhRMvBKwU91EQugh36Crapb85A== X-Received: by 2002:ac8:60d9:: with SMTP id i25mr1153025qtm.26.1574231663349; Tue, 19 Nov 2019 22:34:23 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:189f:f4c9:cf51:7c93? ([2001:67c:370:128:189f:f4c9:cf51:7c93]) by smtp.gmail.com with ESMTPSA id j3sm11185929qke.25.2019.11.19.22.34.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Nov 2019 22:34:22 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 20 Nov 2019 14:34:17 +0800 References: <12219D44-9FB9-4B55-9B86-6B9AB4FCC5C5@sn3rd.com> To: TLS List In-Reply-To: <12219D44-9FB9-4B55-9B86-6B9AB4FCC5C5@sn3rd.com> Message-Id: <54F82BCD-4D4A-4935-AB8C-580634759AD4@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] 2nd WGLC for draft-ietf-tls-dtls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 06:34:28 -0000 I should have noted sometime ago that the WGLC has concluded. The final = issues have been addressed and I will forward the message to Ben for his = AD review. spt > On Oct 14, 2019, at 09:13, Sean Turner wrote: >=20 > This is the second working group last call for the "The Datagram = Transport > Layer Security (DTLS) Protocol Version 1.3" draft available at > https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/. Please > review the document and send your comments to the list by 2359 UTC on > 28 October 2019. >=20 > Please note that we are now on at version -33. -30 was the subject of = the > 1st WGLC and the WG should focus on changes introduced since -30 > version. Diffs between -30 and -33 can be found at: > = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tls-dtls13-30&url2=3Ddraft-= ietf-tls-dtls13-33 >=20 > Note the the GH repo for this draft can be found at: > https://github.com/tlswg/dtls13-spec >=20 > Thanks, > Chris, Joe, and Sean From nobody Tue Nov 19 22:36:06 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C12D8120152; Tue, 19 Nov 2019 22:36:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.110.1 Auto-Submitted: auto-generated Precedence: bulk Cc: Sean Turner , iesg-secretary@ietf.org, tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org Message-ID: <157423176478.5287.16826429674428476284.idtracker@ietfa.amsl.com> Date: Tue, 19 Nov 2019 22:36:04 -0800 Archived-At: Subject: [TLS] Publication has been requested for draft-ietf-tls-dtls13-34 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 06:36:05 -0000 Sean Turner has requested publication of draft-ietf-tls-dtls13-34 as Proposed Standard on behalf of the TLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/ From nobody Tue Nov 19 22:48:23 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B181C120255 for ; Tue, 19 Nov 2019 22:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 MubXEcPq4qLo for ; Tue, 19 Nov 2019 22:48:21 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02768120125 for ; Tue, 19 Nov 2019 22:48:20 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 416AC331BB8; Wed, 20 Nov 2019 01:48:19 -0500 (EST) Date: Wed, 20 Nov 2019 01:48:19 -0500 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20191120064819.GR34850@straasha.imrryr.org> Reply-To: tls@ietf.org References: <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> <20191117002249.GV34850@straasha.imrryr.org> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 06:48:23 -0000 On Wed, Nov 20, 2019 at 11:53:08AM +0800, Tommy Pauly wrote: > > Somebody should try to avoid ending up with N new tickets after > > every connection, but in could well be the client. > > Yes, I think that can and ought to be the client. The client is really the > only party that can know how many tickets have been "consumed" by potentially > failed attempts to connect that the server didn't see in time or got dropped. OK, in that case, the proposal, is that on resumption, if the proposed extension is *absent*, then the server should generally send just one rather than any larger default. If the extension is present, it is up to the client to not blindly ask for N tickets each time, and generally ask for just one ticket on resumption, once it has sufficiently many tickets for the desired concurrency level, with each parallel thread obtaining one replacement ticket its next connection. As discussed clients that prefer to reuse tickets, can ask for zero, and get 1 only as-needed. If the server supports reuse then all is well. If the server does not support and refuses reuse, then it will issue a new ticket each time and may only accept it once, but the client may have a single-slot cache. If the client makes only one connection at a time, this also works, but if/when its handshakes with the server overlap (a narrow window of ~1RTT) and two connections attempt to resume with the same ticket, one of them will end up doing a full handshake, but only when the client and server applications have incompatible ticket reuse expectations. Some friction when the client and server are mismatched is not the end of the world. So on the whole I think the proposal still works with just a numeric signal (tweaked with 0xff == none and 0 == reuse), and the onus to "generally send 1" on resumption moved to the client (i.e. clients that don't solicit ticket reuse should request only 1 ticket once they have enough). -- Viktor. From nobody Wed Nov 20 03:10:50 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A4D1208BA; Wed, 20 Nov 2019 03:10:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157424824321.30520.5974448174507675480@ietfa.amsl.com> Date: Wed, 20 Nov 2019 03:10:43 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-certificate-compression-06.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 11:10:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : TLS Certificate Compression Authors : Alessandro Ghedini Victor Vasiliev Filename : draft-ietf-tls-certificate-compression-06.txt Pages : 7 Date : 2019-11-20 Abstract: In TLS handshakes, certificate chains often take up the majority of the bytes transmitted. This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-06 https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-certificate-compression-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 20 05:14:52 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B72B120024 for ; Wed, 20 Nov 2019 05:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=sn3rd.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 6Kg-uMiQgfot for ; Wed, 20 Nov 2019 05:14:48 -0800 (PST) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 876601200E0 for ; Wed, 20 Nov 2019 05:14:48 -0800 (PST) Received: by mail-qv1-xf35.google.com with SMTP id g18so9668663qvp.8 for ; Wed, 20 Nov 2019 05:14:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jPuttcK8NU9Hot41IZ5pqjSweCX3m73O7dbli7BZEk0=; b=ir8ChCLddLOZuNPjJrtDLFdgSod//oSvx6HWPoWiwe9p10A8DMM9hFIusgGNWy0RtI UhmexLe+0HiOeuKgstvLy8Tpvt6cTI6zrfRu6jpSNyWdHF2fkRNC9ElWOMOWYsVcXHg/ V3/yX2lnqY8FKwN/R4CvVRJzfqgxQRUMuY89Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jPuttcK8NU9Hot41IZ5pqjSweCX3m73O7dbli7BZEk0=; b=hnhKzq5FfOrWGHFWxNXc3ILUlKjX3pViuVE57xnKZHgzc96T+2n9O7U3HOTAdjbjp1 xZwOIKtCsrcPzf4rtCFitNf6xE7ddX7QfD3B5YdlZcKvPPOrjZ1IenZRJtpmwM2pWz0Q BB3SHkaooPjZH1joieiH5aE41XX4yf9z0o7IlcrMkP9zqUgINzcjIaC8PY40pyqLb7XS 67PW03mMMYvibjkuZWh6zd1vAyMJb8D+Fbs3GtUG1R5LFP032MHYkcs+hoCw58iQqxa7 qJutVIci1R8M1mXaJwpJeIKRjWWofF74XkjbAPbBbZwvmcjzMWvsGaZjpg9ImwchHDRG OsLA== X-Gm-Message-State: APjAAAXII4e5llcM4A2IC6+Xexv54l3gXhTanvkjVa7nCoegv6dCxQD0 RviQ4v6t2dLGqdRFo/6EpAkeZw== X-Google-Smtp-Source: APXvYqx6l26q00op9QmSNkhNhI1mcEOd4OkeQu3QF57L5CoR7g4i0u3FFZs1m4LBvqEPhZHGpN1HJw== X-Received: by 2002:a0c:c211:: with SMTP id l17mr2403521qvh.55.1574255687528; Wed, 20 Nov 2019 05:14:47 -0800 (PST) Received: from [5.5.33.48] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id k16sm10265815qki.78.2019.11.20.05.14.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Nov 2019 05:14:46 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: <157424824321.30520.5974448174507675480@ietfa.amsl.com> Date: Wed, 20 Nov 2019 21:14:41 +0800 Cc: TLS List Content-Transfer-Encoding: quoted-printable Message-Id: <4A755C4E-6F7A-4A9F-92A1-E27E0FC95B33@sn3rd.com> References: <157424824321.30520.5974448174507675480@ietfa.amsl.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-06.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2019 13:14:50 -0000 This version, I believe addresses your AD review comments. spt > On Nov 20, 2019, at 19:10, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Layer Security WG of the = IETF. >=20 > Title : TLS Certificate Compression > Authors : Alessandro Ghedini > Victor Vasiliev > Filename : draft-ietf-tls-certificate-compression-06.txt > Pages : 7 > Date : 2019-11-20 >=20 > Abstract: > In TLS handshakes, certificate chains often take up the majority of > the bytes transmitted. >=20 > This document describes how certificate chains can be compressed to > reduce the amount of data transmitted and avoid some round trips. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-06 > = https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compressi= on-06 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-certificate-compression= -06 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Nov 20 18:36:00 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6951208AA for ; Wed, 20 Nov 2019 18:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=Yjtm1ZDV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ucp07IYt 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 VUWNWLnvyToE for ; Wed, 20 Nov 2019 18:35:57 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5017D120077 for ; Wed, 20 Nov 2019 18:35:57 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A0021223A4 for ; Wed, 20 Nov 2019 21:35:56 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 20 Nov 2019 21:35:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=WISig9c6T/orormqrZWi/xi32HD/JOO ydrOc/8XO1kU=; b=Yjtm1ZDV2JpY8UmZUYlyuyyTdQYNecw/wDjr+EVUW82VGyU +S3p7zCVM9tw5+H2wl7XNI1K8vBnmiWwO9yQKRpfmU6+8oViIuzPjjpiFHqsIkB2 unurt4lC3dwYDGTlh0z08U8p1uNAsRkAJLfzQy4C+zHFZxxd+rBQ8Cf2aCyDfs5q 30p2OKV/lxYezNyyFwaMOrmJBiOYTnc/+NTUDjob2KI+SaWkT5K9ZxmAV5BoDwqm 5Ygr//FMwoMuU/TSYdwhLF5/DDwfCGM6CM4k+IKBZu/U1S7XnSMzN5cNiRga4xu3 YRmv8EOoENBSZYv4HY29tgxgkEOCvREFrEGPhcQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=WISig9 c6T/orormqrZWi/xi32HD/JOOydrOc/8XO1kU=; b=Ucp07IYt7AjJHLlYbYxGY4 dGk+daDt+1qtdv5vbuEURbgtaomJmJ0X0hueXtardldfoTjS/BCt6kSq++YObg43 Qmuj8N5taOtpIU7yweoXZPtxU0ZWJkmuoTQIcRri+J2snIzg7nXjeTQAOEyudbL2 mhl74RpKhyLcoSXZE5WHlCfvulimOv/Odtt+NbcjHCnhslIOgGfjMWtkFyRfwxVW /TMcavK0k32FkCsD1I3PaCUQ6YSwltKLQ6F3jVpXFQrE67qTC2dc2dUXXiJoRWjx 2ZPhMH38s2Lpa2qKhpFS0JjKXD/k9e5oXCYCmo7T3+jwLNSHUhmRlxA4sI118ijA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehuddggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehloh ifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 25253E00A3; Wed, 20 Nov 2019 21:35:56 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <430940ff-60f0-4ddd-9d71-9fe8b8ca9cae@www.fastmail.com> References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> <20191118225035.GS20609@akamai.com> <430940ff-60f0-4ddd-9d71-9fe8b8ca9cae@www.fastmail.com> Date: Thu, 21 Nov 2019 10:35:34 +0800 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] =?utf-8?q?Secdir_last_call_review_of_draft-ietf-tls-export?= =?utf-8?q?ed-authenticator-09?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 02:35:59 -0000 On Tue, Nov 19, 2019, at 11:21, Martin Thomson wrote: > On Tue, Nov 19, 2019, at 10:56, Nick Sullivan wrote: > > The text could be amended to say something like: > > "the allowed extensions for client-generated authenticator requests > > need to have CH listed, and for server-generated authenticator requests > > need to have CR listed" > > The only current extension that supports CR, but not CH is oid_filters, > > which is not relevant to client-initiated authenticator requests. > > I like this resolution. After discussion at the meeting, I think that I would also be OK with a new Client Certificate Request message type. That means defining what extensions are valid, but I think that this can be done quickly by copying Certificate Request and adding SNI. I think that some code might be able to use the tuple of (role, message type) to decide on what extensions are valid, but a new message type would be a more cautious approach. From nobody Wed Nov 20 18:40:31 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C824120840 for ; Wed, 20 Nov 2019 18:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 SVkJ4GlcQeXx for ; Wed, 20 Nov 2019 18:40:29 -0800 (PST) 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 2437912018B for ; Wed, 20 Nov 2019 18:40:29 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xAL2aFl4027349; Thu, 21 Nov 2019 02:40:27 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=FhXlK8ahmhw9pq4Pqw24DIvKJNnRVavbzhg5b2vFt5s=; b=fck/psvKW8UbLMEQ94LY6R4wXmB08dyKFM6o1Z8oHWZYjhHNOZ7vV1FZ9QYYx0DIS0d6 yDNmYjpQ3hPymXYoy7N317UVhfsANRX4XJ7czyuQP0n2XLH+Yk68Bld1SEGJFdLokJFK zFqCzNfDLemkCFu+ZwCj0haT9hiba2Z2b7d8Cd2c4tEX4m8I59+ynkY6kjGBw5i/FrMD 7jKoqD1QWkWYirlap25HzyYcjgm4mv2pMg//raYZvYcbWRhSlzeijJaydQGAeEqGR1jr e2636bwWLRRxT8sVijnRrqJCodulweI44XDUrXQ/TtUKT75J2QRpNXszo9o4Guh7KiT6 Nw== Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2wafywp5us-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Nov 2019 02:40:27 +0000 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAL2aAQp016490; Wed, 20 Nov 2019 21:40:26 -0500 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint8.akamai.com with ESMTP id 2wadb1rvsk-8; Wed, 20 Nov 2019 21:40:24 -0500 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id EA4C480D1A; Thu, 21 Nov 2019 02:40:21 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1iXcOK-00050B-Jx; Wed, 20 Nov 2019 18:40:20 -0800 Date: Wed, 20 Nov 2019 18:40:20 -0800 From: Benjamin Kaduk To: Martin Thomson Cc: tls@ietf.org Message-ID: <20191121024019.GW20609@akamai.com> References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> <20191118225035.GS20609@akamai.com> <430940ff-60f0-4ddd-9d71-9fe8b8ca9cae@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-20_08:, , 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=956 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911210022 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-20_08:2019-11-20,2019-11-20 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 bulkscore=0 spamscore=0 phishscore=0 adultscore=0 lowpriorityscore=0 suspectscore=0 clxscore=1015 mlxscore=0 mlxlogscore=963 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911210021 Archived-At: Subject: Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 02:40:30 -0000 On Thu, Nov 21, 2019 at 10:35:34AM +0800, Martin Thomson wrote: > On Tue, Nov 19, 2019, at 11:21, Martin Thomson wrote: > > On Tue, Nov 19, 2019, at 10:56, Nick Sullivan wrote: > > > The text could be amended to say something like: > > > "the allowed extensions for client-generated authenticator requests > > > need to have CH listed, and for server-generated authenticator requests > > > need to have CR listed" > > > The only current extension that supports CR, but not CH is oid_filters, > > > which is not relevant to client-initiated authenticator requests. > > > > I like this resolution. > > After discussion at the meeting, I think that I would also be OK with a new Client Certificate Request message type. That means defining what extensions are valid, but I think that this can be done quickly by copying Certificate Request and adding SNI. I think that some code might be able to use the tuple of (role, message type) to decide on what extensions are valid, but a new message type would be a more cautious approach. I would also be okay with a ClientCertificateRequest. It may not strictly be needed, but it's the safe/conservative option. -Ben From nobody Wed Nov 20 18:43:49 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996A8120046 for ; Wed, 20 Nov 2019 18:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 QLmwawsstyN8 for ; Wed, 20 Nov 2019 18:43:47 -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 3FE6812018B for ; Wed, 20 Nov 2019 18:43:47 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xAL2hkXR002364; Thu, 21 Nov 2019 02:43:46 GMT 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=AF2nknU1UItEk3RxF6VcMBpe/UETkiw7IPLA/CW3QH4=; b=oGzVMfN2OXp74QCX97KiRpgwyOqRUqVYzCTi+Zl1oYOindbIuB+LkaajBmPFAvobiVF4 a+lcQItjzStYan6CfdMYmMHnctqHgu62BP+hTKuJyFALNuZznNAdqR99TiLDoOs27Y4d Cp7xQSLeYAeQXHMZP1IwNT0S+fIchDuwxyA0DsGrMGRxT9UvOpNqX0xMmFpuxrMXrypD fCJ9FZkXOapQPgv9cR39VKoKWT6PzXsEXztRlvNeukD4OFf9tVIoQeMtCWzPmSt0ZL0Z 6XECNTo8D2g6yRYDlEuTQbYL026mIJ5KqtPmsw1egDqR9Qonjp2vl+yfBaYA6IcP3nGz bg== Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2wcq3dqav6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Nov 2019 02:43:46 +0000 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAL2aAXo016480; Wed, 20 Nov 2019 21:43:44 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint8.akamai.com with ESMTP id 2wadb1ry58-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 20 Nov 2019 21:43:44 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Nov 2019 21:43:29 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Wed, 20 Nov 2019 21:43:29 -0500 From: "Salz, Rich" To: Nick Sullivan CC: "tls@ietf.org" Thread-Topic: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09 Thread-Index: AQHVoBUT1euH8Nr4XEGrD55Dql/E5qeVxKkA Date: Thu, 21 Nov 2019 02:43:28 +0000 Message-ID: <892200AE-3D0A-4AF1-AD40-E3C46BE57F88@akamai.com> References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> <20191118225035.GS20609@akamai.com> <430940ff-60f0-4ddd-9d71-9fe8b8ca9cae@www.fastmail.com> <20191121024019.GW20609@akamai.com> In-Reply-To: <20191121024019.GW20609@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191110 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.216.188] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-20_08:, , 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=833 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911210022 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-20_08:2019-11-20,2019-11-20 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 spamscore=0 impostorscore=0 phishscore=0 suspectscore=0 mlxscore=0 clxscore=1011 bulkscore=0 lowpriorityscore=0 priorityscore=1501 mlxlogscore=802 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911210023 Archived-At: Subject: Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 02:43:48 -0000 TGlrZXdpc2UsIEkgYW0gb2theSB3aXRoIHRoZSAiY291bGQgYmUgYW1lbmRlZCIgdGV4dCBidXQg aW4gZmFjdCBJIHNsaWdodGx5IHByZWZlciBhIG5ldyBtZXNzYWdlIHR5cGUsIGZvciBzYWZldHkg cmVhc29ucy4gDQoNCg== From nobody Wed Nov 20 18:49:28 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F68120840 for ; Wed, 20 Nov 2019 18:49:26 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 7K9OyyeilJ1s for ; Wed, 20 Nov 2019 18:49:24 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 5066612018B for ; Wed, 20 Nov 2019 18:49:24 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id a17so1239299lfi.13 for ; Wed, 20 Nov 2019 18:49:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=drFj5nQS7oHr3YhHYzSbsG5UtpfEdxIcT1fBZbbYr0o=; b=Gfby7W4ZmEXy1rV1QTRk0TnYadnCQYyrO+kK6KwBlVsxYM14bfv5DbAnZ3yeSGtxJw 1ZbLnm0Jy9NhiRcvIrzJ9AalBeVyp+sMweBpd+qkVNiuLp/g8OnWz5FFU7ELXgBkyT4B sDSErmNPi2PmrS2Quv7bn1E2KjHeVsKqflA4dpfIQBs9vqCF5P/zMZgLmVsv1tnJFhUq VNfA/icHFfuJQxdAEaiRQE/sCg+b92Gu09EH5EWPFwOCE4xxuXbLtyUi3K0t5eBBc2bq hWQCffAxT+0LiSjPlBHokF0MihHmT6VRwUCG3uSBya7mSXLaKLoNDUll+xZC+c4iPtag ZVGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=drFj5nQS7oHr3YhHYzSbsG5UtpfEdxIcT1fBZbbYr0o=; b=Gq54M8o/AXEy2KfU3WHTKcLI6/S9tnQbIW1MFDQOBKYC3XzoEb2UHzbqGTs3enOeXm Qu0ONurwSNZLWERMO1Mr2N4gEYwIhRpeWPX7zMtTeqJSqZMm3licGRvJBkyH5LAfueqn ofvK0MjlKGCT4aVWd0J7MA9UgtGY8JHyDHNKz02gs1bykQI0/PBaCMzJOLdllaDKd4Kl 1nAShv1IZl6UoE9CxtSayyYfYvdsnSs4X+rP/kD1GX0yzr4jbJiCV/ZNrxpJA2y+UW8A 517uzVdEKJ2o3gv60ydZ1lKn+7I0ktBZvyN6+E8BvOjQf78cHIydZHs67Cppl+gylHhr uCEQ== X-Gm-Message-State: APjAAAViLqNdv9YdpBEs2bT6JWzNPcnjg+MC1vlQlrV7bzx0QQjVM31g 2Thoso8Ntm0PD5qnHLZ/FDZ91HKPtiwm6hCZT28UKMYrmds= X-Google-Smtp-Source: APXvYqz5se4cIRGJSVG0Y4WJyLrvBF3Hfhn1hT+LUhy62V/v9VjCy4FQp4baMrf+9jUPpxgETnGheqXvlR8pqIrb3Cc= X-Received: by 2002:ac2:455c:: with SMTP id j28mr1076175lfm.184.1574304562336; Wed, 20 Nov 2019 18:49:22 -0800 (PST) MIME-Version: 1.0 From: Eric Rescorla Date: Wed, 20 Nov 2019 18:48:45 -0800 Message-ID: To: "" Content-Type: multipart/alternative; boundary="00000000000034e9450597d258c9" Archived-At: Subject: [TLS] Imported Keys/PR #22 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 02:49:27 -0000 --00000000000034e9450597d258c9 Content-Type: text/plain; charset="UTF-8" To recap what I was saying at the microphone earlier today about selfie/reroute issues, there are actually three separate issues. - A reflection attack where an outside attacker makes the client also act as a server. - A reroute attack where an outside attacker makes the client talk to another server with the same PSK as the intended server. - An attack where an inside attacker impersonates another attacker who also has the PSK. The reflection attack is a special case of the reroute attack. The general solution to the reroute attack is to carry the identities of the communicating endpoints in the handshake [0]; AFAIK it's not necessary to have separate keys, though the current text actually generates distinct keys for each pair as well. It's not a problem to have distinct keys, but it's important to know what piece does what. However, that doesn't generally solve the third class of attack if the inside attacker is configured with the input key rather than the fanned out pairwise keys. -Ekr [0] As John Mattson has pointed out, you can fix just the reflection attack by comparing the random values you have outstanding in each direction. --00000000000034e9450597d258c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To recap what I was saying at the microphone earlier today= about
selfie/reroute issues, there are actually three separate issues.<= br>
- A reflection attack where an outside attacker makes the client als= o
=C2=A0 act as a server.

- A reroute attack where an outside att= acker makes the client talk to
=C2=A0 another server with the same PSK a= s the intended server.

- An attack where an inside attacker imperson= ates another attacker
=C2=A0 who also has the PSK.

The reflection= attack is a special case of the reroute attack.=C2=A0 The
general solut= ion to the reroute attack is to carry the identities of
the communicatin= g endpoints in the handshake [0]; AFAIK it's not
necessary to have s= eparate keys, though the current text actually
generates distinct keys f= or each pair as well.=C2=A0 It's not a problem to
have distinct keys= , but it's important to know what piece does what.

However, that= doesn't generally solve the third class of attack if the
inside att= acker is configured with the input key rather than the
fanned out pairwi= se keys.

-Ekr

[0] As John Mattson has pointed out, you can fi= x just the reflection
attack by comparing the random values you have out= standing in each
direction.




--00000000000034e9450597d258c9-- From nobody Wed Nov 20 19:07:02 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551D7120926 for ; Wed, 20 Nov 2019 19:07:00 -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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLoWY3oy7xZ9 for ; Wed, 20 Nov 2019 19:06:57 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10076.outbound.protection.outlook.com [40.107.1.76]) (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 AEAD5120840 for ; Wed, 20 Nov 2019 19:06:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HoU8kZNboz/JmftcOYLbkBXE2kFBGN8EfSf6QcAFTMN5cd12Dp4Dk5g5ody344MJq1n2Cn/35PW1X7lDfdgjWWM9Bol6z8qeRtyV3nrJ18EFwUFneYNC9lmH5ASN66hd8MHgWXoaG40PpPEBkN7WQljV/sf0vmahntjqFSQdjDk+T3NVkSGdd0Rxj1xnGh758AWKjHgCHKOFViD9Qs8NVU1AYtNqDehE11Wj5QXx1V6rxuwoH7MSIbeiTnpTIbZJHdXPDGb6BU51IFQjHZ1qXYY3JZ4ZJaSb/j+fOUaVS9H4abHSZPrpdsYsNlz96svTlI159R7HsYbMuPk8rgnryA== 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=z43G92napiBDXx2SrwQssffYL6/skpTZcHrxRhMOwwU=; b=gNZFoh/6IWDi9A57k9keUIz83zbTRz6bj9wcBd4pg5r+gdangRwmYbly4nGDOtLvV40mbrVwoDFLC1PUJeT5fFdEAM/rEIhj/pKsb1tn0hH6Lm9GL/iPCAf2yOwLaUuD9mf5MSAAYCOHDSIGesfWCebcfzBcMQuabw7wpBlWMHy9037RSqS1N96so1UX/yJLSd9KiTc1sYBNQ/u8z0hTQ5Dxpcna+4bViIlggEyl1Iu041Zr/TBFuNUZDtTSC0h/Ft4qVkmzaxAl21uNeOd6gnIFQZl2W84iRvLjrePCzbFqcvIJRVikarUfSmo0UQ7sHVcd3Tu6PrwWaYyZ5evj4Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z43G92napiBDXx2SrwQssffYL6/skpTZcHrxRhMOwwU=; b=S9umOv9O+Cy+lgnEt6svTj9JAJ3+gHQUsO0yZUR2ptautEXkddIzbx+493BdIRXT3L/hfUxBPY/rwiAWK/5KPzlHsdIhti0NHozGCLAzAuZR1MAZ9CBbLAw5itjj/SChoW7iyYvLXQu0VDrBD1S60rEziWS6YTe8OFC0BN0+gDo= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2956.eurprd07.prod.outlook.com (10.168.93.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.9; Thu, 21 Nov 2019 03:06:53 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::88e5:d23a:73a5:b78e]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::88e5:d23a:73a5:b78e%6]) with mapi id 15.20.2474.015; Thu, 21 Nov 2019 03:06:53 +0000 From: Mohit Sethi M To: Eric Rescorla , "" Thread-Topic: [TLS] Imported Keys/PR #22 Thread-Index: AQHVoBi3NTPXllLVeUmiLUeHaTJXdw== Date: Thu, 21 Nov 2019 03:06:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [31.133.156.79] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a5fd9368-4a91-4dd4-abda-08d76e2fdc70 x-ms-traffictypediagnostic: HE1PR0701MB2956: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0228DDDDD7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(346002)(376002)(396003)(39860400002)(189003)(199004)(81166006)(316002)(81156014)(14444005)(66066001)(606006)(65806001)(65956001)(99286004)(110136005)(58126008)(186003)(7736002)(478600001)(36756003)(6246003)(26005)(236005)(6512007)(486006)(6306002)(54896002)(31696002)(86362001)(25786009)(2616005)(476003)(11346002)(446003)(14454004)(8936002)(66946007)(76116006)(2906002)(31686004)(966005)(229853002)(8676002)(91956017)(256004)(66556008)(6116002)(64756008)(5660300002)(6506007)(53546011)(6436002)(71200400001)(71190400001)(76176011)(66476007)(66446008)(6486002)(102836004)(3846002)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2956; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: V767AI3kG7V/qOPt6DkcOF+JUE2KtIgjqjiu0NW+iRumldYOkYfcjIpdQ+TZsTa8HrJs6KInpvmZgbIUu2sOo+2euGm703Ko49Leg87nKS/SpRG2j9D4bGx18heMnl/lw2XZyfHpjrVbkVEwjMWYVJ3ipGGDmVb+zZIri9pfXP70xWRSANTBTP+NxDOwy5vsb/8nafgxGS/jlpIyrwVYE6NGREtQ3kL27k0HtvGeYZhxtW87x0Ed3eC0tH8+ApiX5mCWLG4zfbv8f50+/LG5byMsfGTTkK2FmSwpT+RJGlettDOetRk43njbzfJU0kVM+Etl+86pZ8qmJablF9LmlTlHMQPywyfgyRV6oxxOww37MQPtZCbVlgvgVhit9CTCJIy1r76F52jtR6VoWFTRcyGJg+l+KGv/vR0w3oirzbX3SjyFy9ASGgjGfocWJlyDhbRhmD8aBahKE3msxkFf8aX3qcp6usYR3lqjC7srVAk= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_ac62664d0b488384dfd2e90d40a9033bericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a5fd9368-4a91-4dd4-abda-08d76e2fdc70 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2019 03:06:53.4775 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bFoRikU0lNOlgWUciGO6aPRljv2jnK+rlRL9GIMLCbM9qmS+cbKgAOrbgiSLSVH6/bfpT79pgg5K4nRsagnAFgzt3POqlxv/DD1Rrnp6WqY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2956 Archived-At: Subject: Re: [TLS] Imported Keys/PR #22 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 03:07:00 -0000 --_000_ac62664d0b488384dfd2e90d40a9033bericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIHRoYXQgbXkgcHVsbCByZXF1ZXN0IHdhcyBpbmRlZWQgY292ZXJpbmcgdGhlIGRp ZmZlcmVudCBjYXNlcyB5b3UgdGFsayBhYm91dC4gU2VlIGluLWxpbmUgcGllY2VzIG9mIHRleHQg ZnJvbSBteSBwdWxsIHJlcXVlc3Q6DQoNCk9uIDExLzIxLzE5IDEwOjQ4IEFNLCBFcmljIFJlc2Nv cmxhIHdyb3RlOg0KVG8gcmVjYXAgd2hhdCBJIHdhcyBzYXlpbmcgYXQgdGhlIG1pY3JvcGhvbmUg ZWFybGllciB0b2RheSBhYm91dA0Kc2VsZmllL3Jlcm91dGUgaXNzdWVzLCB0aGVyZSBhcmUgYWN0 dWFsbHkgdGhyZWUgc2VwYXJhdGUgaXNzdWVzLg0KDQotIEEgcmVmbGVjdGlvbiBhdHRhY2sgd2hl cmUgYW4gb3V0c2lkZSBhdHRhY2tlciBtYWtlcyB0aGUgY2xpZW50IGFsc28NCiAgYWN0IGFzIGEg c2VydmVyLg0KDQotIEEgcmVyb3V0ZSBhdHRhY2sgd2hlcmUgYW4gb3V0c2lkZSBhdHRhY2tlciBt YWtlcyB0aGUgY2xpZW50IHRhbGsgdG8NCiAgYW5vdGhlciBzZXJ2ZXIgd2l0aCB0aGUgc2FtZSBQ U0sgYXMgdGhlIGludGVuZGVkIHNlcnZlci4NCg0KLSBBbiBhdHRhY2sgd2hlcmUgYW4gaW5zaWRl IGF0dGFja2VyIGltcGVyc29uYXRlcyBhbm90aGVyIGF0dGFja2VyDQogIHdobyBhbHNvIGhhcyB0 aGUgUFNLLg0KDQpUaGUgcmVmbGVjdGlvbiBhdHRhY2sgaXMgYSBzcGVjaWFsIGNhc2Ugb2YgdGhl IHJlcm91dGUgYXR0YWNrLiAgVGhlDQpnZW5lcmFsIHNvbHV0aW9uIHRvIHRoZSByZXJvdXRlIGF0 dGFjayBpcyB0byBjYXJyeSB0aGUgaWRlbnRpdGllcyBvZg0KdGhlIGNvbW11bmljYXRpbmcgZW5k cG9pbnRzIGluIHRoZSBoYW5kc2hha2UgWzBdOyBBRkFJSyBpdCdzIG5vdA0KbmVjZXNzYXJ5IHRv IGhhdmUgc2VwYXJhdGUga2V5cywgdGhvdWdoIHRoZSBjdXJyZW50IHRleHQgYWN0dWFsbHkNCmdl bmVyYXRlcyBkaXN0aW5jdCBrZXlzIGZvciBlYWNoIHBhaXIgYXMgd2VsbC4gIEl0J3Mgbm90IGEg cHJvYmxlbSB0bw0KaGF2ZSBkaXN0aW5jdCBrZXlzLCBidXQgaXQncyBpbXBvcnRhbnQgdG8ga25v dyB3aGF0IHBpZWNlIGRvZXMgd2hhdC4NCg0KU2VsZmllIGF0dGFjayB7e1NlbGZpZX19IGlzIGEg c3BlY2lhbCBjYXNlIG9mIHRoZSByZXJvdXRpbmcgYXR0YWNrIGFnYWluc3QgYSBncm91cCBtZW1i ZXIgdGhhdCBjYW4gYWN0IGJvdGggYXMgVExTIHNlcnZlciBhbmQgY2xpZW50LiBJbiB0aGUgc2Vs ZmllIGF0dGFjaywgYSBtYWxpY2lvdXMgbm9uLW1lbWJlciByZXJvdXRlcyBhIGNvbm5lY3Rpb24g ZnJvbSB0aGUgY2xpZW50IHRvIHRoZSBzZXJ2ZXIgb24gdGhlIHNhbWUgZW5kcG9pbnQuDQoNClJl cm91dGluZyBhbmQgc2VsZmllIGF0dGFja3MgY2FuIGJlIGRldGVjdGVkIGJ5IGJpbmRpbmcgdGhl IFRMUyBoYW5kc2hha2UgdG8gZ2xvYmFsbHkgdW5pcXVlIG5vZGUgaWRlbnRpZmllcnMgdXNpbmcg dGhlIGZvbGxvd2luZyBjb250ZXh0IHN0cmluZzoNCnN0cnVjdCB7DQogICAgICAgb3BhcXVlIGNs aWVudF9pZDwwLi4yXjE2LTE+Ow0KICAgICAgIG9wYXF1ZSBzZXJ2ZXJfaWQ8MC4uMl4xNi0xPjsN CiAgfSBDb250ZXh0Ow0KDQoNCkhvd2V2ZXIsIHRoYXQgZG9lc24ndCBnZW5lcmFsbHkgc29sdmUg dGhlIHRoaXJkIGNsYXNzIG9mIGF0dGFjayBpZiB0aGUNCmluc2lkZSBhdHRhY2tlciBpcyBjb25m aWd1cmVkIHdpdGggdGhlIGlucHV0IGtleSByYXRoZXIgdGhhbiB0aGUNCmZhbm5lZCBvdXQgcGFp cndpc2Uga2V5cy4NCg0KDQpXaGVuIHRoZSBQU0sgaXMgYSBncm91cCBrZXk6IFRvIHByZXZlbnQg bWFsaWNpb3VzIHJlcm91dGluZyBpbiBncm91cHMsIGVhY2ggZW5kcG9pbnQgbmVlZHMgdG8ga25v dyB0aGUgaWRlbnRpZmllciBvZiB0aGUgb3RoZXIgZW5kcG9pbnQgd2l0aCB3aGljaCB0aGV5IHdh bnQgdG8gY29ubmVjdCBhbmQgY29tcGFyZSBpdCB3aXRoIHRoZSBvdGhlciBlbmRwb2ludOKAmXMg aWRlbnRpZmllciBpbiBjb250ZXh0LiBPZiBjb3Vyc2UsIHRoaXMgb25seSBwcmV2ZW50cyBhdHRh Y2tzIGJ5IG5vbi1tZW1iZXJzOyB0aGUgZW5kcG9pbnRzIHRoYXQgc2hhcmUgdGhlIGdyb3VwIGtl eSBjYW4gYWx3YXlzIGltcGVyc29uYXRlIGVhY2ggb3RoZXIuDQoNClRoZSBsYXN0IHBhcnQgd2Fz IGV4cGxpY2l0bHkgcmVmZXJyaW5nIHRvIHRoZSBjYXNlIHRoYXQgeW91IGNhbid0IGRvIG11Y2gg YWJvdXQgaW5zaWRlciBhdHRhY2tzIGluIGdyb3VwIFBTSyBzY2VuYXJpb3MuDQoNCi1Fa3INCg0K WzBdIEFzIEpvaG4gTWF0dHNvbiBoYXMgcG9pbnRlZCBvdXQsIHlvdSBjYW4gZml4IGp1c3QgdGhl IHJlZmxlY3Rpb24NCmF0dGFjayBieSBjb21wYXJpbmcgdGhlIHJhbmRvbSB2YWx1ZXMgeW91IGhh dmUgb3V0c3RhbmRpbmcgaW4gZWFjaA0KZGlyZWN0aW9uLg0KDQoNCkkgZmluZCB0aGUgY3VycmVu dCB0ZXh0IGluIGRyYWZ0LWlldGYtdGxzLWV4dGVybmFsLXBzay1pbXBvcnRlciBpbmFkZXF1YXRl IChhbHRob3VnaCBJIHVuZGVyc3RhbmQgdGhhdCBJIGFtIGluIHRoZSByb3VnaCkuIEZvciBleGFt cGxlLCBpdCBkb2Vzbid0IGV4cGxpY2l0bHkgc2F5IHRoYXQgY2xpZW50X21hYyBzaG91bGQgbmV2 ZXIgYmUgdGhlIHNhbWUgYXMgdGhlIHNlcnZlcl9tYWMuIElmIHRoZSBXRyB3YW50cyB0byBhZGRy ZXNzIHRoaXMgaW4gYSBzZXBhcmF0ZSBkb2N1bWVudCwgdGhlbiBzbyBiZSBpdC4gSSBhbSBoYXBw eSB0byBoZWxwLg0KDQotLU1vaGl0DQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3Jn PG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Rscw0KDQo= --_000_ac62664d0b488384dfd2e90d40a9033bericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <9C274D1483B27443B3FEDE6F3CAB0697@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IiNGRkZG RkYiIHRleHQ9IiMwMDAwMDAiPg0KPHA+SSBiZWxpZXZlIHRoYXQgbXkgcHVsbCByZXF1ZXN0IHdh cyBpbmRlZWQgY292ZXJpbmcgdGhlIGRpZmZlcmVudCBjYXNlcyB5b3UgdGFsayBhYm91dC4gU2Vl IGluLWxpbmUgcGllY2VzIG9mIHRleHQgZnJvbSBteSBwdWxsIHJlcXVlc3Q6PGJyPg0KPC9wPg0K PGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAxMS8yMS8xOSAxMDo0OCBBTSwgRXJpYyBS ZXNjb3JsYSB3cm90ZTo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9 Im1pZDpDQUJjWmVCT012S2hCUFpBV2RPaDYtSHVtazRBPXZycVdoWGFMM0V0WGUyX0JHemE9c0FA bWFpbC5nbWFpbC5jb20iPg0KPGRpdiBkaXI9Imx0ciI+VG8gcmVjYXAgd2hhdCBJIHdhcyBzYXlp bmcgYXQgdGhlIG1pY3JvcGhvbmUgZWFybGllciB0b2RheSBhYm91dDxicj4NCnNlbGZpZS9yZXJv dXRlIGlzc3VlcywgdGhlcmUgYXJlIGFjdHVhbGx5IHRocmVlIHNlcGFyYXRlIGlzc3Vlcy48YnI+ DQo8YnI+DQotIEEgcmVmbGVjdGlvbiBhdHRhY2sgd2hlcmUgYW4gb3V0c2lkZSBhdHRhY2tlciBt YWtlcyB0aGUgY2xpZW50IGFsc288YnI+DQombmJzcDsgYWN0IGFzIGEgc2VydmVyLjxicj4NCjxi cj4NCi0gQSByZXJvdXRlIGF0dGFjayB3aGVyZSBhbiBvdXRzaWRlIGF0dGFja2VyIG1ha2VzIHRo ZSBjbGllbnQgdGFsayB0bzxicj4NCiZuYnNwOyBhbm90aGVyIHNlcnZlciB3aXRoIHRoZSBzYW1l IFBTSyBhcyB0aGUgaW50ZW5kZWQgc2VydmVyLjxicj4NCjxicj4NCi0gQW4gYXR0YWNrIHdoZXJl IGFuIGluc2lkZSBhdHRhY2tlciBpbXBlcnNvbmF0ZXMgYW5vdGhlciBhdHRhY2tlcjxicj4NCiZu YnNwOyB3aG8gYWxzbyBoYXMgdGhlIFBTSy48YnI+DQo8YnI+DQpUaGUgcmVmbGVjdGlvbiBhdHRh Y2sgaXMgYSBzcGVjaWFsIGNhc2Ugb2YgdGhlIHJlcm91dGUgYXR0YWNrLiZuYnNwOyBUaGU8YnI+ DQpnZW5lcmFsIHNvbHV0aW9uIHRvIHRoZSByZXJvdXRlIGF0dGFjayBpcyB0byBjYXJyeSB0aGUg aWRlbnRpdGllcyBvZjxicj4NCnRoZSBjb21tdW5pY2F0aW5nIGVuZHBvaW50cyBpbiB0aGUgaGFu ZHNoYWtlIFswXTsgQUZBSUsgaXQncyBub3Q8YnI+DQpuZWNlc3NhcnkgdG8gaGF2ZSBzZXBhcmF0 ZSBrZXlzLCB0aG91Z2ggdGhlIGN1cnJlbnQgdGV4dCBhY3R1YWxseTxicj4NCmdlbmVyYXRlcyBk aXN0aW5jdCBrZXlzIGZvciBlYWNoIHBhaXIgYXMgd2VsbC4mbmJzcDsgSXQncyBub3QgYSBwcm9i bGVtIHRvPGJyPg0KaGF2ZSBkaXN0aW5jdCBrZXlzLCBidXQgaXQncyBpbXBvcnRhbnQgdG8ga25v dyB3aGF0IHBpZWNlIGRvZXMgd2hhdC48YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwPlNl bGZpZSBhdHRhY2sge3tTZWxmaWV9fSBpcyBhIHNwZWNpYWwgY2FzZSBvZiB0aGUgcmVyb3V0aW5n IGF0dGFjayBhZ2FpbnN0IGEgZ3JvdXAgbWVtYmVyIHRoYXQgY2FuIGFjdCBib3RoIGFzIFRMUyBz ZXJ2ZXIgYW5kIGNsaWVudC4gSW4gdGhlIHNlbGZpZSBhdHRhY2ssIGEgbWFsaWNpb3VzIG5vbi1t ZW1iZXIgcmVyb3V0ZXMgYSBjb25uZWN0aW9uIGZyb20gdGhlIGNsaWVudCB0byB0aGUgc2VydmVy IG9uIHRoZSBzYW1lIGVuZHBvaW50LjwvcD4NCjxwPlJlcm91dGluZyBhbmQgc2VsZmllIGF0dGFj a3MgY2FuIGJlIGRldGVjdGVkIGJ5IGJpbmRpbmcgdGhlIFRMUyBoYW5kc2hha2UgdG8gZ2xvYmFs bHkgdW5pcXVlIG5vZGUgaWRlbnRpZmllcnMgdXNpbmcgdGhlIGZvbGxvd2luZyBjb250ZXh0IHN0 cmluZzoNCjxicj4NCnN0cnVjdCB7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IG9wYXF1ZSBjbGllbnRfaWQmbHQ7MC4uMl4xNi0xJmd0Ozs8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb3BhcXVlIHNlcnZlcl9pZCZsdDswLi4yXjE2LTEm Z3Q7Ozxicj4NCiZuYnNwOyB9IENvbnRleHQ7PGJyPg0KPGJyPg0KPC9wPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOkNBQmNaZUJPTXZLaEJQWkFXZE9oNi1IdW1rNEE9dnJxV2hY YUwzRXRYZTJfQkd6YT1zQUBtYWlsLmdtYWlsLmNvbSI+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQpI b3dldmVyLCB0aGF0IGRvZXNuJ3QgZ2VuZXJhbGx5IHNvbHZlIHRoZSB0aGlyZCBjbGFzcyBvZiBh dHRhY2sgaWYgdGhlPGJyPg0KaW5zaWRlIGF0dGFja2VyIGlzIGNvbmZpZ3VyZWQgd2l0aCB0aGUg aW5wdXQga2V5IHJhdGhlciB0aGFuIHRoZTxicj4NCmZhbm5lZCBvdXQgcGFpcndpc2Uga2V5cy48 YnI+DQo8YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwPldoZW4gdGhlIFBTSyBpcyBhIGdy b3VwIGtleTogVG8gcHJldmVudCBtYWxpY2lvdXMgcmVyb3V0aW5nIGluIGdyb3VwcywgZWFjaCBl bmRwb2ludCBuZWVkcyB0byBrbm93IHRoZSBpZGVudGlmaWVyIG9mIHRoZSBvdGhlciBlbmRwb2lu dCB3aXRoIHdoaWNoIHRoZXkgd2FudCB0byBjb25uZWN0IGFuZCBjb21wYXJlIGl0IHdpdGggdGhl IG90aGVyIGVuZHBvaW504oCZcyBpZGVudGlmaWVyIGluIGNvbnRleHQuIE9mIGNvdXJzZSwgdGhp cyBvbmx5IHByZXZlbnRzDQogYXR0YWNrcyBieSBub24tbWVtYmVyczsgdGhlIGVuZHBvaW50cyB0 aGF0IHNoYXJlIHRoZSBncm91cCBrZXkgY2FuIGFsd2F5cyBpbXBlcnNvbmF0ZSBlYWNoIG90aGVy LjwvcD4NCjxwPlRoZSBsYXN0IHBhcnQgd2FzIGV4cGxpY2l0bHkgcmVmZXJyaW5nIHRvIHRoZSBj YXNlIHRoYXQgeW91IGNhbid0IGRvIG11Y2ggYWJvdXQgaW5zaWRlciBhdHRhY2tzIGluIGdyb3Vw IFBTSyBzY2VuYXJpb3MuDQo8YnI+DQo8L3A+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRl PSJtaWQ6Q0FCY1plQk9NdktoQlBaQVdkT2g2LUh1bWs0QT12cnFXaFhhTDNFdFhlMl9CR3phPXNB QG1haWwuZ21haWwuY29tIj4NCjxkaXYgZGlyPSJsdHIiPi1Fa3I8YnI+DQo8YnI+DQpbMF0gQXMg Sm9obiBNYXR0c29uIGhhcyBwb2ludGVkIG91dCwgeW91IGNhbiBmaXgganVzdCB0aGUgcmVmbGVj dGlvbjxicj4NCmF0dGFjayBieSBjb21wYXJpbmcgdGhlIHJhbmRvbSB2YWx1ZXMgeW91IGhhdmUg b3V0c3RhbmRpbmcgaW4gZWFjaDxicj4NCmRpcmVjdGlvbi48YnI+DQo8YnI+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxwPkkgZmluZCB0aGUgY3VycmVudCB0ZXh0IGluIGRyYWZ0LWlldGYtdGxz LWV4dGVybmFsLXBzay1pbXBvcnRlciBpbmFkZXF1YXRlIChhbHRob3VnaCBJIHVuZGVyc3RhbmQg dGhhdCBJIGFtIGluIHRoZSByb3VnaCkuIEZvciBleGFtcGxlLCBpdCBkb2Vzbid0IGV4cGxpY2l0 bHkgc2F5IHRoYXQgY2xpZW50X21hYyBzaG91bGQgbmV2ZXIgYmUgdGhlIHNhbWUgYXMgdGhlIHNl cnZlcl9tYWMuIElmIHRoZSBXRyB3YW50cyB0byBhZGRyZXNzIHRoaXMNCiBpbiBhIHNlcGFyYXRl IGRvY3VtZW50LCB0aGVuIHNvIGJlIGl0LiBJIGFtIGhhcHB5IHRvIGhlbHAuIDxicj4NCjwvcD4N CjxwPi0tTW9oaXQ8YnI+DQo8L3A+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6 Q0FCY1plQk9NdktoQlBaQVdkT2g2LUh1bWs0QT12cnFXaFhhTDNFdFhlMl9CR3phPXNBQG1haWwu Z21haWwuY29tIj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjxicj4NCjxicj4NCjwvZGl2Pg0KPGJy Pg0KPGZpZWxkc2V0IGNsYXNzPSJtaW1lQXR0YWNobWVudEhlYWRlciI+PC9maWVsZHNldD4NCjxw cmUgY2xhc3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNCjxhIGNsYXNzPSJtb3ot dHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRm Lm9yZzwvYT4NCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RsczwvYT4NCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_ac62664d0b488384dfd2e90d40a9033bericssoncom_-- From nobody Wed Nov 20 19:10:16 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B876120924 for ; Wed, 20 Nov 2019 19:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=O/DTSvo3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DAn55pz+ 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 8Ha5PwHDCXeT for ; Wed, 20 Nov 2019 19:10:13 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709D01207FF for ; Wed, 20 Nov 2019 19:10:13 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 957C02240D; Wed, 20 Nov 2019 22:10:12 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 20 Nov 2019 22:10:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm3; bh=miFJ37wQ2xoxUrH8+RgNX9Syr8w4gNpzj46PPEirWzw=; b=O/DTSvo3 RKF+A1Lg6MSejPb7cojOGYGG0VoI0IeHxFTejBrEcTH69NIJq/EfK7Y98IS6k/KH c4NCLDUHNn28AEbFXnTge+Dls8QVqPrGBKde112dIlOblCiaefhMYAU1ksPrvrFl SDGoWvkQghNln5fYIDD+Jw8nU8hrckTCiyJagFpq81Xssyu8Pat/dhXP35Czn3RK bEkLYi2PF6FdIH+AJ0txOMAZB+4WAm3nnPprb1KVWJgfagjlDrvCCdj6GAiBifDK nvopC7o21rhv8LjFHyJTdxojxvUWa1wEd//GV0RjEicOU786tzkFTV1zsR2wbnBu oC/rOY5Xqc6jkA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=miFJ37wQ2xoxUrH8+RgNX9Syr8w4g Npzj46PPEirWzw=; b=DAn55pz+g9vYRH8qE9ESg+Y61WtEmSYMXmjZlcqV2f19c 0y98sKso20qvJvXntebzs7exWd+Ix6WMckKfPZcl78yycECemXnFjlUQfKw5YP7Z pYOMD5OEBITnXjYMQ9BiL5ykef+yl8yViNlMLTPceNUYg1rG6MhSQHSAMWEPEasa UwtlmJQCwT6zFrRBsewk9NTIxEelGSzqS0+WdJcp9dutl5Si+8ly/DRo21IU/VOB A4GTLIJEZFuHLCJkuHdU1822NBdE+7kVAQhwKEh9FjMtYCP3y5NmAicsFp+kXza2 UQj6Q3rsuVpNDxSVwGLVBtKTDvKjG/gwqjjeAiysA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehuddgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkfffhvffutgesthdtredtreertdenucfhrhhomhepfdforghrthhi nhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4C14BE00A3; Wed, 20 Nov 2019 22:10:12 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: Date: Thu, 21 Nov 2019 11:09:52 +0800 From: "Martin Thomson" To: "Jonathan Hoyland" , tls@ietf.org Content-Type: text/plain Archived-At: Subject: [TLS] Diversification with multiple inputs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 03:10:15 -0000 If we do the caveman thing and concatenate inputs to HKDF-Extract, what do you think we should do to the rest of the key schedule to ensure that there is diversity? In the PSK importer draft, we use a different binder label. Do we need diversification if there could be multiple inputs later in the key schedule? Or is that a problem unique to PSKs? From nobody Wed Nov 20 19:17:55 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39EA7120929 for ; Wed, 20 Nov 2019 19:17:54 -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 (1024-bit key) header.d=cloudflare.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 Ajya5IT5iX8j for ; Wed, 20 Nov 2019 19:17:51 -0800 (PST) Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (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 7CD8C12022D for ; Wed, 20 Nov 2019 19:17:51 -0800 (PST) Received: by mail-vk1-xa2c.google.com with SMTP id t184so390307vka.1 for ; Wed, 20 Nov 2019 19:17:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=6mxGfSabBegaVY8iPZ1oq/M5W/uRRRlMwB9eiW8ruqM=; b=VrMdReydm4KJ5mbAyJ7Wp8C/figKGcSi1OL53xuPIh3Pn+T3FQiVXQKmIyi3C7/+SK elIZSscktcrCw4YDe0TIK87wL3fPHyl5L7+S1kIY5gM6n4JR2byCJdVKBt0UHPGqSHVk /KEUb4TX+H9s3VjP8RL71rAVH2gDQTLrKEz0o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6mxGfSabBegaVY8iPZ1oq/M5W/uRRRlMwB9eiW8ruqM=; b=Y5DFLI/wcpJPr9JhUnuWNeFhqHI8YlqMDDOoL/udJxPltWCRY/aDMcM1UO7CtLwGRJ cmT99imC/xWbk9hHRqioxgsCZ0nu7ZDuGLUIXsAkdH+Wa8eqgtTIvQ7ZIEa7PWA/kVde tncLSEzickEKqcjQmfNO15HD8kalLkTNcf2fHkgjq5oYtNWT6xGrOVY8k80TaIUyrUZb aBHqOl0gR+2fWeeEmvQx5B8hNL95KhPecfSQbpQYqe2V6ngiQZr2MtQtQzZ9E+kKKimQ yCNkw2kFXKOnuIB3JXQ8SRNELSSBpK1B99BjwUD0yflo2pJ1hc8V0rowCdgIV6F0p31D UKEQ== X-Gm-Message-State: APjAAAXLGmckKxGLh3hRhB0m2EheliPHIhEfoHq7+1Vm5laurYpbA7Ni Q0FRWTEb/2ca5Ysj7cohe3cYTzRfm9EbRII4poeNblc20vBsC6f9 X-Google-Smtp-Source: APXvYqx5FmSlRWIhJMpCyQicscPpxcvvAC8yJFVr3CWPAEUap4wsLDjAuowscTY8x8BkUAVfEeH5EuO0UcbHsRy+Log= X-Received: by 2002:a1f:a357:: with SMTP id m84mr4032221vke.55.1574306269900; Wed, 20 Nov 2019 19:17:49 -0800 (PST) MIME-Version: 1.0 From: Nick Sullivan Date: Thu, 21 Nov 2019 11:17:33 +0800 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000fc65f50597d2bdca" Archived-At: Subject: [TLS] Maximum lifetime for Delegated Credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 03:17:54 -0000 --000000000000fc65f50597d2bdca Content-Type: text/plain; charset="UTF-8" tlswg, At IETF 106, Hannes Tschofenig suggested that there are use cases in which longer-lived delegated credentials are useful. The idea is to allows the 7-day default to be overridden in the presence of an application profile. This is similar to what is allowed in TLS for MTI cipher suites. Here's the PR: https://github.com/tlswg/tls-subcerts/pull/45 Comments welcome, Nick --000000000000fc65f50597d2bdca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
tlswg,

At IETF 106,=C2=A0Han= nes Tschofenig suggested that there are use cases in which longer-lived del= egated credentials are useful. The idea is to allows the=C2=A07-day default= to be overridden in the presence=C2=A0of an=C2=A0application profile. This= is similar to what is allowed in TLS for MTI cipher suites.

=
Here's the PR:
https://github.com/tlswg/tls-subcerts/pull/45

Comments welcome,
Nick
--000000000000fc65f50597d2bdca-- From nobody Wed Nov 20 19:19:53 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8955E12022A for ; Wed, 20 Nov 2019 19:19:52 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 fXcTgxVw58zi for ; Wed, 20 Nov 2019 19:19:50 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 E8D4A12006E for ; Wed, 20 Nov 2019 19:19:49 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id q28so1347118lfp.2 for ; Wed, 20 Nov 2019 19:19:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=kzGDwEV4QIZLOyiXF+x7xBLKz9zva4//4a1MkZhy7Io=; b=XNzHErmB6ogv5qqikNOVm+MXlQAN04kNSfc/TeL84D50D7UiQoDWVTPfCe0Y/14Fk1 cRhBprrTrb8PNmoX601tkTMWWuX9j92jfFUR4/ZtLEBuMus/NKM3L73yALebAmvCPsGy 6dchcR3a1ZcneeJmObcNQzmRw/5awwdaKPgPH0qNg6er6KeqCvAZde2uMx2EK6Wt2+uT +RqZ5jbJaIEQfy/dFps5DUiO06Nu8ZCNOMea5l9rTexlhP/Ark+YlBnjCHvXmLfBoZjw yT7uYhYPbC/L+qwyLvwqR1yetuNQlV3F4KzgPU4jCGH47Q3Yrji3aATDAsd/c+z0b6ZM gkww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=kzGDwEV4QIZLOyiXF+x7xBLKz9zva4//4a1MkZhy7Io=; b=qnwEAqzwkaYrbbCKMwMh9cOVWYpA8o4dter3DQWUTPOAm6YR4+7cUmr39QaoxDRtzs 9H8WrzlRTx8ZHvJBdmRyhmQPSgUTzXIRsnHNp2KA0NF0lubUJ0DGF+ElOLYSj/+AUf3a GB8YOBYLlvHItgNVUwOh1HY0BLxtSRA2d7/lnjWfoV2SSK0MmkU3QkdW5kH+vvWdEzIo la8P33NABmwmCCpFCNDIW/VFdLf/wm+qAqtWF0hyvDDounoDrFvnkDh05D7P+gcX0G1F 87K7PQFfpLE/OMIXxYKpfErmJ5QVO0xj7C0FKypjoJzHJ0JTm1FvUmuwOd0iUTZqlkjw 7ZrA== X-Gm-Message-State: APjAAAXnfgGKIifTjg/9OwTGfqNlNFTbwSoXDDvou1dUrUcVlCP2Ld1+ Tcv5nOiUdM1v0OrIIKlWBMNbydBcZD0cJ+rWW90GqqZKOAU= X-Google-Smtp-Source: APXvYqwsmV29R6HfXF6dd3v97upYPTZuYo1YZy/IQjfYG3VSxHoLJ3Uyw4qbE6n8LDTPCVp312bF+h6hFQYMoOkxo3g= X-Received: by 2002:a19:22cc:: with SMTP id i195mr4344675lfi.148.1574306388079; Wed, 20 Nov 2019 19:19:48 -0800 (PST) MIME-Version: 1.0 References: <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> <20191117002249.GV34850@straasha.imrryr.org> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> In-Reply-To: <20191120064819.GR34850@straasha.imrryr.org> From: David Schinazi Date: Thu, 21 Nov 2019 11:19:36 +0800 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="000000000000077aaf0597d2c5a0" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 03:19:52 -0000 --000000000000077aaf0597d2c5a0 Content-Type: text/plain; charset="UTF-8" Hi folks, I've chatted with Daniel and Chris offline, and I think there might have been some miscommunication here. Please allow me to rephrase what I think is going on, and please let me know if this accurately represents your views. Daniel has a IoT use-case where due to memory constraints, a client knows it can only handle a certain number of tickets, and therefore Daniel was wondering if it would make sense to make the requested number of tickets a required maximum (as in a RFC 2119 MUST). However, server operators on this thread have indicated that a MUST would get in the way of implementing this, due to STEK rotation for example. Daniel understands this, and is OK with the current mindset of the document (which is only a hint, not a MUST). Additionally, Daniel would prefer to see the document move forward. In order to try to address Daniel's comments, I attempted to rephrase the normative section to suggest in more stronger terms that servers really shouldn't be sending more than the client's request, but keeping it a SHOULD. Here is the PR with the rephrase: https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/10 Here's a copy of the updated paragraph in the PR: Clients can use TicketRequestContents.count to indicate the number of tickets they would prefer to receive. Servers SHOULD NOT send more tickets than TicketRequestContents.count, as clients will most likely discard any additional tickets. Servers SHOULD additionally place a limit on the number of tickets they are willing to send to save resources. Therefore, the number of NewSessionTicket messages sent SHOULD be the minimum of the server's self-imposed limit and TicketRequestContents.count. Regarding Viktor's suggestion, I personally believe it would increase the complexity of the proposal, and I don't see use-cases compelling enough to warrant that complexity. I would rather keep this proposal as simple as possible. Thanks, David On Wed, Nov 20, 2019 at 2:48 PM Viktor Dukhovni wrote: > On Wed, Nov 20, 2019 at 11:53:08AM +0800, Tommy Pauly wrote: > > > > Somebody should try to avoid ending up with N new tickets after > > > every connection, but in could well be the client. > > > > Yes, I think that can and ought to be the client. The client is really > the > > only party that can know how many tickets have been "consumed" by > potentially > > failed attempts to connect that the server didn't see in time or got > dropped. > > OK, in that case, the proposal, is that on resumption, if the proposed > extension is *absent*, then the server should generally send just one > rather > than any larger default. > > If the extension is present, it is up to the client to not blindly ask for > N > tickets each time, and generally ask for just one ticket on resumption, > once it > has sufficiently many tickets for the desired concurrency level, with each > parallel thread obtaining one replacement ticket its next connection. > > As discussed clients that prefer to reuse tickets, can ask for zero, and > get 1 > only as-needed. If the server supports reuse then all is well. > > If the server does not support and refuses reuse, then it will issue a new > ticket each time and may only accept it once, but the client may have a > single-slot cache. If the client makes only one connection at a time, this > also works, but if/when its handshakes with the server overlap (a narrow > window > of ~1RTT) and two connections attempt to resume with the same ticket, one > of > them will end up doing a full handshake, but only when the client and > server > applications have incompatible ticket reuse expectations. Some friction > when the client and server are mismatched is not the end of the world. > > So on the whole I think the proposal still works with just a numeric signal > (tweaked with 0xff == none and 0 == reuse), and the onus to "generally > send 1" > on resumption moved to the client (i.e. clients that don't solicit ticket > reuse > should request only 1 ticket once they have enough). > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000077aaf0597d2c5a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

I've chatted with Daniel = and Chris offline, and I think there might
have been some miscomm= unication here. Please allow me to
rephrase what I think is going= on, and please let me know if
this accurately represents your vi= ews.

Daniel has a IoT use-case where due to memory= constraints,
a client knows it can only handle a certain number = of tickets,
and therefore Daniel was wondering if it would make s= ense to
make the requested number of tickets a required maximum
(as in a RFC 2119 MUST). However, server operators=C2=A0on this
thread have indicated that a MUST would get in the way of
implementing this, due to STEK rotation for example. Daniel
unde= rstands this, and is OK with the current mindset of the
document = (which is only a hint, not a MUST). Additionally,
Daniel would pr= efer to see the document move=C2=A0forward.

In ord= er to try to address Daniel's comments, I attempted
to rephra= se the normative section to suggest in more
stronger terms that s= ervers really shouldn't be sending
more than the client's= request, but keeping it a SHOULD.

Here is the PR = with the rephrase:

Here's a copy of the up= dated paragraph in the PR:
=C2=A0 =C2=A0Clients can use TicketReq= uestContents.count to indicate the number of
=C2=A0 =C2=A0tickets they w= ould prefer to receive.=C2=A0 Servers SHOULD NOT send more
=C2=A0 =C2=A0= tickets than TicketRequestContents.count, as clients will most likely
= =C2=A0 =C2=A0discard any additional tickets.=C2=A0 Servers SHOULD additiona= lly place a
=C2=A0 =C2=A0limit on the number of tickets they are willing= to send to save
=C2=A0 =C2=A0resources.=C2=A0 Therefore, the number of = NewSessionTicket messages sent
=C2=A0 =C2=A0SHOULD be the minimum of the= server's self-imposed limit and
=C2=A0 =C2=A0TicketRequestContents.= count.

Regarding Viktor's suggestion, I pe= rsonally believe it would increase the
complexity of the proposal= , and I don't see use-cases compelling enough
to warrant that= complexity. I would rather keep this proposal as simple as
possi= ble.

Thanks,
David

<= /div>
O= n Wed, Nov 20, 2019 at 2:48 PM Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
On Wed, Nov 20, 2019 at 11:53:08AM = +0800, Tommy Pauly wrote:

> > Somebody should try to avoid ending up with N new tickets after > > every connection, but in could well be the client.
>
> Yes, I think that can and ought to be the client. The client is really= the
> only party that can know how many tickets have been "consumed&quo= t; by potentially
> failed attempts to connect that the server didn't see in time or g= ot dropped.

OK, in that case, the proposal, is that on resumption, if the proposed
extension is *absent*, then the server should generally send just one rathe= r
than any larger default.

If the extension is present, it is up to the client to not blindly ask for = N
tickets each time, and generally ask for just one ticket on resumption, onc= e it
has sufficiently many tickets for the desired concurrency level, with each<= br> parallel thread obtaining one replacement ticket its next connection.

As discussed clients that prefer to reuse tickets, can ask for zero, and ge= t 1
only as-needed.=C2=A0 If the server supports reuse then all is well.

If the server does not support and refuses reuse, then it will issue a new<= br> ticket each time and may only accept it once, but the client may have a
single-slot cache.=C2=A0 If the client makes only one connection at a time,= this
also works, but if/when its handshakes with the server overlap (a narrow wi= ndow
of ~1RTT) and two connections attempt to resume with the same ticket, one o= f
them will end up doing a full handshake, but only when the client and serve= r
applications have incompatible ticket reuse expectations.=C2=A0 Some fricti= on
when the client and server are mismatched is not the end of the world.

So on the whole I think the proposal still works with just a numeric signal=
(tweaked with 0xff =3D=3D none and 0 =3D=3D reuse), and the onus to "g= enerally send 1"
on resumption moved to the client (i.e. clients that don't solicit tick= et reuse
should request only 1 ticket once they have enough).

--
=C2=A0 =C2=A0 Viktor.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000077aaf0597d2c5a0-- From nobody Wed Nov 20 19:55:07 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446651209F5 for ; Wed, 20 Nov 2019 19:55:03 -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 (1024-bit key) header.d=cloudflare.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 Wq9Kpe2HLkEF for ; Wed, 20 Nov 2019 19:55:00 -0800 (PST) Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (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 D827C12098F for ; Wed, 20 Nov 2019 19:54:59 -0800 (PST) Received: by mail-vk1-xa31.google.com with SMTP id e205so406364vke.2 for ; Wed, 20 Nov 2019 19:54:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=K8RMl82C1JBHRYMT2u7TcoRzgcQDEFqeSEELNZ1ZmhI=; b=XVcNbt7qbdqJD//CxqOYpG0M1AocHOevB8Ke/bp/0O5ih23aXaF6RG6vf0R2eBeCxB W0d8Q6yWqomY+wbaqoCgvbjDg7COYeKNGTXGUGWd+xd+ZhgWEyQAzAcQncRbt9My1YA1 h7NzYxyrYpy+C9jrLx73MV5whCwfS9NWerfZo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=K8RMl82C1JBHRYMT2u7TcoRzgcQDEFqeSEELNZ1ZmhI=; b=LSugbLxRwAJuDo4EezVyJHsYqTKt1P/Ogs8UmkSdFLG5DX/0O87CZpIJCSj0OZl6eR GrHxaL0fsE8QR6RnVE547v2TnJ9bpv3SDI6y4gMJM5vHVmTXHRxpxYc2UVBDzwIXb/DL QmeqMubLNtMVv8SJ8b1qOCNvnU/wwYVEhhoS+docBgdz9QsEbXuguoGJCY9dlyaBoQmC j9pveRJ1gdp4aS3SXcF855HQiVU8HupKinhxj0lAecLc25TmlkWkclE0+gJBqYQqhxtt jBumtmIDhqHBEZrOmF9UHq1FgNvIslDphTgQVv6HLtZLVLBxFPfwLXxrmLBUWrtELOT3 Gsgg== X-Gm-Message-State: APjAAAVmjSZJSc3Oer1kG0d0LyCAPTMR3AZZ5h0euHkd1uvkOB1B/oNI CfSZok+bqXmkZwpZ/cj8DFGijdlu2PcIv+gDR1IgYKWZlsfDLVqV X-Google-Smtp-Source: APXvYqx6H/r23ATgDpWxTOp7NQGYPGboeExe1qtWQEHNoSqv/GRau6zkoWa1mRtF0PZhpzUyNtJgcAkVJaoOAkl3bRI= X-Received: by 2002:a1f:5f08:: with SMTP id t8mr4304454vkb.87.1574308498450; Wed, 20 Nov 2019 19:54:58 -0800 (PST) MIME-Version: 1.0 From: Nick Sullivan Date: Thu, 21 Nov 2019 11:54:42 +0800 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000d164bf0597d342a4" Archived-At: Subject: [TLS] More flexible signature_algorithm selection for Delegated Credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 03:55:06 -0000 --000000000000d164bf0597d342a4 Content-Type: text/plain; charset="UTF-8" tlswg, At IETF 106, we discussed adding the ability to advertise specific signature algorithms for use in DCs without requiring clients to have to support these signature algorithms in leaf certificates. Here's a PR to address this issue: https://github.com/tlswg/tls-subcerts/pull/46 Comments welcome! Nick --000000000000d164bf0597d342a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
tlswg,

At IETF 106, we discu= ssed adding the ability to advertise specific signature algorithms for use = in DCs without requiring clients to have to support these signature algorit= hms in leaf certificates.

Here's a PR to addre= ss this issue:
Comments welcome!
Nick
--000000000000d164bf0597d342a4-- From nobody Wed Nov 20 21:01:57 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3D0120963 for ; Wed, 20 Nov 2019 21:01:55 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 vIjsdLHsdxpI for ; Wed, 20 Nov 2019 21:01:53 -0800 (PST) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 7182D120959 for ; Wed, 20 Nov 2019 21:01:53 -0800 (PST) Received: by mail-il1-x12f.google.com with SMTP id p6so2048737ilp.1 for ; Wed, 20 Nov 2019 21:01:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EBglmM6/24dF/AIWb/EK+TAmFEXPahfr0IamULQvEwY=; b=fvW9gbfy6Oli7fqUqWPU7KGPx325D2SoMuGONQVFStB7HpvmWbsOPinratoPmegVfK B6pQA98sxABfMdnYnBCvxFU8nBxd8IwFl5755toBQeOcgVqR/ajEAbSrJz3auSILO+1Q wMTw1wnUEaChldhCohsaMSz0kwXTNMzrRvOuQuXYxHSezLY+QrKjuCCQekiqcUiKsybI cGiC2vulNvtRB+atxGjVP/sEyfL2Q/r/MSgpKcfqaQbQqusV4k33ljhtbXvKZS+gYLQt gKmfjuY9Dgq+5jdCy1UJF2jm7ltpsoeQoU+ROfxFPEqlwjBxxubaC1Kdbri+ObzLYe/Z uj2A== 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=EBglmM6/24dF/AIWb/EK+TAmFEXPahfr0IamULQvEwY=; b=AAVLLmdNVw9OdXLV1vE5zbnjmJ3DVlcpmVpLITnZOx3ivG1XlHuoFEfjWgw7RMo1EY KDpR8NH1w5krK8O3EDo4gEH8jHiWgZYfC93Y/D7WPOmLGBQw3F1+fLrP3waow6j0/fr8 R5btuo8SXaRfFXOalylk294J+IhpqgEGM39ZYaxj8QBYcdhhXt6EfyPvyYJ10cdY48Ix gP5JOW7r2zw6ZUbFIViUKHH0cEHwPYyGxDDwMO9JPOWv23aT4dmqx2WY9KNeIwsWdckK dlcZOv5xJlhYQwkBWwgGW5GiZIOEoJkK3TioowsHViqs9Lb4viL/1XG+0gmLwxkyop7g o4IA== X-Gm-Message-State: APjAAAWE4tmAArUpEJP3vzcuwVKt333ynYVQZHmmgF9Rrx9/l8QqnIqq Um584DVdY6kz1efF3z4+6/Ruz18jZsSfPcIlGsk= X-Google-Smtp-Source: APXvYqxfdkl4v+Ru/YjSBJGXGERcMMzLzGj3qciVd6PfQ0m0h5MyW2TdomUzcRyWaaFV47E+jysZW8rEHbu6qnXGTjs= X-Received: by 2002:a92:8394:: with SMTP id p20mr8224512ilk.73.1574312512424; Wed, 20 Nov 2019 21:01:52 -0800 (PST) MIME-Version: 1.0 References: <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> <20191117002249.GV34850@straasha.imrryr.org> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> In-Reply-To: From: Rob Sayre Date: Wed, 20 Nov 2019 21:01:39 -0800 Message-ID: To: David Schinazi Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000118ef10597d43285" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 05:01:56 -0000 --000000000000118ef10597d43285 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 20, 2019 at 7:20 PM David Schinazi wrote: > Hi folks, > > I've chatted with Daniel and Chris offline, and I think there might > have been some miscommunication here. Please allow me to > rephrase what I think is going on, and please let me know if > this accurately represents your views. > > Daniel has a IoT use-case where due to memory constraints, > a client knows it can only handle a certain number of tickets, > and therefore Daniel was wondering if it would make sense to > make the requested number of tickets a required maximum > (as in a RFC 2119 MUST). However, server operators on this > thread have indicated that a MUST would get in the way of > implementing this, due to STEK rotation for example. Daniel > understands this, and is OK with the current mindset of the > document (which is only a hint, not a MUST). Additionally, > Daniel would prefer to see the document move forward. > > In order to try to address Daniel's comments, I attempted > to rephrase the normative section to suggest in more > stronger terms that servers really shouldn't be sending > more than the client's request, but keeping it a SHOULD. > > Here is the PR with the rephrase: > https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/10 > > Here's a copy of the updated paragraph in the PR: > Clients can use TicketRequestContents.count to indicate the number of > tickets they would prefer to receive. Servers SHOULD NOT send more > tickets than TicketRequestContents.count, as clients will most likely > discard any additional tickets. Servers SHOULD additionally place a > limit on the number of tickets they are willing to send to save > resources. Therefore, the number of NewSessionTicket messages sent > SHOULD be the minimum of the server's self-imposed limit and > TicketRequestContents.count. > This sounds pretty close to the "MAY option" I sent on Oct 2 here: https://mailarchive.ietf.org/arch/msg/tls/YogBUOC0ZujSAxHVp8H0oIjJm3Y The latter half of the patch's paragraph still uses "SHOULD" interoperability requirements to remark on quality-of-implementation issues, rather than just explain them. That's not great, but also not a dealbreaker. thanks, Rob --000000000000118ef10597d43285 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 20, 2019 at 7:20 PM David= Schinazi <dschinazi.ietf@gm= ail.com> wrote:
Hi folks,

I've chatted with = Daniel and Chris offline, and I think there might
have been some = miscommunication here. Please allow me to
rephrase what I think i= s going on, and please let me know if
this accurately represents = your views.

Daniel has a IoT use-case where due to= memory constraints,
a client knows it can only handle a certain = number of tickets,
and therefore Daniel was wondering if it would= make sense to
make the requested number of tickets a required ma= ximum
(as in a RFC 2119 MUST). However, server operators=C2=A0on = this
thread have indicated that a MUST would get in the way of
implementing this, due to STEK rotation for example. Daniel
understands this, and is OK with the current mindset of the
do= cument (which is only a hint, not a MUST). Additionally,
Daniel w= ould prefer to see the document move=C2=A0forward.

In order to try to address Daniel's comments, I attempted
to= rephrase the normative section to suggest in more
stronger terms= that servers really shouldn't be sending
more than the clien= t's request, but keeping it a SHOULD.

Here is = the PR with the rephrase:

He= re's a copy of the updated paragraph in the PR:
=C2=A0 =C2=A0= Clients can use TicketRequestContents.count to indicate the number of
= =C2=A0 =C2=A0tickets they would prefer to receive.=C2=A0 Servers SHOULD NOT= send more
=C2=A0 =C2=A0tickets than TicketRequestContents.count, as cli= ents will most likely
=C2=A0 =C2=A0discard any additional tickets.=C2=A0= Servers SHOULD additionally place a
=C2=A0 =C2=A0limit on the number of= tickets they are willing to send to save
=C2=A0 =C2=A0resources.=C2=A0 = Therefore, the number of NewSessionTicket messages sent
=C2=A0 =C2=A0SHO= ULD be the minimum of the server's self-imposed limit and
=C2=A0 =C2= =A0TicketRequestContents.count.

This sounds pretty close to the "MAY option" I sent on Oct 2 her= e:


The latter half = of the patch's paragraph still uses "SHOULD" interoperability= requirements to remark on quality-of-implementation issues, rather than ju= st explain them. That's not great, but also not a dealbreaker.

thanks,
Rob
--000000000000118ef10597d43285-- From nobody Wed Nov 20 21:34:33 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7D7120044 for ; Wed, 20 Nov 2019 21:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=tqMMwR9n; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=btl08Wgt 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 j7MysijQAAWD for ; Wed, 20 Nov 2019 21:34:28 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B864F120143 for ; Wed, 20 Nov 2019 21:34:28 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id EB26D22431 for ; Thu, 21 Nov 2019 00:34:27 -0500 (EST) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Thu, 21 Nov 2019 00:34:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=uaXMjcERZ7QVXKO6jGas9tKGTxp7DZ+ ykWLTbRNQt88=; b=tqMMwR9ncuqucLJdpqyVwS9x+120glAvOtiU3EX/zANqE33 WN57O8VtHWjsoOWTZAQOVN8escz/X17spnzGJKpk/AHN0NFxuwxwY09bIorbQfZL GHr+UTtWxeKX4QyuKuJuwIJISFZQ9vv2kW1UxiF5dnXIOOFY2bWyY8EHe4twnlzN MikA/nXeokYQW1FwA5CLMS8bmq0mlwrc+rABHgMes/ZJwg/tIqAcr+fJJa/w+dhZ dWmyHuV/09f6GwksXlcU7z5KHCyZZm5msxXeUfcuvM954naJbbDoF+z79QQAyMjB p5+nBBbw2N2BtKDK7Tazxuz1lJSQGWuYhJ229BQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=uaXMjc ERZ7QVXKO6jGas9tKGTxp7DZ+ykWLTbRNQt88=; b=btl08WgtgQAJUcRd1PrazT mxQg+oTcC8plOw6qn5vOOCrxGtfxUMhiVn7r4J2FGBJ1OJ3mJ17zzN+V+n2CQWRB XqFP8Bv3H3dV2+TJvh3dbYzx+fyDsk+DbKUwHNgSXWjijFVMePJLQ08vl3KD2lcC eRym9pXJzT/lMu4bUY0iskcujqrLNEBO5ixc1YWWAKwLtxaA2Hiz3wqya6vXOhdb BFN9jEYFUt8+edGGl9JiVHobQVzKkfIo4cbTJL4DkqFQFUsnflNjrWPB7KhGe61c Ze7zAk0d3qizGW8HhDUpG0z8rmA7FwyBMExZPHiN9wBKLD5rg7aI7pCYmLNy98cA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehuddgkeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtoh hmpdhivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghp ihhnghgsihhtshdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id ABF7B3C00A2; Thu, 21 Nov 2019 00:34:27 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: <1fe837a5-a32a-44c4-be7d-7da480f6b9f4@www.fastmail.com> In-Reply-To: References: <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> <20191117002249.GV34850@straasha.imrryr.org> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> Date: Thu, 21 Nov 2019 13:34:07 +0800 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 05:34:31 -0000 Thanks for clarifying, David! This text reflects my understanding and is fine by my. Best, Chris On Thu, Nov 21, 2019, at 11:19 AM, David Schinazi wrote: > Hi folks, > > I've chatted with Daniel and Chris offline, and I think there might > have been some miscommunication here. Please allow me to > rephrase what I think is going on, and please let me know if > this accurately represents your views. > > Daniel has a IoT use-case where due to memory constraints, > a client knows it can only handle a certain number of tickets, > and therefore Daniel was wondering if it would make sense to > make the requested number of tickets a required maximum > (as in a RFC 2119 MUST). However, server operators on this > thread have indicated that a MUST would get in the way of > implementing this, due to STEK rotation for example. Daniel > understands this, and is OK with the current mindset of the > document (which is only a hint, not a MUST). Additionally, > Daniel would prefer to see the document move forward. > > In order to try to address Daniel's comments, I attempted > to rephrase the normative section to suggest in more > stronger terms that servers really shouldn't be sending > more than the client's request, but keeping it a SHOULD. > > Here is the PR with the rephrase: > https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/10 > > Here's a copy of the updated paragraph in the PR: > Clients can use TicketRequestContents.count to indicate the number of > tickets they would prefer to receive. Servers SHOULD NOT send more > tickets than TicketRequestContents.count, as clients will most likely > discard any additional tickets. Servers SHOULD additionally place a > limit on the number of tickets they are willing to send to save > resources. Therefore, the number of NewSessionTicket messages sent > SHOULD be the minimum of the server's self-imposed limit and > TicketRequestContents.count. > > Regarding Viktor's suggestion, I personally believe it would increase the > complexity of the proposal, and I don't see use-cases compelling enough > to warrant that complexity. I would rather keep this proposal as simple as > possible. > > Thanks, > David > > > On Wed, Nov 20, 2019 at 2:48 PM Viktor Dukhovni wrote: > > On Wed, Nov 20, 2019 at 11:53:08AM +0800, Tommy Pauly wrote: > > > > > > Somebody should try to avoid ending up with N new tickets after > > > > every connection, but in could well be the client. > > > > > > Yes, I think that can and ought to be the client. The client is really the > > > only party that can know how many tickets have been "consumed" by potentially > > > failed attempts to connect that the server didn't see in time or got dropped. > > > > OK, in that case, the proposal, is that on resumption, if the proposed > > extension is *absent*, then the server should generally send just one rather > > than any larger default. > > > > If the extension is present, it is up to the client to not blindly ask for N > > tickets each time, and generally ask for just one ticket on resumption, once it > > has sufficiently many tickets for the desired concurrency level, with each > > parallel thread obtaining one replacement ticket its next connection. > > > > As discussed clients that prefer to reuse tickets, can ask for zero, and get 1 > > only as-needed. If the server supports reuse then all is well. > > > > If the server does not support and refuses reuse, then it will issue a new > > ticket each time and may only accept it once, but the client may have a > > single-slot cache. If the client makes only one connection at a time, this > > also works, but if/when its handshakes with the server overlap (a narrow window > > of ~1RTT) and two connections attempt to resume with the same ticket, one of > > them will end up doing a full handshake, but only when the client and server > > applications have incompatible ticket reuse expectations. Some friction > > when the client and server are mismatched is not the end of the world. > > > > So on the whole I think the proposal still works with just a numeric signal > > (tweaked with 0xff == none and 0 == reuse), and the onus to "generally send 1" > > on resumption moved to the client (i.e. clients that don't solicit ticket reuse > > should request only 1 ticket once they have enough). > > > > -- > > Viktor. > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Nov 20 21:35:07 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F220120971 for ; Wed, 20 Nov 2019 21:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=qXbgWDyr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OAvjV9vJ 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 RC2PTOkJ9DGi for ; Wed, 20 Nov 2019 21:35:05 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8CF9120044 for ; Wed, 20 Nov 2019 21:35:04 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id EDADB2243D for ; Thu, 21 Nov 2019 00:35:03 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 21 Nov 2019 00:35:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=cFST63UDqFkF7wbH8ECVUelC8t1vHjn 1MW770ipM1D8=; b=qXbgWDyr7SLCXmr/MWyczv/y72n4pudr2MKkJu2ixYHugXp ll3EaVdNRh5UGgyqDMToaA6zHw0RqxDxaMqF7c0+9I/GoHeFJpSMavBJnfnQKxL4 hnnVBfDu/ueIPYIvJjH1ZziXMXCx3xArwK5sfHTxrD0kSfESmOdRINKlIwMqq8j2 jyW5SqkkojQI88e/gffsswfA/Py1ZyeLSp8ujzK5/ahXzlVh4oStgFUwbFZSAnMi smABcukyNaUbfMEBfa8K/2qanwL/Qzcpdgs34EXpP7TRp7YrhUF6WBUKM2k1QgaZ RcgczqefFgPkrqN4lMI6rv1tzVVcLc21BEJhVFA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=cFST63 UDqFkF7wbH8ECVUelC8t1vHjn1MW770ipM1D8=; b=OAvjV9vJOOx0W/QX/prjgZ Gi2JkT2d54czULHfkq4gY7T+5Sx9X0LuTdUl18bwiMMXSduPqmjjATB6HzFxgDmb IA6Fzb+zWI4Pm1O3D6IpQcIxQD7iz+Ig+KJTL0RpXwLrN/h3kCc4jfsKKwW9zHiN un5oeRHo/9hDBvd6IJHQ7e3cbkMaz8j+gx4Qrx4xb92EmxonOr9oKLUHlotBbeLD gW7VMH3sPxQcOHPx3mYzZaaRf6Pkx3ghk4xaTS3vp0oN+EzDeaZoLvwWNTw8vSh9 4ddvca/3K8TlAR3wR+kxytKxDrJ2n3fPRDkPvX/uHX5V+R/qtyxSUWp2EoZardAA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehuddgkeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecurf grrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehl uhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9BB2FE00B1; Thu, 21 Nov 2019 00:35:03 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: <241d389b-3f64-4b8f-8cb3-0f07e20252b3@www.fastmail.com> In-Reply-To: References: Date: Thu, 21 Nov 2019 13:34:40 +0800 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] Maximum lifetime for Delegated Credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 05:35:06 -0000 On Thu, Nov 21, 2019, at 11:17, Nick Sullivan wrote: > https://github.com/tlswg/tls-subcerts/pull/45 Thanks for putting this together Nick. This PR cleanly captures the resolution of the discussion. From nobody Wed Nov 20 21:36:35 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742BE120110 for ; Wed, 20 Nov 2019 21:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 LScts2i1ksNU for ; Wed, 20 Nov 2019 21:36:31 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 5A64A12009C for ; Wed, 20 Nov 2019 21:36:31 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id t8so2386643qtc.6 for ; Wed, 20 Nov 2019 21:36:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=u9ccOsA3yDv84JwyZt5WMGSOWAoVx3wf8mJDbHgGbWA=; b=mpImeQXoS3js/bkYHDPZOyIigYDSD0scqqz6wSOMJ41lsv1HWWq5n9yu285NoS+lHh dfJv5eBREmVmjulFPN8NB7i66sRvoOj0kKA+3pcJy7IQ4/E3k4f20kadr2yUPCtVYqnD /fL0vSbJ6W/MpgKYDQK01qJVg09S3GTFFfvMg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=u9ccOsA3yDv84JwyZt5WMGSOWAoVx3wf8mJDbHgGbWA=; b=fqt1pArsymlH2kJvO8nH/BUV85ia3EZFPfYorBAnb81lzFoaFyky9EtUXS69ci3A+B mT+a2L3GIOfoeUAVVSX+uEM5dBqibThd0ZUhIaKma+Amh3F7dA7iSWMDqcrXHxds5HHu e0VC6OFjUUmIdtIvvZ/0BsEvJr9qGuBkOxgJzT3qyUvOw1b6saGvnYT8+aylApQeR/QL FUjPGh6CZvmBUkUxUANGVqRLMLFJscqFjhTgOaoz0XaYD6dDjvtHsfTxeECi9Z8rysJT +YtjQkpN2coG4oDpuzH7TjIQgGuUFTvdotJw8K7p58qjREAoOBMF6Nr0vDRLis2gkvZk kEZg== X-Gm-Message-State: APjAAAXrVadOTsaTqXnJpU28euLYnPsZyzDZ8Q23Z2/94zI1yHfRl+fO BGiQhLtTEFUXaFOWXq+C+uvte5GyQH642w== X-Google-Smtp-Source: APXvYqxQ2lh7imRF+7y3U9QV+mIqRunQB4NUwwAZWJgzMB9Oeq1nvq40MY58mL+9kQpcGKUoB1bvPA== X-Received: by 2002:ac8:644:: with SMTP id e4mr6714243qth.302.1574314590276; Wed, 20 Nov 2019 21:36:30 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:c159:5a2c:c266:40f2? ([2001:67c:370:128:c159:5a2c:c266:40f2]) by smtp.gmail.com with ESMTPSA id k199sm861772qke.0.2019.11.20.21.36.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Nov 2019 21:36:29 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Thu, 21 Nov 2019 13:36:25 +0800 To: TLS List X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [TLS] Adoption call for draft-rescorla-tls-ctls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 05:36:33 -0000 At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS = WG and the LAKE BOF, which is now a chartered WG [3]. After some = discussions, the ADs suggested [4] that the TLS WG consider whether this = draft be adopted as a TLS WG item. LAKE could then later = specify/refer/adopt/profile it, as appropriate. The authors revised cTLS = and presented the revised draft at IETF 106 [5]. At IETF 106 there was = support for adoption of cTLS as a WG item. To confirm this on the list: = if you believe that the TLS WG should not adopt this as a WG item, then = please let the chairs know by posting a message to the TLS list by 2359 = UTC 13 December 2019 (and say why). NOTE: : If the consensus is that this draft should be adopted as a WG item, = then this will necessarily result in a WG rechartering discussions. We = would have gotten to this rechartering discussion anyway now that DTLS = 1.3 is progressing out of the WG. Thanks, Chris, Joe, and Sean [0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/ [1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ [2] https://github.com/ekr/draft-rescorla-tls-ctls [3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ [4] = https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk [5] = https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-= tls-13-00.pdf= From nobody Wed Nov 20 21:37:19 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE64120971; Wed, 20 Nov 2019 21:37:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.110.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157431463736.926.6665699931868132765.idtracker@ietfa.amsl.com> Date: Wed, 20 Nov 2019 21:37:17 -0800 Archived-At: Subject: [TLS] The TLS WG has placed draft-rescorla-tls-ctls in state "Call For Adoption By WG Issued" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 05:37:17 -0000 The TLS WG has placed draft-rescorla-tls-ctls in state Call For Adoption By WG Issued (entered by Sean Turner) The document is available at https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ From nobody Wed Nov 20 21:38:10 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DE5120143 for ; Wed, 20 Nov 2019 21:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=LB9YpvI7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Wqm15III 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 DrknBfz_VdW1 for ; Wed, 20 Nov 2019 21:38:08 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59AFE12009C for ; Wed, 20 Nov 2019 21:38:08 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 85547221C2 for ; Thu, 21 Nov 2019 00:38:07 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 21 Nov 2019 00:38:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=waWB0jQQdQElftMrO7G4qYTtIlY/3HC KVvGL8474uIk=; b=LB9YpvI7bHvjyXERGNOLa0AMp6wycMISkIisbNEqmD7vziI vNn7m7sTGhHZu9kp4NfjXnHKw2lULZlgelAJh1k4bgWGXgxlGpJz5OgOYiPt4r5y NDT1YWsNh6bw5suK+UPwDq4l6NPsasdno9vGnX8GXhga6h7p4dOLWjLiMKLrbtL8 EqdHV1KImfkbRRcW11uSXTQlUUi9CTemSihmfPZm9eIZrapHzvCx1EN5LUKVqvs3 0sHrTHEdHxAmE0fYOLtWxGGtio2dGMYaCuu94YgeUMDco2a/CNgJchmHQKuv+K9S t247oU2AdFnq7u5MqM+uq/5WTezktqWorIAOLcQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=waWB0j QQdQElftMrO7G4qYTtIlY/3HCKVvGL8474uIk=; b=Wqm15IIIyPcZE1awd/+Uf/ iAytzeGKUIdL1lXXNKWgOO54lbV6mXs6h8KOZL+6vW169cbK5ci0/zyPTf4zXATe js2otif1Wr3apc7Jxqwkp+f996R9RUa9/8GEtsY/mxT6twHAlP9kg+8K0uxtZvHi UPN56SPe3smZjk9UE+K7uqinh9+CeJrK0aqGEyNuymn0Zmvq+ugHDsJdd7g3ZpHr FHc+FB426Me1TER5cai8qwKNlVYdv2YVavBByDjTK7zI1uGc20e3Rg2yBHE6uRlR cPyedNZ97QGDdfBKXvol3izj6S8atUjiWR6UXX4ZYTb65tXcpnaaecRaACaKnIUA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehuddgkeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehloh ifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 168E7E00A3; Thu, 21 Nov 2019 00:38:07 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: <67c2ed4f-ce87-4d63-87bf-c38a36c8fb70@www.fastmail.com> In-Reply-To: References: <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> <20191117002249.GV34850@straasha.imrryr.org> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> Date: Thu, 21 Nov 2019 13:37:46 +0800 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 05:38:09 -0000 On Thu, Nov 21, 2019, at 11:19, David Schinazi wrote: > resources. Therefore, the number of NewSessionTicket messages sent > SHOULD be the minimum of the server's self-imposed limit and > TicketRequestContents.count. Thanks for doing this David. Friendly amendment: remove the SHOULD from this sentence (it's a consequence of the two other "SHOULD"s): Therefore, the number of NewSessionTicket messages sent will be the minimum [...] From nobody Wed Nov 20 21:38:37 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BD0120143 for ; Wed, 20 Nov 2019 21:38:35 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ed6N7S11VJgD for ; Wed, 20 Nov 2019 21:38:33 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F9F01201EF for ; Wed, 20 Nov 2019 21:38:33 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id d5so1759289ljl.4 for ; Wed, 20 Nov 2019 21:38:33 -0800 (PST) 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=H18TO2LZ5ZiBkvllWefAmRl9CA5AQsETBATnsB+yZBk=; b=XCTbi5WUctVjfJpscT4FN2pS4KceButiAQHYkbLzieTynqCHZN+Qcf1z4Wo4KdRNN+ OZY2BFFR1Qu9HsRjGFKcRrM/NH9yaAD3HHkR8k8ljgGnu0NabDjd6FrF3pnIK00jfzci UF7q/JxfMq15GsAf+QC+yZjmAMjO8IzzCFCa37OnOV8rosPLh9xmQj9F2//F7NnNkLF0 OVA8Pgn5BHIToFAxq0XN6Ton17qYDu0bllicKrh4yE1CU6ItJMFOCqHoT68rNBgNQF9c iVXf3bHNZ2nL7HhOBfJPT+GplPnIY1KHIkPozEpfzlVlMQ+NWU2OLwy1PMZO5xIoVLC9 ta+A== 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=H18TO2LZ5ZiBkvllWefAmRl9CA5AQsETBATnsB+yZBk=; b=dVnDVA0DS6Z91A5W7N1Q/MdQC6I5/oKCE1L3UzAtI+/XrclnlFIZNsQg9urCe2nPGi MDwtJxErLny1tFsRuHZ0Snt6xwbQFXC7gI/TiMK3ur5M0NZ+vIuaDS5fmmhtw7bVXGr1 a1xwExyhonz/zyHkUhRPiXYGGWxqy5ayj7D940/NYtqoaeu5FxnkjF2sPyjf4jKZf7Q9 /WVIn85Rw7fwK/mdghHJsGoKUarNHSoj7dk7MfqAhh2P5o5DNC9py77Y/KRjUeXnUAby I0eMZJx9N5qwNH74rcGbM/92KzbhSK83oo135RjM02sA39iBKl2YkoiEMgR0Tg6RbAOO 7juw== X-Gm-Message-State: APjAAAUdBNoRmBMWUS9Dk9YnF/26SAxjawAjiZ3qe1RqJKc3X34I7t9r GScOb+TAyQFKEOy0ZtBwhBZmNkzx4sPNMobM7erATmk6 X-Google-Smtp-Source: APXvYqxPRBYkehd2JUjlIvNy5RsmYoovoPaRweO0KlY6a1HlUprkdQx6ugETw6a3/k0+2/gR02ejiUOPt0q0w5HOc20= X-Received: by 2002:a2e:982:: with SMTP id 124mr5832163ljj.48.1574314711451; Wed, 20 Nov 2019 21:38:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Wed, 20 Nov 2019 21:37:54 -0800 Message-ID: To: Sean Turner Cc: TLS List Content-Type: multipart/alternative; boundary="00000000000024202e0597d4b541" Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 05:38:35 -0000 --00000000000024202e0597d4b541 Content-Type: text/plain; charset="UTF-8" I support adoption. On Wed, Nov 20, 2019 at 9:36 PM Sean Turner wrote: > At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS WG > and the LAKE BOF, which is now a chartered WG [3]. After some discussions, > the ADs suggested [4] that the TLS WG consider whether this draft be > adopted as a TLS WG item. LAKE could then later specify/refer/adopt/profile > it, as appropriate. The authors revised cTLS and presented the revised > draft at IETF 106 [5]. At IETF 106 there was support for adoption of cTLS > as a WG item. To confirm this on the list: if you believe that the TLS WG > should not adopt this as a WG item, then please let the chairs know by > posting a message to the TLS list by 2359 UTC 13 December 2019 (and say > why). > > NOTE: > : If the consensus is that this draft should be adopted as a WG item, then > this will necessarily result in a WG rechartering discussions. We would > have gotten to this rechartering discussion anyway now that DTLS 1.3 is > progressing out of the WG. > > Thanks, > Chris, Joe, and Sean > > [0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/ > [1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ > [2] https://github.com/ekr/draft-rescorla-tls-ctls > [3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ > [4] https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk > [5] > https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-tls-13-00.pdf > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000024202e0597d4b541 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adoption.

On Wed, Nov 20, 2019 at 9:36 PM Sea= n Turner <sean@sn3rd.com> wrote= :
At IETF 105, e= kr presented cTLS (Compact TLS) [0][1][2] to both the TLS WG and the LAKE B= OF, which is now a chartered WG [3].=C2=A0 After some discussions, the ADs = suggested [4] that the TLS WG consider whether this draft be adopted as a T= LS WG item. LAKE could then later specify/refer/adopt/profile it, as approp= riate. The authors revised cTLS and presented the revised draft at IETF 106= [5].=C2=A0 At IETF 106 there was support for adoption of cTLS as a WG item= .=C2=A0 To confirm this on the list: if you believe that the TLS WG should = not adopt this as a WG item, then please let the chairs know by posting a m= essage to the TLS list by 2359 UTC 13 December 2019 (and say why).

NOTE:
: If the consensus is that this draft should be adopted as a WG item, then = this will necessarily result in a WG rechartering discussions.=C2=A0 We wou= ld have gotten to this rechartering discussion anyway now that DTLS 1.3 is = progressing out of the WG.

Thanks,
Chris, Joe, and Sean

[0] https://datatracker.ietf.org/doc/slid= es-105-tls-sessa-ctls/
[1] https://datatracker.ietf.org/doc/draft-= rescorla-tls-ctls/
[2] https://github.com/ekr/draft-rescorla-tls-ctls=
[3] https://datatracker.ietf.org/doc/draft-= rescorla-tls-ctls/
[4] https://mailarchive.ietf.o= rg/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk
[5] https://d= atatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-tls-13-00.= pdf
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000024202e0597d4b541-- From nobody Wed Nov 20 21:41:28 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827731201EF for ; Wed, 20 Nov 2019 21:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfN7zDZFlDaS for ; Wed, 20 Nov 2019 21:41:23 -0800 (PST) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 194321200FB for ; Wed, 20 Nov 2019 21:41:23 -0800 (PST) Received: by mail-qt1-x829.google.com with SMTP id i17so2425616qtq.1 for ; Wed, 20 Nov 2019 21:41:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=2bEeOpTemc9guMYpn7rlLAxOxyMZaEB/gcslyPoDPBk=; b=0C5zCE+zQlXus4ji3vS1aWhudynNLSuSvR8YaZCBEn62/zARuhDBz9r9q8mOmdd2h5 X4TbaHFJuak6bvYjSoHJRbG1MriQWRwyNVDM/7sFQz/UVRX6XbI+CACw+/JV7j+fZCq8 zFeOXxC8WUmFhatGU/yLA2pLk89twUbrfNZEIq/LfyTMDKsBLWLnNXVDsrTRF+ZVeVQp rFNrWM0Qmn3H2nYQfSZJE/86Rh9ZYO25cNNXTWelLkC359LL9XbTTNUUs01pZlQ6/eTV ci/IkSIUYQ6gTSY4EW04yUqXDnJoa/+R+KzodBJ08bO+Gvs/65SqNBdUfM8mlvm62v9b ++dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=2bEeOpTemc9guMYpn7rlLAxOxyMZaEB/gcslyPoDPBk=; b=txXoWaZBAF6kSiCFLDa9Gq2OZyAhWKCzCc4IUV6U2sKdZ5xLPY3do+6aWUo+jETMwl z1em4ffx5Nm6ucwRNZsuGXhiwtmkz5m7QsqV45k54OgXEv/9s9+ChZQSzEgyFj5dINpN cAmJnBzhccH800Gv7OtVf8g5vzgCPdObAiJyjiZuqbYvRLtDKMc22JlreUWhhJ6iHUth cCVvs2t2JAzM3zdtDaGEZoKSmuLdxPwHysYKbeylp9Q9mIMOGd8/PGYEfydMUOX+ddba EX/auCiTnWKu6+2ZQNla6g+Ca+JaRXZJMFdsYsrdoO3u3VCKEsWvufaDAv+P8AMs9cLk GhIg== X-Gm-Message-State: APjAAAVrTZ0iKl3401h06zIt857AVCRo+mnA2vqxaGvQaRLBcd26pdv9 yWNPALwsUqjYUVy2TV1C6MRNSYC0l9YkXWYMUNjR7oVu X-Google-Smtp-Source: APXvYqxB5a8n7UnHgxxMUUcF9eCJMj4AzK1C4b7mvZQaQMORfRRyjoO6YyE8e/DXwB62wUjwH/CJfmyQoXU/PebZ9D8= X-Received: by 2002:ac8:23d3:: with SMTP id r19mr7020296qtr.297.1574314881930; Wed, 20 Nov 2019 21:41:21 -0800 (PST) MIME-Version: 1.0 References: <157164508164.31795.18313531664029121455@ietfa.amsl.com> In-Reply-To: <157164508164.31795.18313531664029121455@ietfa.amsl.com> From: Joseph Salowey Date: Thu, 21 Nov 2019 13:41:10 +0800 Message-ID: To: "" Content-Type: multipart/alternative; boundary="0000000000004d689e0597d4bf6e" Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-dtls-connection-id-07.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 05:41:27 -0000 --0000000000004d689e0597d4bf6e Content-Type: text/plain; charset="UTF-8" This revision addresses comments raised by the working group and will be submitted to the IESG. On Mon, Oct 21, 2019 at 4:04 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > > Title : Connection Identifiers for DTLS 1.2 > Authors : Eric Rescorla > Hannes Tschofenig > Thomas Fossati > Filename : draft-ietf-tls-dtls-connection-id-07.txt > Pages : 16 > Date : 2019-10-21 > > Abstract: > This document specifies the Connection ID (CID) construct for the > Datagram Transport Layer Security (DTLS) protocol version 1.2. > > A CID is an identifier carried in the record layer header that gives > the recipient additional information for selecting the appropriate > security association. In "classical" DTLS, selecting a security > association of an incoming DTLS record is accomplished with the help > of the 5-tuple. If the source IP address and/or source port changes > during the lifetime of an ongoing DTLS session then the receiver will > be unable to locate the correct security context. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-07 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls-connection-id-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls-connection-id-07 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000004d689e0597d4bf6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This revision addresses comments raised by the workin= g group and will be submitted=C2=A0to the IESG.=C2=A0=C2=A0

On Mon, Oct 21, = 2019 at 4:04 PM <internet-dr= afts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Transport Layer Security WG of the IETF.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Connection Identifiers for DTLS 1.2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Eric= Rescorla
=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 Hannes Tschofenig
=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 Thomas Fossati
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-tls-dtls-connection-id-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 16
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-10-21

Abstract:
=C2=A0 =C2=A0This document specifies the Connection ID (CID) construct for = the
=C2=A0 =C2=A0Datagram Transport Layer Security (DTLS) protocol version 1.2.=

=C2=A0 =C2=A0A CID is an identifier carried in the record layer header that= gives
=C2=A0 =C2=A0the recipient additional information for selecting the appropr= iate
=C2=A0 =C2=A0security association.=C2=A0 In "classical" DTLS, sel= ecting a security
=C2=A0 =C2=A0association of an incoming DTLS record is accomplished with th= e help
=C2=A0 =C2=A0of the 5-tuple.=C2=A0 If the source IP address and/or source p= ort changes
=C2=A0 =C2=A0during the lifetime of an ongoing DTLS session then the receiv= er will
=C2=A0 =C2=A0be unable to locate the correct security context.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/= draft-ietf-tls-dtls-connection-id/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ie= tf-tls-dtls-connection-id-07
https://datatracker.ietf.o= rg/doc/html/draft-ietf-tls-dtls-connection-id-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff= ?url2=3Ddraft-ietf-tls-dtls-connection-id-07


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000004d689e0597d4bf6e-- From nobody Wed Nov 20 21:43:46 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329AA1200FB for ; Wed, 20 Nov 2019 21:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=h3Uoll9E; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sKzG+kdn 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 eM1kyH1mqooL for ; Wed, 20 Nov 2019 21:43:44 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C75012009C for ; Wed, 20 Nov 2019 21:43:44 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A72E322474 for ; Thu, 21 Nov 2019 00:43:42 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 21 Nov 2019 00:43:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=hBps+/9BtAzjgqvL+tPKOJ6k+J/D90e 1icrCgQwgAf0=; b=h3Uoll9EAulq0nVoCziP0jL92+gOPeR0sYX7IhmqBzh7LvT oaWufcyUybXRLeP+QJkPahGUdt9FFjeWRFQclDGR1aKuscP0MhitNpxINTsYvY2V 8eYAcT3ce9TXIVlFxSiKgxUMkynj0HYEaSVO+1rR3RJUDue5ZpoYN0V7zyFskpd5 BUj0wjdjLVnTvI66UhQbef+77D/cfsn4Oz4k+uyUQRa99TS+PeC73rmmDQv8jlz9 jptRxu7zEwHQ4yMe4dsMcvLeMeZvU4qy70UxcEClbQKphmzISgkDq4E19W7KwMsp YuDpLfGKY0WCO59aS96y0y3PC36Did+v3qv+TCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=hBps+/ 9BtAzjgqvL+tPKOJ6k+J/D90e1icrCgQwgAf0=; b=sKzG+kdnTj7GAo297MTP4o Lzq0JoMCcQ8BsQrRXmaH8JPyC/+dQqsAfjGyP5mELkHqwE7+m7Kr8WDn8VB9C6Bl LgUENy9542AecOSY9+aAL7q183exdjij8R0z0JxQhkAxGxW27yuIGKX52t4y1Azd 6pSGLcAKUH9Fj/jml1/J28aBcW8K6puyJoYw/tF5uhhQ+gqRfq/g2jSdlwIVOAfT J7REQ9YpfoyjfZt1Or3OpWAPNwKF6V1VBF0bD9UlG3v93r5AS4hqB9W01CGjCbOq 8APdVRmLCto+uofphaUOeIfadNWIB2Ep2UXJbDB1otRTJCMI7a5RjuMLelS3LuZA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehuddgkeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehloh ifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4FDA8E00A3; Thu, 21 Nov 2019 00:43:42 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: <97e71c36-9b73-4142-898d-68d345d42d81@www.fastmail.com> In-Reply-To: References: Date: Thu, 21 Nov 2019 13:43:22 +0800 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] =?utf-8?q?More_flexible_signature=5Falgorithm_selection_fo?= =?utf-8?q?r_Delegated_Credentials?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 05:43:45 -0000 On Thu, Nov 21, 2019, at 11:54, Nick Sullivan wrote: > At IETF 106, we discussed adding the ability to advertise specific > signature algorithms for use in DCs without requiring clients to have > to support these signature algorithms in leaf certificates. Is the intent with supporting an empty extension to support backward compatibility? I think that deployed implementations can probably just change to use the list so that we don't have to include this additional flexibility. I'd prefer to always have a list. From nobody Wed Nov 20 21:44:29 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676D31200FB for ; Wed, 20 Nov 2019 21:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 E0bRC_hOYjFW for ; Wed, 20 Nov 2019 21:44:26 -0800 (PST) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 7DEDD12009C for ; Wed, 20 Nov 2019 21:44:26 -0800 (PST) Received: by mail-pf1-x436.google.com with SMTP id q13so1092540pff.2 for ; Wed, 20 Nov 2019 21:44:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=xtx2P9MPcuJSxFWPsH+kgqnS9qNXwMPhmtIGU9YVuzo=; b=rqwP+MkJq4xSfU8MaKR4W2+DfeS9XsJU4Jy/Fn7z6TEvE2ZIa2bvjdO/rS4/FtARVX YdukyZ3jJK0qfpJdBSvTIuz1QIzdd2ITl1nKPG/X0RIyV/5qWuXvgfDce5dwbgKiA7xk m48wvbEyma/jpYxDXtfJJLSX1lyy1gTvhhih6qARZoiYFdJYsUV8QCM+aeNG5S5fidaX ig4skRXZcKryAg658b6ONaMvOU9Uvrqkbhw7KitXub+AxDZRpElMWTbkPwOvg1VLqgIo eh5tVyr4X+4ADZzpcqaIGZM6uUm9NgSXL5Kw9dEO3uA504nHziVNNng9VBj+1svbj+tT mPIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=xtx2P9MPcuJSxFWPsH+kgqnS9qNXwMPhmtIGU9YVuzo=; b=A+tCBgKavMlsnRG9kLJ3qtvhBc+xXLql13TvD6VLq3/O10d2fGUYNsHmYATF54+ymw UTskii3Fomg8XFJSB2Z9uaOUR5Ux0DuUyddl+dRcVAEoGQGTJDSWV4ac8RuIcPmoEvEn yFWN4B50/rjx1CR4dKSqVMlCUwj6j9upHrU/viq2f6o4SsbufJ/ohOnO80ai1sLhYtdw HdZ+q7Kb0qdF3lvhpYvje486spACcHFca3q64Aa1GKf1firaDOfc4MjSWfsdFVb9SjqU UAZNaQR6UWoVdBIH6gghPrJjn28LjDIpFyZbB1XsQvwC6HaPkh/vwaCiirslEtWqFOw5 WrYQ== X-Gm-Message-State: APjAAAVODaLo76GPCB21uMGcrCCa2644BMct/LznAR1eHr/AknbhMtrG xbc68XBwD2cDtOUSCmO+ckw= X-Google-Smtp-Source: APXvYqxTgi+6Utht9fIcD9jdp+4lGKy82KwtI8I+8YX6ex87oHAvuTBYlWCOLFTPezYByD+JjBZzzA== X-Received: by 2002:aa7:86c2:: with SMTP id h2mr8571322pfo.248.1574315065980; Wed, 20 Nov 2019 21:44:25 -0800 (PST) Received: from svannotebook (dhcp-9be3.meeting.ietf.org. [31.133.155.227]) by smtp.gmail.com with ESMTPSA id r24sm1217925pgu.36.2019.11.20.21.44.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Nov 2019 21:44:25 -0800 (PST) From: "Valery Smyslov" To: "'Sean Turner'" , "'TLS List'" References: In-Reply-To: Date: Thu, 21 Nov 2019 08:44:21 +0300 Message-ID: <06fc01d5a02e$bb2b3b10$3181b130$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKGwWZ6z2czDM0oXE6NgAjmueUCdaYy2jww Content-Language: ru Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 05:44:28 -0000 Hi, I think it's a good starting point. I support adoption. Regards, Valery. > At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS WG > and the LAKE BOF, which is now a chartered WG [3]. After some discussions, > the ADs suggested [4] that the TLS WG consider whether this draft be adopted > as a TLS WG item. LAKE could then later specify/refer/adopt/profile it, as > appropriate. The authors revised cTLS and presented the revised draft at IETF > 106 [5]. At IETF 106 there was support for adoption of cTLS as a WG item. To > confirm this on the list: if you believe that the TLS WG should not adopt this as > a WG item, then please let the chairs know by posting a message to the TLS list > by 2359 UTC 13 December 2019 (and say why). > > NOTE: > : If the consensus is that this draft should be adopted as a WG item, then this > will necessarily result in a WG rechartering discussions. We would have gotten > to this rechartering discussion anyway now that DTLS 1.3 is progressing out of > the WG. > > Thanks, > Chris, Joe, and Sean > > [0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/ > [1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ > [2] https://github.com/ekr/draft-rescorla-tls-ctls > [3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ > [4] > https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCv > k > [5] https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-compact- > tls-13-00.pdf > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Nov 20 21:45:13 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950CF1200FB for ; Wed, 20 Nov 2019 21:45:12 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 XoSRgEwc8LSK for ; Wed, 20 Nov 2019 21:45:11 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 CDD3112009C for ; Wed, 20 Nov 2019 21:45:10 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id r7so1787319ljg.2 for ; Wed, 20 Nov 2019 21:45:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YsBRRiCud4E5qrH6R8yE29bo7DibkIge5dQha/4sT9s=; b=N+BJJ7CRnDTfFSNRaN6rRoXUa4W4pREd7BU7UvModILxnTB8LczYAljE+dd2UPTjpV EqRuKWbZRHUNZxPwWV7QnZxwC5Q+OSBOC/NNebka2ZDndxnFDkmhui27rPSykIHxZ4zt O82i2PNaR8fRmVfLJnp13sMR6RLIsqKrnyVERaULSmA5J231n8hPHyLX8mE5qzAJUzEj WUr36lg1+bgm1AuRIdich6eaKVTu+AP6uWPT4gdGRCxur+Mc76SyTozhJidkVMO1bjPa E6tI4/Ft3UlszC4QOqoRidekxXO6tL8KMa1O7mMOfCIHWIbhl1Q/oKOrqMdvULUW1cZf Q5mQ== 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=YsBRRiCud4E5qrH6R8yE29bo7DibkIge5dQha/4sT9s=; b=smwni49pSqqKnd03o3Q6Vvdq94UipOsoThH+K7AqRSfWTs2dp4WYncfDIBH7BbnOIm e+3YLs9buWnOVHVvQfW9NBJAoU7j1YUhnIMVDon0+NPpyNj/oNPiZTwWI32dkE4ZHV1b p1c4Cf3pXhyq6c+BMKRp/WC3A0uVRvvYDuMiEyXqOD/F7QLVcXu8GECHnCbgVJasHujP rEOCZEMkLh8cUZis0uUPTpb57U9ffFTSyyuoHEcSzNiOz0gepO9bJMDHRo9lCrN+zexr BClGhBZDPvmqG2BjFc7TB6Ndj04VMD3odYv1F0eEei3GmeXmUZkG6EPLp5jODxxjSCnM 6Htw== X-Gm-Message-State: APjAAAVcjrkxpbckmL+LMRzhm5FAUqnbnI9vDkZ0mjGs9WcHrUF1hK9+ GVeR1Cy7ZsYEMKOq41bngV6Jh4FX+va1DP3S+bWKZH4n X-Google-Smtp-Source: APXvYqyqzu5eE8R8NWiSiobyzupj7kDOMWOgKyU2ZZzwow/C+0qhQQ9HDsZbSOYBLJNxhtrU3eFiiA8zR2Rme9Sq09o= X-Received: by 2002:a2e:9016:: with SMTP id h22mr5631712ljg.137.1574315108837; Wed, 20 Nov 2019 21:45:08 -0800 (PST) MIME-Version: 1.0 References: <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> <20191117002249.GV34850@straasha.imrryr.org> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> <67c2ed4f-ce87-4d63-87bf-c38a36c8fb70@www.fastmail.com> In-Reply-To: <67c2ed4f-ce87-4d63-87bf-c38a36c8fb70@www.fastmail.com> From: David Schinazi Date: Thu, 21 Nov 2019 13:44:57 +0800 Message-ID: To: Martin Thomson Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="000000000000d3b0d70597d4cceb" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 05:45:12 -0000 --000000000000d3b0d70597d4cceb Content-Type: text/plain; charset="UTF-8" Thanks. I've updated the PR to take MT's suggestion s/SHOULD/will/. David On Thu, Nov 21, 2019 at 1:38 PM Martin Thomson wrote: > On Thu, Nov 21, 2019, at 11:19, David Schinazi wrote: > > resources. Therefore, the number of NewSessionTicket messages sent > > SHOULD be the minimum of the server's self-imposed limit and > > TicketRequestContents.count. > > Thanks for doing this David. > > Friendly amendment: remove the SHOULD from this sentence (it's a > consequence of the two other "SHOULD"s): > > Therefore, the number of NewSessionTicket messages sent will be the > minimum [...] > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000d3b0d70597d4cceb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks. I've updated the PR to take MT's suggestio= n s/SHOULD/will/.

David

On Thu, Nov 21, 2019 at 1:3= 8 PM Martin Thomson <mt@lowentropy.= net> wrote:
On Thu, Nov 21, 2019, at 11:19, David Schinazi wrote:
>=C2=A0 resources. Therefore, the number of NewSessionTicket messages se= nt
>=C2=A0 SHOULD be the minimum of the server's self-imposed limit and=
>=C2=A0 TicketRequestContents.count.

Thanks for doing this David.

Friendly amendment: remove the SHOULD from this sentence (it's a conseq= uence of the two other "SHOULD"s):

Therefore, the number of NewSessionTicket messages sent will be the minimum= [...]

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000d3b0d70597d4cceb-- From nobody Wed Nov 20 21:47:11 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4B21200FB for ; Wed, 20 Nov 2019 21:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=Vg62CT26; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OSxm4Ku1 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 vhmrTHTD8YRu for ; Wed, 20 Nov 2019 21:47:09 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1282512009C for ; Wed, 20 Nov 2019 21:47:09 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 33ACC223D7 for ; Thu, 21 Nov 2019 00:47:08 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 21 Nov 2019 00:47:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=PehfLml/jueupEdH7YGntn+LMi//WPj b5uexUCv2phs=; b=Vg62CT26MrW7wcc6Ehv6ZK4mk+2V5tOjD1iggLoqfvv1o/1 muUaNqxUpjb8nUOufDLbWkUBPTMlowQcskLDGi7INLlrmA0ma5by5mKU7WTa0WpD mOW4W6AW/pux9WxbAO6rM7UdRDx3gdyXz2MU75o4qVcbwZ5A2DcDB++nYKFyo/oX CvSs4yCNpmQZ1zQV/GYFi2N5TSweKX4f/3HoHm9ctSfzlWl2GUM4rfy254bR5oPK w66AYkhswPMXeaHECB+YmwFNEuHJsAlBOd5CJSFxuEI9EXa+E3UV/H7AsVVfJ6k3 ZICZbp1tHrprxPpmOvjli54ooVX9oec8ws/I6Ag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=PehfLm l/jueupEdH7YGntn+LMi//WPjb5uexUCv2phs=; b=OSxm4Ku1YMMHB7mqh5iKei GisVbxlufxJeg8IH4nv0KF48Np8PqjaNVbPvoe2ZpwF3KijPXi8N1TDL7+Pk32gb fScgz5sGOXuJCbHGS9NOFjHwm9hVD77UR+D5q6x8xll/6AMd4jcWLA6xgGMLTn30 ED4D0qgeMAcrls4kyz6nNH7963jh3BMYLtbnTgS2q5y72UjtDvlD5aakcTOY9Dkb 8fOphKVTsljqSrXvqFPKckxzNX6bWDNS//lRY3IwUYkSaX0nMO2e/iYOuX3udBL8 KYl1vp+kl8H1/nf7xY41w6LmkMbZMZFcMtBUb8OqyF7xvxuYoCyuWnWok8vQUNpg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehuddgkeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehloh ifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D6AB8E00A3; Thu, 21 Nov 2019 00:47:07 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: <58530328-e7ca-49bb-a734-45e628e0ed90@www.fastmail.com> In-Reply-To: References: Date: Thu, 21 Nov 2019 13:46:47 +0800 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 05:47:10 -0000 On Thu, Nov 21, 2019, at 13:36, Sean Turner wrote: > [...] if you believe that the TLS WG should not adopt this as a > WG item, then please let the chairs know by posting a message to the > TLS list by 2359 UTC 13 December 2019 (and say why). I know you want dissent, but I thought I would instead express support. From nobody Wed Nov 20 21:48:31 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60B612025D for ; Wed, 20 Nov 2019 21:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpAZmSrQVGrm for ; Wed, 20 Nov 2019 21:48:26 -0800 (PST) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 5F634120236 for ; Wed, 20 Nov 2019 21:48:26 -0800 (PST) Received: by mail-il1-x129.google.com with SMTP id p6so2135357ilp.1 for ; Wed, 20 Nov 2019 21:48:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RgpxZ5HHhfSPeE/NkNzeFhUP+shWsrf+DkDNOIwXCaU=; b=YAWgcHRJZOui5CRdM07kqmybkXLHRbQQHmRGjZOaBYnPAUDlW3xqjCsxBan4xQdcW4 TqMM2H4XUkBxvo0Z/dHM2j5ifSgdYYmeS9dwLzvJ+jQU5rB11e2MfejLKTd/gg+BXq+p 14GYcRyQjLGrQG03yXvEvEN73Ag3doho74Vqoib9u7INi351KGAws6Z0d2N1DK0j9IBO Kj0fNif6/pDxcWm2X4VfEjvXEbHeC5Qq8BpL9ni+IMtVPRKVfB/Esm2gf9Y9sE8pq8XV +J+XvXDoBADDgXLD+YYTG2qq6gdQ+D/LjiUkotqCXnBzvHEwQr6Sn0UVI5LmdRRNMlQr bH3g== 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=RgpxZ5HHhfSPeE/NkNzeFhUP+shWsrf+DkDNOIwXCaU=; b=ZqfqM+vWnB5cXxtle5i70i7d+uaYy8/Qu0YJ/Obw6RmSbarw2j1W7Va5e3ksMzVlza EDIl2kteNuIhrNpjTF65tEO4DqsEWwKIypGmMN8skEb7w1oREtvwHOtIM5PigsRPJL3N 5l0nSW7r8vOUo3TCJhotdICZskzcCcvsRNllfD8FmHu1yQq28egtpbR+7yqBL7y6o1Kb tiyteipNyXTL+jo+t7X9oo2yfNwZ6Gpummvyw2GSGZ63GtNXghLzrKoR72yJp5aSSNwy 7kZl34NP9IeQGV+RtpOaFR05qwB3Dp+hTFeg77kdOq1xNhAPTqBULnJ8W9r9xpuJ33AY kcsw== X-Gm-Message-State: APjAAAW/9Xcf7Vdoj6CYZQZVVDP59MvdRPh3sHcQ60qb+DwX47jVZgPd 6BpWanoIomrbPBU+37tUkQUmo3S2FYCVVzx8QNZewR/mFV8= X-Google-Smtp-Source: APXvYqwf+6fxrSspTpbrtNr0lbacGpmirx4qjWhajqcwVXqJKTPfQOLSBNeZcu+HS+MsTvXwWoNeIQQZCQNunbRYUN0= X-Received: by 2002:a92:690c:: with SMTP id e12mr7872872ilc.153.1574315305220; Wed, 20 Nov 2019 21:48:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Thu, 21 Nov 2019 13:48:13 +0800 Message-ID: To: Eric Rescorla Cc: Sean Turner , TLS List Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000009332d50597d4d8fa" Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 05:48:29 -0000 --0000000000009332d50597d4d8fa Content-Type: multipart/alternative; boundary="00000000000088b5d90597d4d849" --00000000000088b5d90597d4d849 Content-Type: text/plain; charset="UTF-8" I support adoption. In the spirit of Ted Hardie's comment on dividing the work into pieces, I'd like to suggest putting the handshake compression into a separate draft from the certificate compression. Certificate compression could be made into an extension that is usable in standard TLS. cTLS can then use it for free with extension monomorphization. On Thu, Nov 21, 2019 at 1:38 PM Eric Rescorla wrote: > I support adoption. > > On Wed, Nov 20, 2019 at 9:36 PM Sean Turner wrote: > >> At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS >> WG and the LAKE BOF, which is now a chartered WG [3]. After some >> discussions, the ADs suggested [4] that the TLS WG consider whether this >> draft be adopted as a TLS WG item. LAKE could then later >> specify/refer/adopt/profile it, as appropriate. The authors revised cTLS >> and presented the revised draft at IETF 106 [5]. At IETF 106 there was >> support for adoption of cTLS as a WG item.. To confirm this on the list: >> if you believe that the TLS WG should not adopt this as a WG item, then >> please let the chairs know by posting a message to the TLS list by 2359 UTC >> 13 December 2019 (and say why). >> >> NOTE: >> : If the consensus is that this draft should be adopted as a WG item, >> then this will necessarily result in a WG rechartering discussions. We >> would have gotten to this rechartering discussion anyway now that DTLS 1.3 >> is progressing out of the WG. >> >> Thanks, >> Chris, Joe, and Sean >> >> [0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/ >> [1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ >> [2] https://github.com/ekr/draft-rescorla-tls-ctls >> [3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ >> [4] >> https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk >> [5] >> https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-tls-13-00.pdf >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000088b5d90597d4d849 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adoption.

In the spirit of Te= d Hardie's comment on dividing the work into pieces, I'd like to su= ggest putting the handshake compression into a separate draft from the cert= ificate compression.=C2=A0 Certificate compression could be made into an ex= tension that is usable in standard TLS. cTLS can then use it for free with = extension monomorphization.

On Thu, Nov 21, 2019 at 1:38 PM Eric Resco= rla <ekr@rtfm.com> wrote:
I supp= ort adoption.

On Wed, Nov 20, 2019 at 9:36 PM Sean Turner <sean@sn3rd.com> wrote:
=
At IETF 105, ekr pr= esented cTLS (Compact TLS) [0][1][2] to both the TLS WG and the LAKE BOF, w= hich is now a chartered WG [3].=C2=A0 After some discussions, the ADs sugge= sted [4] that the TLS WG consider whether this draft be adopted as a TLS WG= item. LAKE could then later specify/refer/adopt/profile it, as appropriate= . The authors revised cTLS and presented the revised draft at IETF 106 [5].= =C2=A0 At IETF 106 there was support for adoption of cTLS as a WG item..=C2= =A0 To confirm this on the list: if you believe that the TLS WG should not = adopt this as a WG item, then please let the chairs know by posting a messa= ge to the TLS list by 2359 UTC 13 December 2019 (and say why).

NOTE:
: If the consensus is that this draft should be adopted as a WG item, then = this will necessarily result in a WG rechartering discussions.=C2=A0 We wou= ld have gotten to this rechartering discussion anyway now that DTLS 1.3 is = progressing out of the WG.

Thanks,
Chris, Joe, and Sean

[0] https://datatracker.ietf.org/doc/slid= es-105-tls-sessa-ctls/
[1] https://datatracker.ietf.org/doc/draft-= rescorla-tls-ctls/
[2] https://github.com/ekr/draft-rescorla-tls-ctls=
[3] https://datatracker.ietf.org/doc/draft-= rescorla-tls-ctls/
[4] https://mailarchive.ietf.o= rg/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk
[5] https://d= atatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-tls-13-00.= pdf
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000088b5d90597d4d849-- --0000000000009332d50597d4d8fa Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMb5MwaN/thbS6tcoSMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDgxMDA4MjIyMVoXDTIwMDIw NjA4MjIyMVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCapo7ARc1spX97SqdC5FrntcF1TsMY92BYdzbflXSKxq0yT835 3LNJtJ/J4lZC5QSgloRVy9U70CWQVLQUY+kXzFrEZkpgnHAtnlqZITjGGCj7+RAjWXbRHdOtvA/t EJKQJjEsuggE8qjMH2FoThWpOoAFfvLSw8aSir96C2tA8MV59tyI8ewdRBWKvQT6QTLPpPFmKJPJ H1idNM5tnwsWzADF6Xmz2tdLu4Nec4bGyzwHv4jGWrMfW6i5XO3cxFDLluvf7J6A2m+85dRtTC5q 2eqFRCpqqDsHcxsd8OFxpEe9ZhRw1XcMPjZmqHEPpJToDt9ReYetEffXx5DNqIcHAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFE77YQLCDddBAx5p+gBVO6KLah3VMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAW/09trVYeHUY5xMK3 1EuuFQyc7RaPOn+3qWJuDt4DVjNJl0uH27JsA30H70YGSPgNLo/KtC/1ejCAF2SjJrL+Qb93j4Cq BLI0djN/I9AHm7BVy4l+evwS6/7b8xwhKZSt+b2FuMSdpYRfxavlFKYo+WILW6gGx15o+KDRPusJ mo2s2mZDRTUfZ9e87SLTOUe/APBMIeKd+2Z9nnnBh0+d4LCn3tA4vmD1A/pIubUYaaTlLeZIQhpa D41mXEZUHdUVnGaIdPzJKNSkCeIUztyVBUJyYk3ROz9bCBjsHcUy2iqwuLGLaPI3bWjdwvxZ4kG4 dhjPuHq6t95sxpJ1F1X/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMb5MwaN/t hbS6tcoSMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAcu5aI4kgreLPGfLlCNGb/ jfv9Ll9GayyVTqKMZXrS9zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTExMjEwNTQ4MjVaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEARyTfrwS9/8BWcFIvDC0edHqn4Xst7/XRsmUHMjhJ 7v/heVUt9cgxgHp3zAD/UMK7mdvixX6Hbs6jPWAfL+QbvUXuDyhgWJP8iA8QR7xJ+oRK2cV4Wnuc 8mVKMn6AoIRo823Es7MsI/7AURqjjSDeoufyGh3z6qQYAsto8nHX9wq2QEXSqpniOSd0sRT+BGje H7Zoa6i/11DvN4wzoAslDV688E8JJdTKIbEbgD16cUcuGBR7VdIZnWzJpQ5OThYiZA/1KEWJgAIQ iX0t5mJRSj1IFOUyz9dfjAILbxQ/apdoBFunK210FvnbAlhP2xkefxfIzZUOnWj6PYCsfogViQ== --0000000000009332d50597d4d8fa-- From nobody Wed Nov 20 21:51:11 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4E0120800; Wed, 20 Nov 2019 21:51:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.110.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157431546969.935.6253215583742757307.idtracker@ietfa.amsl.com> Date: Wed, 20 Nov 2019 21:51:09 -0800 Archived-At: Subject: [TLS] The TLS WG has placed draft-rescorla-tls-semistatic-dh in state "Call For Adoption By WG Issued" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 05:51:09 -0000 The TLS WG has placed draft-rescorla-tls-semistatic-dh in state Call For Adoption By WG Issued (entered by Sean Turner) The document is available at https://datatracker.ietf.org/doc/draft-rescorla-tls-semistatic-dh/ From nobody Wed Nov 20 21:53:41 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EFB120143 for ; Wed, 20 Nov 2019 21:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 XSc7aEeQMzkd for ; Wed, 20 Nov 2019 21:53:38 -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 1696D1200FB for ; Wed, 20 Nov 2019 21:53:38 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xAL5m2kr018891; Thu, 21 Nov 2019 05:53:37 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Nzh3tU9UHXjyhllI9+hd33w4VlT3dsgFTBU/Oh2yaKk=; b=MQwSOzCBu9VWpEj7Z4tfEVUR8SWkALylZqFyMiAH6i2aUkl+8U4fTqi9zzGYvSAXna41 rwhY5grF8n/Sm15XZuoZpucTJlB1Q2ZK1DGjaYOej6hEgj/auJM3oPl44NoIQyPA1Sf7 aYHp7w7ejU+byCdkm0Y0I5sG2is1eIvfLN+Ga/EeUAXyHi/at9PoOZr+I/8BwftY7VRm 6awrG0xkiL9HKqmkKNSojhrzBeiXLndY2epMKog220K3gAgxvjerYiFsdLFedSwtpP0n ndDmTszXpvw6eQIieNFmY52PxyvEENlPpAsB5DK8ZhhUKNYpFzomR6yanSjtUTL0vpFc 6Q== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2wafwvpwq4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Nov 2019 05:53:37 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAL5khme006059; Thu, 21 Nov 2019 00:53:36 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2wadb07uy2-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 21 Nov 2019 00:53:35 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb2.msg.corp.akamai.com (172.27.123.59) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 21 Nov 2019 00:53:34 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 21 Nov 2019 00:53:34 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Thu, 21 Nov 2019 00:53:34 -0500 From: "Salz, Rich" To: Valery Smyslov , 'Sean Turner' , 'TLS List' Thread-Topic: [TLS] Adoption call for draft-rescorla-tls-ctls Thread-Index: AQHVoC2oBYcmiuNjf0Wbqi6NWBY+FqeVcOiAgACIrwA= Date: Thu, 21 Nov 2019 05:53:33 +0000 Message-ID: <0D989DED-FB62-4AC0-941E-2BDC8E64FFA4@akamai.com> References: <06fc01d5a02e$bb2b3b10$3181b130$@gmail.com> In-Reply-To: <06fc01d5a02e$bb2b3b10$3181b130$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191110 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.219.128] Content-Type: text/plain; charset="utf-8" Content-ID: <4B7E6703D8A49B4593D919952F891FD5@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-20_08:, , 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=767 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911210052 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-20_08:2019-11-20,2019-11-20 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 lowpriorityscore=0 priorityscore=1501 phishscore=0 clxscore=1011 mlxlogscore=739 impostorscore=0 suspectscore=0 bulkscore=0 malwarescore=0 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911210052 Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 05:53:39 -0000 PiAgICBJIHRoaW5rIGl0J3MgYSBnb29kIHN0YXJ0aW5nIHBvaW50LiBJIHN1cHBvcnQgYWRvcHRp b24uDQogDQpTdHJvbmdseSBhZ3JlZS4NCg0K From nobody Wed Nov 20 21:57:34 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064DB120143 for ; Wed, 20 Nov 2019 21:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 Ir2aW9E6_Oqk for ; Wed, 20 Nov 2019 21:57:31 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D882F1200FB for ; Wed, 20 Nov 2019 21:57:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.69,224,1571695200"; d="scan'208";a="412772035" Received: from 89-156-101-160.rev.numericable.fr (HELO [192.168.0.64]) ([89.156.101.160]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Nov 2019 06:57:29 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Karthik Bhargavan In-Reply-To: <0D989DED-FB62-4AC0-941E-2BDC8E64FFA4@akamai.com> Date: Thu, 21 Nov 2019 06:57:28 +0100 Cc: Valery Smyslov , Sean Turner , TLS List Content-Transfer-Encoding: 7bit Message-Id: <60C68483-1DBE-4A86-A6D5-4A6C0F96C27A@inria.fr> References: <06fc01d5a02e$bb2b3b10$3181b130$@gmail.com> <0D989DED-FB62-4AC0-941E-2BDC8E64FFA4@akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 05:57:33 -0000 I support adoption. > On 21 Nov 2019, at 06:53, Salz, Rich wrote: > >> I think it's a good starting point. I support adoption. > > Strongly agree. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Nov 20 21:59:56 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049EC120143 for ; Wed, 20 Nov 2019 21:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 No2AT6i3y68m for ; Wed, 20 Nov 2019 21:59:51 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC0F1200FB for ; Wed, 20 Nov 2019 21:59:51 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 3CD82332921; Thu, 21 Nov 2019 00:59:51 -0500 (EST) Date: Thu, 21 Nov 2019 00:59:51 -0500 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20191121055951.GV34850@straasha.imrryr.org> Reply-To: tls@ietf.org References: <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> <20191117002249.GV34850@straasha.imrryr.org> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 05:59:54 -0000 On Thu, Nov 21, 2019 at 11:19:36AM +0800, David Schinazi wrote: > Daniel has a IoT use-case where due to memory constraints, > a client knows it can only handle a certain number of tickets, > and therefore Daniel was wondering if it would make sense to > make the requested number of tickets a required maximum > (as in a RFC 2119 MUST). I agree. I am also looking for servers to not oversupply clients with excess tickets, and not expecting any obligation on the server to return as many as requested. > Additionally, > Daniel would prefer to see the document move forward. I am also keen for the document to move forward, it adds a very useful signal from the client to server. > Regarding Viktor's suggestion, I personally believe it would increase the > complexity of the proposal, There is no additional complexity in the protocol. The same extension structure is sent, and its interpretation is almost identical. The only difference is: * 0xff is the new zero (client declines use of tickets) * 0x00 is a new value to signal optional (reusable) tickets as-needed. * 0x01-0xfe are interpreted exactly as in the original draft! (But clients should be *encouraged* to send 1 on resumption). > and I don't see use-cases compelling enough to warrant that complexity. I > would rather keep this proposal as simple as possible. There are millions of Postfix MTAs that only support a single slot ticket cache, and where a server that sends more than 1 ticket causes multiple writes to the single-slot cache (hence part of the enthusiasm for the extension), but also writes to the cache (which is an external Berkeley DB) create excessive overhead. Also the server wastes CPU and network bandwidth sending unwanted tickets, but the client must not simply decline tickets, since it wants stale tickets to be refreshed. I have a hard understanding why a relatively simple proposal that meets the needs of many deployed MTAs is not a valid use-case. If you don't feel like authoring the text to make the requested change, I can probably contribute a pull request. At this time the details seem to have been ironed out in principle. -- Viktor. From nobody Wed Nov 20 22:14:40 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80CF512097B for ; Wed, 20 Nov 2019 22:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=XEd4Br6x; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ofdrlij0 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 akKvEtJAvD6s for ; Wed, 20 Nov 2019 22:14:34 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B08B612000F for ; Wed, 20 Nov 2019 22:14:34 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1554622474 for ; Thu, 21 Nov 2019 01:14:34 -0500 (EST) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Thu, 21 Nov 2019 01:14:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=8XrBeBsKd802ZtdAf7Jn66ZS4KAE92N CIhOcqsjkrPU=; b=XEd4Br6xtaBenj298WD6bRH/XpZM/gDWXVVg+nm5Qh4XqGU 4m081W5Wf0B5fAFgyd5J+ekCzeodvxCI1l6qO10u83rgxy+hjCIY62uahpBnmn2G ZFLZzuXbKjv9kXl9U6Ruh9jO+D9nouJff9anPBTKaBWgAQ3sbPpO9Qaz19NOllFO MgPIrwkSqcWv9ZM9WUDLUfl/iWfKtv/q0AvQs53TrMvfwH20/JKwG0FnwJJiMiAL 2tew0CcGiUK9EP5AjNqxbfAGonpTmVi83Npr24rQFxeO1dp/AENiXCycpjg9RUJy Ka7P5rPDbK/tXvtkkLGhRYAtH4tFRa0ORS7D5UA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=8XrBeB sKd802ZtdAf7Jn66ZS4KAE92NCIhOcqsjkrPU=; b=ofdrlij0hb9DNhMRcRP32H 3HGGbcp9csZpLI/PwDyjYR341QZBbLT6GTG4ebh11yqcTKgPiUIO6wgFQPypP8uZ dIgE/E01rS1XB0tV1/NWyE5+qh9zESaT81X6B1tqPwFvsevlFBYpv/e3YTMBGwcy WQsmyQzv1LQ+vIQThwUp8gm8WLkZUC+mHY7JSn0wYqNrRu3jl6l6OJqx/wfrJrvy ETkAwFRlt3faSBwKQ0lJ4hCBCK8rmxzeuqYDZku1ndJrhxrWhy05lJeKFoSrIOtt VoIta5NyUNjyP8AqW+kLFWB54C82/6gLeT2YsT6TwfzKv6E3dXeT5Xb0940xeXyw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehuddgleegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgne curfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght necuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C0A153C00A1; Thu, 21 Nov 2019 01:14:33 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <60C68483-1DBE-4A86-A6D5-4A6C0F96C27A@inria.fr> References: <06fc01d5a02e$bb2b3b10$3181b130$@gmail.com> <0D989DED-FB62-4AC0-941E-2BDC8E64FFA4@akamai.com> <60C68483-1DBE-4A86-A6D5-4A6C0F96C27A@inria.fr> Date: Thu, 21 Nov 2019 14:14:12 +0800 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 06:14:38 -0000 I support adoption. Best, Chris (no hat) On Thu, Nov 21, 2019, at 1:57 PM, Karthik Bhargavan wrote: > I support adoption. > > > On 21 Nov 2019, at 06:53, Salz, Rich wrote: > > > >> I think it's a good starting point. I support adoption. > > > > Strongly agree. > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Nov 20 22:17:43 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEBA12011F for ; Wed, 20 Nov 2019 22:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 0er6CStrn50l for ; Wed, 20 Nov 2019 22:17:40 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22CE812009C for ; Wed, 20 Nov 2019 22:17:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.69,224,1571695200"; d="scan'208";a="412774430" Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.47]) ([82.64.165.115]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 21 Nov 2019 07:17:38 +0100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Benjamin Beurdouche Mime-Version: 1.0 (1.0) Date: Thu, 21 Nov 2019 07:17:37 +0100 Message-Id: <4563D89C-F357-4EC8-9807-F94EC251FDF1@inria.fr> References: <0D989DED-FB62-4AC0-941E-2BDC8E64FFA4@akamai.com> In-Reply-To: <0D989DED-FB62-4AC0-941E-2BDC8E64FFA4@akamai.com> To: TLS List X-Mailer: iPhone Mail (17A878) Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 06:17:42 -0000 I support adoption. B. > On Nov 21, 2019, at 6:53 AM, Salz, Rich wrote: >=20 > =EF=BB=BF >>=20 >> I think it's a good starting point. I support adoption. >=20 > Strongly agree. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Nov 20 22:18:44 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB00D1200FB for ; Wed, 20 Nov 2019 22:18:42 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 vGT0VyKlicfi for ; Wed, 20 Nov 2019 22:18:40 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 761D112006F for ; Wed, 20 Nov 2019 22:18:40 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id k1so2080569ioj.6 for ; Wed, 20 Nov 2019 22:18:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FEvQa1C+SB0A1Bo832QxYNhCEr64wXLP4ffeUYw4J7I=; b=AYuDkXtjTBmerFPJUPy2IWE8cou3RWFxiBNVQB3nfB4v5ftAEvr+MIqinXUSJhwRr5 lgzCwH+Y/SefiwFAyRDT69yYbHshL2VZRPddiSB29gK7UNqYcseceWPBsyUM/aVAmOMP cE5t4rBCM83v7/suQfVs31Ip4jjZE34MObNaVGOPGjo5BwZ4drsDk9yAAAwNcwS0rSRY RomAADAnVM8v8TGuEk9yfb9nJt/8Mxt1x6genH8r2BrOF7sXuzOMkhN2ZCWzznNMu4t+ CqJhE6cvI7fKjH2ZDL9fSTZrob5RL8S1AnLitUoYskVG1OXZWvDUMZf+M+jvFz4rFCk0 VMbg== 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=FEvQa1C+SB0A1Bo832QxYNhCEr64wXLP4ffeUYw4J7I=; b=g0dyfHqp8jkwZ8AxX74QMcqkQS8Je0r1fYCg6DmB/FVJPNzlQyUJSzxMcDElEYA9Xy CUYhILGXhb9yxnIDO2uepcAPvY7NJTAbGTHXQiYBV0qaNlcDrNoklr1lAgQeG6EuHaIo /AIWIVmbiHCYPiUVokm60NAGOszj29C4+A3pMDU9dmiCKLu6EygMZKrJH54Ev442EVoG bFKktenIjZFjel4Wca92fx/BHSXt8eWxP8QWpYdz8SzqVp3dcbv+kOz/dS9ZVqB+RRsr vBjQZZl8azrKXrKTufj4/9OKhrnp0tAVFJfw5637XgJGNiqjGKF/Af8PEN1l6YVQajK6 YqmA== X-Gm-Message-State: APjAAAVeKD62XYHcTa2sjKx0w7fYG4AuDxCnnYdEgErNbhBSV28YVkLs 0xB3HBlLcouSF/nMmYfeT2o/1UYeMupcc0oESUE= X-Google-Smtp-Source: APXvYqwRrlWKiYHMPrV4cRiCa5tGqqdWldAf1ZT3BQjIzYmi0UhZE5wjSaZ+Tex8M8il5hVLaSX6uUVv2ea065ONHWM= X-Received: by 2002:a6b:ec08:: with SMTP id c8mr1355203ioh.257.1574317119537; Wed, 20 Nov 2019 22:18:39 -0800 (PST) MIME-Version: 1.0 References: <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> <20191117002249.GV34850@straasha.imrryr.org> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> <67c2ed4f-ce87-4d63-87bf-c38a36c8fb70@www.fastmail.com> In-Reply-To: From: Rob Sayre Date: Wed, 20 Nov 2019 22:18:26 -0800 Message-ID: To: David Schinazi Cc: Martin Thomson , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ac87590597d54487" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 06:18:43 -0000 --000000000000ac87590597d54487 Content-Type: text/plain; charset="UTF-8" So, the current PR says: "Clients can use TicketRequestContents.count to indicate the number of tickets they would prefer to receive. Servers SHOULD NOT send more tickets than TicketRequestContents.count, as clients will most likely discard any additional tickets. Servers SHOULD additionally place a limit on the number of tickets they are willing to send to save resources. Therefore, the number of NewSessionTicket messages sent will be the minimum of the server's self-imposed limit and TicketRequestContents.count." I would suggest two edits to this text: 1: The second sentence can read: "If servers send more tickets than TicketRequestContents.count, clients will likely discard excess tickets.". This avoids a "SHOULD NOT" that should be a "MAY" or unmentioned. 2: The third sentence is implementation advice, not an interoperability requirement: "Servers SHOULD additionally place a limit on the number of tickets they are willing to send to save resources." I think this sentence should be struck, or rewritten in non-2119 English. If the editors wish to keep the text, I think there should be a comma after "send". These proposed edits make sense to me, because servers can't know if their tickets will be used successfully (network problems, unreliable clients, etc). thanks, Rob On Wed, Nov 20, 2019 at 9:45 PM David Schinazi wrote: > Thanks. I've updated the PR to take MT's suggestion s/SHOULD/will/. > > David > > On Thu, Nov 21, 2019 at 1:38 PM Martin Thomson wrote: > >> On Thu, Nov 21, 2019, at 11:19, David Schinazi wrote: >> > resources. Therefore, the number of NewSessionTicket messages sent >> > SHOULD be the minimum of the server's self-imposed limit and >> > TicketRequestContents.count. >> >> Thanks for doing this David. >> >> Friendly amendment: remove the SHOULD from this sentence (it's a >> consequence of the two other "SHOULD"s): >> >> Therefore, the number of NewSessionTicket messages sent will be the >> minimum [...] >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000ac87590597d54487 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, the current PR says:

&qu= ot;Clients can use TicketRequestContents.count to indicate the number of ti= ckets they would prefer to receive. Servers SHOULD NOT send more tickets th= an TicketRequestContents.count, as clients will most likely discard any add= itional tickets. Servers SHOULD additionally place a limit on the number of= tickets they are willing to send to save resources. Therefore, the number = of NewSessionTicket messages sent will be the minimum of the server's s= elf-imposed limit and TicketRequestContents.count."

I would suggest two edits to this text:

1: = The second sentence can read: "If servers send more tickets than Ticke= tRequestContents.count, clients will likely discard excess tickets.". = This avoids a "SHOULD NOT" that should be a "MAY" or un= mentioned.

2: The third sentence is implementa= tion advice, not an interoperability requirement: "Servers SHOULD addi= tionally place a limit on the number of tickets they are willing to send to= save resources." I think this sentence should be struck, or rewritten= in non-2119 English. If the editors wish to keep the text, I think there s= hould be a comma after "send".

These pro= posed edits make sense to me, because servers can't know if their ticke= ts will be used successfully (network problems, unreliable clients, etc).

thanks,
Rob


On Wed, Nov 20,= 2019 at 9:45 PM David Schinazi <dschinazi.ietf@gmail.com> wrote:
Thanks. I've updated the = PR to take MT's suggestion s/SHOULD/will/.

David

On Thu, Nov 21, 2019 at 1:38 PM Martin Thomson <mt@lowentropy.net> wrote:
=
On Thu, Nov 21, 2019, at = 11:19, David Schinazi wrote:
>=C2=A0 resources. Therefore, the number of NewSessionTicket messages se= nt
>=C2=A0 SHOULD be the minimum of the server's self-imposed limit and=
>=C2=A0 TicketRequestContents.count.

Thanks for doing this David.

Friendly amendment: remove the SHOULD from this sentence (it's a conseq= uence of the two other "SHOULD"s):

Therefore, the number of NewSessionTicket messages sent will be the minimum= [...]

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000ac87590597d54487-- From nobody Wed Nov 20 22:25:14 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075691200FB for ; Wed, 20 Nov 2019 22:25:13 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 mSMY2fsvfBqZ for ; Wed, 20 Nov 2019 22:25:11 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93858120033 for ; Wed, 20 Nov 2019 22:25:10 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id v8so1860106ljh.5 for ; Wed, 20 Nov 2019 22:25:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nddCzLXLBoqlkytDKg878gMau8hOGkHkwBhA4+JZCPE=; b=DxCyjK0kEpruqPBvviXjQlBH3c7nXp2GaQDT4NeoLdG3HqJflRfWHfJdeXxlIES7pH pEPuFa5mOyQWJgIRLtw8937A3lITp/2LLit452x2BAzykS9jOGS9zIvc/UapzU5Zmj2D B05CWuwhVKFVRpMs7zZXAMdVJOQjiLgomTGDauOQiZz6ocnA56kxkH2hLdj0hO093tpN geUGt7iz35JA6mT5xYq6iMl0gN306/xJbOUuKstAG0Al1cGWhISjxBiMMPov5ZJ0MiQ4 +31XiDYZb9Q68f4Z1If1l8+uKH+IbKWC+WOl/wvTExtpfHjxwbSeJWLOuYLvZsbSGRRW oH/w== 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=nddCzLXLBoqlkytDKg878gMau8hOGkHkwBhA4+JZCPE=; b=kEt7On90mYD+4zYVsDxEbU8c1ezwjiH0WA9KrqeIw20a9DmMiZjctiSceXE79hKOPp 9Z3Xi8UujhWcyyJ9u97+FKopWeYKc59+meVghmCBgnUmloKxwqyYKxqsdfZoccUag+1r wi7pjXG7MkEfhLkDCHLjGKEMipB1+QyVxc3FLgYYVven9lTDan1ncYOi83v/UnuTnSDg DiB17SUv6f8kIIZWSr5pUMY7yE93X4DLwc182uCIhWMVxxbV8lHzjJHL97N+gtX/fQz9 CBcFToUzFz+jP0jf6ALZiq4oOAv6yslxsgNOJmUXrYOXzne5dF9kTz7/YPJKEnE5roRj uqEw== X-Gm-Message-State: APjAAAWVu6ljWAQsep55MnsRU0YKe4iP2q6jNwHo9tvOTTZZGKobR175 pxzLEANpHaD0eqBTo7XY+3B7jtoTXm64Y73oTZE= X-Google-Smtp-Source: APXvYqytMy4E+khYaRHPqBn4JwNMo9EP/RvkuBvZ3xrAfHiOnjc5IOpgY3VKoeGH1sHr76gO0W7Shai0J06unC3qXh4= X-Received: by 2002:a2e:9016:: with SMTP id h22mr5763644ljg.137.1574317508700; Wed, 20 Nov 2019 22:25:08 -0800 (PST) MIME-Version: 1.0 References: <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> <20191117002249.GV34850@straasha.imrryr.org> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> <67c2ed4f-ce87-4d63-87bf-c38a36c8fb70@www.fastmail.com> In-Reply-To: From: David Schinazi Date: Thu, 21 Nov 2019 14:24:57 +0800 Message-ID: To: Rob Sayre Cc: Martin Thomson , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000deb0030597d55bf8" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 06:25:13 -0000 --000000000000deb0030597d55bf8 Content-Type: text/plain; charset="UTF-8" Hi Rob, The SHOULD from your point (1) is there to address Daniel's concern about IoT. The SHOULD from (2) is indeed not required for interoperability, but important to ensure servers put this protection in place. That said, I've taken your suggestion to add a comma since that is clearer. Thanks! David On Thu, Nov 21, 2019 at 2:18 PM Rob Sayre wrote: > So, the current PR says: > > "Clients can use TicketRequestContents.count to indicate the number of > tickets they would prefer to receive. Servers SHOULD NOT send more tickets > than TicketRequestContents.count, as clients will most likely discard any > additional tickets. Servers SHOULD additionally place a limit on the number > of tickets they are willing to send to save resources. Therefore, the > number of NewSessionTicket messages sent will be the minimum of the > server's self-imposed limit and TicketRequestContents.count." > > I would suggest two edits to this text: > > 1: The second sentence can read: "If servers send more tickets than > TicketRequestContents.count, clients will likely discard excess tickets.". > This avoids a "SHOULD NOT" that should be a "MAY" or unmentioned. > > 2: The third sentence is implementation advice, not an interoperability > requirement: "Servers SHOULD additionally place a limit on the number of > tickets they are willing to send to save resources." I think this sentence > should be struck, or rewritten in non-2119 English. If the editors wish to > keep the text, I think there should be a comma after "send". > > These proposed edits make sense to me, because servers can't know if their > tickets will be used successfully (network problems, unreliable clients, > etc). > > thanks, > Rob > > > On Wed, Nov 20, 2019 at 9:45 PM David Schinazi > wrote: > >> Thanks. I've updated the PR to take MT's suggestion s/SHOULD/will/. >> >> David >> >> On Thu, Nov 21, 2019 at 1:38 PM Martin Thomson wrote: >> >>> On Thu, Nov 21, 2019, at 11:19, David Schinazi wrote: >>> > resources. Therefore, the number of NewSessionTicket messages sent >>> > SHOULD be the minimum of the server's self-imposed limit and >>> > TicketRequestContents.count. >>> >>> Thanks for doing this David. >>> >>> Friendly amendment: remove the SHOULD from this sentence (it's a >>> consequence of the two other "SHOULD"s): >>> >>> Therefore, the number of NewSessionTicket messages sent will be the >>> minimum [...] >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > --000000000000deb0030597d55bf8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rob,

The SHOULD from your point (1) = is there to address Daniel's concern about IoT.
The SHOULD fr= om (2) is indeed not required for interoperability, but important
to ensure servers put this protection in place.

T= hat said, I've taken your suggestion to add a comma since that is clear= er.

Thanks!
David

On Thu, Nov 21, 2= 019 at 2:18 PM Rob Sayre <sayrer@gma= il.com> wrote:
So, the current PR says:

"Clients can use TicketRequestContents.count to indicate the number= of tickets they would prefer to receive. Servers SHOULD NOT send more tick= ets than TicketRequestContents.count, as clients will most likely discard a= ny additional tickets. Servers SHOULD additionally place a limit on the num= ber of tickets they are willing to send to save resources. Therefore, the n= umber of NewSessionTicket messages sent will be the minimum of the server&#= 39;s self-imposed limit and TicketRequestContents.count."
I would suggest two edits to this text:

1: The second sentence can read: "If servers send more tickets than= TicketRequestContents.count, clients will likely discard excess tickets.&q= uot;. This avoids a "SHOULD NOT" that should be a "MAY"= or unmentioned.

2: The third sentence is impl= ementation advice, not an interoperability requirement: "Servers SHOUL= D additionally place a limit on the number of tickets they are willing to s= end to save resources." I think this sentence should be struck, or rew= ritten in non-2119 English. If the editors wish to keep the text, I think t= here should be a comma after "send".

The= se proposed edits make sense to me, because servers can't know if their= tickets will be used successfully (network problems, unreliable clients, e= tc).

thanks,
Rob

On Wed, N= ov 20, 2019 at 9:45 PM David Schinazi <dschinazi.ietf@gmail.com> wrote:
Thank= s. I've updated the PR to take MT's suggestion s/SHOULD/will/.
=
David

On Thu, Nov 21, 2019 at 1:38 PM Martin Thomson &l= t;mt@lowentropy.net<= /a>> wrote:
O= n Thu, Nov 21, 2019, at 11:19, David Schinazi wrote:
>=C2=A0 resources. Therefore, the number of NewSessionTicket messages se= nt
>=C2=A0 SHOULD be the minimum of the server's self-imposed limit and=
>=C2=A0 TicketRequestContents.count.

Thanks for doing this David.

Friendly amendment: remove the SHOULD from this sentence (it's a conseq= uence of the two other "SHOULD"s):

Therefore, the number of NewSessionTicket messages sent will be the minimum= [...]

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000deb0030597d55bf8-- From nobody Wed Nov 20 22:26:36 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0BF1209EA for ; Wed, 20 Nov 2019 22:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alipay.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 WLeovcIFJs_Y for ; Wed, 20 Nov 2019 22:26:30 -0800 (PST) Received: from out0-136.mail.aliyun.com (out0-136.mail.aliyun.com [140.205.0.136]) (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 395D9120800 for ; Wed, 20 Nov 2019 22:26:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alipay.com; s=default; t=1574317587; h=From:Content-Type:Mime-Version:Subject:Date:To:Message-Id; bh=PKGeel2JXoPc1BK1SNASTtD+QHpigJ1r16BxoMdE/c8=; b=a+bCUzVKRUeWdpbJ+uP1u1W/X6Hx5KNciqF+1XDDH04Whbzhy5de6PH0bppDuIpquMtwN6vNnpqCHpiQCUPKigjXK1+rAVo4xgV8nWoXp85Vv/n37OzqyhaUmH6QzScmJiuumzZspxsibMCrSLijybTGVuU1P1EiDrmgN6yGMRw= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R481e4; CH=green; DM=||false|; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03277; MF=kaishen.yy@alipay.com; NM=1; PH=DS; RN=1; SR=0; TI=SMTPD_---.G2FZch5_1574317584; Received: from 30.56.239.68(mailfrom:kaishen.yy@alipay.com fp:SMTPD_---.G2FZch5_1574317584) by smtp.aliyun-inc.com(127.0.0.1); Thu, 21 Nov 2019 14:26:26 +0800 From: Paul Yang Content-Type: multipart/signed; boundary="Apple-Mail=_CAD392F6-4963-483A-9822-7454D4E75E0A"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 21 Nov 2019 14:26:19 +0800 References: <0D989DED-FB62-4AC0-941E-2BDC8E64FFA4@akamai.com> <4563D89C-F357-4EC8-9807-F94EC251FDF1@inria.fr> To: TLS List In-Reply-To: <4563D89C-F357-4EC8-9807-F94EC251FDF1@inria.fr> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 06:26:35 -0000 --Apple-Mail=_CAD392F6-4963-483A-9822-7454D4E75E0A Content-Type: multipart/alternative; boundary="Apple-Mail=_F5E8F9F7-A95F-4D13-99CF-28F6A79BA93C" --Apple-Mail=_F5E8F9F7-A95F-4D13-99CF-28F6A79BA93C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99d like to see it=E2=80=99s adopted as well. It=E2=80=99s = important for low-bandwidth scenarios. Regards, Paul Yang > On Nov 21, 2019, at 2:17 PM, Benjamin Beurdouche = wrote: >=20 > I support adoption. > B. >=20 >> On Nov 21, 2019, at 6:53 AM, Salz, Rich wrote: >>=20 >> =EF=BB=BF >>>=20 >>> I think it's a good starting point. I support adoption. >>=20 >> Strongly agree. >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_F5E8F9F7-A95F-4D13-99CF-28F6A79BA93C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99d like to see it=E2=80=99s adopted as well. It=E2=80=99s important = for low-bandwidth scenarios.

Regards,

Paul Yang

On Nov 21, 2019, at 2:17 PM, Benjamin Beurdouche <benjamin.beurdouche@inria.fr> wrote:

I = support adoption.
B.

On Nov 21, 2019, at 6:53 = AM, Salz, Rich <rsalz@akamai.com> wrote:

=EF=BB=BF

 I think it's a good starting point. I = support adoption.

Strongly = agree.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

= --Apple-Mail=_F5E8F9F7-A95F-4D13-99CF-28F6A79BA93C-- --Apple-Mail=_CAD392F6-4963-483A-9822-7454D4E75E0A 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----- iQIzBAEBCAAdFiEEndC1x/yVcklg1DZ15HtIVEj/IsoFAl3WLgsACgkQ5HtIVEj/ IsqENw//UxX1np4rhbYKJ14Ml7idZoLjVrQMgcp12L0Nz0dTJ2oRcPxrTwNFkRwh 99/hzhsMwABQ3bJNTxaewsQs5DH4Ov3y5RNl35gb+Phl4C81XS3oiLngr7v7ay8W hJAuUvzZRhBVNsykEX22hhWl/LZfGWrr3AKzQAOSpuojEwdUJxls7sfHfQ2LsmPP DhZp/TpEK0SIrk+k6e2x5DeKotbrQW1Rrfg+WGg5ukmQxe15z0tiWUcew1gIyDMh rvYYkPkr6JXg3s2RoCEYzXleXkPlo/vp1US/Yy1pQ9YC9rBuJHHXfVprV/InjQtb jnvid9FUVtk8EVI7GLIxBLgT3l0f0jfmykIp/l3bSmDezraM0BU7sLW2mHHKm4Zw HNFgCOKEi0JkjVgmfDbqqtiXH+CxMGRDinuc4obKHbu4iFyYfFqzgHGvXaLIzlaN ccEdTsBLLq1QroN+q1h/SuIZAsfzddZ2Chf2ZVdy9htORHTtLNZ92e/cguCTF4vU nNvMbcmkfv2nXryXv3vqBwj5DvcfoSlg8tm+VHpJRpVN+x92YOUXVZHngKanRpsg JPNbqvZLq7yas3NmPt1efFjGlm/G3w2fN9Leuj6RHSwf4+NBGPXt6lzcbyHGJgBk w5FTecgCzPIR51AKUEf4Ei0HzhrJjTulCGS9fjwHno9H2ZDuh2s= =Tkym -----END PGP SIGNATURE----- --Apple-Mail=_CAD392F6-4963-483A-9822-7454D4E75E0A-- From nobody Wed Nov 20 22:35:25 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86301200B5 for ; Wed, 20 Nov 2019 22:35:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 AAfgFz3xXKt8 for ; Wed, 20 Nov 2019 22:35:22 -0800 (PST) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 7509A120033 for ; Wed, 20 Nov 2019 22:35:22 -0800 (PST) Received: by mail-il1-x12e.google.com with SMTP id m5so2231079ilq.0 for ; Wed, 20 Nov 2019 22:35:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T9NO60zmXV2lx2of1PxKxlNtKnGIy254H775FwBud4Q=; b=qwfxQx2y0LOn6MLrgiF2H2GSmyFe1a164AitZRtjb0xhW/cGJN0CFtK0eyPh3WYyvB aHI/O0ul3zCpm2vqHOjHRQVftJvHtSTvh/1KyBBwVyg9MS71S8t9bGrLlrN1FDWS5Ktx lekMfcowNuwm4DfOdNbSrW0myolfmYknGHycR4MvPBKE53qBYDh6l0z9lDnq9VaSGdjj jpdN+Q7JqbAuscDIIeaST8YmZk4ykVCDINowIp6vJAVNVAb210vFmfFWgbmEK1wkyk+e wGbCJY1e1QLr8wH0ySk4NMaNRjJqjXf59YWYK6G2rLECsIG2guQEz3StQ5NogkiyynEg I/SA== 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=T9NO60zmXV2lx2of1PxKxlNtKnGIy254H775FwBud4Q=; b=icDrilmeW2SyBUlxiYQ93dujVhTHViRzXbh999zI0DQhSbjPoYpF+rkTUAMyv5f7zp jh9jH58upksnMzB1I02O9MyrsBkoBCj8BKyk5eLsTUwiFCX/rr8lloCmPURBk21Flh47 MIacjiRxBXdl8Gz55xk2Sw9iElY5Vc2dJ0lCmm4ngoqqMEJRtzgVc9Vi/Jftvq96LAyA DbzRuZ8yf9SCEL51wHy1eLz4+qLHQscr/aQt4ZEltm6WpONJr42YvSxs6o60N4skFRpz JVfIfNj+c4wSKoaRLC5cSW+r5LMnLKD4HBTFdsIpvVIdqvsExbNmwgtcvy1ROGiZMzEm nMFQ== X-Gm-Message-State: APjAAAUA0kw/I9MenDDj6aczAlMg4jKCTxk1tKAgzK7IZGGn3ILQVNGc T+RNX4y7yjzX2gHKMyZvXFxv5ykEqDtFZSEfM+A= X-Google-Smtp-Source: APXvYqw1y8eqFLOhUaZPsg5X1Lk8UTqKQYe+C1aq2vhbBP3elDV79cOo9gM58rtT6d89e/3Jt/DdPFWXI21dfQGkBZM= X-Received: by 2002:a92:5d49:: with SMTP id r70mr8622128ilb.257.1574318121575; Wed, 20 Nov 2019 22:35:21 -0800 (PST) MIME-Version: 1.0 References: <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> <20191117002249.GV34850@straasha.imrryr.org> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> <67c2ed4f-ce87-4d63-87bf-c38a36c8fb70@www.fastmail.com> In-Reply-To: From: Rob Sayre Date: Wed, 20 Nov 2019 22:35:09 -0800 Message-ID: To: David Schinazi Cc: Martin Thomson , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000666cf30597d58084" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 06:35:24 -0000 --000000000000666cf30597d58084 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 20, 2019 at 10:25 PM David Schinazi wrote: > Hi Rob, > > The SHOULD from your point (1) is there to address Daniel's concern about > IoT. > Is the idea that excess tickets would be wasteful? I think that's true, but I would also not want an IoT device that crashed or performed unnecessarily-poorly while processing excess tickets. > The SHOULD from (2) is indeed not required for interoperability, but > important > to ensure servers put this protection in place. > In that case, this issue belongs in the Security Considerations section. I understand that the concern is valid, but a "SHOULD" in this part of the document is not the right way to communicate it. thanks, Rob --000000000000666cf30597d58084 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 20, 2019 at 10:25 PM David Sc= hinazi <dschinazi.ietf@gmail= .com> wrote:
Hi Rob,

The SHOULD from your point (1) is there to address Daniel's concern a= bout IoT.

Is the idea that exce= ss tickets would be wasteful? I think that's true, but I would also not= want an IoT device that crashed or performed unnecessarily-poorly while pr= ocessing excess tickets.
=C2=A0
The SHOULD from (2) is inde= ed not required for interoperability, but important
to ensure ser= vers put this protection in place.

<= div>In that case, this issue belongs in the Security Considerations section= . I understand that the concern is valid, but a "SHOULD" in this = part of the document is not the right way to communicate it.

=
thanks,
Rob=C2=A0
--000000000000666cf30597d58084-- From nobody Wed Nov 20 22:45:40 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190A91201E0 for ; Wed, 20 Nov 2019 22:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=yQR0qhhh; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=r4bvHi3M 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 vdkqEQ046cAx for ; Wed, 20 Nov 2019 22:45:34 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on060e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::60e]) (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 0D7E212000F for ; Wed, 20 Nov 2019 22:45:33 -0800 (PST) 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=SRyZg+jGdTRtDPN2oEUMXqiQZyuRWspTcX99gTmMBlg=; b=yQR0qhhhcEr17d0Or+7zEH7sgckkuDJi6cMUR/iRsPJFlWy5fc2ZzBInw59QakqKlAMfdSQm+SuJqvzeIjV7oN9P87pvJ7FXUbt6QJkkXOk6KxdzTzvaedjX0Cbl/S7g4AbhkirrYYZKojZBgcs/SfX6EPaOrFtmy+xEFJRfOAk= Received: from VI1PR08CA0116.eurprd08.prod.outlook.com (2603:10a6:800:d4::18) by DB6PR0801MB1848.eurprd08.prod.outlook.com (2603:10a6:4:38::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.19; Thu, 21 Nov 2019 06:45:30 +0000 Received: from VE1EUR03FT046.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e09::208) by VI1PR08CA0116.outlook.office365.com (2603:10a6:800:d4::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.16 via Frontend Transport; Thu, 21 Nov 2019 06:45:30 +0000 Authentication-Results: spf=fail (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=none action=none header.from=arm.com; Received-SPF: Fail (protection.outlook.com: domain of arm.com does not designate 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 VE1EUR03FT046.mail.protection.outlook.com (10.152.19.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.17 via Frontend Transport; Thu, 21 Nov 2019 06:45:30 +0000 Received: ("Tessian outbound af6b7800e6cb:v33"); Thu, 21 Nov 2019 06:45:29 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 6637e7894a25165b X-CR-MTA-TID: 64aa7808 Received: from ca20027054d9.2 (ip-172-16-0-2.eu-west-1.compute.internal [104.47.9.52]) by 64aa7808-outbound-1.mta.getcheckrecipient.com id 2067F212-0134-4AB5-922C-F4D84C0A2E73.1; Thu, 21 Nov 2019 06:45:24 +0000 Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03lp2052.outbound.protection.outlook.com [104.47.9.52]) by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id ca20027054d9.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 21 Nov 2019 06:45:24 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RIddJ9mBlBXyFQx6crFJJwxGjetm/UgALb5Koi/sDdIAMtctlXR5g8UP5EDvdPYrJQTDEB6iQ9981KnbeBTGHwxPxfBWSqLlYx+DFySLxgrAFGy/f1lQc+uqT0EY17zwCm2RvlPrpSBYeMU/POvTXy4tM//r3ezrGozqRh56TgvqBvY7/57xJzdNpeijVqLW1fP5WHNUyi6SSBNnqK2U4r3fkQdJYygJaRVog/ZNCFDDam5WwUJ6b9hEo//lXOmgA9+2kv9UHB+PzgTtWmiUrPVoiCO1QzmjFql3SuqT/ge1GvYKSCmBAC0xUYN8drJ3zfSZmyfGeSDBMyG6kXVOfQ== 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=ITA6e0nZFT8B9x9ZnVfS8OSivBasKjGVjBo7vN/hNt4=; b=d7Yrynb5o3Ou6oSSh2t7nx8YWLwSLjzSkqcMAZ7xVeWXtDvJDVMCmfD4Pi4tuME4eYfsH5sAp/u58wtIItscSyBpk/Oyi0AgtKSNKJKbWuvnd8dJZJD6mCB26t/MxB29WGRKIRyracms6o9x3DL6iHmIa0BMlQzS77DvGJ1apf9VWk5Is+EJG4qGVhUsb4eiH8rhAugd3dpsYMvenqWnPN9mhS+/NjfcIHHu284VnI64Or/1DQ2fy5qInhkswOpcwog2vd6/UETfhzdR/V3OyE5AC4XJzRQZNfeL+GqE5mv9ERk2zNNzt0NY6noWiE9jMjpWG1ule9Xa2LWvLne8sg== 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=ITA6e0nZFT8B9x9ZnVfS8OSivBasKjGVjBo7vN/hNt4=; b=r4bvHi3M14wuF7L+avfbRbyaP7f/8+zz+l/R0sjOO+NhlGKHZv3J9z1Z0BIBlmc25TGvLlevilEmg6OiiQ9PihNXKr58RDrNgW9fpq2NuzkW2ofs0kS/Jzo63qIZQI8oUrRlN0bNSBYpGJ74I9wZchvsbHL2dAUHvl00r6mXm8c= Received: from AM0PR08MB4227.eurprd08.prod.outlook.com (20.179.33.142) by AM0PR08MB5490.eurprd08.prod.outlook.com (52.132.213.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.17; Thu, 21 Nov 2019 06:45:22 +0000 Received: from AM0PR08MB4227.eurprd08.prod.outlook.com ([fe80::840a:3730:6550:9ebf]) by AM0PR08MB4227.eurprd08.prod.outlook.com ([fe80::840a:3730:6550:9ebf%7]) with mapi id 15.20.2474.015; Thu, 21 Nov 2019 06:45:22 +0000 From: Thomas Fossati To: Sean Turner , TLS List Thread-Topic: [TLS] Adoption call for draft-rescorla-tls-ctls Thread-Index: AQHVoC2ncmjykdT5KEuMCiXI+u7waaeVLiIA Date: Thu, 21 Nov 2019 06:45:22 +0000 Message-ID: <579D3EA6-5A62-46DC-874D-488A9B0FE587@arm.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191110 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: eeda6f11-01f3-438f-fe8a-08d76e4e66c1 X-MS-TrafficTypeDiagnostic: AM0PR08MB5490:|AM0PR08MB5490:|DB6PR0801MB1848: X-MS-Exchange-PUrlCount: 6 x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0228DDDDD7 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39850400004)(366004)(396003)(376002)(136003)(199004)(189003)(66066001)(66556008)(76116006)(64756008)(66946007)(7736002)(91956017)(305945005)(33656002)(8936002)(5660300002)(8676002)(81156014)(81166006)(66476007)(14444005)(256004)(36756003)(6506007)(66446008)(76176011)(186003)(71200400001)(102836004)(26005)(71190400001)(6246003)(110136005)(446003)(6116002)(3846002)(86362001)(4326008)(478600001)(6486002)(2616005)(6436002)(11346002)(229853002)(58126008)(6306002)(2906002)(316002)(6512007)(25786009)(99286004)(966005)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB5490; H:AM0PR08MB4227.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: HiLxrkeRLfNjVhbfkOC4+PMMxIOSEMBleGy6aEy29h3bedhrzJoQbE4ImiwXrrJ/7+c5GPtxHF9fTldVBwFaSaljq0naDYfoBWz1PvqupVu+HEkVUE/VGmJq1pPTpw8g+nXxVrzxthiXH5fhcJV9X3TzmRlOVJAVt0D5LMfEjFC6c1Wckz2W5a8YOYn4r+S8aqZ/luPIin1LZodFJKPRK7a1lZMe3enQTU3a+e9Op4jesn+T5TSdcj5F98OUR2fy/6PHPeXcBLOLVQG9qr0vc+XEdVDgUWnuuwoPPfxv6l/g4kQx6KxKubFrIUU/X4RBtGblfuw2GqRdUijRrgufAbKdp9RuMaJf35mgkUfkeeagRvJLaOTno2kulRmtdcig9b+KiPu2Yq4UKuYV6HipcE/Ow/Ym2di1gE1Uq8fl//8fZjHI4/g1s17UcYEkoYTFM6NF0kX5xZp6bC4dW/7rD5P+oAJ5pEY+kZRZJk2Aj/Y= Content-Type: text/plain; charset="utf-8" Content-ID: <4E31E193B90D3A4E91EAD9A0400A05EE@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5490 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT046.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(396003)(39850400004)(346002)(1110001)(339900001)(40434004)(189003)(199004)(86362001)(186003)(22756006)(6506007)(336012)(446003)(436003)(11346002)(102836004)(26005)(36756003)(14454004)(76130400001)(5660300002)(76176011)(7736002)(26826003)(478600001)(966005)(2616005)(14444005)(305945005)(70586007)(23676004)(5024004)(25786009)(70206006)(2486003)(81166006)(81156014)(6116002)(8936002)(33656002)(99286004)(36906005)(316002)(8676002)(58126008)(110136005)(105606002)(6246003)(6512007)(6306002)(50466002)(4326008)(66066001)(47776003)(356004)(229853002)(2906002)(3846002)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0801MB1848; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Fail; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; MX:1; A:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: 092df299-97f5-46fb-ca3f-08d76e4e61ea X-Forefront-PRVS: 0228DDDDD7 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: VhN57sXYCSfdjnKtTrbXprTkX43kKnSecpjSkRqSGi+C75N+W8Sr0qAItzZsOMaUk7hLpcMggxfPNpu4z76XWhX2FumShGY2cmjcaBlCtcdpL3X6U1gQxMrJrUB97IDopmEUS5SgUjNp0n7WDFNFeMhBWB1A1vaWaehM9yGAC27fMUDuQYVptJ9IigBpqmkcGfEvZYwbSCFNphL7SRa4GJN2+AZHhPkk7fzrO1lpX3oN7AjD3r+jxiE2gYpOs6rliF3P3BVuQFDgxLXILTeoVAHpASkau4RHc0lAPfVwy5H3kbkkDda9s1dPU9eWpVxK2QOB9jevbPzN/TGri/C6Wx73ZsnDCm9/HGOCv2Zzh1xhrOd2mEC2qEfcG8oZgXTSO1guO9mC0LL90c9ACUlhSDb1tEAbrqx7NlpfS6/zVIi01RcYeIgyyT6UnEMoNT0jWh6DV8rMmfLFe3ZuS3eWh1HvWOXfRhKsTD2X9wRZZPU= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Nov 2019 06:45:30.5667 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: eeda6f11-01f3-438f-fe8a-08d76e4e66c1 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-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB1848 Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 06:45:38 -0000 WWVzLCBwbGVhc2UuDQoNCu+7v09uIDIxLzExLzIwMTksIDA1OjM2LCAiVExTIG9uIGJlaGFsZiBv ZiBTZWFuIFR1cm5lciIgPHRscy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBzZWFuQHNu M3JkLmNvbT4gd3JvdGU6DQoNCiAgICBBdCBJRVRGIDEwNSwgZWtyIHByZXNlbnRlZCBjVExTIChD b21wYWN0IFRMUykgWzBdWzFdWzJdIHRvIGJvdGggdGhlIFRMUyBXRyBhbmQgdGhlIExBS0UgQk9G LCB3aGljaCBpcyBub3cgYSBjaGFydGVyZWQgV0cgWzNdLiAgQWZ0ZXIgc29tZSBkaXNjdXNzaW9u cywgdGhlIEFEcyBzdWdnZXN0ZWQgWzRdIHRoYXQgdGhlIFRMUyBXRyBjb25zaWRlciB3aGV0aGVy IHRoaXMgZHJhZnQgYmUgYWRvcHRlZCBhcyBhIFRMUyBXRyBpdGVtLiBMQUtFIGNvdWxkIHRoZW4g bGF0ZXIgc3BlY2lmeS9yZWZlci9hZG9wdC9wcm9maWxlIGl0LCBhcyBhcHByb3ByaWF0ZS4gVGhl IGF1dGhvcnMgcmV2aXNlZCBjVExTIGFuZCBwcmVzZW50ZWQgdGhlIHJldmlzZWQgZHJhZnQgYXQg SUVURiAxMDYgWzVdLiAgQXQgSUVURiAxMDYgdGhlcmUgd2FzIHN1cHBvcnQgZm9yIGFkb3B0aW9u IG9mIGNUTFMgYXMgYSBXRyBpdGVtLiAgVG8gY29uZmlybSB0aGlzIG9uIHRoZSBsaXN0OiBpZiB5 b3UgYmVsaWV2ZSB0aGF0IHRoZSBUTFMgV0cgc2hvdWxkIG5vdCBhZG9wdCB0aGlzIGFzIGEgV0cg aXRlbSwgdGhlbiBwbGVhc2UgbGV0IHRoZSBjaGFpcnMga25vdyBieSBwb3N0aW5nIGEgbWVzc2Fn ZSB0byB0aGUgVExTIGxpc3QgYnkgMjM1OSBVVEMgMTMgRGVjZW1iZXIgMjAxOSAoYW5kIHNheSB3 aHkpLg0KDQogICAgTk9URToNCiAgICA6IElmIHRoZSBjb25zZW5zdXMgaXMgdGhhdCB0aGlzIGRy YWZ0IHNob3VsZCBiZSBhZG9wdGVkIGFzIGEgV0cgaXRlbSwgdGhlbiB0aGlzIHdpbGwgbmVjZXNz YXJpbHkgcmVzdWx0IGluIGEgV0cgcmVjaGFydGVyaW5nIGRpc2N1c3Npb25zLiAgV2Ugd291bGQg aGF2ZSBnb3R0ZW4gdG8gdGhpcyByZWNoYXJ0ZXJpbmcgZGlzY3Vzc2lvbiBhbnl3YXkgbm93IHRo YXQgRFRMUyAxLjMgaXMgcHJvZ3Jlc3Npbmcgb3V0IG9mIHRoZSBXRy4NCg0KICAgIFRoYW5rcywN CiAgICBDaHJpcywgSm9lLCBhbmQgU2Vhbg0KDQogICAgWzBdIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL3NsaWRlcy0xMDUtdGxzLXNlc3NhLWN0bHMvDQogICAgWzFdIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJlc2NvcmxhLXRscy1jdGxzLw0KICAgIFsy XSBodHRwczovL2dpdGh1Yi5jb20vZWtyL2RyYWZ0LXJlc2NvcmxhLXRscy1jdGxzDQogICAgWzNd IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJlc2NvcmxhLXRscy1jdGxz Lw0KICAgIFs0XSBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2xha2Uva0FD d1c3UFhybVRSYTRQdlhRMFRBMzR4Q3ZrDQogICAgWzVdIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvbWVldGluZy8xMDYvbWF0ZXJpYWxzL3NsaWRlcy0xMDYtdGxzLWNvbXBhY3QtdGxzLTEz LTAwLnBkZg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQogICAgVExTIG1haWxpbmcgbGlzdA0KICAgIFRMU0BpZXRmLm9yZw0KICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQoNCg0KSU1QT1JUQU5UIE5PVElDRTog VGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlk ZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5k IGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0 IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55 IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Wed Nov 20 22:54:30 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F37A120143 for ; Wed, 20 Nov 2019 22:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 pB0FGrZCfVB4 for ; Wed, 20 Nov 2019 22:54:20 -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 7B2DA1200B5 for ; Wed, 20 Nov 2019 22:54:20 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAL6rVjn014728; Thu, 21 Nov 2019 06:54:19 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=xi4cBzo57WTiMFA4IF2LiwFMEs/mk4e1mutRNyHfI20=; b=f9NKu9KNAGu41uX8Ao+EwqU1aZn+Xn/C1aTKbE+Ylxq9OhbpSUKzx8dpacY2qCzQ2wWS kOJh6O71+ps9Sf+6oJW8T4uv5wIS+j9xh1CfGlLEdHblUaTwhBtY/w3dsJ2PI7yg4SW0 UTkjfLU62NtSCjIAGLYg7Ku9mMkMrFciMeB5HT57dYB4H7tNLssHv/DO67qW9Sm5IIGH Im+svUrxXzfqUuK+5nTGycn+Obgcz/IHSCueqkvTd6KSVKK12EsCzdYnHM6+Wi0eisOv tqxRRKCLggBwETjktOi4CfTCHZStKtifTQpy6L5TM6c79wND45ETXoYBt7EDBWgFfOJV 9Q== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2wafq0e4qh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Nov 2019 06:54:19 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAL6lKGB004882; Thu, 21 Nov 2019 01:54:17 -0500 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2wadb2j6wp-1; Thu, 21 Nov 2019 01:54:17 -0500 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 2D38320073; Thu, 21 Nov 2019 06:54:17 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1iXgM3-0005UC-RY; Wed, 20 Nov 2019 22:54:15 -0800 Date: Wed, 20 Nov 2019 22:54:15 -0800 From: Benjamin Kaduk To: Rob Sayre Cc: David Schinazi , "TLS@ietf.org" Message-ID: <20191121065415.GX20609@akamai.com> References: <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> <67c2ed4f-ce87-4d63-87bf-c38a36c8fb70@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-20_08:, , 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=749 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911210058 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-20_08:2019-11-20,2019-11-20 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 phishscore=0 malwarescore=0 spamscore=0 adultscore=0 lowpriorityscore=0 priorityscore=1501 mlxscore=0 bulkscore=0 clxscore=1011 mlxlogscore=762 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911210058 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 06:54:22 -0000 On Wed, Nov 20, 2019 at 10:35:09PM -0800, Rob Sayre wrote: > On Wed, Nov 20, 2019 at 10:25 PM David Schinazi > wrote: > > > The SHOULD from (2) is indeed not required for interoperability, but > > important > > to ensure servers put this protection in place. > > > > In that case, this issue belongs in the Security Considerations section. I > understand that the concern is valid, but a "SHOULD" in this part of the > document is not the right way to communicate it. Is it more of a security consideration or an operational one? -Ben From nobody Wed Nov 20 22:56:48 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC07112020A for ; Wed, 20 Nov 2019 22:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=sn3rd.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 hPyFQthqHUgI for ; Wed, 20 Nov 2019 22:56:45 -0800 (PST) Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 3F6D9120804 for ; Wed, 20 Nov 2019 22:56:45 -0800 (PST) Received: by mail-qv1-xf2d.google.com with SMTP id s18so988365qvr.4 for ; Wed, 20 Nov 2019 22:56:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=qM+sRx7+ZqJIoRJHCQ9ZZDYLpRlZ7voGuECICDWOrYU=; b=MeNKyaBROtuljLZ7PG8Jt3BVuBFQ+qPDohTQSC6JN+5lCzC8AcSrHg3ghTdhkPym7o QebMZ7i0IEE5iVXHN7HuPrF8g1oMF7dJm+NZtuAtVeQ6VZ3rZPkFkH1vx8WTuhroDBO4 t6vU2w2Xcx1GrDHzNcJ34/EzBpysOrlBghSAI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=qM+sRx7+ZqJIoRJHCQ9ZZDYLpRlZ7voGuECICDWOrYU=; b=cj0jjyNdV0fCkXsDnn599TZ/cGC51ZU8h4h2q299J42N39FehgajIEN77uKnvKjlPw LFORXFqUIC7GACOcMx0QDxyekXfSYBZf+A5viVSHfgU31ivqOhq+prouyIaHv3wjUuM2 juuCvUsHEni3llHArpjgdLjRlEnYfdQ7g+yRYqrfFFWcUllQiVnCUv/QU4ZOd9/QCCbV sPlWLmAI03e/Gosm4vHPnS8pfNfttgF9FQROvubzm8lWZnrXkOJndIsqPecweZz5n/rt icPHqzB5Wn8UOcjRX5Lor3h5Mz/ZpSC8IMeIcl2r5r9GsoSlH++O0MTOijYmbVGufatB 7s0w== X-Gm-Message-State: APjAAAX+gVqLHwyg4+86n5Mkc7q4FEDyjhwQ9QEVkJqepf+e9zVJhTsc sKiIuTgfTa22LH/SDQ3MP3lW2BHlmShljA== X-Google-Smtp-Source: APXvYqzkFRdYQteVixbtwEtvWxIemfADJrOGQDFsF/zkPwF2t+w/2O4QBoH488kD4nOoHQBiAYt5Vg== X-Received: by 2002:ad4:55ef:: with SMTP id bu15mr6672492qvb.244.1574319404247; Wed, 20 Nov 2019 22:56:44 -0800 (PST) Received: from [5.5.33.79] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id v143sm174134qka.3.2019.11.20.22.56.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Nov 2019 22:56:43 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Thu, 21 Nov 2019 14:56:39 +0800 To: TLS List X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [TLS] Adoption call for draft-davidben-tls-batch-signing X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 06:56:47 -0000 At IETF 106 there was support for adoption of "Batch Signing for TLS" = [0] as a WG item. To confirm this on the list: if you believe that the = TLS WG should not adopt this as a WG item, then please let the chairs = know by posting a message to the TLS list by 2359 UTC 13 December 2019 = (and say why). NOTE: : If the consensus is that this draft should be adopted as a WG item, = then this will necessarily result in a WG rechartering discussions. We = would have gotten to this rechartering discussion anyway now that DTLS = 1.3 is progressing out of the WG. Thanks, Chris, Joe, and Sean [0] https://datatracker.ietf.org/doc/draft-davidben-tls-batch-signing/= From nobody Wed Nov 20 22:57:19 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 977BF120271; Wed, 20 Nov 2019 22:57:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.110.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157431943161.1061.11460776158183752707.idtracker@ietfa.amsl.com> Date: Wed, 20 Nov 2019 22:57:11 -0800 Archived-At: Subject: [TLS] The TLS WG has placed draft-davidben-tls-batch-signing in state "Call For Adoption By WG Issued" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 06:57:12 -0000 The TLS WG has placed draft-davidben-tls-batch-signing in state Call For Adoption By WG Issued (entered by Sean Turner) The document is available at https://datatracker.ietf.org/doc/draft-davidben-tls-batch-signing/ From nobody Wed Nov 20 22:59:50 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AC11201E0 for ; Wed, 20 Nov 2019 22:59:47 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 h8Co5qBsu3G9 for ; Wed, 20 Nov 2019 22:59:46 -0800 (PST) Received: from mail-il1-x142.google.com (mail-il1-x142.google.com [IPv6:2607:f8b0:4864:20::142]) (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 015DD1200B5 for ; Wed, 20 Nov 2019 22:59:45 -0800 (PST) Received: by mail-il1-x142.google.com with SMTP id p6so2280160ilp.1 for ; Wed, 20 Nov 2019 22:59:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Tymu0ProT5FjrVSIJedCbyjuR5vbB8wOxwZoH/UleTs=; b=To5IvzO4EHyy9og4/eCW2gYgcxhJsuJmxZ43obLmisfyBWypCwRsNJjV4/riRsDmdf Ul7+uy8M4Zc7zmpnPYshTei57IHl3R5wXmF8TkrQPigXMlecS4NnoZK+A2q/Gb5fKKlJ Tl36TRBuEnybVLvavm8zpzbFVAMJB6bsYKqeCavqixWllo8WvpWSHptXxnPOSXCg4uec 05WW2qbGnoudEi+mU5Cd7Jc7wQcV8za63nvmaDuHEMLUVS07lQXyEfgeRdMkAZ71x+rK DrMAAK32Q4f6Hvldv8kvDMAhp5Bhb4v1ziWV4p2oBgeH7wIQ7eYqVNxXGwCbtN2wpOIR 9CGg== 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=Tymu0ProT5FjrVSIJedCbyjuR5vbB8wOxwZoH/UleTs=; b=bnXSqsXS8kfyaivNkVH7uUlGo3NeqHjt0XrrXMaarH9Lgp/f5jzVnBrFVULhd8GZLK poavHI6EX7u2WVefPDtY1x3sSjxHwWXuOQHWCYSA09sG9s0Z7wxDLdUGPRo1+gYCWHn9 lQ9i417KCSnfjKs9XuTfwyfSTtU6oz4qcHUP6IqkfxL/k93pRBJLBaPOp9zRqWx4X8UR l0Cl0twG8CGtwD/1fXjTN26M3cBl9f+/YmBq3/gscHRZjlmb8ak7S5xTvbDWFR/exM2Q 7MrSANvb6vJNn3wVAPFkd1nIcPwPDUMOAUInvCQCqB+9M957bntWakd1pcd6G0nwWzs0 SWEQ== X-Gm-Message-State: APjAAAXtJ1iLCPiwbc1ZQdAxnB9uh63hA1d+MK2kiimsJ361iCR/BJ0S rP+WWAKFO1cPwpGXjF2HNqKeavI6/WC6z65A8D8= X-Google-Smtp-Source: APXvYqzFNGbi2j+xQt+GGC2SiAuyLv5XTUPCRp9WM7eX8YJj2IDAj1sq10pkRqfSsWIuwiNAO9Gi3u4lB4qrJMfDx6Q= X-Received: by 2002:a92:48cf:: with SMTP id j76mr8113127ilg.189.1574319585143; Wed, 20 Nov 2019 22:59:45 -0800 (PST) MIME-Version: 1.0 References: <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> <67c2ed4f-ce87-4d63-87bf-c38a36c8fb70@www.fastmail.com> <20191121065415.GX20609@akamai.com> In-Reply-To: <20191121065415.GX20609@akamai.com> From: Rob Sayre Date: Wed, 20 Nov 2019 22:59:32 -0800 Message-ID: To: Benjamin Kaduk Cc: David Schinazi , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a2b2ef0597d5d718" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 06:59:48 -0000 --000000000000a2b2ef0597d5d718 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 20, 2019 at 10:54 PM Benjamin Kaduk wrote: > On Wed, Nov 20, 2019 at 10:35:09PM -0800, Rob Sayre wrote: > > On Wed, Nov 20, 2019 at 10:25 PM David Schinazi < > dschinazi.ietf@gmail.com> > > wrote: > > > > > The SHOULD from (2) is indeed not required for interoperability, but > > > important > > > to ensure servers put this protection in place. > > > > > > > In that case, this issue belongs in the Security Considerations section. > I > > understand that the concern is valid, but a "SHOULD" in this part of the > > document is not the right way to communicate it. > > Is it more of a security consideration or an operational one? > Since it was referred to as a "protection", I thought it was a DoS concern. If it's only implementation advice, that's also valid, but it doesn't call for 2119 SHOULD language. The document should explain the operational concern without using "SHOULD". thanks, Rob --000000000000a2b2ef0597d5d718 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 20, 2019 at 10:54 PM Benjamin= Kaduk <bkaduk@akamai.com> w= rote:
On Wed, Nov 20, 2019 at 10:35:09PM -0800, Rob Sayre wrote:=
> On Wed, Nov 20, 2019 at 10:25 PM David Schinazi <dschinazi.ietf@gmail.com>= ;
> wrote:
>
> > The SHOULD from (2) is indeed not required for interoperability, = but
> > important
> > to ensure servers put this protection in place.
> >
>
> In that case, this issue belongs in the Security Considerations sectio= n. I
> understand that the concern is valid, but a "SHOULD" in this= part of the
> document is not the right way to communicate it.

Is it more of a security consideration or an operational one?

Since it was referred to as a "protection"= , I thought it was a DoS concern.

If it's only= implementation advice, that's also valid, but it doesn't call for = 2119 SHOULD language. The document should explain the operational concern w= ithout using "SHOULD".

thanks,
Rob

=C2=A0
--000000000000a2b2ef0597d5d718-- From nobody Wed Nov 20 23:11:30 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3C2120817; Wed, 20 Nov 2019 23:11:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157432028365.853.2554583768383349915@ietfa.amsl.com> Date: Wed, 20 Nov 2019 23:11:23 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-certificate-compression-07.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 07:11:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : TLS Certificate Compression Authors : Alessandro Ghedini Victor Vasiliev Filename : draft-ietf-tls-certificate-compression-07.txt Pages : 7 Date : 2019-11-20 Abstract: In TLS handshakes, certificate chains often take up the majority of the bytes transmitted. This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-07 https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-certificate-compression-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 20 23:20:09 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAAC120048 for ; Wed, 20 Nov 2019 23:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 8coAqQEC63gt for ; Wed, 20 Nov 2019 23:20:06 -0800 (PST) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 9B5471202A0 for ; Wed, 20 Nov 2019 23:20:05 -0800 (PST) Received: by mail-vs1-xe34.google.com with SMTP id x21so1587682vsp.6 for ; Wed, 20 Nov 2019 23:20:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mExfAvRqmeylZLqd1K6FFmMT0/zp7uI3q0rWx7kTj28=; b=OWGEY1me1hdlw5lfzOMoi/ruKx7HPO0VrisMyk9mpw1GIek3kiKro98pTDhcf9oo+S qDVhHUbVh4K8X/YS0aBXEG/ljddSlCZYcHpJ3AFhiyCbGqfN/A2B3KuvHlMWm/2M/L78 /232VMUPJsXgLeBn6wjPHYPBjEA86UFZKHbOA= 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=mExfAvRqmeylZLqd1K6FFmMT0/zp7uI3q0rWx7kTj28=; b=XVqahcukAPoxGbrS0TGP59eh6yGsC2P3CFNknN7TMIkv+YifdXw9+VBUY7tvHC5dGC /BxFnYEfSK6Cvm7Zko2Q++cEvQpTC2eB28rAjl2HgHo1GffRa/hK9CmGBN1wAoe6hWA1 pcjrqbgWBNsiz/7l5hSmcB7vnUaw27V42tizg9nAhS8OpJswzVcOAn6KS/FCwGN9sJwp heYloLFWx4TF4PKibIEoAT+8uZKxc7ajQdYCRj/S6w3o8Zhp0wr3UqLmZdtQ5olN8cQl 1w1WleTGxOrHkskaOrQvePPk6XLFFSwLnaQ7IbyW1cZDRWQJ8oz5mTn8KkdBFALwcxvt bLNw== X-Gm-Message-State: APjAAAU0scPDi/eEVCD/loC9kbGyG2Dp/fEZEHRDoWMfTlaJxdS6HQzo X4Q+4uacm6wvAv57lp9PGE3sof3WtLcBTooxzknRMw== X-Google-Smtp-Source: APXvYqwvuLBjNp62r+Ae1g1faagliHxv8WENkFzJEiHjvAaZ7rnNPdP5p9CyXdUZo28plKPWF3jwzUgNbeA7gdY3P8A= X-Received: by 2002:a67:5d02:: with SMTP id r2mr4842822vsb.212.1574320804348; Wed, 20 Nov 2019 23:20:04 -0800 (PST) MIME-Version: 1.0 References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> <20191118225035.GS20609@akamai.com> <430940ff-60f0-4ddd-9d71-9fe8b8ca9cae@www.fastmail.com> <20191121024019.GW20609@akamai.com> <892200AE-3D0A-4AF1-AD40-E3C46BE57F88@akamai.com> In-Reply-To: <892200AE-3D0A-4AF1-AD40-E3C46BE57F88@akamai.com> From: Nick Sullivan Date: Thu, 21 Nov 2019 15:19:47 +0800 Message-ID: To: "Salz, Rich" Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004e89d40597d62056" Archived-At: Subject: Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 07:20:08 -0000 --0000000000004e89d40597d62056 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 21, 2019 at 10:43 AM Salz, Rich wrote: > Likewise, I am okay with the "could be amended" text but in fact I > slightly prefer a new message type, for safety reasons. > How should we determine whether future extensions are permissible in the context of this new message? For example, draft-sullivan-tls-opaque-00 defines a new extension that is valid in CH and ClientCertificateRequest, but is not valid in CR. Does it make sense to require future extensions that can be used in ClientCertificateRequest to include a new tag, "CCR", in the IANA TLS ExtensionType Value table ? In any case, we can address that when/if we get to it. Here's the new proposed text: https://github.com/tlswg/tls-exported-authenticator/pull/55/files --0000000000004e89d40597d62056 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Nov 21, 2019 at 10:43 AM Salz= , Rich <rsalz@akamai.com> wro= te:
Likewise, I = am okay with the "could be amended" text but in fact I slightly p= refer a new message type, for safety reasons.

How should we determine whether future extensions are permissi= ble in the context of this new message? For example,=C2=A0draft= -sullivan-tls-opaque-00=C2=A0defines a new extension that is valid in C= H and=C2=A0ClientCertificateRequest, but is not valid in CR. Does it make s= ense to require future extensions that can be used in ClientCertificateRequ= est to include a new tag, "CCR", in the=C2=A0IANA TLS ExtensionType V= alue table?

In any case, we can address = that when/if we get to it. Here's the new proposed text:
--0000000000004e89d40597d62056-- From nobody Wed Nov 20 23:27:51 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380A612094E for ; Wed, 20 Nov 2019 23:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 zDsBPtJAV1S3 for ; Wed, 20 Nov 2019 23:27:47 -0800 (PST) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE05120A0E for ; Wed, 20 Nov 2019 23:27:47 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id i19so2246710qki.2 for ; Wed, 20 Nov 2019 23:27:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=J7ANYriisgWd3LfPjyOpYK3++pwYoIK327iirYo2HVQ=; b=aofZzciFmui5s6EIHhGrL7fIEKh7alnX6vDU9XV65e+G5q807m5pApjXqy8qKutpJH le4eamPHe0tvKIFZ8STA1Xqup1z84IDIkR0E0XI3XCa7pz82BKjTd+seXAmONFlfgo2C 0ZKS+E0gAXMV66WtyU7p0RMnHeQ9C0ZBhRcbA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=J7ANYriisgWd3LfPjyOpYK3++pwYoIK327iirYo2HVQ=; b=tT1Lcbi/O45xYNBbpnmU+AHy3J9wQP5sBg2kwhnmyMK7ugOiZITJJzlex/E3LiXOoS JEObhVmLU9UhyipJWDL8jYpzvGDPx8tSHmUDI94mxS5xb6F2ib7koNJIqYo1I66fecFb Sh5LH9WQszNPMicpSoqqmaixnxe1Wdv+ymiQJEcN2fsSbKBw3nb6yRdqnd8fV/BYqSK/ GzJQgCJ4ZmCAQeljoDCGSt7AU/leRu8VVJkzT0Gvf4mR6UaP/WHKbmJSBy0RV+EYfGUH TsPrHSGPSaKrG6KXELAkEHGU6XjNj4yu7Gy2ftpoVBpBP3cgScRQQLT2o/MPPzosRGW3 PH8A== X-Gm-Message-State: APjAAAUPXTWr4KEIo6Uv8tGxpP48OHrSP6CVkICgk67hltq6f5ZukC8i ADfdZSPalKUZo8Q4zi+zTENCe9fnQLtm2g== X-Google-Smtp-Source: APXvYqyS/6nm7FzQ90k6BJoCpzJp+Rqgh7mVTgMuYlRcRrezHeSShN/TA7rS1ybgla6MvfEVZpCQTg== X-Received: by 2002:a37:684b:: with SMTP id d72mr6384003qkc.314.1574321266354; Wed, 20 Nov 2019 23:27:46 -0800 (PST) Received: from [5.5.33.79] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id z5sm1015741qtm.9.2019.11.20.23.27.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Nov 2019 23:27:45 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 21 Nov 2019 15:27:41 +0800 References: <157432028365.853.2554583768383349915@ietfa.amsl.com> To: TLS List In-Reply-To: <157432028365.853.2554583768383349915@ietfa.amsl.com> Message-Id: <9EE2A5AA-A176-457B-B26A-C04E36B3620D@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-07.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 07:27:49 -0000 Minor update to add reference column to the registry that says =E2=80=9Cth= is document=E2=80=9D. spt > On Nov 21, 2019, at 15:11, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Layer Security WG of the = IETF. >=20 > Title : TLS Certificate Compression > Authors : Alessandro Ghedini > Victor Vasiliev > Filename : draft-ietf-tls-certificate-compression-07.txt > Pages : 7 > Date : 2019-11-20 >=20 > Abstract: > In TLS handshakes, certificate chains often take up the majority of > the bytes transmitted. >=20 > This document describes how certificate chains can be compressed to > reduce the amount of data transmitted and avoid some round trips. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-07 > = https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compressi= on-07 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-certificate-compression= -07 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Wed Nov 20 23:29:16 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD2912094E for ; Wed, 20 Nov 2019 23:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 6yrM1fFrO3At for ; Wed, 20 Nov 2019 23:29:14 -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 6AC2A12004C for ; Wed, 20 Nov 2019 23:29:14 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xAL7Nk37003916; Thu, 21 Nov 2019 07:29:13 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=l8db810FEXUlCqAGMd2dDyhXzoq1SNRxJBxbAq9iuJg=; b=lIVaBw70lgSPmOaCt/zS/NmkZA50TIt3ly3+YA+MLpr+xXRMDffzdsMN+1XMld6o8ZWg AEDv8gDG5z1aYUm742238U127iKn5J11h2ojeS/yt0fMNBybis9LEB64+bQ+xq7ZSaWn W4FiHcN+JoLzNj9s81cp+MViHJWsjOxbtZFGyaD3z4lU8f+UcSUy58rQp0eVOWrpYsAO fet+F31ETANdtPytkrlnTmJoZRh3LxR7+Yx/yeaR7XlBIvQbY17tEmaKqkHgSR/gedSO xiVwrhcce7eL/dsOY8bFp2JOaf9qwAu2SHBdVjtlQz4PyGDaO0N+2vQPyY4X5gcQbuYi 3A== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2wcq3dr94w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Nov 2019 07:29:13 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAL7GvWf007915; Thu, 21 Nov 2019 02:29:12 -0500 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint1.akamai.com with ESMTP id 2wadb08dyb-1; Thu, 21 Nov 2019 02:29:10 -0500 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 9551980D1A; Thu, 21 Nov 2019 07:29:10 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1iXgtp-0005Xz-9M; Wed, 20 Nov 2019 23:29:09 -0800 Date: Wed, 20 Nov 2019 23:29:08 -0800 From: Benjamin Kaduk To: Rob Sayre Cc: David Schinazi , "TLS@ietf.org" Message-ID: <20191121072908.GY20609@akamai.com> References: <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> <67c2ed4f-ce87-4d63-87bf-c38a36c8fb70@www.fastmail.com> <20191121065415.GX20609@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-20_08:, , 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=763 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911210064 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-20_08:2019-11-20,2019-11-20 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 spamscore=0 impostorscore=0 phishscore=0 suspectscore=0 mlxscore=0 clxscore=1015 bulkscore=0 lowpriorityscore=0 priorityscore=1501 mlxlogscore=773 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911210065 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 07:29:15 -0000 On Wed, Nov 20, 2019 at 10:59:32PM -0800, Rob Sayre wrote: > On Wed, Nov 20, 2019 at 10:54 PM Benjamin Kaduk wrote: > > > On Wed, Nov 20, 2019 at 10:35:09PM -0800, Rob Sayre wrote: > > > On Wed, Nov 20, 2019 at 10:25 PM David Schinazi < > > dschinazi.ietf@gmail.com> > > > wrote: > > > > > > > The SHOULD from (2) is indeed not required for interoperability, but > > > > important > > > > to ensure servers put this protection in place. > > > > > > > > > > In that case, this issue belongs in the Security Considerations section. > > I > > > understand that the concern is valid, but a "SHOULD" in this part of the > > > document is not the right way to communicate it. > > > > Is it more of a security consideration or an operational one? > > > > Since it was referred to as a "protection", I thought it was a DoS concern. > > If it's only implementation advice, that's also valid, but it doesn't call > for 2119 SHOULD language. The document should explain the operational > concern without using "SHOULD". I disagree with your premise on when BCP 14 keyword usage is appropriate. Which is to say, I think the "SHOULD" is fine for operational concerns. -Ben From nobody Wed Nov 20 23:32:44 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13AD2120977 for ; Wed, 20 Nov 2019 23:32:43 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 aw9ViamVErkq for ; Wed, 20 Nov 2019 23:32:41 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 485BA120048 for ; Wed, 20 Nov 2019 23:32:41 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id j13so2320614ioe.0 for ; Wed, 20 Nov 2019 23:32:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vQsibQ+mD/pM8jo1QBHQ4k9XSsPhvaLV3uqjszZNuVU=; b=FVNEvMqAXEw3q9jnnvXtYZo/A72JBvMcLpHlXjNVADwMtCdtKArSAamlqYcz5qjZXz LokSAMbIKJ6MSmkcAKkwlbiHD4wqcRuEtBrbQMLc7O2W2dsWythFuibt1ooEi2hA0xYo +7w9bTOunNsWz2rYyYDGjgeyTcGUUvXqLIq0ga/UJWW5SyPYxEXDJAhC1oxnd9CBmhDJ oNobM6jX5P9aIkri6KJBnK0AB47Dzrr8CTmmBpL/rmvuDTIJ7tgW8BVa0nYhEm+p3aB7 M0GTI7ikr1sXaWCOqEYDMSALNEd3TE1jKu42aiq2AVGoLfu0zUPG/ZxSMGRiYnGXR2iP PL/A== 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=vQsibQ+mD/pM8jo1QBHQ4k9XSsPhvaLV3uqjszZNuVU=; b=rjOOOD1nBS1L/Fd/COHHT7V5FGYOL7xPavR80dE0dYILqwoICSWAt9AenW6RtIedkZ jH3HhmUZeLgfkJ46ziB+5JTEjwSFnX5uBSEraUJekUKxDUpwiuZ/D8lfaUWLwQm/h7GM vOJZGkCt8kq77ii3UKnlajI5zY2Ps0pqjP7TFT0riPmOCVo7a2rUeltbXzfDs808cMNs 12NMcjwVPakGaxbdKW/gxxIfMt6/MU/SUET8dcBJwv0eavFK2SaGF580POtCjj/xxxIp BeVrwBYehDYpezrjL+KK//Cs/u5JKJmptkiVMfZg2btknNauj8Y6LueaCFz0YavPzsoZ 020A== X-Gm-Message-State: APjAAAWUTpcoEVQ+BFLIr36nzIhC9aTkJFEVc4pB1CxZV7Wm2mlaDPKD +Ce5AFt2btmeLxJ0ue0JykOLfJkjWqOd15EgtHo= X-Google-Smtp-Source: APXvYqx0kFqYP9p7AuXgwNeYQE+ZoVz2iAqgYgQmFjAaLOY0qCZjbOTmQ2Xq4HrVkgBuCDARuFn8pYtBovyEOjMWesQ= X-Received: by 2002:a5d:8b83:: with SMTP id p3mr6074122iol.189.1574321560535; Wed, 20 Nov 2019 23:32:40 -0800 (PST) MIME-Version: 1.0 References: <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> <67c2ed4f-ce87-4d63-87bf-c38a36c8fb70@www.fastmail.com> <20191121065415.GX20609@akamai.com> <20191121072908.GY20609@akamai.com> In-Reply-To: <20191121072908.GY20609@akamai.com> From: Rob Sayre Date: Wed, 20 Nov 2019 23:32:28 -0800 Message-ID: To: Benjamin Kaduk Cc: David Schinazi , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000060c67d0597d64d4c" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 07:32:43 -0000 --00000000000060c67d0597d64d4c Content-Type: text/plain; charset="UTF-8" On Wed, Nov 20, 2019 at 11:29 PM Benjamin Kaduk wrote: > > I disagree with your premise on when BCP 14 keyword usage is appropriate. > Which is to say, I think the "SHOULD" is fine for operational concerns. BCP 14, section 6: "Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation..." thanks, Rob --00000000000060c67d0597d64d4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 20, 2019 at 11:29 PM Benjamin= Kaduk <bkaduk@akamai.com> w= rote:

I disagree with your premise on when BCP 14 keyword usage is appropriate. Which is to say, I think the "SHOULD" is fine for operational con= cerns.

=C2=A0BCP 14, section 6:
<= br>
"Imperatives of the type defined in this memo must be us= ed with care and sparingly.=C2=A0 In particular, they MUST only be used whe= re it is actually required for interoperation..."=C2=A0

=
thanks,
Rob

--00000000000060c67d0597d64d4c-- From nobody Wed Nov 20 23:37:13 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C01120255 for ; Wed, 20 Nov 2019 23:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 QbAmYTkLRxYe for ; Wed, 20 Nov 2019 23:37:10 -0800 (PST) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 D9A05120048 for ; Wed, 20 Nov 2019 23:37:09 -0800 (PST) Received: by mail-ua1-x931.google.com with SMTP id z9so675556uan.3 for ; Wed, 20 Nov 2019 23:37:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nvjQQRq0zXdR8q11b6tj4HNILZh1vJT86ePunNFYVns=; b=v+eCZNa3gEKrdkhVCmL0NmHdIvow1KllB+ANM45LYTPfmGQr6dEvzslzM/WgUi8s4M 899IA2tZs1BjfMLBUx67oPNVqFEwrOsKMHpTOWc8nhhcJf8hCBJSeq6OUwZ4JMzhl/fb j4wypUZmelr/7LuonZ2hjqdYyoscAar/drNjo= 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=nvjQQRq0zXdR8q11b6tj4HNILZh1vJT86ePunNFYVns=; b=dbfMHrSGotdbChDX+AJDVyjI+en+DZVrg0ygPmrHw/+yB4NQdEGVYBg+tkUDuQoXhv KOVzIybrWADK5/hrloCcloNivJCdF/bODr1il4w7XNnWptGguxXq6BWGKbamVQ7DR6wU nm9qUFUvVvO/rsjN6Vo9t3n+Kf/owsASxIl4RIPWIuODrQRCc288jLUDpqiwcciOefpL WZ05Ljld72N7aWRgTMz0QuDVkxYltSKRhJXmS0XyPZDbPUMVZy39p+VfoPIszHnXyyUm 0+m3hYdaX9K4o9Roa6wLh2uWuAPn4NM84MCxI6M3n3JJQkeb1zhMzqESpw0Z9833c9N7 K5FA== X-Gm-Message-State: APjAAAWjf6Zolwgrz7DDP8V4vTGhwnXadRH2uJK5iVcb8dUkrfqwdiGy O2vu9XiPQw4VOkNtIiK+Q4B/PfzcR7NlUCCD+b2qOKnHdV5ugQ== X-Google-Smtp-Source: APXvYqwT6nuUT2vz0Z4odt+tOEsCsXaNy+VgUtjeduO0A6JaoYCyt4gzRkg7M+VawZfEnckE7cdvCynBdJwpFTFv9rY= X-Received: by 2002:ab0:393:: with SMTP id 19mr4707360uau.58.1574321828590; Wed, 20 Nov 2019 23:37:08 -0800 (PST) MIME-Version: 1.0 References: <97e71c36-9b73-4142-898d-68d345d42d81@www.fastmail.com> In-Reply-To: <97e71c36-9b73-4142-898d-68d345d42d81@www.fastmail.com> From: Nick Sullivan Date: Thu, 21 Nov 2019 15:36:52 +0800 Message-ID: To: Martin Thomson Cc: "" Content-Type: multipart/alternative; boundary="0000000000005b37930597d65de8" Archived-At: Subject: Re: [TLS] More flexible signature_algorithm selection for Delegated Credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 07:37:11 -0000 --0000000000005b37930597d65de8 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 21, 2019 at 1:43 PM Martin Thomson wrote: > On Thu, Nov 21, 2019, at 11:54, Nick Sullivan wrote: > > At IETF 106, we discussed adding the ability to advertise specific > > signature algorithms for use in DCs without requiring clients to have > > to support these signature algorithms in leaf certificates. > > Is the intent with supporting an empty extension to support backward > compatibility? I think that deployed implementations can probably just > change to use the list so that we don't have to include this additional > flexibility. I'd prefer to always have a list. > Even simpler. Once we have a pre-allocated codepoint, the can be released without conflict with deployed code. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000005b37930597d65de8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Nov 21, 2019 at 1:43 PM Marti= n Thomson <mt@lowentropy.net>= ; wrote:
On Thu,= Nov 21, 2019, at 11:54, Nick Sullivan wrote:
> At IETF 106, we discussed adding the ability to advertise specific > signature algorithms for use in DCs without requiring clients to have =
> to support these signature algorithms in leaf certificates.

Is the intent with supporting an empty extension to support backward compat= ibility?=C2=A0 I think that deployed implementations can probably just chan= ge to use the list so that we don't have to include this additional fle= xibility.=C2=A0 I'd prefer to always have a list.
=
Even simpler. Once we have a pre-allocated codepoint, the ca= n be released without conflict with deployed code.=C2=A0

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000005b37930597d65de8-- From nobody Wed Nov 20 23:59:01 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284C0120147 for ; Wed, 20 Nov 2019 23:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 gEv33rcQtMly for ; Wed, 20 Nov 2019 23:58:58 -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 C346F120048 for ; Wed, 20 Nov 2019 23:58:58 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xAL7w8Pb017385; Thu, 21 Nov 2019 07:58:57 GMT 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 : mime-version; s=jan2016.eng; bh=nJwPKQ9wJZxASgSuV6lzD5Ypv6F/dGs4RAvrmQeEKnk=; b=g+vLjNknIyZu1hk55YoDSY98sQju50DxqQonc3tVU0b0PN4zMq0MQymISMRkeTtBCPrq iTVrxATECyVJ+RQAR+77ZYWxkU2Q+4sOCQ7HiIzEwKWVJl7FweGit3TyaUhRPo3ZS9HL U5GnBOaMiS8UPGtuwWmqEoJsIri5diDGvFswriD7cTlVQybKix5VVKCBMvZE1ojqtTgd AIEodp/BKr4QRmccJ7sQiKJZPykHAZ3z3CS3k1ehpORC4+tQk0bHkBvUtecp7jfUMWS2 KlR2PGeq0tIXVgEnlN3+CfoWdbd6IXMnweNckwztHodjx9Nwj1EHqBdpL5T16JFouVbO qA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2wafwvqag2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Nov 2019 07:58:57 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAL7lABe014818; Thu, 21 Nov 2019 02:58:56 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint1.akamai.com with ESMTP id 2wadb08mx5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 21 Nov 2019 02:58:56 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 21 Nov 2019 02:58:55 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Thu, 21 Nov 2019 02:58:55 -0500 From: "Salz, Rich" To: Nick Sullivan CC: "tls@ietf.org" Thread-Topic: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09 Thread-Index: AQHVoBUT1euH8Nr4XEGrD55Dql/E5qeVxKkA///HGoCAAJEKAA== Date: Thu, 21 Nov 2019 07:58:54 +0000 Message-ID: <13DF0FBB-25E8-47B5-91C8-19F636C1EC59@akamai.com> References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> <20191118225035.GS20609@akamai.com> <430940ff-60f0-4ddd-9d71-9fe8b8ca9cae@www.fastmail.com> <20191121024019.GW20609@akamai.com> <892200AE-3D0A-4AF1-AD40-E3C46BE57F88@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191110 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.219.128] Content-Type: multipart/alternative; boundary="_000_13DF0FBB25E847B591C819F636C1EC59akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-20_08:, , 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=640 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911210069 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-20_08:2019-11-20,2019-11-20 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 lowpriorityscore=0 priorityscore=1501 phishscore=0 clxscore=1015 mlxlogscore=615 impostorscore=0 suspectscore=0 bulkscore=0 malwarescore=0 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911210070 Archived-At: Subject: Re: [TLS] Secdir last call review of draft-ietf-tls-exported-authenticator-09 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 07:59:00 -0000 --_000_13DF0FBB25E847B591C819F636C1EC59akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PkluIGFueSBjYXNlLCB3ZSBjYW4gYWRkcmVzcyB0aGF0IHdoZW4vaWYgd2UgZ2V0IHRvIGl0LiBI ZXJlJ3MgdGhlIG5ldyBwcm9wb3NlZCB0ZXh0Og0KaHR0cHM6Ly9naXRodWIuY29tL3Rsc3dnL3Rs cy1leHBvcnRlZC1hdXRoZW50aWNhdG9yL3B1bGwvNTUvZmlsZXM8aHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX3Rsc3dnX3Rscy0y RGV4cG9ydGVkLTJEYXV0aGVudGljYXRvcl9wdWxsXzU1X2ZpbGVzJmQ9RHdNRmFRJmM9OTZaYlpa Y2FNRjR3MEY0anBONkxaZyZyPTRMTTBHYlIwaDlGdng4NkZ0c0tJLXcmbT1JQ0xIT2doNm5oZ19f R1plNUFiWlZyR3hiS0VacWhqNnlOQ3E0dk9JOGVNJnM9SXNrRHZrZmRyZU5mZG8yUUp4STJWby1J WFNOYkIwQzF4YlgwNjJQa3gzVSZlPT4NCg0KQWdyZWVkLiBUaGUgUFIgbG9va3MgZ29vZCB0byBt ZS4NCg== --_000_13DF0FBB25E847B591C819F636C1EC59akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <98345A1AA1A3234C96E1AA3A26EF7E47@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7PC9zcGFuPjwv Yj5JbiBhbnkgY2FzZSwgd2UgY2FuIGFkZHJlc3MgdGhhdCB3aGVuL2lmIHdlIGdldCB0byBpdC4g SGVyZSdzIHRoZSBuZXcgcHJvcG9zZWQgdGV4dDo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21fdGxzd2dfdGxzLTJEZXhwb3J0ZWQtMkRh dXRoZW50aWNhdG9yX3B1bGxfNTVfZmlsZXMmYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0 dzBGNGpwTjZMWmcmYW1wO3I9NExNMEdiUjBoOUZ2eDg2RnRzS0ktdyZhbXA7bT1JQ0xIT2doNm5o Z19fR1plNUFiWlZyR3hiS0VacWhqNnlOQ3E0dk9JOGVNJmFtcDtzPUlza0R2a2ZkcmVOZmRvMlFK eEkyVm8tSVhTTmJCMEMxeGJYMDYyUGt4M1UmYW1wO2U9Ij5odHRwczovL2dpdGh1Yi5jb20vdGxz d2cvdGxzLWV4cG9ydGVkLWF1dGhlbnRpY2F0b3IvcHVsbC81NS9maWxlczwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdyZWVkLiBUaGUgUFIgbG9va3MgZ29vZCB0 byBtZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_13DF0FBB25E847B591C819F636C1EC59akamaicom_-- From nobody Wed Nov 20 23:59:14 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65493120A0C for ; Wed, 20 Nov 2019 23:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=post-quantum-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 lBNlTfKBIJ5Y for ; Wed, 20 Nov 2019 23:59:08 -0800 (PST) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7BCF120A23 for ; Wed, 20 Nov 2019 23:59:08 -0800 (PST) Received: by mail-oi1-x22f.google.com with SMTP id n14so2325431oie.13 for ; Wed, 20 Nov 2019 23:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=post-quantum-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc:content-transfer-encoding; bh=RxJkfZkGXp9t2gm3qC4wZx7htqRa3A2GGjkl/aFIwqQ=; b=fZ9PVatBW4f4+8QWV1Zvi6dnBnY76VhbbJSFQWoiYPUI90thJD6s1Ze+sh45SFvaMU hPZk9xRY2Jv34VY2gw7auSSlgZHD97QcidjLMmafNvnnqy3Fd1wXGPO9zP0HIbMYm2Zp Rwiq56EQNRrFLh1heQag46mN//V+yArCSgmNYlY9T+YswE4fhE0YduD/tEq0LqA7PlA9 7MO0r5DAkkbLYBJhp8QqgdxhShCCUAusBqNdL/TLrPRtrlKwfU8nV64cpxGolTsRPDRJ VaIoO6fCgzORJ1LCZf3OiI3hWVIvwDx1FlI9z+lrlSPG6JS/BOAHNKSokRmykPCh42dm SBdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc:content-transfer-encoding; bh=RxJkfZkGXp9t2gm3qC4wZx7htqRa3A2GGjkl/aFIwqQ=; b=ilPi7mZjldpT0y3lABm4FvLoUE3EzqCtr80Q8gPtBqGOGWF+4eiIMFUqepnh29ZqXj 1i0CmuYeh53EsC4sNcQeIg9fXgWPrRgRibquid/zCzV1vldWF8OALa1wG69j1xWjtUI3 2RvV4xRd7oWgvCWcg9WtwYX1THrgwqrHnp1gkVDeXnhfaxO5MRBmBCiEHHFZfl1gIKS9 67TAGcufym2igyig0sh+UTfmty+qNKFUv7MBxeS2eKcDsI8p03BAqox32wI0GXdjpTB3 z32k1pQ6jzmmMLA1i/RZFKdoRvGChCYIkwTY6G18LP53ZGBXgsUAy95G2q5654yCn4AX PinQ== X-Gm-Message-State: APjAAAUbNoj9ONYUcgMYJgHp+iBbv7C1xU+A9yloaISmmBVSO3oou4CL +XCN64FtQEmkgFqOtik4XENaA10EwgWFX6dVaI/E5LA12KoQ/UZ9XEBBYzoDZbplJD1MpoQ1MAP j0LxrD6qND82SFbbNmsBf X-Google-Smtp-Source: APXvYqw7qcl8eVrhYwtcWf6hM14XGldzgaXAP43L0F4r+xTNEmxKLrV+Ihi33ulM8P1ThMpS7pXYmEl9srAPMrla1Hw= X-Received: by 2002:aca:320a:: with SMTP id y10mr6321781oiy.152.1574323147954; Wed, 20 Nov 2019 23:59:07 -0800 (PST) Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Thu, 21 Nov 2019 02:59:07 -0500 From: CJ Tjhai Mime-Version: 1.0 (1.0) References: In-Reply-To: Date: Thu, 21 Nov 2019 02:59:07 -0500 Message-ID: To: Sean Turner Cc: TLS List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 07:59:13 -0000 +1 support this adoption. CJ > On 21 Nov 2019, at 05:36, Sean Turner wrote: > > =EF=BB=BFAt IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both = the TLS WG and the LAKE BOF, which is now a chartered WG [3]. After some d= iscussions, the ADs suggested [4] that the TLS WG consider whether this dra= ft be adopted as a TLS WG item. LAKE could then later specify/refer/adopt/p= rofile it, as appropriate. The authors revised cTLS and presented the revis= ed draft at IETF 106 [5]. At IETF 106 there was support for adoption of cT= LS as a WG item. To confirm this on the list: if you believe that the TLS = WG should not adopt this as a WG item, then please let the chairs know by p= osting a message to the TLS list by 2359 UTC 13 December 2019 (and say why)= . > > NOTE: > : If the consensus is that this draft should be adopted as a WG item, the= n this will necessarily result in a WG rechartering discussions. We would = have gotten to this rechartering discussion anyway now that DTLS 1.3 is pro= gressing out of the WG. > > Thanks, > Chris, Joe, and Sean > > [0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/ > [1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ > [2] https://github.com/ekr/draft-rescorla-tls-ctls > [3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ > [4] https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCv= k > [5] https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-com= pact-tls-13-00.pdf > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 PQ Solutions Limited (trading as =E2=80=98Post-Quantum=E2=80=99) is a priva= te limited=20 company incorporated in England and Wales with=C2=A0registered number 06808= 505. =C2=A0 This email is meant only for the intended recipient. If you have received= =20 this email in error, any review, use, dissemination,=C2=A0distribution, or= =20 copying of this email is strictly prohibited. Please notify us immediately= =20 of the error by return email and please=C2=A0delete this message from your= =20 system. Thank you in advance for your cooperation. For more information=20 about Post-Quantum, please visit www.post-quantum.com=20 . In the course of our business relationship,=20 we may collect, store and transfer information about you. Please see our=20 privacy=C2=A0notice at www.post-quantum.com/privacy-notice=20 to learn about how we use this= =20 information. From nobody Thu Nov 21 00:02:56 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4B5120048 for ; Thu, 21 Nov 2019 00:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPT4XsDngdue for ; Thu, 21 Nov 2019 00:02:52 -0800 (PST) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6FE2120822 for ; Thu, 21 Nov 2019 00:02:51 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id xAL82aMi034221; Thu, 21 Nov 2019 00:02:50 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=2azdBC8kGHsgtGwaF16S339X9HB8hlgebmkOCg1PQas=; b=FG25CWHX7WjDdh/8h3RiQdyuFr4Y8ETJQ3dNO79E3amwnyoHikW3TABncFiKzIBOnANh 1ePGEdMjxKMsGc4fzcNMCpdsvdCg68FLtsZuD67cMB79N8+O/dc4+JVfGEf7zWFmuMaV JCCm7Tt+B9lHMVLojka9WTZqhWu4e/wJwovjH4p7wLKFFq0K0pIocTc/vCObEKRrp6Ur AXQ8KiWfTtjiV8+BiBGEghbK7vrfSduOzuSZi+sHnT3FoQqfROkbQ3OfpgZ9c3c+NPrV fNloWWJe719GgAxjVmGDMXqhSPHY4+4lp+6Xapt36iykUdw0FUkPRpj7l3+LMnlgZMUl aQ== Received: from sg-mailsvcp-mta-lapp03.asia.apple.com (sg-mailsvcp-mta-lapp03.asia.apple.com [17.84.67.71]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2waeny26j8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 21 Nov 2019 00:02:50 -0800 Received: from sg-mailsvcp-mmp-lapp02.asia.apple.com (sg-mailsvcp-mmp-lapp02.asia.apple.com [17.84.71.202]) by sg-mailsvcp-mta-lapp03.asia.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul 4 2019)) with ESMTPS id <0Q1B011017OKUW00@sg-mailsvcp-mta-lapp03.asia.apple.com>; Thu, 21 Nov 2019 16:02:45 +0800 (+08) Received: from process_milters-daemon.sg-mailsvcp-mmp-lapp02.asia.apple.com by sg-mailsvcp-mmp-lapp02.asia.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul 4 2019)) id <0Q1B00X006WS4Q00@sg-mailsvcp-mmp-lapp02.asia.apple.com>; Thu, 21 Nov 2019 16:02:44 +0800 (+08) X-Va-A: X-Va-T-CD: 29a5d205e3fac156880c41877a8fa23c X-Va-E-CD: 83469317ce904d9f0634baacf30f66e8 X-Va-R-CD: 884108b4881bbc082a43f7418b0e48c1 X-Va-CD: 0 X-Va-ID: 8fa03aa2-69ed-4870-82d9-0a5ab256d71d X-V-A: X-V-T-CD: 29a5d205e3fac156880c41877a8fa23c X-V-E-CD: 83469317ce904d9f0634baacf30f66e8 X-V-R-CD: 884108b4881bbc082a43f7418b0e48c1 X-V-CD: 0 X-V-ID: ee554402-860e-4242-8338-2b62b735ebd5 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-20_08:,, signatures=0 Received: from [17.235.153.194] by sg-mailsvcp-mmp-lapp02.asia.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul 4 2019)) with ESMTPSA id <0Q1B00ILU7OIM490@sg-mailsvcp-mmp-lapp02.asia.apple.com>; Thu, 21 Nov 2019 16:02:44 +0800 (+08) Sender: tpauly@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) From: Tommy Pauly In-reply-to: Date: Thu, 21 Nov 2019 16:02:37 +0800 Cc: TLS List Content-transfer-encoding: quoted-printable Message-id: <4F60DE3B-56BC-4D4F-B4EC-D65801BFEDBD@apple.com> References: To: Sean Turner X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-20_08:, , signatures=0 Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 08:02:55 -0000 I support adoption of this work. Best, Tommy > On Nov 21, 2019, at 1:36 PM, Sean Turner wrote: >=20 > At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the = TLS WG and the LAKE BOF, which is now a chartered WG [3]. After some = discussions, the ADs suggested [4] that the TLS WG consider whether this = draft be adopted as a TLS WG item. LAKE could then later = specify/refer/adopt/profile it, as appropriate. The authors revised cTLS = and presented the revised draft at IETF 106 [5]. At IETF 106 there was = support for adoption of cTLS as a WG item. To confirm this on the list: = if you believe that the TLS WG should not adopt this as a WG item, then = please let the chairs know by posting a message to the TLS list by 2359 = UTC 13 December 2019 (and say why). >=20 > NOTE: > : If the consensus is that this draft should be adopted as a WG item, = then this will necessarily result in a WG rechartering discussions. We = would have gotten to this rechartering discussion anyway now that DTLS = 1.3 is progressing out of the WG. >=20 > Thanks, > Chris, Joe, and Sean >=20 > [0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/ > [1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ > [2] https://github.com/ekr/draft-rescorla-tls-ctls > [3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ > [4] = https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk > [5] = https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-= tls-13-00.pdf > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Nov 21 00:45:54 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064A912083E for ; Thu, 21 Nov 2019 00:45:52 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Aosge8ADiYJb for ; Thu, 21 Nov 2019 00:45:50 -0800 (PST) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 1F20E12082F for ; Thu, 21 Nov 2019 00:45:50 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id v8so2265286ljh.5 for ; Thu, 21 Nov 2019 00:45:50 -0800 (PST) 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=e0yrP76S7EQrnwjnYapuZlWWkD+ZjYD/28VgmaspcVE=; b=r32TUn61skASi/Xb2IerTagtbqngelo5uGD1706eC+ynErFvD4b8nq81zdv1aVqDAa lYX/D6oGA2HYHj4bN/iFDIRWOW0ZAMpNq4eZPixlG70sASJ7j7GLy4jW7MSKgOhIRc8+ kgdBXeHw3B4EJaGsh0gWhbnSc3jQsC70/vn4RUAb/G2lm+uHNj44/j6MpOgZqgO+Lc+G SPRVRmWi0Ad3/sfJVjxQln1t7/a+Yu7LJedLSMbsp0hWxnUG/A3YDfrNwXVaD7do7OR/ zweZuwpx6O+Z/wztI59S5GhaYzjEzggMHXg+twVufm1tAPHjSiT/9Dqu9/BkO/sWrZtB AjUQ== 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=e0yrP76S7EQrnwjnYapuZlWWkD+ZjYD/28VgmaspcVE=; b=KqAN1kBjSVt/IsKyuIA1b6To+jrDggGnrB1kNDLjwhPEu7bdmjnNCk4TdUrHXRwBqS 9aBhXTV9WvzMONRFOrWwIpVWStk2eaq8J9quZXbn0tHE08XyBgJ9CcQmHEjdpO/yQGug r26zTvPOjFbPAjFZacpv9Nf2cHF8XUI9Lhfznm+a32sHgSksvinKiuG1TVWzzskOsNou iXbQikDjmXudzElOGJq8sSNcYgGTqeCZthTcz8HYhu3z+nNtFx8NTyedqFCGfYSSLoGw vcZtaZ31F3gcsROmazw29G7FMUATyBZ2n8C0b9JAKOmpWfkwPRxAS+6g0tHNF8XBp7j3 hEkA== X-Gm-Message-State: APjAAAWZqmP5LvDFZ/UCiPIQtOPUsBtfw19MVYv/j60XACew1o+Vg1yG fYbBTlf1n4uXf/SRmhWOpzTObiiTfz+iLPecMByGUdLt X-Google-Smtp-Source: APXvYqxLFMOx2UW8hX8+xBGZc4ofThgQY8WVSFfFsHPE4FJP19UyABUz/kKBW7YG/HllCxFI7Lv2ROZJQU8+Q9OyXoA= X-Received: by 2002:a2e:9842:: with SMTP id e2mr6246102ljj.93.1574325948454; Thu, 21 Nov 2019 00:45:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Thu, 21 Nov 2019 00:45:11 -0800 Message-ID: To: Sean Turner Cc: TLS List Content-Type: multipart/alternative; boundary="000000000000eb36050597d752e4" Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls-batch-signing X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 08:45:52 -0000 --000000000000eb36050597d752e4 Content-Type: text/plain; charset="UTF-8" I favor adoption On Wed, Nov 20, 2019 at 10:56 PM Sean Turner wrote: > At IETF 106 there was support for adoption of "Batch Signing for TLS" [0] > as a WG item. To confirm this on the list: if you believe that the TLS WG > should not adopt this as a WG item, then please let the chairs know by > posting a message to the TLS list by 2359 UTC 13 December 2019 (and say > why). > > NOTE: > : If the consensus is that this draft should be adopted as a WG item, then > this will necessarily result in a WG rechartering discussions. We would > have gotten to this rechartering discussion anyway now that DTLS 1.3 is > progressing out of the WG. > > Thanks, > Chris, Joe, and Sean > > [0] https://datatracker.ietf.org/doc/draft-davidben-tls-batch-signing/ > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000eb36050597d752e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I favor adoption

<= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Nov 20, 2019 at 10:56 PM Sean = Turner <sean@sn3rd.com> wrote:<= br>
At IETF 106 ther= e was support for adoption of "Batch Signing for TLS" [0] as a WG= item.=C2=A0 To confirm this on the list: if you believe that the TLS WG sh= ould not adopt this as a WG item, then please let the chairs know by postin= g a message to the TLS list by 2359 UTC 13 December 2019 (and say why).

NOTE:
: If the consensus is that this draft should be adopted as a WG item, then = this will necessarily result in a WG rechartering discussions.=C2=A0 We wou= ld have gotten to this rechartering discussion anyway now that DTLS 1.3 is = progressing out of the WG.

Thanks,
Chris, Joe, and Sean

[0] https://datatracker.ietf.org/d= oc/draft-davidben-tls-batch-signing/
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000eb36050597d752e4-- From nobody Thu Nov 21 00:59:46 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F57120086 for ; Thu, 21 Nov 2019 00:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Y_eHjgBItan for ; Thu, 21 Nov 2019 00:59:44 -0800 (PST) Received: from mta.openssl.org (xmpp.opentls.org [IPv6:2001:608:c00:180::1:e6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1300F12083E for ; Thu, 21 Nov 2019 00:59:44 -0800 (PST) Received: from [10.54.10.6] (ip-11-84-52-196.southampton.uk.amsterdamresidential.com [196.52.84.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id C5AD3E4E88; Thu, 21 Nov 2019 08:59:41 +0000 (UTC) To: Benjamin Kaduk Cc: "Salz, Rich" , "tls@ietf.org" References: <4431e115-64ff-b660-87bb-b8bf3aa4ea15@openssl.org> <2D5349E3-D9FE-44B6-8A40-1F1AE1863A46@akamai.com> <20191120045843.GU20609@akamai.com> From: Matt Caswell Message-ID: <7c4070ef-5ce9-9700-2e88-724d452096de@openssl.org> Date: Thu, 21 Nov 2019 08:59:41 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <20191120045843.GU20609@akamai.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Is Ed25519/Ed448 ok for use in DTLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 08:59:46 -0000 On 20/11/2019 04:58, Benjamin Kaduk wrote: > Quoting from RFC 6347: > > DTLS 1.0 [DTLS1] was originally defined as a delta from [TLS11]. > This document introduces a new version of DTLS, DTLS 1.2, which is > defined as a series of deltas to TLS 1.2 [TLS12]. [...] > > The presumption should be that anything defined for TLS (1.2) is also > defined for DTLS (1.2); if you look at things in any of the IANA > registries that are marked as DTLS-OK(N), you'll find that they are few > and far between, and that there is some (cryptographic) reason why they > are incompatible with DTLS usage, which can involve (e.g.) out-of-order > delivery and retransmission. E.g., RC4 is a stream cipher and can't > handle out-of-order delivery, so TLS_ECDH_RSA_WITH_RC4_128_SHA is > DTLS-OK(N). > > The two signature algorithms in question are pretty bog standard > cryptographic primitives, and only get used in the handshake anyway, so > it's pretty clear to me that hey are rightly marked as DTLS-OK(Y). > > I could only find the AUTHj48 discussions in my mail archives; it's > possible that the IANA discussions happened before I was responsible AD. > If you're still uncertain after the above, we can try to dig up some > more history of where the DTLS-OK(Y) came from. This is ok as an answer but it means there is no traceability of entries in the registry to RFCs that specify those entries - and that can lead to confusion. That has happened in this case (those signature schemes are explicitly coded as TLSv1.2 only in OpenSSL). If you take the line that "anything specified for TLSv1.2 is implicitly ok for DTLSv1.2 unless stated otherwise", then I at least think an RFC should have a minimal nod towards DTLS. At least to give the message that "yes, we have considered this in a DTLS setting and its fine". As you state above there are exceptions, so we do need to consider this on a case-by-case basis. In the case of RFC8422, as a minimum I would have expected that to be in the form of a sentence saying that those entries should have DTLS-OK against them in section 9 - especially as the following paragraph *does* say this for the "Intrinsic" HashAlgorithm registry entry (rather implying by omission that this doesn't hold for ed25519/ed448). Matt From nobody Thu Nov 21 01:34:12 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B9B1209D3 for ; Thu, 21 Nov 2019 01:34:10 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eF2qKOzPVZXB for ; Thu, 21 Nov 2019 01:34:07 -0800 (PST) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D016C1209FB for ; Thu, 21 Nov 2019 01:34:07 -0800 (PST) Received: by mail-oi1-x235.google.com with SMTP id d22so2584281oic.7 for ; Thu, 21 Nov 2019 01:34:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e0q9awooSX0lygD0kQwEIazFqasS7/AsazN92JkSNzw=; b=LuhVUJZaN5+yhsH3qhPD/pfYr1lffkg4+9xxQOZx5MIBaxVoRhDXIodeQiS33lKvR3 iNCHiq8usrD8aw8JRBETP5/YIqsPqYXo7pQjKn7gEk10PyLhdalRAqgtxhZKsJLENtPj rDD8PcCEMnz0+K+/d65wPgi6uFM6xfI1Q2gSCRlESi02mKBtvfPNTvZawPGo8FFrRZt5 S1mD1POZsztSuiuCWizGCJkf1fWBQDpboObqHEcM5tDsxTd82yJiZkWRRuC2SeGt+JwC SgFUv5u+DGF8Gb/uzi03TxxKwQkcUuh6w+RIzKTTAlh03+A6tDSW7SWMyHVqg9/vXph3 5wQA== 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=e0q9awooSX0lygD0kQwEIazFqasS7/AsazN92JkSNzw=; b=uEgp4Vu7ca04vf3rfCXsd1naC1KTIC35U2ArywDGh/WGqtNni0hV/oAPsY8VTZZyz/ GZOGBaJoUU2o5Ln0leAv+DyCng3lFyDd6sEyvLh3/hNDGZGvKkxH5tECpVZvLe+4JRXC RfyX6MvvHj44rNoz/PLvhUtKXqb4oIwF/zC4Txg45S5ptPaO6uVZ2JMWyoHgnIRgsBmV sTTYRV7l5+lnkAXxngwhHHAzXNwvklYrF8DusflRDTnKAJ8vjGAqPJUYXueNT74GkCuW vC9tdLXwomebSfDGZRVGXQ4TD+Wn+06qD7IP8PL3tRRhtpeW5ITMWrGNw81HEWNZOqzZ rWMw== X-Gm-Message-State: APjAAAUrOaiU0tZ5OML2hK4QxrByPI2hAc6jljdjDr93X9Km2xPzSj67 +3DKOXy0IfhRuvyLvqItgYry7MLY5v0f3wfsA8KbmnNwa8c= X-Google-Smtp-Source: APXvYqwXGi28uXo/lLRgGbqOx1mwlwJ6e19EPzbbG+Ziz0A9GwYi9OWR0njR2fMB+8eb8vq0skieDcIE+15vOdo/JE4= X-Received: by 2002:a05:6808:9bc:: with SMTP id e28mr6592032oig.169.1574328846989; Thu, 21 Nov 2019 01:34:06 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Thu, 21 Nov 2019 17:33:54 +0800 Message-ID: To: Ben Schwartz Cc: Eric Rescorla , TLS List Content-Type: multipart/alternative; boundary="000000000000af525d0597d7ffa8" Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 09:34:10 -0000 --000000000000af525d0597d7ffa8 Content-Type: text/plain; charset="UTF-8" I also support adoption. On the question of how the work should be factored: It is true that this work comprises 3-4 fairly separable technologies. However, they have in common that they need to be pre-agreed between the client and server (except possibly the "known certificates" mechanism, which could possibly be negotiated with ClientHello/ServerHello extensions). So my inclination would be to push forward with this work as a unified package, and consider later whether certain mechanisms are separable. --Richard On Thu, Nov 21, 2019 at 1:48 PM Ben Schwartz wrote: > I support adoption. > > In the spirit of Ted Hardie's comment on dividing the work into pieces, > I'd like to suggest putting the handshake compression into a separate draft > from the certificate compression. Certificate compression could be made > into an extension that is usable in standard TLS. cTLS can then use it for > free with extension monomorphization. > > On Thu, Nov 21, 2019 at 1:38 PM Eric Rescorla wrote: > >> I support adoption. >> >> On Wed, Nov 20, 2019 at 9:36 PM Sean Turner wrote: >> >>> At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS >>> WG and the LAKE BOF, which is now a chartered WG [3]. After some >>> discussions, the ADs suggested [4] that the TLS WG consider whether this >>> draft be adopted as a TLS WG item. LAKE could then later >>> specify/refer/adopt/profile it, as appropriate.. The authors revised cTLS >>> and presented the revised draft at IETF 106 [5]. At IETF 106 there was >>> support for adoption of cTLS as a WG item.. To confirm this on the list: >>> if you believe that the TLS WG should not adopt this as a WG item, then >>> please let the chairs know by posting a message to the TLS list by 2359 UTC >>> 13 December 2019 (and say why). >>> >>> NOTE: >>> : If the consensus is that this draft should be adopted as a WG item, >>> then this will necessarily result in a WG rechartering discussions. We >>> would have gotten to this rechartering discussion anyway now that DTLS 1.3 >>> is progressing out of the WG. >>> >>> Thanks, >>> Chris, Joe, and Sean >>> >>> [0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/ >>> [1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ >>> [2] https://github.com/ekr/draft-rescorla-tls-ctls >>> [3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ >>> [4] >>> https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk >>> [5] >>> https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-tls-13-00.pdf >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000af525d0597d7ffa8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I also support adoption.

On = the question of how the work should be factored: It is true that this work = comprises 3-4 fairly separable technologies.=C2=A0 However, they have in co= mmon that they need to be pre-agreed between the client and server (except = possibly the "known certificates" mechanism, which could possibly= be negotiated with ClientHello/ServerHello extensions).=C2=A0 So my inclin= ation would be to push forward with this work as a unified package, and con= sider later whether certain mechanisms are separable.

<= div>--Richard

On Thu, Nov 21, 2019 at 1:48 PM Ben Schwartz <bem= asc=3D40google.com@dmarc.iet= f.org> wrote:
I support adoption.

In the spirit = of Ted Hardie's comment on dividing the work into pieces, I'd like = to suggest putting the handshake compression into a separate draft from the= certificate compression.=C2=A0 Certificate compression could be made into = an extension that is usable in standard TLS. cTLS can then use it for free = with extension monomorphization.

=
On Thu, Nov 21, 2019 at 1:38 PM Eric = Rescorla <ekr@rtfm.com= > wrote:
=
I support adoption.

On Wed, Nov 20, 2019 at 9:36 PM Sea= n Turner <sean@sn3rd= .com> wrote:
At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS= WG and the LAKE BOF, which is now a chartered WG [3].=C2=A0 After some dis= cussions, the ADs suggested [4] that the TLS WG consider whether this draft= be adopted as a TLS WG item. LAKE could then later specify/refer/adopt/pro= file it, as appropriate.. The authors revised cTLS and presented the revise= d draft at IETF 106 [5].=C2=A0 At IETF 106 there was support for adoption o= f cTLS as a WG item..=C2=A0 To confirm this on the list: if you believe tha= t the TLS WG should not adopt this as a WG item, then please let the chairs= know by posting a message to the TLS list by 2359 UTC 13 December 2019 (an= d say why).

NOTE:
: If the consensus is that this draft should be adopted as a WG item, then = this will necessarily result in a WG rechartering discussions.=C2=A0 We wou= ld have gotten to this rechartering discussion anyway now that DTLS 1.3 is = progressing out of the WG.

Thanks,
Chris, Joe, and Sean

[0] https://datatracker.ietf.org/doc/slid= es-105-tls-sessa-ctls/
[1] https://datatracker.ietf.org/doc/draft-= rescorla-tls-ctls/
[2] https://github.com/ekr/draft-rescorla-tls-ctls=
[3] https://datatracker.ietf.org/doc/draft-= rescorla-tls-ctls/
[4] https://mailarchive.ietf.o= rg/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk
[5] https://d= atatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-tls-13-00.= pdf
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000af525d0597d7ffa8-- From nobody Thu Nov 21 01:46:11 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4647D1208BE for ; Thu, 21 Nov 2019 01:46:10 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 5I5E1fKkrOsg for ; Thu, 21 Nov 2019 01:46:08 -0800 (PST) Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (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 57A9E1200B3 for ; Thu, 21 Nov 2019 01:46:08 -0800 (PST) Received: by mail-vk1-xa2b.google.com with SMTP id l5so577362vkb.4 for ; Thu, 21 Nov 2019 01:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JRI+xV2+sCzEVoCknjBJkWlPWJFjRU2NxO9u01RcEXM=; b=gqtfwuuBXAHfp6Ev43dlFwx/1KXdOfqqgmf8xzVcSGXw8Au4jpyfXEv9anGXlwu5ar x+sFgeghBZkU1YfZ1TfUiZXhy3nDOqsFzKuSfy2ML0XG/8RJgm1A97K4xtLXuu2Ii+NI fX6Mdix9zvmJslaBAwFnF+C/UR+OlRzSixXFc1qx8C+qE8bUDHZ0t0B+ES0dpb4xDawb AIbs/N2PgRKsUWVKe4ZzStHJWlusg2Kk18KsZpgMqviO5krPB+0pVCD7Te32V45gnFMu KND2N7UvnC7BkFfcDmgihT3sTSFfYq7Wzexa7rVvD/MyU70VvBZGLcYnI2t9a54OucUQ wAPA== 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=JRI+xV2+sCzEVoCknjBJkWlPWJFjRU2NxO9u01RcEXM=; b=IjNtcYfOJYm9wfpv8sF3fTc6axzvxq3x8mbH1Jpt1AXIh3FPrMKj/PTpwNBprJo1Sq QVKZqd1SsMfQGcGCrKER5LGrUEdYIrB4zirJBX9qBYy8B8MJGtjSfK1s/fQnLiL3R3DT uZUH1EiqQs09sfoDnKhQa9J0nFm36TGLsen/0VUkgiDJTd1/WC4BzG+UXc67tZCjZnfg ODrBrNuB9yqerT/MaYlxlYlM0/n0G/baVYn7pvBz9N9CQ9IMPmB0IndGJnAQ48HD1ChU kbzHU7bVG9caI2p/0VE8d2tkF02xD3VGPpRcoGPvEHbPb89Pjpo13YNudvFcs0oHnRL9 nFlQ== X-Gm-Message-State: APjAAAXboXRFUjOxd9yFpZGl2o/YGHYnNXpr1qfrKPiyjTBd6bKnuXTM t/kWI996IGgh2JW66bOFTdaVRLHVzCznC49DidGU8U1rj+k= X-Google-Smtp-Source: APXvYqxwffyPm2+vVJiOy+o1lNelc6Xll9HXTFpaHsmSsjTqpmMArtkQ+oUmmeJjzt4G+PfgljkG/GPz1sKqNDVVBV8= X-Received: by 2002:a05:6122:301:: with SMTP id c1mr4915516vko.42.1574329566917; Thu, 21 Nov 2019 01:46:06 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dmitry Belyavsky Date: Thu, 21 Nov 2019 12:45:55 +0300 Message-ID: To: Sean Turner Cc: TLS List Content-Type: multipart/alternative; boundary="000000000000987d660597d82a5a" Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 09:46:10 -0000 --000000000000987d660597d82a5a Content-Type: text/plain; charset="UTF-8" I support the adoption. On Thu, Nov 21, 2019 at 8:36 AM Sean Turner wrote: > At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS WG > and the LAKE BOF, which is now a chartered WG [3]. After some discussions, > the ADs suggested [4] that the TLS WG consider whether this draft be > adopted as a TLS WG item. LAKE could then later specify/refer/adopt/profile > it, as appropriate. The authors revised cTLS and presented the revised > draft at IETF 106 [5]. At IETF 106 there was support for adoption of cTLS > as a WG item. To confirm this on the list: if you believe that the TLS WG > should not adopt this as a WG item, then please let the chairs know by > posting a message to the TLS list by 2359 UTC 13 December 2019 (and say > why). > > NOTE: > : If the consensus is that this draft should be adopted as a WG item, then > this will necessarily result in a WG rechartering discussions. We would > have gotten to this rechartering discussion anyway now that DTLS 1.3 is > progressing out of the WG. > > Thanks, > Chris, Joe, and Sean > > [0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/ > [1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ > [2] https://github.com/ekr/draft-rescorla-tls-ctls > [3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ > [4] https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk > [5] > https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-tls-13-00.pdf > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- SY, Dmitry Belyavsky --000000000000987d660597d82a5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support the adoption.

On Thu, Nov 21, 2019 at 8:36 AM Sea= n Turner <sean@sn3rd.com> wrote= :
At IETF 105, e= kr presented cTLS (Compact TLS) [0][1][2] to both the TLS WG and the LAKE B= OF, which is now a chartered WG [3].=C2=A0 After some discussions, the ADs = suggested [4] that the TLS WG consider whether this draft be adopted as a T= LS WG item. LAKE could then later specify/refer/adopt/profile it, as approp= riate. The authors revised cTLS and presented the revised draft at IETF 106= [5].=C2=A0 At IETF 106 there was support for adoption of cTLS as a WG item= .=C2=A0 To confirm this on the list: if you believe that the TLS WG should = not adopt this as a WG item, then please let the chairs know by posting a m= essage to the TLS list by 2359 UTC 13 December 2019 (and say why).

NOTE:
: If the consensus is that this draft should be adopted as a WG item, then = this will necessarily result in a WG rechartering discussions.=C2=A0 We wou= ld have gotten to this rechartering discussion anyway now that DTLS 1.3 is = progressing out of the WG.

Thanks,
Chris, Joe, and Sean

[0] https://datatracker.ietf.org/doc/slid= es-105-tls-sessa-ctls/
[1] https://datatracker.ietf.org/doc/draft-= rescorla-tls-ctls/
[2] https://github.com/ekr/draft-rescorla-tls-ctls=
[3] https://datatracker.ietf.org/doc/draft-= rescorla-tls-ctls/
[4] https://mailarchive.ietf.o= rg/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk
[5] https://d= atatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-tls-13-00.= pdf
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--
SY, Dmitry Belyavsky
--000000000000987d660597d82a5a-- From nobody Thu Nov 21 01:47:47 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC911209C8 for ; Thu, 21 Nov 2019 01:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_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=lowentropy.net header.b=l3wESWFx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iQdORQCx 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 0DS58xgTRTs7 for ; Thu, 21 Nov 2019 01:47:43 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C95991208BC for ; Thu, 21 Nov 2019 01:47:43 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 335032236D for ; Thu, 21 Nov 2019 04:47:43 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 21 Nov 2019 04:47:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=c6euxogY4FVRVLEgJecC9NxTAoOQ94v soWc4yTWmSiA=; b=l3wESWFxdY99UuJKSMNCnEI1gw6H/77CfWeGV98cFHh7HhC afCzR3C51gSgSj8qNVXCj7Qel5cy+5uwy7wTwSWfy0EnRfnGwgHJGBaD+TRQFttl G6QzuzuZszMJ7Nf3lu8llZ6qhvlOgzgbYxzxEAP7fXy3tpPLJIKCmrsX8DB2KegK vO/sF7ucExnuSDAPrnaA1Lszu3b+o2nyGBbaJ8sStVGwQnwF9tJiExTB/wTkmo0d CSpqWMmeBiQlJahZIhk9wKCKAb2tl89l4URIY3EarprMtScYF6paKgEb+JpEjzV9 yOeql22e0ZVfHDKMugC8h/AEePssCw57i2cHEoA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=c6euxo gY4FVRVLEgJecC9NxTAoOQ94vsoWc4yTWmSiA=; b=iQdORQCxfVfFQxtvDQZbKL b+BcEuHuzs7P1tFuS/HwbA2gqSFASSH9yhKpHvf4kXmcPS5/M3JwWoCvqflwibsE AauwWEEDgqRhiYwE0GdFNmt3j9R5d2SJO7aY/dewsLtESDdylpbPW94fm19Lveo6 kcDoyCrja5NI6dpbxF57FFnwH/t9Nl4jf262dj3MbjhaAoifE6XMpSXHoAYUufjF ayykvKOeKahkLpzNgb6i/ueEouqInrvSZ4m5fos8+NNVxEQONBA7FcOpj6E18EKF /EykhlihWbRBRVJNe+5gENcYmktY/CXC6GFPB3WL92ET1mHG8plGgG59MzvV5Idg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehvddgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DB7AAE00A3; Thu, 21 Nov 2019 04:47:42 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: <765a4916-5869-442d-b796-ff6e3c04a4ae@www.fastmail.com> In-Reply-To: References: Date: Thu, 21 Nov 2019 17:47:22 +0800 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls-batch-signing X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 09:47:45 -0000 I support adoption. We can sort out the few tiny issues remaining in the working group. On Thu, Nov 21, 2019, at 14:56, Sean Turner wrote: > At IETF 106 there was support for adoption of "Batch Signing for TLS" > [0] as a WG item. To confirm this on the list: if you believe that the > TLS WG should not adopt this as a WG item, then please let the chairs > know by posting a message to the TLS list by 2359 UTC 13 December 2019 > (and say why). > > NOTE: > : If the consensus is that this draft should be adopted as a WG item, > then this will necessarily result in a WG rechartering discussions. We > would have gotten to this rechartering discussion anyway now that DTLS > 1.3 is progressing out of the WG. > > Thanks, > Chris, Joe, and Sean > > [0] https://datatracker.ietf.org/doc/draft-davidben-tls-batch-signing/ > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu Nov 21 01:49:46 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A90120A3D for ; Thu, 21 Nov 2019 01:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 djF6iM_5dqBh for ; Thu, 21 Nov 2019 01:49:42 -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 B874B120A17 for ; Thu, 21 Nov 2019 01:49:42 -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 xAL9l2iD031128; Thu, 21 Nov 2019 09:49:42 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=S7wVTkyds0S3F15y1XXSPZhPP1ldYNhcVpHJYnh+pAQ=; b=Q7xI2wUeHUIEVzi6HOVekRSy4TunQ9VbhsTupGrmjyWDmnQX9qsg0jEd9B/EhhvBQcIl hyL6P5aLnHPuEuPkdcy6HtlMMyERNs2n+UeYWIzIZcOb0vBDcTEQ9zucWutyp6VMg5uU IERvhXTzOyneSetOFHcz6FNUCIIEJWPtGo9HDzedLHP341N2qGMk0yufewWiYD11zUTQ /EgMorNUtZsE14CYi0RriL5OrbBEf7KLn/ne/vY8Y04RkcKPs0WpmlPhhuziGKCH6v2e XpiIW+4OS7SQrxhsWIYRULfSdivP+XYu44F5YMQatZwIMg4JyRnT0FfxPaXvAxLk+Lvg Iw== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2wafutxp0w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Nov 2019 09:49:42 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAL9l64l010271; Thu, 21 Nov 2019 01:49:41 -0800 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint5.akamai.com with ESMTP id 2wafybu8sw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 21 Nov 2019 01:49:40 -0800 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 21 Nov 2019 04:49:40 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 21 Nov 2019 04:49:39 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Thu, 21 Nov 2019 04:49:39 -0500 From: "Salz, Rich" To: Martin Thomson , "tls@ietf.org" Thread-Topic: [TLS] Adoption call for draft-davidben-tls-batch-signing Thread-Index: AQHVoDjd6ACkmCTL+k6JB+KTadqqGKeVtLcAgACGwIA= Date: Thu, 21 Nov 2019 09:49:39 +0000 Message-ID: <5737AC81-EEFC-4E03-9241-6E554E485140@akamai.com> References: <765a4916-5869-442d-b796-ff6e3c04a4ae@www.fastmail.com> In-Reply-To: <765a4916-5869-442d-b796-ff6e3c04a4ae@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191110 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.216.123] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-21_01:, , 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=886 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911210089 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-21_01:2019-11-20,2019-11-21 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 mlxscore=0 priorityscore=1501 mlxlogscore=862 adultscore=0 bulkscore=0 malwarescore=0 lowpriorityscore=0 clxscore=1015 impostorscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911210088 Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls-batch-signing X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 09:49:44 -0000 SSBhbSBhZ2FpbnN0IHRoZSB3b3JraW5nIGdyb3VwIE5PVCBhZG9wdGluZyB0aGlzLg0KIA0KDQo= From nobody Thu Nov 21 07:04:23 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9C51200E7 for ; Thu, 21 Nov 2019 07:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 QiEVQdFpFvn4 for ; Thu, 21 Nov 2019 07:04:18 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 9A0E912081F for ; Thu, 21 Nov 2019 07:04:18 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id 14so4014926qtf.5 for ; Thu, 21 Nov 2019 07:04:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=u8CM4C2t8TF7bKdVdZEjwkFkpI3EPuy5SjjJ2aXCd2M=; b=ACeQtpqLfu6C5yXCTeHfvM9hlqLVWVjxi4fiscsNkV7A4GKtPhnk/zVWiaehaP+dgV lA72nDJSAtYxcZjjTpHhfMy9/i67jxVeO1VAbi9QFcoG3b7bcTuW7CQ+exHsuSQQKLYT 9IogyNP2ZkUpOcHfUqosLl4VHNRkVL9pg0P/M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=u8CM4C2t8TF7bKdVdZEjwkFkpI3EPuy5SjjJ2aXCd2M=; b=oVF8gPm9TlzRpJ39M2CTGN4BrdksIfJsk9LI61k5uN8wWn5YskzlMbuyaot1gcJNUO K1md96FMkBRr6YWBRKh76lHGLKXKjRpdFnZuEme/zYt26W6dp289NVKYY+Lg7GwA2jCA 1NcIVvKmqTCk0AgRSK/wgARm1JmCq5XiHjWYBZdmT6c9ueUNXD9QbkQ/UWhcInTxyIgY LmSA3mU9ukh8fNw/BlAOkAIbZmX3aRPH6gKFXd+GfQyJnRVixzu+/yVeurhBMm1zU7ds 731/CpCgEcFPWaRHhPR0SVM+WGWBb27mHdX7Irs1mFf9LiSTS++v7FBUqhhmIkZh7F8y zD+A== X-Gm-Message-State: APjAAAV9DXZ1v93649jUs1b0QnDtqI7J5ytDMPdStAA/Vm7+EEpk0s2S MAi26KwfRMoyJ8Fuv6R83bFFFnwWiLvbmw== X-Google-Smtp-Source: APXvYqy3ylsZTE1qB1xkpyRVZEieJJtvRQFpG+9x6Djp/PqcM9NvKPjkYQLzEXlWqSvvvYKVWwEbhg== X-Received: by 2002:ac8:1a28:: with SMTP id v37mr2772190qtj.351.1574348657582; Thu, 21 Nov 2019 07:04:17 -0800 (PST) Received: from [5.5.33.83] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id z16sm1229255qtn.24.2019.11.21.07.04.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Nov 2019 07:04:17 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 21 Nov 2019 23:04:13 +0800 References: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> To: TLS List In-Reply-To: <2FB1D8AD-2C22-4A09-B7AF-0EFD6F0DBACA@sn3rd.com> Message-Id: <555428C4-4925-4A6D-99A8-FFFFBA90E600@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 15:04:21 -0000 I=E2=80=99ve been remiss and not closed the WGLC. Stay tuned for me = based on today=E2=80=99s WG session. spt > On Nov 6, 2019, at 00:05, Sean Turner wrote: >=20 > All, >=20 > This is the working group last call for the "TLS Ticket Requests" = draft available at = https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/. Please = review the document and send your comments to the list by 2359 UTC on 19 = November 2019. >=20 > Note the the GH repo for this draft can be found at: > https://github.com/tlswg/draft-ietf-tls-ticketrequest >=20 > Thanks - J&S From nobody Thu Nov 21 08:38:51 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A6B120BA8 for ; Thu, 21 Nov 2019 08:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=hmMfAnvC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ZOXwSEkm 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 CyzY8waQE8tR for ; Thu, 21 Nov 2019 08:38:47 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AF42120B7E for ; Thu, 21 Nov 2019 08:38:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10564; q=dns/txt; s=iport; t=1574354327; x=1575563927; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZMzN9rjhG4cvGZvGvky1Tr5Dx1ZtjO6/0jO2DOlxa2w=; b=hmMfAnvCYEI9b1L61mc9G4o36guSpz5TmhqGgLtv7OAeO9iMDmzcf9Gf Hy5f6qFuMP16ebahHO+j9C9oJnKVyKl4kVGB9hTG8SkrJmfi1W1nLATwP FvilehDsO7e9hrRXtjC2qjIamNdKJIs5W8T/5iEjVlz//92pirxEGH/km A=; IronPort-PHdr: =?us-ascii?q?9a23=3AYkRZ/h1W8Y5Ikr6usmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEU7yKebjaSUSF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DlAAD5vNZd/5JdJa1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF+gRwvUAVsWCAECyoKhCCDRgOKa4Jfkx+EYoJ?= =?us-ascii?q?SA1QJAQEBDAEBGAEMCAIBAYRAAheCESQ4EwIDDQEBBAEBAQIBBQRthTcMhVE?= =?us-ascii?q?BAQEBAQIBARALBgoTAQEsCwEPAgEIEQQBASgDAgICJQsUCQgCBA4FCBqDAYF?= =?us-ascii?q?5TQMuAQIMA6MhAoE4iGB1gTKCfgEBBYE0AQMDAQxBgwsYghcDBoE2jBYagUA?= =?us-ascii?q?/gRFGgkw+gmIBAQECAYFfKwmCWjKCLJAWhUiJSI8OCoIrhxqOUYI+h2qPcJc?= =?us-ascii?q?AkVQCBAIEBQIOAQEFgWkigVhwFTuCbFARFIZIg3OFFIU/dAGBJ48OAYEOAQE?= X-IronPort-AV: E=Sophos;i="5.69,226,1571702400"; d="scan'208,217";a="672130244" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Nov 2019 16:38:45 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id xALGcjYv023068 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Nov 2019 16:38:45 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 21 Nov 2019 10:38:45 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 21 Nov 2019 11:38:43 -0500 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 21 Nov 2019 10:38:42 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fMjG/z5r1oesR+283KtcnfTxJewN2kqKF0Vvulmf98iychlLBlD17MMRRWIs+s9JeMb/geNnbyCCKEv6WC1sX8KJk4w2R0zlP6mm+hMc8DrcvzhUhUV9M7Kk9TT8TCuaQeM/DiynFTLoGKdPFdatCHoSvLJDio0ud1fpBc1J8Zo+AnTv2GBq80nFzpAEKyRTzlke2mzYarLaGgQjkNRDyPaovyPOuEUM+Jxtfng3jaBZ8j5d9NXkFSop/saKzGmB4Sd96+dzUUXXdjmz7Iw/hAYqn2yJm34ASP6aRAjFhXHGec8B1Bea676fmFCHzdQ6OYhKxhhz+gCVIphM2pEV3A== 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=ZMzN9rjhG4cvGZvGvky1Tr5Dx1ZtjO6/0jO2DOlxa2w=; b=U89GpCn2nWHlFxQ+kllu/P2M0vZq8ZwzoASZ5SfgNUs9hqjKWIPQJPflehQ18Jry0gcpcE75XiMI4VObhnilhi7K3UXRFMaDeAaBc5JmRGHZHYJRsLh3M/7j/aFvFmOs3eoX2iseE8mWVTqsoSwfojDWt93upXTAj8owY2+dQ1ftLy9kAPaXUcJo9n6fqbKzqOVwKyoryfgrjNJVOZVgidKOYDquHM3rQ6jDmTpglAPtaT31KMrRVTLzW1MQ4XbeOOANhGFH0WLoUobO8xgLNGuIdzJYm2wXrIAgYjW2P4B5XB0UuyDNTWYTnfQzuv0X4gcoy6WGVs894DKoQEtPdw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZMzN9rjhG4cvGZvGvky1Tr5Dx1ZtjO6/0jO2DOlxa2w=; b=ZOXwSEkmtNi8l0Eu7ojkdXw1LeN/26XmOthjUH6pnCt9Pw0W7k/IH+kA5XitzAYUuoj4gwrAyN8+lCBibSCgFBRKgZl3/EjQlHLtswc4RMg0gkOxKStLn2SaHl3ni+s4wHu7bZtBsmPVJaasmsjVDU33JW9+iOVOFPAHj0bgTYQ= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2801.namprd11.prod.outlook.com (52.135.246.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.18; Thu, 21 Nov 2019 16:38:40 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5c82:bb6a:d0f0:b802]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5c82:bb6a:d0f0:b802%6]) with mapi id 15.20.2474.019; Thu, 21 Nov 2019 16:38:40 +0000 From: "Panos Kampanakis (pkampana)" To: Sean Turner CC: TLS List Thread-Topic: [TLS] Adoption call for draft-rescorla-tls-ctls Thread-Index: AQHVoFB4BYcmiuNjf0Wbqi6NWBY+FqeV00Tg Date: Thu, 21 Nov 2019 16:38:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [173.38.117.87] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a696e228-5678-447d-3157-08d76ea14401 x-ms-traffictypediagnostic: BN7PR11MB2801: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0228DDDDD7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(346002)(376002)(366004)(136003)(199004)(189003)(11346002)(3846002)(66066001)(446003)(790700001)(81166006)(8676002)(478600001)(316002)(8936002)(6116002)(966005)(14454004)(33656002)(81156014)(25786009)(99286004)(86362001)(2906002)(74316002)(26005)(71200400001)(186003)(6436002)(7736002)(606006)(71190400001)(102836004)(66476007)(6916009)(229853002)(14444005)(256004)(6246003)(7696005)(76176011)(52536014)(76116006)(66946007)(66556008)(64756008)(66446008)(4326008)(236005)(9686003)(6306002)(53546011)(54896002)(5660300002)(55016002)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2801; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MR2WMMGyHL58uXxWoq/dMwzmK+1xn2jND2kT2KmcAF2GvdqrS7RtTjn1g9KJT9m/AwZfuY4mhVGTLM0h43drp0vQ0SoY7YMmcwIxLHYTlRRzZWLUtEKHki53ZP28YIfGtkL87V5RpCB1ZggL5b+tPPKCKZAmquIwQuPYcCyRtzoGvGrd/2IF3SRc7j5cv9cz0+SfEsbypWg3y9xY4w+bU68XOaOJ1xtOKfZye1m1xrxkVyG1BJ6b/urPdX5tygmt+FaHdVvJloGvIxWYGVPkQUwjZkxqR2I9/6hCYXEUJbL5Xtn7e7GKgy3O6Y6dIiZp3tqWpTDiJSVs00Isrc0uk8swP5AUsbgG88AGZK2kDEw6KDJQekVMNZ6uLangBHElGE5xLLJd2uJEbLGYsyANoJ55MC6Lup6bBlcH6qQsi0eBSzTmEVpZgPb0ea0lapWY8NXjjaa/wnsqk/Je7FEaoABvw6//s4evKEbNsm36mUU= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN7PR11MB25472D90A2F91F2DDD3A9609C94E0BN7PR11MB2547namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a696e228-5678-447d-3157-08d76ea14401 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2019 16:38:40.5023 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WdURe6X+a8yLztO882dPAD/fxjcJmvbsTGey+8IxthabvxyHevzZ9Pp+HPUUZ8TTWiGRYrJXV+rop5cBZbPSAA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2801 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 16:38:49 -0000 --_000_BN7PR11MB25472D90A2F91F2DDD3A9609C94E0BN7PR11MB2547namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEsIHN1cHBvcnQgYWRvcHRpb24uDQoNCg0KDQpGcm9tOiBUTFMgPHRscy1ib3VuY2VzQGlldGYu b3JnPiBPbiBCZWhhbGYgT2YgRG1pdHJ5IEJlbHlhdnNreQ0KU2VudDogVGh1cnNkYXksIE5vdmVt YmVyIDIxLCAyMDE5IDQ6NDYgQU0NClRvOiBTZWFuIFR1cm5lciA8c2VhbkBzbjNyZC5jb20+DQpD YzogVExTIExpc3QgPHRsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVExTXSBBZG9wdGlvbiBj YWxsIGZvciBkcmFmdC1yZXNjb3JsYS10bHMtY3Rscw0KDQoNCg0KSSBzdXBwb3J0IHRoZSBhZG9w dGlvbi4NCg0KDQoNCk9uIFRodSwgTm92IDIxLCAyMDE5IGF0IDg6MzYgQU0gU2VhbiBUdXJuZXIg PHNlYW5Ac24zcmQuY29tPG1haWx0bzpzZWFuQHNuM3JkLmNvbT4+IHdyb3RlOg0KDQogICBBdCBJ RVRGIDEwNSwgZWtyIHByZXNlbnRlZCBjVExTIChDb21wYWN0IFRMUykgWzBdWzFdWzJdIHRvIGJv dGggdGhlIFRMUyBXRyBhbmQgdGhlIExBS0UgQk9GLCB3aGljaCBpcyBub3cgYSBjaGFydGVyZWQg V0cgWzNdLiAgQWZ0ZXIgc29tZSBkaXNjdXNzaW9ucywgdGhlIEFEcyBzdWdnZXN0ZWQgWzRdIHRo YXQgdGhlIFRMUyBXRyBjb25zaWRlciB3aGV0aGVyIHRoaXMgZHJhZnQgYmUgYWRvcHRlZCBhcyBh IFRMUyBXRyBpdGVtLiBMQUtFIGNvdWxkIHRoZW4gbGF0ZXIgc3BlY2lmeS9yZWZlci9hZG9wdC9w cm9maWxlIGl0LCBhcyBhcHByb3ByaWF0ZS4gVGhlIGF1dGhvcnMgcmV2aXNlZCBjVExTIGFuZCBw cmVzZW50ZWQgdGhlIHJldmlzZWQgZHJhZnQgYXQgSUVURiAxMDYgWzVdLiAgQXQgSUVURiAxMDYg dGhlcmUgd2FzIHN1cHBvcnQgZm9yIGFkb3B0aW9uIG9mIGNUTFMgYXMgYSBXRyBpdGVtLi4gIFRv IGNvbmZpcm0gdGhpcyBvbiB0aGUgbGlzdDogaWYgeW91IGJlbGlldmUgdGhhdCB0aGUgVExTIFdH IHNob3VsZCBub3QgYWRvcHQgdGhpcyBhcyBhIFdHIGl0ZW0sIHRoZW4gcGxlYXNlIGxldCB0aGUg Y2hhaXJzIGtub3cgYnkgcG9zdGluZyBhIG1lc3NhZ2UgdG8gdGhlIFRMUyBsaXN0IGJ5IDIzNTkg VVRDIDEzIERlY2VtYmVyIDIwMTkgKGFuZCBzYXkgd2h5KS4NCg0KICAgTk9URToNCiAgIDogSWYg dGhlIGNvbnNlbnN1cyBpcyB0aGF0IHRoaXMgZHJhZnQgc2hvdWxkIGJlIGFkb3B0ZWQgYXMgYSBX RyBpdGVtLCB0aGVuIHRoaXMgd2lsbCBuZWNlc3NhcmlseSByZXN1bHQgaW4gYSBXRyByZWNoYXJ0 ZXJpbmcgZGlzY3Vzc2lvbnMuICBXZSB3b3VsZCBoYXZlIGdvdHRlbiB0byB0aGlzIHJlY2hhcnRl cmluZyBkaXNjdXNzaW9uIGFueXdheSBub3cgdGhhdCBEVExTIDEuMyBpcyBwcm9ncmVzc2luZyBv dXQgb2YgdGhlIFdHLg0KDQogICBUaGFua3MsDQogICBDaHJpcywgSm9lLCBhbmQgU2Vhbg0KDQog ICBbMF0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mvc2xpZGVzLTEwNS10bHMtc2Vz c2EtY3Rscy8NCiAgIFsxXSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1y ZXNjb3JsYS10bHMtY3Rscy8NCiAgIFsyXSBodHRwczovL2dpdGh1Yi5jb20vZWtyL2RyYWZ0LXJl c2NvcmxhLXRscy1jdGxzDQogICBbM10gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtcmVzY29ybGEtdGxzLWN0bHMvDQogICBbNF0gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRm Lm9yZy9hcmNoL21zZy9sYWtlL2tBQ3dXN1BYcm1UUmE0UHZYUTBUQTM0eEN2aw0KICAgWzVdIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDYvbWF0ZXJpYWxzL3NsaWRlcy0x MDYtdGxzLWNvbXBhY3QtdGxzLTEzLTAwLnBkZg0KICAgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCiAgIFRMUyBtYWlsaW5nIGxpc3QNCiAgIFRMU0BpZXRm Lm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0KICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90bHMNCg0KDQoNCg0KDQoNCiAgIC0tDQoNCiAgIFNZLCBEbWl0cnkgQmVseWF2 c2t5DQoNCg== --_000_BN7PR11MB25472D90A2F91F2DDD3A9609C94E0BN7PR11MB2547namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5 bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+JiM0MzsxLCBzdXBwb3J0IGFk b3B0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gVExTICZsdDt0bHMtYm91bmNlc0BpZXRmLm9y ZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCkRtaXRyeSBCZWx5YXZza3k8YnI+DQo8Yj5TZW50 OjwvYj4gVGh1cnNkYXksIE5vdmVtYmVyIDIxLCAyMDE5IDQ6NDYgQU08YnI+DQo8Yj5Ubzo8L2I+ IFNlYW4gVHVybmVyICZsdDtzZWFuQHNuM3JkLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFRMUyBM aXN0ICZsdDt0bHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVExTXSBB ZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1yZXNjb3JsYS10bHMtY3RsczxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBzdXBwb3J0IHRoZSBhZG9wdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgTm92IDIxLCAyMDE5IGF0IDg6MzYg QU0gU2VhbiBUdXJuZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpzZWFuQHNuM3JkLmNvbSI+c2VhbkBz bjNyZC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0IElFVEYgMTA1LCBla3IgcHJlc2VudGVkIGNUTFMg KENvbXBhY3QgVExTKSBbMF1bMV1bMl0gdG8gYm90aCB0aGUgVExTIFdHIGFuZCB0aGUgTEFLRSBC T0YsIHdoaWNoIGlzIG5vdyBhIGNoYXJ0ZXJlZCBXRyBbM10uJm5ic3A7IEFmdGVyIHNvbWUgZGlz Y3Vzc2lvbnMsIHRoZSBBRHMgc3VnZ2VzdGVkIFs0XSB0aGF0IHRoZSBUTFMgV0cgY29uc2lkZXIg d2hldGhlciB0aGlzIGRyYWZ0IGJlIGFkb3B0ZWQgYXMgYSBUTFMNCiBXRyBpdGVtLiBMQUtFIGNv dWxkIHRoZW4gbGF0ZXIgc3BlY2lmeS9yZWZlci9hZG9wdC9wcm9maWxlIGl0LCBhcyBhcHByb3By aWF0ZS4gVGhlIGF1dGhvcnMgcmV2aXNlZCBjVExTIGFuZCBwcmVzZW50ZWQgdGhlIHJldmlzZWQg ZHJhZnQgYXQgSUVURiAxMDYgWzVdLiZuYnNwOyBBdCBJRVRGIDEwNiB0aGVyZSB3YXMgc3VwcG9y dCBmb3IgYWRvcHRpb24gb2YgY1RMUyBhcyBhIFdHIGl0ZW0uLiZuYnNwOyBUbyBjb25maXJtIHRo aXMgb24gdGhlIGxpc3Q6IGlmIHlvdQ0KIGJlbGlldmUgdGhhdCB0aGUgVExTIFdHIHNob3VsZCBu b3QgYWRvcHQgdGhpcyBhcyBhIFdHIGl0ZW0sIHRoZW4gcGxlYXNlIGxldCB0aGUgY2hhaXJzIGtu b3cgYnkgcG9zdGluZyBhIG1lc3NhZ2UgdG8gdGhlIFRMUyBsaXN0IGJ5IDIzNTkgVVRDIDEzIERl Y2VtYmVyIDIwMTkgKGFuZCBzYXkgd2h5KS48YnI+DQo8YnI+DQpOT1RFOjxicj4NCjogSWYgdGhl IGNvbnNlbnN1cyBpcyB0aGF0IHRoaXMgZHJhZnQgc2hvdWxkIGJlIGFkb3B0ZWQgYXMgYSBXRyBp dGVtLCB0aGVuIHRoaXMgd2lsbCBuZWNlc3NhcmlseSByZXN1bHQgaW4gYSBXRyByZWNoYXJ0ZXJp bmcgZGlzY3Vzc2lvbnMuJm5ic3A7IFdlIHdvdWxkIGhhdmUgZ290dGVuIHRvIHRoaXMgcmVjaGFy dGVyaW5nIGRpc2N1c3Npb24gYW55d2F5IG5vdyB0aGF0IERUTFMgMS4zIGlzIHByb2dyZXNzaW5n IG91dCBvZiB0aGUgV0cuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCkNocmlzLCBKb2UsIGFuZCBT ZWFuPGJyPg0KPGJyPg0KWzBdIDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL3NsaWRlcy0xMDUtdGxzLXNlc3NhLWN0bHMvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9zbGlkZXMtMTA1LXRscy1zZXNzYS1jdGxzLzwvYT48 YnI+DQpbMV0gPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt cmVzY29ybGEtdGxzLWN0bHMvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1yZXNjb3JsYS10bHMtY3Rscy88L2E+PGJyPg0KWzJdIDxhIGhy ZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9la3IvZHJhZnQtcmVzY29ybGEtdGxzLWN0bHMiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vZWtyL2RyYWZ0LXJlc2NvcmxhLXRscy1jdGxz PC9hPjxicj4NClszXSA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1yZXNjb3JsYS10bHMtY3Rscy8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJlc2NvcmxhLXRscy1jdGxzLzwvYT48YnI+DQpbNF0g PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9sYWtlL2tBQ3dX N1BYcm1UUmE0UHZYUTBUQTM0eEN2ayIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9tYWlsYXJj aGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9sYWtlL2tBQ3dXN1BYcm1UUmE0UHZYUTBUQTM0eEN2azwv YT48YnI+DQpbNV0gPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5n LzEwNi9tYXRlcmlhbHMvc2xpZGVzLTEwNi10bHMtY29tcGFjdC10bHMtMTMtMDAucGRmIiB0YXJn ZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTA2L21h dGVyaWFscy9zbGlkZXMtMTA2LXRscy1jb21wYWN0LXRscy0xMy0wMC5wZGY8L2E+PGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpUTFMgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPlRMU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RscyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdGxzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U1ksIERtaXRyeSBCZWx5YXZza3k8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN7PR11MB25472D90A2F91F2DDD3A9609C94E0BN7PR11MB2547namp_-- From nobody Thu Nov 21 08:40:48 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B071200BA for ; Thu, 21 Nov 2019 08:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=baWBR/Q8; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=z6D1dWs2 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 NQytSSiJ4rPQ for ; Thu, 21 Nov 2019 08:40:44 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 082BC120125 for ; Thu, 21 Nov 2019 08:40:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1812; q=dns/txt; s=iport; t=1574354444; x=1575564044; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=kGXMlidV8S5E5UOA8Yfyma7NuMvKKXVSmuvyw0fysNw=; b=baWBR/Q8Dll1OafNFJbdmoKLwWRhBMWH8BSf6je4hTyWYvpqcZS9P13+ jPSU1kn6hLYjTNscLgzxefGL/vNhRAkJ259fFKYH7LDeDB+24TM5vwgJ5 G/urghOFFVSCZR9vaEPxB6vxuZgohWf/2AKqSoiOpmDljwCUOybizcsDY Y=; IronPort-PHdr: =?us-ascii?q?9a23=3A0YYwHxaHBfeaMHvV6fgfflT/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavybCU/BM1EXXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BPCwCIvdZd/5pdJa1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgX6BSyknBWxYIAQLKgqHZgOKa06CEZgBglIDVAkBAQEMAQEYCwo?= =?us-ascii?q?CAQGEQAKCKCQ4EwIDDQEBBAEBAQIBBQRthTcMhVEBAQEBAwEBEAsdBgEBLAw?= =?us-ascii?q?LBAIBCBEEAQEfECcLHQgCBAESCBqDAYJGAy4BAgyjHwKBOIhggieCfgEBBYF?= =?us-ascii?q?IQYMLGIIXAwaBNowWGoFAP4ERRoJMPoJiAQEDAYFHCQ+DQIIsrjQKgiuHGoU?= =?us-ascii?q?miSuCPodqj3COSIg4kVQCBAIEBQIOAQEFgWkigVhwFTuCbFARFIZIgScBDII?= =?us-ascii?q?/hRSFP3SBKI1fgS8BgQ4BAQ?= X-IronPort-AV: E=Sophos;i="5.69,226,1571702400"; d="scan'208";a="662675616" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Nov 2019 16:40:42 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id xALGeg0M009234 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Nov 2019 16:40:42 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 21 Nov 2019 10:40:42 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 21 Nov 2019 10:40:41 -0600 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 21 Nov 2019 10:40:41 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RDt5CLjU5sqvp/iPlOl9bBdSsixJwdchGBW6XdOWzy17vG8aLpyo8TIGIhYc4eiB5CMmPJmBXMDqVjL4p82edUmPTirAj8HfywNX+hZGPkSnw9VLINq0uvM4bVq28Vq68Ybw/IJvEVX2JoV9PgL5EOhaOhizJ5EZoezIik3ibeJ9ExYr0wi4MWgBx/O97wImYz9hFLHPQOzJxJXgu05CCyQ+VTax4TsJWN9uuvsR3fMQqJg6AFtoa80jV1g19Di/euWtycR6McUNi0LK57oUQPHbHw33Fuqs/pIs7ztx7rZh9+VYsQ/Bp4yAbU++6WUuzwctosLRZQfIPruyhYKlUQ== 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=TtJfoM3cgtF7vKaHMN+aKs5EYOhQJtXCsqbyiaBwHSc=; b=FdSay3s1r/VX9Be9oTtvAwTHElHBQi4kYjNnnmxKEASivrWngeWKVpzjgB1uqbrruwdgTX94FFIHJSdD5/Bg16hGGP45ZNGiKhwTfe4CAXLgX3PyRshuyh+gbV/gDgpZ0tmYuD6QmFE1UwKo69Z3XRfO5Rkcp2drI12ObquMuOhjXslOe05OY1wZVuouktxNp4OafDkVgPDIhPPvICzW+qFGiHqhKJUitlJepuwedfQ472JBBiSx/0WYVfKC8dKF06X5SP2HzOBbn8ZGXcesW33MMh+TEI02bxYH/t8ZrgP2AKlS/Ayk0U4gkS7DV7pVJoN//eBcFfuNkRxKab4J0g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TtJfoM3cgtF7vKaHMN+aKs5EYOhQJtXCsqbyiaBwHSc=; b=z6D1dWs2lM/sTdprUtnfh4QLK+tPbYljF7yHjRWh7XASi8JmLC2Jb/MDlwHc713PoCnniPESxM9pE/QECjAsMHAf5QTBaO9t3+8QPi9BRJlFLK2utlfH9SikCvqaIGuXRJSTTJG/ct6c51qp2CDrXg2yrGl3QKDZ6f7KuLkq+Mo= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2594.namprd11.prod.outlook.com (52.135.246.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.17; Thu, 21 Nov 2019 16:40:40 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5c82:bb6a:d0f0:b802]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5c82:bb6a:d0f0:b802%6]) with mapi id 15.20.2474.019; Thu, 21 Nov 2019 16:40:40 +0000 From: "Panos Kampanakis (pkampana)" To: Sean Turner , TLS List Thread-Topic: [TLS] Adoption call for draft-davidben-tls-batch-signing Thread-Index: AQHVoDjmo2uwrcUz4kKnCRDJOcjVN6eVzxzg Date: Thu, 21 Nov 2019 16:40:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [173.38.117.87] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aa93b0e4-ea8c-4d1c-fe62-08d76ea18b8d x-ms-traffictypediagnostic: BN7PR11MB2594: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0228DDDDD7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(366004)(376002)(136003)(39860400002)(13464003)(189003)(199004)(8936002)(6436002)(8676002)(256004)(446003)(6306002)(14444005)(52536014)(9686003)(7696005)(26005)(2906002)(186003)(55016002)(76176011)(11346002)(5660300002)(6246003)(53546011)(6506007)(81156014)(99286004)(102836004)(305945005)(229853002)(316002)(66066001)(71190400001)(6116002)(14454004)(81166006)(76116006)(110136005)(33656002)(74316002)(66476007)(66556008)(66946007)(66446008)(64756008)(7736002)(25786009)(71200400001)(966005)(86362001)(478600001)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2594; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EZCa/KYuSF48WXmp9PADnfjakb5E7Neg8ec38RTQ9TZZXAm5u9pxb9Tra9Ik7vN48hIUTP8JH1Iyv133R+7GtYVFCdaJk7DGJqHrjKlWmEnbIIAeuNd/nCHfng5yEr1Djb0A7kaYmzZA1B3Atcc7PoQCHDFfcw4X9BBW36W0H7epY5Xr2JMzvybz38VEPd4yz38nUlj9VlykrYPXNYS25p2qnY+6qaCaVugeBtexzvK9HG2fsHeFdrh5mMSu/mxohochIrtDIayTLR2r0MGXwWmpJhRN1hDs51Mr/Ev9G659fDjR0qtJuaRA3h+vNsWYlogXDtLtrsFtCWZJM7H6sWuBpF1NNOOYFTp8v+pcyvdoIj779dxfZ0pwNukQ5MazckvbJyUR1xg3HqTiik6EUQPY9Q4yPAAG2Jpx82i8vGcdM+U+K8tSXNreABlxO6gjhIytax5ZbRe/0xTtC7FLXnSJiTiKlXcD2Ed94em/PS0= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: aa93b0e4-ea8c-4d1c-fe62-08d76ea18b8d X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2019 16:40:40.4934 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yCxijboG1CKbXcw7bUHFTohHN7bmuVYsjXgIyfrPdHRvk4HPQUv5lFBGU6HiLiws5/SG23W2Md3ugnIoCwLFQA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2594 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls-batch-signing X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 16:40:46 -0000 I am not in favor of adoption, but I could be convinced otherwise. Sorry as this may have been discussed in IETF-106, but are we that worried = about the CPU cost of ECDSA or EdDSA that we are willing to have the server= buffer/slow down client connections, generate the Merkle tree and the batc= h signature? Do we really pull the private key from a hardware module or re= mote location with every signature instead of keeping it in volatile memory= in our application? I find it hard to buy the problem statement based on the usecases I know of= , and such a draft would require a lot of client upgrades and participation= in order to have fruitful results. I am ready to buy the argument, if ther= e is concrete data on actual usecases. Rgs, Panos -----Original Message----- From: TLS On Behalf Of Sean Turner Sent: Thursday, November 21, 2019 1:57 AM To: TLS List Subject: [TLS] Adoption call for draft-davidben-tls-batch-signing At IETF 106 there was support for adoption of "Batch Signing for TLS" [0] a= s a WG item. To confirm this on the list: if you believe that the TLS WG s= hould not adopt this as a WG item, then please let the chairs know by posti= ng a message to the TLS list by 2359 UTC 13 December 2019 (and say why). NOTE: : If the consensus is that this draft should be adopted as a WG item, then = this will necessarily result in a WG rechartering discussions. We would ha= ve gotten to this rechartering discussion anyway now that DTLS 1.3 is progr= essing out of the WG. Thanks, Chris, Joe, and Sean [0] https://datatracker.ietf.org/doc/draft-davidben-tls-batch-signing/ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Thu Nov 21 10:50:49 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D7A120B38 for ; Thu, 21 Nov 2019 10:50:48 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 FY2ITw8PWL3T for ; Thu, 21 Nov 2019 10:50:47 -0800 (PST) Received: from bongo.elm.relay.mailchannels.net (bongo.elm.relay.mailchannels.net [23.83.212.21]) (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 CD504120119 for ; Thu, 21 Nov 2019 10:50:46 -0800 (PST) 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 10FFC341200; Thu, 21 Nov 2019 18:50:46 +0000 (UTC) Received: from pdx1-sub0-mail-a67.g.dreamhost.com (100-96-196-51.trex.outbound.svc.cluster.local [100.96.196.51]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 80E1F340A59; Thu, 21 Nov 2019 18:50:45 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a67.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Thu, 21 Nov 2019 18:50:45 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Robust-Duck: 039622d90e7fa291_1574362245784_1173083576 X-MC-Loop-Signature: 1574362245784:1487627048 X-MC-Ingress-Time: 1574362245783 Received: from pdx1-sub0-mail-a67.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a67.g.dreamhost.com (Postfix) with ESMTP id AE18EA9987; Thu, 21 Nov 2019 10:50:39 -0800 (PST) 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=3M3xuPMynDcYXp RniNQO9KdMW68=; b=mhB5mS3GhcW1mYF6hUivDuV0rKBWtnsOEIg5bLS4GguKYn McnKYoYjzOhrBQiGRSh8VCoUqxgRMgqCO0mCifkHwwIj4IouhrDWqFS+Avjx9GH0 keKEBybPT42osleW6CeZXHS4NWcGXr0j8fxTTa5zGBYB1de3zne9fOIMiUxV0= Received: from localhost (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (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-a67.g.dreamhost.com (Postfix) with ESMTPSA id 5AD06A997A; Thu, 21 Nov 2019 10:50:38 -0800 (PST) Date: Thu, 21 Nov 2019 12:50:34 -0600 X-DH-BACKEND: pdx1-sub0-mail-a67 From: Nico Williams To: David Schinazi Cc: tls@ietf.org Message-ID: <20191121185034.GB26241@localhost> References: <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> <20191117002249.GV34850@straasha.imrryr.org> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> 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) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 18:50:48 -0000 On Thu, Nov 21, 2019 at 11:19:36AM +0800, David Schinazi wrote: > Regarding Viktor's suggestion, I personally believe it would increase the > complexity of the proposal, and I don't see use-cases compelling enough > to warrant that complexity. I would rather keep this proposal as simple as > possible. Complexity? I don't see it -- and you didn't show it, only asserted it. But the protocol is a bit broken -yes, broken- without that "option", and here's why: the whole point of this extension is to - a) ensure that clients always have the resumption tickets they need, - and b) to reduce ticket issuance to the minimum necessary for (a), and, well... - that means only issuing resumption tickets when the client needs one to replace the one it's using, - and if the client and server are happy with ticket reuse, then it's up to the server to decide when the client's ticket may no longer be reused, - but the protocol as specified can't let the client say "give me a new ticket IFF you won't let me reuse this one any more", - and it doesn't let the server do such conditional issuance because the client might NOT want to reuse and the server can't know that if the client can't tell it. That's the logical chain that leads me to declare this protocol broken. The fix is trivial. It most certainly isn't complex. A plain assertion that it's too complex is not responsive and insufficient to dismiss the WGLC comment. Nico -- From nobody Thu Nov 21 11:29:05 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBDC120B66 for ; Thu, 21 Nov 2019 11:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=zvnIiw34; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=e99iSRj/ 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 AGLkf7qHJSiA for ; Thu, 21 Nov 2019 11:29:01 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B310C120B64 for ; Thu, 21 Nov 2019 11:28:59 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1574364538; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=oft7n3iskcbnRKM4PWuM4TpjyeK7m8IZyADyclYJohw=; b=zvnIiw34wiTlOYJIQUgUurNEiVk7t7K5ndKRl/tPMge/RKG3M3kpkAQ4 zZEkrwy62Lo2f452O+IyBKzt+g/0Cw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1574364538; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=oft7n3iskcbnRKM4PWuM4TpjyeK7m8IZyADyclYJohw=; b=e99iSRj/2uFUeE1DJsI0iRKuUrnsgAq6+VeXl2Mq4Af5RHgDhujlmRHE GwG0KTBSenA8BfukOWUw8ItOl4YkGy15jefm4TGBfYRV2Eo6qYoZYb03de cXuezUtUlobYSSrJjnLdWZhp9q6KVl+PCk9GC5hpy+KP/Nu+c55Gncf/iU Brm/l7rGB37Q+ul5VTEh0cW1s9lgAjqEWE8Pj9AKt/z7QT7MoL8nheIeoL Cd9eDt67v8vL1PziEuRy9e7WpXnOCzf8L2KLmylhKf5DaorzfnQX9/YWHh DoB3+/NyglyCumaRwqaAEz0o49YccdFug+rZJgr3iptVoIVOzbdr1Q== Received: from fifthhorseman.net (unknown [182.55.86.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id A5FE7F9AF; Thu, 21 Nov 2019 14:28:57 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 5B2602038D; Fri, 22 Nov 2019 03:28:50 +0800 (+08) From: Daniel Kahn Gillmor To: Stephen Farrell , Christian Huitema Cc: "tls\@ietf.org" In-Reply-To: References: <7374648a-d684-87be-0807-219bc10793ac@cs.tcd.ie> <18514.1561564689@localhost> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Fri, 22 Nov 2019 03:28:49 +0800 Message-ID: <878so9jafi.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [TLS] publishing ESNIKeys under a .well-known URI... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 19:29:04 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed 2019-07-03 16:01:21 +0100, Stephen Farrell wrote: > It doesn't take much to encourage me so I just > pushed out that idea in I-D form:-) [1] [=E2=80=A6] > [1] https://tools.ietf.org/html/draft-farrell-tls-wkesni-00 Thanks for this (and for the -01 update for the draft). I like this work, and i think we should pursue it in the WG. A couple notes/questions: - Clients might use this, not just "zone factories". For instance, consider a client with limited access to the DNS that makes an initial direct connection to the hidden host, leaking SNI. If, in that connection, it also fetches this record, it could use that to bootstrap future connections to the host, right? The draft currently contemplates this briefly for followup queries for some clients, but it doesn't go into it in more detail. - Why is it hosted on the cover server, instead of on the hidden server? is that just so that the zone factory doesn't leak $HIDDEN to the network? Surely on a zone factory update, the zone factory already knows the eSNI for $HIDDEN so it could make the request with eSNI to https://$HIDDEN/.well-known/esni/$HIDDEN.json rather than to https://$COVER/.well-known/esni/$HIDDEN.json At the same time, for $COVER to publish this information potentially puts $COVER at more risk, right? And, a $COVER could *claim* to be a cover for $HIDDEN without approval of the $HIDDEN site by publishing these records; if anyone believes that claim, it could cause traffic to be re-routed through the ersatz $COVER. If it's going to be hosted at $COVER and not $HIDDEN, we should be explicit about what defends against such an attack. There could be an "obvious" reason for the choice of hosting it at $COVER instead of at $HIDDEN, but it should be spelled out in the draft. - If this is treated as a separate/independent source of authority about ESNI data for a host from the DNS (e.g. in the client examples contemplated in my first point above, not just the "zone factory"), then the draft probably needs some text discussing what to do when discovering a discrepancy between what's in the DNS and what's found at .well-known. Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXdblcQAKCRB2GBllKa5f +ECAAP0bRqKXJ5tsFMj9q6sDGvGPTX1ixrgu4YVTJ0nxhm3r/QEAmTjaQuQ1sMvK W4STDi7ntWZLfl0cedLqgiWOP99AUwA= =UI7u -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 21 14:28:39 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A8F12016E for ; Thu, 21 Nov 2019 14:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=sn3rd.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 vZASnOAdxamh for ; Thu, 21 Nov 2019 14:28:38 -0800 (PST) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 ECB2B120122 for ; Thu, 21 Nov 2019 14:28:37 -0800 (PST) Received: by mail-qv1-xf35.google.com with SMTP id n12so2136098qvt.1 for ; Thu, 21 Nov 2019 14:28:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=atmLwv06080BfFkYXjrkCkiXa5Nu+xmTFw69HOEC8lE=; b=Sd+imq4wBPN1rs/tCUyqGDLZFQRq7FTYN+GmT18TO/LY4k0GW2xe8cZeeBBuSnGyEK 9CXjOG9qKuQbQ1peYA7mzcKAv06XGz+1RellGqUMBn/3jXKQ9hVkEAXjG8R+N7XiubM+ Yo1izBSxWB7uquydsZ3f594Lm16FytLIacBkk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=atmLwv06080BfFkYXjrkCkiXa5Nu+xmTFw69HOEC8lE=; b=eyokqpb48aqO1BGG+/VrrJQcperuSWlfJH4REWg/thG+XEQ6plNyVwsk2C+RMP/UEV ScXX47e+Gy4KfXtcsd95YtwVdZB+6g4oHbxlFlY52uN/DYlds85xAHYeVla+FpQ/+KhB qWFrnTxKO3Gfvih21cITRlH7YU2pJOG8ck33Z7ctFPTrIO3NFosQLnK3NX1wDaHXPx11 pDcUaBNW2xaTPRYJVUZ0j4wWzDKrvkRV96YR8QLIUIIBR2rf/OMQuUGxKeb+donRd2Fe COvIvlwmzcorclL+AAzlJT/J8jt9B1MJaM7GsBy7/1o5ftkS4BJdDxUmHy57bGPa2Rl/ Je+A== X-Gm-Message-State: APjAAAUL1dgoNeB0X85HCpcUoHi8nna7sXUHTrC14XMyOfXI4w4GyYDF E9yLAh+QJMCMDipOGYk6ICdKtJymPXF5Ww== X-Google-Smtp-Source: APXvYqwwIDPCA0tNGtW/5y8zNo40KQMgLnD1rkqAnNZ7CyNY2zaan85bE2lgRJj8LL8r81nMVEc++g== X-Received: by 2002:a0c:d40c:: with SMTP id t12mr3370964qvh.157.1574375316937; Thu, 21 Nov 2019 14:28:36 -0800 (PST) Received: from [5.5.33.96] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id m5sm2351987qtu.3.2019.11.21.14.28.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Nov 2019 14:28:36 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <96B5CFA4-DF05-4BCF-A4FB-340DE2C890D2@sn3rd.com> Date: Fri, 22 Nov 2019 06:28:34 +0800 To: TLS List X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [TLS] Adoption call for draft-rescorla-tls-semistatic-dh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 22:28:39 -0000 At IETF 106 there was support for adoption of "Semi-Static = Diffie-Hellman Key Establishment" for TLS 1.3 [0] as a WG item. To = confirm this on the list: if you believe that the TLS WG should not = adopt this as a WG item, then please let the chairs know by posting a = message to the TLS list by 2359 UTC 13 December 2019 (and say why). NOTE: : If the consensus is that this draft should be adopted as a WG item, = then this will necessarily result in a WG rechartering discussions. We = would have gotten to this rechartering discussion anyway now that DTLS = 1.3 is progressing out of the WG. Thanks, Joe and Sean [0] https://datatracker.ietf.org/doc/draft-rescorla-tls-semistatic-dh/= From nobody Thu Nov 21 14:38:26 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAB312018D for ; Thu, 21 Nov 2019 14:38:25 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 b1KsudR4iIf0 for ; Thu, 21 Nov 2019 14:38:23 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 D790712016E for ; Thu, 21 Nov 2019 14:38:22 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id a17so3908756lfi.13 for ; Thu, 21 Nov 2019 14:38:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vvwpfMOwWFeD8GWPdJZJTa7J1CjnFQtedAIZxzBeqYs=; b=o2tOYhOlafZspEtFAIzZuOmra8V0l+ENMRo48wBGdpABPGaRFOOL+P4rkHPo7ZLpsH mvOoH+PaBAuSDYlBkhp6D9QBZsJl/CvoXIAUdG+9DreHIiPrVt71EvX3AXWCwHkY2sIe pvDsNOtod46CgJ5fmKPgfEAUpqcRqZ5bTFvQwxGoq8uh8ZpD09YFC+O/RkHo7L5SmiGz K3OsM58zP3rFPKw/LLC8yJQv4YyMBVZUUNfa+hccJ3UocnZ5TPKVyyS5fQ2l/0hOMW29 6LklHIorjC8wcKWe7Z1JLjhlDx4OIc41euN1WAod433YrXVYvoL0aaFsjVfmfwKLlckF 2xlw== 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=vvwpfMOwWFeD8GWPdJZJTa7J1CjnFQtedAIZxzBeqYs=; b=BsILOaLp8dXcok6bpLCTnYKiffeSNUT8za5zL8Fej8Z95UrUpi/aaZxZZZlOxtJ9iN zbjdU39UNnkqQahjyM0EhZ8e0h6ZWQJv9Fylrux9qR3UsqwDfih4NgfHVCOj2Ju787j4 uIikPkXnywZ/79epTaxb/i1aYoz+DpR0hUGrQlDDbbgFy47z+f+wGjdndsdLwINnxode jJT7K7HqYvK48hRo70igZRrbplzaefwE6kIBvlw32pqeIN1QksgP/v1YCL9Yn7lJuimS LtuZNp9gellWLjn5VFutmpBh/Mhv4YB40s3g7A6zPdNO3WXYOs6/GlvU9oLmmKE6igkw G85A== X-Gm-Message-State: APjAAAVCBDKceKrxZXsm/2IN7G/nVKNe86LYVBGN6BZWdicIL8E1K/45 d+1RsJijbOtimNPgSNe8GKMeYavq/NJFnb6pvuA= X-Google-Smtp-Source: APXvYqwqTBsgAAzb6zq/J6amMH7oy8Yj9DITfwVmA+mHatyleoofqZV5uApId74YbedvDInL0bVqCR3DjVWjgOvbETY= X-Received: by 2002:ac2:5193:: with SMTP id u19mr9578318lfi.83.1574375900857; Thu, 21 Nov 2019 14:38:20 -0800 (PST) MIME-Version: 1.0 References: <96B5CFA4-DF05-4BCF-A4FB-340DE2C890D2@sn3rd.com> In-Reply-To: <96B5CFA4-DF05-4BCF-A4FB-340DE2C890D2@sn3rd.com> From: Watson Ladd Date: Thu, 21 Nov 2019 17:37:12 -0500 Message-ID: To: Sean Turner Cc: TLS List Content-Type: multipart/alternative; boundary="000000000000504a220597e2f4fd" Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-semistatic-dh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 22:38:25 -0000 --000000000000504a220597e2f4fd Content-Type: text/plain; charset="UTF-8" On Thu, Nov 21, 2019, 5:28 PM Sean Turner wrote: > At IETF 106 there was support for adoption of "Semi-Static Diffie-Hellman > Key Establishment" for TLS 1.3 [0] as a WG item. To confirm this on the > list: if you believe that the TLS WG should not adopt this as a WG item, > then please let the chairs know by posting a message to the TLS list by > 2359 UTC 13 December 2019 (and say why). > In the spirit of flagrantly ignoring the pragmatics of chairs wishes let me say I support the adoption on the list. > NOTE: > : If the consensus is that this draft should be adopted as a WG item, then > this will necessarily result in a WG rechartering discussions. We would > have gotten to this rechartering discussion anyway now that DTLS 1.3 is > progressing out of the WG. > > Thanks, > Joe and Sean > > [0] https://datatracker.ietf.org/doc/draft-rescorla-tls-semistatic-dh/ > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000504a220597e2f4fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Nov 21, 2019, 5:28 PM Sean Turner <sean@sn3rd.com> wrote:
At IETF 106 there was support for adoption of "S= emi-Static Diffie-Hellman Key Establishment" for TLS 1.3 [0] as a WG i= tem.=C2=A0 To confirm this on the list: if you believe that the TLS WG shou= ld not adopt this as a WG item, then please let the chairs know by posting = a message to the TLS list by 2359 UTC 13 December 2019 (and say why).

In the= spirit of flagrantly ignoring the pragmatics of chairs wishes let me say I= support the adoption on the list.


NOTE:
: If the consensus is that this draft should be adopted as a WG item, then = this will necessarily result in a WG rechartering discussions.=C2=A0 We wou= ld have gotten to this rechartering discussion anyway now that DTLS 1.3 is = progressing out of the WG.

Thanks,
Joe and Sean

[0] https://datatracker= .ietf.org/doc/draft-rescorla-tls-semistatic-dh/
_______________________________________________
TLS mailing list
TLS@ie= tf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000504a220597e2f4fd-- From nobody Thu Nov 21 14:41:46 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479681201C6 for ; Thu, 21 Nov 2019 14:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 yFHNLWJ64C0C for ; Thu, 21 Nov 2019 14:41:42 -0800 (PST) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FD851201B7 for ; Thu, 21 Nov 2019 14:41:42 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id t20so5569676qtn.9 for ; Thu, 21 Nov 2019 14:41:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=Qx3bQOPFKLFYEEdelXRhrQvyQahCSwJPMUh60/XHWrM=; b=l/ktBVK8ZZsgmhoQzEx8FcLcs42SrxSP9AonUmOhhE+RHUg1tr5tgt0T3vyqdqVuy+ eY3Eyc2abddqoSZDFArF2ocNNASbjUx/Uy41vwC/stXPiG5dQZDt8IzYQ+kMFcci8m8N d1EMw+xD50Bwc0Gua/v+j1lgxNZvKQ//X9hTI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=Qx3bQOPFKLFYEEdelXRhrQvyQahCSwJPMUh60/XHWrM=; b=dyqvWvSnXlWr9lM1D+xl2JG5YjQVOzLq8LYt+u2RuRJ4eSGFPRs1LxTKEm3Ah4i5k8 txOob3UGhIo+LijX9CwZRNq32tvTGv7ofPf6UGospZKThwwh+V/iVjyo3CEcN1nqQCld /wNs6j9FKYhDr18QN3qIcfXMJG3VwRAvVt+Gw68eUT9Tx/ODLP7w3Acch3zS6Mpt9yZs dSQUbp4ZfA9+CMHov3wf1AM7SJe7mSB1vGr/QduzzRbiXc1f7Ei1bh6KRMVUUWxlSqdm oZ+7m1S6jACnaQ1lADldxqt5ymoYtJ8i+Y/9ADcF9H+SLsi/g0r5LKEge15h0wG4y8JU uo1Q== X-Gm-Message-State: APjAAAW7XS1gZk+QlA4Wl50szo6kt+PE92jxcBY5A+cuvCyK1cN/rYqY /bL511YGUtTj79SCIRijq12WskF4NbIP+w== X-Google-Smtp-Source: APXvYqyh63IQN9zIIYZBm4P2HBOrox7gZcno3DRY5J9O4VkKW9CRbXQyEIrF/uo5MdCfvXRZgNNVHA== X-Received: by 2002:ac8:66d7:: with SMTP id m23mr1388290qtp.53.1574376101225; Thu, 21 Nov 2019 14:41:41 -0800 (PST) Received: from [5.5.33.96] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id a62sm2130444qkf.81.2019.11.21.14.41.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Nov 2019 14:41:40 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <508EEDF7-73D2-4BE6-AFBA-710E5A5AB41F@sn3rd.com> Date: Fri, 22 Nov 2019 06:41:36 +0800 To: TLS List X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [TLS] WGLC for draft-ietf-tls-md5-sha1-deprecate X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2019 22:41:44 -0000 All, This is the working group last call for the "Deprecating MD5 and SHA-1 = signature hashes in TLS 1.2" draft available = https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/. = Please review the document and send your comments to the list by 2359 = UTC on 13 December 2019. Note the the GH repo for this draft can be found at: https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate Cheers, Joe, Chris, and Sean= From nobody Thu Nov 21 16:27:43 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDABC120129 for ; Thu, 21 Nov 2019 16:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.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 kTQ2bJcHAhtj for ; Thu, 21 Nov 2019 16:27:40 -0800 (PST) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 936FD1200B7 for ; Thu, 21 Nov 2019 16:27:40 -0800 (PST) Received: by mail-pj1-x102e.google.com with SMTP id w8so2249701pjh.11 for ; Thu, 21 Nov 2019 16:27:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sQmiFqZqfwpR7ZjrwQKS4n1hobu+hqlQf4dDRwhZKY0=; b=QOFp7w4XqgIKYU8tXdpdRxQ3XLOF6pXQORoW8F5DkCUTg2Akxgf3LnDggpeFe9mVjT HuFyqvqLHrpoNzesPCs/mBmY1V2iTqUkQyfUTebhbF7JD7wB3sQqYvGkYLCR06p0MaXR Ft+BFPnfWAyJTZOX19JdLPeqorNbDFW8aexB4= 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=sQmiFqZqfwpR7ZjrwQKS4n1hobu+hqlQf4dDRwhZKY0=; b=CvLZhDXpQOSU9sQrbKOC/fXs+dobFnOFJntGa6j0kyv4mQeTL3zhDeL49Kg5VD+LON VZoIMGvN5AmS0DNsUGhum9IvlCt/9EJC2KH0t3sJefokbHWw1SRuhm4U5NvBRx+lwO+P uS3ikiTFbHdLfJmvDsU2jhLfGTLUj3gMDWQ3AqeRONFZJ9Mk9/TEVs1isC1Qmt9uiqtq ee3k6STsispZ7qRmUtpBfKBvDHQgXXMrh4IMcwZ6+2hp2pnhYMijNcRfWdWUUPics+u0 krZh8Sf32Y7KPJj8bnJyiwDbzwJD45+QZLUKaKDdZy/tHJuPYxt85mnnCKP0gJyR4rxH NiSw== X-Gm-Message-State: APjAAAXsLXzbE4oDklusmtXAJ9L2T2ICq7gG/Ot5dF30Ku7bM+gs2H5f BT8vdwRjXfvGAEr2I6mk3H98kCihg5H687WD0r1T X-Google-Smtp-Source: APXvYqwZkUOQpey2gWN+Hz/y679BwA4sZqP3TY9vQmQwSVnm/ZsTxW24dx+M/6sSPcNHh3xOR6svo6mZ69P9E15YhIE= X-Received: by 2002:a17:90a:c789:: with SMTP id gn9mr14697138pjb.99.1574382459682; Thu, 21 Nov 2019 16:27:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Fri, 22 Nov 2019 08:27:23 +0800 Message-ID: To: "Panos Kampanakis (pkampana)" Cc: Sean Turner , TLS List Content-Type: multipart/alternative; boundary="0000000000004077a50597e47b14" Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls-batch-signing X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 00:27:42 -0000 --0000000000004077a50597e47b14 Content-Type: text/plain; charset="UTF-8" Deployments whose long-term private key is an ECDSA or EdDSA key stored in memory probably have no particular need for this, no. Such deployments probably see a signature cost comparable to the ECDH cost this document does not amortise. The existing signature algorithms are sufficient and no one's proposing removing them. However, there are many deployments where that is not the case. Hosting providers often get their certificates and keys from customers, who may just upload an RSA key. RSA keys are expensive enough to be the target of DoS attacks. Beyond that, long-term credentials are very sensitive and, yes, there are deployments that RPC to a remote location or even use hardware modules. Due to performance, I doubt the hardware module is common for server keys, but this draft can apply in both directions. We've seen client certificate deployments that do this and hit performance problems when the hardware cannot even keep up with *client* connection loads. Batch signing is aimed at these kinds of scenarios. You're right that peers need to be updated, but unupgraded peers do not block results. Load decreases as peers adopt this and DoS mitigations often involve selectively serving and dropping requests based on factors such as cost. This decreases the cost of a class of requests, which allows signers under load to serve more of them. For my part in the client space, we are interested in implementing this in BoringSSL and Chrome. On Fri, Nov 22, 2019 at 12:40 AM Panos Kampanakis (pkampana) < pkampana@cisco.com> wrote: > I am not in favor of adoption, but I could be convinced otherwise. > > Sorry as this may have been discussed in IETF-106, but are we that worried > about the CPU cost of ECDSA or EdDSA that we are willing to have the server > buffer/slow down client connections, generate the Merkle tree and the batch > signature? Do we really pull the private key from a hardware module or > remote location with every signature instead of keeping it in volatile > memory in our application? > > I find it hard to buy the problem statement based on the usecases I know > of, and such a draft would require a lot of client upgrades and > participation in order to have fruitful results. I am ready to buy the > argument, if there is concrete data on actual usecases. > > Rgs, > Panos > > > > -----Original Message----- > From: TLS On Behalf Of Sean Turner > Sent: Thursday, November 21, 2019 1:57 AM > To: TLS List > Subject: [TLS] Adoption call for draft-davidben-tls-batch-signing > > At IETF 106 there was support for adoption of "Batch Signing for TLS" [0] > as a WG item. To confirm this on the list: if you believe that the TLS WG > should not adopt this as a WG item, then please let the chairs know by > posting a message to the TLS list by 2359 UTC 13 December 2019 (and say > why). > > NOTE: > : If the consensus is that this draft should be adopted as a WG item, then > this will necessarily result in a WG rechartering discussions. We would > have gotten to this rechartering discussion anyway now that DTLS 1.3 is > progressing out of the WG. > > Thanks, > Chris, Joe, and Sean > > [0] https://datatracker.ietf.org/doc/draft-davidben-tls-batch-signing/ > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000004077a50597e47b14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Deployments whose long-term private key is an ECDSA o= r EdDSA key stored in memory probably have no particular need for this, no.= Such deployments probably see a signature cost comparable to the ECDH cost= this document does not amortise. The existing signature algorithms are suf= ficient and no one's proposing removing them.

= However, there are many deployments where that is not the case. Hosting pro= viders often get their certificates and keys from customers, who may just u= pload an RSA key. RSA keys are expensive enough to be the target of DoS att= acks. Beyond that, long-term credentials are very sensitive and, yes, there= are deployments that RPC to a remote location or even use hardware modules= . Due to performance, I doubt the hardware module is common for server keys= , but this draft can apply in both directions. We've seen client certif= icate deployments that do this and hit performance problems when the hardwa= re cannot even keep up with client=C2=A0connection loads. Batch sign= ing is aimed at these kinds of scenarios.

You'= re right that peers need to be updated, but unupgraded peers do not block r= esults. Load decreases as peers adopt this and DoS mitigations often involv= e selectively serving and dropping requests based on factors such as cost. = This decreases the cost of a class of requests, which allows signers under = load to serve more of them.

For my part in the cli= ent space, we are interested in implementing this in BoringSSL and Chrome.<= /div>
O= n Fri, Nov 22, 2019 at 12:40 AM Panos Kampanakis (pkampana) <pkampana@cisco.com> wrote:
I am not in favor of adoption,= but I could be convinced otherwise.

Sorry as this may have been discussed in IETF-106, but are we that worried = about the CPU cost of ECDSA or EdDSA that we are willing to have the server= buffer/slow down client connections, generate the Merkle tree and the batc= h signature? Do we really pull the private key from a hardware module or re= mote location with every signature instead of keeping it in volatile memory= in our application?

I find it hard to buy the problem statement based on the usecases I know of= , and such a draft would require a lot of client upgrades and participation= in order to have fruitful results. I am ready to buy the argument, if ther= e is concrete data on actual usecases.

Rgs,
Panos



-----Original Message-----
From: TLS <tls= -bounces@ietf.org> On Behalf Of Sean Turner
Sent: Thursday, November 21, 2019 1:57 AM
To: TLS List <tls@ietf= .org>
Subject: [TLS] Adoption call for draft-davidben-tls-batch-signing

At IETF 106 there was support for adoption of "Batch Signing for TLS&q= uot; [0] as a WG item.=C2=A0 To confirm this on the list: if you believe th= at the TLS WG should not adopt this as a WG item, then please let the chair= s know by posting a message to the TLS list by 2359 UTC 13 December 2019 (a= nd say why).

NOTE:
: If the consensus is that this draft should be adopted as a WG item, then = this will necessarily result in a WG rechartering discussions.=C2=A0 We wou= ld have gotten to this rechartering discussion anyway now that DTLS 1.3 is = progressing out of the WG.

Thanks,
Chris, Joe, and Sean

[0] https://datatracker.ietf.org/d= oc/draft-davidben-tls-batch-signing/
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000004077a50597e47b14-- From nobody Thu Nov 21 16:35:06 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C64C1200B7 for ; Thu, 21 Nov 2019 16:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 F0eI6SIeWr3l for ; Thu, 21 Nov 2019 16:35:02 -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 065CF12082C for ; Thu, 21 Nov 2019 16:34:37 -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 xAM0XKLF004745; Fri, 22 Nov 2019 00:34:36 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=9UqUvzoLV6nnu0Q2uPn62PspK+7AR7wBXjRxIFBivVE=; b=Y+vuarrNo7KXGOn536+2IQi/Hb4sniPI7WhmAyU+iYmlRnFGc6JiBdFdcAeJfJP6vz9d /mjgk0yWGS38qMh+jcMmnSP0su2WY1pm1iq+uYE4LGgVz/ffEIansMxInjXA6FWpoci6 eM66IFQiXBV2qwcfzMUK7iOJOhGVOhDTDFnyR3585kRnibMUMenYUAyfpbIT0Kwxz0lB iUx5ji5lIDSuYqFcy3BKAP4W7qpJlQjYJvb8lH11gnoGCl0s+owMk7zaSmvRZ7f2X5C2 97PYUSUKlxMZTEDl+d3V9Gl0KqJEoyhB8K2Bs9q2238NYTH2cC+Crcuaymbc1NAv7CG4 4Q== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2we3j2res5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Nov 2019 00:34:36 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAM0Vd20024891; Thu, 21 Nov 2019 19:34:35 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2wadb30gs3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 21 Nov 2019 19:34:34 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 21 Nov 2019 19:34:14 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Thu, 21 Nov 2019 19:34:14 -0500 From: "Salz, Rich" To: Sean Turner , TLS List Thread-Topic: [TLS] WGLC for draft-ietf-tls-md5-sha1-deprecate Thread-Index: AQHVoLzgvZaYJ6m0nUODILOyuUxBJaeXMZMA Date: Fri, 22 Nov 2019 00:34:13 +0000 Message-ID: <315F2BCF-11E0-4FBD-8420-865F29A66AD1@akamai.com> References: <508EEDF7-73D2-4BE6-AFBA-710E5A5AB41F@sn3rd.com> In-Reply-To: <508EEDF7-73D2-4BE6-AFBA-710E5A5AB41F@sn3rd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191110 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.216.139] Content-Type: text/plain; charset="utf-8" Content-ID: <5DE5BBD093BE3A4DAE1ACE30863B7BD4@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-21_07:, , 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=790 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911220001 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-21_07:2019-11-21,2019-11-21 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 bulkscore=0 mlxlogscore=755 spamscore=0 clxscore=1015 suspectscore=0 phishscore=0 adultscore=0 mlxscore=0 lowpriorityscore=0 malwarescore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911220001 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-md5-sha1-deprecate X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 00:35:05 -0000 PiAgICBUaGlzIGlzIHRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBmb3IgdGhlICJEZXByZWNh dGluZyBNRDUgYW5kIFNIQS0xIHNpZ25hdHVyZSBoYXNoZXMgaW4gVExTIDEuMiIgZHJhZnQgYXZh aWxhYmxlIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGxzLW1k NS1zaGExLWRlcHJlY2F0ZS8uICBQbGVhc2UgcmV2aWV3IHRoZSBkb2N1bWVudCBhbmQgc2VuZCB5 b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0IGJ5IDIzNTkgVVRDIG9uIDEzIERlY2VtYmVyIDIwMTku DQogIA0KSSBqdXN0IHJlLXJlYWQgdGhpcy4gIExvb2tzIGdvb2QuIFBlcmhhcHMgYSBzZW50ZW5j ZSBvZiByYXRpb25hbGUgaW4gc2VjdGlvbiAyIGFuZCAzIGV4cGxhaW5pbmcgd2h5IGl0cyBTSE9V TEQgTk9UIGFuZCBub3QgTVVTVCBOT1Qgd291bGQgaGVscCBleHBsYWluIHRoaW5ncyB0byBzb21l Pw0KDQo= From nobody Thu Nov 21 18:20:08 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D560120836 for ; Thu, 21 Nov 2019 18:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.405 X-Spam-Level: X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.244, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZss-2g-8GVs for ; Thu, 21 Nov 2019 18:20:05 -0800 (PST) Received: from mail-ua1-f44.google.com (mail-ua1-f44.google.com [209.85.222.44]) (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 5528912012A for ; Thu, 21 Nov 2019 18:20:05 -0800 (PST) Received: by mail-ua1-f44.google.com with SMTP id p18so1685992uar.7 for ; Thu, 21 Nov 2019 18:20:05 -0800 (PST) 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=YzUQM9w050KPGcOWpAuwRO7j1D5CjSv2EJXE4Opd+OA=; b=VgzfFUqRrNoLUCUmOvcPFIUj1urG8p+hjqp6cXc5lJaJSxr5v8ZnTcF0vPq7rrtRuy 7ymuTvJh0JBg40Ee1Se6avyAZzbdcv/MDH2XGSAIq/L84ls7aFk9clp8QVSXBzOq1UL5 /n2s61SeNRdCziSVaakbEvNM0tW3IoJtBe3ngbFHppbsB4ioEPhipC/gQE95fqGolfFL NeYQlL1nrNKN6iKtocmzW+QB+Dnizo7rdG3Iws7ksN75LnsJqkAubCzeaFE6ctmfmWuE roDxI2rU3VzwYdAsIKFfgQG9TI3SMfZEFnyYyQzidtVFTzbAgJxE1u8RQ1AgoBDrf3g4 IFAg== X-Gm-Message-State: APjAAAVQbXaY/iElNC+L8O+KeiWgq+/XdNJoaJgZ08+5rMji7/skSFs5 aLTvsuo1+C3imPxYIUAgk+iI5vsFQwEjBEuxbG8= X-Google-Smtp-Source: APXvYqx6O+jQD8ZsQ4jpbjtuIq3gFWzT2CXnFGJ7JYJmOuATVWomZwQwDv9AJe6zXFQmu7mJn9eoeaIcEEiWCAOQs3Q= X-Received: by 2002:ab0:5ea9:: with SMTP id y41mr7970857uag.114.1574389204397; Thu, 21 Nov 2019 18:20:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Migault Date: Fri, 22 Nov 2019 10:19:51 +0800 Message-ID: To: "Panos Kampanakis (pkampana)" Cc: Sean Turner , TLS List Content-Type: multipart/alternative; boundary="0000000000004433d20597e60d0e" Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 02:20:07 -0000 --0000000000004433d20597e60d0e Content-Type: text/plain; charset="UTF-8" I clearly support the adoption of the work, but it seems important to ensure cTLS integrates or remains in line with the work on compression that has been accomplished at the IETF - SCHC defined in lpwan might be a starting point. It also seems important to me that cTLS defines mechanisms that could be reused as TLS 1.3 evolves. Yours, Daniel On Fri, Nov 22, 2019 at 12:39 AM Panos Kampanakis (pkampana) < pkampana@cisco.com> wrote: > +1, support adoption. > > > > *From:* TLS *On Behalf Of * Dmitry Belyavsky > *Sent:* Thursday, November 21, 2019 4:46 AM > *To:* Sean Turner > *Cc:* TLS List > *Subject:* Re: [TLS] Adoption call for draft-rescorla-tls-ctls > > > > I support the adoption. > > > > On Thu, Nov 21, 2019 at 8:36 AM Sean Turner wrote: > > At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS WG > and the LAKE BOF, which is now a chartered WG [3]. After some discussions, > the ADs suggested [4] that the TLS WG consider whether this draft be > adopted as a TLS WG item. LAKE could then later specify/refer/adopt/profile > it, as appropriate. The authors revised cTLS and presented the revised > draft at IETF 106 [5]. At IETF 106 there was support for adoption of cTLS > as a WG item.. To confirm this on the list: if you believe that the TLS WG > should not adopt this as a WG item, then please let the chairs know by > posting a message to the TLS list by 2359 UTC 13 December 2019 (and say > why). > > NOTE: > : If the consensus is that this draft should be adopted as a WG item, then > this will necessarily result in a WG rechartering discussions. We would > have gotten to this rechartering discussion anyway now that DTLS 1.3 is > progressing out of the WG. > > Thanks, > Chris, Joe, and Sean > > [0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/ > [1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ > [2] https://github.com/ekr/draft-rescorla-tls-ctls > [3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ > [4] https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk > [5] > https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-tls-13-00.pdf > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > > > -- > > SY, Dmitry Belyavsky > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000004433d20597e60d0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I clearly support the adoption of the work, but it seems i= mportant to ensure cTLS integrates or remains in line with the work on comp= ression that has been accomplished at the IETF - SCHC defined in lpwan migh= t be a starting point. It also seems important to me that cTLS defines mech= anisms that could be reused as TLS 1.3 evolves.

Yours,=C2=A0
Daniel

On Fri, Nov 22, 2019 at 12:39 AM Panos Kampanaki= s (pkampana) <pkampana@cisco.com> wrote:

+1, support ado= ption.

=C2=A0

From: TLS <tls-bounces@ietf.org> On Behalf Of Dmitry Belyavsky
Sent: Thursday, November 21, 2019 4:46 AM
To: Sean Turner <sean@sn3rd.com>
Cc: TLS List <t= ls@ietf.org>
Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls<= u>

=C2=A0

I support the adoption.

=C2=A0

On Thu, Nov 21, 2019 at 8:36 AM Sean Turner <sean@sn3rd.com> wrot= e:

At IETF 105, ekr presented cTLS (Compact TLS) [0][1]= [2] to both the TLS WG and the LAKE BOF, which is now a chartered WG [3].= =C2=A0 After some discussions, the ADs suggested [4] that the TLS WG consid= er whether this draft be adopted as a TLS WG item. LAKE could then later specify/refer/adopt/profile it, as appropri= ate. The authors revised cTLS and presented the revised draft at IETF 106 [= 5].=C2=A0 At IETF 106 there was support for adoption of cTLS as a WG item..= =C2=A0 To confirm this on the list: if you believe that the TLS WG should not adopt this as a WG item, then please le= t the chairs know by posting a message to the TLS list by 2359 UTC 13 Decem= ber 2019 (and say why).

NOTE:
: If the consensus is that this draft should be adopted as a WG item, then = this will necessarily result in a WG rechartering discussions.=C2=A0 We wou= ld have gotten to this rechartering discussion anyway now that DTLS 1.3 is = progressing out of the WG.

Thanks,
Chris, Joe, and Sean

[0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/
[1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/
[2] https://github.com/ekr/draft-rescorla-tls-ctls
[3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/
[4] https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk<= br> [5] https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-t= ls-13-00.pdf
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls


=C2=A0

--

SY, Dmitry Belyavsky

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000004433d20597e60d0e-- From nobody Thu Nov 21 18:25:44 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2156120836 for ; Thu, 21 Nov 2019 18:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.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 5LmioEBsdYAU for ; Thu, 21 Nov 2019 18:25:41 -0800 (PST) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 90CD612012A for ; Thu, 21 Nov 2019 18:25:41 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id s10so2462163plp.2 for ; Thu, 21 Nov 2019 18:25:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k4F3mgIwBUdJ26SmULZdf0WdEirY0okym6di0ykFUn8=; b=SJab9wHQG2cLKeGln0ZyHjD8jJSXqzawho9XJqMpK3uPfEkRNE1jgO6IL6Mbq5gTmz Jy5JbWiMVZrkxZlWJZw8Nomif1wXwuoqbzKfoBNsBSGWdzPuAmQHRlpal5N5OmVrYh9g 9p2Dyu6xYktARlJ44nRR41gQUA6mBhvcWkFCM= 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=k4F3mgIwBUdJ26SmULZdf0WdEirY0okym6di0ykFUn8=; b=iiza4PV0C4ewRspnOpPzF/ECjgLi8ZjxyFPwUap+OHXvPk9XNSClfUxWX0KAqtFAev g20Mi8iAZEyYDlwN09gnLtHu31x8M26ta6Au4Z/x/u7wIFm0HrwT6xRZQY8nnD5ho285 8meZSEiErKjAC9EAv5Jr7CU91BzqZVbZgkzKYPKAlLTCEFtK0iqAA0fSuk8dTm+Wpe8m cLt2sjniR1+bEd5YMXBLUag2/ytu52AW04efW7wbkovqqKrG/PJ44+yBpeqQuCh1z7km DpCyMF5CbUVfrxYcOGlaXByo0a2weTAgiiQ7TnZCI3p3OAmdhtcEcmuFqS3uQAYJ3y1X IXgg== X-Gm-Message-State: APjAAAUytGXoiDHEXOMWMzIIb5kfBk9HWTkIi9kvJQ8iui0uUUERwyk4 DlkgnwaeTcEDsxGIaTsIvdyLMIEkwMzvUdeGTRsp X-Google-Smtp-Source: APXvYqwvVJ8LX+mpSx4neNFD0eTpAzo1Uf9LCy2ftAEwb//l0YTVn6h73fge7aS7oazkHpJzA5KMe92XctOif7nRn6c= X-Received: by 2002:a17:90a:974b:: with SMTP id i11mr15578569pjw.47.1574389540717; Thu, 21 Nov 2019 18:25:40 -0800 (PST) MIME-Version: 1.0 References: <508EEDF7-73D2-4BE6-AFBA-710E5A5AB41F@sn3rd.com> <315F2BCF-11E0-4FBD-8420-865F29A66AD1@akamai.com> In-Reply-To: <315F2BCF-11E0-4FBD-8420-865F29A66AD1@akamai.com> From: David Benjamin Date: Fri, 22 Nov 2019 10:25:24 +0800 Message-ID: To: "Salz, Rich" Cc: Sean Turner , TLS List Content-Type: multipart/alternative; boundary="0000000000005083d30597e6219f" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-md5-sha1-deprecate X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 02:25:43 -0000 --0000000000005083d30597e6219f Content-Type: text/plain; charset="UTF-8" On Fri, Nov 22, 2019 at 8:35 AM Salz, Rich wrote: > > This is the working group last call for the "Deprecating MD5 and > SHA-1 signature hashes in TLS 1.2" draft available > https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/. > Please review the document and send your comments to the list by 2359 UTC > on 13 December 2019. > > I just re-read this. Looks good. Perhaps a sentence of rationale in > section 2 and 3 explaining why its SHOULD NOT and not MUST NOT would help > explain things to some? > To that end, the combination of client advice in sections 2 and 4 is a bit odd. Section 2 uses SHOULD NOT include MD5 and SHA-1, but section 4 says the client MUST NOT accept the MD5 SHA-1, even if it included it. Why would the client include it in that case? It seems the two should either both be MUST NOT or both be SHOULD NOT. I think client-sent alerts in section 4 are also wrong. handshake_failure means the sender was unable to negotiate parameters, and insufficient_security is a variant of handshake_failure. This is the client reacting to the server sending something inconsistent with the ClientHello, so it should be illegal_parameter. In the context of ServerKeyExchange signatures, handshake_failure or insufficient_security would be sent by the *server* if the *client* only advertised MD5 and SHA-1. (In principle the client rules in section 4 are redundant with the text in section 2. It's just a restatement of negotiation requirements: your advertisement to the peer should match how you react to the peer's selection. But it's nice to write it explicitly and the document is not very long.) Some additional nitpicks: This document mostly writes "SHA-1", but the introduction has an instance of "SHA1". Section 2 should probably have a "the" before the first occurrence of "signature_algorithms extension". Section 4 includes both server behavior and the client restatement of negotiation requirements above, but section 5 does not include the corresponding server restatement of negotiation requirements. Otherwise, the document looks good to me. --0000000000005083d30597e6219f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Nov 22, 2019 at 8:35 AM Salz, Ric= h <rsalz@akamai.com> wrote:
>=C2=A0 =C2=A0 This is the working group last call for the &q= uot;Deprecating MD5 and SHA-1 signature hashes in TLS 1.2" draft avail= able https://datatracker.ietf.org= /doc/draft-ietf-tls-md5-sha1-deprecate/.=C2=A0 Please review the docume= nt and send your comments to the list by 2359 UTC on 13 December 2019.

I just re-read this.=C2=A0 Looks good. Perhaps a sentence of rationale in s= ection 2 and 3 explaining why its SHOULD NOT and not MUST NOT would help ex= plain things to some?

To that end, the = combination of client advice in sections 2 and 4 is a bit odd. Section 2 us= es SHOULD NOT include MD5 and SHA-1, but section 4 says the client MUST NOT= accept the MD5 SHA-1, even if it included it. Why would the client include= it in that case? It seems the two should either both be MUST NOT or both b= e SHOULD NOT.

I think client-sent alerts in sectio= n 4 are also wrong. handshake_failure means the sender was unable to negoti= ate parameters, and insufficient_security is a variant of handshake_failure= .=C2=A0This is the client reacting to the server sending something inconsis= tent with the ClientHello, so it should be illegal_parameter. In the contex= t of ServerKeyExchange signatures, handshake_failure or insufficient_securi= ty would be sent by the server=C2=A0if the client=C2=A0only a= dvertised MD5 and SHA-1.

(In principle the client = rules in section 4 are redundant with the text in section 2. It's just = a restatement of negotiation requirements: your advertisement to the peer s= hould match how you react to the peer's selection. But it's nice to= write it explicitly and the document is not very long.)

Some additional nitpicks:
This document mostly writes &quo= t;SHA-1", but the introduction has an instance of "SHA1".
Section 2 should probably have a "the" before the first o= ccurrence of "signature_algorithms extension".
Section = 4 includes both server behavior and the client restatement of negotiation r= equirements above, but section 5 does not include the corresponding server = restatement of negotiation requirements.

Otherwise= , the document looks good to me.
--0000000000005083d30597e6219f-- From nobody Thu Nov 21 19:29:35 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4F412084C; Thu, 21 Nov 2019 19:29:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Cc: iesg-secretary@ietf.org, joe@salowey.net, Joseph Salowey , tls-chairs@ietf.org, tls@ietf.org Message-ID: <157439337384.32512.2619253488901300031.idtracker@ietfa.amsl.com> Date: Thu, 21 Nov 2019 19:29:33 -0800 Archived-At: Subject: [TLS] Publication has been requested for draft-ietf-tls-dtls-connection-id-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 03:29:34 -0000 Joseph Salowey has requested publication of draft-ietf-tls-dtls-connection-id-07 as Proposed Standard on behalf of the TLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ From nobody Thu Nov 21 19:30:30 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1681202DD for ; Thu, 21 Nov 2019 19:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnrMItr44JUL for ; Thu, 21 Nov 2019 19:30:27 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 5F8EC120103 for ; Thu, 21 Nov 2019 19:30:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574393422; bh=7x6q8kFPj4zNdpAI9bNY4s6lhqRJXg4DwjHujhUZvWQ=; h=X-UI-Sender-Class:From:To:References:In-Reply-To:Subject:Date; b=jiwhAvN27GMdq95cf33tOlQMR9DCLluPaKeTZzoACJrcO60PqrONIrk7zdT5u8UMB 4w3TioQPNI/iiPZ4vzza4TEsqZk0pNBsQS4LjhGs1Jr4KcIo/8RdI4uwLJCxJZOUh9 QbRzsHx4+Uxo+eeh/7JoaU1bEJu4aO76kig55Ivs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from E119863 ([31.133.147.34]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MtfNf-1hhXmc2MV5-00vBvY; Fri, 22 Nov 2019 04:30:22 +0100 From: To: "'Sean Turner'" , "'TLS List'" References: <96B5CFA4-DF05-4BCF-A4FB-340DE2C890D2@sn3rd.com> In-Reply-To: <96B5CFA4-DF05-4BCF-A4FB-340DE2C890D2@sn3rd.com> Date: Fri, 22 Nov 2019 11:30:18 +0800 Message-ID: <000001d5a0e5$2bac1330$83043990$@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLRCfyM9PkkZ1+iNLolsprvXsa7t6WfthZA Content-Language: en-us x-ts-tracking-id: 10182406-f88f-4fd2-a35b-c13ccb4e09bf.0 x-checkrecipientchecked: true X-Provags-ID: V03:K1:ntgo23GaTUPhU33ApATxFyM7fQtRHuVRL18Ve8glJ054hzwFyu8 f4uA8pb6kOdB8rqt2iIuK9aAfldV4LWfS/jeGYOK71nD+UXNB/JNcsjVthNVOVI5YYbolQL 9VBAckPEyDfWmnT5lEI+iwkrZUY+Ss/98lxRVBGjIARQ5aZ3rUKtxzVcImwuJhE3EuJ4Izn HU6s8GjAxSDTosAr3Zn3w== X-UI-Out-Filterresults: notjunk:1;V03:K0:98JFbDWOqMA=:X9hTHyM3gu2C/pqvqtptC2 W9SX1WR2WRNXVKec3aqj43kx7LkGF8TNC5rQYegxpnIn/O1xCKNsCOP3pFgbO8wRobNwej+5c tZZ4RAIepWohnvcbgakFGLfemseVjpzogyywU4tH7m3LQ1BmwG3GjhCA2FU8bvdgdiMOv/FhI /fx63GTmM5Quu7pXoLdbor9V2RcokQqijnu1WEBK2XVJfAFeREj073lsyJQFVcPRIXm2ZWXD/ +STKQiVwfploQGSbTKaxSE4Rg/hwiGMTVe4RlR3O7pF9p/UAitFGcA41jK5fbgG7rOOVW3lir Wji2kpszMlq0EedfZ/cqiRvKJTh/o0B8QSFvSDJBB492SWcSX8wiIBDv2xMcMp3bx2nVrGk7H Gw4TZTZ5BSe5sSyme41GxRXZRjL9bmI6ffUy1W03v/DrWtYSQkvpApeTEb1n0s9JkfF7Nty0k IMKy5YTE5Qu6O884kjPQymiasFLSM2Upiv5P+H0cqFrnScteV6OK17tebX1dTIlqxvPOXP16n c74XARdnS/dKlQd/sjzR4HjGOEC1fDRZRvQKpl7xkTxcPffYaK60G0ESU9JORMTVeIlE9V8cW Ax4VZueJZ608GKYzIg9r/TeTbUeyqBpX7IB9mhzDk7dk0uIiP83c1pfF4G5Mp4v4QkLSmLve0 6YYTri9e/FcSHOxNLJAFe4rQDLVG6yfBV7geQd/W3kzRDbFEoYjsPOfVtlT9RRLyTyZQ8H1A+ Uqs53DhLLOzswmAuoFZ6zDLIq8kZ1rJs/YxS19YvdXuwnJxKzH1gEtY6N3TbhXSGS2QiBXGN9 SUKgW0QmNLQroYHA3qPqCHZI44VkiHYD283d1N6AZloWazWYBc5i6MDV3oa+3FdAYJXydhWyg zbaJiK+SbtkO2lgVKXtkU7oPfkLfRyP5MDR2rV8wttFScDvA+1wKzerFG+ThI0vRNYXB+vq7g eDjI6eCoPTkz0ywyLhrf41rKVAkk0Imdw9Hu08K0xmZpKSuAvM1tY/iFQb7twfPouLYwfnspV VoKKDviG2Vh6EKkLj7uiAau6siYUk6KrITlQEA44XhssryEQfWrq9RVBTrlFdT5IhGJ3CNSzP XQyk65kcjA0gDyjLwTE8nL15DqL4zKJQBwY8XYdqfoc5fZuSxw5kd9Y8/0ksOcnJKzJvSppud 8sBrSdxvFb112H1XCxaWWKYD4oHU6T6BEjEngZ04RKHZBdxipuJ+X0clEgOPsDH+7a4lOMBKn vs5LkJV5ytsF+crOqQB1vQwikfiCCiFsj36fXmEw/VNxQDqtsoQgmY3qugFA= Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-semistatic-dh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 03:30:29 -0000 I am in favor of adopting this document as a starting point for further work. It fits nicely into the work on cTLS -----Original Message----- From: TLS On Behalf Of Sean Turner Sent: Friday, November 22, 2019 6:29 AM To: TLS List Subject: [TLS] Adoption call for draft-rescorla-tls-semistatic-dh At IETF 106 there was support for adoption of "Semi-Static Diffie-Hellman Key Establishment" for TLS 1.3 [0] as a WG item. To confirm this on the list: if you believe that the TLS WG should not adopt this as a WG item, then please let the chairs know by posting a message to the TLS list by 2359 UTC 13 December 2019 (and say why). NOTE: : If the consensus is that this draft should be adopted as a WG item, then this will necessarily result in a WG rechartering discussions. We would have gotten to this rechartering discussion anyway now that DTLS 1.3 is progressing out of the WG. Thanks, Joe and Sean [0] https://datatracker.ietf.org/doc/draft-rescorla-tls-semistatic-dh/ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Thu Nov 21 19:34:01 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DA512084A for ; Thu, 21 Nov 2019 19:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLpwoiVRS4WH for ; Thu, 21 Nov 2019 19:33:58 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 EC185120103 for ; Thu, 21 Nov 2019 19:33:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574393624; bh=V37tt0P8FbpNS8kggAw0Gfr9V8BjcW8XXClRR9hLC7w=; h=X-UI-Sender-Class:From:To:Cc:References:In-Reply-To:Subject:Date; b=huTTE5DPvjr0ETrcZLmF58FMUEBxu2PynkTvy7/sDpYxySyu52ldyQgxJK076ZTEx 4vXV63hB7uxm4W1Kw0rRmCRS0mWp79cFk+DsSobKaiQfyOtt3mF4Raf9IusTs1z9U/ bv5HdqlyiKkk4IELg2gKLI1Ka5bbP/Uv3XOPmv2o= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from E119863 ([31.133.147.34]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MtOGU-1hhor016mU-00uumI; Fri, 22 Nov 2019 04:33:44 +0100 From: To: "'Daniel Migault'" , "'Panos Kampanakis \(pkampana\)'" Cc: "'TLS List'" References: In-Reply-To: Date: Fri, 22 Nov 2019 11:33:39 +0800 Message-ID: <000201d5a0e5$a47e6740$ed7b35c0$@gmx.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01D5A128.B2A24380" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKGwWZ6z2czDM0oXE6NgAjmueUCdQGW5deGAgReMxsBgHKBPaYLagUA Content-Language: en-us x-ts-tracking-id: 5d991491-3d84-469a-abe8-66aa0106b3cd.0 x-checkrecipientchecked: true X-Provags-ID: V03:K1:YLFPSf9oqLWB/PkfzNzRn0kQQRPGbXx2ThV6qtCEc8ktmU30gTQ fyMGDzdxTKW2E8BFpPnXrVVxBTJx2NrSYKl3QUXXCe/g5lLv1tr8Nw7tPZ2b73Meds9KZOv XjPyOzfE+BHLIZE55cO6knrtc3ah5+2OdyVV8Xn2/cYHq1rk8CjjnBVI385O0Tj2upvgTGv 0/nGNb0mSQ/BE0GxKoiJQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:9cIKEGv5BvA=:wFGijjSx0/Ay/HxnULy7MG WhR6GWFf7gj0eisOMyrLm3smmKUpApr6IT3HE8FyP19/KIU3ok02f/48ZcBzmQ6J3PhZqjTib LCbPF6m1m5/zNUWKB2iT+lIEH2X52PbuFYUmAzcCvuNtHIZzm9XiU5zI3/Jfys7wbQ8mQRDhF HlnGMOsadCWOx7/YPJVrYV2dGp9b+FY3kqvqcPcevCkdHggs9WUAp/4pcuMbVlzKPT6e1fbr4 78iGCm5uwdMG2ObxvTmXC70Jli3ANR6ABfaeoSJxBklnCheYmGdWh39200wd/l4Tnz5Yn2sJ9 q4ra9ipuBqTXEjxBnlc9ir18UsbGn5cf+rQUaeY4/bFwZUpdQVfWoIKK1ZwL4E45h9nMHLORH 81UziYKlDYNYfr/rTaeHlizACuLy2XRJlyBuR0ncQN2SKSVm3p8y3OterXp+bybaEOTXbS2mX wBvFG4FeyvLSPjeflwNb3iajk47+12q+4tAx1mfS0ARD/NQJjGifRBIOZnzUDApMuwx21MBR6 WpJeWMIin5Ne4LObQFLZPq6j5Tquh97bYhuRNsZZNGngAgSGzAuGDihlvbneF/gG5Dp6aQ4D8 vT4eRdUdLDGmGFgkyllf3rDlfn6Rlr98o8gxW916KsAQLRorJFl+1n0Ab5XMgjHLrMowQ3DoC kDlXjVrWSyD7IH1ebBxF7zTknTpIcRc+b2GGHVSnBK4GSZQ6UOMIS8eEAQpcmeWPHG2qMdLyi +h3UgZo/KmujoQzBcOERwajLnTDTrWVnKQRxTYpzORgxApowk/hAy56W5FYA7adLwT+ywTwmA kGwcfn+WhnYmAFJnu4bxCwrL31/IIwljLaMM2bdEgvHYQq7POLcN75gRa/Vg/kCaKLpE/SAcc VnMxmcevx6IaOPAb2qViTr9wwQ2djnDAxGuTrPsH9nh3Kb63mM+YMkIW4rByXP/s9i5WHlaMm G/PT+TWAJy1YKV4Rzbtn0OZTE3e++coN+t3AD8Qr2A0+pgLPFjQ5UZYUP3DBjNGwN8+/OLhnq 5auYGoUvOhGIiqxLKCPcQGGVB5ldiU22FWYNP8oaLsMl8NPousLdZjRTpKJeR1l4NiAxrqTNQ qRCOBd/YdZUUcRWEoZNHDw8pbyRYANK92t5gaTLP9I3GBLP3kJCGk/gGvHps39pcny1tmKYA0 gU0v1QHogo+f0jmE33IPN9tD/fCbmUzKs8B9JxcgwGoql8HyLx4nEnT310J+PJaxvRdb++S/K 6CjLS5HcmtUxhXxZcxl5tyI01GWmOgycplApsrPQZdhn9M3CsIDk7ExP+olU= Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 03:34:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0003_01D5A128.B2A24380 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Daniel =20 Although inappropriate to discuss at the time of the adoption call I = wanted to point out that I looked at SCHC and was surprised to learn = that it is more than a compression scheme but also includes a protocol = for adding reliability. In my reading is essentially a replacement for = 6lowpan. Unfortunately, this design decision does not make it a well = suited mechanism for a generic compression mechanism. I am happy to get = convinced otherwise.=20 =20 Ciao Hannes =20 From: TLS On Behalf Of Daniel Migault Sent: Friday, November 22, 2019 10:20 AM To: Panos Kampanakis (pkampana) Cc: TLS List Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls =20 I clearly support the adoption of the work, but it seems important to = ensure cTLS integrates or remains in line with the work on compression = that has been accomplished at the IETF - SCHC defined in lpwan might be = a starting point. It also seems important to me that cTLS defines = mechanisms that could be reused as TLS 1.3 evolves. =20 Yours,=20 Daniel =20 On Fri, Nov 22, 2019 at 12:39 AM Panos Kampanakis (pkampana) = > wrote: +1, support adoption. =20 From: TLS > On = Behalf Of Dmitry Belyavsky Sent: Thursday, November 21, 2019 4:46 AM To: Sean Turner > Cc: TLS List > Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls =20 I support the adoption. =20 On Thu, Nov 21, 2019 at 8:36 AM Sean Turner > wrote: At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS = WG and the LAKE BOF, which is now a chartered WG [3]. After some = discussions, the ADs suggested [4] that the TLS WG consider whether this = draft be adopted as a TLS WG item. LAKE could then later = specify/refer/adopt/profile it, as appropriate. The authors revised cTLS = and presented the revised draft at IETF 106 [5]. At IETF 106 there was = support for adoption of cTLS as a WG item.. To confirm this on the = list: if you believe that the TLS WG should not adopt this as a WG item, = then please let the chairs know by posting a message to the TLS list by = 2359 UTC 13 December 2019 (and say why). NOTE: : If the consensus is that this draft should be adopted as a WG item, = then this will necessarily result in a WG rechartering discussions. We = would have gotten to this rechartering discussion anyway now that DTLS = 1.3 is progressing out of the WG. Thanks, Chris, Joe, and Sean [0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/ [1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ [2] https://github.com/ekr/draft-rescorla-tls-ctls [3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ [4] = https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk [5] = https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-compact= -tls-13-00.pdf _______________________________________________ TLS mailing list TLS@ietf.org =20 https://www.ietf.org/mailman/listinfo/tls =20 --=20 SY, Dmitry Belyavsky _______________________________________________ TLS mailing list TLS@ietf.org =20 https://www.ietf.org/mailman/listinfo/tls ------=_NextPart_000_0003_01D5A128.B2A24380 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Daniel

 

Although inappropriate to discuss at the time of the = adoption call I wanted to point out that I looked at SCHC and was = surprised to learn that it is more than a compression scheme but also = includes a protocol for adding reliability. In my reading is essentially = a replacement for 6lowpan. Unfortunately, this design decision does not = make it a well suited mechanism for a generic compression mechanism. I = am happy to get convinced otherwise.

 

Ciao

Hannes

 

From: = TLS <tls-bounces@ietf.org> On Behalf Of Daniel = Migault
Sent: Friday, November 22, 2019 10:20 AM
To: = Panos Kampanakis (pkampana) <pkampana@cisco.com>
Cc: TLS = List <tls@ietf.org>
Subject: Re: [TLS] Adoption call for = draft-rescorla-tls-ctls

 

I = clearly support the adoption of the work, but it seems important to = ensure cTLS integrates or remains in line with the work on compression = that has been accomplished at the IETF - SCHC defined in lpwan might be = a starting point. It also seems important to me that cTLS defines = mechanisms that could be reused as TLS 1.3 = evolves.

 

Yours, 

Daniel

 

On = Fri, Nov 22, 2019 at 12:39 AM Panos Kampanakis (pkampana) <pkampana@cisco.com> = wrote:

+1, support adoption.

 

From:= TLS <tls-bounces@ietf.org> On Behalf Of = Dmitry Belyavsky
Sent: Thursday, November 21, 2019 4:46 = AM
To: Sean Turner <sean@sn3rd.com>
Cc: TLS List <tls@ietf.org>
Subject: Re: [TLS] = Adoption call for draft-rescorla-tls-ctls

 <= /o:p>

I support = the adoption.

 <= /o:p>

On Thu, Nov = 21, 2019 at 8:36 AM Sean Turner <sean@sn3rd.com> = wrote:

At IETF = 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS WG and = the LAKE BOF, which is now a chartered WG [3].  After some = discussions, the ADs suggested [4] that the TLS WG consider whether this = draft be adopted as a TLS WG item. LAKE could then later = specify/refer/adopt/profile it, as appropriate. The authors revised cTLS = and presented the revised draft at IETF 106 [5].  At IETF 106 there = was support for adoption of cTLS as a WG item..  To confirm this on = the list: if you believe that the TLS WG should not adopt this as a WG = item, then please let the chairs know by posting a message to the TLS = list by 2359 UTC 13 December 2019 (and say why).

NOTE:
: If = the consensus is that this draft should be adopted as a WG item, then = this will necessarily result in a WG rechartering discussions.  We = would have gotten to this rechartering discussion anyway now that DTLS = 1.3 is progressing out of the WG.

Thanks,
Chris, Joe, and = Sean

[0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-c= tls/
[1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctl= s/
[2] https://github.com/ekr/draft-rescorla-tls-ctls
[= 3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctl= s/
[4] https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTR= a4PvXQ0TA34xCvk
[5] https://datatracker.ietf.org/meeting/106/materials/slid= es-106-tls-compact-tls-13-00.pdf
_________________________________= ______________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


 <= /o:p>

-- =

SY, Dmitry = Belyavsky

_______________________________________________
TLS = mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

------=_NextPart_000_0003_01D5A128.B2A24380-- From nobody Thu Nov 21 19:36:45 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815CC1200E5 for ; Thu, 21 Nov 2019 19:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=gmx.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZc8y0YjrVxD for ; Thu, 21 Nov 2019 19:36:41 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 2757B12090F for ; Thu, 21 Nov 2019 19:36:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1574393797; bh=a4+L6DJFlUX5EgbRYGjrKi5pug2IJITGfHsxbRX6MyQ=; h=X-UI-Sender-Class:From:To:References:In-Reply-To:Subject:Date; b=ABxrSmI96rDaXuoz/qlocQTxj4jbJgiNmw4PLVuQrPx6H6kW1hEMxRVa8siUftNi8 3xIuFxXcmVVkYH7MUzeYX/wdjOTAy3FSK8nj7EeGHsbjvCvdoSuGsEYIiHR5sAaTA/ nYlnNZj0fbzW/Hl8yBuG3cVZFY0UQxwxQH3OQBWw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from E119863 ([31.133.147.34]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N8ofO-1hk1je2AFy-015qEK; Fri, 22 Nov 2019 04:36:37 +0100 From: To: "'Sean Turner'" , "'TLS List'" References: In-Reply-To: Date: Fri, 22 Nov 2019 11:36:34 +0800 Message-ID: <001601d5a0e6$0b28e790$217ab6b0$@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKGwWZ6z2czDM0oXE6NgAjmueUCdaY0SJYQ Content-Language: en-us x-ts-tracking-id: 90a401f1-ca82-468c-b7c5-44d546ec69b0.0 x-checkrecipientchecked: true X-Provags-ID: V03:K1:Q1XleKj0yn7mwo0wUSFb0zD1UHKHnv9rNeXYuhEDR6Tzjm9OT8n AWtEcPvkJm2mel/zc2pZg8mU05fB6IrrJ0XT11fbWKe/yDB3eg6w7TOq+XeBJb9y2cFUGiT vJQFP/Xlou0CEnJ/m3s6kgZ3dCrTaoU682wKeJu2ZBtHNfRQquzbxfZzdJDB6E8qYi2uE8O 4orGD9lbExuEwSmzl18wg== X-UI-Out-Filterresults: notjunk:1;V03:K0:pTC4Mwd3jg0=:SRe8Qnv+4XsPBMvVbAqs40 lujvyfQl9eDEcDBjcsWV4HaIjTJDvjflaCClXdRBSn9J4Em+ZgqZg5ppJWufmWUuYMrHr9/Tf N8NfNQejPLdw6HKYN3X7vMEMBT/nCZVCyy3USjSUpk1hogOs9KfyCPg4P4s70fo2DVENBZEnq VKN/tUf8gJ1EHM2tfmVIuAooaOgODP04D88xXPHlxVS3zysV8d7uk3pPJlu1w81E45U1VTDIy w0I3T/pPoeXlDC4G0EfLJ+ClqcHBspicgecsyeydaioQPMMXkYxFXEH9e9KBiJCmyWsteOn+3 epehutlGWoPKiyYltvOSoSSQr7DMgFbjgEDd3mwLopN41vArvVWyf2GvPhSFYTNHeB7PqIZxq ZrfmDpN7dliJNSp9XjjsU4AdrlNYbSvWmecgMvBn0C8X4PCmkmMv7v7egLzNDZWhjBVmFc5kF 75TlKKY0SZvb/7YR6zfW9B6seZEgKY6KefwDqcE7aucQ2BVHnXI4ypGcAKqj484mpMZo+/7zC B2ICJg060WHTNXioyWJW8lnVs7wJoZ2m9CXGd+8TfBbCZm2wtWQ7jl3CUbA8t2Oc95+QDC64Y 4fhDLOW/Wo0ra15yvPbOl1rq8/GRXOA1wLtwjtNcIy+18PD6G/X1d3mYyrB+sEeh8JK5T5O91 o+sHCGZO3tqArBgJHZZX/Css4bYNJ1NfETAO1ZO1k1qRskjF8GgOxLuE9BW+ulbwkrmbz4TgP a7iXfRkOD2XmMz2qMuLnq5/hOR+GoDMsKF5P/4WZrq0JnuJorY77M9FVto7gku0YNHQQ0oMK7 U7wrarwlpRQKrcfTfdAl6lcisIRL5UavxMoBE/HCmI4IDNKtwMvv5AB1Urmywqe+LxhIrQWl3 ClF80nqLADSj84Y9OHH8Xx7ZUrrnUljZ6v2Ra56fBcHiha5daTo/QwH+Agwoh3DCrY9C0/fhI JzmkYIPuqD2JS6WE2AQfvomkJiZdGqRQ/ebM2a7zMqMx2OmRndyfQMXWwVZ0gVpheXT3IV2wq jVw5q9I2hgym4SPIPdWxn00SvRBTJb3+ciQUA5M2isSAb6uu2xXuHKOUVQL6nFRw37BdAKdjk uO0FFYrwFY8zLTKe+yig2uQmJrCbAfPs1gl9ImKkv7AiKy8+vXZwOu4+lY7KUAN2maUlMzY/w ai+G3XsWjjBbPgg+9XD1iXv9e0EORDUULGiGNryhrKeI4LgmJHoZSXkbkFiATOdd64MxlGjzZ fU2ieG+m3anC0sO0xaWKMh/smaWFkMmwMt1aUf8bdcLqCcBDdDdlmnkNRstM= Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 03:36:43 -0000 As a co-author of the document I am in favor of adopting it. I have started on implementation work on top of Mbed TLS already and plan to continue doing that work as it progresses through the IETF. -----Original Message----- From: TLS On Behalf Of Sean Turner Sent: Thursday, November 21, 2019 1:36 PM To: TLS List Subject: [TLS] Adoption call for draft-rescorla-tls-ctls At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS WG and the LAKE BOF, which is now a chartered WG [3]. After some discussions, the ADs suggested [4] that the TLS WG consider whether this draft be adopted as a TLS WG item. LAKE could then later specify/refer/adopt/profile it, as appropriate. The authors revised cTLS and presented the revised draft at IETF 106 [5]. At IETF 106 there was support for adoption of cTLS as a WG item. To confirm this on the list: if you believe that the TLS WG should not adopt this as a WG item, then please let the chairs know by posting a message to the TLS list by 2359 UTC 13 December 2019 (and say why). NOTE: : If the consensus is that this draft should be adopted as a WG item, then this will necessarily result in a WG rechartering discussions. We would have gotten to this rechartering discussion anyway now that DTLS 1.3 is progressing out of the WG. Thanks, Chris, Joe, and Sean [0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/ [1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ [2] https://github.com/ekr/draft-rescorla-tls-ctls [3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ [4] https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk [5] https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-tl s-13-00.pdf _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Thu Nov 21 21:13:30 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A0912022E for ; Thu, 21 Nov 2019 21:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQdbrObA2WYC for ; Thu, 21 Nov 2019 21:13:26 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ABF312022D for ; Thu, 21 Nov 2019 21:13:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 107C5BE4C; Fri, 22 Nov 2019 05:13:24 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLpC_vYl1z7G; Fri, 22 Nov 2019 05:13:21 +0000 (GMT) Received: from [31.133.146.56] (dhcp-9238.meeting.ietf.org [31.133.146.56]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 68C60BE3E; Fri, 22 Nov 2019 05:13:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1574399601; bh=bRdLULqxhcwqmgh0Px+I1yelbE1LKwObQQZNIqqRcbw=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=Wdlhhxpi4iKNfSaO2z3gAN9dxgK1aY+N7tY38ujWMVOCjpSCWlolvnmWwB0x9Usu5 t3hSNjmakTE2mCsqWWiW3Zq1XQ7LPVRGq72q/lt/3PZzEOJmaBaS4rOg15cL6E1E5i dYEawzvVwfRgFJeEsJpEQibqT1FDkt/+141Rd8mk= To: Daniel Kahn Gillmor , Christian Huitema Cc: "tls@ietf.org" References: <7374648a-d684-87be-0807-219bc10793ac@cs.tcd.ie> <18514.1561564689@localhost> <878so9jafi.fsf@fifthhorseman.net> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <6636c7da-39ec-ebef-905f-6458ac8c1a56@cs.tcd.ie> Date: Fri, 22 Nov 2019 05:13:13 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <878so9jafi.fsf@fifthhorseman.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TtavDey8VPoDaQwcDjq85Ypp49oOaWNwu" Archived-At: Subject: Re: [TLS] publishing ESNIKeys under a .well-known URI... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 05:13:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TtavDey8VPoDaQwcDjq85Ypp49oOaWNwu Content-Type: multipart/mixed; boundary="6pTs8akAFNepxxzBc71BT8O7vLL3jSU0P"; protected-headers="v1" From: Stephen Farrell To: Daniel Kahn Gillmor , Christian Huitema Cc: "tls@ietf.org" Message-ID: <6636c7da-39ec-ebef-905f-6458ac8c1a56@cs.tcd.ie> Subject: Re: [TLS] publishing ESNIKeys under a .well-known URI... References: <7374648a-d684-87be-0807-219bc10793ac@cs.tcd.ie> <18514.1561564689@localhost> <878so9jafi.fsf@fifthhorseman.net> In-Reply-To: <878so9jafi.fsf@fifthhorseman.net> --6pTs8akAFNepxxzBc71BT8O7vLL3jSU0P Content-Type: multipart/mixed; boundary="------------285E47BF49F9EF5D14231067" Content-Language: en-US This is a multi-part message in MIME format. --------------285E47BF49F9EF5D14231067 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, (As per the meeting discussion, I'll plan to revise the individual draft in the next while and then the WG can consider what to do about it. If ESNI/ECHO draft-06 is out first, I'll change to align with that. If not, we can worry about that later. In the meantime...) On 21/11/2019 19:28, Daniel Kahn Gillmor wrote: > On Wed 2019-07-03 16:01:21 +0100, Stephen Farrell wrote: >> It doesn't take much to encourage me so I just >> pushed out that idea in I-D form:-) [1] > [=E2=80=A6] >> [1] https://tools.ietf.org/html/draft-farrell-tls-wkesni-00 >=20 > Thanks for this (and for the -01 update for the draft). I like this > work, and i think we should pursue it in the WG. Cool. Thanks. >=20 > A couple notes/questions: >=20 > - Clients might use this, not just "zone factories". For instance, > consider a client with limited access to the DNS that makes an > initial direct connection to the hidden host, leaking SNI. If, in > that connection, it also fetches this record, it could use that to > bootstrap future connections to the host, right? Yep. > The draft currently contemplates this briefly for followup queries > for some clients, but it doesn't go into it in more detail. Right. I wasn't sure if people would like, or be freaked out by, that:-) >=20 > - Why is it hosted on the cover server, instead of on the hidden > server? is that just so that the zone factory doesn't leak $HIDDEN > to the network? Yes. Also - if adding a new $HIDDEN then first time around the zone factory can't use ESNI/ECHO to $HIDDEN. > Surely on a zone factory update, the zone factory already knows the > eSNI for $HIDDEN so it could make the request with eSNI to > https://$HIDDEN/.well-known/esni/$HIDDEN.json rather than to > https://$COVER/.well-known/esni/$HIDDEN.json Other than first time, as noted above. I've also had cases where things got out of whack (because I'd broken stuff) that meant ESNI stopped working to $HIDDEN for a bit. (The specific failures I've seen don't make a real difference to answering your question, as the zone factory does try out the new keys with $HIDDEN as part of it's work, but maybe some other failure cases might matter more.) > At the same time, for $COVER to publish this information potentially= > puts $COVER at more risk, right?=20 Yes. If $COVER is the public_name from the ESNIConfig though it doesn't seem much more of a risk. > And, a $COVER could *claim* to be a > cover for $HIDDEN without approval of the $HIDDEN site by publishing= > these records; if anyone believes that claim, it could cause traffic= > to be re-routed through the ersatz $COVER. If it's going to be > hosted at $COVER and not $HIDDEN, we should be explicit about what > defends against such an attack. Sure. In my case, the zone factory knows all the names but yes, discussion of the more general case is needed. >=20 > There could be an "obvious" reason for the choice of hosting it at > $COVER instead of at $HIDDEN, but it should be spelled out in the > draft. Ack. Will do. >=20 > - If this is treated as a separate/independent source of authority > about ESNI data for a host from the DNS (e.g. in the client examples= > contemplated in my first point above, not just the "zone factory"), > then the draft probably needs some text discussing what to do when > discovering a discrepancy between what's in the DNS and what's found= > at .well-known. True. In the zone factory case, such discrepancies are of course nominal. Otherwise, I can envisage a number of different client scenarios (client DoH/DoT availability can be yes, no or dunno; the client might have old ESNIConfig values or not, and HTTPSSVC might or might not be available etc.) And I guess there's even the case (that probably will freak someone out) where $HIDDEN might not even exist in the DNS at all if it is covered by a wild-card cert and if $HIDDEN is in the client's /etc/hosts or equivalent. (I think I could support that now in my servers but haven't actually deployed such a vhost - maybe I should:-) I'm not sure if this draft ought specify behaviour for such clients, but I can try add text describing the various cases I guess. (If that text were to stay in, then I'd guess that it'll make this document too long to include in the base ESNI/ECHO draft thus taking that option off the table maybe.) Cheers, S. >=20 > Regards, >=20 > --dkg >=20 --------------285E47BF49F9EF5D14231067 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------285E47BF49F9EF5D14231067-- --6pTs8akAFNepxxzBc71BT8O7vLL3jSU0P-- --TtavDey8VPoDaQwcDjq85Ypp49oOaWNwu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl3XbmkACgkQWrL68XsX K+p+FhAAj3PPid7m5CNsn8C4VpCo0SELTQgzAmRCV00XqNkAsStYzoyLWY0HepSO 0jm8o4jzAtTF+HoietgyhIsQQpzUTkWVdZ3aKmjcQDOC0aan4zdTRe1Ro6/P9ISn 9OZZU9NfupeP/GOEgwTO59U5fP0J2EtKyKwx5VylFhDNTz/YgnL7qMVJooHB/Hr0 1yazYA8WHew63c/5UpF3ybF/XjjR/AAb90nFJhWKVmoP0lRMNJWiMY2PmQtYv9ts p1isd0N5cMKJKmqa0SksjSBlYJS+dPs4fDHWcv9Z1JCRWjfQ5d2LJEjW83nor7e6 VrUATNkj/8t4f7FxdX5x685Ftp62vg+tB/nYvQ/Kl7kO+sFl+fFfT0vSjPkXsiYB +jGHrw+faFdR4IqR3qq2tuDUIyykHq8/Wo7IOhkNrz0yZfzZPvxOsoAgnUOyg8/o oIO0CdDbgEyS0Soa+5rI3Bw3NiFnbPGY0oSgQ08sdfhqSIB2idLbA1rNWTNoYmap jwzKOmk4j2QjnJo4s/Yt8c5m+KBW5V//VUv0vNdsFn6BEfmsv/OsX7hv992/dlE3 rGrv0Ti/Uor9VVoU9F/1fVB6X+e9zTJN+6PJFM3yUeT5vCeXWlbx+PrR6a5lo15L FKsRtTvOc/pp5XngcZGHwTpdqU6FP5e2B1tkXZSBZAhWVycrSRY= =M2mw -----END PGP SIGNATURE----- --TtavDey8VPoDaQwcDjq85Ypp49oOaWNwu-- From nobody Thu Nov 21 21:13:37 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C501012022D for ; Thu, 21 Nov 2019 21:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H77PM8cfq2z8 for ; Thu, 21 Nov 2019 21:13:26 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AB7412004E for ; Thu, 21 Nov 2019 21:13:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 147E5BE4D; Fri, 22 Nov 2019 05:13:24 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGYZarH_w5E4; Fri, 22 Nov 2019 05:13:21 +0000 (GMT) Received: from [31.133.146.56] (dhcp-9238.meeting.ietf.org [31.133.146.56]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4F357BE2E; Fri, 22 Nov 2019 05:13:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1574399601; bh=6llW1jTTjATCXJDjsjRGUAJoYYtaJJn8dBqPCkcYgy8=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=NBPI6I07JC6Uav/C1DzIgfb1cQw3tcnA4+ovVa6EUt7e1hewRSQjYspgQX9AKWdcm DFSx/Q6srM73AuaX2RklljwI5zY6VE7uwb5ka6HrzFjDL/qfG6GjWGtawjGB20q8Qp PtZEqchLbkeLXXLaMbbhImMENOBf0ZJRFpH1tSvc= To: Daniel Kahn Gillmor , Christian Huitema Cc: "tls@ietf.org" References: <7374648a-d684-87be-0807-219bc10793ac@cs.tcd.ie> <18514.1561564689@localhost> <878so9jafi.fsf@fifthhorseman.net> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <12d46f25-bfd6-ff16-1569-e6121d7de100@cs.tcd.ie> Date: Fri, 22 Nov 2019 05:13:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <878so9jafi.fsf@fifthhorseman.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BjPurnKaIfJMpZjEVsGDp56eG9DI10qGj" Archived-At: Subject: Re: [TLS] publishing ESNIKeys under a .well-known URI... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 05:13:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BjPurnKaIfJMpZjEVsGDp56eG9DI10qGj Content-Type: multipart/mixed; boundary="mgvTev2XPNrsZCRi1aTTY3tCU4VM6R4Xe"; protected-headers="v1" From: Stephen Farrell To: Daniel Kahn Gillmor , Christian Huitema Cc: "tls@ietf.org" Message-ID: <12d46f25-bfd6-ff16-1569-e6121d7de100@cs.tcd.ie> Subject: Re: [TLS] publishing ESNIKeys under a .well-known URI... References: <7374648a-d684-87be-0807-219bc10793ac@cs.tcd.ie> <18514.1561564689@localhost> <878so9jafi.fsf@fifthhorseman.net> In-Reply-To: <878so9jafi.fsf@fifthhorseman.net> --mgvTev2XPNrsZCRi1aTTY3tCU4VM6R4Xe Content-Type: multipart/mixed; boundary="------------7A4C65259F97965D4E815FF0" Content-Language: en-US This is a multi-part message in MIME format. --------------7A4C65259F97965D4E815FF0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, (As per the meeting discussion, I'll plan to revise the individual draft in the next while and then the WG can consider what to do about it. If ESNI/ECHO draft-06 is out first, I'll change to align with that. If not, we can worry about that later. In the meantime...) On 21/11/2019 19:28, Daniel Kahn Gillmor wrote: > On Wed 2019-07-03 16:01:21 +0100, Stephen Farrell wrote: >> It doesn't take much to encourage me so I just >> pushed out that idea in I-D form:-) [1] > [=E2=80=A6] >> [1] https://tools.ietf.org/html/draft-farrell-tls-wkesni-00 >=20 > Thanks for this (and for the -01 update for the draft). I like this > work, and i think we should pursue it in the WG. Cool. Thanks. >=20 > A couple notes/questions: >=20 > - Clients might use this, not just "zone factories". For instance, > consider a client with limited access to the DNS that makes an > initial direct connection to the hidden host, leaking SNI. If, in > that connection, it also fetches this record, it could use that to > bootstrap future connections to the host, right? Yep. > The draft currently contemplates this briefly for followup queries > for some clients, but it doesn't go into it in more detail. Right. I wasn't sure if people would like, or be freaked out by, that:-) >=20 > - Why is it hosted on the cover server, instead of on the hidden > server? is that just so that the zone factory doesn't leak $HIDDEN > to the network? Yes. Also - if adding a new $HIDDEN then first time around the zone factory can't use ESNI/ECHO to $HIDDEN. > Surely on a zone factory update, the zone factory already knows the > eSNI for $HIDDEN so it could make the request with eSNI to > https://$HIDDEN/.well-known/esni/$HIDDEN.json rather than to > https://$COVER/.well-known/esni/$HIDDEN.json Other than first time, as noted above. I've also had cases where things got out of whack (because I'd broken stuff) that meant ESNI stopped working to $HIDDEN for a bit. (The specific failures I've seen don't make a real difference to answering your question, as the zone factory does try out the new keys with $HIDDEN as part of it's work, but maybe some other failure cases might matter more.) > At the same time, for $COVER to publish this information potentially= > puts $COVER at more risk, right?=20 Yes. If $COVER is the public_name from the ESNIConfig though it doesn't seem much more of a risk. > And, a $COVER could *claim* to be a > cover for $HIDDEN without approval of the $HIDDEN site by publishing= > these records; if anyone believes that claim, it could cause traffic= > to be re-routed through the ersatz $COVER. If it's going to be > hosted at $COVER and not $HIDDEN, we should be explicit about what > defends against such an attack. Sure. In my case, the zone factory knows all the names but yes, discussion of the more general case is needed. >=20 > There could be an "obvious" reason for the choice of hosting it at > $COVER instead of at $HIDDEN, but it should be spelled out in the > draft. Ack. Will do. >=20 > - If this is treated as a separate/independent source of authority > about ESNI data for a host from the DNS (e.g. in the client examples= > contemplated in my first point above, not just the "zone factory"), > then the draft probably needs some text discussing what to do when > discovering a discrepancy between what's in the DNS and what's found= > at .well-known. True. In the zone factory case, such discrepancies are of course nominal. Otherwise, I can envisage a number of different client scenarios (client DoH/DoT availability can be yes, no or dunno; the client might have old ESNIConfig values or not, and HTTPSSVC might or might not be available etc.) And I guess there's even the case (that probably will freak someone out) where $HIDDEN might not even exist in the DNS at all if it is covered by a wild-card cert and if $HIDDEN is in the client's /etc/hosts or equivalent. (I think I could support that now in my servers but haven't actually deployed such a vhost - maybe I should:-) I'm not sure if this draft ought specify behaviour for such clients, but I can try add text describing the various cases I guess. (If that text were to stay in, then I'd guess that it'll make this document too long to include in the base ESNI/ECHO draft thus taking that option off the table maybe.) Cheers, S. >=20 > Regards, >=20 > --dkg >=20 --------------7A4C65259F97965D4E815FF0 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------7A4C65259F97965D4E815FF0 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------7A4C65259F97965D4E815FF0-- --mgvTev2XPNrsZCRi1aTTY3tCU4VM6R4Xe-- --BjPurnKaIfJMpZjEVsGDp56eG9DI10qGj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl3XbmkACgkQWrL68XsX K+p+FhAAj3PPid7m5CNsn8C4VpCo0SELTQgzAmRCV00XqNkAsStYzoyLWY0HepSO 0jm8o4jzAtTF+HoietgyhIsQQpzUTkWVdZ3aKmjcQDOC0aan4zdTRe1Ro6/P9ISn 9OZZU9NfupeP/GOEgwTO59U5fP0J2EtKyKwx5VylFhDNTz/YgnL7qMVJooHB/Hr0 1yazYA8WHew63c/5UpF3ybF/XjjR/AAb90nFJhWKVmoP0lRMNJWiMY2PmQtYv9ts p1isd0N5cMKJKmqa0SksjSBlYJS+dPs4fDHWcv9Z1JCRWjfQ5d2LJEjW83nor7e6 VrUATNkj/8t4f7FxdX5x685Ftp62vg+tB/nYvQ/Kl7kO+sFl+fFfT0vSjPkXsiYB +jGHrw+faFdR4IqR3qq2tuDUIyykHq8/Wo7IOhkNrz0yZfzZPvxOsoAgnUOyg8/o oIO0CdDbgEyS0Soa+5rI3Bw3NiFnbPGY0oSgQ08sdfhqSIB2idLbA1rNWTNoYmap jwzKOmk4j2QjnJo4s/Yt8c5m+KBW5V//VUv0vNdsFn6BEfmsv/OsX7hv992/dlE3 rGrv0Ti/Uor9VVoU9F/1fVB6X+e9zTJN+6PJFM3yUeT5vCeXWlbx+PrR6a5lo15L FKsRtTvOc/pp5XngcZGHwTpdqU6FP5e2B1tkXZSBZAhWVycrSRY= =M2mw -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl3XbmsACgkQWrL68XsX K+oNSg//XxPvo1U//jotzysfRvOb5N38O64m2go7LrhaAnVt3yC4mYhfPCJVmxbM caigBW6x3pu7QPrjuov6H1kh9OPgpj+PrvMWv2hnXQvo5rDgmQ8BzzTmLEwlt3CB eyG9MzsnT58gxZmHSkOMfPE8e36SEeLtgggG7/dKon7Ad2vOBHz1tMlYYsKROGiR oY27w1Xo7WIIRGRz5tURTZgz54R7jDeNUMx1aXowrYFrCPrmwLxqNYhJYU8wFEAl 1W6j7Xnde8zrLDyUw9jphHT+bug3c8RRStI36AzwjqpLksfmmFPyqVHfGlY+8HMf LVH9jDRqJqnM2uGqd1iSeUWKpd8acQzpovEhxb2omiR5w66jLU/CRLpq7H4/Es5M hzynUgmCDUvMWlwsFtcn1/meC6fzKZL2YMFG0WC+MM3pWGzsqSoZKXpqx9XKJY8b 31K9Jo2MiR7ZcCewtCMtGqeZBalQG5mXpFRdqaDjqzyNIsT2RZZMAy4OsgMmOc5U sEh9oJIKGugjGVUPW02vOIjXm9lZ+NQR9LsNrWpKv8MU2SxqVeYX9votMWFmAv2G Dwm1wZc8n3Cbeqn5DXkWzhWOUp9kA+DqtkRt45b+HzFv8N0NmlxUR768CTg4HoGN 1PGaDDmq8Jf1UtM7Wh3dcfxuhHaVAKYjZiJcRN2KA9jlUVNYoP8= =bL2q -----END PGP SIGNATURE----- --BjPurnKaIfJMpZjEVsGDp56eG9DI10qGj-- From nobody Thu Nov 21 23:55:50 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB831200B5 for ; Thu, 21 Nov 2019 23:55:48 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 3ALXlZXBOXbC for ; Thu, 21 Nov 2019 23:55:47 -0800 (PST) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 D3AE012000F for ; Thu, 21 Nov 2019 23:55:46 -0800 (PST) Received: by mail-il1-x129.google.com with SMTP id o18so5962425ils.12 for ; Thu, 21 Nov 2019 23:55:46 -0800 (PST) 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=6FN5BBhol2EGpxBsNryWOnXAHyiOv2yXj1QOp/TXb/w=; b=JPvw0AerKrcsYTaNWWjh7Gzs8Y8d9ZBwHNxRfGBkfAtzdFyuG725Y+cv1uSL3uEeHZ InGGTAfRCcjwPyIZGSJjD53v1ceAbQprMBc5XLeAsIj0oNkppOHo8uO1n1oMDnem1kHA eZOZAfOGvGs/wqNluhnEFUWn4eI/A0ceo7TiaYgt5Q4zHXXx9pqBuJ2H/90XN3PjXbvV 6DnYJoiDuXuI7ZRvxbcpLBrMBhoHZk7b3BLHt+vKyyeut5XueXV7Eon/6TWjS2JVECT/ AGLrQnH/M4MbR74AR5gRRM0awV86LPaX8uuWc0JnsVOJLncm3bhIShOJIFvjRvzRqnxj QSLQ== 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=6FN5BBhol2EGpxBsNryWOnXAHyiOv2yXj1QOp/TXb/w=; b=UF8OgcpotHiYmKf8dqw0Vgr0jAak451b2iiZwARMr60OGPn5ADPmqDuqLIlTV2Rf2G NVcJ6AF5F1scoZ16p7basXntUJuaTrUcQ1XgtN8SYYxdidWjCePKud6GecN7OkvUbxBM Flt0T5ZCrR7/Eaq4KQr8NYw8KA5BFVrcj3odwege9W3h4UR4DC24t9vYPkDVRSWf5hs8 IwG8eQaJIT5qU8sNh1ZMrsdqP5T7paFGp9sMJeJHs1qeKKwOoTW5o5PGyX8ItgUsNNqz dXXG7N7jgSLBnaGpFucY/WcayRUc4nYNZsL7WcQTnsReyavQppE7J/47rgmP5IX6mNZI PXQg== X-Gm-Message-State: APjAAAXTQN9jc9zFtl8iCjUFlHKYwwENVzlooKrQXm976W9+Q03e7h5s LXpu2ynvBOpn+v+yOJ4qE5/Mj5U66wHNeShGGuVKkA== X-Google-Smtp-Source: APXvYqz7lZw5fpb1gQvyfXHMVmwn0JJvwcK4cPy6T5VX7g+b61B8kB9SXTiB5/QGGyvZZrgiuSLeefXzb2R7qpfIhXc= X-Received: by 2002:a92:3c13:: with SMTP id j19mr7903941ila.245.1574409346098; Thu, 21 Nov 2019 23:55:46 -0800 (PST) MIME-Version: 1.0 References: <96B5CFA4-DF05-4BCF-A4FB-340DE2C890D2@sn3rd.com> <000001d5a0e5$2bac1330$83043990$@gmx.net> In-Reply-To: <000001d5a0e5$2bac1330$83043990$@gmx.net> From: Eric Rescorla Date: Thu, 21 Nov 2019 23:55:08 -0800 Message-ID: To: Hannes Tschofenig Cc: Sean Turner , TLS List Content-Type: multipart/alternative; boundary="000000000000ce44340597eabd73" Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-semistatic-dh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 07:55:48 -0000 --000000000000ce44340597eabd73 Content-Type: text/plain; charset="UTF-8" +1 On Thu, Nov 21, 2019 at 7:30 PM wrote: > I am in favor of adopting this document as a starting point for further > work. It fits nicely into the work on cTLS > > -----Original Message----- > From: TLS On Behalf Of Sean Turner > Sent: Friday, November 22, 2019 6:29 AM > To: TLS List > Subject: [TLS] Adoption call for draft-rescorla-tls-semistatic-dh > > At IETF 106 there was support for adoption of "Semi-Static Diffie-Hellman > Key Establishment" for TLS 1.3 [0] as a WG item. To confirm this on the > list: if you believe that the TLS WG should not adopt this as a WG item, > then please let the chairs know by posting a message to the TLS list by > 2359 > UTC 13 December 2019 (and say why). > > NOTE: > : If the consensus is that this draft should be adopted as a WG item, then > this will necessarily result in a WG rechartering discussions. We would > have gotten to this rechartering discussion anyway now that DTLS 1.3 is > progressing out of the WG. > > Thanks, > Joe and Sean > > [0] https://datatracker.ietf.org/doc/draft-rescorla-tls-semistatic-dh/ > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000ce44340597eabd73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

On Thu, Nov 21, 2019 at 7:30 PM <Hannes.Tschofenig@gmx.net> wrote:
I am in favor of adop= ting this document as a starting point for further
work. It fits nicely into the work on cTLS

-----Original Message-----
From: TLS <tls= -bounces@ietf.org> On Behalf Of Sean Turner
Sent: Friday, November 22, 2019 6:29 AM
To: TLS List <tls@ietf= .org>
Subject: [TLS] Adoption call for draft-rescorla-tls-semistatic-dh

At IETF 106 there was support for adoption of "Semi-Static Diffie-Hell= man
Key Establishment" for TLS 1.3 [0] as a WG item.=C2=A0 To confirm this= on the
list: if you believe that the TLS WG should not adopt this as a WG item, then please let the chairs know by posting a message to the TLS list by 235= 9
UTC 13 December 2019 (and say why).

NOTE:
: If the consensus is that this draft should be adopted as a WG item, then<= br> this will necessarily result in a WG rechartering discussions.=C2=A0 We wou= ld
have gotten to this rechartering discussion anyway now that DTLS 1.3 is
progressing out of the WG.

Thanks,
Joe and Sean

[0] https://datatracker.ietf.org/d= oc/draft-rescorla-tls-semistatic-dh/
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000ce44340597eabd73-- From nobody Fri Nov 22 00:29:01 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF50120143 for ; Fri, 22 Nov 2019 00:29:00 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=cT3cpri3; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=Xb57unvF 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 NaxnYkLzCTzQ for ; Fri, 22 Nov 2019 00:28:58 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D00112003E for ; Fri, 22 Nov 2019 00:28:58 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1574411336; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=88y2YZ95UGwyDaUNFgm848D+Wt3b4NyxQb3jlvVUyQQ=; b=cT3cpri3zMS/rTDwQyvkeoD3EsVBwms+dZuWgnURlklgvDQOmfs5+s3N MVDL0QYwyC5f6gtnUIxrLmpA6RTCBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1574411336; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=88y2YZ95UGwyDaUNFgm848D+Wt3b4NyxQb3jlvVUyQQ=; b=Xb57unvFXqHtY4x2qLpp6Flzxh3jZVamnnhpzIqsNXW/+NTBzeNOWDag kvhq3MA8zc0IkIJhfJEeNqdUrjGFCNVAYqZ17TdxRFux9xlu5NFmnewlCC sED2KfIFB++qDhPD/OVnssQxkcDF/zRq9a1HuMUHaC8CPwQE/FjmkVzutT YPiuLnt+iPSUx1rIJyjvce2LMtvVS2pQPu1cpFZZprcWQj/te8vA3BR7/V 0Ht9NBelRQ2cV4uPyUHwga/sSLxXvP4aID1fMKQur2UtEuPNeK7skO5Tqy JNwOQ3o6jxYUtV5PmkZa94KDQ3ew5IXjVJOB9bfwCn5wHPYQPKUmQw== Received: from fifthhorseman.net (unknown [111.65.38.212]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 73644F9B0; Fri, 22 Nov 2019 03:28:55 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 41EA2204B5; Fri, 22 Nov 2019 16:12:51 +0800 (+08) From: Daniel Kahn Gillmor To: Stephen Farrell , Christian Huitema Cc: "tls\@ietf.org" In-Reply-To: <6636c7da-39ec-ebef-905f-6458ac8c1a56@cs.tcd.ie> References: <7374648a-d684-87be-0807-219bc10793ac@cs.tcd.ie> <18514.1561564689@localhost> <878so9jafi.fsf@fifthhorseman.net> <6636c7da-39ec-ebef-905f-6458ac8c1a56@cs.tcd.ie> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw== Date: Fri, 22 Nov 2019 16:12:50 +0800 Message-ID: <87d0dkib25.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [TLS] publishing ESNIKeys under a .well-known URI... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 08:29:00 -0000 --=-=-= Content-Type: text/plain On Fri 2019-11-22 05:13:13 +0000, Stephen Farrell wrote: > I'm not sure if this draft ought specify behaviour for > such clients, but I can try add text describing the various > cases I guess. (If that text were to stay in, then I'd > guess that it'll make this document too long to include > in the base ESNI/ECHO draft thus taking that option off > the table maybe.) The other option would be to make non-"zone factory" clients explicitly out of scope, and spend a couple sentences describing why. And then note how if you're going to play these games as a non-"zone factory" client you really need to think it through a lot more than this draft does. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTJDm02IAobkioVCed2GBllKa5f+AUCXdeYggAKCRB2GBllKa5f +J8hAP9QLnQcDBCSqPWfIGjSyqHwiVFsZbivKmCG2MU4vRgjKAEAzzb3PVClS7Yp mMzY3SEFkE/JMJbXIAScAlgyVnzhjgI= =qthN -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 22 03:11:01 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B8F12021C for ; Fri, 22 Nov 2019 03:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, UNPARSEABLE_RELAY=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 ccs0XwQDMnnG for ; Fri, 22 Nov 2019 03:10:58 -0800 (PST) Received: from paulo.mayfirst.org (paulo.mayfirst.org [162.247.75.97]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7064312008A for ; Fri, 22 Nov 2019 03:10:58 -0800 (PST) Received: from paulo.mayfirst.org (unknown [127.0.0.1]) by paulo.mayfirst.org (Postfix) with ESMTP id C5C5C3F40; Fri, 22 Nov 2019 06:10:56 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: xxxxx) with ESMTPSA id 940613F3C To: Daniel Kahn Gillmor , Stephen Farrell , Christian Huitema Cc: "tls@ietf.org" References: <7374648a-d684-87be-0807-219bc10793ac@cs.tcd.ie> <18514.1561564689@localhost> <878so9jafi.fsf@fifthhorseman.net> <6636c7da-39ec-ebef-905f-6458ac8c1a56@cs.tcd.ie> <87d0dkib25.fsf@fifthhorseman.net> From: Hans-Christoph Steiner Autocrypt: addr=hans@guardianproject.info; prefer-encrypt=mutual; keydata= mQINBFY1RO0BEAC94s679hO9oxi2h1GF0hN7xCXxeIyJp58rA2QxuMJ/NvMhrfBGVqhkolUb 7IqvHy8n7jvTCCAJOHP6ZAtUUwV20ZpUa2Mfp0/6dbGkvXcXwGlU9ShpBiXnDsKvgRRX5gOO /WeWLe8x8HRcFfcJVXS9pHRw2bxjrbs3zKlf7yBACcSt6ZSgPsqHuUQSUs4Qo0E0/H14uJiD k32qQ1YicVrE1r2pFe9iZpxBMGTwgZyNUEUYDeVfTDubL7Jc1MUpgotNTxbJ3jVxt0uHn20l hNXG6ybaYK3MhIHIEp9Nbd4l6+Y81ZgIQbs4jAbAPcy+qY3GT2uQfbFb2UK8+hnDotGmejgo YuDZGBaAukiELIKxrsNCvaSg5DI/yrH6Vx6ZceHpitrer6yOwZescc5SGud3btU4Iktfw7w+ 5pxmyypUazaltibSd13o56n/aKrQZw098bhqnh9xTbPVK14t4wTdsJKyZmJv8oKCqppEuhTc q8kur0PWOM85NSBl0igSfj8/CR8CbzgasMPNQVVwUA0Ody0s8wO13+WVaLq7y6Xpy9t6jSVv S8KLgmJ/wTJimHb2cctHNBSQEwnJtRyy/o7kKnge6HPzOprjPAlv6okA2XQaLTxyjW1YCRwN GatNAJ2WnJx3m89WGRONN6qQ3RFX59kbyzR1uL6D3Z6ts7bTmwARAQABtDJIYW5zLUNocmlz dG9waCBTdGVpbmVyIDxoYW5zQGd1YXJkaWFucHJvamVjdC5pbmZvPokCfgQTAQoAaAIbAQUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgAIZAQUCVjdjhUMYaHR0cHM6Ly9wZ3AubWl0LmVkdS9w a3MvbG9va3VwP29wPXZpbmRleCZzZWFyY2g9MHhFOUUyOERFQTAwQUE1NTU2AAoJEOnijeoA qlVW/IwP/0Uq8896f4NJPv9m5xKZnpCErXhvGU8b4gwH5EXaw66Z/0Zp56zF+J0rLdQZ9FoL HmShM8ZIEHmbNs/NTxqJ5qR0QDKJl8kJW7P/yfNjYOHtBCxPOS5LcapGtUT9jx7GAPU+oJ7z RC0nF8eot97Ds797n139BSbabZ74j0mfwKdGFxRaZVAfhzOD3tevyxUGMwj3w+zRpSXrDHc+ mZa9oHVE6J632rKMUTyDH/7kjzqN54l+dW29SK2NCfC79jfjDcO+ldbUV0lDz+HcLAiEYY1U ucuGVYgL0s/blCqw8YBmwBFdzYYwL6JXiK0KO+eukEZZl9nAWb0CUtuq/8dqkB5VKE39sBjZ pADf8xknMXJVTN1NlMUv6ZDKgRByL0gWdxmSaLLcjBliieXsDvMDHZnwhVsXeoPB1o6PaNLr Ho6ohf8vUrpVzDt6jwEydKBjJiykoSae4Gb7zgVx2/jvHZG3TrMqwktmPQKc+mS/WQBVMfUm ay3EYuIXRFhh2l4czMxFPWpan0nxV3QSpjPYJFOcKm0fPOLBAfe5WnatO8RGtL/quOdpOhMi rfzZKb0I4CiLGmyUHhewCGcggejqrBNDsip4RE4XwEYbH/VjWs0g5VVodSLUm0aC/98eG+XR 0bV/v0urdHFedFOVbkTBYYYJWNzRxvv2paJVoUzxWn5GuQENBFY1RikBCAC2ZLMA4e7v4nZL 4Fy5X5vfaZ5pGHuh/8i34V4geqbMgWKnTgi2CJkAzglVDkbhpyk/Q8hCj4DdiRMsK4+TpLmp sbCYVGBeoaB/zkhZdjHksymED7V5sUim1BV418JXk19bnrDNFvfyhy8fer8FoDKeT0HJNdab lTt5NJrVFIVmglOZFIF+dSbz+HoH15bbwUDoedM63Q9ChQ5RsPKxiKHbwsYQ6zAJb+f/xLsG RUSzg6q6GPwX0A0P6QMkl2a/OXZhk+LGmzvldg4M0roWr6ohH+4iiBxttId4VACNPjQR7UME c8E6GZTRpviaMTTioXHY2wxkjcD6LmdjZ7Hm7F2NABEBAAGJAiUEGAEKAA8FAlY1RikCGwwF CQlmAYAACgkQ6eKN6gCqVVZbvxAAk1RTjZ017OWt/Tpm7Wa1VprbNPSFmDjzXSjIM2ut7E5B iScJLRy4sl7Fl5GcwS8lWkfIz2n8R7zn0Xj4T91dKZZ4J9m+Mf37cHGBBn5Hp2E6gqoClqbN CNLpWeHtwbLf7p9e513yRZwIdwAC4sHCGSzT6ZpFNhOhTqSj4nllfpbkSSjac5KaeV7oRQXI fE8BvwH02sGM5LpsoifhShrdcoEZe3GjyERbf3oh3cqYnr9pR64DnO8IMc+RL2c+sGPoirVS d/kBCIA8vEABZzpHeoNN4DNu3ykg0d0Knn/2CoMY92w4UGrdDRc++uMOawXtI9aGdtt4AIMy YvHfSO5KtZr+U9sViMhSXiiJ1Ofl46C9nZwjyZ5t5NnwfVh3Am79uhDHrckxJ/2aWOt9KOdY H8QqxovWCCq9esUgV+Q0SXow8zdkBa8lKR2H9xbI4frKULnu29iyIv4CbWOZE8QbjKoBcThA XesRjmVb5bvAYx+t5UMyQKaaH7dVTzvdFiIRM3zm0Hxrpxn3muaGk9WRTzKi+cYlAcT3o2ES mlWXkYGArbRoOtnQ1aXbySkF/+veMptetrZ8nyAZJ5oZmjDJ70EBGHEbEhMhNhYXlua4QIiV HdBRZ93PQnQA5j8JcYkeY8g977F9I/Cjk4xSmEuPZ/rmXci54nqnT4tGKQsdnsW5AQ0EVjVG VQEIAMQWAxQD5XvNeoGOwaT6wA63+R2CY2JWutofvPRdftVyrtp02m8M1gfWevNgiooYpI/4 pJiukC2h1WUyqPVaUdBZC7bM64pSO6LLplel8bASe5gwIIm+zd/0WsjxSmmeJvHwDUzuGp6k kiw2is4b+oiokmgQUZsm0AYkNBjYbsPsBD6b5e8seKidtzdKSmJeZkFw4SqEyxRRbYXtPWub JJQjwDxJMA3xt73wsu08wbshsSESNsT34gxjWWF5EofJrYM2x6jABzhzfbx/tQv7J6z9fBTc e06eanR916OjcDyvEaDRI419Ihlyfp0Lx3zfSy3NP+S0NwALA7pML1h0LbkAEQEAAYkDRAQY AQoADwUCVjVGVQIbAgUJCWYBgAEpCRDp4o3qAKpVVsBdIAQZAQoABgUCVjVGVQAKCRA+F3gX uhub+jcFB/0XRcxwcGMkYiGpTZBt5vo/VlqAv5dBUtG/aNb/Mi4jhXZqWO6SGVpiRHrhlNAd jMWJPB9xvcsxF3GwDJfyIKYJlKAVoArJQDcqyXllqIhmhvWbOFH5Tj/XbZNNbbtvbCXSF+sJ 5l94yI/XGhN+PyQlUaHPOZJparDDuP/WGHe5CkhBLf0zNwf6ingo2qUu2Mi+U/GYhAOIgsz1 sy/8oqLWkMmlNnfYHhNEUTviXiBYd1k9qbCxU7LDvl6+ivbpUiNDn9rhmWz0imQHiheXjuSa H1ytDtxm0V9OxP2SzFrx9cGUV4q24h6ytG1bSE07D96/jSt8xIUfsZUx9BM9XbxhVdYP/jIg tMedxiv6MwVhKbNVhmjaGG/6uYuw+eqQeN1zjmXa1N/TmnEss22hiN9qtsR7QpVcAoo3QtMX YyzeplwMQuEfjCFlGb8sy7IqyoCVnSMVj57zvcQPMzbWbckhpTngYtLqzGPemaGYkoMgS2P8 HRQCQzkR5s3VBDNlpT653lRXo+yVdlJkGk72qlauv4GaRyMASX9f5TNCMl17eXvgyQZvlmge QFWm5UUgxR+J/u+U2yhSJbvkW9d/07zof7D3j+IuNuLXGFszb2916yLSyB7EZATpXFZc9MOj 5wTAf9lvFxo5I69WT999ZtRHVosgtixan2WGhOWjQV5ajCkeVvsBrSP91l8G8bzC5SCO8D5K zBn4SusmgVoK1OVdrNpM9hB5OusRl4ah8+ReC/LaxcFtf/38k73ViKI1+8bD+L7pza5enbLD W95kvIaKmer84FwyD+bfEQo6pvLzxEUBsR30JpmqzkPU8KMFtkbPEIKlQlEbk4vvAN12VDL7 jJsQZIVeH92+X4Wfyf2a7bLufsaNR/YOXLLROeZnzntF7MhS9oO+c8Z/J5py0F0KDRrhCrqb u9lRKRcxpPslTd8DKZ3Qtv64Ij/rPVDzsyHgtcgFd7E6fkKGHeiwz67WjFoLUnf09ry7rua+ yqP9FP9bXSbDaeAq9sGXH7wPTAAwbGSX Organization: Guardian Project Message-ID: Date: Fri, 22 Nov 2019 12:10:51 +0100 MIME-Version: 1.0 In-Reply-To: <87d0dkib25.fsf@fifthhorseman.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Archived-At: Subject: Re: [TLS] publishing ESNIKeys under a .well-known URI... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 11:11:00 -0000 Daniel Kahn Gillmor: > On Fri 2019-11-22 05:13:13 +0000, Stephen Farrell wrote: >> I'm not sure if this draft ought specify behaviour for >> such clients, but I can try add text describing the various >> cases I guess. (If that text were to stay in, then I'd >> guess that it'll make this document too long to include >> in the base ESNI/ECHO draft thus taking that option off >> the table maybe.) > > The other option would be to make non-"zone factory" clients explicitly > out of scope, and spend a couple sentences describing why. And then > note how if you're going to play these games as a non-"zone factory" > client you really need to think it through a lot more than this draft > does. That seems reasonable to me, since this is obviously useful in the zone factory use case, while other strong use cases haven't really arisen yet, from what I've seen. Such a use case could come along though. > At the same time, for $COVER to publish this information potentially > puts $COVER at more risk, right? I think it is also important to note that for the obvious use case, I don't think this adds risk to $COVER. If $COVER is megacdn.com where $HIDDEN is hosted, then megacdn.com assumes no new risk since it is already clear that megacdn.com is hosting $HIDDEN. .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556 From nobody Fri Nov 22 05:05:18 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43662120088 for ; Fri, 22 Nov 2019 05:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mA1Q4X4S8Xdb for ; Fri, 22 Nov 2019 05:05:14 -0800 (PST) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 57B49120043 for ; Fri, 22 Nov 2019 05:05:14 -0800 (PST) Received: by mail-il1-x130.google.com with SMTP id s5so6866082iln.4 for ; Fri, 22 Nov 2019 05:05:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qB7m+5PDEQsgm5D8rR0hauCcExLRCg0Id2JGig7Br6M=; b=qxJ/uXPq+7yAa6UdbEfOlWETTEhIcPweynRu9MgVaFwNr5CF4tjJJ2EJrZYRm4O5Uz SQdYWCmLMuDu7LB3GIsFBwwG2NEUtonNmycYI54/M9dHkgU8L0C5cKdUhS7dVywWWqvs iNL01qz7teWuX8dlzvCq2Ok5M3xYG5dT1sysb+GHkwK8xbTDjIlumB1oeE8PeW36i3nP iuGHl9rCzZOSvGQVsCfc/IWLYBIqzhlTpIOvVZuihIm6JQJd6lEE9dwp+y5Xz1nWTnA4 c4aYRtHzK/3gpEGVCCeGEbRIgIzApS3fXFPW5sva+jLYytLscmJIHCrfzPSfNpC6hPa8 Jxig== 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=qB7m+5PDEQsgm5D8rR0hauCcExLRCg0Id2JGig7Br6M=; b=JI2QsAo2MRgs7WASVcmrL7xFVk9qGFfQro9CqxnropOJyNnnY27YUz1FoqW9dkLgAB wmIoyPTk9hA0OAF4hVj6uOUqfQRluqePmY+cNKy7HuVG8oHpw4Av6c2ad3CfaLXpWuBf tzeFlm0TjYV61z42h+8r4rFclROlqsQS6AG6NmzAw0XvX7HN5SpZr43k+K1z46pM+5oK KtJbghDfyWlVxty3pjZk6Iw9ogYSLwtrZoG+wmCRKSK3jy5N5HlGRkXXOQhQ1OKYuBuo Zruj+fCS6EFUZow79NGzhwb2ZMyu4vgef1iLZlJFywySIGvSN3mmNcI9ASxJaqCbl0ed UI2g== X-Gm-Message-State: APjAAAXbINqf0952ACHgsWpo1p4WEPoHl6Oqg974fl/Y0IcejPAY9XAk EMcjBg3HusBfTHcGPSrMyijjguwbNCiE+5KhggPhGw== X-Google-Smtp-Source: APXvYqxZreeF4femoms9+J6hbXVPsI7hw7noG4VKKIpvo814A8QI3YdkooyQm1f5G+PODAYMQkPqSdVKafCYSQyMyZk= X-Received: by 2002:a92:9adb:: with SMTP id c88mr16032741ill.193.1574427913161; Fri, 22 Nov 2019 05:05:13 -0800 (PST) MIME-Version: 1.0 References: <7374648a-d684-87be-0807-219bc10793ac@cs.tcd.ie> <18514.1561564689@localhost> <878so9jafi.fsf@fifthhorseman.net> In-Reply-To: <878so9jafi.fsf@fifthhorseman.net> From: Ben Schwartz Date: Fri, 22 Nov 2019 21:05:01 +0800 Message-ID: To: Daniel Kahn Gillmor Cc: Stephen Farrell , Christian Huitema , "tls@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000087c51b0597ef1040" Archived-At: Subject: Re: [TLS] publishing ESNIKeys under a .well-known URI... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 13:05:16 -0000 --00000000000087c51b0597ef1040 Content-Type: multipart/alternative; boundary="0000000000007d7c560597ef10b1" --0000000000007d7c560597ef10b1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Nov 22, 2019, 3:29 AM Daniel Kahn Gillmor wrote: > On Wed 2019-07-03 16:01:21 +0100, Stephen Farrell wrote: > > It doesn't take much to encourage me so I just > > pushed out that idea in I-D form:-) [1] > [=E2=80=A6] > > [1] https://tools.ietf.org/html/draft-farrell-tls-wkesni-00 > > Thanks for this (and for the -01 update for the draft). I like this > work, and i think we should pursue it in the WG. > > A couple notes/questions: > > - Clients might use this, not just "zone factories". For instance, > consider a client with limited access to the DNS that makes an > initial direct connection to the hidden host, leaking SNI. If, in > that connection, it also fetches this record, it could use that to > bootstrap future connections to the host, right? > > The draft currently contemplates this briefly for followup queries > for some clients, but it doesn't go into it in more detail. Hopefully this use case is covered by the "esniconfig" Alt-Svc parameter ( https://tools.ietf.org/html/draft-ietf-dnsop-svcb-httpssvc-01#section-8). > - Why is it hosted on the cover server, instead of on the hidden > server? is that just so that the zone factory doesn't leak $HIDDEN > to the network? > > Surely on a zone factory update, the zone factory already knows the > eSNI for $HIDDEN so it could make the request with eSNI to > https://$HIDDEN/.well-known/esni/$HIDDEN.json rather than to > https://$COVER/.well-known/esni/$HIDDEN.json > > At the same time, for $COVER to publish this information potentially > puts $COVER at more risk, right? And, a $COVER could *claim* to be a > cover for $HIDDEN without approval of the $HIDDEN site by publishing > these records; if anyone believes that claim, it could cause traffic > to be re-routed through the ersatz $COVER. If it's going to be > hosted at $COVER and not $HIDDEN, we should be explicit about what > defends against such an attack. > > There could be an "obvious" reason for the choice of hosting it at > $COVER instead of at $HIDDEN, but it should be spelled out in the > draft. > > - If this is treated as a separate/independent source of authority > about ESNI data for a host from the DNS (e.g. in the client examples > contemplated in my first point above, not just the "zone factory"), > then the draft probably needs some text discussing what to do when > discovering a discrepancy between what's in the DNS and what's found > at .well-known. > > Regards, > > --dkg > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000007d7c560597ef10b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Nov 22, 2019, 3:29 AM Daniel Kahn Gillmor <= dkg@fifthhorseman.net> wrot= e:
On Wed 2019-07-03 16:01:21 +0100= , Stephen Farrell wrote:
> It doesn't take much to encourage me so I just
> pushed out that idea in I-D form:-) [1]
=C2=A0[=E2=80=A6]
> [1] https://tools.ietf.org/ht= ml/draft-farrell-tls-wkesni-00

Thanks for this (and for the -01 update for the draft).=C2=A0 I like this work, and i think we should pursue it in the WG.

A couple notes/questions:

=C2=A0- Clients might use this, not just "zone factories".=C2=A0 = For instance,
=C2=A0 =C2=A0consider a client with limited access to the DNS that makes an=
=C2=A0 =C2=A0initial direct connection to the hidden host, leaking SNI.=C2= =A0 If, in
=C2=A0 =C2=A0that connection, it also fetches this record, it could use tha= t to
=C2=A0 =C2=A0bootstrap future connections to the host, right?

=C2=A0 =C2=A0The draft currently contemplates this briefly for followup que= ries
=C2=A0 =C2=A0for some clients, but it doesn't go into it in more detail= .

Hop= efully this use case is covered by the "esniconfig" Alt-Svc param= eter (https://tools.ietf.org/html/draft-ietf-dnsop-svcb-httpssvc-0= 1#section-8).

=

=C2=A0- Why is it hosted on the cover server, instead of on the hidden
=C2=A0 =C2=A0server?=C2=A0 is that just so that the zone factory doesn'= t leak $HIDDEN
=C2=A0 =C2=A0to the network?

=C2=A0 =C2=A0Surely on a zone factory update, the zone factory already know= s the
=C2=A0 =C2=A0eSNI for $HIDDEN so it could make the request with eSNI to
=C2=A0 =C2=A0https://$HIDDEN/.well-known/esni/$HIDDEN.json rather than to =C2=A0 =C2=A0https://$COVER/.well-known/esni/$HIDDEN.json

=C2=A0 =C2=A0At the same time, for $COVER to publish this information poten= tially
=C2=A0 =C2=A0puts $COVER at more risk, right?=C2=A0 And, a $COVER could *cl= aim* to be a
=C2=A0 =C2=A0cover for $HIDDEN without approval of the $HIDDEN site by publ= ishing
=C2=A0 =C2=A0these records; if anyone believes that claim, it could cause t= raffic
=C2=A0 =C2=A0to be re-routed through the ersatz $COVER.=C2=A0 If it's g= oing to be
=C2=A0 =C2=A0hosted at $COVER and not $HIDDEN, we should be explicit about = what
=C2=A0 =C2=A0defends against such an attack.

=C2=A0 =C2=A0There could be an "obvious" reason for the choice of= hosting it at
=C2=A0 =C2=A0$COVER instead of at $HIDDEN, but it should be spelled out in = the
=C2=A0 =C2=A0draft.

=C2=A0- If this is treated as a separate/independent source of authority =C2=A0 =C2=A0about ESNI data for a host from the DNS (e.g. in the client ex= amples
=C2=A0 =C2=A0contemplated in my first point above, not just the "zone = factory"),
=C2=A0 =C2=A0then the draft probably needs some text discussing what to do = when
=C2=A0 =C2=A0discovering a discrepancy between what's in the DNS and wh= at's found
=C2=A0 =C2=A0at .well-known.

Regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --dkg
_______________________________________________
TLS mailing list
TLS@ie= tf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000007d7c560597ef10b1-- --00000000000087c51b0597ef1040 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMb5MwaN/thbS6tcoSMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDgxMDA4MjIyMVoXDTIwMDIw NjA4MjIyMVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCapo7ARc1spX97SqdC5FrntcF1TsMY92BYdzbflXSKxq0yT835 3LNJtJ/J4lZC5QSgloRVy9U70CWQVLQUY+kXzFrEZkpgnHAtnlqZITjGGCj7+RAjWXbRHdOtvA/t EJKQJjEsuggE8qjMH2FoThWpOoAFfvLSw8aSir96C2tA8MV59tyI8ewdRBWKvQT6QTLPpPFmKJPJ H1idNM5tnwsWzADF6Xmz2tdLu4Nec4bGyzwHv4jGWrMfW6i5XO3cxFDLluvf7J6A2m+85dRtTC5q 2eqFRCpqqDsHcxsd8OFxpEe9ZhRw1XcMPjZmqHEPpJToDt9ReYetEffXx5DNqIcHAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFE77YQLCDddBAx5p+gBVO6KLah3VMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAW/09trVYeHUY5xMK3 1EuuFQyc7RaPOn+3qWJuDt4DVjNJl0uH27JsA30H70YGSPgNLo/KtC/1ejCAF2SjJrL+Qb93j4Cq BLI0djN/I9AHm7BVy4l+evwS6/7b8xwhKZSt+b2FuMSdpYRfxavlFKYo+WILW6gGx15o+KDRPusJ mo2s2mZDRTUfZ9e87SLTOUe/APBMIeKd+2Z9nnnBh0+d4LCn3tA4vmD1A/pIubUYaaTlLeZIQhpa D41mXEZUHdUVnGaIdPzJKNSkCeIUztyVBUJyYk3ROz9bCBjsHcUy2iqwuLGLaPI3bWjdwvxZ4kG4 dhjPuHq6t95sxpJ1F1X/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMb5MwaN/t hbS6tcoSMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBpV/JqSJXpmZGFqZTykJY4 PFnvxOw7bGuUCpch5UTdkTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTExMjIxMzA1MTNaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAS0eSF/HyJtdXFrycPjzYFA/iszketVHtOSAQ1Ei5 OHqK0U9bDclDBkYQP8/gyKlbNIKU8FVk1XMQG0DX6hS2bubnkW3uLKlfBJhEdUvGlD6yLZ30DPAD Pk0G3t94kmosyzGO593DKdLEJVTiYrJXSH7j4aXSly8DewOOPRnXLTj55LIpJ4FOW/oRv3/ehSbu pD2K/JRJGUgYaY5Of+NpfHA22eacR2FkXzAiocsE1sAUe7OvUFoRNIUptLJbv27Uh1O81UiDs7ht vo62/u+A0u5f4RTGo4PEZoW1ryEr/dc4UBzopxRMLOO6g+Z2p247ys64i8/81UpRz89Sh3VTvA== --00000000000087c51b0597ef1040-- From nobody Fri Nov 22 08:01:49 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5FC1208C8 for ; Fri, 22 Nov 2019 08:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vu5r71bF00Ip for ; Fri, 22 Nov 2019 08:01:45 -0800 (PST) Received: from mta.openssl.org (xmpp.openssl.org [IPv6:2001:608:c00:180::1:e6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D938120018 for ; Fri, 22 Nov 2019 08:01:44 -0800 (PST) Received: from [10.3.10.6] (ip-50-84-52-196.southampton.uk.amsterdamresidential.com [196.52.84.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id 4E684E4ECC for ; Fri, 22 Nov 2019 16:01:41 +0000 (UTC) To: tls@ietf.org References: <4431e115-64ff-b660-87bb-b8bf3aa4ea15@openssl.org> <2D5349E3-D9FE-44B6-8A40-1F1AE1863A46@akamai.com> <20191120045843.GU20609@akamai.com> <7c4070ef-5ce9-9700-2e88-724d452096de@openssl.org> From: Matt Caswell Message-ID: <10fbb478-df04-de9e-074d-ef89a42c0259@openssl.org> Date: Fri, 22 Nov 2019 16:01:40 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <7c4070ef-5ce9-9700-2e88-724d452096de@openssl.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Is Ed25519/Ed448 ok for use in DTLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 16:01:47 -0000 On 21/11/2019 08:59, Matt Caswell wrote: > If you take the line that "anything specified for TLSv1.2 is implicitly > ok for DTLSv1.2 unless stated otherwise", then I at least think an RFC > should have a minimal nod towards DTLS. At least to give the message > that "yes, we have considered this in a DTLS setting and its fine". As > you state above there are exceptions, so we do need to consider this on > a case-by-case basis. In the case of RFC8422, as a minimum I would have > expected that to be in the form of a sentence saying that those entries > should have DTLS-OK against them in section 9 - especially as the > following paragraph *does* say this for the "Intrinsic" HashAlgorithm > registry entry (rather implying by omission that this doesn't hold for > ed25519/ed448). Is the correct way ahead with this to raise it as an erratum on the RFC? I am still not entirely convinced that its not just an error in the registry. But IMO *somewhere* between those two there is an error. Matt From nobody Fri Nov 22 11:18:56 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1343120901 for ; Fri, 22 Nov 2019 11:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jg9mOIFiXISh for ; Fri, 22 Nov 2019 11:18:53 -0800 (PST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9DCE1208B8 for ; Fri, 22 Nov 2019 11:18:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574450332; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MqyPUHMunD5ZWLftfZMLgfXr2bb2J23qYOGrUpjb5UQ=; b=RL6sIW5U8d2qIz/ifJ+AmrMGpV9I7U2BkOJbD+M2XIABZCpLQHfPtz1MRvb/5+m4dlW81h SPwEA2WzHc4StGJP81bNICdq7/1UlN07E+MQ/uxm0mvYfRcP0mKGkwJTy4fPM1qhk0r6kT +Ln/jxqmgyCteN7jySaa5eAsqiujnoY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-420-s25zVshxMOKSpt0Uw5tyrA-1; Fri, 22 Nov 2019 14:18:51 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4503E477 for ; Fri, 22 Nov 2019 19:18:50 +0000 (UTC) Received: from localhost (unknown [10.43.21.210]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E3E9861F58 for ; Fri, 22 Nov 2019 19:18:49 +0000 (UTC) From: Hubert Kario To: Date: Fri, 22 Nov 2019 20:18:47 +0100 MIME-Version: 1.0 Message-ID: In-Reply-To: References: <508EEDF7-73D2-4BE6-AFBA-710E5A5AB41F@sn3rd.com> <315F2BCF-11E0-4FBD-8420-865F29A66AD1@akamai.com> Organization: Red Hat User-Agent: Trojita/0.7; Qt/5.12.5; xcb; Linux; Fedora release 30 (Thirty) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-MC-Unique: s25zVshxMOKSpt0Uw5tyrA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-md5-sha1-deprecate X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 19:18:56 -0000 On Friday, 22 November 2019 03:25:24 CET, David Benjamin wrote: > On Fri, Nov 22, 2019 at 8:35 AM Salz, Rich wrote: > >>> ... >> SHA-1 signature hashes in TLS 1.2" draft available >> https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/. >> Please review the document and send your comments to the list by 2359 UT= C >> on 13 December 2019. >>=20 >> I just re-read this. Looks good. Perhaps a sentence of rationale in ... > > To that end, the combination of client advice in sections 2 and 4 is a bi= t > odd. Section 2 uses SHOULD NOT include MD5 and SHA-1, but section 4 says > the client MUST NOT accept the MD5 SHA-1, even if it included it. Why wou= ld > the client include it in that case? It seems the two should either both b= e > MUST NOT or both be SHOULD NOT. because it also influences certificate selection, and getting a certificate signed with SHA-1 isn't an automatically disqualifying property? (it may be an intermediate CA that's not used, it may be an explicitly=20 trusted certificate, etc.) > I think client-sent alerts in section 4 are also wrong. handshake_failure > means the sender was unable to negotiate parameters, and > insufficient_security is a variant of handshake_failure. This is the clie= nt > reacting to the server sending something inconsistent with the ClientHell= o, > so it should be illegal_parameter. In the context of ServerKeyExchange > signatures, handshake_failure or insufficient_security would be sent by t= he > *server* if the *client* only advertised MD5 and SHA-1. well, it depends if the SHA-1 was advertised by client or not if it was advertised (because of certificates, see above), then handshake_failure is correct; if it wasn't advertised but the signature_algorithms were included, then yes, client should abort with illegal_parameter --=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic From nobody Fri Nov 22 11:30:05 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557F11208C5 for ; Fri, 22 Nov 2019 11:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ofj2Gxoixgn2 for ; Fri, 22 Nov 2019 11:30:02 -0800 (PST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6930A1208C3 for ; Fri, 22 Nov 2019 11:30:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574451000; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cXts81oHukPccgg9v4S8B83H7TBDHkrCHpA/7k79L+4=; b=boNRKNrCe5PGdRq/gPboCwOZR0d2UThaochhvKJNc92M6oa91nZh1V1i7lODMaMQVbc3nv GYOx+US/yyz9bLlvq5FhUkVDT6MEdjrDdLy/vZEdBf+XQX7hMfHaw618SEfMtrOdE98NOH r+5X0AusfN9mDvaAXQqCUu0LW6HrlZc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-270-gIcRTu1-M7unZVS9NbxtBQ-1; Fri, 22 Nov 2019 14:29:58 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D1CFF801E5D for ; Fri, 22 Nov 2019 19:29:57 +0000 (UTC) Received: from localhost (unknown [10.43.21.210]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7870D60925 for ; Fri, 22 Nov 2019 19:29:57 +0000 (UTC) From: Hubert Kario To: Date: Fri, 22 Nov 2019 20:29:55 +0100 MIME-Version: 1.0 Message-ID: <519b9145-2f4e-4118-b33e-3b57696f8ec7@redhat.com> In-Reply-To: <508EEDF7-73D2-4BE6-AFBA-710E5A5AB41F@sn3rd.com> References: <508EEDF7-73D2-4BE6-AFBA-710E5A5AB41F@sn3rd.com> Organization: Red Hat User-Agent: Trojita/0.7; Qt/5.12.5; xcb; Linux; Fedora release 30 (Thirty) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-MC-Unique: gIcRTu1-M7unZVS9NbxtBQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-md5-sha1-deprecate X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2019 19:30:04 -0000 On Thursday, 21 November 2019 23:41:36 CET, Sean Turner wrote: > All, > > This is the working group last call for the "Deprecating MD5=20 > and SHA-1 signature hashes in TLS 1.2" draft available=20 > https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/.=20 > Please review the document and send your comments to the list=20 > by 2359 UTC on 13 December 2019. > > Note the the GH repo for this draft can be found at: > https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate > > Cheers, > > Joe, Chris, and Sean Proposed two PRs to fix the two minor things raised on the ML: https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/2 https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/3 --=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic From nobody Sat Nov 23 05:40:16 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06DA1200D8 for ; Sat, 23 Nov 2019 05:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_5E4rBGP_fV for ; Sat, 23 Nov 2019 05:40:12 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528881200A1 for ; Sat, 23 Nov 2019 05:40:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 4118F237D3 for ; Sat, 23 Nov 2019 15:40:08 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id wF1gXKhi9Tu0 for ; Sat, 23 Nov 2019 15:40:07 +0200 (EET) Received: from LK-Perkele-VII (87-100-246-37.bb.dnainternet.fi [87.100.246.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 87B552308 for ; Sat, 23 Nov 2019 15:40:06 +0200 (EET) Date: Sat, 23 Nov 2019 15:40:05 +0200 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20191123134005.GA1224585@LK-Perkele-VII> References: <508EEDF7-73D2-4BE6-AFBA-710E5A5AB41F@sn3rd.com> <315F2BCF-11E0-4FBD-8420-865F29A66AD1@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-md5-sha1-deprecate X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2019 13:40:15 -0000 On Fri, Nov 22, 2019 at 08:18:47PM +0100, Hubert Kario wrote: > On Friday, 22 November 2019 03:25:24 CET, David Benjamin wrote: > > On Fri, Nov 22, 2019 at 8:35 AM Salz, Rich wrote: > > > > > > ... > > > SHA-1 signature hashes in TLS 1.2" draft available > > > https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/. > > > Please review the document and send your comments to the list by 2359 UTC > > > on 13 December 2019. > > > > > > I just re-read this. Looks good. Perhaps a sentence of rationale in ... > > > > To that end, the combination of client advice in sections 2 and 4 is a bit > > odd. Section 2 uses SHOULD NOT include MD5 and SHA-1, but section 4 says > > the client MUST NOT accept the MD5 SHA-1, even if it included it. Why would > > the client include it in that case? It seems the two should either both be > > MUST NOT or both be SHOULD NOT. > > because it also influences certificate selection, and getting a certificate > signed with SHA-1 isn't an automatically disqualifying property? > (it may be an intermediate CA that's not used, it may be an explicitly > trusted > certificate, etc.) If you don't want SHA-1 exchange signatures, you darn sure do not want actual SHA-1 certificates that are not trust anchors anyway. And because TLS 1.2 does not have separate lists for exchange signatures and certificate signatures, the client needs to withdraw advertisment for both in order to not send a misleading offer. And I expect that in practice, not sending SHA-1 in signature_algorithms would cause very little breakage on top of what is already broken due to using SHA-1 exchange signatures. So I think both should be MUST NOT. -Ilari From nobody Sat Nov 23 08:32:44 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9EA12081A for ; Sat, 23 Nov 2019 08:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jN4ZS9fSls9r for ; Sat, 23 Nov 2019 08:32:40 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1747120041 for ; Sat, 23 Nov 2019 08:32:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.69,234,1571695200"; d="scan'208";a="413180533" Received: from 89-156-101-160.rev.numericable.fr (HELO [192.168.0.63]) ([89.156.101.160]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Nov 2019 17:32:38 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Karthik Bhargavan In-Reply-To: <20191123134005.GA1224585@LK-Perkele-VII> Date: Sat, 23 Nov 2019 17:32:36 +0100 Cc: tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <508EEDF7-73D2-4BE6-AFBA-710E5A5AB41F@sn3rd.com> <315F2BCF-11E0-4FBD-8420-865F29A66AD1@akamai.com> <20191123134005.GA1224585@LK-Perkele-VII> To: Ilari Liusvaara X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-md5-sha1-deprecate X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2019 16:32:43 -0000 This is a bit of a shameless plug, but I think it is important to cite = papers that show that the use of weak hash functions for TLS signatures = is actually exploitable. As far as I know, the last round of deprecating MD5 in TLS signatures = was triggered by the SLOTH attack: https://www.mitls.org/pages/attacks/SLOTH The associated paper explains how weak hash functions can allow an = attacker to break protocols like TLS, SSH, etc. https://www.mitls.org/downloads/transcript-collisions.pdf This probably deserves to be added to the references of this draft. @inproceedings{BhargavanL16, author =3D {Karthikeyan Bhargavan and Gaetan Leurent}, title =3D {Transcript Collision Attacks: Breaking Authentication = in TLS, IKE, and SSH}, booktitle =3D {Proceedings of the {ISOC} Network and Distributed = System Security Symposium ({NDSS} '16)}, month =3D {Feb}, year =3D {2016}, url =3D { http://www.mitls.org/downloads/transcript-collisions.pdf } } Best regards, Karthik > On 23 Nov 2019, at 14:40, Ilari Liusvaara = wrote: >=20 > On Fri, Nov 22, 2019 at 08:18:47PM +0100, Hubert Kario wrote: >> On Friday, 22 November 2019 03:25:24 CET, David Benjamin wrote: >>> On Fri, Nov 22, 2019 at 8:35 AM Salz, Rich wrote: >>>=20 >>>>> ... >>>> SHA-1 signature hashes in TLS 1.2" draft available >>>> = https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/. >>>> Please review the document and send your comments to the list by = 2359 UTC >>>> on 13 December 2019. >>>>=20 >>>> I just re-read this. Looks good. Perhaps a sentence of rationale = in ... >>>=20 >>> To that end, the combination of client advice in sections 2 and 4 is = a bit >>> odd. Section 2 uses SHOULD NOT include MD5 and SHA-1, but section 4 = says >>> the client MUST NOT accept the MD5 SHA-1, even if it included it. = Why would >>> the client include it in that case? It seems the two should either = both be >>> MUST NOT or both be SHOULD NOT. >>=20 >> because it also influences certificate selection, and getting a = certificate >> signed with SHA-1 isn't an automatically disqualifying property? >> (it may be an intermediate CA that's not used, it may be an = explicitly >> trusted >> certificate, etc.) >=20 > If you don't want SHA-1 exchange signatures, you darn sure do not want > actual SHA-1 certificates that are not trust anchors anyway. And = because > TLS 1.2 does not have separate lists for exchange signatures and > certificate signatures, the client needs to withdraw advertisment for > both in order to not send a misleading offer. >=20 > And I expect that in practice, not sending SHA-1 in > signature_algorithms would cause very little breakage on top of what > is already broken due to using SHA-1 exchange signatures. >=20 >=20 > So I think both should be MUST NOT. >=20 >=20 >=20 > -Ilari >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sat Nov 23 16:45:21 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EC4120033 for ; Sat, 23 Nov 2019 16:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=XF7KpF4O; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YN7uKHQI 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 F5CkFICs2NCh for ; Sat, 23 Nov 2019 16:45:16 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE513120013 for ; Sat, 23 Nov 2019 16:45:15 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 28140229C5 for ; Sat, 23 Nov 2019 19:45:15 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 23 Nov 2019 19:45:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=RaJFw7Vg4p6cLrjsJH5twjNyrwDA6pNDA3XmCShBZLs=; b=XF7KpF4O WcFhNYP4jXULQPap2aAjfs4YXxQXovcCae5bRQMtdqaygkisBU6Al2z52dh/U6M6 y0myLha9X5Tf07zfhcRjX+TabJrxuZcIrje58c+9JehFJ2GdUuGhptL7GYISEkXl 0n4ODiiBJlLSAz7DWi7DqUaybpON5+pJth3BSZG+6qKeM9CMat4sd9JGu65vuaVs gc7lTyacBZ+uMDhN2TT9UFY8yosQc3XoXiE4ELaM1vA7juSHSut42psOeWV/NsLU BaDXuUEaq6OqpGGbwsKk7OQf9EYhWRyjF9uZNigIq4cfx0MyDxpUu82KGUIUSJff /LP9XXbulFHJBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=RaJFw7Vg4p6cLrjsJH5twjNyrwDA6 pNDA3XmCShBZLs=; b=YN7uKHQI2ooitx8aZoUo9xHGEY4TkRZS6WqSxGNM9LCKl 17m1jLFmBB1PxFnIq/9KGQmio6Ifvp4Tkul3i7FqBmrqrIbBnRBd67MvsCAAXIDs srkltT/sIXBIb1ONONcELOyytGTqoj+vWxKPjuhNHOFx4yYydjjJrVOjgKmeaouF U9pguEwgAUNmE+Q3Z4dEvRu0drhtNNrVoyz8eAGZIpXGtX3w2WXp01Ilg9i1lLKJ GSYgCJZcJaP8u4IIR8ECu7pw3RMKLGLblC08tOiM54stv9gJTtkTOlGeP6MtBE72 qr0XutirhewEesx6H/IPbhYQF5vhGLIQjONf+dnCQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudehjedgvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpefiihhthhhusgcupfhothhifhhitggrthhiohhnshcuoeguohgpnhhothgp rhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmne cukfhppeeghedrjeelrdduudefrdduieehnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [45.79.113.165]) by mail.messagingengine.com (Postfix) with ESMTPA id DF9E28005A for ; Sat, 23 Nov 2019 19:45:13 -0500 (EST) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id D3E839E308 for ; Sun, 24 Nov 2019 00:45:12 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============3910838504747949019==" MIME-Version: 1.0 From: Github Notifications To: tls@ietf.org Message-Id: <20191124004512.D3E839E308@cloud.mnot.net> Date: Sun, 24 Nov 2019 00:45:12 +0000 (UTC) Archived-At: Subject: [TLS] Weekly github digest (TLS Working Group Drafts) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2019 00:45:19 -0000 --===============3910838504747949019== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * tlswg/draft-ietf-tls-esni (+0/-3/=F0=9F=92=AC4) 2 issues received 4 new comments: - #188 "HKDF-Extract(0, Z)" (3 by chris-wood, ekr, sayrer) https://github.com/tlswg/draft-ietf-tls-esni/issues/188=20 - #149 Replay attack and timestamp (1 by huitema) https://github.com/tlswg/draft-ietf-tls-esni/issues/149 [needs WG discu= ssion]=20 3 issues closed: - Replay attack and timestamp https://github.com/tlswg/draft-ietf-tls-esn= i/issues/149 [needs WG discussion]=20 - How to parse esni_retry_request generically? https://github.com/tlswg/d= raft-ietf-tls-esni/issues/192=20 - "HKDF-Extract(0, Z)" https://github.com/tlswg/draft-ietf-tls-esni/issue= s/188=20 * tlswg/draft-ietf-tls-external-psk-importer (+1/-0/=F0=9F=92=AC0) 1 issues created: - Please be clearer about the PSK ID (by martinthomson) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/23= =20 * tlswg/dtls13-spec (+0/-2/=F0=9F=92=AC0) 2 issues closed: - Records from different connections in the same datagram https://github.= com/tlswg/dtls13-spec/issues/110 [pr-exists]=20 - Omitting length https://github.com/tlswg/dtls13-spec/issues/108 [pr-exi= sts]=20 * tlswg/tls-subcerts (+2/-2/=F0=9F=92=AC1) 2 issues created: - Add language that enables an application profile to override the maximu= m DC lifetime (by grittygrease) https://github.com/tlswg/tls-subcerts/issues/44=20 - Add support for advertising supported signature schemes (by grittygreas= e) https://github.com/tlswg/tls-subcerts/issues/43=20 1 issues received 1 new comments: - #41 Assign codepoint for delegated_credentials extension (1 by seanturn= er) https://github.com/tlswg/tls-subcerts/issues/41=20 2 issues closed: - Security Considerations: network layer https://github.com/tlswg/tls-sub= certs/issues/42=20 - Add language that enables an application profile to override the maximu= m DC lifetime https://github.com/tlswg/tls-subcerts/issues/44=20 * tlswg/tls-exported-authenticator (+1/-0/=F0=9F=92=AC0) 1 issues created: - Secdir review final issue (by grittygrease) https://github.com/tlswg/tls-exported-authenticator/issues/54=20 Pull requests ------------- * tlswg/draft-ietf-tls-esni (+0/-2/=F0=9F=92=AC2) 2 pull requests received 2 new comments: - #200 Advertise multiple ESNIConfigs as a unit (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/pull/200=20 - #197 Key schedule injection proposal. (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/pull/197=20 2 pull requests merged: - Add a length prefix to ESNIConfig contents. https://github.com/tlswg/draft-ietf-tls-esni/pull/198=20 - Advertise multiple ESNIConfigs as a unit https://github.com/tlswg/draft-ietf-tls-esni/pull/200=20 * tlswg/certificate-compression (+3/-3/=F0=9F=92=AC0) 3 pull requests submitted: - Add Reference column to IANA registry (by ghedo) https://github.com/tlswg/certificate-compression/pull/29=20 - addressing Ben's final comments (by seanturner) https://github.com/tlswg/certificate-compression/pull/28=20 - rfc8478bis (by seanturner) https://github.com/tlswg/certificate-compression/pull/27=20 3 pull requests merged: - Add Reference column to IANA registry https://github.com/tlswg/certificate-compression/pull/29=20 - addressing Ben's final comments https://github.com/tlswg/certificate-compression/pull/28=20 - rfc8478bis https://github.com/tlswg/certificate-compression/pull/27=20 * tlswg/draft-ietf-tls-external-psk-importer (+1/-1/=F0=9F=92=AC2) 1 pull requests submitted: - Clarify wire protocol changes. Apply other editorial changes. (by chris= -wood) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/24=20 2 pull requests received 2 new comments: - #22 Addressing selfie attacks (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/22=20 - #10 Change binder_key computation. (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/10=20 1 pull requests merged: - Change binder_key computation. https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/10=20 * tlswg/draft-ietf-tls-ticketrequest (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Reword normative paragraph (by DavidSchinazi) https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/10=20 * tlswg/tls-subcerts (+2/-1/=F0=9F=92=AC1) 2 pull requests submitted: - Address Issue #43 (by grittygrease) https://github.com/tlswg/tls-subcerts/pull/46=20 - Proposal to address Issue #44 (by grittygrease) https://github.com/tlswg/tls-subcerts/pull/45=20 1 pull requests received 1 new comments: - #45 Proposal to address Issue #44 (1 by ekr) https://github.com/tlswg/tls-subcerts/pull/45=20 1 pull requests merged: - Proposal to address Issue #44 https://github.com/tlswg/tls-subcerts/pull/45=20 * tlswg/tls-exported-authenticator (+1/-0/=F0=9F=92=AC1) 1 pull requests submitted: - Nick/secdir2 (by grittygrease) https://github.com/tlswg/tls-exported-authenticator/pull/55=20 1 pull requests received 1 new comments: - #55 Nick/secdir2 (1 by seanturner) https://github.com/tlswg/tls-exported-authenticator/pull/55=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/tls-flags * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/sniencryption * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/draft-ietf-tls-grease --===============3910838504747949019== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday November 24, 2019

Issues

tlswg/draft-ietf-tls-esni (+0/-3/=F0=9F=92=AC4)

2 issues received 4 new comments:

3 issues closed:

tlswg/draft-ietf-tls-external-psk-importer (+1/-0/=F0=9F=92=AC0)

1 issues created:

tlswg/dtls13-spec (+0/-2/=F0=9F=92=AC0)

2 issues closed:

tlswg/tls-subcerts (+2/-2/=F0=9F=92=AC1)

2 issues created:

1 issues received 1 new comments:

2 issues closed:

tlswg/tls-exported-authenticator (+1/-0/=F0=9F=92=AC0)

1 issues created:

Pull requests

tlswg/draft-ietf-tls-esni (+0/-2/=F0=9F=92=AC2)

2 pull requests received 2 new comments:

2 pull requests merged:

tlswg/certificate-compression (+3/-3/=F0=9F=92=AC0)

3 pull requests submitted:

3 pull requests merged:

tlswg/draft-ietf-tls-external-psk-importer (+1/-1/=F0=9F=92=AC2)

1 pull requests submitted:

2 pull requests received 2 new comments:

1 pull requests merged:

tlswg/draft-ietf-tls-ticketrequest (+1/-0/=F0=9F=92=AC0)

1 pull requests submitted:

tlswg/tls-subcerts (+2/-1/=F0=9F=92=AC1)

2 pull requests submitted:

1 pull requests received 1 new comments:

1 pull requests merged:

tlswg/tls-exported-authenticator (+1/-0/=F0=9F=92=AC1)

1 pull requests submitted:

1 pull requests received 1 new comments:

Repositories tracked by this digest:

--===============3910838504747949019==-- From nobody Sun Nov 24 08:27:47 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961FC120052 for ; Sun, 24 Nov 2019 08:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.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 toIloslrUABD for ; Sun, 24 Nov 2019 08:27:43 -0800 (PST) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F942120043 for ; Sun, 24 Nov 2019 08:27:43 -0800 (PST) Received: by mail-pg1-x52c.google.com with SMTP id z188so5850087pgb.1 for ; Sun, 24 Nov 2019 08:27:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gk7LjLN/egQc0a/6riyn/+eel4mG44U2qpoVNF8W9iA=; b=HUA/us7DImVtV+CnOO/6kel5mMLuWdBfysvT7RuPAVCTzgHlmX5wstUT5e9glleV4C NrN3eFOO8izv1PLaBYEdzXEzjPa+gyz8Cm/6b4P9Fhu3mvwuTuuMUSzHYzDWM1bm9u0s d4A29/tce8bEkRbG9WozCFaB0rjX/mTX3S91k= 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=gk7LjLN/egQc0a/6riyn/+eel4mG44U2qpoVNF8W9iA=; b=AyWW+r2MR/6EY9ykWyBfU5M0gzHFaIRNcMvdHZYWvqyEnQb3Pw6ZuYRF6VL0YKebJL ZogGd53rko7+j1FqhVIDF7LdeMGBk/RmqT0wx93P4PMRwlTrnlbIunSkKkNqgpBdQrH0 o+3I0r4m2wANdNtSkGNYc7XgIrbiU6ROoLIDF1gq5Ijo4Rg+VTLKNgr3Cz/TbdMsHm+N oLr7a3csaHbvznRBpMkkCmNTBHOQ8KsxL312vJthfJkUGSMQOttUPrEtzJ8JtfF+6iF8 CuLCoTfytxwOOBYdgS1z3QmDgt57AdBDeYhKcWDl0qOHYZNzlLHDGK/JV2JY5s6SZTD0 7/OA== X-Gm-Message-State: APjAAAVZ5nbIo16WwOcE6Hi7tkTktShz2hAW+pKvGfs0ZpVqjz7v9eR5 4bQzuVt3xATQFv3Mphu+D325xZuB/Uc8ySyszOCe X-Google-Smtp-Source: APXvYqxgCbPvvCebnG0JdBXClK2wduOKcNuG5Y63cGLJHccsg6SseVLx+ycn3o7Kf3hRqC+ehLfo0ihIbrzOjXZP+g0= X-Received: by 2002:a63:e0a:: with SMTP id d10mr14741044pgl.124.1574612862375; Sun, 24 Nov 2019 08:27:42 -0800 (PST) MIME-Version: 1.0 References: <508EEDF7-73D2-4BE6-AFBA-710E5A5AB41F@sn3rd.com> <315F2BCF-11E0-4FBD-8420-865F29A66AD1@akamai.com> <20191123134005.GA1224585@LK-Perkele-VII> In-Reply-To: <20191123134005.GA1224585@LK-Perkele-VII> From: David Benjamin Date: Sun, 24 Nov 2019 11:27:26 -0500 Message-ID: To: Ilari Liusvaara Cc: "" Content-Type: multipart/alternative; boundary="000000000000528c5505981a205a" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-md5-sha1-deprecate X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2019 16:27:46 -0000 --000000000000528c5505981a205a Content-Type: text/plain; charset="UTF-8" On Sat, Nov 23, 2019 at 8:40 AM Ilari Liusvaara wrote: > On Fri, Nov 22, 2019 at 08:18:47PM +0100, Hubert Kario wrote: > > On Friday, 22 November 2019 03:25:24 CET, David Benjamin wrote: > > > On Fri, Nov 22, 2019 at 8:35 AM Salz, Rich wrote: > > > > > > > > ... > > > > SHA-1 signature hashes in TLS 1.2" draft available > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/. > > > > Please review the document and send your comments to the list by > 2359 UTC > > > > on 13 December 2019. > > > > > > > > I just re-read this. Looks good. Perhaps a sentence of rationale in > ... > > > > > > To that end, the combination of client advice in sections 2 and 4 is a > bit > > > odd. Section 2 uses SHOULD NOT include MD5 and SHA-1, but section 4 > says > > > the client MUST NOT accept the MD5 SHA-1, even if it included it. Why > would > > > the client include it in that case? It seems the two should either > both be > > > MUST NOT or both be SHOULD NOT. > > > > because it also influences certificate selection, and getting a > certificate > > signed with SHA-1 isn't an automatically disqualifying property? > > (it may be an intermediate CA that's not used, it may be an explicitly > > trusted > > certificate, etc.) > > If you don't want SHA-1 exchange signatures, you darn sure do not want > actual SHA-1 certificates that are not trust anchors anyway. And because > TLS 1.2 does not have separate lists for exchange signatures and > certificate signatures, the client needs to withdraw advertisment for > both in order to not send a misleading offer. > Right, I had a longer discussion of the certificate-but-not-TLS case but omitted it. :-) Basically what Ilari said. In particular, I believe older versions of Schannel will, despite being able to sign SHA-256, preferentially sign SHA-1 if the client offers it. This is inconvenient when it comes to predicting breakage but is perfectly consistent with the client's offer. When I last looked at this a few years ago, this accounted for a nontrivial portion of SHA-1-negotiating servers on the web, so rejecting SHA-1 while still advertising it is probably not the best strategy. Fortunately, we've already distrusted SHA-1 X.509 signatures on the web, so hopefully that will simplify things. There is a risk that some servers' trust anchors' (otherwise irrelevant) signatures are SHA-1 and they are trying to match it against the signature algorithms list, but I expect the SHA-1-preferring servers to be the deciding concern. Issues with trust-anchor-checking servers can likely be worked around by configuring the server to not send the trust anchor, which is desirable anyway. (All of this may not apply to non-web deployments, of course.) > And I expect that in practice, not sending SHA-1 in > signature_algorithms would cause very little breakage on top of what > is already broken due to using SHA-1 exchange signatures. So I think both should be MUST NOT. > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000528c5505981a205a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Nov 23, 2019 at 8:40 AM Ilari Liu= svaara <il= ariliusvaara@welho.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Nov 22, 2019 at 08= :18:47PM +0100, Hubert Kario wrote:
> On Friday, 22 November 2019 03:25:24 CET, David Benjamin wrote:
> > On Fri, Nov 22, 2019 at 8:35 AM Salz, Rich <rsalz@akamai.com> wrote:
> >
> > > > ...
> > > SHA-1 signature hashes in TLS 1.2" draft available
> > > https://datatracke= r.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/.
> > > Please review the document and send your comments to the lis= t by 2359 UTC
> > > on 13 December 2019.
> > >
> > > I just re-read this.=C2=A0 Looks good. Perhaps a sentence of= rationale in ...
> >
> > To that end, the combination of client advice in sections 2 and 4= is a bit
> > odd. Section 2 uses SHOULD NOT include MD5 and SHA-1, but section= 4 says
> > the client MUST NOT accept the MD5 SHA-1, even if it included it.= Why would
> > the client include it in that case? It seems the two should eithe= r both be
> > MUST NOT or both be SHOULD NOT.
>
> because it also influences certificate selection, and getting a certif= icate
> signed with SHA-1 isn't an automatically disqualifying property? > (it may be an intermediate CA that's not used, it may be an explic= itly
> trusted
> certificate, etc.)

If you don't want SHA-1 exchange signatures, you darn sure do not want<= br> actual SHA-1 certificates that are not trust anchors anyway. And because TLS 1.2 does not have separate lists for exchange signatures and
certificate signatures, the client needs to withdraw advertisment for
both in order to not send a misleading offer.

Right, I had a longer discussion of the certificate-but-not-TLS case= but omitted it. :-) Basically what Ilari said. In particular, I believe ol= der versions of Schannel will, despite being able to sign SHA-256, preferen= tially sign SHA-1 if the client offers it. This is inconvenient when it com= es to predicting breakage but is perfectly consistent with the client's= offer. When I last looked at this a=C2=A0few years ago, this accounted for= a nontrivial portion of SHA-1-negotiating servers on the web, so rejecting= SHA-1 while still advertising it is probably not the best strategy.
<= div>
Fortunately, we've already distrusted SHA-1 X.509 si= gnatures on the web, so hopefully that will simplify things. There is a ris= k that some servers' trust anchors' (otherwise irrelevant) signatur= es are SHA-1 and they are trying to match it against the signature algorith= ms list, but I expect the SHA-1-preferring servers to be the deciding conce= rn. Issues with trust-anchor-checking servers can likely be worked around b= y configuring the server to not send the trust anchor, which is desirable a= nyway.

(All of this may not apply to non-web deplo= yments, of course.)
=C2=A0
And I expect that in practice, not sending SHA-1 in
signature_algorithms would cause very little breakage on top of what
is already broken due to using SHA-1 exchange signatures.=C2=A0
=C2=A0
So I think both should be MUST NOT.



-Ilari

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000528c5505981a205a-- From nobody Sun Nov 24 20:50:00 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A475212022C for ; Sun, 24 Nov 2019 20:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 R8xaSSEjxWFw for ; Sun, 24 Nov 2019 20:49:57 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DEC312023E for ; Sun, 24 Nov 2019 20:49:56 -0800 (PST) Received: from Jude (50.76.105.153) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 24 Nov 2019 20:49:33 -0800 From: Jim Schaad To: 'TLS List' References: In-Reply-To: Date: Sun, 24 Nov 2019 20:49:30 -0800 Message-ID: <053701d5a34b$baf96980$30ec3c80$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKGwWZ6z2czDM0oXE6NgAjmueUCdaY5FIew Content-Language: en-us X-Originating-IP: [50.76.105.153] Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2019 04:49:59 -0000 I believe that this is a worth while effort. I will be willing to review and might contribute text -----Original Message----- From: TLS On Behalf Of Sean Turner Sent: Wednesday, November 20, 2019 9:36 PM To: TLS List Subject: [TLS] Adoption call for draft-rescorla-tls-ctls At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS WG and the LAKE BOF, which is now a chartered WG [3]. After some discussions, the ADs suggested [4] that the TLS WG consider whether this draft be adopted as a TLS WG item. LAKE could then later specify/refer/adopt/profile it, as appropriate. The authors revised cTLS and presented the revised draft at IETF 106 [5]. At IETF 106 there was support for adoption of cTLS as a WG item. To confirm this on the list: if you believe that the TLS WG should not adopt this as a WG item, then please let the chairs know by posting a message to the TLS list by 2359 UTC 13 December 2019 (and say why). NOTE: : If the consensus is that this draft should be adopted as a WG item, then this will necessarily result in a WG rechartering discussions. We would have gotten to this rechartering discussion anyway now that DTLS 1.3 is progressing out of the WG. Thanks, Chris, Joe, and Sean [0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/ [1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ [2] https://github.com/ekr/draft-rescorla-tls-ctls [3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ [4] https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk [5] https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-tl s-13-00.pdf _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Sun Nov 24 22:46:43 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1D412080A for ; Sun, 24 Nov 2019 22:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 AD0bwwF5Yo2M for ; Sun, 24 Nov 2019 22:46:32 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 F154C120806 for ; Sun, 24 Nov 2019 22:46:31 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id k13so14913070ioa.9 for ; Sun, 24 Nov 2019 22:46:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zUXxXOFvuAGdI+6YtAMVbvy8iXJp8+xLvDg33tz2SrI=; b=IW9ugSj9KXPfdsEi/xRzJmz4HAx3mdvAGjYDJ83f8ncDE0jMHtkBxH9FKDOF1rG1C6 XsGbIDbAnIFrmb0IJHYUuRyfBbbpQr8vOHA0fYTmdeXmhpquhvQHpSNK93KamY2jZoxS aMJi1BEDMgAfI0y3wJCN5nM23eeQsFLSo4XBwAcIPcamCjM3vE9JdZQhizOb+lMwk+GJ 3h9KSAyaLKPYPUAtTteBQh4m/G5NqdtkHQBTTw93P3gXcKL0GNWGVOtAuW4lbv4mBCf1 o3dKeZIFuRPMpNfig3Mod0nEW4yldTkYPgo2+SY5pMXHuUefxK/R4oGobNz2fDLYu2nI KeXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=zUXxXOFvuAGdI+6YtAMVbvy8iXJp8+xLvDg33tz2SrI=; b=D5luz2hvxHMGyzCoFN8F3ctLMt0Baj8QIcKmAKbm/mNX+/R9mvQtFX3TEr7YRLdiAE br6CgXI3w4yhD4tOswPW5q2+N8gBkUkXpMtJssIFZDR7eLaEUbSpkR06oF/LNqxasd9E aQErBVsJmeR8KYuxfFAv5AMGUHlIW6OPpswaFDymw2TtoW02nd4RwHiLS/MGmu0bQXV1 LjEOLxOp0wyyhVJTxR/Sl5tTW4Ac4hOTu7yqoMnk+kfkFQKLgqzcsPbChf38kvkGBUKW sAGsorEtUmymfu3zTXkYemza6WhO+4+pFsIzu+/SBrFXE0Xahxfws8UzmHVu89vSgG0i XGQw== X-Gm-Message-State: APjAAAU7WYh2pBrO/nDXQXCwL6E2ODgi48FbiekyCKwm8oTmRM57/uTQ MNMqwOsPu3WWb2yAAULX1Tu2fSA31fHEcBEKMR3PY2UM X-Google-Smtp-Source: APXvYqxwfPrFLPDP5lS/qgDt/dxeiMfkc5fv1HbSAPQUmvPganMeEmOTabo0ou1X86y2RtROHj2qwbQ9zs69+7rLJAE= X-Received: by 2002:a05:6602:8c:: with SMTP id h12mr340726iob.254.1574664390773; Sun, 24 Nov 2019 22:46:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Sun, 24 Nov 2019 22:46:18 -0800 Message-ID: To: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a70f330598261f24" Archived-At: Subject: Re: [TLS] ESNI interoperability questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2019 06:46:34 -0000 --000000000000a70f330598261f24 Content-Type: text/plain; charset="UTF-8" Hi, This client now interoperates with Cloudflare and the https://defo.ie copy of OpenSSL. It's tri-licensed under the Apache 2, MIT, and ISC licenses. It won't be merged until draft-06 is out, at a minimum. https://github.com/ctz/rustls/pull/318/files I found some things confusing in the draft: 1) The draft uses field names that carry a lot of weight, but they're not always explained in prose. 2) I think the draft could benefit from a more procedural description of the steps required, like one might read in a WHATWG draft. This preference could just be what I'm used to, though. 3) It's not clear what to do if the server doesn't consult the (E)SNI at all. For example, Cloudflare doesn't seem to check things for big clients like medium.com, which presumably have a dedicated IP. In newer PRs and proposals, should a bogus encrypted SNI from the client trigger a retry request even if the server doesn't need the SNI? 4) The draft seems to require more precise explanation around the key exchange, since it uses some functions from the TLS 1.3 key schedule in a novel way. I saw weird names and patterns in both rustls and NSS. For example, in rustls, the secret input "Z" ended up being named "premaster_secret". It works, but there's a semantic mismatch. thanks, Rob [0] Example: https://html.spec.whatwg.org/multipage/browsers.html#crossorigingetownpropertyhelper-(-o,-p-) On Sat, Oct 26, 2019 at 3:31 PM Rob Sayre wrote: > Hi, > > I think I have a working ESNI client, but I'm encountering a strange error > testing with Cloudflare. > > I initially tested with "cloudflare.com", but found this was a bad idea, > because that host doesn't seem to require an SNI or ESNI. So, a bogus ESNI > triggered no errors. > > When my client sends an ESNI to a Cloudfront-fronted domain, I get a > handshake_failure error (40). According to the -02 draft, this should only > happen if the server fails to negotiate TLS 1.3. I've got my client > configured for TLS 1.3 only, so this shouldn't be an issue. When I add an > unencrypted SNI to an otherwise identical ClientHello, everything works > over TLS 1.3. If there are problems with my ESNI encryption, I should see > other errors. Things like "illegal_parameter" or "decrypt_error", right? > > In Wireshark, I can at least see that my encrypted_server_name extension > matches Firefox's cipher and key share entries, and the lengths of > record_digest and encrypted_sni are the same. Firefox does send some > extensions I don't, like ALPN. Does the absence of unencrypted SNI imply > the presence of other extensions? > > I also wondered about extension order. Since the ClientHello.key_share is > part of the ESNI calculation, does it need to appear first in the > extensions list? > > thanks, > Rob > --000000000000a70f330598261f24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

=


=
I found some things confusing in the draft:

1= ) The draft uses field names that carry a lot of weight, but they're no= t always explained in prose.
2) I think the draft could benefit f= rom a more procedural description of the steps required, like one might rea= d in a WHATWG draft. This preference could just be what I'm used to, th= ough.
3) It's not clear what to do if the server doesn't = consult the (E)SNI at all. For example, Cloudflare doesn't seem to chec= k things for big clients like medium.com,= which presumably have a dedicated IP. In newer PRs and proposals, should a= bogus encrypted SNI from the client trigger a retry request even if the se= rver doesn't need the SNI?
4) The draft seems to require more= precise explanation around the key exchange, since it uses some functions = from the TLS 1.3 key schedule in a novel way. I saw weird names and pattern= s in both rustls and NSS. For example, in rustls, the secret input "Z&= quot; ended up being named "premaster_secret". It works, but ther= e's a semantic mismatch.

thanks,
Rob=


On Sat, Oct 26, 2019 at 3:31 PM Rob Sayre <sayrer@gmail.com> wrote:
Hi,

I think I have a working ESNI client, but I'm encountering a s= trange error testing with Cloudflare.

I initially = tested with "cloud= flare.com", but found this was a bad idea, because that host doesn= 't seem to require an SNI or ESNI. So, a bogus ESNI triggered no errors= .

When my client sends an ESNI to a Cloudfront= -fronted domain, I get a handshake_failure error (40). According to the -02= draft, this should only happen if the server fails to negotiate TLS 1.3. I= 've got my client configured for TLS 1.3 only, so this shouldn't be= an issue. When I add an unencrypted SNI to an otherwise identical ClientHe= llo, everything works over TLS 1.3. If there are problems with my ESNI encr= yption, I should see other errors. Things like "illegal_parameter"= ; or "decrypt_error", right?

In Wireshar= k, I can at least see that my encrypted_server_name extension matches=C2=A0= Firefox's cipher and key share entries, and the lengths of record_diges= t and encrypted_sni are the same. Firefox does send some extensions I don&#= 39;t, like ALPN. Does the absence of unencrypted SNI imply the presence of = other extensions?

I also wondered about extension = order. Since the ClientHello.key_share is part of the ESNI calculation, doe= s it need to appear first in the extensions list?

= thanks,
Rob
--000000000000a70f330598261f24-- From nobody Mon Nov 25 05:46:01 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72F712095D for ; Mon, 25 Nov 2019 05:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADSD38bcKqFv for ; Mon, 25 Nov 2019 05:45:58 -0800 (PST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4341412095B for ; Mon, 25 Nov 2019 05:45:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574689557; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OcmPPahEAqOpghDRQiXFj0O7A8oSyV/EfseXW9+qRoo=; b=WeZq3iSzdgETrJMsr9O6fGLrBcRfjqMdAUSX78DRbiXnCou2+ynDFqqRv3kL1WRb6pIzb8 mJWXT4cPRanKsciGIPIy0T0Do0YyxijOj2bRrHM08EI25cWex83t6EEbW9Lv3HnwcmFG2Z PKrPzYXchunF9Om1TjgsjA409oBlBoY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-272-Ya6hncAaObWlnhZRA3Q26g-1; Mon, 25 Nov 2019 08:45:55 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9E3818A6FF9 for ; Mon, 25 Nov 2019 13:45:54 +0000 (UTC) Received: from localhost (ovpn-200-53.brq.redhat.com [10.40.200.53]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3639410016DA for ; Mon, 25 Nov 2019 13:45:53 +0000 (UTC) From: Hubert Kario To: Date: Mon, 25 Nov 2019 14:45:51 +0100 MIME-Version: 1.0 Message-ID: <7c40cea2-c466-4511-9394-116e65100e1f@redhat.com> In-Reply-To: References: <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> <20191117002249.GV34850@straasha.imrryr.org> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> <67c2ed4f-ce87-4d63-87bf-c38a36c8fb70@www.fastmail.com> Organization: Red Hat User-Agent: Trojita/0.7; Qt/5.12.5; xcb; Linux; Fedora release 30 (Thirty) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-MC-Unique: Ya6hncAaObWlnhZRA3Q26g-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2019 13:46:00 -0000 On Thursday, 21 November 2019 07:35:09 CET, Rob Sayre wrote: > On Wed, Nov 20, 2019 at 10:25 PM David Schinazi > wrote: > >> Hi Rob, >>=20 >> The SHOULD from your point (1) is there to address Daniel's concern abou= t >> IoT. >>=20 > > Is the idea that excess tickets would be wasteful? I think that's true, b= ut > I would also not want an IoT device that crashed or performed > unnecessarily-poorly while processing excess tickets. an IoT device that can be crashed by server just sending valid and expected messages is horribly broken if it can't handle such messages, I seriously doubt it would handle=20 messages from an actual attacker (which, need I remind, MUST be handled correctly=20 and result in orderly connection shutdown, one that hopefully includes Alert messages) --=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic From nobody Mon Nov 25 05:49:53 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDEA612095E for ; Mon, 25 Nov 2019 05:49:51 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=delignat-lavaud.fr 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 NRzI6WHTbLGH for ; Mon, 25 Nov 2019 05:49:49 -0800 (PST) Received: from argon.maxg.info (argon.maxg.info [IPv6:2001:41d0:2:7f22::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0150612095D for ; Mon, 25 Nov 2019 05:49:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=delignat-lavaud.fr; s=dkim; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=pttqqabnU4r5Y+yP5j86RSgTstgzv85ATSVHsc50uOw=; b=O3Ayo21RWnXo9xOc+j4VJC9jvs LcntR26rD7p86am5cOvIJiCG15iwvy4U0amJF9tqBlF3FCAFDu9h+Uv5R+oLTB/K7s5DfhnTkeRbx pW57YYNck7fWa1HW3Nf/I0Rr0olaCpkfu1t/KJvO+Wbf73chcX98Fa1eGbH8jIU+nPBjP0aipO1gn 5BGrGZbojeYqT+0gmgPTqw+F9o2iv2r7YxJzc8+hmImWxVNhH9vpfRAXIwXuMeLlWDw0PB/ei+Tmz P05tsNo4i8bXkQVigdstFGL95v7rbjGmuDwfQSW4huT6LHRXPvd4iqOlV4+RHOeAnU3fTskpXpQ0g oPD1h/Og==; Received: from localhost (authenticated.user.IP.removed [::1]) by argon.maxg.info with esmtpa (envelope-from ) id 1iZEkM-00024u-Tx ; Mon, 25 Nov 2019 14:49:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 25 Nov 2019 13:49:45 +0000 From: Antoine Delignat-Lavaud To: Sean Turner Cc: TLS List Organization: Microsoft Research In-Reply-To: References: Message-ID: <4069dbe044d1b016bf12623b17ac0ec0@delignat-lavaud.fr> X-Sender: antoine@delignat-lavaud.fr User-Agent: Roundcube Webmail/1.2.3 Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2019 13:49:52 -0000 I support this effort, and would like to point out that we have recently published a paper [1] and a collection of tools [2] to automatically verify the security (non malleability) of binary message formats, which we successfully applied to all of TLS [3] (which revealed many small specification errors in published RFCs, and some malleability problems such as the lack of tag in the CertificateEntry type). Using this collection of tool, if the new compact format is expressible in the same syntax as TLS, it may be relatively easy to formally prove that the compact and full message formats are equivalent (and most of the proof is automated), by writing the lifting from the compact to the full specification types. I also recommend to formalize the message format specification language such that automatic tools like ours can directly operate over the formats described in the RFC. [1] https://www.microsoft.com/en-us/research/uploads/prod/2019/05/20190601everparse.pdf [2] https://github.com/project-everest/everparse [3] https://github.com/project-everest/mitls-fstar/blob/dev/src/parsers/Parsers.rfc Best, Antoine On 2019-11-21 05:36, Sean Turner wrote: > At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the > TLS WG and the LAKE BOF, which is now a chartered WG [3]. After some > discussions, the ADs suggested [4] that the TLS WG consider whether > this draft be adopted as a TLS WG item. LAKE could then later > specify/refer/adopt/profile it, as appropriate. The authors revised > cTLS and presented the revised draft at IETF 106 [5]. At IETF 106 > there was support for adoption of cTLS as a WG item. To confirm this > on the list: if you believe that the TLS WG should not adopt this as a > WG item, then please let the chairs know by posting a message to the > TLS list by 2359 UTC 13 December 2019 (and say why). > > NOTE: > : If the consensus is that this draft should be adopted as a WG item, > then this will necessarily result in a WG rechartering discussions. > We would have gotten to this rechartering discussion anyway now that > DTLS 1.3 is progressing out of the WG. > > Thanks, > Chris, Joe, and Sean > > [0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/ > [1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ > [2] https://github.com/ekr/draft-rescorla-tls-ctls > [3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ > [4] > https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk > [5] > https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-tls-13-00.pdf > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Nov 25 09:05:10 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B679120813 for ; Mon, 25 Nov 2019 09:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.405 X-Spam-Level: X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.244, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVZux9jpHsC4 for ; Mon, 25 Nov 2019 09:05:06 -0800 (PST) Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45]) (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 9D35812099A for ; Mon, 25 Nov 2019 09:05:06 -0800 (PST) Received: by mail-ua1-f45.google.com with SMTP id d6so1712609uam.11 for ; Mon, 25 Nov 2019 09:05:06 -0800 (PST) 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=BFY/Xq3axOQkmRxVM9GOoQ5/KnqqhzAe5lTMh5YymdE=; b=LjbjSSoWHi+MAD5juCDx3p84Qd3VAJPtS1RdizD5M4BmFIPf0fyMJ/YJeZ4tLKVo5R 0N1y4Bfkq3loaKcafT+RtJdg4A4CbcALmQi9KvOirysMvt7JwAhfBP2yuTl+iAOpYXwr uVzQk9ZTQ3y5GbJlzti+A9fvr49i0SAJNQ7gAaUfqF39UgTaMuqGsA4YFExT65YjFfcv Yi1tIZphPz6MNhbAUCGzFOnigi8rxMhP5n49Da+etdBNkDA7nl+NONi593yUX1LX/nin vTzzmKZpMq2f+I+fTSVksZRWxjD80Z34o6TMy09fqsw5zzRCG102uaGelqIqidAW6fXS YgXw== X-Gm-Message-State: APjAAAUNO1qZmbuOi4m8oy/qD5W05KzFN8aYdTbPlC8Lq71qr2Cnpx3n LPkTHAnlJYJdn//LhiaWEPCGBOI/CkxB1p8YPYhujg== X-Google-Smtp-Source: APXvYqwNfcTnncOLMriZeyjVmyyeL5Kui6ekdfDWY8ABG2H9+DFMpI3PTGanT/RQwG5kHJe0eNnJJQ1leUu53d91EvI= X-Received: by 2002:ab0:5ea9:: with SMTP id y41mr18379535uag.114.1574701505623; Mon, 25 Nov 2019 09:05:05 -0800 (PST) MIME-Version: 1.0 References: <20191116103855.GQ20609@akamai.com> <20191116110425.GR34850@straasha.imrryr.org> <556d2210-4af7-b398-fbd7-eab2685d7c62@wizmail.org> <20191116210617.GS34850@straasha.imrryr.org> <20191116235952.GR20609@akamai.com> <20191117002249.GV34850@straasha.imrryr.org> <14690874-E301-4BC0-B385-00DEBCBA94C2@apple.com> <20191120034812.GQ34850@straasha.imrryr.org> <5FBFE820-8C53-4B32-9520-343279C1A6CC@apple.com> <20191120064819.GR34850@straasha.imrryr.org> In-Reply-To: From: Daniel Migault Date: Mon, 25 Nov 2019 12:04:54 -0500 Message-ID: To: David Schinazi Cc: tls Content-Type: multipart/alternative; boundary="000000000000debabf05982ec346" Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2019 17:05:08 -0000 --000000000000debabf05982ec346 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 20, 2019 at 10:20 PM David Schinazi wrote: > Hi folks, > > I've chatted with Daniel and Chris offline, and I think there might > have been some miscommunication here. Please allow me to > rephrase what I think is going on, and please let me know if > this accurately represents your views. > > Daniel has a IoT use-case where due to memory constraints, > a client knows it can only handle a certain number of tickets, > and therefore Daniel was wondering if it would make sense to > make the requested number of tickets a required maximum > (as in a RFC 2119 MUST). However, server operators on this > thread have indicated that a MUST would get in the way of > implementing this, due to STEK rotation for example. Daniel > understands this, and is OK with the current mindset of the > document (which is only a hint, not a MUST). Additionally, > Daniel would prefer to see the document move forward. > > In order to try to address Daniel's comments, I attempted > to rephrase the normative section to suggest in more > stronger terms that servers really shouldn't be sending > more than the client's request, but keeping it a SHOULD. > > Here is the PR with the rephrase: > https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/10 > > Here's a copy of the updated paragraph in the PR: > Clients can use TicketRequestContents.count to indicate the number of > tickets they would prefer to receive. Servers SHOULD NOT send more > tickets than TicketRequestContents.count, as clients will most likely > discard any additional tickets. Servers SHOULD additionally place a > limit on the number of tickets they are willing to send to save > resources. Therefore, the number of NewSessionTicket messages sent > SHOULD be the minimum of the server's self-imposed limit and > TicketRequestContents.count. > > I apology for the late response. This addresses my MUST/SHOULD concern. Thanks David. > Regarding Viktor's suggestion, I personally believe it would increase the > complexity of the proposal, and I don't see use-cases compelling enough > to warrant that complexity. I would rather keep this proposal as simple as > possible. > I particularly like the proposal from Viktor and - at least as I see it - its associated simplicity. I believe it would be beneficial for the document to include it. > > Thanks, > David > > > On Wed, Nov 20, 2019 at 2:48 PM Viktor Dukhovni > wrote: > >> On Wed, Nov 20, 2019 at 11:53:08AM +0800, Tommy Pauly wrote: >> >> > > Somebody should try to avoid ending up with N new tickets after >> > > every connection, but in could well be the client. >> > >> > Yes, I think that can and ought to be the client. The client is really >> the >> > only party that can know how many tickets have been "consumed" by >> potentially >> > failed attempts to connect that the server didn't see in time or got >> dropped. >> >> OK, in that case, the proposal, is that on resumption, if the proposed >> extension is *absent*, then the server should generally send just one >> rather >> than any larger default. >> >> If the extension is present, it is up to the client to not blindly ask >> for N >> tickets each time, and generally ask for just one ticket on resumption, >> once it >> has sufficiently many tickets for the desired concurrency level, with each >> parallel thread obtaining one replacement ticket its next connection. >> >> As discussed clients that prefer to reuse tickets, can ask for zero, and >> get 1 >> only as-needed. If the server supports reuse then all is well. >> >> If the server does not support and refuses reuse, then it will issue a new >> ticket each time and may only accept it once, but the client may have a >> single-slot cache. If the client makes only one connection at a time, >> this >> also works, but if/when its handshakes with the server overlap (a narrow >> window >> of ~1RTT) and two connections attempt to resume with the same ticket, one >> of >> them will end up doing a full handshake, but only when the client and >> server >> applications have incompatible ticket reuse expectations. Some friction >> when the client and server are mismatched is not the end of the world. >> >> So on the whole I think the proposal still works with just a numeric >> signal >> (tweaked with 0xff == none and 0 == reuse), and the onus to "generally >> send 1" >> on resumption moved to the client (i.e. clients that don't solicit ticket >> reuse >> should request only 1 ticket once they have enough). >> >> -- >> Viktor. >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000debabf05982ec346 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 20, 2019 at 10:20 PM Davi= d Schinazi <dschinazi.ietf@gmail.com> wrote:
Hi folks,

I&#= 39;ve chatted with Daniel and Chris offline, and I think there might
<= div>have been some miscommunication here. Please allow me to
reph= rase what I think is going on, and please let me know if
this acc= urately represents your views.

Daniel has a IoT us= e-case where due to memory constraints,
a client knows it can onl= y handle a certain number of tickets,
and therefore Daniel was wo= ndering if it would make sense to
make the requested number of ti= ckets a required maximum
(as in a RFC 2119 MUST). However, server= operators=C2=A0on this
thread have indicated that a MUST would g= et in the way of
implementing this, due to STEK rotation for exam= ple. Daniel
understands this, and is OK with the current mindset = of the
document (which is only a hint, not a MUST). Additionally,=
Daniel would prefer to see the document move=C2=A0forward.
=

In order to try to address Daniel's comments, I att= empted
to rephrase the normative section to suggest in more
=
stronger terms that servers really shouldn't be sending
= more than the client's request, but keeping it a SHOULD.

=
Here is the PR with the rephrase:

Here's a copy of the updated paragraph in the PR:
=C2=A0 =C2=A0Clients can use TicketRequestContents.count to indicate = the number of
=C2=A0 =C2=A0tickets they would prefer to receive.=C2=A0 S= ervers SHOULD NOT send more
=C2=A0 =C2=A0tickets than TicketRequestConte= nts.count, as clients will most likely
=C2=A0 =C2=A0discard any addition= al tickets.=C2=A0 Servers SHOULD additionally place a
=C2=A0 =C2=A0limit= on the number of tickets they are willing to send to save
=C2=A0 =C2=A0= resources.=C2=A0 Therefore, the number of NewSessionTicket messages sent=C2=A0 =C2=A0SHOULD be the minimum of the server's self-imposed limit = and
=C2=A0 =C2=A0TicketRequestContents.count.

I apology for the late response. This addresses my MU= ST/SHOULD concern. Thanks David.
=C2=A0=C2=A0 =C2=A0
Regarding Viktor's suggestion, I personally believe it would increase = the
complexity of the proposal, and I don't see use-cases com= pelling enough
to warrant that complexity. I would rather keep th= is proposal as simple as
possible.
<= br>
I particularly like the proposal from Viktor and - at least a= s I see it - its associated simplicity. I believe it would be beneficial fo= r the document to include it.=C2=A0
=C2=A0=C2=A0

Thanks,
David


On Wed, Nov 20, 2019 at 2:48 P= M Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
On Wed, Nov 20, 2019 at 11:53:08AM +0800, Tomm= y Pauly wrote:

> > Somebody should try to avoid ending up with N new tickets after > > every connection, but in could well be the client.
>
> Yes, I think that can and ought to be the client. The client is really= the
> only party that can know how many tickets have been "consumed&quo= t; by potentially
> failed attempts to connect that the server didn't see in time or g= ot dropped.

OK, in that case, the proposal, is that on resumption, if the proposed
extension is *absent*, then the server should generally send just one rathe= r
than any larger default.

If the extension is present, it is up to the client to not blindly ask for = N
tickets each time, and generally ask for just one ticket on resumption, onc= e it
has sufficiently many tickets for the desired concurrency level, with each<= br> parallel thread obtaining one replacement ticket its next connection.

As discussed clients that prefer to reuse tickets, can ask for zero, and ge= t 1
only as-needed.=C2=A0 If the server supports reuse then all is well.

If the server does not support and refuses reuse, then it will issue a new<= br> ticket each time and may only accept it once, but the client may have a
single-slot cache.=C2=A0 If the client makes only one connection at a time,= this
also works, but if/when its handshakes with the server overlap (a narrow wi= ndow
of ~1RTT) and two connections attempt to resume with the same ticket, one o= f
them will end up doing a full handshake, but only when the client and serve= r
applications have incompatible ticket reuse expectations.=C2=A0 Some fricti= on
when the client and server are mismatched is not the end of the world.

So on the whole I think the proposal still works with just a numeric signal=
(tweaked with 0xff =3D=3D none and 0 =3D=3D reuse), and the onus to "g= enerally send 1"
on resumption moved to the client (i.e. clients that don't solicit tick= et reuse
should request only 1 ticket once they have enough).

--
=C2=A0 =C2=A0 Viktor.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000debabf05982ec346-- From nobody Mon Nov 25 09:12:29 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F6D120A2B for ; Mon, 25 Nov 2019 09:12:24 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 4KMRgjiY1t32 for ; Mon, 25 Nov 2019 09:12:20 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 C4DDE1209C0 for ; Mon, 25 Nov 2019 09:12:19 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id j6so7776538lja.2 for ; Mon, 25 Nov 2019 09:12:19 -0800 (PST) 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=m1soUZ4gZ+sebYkx+IcFAXSmggkjqmyCc9k70ZFy8aI=; b=yzgq8y5aSE6ovAVmiI09IjJmKsMiNl52uHOEi0bAMDELTlNXe8x+8KMnqQt6665I5F VDN9OJNKWVRqIEayqNKDUoNRd+nXbfp+ef3eGzo+ESaau4XOmIgzGy5XS7T1spDs16Fp CjdON7tDQvXmDnTOFChTXo8gDAWceGq7N1ZvjLh8Y83ec8YHM7/eZtVoWDXJMB3Zwkm0 FPiJfoAsnDuP9N5J6K16swYv6sAYa/kZc4KXPcQL3eR+km7XPUmhcocArtfy/DwJFoEE 3WlnOkpg0wUBnAop6Lz2z8TPQWFjfHP1+WPnZL1U8lgeb5MU5TcNcY5MwdnM70A8vaAV gBMQ== 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=m1soUZ4gZ+sebYkx+IcFAXSmggkjqmyCc9k70ZFy8aI=; b=rKwEPGqwibx8zRa2UCFeGAGKmQmhDJLGNZwF8w+5ykD0ERBRcA7IUjq2v9EaW7SEW8 GVFII8Yi6CkAbR3FvvXWnBujW3ux7eKZir7pAcCrX0bjUsRC5XnxVcrQ515Lq3UmF2N2 X7Lj/IQLoD1tFz2xTuc/BfgDmtwHeIJTLhfSC2HL4XOv/q65blBgbH4LVoO2Xg0pIxYI UTqwwogbJv/P/J1PdJ5bROLJMV9JEdmy0P11ZCXk/EFJO5o+eetrDvMMFIoUrNRCI39l 4zWf2KAE5LA/NZ+3Vx7E86hViSycgQZyQCndm5ae6jZhH8CodH9IPocScijL/wfAMETZ s9XQ== X-Gm-Message-State: APjAAAU2lvWlKwJfXVXhT8j2iJ/ZyqP0p/KQg5C8a4iNVlUTjy7Oz2GN Nh/2nDXqDPRiUsRIGj5SSFpdfnqWUkJUfO+9oLDjMw== X-Google-Smtp-Source: APXvYqzeF+FAVotNBEDiM2cHLrTzUS9Xs98E4wG4zZz3lTriLO28OJs3KowEyPv1NkYqUx2TW7znBHsHKQlCRujD8SQ= X-Received: by 2002:a2e:84d0:: with SMTP id q16mr11897820ljh.48.1574701937996; Mon, 25 Nov 2019 09:12:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Mon, 25 Nov 2019 09:11:41 -0800 Message-ID: To: Rob Sayre Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a446fe05982edda9" Archived-At: Subject: Re: [TLS] ESNI interoperability questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2019 17:12:27 -0000 --000000000000a446fe05982edda9 Content-Type: text/plain; charset="UTF-8" On Sun, Nov 24, 2019 at 10:46 PM Rob Sayre wrote: > Hi, > > This client now interoperates with Cloudflare and the https://defo.ie > copy of OpenSSL. It's tri-licensed under the Apache 2, MIT, and ISC > licenses. It won't be merged until draft-06 is out, at a minimum. > > https://github.com/ctz/rustls/pull/318/files > > I found some things confusing in the draft: > > 1) The draft uses field names that carry a lot of weight, but they're not > always explained in prose. > 2) I think the draft could benefit from a more procedural description of > the steps required, like one might read in a WHATWG draft. This preference > could just be what I'm used to, though. > This isn't really IETF style, nor do I think it's clearer. 3) It's not clear what to do if the server doesn't consult the (E)SNI at > all. For example, Cloudflare doesn't seem to check things for big clients > like medium.com, which presumably have a dedicated IP. In newer PRs and > proposals, should a bogus encrypted SNI from the client trigger a retry > request even if the server doesn't need the SNI? > The handling of SNI is defined in 6066. This document just inherits that. 4) The draft seems to require more precise explanation around the key > exchange, since it uses some functions from the TLS 1.3 key schedule in a > novel way. I saw weird names and patterns in both rustls and NSS. For > example, in rustls, the secret input "Z" ended up being named > "premaster_secret". It works, but there's a semantic mismatch. > This seems like an implementation matter, especially as the term premaster_secret doesn't appear in 8446 at all. -Ekr > thanks, > Rob > > [0] Example: > https://html.spec.whatwg.org/multipage/browsers.html#crossorigingetownpropertyhelper-(-o,-p-) > > On Sat, Oct 26, 2019 at 3:31 PM Rob Sayre wrote: > >> Hi, >> >> I think I have a working ESNI client, but I'm encountering a strange >> error testing with Cloudflare. >> >> I initially tested with "cloudflare.com", but found this was a bad idea, >> because that host doesn't seem to require an SNI or ESNI. So, a bogus ESNI >> triggered no errors.. >> >> When my client sends an ESNI to a Cloudfront-fronted domain, I get a >> handshake_failure error (40). According to the -02 draft, this should only >> happen if the server fails to negotiate TLS 1.3. I've got my client >> configured for TLS 1.3 only, so this shouldn't be an issue. When I add an >> unencrypted SNI to an otherwise identical ClientHello, everything works >> over TLS 1.3. If there are problems with my ESNI encryption, I should see >> other errors. Things like "illegal_parameter" or "decrypt_error", right? >> >> In Wireshark, I can at least see that my encrypted_server_name extension >> matches Firefox's cipher and key share entries, and the lengths of >> record_digest and encrypted_sni are the same. Firefox does send some >> extensions I don't, like ALPN. Does the absence of unencrypted SNI imply >> the presence of other extensions? >> >> I also wondered about extension order. Since the ClientHello.key_share is >> part of the ESNI calculation, does it need to appear first in the >> extensions list? >> >> thanks, >> Rob >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000a446fe05982edda9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Nov 24, 2019 at 10:46 PM Rob = Sayre <sayrer@gmail.com> wrot= e:
Hi,

This client now interoperates with Cl= oudflare and the https://defo= .ie copy of OpenSSL. It's tri-licensed under the Apache 2, MIT, and= ISC licenses. It won't be merged until draft-06 is out, at a minimum.<= /div>


I found some things confusing in the draft:

1) The draft uses field names that carry a lot of wei= ght, but they're not always explained in prose.
2) I think th= e draft could benefit from a more procedural description of the steps requi= red, like one might read in a WHATWG draft. This preference could just be w= hat I'm used to, though.

Th= is isn't really IETF style, nor do I think it's clearer.
=

=
3) It's not clear what to do if the server doesn&= #39;t consult the (E)SNI at all. For example, Cloudflare doesn't seem t= o check things for big clients like medium.com, which presumably have a dedicated IP. In newer PRs= and proposals, should a bogus encrypted SNI from the client trigger a retr= y request even if the server doesn't need the SNI?

The handling of SNI is defined in 6066. This docume= nt just inherits that.


4) The draft seems t= o require more precise explanation around the key exchange, since it uses s= ome functions from the TLS 1.3 key schedule in a novel way. I saw weird nam= es and patterns in both rustls and NSS. For example, in rustls, the secret = input "Z" ended up being named "premaster_secret". It w= orks, but there's a semantic mismatch.
This seems like an implementation matter, especially as the ter= m premaster_secret doesn't appear in 8446 at all.

<= div>-Ekr


thanks,
Rob

On Sat, Oct 26, 2019 at 3:31 PM Rob Sayre <sayrer@gmail.com> wro= te:
Hi,

I think I have a working ESNI client, but I= 'm encountering a strange error testing with Cloudflare.

=
I initially tested with "cloudflare.com", but found this was a bad idea, = because that host doesn't seem to require an SNI or ESNI. So, a bogus E= SNI triggered no errors..

When my client sends= an ESNI to a Cloudfront-fronted domain, I get a handshake_failure error (4= 0). According to the -02 draft, this should only happen if the server fails= to negotiate TLS 1.3. I've got my client configured for TLS 1.3 only, = so this shouldn't be an issue. When I add an unencrypted SNI to an othe= rwise identical ClientHello, everything works over TLS 1.3. If there are pr= oblems with my ESNI encryption, I should see other errors. Things like &quo= t;illegal_parameter" or "decrypt_error", right?
In Wireshark, I can at least see that my encrypted_server_name= extension matches=C2=A0Firefox's cipher and key share entries, and the= lengths of record_digest and encrypted_sni are the same. Firefox does send= some extensions I don't, like ALPN. Does the absence of unencrypted SN= I imply the presence of other extensions?

I also w= ondered about extension order. Since the ClientHello.key_share is part of t= he ESNI calculation, does it need to appear first in the extensions list?

thanks,
Rob
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000a446fe05982edda9-- From nobody Mon Nov 25 09:52:13 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBD6120AF6; Mon, 25 Nov 2019 09:52:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: tls-chairs@ietf.org, Sean Turner , draft-ietf-tls-certificate-compression@ietf.org, tls@ietf.org, sean@sn3rd.com, kaduk@mit.edu Content-Transfer-Encoding: 7bit Reply-To: last-call@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157470432531.11465.8444603434405009206.idtracker@ietfa.amsl.com> Date: Mon, 25 Nov 2019 09:52:05 -0800 Archived-At: Subject: [TLS] Last Call: (TLS Certificate Compression) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2019 17:52:06 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'TLS Certificate Compression' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2019-12-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In TLS handshakes, certificate chains often take up the majority of the bytes transmitted. This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7932: Brotli Compressed Data Format (Informational - IETF stream) draft-kucherawy-rfc8478bis: Zstandard Compression and the application/zstd Media Type (None - IETF stream) rfc1950: ZLIB Compressed Data Format Specification version 3.3 (Informational - Legacy stream) From nobody Mon Nov 25 10:50:18 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6F0120908 for ; Mon, 25 Nov 2019 10:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=NBJmQ79I; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KNzQex9s 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 pXnrcAb-GoVe for ; Mon, 25 Nov 2019 10:50:14 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F7D120C31 for ; Mon, 25 Nov 2019 10:50:14 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6C11A22783 for ; Mon, 25 Nov 2019 13:50:13 -0500 (EST) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Mon, 25 Nov 2019 13:50:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm2; bh=W5xughEQOYmzR7fuIVDYUWnwKJETTlkJJ2dbEpUMU3U=; b=NBJmQ79I yvuwWYGpCDHmFFXFAUkpFJy2OWbmQ5YmeikuIbL+13eT3IQmsRoQ2kx2puLMQUq8 6WWZoO6yjNhs0o6A0BkJz/tN+FtV2POSmfN9MtP+InoEmfaL44zuIOeepTwFpLXj zRzvk9Kn8fl6WYtfgyu/VLqUWiOS+3cvVfBC/UvyZfXyvjVNQ9DNLEpdTxBe6lrZ qKTAySCzSKzmy4zGDeC5j/zGj7IwpmSBf4Mh0DNkH1e/frqmqs8JLd4ltzC9Xy+0 vnljqbmZP4cXphRoE8mCt5Oyrhhg+AxtAHNm8lv7ujjvggvdwKpAeg8oTKFJaBey /LRiWJgX1wbYPA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=W5xughEQOYmzR7fuIVDYUWnwKJETT lkJJ2dbEpUMU3U=; b=KNzQex9sG3bYMYcDd+8NKjZAgmOweRkjQfrH4FI2mM7lp +mTOA1PFMOSBcCQeAll9EIm1p2mi1SnsnJ5p0wTYKtYk5pSX89mxPI7Sk/ejb0Y7 wA5v3pWGTm3QNIpUtjy4rAkbrQz/WH6NClfH9VZIOmIjOISYi89yDT/bKFYJm6ES O1dPpHkZ0SWu10zcvK5UwwL7UlPt2RK+RVPkR+gCSeKL0Tazi6tOLzR+scgY9Osj eq5bcM6kEppc3zMyG8yDQ1ZGYSww0//FSd8s3suHLXcg8Y16xj6+J1RDS8/0P/nu 7fm1xSvkl1e9Bx56msTMtIxWv6BgxKldToHmwWHCA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeiuddguddulecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomh enucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgv thenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3F4383C00A1; Mon, 25 Nov 2019 13:50:12 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-578-g826f590-fmstable-20191119v1 Mime-Version: 1.0 Message-Id: Date: Mon, 25 Nov 2019 10:49:52 -0800 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: [TLS] Draft minutes available X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2019 18:50:16 -0000 Draft minutes are available here: https://github.com/tlswg/wg-materials/blob/master/ietf106/minutes.md Thanks to Tommy and Joe for taking notes! Please send edits to the list or chairs as needed. Best, Chris From nobody Mon Nov 25 11:03:06 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25870120CB9 for ; Mon, 25 Nov 2019 11:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 wF2l3Rg2dHKF for ; Mon, 25 Nov 2019 11:03:03 -0800 (PST) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 122BF120CB2 for ; Mon, 25 Nov 2019 11:03:02 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id i11so17441975iol.13 for ; Mon, 25 Nov 2019 11:03:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=RkY6bkTPnvsi/OJlP+IBO44KakaVnLzWa7qkyY2Ojws=; b=MsaM3TDOFkwlSO7X63YxE37PFrhhBq60b7GUN14maqR1WsbhHcpWNj0NsS52HFCh6R tdWB2QzfPsWfTxXAmiecTCcP8cEkabQCQCSdkeu39v6tqQ8QzrTBlGRlyhjcH1+rp7rC //xl028zGy4L9Z/akiUazOvrLcWXhGLio/rbVRZ05OkoujnvEqhiDPog7K6fSOm08FlI gUwKtJa6PvaVBthGsVN3/eCgY24KrnQpP4cUYHX6gV6h8N3iiFaXLL26qoD0DUi1g4Xb zDpkSKaQPLIKrCU/JsPlCHD9T7sYcQqLHiaafJQMygE5HeYiI0s6Rjel9p5J/G8MYtJY vs0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RkY6bkTPnvsi/OJlP+IBO44KakaVnLzWa7qkyY2Ojws=; b=nsD5upyTAlMmSejqXfvGpBiDSVuSnC6QFmMfGmOTGXu0eSvbKvkNqaB6I5FBXDhwZG /G+yKS8Q/Em24IXeA2OB9L+qCqkSp+B5sCZS79OTUO9IFzMyx2BAOi56ICS6ZxgsHpJ0 9MJGu77SzI0/qmyvmp4ZMiDm3Q/RuEnVMESeCFWtqIiDruxtXBhTHdMZjE1lOsGFijlh HUuFLM53QT2VhNNgJCRrtA/iWfJEyRwue3RwJQMAbjfvYnlLsr9pd5q0K7zhbgBWTcc6 KeFCSWIRLZds4kd4TDV2Q236zWV72JOVXmSFe2CDrGam/tulcReogti6K0KhMy4g3Pcg iOKQ== X-Gm-Message-State: APjAAAXibRyQlrcnvPvKL2f0cBzmK81PDbjTN1jEFD1x+BVrlzHv3gEH FkeSdmdYj85SWcZGVi6qeDrKvMswH18ESjsRc0X24w== X-Google-Smtp-Source: APXvYqwTvRMg7+2P9PvJPuModCsXHbJo3BXcu+lhA1Wv3IoKmXvLlruGuEYfTBqE683xO98cAZzVTxB2Br6FV424LBE= X-Received: by 2002:a5d:9b11:: with SMTP id y17mr11060318ion.73.1574708580804; Mon, 25 Nov 2019 11:03:00 -0800 (PST) MIME-Version: 1.0 From: Rob Sayre Date: Mon, 25 Nov 2019 11:02:49 -0800 Message-ID: To: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000956e020598306940" Archived-At: Subject: [TLS] ESNI: Tracking and blocking via record_digest X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2019 19:03:05 -0000 --000000000000956e020598306940 Content-Type: text/plain; charset="UTF-8" Hi, I see the issue of tracking and blocking via record_digest has come up a few times in the github repository, but I don't understand the resolution. If someone wanted to observe or block traffic to "example.com", couldn't they retrieve the ESNI keys, calculate the record_digest themselves, and then use that to spot traffic to "example.com"? Is the idea that DNS providers will vary the shared keys? thanks, Rob --000000000000956e020598306940 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I see the issue of tracking and= blocking via record_digest has come up a few times in the github repositor= y, but I don't understand the resolution.

If s= omeone wanted to observe or block traffic to "example.com", couldn't they retrieve the ESNI keys, cal= culate the record_digest themselves, and then use that to spot traffic to &= quot;example.com"?

Is the idea that DNS providers will vary the shared keys?

thanks,
Rob

--000000000000956e020598306940-- From nobody Mon Nov 25 11:11:33 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFAFC120D2E for ; Mon, 25 Nov 2019 11:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.406 X-Spam-Level: X-Spam-Status: No, score=-1.406 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.244, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2kf8C5VwgN3 for ; Mon, 25 Nov 2019 11:11:30 -0800 (PST) Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DE48120CF6 for ; Mon, 25 Nov 2019 11:11:27 -0800 (PST) Received: by mail-vs1-f48.google.com with SMTP id m5so6214918vsj.3 for ; Mon, 25 Nov 2019 11:11:27 -0800 (PST) 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=WjZVB6ai0Y2/w+kibbsGHokhRrQfBNqjcWXFZhhDNL4=; b=G3hEHdSxVJUT4ZeR2EHqvwDcjVptBrBZ0IivdJMqjRXgvZrl0rIobqcYQYRkpU/8BF JdLma4t7p7AInhfzicxmIMikRd4cERNbIAMH2QgvdMotQFAvBlQxymCzFNoAR6ApomI/ 7mnOCHRfO0E0dkyrPhKYi/D+lmgk+245kU3iYtfIpR441hVM0M10PK5n+L78VX9Pii1Q nSfp6Yd4yzvvoHzbbPmzKUkHp9rsOnXDuJA2bX0BjQj0hbBHxgRkI6F9/WnYfgLY6VY6 8Fwx1qXQPaIhaXhGLSgvTlBDW6lnccvSSXciKHDgs6cTwPYCuS64p6prYXO8LuYy9/PX RCBw== X-Gm-Message-State: APjAAAX0P3m7WWGD5TIEPTuUgzPJpRTSXziWL/UlIyredB1Fkgs/LIp+ MTwjCfjBburcAQlVb2HhaFyJB74gZ7I0axu6CM0= X-Google-Smtp-Source: APXvYqytfnhQBI7GuJ5Dr1JQIiuHo+csbXuJZ9aalSfIvM8mJ34ZXJP38R8fbuVdo1b32FuK+J0H4bJKueo6FlDE3Bc= X-Received: by 2002:a67:bd05:: with SMTP id y5mr20045420vsq.180.1574709086189; Mon, 25 Nov 2019 11:11:26 -0800 (PST) MIME-Version: 1.0 References: <000201d5a0e5$a47e6740$ed7b35c0$@gmx.net> In-Reply-To: <000201d5a0e5$a47e6740$ed7b35c0$@gmx.net> From: Daniel Migault Date: Mon, 25 Nov 2019 14:11:14 -0500 Message-ID: To: Hannes Tschofenig Cc: Daniel Migault , "Panos Kampanakis (pkampana)" , TLS List Content-Type: multipart/alternative; boundary="000000000000b4fc2a05983087c8" Archived-At: Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2019 19:11:32 -0000 --000000000000b4fc2a05983087c8 Content-Type: text/plain; charset="UTF-8" Hi Hannes, My reading is that only compression/decompression applies to our case. Fragmentation is optional and only concerns ipv6. I did not intent to make the comment at an inappropriate time, but if so, please consider it when it is appropriate. Yours, Daniel On Thu, Nov 21, 2019 at 10:34 PM wrote: > Hi Daniel > > > > Although inappropriate to discuss at the time of the adoption call I > wanted to point out that I looked at SCHC and was surprised to learn that > it is more than a compression scheme but also includes a protocol for > adding reliability. In my reading is essentially a replacement for 6lowpan. > Unfortunately, this design decision does not make it a well suited > mechanism for a generic compression mechanism. I am happy to get convinced > otherwise. > > > > Ciao > > Hannes > > > > *From:* TLS *On Behalf Of *Daniel Migault > *Sent:* Friday, November 22, 2019 10:20 AM > *To:* Panos Kampanakis (pkampana) > *Cc:* TLS List > *Subject:* Re: [TLS] Adoption call for draft-rescorla-tls-ctls > > > > I clearly support the adoption of the work, but it seems important to > ensure cTLS integrates or remains in line with the work on compression that > has been accomplished at the IETF - SCHC defined in lpwan might be a > starting point. It also seems important to me that cTLS defines mechanisms > that could be reused as TLS 1.3 evolves. > > > > Yours, > > Daniel > > > > On Fri, Nov 22, 2019 at 12:39 AM Panos Kampanakis (pkampana) < > pkampana@cisco.com> wrote: > > +1, support adoption. > > > > *From:* TLS *On Behalf Of *Dmitry Belyavsky > *Sent:* Thursday, November 21, 2019 4:46 AM > *To:* Sean Turner > *Cc:* TLS List > *Subject:* Re: [TLS] Adoption call for draft-rescorla-tls-ctls > > > > I support the adoption. > > > > On Thu, Nov 21, 2019 at 8:36 AM Sean Turner wrote: > > At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS WG > and the LAKE BOF, which is now a chartered WG [3]. After some discussions, > the ADs suggested [4] that the TLS WG consider whether this draft be > adopted as a TLS WG item. LAKE could then later specify/refer/adopt/profile > it, as appropriate. The authors revised cTLS and presented the revised > draft at IETF 106 [5]. At IETF 106 there was support for adoption of cTLS > as a WG item.. To confirm this on the list: if you believe that the TLS WG > should not adopt this as a WG item, then please let the chairs know by > posting a message to the TLS list by 2359 UTC 13 December 2019 (and say > why). > > NOTE: > : If the consensus is that this draft should be adopted as a WG item, then > this will necessarily result in a WG rechartering discussions. We would > have gotten to this rechartering discussion anyway now that DTLS 1.3 is > progressing out of the WG. > > Thanks, > Chris, Joe, and Sean > > [0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/ > [1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ > [2] https://github.com/ekr/draft-rescorla-tls-ctls > [3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ > [4] https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk > [5] > https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-tls-13-00.pdf > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > > > -- > > SY, Dmitry Belyavsky > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000b4fc2a05983087c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hannes,=C2=A0

My reading = is that only compression/decompression applies to our case. Fragmentation i= s optional and only concerns ipv6. I did not intent to make the comment at = an inappropriate time, but if so, please consider it when it is appropriate= .=C2=A0 =C2=A0

Yours,=C2=A0
Daniel
=

On Thu, Nov 21, 2019 at 10:34 PM <Hannes.Tschofenig@gmx.net> wrote:

Hi Daniel

=C2=A0

Although inappropriate to discuss at the ti= me of the adoption call I wanted to point out that I looked at SCHC and was= surprised to learn that it is more than a compression scheme but also incl= udes a protocol for adding reliability. In my reading is essentially a repl= acement for 6lowpan. Unfortunately, this design decision does not make it a= well suited mechanism for a generic compression mechanism. I am happy to g= et convinced otherwise.

=C2= =A0

Ciao

Hannes

=C2=A0<= /p>

From: TLS <tls-bounces@ietf.org> On Behalf Of = Daniel Migault
Sent: Friday, November 22, 2019 10:20 AM
To: Panos Kampanakis (pkampana) <pkampana@cisco.com>
Cc: TLS List <= ;tls@ietf.org>
= Subject: Re: [TLS] Adoption call for draft-rescorla-tls-ctls<= u>

=C2=A0

I clearly support the adoption of the work, but it seems importan= t to ensure cTLS integrates or remains in line with the work on compression= that has been accomplished at the IETF - SCHC defined in lpwan might be a = starting point. It also seems important to me that cTLS defines mechanisms = that could be reused as TLS 1.3 evolves.

=C2=A0

Yours,=C2=A0=

Daniel

=C2=A0

On Fri, Nov 22, 2019 at 12:39 AM Panos Kampanakis (= pkampana) <pkamp= ana@cisco.com> wrote:

=

+1, s= upport adoption.

=C2=A0

From: TLS <tls-bounces@ietf.org> On Behalf Of Dmitry Belyavsky<= br>Sent: Thursday, November 21, 2019 4:46 AM
To: Sean Turn= er <sean@sn3rd.com>
Cc: TLS List <tls@ietf.org>
Subject: Re: [TLS] Adoption call fo= r draft-rescorla-tls-ctls

=C2=A0=

I support the adoption.

=C2=A0

On Thu, Nov 21, 2019 at 8:36 AM Sean Turner <sean@sn3rd.com> wrote:<= u>

At IETF 105, ekr = presented cTLS (Compact TLS) [0][1][2] to both the TLS WG and the LAKE BOF,= which is now a chartered WG [3].=C2=A0 After some discussions, the ADs sug= gested [4] that the TLS WG consider whether this draft be adopted as a TLS = WG item. LAKE could then later specify/refer/adopt/profile it, as appropria= te. The authors revised cTLS and presented the revised draft at IETF 106 [5= ].=C2=A0 At IETF 106 there was support for adoption of cTLS as a WG item..= =C2=A0 To confirm this on the list: if you believe that the TLS WG should n= ot adopt this as a WG item, then please let the chairs know by posting a me= ssage to the TLS list by 2359 UTC 13 December 2019 (and say why).

NO= TE:
: If the consensus is that this draft should be adopted as a WG item= , then this will necessarily result in a WG rechartering discussions.=C2=A0= We would have gotten to this rechartering discussion anyway now that DTLS = 1.3 is progressing out of the WG.

Thanks,
Chris, Joe, and Sean
[0] https://datatracker.ietf.org/doc/slides-105-tls-ses= sa-ctls/
[1] https://datatracker.ietf.org/doc/draft-res= corla-tls-ctls/
[2] https://github.com/ekr/draft-rescorla-tls-ctls=
[3] https://datatracker.ietf.org/doc/draft-rescorla-tl= s-ctls/
[4] https://mailarchive.ietf.org/a= rch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk
[5] https://datatracker.ietf.org/meeting/106/materials/slid= es-106-tls-compact-tls-13-00.pdf
___________________________________= ____________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls<= u>


=C2=A0

--

= SY, Dmitry Belyavsky

_______________________________________________
TLS mailing list
= TLS@ietf.org
https://= www.ietf.org/mailman/listinfo/tls

<= /div>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000b4fc2a05983087c8-- From nobody Mon Nov 25 11:25:53 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE05C120DCE for ; Mon, 25 Nov 2019 11:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU1FvfCTPX84 for ; Mon, 25 Nov 2019 11:25:49 -0800 (PST) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 56CD5120DCC for ; Mon, 25 Nov 2019 11:25:49 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id i11so6672803ioi.12 for ; Mon, 25 Nov 2019 11:25:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0xNKsFmtJIAOzJPW8vChaIG7Ttg4F2ld7odDkOj6EFs=; b=MpWPBX7GcEm4nAJJZ3nyaGFu8sW8gQcOuKoDXBTE1PgvdpI0HCrc6HeXu8yFRH9d4V tOuS22jXBL0j+vr+mMczmidZu610tNEJVlLEuXcTT+aAGUr4cD3npc+um00Kw89S2OX0 P94bvuulC8NRlTmP7RoydoST78SdEngLzKsWju+3scVVQUM6d2+ra4CyeqtCZ7UsHyMm elrI65dypKls9O3CW5U5ZHHWsXziibL+RCVQX6PgEXnRwghmDJlqAepMQHyN5GTumTUy m6lGMqm27HniGIUFPEERAoPipz30DmHFjcIzgPXkiV7pOKwDyr1j+++GIP9Go+YJSEq0 vPCA== 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=0xNKsFmtJIAOzJPW8vChaIG7Ttg4F2ld7odDkOj6EFs=; b=KPrpKukkMB4b9Omf9XFOU3Zku2gkR/bsDlcOBLxOGSzdD8lc44/6TsYDZYcZ6JZ8Wx gEBsIZgrkFZiPLttacRTrSao5KSpfulOVt+oHtuyaZzRs4g0E93BGEc0dRwaG93RQglx dK4Zhy178xDBu7edfI9MvWbaXEOR/3RBXpeY9v8WABYhWL6YU8/jhj4W73J7M3KZr/XJ cxn8IeeqhGSWarc9fc/9ogNFCKbk48XZHxHJEHbFoq/j79f/68BLjouvQRKkmilL4oaF fMSnO5BxKRGO2yEiEI4z85u+NgtMEIlJvDcNalzgm8ypfAe9qunH68xy7ed27UtOzofS bVhA== X-Gm-Message-State: APjAAAWmLpPNYP4lxtAVhTFTgZbr/RsS40ZnDUEl34PD9aLru7Y3Aggg oGYQt+TmYwXLZmqVDw+/Krasx5vjrvaKtMx4aI7Sqw== X-Google-Smtp-Source: APXvYqwLI3o7YZzsPu8UHFR6UrSXTA/l6sk/4nut0507Q53AnQAZyUKd9WdbgbyL46grxOh6XbGj/QvVMnHkf1SFD+k= X-Received: by 2002:a5d:8985:: with SMTP id m5mr21768290iol.193.1574709948223; Mon, 25 Nov 2019 11:25:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Mon, 25 Nov 2019 14:25:36 -0500 Message-ID: To: Rob Sayre Cc: "TLS@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000210a3e059830bbf7" Archived-At: Subject: Re: [TLS] ESNI: Tracking and blocking via record_digest X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2019 19:25:51 -0000 --000000000000210a3e059830bbf7 Content-Type: multipart/alternative; boundary="000000000000170558059830bbb7" --000000000000170558059830bbb7 Content-Type: text/plain; charset="UTF-8" The record_digest, like the ESNIConfig itself, is intended to be constant across all domains that form an anonymity set (i.e. O(1) ESNIConfigs per CDN). Thus, the record_digest reveals no additional information to an onlooker who can observe the server IP. On Mon, Nov 25, 2019 at 2:03 PM Rob Sayre wrote: > Hi, > > I see the issue of tracking and blocking via record_digest has come up a > few times in the github repository, but I don't understand the resolution. > > If someone wanted to observe or block traffic to "example.com", couldn't > they retrieve the ESNI keys, calculate the record_digest themselves, and > then use that to spot traffic to "example.com"? > > Is the idea that DNS providers will vary the shared keys? > > thanks, > Rob > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000170558059830bbb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The record_digest, like the ESNIConfig itself, is intended= to be constant across all domains that form an anonymity set (i.e. O(1) ES= NIConfigs per CDN).=C2=A0 Thus, the record_digest reveals no additional inf= ormation to an onlooker who can observe the server IP.

On Mon, Nov 25, 2019= at 2:03 PM Rob Sayre <sayrer@gmail.= com> wrote:
Hi,

I see the issue of tracking = and blocking via record_digest has come up a few times in the github reposi= tory, but I don't understand the resolution.

I= f someone wanted to observe or block traffic to "example.com", couldn't they retrie= ve the ESNI keys, calculate the record_digest themselves, and then use that= to spot traffic to "= example.com"?

Is the idea that DNS provid= ers will vary the shared keys?

thanks,
R= ob

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000170558059830bbb7-- --000000000000210a3e059830bbf7 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMb5MwaN/thbS6tcoSMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDgxMDA4MjIyMVoXDTIwMDIw NjA4MjIyMVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCapo7ARc1spX97SqdC5FrntcF1TsMY92BYdzbflXSKxq0yT835 3LNJtJ/J4lZC5QSgloRVy9U70CWQVLQUY+kXzFrEZkpgnHAtnlqZITjGGCj7+RAjWXbRHdOtvA/t EJKQJjEsuggE8qjMH2FoThWpOoAFfvLSw8aSir96C2tA8MV59tyI8ewdRBWKvQT6QTLPpPFmKJPJ H1idNM5tnwsWzADF6Xmz2tdLu4Nec4bGyzwHv4jGWrMfW6i5XO3cxFDLluvf7J6A2m+85dRtTC5q 2eqFRCpqqDsHcxsd8OFxpEe9ZhRw1XcMPjZmqHEPpJToDt9ReYetEffXx5DNqIcHAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFE77YQLCDddBAx5p+gBVO6KLah3VMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAW/09trVYeHUY5xMK3 1EuuFQyc7RaPOn+3qWJuDt4DVjNJl0uH27JsA30H70YGSPgNLo/KtC/1ejCAF2SjJrL+Qb93j4Cq BLI0djN/I9AHm7BVy4l+evwS6/7b8xwhKZSt+b2FuMSdpYRfxavlFKYo+WILW6gGx15o+KDRPusJ mo2s2mZDRTUfZ9e87SLTOUe/APBMIeKd+2Z9nnnBh0+d4LCn3tA4vmD1A/pIubUYaaTlLeZIQhpa D41mXEZUHdUVnGaIdPzJKNSkCeIUztyVBUJyYk3ROz9bCBjsHcUy2iqwuLGLaPI3bWjdwvxZ4kG4 dhjPuHq6t95sxpJ1F1X/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMb5MwaN/t hbS6tcoSMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBi4C3HqhlcSTnGkk2k5XG+ qsJ5xMugiSQ6V1lL4vs6zjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTExMjUxOTI1NDhaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAh6zvUXmh7MBzdbomcFMYpmHu7vZG2MV8azbq7dUE 4y2flA+yB6F2mzh6Iw0nx16aoyIoaq8AGWHPF6Fl8SDxGeIrLA4n5Og/jsyBb/AHP/BcGyB0dvwj AtFNmRueB+eallRieDfTCzht8gv0B4zOb1zveDgakSiX9rU9ZEJT0LIOQ0c0+TAUTpvSZCywrpEQ H/QiCu5jaQuK0mR+b76qB+Z0UqzyFqyv5q3NJ1X/0niNblSbMLDX9FqSB2FoCeZ+vGx6IVq+0w6Y 5V9VS4qOB8duYBKfx8OijFr/BnQy8DTKKMs3vHMeNYvtgNGXDIJb/jzXCeTJf6NFzlTkLkuQFg== --000000000000210a3e059830bbf7-- From nobody Mon Nov 25 12:38:20 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622BC120F69 for ; Mon, 25 Nov 2019 12:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 ZSsdKsH_hyoj for ; Mon, 25 Nov 2019 12:38:16 -0800 (PST) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 D380D120F65 for ; Mon, 25 Nov 2019 12:38:08 -0800 (PST) Received: by mail-il1-x133.google.com with SMTP id y16so7938983iln.0 for ; Mon, 25 Nov 2019 12:38:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B3Jm5fps5z9xyF/r7Qj74lgU75rg0Vexj65MPMw/5Uc=; b=JtQuhtFOp9Ym3RL8P5kJ9VgH9gx3XvWwN3L3lhtkZZ8U2de+NNbNwUuBpcLnwgIF0B RB0Ekrijm6MZBPq1IeVHJy7Lx1QeT30Cg+2HuUSRw942hzyYySQRHuOi8LqegnwKJvCq hTfsMfDgZzbwRC9G8jhDZ13LH5men1Sn5+ypvuuHboPCN86MmqZtK+Uf2DF32VALJ1su k9030MT1UPYczrSzvUnUmc9dotH5Z5zZShxh8BzOVP8XpHrZuK7WYBmNtf3h/DG24YiB FASDJ8aUQ+7IMgb1gqyhxF0e2LVaw0cE6jDjZo3lAeslNxoMW6U1PH7aZN/4HH1ilLuU Oz1w== 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=B3Jm5fps5z9xyF/r7Qj74lgU75rg0Vexj65MPMw/5Uc=; b=mKKdJsc1eiV6DJQweAfE6eYcDAywVRFjJDqH+Eu6hq8OcPF8iaxlfsW8U6CC67bDsI DzPjWV/VdFW5yGnQtNn//bP4KaYZ+ztrdXn5lYpaTftumopnJzlLo6ZLyIyK4A5RxBG8 rwHjS2OoZna+eU374P1h7jNU+B9NC4vRmtMGatW8FCVxlguJ5cpuzO/BSiZ1taZ5CXM8 +KS28WiRjOosBJZEH+hE46/ohAWaMPQNyZ7NKAS8c6IdKQeuaKUNfWNYlNOQA7HHbBon kHHd3y3aUm3D1poWTZ6IxZIhpmTGCSHov9sT2RIB4E+P0mVBfJgVMPkoh9KuIX94aolL Jxpg== X-Gm-Message-State: APjAAAV2BNfnAWJvx3XF7AhxWgUvqjHT5XEnlQ3FeWtcajPfN3Xxhrzg d7KAt1TlRhDpFEtJAaNcQgn8LxSsGctpUBq6Rlg= X-Google-Smtp-Source: APXvYqxp5mGRZA6MhJDHsXPiRx49NWOgCOcuAZEh7i4F13qWO7l2icnNZCfBSHYuKePKp5Qk3xE14OmoKcyjodmI58s= X-Received: by 2002:a92:cb49:: with SMTP id f9mr21786959ilq.189.1574714287993; Mon, 25 Nov 2019 12:38:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Mon, 25 Nov 2019 12:37:56 -0800 Message-ID: To: Ben Schwartz Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c239c4059831bd9d" Archived-At: Subject: Re: [TLS] ESNI: Tracking and blocking via record_digest X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2019 20:38:18 -0000 --000000000000c239c4059831bd9d Content-Type: text/plain; charset="UTF-8" You're right, this is all there in the draft. It's just scattered around a bit, and "anonymity set" is used only once and not defined. I filed an issue https://github.com/tlswg/draft-ietf-tls-esni/issues/204 in case the editors want to consolidate text on this concern. thanks, Rob On Mon, Nov 25, 2019 at 11:25 AM Ben Schwartz wrote: > The record_digest, like the ESNIConfig itself, is intended to be constant > across all domains that form an anonymity set (i.e. O(1) ESNIConfigs per > CDN). Thus, the record_digest reveals no additional information to an > onlooker who can observe the server IP. > > On Mon, Nov 25, 2019 at 2:03 PM Rob Sayre wrote: > >> Hi, >> >> I see the issue of tracking and blocking via record_digest has come up a >> few times in the github repository, but I don't understand the resolution. >> >> If someone wanted to observe or block traffic to "example.com", couldn't >> they retrieve the ESNI keys, calculate the record_digest themselves, and >> then use that to spot traffic to "example.com"? >> >> Is the idea that DNS providers will vary the shared keys? >> >> thanks, >> Rob >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > --000000000000c239c4059831bd9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You're right, this is all there in the draft. It's= just scattered around a bit, and "anonymity set" is used only on= ce and not defined.

I filed an issue https://github.com/tlswg/d= raft-ietf-tls-esni/issues/204 in case the editors want to consolidate t= ext on this concern.

thanks,
Rob


On Mon, Nov 25, 2019 at 11:25 AM Ben Schwartz <bemasc@google.com> wrote:
The record_diges= t, like the ESNIConfig itself, is intended to be constant across all domain= s that form an anonymity set (i.e. O(1) ESNIConfigs per CDN).=C2=A0 Thus, t= he record_digest reveals no additional information to an onlooker who can o= bserve the server IP.

On Mon, Nov 25, 2019 at 2:03 PM Rob Sayre <sayrer@gmail.com> wro= te:
Hi,

I see the issue of tracking and blocking vi= a record_digest has come up a few times in the github repository, but I don= 't understand the resolution.

If someone wante= d to observe or block traffic to "example.com", couldn't they retrieve the ESNI key= s, calculate the record_digest themselves, and then use that to spot traffi= c to "example.com= "?

Is the idea that DNS providers will vary t= he shared keys?

thanks,
Rob
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000c239c4059831bd9d-- From nobody Mon Nov 25 19:33:29 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177D812088A for ; Mon, 25 Nov 2019 19:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 wSqK7DwBCYKi for ; Mon, 25 Nov 2019 19:33:26 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 8CB2F120877 for ; Mon, 25 Nov 2019 19:33:24 -0800 (PST) Received: from xse219.mail2web.com ([66.113.196.219] helo=xse.mail2web.com) by mx61.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iZRbN-0000BZ-LI for tls@ietf.org; Tue, 26 Nov 2019 04:33:23 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 47MTy827WXzBmn for ; Mon, 25 Nov 2019 19:33:20 -0800 (PST) Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1iZRbM-0004GU-5m for tls@ietf.org; Mon, 25 Nov 2019 19:33:20 -0800 Received: (qmail 4919 invoked from network); 26 Nov 2019 03:33:19 -0000 Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Nov 2019 03:33:19 -0000 To: Rob Sayre , Ben Schwartz Cc: "TLS@ietf.org" References: From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <7424f46b-94e7-02ea-61ae-371d2de9b935@huitema.net> Date: Tue, 26 Nov 2019 11:33:17 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------63AD19B6C01E387566B00641" Content-Language: en-US X-Originating-IP: 66.113.196.219 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.219/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.219/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0VyY7+E5Em8uC8nykI/JrD6pSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4aMFKkHPu4qJeKWCSvJWwxsgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+cXQ2Tc+0CTI43RFdWVZDOJmdySlZou9qHIGOZDEEo7O2nS6C1mWTD2n8BB0gTSSfDtw+Ut ziY+nbU7qa50sEXj8hEv6ylbrSataIASdByf+qyWDcKgIew/Pqmv8CiR0A+Ffy7fEg460Hn2xYnW avStyzAiWbbj13U46jbWFIz21cHX/YzWyFk7762whX3QQ+5uhkPm88V7ziklAaTl19sU919xeAvO xjeQEcL5lNmXdLn4jABaJqtNDIuGYj2WGeveXgFMyx0sD4hRS2uyMFprER9E+btGG8Xk1uugE/FU 4J9TrjYo22Tif+7yfJXbGyN6EipRzMVZ5LqwTx7Vvn9SP+LiFhV9TEgXGI3XmDfDnJdoieX2NtRg +o3kI8QyLIsFNipas5GqVFZmFIt1Sjg0Pwkvbbll52zt8HvoKS2WQAeYUOp7A73HI6oJg7w/Vody ZOdhGVEAXrAmVqtPwyUyf9NQdZeiUucWvclnxK3VdV1677oPXF7r5zsW33ZNlioeEsGOJOKU/kLG nxJMOi7dEw3izQpjIH7RqQYMi47SMNQ84QG89JN6MvpNdzLqW7rTTwb9RWp/sgjYx+Loe+aEHHAS JNUmoOHSoqgqxfHmWRWcrRhLeB34s3hUb32GO+051WK4pJ1Ap5f9j0zhZ67q08QV3No+S2msRDep v5w/kkG0v17AmegcpQ0tml/sN9lmMy/o83jVXTcfb9k0nLWblJy7uxV6dw8jzlsaNZe6hynMJcjx DydxsJEju76A7X1QIVydqXpZ6MHhiKws9Iiut28r9wo4SqUIg8Yh9hAM0n3LLzx/F2gT3wl8JQJv Bho= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [TLS] ESNI: Tracking and blocking via record_digest X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2019 03:33:28 -0000 This is a multi-part message in MIME format. --------------63AD19B6C01E387566B00641 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Actually there is one use case in which the anonymity set is size 1 -- mobile servers. The name of the mobile server cannot be deduced from its temporary address. It can also not be deduced from the ESNI. But it can be deduced from the record digest. The mobile server who wants to maintain privacy will want to use ESNI without a record digest,  at the cost of course of trial decryption. -- Christian Huitema On 11/26/2019 4:37 AM, Rob Sayre wrote: > You're right, this is all there in the draft. It's just scattered > around a bit, and "anonymity set" is used only once and not defined. > > I filed an issue > https://github.com/tlswg/draft-ietf-tls-esni/issues/204 in case the > editors want to consolidate text on this concern. > > thanks, > Rob > > > On Mon, Nov 25, 2019 at 11:25 AM Ben Schwartz > wrote: > > The record_digest, like the ESNIConfig itself, is intended to be > constant across all domains that form an anonymity set (i.e. O(1) > ESNIConfigs per CDN).  Thus, the record_digest reveals no > additional information to an onlooker who can observe the server IP. > > On Mon, Nov 25, 2019 at 2:03 PM Rob Sayre > wrote: > > Hi, > > I see the issue of tracking and blocking via record_digest has > come up a few times in the github repository, but I don't > understand the resolution. > > If someone wanted to observe or block traffic to "example.com > ", couldn't they retrieve the ESNI keys, > calculate the record_digest themselves, and then use that to > spot traffic to "example.com "? > > Is the idea that DNS providers will vary the shared keys? > > thanks, > Rob > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------63AD19B6C01E387566B00641 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Actually there is one use case in which the anonymity set is size 1 -- mobile servers. The name of the mobile server cannot be deduced from its temporary address. It can also not be deduced from the ESNI. But it can be deduced from the record digest. The mobile server who wants to maintain privacy will want to use ESNI without a record digest,  at the cost of course of trial decryption.

-- Christian Huitema

On 11/26/2019 4:37 AM, Rob Sayre wrote:
You're right, this is all there in the draft. It's just scattered around a bit, and "anonymity set" is used only once and not defined.

I filed an issue https://github.com/tlswg/draft-ietf-tls-esni/issues/204 in case the editors want to consolidate text on this concern.

thanks,
Rob


On Mon, Nov 25, 2019 at 11:25 AM Ben Schwartz <bemasc@google.com> wrote:
The record_digest, like the ESNIConfig itself, is intended to be constant across all domains that form an anonymity set (i.e. O(1) ESNIConfigs per CDN).  Thus, the record_digest reveals no additional information to an onlooker who can observe the server IP.

On Mon, Nov 25, 2019 at 2:03 PM Rob Sayre <sayrer@gmail.com> wrote:
Hi,

I see the issue of tracking and blocking via record_digest has come up a few times in the github repository, but I don't understand the resolution.

If someone wanted to observe or block traffic to "example.com", couldn't they retrieve the ESNI keys, calculate the record_digest themselves, and then use that to spot traffic to "example.com"?

Is the idea that DNS providers will vary the shared keys?

thanks,
Rob

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--------------63AD19B6C01E387566B00641-- From nobody Mon Nov 25 19:47:38 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928A1120013 for ; Mon, 25 Nov 2019 19:47:37 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 nqmHbEJ838WX for ; Mon, 25 Nov 2019 19:47:35 -0800 (PST) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 BFBD9120143 for ; Mon, 25 Nov 2019 19:47:35 -0800 (PST) Received: by mail-il1-x130.google.com with SMTP id v17so12445180ilg.7 for ; Mon, 25 Nov 2019 19:47:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+pUGMXSRpiuuj6TbF8wQb0I4yWE0ho5SPuydZAM7UH8=; b=n7l37kjq3zRXVamR4zHiDE0zzqw1b9u+nqgWwTjRT7Wtmvhp9iGhkKpiUosrfCdgaY DwYM1HSSAeWIrX4IGQ650B/Wc1dqlkekVfy2vnsKWbHnxAHjSkIsLQ8DXom+lpdGc4Ix UJ/A2WhgymIZ2KloyrBoRhIPry5/nFz2/uYFZ1TwZSG5L0sHPh1Muz1QZTSLWkEl0V9x 9zDhqsCGZ6ObnoFpE5w2TDBuUmuTNA/dYp6JjW7EyK/nr28rqEC6Cb8wdGCSHwuiRp/s KvMN+cYqjW+hr04jXSx1z7xkhws7Kt61i9d9d8IOJ+/DokhLDb1z0vjc0nIRlGn9v1+v Mm8g== 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=+pUGMXSRpiuuj6TbF8wQb0I4yWE0ho5SPuydZAM7UH8=; b=dDmfXYuDCnW+Rk7YJxqjn2+Sl0Rn40O/45AIaDg3fjaMOIyugENEutcDD3Y8915+3W HuyOI3oiERLcXLzuZaVUN9bEWnEtuuV8N7ZWXpNl9N8x0BgN5GggK//iXYZ3uCAhRY0/ JSvkUZ4mJjkzWFblSeBnOCY+eqQCMY3N1kTR7vB/Pous34BGDKKuO44Yhk05+VGTobDV xn3848b7hub82oV+tbAyNK3Hs/W94In+RUYdlnk59D6MEss7CzBJGIzEkp7Cfiqx00Rs UNklgcEDzjvufIYOkRJCwMe8YlKPstzNRH4MFE8VX2WJdQF0x0kLplh3vDgt7+/ADGZO 8vjA== X-Gm-Message-State: APjAAAW2RHvaUnViRnBrrYIb1aBoa/vHy00a2lJVZM55CVWG6bWRBOPC YCYvEnGdcoPeHaX3byx/10L8R/RZwFvmWilWraE= X-Google-Smtp-Source: APXvYqyx+ZJKI9Skrpo6tALGQ6L+HtXaJuIv7GeHm1wdrToJAm4suGmFwoXOshxWtQZ21+SWYkVqJx0LROQ2DDHZx/M= X-Received: by 2002:a92:8394:: with SMTP id p20mr37625633ilk.73.1574740054886; Mon, 25 Nov 2019 19:47:34 -0800 (PST) MIME-Version: 1.0 References: <7424f46b-94e7-02ea-61ae-371d2de9b935@huitema.net> In-Reply-To: <7424f46b-94e7-02ea-61ae-371d2de9b935@huitema.net> From: Rob Sayre Date: Mon, 25 Nov 2019 19:47:23 -0800 Message-ID: To: Christian Huitema Cc: Ben Schwartz , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000095cd10059837bd19" Archived-At: Subject: Re: [TLS] ESNI: Tracking and blocking via record_digest X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2019 03:47:37 -0000 --00000000000095cd10059837bd19 Content-Type: text/plain; charset="UTF-8" Yes, and this concern is covered well by the draft in GitHub, imho. thanks, Rob On Mon, Nov 25, 2019 at 7:33 PM Christian Huitema wrote: > Actually there is one use case in which the anonymity set is size 1 -- > mobile servers. The name of the mobile server cannot be deduced from its > temporary address. It can also not be deduced from the ESNI. But it can be > deduced from the record digest. The mobile server who wants to maintain > privacy will want to use ESNI without a record digest, at the cost of > course of trial decryption. > > > -- Christian Huitema > On 11/26/2019 4:37 AM, Rob Sayre wrote: > > You're right, this is all there in the draft. It's just scattered around a > bit, and "anonymity set" is used only once and not defined. > > I filed an issue https://github.com/tlswg/draft-ietf-tls-esni/issues/204 > in case the editors want to consolidate text on this concern. > > thanks, > Rob > > > On Mon, Nov 25, 2019 at 11:25 AM Ben Schwartz wrote: > >> The record_digest, like the ESNIConfig itself, is intended to be constant >> across all domains that form an anonymity set (i.e. O(1) ESNIConfigs per >> CDN). Thus, the record_digest reveals no additional information to an >> onlooker who can observe the server IP. >> >> On Mon, Nov 25, 2019 at 2:03 PM Rob Sayre wrote: >> >>> Hi, >>> >>> I see the issue of tracking and blocking via record_digest has come up a >>> few times in the github repository, but I don't understand the resolution. >>> >>> If someone wanted to observe or block traffic to "example.com", >>> couldn't they retrieve the ESNI keys, calculate the record_digest >>> themselves, and then use that to spot traffic to "example.com"? >>> >>> Is the idea that DNS providers will vary the shared keys? >>> >>> thanks, >>> Rob >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> > _______________________________________________ > TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls > > --00000000000095cd10059837bd19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, and this concern is covered well by the draft i= n GitHub, imho.

th= anks,
Rob

<= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Nov 25, 2019 at 7:33 PM Christ= ian Huitema <huitema@huitema.net<= /a>> wrote:
=20 =20 =20

Actually there is one use case in which the anonymity set is size 1 -- mobile servers. The name of the mobile server cannot be deduced from its temporary address. It can also not be deduced from the ESNI. But it can be deduced from the record digest. The mobile server who wants to maintain privacy will want to use ESNI without a record digest,=C2=A0 at the cost of course of trial decryption.


-- Christian Huitema

On 11/26/2019 4:37 AM, Rob Sayre wrote:
=20
You're right, this is all there in the draft. It= 's just scattered around a bit, and "anonymity set" is used = only once and not defined.

I filed an issue https://github.com/tlswg/draft-iet= f-tls-esni/issues/204 in case the editors want to consolidate text on this concern.

thanks,
Rob


On Mon, Nov 25, 2019 at 11:25 AM Ben Schwartz <bemasc@google.com> wrote:
The record_digest, like the ESNIConfig itself, is intended to be constant across all domains that form an anonymity set (i.e. O(1) ESNIConfigs per CDN).=C2=A0 Thus, the record_digest reveals no additional information to an onlooker who can observe the server IP.

On Mon, Nov 25, 2019 at 2:03 PM Rob Sayre <sayrer@gmail.com> wrote:
Hi,

I see the issue of tracking and blocking via record_digest has come up a few times in the github repository, but I don't understand the resolution.

If someone wanted to observe or block traffic to "= ;example.com", co= uldn't they retrieve the ESNI keys, calculate the record_digest themselves, and then use that to spot traffic to "example.com"?

Is the idea that DNS providers will vary the shared keys?

thanks,
Rob

_______________________________________________
TLS mailing list
TLS@ietf.or= g
https://www.ietf.org/mailman/listinfo/tls= 

_______________________________________________
TLS mailing list
TLS@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/tls
--00000000000095cd10059837bd19-- From kxuanobj@gmail.com Tue Nov 26 21:07:21 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3732120B60 for ; Tue, 26 Nov 2019 21:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 e8AAy73w1_C2 for ; Tue, 26 Nov 2019 21:07:20 -0800 (PST) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (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 20415120827 for ; Tue, 26 Nov 2019 21:07:20 -0800 (PST) Received: by mail-vk1-xa30.google.com with SMTP id b64so5119712vkg.0 for ; Tue, 26 Nov 2019 21:07:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ayqav6VHpLykJHhZWpaH+QdK92b29GOpwKS7agPkdYM=; b=sr7i4y9vj5g9ANtvDxaED/BHVH5dTBz8RjIgYZsoHy6uMEDSv6nyFcf2RjoUHVAiR0 pTlN0aEuKokVdFJGvBrqgI3mS5tHOp3TiWdD0L00V7lJQUud7opZvaev08iImo3qjBJb cxBQJQQ7c+pKQIMqi5ThD5LRBkRM39Xh++OMwLJ3/UuxWr68DK49ZMwE9KcRAm0fAxgh SQ73/DWXsiCnUlnyc+hMYJCIT8SJuFP8E2VCHQNlOjl62Re+a1+mwnoPjp13D1TbFfqD 65PEsYCUon/6l5BNuI035TJifoyo7QNlv3GWBky8B9Km17InV/1wT4R/DShikOG9Wv1j ZbyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ayqav6VHpLykJHhZWpaH+QdK92b29GOpwKS7agPkdYM=; b=DDio64ZkXGEN3DHhgn7+OBl41SAvLNWrcmSAFM2RgRs5eXLn21kF2d439W1FVxoCFh 1LiKyPPzdAnQLqW/D/YB38QaoORDNYjxeNgtk+JiSESnLAH4gNEkzPeMAWkxDK6FriAF /+u5svqLMYyPN6fFtYj9o0G2PYH8oI3bxLaaPuUUAvqo82A8PM72OCnNn8w/uqENYNzb ngdqfz+JeFa5r42/vOF+qpVByXPfmtS7hjFvDPTXOHjA/bRQirk+yqseetICHt+icfan 3sPNcm14xZQ5eTW6TkjmAvj9DradZn9q/eymzSnXvn+Hs8uRlxpjBEh7Zg6ZglnXcBGo Q6bA== X-Gm-Message-State: APjAAAWJKVEtYM2m759t6pzg+Nh4K6jgyhBuMj9zjsk1nhgmylHy9fU7 g51U4XP34YULM4KcXMJRSV8gIlFcuwZD3HEln/VSIofY1is= X-Google-Smtp-Source: APXvYqxXfTR+hCGT9DqaHIW2lYqrBjm5EynEXbSOUOUufxevjtqNO/5t8v7DjP7lizMhaRPuU3G0Sm+1pGyQjO3W9Rg= X-Received: by 2002:a05:6122:1181:: with SMTP id x1mr1536250vkn.25.1574831238843; Tue, 26 Nov 2019 21:07:18 -0800 (PST) MIME-Version: 1.0 From: Xuan k Date: Wed, 27 Nov 2019 13:06:42 +0800 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="0000000000009290e505984cf828" Archived-At: Subject: [TLS] [DTLS1.3]About the retransmission of Handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2019 06:05:06 -0000 --0000000000009290e505984cf828 Content-Type: text/plain; charset="UTF-8" Hi all, I'm trying to implement a DTLS1.3 library for embedded devices. But It seems something weird about retransmissions and ACKs. In the section "5.2. DTLS Handshake Message Format": The first message each side transmits in each association always has message_seq = 0. Whenever a new message is generated, the message_seq value is incremented by one. When a message is retransmitted, the old *message_seq value is re-used*, i.e., not incremented. From the perspective of the DTLS record layer, the retransmission is a new record. This record will have a *new* * DTLSPlaintext.sequence_number* value. In the section "7. ACK Message", the ACK message use the record_numbers (corresponds to *DTLSPlaintext.sequence_number*). For my understanding, the "message_seq" belongs to "Handshake" and the "sequence_number" or "record_numbers" belongs to record layer. The retransmission detection is done by "Handshake" using "message_seq", but the "acknowledge" is done by "record layer" using "record_numbers". It is so weird. The retransmission, retransmission detection and acknowledge should be done in handshake process, but we need the record layer passing the record_numebrs to the handshake process. Since a new "sequence_number" is used for retransmission, we have to maintain a "record_numbers" to "message_seq" map with dynamic size. Each retransmission attempt creates a new relationship between a new "record_numbers" to an old "message_seq". Since ACK is only used with Handshake messages, is it possible that we use "message_seq" in ACK messages? Or we use *old* "sequence_number" for retransmission, so we do not need maintain the dynamic map. And if replay detection is implemented, the retransmitted record can be dropped by record layer (by replay detection), the "Handshake Protocol" do not need to do retransmission detection. Thanks Zhai Zhaoxuan --0000000000009290e505984cf828 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I'm trying to implement a D= TLS1.3 library for embedded devices. But It seems something weird about ret= ransmissions and ACKs.

In the section "5.2. D= TLS Handshake Message Format":
=C2=A0 =C2=A0The first message each side= transmits in each association always has
=C2=A0 =C2=A0message_se= q =3D 0.=C2=A0 Whenever a new message is generated, the
=C2=A0 = =C2=A0message_seq value is incremented by one.=C2=A0 When a message is
=C2=A0 =C2=A0retransmitted, the old message_seq value is re-used, i.e., not
=C2=A0 =C2=A0incremented.=C2=A0 From the perspectiv= e of the DTLS record layer, the
=C2=A0 =C2=A0retransmission is a = new record.=C2=A0 This record will have a new
=C2=A0 = =C2=A0DTLSPlaintext.sequence_number value.

<= /div>
In the section "7. ACK Message", the ACK message use th= e record_numbers (corresponds to DTLSPlaintext.sequence_number).
=

For my understanding, the "message_seq&= quot; belongs to "Handshake" and the "sequence_number" = or "record_numbers" belongs to
record layer.
=
The retransmission detection is done by "Handshake"= ; using "message_seq", but the "acknowledge" is done by= "record layer" using "record_numbers".
I= t is so weird.=C2=A0

The retransmission,=C2=A0retr= ansmission detection and=C2=A0acknowledge should be done in handshake proce= ss, but we need the record layer passing the
record_numebrs to th= e handshake process.

Since a new "sequence_nu= mber" is used for retransmission, we have to maintain a "record_n= umbers" to "message_seq" map with dynamic size.
Each retransmission attempt creates a new relationship between a ne= w "record_numbers" to an old "message_seq".
<= br>
Since ACK is only used with Handshake messages, is it possibl= e that we use "message_seq" in ACK messages?
Or we = use old "sequence_number" for retransmission, so we do not= need maintain the dynamic map. And if replay detection is implemented, the= retransmitted
record can be dropped by record layer (by repl= ay detection), the "Handshake Protocol" do not need to do=C2=A0re= transmission detection.

Thanks
Zhai Zhao= xuan
--0000000000009290e505984cf828-- From nobody Wed Nov 27 01:41:28 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01035120846; Wed, 27 Nov 2019 01:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P98nIG6zO2jC; Wed, 27 Nov 2019 01:41:24 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83345120821; Wed, 27 Nov 2019 01:41:24 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 47NG4L1L6Hz5vpM; Wed, 27 Nov 2019 10:41:22 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.42]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 47NG4L0Q8Jz1xnY; Wed, 27 Nov 2019 10:41:22 +0100 (CET) Received: from OPEXCAUBM21.corporate.adroot.infra.ftgroup ([fe80::d42b:2e80:86c2:5905]) by OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Wed, 27 Nov 2019 10:41:21 +0100 From: To: "tls@ietf.org" CC: "draft-ietf-lpwan-ipv6-static-context-hc@ietf.org" Thread-Topic: SCHC header compression Thread-Index: AQHVpQbTxc63kmL74UKyHoIcblrViQ== Date: Wed, 27 Nov 2019 09:41:21 +0000 Message-ID: <19292_1574847682_5DDE44C2_19292_136_3_DA040352.6C797%dominique.barthel@orange.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_DA0403526C797dominiquebarthelorangecom_" MIME-Version: 1.0 Archived-At: Subject: [TLS] SCHC header compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2019 09:41:27 -0000 --_000_DA0403526C797dominiquebarthelorangecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gSGFubmVzLCBhbGwsDQoNCkknbSBhIGNvLWF1dGhvciBvZiB0aGUgU0NIQyBkcmFmdCAo aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1scHdhbi1pcHY2LXN0 YXRpYy1jb250ZXh0LWhjLyksIHdoaWNoIGhhcyBwYXNzZWQgSUVTRyByZXZpZXcuDQoNCkkgbWF5 IGJlIHVuZm9ydHVuYXRlIHRoYXQgdGhlIGRyYWZ0IGNvbnRhaW5zIDMgZGlzdGluY3QgZGVsaXZl cmFibGVzIGluIG9uZSBkb2N1bWVudA0KDQotIGEgZ2VuZXJpYyBoZWFkZXIgY29tcHJlc3Npb24g bWVjaGFuaXNtLCB3aGljaCB1c2VzIGEgc3RhdGljIGNvbnRleHQgZm9yIGNvbXByZXNzaW9uIChT dGF0aWMgQ29udGV4dCBIZWFkZXIgQ29tcHJlc3Npb24gPSBTQ0hDKSAoU2VjdGlvbiA3KQ0KDQot IGEgZnJhZ21lbnRhdGlvbiBwcm90b2NvbCwgd2hpY2ggY29tZXMgaW4gMyBmbGF2b3JzLCBzb21l IG9mIHdoaWNoIGhhdmUgYWNrL3JldHJhbnNtaXNzaW9ucyBidWlsdC1pbi4gKFNlY3Rpb24gOCkN Cg0KLSBhbiBhcHBsaWNhdGlvbiBvZiB0aGUgY29tcHJlc3Npb24gbWVjaGFuaXNtIHRvIGNvbXBy ZXNzIFVEUCtJUHY2IGhlYWRlcnMgKFNlY3Rpb24gMTApDQoNClRoaXMgc2l0dWF0aW9uIG1heSBs ZWFkIHRvIHRoZSBjb25jbHVzaW9uIHRoYXQgdGhlIGhlYWRlciBjb21wcmVzc2lvbiBhbmQgZnJh Z21lbnRhdGlvbiB3b3JrIHRvZ2V0aGVyLCBvciB0aGF0IFNDSEMgb25seSBhcHBsaWVzIHRvIFVE UCtJUHY2IGhlYWRlcnMuDQoNClRoZSB0cnV0aCBpcyBkaWZmZXJlbnQuDQoNClRoZSBkcmFmdCBj bGVhcmx5IHN0YXRlcyB0aGF0IGZyYWdtZW50YXRpb24gaXMgb3B0aW9uYWw6ICJJZiBuZWVkZWQg YnkgdGhlIHVuZGVybHlpbmcgbGF5ZXIsIHRoZSBvcHRpb25hbCBTQ0hDIEZyYWdtZW50YXRpb24g TUFZIGJlIGFwcGxpZWQgdG8gdGhlIFNDSEMgUGFja2V0LiINCg0KVHlwaWNhbGx5LCBzb21lIGxv d2VyIGxheWVycyBhbHJlYWR5IGhhdmUgYSBmcmFnbWVudGF0aW9uIG1lY2hhbmlzbSAoZS5nLiBO Qi1Jb1QpLCBhbmQgZG9uJ3QgbmVlZCBhbm90aGVyIG9uZS4NCg0KQXMgYW5vdGhlciBkYXRhIHBv aW50LCB3ZSBoYXZlIGEgZGVtbyBzaG93aW5nIHRoZSBiZW5lZml0cyBvZiBjb21wcmVzc2luZyBD b0FQIGhlYWRlcnMsIG92ZXIgYSBuYXRpdmVseS1JUCBuZXR3b3JrIChMVEUtbSkuIFdlIG9ubHkg dXNlIHRoZSBnZW5lcmljIGNvbXByZXNzaW9uIG1lY2hhbmlzbSBvZiB0aGUgYWJvdmUtbWVudGlv bmVkIGRyYWZ0LCBhbmQgd2Ugb25seSB1c2UgaXQgdG8gY29tcHJlc3MgdGhlIENvQVAgaGVhZGVy cy4NCg0KV2UgYmVsaWV2ZSB0aGF0IG90aGVyIHByb3RvY29scyBjb3VsZCBiZW5lZml0IGZyb20g dGhlIGdlbmVyaWMgaGVhZGVyIGNvbXByZXNzaW9uIGZyYW1ld29yayBlc3RhYmxpc2hlZCBieSBT Q0hDIGFuZCBjb3VsZCBzYXZlIGRlc2lnbiB0aW1lIGFuZCBjb2RlIHNpemUgYnkgaW5zdGFudGlh dGluZyBhIHNldCBvZiBTQ0hDIGNvbXByZXNzaW9uIHJ1bGVzIGZvciB0aGVpciBvd24gaGVhZGVy cy4NCg0KSWYgeW91IGFyZSBpbnRlcmVzdGVkLCB3ZSdkIGJlIGhhcHB5IHRvIHRlbGwgeW91IGEg Yml0IG1vcmUgYWJvdXQgU0NIQywgZWl0aGVyIGF0IGFuIHVwY29taW5nIElFVEYgbWVldGluZyBv ciBkdXJpbmcgYSBkZWRpY2F0ZWQgY29uZiBjYWxsLg0KDQpCZXN0IHJlZ2FyZHMsDQoNCg0KRG9t aW5pcXVlDQoNCj4gSGkgSGFubmVzLA0KPg0KPiBNeSByZWFkaW5nIGlzIHRoYXQgb25seSBjb21w cmVzc2lvbi9kZWNvbXByZXNzaW9uIGFwcGxpZXMgdG8gb3VyIGNhc2UuDQo+IEZyYWdtZW50YXRp b24gaXMgb3B0aW9uYWwgYW5kIG9ubHkgY29uY2VybnMgaXB2Ni4gSSBkaWQgbm90IGludGVudCB0 byBtYWtlDQo+IHRoZSBjb21tZW50IGF0IGFuIGluYXBwcm9wcmlhdGUgdGltZSwgYnV0IGlmIHNv LCBwbGVhc2UgY29uc2lkZXIgaXQgd2hlbiBpdA0KPiBpcyBhcHByb3ByaWF0ZS4NCj4NCj4gWW91 cnMsDQo+IERhbmllbA0KPg0KPiBPbiBUaHUsIE5vdiAyMSwgMjAxOSBhdCAxMDozNCBQTSA8SGFu bmVzLlRzY2hvZmVuaWdAZ214Lm5ldD48bWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQm Z3Q+OyB3cm90ZToNCj4NCj4gSGkgRGFuaWVsDQo+DQo+DQo+DQo+IEFsdGhvdWdoIGluYXBwcm9w cmlhdGUgdG8gZGlzY3VzcyBhdCB0aGUgdGltZSBvZiB0aGUgYWRvcHRpb24gY2FsbCBJDQo+IHdh bnRlZCB0byBwb2ludCBvdXQgdGhhdCBJIGxvb2tlZCBhdCBTQ0hDIGFuZCB3YXMgc3VycHJpc2Vk IHRvIGxlYXJuIHRoYXQNCj4gaXQgaXMgbW9yZSB0aGFuIGEgY29tcHJlc3Npb24gc2NoZW1lIGJ1 dCBhbHNvIGluY2x1ZGVzIGEgcHJvdG9jb2wgZm9yDQo+IGFkZGluZyByZWxpYWJpbGl0eS4gSW4g bXkgcmVhZGluZyBpcyBlc3NlbnRpYWxseSBhIHJlcGxhY2VtZW50IGZvciA2bG93cGFuLg0KPiBV bmZvcnR1bmF0ZWx5LCB0aGlzIGRlc2lnbiBkZWNpc2lvbiBkb2VzIG5vdCBtYWtlIGl0IGEgd2Vs bCBzdWl0ZWQNCj4gbWVjaGFuaXNtIGZvciBhIGdlbmVyaWMgY29tcHJlc3Npb24gbWVjaGFuaXNt LiBJIGFtIGhhcHB5IHRvIGdldCBjb252aW5jZWQNCj4gb3RoZXJ3aXNlLg0KPg0KPg0KPg0KPiBD aWFvDQo+DQo+IEhhbm5lcw0KPg0KPg0KPg0KPiAqRnJvbToqIFRMUyA8dGxzLWJvdW5jZXNAaWV0 Zi5vcmc+PG1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZyZndD47ICpPbiBCZWhhbGYgT2YgKkRh bmllbCBNaWdhdWx0DQo+ICpTZW50OiogRnJpZGF5LCBOb3ZlbWJlciAyMiwgMjAxOSAxMDoyMCBB TQ0KPiAqVG86KiBQYW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkgPHBrYW1wYW5hQGNpc2NvLmNv bT48bWFpbHRvOnBrYW1wYW5hQGNpc2NvLmNvbSZndD47DQo+ICpDYzoqIFRMUyBMaXN0IDx0bHNA aWV0Zi5vcmc+PG1haWx0bzp0bHNAaWV0Zi5vcmcmZ3Q+Ow0KPiAqU3ViamVjdDoqIFJlOiBbVExT XSBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1yZXNjb3JsYS10bHMtY3Rscw0KPg0KPg0KPg0KPiBJ IGNsZWFybHkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhlIHdvcmssIGJ1dCBpdCBzZWVtcyBp bXBvcnRhbnQgdG8NCj4gZW5zdXJlIGNUTFMgaW50ZWdyYXRlcyBvciByZW1haW5zIGluIGxpbmUg d2l0aCB0aGUgd29yayBvbiBjb21wcmVzc2lvbiB0aGF0DQo+IGhhcyBiZWVuIGFjY29tcGxpc2hl ZCBhdCB0aGUgSUVURiAtIFNDSEMgZGVmaW5lZCBpbiBscHdhbiBtaWdodCBiZSBhDQo+IHN0YXJ0 aW5nIHBvaW50LiBJdCBhbHNvIHNlZW1zIGltcG9ydGFudCB0byBtZSB0aGF0IGNUTFMgZGVmaW5l cyBtZWNoYW5pc21zDQo+IHRoYXQgY291bGQgYmUgcmV1c2VkIGFzIFRMUyAxLjMgZXZvbHZlcy4N Cj4NCj4NCj4NCj4gWW91cnMsDQo+DQo+IERhbmllbA0KCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBk aWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh dmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwn ZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBM ZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9u LApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRl IGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZv cm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUg ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWls cyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQg aGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_DA0403526C797dominiquebarthelorangecom_ Content-Type: text/html; charset="utf-8" Content-ID: <947761538506274D8E1B313F2F10A3D3@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPHByZSBjbGFzcz0id29y ZHdyYXAiPjxkaXY+SGVsbG8gSGFubmVzLCBhbGwsPC9kaXY+PC9wcmU+DQo8cHJlIGNsYXNzPSJ3 b3Jkd3JhcCI+SSdtIGEgY28tYXV0aG9yIG9mIHRoZSBTQ0hDIGRyYWZ0ICg8YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWxwd2FuLWlwdjYtc3RhdGlj LWNvbnRleHQtaGMvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LWxwd2FuLWlwdjYtc3RhdGljLWNvbnRleHQtaGMvPC9hPiksIHdoaWNoIGhhcyBwYXNzZWQgSUVT RyByZXZpZXcuPC9wcmU+DQo8cHJlIGNsYXNzPSJ3b3Jkd3JhcCI+SSBtYXkgYmUgdW5mb3J0dW5h dGUgdGhhdCB0aGUgZHJhZnQgY29udGFpbnMgMyBkaXN0aW5jdCBkZWxpdmVyYWJsZXMgaW4gb25l IGRvY3VtZW50PC9wcmU+DQo8ZGl2Pg0KPHByZSBjbGFzcz0id29yZHdyYXAiPi0gYSBnZW5lcmlj IGhlYWRlciBjb21wcmVzc2lvbiBtZWNoYW5pc20sIHdoaWNoIHVzZXMgYSBzdGF0aWMgY29udGV4 dCBmb3IgY29tcHJlc3Npb24gKFN0YXRpYyBDb250ZXh0IEhlYWRlciBDb21wcmVzc2lvbiA9IFND SEMpIChTZWN0aW9uIDcpPC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIGNsYXNzPSJ3b3Jkd3Jh cCI+LSBhIGZyYWdtZW50YXRpb24gcHJvdG9jb2wsIHdoaWNoIGNvbWVzIGluIDMgZmxhdm9ycywg c29tZSBvZiB3aGljaCBoYXZlIGFjay9yZXRyYW5zbWlzc2lvbnMgYnVpbHQtaW4uIChTZWN0aW9u IDgpPC9wcmU+DQo8cHJlIGNsYXNzPSJ3b3Jkd3JhcCI+LSBhbiBhcHBsaWNhdGlvbiBvZiB0aGUg Y29tcHJlc3Npb24gbWVjaGFuaXNtIHRvIGNvbXByZXNzIFVEUCYjNDM7SVB2NiBoZWFkZXJzIChT ZWN0aW9uIDEwKTwvcHJlPg0KPC9kaXY+DQo8cHJlIGNsYXNzPSJ3b3Jkd3JhcCI+VGhpcyBzaXR1 YXRpb24gbWF5IGxlYWQgdG8gdGhlIGNvbmNsdXNpb24gdGhhdCB0aGUgaGVhZGVyIGNvbXByZXNz aW9uIGFuZCBmcmFnbWVudGF0aW9uIHdvcmsgdG9nZXRoZXIsIG9yIHRoYXQgU0NIQyBvbmx5IGFw cGxpZXMgdG8gVURQJiM0MztJUHY2IGhlYWRlcnMuPC9wcmU+DQo8cHJlIGNsYXNzPSJ3b3Jkd3Jh cCI+VGhlIHRydXRoIGlzIGRpZmZlcmVudC48L3ByZT4NCjxwcmUgY2xhc3M9IndvcmR3cmFwIj5U aGUgZHJhZnQgY2xlYXJseSBzdGF0ZXMgdGhhdCBmcmFnbWVudGF0aW9uIGlzIG9wdGlvbmFsOiAm cXVvdDtJZiBuZWVkZWQgYnkgdGhlIHVuZGVybHlpbmcgbGF5ZXIsIHRoZSBvcHRpb25hbCBTQ0hD IEZyYWdtZW50YXRpb24gTUFZIGJlIGFwcGxpZWQgdG8gdGhlIFNDSEMgUGFja2V0LiZxdW90Ozwv cHJlPg0KPHByZSBjbGFzcz0id29yZHdyYXAiPlR5cGljYWxseSwgc29tZSBsb3dlciBsYXllcnMg YWxyZWFkeSBoYXZlIGEgZnJhZ21lbnRhdGlvbiBtZWNoYW5pc20gKGUuZy4gTkItSW9UKSwgYW5k IGRvbid0IG5lZWQgYW5vdGhlciBvbmUuPC9wcmU+DQo8cHJlIGNsYXNzPSJ3b3Jkd3JhcCI+QXMg YW5vdGhlciBkYXRhIHBvaW50LCB3ZSBoYXZlIGEgZGVtbyBzaG93aW5nIHRoZSBiZW5lZml0cyBv ZiBjb21wcmVzc2luZyBDb0FQIGhlYWRlcnMsIG92ZXIgYSBuYXRpdmVseS1JUCBuZXR3b3JrIChM VEUtbSkuIFdlIG9ubHkgdXNlIHRoZSBnZW5lcmljIGNvbXByZXNzaW9uIG1lY2hhbmlzbSBvZiB0 aGUgYWJvdmUtbWVudGlvbmVkIGRyYWZ0LCBhbmQgd2Ugb25seSB1c2UgaXQgdG8gY29tcHJlc3Mg dGhlIENvQVAgaGVhZGVycy48L3ByZT4NCjxwcmUgY2xhc3M9IndvcmR3cmFwIj5XZSBiZWxpZXZl IHRoYXQgb3RoZXIgcHJvdG9jb2xzIGNvdWxkIGJlbmVmaXQgZnJvbSB0aGUgZ2VuZXJpYyBoZWFk ZXIgY29tcHJlc3Npb24gZnJhbWV3b3JrIGVzdGFibGlzaGVkIGJ5IFNDSEMgYW5kIGNvdWxkIHNh dmUgZGVzaWduIHRpbWUgYW5kIGNvZGUgc2l6ZSBieSBpbnN0YW50aWF0aW5nIGEgc2V0IG9mIFND SEMgY29tcHJlc3Npb24gcnVsZXMgZm9yIHRoZWlyIG93biBoZWFkZXJzLjwvcHJlPg0KPHByZSBj bGFzcz0id29yZHdyYXAiPklmIHlvdSBhcmUgaW50ZXJlc3RlZCwgd2UnZCBiZSBoYXBweSB0byB0 ZWxsIHlvdSBhIGJpdCBtb3JlIGFib3V0IFNDSEMsIGVpdGhlciBhdCBhbiB1cGNvbWluZyBJRVRG IG1lZXRpbmcgb3IgZHVyaW5nIGEgZGVkaWNhdGVkIGNvbmYgY2FsbC48L3ByZT4NCjxwcmUgY2xh c3M9IndvcmR3cmFwIj5CZXN0IHJlZ2FyZHMsPC9wcmU+DQo8cHJlIGNsYXNzPSJ3b3Jkd3JhcCI+ PGJyPjwvcHJlPg0KPHByZSBjbGFzcz0id29yZHdyYXAiPkRvbWluaXF1ZTwvcHJlPg0KPHByZSBj bGFzcz0id29yZHdyYXAiPiZndDsgSGkgSGFubmVzLA0KJmd0Ow0KJmd0OyBNeSByZWFkaW5nIGlz IHRoYXQgb25seSBjb21wcmVzc2lvbi9kZWNvbXByZXNzaW9uIGFwcGxpZXMgdG8gb3VyIGNhc2Uu DQomZ3Q7IEZyYWdtZW50YXRpb24gaXMgb3B0aW9uYWwgYW5kIG9ubHkgY29uY2VybnMgaXB2Ni4g SSBkaWQgbm90IGludGVudCB0byBtYWtlDQomZ3Q7IHRoZSBjb21tZW50IGF0IGFuIGluYXBwcm9w cmlhdGUgdGltZSwgYnV0IGlmIHNvLCBwbGVhc2UgY29uc2lkZXIgaXQgd2hlbiBpdA0KJmd0OyBp cyBhcHByb3ByaWF0ZS4NCiZndDsgDQomZ3Q7IFlvdXJzLA0KJmd0OyBEYW5pZWwNCiZndDsgDQom Z3Q7IE9uIFRodSwgTm92IDIxLCAyMDE5IGF0IDEwOjM0IFBNICZsdDs8YSBocmVmPSJtYWlsdG86 SGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldCZhbXA7Z3QiPkhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5u ZXQmZ3Q7PC9hPjsgd3JvdGU6DQomZ3Q7DQomZ3Q7IEhpIERhbmllbA0KJmd0Ow0KJmd0Ow0KJmd0 Ow0KJmd0OyBBbHRob3VnaCBpbmFwcHJvcHJpYXRlIHRvIGRpc2N1c3MgYXQgdGhlIHRpbWUgb2Yg dGhlIGFkb3B0aW9uIGNhbGwgSQ0KJmd0OyB3YW50ZWQgdG8gcG9pbnQgb3V0IHRoYXQgSSBsb29r ZWQgYXQgU0NIQyBhbmQgd2FzIHN1cnByaXNlZCB0byBsZWFybiB0aGF0DQomZ3Q7IGl0IGlzIG1v cmUgdGhhbiBhIGNvbXByZXNzaW9uIHNjaGVtZSBidXQgYWxzbyBpbmNsdWRlcyBhIHByb3RvY29s IGZvcg0KJmd0OyBhZGRpbmcgcmVsaWFiaWxpdHkuIEluIG15IHJlYWRpbmcgaXMgZXNzZW50aWFs bHkgYSByZXBsYWNlbWVudCBmb3IgNmxvd3Bhbi4NCiZndDsgVW5mb3J0dW5hdGVseSwgdGhpcyBk ZXNpZ24gZGVjaXNpb24gZG9lcyBub3QgbWFrZSBpdCBhIHdlbGwgc3VpdGVkDQomZ3Q7IG1lY2hh bmlzbSBmb3IgYSBnZW5lcmljIGNvbXByZXNzaW9uIG1lY2hhbmlzbS4gSSBhbSBoYXBweSB0byBn ZXQgY29udmluY2VkDQomZ3Q7IG90aGVyd2lzZS4NCiZndDsNCiZndDsNCiZndDsNCiZndDsgQ2lh bw0KJmd0Ow0KJmd0OyBIYW5uZXMNCiZndDsNCiZndDsNCiZndDsNCiZndDsgKkZyb206KiBUTFMg Jmx0OzxhIGhyZWY9Im1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZyZhbXA7Z3QiPnRscy1ib3Vu Y2VzQGlldGYub3JnJmd0OzwvYT47ICpPbiBCZWhhbGYgT2YgKkRhbmllbCBNaWdhdWx0DQomZ3Q7 ICpTZW50OiogRnJpZGF5LCBOb3ZlbWJlciAyMiwgMjAxOSAxMDoyMCBBTQ0KJmd0OyAqVG86KiBQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkgJmx0OzxhIGhyZWY9Im1haWx0bzpwa2FtcGFuYUBj aXNjby5jb20mYW1wO2d0Ij5wa2FtcGFuYUBjaXNjby5jb20mZ3Q7PC9hPjsNCiZndDsgKkNjOiog VExTIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzp0bHNAaWV0Zi5vcmcmYW1wO2d0Ij50bHNAaWV0 Zi5vcmcmZ3Q7PC9hPjsNCiZndDsgKlN1YmplY3Q6KiBSZTogW1RMU10gQWRvcHRpb24gY2FsbCBm b3IgZHJhZnQtcmVzY29ybGEtdGxzLWN0bHMNCiZndDsNCiZndDsNCiZndDsNCiZndDsgSSBjbGVh cmx5IHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoZSB3b3JrLCBidXQgaXQgc2VlbXMgaW1wb3J0 YW50IHRvDQomZ3Q7IGVuc3VyZSBjVExTIGludGVncmF0ZXMgb3IgcmVtYWlucyBpbiBsaW5lIHdp dGggdGhlIHdvcmsgb24gY29tcHJlc3Npb24gdGhhdA0KJmd0OyBoYXMgYmVlbiBhY2NvbXBsaXNo ZWQgYXQgdGhlIElFVEYgLSBTQ0hDIGRlZmluZWQgaW4gbHB3YW4gbWlnaHQgYmUgYQ0KJmd0OyBz dGFydGluZyBwb2ludC4gSXQgYWxzbyBzZWVtcyBpbXBvcnRhbnQgdG8gbWUgdGhhdCBjVExTIGRl ZmluZXMgbWVjaGFuaXNtcw0KJmd0OyB0aGF0IGNvdWxkIGJlIHJldXNlZCBhcyBUTFMgMS4zIGV2 b2x2ZXMuDQomZ3Q7DQomZ3Q7DQomZ3Q7DQomZ3Q7IFlvdXJzLA0KJmd0Ow0KJmd0OyBEYW5pZWw8 L3ByZT4NCjxQUkU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1 dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxl Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3Ug Y29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBh ciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1 aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlx dWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRl IHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZh bHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHBy b3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFu Z2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNo YW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DA0403526C797dominiquebarthelorangecom_-- From nobody Wed Nov 27 13:37:54 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98D6120AC1 for ; Wed, 27 Nov 2019 13:37:52 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 MZKjse8QtZ0N for ; Wed, 27 Nov 2019 13:37:50 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 31DA51209E3 for ; Wed, 27 Nov 2019 13:37:50 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id d5so26105735ljl.4 for ; Wed, 27 Nov 2019 13:37:50 -0800 (PST) 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=hQOGlchDPccE9g9J3xWgfxZzttllpUu0S70IYu6g3qY=; b=QTiuZ0TLiRpjymUkLJu2eywUf8wQdKFRRI9bgmNJnr8Bxf23V/qtfL8VWOuJlxTtQ7 O/3xDnYXkIGu/zICYPnW1ZJWyuT9cxysNg8Dq4HmbJoJiolyqg8G/pTgXO8Nckz0GHdh SEMvLysm5vuEK+Zh86cdVRL3ZZYqcfQEDl9oTrm6s+f5eE0A3yoLK/gTqtHkU4IlnSl7 hSnj0ohRbCLl4vxN7ssJBom56u18XI5qNU6vpOwlG6t9RsjQcZ3mGqlXll9FK98e3k3q JKG0Ek+griozWKbhIlu25/UN0iWDpA5XyL7+6mzFDhso58r5QurEWNnnsJ95qVX2TOnV Z+aw== 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=hQOGlchDPccE9g9J3xWgfxZzttllpUu0S70IYu6g3qY=; b=oCihXCqHNajtQC9zPdQ/bAm2NFK2sbO2sexODHO+xJFGKiW4Zb+mjdmhia1pCCK/rY 3675hZCxumo1HG2Zd30o1lu2fNdDdSDrd/x626k1wmVvxxJIYgZpsqRWJ/lNjbMF4Hi+ +bRl6v6gx+FmzljIsHU9tMcVQutKhEpad3CQxIKxNJvwx6XEEmOjK/X6/3DUPlZyBG9X uXaNs1RykIhoqIZvqqURKQtUNdkvo0QS9xIaxywcQabrDFIE7vkjkQ/4911MPF9j+PIK bdO1s3UDvCV01cC60O3vJW45/atBJBwKwgY00jXnlpTq3lEIp8dX58sDcFvkA2+Vufah NFZw== X-Gm-Message-State: APjAAAUOJvZte6+pNtqRjwWzeCRJqelE+B+q0E6ms+0OM5Q3ooN1vpxB U0pj8I/T+17WsifK3tonYUahtswG0NqLyZ/ZwsA0gQ== X-Google-Smtp-Source: APXvYqzReae0e+BmA5S59DnJ01yJ7r9lUHganWghu3Aw8TgIBimNIj18LRLFBy80CyeVaTx58gRTeD/rs1/Fxv4SYn0= X-Received: by 2002:a2e:9842:: with SMTP id e2mr31939623ljj.93.1574890668453; Wed, 27 Nov 2019 13:37:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Wed, 27 Nov 2019 13:37:12 -0800 Message-ID: To: Xuan k Cc: "" Content-Type: multipart/alternative; boundary="000000000000da89c205985ace63" Archived-At: Subject: Re: [TLS] [DTLS1.3]About the retransmission of Handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2019 21:37:53 -0000 --000000000000da89c205985ace63 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 26, 2019 at 10:05 PM Xuan k wrote: > Hi all, > > I'm trying to implement a DTLS1.3 library for embedded devices. But It > seems something weird about retransmissions and ACKs. > > In the section "5.2. DTLS Handshake Message Format": > > The first message each side transmits in each association always has > message_seq = 0. Whenever a new message is generated, the > message_seq value is incremented by one. When a message is > retransmitted, the old *message_seq value is re-used*, i.e., not > incremented. From the perspective of the DTLS record layer, the > retransmission is a new record. This record will have a *new* > * DTLSPlaintext.sequence_number* value. > > > In the section "7. ACK Message", the ACK message use the record_numbers > (corresponds to *DTLSPlaintext.sequence_number*). > > For my understanding, the "message_seq" belongs to "Handshake" and the > "sequence_number" or "record_numbers" belongs to > record layer. > Yes. The retransmission detection is done by "Handshake" using "message_seq", > but the "acknowledge" is done by "record layer" using "record_numbers". > It is so weird. > Hmm... I don't think that this is particularly weird. This is, for instance, how QUIC stream acknowledgement and retransmission works. The retransmission, retransmission detection and acknowledge should be done > in handshake process, but we need the record layer passing the > record_numebrs to the handshake process. > > Since a new "sequence_number" is used for retransmission, we have to > maintain a "record_numbers" to "message_seq" map with dynamic size. > Each retransmission attempt creates a new relationship between a new > "record_numbers" to an old "message_seq". > Yes, that's how it works in NSS. Since ACK is only used with Handshake messages, is it possible that we use > "message_seq" in ACK messages? > Or we use *old* "sequence_number" for retransmission, > Both of these give you strictly less information about the network. One of the cool innovations in QUIC is to label each packet separately so you can determine whether an ACK is an ACK of the original packet or a retransmit. We are trying to inherit tha there -Ekr so we do not need maintain the dynamic map. And if replay detection is > implemented, the retransmitted > record can be dropped by record layer (by replay detection), the > "Handshake Protocol" do not need to do retransmission detection. > > Thanks > Zhai Zhaoxuan > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000da89c205985ace63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 26, 2019 at 10:05 PM Xuan= k <kxuanobj@gmail.com> wro= te:
Hi all,

I'm trying to implement a DTLS1.3 libra= ry for embedded devices. But It seems something weird about retransmissions= and ACKs.

In the section "5.2. DTLS Handshak= e Message Format":
=C2=A0 =C2=A0The first message each sid= e transmits in each association always has
=C2=A0 =C2=A0message_s= eq =3D 0.=C2=A0 Whenever a new message is generated, the
=C2=A0 = =C2=A0message_seq value is incremented by one.=C2=A0 When a message is
=C2=A0 =C2=A0retransmitted, the old message_seq value is re-used, i.e., not
=C2=A0 =C2=A0incremented.=C2=A0 From the perspectiv= e of the DTLS record layer, the
=C2=A0 =C2=A0retransmission is a = new record.=C2=A0 This record will have a new
=C2=A0 = =C2=A0DTLSPlaintext.sequence_number value.

<= /div>
In the section "7. ACK Message", the ACK message use th= e record_numbers (corresponds to DTLSPlaintext.sequence_number).
=

For my understanding, the "message_seq&= quot; belongs to "Handshake" and the "sequence_number" = or "record_numbers" belongs to
record layer.

Yes.

The ret= ransmission detection is done by "Handshake" using "message_= seq", but the "acknowledge" is done by "record layer&qu= ot; using "record_numbers".
It is so weird.=C2=A0

Hmm... I don't think t= hat this is particularly weird. This is, for instance, how QUIC stream ackn= owledgement and retransmission works.


= The retransmission,=C2=A0retransmission detection and=C2=A0acknowledge shou= ld be done in handshake process, but we need the record layer passing the
record_numebrs to the handshake process.

= Since a new "sequence_number" is used for retransmission, we have= to maintain a "record_numbers" to "message_seq" map wi= th dynamic size.
Each retransmission attempt creates a = new relationship between a new "record_numbers" to an old "m= essage_seq".

Yes, that'= ;s how it works in NSS.


Since ACK is on= ly used with Handshake messages, is it possible that we use "message_s= eq" in ACK messages?
Or we use old &qu= ot;sequence_number" for retransmission,
<= br>
Both of these give you strictly less information about the ne= twork. One of the cool innovations in QUIC is to label each packet separate= ly so you can determine whether an ACK is an ACK of the original packet or = a retransmit. We are trying to inherit tha there

-= Ekr

<= div dir=3D"ltr">
so we do not need maintain the dynamic map. And if re= play detection is implemented, the retransmitted
record can b= e dropped by record layer (by replay detection), the "Handshake Protoc= ol" do not need to do=C2=A0retransmission detection.

Thanks
Zhai Zhaoxuan
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000da89c205985ace63-- From nobody Wed Nov 27 23:16:20 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997D9120C61 for ; Wed, 27 Nov 2019 23:16:18 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 paWetKAVLYzJ for ; Wed, 27 Nov 2019 23:16:16 -0800 (PST) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 06E5F120C62 for ; Wed, 27 Nov 2019 23:16:16 -0800 (PST) Received: by mail-vs1-xe2c.google.com with SMTP id y195so3106645vsy.5 for ; Wed, 27 Nov 2019 23:16:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GhLWwDx1su25KMizyw4oLWcEgBw99S3k5NCNxrih3IA=; b=DicQvLklEEvl/9e5ia1OUbAj0SoXSGDnShE4jliFC0CzTg/k8X9CDF3SHoqH/Y98hi XgWg2ebgu7LzzsS9hqpQsLaO9PsY5zSHtx1TErSJ5tr/htwTVD5lrPTAOYL12xMTaHf3 qTtB94I/MovMsW1WID1jroDR1Rbrz6Tt1NYiJn8vtIKWdqF9S1QkcwrCVOs88yNIRS7V 4TjxrEcVl4BMrn6Oc8rMZL1/FVR95y9O8fll/Jz4byASxhngK46N5A3ix3hqWzZYgFQl Mvi3KAVSq6zTHu3O0d3NlHFb3r8nRtJvr1g0FqWKLP4EgpaWDE7sf04piXbFxyGkgtOl 5SGQ== 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=GhLWwDx1su25KMizyw4oLWcEgBw99S3k5NCNxrih3IA=; b=Il68LV+xSE0m9/kjXzNxk2tfbRcHmgnGJdt55pHNLnaOalvZTalt9X4kE+wyzzZXH5 30sQ7UeerwMcI7vueWYkY++VCeKsEAnGtnMX/qsi/1J10mzkCnn8JIROjlDy7WcbJZxk TM9VegrR2rJNvhKwb1rO3rmpdT3NkmDJtL/SaR5TM8ti2BjUedszky67tm7vezjT+Jj0 iNpp52zjCahCxeuE4EXLnROG270bN2nVzfxJ/dii8UmiJgjytK4MTVewcqjq/mf4QNyL PUkeeOcvOuDykFPI6L3tDKklV+rYH/pP9WrrKcqMhaWyZJGy1JlHyGuCJuO3QWoNNht7 G4FQ== X-Gm-Message-State: APjAAAUQtmecBmr+GLIzoM4mbCQZj8pW8eR5Ge3QJyZYmglUTOi9H5ZZ LyqHg2+cAyat5j3knR2t9MIPanZvy8AgNx1LNk/iMRuS8TQ= X-Google-Smtp-Source: APXvYqyfftMxbLmWq788YI9Ir7gFxi55mQJdbxVHpkTtf0KgtFCVUIm5ML98vDo3EXgiqaItQEdfbsdIaBR4VXV9GPk= X-Received: by 2002:a67:d396:: with SMTP id b22mr7240917vsj.195.1574925374829; Wed, 27 Nov 2019 23:16:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Xuan k Date: Thu, 28 Nov 2019 15:15:38 +0800 Message-ID: To: Eric Rescorla Cc: "" Content-Type: multipart/alternative; boundary="00000000000083c58b059862e3f9" Archived-At: Subject: Re: [TLS] [DTLS1.3]About the retransmission of Handshake records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2019 07:16:18 -0000 --00000000000083c58b059862e3f9 Content-Type: text/plain; charset="UTF-8" Hi Ekr, Thanks for your help. I have another question about the "message_seq" in section "6. Example of Handshake with Timeout and Retransmission". Could you please explain it? In the secion 6, the Client send message_seq = 0 in Record 0 and message_seq = 2,3,4 in Record 2. Why message_seq = 1 is skipped by Client? I think the ClientHello in the figure should begin with message_seq=1. The message_seq = 0 is used by the first ClientHello which is the one without cookies. Thanks, Zhai Zhaoxuan On 11/28/19 5:37 AM, Eric Rescorla wrote: On Tue, Nov 26, 2019 at 10:05 PM Xuan k wrote: > Hi all, > > I'm trying to implement a DTLS1.3 library for embedded devices. But It > seems something weird about retransmissions and ACKs. > > In the section "5.2. DTLS Handshake Message Format": > > The first message each side transmits in each association always has > message_seq = 0. Whenever a new message is generated, the > message_seq value is incremented by one. When a message is > retransmitted, the old *message_seq value is re-used*, i.e., not > incremented. From the perspective of the DTLS record layer, the > retransmission is a new record. This record will have a *new* > * DTLSPlaintext.sequence_number* value. > > > In the section "7. ACK Message", the ACK message use the record_numbers > (corresponds to *DTLSPlaintext.sequence_number*). > > For my understanding, the "message_seq" belongs to "Handshake" and the > "sequence_number" or "record_numbers" belongs to > record layer. > Yes. The retransmission detection is done by "Handshake" using "message_seq", > but the "acknowledge" is done by "record layer" using "record_numbers". > It is so weird. > Hmm... I don't think that this is particularly weird. This is, for instance, how QUIC stream acknowledgement and retransmission works. The retransmission, retransmission detection and acknowledge should be done > in handshake process, but we need the record layer passing the > record_numebrs to the handshake process. > > Since a new "sequence_number" is used for retransmission, we have to > maintain a "record_numbers" to "message_seq" map with dynamic size. > Each retransmission attempt creates a new relationship between a new > "record_numbers" to an old "message_seq". > Yes, that's how it works in NSS. Since ACK is only used with Handshake messages, is it possible that we use > "message_seq" in ACK messages? > Or we use *old* "sequence_number" for retransmission, > Both of these give you strictly less information about the network. One of the cool innovations in QUIC is to label each packet separately so you can determine whether an ACK is an ACK of the original packet or a retransmit. We are trying to inherit tha there -Ekr so we do not need maintain the dynamic map. And if replay detection is > implemented, the retransmitted > record can be dropped by record layer (by replay detection), the > "Handshake Protocol" do not need to do retransmission detection. > > Thanks > Zhai Zhaoxuan > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000083c58b059862e3f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=20 =20 =20
Hi Ekr,

Thanks for your help.

I have another question about the &quo= t;message_seq" in section "6. Example of Handshake with Timeout a= nd Retransmission".
Could you please explain it?

In the secion 6, the Client send messa= ge_seq =3D 0 in Record 0 and message_seq =3D 2,3,4 in Record 2.

Why message_seq =3D 1 is skipped by Cl= ient?
I think the ClientHello in the figure should begin with message_seq=3D1. Th= e message_seq =3D 0 is used by the first ClientHello which is the=20 one without cookies.


Thanks,
Zhai Zhaoxuan

On 11/28/19 5:37 AM, Eric Rescorla wrote:
=20


On Tue, Nov 26, 2019 at 10:05 PM Xuan k <kxuanobj@gmail.com> wrote:
Hi all,

I'm trying to implement a DTLS1.3 library for embedded devices. But It seems something weird about retransmissions and ACKs.

In the section "5.2. DTLS Handshake Message Format&= quot;:
=C2=A0 =C2=A0The first message each side transmits in = each association always has
=C2=A0 =C2=A0message_seq =3D 0.=C2=A0 Whenever a new m= essage is generated, the
=C2=A0 =C2=A0message_seq value is incremented by one.= =C2=A0 When a message is
=C2=A0 =C2=A0retransmitted, the old message_seq val= ue is re-used, i.e., not
=C2=A0 =C2=A0incremented.=C2=A0 From the perspective o= f the DTLS record layer, the
=C2=A0 =C2=A0retransmission is a new record.=C2=A0 Thi= s record will have a new
=C2=A0 =C2=A0DTLSPlaintext.sequence_number valu= e.

In the section "7. ACK Message", the ACK messa= ge use the record_numbers (corresponds to DTLSPlaintext.sequenc= e_number).

For my understanding, the "message_seq" belo= ngs to "Handshake" and the "sequence_number"= or "record_numbers" belongs to
record layer.

Yes.

The retransmission detection is done by "Handshak= e" using "message_seq", but the "acknowledge&= quot; is done by "record layer" using "record_numbers"= .
It is so weird.=C2=A0

Hmm... I don't think that this is particularly weird. This is, for instance, how QUIC stream acknowledgement and retransmission works.


The retransmission,=C2=A0retransmission detection and=C2=A0acknowledge should be done in handshake process, but we need the record layer passing the
record_numebrs to the handshake process.

Since a new "sequence_number" is used for retransmission, we have to maintain a "record_number= s" to "message_seq" map with dynamic size.
Each retransmission attempt creates a new relationship between a new "record_numbers" to an= old "message_seq".

Yes, that's how it works in NSS.


Since ACK is only used with Handshake messages, is it possible that we use "message_seq" in ACK message= s?
Or we use old "sequence_number" for retransmission,

Both of these give you strictly less information about the network. One of the cool innovations in QUIC is to label each packet separately so you can determine whether an ACK is an ACK of the original packet or a retransmit. We are trying to inherit tha there

-Ekr

so we do not need maintain the dynamic map. And if replay detection is implemented, the retransmitted
record can be dropped by record layer (by replay detection), the "Handshake Protocol" do not need = to do=C2=A0retransmission detection.

Thanks
Zhai Zhaoxuan
_______________________________________________
TLS mailing list
TLS@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/tls
--00000000000083c58b059862e3f9-- From nobody Thu Nov 28 17:01:48 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A84120801; Thu, 28 Nov 2019 17:01:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema via Datatracker To: Cc: last-call@ietf.org, draft-ietf-tls-certificate-compression.all@ietf.org, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Christian Huitema Message-ID: <157498929764.5575.7815291384505057169@ietfa.amsl.com> Date: Thu, 28 Nov 2019 17:01:37 -0800 Archived-At: Subject: [TLS] Secdir last call review of draft-ietf-tls-certificate-compression-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2019 01:01:38 -0000 Reviewer: Christian Huitema Review result: Has Issues I have reviewed draft-ietf-tls-certificate-compression-07 as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Draft-ietf-tls-certificate-compression-07 defines two new TLS extensions to negotiate and then apply compression of the Certificate message. The draft is clear and well written, and the extensions are already widely deployed. I would like to say "ready", but I have to say "almost". This document is almost ready, except for one nit and one issue. First, one nit. The draft references the "Certificate message", but there is no formal reference section 4.4.2 of RFC8446. Please add that, maybe at the beginning of section 4. It may seem obvious to members of the TLS WG, but uninformed readers will appreciate. Second, my actual concern. Compression may leak information, because different certificate chains will compress differently. The authors mention that an attacker will not be able to inject data in the certificate chain, and thus that attacks of the CRIME variety are unlikely. That's correct, but that's not the entire story. TLS 1.3 will encrypt the compressed certificate message but the length of that message could be deduced from the length of the server's encrypted message. Attackers might be able to derive from that length the identity of the server, even if the SNI is encrypted. One could say that in the absence of compression the length of the certificate chain is also available. Indeed, the problem is flagged in draft-ietf-tls-esni-05, which states in section 5.3 that "it (the server) SHOULD pad the Certificate message, via padding at the record layer, such that its length equals the size of the largest possible Certificate (message) covered by the same ESNI key." Certificate compression introduces a level of complexity here. If only some servers in the anonymity set support compression, attackers can work with a smaller anonymity subset. If all attackers support compression, the padding should try to match the largest Compressed Certificate. It might be good to discuss this issue in the security consideration section. From nobody Fri Nov 29 16:45:01 2019 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4AAB120133; Fri, 29 Nov 2019 16:44:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Scott Bradner via Datatracker To: Cc: last-call@ietf.org, tls@ietf.org, draft-ietf-tls-tls13-cert-with-extern-psk.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.111.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Scott Bradner Message-ID: <157507469364.4754.18326307005747989728@ietfa.amsl.com> Date: Fri, 29 Nov 2019 16:44:53 -0800 Archived-At: Subject: [TLS] Opsdir last call review of draft-ietf-tls-tls13-cert-with-extern-psk-03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2019 00:44:54 -0000 Reviewer: Scott Bradner Review result: Ready This is an OPS-DIR review of TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key (draft-ietf-tls-tls13-cert-with-extern-psk) This ID proposes a TLS 3.1 extension to better prepare for the post quantum computer crypto-armageddon world. The document is very clearly written, as I expect from Russ. I expect there will be some operational issues around hand holding users to get the correct setup to make use of the extension but since this extension basically enables the simultaneous use of existing TLS options any such issues should be confined to sites using exclusively one or the other option and I do not see any way to mitigate such situations. From nobody Sat Nov 30 16:45:20 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFC2120831 for ; Sat, 30 Nov 2019 16:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=gSD5nRJi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=J80FVnHg 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 RrM1J4um7hsV for ; Sat, 30 Nov 2019 16:45:13 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD87312082D for ; Sat, 30 Nov 2019 16:45:13 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id B0429708 for ; Sat, 30 Nov 2019 19:45:12 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 30 Nov 2019 19:45:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=FH2sBuKHhpPlR2vmXdTyP66XVKVXAzDCtOnJAEYwVVY=; b=gSD5nRJi hKk4I1fgg0irb5K7QWyZrW+ri1zcBd2qh2Kx3+ihCHGVVfKGSDldvbw4fU+TOL9P vjJDQr/py4rX1jSfAqatwzypF9RBT2JwlZZ6GCtdOWXBWBUzNOsm/rYszzABiP3b Xze8FNt0SnKvi7SzLGqp0/zBJd+83/IfR+AKfq85tAk+whLZ6/EobzVVDm5Clw0m jNWvGrT0DnHarj0l1JkfyKaKiQvzqhb5+IKu6k6UC8U8147bdfsXSoDyjwiwpppp nHRIs5w86nKjxXL5yWYC5QbnkfI5+vyM6zM9aPociECUmseVAAiKjnslYcekp1ZI b4z/IfRe2pfCUA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=FH2sBuKHhpPlR2vmXdTyP66XVKVXA zDCtOnJAEYwVVY=; b=J80FVnHgUD1BpZTkPwnCAWy+A5KOgZyt6mJRr1AXvYa06 vTPy+SEGAT/+R6/GqH0cqIIXui1MOfOxdXQnc9Jdegz8/nQxKV0d0r9npQ7uHezF a7gH+8k6oS2AVCX+fw3qQaaP0Du8H0jSjZfbk4vUE/8Hc0yP/7gUwVDciKwDyFF7 gPOngO2Ii8tMDqtO3gPDdoqqr2IWWL/bhoPIdCOrE8YGbrY9zbJorhZIEm5MeudF BuurzVps2CdrFJD1xAa+OZFQ/mwfkp/ajBL2SbqX4aO3WpAL55f3saRzvd+XmCgU yoPmBHGastO56gA0e21AlJCzHM8ppKk8tD9jw3ttA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudejvddgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpefiihhthhhusgcupfhothhifhhitggrthhiohhnshcuoeguohgpnhhothgp rhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmne cukfhppeeghedrjeelrdduudefrdduieehnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [45.79.113.165]) by mail.messagingengine.com (Postfix) with ESMTPA id 67A8C30600CD for ; Sat, 30 Nov 2019 19:45:11 -0500 (EST) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 791C69D393 for ; Sun, 1 Dec 2019 00:45:10 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============8319205209598490177==" MIME-Version: 1.0 From: Github Notifications To: tls@ietf.org Message-Id: <20191201004510.791C69D393@cloud.mnot.net> Date: Sun, 1 Dec 2019 00:45:10 +0000 (UTC) Archived-At: Subject: [TLS] Weekly github digest (TLS Working Group Drafts) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 00:45:18 -0000 --===============8319205209598490177== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * tlswg/draft-ietf-tls-esni (+2/-0/=F0=9F=92=AC1) 2 issues created: - Include "receiver anonymity" as motivation for empty record_digest valu= es (by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/issues/205=20 - Anonymity sets (by sayrer) https://github.com/tlswg/draft-ietf-tls-esni/issues/204=20 1 issues received 1 new comments: - #204 Anonymity sets (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/issues/204=20 * tlswg/draft-ietf-tls-external-psk-importer (+0/-1/=F0=9F=92=AC1) 1 issues received 1 new comments: - #23 Please be clearer about the PSK ID (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/23= =20 1 issues closed: - Please be clearer about the PSK ID https://github.com/tlswg/draft-ietf-= tls-external-psk-importer/issues/23=20 * tlswg/dtls13-spec (+1/-0/=F0=9F=92=AC0) 1 issues created: - Fix Figure 11 (by ekr) https://github.com/tlswg/dtls13-spec/issues/114=20 Pull requests ------------- * tlswg/draft-ietf-tls-external-psk-importer (+0/-1/=F0=9F=92=AC0) 1 pull requests merged: - Clarify wire protocol changes. Apply other editorial changes. https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/24=20 * tlswg/draft-ietf-tls-ticketrequest (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - Avoid seemingly-normative language (by sayrer) https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/11=20 1 pull requests merged: - Reword normative paragraph https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/10=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/tls-flags * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/sniencryption * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/draft-ietf-tls-grease --===============8319205209598490177== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday December 01, 2019

Issues

tlswg/draft-ietf-tls-esni (+2/-0/=F0=9F=92=AC1)

2 issues created:

1 issues received 1 new comments:

tlswg/draft-ietf-tls-external-psk-importer (+0/-1/=F0=9F=92=AC1)

1 issues received 1 new comments:

1 issues closed:

tlswg/dtls13-spec (+1/-0/=F0=9F=92=AC0)

1 issues created:

Pull requests

tlswg/draft-ietf-tls-external-psk-importer (+0/-1/=F0=9F=92=AC0)

1 pull requests merged:

tlswg/draft-ietf-tls-ticketrequest (+1/-1/=F0=9F=92=AC0)

1 pull requests submitted:

1 pull requests merged:

Repositories tracked by this digest:

--===============8319205209598490177==--