Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)
Gonzalo Camarillo <gonzalo.camarillo@ericsson.com> Wed, 20 February 2019 12:03 UTC
Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4812E1310DE for <tram@ietfa.amsl.com>; Wed, 20 Feb 2019 04:03:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=GKXiBu7E; dkim=pass (1024-bit key) header.d=ericsson.com header.b=VKeDf15Q
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6b61DOYF72Jt for <tram@ietfa.amsl.com>; Wed, 20 Feb 2019 04:03:09 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87036130E76 for <tram@ietf.org>; Wed, 20 Feb 2019 04:03:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1550664179; x=1553256179; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7cAs27INQzdhqHbRI8UxPpaVAkiM5CWIPYDpbQETuNY=; b=GKXiBu7EMYy+6niO6tA2e/X1BR4V4rro/PkB8akK1jtmVPe1r6QHYqKq2NS6IzUt OlYhSlwDsYoy6c56CuZ8MluJptijjyMYEuNGERwcPAJbSNg72atS4FB7Mz5gsxCr u1GnlO/In7ydbL9+uWQ8VZnI0h+htAD0O3BsvZJ6JU4=;
X-AuditID: c1b4fb2d-2198b9e00000062f-3f-5c6d41d9e0e6
Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 31.8B.01583.9D14D6C5; Wed, 20 Feb 2019 13:02:59 +0100 (CET)
Received: from ESESBMR502.ericsson.se (153.88.183.134) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 20 Feb 2019 12:56:51 +0100
Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESBMR502.ericsson.se (153.88.183.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 20 Feb 2019 12:56:51 +0100
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 20 Feb 2019 12:56:51 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7cAs27INQzdhqHbRI8UxPpaVAkiM5CWIPYDpbQETuNY=; b=VKeDf15QTXCddiv01ECf2becfIz9/J3xR5QaRYazmUZxrNQE/zXPjT9MFPFREqNJMWzl5LXIBxKq/KV26xNEK8okF84x1zIq1Z0CnHKvns2Oz2FDcgGyjPYj5RMj5Xc+oAqEiZqVdImhsdetvv1G2CZgfXW78obGuQa2rGDAFYs=
Received: from VI1PR07MB5421.eurprd07.prod.outlook.com (20.178.15.15) by VI1PR07MB4784.eurprd07.prod.outlook.com (20.177.57.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.11; Wed, 20 Feb 2019 11:56:49 +0000
Received: from VI1PR07MB5421.eurprd07.prod.outlook.com ([fe80::1559:7df1:b61a:4391]) by VI1PR07MB5421.eurprd07.prod.outlook.com ([fe80::1559:7df1:b61a:4391%2]) with mapi id 15.20.1643.014; Wed, 20 Feb 2019 11:56:49 +0000
From: Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
To: "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>
CC: Eric Rescorla <ekr@rtfm.com>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Marc Petit-Huguenin <petithug@acm.org>, "tram-chairs@ietf.org" <tram-chairs@ietf.org>, "tram@ietf.org" <tram@ietf.org>, IESG <iesg@ietf.org>, "draft-ietf-tram-stunbis@ietf.org" <draft-ietf-tram-stunbis@ietf.org>
Thread-Topic: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)
Thread-Index: AQHUa0FPQa4RlvmGQ0G0i0rcGeSYLqXoiXoAgADGtIA=
Date: Wed, 20 Feb 2019 11:56:49 +0000
Message-ID: <4b8f10f7-1eee-c8bc-d9ee-e3f18473de32@ericsson.com>
References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <CABcZeBMn1G8BT13bx3JTs04zwQk8K72+btj=xwC662F5AcANXg@mail.gmail.com> <cbb48225-5089-9275-787c-38fa4504a6a4@acm.org> <CABcZeBPNwu-tr8Tf_DiW2iOVy2NDEJoLwAR-6=EWHZak2gVMYg@mail.gmail.com> <c135ad63-bb18-a5f2-4aa2-e2a3268ac26f@acm.org> <CAKKJt-e1XFJNrx-LKmpZFDy6ZuaXt5+Lp+Uw90-Bu-M22PMt3Q@mail.gmail.com> <472563ee-5fc3-655d-8e31-138cc774e608@acm.org> <CAKKJt-dXijVNnAtYojq9x=9_m0pwAM8XTNP8wUEMvAa+m9UXUA@mail.gmail.com> <af0635b1-e731-0198-3b71-e3267bc10d0e@ericsson.com> <CABcZeBPoFnMBQrfDWcc5TV-=HRRX5CVWM2MO6Byf1QvSYztV3w@mail.gmail.com> <CAKKJt-ekdJuDsGFRQziYdeGqemBiVaQVpUYJiZXuTdNDQU9ySg@mail.gmail.com> <97c561a7-c33a-6121-00c4-09cd11646b98@ericsson.com> <CABcZeBPuLPha64QybuPUc-W+fR2Bqn1rAzDsb908uBNqC9z50A@mail.gmail.com> <D99F4FB6-EA38-49F6-AE00-83570455C6D7@cisco.com> <VI1PR07MB5421AC5849B762B682B52D6883630@VI1PR07MB5421.eurprd07.prod.outlook.com> <CEA96BE8-B0B2-4566-BFB1-6D387D2B1BD6@cisco.com>
In-Reply-To: <CEA96BE8-B0B2-4566-BFB1-6D387D2B1BD6@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [89.166.49.243]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
x-clientproxiedby: HE1PR0902CA0003.eurprd09.prod.outlook.com (2603:10a6:3:e5::13) To VI1PR07MB5421.eurprd07.prod.outlook.com (2603:10a6:803:bc::15)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=gonzalo.camarillo@ericsson.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b72c9727-d222-41bf-4ed0-08d6972a7eff
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB4784;
x-ms-traffictypediagnostic: VI1PR07MB4784:
x-ms-exchange-purlcount: 5
x-microsoft-exchange-diagnostics: 1;VI1PR07MB4784;23:waaFh7hjlSOGAcF2avmqiEmd+Tt9hc+jlon0cz4oQY7C2c+yHzVhqQ96NOZNf7mGmCFgvTaNUUQZgzqQ8WdWBgpQJWiJHurFooSrR7M9m8kOGS3rh3fPQScSnPziEAboHE4/+pbrps+kwqVdzquGPoysa/ECDj7sQAIFvmU67IxlKR37IGOpnC+H4jPesAjxTYHt6dPohqetz8hJVeGAGY2Gdc9hA/smYrBXGQVIF7lngNFlI6SdHDqkwTPm86l2oy1tlV8MGkeLV0Um+5+JvMmLCtOtp/y0XbFiRqW8SoREotNGw3wHdg3OCg8HIU4DxVC9HLZOCP0bSzDQjb9vsuOiW7WHvdipIC9uweAsZ3pZikxhXexK/6jx+rc1eQbATx3I3FsnpMt9NhS6Dh7QPb7rfduB4jGq0B8w9HN3OMplhTJEA4mB40M4qC0E9tz6ElRe6fJ8Mmohfmf3c/jrh+fSaxswBr8MTpULD+h3C3HDSLKRZUz43VPcZ5nH0fd7mOHTQWhmc+6AnWqNoYz+ytPGG5Si8N8UCalSUn9iPr6kcbejt8aohMnBBEse0sVcG0sqUx74+oW4TpN7AhoF88Aqof94ViY/MyNabcoe/dXRYQFQ8MEQ7TQHcyzgAn7pt+WiYJIJekkLwVdi8tK8ykpL/5DNl+Htpje01gAwZn4IBnQqMEVnbdiUHMpp1bZGFoJ+7zlMHGKLECStpmWyJfO3MsnMpH7fVMGe4gqdtcTYRbftZf2xyQFVRQ3vCgMU0wfrKkEQo6UONlcMtGYUKj+aDhA9KoEaNi3OVjN1w69tT37WqGGa1n8M+medO5Bis3TCrynACqiMn0hiYy2SKoa0YhtU3XtwMlDu7EXuxYp3WRHdj4SnYq+LOWnrIMvzK1VMM6Nhgqm+hPDjOROVtAh3lcc6IcmPwvxETbR/SznmAYyk1q/To0VoRZW3Rhb4ChLqOhfBX5YsBcE4rw1HKfWidfyk4B4KKL1v13G9N+yRpg6SBiuioJNAZRF4oI8yeVp8lumEZyR71NdskOE8GxGSBjwDmwahW8+1LZSUjUhhP/U0qwrVW0TamRbDXQk0o4VI9zEyQJL/QVlc2iGazF+swHHCDKZv5Yta7RGPWy/xOS6qAMTqyxS+h6tyymiFmsLS+sSi3/giV6g0icbDWg9M/Z1k27DKZoRbgwvDJkwP4fGLm+tz+YhxmoRHbJxTzT3IAEhjcOAln7jJyP8mB9yI4fNSHIwmC2YpJPrhnZ8G4GZrPHuv7C8v3uwlCB5RSlR7PGuyRCQ8CwMTchL4fg6d2/9g2wm/qD4rWX/dpEKf2EpB6S01Iq/fKBCE3Mh5MTi8r1OHOuMAkrZT37/DcNPna4CctRo9QBbw6sRR7XCm8raJgk0/I73vvCddGHJ+ESJpL780btCLwtzhAPerAP4YBN6ffBHDqxIay0REgIuXX2EDPqWsQEKDV7oX+IMqMmYi990JgFKvvF/GQ6pSj7vgVjILxpjtxywoDQiFap4KJjAKVFxz1uP+t7MakmrMTodlMWwjOG2f21q9BGwaySZbkvTQ9KEcOWTVGqInNFHbmxv+32vo4tgGrZHokAauhQQgSbcpW2q/PBEXb/QCS/xgCOb0iQLfoYhdAkj2PlQVnpTe079E6fGine1FaR66
x-microsoft-antispam-prvs: <VI1PR07MB4784138D9787164B1941DEC2837D0@VI1PR07MB4784.eurprd07.prod.outlook.com>
x-forefront-prvs: 0954EE4910
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(346002)(376002)(136003)(199004)(189003)(51914003)(51444003)(54094003)(53936002)(256004)(71190400001)(106356001)(105586002)(6916009)(64126003)(6512007)(2906002)(446003)(71200400001)(53946003)(305945005)(81156014)(81166006)(6306002)(2616005)(316002)(8676002)(54906003)(7736002)(97736004)(58126008)(14444005)(3846002)(31686004)(386003)(6506007)(53546011)(31696002)(102836004)(6116002)(93886005)(65826007)(30864003)(86362001)(76176011)(14454004)(8936002)(6436002)(6486002)(476003)(5660300002)(966005)(66066001)(36756003)(65806001)(478600001)(11346002)(26005)(229853002)(68736007)(45080400002)(65956001)(186003)(6246003)(52116002)(99286004)(486006)(4326008)(25786009)(561944003)(559001)(579004)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4784; H:VI1PR07MB5421.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: AZHWRiukLWsrVm8zDvN3tlGn6bZNqydFOhJ+5P/dEAGY7wwSbKd2/AP3pszZaULQMq8i9zfU+BbYm1qNcgcN9mHuxMwFUhxakPq4babB/FHVWCBMQodfn83+dfO8lMokbe0zPLIwU/wtX+rnncLXUDCD/oMXXh7DYjAi1YrSf6/2H0yYGOewYveIw/ds8jJAqyMU13aZIwrqqAGA4ClKHiq4+/o06He+Ob9Xkux5fa4MpCKYSeU2cb1jLtjdjHo9fhrugpTSoAGaVGMueUY6lRv7ja6t0L9R29Dph2EOL+8iYMvMKOXcACIPSnHQ2SqAfEhVHm9Y8MhdvP3zFZS8US1h09tCVRuhwPcgPaiQ+Qb7JtaozCJLITXy4CkjtyyDoyAaIKd6GYFdRuJn1K+PUwd8U9NVdpofzyacYWwXW5w=
Content-Type: text/plain; charset="utf-8"
Content-ID: <CF119A27F40DA04080D1C297A89D73A2@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b72c9727-d222-41bf-4ed0-08d6972a7eff
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2019 11:56:48.5389 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4784
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec9l57gavE2XT7OiBhVd7GbY6Z7kh3UxCiIijBx5cJaz2Jlm RWh3NTJLY21gWo1VXrp4d45Mi8TK0mZZiyJzmmkNScriVLTtLOjb73n+//e58bKk8i6tZpNT TbwxVZeikckpy7a6tMiRGEP8/OFcmsupdsm460NPGa6ocCN38dc5kusof0tw9kInyV37eUPG DVd0yFazWlfXem2heIfWNljfMlqb7SehLeg9SW6it8uXJ/Ipyem8cd7KBLm+q2SU3ne+lcyw m29RWcjZSOaiEBbwInC0niFykZxV4gcIPt++IvMLSvwdwZMXeknwcbEzn5ICGwH3s6sYf0Dh fBKs7iOkpJwn4MaXx4wUfEDQbDP7KrOsDHOQXRbtrxuGF4NTPB7oQeJaAga/BfKhOAneDHbT fnsY1oNLXCfZl0JJqyNgp/A0uNpbGZhbgVeB+CMv2GqUge53eQEhBK+AzqFiys8Ij4fRR+WE 1Csc3J5iQloag835LHgAFXzq/UNLPBXavT0BjwrvgAs5RwOLATYjGKw/Fiyqg/cnKoKP50B7 twdJPAmeF58OchyINx8y0uPXCLoueoPCLKhyi5TEamiquoTyUZT1vwGtvgOQeCbccsyT0lro LHMzEk+FwtM9AVbgcdBm8VAliC5FKoEXBEPSwqi5vDF5lyDsTZ2bypsqke9XNVeLkfWobCim BWEWacYqdFGGeCWtSxcOGFoQsKQmTPGB8aUUiboDB3nj3p3GtBReaEERLKUJV/xSjotX4iSd id/D8/t44z+VYEPUWSimsc342WKdklG5Z5l2gtM8eVA2OW/M8Yq46Q0jEf2Pi+6V1MfXKHfH iYe1mb8vhzJo6/CAK9F7KtpUp8pxN71WWrY+mvhmTU+NPTLBNHsLvcH+IDajv1bNVF3JnsF/ fVWwWewr76CaHB5DZtvLj+uXnJu+/2ypNzx24qF3fd1rBzSUoNctmEUaBd1f4oVlhlEDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/y-pbfl6l2vpXGqyenz82MbODRLs>
Subject: Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Feb 2019 12:03:16 -0000
Thanks, Gonzalo! Please, let us know the agreed way forward once you have the call. Cheers, Gonzalo On 19-Feb-19 20:05, Gonzalo Salgueiro (gsalguei) wrote: > Hi Gonzalo - > > We have scheduled a conference call with Ekr, Simon, Marc and myself on March 7th to discuss the last two remaining issues. Will update with resolutions once this has occurred. > > Cheers, > > Gonzalo > > > >> On Feb 18, 2019, at 8:18 AM, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> wrote: >> >> Hi Gonzalo S, >> >> what is the status of this one? >> >> Thanks, >> >> Gonzalo >> >> On 18-Jan-19 20:16, Gonzalo Salgueiro (gsalguei) wrote: >>> Totally agree, Ekr. Marc and I are meeting to come up with a proposal >>> but I do agree we need to have a call to get this put to bed once and >>> for all. We’ll offer some potential dates in the next 2-3 weeks. >>> >>> Cheers, >>> >>> Gonzalo >>> >>> >>>> On Dec 26, 2018, at 8:05 PM, Eric Rescorla <ekr@rtfm.com >>>> <mailto:ekr@rtfm.com>> wrote: >>>> >>>> We really need to bring this to a close before both Spencer and I step >>>> down, I should think. >>>> >>>> -Ekr >>>> >>>> >>>> On Thu, Nov 22, 2018 at 4:30 AM Gonzalo Camarillo >>>> <gonzalo.camarillo@ericsson.com >>>> <mailto:gonzalo.camarillo@ericsson.com>> wrote: >>>> >>>> Eric, Spencer, thanks for the status update! >>>> >>>> Authors, could you please let us know when you plan to get to this? >>>> >>>> Gonzalo >>>> >>>> On 19-Nov-18 23:04, Spencer Dawkins at IETF wrote: >>>>> Hi, Gonzalo, >>>>> On Mon, Nov 19, 2018 at 9:06 AM Eric Rescorla <ekr@rtfm.com >>>> <mailto:ekr@rtfm.com> >>>>> <mailto:ekr@rtfm.com <mailto:ekr@rtfm.com>>> wrote: >>>>> >>>>> Not really. I have not received any response to my mail of >>>> Oct 23. >>>>> As before, I'm happy to have a call, but I believe we're >>>> reaching >>>>> the limits of what can be accomplished by email. >>>>> >>>>> >>>>> Eric would know best (it being his Discuss), but this is also my >>>>> understanding. >>>>> >>>>> I can add this to the agenda of the IESG informal telechat on >>>> November >>>>> 29, if there hasn't been a call before then, but I don't have a >>>> reason >>>>> to wait until then, if it's possible to talk sooner. >>>>> >>>>> Thanks, >>>>> >>>>> Spencer >>>>> >>>>> >>>>> >>>>> -Ekr >>>>> >>>>> >>>>> On Mon, Nov 19, 2018 at 6:35 AM Gonzalo Camarillo >>>>> <gonzalo.camarillo@ericsson.com >>>> <mailto:gonzalo.camarillo@ericsson.com> >>>>> <mailto:gonzalo.camarillo@ericsson.com >>>> <mailto:gonzalo.camarillo@ericsson.com>>> wrote: >>>>> >>>>> Hi Spencer, >>>>> >>>>> what is the status of this? Are the authors and the document >>>>> shepherd >>>>> working with the relevant ADs on the discusses? >>>>> >>>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/ballot/ >>>>> >>>>> Cheers, >>>>> >>>>> Gonzalo >>>>> >>>>> On 24-Oct-18 16:40, Spencer Dawkins at IETF wrote: >>>>> > Hi, Marc, >>>>> > >>>>> > On Wed, Oct 24, 2018 at 3:44 AM Marc Petit-Huguenin >>>>> <petithug@acm.org <mailto:petithug@acm.org> >>>> <mailto:petithug@acm.org <mailto:petithug@acm.org>> >>>>> > <mailto:petithug@acm.org <mailto:petithug@acm.org> >>>> <mailto:petithug@acm.org <mailto:petithug@acm.org>>>> wrote: >>>>> > >>>>> > Hi Spencer, >>>>> > >>>>> > I sent my answers to Eric Rescorla questions on >>>> 2018-10-07 >>>>> following >>>>> > an in-person meeting with my co-author, but never >>>> got a >>>>> response >>>>> > back. Because there was no change proposed by >>>> Eric I went >>>>> ahead and >>>>> > published -19 a couple of weeks after that, with >>>> the text >>>>> agreed in >>>>> > response to Adam's and Benjamin's comments. >>>>> > >>>>> > >>>>> >>>> https://www.ietf.org/mail-archive/web/tram/current/msg02635.html >>>>> > >>>>> > >>>>> > Ah - I wonder if that was what had happened. >>>>> > >>>>> > It sounds like you did the right thing, and that Eric >>>> has now >>>>> responded, >>>>> > which is also the right thing to do. >>>>> > >>>>> > Thanks for helping me understand. >>>>> > >>>>> > Spencer >>>>> > >>>>> > >>>>> > On 10/23/18 7:28 PM, Spencer Dawkins at IETF wrote: >>>>> > > Hi, Marc, >>>>> > > >>>>> > > I see that a -19 has been submitted, but didn't >>>> see a >>>>> reply from >>>>> > Eric in >>>>> > > this thread. Do you think that you've converged? >>>>> > > >>>>> > > (I saw an offer of a conference call, so thought an >>>>> out-of-band >>>>> > > conversation might have happened) >>>>> > > >>>>> > > Thanks, >>>>> > > >>>>> > > Spencer >>>>> > > >>>>> > > On Sun, Oct 7, 2018 at 9:35 AM Marc Petit-Huguenin >>>>> > <petithug@acm.org <mailto:petithug@acm.org> >>>> <mailto:petithug@acm.org <mailto:petithug@acm.org>> >>>>> <mailto:petithug@acm.org <mailto:petithug@acm.org> >>>> <mailto:petithug@acm.org <mailto:petithug@acm.org>>>> wrote: >>>>> > > >>>>> > >> Hi Eric, >>>>> > >> >>>>> > >> Please see inline. >>>>> > >> >>>>> > >> On 09/10/2018 03:25 AM, Eric Rescorla wrote: >>>>> > >>> On Sat, Sep 8, 2018 at 2:31 PM, Marc >>>> Petit-Huguenin >>>>> > <petithug@acm.org <mailto:petithug@acm.org> >>>> <mailto:petithug@acm.org <mailto:petithug@acm.org>> >>>>> <mailto:petithug@acm.org <mailto:petithug@acm.org> >>>> <mailto:petithug@acm.org <mailto:petithug@acm.org>>>> >>>>> > >>> wrote: >>>>> > >>> >>>>> > >>>> Hi Eric, >>>>> > >>>> >>>>> > >>>> Apologies for the delay in getting back to that. >>>>> > >>>> >>>>> > >>>> I think that there is some misunderstanding >>>> in what >>>>> STUNbis is >>>>> > trying to >>>>> > >>>> do, so please see my comments inline. >>>>> > >>>> >>>>> > >>>> On 06/18/2018 10:43 AM, Eric Rescorla wrote: >>>>> > >>>>> Hi folks, >>>>> > >>>>> >>>>> > >>>>> I've reviewed the new version, but I don't think >>>>> that the biddown >>>>> > >>>>> discussion makes much sense. >>>>> > >>>>> >>>>> > >>>>> To recap, there are two hashes here: >>>>> > >>>>> >>>>> > >>>>> - The hash which you use to store the >>>> password with >>>>> (currently >>>>> > mostly >>>>> > >>>> MD5) >>>>> > >>>>> - The hash you use to compute the MAC >>>> (currently SHA-1). >>>>> > >>>>> >>>>> > >>>>> First, let's stipulate that MD5 isn't a >>>> great choice >>>>> here, >>>>> > though SHA-1 >>>>> > >>>>> isn't a great choice >>>>> > >>>>> either for pwd hashing You want Argon or the >>>> like. >>>>> With that said, >>>>> > >>>> there's >>>>> > >>>>> no sensible >>>>> > >>>>> biddown attack on that hash because it's a >>>>> per-server feature, >>>>> > not a >>>>> > >>>>> per-transaction >>>>> > >>>>> feature. So, as long as the server has >>>> MD5-hashed >>>>> passwords, the >>>>> > >>>> situation >>>>> > >>>>> is bad. >>>>> > >>>> >>>>> > >>>> In no place in STUNbis we are proposing to >>>> use SHA-1 >>>>> for password >>>>> > >>>> encryption, so I am not sure where that come >>>> from. >>>>> What we >>>>> > propose is: >>>>> > >>>> >>>>> > >>> >>>>> > >>> You're right, it's SHA-256, but my criticisms >>>> apply >>>>> equally there. >>>>> > >> >>>>> > >> SHA-256 was what the WG adopted. Our attempts >>>> to add >>>>> other passwords >>>>> > >> encryption mechanisms were denied. It is true that >>>>> Argon2 was >>>>> > not in that >>>>> > >> list (in our defense Argon2 was not known >>>> before July >>>>> 2015), but >>>>> > I do not >>>>> > >> see why the WG would have accepted that one >>>> over the >>>>> others. >>>>> > Anyway it is >>>>> > >> too late to fix this, as it is my understanding >>>> that >>>>> the WG does >>>>> > not have >>>>> > >> enough energy to reach consensus on a new password >>>>> algorithm. >>>>> > Someone can >>>>> > >> just write a draft adding Argon2 as password >>>>> encryption, as we >>>>> > will have a >>>>> > >> IANA registry for that. >>>>> > >> >>>>> > >>> >>>>> > >>> >>>>> > >>>> - Establish a registry for new password >>>> algorithms >>>>> (section >>>>> > 18.5), so >>>>> > >>>> algorithms like Argon2 could be added later >>>> (but note >>>>> that our own >>>>> > >>>> proposals to add more password algorithms were >>>>> rejected by the >>>>> > working >>>>> > >>>> group). >>>>> > >>>> - Add a new password algorithm to that registry, >>>>> namely SHA-256. >>>>> > >>>> - Register MD5 as an initial password >>>> algorithm for >>>>> backward >>>>> > >> compatibility >>>>> > >>>> purpose. >>>>> > >>>> >>>>> > >>>> As for the biddown protection itself, it is my >>>>> recollection that it >>>>> > >>>> happened more or less like that: >>>>> > >>>> >>>>> > >>>> >>>>> > >>>> INT. MEETING ROOM - DAY >>>>> > >>>> >>>>> > >>>> One of the co-editors of STUNBis stands at the >>>>> microphone: >>>>> > >>>> >>>>> > >>>> CO-EDITOR >>>>> > >>>> We added SHA-256 protection for >>>>> passwords >>>>> > >>>> in STUNBis. >>>>> > >>>> >>>>> > >>>> SOMEONE (V.O.) >>>>> > >>>> As MD5 still need to be >>>> supported, >>>>> you need to add >>>>> > >>>> protection for bid-down attacks. >>>>> > >>>> >>>>> > >>>> CLOSE-UP on CO-EDITOR ROLLING HIS EYES >>>>> > >>>> >>>>> > >>>> CO-EDITOR >>>>> > >>>> OK, I'll work on that. >>>>> > >>>> >>>>> > >>>> Four to eight months has passed. >>>>> > >>>> >>>>> > >>>> INT. ANOTHER MEETING ROOM - DAY >>>>> > >>>> >>>>> > >>>> The same co-editor of STUNBis stands at the >>>> microphone: >>>>> > >>>> >>>>> > >>>> CO-EDITOR >>>>> > >>>> We added a nice mechanism to >>>> prevent >>>>> bid-down >>>>> > >>>> attacks on passwords. Any >>>> comments? >>>>> > >>>> >>>>> > >>>> THE ROOM >>>>> > >>>> (silence) >>>>> > >>>> >>>>> > >>>> CO-EDITOR >>>>> > >>>> Moving on... >>>>> > >>>> >>>>> > >>> >>>>> > >>> I don't see how any of this is relevant to my >>>>> technical points >>>>> > above. >>>>> > >> >>>>> > >> My point was that we, the co-editors, did not >>>> decide on >>>>> adding >>>>> > bid-down >>>>> > >> protection, someone asked us to do so and >>>> no-one in the >>>>> WG saw >>>>> > any problem >>>>> > >> with that. The reasons that person wanted that >>>> are not >>>>> known to >>>>> > us but, as >>>>> > >> you insist, here's one reason I can think of: >>>>> > >> >>>>> > >> It is a fact that, for operational reasons, a >>>> password >>>>> database >>>>> > cannot be >>>>> > >> re-encrypted at once. Also for operational >>>> reasons, >>>>> the MD5 password >>>>> > >> cannot be immediately removed from the database >>>> as soon >>>>> the user >>>>> > submitted >>>>> > >> a new one. In fact, and for quite some time, both >>>>> encrypted >>>>> > variants of >>>>> > >> the same password may have to be kept in that >>>> database, >>>>> because a >>>>> > single >>>>> > >> user may use a mix of devices, some of them >>>> that use an >>>>> RFC 5389 >>>>> > client, >>>>> > >> some that use a STUNbis client. It is up to >>>> the STUN >>>>> server owner to >>>>> > >> decide how long the migration to STUNbis will >>>> take and >>>>> when it >>>>> > will be >>>>> > >> acceptable to reject all RFC 5389 (i.e. MD5) >>>> clients (that >>>>> > migration time >>>>> > >> can be purposely reduced to 0 seconds but >>>> that's the >>>>> choice and >>>>> > >> responsibility of the owner of the server). >>>>> > >> >>>>> > >> Meanwhile we still need to be sure that if the STUN >>>>> client is >>>>> > implementing >>>>> > >> STUNbis it unconditionally gets the additional >>>>> protection of the new >>>>> > >> password encryption algorithm. That's where >>>> the biddown >>>>> > protection kicks >>>>> > >> in, by preventing an online attacker to have >>>> the server >>>>> > misidentifying a >>>>> > >> STUNbis client as an RFC 5389 client, by >>>> preventing an >>>>> online >>>>> > attacker to >>>>> > >> have the client misidentifying a STUNbis server >>>> as a >>>>> RFC 5389 >>>>> > server, and >>>>> > >> having both them use the MD5 encrypted password >>>> instead >>>>> of the >>>>> > SHA-256 >>>>> > >> encrypted password, all of that easily done by >>>>> stripping the >>>>> > unprotected >>>>> > >> 401 response of the new STUNbis PASSWORD-ALGORITHMS >>>>> attribute. >>>>> > >> >>>>> > >>> >>>>> > >>> >>>>> > >>> >>>>> > >>>>> The second topic is the hash used to compute the >>>>> MAC. However, >>>>> > I don't >>>>> > >>>> see >>>>> > >>>>> how >>>>> > >>>>> this gives you sensible biddown protection >>>> because >>>>> that hash >>>>> > is also >>>>> > >> used >>>>> > >>>>> to compute >>>>> > >>>>> MAC over the negotiation: an attacker who has >>>>> compromised a >>>>> > MAC which >>>>> > >> the >>>>> > >>>>> server >>>>> > >>>>> supports will quite likely be able to forge >>>> a MAC >>>>> over the >>>>> > transcript >>>>> > >> as >>>>> > >>>>> well. This is, >>>>> > >>>>> I suppose, potentially useful as a defense >>>> against >>>>> some other >>>>> > weakness >>>>> > >>>>> (e.g., >>>>> > >>>>> version #), but I don't really see how the >>>> current >>>>> design >>>>> > helps against >>>>> > >>>>> attacks on the >>>>> > >>>>> MAC. >>>>> > >>>> >>>>> > >>>> There is no biddown attack protection for the >>>> MAC, as >>>>> stated in >>>>> > Section >>>>> > >>>> 16.3: >>>>> > >>>> >>>>> > >>>> "The bid-down protection mechanism described >>>> in this >>>>> document >>>>> > is new, >>>>> > >>>> and thus cannot currently protect against a >>>> bid-down >>>>> attack that >>>>> > >>>> lowers the strength of the hash algorithm to >>>> HMAC-SHA1." >>>>> > >>>> >>>>> > >>>> What we put in place is a plan for *future* >>>> versions >>>>> of STUN to get >>>>> > >>>> biddown protection for the MAC. That's it, >>>> no more, >>>>> no less. >>>>> > >>>> >>>>> > >>> >>>>> > >>> Yes, but I don't believe that this will >>>> provide bid-down >>>>> > protection for >>>>> > >> the >>>>> > >>> MAC in the future for the reasons I indicate >>>> above. >>>>> > >>> >>>>> > >>> If you think this does something useful, >>>> please show me an >>>>> > example attack >>>>> > >>> and how this fixes it. Note that it's not >>>> generally >>>>> useful to >>>>> > just bid >>>>> > >> down >>>>> > >>> the MAC itself unless the MAC you bid down to >>>> is weak >>>>> enough to >>>>> > exploit >>>>> > >> in >>>>> > >>> some other way. >>>>> > >> >>>>> > >> I do not know what weaknesses will be >>>> discovered in the >>>>> future. >>>>> > I am also >>>>> > >> pretty sure that the cost of not using that >>>> mechanism >>>>> is very >>>>> > close to 0. >>>>> > >> What I am sure of is that the cost of >>>> reengineering a >>>>> new biddown >>>>> > >> protection mechanism if we ever need it will be >>>> high. >>>>> We already >>>>> > went >>>>> > >> through the pains of designing one for the password >>>>> algorithm, so >>>>> > why not >>>>> > >> extend it so it can be used in the aftermath of the >>>>> next Snowden >>>>> > facepalm >>>>> > >> moment? >>>>> > >> >>>>> > >>> Again, happy to have a call to walk though >>>> this if that >>>>> > >>> helps. >>>>> > >>> >>>>> > >>> -Ekr >>>>> > >>> >>>>> > >>> >>>>> > >>> >>>>> > >>> >>>>> > >>>>> >>>>> > >>>>> You might think that there was a MAC which >>>> was easier to >>>>> > reverse to >>>>> > >> find >>>>> > >>>>> the original >>>>> > >>>>> password, but the defense you have here >>>> doesn't help >>>>> with that >>>>> > because >>>>> > >>>> the >>>>> > >>>>> on-path attacker can do a bid-down and use the >>>>> client as a MAC >>>>> > oracle >>>>> > >> for >>>>> > >>>>> any MAC the client supports. >>>>> > >>>>> >>>>> > >>>>> So, I still don't understand what this is >>>> supposed >>>>> to do. Happy to >>>>> > >> have a >>>>> > >>>>> call if you >>>>> > >>>>> think that helps >>>>> > >>>>> >>>>> > >>>>> -Ekr >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> >>>>> > >>>>> On Mon, Jun 18, 2018 at 3:40 AM, Gonzalo >>>> Camarillo < >>>>> > >>>>> Gonzalo.Camarillo@ericsson.com >>>> <mailto:Gonzalo.Camarillo@ericsson.com> >>>>> <mailto:Gonzalo.Camarillo@ericsson.com >>>> <mailto:Gonzalo.Camarillo@ericsson.com>> >>>>> > <mailto:Gonzalo.Camarillo@ericsson.com >>>> <mailto:Gonzalo.Camarillo@ericsson.com> >>>>> <mailto:Gonzalo.Camarillo@ericsson.com >>>> <mailto:Gonzalo.Camarillo@ericsson.com>>>> wrote: >>>>> > >>>>> >>>>> > >>>>>> Marc, Eric, >>>>> > >>>>>> >>>>> > >>>>>> what is the status of this discussion? >>>>> > >>>>>> >>>>> > >>>>>> Thanks, >>>>> > >>>>>> >>>>> > >>>>>> Gonzalo >>>>> > >>>>>> >>>>> > >>>>>> On 04/05/2018 2:35 AM, Eric Rescorla wrote: >>>>> > >>>>>>> >>>>> > >>>>>>> >>>>> > >>>>>>> On Mon, Apr 23, 2018 at 11:16 AM, Marc >>>>> Petit-Huguenin < >>>>> > >>>> petithug@acm.org <mailto:petithug@acm.org> >>>> <mailto:petithug@acm.org <mailto:petithug@acm.org>> >>>>> <mailto:petithug@acm.org <mailto:petithug@acm.org> >>>> <mailto:petithug@acm.org <mailto:petithug@acm.org>>> >>>>> > >>>>>>> <mailto:petithug@acm.org >>>> <mailto:petithug@acm.org> <mailto:petithug@acm.org >>>> <mailto:petithug@acm.org>> >>>>> <mailto:petithug@acm.org <mailto:petithug@acm.org> >>>> <mailto:petithug@acm.org <mailto:petithug@acm.org>>>>> wrote: >>>>> > >>>>>>> >>>>> > >>>>>>> On 04/22/2018 05:22 PM, Eric Rescorla >>>> wrote: >>>>> > >>>>>>> > On Sun, Apr 22, 2018 at 2:02 PM, Marc >>>>> Petit-Huguenin < >>>>> > >>>>>> petithug@acm.org <mailto:petithug@acm.org> >>>> <mailto:petithug@acm.org <mailto:petithug@acm.org>> >>>>> <mailto:petithug@acm.org <mailto:petithug@acm.org> >>>> <mailto:petithug@acm.org <mailto:petithug@acm.org>>> >>>>> > <mailto:petithug@acm.org <mailto:petithug@acm.org> >>>> <mailto:petithug@acm.org <mailto:petithug@acm.org>> >>>>> <mailto:petithug@acm.org <mailto:petithug@acm.org> >>>> <mailto:petithug@acm.org <mailto:petithug@acm.org>>>>> >>>>> > >>>>>>> > wrote: >>>>> > >>>>>>> > >>>>> > >>>>>>> >> >>>>> > >>>>>>> >>>> For a request or indication >>>> message, >>>>> the agent >>>>> > MUST >>>>> > >>>>>> include the >>>>> > >>>>>>> >>>> USERNAME, >>>> MESSAGE-INTEGRITY-SHA256, and >>>>> > >> MESSAGE-INTEGRITY >>>>> > >>>>>>> >> attributes >>>>> > >>>>>>> >>>> in the message unless the agent >>>>> knows from an >>>>> > external >>>>> > >>>>>> indication >>>>> > >>>>>>> >>>> which message integrity >>>> algorithm is >>>>> supported >>>>> > by both >>>>> > >>>>>> agents. In >>>>> > >>>>>>> >>>> this case either >>>> MESSAGE-INTEGRITY or >>>>> > >>>>>> MESSAGE-INTEGRITY-SHA256 MUST >>>>> > >>>>>>> >>>> be included in addition to >>>>> USERNAME. The HMAC >>>>> > for the >>>>> > >>>>>> MESSAGE- >>>>> > >>>>>>> >>> >>>>> > >>>>>>> >>> This text appears to conflict with >>>> S 7.3 of >>>>> > 5245-bis, which >>>>> > >>>> says: >>>>> > >>>>>>> >> >>>>> > >>>>>>> >> [text missing] >>>>> > >>>>>>> >> >>>>> > >>>>>>> >> Hmm, no, RFC245bis is still referencing >>>>> RFC5389, so the >>>>> > >>>> procedure >>>>> > >>>>>> for >>>>> > >>>>>>> >> stunbis does not apply. >>>>> > >>>>>>> >> >>>>> > >>>>>>> > >>>>> > >>>>>>> > I hear what you're saying, but >>>> publishing two >>>>> > documents at the >>>>> > >>>>>> same time >>>>> > >>>>>>> > which >>>>> > >>>>>>> > make contrary recommendations about >>>> the same >>>>> basic >>>>> > protocol is >>>>> > >>>>>> un-good. >>>>> > >>>>>>> >>>>> > >>>>>>> Sure, but wouldn't it be simpler to have >>>>> rfc5245bis >>>>> > using stunbis >>>>> > >>>>>>> and have them updating their text, >>>> more than >>>>> adding some >>>>> > tortuous >>>>> > >>>>>>> text in stunbis? >>>>> > >>>>>>> >>>>> > >>>>>>> > >>>>> > >>>>>>> > >>>>> > >>>>>>> >>> The STUN usage must specify which >>>>> transport >>>>> > protocol is >>>>> > >>>>>> used, and >>>>> > >>>>>>> >> how >>>>> > >>>>>>> >>>> the agent determines the IP >>>> address >>>>> and port >>>>> > of the >>>>> > >>>>>> recipient. >>>>> > >>>>>>> >>>> Section 8 describes a DNS-based >>>>> method of >>>>> > determining >>>>> > >> the >>>>> > >>>>>> IP >>>>> > >>>>>>> >> address >>>>> > >>>>>>> >>>> and port of a server that a >>>> usage >>>>> may elect to >>>>> > use. >>>>> > >> STUN >>>>> > >>>>>> may be >>>>> > >>>>>>> >> used >>>>> > >>>>>>> >>>> with anycast addresses, but only >>>>> with UDP and >>>>> > in usages >>>>> > >>>>>> where >>>>> > >>>>>>> >>>> authentication is not used. >>>>> > >>>>>>> >>> >>>>> > >>>>>>> >>> Why this restriction? You should >>>> be able >>>>> to use >>>>> > anycast with >>>>> > >>>>>> long-term >>>>> > >>>>>>> >>> AUTH for (say) TURN. >>>>> > >>>>>>> >> >>>>> > >>>>>>> >> >>>>> https://www.ietf.org/mail-archive/web/behave/current/ >>>>> > >>>>>> msg03582.html >>>>> > >>>>>>> >>>>> <https://www.ietf.org/mail-archive/web/behave/current/ >>>>> > >>>> msg03582.html> >>>>> > >>>>>>> >> >>>>> > >>>>>>> >> I think that the decision of >>>> permitting Anycast >>>>> > should be left >>>>> > >>>> to >>>>> > >>>>>> each >>>>> > >>>>>>> >> STUN Usage. Basic STUN Usage does >>>> not use >>>>> > authentication and >>>>> > >>>> use >>>>> > >>>>>> only a >>>>> > >>>>>>> >> one round trip for the Binding >>>> transaction, so >>>>> > Unicast can be >>>>> > >>>>>> used. >>>>> > >>>>>>> >> >>>>> > >>>>>>> > >>>>> > >>>>>>> >> OTOH, TURN and ICE should probably say >>>>> something >>>>> > about that, >>>>> > >> so >>>>> > >>>> I >>>>> > >>>>>> added a >>>>> > >>>>>>> >> new bullet point in Section 13: >>>>> > >>>>>>> >> >>>>> > >>>>>>> >> o If Anycast addresses can be >>>> used for >>>>> the server >>>>> > in case >>>>> > >>>> TCP >>>>> > >>>>>> or >>>>> > >>>>>>> >> TLS-over-TCP, or >>>> authentication are used. >>>>> > >>>>>>> >> >>>>> > >>>>>>> > >>>>> > >>>>>>> > Are you leaving this text in? That seems >>>>> very confusing. >>>>> > >>>>>>> >>>>> > >>>>>>> In isolation yes, but I think it makes >>>> sense >>>>> which the text >>>>> > >> before >>>>> > >>>>>>> the bullet points: >>>>> > >>>>>>> >>>>> > >>>>>>> A STUN usage defines how STUN is >>>> actually >>>>> utilized -- >>>>> > when to >>>>> > >>>> send >>>>> > >>>>>>> requests, what to do with the >>>> responses, >>>>> and which >>>>> > optional >>>>> > >>>>>>> procedures defined here (or in an >>>> extension >>>>> to STUN) >>>>> > are to be >>>>> > >>>>>> used. >>>>> > >>>>>>> A usage also defines: >>>>> > >>>>>>> >>>>> > >>>>>>> [...] >>>>> > >>>>>>> >>>>> > >>>>>>> o If Anycast addresses can be used >>>> for the >>>>> server in >>>>> > case TCP >>>>> > >>>> or >>>>> > >>>>>>> TLS-over-TCP, or authentication >>>> are used. >>>>> > >>>>>>> >>>>> > >>>>>>> >>>>> > >>>>>>> What is the need for the restriction at all. >>>>> > >>>>>>> >>>>> > >>>>>>> >>>>> > >>>>>>> >>>>> > >>>>>>> >>>> transaction over UDP or >>>>> DTLS-over-UDP is also >>>>> > >> considered >>>>> > >>>>>> failed if >>>>> > >>>>>>> >>>> there has been a hard ICMP error >>>>> [RFC1122]. For >>>>> > >> example, >>>>> > >>>>>> assuming >>>>> > >>>>>>> >> an >>>>> > >>>>>>> >>>> RTO of 500ms, requests would >>>> be sent >>>>> at times >>>>> > 0 ms, 500 >>>>> > >>>>>> ms, 1500 >>>>> > >>>>>>> >> ms, >>>>> > >>>>>>> >>>> 3500 ms, 7500 ms, 15500 ms, and >>>>> 31500 ms. If the >>>>> > >> client >>>>> > >>>>>> has not >>>>> > >>>>>>> >>>> received a response after >>>> 39500 ms, >>>>> the client >>>>> > will >>>>> > >>>>>> consider the >>>>> > >>>>>>> >>>> transaction to have timed out. >>>>> > >>>>>>> >>> >>>>> > >>>>>>> >>> I note that these recommendations >>>> now seem >>>>> crazily >>>>> > long. I >>>>> > >>>>>> assume the >>>>> > >>>>>>> >>> WG had consensus on this, but I >>>> wanted to >>>>> note it. >>>>> > >>>>>>> >> >>>>> > >>>>>>> >> Not just the WG, also the IESG that >>>>> approved RFC 5389 >>>>> > too as, >>>>> > >>>> but >>>>> > >>>>>> for the >>>>> > >>>>>>> >> addition of "or DTLS-over-UDP", >>>> this is the >>>>> same text >>>>> > than in >>>>> > >>>> RFC >>>>> > >>>>>> 5389. >>>>> > >>>>>>> >> >>>>> > >>>>>>> > >>>>> > >>>>>>> > Yes, I know. My point is that while they >>>>> might have bee >>>>> > >> sensible >>>>> > >>>>>> when >>>>> > >>>>>>> > 5389 was published they *now* seem >>>> crazily >>>>> long. Did >>>>> > the WG >>>>> > >>>>>> explicitly >>>>> > >>>>>>> > decide not to update them? >>>>> > >>>>>>> >>>>> > >>>>>>> No, nobody ever suggested that there >>>> was an >>>>> issue there. >>>>> > >>>>>>> >>>>> > >>>>>>> >>>>> > >>>>>>> OK, well, this seems like it should be >>>> considered, >>>>> then, >>>>> > because this >>>>> > >>>>>>> doesn't >>>>> > >>>>>>> match modern practice. >>>>> > >>>>>>> >>>>> > >>>>>>> >>>>> > >>>>>>> >>>>> > >>>>>>> > This would be good to explain. >>>>> > >>>>>>> >>>>> > >>>>>>> New text: >>>>> > >>>>>>> >>>>> > >>>>>>> [...] >>>>> > >>>>>>> containing the subjectAltName of that >>>>> certificate. >>>>> > The test >>>>> > >> on >>>>> > >>>>>> the >>>>> > >>>>>>> MESSAGE-INTEGRITY-SHA256 attribute >>>>> indicates that the >>>>> > >>>> transaction >>>>> > >>>>>> is >>>>> > >>>>>>> authenticated and that the client >>>>> implements this >>>>> > >> specification >>>>> > >>>>>> and >>>>> > >>>>>>> so can process the ALTERNATE-DOMAIN >>>> attribute. >>>>> > >>>>>>> >>>>> > >>>>>>> >>>>> > >>>>>>> All right. >>>>> > >>>>>>> >>>>> > >>>>>>> >>>>> > >>>>>>> > >>>>> > >>>>>>> > >>>>> > >>>>>>> >>>> o What authentication and >>>>> message-integrity >>>>> > mechanisms >>>>> > >>>>>> are used. >>>>> > >>>>>>> >>>> >>>>> > >>>>>>> >>>> o The considerations around >>>> manual vs. >>>>> > automatic key >>>>> > >>>>>> derivation >>>>> > >>>>>>> >> for >>>>> > >>>>>>> >>>> the integrity mechanism, as >>>>> discussed in >>>>> > [RFC4107]. >>>>> > >>>>>>> >>>> >>>>> > >>>>>>> >>>> o What mechanisms are used to >>>>> distinguish STUN >>>>> > >> messages >>>>> > >>>>>> from other >>>>> > >>>>>>> >>> >>>>> > >>>>>>> >>> Why is this required? It seems >>>> like that's >>>>> a generic >>>>> > STUN >>>>> > >>>>>> feature. >>>>> > >>>>>>> >> >>>>> > >>>>>>> >> That text is identical to the text >>>> in RFC >>>>> 5389. RFC >>>>> > 5764/7983 >>>>> > >>>> is >>>>> > >>>>>> one such >>>>> > >>>>>>> >> mechanism, but there is nothing that >>>>> prevent another >>>>> > protocol >>>>> > >>>>>> stack to use >>>>> > >>>>>>> >> a different mechanism (inference, >>>> shim, etc...) >>>>> > >>>>>>> >> >>>>> > >>>>>>> > >>>>> > >>>>>>> > But ultimately no matter what the >>>> other protocol >>>>> > provides for >>>>> > >>>>>> demux, STUN >>>>> > >>>>>>> > has its >>>>> > >>>>>>> > own demux. >>>>> > >>>>>>> >>>>> > >>>>>>> In fact I think that the reason for >>>> that item >>>>> was because >>>>> > >>>>>>> FINGERPRINT can also be used to demux STUN >>>>> traffic, but >>>>> > it is >>>>> > >>>>>>> optional. So an STUN Usage needs to >>>> tell if >>>>> FINGERPRINT is >>>>> > >>>>>>> mandatory (like in ICE). >>>>> > >>>>>>> >>>>> > >>>>>>> >>>>> > >>>>>>> This should be explained. >>>>> > >>>>>>> >>>>> > >>>>>>> >>>>> > >>>>>>> >>> >>>>> > >>>>>>> >>>> that is not readily subject to >>>>> offline dictionary >>>>> > >>>> attacks. >>>>> > >>>>>>> >>>> Protection of the channel >>>> itself, >>>>> using TLS or >>>>> > DTLS, >>>>> > >>>>>> mitigates >>>>> > >>>>>>> >> these >>>>> > >>>>>>> >>>> attacks. >>>>> > >>>>>>> >>>> >>>>> > >>>>>>> >>>> STUN supports both >>>> MESSAGE-INTEGRITY and >>>>> > >>>>>>> MESSAGE-INTEGRITY-SHA256, >>>>> > >>>>>>> >>>> which is subject to bid down >>>> attacks >>>>> by an on-path >>>>> > >>>>>> attacker. >>>>> > >>>>>>> >>> >>>>> > >>>>>>> >>> By an on-path attacker who can forge >>>>> HMAC-SHA1 in >>>>> > real-time? >>>>> > >>>>>>> That's a >>>>> > >>>>>>> >>> pretty serious adversary, so you >>>> should >>>>> clarify here >>>>> > >>>>>>> >>> >>>>> > >>>>>>> >> >>>>> > >>>>>>> >> New text: >>>>> > >>>>>>> >> >>>>> > >>>>>>> >> STUN supports both >>>> MESSAGE-INTEGRITY and >>>>> > >>>>>> MESSAGE-INTEGRITY-SHA256, >>>>> > >>>>>>> >> which is subject to bid down >>>> attacks by >>>>> an on-path >>>>> > attacker >>>>> > >>>>>> that >>>>> > >>>>>>> >> would strip the >>>> MESSAGE-INTEGRITY-SHA256 >>>>> attribute >>>>> > leaving >>>>> > >>>>>>> only the >>>>> > >>>>>>> >> MESSAGE-INTEGRITY attribute and >>>>> exploiting a potential >>>>> > >>>>>>> vulnerability. >>>>> > >>>>>>> >> Protection of the channel >>>> itself, using >>>>> TLS or DTLS, >>>>> > >>>> mitigates >>>>> > >>>>>>> these >>>>> > >>>>>>> >> attacks. Timely removal of the >>>> support of >>>>> > >> MESSAGE-INTEGRITY >>>>> > >>>>>> in a >>>>> > >>>>>>> >> future version of STUN is necessary. >>>>> > >>>>>>> >> >>>>> > >>>>>>> > >>>>> > >>>>>>> > I still don't understand the >>>> capabilities >>>>> you seem to >>>>> > believe >>>>> > >> the >>>>> > >>>>>>> attacker >>>>> > >>>>>>> > has. >>>>> > >>>>>>> > Can you describe the exact attack. >>>>> > >>>>>>> > >>>>> > >>>>>>> >>>>> > >>>>>>> 1. Vulnerability is found in HMAC-SHA1 >>>>> > >>>>>>> 2. Client Alice still supports M-I and >>>>> M-I-256, does not >>>>> > know >>>>> > >> what >>>>> > >>>>>>> version of STUN server Bob supports and so >>>>> send both. >>>>> > >>>>>>> 3. On-path attacker removes M-I-256. >>>>> > >>>>>>> 5. stunbis server Bob thinks that >>>> Alice is an >>>>> RFC 5389 >>>>> > client and >>>>> > >>>>>>> continue with that protocol. >>>>> > >>>>>>> >>>>> > >>>>>>> >>>>> > >>>>>>> This seems like an extremely weak attack. In >>>>> general, any >>>>> > protocol of >>>>> > >>>>>>> this type is as strong >>>>> > >>>>>>> as the weakest integrity algorithm it >>>> supports, so >>>>> it's not >>>>> > that the >>>>> > >>>>>>> protocol has a downgrade >>>>> > >>>>>>> attack, but rather that the minimum algorithm >>>>> supported is >>>>> > one you >>>>> > >>>> don't >>>>> > >>>>>>> trust as much >>>>> > >>>>>>> as you might like. >>>>> > >>>>>>> >>>>> > >>>>>>> -Ekr >>>>> > >>>>>>> >>>>> > >>>>>>> >>>>> > >>>>>>> -- >>>>> > >> >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > Marc Petit-Huguenin >>>>> > Email: marc@petit-huguenin.org >>>> <mailto:marc@petit-huguenin.org> >>>>> <mailto:marc@petit-huguenin.org >>>> <mailto:marc@petit-huguenin.org>> <mailto:marc@petit-huguenin.org >>>> <mailto:marc@petit-huguenin.org> >>>>> <mailto:marc@petit-huguenin.org >>>> <mailto:marc@petit-huguenin.org>>> >>>>> > Blog: https://marc.petit-huguenin.org >>>> <https://marc.petit-huguenin.org/> >>>>> > Profile: https://www.linkedin.com/in/petithug >>>>> > >>>>> >>>> >>> >
- 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)