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

"tom.petch" <cfinss@dial.pipex.com> Thu, 06 August 2009 10:30 UTC

Return-Path: <cfinss@dial.pipex.com>
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 332EA3A6B15 for <tls@core3.amsl.com>; Thu, 6 Aug 2009 03:30:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.255
X-Spam-Level:
X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599]
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 TprOz2ZWNslw for <tls@core3.amsl.com>; Thu, 6 Aug 2009 03:30:08 -0700 (PDT)
Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id B83C93A6D90 for <tls@ietf.org>; Thu, 6 Aug 2009 03:29:00 -0700 (PDT)
X-Trace: 239573520/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.244/None/cfinss@dial.pipex.com
X-SBRS: None
X-RemoteIP: 62.188.100.244
X-IP-MAIL-FROM: cfinss@dial.pipex.com
X-SMTP-AUTH:
X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106
X-IP-BHB: Once
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiMFAEpNeko+vGT0/2dsb2JhbACDMEEfjF3DcAmEDwWBTA
X-IronPort-AV: E=Sophos;i="4.43,332,1246834800"; d="scan'208";a="239573520"
X-IP-Direction: IN
Received: from 1cust244.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.244]) by smtp.pipex.tiscali.co.uk with SMTP; 06 Aug 2009 11:29:01 +0100
Message-ID: <000a01ca1678$3bfe7960$0601a8c0@allison>
From: "tom.petch" <cfinss@dial.pipex.com>
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>, tls@ietf.org
References: <AC1CFD94F59A264488DC2BEC3E890DE5087BCE4B@xmb-sjc-225.amer.cisco.com>
Date: Thu, 06 Aug 2009 09:30:46 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: [TLS] Matters arising was: Re: Draft minutes for IETF-75 available
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "tom.petch" <cfinss@dial.pipex.com>
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: Thu, 06 Aug 2009 10:30:09 -0000

I see that the TLS heartbeat extension is mentioned in the minutes.

Discussion of this on the syslog and IPFIX lists said
"However, it's not clear if the TLS WG will support the draft."

I would like to see it supported.

Tom Petch


----- Original Message -----
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: <tls@ietf.org>
Sent: Monday, August 03, 2009 8:28 PM

> Draft minutes for IETF 75 are available:
>
> Transport Layer Security (TLS) Working Group Minutes
> Meeting : IETF75, July 31, 2009
> Location: Stockholm, Sweden, Room 307, 1300-1400
> Chairs  : Joseph Salowey <jsalowey@cisco.com>,
> Eric Rescorla <ekr@networkresonance.com>
> Minutes : Wes Hardaker, Jeff Hodges
> Version 2
>
>
> 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.  For example, in IPFIX I
>       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 send another message which contains extra
> 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.