Hi,
Two short comments/questions on 0-RTT in DTLS 1.3, apologies if I missed
something in the specs:
1) In DTLS 1.3, it would seem common for the server to send an HRR for the sake
of return routability checking. TLS 1.3 forbids the use of 0-RTT after an HRR.
So, 0-RTT can't be used in DTLS 1.
on
Sent: Monday, May 24, 2021 12:57 AM
To: tls@ietf.org
Subject: Re: [TLS] 0-RTT in DTLS 1.3
On Sun, May 23, 2021, at 16:05, Hanno Becker wrote:
> 1) In DTLS 1.3, it would seem common for the server to send an HRR for
> the sake of return routability checking. TLS 1.3 forbids the use of
>
Hi,
> It's not necessarily the case that you would end up with an insecure protocol
> in this case.
One should rather ask: Is it necessarily the case that you would still end up
with a secure protocol, and if so, why.
I don't see an attack either, but I think the binding of epochs to keys is
Hi all,
Both DTLS 1.2 and DTLS 1.3 mandate:
> When a DTLS implementation receives a handshake message fragment
> corresponding to the next expected handshake message sequence number, it MUST
> buffer it until it has the entire handshake message.
Can someone explain the underlying rationale?
I
cr.org
From: Achim Kraus
Sent: Saturday, November 6, 2021 7:36 AM
To: Hanno Becker
Cc: tls@ietf.org
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing
Hi Hanno,
> Can someone explain the underlying rationale?
I can only guess,
___
From: TLS on behalf of Hanno Becker
Sent: Saturday, November 6, 2021 8:18 AM
To: Achim Kraus
Cc: tls@ietf.org
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing
Hey Achim,
Thanks for the quick reply!
Actually, for TLS, you can do the same: Process handsh
mes and gradual processing non-compliant.
From: Scott Fluhrer (sfluhrer)
Sent: Saturday, November 6, 2021 1:56 PM
To: Achim Kraus ; Hanno Becker
Cc: tls@ietf.org
Subject: RE: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing
There are a number of pos
dshake message
from buffered
fragments, gradual processing of fragments (if possible), or a combination of
both.
From: Eric Rescorla
Sent: Saturday, November 6, 2021 8:57 PM
To: Hanno Becker
Cc: Scott Fluhrer (sfluhrer) ; Achim Kraus
; tls@ietf.org
Subject: R
rom: Eric Rescorla
Sent: Sunday, November 7, 2021 9:14 PM
To: Hanno Becker
Cc: Scott Fluhrer (sfluhrer) ; Achim Kraus
; tls@ietf.org
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing
On Sun, Nov 7, 2021 at 12:10 PM Hanno Becker
mailto:hanno.bec...@arm.com>
essing, or
gradual processing of fragments (if possible), or a combination of both.
________
From: Eric Rescorla
Sent: Sunday, November 7, 2021 9:36 PM
To: Hanno Becker
Cc: Scott Fluhrer (sfluhrer) ; Achim Kraus
; tls@ietf.org
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing
immediately rather than buffering it"?
From: Eric Rescorla
Sent: Sunday, November 7, 2021 10:16 PM
To: Hanno Becker
Cc: Scott Fluhrer (sfluhrer) ; Achim Kraus
; tls@ietf.org
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing
I'd like to
ations MAY
process data immediately rather than buffering it.
From: Eric Rescorla
Sent: Monday, November 8, 2021 11:47 AM
To: Hanno Becker
Cc: Scott Fluhrer (sfluhrer) ; Achim Kraus
; tls@ietf.org
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing
On Sun, Nov 7, 2021
__
From: Eric Rescorla
Sent: Monday, November 8, 2021 12:08 PM
To: Hanno Becker
Cc: Scott Fluhrer (sfluhrer) ; Achim Kraus
; tls@ietf.org
Subject: Re: [TLS] DTLS 1.2 and 1.3: HS message reassembly prior to processing
On Mon, Nov 8, 2021 at 3:58 AM Hanno Becker
mailto:hanno.bec...@arm
and 1.3: HS message reassembly prior to processing
On Mon, Nov 08, 2021 at 04:08:51AM -0800, Eric Rescorla wrote:
> On Mon, Nov 8, 2021 at 3:58 AM Hanno Becker wrote:
>
> > > > 'Small tweak in wording': Can we say "Where possible, implementations
> > > &g
PR for immediate processing: https://github.com/tlswg/dtls13-spec/pull/258
Issue for buffering text: https://github.com/tlswg/dtls13-spec/issues/259
Thanks all
From: TLS on behalf of Hanno Becker
Sent: Monday, November 8, 2021 6:56 PM
To: Ilari Liusvaara ; tls
Hi,
TL;DR
This is all about various aspects of how ACKs work in DTLS 1.3:
- The DTLS 1.3 specification requires clarification regarding
when ACKs should be sent.
- Record-level ACKs make efficient implementations for IoT
devices harder. I argue that handshake-level ACKs reduce
implementation
means that ACKing can _not_ be implemented as an automatic
mechanism at the record layer.
I'll file a PR once the discussion has concluded.
Best,
Hanno
____
From: Eric Rescorla
Sent: Friday, February 28, 2020 2:44 PM
To: Hanno Becker
Cc: tls@ietf.org
Subject: Re:
Hi,
[TL;DR]
The DTLS 1.3 spec (draft 34) doesn't fully describe the retransmission state
machine in the case of post-handshake messages, which requires clarification.
For example, is it allowed to send multiple post-handshake messages without
waiting for ACKs for the previous ones? If so, how is t
ecially low
tolerance for concurrency they can close connections.
On Thu, Mar 5, 2020, at 01:19, Hanno Becker wrote:
> Hi,
>
> [TL;DR]
> The DTLS 1.3 spec (draft 34) doesn't fully describe the retransmission state
> machine in the case of post-handshake messages, which req
now, so
> I'll leave it to the chairs to determine how to address this comment.
It would be nice to hear some more opinions on this here, too.
Thanks for the discussion,
Cheers,
Hanno
From: Eric Rescorla
Sent: Thursday, March 5, 2020 2:38 PM
To:
text, but I don't think
> anything else is needed..
>
> -Ekr
>
> On Wed, Mar 4, 2020 at 11:00 PM Hanno Becker wrote:
> > Thanks Martin for your thoughts.
> >
> > > It's unavoidable in any case. If you generate your own post-handshake
> > >
I have a minor comment on DTLS 1.3 draft 37.
On the topic of sending ACKs, the draft recommends:
```
ACKs SHOULD NOT be sent for other complete
flights because they are implicitly acknowledged by the receipt of
the next flight, which generally immediately follows the flight.
```
I wonder if the
Another comment on DTLS 1.3 draft 37.
I believe there is a slight ambiguity in the description of what
shall happen after a peer sends the last flight in a handshake.
On the one hand, the spec says:
```
In the SENDING state, the implementation transmits the buffered
flight of messages. If
In relation to ACKs for KeyUpdate messages, DTLS 1.3 Draft 37 states:
Although KeyUpdate MUST be acknowledged, it is possible for the ACK
to be lost, in which case the sender of the KeyUpdate will retransmit
it. Implementations MUST retain the ability to ACK the KeyUpdate for
up to 2M
Hi Jonathan,
> In Section 7.1, the 2nd bullet following para 1 reads: "When they
> receive a message or fragment which is out of order, either because it
> is not the next expected message or because it is not the next piece
> of the current message. Implementations MUST NOT send ACKs for
> handsh
f the KeyUpdate
(even though they can't decrypt it anymore). The example
shows that this doesn't work, unless I've made a mistake.
Best,
Hanno
From: Hannes Tschofenig
Sent: Monday, March 30, 2020 11:57 AM
To: Hanno Becker ; tls@ietf.org
Subject: RE
___
From: Hannes Tschofenig
Sent: Tuesday, March 31, 2020 7:28 AM
To: Hanno Becker ; tls@ietf.org
Subject: RE: [TLS] Possible deadlock when ACKing KeyUpdate messages?
Hi Hanno,
I believe the part of the paragraph that talks about “canned ACKs” needs to be
clarified.
In https://github.c
Thanks Ekr. I have created PR https://github.com/tlswg/dtls13-spec/pull/138
implementing the suggestion.
From: Eric Rescorla
Sent: Friday, March 27, 2020 4:30 PM
To: Hanno Becker
Cc: tls@ietf.org
Subject: Re: [TLS] [DTLS] ACK's for post-handshake authentic
of Hanno Becker
Sent: Wednesday, March 11, 2020 2:36 PM
To: Christopher Wood ; tls@ietf.org
Subject: Re: [TLS] Gaps in specification of DTLS 1.3 state machine
Thanks Eric, Martin and Chris for your input!
For the record: I withdraw my claim that there's an issue with handshake
me
: Hanno Becker
Cc: Sean Turner ; TLS List
Subject: Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13
Hi Hanno,
Thank you for your clarifications. The example you gave helps a lot.
I believe I now understand the text as written in this bullet (first
bullet, not second--my bad). I no longer think it needs
Hi all,
I am aware that we're late into the standardization of DTLS 1.3, and
likely too late for any intrusive change, but I'd still like to share
another comment on the proposed ACKing scheme and its implication on
complexity of migration from DTLS 1.2 to DTLS 1.3, in addition to the
aspect discu
Hi again,
The DTLS 1.3 ACKing scheme seems to be quite inefficient as it is written,
and I wonder if the current spec matches the authors' intentions.
Example:
Consider a flight broken down as sequence of records 1, 2, .., N.
Assume record 2 gets dropped, while all other records go through
witho
tiple ACKs.
From: TLS on behalf of Hanno Becker
Sent: Friday, April 3, 2020 5:35 PM
To: tls@ietf.org
Subject: [TLS] Efficiency of ACKing scheme
Hi again,
The DTLS 1.3 ACKing scheme seems to be quite inefficient as it is written,
and I wonder if the current spec matches the authors' inten
Hey Martin,
Thanks a lot for your reply!
> I think that you are assuming a lot about how the loss recovery part of the
> sender is operating here
My assumptions follow what the spec says SHOULD be done, though - nothing more
and nothing less.
> If you receive ACK { 1, 3 }, then it might be
>
Hi Thomas!
> 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
Hi Thomas, Hi Ekr,
> > * 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
> > r
___
From: Thomas Fossati
Sent: Thursday, April 9, 2020 4:12 PM
To: Eric Rescorla
Cc: Hanno Becker ; Rob Sayre ;
tls@ietf.org ; Thomas Fossati
Subject: Re: [TLS] Efficiency of ACKing scheme
On 09/04/2020, 15:34, "Eric Rescorla" wrote:
> > > But this require
Hi all,
On ACK protection, DTLS 1.3 Draft 37 says in Section 7:
ACK records MUST be sent with an epoch that is equal to or higher
than the record which is being acknowledged. Implementations SHOULD
simply use the current key.
Since the update of incoming and outgoing keying material is
Hi Ekr,
Great, thanks, I left comments on that PR.
Cheers,
Hano
From: Eric Rescorla
Sent: Sunday, April 19, 2020 10:39 PM
To: Hanno Becker
Cc: tls@ietf.org
Subject: Re: [TLS] Epochs for ACKs
I have posted a PR to clarify this:
https://github.com/tlswg/dtls13
Hi all,
To my understanding, DTLS 1.3 defines AEAD additional data for record protection
as the record header as seen on the wire. Quoting Draft 37, Section 4:
```
The entire header value shown in Figure 4 (but prior to record number
encryption) is used as as the additional data value for t
27;s views,
Hanno
From: Eric Rescorla
Sent: Wednesday, April 22, 2020 2:23 AM
To: Hanno Becker
Cc: tls@ietf.org
Subject: Re: [TLS] DTLS 1.3 AEAD additional data
I think there are two potential resolutions to your CID issue:
1. Cryptographically protect it as in
https://github
ffer manually, because now you'd have to?
Best,
Hanno
Looking forward to hearing other WG member's views,
Hanno
From: Eric Rescorla mailto:e...@rtfm.com>>
Sent: Wednesday, April 22, 2020 2:23 AM
To: Hanno Becker mailto:hanno.bec...@arm.com>>
has already led to one missing cryptographic binding.
Anyway, let's wait for more opinions.
Best,
Hanno
From: Eric Rescorla
Sent: Wednesday, April 22, 2020 3:47 PM
To: Hanno Becker
Cc: tls@ietf.org
Subject: Re: [TLS] DTLS 1.3 AEAD additional data
On Wed,
Hey,
Thanks for joining in, Martin and Chris.
> 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
esses your concerns:
https://github.com/tlswg/dtls13-spec/pull/140
Best,
Chris
On Fri, Apr 3, 2020, at 5:08 AM, Hanno Becker wrote:
> Hi all,
>
> I am aware that we're late into the standardization of DTLS 1.3, and
> likely too late for any intrusive change, but I'd still li
Hi Martin,
On Thu, Apr 23, 2020, at 16:43, Hanno Becker 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
Hi Ekr,
Do you see some simplifications resulting from this?
On first thought I'd think that since implementations are already able to
handle implicit
ACKs, it doesn't come at extra cost to allow their use for post-HS client-auth,
too.
In contrast, it seems that if the client's Certificate mes
Hi Chris,
Just a note on the comparison with TLS 1.3.
> I'd like to point to some related work that could shed light on this question.
> The decision for TLS 1.3 was to authenticate all data that is written to the
> wire,
It doesn't seem straightforward to extrapolate from that case since the
___
From: chris -
Sent: Friday, April 24, 2020 6:57 PM
To: Eric Rescorla
Cc: Hanno Becker ; Hannes Tschofenig
; tls@ietf.org
Subject: Re: [TLS] Choice of Additional Data Computation
It doesn't seem straightforward to extrapolate from that case since the
'pseudo-hea
Hi,
Thanks for your input Chris, this is very helpful.
Yes, this is the way I see it. I think you can get by with implicitly
authenticating things, but when you start doing this, the details of how to
decode the data on the wire begin to really matter for the proof (and
potentially for an atta
some more people from the protocol verification community
will join in here and give their thoughts.
Best,
Hanno
From: chris -
Sent: Saturday, April 25, 2020 6:58 PM
To: Hanno Becker
Cc: Eric Rescorla ; Hannes Tschofenig
; tls@ietf.org
Subject: Re: [TLS] Choice of
> > (*): Even if we optimize the CID away with cTLS the question about the
> > security implications will surface again.
> I think that cTLS is the answer to the size issue. But there, the rule tends
> to be that removing from the wire doesn't also remove from the canonical
> value that is pro
Hi Felix,
Thanks for chiming in!
> First of all, let me make sure I correctly understand that
> * "on-the-wire header" is what's exemplified in Fig. 4 of the draft
> * "pseudo-header" would be a superset, esp. including full epoch, full
> sequence number, length, connection ID, ... -- what else
> Actually, the full epoch is included in the overall sequence number and hence
> used to generate the nonce.
Good point Ekr, I missed that.
So, we're here at the moment:
(1) Only the CID issue really _needs_ fixing somehow.
(2) Other header fields are currently authenticated through a mixture o
I don't support this PR. Compactness of wire presentation is important
(and acknowledged - why would there be a compressed header otherwise)
and implicit CIDs should hence allowed and authenticated via AEAD additional
data,
preferably by generally adopting the pseudo header AAD approach.
Disappoin
Hi Achim and all,
> > 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.
#x27;s not the point of this thread.
Cheers,
Hanno
From: TLS on behalf of Hanno Becker
Sent: Thursday, May 28, 2020 9:17 AM
To: Achim Kraus ; TLS@ietf.org
Subject: Re: [TLS] Banning implicit CIDs in DTLS
Hi Achim and all,
> > Now, it turns out in t
57 matches
Mail list logo
