[sipcore] rfc4244bis #44 (new): 4244bis-02: security section misleading

["sipcore issue tracker" <[e-mail]>]

#44: 4244bis-02: security section misleading

 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.

-- 
------------------------------------+---------------------------------------
 Reporter:  hkaplan@…               |       Owner:            
     Type:  defect                  |      Status:  new       
 Priority:  minor                   |   Milestone:  milestone1
Component:  rfc4244bis              |     Version:  2.0       
 Severity:  In WG Last Call         |    Keywords:            
------------------------------------+---------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/44>
sipcore <http://tools.ietf.org/sipcore/>