Re: [TLS] Network Tokens I-D and TLS / ESNI

[Yiannis Yiakoumis]

(cross-posting to network-tokens@ as this is the first related topic - 
apologies for any duplicates)

Hi Erik,

Thanks for the comments. That's a good point, and wanted to clarify the 
reasoning around binding fields in general, as well as  binding tokens to IP 
addresses specifically.

Unlike access and security tokens, network tokens are not protected by a secure 
TLS connection and can be read by any intermediary node. Therefore, they are 
open to replay attacks, and unless  used in a fully trusted environment, one 
should take measures against such attacks. There are two main approaches here:

* Limit a token's lifetime, to make replay attacks hard. The extreme here is to 
make tokens single use (e.g., through a nonce), and reject tokens with 
previously seen nonces (within a time window).

* Bind the token to a field that limits the scope it can be used (e.g., a user, 
a device, a set of exit gateways, etc). The network should be able to 
separately verify that the token is used within this scope. A binding field can 
be in an IP address, an IMSI, or any other field the network operator may use 
to limit the scope of a token.

Note that the binding value matters only at the point of enforcement ( the 
place where the network checks the scope). It doesn't play any role on the 
client, the server, or other network nodes.  Moreover, when tokens are 
encrypted, the binding field itself is not visible to anyone other than the 
network that issued the token, which should cover privacy concerns.

Two use cases where binding tokens to IP addresses should be fine are i) when 
users (a home or a mobile subscriber) are assigned a static IP address ( or a 
DHCP lease that lasts beyond a token's expiration time), and ii) for public IP 
addresses. Consider the following scenario:

home device → home NAT → operator network (static IP addresses) → operator NAT 
→ Internet .

Despite multiple NATs, the operator can bind the token to the IP address it 
assigns to the modem and not worry about the downstream and upstream NAT.

As you mentioned, there will be cases where IP binding won't work, either 
because the endpoint that gets the token doesn't have an assigned IP address, 
because the enforcement point is behind a NAT, or because of heavy use of 
proxies etc. In such cases one could bind tokens to a different field, or use 
short-lived tokens and/or nonces to prevent replay attacks. The overall benefit 
of binding tokens to certain fields is that they can have a longer lifetime and 
require less state in the network.

Does this address your concern? Also, any ideas/references on how common it is 
to have static/long-leased IP addresses in different scenarios (e.g., 
residential networks and mobile networks)?

Thanks,

Yiannis

On Thu, Jun 25, 2020 at 4:29 PM, Erik Nygren < erik+i...@nygren.org > wrote:

> 
> One quick comment is that binding tokens to IP addresses is strongly
> counter-recommended.
> 
> It doesn't survive NATs or proxies, mobility, and it is especially
> problematic in IPv6+IPv4 dual-stack environments.
> 
> (Even in IPv6-only, privacy addressing causes problems here.)  Even if you
> have a way to convert tokens over
> 
> for your set of IP addresses (eg, to deal with dual-stack) that still may
> not help enough with NAT environments.
> 
> 
> 
> Erik
> 
> 
> 
> 
> On Thu, Jun 25, 2020 at 4:29 PM Yiannis Yiakoumis < yiannis@ selfienetworks.
> com ( yian...@selfienetworks.com ) > wrote:
> 
> 
>> Hi all,
>> 
>> 
>> 
>> I wanted to briefly introduce network tokens ( https://networktokens.org )
>> into this list, how they relate with TLS and ESNI, and kindly ask anyone
>> that is interested to share feedback and join the discussion.
>> 
>> 
>> 
>> Network tokens is a method for endpoints to explicitly and securely
>> coordinate with networks about how their traffic is treated. They are
>> inserted by endpoints in existing protocols, interpreted by trusted
>> networks, and may be signed or encrypted to meet security and privacy
>> requirements. Network tokens provide a means for network operators to
>> expose datapath services (such as a zero-rating service, a user-driven QoS
>> service, or a firewall whitelist), and for end users and application
>> providers to access such services. Network tokens are inspired and derived
>> by existing security tokens (like JWT and CWT), borrowing several of their
>> security and privacy properties, and adjusting them for use in a
>> networking context.
>> 
>> 
>> 
>> There are two ways that network tokens relate with TLS:
>> 
>> * They can support ESNI adoption: in a world where ESNI is widely adopted,
>> network tokens can enable use cases where endpoint-network coordination is
>> required, without having to go back to plaintext SNI that everyone can
>> read.
>> 
>> * Network tokens are embedded as TLS handshake extensions (among others)..
>> 
>> We are shooting for a BoF in November, and are very much interested into
>> feedback around the concept, use cases, what 

Re: [TLS] something something certificate --- boiling a small lake

[Nico Williams]

BTW, thanks for the something-something-certificate work.  Looking at
the I-D, draft-bdc-something-something-certificate-04, I see there's no
way to send the certificate chain on.  I understand the motivation
(compression), but it really would be best to send on the full chain
sent by the client.  More on this below:

On Fri, Jun 19, 2020 at 12:50:17PM -0400, Michael Richardson wrote:
> Thus, a single header isn't enough, although there could be some degeneration
> that results in a single header.  We need a few variables to update.
> 
> I think we have a choice between:

HTTP/2 and, I imagine, /3, does header compression of the right sort
here.

If the backend is HTTP/1, then... that sucks, but maybe this is a good
way to encourage migration to /2 or /3.  That said, I think we can
compress in the /1 case by first sending the certificate (and chain,
please) and in subsequent requests in the same connection sending only a
hash of the certificate.  This would force a /1 backend to keep the kind
of state that a /2 backend would for header compression.

> 1) sending the state (possibly a few kb) on every transaction, which keeps
>the protocol stateless.  We could explore ways to encode it: CDDL+CBOR
>seems like a good thing.  TLS structures are another obvious choice, but
>that's a detail.

There's no need.  HTTP/2 already does header compression.

> 2) assuming that state will be maintained by both ends, and simply updating
>the state appropriately.   When it comes to this, I think of the
>HTTP PATCH methods, but I'm not sure I mean this literally.

