Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

On 24.09.2014 08:02, Martin Thomson wrote:
> My interpretation of things here is that an application is able to
> demand a certain minimum level of protection.  More correctly, I
> believe that it is the responsibility of an application to make that
> demand.  I choose to interpret the existence of efforts like UTAas an
> indication that this is the institutional belief of the IETF, but will
> let others reach their own conclusions on that.
I agree that the application should do this, but the problem is about h2 
being different security than spdy or h1 within the same application. 
Especially 9.2.2 says nothing about h1. So what do you do as app 
developer if you have to implement two protocols with conflicting 
requirements? Is 9.2.2 limiting what h3 can require?
> On the specifics of this matter, I don't think that there is any
> question that we are entitled to require that packets be encrypted,
> rather than using a suite like say TLS_RSA_WITH_NULL_SHA, which
> doesn't encrypt at all.  And as a practical matter, the difference
> between that and something as weak as TLS_RSA_WITH_DES_CBC_SHA is
> pretty much academic.  Maybe that distinction matters more to you, but
> I contend that practicality rules here.
>
> Similarly, I believe that is well within our rights to request a suite
> that can offer forward secrecy.
If you accept this then you need to accept that other protocols do the 
same. TLS doesn't allow you to bind the offers to upper layer protocols.

Received on Wednesday, 24 September 2014 08:44:12 UTC