[Uta] Email over TLS drafts

"Orit Levin (LCA)" <oritl@microsoft.com> Sun, 23 February 2014 22:47 UTC

Return-Path: <oritl@microsoft.com>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E591A075C for <uta@ietfa.amsl.com>; Sun, 23 Feb 2014 14:47:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.798
X-Spam-Level:
X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_60=1.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 ZcNcgqBqaegj for <uta@ietfa.amsl.com>; Sun, 23 Feb 2014 14:47:31 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3C11A01C5 for <uta@ietf.org>; Sun, 23 Feb 2014 14:47:31 -0800 (PST)
Received: from BL2PR03MB290.namprd03.prod.outlook.com (10.141.68.19) by BL2PR03MB592.namprd03.prod.outlook.com (10.255.109.35) with Microsoft SMTP Server (TLS) id 15.0.883.10; Sun, 23 Feb 2014 22:47:29 +0000
Received: from BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) by BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) with mapi id 15.00.0883.010; Sun, 23 Feb 2014 22:47:30 +0000
From: "Orit Levin (LCA)" <oritl@microsoft.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>, "moore@network-heretics.com" <moore@network-heretics.com>, "chris.newman@oracle.com" <chris.newman@oracle.com>
Thread-Topic: Email over TLS drafts
Thread-Index: Ac8w23U47Wyus96JSTSr96rckaErlw==
Date: Sun, 23 Feb 2014 22:47:29 +0000
Message-ID: <f43cbf441ed743f08b70201a7da1a119@BL2PR03MB290.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [81.155.215.86]
x-forefront-prvs: 0131D22242
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(51444003)(199002)(189002)(87266001)(69226001)(54316002)(56776001)(83322001)(76482001)(95416001)(94946001)(85306002)(86612001)(94316002)(86362001)(76176001)(81342001)(87936001)(47736001)(50986001)(47976001)(4396001)(2656002)(95666003)(49866001)(81542001)(93516002)(47446002)(93136001)(33646001)(46102001)(80976001)(74662001)(74502001)(31966008)(51856001)(53806001)(54356001)(74366001)(81816001)(92566001)(59766001)(79102001)(63696002)(74316001)(81686001)(76576001)(76796001)(76786001)(77982001)(65816001)(66066001)(2201001)(56816005)(90146001)(80022001)(74876001)(74706001)(83072002)(85852003)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB592; H:BL2PR03MB290.namprd03.prod.outlook.com; CLIP:81.155.215.86; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/uta/tr0IUY81M1Q6tu8b4bAHzhZIqvU
Cc: "uta@ietf.org" <uta@ietf.org>
Subject: [Uta] Email over TLS drafts
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Sun, 23 Feb 2014 22:47:33 -0000

Dear authors,
In preparation for the London meeting, a few questions/comments about the email drafts:

First, both drafts address the interface between MUA and MSA only, correct? It would be interesting to show (in the presentation), what the situation looks like for other email interfaces (e.g., between MTAs).

draft-newman-email-deep-01

- I think that merging the two drafts was the right move. It allows readers to see the whole range of techniques for consideration. That being said, the draft includes both (1) suggestions for preferred methods of operation based on existing standards and (2) new mechanisms to enhance privacy when email protocols are secured by TLS.  Would you consider discussing  the two categories using parallel tracks (drafts) in order to streamline the work?

- I am curious why the proposed latch mechanism (defined and used in sections 4, 6, and 7) has been considered for email applications specifically. I understand that you need some kind of an "application" or "signalling" or "management" protocol to implement the mechanism, but potentially it could be a common one to serve any application. This question seems especially applicable to the latches' definitions themselves. 

draft-melnikov-email-tls-certs-01

This draft seems to specify the preferred methods of operation based on existing standards. It would helpful to show (in presentation and in the document) which of the recommendations are about putting constraints on the existing standard vs. what statements are real changes to the standard and thus require replacing sections in the existing RFC.

Are any of the suggested recommendations in this draft would apply to applications other than email?

Thanks and looking forward to your presentations in London,
Orit.