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

Benjamin Kaduk <kaduk@mit.edu> Fri, 18 May 2018 22:11 UTC

Return-Path: <kaduk@mit.edu>
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 <kaduk@mit.edu>
To: Brandon Williams <brandon.williams@akamai.com>
Cc: "Matthew A. Miller" <linuxwolf+ietf@outer-planes.net>, Eric Rescorla <ekr@rtfm.com>, 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
Message-ID: <20180518221119.GB2249@kduck.kaduk.org>
References: <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> <fb34d1f8-e57d-8a1b-ea57-e60b3c899dfc@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <fb34d1f8-e57d-8a1b-ea57-e60b3c899dfc@akamai.com>
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: <https://mailarchive.ietf.org/arch/msg/tram/Zcq1AzKGhx5JIpTGM3k4V8N7F2E>
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." <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 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