Subject: [Taps] AD review of draft-ietf-taps-transport-security-08

From: Magnus Westerlund <[email-masked]>
Date: Thu, 26 Sep 2019 08:01:54 +0000

Hi,

Sorry about the delay in getting the AD review done. Below are my comments
and questions. Note the questions are truly questions and after answering we
can discuss if there needed to be any changes or not. 

1. Section 4.1: Is there a reason to use TLS 1.2 specification (RFC5246)
rather than TLS 1.3 as the general reference? 

2. Comment on the writeup: Considering that ID nits results in the below
relevant references warning I would expect some comment in the writeup if
they are intentional. If not please update the references. If they are
intentional, please update the writeup to note them. 

  -- Obsolete informational reference (is this intentional?): RFC 2385

     (Obsoleted by RFC 5925)

  -- Obsolete informational reference (is this intentional?): RFC 4474

     (Obsoleted by RFC 8224)

  -- Obsolete informational reference (is this intentional?): RFC 5246

     (Obsoleted by RFC 8446)

  -- Obsolete informational reference (is this intentional?): RFC 7539

     (Obsoleted by RFC 8439)

3.  Section 4.1.2: Is there a point to mention that TLS forward secrecy are
dependent on cipher suit for the key exchange and not ensured prior to 1.3? 

4. Section 4.1.2: Second to last paragraph: Broken reference to DTLS 1.3
draft: "(Note that this extension is only supported in

   DTLS 1.2 and 1.3 {{?I-D.ietf-tls-dtls13}.)"

5. Section 4.3.3: "QUIC transport relies on UDP." Although QUIC is targeting
UDP as its main deployment vessel, isn't QUIC in fact dependent on a
unreliable datagram service. But, maybe writing UDP is more straightforward?
 
6. Section 4.5.4: When it comes to variants of SRTP. I think referencing RFC
7201 would actually be reasonable, as in the many different options hide
some transport security options that so far is not discussed in this
document. Like securing multicasted / broadcasted RTP. 
 
7. Section 4.5.4: So are ZRTP included as variant because it provides new
security features? Is that session continuity, or something else? 
 
8. Section 11: There are a number of references here that I don't think
meets the requirement for references. These are the ones that only have a
title and n.d. All these could include a URL a date when these pages was
visited and contained the information you want to reference. 

Cheers
 
Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Thu, 26 Sep 2019 11:52:58 +0100

Hi Magnus,

Responses to some of this inline.

> On 26 Sep 2019, at 09:01, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi,
>  
> Sorry about the delay in getting the AD review done. Below are my comments and questions. Note the questions are truly questions and after answering we can discuss if there needed to be any changes or not. 
>  
>  
> 1. Section 4.1: Is there a reason to use TLS 1.2 specification (RFC5246) rather than TLS 1.3 as the general reference? 
>  
> 2. Comment on the writeup: Considering that ID nits results in the below relevant references warning I would expect some comment in the writeup if they are intentional. If not please update the references. If they are intentional, please update the writeup to note them. 
>  
>  
>  
> 3.  Section 4.1.2: Is there a point to mention that TLS forward secrecy are dependent on cipher suit for the key exchange and not ensured prior to 1.3? 
>  
> 4. Section 4.1.2: Second to last paragraph: Broken reference to DTLS 1.3 draft: “(Note that this extension is only supported in
>    DTLS 1.2 and 1.3 {{?I-D.ietf-tls-dtls13}.)”
>  
> 5. Section 4.3.3: “QUIC transport relies on UDP.” Although QUIC is targeting UDP as its main deployment vessel, isn’t QUIC in fact dependent on a unreliable datagram service. But, maybe writing UDP is more straightforward?
>  
> 6. Section 4.5.4: When it comes to variants of SRTP. I think referencing RFC 7201 would actually be reasonable, as in the many different options hide some transport security options that so far is not discussed in this document. Like securing multicasted / broadcasted RTP. 

Most of the additional security options described in RFC 7201 add little, if anything, to the other security protocols already discussed in the draft. We don’t mention that RTP can run over TLS over TCP, for example, but we already discuss TLS. The interesting protocol to mention is likely RTP with MIKEY for group communication, although bringing in group security might significantly widen the scope.

> 7. Section 4.5.4: So are ZRTP included as variant because it provides new security features? Is that session continuity, or something else? 

The use of the short authentication string and key continuity.

> 8. Section 11: There are a number of references here that I don’t think meets the requirement for references. These are the ones that only have a title and n.d. All these could include a URL a date when these pages was visited and contained the information you want to reference. 
>  
>  
> Cheers
>  
> Magnus Westerlund

-- 
Colin Perkins
https://csperkins.org/

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Thu, 26 Sep 2019 21:03:34 +0200

Hi, 

> On 26. Sep 2019, at 10:01, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi,
>  
> 2. Comment on the writeup: Considering that ID nits results in the below relevant references warning I would expect some comment in the writeup if they are intentional.

Sorry, that is my fault. I checked these and discussed them with the authors, but did not include the discussion in the writeup, as it was not clear to me that this needs to be part of the writeup.
I wait for further comments on your review and will add a note to the writeup on the intentional references to deprecated documents.

> If not please update the references. If they are intentional, please update the writeup to note them. 
>  
>  

necessary - the RFC is deprecated, but the mechanism still exists and is used. Its primary use (in BGP) has been deprecated, but is still widely used.

>   -- Obsolete informational reference (is this intentional?): RFC 4474

This is a mistake and has been fixed on github. I did not insist on publishing a new revision for the AD review.

>   -- Obsolete informational reference (is this intentional?): RFC 5246

This is intentional in Section 9, but debatable in Section 4.1

>   -- Obsolete informational reference (is this intentional?): RFC 7539

This is a mistake and has been fixed on github. I did not insist on publishing a new revision for the AD review.

--  
Philipp S. Tiesel
https://philipp.tiesel.net/

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 27 Sep 2019 17:58:57 -0700

Hi Magnus,

Thanks for the feedback! Please see inline below.

On Thu, Sep 26, 2019, at 1:01 AM, Magnus Westerlund wrote:
> 1. Section 4.1: Is there a reason to use TLS 1.2 specification 
> (RFC5246) rather than TLS 1.3 as the general reference? 

Nope! We'll fix this. It was an oversight.

> 2. Comment on the writeup: Considering that ID nits results in the 
> below relevant references warning I would expect some comment in the 
> writeup if they are intentional. If not please update the references. 
> If they are intentional, please update the writeup to note them. 
> 

<snip>

Philipp answered these. (Thanks, Philipp!)

> 3. Section 4.1.2: Is there a point to mention that TLS forward secrecy 
> are dependent on cipher suit for the key exchange and not ensured prior 
> to 1.3? 

Are you asking if we *should* mention that? If so, I think not. That's probably too much detail.
 
> 4. Section 4.1.2: Second to last paragraph: Broken reference to DTLS 
> 1.3 draft: “(Note that this extension is only supported in
> 

Oops, good catch. We'll fix this, too.

> 5. Section 4.3.3: “QUIC transport relies on UDP.” Although QUIC is 
> targeting UDP as its main deployment vessel, isn’t QUIC in fact 
> dependent on a unreliable datagram service. But, maybe writing UDP is 
> more straightforward? 

Indeed! How about, "QUIC transport assumes an unreliable transport, e.g., UDP"?

> 6. Section 4.5.4: When it comes to variants of 
> SRTP. I think referencing RFC 7201 would actually be reasonable, as in 
> the many different options hide some transport security options that so 
> far is not discussed in this document. Like securing multicasted / 
> broadcasted RTP.  

I'm not sure those are new security features, though. Colin, what do you think?

> 7. Section 4.5.4: So are ZRTP included as variant 
> because it provides new security features? Is that session continuity, 
> or something else?  

Colin answered this. (Thanks, Colin!)

> 8. Section 11: There are a number of references 
> here that I don’t think meets the requirement for references. These are 
> the ones that only have a title and n.d. All these could include a URL 
> a date when these pages was visited and contained the information you 
> want to reference.   

We can fix these in the next revision.

Thanks again for the review!

Best,
Chris