On Thu, Aug 27, 2015 at 1:18 PM, Eric Rescorla <e...@rtfm.com> wrote:
> > > On Thu, Aug 27, 2015 at 2:14 AM, Viktor S. Wold Eide < > viktor.s.wold.e...@gmail.com> wrote: > >> On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla <e...@rtfm.com> wrote: >> >>> >>> >>> TLS 1.3 encrypts both the client's and server's certificates already. >>> The server's certificate is secure only against passive attack. The >>> client's is encrypted with a key that the client can authenticate as >>> belonging to the server. >>> >>> >> >> It's good to see that both the client's and the server's certificates are >> encrypted in TLS 1.3, providing protection against passive eavesdropping. >> >> For some use cases it might be worthwhile to reduce the information made >> available to an active attacker also. Are there any suggestions in this >> direction for TLS 1.3? >> >> One might think of a multi stage approach, something like: >> - Anonymous connection establishment, resulting in a secure channel. >> - Authentication by means of group certificate. >> - Authentication by means of a host specific certificate. >> >> The purpose of the second step above is to first only provide the group >> identity to an active attacker, and then to reveal the host identities >> (certificate information) only after group membership has been mutually >> authenticated >> > > I don't think this matches most TLS use cases very well, since the client > generally isn't authenticated at all, so there's no point in the server > progressively > revealing more. > > Although the client generally is not authenticated currently, TLS 1.3 and DTLS 1.3 are likely to stay for a long time and then to be used for lots of different use cases, including more peer-to-peer interaction. For some use-cases, including peer-to-peer interaction, being able to progressively reveal more information would improve protection. Whether this is a worthwhile tradeoff or not, depends on many different factors. I think it is both relevant and interesting to see to what extent (D)TLS 1.3 would support such use cases. Best regards Viktor S. Wold Eide
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
