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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Tue, 19 March 2019 01:27 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B77912785F; Mon, 18 Mar 2019 18:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceTFQgQES9Rx; Mon, 18 Mar 2019 18:26:59 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F5571277D8; Mon, 18 Mar 2019 18:26:58 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id q66so2174600ljq.7; Mon, 18 Mar 2019 18:26:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OboqmQxMvAiOjrna5FnaEQoCNU9dSUMR2oCWmQsv8L8=; b=KnBiNfyRzwO8Gcevwk5I/Mk3Ql6YBkmlPlcJ4aHkVDrv0F2WaO5pDnpTamqhSVKqMr nf5J3aZFwGAhqfgYEt65HnSOtwWbYnnpqUIs6Y5PfpnB+dADN5Z1jnO57bI+zMr7NVoD k8tgj20VnXKJKdbyECtLv5Mr0spCxvxuCxRSGSUwULyEaqMlbdwUk97L2nVvw3ikaPJs kQdhGrVHCiL6AVWP3oTV4AfqtBODMEF58JE2o8QGvbnlD9bHQSPorqOtSepuZvSo3Jae dAq2omWqfc3fKHrDhvN20zO9SrBKbdLfGYEbsRpQISAj5PFTZefZBIRU9AoYL2+yeqY9 9m/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OboqmQxMvAiOjrna5FnaEQoCNU9dSUMR2oCWmQsv8L8=; b=cCVlaffR6UAzipl+cKaQudjBiMt8u5y+bPWoODbhFmzy7BTcRjH6/o6bqfHquNnXJw bss2uIreC/qSQFG2oYEZ24l1P+IU2dsbA8BJi7joRjVO0/DA7j8lxoNZVUA7bIHkmK6y X56nGIgqh8Lo9g7iWZyPob/xUeExToWNtAKtpsp9kZm99+NA+MdKTQvbQbFsIewylI2I RwHVyxBI6LAM0F9CbaC2eQh48IYlS9T6x1VLy/6EdIasMa2JLlBWmlHU/llAqQCJ5JM8 dU++/rZlFDbKgMkCvtJ3HXXwxaSlFZywwBZPMPdeTfhXqxNeo5tndm45YQd4qdjtletC zagQ==
X-Gm-Message-State: APjAAAX8tV+tvW2rKqqtfgJpR6ua+3F1slZo5TGk3OE7xG9dBPFhKJ1v FcZdexrMPT95Zy0OvTJYAbagj4zp9jniIMZ2fCc=
X-Google-Smtp-Source: APXvYqz11B4SBogKlYu+qzCwuDm4STSyw3yrwJIr4EEUy7YSZvpaUAoZKQkLc9CL7E4gc8m6QeqK+9b7KEj6U5XVQGg=
X-Received: by 2002:a2e:88d0:: with SMTP id a16mr11904397ljk.77.1552958816202; Mon, 18 Mar 2019 18:26:56 -0700 (PDT)
MIME-Version: 1.0
References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <CABcZeBMn1G8BT13bx3JTs04zwQk8K72+btj=xwC662F5AcANXg@mail.gmail.com> <cbb48225-5089-9275-787c-38fa4504a6a4@acm.org> <CABcZeBPNwu-tr8Tf_DiW2iOVy2NDEJoLwAR-6=EWHZak2gVMYg@mail.gmail.com> <c135ad63-bb18-a5f2-4aa2-e2a3268ac26f@acm.org> <CAKKJt-e1XFJNrx-LKmpZFDy6ZuaXt5+Lp+Uw90-Bu-M22PMt3Q@mail.gmail.com> <472563ee-5fc3-655d-8e31-138cc774e608@acm.org> <CAKKJt-dXijVNnAtYojq9x=9_m0pwAM8XTNP8wUEMvAa+m9UXUA@mail.gmail.com> <af0635b1-e731-0198-3b71-e3267bc10d0e@ericsson.com> <CABcZeBPoFnMBQrfDWcc5TV-=HRRX5CVWM2MO6Byf1QvSYztV3w@mail.gmail.com> <CAKKJt-ekdJuDsGFRQziYdeGqemBiVaQVpUYJiZXuTdNDQU9ySg@mail.gmail.com> <97c561a7-c33a-6121-00c4-09cd11646b98@ericsson.com> <CABcZeBPuLPha64QybuPUc-W+fR2Bqn1rAzDsb908uBNqC9z50A@mail.gmail.com> <D99F4FB6-EA38-49F6-AE00-83570455C6D7@cisco.com> <VI1PR07MB5421AC5849B762B682B52D6883630@VI1PR07MB5421.eurprd07.prod.outlook.com> <CEA96BE8-B0B2-4566-BFB1-6D387D2B1BD6@cisco.com> <4b8f10f7-1eee-c8bc-d9ee-e3f18473de32@ericsson.com> <CABcZeBOHUPPEvGKLz3PXxHkWW+Gaoq=nQrg+0qxh3aa4PFuKnQ@mail.gmail.com>
In-Reply-To: <CABcZeBOHUPPEvGKLz3PXxHkWW+Gaoq=nQrg+0qxh3aa4PFuKnQ@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Mon, 18 Mar 2019 20:26:42 -0500
Message-ID: <CAKKJt-cO=PfpRR8+XOp1Cwn5hmYg5G-ssFgneh96FEo15OFq=Q@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>, Marc Petit-Huguenin <petithug@acm.org>, "tram-chairs@ietf.org" <tram-chairs@ietf.org>, "tram@ietf.org" <tram@ietf.org>, IESG <iesg@ietf.org>, "draft-ietf-tram-stunbis@ietf.org" <draft-ietf-tram-stunbis@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009733a605846866ec"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/E3ydvyJU5X01OzRZgVxpUsdAqcE>
Subject: Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Mar 2019 01:27:06 -0000

