gpg --refresh with large keyrings and hkps in 2.1.1

[Daniel Kahn Gillmor]

Hi Phil--

On 12/16/2014 09:58 PM, Phil Pennock wrote:
> Does the same happen with an hkp keyserver?  You don't explicitly note
> that you see things proceed further with hkp, which would lead to
> knowing if the problem is with key sizes (on particular key, which you
> see 83 keys into your keyring) or with TLS.

sorry, i should have mentioned this -- i have no problems with hkp, the
full keyring refreshes.

> If you only see this with TLS, are you able to get a pcap capture of
> what's happening and get a protocol trace?

i've gotten a pcap capture, but it's large (20MiB, 2408 packets, 22 TCP
sessions for a query that fails 20 keys into the refresh) and encrypted,
of course :/

Any suggestions for how to reduce its size to something more managable?

> Things which come to mind as avenues for investigation, assuming
> TLS-specific:
> 
>  * TLS session renegotiation and whether or not the GnuTLS integration
>    in GnuPG is missing some callback to allow this

I'm not seeing any session resumption on any of the 22 TCP sessions in
the packet capture.

>  * keyserver TLS proxy size limits, hitting some particular caching
>    limit in size which fits in memory in a common configuration

i guess i'd need to turn on server-side logging on the keyserver i'm
testing to catch that case, but it doesn't seem to line up with
kristian's report of it changing depending on what network he used.

>  * Whether or not smaller keys kept you from reaching MTU-sized packets
>    and something bad is happening locally for you with timeouts during
>    Path MTU Discovery, only kicking in once the flows are large enough
>    inbound

the MTU i'm seeing is F=1500 at the first hop (based on my running
"traceroute --mtu keys2.kfwebs.net")

> The webpage <http://sks.spodhuis.org/sks-peers> is very ugly, but does
> at least show you in-line in the table what the Via: header is (and the
> Server: header too).  It might be worth selecting a host each with
> "nginx", "Apache", "lighttpd", "Squid", "xs-httpd" and "HAProxy" as the
> TLS provider on the server-side.  This will at least let you rule out
> client/server TLS interop issues.  You'll probably need to coerce the
> hostname to be the pool server, though, to get a validatable certificate
> presented to you.  Might be easiest to just hack /etc/hosts around as
> needed.

well, i've seen failures with the two that i've tested so far:
keys.mayfirst.org (zimmermann.mayfirst.org), which is nginx + sks 1.1.5
and keys2.kfwebs.net, which doesn't indicate what its proxy mechanism is
in that table.

any other suggestions to help with the debugging would be welcome!

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20141217/005f86b2/attachment.sig>