Subject: [TLS] IANA considerations I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt

From: "t.petch" <[email-masked]>
Date: Tue, 1 Feb 2011 10:28:37 +0100

Michael

I think that the IANA considerations could do with more work.

Dropping 'Heartbeat Modes' and 'Heartbeat Message Types'
into the IANA website could cause them to be lost for ever.  If they are
specific  to (D)TLS, then I would want to see that in the title, or else
have them subordinate to something that does.

Second, while I like starting with values with one, you leave zero 
open for the next person to use!  I would suggest reserving 
zero and 255 in both registries.

Tom Petch

---

From: "t.petch" <[email-masked]>
Date: Tue, 1 Feb 2011 10:23:25 +0100

----- Original Message -----
From: "Michael Tüxen" <[email-masked]>
To: "Florian Weimer" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 27, 2011 2:49 PM

On Jan 27, 2011, at 2:00 PM, Florian Weimer wrote:

>> This document describes the Heartbeat Extension for the Transport
>> Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
>> protocol.
>
> I think this paragraph
>
> | There MUST NOT be more than one HeartbeatRequest message in flight
> | at a time.
>
> should be changed to:
>
> | Retransmissions MUST use the same payload as the original
> | HeartbeatRequest message.
The intention of the sentence in the ID is that you can not send
multiple HeartbeatRequest out. This could overload the network since
DTLS uses transport layers which do not necessary provide a congestion
control. That is why you can only have one request in flight.
Please note that it is not in flight anymore if the corresponding
HeartbeatReply has been received or the retransmission timer fires.

Michael

My experience of the IESG is that they will insist on a paragraph about
Congestion Control (lack of) and mitigation thereof.  At the same time,
I find it very hard to know what words will satisfy them; my most recent
experience was with RFC6012, albeit a more complex scenario.

Tom Petch

>
> The original requirement seems to be pretty much unimplementable
> because of transport layer characteristics.
Not sure what problem you are thinking about.
An implementation of the ID for OpenSSL is available at
http://sctp.fh-muenster.de/dtls-patches.html

Best regards
Michael
>
> --
> Florian Weimer                <[email-masked]>
> BFK edv-consulting GmbH       http://www.bfk.de/
> Kriegsstraße 100              tel: +49-721-96201-1
> D-76133 Karlsruhe             fax: +49-721-96201-99
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 1 Feb 2011 14:37:40 +0100

> have them subordinate to something that does.
We can name them "DTLS and TLS Heartbeat Modes" and
"DTLS and TLS Heartbeat Message Types" or "(D)TLS Heartbeat Modes"
and "(D)TLS Heartbeat Message Types", whatever you prefer. Any opinion?
> zero and 255 in both registries.
Good idea. Well do that in the next ref.

Best regards
Michael

---

From: Sean Turner <[email-masked]>
Date: Tue, 01 Feb 2011 09:31:02 -0500

On 2/1/11 4:23 AM, t.petch wrote:
> From: "Michael Tüxen"<[email-masked]>
> To: "Florian Weimer"<[email-masked]>
> Cc:<[email-masked]>

I suspect that the transport ADs' interest will be piqued the minute 
they read the words: mtu ;)  The best thing to do is to ask for an early 
review from [email-masked].  I'm willing to send it over if you'd like?

This is my bad, because I haven't yet figured out what magic incantation 
needs to go in drafts to appease the transport (and probably internet 
area) ADs.

spt

>> Florian Weimer<[email-masked]>

---

From: "t.petch" <[email-masked]>
Date: Tue, 1 Feb 2011 15:50:37 +0100

----- Original Message -----
From: "Michael Tüxen" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, February 01, 2011 2:37 PM
> and "(D)TLS Heartbeat Message Types", whatever you prefer. Any opinion?

I would go for just TLS Heartbeat Modes, and TLS Heartbeat Message Types.

DTLS is a delta to TLS and there is a statement that everything is expected to
carry across unless otherwise stated, so for me, TLS implies DTLS.

Tom Petch

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 1 Feb 2011 21:20:12 +0100

On Feb 1, 2011, at 3:31 PM, Sean Turner wrote:

> I suspect that the transport ADs' interest will be piqued the minute they read the words: mtu ;)  The best thing to do is to ask for an early review from [email-masked].  I'm willing to send it over if you'd like?
Hi Sean,

yes, please send it over to them.

Robin and myself are working on some minor text changes and it would be
nice to address also the comments we get from the tsv-dir in the next
revision.
> 
> This is my bad, because I haven't yet figured out what magic incantation needs to go in drafts to appease the transport (and probably internet area) ADs.
Hmm. Regarding path MTU discovery we made references to RFC 4821, which
should make them happy (I hope).

But let us get their comments and improve the document.

Best regards
Michael

---

From: Florian Weimer <[email-masked]>
Date: Wed, 09 Feb 2011 08:33:02 +0000

* t. petch:

> multiple HeartbeatRequest out.

But you actually can because the transport layer may duplicate
datagrams.  In particular, recipients MUST be prepared to deal with
such duplicates.

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 9 Feb 2011 12:01:36 +0100

> datagrams.  In particular, recipients MUST be prepared to deal with
If the transport layer does (like TCP or SCTP), it has a CC.

The intention of allowing only one outstanding HeartbeatRequest
is a very simple form of CC.

Best regards
Michael

---

From: Florian Weimer <[email-masked]>
Date: Wed, 09 Feb 2011 11:03:33 +0000

> If the transport layer does (like TCP or SCTP), it has a CC.

Duplicates can result from other phenomena, not just deliberate
retransmission.

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 9 Feb 2011 23:54:17 +0100

> Duplicates can result from other phenomena, not just deliberate
What is the point here? The rule is to protect the network.
The receiver has to handle any kind of duplication, but that
is not the point here.

I'm not sure what you are suggesting.

Best regards
Michael

---

From: Martin Rex <[email-masked]>
Date: Thu, 10 Feb 2011 14:56:25 +0100 (MET)

> The receiver has to handle any kind of duplication, but that

An over-simplified statement like

   There MUST NOT be more than one HeartbeatRequest message in flight at
   a time.

is inappropiate for the stated purpose.

This single statement does not differentiate between compliant behaviour
for the sender and compliant behaviour for the receiver.
If it is necessary for the _receiver_ to handle duplicates gracefully
then this _must_ be spelled out seperately.

As it is, the wording of the spec implies that the receiver of duplicated
HeartbeatRequest messages needs to abort the connection with a
fatal error in order to comply with the specification.

-Martin

---

From: Florian Weimer <[email-masked]>
Date: Thu, 10 Feb 2011 14:35:45 +0000

> fatal error in order to comply with the specification.

Thanks.  This is my concern as well.

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 10 Feb 2011 16:56:21 +0100

> fatal error in order to comply with the specification.
But that is not written anywere. The ID states clearly:

When a HeartbeatRequest message is received, a corresponding
HeartbeatResponse message MUST be sent carrying an exact copy of the
payload of the HeartbeatRequest.  The padding of the received
HeartbeatRequest message MUST be ignored.  It MUST NOT be included in
the HeartbeatResponse message, i.e. the padding field of the
HeartbeatResponse message MUST have a length of zero.

In general it is a bad idea to send a fatal error when you receive
any DTLS packet twice.

Best regards
Michael

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 10 Feb 2011 16:57:33 +0100

> Thanks.  This is my concern as well.
Ahh, I see what you mean. But the procedures for the receiver are
clearly specified.

Best regards
Michael