Re: HTTP/2.0 draft, NPN/ALPN, and TLS

Late to the party, but Java users can use a reasonably small and
straightforward jetty library for NPN support.   This hasn't been a
complexity problem (in my experience) except that it needs to be in
the boot class path: http://wiki.eclipse.org/Jetty/Feature/NPN

hope this helps,
-A

On Wed, Dec 11, 2013 at 12:49 PM, Chris Burdess <dog@gnu.org> wrote:
> Hi Yoav,
>
> On 11/12/13 12:08, Yoav Nir wrote:
>> I'm an IPsec guy. I've been working on an IPsec implementation for more than a decade, and have been co-author or editor of 7 published RFCs related to IPsec. I don't believe TLS should be deprecated in favor of IPsec for securing the web.  Going over your list of pros and cons:
>>
>>> Pro transport layer:
>>> - all application layer protocols benefit without having to design in
>>> anything special for them (transparency)
>> Transparency works both ways. IPsec has no APIs, partially because it is part of the transport layer, but mostly because it isn't necessarily happening on the same box as the endpoint. Without APIs, the client cannot communicate the server identity to the security layer, so IKE has no way of validating if the credential is valid for what the client is trying to do.  So if the user types "www.example.com", but the certificate has "CN=hackerzRus.net". How is the IKE implementation to know. Similarly, how can the browser know that IPsec was successful and what algorithms are used?
>>> - can secure UDP as well as TCP connections
>>> - IPsec can secure more of the packet envelope than TLS or any other
>>> application level system
>>> - doesn't require PKI (which can be a vulnerable point)
>> Not nearly as vulnerable as providing pair-wise shared keys to hosts or gateways. TLS also supports PSK ciphersuites. The reason PKI is deployed rather than PSK, is that having a PSK for each host you might visit is not practical. So if you want IPsec to scale to what TLS does today, you'll need PKI there as well.
>>>
>>> Pro application layer:
>>> - TLS is better known
>> IPsec and TLS are roughly the same age, and both have seen a lot of deployment. It's true that IPsec has not been used by consumers.
>>> - TLS supports NAT traversal at the protocol layer (maybe not really an
>>> issue with IPv6)
>> So does IPsec.
>>> - ISPs might charge more to support IPsec since it is seen as a B2B feature
>> You can do IPsec on your own CPE or on your own machines, same as TLS.
>>> - can do user-level (as opposed to endpoint-level) authentication,
>>> although typically this is done within the particular application
>>> protocol as well
>> So can IKE, at least since v2 (2006).
>>> Perhaps there are other salient issues not listed here. On balance of
>>> the above, to me it looks like the transport layer is a head ahead.
>>
>> IPsec (or more correctly - IKE) requires mutual authentication. This means distributing credentials to all users. TLS's server authentication is what makes it deploy-able in a way that IPsec has never been.
>
> Thanks very much for this, plenty of stuff to think about.
>
>

Received on Friday, 10 January 2014 01:14:00 UTC