Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)
"Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com> Tue, 19 February 2019 18:06 UTC
Return-Path: <gsalguei@cisco.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 EE09C130F36; Tue, 19 Feb 2019 10:06:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 XRWyGfyLHKR6; Tue, 19 Feb 2019 10:06:35 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EBD8130EAB; Tue, 19 Feb 2019 10:06:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56596; q=dns/txt; s=iport; t=1550599594; x=1551809194; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RrC/yGh3rdB+GFZa1d6JSIIFF3aCcaq0yyWdaPyJs7U=; b=iHqB7tnrKQ2l0INDwQ0beZ8PN+OKF3SsbLTdXkcLgyZBh9QDgw19nz9E b/yuWCT0osujm4OWTGtkW0GCRibM8YlDEPIspOdg1XuE7YXMVoiQpN/TO /1xY/DqY71R+YGd9nopcyFz2QxN23dtsHJdbdN0cxa6tcFbRprapbuLCI I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AEAACERGxc/5hdJa1jGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBggNnSwE3JwqDfIgai2+BaCWYGxSBZwsBASOESQIXg1QiNAkNAQMBAQIBAQJtHAyFSgEBAQECARoJETQRBQsCAQgYAgIUDwMCAgIwFAEQAgQOBYMgAYFqCA+tXYEvhENBhScFgQuIcXaBNR0XgUA/gREnDBOBTn6DHgIBAgGBKgERAgEGAhYHECMVggA6MYImAol2CzCBXYYdhQaMGAkChzqLHRmBcIVVhQKGPYtVhDuMMwIRFIEnHzhCI3FwFTsqAYINAQEyggUiAQEWE4M4hRSFP0ExAYs5gQqBHwEB
X-IronPort-AV: E=Sophos;i="5.58,388,1544486400"; d="scan'208";a="521310092"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2019 18:05:35 +0000
Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x1JI5YRW027387 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Feb 2019 18:05:34 GMT
Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 19 Feb 2019 12:05:32 -0600
Received: from xch-rcd-009.cisco.com ([173.37.102.19]) by XCH-RCD-009.cisco.com ([173.37.102.19]) with mapi id 15.00.1395.000; Tue, 19 Feb 2019 12:05:33 -0600
From: "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
CC: "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>, 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: AQHUa0FPQa4RlvmGQ0G0i0rcGeSYLqXoiXoA
Date: Tue, 19 Feb 2019 18:05:33 +0000
Message-ID: <CEA96BE8-B0B2-4566-BFB1-6D387D2B1BD6@cisco.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> <VI1PR07MB5421AC5849B762B682B52D6883630@VI1PR07MB5421.eurprd07.prod.outlook.com>
In-Reply-To: <VI1PR07MB5421AC5849B762B682B52D6883630@VI1PR07MB5421.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.150.52.169]
Content-Type: text/plain; charset="utf-8"
Content-ID: <A32537E0078B2143BF07DAA1181DD05F@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/aFI4zJsrii5DlGwEPNz3FYZCK1A>
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: Tue, 19 Feb 2019 18:06:38 -0000
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)