Re: [TLS] Proposed text for removing renegotiation

On Mon, Jun 9, 2014 at 3:49 PM, Andrei Popov <Andrei.Popov@microsoft.com>
wrote:

> Hi Martin,
>
> > The former we have decided to solve in HTTP.
>
> Are you referring to these I-Ds:
> http://tools.ietf.org/html/draft-thomson-httpbis-cant-00
> http://tools.ietf.org/html/draft-thomson-tls-care-00
>
> Httpbis-cant talks (rather vaguely) about using "realm" or "other
> challenge parameters" to select an appropriate client cert. I think client
> cert selection should be clearly specified before we can say that the
> mid-session client auth problem has been solved, and remove renegotiation
> from TLS 1.3.
>
> It would be even better to solve this problem at the TLS layer, so that
> each application protocol does not need to come up with a separate
> solution. And avoiding the round-trips involved in establishing a TCP
> connection would be awesome, too. The current solution using renegotiation
> has both of these desirable properties.
>

TLS still includes the Certificate Request message to indicate which client
certificates are being used. If we have an extension to allow clients to
say "I want to offer a cert, what cert do you want?", this can be used.

>
> Cheers,
>
> Andrei
>
> -----Original Message-----
> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson
> Sent: Monday, June 9, 2014 11:17 AM
> To: Nikos Mavrogiannopoulos
> Cc: tls@ietf.org
> Subject: Re: [TLS] Proposed text for removing renegotiation
>
> On 9 June 2014 00:34, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
> > Could somebody elaborate on what is that issue and why does it need to
> > be solved? (it is not even mentioned in the TLS 1.3 charter) As
> > someone who follows the mailing list that proposal comes out of the
> > blue with no context whatsoever.
>
>
> I think that this has been covered in the thread, but piecemeal:
>
> * Renegotiation is a major source of security issues, both of the "we
> screwed the TLS design up" sort and of the "my application didn't realize
> that these things could change" sort.  There is a clear desire to remove
> features that enable either sort of problem.
>
> * Renegotiation is just more protocol complexity.  Removing it potentially
> makes implementations simpler.
>
> I think that either might be sufficient justification for removing the
> feature.
>
> However, a number of use cases depend on renegotiation to achieve their
> ends.  Of these, we have identified:
>
> * mid-session client authentication, which uses renegotiation seems to
> only be used in HTTP
>
> * very long-lived connections, which require renegotiation to re-key
> occasionally
>
> The former we have decided to solve in HTTP.  As a side note, we just
> decided to forbid renegotiation in HTTP/2.
>
> The latter can be addressed by my proposal, or any of a number of
> mechanisms.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
"Those who would give up Essential Liberty to purchase a little Temporary
Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin