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