[lamps] Warren Kumari's Discuss on draft-ietf-lamps-rfc3709bis-08: (with DISCUSS)

Warren Kumari via Datatracker <noreply@ietf.org> Wed, 30 November 2022 19:54 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: spasm@ietf.org
Delivered-To: spasm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A02C1524B1; Wed, 30 Nov 2022 11:54:19 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-lamps-rfc3709bis@ietf.org, lamps-chairs@ietf.org, spasm@ietf.org, tim.hollebeek@digicert.com, tim.hollebeek@digicert.com
X-Test-IDTracker: no
X-IETF-IDTracker: 9.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Warren Kumari <warren@kumari.net>
Message-ID: <166983805955.50688.17697354538904032320@ietfa.amsl.com>
Date: Wed, 30 Nov 2022 11:54:19 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/X7e3jXoYUcFpArSvOqQLN1kqz3U>
Subject: [lamps] Warren Kumari's Discuss on draft-ietf-lamps-rfc3709bis-08: (with DISCUSS)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Nov 2022 19:54:19 -0000

Warren Kumari has entered the following ballot position for
draft-ietf-lamps-rfc3709bis-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc3709bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Don't Panic! As noted in
https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is
a request to have a discussion...

I'm assuming that I'm missing something really obvious here, but this *feels*
like a bad idea to me...

The document says: "The use of logotypes will, in many cases, affect the users
decision to trust and use a certificate." Yes, but that seems like a bad
outcome...

Random things on the Internet tell me that Microsoft has a well recognized
logo. Seems plausible, let's use that as an example. When a user is trying to
figure out if a certificate actually belongs to Microsoft they are likely to go
"Oh, yes, it's a square composed of other colored squares, this must really be
Microsoft", even if the CN is for www.evil-attackers-r-us.net. Even without an
attacker intentionally creating visually confusing logos, many are similar -
for example, https://icn.bg/ looks really similar to Microsoft's logo (and many
things look very similar to the Pepsi logo -
https://yourmileagemayvary.net/2021/05/23/look-up-in-the-sky-its-a-coke-plane-its-a-pepsi-plane-its/
).

Here is an image with two logos:
https://cdn.mos.cms.futurecdn.net/hD95PaJgx5ZZVCFduTWhtg-1200-80.jpg.webp One
of these is for airbnb, and one is for a Japanese drive-in. Keeping in mind
that, as a user, the logotype is likely to affect your decision to trust and
use the cert, when entering your credit-card info to book your next vacation
rental, do you know which of these you should expect? If you get the drive-in
one, would you really recognize that?

The document uses VISA and MasterCard as examples, but, without looking in your
wallet to actually confirm what their logos look like, are you *sure* that you
would be able to unambiguously identify them if placed next to logos made by an
attacker?

Ok, so now that I've had my soapbox rant: This document updates RFC 3709 and
RFC 6170, which been around since 2004 and 2011 respectively. Apparently the
sky hasn't actually fallen yet, and so I must be missing something. I did spend
quite a while trying to find examples using RFC3709/RFC6170, so I could figure
out what I'm missing, but failed. I *did* find a few CA certs with this, but
they just had links to http://logo.verisign.com/vslogo.gif (which doesn't
resolve). The only "live" cert was for https://www.dtihost.cz/, but it's not
valid.

Again, I'm probably missing something obvious, and so clue-bat appreciated...