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: 9a23:Oht2ohXMF8oMRGph1eMBAiMvU0vV8LGuZFwc94YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTFdE7KdehAk8GIiAAEz/IuTtank1B81GW0Jo/lmwMFNeH4D1YFiB6nA=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AFAACNR5Bc/4ENJK1aCRoBAQEBAQIBAQEBBwIBAQEBgVEFAQEBAQsBgT1QA2hMKAQLJ4QLg0cDhFKKYYIyJYkyjVGBLhSBEANUCwEBIwmEQAIXhEMiNAkNAQEDAQEJAQMCbRwMhUoBAQEDARoJBA0MAQEmBQwBBAsCAQgYAgIRAw8DAgICHxEUARACBA4FgyIBgV0DDQgBDp8GAooUcXwzgngBAQU6CYECQYMLDQuCDAMFgQskAYRbhAt2gTYdF4FAP4ERJwwTgU5+gldHAgECAYEYDQUBCAMGAgEGAi0oEIIBOjGCJooXO4FhKoYThSGMFDUJAodZiAyDPxmBfIVwhRiGVIwghGKBNotNAgQCBAUCDgEBBYFHOEIjcXAVOyoBgg0BATKBcxcLAQEWE4M4hRSFP3IBgSeGBCSCKQEB
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
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Camarillo
- [tram] Eric Rescorla's Discuss on draft-ietf-tram… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Marc Petit-Huguenin
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Marc Petit-Huguenin
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Marc Petit-Huguenin
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Marc Petit-Huguenin
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Brandon Williams
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Matthew A. Miller
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Brandon Williams
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Marc Petit-Huguenin
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Marc Petit-Huguenin
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Spencer Dawkins at IETF
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Marc Petit-Huguenin
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Spencer Dawkins at IETF
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Camarillo
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Spencer Dawkins at IETF
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Camarillo
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Camarillo
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Salgueiro (gsalguei)
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Camarillo
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Salgueiro (gsalguei)
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Camarillo
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Spencer Dawkins at IETF
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Salgueiro (gsalguei)
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Salgueiro (gsalguei)
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- [tram] Blackout posting of draft-ietf-tram-stunbi… Spencer Dawkins at IETF
- Re: [tram] Blackout posting of draft-ietf-tram-st… Gonzalo Salgueiro (gsalguei)