Draft: draft-ietf-capport-rfc7710bis

Commentary: Thread : 
 Perhaps a reference to as well as the security considerations sections of 2131 , 4861 , 4862 , and 8415 . 
 The new paragraph is good . The other sentence is a little hard to understand and risks opening questions that we probably do n't want opened .
Mailing list commentary: Reviewer : result : Has Issues Since the use of IP address literal is not forbidden by this document , what if an attacker with the ability to inject DHCP messages or RAs uses this option to force the user to contact an IP address of his choosing ? In this case , the use of TLS and presenting the identity in the certificate might not be of much help . I think this case should be discussed in the security consideration section .
Paragraph (version A):
An attacker with the ability to inject DHCP messages or RAs could
include an option from this document to force users to contact an
address of his choosing.  As an attacker with this capability could
simply list himself as the default gateway (and so intercept all the
victim's traffic); this does not provide them with significantly more
capabilities, but because this document removes the need for
interception, the attacker may have an easier time performing the
attack.  As the operating systems and application that make use of
this information know that they are connecting to a captive-portal
device (as opposed to intercepted connections) they can render the
page in a sandboxed environment and take other precautions, such as
clearly labeling the page as untrusted.  The means of sandboxing and
user interface presenting this information is not covered in this
document - by its nature it is implementation specific and best left
to the application and user interface designers.
Paragraph (version B):
Each of the options described in this document is presented to a node
using the same protocols used to provision other information critical
to the node's successful configuration on a network.  The security
considerations applicable to each of these provisioning mechanisms
also apply when the node is attempting to learn the information
conveyed in these options.  In the absence of security measures like
RA Guard (RFC6105, RFC7113) or DHCP Shield RFC7610, an attacker could
inject, modify, or block DHCP messages or RAs.
Paragraph (version B):
An attacker with the ability to inject DHCP messages or RAs could
include an option from this document to force users to contact an
address of his choosing.  As an attacker with this capability could
simply list themselves as the default gateway (and so intercept all
the victim's traffic); this does not provide them with significantly
more capabilities, but because this document removes the need for
interception, the attacker may have an easier time performing the
attack.
Paragraph (version B):
However, as the operating systems and application that make use of
this information know that they are connecting to a captive-portal
device (as opposed to intercepted connections) they can render the
page in a sandboxed environment and take other precautions, such as
clearly labeling the page as untrusted.  The means of sandboxing and
user interface presenting this information is not covered in this
document - by its nature it is implementation specific and best left
to the application and user interface designers.