<hat location="off">
On Jul 27, 2011, at 6:30 PM, Yoav Nir wrote:
I think this is a terrible idea.
+.5. I think is is a bad idea.
IKEv2 has a way for mutual authentication with a shared key.
A concern was raised that this method was vulnerable to guessing if trivial
shared keys were configured.
There were several proposals for a better cryptographic method.
The IPsecME working group failed to choose between them. This is not so
surprising, because most participants are engineers, not cryptographers. Even
those with some cryptographic background stayed silent because choosing
between several cryptographic protocols is hard. IETF last calls and the IESG
did not help much either.
This draft represents a total shirking of our responsibility.
+.5. I think think it represents a shirking of our leadership's responsibility.
Our leadership said that they would deal with the issue if the WG could not
come to consensus, and the WG could not come to consensus. Adding a layer of
indirection that is mostly transparent is not dealing with it.
Rather than decide on one protocol that is "best" or even arbitrarily
choosing one that is "good enough", it proposes to build a framework so that
everyone and their dog can have their own method. This is a nightmare for
developers: since you can't know what method the peer will support, you have
to implement all of them.
If this had been a hierarchical organization, some manager would decide which
of the methods gets developed (or published) and the others would be
relegated to the recycle bin.
The IETF is not like that and we seek to reach consensus. That's a good
thing, but this time it's leading us to a really bad solution for
interoperability, and a really bad solution for implementers.
I am opposed to this draft.
+1
On Jul 27, 2011, at 6:52 PM, Tero Kivinen wrote:
Yoav Nir writes:
This draft represents a total shirking of our responsibility. Rather
than decide on one protocol that is "best" or even arbitrarily
choosing one that is "good enough", it proposes to build a framework
so that everyone and their dog can have their own method. This is a
nightmare for developers: since you can't know what method the peer
will support, you have to implement all of them.
Partially yes, but unfortunately all of the authors of those actual
protocols decided that they wanted to continue publishing those drafts
as individual RFCs, and each of them used different way to negotiate
them, so there was no way to even implement multiple of them.
Is this true? Because each has it's own way to negotiate its use, one should be
able to implement multiple of the competing proposals as-is, yes?
At least this drafts gives you that option to implement multiple of
them if you want. This draft only provides instructions for those
other draft authors so they can at least common methods to negotiate
the feature and use common method to trasmit data between peers.
True, but it is still punting the problem of us having just one.
--Paul Hoffman
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf