Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
Mike Copley <mikec@lamsap.org> Wed, 02 December 2015 15:15 UTC
Return-Path: <mikec@lamsap.org>
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 D792B1A00AC for <tls@ietfa.amsl.com>; Wed, 2 Dec 2015 07:15:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 N4vW8vIXYNPt for <tls@ietfa.amsl.com>; Wed, 2 Dec 2015 07:15:09 -0800 (PST)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B771A00C2 for <tls@ietf.org>; Wed, 2 Dec 2015 07:15:09 -0800 (PST)
Received: by wmec201 with SMTP id c201so258103283wme.0 for <tls@ietf.org>; Wed, 02 Dec 2015 07:15:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lamsap-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=usA1HGA3YumkjNBaYPVI8rwChgyYfrULLv5kMKjvWY8=; b=IRhiqW2DeBYIN0ext71R3R7u2nzWwQYnjKKakldWK6kTsTTzFzZNIDwQ3GaSaJJo1t HbzXQrKWFEYha8ICbUw6OO1qDf1cSAcRG+BeE1wKQ32GOea3lF499iakcnt8uWqwC63z sxMu+L3bh1ZOwQvH4UlHQ1dX6yGy+2khyjD17SDILZNGljM7UNUVtovGjncrFfBDQMmC dc+amrHeCZS0qrR6+Ha7oEbtcAQVBDfOEcBxhXtGZRsPg3n8c1vlCZyhj5bSMGuyeZ9j g0a23Tlsgfr6FE1bICOpg1bhoE0tA9LYJJmQjWeKKL+fzVZiui4hwex67z6TdFn5m2Qm pu9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=usA1HGA3YumkjNBaYPVI8rwChgyYfrULLv5kMKjvWY8=; b=Ficn4bHrdLaA8EPNFVMgcJWIeeQjWjqSmFJTBCrEGKuRn/pI0HgSjdOyi63RtV74st j+2pyIUFDPwwCiniDryWC7LjbHSGbY19KcChypOjynLpH0M2mSEDK60/JAHpUg+PCxFI NruITe2OP2a7GTZ23doS0ED5QSMQxEaRvVnxh16YZkNhwphiPxSrMMcP3zNH0rKtwo0r FU1lzl2Bl06UpA7U0zVikhkF8t0tFn2pSEOQxs3Pq5sSTnmWj+HzIFjIv2cwFrborahD qfKC55pyaFgS0VBxu5eksrU1IAAuQ7t8QmZZnvi8PYCnk0PTk388LsPFvvgvm5y4mxXE w58A==
X-Gm-Message-State: ALoCoQnEyj++IJC0tWxHPrqrzt3wFvbx5HlD1cu7bGRLOT6LSDPp62r6Rb1xMsgaTgOLXAsrQhQR
X-Received: by 10.28.234.200 with SMTP id g69mr6320674wmi.97.1449069307592; Wed, 02 Dec 2015 07:15:07 -0800 (PST)
Received: from [192.168.18.6] ([94.3.213.136]) by smtp.gmail.com with ESMTPSA id a186sm3627409wmh.4.2015.12.02.07.15.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Dec 2015 07:15:06 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: text/plain; charset="windows-1252"
From: Mike Copley <mikec@lamsap.org>
In-Reply-To: <FC4B4A5A-3D42-411B-AFF9-2381DE61E63E@gmail.com>
Date: Wed, 02 Dec 2015 15:14:56 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <CFCAB19C-9040-4FB0-B774-3A0C3E5EF9B9@lamsap.org>
References: <56586A2F.1070703@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B8DA2A@uxcn10-5.UoA.auckland.ac.nz> <565AC278.2010904@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B92E74@uxcn10-5.UoA.auckland.ac.nz> <565C0F25.7000507@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9331B@uxcn10-5.UoA.auckland.ac.nz> <20151201005609.GD18315@mournblade.imrryr.org> <CAFggDF03fzyAw95Ka8NHtBGEcebAe3RCt5pRd3r8_nhBbR7oNw@mail.gmail.com> <3B906BDF-CA30-4EDF-ADA9-ABFC2A25014D@gmail.com> <CAFggDF2sWLr-2yXPDrznymO_E1Zx_UCm1zn92J8O84WZh2gMrA@mail.gmail.com> <A4341585-0020-4F8B-84CC-BBC0EE7F57CB@gmail.com> <CAFggDF2Mvmqc7RifSYf7Q=tJdK7oWipUQjwK=GmhgB-rvZCqdA@mail.gmail.com> <FC4B4A5A-3D42-411B-AFF9-2381DE61E63E@gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ccF_68qsHh1dwqQsh65qIeZ9_fE>
Cc: tls@ietf.org
Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 02 Dec 2015 15:15:11 -0000
On 2/12/2015, at 1:38 pm, Yoav Nir <ynir.ietf@gmail.com> wrote: > >> On 2 Dec 2015, at 2:59 PM, Jacob Appelbaum <jacob@appelbaum.net> wrote: >> >> >>> These are corporate >>> firewalls. When it comes to filtering HTTPS connections, firewalls have >>> three ways to classify the connection: >>> 1. Look at the SYN and SYN-ACK packets. Make decisions by IP addresses. >>> 2. #1, and additionally follow the stream looking for certain patterns. >>> 3. Full “TLS proxy”. > >>> Whether they are relevant stakeholders or not is to me the same question as >>> whether the network administrator in a corporate environment is a relevant >>> stakeholder. We just make the middlebox that they deploy. >> >> That is a kind of goal post shifting but seeminly weirdly not >> relevant, if I understand. If it won't trouble the middle box, it >> doesn't sound like the network administrator will have troubles. >> >> It will however reduce off-path reassembly to technique #1 from above >> and #2 will be partially eliminated and #3 isn't an option for that >> attacker anyway. >> >> We are working on solutions to #1, TLS 1.3 should reduce and if >> possible, eliminate #2, and #3 is something that should require >> consent of the user in question. Without consent, TLS 1.3 should hard >> fail closed as a security measure. > > A TLS proxy requires user consent (or at least device administrator consent) with TLS 1.2. TLS 1.3 does not change that. With SNI it’s possible to operate a transparent TLS proxy without the users consent. The proxy only has visibility of the SNI hostname - no user data (source: the company I work develops routers with such a proxy). It’s quite useful in hotspot/public wifi environments where making policy decisions based on hostname is more than sufficient, and explicit user configuration of proxy settings is a non-starter. As long as the SNI data is still available in the clear, encrypting subsequent headers won't impact the ability for our particular proxy to operate, as it’s just a generic TCP relay agent at that point. With all that being said, I think the concerns about length hiding are better addressed through other means rather than header encryption. Not sure if this is the right place to consider, but would DTLS 1.3(?) be able to encrypt headers and still handle packet loss and re-ordering? If DTLS needs cleartext headers, would it be better to advise one approach for both protocols? Regards, Mike Copley
- [TLS] Encrypting record headers: practical for TL… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Roland Zink
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Roland Zink
- Re: [TLS] Encrypting record headers: practical fo… Tony Arcieri
- Re: [TLS] Encrypting record headers: practical fo… Watson Ladd
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Henrick Hellström
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bill Cox
- Re: [TLS] Encrypting record headers: practical fo… Nikos Mavrogiannopoulos
- Re: [TLS] Encrypting record headers: practical fo… Dave Garrett
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Short, Todd
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Hubert Kario
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Viktor Dukhovni
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Fabrice Gautier
- Re: [TLS] Encrypting record headers: practical fo… Jim Schaad
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… Hubert Kario
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… John Mattsson
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- [TLS] Fully encrypted and authenticated headers (… Bryan A Ford
- Re: [TLS] Fully encrypted and authenticated heade… Dmitry Belyavsky
- Re: [TLS] Fully encrypted and authenticated heade… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Fabrice Gautier
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Fully encrypted and authenticated heade… Martin Thomson
- Re: [TLS] Fully encrypted and authenticated heade… Viktor Dukhovni
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Fully encrypted and authenticated heade… Dmitry Belyavsky
- Re: [TLS] Fully encrypted and authenticated heade… Bryan Ford
- Re: [TLS] Fully encrypted and authenticated heade… Bryan Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan Ford
- Re: [TLS] Encrypting record headers: practical fo… GUBALLA, JENS (JENS)
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Hubert Kario
- Re: [TLS] Encrypting record headers: practical fo… Yoav Nir
- Re: [TLS] Encrypting record headers: practical fo… Eric Rescorla
- Re: [TLS] Fully encrypted and authenticated heade… Eric Rescorla
- Re: [TLS] Encrypting record headers: practical fo… Mike Copley
- Re: [TLS] Fully encrypted and authenticated heade… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Watson Ladd
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Martin Rex
- Re: [TLS] Encrypting record headers: practical fo… Stephen Farrell
- Re: [TLS] Fully encrypted and authenticated heade… Eric Rescorla
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Eric Rescorla
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Martin Rex
- Re: [TLS] Encrypting record headers: practical fo… Ilari Liusvaara
- Re: [TLS] Encrypting record headers: practical fo… Fabrice Gautier
- Re: [TLS] Encrypting record headers: practical fo… Dave Garrett
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Eric Mill
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Martin Thomson
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Viktor Dukhovni
- Re: [TLS] Fully encrypted and authenticated heade… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Encrypting record headers: practical fo… Bryan A Ford
- Re: [TLS] Fully encrypted and authenticated heade… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Salz, Rich
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Watson Ladd
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Aaron Zauner
- Re: [TLS] Encrypting record headers: practical fo… Martin Rex
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Valery Smyslov
- Re: [TLS] Fully encrypted and authenticated heade… Bryan Ford
- Re: [TLS] Encrypting record headers: practical fo… GUBALLA, JENS (JENS)
- Re: [TLS] Fully encrypted and authenticated heade… Valery Smyslov
- Re: [TLS] Fully encrypted and authenticated heade… Jacob Appelbaum
- Re: [TLS] Fully encrypted and authenticated heade… Jeff Burdges
- Re: [TLS] Encrypting record headers: practical fo… Peter Gutmann
- Re: [TLS] Encrypting record headers: practical fo… Jacob Appelbaum