|
Hi,
I do see your point. My point here was more to point there exists some alternatives that worth being considered and might be developed in the future. I agree this might require more work than I am currently thinking of. I do not know how biased I am toward
DANE, so I let you do what you think is best.
Yours,
Daniel From: Alexey Melnikov <alexey.melnikov@xxxxxxxxx>
Sent: Sunday, January 24, 2021 7:50 AM To: Daniel Migault <daniel.migault@xxxxxxxxxxxx>; secdir@xxxxxxxx <secdir@xxxxxxxx> Cc: draft-ietf-extra-imap4rev2.all@xxxxxxxx <draft-ietf-extra-imap4rev2.all@xxxxxxxx>; extra@xxxxxxxx <extra@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx> Subject: Re: Secdir last call review of draft-ietf-extra-imap4rev2-24 Hi Daniel,
On 19/01/2021 14:52, Daniel Migault via Datatracker wrote: [snip] > During the TLS negotiation [TLS-1.3][TLS-1.2], the client MUST check > its understanding of the server hostname against the server's > identity as presented in the server Certificate message, in order to > prevent man-in-the-middle attacks. This procedure is described in > [RFC7817]. > > <mglt> > I think it would be good to mention DANE as > well as certificate checks. This came up before, but at this point there is no document describing how to use DANE with email clients (an alternative/update to RFC 7817) and I am not aware of any client implementations that use DANE experimentally for this. Best Regards, Alexey |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
