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: =?us-ascii?q?A0AEAACERGxc/5hdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggNnSwE3JwqDfIgai2+BaCWYGxSBZws?= =?us-ascii?q?BASOESQIXg1QiNAkNAQMBAQIBAQJtHAyFSgEBAQECARoJETQRBQsCAQgYAgI?= =?us-ascii?q?UDwMCAgIwFAEQAgQOBYMgAYFqCA+tXYEvhENBhScFgQuIcXaBNR0XgUA/gRE?= =?us-ascii?q?nDBOBTn6DHgIBAgGBKgERAgEGAhYHECMVggA6MYImAol2CzCBXYYdhQaMGAk?= =?us-ascii?q?ChzqLHRmBcIVVhQKGPYtVhDuMMwIRFIEnHzhCI3FwFTsqAYINAQEyggUiAQE?= =?us-ascii?q?WE4M4hRSFP0ExAYs5gQqBHwEB?=
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
>>>>          >
>>>> 
>>> 
>>