Re: [Ntp] I-D Action: draft-ietf-ntp-using-nts-for-ntp-18.txt

Marcus Dansarie <marcus@dansarie.se> Tue, 23 April 2019 19:32 UTC

Return-Path: <marcus.dansarie.nilsson@gmail.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B0512014A for <ntp@ietfa.amsl.com>; Tue, 23 Apr 2019 12:32:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 lFMx7cAGkbIF for <ntp@ietfa.amsl.com>; Tue, 23 Apr 2019 12:32:02 -0700 (PDT)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33331120041 for <ntp@ietf.org>; Tue, 23 Apr 2019 12:32:02 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id h5so12639441lfm.1 for <ntp@ietf.org>; Tue, 23 Apr 2019 12:32:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GcNugy0kKjdXQDqMOi0NQTIbmyJn9d7dUSWZCxPyxgU=; b=Bw0lE6lGQXqDePDaeZWsvhCFl6LdfmoG0ApuTbBAzPnwbdTWOtHuCUfCf2148mtZxd iE9pxaRkA9FsE4PDdBRg2Rmbjwi/Sp4lWwCUsoP0B9yOHb+cZNktn2rUoamCoF4NPjPw OaQx9JzcT27FUY2rvofoWwuQoEN8cr/Qo0MmVs8jlFfFLoCvscK+Yp0wjhrU4ENucWJO /p3jZ7pRTA1wFv+H+9gYPWe3u7Rm0lXzAwfrRq2VGViblSm3dHa2obv0+O1WZhHUtPFJ kWogwh8S/a5n7YAvPQpZ5o9Ka+08Q7D5U0vekzTeNMplGRSnbpdWj/eGBxd/S3oBhmnH wvdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:openpgp :autocrypt:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=GcNugy0kKjdXQDqMOi0NQTIbmyJn9d7dUSWZCxPyxgU=; b=JhgCmPuT5sdFduX48Xlx4HiATri0g9a0Bqh8r/PP5NIO2eH2kUcGtAqOO8q32LaZJa OCaeTUVXGluv1o2JDsBKOkQF4tZ8YOXeWaXpD3ymW7gzaCYkJEtsXaJ281uZDkc3LW6q n0zbLO1KHyBIrhpkqYVtj4N3EudZDeUTQGiSm+05XIQ6pFg1tBfwF8oWdTfF1oNGnWrE S3MrXi4q9kJ+pD3c3Q9/CD/FUEOYZp8gJ4CRMhsO6s/4/GrSLilfmztfETZTTSS3T+Er NVIRdnAV68gkf5WY1Kspr0fdmNw5t38PZ+xYgZ1AN+RqttYqHZ7mr2dqOCMg86whc3ky WuDg==
X-Gm-Message-State: APjAAAXKqjJhAPmCBxxqF/naGdP2EWNzuUFRrVuGndcpKwFjS8odnnlF fkCP9Ty/du5PGl2chgSuTMXjyn6z
X-Google-Smtp-Source: APXvYqw2xTVHXXWw9g9gVgkaQJS29NKQr26HJ6GYF5HiDEGlzddgavAw6aVUo8CqYCrZcjOW4psGBA==
X-Received: by 2002:a19:f705:: with SMTP id z5mr14863464lfe.93.1556047919969; Tue, 23 Apr 2019 12:31:59 -0700 (PDT)
Received: from [10.0.0.126] ([185.40.184.26]) by smtp.gmail.com with ESMTPSA id f18sm3882489lfh.39.2019.04.23.12.31.58 for <ntp@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Apr 2019 12:31:58 -0700 (PDT)
Sender: Marcus Dansarie <marcus.dansarie.nilsson@gmail.com>
To: "ntp@ietf.org" <ntp@ietf.org>
References: <20190422080620.6323340605C@ip-64-139-1-69.sjc.megapath.net>
From: Marcus Dansarie <marcus@dansarie.se>
Openpgp: preference=signencrypt
Autocrypt: addr=marcus@dansarie.se; prefer-encrypt=mutual; keydata= mQINBFawEn4BEAC8YukDy8f3eczlE8WAcuctrjsNltPCLZDzcj3vBmiayXlXuPULOopqeuw4 +oaZqj4KqvdFBA1mzvwPll7IHePuwAoJYJr48IbIXc9MRjtLoFtd0KnhiVPUS8F2cmfzSJ8E FEv92sz6UT8/tlLEu6sNqr6/caYUivspuW5wf4f6nkSE+6rao9Nx9X03r289IPNBSZv+Y/Ym jWHDPpbT8WLUJZ+A8RsW/1oza609oAzqTkclmnRzip8wZZWNg3Q55P7onBmTIOrEz13My9r5 DWCMHyxXgFL1RJ9YW0t4yRkRm+HvOn3Vesk3m8CCGA6esHV0IPZmBOxJr3l+UQYuDiTgFufr WMpu5MvlyKGHS4fNd505DyyJY2G6eQLLrOq3nZy4qoZSL42TMxzYglexg+H6P/YsIIShk5Ch h/hNphXjrElDWhbGT5JiRWIivgSj/gq5QVBbDLR3b25n9PA0byGemfcEHLkii6EKyH7GW6v9 sgmvCmPfEfppYcOP2g9Jdt8RPitx0UBjoCzWAn0Py0NvlFDyz0FQhWDPig3yo1CG5ljb686v VBwcHJthczUV0rIyVzfmnikIb9ZjydHSX3fFwLz1IcIIX+INS58qA0SDqOoyP2WTYGZCDPVw GMMh+wMtAL2MICTr6vybFWB58m4PsI1j8Ri+AQiEkxyJauI2WQARAQABtCRNYXJjdXMgRGFu c2FyaWUgPG1hcmN1c0BkYW5zYXJpZS5zZT6JAlwEEwEIAEYCGwMCHgECF4ACGQEJCwkNCAwH CwoEBhUKCQgLAgUWAwIBABYhBBfkVFb0H62SH33Csy9j5/6tpPBjBQJcLN6RBQkHXf+TAAoJ EC9j5/6tpPBjZNoQAI87t6fNeEDUe3mVxvhHbh0IQ3NTv5555HstmNA6ZKYeUhFIRFGGxo1D a93viLr59dL58NR43O4MA6IJTsOdCxnZfGMLRs7yHGylnilJEh9OwFHEJp0GprJ2RqfBGJsQ 0qQu90ptGhNWHeN1nEVPYg6tyTz6jFG+YuvHzIZjpCFY0xG+J92gncTDG8082kkp/fxSvKGr 6nxiH9lOxItJsUjRF3fUsmr8QERKfaYkrHaqEM05q0zlQu+ofwmq8oHk2Mlx+Earb0KgGWqM 85l8+uVnM/DKeD6qH8zAaOQImcyEn7KNQuHR+FELPRFFJ5BkSrJXat8P4ViC4Md0lF3X3sm9 nxztGbVD4v9M50ci7hosVsiqslU/nMv59f3NPATR+sOZrq3K5rSUGeVbF3+3ZT3fF4FfE7Gl ldtS8D4Lq8MYbfuFD4JnhqLQf9nuOeBH2qcJf6M6R5yi+NwEF7w1xGWYfI+ifNRlPl5FCJDj ft3JFxswKMpobyp2Amo1oman7kORTZ+dnQ9JNLZSbqSZRZ7CQt30exO1jgW0H0oYKVlZ3p3Q VqVC4BA5Ap7Pc6Da7LlgJnF6yfy1ODFllYBIT4kLOL/99W9CsKinaa6pJAjfs+x1QzzrR0ji ucHinLTeZ4JYDtFxXAEkQ2tuxaouoz+cLwrOwTepiBOiUtYnAg8tuQINBFawEqwBEAClJOj1 zOQTMRGzLK/08tEdwR4EwBDiWNci0JtjT59xtJdlGujuf/9wkt9hRIiALqt8U0vHwCzmxVTP Eueewv40WOraJzzDv6OBXJZMeF+IN1/CGrZcn8rLG9J1CyyVf+gCxUUXmpQDlE91iYMB4ifj dTTTizRnVYOQh54TV0yyiL2bn+ZdL8NYNpUbpoG2vppltt0NXv9ib9WPug9Q8Sx33CkkCj3F HJLHeHqo6AkFTpBdSn6/Ezs+ZHpuhNCHtrZyiJOi2YZ8EzpuxDwVjHLh8iXu0amlXSGP5wA7 MpNEtomhGw3bUr3aBcenfS4u/RE3V/y+vXae33LtVmaH7sli0SmrP8iUxkks2qjtS6W2a/qF xlHK/FXBChNIG0uRROvDlIudg6UHzQlK4mBdraGz4etfDpsNAX0x5ssxBTaFrJlZz935GPLR sg4o5f+FYcQrIZGisfCmiH8rdF1bkz450/OyfzS7lTCoxeizOnlamVwUCTfrWah/l8BXgP/i Y6KlbGpfr7aVYvA5e7fPe7uRqzPsxq7pL72r3p/TkNuPtJ7cbShN99p7v/v38STSJ4jbzy2W LMBFw5dJI73XtSGU2g/viZgVfl4Tro4XeYMF/FmRDiYcd+GpuDoB+g+NJYpGRGnr4+GgWl9U YCnN1TE9LSpvehvvKMvGqi0U1ENOUwARAQABiQRbBBgBCAAmAhsCFiEEF+RUVvQfrZIffcKz L2Pn/q2k8GMFAlws3qsFCQdd/38CKcFdIAQZAQgABgUCVrASrAAKCRDBCAAOw+Eh5rtYD/wN eZOov+0rwhszfD+IY9fI4qFUjuiKWR06fJ60HV7cStkDW6WtrF+NkUAwH5G0yrA+izyI9wtR 4r5OW5ruPWTRbHxOmsLfRnqh4dKU6uCvtoL+LNzAMyPORiZkzomOaKAPdtiVgECVupLsApDl 4tI2hpMYKmeTVuessXa83oGOi8uQGK/M57Koz20KPfLltJBsCcOwofCUdbmaPOlN/DspOaIe LWzN7qb3pzAuUltBCvVI3VRgqvfh6JSiGyaSUfjghfbtz0uAlZ4wSfHX2+Iw+1/9mlElZjkC y6QgxCb1vMqGSw5u596aGVm7m2zVGLn4/xhpFNbxHUwWre/AAMtJR5ASK3cq2au1U2rOja3f rRfzMuBqTrQGb+OcCaesaOssd7t+RmDKfv0u40z6ls9Mzav+BCXzfOnb3HNAgJE5C/xApTsd xhn5BZoxHy8N2Pc0emWe6JI5UDPlKpuwH6JDKrLaoHhE7Gy2U6iinQcgI5IEEa8wmwoWfkjU 5phTbZVHJ+yTOeZWcbJtyFIX18fbzyrZWguo1EWHubv33KqbiJ6klpfg5chwKXWZIlLmbivp Dv0KRybk5GB+X83OpeAH9dKT3kvcu6midppjFzakSIiaoSJDS9jcqQYEiRG71lnD7QdCoqjb fHZh8HXGYSbenDzisWIRouGsimOyeSaX6QkQL2Pn/q2k8GOq8g/+PAcag2kmEQeJIVEtVCA3 e+/v+9XTi/7X7fZ247gAHbbaZKavRMFmgVsJNq6riC4HoetUWwMWJ2A/buSVMVJwAd5pWXAq WkOPWgv60FN92yfdUPjXXhLMXhntCLaRbNmKw0gETFLlUGXbRHyiO02EbJziI+vOr3R3AYa/ JEvsCHKX6TUm/HerBmzTUOi/igtd/H7B4EYcO5bZLKSJ8RZT5hKwOpVIYOdvBWZx2+MTG++A w6mDCgpIRseWgsyrkfsKkf+xQw0JewsFMyW5z+swV5/SCrhzexRIh1Jr5KBQ7FI7WgO5l46o EKtCmBjDSckdlBg5wfpPHK4s3k3FreX/tPqrzwTaBY9NIyzLGE2KFgr5lTWOr4P5xb37CNg4 hCzSJStvrlR/MscUmjaYR+dHCwzNr5tkBDSIqBKw6THWV+i0g3Vo41FF06Eg8dnW0yMX5Vfp zw9YYFsTV+WbKBTRwNA6OsAkkD7zMU0KzL3+i33uzgo+CffBYJs12yABIWXtNWlXiJpqePyh /6PTEfYMUE7dDr8qlEt23AoGs3Eme+OgY/Y5Yv03jcINp98/qnXnnqf9ghpVavajVwOIQui5 CMxWUkDweNyEYJA4jaKkov5/iwssNosBSF007b4loCXLv45iz8jkQwYHUwzH86W6Gk13/bdt v0ksRjKe291ygQm5Ag0EVrASywEQAMscigyDy6txQ/cUE8P+S9zMPNbsTSqa3iyj0SREswxm JsrUou+yOt/Y4UxGX+JLc/zjI1+frWE33CNmucYMtrZSrxgQDp+Wp8Ak7UNQlBtRIjdcPqmA EFzgG9OP7If7MJZMeWVd47ybIYUKohuTdFgwJSF80f+DGLLjIchyVZbvyZWSQKIAxfavmZr1 CNEVYXyrL752rLVB+KnQgJaFqHFPp6cO/Y20ViF9QsLRtlref1VrxtdPuILhEKMmmc+ZRsDh J0V8Mi5q8pWcYWrz+JiVRyA1ULAhg6C2ypj1cFNnQyN22XptXbz687bqZQxar5xyAAV4D6i/ 8q1kNgSsbDq+XkWuGjS9kmvLGM9kGARNhMFNguJSgSfqZExPAJhCZ4hVboTKFoRR10482rlO yj0Va0GbmpGqftjNodA4mjpBi52pNymUF+s6eTk13L9DOOJ8d0+2Qd6e4uTeNXJhNW6g2l7b 5dt/bbHMla7hgqRKUtTqQRR2JCpP3vF4sHWnXYdEcJSACarBcxbfdwZBnF9Nwv7GiNTEEg7O +8qwlj16LTB8oNWjOwAHiqg0xQlL8JTz2rkX0gUIW1Hy9A6b6UikViRbmpHXg0s7364Xtxji mkKD8DVnC5NJDiwZztqG2iW7kxJnfA+eAClKEh+niZo5NpjWNUfhjUXM5DNVHtchABEBAAGJ AjwEGAEIACYCGwwWIQQX5FRW9B+tkh99wrMvY+f+raTwYwUCXCzeqwUJB13/YAAKCRAvY+f+ raTwY6oaD/9Q1RhI/RNI0TmS60ih7gTZ1wvWbU24qGHZ1Q5kgriS5C59IWDkVlOCx2qQVwJO eGBrUHDhEuL2AuAF46Rmh+tIFMqij8Orz8zebSydM8aBtSPua2QpAta/IJS/5jvGN0aKbim8 MpD9oCHFp7N+37p7e5jrpLHz3qh5cDau+fFDUzS04gtcgkJb3wXg0MhgoZF/KU3JSq0Xs0Ni ioljOHDgOddGzO7Dd2KbCW2vtzo7m50yrLHI77hsocnkqrIcIn6TeYtH7K1aksEI0KC2Sg0b ome7eO8jCziXZO73iwq9hflXAiZp9CM2HWlb7e2zXe8vChJorEf+9w3t/jyvQzCtOf12jUM1 xr99DODBAEtJ0/tUfSsGvfETmAhYD2tjRmVwzB7jRq6U4bc5jtcYEL5YKEWBIvJDVvzE3iu/ HHjc83bIIyqxeYyT3uClTWPVP5OEWBxGUas7u3hlxxmSzGjpXUDBZyoeC+Q6Q3WUp6zOSg+/ yVwD/KBQQ/Sy6vOfvgh6PmsP1D5xCZSl6UWnxSi8lTtAcjUjHyG1qCudR/pmDv0OL5Ul8PeF 87DBMz4Y0our+MslzlvhrmI90XcKAyHrukdnanS+gle61a44uFwtUGPTvCtSW4AQLR1uixc8 qaHsQNmXpQQOIt6nudcOCisXa1c6P/WU8I94u9BmCjTWRQ==
Message-ID: <9ae82731-6c9c-6c66-6088-2e2a760e6fdd@dansarie.se>
Date: Tue, 23 Apr 2019 21:31:57 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <20190422080620.6323340605C@ip-64-139-1-69.sjc.megapath.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/DuXun_Q73L82jf2eeRkeDW44Njs>
Subject: Re: [Ntp] I-D Action: draft-ietf-ntp-using-nts-for-ntp-18.txt
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Apr 2019 19:32:05 -0000

