Re: [TLS] OPTLS: Signature-less TLS 1.3

Eric Rescorla <ekr@rtfm.com> Sun, 02 November 2014 22:41 UTC

Return-Path: <ekr@rtfm.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 87FCC1A1A3F for <tls@ietfa.amsl.com>; Sun, 2 Nov 2014 14:41:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level:
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 OCLtpCjlcIbh for <tls@ietfa.amsl.com>; Sun, 2 Nov 2014 14:41:56 -0800 (PST)
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C19291A0687 for <tls@ietf.org>; Sun, 2 Nov 2014 14:41:55 -0800 (PST)
Received: by mail-wi0-f173.google.com with SMTP id n3so5097242wiv.0 for <tls@ietf.org>; Sun, 02 Nov 2014 14:41:54 -0800 (PST)
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:from:date :message-id:subject:to:cc:content-type; bh=lT5lRV35l73Nli92MdoxZI1PZ5YuZxZk/JptJFxJ1Vc=; b=EwJev9iV7GPzYt07zpUtkC6FArMMsgnqZ5j/Bp61q4dMBtjy3z/m0UOW1AsymlTo6o RgLNixfz9EmsscAh+ru3wnHkI1AsExJ5Cd5LDRYjVuZWc9b34RjOnhmCYctl8045inMY OE9mf+gjfHU51Bgw5VpznDv9o0M64SXZ+z3YORgDqQ0ahObFt3alP6ASf2KoQBvl6Hv6 7AAPdW6g2Hd++KgNvOzFKjgQTGDzfIx/jQeHq39hyzBNVmPHWv/ph5txHpqoLDlr7NXn XLVsJ04JE3AlvpET6ED6q4opIQVFkg/mYg6BXjarmXZery6H5QDyvJO1MJJmvepId8UY hrqg==
X-Gm-Message-State: ALoCoQlVYybLy9CaiRpWfeXO12KF4K0Wd2U6gaU2nCl922pp3nOdlKC5KsjQSwDFpp/b6BVai862
X-Received: by 10.194.119.193 with SMTP id kw1mr44080023wjb.37.1414968114379; Sun, 02 Nov 2014 14:41:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.49.198 with HTTP; Sun, 2 Nov 2014 14:41:14 -0800 (PST)
In-Reply-To: <CADi0yUO+wobcn0NHGc3-avzMBwTwUjbvSGk8aEmdrCC8d0bEMQ@mail.gmail.com>
References: <CADi0yUObKsTvF6bP=SxAwYA05odyWdzR1-sWutrDLUeu+VJ1KQ@mail.gmail.com> <614363650.3172177.1414834861225.JavaMail.zimbra@redhat.com> <CADi0yUO+wobcn0NHGc3-avzMBwTwUjbvSGk8aEmdrCC8d0bEMQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 02 Nov 2014 14:41:14 -0800
Message-ID: <CABcZeBM9-w9sHYMVgc43tctWsfj8T++ey=bh=JBFBH28twxZDQ@mail.gmail.com>
To: Hugo Krawczyk <hugo@ee.technion.ac.il>
Content-Type: multipart/alternative; boundary="089e01228626d3b0860506e7ef57"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SyDcmqvpU6jzBXSRT8P_Lmzurww
Cc: "tls@ietf.org" <tls@ietf.org>, Hoeteck Wee <hoeteck@alum.mit.edu>
Subject: Re: [TLS] OPTLS: Signature-less TLS 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: Sun, 02 Nov 2014 22:41:58 -0000

On Sun, Nov 2, 2014 at 2:28 PM, Hugo Krawczyk <hugo@ee.technion.ac.il>
wrote:

> The issues regarding group matching (and mis-matching) raised here and
> discussed
> in other messages are indeed very important. In the case of server-only
> authentication this reduces to the client guessing the right g^x and thus
> requires dealing with wrong guesses (this only applies to the 1-RTT case
> as in
> the 0-RTT case the client learns the group together with the server's
> static
> key g^s). In the mutual authentication case, if server and client cannot
> agree
> on using the same group for authentication, then the client would need to
> choose its g^x in the server's group while authentication by the client
> would
> require the server to send an additional ServerKeyShare in the client's
> group.
> Note, however, that in the use case where the parties have certificates for
> signature keys and they sign their own static DH key, clients and servers
> can
> possess static DH keys in different groups (without requiring a CA-issued
> certificate for each such group), hence more easily support the peer's
> group.
>

I believe the latter is the case we should optimize for, as existing
systems which
do client auth generally use signatures and so it's easier to continue to
assume
that then to expect that clients will get all-new certs. This seems like a
natural
extension of the reasoning which motivates the server signing their g^s in
your
proposal.

-Ekr

Hugo
>
>
>
> On Sat, Nov 1, 2014 at 11:41 AM, Nikos Mavrogiannopoulos <nmav@redhat.com>
> wrote:
>
>> ----- Original Message -----
>> > During the TLS interim meeting of last week (Oct 22 2014) I suggested
>> that
>> > TLS
>> > 1.3 should abandon signature-based authentication (other than for
>> > certificates)
>> > and be based solely on a combination of ephemeral Diffie-Hellman for
>> PFS and
>> > static Diffie-Hellman for authentication. This has multiple benefits
>> > including
>> > major performance gain (by replacing the per-handshake RSA signature by
>> the
>> > server with a much cheaper elliptic curve exponentiation), compatibility
>> > with
>> > the mechanisms required for forward secrecy, natural accommodation of a
>> > 0-RTT
>> > option, and a simple extension without signatures for client
>> authentication.
>>
>> That effectively deprecates all existing infrastructure used for TLS that
>> pretty
>> much only works with RSA and ECDSA certificates (from smart cards, to
>> HSMs and
>> acceleration hardware). That's not necessarily bad, and we may already be
>> past the
>> point where TLS 1.3 can be considered a minor revision of TLS 1.2.
>>
>> > PROTOCOL OPTLS:
>> >
>> > ClientHello
>> > ClientKeyShare
>> > ClientData* [K0]       -------->
>> >                                            ServerHello
>> >                                            ServerKeyShare
>> >                                            ServerCertificate* [K1]
>> >                                            ServerFinished [K2]
>> >                        <--------           ServerData* [K2]
>> > ClientFinished* [K2]   -------->
>> >
>> >
>> >             Protected Application Data [K3]
>> >                        <------->
>> > 1-RTT CASE:
>> >
>> > The basic 1-RTT case omits the ClientData* field. It includes a
>> > ClientKeyShare
>> > g^x and a ServerKeyShare g^y and an optional (encrypted) server
>> > certificate.
>> > If the certificate is sent (it can be omitted if the client has
>> indicated
>> > that
>> > it knows the server key as in the case in the 0-RTT scenario) and is
>> > encrypted,
>> > the encryption key K1 is derived from g^{xy}.
>> >
>> > Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is
>> used
>> > to
>> > authenticate-encrypt the ServerFinished and ClientFinished messages
>> (which
>> > include a hash of the previous traffic) and to encrypt data from the
>> server
>> > if
>> > such data is piggybacked to the second message.
>>
>> How does the client get the DH (or ECDH) group parameters used by the
>> server?
>>
>> > CLIENT AUTHENTICATION:
>> >
>> > Client authentication can be supported via an option or extension. It
>> would
>> > include a client certificate for a static DH key g^c sent in the third
>> > message
>> > (the certificate can be encrypted under key K2 to provide client's
>> identity
>> > protection). In this case, the key for computing the ClientFinished
>> message
>> > and
>> > the application key K3 would be derived from a combination of the values
>> > g^xy,
>> > g^xs, g^yc (and possibly also g^{cs}).
>>
>> As I understand client authentication as above would only work if both
>> the client
>> and the server share the same DH/ECDH group for their certificates, and
>> that cannot
>> be assumed to be true on an infrastructure that is designed to upgrade
>> (e.g., change
>> client certs from secp192r1 to secp256r1).
>>
>> regards,
>> Nikos
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>