Re: [TLS] Enforcing Protocol Invariants

[Viktor Dukhovni <[e-mail]>]

> On Nov 8, 2018, at 4:34 AM, Salz, Rich <[e-mail]> wrote:
> 
> What makes you say that?  Please be specific about what you think should be taken out.

One example area where the complexity is noticeably high:

 * Certificate selection metadata specificity seems to far exceed
   plausible diversity of choice on the peer end.  Are there
   really clients or servers out there with so many different
   certificates to choose from that we need:

	a.  CA name hints from client to server?
	b.  OID filters in the certificate request from server to client?
	c.  signature_algorithms_cert (TLS -> X.509 layer violation, I
            just ignore this one)?

    In TLS 1.2 the signature_algorithms extension needs to be combined
    with the certificate types list, and neither 5246 or 4492 provides
    a means for the client to decide which curves the server supports
    in the client certificate (addressed in TLS 1.3).

TLS 1.2 has fixed-(EC)DH ciphersuites that should probably never have
been defined, and for some unknown reason added MD5 as a valid signature
algorithm hash, even though MD5 had already reached its use-by date...

For simplicity, I am a fan of Mike Hamburg's STROBE (a protocol design
framework, not a finished protocol):

   https://eprint.iacr.org/2017/003

of course one still needs to plug in some sort of PKI to get
a complete system, but it robustly unifies many things that in
TLS need to be built with one's bare hands.  I do hope that
STROBE is getting used somewhere, and not just languishing as
a paper design.

-- 
-- 
	Viktor.