Thanks for your comments! See my comments inline.

Kind regards,
Marcus


On 2019-04-22 10:06, Hal Murray wrote:
> 
> Typo, page 20:
>   Duplicate "Nonetheless, "

Thanks! (I submitted a pull request for this last Wednesday.)

> 
> Page 6, single round trip
>   That's after the TLS setup.  Right?  How many round trips does that take?

Correct, that's one round trip excluding the TLS setup. The setup is
expected to take two or three round trips depending on version.
(Theoretically, PSK could bring this down to one round trip, but I do
not envisage it being used in this application.)

> Page 13: cookies
>   Do all cookies have to have the same length?

It is not explicitly required by the draft. I can't see any "sane"
reason for a server to send cookies of different length in the same reply.

A practical reason for changing cookie length is if a server updates its
(implementation dependent) cookie format. It could then start replying
with cookies of different length than before. This could possibly create
problems if the new cookies are longer than the old ones. To avoid
sending replies that are longer than the requests, the server would have
to send zero new cookies as reply to requests containing only one cookie
placeholder in the hope that the client's next request contains two
cookie placeholders, thus enabling it to send one cookie back.
Hopefully, as the old cookies are depleted the client then starts
sending larger cookie placeholder records.

> Page 17, Nonce length and Nonce in general.
>   I don't understand this area.  (My version of "understand" is that I could 
> explain it to somebody.)
> 
>   It seems really really ugly to have an Additional Padding field that 
> requires a layer of magic to compute the length.  Am I missing something 
> simple?

