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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Gonzalo,
On Mon, Nov 19, 2018 at 9:06 AM Eric Rescorla <[e-mail]> 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 <
> [e-mail]> 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 <[e-mail]
>> > <mailto:[e-mail]>> 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
>> >     <[e-mail] <mailto:[e-mail]>> 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
>> >     <[e-mail] <mailto:[e-mail]>>
>> >     >>> 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 <
>> >     >>>>> [e-mail]
>> >     <mailto:[e-mail]>> 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 <
>> >     >>>> [e-mail] <mailto:[e-mail]>
>> >     >>>>>>> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>> >     >>>>>>>
>> >     >>>>>>>     On 04/22/2018 05:22 PM, Eric Rescorla wrote:
>> >     >>>>>>>     > On Sun, Apr 22, 2018 at 2:02 PM, Marc Petit-Huguenin <
>> >     >>>>>> [e-mail] <mailto:[e-mail]>
>> >     <mailto:[e-mail] <mailto:[e-mail]>>>
>> >     >>>>>>>     > 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: [e-mail] <mailto:[e-mail]>
>> >     Blog: https://marc.petit-huguenin.org
>> >     Profile: https://www.linkedin.com/in/petithug
>> >
>>
>