* Viktor Dukhovni <[email protected]> [141014 21:18]: > Sorry, with opportunistic security, as my draft carefully explains, > "cleartext" it is not "fallback", rather it is the "baseline" > security posture, and anything better is "gravy". SMTP is cleartext > by default, and typically reverts to cleartext when STARTTLS is > unavailable or the handshake fails.
Yes. And this is - as I mentioned - pretty specific to SMTP. Which I know is an issue that directly reflects onto your work. But still, we should not advise that for ANY protocol in the BCP. See below. > The cipherstring syntax was substantially improved in 1.0.0. I noticed that during my testing. Actually it finally somewhat makes sense and seems to parse correctly (or should I say: as the user intends it to be parsed). * Viktor Dukhovni <[email protected]> [141014 21:36]: > Understood. There is room to state stronger requirements for > mandatory TLS and somewhat more liberal requirements for unauthenticated > opportunistic TLS (already vulnerable to many active attacks). > > E.g.: > > * Mandatory TLS MUST NOT use RC4, SSL 3.0, ... > > * Unauthenticated opportunistic TLS MAY only as a last resort, > when no stronger options are available, negotiate RC4, SSL 3.0, ... > > [ Note that when opportunistic DANE TLS determines via appropriate > TLSA records that the peer is to be authenticated with DANE, the > applicable requirements are those for mandatory TLS. ] This makes sense and is something I can agree with. I'd even go so far as to directly mention protocols instead of just 'opportunistic' TLS. e.g. 'In the case of SMTP MTA to MTA communication [...]'. The issue with the 'opportunistic' wording in the IETF is still that it's not really defined, although we all seem to understand that we're talking about the same thing. Or is there a document I missed? Anyway. Splitting parts of the document for 'opportunistic'/protocol specific makes sense, I agree. My hope is that this does not make the document confusing to readers - splitting this into two documents would be even more aweful. Thanks for the discussion, Aaron
signature.asc
Description: Digital signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
