[Dots] Eric Rescorla's Discuss on draft-ietf-dots-requirements-18: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-dots-requirements-18: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3543


I only had a short time to read this, but I find myself confused about
the COMSEC requirements here.

There is no COMSEC requirement for the signaling channel in S 2.2.
DATA-002 requires a secure COMSEC protocol for the data channel.
SEC-001 and SEC-002 require "peer mutual authentication" and "message
confidentiality, integrity, and authentication" according to "industry
best practices". This doesn't seem to be a requirement which I can
verify or evaluate. If "industry best practices" were to use raw TCP,
would such an implementation be conformant.

I think what needs to be required here is cryptographic authentication
of both sides and of the messages on both channels. Generally I would
prefer to require confidentiality on both, but I could maybe see an
argument for why that wasn't needed.

DETAIL
S 2.2.
>         free to attempt abbreviated security negotiation methods supported
>         by the protocol, such as DTLS session resumption, but MUST be
>         prepared to negotiate new security state with the redirection
>         target DOTS server.  The authentication domain of the redirection
>         target DOTS server MUST be the same as the authentication domain
>         of the redirecting DOTS server.

what is an "authentication domain"?


S 2.4.
>      SEC-002  Message Confidentiality, Integrity and Authenticity: DOTS
>         protocols MUST take steps to protect the confidentiality,
>         integrity and authenticity of messages sent between client and
>         server.  While specific transport- and message-level security
>         options are not specified, the protocols MUST follow current
>         industry best practices for encryption and message authentication.

This is not a verifiable conformance requirement


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

S 2.1.
>         proprietary DDoS defenses.  Future extensions MUST be backward
>         compatible.  Implementations of older protocol versions MUST
>         ignore optional information added to DOTS messages as part of
>         newer protocol versions.  Implementations of older protocol
>         versions MUST reject mandatory information added to DOTS messages
>         as part of newer protocol versions.

MUST reject the information or MUST reject the messages.
Conventionally, it's the latter.


S 2.2.
>         discussed in [I-D.ietf-intarea-frag-fragile].  If the PMTU cannot
>         be discovered, DOTS agents MUST assume a PMTU of 1280 bytes for
>         IPv6.  If IPv4 support on legacy or otherwise unusual networks is
>         a consideration and the PMTU is unknown, DOTS implementations MAY
>         rely on a PMTU of 576 bytes for IPv4 datagrams, as discussed in
>         [RFC0791] and [RFC1122].

I'm having trouble reading this text. You say above "MUST assume" and
"MAY rely" here. Are you saying "send no more than 576" or "you can
assume you can send at least 576 and we're not saying anything about
the upper bound"


S 2.2.
>         active DOTS client has not requested mitigation, in order to
>         control load.
>   
>         Following mutual authentication, a signal channel MUST be
>         considered active until a DOTS agent explicitly ends the session.
>         During peace time, signal channel MUST be considered active until

"peace time" is probably not the right word here. After all, my
country might be at peace but still subject to a DoS attack