Subject: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-relay-server-security-04: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 12 Apr 2017 13:39:54 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-dhc-relay-server-security-04: Yes

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-dhc-relay-server-security/

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

I am balloting "Yes", but I share the curiosity about whether people will
really do this.

-3, third paragraph: "MUST exchange messages securely"
"Securely" is too ambiguous for a MUST. What specific protections are
required?

-3, paragraph 4:
The list starts with no context. A sentence or paragraph describing the
purpose of the list would be helpful.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 12 Apr 2017 22:31:16 +0000

Hi:

For:

I believe this also was the 4th paragraph?
I guess there are two choices here:
1. Drop “securely” as we are just specifying to use IPsec.
2. Replace “securely” with “encrypted and authenticated”.
Seems to be #1 might be better (as it should be unnecessary given that is what this document is about).

     -3, paragraph 4:

RFC 3315 had before this list:
   Relay agents and servers that support secure relay agent to server or
   relay agent to relay agent communication use IPsec under the
   following conditions:

But I’m not sure “conditions” is the best word? Not sure if there is a better word to use to describe these items?

Perhaps replacing the first sentence in that 4th paragraph with:

  Relay agents and servers MUST exchange messages using the
  IPsec mechanisms described in [RFC4301] with the conditions
  as follows:

And, move the remaining text in that 4th paragraph to the end of section 4 as a separate paragraph.

- Bernie

On 4/12/17, 4:39 PM, "Ben Campbell" <[email-masked]> wrote:

    

    
    -3, paragraph 4:

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 12 Apr 2017 21:52:53 -0500

> I believe this also was the 4th paragraph?

Yes

> is what this document is about).

Is ESP with null encryption allowed?

> But I’m not sure “conditions” is the best word? Not sure if 
> there is a better word to use to describe these items?

Rules? Configuration? (But I don't think "conditions" is awful)

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 13 Apr 2017 03:11:24 +0000

Hi:

OK, I’ll use conditions.

>    Is ESP with null encryption allowed?

No. That was what RFC3315 had but this document changes that.

RFC 3315:

      Mode             Relay agents and servers use transport mode and
                       ESP. The information in DHCP messages is not
                       generally considered confidential, so encryption
                       need not be used (i.e., NULL encryption can be
                       used).

This new draft:

   Encryption and authentication algorithms
                           This document REQUIRES combined mode
                           algorithms for ESP authenticated encryption,
                           ESP encryption algorithms, and ESP
                           authentication algorithms as per Sections
                           2.1, 2.2, and 2.3 of [RFC7321] respectively.
                           Encryption is required as relay agents may
                           forward unencrypted client messages as well
                           as include additional sensitive information,
                           such as vendor-specific information (for
                           example, [CableLabs-DHCP]) and [RFC7839].

- Bernie

On 4/12/17, 10:52 PM, "Ben Campbell" <[email-masked]> wrote:

    
    Yes

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 12 Apr 2017 22:25:30 -0500

> No. That was what RFC3315 had but this document changes that.

That would suggest that the "MUST be secure" assertion in paragraph 4 is 
redundant with other normative text, and could be restated without the 
capitalized MUST.

Ben.

>     >     "Securely" is too ambiguous for a MUST. What specific 
> protections
>     > are
>     >     required?
>     >
>     > Seems to be #1 might be better (as it should be unnecessary 
> given that
>     > is what this document is about).
>
>     >    Relay agents and servers that support secure relay agent to 
> server
>     > or
>     >     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
>     >     The document, along with other ballot positions, can be 
> found
>     > here:
>     >     
>     >     I am balloting "Yes", but I share the curiosity about 
> whether
>     > people will
>     >     really do this.
>     >
>     >     "Securely" is too ambiguous for a MUST. What specific 
> protections
>     > are
>     >     required?
>     >
>     >     -3, paragraph 4:

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 13 Apr 2017 03:39:10 +0000

Hi:

> That would suggest that the "MUST be secure" assertion in paragraph 4 is redundant with other normative text, and could be restated without the capitalized MUST.

I'm not sure exactly what that reference is to? Paragraph 4 is:

   Relay agents and servers MUST exchange messages securely using the
   IPsec mechanisms described in [RFC4301].  If a client message is
   relayed through multiple relay agents (relay chain), each of the
   relay agents MUST have an established independent, pairwise trust
   relationships.  That is, if messages from client C will be relayed by
   relay agent A to relay agent B and then to the server, relay agents A
   and B MUST be configured to use IPsec for the messages they exchange,
   and relay agent B and the server MUST be configured to use IPsec for
   the messages they exchange.

Perhaps you are referring to the first MUST or all be changed to lower case?

I'm proposing going with:

   Relay agents and servers MUST be able to exchange messages using the
   IPsec mechanisms described in [RFC4301] and with the conditions
   below.  If a client message is relayed through multiple relay agents
   (relay chain), each of the relay agents MUST have an established
   independent, pairwise trust relationships.  That is, if messages from
   client C will be relayed by relay agent A to relay agent B and then
   to the server, relay agents A and B MUST be configured to use IPsec
   for the messages they exchange, and relay agent B and the server MUST
   be configured to use IPsec for the messages they exchange.

We do want to make it clear that an implementation that conforms to the to-be-RFC needs to support IPsec with those conditions.

- Bernie

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Wednesday, April 12, 2017 11:26 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: The IESG <[email-masked]>; Tomek Mrugalski <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Ben Campbell's Yes on draft-ietf-dhc-relay-server-security-04: (with COMMENT)

> No. That was what RFC3315 had but this document changes that.

That would suggest that the "MUST be secure" assertion in paragraph 4 is redundant with other normative text, and could be restated without the capitalized MUST.

Ben.