[TLS] PRF in 1.3

Dave Garrett <davemgarrett@gmail.com> Mon, 28 July 2014 20:24 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 []) by ietfa.amsl.com (Postfix) with ESMTP id C62A01A00EB for <tls@ietfa.amsl.com>; Mon, 28 Jul 2014 13:24:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3CaeFdmsN2Rd for <tls@ietfa.amsl.com>; Mon, 28 Jul 2014 13:24:15 -0700 (PDT)
Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71EC1B28FE for <tls@ietf.org>; Mon, 28 Jul 2014 13:24:14 -0700 (PDT)
Received: by mail-qg0-f45.google.com with SMTP id f51so9275958qge.18 for <tls@ietf.org>; Mon, 28 Jul 2014 13:24:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=fYBc4JnZX5B53ABxlZBjdRWDEe15DaMDnXX7Fkfu/c4=; b=RU14NmkX7kr/wdsaJB8sFKl/pLIEs+5ih3Ovd9ft7V95nMAdUaBVBMa9I03+rKNyAr PjCHEk3Rrcn5bFq+gREE7gWxKN+xurohI6EytnwLycALAxbYkffVC+PKqkSf379MOw0D Ul4uKl2dS74O12ZAeHFSvmEaFuhj96BDzJs5V97yQlTD1h9Ba6rfNpshzoCdu3AYVk8M txSBBLrqTAR00nKDesq+d3/4FIUMdGVBsrvlusSmxYffXJ56Oyx8WOaCkceabt8cRViA PRBoloefFrM0+I9eEuPEfMit+PuYTmWWNFaVu9+Bfm2s0vilEr1+NtxkSeCj4ejNx6J6 yUsQ==
X-Received: by with SMTP id z5mr64966634qgz.99.1406579052575; Mon, 28 Jul 2014 13:24:12 -0700 (PDT)
Received: from dave-laptop.localnet (pool-72-78-212-218.phlapa.fios.verizon.net. []) by mx.google.com with ESMTPSA id c16sm31339540qae.49.2014. for <tls@ietf.org> (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 28 Jul 2014 13:24:12 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Mon, 28 Jul 2014 16:24:10 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-62-generic-pae; KDE/4.4.5; i686; ; )
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201407281624.10986.davemgarrett@gmail.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eEO2G_81b2vLLyScV2Hdl59vHqc
X-Mailman-Approved-At: Mon, 28 Jul 2014 15:40:40 -0700
Subject: [TLS] PRF in 1.3
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, 28 Jul 2014 20:26:29 -0000


Issue #26 notes complication with the usage of a negotiable PRF. The
current suggestion mentioned was to consider removing PRF
negotiation in favor of SHA-256, calling it "good enough" until the next
protocol version. I agree that this is quite possibly the case, however
I would like to suggest future proofing things a bit. Old versions of TLS
used the strategy of dual hash algorithms "to ensure that
non-catastrophic flaws in one algorithm will not break the overall
protocol" [RFC4346 F.1.5]. TLS 1.1 used MD5+SHA1. For TLS 1.3, I
would like to suggest SHA2-256+SHA3-256 or similar for consideration.
Picking a single combo allows the removal of negotiation, fixing any issues
that causes, provides a simpler spec for this feature, and allows both the
current standard and new SHA functions to be used without having to
rely 100% on either. Adoption rates of new TLS versions are less than
ideal, so future proofing in manners like this that don't add a fantastic
amount of additional complexity seems like an idea worth consideration.

- Dave