Re: Last Call: draft-ietf-avt-dtls-srtp - DTLS-SRTP to Proposed Standard

[Eric Rescorla <ekr at networkresonance.com>]

At Thu, 02 Oct 2008 17:23:31 -0400,
Russ Housley wrote:
> 
> 
> I know these are a few hours late, but I have a few comments.  I have 
> divided them into TECHNICAL and EDITORIAL.
> 
> TECHNICAL COMMENTS
> 
> Section 1, 2nd para. It is unclear what version of DTLS is being 
> used.  The reference to RFC4347 in this paragraph leads to one 
> conclusion, but in Section 4.1.2 the authors also refer to DTLS 1.2 
> when discussing the PRF.  If this depends on a particular version of 
> DTLS, please tell us up front.

No, it doesn't depend. It's compatible with either version of DTLS.
However, because DTLS has adjustable PRFs, we simply added
this sentence to make clear what to do with DTLS 1.2.


> Appendix B, 2nd example of Multiple DTLS Handshakes.   RFC 5246, 
> section 7.4.1.2, states: "After sending the ClientHello message, the 
> client waits for a ServerHello message.  Any handshake message 
> returned by the server, except for a HelloRequest, is treated as a 
> fatal error". So, looking at the second ClientHello, the server 
> responds with ChangeCipherSpec and Finished messages associated  with 
> the first session.   What will happen?  I can imagine an 
> implementation that will consider it a fatal error.

The text you're referring to in RFC 5246 refers to a single connection,
but Appendix B is talking about two separate connections/associations
(hence the (1) and (2)). This is not an error in TLS. In fact,
in this particular case the state machines are completely uncoupled.


> EDITORIAL COMMENTS
> 
> Maybe we From ietf-bounces at ietf.org  Thu Oct  2 19:00:35 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 1E4C63A683B;
	Thu,  2 Oct 2008 19:00:35 -0700 (PDT)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 6E3C43A683B
	for <ietf at core3.amsl.com>; Thu,  2 Oct 2008 19:00:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.429
X-Spam-Level: 
X-Spam-Status: No, score=0.429 tagged_above=-999 required=5 tests=[AWL=-1.375, 
	BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 
	MANGLED_LIST=2.3, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id HjAfGqF3emXa for <ietf at core3.amsl.com>;
	Thu,  2 Oct 2008 19:00:33 -0700 (PDT)
Received: from kilo.rtfm.com (unknown [74.95.2.169])
	by core3.amsl.com (Postfix) with ESMTP id 0CD343A67A4
	for <ietf at ietf.org>; Thu,  2 Oct 2008 19:00:18 -0700 (PDT)
Received: from kilo-2.local (localhost [127.0.0.1])
	by kilo.rtfm.com (Postfix) with ESMTP id 85B096AC100;
	Thu,  2 Oct 2008 19:00:09 -0700 (PDT)
Date: Thu, 02 Oct 2008 19:00:08 -0700
From: Eric Rescorla <ekr at networkresonance.com>
To: Russ Housley <housley at vigilsec.com>
Subject: Re: Last Call: draft-ietf-avt-dtls-srtp - DTLS-SRTP to Proposed
	Standard
In-Reply-To: <20081002204052.64D495C023 at laser.networkresonance.com>
References: <20081002204052.64D495C023 at laser.networkresonance.com>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20081003020009.85B096AC100 at kilo.rtfm.com>
Cc: fluffy at cisco.com, mcgrew at cisco.com, ietf at ietf.org, jon.peterson at neustar.biz
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org

At Thu, 02 Oct 2008 17:23:31 -0400,
Russ Housley wrote:
> 
> 
> I know these are a few hours late, but I have a few comments.  I have 
> divided them into TECHNICAL and EDITORIAL.
> 
> TECHNICAL COMMENTS
> 
> Section 1, 2nd para. It is unclear what version of DTLS is being 
> used.  The reference to RFC4347 in this paragraph leads to one 
> conclusion, but in Section 4.1.2 the authors also refer to DTLS 1.2 
> when discussing the PRF.  If this depends on a particular version of 
> DTLS, please tell us up front.

No, it doesn't depend. It's compatible with either version of DTLS.
However, because DTLS has adjustable PRFs, we simply added
this sentence to make clear what to do with DTLS 1.2.


> Appendix B, 2nd example of Multiple DTLS Handshakes.   RFC 5246, 
> section 7.4.1.2, states: "After sending the ClientHello message, the 
> client waits for a ServerHello message.  Any handshake message 
> returned by the server, except for a HelloRequest, is treated as a 
> fatal error". So, looking at the second ClientHello, the server 
> responds with ChangeCipherSpec and Finished messages associated  with 
> the first session.   What will happen?  I can imagine an 
> implementation that will consider it a fatal error.

The text you're referring to in RFC 5246 refers to a single connection,
but Appendix B is talking about two separate connections/associations
(hence the (1) and (2)). This is not an error in TLS. In fact,
in this particular case the state machines are completely uncoupled.


> EDITORIAL COMMENTS
> 
> Maybe we can avoican avoid the possessive form of DTLS.  Should it be DTLS's 
> be just DTLS' ?
> 
> Section 1, 3rd para, 1st sentence. s/combine/combines/
> 
> Section 1, 4th para, 3rd bullet.  s/DTLS extension/DTLS extension is/
> 
> Section 3, 8th para. s/handshakes establishment exchanges./handshakes./
> 
> Section 4.1.3, 3rd para, 1st sentence. A subject is missing.  I 
> suggest: "If the client detects a nonzero-length MKI in the server's 
> response that is different than the one the client offered, then the 
> client MUST abort the handshake and SHOULD send an invalid_parameter alert."
> 
> Section 4.2, 1st para after Figure 1, 1st sentence. s/need/needed/
> 
> Section 5.1.2, 1st para after the 5 numbered statements. s/times the 
> number/times the number of/
> 
> Appendix A, 2nd para, 1st sentence. s/authenticated/authenticate/

Thanks. I'll take care of these.


-Ekr
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


d the possessive form of DTLS.  Should it be DTLS's 
> be just DTLS' ?
> 
> Section 1, 3rd para, 1st sentence. s/combine/combines/
> 
> Section 1, 4th para, 3rd bullet.  s/DTLS extension/DTLS extension is/
> 
> Section 3, 8th para. s/handshakes establishment exchanges./handshakes./
> 
> Section 4.1.3, 3rd para, 1st sentence. A subject is missing.  I 
> suggest: "If the client detects a nonzero-length MKI in the server's 
> response that is different than the one the client offered, then the 
> client MUST abort the handshake and SHOULD send an invalid_parameter alert."
> 
> Section 4.2, 1st para after Figure 1, 1st sentence. s/need/needed/
> 
> Section 5.1.2, 1st para after the 5 numbered statements. s/times the 
> number/times the number of/
> 
> Appendix A, 2nd para, 1st sentence. s/authenticated/authenticate/

Thanks. I'll take care of these.


-Ekr
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf