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

[Eric Rescorla <[e-mail]>]

On Fri, Feb 22, 2019 at 8:06 AM Konda, Tirumaleswar Reddy <
[e-mail]> wrote:

> Please see inline
>
>
>
> *From:* Eric Rescorla <[e-mail]>
> *Sent:* Friday, February 22, 2019 7:11 PM
> *To:* Konda, Tirumaleswar Reddy <[e-mail]>
> *Cc:* The IESG <[e-mail]>; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]
> *Subject:* Re: Eric Rescorla's Discuss on
> draft-ietf-dots-requirements-18: (with DISCUSS and COMMENT)
>
>
>
> *CAUTION*: External email. Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
> ------------------------------
>
>
>
>
>
> On Fri, Feb 22, 2019 at 3:41 AM Konda, Tirumaleswar Reddy <
> [e-mail]> wrote:
>
> 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.
>
>
>
> Great. That seems appropriate.
>
>
>
>
>
>
> > 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.
>
>
>
> This looks good. Note that if you are using DTLS, you may need to opt-in
> to the anti-replay service,
>
> as it is optional.
>
>
>
> Yes, DTLS anti-replay is a mandatory profile for the DOTS agents (see
> https://tools.ietf.org/html/draft-ietf-dots-signal-channel-28#section-7.1)
>
>
>
>
>
> >
> > 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.
>
>
>
> How do I interpret this as the redirected party? Does it have to be the
> same identity in the certificate? Something else?
>
>
>
> The redirected (or alternate) DOTS server’s FQDN will be conveyed by the
> redirecting DOTS server, and DOTS client uses the same explicit trust store
> to validate
>
> both the servers certificates.
>

OK, so the client has no way of knowing if these are actually the same
admin domain, it's just an operational requirement?

-Ekr


>
>
> > 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.
>
>
>
> If it 's (D)TLS, then I think you want to cite RFC 7525 here
>
>
>
> Sure, will cite RFC7525.
>
>
>
> > ----------------------------------------------------------------------
> > 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.
>
>
>
> Thanks.
>
>
>
>
>
>
> >
> >
> > 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.
>
>
>
> OK.
>
>
>
>
> >
> >
> > 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.
>
>
>
> If you must, but I think this is might be considered a little in bad taste
> by people who are involved in actual wars.
>
>
>
> Okay, removed the word.
>
>
>
> Cheers,
>
> -Tiru
>
>
>
> -Ekr
>
>
>
>
> Cheers,
> -Tiru
>
> >
>
>