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 <[email protected]> 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
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
