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

["Gonzalo Salgueiro (gsalguei)" <[e-mail]>]

Hi Eric -

I’m attaching the -21 that will be published once the I-D submission tool opens up (or Spencer can override and it published before then).  It uses your proposed bid down protection disclaimer text (save for minor nits I cleaned up).

If this looks good then from my perspective we are done and your DISCUSS can be cleared and we can proceed with publication.

Thanks for all your help.

Cheers,

Gonzalo


On Mar 20, 2019, at 3:57 PM, Eric Rescorla <[e-mail]<mailto:[e-mail]>> wrote:

Gonzalo,

This text still seems to me to need some work. Here is a revised version.

SHA-256 was chosen as the new default for password
hashing for its compability with RFC 7616 but because SHA-256 (like
MD5) is a comparatively fast algorithm, it does little to deter
brute force attacks. Specifically, this means that if the
user has a weak password:

* An attacker who captures the server's password file can often
  determine the user's password and thus impersonate the user
  to other servers where they have used that password. Note that
  such an attacker can impersonate the user to the server itself
  without any brute force attack.

* An attacker who captures a single exchange can brute force
  the user's password and thus potentially impersonate the
  user to the server and other servers where they have used
  the same pasword.

A stronger (which is to say slower) algorithm, like Argon2
[I-D.irtf-cfrg-argon2], would help both of these cases, but in the
case of the first attack, only after until the database entry for this
user is updated to exclusively use that stronger mechanism.

The bid-down defenses in this protocol prevent an attacker from
forcing the client and server to complete a handshake using weaker
algorithms than they jointly support, but only if the weakest joint
algorithm is strong enough that it cannot be brute-forced. However,
this does not defend against many attacks on those algorithms;
specifically, an on-path attacker might perform a bid-down attack on a
client which supported both Argon2 and SHA-256 for password hashing
and use that to collect a MESSAGE-INTEGRITY-SHA256 value which it uses
for an offline brute-force attack. This would be detected when the
server receives the second request, but that does not prevent the
attacker from obtaining the MESSAGE-INTEGRITY-SHA256 value.

Similarly, an attack against the USERHASH mechanism will not succeed
in establishing a session as the server will detect that the feature
was discarded on-path, but the client would still have been convinced
to send its username in clear in the USERNAME attribute, thus
disclosing it to the attacker.

-Ekr


On Mon, Mar 18, 2019 at 6:37 PM Gonzalo Salgueiro (gsalguei) <[e-mail]<mailto:[e-mail]>> wrote:
Thanks, Spencer.  In the interest of expeditiousness I’ve emailed Eric to review the newly published -20 to ensure it addresses his DISCUSS points. Hoping to get this done before Eric steps down as AD.

Cheers,

Gonzalo



> On Mar 18, 2019, at 9:27 PM, Spencer Dawkins at IETF <[e-mail]<mailto:[e-mail]>> wrote:
>
> Dear All,
>
>> On Fri, Mar 8, 2019 at 8:10 PM Eric Rescorla <[e-mail]<mailto:[e-mail]>> wrote:
>>
>> Thanks for the call yesterday.
>>
>
> Thanks to all for moving this specification forward.
>
> If the current conversation turns out to converge on this topic before next
> Wednesday, I'm happy to approve a revised draft after Eric clears his
> Discuss.
>
> If I can help in any way, please let me know.
>
> Spencer
>
>
>>
>> First, here is what I recommend for the question of SHA-256 for password
>> hashing:
>>
>>  Note: the use of SHA-256 for password hashing does not meet modern
>>  standards, which are aimed at slowing down exhaustive password search
>>  by providing a relatively slow minimum time to compute the
>>  hash. Although better algorithms such as Argon2
>>  [https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/] are
>>  available, SHA-256 was chosen for consistency with RFC 7616.
>>
>>
>> Now, WRT to the anti-downgrade situation. Here's a stylized version
>> of the protocol:
>>
>> Client                                                  Server
>>
>> Hello ->
>>                                          <- Nonce, Algorithms
>> HMAC-H1(H2(Password), Nonce, Algorithms, Msg) ->
>>                                 <- HMAC-H1(H2(Password), ...)
>>
>> Where H1 and H2 are the HMAC hash functions and the password hashing
>> function respectively.
>>
>> Now, if we assume that the attacker does not know Password and that
>> both H1 and H2 are secure, then it is not possible for the attacker to
>> complete the transaction or modify any of the messages. Further, if
>> the weakest joint algorithm that both sides support is still strong,
>> then an attacker cannot influence the algorithm negotiation [0]. This
>> property is provided by covering the algorithms under the MAC.
>>
>> However, my point is that this is not a very useful property.
>>
>> First, consider the case in which the implementations jointly support
>> one strong algorithm and one weak algorithm. E.g., for H1 they support
>> SHA-256 and the function Z(x) which always emits 0s. This allows
>> an attacker to force the client and server into using Z, as follows.
>>
>>
>> Client                      Attacker                   Server
>>
>> Hello ->
>>                            Hello ->
>>                                      <- Nonce, Alg=SHA256, Z
>>                <- Nonce, Alg=Z
>> Z(H2(Password), Nonce, Alg=Z)) ->
>>                        Z(H2(Password), Nonce, Alg=SHA256, Z))
>>
>> The issue here is that the only thing that the MAC is doing is
>> authenticating the transaction, and if you can't trust it to do that,
>> you can't trust it to authenticate the bid-down defense either.
>>
>>
>> During our discussion, there was a suggestion that it was useful to
>> have biddown defense to defend against weaknesses in H2. I don't think
>> that that's true either. First, remember that the purpose of H2 is to
>> prevent an attacker who recovers the password database from learning
>> the user's true password. This is not about defending the server from
>> attack (because knowing A1 is enough to attack the server) but about
>> preventing the attacker from learning a password which might have been
>> reused on another site.
>>
>> Now, it's also possible to brute-force the user's password just from
>> the protocol transcript: if you capture the client's first message
>> with MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256, you can just keep
>> trying passwords until you get the right MAC. Note that this is a
>> passive attack. This is comparatively fast because SHA256 and MD5 are
>> fast.
>>
>> A much stronger H2 (e.g., Argon) would help against this, but the
>> problem now becomes that the client supports H2 == MD5 (or SHA-256)
>> and so even if the server supports Argon, the attacker can mount a
>> bid-down defense in which it modifies the server's first message to
>> just advertise MD5 and thus get the client to provide a suitable
>> message. The bid-down defense would prevent the authentication
>> transaction from completing, but that's not necessary for this
>> attack because the attacker can just brute-force the password from
>> the message it has. To make this work, you would need something
>> like a PAKE, which this is not.
>>
>> Finally, you might think that the server has two databases, one
>> which uses Argon and one which uses MD5 and it wants to gradually
>> phase out the MD5 one, which it will do when no client authenticates
>> with MD5 for a very long time. An anti-biddown defense would sort
>> of work here, but the fact that the attacker would have to be
>> active essentially indefinitely to keep the server confused about
>> the state of clients -- and that the attacker can likely just
>> get a valid account and then insist on using MD5 -- makes this a
>> not very useful defense.
>>
>> I think this makes a pretty persuasive case that the bid-down defense
>> isn't useful except in the formal "attacker cannot influence
>> negotiation" sense. With that said, in the spirit of getting this done, I
>> guess
>> I'm willing to let this go if the security considerations make clear
>> that it is only a very limited mechanism.
>>
>> -Ekr
>>
>>
>> [0] This is principally about H1. As long as the H2 approximately
>> evenly distributes the password over its range, then cryptographic
>> strength is not important for this question. For instance, you
>> could replace H2 with an identity function and still have a
>> secure protocol.
>>
>>
>>
>>
>>
>>
>> On Wed, Feb 20, 2019 at 4:03 AM Gonzalo Camarillo <
>> [e-mail]<mailto:[e-mail]>> wrote:
>>
>>> Thanks, Gonzalo! Please, let us know the agreed way forward once you
>>> have the call.
>>>
>>> Cheers,
>>>
>>> Gonzalo
>>>
>>>> On 19-Feb-19 20:05, Gonzalo Salgueiro (gsalguei) wrote:
>>>> Hi Gonzalo -
>>>>
>>>> We have scheduled a conference call with Ekr, Simon, Marc and myself on
>>> March 7th to discuss the last two remaining issues.  Will update with
>>> resolutions once this has occurred.
>>>>
>>>> Cheers,
>>>>
>>>> Gonzalo
>>>>
>>>>
>>>>
>>>>> On Feb 18, 2019, at 8:18 AM, Gonzalo Camarillo <
>>> [e-mail]<mailto:[e-mail]>> wrote:
>>>>>
>>>>> Hi Gonzalo S,
>>>>>
>>>>> what is the status of this one?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Gonzalo
>>>>>
>>>>>> On 18-Jan-19 20:16, Gonzalo Salgueiro (gsalguei) wrote:
>>>>>> Totally agree, Ekr.  Marc and I are meeting to come up with a proposal
>>>>>> but I do agree we need to have a call to get this put to bed once and
>>>>>> for all.  We’ll offer some potential dates in the next 2-3 weeks.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Gonzalo
>>>>>>
>>>>>>
>>>>>>> On Dec 26, 2018, at 8:05 PM, Eric Rescorla <[e-mail]<mailto:[e-mail]>
>>>>>>> <mailto:[e-mail]<mailto:[e-mail]>>> wrote:
>>>>>>>
>>>>>>> We really need to bring this to a close before both Spencer and I
>>> step
>>>>>>> down, I should think.
>>>>>>>
>>>>>>> -Ekr
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Nov 22, 2018 at 4:30 AM Gonzalo Camarillo
>>>>>>> <[e-mail]<mailto:[e-mail]>
>>>>>>> <mailto:[e-mail]<mailto:[e-mail]>>> wrote:
>>>>>>>
>>>>>>>   Eric, Spencer, thanks for the status update!
>>>>>>>
>>>>>>>   Authors, could you please let us know when you plan to get to
>>> this?
>>>>>>>
>>>>>>>   Gonzalo
>>>>>>>
>>>>>>>>   On 19-Nov-18 23:04, Spencer Dawkins at IETF wrote:
>>>>>>>> Hi, Gonzalo,
>>>>>>>> On Mon, Nov 19, 2018 at 9:06 AM Eric Rescorla <[e-mail]<mailto:[e-mail]>
>>>>>>>   <mailto:[e-mail]<mailto:[e-mail]>>
>>>>>>>> <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[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]<mailto:[e-mail]>
>>>>>>>   <mailto:[e-mail]<mailto:[e-mail]>>
>>>>>>>>     <mailto:[e-mail]<mailto:[e-mail]>
>>>>>>>   <mailto:[e-mail]<mailto:[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]> <mailto:[e-mail]<mailto:[e-mail]>>
>>>>>>>   <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>
>>>>>>>>> <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>>>>>>>   <mailto:[e-mail]<mailto:[e-mail]> <mailto:[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]> <mailto:[e-mail]<mailto:[e-mail]>>
>>>>>>>   <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>
>>>>>>>>         <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>>>>>>>   <mailto:[e-mail]<mailto:[e-mail]> <mailto:[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]> <mailto:[e-mail]<mailto:[e-mail]>>
>>>>>>>   <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>
>>>>>>>>         <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>>>>>>>   <mailto:[e-mail]<mailto:[e-mail]> <mailto:[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]>
>>>>>>>   <mailto:[e-mail]<mailto:[e-mail]>>
>>>>>>>>         <mailto:[e-mail]<mailto:[e-mail]>
>>>>>>>   <mailto:[e-mail]<mailto:[e-mail]>>>
>>>>>>>>>    <mailto:[e-mail]<mailto:[e-mail]>
>>>>>>>   <mailto:[e-mail]<mailto:[e-mail]>>
>>>>>>>>         <mailto:[e-mail]<mailto:[e-mail]>
>>>>>>>   <mailto:[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]>>
>>>>>>>   <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>
>>>>>>>>         <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>>>>>>>   <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>>
>>>>>>>>>>>>>>>> <mailto:[e-mail]<mailto:[e-mail]>
>>>>>>>   <mailto:[e-mail]<mailto:[e-mail]>> <mailto:[e-mail]<mailto:[e-mail]>
>>>>>>>   <mailto:[e-mail]<mailto:[e-mail]>>>
>>>>>>>>         <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>>>>>>>   <mailto:[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]>>
>>>>>>>   <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>
>>>>>>>>         <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>>>>>>>   <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>>
>>>>>>>>>    <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>>>>>>>   <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>
>>>>>>>>         <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>>>>>>>   <mailto:[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