On Mon, Jan 31, 2011 at 11:41 AM, Eric Rescorla <ekr(_at_)skype(_dot_)net>
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf