I suggest dropping the references to Ben's individual alt-svc in DNS draft.. it hasn't been adopted and its future is murky.

actual alt-svc (the non dns kind) actually requires the use of the plaintext SNI. As those are both cachable and connections to new IP addresses (less linkable) you could consider updating it with mike bishop's https://tools.ietf.org/html/draft-bishop-httpbis-sni-altsvc-01 (also an individual draft atm)

Doing so doesn't allow a server to gracefully generate new ESNI keys and retire old ones. We should mandate that clients always choose the first ESNI key for which they have group support. If we adopt #24, where servers lookup keys with a (label, group) -> key mapping, should we also require that each label have the same groups?

Do we need it.

Extensibility failed for SNI, no point in repeating that failure. This is less complex:

   struct {
       opaque domain_name<1..255>;
       opaque zeros[ESNIKeys.padded_length - length(sni)];
   } PaddedServerNameList;

Require that the server check that everything after ServerNameList is zero.

6.2 Middleboxes identifies a legitimate concern where middleboxes might strip a new ESNI extension that is unknown to them.

The ServerName structure as defined in RFC 6066 has an 8-bit NameType field where 0 is defined as host_name and all other values are undefined. Why not define 1 (or any other value) as encrypted_host_name?

The name structure inside ServerName is 16 opaque bits which seems able to accommodate EncryptedSNI as defined in this document. (Make encrypted_sni slightly smaller so that "label" and "suite" fit)

ESNI seems to rely on TLS 1.3 KeyShareEntry which makes it incompatible with TLS 1.2.

That's unfortunate with that "The protocol designed in this document is quite straightforward."

The gist of ESNI comes down to "encrypted_server_name extension, which contains the true extension encrypted under the provider’s public key."

That seems pretty generic and backwards compatible.

Appendix A, Communicating SNI to Hidden Server, specifies mechanisms for providing the hidden server with the selected SNI. We should not assume that the network connection between fronting and hidden is private. An obvious attack path is for the adversary to rent or hack servers in the same location as the hidden server. That's one more reason for not sending the SNI in clear text.

Domain fronting already has a bad rap. Perhaps we should give this a new name to avoid pushback?

The biggest concern from web-site operators will be the possibility of out-of-sync or broken ESNIKeys leading to service disruption.

Considering that, I propose having two attributes being added:

• validity - we can borrow notBefore and notAfter from PKIX
• checksum - something like 32-bits would be enough

Seeing wired ESNIKeys will become a big issue especially if the clients accept ESNIKeys sent from low-quality resolvers / proxies (e.g. those in home routers).

PS. One alternative approach would be to use HTTP (.well-known URI) as a transport of the semi-static key between the TLS server and the resolver. Then, we can use the vocabulary of HTTP to implement client-side verification.

The order of DNS queries may matter in systems that use Happy Eyeballs. Also, should TLS connections block until ESNI key queries come back? What if they never come back?

In 3.1 Topologies, in Shared Mode topology the fronting and hidden servers are one and the same.

Fronting Mode Topology is described as "... might not be the origin for any domains, but as a practical matter, it is probably the origin for a large set of innocuous domains".

Why are some domains innocuous and others aren't?
Is it ok for an attacker (adversary) to discover innocuous domains names?

Innocuous domain names may provide cover when the threat model includes censorship.
Is this what you are trying to solve here?
Isn't that orthogonal to ESNI, i.e., architectures where there is a cover reason why a client is communicating with a server? (because it's a known CDN or sth)

In 5.2 Fronting Server Behavior the text says "Upon determining the true SNI, the fronting server then either serves the connection directly (if in Shared Mode), in which case it executes the steps in the following section, or forwards the TLS connection to the hidden server (if in Fronting Mode)."

... or decrypts the TLS connections and forwards plain text traffic to the hidden server. (Bad idea I know)
The question is why should this document describe what happens after a TLS connection is established between a client and server? Seems to deviate from the problem this document is trying to address. (See below)

Introduction implicitly defines the problem as "an on-path attacker to determine the domain name"
This is always true with ESNI between the client and fronting server.
All domain names are hidden, innocuous, non-innocuous, hosted in the fronting or some other server.

