RE: [dccp] New version of DTLS over DCCP (-03) submitted

["Phelan, Tom" <tphelan at sonusnet.com>]

Hi Tom,

> Yes, you have addressed well all the issues I raised, thank you.  

[Tom P.] And thank you for the comments.

> (In
> passing
> you may have seen a post to the TLS list last week about servers
sending
> 29kbyte
> CertificateRequest messages).

[Tom P.]  Interesting discussion.  DTLS would force those certs to be
broken across multiple records, but still, it seems awfully bone-headed.
There's good security in certifying a client who can choose among 160
ways to do it?

> 
> Two further queries.  Is any comment needed on MAC failures?  With TLS
> over TCP,
> they terminate the connection; with DTLS over UDP, it is up to the
> implementation.  Do you have a view on this?

[Tom P.] The reasoning in RFC 4347 seems to apply just as well to DTLS
over DCCP as DTLS over UDP -- MAC failure on one DTLS message doesn't
mean continuous follow-on failures, so it can be up to the
implementation whether to terminate.

> 
> And, linked at least in my thinking, Alerts; is there any need for
> anything
> specific for DTLS/DCCP in the handling of Alerts?

[Tom P.] No, I don't think that's appropriate/necessary.  All of the
alerts are TLS level events and consequences (there aren't any new
alerts for DTLS).  You could vaguely think of a new warning something
like throughput_constrained_by_congestion_control -- but just when do
you send it and what do you do with it?  And that situation is equally
applicable to TLS/TCP connections, if there was no need for it there why
have it in DCCP?  Similarly, you could a connection_resyncing warning,
but that also could occur in TLS/TCP and there's no warning there.

Tom Phelan