[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Do ipsec vendors care about privacy?



Hugo:

I repeat:  The working group co-chairs in combination with the document 
editor need to make a decision concerning the magnitude of the changes.  If 
it is the least bit onerous, then this should not be done.  It is not a 
requirement, and we are already overdue on delivery.

We need to hear from the chairs before proceeding with this discussion.  I 
think that we have given them adequate information to make the decision.  I 
hope that they will make it in the next few days.

Russ

At 09:10 AM 3/21/2003 +0200, Hugo Krawczyk wrote:


>On Thu, 20 Mar 2003, Russ Housley wrote:
>
> > Hugo:
> >
> >
> > I wrote:
> > >Hugo, in my view it is too late to be raising a question that will cause
> > >major surgery on the document.  It is time to fix things that are broken,
> > >make the document internally consistent, and publish it.  I do not 
> think it
> > >is time to raise new requirements.
>
>I agree: no time for major surgery on the document.
>But not too late for a change that takes 1-5 minutes editorial work
>On the other hand, I admit that there are some operational issues
>that are not fully resolved in my proposals and need more input from
>people that care and know better. If this does not come on time
>to make the document before being closed then we will not have it.
>
>On the other hand, user's id protection in the remote access protocol of
>ikev2 IS A NATURAL REQUIREMENT according to anything I heard from ipsec
>developers (on the list and outside the list). So giving the opprtunity to
>this substantial improvement if it comes at little cost and on time is a
>reasonable thing to do.
>
>In any case, ,I raised the issue and two possible solutions, but I am not
>the one that needs to decide if the WG is to adopt this or not. THOSE THAT
>CARE (in one way or another) SHOULD SPEAK UP.
>
>If there is not enough interest, then nothing needs to be done.
>At least it will be documented that this was a conscious decision rather
>than an overlook or the result of simple rushing.
>(This will help against future criticizers of the protocol that wil
>raise these issues in their papers...)
>
>I will be glad to see some technical discussion in the coming days
>if people care about having such discussions. Beyond that I am not going
>to insist (this is not an area of "correct cryptographic design" for
>which I personally care but rather one of engineering trade-offs that
>other understand better than me).
>
>Hugo
>
>PS: shoot the engineers but not the scientists :)
>
> >
> > You replied:
> > >This response really sounds as coming from the area director :)
> > >ANyway, I'd agree with you that this is too late if the change I proposed
> > >required "major surgery on the document". But it doesn't.
> > >Any of the proposed solutions takes a 1 minute editorial work,
> > >just moving one or two fields from one message to the other in section
> > >2.16 (and has no influence on other partts of the document).
> > >
> > >The question is not specification complexity which is null for this
> > >changes. ALso, it is not a performance issue. None of the proposed changes
> > >add round trips or computation (a message to the list from
> > >Antonio Forzieri might have given that impression but his
> > >modification of my proposal was unnecessary as he later stated himself).
> > >
> > >The only question is operational: can the responder (server) send the
> > >first EAP message before getting IDi? If this is the case (as it was in
> > >PIC and seems tobe agreed in some responses to my message) then we are
> > >done at no cost at all (solution 1). If not, we may need to go to
> > >solution 2 (in which the responder authenticates in message 2). Here the
> > >main operational issue, pointed out by Antonio, is that you need to have a
> > >way for the initiator to signal that he is requiring legacy
> > >authentication.
> > >
> > >So all we need is some feedback on the above operational issues, and then
> > >make a definitive decision about the right design/privacy trade-off.
> > >It should not put any delay on the closure of ikev2.
> >
> > The working group co-chairs in combination with the document editor 
> need to
> > make a decision concerning the magnitude of the changes.  If it is the
> > least bit onerous, then this should not be done.  It is not a requirement,
> > and we are already overdue on delivery.
> >
> > It is time to warp this effort up.  Fix anything that fails to meet the
> > requirements that have already been set by the working group. then make 
> the
> > document internally consistent.  Additional stuff can be dealt with by a
> > subsequent working group.
> >
> > Ted got it right at the beginning of the meeting.  He said, "It is time to
> > shoot the engineers and ship the product."
> >
> > Russ
> >
> >