Can TLS let a client authenticate multiple times?

> Alternately, the TLS front-end could maintain a RESTful interface on a
> per-connection basis that the back-end could interrogate.  The header
> would just provide the right reference to that.  The RESTful interface
> could even be pushed/updated into some other CPU on the TLS terminator.

Yes, this would also work.  In this case Client-Cert: would carry just a
URI.  This is nice because the backend can validate that the origin of
that URL is one it trusts.

Nico
-- 

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

Re: [TLS] Network Tokens I-D and TLS / ESNI

[Erik Nygren]

One quick comment is that binding tokens to IP addresses is strongly
counter-recommended.
It doesn't survive NATs or proxies, mobility, and it is especially
problematic in IPv6+IPv4 dual-stack environments.
(Even in IPv6-only, privacy addressing causes problems here.)  Even if you
have a way to convert tokens over
for your set of IP addresses (eg, to deal with dual-stack) that still may
not help enough with NAT environments.

  Erik


On Thu, Jun 25, 2020 at 4:29 PM Yiannis Yiakoumis <
yian...@selfienetworks.com> wrote:

> Hi all,
>
> I wanted to briefly introduce network tokens 
> into this list, how they relate with TLS and ESNI, and kindly ask anyone
> that is interested to share feedback and join the discussion.
>
> Network tokens is a method for endpoints to explicitly and securely
> coordinate with networks about how their traffic is treated. They are
> inserted by endpoints in existing protocols, interpreted by trusted
> networks, and may be signed or encrypted to meet security and privacy
> requirements. Network tokens provide a means for network operators to
> expose datapath services (such as a zero-rating service, a user-driven QoS
> service, or a firewall whitelist), and for end users and application
> providers to access such services. Network tokens are inspired and derived
> by existing security tokens (like JWT and CWT), borrowing several of their
> security and privacy properties, and adjusting them for use in a networking
> context.
>
> There are two ways that network tokens relate with TLS:
>
>1. They can support ESNI adoption: in a world where ESNI is widely
>adopted, network tokens can enable use cases where endpoint-network
>coordination is required, without having to go back to plaintext SNI that
>everyone can read.
>2. Network tokens are embedded as TLS handshake extensions (among
>others).
>
> We are shooting for a BoF in November, and are very much interested into
> feedback around the concept, use cases, what we need to do to make network
> tokens adopted as a TLS handshake extension, and folks that are interested
> to get involved in the effort!
>
> Links to an IETF I-D, a mailing list, and initial implementation are
> available at https://networktokens.org  .
>
> Best,
> Yiannis
>
> =
> Yiannis Yiakoumis
> Co-Founder & CEO
> https://selfienetworks.com | +1-650-644-7857
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] something something certificate --- boiling a small lake

