Re: [TLS] Draft minutes for IETF-75 available

Gerhard Muenz <muenz@net.in.tum.de> Mon, 03 August 2009 20:03 UTC

Return-Path: <muenz@net.in.tum.de>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8965A28C26C for <tls@core3.amsl.com>; Mon, 3 Aug 2009 13:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.063
X-Spam-Level:
X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 Hv0i4qvs6cTp for <tls@core3.amsl.com>; Mon, 3 Aug 2009 13:03:31 -0700 (PDT)
Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 76F2728C23C for <tls@ietf.org>; Mon, 3 Aug 2009 13:03:31 -0700 (PDT)
Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 70C0F48588 for <tls@ietf.org>; Mon, 3 Aug 2009 22:03:32 +0200 (CEST)
Received: from [131.159.20.251] (vpn-1.net.in.tum.de [131.159.20.251]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 3CCBD3F04 for <tls@ietf.org>; Mon, 3 Aug 2009 22:03:32 +0200 (CEST)
Message-ID: <4A77429B.9080506@net.in.tum.de>
Date: Mon, 03 Aug 2009 22:03:39 +0200
From: Gerhard Muenz <muenz@net.in.tum.de>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: tls@ietf.org
References: <mailman.77.1249326021.24683.tls@ietf.org>
In-Reply-To: <mailman.77.1249326021.24683.tls@ietf.org>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="------------ms000109010507050101030809"
X-Virus-Scanned: ClamAV using ClamSMTP
Subject: Re: [TLS] Draft minutes for IETF-75 available
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Mon, 03 Aug 2009 20:03:32 -0000

Hi,

> Draft minutes for IETF 75 are available here:
> 
> http://www.ietf.org/proceedings/75/minutes/tls.txt
> 
> Let me know if you have corrections.

Probably here:

> 3. DTLS Heartbeat - Presented by Michael Tuexen
> 
> Draft: http://www.ietf.org/internet-drafts/draft-seggelmann-tls-dtls-heartbeat-00.txt
> 
> Pasi Eronen (AD): I can see this being useful in cases, but I can also see
>       it being solved in the lower layer protocols.  EG, in IPFIX I

lower => upper ? (otherwise, it does not make sense)

>       can very much see them solving it at their layer.
> Michael Tuexen: I see your point but...
> Pasi: I can also see this useful for PMTU discovery.
> Michael: That's true but it doesn't necessarily work for bi-directional
> 	differences.  You can another message which contains extra

missing verb?

> 	stuff for doing discovery.  SCTP has opaque data for doing
> 	things like that.  I like the discovery message, but I think
> 	it should be another message.
> Eric (Jabber): this is relevant in TCP cases as well.
> 
> Question: if you use this in UDP, the draft says you must not send them
>       while you're waiting for a response.
> Michael: Only one heart-beat request in flight at a time.  I don't want
> 	to have a congestion control problem
> 
> Wes Hardaker: agree with EKR that it is useful it TCP as well,
>       though you need to document differences.  Longer discussion on
>       the rational behind it.  

Some thoughts about the proposal to solve Heartbeat at the IPFIX layer
(from me as a contributor to IPFIX):
It is extremely unlikely that we will change the IPFIX protocol from
unidirectional to bidirectional just because DTLS-over-UDP requires it.
In my opinion, if we had to choose, it would be more likely that we
would update RFC5101 saying that DTLS is not required any more for
IPFIX-over-UDP implementations, and that the usage of
IPFIX-over-DTLS/UDP is not recommended because of the dead peer
detection problem.
IPFIX cannot reasonably deploy DTLS for UDP without the proposed
Heartbeat extension. The available workarounds are not very nice.

Regards,
Gerhard