Opened 10 years ago

#44 new defect

4244bis-02: security section misleading

Reported by: hkaplan@… Owned by:
Priority: minor Milestone: milestone1
Component: rfc4244bis Version: 2.0
Severity: In WG Last Call Keywords:


Section 9 says:

With the level of security provided by TLS (SEC-req-3), the
information in the History-Info header can thus be evaluated to
determine if information has been removed by evaluating the indices
for gaps (SEC-req-1, SEC-req-2). It would be up to the application
to define whether it can make use of the information in the case of
missing entries.

No, TLS doesn't do that. TLS only guarantees you that the next-hop or previous-hop is who its cert claims it to be (assuming you trust its anchor), and prevents tampering by something in-between you and that previous-hop or next-hop. That doesn't mean that previous-hop or next-hop, or some upstream/downstream entity beyond it, did not modify the H-I entries - including in ways which you cannot possibly detect. For example it could have renumbered them, changed their content, etc.

This section-9 paragraph is wrong, and we won't be able to satisfy the security requirements in appendix A.1 That's *OK*. We're not going to get better than that. In fact, we basically need that behavior, since we need PSTN Gateways to be able to generate H-I entries based on ISUP info (even for numbers they don't own); and we need Diversion interworked to H-I too.

Change History (0)

Note: See TracTickets for help on using tickets.