[Uta] Opportunistic encryption and authentication agility

Trevor Perrin <trevp@trevp.net> Sat, 22 March 2014 01:37 UTC

Return-Path: <trevp@trevp.net>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id EB4231A099E for <uta@ietfa.amsl.com>; Fri, 21 Mar 2014 18:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id FWSg4a1ro2bW for <uta@ietfa.amsl.com>; Fri, 21 Mar 2014 18:37:55 -0700 (PDT)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 1C1221A098A for <uta@ietf.org>; Fri, 21 Mar 2014 18:37:54 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id bs8so1033233wib.1 for <uta@ietf.org>; Fri, 21 Mar 2014 18:37:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ExAJ0POyZUmNZoh9/p1wrmTsULNFdlGcKWW3gkntzAs=; b=XtKH5DdOVTrMiyZKYrCq/ViBmWPhKdUGYNKEMcsLvQJgxA/uNErItdO2lWkqiT1AY+ rqu6nljHhNljzg3UWdktz/Od5shaitMDPTk1luDOJ2O1HDsJyOkklF1ERguCF/MPCc/t /uq9tn9cmixAYInZ2f5SYLZqNuQZ464NcpdUvnHQWTEZwe9Nm5avhmrwlnXo7ZuKhUB+ zmv5UznrmsvUb40+w+Ne4C9awCFOIDybfpWOP8nKSbkTQ4Gv6W9HJ+HzOBcGZMxztgEk sN1C+XDQrQuXlL2049JHwndZOR3X91z0zWk1bBceqaQcAeRHOfq3q1kS4d3oX3bMDE/G 1sPQ==
X-Gm-Message-State: ALoCoQmjS7yRfYMYfJ3ivV+ZwX03c6/5zk8/uljECIeL1zyF8f/4BjCVVyZDdtZ0wOPJbTtpViE/
MIME-Version: 1.0
X-Received: by with SMTP id ef3mr682831wib.39.1395452265080; Fri, 21 Mar 2014 18:37:45 -0700 (PDT)
Received: by with HTTP; Fri, 21 Mar 2014 18:37:45 -0700 (PDT)
X-Originating-IP: []
Date: Fri, 21 Mar 2014 18:37:45 -0700
Message-ID: <CAGZ8ZG0rBxiE2dGZXhpvhKiyJOu=6Bn8sQ2seJ9_KvgPjmaaRg@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: "uta@ietf.org" <uta@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/uta/cDQvYvwFy3cB9EZpogW1kac04ns
Subject: [Uta] Opportunistic encryption and authentication agility
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Mar 2014 01:37:57 -0000

A point I haven't seen in the recent debate:

Whether a TLS connection is "opportunistic" or "authenticated" depends
not just on the wire protocol but on the client's capabilities.

A client who possesses an HPKP or TACK pin, or is capable of querying
DANE or Convergence, might be able to authenticate a connection which
to a different client would be opportunistic.

So when we talk about OE at the protocol level, I think we're really
talking about whether to allow agility of authentication methods, or
mandate a specific method.

In the case of HTTPS, the Web PKI has been mandated.  A small site
that doesn't want to pay the costs of Web PKI but would be willing to
deploy cheaper methods (pinning; DNSSEC/DANE) cannot do so.

If opportunistic TLS was allowed, then we would have the ability to
deploy new auth methods without having to forever support whatever was
in vogue when the initial standard came out.

I think that argues in favor of opportunistic TLS, for HTTP and other protocols.