Re: [TLS] 2nd WG Last Call for draft-ietf-tls-dtls-rrc
Hi Marco, On Mon, 9 Oct 2023 at 14:53, Marco Tiloca wrote: > Thank you, the PR looks good me! Cool, we'll merge it then, and publish an updated version soon. > Right, I was thinking of spelling out how the initiator should behave if the > responder does not comply with the specification. > > If that can be excluded altogether or a safe behavior at the responder is > obvious/implied, then the current text is just fine. Thanks for clarifying your point. It looks to me that your concern is more about the quality of implementations rather than strict protocol requirements. So, for now, I think it's safe to leave §7.* as-is. cheers & thanks again! ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 2nd WG Last Call for draft-ietf-tls-dtls-rrc
Hi Marco, We think we have addressed all your comments (but one, see below). Could you please check that the PR at [1] is good to go? [1] https://github.com/tlswg/dtls-rrc/pull/63/files The one comment we wanted to have a bit more discussion before deciding how to proceed is this: On Tue, 3 Oct 2023 at 15:50, Marco Tiloca wrote: > [Section 7.4] > > * I think that another requirement should be that the initiator MUST NOT act > on more than one valid path_response or path_drop message for each > path_challenge message that it has sent. §7.4 currently says: "The responder MUST send exactly one path_response or path_drop message for each received path_challenge." So it's not clear how a situation with multiple occurrences of path_drop/path_challenge could come off, if the responder obeys the specified MUST? Could you clarify your concern a bit more? > [Section 10] > > * You will need to add a new subsection that provides expert review > instructions, for the Designated Experts assigned to the new subregistry > defined in Section 10.3. Thanks: this made us realise that expert review was a bit too lightweight, therefore we moved to STD required. cheers, thanks! ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] 2nd WG Last Call for draft-ietf-tls-dtls-rrc
Hi Marco, Thanks very much for the thorough review. Really appreciate it. Your comments are tracked at https://github.com/tlswg/dtls-rrc/issues/62 Cheers, thank you! On Tue, 3 Oct 2023 at 15:50, Marco Tiloca wrote: > > Hi all, > > Thanks for this document! I think it's good and well written. > > Please see below some minor comments. > > Best, > /Marco > > > > [Section 1] > > * "selecting a security context of an incoming DTLS record" > >I think you mean "selecting a security context for processing an incoming > DTLS record" > > * I think that the text would read better if you swap the two following > blocks of text: > >"A CID is an identifier carried in ... for DTLS 1.3." > >and > >"Without CID, if the ... and negotiated" > >hence introducing the concept of CID before using it. > > * "Section 6 of [RFC9146] describes how ..." > >Aren’t such considerations applicable also to DTLS 1.3? If so, it’s worth > mentioning. > > * "This is done in order to provide more confidence to the receiving peer > that the sending peer is reachable at the indicated address and port." > >I guess you mean: "the latest indicated address and port" > > * "that a peer is still in possession of its address" > >Similar to the previous comment, this can be: "is still reachable to its > last known address" > > * "if RRC has been successfully negotiated" > >It should be: "if the use of RRC has been successfully negotiated", also > consistent with the beginning of Section 3. > > * That last paragraph uses both "peer" and "endpoint", apparently > interchangeably. Is there any reason to not use only one of the two words? > Earlier in the section, only "peer" is used. > >Later in the document, "endpoint" is also used. Maybe add a note in > Section 2 about the equivalence of the two terms? > > > [Section 4] > > * "Implementations MUST be able to parse and ignore messages with an unknown > msg_type." > >Right, at the same time the intention should be that, if a peer uses RRC, > then it MUST support all the three message types defined in this document. > It's worth stating it explicitly. > > > [Section 5] > > * "that has the source address of the enclosing UDP datagram different from > the one currently associated" > >Couldn't (also) the source port number have changed? If so, I think you > mean: "that has the source address and/or source port number of the enclosing > UDP datagram different from what is currently associated" > > * "the receiver SHOULD perform a return routability check as described in > Section 7, unless an application layer specific address validation mechanism > can be triggered instead." > >As an example of alternative mechanism that can be triggered, it's worth > mentioning RFC 9175, which describes the exchange of a CoAP response and a > follow-up CoAP request, both including a CoAP Echo option with value set by > the server sending the response. > >Besides allowing the server to assert the freshness of the follow-up > request, this exchange provides validation of the claimed address of the > client sending the request. > > > [Section 6.1] > > * "(e.g., a CoAP server returning an MTU's worth of data from a 20-bytes GET > request) > >It's worth referring to RFC 7252 and to > https://datatracker.ietf.org/doc/draft-irtf-t2trg-amplification-attacks/ > > > [Section 6.2] > > * In figure 5, the arrow for message 2 (path-drop) should not be > bidirectional, but rather only from the sender to the receiver. > > > [Sections 7.1 and 7.2] > > * s/The receiver creates/The receiver, i.e., the initiator creates > > * s/The peer endpoint/The other peer, i.e., the responder, > > > [Section 7.4] > > * I think that another requirement should be that the initiator MUST NOT act > on more than one valid path_response or path_drop message for each > path_challenge message that it has sent. > > > [Section 10] > > * You will need to add a new subsection that provides expert review > instructions, for the Designated Experts assigned to the new subregistry > defined in Section 10.3. > > > [Nits] > > Section 1 > - s/i.e./i.e., > - s/a variety reasons/a variety of reasons > > Section 4 > - s/path_response and/path_response, and > -s/a 8-byte/an 8-byte > > Section 6 > - s/Note that in general,/Note that, in general, > - s/verification due to/verification, due to > - s/Figure 2: Attackers capabilities/Figure 2: Attacker's capabilities > > Section 6.1 > - s/injecting and racing it/injecting, and racing it > > Section 7 > - s/concerns, the need/concerns, and the need > > Section 7.2 > - s/i.e./i.e., > > Section 8 > - s/In the example/In the example of > - s/as well as the RRC/as well as for the use of the RRC > - s/been established the/been established, the > - s/interaction the IP/interaction, the IP > > > On 2023-09-18 23:03, Sean Turner wrote: > > This email starts the 2nd working group last call for "Return Routability > Check for DTLS
Re: [TLS] I-D Action: draft-ietf-tls-deprecate-obsolete-kex-03.txt
Hi, Maybe I am completely confused but It also looks like the "SHOULD NOT non-ephemeral ECDH" (second para of §2) is already in the "general guidelines" of RFC9325. If you want to reiterate the point (which is good), you could just reference it? cheers, t On Thu, 21 Sept 2023 at 17:13, Thomas Fossati wrote: > > Hi, > > It looks like the requirements in §2 and §3 regarding FFDH(E) update > the guidance given in RFC9325 (i.e., SHOULD NOT => MUST NOT). > > I guess this must be reflected in the "Updates" header. > > cheers, thanks > t > > On Thu, 21 Sept 2023 at 10:22, wrote: > > > > Internet-Draft draft-ietf-tls-deprecate-obsolete-kex-03.txt is now > > available. > > It is a work item of the Transport Layer Security (TLS) WG of the IETF. > > > >Title: Deprecating Obsolete Key Exchange Methods in TLS 1.2 > >Authors: Carrick Bartle > > Nimrod Aviram > >Name:draft-ietf-tls-deprecate-obsolete-kex-03.txt > >Pages: 20 > >Dates: 2023-09-21 > > > > Abstract: > > > >This document deprecates the use of RSA key exchange and Diffie > >Hellman over a finite field in TLS 1.2, and discourages the use of > >static elliptic curve Diffie Hellman cipher suites. > > > >Note that these prescriptions apply only to TLS 1.2 since TLS 1.0 and > >1.1 are deprecated by [RFC8996] and TLS 1.3 either does not use the > >affected algorithm or does not share the relevant configuration > >options. > > > > The IETF datatracker status page for this Internet-Draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/ > > > > There is also an HTML version available at: > > https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-03.html > > > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-deprecate-obsolete-kex-03 > > > > Internet-Drafts are also available by rsync at: > > rsync.ietf.org::internet-drafts > > > > > > ___ > > 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
Re: [TLS] I-D Action: draft-ietf-tls-deprecate-obsolete-kex-03.txt
Hi, It looks like the requirements in §2 and §3 regarding FFDH(E) update the guidance given in RFC9325 (i.e., SHOULD NOT => MUST NOT). I guess this must be reflected in the "Updates" header. cheers, thanks t On Thu, 21 Sept 2023 at 10:22, wrote: > > Internet-Draft draft-ietf-tls-deprecate-obsolete-kex-03.txt is now available. > It is a work item of the Transport Layer Security (TLS) WG of the IETF. > >Title: Deprecating Obsolete Key Exchange Methods in TLS 1.2 >Authors: Carrick Bartle > Nimrod Aviram >Name:draft-ietf-tls-deprecate-obsolete-kex-03.txt >Pages: 20 >Dates: 2023-09-21 > > Abstract: > >This document deprecates the use of RSA key exchange and Diffie >Hellman over a finite field in TLS 1.2, and discourages the use of >static elliptic curve Diffie Hellman cipher suites. > >Note that these prescriptions apply only to TLS 1.2 since TLS 1.0 and >1.1 are deprecated by [RFC8996] and TLS 1.3 either does not use the >affected algorithm or does not share the relevant configuration >options. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-03.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-deprecate-obsolete-kex-03 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > ___ > 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
Re: [TLS] [Uta] Question regarding RFC 8446
Hi Paul, all, I agree with Yaron: this looks like a (D)TLS profiling aspect that should be defined by the HL7 protocol. Cheers, t On 08/11/2022, 10:36, "Uta" wrote: > > Hi Paul, > > I'm actually not sure this is a good idea, and not because we are at > the RFC Editor. > > TLS has intentionally kept this aspect out of scope basically forever. > The following text appears in TLS 1.0 (Jan. 1999) and still appears > unchanged in TLS 1.3: > > "No part of this standard should be taken to dictate the manner in > which a usage profile for TLS manages its data transport, including > when connections are opened or closed." > > Given we left this behavior unspecified, it is no wonder that people > have differing implementations. I'm not sure it is appropriate for UTA > to make this decision for the whole industry and hundreds of protocols > that are layered on top of TLS. > > Thanks, Yaron > > On 08/11/2022, 10:05, "Uta on behalf of Paul Wouters" > wrote: > > On Mon, 7 Nov 2022, Eric Rescorla wrote: > > > Subject: Re: [TLS] Question regarding RFC 8446 > > > > Hi David, > > > > This question seems a bit out of scope for TLS, which is kind of > > indifferent to the transport interaction. > > > > Perhaps it might make sense to be in UTA, though unfortunately, > > RFC 7525-bis is in the editor queue now... > > I just talked to my fellow AD, and we are okay with a one > line/paragraph addition to 7525-bis if the document authors and > UTA chairs are okay with this as well. It seems a real interop > issue that would be good to nail down. > > Paul > > > -Ekr > > > > > > On Mon, Nov 7, 2022 at 1:37 AM David Barr > > wrote: How can I make suggestions for the TLS specifications? > > I'm having a problem that could be clarified by a change to the > > spec. This is the sentence that causes problems for me: "how to > > initiate TLS handshaking and how to interpret the authentication > > certificates exchanged are left to the judgment of the designers > > and implementors of protocols that run on top of TLS". > > > > I have two vendors that have implemented software that layers > > the HL7 protocol on top of TLS. The Epic implementation does not > > perform a handshake until it has data to send. This could be > > hours after the TCP connection is established. There is no other > > TCP communication prior to the handshake (e.g. a STARTTLS > > command). The Infor Cloverleaf implementation times out waiting > > for a handshake, and the software becomes unresponsive while > > this is happening. > > > > It would be helpful if the TLS spec added something like this: > > > > If protocols that are layered on top of TLS use implicit > > encryption (relying on a port number rather than an > > explicit command that is issued before the handshake), > > then the handshake should begin immediately after the > > TCP/IP socket connection is established. > > > > I have no idea how suggestions like this make it into the spec, > > so if I need to suggest this somewhere else, please let me know. > > > > David Barr > > > > ___ TLS mailing list > > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > > > > > > > > ___ Uta mailing list > u...@ietf.org https://www.ietf.org/mailman/listinfo/uta > > > ___ Uta mailing list > u...@ietf.org https://www.ietf.org/mailman/listinfo/uta > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Flags Extension: why only for TLS 1.3?
hi John, On Thu, Nov 4, 2021 at 1:11 PM John Mattsson wrote: > TLS 1.2 has been obsolete for over three years. Oxford dictionary defines > obsolete as "no longer produced or used; out of date." NIST requires > support of TLS 1.3 everywhere no later than Jan 2024, which at least in > theory means no negotiation of TLS 1.2. > > > > I think IETF, TLS WG, and TLS libraries should spend their time on TLS > 1.3 rather than giving the false idea it is ok to stay on TLS 1.2. > Whilst I agree on the general sentiment, let me point out that the specific extension we wanted to register (RRC) would be DTLS-only. And while deprecating TLS 1.2 is certainly OK since 8446 has been around for 3+ years, the deprecation of DTLS 1.2 would seem a tad premature absent a published RFC for 1.3 (*) cheers! (*) This is going to change soon, but it'll take time for implementations to catch up (**) (**) IoT is a vastly different space compared to telco and web. It is very fragmented with no real incumbents that could orchestrate a quick switchover. Also, because of the heterogeneity of platforms there is a very high number of purpose built stacks. So we need to be a bit more patient (***) (***) Nothing, just checking if you are still following me in this meander of recursive footnotes ;-) > John > > > > *From: *TLS on behalf of Hannes Tschofenig < > hannes.tschofe...@arm.com> > *Date: *Monday, 25 October 2021 at 19:12 > *To: *IETF TLS > *Subject: *[TLS] Flags Extension: why only for TLS 1.3? > > Hi all, > > > > why is the flags extension only defined for TLS 1.3? > > > > There is nothing in this extension that prevents us from using it also in > TLS 1.2. > > > > Could we make it also available to TLS 1.2? > > > > Ciao > > Hannes > > > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Thomas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS RRC and heartbeat
Rich, Hanno, Mohit, Thanks a lot for your excellent input. We are going to follow your advice and avoid overloading heartbeat then. Scope-wise, RRC will focus on path validation and liveliness use cases, leaving PMTU discovery out, at least for the moment. cheers, On Thu, Oct 21, 2021 at 4:45 PM Salz, Rich wrote: > >And we are not sure, if considering mainly implementation issues, will > justify to allocate a new code-point. > > As one of the three TLS registry experts, let me tell you not to be > worried about requesting a new codepoint. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Thomas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] DTLS RRC and heartbeat
Hi, Hannes, Achim and I are working on the DTLS return routability check (RRC) draft [1]. In the process, we realised that what we were building was heartbeat (RFC6520) just with a different name. If one looks at RFC6520's use cases [2], path MTU discovery and path liveliness are listed already. So we could update the existing RFC with a path validation use case and profile the probing algorithm to support the more subtle threat model that QUIC assumes, which we are reasonably sure we want to do. Enhancing the heartbeat mechanism with a "path validation" sub-protocol for DTLS seems quite logical (to us). This would be incremental work rather than reinventing the wheel. To us, this appears to be an attractive approach. One problem is - as Hannes put it - that heartbeat has a "somewhat tricky history", making its marketing a slightly intricate operation, and the code reuse story a bit more complicated than desired (see for example [3]). So, we are not entirely sure what we should do, and on Chris's suggestion we are bringing this to the group to ask for direction. Thanks in advance for any thought, opinion, ideas you may want to share with us. [1] https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls-rrc [2] https://www.rfc-editor.org/rfc/rfc6520#section-5 [3] https://github.com/openssl/openssl/pull/1928 -- Thomas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WG adoption call for draft-tschofenig-tls-dtls-rrc: redux
On 03/05/2021, 16:46, "Sean Turner" wrote: > Hi! > > We would like to re-run the WG adoption call for "Return Routability > Check for DTLS 1.2 and DTLS 1.3”. Please state whether you support > adoption of this draft as a WG item by posting a message to the TLS > list by 2359 UTC 24 May 2021. Please include any additional > information that is helpful in understanding your position. > > NOTES: > > 1) We are re-running this WG adoption now that DTLS 1.3 [1] and >Connection Identifiers for DTLS 1.2 [2] is done. > 2) Here is a link to the original WG adoption call [3]. > > Thanks, > Chris, Joe, and Sean > > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/ > [2] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ > [3] https://mailarchive.ietf.org/arch/msg/tls/IJYqpTmSHsCkiMaUPt_AltvKbe8/ +1 for adoption (the same considerations stated at the time of the previous CfA [0] hold.) [0] https://mailarchive.ietf.org/arch/msg/tls/ZoHz7u9SaCURvvJNaWLDlA9--YE/ IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Francesca Palombini's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
Hi Francesca, thank you for your review.
The ticket to track your review is:
https://github.com/tlswg/dtls-conn-id/issues/106
cheers!
On Tue, Apr 20, 2021 at 5:22 PM Francesca Palombini via Datatracker
wrote:
>
> Francesca Palombini has entered the following ballot position for
> draft-ietf-tls-dtls-connection-id-11: 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 DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/
>
>
>
> --
> COMMENT:
> --
>
> Thank you for the work on this document. I only have minor comments and nits
> below.
>
> Francesca
>
> 1. -
>
>sending messages to the client. A zero-length CID value indicates
>that the client is prepared to send with a CID but does not wish the
>server to use one when sending.
>
> ...
>
>to use when sending messages towards it. A zero-length value
>indicates that the server will send with the client's CID but does
>not wish the client to include a CID.
>
> FP: clarification question: I am not sure the following formulation is very
> clear to me: "to send with a(/the client's) CID". Could "send with" be
> rephrased to clarify? The previous paragraph uses "using a CID value", that
> would be better IMO.
>
> 2. -
>
>the record format defined in {{dtls-ciphertext} with the new MAC
>
> FP: nit - missing "}" in markdown.
>
> 3. -
>
>The following MAC algorithm applies to block ciphers that use the
>with Encrypt-then-MAC processing described in [RFC7366].
>
> FP: remove "with"
>
> 4. -
>
> Section 10.1
>
> FP: I believe you should specify 1. what allowed values are for this column
> (i.e. Y or N, and what they mean) and 2. what happens to the existing entries
> -
> namely that they all get "N" value.
>
> 5. -
>
> Section 10.2
>
> FP: Just checking - why is 53 "incompatible with this document"?
>
> 6. -
>
>Value Extension Name TLS 1.3 DTLS Only Recommended Reference
>
> FP: nit- s/DTLS Only/DTLS-Only to be consistent with 10.1
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
--
Thomas
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Robert Wilton's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
Hi Rob, Thank you for your review and suggestion. Your review is tracked here: https://github.com/tlswg/dtls-conn-id/issues/104 cheers, t On 19/04/2021, 11:34, "Robert Wilton via Datatracker" wrote: > -- > COMMENT: > -- > > Hi, > > I'm no DTLS expert, but I found the concepts/explanation in this > document easy to follow. > > I was slightly confused by the requirement to encode the length in > variable length CIDs, and had to read the relevant text a second time. > As a suggestion, it might help if these two sentences were reworded > the other way round: > > OLD: > Implementations that want to use >variable-length CIDs are responsible for constructing the CID in >such a way that its length can be determined on reception. Note >that there is no CID length information included in the record >itself. > > NEW: > Since the CID length information is not included in the record itself, > implementations that want to use ... . > > One minor question. In the contributors, I noted that Jana is listed > as being associated with Google, but it might be worth checking if > that is still accurate. > > Regards. > Rob IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Éric Vyncke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
Hi Éric, Thank you very much for your review, there's now a ticket to track it here: https://github.com/tlswg/dtls-conn-id/issues/103 Re: > -- Section 6 -- > I am puzzled by the text: > "There is a strategy for ensuring that the new peer address is > able to receive and process DTLS records. No such strategy is > defined in this specification." > Does this mean that there is no way to update the peer IP address ? No, it means that we delegate the application using DTLS to do the Validation (*). Specifically, the DTLS API on the receiver must be able to: (1) forward the "peer address update" signal to the application so that it can carry out validation of the new address using some minimal application traffic exchange (e.g., CoAP has the Echo option for that purpose); (2) update the new address if requested by the application - in case the action triggered by (1) is successful in confirming that the new address is effectively the known peer. This should be already captured in the penultimate paragraph of Section 6. If that is not the case, could you suggest text to improve it? Cheers, thanks! (*) Note that an in-protocol solution [1] has been proposed but it is not (yet) adopted. [1] https://tools.ietf.org/html/draft-tschofenig-tls-dtls-rrc-01 On 19/04/2021, 08:48, "Éric Vyncke via Datatracker" wrote: > > Éric Vyncke has entered the following ballot position for > draft-ietf-tls-dtls-connection-id-11: 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 DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ > > > > -- > COMMENT: > -- > > Thank you for the work put into this document. This specification > addresses the IPv4-mainly issue of NAT binding and is still required. > I am also trusted the security ADs for section 5. > > Please find below some non-blocking COMMENT points (but replies would > be appreciated), and some nits. > > I hope that this helps to improve the document, > > Regards, > > -éric > > == COMMENTS == > > -- Abstract -- > As an important part of this document is the padding, should it be > mentioned also in the abstract ? > > -- Section 3 -- > While I am not a DTLS expert, I find this section quite difficult to > understand the reasoning behind the specification as little > explanations are given about, e.g, what is the motivation of "A > zero-length value indicates that the server will send with the > client's CID but does not wish the client to include a CID." > > -- Section 6 -- > I am puzzled by the text: > "There is a strategy for ensuring that the new peer address is > able to receive and process DTLS records. No such strategy is > defined in this specification." > Does this mean that there is no way to update the peer IP address ? > > == NITS == > > -- Section 1 -- > Please expand CID on first use outside of the abstract. > > -- Section 4 -- > Suggest to add a short paragraph as a preamble to figure 3. Currently, > it looks like figure 3 belongs to the 'zeros' field description. > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Gen-art] Genart last call review of draft-ietf-tls-dtls-connection-id-10
Hi Russ, Thank you for your review. On 15/03/2021, 15:29, "Gen-art on behalf of Russ Housley via Datatracker" wrote: > Section 4: For increased clarity, I suggest: > OLD: >real_type The content type describing the payload. > NEW: >real_type The content type describing the cleartext payload. https://github.com/tlswg/dtls-conn-id/issues/97 t IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard
hi Tom, On 13/03/2021, 11:54, "tom petch" wrote: > > Is your suggestion to remove the parenthetical? I.e.: > > > > OLD > > A zero-length value indicates that the server will send with the > > client's CID but does not wish the client to include a CID (or > > again, alternately, to use a zero-length CID). > > > > NEW > > A zero-length value indicates that the server will send with the > > client's CID but does not wish the client to include a CID. > > Thomas > > Yes, that would fix this particular problem I have within this > section. > > I word it that way since I did raise two other doubts about the > wording in this section in my original post, one about successful > negotiation, which seems to me an undefined term, and one about > sending and receiving, which seems over-restrictive in the context. At the top of the thread, you suggested to change: > If DTLS peers have negotiated the use of a CIDs using the ClientHello > and the ServerHello messages into: > If DTLS peers have negotiated the use of a non-zero CID in at least > one direction, using the ClientHello and the ServerHello messages which is fine with me. However, I think it doesn't completely remove the ambiguity you are pointing at. So I'd suggest we also change the paragraph just above from: If DTLS peers have not negotiated the use of CIDs then the RFC 6347-defined record format and content type MUST be used. to: If DTLS peers have not negotiated the use of CIDs, which includes the case where both sent a zero-length cid in their connection_id extensions, then the RFC 6347-defined record format and content type MUST be used. Regarding your suggestion: > "The DTLS peers determine whether incoming and outgoing messages > need.." seems not to cater for unidirectional CIDs; perhaps > "The DTLS peers determine whether incoming or outgoing, or both, > messages need.." It surely works for me. cheers, thanks! IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard
Hi Tom, all, On 12/03/2021, 17:29, "tom petch" wrote: > On 12/03/2021 16:18, Achim Kraus wrote: > > Hi Tom, Hannes, Thomas, > > > > "A zero-length value indicates that the server will send with the > > client's CID but does not wish the client to include a CID (or > > again, alternately, to use a zero-length CID)." > > > > My feeling is, the text in the paragraphs following that seems to > > introduce first the idea of a "zero-length CID", and later use that > > only to negate the use of tls_cid record. It may be more straight > > forward, if the use of a "zero-length CID" is limited to the > > ClientHello and the ServerHello extensions. And later the use of a > > tls_cid record is then only for negotiated non-empty CID. > > > > WDYT? > > I think that I cannot make sense of that 'alternately'. The > subsequent paragraphs seem to rule it out as an option. On a first > read I thought that a zero length CID was a valid option for > Application Data and wanted to know which form of header and MAC was > appropriate but my understanding of the later paragraphs became that a > zero length CID can only appear in Hello; but I do think that this > needs fixing. Is your suggestion to remove the parenthetical? I.e.: OLD A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID (or again, alternately, to use a zero-length CID). NEW A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID. > I did track the WG discussion last October and did not see anything > very clear then. > > Tom Petch IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Last Call: (Connection Identifiers for DTLS 1.2) to Proposed Standard
Hi Tom, Thanks very much! Your review is tracked in the issues below. On 12/03/2021, 10:39, "tom petch" wrote: > > Some editorial quirks > > s.2 > lacks the boiler plate of RFC8174 https://github.com/tlswg/dtls-conn-id/issues/88 > s.3 > I found this unclear until I had understood it all (or perhaps I do not > understand it) > > "...or again, alternately, to use a zero-length CID)." > This suggests that a zero length CID is valid in Application Data which > later text seems to contradict; otherwise I cannot see what this is saying. > > " If DTLS peers have negotiated the use of a CIDs using the ClientHello > and the ServerHello messages " > arguably sending a zero CID and receiving a zero CID is a successful > Hello negotiation perhaps > " If DTLS peers have negotiated the use of a non-zero CID in at least > one direction, using the ClientHello and the ServerHello messages" > > "The DTLS peers determine whether incoming and outgoing messages need.." > seems not to cater for unidirectional CIDs; perhaps > "The DTLS peers determine whether incoming or outgoing, or both, > messages need.. " https://github.com/tlswg/dtls-conn-id/issues/89 > s.4 > /always recieve CIDs/always receive CIDs/ > > > s.5.1 > "the with Encrypt-then-MAC processing described in [RFC7366]." > I do not understand why 'with' is needed > > s.5.2 > ditto > > s.8 > /this aspects SHOULD refuse/these aspects SHOULD refuse/ https://github.com/tlswg/dtls-conn-id/issues/90 > s.10 > I would find this clearer as three sections for the three IANA actions > 10.1 new column for ExtensionType > 10.2 new value for ExtensionType > 10.3 new value for ContentType > > " IANA is requested to allocate an entry to the existing TLS > "ExtensionType Values" registry, defined in [RFC5246],.." > well no; whatever you think of RFC8447 the name has changed > " IANA is requested to allocate an entry to the existing "TLS > ExtensionType Values" registry, defined in [RFC5246],.." > or, if you are picky (which I am not), > IANA is requested to allocate an entry to the existing "TLS > "ExtensionType Values" registry, defined in [RFC5246], and > renamed by RFC8447 > > An extra column is added but I cannot see what value should be placed in > that column for existing entries. > > "The tls12_cid ContentType is only applicable to DTLS 1.2." > Good information but I struggle to see what IANA will do with it; I see > nowhere for it to go. https://github.com/tlswg/dtls-conn-id/issues/91 cheers, t > Tom Petch > > > On 08/03/2021 11:19, The IESG wrote: > > > > > > The IESG has received a request from the Transport Layer Security WG (tls) > > to > > consider the following document: - 'Connection Identifiers for DTLS 1.2' > > as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits final > > comments on this action. Please send substantive comments to the > > last-c...@ietf.org mailing lists by 2021-03-28. Exceptionally, comments may > > be sent to i...@ietf.org instead. In either case, please retain the > > beginning > > of the Subject line to allow automated sorting. > > > > Abstract > > > > > > This document specifies the Connection ID (CID) construct for the > > Datagram Transport Layer Security (DTLS) protocol version 1.2. > > > > A CID is an identifier carried in the record layer header that gives > > the recipient additional information for selecting the appropriate > > security association. In "classical" DTLS, selecting a security > > association of an incoming DTLS record is accomplished with the help > > of the 5-tuple. If the source IP address and/or source port changes > > during the lifetime of an ongoing DTLS session then the receiver will > > be unable to locate the correct security context. > > > > > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ > > > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > > > > ___ > > IETF-Announce mailing list > > ietf-annou...@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce > > . > > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WG adoption call for draft-tschofenig-tls-dtls-rrc
I think this is an important protocol feature and I'm in favour of adoption. I'm also happy to invest cycles to bring it to fruition. I agree with Martin that the currently defined mechanism is simplistic, and I expect it to change substantially. Hopefully, we can reuse at least some of the good stuff that has been produced in QUIC in this same area. Cheers! On 01/08/2020, 01:55, "TLS on behalf of Sean Turner" wrote: > > Just a reminder that this WG adoption call is still ongoing. > > spt > > > On Jul 22, 2020, at 14:55, Sean Turner wrote: > > > > Hi! > > > > The authors of "Return Routability Check for DTLS 1.2 and DTLS 1.3" > > have asked for adoption of their draft as a WG item. Please state > > whether you support adoption of this draft as a WG item by posting a > > message to the TLS list by 2359 UTC 06 August 2020. Please include > > any additional information that is helpful in understanding your > > position. > > > > NOTE: We discussed this draft at IETF 105 in connection with > > draft-ietf-tls-dtls-connection-id [0]. The plan at the time was to > > progress draft-tschofenig-tls-dtls-rrc after we progressed > > draft-ietf-tls-dtls-connection-id. That time is now. > > > > Thanks, Chris, Joe, and Sean > > > > [0] > > https://datatracker.ietf.org/meeting/105/materials/slides-105-tls-sessb-cid-00 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Banning implicit CIDs in DTLS
Hi Achim, > I'm not sure, how CoAP (RFC 7252) offers framing. AFAIK it uses the > size of the UDP message (or that of the DTLS "application_data" part). > Only for TCP the size is explicitly encoded in the CoAP messages (but > that's not RFC7252). If I miss something about that, it would be > great, if you share some details to help me out. No, you're right, I got 8323 and 7252 framing mixed up. Thanks! IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Banning implicit CIDs in DTLS
On 24/05/2020, 20:45, "Eric Rescorla" wrote: > In what context do you have a use for implicit CIDs? The specific use case I had in mind is that of an endpoint sending small and frequent application data units to the same peer - e.g., sensor readings through CoAP observe. In this (and similar) situation(s) where the payload / header ratio is low one wants to have as little transport overhead as possible. Now, it turns out in the specific situation (and whenever the data framing is provided by a higher layer protocol - CoAP, SCTP, DNS) one might as well buffer and coalesce all the application stuff into one single record, making the need for CID compression moot. So, I am now convinced I don't have a compelling case to bring to the table and might as well move into Martin's "vanishingly small use cases" camp, therefore subscribing the gist of PR#148. PS A note about the more general argument of a pure pseudo-header approach: it'd enable compression boxes at ingress into a constrained network, which would be really useful. Without a thorough analysis wrt header malleability this is unfortunately out of reach. -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Banning implicit CIDs in DTLS
On 22/05/2020, 01:09, "Christopher Wood" wrote: > On Thu, May 21, 2020, at 9:22 AM, Thomas Fossati wrote: > > Hi Chris, > > > > On 21/05/2020, 17:00, "Christopher Wood" > > wrote: > > > *One proposal to address this is by extending the AAD to include > > > the pseudo-header. However, the chairs feel this is an unnecessary > > > divergence from QUIC. > > > > I don't understand the "unnecessary" in the above para, i.e., why > > are we so tied to QUIC in this case? I'm asking because it looks > > like this was a core criterion in the Chairs' proposal. > Sorry for the confusion! The point here was that QUIC authenticates > what's on the wire, which we felt was important. I should have spelled > that out. There are of course other things to consider, as Martin > points out. OK, thanks for clarifying. I want to be able to use implicit CIDs so I don't support PR#148 as-is. As much as I'd like to go for a pure pseudo-header approach, I don't think I have enough data at this point in time that I'd feel safe going that way. Since adding implicit CID to the AD doesn't look like a big deal in terms of performance overhead, that would be my preference. cheers, t IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Banning implicit CIDs in DTLS
Hi Chris, On 21/05/2020, 17:00, "Christopher Wood" wrote: > *One proposal to address this is by extending the AAD to include the > pseudo-header. However, the chairs feel this is an unnecessary > divergence from QUIC. I don't understand the "unnecessary" in the above para, i.e., why are we so tied to QUIC in this case? I'm asking because it looks like this was a core criterion in the Chairs' proposal. Cheers, t IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Integrity bounds in DTLS
On 18/05/2020, 01:47, "Martin Thomson" wrote: > The question is whether it is clear that these limits apply to the use > of AEADs in TLS more generally. I think that is clear enough, but I > doubt that people will pay any mind unless they are implementing TLS > 1.3. Yes, that's exactly my original point. I'd like to maximise the chance that the message doesn't get ignored: we have 1.2 deployments around that are not likely to be forklifted to 1.3 soon and will have to make them aware of the risk nonetheless. > The problem with TLS 1.2 is that there is no option for key updates, > unless you count renegotiation, which is often disabled. When I added > limits to NSS, all I could reliably do was make the connection > terminate if the limit was hit (which is why the limits used are > larger than advised in the spec). Sure, protocol version as well as stack specific reactions will differ. I guess my question is whether, to maximise coverage/visibility, it makes sense to state the general problem together with version specific behaviours in a separate doc? IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Integrity bounds in DTLS
On 15/05/2020, 01:51, "Martin Thomson" wrote: > Continuing the trend where I am the only one to post to this thread... > > I just posted a proposal: > > https://github.com/tlswg/dtls13-spec/pull/147 Looks good, thanks! While the specific behaviours might more or less differ, the same considerations apply to 1.2. How do we make sure that the message doesn't get ignored? Would it be worth drafting this separately to cover both versions (+ an explicit "Updates: 6347" label)? > So I see two paths and one maybe option: > > 1. Prohibit use of TLS_AES_128_CCM_8_SHA256 in DTLS. > 2. Allow TLS_AES_128_CCM_8_SHA256 in DTLS under special circumstances >(the PR). > 3. An unspecified proposal that allows TLS_AES_128_CCM_8_SHA256 more >generally somehow. While I'd personally prefer path 1, I think we need to factor in existing deployments somehow. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS 1.3 AEAD additional data
On 26/04/2020, 15:49, "Christopher Wood" wrote: > To clarify (as the request was about prohibiting implicit CIDs and not > more generally about what's included in the AAD), you'd prefer we > allow implicit CIDs, correct? Hi Chris, correct. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS 1.3 AEAD additional data
On 25/04/2020, 11:43, "Thomas Fossati" wrote: > On 25/04/2020, 11:11, "Thomas Fossati" wrote: > > On 25/04/2020, 01:30, "Christopher Wood" > > wrote: > > > On Thu, Apr 23, 2020, at 2:17 PM, Eric Rescorla wrote: > > > > 1. Allowing implicit CIDs is very recent (it was introduced in > > > > -34) > > > > 2. The CID specification explicitly prohibits it for DTLS 1.2. > > > > 3. I haven't really heard a very compelling argument for this > > > >and I note that QUIC forbids it [and in fact has much worse > > > >problems when you mix epochs because the long header is so > > > >long] > > > > > > > > So, given that the simplest and most consistent thing is to > > > > simply forbid it: can someone make an argument for why this is > > > > important to permit? > > > > > > Thanks to everyone who participated in this thread so far! Given > > > the points above, the chairs would like to hear arguments in favor > > > of implicit CIDs. Absent substantial rationale, we'll assume rough > > > consensus for explicit CIDs. > > > > Hi Chris, I think implicit CID needs to be considered in the wider > > scope of unified_hdr compression, together with implicit length and > > shortened epoch. In particular, from Chris P's emails I understand > > that being able to authenticate records' length is a core assumption > > in the security proof of TLS. Therefore leaving it out from DTLS > > AAD when it's not in the header looks like a pretty bad idea. If > > this is the case (i.e. the fact that the wire image by itself is not > > sufficient input to the AAD), then authenticating implicit CIDs > > should just come in the same bundle. > > Sorry, scratch that for the moment - I had missed the most recent > emails on this thread :-( Back to this after having read and digested the parallel thread. As it stands I don't think we have enough data to take an optimal decision with respect to what needs to be input to the AAD. I suggest we err on the side of caution and use a pseudo-header approach where the pseudo-header equates the wire-header (except the epoch is in full) when no compression is involved and otherwise includes all the elided fields. I also note that it'd be great if the formal verification community could carve some time to look into the security of DTLS 1.3. There is certainly a lot of overlap with TLS and I guess substantial parts of the modelling can be reused, but there are interesting differences (in particular, around the tight knit between reliability and security layers during handshake) that are unique to DTLS and likely deserve a more careful look. cheers! IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS 1.3 AEAD additional data
On 25/04/2020, 11:11, "Thomas Fossati" wrote: > On 25/04/2020, 01:30, "Christopher Wood" wrote: > > On Thu, Apr 23, 2020, at 2:17 PM, Eric Rescorla wrote: > > > 1. Allowing implicit CIDs is very recent (it was introduced in > > > -34) > > > 2. The CID specification explicitly prohibits it for DTLS 1.2. 3. > > > I haven't really heard a very compelling argument for this and I > > > note that QUIC forbids it [and in fact has much worse problems > > > when you mix epochs because the long header is so long] > > > > > > So, given that the simplest and most consistent thing is to simply > > > forbid it: can someone make an argument for why this is important > > > to permit? > > > > Thanks to everyone who participated in this thread so far! Given the > > points above, the chairs would like to hear arguments in favor of > > implicit CIDs. Absent substantial rationale, we'll assume rough > > consensus for explicit CIDs. > > Hi Chris, I think implicit CID needs to be considered in the wider > scope of unified_hdr compression, together with implicit length and > shortened epoch. In particular, from Chris P's emails I understand > that being able to authenticate records' length is a core assumption > in the security proof of TLS. Therefore leaving it out from DTLS AAD > when it's not in the header looks like a pretty bad idea. If this is > the case (i.e. the fact that the wire image by itself is not > sufficient input to the AAD), then authenticating implicit CIDs should > just come in the same bundle. Sorry, scratch that for the moment - I had missed the most recent emails on this thread :-( IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Choice of Additional Data Computation
On 24/04/2020, 22:35, "Eric Rescorla" wrote: > On Fri, Apr 24, 2020 at 2:29 PM chris - wrote: > > I would need to study the specs in order to provide an intelligent > > answer here. Off the hip, it would seem to depend on how the > > boundaries between record headers and ciphertexts are determined. > > Taking a quick look at draft-37, Fig. 4: the "full" header includes > > three values that are excluded from the "minimal" header, the length > > of the ciphertext being one of the fields. Presumably, when using > > the "minimal" header, the length is a parameter that the sender and > > receiver already agree on. > > Yes. It's "the rest of the UDP datagram". I might be missing something but this doesn't look to me like the definition of "agreed upon" by the TLS principals: an attacker can modify what "the rest of the datagram" is at will, no? IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS 1.3 AEAD additional data
On 25/04/2020, 01:30, "Christopher Wood" wrote: > On Thu, Apr 23, 2020, at 2:17 PM, Eric Rescorla wrote: > > 1. Allowing implicit CIDs is very recent (it was introduced in -34) > > 2. The CID specification explicitly prohibits it for DTLS 1.2. 3. I > > haven't really heard a very compelling argument for this and I note > > that QUIC forbids it [and in fact has much worse problems when you > > mix epochs because the long header is so long] > > > > So, given that the simplest and most consistent thing is to simply > > forbid it: can someone make an argument for why this is important to > > permit? > > Thanks to everyone who participated in this thread so far! Given the > points above, the chairs would like to hear arguments in favor of > implicit CIDs. Absent substantial rationale, we'll assume rough > consensus for explicit CIDs. Hi Chris, I think implicit CID needs to be considered in the wider scope of unified_hdr compression, together with implicit length and shortened epoch. In particular, from Chris P's emails I understand that being able to authenticate records' length is a core assumption in the security proof of TLS. Therefore leaving it out from DTLS AAD when it's not in the header looks like a pretty bad idea. If this is the case (i.e. the fact that the wire image by itself is not sufficient input to the AAD), then authenticating implicit CIDs should just come in the same bundle. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Choice of Additional Data Computation
On 24/04/2020, 19:53, "chris -" wrote: > [...] the details of how to decode the data on the wire begin to > really matter for the proof (and potentially for an attacker). I have zero experience with formal security proofs, so I need to trust your assessment here, which looks like the crux of the argument against authenticating the pseudo-header alone. > I don't think it would hurt to authenticate more than this, e..g., > other fields that the sender and receiver need to agree on. IIUC the other seemingly critical thing for the security proof of TLS, which I think it's critically important we try hard not to diverge from, was authenticating the length of the record: > [...] all we cared about is that the header correctly encodes the > length of the next ciphertext to decrypt. The thing is with UDP it is trivial for an attacker to truncate a datagram and therefore change the *implicit* length of the carried record and go undetected if that is not included in the authenticated data. So it seems that - at a minimum - we should always authenticate the length even when it is not put on the wire. And if we need to do that, keeping the implicit CID looks like a no-brainer to me. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] DTLS 1.3 AEAD additional data
Just one comment. On 23/04/2020, 00:54, "Martin Thomson" wrote: > But Hanno's proposal is a terrible thing to have to implement. You > have to assume that there is some way to recover which CID to use in > decrypting any record. You might save some datagram-local state, but > that's awkward. Stacks that I've worked on try very hard not to have > state transmission between records for good reasons. So this would be > a fairly bad complication. The cost of keeping per-datagram state on the receiving end seem very low to me. And that would be the only cost overall, because on the sending side there's none. And this is in contrast to the higher sender complexity in the current draft. Also, once you start keeping per-datagram state, you might as well stash as much as possible in it and for example compress sequence numbers as well as just the CID. So, if that is the only blocker WRT Hanno's proposal, I'd be happy to trade that off for the nice properties it comes with. > Separately, I hope that no one would be contemplating trial decryption > for this, which would be terrible. Surely not. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Efficiency of ACKing scheme
On 09/04/2020, 15:34, "Eric Rescorla" wrote:
> > > But this requires being able to send an empty ACK that means "I
> > > got nothing". In which case, I don't see how it's really different
> > > from the current text except that it gives the sender less
> > > guidance.
> >
> > Not sure there's an "empty ACK" in Hanno's proposal. This is how I
> > interpret it in the context of your example: in the second flight,
> > if rec#0 (containing SH) is lost and rec#1 gets through, the
> > receiver sends ACK {1}. From that the sender can infer the gap and
> > retransmit rec#0.
> >
> > You can't send ACK{1} because you can't decrypt it because it is
> > out of order with respect to the DH key. This is the point of the
> > empty ACK.
True, so you send ACK{} (as per last para of Section 7.1) and similarly
the receiver can deduce a gap -- indeed a very precise one -- and
re-send record containing the SH.
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Efficiency of ACKing scheme
On 09/04/2020, 15:18, "Eric Rescorla" wrote:
> > On Thu, Apr 9, 2020 at 6:59 AM Thomas Fossati
> > wrote:
> > On 09/04/2020, 14:20, "Eric Rescorla" wrote:
> > > Assuming I understand Hanno's proposal, I do not believe that this
> > > is in fact an improvement, as it does not cover the important case
> > > where the record containing the SH is lost and then the rest of
> > > the messages from the server are uninterpretable.
> >
> > I don't want to speak for Hanno here but the refinement proposed in
> > [1], specifically the bit that says:
> >
> > [...] They may also proactively retransmit parts of a flight early
> > if an ACK message indicates a gap.
> >
> > should cover the case you mention I think.
>
> But this requires being able to send an empty ACK that means "I got
> nothing". In which case, I don't see how it's really different from
> the current text except that it gives the sender less guidance.
Not sure there's an "empty ACK" in Hanno's proposal. This is how I
interpret it in the context of your example: in the second flight, if
rec#0 (containing SH) is lost and rec#1 gets through, the receiver sends
ACK {1}. From that the sender can infer the gap and retransmit rec#0.
(But again, I'm not him and that's why I suggested collecting all the
pieces of this discussion together in one PR.)
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Efficiency of ACKing scheme
On 09/04/2020, 14:20, "Eric Rescorla" wrote: > Assuming I understand Hanno's proposal, I do not believe that this is > in fact an improvement, as it does not cover the important case where > the record containing the SH is lost and then the rest of the messages > from the server are uninterpretable. I don't want to speak for Hanno here but the refinement proposed in [1], specifically the bit that says: [...] They may also proactively retransmit parts of a flight early if an ACK message indicates a gap. should cover the case you mention I think. [1] https://mailarchive.ietf.org/arch/msg/tls/w2nEYEB3ZMs5bzejqcHVEO-OBVQ/ IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Efficiency of ACKing scheme
Hey Hanno, On 08/04/2020, 15:11, "Hanno Becker" wrote: > As far as I see, tail loss indication involves a timer in both cases: > > - As it stands, tail loss recovery is triggered by the ACK resulting > from the 'lack of progress' indicator of disruption, described in > the second bullet point of draft-ietf-tls-dtls13-37#section-7.1 > In particular, it only occurs after a 'short' timer triggered on the > receiver, where by 'short' I mean that is has smaller threshold than > the ordinary retransmission timer from DTLS 1.2, marking the bottom > line recovery time we want to improve upon. > > - Likewise, there's short timer based recovery in the new proposal, > but mirrored: The sender retransmits upon noticing a gap in the > ACKs, which too can be detected by a short timer as in the current > proposal. You are right, this wouldn't have worse tail-loss recovery than what is currently specified. So, all things considered it looks like a real improvement compared to dtls13-37. Could collect the text from this thread in a PR against Section 7? This way folks that haven't followed the discussion closely can see how your proposal looks overall. cheers, thanks! IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Efficiency of ACKing scheme
On 06/04/2020, 15:16, "Hanno Becker" wrote: > Given we agree that there is a significant inefficiency in the ACKing > scheme as stated, I'd prefer we try to improve the spec now provided > we find a not too intrusive way to do so, and not postpone the > problem. > > After all, it seems that there isn't much to be changed if we go for > option 2 from the original post, which perhaps isn't far off from the > original intention anyway: > > * Sending ACKs: ACKs may be sent for any record immediately, but it is > recommended to bunch ACKs and in particular send them on any sign of > disruption. > > * Receiving ACKs: Upon receipt of an ACK, implementations should note > which messages have been received and omit them from future > retransmissions. It is up to the implementation to decide when to > retransmit and what to retransmit, but it is recommended they > retransmit after a period of time during which no further ACK messages > have been received. They may also proactively retransmit parts of a > flight early if an ACK message indicates a gap (note, though, that in > this example one would only retransmit the gap, not the gap + tail as > before). Looks like a sound proposal to me. The only problem I see with this is that recovery from tail loss is not efficient, which might or might not be a problem, depending on the loss pattern of your path. cheers! IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Efficiency of ACKing scheme
Hi Hanno, On 06/04/2020, 12:19, "Hanno Becker" wrote: > Thus, in a nutshell, leaving the question of whether ACKs should be > buffered or not on the receiver to the implementor, leads to > interoperability issues. I'm not sure this strictly qualifies as an interop issue. At a subtle level it is, in the sense that the signals coming from one side don't the same exact semantics when observed from the peer point of view, but that doesn't result in an interop problem at the macro level. It does make the reliability scheme suboptimal and maybe even grossly inefficient in some cases and may have disruptive potential on the network, agreed. But the overall "lost in translation" effect depends greatly on the resources available to the endpoints as well as the network path rather than the inner logics of the ACKing scheme. cheers IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Efficiency of ACKing scheme
On 06/04/2020, 12:17, "Rob Sayre" wrote: > Are there decisions here that will be difficult to reverse? At a first glance it doesn't seem likely. The spec is quite malleable and gives implementations a lot of leeway. That said, as currently written, this doesn't seem to work particularly well on paths that are lossy, slow, and with small MTUs (or a combination thereof), which we need to make sure it's reasonably well covered as it happens to be one of our main use cases. I'm inclined to say this could be solved by profiling the reliability scheme for constrained networks (in I-D.tschofenig-uta-tls13-profile), but there still things that can be said wrt ACK timing here that can improve implementations in the general case, I think. Cheers IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Efficiency of ACKing scheme
On 06/04/2020, 02:49, Martin Thomson wrote:
> I think that you are assuming a lot about how the loss recovery part
> of the sender is operating here.
>
> If you receive ACK { 1, 3 }, then it might be reasonable to assume
> that 2 got lost, but it seems to me that assuming anything about 4 is
> premature.
The spec as currently written says that the signal "ACK {1, 3}" means
"retransmit {2, (3, end]}":
Upon receipt of an ACK for only some messages from a flight, an
implementation SHOULD retransmit the remaining messages or
fragments.
This works as expected only if the sender can assume that the receiver
has let enough time pass before generating ACK {1, 3}, but this is not
strongly stated in the description of receiver behaviour.
We should keep in mind that DTLS implementers are not necessarily
transport experts, and that warrants a bit more care in what we say as
well as what we don't say. In particular, we should try hard to avoid
expert bias.
One example where we can improve: we have a nice sentence about bunching
ACKs at 25% of current RTO halfway through bullet 2 of Section 7.1. In
fact, avoiding knee-jerk ACKing is one of the basic things to understand
here. Incidentally, this is how one's solves Hanno's conundrum above
(at least in non-pathological cases) because "retransmit {2, (3, end]}"
would be generated when the receiver has got some confidence about 4 &
co. being actually lost. Unfortunately, the sentence is oddly placed
and one tends to overlook it and not giving it the high and general
relevance it actually has.
> The sender can also make some adjustments, without necessarily
> adhering to a strict interpretation of the recommendations in the
> spec.
Agree again, but deciding to violate a SHOULD should be an exception,
not the rule. If I have to implement this, especially on very
low-bandwidth paths that fragment a lot, I probably would never follow
the recommendation: I'd first re-send 3 and sit back for a while waiting
for further ACKs before resending (3, end].
> The draft is imprecise about this logic intentionally. It recommends
> that the sender send missing data, which will likely work, and be
> fast. For large flights, yes, this will be suboptimal, but we are
> also assuming that this data is not subject to congestion control
> limits.
Just a note: "large flights" is relative to the available bandwidth so
(very) low-bandwidth would always have suboptimal recovery even if HS
data is not congestion controlled. And that's the environment where you
absolutely want to have a reliability scheme that is bandwidth
efficient.
> If we go to PQ schemes with large amounts of data, then that requires
> a different set of assumptions. It might also require that
> implementations take extra steps to avoid the resulting
> inefficiencies.
True that.
Cheers!
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for draft-rescorla-tls-ctls
Yes, please. On 21/11/2019, 05:36, "TLS on behalf of Sean Turner" wrote: At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS WG and the LAKE BOF, which is now a chartered WG [3]. After some discussions, the ADs suggested [4] that the TLS WG consider whether this draft be adopted as a TLS WG item. LAKE could then later specify/refer/adopt/profile it, as appropriate. The authors revised cTLS and presented the revised draft at IETF 106 [5]. At IETF 106 there was support for adoption of cTLS as a WG item. To confirm this on the list: if you believe that the TLS WG should not adopt this as a WG item, then please let the chairs know by posting a message to the TLS list by 2359 UTC 13 December 2019 (and say why). NOTE: : If the consensus is that this draft should be adopted as a WG item, then this will necessarily result in a WG rechartering discussions. We would have gotten to this rechartering discussion anyway now that DTLS 1.3 is progressing out of the WG. Thanks, Chris, Joe, and Sean [0] https://datatracker.ietf.org/doc/slides-105-tls-sessa-ctls/ [1] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ [2] https://github.com/ekr/draft-rescorla-tls-ctls [3] https://datatracker.ietf.org/doc/draft-rescorla-tls-ctls/ [4] https://mailarchive.ietf.org/arch/msg/lake/kACwW7PXrmTRa4PvXQ0TA34xCvk [5] https://datatracker.ietf.org/meeting/106/materials/slides-106-tls-compact-tls-13-00.pdf ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] cTLS transport question
Thanks for presenting this work. I really like this and I think it'd be really useful for the use cases we have (IoT, M2M). One comment: from a quick skimming of the draft, I'm not sure I understand what the stated expectations on the transport layer are? Since it's cTLS and not cDTLS I'd have thought it's the same as TLS (in-order & reliable) but then I got confused reading section 3.2 [1]: "The CTLS Record Layer assumes that records are externally framed (i.e., that the length is already known because it is carried in a UDP datagram or the like)" On Jabber Ben suggested that one could put CoAP between UDP and cTLS to get in-order & reliable delivery with a datagram transport, but then I'm not sure what the advantage would be since we'd be trading 2 bytes of TLSPlaintext.length with 4 bytes (minimum) of CoAP header? From the Jabber discussion, my current understanding is that there are 2 assumptions: a) the transport is in-order & reliable, and 2) there is one TLS record per transport layer packet. Is that the correct interpretation? If it is, is it not too restrictive a requirement? Cheers, thanks [1] https://tools.ietf.org/html/draft-rescorla-tls-ctls-02#section-3.2 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for draft-nir-tls-tlsflags
On 24/07/2019, 13:47, "TLS on behalf of Christopher Wood" wrote: > > At TLS@IETF105, there was interest in the room to adopt > draft-nir-tls-tlsflags as a WG item. The draft can be found here: > >https://datatracker.ietf.org/doc/draft-nir-tls-tlsflags/ > > This email starts the call for adoption. It will run until August 7, > 2019. Please indicate whether or not you would like to see this draft > adopted. adopt += 1 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-dtls-connection-id-06
On 17/07/2019, 17:42, "Thomas Fossati" wrote: > My suggestion is we move that section back and point to RRC for the > "final" solution. This doesn't give complete internal coherency to > conn-id -- which is indeed suboptimal -- but the recommendation to > provide peer address update call-backs provides at least a way out and > looks to me like the least worse solution given where we are. Just FYI, the current state of the confab between Achim, Philippe and myself is captured at: https://github.com/tlswg/dtls-conn-id/compare/master...thomas-fossati:address-validation-take-2 cheers, t IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-dtls-connection-id-06
On 17/07/2019, 16:33, "TLS on behalf of Martin Thomson" wrote: > I'm really concerned about shipping a protocol that enables the sorts > of attacks that connection IDs enable. I think that we should discuss > that issue when we meet. I know that Hannes' new draft is an attempt > to tackle this issue, but that's a long way from being done. If we > ship a spec with this hole, it will only be usable in certain narrow > contexts, like with ICE, where this really isn't a concern anyway. I share the same worry that the document as it is at the moment creates a dangerous situation if implemented in isolation, i.e. without RRC. Originally I had proposed the text in [1]. The two MUSTs in that PR should counter the man-on-the-side attacks described in [2]. They are self-contained, cheap and effective countermeasures that an endpoint can implement unilaterally. This was before RRC was drafted. Those paragraphs have now been moved there; however, I think they really belong to conn-id. My suggestion is we move that section back and point to RRC for the "final" solution. This doesn't give complete internal coherency to conn-id -- which is indeed suboptimal -- but the recommendation to provide peer address update call-backs provides at least a way out and looks to me like the least worse solution given where we are. Cheers, t [1] https://github.com/tlswg/dtls-conn-id/pull/65/files [2] https://github.com/tlswg/dtls-conn-id/issues/64#issue-448307810 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WGLC for draft-ietf-tls-dtls-connection-id-03
On Mon, Mar 4, 2019 at 4:43 PM Joseph Salowey wrote: > This is a working group last call for draft-ietf-tls-dtls-connection-id-03. > The last working group last call resulted in some issues. The authors worked > with the reviewers to publish a new draft to address these issue. Please > focus your review on the changes since the previous last call. You can find > a link to a diff with the previous draft on the tools page [1]. Please > response to the list with any comments by 2359 UTC on 12 March 2019. > Thanks, > > Chris, Joe and Sean > > [1] https://tools..ietf.org/html/draft-ietf-tls-dtls-connection-id-03 -05 describes CID processing with AEAD ciphersuites only, which seems to imply that CID modifies ciphersuite's selection -- and it's incompatible with EtM. I looks like the interaction between CID, non-AEAD modes and EtM should be clarified. Cheers, ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
