Re: Last Call: <draft-ietf-tsvwg-iana-ports-09.txt> (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

[Eric Rescorla <[e-mail]>]

On Mon, Jan 31, 2011 at 11:41 AM, Eric Rescorla <[e-mail]> wrote:
> So first, we already have a BCP that says  more or less all protocols must implement a secure version but deployment is optional. This is a good BCP, and it comes from the right area to say that - security. It's probably impacts design work in working groups more than any other BCP. It has IETF consensus. The IESG holds protocols to this.
>
> Now - I am at loss to see why forcing people to use one port will make it more likely to have secure protocols. This seems crazy.  Please do enlighten me.

I don't think it does.

At a high level, there are three ways in which insecure and secure
versions (by which I mostly mean channel security mechanisms such as
TLS) of the same protocol can coexist:

1. They can operate on totally different transport parameters (e.g., ports)
2. They can be demuxable by some indicator that's simply sent by one
side and accepted or rejected by the other side. (E.g., "If the first
byte is 20 this is TLS, else it's not)
3. It can be negotiated as in STARTTLS

In the first two of these, the client knows which version it wants
(secure or insecure) and there is no chance for the server to indicate
otherwise other than failing the connection. In the third, the sides
negotiate. So, I think the first question is which general design you
wish to have. Each of these have their merits: negotiation designs are
more complicated but allow for opportunistic security. Unfortunately,
they also allow for downgrade attack, as the experience with STARTTLS
for SMTP shows. By contrast, non-negotiation designs are easier to
implement and provide for referential integrity but not for
opportunistic security. IMO there is a place for both, though I
generally tend towards non-negotiated designs, in part out of a
feeling that the world would be better if people used encryption all
the time.

Clearly, if you're going to do a negotiation design you want a single port.
If you're going to do a non-negotiated design, then I don't see a huge
amount of value in using a single port. It's true that there is a port
consumption issue, but OTOH ports are there for protocol demuxing and
this is clearly another protocol. It's simply a lot easier to have
your TLS stack just start its thing rather than try to autodetect
whether you have TLS or some other protocol. So I would generally push
back on the claim that non-negotiated designs should have to have
demuxing in information in the dataflow rather than use the port.


> And on the topic, I'm still looking forward to an explanation of how the current CoAP design stomping all over the TLS code points would be an acceptable design.

I don't consider this an acceptable design and I've already told the
CoAP authors and chairs so. Speaking as chair, if the CoAP
authors/chairs wish to pursue this avenue they should bring it to the
TLS WG, which AFAIK they have not done.

-Ekr



>
> On Jan 31, 2011, at 9:27 , Eliot Lear wrote:
>
>>
>>
>> On 1/31/11 5:13 PM, Cullen Jennings wrote:
>>> Hmm ... I don't agree that solves the issue.
>>>
>>> Well lets say the request was coming from 3GPP for a protocol they designed - why should IANA be able to tell them no but IETF yes.
>>
>> Who, ultimately, is the steward of this precious resource?  If it is not
>> the IANA and it is not the IETF, then who?  To say that it is everyone's
>> responsibility is to avoid responsibility entirely.  Who gets to say
>> which standards organizations are stewards and which are not?
>>
>>> I think the policy issue here is fairly clear. We do not have consensus that in all cases that one should not have a second port for security (I'm basing this assertion on Magnus read of WG consensus and my read of IETF LC consensus). Therefore that should not be a ground for the expert reviewer (or IANA) to reject the registration. The document needs to be updated to make that clear or it does not reflect consensus. If the authors of the draft want to propose text for conditions when it would be ok to reject a second port for security purposes and see if they can get consensus for that text, that seems perfectly reasonable.
>>
>> This is a VERY VERY dangerous approach you propose, Cullen.  It is akin
>> to saying, "you can think about security later, because we'll have to
>> give you a port for it later."  We don't want to be saying that.
>>
>
>
> Cullen Jennings
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>
>
>