Re: [TLS] AD Evaluation of draft-ietf-tls-dtls13-39
Ben, Thanks for your review. > I made a pull request with editorial/nit-level stuff at > https://github.com/tlswg/dtls13-spec/pull/160 (though some editorial > issues remain mentioned here where there is a lot of flexibility in how > to resolve them). I will take a look at these. > I think there are probably some DTLS-specific "implementation pitfalls" > that might merit a section akin to RFC 8446's Appendix C.3. > > I also mention in the per-section comments a few places where we should > say a bit more about how we diverge from RFC 8446, and a few places > where being more explicit about separate read and write epochs would be > helpful. > > Section 1 > >1.2 (see Appendix D of [TLS13] for details). While backwards >compatibility with DTLS 1.0 is possible the use of DTLS 1.0 is not >recommended as explained in Section 3.1.2 of RFC 7525 [RFC7525]. > > I guess we might want to reference draft-ietf-tls-oldversions-deprecate > by the time we hit the RFC Editor's queue. https://github.com/tlswg/dtls13-spec/pull/163 > Section 2 > >- connection: A transport-layer connection between two endpoints. > > Can there even be a datagram "connection"? > > Regardless, we should define "association" since we use that as well. > >- handshake: An initial negotiation between client and server that > establishes the parameters of their transactions. > > This is the only place in the document where we use the word > "transaction", which makes me suspect that it is not the best word > choice. > >- session: An association between a client and a server resulting > from a handshake. > > This seems technically true, but could be confusing if we want to have > an analogy DTLS Session:TLS Session::DTLS Association:TLS Connection. > (Per the previous comments, I am not 100% sure that we are trying to > have that anaolgy, though.) Sure. I think the original intent was to be as you say, but things may have gotten muddled. https://github.com/tlswg/dtls13-spec/pull/164 > Section 3.4 > >DTLS optionally supports record replay detection. The technique used >is the same as in IPsec AH/ESP, by maintaining a bitmap window of > > Do we want a reference for the IPsec usage? (We do reference > https://tools.ietf.org/html/rfc4303#section-3.4.3 from §4.5.1 when we > talk about the mechanics of the replay window.) I don't think it's necessary here. >Applications may conceivably detect duplicate packets and accordingly >modify their data transmission strategy. > > The text here doesn't give me a clear impression of whether the > application is supposed to use the DTLS sequence numbers for this > detection, or their own (application layer) information. (I didn't > think that most DTLS implementations exposed an API to give the > application the record sequence number.) Is there a reason we need to weigh in on this? We don't generally take a position on this kind of API issue. > Section 4 > >ProtocolVersion legacy_record_version; > > We should probably say what value(s) are allowed here, akin to the RFC > 8446 "MUST be set to 0x0303 for all records [...] other than an initial > ClientHello". https://github.com/tlswg/dtls13-spec/pull/165 >Fixed Bits: The three high bits of the first byte of the > DTLSCiphertext header are set to 001. > > Do we want to say something about why we have fixed bits and all and how > the values were chosen (perhaps a reference to RFC 7983)? https://github.com/tlswg/dtls13-spec/pull/165 >If a connection ID is negotiated, then it MUST be contained in all >datagrams. Sending implementations MUST NOT mix records from >multiple DTLS associations in the same datagram. If the second or >later record has a connection ID which does not correspond to the >same association used for previous records, the rest of the datagram >MUST be discarded. > > I'm failing to come up with a reason why you would directly want to use > CIDs (for the same association) for records in a single datagram; should > we recommend using a single CID value per datagram explicitly? This was litigated extensively on-list with the outcome you see here. The short version is that eliding the CID in subsequent records means that it is not covered by the AEAD which covers the header. See the thread starting here: https://mailarchive.ietf.org/arch/msg/tls/zEnIvS3yf-Gov6P0_yqCh_ZOwJk/ > >The entire header value shown in Figure 4 (but prior to record number >encryption) is used as as the additional data value for the AEAD > > Maybe forward-reference §4.2.3 for the record-number encryption? Fixed in https://github.com/tlswg/dtls13-spec/commit/62847c4570a41a78e740b2d804b29f81714448b5 > >The entire header value shown in Figure 4 (but prior to record number >encryption) is used as as the additional data value for the AEAD >function. For instance, if the minimal variant is used, the AAD is 2 >octets long. Note that
Re: [TLS] TLS Flags Open Question
On Sat, Dec 5, 2020 at 6:31 PM Eric Rescorla wrote: > > > On Sat, Dec 5, 2020 at 7:05 AM Yoav Nir wrote: > >> Hi. >> >> At IETF 108 a question was raised about The TLS Flags extension. What >> payloads on the server side can include this extension? >> >> The “candidates” are ServerHello, EncryptedExtensions, Certificate, and >> NewSessionTicket. >> > Should CertificateRequest be in that list? By the way, the text for section 3 might need tweaking. The rules for request vs. response extensions are almost client/server, but not quite. Probably better to cite or adapt the text in RFC8446, section 4.2. > The only one that is controversial here (I think) is ServerHello, because >> it is not encrypted. Looking at the current list of extensions, I see that >> only 6 can go in ServerHello: >> >>- password_salt >>- tls_cert_with_extern_psk >>- supported_ekt_ciphers >>- pre_shared_key >>- supported_versions >>- key_share >> >> >> Of those, only one would be (if it hadn’t already been standardized) a >> candidate for the TLS-Flags extension: tls_cert_with_extern_psk. The RFC >> describes it with “The “tls_cert_with_extern_psk" extension is >> essentially a flag to use the external PSK in the key schedule”. I >> don’t think it’s unreasonable to think that at some point there’s going to >> be another flag-like extension that will need to be signalled in >> ServerHello. >> >> So the question for the group is, do we allow the flags extension (and >> the flags themselves) to be in ServerHello, or do we prohibit them for now, >> and if ever an extension does need to signal in ServerHello, it can update >> the TLS-Flags RFC at that time? >> >> My vote would be to allow it in all places, and trust the process not to >> place flags that should be encrypted in payloads that aren’t, but either >> way, we need working group consensus. >> > > I agree with you that this is the right outcome. > I also agree. I suspect it doesn't hugely matter since ServerHello carries response messages. Until and unless we define a ServerHello flags extension, the no unsolicited extensions rule and the no empty flags rule mean ServerHello flags are effectively prohibited unless the client implements such an extension. So that means we can punt to TLS-flags RFC. (Whereas I think we'll need to sort out CertificateRequest now to avoid compat issues.) But it's easy to allow it now, and saves us having to think about whether it's safe to do later. David ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
