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

Brandon Williams <brandon.williams@akamai.com> Fri, 18 May 2018 13:44 UTC

Return-Path: <brandon.williams@akamai.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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" <linuxwolf+ietf@outer-planes.net>, Benjamin Kaduk <kaduk@mit.edu>, Eric Rescorla <ekr@rtfm.com>
Cc: Marc Petit-Huguenin <petithug@acm.org>, tram-chairs@ietf.org, tram@ietf.org, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, tasveren@rbbn.com, The IESG <iesg@ietf.org>, draft-ietf-tram-stunbis@ietf.org
References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <c0a06754-6f8c-97dc-7f7e-26a7df43e842@acm.org> <31a441d2-8843-c8ee-f5ef-5496e5b4b364@acm.org> <CABcZeBO+2LG4-1-dhzTTSJFH6uhJdSEKLjyVfxO+krzHR8ueQw@mail.gmail.com> <29c18858-3694-c48a-54c3-6dcbfa3b6705@acm.org> <20180515182435.GN2249@kduck.kaduk.org> <25e551de-87b7-1612-c869-8336fe3c4b95@akamai.com> <CABcZeBN+sgdH5a56zWTHm-=PD3vJ_DzSyPZYF=S5Bt3i_ATvBw@mail.gmail.com> <20180517203337.GN2249@kduck.kaduk.org> <6710a82f-3857-7b06-c253-73674d65d323@outer-planes.net>
From: Brandon Williams <brandon.williams@akamai.com>
Message-ID: <fb34d1f8-e57d-8a1b-ea57-e60b3c899dfc@akamai.com>
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: <https://mailarchive.ietf.org/arch/msg/tram/mRTfO_lVHxC1-2gygBsP8F24Yf0>
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." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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
>