Re: [TLS] The future of external PSK in TLS 1.3
Hannes Tschofenig <Hannes.Tschofenig@arm.com> Wed, 23 September 2020 11:49 UTC
Return-Path: <Hannes.Tschofenig@arm.com>
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 409D13A0FA8 for <tls@ietfa.amsl.com>; Wed, 23 Sep 2020 04:49:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=lMvqcrL/; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=lMvqcrL/
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgIg3JnikAey for <tls@ietfa.amsl.com>; Wed, 23 Sep 2020 04:49:28 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70049.outbound.protection.outlook.com [40.107.7.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C363A0FB2 for <tls@ietf.org>; Wed, 23 Sep 2020 04:49:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=je1iTHNOp/hvUQmUHKUUTZy10jBRnCUo3PtqbcAt7+I=; b=lMvqcrL/k2UpwpIzE+YgiKTHYFhhZvfOf2YpsFMtKYIaUXTtRKbyaMvAkbO2sYb8y/+tgQEkPsI86mqYmgVAPy+6DwuVwJ8HC8QFFdaBbnIjMCQ8AksGr/L0h3ZCYfrKaKbxCGo1qJwe1QEBUTcWdS0RDvymMwqaP8UfTDdWC0A=
Received: from AM6P192CA0041.EURP192.PROD.OUTLOOK.COM (2603:10a6:209:82::18) by VE1PR08MB5744.eurprd08.prod.outlook.com (2603:10a6:800:1af::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.19; Wed, 23 Sep 2020 11:49:24 +0000
Received: from VE1EUR03FT041.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:82:cafe::c2) by AM6P192CA0041.outlook.office365.com (2603:10a6:209:82::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.20 via Frontend Transport; Wed, 23 Sep 2020 11:49:24 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT041.mail.protection.outlook.com (10.152.19.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21 via Frontend Transport; Wed, 23 Sep 2020 11:49:23 +0000
Received: ("Tessian outbound bac899b43a54:v64"); Wed, 23 Sep 2020 11:49:23 +0000
X-CR-MTA-TID: 64aa7808
Received: from c9baa8679224.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 72B0A559-BF0A-48AA-82BF-9D62F947E58B.1; Wed, 23 Sep 2020 11:49:18 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id c9baa8679224.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 23 Sep 2020 11:49:18 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FfatM0wESLkHaUPyxQiRNCXZnSZ240g587m7L9O84z0QNMy0O3djWcU1XweK46e2662lJmQprEp8JkicRIcBoJqakrqwk32wHrVXDDlV9HP/0Ap4f+qTZrmVTHx9Q7KRhf0dcHSNcQWgNQ0/GxoFKJSAaWUtIH8zerbRa5JckIRBZaPD3fYk455U9KuHGVtz3po3NbGOgKsn2PQRAGv43qNI8dKIkDLxjrND7pkbKRjM5uZJmhm0VOVUaQmRYlTMYnhseH8tAtmI/FdYeF3BaQ6sq6rgkIRlxrNHE9Kj0NaoG46bxGtH0qCWG4M7LwBj1pQDxReuDm/77Eq2vEdyqA==
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=je1iTHNOp/hvUQmUHKUUTZy10jBRnCUo3PtqbcAt7+I=; b=oHZcFz6iO7yReX+zNdHj5ijBF8ODVcC7Skx+sHUFPNqEh4vLARD+Ypa2zMjlddNr9lPNSKe3wa2n4L2N8/dX3KnsTikcdDFg6OPhEKe61UL55oCtMqExGBAVfTWf58qETpO0D41WNpU+cMjR69QMY2393u1dxdVy9oE7ZgpyIxBwnCZ/gJTg1cBao/prNA8wXEgH6dhFMut3jIwQCAoIPD0FEoNsjYI7cxJ3L4mY4WaDHptNEpjXv6nVJh9GHTeS0CVYE+SFvgUDCKE18tYPdn8XmhAfUNIEMVX3ciW8JNA09i9nGB98j8Yp+CzyuwtOgXEbYeNxCR7GePvERIwM+A==
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=je1iTHNOp/hvUQmUHKUUTZy10jBRnCUo3PtqbcAt7+I=; b=lMvqcrL/k2UpwpIzE+YgiKTHYFhhZvfOf2YpsFMtKYIaUXTtRKbyaMvAkbO2sYb8y/+tgQEkPsI86mqYmgVAPy+6DwuVwJ8HC8QFFdaBbnIjMCQ8AksGr/L0h3ZCYfrKaKbxCGo1qJwe1QEBUTcWdS0RDvymMwqaP8UfTDdWC0A=
Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB4098.eurprd08.prod.outlook.com (2603:10a6:208:12f::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.19; Wed, 23 Sep 2020 11:49:17 +0000
Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::900e:c64d:a006:4860]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::900e:c64d:a006:4860%6]) with mapi id 15.20.3391.026; Wed, 23 Sep 2020 11:49:17 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: Carrick Bartle <cbartle891@icloud.com>
CC: Carrick Bartle <cbartle891=40icloud.com@dmarc.ietf.org>, Filippo Valsorda <filippo@ml.filippo.io>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] The future of external PSK in TLS 1.3
Thread-Index: AQHWjng9Pwzr8fTsOkSjvpJZy/djPKlv2BqIgABG0ACAAlNKgIAAVNSggACB6oCAAAGjAA==
Date: Wed, 23 Sep 2020 11:49:17 +0000
Message-ID: <AM0PR08MB371678103D9EEB89C9AA44C1FA380@AM0PR08MB3716.eurprd08.prod.outlook.com>
References: <77039F11-188E-4408-8B39-57B908DDCB80@ericsson.com> <1600516093048.75181@cs.auckland.ac.nz> <2f2ecb30-bef5-414a-8ff7-d707d773c7ea@www.fastmail.com> <FDD012C2-9B37-461D-BC81-854135EE994E@icloud.com> <AM0PR08MB3716861B782527DAB3C1EA1BFA3A0@AM0PR08MB3716.eurprd08.prod.outlook.com> <DF3B268F-2E80-4444-B643-D33BC0C7151E@icloud.com>
In-Reply-To: <DF3B268F-2E80-4444-B643-D33BC0C7151E@icloud.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ts-tracking-id: 77198E93AE7E8D4080A78AF5656B1979.0
x-checkrecipientchecked: true
Authentication-Results-Original: icloud.com; dkim=none (message not signed) header.d=none;icloud.com; dmarc=none action=none header.from=arm.com;
x-originating-ip: [80.92.122.149]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 656fa25c-69c0-41da-8022-08d85fb6b789
x-ms-traffictypediagnostic: AM0PR08MB4098:|VE1PR08MB5744:
X-Microsoft-Antispam-PRVS: <VE1PR08MB574493F64BBFAEDF6DFF213FFA380@VE1PR08MB5744.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:8273;OLM:8273;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: HLDW0NcZLEtIZLQk8OyCtB7PDU5y70795Imlb6m0NvW93Z2Fqq08B2/9IU/WO5EgfBHPTXShzxwHj67Z+e+xo8+4ISXUlLmG8KDGHBhHU7hej95fgRKsTKSCS4d0uQ57vwbhcEGRc2W9p8H6EAroPTKxTv6LeKVnFYB4sKHJCISH0lrK3TShPRo2vWoObH1Ffj91CijxV593mtY5s4i0y/rxvmNsb+18RqoQgMjWLAbZIzdDMiZgaaoHLpZHrRxIKeM1lVsmd0jPV9MmqhjEOAGuZrhuug7MMR6Aw5Uesr7wRLWYRWJ+6h8XbdHGqzBwCFx1ptOnqp1AZjQQ48SiHF84RMX+Qm+cWWj4JRAR3AHtDC3KC43nGw2rjuhoBSrXCSQrRQ3a5Pi/Tj7T6bn20g==
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(346002)(136003)(39860400002)(376002)(966005)(9326002)(9686003)(8936002)(66574015)(8676002)(4326008)(54906003)(5660300002)(52536014)(6916009)(7696005)(186003)(33656002)(83380400001)(86362001)(2906002)(71200400001)(76116006)(64756008)(66446008)(53546011)(55016002)(26005)(316002)(166002)(66476007)(66556008)(66946007)(6506007)(478600001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: rKNG362XTKL+WkRBZag3MCh5Ds9q68yqZvwq+0YNY58bQUg6oiX0q8Y0yoABSyqDh89YF6tIiaSlEAGaKGPxrflRrd/4Gdzo4Rtqid31IgOS86HN58sESPcBoEERSDyMWaXgSYXJgDivbYBVNmaEhMjboS3oB4AFz71cX+7lsSpM3bn6VuwfV8ExoSM4iNVO7izycLIyCZhQfWOcL68VHx7fnhT1CGb6b8c/NWV+dBHg4DnQ6tpdd9HrOiVpal9OjjI2Soldtf7cyoaT4BqJPA18v9uGZ1c8Hj0Zxa4CWkNr6sVfpRVEPZF/p+OqISmAPydMNQFqGExyS555DpzsF0o/FCv0JIWsWjlwS7qmOjuxmgHKHT44hBqpILkKVbwkIDzgpaIX546i/g+xKoAu+4TpPejj3ZJwtkIUe6XOyoVS47bl83Eft6vuATbuYqhZPcC+0Kj3VzQBmN1s6o+bXAaolXb5KoA79DNWWi2vXRDEvwyVqIqrsCNNIBPI3mMoAPk0bD7+13nsC8VmVAz2MvJJdyhewsXCUDJ4dr/MGCpj2uN/Eo/lyQI1y7z0IOO+n9uW6DopsAoIMTCQPJbK0kDeJGf1WEizBvnZ+//OuriDaHxjfG/gJRjOYPqw+Op3h3bkxrZfoUj+mNuSoR+I0Q==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM0PR08MB371678103D9EEB89C9AA44C1FA380AM0PR08MB3716eurp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4098
Original-Authentication-Results: icloud.com; dkim=none (message not signed) header.d=none;icloud.com; dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT041.eop-EUR03.prod.protection.outlook.com
X-MS-Office365-Filtering-Correlation-Id-Prvs: 9a5ea71e-97ba-411e-ca10-08d85fb6b3bd
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 7Dhc+zBreM0jrzuCKcCmsY65yro1Q2VINx6uvWKvKV4GLtEtYHUqxqQi91inkXjADm/hYNqFCFxRL8GDtJ8h/hXpvUpbO2t5tzqjbsFjPMHG5cTKQ0yDxKutl24WotcgxMGG3Er2TzvfUA+b1RhiIusZ0uXm/USVJ6BRDrW6W4N9IKTHtBSEkGohq/w98ZyM6n3kTmhEgFMCndu7srHPeIM2zlrtsk683r7QIik+F+tYRBIcFnQa1LO/EPfn2hDleLNx+lhTfAUUtBSwSd0mvQZBXaZp64JmaRhSYhYd2VlGuRcqmTvY+ofF8zX768y2s65Zeyt/MRC4c4Rg5CsyjLlYUGCxm2eXDLJgIgx1daTGAw8WjPDP21ZbS8Rrqu2MqlT6qnO0bgvHdYXED5ywmBm8TOnU+HrJpLEQ7iaSk7vIfqRSyHaiq8ijryZGeBaBiui9lk+wjealtfJzJAVf8Uo14Nmlc2h07u3/VeWPxGo=
X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(396003)(136003)(376002)(346002)(39860400002)(46966005)(82740400003)(478600001)(33656002)(9686003)(7696005)(5660300002)(336012)(53546011)(47076004)(966005)(81166007)(356005)(6506007)(83380400001)(33964004)(8676002)(6862004)(186003)(54906003)(52536014)(82310400003)(316002)(26005)(4326008)(8936002)(70206006)(9326002)(70586007)(55016002)(36906005)(86362001)(2906002)(166002)(66574015); DIR:OUT; SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2020 11:49:23.9376 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 656fa25c-69c0-41da-8022-08d85fb6b789
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT041.eop-EUR03.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5744
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Tu5hExmPTc4nHL2en8UrpssTEWg>
Subject: Re: [TLS] The future of external PSK in TLS 1.3
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Sep 2020 11:49:32 -0000
Hi Carrick, you note that SCADA is a pretty specific use case. SCADA sounds specific but TLS is used widely in the IoT market. It is even used in devices that use smart cards, which use TLS with PSK to protect their provisioning protocol. I am worried that marking a ciphersuite as N with the meaning that it "has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases" is hard for readers to understand which of these three cases were actually the reason for marking it as “N”. The "has not been through the IETF consensus process" will scare off many people. For most people the web is the generic case and everything else is a “specific use case”. Sure, the web is very important but TLS is a generic protocol used in many environments. I don’t understand John’s motivation. The LAKE group makes a decision to remove PSK support. That’s good for them. Does this imply that the TLS group also needs to make the same decision? Ciao Hannes From: Carrick Bartle <cbartle891@icloud.com> Sent: Monday, September 21, 2020 6:19 PM To: Hannes Tschofenig <Hannes.Tschofenig@arm.com> Cc: Carrick Bartle <cbartle891=40icloud.com@dmarc.ietf.org>; Filippo Valsorda <filippo@ml.filippo.io>; tls@ietf.org Subject: Re: [TLS] The future of external PSK in TLS 1.3 Can you justify your reasoning? Which part? On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com<mailto:Hannes.Tschofenig@arm.com>> wrote: Hi Carrick, Can you justify your reasoning? The challenge I have with the work on IoT in the IETF that the preferences for pretty much everything changes on a regular basis. I don’t see a problem that requires a change. In fact, I have just posted a mail to the UTA list that gives an overview of the implementation status of embedded TLS stacks and PSK-based ciphersuites are widely implemented. Ciao Hannes From: TLS <tls-bounces@ietf.org<mailto:tls-bounces@ietf.org>> On Behalf Of Carrick Bartle Sent: Monday, September 21, 2020 5:31 AM To: Filippo Valsorda <filippo@ml.filippo.io<mailto:filippo@ml.filippo.io>> Cc: tls@ietf.org<mailto:tls@ietf.org> Subject: Re: [TLS] The future of external PSK in TLS 1.3 I'm also fine with marking psk_ke as not recommended to be consistent with the non-PFS ciphers, but there are plenty of valid use cases that justify keeping dhe_psk_ke as recommended for external PSKs. Several of these use cases are detailed in draft-ietf-tls-external-psk-guidance-00. On Sep 19, 2020, at 9:00 AM, Filippo Valsorda <filippo@ml.filippo.io<mailto:filippo@ml.filippo.io>> wrote: 2020-09-19 13:48 GMT+02:00 Peter Gutmann <pgut001@cs.auckland.ac.nz<mailto:pgut001@cs.auckland.ac.nz>>: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org<mailto:40ericsson.com@dmarc.ietf.org>> writes: >Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and >especially psk_ke are both marked as RECOMMENDED. If used in the initial >handshake, both modes have severe privacy problems, PSK is used a fair bit in SCADA. There are no privacy problems there. So just because there's a concern for one specific environment doesn't mean it should be banned for any use. In particular, I think if a specific industry has a particular concern, they should profile it for use in that industry but not require that everyone else change their behaviour. Indeed, if the SCADA industry has a particular need, they should profile TLS for use in that industry, and not require we change the recommendation for the open Internet. Setting Recommended to N is not "banning" anything, it's saying it "has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases". SCADA sounds like a pretty specific use case. I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke wouldn't be marked N like all suites lacking PFS. _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
- Re: [TLS] The future of external PSK in TLS 1.3 Peter Gutmann
- [TLS] The future of external PSK in TLS 1.3 John Mattsson
- Re: [TLS] The future of external PSK in TLS 1.3 Filippo Valsorda
- Re: [TLS] The future of external PSK in TLS 1.3 Viktor Dukhovni
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 Carrick Bartle
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 Pascal Urien
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 Pascal Urien
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 Pascal Urien
- Re: [TLS] The future of external PSK in TLS 1.3 Pascal Urien
- Re: [TLS] The future of external PSK in TLS 1.3 Carrick Bartle
- Re: [TLS] The future of external PSK in TLS 1.3 Achim Kraus
- Re: [TLS] The future of external PSK in TLS 1.3 Achim Kraus
- Re: [TLS] The future of external PSK in TLS 1.3 Pascal Urien
- Re: [TLS] The future of external PSK in TLS 1.3 Achim Kraus
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] The future of external PSK in TLS 1.3 Filippo Valsorda
- Re: [TLS] The future of external PSK in TLS 1.3 David Woodhouse
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 Salz, Rich
- Re: [TLS] The future of external PSK in TLS 1.3 David Benjamin
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 David Benjamin
- Re: [TLS] The future of external PSK in TLS 1.3 Carrick Bartle
- Re: [TLS] The future of external PSK in TLS 1.3 Lanlan Pan
- Re: [TLS] The future of external PSK in TLS 1.3 Peter Gutmann
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 Filippo Valsorda
- Re: [TLS] The future of external PSK in TLS 1.3 Pascal Urien
- Re: [TLS] The future of external PSK in TLS 1.3 Salz, Rich
- Re: [TLS] The future of external PSK in TLS 1.3 Pascal Urien
- Re: [TLS] The future of external PSK in TLS 1.3 Achim Kraus
- Re: [TLS] The future of external PSK in TLS 1.3 Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] The future of external PSK in TLS 1.3 Watson Ladd
- Re: [TLS] The future of external PSK in TLS 1.3 Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] The future of external PSK in TLS 1.3 Carrick Bartle
- Re: [TLS] The future of external PSK in TLS 1.3 Achim Kraus
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 Rob Sayre
- Re: [TLS] The future of external PSK in TLS 1.3 Achim Kraus
- Re: [TLS] The future of external PSK in TLS 1.3 Hannes Tschofenig
- Re: [TLS] The future of external PSK in TLS 1.3 Watson Ladd
- Re: [TLS] The future of external PSK in TLS 1.3 Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] The future of external PSK in TLS 1.3 Salz, Rich
- Re: [TLS] The future of external PSK in TLS 1.3 Rob Sayre