Re: [TLS] Signed messages should be prefixed with a NUL-terminated context string.

[Nikos Mavrogiannopoulos <[e-mail]>]

On Mon, 2014-12-01 at 14:28 -0800, Adam Langley wrote:
> On Wed, Nov 26, 2014 at 6:09 AM, Eric Rescorla <[e-mail]> wrote:
> > If someone wants to contribute a PR so that we can have something
> > concrete to look at that would be even better.
> 
> I have submitted a PR for the padding and context-string changes:
> https://github.com/tlswg/tls13-spec/pull/100
> I did not change the CertificateVerify structure in the same commit
> because I'm not quite sure that I follow the reasoning. The
> CertificateVerify implicitly contains the client and server nonce
> because it contains all the preceding handshake messages. What's the
> motivation for duplicating them at the beginning? Is it simply to
> avoid having the opaque signer understand the TLS structure? If so,
> does the padding and context strings that I've just proposed break
> that?

Is this about the comment in
https://www.ietf.org/mail-archive/web/tls/current/msg14764.html ?
If yes, it is unrelated to the context issue. By having an explicit
server random value, a server can delegate the TLS protocol to a worker
process, while he can still verify that the connected peer is the
intended. For that, the server only needs to explicitly set the
server_random data and then verify the client's CertificateVerify
message based on that. That would allow  designs with privilege
separation (e.g., similar to openssh's) to use TLS. Without the explicit
random values, the server would have to receive the whole TLS transcript
and calculate the hash over it.

In short it allows the server or the client to provide a short proof
that they established a session with a particular peer.

regards,
Nikos