httpwg / http-extensions Goto Github PK

http://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0056.html

Why does the spec explicitly allow the alternate to simultaneously send you an alternate list (which we trust, because the alternate is authoritative for this origin) and a status code telling us this host is not authoritative for this origin?

It seems like 421 should automatically remove the alternate (as stated) and cause the user agent to fall back to the origin server. While one can also envision a scenario where the server says "I'm not authoritative, but I know who might be....", that way lies loops.

Bence Béky in http://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0220.html:

"I need some clarification. I am writing a parser for ALTSVC header
fields and wish to ignore unknown parameters. However, it is unclear
to me whether a parameter without "=value" should be ignored or
treated as malformed.

draft-ietf-httpbis-alt-svc-06 Section 3 refers to "parameter".
Section 1.1 says "parameter" is defined in RFC7230. In fact, RFC7230
has "transfer-parameter" but not "parameter". Also, RFC7230 Section
says "Parameters are in the form of a name or name=value pair.",
implicilty allowing names without values, but in the next line
"transfer-parameter" is defined as a name=value pair, which disallowes
names without values. On the other hand, RFC7231 Section 3.1.1.1
defines "parameter" as a name=value pair, but this is not what
draft-ietf-httpbis-alt-svc-06 refers to."

Ryan asks what you should pass to proxy.pac when you know about a potential alt-svc.

I suggested that you use the original request origin and only use alternatives if the proxy.pac doesn't provide a proxy address. That is proxy.pac overrides alternative services.

Second para of 3. Server Authentication starts:

When connecting to an alternative service for an "http" URI, clients are required to perform the server authentication procedure descriptor in Section 3.1 of [RFC2818].

Is this merely a missing "not"? If that isn't the case, this is a design issue...

The current Alt-Svc-Used indicator is a boolean ("0"/"1"), due to the desire to preserve privacy.
Based on some explorations of how this would be implemented on the server side, we realized that this doesn't provide enough information to distinguish between the different use-cases for Alt-Svc. In particular, a server would have no way to know if just the protocol was changed, or if both the protocol and host were changed. If we start using multiple Alt-Svc sources (such as DNS) this also becomes relevant.

An option short of including (proto,host,port) in Alt-Svc-Used would be to include a better indicator of how the Alt-Svc was used. This could be either a bitmask or a string of tokens. For example, with a bitmask:

• 1 = Alt-Svc was used to change protocol (ie, service proto != default origin scheme's proto)
• 2 = Alt-Svc was used to change port (ie, service port != origin port)
• 4 = Alt-Svc was used to change host (ie, service host != origin host)
• 8 = Alt-Svc was obtained via Alt-Svc header
• 16 = Alt-Svc was obtained via ALTSVC frame
• 32 = Alt-Svc was obtained via DNS record (reserved, not yet defined)

With a token approach, short character strings could replace the bitmask.
In either case this would result in a value like:

Alt-Svc-Used: 20
Alt-Svc-Used: h,f

For load-balancing, this would make it possible to infer the (proto,host,port) that may have been used in cases where it differs by use-case but is consistent within a use-case.

This would also significantly help with debuggability on the server side.

Editorial

Regardless of how this is resolved, there is still text referring to previous Alt-Svc-Used indicator proposals that should be cleaned up to be consistent with whatever we decide on. For example, with the current text the following is confusing and should be removed:

To reduce the ability of servers to track individual clients over time (see ), an alternative service indication sent by a client &SHOULD-NOT; include
any alternative service information other than the protocol, host and port.

(as the protocol, host, and port aren't part of what is being sent in the current indication).

The same applies of the "Tracking Clients Using Alternative Services" section which may be a remnant from previous versions.

The current text also mentions a "token" in the Alt-Svc-Used definition, but does not explain it or specify how it might be used or set.

We need to define how a client using OppSec connects to a configured proxy; e.g., does it CONNECT, or does it downgrade? Does the answer change if the proxy is http vs https? Can the proxy advertise OppSec?

Issue by mnot
Monday Mar 31, 2014 at 03:20 GMT
Originally opened as httpwg/http2-spec#444

For the load balancing use case, it's necessary for clients to always flush altsvc cache upon a network change, but right now they're only required to examine the cache for suspicious entries. We should discuss whether this should be upgraded to always flush.

Section 3 third para ends:

For instance, a client could examine the certificate to see if it has changed over time.

This implies that certs SHOULD NOT change over time; as it is, though, they can't rely upon that, so this text is highly speculative. I think we should either firm it up or take it out (probably the latter).

Issue by martinthomson
Thursday Jun 12, 2014 at 18:00 GMT
Originally opened as httpwg/http2-spec#522

What are the semantics of subsequent ALTSVC frames for a given origin?

The current story is that a new value replaces the value of the old for that origin.

Alternatively, we could have multiple frames present alternative alternative services. That opens the question of how to indicate that a given service is obsolete. But it's not clear we even need to do that.

Then there is the fact that the Alt-Svc header field can have multiple values (see #521). Do we need to replicate that capability for frames?

I think the introduction needs to do a stronger job of framing expectations regarding security properties.

E.g., insert new para after para 2:

Opportunistic Security does not provide the same guarantees as using TLS with "https" URIs; it is vulnerable to active attacks, and does not change the security context of the connection. Normally, users will not be able to tell that it is in use (e.g., there will be no "lock icon").

If draft-dukhovni-blah ever gets published, or at least the constant spiraling in SAAG quiets down, then we want to include a reference to that.

must ignore? how to register new ones? IANA registry?

ALPN identifiers from the ALPN spec have been defined in the context of negotiating the application protocol in TLS. In this context, they imply a layering above TLS.
When used outside this context, there is an ambiguity, mainly for the http/1.1 token: does it refer to HTTP/1.1 over TLS, or can it refer also to HTTP/1.1 over TCP?
The draft should resolve this ambiguity by stating that the http/1.1 identifier is used to identify HTTP/1.1 over TLS.

In addition, a new identifier, h1c for example, could be defined to identify HTTP/1.1 over cleartext TCP, in order to allow using Alt-Svc to be used to target an HTTP/1.1 server over cleartext TCP.

Section 4 doesn't explain what to do when the frame is missing the origin on stream 0.

Simplest thing would be to say that a frame on stream 0 that doesn't contain an origin should be ignored.

I think we need to be REALLY careful about making assertions about an origin in a response, given things like pretty-bad-proxy.

Section 3 says:

Alt-Svc MAY occur in any HTTP response message, regardless of the status code.

That's way too broad. For example, what if it's in response to a CONNECT -- will clients associate it with the origin?

I think the resolution of this will need to reference this:
http://httpwg.github.io/specs/rfc7231.html#identification

HTTP-TLS creates a commitment to use an authenticated connection. We need to make it clear that changes to Alt-Svc, even on that connection cannot change the fact that the origin needs to be authenticated for the duration of the commitment.

One potential attack here is for a MitM to advertise a different Alt-Svc, perhaps overriding the advertisement for the secured endpoint. A naive implementation might update the set of available Alt-Svc advertisements and then continue. What should happen here is that the service becomes unreachable.

section 4 of alt-svc clearly describes origin field handling for stream 0 and client initiated (odd) streams, but it is silent on pushed streams.

I think it should say must ignore

When the origin delegates to an alternate for 30 seconds, and the alternate delegates somewhere else (or to itself) for 7 days, how long does the client keep it? 30 seconds because that’s what the origin said, or 7 days because the alternate is supposed to be equivalent in authority to the origin?

I'm inclined toward the second, since the alternate is supposed to be fully authoritative and since it enables use of an alternate to be persistent so long as you regularly visit the origin. It feels odd to let a delegate grant itself more power than the delegation originally gave it, though....

Issue by mnot
Monday Apr 21, 2014 at 03:02 GMT
Originally opened as httpwg/http2-spec#462

Currently, Alt-Svc says:

Intermediaries MUST NOT change or append Alt-Svc field values.

This seems too restrictive; e.g., a gateway (CDN) could do something useful here.

Suggestion:

Proxies MUST NOT change or append Alt-Svc field values.

An argument could be made to degrade to SHOULD NOT, but if we do that, the specific conditions ought to be enumerated.

Section 4 requires PROTOCOL_ERROR on an ALTSVC frame. However, earlier we say that it's a non-critical extension, and can be ignored. Which is it?

Yes, we could make a distinction on "supporting the frame", but that doesn't seem to helpful.

Can we just drop the requirement and say it doesn't mean anything?

In 3 The Alt-Svc HTTP Header Field, there's:

When an Alt-Svc response header field is received from an origin, its value invalidates and replaces all cached alternative services for that origin.

However, in several other places, we now say that multiple alternatives can co-exist (with the client figuring out which to use).

Is this still our intent -- i.e., that the header field has a special cache invalidation semantic -- or is it just left over from our previous approach?

https://tools.ietf.org/html/rfc7234#section-5.3

Contains the text: "The Expires value is an HTTP-date timestamp, as defined in Section 7.1.1.1 of [RFC7231]."

The target of the link to Section 7.1.1.1 is https://tools.ietf.org/html/rfc7234#section-7.1.1.1 but should be https://tools.ietf.org/html/rfc7231#section-7.1.1.1 instead

Section 3 implies that there are no cipher suite requirements on Opp Sec, but it'd be good to discuss and formalise this. May require tweaks to HTTP/2 (which places requirements on use of TLS, not TLS with "https").

Or, for "parameter", reference the alt-svc spec.

Alt-Svc tells me to use h2, so I open a TLS connection, and the server either doesn’t support ALPN or doesn’t select h2. What now? Weird corner cases ensue where I’m connected to something that may or may not be the alternate I was intending to reach. (Similar issues ensue attempting to connect using h2c -- does it mean a direct TCP connection to the specified port, or that the client should offer Upgrade? What if the server doesn't accept the Upgrade?)

It's simpler to just say TLS is the protocol and require ALPN support in 2.3 as well. Point me to a TLS-enabled endpoint, and the specific protocols we'll use will be negotiated in real-time.

However, this does pose a challenge if you wanted only HTTP/3 traffic going to your alternate.

Section 9.4 - is this still necessary, now that it's just one bit? At a minimum, this section should be toned down.

Someone who controls any resource on an origin can issue directives that affect all resources on that origin. (Thinking of the server the CS/CE students could work with in college, where we all had pages at server.example.edu/~username.) Sure, I can’t change the host because I don’t have the server cert, but I can change ports without that requirement.

The guidance in 9.1 just says “don’t let people do that,” which is easier said than done on systems that already exist. People can run apps listening on ephemeral ports, and people can control their home pages. With this combination, everyone else's home pages can be hijacked unless the server admin reads this draft before any students do and promptly prohibits pages from emitting headers named Alt-Svc.

The way to partially fix this is to require strong auth for changes of port as well. Resources can still slow down access by causing attempts to access an alternate, but the alternate won't be able to supply fake resources.

The field-name for Alt-Svc-Used is 12 characters, and it's required to be sent in every request.

While we have header compression in /2, we don't in /1.

Can we make this shorter? Perhaps "ASU"?

Issue by mnot
Monday Mar 31, 2014 at 03:19 GMT
Originally opened as httpwg/http2-spec#443

It's likely necessary for the server to know which protocol the user agent has chosen, and perhaps even the hostname (for load balancing). At the very least, there should be a flag in SETTINGS that indicates that an alternate service has been used.

(In the Readme)
Just shows GitHub Pages' default 404 site.

Issue by mnot
Wednesday Jun 04, 2014 at 16:11 GMT
Originally opened as httpwg/http2-spec#492

When we were originally working on Alt-Svc, Patrick and I put a restriction on the Alt-Svc header field so that it couldn’t redirect clients to a different host.

Since then, several people have pointed out that the requirement to have strong server authentication, as well as cache flushing, seems to contain the risk associated with doing this, and that the facility could be quite useful.

So, I’m suggesting we (re-) add the capability to the header.

a) it's obsoleted anyway, b) that's what we have the IANA status code registry for.

Raised by Amos in https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0452.html:

Section 4 uses the term "proxy authentication" referencing RFC 7235.

In RFC 7235 there is no definition, and only a vague implied explanation
of that term via explaining what the 407 status means.

I believe the text in section 4 should be re-written to match the
per-header descriptions found in RFC 7235 sectio 4.3/4.3 paragraph 2.
With mention specifically about how it differs from Authentication-Info
by being hop-by-hop.

I think the purpose of the headers should be made more consistent across the document.
In the Introduction, they are used to "return additional information during or after authentication", while in 3, the Authentication-Info header is used to "communicate additional information regarding the successful authentication".

DIGEST use it in an optional manner, to convey additional information after a successful authentication.
Scram is using it in a mandatory manner, to finalize the authentication, by conveying information for authenticating the server.

I think that Authentication-Info should be used by the server once the client is authenticated (i.e. the status code is not 401), to either convey additional information or finalize the authentication.

Proposal in #47.

Issue by martinthomson
Thursday Jun 05, 2014 at 19:46 GMT
Originally opened as httpwg/http2-spec#502

...with a good explanation. This helps alleviate the privacy considerations (see #501)

The security considerations ("Tracking Clients Using Alternative Services") are currently focused on the Alt-Used header field, which adds one bit of tracking info. They also need to mention that the alt-svc host name itself could be used for tracking.

Alternates provided because of location (seattle.edge.net vs. sfc.edge.net) need to be cleared on network changes. (They’re probably direct pointers to individual nodes/datacenters.) Alternates provided because of capabilities (sni.edge.net as alternate of legacy.edge.net) shouldn’t be cleared on network changes, because they’re not location-dependent. (The names probably resolve to different IPs based on location at the DNS level, or they resolve to anycast addresses.)

Should there be a hint to the client that a particular alternate does/doesn’t need to be flushed on changes? Might impact the issues described in 9.2, but TLS should still mitigate without the flushing.

I'm not sure how this can be turned into something useful, but this seems pretty bad:

1. An HTTP/1.1 server doesn't check the scheme, but permits authority form requests for both http and https equally. Scheme is instead inferred from the presence/absence of TLS in the stack.
2. Attacker sends an Alt-Svc header field to clients referencing the https endpoint on that server. This can come from any resource on the http endpoint, so it might not require any MitM attack.
3. Clients now make http requests to the secure endpoint and now the content from the https origin is entered into the http origin.

Do we want to require an explicit indication from HTTP/1.1 servers so that clients can
be assured that this error did not occur?

This should not be a problem for HTTP/2.

The full name of the WG is "HTTP Working Group" -- httpbis is only the short identifier (kept because changing it would be a pain). Please replace throughout your drafts, and note below when each is done.

Apparently, this is confusing. Picking a new name might help.

At the end of section 3, the paragraph:

The value(s) advertised by Alt-Svc can be used by clients to open a new connection to one or more alternative services immediately, or simultaneously with subsequent requests on the same connection.

says that several alternative services can be used simultaneously by a client.

However, section 2.4 Using Alternative Services, recommend choosing one alternative service and using only one alternative service (except during the transition time).

I think we should align the two by rephrasing the sentence in 3.

After a re-read of alt-svc and opp-sec, it may make sense to have use some better alignment between the two docs around the cases where authentication is not employed. In particular, alt-svc indicates:

Importantly, this includes its security context; in particular, when TLS
is in use, the alternative server will need to present a certificate
for the origin's host name, not that of the alternative.

Replacing "is in use" with "is used to authenticate" would align that text better with opp-sec.

On the opp-sec side:

A client MAY perform additional checks on the offered certificate if the server does not select an
unauthenticated TLS cipher suite. This document doesn't define any such checks, though clients
could be configured with a policy that defines what is acceptable.

is very unclear for a server implementer (as well as clients). If authentication doesn't succeed, should the client fail-back to clear-text (the origin) or hard fail?

One possibility (which may start getting outside of the editorial realm) is for an Alt-Svc parameter indicating that authentication will not be present (either via an unauthenticated cipher suite or a mismatching cert). This would allow clients to chose to ignore the Alt-Svc rather than following it and erroring or needing to fall-back). For example:

 Alt-Svc: h2=":443" ; unauth

The spec currently doesn't use BCP14 which MAY or MAY NOT confuse people.

1. allow the frame to carry multiple indicators
2. while doing so, use the same payload formats for both

Issue by martinthomson
Thursday Jun 12, 2014 at 17:56 GMT
Originally opened as httpwg/http2-spec#521

The Alt-Svc header field permits multiple entries. How does a client select between them when there are multiple options that are acceptable to the client?

1. Add a q= parameter.
2. Select the first acceptable option.
3. Something else.

Raised by Amos in https://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/0452.html:

Section 3 paragraph 3 says "Intermediaries are not allowed to modify the field value in any way."

RFC 7235 uses wording in the form: "A proxy forwarding ... MUST NOT modify ..."

I believe the Authentication-Info should share both normative MUST NOT,
and term "proxy" instead of intermediary. Since there are legitimate
cases where gateways and/or other intermediaries may need to change it
per the relevant auth scheme.

Issue by reschke
Tuesday Apr 01, 2014 at 06:16 GMT
Originally opened as httpwg/http2-spec#446

See http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/0856.html

What does that even mean?

I think that we can be a little clearer and more precise about this statement.