On Mon, Oct 12, 2015 at 6:53 PM, Benjamin Kaduk wrote:
> On 10/11/2015 08:46 AM, Watson Ladd wrote:
>> On Sun, Oct 11, 2015 at 8:17 AM, Ilari Liusvaara
>> wrote:
>>> Some quick comments:
>>> - The signed DH share does not look to be bound to anything (crypto
>>> parameters negotiation, randoms,
On 10/12/2015 10:21 PM, Rick van Rein wrote:
> Hello Benjamin,
>
>> This would seem to require an application protocol doing some Kerberos
>> exchanges up front to establish the Kerberos session key before pivoting
>> into TLS-PSK in a STARTLS-esque fashion. If that's what the application
>> protoc
Hello Benjamin,
> This would seem to require an application protocol doing some Kerberos
> exchanges up front to establish the Kerberos session key before pivoting
> into TLS-PSK in a STARTLS-esque fashion. If that's what the application
> protocol would look like, it seems like there's no reason
Hello Ilara / Watson / TLS WG,
Thanks again,
If I was to do things like the current proposal (as opposed to
overloading DHE-PSK), I would put in hash of entiere client and server
first flights.
Now I see what you mean. Indeed, the master secret used in Finished
does not take it into account in
On 10/11/2015 08:46 AM, Watson Ladd wrote:
> On Sun, Oct 11, 2015 at 8:17 AM, Ilari Liusvaara
> wrote:
>> Some quick comments:
>> - The signed DH share does not look to be bound to anything (crypto
>> parameters negotiation, randoms, server key exchange, etc..). I can't
>> offhand say what tha
On Mon, Oct 12, 2015 at 07:14:05AM +0200, Rick van Rein wrote:
> 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 ea
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
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 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
___
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 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
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
12 matches
Mail list logo
