Subject: AW: [Ecrit] Review of draft-taylor-ecrit-security-threats-02.txt

From: "Tschofenig, Hannes" <[email-masked]>
Date: Wed, 1 Mar 2006 11:19:19 +0100

hi tom, 

please find my response below:

> -----Ursprüngliche Nachricht-----
> Von: Tom-PT Taylor [mailto:[email-masked]] 
> Gesendet: Freitag, 24. Februar 2006 15:12
> An: Hannes Tschofenig
> Cc: [email-masked]
> Betreff: Re: [Ecrit] Review of 
> draft-taylor-ecrit-security-threats-02.txt
> 
> I'm pleased to get your response. I never got my copy of my E-mail to 
> the list,so I was afraid it had disappeared into a black hole.
> 
> Just a couple of items to discuss, see below. Other stuff 
> snipped away.
> 
> Hannes Tschofenig wrote:
> > hi tom,
> > 
> > thanks for your response.
> > please find some comments inline:
> > 
> > Tom-PT Taylor wrote:
> > 
> >> Here are my detailed responses.
> >>
> ...
> >>
> >> Comment: section 5.1, end of third para, what is meant by 
> "installing 
> >> filters"?
> >> Response: What I meant by this was to say "intercept and discard 
> >> mapping queries relating to the target at a router on the 
> >> query-response path or at the mapping server". Because 
> this is rather 
> >> longer than the original, I'll rework the sentence 
> structure to handle 
> >> it.
> > 
> > 
> > the problem is: how do you setup these filters to only drop 
> queries by
> > adversaries. this sounds like a difficult problem to me.
> > furthermore, we are supposed to be indicating requirements 
> rather than
> > specific solutions.
> > 
> [PTT] No, I meant that the attacker installs the filters. 
> Presumably the 
> attacker has the information to construct them.

how can the attacker install packet filters to discard mapping queries? 

> >>
> ...
> >>
> >> Comment: section 6, requirements in response to man-in-the-middle 
> >> threat. Proposed alternative wording.
> >> Response: Your wording introduces the issue I mentioned in 
> my previous 
> >> E-mail: do we require implementation or only make it possible to 
> >> implement?
> > 
> > 
> > you mean: implementation vs. usage
> > 
> > my impression is that we have to be explicit as whether we 
> talk about
> > usage or implementation when we use RFC 2119 language. we 
> ask roger to
> > walk through the requirements draft todo the same. hence, i think we
> > should also apply it to this draft.
> > 
> > you are right that a MUST use in this particular case is really
> > difficult to accomplish in all cases.
> > 
> > what about MUST implement and SHOULD use?
> > 
> [PTT] We've heard objections that MUST implement is unrealistic for a 
> couple of reasons -- client resources and effect on call setup times. 

i don't buy the story that a MUST implement for TLS is a problem. almost every device today has TLS implemented already. 

the aspect of call setup time only effects the "SHOULD use" part. here, i again think that it is not a problem. TLS performance tests have shown that it is not really a problem. what could cause problems is certificate validation, path validation, CRL checking, etc.. this is, however, a separate issue that we tried to soften with the "SHOULD" regarding usage.

> Anyway, a "MUST implement" provision would be part of the protocol 
> specification rather than the requirements. What we would 
> distinguish at 
> the requirements level is "the protocol must provide" vs. 
> "the protocol 
> must not prevent". I am suggesting we use the latter.

we use the RFC 2119 language in the security threats document as a guideline to the protocol development. we do the same in the requirements drafts. maybe we should add a sentence explaining this fact to the terminology section in both the requirements and the security threats draft to make it clear. 

> >>
> ...
> >>
> >> Comment: section 6, fraudulent calls, remark that reverse 
> lookup is an 
> >> unnecessary requirement.
> >> Response: You're half right -- it is mostly an 
> optimization. But then 
> >> you're assuming that the VSP/ASP proxy is capable of reading the 
> >> location from the INVITE so it can redo the lookup. Is this 
> >> sufficiently problematic that we need the reverse lookup anyway?
> > 
> > we are entering solution specific teritory here. maybe we 
> should talk
> > about this at all in the draft.
> > 
> > here is my impression about this stuff in relationship to 
> the ongoing
> > solution specific work:
> > we do not have the infrastructure to perform reverse 
> lookups. we only
> > worried about "Location -> URI" mapping. We have never 
> looked at the URI
> > -> Location mapping.
> > 
> > we should keep an eye on this issue.
> > 
> [PTT] The requirement doesn't go that far. What is needed is 
> to be able 
> to look up a URI and get back an assurance that the URI 
> points to a PSAP 
> -- a "yes" or "no". I'll make sure the wording is clear on this point.
ok. sounds good to me.

ciao
hannes

> > ciao
> > hannes
> > 
> ...
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
> 

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

---

From: Andrew Newton <[email-masked]>
Date: Wed, 15 Mar 2006 20:46:01 -0500

On Mar 1, 2006, at 5:19 AM, Tschofenig, Hannes wrote:

> here, i again think that it is not a problem. TLS performance tests  
> have shown that it is not really a problem.

I believe if you have long lived sessions where TLS is using  
symmetric cryptography that this may be the case, but for a short  
lived sessions in a request/response protocol TLS will certainly add  
to performance issues.  The simple test I presented at the interim  
showed a 3.4 times greater latency with TLS than over plain TCP.

> what could cause problems is certificate validation, path  
> validation, CRL checking, etc.. this is, however, a separate issue  
> that we tried to soften with the "SHOULD" regarding usage.

Certainly there seems no point to invoking heavy weight public key  
cryptography if the results are to just be thrown away.

-andy