On Sun, Jun 22, 2014 at 4:09 PM, Stephen Farrell
<[email protected]> wrote:
>
>
> On 23/06/14 00:02, Christian Huitema wrote:
>> This may be the current practice, but is it something that we want to keep
>> or encourage? "Just starting TLS" is clearly simpler and more robust than
>> first going through a "STARTTLS" negotiation. I think it would make perfect
>> sense to allocate TLS only ports for services that we want to transition to
>> a "default TLS" posture. RFC 6335 explains why IANA should preserve the
>> port-numbers resource, and we could do that by phasing out usage of the
>> clear-text only port, and then removing its registration.
>
> That seems like a good strategic approach to me, where we can
> get it agreed. I suspect its not for this WG though, but yeah,
> maybe sometime in the not-too-distant we can deprecate some
> clear-text ports. (I wonder which would be the first where that
> is practical?)

Maybe the echo service? The problem is that this requires global
coordinated action.

We can get to TLS everywhere even with STARTTLS and without stripping
attacks by remembering TLS support of peers and applying ratchets.
Once enough peers use TLS, we can force its use by making STARTTLS
mandatory, and aborting if the client does it support it.

By contrast freeing a port means figuring out if it is used by anyone
at all. I think we might be able to take DEC related protocols back,
but watch as someone says "well, I got this sewage treatment plant
that runs on a VAX, and when it breaks we'll replace it, but until
then..." This is not an imaginary problem: I seem to remember
discussion of a Cisco protocol that stepped on what was once supposed
to be a port for secure mail submission, and IANA, in its infinite
wisdom, changed the usage of the port.

Sincerely,
Watson Ladd


-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta

Reply via email to