Re: Proposed Statement on "HTTPS everywhere for the IETF"

Hector Santos <hsantos@isdg.net> Sun, 07 June 2015 06:11 UTC

Return-Path: <hsantos@isdg.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4EA1A87F0 for <ietf@ietfa.amsl.com>; Sat, 6 Jun 2015 23:11:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.001
X-Spam-Level:
X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 heAsZsltBqZI for <ietf@ietfa.amsl.com>; Sat, 6 Jun 2015 23:11:53 -0700 (PDT)
Received: from secure.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 421871A87EF for <ietf@ietf.org>; Sat, 6 Jun 2015 23:11:53 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2471; t=1433657508; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=lQCithLHcNZZll3bbJhf1nOhWvg=; b=BIWzUplKrgWitbN2AdIJF0WDAfBAXCpTZ4oA9JiBBwEnwoKL65u0/8AlIM3G/u YX5ZEUQIiiPZH95AeOHWef/m9Mrn3dHPiQgBfGQorMPDqSGkPIwzMOmqpibuld42 adLLVtq6H8apBsdJ+46gE8JqB4d1Aqd2+F3LDhfX4+shU=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Sun, 07 Jun 2015 02:11:48 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer);
Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3072503225.6740.4892; Sun, 07 Jun 2015 02:11:47 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2471; t=1433657180; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=tLgWdhM mJXFMhoJaKS6TSTPvfKBKubPnNAgotPPbVDI=; b=sqLJk66iCOWpC44Xx0hXN6J 1ApdDQEGklnxUpVJxyRv3CW0oXSP/QTumVwXiD4dyM54bwSHOgLI4xQMqlK9kI6G 2Z7a5YEGHVCXXil8+IsCkLIV4l76l47hXt9Ezr28Y397Iq2vFpz1IUpRRBaiG0ao b2dOsCVGG1LYr479hM0I=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Sun, 07 Jun 2015 02:06:20 -0400
Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1664749099.9.37712; Sun, 07 Jun 2015 02:06:19 -0400
Message-ID: <5573E09D.2030400@isdg.net>
Date: Sun, 07 Jun 2015 02:11:41 -0400
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: Xiaoyin Liu <xiaoyin.l@outlook.com>, "Niels Dettenbach Syndicat.com" <nd@syndicat.com>, Jari Arkko <jari.arkko@piuha.net>, IETF <ietf@ietf.org>
Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"
References: <20150601164359.29999.35343.idtracker@ietfa.amsl.com>, <CAL02cgRPFooA5fVFwvdprb3wPD+Y55pD+7RWjkACDv7T_TBW5Q@mail.gmail.com>, <1472054.O9DP0qoCQf@gongo> <556CBCF5.3060402@alvestrand.no>, <1C4D741C-89EA-4973-8536-D6A02EFD7624@syndicat.com>, <556D4C38.6060704@alvestrand.no>, <1F11D864-2532-4971-9771-F8037989A9BB@piuha.net>, <70AA892E-C97F-4EEA-9BB8-829F654FA57F@syndicat.com>, <557310E6.4010109@isdg.net> <BAY180-W22CC446142733EDDCB5407FFB00@phx.gbl> <5573DD2E.2070505@isdg.net>
In-Reply-To: <5573DD2E.2070505@isdg.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/MAPSRmxuCzbiPgrLonh_cJ54hPY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Jun 2015 06:11:55 -0000

Small correction, July 2016, not July 2015, is the new TLS v1.1/1.2 
compliant deadline for PCI v3.1.  From the PCI/DSS reference below:

Removed SSL as an example of a secure
technology. Added note that SSL and early
TLS are no longer considered to be strong
cryptography and cannot be used as a security
control after June 30, 2016. Additional
guidance provided in Guidance column. Also
impacts Requirements 2.3 and 4.1.


-- 
HLS


On 6/7/2015 1:57 AM, Hector Santos wrote:
> On 6/6/2015 11:08 PM, Xiaoyin Liu wrote:
>>> Date: Sat, 6 Jun 2015 11:25:26 -0400
>>> From: hsantos@isdg.net
>>> To: nd@syndicat.com; jari.arkko@piuha.net; ietf@ietf.org
>>> Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"
>>>
>>> It could not update because the
>>> HTTPS URL was failing due the browser seeing an erroneous "Invalid
>>> Certificate" display with no option to accept, temporary or otherwise.
>>>   You have to download via another browser that isn't so strict, yet.
>>
>> Why does the IETF use invalid certificates in the first place? If this
>> is due to a wrong system clock, then the user probably cannot visit
>> Google, Facebook, GitHub, etc. as well, and at least Firefox and
>> Chrome advise users to fix the clock in such situation.
>>
>> Xiaoyin
>
> Most likely because the HTTPS server is now fully PCI/DSS v3.1
> compliant which only supports TLS v1.1 or TLS v1.2.  I believe PCI/DSS
> v3.1 takes effects July 2015 so you are going to see a lot of this.
>
>      PCI/DSS (Payment Card Industry/Data Security Standard) v3.0 to
> v3.1 changes
>
> https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1_Summary_of_Changes.pdf
>
>
> If the HTTPS server only enables TLS v1.1/v1.2 as required by PCI/DSS
> v3.1, this can fail older/current HTTPS clients which does not not
> support TLS v1.1/v1.2. It could/may display an erroneous "invalid
> certificate" display or even show an unknown site page because the
> non-compliant HTTPS socket request was broken.
>
> For product update scenarios, if the site forces HTTPS transactions
> only, then its not possible for it to update itself via HTTPS.
>
> This is more about implementations and how they need to learn how up
> "update" users using any current secured frontend. For PCI/DSS, I
> predict we will see many of these issues that in short will force
> users to update their client software on their machines, whether they
> like it or not.
>