Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Roland Zink <roland@zinks.de> Wed, 25 October 2017 16:21 UTC

Return-Path: <roland@zinks.de>
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 45F26138BDB for <tls@ietfa.amsl.com>; Wed, 25 Oct 2017 09:21:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de
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 B1wsyQ4zW9WW for <tls@ietfa.amsl.com>; Wed, 25 Oct 2017 09:21:41 -0700 (PDT)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72EA0138AED for <tls@ietf.org>; Wed, 25 Oct 2017 09:21:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1508948499; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:MIME-Version:Date:From:References:To: Subject; bh=guABaOm6A0h7AXWIYBhdhC8oxhcmLwV7vdz0tJjMoHE=; b=nXwmNRP1bjwvcTCuYX4IwhfWTCaB3hXiMCBbc/Y/PwiByxef3WcNwB6umrhHLMXDbU byh8NJyYrB4DCPun5v2YYblJ1MJVHxrbKMnMpbAm9+DaRoQtbuU1HL1nC74tG18hwi0O 1zZbUOPL/qfs662qCngG0wBCO5V5qXlbMonls=
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKn1oaZ1h8oElbYgmd7hPw=
X-RZG-CLASS-ID: mo00
Received: from [10.10.10.82] (p57B97B8D.dip0.t-ipconnect.de [87.185.123.141]) by smtp.strato.de (RZmta 42.8 DYNA|AUTH) with ESMTPSA id Y0538ft9PGLdTUk (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for <tls@ietf.org>; Wed, 25 Oct 2017 18:21:39 +0200 (CEST)
To: tls@ietf.org
References: <cde0e322-797c-56e8-8c8d-655248ed7974@nist.gov> <FB95CAC8-C967-4724-90FB-B7E609DADF45@akamai.com> <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <49EFAAD0-8457-4775-AE21-1D270872CD56@akamai.com> <f741b067-e7af-5231-4bb1-a0c2d151e6bf@nist.gov> <E775B188-59A0-4D87-A70F-638A2AD4C307@akamai.com> <4f1b6a8d-688b-a286-6d0e-46f7f6a3cdd6@nist.gov> <EE940D69-7137-4957-8118-42DAFB173500@akamai.com>
From: Roland Zink <roland@zinks.de>
Message-ID: <0c39a8cb-3fc9-e91b-9230-ccc3d6afe999@zinks.de>
Date: Wed, 25 Oct 2017 18:21:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <EE940D69-7137-4957-8118-42DAFB173500@akamai.com>
Content-Type: multipart/alternative; boundary="------------9A456636509F617067C0122B"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/aJzbRPPbxLpsSsps7uMLpi_Vjmc>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
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, 25 Oct 2017 16:21:44 -0000

It could but RFC 7469 section 2.6 
(https://tools.ietf.org/html/rfc7469#section-2.6) says:


"  It is acceptable to allow Pin
    Validation to be disabled for some Hosts according to local policy.
    For example, a UA may disable Pin Validation for Pinned Hosts whose
    validated certificate chain terminates at a user-defined trust
    anchor, rather than a trust anchor built-in to the UA (or underlying
    platform)."


and most browsers seem to follow this mitm exception.

Regards,
Roland


Am 25.10.2017 um 18:06 schrieb Salz, Rich:
>> since those other means would be easier and more effective. You
>      have done nothing to suggest otherwise.
>    
> Public-key pinning and CT seem like they would prevent those other mechanisms.  No?
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls