On Sun, Aug 17, 2014 at 1:22 PM, Yaron Sheffer <[email protected]> wrote: > Banning SSLv3 is something that seems to have the community's consensus (we > should still ascertain that). > > Banning exponent reuse is not, and we know that implementations are actually > reusing exponents. So we would need a more nuanced wording and I think this > exercise is outside the scope of this WG.
So we're going to ignore the issue? To be clear, reusing exponents means an attacker who rolls up, grabs the server and snarfs RAM along with the disks has every bit of data that ever went through that server. This is only marginally an improvement from no ephemeral key exchange, and it's something that people designing systems based on TLS need to be aware of. Sincerely, Watson Ladd > > Thanks, > Yaron > > > On 08/17/2014 08:38 PM, Watson Ladd wrote: >> >> >> On Aug 17, 2014 10:32 AM, "Yaron Sheffer" <[email protected] >> <mailto:[email protected]>> wrote: >> > >> > I'm fine with the text re: validation. Thank you. >> > >> > But IMHO your text on reuse is, in fact, normative. >> >> And? Banning SSL3 is also normative. Reuse of ephemeral exponents makes >> them useless: why can't we say that? >> > >> > Thanks, Yaron >> > >> > On 17 August, 2014 8:12:38 PM GMT+02:00, Watson Ladd >> <[email protected] <mailto:[email protected]>> wrote: >> >> >> >> On Sun, Aug 17, 2014 at 9:22 AM, Ralph Holz <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >> >>> EDIT: And of course, RFC 5280 describes the process of correct >> hostname >> >>> validation, too. >> >> >> >> >> >> The issue isn't implementing validation: it's knowing that this is a >> >> separate step that TLS implementations (yaSSL, OpenSSL, MatrixSSL,...) >> >> don't do automatically (or in some cases at all). Maybe the text. >> >> >> >> "Application authors should take note that TLS implementations >> >> frequently do not validate hostnames, and must therefore determine if >> >> the TLS implementation they are using does, and if not write their own >> >> validation code or consider changing the TLS implementation" would >> >> work. >> >> >> >> As for ephemeral keys, I feel that text akin to "TLS users should be >> >> aware that reuse of ephemeral keys negates many >> >> of the advantages, and >> >> SHOULD NOT be used" is fine. It might be seen as adding a normative >> >> bit, but that's okay: we're taking optional behavior and saying "yes, >> >> this is good, but alternatives aren't". >> >> >> >> Sincerely, >> >> Watson Ladd >> >> >> >>> >> >>> >> >>> Hi, >> >>> >> >>>>> We seem to be woefully short on advice dealing with hostname >> >>>>> validation. This is probably the real world problem that most >> often >> >>>>> trips people up, in part because OpenSSL versions prior to 0.9.8 >> don't >> >>>>> do it, and many TLS libraries have poor interfaces for it. >> >>>> >> >>>> >> >>>> I would appreciate proposed text about >> >>>> hostname validation. I suspect >> >>>> this simply amounts to "please implement the RFC correctly", but if >> >>>> there's something better we can say, let's do it. >> >>> >> >>> >> >>> IIRC the current Baseline Requirements by the CA/B Forum have such a >> >>> definition. It amounts to putting the domain/host name in the >> Subject >> >>> Alternative Name, with wildcarding defined. >> >>> >> >>> I can put together some text, if you want? >> >>> >> >>> Ralph >> >>> >> >>> >> >>> -- >> >>> Ralph Holz >> >>> I8 - Network Architectures and Services >> >>> Technische Universität München >> >>> http://www.net.in.tum.de/de/mitarbeiter/holz/ >> >>> Phone +49.89.289.18043 >> >>> PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF >> >>> >> >>> ________________________________ >> >>> >> >>> Uta mailing list >> >>> [email protected] <mailto:[email protected]> >> >> >>> https://www.ietf.org/mailman/listinfo/uta >> >> >> >> >> >> >> > >> > -- >> > Sent from my Android device with K-9 Mail. Please excuse my brevity. >> > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
