IETF Logo Mail Archive

Re: [TLS] Forged RST (was: About encrypting SNI)

Nico Williams <nico@cryptonector.com> Thu, 17 April 2014 16:52 UTC

Return-Path: <nico@cryptonector.com>
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 26AE31A01D3 for <tls@ietfa.amsl.com>; Thu, 17 Apr 2014 09:52:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level:
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no
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 aiUdKKJvxQZJ for <tls@ietfa.amsl.com>; Thu, 17 Apr 2014 09:51:59 -0700 (PDT)
Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 503371A0252 for <tls@ietf.org>; Thu, 17 Apr 2014 09:51:59 -0700 (PDT)
Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id AF0721B406F for <tls@ietf.org>; Thu, 17 Apr 2014 09:51:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=BZKnZt8VO9rPHPtf17Ui3MDS+00=; b=gyUWenD6xUr J8e0TXFUk1PfPDOY5uJzxa5tW/k/OhptNFxj4t2uF29Kr5OeL7ebYWSbRBkrpywF qncqagIKJoejYqpk2MQUSZ/RhDj2PnsC5f3dXwnGq4ZChOLXZ4t/OeMNJyWXFZp7 6shAr1TWCr6wHXK7RRTQY6+FGhksnEtM=
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 5A4431B4058 for <tls@ietf.org>; Thu, 17 Apr 2014 09:51:55 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id cc10so1109467wib.16 for <tls@ietf.org>; Thu, 17 Apr 2014 09:51:54 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.211.116 with SMTP id nb20mr13042285wic.5.1397753514014; Thu, 17 Apr 2014 09:51:54 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Thu, 17 Apr 2014 09:51:53 -0700 (PDT)
In-Reply-To: <822C36AB-27AC-4844-8C83-449064FC345C@gmail.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04ED40@USMBX1.msg.corp.akamai.com> <534C3D5A.3020406@fifthhorseman.net> <474FAE5F-DE7D-4140-931E-409325168487@akamai.com> <D2CB0B72-A548-414C-A926-A9AA45B962DA@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120B490162@USMBX1.msg.corp.akamai.com> <CACsn0cmusUc3Rsb2Wof+dn0PEg3P0bPC3ZdJ75b9kkZ5LDGu_A@mail.gmail.com> <534DB18A.4060408@mit.edu> <m2ppkhl08c.fsf@usma1mc-0csx92.kendall.corp.akamai.com> <CAFggDF13=bKS3_kRz_uh-6y71TQ9O4v1e3+xs3fiM4YZwjAULA@mail.gmail.com> <CALCETrU-w=yon9TVzbvGSbznEgThxzUkzy4Yeu+CBfSp7Zk2hw@mail.gmail.com> <CAFggDF3i1ku++GWMp=03aL3ogpHO_Fg9qJ3daZuLN4SH5Fcj8g@mail.gmail.com> <534F0A33.9070408@akr.io> <822C36AB-27AC-4844-8C83-449064FC345C@gmail.com>
Date: Thu, 17 Apr 2014 11:51:53 -0500
Message-ID: <CAK3OfOgkvxLEib+3AnzBDTyz01RW-=xDgrRbwSmkjBh=D69kQw@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yfzQRuL90jF9Gnc78JlHIVB4mFQ
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Forged RST (was: About encrypting SNI)
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: Thu, 17 Apr 2014 16:52:03 -0000

On Thu, Apr 17, 2014 at 3:27 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
> On Apr 17, 2014, at 1:54 AM, Alyssa Rowan <akr@akr.io> wrote:
> We’re at the wrong layer to fix an attack against TCP.  The right place to protect TCP is either in TCP itself, or by using IPsec.

Well, yes, but we're well past having clean layers now.  I wouldn't
_terribly_ mind an option where TLS keying can be used to key a TCP
encryption option.  That is, I'd not like it very much, but I'd accept
it.

> Those who won’t use TCP are doomed to re-create it. To get a UDP-based protocol to replace TCP for the web you’d need all of reliable delivery through (selective?) retransmissions, bandwidth detection, replay protection, a whole lot of things that took the transport community years to get right. Yes, there have been many attempts, but there’s a reason TCP is still the protocol everyone uses for pretty much any type of bulk transfer. And this is before we even begin to talk about middleboxes dropping unrecognized UDP services.

Yes, but TCP has issues.  See mosh for an example of why one might
abandon TCP for UDP.  (Briefly: with UDP one gets mobility for free;
with TCP one can only get mobility via IP mobility protocols,
therefore one doesn't.)

>> UDP is also notably better for
>> connections through NAT and suchlike. (I've even done my own
>> experiments in that general direction, although delicious and moist as
>> they seem to be, they're simply experiments and I'm not yet ready to
>> serve them to guests, let alone strangers!)
>
> UDP is connectionless. As such, NAT devices don’t know when it’s done. So NAT mappings need to linger a lot longer after the last packet. TCP works better with NAT.

Yes, but for some application protocols (e.g., mosh) this is not a big deal.

> It would require an explanation about why this new wheel would be better than TCP in IPsec.

Because no one has cared to implement RFC5660 or anything like it.
IPsec as it is implemented and deployed does not provide TLS-like
guarantees that the peer at the other end remains the same for the
life of the connection (assuming local security).  This is a major
failure of IPsec, and a barely acknowledge failure at that.

If you want to use IPsec for end-to-end security then a) some parts of
the authentication process must move to higher layers, b) peer
continuity MUST be provided.  Any discussion of use of IPsec for
end-to-end security [outside small networks] without such an
acknowledgment of this just isn't credible.

Nico
--

v2.23.0 | Report a Bug | By Email