Re: [TLS] TLS@IETF101 Agenda Posted

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Wed, 14 March 2018 03:30 UTC

Return-Path: <kathleen.moriarty.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 85CF5124B17 for <tls@ietfa.amsl.com>; Tue, 13 Mar 2018 20:30:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 L_s3GKYsj2U5 for <tls@ietfa.amsl.com>; Tue, 13 Mar 2018 20:30:36 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 ACD1D120726 for <tls@ietf.org>; Tue, 13 Mar 2018 20:30:36 -0700 (PDT)
Received: by mail-io0-x235.google.com with SMTP id e30so2633381ioc.3 for <tls@ietf.org>; Tue, 13 Mar 2018 20:30:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UUJblP/f8s8JOd5cMLDI4ZLCiSpKTtidAmdKyc+G1Y4=; b=kFncybt98gpfxJUEs/xiWhDsMrhOSQvM1EdvH9rjPfqYmOoS6Rl2AECMokIyl/oPqE IG+hrQfyanpRtONEVss7C5Nem6siiLCwb1t9VHHOEoKcgem6Rdpezt0WYjAl+0jcP/SJ PvbHVB8DOzVT1y8BJ7YltriF/6PBkJ8+jJ+CJGy6s+tbzgVF7W3uOQZtz2zKl0BWxEcz wkJgb0cxbuEuz0asrF+RpbqLohzt9Eez8ojqFC5gYHUM71YJjswhsK5camdbJAXUBSOO /Etyik5/ugfafsAfNereu2StoGuodhFKerMUloICEbNpjaF9bM3GuJvNKhAdLwCXRb9C DzMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UUJblP/f8s8JOd5cMLDI4ZLCiSpKTtidAmdKyc+G1Y4=; b=K5D0UidpzEzC61my26QQcQaT5THFX0+xAvpOzNQBI5ER1+rPjTYF5RZMhAYiXMQDlB p5kN2+yHWCt409upum8Af8mBTg+jxgthzbkHoxeVIMWo++u3I4MkQuYAPXNkKYVm1sZr y6vjNOLqAUYmYPqlC0JbMjdbnPcn6U2yVSCMRDXFm39Rhsh5bT5yvaV0PMTMrXIr+aZI xfsY6lvN/dkxaCSOJXeXrbOoE2/lVnwANCEehldeuk1YG4hfFRfVwAQCFJUZ841KGXcv DZcYhtXVZNeTyit4FncXTNlmd3je4H9O/QiHhJNxupK0PcBkNcFegCr4yxpHJQeGQGiL N+gQ==
X-Gm-Message-State: AElRT7HMvD6CnmEm01nJ4vCZIK3kf/9LUd5E+5uS150bhoEo0FWxe6g5 TZrUu/MVDQyq7ZI0e7DLa/ppV44g56dgaeEUsao=
X-Google-Smtp-Source: AG47ELuiLd4prsw4nuQWBRlv4OP4NrYuiVlAr/jL8GhDS87ueKc8VL6g/LPwI3sEvIVlQ/1IQuMc5M2veHrc/B8sbw8=
X-Received: by 10.107.34.80 with SMTP id i77mr3115659ioi.220.1520998235976; Tue, 13 Mar 2018 20:30:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.192.156.137 with HTTP; Tue, 13 Mar 2018 20:29:55 -0700 (PDT)
In-Reply-To: <7AD6659C-C85E-4AD1-A85A-3789471258FA@vigilsec.com>
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> <3F8142DE-EADB-4AB9-A204-7D87ACDCD3E3@akamai.com> <CAPsNn2VE_7+rWT0fp9rrVnZrgcY7ORLWTee+kf_Av1dqm4CiDQ@mail.gmail.com> <CB55AABB-8937-4F6B-B5AC-B6F262F08A4F@akamai.com> <CAPsNn2U_xG28Tumo3oRkQ+6=BHzgv-6YtgNSpwvhdFFRWc7EQQ@mail.gmail.com> <2DC45296-244E-4C72-8B3C-DE47EADAC2DE@fugue.com> <BN7PR14MB23696A2767FF9C1A410110AFD7D20@BN7PR14MB2369.namprd14.prod.outlook.com> <090F06AF-371D-4B11-91AA-BD80C1ADB4E9@fugue.com> <C1970611-C781-41A8-87CA-D00629AC41E7@vigilsec.com> <35A28548-B200-447A-A3EC-365AAD491858@fugue.com> <7AD6659C-C85E-4AD1-A85A-3789471258FA@vigilsec.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Tue, 13 Mar 2018 23:29:55 -0400
Message-ID: <CAHbuEH4Sby-6Mi+5cWg7tvYSsL4Z6ALgUjpWNzbe-Ou2o0XmsA@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Cc: Ted Lemon <mellon@fugue.com>, IETF TLS <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/DxRyxLq58UAk1vCgXPzweWYwpFg>
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: Wed, 14 Mar 2018 03:30:39 -0000

Clarifying question

On Tue, Mar 13, 2018 at 10:55 PM, Russ Housley <housley@vigilsec.com>; wrote:
> Ted:
>
> I do not follow.
>
> This is a bogus argument.
>
>
> I'm pretty sure there's a Monty Python skit about this, so I won't belabor
> the point.
>
>
> I'll avoid asking how many sparrows are needed ;-)
>
> First, staying with an old protocol version often leads to locking in
> unmaintained versions of old software.
>
>
> Right, that's one of the stated goals of this work: to be able to continue
> to use software that the operator can't upgrade.
>
>
> No, the enterprise wants to use maintained server implementations.
>
> Second, using TLS1.2 does not technically address the issue.  If the client
> were to exclusively offer DHE-based ciphersuites, then the visibility
> techniques that have been used in the past are thwarted.
>
>
> The client in this case is under the control of the operator, so this is a
> non-issue.
>
>
> In some cases, the client in the load balancer is under the control of the
> enterprise.  In other cases, the client is in the customer browser, and
> opt-in is very significant.

When you say customer browser, do you mean the users on the enterprise
network behind the firewall, all within the control of the enterprise
that owns the data?  I think this is what is meant since the Internet
sessions from customers could be terminated at a load balancer on the
enterprise edge and then this extension may be used between servers
internal to the enterprise and from what you are saying, browsers as
well.  Or is the plan for this to be opt-in from the customer external
to the enterprise (I didn't think that was the case and it would be
good to clarify).  This distinction would be helpful to know where
traffic may be intercepted if there were another party that might be
malicious.

Thanks,
Kathleen

>
> Russ
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 

Best regards,
Kathleen