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

From: Eric Rescorla <[email-masked]>
Date: Thu, 21 Feb 2019 07:03:03 -0800

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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 22 Feb 2019 11:41:47 +0000

Hi Eric,

Please see inline

> -----Original Message-----
> From: Eric Rescorla <[email-masked]>
> Sent: Thursday, February 21, 2019 8:33 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; Liang Xia
> <[email-masked]>; [email-masked];
> [email-masked]
> 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.
> 
> 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.)
> 
> 
> I only had a short time to read this, but I find myself confused about the
> COMSEC requirements here.
> 

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

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

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

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

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

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

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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 22 Feb 2019 05:41:10 -0800

On Fri, Feb 22, 2019 at 3:41 AM Konda, Tirumaleswar Reddy <
[email-masked]> wrote:

> email
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

Great. That seems appropriate.

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

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.

> We are trying to say both the redirecting and redirected target DOTS
> server 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?

> 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

> Implementations of older protocol versions MUST reject DOTS messages
> carrying mandatory information as part of newer protocol versions.
>

Thanks.

> "MAY

OK.

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

-Ekr

---

From: Andrew Mortensen <[email-masked]>
Date: Fri, 22 Feb 2019 10:02:29 -0500

See below.

> On Feb 22, 2019, at 8:41 AM, Eric Rescorla <[email-masked]> wrote:
> …snip...
> 
>> 
>> 
>> S 2.2.
> If you must, but I think this is might be considered a little in bad taste by people who are involved in actual wars.

I think we can just change the text to “When no attack traffic is present, the signal channel MUST be….” No need for the extra definition.

andrew

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 22 Feb 2019 15:11:45 +0000

> From: Andrew Mortensen <[email-masked]>
> Sent: Friday, February 22, 2019 8:32 PM
> To: Eric Rescorla <[email-masked]>
> Cc: Konda, Tirumaleswar Reddy <[email-masked]>;
> The IESG <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Eric Rescorla's Discuss on draft-ietf-dots-requirements-18: (with
> DISCUSS and COMMENT)
> 
> I think we can just change the text to “When no attack traffic is present, the
> signal channel MUST be….” No need for the extra definition.

Yes, will also remove the use of 'peacetime' word from the DOTS signal channel draft.

-Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 22 Feb 2019 16:06:05 +0000

Please see inline

From: Eric Rescorla <[email-masked]>
Sent: Friday, February 22, 2019 7:11 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric,

Please see inline

> From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
> To: The IESG <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Liang Xia
> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>

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

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.

Sure, will cite RFC7525.

Thanks.

OK.

Okay, removed the word.

Cheers,
-Tiru

-Ekr

Cheers,
-Tiru

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 22 Feb 2019 08:44:58 -0800

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

> Please see inline
>
>
>
> *From:* Eric Rescorla <[email-masked]>
> *Sent:* Friday, February 22, 2019 7:11 PM
> *To:* Konda, Tirumaleswar Reddy <[email-masked]>
> *Cc:* The IESG <[email-masked]>; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> *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.
> ------------------------------
>
>
>
>
>
> 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.
> 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
>

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

-Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 22 Feb 2019 16:19:01 -0600

> admin domain, it's just an operational requirement?

(D)TLS mutual auth is used, so there is some information available as a
proxy for "same admin domain", like "certificate issued by same private CA
hierarchy" or similar.

-Benjamin