Subject: [Ecrit] Roman Danyliw's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 02 Mar 2020 13:35:41 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-ecrit-data-only-ea-21: 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-ecrit-data-only-ea/

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

Section 9.  Since CAPs can be included by reference (via URI) and the senders
may be unknown to the ESRP/PSAP, please include language on the security
considerations for untrusted URIs per Section 7 of RFC3986

Section 9.  Per “To provide protection of the entire SIP message exchange
between neighboring SIP entities, the usage of TLS is REQUIRED.”, can you
please provide guidance on how to use TLS.

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

Section 1.  Per “These messages may be one-shot alerts to emergency authorities
…”, aren’t these alerts as scoped for the purposes of this document _always_
“one-shot alerts”?

Section 4.2.  In the definition of ‘area’, please note that the various
conversions (e.g., arc-bands to equivalent polygons) are out of scope of this
document.

---

From: Adam Roach <[email-masked]>
Date: Mon, 2 Mar 2020 15:44:41 -0600

> please provide guidance on how to use TLS.

I think the strong implication here is that TLS is to be used in the 
same way that TLS is used in other SIP applications (in the same way 
that an HTTP document saying "MUST use TLS" is pretty clearly saying to 
use HTTPS as per the existing HTTP RFCs).

Unfortunately, the TLS handling for SIP is mixed into RFC 3261 all 
_over_ the place, so there's not anything particularly comprehensive to 
point to. The best that I think could be said would be something along 
the lines of "...the usage of TLS, as described in section 26 of 
[RFC3261], is REQUIRED."

Would that satisfy your concern?

/a

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 2 Mar 2020 21:51:00 +0000

Hi Adam!

> -----Original Message-----
> From: Adam Roach <[email-masked]>
> Sent: Monday, March 02, 2020 4:45 PM
> To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; draft-
> [email-masked]
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-ecrit-data-only-ea-21:
> (with DISCUSS and COMMENT)
> 
> > Section 9.  Per “To provide protection of the entire SIP message
> > exchange between neighboring SIP entities, the usage of TLS is
> > REQUIRED.”, can you please provide guidance on how to use TLS.
> 
> 
> I think the strong implication here is that TLS is to be used in the same way
> that TLS is used in other SIP applications (in the same way that an HTTP
> document saying "MUST use TLS" is pretty clearly saying to use HTTPS as per
> the existing HTTP RFCs).
> 
> Unfortunately, the TLS handling for SIP is mixed into RFC 3261 all _over_ the
> place, so there's not anything particularly comprehensive to point to. The
> best that I think could be said would be something along the lines of "...the
> usage of TLS, as described in section 26 of [RFC3261], is REQUIRED."
> 

I can appreciate this difficulty.  Sounds good to me. 

Roman

---

From: Brian Rosen <[email-masked]>
Date: Mon, 2 Mar 2020 17:24:12 -0500

I’ll add Adam’s suggested language.

WRT the first issue: URIs to untrusted entities, I note that there is no discussion of untrusted entities in Section 7 of RFC 3986.  There is discussion of misleading URIs.  If I added text to the security section that read:

When the CAP message is passed by reference, the recipients of the MESSAGE may not have a trust relationship with the sender.  Recipients MUST take precautions in retrieving the CAP message because the URI may point to a malicious actor.  

Would that satisfy your concerns?

I will also fix the nits.

> On Mar 2, 2020, at 4:51 PM, Roman Danyliw <[email-masked]> wrote:
> 
> Hi Adam!
> 
>> From: Adam Roach <[email-masked] <mailto:[email-masked]>>
>> To: Roman Danyliw <[email-masked] <mailto:[email-masked]>>; The IESG <[email-masked] <mailto:[email-masked]>>
>> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; draft-
>> [email-masked] <mailto:[email-masked]>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 9 Mar 2020 17:06:49 -0400

I hope I got all your comments fixed in -22
https://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-22

Brian

> On Mar 2, 2020, at 5:24 PM, Brian Rosen <[email-masked]> wrote:
> 
>> On Mar 2, 2020, at 4:51 PM, Roman Danyliw <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Adam!
>>