[Michael Richardson]

Brian Campbell  wrote:
> My aim with something-something-
> 

> certificate
> 

> is/was to address a narrow but existing need by documenting current
> practice while introducing enough commonality to the header name and its
> content/encoding so as to facilitate relatively simple interoperability
> between independently developed systems. I see where you are going with
> this boiling of a small lake but it's well beyond the scope of the kind of
> solution I'd envisioned or think would be practically deployed and useful
> in any meaningful numbers.

I agree with you.

I think it's useful to think about what the next step of complexity would be
in order to understand the ROI for this simiplicity.

I think that a key line is figuring out how/if the certificate chain will be
provided with the simplest design.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] something something certificate --- boiling a small lake

[Brian Campbell]

My aim with something-something-

certificate

is/was to address a narrow but existing need by documenting current
practice while introducing enough commonality to the header name and its
content/encoding so as to facilitate relatively simple interoperability
between independently developed systems. I see where you are going with
this boiling of a small lake but it's well beyond the scope of the kind of
solution I'd envisioned or think would be practically deployed and useful
in any meaningful numbers.

On Fri, Jun 19, 2020 at 10:50 AM Michael Richardson 
wrote:

>
> Brian,
> {I have been on the httpbis list, but I'm not right now, and I know that
> w3 and IETF do not share their whitelists, so this might not work}
>
> I was thinking about something-something-certificate yesterday while
> cleaning/swimming
> my pool.  (A long thankless task, as the pool is not heated, we've been
> getting very a-seasonal *snow*, and nobody in my family but me will swim
> in it
> until it's "perfect".  Also we have many many trees, which we won't cut
> down.
> You can see how my mind might wander)
>
> [This discussion would be better done with beer and napkins.]
>
> So I am thinking that we need to create a "digital twin" in the back-end
> server for the front-end TLS state machine.  It needs to reflect the
> current
> state at a level of detail appropriate for the application.
>
> Thus, a single header isn't enough, although there could be some
> degeneration
> that results in a single header.  We need a few variables to update.
>
> I think we have a choice between:
>
> 1) sending the state (possibly a few kb) on every transaction, which keeps
>the protocol stateless.  We could explore ways to encode it: CDDL+CBOR
>seems like a good thing.  TLS structures are another obvious choice, but
>that's a detail.
>
> 2) assuming that state will be maintained by both ends, and simply updating
>the state appropriately.   When it comes to this, I think of the
>HTTP PATCH methods, but I'm not sure I mean this literally.
>
> It's the model of having a few objects per-connection that the TLS
> front-end
> might update on the backend, and making the management of the TLS
> connections explicit.
>
> Alternately, the TLS front-end could maintain a RESTful interface on a
> per-connection basis that the back-end could interrogate.  The header
> would just provide the right reference to that.  The RESTful interface
> could even be pushed/updated into some other CPU on the TLS terminator.
>
> This is cleaner, but this has read-latency round trip issues, while pushing
> the state out on each HTTP request (or uwsgi, fastcgi, ...) seems a lot
> more
> pipelined.  Or MQTT :-)
>
> To this, I think we'd have to look at the RFC8446 Appendix A.2 state
> machine
> and figure out how to express this.   I don't really see re-auth in that
> diagram.  Maybe I'm overthinking here, but given the opportunities in TLS
> 1.2 and 1.3 for newer states, and the review from TLS experts on the
> header,
> this might be cleaner and less of a hack to get the additional things in.
>
> This data model mechanism also better accomodates the split between those
> who
> need the entire certificate chain (w/ and w/o trust anchor used), and those
> that just care about the EE involved.
>
> ---
>
> I don't know, in a HTTP/3(QUIC) world, what the TLS front-end/backend
> connection looks like.  I haven't entered such a world personally.
>
> TLS front-end systems *are* collecting/storing state on a per-client
> connection basis, whether the transport is QUIC or not.  I don't think it
> scales well to try to spread that state across load balancers, you want to
> split the traffic before the TLS terminators in order to horizontally scale
> them.
>
> A thought that I have is that with a move to HTTP/3, that the need for
> something-something-certificate declines.
> A model that I could see in such a situation is that since the bulk of the
> transport is via QUIC, it could be that it makes less sense to have TLS
> hardware terminators; by careful use of port numbers to demux upon, and/or
> IPv6 addresses, it might be easier to load balance directly to application
> servers, and just horizontally scale them wider.
>
> The hardware TLS offload box then is only important for adapting HTTP 1
> and HTTP/2 connections to HTTP/3.
>
> --
> ]   Never tell me the odds! | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works|IoT
> architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on
> rails[
>
>
>
>
>
>
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). 

