Re: [TLS] I-D: CipherSuites for Kerberos + DH

Benjamin Kaduk <bkaduk@akamai.com> Mon, 12 October 2015 22:53 UTC

Return-Path: <bkaduk@akamai.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 1C0781B2B69 for <tls@ietfa.amsl.com>; Mon, 12 Oct 2015 15:53:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.796
X-Spam-Level:
X-Spam-Status: No, score=0.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 rl1qadHfOLs6 for <tls@ietfa.amsl.com>; Mon, 12 Oct 2015 15:53:49 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (unknown [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 928261B2B68 for <tls@ietf.org>; Mon, 12 Oct 2015 15:53:49 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 64E2E433427 for <tls@ietf.org>; Mon, 12 Oct 2015 22:53:48 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 4EE78433419 for <tls@ietf.org>; Mon, 12 Oct 2015 22:53:48 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1444690428; bh=cdsrOB2vKtXclN/lZeR/x9H6/qIf13UWE9ELvv4O2UE=; l=2056; h=References:To:From:Date:In-Reply-To:From; b=Es3OUiZ8BCrnGuKOstsrIjzSdg2kvvl9bt9X/OXamZ2e15wqKQB5g8vZgGn9jn3rO Ndj5Ti3gqiPSh+h4JdIF3NIxhda/5OLZESpw4/xv4qFwvpFzEVjVfTcy8wmsE67h+O XuNufPvR34TdxBLjYN62CM0myw1EoWwwWOMwpK8w=
Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 2F2F82027 for <tls@ietf.org>; Mon, 12 Oct 2015 22:53:48 +0000 (GMT)
References: <561A0ED6.1000505@openfortress.nl> <20151011121701.GA26616@LK-Perkele-V2.elisa-laajakaista.fi> <CACsn0c=0dFpaRyiSsErVg_2cuco6M8mMgMS3YHLpxYEuH_82kw@mail.gmail.com>
To: tls@ietf.org
From: Benjamin Kaduk <bkaduk@akamai.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <561C39FB.6060206@akamai.com>
Date: Mon, 12 Oct 2015 17:53:47 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <CACsn0c=0dFpaRyiSsErVg_2cuco6M8mMgMS3YHLpxYEuH_82kw@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Ml1Zlo5B9T3nho0ORLrii2hXvok>
Subject: Re: [TLS] I-D: CipherSuites for Kerberos + DH
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: <https://mailarchive.ietf.org/arch/browse/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, 12 Oct 2015 22:53:51 -0000

On 10/11/2015 08:46 AM, Watson Ladd wrote:
> On Sun, Oct 11, 2015 at 8:17 AM, Ilari Liusvaara
> <ilariliusvaara@welho.com> wrote:
>> Some quick comments:
>> - The signed DH share does not look to be bound to anything (crypto
>>   parameters negotiation, randoms, server key exchange, etc..). I can't
>>   offhand say what that would lead to, but it looks even worse than
>>   TLS ServerKeyExchange, which has known vulernabilities due to
>>   lack of binding to things like ciphersuite.
>> - The ciphersuite list looks bad: 1) IDEA (bad idea), CBC
>>   (don't use), apparent SHA-1 prf-hash (REALLY bad idea)[1][2].
>> - Even use of DH is questionable.
> I would suggest piggybacking on the PSK mode, using the key Kerberos
> provides at both ends as the PSK key. This would address all of these
> issues in TLS 1.3
>

This would seem to require an application protocol doing some Kerberos
exchanges up front to establish the Kerberos session key before pivoting
into TLS-PSK in a STARTLS-esque fashion.  If that's what the application
protocol would look like, it seems like there's no reason not to go
full-on GSSAPI with GSS_Pseudo_random to extract a PSK on both sides.

This proposal (as complicated as it is, and I'm not sure that I'm
entirely comfortable with it yet) has the comparative advantage that the
application speaks TLS from the start, with the Kerberos messages
included in the TLS CKE.  In that sense, at least, it is elegant.

This proposal also includes a generic mechanism for the server to
indicate what service type and hostname should be used in constructing
the host-based service principal name for Kerberos, which is useful --
the convention for that would otherwise have to be baked into the
application protocol.  The considerations around client anonymity and a
protocol for the server to convey its expectations are also interesting,
though I'm not sure I would have put it in the -00 if it was my own
document.

There are some nits in the Kerberos bits that I might mention over on
kitten.

-Ben