Re: [TLS] What would make TLS cryptographically better for TLS 1.3

Hi,

avoid renegotiation. It serves no purpose and only adds complexity. It is
so much more secure to kill and re-establish the TLS if the counters run
out instead of renegotiating.

This might be better placed in a higher layer:
It is desirable for the server to know how the client authenticated the
server. E.g. currently the a server does not know if the client matched the
Server's Certificate's CommonName against the URI or if the client
performed full certificate chain authentication. Currently the server
blindly trusts the client (e.g. user) to check the certificate chain and
match the URI<>CN.

(An example are jabber servers using TLS. Most clients allow the user to
accept any server certificate without verification. The jabber server has
no way to detect which client performed proper certificate verification and
CN<>URI match).

regards,

ralf

On Fri, Nov 1, 2013 at 7:09 PM, Nikos Mavrogiannopoulos <nmav@gnutls.org>wrote:

> On 11/01/2013 12:09 AM, Nico Williams wrote:
> >
> > My list:
> >
> >  - It should be deployable, that's first; in particular, it needs to be
> >    deployable with ECDH PFS key exchanges.
>
> (unrelated) It would actually be nice to have a wiki for anyone to add
> his wish list there.
>
>
> >  - Renegotiation should be replaced with an NPN-like extension that
> >    provides privacy to the TLS client principal name.
>
> I don't think anyone can avoid renegotiation. Since the TLS packet
> counters are 64-bit (and more importantly in DTLS 48-bits), one cannot
> avoid renegotiation to reset the counters.
>
> (nevertheless, all the practical VPNs I've seen using TLS, don't use
> renegotiation, they just re-establish the session).
>
> regards,
> Nikos
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>