IETF Logo Mail Archive

[TLS] MTI policy & practice (Was: Re: Comments on various things on agenda)

Dave Garrett <davemgarrett@gmail.com> Mon, 09 March 2015 20:10 UTC

Return-Path: <davemgarrett@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F731A9245 for <tls@ietfa.amsl.com>; Mon, 9 Mar 2015 13:10:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 fSiv4L25OTUX for <tls@ietfa.amsl.com>; Mon, 9 Mar 2015 13:10:25 -0700 (PDT)
Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (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 7FF1B1AC3CF for <tls@ietf.org>; Mon, 9 Mar 2015 13:10:25 -0700 (PDT)
Received: by qcyl6 with SMTP id l6so11617675qcy.10 for <tls@ietf.org>; Mon, 09 Mar 2015 13:10:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-type:content-transfer-encoding:message-id; bh=V9LpwERPHKPn0M5GacTbanes7fBUDE7L8N6/U20Igr8=; b=oRiFUhQoN5muGmsD5gkop5RsN1Aw0jxDAbmH0Hcm/18y0HLGJyTSHZvjJn20mf7+KW dJ+KSPngO1FmiVeLrmeaVIZZei0vh8ps71RN79S3zTDVRV3jsYBylPC5D2GdYCJskKGZ yz2gFcv0Y3sE9VbeME1NfGyXec+Y/+/eJo0xLxwawexxpD1l2lFppfKcCu9rBMACpuBP 4Z7KIfHs9FkGrngHrK2cR980voesD/Ox3/G6O+0XJgwm+saJuekJcJP2Z2jil+qh104R O4GoWKHZFUX+jW42VUutXS2z7+WhIpYnyNIO7/VaK9lkWQwi5PsozRRbGT6yd333sj9X QmcA==
X-Received: by 10.55.31.83 with SMTP id f80mr12963558qkf.57.1425931824791; Mon, 09 Mar 2015 13:10:24 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id d19sm12216393qhc.42.2015.03.09.13.10.24 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 09 Mar 2015 13:10:24 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org, "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>, Stephen Checkoway <s@pahtak.org>, Eric Rescorla <ekr@rtfm.com>, Aaron Zauner <azet@azet.org>
Date: Mon, 09 Mar 2015 16:10:22 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; )
References: <65D2FD736B6B2B48B2EAD2BD189DC9CC270CA949@LLE2K10-MBX01.mitll.ad.local>
In-Reply-To: <65D2FD736B6B2B48B2EAD2BD189DC9CC270CA949@LLE2K10-MBX01.mitll.ad.local>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201503091610.23008.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/OlKdMBcvu0KIU8DEwZG8cwi1Lzo>
Subject: [TLS] MTI policy & practice (Was: Re: Comments on various things on agenda)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Mar 2015 20:10:27 -0000

On Monday, March 09, 2015 03:27:12 pm Stephen Checkoway wrote:
> On Mar 9, 2015, at 2:19 PM, Dave Garrett <davemgarrett@gmail.com> wrote:
> > Generally specs get exactly one MTI.
> 
> We should reevaluate that. Having a single MTI leads to situations like IMAP's STARTTLS (RFC 3501) which makes RC4 the only MTI.

Honestly, I don't believe the existing policy is unreasonable. If implementers could actually be compelled to implement both, great, but RFCs can get ignored and in practice you could end up with only one... and no interop.

A bigger problem is that just specifying MTI isn't enough in practice. It would be better to have an MTI and a separate MTD (MTI + mandatory to deploy). For example, with RC4 being phased out I've actually got a report from someone who has a host that uses TLS 1.2 but with their MTI suite (AES-CBC) disabled, and only RC4 and Camellia supported. This shouldn't be a thing we have to worry about. If we picked an MTD and an MTI, that would be far more reliable. Both would of course be subject to revision in a future RFC, and it should probably state that up front. (instead of pretending that everything will be fine forever)

So, with this in mind, I'd suggest for TLS 1.3:

MTD: ECDHE ChaCha20/Poly1305 AEAD
MTI: ECDHE AES-GCM (possibly both ECDSA and RSA auth)

Also specifying MTI curves is probably a good idea at this point.


Dave

v2.23.0 | Report a Bug | By Email