Re: [TLS] Pull request for session hash

Eric Rescorla <ekr@rtfm.com> Wed, 24 December 2014 21:04 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 6C1DF1A1AD2 for <tls@ietfa.amsl.com>; Wed, 24 Dec 2014 13:04:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 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] 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 QkAS-jlxJP_6 for <tls@ietfa.amsl.com>; Wed, 24 Dec 2014 13:04:26 -0800 (PST)
Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF9891A1A91 for <tls@ietf.org>; Wed, 24 Dec 2014 13:04:25 -0800 (PST)
Received: by mail-wg0-f52.google.com with SMTP id x12so11923650wgg.25 for <tls@ietf.org>; Wed, 24 Dec 2014 13:04:24 -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=ikoJK0rH16qg0jf0DLE5/qUpHbrxpM2qEeNg1afq1zI=; b=Ur446PyQmNCKyBtpqf8kHpqcAICIcaEdee7g8g1av+RrfDwndSFXz4IHJJ1thI3ZXI OGdCYf4o+bbEX+qVXv7dqJQ9zQMxYWSLSM4JLxJxTBHalnAJ0MnCqDjH29xHX2SNCPnv YdYxkbsIybsJy0IPEwLhcNekGSOf7MCsi3X7/x//Oz0XznceKMuAGPUkn+evELQht5fT 8wtMM3oCnsXMJZrZKervI9MaLqNcssesMKFkfs6vKhuuHNXpd2mJq19LVzXeicVJFLil sHpKifgPsy1NVQGeXfDzs1+scjpB3k1hu6Kpx7l57aCFXtErEaUX/nilh7jkDbM6L0V+ AJQw==
X-Gm-Message-State: ALoCoQm/WxaImXQ6wrl93WxdAZ6JLbVQIsTuRFcMsPrlLELi57ie/ANHP625rK7oRrs1tclVURS8
X-Received: by 10.180.198.164 with SMTP id jd4mr53937672wic.42.1419455064751; Wed, 24 Dec 2014 13:04:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.130.34 with HTTP; Wed, 24 Dec 2014 13:03:44 -0800 (PST)
In-Reply-To: <CACsn0cn0fV7_8dPtpQwi7j+x2jRt8wxpM-Ms+axES3EAMW_bVg@mail.gmail.com>
References: <CABcZeBNj2n-UM-qwVH8PSV+7MgS6kNxzqQZ20J3DtfZ8tLg9-Q@mail.gmail.com> <CABcZeBM9BonSs0PUF4BvRvRQ7L3-TL7n-XLGm_AtDypbWj3a5w@mail.gmail.com> <20141223142648.GA11149@LK-Perkele-VII> <CABcZeBOLOw3Dx6iADsEgpKP0DA-z4oss7gdrWG5WxQKx5qY43w@mail.gmail.com> <CACsn0cn0fV7_8dPtpQwi7j+x2jRt8wxpM-Ms+axES3EAMW_bVg@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 24 Dec 2014 13:03:44 -0800
Message-ID: <CABcZeBOsLk+nyRFnmc9k_xK4BDdom-RzR1agAteZ=B_Cg0nN6Q@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b604706e8d6cc050afca29d
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DcpKQaUd4Yu2yY9-CASSxHs3cc4
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Pull request for session hash
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: Wed, 24 Dec 2014 21:04:28 -0000

On Wed, Dec 24, 2014 at 11:21 AM, Watson Ladd <watsonbladd@gmail.com>; wrote:

> On Wed, Dec 24, 2014 at 1:29 PM, Eric Rescorla <ekr@rtfm.com>; wrote
> >
> >> That would stop applications from exporting important system keys.
> >
> >
> > I suggested that, but  upon reconsideration it seemed a bit
> > over-complicated. What's the threat model you have in mind
> > here?
>
> Application authors shouldn't depend on magic details for their
> applications to be secure. So long as the exporter is capable of
> generating keys used to encrypt or authenticate data, the application
> author has to ensure that they don't accidentally do that. By making
> it impossible to mess up, we make the application author's job easier.
>
> I'm strongly in favor of making it easy to make secure systems.


It seems like the underlying desire is for separation between keys
and exporters, right? I know MSJ has asked for context separation
to make things more compatible with HSMs. Would that solve the
issue here as well, without creating a new MS?



>> "If the server does not request client authentication, the master
> >> secret can be computed at the time that the server sends its Finished,
> >> thus allowing the server to send traffic on its first flight (see
> >> [TODO] for security considerations on this practice.) If the server
> >> requests client authentication, this secret can be computed after the
> >> client's Certificate and CertificateVerify have been sent, or, if the
> >> client refuses client authentication, after the client's empty
> >> Certificate message has been sent."
> >>
> >> Server can't send data on first flight (to anonymous recipient) if
> >> it requests client authentication? E.g. HTTP/2 settings blocks,
> >> protocol banners or various other protocol capability negotiations.
> >
> >
> > That's correct. This is obviously not ideal but the alternative with this
> > design is to have an even more complicated key schedule. The idea
> > behind PR 95 (https://github.com/tlswg/tls13-spec/pull/95) is to
> > address this, though that's of course not the only way. What are
> > your thoughts here?
>
> I think we can deal with a more complicated implementation, so long as
> exposing the feature isn't that complicated. Transporting data ahead
> of checking who the person is that it is being sent to is very simple
> to expose: a function to accept data and send it, and one to check if
> the authentication is complete and who it is. Applications that can't
> meaningfully deal with this can be written as normal. But I'm still
> thinking about the right way to do this


See also the PR I point to above for an alternative protocol-level
implementation
of this.

-Ekr