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

Define a "mandatory" SvcParamKey #205

Merged
merged 3 commits into from
Jul 3, 2020
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
57 changes: 42 additions & 15 deletions draft-ietf-dnsop-svcb-https.md
Original file line number Diff line number Diff line change
Expand Up @@ -520,7 +520,7 @@ following procedure:
{{client-failures}}).

3. If one or more SVCB records of ServiceForm SvcRecordType are returned
for HOST, clients should select the highest-priority option with
for HOST, clients should select the highest-priority compatible record with
acceptable parameters, and resolve AAAA and/or A records for its
SvcDomainName if they are not already available. These are the
preferred SvcFieldValue and IP addresses. If the connection fails, the
Expand Down Expand Up @@ -867,7 +867,33 @@ compliant recursive resolvers. When SvcDomainName is ".", server operators
SHOULD NOT include these hints, because they are unlikely to convey any
performance benefit.

## "mandatory" {#mandatory}

In a ServiceForm RR, a SvcParamKey is considered "mandatory" if the RR will not
function correctly for clients that ignore this SvcParamKey. Each SVCB
protocol mapping SHOULD specify a set of keys that are "automatically
mandatory", i.e. mandatory if they are present in an RR. The SvcParamKey
"mandatory" is used to indicate any mandatory keys for this RR, in addition to
any automatically mandatory keys that are present.

A ServiceForm RR is considered "compatible" with a client if the client
implements support for all its mandatory keys. If the SVCB RRSet contains
no compatible RRs, the client will generally act as if the RRSet is empty.

enygren marked this conversation as resolved.
Show resolved Hide resolved
In presentation format, "mandatory" contains a list of one or more valid
SvcParamKeys, either by their registered name or in the unknown-key format
({{svcfieldvalue}}). Keys MAY appear in any order, but MUST NOT appear more
than once. Any listed keys MUST also appear in the SvcFieldValue.
For example, the following is a valid SvcFieldValue:

enygren marked this conversation as resolved.
Show resolved Hide resolved
echconfig=... key65333=ex1 key65444=ex2 mandatory=key65444,echconfig

In wire format, the keys are represented by their numeric values in
network byte order, concatenated in ascending order.

This SvcParamKey is always automatically mandatory, and MUST NOT appear in its
own value list. Other automatically mandatory keys SHOULD NOT appear in the
list either. (Including them wastes space and otherwise has no effect.)

# Using SVCB with HTTPS and HTTP {#https}

Expand All @@ -886,6 +912,8 @@ semantics apply equally to HTTPS RRs unless specified otherwise.

All the SvcParamKeys defined in {{keys}} are permitted for use in
HTTPS RRs. The default set of ALPN IDs is the single value "http/1.1".
The "automatically mandatory" keys ({{mandatory}}) are "port", "alpn",
and "no-default-alpn".

The presence of an HTTPS RR for an origin also indicates
that all HTTP resources are available over HTTPS, as
Expand Down Expand Up @@ -1002,12 +1030,9 @@ the origin, not the SvcDomainName.

## HTTP Strict Transport Security {#hsts}

By publishing an HTTPS RR, the server
operator indicates that all useful HTTP resources on that origin are
reachable over HTTPS, similar to HTTP Strict Transport Security
{{!HSTS=RFC6797}}. When an HTTPS RR is present for an origin,
all "http" scheme requests for that origin SHOULD logically be redirected
to "https".
By publishing a usable HTTPS RR, the server operator indicates that all
useful HTTP resources on that origin are reachable over HTTPS, similar to
HTTP Strict Transport Security {{!HSTS=RFC6797}}.

Prior to making an "http" scheme request, the client SHOULD perform a lookup
to determine if any HTTPS RRs exist for that origin. To do so,
Expand All @@ -1021,9 +1046,11 @@ the client SHOULD construct a corresponding "https" URL as follows:

This construction is equivalent to Section 8.3 of {{HSTS}}, point 5.

If an HTTPS RR query for this "https" URL returns any HTTPS RRs
(AliasForm or ServiceForm), the client SHOULD act as if it has received an
HTTP "307 Temporary Redirect" redirect to this "https" URL.
If an HTTPS RR query for this "https" URL returns any AliasForm HTTPS RRs,
or any compatible ServiceForm HTTPS RRs (see {{mandatory}}), the client
enygren marked this conversation as resolved.
Show resolved Hide resolved
SHOULD act as if it has received an HTTP "307 Temporary Redirect" redirect
to this "https" URL. (Receipt of an incompatible ServiceForm RR does not
trigger the redirect behavior.)
Because HTTPS RRs are received over an often insecure channel (DNS),
clients MUST NOT place any more trust in this signal than if they
had received a 307 redirect over cleartext HTTP.
Expand Down Expand Up @@ -1074,8 +1101,8 @@ behavior for connection establishment:

1. Perform connection establishment using HTTPS RRs as described in
{{client-behavior}}, but do not fall back to the origin's A/AAAA records.
If all the HTTPS RRs have an "echconfig" key, and they all fail,
terminate connection establishment.
If there are compatible HTTPS RRs, they all have an "echconfig" key, and
attempts to connect to them all fail, terminate connection establishment.
2. If the client implements Alt-Svc, try to connect using any entries from
the Alt-Svc cache.
3. Fall back to the origin's A/AAAA records if necessary.
Expand Down Expand Up @@ -1247,15 +1274,15 @@ be populated with the registrations below:

| SvcParamKey | NAME | Meaning | Reference |
| ----------- | ------ | ---------------------- | --------------- |
| 0 | (no name) | Reserved for internal use | (This document) |
| 0 | mandatory | Mandatory keys in this RR | (This document) |
| 1 | alpn | Additional supported protocols | (This document) |
| 2 | no-default-alpn | No support for default protocol | (This document) |
| 3 | port | Port for alternative service | (This document) |
| 4 | ipv4hint | IPv4 address hints | (This document) |
| 5 | echconfig | Encrypted ClientHello info | (This document) |
| 5 | echconfig | Encrypted ClientHello info | (This document) |
| 6 | ipv6hint | IPv6 address hints | (This document) |
| 65280-65534 | keyNNNNN | Private Use | (This document) |
| 65535 | key65535 | Reserved | (This document) |
| 65535 | key65535 | Reserved ("Invalid key") | (This document) |

TODO: do we also want to reserve a range for greasing?

Expand Down