Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)
"Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com> Fri, 18 January 2019 18:16 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 1013113129F; Fri, 18 Jan 2019 10:16:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -19.052
X-Spam-Level:
X-Spam-Status: No, score=-19.052 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, HTML_MESSAGE=0.001, 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 KPCbghuqDSPl; Fri, 18 Jan 2019 10:16:14 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFDC5131290; Fri, 18 Jan 2019 10:16:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=185058; q=dns/txt; s=iport; t=1547835374; x=1549044974; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=G00uFt5vAGBwUJkuIzDOmLm5u7weGTejsd7JhHl9Hj4=; b=VPVwnZYEIczmLDHwa76qhn1ISmygrEJ1BEht9GEB2Rw8ZS8vy7wmnwqt 5TOJ5wf3vr9prls1+SAslKy9TX+i367YavCaDF6OW9I0Yoc8CXX95pByG NWJ6rR/dpS990E/C8oRKJoECW/Y4gCOS2T36Vpx9AXrgecGoxxghuZkob c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AEAABAF0Jc/4QNJK1kGgEBAQEBAgEBAQEHAgEBAQGBUQUBAQEBCwGBVS5mSgE3JwqDd4gai2iCDZgBFIFnCwEBI4RJAheCRSI0CQ0BAwEBAgEBAm0cDIVKAQEBAwEaAQhFEQULAgEIDgoYCAEGAwICAjAUEQIEDgWDIgGBHVwID6t9gS+EQkGFKwWJeXaBNR0XgUA/gREnH4FOfoMeAgECAYEqARECAQYCLTiCADoxgiYCiVALMIFVhBGBcYRti1EJAociincYgWaFLoRohhiLDIQUi1YCERSBJx84QiNxcBU7KgGCDQEBMoIEIgEBFhODOIUUhT9BMQGHaoEKgR8BAQ
X-IronPort-AV: E=Sophos;i="5.56,491,1539648000"; d="scan'208,217";a="227436269"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2019 18:16:11 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x0IIGBOL031986 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Jan 2019 18:16:11 GMT
Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 18 Jan 2019 12:16:10 -0600
Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1395.000; Fri, 18 Jan 2019 12:16:10 -0600
From: "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>
To: Eric Rescorla <ekr@rtfm.com>
CC: Gonzalo Camarillo <gonzalo.camarillo@ericsson.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>, "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: AQHUa0FPQa4RlvmGQ0G0i0rcGeSYLqUuaM8AgABS4ICAKPySAIAACJIAgABkJoCABCeEgIA2QhKAgCOzSIA=
Date: Fri, 18 Jan 2019 18:16:10 +0000
Message-ID: <D99F4FB6-EA38-49F6-AE00-83570455C6D7@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>
In-Reply-To: <CABcZeBPuLPha64QybuPUc-W+fR2Bqn1rAzDsb908uBNqC9z50A@mail.gmail.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.54.123]
Content-Type: multipart/alternative; boundary="_000_D99F4FB6EA3849F6AE0083570455C6D7ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/4JYuL2YmCgyDHx8r1cXePHIEHOw>
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: Fri, 18 Jan 2019 18:16:22 -0000
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)