Dear All,

On Fri, Mar 8, 2019 at 8:10 PM Eric Rescorla <ekr@rtfm.com> 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 <
> gonzalo.camarillo@ericsson.com> 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 <
>> Gonzalo.Camarillo@ericsson.com> 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 <ekr@rtfm.com
>> >>>> <mailto:ekr@rtfm.com>> 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
>> >>>> <gonzalo.camarillo@ericsson.com
>> >>>> <mailto:gonzalo.camarillo@ericsson.com>> 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 <ekr@rtfm.com
>> >>>>    <mailto:ekr@rtfm.com>
>> >>>>> <mailto:ekr@rtfm.com <mailto:ekr@rtfm.com>>> 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
>> >>>>>      <gonzalo.camarillo@ericsson.com
>> >>>>    <mailto:gonzalo.camarillo@ericsson.com>
>> >>>>>      <mailto:gonzalo.camarillo@ericsson.com
>> >>>>    <mailto:gonzalo.camarillo@ericsson.com>>> 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
>> >>>>>          <petithug@acm.org <mailto:petithug@acm.org>
>> >>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>
>> >>>>>          > <mailto:petithug@acm.org <mailto:petithug@acm.org>
>> >>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>>> 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
>> >>>>>          >     <petithug@acm.org <mailto:petithug@acm.org>
>> >>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>
>> >>>>>          <mailto:petithug@acm.org <mailto:petithug@acm.org>
>> >>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>>> 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
>> >>>>>          >     <petithug@acm.org <mailto:petithug@acm.org>
>> >>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>
>> >>>>>          <mailto:petithug@acm.org <mailto:petithug@acm.org>
>> >>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>>>
>> >>>>>          >     >>> 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 <
>> >>>>>          >     >>>>> Gonzalo.Camarillo@ericsson.com
>> >>>>    <mailto:Gonzalo.Camarillo@ericsson.com>
>> >>>>>          <mailto:Gonzalo.Camarillo@ericsson.com
>> >>>>    <mailto:Gonzalo.Camarillo@ericsson.com>>
>> >>>>>          >     <mailto:Gonzalo.Camarillo@ericsson.com
>> >>>>    <mailto:Gonzalo.Camarillo@ericsson.com>
>> >>>>>          <mailto:Gonzalo.Camarillo@ericsson.com
>> >>>>    <mailto:Gonzalo.Camarillo@ericsson.com>>>> 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 <
>> >>>>>          >     >>>> petithug@acm.org <mailto:petithug@acm.org>
>> >>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>
>> >>>>>          <mailto:petithug@acm.org <mailto:petithug@acm.org>
>> >>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>>
>> >>>>>          >     >>>>>>> <mailto:petithug@acm.org
>> >>>>    <mailto:petithug@acm.org> <mailto:petithug@acm.org
>> >>>>    <mailto:petithug@acm.org>>
>> >>>>>          <mailto:petithug@acm.org <mailto:petithug@acm.org>
>> >>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>>>> wrote:
>> >>>>>          >     >>>>>>>
>> >>>>>          >     >>>>>>>     On 04/22/2018 05:22 PM, Eric Rescorla
>> >>>>    wrote:
>> >>>>>          >     >>>>>>>     > On Sun, Apr 22, 2018 at 2:02 PM, Marc
>> >>>>>          Petit-Huguenin <
>> >>>>>          >     >>>>>> petithug@acm.org <mailto:petithug@acm.org>
>> >>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>
>> >>>>>          <mailto:petithug@acm.org <mailto:petithug@acm.org>
>> >>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>>
>> >>>>>          >     <mailto:petithug@acm.org <mailto:petithug@acm.org>
>> >>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>
>> >>>>>          <mailto:petithug@acm.org <mailto:petithug@acm.org>
>> >>>>    <mailto:petithug@acm.org <mailto:petithug@acm.org>>>>>
>> >>>>>          >     >>>>>>>     > 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: marc@petit-huguenin.org
>> >>>>    <mailto:marc@petit-huguenin.org>
>> >>>>>          <mailto:marc@petit-huguenin.org
>> >>>>    <mailto:marc@petit-huguenin.org>> <mailto:marc@petit-huguenin.org
>> >>>>    <mailto:marc@petit-huguenin.org>
>> >>>>>          <mailto:marc@petit-huguenin.org
>> >>>>    <mailto:marc@petit-huguenin.org>>>
>> >>>>>          >     Blog: https://marc.petit-huguenin.org
>> >>>>    <https://marc.petit-huguenin.org/>
>> >>>>>          >     Profile: https://www.linkedin.com/in/petithug
>> >>>>>          >
>> >>>>>
>> >>>>
>> >>>
>> >
>>
>