[openpgp] WKD lookup advanced → direct fallback clarification

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Tue, 20 August 2019 21:00 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5491D120180 for <openpgp@ietfa.amsl.com>; Tue, 20 Aug 2019 14:00:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=Rkq29AYA; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=a+RKnQZl
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 jGfPzTsPPmr6 for <openpgp@ietfa.amsl.com>; Tue, 20 Aug 2019 14:00:28 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BC43120086 for <openpgp@ietf.org>; Tue, 20 Aug 2019 14:00:28 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1566334826; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=RFmHoSAddj7CgdhMFE8zh+FjtrmCWDScZf2+59zI3cw=; b=Rkq29AYAFdI2qsdoZw/cE41+hHoHGrsS3hXJLR+tbV9duulcuUTI+iN1 JLAgXpUyFlmDcQI/Isw6yy6l6v2XAw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1566334826; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=RFmHoSAddj7CgdhMFE8zh+FjtrmCWDScZf2+59zI3cw=; b=a+RKnQZlcYIWj9nG8mFZaaPjH0GehPGG5DojAj+JWwam8w6rUnbbAowq ZxkjQkyPlzBqLhwjKFHR52MMBksQKHV8rxiWIaK16iEfX0eXln+ZuIyPlF uAyOTWszkagsdvwlFi1JbjN36GMDEWbo6kK7uV2sUpLOkHPTTdEBg7ZCpD 0dQ16nAUQw2PhOPLaCSrJ7/32WkzKS/l8RxQSNeiMmj6UJ/50C9DcBfdUM lQEiKxfV6B0rGv02yPwgt+rbre/rqTMIKwMGzLabGO2TNiyPVPk1xPlBiY z22gTcUIigGtnYM+R/g4T0dGa6pROmqtKSy6og+darf8f++Pqz02kw==
Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id BC920F99D for <openpgp@ietf.org>; Tue, 20 Aug 2019 17:00:26 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id CD8952035D; Tue, 20 Aug 2019 17:00:23 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: openpgp@ietf.org
Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQUJA8Jn AAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgBYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJcQsbzAhkB AAoJEPIGkReQOOXG4fkBAO1joRxqAZY57PjdzGieXLpluk9RkWa3ufkt3YUVEpH/AP9c+pgIxtyW +FwMQRjlqljuj8amdN4zuEqaCy4hhz/1DbgzBFxCv4sWCSsGAQQB2kcPAQEHQERSZxSPmgtdw6nN u7uxY7bzb9TnPrGAOp9kClBLRwGfiPUEGBYIACYWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUCXEK/ iwIbAgUJAeEzgACBCRDyBpEXkDjlxnYgBBkWCAAdFiEEyQ5tNiAKG5IqFQnndhgZZSmuX/gFAlxC v4sACgkQdhgZZSmuX/iVWgD/fCU4ONzgy8w8UCHGmrmIZfDvdhg512NIBfx+Mz9ls5kA/Rq97vz4 z48MFuBdCuu0W/fVqVjnY7LN5n+CQJwGC0MIA7QA/RyY7Sz2gFIOcrns0RpoHr+3WI+won3xCD8+ sVXSHZvCAP98HCjDnw/b0lGuCR7coTXKLIM44/LFWgXAdZjm1wjODbg4BFxCv50SCisGAQQBl1UB BQEBB0BG4iXnHX/fs35NWKMWQTQoRI7oiAUt0wJHFFJbomxXbAMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJcQr+dAhsMBQkB4TOAAAoJEPIGkReQOOXGe/cBAPlek5d9xzcXUn/D kY6jKmxe26CTws3ZkbK6Aa5Ey/qKAP0VuPQSCRxA7RKfcB/XrEphfUFkraL06Xn/xGwJ+D0hCw==
Date: Tue, 20 Aug 2019 17:00:23 -0400
Message-ID: <87d0gzeemw.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/eOK1WbhDDZB4ceEh_Bp4lHV1xt8>
Subject: [openpgp] =?utf-8?q?WKD_lookup_advanced_=E2=86=92_direct_fallbac?= =?utf-8?q?k_clarification?=
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Aug 2019 21:00:31 -0000

https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-08#page-4

says:

   There are two variants on how to form the request URI: The advanced
   and the direct method.  Implementations MUST first try the advanced
   method.  Only if the required sub-domain does not exist, they SHOULD
   fall back to the direct method.

But it's not clear what "the required sub-domain does not exist" means
exactly.  I can imagine several different
implementations/interpretations:


 0) is there no DNS record at all at openpgpkey.example.org?

 1) does a DNS query for A records for openpgpkey.example.org return an
    assertion of non-existence?

 2) does a DNS query for A or AAAA records for openpgpkey.example.org
    return an assertion of non-existence?

 3) are all of the A or AAAA addresses returned from such a query
    (after following CNAMEs) unreachable on the network?

 4) if one is reachable, but port 443 is closed?

 5) if port 443 is closed, but the TLS handshake authentication fails?

 6) if the TLS connection completes, and an HTTP request can be sent,
    but the response is not an HTTP response?

 7) if the HTTP response does not return 200 for the specific lookup?

 8) if the 200 HTTP response is not a series of OpenPGP certificates?

I *think* that (2) above is the right trigger for the fallback, but i'm
not sure exactly how to implement it in many HTTP client libraries that
abstract away the specific failures. i'm also not exactly sure how to
implement it when connecting through a SOCKS5 proxy or other situation
where as a client i don't have access to the DNS queries directly.
Perhaps a concrete example about how/when to fallback would be a useful
contribution to the doc?

I've noted this question over on https://dev.gnupg.org/T4679 too, since
that appears to be the bug tracker for this document.

           --dkg