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

[Colin Perkins <[e-mail]>]

Hi Magnus,

Responses to some of this inline.

> On 26 Sep 2019, at 09:01, Magnus Westerlund <[e-mail]> 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. 
>  
>  
>  
>   -- 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. 

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/