Re: [Uta] Eric Rescorla's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)

Barry Leiba <barryleiba@computer.org> Thu, 28 February 2019 16:15 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E223130F93; Thu, 28 Feb 2019 08:15:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level:
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 CUb8SuX9vOXf; Thu, 28 Feb 2019 08:15:15 -0800 (PST)
Received: from mail-yw1-f41.google.com (mail-yw1-f41.google.com [209.85.161.41]) (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 639FA130FA0; Thu, 28 Feb 2019 08:15:15 -0800 (PST)
Received: by mail-yw1-f41.google.com with SMTP id v201so11485293ywa.9; Thu, 28 Feb 2019 08:15:15 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bbvjzKXPdxNm5c31he0ttcX5xUlK/212fyQp+M+vSW8=; b=kIsr4+uqdPgZAU3GwG37HK0DbX7legmCNd/dXUqgcaaUA0AEKvYL1Mc7bA0W7ApcOB CejM/ne9oOa5ashyWANjiN8XAt61nlSprA/rx4uCg1WgxSzObuQc8Ori2DmoVxWV33qj 1S/L0yRUA4Zbodr7zK2GaCk4yiqbwKy8upFlKw5ftgumDfLwREcb4SUZEePnpcX8vQ38 BxwIXMfKefhpJbBsF+CK68PlbHg6Xr9yYpLMLstkhW20+n2Ci5C1miOE8sNd+yvgFkUR Ky/2UMCm686VpfKetphR5ADwaU1eg9w+0pmVljpuYJt4KJlkId9AAAkkf/MC79SyrbA7 PhJg==
X-Gm-Message-State: AHQUAubjGixoF9hJmPC9w2eFrijkhbkG6/lrxoKjqVdjYlQ4mcHLdazd RxS9luXuPdTC9VuibnokaqrNyk2c4O7lnZb+HYo=
X-Google-Smtp-Source: AHgI3IZ1Ifx3/07FpljOoCk+GypxAe5QM47lJHG4xFFOYUcGfOw4/c1uZF3sxYIikU0+docQ39WE2jSAKm3Fbt1DXCU=
X-Received: by 2002:a81:3a0b:: with SMTP id h11mr6069733ywa.325.1551370514318; Thu, 28 Feb 2019 08:15:14 -0800 (PST)
MIME-Version: 1.0
References: <155076162945.8595.2671476533659571699.idtracker@ietfa.amsl.com> <20190227234403.GF4108@localhost>
In-Reply-To: <20190227234403.GF4108@localhost>
From: Barry Leiba <barryleiba@computer.org>
Date: Thu, 28 Feb 2019 08:15:03 -0800
Message-ID: <CALaySJLsj+5xsOcukj8Pn9AU7JCvVpHJOTySV_4x62zD3DLXwQ@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Cc: uta@ietf.org, IESG <iesg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/hiceVnCFPI1Hz6LVctGRSJwFtvM>
Subject: Re: [Uta] Eric Rescorla's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Feb 2019 16:15:18 -0000

> My idea of an ideal end-state for hop-by-hop security for e-mail is
> that:
>
> a) *senders* should be able to specify in the envelope that they want
>    secure, encrypted, authenticated delivery of email at every hop,
>
> b) senders should get bounces when that cannot happen,
>
> c) *recipients* get an indication of the security of any given e-mail's
>    path to the recipient (perhaps we need a Transmitted: header by which
>    each sending hop MTA can record what it did to authenticate the next
>    hop),
>
> d) (a) and (c) get prominent UI indications in MUAs,

See, this is why we often say that IETF folks should not generally try
to design UI things:
There are plenty of studies that show that users -- apart from those
of us on this discussion thread and our ilk -- don't understand these
sorts of UI indications.  General users grossly misunderstand the
"lock" symbol that browsers use to tell us that HTTPS is in effect.
I'm sure that any attempt to create some version of "this message
was/wasn't sent in a way that the message content can't have been
looked at in transit (well, except for someone looking at it while it
was stored waiting to be relayed)" that's understandable to a typical
user will be wildly unsuccessful.

Barry