Re: Passwords over the wire and WebAuthn woes

Benjamin Kaduk <kaduk@mit.edu> Sun, 17 May 2020 07:00 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8AB3A0DF0 for <ietf@ietfa.amsl.com>; Sun, 17 May 2020 00:00:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, 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 gSYJR0RQSHVJ for <ietf@ietfa.amsl.com>; Sun, 17 May 2020 00:00:01 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 CFAD83A07A4 for <ietf@ietf.org>; Sun, 17 May 2020 00:00:00 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04H6xusd016527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 17 May 2020 02:59:58 -0400
Date: Sat, 16 May 2020 23:59:56 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Michael Thomas <mike@mtcc.com>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
Subject: Re: Passwords over the wire and WebAuthn woes
Message-ID: <20200517065956.GC58497@kduck.mit.edu>
References: <6604a0ab-c714-81fb-9bc7-7834182c7bdf@mtcc.com> <20200512051740.GY27494@kduck.mit.edu> <a426e117-fed7-d275-f27f-f1558cb0c227@mtcc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <a426e117-fed7-d275-f27f-f1558cb0c227@mtcc.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/wsSbZ8R_yv2IxfpNd_7zeqlnFzI>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 May 2020 07:00:02 -0000

On Tue, May 12, 2020 at 12:30:56PM -0700, Michael Thomas wrote:
> 
> On 5/11/20 10:17 PM, Benjamin Kaduk wrote:
> > On Thu, May 07, 2020 at 02:05:53PM -0700, Michael Thomas wrote:
> >> So here's the question: the flows that I created are definitely over the
> >> wire. But they are over the wire between really one party, the web site
> >> owner, since they control the code (= server, client js) on both ends.
> >> However as everybody knows, security is not easy so getting those flows
> >> *correct* is very hard. I have some experience here, and it's mainly
> >> telling me that I'm sure I got things wrong. So  what is the policy
> >> within IETF where a site could roll their own, but really shouldn't
> >> because it ought to be vetted?  Is standardizing such a thing in scope
> >> in IETF or other standards bodies? Because at its heart is not
> >> interoperability across implementation, but vetting a security design
> >> that goes over the wire.
> > If I understand you correctly, it can be in scope to write up
> > (informationally, usually) a protocol for sending stuff over the wire
> > between two endpoints controlled by the same entity that avoids
> > security-relevant pitfalls.
> 
> 
> I guess this begs the question why standards-track isn't appropriate? I 
> mean, lots of $MEGACORPS might just as well be different organizations 
> when it comes to interoperability issues. And they certainly have all of 
> the same problems of each group rolling their own (badly). And of course 
> standards mean that there's review, which is especially important with 
> security related stuff.

Standards-track is not out of the question, and could well be appropriate
in some casess.  My parenthetical was just meant to provide my unscientific
estimate of what has been done in the past.

-Ben