Re: [apps-discuss] Mail client configuration via WebFinger

Phillip Hallam-Baker <ietf@hallambaker.com> Mon, 08 February 2016 20:22 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEACD1B3242; Mon, 8 Feb 2016 12:22:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 GMDdhKxvz1Gv; Mon, 8 Feb 2016 12:22:56 -0800 (PST)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 7E63E1B32AE; Mon, 8 Feb 2016 12:22:56 -0800 (PST)
Received: by mail-lf0-x229.google.com with SMTP id l143so103049479lfe.2; Mon, 08 Feb 2016 12:22:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Rl3BwJddE82/NqsqMZ3Mk7vdOMgNv62oE5CrcONew/4=; b=QEN4YTQqek0YGaEj49ZkU+aHAVsFmi3d5pdBy9iIR/9OJLfArP1CXt5bYBQsR3s/qc 9qF7tCnQwZM+vHkz1j2h4oNLSfpy2IuFedFNf+bz5PCEEUFhF8ohiCVIF4LQ19a9gKlB yItE5njzxnsawWZKQCOF50pV6Rcez3kBKpSPwfzVvYLeElmNeOt5aTSZoPI3mza/g+H5 OT9FST+9VAk+6nryYrZz5BTrgPOt7EdTK2F5o5N6kY01K+CI+onLFXsHUlbywwCZvZcy VY8DdntGTwwQjsVgviHr8+YzEmSOCEhBdYiJ1wOIsl8h77scYLBu23kGtBrKmqr92B0W k+kw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Rl3BwJddE82/NqsqMZ3Mk7vdOMgNv62oE5CrcONew/4=; b=L9CdW+J1Pj/EKBFgGZLCuFcORAYFB0DMogt0MA1jKFO/h/iCkkDKeLqdSqVzREDeTH JuPrHbr6YUxBwRqNPokK1ekOFHU+s/Q/uof08303xxRFX4J3gLzfaGgXy11yQ0AkIoei 5ElKPf0vAc3scAtjRSJO49KUtN1aJwQrhyNOz3g305ogjFP1Zii4oLUZwxR802E6iGFu bY8uc4fyJnMi/7+SxiVHHZC0nPnRjrjRAWBLO9AALqaRc6QUODEA0q9R3nagqfGFkK50 hb/v6gJwwxucl6KVekfmnL4/ZAP2xIk7my00XdQ8KuTkocCSLk4HfZaqho8gpBrfi76f W+Ow==
X-Gm-Message-State: AG10YOSDiW1SCUe3XI+1NAoDEKDV7loNQTv0V3Fx8E6ZiKCLIEfaYbVc5sqYHJJk7fLtKCeH+/Z8Ucvy4HB8Xg==
MIME-Version: 1.0
X-Received: by 10.25.205.7 with SMTP id d7mr4820324lfg.70.1454962974806; Mon, 08 Feb 2016 12:22:54 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.49.80 with HTTP; Mon, 8 Feb 2016 12:22:54 -0800 (PST)
In-Reply-To: <56B7F345.9060505@cs.tcd.ie>
References: <emc9b882a7-c562-43e8-9f49-588d8de9d20b@sydney> <56B7F345.9060505@cs.tcd.ie>
Date: Mon, 8 Feb 2016 15:22:54 -0500
X-Google-Sender-Auth: t_h3vjd3BZXXX_DfZNkKXBlNOwg
Message-ID: <CAMm+LwgZQJK-5L3ja99MES3Mk1Ox41nhG0VRwtehMPkLU9Oe+w@mail.gmail.com>
From: Phillip Hallam-Baker <ietf@hallambaker.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/epbiUID1Ws93uWkiEkEqspiXv4w>
Cc: General discussion of application-layer protocols <apps-discuss@ietf.org>, webfinger@ietf.org
Subject: Re: [apps-discuss] Mail client configuration via WebFinger
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Feb 2016 20:22:58 -0000

On Sun, Feb 7, 2016 at 8:45 PM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
>
>
> On 08/02/16 00:45, Paul E. Jones wrote:
>>
>> If ACAP was going to take off, I think it would have by now.
>
> That seems correct to me.
>
> I think solving this problem in isolation would be worthwhile
> if folks deployed a solution. (IOW, let's not generalise too
> much.)
>
> My own ask here is that the user not be expected to enter a
> password until after whatever automatable checks can be done,
> have been done. I really hate entering a password into a new
> device before I've gotten any feedback that that device is not
> going to send the password in clear over the network. And yes
> that may be a minority concern, but it is still I think one
> we ought not ignore, esp. as it should be quite possible to
> encourage good behaviour here (it's as easy as encouraging
> bad behaviour;-)

PLEASE

No more password based protocols.

Passwords are not the way to solve this problem except in the
hopefully very rare case of catastrophe recovery.

'We believe in strong cryptography and reviewed code'


The problem with passwords is that a human cannot be expected to
remember any piece of information that is secure enough to be
unguessable.

Remember when the requirement to have mixed case and a punctuation
mark in a password came in? That was in response to Crack published in
1991 which was a dictionary based search running on machines that
could do 35 password tests a second. Four years ago, someone lashed
together 20 GPU cards discarded by the bitcoin miners and built a
machine that could do 350 billion tests a second. It isn't a
dictionary attack and so the password restrictions actually reduce the
search space and make the problem easier.

Passwords are done, they are dead.

If we want to have an application configuration protocol it should be
capable of configuring cryptographic authentication credentials. Now
we might optionally encrypt those credentials with a PIN, but that is
a local security matter, not something that travels over the network.