Re: [TLS] Short notes on TLS RFCs ...

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Fri, 20 June 2014 13:07 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3E71B27D6 for <tls@ietfa.amsl.com>; Fri, 20 Jun 2014 06:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.202
X-Spam-Level:
X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgTMqAiM9FWB for <tls@ietfa.amsl.com>; Fri, 20 Jun 2014 06:07:27 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9701D1B27BF for <tls@ietf.org>; Fri, 20 Jun 2014 06:07:10 -0700 (PDT)
Received: from [192.168.1.200] (p508F221E.dip0.t-ipconnect.de [80.143.34.30]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 98EF71C104938; Fri, 20 Jun 2014 15:07:07 +0200 (CEST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <CACsn0cn7j0Qh-GJ7JK9Cs-NK9yQLqaz2k900C=D6ZAcbXWEPhQ@mail.gmail.com>
Date: Fri, 20 Jun 2014 15:07:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <D538F06C-FAC3-4EDC-8EBB-3077BBD66EB8@lurchi.franken.de>
References: <CAAF6GDfWGkZkYxvCHA+fScLzFse8bafDDd91Cgg_i-_UTu-Q0w@mail.gmail.com> <5772B9EF-EDD0-4B3E-A85E-43CCEA199D01@lurchi.franken.de> <CACsn0cn7j0Qh-GJ7JK9Cs-NK9yQLqaz2k900C=D6ZAcbXWEPhQ@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CHsfQbXb0NlDPDBMAiB9_m2g5hQ
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Short notes on TLS RFCs ...
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 20 Jun 2014 13:07:33 -0000

On 20 Jun 2014, at 14:31, Watson Ladd <watsonbladd@gmail.com> wrote:

> On Fri, Jun 20, 2014 at 9:15 AM, Michael Tuexen
> <Michael.Tuexen@lurchi.franken.de> wrote:
>> On 20 Jun 2014, at 05:32, Colm MacCárthaigh <colm@allcosts.net> wrote:
>> 
>>> 
>>> 3. The purpose of heartbeat message seems to be a form of path MTU
>>> discovery, but they also seem ill-suited to MTU discovery. In
>>> particular, Heartbeat messages seem to me capable of only discovering
>>> the lowest-MTU supported in both directions of transmission; rather
>>> than the actual MTU of the network paths; which can be (and sometimes
>>> are) asymmetrical.  This may seem very esoteric, but as WANs and
>>> transit providers deploy jumbo-frames inconsistently, asymmetrical
>>> MTUs are becoming more common. Though hopefully that day will pass.
>> No, heartbeat messages contain a payload being reflected and a padding
>> being discarded. Therefore you can send your (large) probe packet
>> containing a relatively small payload and a padding to get it to
>> the size you want to test, and just get back a small answer containing
>> the payload (and a small padding). So the padding is there especially
>> for dealing with asymmetric paths.
> 
> So Heartbleed is a feature: send a small packet and get a large
> response for the direction you want to test.
No... You send a large packet (mostly containing padding) and get
back a small one (mostly containing the reflected payload)...

Best regards
Michael
> 
> Sincerely,
> Watson Ladd
>> 
>> Best regards
>> Michael
>>> 
>>> Again, apologies if my notes are duplicative, but figured it was
>>> better to report a dupe than to miss something.
>>> 
>>> --
>>> Colm
>>> 
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>> 
>> 
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> 
> 
> 
> -- 
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety deserve neither  Liberty nor Safety."
> -- Benjamin Franklin
>