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: 1; VI1PR07MB3279; 23:68ZEWxN8SyQwRy0GznankcGASfSjZsg2XPyiAIL1STJBdZLW/VoGkf2zkXrzYxw8o3N1Sr7v2DMVnhLgapZ4uSquBidxmA07Ai+FyAYBMM0VYAl8jlSV7lJjnKvLJDgJ1gU40Jli/M9HnCxXOIL/VhbDyqNUYKxCRMD2f2JWZUuixQRLgPjZXQSnUGMMvO6m95EjbLXUb5q3OP9pYZhFfewK19OptOTpI/y/w45BONw+0kIuhzOiZkUKxZog1yrCJ+u7ZhGyt/Q5mFzbmZLhWtgwIzotArA3ptRAsE0Hq3ziVOpVBeP1tDYPgdqMe0QdzpwmWqIZ783J9Nf/j0WAYV7XybuMNLuvlPw4aMBn8sF/QWLazYn4o4AhcyMy5El1KqQjFIiWkCov43AyYUHYFzmIXkNPBGZ0FKE0EEXQBPT/a4hEBPGfMGtyimDNEe+2FUfVIYYXCjVS2Vk3AfXPPHi28UjZO0IoPK3g91WtT5bfK1N0TGNzjSQ921BWnTfubPjU7laGqVcGVajCRSmCg8O65QzIeA26Z5a8KbisYUu4UdJts3pRykNL26CJPES3FPa9JRvXU2t4Bukf43IGBtfLGTwD3+8J6CaST5+i8mOUlM8gn8rtyVVlrJmfof/NayZE0wXA8uySlAeWCxPHzAGOD+u4EzIcFFkoEXhhy+kDGBXMhlMIttW65IPWB21wI07CsffQEhr0kMUgwd3NOMVmgWnPN7o8JgKXuj7KoDNkhJzzMHJd1EeiFr15IjMfty2qR666CPPHj0KL8Jn9M48/IH/IuZWlzRMmr/yjfrad0mRbkB8RxzIzMxlNc+6s0yrmPUEO+K+WP9Pk0TL1lIMxMp7qwDsA6hkMKJjdqiP1LAacDqASb4/pvMoJaYKe1xxjsOu8uI0L3YlyphfzZqQiDoNu8BHrMtmYyJVmHl/Y1UxZDW4Oc1cWlQY80MxFIbjdYMOZoNkrHvLKIdx8AiFR8YQ9WjK8xqwD1E/lIibtHrkhTCdnbzJyUH2WyfP/K+lfXryyNCngSCyeFxvE9dGksXJq3fchxfzTtVzFQtgMfQZeE6MXZt9/vM6criWNV+mkbDg1Iog/wiaACN0InOIww+Q+6+QOCat/wEC2YH+K9aMU1XMueplYl5LsnrbsRS+oFh6PL58f/wplLoHG1Wjb5blfAzjzWyF6cEhDmYOLEa7sOaXEtt/KcWvq4tHUoN6k6jw+UOKYKoVZcGd41x6VMwi8/iDICCDzaBTtl9qfmZmoO43PUDIvjlmmLs/pbUOVdaMMnWXqvFiko2L2MqfoLU+AphuuHtEfDZWDeNAC/IAV9bvuaNR3e9EGF53uxoySBnBH6Gtb6BKPlG0neUeTU1LT7pMCE6ZNI+uRG7pTz0P0DXnT9YkI2fLFRBvq4PNqCPnf/09PeqopJb0zVI3bitHj4dPUDdzVNxHeXpLIphTRqvrDTlvdtzj9dOjqOnC24APmlZ12tjfTbjO9Kw==
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 >> > > >> > >> >
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Camarillo
- [tram] Eric Rescorla's Discuss on draft-ietf-tram… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Marc Petit-Huguenin
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Marc Petit-Huguenin
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Marc Petit-Huguenin
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Marc Petit-Huguenin
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Brandon Williams
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Matthew A. Miller
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Brandon Williams
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Marc Petit-Huguenin
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Marc Petit-Huguenin
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Spencer Dawkins at IETF
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Marc Petit-Huguenin
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Spencer Dawkins at IETF
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Camarillo
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Spencer Dawkins at IETF
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Camarillo
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Camarillo
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Salgueiro (gsalguei)
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Camarillo
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Salgueiro (gsalguei)
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Camarillo
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Spencer Dawkins at IETF
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Salgueiro (gsalguei)
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Salgueiro (gsalguei)
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- [tram] Blackout posting of draft-ietf-tram-stunbi… Spencer Dawkins at IETF
- Re: [tram] Blackout posting of draft-ietf-tram-st… Gonzalo Salgueiro (gsalguei)