Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Align opp-sec and alt-svc #33

Closed
enygren opened this issue Aug 22, 2014 · 8 comments

Comments

Projects
None yet
4 participants
@enygren
Copy link
Contributor

commented Aug 22, 2014

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
@martinthomson

This comment has been minimized.

Copy link
Contributor

commented Aug 22, 2014

Yeah, I think that this did cross that line. The first suggestion is fine, and we probably need to identify what is actually used to authenticate the server identify (which is not TLS :).

The second suggestion I'd like to respond to, but won't go into detail here because the list is more appropriate (and I'm very tired right now). We have discussed this sort of signal before. Mark's original draft proposed a very similar feature in a different form.

@mnot mnot added design labels Aug 26, 2014

@mnot

This comment has been minimized.

Copy link
Member

commented Aug 26, 2014

Marked "design" for the second part. Eric, in the future please open separate issues.

@mnot

This comment has been minimized.

Copy link
Member

commented Nov 11, 2014

Discussed in Honolulu; can flip to editorial.

@mnot mnot added editorial and removed design labels Jan 21, 2015

@mnot mnot added the opp-sec label Feb 11, 2015

@reschke

This comment has been minimized.

Copy link
Contributor

commented Apr 30, 2015

I looked at https://github.com/httpwg/wg-materials/blob/gh-pages/ietf91/minutes.md#alt-svc; not sure what the concrete proposal here is. Just apply the first part of Eric's proposed change?

@mnot

This comment has been minimized.

Copy link
Member

commented May 1, 2015

For alt-svc, yes.

reschke added a commit that referenced this issue May 1, 2015

@reschke

This comment has been minimized.

Copy link
Contributor

commented May 1, 2015

removing alt-svc label because that change has been applied

@reschke reschke removed the alt-svc label May 1, 2015

@mnot

This comment has been minimized.

Copy link
Member

commented Feb 6, 2016

Is there anything that needs to change in OppSec here?

@mnot

This comment has been minimized.

Copy link
Member

commented Mar 2, 2016

Closing.

@mnot mnot closed this Mar 2, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.