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

[Gonzalo Camarillo <[e-mail]>]

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
>