# Decisions ## Curve 25519+448 draft Move text from draft-ietf-tls-curve25519 to draft-ietf-tls-rfc4492bis. The appropriate curve 25519 & 448 will be included in TLS1.3; it's going to be nearly empty because it's going to point at the CFRG draft (soon to be RFC). ## Issue 223 - absolute or relative time Leave as-is because a) switching to relative time is painful and it's not standalone, b) it's not entirely clear what benefit we get from this, and c) we're already using absolute time for other things like certificates & OCSP. ## Issue 242 - do we require alerts to be sent There was consensus around the idea that if we're going to send an alert then we need to say unequivocally which alert to send. The desired requirement level for sending alerts on the list ran the gamut from MUST NOT to MUST, so at the interim it was agreed that we should reflect reality and make sending all alerts a SHOULD level requirement. This will allow for those with concerns about sending alerts for whatever reason to not send them, but also allow those who do to send them for whatever reason to continue to do so. Note that we have no guarantee that the alert that gets sent ever gets to the recipient because our threat model has always assumed that the attacker controls the links. See issue #254. ## PR 248 - revised KDF We agreed to adopt this PR. But, we also discussed how to address MSJ's comments wrt PKCS11/HSM support so EKR will submit another PR that will include the label + length but nothing else. See issue #5. ## PR 231 - remove SHA-1 from handshake Based on list discussion, the chairs have determined that there is consensus to remove support for SHA-1 from the TLS 1.3 supported_signature_algorithms extension. But, there is also a desire to continue to allow TLS 1.3 clients to interoperate with the installed base of TLS < 1.3 servers that support SHA-1, so if a client wants to interoperate with a TLS 1.2/1/0 server it can offer SHA-1, but it must do so as the last signature/hash pair in the supported_signature_algorithms extensions. Further, the server if it absolutely positively cannot return a path signed with signature/hash algorithm pair in the client-supplied support_signature_algorithms extension then it can also return a chain signed with SHA-1; MD5 remains a MUST NOT and we also agreed to include SHA-224 in the MUST NOT column as well. ## Client Authentication We agreed that we need to support this in TLS 1.3. ### How 1. We need to continue to support the existing two modes supported by D/TLS: 1-RTT (i.e., the "normal" way: CC/CCV + Finish in 2nd flight) 0-RTT (i.e., send cert with CH and the need to send a cert is explicit in the server config) 2. We will modify the data that's signed to conform with what Andrei is proposing provided we also terminate the transcript for key derivation before the CC/CCV. investigate: using the same construct for server/client sigs. 2.5. We're going to adopt the proposal from Andrei. 3. We agreed to opaque correlators. 4. We agreed to not allow unsolicited client auth. 5. We agreed to take out the ClientCertificatType from CertificateRequest. 6. We want a consolidated certificate message and certificate verify. ### Syntax There is currently no consensus to add the "CertificateExtension" field to the CertificateRequest because a) for this to be properly implement the matching rules for each extension type need to be defined, b) there is a concern that this mechanism can be used to fingerprint the client as well as extracting which certificate the client supports, and c) it was unclear why the CA DN couldn't be used to scope the returned certificates. Andrei agreed to provide a list of more constrained certificate extensions that have been asked for. ## Encrypted Content Type and Padding We agreed that we need to support these two features in TLS 1.3. We also agreed to take a conservative approach when incorporating them. For encrypted content type, we agreed to temporalily stay consistent with the current TLS to keep a static content type to avoid breaking middle boxes. See PR #51. For padding, we reached a very rough consensus to start with the content type followed by all zeros (insert reasons why) over the explicit length option (insert reasons why). DKG to propose a PR that we'll then fight out on the list. See PR #253. Why: Versions of TLS prior to 1.3 had limited support for padding. This padding scheme was selected because it allows padding of any encrypted TLS record by an arbitrary size (from zero up to TLS record size limits) without introducing new content types. The design also enforces all-zero padding octets, which allows for quick detection of padding errors For the padding policy for handshake messages, we need some more thought because it is really hard. ## Quantum Safe Extension/CipherSuite The prevailing feeling at the meeting was that the scheme was not well baked, but we also acknowledged that the WG is almost entirely focused on developing TLS 1.3. Because, this is intended as an experiment, we felt that the quickest way forward was for the authors to select a cipher suite from the private use space; this does not require an RFC or an internet-draft. Alternatively, if the authors want a stable specification they can produce an internet-draft that they then take to the ISE (independent stream editor) for publication and ask for a cipher suite from the specification required space. We acknowledged that pursing an extension is more work because it requires an IETF consensus document (i.e., an RFC) and that in the long term we would consider adopting a draft that relaxes this position for this registry. ## Document TLS-Unique for 1.3 Issue #228 Problem: tls-unique is too short. Solution need a draft that says: 1. Don't use tls-unique 2. Use an exporter 3. Make the the output length of at least 32 bytes 4. Define a label per application 5. Use session hash Who: Ask Nico to generate a draft that specifies this. ## Data transfer limitation per connection (issue 125/4) After quibbling with the math a bit, we need to specify how much data current ciphers can safely encrypt. Ask David McGrew for input! ## Include randoms directly in digital signatures Issue 224 Consensus at the interim was that this has straightforward to do by just having the authentication server supply the ServerRandom was enough since it can search through the handshake transcript. # PRF designation in server certificate verify Issue 227 Consensus was to leave as-is. A hash identifier isn't the way to solve this. What you really need is contributory behavior to solve this issue. ## What identity is hashed into the secrets in "anonymous" mode Issue 219 OBE - we removed anonymous. ## Consider extensionifying ServerKeyShare Issue 214 Consensus is to just do it. There's a minor improvement here. ## Encrypted SNI We're punting on trying to learn the cover server config in band. If we learn the cover server config out-of-band, then we need a few things in the protocol to make this work (must get 1&2 and padding, 3&4 are nice to have): 1. encrypted extensions from the client 2. descriptions of which extensions are allowed to be sent as encrypted extensions 3. define sekrit_SNI extension that overrides normal one 4. define cover_server_config extension Now we need a PR.