Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate?

Martin Thomson <martin.thomson@gmail.com> Tue, 12 July 2016 01:13 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D179712D6B3 for <tls@ietfa.amsl.com>; Mon, 11 Jul 2016 18:13:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 jZgc6vx6Uc_3 for <tls@ietfa.amsl.com>; Mon, 11 Jul 2016 18:13:09 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 ECB7D12D735 for <tls@ietf.org>; Mon, 11 Jul 2016 18:13:08 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id 82so1100452qko.3 for <tls@ietf.org>; Mon, 11 Jul 2016 18:13:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0EgxkXLMK3t3I0Hg6yEopt3N75Y+7aiJfWf0nLqWuO8=; b=xYEbB2285S1ahOxGsZ/IIs9PVwbyM3KioXoxB8Dz7lnJL6Hd4q5Q0JM25r/uSZ6z4+ 44mPtr7+PZdA/ArrmJoVeeSb99Y/fJn6p9II9eD3bXjYjgbPidw3ulJ34oMEpT96AfGb d6kMZnhzIY29rZZWiLyn5vQJJWIttdyheo9d5pigKlL5Iq18ilqjFSockhuJ55bhCbAh BXgtHFYgdIR53gE0yWFNjdn+huQ42GgX1ItcI1NAGlqaTnXSJ+3bxshBfoh5wyctJIxg w9rFSsmwDkw9ZcYjwSYzmTyXhEua0U2qeDwRXApz6uHBVAk4t7jUd/altTnwtlnDyB5c 6Qbw==
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-transfer-encoding; bh=0EgxkXLMK3t3I0Hg6yEopt3N75Y+7aiJfWf0nLqWuO8=; b=E/QTAbRIp2ViWwn585rj9x5PVJRm6sITezVl9aq3T7aseXCOdwK2tBkGaYlha/TL9q wjkNhTeRKX1tJ6bGn9WzQSurGDE4kkbysxc6nRkOb62lLTmizsAQ6akcFOgTmXSNqvNy 3AhYxaLDSzkW1YeT06D0SuoBKdBJzYdubcnjQ2PHTc1oEOfsPy/qQ9+TVQ3TFqCcFeV1 hYKZFndkGMEt1ysYGy23Wy/oaP4ea7cLYo9d/sfeUJfPYJvM8gj3Wfac0LSO08MZgZqO 2k3xPXjLwnlde7J8veyhuFsHqjhY2NOzV5QBThOw36xiqMf9aSSWiiRs4+WugmnbJz3S i6ww==
X-Gm-Message-State: ALyK8tLiPyA14Kc82jXHI3tM1UIGqcqRGsweJa4xLt17l/PP+7NrtGJXfxC1xhjUgvzAqeIC9L9sVUWYR/CSpw==
X-Received: by 10.55.214.77 with SMTP id t74mr29748341qki.80.1468285988007; Mon, 11 Jul 2016 18:13:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.22.38 with HTTP; Mon, 11 Jul 2016 18:13:07 -0700 (PDT)
In-Reply-To: <C6FAB38B-FF5A-43D3-A0DB-554FAF23ED92@gmail.com>
References: <C6FAB38B-FF5A-43D3-A0DB-554FAF23ED92@gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 12 Jul 2016 11:13:07 +1000
Message-ID: <CABkgnnXjoQnAmsUBnU1MjF5cotFCRYF9VHUayv3K9xD+dN1QUQ@mail.gmail.com>
To: Douglas Stebila <dstebila@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Lvf3Pw1vBVp21hdVpvo67A8kTXw>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 12 Jul 2016 01:13:11 -0000

Not taking any position on the question, which I think is a fine thing
to ask, but...

I'd just like to point out that the example is flawed in the sense
that the system permits both users to share state.  When Alice logs
out, that needs to include any state that might have been accumulated
to Alice.  This necessarily includes any sessions, including that TLS
connection.

If we imagine that this is a browser, then you also need to flush
caches and remove cookies before the system is usable by another user.
There might be operating system level things as well.  Machines in
internet cafes often create temporary accounts, or even rebuild the
entire machine between users for this reason.

Back to the question...
One challenge with this is that exporters are often used to compare
things.  For instance, one side signs an exported value, the other
validates the signature by independently exporting the same value.
Getting different values for a particular exporter will cause some
classes of things to fail in subtle ways.


On 12 July 2016 at 05:39, Douglas Stebila <dstebila@gmail.com> wrote:
> Some of the discussions I've had with people about post-handshake client authentication have raised the question of whether application traffic secrets should be updated automatically upon post-handshake client authentication: the thinking being that every change in context should be accompanied by a change in keying material.  I used to think that was a good idea for TLS 1.3, although it was recently argued to me that if we view the application traffic secrets as being "internal" to the TLS protocol, then the change in client authentication status doesn't change the confidential or integrity properties of the record layer, it just serves as a "marker" to the application that certain portions of the application data were associated with certain authentication contexts.  I was convinced that this can be safely accomplished without a change in application traffic secret key material.
>
> But I'm not sure that the same applies to *exporter* keys.  Should exported keying material change as the authentication context changes?
>
> Consider a long-lived TLS connection, where different users come and go.  For example, a web browser on a public terminal may have established a long-lived TLS connection to a particular website, and send subsequent requests to the same website over the same TLS connection.  Now imagine two users use the terminal one after another:
>
> 1: initial handshake on a public terminal
> 2: [time passes]
> 3: Alice starts browsing
> 4: Alice does post-handshake client authentication
> 5: Alice purchases something
> 6: Alice hits "logout" at the application layer
> 7: [time passes]
> 8: Bob starts using the terminal
> 9: Bob does post-handshake client authentication
> 10: Bob purchases something
> 11: Bob hits "logout" at the application layer
>
> TLS 1.3 will tell the application about events 4 and 9.  Events 6 and 11 happen at the application layer rather than the TLS layer (since I don't think TLS 1.3 has a client-de-authentication option).  But putting this all together, the application will learn all the correct authentication contexts: 1-3 is anonymous, 4-5 is Alice, 6-8 is anonymous, 9-10 is Bob, 11-onwards is anonymous.
>
> Now imagine that we use keying material exporters in on lines 5 and 10:
>
> 1: initial handshake on a public terminal
> 2: [time passes]
> 3: Alice starts browsing
> 4: Alice does post-handshake client authentication
> *5: Alice presses the "export keying material" button
> 6: Alice hits "logout" at the application layer
> 7: [time passes]
> 8: Bob starts using the terminal
> 9: Bob does post-handshake client authentication
> *10: Bob presses the "export keying material" button
> 11: Bob hits "logout" at the application layer
>
> Since the exporter master secret is not updated when client authentication changes, Alice and Bob will export the same keying material at steps 5 and 10.  If the intended goal of this exported key is for Alice to obtain confidentiality in some other use, this will not be achieved, since Bob will obtain the same exported key.
>
> Now, a proviso is that RFC 5705 allows for the application to mix a "context value" into the export, which could mitigate this, but that is optional.
>
> So it seems to me like in at least some scenarios, exported keying material should be associated with authentication context.  It is less clear to me if the same holds true for KeyUpdates.
>
> Douglas
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls