Re: [TLS] Refactoring client auth/re-key

Watson Ladd <watsonbladd@gmail.com> Sat, 18 October 2014 21:56 UTC

Return-Path: <watsonbladd@gmail.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 A46241A1B27 for <tls@ietfa.amsl.com>; Sat, 18 Oct 2014 14:56:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeCCdKKcBOaZ for <tls@ietfa.amsl.com>; Sat, 18 Oct 2014 14:56:00 -0700 (PDT)
Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6E421A1B34 for <tls@ietf.org>; Sat, 18 Oct 2014 14:56:00 -0700 (PDT)
Received: by mail-yk0-f170.google.com with SMTP id 20so1229384yks.1 for <tls@ietf.org>; Sat, 18 Oct 2014 14:56:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uxozVz264jYRFC0LOxobOGy2xdch6lurmA/h+BqEk6c=; b=KSr7hbgHO9u8IyMrtdFLcq5woURIBAxgwN+9oD4fbVIo2mtAcUJO2b3Sj98KUmUHm4 bvQhEWLW/LwuCAYbMTiW9dmlLrCaKEojSCB1llFsLcDGRYSmfUqWV65inH8/P6ArEMMp ZeMFvOfhvnmOe55dpo0/MOiWmlyXvIOr3G3giN6cXVx6lh3+2muY4369IckcsZW28yYj kuVXm2DxoELTmrVB7Dqv6FHCNzGzRvotU10OXIDgcnP1MyteHpWryBQJPtz5IfTUxg4+ K8dJ4aqsIx8hMEQzRDwcO7ghurk5jHnhFA41M638/eZdwnG+XUoTFl0I9zaNqP1uW+YU YO7A==
MIME-Version: 1.0
X-Received: by 10.236.45.7 with SMTP id o7mr46046yhb.169.1413669359875; Sat, 18 Oct 2014 14:55:59 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Sat, 18 Oct 2014 14:55:59 -0700 (PDT)
In-Reply-To: <CABcZeBMxw3Oz1U-6GeTAuUJ1bZbBYhRWsQgscrHFLcTHh=_H1g@mail.gmail.com>
References: <CABcZeBOdpK_JEH4EwnsoTA8Rje5pS5CtSbFGh8rHQzse92m9Wg@mail.gmail.com> <CACsn0cmYs8TMeKcTvqxv1DUGizcp5k7uo86muoqYbGRH4xDQHA@mail.gmail.com> <CABcZeBMxw3Oz1U-6GeTAuUJ1bZbBYhRWsQgscrHFLcTHh=_H1g@mail.gmail.com>
Date: Sat, 18 Oct 2014 14:55:59 -0700
Message-ID: <CACsn0ckZhXdwtLxt7v1ZeYixTJcf0WVA=MMQySvae7mZ__0m-w@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9HIgtWXyxjo4wAZVt_rRp59pgP8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Refactoring client auth/re-key
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: Sat, 18 Oct 2014 21:56:02 -0000

On Sat, Oct 18, 2014 at 9:10 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> Watson,
>
> Thanks for your comments.
>
> On Sat, Oct 18, 2014 at 4:15 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
>>
>> On Sat, Oct 18, 2014 at 7:32 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>> >
>> So I seem to remember DJB telling me that once you have a properly
>> made channel via Diffie-Hellman, that authenticating requires just
>> signing a value derived from the key. (Sadly I forgot/don't know the
>> proof, so someone will have to check this or tell me I'm completely
>> wrong) So we don't need the session hash to include the certificates,
>> and so don't need to keep the running hash going past the first
>> exchange.
>>
>> Concretely the idea would be as follows: A sends to B g^x, and B
>> responds with g^y. Both calculate MS=H(g^xy, g^x, g^y). (Of course, we
>> need to hash the actual messages.)
>>
>> At this point we can compute channel_AtoB_key=PRF(MS, "channel AtoB
>> key"),  channel_BtoA_key=PRF(MS, "channel BtoA key"),
>> A_authstr=PRF(MS, "A authstr"), B_authstr=PRF(MS, "B authstr"). The
>> channel keys can be used to encrypt each side as in the proposal, and
>> the authstrs can be signed and sent over the channel to provide a
>> proof of identity.
>
>
>
> Trying to think through this a bit, is this a generic comment on the
> session-hash proposal even for TLS 1.2 where they are careful to
> sign everything up to CertificateVerify? See:
>
> https://tools.ietf.org/html/draft-ietf-tls-session-hash-02#section-4.1

That struck me as an implementation driven decision, since
implementations keep a running hash for the Finished message, which is
repurposed in the session hash proposal. Furthermore, what I  proposed
only works because we are sending the identities over a secure
channel: otherwise an attacker could remove the client authentication
and replace it with their own, thus causing both sides to disagree
over what the authentication status is.

The session hash was designed to be as minor a change as possible to
TLS 1.2. I've got no interest in mixing security improvements with
massive changes, as that slows adoption big time. While you could make
a similar change to TLS 1.2, it would be unnecessarily large.

My only other comment is that this is a much larger change than
1.1->1.2. Perhaps we really should be honest and call it TLS 2.0.

Sincerely,
Watson Ladd
>
> Perhaps one of the authors of that document can weigh in here.
>
> Best,
> -Ekr
>
>
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin