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:02 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 2F2F6130F03; Thu, 28 Feb 2019 08:02:11 -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 6VS01DKJcvFe; Thu, 28 Feb 2019 08:02:09 -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 6CC7B130ED6; Thu, 28 Feb 2019 08:02:09 -0800 (PST)
Received: by mail-yw1-f41.google.com with SMTP id o184so11447719ywo.5; Thu, 28 Feb 2019 08:02:09 -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=LSZEEP/o2chtxRpMZSaEPo+sWrbRHWJE2MjKX/JsNk4=; b=hRyQaVM+Inne+q0Z0qrNuSgizx6e4QY5QgMw5Ll3n942lA029a9cqsHVToRd96yYDk almmADJ+H3PAZVgZ9NRWFeruTFJlr8UB9YyBCF67y/zfSsHsXpkV7Cd+GXUxyaS9dnyN w31sX3TZrXUps7WTVyPLxZs0RpWYOIR8YLR98noaUVUWtox/CgNIn2ETdfke1bJzVnk/ MuRk4cPYYqVxpaE7PWOVt44W4Mnxobo3GahoFrVhwil2h7rzyJyeSiQf7qa2QBDKF77h uC5U892E2MnGu4IASP0RVuy/iWpE3zUdLo4KtTOcKc7h3zIftQgQsBkAYF6eoqVflveE dFeQ==
X-Gm-Message-State: AHQUAubgvSVP5imJyXOVcTzo+wG3DhsWEfkjbbKVWyMIYRCcQcqbtpBj prhBkrjwC6H0l5XN/NdUhysrK9nuTvQqAW3+j2Y=
X-Google-Smtp-Source: AHgI3Ia0F9LSebqSVjGyT2lUVPweLwtpB5kLDaR/kLAEEnyW7/S9HGusuN5l2pCEJFagGKa2u7frEB5O33PCufGxPG0=
X-Received: by 2002:a81:180b:: with SMTP id 11mr5860797ywy.431.1551369728115; Thu, 28 Feb 2019 08:02:08 -0800 (PST)
MIME-Version: 1.0
References: <155076162945.8595.2671476533659571699.idtracker@ietfa.amsl.com> <554356ec-de3a-08ed-a920-0397813895e0@bluepopcorn.net> <CABcZeBPOWVhPTpBt3E8GsqH7LMtG4y04voqTCLS=PG3hZk+NaA@mail.gmail.com>
In-Reply-To: <CABcZeBPOWVhPTpBt3E8GsqH7LMtG4y04voqTCLS=PG3hZk+NaA@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Thu, 28 Feb 2019 08:01:55 -0800
Message-ID: <CALaySJKdQziPJerfW9RJ_tExytaESjmfNMysRduYJ93z=kuyAg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Jim Fenton <fenton@bluepopcorn.net>, uta@ietf.org, uta-chairs@ietf.org, valery@smyslov.net, draft-ietf-uta-smtp-require-tls@ietf.org, The IESG <iesg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/wV0JXG84_YxgUIgmb-_v6EtV5vQ>
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:02:12 -0000

>> > To elaborate on one point a bit: it seems to me that it's harmful to
>> > security to allow the sender to unilaterally override the recipient's
>> > preferences that something be encrypted. To forestall one argument,
>> > yes, the sender knows the contents of the message, but the recipient
>> > knows their own circumstances, and they may be at particular risk
>>
>> The general approach of REQUIRETLS is that the sender is in a good
>> position to determine the sensitivity of the message(s) they are
>> sending, because they know what the message is.
>
> Right, this is what I am disputing.

I have to agree with EKR about it not completely being the sender's
decision, though for a rather different reason.  I really doubt that
in the vast majority of cases any human user will actively choose or
not choose this option on a message-by-message basis.  I think that in
the real world we'll see one of two use cases:

1. The sending system is just configured to require TLS, because, of
course, it's a Good Thing to make sure TLS is used all the time.  This
might or might not cause frustrating delivery problems, depending upon
how broadly and quickly this gets deployed.

2. Some other aspect of a message, such as having it marked "Company
Confidential", "Top Secret", or some such, will result in the sending
system requiring TLS for that message.  My experience with working in
organizations that use such markings is that they overuse them: the
sending human doesn't actually determine the sensitivity; rather, the
sending human becomes used to putting "Top Secret" on nearly
everything, or "Confidential and Privileged", in the case of lawyers,
on absolutely everything including, "Let's have lunch."

For EKR's concern about the recipient's preference, this protocol
would need some sort of recipient policy that senders would look up.
While I absolutely see the value in that, I'm not sure how workable it
would be.

Barry