Re: [TLS] PR #604 Change "supported_groups" to "supported_kems"

To be honest, the purist in me likes the general idea here, though I think I prefer "kex" as I'm used to that with SSH. Then again, that isn't even quite correct, as the most popular mechanism is DH, which is key agreement based on the exchange of inputs to a formula: no keys are actually exchange

Re: [TLS] Finished stuffing

On Tue, Sep 13, 2016 at 12:04:40PM -0500, Benjamin Kaduk wrote: > > > On 09/09/2016 03:19 PM, Ilari Liusvaara wrote: > > On Fri, Sep 09, 2016 at 02:50:59PM -0500, Benjamin Kaduk wrote: > > >> I have a slight (i.e., unjustified) preference for doing > >> ClientHello-with-block-of-zeros rather tha

Re: [TLS] PR #604 Change "supported_groups" to "supported_kems"

I'd like to just check and see if there are any objections to this PR. There seems no reason to bake a particular cryptographic family into our terminology. This is a low-cost change that will save us from looking silly in a few years time. Cheers, William On Tue, Sep 13, 2016 at 1:19 PM, Sean T

Re: [TLS] Fwd: New Version Notification for draft-sandj-tls-iana-registry-updates-00.txt

For the 16-bit fields, do we want to leave first-octet-zero values as IETF Consensus and leave 1-254 for Specification Required? I suspect we'll need to wordsmith the text for the "Recommended" field in the cipher suite registry some; Standards-Track may or may not quite match up exactly with w

Re: [TLS] PR #604 Change "supported_groups" to "supported_kems"

There appears to be no consensus to adopt the change proposed by this PR. The small condolence here is that the name+semantics for this extension has been changed once before and if the extension really needs to be renamed in 5-7 years we’ve got precedence for doing so. spt > On Aug 29, 2016,

Re: [TLS] Version negotiation, take two

All, There appears to be an emerging consensus here to adopt the change proposed by this PR. Please indicate whether you are unwilling (and why) to accept this change by September 16th. J&S > On Sep 08, 2016, at 12:04, David Benjamin wrote: > > Hi folks, > > I’d like to revisit the questio

Re: [TLS] Finished stuffing

On 09/09/2016 03:19 PM, Ilari Liusvaara wrote: > On Fri, Sep 09, 2016 at 02:50:59PM -0500, Benjamin Kaduk wrote: >> I made a few notes on the pull request. Generally, I support the >> change, but I get the sense that it may aid the cryptographic properties >> if we keep the resumption_context an

Re: [TLS] Version negotiation, take two

On Thu, Sep 8, 2016 at 12:04 PM, David Benjamin wrote: > The major arguments against this change seem to be: > > 1. It’s inelegant to have two mechanisms. > 2. We should fix broken servers > There's also: 3. Implementors will find a way to screw this up, too. But if you follow through with you

Re: [TLS] Version negotiation, take two

This is the best proposal I've seen given the deployment constraints imposed by reality. Perhaps it could be tweaked to improve it slightly, but I support merging this version. -Ben On 09/08/2016 11:04 AM, David Benjamin wrote: > Hi folks, > > I’d like to revisit the question of version negotiat

Re: [TLS] Oracle's plans for Java crypto (mostly TLS-related)

Salz, Rich writes: >FYI: https://www.java.com/en/jre-jdk-cryptoroadmap.html >From that page: 2017-01-17 DSA Increase the minimum key length for DSA certificates to 1024 bits. Will Oracle also be announcing upcoming support for Windows 95, that newfangled Linux thing that's just appeare

[TLS] Oracle's plans for Java crypto (mostly TLS-related)

FYI: https://www.java.com/en/jre-jdk-cryptoroadmap.html -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls