IETF Logo Mail Archive

[TLS] comment on draft-kinnear-tls-client-net-address

Hubert Kario <hkario@redhat.com> Mon, 25 March 2019 11: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 70A9D1203F0 for <tls@ietfa.amsl.com>; Mon, 25 Mar 2019 04:30:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 RbaOZgHhCY5h for <tls@ietfa.amsl.com>; Mon, 25 Mar 2019 04:30:37 -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 3E538120416 for <tls@ietf.org>; Mon, 25 Mar 2019 04:30:37 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 836D93088B75 for <tls@ietf.org>; Mon, 25 Mar 2019 11:30:36 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (ovpn-200-45.brq.redhat.com [10.40.200.45]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1A6E95D72F for <tls@ietf.org>; Mon, 25 Mar 2019 11:30:35 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Mon, 25 Mar 2019 12:30:29 +0100
Message-ID: <1635428.JdYyXqVr20@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart4574456.FdPygpSZcb"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Mon, 25 Mar 2019 11:30:36 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-77bu3qRDyN9d8snFtNxp0GEU7E>
Subject: [TLS] comment on draft-kinnear-tls-client-net-address
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: Mon, 25 Mar 2019 11:30:43 -0000

I wanted to rise one comment on the IETF session, but we ran out of time:

given that TLS is a providing integrity and authenticity to the IP address 
information, shouldn't the protocol require the client to perform the full 
handshake and only then request information from the server? I.e. make it a 
post-handshake messages, like KeyUpdate, rather than an extension.

I worry that some clients may short-circuit processing and do the handshake 
only up to EncryptedExtensions, without processing CertificateVerify or 
Finished (in case of PSK), and in result expose themselves to MitM attacks.
-- 
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

v2.23.0 | Report a Bug | By Email