Last Call Review of draft-ietf-mext-mip6-tls-
review-ietf-mext-mip6-tls-secdir-lc-gondrom-2012-03-01-00

I have reviewed this document as part of the
      security directorate's ongoing effort to review all IETF documents
      being processed by the IESG.  These comments were written
      primarily for the benefit of the security area directors. 
      Document editors and WG chairs should treat these comments just
      like any other last call comments.








      This draft of the MEXT WG is experimental and aims at using
      Transport Layer Security-based Mobile IPv6 Security Framework for
      Mobile Node to Home Agent Communication instead of IPSEC. 





      In general this can be feasible 

and the
      security considerations section is relatively extensive,

 however a number of issues come to mind, which can
      be grouped in four areas:





      1. TLS:


      - risk of TLS downgrading (via renegotiation)


      - risk of TLS stripping (by a MitM)





      2. trust and server certificates




- as we saw in websec there are a number
      of risks with the handling/provisoning of certs through CAs.


      In this case the server landscape could be much better controlled
      by the operator, this may be easier here, but still the question
      remains: 


      - as this uses certs for authentication, do we have to look at
      compromised certs / how to update trust-anchors in mobile nodes?


      - do we need to look into cert pinning to sustain trust
      relationships? 







3. Cipher Suites (5.6.5. and following):


      the listed cipher suites seem limited and potentially not
      sufficiently secure and agile.


      - why are you not including AES-256 and SHA-2 (512bit)?


      - furthermore due to the list of ciphers it seems the spec is
      lacking algorithm agility, it might be apropriate to use a
      registry or even better refer to an existing registry for cipher
      suites?





      4. Misc:


      - and on a personal note maybe a stupid question: why do you MUST
      set the sequence number to 0 at the start? 


      Does this 

reduction in the range of
      expected sequence number values possibly open channels for attack,
      like 

increase the risk of an attacker
      guessing sequence numbers in the stream?







In general I feel the draft could use the
      improvements in the above four areas, but as it is experimental,
      it may be sufficient. 





      Best regards, Tobias