Re: [TLS] draft-ietf-tls-esni feedback

[Patrick McManus]

wildcards are real in both dns and http services.. (also the dns entries
might be invisible to the http provider thanks to cname indirections..
though obviously service names are not.)

On Mon, Oct 21, 2019 at 4:56 PM Eric Rescorla  wrote:

>
>
> On Mon, Oct 21, 2019 at 1:46 PM Stephen Farrell 
> wrote:
>
>>
>> Hiya,
>>
>> On 21/10/2019 21:02, Eric Rescorla wrote:
>> >> Sure, but the point holds though. If ESNIKeys are changed every
>> >> N seconds, and any new certificate is loaded during that time,
>> >> then the server operator can't tell the lengths that the CAs
>> >> might produce in future. So with the current design 260-always is
>> >> the only thing a server-operator (or really an ESNIKeys generator
>> >> who may be a slightly different entity) can rely on in general.
>> >>
>> > I don't believe that this claim is correct in general. Remember that
>> these
>> > records are stored in the DNS under the name that becomes the SNI, so,
>> > absent wildcards, ths eet of names is in fact known, regardless of what
>> > happens to be in the certificate.
>>
>> Depends which "in general" is more general I guess.
>>
>> Wildcards do exist in the DNS, though TBH I'm not really
>> familiar with how they're implemented in authoritatives.
>>
>> But even ignoring those, deployment models where the
>> ESNIKeys are generated by the TLS server operator, but
>> DNS records are published by a different entity (say the
>> owner of the name or registrar) ought not be precluded
>> I think. Supporting such a model I think more or less
>> requires setting padding_length to 260 or else risking
>> a failure nobody will notice (if browsers fall back to
>> cleartext SNI) or know how to diagnose if they do.
>>
>> And even in the case of a monolithic service that does it
>> all for every name, I think it'd still likely pick 260
>> in order to avoid having to exercise/write the code to
>> detect and react to a need to increase the padding_length.
>>
>
> Fortunately, we have a number of such operators on this list. Alessandro?
> McManus? Nygren, What say you?
>
> -Ekr
>
>
>
> ("Holy crap - you mean I need to re-publish everyone's
>> ESNIKeys just because this bozo has a really long name?
>> Who made that up?")
>>
>> I really can't see what'd motivate anyone to publish
>> ESNIKeys with a padding_length < 260 tbh (well, other
>> than not having thought it through;-). Anything <260
>> just seems to be asking for later problems.
>>
>> S.
>>
>>
>> ___
> 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] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.txt)

[Patrick McManus]

some thoughts after catching up on this thread:

* cdn -> origin ime generally resolves via DNS for the same reason you want
anything else to resolve via DNS: a level of indirection is handy for
management. Occasionally it bypasses DNS for the same reasons you want
anything to bypass DNS: a level of indirection adds tail risk and overhead.

* origins sometimes have reasonable potential for ESNI anonymity sets
themselves .. cloud hosting environments would be good examples. this
should be encouraged.

* it seems pretty unusual that a CDN and Origin would share keys.. the
major use case of the CDN key is to cover an anonymity set that is a
significant number of distinct customers.

* using one v6 per origin (when you've got multiple origins available)
isn't a great pattern imo - not only does it make ESNI rather useless (with
an anonymity set of 1). but it fails to leverage the handshake and
congestion control amortizations across origins that h2/h3 can and will be
able to give you. We've built all the necessary http authority muxxing
stuff into higher levels with SNI and HTTP at this point, there's no need
to force it back into correlations withe the transport addresses.

* a few folks do like to authenticate the cdn to the origin with client
certs. That's nifty - but overall its pretty unpopular for the same reasons
managing distributed keys are always unpopular - its a hassle to manage in
the wild certs in a low risk way. DNS (scoped to ESNI - not as
authentication replacement) is a bit nicer in this respect because you
don't need to manage all the clients (multi cdn), but rather just a origin
property..

tldr; imo none of this works if the origin does not have a decent anonymity
set potential. If it does, just reuse esni for that hop rather than minting
something new.

On Sat, Oct 12, 2019 at 3:19 AM Rob Sayre  wrote:

> On Sat, Oct 12, 2019 at 12:11 AM Salz, Rich  wrote:
>
>>
>>
>>- How does a request of the form "username.example.com
>>
>> "
>>get through a CDN to an Origin while leaving the SNI encrypted on the 
>> wire?
>>
>>
>>
>> The CDN needs to see the decrypted SNI.
>>
>
> Agreed.
>
>
>
>> If the CDN and origin share the ESNI keys, the CDN can just pass the
>> original ESNI value along.  If the CDN and origin do not share ESNI keys,
>> then the CDN will have to re-encrypt.  If that is an issue you haven’t
>> explained why or I missed.
>>
>
> It's definitely one approach. I am not sure which keys should be used for
> the CDN -> Origin traffic, though. I suggested sending the SNI with the
> client cert, because it seemed simpler if client certs are already being
> used (an option I recommend for CDN -> Origin traffic).
>
> EKR's Host header suggestion may also be viable, but my goal is actually
> to make some TLS-level decisions about traffic based on the SNI. EKR's
> proposal also assumes some level of Host header / SNI divergence is allowed
> by the Origin host. These policies are not clear to me. For example, I'm
> not sure what rules a Cloudflare to Google Cloud Platform link would need
> to follow (this is a common enough setup that they have an egress
> agreement).
>
>
>>
>>- I also disagree with the argument that ESNI is pointless when “IPv6
>>uniquely identifies the origin”.
>>
>>
>>
>> Can you explain why?
>>
>
> I agree that a unique IPv6 address would expose the fact that a CDN is
> communicating with an Origin, but I also think subdomain data could be used
> for tracking, and so the SNI should still be encrypted.
>
> thanks,
> Rob
> ___
> 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] I-D Action: draft-ietf-tls-certificate-compression-05.txt

[Patrick McManus]

also congestion control interaction will typically cause more bytes to
incur extra round trips - especially early in the connection.

On Fri, Apr 5, 2019 at 1:04 PM John Mattsson 
wrote:

> If fragmentation is used on some layer, lowering the number of bytes can
> definitely reduce the number of round-trips. This should probably be
> explained a bit more.
>
> If used in any of the TLS based EAP methods, the use of compression may
> even be needed to make the handshake complete at all as many access points
> drop EAP connections after 40-50 packets.
> https://tools.ietf.org/html/draft-ms-emu-eaptlscert-02
>
> John
>
> -Original Message-
> From: TLS  on behalf of Jeremy Harris <
> j...@wizmail.org>
> Date: Friday, 5 April 2019 at 12:35
> To: "TLS@ietf.org" 
> Subject: Re: [TLS] I-D Action:
> draft-ietf-tls-certificate-compression-05.txt
>
> On 05/04/2019 11:03, internet-dra...@ietf.org wrote:
> >In TLS handshakes, certificate chains often take up the majority
> of
> >the bytes transmitted.
> >
> >This document describes how certificate chains can be compressed
> to
> >reduce the amount of data transmitted and avoid some round trips..
>
> Reducing the number of bytes (and possibly packets) is a good thing,
> but how does this reduce roundtrips?
> --
> Thanks,
>   Jeremy
>
> ___
> 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Multi-CDN and ESNI

[Patrick McManus]

Here's a PR on one way to skin this cat.
https://github.com/ekr/draft-rescorla-tls-esni/pull/104/files


I hope to work this into a PR.. my first attempt wasn't very readable, but
>>> I'll try again tomorrow.
>>>
>>> -P
>>>
>>>
>>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Multi-CDN and ESNI

[Patrick McManus]

Hey Nick,

On Tue, Oct 23, 2018 at 8:45 PM Nick Sullivan  wrote:

