Re: [TLS] Proposed text for removing renegotiation

That's a good rationale for saying TLS implementations SHALL NOT renegotiate unless requested or enabled by the application.  If the API doesn't provide a way to request/enable, then the stack shouldn't do it behind the app's back.

> Either we clean up renegotiation to the point where it can be useful, or we throw it out.

+1.  That's different from saying throw it out, period.

-----Original Message-----
From: Watson Ladd [mailto:watsonbladd@gmail.com] 
Sent: Wednesday, June 11, 2014 9:17 PM
To: Kemp, David P.
Cc: tls@ietf.org
Subject: Re: [TLS] Proposed text for removing renegotiation

On Wed, Jun 11, 2014 at 1:08 PM, Kemp, David P. <DPKemp@missi.ncsc.mil> wrote:
> A decision on the proper place to do access control has nothing to do with the skill of implementers.
>
> If a web server (or any service provider) doesn't know how to grant access to resources based on authenticated user identity, user attributes, resource attributes and access policy, then a perfect bug-free network stack is not going to help them.

Well, they do know how to grant access based on authenticated user identity. What they don't know how to do is deal with portions of a request being made with one identity, other portions with another.

>
> If a "certificate changes", then either the application should have requested renegotiation synchronously or it should have asynchronously established conditions for when the stack renegotiates and registered to be notified when it happens.  The proper response to renegotiation is identical to the proper response to negotiating the first time.

Name one program that actually enforces this, or a TLS implementation that permits it, except by banning renegotiation entirely.

>
> "We know more than the application layer people" - pure hubris.  TLS/IPSEC practitioners should definitely know more about cryptography, which application developers should be able to largely ignore as a black box.  But access control to application resources is inherently an application function for which TLS library coding expertise is no substitute.

Yes, but we can make the job of the application much easier by restricting the transformations that can happen. Applications are mostly unaware that responses could be split across authentication levels. That's why we had the renegotiation fix.

Things can get even worse: if I want to restrict a resource to some ciphersuites, not others, this can be evaded by renegotiation if the first ciphersuite is broken.

The issue is that the state transitions in renegotiation aren't clearly explained or cleanly exposed to applications by most TLS stacks. At this point, given the enormous number of applications using and that should be using TLS, the fact that historically most TLS stacks and applications using TLS have gotten this wrong, I don't see stay the course as a reasonable option. Either we clean up renegotiation to the point where it can be useful, or we throw it out.

Sincerely,
Watson Ladd

>
>
> -----Original Message-----
> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Watson Ladd
> Sent: Wednesday, June 11, 2014 7:46 AM
> To: Nikos Mavrogiannopoulos
> Cc: tls@ietf.org
> Subject: Re: [TLS] Proposed text for removing renegotiation
>
> On Wed, Jun 11, 2014 at 5:45 AM, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
>> On Tue, 2014-06-10 at 14:04 -0300, Watson Ladd wrote:
>>
>>> Quick: what is the proper response when the Certificate changes 
>>> between a negotiation and a renegotiation?
>>
>> That is on the application protocol to decide.
>
> Always the wrong answer: we know more then the application layer people do about security, just as the networking people know more than we do about sending packets through the network.
>
>
> _______________________________________________
> 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