[TLS] Adam Roach's No Objection on draft-ietf-tls-tls13-cert-with-extern-psk-03: (with COMMENT)
Adam Roach has entered the following ballot position for draft-ietf-tls-tls13-cert-with-extern-psk-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-cert-with-extern-psk/ -- COMMENT: -- Thanks for the work on this document and its described mechanism. ID Nits reports: == Unused Reference: 'RFC2104' is defined on line 504, but no explicit reference was found in the text ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adam Roach's Yes on draft-ietf-tls-sni-encryption-05: (with COMMENT)
No worries! I'd work with the responsible AD to coordinate when to publish a new version. I do have one comment below -- regarding the multi-party security context -- that isn't really editorial and which isn't addressed in the github version. Do you have any thoughts on it? Am I just missing something obvious? /a On 9/18/19 4:10 PM, Christian Huitema wrote: Thanks, Adam I appreciate the feedback, and in fact I need to apologize. We have a new version of the draft ready at https://github.com/tlswg/sniencryption, which takes into account the comments received before Saturday 15, but does not take into account the latest round of comments from Alissa, Éric and Roman. It resolves almost all the nits that many of you have noticed. I probably hesitated too long before publishing a new version of the draft. I knew the ballot was in progress, and I was trying to not force everybody to read the draft a second time. Also, I was concerned that comments would keep coming as long as the ballot progressed, and I kind of hoped resolving all of them before cutting a new version. But then, several of you end up stumbling on the same issues that are already fixed in the editor copy. My bad. At that point, I could either publish a new draft version right know, or wait a couple of days and address the last comments. I wonder what is best for the IESG members. Any opinion? -- Christian Huitema On 9/17/2019 7:55 PM, Adam Roach via Datatracker wrote: Adam Roach has entered the following ballot position for draft-ietf-tls-sni-encryption-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ -- COMMENT: -- Thanks to everyone who worked on this. It seems that it will be a useful tool for evaluating potential solutions. --- §3.1: Regardless of the encryption used, these designs can be broken by a simple replay attack, which works as follow: Nit: "...as follows:" --- §3.6: These solutions offer more protection against a Man-In-The- Middle attack by the fronting service. The downside is the the client will not verify the identity of the fronting service with risks discussed in , but solutions will have to mitigate this risks. This final sentence appears to be missing some kind of citation before the comma. --- §3.6: Adversaries can also attempt to hijack the traffic to the regular fronting server, using for example spoofed DNS responses or spoofed IP level routing, combined with a spoofed certificate. It's a bit unclear why this is described as part of the injection of a third party into the scenario. As far as I understand, the described attack exists today, in the absence of any SNI encrypting schemes. If there's a new twist introduced by a multi-party security context, the current text doesn't seem to explain what it is. --- §3.7: Multiple other applications currently use TLS, including for example SMTP [RFC5246], DNS [RFC7858], or XMPP [RFC7590]. Nit: "...including, for example, SMTP..." Nit: "...and XMPP..." These applications too will benefit of SNI encryption. HTTP only methods like those described in Section 4.1 would not apply there. Nit: "...benefit from SNI..." Nit: "HTTP-only..." --- §4.2: This requires a controlled way to indicate which fronting ferver is acceptable by the hidden service. Nit: "...server..." --- §7: Thanks to Stephen Farrell, Martin Rex Martin Thomson and employees of the UK National Cyber Security Centre for their reviews. I think you're missing a comma between the two Martins. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Adam Roach's Yes on draft-ietf-tls-sni-encryption-05: (with COMMENT)
Adam Roach has entered the following ballot position for draft-ietf-tls-sni-encryption-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ -- COMMENT: -- Thanks to everyone who worked on this. It seems that it will be a useful tool for evaluating potential solutions. --- §3.1: > Regardless of the encryption used, > these designs can be broken by a simple replay attack, which works as > follow: Nit: "...as follows:" --- §3.6: > These solutions offer more protection against a Man-In-The- > Middle attack by the fronting service. The downside is the the > client will not verify the identity of the fronting service with > risks discussed in , but solutions will have to mitigate this risks. This final sentence appears to be missing some kind of citation before the comma. --- §3.6: > Adversaries can also attempt to hijack the traffic to the > regular fronting server, using for example spoofed DNS responses or > spoofed IP level routing, combined with a spoofed certificate. It's a bit unclear why this is described as part of the injection of a third party into the scenario. As far as I understand, the described attack exists today, in the absence of any SNI encrypting schemes. If there's a new twist introduced by a multi-party security context, the current text doesn't seem to explain what it is. --- §3.7: > Multiple other applications currently use TLS, including for example > SMTP [RFC5246], DNS [RFC7858], or XMPP [RFC7590]. Nit: "...including, for example, SMTP..." Nit: "...and XMPP..." > These applications > too will benefit of SNI encryption. HTTP only methods like those > described in Section 4.1 would not apply there. Nit: "...benefit from SNI..." Nit: "HTTP-only..." --- §4.2: > This requires a > controlled way to indicate which fronting ferver is acceptable by the > hidden service. Nit: "...server..." --- §7: > Thanks to Stephen Farrell, Martin Rex Martin Thomson > and employees of the UK National Cyber Security Centre for their > reviews. I think you're missing a comma between the two Martins. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-tls13-vectors-06: (with COMMENT)
On 7/30/18 6:13 PM, Martin Thomson wrote: On Tue, Jul 31, 2018 at 8:33 AM Adam Roach wrote: This doesn't parse. Probably should say "...through the use of labels..." or something similar. [...] I'm not sure what to make of this. Should it say "...private RSA keys for this example..." or something like that? It may also be useful to include a sentence or clause explaining why the omitted private key is not useful for users of this document. The private keys for certificates weren't included (as you noticed, the key exchange keys are). Both fixed in https://github.com/tlswg/draft-ietf-tls-tls13-vectors/commit/ca4896c7a3b3cc6d214a1e6fe94b64ba1b1230e8 Thanks! /a ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Adam Roach's No Objection on draft-ietf-tls-tls13-vectors-06: (with COMMENT)
Adam Roach has entered the following ballot position for
draft-ietf-tls-tls13-vectors-06: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/
--
COMMENT:
--
Thanks for all the work that went into this document. I think it's very useful
to have a set of test vectors for future implementations to develop against. I
have a couple of minor comments.
---
§1:
> Note: Invocations of HMAC-based Extract-and-Expand Key Derivation
> Function (HKDF) [RFC5869] are not labelled, but can be identified
> through the use the labels used by HKDF.
This doesn't parse. Probably should say "...through the use of labels..." or
something similar.
---
§6:
> Note that private keys for this
> example are not included in the draft.
>
> {client} create an ephemeral x25519 key pair:
>
> private key (32 octets):...
I'm not sure what to make of this. Should it say "...private RSA keys for this
example..." or something like that? It may also be useful to include a sentence
or clause explaining why the omitted private key is not useful for users of this
document.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adam Roach's Yes on draft-ietf-tls-record-limit-02: (with COMMENT)
On 4/4/18 1:44 AM, Martin Thomson wrote: Hi Adam, Thanks for the review. You picked up on something that was a little sloppy there. PR: https://github.com/tlswg/tls-record-limit/pull/19 On Wed, Apr 4, 2018 at 3:58 PM, Adam Roach <a...@nostrum.com> wrote:> Adam Roach has entered the following ballot position for §4: MUST NOT send a value higher than the protocol-defined maximum record size unless explicitly allowed by such a future version or extension. Presumably, recipients MUST gracefully accept values higher than the maximum record size? That is implied by this text (and the text that follows), but given how TLS frequently aborts connections at the first sign of any irregularity, it's probably worth saying explicitly. I thought that the following text was doing precisely that: A server MUST NOT enforce this restriction; a client might advertise a higher limit that is enabled by an extension or version the server does not understand. It would, if it were present. The IESG is reviewing version -02 of the document, in which that text does not appear. (I see it's in your repo, so presumably the -03 version will address the issue I highlight). A client can enforce the restriction, because it knows the entire set of possible extensions that determine the maximum size. I'll concede that it's a little sloppy in that it doesn't explicitly say whether a client is expected to police the value. Is that a change you would like to see? As in: A client MAY abort the handshake with an illegal_parameter alert if the record_size_limit extension includes a value greater than the maximum record size permitted by the negotiated protocol version and extensions. Note that this wasn't made a MUST because if there is an extension that raises the limit, the client has to do a second pass over the extensions and that's awkward. I'm okay both with and without the change. What I really wanted was text equivalent to what you quote above. §4: a DTLS endpoint that receives a record larger than its advertised limit MAY either generate a fatal "record_overflow" alert or discard the record. I'm concerned about the interaction between the option to discard the record and protocols that perform retransmission of lost packets over DTLS (e.g., proposals such as draft-rescorla-quic-over-dtls). In the case that an oversized packet is simply discarded, retransmissions of that (presumably still oversized) packet will take a while to time out (I'm not particularly well-versed in QUIC, but assume it has characteristics similar to TCP's ~nine-minute timeout), which would result in really bad user experiences. Is there rationale for this optionality? It would seem to be cleaner if the response were simply to always send a fatal error. The problem is that you only want to abort if you decrypt the record. DTLS doesn't kill connections if it receives junk. Ah, okay. That makes perfect sense. Under such circumstances, I agree that dropping such packets seems to be the least bad path. No document change is necessary, although I wouldn't object if you added an explanation to the document that says exactly what you say above. /a ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Adam Roach's Yes on draft-ietf-tls-record-limit-02: (with COMMENT)
Adam Roach has entered the following ballot position for draft-ietf-tls-record-limit-02: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ -- COMMENT: -- Thanks to everyone who contributed work towards this document. --- §4: > MUST NOT send a value higher than the protocol-defined maximum record > size unless explicitly allowed by such a future version or extension. Presumably, recipients MUST gracefully accept values higher than the maximum record size? That is implied by this text (and the text that follows), but given how TLS frequently aborts connections at the first sign of any irregularity, it's probably worth saying explicitly. --- §4: > a DTLS endpoint that > receives a record larger than its advertised limit MAY either > generate a fatal "record_overflow" alert or discard the record. I'm concerned about the interaction between the option to discard the record and protocols that perform retransmission of lost packets over DTLS (e.g., proposals such as draft-rescorla-quic-over-dtls). In the case that an oversized packet is simply discarded, retransmissions of that (presumably still oversized) packet will take a while to time out (I'm not particularly well-versed in QUIC, but assume it has characteristics similar to TCP's ~nine-minute timeout), which would result in really bad user experiences. Is there rationale for this optionality? It would seem to be cleaner if the response were simply to always send a fatal error. If this optionality is retained, please at least consider adding text describing the impact of discarding oversized packets when used with a reliable protocol. --- §4.1: > In TLS 1.2, block ciphers allow between 1 and 256 octets of padding. nit: The formulation "between X and Y" is ambiguous as to whether X and Y are included in the range. Consider rephrasing as "...from 1 to 256...". ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Adam Roach's Yes on draft-ietf-tls-iana-registry-updates-04: (with COMMENT)
Adam Roach has entered the following ballot position for
draft-ietf-tls-iana-registry-updates-04: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/
--
COMMENT:
--
Thanks for the work everyone put in on this document. I have a handful of
comments, ranging from nits to minor issues. They appear in document order.
---
Title:
Please expand "TLS" and "DTLS" in the title. See
https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.
---
Abstract:
Please include the list of updated RFCs in the abstract. See
<https://www.ietf.org/standards/ids/checklist/> §3.1.D. The current formulation
of "This document updates many (D)TLS RFCs (see updates header)" is problematic
due to the factors described in the final paragraph of RFC 7322 §4.3.
---
§2:
> Instead of listing the changes and their rationale in this,
> the introductory, section each section provides rationale for the
> proposed change(s).
There's something awkward with the commas here. Perhaps you mean:
> Instead of listing the changes and their rationale in this,
> the introductory section, each section provides rationale for the
> proposed change(s).
---
§8:
This section doesn't indicate anything about the disposition of
"token_binding," which is due to (potentially) expire in 11 months. Given that
the temporary property of this registration is due only to the previous policy
that this document is obsoleting, it seems that this document should instruct
IANA to remove the temporary status from the "token_binding" TLS ExtensionType.
---
§8:
The table that adds a "Recommended" column to the TLS ExtensionType does not
indicate values for "token_binding" or "cached_info." I suggest either adding
them, or adding text to explain their omission.
---
§9:
> assigned via Specification Required {{RFC8126}}. Values with the
> first byte 255 (decimal) are reserved for Private Use {{RFC8126}}.
Nit: the "{{...}}" citation style is probably not what you intended.
---
§13:
> o A "Recommended" column to the TLS Exporter Label registry. The
> table that follows has been generated by marking Standards Track
> RFCs as "Yes" and all others as "No".
No rows are marked "No." Presumably, the text above should instead say "any
values not indicated in the table below [will be/have been] marked 'No'"
---
§14:
> 120 no_application_protocol Y [RFC7301]
Every other updated table is amended to also point to this document. I presume
that omitting it from this entry is an oversight, and that it should instead be:
> 120 no_application_protocol Y [RFC7301] [RFCthis]
---
§17:
> o [SHALL update/has updated] the TLS HashAlgorithm Registry to list
> values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry
> to list values 4-223 as "Reserved".
HashAlgorithm 8 is already assigned, as are SignatureAlgorithms 7 and 8.
Presumably the reserved ranges should be "7 and 9-223" and "4-6 and 9-223",
respectively.
---
§17:
> Despite the fact that the HashAlgorithm and SignatureAlgorithm
> registries are orphaned, it is still import to warn implementers of
nit: "important"
> pre-TLS1.3 implementations about the dangers of blinding implementing
nit: "blindly"
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adam Roach's Yes on draft-ietf-tls-tls13-26: (with COMMENT)
On 3/7/18 12:58 PM, Eric Rescorla wrote:
> As a rule of thumb, "that" is used to start restrictive clauses
("Two doors
> are in front of you. The door that is on the right leads outside"),
while
> "which" is used to start non-restrictive clauses ("The only door in
the room,
> which is made of wood, leads outside.") This document uses "which"
where "that"
> is called for in numerous locations. Although there are several more
than listed
> below, I'm highlighting the locations where a literal reading of "which"
> technically leads to ambiguity. Each instance has a leading line for
context
> (except those that occur at the beginning of a paragraph).
I appreciate that many people hold to this rule of thumb, but it is,
unfortunately, an invented rule:
http://itre.cis.upenn.edu/~myl/languagelog/archives/000918.html
http://itre.cis.upenn.edu/~myl/languagelog/archives/001461.html
There is an old myth that which is not used in integrated relative
clauses (e.g. something which I hate) and that has to be used instead
something that I hate). It is completely untrue. The choice between
the two is free and open.
We're going to have to agree to disagree on this point. It's your
document and this is merely editorial, so your preference stands here.
/a
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adam Roach's Yes on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)
On 2/6/18 9:28 PM, Viktor Dukhovni wrote: On Feb 6, 2018, at 10:19 PM, Adam Roach <a...@nostrum.com> wrote: Unless I missed something important, this scenario doesn't seem to make much sense: if the client provides name A and the server replies with name B, the client either (1) isn't performing server name validation (in which case it is nonsense for the client to ask for a dnssec_chain), or (2) is going to error out the connection. Do I have that right? If there's some situation in which the server acting as described above provides some benefit, I would love to see it described in here. If it's just a matter of having completely described behavior for corner cases, it may be worthwhile indicating that the client will reject the connection if the server decides to complete the handshake like this. DANE clients sometimes accept more than one name for the server. This happens when the server name is obtained indirectly from MX OR SRV records, or as the result of (DNSSEC-validated) CNAME expansion. Ah, that's an interesting point. You may want to keep this in mind when responding to the question put forth by the GEN-ART reviewer. So in principle, more than one name might be acceptable to the client. In practice however, I don't yet see a mechanism where a client that can't do DNSSEC validation on its own would be in a position to do this. My understanding is that this mechanism isn't just for clients that can't do their own DNSSEC validation; it's also intended to reduce latency for interactive applications (web browsers and real-time-communication clients in particular). So the server may indeed be able to validate a certificate for some name that the client did not expect, and it would then be up to some external mechanism (prompt the user?) to accept that name or not. It is not entirely unreasonable to allow the client that freedom, but it would likely not be a mainstream mode of operation. Perhaps I am not thinking creatively enough about other ways for the client to be configured security to accept one of many names for the server, and to "guess" the wrong one. I think we're in the same boat here. :) /a ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Adam Roach's Yes on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)
Adam Roach has entered the following ballot position for draft-ietf-tls-dnssec-chain-extension-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ -- COMMENT: -- I like this mechanism and look forward to its deployment. I have one point of clarification and a small handful of editorial comments. First, the point of clarification: §4: > if the server does not recognize the > provided name and wishes to proceed with the handshake rather than to > abort the connection, the server uses the domain name associated with > the server IP address to which the connection has been established. Unless I missed something important, this scenario doesn't seem to make much sense: if the client provides name A and the server replies with name B, the client either (1) isn't performing server name validation (in which case it is nonsense for the client to ask for a dnssec_chain), or (2) is going to error out the connection. Do I have that right? If there's some situation in which the server acting as described above provides some benefit, I would love to see it described in here. If it's just a matter of having completely described behavior for corner cases, it may be worthwhile indicating that the client will reject the connection if the server decides to complete the handshake like this. --- > Intended status: Standards Track R. Barnes > Expires: July 27, 2018 Mozilla s/Mozilla/Cisco/ --- §1: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. This document has significant usage of these terms in lowercase. Please consider using the boilerplate from RFC 8174 instead. --- §3.3: > the case in DANE in which a client either ignores the name in > certificate (as specified in [RFC7671] or there is no attestation of Nit: "...in the certificate..." Nit: Add closing paren after [RFC7671] --- §4: > specific processing needed for aliases and wildcards. If DNS > responses messages contain any domain names utilizing name Nit: "response" ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)
On 5/23/17 9:33 PM, Daniel Migault wrote: The current version does not consider that proposing the cipher suites of the document implicitly assumes the client supports TLS1.2. Really? Can you clarify the meaning of the following passage? Because I can't read it in any way other than to contradict your assertion above: A server receiving a ClientHello and a client_version indicating (3,1) "TLS 1.0" or (3,2) "TLS 1.1" and any of the cipher suites from this document in ClientHello.cipher_suites can safely assume that the client supports TLS 1.2 and is willing to use it. /a ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Adam Roach's No Objection on draft-ietf-tls-ecdhe-psk-aead-04: (with COMMENT)
Adam Roach has entered the following ballot position for draft-ietf-tls-ecdhe-psk-aead-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ -- COMMENT: -- I agree with EKR's discuss -- specifying semantics for these ciphersuites with TLS 1.0 and 1.1 is a material change, and the proposed mechanism (in which servers are encouraged to infer 1.2 support even in the absence of explicit indication) is a bit baffling. Given the scope this document covers, I recommend adding "1.2" to the title of the document. (e.g.: "ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security Version 1.2 (TLS 1.2)") ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