The additional padding field ensures that the server always can select
the nonce length it wishes without having to send a reply larger than
the request. The somewhat complicated algorithm is due to the
specifications in RFC 5116 and the requirement that the field length be
divisible by four.

> 
>   If I poke around in AEAD RFCs, I find text about having a counter to make 
> sure the nonce is unique.  Is that appropriate or necessary?  It's really 
> really hard to keep from reusing a counter if you consider disks getting 
> restored from backup and such.
> 
>   Are random number generators good enough?  How do I figure out how many bits 
> I need?

Correctly implemented CPRNGs are good enough and is probably best
practice in this case. Still, implementors have to be careful that the
PRNG is initialized with random data and that initialization data is not
accidentaly restored from backups or similar. 128 bits is a good rule of
thumb for lowest acceptable nonce length. We would then expect a
collision (i.e. same nonce generated twice) with 50% probability after
about 2^64 generated nonces.


>   How nonce-reuse resistant are the algorithms we are using?

This is discussed in RFC 5297 section 1.3.2.

> Why not require the client to use the same length as the server?  Maybe pad 
> the client nonce with 0s if generating randomness is expensive and it doesn't 
> need as long a nonce as the server.

When the client first sends a reply, it doesn't know what length the
server wishes to use in its reply. Padding a short nonce with zeros
would not increase security. A client that wishes to do so in order to
avoid adding an additional padding field is free to do so. It is not
against the language in the draft.


