Subject: Re: #612: 9.2.2 requirements

From: Roland Zink <[email-masked]>
Date: Sat, 1 Nov 2014 11:17:24 +0100

> Am 31.10.2014 um 22:05 schrieb Brian Smith <[email-masked]>:
> 
> 
> First of all, it is almost always going to be a bad idea to have the server TLS stack choose which application protocol to use. Instead, it should defer that choice to the server application. 

The TLS layer can check the ALPN and then call the appropriate server application, e.g. If it contains h2 then call the h2 stack, if it SMTP then call the SMTP stack and as fallback call the http/1.1 stack. Give this to the application layer protocol handler seem to be a layering problem.

> Second of all, if the server doesn't take that advice, and the TLS stack has already chosen h2, then the HTTP/2 layer might as well keep going on the assumption that XYZ is OK, because it 
I think this violates 9.2.2.

> hasn't given itself any better choice, due to not taking that advice. If things don't work, the server administrator will likely fix it by improving the cipher suite configuration, probably by reading section 9.2.2 of the specification or documentation derived from it. Of course, it's better for the server software implementation to just automatically do the right thing, but that's a quality-of-implementation issue, not a protocol issue.

The protocol doesn't provide it and you give the correct handling to the application. What should a TLS protocol offloading device do? Does it needs to know all requirements of all future protocols or is there an interaction with the upper layer processing machines necessary?

Regards,
Roland

---

From: Roland Zink <[email-masked]>
Date: Sat, 1 Nov 2014 12:31:12 +0100

Am 31.10.2014 um 19:35 schrieb Mark Nottingham <[email-masked]>:

>> On 27 Oct 2014, at 1:54 pm, Mark Nottingham <[email-masked]> wrote:
>> 
>> <https://github.com/http2/http2-spec/issues/612>
>> 
>> Reviewing the discussion, I think it’s going to be difficult to declare consensus on 9.2.2 in its current form.
> 
> And yet, I get the big bucks* from the IESG to do the difficult things. Winning a straw poll is not necessarily consensus in the IETF.
> 
>> Talking through it with a few of the proponents, my proposal to close this issue is to remove 9.2.2 (i.e., the specific requirements on cipher suites), but leave 9.2.1 (the section on TLS features) as-is.
> 
> Talking it through at length with our Area Director and other IETF leadership, this will not fly (at least that easily). 
> 
> The fundamental technical issue — publishing a protocol standard that allows cipher suites that we know to be insecure — has not been addressed. Patrick is absolutely right about this. 
If this is the concern then the cipher suites are not defined in h2. The correct way of doing this would be to copy TLS 1.2, add the text from 9.2.2 and publish this as TLS 1.3. Otherwise you are proposing insecure cipher suites for a lot of use cases including HTTP/1.1.

> The question at hand is what interoperability cost is involved in 9.2.2. If it is a cost paid by a few implementations who don’t have adequate APIs immediately at hand, that is emphatically *not* a technical issue. 
> If it were a considerable interoperability cost to the whole community — i.e., it caused long-term problems across most or all deployments of the new protocol — it would be serious enough to warrant consideration. 
> 
My concern is mostly about the future, e.g. how is it possible to add a new cipher and/or new protocols. Without a plan how this can be accomplished without causing interoperability issues the short time advantage of having 9.2.2 may just be a step into the wrong direction.

> So far, this does not seem to be the case; a significant number of browser vendors have said that they will not fall back to HTTP/1.1 if they see servers that cause them to throw INADEQUATE_SECURITY, thereby isolating those servers that are not conformant (and giving them a *very* strong incentive to become conformant). Even if they were to retry, it would not be an interoperability issue; only a performance degradation for non-conformant servers.
If I assume the ciphers can be configured at servers then administrators may break conformance without knowing it. Some clients may still work if they do a fallback. Then interoperability issues may occur quite often.

> In other words, while 9.2.2 may retard deployment of the new protocol while some implementations are updated to support it, it does not seem to put the entire effort at risk of interoperability problems.
> 
> The arguments that this is a process or layering issue are not valid; both have been refuted.
> 
> While some may consider the handshake “fragile”, they’ll need to explain how — given the above context — it affects interoperability in a way that’s significant. So far, I haven’t seen an explanation of how the handshake raises such an issue.
> 
Assuming a new cipher xyz is added in a revision to 9.2.2 and to TLS. Then the clients TLS library is updated and supports xyz. The server is updated to support xyz as well. The client now offers xyz and h2. The server selects h2 together with xyz. The clients h2 implementation doesn't know about xyz and rejects it, although it would accept it together with h1.

Now is it necessary to bump up the http2 version number and ALPN token if a new cipher xyz not matching the 9.2.2 requirements is added? Or is it so unlikely that this is of no concern?

> If you think you have one, please carefully explain it to us (even if you have before — and thank you for your patience) soon. Without more (and convincing) information, we don’t have adequate reason to remove 9.2.2 from the specification, and therefore I think that the resolution that gets us to consensus on #612 is Martin’s first pull request:
> 
>  https://github.com/http2/http2-spec/pull/615
> 
> Sorry for the back-and-forth; it’s important to get this right.
> 
> Regards,
> 
> 
> * If I’m really lucky, Barry will buy me a drink in HNL.
> 
> --
> Mark Nottingham   http://www.mnot.net
> 
Regards,
Roland

---

From: Michael Sweet <[email-masked]>
Date: Sat, 01 Nov 2014 08:14:50 -0400

[replying to my own post as sleep has yielded an additional argument]

Normally we specify conformance requirements for interoperability, to enforce a particular semantic or property, or to ensure a minimum level of functionality. The current 9.2.2 text is making a mandate purely to enforce a TLS best practice, and in doing so is putting an undue burden on already complex implementations of TLS to make sweeping changes on both the client and server side that negatively affect interoperability while violating layering - the TLS stack now needs knowledge about the application protocol.

I am not a fan of making hard requirements on cipher suites. I know from experience that such requirements become out of date quickly, forcing otherwise unnecessary updates to specifications, and they do not allow developers or users to make different choices (valid or otherwise) without sacrificing conformance.

However, in this case it seems that some feel that the mandatory cipher suite in TLS/1.2 is inadequate, and that a specific set of cipher suites is now preferred (and MAY be a requirement in TLS/1.3). Therefore, the proper, RFC 2119, approach would be to require support for one or more cipher suites that are seen as providing adequate security - that ensures interoperability and that the two end points will be able to negotiate a "secure" connection without requiring layering violations or causing interoperability problems.

Sent from my iPad

> On Oct 31, 2014, at 8:09 PM, Michael Sweet <[email-masked]> wrote:
> 
> Brian,
> 
>> On Oct 31, 2014, at 7:11 PM, Brian Smith <[email-masked]> wrote:
>> 
>> Michael Sweet <[email-masked]> wrote:
>>> First, TLS does not provide a way to tie cipher suite selection to ALPN. 
>> 
>> Sure it does. It is easy to see how a TLS implementation could be designed such that it associates every ALPN protocol with a different set of cipher suites and then chooses a cipher suite based on that information, even before, during, or after it decides which protocol to advertise with ALPN 
> 
> Sigh. No implementation exists to offer that feature set, and the ALPN negotiation doesn't have information on what a particular protocol needs. And worse, there are already multiple protocols that a browser might negotiate, with different cipher suite requirements!
> 
>>> That makes it impossible for a client or server to restrict their ciphers without deciding ahead of time to first try only HTTP/2-compatible cipher suites and, when that fails, re-try a HTTP/1.x only connection.  I think that counts as a technical issue, and definitely a performance issue that will only hurt adoption of HTTP/2 or force UAs to try two connections in parallel to avoid the HTTP/1 penalty.
>> 
>> There are already implementations doing the thing that you call impossible, so it is clearly not impossible.
> 
> We have limited deployment of implementations that use their own crypto toolkits, or that only support http/2 and its cipher suites. And a bunch of work in progress prototypes whose developers have been complaining about these requirements from day one because their own toolkits are not capable of supporting both http/1 and http/2 TLS requirements.
>  
>>> Second, you cannot dismiss the inadequate API issue.  Currently only OpenSSL and GNU TLS offer APIs to select cipher suites based on general capabilities, and even they are not sufficient to match all of 9.2.2's current restrictions.  For SSP on Windows and SecureTransport on iOS and OS X, you have to either hardcode a list of known cipher suite constants or try to write a blacklist by querying the supported cipher suites and removing those that are known not to be acceptable.  On top of that is a known bug in SecureTransport that prevents you from actually using the API to set the enabled cipher suites... :/  None of the common TLS libraries provide a way to ask what the security properties of a particular cipher suite are, so it is impossible to programmatically support 9.2.2 and support new cipher suites without a code change in the application layer.
>> 
>> Those are *all* implementation issues that can easily be fixed. Also, keep in mind that the HTTP/2 implementation can choose to use a different TLS stack that is more capable and/or easier to modify. In particular, you're not forced to use SecureTransport or SSP.
> 
> You do if you want to ship applications for a particular OS and support the OS supplied TLS policies.
> 
>> Also, I see no reason to think that it is impossible to modify SecureTransport or SSP to have the additional capabilities in a way that is backward-compatible and non-disruptive to existing applications.
> 
> The point is that they cannot support HTTP/2 today with these restrictions, not that we can't make arbitrary API to support an arbitrary and questionable line in the sand that has obvious interop issues with today's web. HTTP/1 will be around for a very long time yet, so intentionally adding barriers to HTTP/2 adoption seems short sighted. You're trying to mandate security in a way that causes interoperability problems, and conformance requirements are supposed to work the other way (I.e., improve interoperability)
>

---

From: "Jason T. Greene" <[email-masked]>
Date: Sat, 1 Nov 2014 09:51:29 -0400 (EDT)

>> On Oct 31, 2014, at 11:12 PM, Martin Thomson <[email-masked]> wrote:
>> 
>> On 31 October 2014 20:49, Jason Greene <[email-masked]> wrote:
>> My point is that a legacy compatible client advertises cipher suites that aren’t compatible with H2 before H2 is selected. This is in contrast to a 1.3 client that would advertise 1.3 ciphers, and use SCSV fallback for pre 1.3 ciphers, which is a much more robust handshake, and leaves the TLS cipher selection where it belongs.
> 
> That's not right.  A 1.3 client will offer cipher suites that are only
> supported in 1.2 and earlier because a round-trip is a high price to
> pay for guessing wrong.  What you suggest would basically prevent 1.3
> from ever being deployed.
> 
> The 1.3 handshake will be compatible with all 1.2 and earlier servers
> (assuming that they are not version or extension intolerant...i.e.,
> not broken).

Ah yes, you are right. I was under the mistaken impression that there was a desire to discourage these ciphers, but I suppose the reality is clients would be blamed for this cost, so they will always include. Further it doesn't really matter whether they are included or not since they will always be in the right order, and the TLS implementation has all the knowledge and facilities to properly reject the wrong cipher with the wrong TLS.

Reconsidering Brian's argument regarding ALPN behavior, it's perfectly plausible that a TLS impl could validate the ALPN + cipher combination and ensure either the right ciphers are chosen, or that the ALPN missing the proper cipher requirements is not selected by the application. Following this line of thought I must concede that there is no TLS protocol problem. 

In fairness, the issue instead a practical one (the lack of support by TLS implementations, and the inability of H2 implementations to comply with these rules at the time of H2 standardization)

---

From: Nicholas Hurley <[email-masked]>
Date: Sat, 1 Nov 2014 09:42:03 -0700

> On 1 Nov, 2014, at 05:14, Michael Sweet <[email-masked]> wrote:
> 

Good news! Quoting 9.2.2:

"To avoid this problem, implementations of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE <http://tools.ietf.org/html/draft-ietf-httpbis-http2-14#ref-TLS-ECDHE>] with P256 [FIPS186 <http://tools.ietf.org/html/draft-ietf-httpbis-http2-14#ref-FIPS186>].”

which, by the way, it has said as long as I can remember. Thus, we always will have a cipher suite that implementations advertising “h2” can agree on. If that cipher suite, at some point in the future, becomes unsatisfactory, then we will update the RFC, and make the new RFC require a new ALPN token. Problem solved.

Everything else in 9.2.2 is basically just saying if you want to use a cipher suite that’s NOT the one mentioned above, AND you’re using TLS 1.2, then it has to meet certain requirements (which the specified cipher suite does, in fact, meet).

---

From: "Martin Nilsson" <[email-masked]>
Date: Sat, 01 Nov 2014 17:53:00 +0100

On Fri, 31 Oct 2014 22:14:29 +0100, Patrick McManus <[email-masked]>  
wrote:

>
> On Fri, Oct 31, 2014 at 3:42 PM, Jason Greene <[email-masked]>  
> wrote:
>>
>>>> Ilari’s use case is a great example of where it all goes wrong:
>> http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0167.html
>
> I believe that just describes an API limitation, not a protocol problem.  
> A hypothetical implementation directly participated in the negotiation  
> of >XYZ and h2 but for whatever reason cannot ensure the relevant  
> properties of XYZ with respect to h2's application profile of tls laid  
> out in 9.2.

I think it can be even easier than that. Given the assumption that no new  
suites will be created with worse security properties than the banned ones  
the ciphersuite can be any of these three

- Known and secure
- Known and insecure
- Unknown and secure

/Martin Nilsson

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

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 02 Nov 2014 04:50:13 +0900

On 2014/11/02 01:53, Martin Nilsson wrote:

> I think it can be even easier than that. Given the assumption that no new suites
> will be created with worse security properties than the banned ones the
> ciphersuite can be any of these three
>
> - Known and secure
> - Known and insecure
> - Unknown and secure

Not necessarily true. Of course nobody wants to create new suites with 
worse properties, but just imagine a new suite that looks very good and 
gets introduced, but then a year or two down the line, a crucial flaw is 
found. For a piece of software that hasn't been updated during that 
time, the cypher is unknown but insecure.

Regards,   Martin.

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 2 Nov 2014 09:04:44 +1100

> On 1 Nov 2014, at 6:42 am, Jason Greene <[email-masked]> wrote:
> 
> It would be great to hear the refutation to Microsoft’s position that the UTA is more appropriate for mandating TLS implementation API enhancements, and not the HTTP WG:
> 
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0114.html

The only applicable argument I see there is "Historically this type of document is separate from the core protocol”. 

