Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)

Gonzalo Camarillo <gonzalo.camarillo@ericsson.com> Wed, 20 February 2019 12:03 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4812E1310DE for <tram@ietfa.amsl.com>; Wed, 20 Feb 2019 04:03:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 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_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=GKXiBu7E; dkim=pass (1024-bit key) header.d=ericsson.com header.b=VKeDf15Q
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6b61DOYF72Jt for <tram@ietfa.amsl.com>; Wed, 20 Feb 2019 04:03:09 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 87036130E76 for <tram@ietf.org>; Wed, 20 Feb 2019 04:03:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1550664179; x=1553256179; h=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=7cAs27INQzdhqHbRI8UxPpaVAkiM5CWIPYDpbQETuNY=; b=GKXiBu7EMYy+6niO6tA2e/X1BR4V4rro/PkB8akK1jtmVPe1r6QHYqKq2NS6IzUt OlYhSlwDsYoy6c56CuZ8MluJptijjyMYEuNGERwcPAJbSNg72atS4FB7Mz5gsxCr u1GnlO/In7ydbL9+uWQ8VZnI0h+htAD0O3BsvZJ6JU4=;
X-AuditID: c1b4fb2d-2198b9e00000062f-3f-5c6d41d9e0e6
Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 31.8B.01583.9D14D6C5; Wed, 20 Feb 2019 13:02:59 +0100 (CET)
Received: from ESESBMR502.ericsson.se (153.88.183.134) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 20 Feb 2019 12:56:51 +0100
Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESBMR502.ericsson.se (153.88.183.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 20 Feb 2019 12:56:51 +0100
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 20 Feb 2019 12:56:51 +0100
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=7cAs27INQzdhqHbRI8UxPpaVAkiM5CWIPYDpbQETuNY=; b=VKeDf15QTXCddiv01ECf2becfIz9/J3xR5QaRYazmUZxrNQE/zXPjT9MFPFREqNJMWzl5LXIBxKq/KV26xNEK8okF84x1zIq1Z0CnHKvns2Oz2FDcgGyjPYj5RMj5Xc+oAqEiZqVdImhsdetvv1G2CZgfXW78obGuQa2rGDAFYs=
Received: from VI1PR07MB5421.eurprd07.prod.outlook.com (20.178.15.15) by VI1PR07MB4784.eurprd07.prod.outlook.com (20.177.57.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.11; Wed, 20 Feb 2019 11:56:49 +0000
Received: from VI1PR07MB5421.eurprd07.prod.outlook.com ([fe80::1559:7df1:b61a:4391]) by VI1PR07MB5421.eurprd07.prod.outlook.com ([fe80::1559:7df1:b61a:4391%2]) with mapi id 15.20.1643.014; Wed, 20 Feb 2019 11:56:49 +0000
From: Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
To: "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>
CC: Eric Rescorla <ekr@rtfm.com>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Marc Petit-Huguenin <petithug@acm.org>, "tram-chairs@ietf.org" <tram-chairs@ietf.org>, "tram@ietf.org" <tram@ietf.org>, IESG <iesg@ietf.org>, "draft-ietf-tram-stunbis@ietf.org" <draft-ietf-tram-stunbis@ietf.org>
Thread-Topic: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)
Thread-Index: AQHUa0FPQa4RlvmGQ0G0i0rcGeSYLqXoiXoAgADGtIA=
Date: Wed, 20 Feb 2019 11:56:49 +0000
Message-ID: <4b8f10f7-1eee-c8bc-d9ee-e3f18473de32@ericsson.com>
References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <CABcZeBMn1G8BT13bx3JTs04zwQk8K72+btj=xwC662F5AcANXg@mail.gmail.com> <cbb48225-5089-9275-787c-38fa4504a6a4@acm.org> <CABcZeBPNwu-tr8Tf_DiW2iOVy2NDEJoLwAR-6=EWHZak2gVMYg@mail.gmail.com> <c135ad63-bb18-a5f2-4aa2-e2a3268ac26f@acm.org> <CAKKJt-e1XFJNrx-LKmpZFDy6ZuaXt5+Lp+Uw90-Bu-M22PMt3Q@mail.gmail.com> <472563ee-5fc3-655d-8e31-138cc774e608@acm.org> <CAKKJt-dXijVNnAtYojq9x=9_m0pwAM8XTNP8wUEMvAa+m9UXUA@mail.gmail.com> <af0635b1-e731-0198-3b71-e3267bc10d0e@ericsson.com> <CABcZeBPoFnMBQrfDWcc5TV-=HRRX5CVWM2MO6Byf1QvSYztV3w@mail.gmail.com> <CAKKJt-ekdJuDsGFRQziYdeGqemBiVaQVpUYJiZXuTdNDQU9ySg@mail.gmail.com> <97c561a7-c33a-6121-00c4-09cd11646b98@ericsson.com> <CABcZeBPuLPha64QybuPUc-W+fR2Bqn1rAzDsb908uBNqC9z50A@mail.gmail.com> <D99F4FB6-EA38-49F6-AE00-83570455C6D7@cisco.com> <VI1PR07MB5421AC5849B762B682B52D6883630@VI1PR07MB5421.eurprd07.prod.outlook.com> <CEA96BE8-B0B2-4566-BFB1-6D387D2B1BD6@cisco.com>
In-Reply-To: <CEA96BE8-B0B2-4566-BFB1-6D387D2B1BD6@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [89.166.49.243]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
x-clientproxiedby: HE1PR0902CA0003.eurprd09.prod.outlook.com (2603:10a6:3:e5::13) To VI1PR07MB5421.eurprd07.prod.outlook.com (2603:10a6:803:bc::15)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=gonzalo.camarillo@ericsson.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b72c9727-d222-41bf-4ed0-08d6972a7eff
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB4784;
x-ms-traffictypediagnostic: VI1PR07MB4784:
x-ms-exchange-purlcount: 5
x-microsoft-exchange-diagnostics: =?utf-8?B?MTtWSTFQUjA3TUI0Nzg0OzIzOndhYUZoN2hqbFNPR0FjRjJhdm1xaUVtZCtU?= =?utf-8?B?dDloYytqbG9uMGN6NG9RWTdDMmMreUh6VmhxUTk2Tk9aTmY3bUdtQ0ZndlRh?= =?utf-8?B?TlVVUVpnenFROFdkV0JncFFKV2lKSHVyRm9vU3JSN005bThrT0dTM3JoM2ZQ?= =?utf-8?B?UVNjU25QemlFQWJvSEU0LytwYnJwcytrd3FWZHpxdUdQb3lzYS9FQ0RqN3NR?= =?utf-8?B?QUlGdm1VNjdJeGxLUjM3SUdPcG5DK0g0alBlc0FqeFRZSHQ2ZFBvaHFldHo4?= =?utf-8?B?aEpWZUdBR1kyR2RjOWhBL3NtWXJCWEdRVklGN2xuZ05GbEk2U2RIRHFrd1RQ?= =?utf-8?B?bTg2bDJveTF0bFY4TUdrZUxWMFVtKzUrSnZNbUxDdE90cC95MFhiRmlScVc4?= =?utf-8?B?U29SRW90Tkd3M3dIZGczT0NnOEhJVTREeFZDOUhMWk9DUDBiU3pEUWpiOXZz?= =?utf-8?B?dU9pVzdXSHZkaXBJQzl1d2VBc1ozcFppa3hoWGV4Sy82angrcmMxZVFiQVR4?= =?utf-8?B?M0kzRnNucE10OU5oUzZEaDdRUGI3cmZkdUI0akdxMEI4dzlITjNPTXBsaFRK?= =?utf-8?B?RUE0bUI0ME00cUMwRTl0ejZFbFJlNmZKOE1tb2hmbWYzYy9qcmgrZlNheHN3?= =?utf-8?B?QnI4TVRwVUxEK2gzQzNIRFNMS1JaVXo0M1ZQY1o1bkgwZmQ3bU9IVFFXaG1j?= =?utf-8?B?KzZBbldxTm9Zeit5dFBHRzVTaThOOFVDYWxTVW45aVByNmtjYmVqdDhhb2hN?= =?utf-8?B?bkJCRXNlMHNWY0cwc3FVeDc0K29XNFRwTjdBaG9GODhBcW9mOTRWaVkvTXlO?= =?utf-8?B?YWJjb2UvZFhSWVFGUThNRVE3VFFIY3l6Z0FuN3B0K1dpWUpJSmVra0x3VmRp?= =?utf-8?B?OHRLOHlrcEwvNURObCtIdHBqZTAxZ0F3Wm40SUJuUXFNRVZuYmRpVUhNcHAx?= =?utf-8?B?YlpHRm9KKzd6bE1IR0tMRUNTdHBtV3lKZk8zTXNuTXBIN2ZWTUdlNGdxZHRj?= =?utf-8?B?VFlSYmZ0WmYyeHlRRlZSUTN2Q2dNVTB3ZnJLa0VRbzZVT05sY010R1lVS2or?= =?utf-8?B?YURoQTlLb0VhTmkzT1ZqTjF3Njl0VDM3V3FHR2ExbjhNK21lZE81QmlzM1RD?= =?utf-8?B?cnluQUNxaU1uMGhpWXkyU0tvYTBZaHRVM1h0d01sRHU3RVh1eFlwM1dSSGRq?= =?utf-8?B?NFNuWXErTE9XbnJJTXZ6SzFWTU02TmhncW0raFBEak9ST1Z0QWgzbGNjNklj?= =?utf-8?B?bVB3dnhFVGJSL1N6bm1BWXlrMXEvVG8wVm9SWlczUmhiNENoTHFPaGZCWDVZ?= =?utf-8?B?c0JjRTRydzFIS2ZXaWRmeWs0QjRLS0wxdjEzRzlOK3lScGc2U0JpdWlvSk5B?= =?utf-8?B?WlJGNG9JOHllVnA4bHVtRVp5UjcxTmRza09FOEd4R1NCandEbXdhaFc4KzFM?= =?utf-8?B?WlNValVoaFAvVTBxd3JWVzBUYW1SYkRYUWswbzRWSTl6RXlRSkwvUVZsYzJp?= =?utf-8?B?R2F6Ritzd0hIQ0RLWnY1WXRhN1JHUFd5L3hPUzZxQU1UcXl4UytoNnR5eW1p?= =?utf-8?B?Rm1zTFMrc1NpMy9naVY2ZzBpY2JEV2c5TS9aMWsyN0RLWm9SYmd3dkRKa3dQ?= =?utf-8?B?NGZHTG0rdHorWWh4bW9SSGJKeFR6VDNJQUVoamNPQWxuN2pKeVA4bUI5eUk0?= =?utf-8?B?Zk5TSEl3bUMyWXBKUHJoblo4RzRHWnJQSHV2N0M4djN1d2xDQjVSU2xSN1BH?= =?utf-8?B?dXlSQ1E4Q3dNVGNoTDRmZzZkMi85ZzJ3bS9xRDRyV1gvZHBFS2YyRXBCNlMw?= =?utf-8?B?MUlxL2ZLQkNFM01oNU1UaThyMU9IT3VNQWtyWlQzNy9EY05QbmE0Q2N0Um85?= =?utf-8?B?UUJidzZzUlI3WENtOHJhSmdrMC9JNzN2dkNkZEdISitFU0pwTDc4MGJ0Q0x3?= =?utf-8?B?dHpoQVBlckFQNFlCTjZmZkJIRHF4SWF5MFJFZ0l1WFgyRURQcVdzUUVLRFY3?= =?utf-8?B?b1grSU1xTW1ZaTk5MEpnRkt2dkYvR1E2cFNqN3ZnVmpJTHhwanR4eXdvRFFp?= =?utf-8?B?RmFwNEtKakFLVkZ4ejF1UCt0N01ha21yTVRvZGxNV3dqT0cyZjIxcTlCR3dh?= =?utf-8?B?eVNaYmt2VFE5S0VjT1dUVkdxSW5ORkhibXh2KzMydm80dGdHclpIb2tBYXVo?= =?utf-8?B?UVFnU2JjcFcycS9QQkVYYi9RQ1MveGdDT2IwaVFMZm9ZaGRBa2oyUGxRVm5w?= =?utf-8?Q?Te079E6fGine1FaR66?=
x-microsoft-antispam-prvs: <VI1PR07MB4784138D9787164B1941DEC2837D0@VI1PR07MB4784.eurprd07.prod.outlook.com>
x-forefront-prvs: 0954EE4910
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(346002)(376002)(136003)(199004)(189003)(51914003)(51444003)(54094003)(53936002)(256004)(71190400001)(106356001)(105586002)(6916009)(64126003)(6512007)(2906002)(446003)(71200400001)(53946003)(305945005)(81156014)(81166006)(6306002)(2616005)(316002)(8676002)(54906003)(7736002)(97736004)(58126008)(14444005)(3846002)(31686004)(386003)(6506007)(53546011)(31696002)(102836004)(6116002)(93886005)(65826007)(30864003)(86362001)(76176011)(14454004)(8936002)(6436002)(6486002)(476003)(5660300002)(966005)(66066001)(36756003)(65806001)(478600001)(11346002)(26005)(229853002)(68736007)(45080400002)(65956001)(186003)(6246003)(52116002)(99286004)(486006)(4326008)(25786009)(561944003)(559001)(579004)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4784; H:VI1PR07MB5421.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: AZHWRiukLWsrVm8zDvN3tlGn6bZNqydFOhJ+5P/dEAGY7wwSbKd2/AP3pszZaULQMq8i9zfU+BbYm1qNcgcN9mHuxMwFUhxakPq4babB/FHVWCBMQodfn83+dfO8lMokbe0zPLIwU/wtX+rnncLXUDCD/oMXXh7DYjAi1YrSf6/2H0yYGOewYveIw/ds8jJAqyMU13aZIwrqqAGA4ClKHiq4+/o06He+Ob9Xkux5fa4MpCKYSeU2cb1jLtjdjHo9fhrugpTSoAGaVGMueUY6lRv7ja6t0L9R29Dph2EOL+8iYMvMKOXcACIPSnHQ2SqAfEhVHm9Y8MhdvP3zFZS8US1h09tCVRuhwPcgPaiQ+Qb7JtaozCJLITXy4CkjtyyDoyAaIKd6GYFdRuJn1K+PUwd8U9NVdpofzyacYWwXW5w=
Content-Type: text/plain; charset="utf-8"
Content-ID: <CF119A27F40DA04080D1C297A89D73A2@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b72c9727-d222-41bf-4ed0-08d6972a7eff
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2019 11:56:48.5389 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4784
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec9l57gavE2XT7OiBhVd7GbY6Z7kh3UxCiIijBx5cJaz2Jlm RWh3NTJLY21gWo1VXrp4d45Mi8TK0mZZiyJzmmkNScriVLTtLOjb73n+//e58bKk8i6tZpNT TbwxVZeikckpy7a6tMiRGEP8/OFcmsupdsm460NPGa6ocCN38dc5kusof0tw9kInyV37eUPG DVd0yFazWlfXem2heIfWNljfMlqb7SehLeg9SW6it8uXJ/Ipyem8cd7KBLm+q2SU3ne+lcyw m29RWcjZSOaiEBbwInC0niFykZxV4gcIPt++IvMLSvwdwZMXeknwcbEzn5ICGwH3s6sYf0Dh fBKs7iOkpJwn4MaXx4wUfEDQbDP7KrOsDHOQXRbtrxuGF4NTPB7oQeJaAga/BfKhOAneDHbT fnsY1oNLXCfZl0JJqyNgp/A0uNpbGZhbgVeB+CMv2GqUge53eQEhBK+AzqFiys8Ij4fRR+WE 1Csc3J5iQloag835LHgAFXzq/UNLPBXavT0BjwrvgAs5RwOLATYjGKw/Fiyqg/cnKoKP50B7 twdJPAmeF58OchyINx8y0uPXCLoueoPCLKhyi5TEamiquoTyUZT1vwGtvgOQeCbccsyT0lro LHMzEk+FwtM9AVbgcdBm8VAliC5FKoEXBEPSwqi5vDF5lyDsTZ2bypsqke9XNVeLkfWobCim BWEWacYqdFGGeCWtSxcOGFoQsKQmTPGB8aUUiboDB3nj3p3GtBReaEERLKUJV/xSjotX4iSd id/D8/t44z+VYEPUWSimsc342WKdklG5Z5l2gtM8eVA2OW/M8Yq46Q0jEf2Pi+6V1MfXKHfH iYe1mb8vhzJo6/CAK9F7KtpUp8pxN71WWrY+mvhmTU+NPTLBNHsLvcH+IDajv1bNVF3JnsF/ fVWwWewr76CaHB5DZtvLj+uXnJu+/2ypNzx24qF3fd1rBzSUoNctmEUaBd1f4oVlhlEDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/y-pbfl6l2vpXGqyenz82MbODRLs>
Subject: Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Feb 2019 12:03:16 -0000

Thanks, Gonzalo! Please, let us know the agreed way forward once you
have the call.

Cheers,

Gonzalo

On 19-Feb-19 20:05, Gonzalo Salgueiro (gsalguei) wrote:
> Hi Gonzalo - 
> 
> We have scheduled a conference call with Ekr, Simon, Marc and myself on March 7th to discuss the last two remaining issues.  Will update with resolutions once this has occurred.
> 
> Cheers,
> 
> Gonzalo
> 
> 
> 
>> On Feb 18, 2019, at 8:18 AM, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> wrote:
>>
>> Hi Gonzalo S,
>>
>> what is the status of this one?
>>
>> Thanks,
>>
>> Gonzalo
>>
>> On 18-Jan-19 20:16, Gonzalo Salgueiro (gsalguei) wrote:
>>> Totally agree, Ekr.  Marc and I are meeting to come up with a proposal
>>> but I do agree we need to have a call to get this put to bed once and
>>> for all.  We’ll offer some potential dates in the next 2-3 weeks.
>>>
>>> Cheers,
>>>
>>> Gonzalo
>>>
>>>
>>>> On Dec 26, 2018, at 8:05 PM, Eric Rescorla <ekr@rtfm.com
>>>> <mailto:ekr@rtfm.com>> wrote:
>>>>
>>>> We really need to bring this to a close before both Spencer and I step
>>>> down, I should think.
>>>>
>>>> -Ekr
>>>>
>>>>
>>>> On Thu, Nov 22, 2018 at 4:30 AM Gonzalo Camarillo
>>>> <gonzalo.camarillo@ericsson.com
>>>> <mailto:gonzalo.camarillo@ericsson.com>> wrote:
>>>>
>>>>    Eric, Spencer, thanks for the status update!
>>>>
>>>>    Authors, could you please let us know when you plan to get to this?
>>>>
>>>>    Gonzalo
>>>>
>>>>    On 19-Nov-18 23:04, Spencer Dawkins at IETF wrote:
>>>>> Hi, Gonzalo, 
>>>>> On Mon, Nov 19, 2018 at 9:06 AM Eric Rescorla <ekr@rtfm.com
>>>>    <mailto:ekr@rtfm.com>
>>>>> <mailto:ekr@rtfm.com <mailto:ekr@rtfm.com>>> wrote:
>>>>>
>>>>>      Not really. I have not received any response to my mail of
>>>>    Oct 23.
>>>>>      As before, I'm happy to have a call, but I believe we're
>>>>    reaching
>>>>>      the limits of what can be accomplished by email.
>>>>>
>>>>>
>>>>> Eric would know best (it being his Discuss), but this is also my
>>>>> understanding. 
>>>>>
>>>>> I can add this to the agenda of the IESG informal telechat on
>>>>    November
>>>>> 29, if there hasn't been a call before then, but I don't have a
>>>>    reason
>>>>> to wait until then, if it's possible to talk sooner.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Spencer
>>>>>  
>>>>>
>>>>>
>>>>>      -Ekr
>>>>>
>>>>>
>>>>>      On Mon, Nov 19, 2018 at 6:35 AM Gonzalo Camarillo
>>>>>      <gonzalo.camarillo@ericsson.com
>>>>    <mailto:gonzalo.camarillo@ericsson.com>
>>>>>      <mailto:gonzalo.camarillo@ericsson.com
>>>>    <mailto:gonzalo.camarillo@ericsson.com>>> wrote:
>>>>>
>>>>>          Hi Spencer,
>>>>>
>>>>>          what is the status of this? Are the authors and the document
>>>>>          shepherd
>>>>>          working with the relevant ADs on the discusses?
>>>>>
>>>>>        
>>>>     https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/ballot/
>>>>>
>>>>>          Cheers,
>>>>>
>>>>>          Gonzalo
>>>>>
>>>>>          On 24-Oct-18 16:40, Spencer Dawkins at IETF wrote:
>>>>>          > Hi, Marc, 
>>>>>          >
>>>>>          > On Wed, Oct 24, 2018 at 3:44 AM Marc Petit-Huguenin
>>>>>          <petithug@acm.org <mailto:petithug@acm.org>
>>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>
>>>>>          > <mailto:petithug@acm.org <mailto:petithug@acm.org>
>>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>>> wrote:
>>>>>          >
>>>>>          >     Hi Spencer,
>>>>>          >
>>>>>          >     I sent my answers to Eric Rescorla questions on
>>>>    2018-10-07
>>>>>          following
>>>>>          >     an in-person meeting with my co-author, but never
>>>>    got a
>>>>>          response
>>>>>          >     back.  Because there was no change proposed by
>>>>    Eric I went
>>>>>          ahead and
>>>>>          >     published -19 a couple of weeks after that, with
>>>>    the text
>>>>>          agreed in
>>>>>          >     response to Adam's and Benjamin's comments.
>>>>>          >
>>>>>          >   
>>>>>        
>>>>      https://www.ietf.org/mail-archive/web/tram/current/msg02635.html
>>>>>          >
>>>>>          >
>>>>>          > Ah - I wonder if that was what had happened. 
>>>>>          >
>>>>>          > It sounds like you did the right thing, and that Eric
>>>>    has now
>>>>>          responded,
>>>>>          > which is also the right thing to do. 
>>>>>          >
>>>>>          > Thanks for helping me understand.
>>>>>          >
>>>>>          > Spencer
>>>>>          >  
>>>>>          >
>>>>>          >     On 10/23/18 7:28 PM, Spencer Dawkins at IETF wrote:
>>>>>          >     > Hi, Marc,
>>>>>          >     >
>>>>>          >     > I see that a -19 has been submitted, but didn't
>>>>    see a
>>>>>          reply from
>>>>>          >     Eric in
>>>>>          >     > this thread. Do you think that you've converged?
>>>>>          >     >
>>>>>          >     > (I saw an offer of a conference call, so thought an
>>>>>          out-of-band
>>>>>          >     > conversation might have happened)
>>>>>          >     >
>>>>>          >     > Thanks,
>>>>>          >     >
>>>>>          >     > Spencer
>>>>>          >     >
>>>>>          >     > On Sun, Oct 7, 2018 at 9:35 AM Marc Petit-Huguenin
>>>>>          >     <petithug@acm.org <mailto:petithug@acm.org>
>>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>
>>>>>          <mailto:petithug@acm.org <mailto:petithug@acm.org>
>>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>>> wrote:
>>>>>          >     >
>>>>>          >     >> Hi Eric,
>>>>>          >     >>
>>>>>          >     >> Please see inline.
>>>>>          >     >>
>>>>>          >     >> On 09/10/2018 03:25 AM, Eric Rescorla wrote:
>>>>>          >     >>> On Sat, Sep 8, 2018 at 2:31 PM, Marc
>>>>    Petit-Huguenin
>>>>>          >     <petithug@acm.org <mailto:petithug@acm.org>
>>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>
>>>>>          <mailto:petithug@acm.org <mailto:petithug@acm.org>
>>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>>>
>>>>>          >     >>> wrote:
>>>>>          >     >>>
>>>>>          >     >>>> Hi Eric,
>>>>>          >     >>>>
>>>>>          >     >>>> Apologies for the delay in getting back to that.
>>>>>          >     >>>>
>>>>>          >     >>>> I think that there is some misunderstanding
>>>>    in what
>>>>>          STUNbis is
>>>>>          >     trying to
>>>>>          >     >>>> do, so please see my comments inline.
>>>>>          >     >>>>
>>>>>          >     >>>> On 06/18/2018 10:43 AM, Eric Rescorla wrote:
>>>>>          >     >>>>> Hi folks,
>>>>>          >     >>>>>
>>>>>          >     >>>>> I've reviewed the new version, but I don't think
>>>>>          that the biddown
>>>>>          >     >>>>> discussion makes much sense.
>>>>>          >     >>>>>
>>>>>          >     >>>>> To recap, there are two hashes here:
>>>>>          >     >>>>>
>>>>>          >     >>>>> - The hash which you use to store the
>>>>    password with
>>>>>          (currently
>>>>>          >     mostly
>>>>>          >     >>>> MD5)
>>>>>          >     >>>>> - The hash you use to compute the MAC
>>>>    (currently SHA-1).
>>>>>          >     >>>>>
>>>>>          >     >>>>> First, let's stipulate that MD5 isn't a
>>>>    great choice
>>>>>          here,
>>>>>          >     though SHA-1
>>>>>          >     >>>>> isn't a great choice
>>>>>          >     >>>>> either for pwd hashing You want Argon or the
>>>>    like.
>>>>>          With that said,
>>>>>          >     >>>> there's
>>>>>          >     >>>>> no sensible
>>>>>          >     >>>>> biddown attack on that hash because it's a
>>>>>          per-server feature,
>>>>>          >     not a
>>>>>          >     >>>>> per-transaction
>>>>>          >     >>>>> feature. So, as long as the server has
>>>>    MD5-hashed
>>>>>          passwords, the
>>>>>          >     >>>> situation
>>>>>          >     >>>>> is bad.
>>>>>          >     >>>>
>>>>>          >     >>>> In no place in STUNbis we are proposing to
>>>>    use SHA-1
>>>>>          for password
>>>>>          >     >>>> encryption, so I am not sure where that come
>>>>    from. 
>>>>>          What we
>>>>>          >     propose is:
>>>>>          >     >>>>
>>>>>          >     >>>
>>>>>          >     >>> You're right, it's SHA-256, but my criticisms
>>>>    apply
>>>>>          equally there.
>>>>>          >     >>
>>>>>          >     >> SHA-256 was what the WG adopted.  Our attempts
>>>>    to add
>>>>>          other passwords
>>>>>          >     >> encryption mechanisms were denied.  It is true that
>>>>>          Argon2 was
>>>>>          >     not in that
>>>>>          >     >> list (in our defense Argon2 was not known
>>>>    before July
>>>>>          2015), but
>>>>>          >     I do not
>>>>>          >     >> see why the WG would have accepted that one
>>>>    over the
>>>>>          others. 
>>>>>          >     Anyway it is
>>>>>          >     >> too late to fix this, as it is my understanding
>>>>    that
>>>>>          the WG does
>>>>>          >     not have
>>>>>          >     >> enough energy to reach consensus on a new password
>>>>>          algorithm. 
>>>>>          >     Someone can
>>>>>          >     >> just write a draft adding Argon2 as password
>>>>>          encryption, as we
>>>>>          >     will have a
>>>>>          >     >> IANA registry for that.
>>>>>          >     >>
>>>>>          >     >>>
>>>>>          >     >>>
>>>>>          >     >>>> - Establish a registry for new password
>>>>    algorithms
>>>>>          (section
>>>>>          >     18.5), so
>>>>>          >     >>>> algorithms like Argon2 could be added later
>>>>    (but note
>>>>>          that our own
>>>>>          >     >>>> proposals to add more password algorithms were
>>>>>          rejected by the
>>>>>          >     working
>>>>>          >     >>>> group).
>>>>>          >     >>>> - Add a new password algorithm to that registry,
>>>>>          namely SHA-256.
>>>>>          >     >>>> - Register MD5 as an initial password
>>>>    algorithm for
>>>>>          backward
>>>>>          >     >> compatibility
>>>>>          >     >>>> purpose.
>>>>>          >     >>>>
>>>>>          >     >>>> As for the biddown protection itself, it is my
>>>>>          recollection that it
>>>>>          >     >>>> happened more or less like that:
>>>>>          >     >>>>
>>>>>          >     >>>>
>>>>>          >     >>>> INT. MEETING ROOM - DAY
>>>>>          >     >>>>
>>>>>          >     >>>> One of the co-editors of STUNBis stands at the
>>>>>          microphone:
>>>>>          >     >>>>
>>>>>          >     >>>>                            CO-EDITOR
>>>>>          >     >>>>                  We added SHA-256 protection for
>>>>>          passwords
>>>>>          >     >>>>                  in STUNBis.
>>>>>          >     >>>>
>>>>>          >     >>>>                            SOMEONE (V.O.)
>>>>>          >     >>>>                  As MD5 still need to be
>>>>    supported,
>>>>>          you need to add
>>>>>          >     >>>>                  protection for bid-down attacks.
>>>>>          >     >>>>
>>>>>          >     >>>> CLOSE-UP on CO-EDITOR ROLLING HIS EYES
>>>>>          >     >>>>
>>>>>          >     >>>>                            CO-EDITOR
>>>>>          >     >>>>                  OK, I'll work on that.
>>>>>          >     >>>>
>>>>>          >     >>>> Four to eight months has passed.
>>>>>          >     >>>>
>>>>>          >     >>>> INT. ANOTHER MEETING ROOM - DAY
>>>>>          >     >>>>
>>>>>          >     >>>> The same co-editor of STUNBis stands at the
>>>>    microphone:
>>>>>          >     >>>>
>>>>>          >     >>>>                            CO-EDITOR
>>>>>          >     >>>>                  We added a nice mechanism to
>>>>    prevent
>>>>>          bid-down
>>>>>          >     >>>>                  attacks on passwords.  Any
>>>>    comments?
>>>>>          >     >>>>
>>>>>          >     >>>>                            THE ROOM
>>>>>          >     >>>>                  (silence)
>>>>>          >     >>>>
>>>>>          >     >>>>                            CO-EDITOR
>>>>>          >     >>>>                  Moving on...
>>>>>          >     >>>>
>>>>>          >     >>>
>>>>>          >     >>> I don't see how any of this is relevant to my
>>>>>          technical points
>>>>>          >     above.
>>>>>          >     >>
>>>>>          >     >> My point was that we, the co-editors, did not
>>>>    decide on
>>>>>          adding
>>>>>          >     bid-down
>>>>>          >     >> protection, someone asked us to do so and
>>>>    no-one in the
>>>>>          WG saw
>>>>>          >     any problem
>>>>>          >     >> with that.  The reasons that person wanted that
>>>>    are not
>>>>>          known to
>>>>>          >     us but, as
>>>>>          >     >> you insist, here's one reason I can think of:
>>>>>          >     >>
>>>>>          >     >> It is a fact that, for operational reasons, a
>>>>    password
>>>>>          database
>>>>>          >     cannot be
>>>>>          >     >> re-encrypted at once.  Also for operational
>>>>    reasons,
>>>>>          the MD5 password
>>>>>          >     >> cannot be immediately removed from the database
>>>>    as soon
>>>>>          the user
>>>>>          >     submitted
>>>>>          >     >> a new one.  In fact, and for quite some time, both
>>>>>          encrypted
>>>>>          >     variants of
>>>>>          >     >> the same password may have to be kept in that
>>>>    database,
>>>>>          because a
>>>>>          >     single
>>>>>          >     >> user may use a mix of devices, some of them
>>>>    that use an
>>>>>          RFC 5389
>>>>>          >     client,
>>>>>          >     >> some that use a STUNbis client.  It is up to
>>>>    the STUN
>>>>>          server owner to
>>>>>          >     >> decide how long the migration to STUNbis will
>>>>    take and
>>>>>          when it
>>>>>          >     will be
>>>>>          >     >> acceptable to reject all RFC 5389 (i.e. MD5)
>>>>    clients (that
>>>>>          >     migration time
>>>>>          >     >> can be purposely reduced to 0 seconds but
>>>>    that's the
>>>>>          choice and
>>>>>          >     >> responsibility of the owner of the server).
>>>>>          >     >>
>>>>>          >     >> Meanwhile we still need to be sure that if the STUN
>>>>>          client is
>>>>>          >     implementing
>>>>>          >     >> STUNbis it unconditionally gets the additional
>>>>>          protection of the new
>>>>>          >     >> password encryption algorithm.  That's where
>>>>    the biddown
>>>>>          >     protection kicks
>>>>>          >     >> in, by preventing an online attacker to have
>>>>    the server
>>>>>          >     misidentifying a
>>>>>          >     >> STUNbis client as an RFC 5389 client, by
>>>>    preventing an
>>>>>          online
>>>>>          >     attacker to
>>>>>          >     >> have the client misidentifying a STUNbis server
>>>>    as a
>>>>>          RFC 5389
>>>>>          >     server, and
>>>>>          >     >> having both them use the MD5 encrypted password
>>>>    instead
>>>>>          of the
>>>>>          >     SHA-256
>>>>>          >     >> encrypted password, all of that easily done by
>>>>>          stripping the
>>>>>          >     unprotected
>>>>>          >     >> 401 response of the new STUNbis PASSWORD-ALGORITHMS
>>>>>          attribute.
>>>>>          >     >>
>>>>>          >     >>>
>>>>>          >     >>>
>>>>>          >     >>>
>>>>>          >     >>>>> The second topic is the hash used to compute the
>>>>>          MAC. However,
>>>>>          >     I don't
>>>>>          >     >>>> see
>>>>>          >     >>>>> how
>>>>>          >     >>>>> this gives you sensible biddown protection
>>>>    because
>>>>>          that hash
>>>>>          >     is also
>>>>>          >     >> used
>>>>>          >     >>>>> to compute
>>>>>          >     >>>>> MAC over the negotiation: an attacker who has
>>>>>          compromised a
>>>>>          >     MAC which
>>>>>          >     >> the
>>>>>          >     >>>>> server
>>>>>          >     >>>>> supports will quite likely be able to forge
>>>>    a MAC
>>>>>          over the
>>>>>          >     transcript
>>>>>          >     >> as
>>>>>          >     >>>>> well. This is,
>>>>>          >     >>>>> I suppose, potentially useful as a defense
>>>>    against
>>>>>          some other
>>>>>          >     weakness
>>>>>          >     >>>>> (e.g.,
>>>>>          >     >>>>> version #), but I don't really see how the
>>>>    current
>>>>>          design
>>>>>          >     helps against
>>>>>          >     >>>>> attacks on the
>>>>>          >     >>>>> MAC.
>>>>>          >     >>>>
>>>>>          >     >>>> There is no biddown attack protection for the
>>>>    MAC, as
>>>>>          stated in
>>>>>          >     Section
>>>>>          >     >>>> 16.3:
>>>>>          >     >>>>
>>>>>          >     >>>> "The bid-down protection mechanism described
>>>>    in this
>>>>>          document
>>>>>          >     is new,
>>>>>          >     >>>>  and thus cannot currently protect against a
>>>>    bid-down
>>>>>          attack that
>>>>>          >     >>>>  lowers the strength of the hash algorithm to
>>>>    HMAC-SHA1."
>>>>>          >     >>>>
>>>>>          >     >>>> What we put in place is a plan for *future*
>>>>    versions
>>>>>          of STUN to get
>>>>>          >     >>>> biddown protection for the MAC.  That's it,
>>>>    no more,
>>>>>          no less.
>>>>>          >     >>>>
>>>>>          >     >>>
>>>>>          >     >>> Yes, but I don't believe that this will
>>>>    provide bid-down
>>>>>          >     protection for
>>>>>          >     >> the
>>>>>          >     >>> MAC in the future for the reasons I indicate
>>>>    above.
>>>>>          >     >>>
>>>>>          >     >>> If you think this does something useful,
>>>>    please show me an
>>>>>          >     example attack
>>>>>          >     >>> and how this fixes it. Note that it's not
>>>>    generally
>>>>>          useful to
>>>>>          >     just bid
>>>>>          >     >> down
>>>>>          >     >>> the MAC itself unless the MAC you bid down to
>>>>    is weak
>>>>>          enough to
>>>>>          >     exploit
>>>>>          >     >> in
>>>>>          >     >>> some other way.
>>>>>          >     >>
>>>>>          >     >> I do not know what weaknesses will be
>>>>    discovered in the
>>>>>          future. 
>>>>>          >     I am also
>>>>>          >     >> pretty sure that the cost of not using that
>>>>    mechanism
>>>>>          is very
>>>>>          >     close to 0.
>>>>>          >     >> What I am sure of is that the cost of
>>>>    reengineering a
>>>>>          new biddown
>>>>>          >     >> protection mechanism if we ever need it will be
>>>>    high. 
>>>>>          We already
>>>>>          >     went
>>>>>          >     >> through the pains of designing one for the password
>>>>>          algorithm, so
>>>>>          >     why not
>>>>>          >     >> extend it so it can be used in the aftermath of the
>>>>>          next Snowden
>>>>>          >     facepalm
>>>>>          >     >> moment?
>>>>>          >     >>
>>>>>          >     >>> Again, happy to have a call to walk though
>>>>    this if that
>>>>>          >     >>> helps.
>>>>>          >     >>>
>>>>>          >     >>> -Ekr
>>>>>          >     >>>
>>>>>          >     >>>
>>>>>          >     >>>
>>>>>          >     >>>
>>>>>          >     >>>>>
>>>>>          >     >>>>> You might think that there was a MAC which
>>>>    was easier to
>>>>>          >     reverse to
>>>>>          >     >> find
>>>>>          >     >>>>> the original
>>>>>          >     >>>>> password, but the defense you have here
>>>>    doesn't help
>>>>>          with that
>>>>>          >     because
>>>>>          >     >>>> the
>>>>>          >     >>>>> on-path attacker can do a bid-down and use the
>>>>>          client as a MAC
>>>>>          >     oracle
>>>>>          >     >> for
>>>>>          >     >>>>> any MAC the client supports.
>>>>>          >     >>>>>
>>>>>          >     >>>>> So, I still don't understand what this is
>>>>    supposed
>>>>>          to do. Happy to
>>>>>          >     >> have a
>>>>>          >     >>>>> call if you
>>>>>          >     >>>>> think that helps
>>>>>          >     >>>>>
>>>>>          >     >>>>> -Ekr
>>>>>          >     >>>>>
>>>>>          >     >>>>>
>>>>>          >     >>>>>
>>>>>          >     >>>>>
>>>>>          >     >>>>> On Mon, Jun 18, 2018 at 3:40 AM, Gonzalo
>>>>    Camarillo <
>>>>>          >     >>>>> Gonzalo.Camarillo@ericsson.com
>>>>    <mailto:Gonzalo.Camarillo@ericsson.com>
>>>>>          <mailto:Gonzalo.Camarillo@ericsson.com
>>>>    <mailto:Gonzalo.Camarillo@ericsson.com>>
>>>>>          >     <mailto:Gonzalo.Camarillo@ericsson.com
>>>>    <mailto:Gonzalo.Camarillo@ericsson.com>
>>>>>          <mailto:Gonzalo.Camarillo@ericsson.com
>>>>    <mailto:Gonzalo.Camarillo@ericsson.com>>>> wrote:
>>>>>          >     >>>>>
>>>>>          >     >>>>>> Marc, Eric,
>>>>>          >     >>>>>>
>>>>>          >     >>>>>> what is the status of this discussion?
>>>>>          >     >>>>>>
>>>>>          >     >>>>>> Thanks,
>>>>>          >     >>>>>>
>>>>>          >     >>>>>> Gonzalo
>>>>>          >     >>>>>>
>>>>>          >     >>>>>> On 04/05/2018 2:35 AM, Eric Rescorla wrote:
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>> On Mon, Apr 23, 2018 at 11:16 AM, Marc
>>>>>          Petit-Huguenin <
>>>>>          >     >>>> petithug@acm.org <mailto:petithug@acm.org>
>>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>
>>>>>          <mailto:petithug@acm.org <mailto:petithug@acm.org>
>>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>>
>>>>>          >     >>>>>>> <mailto:petithug@acm.org
>>>>    <mailto:petithug@acm.org> <mailto:petithug@acm.org
>>>>    <mailto:petithug@acm.org>>
>>>>>          <mailto:petithug@acm.org <mailto:petithug@acm.org>
>>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>>>> wrote:
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>     On 04/22/2018 05:22 PM, Eric Rescorla
>>>>    wrote:
>>>>>          >     >>>>>>>     > On Sun, Apr 22, 2018 at 2:02 PM, Marc
>>>>>          Petit-Huguenin <
>>>>>          >     >>>>>> petithug@acm.org <mailto:petithug@acm.org>
>>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>
>>>>>          <mailto:petithug@acm.org <mailto:petithug@acm.org>
>>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>>
>>>>>          >     <mailto:petithug@acm.org <mailto:petithug@acm.org>
>>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>
>>>>>          <mailto:petithug@acm.org <mailto:petithug@acm.org>
>>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>>>>
>>>>>          >     >>>>>>>     > wrote:
>>>>>          >     >>>>>>>     >
>>>>>          >     >>>>>>>     >>
>>>>>          >     >>>>>>>     >>>>      For a request or indication
>>>>    message,
>>>>>          the agent
>>>>>          >     MUST
>>>>>          >     >>>>>> include the
>>>>>          >     >>>>>>>     >>>>      USERNAME,
>>>>    MESSAGE-INTEGRITY-SHA256, and
>>>>>          >     >> MESSAGE-INTEGRITY
>>>>>          >     >>>>>>>     >> attributes
>>>>>          >     >>>>>>>     >>>>      in the message unless the agent
>>>>>          knows from an
>>>>>          >     external
>>>>>          >     >>>>>> indication
>>>>>          >     >>>>>>>     >>>>      which message integrity
>>>>    algorithm is
>>>>>          supported
>>>>>          >     by both
>>>>>          >     >>>>>> agents.  In
>>>>>          >     >>>>>>>     >>>>      this case either
>>>>    MESSAGE-INTEGRITY or
>>>>>          >     >>>>>> MESSAGE-INTEGRITY-SHA256 MUST
>>>>>          >     >>>>>>>     >>>>      be included in addition to
>>>>>          USERNAME.  The HMAC
>>>>>          >     for the
>>>>>          >     >>>>>> MESSAGE-
>>>>>          >     >>>>>>>     >>>
>>>>>          >     >>>>>>>     >>> This text appears to conflict with
>>>>    S 7.3 of
>>>>>          >     5245-bis, which
>>>>>          >     >>>> says:
>>>>>          >     >>>>>>>     >>
>>>>>          >     >>>>>>>     >> [text missing]
>>>>>          >     >>>>>>>     >>
>>>>>          >     >>>>>>>     >> Hmm, no, RFC245bis is still referencing
>>>>>          RFC5389, so the
>>>>>          >     >>>> procedure
>>>>>          >     >>>>>> for
>>>>>          >     >>>>>>>     >> stunbis does not apply.
>>>>>          >     >>>>>>>     >>
>>>>>          >     >>>>>>>     >
>>>>>          >     >>>>>>>     > I hear what you're saying, but
>>>>    publishing two
>>>>>          >     documents at the
>>>>>          >     >>>>>> same time
>>>>>          >     >>>>>>>     > which
>>>>>          >     >>>>>>>     > make contrary recommendations about
>>>>    the same
>>>>>          basic
>>>>>          >     protocol is
>>>>>          >     >>>>>> un-good.
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>     Sure, but wouldn't it be simpler to have
>>>>>          rfc5245bis
>>>>>          >     using stunbis
>>>>>          >     >>>>>>>     and have them updating their text,
>>>>    more than
>>>>>          adding some
>>>>>          >     tortuous
>>>>>          >     >>>>>>>     text in stunbis?
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>     >
>>>>>          >     >>>>>>>     >
>>>>>          >     >>>>>>>     >>>      The STUN usage must specify which
>>>>>          transport
>>>>>          >     protocol is
>>>>>          >     >>>>>> used, and
>>>>>          >     >>>>>>>     >> how
>>>>>          >     >>>>>>>     >>>>      the agent determines the IP
>>>>    address
>>>>>          and port
>>>>>          >     of the
>>>>>          >     >>>>>> recipient.
>>>>>          >     >>>>>>>     >>>>      Section 8 describes a DNS-based
>>>>>          method of
>>>>>          >     determining
>>>>>          >     >> the
>>>>>          >     >>>>>> IP
>>>>>          >     >>>>>>>     >> address
>>>>>          >     >>>>>>>     >>>>      and port of a server that a
>>>>    usage
>>>>>          may elect to
>>>>>          >     use.
>>>>>          >     >> STUN
>>>>>          >     >>>>>> may be
>>>>>          >     >>>>>>>     >> used
>>>>>          >     >>>>>>>     >>>>      with anycast addresses, but only
>>>>>          with UDP and
>>>>>          >     in usages
>>>>>          >     >>>>>> where
>>>>>          >     >>>>>>>     >>>>      authentication is not used.
>>>>>          >     >>>>>>>     >>>
>>>>>          >     >>>>>>>     >>> Why this restriction? You should
>>>>    be able
>>>>>          to use
>>>>>          >     anycast with
>>>>>          >     >>>>>> long-term
>>>>>          >     >>>>>>>     >>> AUTH for (say) TURN.
>>>>>          >     >>>>>>>     >>
>>>>>          >     >>>>>>>     >>
>>>>>          https://www.ietf.org/mail-archive/web/behave/current/
>>>>>          >     >>>>>> msg03582.html
>>>>>          >     >>>>>>>   
>>>>>           <https://www.ietf.org/mail-archive/web/behave/current/
>>>>>          >     >>>> msg03582.html>
>>>>>          >     >>>>>>>     >>
>>>>>          >     >>>>>>>     >> I think that the decision of
>>>>    permitting Anycast
>>>>>          >     should be left
>>>>>          >     >>>> to
>>>>>          >     >>>>>> each
>>>>>          >     >>>>>>>     >> STUN Usage.  Basic STUN Usage does
>>>>    not use
>>>>>          >     authentication and
>>>>>          >     >>>> use
>>>>>          >     >>>>>> only a
>>>>>          >     >>>>>>>     >> one round trip for the Binding
>>>>    transaction, so
>>>>>          >     Unicast can be
>>>>>          >     >>>>>> used.
>>>>>          >     >>>>>>>     >>
>>>>>          >     >>>>>>>     >
>>>>>          >     >>>>>>>     >> OTOH, TURN and ICE should probably say
>>>>>          something
>>>>>          >     about that,
>>>>>          >     >> so
>>>>>          >     >>>> I
>>>>>          >     >>>>>> added a
>>>>>          >     >>>>>>>     >> new bullet point in Section 13:
>>>>>          >     >>>>>>>     >>
>>>>>          >     >>>>>>>     >>    o  If Anycast addresses can be
>>>>    used for
>>>>>          the server
>>>>>          >     in case
>>>>>          >     >>>> TCP
>>>>>          >     >>>>>> or
>>>>>          >     >>>>>>>     >>       TLS-over-TCP, or
>>>>    authentication are used.
>>>>>          >     >>>>>>>     >>
>>>>>          >     >>>>>>>     >
>>>>>          >     >>>>>>>     > Are you leaving this text in? That seems
>>>>>          very confusing.
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>     In isolation yes, but I think it makes
>>>>    sense
>>>>>          which the text
>>>>>          >     >> before
>>>>>          >     >>>>>>>     the bullet points:
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>        A STUN usage defines how STUN is
>>>>    actually
>>>>>          utilized --
>>>>>          >     when to
>>>>>          >     >>>> send
>>>>>          >     >>>>>>>        requests, what to do with the
>>>>    responses,
>>>>>          and which
>>>>>          >     optional
>>>>>          >     >>>>>>>        procedures defined here (or in an
>>>>    extension
>>>>>          to STUN)
>>>>>          >     are to be
>>>>>          >     >>>>>> used.
>>>>>          >     >>>>>>>        A usage also defines:
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>     [...]
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>        o  If Anycast addresses can be used
>>>>    for the
>>>>>          server in
>>>>>          >     case TCP
>>>>>          >     >>>> or
>>>>>          >     >>>>>>>           TLS-over-TCP, or authentication
>>>>    are used.
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>> What is the need for the restriction at all.
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>     >>>>      transaction over UDP or
>>>>>          DTLS-over-UDP is also
>>>>>          >     >> considered
>>>>>          >     >>>>>> failed if
>>>>>          >     >>>>>>>     >>>>      there has been a hard ICMP error
>>>>>          [RFC1122].  For
>>>>>          >     >> example,
>>>>>          >     >>>>>> assuming
>>>>>          >     >>>>>>>     >> an
>>>>>          >     >>>>>>>     >>>>      RTO of 500ms, requests would
>>>>    be sent
>>>>>          at times
>>>>>          >     0 ms, 500
>>>>>          >     >>>>>> ms, 1500
>>>>>          >     >>>>>>>     >> ms,
>>>>>          >     >>>>>>>     >>>>      3500 ms, 7500 ms, 15500 ms, and
>>>>>          31500 ms.  If the
>>>>>          >     >> client
>>>>>          >     >>>>>> has not
>>>>>          >     >>>>>>>     >>>>      received a response after
>>>>    39500 ms,
>>>>>          the client
>>>>>          >     will
>>>>>          >     >>>>>> consider the
>>>>>          >     >>>>>>>     >>>>      transaction to have timed out.
>>>>>          >     >>>>>>>     >>>
>>>>>          >     >>>>>>>     >>> I note that these recommendations
>>>>    now seem
>>>>>          crazily
>>>>>          >     long. I
>>>>>          >     >>>>>> assume the
>>>>>          >     >>>>>>>     >>> WG had consensus on this, but I
>>>>    wanted to
>>>>>          note it.
>>>>>          >     >>>>>>>     >>
>>>>>          >     >>>>>>>     >> Not just the WG, also the IESG that
>>>>>          approved RFC 5389
>>>>>          >     too as,
>>>>>          >     >>>> but
>>>>>          >     >>>>>> for the
>>>>>          >     >>>>>>>     >> addition of "or DTLS-over-UDP",
>>>>    this is the
>>>>>          same text
>>>>>          >     than in
>>>>>          >     >>>> RFC
>>>>>          >     >>>>>> 5389.
>>>>>          >     >>>>>>>     >>
>>>>>          >     >>>>>>>     >
>>>>>          >     >>>>>>>     > Yes, I know. My point is that while they
>>>>>          might have bee
>>>>>          >     >> sensible
>>>>>          >     >>>>>> when
>>>>>          >     >>>>>>>     > 5389 was published they *now* seem
>>>>    crazily
>>>>>          long. Did
>>>>>          >     the WG
>>>>>          >     >>>>>> explicitly
>>>>>          >     >>>>>>>     > decide not to update them?
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>     No, nobody ever suggested that there
>>>>    was an
>>>>>          issue there.
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>> OK, well, this seems like it should be
>>>>    considered,
>>>>>          then,
>>>>>          >     because this
>>>>>          >     >>>>>>> doesn't
>>>>>          >     >>>>>>> match modern practice.
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>     > This would be good to explain.
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>     New text:
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>        [...]
>>>>>          >     >>>>>>>        containing the subjectAltName of that
>>>>>          certificate. 
>>>>>          >     The test
>>>>>          >     >> on
>>>>>          >     >>>>>> the
>>>>>          >     >>>>>>>        MESSAGE-INTEGRITY-SHA256 attribute
>>>>>          indicates that the
>>>>>          >     >>>> transaction
>>>>>          >     >>>>>> is
>>>>>          >     >>>>>>>        authenticated and that the client
>>>>>          implements this
>>>>>          >     >> specification
>>>>>          >     >>>>>> and
>>>>>          >     >>>>>>>        so can process the ALTERNATE-DOMAIN
>>>>    attribute.
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>> All right.
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>     >
>>>>>          >     >>>>>>>     >
>>>>>          >     >>>>>>>     >>>>      o  What authentication and
>>>>>          message-integrity
>>>>>          >     mechanisms
>>>>>          >     >>>>>> are used.
>>>>>          >     >>>>>>>     >>>>
>>>>>          >     >>>>>>>     >>>>      o  The considerations around
>>>>    manual vs.
>>>>>          >     automatic key
>>>>>          >     >>>>>> derivation
>>>>>          >     >>>>>>>     >> for
>>>>>          >     >>>>>>>     >>>>         the integrity mechanism, as
>>>>>          discussed in
>>>>>          >     [RFC4107].
>>>>>          >     >>>>>>>     >>>>
>>>>>          >     >>>>>>>     >>>>      o  What mechanisms are used to
>>>>>          distinguish STUN
>>>>>          >     >> messages
>>>>>          >     >>>>>> from other
>>>>>          >     >>>>>>>     >>>
>>>>>          >     >>>>>>>     >>> Why is this required? It seems
>>>>    like that's
>>>>>          a generic
>>>>>          >     STUN
>>>>>          >     >>>>>> feature.
>>>>>          >     >>>>>>>     >>
>>>>>          >     >>>>>>>     >> That text is identical to the text
>>>>    in RFC
>>>>>          5389.  RFC
>>>>>          >     5764/7983
>>>>>          >     >>>> is
>>>>>          >     >>>>>> one such
>>>>>          >     >>>>>>>     >> mechanism, but there is nothing that
>>>>>          prevent another
>>>>>          >     protocol
>>>>>          >     >>>>>> stack to use
>>>>>          >     >>>>>>>     >> a different mechanism (inference,
>>>>    shim, etc...)
>>>>>          >     >>>>>>>     >>
>>>>>          >     >>>>>>>     >
>>>>>          >     >>>>>>>     > But ultimately no matter what the
>>>>    other protocol
>>>>>          >     provides for
>>>>>          >     >>>>>> demux, STUN
>>>>>          >     >>>>>>>     > has its
>>>>>          >     >>>>>>>     > own demux.
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>     In fact I think that the reason for
>>>>    that item
>>>>>          was because
>>>>>          >     >>>>>>>     FINGERPRINT can also be used to demux STUN
>>>>>          traffic, but
>>>>>          >     it is
>>>>>          >     >>>>>>>     optional.  So an STUN Usage needs to
>>>>    tell if
>>>>>          FINGERPRINT is
>>>>>          >     >>>>>>>     mandatory (like in ICE).
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>> This should be explained.
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>     >>>
>>>>>          >     >>>>>>>     >>>>      that is not readily subject to
>>>>>          offline dictionary
>>>>>          >     >>>> attacks.
>>>>>          >     >>>>>>>     >>>>      Protection of the channel
>>>>    itself,
>>>>>          using TLS or
>>>>>          >     DTLS,
>>>>>          >     >>>>>> mitigates
>>>>>          >     >>>>>>>     >> these
>>>>>          >     >>>>>>>     >>>>      attacks.
>>>>>          >     >>>>>>>     >>>>
>>>>>          >     >>>>>>>     >>>>      STUN supports both
>>>>    MESSAGE-INTEGRITY and
>>>>>          >     >>>>>>>     MESSAGE-INTEGRITY-SHA256,
>>>>>          >     >>>>>>>     >>>>      which is subject to bid down
>>>>    attacks
>>>>>          by an on-path
>>>>>          >     >>>>>> attacker.
>>>>>          >     >>>>>>>     >>>
>>>>>          >     >>>>>>>     >>> By an on-path attacker who can forge
>>>>>          HMAC-SHA1 in
>>>>>          >     real-time?
>>>>>          >     >>>>>>>     That's a
>>>>>          >     >>>>>>>     >>> pretty serious adversary, so you
>>>>    should
>>>>>          clarify here
>>>>>          >     >>>>>>>     >>>
>>>>>          >     >>>>>>>     >>
>>>>>          >     >>>>>>>     >> New text:
>>>>>          >     >>>>>>>     >>
>>>>>          >     >>>>>>>     >>    STUN supports both
>>>>    MESSAGE-INTEGRITY and
>>>>>          >     >>>>>> MESSAGE-INTEGRITY-SHA256,
>>>>>          >     >>>>>>>     >>    which is subject to bid down
>>>>    attacks by
>>>>>          an on-path
>>>>>          >     attacker
>>>>>          >     >>>>>> that
>>>>>          >     >>>>>>>     >>    would strip the
>>>>    MESSAGE-INTEGRITY-SHA256
>>>>>          attribute
>>>>>          >     leaving
>>>>>          >     >>>>>>>     only the
>>>>>          >     >>>>>>>     >>    MESSAGE-INTEGRITY attribute and
>>>>>          exploiting a potential
>>>>>          >     >>>>>>>     vulnerability.
>>>>>          >     >>>>>>>     >>    Protection of the channel
>>>>    itself, using
>>>>>          TLS or DTLS,
>>>>>          >     >>>> mitigates
>>>>>          >     >>>>>>>     these
>>>>>          >     >>>>>>>     >>    attacks.  Timely removal of the
>>>>    support of
>>>>>          >     >> MESSAGE-INTEGRITY
>>>>>          >     >>>>>> in a
>>>>>          >     >>>>>>>     >>    future version of STUN is necessary.
>>>>>          >     >>>>>>>     >>
>>>>>          >     >>>>>>>     >
>>>>>          >     >>>>>>>     > I still don't understand the
>>>>    capabilities
>>>>>          you seem to
>>>>>          >     believe
>>>>>          >     >> the
>>>>>          >     >>>>>>>     attacker
>>>>>          >     >>>>>>>     > has.
>>>>>          >     >>>>>>>     > Can you describe the exact attack.
>>>>>          >     >>>>>>>     >
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>     1. Vulnerability is found in HMAC-SHA1
>>>>>          >     >>>>>>>     2. Client Alice still supports M-I and
>>>>>          M-I-256, does not
>>>>>          >     know
>>>>>          >     >> what
>>>>>          >     >>>>>>>     version of STUN server Bob supports and so
>>>>>          send both.
>>>>>          >     >>>>>>>     3. On-path attacker removes M-I-256.
>>>>>          >     >>>>>>>     5. stunbis server Bob thinks that
>>>>    Alice is an
>>>>>          RFC 5389
>>>>>          >     client and
>>>>>          >     >>>>>>>     continue with that protocol.
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>> This seems like an extremely weak attack. In
>>>>>          general, any
>>>>>          >     protocol of
>>>>>          >     >>>>>>> this type is as strong
>>>>>          >     >>>>>>> as the weakest integrity algorithm it
>>>>    supports, so
>>>>>          it's not
>>>>>          >     that the
>>>>>          >     >>>>>>> protocol has a downgrade
>>>>>          >     >>>>>>> attack, but rather that the minimum algorithm
>>>>>          supported is
>>>>>          >     one you
>>>>>          >     >>>> don't
>>>>>          >     >>>>>>> trust as much
>>>>>          >     >>>>>>> as you might like.
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>> -Ekr
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>
>>>>>          >     >>>>>>>     --
>>>>>          >     >>
>>>>>          >
>>>>>          >
>>>>>          >
>>>>>          >     --
>>>>>          >     Marc Petit-Huguenin
>>>>>          >     Email: marc@petit-huguenin.org
>>>>    <mailto:marc@petit-huguenin.org>
>>>>>          <mailto:marc@petit-huguenin.org
>>>>    <mailto:marc@petit-huguenin.org>> <mailto:marc@petit-huguenin.org
>>>>    <mailto:marc@petit-huguenin.org>
>>>>>          <mailto:marc@petit-huguenin.org
>>>>    <mailto:marc@petit-huguenin.org>>>
>>>>>          >     Blog: https://marc.petit-huguenin.org
>>>>    <https://marc.petit-huguenin.org/>
>>>>>          >     Profile: https://www.linkedin.com/in/petithug
>>>>>          >
>>>>>
>>>>
>>>
>