Re: [TLS] TLS@IETF101 Agenda Posted

Artyom Gavrichenkov <ximaera@gmail.com> Tue, 13 March 2018 17:32 UTC

Return-Path: <ximaera@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 724CF12741D for <tls@ietfa.amsl.com>; Tue, 13 Mar 2018 10:32:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, 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 tAw6nnKLnI1R for <tls@ietfa.amsl.com>; Tue, 13 Mar 2018 10:32:18 -0700 (PDT)
Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 28C781267BB for <tls@ietf.org>; Tue, 13 Mar 2018 10:32:18 -0700 (PDT)
Received: by mail-ua0-x236.google.com with SMTP id b13so267628uam.10 for <tls@ietf.org>; Tue, 13 Mar 2018 10:32:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ICsRl/2RIirGBd4m19QCBcF5vYE8+sRNOiZb/q/WcRA=; b=kkh2EHtYE/RQJdBFGkyGOpuXxISKBn1h3Sdzx8BGUBpVPTEQHWGOS5LcQVmF9bD6S/ loTBX9GLgtY1hIQlpp3N6HxnvmQht/NYadjAIHnc+Mu5i8nE3sdmzPbtQ8yJzsflS59u NjLxA/wp1phwOzXVYveU3f/UTQAKpQTYxMC/wfzcOp/OzF2CzbA1Xkk0/voUCkJoNtaK 2farEQ+GpNEr5bxhyj12v4hnbfXx4QelX9ba8fBwUkAEPrQ331a0Fok+5v/hWwYu/Dr8 qpvN08Ba60zp3xMRHeSIkyn4i//c8lPYZkTiGNPDhUDoLyyWcHNVQjB7RfxieNDiB4OW imPg==
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=ICsRl/2RIirGBd4m19QCBcF5vYE8+sRNOiZb/q/WcRA=; b=g+mrZ3t8Ml/mk+8UHoUc9gE++aAvo3zO59Kl2C8UsEYxEXcUG1jZfMHGpYexyg/FcD K22JCk2TBL4Tm3VjpYcBhR07r/XLdx1GHxBs2YjB8M45Xxo3Joqu47V7U/N+LkUPw1B1 sluFjpkSuh3bKTxboyy312gRatC6Tq+wzbYFxAPqPNJcsKIQKv5opr70BD3GZMe5owUz TXQzJG51tdDh+u5EKFuYLDba5fK5oA6V2+AzhPyfHZ0qwW8SAOE4YFmUmYUIm2mLsC/k 4OmCZ+zXnkwAQ/MlWF256VrjYNEasp45GpUaLjcbirSaozXuNe3SXv+/8LYOrPdBWYLN 6Htw==
X-Gm-Message-State: AElRT7GgQQ+e+nHSMf8F/F/KHZAON8lBHGhTolmpy3fc6UfZHPutPSKW IiDaCcZzNN4nK8zQtWOAdXdBeRPyrL1cs8cVd2o9ByAn
X-Google-Smtp-Source: AG47ELsy979+6p9Iv+hHAzEUjKJ8kmMt7sO7L7OBl8Jdj/Uou/7CLUNbU4YLBvVjWKAvgzxcezP4mwlBoJ1013eghAk=
X-Received: by 10.176.9.224 with SMTP id e32mr1160738uah.186.1520962337013; Tue, 13 Mar 2018 10:32:17 -0700 (PDT)
MIME-Version: 1.0
References: <6140B7A6-A1C7-44BC-9C65-9BE0D5E1B580@sn3rd.com> <986797a7-81b0-7874-5f39-afe83c86635b@cs.tcd.ie> <CAOgPGoBYc7O+qmjM-ptkRkE6mRsOYgc5O7Wu9pm3drFp3TVa6Q@mail.gmail.com> <d7dfdc1a-2c96-fd88-df1b-3167fe0f804b@cs.tcd.ie> <CAHbuEH7E8MhFcMt2GSngSrGxN=6bU6LD49foPC-mdoUZboH_0Q@mail.gmail.com> <1a024320-c674-6f75-ccc4-d27b75e3d017@nomountain.net> <2ed0gc.p5dcxd.31eoyz-qmf@mercury.scss.tcd.ie> <d7ec110f-2a0b-cf97-94a3-eeb5594d8c24@cs.tcd.ie> <CAAF6GDcaG7nousyQ6wotEg4dW8PFuXi=riH2702eZZn2fwfLQw@mail.gmail.com> <CAPsNn2XCNtqZaQM6Bg8uoMZRJE+qQakEwvw8Cn9fBm-5H+Xn_A@mail.gmail.com> <CABcZeBNpMekXPRYiLe3oGCjhuu3X+9zuLVnbiz1TnhymVWAMgQ@mail.gmail.com>
In-Reply-To: <CABcZeBNpMekXPRYiLe3oGCjhuu3X+9zuLVnbiz1TnhymVWAMgQ@mail.gmail.com>
From: Artyom Gavrichenkov <ximaera@gmail.com>
Date: Tue, 13 Mar 2018 17:32:05 +0000
Message-ID: <CALZ3u+ZgXT5+9z2SayYK6ocNS2iaGdnT5SjZYziTZT2w33=gZg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>, nalini elkins <nalini.elkins@e-dco.com>
Content-Type: multipart/alternative; boundary="f403043ee33cd084cb05674ea317"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/JeFThNC-0zDKnBMFS6hkbHI3InU>
Subject: Re: [TLS] TLS@IETF101 Agenda Posted
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: Tue, 13 Mar 2018 17:32:20 -0000

