Subject: [quicwg/base-drafts] Expand source address validation text (#275)

From: Martin Thomson <[email-masked]>
Date: Wed, 08 Feb 2017 16:00:06 -0800

This completes the changes that were started in #120.  As agreed at the interim, TLS will host the source address validation packets, but the transport will be responsible for constructing and validating the token.  I've expanded the detailed interface section to cover this.

There's some finessing in the text around which part adds the integrity check, with the recognition that - because the token will likely be put alongside other TLS information that needs integrity checks - TLS is probably the best place to do that.

This builds on #122 because to do otherwise would be to invite merge conflict hell.  Once that is merged, this will be much easier to review.

Closes #52.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/275

-- Commit Summary --

  * Add definition of transport parameters to -transport
  * Define the extension in -tls
  * Add a stub iana section, fix dead references
  * Remove COPT, add rule about unknown extensions
  * Reference WINDOW_UPDATE properly
  * Remove extra sentence on ignoring unknown parameters
  * editorial
  * Correct reference
  * Move crypto requirements to head of section
  * Wrap note
  * Remove QUIC-Crypto reference
  * Transport parameter are available when the handshake completes
  * Simplify the section on new parameters
  * Add IANA considerations
  * Add transport parameters to the handshake interface in TLS
  * Fix formatting
  * Proofread version negotiation and correct errors
  * Use hex, add initial registry contents
  * Transport parameters during 0-RTT are either remembered or defaults
  * Expanding and refining source/client address validation
  * Note that the server sends address validation tokens to itself.  Closes #118.

-- File Changes --

    M draft-ietf-quic-tls.md (219)
    M draft-ietf-quic-transport.md (489)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/275.patch
https://github.com/quicwg/base-drafts/pull/275.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/275

---

From: Martin Thomson <[email-masked]>
Date: Wed, 08 Feb 2017 16:04:09 -0800

@martinthomson pushed 1 commit.

65c9296  Small refinements

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/275/files/9cb9be462a18e26f8c1c978dd1bf03b0fe5589b2..65c9296eccc1ab931385e072e098b09d34a61c6f

---

From: Martin Thomson <[email-masked]>
Date: Wed, 08 Feb 2017 16:23:06 -0800

d06d901  Capitals are great, but not that Good.

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/275/files/65c9296eccc1ab931385e072e098b09d34a61c6f..d06d901b0e7ba4f2ec0614dc2781ea82e7734422

---

From: janaiyengar <[email-masked]>
Date: Wed, 22 Feb 2017 20:00:30 -0800

janaiyengar commented on this pull request.

One question and a few minor changes. LGTM modulo those.

> -update the state that is included in the ticket.  This might be done to refresh
-the ticket, or in response to changes in the state of a connection.
+Source address validation is therefore performed during the establishment of a
+connection.  TLS provides the tools that support the feature, but basic
+validation is performed by the core transport protocol.
+
+
+### Client Address Validation Procedure
+
+QUIC uses token-based address validation.  Any time the server wishes to
+validate a client address, it provides the client with a token.  As long as the
+token cannot be easily guessed (see {{token-integrity}}), if the client is able
+to return that token, it proves to the server that it received the token.
+
+During the processing of the cryptographic handshake messages from a client, TLS
+will request that the transport make a decision about whether to proceed based

replace "the transport" with "QUIC"

> -the ticket, or in response to changes in the state of a connection.
+Source address validation is therefore performed during the establishment of a
+connection.  TLS provides the tools that support the feature, but basic
+validation is performed by the core transport protocol.
+
+
+### Client Address Validation Procedure
+
+QUIC uses token-based address validation.  Any time the server wishes to
+validate a client address, it provides the client with a token.  As long as the
+token cannot be easily guessed (see {{token-integrity}}), if the client is able
+to return that token, it proves to the server that it received the token.
+
+During the processing of the cryptographic handshake messages from a client, TLS
+will request that the transport make a decision about whether to proceed based
+on the information it has.  TLS will provide the transport with any token that

the transport --> QUIC

> +Source address validation is therefore performed during the establishment of a
+connection.  TLS provides the tools that support the feature, but basic
+validation is performed by the core transport protocol.
+
+
+### Client Address Validation Procedure
+
+QUIC uses token-based address validation.  Any time the server wishes to
+validate a client address, it provides the client with a token.  As long as the
+token cannot be easily guessed (see {{token-integrity}}), if the client is able
+to return that token, it proves to the server that it received the token.
+
+During the processing of the cryptographic handshake messages from a client, TLS
+will request that the transport make a decision about whether to proceed based
+on the information it has.  TLS will provide the transport with any token that
+was provided by the client.  For an initial packet, the transport can decide to

ditto here and below

> +validate a client address, it provides the client with a token.  As long as the
+token cannot be easily guessed (see {{token-integrity}}), if the client is able
+to return that token, it proves to the server that it received the token.
+
+During the processing of the cryptographic handshake messages from a client, TLS
+will request that the transport make a decision about whether to proceed based
+on the information it has.  TLS will provide the transport with any token that
+was provided by the client.  For an initial packet, the transport can decide to
+abort the connection, allow it to proceed, or request address validation.
+
+If the transport decides to request address validation, it provides the
+cryptographic handshake with a token.  The contents of this token are consumed
+by the server that generates the token, so there is no need for a single
+well-defined format.  A token could include information about the claimed client
+address (IP and port), and any other supplementary information the server will
+need to validate the token in the future.

While we're suggesting, add "timestamp" as a suggestion?

> +During the processing of the cryptographic handshake messages from a client, TLS
+will request that the transport make a decision about whether to proceed based
+on the information it has.  TLS will provide the transport with any token that
+was provided by the client.  For an initial packet, the transport can decide to
+abort the connection, allow it to proceed, or request address validation.
+
+If the transport decides to request address validation, it provides the
+cryptographic handshake with a token.  The contents of this token are consumed
+by the server that generates the token, so there is no need for a single
+well-defined format.  A token could include information about the claimed client
+address (IP and port), and any other supplementary information the server will
+need to validate the token in the future.
+
+The cryptographic handshake is responsible for enacting validation by sending
+the address validation token to the client.  A legitimate client will include a
+copy of the token when they attempt to continue the handshake.  The

"they attempt" --> "it attempts"

> +
+If the transport decides to request address validation, it provides the
+cryptographic handshake with a token.  The contents of this token are consumed
+by the server that generates the token, so there is no need for a single
+well-defined format.  A token could include information about the claimed client
+address (IP and port), and any other supplementary information the server will
+need to validate the token in the future.
+
+The cryptographic handshake is responsible for enacting validation by sending
+the address validation token to the client.  A legitimate client will include a
+copy of the token when they attempt to continue the handshake.  The
+cryptographic handshake extracts the token then asks the transport a second time
+whether the token is acceptable.  In response, the transport can either abort
+the connection or permit it to proceed.
+
+A connection MAY be accepted without address validation - or with only limited

I don't understand what this means. Why should a connection be accepted without address validation?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/275#pullrequestreview-23394714

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Feb 2017 20:27:25 -0800

Comments addressed.  Rebased.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/275#issuecomment-281891406

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Feb 2017 20:21:33 -0800

martinthomson commented on this pull request.

If you aren't going to send much data to the client, then it's a calculated risk.  As I observe here, there is implicit validation when the cryptographic handshake completes and a server might choose to avoid paying the tax of an explicit validation step (and an RTT) in favour of provisionally continuing.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/275#discussion_r102636822

---

From: janaiyengar <[email-masked]>
Date: Wed, 22 Feb 2017 22:51:13 -0800

janaiyengar approved this pull request.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/275#pullrequestreview-23408567

---

From: janaiyengar <[email-masked]>
Date: Wed, 22 Feb 2017 22:51:17 -0800

Merged #275.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/275#event-973873456