Re: [TLS] TLS interception technologies that can be used with TLS 1.3

Yoav Nir <ynir.ietf@gmail.com> Thu, 15 March 2018 22:49 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379F21241FC for <tls@ietfa.amsl.com>; Thu, 15 Mar 2018 15:49:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 lXZ74CctfBbH for <tls@ietfa.amsl.com>; Thu, 15 Mar 2018 15:49:36 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 4C8C3120454 for <tls@ietf.org>; Thu, 15 Mar 2018 15:49:36 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id h21so13306701wmd.1 for <tls@ietf.org>; Thu, 15 Mar 2018 15:49:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KKBkNXkUFolpdiIkld8m+O/+l9JwW+RT+/e+zUjj3V4=; b=MXKU6EqLU/ThSfk9NRr31GhQbrjESEqsNQo2XNGvUuXpnUM7VovUlY7TFr72HcNU3T CsIMThJwQFenyuqBseMDlob4psufmY0YeRscfRbOuqXo+VGN5n9b6QnCLiv+L9hgXOWT M8bxd12FTWb1epAWexmWV0MmS5dkJ7qK1tBAJOm7re6MlpcxKinV+2d4KD84mtk/ZNPv aWv23WiLgbcg5xiecRyXCeFkXtyqm65bQM8fz3HF0VBQ6yFlU180lRl899Ng4pCFIcxd +yLlI9ik3fZMBBYSe2FlP73KLglBFhwhEF9+9N9NCAaiZUPdT1WwWV5n7GSmD7/Kf3M0 f2/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KKBkNXkUFolpdiIkld8m+O/+l9JwW+RT+/e+zUjj3V4=; b=BBwOBdStIfP00MMjw8NUrV23iJud16XrZ0cJYMGdATrokcP9jJg1RKhYK0xXTf/f75 Uk39B37K6ACsZi3VBT15ER0kAIx7u/AuX6nUOsYfg42YRh3tvOL4YM/DFBCsASKpPvrD tzzjpLfq3dbmwrtuprsFC7v29RXxitA6/dg+2Lc/anVKE9MY4O4nIxBxNr9lmeZapJtx 5PZzjhfBcbCC/4SH0MkkneIarQGglmmzJK95PYgJ25ejsQSXBF0GGDusJ6Oaf5oCF9xj +5hmK8EaFnUssU8QkweAL1quVJcBQ2+CY/Pfwxp3y2esfZs2jf4XOMdZmHv9w/6Ml62M 8wVA==
X-Gm-Message-State: AElRT7Hlgax1yzY6Wi7rrvfyQ/plHVmV02A3wXRYYO9VabnMHGpvq2Nz dnO/OsbugLBpw7bLqJyazyw=
X-Google-Smtp-Source: AG47ELs4SAt23vObJn8TPngGfMx5kU1VdM29FXjVojDzBaFU3HbG0wCfwQcoehmqmajw414xgCDz9A==
X-Received: by 10.80.195.78 with SMTP id q14mr48814edb.254.1521154174866; Thu, 15 Mar 2018 15:49:34 -0700 (PDT)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id s56sm3012840edd.96.2018.03.15.15.49.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Mar 2018 15:49:34 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <1E3319E8-E6E6-4317-B427-3AE5B10BE3F6@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_259E18C4-28B8-45E7-94F9-56EB4A9DC746"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Fri, 16 Mar 2018 00:49:52 +0200
In-Reply-To: <619FD02D-8F30-4261-BFE9-22CCFD145BE7@akamai.com>
Cc: Richard Barnes <rlb@ipv.sx>, Hubert Kario <hkario@redhat.com>, "tls@ietf.org" <tls@ietf.org>
To: Rich Salz <rsalz@akamai.com>
References: <CACsn0cmNuuG4dhkouNzb=RDfYwG25VaKN7cGhm21wfLk-NmS5A@mail.gmail.com> <9B30F837-8F6A-4AF0-A3BD-69F9AFED5D7B@gmail.com> <2832089.SA8sAEVfAM@pintsize.usersys.redhat.com> <6BC4335A-D2E9-41FC-9F72-04B06594883B@gmail.com> <5CFD360D-818E-41A0-A140-59C283DC6CB0@akamai.com> <CAL02cgQQ7vve5+ndj1tUNgO+eH8cro2Mhhwj-bfBK=BnxECfRw@mail.gmail.com> <A2B23437-63DE-42B0-A29E-3A0635BCA85E@gmail.com> <619FD02D-8F30-4261-BFE9-22CCFD145BE7@akamai.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_kRsQvm-Eu3ceUlBHqI5h1ip9ik>
Subject: Re: [TLS] TLS interception technologies that can be used with TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 15 Mar 2018 22:49:39 -0000

Yeah, as log as we know who we’re shipping it to and the user intends for us to send it to this entity.

For the debugging case that we were talking about in Prague, sending the keys out-of-band should work fine.

For some middlebox that needs to decrypt the traffic online, it needs the keys before the first data record goes out. I don’t see how we can do that without interleaving it with the handshake.



> On 16 Mar 2018, at 0:42, Salz, Rich <rsalz@akamai.com> wrote:
> 
> I think if we ship the keys over some kind of secure socket layer we should be okay, right?
> 
> 
> From: Yoav Nir <ynir.ietf@gmail.com>
> Date: Thursday, March 15, 2018 at 6:41 PM
> To: Richard Barnes <rlb@ipv.sx>
> Cc: Rich Salz <rsalz@akamai.com>, Hubert Kario <hkario@redhat.com>, "tls@ietf.org" <tls@ietf.org>
> Subject: Re: [TLS] TLS interception technologies that can be used with TLS 1.3
> 
> IIUC not quite. There is an API, so the application that uses the library can get the keys. The application can then save it to a file, send it to a central repository, send it to the government, or whatever else it might want to do. <>
> 
> There is no built-in setting where OpenSSL writes the keys to a file, nor do applications such as web servers do this AFAIK.
> 
> It should not be difficult to write, but is not provided in off-the-shelf software.
> 
> Making the library send this in-band in some protocol extension is a far bigger endeavor. It’s also a dangerous switch to leave lying around.
> 
> 
>> On 16 Mar 2018, at 0:16, Richard Barnes <rlb@ipv.sx <mailto:rlb@ipv.sx>> wrote:
>> 
>> Just to confirm that I understand the scope of the discussion here:
>> 
>> - TLS libraries have facilities to export keys from the library
>> - Obviously, it's possible to ship these exported keys elsewhere (`tail -f $SSLKEYLOGFILE | nc $LOGBOX`)
>> 
>> So all we're really talking about is whether to define a way to do the shipment of the exported keys in-band to the TLS session.
>> 
>> 
>> On Thu, Mar 15, 2018 at 3:05 PM, Salz, Rich <rsalz@akamai.com <mailto:rsalz@akamai.com>> wrote:
>>> This is what OpenSSL provides:
>>>     https://www.openssl.org/docs/manmaster/man3/SSL_CTX_get_keylog_callback.html <https://www.openssl.org/docs/manmaster/man3/SSL_CTX_get_keylog_callback.html>
>>> 
>>> 
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org <mailto:TLS@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>