Re: [TLS] TLS Impact on Network Security draft updated

Hubert Kario <hkario@redhat.com> Wed, 24 July 2019 12:30 UTC

Return-Path: <hkario@redhat.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 BB2EB1200EC for <tls@ietfa.amsl.com>; Wed, 24 Jul 2019 05:30:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 qMOMr266n-YR for <tls@ietfa.amsl.com>; Wed, 24 Jul 2019 05:30:27 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CE251200C4 for <tls@ietf.org>; Wed, 24 Jul 2019 05:30:27 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 98CA13DE0F; Wed, 24 Jul 2019 12:30:26 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (ovpn-200-50.brq.redhat.com [10.40.200.50]) by smtp.corp.redhat.com (Postfix) with ESMTP id 46193601B7; Wed, 24 Jul 2019 12:30:25 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Wed, 24 Jul 2019 14:30:19 +0200
Message-ID: <5650096.7ke3dDvEqm@pintsize.usersys.redhat.com>
In-Reply-To: <DM6PR14MB24745D7DDD5F1503387A7694D7C60@DM6PR14MB2474.namprd14.prod.outlook.com>
References: <6AF48228-19C2-41C7-BA86-BA16940C3CFF@cisco.com> <CACsn0cmxuUTxAGxdmmtyg7BX0GPJLht343CRcFrakLvsbKM2zQ@mail.gmail.com> <DM6PR14MB24745D7DDD5F1503387A7694D7C60@DM6PR14MB2474.namprd14.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2108931.upD5VemBPa"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 24 Jul 2019 12:30:26 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ec5QmzBeHKgjrwyocX5qVfaMySg>
Subject: Re: [TLS] TLS Impact on Network Security draft updated
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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, 24 Jul 2019 12:30:30 -0000

On Wednesday, 24 July 2019 05:17:37 CEST Ackermann, Michael wrote:
> This should not be dismissed as small segments of industries.    This
> represents ubiquitous use cases at all large organizations in Insurance,
> Health Care, Banking, Automotive and many others.

Not "all" and not "ubiquitous", the word you're looking for is "some". As it 
was pointed out many times already on this mailing list.

> We as the IETF should
> not lightly dismiss such significant numbers and volume, even (or
> especially),  if the answers are not easy ones. 

Also, the people that are pushing against the IETF consens should not lightly 
dismiss it, even (or especially), if the answers are not the ones that they 
would like to hear.

> From: TLS <tls-bounces@ietf.org> On Behalf Of Watson Ladd
> Sent: Tuesday, July 23, 2019 6:58 PM
> To: Filippo Valsorda <filippo@ml.filippo.io>
> Cc: TLS List <tls@ietf.org>
> Subject: Re: [TLS] TLS Impact on Network Security draft updated
> 
>  ALERT This email was sent from a source external to BCBSM/BCN.
>  DO NOT CLICK links or attachments unless you recognize the sender and trust
> the content.
 
> 
> On Tue, Jul 23, 2019, 3:47 PM Filippo Valsorda
> <filippo@ml.filippo.io<mailto:filippo@ml.filippo.io>> wrote:
> Before any
> technical or wording feedback, I am confused as to the nature of this
> document. It does not seem to specify any protocol change or mechanism, and
> it does not even focus on solutions to move the web further. 
> Instead, it looks like a well edited blog post, presenting the perspective
> of one segment of the industry. (The perspective seems to also lack
> consensus, but I believe even that is secondary.) Note how as of
> draft-camwinget-tls-use-cases-05 there are no IANA considerations, no
> security considerations, and no occurrences of any of the BCP 14 key words
> (MUST, SHOULD, etc.).
 
> Is there precedent for publishing such a document as an RFC?
> 
> I was going to say RFC 691 but no, it recommends changes to the protocol (as
> well as being quite amusing). RFC 4074 comes close describing bad behavior
> without an explicit plea to stop doing it, but has a security
> considerations section. RFC 7021 describes the impact of a particular
> networking technique on applications.
 
> So there is precedent.
> 
> Sincerely,
> Watson
> 
> 
> The information contained in this communication is highly confidential and
> is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you are
> hereby notified that any viewing, copying, disclosure or distribution of
> this information is prohibited. Please notify the sender, by electronic
> mail or telephone, of any unintended receipt and delete the original
> message without making any copies.
> 
>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
> nonprofit corporations and independent licensees of the Blue Cross and Blue
> Shield Association.


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic