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: =?us-ascii?q?A0AEAABAF0Jc/4QNJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBVS5mSgE3JwqDd4gai2iCDZgBFIFnCwEBI4R?= =?us-ascii?q?JAheCRSI0CQ0BAwEBAgEBAm0cDIVKAQEBAwEaAQhFEQULAgEIDgoYCAEGAwI?= =?us-ascii?q?CAjAUEQIEDgWDIgGBHVwID6t9gS+EQkGFKwWJeXaBNR0XgUA/gREnH4FOfoM?= =?us-ascii?q?eAgECAYEqARECAQYCLTiCADoxgiYCiVALMIFVhBGBcYRti1EJAociincYgWa?= =?us-ascii?q?FLoRohhiLDIQUi1YCERSBJx84QiNxcBU7KgGCDQEBMoIEIgEBFhODOIUUhT9?= =?us-ascii?q?BMQGHaoEKgR8BAQ?=
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
>         >
>