IETF Logo Mail Archive

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

Hector Santos <hsantos@isdg.net> Sun, 07 June 2015 05:57 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 8C8E01A87D2 for <ietf@ietfa.amsl.com>; Sat, 6 Jun 2015 22:57:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.102
X-Spam-Level:
X-Spam-Status: No, score=-100.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 WMslDq-AE5by for <ietf@ietfa.amsl.com>; Sat, 6 Jun 2015 22:57:15 -0700 (PDT)
Received: from secure.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CFF9B1A87D1 for <ietf@ietf.org>; Sat, 6 Jun 2015 22:57:14 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1928; t=1433656629; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=/aExfjTJwDVkwKkNV6PcPvPtRG8=; b=qgLQJ3udmdhju/Xbfe04yy7Emc3Vm/GY3sUf+dzitMjJUD1gUWVVb7kqfjeseY idXYS5GIIqNDdcR3sMdJ1E0q8wbr2GzEHUUK2SDnq7fEOjQ17BOOAtbg3w+62qZ2 L9zgTd5fT5EZf1+Cw7fHQD/96nZMHVygZcKgZico1wD14=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Sun, 07 Jun 2015 01:57:09 -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 3071622990.3911.5396; Sun, 07 Jun 2015 01:57:07 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1928; t=1433656302; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=DmQTTt/ bLR7e1Arj/t8tT2Y+3QM5n1rtq40K33wQ6Vw=; b=Y14/3xe9VPEtAyIJCjLE4cU AMBbzIZaMuw44X5ykzs9h5tyStUj8s7olWXYmr3mb/U8IsaCbjCRmN41s7kAgeKO ULponnGkenDjMjmuUHxupLe4fKmUyciWw/yO8Yg/nicNIf5AjS8mM2iYEdAjVCjz XO25z4ww65DvMBI8rG5Y=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Sun, 07 Jun 2015 01:51:42 -0400
Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1663870395.9.37812; Sun, 07 Jun 2015 01:51:41 -0400
Message-ID: <5573DD2E.2070505@isdg.net>
Date: Sun, 07 Jun 2015 01:57:02 -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>
In-Reply-To: <BAY180-W22CC446142733EDDCB5407FFB00@phx.gbl>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/n_DEC8k1MaKFd-If85TI2z23yec>
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 05:57:17 -0000

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.

-- 
HLS

v2.23.0 | Report a Bug | By Email