Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-00.txt

[Nikos Mavrogiannopoulos <[e-mail]>]

On Mon, 2015-06-15 at 19:46 -0400, Jeffrey Walton wrote:
> > 
> > > > What is the use-case?
> > > 
> > > 0.   Authentication other than via certificate-based PKI. 
> > >  Establish
> > >      anon TLS, and channel-bind the TLS-unique via GSSAPI or some
> > >      other authentication method.
> > > 
> > > 1.  Unauthenticated opportunistic TLS.
> > > 
> > >     * Server performs no unnecessary signature operations,
> > >       since the client can't verify the signature anyway.
> > >       (More precisely the client can't verify the authenticity
> > >       of the server keys, so it can only determine that somebody
> > >       signed the handshake, but no idea whether it is the 
> > > intended
> > >       server).
> > 
> > Both those use-cases can be achieved by choosing, say, ECDHE_ECDSA 
> > and
> > not verify the signature, right?
> > 
> That's a violation of the engineering requirements :) If you don't
> need server authenticity, then you don't ask for it. If you ask for
> it, then you have to validate it.

Not really. Validation of certificates is outside the scope of TLS. You
may validate using PKIX, trust on first use, or not at all and still do
TLS.

Said that, I cannot think of many cases where you don't need server 
authenticity. Even the opportunistic encryption mentioned can use 
server authenticity, to verify using trust on first use for example.
However, if you rely on the anonymous ciphersuites for opportunistic
encryption you ensure that trust on first use _cannot_ be done.

For the use case (0) mentioned, for authentication with alternative 
PKI  methods, rfc7250 is more appropriate, rather than an anonymous 
ciphersuite.

For channel-binding using anonymous ciphersuites, is that defined 
somewhere? If that practice is already used and defined by IETF, 
adding an anonymous ciphersuite may make sense.

regards,
Nikos