Hi Eric,

The author probably refers to a case where an infosec dept of an enterprise
will not just disable TLSv1.3 on the servers, but will also set up some
deep-juju DPI for filtering v1.3 in transit to make sure no one will enable
v1.3 accidentally somewhere.

As those DPI solutions are often of questionable reliability, that may
affect other transit users of that network.

вт, 13 мар. 2018 г., 13:24 Eric Rescorla <ekr@rtfm.com>;:

> On Tue, Mar 13, 2018 at 8:58 AM, nalini elkins <nalini.elkins@e-dco.com>;
> wrote:
>
>> Stephen (and TLS group)
>>
>> We need to look at the bigger picture.
>>
>> The TLS working group has been concentrating on making the Internet
>> secure for the individual user.    We feel that there is also an underlying
>> motivation to help the underdog and protect the political dissident.  These
>> are all laudable goals.
>>
>> But, the Internet is much more than that.  The Internet is the
>> underpinnings of much of the business community which is utilized by
>> consumers (end users).   Making a change which makes businesses less secure
>> because crucial functions cannot be done will lead to enormous chaos and
>> disruption.   Many businesses are likely to not want to adopt TLS1.3 or
>> seek unique DIY type alternatives.  In fact, we have already heard of some
>> planning to block TLS 1.3 traffic just for this reason.
>>
>
> As a break from the meta-discussion about whether this topic should be
> on the agenda, I'd like to make a technical point. There are two
> separate settings where TLS 1.3 makes inspection more difficult:
>
> 1. Cases where the inspecting entity controls the server and does
>    passive inspection: TLS 1.3 mandates PFS and so designs
>    which involve having a copy of the server's RSA key won't work
>
> 2. Cases where the inspecting entity controls the client and does
>    MITM: TLS 1.3 encrypts the certificate and so conditional
>    inspection based on the server cert doesn't work (though see [0]
>    for some of the reasons this is problematic.)
>
> The two drafts under discussion here only apply to case #1 and not to
> case #2. However, for case #1, because you control the server, there's
> no need to look at blocking TLS 1.3, you merely need to not enable it
> on your server, so this framing is a bit confusing.
>
>
> -Ekr
>
> [0] https://www.imperialviolet.org/2018/03/10/tls13.html
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>