Subject: [TLS] PR#837: Forward and backward secrecy

From: "Guballa Jens (ETAS-PSC/ECS)" <[email-masked]>
Date: Wed, 28 Dec 2016 13:11:36 +0000

Hi,

I just created a new pull request (and I just recognized it results in a merge conflict):

https://github.com/tlswg/tls13-spec/pull/837

I think in section "E.2 Record Layer" the terms "forward secrecy" and "backward secrecy" have been mixed up.

My understanding: 
A compromised long term key does not compromise captured future traffic => forward secrecy (provided by (EC)DHE)
A compromised long term key does not compromise captured traffic from the past => backward secrecy (provided by HKDF-hash)

Thanks,
Jens

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 28 Dec 2016 18:54:17 +0000

> A compromised long term key does not compromise captured future traffic => forward secrecy (provided by (EC)DHE)

This is not correct.  Forward-secrecy is the below, not the above.

-- 
	Viktor.

---

From: "Guballa Jens (ETAS-PSC/ECS)" <[email-masked]>
Date: Thu, 29 Dec 2016 09:53:47 +0000

> This is not correct.  Forward-secrecy is the below, not the above.

[JG] I did not say clearly what I meant. :-) 
For my statement I set the presence implicitly to the end of the handshake, 
sorry for the confusion.

Anyway, in principle I am in line with the definition of "Forward secret" 
in section E.1, but still I have two comments:

1.
"Forward secret
    If the long-term keying material (in this case the signature keys in
certificate-based authentication modes or the external/resumption PSK in PSK
with (EC)DHE modes) are compromised after the handshake is complete, this
does not compromise the security of the session key (See [DOW92]).[...]"
	
- I think that "session key" is a synonym for "master secret". 
- My understanding: The master secret is a short-term secret, I think an 
implementation can delete it after the working keys have been derived,
right?

If these assumptions are correct, then I prefer something like
"..., this does not compromise the security of the master secret (see
[DOW92]) and
the derived working keys."
	
2.
If the term "backward secrecy" will remain in the draft, then I propose to 
either add a definition or refer to a definition of this term outside of
the draft.

> 
> > A compromised long term key does not compromise captured traffic from
> the past => backward secrecy (provided by HKDF-hash)
> 
> --
> 	Viktor.
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls