Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)
Gonzalo Camarillo <gonzalo.camarillo@ericsson.com> Mon, 14 January 2019 10:44 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 A6D7F130FE9 for <tram@ietfa.amsl.com>; Mon, 14 Jan 2019 02:44:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.853
X-Spam-Level:
X-Spam-Status: No, score=-8.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=OI0Fjnej; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Zpzq5f7k
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 2r4_JSOcZxOF for <tram@ietfa.amsl.com>; Mon, 14 Jan 2019 02:44:30 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 BAA3B130FDE for <tram@ietf.org>; Mon, 14 Jan 2019 02:44:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1547462667; x=1550054667; 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=5MiinGEyRJFwrIra7tpVKCVtE/dMVxsOuDsSzaord6Q=; b=OI0FjnejcBgZ2pzmcXi2Klr8mPY9MAgV/gprm3sEivhxBcr2FM7xL8hfGVkHK6DJ dC8foBEvhhCwfVjM/Mv1W3ahr6vsZOLqr4dwf5FwLwtZMHnnlU65DaBbGxHZyPNM z6eJAQlMxfBD1nRwxBqi2gej+j2x2nTJ1T1qYJTd81s=;
X-AuditID: c1b4fb30-fabff7000000355c-43-5c3c680b1a4c
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A8.4D.13660.B086C3C5; Mon, 14 Jan 2019 11:44:27 +0100 (CET)
Received: from ESESSMR503.ericsson.se (153.88.183.112) by ESESSMB501.ericsson.se (153.88.183.119) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 14 Jan 2019 11:44:27 +0100
Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMR503.ericsson.se (153.88.183.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 14 Jan 2019 11:44:27 +0100
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB502.ericsson.se (153.88.183.169) 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, 14 Jan 2019 11:44:27 +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=5MiinGEyRJFwrIra7tpVKCVtE/dMVxsOuDsSzaord6Q=; b=Zpzq5f7kxB7HKRy0M5SskAQiP9Rb7dQ0TFGjcM9aIJv4QOk1hE20BTAHyQ3h7LJZ8xXj1WKj6aV/8laDz28F1QHNACdmWXbw4SQnZys/v9YsiHQueN7XbQSnLSNDLX4ctwVaJX8/un0iijHyie1CKoCt3Ngw04ow5/oxv+zGLaM=
Received: from VI1PR07MB6127.eurprd07.prod.outlook.com (20.178.124.154) by VI1PR07MB6032.eurprd07.prod.outlook.com (20.178.124.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.18; Mon, 14 Jan 2019 10:44:25 +0000
Received: from VI1PR07MB6127.eurprd07.prod.outlook.com ([fe80::d438:c7d:7008:e3df]) by VI1PR07MB6127.eurprd07.prod.outlook.com ([fe80::d438:c7d:7008:e3df%4]) with mapi id 15.20.1537.018; Mon, 14 Jan 2019 10:44:25 +0000
From: Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
To: 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: AQHUnYBiqLLC9ixfgUKft2RgQQqd9Q==
Date: Mon, 14 Jan 2019 10:44:25 +0000
Message-ID: <VI1PR07MB6127D619881C66536166473F83800@VI1PR07MB6127.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>
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-microsoft-exchange-diagnostics: 1; VI1PR07MB6032; 6:cnOjZ3RZZPMceCD3ccuie2QlRqlbjU4cr2sYsmsefmvcOX/oJKEWH1VURpl14jrkhUumDsLogFjZok6VSGwWdWYcG7twNUbK6JtHDR1HSqrQCjHTl6eXMnLeZNwDnt/ZD/DuQ6CbwGw+QzOicplhKuKf9X6ktzO5T07+t9B4yvtywTB6xQaW5Q/MyIEnm2aZyrpS47n1BsxbfJxk1ZPbslImGTv5StPsu6n+vJ7MvnMoD9QwCNg5/f4N37t+BLBmumXseuWot+vR/MjMjuFL6feltxqoLLTXGnqXuuUMadv07FTGJH1B6Om4zgHR/kdx3/EsrXOQpLmmb1vdoRlAEwvdOzQCBqwYHKHDq02nUZWTNeY1Uq7LTtALKL4VNMAcoNdBzEI39FnBSSJMcyn5TNxf/Tv46NPDxU3iuzA+UWq0t3psdd5eRnQ76TqNeJ7tDMVDpIbaTZqtczx2vaOCBQ==; 5:BPY43v2O6bDqir1juSVRO9jFkYcCI1d4E2QQwIOd2eIqVTr1ljJdcnj7aIT6VvxUi7+fYuuH/7vy8UvIvOHw8n4sF+7mZlLFfI04G2FYwuTCgk74V2FaZlBsLf/ZLyGXYd2GvOyskqvTM+GVoZWtCyPPGLvM4COvLIle3NrlndnFKbEasfRtjYiFxUEpS+oVNWhbVhQ2YO0ztc6RuYfJcA==; 7:NP0Nsji2bXuNd0SGieOiv7lJZ5Lle1P+2QjPq5nUkxET9zF2FN6n/cZ0uzB9Ljv57jI3HvJ28Bge2bcGeAixcG9uJOF33ByeIOKrehZG7x7jXFC8+dJn+qBw2YCi80FMtJA1sNJnhs1d5exZQ8PItg==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: db0578b0-b4ca-4b91-4421-08d67a0d4073
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB6032;
x-ms-traffictypediagnostic: VI1PR07MB6032:
x-microsoft-antispam-prvs: <VI1PR07MB603235CB17C0D61D3F92368C83800@VI1PR07MB6032.eurprd07.prod.outlook.com>
x-forefront-prvs: 0917DFAC67
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(376002)(39860400002)(346002)(366004)(189003)(199004)(54094003)(51914003)(51444003)(446003)(105586002)(478600001)(6246003)(186003)(30864003)(25786009)(5660300001)(229853002)(66066001)(106356001)(316002)(71200400001)(76176011)(71190400001)(81166006)(81156014)(551544002)(2906002)(53936002)(53546011)(54906003)(8676002)(6506007)(102836004)(55016002)(6916009)(99286004)(26005)(53946003)(8936002)(476003)(305945005)(486006)(7736002)(44832011)(97736004)(6116002)(3846002)(6306002)(6436002)(7696005)(9686003)(551934003)(4326008)(33656002)(93886005)(39060400002)(74316002)(68736007)(45080400002)(966005)(14444005)(256004)(86362001)(14454004)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB6032; H:VI1PR07MB6127.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: 1YVd0EwV7/OD3PD3MmQYvb6H8aI6jYOkv4d54WdrNSwJRAMO4IAF9669SvwBTxaD0iEpvIlT7EIW4Iks+pH/Mgmgoxi00XMrYJqFX62ogEi07uBVlCyiB29YkQEBI1D18Avi2zmHAmnjFad6exonmRvF33YrRVpyLuR/IwPQ8Pk5zMlLcAYctUeByfyA6ayaPnevuB2lEGIK+uIy5qtQTCLtRErd9x6IFwIsaSzuoKs08UV3n2xxQsUimYJKLiourbEsxQwF42EDh8kgIFBCCox4gZnZyPhu2yahcwfVW8gZT6MB2lsWOHTs83feSR1aZQ0M9bepN1ml9vOGzE72j/6iyvzSBwhsqkAZT81EtxomWLPAnNIpo7bedopBir0fUQVjZHBHP7tvbT9DLvI7AFLmUhKqEKUqwGuMdWGRASs=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: db0578b0-b4ca-4b91-4421-08d67a0d4073
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2019 10:44:25.2400 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6032
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTcRTH+e0+dp2Ofs6ZJyvQkViK84HEDTRSoYYhSSZYTGrmxYlPds1H EJlQuImipaFLUWOo+cAe9qJpJhIlmSPFtDB8LPIBKWqKTjLnXdF/33O+n+/5nQM/hpA9oTyZ 1MwcTpepSVfQErIm4XlegLM2TB00V3KM1XcN02zLwkcxW71VQbCW9gkR21RpJtjO5jUx27zx gGaXOiz0CUY1PHJa9dI4IVaZTBsilbn2NlLdmblFxFIXJGHJXHpqLqcLPH5Jot3unKGzn44R +TW2NnEhKrWKDMiJARwK+l/jyIAkjAz3Iygp7qbshgyvIVh9y//TlYNaATKJwNYzSdgLEpcT MLo64ohXisAyXUEJxSSCxvkR2oAYhsYsFLcdtY+SYy/Y3HpH2hkC94pgxTy9u4gbToGv858p Oy/HWhi2RQtSCWWTQXZJYh/YrlXaYSlWQ9tGg+MlKwPWJTOyGwjvhfWB9t2JBPaAL9Z6x5kY TOYhQtDuMDfzmxJ4DUze7HD0vWHw55SDPwif6kt27wJcJIaulW1SMAJgqarKEYiB0a0OQoAs CIyzK2LB8IO+eT0l6DRYvLfoCB+A0ZX7lBD4QEOdeVhcjgKN/20raCWMVVXSgvaHpsYFwrh7 tiu8r7GSDYhsRe48xydlpISEKDld6mWez8pUZnI5j9HOV3rTZQt6geZ+RPQhzCCFi3Q8Lkwt ozS5fEFGHwKGUMiluZE7LWmypuAqp8u6qLuSzvF9aD9DKjykWzJXtQynaHK4NI7L5nR/XRHj 5FmIzsVVN5mbcwIS9/ka5+N8erIeBTrL3QkPl8Ox2bojLY3pxWdsknhFXeu1gWXD2bvhtd+z ok0xr4ry9d6bCdfDvep5gyUqyWO1JiIxJEq/J7S/+xCsVpwqS+udcWnKjl6/cd5/SF1avvHw mVu8vDt4aSrydcRyXr2f+OQ339ni8n4FyWs1wX6Ejtf8AUtbvfZGAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/bYKlqVv73QOHiDRSG_BOpzn-Ovw>
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, 14 Jan 2019 10:44:33 -0000
Authors of stunbis (Marc and Gonzalo S), could you please respond to this? Thanks! Cheers, Gonzalo On 27-Dec-18 03:05, Eric Rescorla 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 > > > 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)