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

Works for me.

I believe this document is ready for advancement.

-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
>>
>
>