From nobody Sun Oct 7 05:48:11 2018 Return-Path: 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 3129C130E1E; Sun, 7 Oct 2018 05:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 IEzsipSXdv0m; Sun, 7 Oct 2018 05:48:01 -0700 (PDT) Received: from implementers.org (unknown [92.243.22.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0245130E1A; Sun, 7 Oct 2018 05:48:00 -0700 (PDT) Received: from [IPv6:2601:648:8400:8e7d:6571:21bd:7029:6ef2] (unknown [IPv6:2601:648:8400:8e7d:6571:21bd:7029:6ef2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 296C8AE009; Sun, 7 Oct 2018 14:47:55 +0200 (CEST) To: Benjamin Kaduk Cc: Adam Roach , Gonzalo Camarillo , The IESG , tram-chairs@ietf.org, draft-ietf-tram-stunbis@ietf.org, Tolga Asveren , tram@ietf.org References: <152403138853.31946.14807823535362928987.idtracker@ietfa.amsl.com> <27cb2f70-d907-b61f-bb5a-6b19053238fe@petit-huguenin.org> <1e8cd5de-06de-6745-fc4d-d15fcdd0b4d9@petit-huguenin.org> <5ff10fb0-301e-5d97-01b0-f15296bae0d3@nostrum.com> <20180909014711.GT73164@kduck.kaduk.org> From: Marc Petit-Huguenin Openpgp: preference=signencrypt Autocrypt: addr=marc@petit-huguenin.org; prefer-encrypt=mutual; keydata= mQINBE6Mh9wBEADrUEDZChteJbQtsHwZITZExr7TAqT7pniNwhBX3nFgd+FrV3lsLKJ1rym2 52MAYpubXEJZGzMp6uCCAnROWbtmQbOm8z/jHnjxHhPqfuYCYPpAQqu8K/Sc194Rp37krMwB jz32yr7+gvWLzRgQGKIh9d2mzy8QLMETVWWQWGb6fEfpOxXo0wumN1rc/275kZwOu44JIPGg zbgwZdnEqYOUUa18K9MXeRDoWbwDISP30CvKuZDwD14lbBE3o7tBQrU9uoMhE7eFlTjbsCox qoubI2tZSuOTF8mRXjPmNrRGtf9mYkQnOB7y6qy/QxmOVMq4IRtHzOYIm/EZ6NTodcpZQHOM 2v6B6YK9uKrYrapSpJzn4f9oU7alT31Y3o2hOlxAWDQ16+Dd1MOPYsKQXOwY1/ihm4PTjiJ8 ud8yPzy7c+BSVs5wkBU6QuLNIgZHrrxdn+KxM+F/oAVtfzO7XzVoeOcXyWi3/CHL5pgoBruY enIF/RrRuplpy09pvZjmFPNfqKBYJGnqpQuqsQwO7LsFqDqfY2EuHg+KsGN1XuN+jxXc48/1 gCnKw7ALSPWEb7g25wD6KfiZTAcyRTG8LePNFQKhw61LbIWmkw9EaVLyXvwPTc1iCSc0dDT/ pcT/z+8xrWOyWGZNZAjR584NlDpKollbItcxYtFcYZkvTCmOVwARAQABtC1NYXJjIFBldGl0 LUh1Z3VlbmluIDxtYXJjQHBldGl0LWh1Z3VlbmluLm9yZz6JAjsEEwEIACUCGyMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheAAhkBBQJX8tdbAAoJECnERZXWan7EiNkQAIbS72cyalFjxQ1l vEW9S8NjjwIMbb5+NC2XqDakAmZq+Aav/Yfk8aEc+eAWBboVC3NBBjYojMRXK1XEnD7xPQ1X rWd23TDibKajy/2fo/MS9/s6uPFOAINi1ykOMq8ShxMHcIPC/dvVt59a7DV1KPGlnUheNR7N 4rIbkL5KndatD38yTGkyKsFvVKTHJn3y5zqHTGP0BjE1rxsGEBn4h+EzxVCIMVFQUeMVPKPV dlQY9fxdicSGPK2WKo1KL3CVpnYTuNCAVIGA9DPTXPPKvEte+/+xv10I03pj4w87iMUZt7Ca FTO55Gsf8hZvmpuB224yzrAbquA450EUVcQ7KAPcHrph5KAu0d3nwrjrUDn/RWWbyRiVrPtf hmnAAhkSv7oOxzyMdLvqt7XKGKbABhrl1ZRF8QbquOkyu8n3Bz2Osgw7JyFn9N6svlFPmpML UTEi64NewvN6zszKs/zBS6bn7na75gxHNvjSZpSF6uSLYgmKbyG8vkY/i0s0e0njjOHcpNx1 0mNZ+wOoCgHtSCZFyv14ncioJTiSjtZCs+srW9PFlbOg73C1Op42xV5Y+dh/mCC+rweKtB3t yTAy52v8vPG0VjsLS52x6yUsoDjYV33AmTEaWmGzN5t8BX/qh7pgNIEd9TEwrR3B4LjqMmUk XXWSJG5IM8Zr2OE/t2vyuQINBE6Mh9wBEAC/i4Lh4XEgwi/yHr3XLx/+f38ztn5rrk8XRsK2 WUpu5evxw9iK2oelqWtS71XkW57EavJOjvP4t8FWqRKED5jWN741n12iW/EeLx3KoHMcPTfY 4WWvprxiZPfnCIpQ8j8x0QQSA+Hf96BSkAkOGNkiJDuus5z4XwTktn9gFOwLVx4VRMo+lrCy um6BDHI+4/sOWnrNp2WptI4YKM/uA0HpuLpPKLra0ZW6Bp2TewNpAjbst/VHjqewab0PeSCn CQiHkqIibdgOATT0K6KoVtMxp/WPRSfVImfWCHjT2G7HFMcb6w/jlPSb+u4VtL9yn76CCg8F SqTtzFuqPtbXkhrdSgks/grxiQryMXwpO0uSuUgZ3u2TSs+65Bl2CM5cq+2aBIER5qhpnCv7 B00uHuoNqUEK0VEpLKcqi2ZeVM5oO8iOaBgS9Gh082HQ5JDijEV2J5e4rwXjbRnJ4hqpTjSy caW8HnPI+4S0aqVxbnqW7T6l/xnn7ivK3aPqaRKqUSedHCU3oHIU31n0o5+f5htQeDs/Tpzn ARHkyzu9vZ9CvQXk8daZorA+j/38q6mWU6Mw8FRIu1qPQDmqljobk3vC9BZRSJOn3P8jNMM7 w1j+7Da3rxGBylfa3fmHPyY7dvdyeLmsq7egzTJkpAMN55Qat7iuXeeCdBQLAFHLBP1tvwAR AQABiQIfBBgBCAAJAhsMBQJX8tdcAAoJECnERZXWan7EkMgP/isd3lrSsm/8t+U44LY0/x67 cPmiKa9biveywJZ9Y+Zu/pUP44dP670mY7PmEDGC6lRiPKGmhf7vqq6JJFOqX64VWePQ9QZp kkzAUmIJwQ2Kmcmfrs0J5w2Lf5qaNji25fQYbon0eUFy6eN3BNRSIcg0+OsH7HubTWfpZeJu B7V7k8OFt2+HDx7aNdNutDJIu4V25AzGfonARQzJK62cmB0pwYXpcyDO152OwP12XbpXxXA1 xHGYQBRL98pSbMU5xsMw8j9VQHQRS94aT9Qqnz9SrYuISnMV2WGyIE0rAY3GGz3IcN5LVE1N vSP51ih+YJg/qsBYs8obbfEIZelOuznWf120RgV7P+7ZWCSBohmchuyELQzl9D7FXfulkXA3 RapKQcGJMVPIHYgnlvmE0OXfJl1z09nYRQHitoQhWtviHWl7x/KL42aUzHirLR61iVA2kqkO BhU+u+g2w8qrZj+lJfXIxlbVyLOuBVqkfcK28AR9RriB4Q5hvbDeQJMgfZsV2hBt7huBOqkH nnbSCguqfnmwLGkxoM7RVjCQwvC1M57uwdKMlsTVaBP0RreZnrDngLamK+ibXYe7p8pPAWD9 cuHvkkjML7cIfuvbScDYRmGzia3V9+LVzQCm+q/6xUY1SZvrDz7OaJOy3Xb1d+aPhYaNC0TQ 7IqA1dx8rZYQ Message-ID: <49512499-0e71-1f5b-e12c-213a3dd88d91@petit-huguenin.org> Date: Sun, 7 Oct 2018 05:47:54 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180909014711.GT73164@kduck.kaduk.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YUbsRsAxd584CUGEYo73oJTHyKcYdFXZN" Archived-At: Subject: Re: [tram] Adam Roach'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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 12:48:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --YUbsRsAxd584CUGEYo73oJTHyKcYdFXZN Content-Type: multipart/mixed; boundary="A7yGGfktMhaxQnoXo51QP8UOVAs2agfIN"; protected-headers="v1" From: Marc Petit-Huguenin To: Benjamin Kaduk Cc: Adam Roach , Gonzalo Camarillo , The IESG , tram-chairs@ietf.org, draft-ietf-tram-stunbis@ietf.org, Tolga Asveren , tram@ietf.org Message-ID: <49512499-0e71-1f5b-e12c-213a3dd88d91@petit-huguenin.org> Subject: Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) References: <152403138853.31946.14807823535362928987.idtracker@ietfa.amsl.com> <27cb2f70-d907-b61f-bb5a-6b19053238fe@petit-huguenin.org> <1e8cd5de-06de-6745-fc4d-d15fcdd0b4d9@petit-huguenin.org> <5ff10fb0-301e-5d97-01b0-f15296bae0d3@nostrum.com> <20180909014711.GT73164@kduck.kaduk.org> In-Reply-To: <20180909014711.GT73164@kduck.kaduk.org> --A7yGGfktMhaxQnoXo51QP8UOVAs2agfIN Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Benjamin, See inline. On 09/08/2018 06:52 PM, Benjamin Kaduk wrote: > Hi Marc, >=20 > On Sat, Sep 08, 2018 at 02:59:41PM -0700, Marc Petit-Huguenin wrote: >> Hi Adam, >> >> Apologies for the delay in working on that. >> >> For the first issue, the fix is in my copy of the draft. >> >> As for the second issue, Section 8.1 says: >> >> 'A "stuns" URI >> containing an IP address MUST be rejected, unless the domain name is >> provided by the same mechanism that provided the STUN URI, and that >> domain name can be passed to the verification code.' >> >> That text was never about IP addresses in certificates, but about the = way a STUN (or TURN really, but that draft does not care about TURN) serv= er IP address is passed to a WebRTC browser. RFC 7064 permits to store a= n IP address directly inside a stun URI, and RFC 7350 extended that to st= uns URI, and in fact the text above is directly copied from RFC 7350. >> >> The idea is that a stun URI can be provisioned by a JavaScript program= >> downloaded by a WebRTC browser as part of the initialization of a WebR= TC >> application. A security assumption is that using a stuns URI that >> contains an API address is safe if the Javascript program was download= ed > ^^^ > (I assume this is autocorrect picking the wrong thing to fix a typo and= > should be "IP Address") Yes. But no auto-correct feature was to blame in that case. >=20 >> using https, that the hostname verification for the https certificate >> implies that the stuns URI embedded in the document are receiving >> adequate protection and can be used without worrying about the lack of= >> certificate verification for the stuns URI. >> >> Now that is an assumption that we made, and we'd very much like to hea= r >> if that assumption is incorrect. >=20 > Note that I may be lacking full context, but based just on your descrip= tion > above and =C2=A7 8.1 of the -18, I am concerned about your statement "w= ithout > worrying about the lack of certificate verification for the stuns URI".= My > understanding is, that given a stuns URI with an IP address for the hos= t > and some domain name specified by the same mechanism that provided the = URI, > is that this domain name would then be used as input to the servername > verification process for the new connection using this stuns URI. Your= > statement that I quote here makes it sound like no certificate verifica= tion > is done on this second connection, which would seem to make it vulnerab= le > to a MITM attack (and thus be a bad idea). You are right. I am not sure if there is an easy way to fix that but if = someone figure that out it can be spelled out in a separate draft. Meanw= hile I updated the text in the new version of the draft as follow: "If the part of a "stun" URI contains an IP address, then this IP address is used directly to contact the server. A "stuns" URI containing an IP address MUST be rejected." >=20 > -Benjamin >=20 >> Section 6.2.3 is unrelated - it is about IP addresses provisioned loca= lly (not received from the server), and a matching certificate containing= IPAddress. I'll make that more explicit after I receive your response o= n the subject above. >> >> Also it seems that your DISCUSS is not related to that issue at all, w= ould it be possible to clear it? >> >> Thanks. >> >> On 06/18/2018 10:45 AM, Adam Roach wrote: >>> Gonzalo: >>> >>> TL;DR -- unless someone can find evidence indicating what the WG inte= nded, I believe we are waiting on you and Simon. >>> >>> I had two responses in my most recent message. I presume the first sh= ould be uncontroversial. >>> >>> The second point pertains to how the working group intended to treat = IP addresses in STUNS URIs. The document right now is ambiguous and self-= contradictory. If this has been discussed in the past, then the document = simply needs to be updated to reflect the outcome of that conversation. I= f not, then I believe the WG needs to have a conversation about what is i= ntended. >>> >>> As it stands, the document will lead to various notions about whether= (and how) IP addresses can be used, which will be an interop nightmare. >>> >>> /a >>> >>> On 6/18/18 05:41, Gonzalo Camarillo wrote: >>>> Marc, Adam, >>>> >>>> what is the status of this discussion? >>>> >>>> Thanks, >>>> >>>> Gonzalo >>>> >>>> On 21/05/2018 9:11 PM, Adam Roach wrote: >>>>> Sorry for taking so long to get back to you on this. Two responses = below >>>>> -- everything else looks good. >>>>> >>>>> On 5/3/18 6:37 PM, Marc Petit-Huguenin wrote: >>>>>> On 04/23/2018 03:37 PM, Marc Petit-Huguenin wrote: >>>>>>>> ----------------------------------------------------------------= ----------- >>>>>>>> >>>>>>>> >>>>>>>> =C2=A717.3.1: >>>>>>>> >>>>>>>>> =C2=A0=C2=A0 IANA is requested to update the names for attribut= es 0x0002, 0x0003, >>>>>>>>> =C2=A0=C2=A0 0x0004, 0x0005, 0x0007, and 0x000B, and the refere= nce from RFC 5389 >>>>>>>>> =C2=A0=C2=A0 to RFC-to-be for the following STUN methods: >>>>>>>> ... >>>>>>>>> =C2=A0=C2=A0 0x0003: (Reserved; prior to [RFC5389] this was CHA= NGE-REQUEST) >>>>>>>> The attribute 0x0003 is registered by RFC 5780, and should not b= e >>>>>>>> removed by this document. >>>>>>> Fixed. >>>>> >>>>> Thanks for the change, but the new text still asks IANA to update t= he >>>>> table so that 0x0003 points to *this* document, instead of continui= ng to >>>>> point to RFC 5780. Since this document does not do anything with >>>>> CHANGE-REQUEST, this update does not seem correct. >>>>> >>>>> >>>>>>>> ----------------------------------------------------------------= ----------- >>>>>>>> >>>>>>>> >>>>>>>> =C2=A76.2.3 says: >>>>>>>> >>>>>>>>> =C2=A0=C2=A0 Alternatively, a >>>>>>>>> =C2=A0=C2=A0 client MAY be configured with a set of IP addresse= s that are >>>>>>>>> trusted; >>>>>>>>> =C2=A0=C2=A0 if a certificate is received that identifies one o= f those IP >>>>>>>>> =C2=A0=C2=A0 addresses, the client considers the identity of th= e server to be >>>>>>>>> =C2=A0=C2=A0 verified. >>>>>>>> Presumably, this means the server supplies a certificate with >>>>>>>> SubjectAltName >>>>>>>> containing an iPAddress? Please add text to clarify whether that= 's the >>>>>>>> intention. >>>>>>>> >>>>>>>> If that *is* the intended meaning, then this behavior in =C2=A78= =2E1 seems >>>>>>>> unnecessarily restrictive: >>>>>>>> >>>>>>>>> =C2=A0=C2=A0 A "stuns" URI >>>>>>>>> =C2=A0=C2=A0 containing an IP address MUST be rejected, unless = the domain name is >>>>>>>>> =C2=A0=C2=A0 provided by the same mechanism that provided the S= TUN URI, and that >>>>>>>>> =C2=A0=C2=A0 domain name can be passed to the verification code= =2E >>>>>>>> Presumably, this is done because certs with iPAddress-form >>>>>>>> SubjectAltNames are >>>>>>>> pretty rare (although CAB Forum baseline requirements do explici= tly >>>>>>>> allow >>>>>>>> their issuance) -- but if the text in =C2=A76.2.3 is based on al= lowing >>>>>>>> the use of >>>>>>>> such certs in a TURN deployment, then it seems that URI resoluti= on >>>>>>>> should be >>>>>>>> also. >>>>>>>> >>>>>>> I am not sure what was the intent there, so I'll work on that lat= er. >>>>>> We addressed all the other comments, but it would be great if you >>>>>> could suggest some text to address that one. >>>>> I'm not sure what was meant either! >>>>> >>>>> I think we need to untangle what the working group meant to say >>>>> regarding "trusted IP addresses," the way this protocol is intended= to >>>>> use certs, and whether the prohibition on using IP addresses in "st= uns" >>>>> URIs derives from cert handling or if it has a completely different= >>>>> rationale behind it; and, if the former, ensure that those things t= hat >>>>> are prohibited or allowed in certs are similarly prohibited or allo= wed >>>>> in URIs. >>>>> >>>>> I can suggest some *behavior*, but unless there is some record of w= hat >>>>> the WG meant, any such behavior would need to be discussed by the >>>>> working group, and a consensus would need to be declared by the cha= irs. >>>>> >>>>> >>>>> /a >>>>> >>> >> --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --A7yGGfktMhaxQnoXo51QP8UOVAs2agfIN-- --YUbsRsAxd584CUGEYo73oJTHyKcYdFXZN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlu6AHoACgkQKcRFldZq fsRFaA//bHpa7SQboRNzZ1IWdCAmLrOhx7EbktY28wrY4gD05FqQr4KAGnTzN/d5 kTfBBDh92RCcxHzFuTx4ppBBMIrzXLKRZZiqHVAE+Qa+RWHYemSxrybw+2PX8nHf k+rNmjNka2GH3Gw+VBK220K4Atc87e+kVNY2lj8AAlPJ4QWQjAVfVsEqFki5IxCZ P2Ww5Y10uNUuEDLPgvXchMgG0cLCeaLEJnzGiBoadR0XAvk5RR175At/62WQzNT1 VqpMj5908LARxgmI1GqW3WobUNQACsS8fmyeDGZhDNMOMFCI0qbcgAFKG6atqedz jVm6GOfYmmsXywKgqJvMQl1JgSNfe8DMSEdFSZWTqyDV3wvtZs3D1gVi0w5idI9n ioS0/PeKVfHNovPuBM/N+2Olx807lGVHNTaxkS28v3QhZRJ9FTYquGovM2DigXS6 NoBwItonxjWEIADk1s0Citx7GeYYPzdlfF5m9E2kd2A8jjKSN774U8ZI6J8ccdeX gfdGmjWmB7sUOhWFnlqFA1C6HeDjDZpfLmdItfqurCMz6ypIjhG/LUjWLs/KdqH8 /kTj8br0YmKd5hrsZcrAnCWgyDTGaCN0OeC9ABNiRE6cXqJKJ2xqEJCGFMWAZ7dj ksISzuCKhFFVCg/XFNhvovtMqSohE8eNqHOcSKqvph4/i2Q3lcA= =N3NT -----END PGP SIGNATURE----- --YUbsRsAxd584CUGEYo73oJTHyKcYdFXZN-- From nobody Sun Oct 7 05:53:56 2018 Return-Path: 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 85785130E22; Sun, 7 Oct 2018 05:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 yZm6E2hCTyo5; Sun, 7 Oct 2018 05:53:53 -0700 (PDT) Received: from implementers.org (unknown [92.243.22.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98AA130E21; Sun, 7 Oct 2018 05:53:52 -0700 (PDT) Received: from [IPv6:2601:648:8400:8e7d:6571:21bd:7029:6ef2] (unknown [IPv6:2601:648:8400:8e7d:6571:21bd:7029:6ef2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id E2D87AE009; Sun, 7 Oct 2018 14:53:49 +0200 (CEST) To: Adam Roach , The IESG Cc: tram-chairs@ietf.org, Tolga Asveren , Gonzalo.Camarillo@ericsson.com, draft-ietf-tram-stunbis@ietf.org, tram@ietf.org References: <152403138853.31946.14807823535362928987.idtracker@ietfa.amsl.com> <27cb2f70-d907-b61f-bb5a-6b19053238fe@petit-huguenin.org> <1e8cd5de-06de-6745-fc4d-d15fcdd0b4d9@petit-huguenin.org> From: Marc Petit-Huguenin Openpgp: preference=signencrypt Autocrypt: addr=marc@petit-huguenin.org; prefer-encrypt=mutual; keydata= mQINBE6Mh9wBEADrUEDZChteJbQtsHwZITZExr7TAqT7pniNwhBX3nFgd+FrV3lsLKJ1rym2 52MAYpubXEJZGzMp6uCCAnROWbtmQbOm8z/jHnjxHhPqfuYCYPpAQqu8K/Sc194Rp37krMwB jz32yr7+gvWLzRgQGKIh9d2mzy8QLMETVWWQWGb6fEfpOxXo0wumN1rc/275kZwOu44JIPGg zbgwZdnEqYOUUa18K9MXeRDoWbwDISP30CvKuZDwD14lbBE3o7tBQrU9uoMhE7eFlTjbsCox qoubI2tZSuOTF8mRXjPmNrRGtf9mYkQnOB7y6qy/QxmOVMq4IRtHzOYIm/EZ6NTodcpZQHOM 2v6B6YK9uKrYrapSpJzn4f9oU7alT31Y3o2hOlxAWDQ16+Dd1MOPYsKQXOwY1/ihm4PTjiJ8 ud8yPzy7c+BSVs5wkBU6QuLNIgZHrrxdn+KxM+F/oAVtfzO7XzVoeOcXyWi3/CHL5pgoBruY enIF/RrRuplpy09pvZjmFPNfqKBYJGnqpQuqsQwO7LsFqDqfY2EuHg+KsGN1XuN+jxXc48/1 gCnKw7ALSPWEb7g25wD6KfiZTAcyRTG8LePNFQKhw61LbIWmkw9EaVLyXvwPTc1iCSc0dDT/ pcT/z+8xrWOyWGZNZAjR584NlDpKollbItcxYtFcYZkvTCmOVwARAQABtC1NYXJjIFBldGl0 LUh1Z3VlbmluIDxtYXJjQHBldGl0LWh1Z3VlbmluLm9yZz6JAjsEEwEIACUCGyMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheAAhkBBQJX8tdbAAoJECnERZXWan7EiNkQAIbS72cyalFjxQ1l vEW9S8NjjwIMbb5+NC2XqDakAmZq+Aav/Yfk8aEc+eAWBboVC3NBBjYojMRXK1XEnD7xPQ1X rWd23TDibKajy/2fo/MS9/s6uPFOAINi1ykOMq8ShxMHcIPC/dvVt59a7DV1KPGlnUheNR7N 4rIbkL5KndatD38yTGkyKsFvVKTHJn3y5zqHTGP0BjE1rxsGEBn4h+EzxVCIMVFQUeMVPKPV dlQY9fxdicSGPK2WKo1KL3CVpnYTuNCAVIGA9DPTXPPKvEte+/+xv10I03pj4w87iMUZt7Ca FTO55Gsf8hZvmpuB224yzrAbquA450EUVcQ7KAPcHrph5KAu0d3nwrjrUDn/RWWbyRiVrPtf hmnAAhkSv7oOxzyMdLvqt7XKGKbABhrl1ZRF8QbquOkyu8n3Bz2Osgw7JyFn9N6svlFPmpML UTEi64NewvN6zszKs/zBS6bn7na75gxHNvjSZpSF6uSLYgmKbyG8vkY/i0s0e0njjOHcpNx1 0mNZ+wOoCgHtSCZFyv14ncioJTiSjtZCs+srW9PFlbOg73C1Op42xV5Y+dh/mCC+rweKtB3t yTAy52v8vPG0VjsLS52x6yUsoDjYV33AmTEaWmGzN5t8BX/qh7pgNIEd9TEwrR3B4LjqMmUk XXWSJG5IM8Zr2OE/t2vyuQINBE6Mh9wBEAC/i4Lh4XEgwi/yHr3XLx/+f38ztn5rrk8XRsK2 WUpu5evxw9iK2oelqWtS71XkW57EavJOjvP4t8FWqRKED5jWN741n12iW/EeLx3KoHMcPTfY 4WWvprxiZPfnCIpQ8j8x0QQSA+Hf96BSkAkOGNkiJDuus5z4XwTktn9gFOwLVx4VRMo+lrCy um6BDHI+4/sOWnrNp2WptI4YKM/uA0HpuLpPKLra0ZW6Bp2TewNpAjbst/VHjqewab0PeSCn CQiHkqIibdgOATT0K6KoVtMxp/WPRSfVImfWCHjT2G7HFMcb6w/jlPSb+u4VtL9yn76CCg8F SqTtzFuqPtbXkhrdSgks/grxiQryMXwpO0uSuUgZ3u2TSs+65Bl2CM5cq+2aBIER5qhpnCv7 B00uHuoNqUEK0VEpLKcqi2ZeVM5oO8iOaBgS9Gh082HQ5JDijEV2J5e4rwXjbRnJ4hqpTjSy caW8HnPI+4S0aqVxbnqW7T6l/xnn7ivK3aPqaRKqUSedHCU3oHIU31n0o5+f5htQeDs/Tpzn ARHkyzu9vZ9CvQXk8daZorA+j/38q6mWU6Mw8FRIu1qPQDmqljobk3vC9BZRSJOn3P8jNMM7 w1j+7Da3rxGBylfa3fmHPyY7dvdyeLmsq7egzTJkpAMN55Qat7iuXeeCdBQLAFHLBP1tvwAR AQABiQIfBBgBCAAJAhsMBQJX8tdcAAoJECnERZXWan7EkMgP/isd3lrSsm/8t+U44LY0/x67 cPmiKa9biveywJZ9Y+Zu/pUP44dP670mY7PmEDGC6lRiPKGmhf7vqq6JJFOqX64VWePQ9QZp kkzAUmIJwQ2Kmcmfrs0J5w2Lf5qaNji25fQYbon0eUFy6eN3BNRSIcg0+OsH7HubTWfpZeJu B7V7k8OFt2+HDx7aNdNutDJIu4V25AzGfonARQzJK62cmB0pwYXpcyDO152OwP12XbpXxXA1 xHGYQBRL98pSbMU5xsMw8j9VQHQRS94aT9Qqnz9SrYuISnMV2WGyIE0rAY3GGz3IcN5LVE1N vSP51ih+YJg/qsBYs8obbfEIZelOuznWf120RgV7P+7ZWCSBohmchuyELQzl9D7FXfulkXA3 RapKQcGJMVPIHYgnlvmE0OXfJl1z09nYRQHitoQhWtviHWl7x/KL42aUzHirLR61iVA2kqkO BhU+u+g2w8qrZj+lJfXIxlbVyLOuBVqkfcK28AR9RriB4Q5hvbDeQJMgfZsV2hBt7huBOqkH nnbSCguqfnmwLGkxoM7RVjCQwvC1M57uwdKMlsTVaBP0RreZnrDngLamK+ibXYe7p8pPAWD9 cuHvkkjML7cIfuvbScDYRmGzia3V9+LVzQCm+q/6xUY1SZvrDz7OaJOy3Xb1d+aPhYaNC0TQ 7IqA1dx8rZYQ Message-ID: <7b2bc00f-49da-4d64-cdb3-01ddfeb69a00@petit-huguenin.org> Date: Sun, 7 Oct 2018 05:53:48 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EwNEbZ0vdpr5PTAdToeyrhfSaZosak3w9" Archived-At: Subject: Re: [tram] Adam Roach'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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 12:53:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EwNEbZ0vdpr5PTAdToeyrhfSaZosak3w9 Content-Type: multipart/mixed; boundary="KS1qdtBxcIg3Ayp85lz1ZlXvtryLz5WHz"; protected-headers="v1" From: Marc Petit-Huguenin To: Adam Roach , The IESG Cc: tram-chairs@ietf.org, Tolga Asveren , Gonzalo.Camarillo@ericsson.com, draft-ietf-tram-stunbis@ietf.org, tram@ietf.org Message-ID: <7b2bc00f-49da-4d64-cdb3-01ddfeb69a00@petit-huguenin.org> Subject: Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) References: <152403138853.31946.14807823535362928987.idtracker@ietfa.amsl.com> <27cb2f70-d907-b61f-bb5a-6b19053238fe@petit-huguenin.org> <1e8cd5de-06de-6745-fc4d-d15fcdd0b4d9@petit-huguenin.org> In-Reply-To: --KS1qdtBxcIg3Ayp85lz1ZlXvtryLz5WHz Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Adam, See one more response inline. Additionally it seems that your DISCUSS is not related to these issues at= all, would it be possible to clear it? Thanks. On 05/21/2018 11:11 AM, Adam Roach wrote: > Sorry for taking so long to get back to you on this. Two responses belo= w -- everything else looks good. >=20 > On 5/3/18 6:37 PM, Marc Petit-Huguenin wrote: >> On 04/23/2018 03:37 PM, Marc Petit-Huguenin wrote: >>> >>>> --------------------------------------------------------------------= ------- >>>> >>>> =C2=A717.3.1: >>>> >>>>> =C2=A0 IANA is requested to update the names for attributes 0x0002,= 0x0003, >>>>> =C2=A0 0x0004, 0x0005, 0x0007, and 0x000B, and the reference from R= FC 5389 >>>>> =C2=A0 to RFC-to-be for the following STUN methods: >>>> ... >>>>> =C2=A0 0x0003: (Reserved; prior to [RFC5389] this was CHANGE-REQUES= T) >>>> The attribute 0x0003 is registered by RFC 5780, and should not be re= moved by this document. >>> Fixed. >=20 >=20 > Thanks for the change, but the new text still asks IANA to update the t= able so that 0x0003 points to *this* document, instead of continuing to p= oint to RFC 5780. Since this document does not do anything with CHANGE-RE= QUEST, this update does not seem correct. >=20 >=20 >>>> --------------------------------------------------------------------= ------- >>>> >>>> =C2=A76.2.3 says: >>>> >>>>> =C2=A0 Alternatively, a >>>>> =C2=A0 client MAY be configured with a set of IP addresses that are= trusted; >>>>> =C2=A0 if a certificate is received that identifies one of those IP= >>>>> =C2=A0 addresses, the client considers the identity of the server t= o be >>>>> =C2=A0 verified. >>>> Presumably, this means the server supplies a certificate with Subjec= tAltName >>>> containing an iPAddress? Please add text to clarify whether that's t= he >>>> intention. >>>> >>>> If that *is* the intended meaning, then this behavior in =C2=A78.1 s= eems >>>> unnecessarily restrictive: To align with the modification done in section 8.1. (see my previous emai= l to Benjamin Kaduk), I completely removed the sentence from the next ver= sion of the draft. >>>> >>>>> =C2=A0 A "stuns" URI >>>>> =C2=A0 containing an IP address MUST be rejected, unless the domain= name is >>>>> =C2=A0 provided by the same mechanism that provided the STUN URI, a= nd that >>>>> =C2=A0 domain name can be passed to the verification code. >>>> Presumably, this is done because certs with iPAddress-form SubjectAl= tNames are >>>> pretty rare (although CAB Forum baseline requirements do explicitly = allow >>>> their issuance) -- but if the text in =C2=A76.2.3 is based on allowi= ng the use of >>>> such certs in a TURN deployment, then it seems that URI resolution s= hould be >>>> also. >>>> >>> I am not sure what was the intent there, so I'll work on that later. >> We addressed all the other comments, but it would be great if you coul= d suggest some text to address that one. >=20 > I'm not sure what was meant either! >=20 > I think we need to untangle what the working group meant to say regardi= ng "trusted IP addresses," the way this protocol is intended to use certs= , and whether the prohibition on using IP addresses in "stuns" URIs deriv= es from cert handling or if it has a completely different rationale behin= d it; and, if the former, ensure that those things that are prohibited or= allowed in certs are similarly prohibited or allowed in URIs. >=20 > I can suggest some *behavior*, but unless there is some record of what = the WG meant, any such behavior would need to be discussed by the working= group, and a consensus would need to be declared by the chairs. >=20 >=20 > /a >=20 --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --KS1qdtBxcIg3Ayp85lz1ZlXvtryLz5WHz-- --EwNEbZ0vdpr5PTAdToeyrhfSaZosak3w9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlu6AdwACgkQKcRFldZq fsRvNg/+NeRTlAXOVk7/isMt5ECcYKNmsQJpYObTAhlDBrcl/nCYX1LvWsB3syoZ 4wlKwJADGFA5MGpD5bwbcg769hsK1pBYe6139n0UBRpv3vXTmp8jKcrJ3Chw78Wt sXdGIfhgOk49MfK5wLdJZMAo36iwUWx5acWMBV8RUbJBGvX9QhHzNQxbAcPNFDQW /Qhj2cK1oc5XfHxHkhAyh0uscQAD2A+3nhWnGZqprCcMqY/6iRwQ15AKaOaUZT2m z+4ED0xpvl74SLPcQsHlL7/iVx7N1MAIIkvdqC4+FnYw+JBMM8Lchb4OfbO1A2oX Dg5O5+hw4TVv22v7VOhzP8fyOzk9GQ/+EnPoW0d8SVoZ3fPptdyVOc9E2hcmMGDs Mzs75DD+K+oN4Hq52UWTvvh/dQGoQlCEgqniU3ao02AeXeH2QjysztLRt5T4SQkk H1qvEQHQWn7x4alvjxi7k46kDiRI1N7Up4rOCIdiWJWKQ+r1PE8mBBwA1ZQKKpWo qAvRmjXXD9GtNcz9Yqh3E2cuzdmAW85w4zlRdVoybpE/X2O6P57y6V25m3kjCIBj 7n+ILxiQBJ1MLFJII/j5trhkwklZIb3tcaRtt55QtNk9/BXrC/CpMBQvuAKqzMS+ 6y3r7OdPoJIMfN/rxo/7/WD3jJ0Cg9xtgvOMZV/RXnES1t5Ev0E= =EE0H -----END PGP SIGNATURE----- --EwNEbZ0vdpr5PTAdToeyrhfSaZosak3w9-- From nobody Sun Oct 7 07:35:18 2018 Return-Path: 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 B1FFD130E22; Sun, 7 Oct 2018 07:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 FOJ1CiS24rb2; Sun, 7 Oct 2018 07:35:07 -0700 (PDT) Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D89130DE1; Sun, 7 Oct 2018 07:35:06 -0700 (PDT) Received: from [IPv6:2601:648:8400:8e7d:6571:21bd:7029:6ef2] (unknown [IPv6:2601:648:8400:8e7d:6571:21bd:7029:6ef2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 01803AE009; Sun, 7 Oct 2018 16:35:02 +0200 (CEST) To: Eric Rescorla Cc: tram-chairs@ietf.org, tram@ietf.org, Gonzalo Camarillo , tasveren@rbbn.com, The IESG , draft-ietf-tram-stunbis@ietf.org References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <02569943-db8f-654e-7322-49bc1f1a1163@acm.org> <235b838f-2800-2cd0-8b01-947e70837619@ericsson.com> From: Marc Petit-Huguenin Openpgp: preference=signencrypt Autocrypt: addr=petithug@acm.org; prefer-encrypt=mutual; keydata= mQINBE6Mh9wBEADrUEDZChteJbQtsHwZITZExr7TAqT7pniNwhBX3nFgd+FrV3lsLKJ1rym2 52MAYpubXEJZGzMp6uCCAnROWbtmQbOm8z/jHnjxHhPqfuYCYPpAQqu8K/Sc194Rp37krMwB jz32yr7+gvWLzRgQGKIh9d2mzy8QLMETVWWQWGb6fEfpOxXo0wumN1rc/275kZwOu44JIPGg zbgwZdnEqYOUUa18K9MXeRDoWbwDISP30CvKuZDwD14lbBE3o7tBQrU9uoMhE7eFlTjbsCox qoubI2tZSuOTF8mRXjPmNrRGtf9mYkQnOB7y6qy/QxmOVMq4IRtHzOYIm/EZ6NTodcpZQHOM 2v6B6YK9uKrYrapSpJzn4f9oU7alT31Y3o2hOlxAWDQ16+Dd1MOPYsKQXOwY1/ihm4PTjiJ8 ud8yPzy7c+BSVs5wkBU6QuLNIgZHrrxdn+KxM+F/oAVtfzO7XzVoeOcXyWi3/CHL5pgoBruY enIF/RrRuplpy09pvZjmFPNfqKBYJGnqpQuqsQwO7LsFqDqfY2EuHg+KsGN1XuN+jxXc48/1 gCnKw7ALSPWEb7g25wD6KfiZTAcyRTG8LePNFQKhw61LbIWmkw9EaVLyXvwPTc1iCSc0dDT/ pcT/z+8xrWOyWGZNZAjR584NlDpKollbItcxYtFcYZkvTCmOVwARAQABtCZNYXJjIFBldGl0 LUh1Z3VlbmluIDxwZXRpdGh1Z0BhY20ub3JnPokCOAQTAQgAIgIbIwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AFAlfy11wACgkQKcRFldZqfsRWqBAAu/61DGo+j38UefTKnEse0mftPBXa S4lre7vknn33MI0L5QXmiM8zRs9FOKSuXPx0EV+JhI4pWZGW/2MJPuyifXHvnIChcdGInN8J GBdTLZSOgdDFZL9msO+QUsvMA8ZUsqlKOEcVL1NyoLupblCWNq4fYhBCx1zDwX9LZSuGn8lZ Mk8a4QFGoR6dWKaOxeCwnoquW5IK1CfRIhYjHfQMjA5gY0H46F0iCqBaFF/S7krQwIJd0XN4 YbSL4KOrWuxtgQ+iH/iaxxBXgJ1blBNRzXaWJBF4PHv23nSnEzWO17j+uVMaHJu7ycYEf8T9 pVc0xcok1BM2rCrNE5FUFAzsUtAtBZEEK6sSIeOhRG93uD/Hv1hrWzEwf+Z7B1tVQLCQQ4kL 7wyS7SXI/JTuW2xTEGCmwMeWYGERdkgsatmx4zi5nVHDjt3/mlPMj4L+u05SkI2iV4W6xxU1 jHlBIJDs7AVM0dsxzTyIPf2Sz843WyHuBgkoCskxGfOwlkZzDX9rwcWRKal1wjy1w/25LsBY U50INandw3UbrS2I73VX8ARI8uOWZrW7uzRLf8EmuPhtSQ35ThmdoNSgGMP9EXwNgzi/i+5G hbX5KbrSLG9SITFJEcJA4tnwu3nqmBh7D7vbd5ln5X7rmqPdyjidt0zcSjvuaBA+nkmakA4A O+choWy5Ag0EToyH3AEQAL+LguHhcSDCL/IevdcvH/5/fzO2fmuuTxdGwrZZSm7l6/HD2Ira h6Wpa1LvVeRbnsRq8k6O8/i3wVapEoQPmNY3vjWfXaJb8R4vHcqgcxw9N9jhZa+mvGJk9+cI ilDyPzHRBBID4d/3oFKQCQ4Y2SIkO66znPhfBOS2f2AU7AtXHhVEyj6WsLK6boEMcj7j+w5a es2nZam0jhgoz+4DQem4uk8outrRlboGnZN7A2kCNuy39UeOp7BpvQ95IKcJCIeSoiJt2A4B NPQroqhW0zGn9Y9FJ9UiZ9YIeNPYbscUxxvrD+OU9Jv67hW0v3KfvoIKDwVKpO3MW6o+1teS Gt1KCSz+CvGJCvIxfCk7S5K5SBne7ZNKz7rkGXYIzlyr7ZoEgRHmqGmcK/sHTS4e6g2pQQrR USkspyqLZl5Uzmg7yI5oGBL0aHTzYdDkkOKMRXYnl7ivBeNtGcniGqlONLJxpbwec8j7hLRq pXFuepbtPqX/GefuK8rdo+ppEqpRJ50cJTegchTfWfSjn5/mG1B4Oz9OnOcBEeTLO729n0K9 BeTx1pmisD6P/fyrqZZTozDwVEi7Wo9AOaqWOhuTe8L0FlFIk6fc/yM0wzvDWP7sNrevEYHK V9rd+Yc/Jjt293J4uayrt6DNMmSkAw3nlBq3uK5d54J0FAsAUcsE/W2/ABEBAAGJAh8EGAEI AAkCGwwFAlfy11wACgkQKcRFldZqfsSQyA/+Kx3eWtKyb/y35TjgtjT/Hrtw+aIpr1uK97LA ln1j5m7+lQ/jh0/rvSZjs+YQMYLqVGI8oaaF/u+qrokkU6pfrhVZ49D1BmmSTMBSYgnBDYqZ yZ+uzQnnDYt/mpo2OLbl9BhuifR5QXLp43cE1FIhyDT46wfse5tNZ+ll4m4HtXuTw4W3b4cP Hto10260Mki7hXbkDMZ+icBFDMkrrZyYHSnBhelzIM7XnY7A/XZdulfFcDXEcZhAFEv3ylJs xTnGwzDyP1VAdBFL3hpP1CqfP1Kti4hKcxXZYbIgTSsBjcYbPchw3ktUTU29I/nWKH5gmD+q wFizyhtt8Qhl6U67OdZ/XbRGBXs/7tlYJIGiGZyG7IQtDOX0PsVd+6WRcDdFqkpBwYkxU8gd iCeW+YTQ5d8mXXPT2dhFAeK2hCFa2+IdaXvH8ovjZpTMeKstHrWJUDaSqQ4GFT676DbDyqtm P6Ul9cjGVtXIs64FWqR9wrbwBH1GuIHhDmG9sN5AkyB9mxXaEG3uG4E6qQeedtIKC6p+ebAs aTGgztFWMJDC8LUznu7B0oyWxNVoE/RGt5mesOeAtqYr6Jtdh7unyk8BYP1y4e+SSMwvtwh+ 69tJwNhGYbOJrdX34tXNAKb6r/rFRjVJm+sPPs5ok7LddvV35o+Fho0LRNDsioDV3HytlhA= Message-ID: Date: Sun, 7 Oct 2018 07:34:56 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="o8tY0mSmyIkfENNNxhUWm5GP4Kcp9MsXh" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 14:35:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --o8tY0mSmyIkfENNNxhUWm5GP4Kcp9MsXh Content-Type: multipart/mixed; boundary="v8iyQ42nnuAngIoxsUPTvCMKIkyLaHskq"; protected-headers="v1" From: Marc Petit-Huguenin To: Eric Rescorla Cc: tram-chairs@ietf.org, tram@ietf.org, Gonzalo Camarillo , tasveren@rbbn.com, The IESG , draft-ietf-tram-stunbis@ietf.org Message-ID: Subject: Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <02569943-db8f-654e-7322-49bc1f1a1163@acm.org> <235b838f-2800-2cd0-8b01-947e70837619@ericsson.com> In-Reply-To: --v8iyQ42nnuAngIoxsUPTvCMKIkyLaHskq Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable 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 > wrote: >=20 >> 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= : >> >=20 > 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 enc= ryption mechanisms were denied. It is true that Argon2 was not in that l= ist (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 i= s too late to fix this, as it is my understanding that the WG does not ha= ve 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. >=20 >=20 >> - 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 compatibi= lity >> 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... >> >=20 > 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 p= rotection, 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 ca= nnot 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 dec= ide how long the migration to STUNbis will take and when it will be accep= table 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 responsibilit= y of the owner of the server). Meanwhile we still need to be sure that if the STUN client is implementin= g STUNbis it unconditionally gets the additional protection of the new pa= ssword encryption algorithm. That's where the biddown protection kicks i= n, by preventing an online attacker to have the server misidentifying a S= TUNbis 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 e= ncrypted password, all of that easily done by stripping the unprotected 4= 01 response of the new STUNbis PASSWORD-ALGORITHMS attribute. >=20 >=20 >=20 >>> 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 weaknes= s >>> (e.g., >>> version #), but I don't really see how the current design helps again= st >>> attacks on the >>> MAC. >> >> There is no biddown attack protection for the MAC, as stated in Sectio= n >> 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. >> >=20 > 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. >=20 > If you think this does something useful, please show me an example atta= ck > 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.=20 I do not know what weaknesses will be discovered in the future. I am als= o 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 pro= tection mechanism if we ever need it will be high. We already went throu= gh the pains of designing one for the password algorithm, so why not exte= nd it so it can be used in the aftermath of the next Snowden facepalm mom= ent? > Again, happy to have a call to walk though this if that > helps. >=20 > -Ekr >=20 >=20 >=20 >=20 >>> >>> You might think that there was a MAC which was easier to reverse to f= ind >>> the original >>> password, but the defense you have here doesn't help with that becaus= e >> 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 ha= ve a >>> call if you >>> think that helps >>> >>> -Ekr >>> >>> >>> >>> >>> On Mon, Jun 18, 2018 at 3:40 AM, Gonzalo Camarillo < >>> 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 >>>>> > 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 > >>>>> > wrote: >>>>> > >>>>> >> >>>>> >>>> For a request or indication message, the agent MUST >>>> include the >>>>> >>>> USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEG= RITY >>>>> >> attributes >>>>> >>>> in the message unless the agent knows from an externa= l >>>> indication >>>>> >>>> which message integrity algorithm is supported by bot= h >>>> agents. In >>>>> >>>> this case either MESSAGE-INTEGRITY or >>>> MESSAGE-INTEGRITY-SHA256 MUST >>>>> >>>> be included in addition to USERNAME. The HMAC for th= e >>>> 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 th= e >>>> same time >>>>> > which >>>>> > make contrary recommendations about the same basic protocol i= s >>>> un-good. >>>>> >>>>> Sure, but wouldn't it be simpler to have rfc5245bis using stunb= is >>>>> and have them updating their text, more than adding some tortuo= us >>>>> text in stunbis? >>>>> >>>>> > >>>>> > >>>>> >>> The STUN usage must specify which transport protocol i= s >>>> 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 usag= es >>>> where >>>>> >>>> authentication is not used. >>>>> >>> >>>>> >>> Why this restriction? You should be able to use anycast wit= h >>>> long-term >>>>> >>> AUTH for (say) TURN. >>>>> >> >>>>> >> https://www.ietf.org/mail-archive/web/behave/current/ >>>> msg03582.html >>>>> > msg03582.html> >>>>> >> >>>>> >> I think that the decision of permitting Anycast should be le= ft >> to >>>> each >>>>> >> STUN Usage. Basic STUN Usage does not use authentication an= d >> use >>>> only a >>>>> >> one round trip for the Binding transaction, so Unicast can b= e >>>> 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 cas= e >> 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 bef= ore >>>>> the bullet points: >>>>> >>>>> A STUN usage defines how STUN is actually utilized -- when t= o >> 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 T= CP >> 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 conside= red >>>> failed if >>>>> >>>> there has been a hard ICMP error [RFC1122]. For exam= ple, >>>> assuming >>>>> >> an >>>>> >>>> RTO of 500ms, requests would be sent at times 0 ms, 5= 00 >>>> ms, 1500 >>>>> >> ms, >>>>> >>>> 3500 ms, 7500 ms, 15500 ms, and 31500 ms. If the cli= ent >>>> 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 i= n >> RFC >>>> 5389. >>>>> >> >>>>> > >>>>> > Yes, I know. My point is that while they might have bee sensi= ble >>>> 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 th= is >>>>> 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 specificat= ion >>>> and >>>>> so can process the ALTERNATE-DOMAIN attribute. >>>>> >>>>> >>>>> All right. >>>>> >>>>> >>>>> > >>>>> > >>>>> >>>> o What authentication and message-integrity mechanis= ms >>>> are used. >>>>> >>>> >>>>> >>>> o The considerations around manual vs. automatic key= >>>> derivation >>>>> >> for >>>>> >>>> the integrity mechanism, as discussed in [RFC4107]= =2E >>>>> >>>> >>>>> >>>> o What mechanisms are used to distinguish STUN messa= ges >>>> 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/79= 83 >> is >>>> one such >>>>> >> mechanism, but there is nothing that prevent another protoco= l >>>> 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 attack= er >>>> that >>>>> >> would strip the MESSAGE-INTEGRITY-SHA256 attribute leavin= g >>>>> 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-INTEGR= ITY >>>> 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 w= hat >>>>> 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 a= nd >>>>> 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 th= e >>>>> 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 >>>>> >>>>> >>>>> -- --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --v8iyQ42nnuAngIoxsUPTvCMKIkyLaHskq-- --o8tY0mSmyIkfENNNxhUWm5GP4Kcp9MsXh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlu6GZAACgkQKcRFldZq fsRj/RAApaIC/2/bQfCeA56wgKD61dy3R7fdyxZ7slFBaGUKnqZrLYw1PIKQ8ROD VxF/Vbyz7Aa/wynVjHNbTW4LUNczOvoQznbCM9oO1aLgi5CxsWmR6SLd8cuWb4Gb RY3wCY21iSQ4jcK4bAmp2DqmcMOP/WtesoF1ZaP5PIb0lbozqu7Td92+Bg+5zxa8 N5cqtYjxvAFW6YYmCVD42MU8Owelxg1xnIdzyByk3zI73mAbqlBd2sfMNyGSCTdu dmnR+CuR14ttlvtB1R9yXPOgQ/A24owO94r3ofAEP/NNLmzoyMe+UpRI6pmEyTwF A9uKsKORQmbMsBrQvAm3QG+X1cFanevacqkhYSLWpdSfrvnPtK4idKvMifVmo6S3 vIONAg93FePfxD7BdC9mNPpIHbGyLjFpXd2iNDbxLPxITamFaKr+xqjv9y1xxrxq j7Z+DwPcVD6IU0UNMErerjfmsMSxeQw+y03KNGyBaTiEVVb0SePDuXATeOBOA0iP MxpwVzYdcGb4OY7GQcQInrqYhVcYVZTibIOQ/tvwm8WuWkzTaDAjxcvsd0qmaYet mbCHB4/ECJrxyQkR7HaaGbnG6/wdKLEo3QnKMdpO4TE+GjcIxN3/Ep82+U6Nf6Th GkClAry7GI/uzSTGgMEahvqLNfGYVltQRax8blKxDlyMaSorjag= =lGAP -----END PGP SIGNATURE----- --o8tY0mSmyIkfENNNxhUWm5GP4Kcp9MsXh-- From nobody Sun Oct 7 08:05:55 2018 Return-Path: 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 64AFD130E07; Sun, 7 Oct 2018 08:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbyIhF0sXOrd; Sun, 7 Oct 2018 08:05:50 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 C844F124BE5; Sun, 7 Oct 2018 08:05:49 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id v18-v6so10034278vsl.11; Sun, 07 Oct 2018 08:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+NB5S96RBzORSKszq/CID0DapxuJDeC6WpeuENIadVU=; b=s7YkbxaUvw7CjSZWmXq4yGyhPrwF0/Dwucyz1Mv1POVx8RDPD+LOkVipd2d6/UMXCY hvpmJ+6X5h0nKRXv7VIUPqPreXBPZrhvYIvo3a0nKU8gGN2yTc+26tsk+G9QlfsaGSQC 7QlCGjlK+YuRIkU1n7i03hoG7dLgTMPeE2Z6Cxr/qGqukxKb9rpqY7oRFIIXVU6DOGCq tnzyrNhQLXVSm3jlmgPNKdFMHZ7GIRGfvIOmu9sSCcpiwbBQtGh12xtV/IDi7d+Ya6xo dgmv4Q+0KT39OMK2cSMC3CBGk9ZT6wz8zGsMZ/KRqlfL4mHG3Kz0BFQWMhMz7inAPUT6 U5TQ== 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=+NB5S96RBzORSKszq/CID0DapxuJDeC6WpeuENIadVU=; b=ot7WKQedcgQKqOOXyM/oxXUI53s8cW4RVwh56z20AXgd2xVG5tWbyUhjCEYmwt+gTB CHut37ak0gUxLgJr9IiMO9dS2Pt84VC/xJxwB6FByoNC5HTJSLcgHFyuSP4FY2aV9ogf 8RWFQoX/r0EpV7UdkfPommIAJSErlJeIgpinM5M6HMQPR1PcS9J3OR/aAwZDZl2bPxWY XKQYtyjM41GniC5rcepOIzVy69oMj1FROtUbjA+CkMi4GMXkz6ju8sRoF1d9yqzNQreX Byrl9FcNCzt4+Sm6yp6EPFiowUgRyW4v/QffrlCyXn8kW1guCuqXNWwNsfjsDQKAZjr8 RMQg== X-Gm-Message-State: ABuFfohj7jYpH+46v/a/4SbaBlsis8o2ocKgkymXDSywenstfBpDKJKo v0StG2o+1vjqBovXqmZMu3Nl0n+xvJlJhYksTBE= X-Google-Smtp-Source: ACcGV60C5DFBYX0MG5GYsytJ/7VJhXimsDbD+MCv5Xt5+6ikhfHJybmZmKBmrnyTO8uW7Mi75AB4B8kEEa+jd24UQ6U= X-Received: by 2002:a67:47d8:: with SMTP id b85mr7228539vsg.184.1538924748606; Sun, 07 Oct 2018 08:05:48 -0700 (PDT) MIME-Version: 1.0 References: <152403138853.31946.14807823535362928987.idtracker@ietfa.amsl.com> <27cb2f70-d907-b61f-bb5a-6b19053238fe@petit-huguenin.org> <1e8cd5de-06de-6745-fc4d-d15fcdd0b4d9@petit-huguenin.org> <5ff10fb0-301e-5d97-01b0-f15296bae0d3@nostrum.com> <20180909014711.GT73164@kduck.kaduk.org> <49512499-0e71-1f5b-e12c-213a3dd88d91@petit-huguenin.org> In-Reply-To: <49512499-0e71-1f5b-e12c-213a3dd88d91@petit-huguenin.org> From: Rohan Mahy Date: Sun, 7 Oct 2018 08:05:36 -0700 Message-ID: To: Marc Petit-Huguenin Cc: Benjamin Kaduk , Adam Roach , Gonzalo Camarillo , The IESG , tram-chairs@ietf.org, draft-ietf-tram-stunbis@ietf.org, Tolga Asveren , tram@ietf.org Content-Type: multipart/alternative; boundary="000000000000fa11ba0577a4d603" Archived-At: Subject: Re: [tram] Adam Roach'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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 15:05:53 -0000 --000000000000fa11ba0577a4d603 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [snip] >> using https, that the hostname verification for the https certificate >> implies that the stuns URI embedded in the document are receiving >> adequate protection and can be used without worrying about the lack of >> certificate verification for the stuns URI. >> >> Now that is an assumption that we made, and we'd very much like to hear >> if that assumption is incorrect. > > Note that I may be lacking full context, but based just on your description > above and =C2=A7 8.1 of the -18, I am concerned about your statement "wit= hout > worrying about the lack of certificate verification for the stuns URI". My > understanding is, that given a stuns URI with an IP address for the host > and some domain name specified by the same mechanism that provided the URI, > is that this domain name would then be used as input to the servername > verification process for the new connection using this stuns URI. Your > statement that I quote here makes it sound like no certificate verification > is done on this second connection, which would seem to make it vulnerable > to a MITM attack (and thus be a bad idea). Probably too late now, but if you wanted to be able use a stuns: URI safely with an IP address, you could use a fingerprint URI parameter to prevent MITM. This would work as long as you received the URI over an authenticated channel (ex: https:, sip: + S/MIME, and possibly sips:). Thanks, -rohan On Sun, Oct 7, 2018 at 5:48 AM Marc Petit-Huguenin wrote: > Hi Benjamin, > > See inline. > > On 09/08/2018 06:52 PM, Benjamin Kaduk wrote: > > Hi Marc, > > > > On Sat, Sep 08, 2018 at 02:59:41PM -0700, Marc Petit-Huguenin wrote: > >> Hi Adam, > >> > >> Apologies for the delay in working on that. > >> > >> For the first issue, the fix is in my copy of the draft. > >> > >> As for the second issue, Section 8.1 says: > >> > >> 'A "stuns" URI > >> containing an IP address MUST be rejected, unless the domain name is > >> provided by the same mechanism that provided the STUN URI, and that > >> domain name can be passed to the verification code.' > >> > >> That text was never about IP addresses in certificates, but about the > way a STUN (or TURN really, but that draft does not care about TURN) serv= er > IP address is passed to a WebRTC browser. RFC 7064 permits to store an I= P > address directly inside a stun URI, and RFC 7350 extended that to stuns > URI, and in fact the text above is directly copied from RFC 7350. > >> > >> The idea is that a stun URI can be provisioned by a JavaScript program > >> downloaded by a WebRTC browser as part of the initialization of a WebR= TC > >> application. A security assumption is that using a stuns URI that > >> contains an API address is safe if the Javascript program was download= ed > > ^^^ > > (I assume this is autocorrect picking the wrong thing to fix a typo and > > should be "IP Address") > > Yes. But no auto-correct feature was to blame in that case. > > > > >> using https, that the hostname verification for the https certificate > >> implies that the stuns URI embedded in the document are receiving > >> adequate protection and can be used without worrying about the lack of > >> certificate verification for the stuns URI. > >> > >> Now that is an assumption that we made, and we'd very much like to hea= r > >> if that assumption is incorrect. > > > > Note that I may be lacking full context, but based just on your > description > > above and =C2=A7 8.1 of the -18, I am concerned about your statement "w= ithout > > worrying about the lack of certificate verification for the stuns URI". > My > > understanding is, that given a stuns URI with an IP address for the hos= t > > and some domain name specified by the same mechanism that provided the > URI, > > is that this domain name would then be used as input to the servername > > verification process for the new connection using this stuns URI. Your > > statement that I quote here makes it sound like no certificate > verification > > is done on this second connection, which would seem to make it vulnerab= le > > to a MITM attack (and thus be a bad idea). > > You are right. I am not sure if there is an easy way to fix that but if > someone figure that out it can be spelled out in a separate draft. > Meanwhile I updated the text in the new version of the draft as follow: > > "If the part of a "stun" URI contains an IP address, then this > IP address is used directly to contact the server. A "stuns" URI > containing an IP address MUST be rejected." > > > > > -Benjamin > > > >> Section 6.2.3 is unrelated - it is about IP addresses provisioned > locally (not received from the server), and a matching certificate > containing IPAddress. I'll make that more explicit after I receive your > response on the subject above. > >> > >> Also it seems that your DISCUSS is not related to that issue at all, > would it be possible to clear it? > >> > >> Thanks. > >> > >> On 06/18/2018 10:45 AM, Adam Roach wrote: > >>> Gonzalo: > >>> > >>> TL;DR -- unless someone can find evidence indicating what the WG > intended, I believe we are waiting on you and Simon. > >>> > >>> I had two responses in my most recent message. I presume the first > should be uncontroversial. > >>> > >>> The second point pertains to how the working group intended to treat > IP addresses in STUNS URIs. The document right now is ambiguous and > self-contradictory. If this has been discussed in the past, then the > document simply needs to be updated to reflect the outcome of that > conversation. If not, then I believe the WG needs to have a conversation > about what is intended. > >>> > >>> As it stands, the document will lead to various notions about whether > (and how) IP addresses can be used, which will be an interop nightmare. > >>> > >>> /a > >>> > >>> On 6/18/18 05:41, Gonzalo Camarillo wrote: > >>>> Marc, Adam, > >>>> > >>>> what is the status of this discussion? > >>>> > >>>> Thanks, > >>>> > >>>> Gonzalo > >>>> > >>>> On 21/05/2018 9:11 PM, Adam Roach wrote: > >>>>> Sorry for taking so long to get back to you on this. Two responses > below > >>>>> -- everything else looks good. > >>>>> > >>>>> On 5/3/18 6:37 PM, Marc Petit-Huguenin wrote: > >>>>>> On 04/23/2018 03:37 PM, Marc Petit-Huguenin wrote: > >>>>>>>> > -------------------------------------------------------------------------= -- > >>>>>>>> > >>>>>>>> > >>>>>>>> =C2=A717.3.1: > >>>>>>>> > >>>>>>>>> IANA is requested to update the names for attributes 0x0002, > 0x0003, > >>>>>>>>> 0x0004, 0x0005, 0x0007, and 0x000B, and the reference from > RFC 5389 > >>>>>>>>> to RFC-to-be for the following STUN methods: > >>>>>>>> ... > >>>>>>>>> 0x0003: (Reserved; prior to [RFC5389] this was CHANGE-REQUES= T) > >>>>>>>> The attribute 0x0003 is registered by RFC 5780, and should not b= e > >>>>>>>> removed by this document. > >>>>>>> Fixed. > >>>>> > >>>>> Thanks for the change, but the new text still asks IANA to update t= he > >>>>> table so that 0x0003 points to *this* document, instead of > continuing to > >>>>> point to RFC 5780. Since this document does not do anything with > >>>>> CHANGE-REQUEST, this update does not seem correct. > >>>>> > >>>>> > >>>>>>>> > -------------------------------------------------------------------------= -- > >>>>>>>> > >>>>>>>> > >>>>>>>> =C2=A76.2.3 says: > >>>>>>>> > >>>>>>>>> Alternatively, a > >>>>>>>>> client MAY be configured with a set of IP addresses that are > >>>>>>>>> trusted; > >>>>>>>>> if a certificate is received that identifies one of those IP > >>>>>>>>> addresses, the client considers the identity of the server t= o > be > >>>>>>>>> verified. > >>>>>>>> Presumably, this means the server supplies a certificate with > >>>>>>>> SubjectAltName > >>>>>>>> containing an iPAddress? Please add text to clarify whether > that's the > >>>>>>>> intention. > >>>>>>>> > >>>>>>>> If that *is* the intended meaning, then this behavior in =C2=A78= .1 > seems > >>>>>>>> unnecessarily restrictive: > >>>>>>>> > >>>>>>>>> A "stuns" URI > >>>>>>>>> containing an IP address MUST be rejected, unless the domain > name is > >>>>>>>>> provided by the same mechanism that provided the STUN URI, > and that > >>>>>>>>> domain name can be passed to the verification code. > >>>>>>>> Presumably, this is done because certs with iPAddress-form > >>>>>>>> SubjectAltNames are > >>>>>>>> pretty rare (although CAB Forum baseline requirements do > explicitly > >>>>>>>> allow > >>>>>>>> their issuance) -- but if the text in =C2=A76.2.3 is based on al= lowing > >>>>>>>> the use of > >>>>>>>> such certs in a TURN deployment, then it seems that URI resoluti= on > >>>>>>>> should be > >>>>>>>> also. > >>>>>>>> > >>>>>>> I am not sure what was the intent there, so I'll work on that > later. > >>>>>> We addressed all the other comments, but it would be great if you > >>>>>> could suggest some text to address that one. > >>>>> I'm not sure what was meant either! > >>>>> > >>>>> I think we need to untangle what the working group meant to say > >>>>> regarding "trusted IP addresses," the way this protocol is intended > to > >>>>> use certs, and whether the prohibition on using IP addresses in > "stuns" > >>>>> URIs derives from cert handling or if it has a completely different > >>>>> rationale behind it; and, if the former, ensure that those things > that > >>>>> are prohibited or allowed in certs are similarly prohibited or > allowed > >>>>> in URIs. > >>>>> > >>>>> I can suggest some *behavior*, but unless there is some record of > what > >>>>> the WG meant, any such behavior would need to be discussed by the > >>>>> working group, and a consensus would need to be declared by the > chairs. > >>>>> > >>>>> > >>>>> /a > >>>>> > >>> > >> > > > -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: https://marc.petit-huguenin.org > Profile: https://www.linkedin.com/in/petithug > > --000000000000fa11ba0577a4d603 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

[snip]
>= ;> using https, that the hostname verification for the https certificate=
>> implies that the stuns URI embedded in the document are receiving<= br> >> adequate protection and can be used without worrying about the lac= k of
>> certificate verification for the stuns URI.
>>
>> Now that is an assumption that we made, and we'd very much lik= e to hear
>> if that assumption is incorrect.
>
> Note that I may be lacking full context, but based just on your descri= ption
> above and =C2=A7 8.1 of the -18, I am concerned about your statement &= quot;without
> worrying about the lack of certificate verification for the stuns URI&= quot;.=C2=A0 My
> understanding is, that given a stuns URI with an IP address for the ho= st
> and some domain name specified by the same mechanism that provided the= URI,
> is that this domain name would then be used as input to the servername=
> verification process for the new connection using this stuns URI.=C2= =A0 Your
> statement that I quote here makes it sound like no certificate verific= ation
> is done on this second connection, which would seem to make it vulnera= ble
> to a MITM attack (and thus be a bad idea).

Probably too = late now, but if you wanted to be able use a stuns: URI safely with an IP a= ddress, you could use a fingerprint URI parameter to prevent MITM. This wou= ld work as long as you received the URI over an authenticated channel (ex: = https:, sip: + S/MIME, and possibly sips:).
Thanks,
-rohan

On Sun, Oct = 7, 2018 at 5:48 AM Marc Petit-Huguenin <marc@petit-huguenin.org> wrote:
Hi Benjamin,

See inline.

On 09/08/2018 06:52 PM, Benjamin Kaduk wrote:
> Hi Marc,
>
> On Sat, Sep 08, 2018 at 02:59:41PM -0700, Marc Petit-Huguenin wrote: >> Hi Adam,
>>
>> Apologies for the delay in working on that.
>>
>> For the first issue, the fix is in my copy of the draft.
>>
>> As for the second issue, Section 8.1 says:
>>
>> 'A "stuns" URI
>>=C2=A0 containing an IP address MUST be rejected, unless the domain= name is
>>=C2=A0 provided by the same mechanism that provided the STUN URI, a= nd that
>>=C2=A0 domain name can be passed to the verification code.'
>>
>> That text was never about IP addresses in certificates, but about = the way a STUN (or TURN really, but that draft does not care about TURN) se= rver IP address is passed to a WebRTC browser.=C2=A0 RFC 7064 permits to st= ore an IP address directly inside a stun URI, and RFC 7350 extended that to= stuns URI, and in fact the text above is directly copied from RFC 7350. >>
>> The idea is that a stun URI can be provisioned by a JavaScript pro= gram
>> downloaded by a WebRTC browser as part of the initialization of a = WebRTC
>> application.=C2=A0 A security assumption is that using a stuns URI= that
>> contains an API address is safe if the Javascript program was down= loaded
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^
> (I assume this is autocorrect picking the wrong thing to fix a typo an= d
> should be "IP Address")

Yes.=C2=A0 But no auto-correct feature was to blame in that case.

>
>> using https, that the hostname verification for the https certific= ate
>> implies that the stuns URI embedded in the document are receiving<= br> >> adequate protection and can be used without worrying about the lac= k of
>> certificate verification for the stuns URI.
>>
>> Now that is an assumption that we made, and we'd very much lik= e to hear
>> if that assumption is incorrect.
>
> Note that I may be lacking full context, but based just on your descri= ption
> above and =C2=A7 8.1 of the -18, I am concerned about your statement &= quot;without
> worrying about the lack of certificate verification for the stuns URI&= quot;.=C2=A0 My
> understanding is, that given a stuns URI with an IP address for the ho= st
> and some domain name specified by the same mechanism that provided the= URI,
> is that this domain name would then be used as input to the servername=
> verification process for the new connection using this stuns URI.=C2= =A0 Your
> statement that I quote here makes it sound like no certificate verific= ation
> is done on this second connection, which would seem to make it vulnera= ble
> to a MITM attack (and thus be a bad idea).

You are right.=C2=A0 I am not sure if there is an easy way to fix that but = if someone figure that out it can be spelled out in a separate draft.=C2=A0= Meanwhile I updated the text in the new version of the draft as follow:
"If the <host> part of a "stun" URI contains an IP add= ress, then this
=C2=A0IP address is used directly to contact the server.=C2=A0 A "stun= s" URI
=C2=A0containing an IP address MUST be rejected."

>
> -Benjamin
>
>> Section 6.2.3 is unrelated - it is about IP addresses provisioned = locally (not received from the server), and a matching certificate containi= ng IPAddress.=C2=A0 I'll make that more explicit after I receive your r= esponse on the subject above.
>>
>> Also it seems that your DISCUSS is not related to that issue at al= l, would it be possible to clear it?
>>
>> Thanks.
>>
>> On 06/18/2018 10:45 AM, Adam Roach wrote:
>>> Gonzalo:
>>>
>>> TL;DR -- unless someone can find evidence indicating what the = WG intended, I believe we are waiting on you and Simon.
>>>
>>> I had two responses in my most recent message. I presume the f= irst should be uncontroversial.
>>>
>>> The second point pertains to how the working group intended to= treat IP addresses in STUNS URIs. The document right now is ambiguous and = self-contradictory. If this has been discussed in the past, then the docume= nt simply needs to be updated to reflect the outcome of that conversation. = If not, then I believe the WG needs to have a conversation about what is in= tended.
>>>
>>> As it stands, the document will lead to various notions about = whether (and how) IP addresses can be used, which will be an interop nightm= are.
>>>
>>> /a
>>>
>>> On 6/18/18 05:41, Gonzalo Camarillo wrote:
>>>> Marc, Adam,
>>>>
>>>> what is the status of this discussion?
>>>>
>>>> Thanks,
>>>>
>>>> Gonzalo
>>>>
>>>> On 21/05/2018 9:11 PM, Adam Roach wrote:
>>>>> Sorry for taking so long to get back to you on this. T= wo responses below
>>>>> -- everything else looks good.
>>>>>
>>>>> On 5/3/18 6:37 PM, Marc Petit-Huguenin wrote:
>>>>>> On 04/23/2018 03:37 PM, Marc Petit-Huguenin wrote:=
>>>>>>>> ------------------------------------------= ---------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> =C2=A717.3.1:
>>>>>>>>
>>>>>>>>> =C2=A0=C2=A0 IANA is requested to upda= te the names for attributes 0x0002, 0x0003,
>>>>>>>>> =C2=A0=C2=A0 0x0004, 0x0005, 0x0007, a= nd 0x000B, and the reference from RFC 5389
>>>>>>>>> =C2=A0=C2=A0 to RFC-to-be for the foll= owing STUN methods:
>>>>>>>> ...
>>>>>>>>> =C2=A0=C2=A0 0x0003: (Reserved; prior = to [RFC5389] this was CHANGE-REQUEST)
>>>>>>>> The attribute 0x0003 is registered by RFC = 5780, and should not be
>>>>>>>> removed by this document.
>>>>>>> Fixed.
>>>>>
>>>>> Thanks for the change, but the new text still asks IAN= A to update the
>>>>> table so that 0x0003 points to *this* document, instea= d of continuing to
>>>>> point to RFC 5780. Since this document does not do any= thing with
>>>>> CHANGE-REQUEST, this update does not seem correct.
>>>>>
>>>>>
>>>>>>>> ------------------------------------------= ---------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> =C2=A76.2.3 says:
>>>>>>>>
>>>>>>>>> =C2=A0=C2=A0 Alternatively, a
>>>>>>>>> =C2=A0=C2=A0 client MAY be configured = with a set of IP addresses that are
>>>>>>>>> trusted;
>>>>>>>>> =C2=A0=C2=A0 if a certificate is recei= ved that identifies one of those IP
>>>>>>>>> =C2=A0=C2=A0 addresses, the client con= siders the identity of the server to be
>>>>>>>>> =C2=A0=C2=A0 verified.
>>>>>>>> Presumably, this means the server supplies= a certificate with
>>>>>>>> SubjectAltName
>>>>>>>> containing an iPAddress? Please add text t= o clarify whether that's the
>>>>>>>> intention.
>>>>>>>>
>>>>>>>> If that *is* the intended meaning, then th= is behavior in =C2=A78.1 seems
>>>>>>>> unnecessarily restrictive:
>>>>>>>>
>>>>>>>>> =C2=A0=C2=A0 A "stuns" URI >>>>>>>>> =C2=A0=C2=A0 containing an IP address = MUST be rejected, unless the domain name is
>>>>>>>>> =C2=A0=C2=A0 provided by the same mech= anism that provided the STUN URI, and that
>>>>>>>>> =C2=A0=C2=A0 domain name can be passed= to the verification code.
>>>>>>>> Presumably, this is done because certs wit= h iPAddress-form
>>>>>>>> SubjectAltNames are
>>>>>>>> pretty rare (although CAB Forum baseline r= equirements do explicitly
>>>>>>>> allow
>>>>>>>> their issuance) -- but if the text in =C2= =A76.2.3 is based on allowing
>>>>>>>> the use of
>>>>>>>> such certs in a TURN deployment, then it s= eems that URI resolution
>>>>>>>> should be
>>>>>>>> also.
>>>>>>>>
>>>>>>> I am not sure what was the intent there, so I&= #39;ll work on that later.
>>>>>> We addressed all the other comments, but it would = be great if you
>>>>>> could suggest some text to address that one.
>>>>> I'm not sure what was meant either!
>>>>>
>>>>> I think we need to untangle what the working group mea= nt to say
>>>>> regarding "trusted IP addresses," the way th= is protocol is intended to
>>>>> use certs, and whether the prohibition on using IP add= resses in "stuns"
>>>>> URIs derives from cert handling or if it has a complet= ely different
>>>>> rationale behind it; and, if the former, ensure that t= hose things that
>>>>> are prohibited or allowed in certs are similarly prohi= bited or allowed
>>>>> in URIs.
>>>>>
>>>>> I can suggest some *behavior*, but unless there is som= e record of what
>>>>> the WG meant, any such behavior would need to be discu= ssed by the
>>>>> working group, and a consensus would need to be declar= ed by the chairs.
>>>>>
>>>>>
>>>>> /a
>>>>>
>>>
>>


--
Marc Petit-Huguenin
Email: marc@pe= tit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

--000000000000fa11ba0577a4d603-- From nobody Sun Oct 7 08:17:20 2018 Return-Path: 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 BF0C2130E2A; Sun, 7 Oct 2018 08:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 ktcGrVlCZ9b0; Sun, 7 Oct 2018 08:17:15 -0700 (PDT) Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9332D124BE5; Sun, 7 Oct 2018 08:17:15 -0700 (PDT) Received: from [IPv6:2601:648:8400:8e7d:6571:21bd:7029:6ef2] (unknown [IPv6:2601:648:8400:8e7d:6571:21bd:7029:6ef2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 31163AE009; Sun, 7 Oct 2018 17:17:12 +0200 (CEST) To: Rohan Mahy Cc: Benjamin Kaduk , Adam Roach , Gonzalo Camarillo , The IESG , tram-chairs@ietf.org, draft-ietf-tram-stunbis@ietf.org, Tolga Asveren , tram@ietf.org References: <152403138853.31946.14807823535362928987.idtracker@ietfa.amsl.com> <27cb2f70-d907-b61f-bb5a-6b19053238fe@petit-huguenin.org> <1e8cd5de-06de-6745-fc4d-d15fcdd0b4d9@petit-huguenin.org> <5ff10fb0-301e-5d97-01b0-f15296bae0d3@nostrum.com> <20180909014711.GT73164@kduck.kaduk.org> <49512499-0e71-1f5b-e12c-213a3dd88d91@petit-huguenin.org> From: Marc Petit-Huguenin Openpgp: preference=signencrypt Autocrypt: addr=marc@petit-huguenin.org; prefer-encrypt=mutual; keydata= mQINBE6Mh9wBEADrUEDZChteJbQtsHwZITZExr7TAqT7pniNwhBX3nFgd+FrV3lsLKJ1rym2 52MAYpubXEJZGzMp6uCCAnROWbtmQbOm8z/jHnjxHhPqfuYCYPpAQqu8K/Sc194Rp37krMwB jz32yr7+gvWLzRgQGKIh9d2mzy8QLMETVWWQWGb6fEfpOxXo0wumN1rc/275kZwOu44JIPGg zbgwZdnEqYOUUa18K9MXeRDoWbwDISP30CvKuZDwD14lbBE3o7tBQrU9uoMhE7eFlTjbsCox qoubI2tZSuOTF8mRXjPmNrRGtf9mYkQnOB7y6qy/QxmOVMq4IRtHzOYIm/EZ6NTodcpZQHOM 2v6B6YK9uKrYrapSpJzn4f9oU7alT31Y3o2hOlxAWDQ16+Dd1MOPYsKQXOwY1/ihm4PTjiJ8 ud8yPzy7c+BSVs5wkBU6QuLNIgZHrrxdn+KxM+F/oAVtfzO7XzVoeOcXyWi3/CHL5pgoBruY enIF/RrRuplpy09pvZjmFPNfqKBYJGnqpQuqsQwO7LsFqDqfY2EuHg+KsGN1XuN+jxXc48/1 gCnKw7ALSPWEb7g25wD6KfiZTAcyRTG8LePNFQKhw61LbIWmkw9EaVLyXvwPTc1iCSc0dDT/ pcT/z+8xrWOyWGZNZAjR584NlDpKollbItcxYtFcYZkvTCmOVwARAQABtC1NYXJjIFBldGl0 LUh1Z3VlbmluIDxtYXJjQHBldGl0LWh1Z3VlbmluLm9yZz6JAjsEEwEIACUCGyMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheAAhkBBQJX8tdbAAoJECnERZXWan7EiNkQAIbS72cyalFjxQ1l vEW9S8NjjwIMbb5+NC2XqDakAmZq+Aav/Yfk8aEc+eAWBboVC3NBBjYojMRXK1XEnD7xPQ1X rWd23TDibKajy/2fo/MS9/s6uPFOAINi1ykOMq8ShxMHcIPC/dvVt59a7DV1KPGlnUheNR7N 4rIbkL5KndatD38yTGkyKsFvVKTHJn3y5zqHTGP0BjE1rxsGEBn4h+EzxVCIMVFQUeMVPKPV dlQY9fxdicSGPK2WKo1KL3CVpnYTuNCAVIGA9DPTXPPKvEte+/+xv10I03pj4w87iMUZt7Ca FTO55Gsf8hZvmpuB224yzrAbquA450EUVcQ7KAPcHrph5KAu0d3nwrjrUDn/RWWbyRiVrPtf hmnAAhkSv7oOxzyMdLvqt7XKGKbABhrl1ZRF8QbquOkyu8n3Bz2Osgw7JyFn9N6svlFPmpML UTEi64NewvN6zszKs/zBS6bn7na75gxHNvjSZpSF6uSLYgmKbyG8vkY/i0s0e0njjOHcpNx1 0mNZ+wOoCgHtSCZFyv14ncioJTiSjtZCs+srW9PFlbOg73C1Op42xV5Y+dh/mCC+rweKtB3t yTAy52v8vPG0VjsLS52x6yUsoDjYV33AmTEaWmGzN5t8BX/qh7pgNIEd9TEwrR3B4LjqMmUk XXWSJG5IM8Zr2OE/t2vyuQINBE6Mh9wBEAC/i4Lh4XEgwi/yHr3XLx/+f38ztn5rrk8XRsK2 WUpu5evxw9iK2oelqWtS71XkW57EavJOjvP4t8FWqRKED5jWN741n12iW/EeLx3KoHMcPTfY 4WWvprxiZPfnCIpQ8j8x0QQSA+Hf96BSkAkOGNkiJDuus5z4XwTktn9gFOwLVx4VRMo+lrCy um6BDHI+4/sOWnrNp2WptI4YKM/uA0HpuLpPKLra0ZW6Bp2TewNpAjbst/VHjqewab0PeSCn CQiHkqIibdgOATT0K6KoVtMxp/WPRSfVImfWCHjT2G7HFMcb6w/jlPSb+u4VtL9yn76CCg8F SqTtzFuqPtbXkhrdSgks/grxiQryMXwpO0uSuUgZ3u2TSs+65Bl2CM5cq+2aBIER5qhpnCv7 B00uHuoNqUEK0VEpLKcqi2ZeVM5oO8iOaBgS9Gh082HQ5JDijEV2J5e4rwXjbRnJ4hqpTjSy caW8HnPI+4S0aqVxbnqW7T6l/xnn7ivK3aPqaRKqUSedHCU3oHIU31n0o5+f5htQeDs/Tpzn ARHkyzu9vZ9CvQXk8daZorA+j/38q6mWU6Mw8FRIu1qPQDmqljobk3vC9BZRSJOn3P8jNMM7 w1j+7Da3rxGBylfa3fmHPyY7dvdyeLmsq7egzTJkpAMN55Qat7iuXeeCdBQLAFHLBP1tvwAR AQABiQIfBBgBCAAJAhsMBQJX8tdcAAoJECnERZXWan7EkMgP/isd3lrSsm/8t+U44LY0/x67 cPmiKa9biveywJZ9Y+Zu/pUP44dP670mY7PmEDGC6lRiPKGmhf7vqq6JJFOqX64VWePQ9QZp kkzAUmIJwQ2Kmcmfrs0J5w2Lf5qaNji25fQYbon0eUFy6eN3BNRSIcg0+OsH7HubTWfpZeJu B7V7k8OFt2+HDx7aNdNutDJIu4V25AzGfonARQzJK62cmB0pwYXpcyDO152OwP12XbpXxXA1 xHGYQBRL98pSbMU5xsMw8j9VQHQRS94aT9Qqnz9SrYuISnMV2WGyIE0rAY3GGz3IcN5LVE1N vSP51ih+YJg/qsBYs8obbfEIZelOuznWf120RgV7P+7ZWCSBohmchuyELQzl9D7FXfulkXA3 RapKQcGJMVPIHYgnlvmE0OXfJl1z09nYRQHitoQhWtviHWl7x/KL42aUzHirLR61iVA2kqkO BhU+u+g2w8qrZj+lJfXIxlbVyLOuBVqkfcK28AR9RriB4Q5hvbDeQJMgfZsV2hBt7huBOqkH nnbSCguqfnmwLGkxoM7RVjCQwvC1M57uwdKMlsTVaBP0RreZnrDngLamK+ibXYe7p8pPAWD9 cuHvkkjML7cIfuvbScDYRmGzia3V9+LVzQCm+q/6xUY1SZvrDz7OaJOy3Xb1d+aPhYaNC0TQ 7IqA1dx8rZYQ Message-ID: <7aacd118-e726-320b-2083-5ee89746c042@petit-huguenin.org> Date: Sun, 7 Oct 2018 08:17:09 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dNHilH7yyoEsptE1iniEGKiHXTheZE8N1" Archived-At: Subject: Re: [tram] Adam Roach'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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 15:17:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dNHilH7yyoEsptE1iniEGKiHXTheZE8N1 Content-Type: multipart/mixed; boundary="YhcvzDcOxojFEgGwRj0rhEXOJcHPJ9lVn"; protected-headers="v1" From: Marc Petit-Huguenin To: Rohan Mahy Cc: Benjamin Kaduk , Adam Roach , Gonzalo Camarillo , The IESG , tram-chairs@ietf.org, draft-ietf-tram-stunbis@ietf.org, Tolga Asveren , tram@ietf.org Message-ID: <7aacd118-e726-320b-2083-5ee89746c042@petit-huguenin.org> Subject: Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) References: <152403138853.31946.14807823535362928987.idtracker@ietfa.amsl.com> <27cb2f70-d907-b61f-bb5a-6b19053238fe@petit-huguenin.org> <1e8cd5de-06de-6745-fc4d-d15fcdd0b4d9@petit-huguenin.org> <5ff10fb0-301e-5d97-01b0-f15296bae0d3@nostrum.com> <20180909014711.GT73164@kduck.kaduk.org> <49512499-0e71-1f5b-e12c-213a3dd88d91@petit-huguenin.org> In-Reply-To: --YhcvzDcOxojFEgGwRj0rhEXOJcHPJ9lVn Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 10/07/2018 08:05 AM, Rohan Mahy wrote: > [snip] >>> using https, that the hostname verification for the https certificate= >>> implies that the stuns URI embedded in the document are receiving >>> adequate protection and can be used without worrying about the lack o= f >>> certificate verification for the stuns URI. >>> >>> Now that is an assumption that we made, and we'd very much like to he= ar >>> if that assumption is incorrect. >> >> Note that I may be lacking full context, but based just on your > description >> above and =C2=A7 8.1 of the -18, I am concerned about your statement "= without >> worrying about the lack of certificate verification for the stuns URI"= =2E > My >> understanding is, that given a stuns URI with an IP address for the ho= st >> and some domain name specified by the same mechanism that provided the= > URI, >> is that this domain name would then be used as input to the servername= >> verification process for the new connection using this stuns URI. You= r >> statement that I quote here makes it sound like no certificate > verification >> is done on this second connection, which would seem to make it vulnera= ble >> to a MITM attack (and thus be a bad idea). >=20 > Probably too late now, but if you wanted to be able use a stuns: URI sa= fely > with an IP address, you could use a fingerprint URI parameter to preven= t > MITM. This would work as long as you received the URI over an authentic= ated > channel (ex: https:, sip: + S/MIME, and possibly sips:). Yes but, as you said, it is too late now for stunbis and TRAM. Maybe in = a draft in 2019... > Thanks, > -rohan >=20 > On Sun, Oct 7, 2018 at 5:48 AM Marc Petit-Huguenin > wrote: >=20 >> Hi Benjamin, >> >> See inline. >> >> On 09/08/2018 06:52 PM, Benjamin Kaduk wrote: >>> Hi Marc, >>> >>> On Sat, Sep 08, 2018 at 02:59:41PM -0700, Marc Petit-Huguenin wrote: >>>> Hi Adam, >>>> >>>> Apologies for the delay in working on that. >>>> >>>> For the first issue, the fix is in my copy of the draft. >>>> >>>> As for the second issue, Section 8.1 says: >>>> >>>> 'A "stuns" URI >>>> containing an IP address MUST be rejected, unless the domain name i= s >>>> provided by the same mechanism that provided the STUN URI, and that= >>>> domain name can be passed to the verification code.' >>>> >>>> That text was never about IP addresses in certificates, but about th= e >> way a STUN (or TURN really, but that draft does not care about TURN) s= erver >> IP address is passed to a WebRTC browser. RFC 7064 permits to store a= n IP >> address directly inside a stun URI, and RFC 7350 extended that to stun= s >> URI, and in fact the text above is directly copied from RFC 7350. >>>> >>>> The idea is that a stun URI can be provisioned by a JavaScript progr= am >>>> downloaded by a WebRTC browser as part of the initialization of a We= bRTC >>>> application. A security assumption is that using a stuns URI that >>>> contains an API address is safe if the Javascript program was downlo= aded >>> ^^^ >>> (I assume this is autocorrect picking the wrong thing to fix a typo a= nd >>> should be "IP Address") >> >> Yes. But no auto-correct feature was to blame in that case. >> >>> >>>> using https, that the hostname verification for the https certificat= e >>>> implies that the stuns URI embedded in the document are receiving >>>> adequate protection and can be used without worrying about the lack = of >>>> certificate verification for the stuns URI. >>>> >>>> Now that is an assumption that we made, and we'd very much like to h= ear >>>> if that assumption is incorrect. >>> >>> Note that I may be lacking full context, but based just on your >> description >>> above and =C2=A7 8.1 of the -18, I am concerned about your statement = "without >>> worrying about the lack of certificate verification for the stuns URI= ". >> My >>> understanding is, that given a stuns URI with an IP address for the h= ost >>> and some domain name specified by the same mechanism that provided th= e >> URI, >>> is that this domain name would then be used as input to the servernam= e >>> verification process for the new connection using this stuns URI. Yo= ur >>> statement that I quote here makes it sound like no certificate >> verification >>> is done on this second connection, which would seem to make it vulner= able >>> to a MITM attack (and thus be a bad idea). >> >> You are right. I am not sure if there is an easy way to fix that but = if >> someone figure that out it can be spelled out in a separate draft. >> Meanwhile I updated the text in the new version of the draft as follow= : >> >> "If the part of a "stun" URI contains an IP address, then this >> IP address is used directly to contact the server. A "stuns" URI >> containing an IP address MUST be rejected." >> >>> >>> -Benjamin >>> >>>> Section 6.2.3 is unrelated - it is about IP addresses provisioned >> locally (not received from the server), and a matching certificate >> containing IPAddress. I'll make that more explicit after I receive yo= ur >> response on the subject above. >>>> >>>> Also it seems that your DISCUSS is not related to that issue at all,= >> would it be possible to clear it? >>>> >>>> Thanks. >>>> >>>> On 06/18/2018 10:45 AM, Adam Roach wrote: >>>>> Gonzalo: >>>>> >>>>> TL;DR -- unless someone can find evidence indicating what the WG >> intended, I believe we are waiting on you and Simon. >>>>> >>>>> I had two responses in my most recent message. I presume the first >> should be uncontroversial. >>>>> >>>>> The second point pertains to how the working group intended to trea= t >> IP addresses in STUNS URIs. The document right now is ambiguous and >> self-contradictory. If this has been discussed in the past, then the >> document simply needs to be updated to reflect the outcome of that >> conversation. If not, then I believe the WG needs to have a conversati= on >> about what is intended. >>>>> >>>>> As it stands, the document will lead to various notions about wheth= er >> (and how) IP addresses can be used, which will be an interop nightmare= =2E >>>>> >>>>> /a >>>>> >>>>> On 6/18/18 05:41, Gonzalo Camarillo wrote: >>>>>> Marc, Adam, >>>>>> >>>>>> what is the status of this discussion? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Gonzalo >>>>>> >>>>>> On 21/05/2018 9:11 PM, Adam Roach wrote: >>>>>>> Sorry for taking so long to get back to you on this. Two response= s >> below >>>>>>> -- everything else looks good. >>>>>>> >>>>>>> On 5/3/18 6:37 PM, Marc Petit-Huguenin wrote: >>>>>>>> On 04/23/2018 03:37 PM, Marc Petit-Huguenin wrote: >>>>>>>>>> >> ----------------------------------------------------------------------= ----- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> =C2=A717.3.1: >>>>>>>>>> >>>>>>>>>>> IANA is requested to update the names for attributes 0x000= 2, >> 0x0003, >>>>>>>>>>> 0x0004, 0x0005, 0x0007, and 0x000B, and the reference from= >> RFC 5389 >>>>>>>>>>> to RFC-to-be for the following STUN methods: >>>>>>>>>> ... >>>>>>>>>>> 0x0003: (Reserved; prior to [RFC5389] this was CHANGE-REQU= EST) >>>>>>>>>> The attribute 0x0003 is registered by RFC 5780, and should not= be >>>>>>>>>> removed by this document. >>>>>>>>> Fixed. >>>>>>> >>>>>>> Thanks for the change, but the new text still asks IANA to update= the >>>>>>> table so that 0x0003 points to *this* document, instead of >> continuing to >>>>>>> point to RFC 5780. Since this document does not do anything with >>>>>>> CHANGE-REQUEST, this update does not seem correct. >>>>>>> >>>>>>> >>>>>>>>>> >> ----------------------------------------------------------------------= ----- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> =C2=A76.2.3 says: >>>>>>>>>> >>>>>>>>>>> Alternatively, a >>>>>>>>>>> client MAY be configured with a set of IP addresses that a= re >>>>>>>>>>> trusted; >>>>>>>>>>> if a certificate is received that identifies one of those = IP >>>>>>>>>>> addresses, the client considers the identity of the server= to >> be >>>>>>>>>>> verified. >>>>>>>>>> Presumably, this means the server supplies a certificate with >>>>>>>>>> SubjectAltName >>>>>>>>>> containing an iPAddress? Please add text to clarify whether >> that's the >>>>>>>>>> intention. >>>>>>>>>> >>>>>>>>>> If that *is* the intended meaning, then this behavior in =C2=A7= 8.1 >> seems >>>>>>>>>> unnecessarily restrictive: >>>>>>>>>> >>>>>>>>>>> A "stuns" URI >>>>>>>>>>> containing an IP address MUST be rejected, unless the doma= in >> name is >>>>>>>>>>> provided by the same mechanism that provided the STUN URI,= >> and that >>>>>>>>>>> domain name can be passed to the verification code. >>>>>>>>>> Presumably, this is done because certs with iPAddress-form >>>>>>>>>> SubjectAltNames are >>>>>>>>>> pretty rare (although CAB Forum baseline requirements do >> explicitly >>>>>>>>>> allow >>>>>>>>>> their issuance) -- but if the text in =C2=A76.2.3 is based on = allowing >>>>>>>>>> the use of >>>>>>>>>> such certs in a TURN deployment, then it seems that URI resolu= tion >>>>>>>>>> should be >>>>>>>>>> also. >>>>>>>>>> >>>>>>>>> I am not sure what was the intent there, so I'll work on that >> later. >>>>>>>> We addressed all the other comments, but it would be great if yo= u >>>>>>>> could suggest some text to address that one. >>>>>>> I'm not sure what was meant either! >>>>>>> >>>>>>> I think we need to untangle what the working group meant to say >>>>>>> regarding "trusted IP addresses," the way this protocol is intend= ed >> to >>>>>>> use certs, and whether the prohibition on using IP addresses in >> "stuns" >>>>>>> URIs derives from cert handling or if it has a completely differe= nt >>>>>>> rationale behind it; and, if the former, ensure that those things= >> that >>>>>>> are prohibited or allowed in certs are similarly prohibited or >> allowed >>>>>>> in URIs. >>>>>>> >>>>>>> I can suggest some *behavior*, but unless there is some record of= >> what >>>>>>> the WG meant, any such behavior would need to be discussed by the= >>>>>>> working group, and a consensus would need to be declared by the >> chairs. >>>>>>> >>>>>>> >>>>>>> /a >>>>>>> >>>>> --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --YhcvzDcOxojFEgGwRj0rhEXOJcHPJ9lVn-- --dNHilH7yyoEsptE1iniEGKiHXTheZE8N1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlu6I3UACgkQKcRFldZq fsQd3Q/+NKzCSyyXGotVr0zNQJKKNkbOinjmychGhF5JbrfZ4JESfgkpS1nyHPoF 0YkLzGH2CcO5Ju+0eSgFPhDF/GXjONLHSw8iLXJy2QTie/KGuXIYdSCVfPX6ytd4 Cd9BQSzMP7HngAz4txERRW48nhMYKuvkYuuPsX/3yHqn8Fv37e/4Bu0u4uyj3M6v h8I9vvTpBBF0OkP2h9GfSbkpGTS0BN6ZZhAKRTbylbrIKz4/LvpfsO1aHabxh3qS ELKY1KrLZAMBPTJsFZ5KIdVnY0D7M/sn5CzR+XWYkSSrMNXDZlguSy3H0Rjgkm8P RLCUweV8c63zfdODPPLBXx9xvD1T8aK47BBuliVKGuzQDac5cE5pHFBlCtjxs2EW hsWEApJoVf7Je1R6ksJh7yoq/SuAgigEo38elFu1Vt2Qutwo1zSKSQNUR7dMsZ2L oJUfElouzkkSmWRYcDg4LGzWDI/AttxneOV+xLv+kYqbczI3oO+oiMAFx5cDIh7B xh2c91OD3i33YYCSi9Ks9kob68GPae3WPBgT4M/EKASXBbGbnfaK1ZWXEc8Clc0z FaizUREeFMm1/IYTF3o5fdvVzeVPNjahofZ4Sp1lnT7C1keXfXJLltAJqJunv/AT Efw3rykzj24tRLS/FiKgKmFoMII0mNa5aR54NM68DqqatzceXHQ= =K7Fc -----END PGP SIGNATURE----- --dNHilH7yyoEsptE1iniEGKiHXTheZE8N1-- From nobody Sun Oct 7 13:27:46 2018 Return-Path: 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 0676A1292AD; Sun, 7 Oct 2018 13:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 zk7Xml7cDapu; Sun, 7 Oct 2018 13:27:35 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5CE2124D68; Sun, 7 Oct 2018 13:27:34 -0700 (PDT) X-AuditID: 1209190f-2bfff700000069a2-6c-5bba6c34c5cc Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 0F.67.27042.53C6ABB5; Sun, 7 Oct 2018 16:27:33 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w97KRRhS006411; Sun, 7 Oct 2018 16:27:28 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w97KRJFo031990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 7 Oct 2018 16:27:23 -0400 Date: Sun, 7 Oct 2018 15:27:19 -0500 From: Benjamin Kaduk To: Marc Petit-Huguenin Cc: Adam Roach , Gonzalo Camarillo , The IESG , tram-chairs@ietf.org, draft-ietf-tram-stunbis@ietf.org, Tolga Asveren , tram@ietf.org Message-ID: <20181007202719.GD56675@kduck.kaduk.org> References: <152403138853.31946.14807823535362928987.idtracker@ietfa.amsl.com> <27cb2f70-d907-b61f-bb5a-6b19053238fe@petit-huguenin.org> <1e8cd5de-06de-6745-fc4d-d15fcdd0b4d9@petit-huguenin.org> <5ff10fb0-301e-5d97-01b0-f15296bae0d3@nostrum.com> <20180909014711.GT73164@kduck.kaduk.org> <49512499-0e71-1f5b-e12c-213a3dd88d91@petit-huguenin.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <49512499-0e71-1f5b-e12c-213a3dd88d91@petit-huguenin.org> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNKsWRmVeSWpSXmKPExsUixG6nomuasyva4MNfNYs9fxexW3Ruucxm sWn5SiaLGX8mMlusPX6T0WL98m/sFst/rmSz+LD2ApsDh8evr1fZPJYs+cnkMWvnExaP46ev s3rsmTOJMYA1issmJTUnsyy1SN8ugSvjweapbAXXpSvuHTrK2sC4T7SLkZNDQsBEYu/fKUwg tpDAYiaJ533ZXYxcQPYGRonzh96wQzhXmCS+TpvO3MXIwcEioCIxZZYZSAMbkNnQfZkZxBYR MJQ4v+g6M0g9s8BfRokv236ygSSEBVIkjj6YwATSywu0bfeaTIiZnSwSXYcus4PU8AoISpyc +YQFxGYW0JHYufUOG0g9s4C0xPJ/HBBheYnmrbPBdnEKuEn8b94LZosKKEvs7TvEPoFRcBaS SbOQTJqFMGkWkkkLGFlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Zro5WaW6KWmlG5iBMULpyT/ DsY5Dd6HGAU4GJV4eBmCd0ULsSaWFVfmHmKU5GBSEuU9sWFntBBfUn5KZUZicUZ8UWlOavEh RgkOZiUR3k9BQDnelMTKqtSifJiUNAeLkjjvhJbF0UIC6YklqdmpqQWpRTBZGQ4OJQne21lA ewSLUtNTK9Iyc0oQ0kwcnCDDeYCGvwCp4S0uSMwtzkyHyJ9i1OVoe3p9BrMQS15+XqqUOG8i SJEASFFGaR7cHFCak8jeX/OKURzoLWFeu2ygKh5gioSb9ApoCRPQkt8JO0CWlCQipKQaGK0X u10XUk7Mt7ydG5zOu2P288N1c84LstiGLH47Z9fhqIsh53ftCQgKNJxsnvR3tmLyMktBI6U3 s/0Kg92/8VZ/nfRP0HC6tN7Km18aXjKq+ZqvW2EXdf9Ndck/o3oeDyf52EW9G4Jn1ylkPn/6 WCJsBkNIfM6X5nPlrcKrXLbqmvwqnv5lkhJLcUaioRZzUXEiAGItZmBOAwAA Archived-At: Subject: Re: [tram] Adam Roach'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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 20:27:37 -0000 Hi Marc, On Sun, Oct 07, 2018 at 05:47:54AM -0700, Marc Petit-Huguenin wrote: > Hi Benjamin, > > See inline. > > On 09/08/2018 06:52 PM, Benjamin Kaduk wrote: > > Hi Marc, > > > > On Sat, Sep 08, 2018 at 02:59:41PM -0700, Marc Petit-Huguenin wrote: > >> Hi Adam, > >> > >> Apologies for the delay in working on that. > >> > >> For the first issue, the fix is in my copy of the draft. > >> > >> As for the second issue, Section 8.1 says: > >> > >> 'A "stuns" URI > >> containing an IP address MUST be rejected, unless the domain name is > >> provided by the same mechanism that provided the STUN URI, and that > >> domain name can be passed to the verification code.' > >> > >> That text was never about IP addresses in certificates, but about the way a STUN (or TURN really, but that draft does not care about TURN) server IP address is passed to a WebRTC browser. RFC 7064 permits to store an IP address directly inside a stun URI, and RFC 7350 extended that to stuns URI, and in fact the text above is directly copied from RFC 7350. > >> > >> The idea is that a stun URI can be provisioned by a JavaScript program > >> downloaded by a WebRTC browser as part of the initialization of a WebRTC > >> application. A security assumption is that using a stuns URI that > >> contains an API address is safe if the Javascript program was downloaded > > ^^^ > > (I assume this is autocorrect picking the wrong thing to fix a typo and > > should be "IP Address") > > Yes. But no auto-correct feature was to blame in that case. > > > > >> using https, that the hostname verification for the https certificate > >> implies that the stuns URI embedded in the document are receiving > >> adequate protection and can be used without worrying about the lack of > >> certificate verification for the stuns URI. > >> > >> Now that is an assumption that we made, and we'd very much like to hear > >> if that assumption is incorrect. > > > > Note that I may be lacking full context, but based just on your description > > above and § 8.1 of the -18, I am concerned about your statement "without > > worrying about the lack of certificate verification for the stuns URI". My > > understanding is, that given a stuns URI with an IP address for the host > > and some domain name specified by the same mechanism that provided the URI, > > is that this domain name would then be used as input to the servername > > verification process for the new connection using this stuns URI. Your > > statement that I quote here makes it sound like no certificate verification > > is done on this second connection, which would seem to make it vulnerable > > to a MITM attack (and thus be a bad idea). > > You are right. I am not sure if there is an easy way to fix that but if someone figure that out it can be spelled out in a separate draft. Meanwhile I updated the text in the new version of the draft as follow: > > "If the part of a "stun" URI contains an IP address, then this > IP address is used directly to contact the server. A "stuns" URI > containing an IP address MUST be rejected." Thanks, this is an okay way to address my concern. (I think it would also be fine to allow "stuns" URIs with IP addresses, if they are obtained over secure transport and accompanied by a hostname to use in certificate validation, but I can understand if you don't want to try to capture the subtleties of that in a document at this stage of processing.) -Benjamin From nobody Sun Oct 7 13:37:34 2018 Return-Path: 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 591AF130DEF; Sun, 7 Oct 2018 13:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_GDJ6h2iVYk; Sun, 7 Oct 2018 13:37:21 -0700 (PDT) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 0C62F124D68; Sun, 7 Oct 2018 13:37:21 -0700 (PDT) Received: by mail-ua1-x92b.google.com with SMTP id g18-v6so6459585uam.6; Sun, 07 Oct 2018 13:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9Zhw2ip7iPwAsN+7vVKl362nVGD6b0/zAOUQq9AvHJw=; b=Kf5rlbOrKCAX2u8175/O0DtyJkOr3oGbq9nO02uDzRmxa223ul8ullFfLexKhojCMw jjDN7+/l/P+w9kxjc305QbCcc3oTsosnojlOQx3urDpkEr74g5R7oz15W19JQJuXVUtc ClsWHJUZrk2uZymvQdYVYJ+eB3zl2kZVPI3hHibuYjTCLCHIE/uFhXEaJyyb0QDYsU4V SAuOovP6NFrzonvoZU1662MXhz+Fl2phmhzrKvoI7JiPzrqCPjU+Fpu4fPxbIGj1BJwj w/4/VQDXYzLwlL6hn+qMYRZPD6T3QDj0RW9l5FLQ3QhgLZXZF302rnz9Tcq8KWzM2Yj2 AgMg== 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=9Zhw2ip7iPwAsN+7vVKl362nVGD6b0/zAOUQq9AvHJw=; b=IG+JFEek7icRqq3x3OsSaOJCQDAj/adz+hanKDsaFJTQ7KiQsIJS3ONEjC4ihdHqeh 187eKhoEMwFpFIBHxs6YDQMWnUiXfiTfDXkPpWcFUlSM2DlsbS65N7i4aUVMy/V91apy yPXHTedFHM03pz8VY44UwctEiDHdjHzdPJG8EQjJEn3hj7J9aLlYsxggObKACRO6Jz1y rP5n/EvWWsmZmA0a2z0UF2+Ruz3YzcgGvJmE0Pu/arDrszDkgFm7jSjup3Xe/RTWy4iV /h5hzvYgN1TB0aoGjjzv4XDCHRJW7msDPPD/rbkiuAYciLDUR6mqs1NgLBNn4s+uMspP CGHg== X-Gm-Message-State: ABuFfoi4o/GeJ4XGTcyBzcQA6Hn1jpUX9XN1AAF2bxoxXK0FrkBBVU5I wLU9z45slG3sMvYINggdazN8HXUrDKcMI1KjIhc= X-Google-Smtp-Source: ACcGV605yRjmCf2DOvOEH8SfMb803Bb4bqPWrbis+y3F704K0o3IGzKb/XEVMJZA12VHZfyj+WAAanUd4I8Cgoia+4g= X-Received: by 2002:ab0:2101:: with SMTP id d1mr7732463ual.108.1538944639836; Sun, 07 Oct 2018 13:37:19 -0700 (PDT) MIME-Version: 1.0 References: <152403138853.31946.14807823535362928987.idtracker@ietfa.amsl.com> <27cb2f70-d907-b61f-bb5a-6b19053238fe@petit-huguenin.org> <1e8cd5de-06de-6745-fc4d-d15fcdd0b4d9@petit-huguenin.org> <5ff10fb0-301e-5d97-01b0-f15296bae0d3@nostrum.com> <20180909014711.GT73164@kduck.kaduk.org> <49512499-0e71-1f5b-e12c-213a3dd88d91@petit-huguenin.org> <7aacd118-e726-320b-2083-5ee89746c042@petit-huguenin.org> In-Reply-To: <7aacd118-e726-320b-2083-5ee89746c042@petit-huguenin.org> From: Rohan Mahy Date: Sun, 7 Oct 2018 13:37:08 -0700 Message-ID: To: Marc Petit-Huguenin Cc: Benjamin Kaduk , Adam Roach , Gonzalo Camarillo , The IESG , tram-chairs@ietf.org, draft-ietf-tram-stunbis@ietf.org, Tolga Asveren , tram@ietf.org Content-Type: multipart/alternative; boundary="0000000000009628650577a978bf" Archived-At: Subject: Re: [tram] Adam Roach'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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2018 20:37:25 -0000 --0000000000009628650577a978bf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If we think this might happen we could add: "A future STUN extension or usage may relax this requirement provided it demonstrates how to authenticate the STUN server and prevent man in the middle attacks." Thanks, -rohan On Sun, Oct 7, 2018, 08:17 Marc Petit-Huguenin wrote: > On 10/07/2018 08:05 AM, Rohan Mahy wrote: > > [snip] > >>> using https, that the hostname verification for the https certificate > >>> implies that the stuns URI embedded in the document are receiving > >>> adequate protection and can be used without worrying about the lack o= f > >>> certificate verification for the stuns URI. > >>> > >>> Now that is an assumption that we made, and we'd very much like to he= ar > >>> if that assumption is incorrect. > >> > >> Note that I may be lacking full context, but based just on your > > description > >> above and =C2=A7 8.1 of the -18, I am concerned about your statement "= without > >> worrying about the lack of certificate verification for the stuns URI"= . > > My > >> understanding is, that given a stuns URI with an IP address for the ho= st > >> and some domain name specified by the same mechanism that provided the > > URI, > >> is that this domain name would then be used as input to the servername > >> verification process for the new connection using this stuns URI. You= r > >> statement that I quote here makes it sound like no certificate > > verification > >> is done on this second connection, which would seem to make it > vulnerable > >> to a MITM attack (and thus be a bad idea). > > > > Probably too late now, but if you wanted to be able use a stuns: URI > safely > > with an IP address, you could use a fingerprint URI parameter to preven= t > > MITM. This would work as long as you received the URI over an > authenticated > > channel (ex: https:, sip: + S/MIME, and possibly sips:). > > Yes but, as you said, it is too late now for stunbis and TRAM. Maybe in = a > draft in 2019... > > > Thanks, > > -rohan > > > > On Sun, Oct 7, 2018 at 5:48 AM Marc Petit-Huguenin < > marc@petit-huguenin.org> > > wrote: > > > >> Hi Benjamin, > >> > >> See inline. > >> > >> On 09/08/2018 06:52 PM, Benjamin Kaduk wrote: > >>> Hi Marc, > >>> > >>> On Sat, Sep 08, 2018 at 02:59:41PM -0700, Marc Petit-Huguenin wrote: > >>>> Hi Adam, > >>>> > >>>> Apologies for the delay in working on that. > >>>> > >>>> For the first issue, the fix is in my copy of the draft. > >>>> > >>>> As for the second issue, Section 8.1 says: > >>>> > >>>> 'A "stuns" URI > >>>> containing an IP address MUST be rejected, unless the domain name i= s > >>>> provided by the same mechanism that provided the STUN URI, and that > >>>> domain name can be passed to the verification code.' > >>>> > >>>> That text was never about IP addresses in certificates, but about th= e > >> way a STUN (or TURN really, but that draft does not care about TURN) > server > >> IP address is passed to a WebRTC browser. RFC 7064 permits to store a= n > IP > >> address directly inside a stun URI, and RFC 7350 extended that to stun= s > >> URI, and in fact the text above is directly copied from RFC 7350. > >>>> > >>>> The idea is that a stun URI can be provisioned by a JavaScript progr= am > >>>> downloaded by a WebRTC browser as part of the initialization of a > WebRTC > >>>> application. A security assumption is that using a stuns URI that > >>>> contains an API address is safe if the Javascript program was > downloaded > >>> ^^^ > >>> (I assume this is autocorrect picking the wrong thing to fix a typo a= nd > >>> should be "IP Address") > >> > >> Yes. But no auto-correct feature was to blame in that case. > >> > >>> > >>>> using https, that the hostname verification for the https certificat= e > >>>> implies that the stuns URI embedded in the document are receiving > >>>> adequate protection and can be used without worrying about the lack = of > >>>> certificate verification for the stuns URI. > >>>> > >>>> Now that is an assumption that we made, and we'd very much like to > hear > >>>> if that assumption is incorrect. > >>> > >>> Note that I may be lacking full context, but based just on your > >> description > >>> above and =C2=A7 8.1 of the -18, I am concerned about your statement > "without > >>> worrying about the lack of certificate verification for the stuns URI= ". > >> My > >>> understanding is, that given a stuns URI with an IP address for the > host > >>> and some domain name specified by the same mechanism that provided th= e > >> URI, > >>> is that this domain name would then be used as input to the servernam= e > >>> verification process for the new connection using this stuns URI. Yo= ur > >>> statement that I quote here makes it sound like no certificate > >> verification > >>> is done on this second connection, which would seem to make it > vulnerable > >>> to a MITM attack (and thus be a bad idea). > >> > >> You are right. I am not sure if there is an easy way to fix that but = if > >> someone figure that out it can be spelled out in a separate draft. > >> Meanwhile I updated the text in the new version of the draft as follow= : > >> > >> "If the part of a "stun" URI contains an IP address, then this > >> IP address is used directly to contact the server. A "stuns" URI > >> containing an IP address MUST be rejected." > >> > >>> > >>> -Benjamin > >>> > >>>> Section 6.2.3 is unrelated - it is about IP addresses provisioned > >> locally (not received from the server), and a matching certificate > >> containing IPAddress. I'll make that more explicit after I receive yo= ur > >> response on the subject above. > >>>> > >>>> Also it seems that your DISCUSS is not related to that issue at all, > >> would it be possible to clear it? > >>>> > >>>> Thanks. > >>>> > >>>> On 06/18/2018 10:45 AM, Adam Roach wrote: > >>>>> Gonzalo: > >>>>> > >>>>> TL;DR -- unless someone can find evidence indicating what the WG > >> intended, I believe we are waiting on you and Simon. > >>>>> > >>>>> I had two responses in my most recent message. I presume the first > >> should be uncontroversial. > >>>>> > >>>>> The second point pertains to how the working group intended to trea= t > >> IP addresses in STUNS URIs. The document right now is ambiguous and > >> self-contradictory. If this has been discussed in the past, then the > >> document simply needs to be updated to reflect the outcome of that > >> conversation. If not, then I believe the WG needs to have a conversati= on > >> about what is intended. > >>>>> > >>>>> As it stands, the document will lead to various notions about wheth= er > >> (and how) IP addresses can be used, which will be an interop nightmare= . > >>>>> > >>>>> /a > >>>>> > >>>>> On 6/18/18 05:41, Gonzalo Camarillo wrote: > >>>>>> Marc, Adam, > >>>>>> > >>>>>> what is the status of this discussion? > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Gonzalo > >>>>>> > >>>>>> On 21/05/2018 9:11 PM, Adam Roach wrote: > >>>>>>> Sorry for taking so long to get back to you on this. Two response= s > >> below > >>>>>>> -- everything else looks good. > >>>>>>> > >>>>>>> On 5/3/18 6:37 PM, Marc Petit-Huguenin wrote: > >>>>>>>> On 04/23/2018 03:37 PM, Marc Petit-Huguenin wrote: > >>>>>>>>>> > >> > -------------------------------------------------------------------------= -- > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> =C2=A717.3.1: > >>>>>>>>>> > >>>>>>>>>>> IANA is requested to update the names for attributes 0x000= 2, > >> 0x0003, > >>>>>>>>>>> 0x0004, 0x0005, 0x0007, and 0x000B, and the reference from > >> RFC 5389 > >>>>>>>>>>> to RFC-to-be for the following STUN methods: > >>>>>>>>>> ... > >>>>>>>>>>> 0x0003: (Reserved; prior to [RFC5389] this was > CHANGE-REQUEST) > >>>>>>>>>> The attribute 0x0003 is registered by RFC 5780, and should not > be > >>>>>>>>>> removed by this document. > >>>>>>>>> Fixed. > >>>>>>> > >>>>>>> Thanks for the change, but the new text still asks IANA to update > the > >>>>>>> table so that 0x0003 points to *this* document, instead of > >> continuing to > >>>>>>> point to RFC 5780. Since this document does not do anything with > >>>>>>> CHANGE-REQUEST, this update does not seem correct. > >>>>>>> > >>>>>>> > >>>>>>>>>> > >> > -------------------------------------------------------------------------= -- > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> =C2=A76.2.3 says: > >>>>>>>>>> > >>>>>>>>>>> Alternatively, a > >>>>>>>>>>> client MAY be configured with a set of IP addresses that a= re > >>>>>>>>>>> trusted; > >>>>>>>>>>> if a certificate is received that identifies one of those = IP > >>>>>>>>>>> addresses, the client considers the identity of the server > to > >> be > >>>>>>>>>>> verified. > >>>>>>>>>> Presumably, this means the server supplies a certificate with > >>>>>>>>>> SubjectAltName > >>>>>>>>>> containing an iPAddress? Please add text to clarify whether > >> that's the > >>>>>>>>>> intention. > >>>>>>>>>> > >>>>>>>>>> If that *is* the intended meaning, then this behavior in =C2= =A78.1 > >> seems > >>>>>>>>>> unnecessarily restrictive: > >>>>>>>>>> > >>>>>>>>>>> A "stuns" URI > >>>>>>>>>>> containing an IP address MUST be rejected, unless the doma= in > >> name is > >>>>>>>>>>> provided by the same mechanism that provided the STUN URI, > >> and that > >>>>>>>>>>> domain name can be passed to the verification code. > >>>>>>>>>> Presumably, this is done because certs with iPAddress-form > >>>>>>>>>> SubjectAltNames are > >>>>>>>>>> pretty rare (although CAB Forum baseline requirements do > >> explicitly > >>>>>>>>>> allow > >>>>>>>>>> their issuance) -- but if the text in =C2=A76.2.3 is based on > allowing > >>>>>>>>>> the use of > >>>>>>>>>> such certs in a TURN deployment, then it seems that URI > resolution > >>>>>>>>>> should be > >>>>>>>>>> also. > >>>>>>>>>> > >>>>>>>>> I am not sure what was the intent there, so I'll work on that > >> later. > >>>>>>>> We addressed all the other comments, but it would be great if yo= u > >>>>>>>> could suggest some text to address that one. > >>>>>>> I'm not sure what was meant either! > >>>>>>> > >>>>>>> I think we need to untangle what the working group meant to say > >>>>>>> regarding "trusted IP addresses," the way this protocol is intend= ed > >> to > >>>>>>> use certs, and whether the prohibition on using IP addresses in > >> "stuns" > >>>>>>> URIs derives from cert handling or if it has a completely differe= nt > >>>>>>> rationale behind it; and, if the former, ensure that those things > >> that > >>>>>>> are prohibited or allowed in certs are similarly prohibited or > >> allowed > >>>>>>> in URIs. > >>>>>>> > >>>>>>> I can suggest some *behavior*, but unless there is some record of > >> what > >>>>>>> the WG meant, any such behavior would need to be discussed by the > >>>>>>> working group, and a consensus would need to be declared by the > >> chairs. > >>>>>>> > >>>>>>> > >>>>>>> /a > >>>>>>> > >>>>> > > > > -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: https://marc.petit-huguenin.org > Profile: https://www.linkedin.com/in/petithug > > --0000000000009628650577a978bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If we think this might happen we could add: "A futur= e STUN extension or usage may relax this requirement provided it demonstrat= es how to authenticate the STUN server and prevent man in the middle attack= s."
Thanks,
-rohan
=
On Sun, Oct 7, 2018, 08:17 = Marc Petit-Huguenin <marc@pet= it-huguenin.org> wrote:
On 1= 0/07/2018 08:05 AM, Rohan Mahy wrote:
> [snip]
>>> using https, that the hostname verification for the https cert= ificate
>>> implies that the stuns URI embedded in the document are receiv= ing
>>> adequate protection and can be used without worrying about the= lack of
>>> certificate verification for the stuns URI.
>>>
>>> Now that is an assumption that we made, and we'd very much= like to hear
>>> if that assumption is incorrect.
>>
>> Note that I may be lacking full context, but based just on your > description
>> above and =C2=A7 8.1 of the -18, I am concerned about your stateme= nt "without
>> worrying about the lack of certificate verification for the stuns = URI".
> My
>> understanding is, that given a stuns URI with an IP address for th= e host
>> and some domain name specified by the same mechanism that provided= the
> URI,
>> is that this domain name would then be used as input to the server= name
>> verification process for the new connection using this stuns URI.= =C2=A0 Your
>> statement that I quote here makes it sound like no certificate
> verification
>> is done on this second connection, which would seem to make it vul= nerable
>> to a MITM attack (and thus be a bad idea).
>
> Probably too late now, but if you wanted to be able use a stuns: URI s= afely
> with an IP address, you could use a fingerprint URI parameter to preve= nt
> MITM. This would work as long as you received the URI over an authenti= cated
> channel (ex: https:, sip: + S/MIME, and possibly sips:).

Yes but, as you said, it is too late now for stunbis and TRAM.=C2=A0 Maybe = in a draft in 2019...

> Thanks,
> -rohan
>
> On Sun, Oct 7, 2018 at 5:48 AM Marc Petit-Huguenin <marc@petit= -huguenin.org>
> wrote:
>
>> Hi Benjamin,
>>
>> See inline.
>>
>> On 09/08/2018 06:52 PM, Benjamin Kaduk wrote:
>>> Hi Marc,
>>>
>>> On Sat, Sep 08, 2018 at 02:59:41PM -0700, Marc Petit-Huguenin = wrote:
>>>> Hi Adam,
>>>>
>>>> Apologies for the delay in working on that.
>>>>
>>>> For the first issue, the fix is in my copy of the draft. >>>>
>>>> As for the second issue, Section 8.1 says:
>>>>
>>>> 'A "stuns" URI
>>>>=C2=A0 containing an IP address MUST be rejected, unless th= e domain name is
>>>>=C2=A0 provided by the same mechanism that provided the STU= N URI, and that
>>>>=C2=A0 domain name can be passed to the verification code.&= #39;
>>>>
>>>> That text was never about IP addresses in certificates, bu= t about the
>> way a STUN (or TURN really, but that draft does not care about TUR= N) server
>> IP address is passed to a WebRTC browser.=C2=A0 RFC 7064 permits t= o store an IP
>> address directly inside a stun URI, and RFC 7350 extended that to = stuns
>> URI, and in fact the text above is directly copied from RFC 7350.<= br> >>>>
>>>> The idea is that a stun URI can be provisioned by a JavaSc= ript program
>>>> downloaded by a WebRTC browser as part of the initializati= on of a WebRTC
>>>> application.=C2=A0 A security assumption is that using a s= tuns URI that
>>>> contains an API address is safe if the Javascript program = was downloaded
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^
>>> (I assume this is autocorrect picking the wrong thing to fix a= typo and
>>> should be "IP Address")
>>
>> Yes.=C2=A0 But no auto-correct feature was to blame in that case.<= br> >>
>>>
>>>> using https, that the hostname verification for the https = certificate
>>>> implies that the stuns URI embedded in the document are re= ceiving
>>>> adequate protection and can be used without worrying about= the lack of
>>>> certificate verification for the stuns URI.
>>>>
>>>> Now that is an assumption that we made, and we'd very = much like to hear
>>>> if that assumption is incorrect.
>>>
>>> Note that I may be lacking full context, but based just on you= r
>> description
>>> above and =C2=A7 8.1 of the -18, I am concerned about your sta= tement "without
>>> worrying about the lack of certificate verification for the st= uns URI".
>> My
>>> understanding is, that given a stuns URI with an IP address fo= r the host
>>> and some domain name specified by the same mechanism that prov= ided the
>> URI,
>>> is that this domain name would then be used as input to the se= rvername
>>> verification process for the new connection using this stuns U= RI.=C2=A0 Your
>>> statement that I quote here makes it sound like no certificate=
>> verification
>>> is done on this second connection, which would seem to make it= vulnerable
>>> to a MITM attack (and thus be a bad idea).
>>
>> You are right.=C2=A0 I am not sure if there is an easy way to fix = that but if
>> someone figure that out it can be spelled out in a separate draft.=
>> Meanwhile I updated the text in the new version of the draft as fo= llow:
>>
>> "If the <host> part of a "stun" URI contains = an IP address, then this
>>=C2=A0 IP address is used directly to contact the server.=C2=A0 A &= quot;stuns" URI
>>=C2=A0 containing an IP address MUST be rejected."
>>
>>>
>>> -Benjamin
>>>
>>>> Section 6.2.3 is unrelated - it is about IP addresses prov= isioned
>> locally (not received from the server), and a matching certificate=
>> containing IPAddress.=C2=A0 I'll make that more explicit after= I receive your
>> response on the subject above.
>>>>
>>>> Also it seems that your DISCUSS is not related to that iss= ue at all,
>> would it be possible to clear it?
>>>>
>>>> Thanks.
>>>>
>>>> On 06/18/2018 10:45 AM, Adam Roach wrote:
>>>>> Gonzalo:
>>>>>
>>>>> TL;DR -- unless someone can find evidence indicating w= hat the WG
>> intended, I believe we are waiting on you and Simon.
>>>>>
>>>>> I had two responses in my most recent message. I presu= me the first
>> should be uncontroversial.
>>>>>
>>>>> The second point pertains to how the working group int= ended to treat
>> IP addresses in STUNS URIs. The document right now is ambiguous an= d
>> self-contradictory. If this has been discussed in the past, then t= he
>> document simply needs to be updated to reflect the outcome of that=
>> conversation. If not, then I believe the WG needs to have a conver= sation
>> about what is intended.
>>>>>
>>>>> As it stands, the document will lead to various notion= s about whether
>> (and how) IP addresses can be used, which will be an interop night= mare.
>>>>>
>>>>> /a
>>>>>
>>>>> On 6/18/18 05:41, Gonzalo Camarillo wrote:
>>>>>> Marc, Adam,
>>>>>>
>>>>>> what is the status of this discussion?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Gonzalo
>>>>>>
>>>>>> On 21/05/2018 9:11 PM, Adam Roach wrote:
>>>>>>> Sorry for taking so long to get back to you on= this. Two responses
>> below
>>>>>>> -- everything else looks good.
>>>>>>>
>>>>>>> On 5/3/18 6:37 PM, Marc Petit-Huguenin wrote:<= br> >>>>>>>> On 04/23/2018 03:37 PM, Marc Petit-Hugueni= n wrote:
>>>>>>>>>>
>> ------------------------------------------------------------------= ---------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> =C2=A717.3.1:
>>>>>>>>>>
>>>>>>>>>>>=C2=A0 =C2=A0 IANA is requested= to update the names for attributes 0x0002,
>> 0x0003,
>>>>>>>>>>>=C2=A0 =C2=A0 0x0004, 0x0005, 0= x0007, and 0x000B, and the reference from
>> RFC 5389
>>>>>>>>>>>=C2=A0 =C2=A0 to RFC-to-be for = the following STUN methods:
>>>>>>>>>> ...
>>>>>>>>>>>=C2=A0 =C2=A0 0x0003: (Reserved= ; prior to [RFC5389] this was CHANGE-REQUEST)
>>>>>>>>>> The attribute 0x0003 is registered= by RFC 5780, and should not be
>>>>>>>>>> removed by this document.
>>>>>>>>> Fixed.
>>>>>>>
>>>>>>> Thanks for the change, but the new text still = asks IANA to update the
>>>>>>> table so that 0x0003 points to *this* document= , instead of
>> continuing to
>>>>>>> point to RFC 5780. Since this document does no= t do anything with
>>>>>>> CHANGE-REQUEST, this update does not seem corr= ect.
>>>>>>>
>>>>>>>
>>>>>>>>>>
>> ------------------------------------------------------------------= ---------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> =C2=A76.2.3 says:
>>>>>>>>>>
>>>>>>>>>>>=C2=A0 =C2=A0 Alternatively, a<= br> >>>>>>>>>>>=C2=A0 =C2=A0 client MAY be con= figured with a set of IP addresses that are
>>>>>>>>>>> trusted;
>>>>>>>>>>>=C2=A0 =C2=A0 if a certificate = is received that identifies one of those IP
>>>>>>>>>>>=C2=A0 =C2=A0 addresses, the cl= ient considers the identity of the server to
>> be
>>>>>>>>>>>=C2=A0 =C2=A0 verified.
>>>>>>>>>> Presumably, this means the server = supplies a certificate with
>>>>>>>>>> SubjectAltName
>>>>>>>>>> containing an iPAddress? Please ad= d text to clarify whether
>> that's the
>>>>>>>>>> intention.
>>>>>>>>>>
>>>>>>>>>> If that *is* the intended meaning,= then this behavior in =C2=A78.1
>> seems
>>>>>>>>>> unnecessarily restrictive:
>>>>>>>>>>
>>>>>>>>>>>=C2=A0 =C2=A0 A "stuns&quo= t; URI
>>>>>>>>>>>=C2=A0 =C2=A0 containing an IP = address MUST be rejected, unless the domain
>> name is
>>>>>>>>>>>=C2=A0 =C2=A0 provided by the s= ame mechanism that provided the STUN URI,
>> and that
>>>>>>>>>>>=C2=A0 =C2=A0 domain name can b= e passed to the verification code.
>>>>>>>>>> Presumably, this is done because c= erts with iPAddress-form
>>>>>>>>>> SubjectAltNames are
>>>>>>>>>> pretty rare (although CAB Forum ba= seline requirements do
>> explicitly
>>>>>>>>>> allow
>>>>>>>>>> their issuance) -- but if the text= in =C2=A76.2.3 is based on allowing
>>>>>>>>>> the use of
>>>>>>>>>> such certs in a TURN deployment, t= hen it seems that URI resolution
>>>>>>>>>> should be
>>>>>>>>>> also.
>>>>>>>>>>
>>>>>>>>> I am not sure what was the intent ther= e, so I'll work on that
>> later.
>>>>>>>> We addressed all the other comments, but i= t would be great if you
>>>>>>>> could suggest some text to address that on= e.
>>>>>>> I'm not sure what was meant either!
>>>>>>>
>>>>>>> I think we need to untangle what the working g= roup meant to say
>>>>>>> regarding "trusted IP addresses," th= e way this protocol is intended
>> to
>>>>>>> use certs, and whether the prohibition on usin= g IP addresses in
>> "stuns"
>>>>>>> URIs derives from cert handling or if it has a= completely different
>>>>>>> rationale behind it; and, if the former, ensur= e that those things
>> that
>>>>>>> are prohibited or allowed in certs are similar= ly prohibited or
>> allowed
>>>>>>> in URIs.
>>>>>>>
>>>>>>> I can suggest some *behavior*, but unless ther= e is some record of
>> what
>>>>>>> the WG meant, any such behavior would need to = be discussed by the
>>>>>>> working group, and a consensus would need to b= e declared by the
>> chairs.
>>>>>>>
>>>>>>>
>>>>>>> /a
>>>>>>>
>>>>>



--
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

--0000000000009628650577a978bf-- From nobody Tue Oct 9 10:30:42 2018 Return-Path: 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 8B2DE12D7EA; Tue, 9 Oct 2018 10:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no 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 tZ_llIQUDWYT; Tue, 9 Oct 2018 10:30:39 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2A6AB130DC8; Tue, 9 Oct 2018 10:30:39 -0700 (PDT) Received: from Svantevit.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w99HUa1Y019725 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 9 Oct 2018 12:30:37 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.roach.at To: Marc Petit-Huguenin , Gonzalo Camarillo , The IESG Cc: tram-chairs@ietf.org, draft-ietf-tram-stunbis@ietf.org, Tolga Asveren , tram@ietf.org References: <152403138853.31946.14807823535362928987.idtracker@ietfa.amsl.com> <27cb2f70-d907-b61f-bb5a-6b19053238fe@petit-huguenin.org> <1e8cd5de-06de-6745-fc4d-d15fcdd0b4d9@petit-huguenin.org> <5ff10fb0-301e-5d97-01b0-f15296bae0d3@nostrum.com> From: Adam Roach Message-ID: Date: Tue, 9 Oct 2018 12:30:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [tram] Adam Roach'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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 17:30:41 -0000 On 9/8/18 4:59 PM, Marc Petit-Huguenin wrote: > Also it seems that your DISCUSS is not related to that issue at all, would it be possible to clear it? Yes -- I've cleared the DISCUSS. /a From nobody Wed Oct 10 11:03:16 2018 Return-Path: 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 42750124D68 for ; Wed, 10 Oct 2018 11:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAyvkG2HdaEG for ; Wed, 10 Oct 2018 11:03:12 -0700 (PDT) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 6522A1200D7 for ; Wed, 10 Oct 2018 11:03:12 -0700 (PDT) Received: by mail-oi1-x236.google.com with SMTP id u74-v6so4831537oia.11 for ; Wed, 10 Oct 2018 11:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=hYy8YNPOmOGxcjXdAfU4nxM8Q40WMLsKXqDp56axNho=; b=iV3fCVHaXahpaaaWBMVL5Wx7F03kmBJhd9Ac+zJp5yjw5fUHfI8reAqgurA2bLad8r 91SYCYn8V/sP4eseXYItFiYC9JbSSQsbeL0JQEXqEG3TtBljP8PlhqLzjkxiwbk+FWPX 77HjCcLzU9+8/m16WgxqOzVEXPPNm6/K3rxkk++fpEbrfwrXWwqOViCq29qRv8hXDK1/ MZ9aMj6sICTfWHUZUEDVA3kTNaIip+0DQaL1NZjE3ZLuVD5xMsKNjSrNGgNYCtWqDOzE 9A8q1wgYmwFMatAMU6rfWKp5g7lS1CnahjjP1vwkHw1OfPCWHpHu0Zo2RGVR+r0AGKNy HlEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=hYy8YNPOmOGxcjXdAfU4nxM8Q40WMLsKXqDp56axNho=; b=aQppqKp8f2Dfw/acHS8OvYMD3Idd4gMDKwWIZRpsKJBa+Z/dR3AFJcfvxgMriisYli z2CPhEae2rplWX9etpKg4tfWL/zuub8RULWZCkScISbteTaXtw8emzyNR57BwdvBOchP 73XzOssGZlgqxoAt+QWFhwfQHsickUg2eOcBd/rLAyBl8Vojk+RY3MBT9I9yb+PzYOKI ZCDKNBYTnqPlib0MShvTSLR6Ajwp6NavCeDKbqNvr4mwVZM4QmwmP4tyS6QaoeRnf95k u+MpN04SPFyI3TUw1a8GChsLq5O8RoaNFIzL85gc9QCrzGgKZ9IEXibqXUwT6KrCsNEm uXBA== X-Gm-Message-State: ABuFfojUwFNJbp2nHRwxaqHlS7FkhgueJpM5FeqKjKZBlvTps67tUT0d wF73XSrVTkSUjxpABgDLdBI= X-Google-Smtp-Source: ACcGV61uLR7ItjauLft/Fm6F4cGnIo+afvjtNH/GcOK6BqPHOFOTaR22PgXumhSoTQltA4gHZNHFLw== X-Received: by 2002:aca:d6cd:: with SMTP id n196-v6mr2197658oig.32.1539194591561; Wed, 10 Oct 2018 11:03:11 -0700 (PDT) Received: from [192.168.86.140] ([75.111.77.103]) by smtp.gmail.com with ESMTPSA id u123-v6sm7303256oie.22.2018.10.10.11.03.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Oct 2018 11:03:10 -0700 (PDT) From: Dan Wing Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Wed, 10 Oct 2018 11:03:08 -0700 To: jonathan@vidyo.com, tram@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-19.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2018 18:03:14 -0000 Back on 13 August 2018, Jonathan Lennox wrote: > I=E2=80=99d also like to get security review of this change, = especially from the perspective of people running firewalls. >=20 > One of the design goals of TURN originally was that it behave like an = address-dependent filtering firewall / NAT =E2=80=94 you can=E2=80=99t = get incoming traffic from a peer you don=E2=80=99t already know about. = This was so it can=E2=80=99t be used to tunnel connections to an open = server behind a firewall, e.g. to allow a controller somewhere on the = open Internet to contact malware running inside a corporate network.=20 >=20 > Thus, network operators can be more confident about allowing TURN = traffic out through their firewalls.=20 >=20 > Permissionless ICE relay support breaks this guarantee, if you can = tunnel your traffic to make it look like ICE connectivity checks, and = I=E2=80=99m worried it will make operators less willing to allow TURN = out of their networks.=20 >=20 > Now, maybe the relevant operators are already not allowing TURN, or = there are already plenty of ways to tunnel in traffic, so this isn=E2=80=99= t a concern. But if we change this property, I=E2=80=99d like to make = sure we=E2=80=99re doing so with full consciousness and deliberation.=20 I was poking through STUNbis and TURNbis recently and thought of a = different approach. Prior to -19, TURN created permissions based on the remote IP address. = Could we create permissions based on the remote STUN Username? That = would avoid the "permissionless" problem, as the local peer (which = created the TURN allocation) knows half the STUN connectivity check = Username (the portion before the ":"), and can communicate that to the = TURN server to install what we might call a "username permission". The = TURN server could allow traffic that has (1) an IP permission or (2) is = STUN with a matching Username. We should be able to piggyback that = username onto the existing TURN allocation. Finally, considering ":" is = used for the local:remote STUN username, we might consider using another = character (e.g., "@") as a username prefix for the TURN server to allow, = so that the local client can use different STUN usernames for other = purposes. -d From nobody Fri Oct 12 02:40:27 2018 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B53DB130DED; Fri, 12 Oct 2018 02:40:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.86.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tram@ietf.org Message-ID: <153933722568.29237.7778013433015716917@ietfa.amsl.com> Date: Fri, 12 Oct 2018 02:40:25 -0700 Archived-At: Subject: [tram] I-D Action: draft-ietf-tram-turnbis-20.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 09:40:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized WG of the IETF. Title : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Authors : Tirumaleswar Reddy Alan Johnston Philip Matthews Jonathan Rosenberg Filename : draft-ietf-tram-turnbis-20.txt Pages : 85 Date : 2018-10-12 Abstract: If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it also can be used without ICE. This document obsoletes RFC 5766 and RFC 6156. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tram-turnbis-20 https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 12 02:42:31 2018 Return-Path: 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 7A696130E01 for ; Fri, 12 Oct 2018 02:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 R9-N6ETIi-Kb for ; Fri, 12 Oct 2018 02:42:28 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5F51130DED for ; Fri, 12 Oct 2018 02:42:27 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1539337360; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-ms-exchange-senderadcheck:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=o uXD4Igc7VLvw/g59IbSe6ZhRcuCPpaMAA1RSYt0Dm U=; b=M4K+nD930x5HDYNWuyjANS9xz25R1Zt4Xx/VAVHuemJP qZe4bwlonyVt1QMe9pIXKoyVt5rtYGr8kp6NuADiZSp/Q6fn2C DWOC8Omb1m0Fj5wDrEcLDqgYWoSt5ww99dMgsNiwGbk5QdHhyQ 2Vh6pARywmh0msyD+gtrlXTzDR4= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 0c89_5454_29125512_ec4a_4d2d_95ef_ab0ed76c1f57; Fri, 12 Oct 2018 04:42:39 -0500 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 12 Oct 2018 03:42:03 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 12 Oct 2018 03:42:03 -0600 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 12 Oct 2018 03:42:03 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1523.namprd16.prod.outlook.com (10.172.208.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1228.25; Fri, 12 Oct 2018 09:42:01 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::519f:c7ae:26de:272d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::519f:c7ae:26de:272d%2]) with mapi id 15.20.1228.020; Fri, 12 Oct 2018 09:42:01 +0000 From: "Konda, Tirumaleswar Reddy" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-20.txt Thread-Index: AQHUYg+5XwEpfRn/XECbT5ygSvhQJKUbWwGQ Date: Fri, 12 Oct 2018 09:42:01 +0000 Message-ID: References: <153933722568.29237.7778013433015716917@ietfa.amsl.com> In-Reply-To: <153933722568.29237.7778013433015716917@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.500.52 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1523; 6:oktRtPibyGAd2ka+dtel/3XwjW+i5nLWyN9EkledaXYCR7FG7sRVVTDLMZlln2yofUV+AUR9f08aAtAPDL3Ec0YTUvOa32sC37FXsStIe3CgM1MECmZgwQG1xMYEZGez6nU5//q6jCXxfX2oetMKUHD/meex2yZEbAdEXHScSSNZKmoP/Wmk+i2C/IpEhnM2eTehDWWpBlT9ymGOzzO4lmcFsAecCRCMSkpolAx+zvu808DB3xo3/+CXgjljLnF7HAg77VXj8NQXGXAqmRClVX1NnWLHcVq/zq2n71737nctF3V7Cne8IQtwubTib7oUkwOzjMwzGtxGOxBzBnWGPYFYuFxpq3Mu7+JuQGkDyOdyZvOgniLqJ8KlrWLUC+vkHigBdwmG2yhJ+vbrotm5lENvBeNxCBwS8+zEa9NndT5Lipd5Oa9TZH35dSBwZXogh6iUfLtKK5ZyKl5j/nR+Cw==; 5:k1US6+CwQRKpyF76iB8SP9+piFLPlARP0wZIXjLSq146Sikgk0tcHyo+LP9brdhhYxpEv+rsL5CGxJ7aYah/g0HV6kWhgo6letJfeA+xrCIxbPNChRwL37f7B7yS5ColU1eSV+T/YwciHGmeoqBK/adzj8CwH8Kr8urLTUZ4USg=; 7:rUJnkgOy8s4qgisqfLo/4rOo1+m2g8keb8wQXMS4+R9gdwHBbCE+GYsjsIiASqYDHEgrEvjoCtpiki1DVZO4wL58BF5LjSQXzJlpPYC8keewEEBGrynIIwQ2NOYamsO+HOCCd1W4ak7f6rwVCHd3FD1uJEtG2jX71ZDSg33WE8CEXt1165LeNS0W50w4IrefWTY86rp75t1ail3Yh38v3o2meQeTz3s4ebkQA+a28eC4PzyuPwMOHWrXYAgDvAA8 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 56570048-bf04-4641-ee9b-08d63026f64e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1523; x-ms-traffictypediagnostic: BN6PR16MB1523: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231355)(944501410)(52105095)(10201501046)(3002001)(93006095)(93001095)(149066)(150057)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(201708071742011)(7699051); SRVR:BN6PR16MB1523; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1523; x-forefront-prvs: 0823A5777B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(376002)(346002)(136003)(366004)(396003)(39860400002)(32952001)(13464003)(189003)(199004)(316002)(478600001)(5640700003)(5250100002)(33656002)(2501003)(186003)(72206003)(229853002)(106356001)(8936002)(2351001)(2906002)(26005)(14454004)(68736007)(8676002)(6436002)(966005)(6916009)(5024004)(81156014)(1730700003)(105586002)(81166006)(76176011)(7696005)(256004)(25786009)(305945005)(486006)(53936002)(5660300001)(53546011)(7736002)(102836004)(6116002)(3846002)(74316002)(86362001)(6246003)(80792005)(4001150100001)(9686003)(6306002)(6506007)(2900100001)(55016002)(11346002)(71200400001)(71190400001)(476003)(99286004)(66066001)(97736004)(446003)(85282002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1523; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: kmcWxI0g1xjhiALl+asdKBnInJcHRLv+Q8hd0Vwg9m+hI248NoWw9QxJU8Ca08iF5YL77lwEIJ/dGdns0ALgzX8MgS5vQdSOpevgmmr7ikg8tcOazATu8Hy6UHioMv+PB6xjyO9x763QGhZS6gnrI3MdOhgcvzjg4NjB1+o7Syc1vjjzJW/S17qeWj5YmJYlkZPZ50K8P+J89DhfFaRSgFz/2OFV6dD4ykJOzeVtOA5L36XQU4HOeDsz3VXA0+p1ZgqxXdUhl0pwfZgHgDXbl2YP27Wp0RRecw2CrRdSNNIClzLGCwTUggBCCOYkPtKc6A7NuuAWvkpFV11Z9w834Vk1Sz6rqPSkXbr8lXCptQw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 56570048-bf04-4641-ee9b-08d63026f64e X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2018 09:42:01.7020 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1523 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6393> : inlines <6928> : streams <1801083> : uri <2728786> Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-20.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 09:42:30 -0000 This revision addresses editorial comments from Dan. -Tiru > -----Original Message----- > From: tram On Behalf Of internet-drafts@ietf.org > Sent: Friday, October 12, 2018 3:10 PM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turnbis-20.txt >=20 > This email originated from outside of the organization. Do not click link= s or > open attachments unless you recognize the sender and know the content is > safe. >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the TURN Revised and Modernized WG of the > IETF. >=20 > Title : Traversal Using Relays around NAT (TURN): Relay > Extensions to Session Traversal Utilities for NAT (STUN) > Authors : Tirumaleswar Reddy > Alan Johnston > Philip Matthews > Jonathan Rosenberg > Filename : draft-ietf-tram-turnbis-20.txt > Pages : 85 > Date : 2018-10-12 >=20 > Abstract: > If a host is located behind a NAT, then in certain situations it can > be impossible for that host to communicate directly with other hosts > (peers). In these situations, it is necessary for the host to use > the services of an intermediate node that acts as a communication > relay. This specification defines a protocol, called TURN (Traversal > Using Relays around NAT), that allows the host to control the > operation of the relay and to exchange packets with its peers using > the relay. TURN differs from some other relay control protocols in > that it allows a client to communicate with multiple peers using a > single relay address. >=20 > The TURN protocol was designed to be used as part of the ICE > (Interactive Connectivity Establishment) approach to NAT traversal, > though it also can be used without ICE. >=20 > This document obsoletes RFC 5766 and RFC 6156. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tram-turnbis-20 > https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-20 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turnbis-20 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Mon Oct 15 05:22:32 2018 Return-Path: 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 3D094130E5D; Mon, 15 Oct 2018 05:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 OfmnNDApjOhT; Mon, 15 Oct 2018 05:22:22 -0700 (PDT) Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85CD128CE4; Mon, 15 Oct 2018 05:22:21 -0700 (PDT) Received: from [IPv6:2601:648:8400:8e7d:e8a4:7bee:f8e:19a6] (unknown [IPv6:2601:648:8400:8e7d:e8a4:7bee:f8e:19a6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 4A52FAE004; Mon, 15 Oct 2018 14:22:17 +0200 (CEST) To: Rohan Mahy Cc: Benjamin Kaduk , Adam Roach , Gonzalo Camarillo , The IESG , tram-chairs@ietf.org, draft-ietf-tram-stunbis@ietf.org, Tolga Asveren , tram@ietf.org References: <152403138853.31946.14807823535362928987.idtracker@ietfa.amsl.com> <27cb2f70-d907-b61f-bb5a-6b19053238fe@petit-huguenin.org> <1e8cd5de-06de-6745-fc4d-d15fcdd0b4d9@petit-huguenin.org> <5ff10fb0-301e-5d97-01b0-f15296bae0d3@nostrum.com> <20180909014711.GT73164@kduck.kaduk.org> <49512499-0e71-1f5b-e12c-213a3dd88d91@petit-huguenin.org> <7aacd118-e726-320b-2083-5ee89746c042@petit-huguenin.org> From: Marc Petit-Huguenin Openpgp: preference=signencrypt Autocrypt: addr=marc@petit-huguenin.org; prefer-encrypt=mutual; keydata= mQINBE6Mh9wBEADrUEDZChteJbQtsHwZITZExr7TAqT7pniNwhBX3nFgd+FrV3lsLKJ1rym2 52MAYpubXEJZGzMp6uCCAnROWbtmQbOm8z/jHnjxHhPqfuYCYPpAQqu8K/Sc194Rp37krMwB jz32yr7+gvWLzRgQGKIh9d2mzy8QLMETVWWQWGb6fEfpOxXo0wumN1rc/275kZwOu44JIPGg zbgwZdnEqYOUUa18K9MXeRDoWbwDISP30CvKuZDwD14lbBE3o7tBQrU9uoMhE7eFlTjbsCox qoubI2tZSuOTF8mRXjPmNrRGtf9mYkQnOB7y6qy/QxmOVMq4IRtHzOYIm/EZ6NTodcpZQHOM 2v6B6YK9uKrYrapSpJzn4f9oU7alT31Y3o2hOlxAWDQ16+Dd1MOPYsKQXOwY1/ihm4PTjiJ8 ud8yPzy7c+BSVs5wkBU6QuLNIgZHrrxdn+KxM+F/oAVtfzO7XzVoeOcXyWi3/CHL5pgoBruY enIF/RrRuplpy09pvZjmFPNfqKBYJGnqpQuqsQwO7LsFqDqfY2EuHg+KsGN1XuN+jxXc48/1 gCnKw7ALSPWEb7g25wD6KfiZTAcyRTG8LePNFQKhw61LbIWmkw9EaVLyXvwPTc1iCSc0dDT/ pcT/z+8xrWOyWGZNZAjR584NlDpKollbItcxYtFcYZkvTCmOVwARAQABtC1NYXJjIFBldGl0 LUh1Z3VlbmluIDxtYXJjQHBldGl0LWh1Z3VlbmluLm9yZz6JAjsEEwEIACUCGyMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheAAhkBBQJX8tdbAAoJECnERZXWan7EiNkQAIbS72cyalFjxQ1l vEW9S8NjjwIMbb5+NC2XqDakAmZq+Aav/Yfk8aEc+eAWBboVC3NBBjYojMRXK1XEnD7xPQ1X rWd23TDibKajy/2fo/MS9/s6uPFOAINi1ykOMq8ShxMHcIPC/dvVt59a7DV1KPGlnUheNR7N 4rIbkL5KndatD38yTGkyKsFvVKTHJn3y5zqHTGP0BjE1rxsGEBn4h+EzxVCIMVFQUeMVPKPV dlQY9fxdicSGPK2WKo1KL3CVpnYTuNCAVIGA9DPTXPPKvEte+/+xv10I03pj4w87iMUZt7Ca FTO55Gsf8hZvmpuB224yzrAbquA450EUVcQ7KAPcHrph5KAu0d3nwrjrUDn/RWWbyRiVrPtf hmnAAhkSv7oOxzyMdLvqt7XKGKbABhrl1ZRF8QbquOkyu8n3Bz2Osgw7JyFn9N6svlFPmpML UTEi64NewvN6zszKs/zBS6bn7na75gxHNvjSZpSF6uSLYgmKbyG8vkY/i0s0e0njjOHcpNx1 0mNZ+wOoCgHtSCZFyv14ncioJTiSjtZCs+srW9PFlbOg73C1Op42xV5Y+dh/mCC+rweKtB3t yTAy52v8vPG0VjsLS52x6yUsoDjYV33AmTEaWmGzN5t8BX/qh7pgNIEd9TEwrR3B4LjqMmUk XXWSJG5IM8Zr2OE/t2vyuQINBE6Mh9wBEAC/i4Lh4XEgwi/yHr3XLx/+f38ztn5rrk8XRsK2 WUpu5evxw9iK2oelqWtS71XkW57EavJOjvP4t8FWqRKED5jWN741n12iW/EeLx3KoHMcPTfY 4WWvprxiZPfnCIpQ8j8x0QQSA+Hf96BSkAkOGNkiJDuus5z4XwTktn9gFOwLVx4VRMo+lrCy um6BDHI+4/sOWnrNp2WptI4YKM/uA0HpuLpPKLra0ZW6Bp2TewNpAjbst/VHjqewab0PeSCn CQiHkqIibdgOATT0K6KoVtMxp/WPRSfVImfWCHjT2G7HFMcb6w/jlPSb+u4VtL9yn76CCg8F SqTtzFuqPtbXkhrdSgks/grxiQryMXwpO0uSuUgZ3u2TSs+65Bl2CM5cq+2aBIER5qhpnCv7 B00uHuoNqUEK0VEpLKcqi2ZeVM5oO8iOaBgS9Gh082HQ5JDijEV2J5e4rwXjbRnJ4hqpTjSy caW8HnPI+4S0aqVxbnqW7T6l/xnn7ivK3aPqaRKqUSedHCU3oHIU31n0o5+f5htQeDs/Tpzn ARHkyzu9vZ9CvQXk8daZorA+j/38q6mWU6Mw8FRIu1qPQDmqljobk3vC9BZRSJOn3P8jNMM7 w1j+7Da3rxGBylfa3fmHPyY7dvdyeLmsq7egzTJkpAMN55Qat7iuXeeCdBQLAFHLBP1tvwAR AQABiQIfBBgBCAAJAhsMBQJX8tdcAAoJECnERZXWan7EkMgP/isd3lrSsm/8t+U44LY0/x67 cPmiKa9biveywJZ9Y+Zu/pUP44dP670mY7PmEDGC6lRiPKGmhf7vqq6JJFOqX64VWePQ9QZp kkzAUmIJwQ2Kmcmfrs0J5w2Lf5qaNji25fQYbon0eUFy6eN3BNRSIcg0+OsH7HubTWfpZeJu B7V7k8OFt2+HDx7aNdNutDJIu4V25AzGfonARQzJK62cmB0pwYXpcyDO152OwP12XbpXxXA1 xHGYQBRL98pSbMU5xsMw8j9VQHQRS94aT9Qqnz9SrYuISnMV2WGyIE0rAY3GGz3IcN5LVE1N vSP51ih+YJg/qsBYs8obbfEIZelOuznWf120RgV7P+7ZWCSBohmchuyELQzl9D7FXfulkXA3 RapKQcGJMVPIHYgnlvmE0OXfJl1z09nYRQHitoQhWtviHWl7x/KL42aUzHirLR61iVA2kqkO BhU+u+g2w8qrZj+lJfXIxlbVyLOuBVqkfcK28AR9RriB4Q5hvbDeQJMgfZsV2hBt7huBOqkH nnbSCguqfnmwLGkxoM7RVjCQwvC1M57uwdKMlsTVaBP0RreZnrDngLamK+ibXYe7p8pPAWD9 cuHvkkjML7cIfuvbScDYRmGzia3V9+LVzQCm+q/6xUY1SZvrDz7OaJOy3Xb1d+aPhYaNC0TQ 7IqA1dx8rZYQ Message-ID: Date: Mon, 15 Oct 2018 05:22:09 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="38UYEwX2bHVRPvJcwrRiyOaYwDylyb7SX" Archived-At: Subject: Re: [tram] Adam Roach'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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 12:22:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --38UYEwX2bHVRPvJcwrRiyOaYwDylyb7SX Content-Type: multipart/mixed; boundary="Lias9ar0BH8bvd4EiOkJxbgVVRg8eKR7F"; protected-headers="v1" From: Marc Petit-Huguenin To: Rohan Mahy Cc: Benjamin Kaduk , Adam Roach , Gonzalo Camarillo , The IESG , tram-chairs@ietf.org, draft-ietf-tram-stunbis@ietf.org, Tolga Asveren , tram@ietf.org Message-ID: Subject: Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) References: <152403138853.31946.14807823535362928987.idtracker@ietfa.amsl.com> <27cb2f70-d907-b61f-bb5a-6b19053238fe@petit-huguenin.org> <1e8cd5de-06de-6745-fc4d-d15fcdd0b4d9@petit-huguenin.org> <5ff10fb0-301e-5d97-01b0-f15296bae0d3@nostrum.com> <20180909014711.GT73164@kduck.kaduk.org> <49512499-0e71-1f5b-e12c-213a3dd88d91@petit-huguenin.org> <7aacd118-e726-320b-2083-5ee89746c042@petit-huguenin.org> In-Reply-To: --Lias9ar0BH8bvd4EiOkJxbgVVRg8eKR7F Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Rohan, Thanks, I added your text verbatim to the end of the first paragraph of s= ection 8.1. I will publish -19 in few minutes. On 10/7/18 1:37 PM, Rohan Mahy wrote: > If we think this might happen we could add: "A future STUN extension or= > usage may relax this requirement provided it demonstrates how to > authenticate the STUN server and prevent man in the middle attacks." > Thanks, > -rohan >=20 > On Sun, Oct 7, 2018, 08:17 Marc Petit-Huguenin > wrote: >=20 >> On 10/07/2018 08:05 AM, Rohan Mahy wrote: >>> [snip] >>>>> using https, that the hostname verification for the https certifica= te >>>>> implies that the stuns URI embedded in the document are receiving >>>>> adequate protection and can be used without worrying about the lack= of >>>>> certificate verification for the stuns URI. >>>>> >>>>> Now that is an assumption that we made, and we'd very much like to = hear >>>>> if that assumption is incorrect. >>>> >>>> Note that I may be lacking full context, but based just on your >>> description >>>> above and =C2=A7 8.1 of the -18, I am concerned about your statement= "without >>>> worrying about the lack of certificate verification for the stuns UR= I". >>> My >>>> understanding is, that given a stuns URI with an IP address for the = host >>>> and some domain name specified by the same mechanism that provided t= he >>> URI, >>>> is that this domain name would then be used as input to the serverna= me >>>> verification process for the new connection using this stuns URI. Y= our >>>> statement that I quote here makes it sound like no certificate >>> verification >>>> is done on this second connection, which would seem to make it >> vulnerable >>>> to a MITM attack (and thus be a bad idea). >>> >>> Probably too late now, but if you wanted to be able use a stuns: URI >> safely >>> with an IP address, you could use a fingerprint URI parameter to prev= ent >>> MITM. This would work as long as you received the URI over an >> authenticated >>> channel (ex: https:, sip: + S/MIME, and possibly sips:). >> >> Yes but, as you said, it is too late now for stunbis and TRAM. Maybe = in a >> draft in 2019... >> >>> Thanks, >>> -rohan >>> >>> On Sun, Oct 7, 2018 at 5:48 AM Marc Petit-Huguenin < >> marc@petit-huguenin.org> >>> wrote: >>> >>>> Hi Benjamin, >>>> >>>> See inline. >>>> >>>> On 09/08/2018 06:52 PM, Benjamin Kaduk wrote: >>>>> Hi Marc, >>>>> >>>>> On Sat, Sep 08, 2018 at 02:59:41PM -0700, Marc Petit-Huguenin wrote= : >>>>>> Hi Adam, >>>>>> >>>>>> Apologies for the delay in working on that. >>>>>> >>>>>> For the first issue, the fix is in my copy of the draft. >>>>>> >>>>>> As for the second issue, Section 8.1 says: >>>>>> >>>>>> 'A "stuns" URI >>>>>> containing an IP address MUST be rejected, unless the domain name= is >>>>>> provided by the same mechanism that provided the STUN URI, and th= at >>>>>> domain name can be passed to the verification code.' >>>>>> >>>>>> That text was never about IP addresses in certificates, but about = the >>>> way a STUN (or TURN really, but that draft does not care about TURN)= >> server >>>> IP address is passed to a WebRTC browser. RFC 7064 permits to store= an >> IP >>>> address directly inside a stun URI, and RFC 7350 extended that to st= uns >>>> URI, and in fact the text above is directly copied from RFC 7350. >>>>>> >>>>>> The idea is that a stun URI can be provisioned by a JavaScript pro= gram >>>>>> downloaded by a WebRTC browser as part of the initialization of a >> WebRTC >>>>>> application. A security assumption is that using a stuns URI that= >>>>>> contains an API address is safe if the Javascript program was >> downloaded >>>>> ^^^ >>>>> (I assume this is autocorrect picking the wrong thing to fix a typo= and >>>>> should be "IP Address") >>>> >>>> Yes. But no auto-correct feature was to blame in that case. >>>> >>>>> >>>>>> using https, that the hostname verification for the https certific= ate >>>>>> implies that the stuns URI embedded in the document are receiving >>>>>> adequate protection and can be used without worrying about the lac= k of >>>>>> certificate verification for the stuns URI. >>>>>> >>>>>> Now that is an assumption that we made, and we'd very much like to= >> hear >>>>>> if that assumption is incorrect. >>>>> >>>>> Note that I may be lacking full context, but based just on your >>>> description >>>>> above and =C2=A7 8.1 of the -18, I am concerned about your statemen= t >> "without >>>>> worrying about the lack of certificate verification for the stuns U= RI". >>>> My >>>>> understanding is, that given a stuns URI with an IP address for the= >> host >>>>> and some domain name specified by the same mechanism that provided = the >>>> URI, >>>>> is that this domain name would then be used as input to the servern= ame >>>>> verification process for the new connection using this stuns URI. = Your >>>>> statement that I quote here makes it sound like no certificate >>>> verification >>>>> is done on this second connection, which would seem to make it >> vulnerable >>>>> to a MITM attack (and thus be a bad idea). >>>> >>>> You are right. I am not sure if there is an easy way to fix that bu= t if >>>> someone figure that out it can be spelled out in a separate draft. >>>> Meanwhile I updated the text in the new version of the draft as foll= ow: >>>> >>>> "If the part of a "stun" URI contains an IP address, then thi= s >>>> IP address is used directly to contact the server. A "stuns" URI >>>> containing an IP address MUST be rejected." >>>> >>>>> >>>>> -Benjamin >>>>> >>>>>> Section 6.2.3 is unrelated - it is about IP addresses provisioned >>>> locally (not received from the server), and a matching certificate >>>> containing IPAddress. I'll make that more explicit after I receive = your >>>> response on the subject above. >>>>>> >>>>>> Also it seems that your DISCUSS is not related to that issue at al= l, >>>> would it be possible to clear it? >>>>>> >>>>>> Thanks. >>>>>> >>>>>> On 06/18/2018 10:45 AM, Adam Roach wrote: >>>>>>> Gonzalo: >>>>>>> >>>>>>> TL;DR -- unless someone can find evidence indicating what the WG >>>> intended, I believe we are waiting on you and Simon. >>>>>>> >>>>>>> I had two responses in my most recent message. I presume the firs= t >>>> should be uncontroversial. >>>>>>> >>>>>>> The second point pertains to how the working group intended to tr= eat >>>> IP addresses in STUNS URIs. The document right now is ambiguous and >>>> self-contradictory. If this has been discussed in the past, then the= >>>> document simply needs to be updated to reflect the outcome of that >>>> conversation. If not, then I believe the WG needs to have a conversa= tion >>>> about what is intended. >>>>>>> >>>>>>> As it stands, the document will lead to various notions about whe= ther >>>> (and how) IP addresses can be used, which will be an interop nightma= re. >>>>>>> >>>>>>> /a >>>>>>> >>>>>>> On 6/18/18 05:41, Gonzalo Camarillo wrote: >>>>>>>> Marc, Adam, >>>>>>>> >>>>>>>> what is the status of this discussion? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Gonzalo >>>>>>>> >>>>>>>> On 21/05/2018 9:11 PM, Adam Roach wrote: >>>>>>>>> Sorry for taking so long to get back to you on this. Two respon= ses >>>> below >>>>>>>>> -- everything else looks good. >>>>>>>>> >>>>>>>>> On 5/3/18 6:37 PM, Marc Petit-Huguenin wrote: >>>>>>>>>> On 04/23/2018 03:37 PM, Marc Petit-Huguenin wrote: >>>>>>>>>>>> >>>> >> ----------------------------------------------------------------------= ----- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> =C2=A717.3.1: >>>>>>>>>>>> >>>>>>>>>>>>> IANA is requested to update the names for attributes 0x0= 002, >>>> 0x0003, >>>>>>>>>>>>> 0x0004, 0x0005, 0x0007, and 0x000B, and the reference fr= om >>>> RFC 5389 >>>>>>>>>>>>> to RFC-to-be for the following STUN methods: >>>>>>>>>>>> ... >>>>>>>>>>>>> 0x0003: (Reserved; prior to [RFC5389] this was >> CHANGE-REQUEST) >>>>>>>>>>>> The attribute 0x0003 is registered by RFC 5780, and should n= ot >> be >>>>>>>>>>>> removed by this document. >>>>>>>>>>> Fixed. >>>>>>>>> >>>>>>>>> Thanks for the change, but the new text still asks IANA to upda= te >> the >>>>>>>>> table so that 0x0003 points to *this* document, instead of >>>> continuing to >>>>>>>>> point to RFC 5780. Since this document does not do anything wit= h >>>>>>>>> CHANGE-REQUEST, this update does not seem correct. >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> >>>> >> ----------------------------------------------------------------------= ----- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> =C2=A76.2.3 says: >>>>>>>>>>>> >>>>>>>>>>>>> Alternatively, a >>>>>>>>>>>>> client MAY be configured with a set of IP addresses that= are >>>>>>>>>>>>> trusted; >>>>>>>>>>>>> if a certificate is received that identifies one of thos= e IP >>>>>>>>>>>>> addresses, the client considers the identity of the serv= er >> to >>>> be >>>>>>>>>>>>> verified. >>>>>>>>>>>> Presumably, this means the server supplies a certificate wit= h >>>>>>>>>>>> SubjectAltName >>>>>>>>>>>> containing an iPAddress? Please add text to clarify whether >>>> that's the >>>>>>>>>>>> intention. >>>>>>>>>>>> >>>>>>>>>>>> If that *is* the intended meaning, then this behavior in =C2= =A78.1 >>>> seems >>>>>>>>>>>> unnecessarily restrictive: >>>>>>>>>>>> >>>>>>>>>>>>> A "stuns" URI >>>>>>>>>>>>> containing an IP address MUST be rejected, unless the do= main >>>> name is >>>>>>>>>>>>> provided by the same mechanism that provided the STUN UR= I, >>>> and that >>>>>>>>>>>>> domain name can be passed to the verification code. >>>>>>>>>>>> Presumably, this is done because certs with iPAddress-form >>>>>>>>>>>> SubjectAltNames are >>>>>>>>>>>> pretty rare (although CAB Forum baseline requirements do >>>> explicitly >>>>>>>>>>>> allow >>>>>>>>>>>> their issuance) -- but if the text in =C2=A76.2.3 is based o= n >> allowing >>>>>>>>>>>> the use of >>>>>>>>>>>> such certs in a TURN deployment, then it seems that URI >> resolution >>>>>>>>>>>> should be >>>>>>>>>>>> also. >>>>>>>>>>>> >>>>>>>>>>> I am not sure what was the intent there, so I'll work on that= >>>> later. >>>>>>>>>> We addressed all the other comments, but it would be great if = you >>>>>>>>>> could suggest some text to address that one. >>>>>>>>> I'm not sure what was meant either! >>>>>>>>> >>>>>>>>> I think we need to untangle what the working group meant to say= >>>>>>>>> regarding "trusted IP addresses," the way this protocol is inte= nded >>>> to >>>>>>>>> use certs, and whether the prohibition on using IP addresses in= >>>> "stuns" >>>>>>>>> URIs derives from cert handling or if it has a completely diffe= rent >>>>>>>>> rationale behind it; and, if the former, ensure that those thin= gs >>>> that >>>>>>>>> are prohibited or allowed in certs are similarly prohibited or >>>> allowed >>>>>>>>> in URIs. >>>>>>>>> >>>>>>>>> I can suggest some *behavior*, but unless there is some record = of >>>> what >>>>>>>>> the WG meant, any such behavior would need to be discussed by t= he >>>>>>>>> working group, and a consensus would need to be declared by the= >>>> chairs. >>>>>>>>> >>>>>>>>> >>>>>>>>> /a >>>>>>>>> --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --Lias9ar0BH8bvd4EiOkJxbgVVRg8eKR7F-- --38UYEwX2bHVRPvJcwrRiyOaYwDylyb7SX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlvEhnIACgkQKcRFldZq fsTeLA/9EWfjGnuo3jKN6slsURKMdop2LG/+7d7htLNr8I7DWyzPOui2dgObMxLK rZwTf9wSaWo+6XmnS+VeUIHDPWJXkT2djLHz5ig92qLxnGCAV5/1LI9+RESYYfwB kjbBan6vQigzw6Jca/78e0hgTQq8qYLCwdwlylcG8xTHQeNo6GOSgvTvVoLZIGyV VvM9ECrRoYRLRt6s9CiOoZREvTVvhV/VULMvjvp0ptlomlZtHSrgesouMqRsKdbN fllPFqEgEtuenvMM3Fe3YnOpG+A9cFjSVxw8wFqvWj6Tqt6TEKMsqOQq0dwiPyWd zj+3ku85ran+0AgLtLsIpTtaXxrz28jl70zFfSYrOQfbi0MnE5rumnDpuZ8+nGxw 4oayuE/i63obd60YYj+9j6hv30WTbvCn1TP0Th/+B+7GCluIr1y9VoPAwTnMn/yQ LV+Tsf9P9x5+O6qlv6kdK9Iy2nKxVzjYaE4VkbIo1dRmqjvpTu3rlKZpEo1LaG8o T1kuGY/xjGCEKT00+SJ8GRm6fPXUGZHTzy7QKmog5atG5Mehei983svSuwbp2JsW O0xlqW/txgXsP+0gcYMShrpC+2+AeBae65KhuH7aqlzcLIIiP4/twWyLIh17IlCa Ude5X0D9/fVay0MdArRne2PXjMtm35BDb0MaVIZCVIPJa6/cF5k= =U7ah -----END PGP SIGNATURE----- --38UYEwX2bHVRPvJcwrRiyOaYwDylyb7SX-- From nobody Mon Oct 15 05:34:00 2018 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D64AF130E68; Mon, 15 Oct 2018 05:33:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.86.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tram@ietf.org Message-ID: <153960683277.4553.16546858358730968554@ietfa.amsl.com> Date: Mon, 15 Oct 2018 05:33:52 -0700 Archived-At: Subject: [tram] I-D Action: draft-ietf-tram-stunbis-19.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 12:33:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized WG of the IETF. Title : Session Traversal Utilities for NAT (STUN) Authors : Marc Petit-Huguenin Gonzalo Salgueiro Jonathan Rosenberg Dan Wing Rohan Mahy Philip Matthews Filename : draft-ietf-tram-stunbis-19.txt Pages : 72 Date : 2018-10-15 Abstract: Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This document obsoletes RFC 5389. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tram-stunbis-19 https://datatracker.ietf.org/doc/html/draft-ietf-tram-stunbis-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 23 19:28:58 2018 Return-Path: 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 0FE24130DD2; Tue, 23 Oct 2018 19:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA0IwEBdr9-v; Tue, 23 Oct 2018 19:28:46 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 65089130E5A; Tue, 23 Oct 2018 19:28:45 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id t22-v6so3256285lji.7; Tue, 23 Oct 2018 19:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QkTRLklKSZ8BhB6oEf2tcY4bUFUq4rnZj+fHw2tEXSY=; b=d61HmuN1+fbhydUBbEpQto632DYKOpyAMJaA9Ed9U2Ru9E+VCbPGYoHyjJE+kzyCTx PpqQ3iL0sABj5PMNKZcDVjvcdy0Or3eVXyz/kwjS9sE1FQj3Cu4t62M2j2TQU3wwwWvS ZBQvr0P02EyhgQCUtK7WFn4iDpQJxvmG+jJ+YlmMfeXIwkln3VG+V4LM0FnTdbj8gCh7 2VIt5G5DALRyg/zC6LpG2NeZyTsXYLxKBKqtcOaVbKbWXjjc6tFJKW360VJhiTBN2hqB 2VurYH1LW6LGTgR0lFX2kN52GINPhes2fBFgPKh1GYohQb4KndoaFFQg5guN688zCqPa vWeQ== 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=QkTRLklKSZ8BhB6oEf2tcY4bUFUq4rnZj+fHw2tEXSY=; b=S+C3Kl5bYGalCsw3tdxAffFYQjjDEr7lP3MLFNJ1EcAQ0DSHt5ISfIhAzrF0JI5XI2 5KrcZ+PNLYPfiHylbRdci2c9AKmAemgjpHJxS4t4vpx3TbgtmPoqRHuEEOtztnbLAWT8 2MCncp7RMg0HFO6yc7pZ0kgDg9nArdbI9FmwGoTvgrFdOBEokBk6fTyOvEqcydwQUlyx kEedwj4uBlpbVWFIiCypBfoyCZDINYjrK5GONuflGHxW9HcBr21A30GdefhGuXD6cJJv YJm+8miJxwO/A1PCu0BlQ9pKWInQsIPS77yfaK2hFywC/c4wyEzWxa+KgNs4ID+hc4T2 c54w== X-Gm-Message-State: AGRZ1gLCczmsW2hKXME69DodtSTvwcgjvtLFyWo4bSxTo8HpU0PaAxuX jD+7Y4OQTXNGN8s3U71CVzM3ziCc43LdR4a6dJg= X-Google-Smtp-Source: AJdET5eyuwkl9yA82ApflAcx9KyjZslREBt3PHeLvC8m4OjHJL98UEVFfm/5rbisVTYTPqLTJ0QdPLBh3DXPKbKDyVo= X-Received: by 2002:a2e:93ca:: with SMTP id p10-v6mr440618ljh.158.1540348123257; Tue, 23 Oct 2018 19:28:43 -0700 (PDT) MIME-Version: 1.0 References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <02569943-db8f-654e-7322-49bc1f1a1163@acm.org> <235b838f-2800-2cd0-8b01-947e70837619@ericsson.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Tue, 23 Oct 2018 21:28:29 -0500 Message-ID: To: Marc Petit-Huguenin Cc: Eric Rescorla , tram-chairs@ietf.org, tram@ietf.org, Gonzalo Camarillo , "Asveren, Tolga" , IESG , draft-ietf-tram-stunbis@ietf.org Content-Type: multipart/alternative; boundary="000000000000b79f930578f03e57" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 02:28:51 -0000 --000000000000b79f930578f03e57 Content-Type: text/plain; charset="UTF-8" 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 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 > > 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> 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 > >>>>> > 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 > > >>>>> > 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 > >>>>> >> 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 > Blog: https://marc.petit-huguenin.org > Profile: https://www.linkedin.com/in/petithug > > --000000000000b79f930578f03e57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Marc,=C2=A0

I see that a -19 has be= en submitted, but didn't see a reply from Eric in this thread. Do you t= hink that you've converged?=C2=A0

(I saw an of= fer of a conference call, so thought an out-of-band conversation might have= happened)

Thanks,

Spence= r

On Sun, Oct 7, = 2018 at 9:35 AM Marc Petit-Huguenin <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>
> wrote:
>
>> Hi Eric,
>>
>> Apologies for the delay in getting back to that.
>>
>> I think that there is some misunderstanding in what STUNbis is try= ing 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 h= ere, though SHA-1
>>> isn't a great choice
>>> either for pwd hashing You want Argon or the like. With that s= aid,
>> there's
>>> no sensible
>>> biddown attack on that hash because it's a per-server feat= ure, not a
>>> per-transaction
>>> feature. So, as long as the server has MD5-hashed passwords, t= he
>> situation
>>> is bad.
>>
>> In no place in STUNbis we are proposing to use SHA-1 for password<= br> >> encryption, so I am not sure where that come from.=C2=A0 What we p= ropose is:
>>
>
> You're right, it's SHA-256, but my criticisms apply equally th= ere.

SHA-256 was what the WG adopted.=C2=A0 Our attempts to add other passwords = encryption mechanisms were denied.=C2=A0 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.=C2=A0 Anyw= ay it is too late to fix this, as it is my understanding that the WG does n= ot have enough energy to reach consensus on a new password algorithm.=C2=A0= 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 wor= king
>> group).
>> - Add a new password algorithm to that registry, namely SHA-256. >> - Register MD5 as an initial password algorithm for backward compa= tibility
>> purpose.
>>
>> As for the biddown protection itself, it is my recollection that i= t
>> happened more or less like that:
>>
>>
>> INT. MEETING ROOM - DAY
>>
>> One of the co-editors of STUNBis stands at the microphone:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CO-EDITOR
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 We a= dded SHA-256 protection for passwords
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in S= TUNBis.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SOMEONE (V.O.)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 As M= D5 still need to be supported, you need to add
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 prot= ection for bid-down attacks.
>>
>> CLOSE-UP on CO-EDITOR ROLLING HIS EYES
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CO-EDITOR
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 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:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CO-EDITOR
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 We a= dded a nice mechanism to prevent bid-down
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 atta= cks on passwords.=C2=A0 Any comments?
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 THE ROOM
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (sil= ence)
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CO-EDITOR
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Movi= ng on...
>>
>
> I don't see how any of this is relevant to my technical points abo= ve.

My point was that we, the co-editors, did not decide on adding bid-down pro= tection, someone asked us to do so and no-one in the WG saw any problem wit= h that.=C2=A0 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 r= e-encrypted at once.=C2=A0 Also for operational reasons, the MD5 password c= annot be immediately removed from the database as soon the user submitted a= new one.=C2=A0 In fact, and for quite some time, both encrypted variants o= f 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, so= me that use a STUNbis client.=C2=A0 It is up to the STUN server owner to de= cide how long the migration to STUNbis will take and when it will be accept= able 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 passwo= rd encryption algorithm.=C2=A0 That's where the biddown protection kick= s 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 h= ave the client misidentifying a STUNbis server as a RFC 5389 server, and ha= ving both them use the MD5 encrypted password instead of the SHA-256 encryp= ted password, all of that easily done by stripping the unprotected 401 resp= onse 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 i= s also used
>>> to compute
>>> MAC over the negotiation: an attacker who has compromised a MA= C which the
>>> server
>>> supports will quite likely be able to forge a MAC over the tra= nscript 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 Se= ction
>> 16.3:
>>
>> "The bid-down protection mechanism described in this document= is new,
>>=C2=A0 and thus cannot currently protect against a bid-down attack = that
>>=C2=A0 lowers the strength of the hash algorithm to HMAC-SHA1."= ;
>>
>> What we put in place is a plan for *future* versions of STUN to ge= t
>> biddown protection for the MAC.=C2=A0 That's it, no more, no l= ess.
>>
>
> Yes, but I don't believe that this will provide bid-down protectio= n for the
> MAC in the future for the reasons I indicate above.
>
> If you think this does something useful, please show me an example att= ack
> 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 exploi= t in
> some other way.

I do not know what weaknesses will be discovered in the future.=C2=A0 I am = also pretty sure that the cost of not using that mechanism is very close to= 0.=C2=A0 What I am sure of is that the cost of reengineering a new biddown= protection mechanism if we ever need it will be high.=C2=A0 We already wen= t 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 rever= se 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> 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>> wrote:
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0On 04/22/2018 05:22 PM, Eric Rescor= la wrote:
>>>>>=C2=A0 =C2=A0 =C2=A0> On Sun, Apr 22, 2018 at 2:02 P= M, Marc Petit-Huguenin <
>>>> peti= thug@acm.org <mailto:petithug@acm.org>>
>>>>>=C2=A0 =C2=A0 =C2=A0> wrote:
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 For a request or indication message, the agent MUST
>>>> include the
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGRITY
>>>>>=C2=A0 =C2=A0 =C2=A0>> attributes
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 in the message unless the agent knows from an external
>>>> indication
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 which message integrity algorithm is supported by both
>>>> agents.=C2=A0 In
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 this case either MESSAGE-INTEGRITY or
>>>> MESSAGE-INTEGRITY-SHA256 MUST
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 be included in addition to USERNAME.=C2=A0 The HMAC for the
>>>> MESSAGE-
>>>>>=C2=A0 =C2=A0 =C2=A0>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>> This text appears to c= onflict with S 7.3 of 5245-bis, which
>> says:
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>> [text missing]
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>> Hmm, no, RFC245bis is stil= l referencing RFC5389, so the
>> procedure
>>>> for
>>>>>=C2=A0 =C2=A0 =C2=A0>> stunbis does not apply. >>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>=C2=A0 =C2=A0 =C2=A0> I hear what you're saying,= but publishing two documents at the
>>>> same time
>>>>>=C2=A0 =C2=A0 =C2=A0> which
>>>>>=C2=A0 =C2=A0 =C2=A0> make contrary recommendations = about the same basic protocol is
>>>> un-good.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0Sure, but wouldn't it be simple= r to have rfc5245bis using stunbis
>>>>>=C2=A0 =C2=A0 =C2=A0and have them updating their text, = more than adding some tortuous
>>>>>=C2=A0 =C2=A0 =C2=A0text in stunbis?
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 Th= e STUN usage must specify which transport protocol is
>>>> used, and
>>>>>=C2=A0 =C2=A0 =C2=A0>> how
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 the agent determines the IP address and port of the
>>>> recipient.
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 Section 8 describes a DNS-based method of determining the
>>>> IP
>>>>>=C2=A0 =C2=A0 =C2=A0>> address
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 and port of a server that a usage may elect to use.=C2=A0 STUN
>>>> may be
>>>>>=C2=A0 =C2=A0 =C2=A0>> used
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 with anycast addresses, but only with UDP and in usages
>>>> where
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 authentication is not used.
>>>>>=C2=A0 =C2=A0 =C2=A0>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>> Why this restriction? = You should be able to use anycast with
>>>> long-term
>>>>>=C2=A0 =C2=A0 =C2=A0>>> AUTH for (say) TURN. >>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>> https://www.ietf.org/mail-archive/web/behave/current/
>>>> msg03582.html
>>>>>=C2=A0 =C2=A0 =C2=A0<htt= ps://www.ietf.org/mail-archive/web/behave/current/
>> msg03582.html>
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>> I think that the decision = of permitting Anycast should be left
>> to
>>>> each
>>>>>=C2=A0 =C2=A0 =C2=A0>> STUN Usage.=C2=A0 Basic ST= UN Usage does not use authentication and
>> use
>>>> only a
>>>>>=C2=A0 =C2=A0 =C2=A0>> one round trip for the Bin= ding transaction, so Unicast can be
>>>> used.
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>=C2=A0 =C2=A0 =C2=A0>> OTOH, TURN and ICE should = probably say something about that, so
>> I
>>>> added a
>>>>>=C2=A0 =C2=A0 =C2=A0>> new bullet point in Sectio= n 13:
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 o=C2=A0 If An= ycast addresses can be used for the server in case
>> TCP
>>>> or
>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0= TLS-over-TCP, or authentication are used.
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>=C2=A0 =C2=A0 =C2=A0> Are you leaving this text in? = That seems very confusing.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0In isolation yes, but I think it ma= kes sense which the text before
>>>>>=C2=A0 =C2=A0 =C2=A0the bullet points:
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 A STUN usage defines how ST= UN is actually utilized -- when to
>> send
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 requests, what to do with t= he responses, and which optional
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 procedures defined here (or= in an extension to STUN) are to be
>>>> used.
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 A usage also defines:
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0[...]
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 o=C2=A0 If Anycast addresse= s can be used for the server in case TCP
>> or
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TLS-over-TCP, = or authentication are used.
>>>>>
>>>>>
>>>>> What is the need for the restriction at all.
>>>>>
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 transaction over UDP or DTLS-over-UDP is also considered
>>>> failed if
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 there has been a hard ICMP error [RFC1122].=C2=A0 For example,
>>>> assuming
>>>>>=C2=A0 =C2=A0 =C2=A0>> an
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 RTO of 500ms, requests would be sent at times 0 ms, 500
>>>> ms, 1500
>>>>>=C2=A0 =C2=A0 =C2=A0>> ms,
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 3500 ms, 7500 ms, 15500 ms, and 31500 ms.=C2=A0 If the client
>>>> has not
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 received a response after 39500 ms, the client will
>>>> consider the
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 transaction to have timed out.
>>>>>=C2=A0 =C2=A0 =C2=A0>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>> I note that these reco= mmendations now seem crazily long. I
>>>> assume the
>>>>>=C2=A0 =C2=A0 =C2=A0>>> WG had consensus on th= is, but I wanted to note it.
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>> Not just the WG, also the = IESG that approved RFC 5389 too as,
>> but
>>>> for the
>>>>>=C2=A0 =C2=A0 =C2=A0>> addition of "or DTLS-= over-UDP", this is the same text than in
>> RFC
>>>> 5389.
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>=C2=A0 =C2=A0 =C2=A0> Yes, I know. My point is that = while they might have bee sensible
>>>> when
>>>>>=C2=A0 =C2=A0 =C2=A0> 5389 was published they *now* = seem crazily long. Did the WG
>>>> explicitly
>>>>>=C2=A0 =C2=A0 =C2=A0> decide not to update them?
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0No, nobody ever suggested that ther= e was an issue there.
>>>>>
>>>>>
>>>>> OK, well, this seems like it should be considered, the= n, because this
>>>>> doesn't
>>>>> match modern practice.
>>>>>
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0> This would be good to explain.=
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0New text:
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 [...]
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 containing the subjectAltNa= me of that certificate.=C2=A0 The test on
>>>> the
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 MESSAGE-INTEGRITY-SHA256 at= tribute indicates that the
>> transaction
>>>> is
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 authenticated and that the = client implements this specification
>>>> and
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 so can process the ALTERNAT= E-DOMAIN attribute.
>>>>>
>>>>>
>>>>> All right.
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 o=C2=A0 What authentication and message-integrity mechanisms
>>>> are used.
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 o=C2=A0 The considerations around manual vs. automatic key
>>>> derivation
>>>>>=C2=A0 =C2=A0 =C2=A0>> for
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0the integrity mechanism, as discussed in [RFC4107].
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 o=C2=A0 What mechanisms are used to distinguish STUN messages
>>>> from other
>>>>>=C2=A0 =C2=A0 =C2=A0>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>> Why is this required? = It seems like that's a generic STUN
>>>> feature.
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>> That text is identical to = the text in RFC 5389.=C2=A0 RFC 5764/7983
>> is
>>>> one such
>>>>>=C2=A0 =C2=A0 =C2=A0>> mechanism, but there is no= thing that prevent another protocol
>>>> stack to use
>>>>>=C2=A0 =C2=A0 =C2=A0>> a different mechanism (inf= erence, shim, etc...)
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>=C2=A0 =C2=A0 =C2=A0> But ultimately no matter what = the other protocol provides for
>>>> demux, STUN
>>>>>=C2=A0 =C2=A0 =C2=A0> has its
>>>>>=C2=A0 =C2=A0 =C2=A0> own demux.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0In fact I think that the reason for= that item was because
>>>>>=C2=A0 =C2=A0 =C2=A0FINGERPRINT can also be used to dem= ux STUN traffic, but it is
>>>>>=C2=A0 =C2=A0 =C2=A0optional.=C2=A0 So an STUN Usage ne= eds to tell if FINGERPRINT is
>>>>>=C2=A0 =C2=A0 =C2=A0mandatory (like in ICE).
>>>>>
>>>>>
>>>>> This should be explained.
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 that is not readily subject to offline dictionary
>> attacks.
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 Protection of the channel itself, using TLS or DTLS,
>>>> mitigates
>>>>>=C2=A0 =C2=A0 =C2=A0>> these
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 attacks.
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 STUN supports both MESSAGE-INTEGRITY and
>>>>>=C2=A0 =C2=A0 =C2=A0MESSAGE-INTEGRITY-SHA256,
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 which is subject to bid down attacks by an on-path
>>>> attacker.
>>>>>=C2=A0 =C2=A0 =C2=A0>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>> By an on-path attacker= who can forge HMAC-SHA1 in real-time?
>>>>>=C2=A0 =C2=A0 =C2=A0That's a
>>>>>=C2=A0 =C2=A0 =C2=A0>>> pretty serious adversa= ry, so you should clarify here
>>>>>=C2=A0 =C2=A0 =C2=A0>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>> New text:
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 STUN supports= both MESSAGE-INTEGRITY and
>>>> MESSAGE-INTEGRITY-SHA256,
>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 which is subj= ect to bid down attacks by an on-path attacker
>>>> that
>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 would strip t= he MESSAGE-INTEGRITY-SHA256 attribute leaving
>>>>>=C2=A0 =C2=A0 =C2=A0only the
>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 MESSAGE-INTEG= RITY attribute and exploiting a potential
>>>>>=C2=A0 =C2=A0 =C2=A0vulnerability.
>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 Protection of= the channel itself, using TLS or DTLS,
>> mitigates
>>>>>=C2=A0 =C2=A0 =C2=A0these
>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 attacks.=C2= =A0 Timely removal of the support of MESSAGE-INTEGRITY
>>>> in a
>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 future versio= n of STUN is necessary.
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>=C2=A0 =C2=A0 =C2=A0> I still don't understand t= he capabilities you seem to believe the
>>>>>=C2=A0 =C2=A0 =C2=A0attacker
>>>>>=C2=A0 =C2=A0 =C2=A0> has.
>>>>>=C2=A0 =C2=A0 =C2=A0> Can you describe the exact att= ack.
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A01. Vulnerability is found in HMAC-S= HA1
>>>>>=C2=A0 =C2=A0 =C2=A02. Client Alice still supports M-I = and M-I-256, does not know what
>>>>>=C2=A0 =C2=A0 =C2=A0version of STUN server Bob supports= and so send both.
>>>>>=C2=A0 =C2=A0 =C2=A03. On-path attacker removes M-I-256= .
>>>>>=C2=A0 =C2=A0 =C2=A05. stunbis server Bob thinks that A= lice is an RFC 5389 client and
>>>>>=C2=A0 =C2=A0 =C2=A0continue 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&= #39;s not that the
>>>>> protocol has a downgrade
>>>>> attack, but rather that the minimum algorithm supporte= d is one you
>> don't
>>>>> trust as much
>>>>> as you might like.
>>>>>
>>>>> -Ekr
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0--


--
Marc Petit-Huguenin
Email: marc@pe= tit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

--000000000000b79f930578f03e57-- From nobody Tue Oct 23 20:13:51 2018 Return-Path: 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 AC175130EE4 for ; Tue, 23 Oct 2018 20:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 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] 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 C8qHMpDC_bX8 for ; Tue, 23 Oct 2018 20:13:37 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 1B9AE130ED0 for ; Tue, 23 Oct 2018 20:13:33 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id v6-v6so3316378ljc.11 for ; Tue, 23 Oct 2018 20:13:32 -0700 (PDT) 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=TOdAfQ8nfPaGa5n7fGePvgHjsBrZLzPecOZxuiHbRsA=; b=LTA/CzZDXaPGy/SQ9GwkjTfSjIWf5D7JPBmqqJCWAQb7WxXhBZAGnUTZ8kZ5xIrfHw g6UU4PIJ3cKbKy19SVKa8smbxjPv3NvHIAxON7UwCBfDtkoDeYGwTVN4XBw9XowiT3hG pzKGYXtOsEv0lI8c4W/66VlJuoLRiSddF+zNzCG3Gocoj+OIGZNROdUD4zW4lJGM/KdZ 9ws7neCuM30YXey3QAmDq6Pv/N5xYSEs2kPVk4/ig5E5o5wo2f9w21bzhTHHD//FsEGZ YS8eFM5bL6MaWF3ucjorp9BDTT3+6OJ1u3pzdmuH5ZYErPty6wMZABk8P/bmsgLg14gB tu9A== 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=TOdAfQ8nfPaGa5n7fGePvgHjsBrZLzPecOZxuiHbRsA=; b=hDITYGHQKaDbTTugx4BXu4Z8tv8jJe/k0ahl0i5GrcotPbWa6F06g7ql641Frj9Qdz IoZ17J/14dljP+6ODZzW+b8FHRWVP7PVR9aH6Mny4Pv1fe5S9bFu0WFdQwfyoBGPKB85 Anb1tpFZUSvRLGkjTLmlvifPhynrXqKoWi9f3YBev+EFcDMJ1cZAGjunayc9NGaMYtSE vuqTTdAWiqk2P6yAY2RGYX1oGvcYKMIOX3NOBQTwmxK0fF5ewc57NsrBmgfkgbqyh9+9 mSA5/PDDa1pSsYBIuIDm6ImwodKWruUHPlEJ6yNbrhiJrRFVVfZv+TJZzbWTXDkvpFym 8Kiw== X-Gm-Message-State: AGRZ1gILmUN/C+4U1LTTgkjVt1cWLIJ6skH7TpI3CfTNsLXvfB49JmMH dH3R76YzWiS0vNV/+Aw1tg+lgeTKdwpfpCX67+dcSg== X-Google-Smtp-Source: AJdET5desWOS5+iCmcmSOqd4PFlYqYOGQ/YPvrhgfAcsgCWAhNiwrpnIsAbtj29bEUEBdKdHNHr46Blxt+t9FoUJGh4= X-Received: by 2002:a2e:2a43:: with SMTP id q64-v6mr437224ljq.153.1540350811204; Tue, 23 Oct 2018 20:13:31 -0700 (PDT) MIME-Version: 1.0 References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <02569943-db8f-654e-7322-49bc1f1a1163@acm.org> <235b838f-2800-2cd0-8b01-947e70837619@ericsson.com> In-Reply-To: From: Eric Rescorla Date: Tue, 23 Oct 2018 20:12:54 -0700 Message-ID: To: Spencer Dawkins Cc: Marc Petit-Huguenin , tram-chairs@ietf.org, tram@ietf.org, Gonzalo Camarillo , tasveren@rbbn.com, IESG , draft-ietf-tram-stunbis@ietf.org Content-Type: multipart/alternative; boundary="000000000000ee823d0578f0dea2" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 03:13:49 -0000 --000000000000ee823d0578f0dea2 Content-Type: text/plain; charset="UTF-8" On Tue, Oct 23, 2018 at 7:28 PM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Marc, > > I see that a -19 has been submitted, but didn't see a reply from Eric in > this thread > No, I missed this. . Do you think that you've converged? > No, we have not. (I saw an offer of a conference call, so thought an out-of-band > conversation might have happened) > No, it did not. > Thanks, > > Spencer > > On Sun, Oct 7, 2018 at 9:35 AM Marc Petit-Huguenin > 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 >> > 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. > > Argon2 is just the latest in a series of password hashing algorithms that are designed to be generically slow, and so is a better choice than SHA-256. However, even pre-Argon there were other algorithms (scrypt, etc.) > 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. > > This doesn't seem like a good reason to me. If we're going to rev the spec to add a new algorithm, we should follow good practice. > >> > 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. > > This, also, is not relevant to my technical points. Moreover, the point of IESG review is to catch things that might otherwise have been caught by the WG. 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. >> > Again, the problem here is the threat model: the reason that MD5-based stored password hashing is problematic is *not* active attack during the handshake. Rather, it is that MD5 is fast and thus easily reversed (a defect it shares with SHA-256). And so biddown attack isn't relevant here. So, while it *is* useful to know what clients support so that when MD5 usage drops low enough, you can remove the MD5 passwords. But biddown attacks don't really represent a significant threat to that measurement. >> 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? >> > This isn't responsive. We don't add security mechanisms for no reason. If you can't adduce a reason, then this feature should go. -Ekr >> > 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> 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 >> >>>>> > 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 > >> >>>>> > 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 >> >>>>> > >> 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 >> Blog: https://marc.petit-huguenin.org >> Profile: https://www.linkedin.com/in/petithug >> >> --000000000000ee823d0578f0dea2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , Oct 23, 2018 at 7:28 PM Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Hi, Marc,=C2=A0
=
I see that a -19 has been submitted, but didn't see a re= ply from Eric in this thread

No= , I missed this.

. Do you think that you've converged?=C2=A0
=

No, we have not.=C2=A0


(I saw= an offer of a conference call, so thought an out-of-band conversation migh= t have happened)

No, it did not= .


Thanks,

Spencer

On Sun, Oct 7, 2018 at 9:35 AM Marc= Petit-Huguenin <p= etithug@acm.org> wrote:
Hi E= ric,

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>
> wrote:
>
>> Hi Eric,
>>
>> Apologies for the delay in getting back to that.
>>
>> I think that there is some misunderstanding in what STUNbis is try= ing 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 h= ere, though SHA-1
>>> isn't a great choice
>>> either for pwd hashing You want Argon or the like. With that s= aid,
>> there's
>>> no sensible
>>> biddown attack on that hash because it's a per-server feat= ure, not a
>>> per-transaction
>>> feature. So, as long as the server has MD5-hashed passwords, t= he
>> situation
>>> is bad.
>>
>> In no place in STUNbis we are proposing to use SHA-1 for password<= br> >> encryption, so I am not sure where that come from.=C2=A0 What we p= ropose is:
>>
>
> You're right, it's SHA-256, but my criticisms apply equally th= ere.

SHA-256 was what the WG adopted.=C2=A0 Our attempts to add other passwords = encryption mechanisms were denied.=C2=A0 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.

Argon2 is just the la= test in a series of password hashing algorithms that are designed to be gen= erically slow, and so is a better choice than SHA-256. However, even pre-Ar= gon there were other algorithms (scrypt, etc.)

=C2=A0
Anyway it is too late to f= ix this, as it is my understanding that the WG does not have enough energy = to reach consensus on a new password algorithm.

This doesn't seem like a good reaso= n to me. If we're going to rev the spec to add a new algorithm, we shou= ld follow good practice.


>
> I don't see how any of this is relevant to my technical points abo= ve.

My point was that we, the co-editors, did not decide on adding bid-down pro= tection, someone asked us to do so and no-one in the WG saw any problem wit= h that.=C2=A0

This, also, is not relevant to my technical points. Moreover, the point o= f IESG review is to catch things that might otherwise have been caught by t= he WG.


The reasons that person wanted that are not known to us but, as yo= u insist, here's one reason I can think of:

It is a fact that, for operational reasons, a password database cannot be r= e-encrypted at once.=C2=A0 Also for operational reasons, the MD5 password c= annot be immediately removed from the database as soon the user submitted a= new one.=C2=A0 In fact, and for quite some time, both encrypted variants o= f 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, so= me that use a STUNbis client.=C2=A0 It is up to the STUN server owner to de= cide how long the migration to STUNbis will take and when it will be accept= able 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 passwo= rd encryption algorithm.=C2=A0 That's where the biddown protection kick= s 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 h= ave the client misidentifying a STUNbis server as a RFC 5389 server, and ha= ving both them use the MD5 encrypted password instead of the SHA-256 encryp= ted password, all of that easily done by stripping the unprotected 401 resp= onse of the new STUNbis PASSWORD-ALGORITHMS attribute.

Again, the problem here is t= he threat model: the reason that MD5-based stored password hashing is probl= ematic is *not* active attack during the handshake. Rather, it is that MD5 = is fast and thus easily reversed (a defect it shares with SHA-256). And so = biddown attack isn't relevant here. So, while it *is* useful to know wh= at clients support so that when MD5 usage drops low enough, you can remove = the MD5 passwords. But biddown attacks don't really represent a signifi= cant threat to that measurement.


>> There is no biddown attack protection for the MAC, as stated in Se= ction
>> 16.3:
>>
>> "The bid-down protection mechanism described in this document= is new,
>>=C2=A0 and thus cannot currently protect against a bid-down attack = that
>>=C2=A0 lowers the strength of the hash algorithm to HMAC-SHA1."= ;
>>
>> What we put in place is a plan for *future* versions of STUN to ge= t
>> biddown protection for the MAC.=C2=A0 That's it, no more, no l= ess.
>>
>
> Yes, but I don't believe that this will provide bid-down protectio= n for the
> MAC in the future for the reasons I indicate above.
>
> If you think this does something useful, please show me an example att= ack
> 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 exploi= t in
> some other way.

I do not know what weaknesses will be discovered in the future.=C2=A0 I am = also pretty sure that the cost of not using that mechanism is very close to= 0.=C2=A0 What I am sure of is that the cost of reengineering a new biddown= protection mechanism if we ever need it will be high.=C2=A0 We already wen= t 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?

= This isn't responsive. We don't add security mechanisms for no reas= on. If you can't adduce a reason, then this feature should go.

-Ekr




> 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 rever= se 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> 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>> wrote:
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0On 04/22/2018 05:22 PM, Eric Rescor= la wrote:
>>>>>=C2=A0 =C2=A0 =C2=A0> On Sun, Apr 22, 2018 at 2:02 P= M, Marc Petit-Huguenin <
>>>> peti= thug@acm.org <mailto:petithug@acm.org>>
>>>>>=C2=A0 =C2=A0 =C2=A0> wrote:
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 For a request or indication message, the agent MUST
>>>> include the
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGRITY
>>>>>=C2=A0 =C2=A0 =C2=A0>> attributes
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 in the message unless the agent knows from an external
>>>> indication
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 which message integrity algorithm is supported by both
>>>> agents.=C2=A0 In
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 this case either MESSAGE-INTEGRITY or
>>>> MESSAGE-INTEGRITY-SHA256 MUST
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 be included in addition to USERNAME.=C2=A0 The HMAC for the
>>>> MESSAGE-
>>>>>=C2=A0 =C2=A0 =C2=A0>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>> This text appears to c= onflict with S 7.3 of 5245-bis, which
>> says:
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>> [text missing]
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>> Hmm, no, RFC245bis is stil= l referencing RFC5389, so the
>> procedure
>>>> for
>>>>>=C2=A0 =C2=A0 =C2=A0>> stunbis does not apply. >>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>=C2=A0 =C2=A0 =C2=A0> I hear what you're saying,= but publishing two documents at the
>>>> same time
>>>>>=C2=A0 =C2=A0 =C2=A0> which
>>>>>=C2=A0 =C2=A0 =C2=A0> make contrary recommendations = about the same basic protocol is
>>>> un-good.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0Sure, but wouldn't it be simple= r to have rfc5245bis using stunbis
>>>>>=C2=A0 =C2=A0 =C2=A0and have them updating their text, = more than adding some tortuous
>>>>>=C2=A0 =C2=A0 =C2=A0text in stunbis?
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 =C2=A0 Th= e STUN usage must specify which transport protocol is
>>>> used, and
>>>>>=C2=A0 =C2=A0 =C2=A0>> how
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 the agent determines the IP address and port of the
>>>> recipient.
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 Section 8 describes a DNS-based method of determining the
>>>> IP
>>>>>=C2=A0 =C2=A0 =C2=A0>> address
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 and port of a server that a usage may elect to use.=C2=A0 STUN
>>>> may be
>>>>>=C2=A0 =C2=A0 =C2=A0>> used
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 with anycast addresses, but only with UDP and in usages
>>>> where
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 authentication is not used.
>>>>>=C2=A0 =C2=A0 =C2=A0>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>> Why this restriction? = You should be able to use anycast with
>>>> long-term
>>>>>=C2=A0 =C2=A0 =C2=A0>>> AUTH for (say) TURN. >>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>> https://www.ietf.org/mail-archive/web/behave/current/
>>>> msg03582.html
>>>>>=C2=A0 =C2=A0 =C2=A0<htt= ps://www.ietf.org/mail-archive/web/behave/current/
>> msg03582.html>
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>> I think that the decision = of permitting Anycast should be left
>> to
>>>> each
>>>>>=C2=A0 =C2=A0 =C2=A0>> STUN Usage.=C2=A0 Basic ST= UN Usage does not use authentication and
>> use
>>>> only a
>>>>>=C2=A0 =C2=A0 =C2=A0>> one round trip for the Bin= ding transaction, so Unicast can be
>>>> used.
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>=C2=A0 =C2=A0 =C2=A0>> OTOH, TURN and ICE should = probably say something about that, so
>> I
>>>> added a
>>>>>=C2=A0 =C2=A0 =C2=A0>> new bullet point in Sectio= n 13:
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 o=C2=A0 If An= ycast addresses can be used for the server in case
>> TCP
>>>> or
>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2=A0 =C2=A0= TLS-over-TCP, or authentication are used.
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>=C2=A0 =C2=A0 =C2=A0> Are you leaving this text in? = That seems very confusing.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0In isolation yes, but I think it ma= kes sense which the text before
>>>>>=C2=A0 =C2=A0 =C2=A0the bullet points:
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 A STUN usage defines how ST= UN is actually utilized -- when to
>> send
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 requests, what to do with t= he responses, and which optional
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 procedures defined here (or= in an extension to STUN) are to be
>>>> used.
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 A usage also defines:
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0[...]
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 o=C2=A0 If Anycast addresse= s can be used for the server in case TCP
>> or
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TLS-over-TCP, = or authentication are used.
>>>>>
>>>>>
>>>>> What is the need for the restriction at all.
>>>>>
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 transaction over UDP or DTLS-over-UDP is also considered
>>>> failed if
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 there has been a hard ICMP error [RFC1122].=C2=A0 For example,
>>>> assuming
>>>>>=C2=A0 =C2=A0 =C2=A0>> an
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 RTO of 500ms, requests would be sent at times 0 ms, 500
>>>> ms, 1500
>>>>>=C2=A0 =C2=A0 =C2=A0>> ms,
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 3500 ms, 7500 ms, 15500 ms, and 31500 ms.=C2=A0 If the client
>>>> has not
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 received a response after 39500 ms, the client will
>>>> consider the
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 transaction to have timed out.
>>>>>=C2=A0 =C2=A0 =C2=A0>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>> I note that these reco= mmendations now seem crazily long. I
>>>> assume the
>>>>>=C2=A0 =C2=A0 =C2=A0>>> WG had consensus on th= is, but I wanted to note it.
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>> Not just the WG, also the = IESG that approved RFC 5389 too as,
>> but
>>>> for the
>>>>>=C2=A0 =C2=A0 =C2=A0>> addition of "or DTLS-= over-UDP", this is the same text than in
>> RFC
>>>> 5389.
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>=C2=A0 =C2=A0 =C2=A0> Yes, I know. My point is that = while they might have bee sensible
>>>> when
>>>>>=C2=A0 =C2=A0 =C2=A0> 5389 was published they *now* = seem crazily long. Did the WG
>>>> explicitly
>>>>>=C2=A0 =C2=A0 =C2=A0> decide not to update them?
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0No, nobody ever suggested that ther= e was an issue there.
>>>>>
>>>>>
>>>>> OK, well, this seems like it should be considered, the= n, because this
>>>>> doesn't
>>>>> match modern practice.
>>>>>
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0> This would be good to explain.=
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0New text:
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 [...]
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 containing the subjectAltNa= me of that certificate.=C2=A0 The test on
>>>> the
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 MESSAGE-INTEGRITY-SHA256 at= tribute indicates that the
>> transaction
>>>> is
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 authenticated and that the = client implements this specification
>>>> and
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 so can process the ALTERNAT= E-DOMAIN attribute.
>>>>>
>>>>>
>>>>> All right.
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 o=C2=A0 What authentication and message-integrity mechanisms
>>>> are used.
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 o=C2=A0 The considerations around manual vs. automatic key
>>>> derivation
>>>>>=C2=A0 =C2=A0 =C2=A0>> for
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0the integrity mechanism, as discussed in [RFC4107].
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 o=C2=A0 What mechanisms are used to distinguish STUN messages
>>>> from other
>>>>>=C2=A0 =C2=A0 =C2=A0>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>> Why is this required? = It seems like that's a generic STUN
>>>> feature.
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>> That text is identical to = the text in RFC 5389.=C2=A0 RFC 5764/7983
>> is
>>>> one such
>>>>>=C2=A0 =C2=A0 =C2=A0>> mechanism, but there is no= thing that prevent another protocol
>>>> stack to use
>>>>>=C2=A0 =C2=A0 =C2=A0>> a different mechanism (inf= erence, shim, etc...)
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>=C2=A0 =C2=A0 =C2=A0> But ultimately no matter what = the other protocol provides for
>>>> demux, STUN
>>>>>=C2=A0 =C2=A0 =C2=A0> has its
>>>>>=C2=A0 =C2=A0 =C2=A0> own demux.
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0In fact I think that the reason for= that item was because
>>>>>=C2=A0 =C2=A0 =C2=A0FINGERPRINT can also be used to dem= ux STUN traffic, but it is
>>>>>=C2=A0 =C2=A0 =C2=A0optional.=C2=A0 So an STUN Usage ne= eds to tell if FINGERPRINT is
>>>>>=C2=A0 =C2=A0 =C2=A0mandatory (like in ICE).
>>>>>
>>>>>
>>>>> This should be explained.
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 that is not readily subject to offline dictionary
>> attacks.
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 Protection of the channel itself, using TLS or DTLS,
>>>> mitigates
>>>>>=C2=A0 =C2=A0 =C2=A0>> these
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 attacks.
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 STUN supports both MESSAGE-INTEGRITY and
>>>>>=C2=A0 =C2=A0 =C2=A0MESSAGE-INTEGRITY-SHA256,
>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2=A0 =C2= =A0 which is subject to bid down attacks by an on-path
>>>> attacker.
>>>>>=C2=A0 =C2=A0 =C2=A0>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>> By an on-path attacker= who can forge HMAC-SHA1 in real-time?
>>>>>=C2=A0 =C2=A0 =C2=A0That's a
>>>>>=C2=A0 =C2=A0 =C2=A0>>> pretty serious adversa= ry, so you should clarify here
>>>>>=C2=A0 =C2=A0 =C2=A0>>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>> New text:
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 STUN supports= both MESSAGE-INTEGRITY and
>>>> MESSAGE-INTEGRITY-SHA256,
>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 which is subj= ect to bid down attacks by an on-path attacker
>>>> that
>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 would strip t= he MESSAGE-INTEGRITY-SHA256 attribute leaving
>>>>>=C2=A0 =C2=A0 =C2=A0only the
>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 MESSAGE-INTEG= RITY attribute and exploiting a potential
>>>>>=C2=A0 =C2=A0 =C2=A0vulnerability.
>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 Protection of= the channel itself, using TLS or DTLS,
>> mitigates
>>>>>=C2=A0 =C2=A0 =C2=A0these
>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 attacks.=C2= =A0 Timely removal of the support of MESSAGE-INTEGRITY
>>>> in a
>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 future versio= n of STUN is necessary.
>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>=C2=A0 =C2=A0 =C2=A0> I still don't understand t= he capabilities you seem to believe the
>>>>>=C2=A0 =C2=A0 =C2=A0attacker
>>>>>=C2=A0 =C2=A0 =C2=A0> has.
>>>>>=C2=A0 =C2=A0 =C2=A0> Can you describe the exact att= ack.
>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A01. Vulnerability is found in HMAC-S= HA1
>>>>>=C2=A0 =C2=A0 =C2=A02. Client Alice still supports M-I = and M-I-256, does not know what
>>>>>=C2=A0 =C2=A0 =C2=A0version of STUN server Bob supports= and so send both.
>>>>>=C2=A0 =C2=A0 =C2=A03. On-path attacker removes M-I-256= .
>>>>>=C2=A0 =C2=A0 =C2=A05. stunbis server Bob thinks that A= lice is an RFC 5389 client and
>>>>>=C2=A0 =C2=A0 =C2=A0continue 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&= #39;s not that the
>>>>> protocol has a downgrade
>>>>> attack, but rather that the minimum algorithm supporte= d is one you
>> don't
>>>>> trust as much
>>>>> as you might like.
>>>>>
>>>>> -Ekr
>>>>>
>>>>>
>>>>>=C2=A0 =C2=A0 =C2=A0--


--
Marc Petit-Huguenin
Email: marc@pe= tit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

--000000000000ee823d0578f0dea2-- From nobody Wed Oct 24 01:44:43 2018 Return-Path: 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 39E92130EBB; Wed, 24 Oct 2018 01:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 K4zINfiW-sAN; Wed, 24 Oct 2018 01:44:36 -0700 (PDT) Received: from implementers.org (unknown [92.243.22.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EFCF130EE0; Wed, 24 Oct 2018 01:44:35 -0700 (PDT) Received: from [IPv6:2601:648:8400:8e7d:2045:7a00:9dfd:61bf] (unknown [IPv6:2601:648:8400:8e7d:2045:7a00:9dfd:61bf]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id A0E7CAE00A; Wed, 24 Oct 2018 10:44:31 +0200 (CEST) To: Spencer Dawkins at IETF Cc: Eric Rescorla , tram-chairs@ietf.org, tram@ietf.org, Gonzalo Camarillo , "Asveren, Tolga" , IESG , draft-ietf-tram-stunbis@ietf.org References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <02569943-db8f-654e-7322-49bc1f1a1163@acm.org> <235b838f-2800-2cd0-8b01-947e70837619@ericsson.com> From: Marc Petit-Huguenin Openpgp: preference=signencrypt Autocrypt: addr=petithug@acm.org; prefer-encrypt=mutual; keydata= mQINBE6Mh9wBEADrUEDZChteJbQtsHwZITZExr7TAqT7pniNwhBX3nFgd+FrV3lsLKJ1rym2 52MAYpubXEJZGzMp6uCCAnROWbtmQbOm8z/jHnjxHhPqfuYCYPpAQqu8K/Sc194Rp37krMwB jz32yr7+gvWLzRgQGKIh9d2mzy8QLMETVWWQWGb6fEfpOxXo0wumN1rc/275kZwOu44JIPGg zbgwZdnEqYOUUa18K9MXeRDoWbwDISP30CvKuZDwD14lbBE3o7tBQrU9uoMhE7eFlTjbsCox qoubI2tZSuOTF8mRXjPmNrRGtf9mYkQnOB7y6qy/QxmOVMq4IRtHzOYIm/EZ6NTodcpZQHOM 2v6B6YK9uKrYrapSpJzn4f9oU7alT31Y3o2hOlxAWDQ16+Dd1MOPYsKQXOwY1/ihm4PTjiJ8 ud8yPzy7c+BSVs5wkBU6QuLNIgZHrrxdn+KxM+F/oAVtfzO7XzVoeOcXyWi3/CHL5pgoBruY enIF/RrRuplpy09pvZjmFPNfqKBYJGnqpQuqsQwO7LsFqDqfY2EuHg+KsGN1XuN+jxXc48/1 gCnKw7ALSPWEb7g25wD6KfiZTAcyRTG8LePNFQKhw61LbIWmkw9EaVLyXvwPTc1iCSc0dDT/ pcT/z+8xrWOyWGZNZAjR584NlDpKollbItcxYtFcYZkvTCmOVwARAQABtCZNYXJjIFBldGl0 LUh1Z3VlbmluIDxwZXRpdGh1Z0BhY20ub3JnPokCOAQTAQgAIgIbIwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AFAlfy11wACgkQKcRFldZqfsRWqBAAu/61DGo+j38UefTKnEse0mftPBXa S4lre7vknn33MI0L5QXmiM8zRs9FOKSuXPx0EV+JhI4pWZGW/2MJPuyifXHvnIChcdGInN8J GBdTLZSOgdDFZL9msO+QUsvMA8ZUsqlKOEcVL1NyoLupblCWNq4fYhBCx1zDwX9LZSuGn8lZ Mk8a4QFGoR6dWKaOxeCwnoquW5IK1CfRIhYjHfQMjA5gY0H46F0iCqBaFF/S7krQwIJd0XN4 YbSL4KOrWuxtgQ+iH/iaxxBXgJ1blBNRzXaWJBF4PHv23nSnEzWO17j+uVMaHJu7ycYEf8T9 pVc0xcok1BM2rCrNE5FUFAzsUtAtBZEEK6sSIeOhRG93uD/Hv1hrWzEwf+Z7B1tVQLCQQ4kL 7wyS7SXI/JTuW2xTEGCmwMeWYGERdkgsatmx4zi5nVHDjt3/mlPMj4L+u05SkI2iV4W6xxU1 jHlBIJDs7AVM0dsxzTyIPf2Sz843WyHuBgkoCskxGfOwlkZzDX9rwcWRKal1wjy1w/25LsBY U50INandw3UbrS2I73VX8ARI8uOWZrW7uzRLf8EmuPhtSQ35ThmdoNSgGMP9EXwNgzi/i+5G hbX5KbrSLG9SITFJEcJA4tnwu3nqmBh7D7vbd5ln5X7rmqPdyjidt0zcSjvuaBA+nkmakA4A O+choWy5Ag0EToyH3AEQAL+LguHhcSDCL/IevdcvH/5/fzO2fmuuTxdGwrZZSm7l6/HD2Ira h6Wpa1LvVeRbnsRq8k6O8/i3wVapEoQPmNY3vjWfXaJb8R4vHcqgcxw9N9jhZa+mvGJk9+cI ilDyPzHRBBID4d/3oFKQCQ4Y2SIkO66znPhfBOS2f2AU7AtXHhVEyj6WsLK6boEMcj7j+w5a es2nZam0jhgoz+4DQem4uk8outrRlboGnZN7A2kCNuy39UeOp7BpvQ95IKcJCIeSoiJt2A4B NPQroqhW0zGn9Y9FJ9UiZ9YIeNPYbscUxxvrD+OU9Jv67hW0v3KfvoIKDwVKpO3MW6o+1teS Gt1KCSz+CvGJCvIxfCk7S5K5SBne7ZNKz7rkGXYIzlyr7ZoEgRHmqGmcK/sHTS4e6g2pQQrR USkspyqLZl5Uzmg7yI5oGBL0aHTzYdDkkOKMRXYnl7ivBeNtGcniGqlONLJxpbwec8j7hLRq pXFuepbtPqX/GefuK8rdo+ppEqpRJ50cJTegchTfWfSjn5/mG1B4Oz9OnOcBEeTLO729n0K9 BeTx1pmisD6P/fyrqZZTozDwVEi7Wo9AOaqWOhuTe8L0FlFIk6fc/yM0wzvDWP7sNrevEYHK V9rd+Yc/Jjt293J4uayrt6DNMmSkAw3nlBq3uK5d54J0FAsAUcsE/W2/ABEBAAGJAh8EGAEI AAkCGwwFAlfy11wACgkQKcRFldZqfsSQyA/+Kx3eWtKyb/y35TjgtjT/Hrtw+aIpr1uK97LA ln1j5m7+lQ/jh0/rvSZjs+YQMYLqVGI8oaaF/u+qrokkU6pfrhVZ49D1BmmSTMBSYgnBDYqZ yZ+uzQnnDYt/mpo2OLbl9BhuifR5QXLp43cE1FIhyDT46wfse5tNZ+ll4m4HtXuTw4W3b4cP Hto10260Mki7hXbkDMZ+icBFDMkrrZyYHSnBhelzIM7XnY7A/XZdulfFcDXEcZhAFEv3ylJs xTnGwzDyP1VAdBFL3hpP1CqfP1Kti4hKcxXZYbIgTSsBjcYbPchw3ktUTU29I/nWKH5gmD+q wFizyhtt8Qhl6U67OdZ/XbRGBXs/7tlYJIGiGZyG7IQtDOX0PsVd+6WRcDdFqkpBwYkxU8gd iCeW+YTQ5d8mXXPT2dhFAeK2hCFa2+IdaXvH8ovjZpTMeKstHrWJUDaSqQ4GFT676DbDyqtm P6Ul9cjGVtXIs64FWqR9wrbwBH1GuIHhDmG9sN5AkyB9mxXaEG3uG4E6qQeedtIKC6p+ebAs aTGgztFWMJDC8LUznu7B0oyWxNVoE/RGt5mesOeAtqYr6Jtdh7unyk8BYP1y4e+SSMwvtwh+ 69tJwNhGYbOJrdX34tXNAKb6r/rFRjVJm+sPPs5ok7LddvV35o+Fho0LRNDsioDV3HytlhA= Message-ID: <472563ee-5fc3-655d-8e31-138cc774e608@acm.org> Date: Wed, 24 Oct 2018 01:44:18 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="W3XKfhMwAcgtTYaVZf4OshRPa5w8GxaZn" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 08:44:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --W3XKfhMwAcgtTYaVZf4OshRPa5w8GxaZn Content-Type: multipart/mixed; boundary="57TkV3HkfoOovU1xa2vS71QHTEJcsp8cK"; protected-headers="v1" From: Marc Petit-Huguenin To: Spencer Dawkins at IETF Cc: Eric Rescorla , tram-chairs@ietf.org, tram@ietf.org, Gonzalo Camarillo , "Asveren, Tolga" , IESG , draft-ietf-tram-stunbis@ietf.org Message-ID: <472563ee-5fc3-655d-8e31-138cc774e608@acm.org> Subject: Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT) References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <02569943-db8f-654e-7322-49bc1f1a1163@acm.org> <235b838f-2800-2cd0-8b01-947e70837619@ericsson.com> In-Reply-To: --57TkV3HkfoOovU1xa2vS71QHTEJcsp8cK Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Spencer, I sent my answers to Eric Rescorla questions on 2018-10-07 following an i= n-person meeting with my co-author, but never got a response back. Becau= se 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 an= d Benjamin's comments. https://www.ietf.org/mail-archive/web/tram/current/msg02635.html On 10/23/18 7:28 PM, Spencer Dawkins at IETF wrote: > Hi, Marc, >=20 > I see that a -19 has been submitted, but didn't see a reply from Eric i= n > this thread. Do you think that you've converged? >=20 > (I saw an offer of a conference call, so thought an out-of-band > conversation might have happened) >=20 > Thanks, >=20 > Spencer >=20 > On Sun, Oct 7, 2018 at 9:35 AM Marc Petit-Huguenin w= rote: >=20 >> 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 >>> wrote: >>> >>>> Hi Eric, >>>> >>>> Apologies for the delay in getting back to that. >>>> >>>> I think that there is some misunderstanding in what STUNbis is tryin= g 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 most= ly >>>> 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 S= HA-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 i= t is >> too late to fix this, as it is my understanding that the WG does not h= ave >> enough energy to reach consensus on a new password algorithm. Someone= can >> just write a draft adding Argon2 as password encryption, as we will ha= ve a >> IANA registry for that. >> >>> >>> >>>> - Establish a registry for new password algorithms (section 18.5), s= o >>>> algorithms like Argon2 could be added later (but note that our own >>>> proposals to add more password algorithms were rejected by the worki= ng >>>> 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-dow= n >> protection, someone asked us to do so and no-one in the WG saw any pro= blem >> with that. The reasons that person wanted that are not known to us bu= t, 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 submi= tted >> 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 sing= le >> user may use a mix of devices, some of them that use an RFC 5389 clien= t, >> 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 t= ime >> 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 implemen= ting >> STUNbis it unconditionally gets the additional protection of the new >> password encryption algorithm. That's where the biddown protection ki= cks >> 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 unprotect= ed >> 401 response of the new STUNbis PASSWORD-ALGORITHMS attribute. >> >>> >>> >>> >>>>> The second topic is the hash used to compute the MAC. However, I do= n't >>>> see >>>>> how >>>>> this gives you sensible biddown protection because that hash is als= o >> used >>>>> to compute >>>>> MAC over the negotiation: an attacker who has compromised a MAC whi= ch >> the >>>>> server >>>>> supports will quite likely be able to forge a MAC over the transcri= pt >> as >>>>> well. This is, >>>>> I suppose, potentially useful as a defense against some other weakn= ess >>>>> (e.g., >>>>> version #), but I don't really see how the current design helps aga= inst >>>>> attacks on the >>>>> MAC. >>>> >>>> There is no biddown attack protection for the MAC, as stated in Sect= ion >>>> 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 f= or >> the >>> MAC in the future for the reasons I indicate above. >>> >>> If you think this does something useful, please show me an example at= tack >>> and how this fixes it. Note that it's not generally useful to just bi= d >> down >>> the MAC itself unless the MAC you bid down to is weak enough to explo= it >> 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 facep= alm >> 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 beca= use >>>> the >>>>> on-path attacker can do a bid-down and use the client as a MAC orac= le >> 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> 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 >>>>>>> > 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 > >>>>>>> > 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 exter= nal >>>>>> indication >>>>>>> >>>> which message integrity algorithm is supported by b= oth >>>>>> 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, whi= ch >>>> 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 stu= nbis >>>>>>> and have them updating their text, more than adding some tort= uous >>>>>>> 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 determini= ng >> 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 us= ages >>>>>> where >>>>>>> >>>> authentication is not used. >>>>>>> >>> >>>>>>> >>> Why this restriction? You should be able to use anycast w= ith >>>>>> long-term >>>>>>> >>> AUTH for (say) TURN. >>>>>>> >> >>>>>>> >> https://www.ietf.org/mail-archive/web/behave/current/ >>>>>> msg03582.html >>>>>>> >>> 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 tha= t, >> so >>>> I >>>>>> added a >>>>>>> >> new bullet point in Section 13: >>>>>>> >> >>>>>>> >> o If Anycast addresses can be used for the server in c= ase >>>> 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 optiona= l >>>>>>> procedures defined here (or in an extension to STUN) are t= o 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 te= st >> 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 mechan= isms >>>>>> are used. >>>>>>> >>>> >>>>>>> >>>> o The considerations around manual vs. automatic k= ey >>>>>> derivation >>>>>>> >> for >>>>>>> >>>> the integrity mechanism, as discussed in [RFC410= 7]. >>>>>>> >>>> >>>>>>> >>>> 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 proto= col >>>>>> stack to use >>>>>>> >> a different mechanism (inference, shim, etc...) >>>>>>> >> >>>>>>> > >>>>>>> > But ultimately no matter what the other protocol provides f= or >>>>>> 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-ti= me? >>>>>>> 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 atta= cker >>>>>> that >>>>>>> >> would strip the MESSAGE-INTEGRITY-SHA256 attribute leav= ing >>>>>>> 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 belie= ve >> 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 protoco= l 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 yo= u >>>> don't >>>>>>> trust as much >>>>>>> as you might like. >>>>>>> >>>>>>> -Ekr >>>>>>> >>>>>>> >>>>>>> -- >> --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --57TkV3HkfoOovU1xa2vS71QHTEJcsp8cK-- --W3XKfhMwAcgtTYaVZf4OshRPa5w8GxaZn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlvQMOIACgkQKcRFldZq fsTLAhAAu2Hlg1fPr0tmBydDfP4eJ1zEQI/t1O32+7Tr33KU+OgmIrb+hHw5/Rly Kw9QDEb55HBEwdOrqyOZ08gvEqlGGFLj+C/kDgPVe2YPm55FWG/vmRsXIKPacCZR oLeX8YcB0s3Dp+khDnJ2FgLzenqVBXTyylY5xqVCnYF35nH4ZYDdnPYEdIin26C8 vIkhvaLp3TbK/hNGbSjaVKGkBClZxUyxb6YC8k8mmmfteREFltyHX7hpCV2uOWJG 1HK+eKO1Q3KQ1tAvp0DrwW5vbImRCB8YyKGCi4wA/MerN6smKrMRDQ8Pl94JKtjT wJVL5tt0kRStMq6XTTiib73XPcS1WNam9JSJ4wU4jaby3/xxcQmXSgi2P2u2p/c6 9Bp0e9nDB2ilNoFRXh49jMMHusELNxQgEFvl8YW9Y7Cbpqvnax0TPtB5VfPgmF13 Jagtdv18MVRgFbrqo0HYbItmSJj9JzA+hmw2SfLvkC6ksWEFKdWaxmpxf7rIUN0a bZ9Stb0nKZZEcQTcnqDajmRwJ2YT2QGggr2pjvUxui+70Bga2KSgjJkdqYm4TAWB uicpKq68McmtKYZqERwh/7hMPXNDRqWYvvZYQ5r50LqsJJXdKdp8DUn6FdEz9eni aTRfbsdhcjtfxymjUCJnkt5HL7I6DFQuafvCW9LWxod80UIyHGg= =qm3M -----END PGP SIGNATURE----- --W3XKfhMwAcgtTYaVZf4OshRPa5w8GxaZn-- From nobody Wed Oct 24 06:41:26 2018 Return-Path: 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 2A059128CF3; Wed, 24 Oct 2018 06:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bws2RiV8IAnb; Wed, 24 Oct 2018 06:41:11 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 E6B91127332; Wed, 24 Oct 2018 06:41:08 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id v6-v6so4798975ljc.11; Wed, 24 Oct 2018 06:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MPPftkVINzNSnketAlIoNOXC/cFHRSbcnpafYD0DLGg=; b=e62LZ9vypy1AgqyAcckGn+ui0vlue8m7sDqE2nHebux/qTLx+9IVlxyuYHdyyqymRR JYhAJeankgGUYvIfAo4rH8Stee6aMeyy7xKhFgESr/THTC6jHtv/byfIE3UCXug3gUIJ 9k0QzxjibhXYxhGnO6ufS6bQVhhLsRqkqDy0/Wi6XdJQR//FHg4tzZ2DWFsetUUywXU6 I85/wG9ZCd7C5Kyly2TAK4vvD9x2xkdfMC1cJkrI/D4CJH5sZRZXss4sSk3xbab/T3wA JuJT67KKGhkNpz3VDh+BoxEP3aSAlzdQyM+EG1ehgoAh/h9D+g0XKlR4qWfbvzX/lDjT 3J3g== 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=MPPftkVINzNSnketAlIoNOXC/cFHRSbcnpafYD0DLGg=; b=ihaNUg08Ic/QoUlsZ67MZtNmt3CFiHOTOOOzSVy6wFCPewP3C0TwW7G3JayLteLomy AXJd8Rx2aexjo2lJ/JlF6BgFydfL/gnc7qq7kqKg7WPtXV0XClQxDWYC02QsUk+IWcXK AZKmT6CzPgB9B4dJdP+QknX8cw6tXB78n+10A78MNGFFgpK629uiEoQDL9BLhqWkhcA8 mmN4hz58AryQFfsXcqI2QkhquOXjO2u++q6fopBH+fcQeURbw5jlR5n4wcPYL0j8Ipzv GZEGCxNThw8K53tid6vyqedNimgVEkg1Wfv/kwLQGm+19q/J+lq+bnCtFfR1duPl95YQ fqDQ== X-Gm-Message-State: AGRZ1gJxNhM7yfNmkvZEhY0eOgCdVACSpp+7oFv8Jepk3721P3qj2/l7 p6Z4fIxt/tEpXPrvYawyQ0TfFtFGMm2KDddrueALtQ== X-Google-Smtp-Source: AJdET5e75+2dgU53jbC2IeOqpc3vnjaW30gTI7vlPIIUNK/QQ56MfewdgYNQUWPNZXcruJb+Mx4Qtk8eNIFAcg5DRs8= X-Received: by 2002:a2e:921a:: with SMTP id k26-v6mr1814117ljg.163.1540388466893; Wed, 24 Oct 2018 06:41:06 -0700 (PDT) MIME-Version: 1.0 References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <02569943-db8f-654e-7322-49bc1f1a1163@acm.org> <235b838f-2800-2cd0-8b01-947e70837619@ericsson.com> <472563ee-5fc3-655d-8e31-138cc774e608@acm.org> In-Reply-To: <472563ee-5fc3-655d-8e31-138cc774e608@acm.org> From: Spencer Dawkins at IETF Date: Wed, 24 Oct 2018 08:40:55 -0500 Message-ID: To: Marc Petit-Huguenin Cc: Eric Rescorla , tram-chairs@ietf.org, tram@ietf.org, Gonzalo Camarillo , "Asveren, Tolga" , IESG , draft-ietf-tram-stunbis@ietf.org Content-Type: multipart/alternative; boundary="00000000000062ab300578f9a348" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 13:41:17 -0000 --00000000000062ab300578f9a348 Content-Type: text/plain; charset="UTF-8" Hi, Marc, On Wed, Oct 24, 2018 at 3:44 AM Marc Petit-Huguenin 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 > 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 > >>> 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> 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 > >>>>>>> > 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 > > >>>>>>> > 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 > >>>>>>> >>>> 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 > Blog: https://marc.petit-huguenin.org > Profile: https://www.linkedin.com/in/petithug > > --00000000000062ab300578f9a348 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Marc,=C2=A0

On Wed, Oct 24, 2018 at 3:44 AM Marc Petit-Huguenin <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.=C2=A0 Beca= use there was no change proposed by Eric I went ahead and published -19 a c= ouple of weeks after that, with the text agreed in response to Adam's a= nd Benjamin's comments.

https://www.ietf.org/mail-archive/we= b/tram/current/msg02635.html

Ah - I won= der if that was what had happened.=C2=A0

It sounds= like you did the right thing, and that Eric has now responded, which is al= so the right thing to do.=C2=A0

Thanks for helping= me understand.

Spencer
=C2=A0
On 10/23/18 7:28 PM, Spencer Dawkins at IETF wro= te:
> Hi, Marc,
>
> I see that a -19 has been submitted, but didn't see a reply from E= ric 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> 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> >>> wrote:
>>>
>>>> Hi Eric,
>>>>
>>>> Apologies for the delay in getting back to that.
>>>>
>>>> I think that there is some misunderstanding in what STUNbi= s 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 thi= nk that the biddown
>>>>> discussion makes much sense.
>>>>>
>>>>> To recap, there are two hashes here:
>>>>>
>>>>> - The hash which you use to store the password with (c= urrently 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. Wit= h that said,
>>>> there's
>>>>> no sensible
>>>>> biddown attack on that hash because it's a per-ser= ver feature, not a
>>>>> per-transaction
>>>>> feature. So, as long as the server has MD5-hashed pass= words, the
>>>> situation
>>>>> is bad.
>>>>
>>>> In no place in STUNbis we are proposing to use SHA-1 for p= assword
>>>> encryption, so I am not sure where that come from.=C2=A0 W= hat we propose is:
>>>>
>>>
>>> You're right, it's SHA-256, but my criticisms apply eq= ually there.
>>
>> SHA-256 was what the WG adopted.=C2=A0 Our attempts to add other p= asswords
>> encryption mechanisms were denied.=C2=A0 It is true that Argon2 wa= s 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.=C2=A0= Anyway it is
>> too late to fix this, as it is my understanding that the WG does n= ot have
>> enough energy to reach consensus on a new password algorithm.=C2= =A0 Someone can
>> just write a draft adding Argon2 as password encryption, as we wil= l have a
>> IANA registry for that.
>>
>>>
>>>
>>>> - Establish a registry for new password algorithms (sectio= n 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 SH= A-256.
>>>> - Register MD5 as an initial password algorithm for backwa= rd
>> compatibility
>>>> purpose.
>>>>
>>>> As for the biddown protection itself, it is my recollectio= n that it
>>>> happened more or less like that:
>>>>
>>>>
>>>> INT. MEETING ROOM - DAY
>>>>
>>>> One of the co-editors of STUNBis stands at the microphone:=
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CO-EDITOR
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 We added SHA-256 protection for passwords
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 in STUNBis.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SOMEONE (V.O.)
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 As MD5 still need to be supported, you need to add
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 protection for bid-down attacks.
>>>>
>>>> CLOSE-UP on CO-EDITOR ROLLING HIS EYES
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CO-EDITOR
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 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: >>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CO-EDITOR
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 We added a nice mechanism to prevent bid-down
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 attacks on passwords.=C2=A0 Any comments?
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 THE ROOM
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 (silence)
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CO-EDITOR
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Moving on...
>>>>
>>>
>>> I don't see how any of this is relevant to my technical po= ints 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.=C2=A0 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 ca= nnot be
>> re-encrypted at once.=C2=A0 Also for operational reasons, the MD5 = password
>> cannot be immediately removed from the database as soon the user s= ubmitted
>> a new one.=C2=A0 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 c= lient,
>> some that use a STUNbis client.=C2=A0 It is up to the STUN server = owner to
>> decide how long the migration to STUNbis will take and when it wil= l be
>> acceptable to reject all RFC 5389 (i.e. MD5) clients (that migrati= on time
>> can be purposely reduced to 0 seconds but that's the choice an= d
>> responsibility of the owner of the server).
>>
>> Meanwhile we still need to be sure that if the STUN client is impl= ementing
>> STUNbis it unconditionally gets the additional protection of the n= ew
>> password encryption algorithm.=C2=A0 That's where the biddown = protection kicks
>> in, by preventing an online attacker to have the server misidentif= ying a
>> STUNbis client as an RFC 5389 client, by preventing an online atta= cker to
>> have the client misidentifying a STUNbis server as a RFC 5389 serv= er, and
>> having both them use the MD5 encrypted password instead of the SHA= -256
>> encrypted password, all of that easily done by stripping the unpro= tected
>> 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 tha= t hash is also
>> used
>>>>> to compute
>>>>> MAC over the negotiation: an attacker who has compromi= sed 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 som= e 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 stat= ed in Section
>>>> 16.3:
>>>>
>>>> "The bid-down protection mechanism described in this = document is new,
>>>>=C2=A0 and thus cannot currently protect against a bid-down= attack that
>>>>=C2=A0 lowers the strength of the hash algorithm to HMAC-SH= A1."
>>>>
>>>> What we put in place is a plan for *future* versions of ST= UN to get
>>>> biddown protection for the MAC.=C2=A0 That's it, no mo= re, no less.
>>>>
>>>
>>> Yes, but I don't believe that this will provide bid-down p= rotection for
>> the
>>> MAC in the future for the reasons I indicate above.
>>>
>>> If you think this does something useful, please show me an exa= mple 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 t= o exploit
>> in
>>> some other way.
>>
>> I do not know what weaknesses will be discovered in the future.=C2= =A0 I am also
>> pretty sure that the cost of not using that mechanism is very clos= e to 0.
>> What I am sure of is that the cost of reengineering a new biddown<= br> >> protection mechanism if we ever need it will be high.=C2=A0 We alr= eady 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 f= acepalm
>> 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 he= lp 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> 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-H= uguenin <
>>>> peti= thug@acm.org
>>>>>>> <mailto:petithug@acm.org>> wrote:
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0On 04/22/2018 05:22 PM, Eri= c Rescorla wrote:
>>>>>>>=C2=A0 =C2=A0 =C2=A0> On Sun, Apr 22, 2018 a= t 2:02 PM, Marc Petit-Huguenin <
>>>>>> petithug@acm.org <mailto:petithug@acm.org>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0> wrote:
>>>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 For a request or indication message, the agent MUST
>>>>>> include the
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 USERNAME, MESSAGE-INTEGRITY-SHA256, and
>> MESSAGE-INTEGRITY
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> attributes
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 in the message unless the agent knows from an external
>>>>>> indication
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 which message integrity algorithm is supported by both
>>>>>> agents.=C2=A0 In
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 this case either MESSAGE-INTEGRITY or
>>>>>> MESSAGE-INTEGRITY-SHA256 MUST
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 be included in addition to USERNAME.=C2=A0 The HMAC for the
>>>>>> MESSAGE-
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>> This text appe= ars to conflict with S 7.3 of 5245-bis, which
>>>> says:
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> [text missing]
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> Hmm, no, RFC245bis= is still referencing RFC5389, so the
>>>> procedure
>>>>>> for
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> stunbis does not a= pply.
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>>>=C2=A0 =C2=A0 =C2=A0> I hear what you're= saying, but publishing two documents at the
>>>>>> same time
>>>>>>>=C2=A0 =C2=A0 =C2=A0> which
>>>>>>>=C2=A0 =C2=A0 =C2=A0> make contrary recommen= dations about the same basic protocol is
>>>>>> un-good.
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0Sure, but wouldn't it b= e simpler to have rfc5245bis using stunbis
>>>>>>>=C2=A0 =C2=A0 =C2=A0and have them updating thei= r text, more than adding some tortuous
>>>>>>>=C2=A0 =C2=A0 =C2=A0text in stunbis?
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 = =C2=A0 The STUN usage must specify which transport protocol is
>>>>>> used, and
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> how
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 the agent determines the IP address and port of the
>>>>>> recipient.
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 Section 8 describes a DNS-based method of determining
>> the
>>>>>> IP
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> address
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 and port of a server that a usage may elect to use.
>> STUN
>>>>>> may be
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> used
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 with anycast addresses, but only with UDP and in usages
>>>>>> where
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 authentication is not used.
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>> Why this restr= iction? You should be able to use anycast with
>>>>>> long-term
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>> AUTH for (say)= TURN.
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> https://www.ietf.org/mail-archive/web/behave/current/
>>>>>> msg03582.html
>>>>>>>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mail-archive/web/behave/current/
>>>> msg03582.html>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> I think that the d= ecision of permitting Anycast should be left
>>>> to
>>>>>> each
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> STUN Usage.=C2=A0 = Basic STUN Usage does not use authentication and
>>>> use
>>>>>> only a
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> one round trip for= the Binding transaction, so Unicast can be
>>>>>> used.
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> OTOH, TURN and ICE= should probably say something about that,
>> so
>>>> I
>>>>>> added a
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> new bullet point i= n Section 13:
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 o=C2= =A0 If Anycast addresses can be used for the server in case
>>>> TCP
>>>>>> or
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 =C2= =A0 =C2=A0TLS-over-TCP, or authentication are used.
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>>>=C2=A0 =C2=A0 =C2=A0> Are you leaving this t= ext in? That seems very confusing.
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0In isolation yes, but I thi= nk it makes sense which the text
>> before
>>>>>>>=C2=A0 =C2=A0 =C2=A0the bullet points:
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 A STUN usage define= s how STUN is actually utilized -- when to
>>>> send
>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 requests, what to d= o with the responses, and which optional
>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 procedures defined = here (or in an extension to STUN) are to be
>>>>>> used.
>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 A usage also define= s:
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0[...]
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 o=C2=A0 If Anycast = addresses can be used for the server in case TCP
>>>> or
>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TLS-ov= er-TCP, or authentication are used.
>>>>>>>
>>>>>>>
>>>>>>> What is the need for the restriction at all. >>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 transaction over UDP or DTLS-over-UDP is also
>> considered
>>>>>> failed if
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 there has been a hard ICMP error [RFC1122].=C2=A0 For
>> example,
>>>>>> assuming
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> an
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 RTO of 500ms, requests would be sent at times 0 ms, 500
>>>>>> ms, 1500
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> ms,
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 3500 ms, 7500 ms, 15500 ms, and 31500 ms.=C2=A0 If the
>> client
>>>>>> has not
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 received a response after 39500 ms, the client will
>>>>>> consider the
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 transaction to have timed out.
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>> I note that th= ese recommendations now seem crazily long. I
>>>>>> assume the
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>> WG had consens= us on this, but I wanted to note it.
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> Not just the WG, a= lso the IESG that approved RFC 5389 too as,
>>>> but
>>>>>> for the
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> addition of "= or DTLS-over-UDP", this is the same text than in
>>>> RFC
>>>>>> 5389.
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>>>=C2=A0 =C2=A0 =C2=A0> Yes, I know. My point = is that while they might have bee
>> sensible
>>>>>> when
>>>>>>>=C2=A0 =C2=A0 =C2=A0> 5389 was published the= y *now* seem crazily long. Did the WG
>>>>>> explicitly
>>>>>>>=C2=A0 =C2=A0 =C2=A0> decide not to update t= hem?
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0No, nobody ever suggested t= hat there was an issue there.
>>>>>>>
>>>>>>>
>>>>>>> OK, well, this seems like it should be conside= red, then, because this
>>>>>>> doesn't
>>>>>>> match modern practice.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0> This would be good to = explain.
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0New text:
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 [...]
>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 containing the subj= ectAltName of that certificate.=C2=A0 The test
>> on
>>>>>> the
>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 MESSAGE-INTEGRITY-S= HA256 attribute indicates that the
>>>> transaction
>>>>>> is
>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 authenticated and t= hat the client implements this
>> specification
>>>>>> and
>>>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 so can process the = ALTERNATE-DOMAIN attribute.
>>>>>>>
>>>>>>>
>>>>>>> All right.
>>>>>>>
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 o=C2=A0 What authentication and message-integrity mechanisms
>>>>>> are used.
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 o=C2=A0 The considerations around manual vs. automatic key
>>>>>> derivation
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> for
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0the integrity mechanism, as discussed in [RFC4107].=
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 o=C2=A0 What mechanisms are used to distinguish STUN
>> messages
>>>>>> from other
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>> Why is this re= quired? It seems like that's a generic STUN
>>>>>> feature.
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> That text is ident= ical to the text in RFC 5389.=C2=A0 RFC 5764/7983
>>>> is
>>>>>> one such
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> mechanism, but the= re is nothing that prevent another protocol
>>>>>> stack to use
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> a different mechan= ism (inference, shim, etc...)
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>>>=C2=A0 =C2=A0 =C2=A0> But ultimately no matt= er what the other protocol provides for
>>>>>> demux, STUN
>>>>>>>=C2=A0 =C2=A0 =C2=A0> has its
>>>>>>>=C2=A0 =C2=A0 =C2=A0> own demux.
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0In fact I think that the re= ason for that item was because
>>>>>>>=C2=A0 =C2=A0 =C2=A0FINGERPRINT can also be use= d to demux STUN traffic, but it is
>>>>>>>=C2=A0 =C2=A0 =C2=A0optional.=C2=A0 So an STUN = Usage needs to tell if FINGERPRINT is
>>>>>>>=C2=A0 =C2=A0 =C2=A0mandatory (like in ICE). >>>>>>>
>>>>>>>
>>>>>>> This should be explained.
>>>>>>>
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 that is not readily subject to offline dictionary
>>>> attacks.
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 Protection of the channel itself, using TLS or DTLS,
>>>>>> mitigates
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> these
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 attacks.
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 STUN supports both MESSAGE-INTEGRITY and
>>>>>>>=C2=A0 =C2=A0 =C2=A0MESSAGE-INTEGRITY-SHA256, >>>>>>>=C2=A0 =C2=A0 =C2=A0>>>>=C2=A0 =C2= =A0 =C2=A0 which is subject to bid down attacks by an on-path
>>>>>> attacker.
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>> By an on-path = attacker who can forge HMAC-SHA1 in real-time?
>>>>>>>=C2=A0 =C2=A0 =C2=A0That's a
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>> pretty serious= adversary, so you should clarify here
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>> New text:
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 STUN = supports both MESSAGE-INTEGRITY and
>>>>>> MESSAGE-INTEGRITY-SHA256,
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 which= is subject to bid down attacks by an on-path attacker
>>>>>> that
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 would= strip the MESSAGE-INTEGRITY-SHA256 attribute leaving
>>>>>>>=C2=A0 =C2=A0 =C2=A0only the
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 MESSA= GE-INTEGRITY attribute and exploiting a potential
>>>>>>>=C2=A0 =C2=A0 =C2=A0vulnerability.
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 Prote= ction of the channel itself, using TLS or DTLS,
>>>> mitigates
>>>>>>>=C2=A0 =C2=A0 =C2=A0these
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 attac= ks.=C2=A0 Timely removal of the support of
>> MESSAGE-INTEGRITY
>>>>>> in a
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 futur= e version of STUN is necessary.
>>>>>>>=C2=A0 =C2=A0 =C2=A0>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>>>=C2=A0 =C2=A0 =C2=A0> I still don't unde= rstand the capabilities you seem to believe
>> the
>>>>>>>=C2=A0 =C2=A0 =C2=A0attacker
>>>>>>>=C2=A0 =C2=A0 =C2=A0> has.
>>>>>>>=C2=A0 =C2=A0 =C2=A0> Can you describe the e= xact attack.
>>>>>>>=C2=A0 =C2=A0 =C2=A0>
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A01. Vulnerability is found i= n HMAC-SHA1
>>>>>>>=C2=A0 =C2=A0 =C2=A02. Client Alice still suppo= rts M-I and M-I-256, does not know
>> what
>>>>>>>=C2=A0 =C2=A0 =C2=A0version of STUN server Bob = supports and so send both.
>>>>>>>=C2=A0 =C2=A0 =C2=A03. On-path attacker removes= M-I-256.
>>>>>>>=C2=A0 =C2=A0 =C2=A05. stunbis server Bob think= s that Alice is an RFC 5389 client and
>>>>>>>=C2=A0 =C2=A0 =C2=A0continue with that protocol= .
>>>>>>>
>>>>>>>
>>>>>>> This seems like an extremely weak attack. In g= eneral, 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
>>>>>>>
>>>>>>>
>>>>>>>=C2=A0 =C2=A0 =C2=A0--
>>



--
Marc Petit-Huguenin
Email: marc@pe= tit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

--00000000000062ab300578f9a348--