UTA was chartered to recommend best practices for existing protocols, and give guidelines to future protocols; it does not constrain what we can do with TLS. I specifically asked this question during the chartering process for UTA and was satisfied with the result; HTTP/2’s approach to TLS is *not* controlled by UTA.

Cheers,

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

---

From: Michael Sweet <[email-masked]>
Date: Sat, 01 Nov 2014 22:55:44 -0400

Nicholas,

> On Nov 1, 2014, at 12:42 PM, Nicholas Hurley <[email-masked]> wrote:
> 
> 
> "To avoid this problem, implementations of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with P256 [FIPS186].”

I have no problem with this.  I *do* have a problem forbidding all of the other TLS/1.2 cipher suites (including the mandatory cipher suite in RFC 5246) which is a) not necessary for interop and b) causes interop and implementation problems.

Also, based on the traffic on the TLS WG list, it looks like TLS/1.3 will still include cipher suites that are not allowed by the current HTTP/2 text, but are otherwise considered "secure".  And thanks to the current wording, they will be valid when TLS/1.3 is negotiated but not TLS/1.2. (think of the interop issues there!)

Include recommendations if you must.  Explain the reasons for using particular kinds of cipher suites, or provide caveats that HTTP/2 over TLS has only had a crypto analysis with particular cipher suites, etc.  But don't lump on conformance requirements that will only hurt interoperability and deployment of HTTP/2.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Nov 2014 06:16:36 -0800

On Sat, Nov 1, 2014 at 7:55 PM, Michael Sweet <[email-masked]> wrote:

> >> However, in this case it seems that some feel that the mandatory cipher
> suite in TLS/1.2 is inadequate, and that a specific set of cipher suites is
> now preferred (and MAY be a requirement in TLS/1.3). Therefore, the proper,
> RFC 2119, approach would be to require support for one or more cipher
> suites that are seen as providing adequate security - that ensures
> interoperability and that the two end points will be able to negotiate a
> "secure" connection without requiring layering violations or causing
> interoperability problems.
> >
> > "To avoid this problem, implementations of HTTP/2 that use TLS 1.2 MUST
> support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with P256
> [FIPS186].”
>
> I have no problem with this.  I *do* have a problem forbidding all of the
> other TLS/1.2 cipher suites (including the mandatory cipher suite in RFC
> 5246) which is a) not necessary for interop and b) causes interop and
> implementation problems.
>
> Also, based on the traffic on the TLS WG list, it looks like TLS/1.3 will
> still include cipher suites that are not allowed by the current HTTP/2
> text, but are otherwise considered "secure".  And thanks to the current
> wording, they will be valid when TLS/1.3 is negotiated but not TLS/1.2.
> (think of the interop issues there!)
>

Which cipher suites do you believe those will be?

-Ekr

---

From: Michael Sweet <[email-masked]>
Date: Sun, 02 Nov 2014 10:08:33 -0500

The PSK suites.

> On Nov 2, 2014, at 9:16 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
>

---

From: "Martin Nilsson" <[email-masked]>
Date: Sun, 02 Nov 2014 18:29:16 +0100

> time, the cypher is unknown but insecure.

But a flaw can be found in any of the cipher suites, so I don't see this  
as directly related.

/Martin Nilsson

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Nov 2014 11:27:41 -0800

> The PSK suites.

I see.

This doesn't seem like a source of confusion because PSK suites only
work by prior arrangement between the client and server, so it's not
like they are going to be negotiated by generic HTTP2 clients
(modulo the PSK-as-resumption technique proposed by Karthik, which
doesn't seem like a source of confusion either).

-Ekr

> > >> However, in this case it seems that some feel that the mandatory
> cipher suite in TLS/1.2 is inadequate, and that a specific set of cipher
> suites is now preferred (and MAY be a requirement in TLS/1.3). Therefore,
> the proper, RFC 2119, approach would be to require support for one or more
> cipher suites that are seen as providing adequate security - that ensures
> > > "To avoid this problem, implementations of HTTP/2 that use TLS 1.2
> MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with P256
> [FIPS186].”
> >
> > I have no problem with this.  I *do* have a problem forbidding all of
> the other TLS/1.2 cipher suites (including the mandatory cipher suite in
> RFC 5246) which is a) not necessary for interop and b) causes interop and
> implementation problems.
> >
> > Also, based on the traffic on the TLS WG list, it looks like TLS/1.3
> will still include cipher suites that are not allowed by the current HTTP/2

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 3 Nov 2014 11:03:20 +1100

Michael,

> On 2 Nov 2014, at 1:55 pm, Michael Sweet <[email-masked]> wrote:
> 

See the current proposal, which makes the requirements specific to TLS 1.2:
  https://github.com/http2/http2-spec/pull/615

—

---

From: Roland Zink <[email-masked]>
Date: Mon, 03 Nov 2014 11:44:21 +0100