I would propose to drop any mention of hidden servers or deployment architectures, just say "server" and in Security Considerations mention that a server SHOULD be configured in a way that it does not leak the identities of domains it wants to protect. I.e., when the SNI / ESNI extension is missing the server SHOULD not return a certificate for a protected site. For example CDNs should just return a certificate for their own domain.

From the "Fronting Server Behavior" section:

the fronting server then [...] forwards the TLS connection to the hidden server

This is not very clearly defined. Does the fronting server not make any changes to the client hello? Doesn't it remove the encrypted SNI extension and/or possibly add a cleartext SNI as discussed in "Communicating SNI to Hidden Server"?

When I lookup hidden.example, I would expect to have an A (or AAAA) for hidden.example, a TXT for _esni.hidden.example and nothing more.

The key idea is that all hidden servers that share a front would return the same A records. You need to say that.

https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/

is in wglc and seems likely to become a standards track doc.

It establishes a registry for undesrscore scoped names

      "Per" [Attrleaf] "please add the following entry to the DNS
      Underscore Global Scoped Entry Registry:"

   +--------+----------------+-----------------------------------------+
   | RR     | _NODE NAME     | REFERENCE                               |
   | Type   |                |                                         |
   +--------+----------------+-----------------------------------------+
   | TXT    | _esni          | this document                           |
   +--------+----------------+-----------------------------------------+

it means a blocking reference to ATTRLEAF, but that doesn't seem like a problem time wise

In most cases, this can be absent, but it might help with deployment to have SNI in every handshake. Controlling the value of the SNI used (or more to the point, suggesting a safe value), might give clients a better way to avoid notice.

Regarding:

Servers SHOULD configure DNS such that, upon querying a domain name with ESNI support, at most one each of A, AAAA, TXT ESNI, and ALTSVC {{?I-D.schwartz-httpbis-dns-alt-svc}} Resource Record is returned.

Why is that a SHOULD? Does it apply to both fronting and shared mode?

For reference, Cloudflare almost always sends at least two A and AAAA answers for every question.

(I get that it's not a MUST, though I'd also like to understand what the reasoning is in the first place)

Using the same key share looked like a good idea, but it's actually a real pain to implement because you need to get pretty involved with the TLS 1.3 key exchange.

Another approach would be to have separate keys but bind the ClientHello.KeyShare extension into the ESNI extension. I had thought of putting a hash in the extension plaintext but @martinthomson points out that if you use it as AAD, then the client-facing server will automatically detect mismatch

Replace

"It only affects connection routing, server certificate selection, and client certificate verification."

with

"It may affect connection routing, server certificate selection, and client certificate verification."

The current document uses the TXT record for _esni.example.org. This will cause multiple issues.

1. There is no IANA registry for prefixes that start with underscores to be used in DNS, so it is valid for existing servers to already be using _esni as part of the FQDN.
2. The TXT record was designed to hold descriptive text, which means operators can already be using it for other descriptions.
3. As described in issue #35 , using a prefix breaks CNAME.
4. TXT requires base64 encoding which adds overhead on the network and recursive resolvers.

The generally recommended way to "stuff it in the DNS" is to create a new RR type for your data. For example DANE established RR type TLSA (52). There is room in the 16bit IANA registry for another value. The key here is that this prevents systems from misinterpreting the TXT record as something else, and it prevents systems from already using it for something else

https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4

Say that you have a server whose policy is that it will accept any KeyShare that is in the overlap between the client and server supported_groups (this isn't really an advisable policy). An on-path to DNS attacker can force you into the weakest joint group by creating an invalid ESNIKeys structure with a key in that group. The client will then send a KeyShare in that group, and you have been undetectably downgraded. Note that this will lead to suppression of SNI (because the client will be encrypting), but many servers don't require SNI. This works even against a non-ESNI servers.

There's also a weaker attack in which the client-facing server just sends a weaker share in ESNIKeys. This will be very hard for the server to detect.

This doesn't seem ideal, and I'm not quite sure how to remove it. This seems like an argument for #67 if we can make that work.

Thanks to @tvdmerwe for discussions leading to this.

@kazuho: ^^

issue #7 briefly discussed the choice of a _esni DNS prefix for the TXT record. I think we should revisit that.

My primary concern is that using 2 different names for the addressing and key information makes DNS aliasing un-necessarily complicated.

Consider the case where www.example.com is a customer of bigHoster.com and bigHoster.com is deploying ESNI for all its customers.

A classic way to do this is to have www.example.com be a CNAME for host1.bighoster.com

unfortunately to use bighoster.com's new ESNI infrastructure www.example.com would need to add a CNAME record for _esni.www.example.com as well. So the ESNI deployment requires DNS changes outside of the org deploying ESNI, which is going to limit its deployment, which in turn is going to limit the breadth of its anonymity pool. :(

Additionally, I've been told that anecdotally putting names under a CNAME is legal but error prone. RFC 1912 seems to have some language that suggests its not even legal (though that is informational).

If the ESNI information were instead stored without a prefix then the alias would automatically apply as the CNAME applies to all the RR's of a hostname.

Part of the reason for choosing the prefix was to avoid collisions in the TXT space, so it makes sense to also reopen #40 and use a non TXT RR type if we drop the prefix. I think the consensus is moving towards that being fine.

This would also resolve #79 to harmonize esni with existing dns deployments.

You are mixing ClientHello.random in. That would seem to be sufficient. From that you can generate the AEAD nonce and key as though this were record protection.

esni_secret = HKDF-Extract(0, Z)
k = HKDF-Expand-Label(esni_secret, "esni key", ClientHello.random, L)
iv = HKDF-Expand-Label(esni_secret, "esni key", ClientHello.random, L)

We don't need another reason for people to complain about exposing the random number generator state to the network.

The proposed DNS publication method for the key is sketched in section 4, Publishing the SNI Encryption Key. The proposed structure is

    struct {
        ESNIKeyShareEntry keys<4..2^16-1>;
        CipherSuite cipher_suites<2..2^16-2>;
        uint16 padded_length;
    } ESNIKeys;

This can be problematic, given the constraints on TXT records. The practical length of the record payload is at most 255 bytes. The payload content is supposed to be text, which would suggest a base64 encoding, further reducing the available payload size to 189 bytes.

I would suggest encoding just one key & one ciphersuite per record using base64 encoding, and using multiple records if necessary.

This seems to be somewhat discussed in the draft and in issues, but I fail to see the motivation behind not using the ESNI key to encrypt other extensions such as ALPN. The main concern seems to be around entities seeing the value of decrypted ALPN, but that's still better than ALPN being the clear. Another concern is a middlebox blocking this extension, but if the client decides to fail hard, blocking is better than leaking; and if a client falls back to unencrypted then the connection works regardless. If I'm missing something, can that be clarified in the draft?

The text in section 4, Publishing the SNI Encryption Key, specifies that _if a client queries example.com, the ESNI TXT name is esni.example.com. That's fine, but suppose that the client queries "hidden.example.com". The client needs to learn that "hidden.example.com" is fronted by "fronting.example.com" -- per PR #18, the client will do that by obtaining an ALT-SVC record. Should the client get the ESNI key from "_esni.hidden.example.com", or from "_esni.fronting.example.com" ?

Thank you for working on the draft. I can't be more happy to see someone willing to lead the community towards having a particular ESNI solution.

Considering the fact that omitting the certificate chain and the signature was one of the options discussed in my draft (was originally suggested by @siyengar), I am happy to support the proposal and am willing to implement it.

OTOH, please let me argue here for sending the certificate-chain along with the ESNIKey.

While I agree that there is no huge difference in terms of security, there are benefits related to performance in sending the certificate chain along with the ESNIKey.

In QUIC, we are discussing how many packets a server can send before the client's address is validated. This is because sending packets to an non-validated address is an vector for amplification attacks. We can resolve the issue by sending the certificate chain along with the ESNIKey and using an encrypted variant of Cached Certificate Extension.

We also revive the possibility of doing 0-RTT using semi-static key, because the key will be signed by the certificate.

I think that providing performance improvement might give people more incentive to start using ESNI.

traditional SNI is the origin name. You can use an HTTP connect tunnel, traverse a CNAME (or 3), or engage in some alt-svc load balancing and, while these things all change the DNS name you lookup and connect() to, they don't change the SNI.

what about eSNI? the keys are a property of the server, not really the origin. It seems really hard to coordinate this across administrative domains.

The case I'm particularly worried about is where more than one hosting provider is in the mix.. ISTM a typical way of doing this is LB'ing DNS responses with CNAMEs. (e.g. 50% of www.example.com gets CNAME www.cdnA.com and 50% gets www.cdnB.com).. We've got folks from 2 CDNs as active contributors here who know better than I, but this kind of level of indirection to get you CDN agility seems pretty common.. we would want cdnA and cdnB to be able to each use their own keys.

Even without agility, its a pretty common pattern for an origin to maintain control of their own DNS and only delegate to a CDN under load/whatnot and do that via cname...

that argues to me to allow _esni TXT records on the server lookup, not just the origin name. Perhaps they could override the _esni at the origin scope but that seems like a way to trigger the misconfiguration fallback path.

Also, what about connect tunnels where you do do SNI, but don't traditionally do DNS at all?

Regarding:

- If the EncryptedSNI.label value does not correspond to any known
  SNI encryption key, it MUST abort the connection with an
  "illegal_parameter" alert.
  [[OPEN ISSUE: We looked at ignoring the extension but concluded
  this was better.]]

Rather than aborting, would it make more sense for the server to (optionally?) send a fresh ESNIKeys as an extension as part of HelloRetryRequest? Example use case would be that for whatever reason (e.g. key compromise?) the server might want to discard a previously advertised ESNIKeys before it expires. Not sure if it's worth the added complexity though.

(With some other changes it could also be used as an alternative way to publish a key at the cost of one round trip, but the usefulness there is probably limited)

if you dynamically syntehsize a whole bunch of names in example.com you would probably use a *.example.com a/aaaa configuration to do so and give them all the same addresses.

but you can't do the same things for TXT records with the _esni prefix.. basically _esni.*.example.com doesn't do the trick (rfc 4592).

initially I viewed this as a configuration and implementation issue because queries and responses do not carry the * at all - the records are synthesized on demand from this config.

however, the wildcard is part of AXFR which forms an open interface between resolvers so its syntax and meaning is quite reasonably standardized and should be considered.

I don't know that I can give out my advice here before, so I had written an e-mail to [email protected] and that's my first time to send an email to IETF. I don't know whether sending an e-mail is the right thing, so I would paste it here again.

I'm not a native English speaker, I would apologize for my poor English first.

DNS record disadvantage

1.Impossible for wildcard A or AAAA record

It isn't possible for us to set a txt record for wildcard A or AAAA record (_esni.*.example.com. 60S IN TXT "..." "...").
The same problem as #79 mentioned.

2.Publishing a public key using DNS is very inconvenient and insecure.

In general, we can't change the DNS record very conveniently (except some DNS which provide API), so that most domain owners won't change the key very often.

And in some cases, domain owners host their site at host service providers (I don't know how to explain that in English. Host service provider use one physical or virtual server to host many sites) once the provider want to change the ESNI public key, all owners on this server need to change their txt record on time, which is very inconvenient and nearly impossible.

The lack of frequently changing public key and the lack of Perfect Forward Security only provide us little security.

3.DNS record limited only exist domains can enable ESNI

As DNS record is needed to be set, only the owner of a exist and valid domain can enable ESNI.

However, sometimes we want to use encrypted-sni as a private entry. For example, I configured my server that client hello with the sni "vps.panel" would lead to the vps control panel ( I issued a cert for "vps.panel" from my own PKI ). Though I configured that the server must verify my identity using a client certificate, I don't want this private sni to be known to the public. But your draft's method won't allow this use case as "vps.panel" isn't a valid domain name, so that I won't be able to own this domain and set a DNS record for it.

4.Local DNS (hosts) won't work

The hosts file can only take the place of A and AAAA record and won't be able to set public key in hosts in the near future.

5.Requirements to the server is too high

This ESNI draft requires that the server can the decrypt the sni which is encrypted by any public key. This means that the server has to take hold all ESNI private keys. However, I think that it's not proper.
To CDN service provider like Cloudflare, it means that one Cloudflare server has to storage all private ESNI keys of the websites hosted on it.
In my opinion, the browser should encrypt the sni using all public keys found in the DNS record and add a few invalid ESNI along with those, to prevent the attacker identify the real sni from the number of public keys.

Purpose Enhancement - Wall-resistent

In some countries (e.g. China, North Korea, Iran) , people may want to use ESNI to break the government's GreatFireWall, which blocks people from visiting some website.

The wall isn't just a wall, but a very complicated system which can modify DNS resolve result ( DNSSEC isn't common ). They can simply block all _esni txt record, so that all browsers can' get the public key and downgrade to cleartext-sni.

If ESNI can be used with SNI Proxy, it would be a good solution to break the wall. However the DNS record limited only the owner can enable ESNI ( Another disadvantage of DNS :D )

My suggestions

I think some ideas of https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ is quite good. One good idea is to use a certificate to authenticate the Client-Facing Server instead of publishing a public key. My main idea is to introduce a series of HTTP headers like HSTS and HPKP. I will give an example below:

Firstly, I would introduce these headers
( These names may be not proper due to my poor English )

ESNI:(preload);(includeSubdomains);max-age=??
If ESNI header presents in the response, it means this domain enables ESNI. Otherwise, the browser MUST ignore other ESNI-* headers.
e.g.
ESNI:preload;includeSubdomains;max-age=31536000

ESNI-Resolve:{address};max-age=??
{address} can be either FQDN or IP(s) the purpose is to hide the real domain during DNS resolve. The server MUST keep this header up-to-date. This header just like a cacheable CNAME record.
e.g. 
ESNI-Resolve: server233.domain-cdn.com;max-age=31536000
ESNI-Resolve: 0.0.0.0/16;max-age=2592000
ESNI-Resolve: 1.1.1.1;max-age=2592000

ESNI-Trust:{address or pin-hash};max-age=??
{address} is the same as above. The only difference is that the FQDN can contain wildcard.
{pin-hash} is similar to HPKP's pin-hash.
Can have more than one this header in the HTTP Response. (Explain later)
e.g.
ESNI-Trust:fqdn{ *.domain-cdn.com};max-age=31536000
ESNI-Trust:ip{0.0.0.0/16};max-age=31536000
ESNI-Trust:pin-hash{X523zEOQCuEJeU6PzewOGkKCRX+YLvfAsCYJbQubCuE=};max-age=31536000


ESNI-Policy:{policy};max-age=??
{policy} can be "force-encrypted-sni", "retry-clear-sni", "allow-dns-re-resolve", "disallow-dns-re-resolve" defines the action if error happens using ESNI. 
Can have more than one this header in the Response. (Explain below)

It's impossible to have more than one header with the same name, but we may construct these in to a structure and encode (e.g.base64) into one header. The header may be very big, but don't worry, only the first response contains it, HTTP2 will automatically compress them into a few bits in the later response.

When the first time I visit https://www.example.com , I just do the normal tls1.3 hand shake with clear-text sni. The server just do what it should do, but the response MUST contain those ESNI headers if ESNI is enabled. The browser MUST remember these headers ( unless in incognito mode )

When the second time I visit https://www.example.com , the browser SHOULD NOT query DNS resolve for www.example.com, instead, it should visit the FQDN/IP mentioned in the ESNI-Resolve header. And the browser MUST NOT send clear-text sni in the ClientHello, instead, send a CH without sni or a special CH indicates using ESNI. The Client-Facing Server send back certificate, the browser validates the certificate and makes sure the certificate contains at least one FQDN/IP mentioned in the ESNI-Trust header. If mismatch, check the ESNI-Policy and determine whether to retry or not.
And then re-handshake with the server with encrypted-ClientHello in the 0RTT data or another CH extension.
( similar to draft-ietf-tls-sni-encryption method )

My suggestions' advantages and disadvantages are nearly the same as draft-ietf-tls-sni-encryption method. It provides PFS, don't need to change the Split-Mode Server and solved some part of DNS sniffing. But the disadvantage is obvious too, the first hand shake can't be encrypted and the ESNI-Resolve may become incorrect over time. It needs to handshake twice, however, it provided PFS and I think it worth it. And if multiple sites are hosted on the same server (e.g.CDN, Host Service Provider), we just need to do the second handshake, which eliminate the risk of DoS attack in some level.... And I think 0RTT symmetric decryption is better than asymmetric decryption.
Setting max-age too big or too small both have some risks, and I don't know how to solve it.

If you don't like the idea of authenticating the Client-Facing Server, you can simply replace the ESNI-Trust header's content into a public key and use your method. But I don' think set a static public key is a good idea ( explained in some part of DNS disadvantage ).

All in all, we can't have both efficiency, performance and security, reliability. You should make up your mind and choose whether to provide perfect security or perfect performance. I prefer the former.

I know that my idea is similar to draft-ietf-tls-sni-encryption than yours. However, you are the candidate for TLS WG, so I hope you can think it over. But I do agree with your idea that "no need to don't stick out" or simply "we can stick out" :D

Does the advertisement really need a checksum? It complicates things for questionable benefit.

Use DNS-over-something-that-isn't-as-lame-as-UDP and this problem goes away. You probably want DNS to be protected by TLS anyway.

As well as the IANA registrations

PR #73 from @ghedo implements the ESNI RRType, but there doesn't seem to be another issue currently open to track discussion of it.

• a new RRType allows the removal of the _esni prefix (#105 and #79)
• reusing TXT has the potential for conflicts with other uses even with the prefix. (imagine the definition of a TXT record that simply applied to all DNS entries)
• while both TXT and ESNI are 8 bit clean, some people are surprised to learn that about TXT so using a new type may be more robust. Some generic tools processing TXT records would benefit from this.
• TXT is a set of <= 255 byte strings, defining a new type removes that complexity and reduces overhead
• There was initially concern about the viability of new RRTypes, but I believe people are more comfortable with that now than when the text was drafted.

Others include those discussed in I-D.ietf-tls-sni-encryption and the H2-layer approach with secondary certs.

Currently, the connect fails when a mismatch occurs. An alternative strategy might be to return a new ESNI key that is then used for a subsequent connection.

The hash used in the extension should use the same hash inputs as the checksum. The difference here just makes using this harder.

The second paragraph of this section currently contains:

Clearly, DNSSEC (if the client validates and hard fails) is a defense against
this form of attack, but DoH/DPRIVE are also defenses against DNS attacks
by attackers on the local network, which is a common case where SNI.

Clearly, the sentence abruptly ends.

Moreover, the sentence could probably be split in two, at the "but". This should make it easier to read.

Please consider changing the ESNI client extension to a vector of ESNI values. This could be used for server-side redundancy and key rollover. I understand that only one of the entries would be ack'd in EE, and that we would have to think through the possible attacks on the mechanism due to the change.

See
https://mailarchive.ietf.org/arch/msg/tls/rc_tgkgVIeB4yeNCgPcyPzRnrBI

This might not need the same level of rigour as TLS itself, but the construction of the keys could be better. Right now, Z is dependent on contributory behaviour.

I recommend that rather than just hashing ClientHello.random, a pseudo-message be constructed that includes the random, the server advertisement (in its entirety), the client's key share in some form, and maybe the prologue of the esni extension as well. Essentially the entire mini-protocol we're using.

With #22 merged, I wonder if the ESNIKeys struct should just be renamed to something not specific to ESNI, but something more like "generic TLS config in DNS" so that it can be more cleanly reused by unrelated features.

"ServerConfiguration" comes to mind from the early TLS 1.3 days.

Current text says:

If the serialized ServerNameList is longer than ESNIKeys.padded_length, the client MUST NOT use
the "encrypted_server_name" extension.

However, I am not sure if this is the desired behavior. I would rather suggest encrypting even when the hostname exceeds the padded_length. Having some protection is better than none.

The issue is that in certain deployments it is impossible to guess what the maximum length of the hostname will be. Consider *.github.io. It uses a wildcard certificate. Anybody can add a new hostname of any length by creating a new Github account (it might be true that Github some limitation on the length, but that does not necessarily mean that Github shares the maximum length information with the fronting CDN, assuming that it uses a CDN).

dns records are 8 bit clean and rfc 6763 is an example of a TXT record carrying arbitrary data

In DNS, yes, but under what name?

I suggest at _esni.. Usage of TXT and underscore names is now considered an acceptable way to deploy new features. It also deploys more reliably than a new RRtype.

The TLS server name (and thus SNI) is the HTTP origin name, however it is not necessarily the same as the host name of the TLS server. HTTP Alternative Services is the obvious way that happens - but Alt-Svc never changes the origin name.

When fetching the ESNI key, do we fetch it from _esni.origin-name or _esni.host-name?

I think origin-name makes more sense - keeping everything that is an expiicit protocol element in terms of origin eliminates confusion.

the counter argument is that you can use alt-svc to do fine grained fanout to providers with different keys (using cdn specific names for them in alt-svc) in a way that is harder to do through the origin name dns controls.