Re: [OPSEC] [TLS] OpSec WGLC for draft-ietf-opsec-ns-impact
Eric Rescorla <ekr@rtfm.com> Thu, 20 August 2020 19:14 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 2A3723A12E9
for <opsec@ietfa.amsl.com>; Thu, 20 Aug 2020 12:14:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001,
URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key)
header.d=rtfm-com.20150623.gappssmtp.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 fqwTAt2-qrMG for <opsec@ietfa.amsl.com>;
Thu, 20 Aug 2020 12:14:25 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com
[IPv6:2a00:1450:4864:20::22b])
(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 9C4793A12ED
for <opsec@ietf.org>; Thu, 20 Aug 2020 12:14:24 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id t23so3350245ljc.3
for <opsec@ietf.org>; Thu, 20 Aug 2020 12:14:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=rtfm-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=bMTXMwfq5tFlnZ0xzonGdtOtYOU+OW/qI6iRdMXFZt0=;
b=OMMjTC0Xh4rsRemlfuNKmGkvgSY4RYzxIrgWn2jAJXW+y5/mHg7MYoY72EbR4PegfK
vReBqtlSui5l7LxYMe/jAKDATJtBOrHV6pegxhBksm5yvwxNiZvD6j/771jXvfIQEQtx
PT9oXRgFcxSMejTfNxPZoERGShJuJXdTAS6NIV234x4p8tkeGscfu3fSACOHMbN9holo
4tlkdhSGimBx8vtL7TW0yER1o+u24Nq2kGAEk7p/VyMkHR/hntph40QIXUZ4VfNwOPaP
Myve/xU1KtiHcPUDTRpQ0GMZY6nncFK/1ZHOgl2aKNRYwYOOhCpgCbEWAz/T29n03nPs
NVyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=bMTXMwfq5tFlnZ0xzonGdtOtYOU+OW/qI6iRdMXFZt0=;
b=I/Sbf9BExsfrLA9XFJd2odsFKTmUKb4aE9ZZZBfIDAmVELyuXSOEK5Vi3jpC21TGTz
WiKNBH7j0ChGcuRUr0Ke8LY9WPa+oyaX6zx5Ku8ijUjFa4Pbra2KE0hF/0WrjX8kVynv
0W/agaHfLGrml6M14IVE/JyS+ylOXOOXsX3ndx8UhKy/F209JnsHfZD/M8gaXB3uzGYx
UVPy3ZWt4ro7xdeOsV+iRk9YWUJAWjh+DmdbZV/35Ds9IE8Qnmynr8Co8trUv6h5r458
cUoVETRP1GAKOkcEHtpVhxiSaHnRkxlPAaJnw617UJ3PZ65kwD7nOlAwmoYZvryRVAuF
KPxw==
X-Gm-Message-State: AOAM532yDjg5TSHVjyp1LYRCtW0HLKgHYM85QrVIn1WCOoQG2p06ardn
o2SIgUJicqMolJDuJh4gOOCL0ErPnYi2r7y4M+4uqZat/Na3ow==
X-Google-Smtp-Source: ABdhPJywNhh62PEAdKpjAe0N4TPehgVrUmQZHqB893NR3NDJBr+Iion//cEbhrzlcPAk2Ir4RbjqhTR9jMXRBPIEXbA=
X-Received: by 2002:a2e:3609:: with SMTP id d9mr2040394lja.17.1597950862600;
Thu, 20 Aug 2020 12:14:22 -0700 (PDT)
MIME-Version: 1.0
References: <20200817163938.07580cee@totoro.tlrmx.org>
<2B1FF3B4-949A-4A29-ABDC-B2B91878B947@cisco.com>
<20200819234314.29c3bbdc@totoro.tlrmx.org>
<387460EC-D00A-4D12-9E12-713E9E0049B1@nerd.ninja>
In-Reply-To: <387460EC-D00A-4D12-9E12-713E9E0049B1@nerd.ninja>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 20 Aug 2020 12:13:45 -0700
Message-ID: <CABcZeBMrx6HdOG98Ou78s5WOhDBi6Yts-wnuRW_U_NHEDQ7B8Q@mail.gmail.com>
To: Roelof DuToit <r@nerd.ninja>
Cc: Nick Lamb <njl@tlrmx.org>, "opsec@ietf.org" <opsec@ietf.org>,
"tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000088c47705ad53ed92"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/yN-MUI7rLY8Vggg1Pvdy4QNff-M>
Subject: Re: [OPSEC] [TLS] OpSec WGLC for draft-ietf-opsec-ns-impact
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>,
<mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>,
<mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Aug 2020 19:14:27 -0000
On Thu, Aug 20, 2020 at 7:01 AM Roelof DuToit <r@nerd.ninja> wrote: > As co-author I am not a proponent of passive TLS inspection - not least > because of the ossification implications. It cannot be labeled as > ineffective though (see further comments below), even if the document > strongly hints at not using passive TLS inspection in a post-TLS-1.2 world. > > > On Aug 19, 2020, at 6:43 PM, Nick Lamb <njl@tlrmx.org> wrote: > > > > The passive eavesdropper can indeed see the handshake in TLS 1.2, but > > since they were not a participant they don't actually know what it > > means even though it wasn't encrypted. > > > > For example, suppose an RSA certificate is sent and the handshake seems > > to agree RSA key exchange and Client sends an EncryptedPreMasterSecret. > > The passive eavesdropper has no idea if that's actually encrypted to the > > RSA public key from the certificate, it's just an opaque blob. > > > > > > Thus it's easily possible for an eavesdropper to witness a handshake in > > which the eavesdropper believes what happened is: > > > > Client proposed to do RSA key exchange > > Server showed a certificate for www.local-hospital.example > > Client sent an EncryptedPreMasterSecret to the local hospital > > both agreed this all worked fine and continue encrypted > > > > The eavesdropper's "Don't eavesdrop on people's medical stuff" policy > > kicks in and it allows the connection unmolested. Unfortunately what > > really happened is: > > > > Client proposed to do RSA key exchange > > Server showed a certificate for www.local-hospital.example > > Client sent an EncryptedPreMasterSecret for the GRU data exfiltration > > server ignoring the bogus certificate > > $5Bn of stolen commercial documents are uploaded to the server > > > Advanced passive TLS inspection devices use a combination of techniques to > defend against those attacks for TLS 1.2 (and below): > 1. Policy-based control over the use of RSA key exchange. It should not > be allowed. > 2. Checking the signature in the ServerKeyExchange message when (EC)DHE > key exchange is used. > 3. Not trusting the destination IP address. The hostname from the SNI is > resolved and compared. > > None of those techniques are perfect given an advanced adversary that > controls the client + DNS in the enterprise + the flow of traffic on the > server side of the TLS inspection device. > (Side note: If I’m an attacker that has control over DNS then I would not > bother with TLS-based attacks for data exfiltration). > In other words, nation state attacks might succeed but it does not mean > that passive TLS inspection devices are not effective against other attacks. > It seems to me that the conditions under which this kind of inspection works and does not work are quite subtle. If you want to proceed with this document, it would probably be good to document them, -Ekr
- [OPSEC] OpSec WGLC for draft-ietf-opsec-ns-impact Jen Linkova
- Re: [OPSEC] OpSec WGLC for draft-ietf-opsec-ns-im… tom petch
- Re: [OPSEC] [TLS] OpSec WGLC for draft-ietf-opsec… Nancy Cam-Winget (ncamwing)
- Re: [OPSEC] OpSec WGLC for draft-ietf-opsec-ns-im… Jen Linkova
- Re: [OPSEC] [TLS] OpSec WGLC for draft-ietf-opsec… Nancy Cam-Winget (ncamwing)
- Re: [OPSEC] [TLS] OpSec WGLC for draft-ietf-opsec… Stephen Farrell
- Re: [OPSEC] [TLS] OpSec WGLC for draft-ietf-opsec… Rob Sayre
- Re: [OPSEC] OpSec WGLC for draft-ietf-opsec-ns-im… tom petch
- Re: [OPSEC] OpSec WGLC for draft-ietf-opsec-ns-im… Jen Linkova
- Re: [OPSEC] [TLS] OpSec WGLC for draft-ietf-opsec… Bill Frantz
- Re: [OPSEC] [TLS] OpSec WGLC for draft-ietf-opsec… Nancy Cam-Winget (ncamwing)
- Re: [OPSEC] [TLS] OpSec WGLC for draft-ietf-opsec… Roelof DuToit
- Re: [OPSEC] [TLS] OpSec WGLC for draft-ietf-opsec… Eric Rescorla