[TLS] Directly signing randoms

Eric Rescorla <ekr@rtfm.com> Mon, 19 October 2015 16:09 UTC

MIME-Version: 1.0
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 19 Oct 2015 09:08:55 -0700
Message-ID: <CABcZeBOFma78=bjqxCXMLPMqLes0oFAbPTgeJODwukPnPLD0nQ@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a1149198807f56a0522775f78"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/764YDOxf--8ULB5Ia3zh8Mnmfl0>
Subject: [TLS] Directly signing randoms
Precedence: list

Folks,

https://github.com/tlswg/tls13-spec/issues/224

At the interim we discussed whether it was worth having digital
signatures explicitly include the client and server random values
rather than just the transcript to enable privilege separation, as
proposed by Nikos. We had a little trouble getting clarity on the
desired use case, but the two we understood were:

1. Having a separate module which is signing for authentication
   and wants to explicitly provide a random value to ensure
   that it's not signing arbitrary data.

2. Having a separate module which is verifying the peer's authentication
   and wants to explicitly provide a challenge to be signed by the
   peer.

The general feeling was that you could achieve both cases by simply
the unprivileged portion of the system provide the module with the
handshake transcript and allow it to verify that the random
was present in the correct location (or at all in case #2) and so
that no change was needed.

As I said, there was some confusion on the exact scenario, so if
I've misunderstood please clarify. Otherwise, I think we have
consensus to close this as WONTFIX.

-Ekr

[TLS] Directly signing randoms Eric Rescorla