Re: [Uta] Review of draft-ietf-uta-email-deep-08

Keith Moore <moore@network-heretics.com> Tue, 25 July 2017 11:07 UTC

Return-Path: <moore@network-heretics.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 44C05131BBF for <uta@ietfa.amsl.com>; Tue, 25 Jul 2017 04:07:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
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 EAgQp-5Lw5wi for <uta@ietfa.amsl.com>; Tue, 25 Jul 2017 04:07:52 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B355F126E3A for <uta@ietf.org>; Tue, 25 Jul 2017 04:07:52 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1C22020B50; Tue, 25 Jul 2017 07:07:52 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 25 Jul 2017 07:07:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=jmb9UTB9x4W56DxfQD 1/sQTRR+It9hlrz09RM13dl1o=; b=UZnNxz9hnHjouj0YK74W7/lXuQLjbFFJoY OEzww97tTH9PQZaXVeE8N2pODD8z9F1boU3BBJkFYRGmxfakUckbzi5h4uF8yOPx R/kNs5J5o6OIdnbjlUh9Y1FFsk3ESL0SWEAN2zISlJZQdQ0G/jEhKxVdwHJ7ZFjZ mApxZ4fzQEp79W+xrbytKXy43VTsthxqY48hYtIGlY4C3Nrt4LbBvrRKysXmUGm3 jvcVXPatpXHy06sGWVniDpr1oHXO1aiExMihyk2U90mFnL8Gk//6d6jJ5qHMDrzJ XkcwOftw9GUQlGb99KNMr7no5EcBxB8Bo/wVBwi8dJCvNExOTR9Q==
X-ME-Sender: <xms:iCZ3WXla_VhqZJorwoRK-ciFfy4crzR5eNmzIfJHeMqvRcTeBsiL4A>
X-Sasl-enc: Y2tn/GEoDmAs71R5xc5RsHOLUHZS9ZHA+qSUGtU/sIpz 1500980871
Received: from [192.168.1.66] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id A71777E1D0; Tue, 25 Jul 2017 07:07:51 -0400 (EDT)
To: uta@ietf.org, Alexey Melnikov <alexey.melnikov@isode.com>
References: <c0868a3a-be39-a971-02cc-18c550138a9f@isode.com> <ef041be4-8c98-5339-68d2-6d6b26233459@network-heretics.com> <5976EB8A.9090802@isode.com>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <808a8977-a309-c187-6070-ed8a9ed81365@network-heretics.com>
Date: Tue, 25 Jul 2017 07:07:51 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <5976EB8A.9090802@isode.com>
Content-Type: multipart/alternative; boundary="------------BE0EEBC6D4F56E2DDA4D01CA"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/01IXx2DLmYrj8Pu5OLdxwTOz_5c>
Subject: Re: [Uta] Review of draft-ietf-uta-email-deep-08
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 25 Jul 2017 11:07:54 -0000

On 07/25/2017 02:56 AM, Alexey Melnikov wrote:
>> Use of pinned certs isn't forbidden by the draft, but pinned certs don't
>> meet minimum confidentiality requirements.
>>
>> I think it might be possible to adequately address the security concerns
>> associated with the usual implementation of pinned certificates, but
>> working though the details seems beyond the scope of this document.
> Ok, how about inserting "typically" before "lacks a mechanism to revoke
> ...". This way you are making an observation about state of UIs without
> sounding like it is a fact of nature.
I'm thinking more along the lines of "there is currently no protocol 
defined for revocation of a pinned certificate".

TOFU isn't entirely good or evil, though it does provide a vulnerability 
that will certainly be exploited.  (We're creating a similar 
vulnerability by encouraging use of unsigned SRV records to dictate 
account configuration parameters, which seems hard to fix at the moment 
given how hard it is to deploy DNSSEC.   Maybe DNS-over-TLS will emerge 
as a way to double-check the validity of those SRV records.)

Keith