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

Eric Rescorla <ekr@rtfm.com> Sat, 09 March 2019 02:10 UTC

Return-Path: <ekr@rtfm.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 60AB1128678 for <tram@ietfa.amsl.com>; Fri, 8 Mar 2019 18:10:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 D0jqZkacl0tF for <tram@ietfa.amsl.com>; Fri, 8 Mar 2019 18:10:48 -0800 (PST)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 5DDB112796B for <tram@ietf.org>; Fri, 8 Mar 2019 18:10:47 -0800 (PST)
Received: by mail-lf1-x12e.google.com with SMTP id a8so15577739lfi.7 for <tram@ietf.org>; Fri, 08 Mar 2019 18:10:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1mGVFqaIAF6icM2BZW2fT88+JHlmzbSUS/2gSjkW4k4=; b=h2dqGzuMp96KJ7H8QWCeRFj7ZAumYy76VwDjAQROraB/IfMxIgDtUooxyomj2KuLf0 8hzRBc24CdT1QkMsGIXVHUz0ygPUqZ1J4SOFLupip1GaXKaxt/OGHwStecGX0aSOBbte u+4Yahmc1L6QTZrbcz32cZl/ZEsGNsxhgRTSnWaFmDXDvMAsASGOOTMJulDSwIl25iQD GL0x9RFpg0qzgBdiN8nNdh81p33vOFrWp+noNTNNMBm5WqziqxX+0FIudKB2dhJXiGMb pHtZP18tgaZcugirdXJ3u1XqQRZhWCn3FaQYSUk4Ehvx98sSFK84trU/uui51ukUFkXB GWEA==
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=1mGVFqaIAF6icM2BZW2fT88+JHlmzbSUS/2gSjkW4k4=; b=pRDR+H3C/25OKxa/XcufZKx62I43db4OIQBDnIvdS6nfN5OdHEUQAbAU/9jRESquhY 2bhAZfDgAV1ONF/86YD8tVjLLwi64B/rPtg39l3CJZCA1BBwFM5JhxxemnLnA8g3tcG5 2buHt7LVdgpGsMLa7ej+MPRPs3YytOGKVIO6P2t4h4FKhqGWmjBD3hF4QadT8yn4dE2i iu+wXwH5R/0dZrNcgE49BGXMRinLbeHiFYp56H3xfgod1ET5Z6xv91DiT/S1EdUAa5/h Uy78LJdX9OaqMd36gj3Q799SPFfLMPUkNUQ1JV6ntwB9ZOF24udnJRTteZKNLhLljnyj XnJA==
X-Gm-Message-State: APjAAAVF/87nQnuiSf4DlCgkO9tNwT7MhhC7hurSR5lejwAc/T4Qm5ha Qm2MzjyqJ+awKaPgCmdvpoVCaeAgLAPS4R7wN9Z8EA==
X-Google-Smtp-Source: APXvYqyToGl9NtcMTErr2L4PnmTX+mZAleXWlAgMh7w6dxW6IogGN4wdEl4YR4I4VYE9E95OLpTQEBvJDwkfbo1rtfw=
X-Received: by 2002:ac2:529c:: with SMTP id q28mr7860409lfm.123.1552097445091; Fri, 08 Mar 2019 18:10:45 -0800 (PST)
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>
In-Reply-To: <4b8f10f7-1eee-c8bc-d9ee-e3f18473de32@ericsson.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 8 Mar 2019 18:10:07 -0800
Message-ID: <CABcZeBOHUPPEvGKLz3PXxHkWW+Gaoq=nQrg+0qxh3aa4PFuKnQ@mail.gmail.com>
To: Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Cc: "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.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="000000000000df312105839fd8d6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/J_8aXYRHaMpmRkN8jAgfJEPNwwc>
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: Sat, 09 Mar 2019 02:10:54 -0000

Thanks for the call yesterday.

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
> >>>>>          >
> >>>>>
> >>>>
> >>>
> >
>