Re: [TLS] DSA should die

Joseph Salowey <joe@salowey.net> Thu, 02 April 2015 21:31 UTC

Return-Path: <joe@salowey.net>
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 7A5C21A6EF4 for <tls@ietfa.amsl.com>; Thu, 2 Apr 2015 14:31:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 kMcT3b4s5VZ0 for <tls@ietfa.amsl.com>; Thu, 2 Apr 2015 14:31:39 -0700 (PDT)
Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (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 4C5A91A6EFC for <tls@ietf.org>; Thu, 2 Apr 2015 14:31:39 -0700 (PDT)
Received: by qgep97 with SMTP id p97so80671578qge.1 for <tls@ietf.org>; Thu, 02 Apr 2015 14:31:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=M3N4bu+nnB9DBVdTIc3IXIM0ACxazVE0avEEGC7j1yQ=; b=Ta2/JsPrqJcP92HcOHKAawd1EDpmZV/1248b5rC2js1r7twM38BCpVhvx4QYZqo0Ot DB2x9T5ZLqqAJnB6KviK/39zEksMMKvTjeEXjMn/7DS2xqTBX9qBOoAPco9BSRf8GEeo hYQm7LNMxG2EZRKL7IQg+18jsl74qObOCoUVdFiz/Nx6uthUf5Yj6n7IF8+xpLjYO61l Jie1ZXqe/EIpOcTsslGI9vW3L1e2efF2fKvjurdvZ+7iWG16k3jvZhdMMTCxlowd8iS+ xe9GMDT025NEgnpIFEmiHzYxV14IyfI4sYo9XtPkIemEDsUYZCG9AUYOHuSCgpVIj19Q bu+g==
X-Gm-Message-State: ALoCoQlTQjHsDJObj6LlFzus9GijcDHxdbnoAoBKftBp7nbmCLFG56OWg1fIgzk5EHjynrdOWS1J
MIME-Version: 1.0
X-Received: by 10.140.165.198 with SMTP id l189mr66370934qhl.93.1428010298472; Thu, 02 Apr 2015 14:31:38 -0700 (PDT)
Received: by 10.96.121.104 with HTTP; Thu, 2 Apr 2015 14:31:38 -0700 (PDT)
X-Originating-IP: [50.206.82.141]
In-Reply-To: <201504021257.09955.davemgarrett@gmail.com>
References: <20150401201221.163745c2@pc1.fritz.box> <CAK9dnSyKf7AY11h1i1h+SudRc-NmTZE5wC682YKhNsxnfV5ShQ@mail.gmail.com> <CAK3OfOgPbADQ1CvOs=8T7ee6f_T+bi3F6GCdBtxufQpznzYbQA@mail.gmail.com> <201504021257.09955.davemgarrett@gmail.com>
Date: Thu, 2 Apr 2015 14:31:38 -0700
Message-ID: <CAOgPGoDJTcLn4j90wNu=mhCZJnb2WUuAvM5TN6KOO7RdC==qHQ@mail.gmail.com>
From: Joseph Salowey <joe@salowey.net>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: multipart/alternative; boundary=001a1134ee6e9392b70512c48e9f
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/dKUJ0yN_5_N6tnDK5UdqZHUsNDM>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] DSA should die
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: Thu, 02 Apr 2015 21:31:41 -0000

I think I would prefer to break things up between what is needed for the
record protection and what is needed for authentication (of the peer).
The argument has been made on other threads on the list that these are two
separate concerns and I think it would be best to treat each one as a
unit.  I think TLS 1.3 will make this separation a bit more formal
especially with the removal of RSA key transport.

The record layer protection aspect would include things directly involved
in generating and using the encryption keys:

      AEAD Cipher (e.g. AES-GCM) +  Key agreement (e.g. DH)  + KDF/PRF
(HKDF-SHA256)

I'm tempted to throw the groups used in the DH agreement (25519, p-256,etc)
because that way you can make sure you are consistent matching your
algorithm strength between key agreement and encryption.   I could also see
negotiating the group separately to contain the combinatorial possibilities
of allocations, although we may want to warn against some combinations
 It might make sense to tie the KDF into Key agreement and perhaps these
are fixed to the TLS version.

Authentication would include what the handshake uses use for authenticating
the peers.   It seems there are a number of parameters here: signature
algorithm (RSA-PSS-SHA256, PSK MAC, PAKE), certification parameters (cert
types and params), handshake hash (maybe this is set by the KDF above).
The parameterization of authentication mechanisms may be a bit more
complex, but I think we have much of the machinery there already, it just
may need to be tweaked a bit.

Joe







On Thu, Apr 2, 2015 at 9:57 AM, Dave Garrett <davemgarrett@gmail.com> wrote:

> On Thursday, April 02, 2015 12:45:35 pm Nico Williams wrote:
> > On Thu, Apr 2, 2015 at 2:39 AM, CodesInChaos <codesinchaos@gmail.com>
> wrote:
> > > I think full a-la-carte is too complex. But I'm for negotiating the
> > > handshake and symmetric crypto separately. They're already very
> > > loosely coupled and most proposals that introduce/obsolete
> > > ciphersuites are only interested in one of the two sides, with the
> > > other being only an afterthought.
> >
> > That would be a huge improvement over what we have now.
>
> That could be a good middle ground. Just split cipher suites into
> essentially asymmetric & symmetric cipher suites, and put them both in the
> same array. Server just picks one of each for handshake & connection.
>
>
> Dave
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>