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

"Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com> Tue, 19 March 2019 01:37 UTC

Return-Path: <gsalguei@cisco.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 CD74D130ED0; Mon, 18 Mar 2019 18:37:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Psaudp7K; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=WobXPju4
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 Lti6CHqrFO08; Mon, 18 Mar 2019 18:37:31 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EF7D130ECA; Mon, 18 Mar 2019 18:37:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44584; q=dns/txt; s=iport; t=1552959450; x=1554169050; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LhzN5nGaSe/G/sNO274/SIsE4qqqxhCLi4GKl735Ocg=; b=Psaudp7KvXwihFTOIejZc5B3OFe57y8XHW3IrSKo0nK27j5V6jHnb6bF 3WSu8erqb8G773aLhi447HoK9SQ/hTlSJVqNzf81tzvopUO24XW0TCbXh R1s9oAONh+YqP3gnttNtvJI9Wj9EGH/TSOdeD4/CJLKyZ6UVeSgiSfOIy U=;
IronPort-PHdr: =?us-ascii?q?9a23=3AOht2ohXMF8oMRGph1eMBAiMvU0vV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank1B81GW0Jo/lmwMFNeH4D1YFiB6nA=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAACNR5Bc/4ENJK1aCRoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVEFAQEBAQsBgT1QA2hMKAQLJ4QLg0cDhFKKYYIyJYkyjVG?= =?us-ascii?q?BLhSBEANUCwEBIwmEQAIXhEMiNAkNAQEDAQEJAQMCbRwMhUoBAQEDARoJBA0?= =?us-ascii?q?MAQEmBQwBBAsCAQgYAgIRAw8DAgICHxEUARACBA4FgyIBgV0DDQgBDp8GAoo?= =?us-ascii?q?UcXwzgngBAQU6CYECQYMLDQuCDAMFgQskAYRbhAt2gTYdF4FAP4ERJwwTgU5?= =?us-ascii?q?+gldHAgECAYEYDQUBCAMGAgEGAi0oEIIBOjGCJooXO4FhKoYThSGMFDUJAod?= =?us-ascii?q?ZiAyDPxmBfIVwhRiGVIwghGKBNotNAgQCBAUCDgEBBYFHOEIjcXAVOyoBgg0?= =?us-ascii?q?BATKBcxcLAQEWE4M4hRSFP3IBgSeGBCSCKQEB?=
X-IronPort-AV: E=Sophos;i="5.58,496,1544486400"; d="scan'208";a="526528780"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Mar 2019 01:37:27 +0000
Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x2J1bR5B031358 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Mar 2019 01:37:27 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Mar 2019 20:37:27 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Mar 2019 20:37:26 -0500
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 18 Mar 2019 20:37:26 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LhzN5nGaSe/G/sNO274/SIsE4qqqxhCLi4GKl735Ocg=; b=WobXPju4zHQiPGSjMOnE6kEMMp+9NfHea1URR/U+KEGWesPb71y/il+qv9NXP974zerpQhEPbVXpuirirnU0lUAjbCa9g71gtiZ3VwtOoc2T/cOxQ/pP8Oyhb1dvHYtlVQNbGrEArL2Xz7PHF00gX2xkIcWOs3ga+8+Ij4EbMEc=
Received: from BY5PR11MB3895.namprd11.prod.outlook.com (10.255.72.92) by BY5PR11MB4055.namprd11.prod.outlook.com (10.255.162.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.13; Tue, 19 Mar 2019 01:37:24 +0000
Received: from BY5PR11MB3895.namprd11.prod.outlook.com ([fe80::85d0:5bc1:f305:1423]) by BY5PR11MB3895.namprd11.prod.outlook.com ([fe80::85d0:5bc1:f305:1423%6]) with mapi id 15.20.1709.015; Tue, 19 Mar 2019 01:37:24 +0000
From: "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
CC: Eric Rescorla <ekr@rtfm.com>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.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>
Thread-Topic: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)
Thread-Index: AQHUa0FPQa4RlvmGQ0G0i0rcGeSYLqUuaM8AgABS4ICAKPySAIAACJIAgABkJoCABCeEgIA2QhKAgCOzSICAXM16RYAAAsel
Date: Tue, 19 Mar 2019 01:37:24 +0000
Message-ID: <A695E6C8-E8AF-4277-948E-845EFF62085D@cisco.com>
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>, <CAKKJt-cO=PfpRR8+XOp1Cwn5hmYg5G-ssFgneh96FEo15OFq=Q@mail.gmail.com>
In-Reply-To: <CAKKJt-cO=PfpRR8+XOp1Cwn5hmYg5G-ssFgneh96FEo15OFq=Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=gsalguei@cisco.com;
x-originating-ip: [2600:387:2:80f::28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ddab4611-cf9c-4ce3-49e5-08d6ac0b7019
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BY5PR11MB4055;
x-ms-traffictypediagnostic: BY5PR11MB4055:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <BY5PR11MB405570E8CA7A0EEC22F0EF85C7400@BY5PR11MB4055.namprd11.prod.outlook.com>
x-forefront-prvs: 0981815F2F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(376002)(346002)(136003)(366004)(51444003)(54164003)(189003)(199004)(51914003)(54094003)(5660300002)(446003)(476003)(2616005)(99286004)(36756003)(486006)(229853002)(14444005)(256004)(97736004)(105586002)(11346002)(82746002)(6116002)(106356001)(71190400001)(8936002)(71200400001)(54906003)(316002)(2906002)(305945005)(83716004)(93886005)(46003)(6246003)(81156014)(14454004)(53946003)(6512007)(81166006)(53546011)(30864003)(6916009)(7736002)(25786009)(86362001)(4326008)(68736007)(478600001)(966005)(6306002)(102836004)(6506007)(33656002)(186003)(561944003)(6436002)(53936002)(76176011)(6486002)(8676002)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR11MB4055; H:BY5PR11MB3895.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: bSeyj8LZ+WqBkIQTyFXdKXe1yArhWqkitDuwaTKr6ajGLF/23ZnkyoZ4xr2K8E/X/L3DEopdfmZeuX07DwAPldZ3z8rvLbY3cdzP0A1T9Mz0P/qZSVgjn0Zq6y27Dlqdz/SDTTTkRjhYcTViPpDEO7ZhJxc1C4tZBltU34fUdIVwAV1cb4DM7mapamboEnDCyM0YQ1Gos8IZuTAN28fdak5eXN42q2xtm6XWT23gJhAIqdhyobH7QO0Oq0M1laSSj63uzoms9FeonJBIzSnCHlJm5HkR6XrAQjfnaUKzGA/JLmD5TOb6hdaRdspeKCgPd/DzY/Uoh+YyvR/4qrcN2fc4CmkAtudDHxIMGmrbfXMF9tpqE1bFMTPYUK2ibGFSDaEz9cvQ1kBmp2Ucj28KuUYTtUbeeMB7/09qcumgthM=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ddab4611-cf9c-4ce3-49e5-08d6ac0b7019
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2019 01:37:24.3105 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4055
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.28, xch-rcd-018.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/_ByuQYLbqZBA6Ur2ZUxb27_RWIo>
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:37:36 -0000

Thanks, Spencer.  In the interest of expeditiousness I’ve emailed Eric to review the newly published -20 to ensure it addresses his DISCUSS points. Hoping to get this done before Eric steps down as AD.

Cheers,

Gonzalo 



> On Mar 18, 2019, at 9:27 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> 
> 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