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

[Hubert Kario <[e-mail]>]

On Tuesday 16 June 2015 10:08:30 Simon Josefsson wrote:
> Jeffrey Walton <[e-mail]> writes:
> >>>> 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.
> 
> It may appear that way -- but implementing support for ANON ciphers is
> more work than NOT implementing support for certificate validation.
> Supporting ANON in standards, implementation, testing/QA etc carry a
> cost.  We should strive towards offsetting costs with use-cases that can
> motivate the costs.

From QA perspective it's easier to test a specific ciphersuite than to test 
some obscure option that disables signature verification that every 
application names differently.

A(EC)DH ciphersutes are well known and used configuration option, "disable 
signature verification on ServerKeyExchange" is not.

> > I know I'm splitting hairs, but I would reject that kind of check-in.
> > I fear a proliferation of
> > https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html.
> > It also creates a few extra rules, and we have to teach them to
> > developers, QA and auditors.
> 
> Negotiating these ciphers and not verifying the signature is already
> widely deployed (e.g., SMTP STARTTLS), so there is nothing new that
> needs to be done.

this is true only in SMTP because of its legacy, it's not something we should 
encourage

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic