Re: 9.2.2, Rough Consensus, and Working Code

Mark,

> On Nov 5, 2014, at 6:16 PM, Mark Nottingham <mnot@mnot.net> wrote:
> ...
>> ยท        Apple - http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0437.html
> 
> Apple is not currently implementing, as far as we know, so this is a statement of Michael's opinion, not implementation support. Additionally, Michael AFAIK does *not* represent Safari or Apple's HTTP stack; he's working on printing protocols (some of which use HTTP). Michael, please correct me if this is incorrect.

While my primary focus *is* on IPP (really the only print protocol being "worked on" and deployed in close to 500 million printers over the last 4 years), I am one of the few people at Apple that represents our interests in the IETF and other standards bodies so I naturally work internally with other groups inside Apple to make sure I fairly represent all of Apple's interests - in this case printing, web client, and web/content serving.

As you may have noticed, Apple is generally pretty secretive about the work it does leading up to a product release.  So the lack of an official statement from the Safari or WebKit teams is *not* informative - until a release is public, they generally cannot say anything about what Apple may or may not implement.

That said, I can (as an official representative of Apple) make statements about what is currently released or what is available as open source software.  And I believe I have been very clear on our (Apple's) position and dislike for the current 9.2.2 text:

1. Apple's SecureTransport API already supports the required cipher suite identified in the current draft's section 9.2.2.  So we are OK there.

2. Apple's SecureTransport API does not support a way to filter cipher suites based on capabilities (i.e. AEAD vs. CBC, etc.)  It does support (barring a current bug) specification of which cipher suites are enabled, and it is possible to implement a crude whitelist/blacklist approach to allow the widest possible set of cipher suites to be negotiated.  We could live with such a hack, but doing so interferes with HTTP/1 compatibility.

3. Since ALPN provides no way to restrict cipher suites based on negotiated protocol, a Client that tries to opportunistically use HTTP/2 will fail when connecting to many existing HTTP/1 servers.  This will force an additional connection attempt in a HTTP/1-only mode, impacting performance, power usage, etc. which is a deal-breaker for Apple.

These issues exist independent of whether I write a web browser, web/content server, or printer software for Apple - they are fundamental limitations of the APIs and protocol (TLS) we both must use.  And my current prototype implementation (running code) of the HTTP/2 drafts is unable to support the restrictions of 9.2.2 - not only can I not restrict the allowed cipher suites right now (thanks to a SecureTransport bug), but even if that API worked I would still run into problems when communicating with non-HTTP/2 implementations that don't implement the newer cipher suites (pretty common in the printing world, just like the web server world...)

My (Apple's) proposed alternative is to simply change the MUST and MUST NOT to SHOULD and SHOULD NOT: these are security best practices, not requirements to support interoperability.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Thursday, 6 November 2014 02:47:06 UTC