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

[Eric Rescorla <[e-mail]>]

Spencer, why don't; you override it and then I can take a final look

On Thu, Mar 21, 2019 at 11:22 AM Gonzalo Salgueiro (gsalguei) <
[e-mail]> wrote:

> 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]> 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]> 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]> wrote:
> >
> > Dear All,
> >
> >> On Fri, Mar 8, 2019 at 8:10 PM Eric Rescorla <[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]> 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]> 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]>> 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]>> 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]>>> 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]>>> 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]>>>> 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]>>>> 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]>>>>
> >>>>>>>>>>>> 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]>>>> 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]>>>>> 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]>>>>>
> >>>>>>>>>>>>>>>>> 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
>
>
>