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"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ec5QmzBeHKgjrwyocX5qVfaMySg>
Subject: Re: [TLS] TLS Impact on Network Security draft updated
Precedence: list

--nextPart2108931.upD5VemBPa
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

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 i=
t=20
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.=20

Also, the people that are pushing against the IETF consens should not light=
ly=20
dismiss it, even (or especially), if the answers are not the ones that they=
=20
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
>=20
>  ALERT This email was sent from a source external to BCBSM/BCN.
>  DO NOT CLICK links or attachments unless you recognize the sender and tr=
ust
> the content.
=20
>=20
> 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, a=
nd
> it does not even focus on solutions to move the web further.=20
> 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.).
=20
> Is there precedent for publishing such a document as an RFC?
>=20
> 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.
=20
> So there is precedent.
>=20
> Sincerely,
> Watson
>=20
>=20
> 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.
>=20
>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
> nonprofit corporations and independent licensees of the Blue Cross and Bl=
ue
> Shield Association.


=2D-=20
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00  Brno, Czech Republic
--nextPart2108931.upD5VemBPa
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAl04T1sACgkQkqjRuAHS
9fXE4Q/9HQTFH3qnRjTC/n5mra9Q3XbrIo2fLjAqrkPoM9weNnpO1p90FsQtsSQt
oFOrkuPpzl4Yq+d2GfnysHex3q1GOZ4zflEWScyyZM7EmlxWZ2WXEh92OyPHc91/
YORZL7PcPkXas2+dLBCXfgQOZJNlN28m5oOhdQQ6wGwN2QDbJ4AXZcgbTdbH3qd2
6YnQMeaVc2Ae4Tq6xRMs6CNtAtczF8/YsWLjBgIb5a2McBiBZ1dRhdPby8YQEdQV
K4TCODovsfo5TWAmL/zabSX7EBasaIcoBK+aqnPidEBIVhuwEBviOSVrQ9Yg/FbC
rYgIdYVlOgST2OkrbxNpdSAoF3Wzv1E3RvSYQMRa2mAhXn8IMvbCkm4UDUslw9zk
CS0MjZ6VmYrbJGP65XJt4TVEGSOsVpCAlbTry9ouwxG3mrSnCxn6h1R+yVG65xsq
Wulc+ypHoKu2iFRPTLYAvhP/ehaNK+x03e0h0eKWs9qcudZEKezKt0mTrlJovRiw
lU0zoiIZA3dRcXkZC4rmgorD73pffSCOnY0mgoifEMp3FXVTCW/iWCRlftLZ5Eal
nYxSRyZCNo2n/PG4mQGEKhtprcmEFZj4JpVsuvmE6w8XwpB48zpOL06NCAt1lMYS
enk12tc2t52cdGTEg9t/A1J4c5V9m7FeAz3PszEC3a9c3GVwyjI=
=R9FF
-----END PGP SIGNATURE-----

--nextPart2108931.upD5VemBPa--