> This line of commentary describes one instance of a more general situation
> that is unrelated to the multi-provider case: what happens when you connect
> to a server that doesn't know the ESNI key you're using? This can even
> happen on a single provider due to DNS caching issues, for example.
>
> The two cases are related and there are two features missing from the
> current ESNI draft that might be useful to mitigate these scenarios:
> 1) Allow multiple simultaneous ESNI keys. The DNS provider could present
> ESNI keys from multiple HTTPS providers (perhaps as different DNS records)
> and the client could choose to send multiple entries in its ESNI extension,
> each encrypted to a different key. This would likely solve the multi-CDN
> scenario at the cost of some clienthello bloat.
>

I would like to see this feature, but I don't think it addresses this
problem..

consider load balancer L, CDN A and CDN B. In a world in which L is aware
of A and B (duh) but not ESNI, and A wants to deploy ESNI but B has not yet
done so. You have the likely situation where at some point you've got an
address record for B but a key for only A and you run into hard failure.

even if A and B both want to do ESNI they need to be aware of each other
and coordinate key rotations somehow to synthesize records - or else you
end up spf like includes (please no). Requiring cross provider coordination
seems like assuming knowledge the providers don't reliably have and
probably could't reliably maintain. You could boot the problem to cusomter
configuration but.. 1] esni is so much better as automatic infrastructure
so CDNs can just turn it on and 2] origin names may not wish to disclose
all of their providers to each other.


> 2) Allow in-band distribution of ESNI keys if the server does not know the
> ESNI key sent by the client. The server could prove ownership over a
> specific long-term "fallback key" advertised in the ESNI record (or maybe a
> fallback domain) when sent a TLS connection for which no ESNI extensions
> can be decrypted, then in-band send back a new ESNI public key that the
> client could use to send the SNI in a follow-up message. It's also possible
> that handshake encryption alone is enough. This might require some TLS
> message gymnastics, but doesn't seem impossible. I've heard more well-baked
> versions of this idea batted around by others. (note that this incurs at
> least one additional round-trip, but considering that a server not having
> the active ESNI key should be rare, it is likely ok)
>
>
My concern would be a legacy TLS stack. The problematic case is when the
lookup for ESNI yields a key, but the host at the end of the A record has
never heard of it (or perhaps even heard of TLS 1.3). These are different
orgs, so its totally possible and inevitable in the sense that there are no
flag days. How does that work with this scheme?

This is tricky because the failure mode is so painful. provider A can
essentially break provider B by deploying ESNI - externalizing some of its
own risk. A and B don't have a super reliable way of knowing about each
other to even make sane risk judgments.


> To comment specifically on your proposals, Patrick, I don't see #3 as a
> workable solution since many authoritative DNS providers hide the fact that
> a CNAME is used when returning A/ records. This obfuscates the
> indirection that would be necessary to do what you propose, and it does it
> for a good reason (saving round trips on DNS resolution). Furthermore,
> intermediate values of CNAME chains seems like a brittle mechanism to rely
> on for policy enforcement.
>
>
Roughly, this is inspired by what krb does with canonical names in
practice. And it makes logical sense - the key applies to the canonical
name, not the alias. That said - this is a pain point I agree.

I'm glad you brought up flattening - I know of a handful of orgs that do
that. But do any of them do it across administrative domains or just as
optimizations to their own 'zone files'?  I understood it to be the latter,
and I don't think that would really be a problem here as long as it was
consistent across rrtypes.

another thought, Kazuho had mentioned reverse lookups at some point.
Definitely too painful for the normal case, but perhaps plausible as a
fallback? Doing a reverse lookup of the address record to obtain the
canonical key for the address (and absence of a reverse-lookup key means
that host doesn't really do ESNI so proceed the old way). it would be
backwards compatible but I worry both that its too fragile itself (IP
addressing can be pretty disjoint from http operations) and perhaps too
much of a time penalty to bear given the 'externalization' problem. But
let&#

Re: [TLS] Multi-CDN and ESNI

[Patrick McManus]

Definitely agree this is something that needs to be addressed..

As Mike notes, the fundamental issue is that there are 2 pieces of
information that are statefully related (the key and address) but obtained
statelessly from each other and can therefore come from un-coordinated
sources. 2 CDNs are commonly un-coordinated sources.. but I've seen this
with other kinds of cloud providers too. All of which should be target
audiences of ESNI (because they terminate a variety of hostnames on a
smaller number of addresses).

fwiw there is a muddled github issue open on this in the old
individual-draft repo:
https://github.com/ekr/draft-rescorla-tls-esni/issues/35 .. which I'll
re-open when the tls-wg repo starts being used for this draft.

I see three solution spaces.

1] As Rich suggests, you can coordinate the uncoordinated sources to have
one keying record to rule them all. I suspect that's actually not good for
anonymity unless it somehow had a normalized global set .. and given the
one way nature of a CNAME pointer, I feel like this would be really fragile..

2] you could scope the keys to only be valid for certain addresses by
putting the valid addresses in the key record. This wouldn't help you do
ESNI when they didn't match, but at least you could avoid hard failure. (or
you could ignore the addressing record but that might be a bridge too far?)

3] My preferred approach, you could scope the keys to the same intermediate
name. So if www.example.com -> cname www.cdn-a.com -> ESNI record
www.cdn-a.com we could make a rule that the ESNI record would only apply to
address records with a final intermediate of www.cdn-a.com. (I'm presuming
we'll shift from TXT to ESNI RRTYPE without a prefix, but I don't think it
matters for this..).. when there is a mismatch you could use the addressing
intermediate as a place to try a new ESNI query from.. That's a perf
penalty, but its only paid in the hopefully rare case where these things
are unsyncd.

#3 is admittedly a bit non traditional, but I spent a bit of time looking
at the features of DNS APIs that already have the necessary surface to make
a query for a new RRTYPE... and the cname intermediates are indeed
generally available.. its true of getdns, res_query, the IOS and MacOS
interfaces, DnsQuery* on windows, and of course the custom dns stacks in
cronet/android and firefox/doh could do it.

I hope to work this into a PR.. my first attempt wasn't very readable, but
I'll try again tomorrow.

-P






On Tue, Oct 23, 2018 at 1:59 PM Salz, Rich  wrote:

> I think perhaps we need to take a step back and explain something that
> might not be well-known outside the community of CDN’s and their
> customers.  It is not uncommon for (admittedly larger) origins to use
> multiple CDN’s, and to switch among them. This can be done on a per-request
> basis, because of things like contractual arrangements that make one
> preferable, or it can be done globally but switched in a matter of seconds
> because of a short TTL on the www.example.com entry.
>
>
>
> The issues that Mike discusses impact on this, somewhat negatively.
>
>
>
> A quick hack thought is to allow multiple entries in the TXT record,
> forcing a wee bit more work on the CDN.
>
>
> ___
> 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] WG adoption call: draft-rescorla-tls-esni

[Patrick McManus]

I support adoption of this document and I will review and provide
contributions to it as it evolves in the WG - its important work.

-Patrick


On Tue, Jul 24, 2018 at 10:16 PM, Joseph Salowey  wrote:

>
> The sense of the TLS@IETF102 room was the the WG should adopt
> https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/ as a WG item.
> But, we need to confirm this on list.  If you would like for this draft to
> become a WG document and you are willing to review it as it moves through
> the process, then please let the list know by 2359UTC 20180807.  If you are
> opposed to this being a WG document, please say so (and say why).
>
> Note that the draft has been marked as a "Candidate for WG Adoption” in
> the datatracker.
>
>
>
> ___
> 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] DNS-based Encrypted SNI

[Patrick McManus]

On Tue, Jul 3, 2018 at 11:20 AM, Ben Schwartz <
bemasc=40google@dmarc.ietf.org> wrote:

>
> One concern I've heard many times is that we can't add non-A/ queries
> to a browser's critical path because there are middleboxes and buggy
> recursives that will just drop them, leading to a DNS timeout delay on
> every new socket.  However, for encrypted SNI I think we can ignore this by
> focusing on clients with DPRIVE or DOH enabled, which should avoid these
> kinds of problems.
>
>
yes, and of course encrypting sni is a lot more valuable when the dns query
is also encrypted.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt

[Patrick McManus]

Some feedback, in no particular order:

* have a hard think about handshake/termination loads. istm this scheme
devolves pretty quickly to a termination per object HTTP/1.0 style so
you'll be fairly quickly looking to do some kind of multiplexing and reuse
on top of it for the same reasons HTTP evolved that way. as an alternative
- HTTP/2 inside of a CONNECT tunnel (e.g. HTTP/2 on one stream of an HTTP/2
session) is something browsers already do and may be a carrot worth chasing
if you want to give up on the dream of just deploying js into the current
environment.

* read the current websockets over http/2 thread on httpbis with an eye to
the discussion about CONNECT vs (a hypothetical) TUNNEL. There are some
similarities to the discussion here.

* also take a look at https://tools.ietf.org/html/dr
aft-nottingham-bcp56bis-00 (to be adopted imminently by httpbis) - for
general foo over http guidance. In particular note that requiring
particular behavior from http response codes beyond what is already defined
(adding semantics) is called out as a practice to be avoided.

* I don't really understand how s->c data flows other than as a reply to
client data. hanging get? polling? push?

* istm you are using http as a reliable messaging layer. That 'reliable'
part might get you into trouble.. various events can cause an http
transaction to fail and I'm not sure how you recover that state without
record number etc.. Is there room for a off path malicious actor to disrupt
your stream state (e.g. send a get with your session ID to get a few bytes
of ciphertext - which means you never get them?)? Perhaps this works better
as a more generic "datagram over http" framework which you can obviously
run some form of reliable stream and tls (and http) on top of. why is a tls
record the best scope here?



On Tue, Oct 31, 2017 at 10:26 PM, Stephen Farrell  wrote:

>
> Hi Owen,
>
> On 31/10/17 21:03, Owen Friel (ofriel) wrote:
> >> Interesting. One bit puzzles me: wouldn't the new content-type
> >> give the game away and cause middleboxes to block this?
> >>
> >> S.
> >>
> > [ofriel] The intention isn’t to try and obscure the fact that there
> > is an ATLS session. Even if that new content-type was not defined,
> > it would be easy to write a simple pattern match script on the
> > middlebox to identity the JSON body and leading base64 bytes of the
> > TLS records in the body.
>
> So that leaves me puzzled still, sorry.
>
> I can't think of a situation with a middlebox that isn't ok
> with the client doing proper TLS but is ok with ATLS.
>
> Can you give an example of such a situation?
>
> In case it helps, I can imagine that some middleboxes won't
> (yet) know about this and will let it through for a while,
> but that seems fairly brittle. So, I'd have thought it may
> be worthwhile trying to hide what's what here if you want
> it to be robust against an antagonistic middlebox or censor.
> But maybe you guys analysed that already and figured it'd
> not work. (Which brings me back to "puzzled":-)
>
> Cheers,
> S.
>
>
> >
> >
>
>
> ___
> 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] Call for adoption of draft-sullivan-tls-exported-authenticator

[Patrick McManus]

I have read this draft and believe the final consensus version of this
function will be of high value to the HTTP ecosystem in particular - I
support TLS-WG adopting it.

On Fri, Apr 14, 2017 at 12:29 AM, Joseph Salowey  wrote:

> Hey Folks,
>
> At the IETF 98 meeting in Chicago there was support in the room to adopt
> draft-sullivan-tls-exported-authenticator [0]. We are looking for
> feedback on adopting this draft form the list. Please respond if you
> support the draft and are willing to review it. If you object to its
> adoption, please let us know why. Please respond to the list by 20170501
>
> Cheers,
>
> J&S
>
> [0] https://datatracker.ietf.org/doc/html/draft-sullivan-tls
> -exported-authenticator
>
> ___
> 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] Confirming consensus: TLS1.3->TLS*

[Patrick McManus]

I favor naming the result tls 1.3 - the X in 1.X has effectively become the
modern versioning field and we should stick with that road now as the best
of a bunch of weak options.

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