Re: [TLS] Security concerns around co-locating TLS and non-secure on same port (WGLC: draft-ietf-tsvwg-iana-ports-08)

[Matt DeMoss <[e-mail]>]

>
>
> I can not deny that separate-port for SSL is simpler to implement on the
> server side (having done both). Since the odds of security bugs increases
> with the amount of code, I must conclude that separate-port SSL is more
> secure for _implementers_ and _implementations_ for that reason alone.
>
 [...]

> As an aside, there is no interoperable specification for use of TLS client
> certificate authentication with the "pops" protocol (does it start in
> not-authenticated state and require an AUTH EXTERNAL, or does it start in
> authenticated state -- no way to distinguish the two cases). However, use of
> TLS client certificate authentication with POP+STLS according to written
> rules in RFC 2595 does interoperate.
>
>
I think the argument for protecting complex code paths from exposure is much
stronger in the case of required client certificate authentication where
unauthorized users may be able to exercise fewer paths.

There are also some cases where it seems like you get client-cert-auth 'for
free' as a side effect of sitting on top of a TLS implementation that
supports client auth. MS Outlook seems to like this with LDAPS: I doubt it
was a conscious choice on their part to include that mode of authentication.

The separate port model also makes it easier to terminate the TLS tunnel at
a simple load balancing or TLS accelerating device that knows nothing of the
underlying protocol.