>    https://github.com/http2/http2-spec/pull/615
Wouldn't this be confusing? A cipher is allowed with TLS 1.2, but not 
with TLS 1.2 together with h2. But if h2 is used together with TLS 1.3 
it is allowed again.

Roland

---

From: Michael Sweet <[email-masked]>
Date: Mon, 03 Nov 2014 05:56:18 -0500

That was my point - right now a cipher suite that is valid in both TLS/1.2 and TLS/1.3 may only be usable with HTTP/2 when TLS/1.3 is negotiated. Aside from the confusion factor this seems like a recipe for interop disaster.

Sent from my iPad

> On Nov 3, 2014, at 5:44 AM, Roland Zink <[email-masked]> wrote:
> 
> Wouldn't this be confusing? A cipher is allowed with TLS 1.2, but not with TLS 1.2 together with h2. But if h2 is used together with TLS 1.3 it is allowed again.
> 
>> 
>> —

---

From: Jason Greene <[email-masked]>
Date: Mon, 3 Nov 2014 09:21:20 -0600

> 
> On Oct 31, 2014, at 10:49 PM, Jason Greene <[email-masked]> wrote:
> 
>> No, it doesn't have to reject XYZ. It can carry on based on the assumption that XYZ is OK. If it is, then the client will accept it. If it isn't, the client will return INSUFFICIENT_SECURITY to the server. (Keep in mind that this is only in the worse case where the server's HTTP/2 implementation is based on a TLS stack that is too inflexible to do better things.)
> 
> But that would violate 9.2.2 which clearly refers to both parties. I agree that it would be better if the language where changed to say that the client MUST and the server SHOULD, and would be in favor of that change. That would certainly address the interop issue, but it would still leave the possibility that an h2 client would exclude stronger ciphers than the TLS implementation supports, since the h2 stack may not yet be aware of them.

I have some proposed text for this option here:

https://github.com/http2/http2-spec/pull/639/files

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

---

From: Martin Thomson <[email-masked]>
Date: Mon, 3 Nov 2014 12:20:03 -0800

On 1 November 2014 12:50, "Martin J. Dürst" <[email-masked]> wrote:
>> suites
> Not necessarily true. Of course nobody wants to create new suites with worse
> properties, but just imagine a new suite that looks very good and gets
> introduced, but then a year or two down the line, a crucial flaw is found.
> For a piece of software that hasn't been updated during that time, the
> cypher is unknown but insecure.

The important distinction here is not "secure" or "not secure".  The
distinction is "AEAD" and "not AEAD", which is far more deterministic
than anything regarding security.  So: if you s/secure/AEAD/ in
Martin's list above, you get the right results.

(Note: I'm being imprecise here: it's not a requirement for AEAD, it's
a requirement for NOT stream or block.)

---

From: Martin Thomson <[email-masked]>
Date: Mon, 3 Nov 2014 12:23:41 -0800

> That was my point - right now a cipher suite that is valid in both TLS/1.2 and TLS/1.3 may only be usable with HTTP/2 when TLS/1.3 is negotiated. Aside from the confusion factor this seems like a r…

That doesn't happen.  The set permitted by HTTP/2 is strictly the same
as the set permitted by TLS 1.3.  (1.3 makes exactly the same changes
to the permitted cipher suite list).

---

From: Michael Sweet <[email-masked]>
Date: Mon, 03 Nov 2014 15:49:12 -0500

Martin,

Based on the TLS mailing list discussion, it sounds like there is serious consideration of keeping the PSK suites, which as I understand it do not support AEAD (but I am not a TLS expert, so I could easily be mistaken...)

Again, it makes perfect sense to require support for a known good cipher suite that will be in TLS 1.3 so that each endpoint is assured of being able to interoperate with the other using a known good cipher suite.  It does not make sense to forbid other cipher suites to needlessly complicate interoperability with existing clients and servers and ensure a slow adoption of HTTP/2 because of the resulting confusion, problems, and slowdown.

> On Nov 3, 2014, at 3:23 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 3 Nov 2014 14:18:46 -0800

> Based on the TLS mailing list discussion, it sounds like there is serious consideration of keeping the PSK suites, which as I understand it do not support AEAD (but I am not a TLS expert, so I coul…

AEAD is record protection; PSK is for key exchange.  These are orthogonal.

The questions related to PSK relate to their interaction with
foward-secrecy-capable key exchange (which the 1.3 draft currently
assumes is the only form of full handshake) and with renegotiation
(since Karthik noted that PSK is currently interchangeable with
renegotiation in many cases).

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 5 Nov 2014 12:13:29 +1100

On 1 November 2014 05:35, Mark Nottingham <[email-masked]> wrote:

> While some may consider the handshake “fragile”, they’ll need to explain
> how — given the above context — it affects interoperability in a way that’s
> significant. So far, I haven’t seen an explanation of how the handshake
> raises such an issue.

The problem with 9.2.2 is not that it tries to restrict TLS ciphers to
known good ciphers.   It is that is also tries to allow clients to continue
using known poor ciphers with http1 without any penalty.

If we all collectively just grew a pair and said that known bad ciphers are
not acceptable for HTTP (regardless of version) then the handshake would
not be fragile.

The interoperability problem comes because the handshake does not have the
expressive capability to clearly identify which ciphers are being offered
for h2 and which ciphers are being offered for h1 fallback to bad
ciphers.      This allows the handshake to fail when there is a mutually
acceptable  pairing of protocol and cipher.

I believe the best fix is to only allow h2 acceptable ciphers in the
initial handshake.      If the server fails to accept that connection
attempt, then IF WE REALLY HAVE TO, we can allow clients to retry a h1
connection with old weak ciphers.

The argument against this is that suffering an extra round trip is
unacceptable for the clients that wish to talk to these old weak
servers.     I believe that continuing to talk to such servers is
unacceptable, but if you really have to do it, then adding the round trip
is a good incentive to update ciphers/protocols.

If you want to protect against downgrade attacks, then just don't support
old weak ciphers regardless of the protocol spoken.

regards

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

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 5 Nov 2014 12:31:08 +1100

On 1 November 2014 05:35, Mark Nottingham <[email-masked]> wrote:

>
> The fundamental technical issue — publishing a protocol standard that
> allows cipher suites that we know to be insecure — has not been addressed.
>

Just to double down....  How do you reconcile the position above with the
text in 9.2.2 that says:

   Clients MAY advertise support of cipher suites that are prohibited by
   the above restrictions in order to allow for connection to servers
   that do not support HTTP/2.  This enables a fallback to protocols
   without these constraints without the additional latency imposed by
   using a separate connection for fallback.

If it is not acceptable for a newly published protocol standard to allow
known insecure ciphers, then it is not acceptable for such ciphers to be
offered in a handshake that is offering h2 - full stop.      Why are we
making our handshake fragile for all time, just so we can avoid "additional
latency" for known insecure ciphers.

Remove that paragraph and I'm basically happy - modulo any improvements in
the cipher restriction text being discussed here.

cheers

---

From: Yoav Nir <[email-masked]>
Date: Wed, 5 Nov 2014 07:31:25 +0200

> On Nov 5, 2014, at 3:13 AM, Greg Wilkins <[email-masked]> wrote:
> 
> 
> On 1 November 2014 05:35, Mark Nottingham <[email-masked] <mailto:[email-masked]>> wrote:
> The problem with 9.2.2 is not that it tries to restrict TLS ciphers to known good ciphers.   It is that is also tries to allow clients to continue using known poor ciphers with http1 without any penalty.

You are implying that TLS_RSA_WITH_AES_128_CBC_SHA is known insecure. This is not the case.

Yoav

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 5 Nov 2014 17:01:34 +1100

> You are implying that TLS_RSA_WITH_AES_128_CBC_SHA is known insecure.

Not at all.

I'm saying that it allows a h2 handshake to include weak ciphers for the
purposes of h1 fall back:

This is the clause that causes the handshake to be fragile, because the
ALPN protocol does not support differing cipher sets for each protocol.
So it is not possible for a server to distinguish between a unknown cipher
being offered as a h2 cipher or as a h1 fallback.

There are two linked conversations going on.  One about what ciphers we
should (or should not) restrict and one about the handshake. Some are
trying to argue that the definition of what ciphers to restrict is crystal
clear and future proof, so that the fragile handshake is not a
problem.         They may well be right, but they cannot prove that to be
the case.  Thus I am arguing that the handshake should be fixed - so that
if the future of ciphers does turn out to be less than crystal clear then
the result not a handshake failure.

If we have a robust handshake, then I am prepared to accept cipher
restrictions recommended by experts  even though I do not believe they
belong in an application protocol.

Without a robust handshake, I am not prepared to even attempt getting
involved in cipher negotiations. Jetty will just try to use whatever the
TLS layer negotiates regardless of protocol.

regards

---

From: Yoav Nir <[email-masked]>
Date: Wed, 5 Nov 2014 08:36:42 +0200

> On Nov 5, 2014, at 8:01 AM, Greg Wilkins <[email-masked]> wrote:
> 
> 
> On 5 November 2014 16:31, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
> I'm saying that it allows a h2 handshake to include weak ciphers for the purposes of h1 fall back:
> This is the clause that causes the handshake to be fragile, because the ALPN protocol does not support differing cipher sets for each protocol.     So it is not possible for a server to distinguish between a unknown cipher being offered as a h2 cipher or as a h1 fallback.
> 
> There are two linked conversations going on.  One about what ciphers we should (or should not) restrict and one about the handshake. Some are trying to argue that the definition of what ciphers to restrict is crystal clear and future proof, so that the fragile handshake is not a problem.         They may well be right, but they cannot prove that to be the case.  Thus I am arguing that the handshake should be fixed - so that if the future of ciphers does turn out to be less than crystal clear then the result not a handshake failure.
> 
> If we have a robust handshake, then I am prepared to accept cipher restrictions recommended by experts  even though I do not believe they belong in an application protocol.
> 
> Without a robust handshake, I am not prepared to even attempt getting involved in cipher negotiations. Jetty will just try to use whatever the TLS layer negotiates regardless of protocol.

Then we’re on the same page. I think the sanest way to implement this is to have the HTTP implementation ignore ciphersuites entirely and have the TLS layer know which ciphersuites go with h2 and which go only with h1.

That’s an ugly hack IMO because a TLS library should be generic - good for HTTP, SMTP, our proprietary protocol for managing firewalls. Placing HTTP/2-specific logic in it is an ugly hack, but it’s better than adding multiple APIs.

Yoav

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 6 Nov 2014 10:19:16 +1100

Greg,

On 5 Nov 2014, at 12:13 pm, Greg Wilkins <[email-masked]> wrote:
> If we all collectively just grew a pair and said that known bad ciphers are not acceptable for HTTP (regardless of version) then the handshake would not be fragile.

We're here to define HTTP/2, not redefine HTTP/1. The time to make this argument was during bis, and I suspect it would have had a similar reaction; we can't put new requirements on the existing, deployed Web. 

More to the point, prescribing fallback / retry behaviours is something that HTTP has historically avoided, for good reason; it's up to a client when and how they retry a request, and they may (for good reason) use different approaches. We're here to define how all HTTP implementations behave, not just browsers.

> The interoperability problem comes because the handshake does not have the expressive capability to clearly identify which ciphers are being offered for h2 and which ciphers are being offered for h1 fallback to bad ciphers.      This allows the handshake to fail when there is a mutually acceptable  pairing of protocol and cipher.

"Lack of expressive capability" is not necessarily an interoperability problem. Likewise, as per above failing to make a connection is always a possible end state, if the client and server can't agree on requirements.

However, it still hasn't been shown how this will be the case with HTTP/2, if both the client and server are conformant to the proposed text.

>> The fundamental technical issue — publishing a protocol standard that allows cipher suites that we know to be insecure — has not been addressed. 
> 
> Just to double down....  How do you reconcile the position above with the text in 9.2.2 that says:
> 
> If it is not acceptable for a newly published protocol standard to allow known insecure ciphers, then it is not acceptable for such ciphers to be offered in a handshake that is offering h2 - full stop.      Why are we making our handshake fragile for all time, just so we can avoid "additional latency" for known insecure ciphers.

We are also publishing a protocol that needs a realistic chance of transitioning from HTTP/1. Your statement before:

> The argument against this is that suffering an extra round trip is unacceptable for the clients that wish to talk to these old weak servers.     I believe that continuing to talk to such servers is unacceptable, but if you really have to do it, then adding the round trip is a good incentive to update ciphers/protocols.

is quite revealing. Do you really think that this WG can declare widely deployed cipher suites as non-conformant in HTTP/1, and browsers will just start refusing to interoperate with those servers? 

> Remove that paragraph and I'm basically happy - modulo any improvements in the cipher restriction text being discussed here.

Greg, with all respect, we're not here to make all participants happy -- it is a completely normal end-state in the IETF for many to be unhappy. What we need to do is address technical issues that are brought to our attention. 

Regards,

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

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 6 Nov 2014 10:43:26 +1100

Mark,

your response is a whole bunch of straw men.  You are talking about things
that I am just not proposing.

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

> Greg,
>
> We're here to define HTTP/2, not redefine HTTP/1. The time to make this
> argument was during bis, and I suspect it would have had a similar
> reaction; we can't put new requirements on the existing, deployed Web.
>
>
I am not suggesting that we  redefine HTTP/1

I'm saying that in the brand new http2 handshake that we are defining,
there is no need to support weak ciphers and old protocols.  If clients
wish to talk weak ciphers to old protocols, they are free to retry
connections using the existing http/1 protocol unchanged.

More to the point, prescribing fallback / retry behaviours is something
> that HTTP has historically avoided, for good reason; it's up to a client
> when and how they retry a request, and they may (for good reason) use
> different approaches. We're here to define how all HTTP implementations
> behave, not just browsers.
>

I'm not prescribing fallback (I did propose that previously but not now).
I endorse Martins text in his PR that simply says that retries may be done,
with suitable warnings about downgrade attacks.     All I'm currently
advocating is that we do not support weak ciphers in the new h2 handshake.

"Lack of expressive capability" is not necessarily an interoperability
> problem. Likewise, as per above failing to make a connection is always a
> possible end state, if the client and server can't agree on requirements.
>
> The interoperability problem is that the client and server may share an
acceptable protocol/cipher pair, but the handshake may fail to negotiate
that.     Connection failure is fine IFF there is no acceptable
cipher/protocol pair.

> However, it still hasn't been shown how this will be the case with HTTP/2,
> if both the client and server are conformant to the proposed text.
>

The situation has been described many times in many variations.   One such
situation is if the server does not have access to the details of the
cipher and only knows it's name.  Then it's 9.2.2 implementation will most
likely be done by white/black lists and/or regular expression matching on
the name.    Such an approach will not be perfect in the face of future
cipher development (the XYZ cipher), thus there is always the opportunity
for differences in 9.2.2 implementation when being updated for new ciphers
and thus the hand shake can fail.

> Do you really think that this WG can declare widely deployed cipher suites
> as non-conformant in HTTP/1, and browsers will just start refusing to
> interoperate with those servers?
>

I'm not saying that at all.   I'm saying that we should not support known
weak ciphers in the new h2 handshake.     Browser making connections using
http1 are free to continue doing whatever they have been doing.

Fundamentally it is a misuse of ALPN for the client to advertise support
for a cipher that is subsequently rejects as inadequate security for the
protocols included in the ALPN handshake.  If you REALLY want to avoid any
increase in latency for talking weak ciphers to old servers, then you need
to come up with an enhancement proposal for ALPN that allows ciphers sets
per offered protocol.

> Remove that paragraph and I'm basically happy - modulo any improvements
> in the cipher restriction text being discussed here.
>
> Greg, with all respect, we're not here to make all participants happy --
> it is a completely normal end-state in the IETF for many to be unhappy.
> What we need to do is address technical issues that are brought to our
> attention.
>

C'mon mate! don't get hung up on a turn of phrase.         I have been
raising technical objections.   Removing the weak ciphers from the h2 ALPN
handshake addresses my technical objections... which I would make me
happy.

regards

---

From: "Jason T. Greene" <[email-masked]>
Date: Wed, 5 Nov 2014 18:56:52 -0500 (EST)

> On Nov 5, 2014, at 5:22 PM, Mark Nottingham <[email-masked]> wrote:
> 

Why do you keep saying this? I have reposted the frequently discussed problematic scenario numerous times in response to it.

I'm also not saying it can't be fixed. I even have a candidate PR for one option that came out of a discussion with Brian (who at least acknowledged the issue). Other options and proposals have been brought up (as recently as today). I have summarized them on multiple occasions.

-Jason

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 06 Nov 2014 00:00:12 +0000

--------
In message <CAH_y2NHyq=[email-masked]>

>connections using the existing http/1 protocol unchanged.

It's a really bad idea to try to cram a political agenda down peoples
throats using artifical and unenforceable tools.

Not only does it never actually work in the first place, it invariably
ruins the tools universality, portability and interoperability that
people hack in workarounds.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 6 Nov 2014 11:08:23 +1100

> On 6 Nov 2014, at 10:56 am, Jason T. Greene <[email-masked]> wrote:
> 
> 

See: <http://www.w3.org/mid/[email-masked]>

Cheers,

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 6 Nov 2014 11:11:01 +1100

On 6 November 2014 11:00, Poul-Henning Kamp <[email-masked]> wrote:

> --------
> In message <CAH_y2NHyq=
> [email-masked]>
> , Greg Wilkins writes:
>

I agree that the application layer protocol really should not be trying to
do this sort of thing.....   but I'm prepared to compromise on that IFF it
is done so in a technically robust way - so that political preference is
indistinguishable from technical choice.

Hence my stated position that if the handshake is made robust, then I will
make a best effort attempt to enforce cipher restrictions as recommended by
experts (even if those recommendations are political, as it is beyond my
expertise to evaluate if that is or is not the case).

cheers

---

From: Jason Greene <[email-masked]>
Date: Wed, 5 Nov 2014 19:39:09 -0600

> On Nov 5, 2014, at 6:08 PM, Mark Nottingham <[email-masked]> wrote:
> 
> 

Yes, but these statements are not exclusive. TLS + ALPN can theoretically be implemented in an interoperable way with mixed cipher suite requirements. However, in practice the H2 implementation is at the mercy of the TLS implementation it uses. Both parties can enforce their respective portion of 9.2.2 in total compliance, yet the end result will be a failed negotiation. 

Again the issue is that all the H2 stack is in a position to do, is to validate what the TLS stack already did, which is too late. If TLS and H2 have different knowledge, which again is likely since common practice is for a shared dynamically linked TLS library, then the H2 stack can find itself being overly restrictive because thats what the 9.2.2 text requires it to do. All it takes is for the TLS stack to support a newer cipher than the H2 stack recognizes.

All we need to do to fix it is to slightly soften the restrictions on the server side. so that the H2 stack has the option to accept the stronger cipher it doesn’t yet know about. This allows the TLS implementations of today to work, as well as the theoretical future implementers that 9.2.2 was created for.