[TLS] Network Tokens I-D and TLS / ESNI

[Yiannis Yiakoumis]

Hi all,

I wanted to briefly introduce network tokens ( https://networktokens.org ) into 
this list, how they relate with TLS and ESNI, and kindly ask anyone that is 
interested to share feedback and join the discussion.

Network tokens is a method for endpoints to explicitly and securely coordinate 
with networks about how their traffic is treated. They are inserted by 
endpoints in existing protocols, interpreted by trusted networks, and may be 
signed or encrypted to meet security and privacy requirements. Network tokens 
provide a means for network operators to expose datapath services (such as a 
zero-rating service, a user-driven QoS service, or a firewall whitelist), and 
for end users and application providers to access such services. Network tokens 
are inspired and derived by existing security tokens (like JWT and CWT), 
borrowing several of their security and privacy properties, and adjusting them 
for use in a networking context.

There are two ways that network tokens relate with TLS:

* They can support ESNI adoption: in a world where ESNI is widely adopted, 
network tokens can enable use cases where endpoint-network coordination is 
required, without having to go back to plaintext SNI that everyone can read..

* Network tokens are embedded as TLS handshake extensions (among others).

We are shooting for a BoF in November, and are very much interested into 
feedback around the concept, use cases, what we need to do to make network 
tokens adopted as a TLS handshake extension, and folks that are interested to 
get involved in the effort!

Links to an IETF I-D, a mailing list, and initial implementation are available 
at https://networktokens.org ( https://networktokens.org/ ).

Best,

Yiannis

=
Yiannis Yiakoumis
Co-Founder & CEO
https://selfienetworks.com | +1-650-644-7857___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Moving SHA-1 signature schemes to not recommended in draft-ietf-tls-md5-sha1-deprecate

[Salz, Rich]

  *   I submitted a PR [1] for draft-ietf-tls-md5-sha1-deprecate to move the 
recommended IANA registry entries for  rsa_pkcs1_sha1 and ecdsa_sha1 in the 
Signature Scheme registry from Y to N.   This change can be incorporated with 
any updates from the AD review.

Yes yes yes.

Or no no no?

I think it is remove the “Y” and leave blank, right?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Moving SHA-1 signature schemes to not recommended in draft-ietf-tls-md5-sha1-deprecate

[Kathleen Moriarty]

Thank you, Joe.

Sent from my mobile device

> On Jun 25, 2020, at 1:10 AM, Joseph Salowey  wrote:
> 
> 
> Hi All,
> 
> I submitted a PR [1] for draft-ietf-tls-md5-sha1-deprecate to move the 
> recommended IANA registry entries for  rsa_pkcs1_sha1 and ecdsa_sha1 in the 
> Signature Scheme registry from Y to N.   This change can be incorporated with 
> any updates from the AD review.  
> 
> Please post to this thread if you have any concerns with this change.  
> 
> Cheers,
> 
> Joe
> 
> [1] https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/7
> 
> 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls