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
