Re: [TLS] An IETF draft on TLS based on ECCSI public key (RFC 6507)

[Ilari Liusvaara <[e-mail]>]

On Fri, Jul 07, 2017 at 03:14:10PM +0000, Salz, Rich wrote:
> > Just as a clarification, all new RFCs should ideally meet all of the following
> > criteria:
> > * AEAD only
> > * PFS only
> > * TLS 1.2 and 1.3 support
> > * no TLS 1.0 or 1.1 support (let alone SSL)
> > * no use of broken hashes (MD5, SHA1, etc.)
> 
> That's a good idea.
> 
> Want to throw together a quick draft for curdle or AD-sponsored SAAG?

Well, my own view is (with explanations):

- AEAD only.

TLS streammode has all ciphers deprecated, and furthermore contains a
design mistake. TLS blockmode padding is outside MAC, which makes
implementing such modes securely very hard. This leaves just AEAD
ciphers.

- No use of broken, dubious, <128-bit keylength or <128-bit blocklength
  ciphers.

These probably won't last long until becoming attack vectors (RC4
anyone, that was dubious back in late 90s, when TLS 1.0 was done).

- PFS or pure-PSK only.

Small things can't do PFS unforunately.

- No use of l < 2^241 for key exchange.

Such key exchanges provode <120 bits of security (or thereabouts).
I used 2^241, since this is between the values used by methods claiming
to be "128-bit secure" and "112-bit secure" (or even weaker).

- Security of any key exchange method against classical attacks has to
  be well established.

No key exchanges that are dubious against non-quantum attacks. Impiles
hybrid PQC exchanges,if relevant. I have seen a dubious key exchange
method just catastrophically fail.

- Support TLS 1.3 (unless it is a security fix for earlier TLS, in that
  case it has to co-exist with TLS 1.3).

The current version of TLS in the relevant timeframe will be 1.3.

- No fallbacks for TLS 1.0 or 1.1.

Don't waste effort on TLS 1.0 or 1.1. Use any new features in TLS 1.2
(e.g., not having to define key exchange methods for signature methods)
if those make things simpler.

- No use of broken, dubious, unusual (including usage mode) or <128-bit
  secure hashes.

These probably won't last long, or will be headache to find
implementations for (e.g., try finding implementation of Skein that
supports any more exotic use of datatyping than the native MAC mode,
the reference implementation does not).




-Ilari