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