Re: 9.2.2, Rough Consensus, and Working Code

On Wed, 05 Nov 2014 04:55:42 +0100, Michael Sweet <msweet@apple.com> wrote:

> Greg,
>
> This is one of the reasons why I proposed just keeping the "MUST support  
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with P256 [FIPS186]"  
> requirement and dropping the rest.  That way HTTP/2 capable servers and  
> proxies can continue to offer HTTP/1 compatible cipher suites to provide  
> the best security and interoperability without hacks.
>

This, together with some text defining DH parameter size, is good because  
it allows everyone to do the right thing. It is bad because it doesn't  
force everyone to do the right thing. However, the current 9.2.2 text  
doesn't force the implementations to do the right thing from protocol  
design, but by coercion. If the client sends all possible ciphers and the  
server selects a non-TLS1.3 cipher, then there is nothing technically that  
stops the client from accepting that. Rules without enforcement are  
recommendations.

So we could move from the current 9.2.2 text saying

                                     MUST  SHOULD  MAY
Client sends ECDHE-AES-GCM          X
Server selects TLS 1.3 compatible   X
Client verifies server selection    X

to
                                     MUST  SHOULD  MAY
Client sends ECDHE-AES-GCM          X
Server selects TLS 1.3 compatible   X
Client verifies server selection          X

and get something stronger than Michaels proposal that maybe is palatable  
to those without API flexibility to the TLS stack they integrate with.

/Martin Nilsson

-- 
Using Opera's mail client: http://www.opera.com/mail/

Received on Thursday, 6 November 2014 01:09:57 UTC