Subject: AW: [NSIS] GIST: On Reverse Path Attacker, NTLP issue #17

From: "Tschofenig, Hannes" <[email-masked]>
Date: Fri, 5 Aug 2005 10:02:37 +0200

hi roland, 

i think that the additional effort is mostly in a small piece of protocol specification. 
there is almost no difference from a computational point of view. 
 
ciao
hannes

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im 
> Auftrag von Roland Bless
> Gesendet: Donnerstag, 4. August 2005 20:37
> An: [email-masked]
> Betreff: [NSIS] GIST: On Reverse Path Attacker, NTLP issue #17
> 
> 
> Hi,
> 
> (see 
> http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue17
> for more details)
> 
> as I already expressed in
> http://www1.ietf.org/mail-archive/web/nsis/current/msg05085.html
> 
> I'm in favor of Roberts approach, to document it as residual
> threat. So I'm not agreeing on Hannes opinion "let's do it".
> Sure we technically can, but
> I don't think it is really worth spending the effort, because
> it is more or less a special type of man in the middle attack,
> which cannot be prevented anyway by NTLP. Maybe Hannes could
> elaborate a little bit more...furthermore: maybe some guy
> from the Security Area could give advise what to do about this
> issue.
> 
> Regards,
>  Roland
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Roland Bless <[email-masked]>
Date: Fri, 05 Aug 2005 10:27:34 +0200

> there is almost no difference from a computational point of view. 

AFAIK this would require an additional cookie mechanism.
What about additional implementation complexity etc.??
Robert seemed also to be reluctant to change the current spec
(for these reasons, other others? What's your opionion on
spec/implementation complexity?).
I very much like to follow the KISS principle here:
since we do not really can avoid a MitM attack in general,
we should avoid this "additional" security mechanism
-> reduces implementation complexity...and saves some
paragraphs(?) in the protocol spec.

Regards,
 Roland