RE: 9.2.2, Rough Consensus, and Working Code

The server administrator has learned that a particular cipher (perhaps AES-GCM) has been broken, and immediately disabled it on his machine.  TLS negotiation ends with a ciphersuite acceptable to the administrator (and his TLS config) in 20XX, but not to this working group at the end of 2014.

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Wednesday, November 5, 2014 4:06 PM
To: Mike Bishop
Cc: Mark Nottingham; HTTP Working Group
Subject: Re: 9.2.2, Rough Consensus, and Working Code

On 5 November 2014 15:39, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> if there's no required enforcement, then the others aren't really MUSTs, either.

Only if you like to play Russian Roulette.  If the others aren't MUSTs, then when you don't comply you risk getting shut down.  That's interoperability failure of a sort, is it not?

> If it rejects the client's security settings, the client can't know 
> for sure what configuration the server would accept

I don't think that this is right.  The reasons for sending INADEQUATE_SECURITY are precise, so it has to be one of those things.
You aren't allowed to send INADEQUATE_SECURITY for other reasons (that is a clarification that I'm prepared to add to #615).  Can you describe a scenario where the server would send this message and the client would be unable to determine what was wrong?

Received on Thursday, 6 November 2014 20:11:21 UTC