Re: [Pce] Use of TCP AO and TLS in PCEP

[Joe Touch <[e-mail]>]

On 2/11/2014 6:26 AM, Diego R. Lopez wrote:
> Hi Joe,
>
> Too much travel making my email backlog grow, I'm afraid...
>
> On 6 Feb 2014, at 22:41 , Joe Touch <[e-mail]> wrote:
>>> The rationale is the common practice derived from the TLS layered
>>> approach, so a client knows how and when require the server to start a
>>> TLS connection, and the server knows in advance what the client is
>>> requiring and match it against its policy.
>>
>> That is common when there is no other way to determine whether a connection uses TLS or not (and even then is at best a performance optimization).
>
> I'd say is not only performance, but a security optimization. Unless
> the server is sure that starting a TLS session is explicitly required by
> the client, how can a server know whether there has been an intentional
> downgrade by a man-in-the-middle?

It cannot, but let's look at the case where there are different ports. 
The MITM in that case can rewrite packets to the different port. Same 
problem.

The conclusion is that the server cannot know about the downgrade until 
the connection fails because the MITM can't spoof the server's TLS 
credentials back to the client.

 > Furthermore, the client and server
> codes become completely independent of what happens at the TCP layer,
> and I think this is in general a good design practice.

Ports are a critical global community resource, not a programming 
convenience.

> And even if you find counterarguments to the two reasons above, the
> common practice is the use of either a dedicated port or a dedicated
> command.

We should be aiming for best practice, not common practice.

 > And that implies that developers will find plenty of choices to
> implement this, widely validated and understood by the community. And
> when it comes to security, this is of great value, mostly when PCEP peer
> developers will not usually be security experts.

Agreed, but they need to be protocol experts or they won't get the 
protocols right. If they do get the protocols right, then they can 
trivially determine the type of connection - at connection start - 
simply from the configuration of keys.

>> The use of TCP protection must be orthogonal to the use of TLS, so it
>>> can not be used for the server making a guess of the protocol
>>> security encapsulation.
>>
>> TCP protection isn't orthogonal to TLS for pcep as currently specified; see the table above. The only connections that can use TLS would be those that do not use TCP MD5 (see the list of cases above).
>>
>>> Either we have a protocol-specific mechanism (a-la-STARTTLS) or we
>>> usea specific port.
>> ...
>>
>> For every connection, you already know the mode before the
>> connectionstarts. If the connection is configured to require TCP MD5, then there
>> is no TLS. If not, then there must be TLS.
>
> What I cannot see is why the combination of TCP MD5 with TLS could
> nothappen,

It isn't specified, therefore you can say that if it happens you can 
cancel the connection attempt.

 > or the combination of TCP AO without TLS.

Same thing.

> We are talking about
> independent layers, or am I missing something? FWIW, you could use any
> of them on an IPsec connection as well...

You could, but they should all fail except the ones that you specify. 
That's a basic tenet of security design.

This is why I concluded that the protocol specifications - existing and 
the one currently under review - are easily distinguished. Ports are 
assigned for current use, not potential future use.

So unless you're proposing to revise the doc to include these other 
cases, they're irrelevant. And if you are, we can then talk about 
whether it's good security design to consider so may alternatives 
without specific use cases in mind.

>> There are no protocol changes required to make this happen; you
>> just  need to use the information you already have.
>
> By not having TCP protection and TLS orthogonal we are mixing
> securitymechanisms at two different layers, and assuming there is some kind of
> cross-layer exchange that may not necessarily happen because is out of
> the common practice, and that is a recipe for security holes.

TCP is - and needs to be - aware of both TCP and TLS protection. It has 
to have all the information needed anyway.

(yes, if we throw in other protocol layers here, that might not be true, 
but again we're talking about what has been proposed, not what might be).

> Maybe that the current writing of the PCEPS draft is not clear
> enough  in that respect. We would really appreciate any suggestion in 
improving it.

If you intend the protections to be orthogonal, you need to say that, 
and you need to justify why all possible combinations are needed. At 
that point I would argue against that set of combinations.

Joe