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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

Hi Eric,

Please see inline

> -----Original Message-----
> From: Eric Rescorla <[e-mail]>
> Sent: Thursday, February 21, 2019 8:33 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; Liang Xia
> <[e-mail]>; [e-mail];
> [e-mail]
> Subject: Eric Rescorla's Discuss on draft-ietf-dots-requirements-18: (with
> DISCUSS and COMMENT)
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is safe.
> 
> 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.

Both signal and data channel require confidentiality and have the same data privacy and integrity requirements.

> 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. 

Yes, both the protocols using (D)TLS to mutually authenticate both sides and the messages on both channels are encrypted.

> Generally I would prefer to require
> confidentiality on both, but I could maybe see an argument for why that wasn't
> needed.

Removed DATA-002 and updated security requirements to discuss confidentiality for both DOTS protocols.

   SEC-003  Data privacy and integrity: Transmissions over the DOTS
      protocols are likely to contain operationally or privacy-sensitive
      information or instructions from the remote DOTS agent.  Theft,
      modification, or replay of message transmissions could lead to
      information leaks or malicious transactions on behalf of the
      sending agent (see Section 4 below).  Consequently data sent over
      the DOTS protocols MUST be encrypted using secure transports 
      (like TLS and DTLS).  DOTS servers MUST enable means to prevent leaking
      operationally or privacy-sensitive data.  Although administrative
      entities participating in DOTS may detail what data may be
      revealed to third-party DOTS agents, such considerations are not
      in scope for this document.

> 
> 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"?

We are trying to say both the redirecting and redirected target DOTS server belong to the same administrative domain.

Modified the last line as follows:
The redirection DOTS server and redirecting DOTS server MUST belong to the same administrative 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

When the requirements draft is initially drafted, the WG wanted to select the current IETF best practices for encryption and message authentication of DOTS messages.  The DOTS WG has decided to use (D)TLS for signal channel and TLS  for data channel.  I can modify the text to say "current IETF best practices for encryption and message authentication" for both SEC-001 and SEC-002.


> 
> 
> ----------------------------------------------------------------------
> 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.

Yes, modified the line as follows:
Implementations of older protocol versions MUST reject DOTS messages carrying mandatory information as part of newer protocol versions.

> 
> 
> 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"

I have replaced the above lines with the text suggested by Suresh.

> 
> 
> 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

Added the following term to avoid confusion :
Peacetime: In DDoS, ‘peacetime’ refers to the period during which the target network is not under DDoS attack.

Cheers,
-Tiru

>