Re: [TLS] What counts as the same ClientHello?

2017-08-30 Thread Martin Thomson 
On 30 August 2017 at 22:57, Ilari Liusvaara  wrote:
> However, I identified a new category of extensions that I didn't notice
> before: Dependent on altered extensions. There are no such standardized
> extensions, but there is at least one proposal (in WG draft stage).

Is it possible that you could help us by sharing which one?

I would however suggest that this sort of dependency is already
possible.  We have a few places in our code that checks certain
conditions after extension processing because of dependencies between
extensions.  In particular, the pre_shared_key and early_data
extensions trigger a lot of cross checking because they change the
protocol in fairly fundamental ways.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] What counts as the same ClientHello?

2017-08-30 Thread Ilari Liusvaara 
On Tue, Aug 29, 2017 at 01:29:55PM -0500, Benjamin Kaduk wrote:
> Hi Ilari,
> 
> Thanks for the by-extension categorization/breakdown.

Sigh, I missed cached_info, because that does not appear in TLS 1.3
extension lists. It falls into "unsafe to alter because unknown
commitments" category.

However, I identified a new category of extensions that I didn't notice
before: Dependent on altered extensions. There are no such standardized
extensions, but there is at least one proposal (in WG draft stage).


The latter kind of extensions is incompatible with MUST be the same
except  requirement.




-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] CoAP, TLS and ALPN

2017-08-30 Thread Hannes Tschofenig 
Hi all,

I would need your deployment experience with the use of ALPN.

Here is the background: With the CoAP over TCP/TLS described in
https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-09
we are defining how to run CoAP over TCP and TLS. CoAP is a protocol
typically used in the Internet of Things environment, which was
initially designed to operate over UDP.

To ensure proper multiplexing we offer two approaches, namely one using
ALPN and the other one is to use a dedicated port.

The suggestion was made to only use ALPN (see
https://github.com/core-wg/coap-tcp-tls/issues/155).

This is may be fine since many stacks implement ALPN already (including
embedded TLS stacks).

What is the situation on the TLS loadbalancer/concentrator side? Do
these boxes also forward the ALPN information to the application server?
Has someone run into operational issues with ALPN on the server-side?

Ciao
Hannes

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS-in-TLS tunneling use cases (was: SNI Encryption)

2017-08-30 Thread Tony Arcieri 
On Fri, Aug 18, 2017 at 3:46 PM, Daniel Kahn Gillmor 
wrote:

> While i think i understand where you're coming from, Tony, i can't help
> but note that this use case is difficult to distinguish from a regime
> that:
>
>  (a) wants to forbid anonymous speech, and
>
>  (b) wants to censor "unapproved" information sources, and
>
>  (c) wants the capacity to undermine freedom of association.
>
> That makes me wary, and i hope that SNI Encryption is *not* conflated
> with these particular use cases.
>

TLS tunnels have a multitude of use cases, from SNI encryption to service
discovery-aware load balancers to Tor-like anonymity networks to
privacy-preserving payment channel networks to my much more mundane
"Squid-like authenticated egress proxy" problem.

I'm simply asking that if tunnels become the mechanism by which SNI
encryption is ultimately implemented, that all of the potential use cases
of tunnels are considered, rather than observing the problem through the
microcosm that is "SNI Encryption".

Note that I'm proposing absolutely nothing new, just asking that the
tunneling problem be considered from more angles than one. If TLS contains
(mis)features which forbid anonymous speech or censor unapproved
information sources, I'm afraid that the ship has already sailed there. But
perhaps, well-implemented TLS tunnels could ultimately help route around
censorship.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls