[TLS] RFC 8773 on TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key
A new Request for Comments is now available in online RFC libraries. RFC 8773 Title: TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key Author: R. Housley Status: Experimental Stream: IETF Date: March 2020 Mailbox:hous...@vigilsec.com Pages: 11 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-tls-tls13-cert-with-extern-psk-07.txt URL:https://www.rfc-editor.org/info/rfc8773 DOI:10.17487/RFC8773 This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre-shared key (PSK). This document is a product of the Transport Layer Security Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13
Hi Jonathan, > In Section 7.1, the 2nd bullet following para 1 reads: "When they > receive a message or fragment which is out of order, either because it > is not the next expected message or because it is not the next piece > of the current message. Implementations MUST NOT send ACKs for > handshake messages which they discard as > out-of-order, because otherwise those messages will not be retransmitted." > This is confusing as the difference between "out of order" messages > that require an ACK and those that do not is not quite clear. Also the > term "out of order" is written in two ways in this paragraph. On second read, I agree that this is confusing. The point is that while, to my understanding, out-of-order messages should trigger the transmission of an ACK acknowledging what has been processed so far, the out-of-order messages themselves must not be included in those ACKs unless they have been buffered. In more detail, there are two kinds of feedback signals from the handshake layer to the record layer: 1. Signal whether there is some disruption in the incoming flight which the peer should be informed about via an ACK of those messages received and processed so far. That's what the first sentence in the above quote is about. 2. Signal whether a handshake message has been processed. That's what the second sentence in the above quote is about, which can also be rephased as follows: An ACK must only be sent for those records which consist of handshake messages each of which has been signalled as processed by the handshake layer. In particular, in situations where a single record contains multiple handshake messages/fragments, and the implementation processes only some of them, the record must not be acknowledged. A real-world example for this would be an implementation which supports out-of-order buffering but only contiguous reassembly: If the initial fragment of a HS message gets sent in one record which is lost, and the final fragment together with a subsequent handshake message is sent in another record, then this latter record must not be ACKed if the stack drops the fragment. Unbuffered out-of-order handshake messages do trigger signal 1, but they don't trigger signal 2. At least, that's my understanding. Best, Hanno From: TLS on behalf of Jonathan Hammell Sent: Friday, March 27, 2020 5:10 PM To: Sean Turner Cc: TLS List Subject: Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13 I know that this WGLC was supposed to focus on the diff between -34 and -37. I don't have any comments on that diff, but I do have some comments on the draft following a re-read of the entire document. # Minor The term "deprotection" is used twice in document but never defined. Section 5.11 abandoning vs destroying association. In the document we see the term "abandon" being used, referring to associations. However section 5.11 states that a server "MUST NOT destroy the existing association" and then further along it states that "the server MUST abandon the previous association". Do abandon and destroy mean the same thing? In Section 7, what does "handshake-containing" mean in the phrase "The ACK message is used by an endpoint to indicate handshake-containing..."? In Section 7, what does "non-duplicative" mean in phrase "Implementations MUST NOT acknowledge records containing non-duplicative handshake messages..."? In Section 7.1, the 2nd bullet following para 1 reads: "When they receive a message or fragment which is out of order, either because it is not the next expected message or because it is not the next piece of the current message. Implementations MUST NOT send ACKs for handshake messages which they discard as out-of-order, because otherwise those messages will not be retransmitted." This is confusing as the difference between "out of order" messages that require an ACK and those that do not is not quite clear. Also the term "out of order" is written in two ways in this paragraph. In Figure 10, the edge going from SENDING to FINISHED has no label to differentiate with edge to WAITING. Should it read: "send last flight"? In Figure 13, why is there no NewConnectionID message in the exchanges since new CIDs are offered? Also, a short explanation of the CID negotiation and exchange could be helpful in the text. The state machine in Figure 10 is somewhat puzzling. How do we differentiate between "Receive ACK for last flight" and "Receive last flight"? According to Figure 7, for example, the last ACK is a flight itself. Also, with respect to the client, if sending last flight takes him to finished state, how will he then receive the ACK for his final flight? # Nits Section 3.1 Packet Loss. Figure 1 is a little confusing since it resembles Figure 5; as each has the server sending a HelloRetryRequest. Might illustrate the concept better to have the server send a ServerHello in Figure 1 rather than a
Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13
Hi Jonathan, Thanks for carefully reading the spec and for your feedback. Let me quickly respond to some of your comments. -Original Message- From: TLS On Behalf Of Jonathan Hammell Sent: Friday, March 27, 2020 6:10 PM To: Sean Turner Cc: TLS List Subject: Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13 I know that this WGLC was supposed to focus on the diff between -34 and -37. I don't have any comments on that diff, but I do have some comments on the draft following a re-read of the entire document. # Minor The term "deprotection" is used twice in document but never defined. [Hannes] Looking at the text I believe we can just remove the term. Here is the PR: https://github.com/tlswg/dtls13-spec/pull/129 ~snip~ # Nits Section 3.1 Packet Loss. Figure 1 is a little confusing since it resembles Figure 5; as each has the server sending a HelloRetryRequest. Might illustrate the concept better to have the server send a ServerHello in Figure 1 rather than a HelloRetryRequest? [Hannes] I changed Figure 1, as suggested. Note, however, there is nothing wrong with the figures as they are because these two sections describe different concepts. Figure 1 talks about packet loss and retransmissions while Figure 5 is about the cookie exchange. PR is here: https://github.com/tlswg/dtls13-spec/pull/130 and for the wording changes below I have created another PR here: https://github.com/tlswg/dtls13-spec/pull/131 Section 5.1. para 3 - Typo. "The DTLS 1.3 specification changes the way how cookies are exchanged compared to DTLS 1.2. DTLS 1.3 re-uses the HelloRetryRequest message". The "... the way how cookies..." either use "how" or "the way" but not both. [Hannes] OK. Page 9 last para - Typo. s/assocatiation/association [Hannes] Fixed. In section 3, bullet #3, the term "flight" is used without being defined; a reference to section 5.6 would be nice. [Hannes] I changed the sentence to omit the term 'flight' to avoid the forward reference to Section 5.6 in the overview. MSL is used first in section 4.2.1 but only defined in section 5.7.1 [Hannes] I added MSL to the terminology section. In section 5.11 the notion of "CID concept" is mentioned. Might be nice to refer to section 9.1 where an example of the concept is presented. Also, section 9.1 never mentions "CID concept"; might be good to add the term to know that we are talking about the same thing. [Hannes] I removed the term concept and added a sentence to the terminology. In Section 6.1, the phrase "...loss and re-order an identifier is needed to determine..." could use a comma after "re-order" and possibly replace "re-order" with "re-ordering". [Hannes] Ok. In Section 6.1, the phrase "In addition to the key derivation steps described in Section 7 of [TLS13] triggered by the states during the handshake a sender may want to rekey at any time during the lifetime of the connection and has to have a way to indicate that it is updating its sending cryptographic keys" is long and difficult to follow. It could be rephrased as "In addition to the key derivation steps described in Section 7 of [TLS13], a sender may want to rekey at any time during the lifetime of the connection. The epoch value provides a means to indicate that the sender is updating its sending cryptographic keys." [Hannes] I re-worded the sentence. In Section 6.1, replace "For example, client incorrectly uses..." with "For example, if a client incorrectly uses..." [Hannes] OK. In Section 7, the term "current key" is used in the phrase "Implementations SHOULD simply use the current key." Would it be clearer to say that "Implementations SHOULD use the key material of the current epoch"? [Hannes] Fine for me. Section 11, second para, s/Even with such a test, An/Even with such a test, an [Hannes] Fixed. Section 11, third bullet: the statement "...DTLS 1.3 records irrespectively of the use of a CID" could be rephrased as "...DTLS 1.3 records irrespective of whether a CID is used or not." [Hannes] Fixed. Ciao Hannes On Fri, Mar 20, 2020 at 10:18 AM Sean Turner wrote: > > This is the third working group last call for the "The Datagram > Transport Layer Security (DTLS) Protocol Version 1.3" draft available > at https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/. Please > review the document and send your comments to the list by 2359 UTC on > 27 March 2019. > > This is a targeted one-week WGLC intended to focus on the changes from -34, > which was the subject of the second working group last call, and -37. The > diffs between -34 and -37 can be found at: > https://www.ietf.org/rfcdiff?url1=draft-ietf-tls-dtls13-34=draft- > ietf-tls-dtls13-37 As you will see in the diffs, the changes include > 2119-language related changes in s5.1 and s7. These two changes were > introduced in -35, which was post in November. > > Note the the GH repo for this draft can be found at: > https://github.com/tlswg/dtls13-spec > > Thanks, > Chris, Joe, and
[TLS] Weekly github digest (TLS Working Group Drafts)
Issues -- * tlswg/draft-ietf-tls-external-psk-importer (+1/-0/0) 1 issues created: - Clarify MUSTs (by chris-wood) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/26 * tlswg/dtls13-spec (+1/-0/2) 1 issues created: - Improve ACK advice (by ekr) https://github.com/tlswg/dtls13-spec/issues/128 1 issues received 2 new comments: - #128 Improve ACK advice (2 by rtatnet) https://github.com/tlswg/dtls13-spec/issues/128 Pull requests - * tlswg/draft-ietf-tls-esni (+2/-1/14) 2 pull requests submitted: - Bind CHOuter to CHInner (by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/pull/212 - Remove OPEN ISSUE regarding an explicit ECHO negotiated signal. (by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/pull/211 1 pull requests received 14 new comments: - #209 padding scheme text (14 by chris-wood, davidben, sayrer, sftcd) https://github.com/tlswg/draft-ietf-tls-esni/pull/209 1 pull requests merged: - Remove OPEN ISSUE regarding an explicit ECHO negotiated signal. https://github.com/tlswg/draft-ietf-tls-esni/pull/211 * tlswg/draft-ietf-tls-external-psk-importer (+2/-0/1) 2 pull requests submitted: - Editorial pass to simplify text and unify terminology. (by chris-wood) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/28 - Clarify single hash function requirements. (by chris-wood) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/27 1 pull requests received 1 new comments: - #27 Clarify single hash function requirements. (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/27 Repositories tracked by this digest: --- * https://github.com/tlswg/draft-ietf-tls-semistatic-dh * https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/tls-flags * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/sniencryption * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/draft-ietf-tls-grease ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
