Re: [TLS] John Scudder's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

[Eric Rescorla <[e-mail]>]

On Tue, Apr 20, 2021 at 3:42 PM John Scudder <[e-mail]> wrote:

> On Apr 20, 2021, at 5:32 PM, Eric Rescorla <[e-mail]> wrote:
>
> 3. Section 6:
>>
>>    *  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.
>>
>> This is a little mind-boggling to me. I understand this to mean I can’t
>> send
>> the new address a DTLS record unless I’ve already ensured it can receive
>> and
>> process that record, right? This seems almost like a classic Catch-22. I
>> feel
>> like I must be missing something.
>
>
> This specification *only* allows you to mux, but doesn't allow you to
> migrate.
> We could probably make this point clearer.
>
>
> Yes, I think so. Various things led me to think this was supposed to be a
> feature. For starters, the abstract:
>
>    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.
>
>
> It’s true the abstract doesn’t promise that I can migrate to the new
> address, but I felt led in that direction. But more to the point, §6 itself:
>
>    When a record with a CID is received that has a source address
>    different than the one currently associated with the DTLS connection,
>    the receiver MUST NOT replace the address it uses for sending records
>    to its peer with the source address specified in the received
>    datagram unless the following three conditions are met:
>
>
> If I understand your reply correctly, the quoted sentence could end “…
> unless the following three conditions are met (which will never happen):”.
> Since that seems both capricious and pointless, I still think I’m missing
> something. Is it that you envision a future specification that does define
> a strategy that will fulfill the third condition?
>

Yes.

-Ekr