On Oct 11, 2015, at 8:53 AM, Dave Garrett wrote:
> From a perspective to get it to work with the bare minimum needed, it's
> excessive. From a perspective of killing SHA-1 wherever viable, it is not.
I don’t think killing SHA-1 wherever viable should be a goal of this document.
A certificate
Hello TLS WG,
I would like to propose new CipherSuites for TLS. The cryptography is
founded on Kerberos authentication and DH encryption, cryptographically
bound together. The mechanism uses mutual authentication, although
clients may use anonymous tickets.
Any feedback that you may have (techn
On Sun, Oct 11, 2015 at 09:25:10AM +0200, Rick van Rein wrote:
> > *From:* internet-dra...@ietf.org
> >
> > Name: draft-vanrein-tls-kdh
> > Revision: 00
>
> Hello TLS WG,
>
> I would like to propose new CipherSuites for TLS. The cryptography is
> founded on Kerberos authentication
On Sun, Oct 11, 2015 at 02:01:59AM -0400, Dave Garrett wrote:
> On Sunday, October 11, 2015 01:53:34 am Dave Garrett wrote:
> > If the trust model doesn't need the problematic portion of the chain,
> > then the chain is not trustworthy and this does not apply.
>
> Sorry, follow-up to fix a rather
On Sun, Oct 11, 2015 at 8:17 AM, Ilari Liusvaara
wrote:
> On Sun, Oct 11, 2015 at 09:25:10AM +0200, Rick van Rein wrote:
>> > *From:* internet-dra...@ietf.org
>> >
>> > Name: draft-vanrein-tls-kdh
>> > Revision: 00
>>
>> Hello TLS WG,
>>
>> I would like to propose new CipherSuites
This seems like a good approach.
-Ekr
On Sun, Oct 11, 2015 at 6:46 AM, Watson Ladd wrote:
> On Sun, Oct 11, 2015 at 8:17 AM, Ilari Liusvaara
> wrote:
> > On Sun, Oct 11, 2015 at 09:25:10AM +0200, Rick van Rein wrote:
> >> > *From:* internet-dra...@ietf.org
> >> >
> >> > Name: dr
On Sun, Oct 11, 2015 at 01:53:34AM -0400, Dave Garrett wrote:
> On Sunday, October 11, 2015 01:08:41 am Viktor Dukhovni wrote:
> > Is this clear yet?
>
> It's clear, but we disagree on a few points here.
It is important to keep in mind that the TLS protocol specification
has a reasonably well de
On Sun, Oct 11, 2015 at 01:24:36PM -0400, Dave Garrett wrote:
> > Is is not appropriate mission for the TLS WG to launch a wider
> > anti-SHA1 crusade. The TLS WG just needs to just avoid SHA-1
> > problems in the TLS protocol itself (PRFs, ...). Avoiding SHA-1
> > in PKIX is outside this group'
> On Oct 11, 2015, at 09:46, Watson Ladd wrote:
>
>
> I would suggest piggybacking on the PSK mode, using the key Kerberos
> provides at both ends as the PSK key. This would address all of these
> issues in TLS 1.3
>
Which would also match how Kerberos is used in IKE/IPsec
Paul
___
Hi Yaron--
On Sun 2015-10-11 15:57:38 -0400, Yaron Sheffer wrote:
> We have a standard for certificate pinning (RFC 7469), but it is rather
> hard to use and as a result is rarely deployed. This draft proposes a
> lightweight alternative that allows TLS clients to authenticate the
> server they
> On Oct 11, 2015, at 3:59 PM, Dave Garrett wrote:
>
> On Sunday, October 11, 2015 02:17:17 pm Viktor Dukhovni wrote:
>> Please start with a sensibly minimal proposal that achieves the
>> essential goal of deprecating *trust* in SHA-1. Please do not
>> overreach by requiring not sending SHA-1 o
On Sun, Oct 11, 2015 at 07:13:03PM -0400, Dave Garrett wrote:
> A wording change might be helpful here. Instead of no sending of SHA1 certs:
> 1) SHA1 signatures must not be trusted
Excellent.
> 2) servers must not send cert chains they do not trust
Pointless overreach that breaks things.
> Y
On Sun, Oct 11, 2015 at 9:46 AM, Watson Ladd wrote:
> On Sun, Oct 11, 2015 at 8:17 AM, Ilari Liusvaara
> wrote:
> > On Sun, Oct 11, 2015 at 09:25:10AM +0200, Rick van Rein wrote:
> >> > *From:* internet-dra...@ietf.org
> >> >
> >> > Name: draft-vanrein-tls-kdh
> >> > Revision: 00
On Sunday, October 11, 2015 08:00:45 pm Viktor Dukhovni wrote:
> There's no reason for pessimism
Sorry, I have to laugh a bit here. :p
> we're not trying to deprecated deployed
> functionality, there is no TLS 1.3 deployed base.
Due to the fact that the vast majority of TLS implementations that
I'd like to get a sense of what the WG is willing to consider with regard to
SHA-1, rather than only Viktor and myself discussing this. Basically, I see 3
options:
Option 0: Do nothing new. SHA-1 is soft deprecated, but still a fully viable
option in TLS 1.3 if nothing better is installed.
Opti
On Sun, October 11, 2015 7:43 pm, Dave Garrett wrote:
> I'd like to get a sense of what the WG is willing to consider with regard
> to SHA-1, rather than only Viktor and myself discussing this. Basically, I
> see 3 options:
>
> Option 0: Do nothing new. SHA-1 is soft deprecated, but still a ful
I’m going to close this thread. We discussed SHA-1 support in TLS on the list
and at the interim the chairs made the consensus call that PR#231 reflects the
WG’s consensus.
Note that Stephen started a thread on the saag list about further work to
remove SHA-1 from protocols [1]; maybe the refe
Hello,
Thanks for the feedback. Responding to it:
Ilari> - The signed DH share does not look to be bound to anything (crypto
Ilari> parameters negotiation, randoms, server key exchange, etc..).
This is indeed easy to miss; it relies on Kerberos infra to deliver a
short-lived session key to
18 matches
Mail list logo