> Did anybody test this?  (I doubt if our code will do the right thing.)

Test what?

> Should we include a table of AEAD algorithms and the Nonce size?

This is in the RFCs specifying the algorithms. See
https://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml


> Page 19:
>   Why MUST the Unique Identifier be in the clear?

In case a server receives a request containing a cookie it cannot parse,
for example because it is encrypted with a key the server does not have,
it will reply with a NTSN KoD. Requiring inclusion of the unique
identifier stops off-path attackers from faking such replies.

> Page 21:
>   What is  an AEAD tag?  I couldn't find any other references.

It is data generated by the AEAD algorithm that cryptographically
authenticates the message.

> Page 23:  KoD/NTSN
>   They can be forged.  What's the current policy on processing KoDs?

This is discussed beginning on paragraph 4 on page 23  ("If the NTP
server has previously...").

> Page 23, last paragraph, save AEAD alg, S2C, C2S, and cookie to avoid NTS-KE 
> on NTP restart.
>   I think that paragraph would be better in an appendix.
>   In addition to avoiding the load on the NTS-KE server, it also avoids the 
> time delay that would add to the startup sequence.

The primary motivation for including the recommendation/requirement is
that the NTS system should be dependent on the KE servers as little as
possible. Ideally, an NTS client should only perform a KE once in its
existence.

> Page 24:  "AEAD key"
>   AEAD is used in two contexts - one for the wire and another for cookies.  It 
> would be nice if that word wasn't reused here.  I don't have any good 
> wordsmith suggestions.
> 

Ah, I think I see what you mean: should we be more clear that the
server's key for encrypting/decrypting cookies is different from the S2C
and C2S keys?

> Page 36, checking certificates before you know the time.
> 
>   Does the NTP_PHASE_MAX test work with systems that have been sleeping in low 
> power mode?
> 
>   "by picking a random time in the week preceding"...
>   At a quick read, it's not obvious if that's an example of what to do or what 
> not to do.  Is the idea that the certificate will get updated at least a week 
> in advance, so asking a week in advance will get the new certificate?

Yes, that's the idea. I just realized that we made that assumption
without explicitly stating it.

> Page 37/42, [Shpiner]
>   The reference on page 42 says "Mizraha, T" - no mention of Shpiner.

This is due to an error in the XML source. I submitted a pull request
fixing it last Wednesday.