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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 24 October 2018 02:28 UTC

Return-Path: <spencerdawkins.ietf@gmail.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 0FE24130DD2; Tue, 23 Oct 2018 19:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 yA0IwEBdr9-v; Tue, 23 Oct 2018 19:28:46 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65089130E5A; Tue, 23 Oct 2018 19:28:45 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id t22-v6so3256285lji.7; Tue, 23 Oct 2018 19:28:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QkTRLklKSZ8BhB6oEf2tcY4bUFUq4rnZj+fHw2tEXSY=; b=d61HmuN1+fbhydUBbEpQto632DYKOpyAMJaA9Ed9U2Ru9E+VCbPGYoHyjJE+kzyCTx PpqQ3iL0sABj5PMNKZcDVjvcdy0Or3eVXyz/kwjS9sE1FQj3Cu4t62M2j2TQU3wwwWvS ZBQvr0P02EyhgQCUtK7WFn4iDpQJxvmG+jJ+YlmMfeXIwkln3VG+V4LM0FnTdbj8gCh7 2VIt5G5DALRyg/zC6LpG2NeZyTsXYLxKBKqtcOaVbKbWXjjc6tFJKW360VJhiTBN2hqB 2VurYH1LW6LGTgR0lFX2kN52GINPhes2fBFgPKh1GYohQb4KndoaFFQg5guN688zCqPa vWeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QkTRLklKSZ8BhB6oEf2tcY4bUFUq4rnZj+fHw2tEXSY=; b=S+C3Kl5bYGalCsw3tdxAffFYQjjDEr7lP3MLFNJ1EcAQ0DSHt5ISfIhAzrF0JI5XI2 5KrcZ+PNLYPfiHylbRdci2c9AKmAemgjpHJxS4t4vpx3TbgtmPoqRHuEEOtztnbLAWT8 2MCncp7RMg0HFO6yc7pZ0kgDg9nArdbI9FmwGoTvgrFdOBEokBk6fTyOvEqcydwQUlyx kEedwj4uBlpbVWFIiCypBfoyCZDINYjrK5GONuflGHxW9HcBr21A30GdefhGuXD6cJJv YJm+8miJxwO/A1PCu0BlQ9pKWInQsIPS77yfaK2hFywC/c4wyEzWxa+KgNs4ID+hc4T2 c54w==
X-Gm-Message-State: AGRZ1gLCczmsW2hKXME69DodtSTvwcgjvtLFyWo4bSxTo8HpU0PaAxuX jD+7Y4OQTXNGN8s3U71CVzM3ziCc43LdR4a6dJg=
X-Google-Smtp-Source: AJdET5eyuwkl9yA82ApflAcx9KyjZslREBt3PHeLvC8m4OjHJL98UEVFfm/5rbisVTYTPqLTJ0QdPLBh3DXPKbKDyVo=
X-Received: by 2002:a2e:93ca:: with SMTP id p10-v6mr440618ljh.158.1540348123257; Tue, 23 Oct 2018 19:28:43 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <c135ad63-bb18-a5f2-4aa2-e2a3268ac26f@acm.org>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Tue, 23 Oct 2018 21:28:29 -0500
Message-ID: <CAKKJt-e1XFJNrx-LKmpZFDy6ZuaXt5+Lp+Uw90-Bu-M22PMt3Q@mail.gmail.com>
To: Marc Petit-Huguenin <petithug@acm.org>
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
Content-Type: multipart/alternative; boundary="000000000000b79f930578f03e57"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/K2vAKJi9Ds86xcJhoNpu8bSgkKk>
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 02:28:51 -0000

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
>
>