From nobody Wed May 2 15:20:21 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 29F4F12DA3F; Wed, 2 May 2018 15:20:19 -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 x0koTTMEXatY; Wed, 2 May 2018 15:20:16 -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 160B412DA45; Wed, 2 May 2018 15:20:16 -0700 (PDT) Received: from [IPv6:2601:648:8301:730f:388b:e133:9a29:637a] (unknown [IPv6:2601:648:8301:730f:388b:e133:9a29:637a]) (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 750F1AE844; Thu, 3 May 2018 00:20:11 +0200 (CEST) From: Marc Petit-Huguenin To: Benjamin Kaduk , The IESG Cc: tram-chairs@ietf.org, tasveren@rbbn.com, Gonzalo.Camarillo@ericsson.com, draft-ietf-tram-stunbis@ietf.org, tram@ietf.org References: <152410023763.28841.5479872591399614102.idtracker@ietfa.amsl.com> Message-ID: Date: Wed, 2 May 2018 15:20:05 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <152410023763.28841.5479872591399614102.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CrUngAgkt2PCEhO0BQvMvrURlnxO8YS99" Archived-At: Subject: Re: [tram] Benjamin Kaduk's No Record on draft-ietf-tram-stunbis-16: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 02 May 2018 22:20:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CrUngAgkt2PCEhO0BQvMvrURlnxO8YS99 Content-Type: multipart/mixed; boundary="igR2Nx1qcJ8myfqQf0BieP4RT2mJ1hsq4"; protected-headers="v1" From: Marc Petit-Huguenin To: Benjamin Kaduk , The IESG Cc: tram-chairs@ietf.org, tasveren@rbbn.com, Gonzalo.Camarillo@ericsson.com, draft-ietf-tram-stunbis@ietf.org, tram@ietf.org Message-ID: Subject: Re: [tram] Benjamin Kaduk's No Record on draft-ietf-tram-stunbis-16: (with COMMENT) References: <152410023763.28841.5479872591399614102.idtracker@ietfa.amsl.com> In-Reply-To: <152410023763.28841.5479872591399614102.idtracker@ietfa.amsl.com> --igR2Nx1qcJ8myfqQf0BieP4RT2mJ1hsq4 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Benjamin, Thanks for the review, please see my responses inline. On 04/18/2018 06:10 PM, Benjamin Kaduk wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-tram-stunbis-16: No Record >=20 [...] >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I'm balloting No Objection and not DISCUSS because no individual > item rises quite to that level of criticality, but there still are > quite a number of things that ought to be addressed prior to > publication. >=20 > In addition to the excellent points raised in the secdir review > (which are mostly addressed but only in the editor's copy?), I > would call out a few more key observations: >=20 > If I understand correctly, the server's PASSWORD-ALGORITHMS array > from the response are echoed back by the client in the subsequent > request in order to provide downgrade protection -- the initial > response is at least sometimes not authenticated, and by having the > client repeat it back under an authenticated scheme, the server can > detect if the list was tampered to remove any new, stronger, > algorithms. This is probably an important enough concept to be > called out explicitly, either where the behavior is described or in > Section 9.2.1 ("Bid Down Attack Prevention").usb Yes, EKR had a similar question that I still have to answer, and I'll ans= wer both after this review. >=20 > Section 8.1 has some text that could be read as requiring a STUN > client to implement dual-stack IPv4/IPv6, which presumably is not > the intention: > In addition, instead of querying either the A or the AAAA resource > records for a domain name, the client MUST query both and try the > requests with all the IP addresses received, as specified in > [RFC8305]. New text: In addition, instead of querying either the A or the AAAA resource records for a domain name, a dual-stack IPv4/IPv6 client MUST query both and try the requests with all the IP addresses received, as specified in [RFC8305]. >=20 > There are still some places where the text talks about > MESSAGE-INTEGRITY when it really means "message integrity > protection" (i.e., either the SHA1 or SHA-256 variants, for now); > I've attempted to note them in the notes below. >=20 > There is text in both Sections 9.1 and 9.2 that talks of replay > protection being provided, by the time-limited nature of the > short-term credentials or the nonce for long-term credentials. This > seems to only, strictly speaking, be true if any given > password/nonce can only be used once, but for the short-term > credentials the password is used for the duration of the > "session-equivalent", and for the long-term credentials a nonce can > be reused for some amount of time as well. So while these are both > replay countermeasures that can limit replay attacks, it seems a > stretch to claim that they prevent replay attacks (entirely). s/prevented/limited/ >=20 > The Stale Nonce behavior seems potentially worrisome, in that it > opens up a side channel for a distinguishing attack, > between a 401 and 438 response. (That is, "password correct" vs. > "password incorrect".) The impact seems rather muted, though, since > the gain to the attacker is to be able to precompute a bunch of > requests using a nonce of the attacker's choosing and blindly replay > the precomputed object against (possibly multiple) servers looking > for a guess. The realm and username are still in play, so the scope > for the attacker to gain from the precomputation seems limited. > (The same level of brute-force guessing can be obtained "live" just > by computing the trial responses against a live server, using a > valid nonce.) So, while it might be nice to give guidance that 438 > should only be used when the server can validate that it did > generate the nonce and the nonce was valid "recently", and to treat > other cases as authentication failures, it's not clear to me that > there's enough of a benefit from the change to make it worth doing. I am not sure what to do there. >=20 >=20 > Section 6.2.3 >=20 > Maybe just cite BCP 195/RFC 7525 instead of inlining requirements? Already fixed following a previous review. >=20 > Also, the "client SHOULD verify ..." and "client MUST verify ..." are > similar enough that some clarification of certificate vs. identity > verification would be in order, if both statements are believed > accurate. Changed SHOULD to MUST. >=20 >=20 > Section 6.3 >=20 > [...] Known-but-unexpected attributes SHOULD be ignored by > the agent. [...] >=20 > Why is this not an error? Probably an application of Postel's law but that text was already in RFC = 5389 so we cannot change it without breaking compatibility with RFC 5389 = implementations. >=20 >=20 > Section 6.3.1, 6.3.2, etc. >=20 > Should the second paragraph start with "Otherwise, "? Presumably > once an error response is sent or processing ceases, processing stops..= =2E Applied. >=20 >=20 > Section 8.1 >=20 > [...] 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. >=20 > "the verifcation code" is probably unnecessarily vague; we're just > talking about the (D)TLS SNI and certifciate verification code, > right? New text: [...] IP address is used directly to contact the server. 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 (D)TLS SNI and certificate verification code. >=20 >=20 >=20 > Section 9.2 >=20 > [...[ The nonce provides the replay protection. It is a cookie, > selected by the server, and encoded in such a way as to indicate a > duration of validity or client identity from which it is valid. >=20 > Is this like a TLS cookie, where only the server needs to know about > the internal structure (viz. "encoded" in the above)? If so, the > text could probably be more clear. New text: [...] a nonce. The nonce provides the replay protection. It is a cookie, selected by the server, and encoded in such a way as to indicate a duration of validity or client identity from which it is valid. Only [...] >=20 > When mentioning just "a message-integrity", maybe forward-ref both > versions of it to be more clear that we don't mean just the old one? New text: [...] the realm, and echoing the nonce provided by the server. The client also includes one of the message-integrity attributes defined in this document, which provides an HMAC over the entire request, including the nonce. The server validates the nonce and checks the message [...] >=20 > It's unclear why indications can't use a nonce, if one is known > from a previous request/response on the same connection. I think that the explanation is clear: "[...] indications cannot be chall= enged." and as there is no way to know the when a cookie will expire, we = cannot risk losing data for that reason. >=20 > When encoding the value of 0 for the security feature, it may be > worth clarifying that it is still encoded as a 24-bit integer and > base64-encoded, though the "13 character string" text ought to make > this clear to the reader. New text: [...] as the less significant bit of the third byte. If no security features are used, then an integer with all 24 bit set to zero MUST be encoded instead. For the remainder of this document the term [...] >=20 >=20 > Section 9.2.4 >=20 > * If the request contains neither PASSWORD-ALGORITHMS nor > PASSWORD- ALGORITHM, then the request is processed as though > PASSWORD- ALGORITHM were MD5 (Note that if the original > PASSWORD-ALGORITHMS attribute did not contain MD5, this will > result in a 400 Bad Request in a later step below). >=20 > This Note seems a bit odd, since we're predicated on > PASSWORD-ALGORITHMS being absent. New text: * If the request contains neither PASSWORD-ALGORITHMS nor PASSWORD-ALGORITHM, then the request is processed as though PASSWORD-ALGORITHM were MD5 (Note that if the PASSWORD- ALGORITHMS attribute is present but does not contain MD5, this will result in a 400 Bad Request in a later step below). >=20 > * Otherwise, unless (1) PASSWORD-ALGORITHM and PASSWORD- > ALGORITHMS are both present, (2) PASSWORD-ALGORITHMS matches > the value sent in the response that sent this NONCE, and (3) > PASSWORD-ALGORITHM matches one of the entries in PASSWORD- > ALGORITHMS, the server MUST generate an error response with an= > error code of 400 (Bad Request). >=20 > Maybe we could be more clear about "the value of the > PASSWORD-ALGORITHMS attribute in the message matches the value of > the PASSWORD-ALGORITHMS attribute sent in the response that sent the > NONCE used with this message"? I am not sure what to do there. >=20 >=20 > Section 9.2.5 >=20 > If the response contains a PASSWORD-ALGORITHMS attribute, the > subsequent request MUST be authenticated using MESSAGE-INTEGRITY- > SHA256 only. >=20 > This means "all subsequent requests to this server"? Maybe the > wording could be more clear. (It also means that if we get a new > scheme when SHA256 is broken, the document introducing it may need > to Update this document to remove the MUST.) Fixed. >=20 > Also, I think the Security Feature bit is "Password algorithms" > plural (in the next paragraph and maybe multiple locations in the > document). Fixed. >=20 >=20 > Section 10 >=20 > [...] If the transaction uses TLS or DTLS and if the > transaction is authenticated by a MESSAGE-INTEGRITY-SHA256 attribute= > and if the server wants to redirect to a server that uses a differen= t > certificate, then it MUST include an ALTERNATE-DOMAIN attribute > containing the subjectAltName of that certificate. >=20 > The (definite article), implying the entire subjectAltName? Or just > one name that is contained as a SAN entry? New text: [...] or practical. If the transaction uses TLS or DTLS and if the transaction is authenticated by a MESSAGE-INTEGRITY-SHA256 attribute and if the server wants to redirect to a server that uses a different certificate, then it MUST include an ALTERNATE-DOMAIN attribute containing the name contained in the subjectAltName of that certificate. The test on the MESSAGE-INTEGRITY-SHA256 attribute [...] >=20 >=20 > Section 14.8 >=20 > Need to not just say MESSAGE-INTEGRITY since the SHA256 variant > should be fine as well. Fixed. >=20 >=20 > Section 14.10 >=20 > Maybe the nonce cookie should get a shout-out here? Not sure, as when using stunbis with RFC 5389, the nonce cookie will not = be present. >=20 >=20 > Section 14.12 >=20 > Do we need to talk about the padding, since this is the the sole > contents of the attribute and the attribute padding suffices? Added similar text that was added to 14 about setting the padding bits to= zero. >=20 > Also, "derive the long-term password" doesn't seem quite right; > we're deriving the key from the long-term password, per Section > 17.15.1. New text: The PASSWORD-ALGORITHM attribute is present only in requests. It contains the algorithms that the server must use to derive a key from the long-term password. >=20 >=20 > Section 15.1.2 >=20 > There is no amplification of the number of packets with this attack > (the STUN server sends one packet for each packet sent by the > client), though there is a small increase in the amount of data, > since STUN responses are typically larger than requests. >=20 > I usually hear amplification in terms of bytes or bandwidth, not > packets. So maybe just "amplification is modest"? That text is unchanged from RFC 5389. Additionally the text says that "[= =2E..]there is a small increase in the amount of data," >=20 >=20 > Section 15.3 >=20 > This specification uses both HMAC-SHA1 and HMAC-SHA256 for > computation of the message integrity. >=20 > Could perhaps be reworded, since the number of situations when both > are used on the same message is small, and we try to push SHA256 > when we can. New text: This specification uses both HMAC-SHA256 for computation of the message integrity, sometimes in combination with HMAC-SHA1. If, at a [...] >=20 > o STUN Client and Server using the Short Term Credential Mechanism >=20 > Clients and Servers, plural. Fixed. >=20 >=20 > Section 17.32. >=20 > I'm confused why we have MUST-level requirements about using > PASSWORD-ALGORITHMS when it is in the comprehension-optional range > (e.g., echoing from response to repeated request as in Section > 9.2.5). The server cannot actually enforce this MUST when talking > to an old client if we want to retain the comprehension-optional > semantics, IIUC. It is comprehension-optional so old clients does not break. But old clie= nt MUST process them (comprehension-optional doe snot mean that processin= g them is optional, but that an agent should not fail when seeing them an= d not understanding them). >=20 >=20 > Section 17.6 >=20 > If we're adding support for DTLS-over-udp (per the next section), > should we be registering stuns/udp? Adam explained why it is not needed. >=20 > "password encryption algorithm" is not quite the right statement to > make, since we're hashing, not encrypting. >=20 I am not what this is about, as these words are not used in this section = (or in the whole document). --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --igR2Nx1qcJ8myfqQf0BieP4RT2mJ1hsq4-- --CrUngAgkt2PCEhO0BQvMvrURlnxO8YS99 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlrqOZUACgkQKcRFldZq fsRBJBAAia2D/PC7pJkSka+7ictYcAWTMT8eZeYNP6dkhfGOWu/sHSznB9I2XKek gAWBveI+7DNDr3V+4ORbWKq27ooBx4qRNCtPgm0tNtyIV7ukHLXSLku/Tg5DkVID RASLZ6YKPTDlcBfuqwZh6Ub6rBLGTzkMB2AEhcCbu5j75PD3AMlbGq+U897AztDw G6xXK1bECcOLQSTzSniiHBisDbam6QoIizz9bqE2qZZZVPD0Kl/P03zeWjfUBqcZ Lm32KXDydv4y++TUV/GKnZb6DXOld6aAlSxdw+o/2MwuikZpx0BZJ5Yy5jPlGWfY wOxwcCVn4wYHE5ybLLCfFMydmtmNLIa538ti4oOV4iY3o/me55NT9vIIAk7bv0iK dZbHfc865ckBGfhkPsaklN8bjAKtO6P+bJVKkH5qysry7d1KRMgkztfuvN+qDo6n lOZbdVZcEJTPolo4/U/Xn/+LBgrXzD8K/e98FKCuD2QU2tOCkhNUoa+3ygaFUFds wZgC0lIxHRhmEUY/WWJ/+Y3NfsGce4eEhe9p9NyG8TEtjs6XT8eicYylMOAR6NI9 BRdNGIwEYdIux1UAO7VeZaDUveqJpE4SxN/l8R46Rq19lnTmWoreJ7xagxCbg+WB FSaCSDM4QNkz+vIJxvqXX7Bbgxmnpry6IR3tvroTO1vStL9puQs= =p1qy -----END PGP SIGNATURE----- --CrUngAgkt2PCEhO0BQvMvrURlnxO8YS99-- From nobody Wed May 2 17:44: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 043E8127275; Wed, 2 May 2018 17:44:04 -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 R89AuwrEs-Oq; Wed, 2 May 2018 17:44:02 -0700 (PDT) Received: from mail-vk0-x244.google.com (mail-vk0-x244.google.com [IPv6:2607:f8b0:400c:c05::244]) (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 1FCC2127241; Wed, 2 May 2018 17:44:02 -0700 (PDT) Received: by mail-vk0-x244.google.com with SMTP id g72-v6so5810283vke.2; Wed, 02 May 2018 17:44:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Af7lxBqQW6I0gm5ib8/3WaY9p0XlNF8plzzIIHtv7fo=; b=o8VoGR2CnTxINHm/L12iPpfpuoYRde8NEXnUXXQk6ad9+ELgizXIGuqZb4SA/lCCCS x+hDJO91d6OWAhtBE0hAyfXZDxrRjPSeET61ePQIiu3ARvckQ9cs//SFkVAtYxyPQRGp 6ETq6/o45jUpCFwE3j9n6mDhLOLglaSPP8ZWEWM6bxmhnHi5xsPcz2XFkF60DZe79uro xc+63m4gN4645B8kWXxS+x361p1y+Ww4XXy1LPjVKxZfM1doJ2Ey+m4brDJzodEQtQ1f BAg6EaLAv+JDXadUV7N8CjcSDGWUGgnzdVJ89FtvRlohvbteO1j4NM12QU0xELtDbB1R MPQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Af7lxBqQW6I0gm5ib8/3WaY9p0XlNF8plzzIIHtv7fo=; b=qrI6iFpk0rZU125xmLGw29Ufxcas2QI8q6vmLXHObTeqGbThC5GteKSGau8i3Upo3i peadbDEDEsEROitl++fChSew2E58HG1a4jQfnlEx+7osskUhCkhzsISx3bESkCLMEJCS ifJ8yshjAph96pHNrfzDLVHLRTbTz4yeCRct4tCfrS7tO7aNAftBvf6gGTHLNwiBT8Ae IT4zWHS64FrSZWGNlZjlINVwX5rNUKW3PVLrHXkEUPRx3dr+1RrxKaBg+B1UoIcYrUr9 VN88l23f/zwgWyw/zIUn7nMny1Vg0RscdOboJd+ZSJw9DATezJ2ypvGnB29SFlmDmXz6 jlJA== X-Gm-Message-State: ALQs6tA5bBlPGUJ1Vvne9X4rRsO8shh+6DwezWCWk2fLUUkYxNGitVbz 5lTK8JJo/9sy5Jer9oflEs4/j/MV/j0lv+yo6NU= X-Google-Smtp-Source: AB8JxZqnvOwJrOkTopITUvu/lCQVgBqvE5X3hP3VsQbGpyKb5gwu3gtaUgUjGtok4g9u1quJqDvO9LfijFkvQNeeNUc= X-Received: by 2002:a1f:954c:: with SMTP id x73-v6mr14535010vkd.129.1525308241082; Wed, 02 May 2018 17:44:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.112.66 with HTTP; Wed, 2 May 2018 17:44:00 -0700 (PDT) In-Reply-To: <152410023763.28841.5479872591399614102.idtracker@ietfa.amsl.com> References: <152410023763.28841.5479872591399614102.idtracker@ietfa.amsl.com> From: Rohan Mahy Date: Wed, 2 May 2018 17:44:00 -0700 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-tram-stunbis@ietf.org, Gonzalo Camarillo , Tolga Asveren , tram-chairs@ietf.org, tram@ietf.org Content-Type: multipart/alternative; boundary="000000000000e1fda8056b427f7e" Archived-At: Subject: Re: [tram] Benjamin Kaduk's No Record on draft-ietf-tram-stunbis-16: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 03 May 2018 00:44:04 -0000 --000000000000e1fda8056b427f7e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I had a quick question about your comment on stale nonce error handling (below). If I were implementing, I would check if the nonce was fresh before checking if the password was valid. Would this potential attack be prevented if a stale nonce MUST return a 438 response whether or not the password is correct? Thanks, -rohan =E2=80=8B > The Stale Nonce behavior seems potentially worrisome, in that it > opens up a side channel for a distinguishing attack, > between a 401 and 438 response. (That is, "password correct" vs. > "password incorrect".) The impact seems rather muted, though, since > the gain to the attacker is to be able to precompute a bunch of > requests using a nonce of the attacker's choosing and blindly replay > the precomputed object against (possibly multiple) servers looking > for a guess. The realm and username are still in play, so the scope > for the attacker to gain from the precomputation seems limited. > (The same level of brute-force guessing can be obtained "live" just > by computing the trial responses against a live server, using a > valid nonce.) So, while it might be nice to give guidance that 438 > should only be used when the server can validate that it did > generate the nonce and the nonce was valid "recently", and to treat > other cases as authentication failures, it's not clear to me that > there's enough of a benefit from the change to make it worth doing. > --000000000000e1fda8056b427f7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I had a quick question about your comment o= n stale nonce error handling (below).

If I were implementing, = I would check if the nonce was fresh before checking if the password was va= lid. Would this potential attack be prevented if a stale nonce MUST return = a 438 response whether or not the password is correct?

Thanks= ,
-rohan
=E2=80=8B
The Stale Nonce behavior seems potentially wor= risome, in that it
opens up a side channel for a distinguishing attack,
between a 401 and 438 response.=C2=A0 (That is, "password correct"= ; vs.
"password incorrect".)=C2=A0 The impact seems rather muted, thoug= h, since
the gain to the attacker is to be able to precompute a bunch of
requests using a nonce of the attacker's choosing and blindly replay the precomputed object against (possibly multiple) servers looking
for a guess.=C2=A0 The realm and username are still in play, so the scope for the attacker to gain from the precomputation seems limited.
(The same level of brute-force guessing can be obtained "live" ju= st
by computing the trial responses against a live server, using a
valid nonce.)=C2=A0 So, while it might be nice to give guidance that 438 should only be used when the server can validate that it did
generate the nonce and the nonce was valid "recently", and to tre= at
other cases as authentication failures, it's not clear to me that
there's enough of a benefit from the change to make it worth doing.
=

--000000000000e1fda8056b427f7e-- From nobody Thu May 3 06:44:24 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 DE3721270AE; Thu, 3 May 2018 06:44:17 -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 yKM8szOCo1iW; Thu, 3 May 2018 06:44:16 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 7B007120454; Thu, 3 May 2018 06:44:15 -0700 (PDT) X-AuditID: 12074424-8c9ff70000003212-fc-5aeb122c0fba 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-7.mit.edu (Symantec Messaging Gateway) with SMTP id 8A.47.12818.D221BEA5; Thu, 3 May 2018 09:44:13 -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 w43Di765023987; Thu, 3 May 2018 09:44:09 -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 w43Di3vS021340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 May 2018 09:44:05 -0400 Date: Thu, 3 May 2018 08:44:03 -0500 From: Benjamin Kaduk To: Rohan Mahy Cc: The IESG , draft-ietf-tram-stunbis@ietf.org, Gonzalo Camarillo , Tolga Asveren , tram-chairs@ietf.org, tram@ietf.org Message-ID: <20180503134403.GD23530@kduck.kaduk.org> References: <152410023763.28841.5479872591399614102.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGKsWRmVeSWpSXmKPExsUixG6noqsr9DrK4NBfE4vOLZfZLDYtX8lk MePPRGaLZ1O2M1qsX/6N3WL5z5VsFh/WXmBzYPf49fUqm8fOWXfZPZYs+cnksWfOJMYAligu m5TUnMyy1CJ9uwSujG+zWxkL9vBUbJg/ibmB8TlnFyMnh4SAicSl5ja2LkYuDiGBxUwSV/ed ZoRwNjBKNO24DeVcYZKYsLWTCaSFRUBF4vOvM4wgNhuQ3dB9mRnEFhFQldj0fgELiM0scIZR 4sgPMxBbWCBconvxTrAaXqB15341soLYQgJTGCUePM2FiAtKnJz5BKpXXeLPvEtA9RxAtrTE 8n8cEGF5ieats8HGcAoESryeeRpsjKiAssTevkPsExgFZyGZNAvJpFkIk2YhmbSAkWUVo2xK bpVubmJmTnFqsm5xcmJeXmqRrrlebmaJXmpK6SZGcHS4qOxg7O7xPsQowMGoxMObcfpllBBr YllxZe4hRkkOJiVR3u8ngUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeKd0v4oS4k1JrKxKLcqH SUlzsCiJ8y7evzdKSCA9sSQ1OzW1ILUIJivDwaEkwXtI4HWUkGBRanpqRVpmTglCmomDE2Q4 D9BwOUGgGt7igsTc4sx0iPwpRkUpcd7nIM0CIImM0jy4XlDyksjeX/OKURzoFWHeCyBVPMDE B9f9CmgwE9Dgz1+fgwwuSURISTUwSs6t7LP4NbmDySuvPiI1arbyxXvrwuV84vVW6ektmdTX s9XrgX2Q/9vFXNzLj7nYe8/8dLimQPNDtVX5C9f5jq99/Dfvrln9zGKGi/I//zzx344GwYWn fwjw1zEprZ5oeZF1a/ADrfKb1+9v6DPZf8b6kM/S/IBjleodcbyXnU5cbBaWuNWhxFKckWio xVxUnAgAN14WsTkDAAA= Archived-At: Subject: Re: [tram] Benjamin Kaduk's No Record on draft-ietf-tram-stunbis-16: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 03 May 2018 13:44:18 -0000 On Wed, May 02, 2018 at 05:44:00PM -0700, Rohan Mahy wrote: > I had a quick question about your comment on stale nonce error handling > (below). > > If I were implementing, I would check if the nonce was fresh before > checking if the password was valid. Would this potential attack be > prevented if a stale nonce MUST return a 438 response whether or not the > password is correct? I believe so, yes. -Benjamin > Thanks, > -rohan > ​ > > > The Stale Nonce behavior seems potentially worrisome, in that it > > opens up a side channel for a distinguishing attack, > > between a 401 and 438 response. (That is, "password correct" vs. > > "password incorrect".) The impact seems rather muted, though, since > > the gain to the attacker is to be able to precompute a bunch of > > requests using a nonce of the attacker's choosing and blindly replay > > the precomputed object against (possibly multiple) servers looking > > for a guess. The realm and username are still in play, so the scope > > for the attacker to gain from the precomputation seems limited. > > (The same level of brute-force guessing can be obtained "live" just > > by computing the trial responses against a live server, using a > > valid nonce.) So, while it might be nice to give guidance that 438 > > should only be used when the server can validate that it did > > generate the nonce and the nonce was valid "recently", and to treat > > other cases as authentication failures, it's not clear to me that > > there's enough of a benefit from the change to make it worth doing. > > From nobody Thu May 3 16:29:11 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 63C7E12DA05; Thu, 3 May 2018 16:29:04 -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.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152539014434.11734.8429638414416770335@ietfa.amsl.com> Date: Thu, 03 May 2018 16:29:04 -0700 Archived-At: Subject: [tram] I-D Action: draft-ietf-tram-stunbis-17.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 03 May 2018 23:29:04 -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-17.txt Pages : 73 Date : 2018-05-03 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-17 https://datatracker.ietf.org/doc/html/draft-ietf-tram-stunbis-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-17 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 Thu May 3 16:32:48 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 7EFBA12DA43; Thu, 3 May 2018 16:32:40 -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 cerg0jQPQGpF; Thu, 3 May 2018 16:32:39 -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 E0D0212DA48; Thu, 3 May 2018 16:32:38 -0700 (PDT) Received: from [IPv6:2001:0:53aa:64c:18b5:3a25:f31a:9fd] (unknown [IPv6:2001:0:53aa:64c:18b5:3a25:f31a:9fd]) (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 C347FAE844; Fri, 4 May 2018 01:32:33 +0200 (CEST) From: Marc Petit-Huguenin To: Dale Worley , gen-art@ietf.org Cc: draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org References: <152237792217.20556.13689609450529144296@ietfa.amsl.com> Message-ID: <28aabbd3-db27-87a8-2b62-18ecab661d22@petit-huguenin.org> Date: Thu, 3 May 2018 16:32:30 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 03 May 2018 23:32:40 -0000 On 04/16/2018 02:49 PM, Marc Petit-Huguenin wrote: > Thanks again for the review. Comments inline. > > On 03/30/2018 04:45 AM, Dale Worley wrote: >> Reviewer: Dale Worley >> Review result: Ready with Nits >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed by >> the IESG for the IETF Chair. Please wait for direction from your >> document shepherd or AD before posting a new version of the draft. >> >> For more information, please see the FAQ at >> . >> >> Document: draft-ietf-tram-stunbis-16 >> Reviewer: Dale R. Worley >> Review Date: 2018-03-29 >> IETF LC End Date: 2018-02-20 >> IESG Telechat date: 2018-04-19 >> >> Summary: >> >> This draft is basically ready for publication, but has nits >> that should be fixed before publication. >> >> The only interesting item concerns section 17.1, where the assignment >> of meanings to bits in the "security feature set" value is different >> from the assignment in -16. This is either non-upward-compatible with >> -16, or there is an error in either -16 or -17. >> >> ---------------------------------------------------------------------- >> >> There is an issue that shows up in several places: The NAT may >> forward the request using an IP family that is different from the IP >> family that it received the request using. This means that the >> "source IP family of the request" may depend on whether one is >> speaking of the client or the server. The draft is cognizant of this, >> and mentions its consequences in sections 6.3.3 and 12. But this also >> has consequences for ALTERNATE-SERVER: Section 14.15 says "The IP >> address family MUST be identical to that of the source IP address of >> the request." even though that family might not be usable by the >> client. The draft doesn't seem to explicitly say that this comes from >> address-switching by the NAT. It would help if there was a >> higher-level discussion of this matter, pointing to the various >> consequences. > > I still do not have text about that but, as this is blocking this response since 2 weeks now, I am releasing it as is and will come back to that after I process the other reviews that accumulated during my time traveling around Europe. > Because we believe that this is a problem that will become more and more frequent, we decided to fix it, at least for new implementations. Please have a look at -17 and let us know what you think of it. Thanks. From nobody Thu May 3 16:35:01 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 BA74612DA43; Thu, 3 May 2018 16:34:55 -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 rpPRZKHRICqy; Thu, 3 May 2018 16:34:53 -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 B06AD12DA05; Thu, 3 May 2018 16:34:53 -0700 (PDT) Received: from [IPv6:2001:0:53aa:64c:18b5:3a25:f31a:9fd] (unknown [IPv6:2001:0:53aa:64c:18b5:3a25:f31a:9fd]) (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 75022AE844; Fri, 4 May 2018 01:34:49 +0200 (CEST) From: Marc Petit-Huguenin To: Eric Rescorla , The IESG Cc: draft-ietf-tram-stunbis@ietf.org, tram-chairs@ietf.org, Gonzalo.Camarillo@ericsson.com, tasveren@rbbn.com, tram@ietf.org References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> Message-ID: <31a441d2-8843-c8ee-f5ef-5496e5b4b364@acm.org> Date: Thu, 3 May 2018 16:34:47 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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.22 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: Thu, 03 May 2018 23:34:56 -0000 On 04/22/2018 02:02 PM, Marc Petit-Huguenin wrote: > Hi Eric, > > Thanks for the review, please see my responses inline. > > On 04/16/2018 12:57 PM, Eric Rescorla wrote: >> Eric Rescorla has entered the following ballot position for >> draft-ietf-tram-stunbis-16: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Rich version of this review at: >> https://mozphab-ietf.devsvcdev.mozaws.net/D5132 >> >> >> Can you please indicate how you addressed the points Matt Miller >> raised in his secdir review about the use of MD5. > > From my response on 2018-03-11: > >> * The description for 17.5.1. "MD5" list the key size as 20 bytes, but the >> hash length of MD5 is 16 bytes (128 bits). I think this is merely a typo, >> since the purpose appears to be for backwards compatibility with existing >> systems. > > Fixed. > >> >> * Both 17.5.1.1. "MD5" Section 9.2.2. "HMAC Key" (long-term credential) >> and Section appear to define the same functional algorithm, but with subtle >> syntax differences. As far as I can tell, they are actually the same >> algorithm; would it not be acceptable to have Section 9.2.2 point to >> Section 17.5.1.1 for the algorithm description? >> >> > > This is going into the IANA registry so I left things there. I fixed the discrepancy with section 9.2.2. > > I also fixed the definition of the key for SHA-256, which must use OpaqueString for the realm. > >> >> >> >> DETAIL >>> by the agent sending the indication. It primarily serves to >>> correlate requests with responses, though it also plays a small role >>> in helping to prevent certain types of attacks. The server also uses >>> the transaction ID as a key to identify each transaction uniquely >>> across all clients. As such, the transaction ID MUST be uniformly >>> and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be >> >> I didn't realize this was a SHOULD. ICE depends on it as a security >> condition, so it probably needs to be a MUST. > > Done. > >> >> >>> 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. > >> >> >>> STUN Security Feature it is understood that the corresponding STUN >>> Security Feature bit in the "nonce cookie" is set to 1. >>> >>> For example, in Section 9.2.4 discussing the PASSWORD-ALGORITHMS >>> security feature, it is implied that the "Password algorithms" bit, >>> as defined in Section 17.1, is set to 1 in the "nonce cookie". >> >> I'm not sure I understand the bid down attack here or the proposed >> defense. Can you please walk through what the assumed attacker >> capabilities are, what the client and server capabilities are, how the >> bid down attack works, and how this protects against it? > > The plan is to add an annex to the document explaining that. I'll finish to process the other reviews from the IESG and then come back to that. > Instead of an annex, we added a new section in the Security Considerations. Please have a look at -17 and let us know if that explanation is good enough. Thanks. From nobody Thu May 3 16:35:53 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 C6BE312DA05 for ; Thu, 3 May 2018 16:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Ywr8npiyHg6A for ; Thu, 3 May 2018 16:35:42 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (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 7309F12DA43 for ; Thu, 3 May 2018 16:35:42 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id m11-v6so16443587otf.3 for ; Thu, 03 May 2018 16:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9PqAb68NDHbdHGm3ISwNk6n09yGuIh5ZDpH4Qt9UUCk=; b=UqpCemfeDtefsBjk7hoMmb59jWPT6UwOZw1r76GYuTXI67UAIfNIMXsZQVV15twlAm bK3TuthEEF298gBfcjQWf2UbkJ3L1ZGgZl0eO4lmHKt+GXSvF9JKWqO0elGo1TUo3W6x L3suI7qH5cA9MYbqHBvCT5phfFiutWPF/dUHVdZormr1aSU4Br3tMBVr39ZT75T7SaZT /Ap73NWPT0r8wcBgBw01M4C2oohGPL92g/kWV+G2zAeSVLLwgvbHj6OePU3n8+dtU1ds jmM8hZBLexLVxBoC97KzkSO0xcp2CWnQ9TlrRVkj7XUbQw1u8x2GeA5J6JH6RUX8m8ad uqGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9PqAb68NDHbdHGm3ISwNk6n09yGuIh5ZDpH4Qt9UUCk=; b=HXtHmfa7y2O4K1fqBOaaByKlY9GxyCFVMeDEGjHGxefh/VZ1c7Q89GadtRU8Iiuv6e 5nXeD/q1AX4rLdNkbACukhxjjEZAUmJTtR+WF7jZ7WJ6miBV076kS0f5FCQ4L+WKpBUx ZzhnL5wxBHDJ/nxZNQ605yj4s4gq/jDRwDsfo8xOkkm9r8cE/pRiDfianqsi6XSkGTJW T/BDtgcQBA5UCzy77IMOrBgQaAbGlmIfphWWRjrRbfiihEu2VzKkgfNQ/0jDQn4ZAr38 qezBVMHUR7Gu4l7vFvwXCMv+24t48SZhZ710diOhm0WdyK057T89U8mDWIcZ4bhwciDC tEAA== X-Gm-Message-State: ALQs6tDkY2nKvFqTv+lSRaRBlxtKhiT1aoaMqThSaVLHw61RQm8ex9o1 n4vrxHvPqPCHrAZxQgtTW+IKmF1ciLp1zS+owIUh+g== X-Google-Smtp-Source: AB8JxZqVWE5NKYBcaScrCSZoMYDEKKRUOwrEfAcp9pl00lnAQQVzzz/37Txf8Pg8UMwKTU8sXeXEtVdUBlxymvQXCNA= X-Received: by 2002:a9d:334f:: with SMTP id u15-v6mr17081667otd.214.1525390541756; Thu, 03 May 2018 16:35:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Thu, 3 May 2018 16:35:01 -0700 (PDT) In-Reply-To: <02569943-db8f-654e-7322-49bc1f1a1163@acm.org> References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <02569943-db8f-654e-7322-49bc1f1a1163@acm.org> From: Eric Rescorla Date: Thu, 3 May 2018 16:35:01 -0700 Message-ID: To: Marc Petit-Huguenin Cc: tram-chairs@ietf.org, tram@ietf.org, Gonzalo Camarillo , tasveren@rbbn.com, The IESG , draft-ietf-tram-stunbis@ietf.org Content-Type: multipart/alternative; boundary="00000000000062b5bb056b55a9ba" 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.22 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: Thu, 03 May 2018 23:35:47 -0000 --00000000000062b5bb056b55a9ba Content-Type: text/plain; charset="UTF-8" On Mon, Apr 23, 2018 at 11:16 AM, Marc Petit-Huguenin wrote: > On 04/22/2018 05:22 PM, Eric Rescorla wrote: > > On Sun, Apr 22, 2018 at 2:02 PM, Marc Petit-Huguenin > > 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 > >> > >> 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 > > --00000000000062b5bb056b55a9ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Apr 23, 2018 at 11:16 AM, Marc Petit-Huguenin <petithug@acm.org= > wrote:
O= n 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:
>
>>
>>>>=C2=A0 =C2=A0 =C2=A0 For a request or indication message, t= he agent MUST include the
>>>>=C2=A0 =C2=A0 =C2=A0 USERNAME, MESSAGE-INTEGRITY-SHA256, an= d MESSAGE-INTEGRITY
>> attributes
>>>>=C2=A0 =C2=A0 =C2=A0 in the message unless the agent knows = from an external indication
>>>>=C2=A0 =C2=A0 =C2=A0 which message integrity algorithm is s= upported by both agents.=C2=A0 In
>>>>=C2=A0 =C2=A0 =C2=A0 this case either MESSAGE-INTEGRITY or = MESSAGE-INTEGRITY-SHA256 MUST
>>>>=C2=A0 =C2=A0 =C2=A0 be included in addition to USERNAME.= =C2=A0 The HMAC for the MESSAGE-
>>>
>>> This text appears to conflict with S 7.3 of 5245-bis, which sa= ys:
>>
>> [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 sam= e time
> which
> make contrary recommendations about the same basic protocol is un-good= .

Sure, but wouldn't it be simpler to have rfc5245bis using stunbi= s and have them updating their text, more than adding some tortuous text in= stunbis?

>
>
>>>=C2=A0 =C2=A0 =C2=A0 The STUN usage must specify which transpor= t protocol is used, and
>> how
>>>>=C2=A0 =C2=A0 =C2=A0 the agent determines the IP address an= d port of the recipient.
>>>>=C2=A0 =C2=A0 =C2=A0 Section 8 describes a DNS-based method= of determining the IP
>> address
>>>>=C2=A0 =C2=A0 =C2=A0 and port of a server that a usage may = elect to use.=C2=A0 STUN may be
>> used
>>>>=C2=A0 =C2=A0 =C2=A0 with anycast addresses, but only with = UDP and in usages where
>>>>=C2=A0 =C2=A0 =C2=A0 authentication is not used.
>>>
>>> Why this restriction? You should be able to use anycast with l= ong-term
>>> AUTH for (say) TURN.
>>
>> https://www.ietf.org/mail= -archive/web/behave/current/msg03582.html
>>
>> I think that the decision of permitting Anycast should be left to = each
>> STUN Usage.=C2=A0 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:
>>
>>=C2=A0 =C2=A0 o=C2=A0 If Anycast addresses can be used for the serv= er in case TCP or
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0TLS-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 t= he bullet points:

=C2=A0 =C2=A0A STUN usage defines how STUN is actually utilized -- when to = send
=C2=A0 =C2=A0requests, what to do with the responses, and which optional =C2=A0 =C2=A0procedures defined here (or in an extension to STUN) are to be= used.
=C2=A0 =C2=A0A usage also defines:

[...]

=C2=A0 =C2=A0o=C2=A0 If Anycast addresses can be used for the server in cas= e TCP or
=C2=A0 =C2=A0 =C2=A0 TLS-over-TCP, or authentication are used.

What is the need for the restriction at all.=

=C2=A0
<= span class=3D"">>>>>=C2=A0 =C2=A0 =C2= =A0 transaction over UDP or DTLS-over-UDP is also considered failed if
>>>>=C2=A0 =C2=A0 =C2=A0 there has been a hard ICMP error [RFC1= 122].=C2=A0 For example, assuming
>> an
>>>>=C2=A0 =C2=A0 =C2=A0 RTO of 500ms, requests would be sent a= t times 0 ms, 500 ms, 1500
>> ms,
>>>>=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 received a response after 39500 ms, th= e client will consider the
>>>>=C2=A0 =C2=A0 =C2=A0 transaction to have timed out.
>>>
>>> I note that these recommendations now seem crazily long. I ass= ume 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 th= an in RFC 5389.
>>
>
> Yes, I know. My point is that while they might have bee sensible when<= br> > 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.
<= div>


> This would be good to explain.

New text:

=C2=A0 =C2=A0[...]
=C2=A0 =C2=A0containing the subjectAltName of that certificate.=C2=A0 The t= est on the
=C2=A0 =C2=A0MESSAGE-INTEGRITY-SHA256 attribute indicates that the transact= ion is
=C2=A0 =C2=A0authenticated and that the client implements this specificatio= n and
=C2=A0 =C2=A0so can process the ALTERNATE-DOMAIN attribute.

All right.


>
>
>>>>=C2=A0 =C2=A0 =C2=A0 o=C2=A0 What authentication and messag= e-integrity mechanisms are used.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 o=C2=A0 The considerations around manu= al vs. automatic key derivation
>> for
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the integrity mechanism, = as discussed in [RFC4107].
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 o=C2=A0 What mechanisms are used to di= stinguish 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.=C2=A0 RFC 5764/798= 3 is one such
>> mechanism, but there is nothing that prevent another protocol stac= k to use
>> a different mechanism (inference, shim, etc...)
>>
>
> But ultimately no matter what the other protocol provides for demux, S= TUN
> has its
> own demux.

In fact I think that the reason for that item was because FINGERPRIN= T can also be used to demux STUN traffic, but it is optional.=C2=A0 So an S= TUN Usage needs to tell if FINGERPRINT is mandatory (like in ICE).

This should be explained.

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

>>>
>>>>=C2=A0 =C2=A0 =C2=A0 that is not readily subject to offline= dictionary attacks.
>>>>=C2=A0 =C2=A0 =C2=A0 Protection of the channel itself, usin= g TLS or DTLS, mitigates
>> these
>>>>=C2=A0 =C2=A0 =C2=A0 attacks.
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 STUN supports both MESSAGE-INTEGRITY a= nd MESSAGE-INTEGRITY-SHA256,
>>>>=C2=A0 =C2=A0 =C2=A0 which is subject to bid down attacks b= y an on-path attacker.
>>>
>>> By an on-path attacker who can forge HMAC-SHA1 in real-time? T= hat's a
>>> pretty serious adversary, so you should clarify here
>>>
>>
>> New text:
>>
>>=C2=A0 =C2=A0 STUN supports both MESSAGE-INTEGRITY and MESSAGE-INTE= GRITY-SHA256,
>>=C2=A0 =C2=A0 which is subject to bid down attacks by an on-path at= tacker that
>>=C2=A0 =C2=A0 would strip the MESSAGE-INTEGRITY-SHA256 attribute le= aving only the
>>=C2=A0 =C2=A0 MESSAGE-INTEGRITY attribute and exploiting a potentia= l vulnerability.
>>=C2=A0 =C2=A0 Protection of the channel itself, using TLS or DTLS, = mitigates these
>>=C2=A0 =C2=A0 attacks.=C2=A0 Timely removal of the support of MESSA= GE-INTEGRITY in a
>>=C2=A0 =C2=A0 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 th= at the protocol has a downgrade
attack, but rather that the minim= um 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


--00000000000062b5bb056b55a9ba-- From nobody Thu May 3 16:37:41 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 7B40512EB8B; Thu, 3 May 2018 16:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-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 C6PM6GECYQ9m; Thu, 3 May 2018 16:37:29 -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 7CE9712EB5A; Thu, 3 May 2018 16:37:29 -0700 (PDT) Received: from [IPv6:2001:0:53aa:64c:18b5:3a25:f31a:9fd] (unknown [IPv6:2001:0:53aa:64c:18b5:3a25:f31a:9fd]) (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 13084AE844; Fri, 4 May 2018 01:37:25 +0200 (CEST) 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 References: <152403138853.31946.14807823535362928987.idtracker@ietfa.amsl.com> <27cb2f70-d907-b61f-bb5a-6b19053238fe@petit-huguenin.org> Message-ID: <1e8cd5de-06de-6745-fc4d-d15fcdd0b4d9@petit-huguenin.org> Date: Thu, 3 May 2018 16:37:22 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <27cb2f70-d907-b61f-bb5a-6b19053238fe@petit-huguenin.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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.22 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: Thu, 03 May 2018 23:37:35 -0000 On 04/23/2018 03:37 PM, Marc Petit-Huguenin wrote: > Hi Adam, > > Thanks for the review, please see my responses inline. > > This is also the last review I can process until Saturday 28. The remaining of the work to do on stunbis is: > > - process Alexey Melnikov review > - process Process Benjamin Kaduk review > - add text for Dale Worley point on IPv6 NAT > - add text explaining the bid-attack protection mechanism > - work on answer to §6.2.3 below > - answer additional concerns following my responses > - final review for language > - publish -17 > > > On 04/17/2018 11:03 PM, Adam Roach wrote: >> Adam Roach has entered the following ballot position for >> draft-ietf-tram-stunbis-16: Discuss >> > > [...] > >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Thanks to everyone who worked on this revision of the STUN protocol. Thanks in >> particular to the ARTART reviewer and to the authors for actively engaging on >> the points he raised. >> >> I have one concern about interoperability and another about the IANA changes >> that I believe require changes to the document prior to publication. >> >> §14.2: >> >>> X-Port is computed by taking the mapped port in host byte order, >>> XOR'ing it with the most significant 16 bits of the magic cookie, and >>> then the converting the result to network byte order. If the IP >>> address family is IPv4, X-Address is computed by taking the mapped IP >>> address in host byte order, XOR'ing it with the magic cookie, and >>> converting the result to network byte order. If the IP address >>> family is IPv6, X-Address is computed by taking the mapped IP address >>> in host byte order, XOR'ing it with the concatenation of the magic >>> cookie and the 96-bit transaction ID, and converting the result to >>> network byte order. >> >> The discussion of performing operations "in host byte order" is very confusing, >> and seems likely to cause issues communicating between machines of different >> endianness. As an implementor, based on this description, I cannot tell >> whether, given a port of 0x1234 (and operating on a little-endian machine), >> I'm supposed to do: >> >> Port (host order): 34 12 >> Magic Cookie Prefix: 21 12 >> Result (host order): 15 00 >> X-Port (net order): 00 15 >> >> or: >> >> Port (host order): 34 12 >> Magic Cookie Prefix: 12 21 >> Result (host order): 26 33 >> X-Port (net order): 33 26 >> >> One of these is clearly wrong. I think it's the first one, but I *also* think >> that the first one is the most straightforward interpretation of the quoted >> paragraph. >> >> The following would seem to be a complete description of the >> operation without introducing possible confusion about the difference between >> host and network order: >> >> X-Port is computed by XOR'ing the mapped port with the most significant 16 >> bits of the magic cookie. If the IP address family is IPv4, X-Address is >> computed XOR'ing the mapped IP with the magic cookie. If the IP address >> family is IPv6, X-Address is computed by XOR'ing the mapped IP address with >> the concatenation of the magic cookie and the 96-bit transaction ID. In all >> cases, the XOR operation works on its inputs in network byte order (that is, >> the order they will be encoded in the message). >> >> This makes it clear that the proper operation is: >> >> Port: 12 34 >> Magic Cookie Prefix: 21 12 >> Result / X-Port: 33 26 > > It seems that you are advocating the opposite of what is traditionally done on that subject: Always do all the calculations using the computer order and eventually convert to/from the network order when writing/reading a packet. That basically force all little-endian computers (which is most computers nowadays) to do their work in big-endian format. > > If there is some ambiguity in the text, I am all for fixing it, for example by saying that the 16 bits of the magic cookie, the magic cookie and the concatenation of the magic cookie and the 96-bit transaction ID should all be converted into host byte order before been used with the XOR operation - which is done automatically when loading them in integer variables. > >> >> --------------------------------------------------------------------------- >> >> §17.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-REQUEST) >> >> The attribute 0x0003 is registered by RFC 5780, and should not be removed by this document. > > Fixed. > >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> §3: >> >> This is almost, but not quite, the boilerplate defined by RFC 8174. Please >> update to match the text in RFC 8174. > > Already fixed following a previous review. > >> >> --------------------------------------------------------------------------- >> >> §5: >> >>> server to detect if the client will understand certain attributes >>> that were added in this revised specification. >> >> This is a *bit* misleading, as these attributes were actually added in RFC 5389. >> Consider: "...that were added to STUN by [RFC5389]." > > Applied. > >> >> --------------------------------------------------------------------------- >> >> §6.1: >> >>> If the agent is sending a request, it SHOULD add a SOFTWARE attribute >>> to the request. >> >> I believe this would benefit from a pointer to the security section; e.g.: >> "Note that the inclusion of a SOFTWARE attribute may have security >> implications; see Section 15.1.2 for details." > > Applied. > >> >> --------------------------------------------------------------------------- >> >> §6.2: >> >>> STUN may be used >>> with anycast addresses, but only with UDP and in usages where >>> authentication is not used. >> >> This bit of operational advice seems out of place in the middle of an >> implementation discussion, and is quite likely to be missed by its intended >> audience. Consider relocating it to an "Operational Considerations" section. > > Done. > >> >> --------------------------------------------------------------------------- >> >> §6.2.1: >> >>> As with TCP, the usage of Karn's >>> algorithm is RECOMMENDED [KARN87]. >> >> This normative language means that [KARN87] needs to be a normative reference. > > Done. > >> >> --------------------------------------------------------------------------- >> >> §6.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 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 §8.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 §6.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 you could suggest some text to address that one. Thanks. From nobody Thu May 3 16:45: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 1ADFE12E884 for ; Thu, 3 May 2018 16:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ac_BYaO-27l8 for ; Thu, 3 May 2018 16:45:50 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 03C2112E034 for ; Thu, 3 May 2018 16:45:50 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id k5-v6so10863754oiw.0 for ; Thu, 03 May 2018 16:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZErh6SYyqcHOKTQtgJUo2EAFeU1w0RAc5pJKVSjDGpM=; b=z+SotQcijEtbIQGFpPsyXrRp582s+4NfkqFNJ/htp+VnF5G+aFikEiFsvPvgzb6HZV VK507ZjvD2cYMuBUMZroRpWupgpPZml/+Rb1E4ZGVKD3bFsmZun9cFMnlzmTMU8SAgfx 4pFiJCMoBpf2dW4XSqQ39SVU0BegMFIz+yI2mLUvi8a1UCUsnjEkQxVPpC6iv8TZLea7 my+/XWZzWwB8Gn+Dx5UPPygppxaPoAaDwsBJ2uaXGWsNxGadUrD4MjVqA25oblvaK0Vu jKrkWBNonq0GqBHr2xY8pmtclzGDMF0d94kUticpTb5AxjDOqf+UtLN4WmCG2Ra70JGz B55Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZErh6SYyqcHOKTQtgJUo2EAFeU1w0RAc5pJKVSjDGpM=; b=DjiKsSZCidSMezUS1tV3PgU4yC7Vwtl7ckKilqjJ5JhkduJz48jSbJxM2vNE+SmsFz Kn/AJjsX5aTlO2nee+KrYv84NYnujKHkiuWX5K3PnHplNC+SOJSbmYKXpewGTqCwIhzU 9Op8aZgwbX5EV0kMFlmEmRFR6Rj3DeDq7mMOkGsqTnc0pcXYbnKq4uh6jJeJlquMxXkq 4r3FfT69piNh85BVXjWLfwnPmfznpmBE9UkRZZn6wZflk/a4TPJ6m2apDSBzwL46uhxd UM7+BYBd+9wtgtwanOGbrHpZRxKGf33Z6uJI1B4e0uT+NyWkiVUVdBB4WVrkvJ5v0t6x ypcw== X-Gm-Message-State: ALQs6tB9zJn7z9axiP2kTlruMeuHSBoPry4kqM01SdGPl+olrE5pja/3 P0PsV2YFZ/a2OmAiipCZfyC3WAX9BG/RgKTL6z8SiA== X-Google-Smtp-Source: AB8JxZpTODeTtoX/+2A25cQZHQM6Ic4XyJ06+2FqGeMO4kiDSi2/CFS7Y9toaUG3tBN6bXkkOXMuqaToxhn2ZY/tvnw= X-Received: by 2002:aca:ea46:: with SMTP id i67-v6mr16261782oih.174.1525391149337; Thu, 03 May 2018 16:45:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Thu, 3 May 2018 16:45:08 -0700 (PDT) In-Reply-To: <31a441d2-8843-c8ee-f5ef-5496e5b4b364@acm.org> References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <31a441d2-8843-c8ee-f5ef-5496e5b4b364@acm.org> From: Eric Rescorla Date: Thu, 3 May 2018 16:45:08 -0700 Message-ID: To: Marc Petit-Huguenin Cc: The IESG , draft-ietf-tram-stunbis@ietf.org, tram-chairs@ietf.org, Gonzalo Camarillo , tasveren@rbbn.com, tram@ietf.org Content-Type: multipart/alternative; boundary="00000000000099aba2056b55cd85" 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.22 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: Thu, 03 May 2018 23:45:53 -0000 --00000000000099aba2056b55cd85 Content-Type: text/plain; charset="UTF-8" No, I don't understand this at all. This section talks about a bid-down on the PASSWORD-ALGORITHM, but I don't see how a weakness in MD5 is relevant here. Assuming I understand correctly, the structure of the protocol is that given a password, you do: key = Password-Algorithm(username, realm, password) And then use key with HMAC for an integrity check, where HMAC is SHA-1 (with MESSAGE-INTEGRITY) or SHA-256 (with MESSAGE-INTEGRITY-SHA256). However, in this case the MD5 isn't a security critical component at the protocol layer [0], because it's just is just to act as a transformation of the password into a fixed-length string for use as a key, so this doesn't require collision resistance or pseudorandomness. I could be wrong here, but if so, please describe a potential weakness in MD5 which could lead to compromise of this protocol -Ekr [0] It might be an issue if someone were to recover the hashed password. On Thu, May 3, 2018 at 4:34 PM, Marc Petit-Huguenin wrote: > On 04/22/2018 02:02 PM, Marc Petit-Huguenin wrote: > > Hi Eric, > > > > Thanks for the review, please see my responses inline. > > > > On 04/16/2018 12:57 PM, Eric Rescorla wrote: > >> Eric Rescorla has entered the following ballot position for > >> draft-ietf-tram-stunbis-16: Discuss > >> > >> When responding, please keep the subject line intact and reply to all > >> email addresses included in the To and CC lines. (Feel free to cut this > >> introductory paragraph, however.) > >> > >> > >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > >> for more information about IESG DISCUSS and COMMENT positions. > >> > >> > >> The document, along with other ballot positions, can be found here: > >> https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ > >> > >> > >> > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> Rich version of this review at: > >> https://mozphab-ietf.devsvcdev.mozaws.net/D5132 > >> > >> > >> Can you please indicate how you addressed the points Matt Miller > >> raised in his secdir review about the use of MD5. > > > > From my response on 2018-03-11: > > > >> * The description for 17.5.1. "MD5" list the key size as 20 bytes, but > the > >> hash length of MD5 is 16 bytes (128 bits). I think this is merely a > typo, > >> since the purpose appears to be for backwards compatibility with > existing > >> systems. > > > > Fixed. > > > >> > >> * Both 17.5.1.1. "MD5" Section 9.2.2. "HMAC Key" (long-term credential) > >> and Section appear to define the same functional algorithm, but with > subtle > >> syntax differences. As far as I can tell, they are actually the same > >> algorithm; would it not be acceptable to have Section 9.2.2 point to > >> Section 17.5.1.1 for the algorithm description? > >> > >> > > > > This is going into the IANA registry so I left things there. I fixed > the discrepancy with section 9.2.2. > > > > I also fixed the definition of the key for SHA-256, which must use > OpaqueString for the realm. > > > >> > >> > >> > >> DETAIL > >>> by the agent sending the indication. It primarily serves to > >>> correlate requests with responses, though it also plays a small > role > >>> in helping to prevent certain types of attacks. The server also > uses > >>> the transaction ID as a key to identify each transaction uniquely > >>> across all clients. As such, the transaction ID MUST be uniformly > >>> and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be > >> > >> I didn't realize this was a SHOULD. ICE depends on it as a security > >> condition, so it probably needs to be a MUST. > > > > Done. > > > >> > >> > >>> 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. > > > >> > >> > >>> STUN Security Feature it is understood that the corresponding STUN > >>> Security Feature bit in the "nonce cookie" is set to 1. > >>> > >>> For example, in Section 9.2.4 discussing the PASSWORD-ALGORITHMS > >>> security feature, it is implied that the "Password algorithms" > bit, > >>> as defined in Section 17.1, is set to 1 in the "nonce cookie". > >> > >> I'm not sure I understand the bid down attack here or the proposed > >> defense. Can you please walk through what the assumed attacker > >> capabilities are, what the client and server capabilities are, how the > >> bid down attack works, and how this protects against it? > > > > The plan is to add an annex to the document explaining that. I'll > finish to process the other reviews from the IESG and then come back to > that. > > > > Instead of an annex, we added a new section in the Security > Considerations. Please have a look at -17 and let us know if that > explanation is good enough. > > Thanks. > --00000000000099aba2056b55cd85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No, I don't understand this at all. This section = talks about a bid-down on the PASSWORD-ALGORITHM, but I don't see how a= weakness in MD5 is relevant here.

Assuming I unde= rstand correctly, the structure of the protocol is that given a password, y= ou do:

=C2=A0=C2=A0 key =3D Password-Algorithm(use= rname, realm, password)

And then use key with HMAC= for an integrity check, where HMAC is SHA-1 (with MESSAGE-INTEGRITY) or SH= A-256 (with MESSAGE-INTEGRITY-SHA256). However, in this case the MD5 isn= 9;t a security critical component at the protocol layer [0], because it'= ;s just is just to act as a transformation of the password into a fixed-len= gth string for use as a key, so this doesn't require collision resistan= ce or pseudorandomness. I could be wrong here, but if so, please describe a= potential weakness in MD5 which could lead to compromise of this protocol<= br>

-Ekr

[0] It might be = an issue if someone were to recover the hashed password.

On Thu, May 3, 2018 = at 4:34 PM, Marc Petit-Huguenin <petithug@acm.org> wrote:
=
On 0= 4/22/2018 02:02 PM, Marc Petit-Huguenin wrote:
> Hi Eric,
>
> Thanks for the review, please see my responses inline.
>
> On 04/16/2018 12:57 PM, Eric Rescorla wrote:
>> Eric Rescorla has entered the following ballot position for
>> draft-ietf-tram-stunbis-16: Discuss
>>
>> When responding, please keep the subject line intact and reply to = all
>> email addresses included in the To and CC lines. (Feel free to cut= this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.o= rg/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here= :
>> https://datatracker.ietf.org/= doc/draft-ietf-tram-stunbis/
>>
>>
>>
>> ------------------------------------------------------------<= wbr>----------
>> DISCUSS:
>> ------------------------------------------------------------<= wbr>----------
>>
>> Rich version of this review at:
>> https://mozphab-ietf.devsvcdev.mozaws.n= et/D5132
>>
>>
>> Can you please indicate how you addressed the points Matt Miller >> raised in his secdir review about the use of MD5.
>
> From my response on 2018-03-11:
>
>> * The description for 17.5.1. "MD5" list the key size as= 20 bytes, but the
>> hash length of MD5 is 16 bytes (128 bits).=C2=A0 I think this is m= erely a typo,
>> since the purpose appears to be for backwards compatibility with e= xisting
>> systems.
>
> Fixed.
>
>>
>> * Both 17.5.1.1. "MD5" Section 9.2.2. "HMAC Key&quo= t; (long-term credential)
>> and Section appear to define the same functional algorithm, but wi= th subtle
>> syntax differences.=C2=A0 As far as I can tell, they are actually = the same
>> algorithm; would it not be acceptable to have Section 9.2.2 point = to
>> Section 17.5.1.1 for the algorithm description?
>>
>>
>
> This is going into the IANA registry so I left things there.=C2=A0 I f= ixed the discrepancy with section 9.2.2.
>
> I also fixed the definition of the key for SHA-256, which must use Opa= queString for the realm.
>
>>
>>
>>
>> DETAIL
>>>=C2=A0 =C2=A0 =C2=A0 by the agent sending the indication.=C2=A0= It primarily serves to
>>>=C2=A0 =C2=A0 =C2=A0 correlate requests with responses, though = it also plays a small role
>>>=C2=A0 =C2=A0 =C2=A0 in helping to prevent certain types of att= acks.=C2=A0 The server also uses
>>>=C2=A0 =C2=A0 =C2=A0 the transaction ID as a key to identify ea= ch transaction uniquely
>>>=C2=A0 =C2=A0 =C2=A0 across all clients.=C2=A0 As such, the tra= nsaction ID MUST be uniformly
>>>=C2=A0 =C2=A0 =C2=A0 and randomly chosen from the interval 0 ..= 2**96-1, and SHOULD be
>>
>> I didn't realize this was a SHOULD. ICE depends on it as a sec= urity
>> condition, so it probably needs to be a MUST.
>
> Done.
>
>>
>>
>>>=C2=A0 =C2=A0 =C2=A0 For a request or indication message, the a= gent MUST include the
>>>=C2=A0 =C2=A0 =C2=A0 USERNAME, MESSAGE-INTEGRITY-SHA256, and ME= SSAGE-INTEGRITY attributes
>>>=C2=A0 =C2=A0 =C2=A0 in the message unless the agent knows from= an external indication
>>>=C2=A0 =C2=A0 =C2=A0 which message integrity algorithm is suppo= rted by both agents.=C2=A0 In
>>>=C2=A0 =C2=A0 =C2=A0 this case either MESSAGE-INTEGRITY or MESS= AGE-INTEGRITY-SHA256 MUST
>>>=C2=A0 =C2=A0 =C2=A0 be included in addition to USERNAME.=C2=A0= The HMAC for the MESSAGE-
>>
>> This text appears to conflict with S 7.3 of 5245-bis, which says:<= br> >
> [text missing]
>
> Hmm, no, RFC245bis is still referencing RFC5389, so the procedure for = stunbis does not apply.
>
>>
>>
>>>=C2=A0 =C2=A0 =C2=A0 STUN Security Feature it is understood tha= t the corresponding STUN
>>>=C2=A0 =C2=A0 =C2=A0 Security Feature bit in the "nonce co= okie" is set to 1.
>>>
>>>=C2=A0 =C2=A0 =C2=A0 For example, in Section 9.2.4 discussing t= he PASSWORD-ALGORITHMS
>>>=C2=A0 =C2=A0 =C2=A0 security feature, it is implied that the &= quot;Password algorithms" bit,
>>>=C2=A0 =C2=A0 =C2=A0 as defined in Section 17.1, is set to 1 in= the "nonce cookie".
>>
>> I'm not sure I understand the bid down attack here or the prop= osed
>> defense.=C2=A0 Can you please walk through what the assumed attack= er
>> capabilities are, what the client and server capabilities are, how= the
>> bid down attack works, and how this protects against it?
>
> The plan is to add an annex to the document explaining that.=C2=A0 I&#= 39;ll finish to process the other reviews from the IESG and then come back = to that.
>

Instead of an annex, we added a new section in the Security Con= siderations.=C2=A0 Please have a look at -17 and let us know if that explan= ation is good enough.

Thanks.

--00000000000099aba2056b55cd85-- From nobody Thu May 3 18:32: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 0073512DA06 for ; Thu, 3 May 2018 18:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, 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 1-6sJyQZWUpX for ; Thu, 3 May 2018 18:32:39 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (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 CA10B12D93E for ; Thu, 3 May 2018 18:32:39 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-10v.sys.comcast.net with ESMTP id EP0WfU0lx8Vr2EPaQfKyc2; Fri, 04 May 2018 01:32:38 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-14v.sys.comcast.net with ESMTPA id EPaPfJHnp1FLWEPaPf1S9n; Fri, 04 May 2018 01:32:38 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id w441WaSv010906; Thu, 3 May 2018 21:32:36 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w441WZix010890; Thu, 3 May 2018 21:32:35 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Marc Petit-Huguenin Cc: gen-art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org In-Reply-To: <28aabbd3-db27-87a8-2b62-18ecab661d22@petit-huguenin.org> (marc@petit-huguenin.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 03 May 2018 21:32:35 -0400 Message-ID: <87d0yc434c.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfOcngeLaFjJsIXPysQ5HZbRwBgP5auUJa/hFz0l13qkqFR9KBjNpx9O5aDGGc8xmIC1WBWg/BoPZ6MUqWYC+t9Ct8024C0qvkBtNaKcdoMoox9YOOgee DaA+82WTrXjVboFIys74/TUO63mpmXfrQQvS3B90dJ2MR+GbG1XRh7EJmqwy01QA8dUKpYhYWyP2sVgi9fRrTEq5cKE0pm2SMZYiKimKTLd4j5lQMFVSHLJU fz5gEkvzmCyEDb+Px3RuWgBXGvCNrnSCyI4umI8Mgpyui7tTVsyGafioahoHVjRR7KOFy/smWTe3OXjdMtB+kRb4z0j3yHBFNfziUMtaesfXFO3d+DlQuXK4 Mr5kjnNVzxX2Oh9vdCv/ruKZWi8rkw== Archived-At: Subject: Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 04 May 2018 01:32:41 -0000 Marc Petit-Huguenin writes: > Because we believe that this is a problem that will become more and > more frequent, we decided to fix it, at least for new implementations. > > Please have a look at -17 and let us know what you think of it. It looks like you've handled the problem of a NAT that changes the address family of the request as well as can be done. You've clarified the question of how the security feature bits are assigned, although I note that -16 and -17 assign the bits differently than versions -7 through -15 do. That completes all of the significant issues from my review of -16. And there are some nits: 6.2.1. Sending over UDP or DTLS-over-UDP SHOULD be greater or equal than 500 ms. s/equal than/equal to/. 6.2.3. Sending over TLS-over-TCP or DTLS-over-UDP To do that, it follows the identification procedures defined in [RFC6125], with a certificate containing an identifier of type DNS-ID or CN-ID, eventually with wildcards, but not of type SRV-ID or URI-ID. The meaning of "eventually" here is not clear. 14. STUN Attributes The padding bits MUST be set to zero on sending and must be ignored by the receiver. I assume the latter "must" is supposed to be "MUST". 14.13. UNKNOWN-ATTRIBUTES Note: In [RFC3489], this field was padded to 32 by duplicating the last attribute. In this version of the specification, thPetriNet m --> PetriNet m --> e normal padding rules for attributes are used instead. I assume that "thPetriNet m --> PetriNet m --> e" is intended to be "the". Appendix C. Release notes Section C.8 has the same contents as section C.9, but section C.9 has the same title as section C.10. (Although section C will be removed before publication, so it's not important.) Dale From nobody Fri May 4 09:18:21 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 E4505126579; Fri, 4 May 2018 09:18:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-tram-stunbis@ietf.org, Gonzalo.Camarillo@ericsson.com, Tolga Asveren , tram-chairs@ietf.org, tasveren@rbbn.com, tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152545069888.11705.18164400496131070098.idtracker@ietfa.amsl.com> Date: Fri, 04 May 2018 09:18:18 -0700 Archived-At: Subject: [tram] Alexey Melnikov's No Objection on draft-ietf-tram-stunbis-17: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 04 May 2018 16:18:19 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-tram-stunbis-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS points and comments. From nobody Tue May 8 20:32:04 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 9E79212711A; Tue, 8 May 2018 20:32:03 -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 LuAurtA_5Lef; Tue, 8 May 2018 20:32:01 -0700 (PDT) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::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 D96ED12DB71; Tue, 8 May 2018 20:32:00 -0700 (PDT) Received: by mail-yb0-x22b.google.com with SMTP id l9-v6so11892297ybm.8; Tue, 08 May 2018 20:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hKSL258Qsy0DEvwEe44w63nanpwoasck1RXLBErLpq4=; b=pe4V1WuXPnrwox4lmLX5uRgfEXUcXIeVrELtCIq/IOXwMAfIWUrjONBBxQOqt8mPec KyPxVT2fjXm1nh5osVQHo/QjjQMpRpZiFvCU/JxnMXd8kUMbaXaexEFVUC8OkO6Kf8lw eAd0jSLsqUa978kjEe2IZHmtc/ITbewwHPe2T2XoOrpl2kCdqrRsYP7UcDelmKImo9TR CFrXe5gcQwrFfepPFG8NkHzBHw4+WyP3xlxafHL3WBdNVA+/TK/cjRAvLkvhyaPJSY8d riPMXKI6drUz3QRING0Vtrd/XMaH++SUDqTtEaPEJLydzyvLfuLhFquUNAdkexNCozQB 0BaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hKSL258Qsy0DEvwEe44w63nanpwoasck1RXLBErLpq4=; b=piiC/KiAlGBVviPx4T+khHpD4Rwv93mwswG06Gfd8KSgv5LyR7DGr55onLjawCfTJy XFXeNDl+ZFnhUqNIdcSGqIQeDvmEnJ88bUP/eyQ9h2Ter4C/018DDyNR6q866YIyAGgd wP7eeZw6VQzNf0js7FhRo6bkELVDC7VJmAwS7gVX5dxcnl6iyIdizP9K2Li08DzDG3FO vxzJfDZMwEGriJK6jlqGysZOZOY5OvgBAtZCb6fg5Tvddjr1WSj7znydnG4tI8OcRIr2 X0aSMEEc+7WJqy0yFLnmOoXgQsk5n6wXhUCQC1WyZ2KCtc0GtAkLGHRiVQBbn0MVKX4C igXQ== X-Gm-Message-State: ALKqPwcuL69pm13L84yJdvj6CtYoFz1iRvv00vrNf8vqCiYu6uyidSOw LKE9DXN4NgfOv8FuE9o8BWl0XtJCADCYgQvoM6eN2A== X-Google-Smtp-Source: AB8JxZq3NXUdaxP45aZQbYe+56FDtS1eQjtNNWzAgZK/LwSPl7Aq6wc+/NDiKbWdWrGKpMXG5tpPnTgho42LoFCsoA0= X-Received: by 2002:a5b:acf:: with SMTP id a15-v6mr5684099ybr.44.1525836719468; Tue, 08 May 2018 20:31:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:d014:0:0:0:0:0 with HTTP; Tue, 8 May 2018 20:31:58 -0700 (PDT) In-Reply-To: <152421676370.10784.8969648253452773656.idtracker@ietfa.amsl.com> References: <152421676370.10784.8969648253452773656.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Tue, 8 May 2018 22:31:58 -0500 Message-ID: To: draft-ietf-tram-stun-pmtud@ietf.org Cc: tram-chairs@ietf.org, tram@ietf.org, Tolga Asveren Content-Type: multipart/alternative; boundary="000000000000a63689056bbd8b39" Archived-At: Subject: Re: [tram] Publication has been requested for draft-ietf-tram-stun-pmtud-07 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 09 May 2018 03:32:03 -0000 --000000000000a63689056bbd8b39 Content-Type: text/plain; charset="UTF-8" Dear Authors, On Fri, Apr 20, 2018 at 4:32 AM, Gonzalo Camarillo < gonzalo.camarillo@ericsson.com> wrote: > Gonzalo Camarillo has requested publication of > draft-ietf-tram-stun-pmtud-07 as Proposed Standard on behalf of the TRAM > working group. > > Please verify the document's state at https://datatracker.ietf.org/ > doc/draft-ietf-tram-stun-pmtud/ This document was fairly clear to me. I did have some questions I'd like to work through before requesting Last Call, but none of them are showstoppers - they shouldn't even slow the show down much. Thanks, Spencer I've been wrong before, but I'm thinking that Not all UDP-based protocols implement the Path MTU discovery mechanism described in [RFC4821]. is an understatement - I'm thinking of several widely used UDP-based protocols that try to use heuristics including just pick a low MTU size, or switch to TCP transport, or some other workaround. This statement seems to say that most UDP-based protocols do RFC 4821. Is it fair to say that many UDP-based protocols don't do RFC 4821 PMTU discovery? For this section, 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. When these words are not in ALL CAPS (such as "must" or "Must"), they have their usual English meanings, and are not to be interpreted as RFC 2119 key words. you might consider replacing it with the corresponding paragraph in https://tools.ietf.org/html/rfc8174 - I'm seeing an increasing number of comments on IESG ballots suggesting this, and it's likely that the new BCP text will more familiar to most readers over time. This may be a dumb question, but in this text, Implementations supporting this specification MUST implement the server side of both the Simple Probing mechanism (Section 4.1) and the Complete Probing mechanism (Section 4.2). Implementations supporting this specification MUST implement the client side of the Complete Probing mechanism. They MAY implement the client side of the Simple Probing mechanism. does this mean "Server implementations" and "Client implementations"? I'm a bit confused about this text: Some application layer protocols may already have a way of identifying each individual UDP packet, in which case these identifiers SHOULD be used in the IDENTIFIERS attribute of the Report Response. While there are other possible packet identification schemes, this document describes two different ways to identify a specific packet. In the first packet identification mechanism, the server computes a checksum over each packet received and sends back to the sender the list of checksums ordered chronologically. The client compares this list to its own list of checksums. In the second packet identification mechanism, the client prepends the UDP data with a header that provides a sequence number. The server sends back the chronologically ordered list of sequence numbers received that the client then compares with its own list. It wasn't clear to me from this text whether these two packet identification mechanism are descriptions of what applications do if they DON'T already have a way of identifying packets. If that's what's intended, perhaps Some application layer protocols may already have a way of identifying each individual UDP packet, in which case these identifiers SHOULD be used in the IDENTIFIERS attribute of the Report Response. While there are other possible packet identification schemes, this document describes two different ways to identify a specific packet, when no application layer protocol-specific identification ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ mechanism is available. ^^^^^^^^^^^^^^^^^^^^^^ ? When I read this text, Then the client waits half the RTO, if it is known, or 250 ms after sending the last Probe Indication and then sends the Report Request to the server over UDP. I was confused - isn't there's a 500-ms default RTO value in 4.1.1? Is this different from Then the client waits half the RTO after sending the last Probe Indication and then sends the Report Request to the server over UDP. or am I missing your point? In this text, The algorithm used to calculate the checksum is similar to the algorithm used for the FINGERPRINT attribute (i.e., the CRC-32 of the payload XOR'ed with the 32-bit value 0x5354554e). is there a reference you could provide for the "algorithm used for the FINGERPRINT attribute" here? I'm pretty sure I could find the right one, but googling for "STUN FINGERPRINT checksum" is a lot less helpful than I expected, and making sure that you understand what something is "similar to" seems important if that's going to be helpful information for implementers. If using authentication in UDP-based protocols that want to use any of these mechanisms, including the PMTUD-SUPPORTED attribute, to signal PMTUD capabilities MUST ensure that it cannot be used to launch an amplification attack. For example, using authentication can ensure this. is only one way to ensure prevention of amplification attacks, is there any guidance or reference you could point to that would help implementers evaluate other approaches? Actually, after reading The Probe Request or Indication that are used to implicitly signal probing support in the reverse direction MUST be authenticated to prevent amplification attacks. I wonder why authentication isn't a MUST for UDP-based protocols using STUN-PMTUD, but that's just me wondering ... I was a bit confused by This specification defines two new STUN methods and two new STUN attributes. IANA added these new protocol elements to the "STUN Parameters Registry" created by [RFC5389]. because they haven't been added to the registry yet, right? --000000000000a63689056bbd8b39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Authors,

On Fri, Apr= 20, 2018 at 4:32 AM, Gonzalo Camarillo <gonzalo.camarillo@er= icsson.com> wrote:
Gonzalo Camarillo has= requested publication of draft-ietf-tram-stun-pmtud-07 as Proposed Standar= d on behalf of the TRAM working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/

This document was fairly clear= to me. I did have some questions I'd like to work through before reque= sting Last Call, but none of them are showstoppers - they shouldn't eve= n slow the show down much.

Thanks,

Spencer

I've been wrong before, but I'm thinking that=C2=A0

=C2=A0 Not all UDP-based protocols implement the= Path MTU discovery
= =C2=A0 =C2=A0mechanism described in [RFC4821].=C2=A0

is an understatement - I'm thinking of several widely use= d UDP-based protocols that try to use heuristics including just pick a low = MTU size, or switch to TCP transport, or some other workaround. This statem= ent seems to say that most UDP-based protocols do RFC 4821. Is it fair to s= ay that many UDP-based protocols don't do RFC 4821 PMTU discovery?

For this section,

3.=C2=A0 Terminology

=C2=A0 = =C2=A0The key words "MUST", "MUST NOT", "REQUIRED&= quot;, "SHALL", "SHALL NOT",
=C2=A0 =C2=A0"SHOULD", "SHOULD NO= T", "RECOMMENDED", "MAY", and "OPTIONAL"= in this
=C2=A0 =C2=A0= document are to be interpreted as described in [RFC2119].=C2=A0 When these<= /font>
=C2=A0 =C2=A0words are= not in ALL CAPS (such as "must" or "Must"), they have = their
=C2=A0 =C2=A0usu= al English meanings, and are not to be interpreted as RFC 2119 key
=C2=A0 =C2=A0words.

you might consider replacing it with the correspo= nding paragraph in https://= tools.ietf.org/html/rfc8174 - I'm seeing an increasing number of co= mments on IESG ballots suggesting this, and it's likely that the new BC= P text will more familiar to most readers over time.

This may be a dumb question, but in this text,=C2=A0

=C2=A0 =C2=A0Implementations supporting this sp= ecification MUST implement the
=C2=A0 =C2=A0server side of both the Simple Probing mechanism (Sec= tion 4.1) and
=C2=A0 = =C2=A0the Complete Probing mechanism (Section 4.2).

=C2=A0 =C2=A0Implementations supporting this specification MUS= T implement the
=C2=A0= =C2=A0client side of the Complete Probing mechanism.=C2=A0 They MAY implem= ent
=C2=A0 =C2=A0the c= lient side of the Simple Probing mechanism.

does this mean "Server implementations" and "Client imp= lementations"?=C2=A0

I'm a bit= confused about this text:

=C2=A0 =C2= =A0Some application layer protocols may already have a way of
<= div>=C2=A0 =C2=A0identifying each indiv= idual UDP packet, in which case these
=C2=A0 =C2=A0identifiers SHOULD be used in the IDENTIFIERS = attribute of the Report
=C2=A0 =C2=A0= schemes, this document describes two different ways to identify a
=C2=A0 =C2=A0specific packet.

<= font face=3D"monospace, monospace">=C2=A0 =C2=A0In the first packet identif= ication mechanism, the server computes a
=C2=A0 =C2=A0checksum over each packet received and send= s back to the sender the
=C2=A0 =C2=A0list of checksums ordered chronologically.=C2=A0 The client= compares this
=C2=A0 = =C2=A0list to its own list of checksums.

=C2=A0 =C2=A0th= e UDP data with a header that provides a sequence number.=C2=A0 The<= /div>
=C2=A0 =C2=A0server sends bac= k the chronologically ordered list of sequence
=C2=A0 =C2=A0numbers received that the client the= n compares with its own list.

It wasn&#= 39;t clear to me from this text whether these two packet identification mec= hanism are descriptions of what applications do if they DON'T already h= ave a way of identifying packets. If that's what's intended, perhap= s

=C2=A0 Some application layer protoco= ls may already have a way of
=C2=A0 =C2=A0identifying each individual UDP packet, in which case t= hese
=C2=A0 =C2=A0iden= tifiers SHOULD be used in the IDENTIFIERS attribute of the Report
=C2=A0 =C2=A0Response.=C2=A0 Wh= ile there are other possible packet identification
=C2=A0 =C2=A0schemes, this document describes = two different ways to identify a
=C2=A0 =C2=A0specific packet, when no application layer protocol= -specific identification
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^^^^^^^= ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
=C2=A0 =C2=A0mechanism is available.=C2=A0
=C2=A0 =C2=A0^^^^^^^^^^^= ^^^^^^^^^^^
?

When I read this text,

=C2=A0 Then the client waits half the RTO, if it is known, or 2= 50 ms after
=C2=A0 =C2= =A0sending the last Probe Indication and then sends the Report Request
=C2=A0 =C2=A0to the server= over UDP.

=
I was confused - isn't t= here's a 500-ms default RTO value in 4.1.1? Is this different from=C2= =A0

<= div>=C2=A0 Then the client waits half t= he RTO after
=C2=A0 = =C2=A0sending the last Probe Indication and then sends the Report Request
=C2=A0 =C2=A0to the ser= ver over UDP.

or am I missing your poin= t?

In this text,=C2=A0

=C2=A0 The algorithm used to calculate the checksum is = similar to the
=C2=A0 = =C2=A0algorithm used for the FINGERPRINT attribute (i.e., the CRC-32 of the=
=C2=A0 =C2=A0payload = XOR'ed with the 32-bit value 0x5354554e).

is there a reference you could provide for the "algorithm use= d for the FINGERPRINT attribute" here? I'm pretty sure I could fin= d the right one, but googling for "STUN FINGERPRINT checksum" is = a lot less helpful than I expected, and making sure that you understand wha= t something is "similar to" seems important if that's going t= o be helpful information for implementers.

If using authentication in=C2=A0

= =C2=A0 UDP-based protocols that want to use any of these mechanisms,=
=C2=A0 =C2=A0including the P= MTUD-SUPPORTED attribute, to signal PMTUD capabilities
=C2=A0 =C2=A0MUST ensure that it cannot be= used to launch an amplification attack.
=C2=A0 =C2=A0For example, using authentication can ensur= e this.

is only one way to ensure preve= ntion of amplification attacks, is there any guidance or reference you coul= d point to that would help implementers evaluate other approaches?=C2=A0

Actually, after reading=C2=A0

=C2=A0 The Probe Request or Indication that are u= sed to implicitly signal
=C2=A0 =C2=A0probing support in the reverse direction MUST be authentica= ted to
=C2=A0 =C2=A0pr= event amplification attacks.

I wonder w= hy authentication isn't a MUST for UDP-based protocols using STUN-PMTUD= , but that's just me wondering ...

= I was a bit confused by=C2=A0

=C2=A0 Th= is specification defines two new STUN methods and two new STUN
=
=C2=A0 =C2=A0attributes.=C2=A0 IAN= A added these new protocol elements to the "STUN
=C2=A0 =C2=A0Parameters Registry" crea= ted by [RFC5389].

=
because they haven= 9;t been added to the registry yet, right?
--000000000000a63689056bbd8b39-- From nobody Mon May 14 04:05:53 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 2ED2B12DA13 for ; Mon, 14 May 2018 04:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 yjK42mSVDWii for ; Mon, 14 May 2018 04:05:49 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 B9E9812DA14 for ; Mon, 14 May 2018 04:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1526295946; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=53WfdODGraLZ8+q7zU+iqj3ewI+wTTPRbSZG27+Dl0Y=; b=NLubmd/C/wpiPnBjKTE0IOqNZUktw4CaABWmMuNIl7iedw03h5Y3ghi3zuq8kiCZ eUOf5/VOLiE8HEcfS5ptyFrphofucAfU8fOHc/8BWKDiYeqEGqG3FwA+taS1U307 PsZ87RBItq4LUbOlSLtLSmgMqOaAVHdNyXG2Umd1rIM=; X-AuditID: c1b4fb2d-a6b079c00000050d-8a-5af96d8a0d78 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A7.E4.01293.A8D69FA5; Mon, 14 May 2018 13:05:46 +0200 (CEST) Received: from [147.214.19.74] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.382.0; Mon, 14 May 2018 13:04:43 +0200 To: Spencer Dawkins at IETF , CC: , , Tolga Asveren References: <152421676370.10784.8969648253452773656.idtracker@ietfa.amsl.com> From: Gonzalo Camarillo Message-ID: Date: Mon, 14 May 2018 13:04:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM2K7mW5X7s8ogwkrJC0Oz1OwWDZlD7PF +uXf2C2W/1zJZvFh7QU2B1aPnbPusnssWfKTyWPPnEmMAcxRXDYpqTmZZalF+nYJXBnr5y1k Lmgyq5jW9Z2xgXGFdhcjJ4eEgInEuZ4Opi5GLg4hgSOMEh9XvWSEcFYzSvxccRrI4eAQFgiT +HmwFqRBRCBFYsqqW0wgNrOAn8Ty/UehmqcwSpw/1cIOkmATsJDYcus+C4jNK2AvsfrdZ0YQ m0VAVeLJzx5WEFtUIEbix9EuqBpBiZMzn4DZnAKBEn/27GAD2cssoCmxfpc+xC5xiVtP5kPt lZdo3jqbGcQWEtCWWP6shWUCo+AsJJNmIXTPQtI9C0n3AkaWVYyixanFxbnpRsZ6qUWZycXF +Xl6eaklmxiBoX5wy2/dHYyrXzseYhTgYFTi4T0f/jNKiDWxrLgy9xCjBAezkgjvbiOgEG9K YmVValF+fFFpTmrxIUZpDhYlcV69VXuihATSE0tSs1NTC1KLYLJMHJxSDYy953qLF69ZxNWf +v/DzvOmrx99jrWKUKrY+PDx453RYnfWn+K+tFurP7bjhrfb2iPRh86/u+06IWeCmwiHb1Zj aZ+I2fGmX+qN0tX8Omefe3Iz/Hm9VJBl+hzN8qK1v3Mnrp25aJLF6YPaqssNyjLZrHsTt+me FOoMWr1qlmlRdzv3lXNxVpuUWIozEg21mIuKEwHY/zc+cQIAAA== Archived-At: Subject: Re: [tram] Publication has been requested for draft-ietf-tram-stun-pmtud-07 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 14 May 2018 11:05:51 -0000 Authors, could you please look at Spencer's AD review below and address his comments? Thanks! Cheers, Gonzalo On 09/05/2018 5:31 AM, Spencer Dawkins at IETF wrote: > Dear Authors, > > On Fri, Apr 20, 2018 at 4:32 AM, Gonzalo Camarillo > > > wrote: > > Gonzalo Camarillo has requested publication of > draft-ietf-tram-stun-pmtud-07 as Proposed Standard on behalf of the > TRAM working group. > > Please verify the document's state at > https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/ > > > > This document was fairly clear to me. I did have some questions I'd like > to work through before requesting Last Call, but none of them are > showstoppers - they shouldn't even slow the show down much. > > Thanks, > > Spencer > > I've been wrong before, but I'm thinking that  > >   Not all UDP-based protocols implement the Path MTU discovery >    mechanism described in [RFC4821].  > > is an understatement - I'm thinking of several widely used UDP-based > protocols that try to use heuristics including just pick a low MTU size, > or switch to TCP transport, or some other workaround. This statement > seems to say that most UDP-based protocols do RFC 4821. Is it fair to > say that many UDP-based protocols don't do RFC 4821 PMTU discovery? > > For this section, > > 3.  Terminology > >    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >    document are to be interpreted as described in [RFC2119].  When these >    words are not in ALL CAPS (such as "must" or "Must"), they have their >    usual English meanings, and are not to be interpreted as RFC 2119 key >    words. > > you might consider replacing it with the corresponding paragraph in > https://tools.ietf.org/html/rfc8174 - I'm seeing an increasing number of > comments on IESG ballots suggesting this, and it's likely that the new > BCP text will more familiar to most readers over time. > > This may be a dumb question, but in this text,  > >    Implementations supporting this specification MUST implement the >    server side of both the Simple Probing mechanism (Section 4.1) and >    the Complete Probing mechanism (Section 4.2). > >    Implementations supporting this specification MUST implement the >    client side of the Complete Probing mechanism.  They MAY implement >    the client side of the Simple Probing mechanism. > > does this mean "Server implementations" and "Client implementations"?  > > I'm a bit confused about this text: > >    Some application layer protocols may already have a way of >    identifying each individual UDP packet, in which case these >    identifiers SHOULD be used in the IDENTIFIERS attribute of the Report >    Response.  While there are other possible packet identification >    schemes, this document describes two different ways to identify a >    specific packet. > >    In the first packet identification mechanism, the server computes a >    checksum over each packet received and sends back to the sender the >    list of checksums ordered chronologically.  The client compares this >    list to its own list of checksums. > >    In the second packet identification mechanism, the client prepends >    the UDP data with a header that provides a sequence number.  The >    server sends back the chronologically ordered list of sequence >    numbers received that the client then compares with its own list. > > It wasn't clear to me from this text whether these two packet > identification mechanism are descriptions of what applications do if > they DON'T already have a way of identifying packets. If that's what's > intended, perhaps > >   Some application layer protocols may already have a way of >    identifying each individual UDP packet, in which case these >    identifiers SHOULD be used in the IDENTIFIERS attribute of the Report >    Response.  While there are other possible packet identification >    schemes, this document describes two different ways to identify a >    specific packet, when no application layer protocol-specific > identification >                   > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >    mechanism is available.  >    ^^^^^^^^^^^^^^^^^^^^^^ > ? > > When I read this text, > >   Then the client waits half the RTO, if it is known, or 250 ms after >    sending the last Probe Indication and then sends the Report Request >    to the server over UDP. > > I was confused - isn't there's a 500-ms default RTO value in 4.1.1? Is > this different from  > >   Then the client waits half the RTO after >    sending the last Probe Indication and then sends the Report Request >    to the server over UDP. > > or am I missing your point? > > In this text,  > >   The algorithm used to calculate the checksum is similar to the >    algorithm used for the FINGERPRINT attribute (i.e., the CRC-32 of the >    payload XOR'ed with the 32-bit value 0x5354554e). > > is there a reference you could provide for the "algorithm used for the > FINGERPRINT attribute" here? I'm pretty sure I could find the right one, > but googling for "STUN FINGERPRINT checksum" is a lot less helpful than > I expected, and making sure that you understand what something is > "similar to" seems important if that's going to be helpful information > for implementers. > > If using authentication in  > >   UDP-based protocols that want to use any of these mechanisms, >    including the PMTUD-SUPPORTED attribute, to signal PMTUD capabilities >    MUST ensure that it cannot be used to launch an amplification attack. >    For example, using authentication can ensure this. > > is only one way to ensure prevention of amplification attacks, is there > any guidance or reference you could point to that would help > implementers evaluate other approaches?  > > Actually, after reading  > >   The Probe Request or Indication that are used to implicitly signal >    probing support in the reverse direction MUST be authenticated to >    prevent amplification attacks. > > I wonder why authentication isn't a MUST for UDP-based protocols using > STUN-PMTUD, but that's just me wondering ... > > I was a bit confused by  > >   This specification defines two new STUN methods and two new STUN >    attributes.  IANA added these new protocol elements to the "STUN >    Parameters Registry" created by [RFC5389]. > > because they haven't been added to the registry yet, right? From nobody Mon May 14 09:56: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 94DC912E895 for ; Mon, 14 May 2018 09:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 WXkh3Qf-c6me for ; Mon, 14 May 2018 09:56:15 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 C29CA12E898 for ; Mon, 14 May 2018 09:56:14 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4EGlEBO015495; Mon, 14 May 2018 17:56:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=9uQrqD2wgUFc125fBI6TLVifSOWxhD/NEpXl1FCONkY=; b=dNVMXpNpoWuRrPuSfUSMSjZNYAiPn+PC0yDe3MIu350EJCE9PdUton8oSfo2JhZNG7fF REn0+4LQQU7s2FliVXB2rCKkSA0NQkFJje7WAH+F69Ku9Q1/UKAshvOPE4209LoWwwrW TYt4pIWTrheXVMFl4PTPVm9DJ9Ne5azBI4D9hbWPuAKyL4eG7+cSS2aJiJ3FhX5cejP/ 4OVXiYP5DnZLbO3glcD5UhVCh3d4OgMGzi/n4yNokTj5Dq9UEwtsdh+d0soObOGTFvKI +4XHjke9xt0Uuk0u7k7s1yiMVrw6NyWDqwl9tFPuGVhU6WJvndVxzP/SU3zGFI1gtN74 4A== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2hwraewj3g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 May 2018 17:56:14 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w4EGjqAT023127; Mon, 14 May 2018 12:56:12 -0400 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2hwukus87b-1; Mon, 14 May 2018 12:56:12 -0400 Received: from [172.28.116.218] (bowill.kendall.corp.akamai.com [172.28.116.218]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id BB3DE1FC11; Mon, 14 May 2018 16:56:11 +0000 (GMT) To: "Konda, Tirumaleswar Reddy" , "tram@ietf.org" References: <152449325211.21886.16366690442756908271@ietfa.amsl.com> From: Brandon Williams Message-ID: <347de982-54c5-4156-e406-0aa13ed4446c@akamai.com> Date: Mon, 14 May 2018 12:56:10 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-14_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805140171 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-14_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805140171 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-17.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 14 May 2018 16:56:18 -0000 Hi Tiru, I've got a few editorial suggestions on the new content re: permissionless STUN relay. As these are all editorial, you can of course feel free to ignore any/all of them. They are simply highlighting some places where I had some trouble parsing the text and do not represent substantive changes to the proposed content. Please let me know if you have any questions about the following. --Brandon Section 2.3. Permissions * "... the UDP datagram is silently discarded. However, a TURN server can be configured to permit ..." The use of "However" here implies a more significant departure from the preceding sentence than you intend. I suggest dropping it. "... the UDP datagram is silently discarded. A TURN server can be configured to permit ..." * "... speeds up STUN connectivity checks, while the client creates permissions in the TURN server for the remote peer IP addresses, the remote peer can initiate connectivity checks to the client." The use of "while" after the comma makes it seem like a different use of the word than you intend. I suggest "... speeds up STUN connectivity checks, allowing the remote peer to initiate connectivity checks to the client while the client is creating permissions in the TURN server for the remote peer IP addresses." Section 9. Permissions * "... do not match the permissions installed, this configuration knob MUST ..." The "," makes this sentence seem like a run-on. I suggest "... do not match the permissions installed. This configuration knob MUST ..." * "... unless explicitly configured to do so otherwise." The "so" is confusing here. I suggest "... unless explicitly configured to do otherwise." * "If no match is found and the received datagram is not a STUN packet, relaying is not permitted, and the server silently discards the UDP datagram. If an exact match is found or the received datagram is a STUN packet, then the permission check is considered to have succeeded and the server continues to process the UDP datagram as specified elsewhere (Section 11.3)." Although the correct interpretation of this text is suggested by the preceding paragraph, as written it appears to imply that the non-default behavior is the normal expected behavior. I think it would be good to clarify. I suggest the following text. "If no match is found and the received datagram is not a STUN packet, the permission check is considered to have failed. If an exact match is found, the permission check is considered to have succeeded. If no match is found and the received datagram is a STUN packet, the permission check is considered to have failed unless the server is configured to allow STUN packets without explicit permission, in which case the permission check is considered to have succeeded. If the permission check fails, relaying is not permitted and the server silently discards the UDP datagram. If the permission check succeeds, the services continues to process the UDP datagram as specified elsewhere (Section 11.3)." If that text seems unwieldy, the section might be easier to parse if converted to a bullet list. Section 19.2. Firewall Considerations I find the new paragraph to be a little bit difficult to read. I suggest reorganizing the text. ====== When a TURN server is configured to permit inbound STUN packets on the allocation's relayed address even if the source IP addresses of the STUN packet's does not match the permissions installed, the TURN server MUST have a security policy for inbound STUN packets from IP addresses not matching the permissions installed in order to prevent an attacker from flooding the TURN client with STUN-like packets. The TURN server can limit forwarding to well-formed STUN connectivity check packets by looking for the STUN atrributes USERNAME and MESSAGE-INTEGRITY and verifying that the message does not exceed a specific configurable packet size. Additionally, the TURN server policy can be configured with maximum rate-limits for the number of STUN packets allowed in a TURN session, STUN packets allowed per second, and IP addresses allowed to send STUN packets. ===== On 04/23/2018 10:29 AM, Konda, Tirumaleswar Reddy wrote: > Updated draft allows the TURN server to forward inbound STUN connectivity checks without permissions and also addresses the comments from Noriyuki Torii. > > -Tiru > >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: Monday, April 23, 2018 7:51 PM >> To: i-d-announce@ietf.org >> Cc: tram@ietf.org >> Subject: [tram] I-D Action: draft-ietf-tram-turnbis-17.txt >> >> >> >> >> 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-17.txt >> Pages : 84 >> Date : 2018-04-23 >> >> 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-17 >> https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-17 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-17 >> >> >> 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/ >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From nobody Mon May 14 13:06:21 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 D128012D963; Mon, 14 May 2018 13:06:14 -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 oO0w9mJzrbor; Mon, 14 May 2018 13:06:12 -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 7F1C512D960; Mon, 14 May 2018 13:06:12 -0700 (PDT) Received: from [IPv6:2601:648:8300:e8a:d578:c438:f732:cb38] (unknown [IPv6:2601:648:8300:e8a:d578:c438:f732:cb38]) (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 43311AE8D8; Mon, 14 May 2018 22:06:07 +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> <31a441d2-8843-c8ee-f5ef-5496e5b4b364@acm.org> From: Marc Petit-Huguenin Message-ID: <29c18858-3694-c48a-54c3-6dcbfa3b6705@acm.org> Date: Mon, 14 May 2018 13:06:00 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6EYGT8NOVfAyQNgSolyXr5tQtvhQ02FZ1" 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.22 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, 14 May 2018 20:06:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6EYGT8NOVfAyQNgSolyXr5tQtvhQ02FZ1 Content-Type: multipart/mixed; boundary="3NoRU4CJ1v9XBRnBJro8epv8BjgRqAl6C"; 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: <29c18858-3694-c48a-54c3-6dcbfa3b6705@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> <31a441d2-8843-c8ee-f5ef-5496e5b4b364@acm.org> In-Reply-To: --3NoRU4CJ1v9XBRnBJro8epv8BjgRqAl6C Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable During the discussion about choosing password algorithms, someone came to= the microphone (AFAIR) and said that it was subject to bid-down attack. = We then design a solution to prevent that and that's what, after more di= scussions, we put in the draft. So I welcome any comment on the strength= or weakness of the protection offered by the scheme we put in place and = any suggestion to make it better, but as for the reasons it is there you = will have to talk to the Working Group. Thanks. On 05/03/2018 04:45 PM, Eric Rescorla wrote: > No, I don't understand this at all. This section talks about a bid-down= on > the PASSWORD-ALGORITHM, but I don't see how a weakness in MD5 is releva= nt > here. >=20 > Assuming I understand correctly, the structure of the protocol is that > given a password, you do: >=20 > key =3D Password-Algorithm(username, realm, password) >=20 > And then use key with HMAC for an integrity check, where HMAC is SHA-1 > (with MESSAGE-INTEGRITY) or SHA-256 (with MESSAGE-INTEGRITY-SHA256). > However, in this case the MD5 isn't a security critical component at th= e > protocol layer [0], because it's just is just to act as a transformatio= n of > the password into a fixed-length string for use as a key, so this doesn= 't > require collision resistance or pseudorandomness. I could be wrong here= , > but if so, please describe a potential weakness in MD5 which could lead= to > compromise of this protocol >=20 > -Ekr >=20 > [0] It might be an issue if someone were to recover the hashed password= =2E >=20 > On Thu, May 3, 2018 at 4:34 PM, Marc Petit-Huguenin > wrote: >=20 >> On 04/22/2018 02:02 PM, Marc Petit-Huguenin wrote: >>> Hi Eric, >>> >>> Thanks for the review, please see my responses inline. >>> >>> On 04/16/2018 12:57 PM, Eric Rescorla wrote: >>>> Eric Rescorla has entered the following ballot position for >>>> draft-ietf-tram-stunbis-16: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to al= l >>>> email addresses included in the To and CC lines. (Feel free to cut t= his >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria= =2E >> html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ >>>> >>>> >>>> >>>> --------------------------------------------------------------------= -- >>>> DISCUSS: >>>> --------------------------------------------------------------------= -- >>>> >>>> Rich version of this review at: >>>> https://mozphab-ietf.devsvcdev.mozaws.net/D5132 >>>> >>>> >>>> Can you please indicate how you addressed the points Matt Miller >>>> raised in his secdir review about the use of MD5. >>> >>> From my response on 2018-03-11: >>> >>>> * The description for 17.5.1. "MD5" list the key size as 20 bytes, b= ut >> the >>>> hash length of MD5 is 16 bytes (128 bits). I think this is merely a= >> typo, >>>> since the purpose appears to be for backwards compatibility with >> existing >>>> systems. >>> >>> Fixed. >>> >>>> >>>> * Both 17.5.1.1. "MD5" Section 9.2.2. "HMAC Key" (long-term credenti= al) >>>> and Section appear to define the same functional algorithm, but with= >> subtle >>>> syntax differences. As far as I can tell, they are actually the sam= e >>>> algorithm; would it not be acceptable to have Section 9.2.2 point to= >>>> Section 17.5.1.1 for the algorithm description? >>>> >>>> >>> >>> This is going into the IANA registry so I left things there. I fixed= >> the discrepancy with section 9.2.2. >>> >>> I also fixed the definition of the key for SHA-256, which must use >> OpaqueString for the realm. >>> >>>> >>>> >>>> >>>> DETAIL >>>>> by the agent sending the indication. It primarily serves to >>>>> correlate requests with responses, though it also plays a smal= l >> role >>>>> in helping to prevent certain types of attacks. The server al= so >> uses >>>>> the transaction ID as a key to identify each transaction uniqu= ely >>>>> across all clients. As such, the transaction ID MUST be unifo= rmly >>>>> and randomly chosen from the interval 0 .. 2**96-1, and SHOULD= be >>>> >>>> I didn't realize this was a SHOULD. ICE depends on it as a security >>>> condition, so it probably needs to be a MUST. >>> >>> Done. >>> >>>> >>>> >>>>> For a request or indication message, the agent MUST include th= e >>>>> USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGRITY >> attributes >>>>> in the message unless the agent knows from an external indicat= ion >>>>> 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. >>> >>>> >>>> >>>>> STUN Security Feature it is understood that the corresponding = STUN >>>>> Security Feature bit in the "nonce cookie" is set to 1. >>>>> >>>>> For example, in Section 9.2.4 discussing the PASSWORD-ALGORITH= MS >>>>> security feature, it is implied that the "Password algorithms"= >> bit, >>>>> as defined in Section 17.1, is set to 1 in the "nonce cookie".= >>>> >>>> I'm not sure I understand the bid down attack here or the proposed >>>> defense. Can you please walk through what the assumed attacker >>>> capabilities are, what the client and server capabilities are, how t= he >>>> bid down attack works, and how this protects against it? >>> >>> The plan is to add an annex to the document explaining that. I'll >> finish to process the other reviews from the IESG and then come back t= o >> that. >>> >> >> Instead of an annex, we added a new section in the Security >> Considerations. Please have a look at -17 and let us know if that >> explanation is good enough. >> >> Thanks. >> >=20 --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --3NoRU4CJ1v9XBRnBJro8epv8BjgRqAl6C-- --6EYGT8NOVfAyQNgSolyXr5tQtvhQ02FZ1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlr57CgACgkQKcRFldZq fsQpHBAAzbyI2onzh7aGyBus0H7CGqOmO54418Qv60YnaKJl1cexEn9uEZUqFzDO 0J5elN/toi73pk9NwsEylzT1YhiiokhsHcVcXJs+hiFEzKU0PXSi61iCVFyE+1vL UCWoKrOaZmq2rkK+kR/KqBrEMCQmJ+xU1d4AUhuob4n12aZqG91u+rqdNjezeOjw 1HEbHSHK0Bhr1JwYkOwfAMeW94FKRZs3yf7TThOvHeMreJHl659dSouavZI2luxW GQN7ihchru5cH+T6H80AzohQZHySit0A3BAXHmb6m06IFIRExa2dlgU7frJi2ihA tGWnVPQ0IjMTtppIiCxZfIUwEtYsIQI/77csf0fsTdgOgRyzRu0KYuexz4A5UTx6 vAuKHBnBH4zslSiuaMFeNszoFPrdwlqVDuCbvrOpLOpG7tr3YkX8e69zJM6aAaZM vmKnTpNRoktcPZmtXmdGkicjymkiMyJf5GvMrtzXNDkMosHfCZslQcRFTcMMOoeU 6fcndkH5+EKgt8ASyRng7L1XNewgPbglCFS6hAMc9Yj/LmkdMABX6Pd+CMhi3R2C eSxdlKBn5qUC6Qrs5siygfwIphD0V83RkA4kfQw55qnQhKOekXHbQcZv3ioBL2aT ObeNinspi4cexrsHR+dMYV1BdZ3ky0PQncI1JiHJ/JRVY0QJK44= =w56P -----END PGP SIGNATURE----- --6EYGT8NOVfAyQNgSolyXr5tQtvhQ02FZ1-- From nobody Mon May 14 13:23:35 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 342C7124319; Mon, 14 May 2018 13:23:29 -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 ASZhzWJ3s0Tx; Mon, 14 May 2018 13:23:27 -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 835D31277BB; Mon, 14 May 2018 13:23:27 -0700 (PDT) Received: from [IPv6:2601:648:8300:e8a:d578:c438:f732:cb38] (unknown [IPv6:2601:648:8300:e8a:d578:c438:f732:cb38]) (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 57AC9AE8D8; Mon, 14 May 2018 22:23:25 +0200 (CEST) To: "Dale R. Worley" Cc: gen-art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org References: <87d0yc434c.fsf@hobgoblin.ariadne.com> From: Marc Petit-Huguenin Message-ID: <387eea8b-6f77-c94e-d67e-180ef17cd0f0@acm.org> Date: Mon, 14 May 2018 13:23:22 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <87d0yc434c.fsf@hobgoblin.ariadne.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mZpx5RTOsvVcpHlTMom89lNGd724M9hye" Archived-At: Subject: Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 14 May 2018 20:23:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mZpx5RTOsvVcpHlTMom89lNGd724M9hye Content-Type: multipart/mixed; boundary="4dFZmaKFGtrapLDf5fVxJSnJj26WOC818"; protected-headers="v1" From: Marc Petit-Huguenin To: "Dale R. Worley" Cc: gen-art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org Message-ID: <387eea8b-6f77-c94e-d67e-180ef17cd0f0@acm.org> Subject: Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16 References: <87d0yc434c.fsf@hobgoblin.ariadne.com> In-Reply-To: <87d0yc434c.fsf@hobgoblin.ariadne.com> --4dFZmaKFGtrapLDf5fVxJSnJj26WOC818 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Thank you. See inline. On 05/03/2018 06:32 PM, Dale R. Worley wrote: > Marc Petit-Huguenin writes: >> Because we believe that this is a problem that will become more and >> more frequent, we decided to fix it, at least for new implementations.= >> >> Please have a look at -17 and let us know what you think of it. >=20 > It looks like you've handled the problem of a NAT that changes the > address family of the request as well as can be done. >=20 > You've clarified the question of how the security feature bits are > assigned, although I note that -16 and -17 assign the bits differently > than versions -7 through -15 do. >=20 > That completes all of the significant issues from my review of -16. >=20 > And there are some nits: >=20 > 6.2.1. Sending over UDP or DTLS-over-UDP >=20 > SHOULD be greater or equal than 500 ms. >=20 > s/equal than/equal to/. Applied. >=20 > 6.2.3. Sending over TLS-over-TCP or DTLS-over-UDP >=20 > To do that, it follows the > identification procedures defined in [RFC6125], with a certificate > containing an identifier of type DNS-ID or CN-ID, eventually with > wildcards, but not of type SRV-ID or URI-ID. >=20 > The meaning of "eventually" here is not clear. Rephrased as: [...] containing an identifier of type DNS-ID or CN-ID, eventually with a wildcard character as leftmost label, but not of type SRV-ID or URI- [...] >=20 > 14. STUN Attributes >=20 > The > padding bits MUST be set to zero on sending and must be ignored by > the receiver. >=20 > I assume the latter "must" is supposed to be "MUST". Fixed. >=20 > 14.13. UNKNOWN-ATTRIBUTES >=20 > Note: In [RFC3489], this field was padded to 32 by duplicating the > last attribute. In this version of the specification, thPetriNet= > m --> PetriNet m --> e normal padding rules for attributes are > used instead. >=20 > I assume that "thPetriNet m --> PetriNet m --> e" is intended to be > "the". Fixed. >=20 > Appendix C. Release notes >=20 > Section C.8 has the same contents as section C.9, but section C.9 has > the same title as section C.10. (Although section C will be removed > before publication, so it's not important.) Fixed. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --4dFZmaKFGtrapLDf5fVxJSnJj26WOC818-- --mZpx5RTOsvVcpHlTMom89lNGd724M9hye Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlr58DsACgkQKcRFldZq fsSqMxAAprzXauCphrup86OVa5d13jG9iYiUIaNZETZ5itMXbg89jIH2km96kXkd IJiB9j6r+Pt76/f3hDJzCDPVUL/tWTDT9jT7ZLqcVcoPY0ieU56SLMqd2BpYx/43 SoVwMe1INAIzA+ut2b5SXrkva+0nAgbTFht8WKBaKR+0Urlb5Z5xX3eSb9zZyGyz +2j6n0fxfag6X05cwyO3j49WiQ/gab2f/YU7RrKLPDa7aN1p7cMGuUQQt27DrlFQ MzYw5HHadideeZwqyq6j5dkhcMdA65u3yo8OYKWSaGZmuD3hTRJ3jtcJIgRdTK5A GJq5xAsDZKScoZWgtSu2Sg4I0FdYKUZoL9u/J7xrRVplPtHOe9Bf//lBCkmE7DZk 0rkcG4yc1v4uGdmznAZibIJ4gpOzA/sfzQmRZ9nuv8G7NwlhrzrDdL0gV67uxc30 W2aDhnEHJcYAUy3Uo7MifBOauBcPYXNBQUpBV7Cwd8tk7tbIeU71rjPQFzp9eRe1 Q/PAHRxxAJ1ADUNGWVGouBfqco9y/PUI9A/L8zEJAl5mTZxutGl4M8DjcB72c1fD 4p8UXyNZsK/RDMS16HpkNsU1BQjh09X91i0XfE2MnfhkCpbXuM2nVDROGhCs+nHW tRQ0YL4XbNc9gvYhvYrt672JK66WPmA2xABHTl+qc7fa39yuDj4= =L8Hm -----END PGP SIGNATURE----- --mZpx5RTOsvVcpHlTMom89lNGd724M9hye-- From nobody Mon May 14 15:58:30 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 60D3812E8E6; Mon, 14 May 2018 15:58:28 -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.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152633870834.3807.7954298926527489656@ietfa.amsl.com> Date: Mon, 14 May 2018 15:58:28 -0700 Archived-At: Subject: [tram] I-D Action: draft-ietf-tram-stunbis-18.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 14 May 2018 22:58:28 -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-18.txt Pages : 72 Date : 2018-05-14 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-18 https://datatracker.ietf.org/doc/html/draft-ietf-tram-stunbis-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-18 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 Mon May 14 16:50:52 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 2CB8C12E957; Mon, 14 May 2018 16:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-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 h0dyj5wEMIu3; Mon, 14 May 2018 16:50:46 -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 926BF12E8DD; Mon, 14 May 2018 16:50:46 -0700 (PDT) Received: from [IPv6:2601:648:8300:e8a:d578:c438:f732:cb38] (unknown [IPv6:2601:648:8300:e8a:d578:c438:f732:cb38]) (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 92120AE8D8; Tue, 15 May 2018 01:50:42 +0200 (CEST) To: Spencer Dawkins at IETF , draft-ietf-tram-stun-pmtud@ietf.org Cc: tram-chairs@ietf.org, tram@ietf.org, Tolga Asveren References: <152421676370.10784.8969648253452773656.idtracker@ietfa.amsl.com> From: Marc Petit-Huguenin Message-ID: <55552202-8550-235b-b907-5f7dd65dbde2@petit-huguenin.org> Date: Mon, 14 May 2018 16:50:39 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Qvnrhs29HBsa7rTk1MNFbs9fC7shzJrmJ" Archived-At: Subject: Re: [tram] Publication has been requested for draft-ietf-tram-stun-pmtud-07 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 14 May 2018 23:50:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Qvnrhs29HBsa7rTk1MNFbs9fC7shzJrmJ Content-Type: multipart/mixed; boundary="AOec3ZN3Mq4GN48yP1Bk0yEm8drRFYeas"; protected-headers="v1" From: Marc Petit-Huguenin To: Spencer Dawkins at IETF , draft-ietf-tram-stun-pmtud@ietf.org Cc: tram-chairs@ietf.org, tram@ietf.org, Tolga Asveren Message-ID: <55552202-8550-235b-b907-5f7dd65dbde2@petit-huguenin.org> Subject: Re: Publication has been requested for draft-ietf-tram-stun-pmtud-07 References: <152421676370.10784.8969648253452773656.idtracker@ietfa.amsl.com> In-Reply-To: --AOec3ZN3Mq4GN48yP1Bk0yEm8drRFYeas Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Spencer, Thank you for the review. Please see inline. On 05/08/2018 08:31 PM, Spencer Dawkins at IETF wrote: > Dear Authors, >=20 > On Fri, Apr 20, 2018 at 4:32 AM, Gonzalo Camarillo < > gonzalo.camarillo@ericsson.com> wrote: >=20 >> Gonzalo Camarillo has requested publication of >> draft-ietf-tram-stun-pmtud-07 as Proposed Standard on behalf of the TR= AM >> working group. >> >> Please verify the document's state at https://datatracker.ietf.org/ >> doc/draft-ietf-tram-stun-pmtud/ >=20 >=20 > This document was fairly clear to me. I did have some questions I'd lik= e to > work through before requesting Last Call, but none of them are showstop= pers > - they shouldn't even slow the show down much. >=20 > Thanks, >=20 > Spencer >=20 > I've been wrong before, but I'm thinking that >=20 > Not all UDP-based protocols implement the Path MTU discovery > mechanism described in [RFC4821]. >=20 > is an understatement - I'm thinking of several widely used UDP-based > protocols that try to use heuristics including just pick a low MTU size= , or > switch to TCP transport, or some other workaround. This statement seems= to > say that most UDP-based protocols do RFC 4821. Is it fair to say that m= any > UDP-based protocols don't do RFC 4821 PMTU discovery? New text: Many UDP-based protocols do not implement the Path MTU discovery mechanism described in [RFC4821]. These protocols can make use of [...] >=20 > For this section, >=20 > 3. Terminology >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this= > document are to be interpreted as described in [RFC2119]. When thes= e > words are not in ALL CAPS (such as "must" or "Must"), they have thei= r > usual English meanings, and are not to be interpreted as RFC 2119 ke= y > words. >=20 > you might consider replacing it with the corresponding paragraph in > https://tools.ietf.org/html/rfc8174 - I'm seeing an increasing number o= f > comments on IESG ballots suggesting this, and it's likely that the new = BCP > text will more familiar to most readers over time. Done. >=20 > This may be a dumb question, but in this text, >=20 > Implementations supporting this specification MUST implement the > server side of both the Simple Probing mechanism (Section 4.1) and > the Complete Probing mechanism (Section 4.2). >=20 > Implementations supporting this specification MUST implement the > client side of the Complete Probing mechanism. They MAY implement > the client side of the Simple Probing mechanism. >=20 > does this mean "Server implementations" and "Client implementations"? No, a compliant implementation must support both the client and the serve= r side so to discover the PMTU in both directions. The only choice is to= not support the client side of the simple probing mechanism. >=20 > I'm a bit confused about this text: >=20 > Some application layer protocols may already have a way of > identifying each individual UDP packet, in which case these > identifiers SHOULD be used in the IDENTIFIERS attribute of the Repor= t > Response. While there are other possible packet identification > schemes, this document describes two different ways to identify a > specific packet. >=20 > In the first packet identification mechanism, the server computes a > checksum over each packet received and sends back to the sender the > list of checksums ordered chronologically. The client compares this= > list to its own list of checksums. >=20 > In the second packet identification mechanism, the client prepends > the UDP data with a header that provides a sequence number. The > server sends back the chronologically ordered list of sequence > numbers received that the client then compares with its own list. >=20 > It wasn't clear to me from this text whether these two packet > identification mechanism are descriptions of what applications do if th= ey > DON'T already have a way of identifying packets. If that's what's inten= ded, > perhaps >=20 > Some application layer protocols may already have a way of > identifying each individual UDP packet, in which case these > identifiers SHOULD be used in the IDENTIFIERS attribute of the Repor= t > Response. While there are other possible packet identification > schemes, this document describes two different ways to identify a > specific packet, when no application layer protocol-specific > identification >=20 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > mechanism is available. > ^^^^^^^^^^^^^^^^^^^^^^ > ? Applied. >=20 > When I read this text, >=20 > Then the client waits half the RTO, if it is known, or 250 ms after > sending the last Probe Indication and then sends the Report Request > to the server over UDP. >=20 > I was confused - isn't there's a 500-ms default RTO value in 4.1.1? Is = this > different from >=20 > Then the client waits half the RTO after > sending the last Probe Indication and then sends the Report Request > to the server over UDP. >=20 > or am I missing your point? Replaced by your text. >=20 > In this text, >=20 > The algorithm used to calculate the checksum is similar to the > algorithm used for the FINGERPRINT attribute (i.e., the CRC-32 of th= e > payload XOR'ed with the 32-bit value 0x5354554e). >=20 > is there a reference you could provide for the "algorithm used for the > FINGERPRINT attribute" here? I'm pretty sure I could find the right one= , > but googling for "STUN FINGERPRINT checksum" is a lot less helpful than= I > expected, and making sure that you understand what something is "simila= r > to" seems important if that's going to be helpful information for > implementers. Added reference to ITU V42. >=20 > If using authentication in >=20 > UDP-based protocols that want to use any of these mechanisms, > including the PMTUD-SUPPORTED attribute, to signal PMTUD capabilitie= s > MUST ensure that it cannot be used to launch an amplification attack= =2E > For example, using authentication can ensure this. >=20 > is only one way to ensure prevention of amplification attacks, is there= any > guidance or reference you could point to that would help implementers > evaluate other approaches? It's a good question. I have to think about that. >=20 > Actually, after reading >=20 > The Probe Request or Indication that are used to implicitly signal > probing support in the reverse direction MUST be authenticated to > prevent amplification attacks. >=20 > I wonder why authentication isn't a MUST for UDP-based protocols using > STUN-PMTUD, but that's just me wondering ... When STUN-PMTUD is used as an add-on to an existing protocol, it is diffi= cult to impose to make the whole protocol authenticated. When it is for = a new protocol I agree that it should be secure, but then it is up to the= protocol designer to do that (and to the IESG to enforce it). >=20 > I was a bit confused by >=20 > This specification defines two new STUN methods and two new STUN > attributes. IANA added these new protocol elements to the "STUN > Parameters Registry" created by [RFC5389]. >=20 > because they haven't been added to the registry yet, right? >=20 Right. I changed the whole IANA section to look like the one in STUNBis.= --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --AOec3ZN3Mq4GN48yP1Bk0yEm8drRFYeas-- --Qvnrhs29HBsa7rTk1MNFbs9fC7shzJrmJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlr6IM8ACgkQKcRFldZq fsQaCQ//dXEDDEbLtqTy8wiMXCURbgjNDbCaZvWRnGvaou1S9sqoVGInEsWJ+63B /DsFuP1o9bYYCClP/RnVBMf04ft56TiQrRoMKNxiVkPvaKxI1mfJ9atJFTBaYq6G PS9ZYdfIW/Mpx8UCTY8JOqQZIeE/6CCL/wnAlLgMxMGeXWSFbPzcIAlsV8tKG5kU P7ZXTFgNqAf/nsGIRxfSFQXuD8sP5jvcXAgbMrZvjCd84kH0PsPJlp1a1i63dtEh 8RYqFHS7hARrUNWWGQHNd4ktXZPqXYtYshYvUeW3osHQ2epwQKUK+Sq6gXqRpXxd E5gchqUPGPBVzF7diQl1RbB1pNH9bL+INS4SEuP8a7CZ1+hjv8pPTTWy5jZg9k7m +H2ZfkRS+SCoKPuzKpf3YBJaIdBUqy4vNV4Yrra1Qryno/DdAuZGNEPTQl+xwSWv +DrL1HYE4Hpa6hfWywa+xmGrD6JZel06Hss2ja+73cKvAqcE6DqOhoYDlPn4eZf+ aMhVxRAU7l4YHPTjIAvavf5mp3A4U9CI3ZYojtKyIdVcE73yUo5xPBHsrKOczS67 veNgRJgwGVCywBIYZxJPq4zzbKCPv34h7A+U+GRv53c2cjlQXA/WeeG5jY+G/zQp M946FMvhVLi5ArbLg+6khoInrP8kJYwBI63572MWNy6Qa528SY4= =mfOh -----END PGP SIGNATURE----- --Qvnrhs29HBsa7rTk1MNFbs9fC7shzJrmJ-- From nobody Mon May 14 16:53:51 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 9584212E8DD; Mon, 14 May 2018 16:53:49 -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.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152634202957.3779.5795086180096690980@ietfa.amsl.com> Date: Mon, 14 May 2018 16:53:49 -0700 Archived-At: Subject: [tram] I-D Action: draft-ietf-tram-stun-pmtud-08.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 14 May 2018 23:53:50 -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 : Path MTU Discovery Using Session Traversal Utilities for NAT (STUN) Authors : Marc Petit-Huguenin Gonzalo Salgueiro Filename : draft-ietf-tram-stun-pmtud-08.txt Pages : 17 Date : 2018-05-14 Abstract: This document describes a Session Traversal Utilities for NAT (STUN) Usage for Path MTU Discovery (PMTUD) between a client and a server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tram-stun-pmtud-08 https://datatracker.ietf.org/doc/html/draft-ietf-tram-stun-pmtud-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-pmtud-08 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 Mon May 14 19:18:14 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 DE90112E8C7 for ; Mon, 14 May 2018 19:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_LOW=-0.7, 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 ypCjGtjDmM7y for ; Mon, 14 May 2018 19:18:04 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 7B1E712EA74 for ; Mon, 14 May 2018 19:18:03 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-08v.sys.comcast.net with ESMTP id INvufMaGkmuQ1IPXOf0mIu; Tue, 15 May 2018 02:18:02 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-09v.sys.comcast.net with ESMTPA id IPXNfYyOYPhUCIPXNfXVMZ; Tue, 15 May 2018 02:18:02 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id w4F2I0SH021154; Mon, 14 May 2018 22:18:01 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id w4F2I0BS021151; Mon, 14 May 2018 22:18:00 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Marc Petit-Huguenin Cc: gen-art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org In-Reply-To: <387eea8b-6f77-c94e-d67e-180ef17cd0f0@acm.org> (petithug@acm.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 14 May 2018 22:18:00 -0400 Message-ID: <877eo5vezr.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4wfCZArg1CqpTngJJvZPGQjADBTYcFKuNP7Tgh6La5vcruVByqLR9ghk+aCTo9icMqRkANL46U+0cz8wNBRCA7/Ord6oHmfPQLevgxiCKAKx2E/ja0NqsC QJptPF9BUDBJ44029Z9gZHdMkf3BZFdgw6qhvGnn0MM69Q5ucJFP2k8aoy37ecQ9uUxJ4lcsE70FK8E6tJaOnNg4Nr1Ah4kGS9vzAXFBVpuLEkiNh5+R8Kd2 g6y0o6ad6qiAcLl23VOuN23A3nnAgTGpHG2gfwoPsSvfX/FmZKmMeqV7lDWgp0G8j2q+ln844V+R0gs9cxNiBNrogQ3JQ3irttij6Q61L/XN7KfDpdS4XVeP mB+OAdWRFz3QGiKTtxt9YQ94flU8Xg== Archived-At: Subject: Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 15 May 2018 02:18:06 -0000 Marc Petit-Huguenin writes: >> To do that, it follows the >> identification procedures defined in [RFC6125], with a certificate >> containing an identifier of type DNS-ID or CN-ID, eventually with >> wildcards, but not of type SRV-ID or URI-ID. >>=20 >> The meaning of "eventually" here is not clear. > > Rephrased as: > > [...] > containing an identifier of type DNS-ID or CN-ID, eventually with a > wildcard character as leftmost label, but not of type SRV-ID or URI- > [...] I have some doubt about the use of "eventually" here. As I use it, "eventually" means that the thing will happen at some unspecified time in the future. Wiktionary gives this meaning also. But I looked "eventually" up in my paper dictionary, and it also has the meaning "dependent on circumstance; contingent". In this context, I do not see how the meaning about unspecified future time works. But perhaps you mean that having a wildcard character as leftmost label is contingent? That meaning works. But in that case, I would find "optionally" to be clearer. (And Google Translate says that "=C3=A9ventuellement" can be translated into English as either "eventually" or "optionally", although it provides "facultativement" as the first translation into French of "optionally".) You may wish to consult the RFC Editor about this. Dale From nobody Tue May 15 03:14:15 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 3443512D7F0; Tue, 15 May 2018 03:14:14 -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 yd47t1aqSKjR; Tue, 15 May 2018 03:14:12 -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 E384612D868; Tue, 15 May 2018 03:14:02 -0700 (PDT) Received: from [IPv6:2601:648:8300:e8a:d578:c438:f732:cb38] (unknown [IPv6:2601:648:8300:e8a:d578:c438:f732:cb38]) (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 B48D3AE844; Tue, 15 May 2018 12:13:59 +0200 (CEST) To: "Dale R. Worley" Cc: gen-art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org References: <877eo5vezr.fsf@hobgoblin.ariadne.com> From: Marc Petit-Huguenin Message-ID: Date: Tue, 15 May 2018 03:13:45 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <877eo5vezr.fsf@hobgoblin.ariadne.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="D0y4dtMtx4nkC3esTkz21W5hO1b5B24lK" Archived-At: Subject: Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 15 May 2018 10:14:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --D0y4dtMtx4nkC3esTkz21W5hO1b5B24lK Content-Type: multipart/mixed; boundary="5RkcEDcKefaUrr7khC2WBpkVZWihO9ojo"; protected-headers="v1" From: Marc Petit-Huguenin To: "Dale R. Worley" Cc: gen-art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org Message-ID: Subject: Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16 References: <877eo5vezr.fsf@hobgoblin.ariadne.com> In-Reply-To: <877eo5vezr.fsf@hobgoblin.ariadne.com> --5RkcEDcKefaUrr7khC2WBpkVZWihO9ojo Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 05/14/2018 07:18 PM, Dale R. Worley wrote: > Marc Petit-Huguenin writes: >>> To do that, it follows the >>> identification procedures defined in [RFC6125], with a certificate= >>> containing an identifier of type DNS-ID or CN-ID, eventually with >>> wildcards, but not of type SRV-ID or URI-ID. >>> >>> The meaning of "eventually" here is not clear. >> >> Rephrased as: >> >> [...] >> containing an identifier of type DNS-ID or CN-ID, eventually with a= >> wildcard character as leftmost label, but not of type SRV-ID or URI= - >> [...] >=20 > I have some doubt about the use of "eventually" here. As I use it, > "eventually" means that the thing will happen at some unspecified time > in the future. Wiktionary gives this meaning also. But I looked > "eventually" up in my paper dictionary, and it also has the meaning > "dependent on circumstance; contingent". >=20 > In this context, I do not see how the meaning about unspecified future > time works. But perhaps you mean that having a wildcard character as > leftmost label is contingent? That meaning works. But in that case, I= > would find "optionally" to be clearer. (And Google Translate says that= > "=C3=A9ventuellement" can be translated into English as either "eventua= lly" > or "optionally", although it provides "facultativement" as the first > translation into French of "optionally".) >=20 > You may wish to consult the RFC Editor about this. >=20 No, you are right, I was using "eventually" incorrectly all this time. I= changed "eventually" to "optionally" in my copy. Thanks. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --5RkcEDcKefaUrr7khC2WBpkVZWihO9ojo-- --D0y4dtMtx4nkC3esTkz21W5hO1b5B24lK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlr6stkACgkQKcRFldZq fsQiWxAAzKLguwtoYYEj8sbrtFfiI8T0t/GmDxt3KQ/rZG/NH0pr3MHoaVREeghE Qie7aH1SP0LnFLgZpkTeXSXqFJNnRD5Z54PG5TqWBQYi5Yewl8yDF7ml3geuU2Kv LSujSov0CmvK51Lz2ALfvZlWsYLAhN+NLjtfQdTVbCvVNJ4jP64JUdVhOQq3IbHe DzKIY/wMaFd22H6uBy/yGKQ99oh2RR+r1n7M/ltGbAO/JCGC+gGty0xyLtDieFOV +bZkWXlggMu8KqxTGoMCcPA6zM60WBpYjR7OoBujtC9mLGwoSGSunyv0MtuaFjyL hO/D/ccumY/sCgcH4YOw1vVWdrdimZ9IG2ZblPwrgx6Z97yeUBOHvWpOc4u9LW34 g12VVPSnhhQtjN2z3fi3/swYZ7xvYgsjDdZZLqEqgSiqkfnihAc6dOlg7yyzGmPV mFZxdknpj2LmLQe/8+aphDGbWe/5Hh1EUUoLG/CUDm6+xCSxF+/6ULOU/8NPUTkS DHVGtJk0WtuHTODsEgnIYDCtMLejnW6lWJrk31UOQRGKo49Q8pSqsATlRBrvSDMI a84UF5HKRJpOGwphNQtg0bqodUdi3zRKodH5ookjbCSnieuacwsXFPkpZjs2w3kG JRADdSi2bK2Og5OqZLf+n7AZa5BY47a0Gmb7rDaT77jr0Zn3E1k= =iFA5 -----END PGP SIGNATURE----- --D0y4dtMtx4nkC3esTkz21W5hO1b5B24lK-- From nobody Tue May 15 08:34:04 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 3B60F12D945; Tue, 15 May 2018 08:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 dtuBkWnsYphB; Tue, 15 May 2018 08:33:58 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 79AC512D942; Tue, 15 May 2018 08:33:58 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id q7-v6so183300ywd.9; Tue, 15 May 2018 08:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=biv3EiCPlCrMw8HcTF+diAd9HO+iOoail8NF8h6a95o=; b=uPwFWzGxzdnPUsPnAPu+uFL+PY0LI8Ft6Wrce8pmA5HgBPEsE9hVCMiHiXU09xR81w 9xeFToLPpSsADOOq60YpzHjsLVpz9laxA3fKAj3yw/YT+SYTMz2RMxbLLyC8rWRF+csd vO+tT8bpm7gZTQ5QuM81cyV0Ypud2Tyl0N74MDDvKHyOUYiQ6zzuHrl6nifGWo70eZMR 9sjKZtt2zKScs/hGIjTyQqitZ4Fpy//HLjuoaVOW2mF9r3UzbkHBiGg1wssJPl46TvjW CoFdaBG0UMi99M44HfN2H2unU6SHgszd+iH89GlFmv0M8VQ7NzZzZv6c8VLT90uc1Co7 sVuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=biv3EiCPlCrMw8HcTF+diAd9HO+iOoail8NF8h6a95o=; b=p8FAZWK7KJadcaFC1iSzfkfMeUpOq1ZBs+OhGa+I/oBrkrnhUt29Mu5BUNvON9Hc1a Bk04nEymskV6yq8sfl8zFnaJGvrUnd3/uHj2i3JsMh8b1TUXq34260r3woeTZg+lZV6R vPcNAhKJpyoX06ZXyNaaRCDdA044sSuoiMqmwrJeXXGUX+PhtOvu14Azdcd9oC3TYeSV pgIfBiJzu8P7j4661hc3nUB+TvQflS4qtplcWoFyf2uMIGpSQ68CVg7FTeiuSN9Hb6yy HnaFtqlJkSz3N72EpeQEINyhCx/PTQAER/1k4leONMX/Ql1FlszVcAofYgnq+rHjyeoq ovXA== X-Gm-Message-State: ALKqPweIZAuhkEyC8Cy4GLXHZ5yp70dAuyzNBpt9GjguPQzFt5rJI0K8 y8ccSrST9RJLG/1hlsybRB+fxc3x3ZPAFjyLt94= X-Google-Smtp-Source: AB8JxZosAn8fEAyt8NMK7msObQ7k23hqSBIhJGAWjidbmcJdMw57O/In7MvqxGFKzW18CrUf5EiXKd4xFDlBQQ0NV1Y= X-Received: by 2002:a81:ec14:: with SMTP id j20-v6mr6582491ywm.311.1526398437583; Tue, 15 May 2018 08:33:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:d014:0:0:0:0:0 with HTTP; Tue, 15 May 2018 08:33:57 -0700 (PDT) In-Reply-To: <55552202-8550-235b-b907-5f7dd65dbde2@petit-huguenin.org> References: <152421676370.10784.8969648253452773656.idtracker@ietfa.amsl.com> <55552202-8550-235b-b907-5f7dd65dbde2@petit-huguenin.org> From: Spencer Dawkins at IETF Date: Tue, 15 May 2018 10:33:57 -0500 Message-ID: To: Marc Petit-Huguenin Cc: draft-ietf-tram-stun-pmtud@ietf.org, tram-chairs@ietf.org, tram@ietf.org, Tolga Asveren Content-Type: multipart/alternative; boundary="000000000000a870cc056c405459" Archived-At: Subject: Re: [tram] Publication has been requested for draft-ietf-tram-stun-pmtud-07 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 15 May 2018 15:34:02 -0000 --000000000000a870cc056c405459 Content-Type: text/plain; charset="UTF-8" Hi, Marc, On Mon, May 14, 2018 at 6:50 PM, Marc Petit-Huguenin < marc@petit-huguenin.org> wrote: > Hi Spencer, > > Thank you for the review. Please see inline. > > On 05/08/2018 08:31 PM, Spencer Dawkins at IETF wrote: > > Dear Authors, > > > > On Fri, Apr 20, 2018 at 4:32 AM, Gonzalo Camarillo < > > gonzalo.camarillo@ericsson.com> wrote: > > > >> Gonzalo Camarillo has requested publication of > >> draft-ietf-tram-stun-pmtud-07 as Proposed Standard on behalf of the TRAM > >> working group. > >> > >> Please verify the document's state at https://datatracker.ietf.org/ > >> doc/draft-ietf-tram-stun-pmtud/ > > > > > > This document was fairly clear to me. I did have some questions I'd like > to > > work through before requesting Last Call, but none of them are > showstoppers > > - they shouldn't even slow the show down much. > > > > Thanks, > > > > Spencer > > > > I've been wrong before, but I'm thinking that > > > > Not all UDP-based protocols implement the Path MTU discovery > > mechanism described in [RFC4821]. > > > > is an understatement - I'm thinking of several widely used UDP-based > > protocols that try to use heuristics including just pick a low MTU size, > or > > switch to TCP transport, or some other workaround. This statement seems > to > > say that most UDP-based protocols do RFC 4821. Is it fair to say that > many > > UDP-based protocols don't do RFC 4821 PMTU discovery? > > New text: > > Many UDP-based protocols do not implement the Path MTU discovery > mechanism described in [RFC4821]. These protocols can make use of > [...] > > > > > For this section, > > > > 3. Terminology > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > document are to be interpreted as described in [RFC2119]. When these > > words are not in ALL CAPS (such as "must" or "Must"), they have their > > usual English meanings, and are not to be interpreted as RFC 2119 key > > words. > > > > you might consider replacing it with the corresponding paragraph in > > https://tools.ietf.org/html/rfc8174 - I'm seeing an increasing number of > > comments on IESG ballots suggesting this, and it's likely that the new > BCP > > text will more familiar to most readers over time. > > Done. > > > > > This may be a dumb question, but in this text, > > > > Implementations supporting this specification MUST implement the > > server side of both the Simple Probing mechanism (Section 4.1) and > > the Complete Probing mechanism (Section 4.2). > > > > Implementations supporting this specification MUST implement the > > client side of the Complete Probing mechanism. They MAY implement > > the client side of the Simple Probing mechanism. > > > > does this mean "Server implementations" and "Client implementations"? > > No, a compliant implementation must support both the client and the server > side so to discover the PMTU in both directions. The only choice is to not > support the client side of the simple probing mechanism. > > > > > I'm a bit confused about this text: > > > > Some application layer protocols may already have a way of > > identifying each individual UDP packet, in which case these > > identifiers SHOULD be used in the IDENTIFIERS attribute of the Report > > Response. While there are other possible packet identification > > schemes, this document describes two different ways to identify a > > specific packet. > > > > In the first packet identification mechanism, the server computes a > > checksum over each packet received and sends back to the sender the > > list of checksums ordered chronologically. The client compares this > > list to its own list of checksums. > > > > In the second packet identification mechanism, the client prepends > > the UDP data with a header that provides a sequence number. The > > server sends back the chronologically ordered list of sequence > > numbers received that the client then compares with its own list. > > > > It wasn't clear to me from this text whether these two packet > > identification mechanism are descriptions of what applications do if they > > DON'T already have a way of identifying packets. If that's what's > intended, > > perhaps > > > > Some application layer protocols may already have a way of > > identifying each individual UDP packet, in which case these > > identifiers SHOULD be used in the IDENTIFIERS attribute of the Report > > Response. While there are other possible packet identification > > schemes, this document describes two different ways to identify a > > specific packet, when no application layer protocol-specific > > identification > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > mechanism is available. > > ^^^^^^^^^^^^^^^^^^^^^^ > > ? > > Applied. > > > > > When I read this text, > > > > Then the client waits half the RTO, if it is known, or 250 ms after > > sending the last Probe Indication and then sends the Report Request > > to the server over UDP. > > > > I was confused - isn't there's a 500-ms default RTO value in 4.1.1? Is > this > > different from > > > > Then the client waits half the RTO after > > sending the last Probe Indication and then sends the Report Request > > to the server over UDP. > > > > or am I missing your point? > > Replaced by your text. > > > > > In this text, > > > > The algorithm used to calculate the checksum is similar to the > > algorithm used for the FINGERPRINT attribute (i.e., the CRC-32 of the > > payload XOR'ed with the 32-bit value 0x5354554e). > > > > is there a reference you could provide for the "algorithm used for the > > FINGERPRINT attribute" here? I'm pretty sure I could find the right one, > > but googling for "STUN FINGERPRINT checksum" is a lot less helpful than I > > expected, and making sure that you understand what something is "similar > > to" seems important if that's going to be helpful information for > > implementers. > > Added reference to ITU V42. > > > > > If using authentication in > > > > UDP-based protocols that want to use any of these mechanisms, > > including the PMTUD-SUPPORTED attribute, to signal PMTUD capabilities > > MUST ensure that it cannot be used to launch an amplification attack. > > For example, using authentication can ensure this. > > > > is only one way to ensure prevention of amplification attacks, is there > any > > guidance or reference you could point to that would help implementers > > evaluate other approaches? > > It's a good question. I have to think about that. > Thanks for the quick and thorough responses. I think I'm good on your responses for all my other questions. I'll let the working group chew on this one, and let the chairs/shepherd let me know when to request Last Call. Spencer > > Actually, after reading > > > > The Probe Request or Indication that are used to implicitly signal > > probing support in the reverse direction MUST be authenticated to > > prevent amplification attacks. > > > > I wonder why authentication isn't a MUST for UDP-based protocols using > > STUN-PMTUD, but that's just me wondering ... > > When STUN-PMTUD is used as an add-on to an existing protocol, it is > difficult to impose to make the whole protocol authenticated. When it is > for a new protocol I agree that it should be secure, but then it is up to > the protocol designer to do that (and to the IESG to enforce it). > > > > > I was a bit confused by > > > > This specification defines two new STUN methods and two new STUN > > attributes. IANA added these new protocol elements to the "STUN > > Parameters Registry" created by [RFC5389]. > > > > because they haven't been added to the registry yet, right? > > > > Right. I changed the whole IANA section to look like the one in STUNBis. > > -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: https://marc.petit-huguenin.org > Profile: https://www.linkedin.com/in/petithug > > --000000000000a870cc056c405459 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Marc,=C2=A0

On Mon, May 14, 2018 at 6:50 PM, Marc Petit-Huguenin <marc@petit-huguenin.org> wrote:
Hi Spencer,

Thank you for the review.=C2=A0 Please see inline.

On 05/08/2018 08:31 PM, Spencer Dawkins at IETF wrote:
> Dear Authors,
>
> On Fri, Apr 20, 2018 at 4:32 AM, Gonzalo Camarillo <
> gonzalo.camarillo@er= icsson.com> wrote:
>
>> Gonzalo Camarillo has requested publication of
>> draft-ietf-tram-stun-pmtud-07 as Proposed Standard on behalf of th= e TRAM
>> working group.
>>
>> Please verify the document's state at https://datatracker.= ietf.org/
>> doc/draft-ietf-tram-stun-pmtud/
>
>
> This document was fairly clear to me. I did have some questions I'= d like to
> work through before requesting Last Call, but none of them are showsto= ppers
> - they shouldn't even slow the show down much.
>
> Thanks,
>
> Spencer
>
> I've been wrong before, but I'm thinking that
>
>=C2=A0 =C2=A0Not all UDP-based protocols implement the Path MTU discove= ry
>=C2=A0 =C2=A0 mechanism described in [RFC4821].
>
> is an understatement - I'm thinking of several widely used UDP-bas= ed
> protocols that try to use heuristics including just pick a low MTU siz= e, or
> switch to TCP transport, or some other workaround. This statement seem= s to
> say that most UDP-based protocols do RFC 4821. Is it fair to say that = many
> UDP-based protocols don't do RFC 4821 PMTU discovery?

New text:

=C2=A0 =C2=A0Many UDP-based protocols do not implement the Path MTU discove= ry
=C2=A0 =C2=A0mechanism described in [RFC4821].=C2=A0 These protocols can ma= ke use of
=C2=A0 =C2=A0[...]

>
> For this section,
>
> 3.=C2=A0 Terminology
>
>=C2=A0 =C2=A0 The key words "MUST", "MUST NOT", &qu= ot;REQUIRED", "SHALL", "SHALL NOT",
>=C2=A0 =C2=A0 "SHOULD", "SHOULD NOT", "RECOMME= NDED", "MAY", and "OPTIONAL" in this
>=C2=A0 =C2=A0 document are to be interpreted as described in [RFC2119].= =C2=A0 When these
>=C2=A0 =C2=A0 words are not in ALL CAPS (such as "must" or &q= uot;Must"), they have their
>=C2=A0 =C2=A0 usual English meanings, and are not to be interpreted as = RFC 2119 key
>=C2=A0 =C2=A0 words.
>
> you might consider replacing it with the corresponding paragraph in > https://tools.ietf.org/html/rfc8174 - I'm seein= g an increasing number of
> comments on IESG ballots suggesting this, and it's likely that the= new BCP
> text will more familiar to most readers over time.

Done.

>
> This may be a dumb question, but in this text,
>
>=C2=A0 =C2=A0 Implementations supporting this specification MUST implem= ent the
>=C2=A0 =C2=A0 server side of both the Simple Probing mechanism (Section= 4.1) and
>=C2=A0 =C2=A0 the Complete Probing mechanism (Section 4.2).
>
>=C2=A0 =C2=A0 Implementations supporting this specification MUST implem= ent the
>=C2=A0 =C2=A0 client side of the Complete Probing mechanism.=C2=A0 They= MAY implement
>=C2=A0 =C2=A0 the client side of the Simple Probing mechanism.
>
> does this mean "Server implementations" and "Client imp= lementations"?

No, a compliant implementation must support both the client and the = server side so to discover the PMTU in both directions.=C2=A0 The only choi= ce is to not support the client side of the simple probing mechanism.

>
> I'm a bit confused about this text:
>
>=C2=A0 =C2=A0 Some application layer protocols may already have a way o= f
>=C2=A0 =C2=A0 identifying each individual UDP packet, in which case the= se
>=C2=A0 =C2=A0 identifiers SHOULD be used in the IDENTIFIERS attribute o= f the Report
>=C2=A0 =C2=A0 Response.=C2=A0 While there are other possible packet ide= ntification
>=C2=A0 =C2=A0 schemes, this document describes two different ways to id= entify a
>=C2=A0 =C2=A0 specific packet.
>
>=C2=A0 =C2=A0 In the first packet identification mechanism, the server = computes a
>=C2=A0 =C2=A0 checksum over each packet received and sends back to the = sender the
>=C2=A0 =C2=A0 list of checksums ordered chronologically.=C2=A0 The clie= nt compares this
>=C2=A0 =C2=A0 list to its own list of checksums.
>
>=C2=A0 =C2=A0 In the second packet identification mechanism, the client= prepends
>=C2=A0 =C2=A0 the UDP data with a header that provides a sequence numbe= r.=C2=A0 The
>=C2=A0 =C2=A0 server sends back the chronologically ordered list of seq= uence
>=C2=A0 =C2=A0 numbers received that the client then compares with its o= wn list.
>
> It wasn't clear to me from this text whether these two packet
> identification mechanism are descriptions of what applications do if t= hey
> DON'T already have a way of identifying packets. If that's wha= t's intended,
> perhaps
>
>=C2=A0 =C2=A0Some application layer protocols may already have a way of=
>=C2=A0 =C2=A0 identifying each individual UDP packet, in which case the= se
>=C2=A0 =C2=A0 identifiers SHOULD be used in the IDENTIFIERS attribute o= f the Report
>=C2=A0 =C2=A0 Response.=C2=A0 While there are other possible packet ide= ntification
>=C2=A0 =C2=A0 schemes, this document describes two different ways to id= entify a
>=C2=A0 =C2=A0 specific packet, when no application layer protocol-speci= fic
> identification
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>=C2=A0 =C2=A0 mechanism is available.
>=C2=A0 =C2=A0 ^^^^^^^^^^^^^^^^^^^^^^
> ?

Applied.

>
> When I read this text,
>
>=C2=A0 =C2=A0Then the client waits half the RTO, if it is known, or 250= ms after
>=C2=A0 =C2=A0 sending the last Probe Indication and then sends the Repo= rt Request
>=C2=A0 =C2=A0 to the server over UDP.
>
> I was confused - isn't there's a 500-ms default RTO value in 4= .1.1? Is this
> different from
>
>=C2=A0 =C2=A0Then the client waits half the RTO after
>=C2=A0 =C2=A0 sending the last Probe Indication and then sends the Repo= rt Request
>=C2=A0 =C2=A0 to the server over UDP.
>
> or am I missing your point?

Replaced by your text.

>
> In this text,
>
>=C2=A0 =C2=A0The algorithm used to calculate the checksum is similar to= the
>=C2=A0 =C2=A0 algorithm used for the FINGERPRINT attribute (i.e., the C= RC-32 of the
>=C2=A0 =C2=A0 payload XOR'ed with the 32-bit value 0x5354554e).
>
> is there a reference you could provide for the "algorithm used fo= r the
> FINGERPRINT attribute" here? I'm pretty sure I could find the= right one,
> but googling for "STUN FINGERPRINT checksum" is a lot less h= elpful than I
> expected, and making sure that you understand what something is "= similar
> to" seems important if that's going to be helpful information= for
> implementers.

Added reference to ITU V42.

>
> If using authentication in
>
>=C2=A0 =C2=A0UDP-based protocols that want to use any of these mechanis= ms,
>=C2=A0 =C2=A0 including the PMTUD-SUPPORTED attribute, to signal PMTUD = capabilities
>=C2=A0 =C2=A0 MUST ensure that it cannot be used to launch an amplifica= tion attack.
>=C2=A0 =C2=A0 For example, using authentication can ensure this.
>
> is only one way to ensure prevention of amplification attacks, is ther= e any
> guidance or reference you could point to that would help implementers<= br> > evaluate other approaches?

It's a good question.=C2=A0 I have to think about that.

Thanks for the quick and thorough responses.

I think I'm good on your responses for all my ot= her questions. I'll let the working group chew on this one, and let the= chairs/shepherd let me know when to request Last Call.

Spencer
=C2=A0
> Actually, after reading
>
>=C2=A0 =C2=A0The Probe Request or Indication that are used to implicitl= y signal
>=C2=A0 =C2=A0 probing support in the reverse direction MUST be authenti= cated to
>=C2=A0 =C2=A0 prevent amplification attacks.
>
> I wonder why authentication isn't a MUST for UDP-based protocols u= sing
> STUN-PMTUD, but that's just me wondering ...

When STUN-PMTUD is used as an add-on to an existing protocol, it is = difficult to impose to make the whole protocol authenticated.=C2=A0 When it= is for a new protocol I agree that it should be secure, but then it is up = to the protocol designer to do that (and to the IESG to enforce it).

>
> I was a bit confused by
>
>=C2=A0 =C2=A0This specification defines two new STUN methods and two ne= w STUN
>=C2=A0 =C2=A0 attributes.=C2=A0 IANA added these new protocol elements = to the "STUN
>=C2=A0 =C2=A0 Parameters Registry" created by [RFC5389].
>
> because they haven't been added to the registry yet, right?
>

Right.=C2=A0 I changed the whole IANA section to look like the one i= n STUNBis.

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


--000000000000a870cc056c405459-- From nobody Tue May 15 11:24:54 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 CEAFE12E04F; Tue, 15 May 2018 11:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 3sBfKHL11vuN; Tue, 15 May 2018 11:24:50 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 640A11241FC; Tue, 15 May 2018 11:24:49 -0700 (PDT) X-AuditID: 12074424-707ff70000001acb-c7-5afb25ed9865 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 8A.70.06859.EE52BFA5; Tue, 15 May 2018 14:24:47 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w4FIOfIO031389; Tue, 15 May 2018 14:24:42 -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 w4FIOZHT030577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 May 2018 14:24:38 -0400 Date: Tue, 15 May 2018 13:24:35 -0500 From: Benjamin Kaduk To: Marc Petit-Huguenin Cc: Eric Rescorla , tram-chairs@ietf.org, tram@ietf.org, Gonzalo Camarillo , tasveren@rbbn.com, The IESG , draft-ietf-tram-stunbis@ietf.org Message-ID: <20180515182435.GN2249@kduck.kaduk.org> References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <31a441d2-8843-c8ee-f5ef-5496e5b4b364@acm.org> <29c18858-3694-c48a-54c3-6dcbfa3b6705@acm.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oLBj+sq0vYjzfsbl" Content-Disposition: inline In-Reply-To: <29c18858-3694-c48a-54c3-6dcbfa3b6705@acm.org> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMKsWRmVeSWpSXmKPExsUixG6nrvte9XeUQf8bNYvOLZfZLFa8Psdu sWn5SiaLGX8mMltcWHOXyWL98m/sFst/rmSz+LD2ApsDh8flK94ev75eZfNYsuQnk8eeOZMY PSY/bmMOYI3isklJzcksSy3St0vgytj0+xZTwW+7irO9k9gbGFcZdTFyckgImEjM77zK3MXI xSEksJhJ4uPTb2wgCSGBjYwSN5d5QiSuMkk83XMGLMEioCpx9PFDJhCbTUBFoqH7MjOILSKg JbF/ynWwScwCtxgl9vT8ZQdJCAukS9x+dZ0VxOYVMJZY1fiGBWLqCiaJW1P/MEMkBCVOznzC AmIzC5RJfD/9ibGLkQPIlpZY/o8DJMwpYC3xbud1sHJRAWWJvX2H2CcwCsxC0j0LSfcshG6I sJbEjX8vmTCEtSWWLXzNDGHbSqxb955lASP7KkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1zvdzM Er3UlNJNjOD4clHZwdjd432IUYCDUYmH98LNX1FCrIllxZW5hxglOZiURHmt/wCF+JLyUyoz Eosz4otKc1KLDzGqAO16tGH1BUYplrz8vFQlEd5M3t9RQrwpiZVVqUX5MGXSHCxK4ryCmz9E CQmkJ5akZqemFqQWwWRlODiUJHgvqgA1ChalpqdWpGXmlCCkmTg4DzFKcPAADfdTBRleXJCY W5yZDpE/xagoJc6rBZIQAElklObB9YLSokT2/ppXjOJAbwnz+oOs4AGmVLjuV0CDmYAGF536 DjK4JBEhJdXA6O9y5j3vrwVVjl6tCX4dlsah5jnlulKx24Sd4rMZFLOMXXUPb6ydf/VI8dUJ zg+81G86xLf8WNax46v736bf+4ze+gZ4M/xxn7F+3X4+07suyQ/5l6fuPO/V6nS5SUiqSzr6 TYDbY8U2XvNMHuvZfxsmdfK896macDVwgbj9bOMNwRb1q/KUWIozEg21mIuKEwE0TsDKZgMA AA== 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.22 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, 15 May 2018 18:24:53 -0000 --oLBj+sq0vYjzfsbl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I think I have the same understanding as Ekr, in which case the bid-down concerns apply only to message integrity and not to password-algorithm. So it would be good to hear from the WG on this issue. -Benjamin On Mon, May 14, 2018 at 01:06:00PM -0700, Marc Petit-Huguenin wrote: > During the discussion about choosing password algorithms, someone came to= the microphone (AFAIR) and said that it was subject to bid-down attack. W= e then design a solution to prevent that and that's what, after more discus= sions, we put in the draft. So I welcome any comment on the strength or we= akness of the protection offered by the scheme we put in place and any sugg= estion to make it better, but as for the reasons it is there you will have = to talk to the Working Group. >=20 > Thanks. >=20 > On 05/03/2018 04:45 PM, Eric Rescorla wrote: > > No, I don't understand this at all. This section talks about a bid-down= on > > the PASSWORD-ALGORITHM, but I don't see how a weakness in MD5 is releva= nt > > here. > >=20 > > Assuming I understand correctly, the structure of the protocol is that > > given a password, you do: > >=20 > > key =3D Password-Algorithm(username, realm, password) > >=20 > > And then use key with HMAC for an integrity check, where HMAC is SHA-1 > > (with MESSAGE-INTEGRITY) or SHA-256 (with MESSAGE-INTEGRITY-SHA256). > > However, in this case the MD5 isn't a security critical component at the > > protocol layer [0], because it's just is just to act as a transformatio= n of > > the password into a fixed-length string for use as a key, so this doesn= 't > > require collision resistance or pseudorandomness. I could be wrong here, > > but if so, please describe a potential weakness in MD5 which could lead= to > > compromise of this protocol > >=20 > > -Ekr > >=20 > > [0] It might be an issue if someone were to recover the hashed password. > >=20 > > On Thu, May 3, 2018 at 4:34 PM, Marc Petit-Huguenin > > wrote: > >=20 > >> On 04/22/2018 02:02 PM, Marc Petit-Huguenin wrote: > >>> Hi Eric, > >>> > >>> Thanks for the review, please see my responses inline. > >>> > >>> On 04/16/2018 12:57 PM, Eric Rescorla wrote: > >>>> Eric Rescorla has entered the following ballot position for > >>>> draft-ietf-tram-stunbis-16: Discuss > >>>> > >>>> When responding, please keep the subject line intact and reply to all > >>>> email addresses included in the To and CC lines. (Feel free to cut t= his > >>>> introductory paragraph, however.) > >>>> > >>>> > >>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > >> html > >>>> for more information about IESG DISCUSS and COMMENT positions. > >>>> > >>>> > >>>> The document, along with other ballot positions, can be found here: > >>>> https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ > >>>> > >>>> > >>>> > >>>> --------------------------------------------------------------------= -- > >>>> DISCUSS: > >>>> --------------------------------------------------------------------= -- > >>>> > >>>> Rich version of this review at: > >>>> https://mozphab-ietf.devsvcdev.mozaws.net/D5132 > >>>> > >>>> > >>>> Can you please indicate how you addressed the points Matt Miller > >>>> raised in his secdir review about the use of MD5. > >>> > >>> From my response on 2018-03-11: > >>> > >>>> * The description for 17.5.1. "MD5" list the key size as 20 bytes, b= ut > >> the > >>>> hash length of MD5 is 16 bytes (128 bits). I think this is merely a > >> typo, > >>>> since the purpose appears to be for backwards compatibility with > >> existing > >>>> systems. > >>> > >>> Fixed. > >>> > >>>> > >>>> * Both 17.5.1.1. "MD5" Section 9.2.2. "HMAC Key" (long-term credenti= al) > >>>> and Section appear to define the same functional algorithm, but with > >> subtle > >>>> syntax differences. As far as I can tell, they are actually the same > >>>> algorithm; would it not be acceptable to have Section 9.2.2 point to > >>>> Section 17.5.1.1 for the algorithm description? > >>>> > >>>> > >>> > >>> This is going into the IANA registry so I left things there. I fixed > >> the discrepancy with section 9.2.2. > >>> > >>> I also fixed the definition of the key for SHA-256, which must use > >> OpaqueString for the realm. > >>> > >>>> > >>>> > >>>> > >>>> DETAIL > >>>>> by the agent sending the indication. It primarily serves to > >>>>> correlate requests with responses, though it also plays a small > >> role > >>>>> in helping to prevent certain types of attacks. The server al= so > >> uses > >>>>> the transaction ID as a key to identify each transaction uniqu= ely > >>>>> across all clients. As such, the transaction ID MUST be unifo= rmly > >>>>> and randomly chosen from the interval 0 .. 2**96-1, and SHOULD= be > >>>> > >>>> I didn't realize this was a SHOULD. ICE depends on it as a security > >>>> condition, so it probably needs to be a MUST. > >>> > >>> Done. > >>> > >>>> > >>>> > >>>>> 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 indicat= ion > >>>>> 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. > >>> > >>>> > >>>> > >>>>> STUN Security Feature it is understood that the corresponding = STUN > >>>>> Security Feature bit in the "nonce cookie" is set to 1. > >>>>> > >>>>> For example, in Section 9.2.4 discussing the PASSWORD-ALGORITH= MS > >>>>> security feature, it is implied that the "Password algorithms" > >> bit, > >>>>> as defined in Section 17.1, is set to 1 in the "nonce cookie". > >>>> > >>>> I'm not sure I understand the bid down attack here or the proposed > >>>> defense. Can you please walk through what the assumed attacker > >>>> capabilities are, what the client and server capabilities are, how t= he > >>>> bid down attack works, and how this protects against it? > >>> > >>> The plan is to add an annex to the document explaining that. I'll > >> finish to process the other reviews from the IESG and then come back to > >> that. > >>> > >> > >> Instead of an annex, we added a new section in the Security > >> Considerations. Please have a look at -17 and let us know if that > >> explanation is good enough. > >> > >> Thanks. > >> > >=20 >=20 >=20 >=20 > --=20 > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: https://marc.petit-huguenin.org > Profile: https://www.linkedin.com/in/petithug >=20 --oLBj+sq0vYjzfsbl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlr7Jd4ACgkQKNmm82Tr dRK5mAweKPd5Rwh7U2YMuQs1vYMMJSFeMI8N8aSQAkutUPlhy5qpKu4REhxxSQwZ EPDJ4R8asgWMADrWB2OIRBxfJJobjnOYx7uQZ1hMN1ZDq0hmsiS9h01fPoXrV2Ai OyJJ8PjOP64OmFHo0IK8P8/Jg/T6wN3WKyqeCNoNzh0nJgAQBScHqPrbamixDAS8 C1HnyXPaB08S7QJpwbGXBDn/Z/WSyybXmNMNb8zV+3nbb0AtFJdK3j520RPzTUQe 4OP+4kxsSZZ50PmQnj/1OnHp3zBKOOXFvb8tb3HKTXwghzhMsGw7/+LJC2uXiqlb 1tO8yeopq2kHagESjIQvXVfGGdYX8bhHRHWD+HCg87BF1hPFhIR4nV02yuor3QKA JVk5feull8xlJSXr6vN/IuJJNhn/2Dmm7B+cxpUvuALE5x7kQUq3n/UU3C+emvgS hWwLPU51raeBFdzDrbrOdpfr2XNxkvRmSYcR3YHdw3Qhrs3Rd3OmWOXLebTJk0Gx n5lcznRmD75feQ== =ljg/ -----END PGP SIGNATURE----- --oLBj+sq0vYjzfsbl-- From nobody Tue May 15 11:52:38 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 352E912E86D; Tue, 15 May 2018 11:52:31 -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 FmdWNAoKOPOi; Tue, 15 May 2018 11:52:28 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 820F112E858; Tue, 15 May 2018 11:52:27 -0700 (PDT) X-AuditID: 12074425-973ff7000000492e-09-5afb2c678b3d 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-8.mit.edu (Symantec Messaging Gateway) with SMTP id 07.D4.18734.86C2BFA5; Tue, 15 May 2018 14:52:25 -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 w4FIqIrI030124; Tue, 15 May 2018 14:52:19 -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 w4FIqDHm018987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 May 2018 14:52:15 -0400 Date: Tue, 15 May 2018 13:52:13 -0500 From: Benjamin Kaduk To: Marc Petit-Huguenin Cc: The IESG , tram-chairs@ietf.org, tasveren@rbbn.com, Gonzalo.Camarillo@ericsson.com, draft-ietf-tram-stunbis@ietf.org, tram@ietf.org Message-ID: <20180515185210.GO2249@kduck.kaduk.org> References: <152410023763.28841.5479872591399614102.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ALfTUftag+2gvp1h" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFKsWRmVeSWpSXmKPExsUixG6nopup8zvKoOeMhkXnlstsFpuWr2Sy mPFnIrPFhTV3mSzWL//GbrH850o2iw9rL7A5sHtcvuLt8evrVTaPJUt+MnnsmTOJMYAlissm JTUnsyy1SN8ugSvj+9kFjAX7exgrvlydzt7AeCC3i5GTQ0LARGLjhPWMXYxcHEICi5kkFu54 DeVsZJSYf7SdDcK5yiSx/s9aZpAWFgFViSUT/7GA2GwCKhIN3ZfB4iICWhL7p1xnBmlgFljB KDH3+QxWkISwQJzEvzPP2UFsXgFjiUdrvrOB2EICdRLPnn1nhogLSpyc+QRsKLNAmcSzjh6m LkYOIFtaYvk/DpAwp4C1xJRrp5lAbFEBZYm9fYfYJzAKzELSPQtJ9yyEboiwlsSNfy8xhbUl li18zQxh20qsW/eeZQEj+ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdC73czBK91JTSTYzgaHJR 3cE456/XIUYBDkYlHt4LN39FCbEmlhVX5h5ilORgUhLltf4DFOJLyk+pzEgszogvKs1JLT7E qAK069GG1RcYpVjy8vNSlUR4M3l/RwnxpiRWVqUW5cOUSXOwKInzCm7+ECUkkJ5YkpqdmlqQ WgSTleHgUJLgldMGahQsSk1PrUjLzClBSDNxcB5ilODgARpuCFLDW1yQmFucmQ6RP8WoKCXO e1ILKCEAksgozYPrBSVBiez9Na8YxYHeEuaNB2nnASZQuO5XQIOZgAYXnfoOMrgkESEl1cBo HpG8bImB1NTHvjvtG07eMHisyhpf/CWEu2KZTOOnr+W5YhPbvk87eXmRypIz7ltsra10n2s2 Ve2SWzIzeMJcJobPceVXl4nlxts+cV5guUJq1iKnPRdmXHEKF2AM1BSZvMngWv97z5rnO/5u log8+bvmsuG7nS8POebP4bCvXfJpj8LFJpMKJZbijERDLeai4kQAUnAT5l0DAAA= Archived-At: Subject: Re: [tram] Benjamin Kaduk's No Record on draft-ietf-tram-stunbis-16: (with COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 15 May 2018 18:52:31 -0000 --ALfTUftag+2gvp1h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 02, 2018 at 03:20:05PM -0700, Marc Petit-Huguenin wrote: > Hi Benjamin, >=20 > Thanks for the review, please see my responses inline. Sorry for the slow reply. > On 04/18/2018 06:10 PM, Benjamin Kaduk wrote: > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-tram-stunbis-16: No Record > >=20 > [...] > >=20 > >=20 > >=20 > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > >=20 > > I'm balloting No Objection and not DISCUSS because no individual > > item rises quite to that level of criticality, but there still are > > quite a number of things that ought to be addressed prior to > > publication. > >=20 > > In addition to the excellent points raised in the secdir review > > (which are mostly addressed but only in the editor's copy?), I > > would call out a few more key observations: > >=20 > > If I understand correctly, the server's PASSWORD-ALGORITHMS array > > from the response are echoed back by the client in the subsequent > > request in order to provide downgrade protection -- the initial > > response is at least sometimes not authenticated, and by having the > > client repeat it back under an authenticated scheme, the server can > > detect if the list was tampered to remove any new, stronger, > > algorithms. This is probably an important enough concept to be > > called out explicitly, either where the behavior is described or in > > Section 9.2.1 ("Bid Down Attack Prevention").usb >=20 > Yes, EKR had a similar question that I still have to answer, and I'll ans= wer both after this review. >=20 > >=20 > > Section 8.1 has some text that could be read as requiring a STUN > > client to implement dual-stack IPv4/IPv6, which presumably is not > > the intention: > > In addition, instead of querying either the A or the AAAA resource > > records for a domain name, the client MUST query both and try the > > requests with all the IP addresses received, as specified in > > [RFC8305]. >=20 > New text: >=20 > In addition, instead of querying either the A or the AAAA resource > records for a domain name, a dual-stack IPv4/IPv6 client MUST query > both and try the requests with all the IP addresses received, as > specified in [RFC8305]. SGTM. > >=20 > > There are still some places where the text talks about > > MESSAGE-INTEGRITY when it really means "message integrity > > protection" (i.e., either the SHA1 or SHA-256 variants, for now); > > I've attempted to note them in the notes below. > >=20 > > There is text in both Sections 9.1 and 9.2 that talks of replay > > protection being provided, by the time-limited nature of the > > short-term credentials or the nonce for long-term credentials. This > > seems to only, strictly speaking, be true if any given > > password/nonce can only be used once, but for the short-term > > credentials the password is used for the duration of the > > "session-equivalent", and for the long-term credentials a nonce can > > be reused for some amount of time as well. So while these are both > > replay countermeasures that can limit replay attacks, it seems a > > stretch to claim that they prevent replay attacks (entirely). >=20 > s/prevented/limited/ Thanks :) > >=20 > > The Stale Nonce behavior seems potentially worrisome, in that it > > opens up a side channel for a distinguishing attack, > > between a 401 and 438 response. (That is, "password correct" vs. > > "password incorrect".) The impact seems rather muted, though, since > > the gain to the attacker is to be able to precompute a bunch of > > requests using a nonce of the attacker's choosing and blindly replay > > the precomputed object against (possibly multiple) servers looking > > for a guess. The realm and username are still in play, so the scope > > for the attacker to gain from the precomputation seems limited. > > (The same level of brute-force guessing can be obtained "live" just > > by computing the trial responses against a live server, using a > > valid nonce.) So, while it might be nice to give guidance that 438 > > should only be used when the server can validate that it did > > generate the nonce and the nonce was valid "recently", and to treat > > other cases as authentication failures, it's not clear to me that > > there's enough of a benefit from the change to make it worth doing. >=20 > I am not sure what to do there. "Nothing" may be the right answer, though I guess there was a touch more follow-up on this point already. > >=20 > >=20 > > Section 6.2.3 > >=20 > > Maybe just cite BCP 195/RFC 7525 instead of inlining requirements? >=20 > Already fixed following a previous review. >=20 > >=20 > > Also, the "client SHOULD verify ..." and "client MUST verify ..." are > > similar enough that some clarification of certificate vs. identity > > verification would be in order, if both statements are believed > > accurate. >=20 > Changed SHOULD to MUST. WFM > >=20 > >=20 > > Section 6.3 > >=20 > > [...] Known-but-unexpected attributes SHOULD be ignored by > > the agent. [...] > >=20 > > Why is this not an error? >=20 > Probably an application of Postel's law but that text was already in RFC = 5389 so we cannot change it without breaking compatibility with RFC 5389 im= plementations. Ah, agreed about the compatibility implications. > >=20 > >=20 > > Section 6.3.1, 6.3.2, etc. > >=20 > > Should the second paragraph start with "Otherwise, "? Presumably > > once an error response is sent or processing ceases, processing stops... >=20 > Applied. >=20 > >=20 > >=20 > > Section 8.1 > >=20 > > [...] 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. > >=20 > > "the verifcation code" is probably unnecessarily vague; we're just > > talking about the (D)TLS SNI and certifciate verification code, > > right? >=20 > New text: >=20 > [...] > IP address is used directly to contact the server. 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 (D)TLS SNI and certificate > verification code. WFM. > >=20 > >=20 > >=20 > > Section 9.2 > >=20 > > [...[ The nonce provides the replay protection. It is a cookie, > > selected by the server, and encoded in such a way as to indicate a > > duration of validity or client identity from which it is valid. > >=20 > > Is this like a TLS cookie, where only the server needs to know about > > the internal structure (viz. "encoded" in the above)? If so, the > > text could probably be more clear. >=20 > New text: >=20 > [...] > a nonce. The nonce provides the replay protection. It is a cookie, > selected by the server, and encoded in such a way as to indicate a > duration of validity or client identity from which it is valid. Only > [...] I think the copy/paste was from the wrong spot, but looking at the diff, the new text works for me. > >=20 > > When mentioning just "a message-integrity", maybe forward-ref both > > versions of it to be more clear that we don't mean just the old one? >=20 > New text: >=20 > [...] > the realm, and echoing the nonce provided by the server. The client > also includes one of the message-integrity attributes defined in this > document, which provides an HMAC over the entire request, including > the nonce. The server validates the nonce and checks the message > [...] WFM > >=20 > > It's unclear why indications can't use a nonce, if one is known > > from a previous request/response on the same connection. >=20 > I think that the explanation is clear: "[...] indications cannot be chall= enged." and as there is no way to know the when a cookie will expire, we ca= nnot risk losing data for that reason. Okay. > >=20 > > When encoding the value of 0 for the security feature, it may be > > worth clarifying that it is still encoded as a 24-bit integer and > > base64-encoded, though the "13 character string" text ought to make > > this clear to the reader. >=20 > New text: >=20 > [...] > as the less significant bit of the third byte. If no security > features are used, then an integer with all 24 bit set to zero MUST > be encoded instead. For the remainder of this document the term > [...] Okay > >=20 > >=20 > > Section 9.2.4 > >=20 > > * If the request contains neither PASSWORD-ALGORITHMS nor > > PASSWORD- ALGORITHM, then the request is processed as though > > PASSWORD- ALGORITHM were MD5 (Note that if the original > > PASSWORD-ALGORITHMS attribute did not contain MD5, this will > > result in a 400 Bad Request in a later step below). > >=20 > > This Note seems a bit odd, since we're predicated on > > PASSWORD-ALGORITHMS being absent. >=20 > New text: >=20 > * If the request contains neither PASSWORD-ALGORITHMS nor > PASSWORD-ALGORITHM, then the request is processed as though > PASSWORD-ALGORITHM were MD5 (Note that if the PASSWORD- > ALGORITHMS attribute is present but does not contain MD5, this > will result in a 400 Bad Request in a later step below). Ah, this makes more sense. > >=20 > > * Otherwise, unless (1) PASSWORD-ALGORITHM and PASSWORD- > > ALGORITHMS are both present, (2) PASSWORD-ALGORITHMS matches > > the value sent in the response that sent this NONCE, and (3) > > PASSWORD-ALGORITHM matches one of the entries in PASSWORD- > > ALGORITHMS, the server MUST generate an error response with an > > error code of 400 (Bad Request). > >=20 > > Maybe we could be more clear about "the value of the > > PASSWORD-ALGORITHMS attribute in the message matches the value of > > the PASSWORD-ALGORITHMS attribute sent in the response that sent the > > NONCE used with this message"? >=20 > I am not sure what to do there. I think I was trying to propose: * Otherwise, unless (1) PASSWORD-ALGORITHM and PASSWORD- ALGORITHMS are both present, (2) the value of the PASSWORD-ALGORITHMS attribute in this message matches the value of the PASSWORD-ALGORITHMS attribute sent in the response that sent the NONCE used with this message, and (3) PASSWORD-ALGORITHM matches one of the entries in PASSWORD- ALGORITHMS, the server MUST generate an error response with an error code of 400 (Bad Request). Though I suspect that "this message" has a more appropriate term that could be used instead. > >=20 > >=20 > > Section 9.2.5 > >=20 > > If the response contains a PASSWORD-ALGORITHMS attribute, the > > subsequent request MUST be authenticated using MESSAGE-INTEGRITY- > > SHA256 only. > >=20 > > This means "all subsequent requests to this server"? Maybe the > > wording could be more clear. (It also means that if we get a new > > scheme when SHA256 is broken, the document introducing it may need > > to Update this document to remove the MUST.) >=20 > Fixed. >=20 > >=20 > > Also, I think the Security Feature bit is "Password algorithms" > > plural (in the next paragraph and maybe multiple locations in the > > document). >=20 > Fixed. >=20 > >=20 > >=20 > > Section 10 > >=20 > > [...] If the transaction uses TLS or DTLS and if the > > transaction is authenticated by a MESSAGE-INTEGRITY-SHA256 attribute > > and if the server wants to redirect to a server that uses a different > > certificate, then it MUST include an ALTERNATE-DOMAIN attribute > > containing the subjectAltName of that certificate. > >=20 > > The (definite article), implying the entire subjectAltName? Or just > > one name that is contained as a SAN entry? >=20 > New text: >=20 > [...] > or practical. If the transaction uses TLS or DTLS and if the > transaction is authenticated by a MESSAGE-INTEGRITY-SHA256 attribute > and if the server wants to redirect to a server that uses a different > certificate, then it MUST include an ALTERNATE-DOMAIN attribute > containing the name contained in the subjectAltName of that > certificate. The test on the MESSAGE-INTEGRITY-SHA256 attribute > [...] I think "a name contained in the subjectAltName of that certificate" is the expected meaning ("the" --> "a"), since SAN can be multi-valued. > >=20 > >=20 > > Section 14.8 > >=20 > > Need to not just say MESSAGE-INTEGRITY since the SHA256 variant > > should be fine as well. >=20 > Fixed. >=20 > >=20 > >=20 > > Section 14.10 > >=20 > > Maybe the nonce cookie should get a shout-out here? >=20 > Not sure, as when using stunbis with RFC 5389, the nonce cookie will not = be present. Even "in some cases, this value will include a 'nonce cookie' as defined previously in the document" might be useful, but I'll defer to your judgment. > >=20 > >=20 > > Section 14.12 > >=20 > > Do we need to talk about the padding, since this is the the sole > > contents of the attribute and the attribute padding suffices? >=20 > Added similar text that was added to 14 about setting the padding bits to= zero. Thanks > >=20 > > Also, "derive the long-term password" doesn't seem quite right; > > we're deriving the key from the long-term password, per Section > > 17.15.1. >=20 > New text: >=20 > The PASSWORD-ALGORITHM attribute is present only in requests. It > contains the algorithms that the server must use to derive a key from > the long-term password. SGTM > >=20 > >=20 > > Section 15.1.2 > >=20 > > There is no amplification of the number of packets with this attack > > (the STUN server sends one packet for each packet sent by the > > client), though there is a small increase in the amount of data, > > since STUN responses are typically larger than requests. > >=20 > > I usually hear amplification in terms of bytes or bandwidth, not > > packets. So maybe just "amplification is modest"? >=20 > That text is unchanged from RFC 5389. Additionally the text says that "[= =2E..]there is a small increase in the amount of data," I don't think that faithfulness to RFC 5389 need apply here (this is a full-fledged 'bis' version), but I also don't insist on any change; it's a very minor issue. > >=20 > >=20 > > Section 15.3 > >=20 > > This specification uses both HMAC-SHA1 and HMAC-SHA256 for > > computation of the message integrity. > >=20 > > Could perhaps be reworded, since the number of situations when both > > are used on the same message is small, and we try to push SHA256 > > when we can. >=20 > New text: >=20 > This specification uses both HMAC-SHA256 for computation of the > message integrity, sometimes in combination with HMAC-SHA1. If, at a > [...] "both" seems out of place, now. > >=20 > > o STUN Client and Server using the Short Term Credential Mechanism > >=20 > > Clients and Servers, plural. >=20 > Fixed. >=20 > >=20 > >=20 > > Section 17.32. > >=20 > > I'm confused why we have MUST-level requirements about using > > PASSWORD-ALGORITHMS when it is in the comprehension-optional range > > (e.g., echoing from response to repeated request as in Section > > 9.2.5). The server cannot actually enforce this MUST when talking > > to an old client if we want to retain the comprehension-optional > > semantics, IIUC. >=20 > It is comprehension-optional so old clients does not break. But old clie= nt MUST process them (comprehension-optional doe snot mean that processing = them is optional, but that an agent should not fail when seeing them and no= t understanding them). Probably I was just confused on my first read, sorry about that. (A client *implementing this spec* MUST echo PASSWORD-ALGORITHMS when generating a new request after an error response, but of course older clients don't implement this spec.) > >=20 > >=20 > > Section 17.6 > >=20 > > If we're adding support for DTLS-over-udp (per the next section), > > should we be registering stuns/udp? >=20 > Adam explained why it is not needed. >=20 > >=20 > > "password encryption algorithm" is not quite the right statement to > > make, since we're hashing, not encrypting. > >=20 >=20 > I am not what this is about, as these words are not used in this section = (or in the whole document). I see "password encryption algorithm" in the "Changes since RFC 5389" section, even in the -18. Thanks for all the explanations and updates! Benjamin --ALfTUftag+2gvp1h Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlr7LE0ACgkQKNmm82Tr dRJ7Xwwg0g0s7Q4go6+jFft2eU3+F3xS0VmWcUvG9Pu74M6tNleWnJSHlTEEcnic dD9KMCKkQFZiQXv72GPwCXkdETfU0rNZ7fmtfjoMbQ9rklMIKqj8ckX3LIGDFcHP RvpLd1CeqFcLOVsCv0HS+1Vldwzd8RBoQsLNeNQdjQa3CWuUv7ogMek90KNUkNtY n52VHz2TfnbYlPpY3PlojfC84xW1iGX9eqSk3nLAcx3mG3TAgyDs0OcuhkakUJBs Aics9qNc9i3ORmYEDVDBsRwk6JSzZ+4NwGkz1J/XDJ7Ba6sw/m4XBtyRXtOOwofG wKeQqpYH/LYxyX/iZWjjKlPcXegWRcVFIASaGYm/w/yZ1SNMQcOZuJCdiHw9DPch 61OWp/ttDvYB1cH/toSvf6WlOzV+PFvb76SOHcEZvPhNb34f72y2wNGYe78NriiR D7mDGa3ogmbBT43yjfvO0Pzw+vWlPFKn/ziAISgkKqOwoXpGKJGZRLZWcrezo6J0 8qAsMQKluMNCOA== =+i30 -----END PGP SIGNATURE----- --ALfTUftag+2gvp1h-- From nobody Wed May 16 06:01:14 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 7528312D876 for ; Wed, 16 May 2018 06:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.248, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, SPF_FAIL=0.001, T_DKIM_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ietf.org header.b=q3ptMel6; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ietf.org header.b=tLi5Dn+F 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 qKOkACwpQviW for ; Wed, 16 May 2018 06:01:05 -0700 (PDT) Received: from eu-smtp-delivery-152.mimecast.com (eu-smtp-delivery-152.mimecast.com [207.82.80.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 475A412D87E for ; Wed, 16 May 2018 06:01:05 -0700 (PDT) Received: from us.didata.com (mx1.us.didata.com [204.56.87.198]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-48-3VxSb4XjPOe8Wgr5NqKUCw-1; Wed, 16 May 2018 14:01:01 +0100 X-MC-Unique: 3VxSb4XjPOe8Wgr5NqKUCw-1 Received: from ([10.194.8.125]) by mx1.us.didata.com with ESMTP with TLS id 87TH0L1.34517924; Wed, 16 May 2018 09:00:54 -0400 Received: from Pickup by usispsvexcas05.na.didata.local with Microsoft SMTP Server id 14.3.389.1; Wed, 16 May 2018 12:43:58 +0000 X-MC-Unique: zBwnP_WgO3WeNFABwjnrWQ-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1526329435; bh=7ohLCzMxg30FLwYnmgxaXy+tV+1Fi7CG3XbleK3uYy0=; h=Subject:To:References:From:Date:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=q3ptMel6THYOwTna60TJjQkpdB8XLZwUOXCkz+bAPxskjCyH8Mz+D3PiV8V9Pr7xj Inf2phCa6deRwVbHlQrm8tsjwgJJe3xvYf/m761zOTNmCO7TjM6SvoZhIS9NbE8wUw MsUkXN7oWPUj1w35FaQ2PwNjjqOLySfaa8woipac= X-Mailbox-Line: From ietf-bounces@ietf.org Mon May 14 13:23:52 2018 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1526329413; bh=7ohLCzMxg30FLwYnmgxaXy+tV+1Fi7CG3XbleK3uYy0=; h=Subject:To:References:From:Date:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc; b=tLi5Dn+FiaGUF04hn/Qo/0JrfoN+h9Lbz/QATtDiRXjYl9/pf0wqyvNjevrcVo/M6 4ZtWKrScOKPTjK2rfmukj5UftFlSKubE+BWss4+e4FdoV+mWVml1+0XZwF/+bkkSFv fhWThmPsWrwyQhV87MYR8DYglcg3UjO2bFIn9N3U= X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com To: "Dale R. Worley" References: <87d0yc434c.fsf@hobgoblin.ariadne.com> From: Marc Petit-Huguenin Message-ID: <387eea8b-6f77-c94e-d67e-180ef17cd0f0@acm.org> Date: Mon, 14 May 2018 13:23:22 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <87d0yc434c.fsf@hobgoblin.ariadne.com> Archived-At: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.22 Precedence: list CC: , , , Errors-To: ietf-bounces@ietf.org Sender: ietf Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mZpx5RTOsvVcpHlTMom89lNGd724M9hye" Archived-At: Subject: Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16 X-BeenThere: tram@ietf.org 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, 16 May 2018 13:01:08 -0000 --mZpx5RTOsvVcpHlTMom89lNGd724M9hye Content-Type: multipart/mixed; boundary="4dFZmaKFGtrapLDf5fVxJSnJj26WOC818"; protected-headers="v1" From: Marc Petit-Huguenin To: "Dale R. Worley" Cc: gen-art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org Message-ID: <387eea8b-6f77-c94e-d67e-180ef17cd0f0@acm.org> Subject: Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16 References: <87d0yc434c.fsf@hobgoblin.ariadne.com> In-Reply-To: <87d0yc434c.fsf@hobgoblin.ariadne.com> --4dFZmaKFGtrapLDf5fVxJSnJj26WOC818 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Thank you. See inline. On 05/03/2018 06:32 PM, Dale R. Worley wrote: > Marc Petit-Huguenin writes: >> Because we believe that this is a problem that will become more and >> more frequent, we decided to fix it, at least for new implementations. >> >> Please have a look at -17 and let us know what you think of it. >=20 > It looks like you've handled the problem of a NAT that changes the > address family of the request as well as can be done. >=20 > You've clarified the question of how the security feature bits are > assigned, although I note that -16 and -17 assign the bits differently > than versions -7 through -15 do. >=20 > That completes all of the significant issues from my review of -16. >=20 > And there are some nits: >=20 > 6.2.1. Sending over UDP or DTLS-over-UDP >=20 > SHOULD be greater or equal than 500 ms. >=20 > s/equal than/equal to/. Applied. >=20 > 6.2.3. Sending over TLS-over-TCP or DTLS-over-UDP >=20 > To do that, it follows the > identification procedures defined in [RFC6125], with a certificate > containing an identifier of type DNS-ID or CN-ID, eventually with > wildcards, but not of type SRV-ID or URI-ID. >=20 > The meaning of "eventually" here is not clear. Rephrased as: [...] containing an identifier of type DNS-ID or CN-ID, eventually with a wildcard character as leftmost label, but not of type SRV-ID or URI- [...] >=20 > 14. STUN Attributes >=20 > The > padding bits MUST be set to zero on sending and must be ignored by > the receiver. >=20 > I assume the latter "must" is supposed to be "MUST". Fixed. >=20 > 14.13. UNKNOWN-ATTRIBUTES >=20 > Note: In [RFC3489], this field was padded to 32 by duplicating the > last attribute. In this version of the specification, thPetriNet > m --> PetriNet m --> e normal padding rules for attributes are > used instead. >=20 > I assume that "thPetriNet m --> PetriNet m --> e" is intended to be > "the". Fixed. >=20 > Appendix C. Release notes >=20 > Section C.8 has the same contents as section C.9, but section C.9 has > the same title as section C.10. (Although section C will be removed > before publication, so it's not important.) Fixed. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --4dFZmaKFGtrapLDf5fVxJSnJj26WOC818-- --mZpx5RTOsvVcpHlTMom89lNGd724M9hye Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlr58DsACgkQKcRFldZq fsSqMxAAprzXauCphrup86OVa5d13jG9iYiUIaNZETZ5itMXbg89jIH2km96kXkd IJiB9j6r+Pt76/f3hDJzCDPVUL/tWTDT9jT7ZLqcVcoPY0ieU56SLMqd2BpYx/43 SoVwMe1INAIzA+ut2b5SXrkva+0nAgbTFht8WKBaKR+0Urlb5Z5xX3eSb9zZyGyz +2j6n0fxfag6X05cwyO3j49WiQ/gab2f/YU7RrKLPDa7aN1p7cMGuUQQt27DrlFQ MzYw5HHadideeZwqyq6j5dkhcMdA65u3yo8OYKWSaGZmuD3hTRJ3jtcJIgRdTK5A GJq5xAsDZKScoZWgtSu2Sg4I0FdYKUZoL9u/J7xrRVplPtHOe9Bf//lBCkmE7DZk 0rkcG4yc1v4uGdmznAZibIJ4gpOzA/sfzQmRZ9nuv8G7NwlhrzrDdL0gV67uxc30 W2aDhnEHJcYAUy3Uo7MifBOauBcPYXNBQUpBV7Cwd8tk7tbIeU71rjPQFzp9eRe1 Q/PAHRxxAJ1ADUNGWVGouBfqco9y/PUI9A/L8zEJAl5mTZxutGl4M8DjcB72c1fD 4p8UXyNZsK/RDMS16HpkNsU1BQjh09X91i0XfE2MnfhkCpbXuM2nVDROGhCs+nHW tRQ0YL4XbNc9gvYhvYrt672JK66WPmA2xABHTl+qc7fa39yuDj4= =L8Hm -----END PGP SIGNATURE----- --mZpx5RTOsvVcpHlTMom89lNGd724M9hye-- From nobody Fri May 18 10:28:29 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 144A212D874 for ; Fri, 18 May 2018 10:28:27 -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 n9nZDsoFUTjv for ; Fri, 18 May 2018 10:28:22 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CCD1126BF3 for ; Fri, 18 May 2018 10:28:22 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id C47C41C00B7 for ; Fri, 18 May 2018 10:28:13 -0700 (PDT) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) by c8a.amsl.com (Postfix) with ESMTPSA id A27351C00B6 for ; Fri, 18 May 2018 10:28:13 -0700 (PDT) Received: by mail-io0-f169.google.com with SMTP id e20-v6so7069069iof.4 for ; Fri, 18 May 2018 10:28:22 -0700 (PDT) X-Gm-Message-State: ALKqPwdw9YT8Q5oO802GxW511lat3sagISFLgwP3T47nSsOnxRIf/0Jj cNJexz3T9oP+7ZKv6vVi6IIMdX9NagWkNUnkOXI= X-Google-Smtp-Source: AB8JxZrc+314DVkOhwmZ6HDE/i76CDw/nsww4/mksFy8EWmvcGQZBYFef4X4581RJbYWfJ8n7+lgZj2J0g/mFmU2k/k= X-Received: by 2002:a6b:30cd:: with SMTP id w196-v6mr10751423iow.183.1526664501787; Fri, 18 May 2018 10:28:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:1c49:0:0:0:0:0 with HTTP; Fri, 18 May 2018 10:28:01 -0700 (PDT) From: Glen Date: Fri, 18 May 2018 10:28:01 -0700 X-Gmail-Original-Message-ID: Message-ID: To: tram@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [tram] Some additional TRAM list messages coming through late X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 18 May 2018 17:28:27 -0000 Dear TRAM list participants - You are doubtless aware of yesterday's email outage. We got an inquiry about some email messages to this list which didn't even make it to the archives. There are several messages from yesterday which were held for "too many recipients". But because of the outage, the list owners didn't get the notification message about the held emails. For everyone's convenience, I am going to release those messages myself now. I just wanted to send this message so you all understood why you are suddenly going to get some list messages now, that were dated yesterday: They got stuck in list moderation. Thank you, Glen -- Glen Barney IT Director AMS (IETF Secretariat) From nobody Fri May 18 10:29:14 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 C47A412711D; Thu, 17 May 2018 13:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 imjUACC8ly7h; Thu, 17 May 2018 13:04:59 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 7300F1270B4; Thu, 17 May 2018 13:04:59 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w4HK2Fdu009040; Thu, 17 May 2018 21:04:46 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=AWGLwp3H4Jl5dKIcJTzejypfjSws2xFNdqp4Ptjwl+E=; b=UVrVOJgXmbXb9Eo4T5xnU5Zd60U3Ti+Xoc4eomf2TNpJKwaGm+3+MhCarpFCrdCgVWlL 8+JDWHF95+NrtN6NHeSj1RWpFbACkMjYYGG4pojxNsa4JU29fvzLlvYVE+r8WI9n5n/A gE5pEjuJLh/sJ1Z7dAH5jlB589eBrz7nrg8KLBIqPeOJ9CEwHkOXdiVuZdcJKwS9fzFM nGh16iZXaq7e9FYfvmDzOrG54qNRS3LBiffLaHsBFc0j5eXvykU8nsYkW4aWEj0PDhjW bhE+f2MePogSzyg/cl1PCBg1CD1PBvY0N5ZiUXxdmGTdogOvk8xQ6G2ETVag/4VA27ld Pg== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2j0fscdbu9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 May 2018 21:04:46 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w4HK1aRv023047; Thu, 17 May 2018 16:04:45 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2hwukxe2bd-1; Thu, 17 May 2018 16:04:45 -0400 Received: from [172.28.116.218] (bowill.kendall.corp.akamai.com [172.28.116.218]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 928DA20064; Thu, 17 May 2018 20:04:44 +0000 (GMT) To: Benjamin Kaduk , Marc Petit-Huguenin Cc: tram-chairs@ietf.org, Eric Rescorla , tram@ietf.org, Gonzalo Camarillo , tasveren@rbbn.com, The IESG , draft-ietf-tram-stunbis@ietf.org, "Matthew A. Miller" References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <31a441d2-8843-c8ee-f5ef-5496e5b4b364@acm.org> <29c18858-3694-c48a-54c3-6dcbfa3b6705@acm.org> <20180515182435.GN2249@kduck.kaduk.org> From: Brandon Williams Message-ID: <25e551de-87b7-1612-c869-8336fe3c4b95@akamai.com> Date: Thu, 17 May 2018 16:04:42 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180515182435.GN2249@kduck.kaduk.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-17_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805170185 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-17_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805170185 Archived-At: X-Mailman-Approved-At: Fri, 18 May 2018 10:29:12 -0700 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.22 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: Thu, 17 May 2018 20:05:03 -0000 I'll take a stab at describing the working group discussion, but please keep in mind that my recollection of this is faint ... it was a few years ago at this point. The working group started with a fundamental assumption that we should be moving away from MD5 for the purpose of key generation. I don't recall the WG having any detailed discussion of whether using MD5 here is a real security weakness in the protocol; had Ekr suggested at the mic that MD5 weakness might not actually be a problem we quite possibly would have chosen not to make any change to key derivation at all. So, working from the basic assumption that we should be moving away from MD5 for key derivation, it seemed only natural that we should be attempting to prevent an adversary from forcing downgrade back to MD5 via a bid-down attack as a way to weaken key derivation. After all, if preventing bid-down is not important then the same logic seems to suggest that moving away from MD5 at all is not important. I know that's not a very satisfying answer to the question of how we got here, but it represents my best recollection nonetheless. That having been said, I'm having trouble reconciling Ekr's "I don't see how a weakness in MD5 is relevant here" with Matt Miller's earlier comment "I am wondering why a more robust password algorithm (key derivation function) was not defined (e.g., HKDF-SHA-256)". Matt appears to suggest that we should go farther than we have while Ekr appears to suggest that we might not need to have gone even that far. Any suggestions about path to resolution on this? Am I just completely misinterpreting the comments we've received so far? --Brandon On 05/15/2018 02:24 PM, Benjamin Kaduk wrote: > I think I have the same understanding as Ekr, in which case the > bid-down concerns apply only to message integrity and not to > password-algorithm. > > So it would be good to hear from the WG on this issue. > > -Benjamin > > On Mon, May 14, 2018 at 01:06:00PM -0700, Marc Petit-Huguenin wrote: >> During the discussion about choosing password algorithms, someone came to the microphone (AFAIR) and said that it was subject to bid-down attack. We then design a solution to prevent that and that's what, after more discussions, we put in the draft. So I welcome any comment on the strength or weakness of the protection offered by the scheme we put in place and any suggestion to make it better, but as for the reasons it is there you will have to talk to the Working Group. >> >> Thanks. >> >> On 05/03/2018 04:45 PM, Eric Rescorla wrote: >>> No, I don't understand this at all. This section talks about a bid-down on >>> the PASSWORD-ALGORITHM, but I don't see how a weakness in MD5 is relevant >>> here. >>> >>> Assuming I understand correctly, the structure of the protocol is that >>> given a password, you do: >>> >>> key = Password-Algorithm(username, realm, password) >>> >>> And then use key with HMAC for an integrity check, where HMAC is SHA-1 >>> (with MESSAGE-INTEGRITY) or SHA-256 (with MESSAGE-INTEGRITY-SHA256). >>> However, in this case the MD5 isn't a security critical component at the >>> protocol layer [0], because it's just is just to act as a transformation of >>> the password into a fixed-length string for use as a key, so this doesn't >>> require collision resistance or pseudorandomness. I could be wrong here, >>> but if so, please describe a potential weakness in MD5 which could lead to >>> compromise of this protocol >>> >>> -Ekr >>> >>> [0] It might be an issue if someone were to recover the hashed password. >>> >>> On Thu, May 3, 2018 at 4:34 PM, Marc Petit-Huguenin >>> wrote: >>> >>>> On 04/22/2018 02:02 PM, Marc Petit-Huguenin wrote: >>>>> Hi Eric, >>>>> >>>>> Thanks for the review, please see my responses inline. >>>>> >>>>> On 04/16/2018 12:57 PM, Eric Rescorla wrote: >>>>>> Eric Rescorla has entered the following ballot position for >>>>>> draft-ietf-tram-stunbis-16: Discuss >>>>>> >>>>>> When responding, please keep the subject line intact and reply to all >>>>>> email addresses included in the To and CC lines. (Feel free to cut this >>>>>> introductory paragraph, however.) >>>>>> >>>>>> >>>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. >>>> html >>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>> >>>>>> >>>>>> The document, along with other ballot positions, can be found here: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ >>>>>> >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> DISCUSS: >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> Rich version of this review at: >>>>>> https://mozphab-ietf.devsvcdev.mozaws.net/D5132 >>>>>> >>>>>> >>>>>> Can you please indicate how you addressed the points Matt Miller >>>>>> raised in his secdir review about the use of MD5. >>>>> >>>>> From my response on 2018-03-11: >>>>> >>>>>> * The description for 17.5.1. "MD5" list the key size as 20 bytes, but >>>> the >>>>>> hash length of MD5 is 16 bytes (128 bits). I think this is merely a >>>> typo, >>>>>> since the purpose appears to be for backwards compatibility with >>>> existing >>>>>> systems. >>>>> >>>>> Fixed. >>>>> >>>>>> >>>>>> * Both 17.5.1.1. "MD5" Section 9.2.2. "HMAC Key" (long-term credential) >>>>>> and Section appear to define the same functional algorithm, but with >>>> subtle >>>>>> syntax differences. As far as I can tell, they are actually the same >>>>>> algorithm; would it not be acceptable to have Section 9.2.2 point to >>>>>> Section 17.5.1.1 for the algorithm description? >>>>>> >>>>>> >>>>> >>>>> This is going into the IANA registry so I left things there. I fixed >>>> the discrepancy with section 9.2.2. >>>>> >>>>> I also fixed the definition of the key for SHA-256, which must use >>>> OpaqueString for the realm. >>>>> >>>>>> >>>>>> >>>>>> >>>>>> DETAIL >>>>>>> by the agent sending the indication. It primarily serves to >>>>>>> correlate requests with responses, though it also plays a small >>>> role >>>>>>> in helping to prevent certain types of attacks. The server also >>>> uses >>>>>>> the transaction ID as a key to identify each transaction uniquely >>>>>>> across all clients. As such, the transaction ID MUST be uniformly >>>>>>> and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be >>>>>> >>>>>> I didn't realize this was a SHOULD. ICE depends on it as a security >>>>>> condition, so it probably needs to be a MUST. >>>>> >>>>> Done. >>>>> >>>>>> >>>>>> >>>>>>> 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. >>>>> >>>>>> >>>>>> >>>>>>> STUN Security Feature it is understood that the corresponding STUN >>>>>>> Security Feature bit in the "nonce cookie" is set to 1. >>>>>>> >>>>>>> For example, in Section 9.2.4 discussing the PASSWORD-ALGORITHMS >>>>>>> security feature, it is implied that the "Password algorithms" >>>> bit, >>>>>>> as defined in Section 17.1, is set to 1 in the "nonce cookie". >>>>>> >>>>>> I'm not sure I understand the bid down attack here or the proposed >>>>>> defense. Can you please walk through what the assumed attacker >>>>>> capabilities are, what the client and server capabilities are, how the >>>>>> bid down attack works, and how this protects against it? >>>>> >>>>> The plan is to add an annex to the document explaining that. I'll >>>> finish to process the other reviews from the IESG and then come back to >>>> that. >>>>> >>>> >>>> Instead of an annex, we added a new section in the Security >>>> Considerations. Please have a look at -17 and let us know if that >>>> explanation is good enough. >>>> >>>> Thanks. >>>> >>> >> >> >> >> -- >> Marc Petit-Huguenin >> Email: marc@petit-huguenin.org >> Blog: https://marc.petit-huguenin.org >> Profile: https://www.linkedin.com/in/petithug >> > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Chief Architect Cloud Networking; Akamai Technologies Inc. From nobody Fri May 18 10:29:21 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 AABFF12EB9B for ; Thu, 17 May 2018 13:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 dRQ8qUix-F85 for ; Thu, 17 May 2018 13:22:50 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 9DA0712EB96 for ; Thu, 17 May 2018 13:22:46 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id l1-v6so5197339oii.1 for ; Thu, 17 May 2018 13:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=udf0rIE+u8rFMfnDKUDqUVFXbGTTOs1NgJNQkvCTRBk=; b=VORVKLLJ68CqMG2pRboF+CUyUE55hhJBk5olq2V8OzGZ48rIQ1rRbcOGfvilNS3tEj s4n77xfOf63lvJ+NNtvBcuU2zIyz4kQBqtNoZFwWKgMagmYSnkFhucARYbx+UpwgbeKv /MYfy9kmTsRIBAfOL40W0G2TtO1hk8pEGpntaGJBvaMIhkTPpZ9q3rwwleeGc0mo0cEJ Vy8Kjttl5lwjYpbOUdr/2DRRWGp85KBcaqDmSdIidbs6TKS3e9IyIIajXQUpn/KsZVcb 2ScsCyz8GPaYqj8xzU/vpQLuy4GKvz8TMfewTFzwqOyzcfLtZFHtT9Fd8YDFY8I4WUni fl4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=udf0rIE+u8rFMfnDKUDqUVFXbGTTOs1NgJNQkvCTRBk=; b=BazfEwjzq1+p3mBua0yLra4nhpNWjlSZSSHF2dAQeROIpEzrZE+htKA477i1hM3Dcr NxUIrEh0ub53ffxzUACXbBY9AmNvTxnfnLCT5EbtD3WuQYwiLacQHr13vo8q3dZEVeWt AkwnxUoBCk8PFbJRO/CjIFaXLGvBzF+YoCkzBdTlUwGzYYjOWpr6fYVd5NdY9cVJ1ggC rqqC+TTsHl1w+/LxebFw78u34wr/GAsLHHZ7l2jFabcsKuDgR2YBYs/E9t6S/a86T+ZU leArzRyq6lASHzIN7ym7D0ZZ0hvwEtgToGvLmQH/Y8Hf2p6cmbW7RbEIsn6xamxz3VpS vIRA== X-Gm-Message-State: ALKqPwfpRKLncYeVPUfbmNht4cVu8U4nZcP88Qrr7hLYBq6dURWmCeym RLNvWJ3Uvl6gxVwSp+ULOOHKPuNViJlTuiXXwGnqsQ== X-Google-Smtp-Source: AB8JxZoVtcU+5V+yhfba88hb3pjMbwz/9xbmU3P9+uht8xuVdpb0KpNuFb5S2PHjTr/MMpphdA/zgnIptbnDJIYndXI= X-Received: by 2002:aca:c589:: with SMTP id v131-v6mr4306245oif.92.1526588565917; Thu, 17 May 2018 13:22:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Thu, 17 May 2018 13:22:04 -0700 (PDT) In-Reply-To: <25e551de-87b7-1612-c869-8336fe3c4b95@akamai.com> References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <31a441d2-8843-c8ee-f5ef-5496e5b4b364@acm.org> <29c18858-3694-c48a-54c3-6dcbfa3b6705@acm.org> <20180515182435.GN2249@kduck.kaduk.org> <25e551de-87b7-1612-c869-8336fe3c4b95@akamai.com> From: Eric Rescorla Date: Thu, 17 May 2018 13:22:04 -0700 Message-ID: To: Brandon Williams Cc: Benjamin Kaduk , Marc Petit-Huguenin , tram-chairs@ietf.org, tram@ietf.org, Gonzalo Camarillo , tasveren@rbbn.com, The IESG , draft-ietf-tram-stunbis@ietf.org, "Matthew A. Miller" Content-Type: multipart/alternative; boundary="00000000000030a932056c6c99a0" Archived-At: X-Mailman-Approved-At: Fri, 18 May 2018 10:29:12 -0700 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.22 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: Thu, 17 May 2018 20:22:54 -0000 --00000000000030a932056c6c99a0 Content-Type: text/plain; charset="UTF-8" On Thu, May 17, 2018 at 1:04 PM, Brandon Williams < brandon.williams@akamai.com> wrote: > I'll take a stab at describing the working group discussion, but please > keep in mind that my recollection of this is faint ... it was a few years > ago at this point. > > The working group started with a fundamental assumption that we should be > moving away from MD5 for the purpose of key generation. I don't recall the > WG having any detailed discussion of whether using MD5 here is a real > security weakness in the protocol; had Ekr suggested at the mic that MD5 > weakness might not actually be a problem we quite possibly would have > chosen not to make any change to key derivation at all. > Sure. I don't remember being in the room for this. > So, working from the basic assumption that we should be moving away from > MD5 for key derivation, it seemed only natural that we should be attempting > to prevent an adversary from forcing downgrade back to MD5 via a bid-down > attack as a way to weaken key derivation. After all, if preventing bid-down > is not important then the same logic seems to suggest that moving away from > MD5 at all is not important. > > I know that's not a very satisfying answer to the question of how we got > here, but it represents my best recollection nonetheless. > > That having been said, I'm having trouble reconciling Ekr's "I don't see > how a weakness in MD5 is relevant here" with Matt Miller's earlier comment > "I am wondering why a more robust password algorithm (key derivation > function) was not defined (e.g., HKDF-SHA-256)". Matt appears to suggest > that we should go farther than we have while Ekr appears to suggest that we > might not need to have gone even that far. > > Any suggestions about path to resolution on this? Am I just completely > misinterpreting the comments we've received so far? > Well, I don't know what Matt is thinking. Perhaps he would like to weigh in? -Ekr > --Brandon > > > On 05/15/2018 02:24 PM, Benjamin Kaduk wrote: > >> I think I have the same understanding as Ekr, in which case the >> bid-down concerns apply only to message integrity and not to >> password-algorithm. >> >> So it would be good to hear from the WG on this issue. >> >> -Benjamin >> >> On Mon, May 14, 2018 at 01:06:00PM -0700, Marc Petit-Huguenin wrote: >> >>> During the discussion about choosing password algorithms, someone came >>> to the microphone (AFAIR) and said that it was subject to bid-down attack. >>> We then design a solution to prevent that and that's what, after more >>> discussions, we put in the draft. So I welcome any comment on the strength >>> or weakness of the protection offered by the scheme we put in place and any >>> suggestion to make it better, but as for the reasons it is there you will >>> have to talk to the Working Group. >>> >>> Thanks. >>> >>> On 05/03/2018 04:45 PM, Eric Rescorla wrote: >>> >>>> No, I don't understand this at all. This section talks about a bid-down >>>> on >>>> the PASSWORD-ALGORITHM, but I don't see how a weakness in MD5 is >>>> relevant >>>> here. >>>> >>>> Assuming I understand correctly, the structure of the protocol is that >>>> given a password, you do: >>>> >>>> key = Password-Algorithm(username, realm, password) >>>> >>>> And then use key with HMAC for an integrity check, where HMAC is SHA-1 >>>> (with MESSAGE-INTEGRITY) or SHA-256 (with MESSAGE-INTEGRITY-SHA256). >>>> However, in this case the MD5 isn't a security critical component at the >>>> protocol layer [0], because it's just is just to act as a >>>> transformation of >>>> the password into a fixed-length string for use as a key, so this >>>> doesn't >>>> require collision resistance or pseudorandomness. I could be wrong here, >>>> but if so, please describe a potential weakness in MD5 which could lead >>>> to >>>> compromise of this protocol >>>> >>>> -Ekr >>>> >>>> [0] It might be an issue if someone were to recover the hashed password. >>>> >>>> On Thu, May 3, 2018 at 4:34 PM, Marc Petit-Huguenin >>>> wrote: >>>> >>>> On 04/22/2018 02:02 PM, Marc Petit-Huguenin wrote: >>>>> >>>>>> Hi Eric, >>>>>> >>>>>> Thanks for the review, please see my responses inline. >>>>>> >>>>>> On 04/16/2018 12:57 PM, Eric Rescorla wrote: >>>>>> >>>>>>> Eric Rescorla has entered the following ballot position for >>>>>>> draft-ietf-tram-stunbis-16: Discuss >>>>>>> >>>>>>> When responding, please keep the subject line intact and reply to all >>>>>>> email addresses included in the To and CC lines. (Feel free to cut >>>>>>> this >>>>>>> introductory paragraph, however.) >>>>>>> >>>>>>> >>>>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria >>>>>>> . >>>>>>> >>>>>> html >>>>> >>>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>>> >>>>>>> >>>>>>> The document, along with other ballot positions, can be found here: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------ >>>>>>> ---------- >>>>>>> DISCUSS: >>>>>>> ------------------------------------------------------------ >>>>>>> ---------- >>>>>>> >>>>>>> Rich version of this review at: >>>>>>> https://mozphab-ietf.devsvcdev.mozaws.net/D5132 >>>>>>> >>>>>>> >>>>>>> Can you please indicate how you addressed the points Matt Miller >>>>>>> raised in his secdir review about the use of MD5. >>>>>>> >>>>>> >>>>>> From my response on 2018-03-11: >>>>>> >>>>>> * The description for 17.5.1. "MD5" list the key size as 20 bytes, but >>>>>>> >>>>>> the >>>>> >>>>>> hash length of MD5 is 16 bytes (128 bits). I think this is merely a >>>>>>> >>>>>> typo, >>>>> >>>>>> since the purpose appears to be for backwards compatibility with >>>>>>> >>>>>> existing >>>>> >>>>>> systems. >>>>>>> >>>>>> >>>>>> Fixed. >>>>>> >>>>>> >>>>>>> * Both 17.5.1.1. "MD5" Section 9.2.2. "HMAC Key" (long-term >>>>>>> credential) >>>>>>> and Section appear to define the same functional algorithm, but with >>>>>>> >>>>>> subtle >>>>> >>>>>> syntax differences. As far as I can tell, they are actually the same >>>>>>> algorithm; would it not be acceptable to have Section 9.2.2 point to >>>>>>> Section 17.5.1.1 for the algorithm description? >>>>>>> >>>>>>> >>>>>>> >>>>>> This is going into the IANA registry so I left things there. I fixed >>>>>> >>>>> the discrepancy with section 9.2.2. >>>>> >>>>>> >>>>>> I also fixed the definition of the key for SHA-256, which must use >>>>>> >>>>> OpaqueString for the realm. >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> DETAIL >>>>>>> >>>>>>>> by the agent sending the indication. It primarily serves to >>>>>>>> correlate requests with responses, though it also plays a >>>>>>>> small >>>>>>>> >>>>>>> role >>>>> >>>>>> in helping to prevent certain types of attacks. The server also >>>>>>>> >>>>>>> uses >>>>> >>>>>> the transaction ID as a key to identify each transaction >>>>>>>> uniquely >>>>>>>> across all clients. As such, the transaction ID MUST be >>>>>>>> uniformly >>>>>>>> and randomly chosen from the interval 0 .. 2**96-1, and >>>>>>>> SHOULD be >>>>>>>> >>>>>>> >>>>>>> I didn't realize this was a SHOULD. ICE depends on it as a security >>>>>>> condition, so it probably needs to be a MUST. >>>>>>> >>>>>> >>>>>> Done. >>>>>> >>>>>> >>>>>>> >>>>>>> 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. >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> STUN Security Feature it is understood that the corresponding >>>>>>>> STUN >>>>>>>> Security Feature bit in the "nonce cookie" is set to 1. >>>>>>>> >>>>>>>> For example, in Section 9.2.4 discussing the >>>>>>>> PASSWORD-ALGORITHMS >>>>>>>> security feature, it is implied that the "Password algorithms" >>>>>>>> >>>>>>> bit, >>>>> >>>>>> as defined in Section 17.1, is set to 1 in the "nonce cookie". >>>>>>>> >>>>>>> >>>>>>> I'm not sure I understand the bid down attack here or the proposed >>>>>>> defense. Can you please walk through what the assumed attacker >>>>>>> capabilities are, what the client and server capabilities are, how >>>>>>> the >>>>>>> bid down attack works, and how this protects against it? >>>>>>> >>>>>> >>>>>> The plan is to add an annex to the document explaining that. I'll >>>>>> >>>>> finish to process the other reviews from the IESG and then come back to >>>>> that. >>>>> >>>>>> >>>>>> >>>>> Instead of an annex, we added a new section in the Security >>>>> Considerations. Please have a look at -17 and let us know if that >>>>> explanation is good enough. >>>>> >>>>> Thanks. >>>>> >>>>> >>>> >>> >>> >>> -- >>> Marc Petit-Huguenin >>> Email: marc@petit-huguenin.org >>> Blog: https://marc.petit-huguenin.org >>> Profile: https://www.linkedin.com/in/petithug >>> >>> >> >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> > -- > Brandon Williams; Chief Architect > Cloud Networking; Akamai Technologies Inc. > --00000000000030a932056c6c99a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, May 17, 2018 at 1:04 PM, Brandon Williams <= ;brandon.w= illiams@akamai.com> wrote:
= I'll take a stab at describing the working group discussion, but please= keep in mind that my recollection of this is faint ... it was a few years = ago at this point.

The working group started with a fundamental assumption that we should be m= oving away from MD5 for the purpose of key generation. I don't recall t= he WG having any detailed discussion of whether using MD5 here is a real se= curity weakness in the protocol; had Ekr suggested at the mic that MD5 weak= ness might not actually be a problem we quite possibly would have chosen no= t to make any change to key derivation at all.

Sure. I don't remember being in the room for this.
=C2=A0
So, working from the basic assumption that we should be moving away from MD= 5 for key derivation, it seemed only natural that we should be attempting t= o prevent an adversary from forcing downgrade back to MD5 via a bid-down at= tack as a way to weaken key derivation. After all, if preventing bid-down i= s not important then the same logic seems to suggest that moving away from = MD5 at all is not important.

I know that's not a very satisfying answer to the question of how we go= t here, but it represents my best recollection nonetheless.

That having been said, I'm having trouble reconciling Ekr's "I= don't see how a weakness in MD5 is relevant here" with Matt Mille= r's earlier comment "I am wondering why a more robust password alg= orithm (key derivation function) was not defined (e.g., HKDF-SHA-256)"= . Matt appears to suggest that we should go farther than we have while Ekr = appears to suggest that we might not need to have gone even that far.

Any suggestions about path to resolution on this? Am I just completely misi= nterpreting the comments we've received so far?
Well, I don't know what Matt is thinking. Perhaps he would= like to weigh in?

-Ekr


--Brandon


On 05/15/2018 02:24 PM, Benjamin Kaduk wrote:
I think I have the same understanding as Ekr, in which case the
bid-down concerns apply only to message integrity and not to
password-algorithm.

So it would be good to hear from the WG on this issue.

-Benjamin

On Mon, May 14, 2018 at 01:06:00PM -0700, Marc Petit-Huguenin wrote:
During the discussion about choosing password algorithms, someone came to t= he microphone (AFAIR) and said that it was subject to bid-down attack.=C2= =A0 We then design a solution to prevent that and that's what, after mo= re discussions, we put in the draft.=C2=A0 So I welcome any comment on the = strength or weakness of the protection offered by the scheme we put in plac= e and any suggestion to make it better, but as for the reasons it is there = you will have to talk to the Working Group.

Thanks.

On 05/03/2018 04:45 PM, Eric Rescorla wrote:
No, I don't understand this at all. This section talks about a bid-down= on
the PASSWORD-ALGORITHM, but I don't see how a weakness in MD5 is releva= nt
here.

Assuming I understand correctly, the structure of the protocol is that
given a password, you do:

=C2=A0 =C2=A0 key =3D Password-Algorithm(username, realm, password)

And then use key with HMAC for an integrity check, where HMAC is SHA-1
(with MESSAGE-INTEGRITY) or SHA-256 (with MESSAGE-INTEGRITY-SHA256).
However, in this case the MD5 isn't a security critical component at th= e
protocol layer [0], because it's just is just to act as a transformatio= n of
the password into a fixed-length string for use as a key, so this doesn'= ;t
require collision resistance or pseudorandomness. I could be wrong here, but if so, please describe a potential weakness in MD5 which could lead to<= br> compromise of this protocol

-Ekr

[0] It might be an issue if someone were to recover the hashed password.
On Thu, May 3, 2018 at 4:34 PM, Marc Petit-Huguenin <petithug@acm.org>
wrote:

On 04/22/2018 02:02 PM, Marc Petit-Huguenin wrote:
Hi Eric,

Thanks for the review, please see my responses inline.

On 04/16/2018 12:57 PM, Eric Rescorla wrote:
Eric Rescorla has entered the following ballot position for
draft-ietf-tram-stunbis-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.
html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/dra= ft-ietf-tram-stunbis/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5132<= /a>


Can you please indicate how you addressed the points Matt Miller
raised in his secdir review about the use of MD5.

=C2=A0From my response on 2018-03-11:

* The description for 17.5.1. "MD5" list the key size as 20 bytes= , but
the
hash length of MD5 is 16 bytes (128 bits).=C2=A0 I think this is merely a
typo,
since the purpose appears to be for backwards compatibility with
existing
systems.

Fixed.


* Both 17.5.1.1. "MD5" Section 9.2.2. "HMAC Key" (long-= term credential)
and Section appear to define the same functional algorithm, but with
subtle
syntax differences.=C2=A0 As far as I can tell, they are actually the same<= br> algorithm; would it not be acceptable to have Section 9.2.2 point to
Section 17.5.1.1 for the algorithm description?



This is going into the IANA registry so I left things there.=C2=A0 I fixed<= br>
the discrepancy with section 9.2.2.

I also fixed the definition of the key for SHA-256, which must use
OpaqueString for the realm.




DETAIL
=C2=A0 =C2=A0 =C2=A0 by the agent sending the indication.=C2=A0 It primaril= y serves to
=C2=A0 =C2=A0 =C2=A0 correlate requests with responses, though it also play= s a small
role
=C2=A0 =C2=A0 =C2=A0 in helping to prevent certain types of attacks.=C2=A0 = The server also
uses
=C2=A0 =C2=A0 =C2=A0 the transaction ID as a key to identify each transacti= on uniquely
=C2=A0 =C2=A0 =C2=A0 across all clients.=C2=A0 As such, the transaction ID = MUST be uniformly
=C2=A0 =C2=A0 =C2=A0 and randomly chosen from the interval 0 .. 2**96-1, an= d SHOULD be

I didn't realize this was a SHOULD. ICE depends on it as a security
condition, so it probably needs to be a MUST.

Done.



=C2=A0 =C2=A0 =C2=A0 For a request or indication message, the agent MUST in= clude the
=C2=A0 =C2=A0 =C2=A0 USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGR= ITY
attributes
=C2=A0 =C2=A0 =C2=A0 in the message unless the agent knows from an external= indication
=C2=A0 =C2=A0 =C2=A0 which message integrity algorithm is supported by both= agents.=C2=A0 In
=C2=A0 =C2=A0 =C2=A0 this case either MESSAGE-INTEGRITY or MESSAGE-INTEGRIT= Y-SHA256
MUST
=C2=A0 =C2=A0 =C2=A0 be included in addition to USERNAME.=C2=A0 The HMAC fo= r 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.



=C2=A0 =C2=A0 =C2=A0 STUN Security Feature it is understood that the corres= ponding STUN
=C2=A0 =C2=A0 =C2=A0 Security Feature bit in the "nonce cookie" i= s set to 1.

=C2=A0 =C2=A0 =C2=A0 For example, in Section 9.2.4 discussing the PASSWORD-= ALGORITHMS
=C2=A0 =C2=A0 =C2=A0 security feature, it is implied that the "Passwor= d algorithms"
bit,
=C2=A0 =C2=A0 =C2=A0 as defined in Section 17.1, is set to 1 in the "n= once cookie".

I'm not sure I understand the bid down attack here or the proposed
defense.=C2=A0 Can you please walk through what the assumed attacker
capabilities are, what the client and server capabilities are, how the
bid down attack works, and how this protects against it?

The plan is to add an annex to the document explaining that.=C2=A0 I'll=
finish to process the other reviews from the IESG and then come back to
that.


Instead of an annex, we added a new section in the Security
Considerations.=C2=A0 Please have a look at -17 and let us know if that
explanation is good enough.

Thanks.





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





_______________________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram


--
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.

--00000000000030a932056c6c99a0-- From nobody Fri May 18 10:29:27 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 67857127275; Thu, 17 May 2018 13:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 6SbfBuTP6DBY; Thu, 17 May 2018 13:33:53 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 9BF971241FC; Thu, 17 May 2018 13:33:52 -0700 (PDT) X-AuditID: 1209190e-28dff700000050b3-98-5afde72e1b37 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 88.EC.20659.F27EDFA5; Thu, 17 May 2018 16:33:51 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w4HKXiLE002602; Thu, 17 May 2018 16:33:46 -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 w4HKXbca008984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 May 2018 16:33:40 -0400 Date: Thu, 17 May 2018 15:33:37 -0500 From: Benjamin Kaduk To: Eric Rescorla Cc: Brandon Williams , Marc Petit-Huguenin , tram-chairs@ietf.org, tram@ietf.org, Gonzalo Camarillo , tasveren@rbbn.com, The IESG , draft-ietf-tram-stunbis@ietf.org, "Matthew A. Miller" Message-ID: <20180517203337.GN2249@kduck.kaduk.org> References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <31a441d2-8843-c8ee-f5ef-5496e5b4b364@acm.org> <29c18858-3694-c48a-54c3-6dcbfa3b6705@acm.org> <20180515182435.GN2249@kduck.kaduk.org> <25e551de-87b7-1612-c869-8336fe3c4b95@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLKsWRmVeSWpSXmKPExsUixG6nrqv//G+UwZRL8hbLHu9ktejccpnN YsXrc+wWm5avZLKY8Wcis8WkLY9YLS6suctksX75N3aL5T9Xsll8WHuBzYHL4/IVb4/JRxYw e/z6epXNY8mSn0weTz7/Y/LYM2cSo8fkx23MAexRXDYpqTmZZalF+nYJXBktdxczF3zjruie +YCtgfE0ZxcjJ4eEgInEzDmvGbsYuTiEBBYzSVzbeZwZwtnIKPFhbytU5iqTxKp9p9lBWlgE VCXeH5jBBGKzCahINHRfZgaxRQQUJH79OcEC0sAs8IxJYvvRHrAGYYF0iduvrrOC2LwCxhI9 K9pYIaaeZZaYsGERM0RCUOLkzCcsIDazgJbEjX8vgTZwANnSEsv/cYCEOQUCJXatPgw2R1RA WWJv3yH2CYwCs5B0z0LSPQuhewEj8ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdY73czBK91JTS TYygWOGU5NvBOKnB+xCjAAejEg+vw5S/UUKsiWXFlbmHGCU5mJREefv+/Y4S4kvKT6nMSCzO iC8qzUktPsQowcGsJMLrVwlUzpuSWFmVWpQPk5LmYFES5xXY/CFKSCA9sSQ1OzW1ILUIJivD waEkwXvnKVCjYFFqempFWmZOCUKaiYMTZDgP0PCrIDW8xQWJucWZ6RD5U4yKUuK8Cc+AEgIg iYzSPLheUCqTyN5f84pRHOgVYd5gkCoeYBqE634FNJgJaDDjgd8gg0sSEVJSDYyeT3z1+bk2 fnh57oHV8m+2px0WG6bN+vvGwfm6juzymGm35locMiyJrBO3Cd0WaGN/vWTj0/dbhO719ZSl blsut+cfY8yL6btnvi0/l1356CVjptfZ/dFtG5bOTLeQ2P9b3ndSxiuuQK6bmlPaLkw7wFV4 fTaXW9ar8P8aejOqNfVkTf2q+TKUWIozEg21mIuKEwGOEeOvQAMAAA== Archived-At: X-Mailman-Approved-At: Fri, 18 May 2018 10:29:12 -0700 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.22 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: Thu, 17 May 2018 20:33:55 -0000 On Thu, May 17, 2018 at 01:22:04PM -0700, Eric Rescorla wrote: > On Thu, May 17, 2018 at 1:04 PM, Brandon Williams < > brandon.williams@akamai.com> wrote: > > > > > That having been said, I'm having trouble reconciling Ekr's "I don't see > > how a weakness in MD5 is relevant here" with Matt Miller's earlier comment > > "I am wondering why a more robust password algorithm (key derivation > > function) was not defined (e.g., HKDF-SHA-256)". Matt appears to suggest > > that we should go farther than we have while Ekr appears to suggest that we > > might not need to have gone even that far. > > > > Any suggestions about path to resolution on this? Am I just completely > > misinterpreting the comments we've received so far? > > > > Well, I don't know what Matt is thinking. Perhaps he would like to weigh in? I think this is a question of "attack over the network" vs. "compromised password database". You want HKDF-SHA-256 or Argon2 or something like that because it makes it harder for an attacker to brute-force a compromised database of hashed passwords, which is something of a different concern than turning a string into a crypto key and worrying about an attacker in the network that only observes the ciphertext. That is, the problem of brute-forcing the secret material given the network ciphertext is different from attacking the (hashed) password database directly. So it seems possible that both points are relevant, just protecting against different things. -Benjamin From nobody Fri May 18 10:29:35 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 889AA1270B4 for ; Thu, 17 May 2018 13:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Q9asxw2_kjQi for ; Thu, 17 May 2018 13:51:13 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 E84F21272E1 for ; Thu, 17 May 2018 13:51:12 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id y15-v6so5227998oia.13 for ; Thu, 17 May 2018 13:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PQCt45zAqOUnkxZfBiVGBwDVX6te3T+z6dKzG1Bc/OI=; b=zxTSe1tgPxmU+HJJ8fHcV+nQvx/F68D68bN09cP/XbnwIVChm0uMcdfImQY0V96g04 7JtMW0tIIciW/Z9n8s0ec77GwuLEq/W26TwT2hW0O8D9zp0Dy6c2dDX7sGZHo+chOLkc ivxWdWVvjpHMdvhaH4f/A9LLfMrL3RY6oMXnJ5tai7qZzI0TadGjK/IYLDlyCUvqgHp2 kc7JuKqryuhnxHPoCWKOQMTNyp6mn0tlh+WFmfNdXNxTYjR1w9J1wCeSW15FyD6JPjet yrI+mrZgXtI0IxV+XY/ukwsBiHYBmDJ2rOChMzx82syDKVGXfNq6bwCL3NpYSZ3EcSZI 4BlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PQCt45zAqOUnkxZfBiVGBwDVX6te3T+z6dKzG1Bc/OI=; b=r5IEfwYqm5Sw/yIRceHp+tSo9HQ7pUB+WleY4pTL5OK4dV9XKm5t/RVrPmFnuTXf6D QddjVUSwfc05dxMsoXriVRz3clP6SNp5AgDm5j/TOqxWez+W4H7pIiAdXTMPM5HAwX7O TaOGyiBjojtZrAIucc76Y9ze/ROHHBNWzoexAb9hMqBaN7MD5t+a9TvyLt83V8k8fQWa Eas77RCMGtWXkHoOqFWIF02PhwAOLwAASEZabWZ4IkLzaVOhFtLz1Qv3jOPXtiT7FuAP HseMeSnHty1G8bMt3FZIsc8XSNt0txKi4XgnmsLtZ2vs18duBxlMil9LMWclgyG12Ds7 49iA== X-Gm-Message-State: ALKqPwfTbfzIwM2+ZDl9AxilyECHAxdFIqzWcy/ohm0vKWsrhTpM59LF 3Z/BtjZUEWwxrj39M0nMN6MSe7eH4HP595DX563/Cw== X-Google-Smtp-Source: AB8JxZquue2RY3TqatG13z7GxXSJDq++H8LmVjFJGX7UiruoJ/i7XnjmV3dKsuF9ZGWu710mMrbRlZQl5SdXGy38/0Y= X-Received: by 2002:aca:4c11:: with SMTP id z17-v6mr4276096oia.174.1526590272172; Thu, 17 May 2018 13:51:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.118.130 with HTTP; Thu, 17 May 2018 13:50:31 -0700 (PDT) In-Reply-To: <20180517203337.GN2249@kduck.kaduk.org> References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <31a441d2-8843-c8ee-f5ef-5496e5b4b364@acm.org> <29c18858-3694-c48a-54c3-6dcbfa3b6705@acm.org> <20180515182435.GN2249@kduck.kaduk.org> <25e551de-87b7-1612-c869-8336fe3c4b95@akamai.com> <20180517203337.GN2249@kduck.kaduk.org> From: Eric Rescorla Date: Thu, 17 May 2018 13:50:31 -0700 Message-ID: To: Benjamin Kaduk Cc: Brandon Williams , Marc Petit-Huguenin , tram-chairs@ietf.org, tram@ietf.org, Gonzalo Camarillo , tasveren@rbbn.com, The IESG , draft-ietf-tram-stunbis@ietf.org, "Matthew A. Miller" Content-Type: multipart/alternative; boundary="000000000000e40b35056c6cfeeb" Archived-At: X-Mailman-Approved-At: Fri, 18 May 2018 10:29:12 -0700 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.22 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: Thu, 17 May 2018 20:51:16 -0000 --000000000000e40b35056c6cfeeb Content-Type: text/plain; charset="UTF-8" On Thu, May 17, 2018 at 1:33 PM, Benjamin Kaduk wrote: > On Thu, May 17, 2018 at 01:22:04PM -0700, Eric Rescorla wrote: > > On Thu, May 17, 2018 at 1:04 PM, Brandon Williams < > > brandon.williams@akamai.com> wrote: > > > > > > > > That having been said, I'm having trouble reconciling Ekr's "I don't > see > > > how a weakness in MD5 is relevant here" with Matt Miller's earlier > comment > > > "I am wondering why a more robust password algorithm (key derivation > > > function) was not defined (e.g., HKDF-SHA-256)". Matt appears to > suggest > > > that we should go farther than we have while Ekr appears to suggest > that we > > > might not need to have gone even that far. > > > > > > Any suggestions about path to resolution on this? Am I just completely > > > misinterpreting the comments we've received so far? > > > > > > > Well, I don't know what Matt is thinking. Perhaps he would like to weigh > in? > > I think this is a question of "attack over the network" vs. > "compromised password database". You want HKDF-SHA-256 or Argon2 or > something like that because it makes it harder for an attacker to > brute-force a compromised database of hashed passwords, which is > something of a different concern than turning a string into a crypto > key and worrying about an attacker in the network that only observes > the ciphertext. That is, the problem of brute-forcing the secret material > given the network ciphertext is different from attacking the > (hashed) password database directly. > Right. But the weak password hashing function is a problem if you have the data on disk, whether you negotiate it or not, so biddown protection doesn't help. -Ekr So it seems possible that both points are relevant, just protecting > against different things. > > -Benjamin > --000000000000e40b35056c6cfeeb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, May 17, 2018 at 1:33 PM, Benjamin Kaduk <<= a href=3D"mailto:kaduk@mit.edu" target=3D"_blank">kaduk@mit.edu> wrote:
On Thu, May 1= 7, 2018 at 01:22:04PM -0700, Eric Rescorla wrote:
> On Thu, May 17, 2018 at 1:04 PM, Brandon Williams <
> brandon.williams@akamai= .com> wrote:
>
> >
> > That having been said, I'm having tro= uble reconciling Ekr's "I don't see
> > how a weakness in MD5 is relevant here" with Matt Miller'= ;s earlier comment
> > "I am wondering why a more robust password algorithm (key de= rivation
> > function) was not defined (e.g., HKDF-SHA-256)". Matt appear= s to suggest
> > that we should go farther than we have while Ekr appears to sugge= st that we
> > might not need to have gone even that far.
> >
> > Any suggestions about path to resolution on this? Am I just compl= etely
> > misinterpreting the comments we've received so far?
> >
>
> Well, I don't know what Matt is thinking. Perhaps he would like to= weigh in?

I think this is a question of "attack over the network" vs= .
"compromised password database".=C2=A0 You want HKDF-SHA-256 or A= rgon2 or
something like that because it makes it harder for an attacker to
brute-force a compromised database of hashed passwords, which is
something of a different concern than turning a string into a crypto
key and worrying about an attacker in the network that only observes
the ciphertext.=C2=A0 That is, the problem of brute-forcing the secret mate= rial
given the network ciphertext is different from attacking the
(hashed) password database directly.

Ri= ght. But the weak password hashing function is a problem if you have
<= div>the data on disk, whether you negotiate it or not, so biddown protectio= n
doesn't help.

-Ekr
<= br>
So it seems possible that both points are relevant, just protecting
against different things.

-Benjamin

--000000000000e40b35056c6cfeeb-- From nobody Fri May 18 10:29:52 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 4DCDD1270B4; Thu, 17 May 2018 13:55:31 -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 jYdM4OA3JJxK; Thu, 17 May 2018 13:55:29 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 799A91241FC; Thu, 17 May 2018 13:55:29 -0700 (PDT) X-AuditID: 1209190c-9ebff70000005454-76-5afdec3fc741 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-1.mit.edu (Symantec Messaging Gateway) with SMTP id 8F.1F.21588.04CEDFA5; Thu, 17 May 2018 16:55:28 -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 w4HKtL6s031313; Thu, 17 May 2018 16:55:23 -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 w4HKtFLr015690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 May 2018 16:55:18 -0400 Date: Thu, 17 May 2018 15:55:16 -0500 From: Benjamin Kaduk To: Eric Rescorla Cc: Brandon Williams , Marc Petit-Huguenin , tram-chairs@ietf.org, tram@ietf.org, Gonzalo Camarillo , tasveren@rbbn.com, The IESG , draft-ietf-tram-stunbis@ietf.org, "Matthew A. Miller" Message-ID: <20180517205516.GO2249@kduck.kaduk.org> References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <31a441d2-8843-c8ee-f5ef-5496e5b4b364@acm.org> <29c18858-3694-c48a-54c3-6dcbfa3b6705@acm.org> <20180515182435.GN2249@kduck.kaduk.org> <25e551de-87b7-1612-c869-8336fe3c4b95@akamai.com> <20180517203337.GN2249@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLKsWRmVeSWpSXmKPExsUixG6nouvw5m+UwcxJkhbLHu9ktejccpnN YsXrc+wWm5avZLKY8Wcis8WkLY9YLS6suctksX75N3aL5T9Xsll8WHuBzYHL4/IVb4/JRxYw e/z6epXNY8mSn0weTz7/Y/LYM2cSo8fkx23MAexRXDYpqTmZZalF+nYJXBnHlzxjLfjNUbF2 /wGWBsYJ7F2MnBwSAiYSiy/sYOpi5OIQEljMJLFr8zEWCGcjo0TTpYlQzlUmicYJq5hAWlgE VCUedf1mBbHZBFQkGrovM4PYIgIKEr/+nABrYBZ4xiSx/WgP2A5hgXSJ26+ugzXwChhLdN49 zAgxdR+LxOtNM1kgEoISJ2c+AbOZBbQkbvx7CbSNA8iWllj+jwMkzCkQKLHg8jSwI0QFlCX2 9h1in8AoMAtJ9ywk3bMQuhcwMq9ilE3JrdLNTczMKU5N1i1OTszLSy3SNdTLzSzRS00p3cQI ihVOSZ4djGfeeB1iFOBgVOLhfTHxb5QQa2JZcWXuIUZJDiYlUd6+f7+jhPiS8lMqMxKLM+KL SnNSiw8xSnAwK4nw+lUClfOmJFZWpRblw6SkOViUxHkFNn+IEhJITyxJzU5NLUgtgsnKcHAo SfAKvgZqFCxKTU+tSMvMKUFIM3FwggznARpeBVLDW1yQmFucmQ6RP8WoKCXOKwuSEABJZJTm wfWCUplE9v6aV4ziQK8I87qAVPEA0yBc9yugwUxAgxkP/AYZXJKIkJJqYDyj82TlX1aFN6kB KTIbJtSf6rUMvMM48ZqhyAlW9iVuGpF2650uJzW9/+DxUK1mxuxONqXIg5eUF8b/nz+fM0Fy SpuzqlSQmnvoneMLuU4eTdBTeiLixWbgrSWhuDf7Uvwq5eD9t0/945/D2c0kYJX/SbAnjk9i WfXfYs6NBkr7trnVX570X4mlOCPRUIu5qDgRABqgkE9AAwAA Archived-At: X-Mailman-Approved-At: Fri, 18 May 2018 10:29:12 -0700 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.22 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: Thu, 17 May 2018 20:55:32 -0000 On Thu, May 17, 2018 at 01:50:31PM -0700, Eric Rescorla wrote: > On Thu, May 17, 2018 at 1:33 PM, Benjamin Kaduk wrote: > > > > > I think this is a question of "attack over the network" vs. > > "compromised password database". You want HKDF-SHA-256 or Argon2 or > > something like that because it makes it harder for an attacker to > > brute-force a compromised database of hashed passwords, which is > > something of a different concern than turning a string into a crypto > > key and worrying about an attacker in the network that only observes > > the ciphertext. That is, the problem of brute-forcing the secret material > > given the network ciphertext is different from attacking the > > (hashed) password database directly. > > > > Right. But the weak password hashing function is a problem if you have > the data on disk, whether you negotiate it or not, so biddown protection > doesn't help. Right. So maybe we need a way to signal that the MD5-hashed thing can be removed from the on-disk database. (Well, "need".) The first occurrence of non-md5 might not be enough, though... -Benjamin From nobody Fri May 18 10:29: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 8B4E312D886 for ; Thu, 17 May 2018 15:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.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 en0409fsoFoS for ; Thu, 17 May 2018 15:17:47 -0700 (PDT) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (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 167F312EBA5 for ; Thu, 17 May 2018 15:17:47 -0700 (PDT) Received: by mail-ot0-x231.google.com with SMTP id l22-v6so6885858otj.0 for ; Thu, 17 May 2018 15:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:cc:references:from:openpgp:autocrypt:message-id :date:user-agent:mime-version:in-reply-to; bh=ltOc9ClUN36iLw7FYNAcXJK4NUbwqL+8bPFeKFefqE4=; b=W/gQGjXOLIckG01ZSb0xdtXVFnmLGoJDIrwRPZbDcyowLYmhfFTtNG0BuigWiSIL1y vZ4XP5UdlD9BIMqspRWJQbsWck0ZvJwS2O4pG7tZ5A9hoTvXR8A5u8eer4P2S379MPol xvyrzna35rfYkE9F4IA0wLO6sUOVkccEVpH07+Aab6bpk5YQj/3lZ9v+BQwHInhiCDtT nPvZ3n5rwi4tBxXGuuQ6Nub7u3P4xgUw0WlbklJGcYR9JEWqws00KUle2foZn5VT2+gm zQocxGuXP+evkPU/atzXXbApfH/O15a7N8pwrHuCC+VN9+QPs5i4UR580C4Eq/CZ9MvQ 5zyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:openpgp :autocrypt:message-id:date:user-agent:mime-version:in-reply-to; bh=ltOc9ClUN36iLw7FYNAcXJK4NUbwqL+8bPFeKFefqE4=; b=YcIiNA74tYEGmYkSx0xax8j3mlQbHDfEkbjjHxC/yxFlCvJvYRau2Lri6cqG2/YDZk 2LEE61xqoi4HfeUQSMMCymKpS7o/edTk8hnXHVX/ud7tCUbxVJ2aAc2BrcX3+rVl9szl o2qHUkJF9g3ieHM6Y+yTzFZPcUHWrMyYIFEy+tE7FIyrHpY+j2GKlSFU82I8pPi27h4+ xJahtt3Y4TUumpseKPEzSDPHREFKkm07oH1z3LS1xVjZaEfANMOUn1WYW66cgbMrzcue eKhT4qiLrax4jP6JzuR6D77b6pIk2zAm1FYHvwstr03UFN9ZeVCzOXky0/2V5K2hgQC6 kTjQ== X-Gm-Message-State: ALKqPwdFQqmoCaHG5ob1d1b+cRttS01NZ1YGfZAYJaVOZsoWbtfjtkmz XdbVW6ysATSwT5YB4R5hFHZxIA== X-Google-Smtp-Source: AB8JxZrQ211SxVipIIVosvynIIHPJEdbGg/4Y86tW1WbH4eitVIPs2kVZ6QeXkwkBo6YqmHba2hMHQ== X-Received: by 2002:a9d:e28:: with SMTP id c37-v6mr5234999otc.251.1526595466306; Thu, 17 May 2018 15:17:46 -0700 (PDT) Received: from [10.6.21.160] ([128.177.113.102]) by smtp.gmail.com with ESMTPSA id r48-v6sm5691074otb.51.2018.05.17.15.17.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 May 2018 15:17:45 -0700 (PDT) Sender: Matthew Miller To: Benjamin Kaduk , Eric Rescorla Cc: Brandon Williams , Marc Petit-Huguenin , 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> <31a441d2-8843-c8ee-f5ef-5496e5b4b364@acm.org> <29c18858-3694-c48a-54c3-6dcbfa3b6705@acm.org> <20180515182435.GN2249@kduck.kaduk.org> <25e551de-87b7-1612-c869-8336fe3c4b95@akamai.com> <20180517203337.GN2249@kduck.kaduk.org> From: "Matthew A. Miller" Openpgp: preference=signencrypt Autocrypt: addr=linuxwolf+ietf@outer-planes.net; prefer-encrypt=mutual; keydata= xsBNBFJoAooBCADQmEtpbpY/4wTeKgZIuyG7HkxIFgiUeqOvtiBKj/pCA73d7Q5hCvQdGcKJ 6uZsYz3Il9oKoKFxVt90iEXspbE39g6ek19e6RsB4j0Q10l4QvH+EqeD760gs0H2yf/eYj9i uk9/VY6axdQlPsmid1zoQgCNjSM7X4/K26WGMs03sbXJpKdoonelzIlJSNfzi0q546iplo72 D2cCm9BriMkQvcGnsm4B9eBIBn3GKmVx1tsmPNeNTyun2DvaLnrYxbA0Ivo1DzZReds9NZ25 uROI/+b+lcg9/kmHzhK+q8NMQCFWmqpS/lZRKxVBSijKGpGr5h8VLVf5iURHtwG+B/QxABEB AAHNLk1hdHRoZXcgQS4gTWlsbGVyIDxsaW51eHdvbGZAb3V0ZXItcGxhbmVzLm5ldD7CwIAE EwEKACoCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AFCQvHJDEFAlirCeQCGQEACgkQ7PRy ThCeBbt+sAgAzUQokr+f+ArieIrv2JkiQLqiBaZX29Aph9YwG3OPLWSdESEKkFOSJT0LWbsC cAKHLrVfgl2+6iPhf4OOacTdqK7wS6vruPZC1ChdO7NZTgbVa0hP/Q/QKEoaMGNdfc1/lgxY 5kwh+bvGIF1+HyadytgCBBHxdVEhYI7G3ejKqA8iVwri1VW0Wjp8iWdjpF74swIHhid5GcAu 6VJgVNJw3P+WkTkNrkd2tx5yUfNXQuGyFhxwlpiuaOpIk3p74P6e8h/riMpkJ5mIH/ryGTH7 qxpEIuep2bLQZmGwBen8kf3MO/VbiA/NMY6OHdc93EBKr0g7n2BA5uFLdy79FqAA3M7ATQRS aAKKAQgAwP67h8GJUO6XYyWOrcJGXDJnnZEDS+q+bTQXkJMFa74rVIx0yioqY8QdpBJFGaMT 4DCNYe/3pw61ZTDDKqukSCfOh/ssdd8zSGTQZSX5lR4B4+00/LKWugP6iHHHYiETbBVb5bxc aR/LE41Wx3z2HsW3TkeZB6WVk82MTclS1zCuY3p9AeCvr424BSQL7KC38y2eQc95G+nabsVD c6oQ8oZOf1D2giBb2VgbYkSppKj8BKvBtmjCauWeEq/AkZKaDAdua8Qj0vEfgcoh8aavlPJi rqj1YNSyc3AO4R5prPGgTepcUpW8ip8xIPAFoJXfuvsZSV7uVP36gwApU4+ZnwARAQABwsB8 BBgBCgAmAhsMFiEEMddYjeyQaQ1rzJjg7PRyThCeBbsFAlpvpIsFCQvLWoEACgkQ7PRyThCe BbuNHAf/cchJ7kHoIr5i+jgVRuR71AGlxlMbVolnS5tza3bi9Ie63LRdOtMUE3pDUQo25cWd cP7pzwwRBCDD2GxfIuyMCWaES0xtQdTIyNOAFFOtBtCFOrsNEk+iLAu6GBr4QzSQKW1QW4/b vcfpM2pLQn7Zd6naUioEYfTHCMmYHr7hQXaPNEQ7V/J4pLVAN8bHyVgQ9ciQN91DUs6jnueM BUW7DNvuHq0RDzA+ufYdpQAjwl4z1v+rnJ79P3HTxfFdiTTAk9MjyVQklHxS067cmLYkSOku dnCOHhDmSFwkKd9EwOBNuztpjCzmM5SgOT+U/iHH+IM/Hv6bjVCiAQ5WOihe6Q== Message-ID: <6710a82f-3857-7b06-c253-73674d65d323@outer-planes.net> Date: Thu, 17 May 2018 16:17:44 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180517203337.GN2249@kduck.kaduk.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x0fDX7NgQQW9TD5HqhA72mtky1fUzH1zz" Archived-At: X-Mailman-Approved-At: Fri, 18 May 2018 10:29:12 -0700 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.22 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: Thu, 17 May 2018 22:17:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --x0fDX7NgQQW9TD5HqhA72mtky1fUzH1zz Content-Type: multipart/mixed; boundary="KNxKAXkf3B2JWd6IJ24oloVypH6wBZ4Ci"; protected-headers="v1" From: "Matthew A. Miller" To: Benjamin Kaduk , Eric Rescorla Cc: Brandon Williams , Marc Petit-Huguenin , tram-chairs@ietf.org, tram@ietf.org, Gonzalo Camarillo , tasveren@rbbn.com, The IESG , draft-ietf-tram-stunbis@ietf.org Message-ID: <6710a82f-3857-7b06-c253-73674d65d323@outer-planes.net> 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> <31a441d2-8843-c8ee-f5ef-5496e5b4b364@acm.org> <29c18858-3694-c48a-54c3-6dcbfa3b6705@acm.org> <20180515182435.GN2249@kduck.kaduk.org> <25e551de-87b7-1612-c869-8336fe3c4b95@akamai.com> <20180517203337.GN2249@kduck.kaduk.org> In-Reply-To: <20180517203337.GN2249@kduck.kaduk.org> --KNxKAXkf3B2JWd6IJ24oloVypH6wBZ4Ci Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 18/05/17 14:33, Benjamin Kaduk wrote: > On Thu, May 17, 2018 at 01:22:04PM -0700, Eric Rescorla wrote: >> On Thu, May 17, 2018 at 1:04 PM, Brandon Williams < >> brandon.williams@akamai.com> wrote: >> >>> >>> That having been said, I'm having trouble reconciling Ekr's "I don't = see >>> how a weakness in MD5 is relevant here" with Matt Miller's earlier co= mment >>> "I am wondering why a more robust password algorithm (key derivation >>> function) was not defined (e.g., HKDF-SHA-256)". Matt appears to sugg= est >>> that we should go farther than we have while Ekr appears to suggest t= hat we >>> might not need to have gone even that far. >>> >>> Any suggestions about path to resolution on this? Am I just completel= y >>> misinterpreting the comments we've received so far? >>> >> >> Well, I don't know what Matt is thinking. Perhaps he would like to wei= gh in? >=20 > I think this is a question of "attack over the network" vs. > "compromised password database". You want HKDF-SHA-256 or Argon2 or > something like that because it makes it harder for an attacker to > brute-force a compromised database of hashed passwords, which is > something of a different concern than turning a string into a crypto > key and worrying about an attacker in the network that only observes > the ciphertext. That is, the problem of brute-forcing the secret mater= ial > given the network ciphertext is different from attacking the > (hashed) password database directly. >=20 > So it seems possible that both points are relevant, just protecting > against different things. >=20 My initial thoughts were along the lines of "compromised database", which admittedly data-at-rest is at the top of my mind most of the time. The key derivations in this document are ok for how they are used. I thought I'd backed away from that robustness point in the email discussion that ensued from the review, as it sounded like a concern that was out of scope for this work. If offline attacks are in-scope then something that makes brute force take some real work (at _a minimum_ PBKDF2 with 10k+ iterations, or better yet use scrypt or argon2). If it's out-of-scope, then this needs to be called out in the security considerations. Otherwise, I think a valid concern to implementers is that MD5 is getting removed from or turned-off in various base libraries and module. Moving away from it helps implementations avoid having to rely on older (and potentially vulnerable/exploitable) base libraries just to keep an algorithm around seems very worthwhile. - m&m Matthew A. Miller --KNxKAXkf3B2JWd6IJ24oloVypH6wBZ4Ci-- --x0fDX7NgQQW9TD5HqhA72mtky1fUzH1zz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEMddYjeyQaQ1rzJjg7PRyThCeBbsFAlr9/4gACgkQ7PRyThCe BbssAAf9GzcDHEV3UJzbUyCFxELvwGd6idQi2pSmRDo9+ti70SkZ8F7KJj2GOBca QeJbW1JXoBP+osxnYsd91WQB6OZkliBB2rVmPu2Vty++4bZz0q+SPsyu2WU7x8ri c0rJgOAijkUl1p3HJAL9QGdbQ5wTaVJkb2zL/sc/HQeUd+NEfpbHbYvQdY8mECWH GS7w8/UkmFJ7ugaatbBn+2JJB6weHfV5wDE9Gxk68URriU9U7bcSuojDj+JbHEuf H0vj+Q6T+2A4TjCwZPTrWzPiix65rR7dlIO8lLLNtOV77NPvYf29TvJ18dLY3Sux HqRkGay1n+RWqbgA6HWEDHFWgIoehQ== =busC -----END PGP SIGNATURE----- --x0fDX7NgQQW9TD5HqhA72mtky1fUzH1zz-- From nobody Fri May 18 10:30:00 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 0DBCD12D7F8; Fri, 18 May 2018 06:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 afJNnwz3geZ4; Fri, 18 May 2018 06:44:02 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 50D5112D95C; Fri, 18 May 2018 06:44:02 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4IDg5sg016096; Fri, 18 May 2018 14:43:50 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=Bn9VZHV1a99LAlUVRSkEvNe8mSO0t+32phAP+GsEQl8=; b=mANjeCM/1yCrvfVuiGxK2D/5+aBv9qo95hvUNblbNOzobWXAmtTcpSXyBxpbAbtJ3xpu 2ggAYRCYAKzd+dchPlJgwx6wsGZV66nnQzM9ZFyvV1Do5WtwikW61kAmFRgrzsnf20h/ tbxoSZjfMjmdo30E7SVEbYGb5S6xx2thysIq5QsxEo4cpxT9S1Q9OFjLtGWpmnYoZrki mAjcZiumMVG5PeeESDSsP1rq0rHChhxX0LR/rfHSdKvdRQhVXJI4jFnbZ4hg8VwYR2YB PQcvWmhvA+auBcCtMXGuTzjNbxLBGuRaYwBRhM5s0Vhnnzdmp22X2Oh00nnTW1hbkDpB TA== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0a-00190b01.pphosted.com with ESMTP id 2j04570mrx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 May 2018 14:43:49 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w4IDa5N0023765; Fri, 18 May 2018 09:43:48 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2hwukws8wb-1; Fri, 18 May 2018 09:43:48 -0400 Received: from [172.28.116.218] (bowill.kendall.corp.akamai.com [172.28.116.218]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id D70D220067; Fri, 18 May 2018 13:43:47 +0000 (GMT) To: "Matthew A. Miller" , Benjamin Kaduk , Eric Rescorla Cc: Marc Petit-Huguenin , 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> <31a441d2-8843-c8ee-f5ef-5496e5b4b364@acm.org> <29c18858-3694-c48a-54c3-6dcbfa3b6705@acm.org> <20180515182435.GN2249@kduck.kaduk.org> <25e551de-87b7-1612-c869-8336fe3c4b95@akamai.com> <20180517203337.GN2249@kduck.kaduk.org> <6710a82f-3857-7b06-c253-73674d65d323@outer-planes.net> From: Brandon Williams Message-ID: Date: Fri, 18 May 2018 09:43:44 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <6710a82f-3857-7b06-c253-73674d65d323@outer-planes.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-18_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805180149 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-18_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805180150 Archived-At: X-Mailman-Approved-At: Fri, 18 May 2018 10:29:12 -0700 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.22 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, 18 May 2018 13:44:04 -0000 OK, so based on this, it seems that the WG was right about the desire to move away from MD5 but unclear about the reason. If the goal is to mitigate against keeping weak hashes in a local database on the server, the doc should be clear that this is risk and explain how bid-down helps achieve the goal. Depending upon the internal implementation on the server, bid-down protection could be important as part of a model to help the server avoid caching weak precomputed password hashes to insecure local storage I suppose. For example, if the server computes the hash using the negotiated algorithm and then writes the hash to a local cache to avoid having to calculate it again, it would be good to avoid generating weak hashes that could be leaked from a compromised server. Of course, this is only really meaningful if the server has strong protections around the the username/password database that's required to generate the hash values in the first place. Does this seem like it would be going in the right direction? --Brandon On 05/17/2018 06:17 PM, Matthew A. Miller wrote: > On 18/05/17 14:33, Benjamin Kaduk wrote: >> On Thu, May 17, 2018 at 01:22:04PM -0700, Eric Rescorla wrote: >>> On Thu, May 17, 2018 at 1:04 PM, Brandon Williams < >>> brandon.williams@akamai.com> wrote: >>> >>>> >>>> That having been said, I'm having trouble reconciling Ekr's "I don't see >>>> how a weakness in MD5 is relevant here" with Matt Miller's earlier comment >>>> "I am wondering why a more robust password algorithm (key derivation >>>> function) was not defined (e.g., HKDF-SHA-256)". Matt appears to suggest >>>> that we should go farther than we have while Ekr appears to suggest that we >>>> might not need to have gone even that far. >>>> >>>> Any suggestions about path to resolution on this? Am I just completely >>>> misinterpreting the comments we've received so far? >>>> >>> >>> Well, I don't know what Matt is thinking. Perhaps he would like to weigh in? >> >> I think this is a question of "attack over the network" vs. >> "compromised password database". You want HKDF-SHA-256 or Argon2 or >> something like that because it makes it harder for an attacker to >> brute-force a compromised database of hashed passwords, which is >> something of a different concern than turning a string into a crypto >> key and worrying about an attacker in the network that only observes >> the ciphertext. That is, the problem of brute-forcing the secret material >> given the network ciphertext is different from attacking the >> (hashed) password database directly. >> >> So it seems possible that both points are relevant, just protecting >> against different things. >> > > My initial thoughts were along the lines of "compromised database", > which admittedly data-at-rest is at the top of my mind most of the time. > The key derivations in this document are ok for how they are used. > > I thought I'd backed away from that robustness point in the email > discussion that ensued from the review, as it sounded like a concern > that was out of scope for this work. If offline attacks are in-scope > then something that makes brute force take some real work (at _a > minimum_ PBKDF2 with 10k+ iterations, or better yet use scrypt or > argon2). If it's out-of-scope, then this needs to be called out in the > security considerations. > > Otherwise, I think a valid concern to implementers is that MD5 is > getting removed from or turned-off in various base libraries and module. > Moving away from it helps implementations avoid having to rely on older > (and potentially vulnerable/exploitable) base libraries just to keep an > algorithm around seems very worthwhile. > > > > - m&m > > Matthew A. Miller > From nobody Sat May 19 00:47:39 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 DE8FB12E86D; Fri, 18 May 2018 15:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 dIqQHvag_yF6; Fri, 18 May 2018 15:11:33 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 EE1EC12E86A; Fri, 18 May 2018 15:11:32 -0700 (PDT) X-AuditID: 1209190e-781ff70000005d92-94-5aff4f9109a2 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 59.44.23954.29F4FFA5; Fri, 18 May 2018 18:11:30 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w4IMBPpH019819; Fri, 18 May 2018 18:11:26 -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 w4IMBJs3017119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 18 May 2018 18:11:21 -0400 Date: Fri, 18 May 2018 17:11:19 -0500 From: Benjamin Kaduk To: Brandon Williams Cc: "Matthew A. Miller" , Eric Rescorla , Marc Petit-Huguenin , tram-chairs@ietf.org, tram@ietf.org, Gonzalo Camarillo , tasveren@rbbn.com, The IESG , draft-ietf-tram-stunbis@ietf.org Message-ID: <20180518221119.GB2249@kduck.kaduk.org> References: <31a441d2-8843-c8ee-f5ef-5496e5b4b364@acm.org> <29c18858-3694-c48a-54c3-6dcbfa3b6705@acm.org> <20180515182435.GN2249@kduck.kaduk.org> <25e551de-87b7-1612-c869-8336fe3c4b95@akamai.com> <20180517203337.GN2249@kduck.kaduk.org> <6710a82f-3857-7b06-c253-73674d65d323@outer-planes.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsUixG6nrjvJ/3+UwaQJZhbLHu9ktejccpnN YsXrc+wWm5avZLKY8Wcis8WkLY9YLS6suctksX75N3aL5T9Xsll8WHuBzYHL4/IVb4/JRxYw e/z6epXNY8mSn0weTz7/Y/LYM2cSo8fkx23MAexRXDYpqTmZZalF+nYJXBmzW7awFyzmrOi9 mtDAuJy9i5GDQ0LAROJyj1kXIxeHkMBiJokTmx+yQjgbGSVOz7vEAuFcZZLoPLQLKMPJwSKg KnHnWRsLiM0moCLR0H2ZGcQWETCS+LaogxGkgVngNJPEn3m97CAJYYF0iduvrrOCrOMVMJbY t00FYugCFokDex4ygtTwCghKnJz5BGwos4CWxI1/L5lA6pkFpCWW/+MACXMK2Ens/XgCrFxU QFlib98h9gmMArOQdM9C0j0LoXsBI/MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXWO93MwSvdSU 0k2MoCjhlOTbwTipwfsQowAHoxIP74k3/6KEWBPLiitzDzFKcjApifJyWf2PEuJLyk+pzEgs zogvKs1JLT7EKMHBrCTCm2kBlONNSaysSi3Kh0lJc7AoifMKbP4QJSSQnliSmp2aWpBaBJOV 4eBQkuA94wfUKFiUmp5akZaZU4KQZuLgBBnOAzRcGKSGt7ggMbc4Mx0if4pRUUqcVwokIQCS yCjNg+sFJTGJ7P01rxjFgV4R5p0PUsUDTIBw3a+ABjMBDWY88BtkcEkiQkqqgfGY6PSn3zd1 ydToaz/S6QxR0D3L07Lu2s9Og/a/K3PcrpwJe7Znn8uHbOOV0doaP7mvseczWYaymbIvzHse 3WMkfft6t1rd/nDmH+4+JuriBgs2zbzfciRAWerYLj++tu1XutateXBtiXuB1r5rSkVqTVGd n6f//1Vn7iRb/zsu98WXrU7HlZVYijMSDbWYi4oTAX+Wa5Y9AwAA Archived-At: X-Mailman-Approved-At: Sat, 19 May 2018 00:47:37 -0700 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.22 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, 18 May 2018 22:11:35 -0000 On Fri, May 18, 2018 at 09:43:44AM -0400, Brandon Williams wrote: > OK, so based on this, it seems that the WG was right about the desire to > move away from MD5 but unclear about the reason. If the goal is to > mitigate against keeping weak hashes in a local database on the server, > the doc should be clear that this is risk and explain how bid-down helps > achieve the goal. > > Depending upon the internal implementation on the server, bid-down > protection could be important as part of a model to help the server > avoid caching weak precomputed password hashes to insecure local storage > I suppose. For example, if the server computes the hash using the > negotiated algorithm and then writes the hash to a local cache to avoid > having to calculate it again, it would be good to avoid generating weak > hashes that could be leaked from a compromised server. Of course, this > is only really meaningful if the server has strong protections around > the the username/password database that's required to generate the hash > values in the first place. > > Does this seem like it would be going in the right direction? I think so. -Benjamin From nobody Mon May 21 11:11:40 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 22D5712E8C6; Mon, 21 May 2018 11:11:38 -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 Ggd5mfCy_IWe; Mon, 21 May 2018 11:11:36 -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 2603312D7EF; Mon, 21 May 2018 11:11:36 -0700 (PDT) Received: from Svantevit.local (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 w4LIBWa4055327 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 21 May 2018 13:11:34 -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.local To: Marc Petit-Huguenin , 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: Adam Roach Message-ID: Date: Mon, 21 May 2018 13:11:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1e8cd5de-06de-6745-fc4d-d15fcdd0b4d9@petit-huguenin.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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.22 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, 21 May 2018 18:11:38 -0000 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: >> >>> --------------------------------------------------------------------------- >>> >>> §17.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-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. >>> --------------------------------------------------------------------------- >>> >>> §6.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 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 §8.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 §6.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 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 From nobody Tue May 29 03:18:35 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 52EA4129C6E for ; Tue, 29 May 2018 03:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 C17Vts4cylvD for ; Tue, 29 May 2018 03:18:31 -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 9AB7112D7E2 for ; Tue, 29 May 2018 03:18:31 -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=1527589114; 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-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-Office365-Filtering-Correlation-Id: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=y CEX6v9Vw9mTyEa8/nlnozlkHOro5W3qtVjulJD4nL o=; b=cCR/VFVmtWO6i7PiAj3hVX4Uh8hrK/pLvWJ48zuROHq0 76Quq8sJTSP6YVbo0vjJQ+8HoB+cI4uYRXZQ0ysOJKXxgtshsO wOdRq2p9Taxfs2+PNBCLohWTMMOozIYbTB81cp/qJKoX3hv5pb 696KefIbIfReJXN8OduW63sHOXs= Received: from DNVEXAPP1N05.corpzone.internalzone.com (DNVEXAPP1N05.corpzone.internalzone.com [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 4a35_7bd5_b6f822aa_1d17_45b2_8c07_147b219289cd; Tue, 29 May 2018 05:18:34 -0500 Received: from DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 29 May 2018 04:17:53 -0600 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 29 May 2018 04:17:52 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 29 May 2018 04:17:52 -0600 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 29 May 2018 04:17:51 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1538.namprd16.prod.outlook.com (10.172.208.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.797.11; Tue, 29 May 2018 10:17:49 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::601e:a909:b9fe:31bd]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::601e:a909:b9fe:31bd%8]) with mapi id 15.20.0797.018; Tue, 29 May 2018 10:17:49 +0000 From: "Konda, Tirumaleswar Reddy" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-17.txt Thread-Index: AQHT2w5k5Ye43UtxsU6plD0Ba+ptDKQOZzcQgCErlgCAFyJkAA== Date: Tue, 29 May 2018 10:17:49 +0000 Message-ID: References: <152449325211.21886.16366690442756908271@ietfa.amsl.com> <347de982-54c5-4156-e406-0aa13ed4446c@akamai.com> In-Reply-To: <347de982-54c5-4156-e406-0aa13ed4446c@akamai.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.300.84 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; BN6PR16MB1538; 7:hXtS+NJwlBy3QZRN2hoaWKT/QOAjEqQMczeSG9RxYuLWsxmTEk/9A1uvubPhx4AlfBSPTMjfDYbCbNo6GdD87LztA9/240sv+lRTszutrZD+B1NoQVK/ylscK5YSFb4ThugbW9YKUxVP3Cc/eySIYGgPYWz4TMik0oLVcfqIs0ck+QqLAMlrIuxQrG3PUj3xhazFmX6liw6JKQ1RVrc4P3yX26ZQGpQa1am/hM7bVeADBWylEozR5RvGy6oLfllB x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1538; x-ms-traffictypediagnostic: BN6PR16MB1538: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(192374486261705)(123452027830198); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:BN6PR16MB1538; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1538; x-forefront-prvs: 0687389FB0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(376002)(346002)(39380400002)(39860400002)(199004)(189003)(32952001)(377424004)(15404003)(13464003)(8676002)(7736002)(5250100002)(5890100001)(99286004)(2501003)(316002)(6306002)(66066001)(5660300001)(305945005)(110136005)(9686003)(8936002)(3280700002)(3660700001)(74316002)(81156014)(81166006)(53936002)(11346002)(72206003)(966005)(446003)(478600001)(6246003)(6436002)(2906002)(86362001)(486006)(55016002)(14454004)(33656002)(7696005)(476003)(68736007)(2900100001)(6116002)(3846002)(76176011)(229853002)(26005)(102836004)(80792005)(186003)(97736004)(25786009)(106356001)(53546011)(105586002)(59450400001)(6506007)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1538; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: mczwkyyiMzsnB+dMr3yD4yHUtFXQjMwz8pZJMpVIvbEqYJOfu5J7iHE+4UEvoyhF5GJLAOhSsEdhC0EIU/duVlLAMzwOQCyR5uOYtjtU0KACsnWhqS3zhI8XEgrOWbcA9Gk7r7IyBkLRoN6QOCH04ifqvL77yK84zPiHoiyoobvWm7hpEdy23wWoZ+nQLaQwiVbl7FlDPy5UgSlxEU51OA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 9344a662-ebb3-4bca-8fa0-08d5c54d6e53 X-MS-Exchange-CrossTenant-Network-Message-Id: 9344a662-ebb3-4bca-8fa0-08d5c54d6e53 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2018 10:17:49.5354 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1538 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 <6295> : inlines <6663> : streams <1788130> : uri <2649091> Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-17.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 29 May 2018 10:18:34 -0000 VGhhbmtzIEJyYW5kb24gZm9yIHRoZSByZXZpZXcuIFVwZGF0ZWQgZHJhZnQgdG8gaW5jb3Jwb3Jh dGUgdGhlIHByb3Bvc2VkIGNoYW5nZXMuDQoNCkNoZWVycywNCi1UaXJ1DQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQnJhbmRvbiBXaWxsaWFtcyBbbWFpbHRvOmJyYW5k b24ud2lsbGlhbXNAYWthbWFpLmNvbV0NCj4gU2VudDogTW9uZGF5LCBNYXkgMTQsIDIwMTggMTA6 MjYgUE0NCj4gVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5 X0tvbmRhQE1jQWZlZS5jb20+Ow0KPiB0cmFtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdHJh bV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMTcudHh0DQo+IA0KPiBUaGlz IGVtYWlsIG9yaWdpbmF0ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24uIERvIG5v dCBjbGljayBsaW5rcyBvcg0KPiBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXpl IHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCj4gDQo+IEhpIFRpcnUs DQo+IA0KPiBJJ3ZlIGdvdCBhIGZldyBlZGl0b3JpYWwgc3VnZ2VzdGlvbnMgb24gdGhlIG5ldyBj b250ZW50IHJlOg0KPiBwZXJtaXNzaW9ubGVzcyBTVFVOIHJlbGF5LiBBcyB0aGVzZSBhcmUgYWxs IGVkaXRvcmlhbCwgeW91IGNhbiBvZiBjb3Vyc2UgZmVlbA0KPiBmcmVlIHRvIGlnbm9yZSBhbnkv YWxsIG9mIHRoZW0uIFRoZXkgYXJlIHNpbXBseSBoaWdobGlnaHRpbmcgc29tZSBwbGFjZXMgd2hl cmUNCj4gSSBoYWQgc29tZSB0cm91YmxlIHBhcnNpbmcgdGhlIHRleHQgYW5kIGRvIG5vdCByZXBy ZXNlbnQgc3Vic3RhbnRpdmUgY2hhbmdlcyB0bw0KPiB0aGUgcHJvcG9zZWQgY29udGVudC4NCj4g DQo+IFBsZWFzZSBsZXQgbWUga25vdyBpZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zIGFib3V0IHRo ZSBmb2xsb3dpbmcuDQo+IA0KPiAtLUJyYW5kb24NCj4gDQo+IFNlY3Rpb24gMi4zLiBQZXJtaXNz aW9ucw0KPiANCj4gKiAiLi4uIHRoZSBVRFAgZGF0YWdyYW0gaXMgc2lsZW50bHkgZGlzY2FyZGVk LiBIb3dldmVyLCBhIFRVUk4gc2VydmVyIGNhbiBiZQ0KPiBjb25maWd1cmVkIHRvIHBlcm1pdCAu Li4iDQo+IA0KPiBUaGUgdXNlIG9mICJIb3dldmVyIiBoZXJlIGltcGxpZXMgYSBtb3JlIHNpZ25p ZmljYW50IGRlcGFydHVyZSBmcm9tIHRoZQ0KPiBwcmVjZWRpbmcgc2VudGVuY2UgdGhhbiB5b3Ug aW50ZW5kLiBJIHN1Z2dlc3QgZHJvcHBpbmcgaXQuICIuLi4gdGhlIFVEUA0KPiBkYXRhZ3JhbSBp cyBzaWxlbnRseSBkaXNjYXJkZWQuIEEgVFVSTiBzZXJ2ZXIgY2FuIGJlIGNvbmZpZ3VyZWQgdG8g cGVybWl0IC4uLiINCj4gDQo+ICogIi4uLiBzcGVlZHMgdXAgU1RVTiBjb25uZWN0aXZpdHkgY2hl Y2tzLCB3aGlsZSB0aGUgY2xpZW50IGNyZWF0ZXMgcGVybWlzc2lvbnMNCj4gaW4gdGhlIFRVUk4g c2VydmVyIGZvciB0aGUgcmVtb3RlIHBlZXIgSVAgYWRkcmVzc2VzLCB0aGUgcmVtb3RlIHBlZXIg Y2FuDQo+IGluaXRpYXRlIGNvbm5lY3Rpdml0eSBjaGVja3MgdG8gdGhlIGNsaWVudC4iDQo+IA0K PiBUaGUgdXNlIG9mICJ3aGlsZSIgYWZ0ZXIgdGhlIGNvbW1hIG1ha2VzIGl0IHNlZW0gbGlrZSBh IGRpZmZlcmVudCB1c2Ugb2YgdGhlDQo+IHdvcmQgdGhhbiB5b3UgaW50ZW5kLiBJIHN1Z2dlc3Qg Ii4uLiBzcGVlZHMgdXAgU1RVTiBjb25uZWN0aXZpdHkgY2hlY2tzLA0KPiBhbGxvd2luZyB0aGUg cmVtb3RlIHBlZXIgdG8gaW5pdGlhdGUgY29ubmVjdGl2aXR5IGNoZWNrcyB0byB0aGUgY2xpZW50 IHdoaWxlIHRoZQ0KPiBjbGllbnQgaXMgY3JlYXRpbmcgcGVybWlzc2lvbnMgaW4gdGhlIFRVUk4g c2VydmVyIGZvciB0aGUgcmVtb3RlIHBlZXIgSVANCj4gYWRkcmVzc2VzLiINCj4gDQo+IFNlY3Rp b24gOS4gUGVybWlzc2lvbnMNCj4gDQo+ICogIi4uLiBkbyBub3QgbWF0Y2ggdGhlIHBlcm1pc3Np b25zIGluc3RhbGxlZCwgdGhpcyBjb25maWd1cmF0aW9uIGtub2IgTVVTVCAuLi4iDQo+IA0KPiBU aGUgIiwiIG1ha2VzIHRoaXMgc2VudGVuY2Ugc2VlbSBsaWtlIGEgcnVuLW9uLiBJIHN1Z2dlc3Qg Ii4uLiBkbyBub3QgbWF0Y2ggdGhlDQo+IHBlcm1pc3Npb25zIGluc3RhbGxlZC4gVGhpcyBjb25m aWd1cmF0aW9uIGtub2IgTVVTVCAuLi4iDQo+IA0KPiAqICIuLi4gdW5sZXNzIGV4cGxpY2l0bHkg Y29uZmlndXJlZCB0byBkbyBzbyBvdGhlcndpc2UuIg0KPiANCj4gVGhlICJzbyIgaXMgY29uZnVz aW5nIGhlcmUuIEkgc3VnZ2VzdCAiLi4uIHVubGVzcyBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgdG8g ZG8NCj4gb3RoZXJ3aXNlLiINCj4gDQo+ICogIklmIG5vIG1hdGNoIGlzIGZvdW5kIGFuZCB0aGUg cmVjZWl2ZWQgZGF0YWdyYW0gaXMgbm90IGEgU1RVTiBwYWNrZXQsDQo+IHJlbGF5aW5nIGlzIG5v dCBwZXJtaXR0ZWQsIGFuZCB0aGUgc2VydmVyIHNpbGVudGx5IGRpc2NhcmRzIHRoZSBVRFAgZGF0 YWdyYW0uIElmDQo+IGFuIGV4YWN0IG1hdGNoIGlzIGZvdW5kIG9yIHRoZSByZWNlaXZlZCBkYXRh Z3JhbSBpcyBhIFNUVU4gcGFja2V0LCB0aGVuIHRoZQ0KPiBwZXJtaXNzaW9uIGNoZWNrIGlzIGNv bnNpZGVyZWQgdG8gaGF2ZSBzdWNjZWVkZWQgYW5kIHRoZSBzZXJ2ZXIgY29udGludWVzIHRvDQo+ IHByb2Nlc3MgdGhlIFVEUCBkYXRhZ3JhbSBhcyBzcGVjaWZpZWQgZWxzZXdoZXJlIChTZWN0aW9u IDExLjMpLiINCj4gDQo+IEFsdGhvdWdoIHRoZSBjb3JyZWN0IGludGVycHJldGF0aW9uIG9mIHRo aXMgdGV4dCBpcyBzdWdnZXN0ZWQgYnkgdGhlIHByZWNlZGluZw0KPiBwYXJhZ3JhcGgsIGFzIHdy aXR0ZW4gaXQgYXBwZWFycyB0byBpbXBseSB0aGF0IHRoZSBub24tZGVmYXVsdCBiZWhhdmlvciBp cyB0aGUNCj4gbm9ybWFsIGV4cGVjdGVkIGJlaGF2aW9yLiBJIHRoaW5rIGl0IHdvdWxkIGJlIGdv b2QgdG8gY2xhcmlmeS4gSSBzdWdnZXN0IHRoZQ0KPiBmb2xsb3dpbmcgdGV4dC4gIklmIG5vIG1h dGNoIGlzIGZvdW5kIGFuZCB0aGUgcmVjZWl2ZWQgZGF0YWdyYW0gaXMgbm90IGEgU1RVTg0KPiBw YWNrZXQsIHRoZSBwZXJtaXNzaW9uIGNoZWNrIGlzIGNvbnNpZGVyZWQgdG8gaGF2ZSBmYWlsZWQu IElmIGFuIGV4YWN0IG1hdGNoIGlzDQo+IGZvdW5kLCB0aGUgcGVybWlzc2lvbiBjaGVjayBpcyBj b25zaWRlcmVkIHRvIGhhdmUgc3VjY2VlZGVkLiBJZiBubyBtYXRjaCBpcw0KPiBmb3VuZCBhbmQg dGhlIHJlY2VpdmVkIGRhdGFncmFtIGlzIGEgU1RVTiBwYWNrZXQsIHRoZSBwZXJtaXNzaW9uIGNo ZWNrIGlzDQo+IGNvbnNpZGVyZWQgdG8gaGF2ZSBmYWlsZWQgdW5sZXNzIHRoZSBzZXJ2ZXIgaXMg Y29uZmlndXJlZCB0byBhbGxvdyBTVFVOIHBhY2tldHMNCj4gd2l0aG91dCBleHBsaWNpdCBwZXJt aXNzaW9uLCBpbiB3aGljaCBjYXNlIHRoZSBwZXJtaXNzaW9uIGNoZWNrIGlzIGNvbnNpZGVyZWQg dG8NCj4gaGF2ZSBzdWNjZWVkZWQuIElmIHRoZSBwZXJtaXNzaW9uIGNoZWNrIGZhaWxzLCByZWxh eWluZyBpcyBub3QgcGVybWl0dGVkIGFuZCB0aGUNCj4gc2VydmVyIHNpbGVudGx5IGRpc2NhcmRz IHRoZSBVRFAgZGF0YWdyYW0uIElmIHRoZSBwZXJtaXNzaW9uIGNoZWNrIHN1Y2NlZWRzLA0KPiB0 aGUgc2VydmljZXMgY29udGludWVzIHRvIHByb2Nlc3MgdGhlIFVEUCBkYXRhZ3JhbSBhcyBzcGVj aWZpZWQgZWxzZXdoZXJlDQo+IChTZWN0aW9uIDExLjMpLiINCj4gDQo+IElmIHRoYXQgdGV4dCBz ZWVtcyB1bndpZWxkeSwgdGhlIHNlY3Rpb24gbWlnaHQgYmUgZWFzaWVyIHRvIHBhcnNlIGlmIGNv bnZlcnRlZCB0bw0KPiBhIGJ1bGxldCBsaXN0Lg0KPiANCj4gU2VjdGlvbiAxOS4yLiBGaXJld2Fs bCBDb25zaWRlcmF0aW9ucw0KPiANCj4gSSBmaW5kIHRoZSBuZXcgcGFyYWdyYXBoIHRvIGJlIGEg bGl0dGxlIGJpdCBkaWZmaWN1bHQgdG8gcmVhZC4gSSBzdWdnZXN0DQo+IHJlb3JnYW5pemluZyB0 aGUgdGV4dC4NCj4gDQo+ID09PT09PQ0KPiBXaGVuIGEgVFVSTiBzZXJ2ZXIgaXMgY29uZmlndXJl ZCB0byBwZXJtaXQgaW5ib3VuZCBTVFVOIHBhY2tldHMgb24gdGhlDQo+IGFsbG9jYXRpb24ncyBy ZWxheWVkIGFkZHJlc3MgZXZlbiBpZiB0aGUgc291cmNlIElQIGFkZHJlc3NlcyBvZiB0aGUgU1RV Tg0KPiBwYWNrZXQncyBkb2VzIG5vdCBtYXRjaCB0aGUgcGVybWlzc2lvbnMgaW5zdGFsbGVkLCB0 aGUgVFVSTiBzZXJ2ZXIgTVVTVCBoYXZlDQo+IGEgc2VjdXJpdHkgcG9saWN5IGZvciBpbmJvdW5k IFNUVU4gcGFja2V0cyBmcm9tIElQIGFkZHJlc3NlcyBub3QgbWF0Y2hpbmcgdGhlDQo+IHBlcm1p c3Npb25zIGluc3RhbGxlZCBpbiBvcmRlciB0byBwcmV2ZW50IGFuIGF0dGFja2VyIGZyb20gZmxv b2RpbmcgdGhlIFRVUk4NCj4gY2xpZW50IHdpdGggU1RVTi1saWtlIHBhY2tldHMuIFRoZSBUVVJO IHNlcnZlciBjYW4gbGltaXQgZm9yd2FyZGluZyB0byB3ZWxsLQ0KPiBmb3JtZWQgU1RVTiBjb25u ZWN0aXZpdHkgY2hlY2sgcGFja2V0cyBieSBsb29raW5nIGZvciB0aGUgU1RVTiBhdHJyaWJ1dGVz DQo+IFVTRVJOQU1FIGFuZCBNRVNTQUdFLUlOVEVHUklUWSBhbmQgdmVyaWZ5aW5nIHRoYXQgdGhl IG1lc3NhZ2UgZG9lcyBub3QNCj4gZXhjZWVkIGEgc3BlY2lmaWMgY29uZmlndXJhYmxlIHBhY2tl dCBzaXplLiBBZGRpdGlvbmFsbHksIHRoZSBUVVJOIHNlcnZlciBwb2xpY3kNCj4gY2FuIGJlIGNv bmZpZ3VyZWQgd2l0aCBtYXhpbXVtIHJhdGUtbGltaXRzIGZvciB0aGUgbnVtYmVyIG9mIFNUVU4g cGFja2V0cw0KPiBhbGxvd2VkIGluIGEgVFVSTiBzZXNzaW9uLCBTVFVOIHBhY2tldHMgYWxsb3dl ZCBwZXIgc2Vjb25kLCBhbmQgSVAgYWRkcmVzc2VzDQo+IGFsbG93ZWQgdG8gc2VuZCBTVFVOIHBh Y2tldHMuDQo+ID09PT09DQo+IA0KPiBPbiAwNC8yMy8yMDE4IDEwOjI5IEFNLCBLb25kYSwgVGly dW1hbGVzd2FyIFJlZGR5IHdyb3RlOg0KPiA+IFVwZGF0ZWQgZHJhZnQgYWxsb3dzIHRoZSBUVVJO IHNlcnZlciB0byBmb3J3YXJkIGluYm91bmQgU1RVTiBjb25uZWN0aXZpdHkNCj4gY2hlY2tzIHdp dGhvdXQgcGVybWlzc2lvbnMgYW5kIGFsc28gYWRkcmVzc2VzIHRoZSBjb21tZW50cyBmcm9tIE5v cml5dWtpDQo+IFRvcmlpLg0KPiA+DQo+ID4gLVRpcnUNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtDQo+ID4+IGRyYWZ0c0BpZXRmLm9yZw0KPiA+PiBT ZW50OiBNb25kYXksIEFwcmlsIDIzLCAyMDE4IDc6NTEgUE0NCj4gPj4gVG86IGktZC1hbm5vdW5j ZUBpZXRmLm9yZw0KPiA+PiBDYzogdHJhbUBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBbdHJhbV0g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMTcudHh0DQo+ID4+DQo+ID4+DQo+ ID4+DQo+ID4+DQo+ID4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRo ZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4gPj4gVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgVFVSTiBSZXZpc2VkIGFuZCBNb2Rlcm5pemVkIFdHIG9mIHRo ZQ0KPiBJRVRGLg0KPiA+Pg0KPiA+PiAgICAgICAgICBUaXRsZSAgICAgICAgICAgOiBUcmF2ZXJz YWwgVXNpbmcgUmVsYXlzIGFyb3VuZCBOQVQgKFRVUk4pOiBSZWxheQ0KPiBFeHRlbnNpb25zDQo+ ID4+IHRvIFNlc3Npb24gVHJhdmVyc2FsIFV0aWxpdGllcyBmb3IgTkFUIChTVFVOKQ0KPiA+PiAg ICAgICAgICBBdXRob3JzICAgICAgICAgOiBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gPj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgQWxhbiBKb2huc3Rvbg0KPiA+PiAgICAgICAgICAgICAgICAg ICAgICAgICAgICBQaGlsaXAgTWF0dGhld3MNCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgSm9uYXRoYW4gUm9zZW5iZXJnDQo+ID4+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRm LXRyYW0tdHVybmJpcy0xNy50eHQNCj4gPj4gCVBhZ2VzICAgICAgICAgICA6IDg0DQo+ID4+IAlE YXRlICAgICAgICAgICAgOiAyMDE4LTA0LTIzDQo+ID4+DQo+ID4+IEFic3RyYWN0Og0KPiA+PiAg ICAgSWYgYSBob3N0IGlzIGxvY2F0ZWQgYmVoaW5kIGEgTkFULCB0aGVuIGluIGNlcnRhaW4gc2l0 dWF0aW9ucyBpdCBjYW4NCj4gPj4gICAgIGJlIGltcG9zc2libGUgZm9yIHRoYXQgaG9zdCB0byBj b21tdW5pY2F0ZSBkaXJlY3RseSB3aXRoIG90aGVyIGhvc3RzDQo+ID4+ICAgICAocGVlcnMpLiAg SW4gdGhlc2Ugc2l0dWF0aW9ucywgaXQgaXMgbmVjZXNzYXJ5IGZvciB0aGUgaG9zdCB0byB1c2UN Cj4gPj4gICAgIHRoZSBzZXJ2aWNlcyBvZiBhbiBpbnRlcm1lZGlhdGUgbm9kZSB0aGF0IGFjdHMg YXMgYSBjb21tdW5pY2F0aW9uDQo+ID4+ICAgICByZWxheS4gIFRoaXMgc3BlY2lmaWNhdGlvbiBk ZWZpbmVzIGEgcHJvdG9jb2wsIGNhbGxlZCBUVVJOIChUcmF2ZXJzYWwNCj4gPj4gICAgIFVzaW5n IFJlbGF5cyBhcm91bmQgTkFUKSwgdGhhdCBhbGxvd3MgdGhlIGhvc3QgdG8gY29udHJvbCB0aGUN Cj4gPj4gICAgIG9wZXJhdGlvbiBvZiB0aGUgcmVsYXkgYW5kIHRvIGV4Y2hhbmdlIHBhY2tldHMg d2l0aCBpdHMgcGVlcnMgdXNpbmcNCj4gPj4gICAgIHRoZSByZWxheS4gIFRVUk4gZGlmZmVycyBm cm9tIHNvbWUgb3RoZXIgcmVsYXkgY29udHJvbCBwcm90b2NvbHMgaW4NCj4gPj4gICAgIHRoYXQg aXQgYWxsb3dzIGEgY2xpZW50IHRvIGNvbW11bmljYXRlIHdpdGggbXVsdGlwbGUgcGVlcnMgdXNp bmcgYQ0KPiA+PiAgICAgc2luZ2xlIHJlbGF5IGFkZHJlc3MuDQo+ID4+DQo+ID4+ICAgICBUaGUg VFVSTiBwcm90b2NvbCB3YXMgZGVzaWduZWQgdG8gYmUgdXNlZCBhcyBwYXJ0IG9mIHRoZSBJQ0UN Cj4gPj4gICAgIChJbnRlcmFjdGl2ZSBDb25uZWN0aXZpdHkgRXN0YWJsaXNobWVudCkgYXBwcm9h Y2ggdG8gTkFUIHRyYXZlcnNhbCwNCj4gPj4gICAgIHRob3VnaCBpdCBhbHNvIGNhbiBiZSB1c2Vk IHdpdGhvdXQgSUNFLg0KPiA+Pg0KPiA+PiAgICAgVGhpcyBkb2N1bWVudCBvYnNvbGV0ZXMgUkZD IDU3NjYgYW5kIFJGQyA2MTU2Lg0KPiA+Pg0KPiA+Pg0KPiA+PiBUaGUgSUVURiBkYXRhdHJhY2tl ciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gPj4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMvDQo+ID4+DQo+ID4+IFRoZXJl IGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4gPj4gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTE3DQo+ID4+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMt MTcNCj4gPj4NCj4gPj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxh YmxlIGF0Og0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0 Zi10cmFtLXR1cm5iaXMtMTcNCj4gPj4NCj4gPj4NCj4gPj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPj4gc3VibWlz c2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KPiA+Pg0KPiA+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZh aWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ID4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvDQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4+IHRyYW0gbWFpbGluZyBsaXN0DQo+ID4+IHRyYW1AaWV0Zi5v cmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQo+ID4N Cj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ IHRyYW0gbWFpbGluZyBsaXN0DQo+ID4gdHJhbUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KPiA+DQoNCg== From nobody Tue May 29 03:47:57 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 D0843127522; Tue, 29 May 2018 03:47:49 -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.80.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152759086979.25527.10597739101423022507@ietfa.amsl.com> Date: Tue, 29 May 2018 03:47:49 -0700 Archived-At: Subject: [tram] I-D Action: draft-ietf-tram-turnbis-18.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 29 May 2018 10:47:50 -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-18.txt Pages : 84 Date : 2018-05-29 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-18 https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-18 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 May 29 03:53:12 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 A58D7126E01 for ; Tue, 29 May 2018 03:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 DR-VIgStjyeP for ; Tue, 29 May 2018 03:53:08 -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 6644B126D45 for ; Tue, 29 May 2018 03:53:08 -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=1527591191; 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-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-Office365-Filtering-Correlation-Id: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=P 9kYjhkKMaFldAfpxFQ96RFLMvPcDyYZGL2jlt4MAI 0=; b=GH1GLgwCN1GSY5YkQH2PqpHqpWfiJq3qATj/oJANFIVY uuaggx/kiMXfGPBNK2DukLQAcI2DNYii4lChjP6LfNMnh4Tup7 GJeSEV+8aPRvJqLXK1JSlUiHjKdsML7xQInxpgHBRezTZwhw6L WyjeO7uC9d12fob9BqI31/OyIBc= 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 4a35_a9f0_ef1ea4c9_bdbc_45ed_b913_246d1818e43f; Tue, 29 May 2018 05:53:10 -0500 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 29 May 2018 04:53:04 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 29 May 2018 04:53:03 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 29 May 2018 04:53:03 -0600 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 29 May 2018 04:52:56 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1363.namprd16.prod.outlook.com (10.172.206.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.11; Tue, 29 May 2018 10:52:56 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::601e:a909:b9fe:31bd]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::601e:a909:b9fe:31bd%8]) with mapi id 15.20.0797.018; Tue, 29 May 2018 10:52:56 +0000 From: "Konda, Tirumaleswar Reddy" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-18.txt Thread-Index: AQHT9zq5N1gn8v3m7UqV0RigDpo6KaRGhy+w Date: Tue, 29 May 2018 10:52:56 +0000 Message-ID: References: <152759086979.25527.10597739101423022507@ietfa.amsl.com> In-Reply-To: <152759086979.25527.10597739101423022507@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.300.84 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; BN6PR16MB1363; 7:F2A9yC7faZ5LZz8Y504DbwVAKhxdKRMJjf8fyV6/gRhOojWa8Yeggj5qcSRaHZQyGD13d+4pYe3LRqr4PJK0jMW5EN72VYBSPoo+aQar3q+B0d7V7/sYJNO4KL9G2C9BzHtaebmcTB3Yi7uGIu1sZ8NeNhCMhLDfcctYZ+7zakjkpREda676xcs53GYcVmmnwOgpvIXO1StfrM/M2ykrixkwdkI/NNS/90wvg0KTGvvogrCFUd9CFHKcPcWvboC6 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1363; x-ms-traffictypediagnostic: BN6PR16MB1363: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123562045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:BN6PR16MB1363; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1363; x-forefront-prvs: 0687389FB0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(376002)(39860400002)(396003)(366004)(346002)(189003)(199004)(377424004)(13464003)(32952001)(2501003)(305945005)(316002)(74316002)(5250100002)(7736002)(25786009)(6246003)(5660300001)(86362001)(2900100001)(6916009)(3846002)(66066001)(486006)(186003)(6116002)(476003)(53936002)(72206003)(11346002)(55016002)(106356001)(229853002)(966005)(8676002)(6436002)(2906002)(33656002)(76176011)(102836004)(14454004)(105586002)(26005)(99286004)(97736004)(446003)(478600001)(68736007)(53546011)(6506007)(8936002)(7696005)(6306002)(1730700003)(2351001)(3660700001)(9686003)(81166006)(81156014)(3280700002)(5640700003)(80792005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1363; 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: qRMOEepdpueR3e3bZCdFmXU59Lilm4DwYoVfKHo06swO5um35r/g/DXYIF7Xv5HRfdlmBxS1n+Ey6TRFTYXPio8U6WNReLdzJGo1omigP5x2btdsUSSiRLV09ID4yJ7BtRJ8yNWLZec15wkEZ8zP1F/Oc+NnwHQNfkA0GR8VG5WKvgc1jWtInOEahK0+Xjb8uNbKYZ+SHeLOC7LPEIp5SQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: f3f044d6-0dc2-4657-98fc-08d5c552562f X-MS-Exchange-CrossTenant-Network-Message-Id: f3f044d6-0dc2-4657-98fc-08d5c552562f X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2018 10:52:56.5337 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1363 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 <6296> : inlines <6663> : streams <1788132> : uri <2649106> Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-18.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 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, 29 May 2018 10:53:11 -0000 This revision incorporates editorial changes proposed by Brandon to allow t= he TURN server to forward inbound STUN connectivity checks without explicit= permissions.=20 More comments and suggestions are welcome. Cheers, -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Tuesday, May 29, 2018 4:18 PM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turnbis-18.txt >=20 >=20 >=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 IE= TF. >=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-18.txt > Pages : 84 > Date : 2018-05-29 >=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-18 > https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-18 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turnbis-18 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.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