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

From: Eric Rescorla <[email-masked]>
Date: Wed, 26 Dec 2018 17:05:23 -0800

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 <
[email-masked]> 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 <[email-masked]
> > <mailto:[email-masked]>> 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
> >     <[email-masked]
> >     <mailto:[email-masked]>> 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
> >         <[email-masked] <mailto:[email-masked]>
> >         > <mailto:[email-masked] <mailto:[email-masked]>>> 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
> >         >     <[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>> 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
> >         >     <[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>>
> >         >     >>> 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 <
> >         >     >>>>> [email-masked]
> >         <mailto:[email-masked]>
> >         >     <mailto:[email-masked]
> >         <mailto:[email-masked]>>> 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 <
> >         >     >>>> [email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>
> >         >     >>>>>>> <mailto:[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
> >         >     >>>>>>>
> >         >     >>>>>>>     On 04/22/2018 05:22 PM, Eric Rescorla wrote:
> >         >     >>>>>>>     > On Sun, Apr 22, 2018 at 2:02 PM, Marc
> >         Petit-Huguenin <
> >         >     >>>>>> [email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>
> >         >     <mailto:[email-masked] <mailto:[email-masked]>
> >         <mailto:[email-masked] <mailto:[email-masked]>>>>
> >         >     >>>>>>>     > 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: [email-masked]
> >         <mailto:[email-masked]> <mailto:[email-masked]
> >         <mailto:[email-masked]>>
> >         >     Blog: https://marc.petit-huguenin.org
> >         >     Profile: https://www.linkedin.com/in/petithug
> >         >
> >
>