Subject: Re: null ciphers in 9.2.2

From: Eric Rescorla <[email-masked]>
Date: Wed, 1 Oct 2014 04:49:45 -0700

On Tue, Sep 30, 2014 at 9:38 PM, Jason Greene <[email-masked]>
wrote:

>
> On Sep 30, 2014, at 10:27 PM, Martin Thomson <[email-masked]>
> wrote:
>
> > On 30 September 2014 20:15, Jason Greene <[email-masked]>
> wrote:
> >> A TLS 1.3 stack will accept a TLS 1.2 client using a cipher which a
> compliant HTTP/2 stack will then reject.
> >
> > How is that possible?  I'm not saying that my understanding is
> > perfect, but I believe that's impossible.
>
> So the current TLS 1.3 draft allows a TLS 1.3 server to accept connections
> for anything from SSL 3 to 1.3. A TLS 1.2 client can specify a block cipher
> like AES256-CBC, and that will be accepted by the TLS stack (unless of
> course the TLS implementation has been operationally configured not to
> allow it).

Yes, and no.

TLS 1.3 servers can concurrently implement multiple versions of TLS. Thus,
if a TLS 1.3 server implement TLS 1.2, it would respond to the ClientHello
you indicate by negotiating 1.2 and selecting the cipher suite. A *pure*
TLS 1.3 server [either because it had been implemented that way or because
it had been configured that way] would, however, fail to negotiate with
such a
client.

-Ekr

> Such ciphers aren’t bad, they just aren’t state of the art, and are
> accepted by major websites/servers right now. They will likely continue to
> be supported as well since sites wish to remain compatible with legacy
> devices and software.
>
> If the client uses HTTP/1.1 and TLS 1.2 talking to a TLS 1.3 server, using
> CBC it will all work fine. However, if the client uses HTTP/2, and CBC ends
> up getting negotiated, then the server needs to reject with
> INADEQUATE_SECURITY. So HTTP/2 is asserting additional restrictions beyond
> what a TLS 1.3 stack would natively do. Since both HTTP/1.1 and HTTP/2
> share the same port, a dual h1/h2 stack will be forced to do fiddly things
> to allow ciphers from H1 that it will disallow on H2.
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
>

---

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Wed, 1 Oct 2014 15:00:41 +0000

Hi Martin,

On 30/09/2014 21:34, "Martin Thomson" <[email-masked]> wrote:
>On 30 September 2014 13:25, FOSSATI, Thomas (Thomas)
><[email-masked]> wrote:
>> true for https resources.  But I can't find any explicit reference to
>>https in 9.2 (and subsections), therefore I was inferring that those
>>requirements also apply to opp-sec use of TLS?
>
>Would you like to make an argument for integrity-only for
>opportunistic security?  I can't imagine any argument that I'd find
>compelling, but am always willing to be surprised.

I was thinking more generally at uses of the H2/TLS combo to access http
(as opposed to https) resources.

One specific use case that I have in mind is making sure that the forward
proxy whose name I have discovered via some mechanism (e.g. Mark¹s WPD) is
the same as the one I¹m actually connected to.  I can get from TLS all the
properties that I need - i.e. identification via proxy's certificate, and
channel integrity from the negotiated key - without encryption.

Cheers

---

From: Jason Greene <[email-masked]>
Date: Wed, 1 Oct 2014 11:49:29 -0500

On Oct 1, 2014, at 6:49 AM, Eric Rescorla <[email-masked]> wrote:

> On Tue, Sep 30, 2014 at 9:38 PM, Jason Greene <[email-masked]> wrote:
> 
> On Sep 30, 2014, at 10:27 PM, Martin Thomson <[email-masked]> wrote:
> 
>> So the current TLS 1.3 draft allows a TLS 1.3 server to accept connections for anything from SSL 3 to 1.3. A TLS 1.2 client can specify a block cipher like AES256-CBC, and that will be accepted by the TLS stack (unless of course the TLS implementation has been operationally configured not to allow it).
> 
> Yes, and no.
> 
> it had been configured that way] would, however, fail to negotiate with such a
> client.

Exactly the TLS protocol allows it, leaving it to implementors and site operators to decide, whereas the http protocol disallows it, leaving it to the HTTP WG to decide. 

HTTP/2 has no real need to specify cipher restrictions (it’s usable over the clear), its just being used as a hostage.

I disagree with that choice, but I can live with being a hostage taker *IF* we do it in a way that doesn’t break abstractions (leading to unnecessary complexity and potential interop problems).  

This can be accomplished by simply having HTTP/2 mandate connections use TLS 1.3.  Every TLS impl I have used has a facility to check the negotiated version, no additional cipher introspection APIs are necessary. Further an H2 impl doesn’t have to bother with specifying ciphers (and potentially getting it wrong). Interop with legacy implementations is easy because the TLS version and cipher suite selection are part of the handshake/negotiation. A client never sends “legacy” ciphers unless the server falls back, which is all handled gracefully in the TLS protocol.

If we can’t wait for TLS 1.3 (which seems, we should be willing to do, since we apparently want everything that’s in it) then we should change the restriction to a deployment recommendation.

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 1 Oct 2014 18:19:51 +0000

+1 on making this a deployment recommendation, for which there's the UTA working group for already. 

It is not in our charter to impose new TLS "instrospection APIs". *IF* that interface is to be done, it should be done elsewhere, in TLS WG or in some W3C group, not here. Perhaps a revision to RFC 2828 is also in order, as that would make it general for both HTTP/1.1 and 2.

If 9.2.2 didn't exist we'd negotiate to the highest version of TLS with the highest crypto available by default. But forcing this into the code per current 9.2.2 would require changes that frankly are not high in our priority list.

> -----Original Message-----
> From: Jason Greene [mailto:[email-masked]]
> Sent: Wednesday, October 1, 2014 9:49
> To: Eric Rescorla
> Cc: Martin Thomson; Stephen Farrell; Greg Wilkins; FOSSATI, Thomas
> (Thomas); HTTP Working Group
> Subject: Re: null ciphers in 9.2.2
> 
> 
> for anything from SSL 3 to 1.3. A TLS 1.2 client can specify a block cipher like
> AES256-CBC, and that will be accepted by the TLS stack (unless of course the
> TLS implementation has been operationally configured not to allow it).
> >
> > Yes, and no.
> >
> > TLS 1.3 servers can concurrently implement multiple versions of TLS.
> > Thus, if a TLS 1.3 server implement TLS 1.2, it would respond to the
> > ClientHello you indicate by negotiating 1.2 and selecting the cipher
> > suite. A *pure* TLS 1.3 server [either because it had been implemented
> > that way or because it had been configured that way] would, however,
> > fail to negotiate with such a client.
> 
> Exactly the TLS protocol allows it, leaving it to implementors and site
> operators to decide, whereas the http protocol disallows it, leaving it to the
> HTTP WG to decide.
> 
> HTTP/2 has no real need to specify cipher restrictions (it's usable over the
> clear), its just being used as a hostage.
> 
> I disagree with that choice, but I can live with being a hostage taker *IF* we do
> it in a way that doesn't break abstractions (leading to unnecessary complexity
> and potential interop problems).
> 
> This can be accomplished by simply having HTTP/2 mandate connections use
> TLS 1.3.  Every TLS impl I have used has a facility to check the negotiated
> version, no additional cipher introspection APIs are necessary. Further an H2
> impl doesn't have to bother with specifying ciphers (and potentially getting it
> wrong). Interop with legacy implementations is easy because the TLS version
> and cipher suite selection are part of the handshake/negotiation. A client
> never sends "legacy" ciphers unless the server falls back, which is all handled
> gracefully in the TLS protocol.
> 
> If we can't wait for TLS 1.3 (which seems, we should be willing to do, since we
> apparently want everything that's in it) then we should change the restriction
> to a deployment recommendation.
> 
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 6 Oct 2014 06:20:47 +1100

Hi Martin,

Given that this thread was quickly hijacked to discuss other issues, and no one has actually given feedback on this, I think that’s a reasonable clarification.

Cheers,

On 27 Sep 2014, at 1:49 am, Martin Thomson <[email-masked]> wrote:

> As a clarification, I think that we need to be sure to say that the
> null cipher is not permitted.
> 
> Technically, the null cipher is a stream cipher, but this isn't made
> explicit in the draft.
> 
> I'm going to add this to the chain of changes I have for 9.2.2, since
> I hate managing conflicts.  So it won't hit the main spec until we
> resolve that issue.
> 

--
Mark Nottingham   http://www.mnot.net/

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 6 Oct 2014 10:37:36 +1100

On 6 October 2014 06:20, Mark Nottingham <[email-masked]> wrote:

> Given that this thread was quickly hijacked to discuss other issues, and
> no one has actually given feedback on this, I think that’s a reasonable
> clarification.

I don't think it is fair to characterise my initial feedback to Martin's
enquiry as a hijack.  Specifically I noted that using null ciphers is a
debugging technique that will not be available if null ciphers are
prohibited.

The issue is that if we bake in restrictions for the main deployment mode
of the protocol, we are prohibiting niche deployments modes that may use
null, weak or unusual ciphers.

I think that is valid feedback to Martin's question.

regards

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 6 Oct 2014 10:45:25 +1100

On 6 Oct 2014, at 10:37 am, Greg Wilkins <[email-masked]> wrote:

> The issue is that if we bake in restrictions for the main deployment mode of the protocol, we are prohibiting niche deployments modes that may use null, weak or unusual ciphers.

That’s by design. Nothing stops someone from explicitly configuring a pair of endpoints to violate the protocol for testing purposes — we just need to be clear what “normal” operation is.

Cheers,

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 6 Oct 2014 15:37:01 +1100

On 6 October 2014 10:45, Mark Nottingham <[email-masked]> wrote:

>
> That’s by design. Nothing stops someone from explicitly configuring a pair
> of endpoints to violate the protocol for testing purposes:

There is something stopping that.  We have a fragile handshake that will
definitely break if 9.2.2 is implemented by configuration. 9.2.2 is hard
coded in FF and the discussion here has been very much that implementations
should check cipher properties. So there is no "Configuring" of 9.2.2
non-compliance,   you might configure in a null/weak cipher, but the hard
coded isAEAD() will reject it for h2 purposes.

You cannot simultaneously argue that deployers can configure their
endpoints however they like for their special needs AND that the fragile
handshake will never break because there will never be  differing
interpretations of 9.2.2

So I remain in the can't live with it camp for 9.2.2.   I cannot live with
a deliberately fragile and inflexible design.       Jetty will not be
implementing this (not that we have the option as the APIs do not exist for
us to do so).

regards

---

From: Nicholas Hurley <[email-masked]>
Date: Mon, 06 Oct 2014 11:14:41 -0700

On Sun, Oct 5, 2014, at 21:37, Greg Wilkins wrote:

On 6 October 2014 10:45, Mark Nottingham <[1][email-masked]>
wrote:

  That’s by design. Nothing stops someone from explicitly
  configuring a pair of endpoints to violate the protocol for
  testing purposes:

There is something stopping that.  We have a fragile handshake
that will definitely break if 9.2.2 is implemented by
configuration. 9.2.2 is hard coded in FF and the discussion
here has been very much that implementations should check
cipher properties. So there is no "Configuring" of 9.2.2
non-compliance,   you might configure in a null/weak cipher,
but the hard coded isAEAD() will reject it for h2 purposes.

Well that's just patently untrue. There is, in fact, an option
to prevent Firefox from enforcing the TLS requirements. Just
because we're not advertising it widely (since we do, in fact,
want people to conform to 9.2.2) doesn't mean it doesn't exist
for testing purposes. I've made use of it plenty of times (and
still do, on the rare occasion I come up against someone that
doesn't implement 9.2.2).

So... yes, it's entirely possible, as Mark said, to configure a
pair of endpoints to violate the protocol for testing. I can't
speak to other people's implementations, of course, but I
wouldn't be surprised if others have a similar flag hidden
somewhere (or had one in the past, when 9.2.2 compliance was
less common).

--
Peace,
  -Nick

References

1. mailto:[email-masked]

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 7 Oct 2014 07:55:25 +1100

Nicholas,

I was not implying that FF has done anything wrong and it is good to know
that there is a configuration to turn off 9.2.2 checking.

But my point remains. if 9.2.2 is configurable, then a server cannot know
on what basis a cipher is offered - is it a h1 fallback cipher or a
configured weak cipher.  If the server guesses wrong communication failure
results even though the pair might have protocol/cipher choices that are
acceptable.

The argument made when the fragile handshake was pointed out was that 9.2.2
could never ever be implemented differently and thus would not be subject
to configuration.   So when I point out that null ciphers/weak/unusual
ciphers might have niche use-cases, it can't be argued that acceptable
ciphers are indeed configurable.

regards

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Oct 2014 00:06:34 -0400

> results even though the pair might have protocol/cipher choices that are

I don't understand this argument. The server doesn't have to guess, it just
complies
with with 9.2.2 and things should work regardless of whether the client is
configured to accept non-AEAD ciphers for h2 or not.

More generally, clients and servers routinely have hidden switches to
override
specification requirements for testing purposes: to take a non-HTTP example,
the getUserMedia() specification explicitly requires the user to be prompted
before granting camera and microphone access, but Firefox has a pref in
about:config to let you override that. When you flip that preference,
Firefox
becomes nonconformant. There are reasons to do that for testing, but if you
do it, you're on your own. I don't see the situation here as being any
different.

-Ekr

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 8 Oct 2014 09:14:04 +1100

Eric,

You are saying that we will be OK if endpoints "just comply with 9.2.2",
yet that "clients and servers routinely have hidden switches to override
specification requirements".     Thus you are saying we will routinely be
exposed to a fragile handshake that might not work.

9.2.2 interpretation is and will be subject to configuration.  Initially
the configuration might be made non compliant only for testing or for niche
deployments.  But in future, who know how ciphers will evolve and how that
configuration will be changed in real deployments.

We need a robust handshake that will not fail if there is some deviation
from strict 9.2.2 compliance in configuration.       We need to allow "h2
acceptability" to be evolve by experts and experience without the risk of
connection failure when there are mutually acceptable protocol/cipher
pairs.

See other thread for the start of a concrete proposal for this.

cheers

On 7 October 2014 15:06, Eric Rescorla <[email-masked]> wrote:

> I don't understand this argument. The server doesn't have to guess, it
> just complies

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 Oct 2014 15:37:26 -0700

On 7 October 2014 15:14, Greg Wilkins <[email-masked]> wrote:
> You are saying that we will be OK if endpoints "just comply with 9.2.2", yet
> that "clients and servers routinely have hidden switches to override

That's a logical fallacy called a category mistake.  The switches
exist only for private deployments.

I know of many places where standardized protocols are broken in
various ways when there are private agreements between the
communicating parties.  This is what Ekr refers to when he talks about
switches like this.

The document we produce does not apply in those situations, and it
should not attempt to apply.

> 9.2.2 interpretation is and will be subject to configuration.  Initially the
> configuration might be made non compliant only for testing or for niche

As I have said, this is also incorrect.  9.2.2 is unambiguous and
deterministic (modulo the sort of aggressive qualification that ekr
proposed upthread).  This allows for new ciphers, so the set of
ciphers can vary on configuration.  That's a feature.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Oct 2014 15:47:50 -0700

> exposed to a fragile handshake that might not work.

No. I am saying that people who are doing testing can configure their
software in noncompliant ways, which may cause bustage.

-Ekr

>>> I was not implying that FF has done anything wrong and it is good to
>>> know that there is a configuration to turn off 9.2.2 checking.
>>>
>>> But my point remains. if 9.2.2 is configurable, then a server cannot
>>> know on what basis a cipher is offered - is it a h1 fallback cipher or a

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 8 Oct 2014 09:50:58 +1100

On 8 October 2014 09:37, Martin Thomson <[email-masked]> wrote:

> The switches exist only for private deployments.
>

Can guarantee that no such private standards overrides have ever been
deployed publicly?  Or even become the new norm?  RFC2616 had a 2
connection limit, but circumstances made browser first optionally breach
that and then eventually it became the new norm?     We cannot predict the
future and we cannot say that 9.2.2 breaches may not eventually be widely
deployed.

Rather than saying the fragile handshake will not be a problem because you
know what the future will hold, why not just fix the fragile handshake?

What is the down side of fixing the handshake?