Re: [smime] Discussion of draft-melnikov-smime-msa-to-mda
Phillip Hallam-Baker <hallam@gmail.com> Wed, 05 February 2014 17:42 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: smime@ietfa.amsl.com
Delivered-To: smime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BEE1A011C for <smime@ietfa.amsl.com>; Wed, 5 Feb 2014 09:42:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=ham
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 h1pJcuZc-N0k for <smime@ietfa.amsl.com>; Wed, 5 Feb 2014 09:42:00 -0800 (PST)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 304931A0122 for <smime@ietf.org>; Wed, 5 Feb 2014 09:42:00 -0800 (PST)
Received: by mail-la0-f52.google.com with SMTP id c6so576831lan.25 for <smime@ietf.org>; Wed, 05 Feb 2014 09:41:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q5xfzoe6Ux+SLl09b12IqCgTGrFW3ql3Nqdy1oHIR3w=; b=qe4odeOeyTHk8JsahNWUz3ODQcVzRfMXUPoBlCdpxeBeOZfsHFaXly0tmZH+4D56T3 0Rp44DZwRUocotsTvUoEC6Vge9v4jyZJuxw9OJAkD9lg0V+6jqIya8e1UD6oeBhm9zIk VgtRhoR5MMgUh4EpOzM2pYHnQ0G1PuEnTfgB9S9Z3pYUy3PMOopV/0S51aWDrULnsvht GTCbrDF6LRYRegnYAWPUwNHF6oKFbZbv+TNWRpYiw+LaVhsdOtQyJePAFz4I8f0lrz7m BLV/FAAU9lfAgOggwrs4SlV7k9NsJ1wwY2GzVFx49mwALQ0b14Zz7gY/4TJ/gNOShMb0 v8aw==
MIME-Version: 1.0
X-Received: by 10.112.211.233 with SMTP id nf9mr1838001lbc.50.1391622118579; Wed, 05 Feb 2014 09:41:58 -0800 (PST)
Received: by 10.112.37.168 with HTTP; Wed, 5 Feb 2014 09:41:58 -0800 (PST)
In-Reply-To: <569490B7-B09B-459D-B171-92C469243AF5@vpnc.org>
References: <20140205140418.6605.46720.idtracker@ietfa.amsl.com> <569490B7-B09B-459D-B171-92C469243AF5@vpnc.org>
Date: Wed, 05 Feb 2014 12:41:58 -0500
Message-ID: <CAMm+LwgZXWvrK_EkiZzdAWcbb3=ohokBRy5zVB+jGrVEucNmhg@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: multipart/alternative; boundary="001a11c3c8a60a245704f1ac4692"
Cc: smime@ietf.org
Subject: Re: [smime] Discussion of draft-melnikov-smime-msa-to-mda
X-BeenThere: smime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SMIME Working Group <smime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/smime>, <mailto:smime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/smime/>
List-Post: <mailto:smime@ietf.org>
List-Help: <mailto:smime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smime>, <mailto:smime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Feb 2014 17:42:03 -0000
On Wed, Feb 5, 2014 at 11:59 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote: > This document should be of obvious interest to anyone on this mailing > list. Please review it and send comments here to the list for discussion. > +1 One toplevel comment is that the only real challenge here is working around the constraints of the legacy installed base. That is part of what makes S/MIME so attractive. It is also what shots you in the foot. this is one of those cases where pushing for a big change or several changes at once might actually be easier than a small one. The difficulty of the deployment problem comes from the diversity and ambiguities of the deployed base. Getting signature to work right when the mail is received by an application or service that does the right thing is easy. The problem comes when the receiver does not understand what the right thing is. Working domain to domain is a good idea. We have infrastructures that work very well making domain level assertions. So lets imagine that Bank of Ethel, a major money center bank with $100 billion under management decides to send all their mail signed with S/MIME. That can't work today because if even 0.01% of that mail is received by faulty mail clients that give a terrible user experience, that is several million dollars worth of customer support calls. Now lets imagine that we work at the domain level. We have two infrastructures available: DNS allows us to make domain level statements about the Internet infrastructure, DNSSEC allows us to authenticate those statements. WebPKI allows us to make statements about the accountability of organizations and tie them to domains. Ideally I would want to use EV certificates with logotype data embedded to show the logo of the organization sending mail. DNS does not really help us very much when making statements about the sender of a message because the mail protocols don't really require the sender to have a DNS domain at all. On the receiver side, the DNS is the maypole around which the mail protocols dance. This is not an accident, email is the killer application that made the DNS necessary in the first place. Lets imagine that we have a statement from the MDA (i.e. receiver) that says 'please send all mail to me with group S/MIME signatures and/or encryption, I will make sure that all the necessary transformations get done to ensure that the receiving MUA gets the message in a form that it can understand.' The logical place to make that statement is actually an SMTP extension. But we would ideally want to authenticate that statement under STARTTLS and then tie the STATTLS credentials back to the DNS domain with something like DANE or WebPKI or both. I won't go into it here, but a lot of my objections to DNSSEC under the ICANN hierarchy, the fact that many registrars are crooks etc. etc. are answered if we tie DNSSEC authentication inside a domain to a certificate that is published in a Certificate Transparency log. That one statement allows us to unlock the deployment deadlock that makes progress in the S/MIME world so difficult. The changes that we then need on the protocol side are a few flags in the IMAP and SMTP services. The workings of these flags is essentially no different to the internationalization flags that already exist and Paul H. can probably tell us how these work. -- Website: http://hallambaker.com/
- [smime] Publication has been requested for draft-… Sean Turner
- [smime] Discussion of draft-melnikov-smime-msa-to… Paul Hoffman
- Re: [smime] Discussion of draft-melnikov-smime-ms… Phillip Hallam-Baker