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
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
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
> provid
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
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
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
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
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
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
> &
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
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
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 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
>
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
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
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
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
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)
>
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. Allow
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
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.
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
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
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
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
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
>
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
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)
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.
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
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
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
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
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 É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
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
>
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
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
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
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 2
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
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.
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.
>
>
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
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
45 matches
Mail list logo
