Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

Nico Williams <> Fri, 17 April 2015 21:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A2FDB1B3070 for <>; Fri, 17 Apr 2015 14:57:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jUa6YKkjMemc for <>; Fri, 17 Apr 2015 14:57:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D61171B306D for <>; Fri, 17 Apr 2015 14:57:27 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 970032C807A; Fri, 17 Apr 2015 14:57:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=2r+VONeVV+USU5 qemQ6XaSq0gMc=; b=MC5m3RMKIWx58yr9oUmjTVHcVX3TdTaMcig9ZnUL+A68qS YjkJQp1FAdH+iFdzKkaos5levlzoG+BeXToSaLjKcTEDYQLKiC/FPwNRrO6MWIV/ AHkZas7acna8JxFkjq3ejXdUwJculphW2H/z/BB+JkhOSR5LfHDTJpteRCTxg=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id 5051D2C806C; Fri, 17 Apr 2015 14:57:27 -0700 (PDT)
Date: Fri, 17 Apr 2015 16:57:26 -0500
From: Nico Williams <>
To: Benjamin Kaduk <kaduk@MIT.EDU>
Message-ID: <20150417215725.GL13041@localhost>
References: <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Apr 2015 21:57:28 -0000

On Fri, Apr 17, 2015 at 03:43:52PM -0400, Benjamin Kaduk wrote:
> On Thu, 9 Apr 2015, Jeffrey Altman wrote:
> > Due to BCP 179 / RFC 6649 and draft-kaduk-kitten-des-des-des-die-die-die
> > the Kerberos protocol is left with two related AES*-CTS-SHA1 encryption
> > types for RFC 3961 based protocols.  Regardless of what track this
> > document is placed on it is going to be widely and rapidly deployed.  As
> > a result it is important that the working group ensure that the
> > encryption type is correct and that independent implementations for the
> > most widely used Kerberos implementations are available and are
> > demonstrated to be interoperable.
> I don't share your confidence that this particular enctype is going to be
> widely and rapidly deployed.  I agree with the sentiment that we should
> have something other than enctypes 17 and 18, but it is not necessarily
> clear that this would be it.  There might be more excitement for something
> other than AES; I don't know.  We certainly don't have people coming to us
> (MIT krb5) and clamoring for this exact enctype...

We're definitely in shape to *add* enctypes now.  Interop issues from
dealing with 3DES and RC4 have shaken out the sorts of bugs that would
make adding new enctypes difficult.

The fact that these enctypes are simple variants on the existing ones
should help get implementations, should anyone need them.

I think there will be sites that need to move away from SHA-1, even if
HMAC-SHA-1 remains secure (which I'm not saying it does).

That said, I don't think these enctypes will generate much interest
beyond moving beyond SHA-1.  As with TLS, ideally we should add new
enctypes based on ciphers other than AES in addition to the AES ones.
For Kerberos this is much harder than for TLS due to the fact that a)
AEAD ciphers/cipher modes are all the rage now, b) RFC3961 is not
AEAD-friendly, c) if we're to use AEAD ciphermodes then we need ones
which don't require stateful nodes (i.e., which don't fall apart because
of (key, IV) reuse).  There's a relevant thread on CFRG about this right