Re: [TLS] Minor comments on draft-ietf-tls-dtls-heartbeat

Michael Tüxen <Michael.Tuexen@lurchi.franken.de> Thu, 01 September 2011 20:46 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68CD21F8E02 for <tls@ietfa.amsl.com>; Thu, 1 Sep 2011 13:46:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HnVtG70iE7B for <tls@ietfa.amsl.com>; Thu, 1 Sep 2011 13:46:40 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 72FCE21F8DE7 for <tls@ietf.org>; Thu, 1 Sep 2011 13:46:27 -0700 (PDT)
Received: from [192.168.1.195] (p508FDF41.dip.t-dialin.net [80.143.223.65]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 956F81C0C0BD9; Thu, 1 Sep 2011 22:48:00 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Michael_T=FCxen?= <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <CABcZeBP7MmhodxZ+nCK=Rs1hQAVTJ4+FJzzhw-s0LXO+0cqZjg@mail.gmail.com>
Date: Thu, 1 Sep 2011 22:47:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <DED6E62E-DEB5-47AB-912F-2370B3AE0FC1@lurchi.franken.de>
References: <CABcZeBOaYCecK3jqfteLp19DBQ2YS_xcQ_mbqstq-nW7Q7AoDQ@mail.gmail.com> <CD72BEBD-26E8-4B55-8ED2-D2FACDF04FC1@lurchi.franken.de> <CABcZeBP7MmhodxZ+nCK=Rs1hQAVTJ4+FJzzhw-s0LXO+0cqZjg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.1084)
Cc: draft-ietf-dtls-heartbeat@tools.ietf.org, tls@ietf.org
Subject: Re: [TLS] Minor comments on draft-ietf-tls-dtls-heartbeat
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Sep 2011 20:46:40 -0000

On Sep 1, 2011, at 10:26 PM, Eric Rescorla wrote:

> Works for me.
> 
> I believe this document is ready for advancement.
Thanks for the quick feedback.

Best regards
Michael
> 
> -Ekr
> 
> [As an individual]
> 
> On Thu, Sep 1, 2011 at 1:03 PM, Michael Tüxen
> <Michael.Tuexen@lurchi.franken.de> wrote:
>> On Sep 1, 2011, at 2:51 AM, Eric Rescorla wrote:
>> 
>> Hi Eric,
>> 
>> thanks a lot for the comments. See my comments in-line.
>> Accepted changes will be included in rev 03, which I will
>> submit when the WG LC is closed.
>> 
>> Best regards
>> Michael
>>> S 1.1.
>>> "and their adoptions" -> "and their adaptations"
>> Done.
>>> 
>>> "as described" -> described
>> Done.
>>> 
>>> 
>>> S 3.
>>> "Like the ChangeCipherSpec message,.... can arrive at any time"
>>> I guess a CSS can in principle arrive at any time, but it's not permitted at
>>> any time. You couldn't send it as the first message of a connection,
>>> for instance. I'm not sure there is a specific statement to this effect
>>> in 5246, but it seems implicit in S 7.3.
>> I think we can just say:
>> A HeartbeatRequest message can arrive almost at any time during the
>> lifetime of a connection.
>>> 
>>> "MUST stop the retransmission timer" -> "MUST stop the DTLS retransmission
>>> timer" perhaps?
>> Done.
>>> 
>>> "HeartbeatRequest messages from older epochs must be discarded"
>>> I would clarify that this is DTLS only since TLS has no epochs.
>> Changed to:
>> In case of DTLS, HeartbeatRequest messages from older epochs SHOULD be
>> discarded.
>>> 
>>> 
>>> S 4.
>>> You should probably clarify why the padding length is what it is.
>> OK. It reads now:
>> The padding is additional arbitrary content which MUST be ignored
>> by the receiver. The length of a HeartbeatMessage is TLSPlaintext.length
>> for TLS and DTLSPlaintext.length for DTLS. The length of the type field is 1
>> byte and the length of the payload_length is 2. Therefore, the
>> padding_length is TLSPlaintext.length - payload_length - 3 for TLS and
>> DTLSPlaintext.length - payload_length - 3 for DTLS.
>>> 
>>> 
>>> S 5.1
>>> We'll need to update the 4347 citation to DTLS 1.2
>> Done.
>>> 
>>> 5.2.
>>> "allows this check" -> "allows a check" perhaps?
>> Done.
>>> 
>>> "multiple round trip times"
>>> You should probably recommend some multiple.
>> I can't provide a concrete number. The text is based on a suggestion of the transport
>> area directorate.
>> 
>> The tradeoff is clear: The sooner you send a HB, the sooner you will figure out
>> that the peer is gone. However, the more traffic you are sending.
>> 
>> From a congestion control point of view, you can send a HB per RTT. But this is covered
>> by the requirement that you can only have one HB in flight.
>>> 
>>> S 6.
>>> Specification required is a pretty low bar for a field this small... Perhaos
>>> Expert Review would be better.
>> Changed.
>>> 
>>> 
>>> -Ekr
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>> 
>> 
>> 
>