Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)

Marc Petit-Huguenin <petithug@acm.org> Wed, 24 October 2018 08:44 UTC

Return-Path: <petithug@acm.org>
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 39E92130EBB; Wed, 24 Oct 2018 01:44:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.442
X-Spam-Level:
X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
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 K4zINfiW-sAN; Wed, 24 Oct 2018 01:44:36 -0700 (PDT)
Received: from implementers.org (unknown [92.243.22.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EFCF130EE0; Wed, 24 Oct 2018 01:44:35 -0700 (PDT)
Received: from [IPv6:2601:648:8400:8e7d:2045:7a00:9dfd:61bf] (unknown [IPv6:2601:648:8400:8e7d:2045:7a00:9dfd:61bf]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id A0E7CAE00A; Wed, 24 Oct 2018 10:44:31 +0200 (CEST)
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: Eric Rescorla <ekr@rtfm.com>, tram-chairs@ietf.org, tram@ietf.org, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, "Asveren, Tolga" <tasveren@rbbn.com>, IESG <iesg@ietf.org>, draft-ietf-tram-stunbis@ietf.org
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>
From: Marc Petit-Huguenin <petithug@acm.org>
Openpgp: preference=signencrypt
Autocrypt: addr=petithug@acm.org; prefer-encrypt=mutual; keydata= mQINBE6Mh9wBEADrUEDZChteJbQtsHwZITZExr7TAqT7pniNwhBX3nFgd+FrV3lsLKJ1rym2 52MAYpubXEJZGzMp6uCCAnROWbtmQbOm8z/jHnjxHhPqfuYCYPpAQqu8K/Sc194Rp37krMwB jz32yr7+gvWLzRgQGKIh9d2mzy8QLMETVWWQWGb6fEfpOxXo0wumN1rc/275kZwOu44JIPGg zbgwZdnEqYOUUa18K9MXeRDoWbwDISP30CvKuZDwD14lbBE3o7tBQrU9uoMhE7eFlTjbsCox qoubI2tZSuOTF8mRXjPmNrRGtf9mYkQnOB7y6qy/QxmOVMq4IRtHzOYIm/EZ6NTodcpZQHOM 2v6B6YK9uKrYrapSpJzn4f9oU7alT31Y3o2hOlxAWDQ16+Dd1MOPYsKQXOwY1/ihm4PTjiJ8 ud8yPzy7c+BSVs5wkBU6QuLNIgZHrrxdn+KxM+F/oAVtfzO7XzVoeOcXyWi3/CHL5pgoBruY enIF/RrRuplpy09pvZjmFPNfqKBYJGnqpQuqsQwO7LsFqDqfY2EuHg+KsGN1XuN+jxXc48/1 gCnKw7ALSPWEb7g25wD6KfiZTAcyRTG8LePNFQKhw61LbIWmkw9EaVLyXvwPTc1iCSc0dDT/ pcT/z+8xrWOyWGZNZAjR584NlDpKollbItcxYtFcYZkvTCmOVwARAQABtCZNYXJjIFBldGl0 LUh1Z3VlbmluIDxwZXRpdGh1Z0BhY20ub3JnPokCOAQTAQgAIgIbIwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AFAlfy11wACgkQKcRFldZqfsRWqBAAu/61DGo+j38UefTKnEse0mftPBXa S4lre7vknn33MI0L5QXmiM8zRs9FOKSuXPx0EV+JhI4pWZGW/2MJPuyifXHvnIChcdGInN8J GBdTLZSOgdDFZL9msO+QUsvMA8ZUsqlKOEcVL1NyoLupblCWNq4fYhBCx1zDwX9LZSuGn8lZ Mk8a4QFGoR6dWKaOxeCwnoquW5IK1CfRIhYjHfQMjA5gY0H46F0iCqBaFF/S7krQwIJd0XN4 YbSL4KOrWuxtgQ+iH/iaxxBXgJ1blBNRzXaWJBF4PHv23nSnEzWO17j+uVMaHJu7ycYEf8T9 pVc0xcok1BM2rCrNE5FUFAzsUtAtBZEEK6sSIeOhRG93uD/Hv1hrWzEwf+Z7B1tVQLCQQ4kL 7wyS7SXI/JTuW2xTEGCmwMeWYGERdkgsatmx4zi5nVHDjt3/mlPMj4L+u05SkI2iV4W6xxU1 jHlBIJDs7AVM0dsxzTyIPf2Sz843WyHuBgkoCskxGfOwlkZzDX9rwcWRKal1wjy1w/25LsBY U50INandw3UbrS2I73VX8ARI8uOWZrW7uzRLf8EmuPhtSQ35ThmdoNSgGMP9EXwNgzi/i+5G hbX5KbrSLG9SITFJEcJA4tnwu3nqmBh7D7vbd5ln5X7rmqPdyjidt0zcSjvuaBA+nkmakA4A O+choWy5Ag0EToyH3AEQAL+LguHhcSDCL/IevdcvH/5/fzO2fmuuTxdGwrZZSm7l6/HD2Ira h6Wpa1LvVeRbnsRq8k6O8/i3wVapEoQPmNY3vjWfXaJb8R4vHcqgcxw9N9jhZa+mvGJk9+cI ilDyPzHRBBID4d/3oFKQCQ4Y2SIkO66znPhfBOS2f2AU7AtXHhVEyj6WsLK6boEMcj7j+w5a es2nZam0jhgoz+4DQem4uk8outrRlboGnZN7A2kCNuy39UeOp7BpvQ95IKcJCIeSoiJt2A4B NPQroqhW0zGn9Y9FJ9UiZ9YIeNPYbscUxxvrD+OU9Jv67hW0v3KfvoIKDwVKpO3MW6o+1teS Gt1KCSz+CvGJCvIxfCk7S5K5SBne7ZNKz7rkGXYIzlyr7ZoEgRHmqGmcK/sHTS4e6g2pQQrR USkspyqLZl5Uzmg7yI5oGBL0aHTzYdDkkOKMRXYnl7ivBeNtGcniGqlONLJxpbwec8j7hLRq pXFuepbtPqX/GefuK8rdo+ppEqpRJ50cJTegchTfWfSjn5/mG1B4Oz9OnOcBEeTLO729n0K9 BeTx1pmisD6P/fyrqZZTozDwVEi7Wo9AOaqWOhuTe8L0FlFIk6fc/yM0wzvDWP7sNrevEYHK V9rd+Yc/Jjt293J4uayrt6DNMmSkAw3nlBq3uK5d54J0FAsAUcsE/W2/ABEBAAGJAh8EGAEI AAkCGwwFAlfy11wACgkQKcRFldZqfsSQyA/+Kx3eWtKyb/y35TjgtjT/Hrtw+aIpr1uK97LA ln1j5m7+lQ/jh0/rvSZjs+YQMYLqVGI8oaaF/u+qrokkU6pfrhVZ49D1BmmSTMBSYgnBDYqZ yZ+uzQnnDYt/mpo2OLbl9BhuifR5QXLp43cE1FIhyDT46wfse5tNZ+ll4m4HtXuTw4W3b4cP Hto10260Mki7hXbkDMZ+icBFDMkrrZyYHSnBhelzIM7XnY7A/XZdulfFcDXEcZhAFEv3ylJs xTnGwzDyP1VAdBFL3hpP1CqfP1Kti4hKcxXZYbIgTSsBjcYbPchw3ktUTU29I/nWKH5gmD+q wFizyhtt8Qhl6U67OdZ/XbRGBXs/7tlYJIGiGZyG7IQtDOX0PsVd+6WRcDdFqkpBwYkxU8gd iCeW+YTQ5d8mXXPT2dhFAeK2hCFa2+IdaXvH8ovjZpTMeKstHrWJUDaSqQ4GFT676DbDyqtm P6Ul9cjGVtXIs64FWqR9wrbwBH1GuIHhDmG9sN5AkyB9mxXaEG3uG4E6qQeedtIKC6p+ebAs aTGgztFWMJDC8LUznu7B0oyWxNVoE/RGt5mesOeAtqYr6Jtdh7unyk8BYP1y4e+SSMwvtwh+ 69tJwNhGYbOJrdX34tXNAKb6r/rFRjVJm+sPPs5ok7LddvV35o+Fho0LRNDsioDV3HytlhA=
Message-ID: <472563ee-5fc3-655d-8e31-138cc774e608@acm.org>
Date: Wed, 24 Oct 2018 01:44:18 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <CAKKJt-e1XFJNrx-LKmpZFDy6ZuaXt5+Lp+Uw90-Bu-M22PMt3Q@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="W3XKfhMwAcgtTYaVZf4OshRPa5w8GxaZn"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/e_xm4t8uSQf7YFYkbRs5I43QRj8>
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: Wed, 24 Oct 2018 08:44:42 -0000

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

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> 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>
>>> 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> 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>> 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>>
>>>>>>>     > 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
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug