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

Gonzalo Camarillo <gonzalo.camarillo@ericsson.com> Mon, 18 February 2019 13:18 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 59292128B14 for <tram@ietfa.amsl.com>; Mon, 18 Feb 2019 05:18:54 -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_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=ericsson.com header.b=RnToR+HD; dkim=pass (1024-bit key) header.d=ericsson.com header.b=NH5P3ncy
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 FVHJrsHcCAbg for <tram@ietfa.amsl.com>; Mon, 18 Feb 2019 05:18:51 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 D46E0130EFC for <tram@ietf.org>; Mon, 18 Feb 2019 05:18:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1550495924; x=1553087924; 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=922gTjpoawYTlImN5jRoeDnyYJJV+6VapWr8XKQCC4I=; b=RnToR+HDy2RqZGLamdGxRKKxzKMH1Q1La2e2tZFjLWJDzv8+WoQFK3sCmCq6A7A1 C+pYcHj5co6FbwAPOb1hP5GlA4XVJVIVA5tcnk/7mmQxjMd44bGOaejIEc/pyOkN dQlxqNsieIVkuRDQFfrxAT63+Lxdi/+7oWwm0IqJNUY=;
X-AuditID: c1b4fb25-da1ff70000005ff7-b7-5c6ab0b4bbfc
Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 25.3E.24567.4B0BA6C5; Mon, 18 Feb 2019 14:18:44 +0100 (CET)
Received: from ESESSMR505.ericsson.se (153.88.183.127) by ESESSMB504.ericsson.se (153.88.183.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 18 Feb 2019 14:18:44 +0100
Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESSMR505.ericsson.se (153.88.183.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 18 Feb 2019 14:18:43 +0100
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) 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; Mon, 18 Feb 2019 14:18:43 +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=922gTjpoawYTlImN5jRoeDnyYJJV+6VapWr8XKQCC4I=; b=NH5P3ncy63XQk7xPMUJxOn/UQiMIBdh8sxyXA5adRAcpWvyImu1rQenYtcjVdzKJsZjj/LUuIvp1IsDe96kafauSsExbmJw13HVDmDLE0gRC4TT66KG2YFo6RFXdBpwymHswHwT+Ra1fzO0PSZtkIij2b//KZQwq6gMDO5dSF10=
Received: from VI1PR07MB5421.eurprd07.prod.outlook.com (20.178.15.15) by VI1PR07MB3279.eurprd07.prod.outlook.com (10.175.243.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.7; Mon, 18 Feb 2019 13:18:42 +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.008; Mon, 18 Feb 2019 13:18:42 +0000
From: Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
To: "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>, Eric Rescorla <ekr@rtfm.com>
CC: 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>, "Asveren, Tolga" <tasveren@rbbn.com>, 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: AQHUx4x3Akxfdr43yEypZttwA368ow==
Date: Mon, 18 Feb 2019 13:18:42 +0000
Message-ID: <VI1PR07MB5421AC5849B762B682B52D6883630@VI1PR07MB5421.eurprd07.prod.outlook.com>
References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <c0a06754-6f8c-97dc-7f7e-26a7df43e842@acm.org> <CABcZeBNk4KWA1Bzw7=i=Siie_6Vf7v-v2cfDyA4WvSAE2D9hrA@mail.gmail.com> <02569943-db8f-654e-7322-49bc1f1a1163@acm.org> <CABcZeBN2=a90qbgo8MkihVFpO2bBzi2Ceepj3UpXVxAZJKJrxg@mail.gmail.com> <235b838f-2800-2cd0-8b01-947e70837619@ericsson.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>
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=gonzalo.camarillo@ericsson.com;
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 454d4e70-6180-4027-2f29-08d695a39aac
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB3279;
x-ms-traffictypediagnostic: VI1PR07MB3279:
x-ms-exchange-purlcount: 5
x-microsoft-exchange-diagnostics: =?Windows-1252?Q?1; VI1PR07MB3279; 23:68ZEWxN8SyQwRy0GznankcGASfSjZsg2XPyiA?= =?Windows-1252?Q?IL1STJBdZLW/VoGkf2zkXrzYxw8o3N1Sr7v2DMVnhLgapZ4uSquBidxm?= =?Windows-1252?Q?A07Ai+FyAYBMM0VYAl8jlSV7lJjnKvLJDgJ1gU40Jli/M9HnCxXOIL/V?= =?Windows-1252?Q?hbDyqNUYKxCRMD2f2JWZUuixQRLgPjZXQSnUGMMvO6m95EjbLXUb5q3O?= =?Windows-1252?Q?P9pYZhFfewK19OptOTpI/y/w45BONw+0kIuhzOiZkUKxZog1yrCJ+u7Z?= =?Windows-1252?Q?hGyt/Q5mFzbmZLhWtgwIzotArA3ptRAsE0Hq3ziVOpVBeP1tDYPgdqMe?= =?Windows-1252?Q?0QdzpwmWqIZ783J9Nf/j0WAYV7XybuMNLuvlPw4aMBn8sF/QWLazYn4o?= =?Windows-1252?Q?4AhcyMy5El1KqQjFIiWkCov43AyYUHYFzmIXkNPBGZ0FKE0EEXQBPT/a?= =?Windows-1252?Q?4hEBPGfMGtyimDNEe+2FUfVIYYXCjVS2Vk3AfXPPHi28UjZO0IoPK3g9?= =?Windows-1252?Q?1WtT5bfK1N0TGNzjSQ921BWnTfubPjU7laGqVcGVajCRSmCg8O65QzIe?= =?Windows-1252?Q?A26Z5a8KbisYUu4UdJts3pRykNL26CJPES3FPa9JRvXU2t4Bukf43IGB?= =?Windows-1252?Q?tfLGTwD3+8J6CaST5+i8mOUlM8gn8rtyVVlrJmfof/NayZE0wXA8uySl?= =?Windows-1252?Q?AeWCxPHzAGOD+u4EzIcFFkoEXhhy+kDGBXMhlMIttW65IPWB21wI07Cs?= =?Windows-1252?Q?ffQEhr0kMUgwd3NOMVmgWnPN7o8JgKXuj7KoDNkhJzzMHJd1EeiFr15I?= =?Windows-1252?Q?jMfty2qR666CPPHj0KL8Jn9M48/IH/IuZWlzRMmr/yjfrad0mRbkB8Rx?= =?Windows-1252?Q?zIzMxlNc+6s0yrmPUEO+K+WP9Pk0TL1lIMxMp7qwDsA6hkMKJjdqiP1L?= =?Windows-1252?Q?AacDqASb4/pvMoJaYKe1xxjsOu8uI0L3YlyphfzZqQiDoNu8BHrMtmYy?= =?Windows-1252?Q?JVmHl/Y1UxZDW4Oc1cWlQY80MxFIbjdYMOZoNkrHvLKIdx8AiFR8YQ9W?= =?Windows-1252?Q?jK8xqwD1E/lIibtHrkhTCdnbzJyUH2WyfP/K+lfXryyNCngSCyeFxvE9?= =?Windows-1252?Q?dGksXJq3fchxfzTtVzFQtgMfQZeE6MXZt9/vM6criWNV+mkbDg1Iog/w?= =?Windows-1252?Q?iaACN0InOIww+Q+6+QOCat/wEC2YH+K9aMU1XMueplYl5LsnrbsRS+oF?= =?Windows-1252?Q?h6PL58f/wplLoHG1Wjb5blfAzjzWyF6cEhDmYOLEa7sOaXEtt/KcWvq4?= =?Windows-1252?Q?tHUoN6k6jw+UOKYKoVZcGd41x6VMwi8/iDICCDzaBTtl9qfmZmoO43PU?= =?Windows-1252?Q?DIvjlmmLs/pbUOVdaMMnWXqvFiko2L2MqfoLU+AphuuHtEfDZWDeNAC/?= =?Windows-1252?Q?IAV9bvuaNR3e9EGF53uxoySBnBH6Gtb6BKPlG0neUeTU1LT7pMCE6ZNI?= =?Windows-1252?Q?+uRG7pTz0P0DXnT9YkI2fLFRBvq4PNqCPnf/09PeqopJb0zVI3bitHj4?= =?Windows-1252?Q?dPUDdzVNxHeXpLIphTRqvrDTlvdtzj9dOjqOnC24APmlZ12tjfTbjO9K?= =?Windows-1252?B?dz09?=
x-microsoft-antispam-prvs: <VI1PR07MB3279BE8CFFA07D61219112AA83630@VI1PR07MB3279.eurprd07.prod.outlook.com>
x-forefront-prvs: 09525C61DB
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(376002)(39860400002)(346002)(366004)(54094003)(199004)(189003)(51444003)(51914003)(446003)(71190400001)(71200400001)(305945005)(7736002)(74316002)(106356001)(2906002)(4326008)(6246003)(97736004)(5660300002)(8936002)(86362001)(229853002)(30864003)(256004)(14444005)(81166006)(81156014)(8676002)(476003)(186003)(478600001)(33656002)(53936002)(45080400002)(561944003)(7696005)(6306002)(55016002)(76176011)(9686003)(53946003)(14454004)(6116002)(3846002)(102836004)(53546011)(6506007)(99286004)(93886005)(6436002)(66066001)(110136005)(316002)(25786009)(105586002)(966005)(54906003)(44832011)(486006)(26005)(68736007)(559001)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3279; 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: 19Q1G2lF4F8GpOABWZ9iUMRNph3gnjt93mjDH22C7MNqphEmtPg4bXj72IPi1/3fFh6KwEA30t4QqIYEJdbDK62cd8LLS/N3ELkC08kICpAi+GOE2mpvlDSNKa/D25h0yXC5B/8hdw/OwMmnd8wrWlT0+jEZKzZDQ7pKftnJSWqxnSsWeWfsjjZno35QbJWhZTzvf4X6hzMiUNZcfWZR9uvpbG1OMQs6AlwCvTyp4Nje+4uAgyLzS7brpL3EX8Q6qaZbTJbhyUoSmIUP9pbKc0ZCLmKSpqGAIT0lgi5TJ2NsMsOKVx+DQYhpTQXRjCTz2tP5uxinN+94sqOYfDGcu8MQ+FAXFFwBDIyznn1XxtLly4JbzNfgx0IuGwoxly81Rgfn8N6KLGL6yJsgvxoIGHZpwwt0QNf0jgZRdPEh2M8=
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 454d4e70-6180-4027-2f29-08d695a39aac
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2019 13:18:42.5506 (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-Transport-CrossTenantHeadersStamped: VI1PR07MB3279
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHeXfOzo7W6HXenrSoVhYZLbWwQ6UYfRlZURBUJtTSg/dpm5MU TD+opamZWl7zQuJdNDMzXN4IykgzHWrGyqYmU0vNUtRhuZ1Fffv/n//veZ/nfXlpQtTOd6CD 5JGsQi4LFVOWZN7FZzH7mxqCfV1mRhyZ5KYBiqmc7hUwD7PPMLmGewTTV6vlMeXZaoKpr1gU MBXLVRQzV9dHeVlIBzTe0uzVx3zp83ytQFpWtsyTqgszkTRrLIk4S/lYHvNnQ4OiWMUBz6uW gVMJ9YKIX5PEjdae12Q8+jTHS0EWNOBDkDyvpVKQJS3CLxGk3o3ncWYRwdvO9//M6NIjM1bG A83PW4TRkDiDgGFtAeKSTB48GJ4QcEaHID9pZL2HpinMwO0ad+NEG3wB1MONpm4Cd/BgQa0z rWKNA+Dj1BDfyNvgQBhYPcnxEtDpvlFGTWInKO14hYxaiH1hvDCL5GblWEB1+6DAGCBsB0tv ak1nEtgeRsaLzVfFUKZ+R3DaFvRja3yOl8FoYp25vgN6vn8x81uhv/gO4vRpSG0dMw0D/AHB cLee5AJnKPjaY4YcoP1JEeKgBQzTFWvmk0Lg/qje9BKAt0DLj8Mc00ZBUbUGZSBJ/n/LctoF ZnuLCU7vg/LSaZMWYivozhsnSxBZjWyVrPJaWIDbQQmrCPJTKsPlEjkb2YjWv1Vn06pTCxqY Od6FMI3EG4WSmmBfEV8WpYwO60JAE2IbYXr9eknoL4uOYRXhVxSqUFbZhRxpUmwvNIisfEU4 QBbJhrBsBKv4m/JoC4d4ZCfPWdlR5PG0avFEM1FrXeCTPNF/iTDsyfPIIW+WH1l1UqmI7cHe 9Z+9rHWeztlpbnq2OzEN+6Un7Jad/+0T46Y65X40E1LtsqyKWkvyKnel1cR6bTa8mKUW4ja1 a87Nu64Imyc3VG2LQ22X84cCru/N1cfmqkTajp2DDa0zNmJSGShzdSYUStkfCnx8YVIDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/gZ7rDA7HZEu_mJgHxNz_b3YJqEE>
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: Mon, 18 Feb 2019 13:18:55 -0000

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