[websec] Issue #41

Yoav Nir <ynir@checkpoint.com> Mon, 26 March 2012 15:09 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E94A321F851D for <websec@ietfa.amsl.com>; Mon, 26 Mar 2012 08:09:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.492
X-Spam-Status: No, score=-10.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nMME5oko2-YW for <websec@ietfa.amsl.com>; Mon, 26 Mar 2012 08:09:27 -0700 (PDT)
Received: from michael.checkpoint.com (smtp.checkpoint.com []) by ietfa.amsl.com (Postfix) with ESMTP id CCB2421F8501 for <websec@ietf.org>; Mon, 26 Mar 2012 08:09:26 -0700 (PDT)
Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com []) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2QF9OVs026575 for <websec@ietf.org>; Mon, 26 Mar 2012 17:09:24 +0200
X-CheckPoint: {4F7085D7-0-1B221DC2-5FFFF}
Received: from il-ex01.ad.checkpoint.com ([]) by il-ex01.ad.checkpoint.com ([]) with mapi; Mon, 26 Mar 2012 17:09:24 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: "websec@ietf.org WG" <websec@ietf.org>
Date: Mon, 26 Mar 2012 17:09:22 +0200
Thread-Topic: Issue #41
Thread-Index: Ac0LYm3R7n9kKqNFR0KrH0OT5cN68A==
Message-ID: <9896F788-8F89-4483-AB38-D1702578C194@checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [websec] Issue #41
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2012 15:09:28 -0000


It was my review that triggered this, so I'd like to explain my position.

There are several things that could be considered failures of the TLS layer:
 1. Revoked certificate
 2. No CRL/OCSP response
 3. Expired certificate
 4. Expired CRL (yes, I know NextUpdate is not expiry…)
 5. Mismatch between hostname and certificate (CN or alt name)
 6. Some other things I forgot?

I believe we all agree that #1 should be a hard fail. Maybe even in the absence of HSTS. #2 is usually not treated as a failure today - it doesn't trigger a warning screen in any browser. I haven't tested this with HSTS, but I'd be surprised if this causes a hard fail. Same for #4.

AFAIK the most common failure cases are #3 and #5. Certificates do expire, and even some well-run, security conscious site administrators have been known to let them expire. 
Mismatching domain names is an issue, because two FQDNs might point to the same server. IMO this is a good argument for a report-only setting, whereas the expiry is something that will bite you far after your supposedly successful deployment.

I guess my issue with this is because when I read the draft for the first time, I thought this would be a good idea for websites that only do HTTPS and do not do HTTP except to redirect to HTTPS. I thought it would allow them to signal this information, and allow them to defeat HTTP-based MiTM attacks. The draft as it stands is not a good fit for this use case, because it requires more of the administrator than is currently reasonable to expect.

I could propose an "HSTS-light" header for this use case, but I don't think anybody would like to have that.