On Tue, Sep 24, 2024, 12:35 David Benjamin <david...@chromium.org> wrote:
> On Tue, Sep 24, 2024, 12:12 Martin Thomson <m...@lowentropy.net> wrote:
>
>> On Thu, Sep 12, 2024, at 13:31, David Benjamin wrote:
>> > 1. If a DTLS 1.2 (i.e. does not implement RFC 9147 at all)
>> > implementation receives an ACK record for whatever reason, what
>> > happens? This decision we don't get to change. Rather, it is a design
>> > constraint. Both OpenSSL and BoringSSL treat unexpected record types as
>> > a fatal error. I haven't checked other implementations. So I think we
>> > must take as a constraint that you cannot send an ACK unless you know
>> > the peer is 1.3-capable.
>>
>> This is tangential, but I find this claim about {Open|Boring}SSL to be a
>> bit troubling, if true.
>>
>> No DTLS implementation should treat unauthenticated packets as being
>> fatal. Though perhaps that could be true prior to completing the
>> handshake, the reasons for dying should still be somewhat limited.
>>
>
> This is unavoidable, no? Suppose I sent you an unauthenticated ACK, or
> part of a ClientHello/ServerHello with the wrong contents. Or maybe I made
> you think that the server sent HelloRetryRquest
>
Sorry I meant to say HelloVerifyRequest, since that is no longer allowed in
DTLS 1.3.
or a non-existent message as the first message. You'll update your internal
> state accordingly and fail to complete the handshake, e.g. because the
> transcript is wrong or you thought a packet was received but it wasn't.
>
> If the attacker can manipulate the transport for a given connection, they
> can cause the connection to fail. That's true in either TLS or DTLS. Of
> course, if they can break the integrity or confidentiality of the
> connection, that's a problem. Or if one connection can cause *another*
> connection to fail by using disproportionate global resources. But things
> we do in this working group can't really guarantee availability in the face
> of the underlying transport not working at all.
>
> David
>
>>
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
