Against certain proposed TLS client-side options

[Gary E. Miller]

Yo Eric!

On Sat,  2 Feb 2019 06:16:45 -0500 (EST)
"Eric S. Raymond via devel" <devel at ntpsec.org> wrote:

> NEVER CONFIGURE WHAT YOU CAN DISCOVER
> 
> These are from nts.adoc:
> 
>      *tls1.2* Allow TLS1.2 connection.
> 
>      *tls1.3* Allow TLS1.3 connection.
> 
> We don't need these because in this 'graph
> 
>      Implementations MUST NOT negotiate TLS versions earlier than 1.2,
>      SHOULD negotiate TLS 1.3 [RFC8446] or later when possible, and
> MAY refuse to negotiate any TLS version which has been superseded by a
>      later supported version.
> 
> the last normative is a MAY, not a MUST.  Thus, you never need to do
> anything but allow some connection at 1.2 or up even once 1.2 is
> superseded. Correct[racticr is to use the highest version you have.

As previously asked, discussed and answered here:  

The list of allowed versions, and even names, will change.  Sometimes
overnight as we have seen many times.

Being able to force a version is required for testing.

> We also don't need these.

Wrong.

>      *tls1.2ciphers [list]*  List of TLS 1.2 ciphers to negotiate, in
> prefered order.  The list is one or more cipher names, separated by
> colons.
> 
>      *tls1.3ciphers [list]*  List of TLS 1.3 ciphers to negotiate, in
> prefered order.  TLS 1.2 and 1.3 ciphers are different and must be
> specified separately as OpenSSL needs them separately.
> 
>      *ntpciphers [list]* List of ciphers to negotiate, in prefered
> order for the NTPD connection.  The server must support
> AEAD_AES_SIV_CMAC_256.
> 
> The correct, conformant policy is to negitiate your best possible TLS
> version, then ask your TLS implementation what its list of ciphers
> for that level is, then ship that.
> 
> NEVER CONFIGURE WHAT YOU CAN DISCOVER

BY DEFAULT, YES, BUT NOT ALWAYS.

As previously asked, discussed and answered here:  

The history of crypto has shown us, with Apache, nginx, sendmail and
postfix, that the algorthims are time and space dependent, and often
need to be changed in an emergency. Literally overnight.  Do not ignore
long standing best practice without long and hard thought.

If is also needed to test the Proposed RFC corner cases.

Oh, and discovery of these is a bitch.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190202/7d274fb8/attachment.bin>