On Wednesday 14 October 2015 16:06:00 Martin Thomson wrote:
> On 14 October 2015 at 15:43, Matt Caswell wrote:
> > "highly dangerous idea"
>
> Wrong Martin. I agree that there is a need for caution, but in
> reality, it's not like you can use renegotiation to hand-off to
> someone else entirely.
On Thu, Oct 15, 2015 at 9:12 AM, Matt Caswell wrote:
>
>
> On 15/10/15 14:00, Martin Rex wrote:
>> Is the particular interop problem that you want to address
>> caused by a necessity to really process application data and
>> handshake data with arbitrary interleave,
>>
>> or is it rather a problem
On Friday 16 October 2015 09:16:01 Watson Ladd wrote:
> On Thu, Oct 15, 2015 at 9:12 AM, Matt Caswell
wrote:
> > On 15/10/15 14:00, Martin Rex wrote:
> >> Is the particular interop problem that you want to address
> >> caused by a necessity to really process application data and
> >> handshake da
Hello,
Based on the feedback in this WG, I'm now redefining TLS-KDH to keep ECDH and
Kerberos orthogonal. That simplifies matters enormously. I can now see a few
design alternatives. If you have any response to them, it is kindly
appreciated!
1) Continue to use KeyExchange
This variation
On Fri, 16 Oct 2015, Rick van Rein wrote:
3) Similar to OpenPGP: Negotiate cert-type
There is a cert-type for X.509 and for OpenPGP; add one for Kerberos Tickets.
PRO: Good integration with TLS: Tickets are transported in the
ClientCertificate, and an Authenticator is the ClientVerify. DH is
Hi Matt:
I agree with your interpretation, in that there should be no records of any
type between the CSS and the Handshake/Finished message, even during
re-handshake. The full handshake (and subsequent key material) cannot be
validated until the Handshake/Finished messages has been received an
Karthikeyan Bhargavan wrote:
> The attack we’re protecting against is the following:
> [snip]
>
The key observation is that downgrade protection in TLS 1.2 (and below)
> relies on the Finished MAC, but the elements that go into computing this
> MAC (DH group, hash algorithm)
> are themselves neg
On 10/16/2015 01:48 PM, Paul Wouters wrote:
> On Fri, 16 Oct 2015, Rick van Rein wrote:
>
>> 3) Similar to OpenPGP: Negotiate cert-type
>>
>> There is a cert-type for X.509 and for OpenPGP; add one for Kerberos
>> Tickets.
>>
>> PRO: Good integration with TLS: Tickets are transported in the
>> Clie
On 16 October 2015 at 12:22, Brian Smith wrote:
> Why only protect TLS 1.3 from such a downgrade? I think it is worthwhile to
> protect TLS 1.2 from the downgrade too, in a similar way. Or, is there
> something specific about TLS 1.3 that makes the downgrade worse?
Given that we can't expect TLS
On Fri, Oct 16, 2015 at 04:05:34PM +0200, Hubert Kario wrote:
> On Friday 16 October 2015 09:16:01 Watson Ladd wrote:
> > Unfortunately I don't know how to verify this. Can miTLS cover this
> > case?
>
> you mean, you want an implementation that can insert application data in
> any place of the h
On Fri, Oct 16, 2015 at 10:04 AM, Martin Thomson
wrote:
> On 16 October 2015 at 12:22, Brian Smith wrote:
> > Why only protect TLS 1.3 from such a downgrade? I think it is worthwhile
> to
> > protect TLS 1.2 from the downgrade too, in a similar way. Or, is there
> > something specific about TLS
- Original Message -
> Hello,
> 3) Similar to OpenPGP: Negotiate cert-type
>
> There is a cert-type for X.509 and for OpenPGP; add one for Kerberos Tickets.
> PRO: Good integration with TLS: Tickets are transported in the
> ClientCertificate, and an Authenticator is the ClientVerify. DH
On 10/16/2015 04:13 PM, Nikos Mavrogiannopoulos wrote:
> - Original Message -
>> Hello,
>> 3) Similar to OpenPGP: Negotiate cert-type
>>
>> There is a cert-type for X.509 and for OpenPGP; add one for Kerberos Tickets.
>> PRO: Good integration with TLS: Tickets are transported in the
>> Clie
On 16 October 2015 at 13:39, Brian Smith wrote:
> That would be especially true for an implementation that does False Start
> for TLS 1.2.
I don't see how false start plays into this. We could have clients
reject false start if they see this sentinel value. But don't we want
to just treat this
On Fri, Oct 16, 2015 at 12:12 PM, Martin Thomson
wrote:
> On 16 October 2015 at 13:39, Brian Smith wrote:
> > That would be especially true for an implementation that does False Start
> > for TLS 1.2.
>
> I don't see how false start plays into this. We could have clients
> reject false start if
Hi Brian, yes, the mechanism proposed here could also be used by TLS 1.2
implementations to signal each other about their preferred connection
parameters.
To make most use of the bytes provided, one could use the sentinel value to
indicate
support for an extension, which then carries a signed s
Hello Paul,
>> 3) Similar to OpenPGP: Negotiate cert-type
>>
>> There is a cert-type for X.509 and for OpenPGP; add one for Kerberos
>> Tickets.
>
> How is this type of TLS connection prevented from being MITM'ed by
> someone replaying kerberos tickets (which it cannot read itself)
In Kerberos, t
Hello,
>> What messages do you need to transfer for Kerberos? Is it only a ping-pong?
Yes, the plan is to send a Ticket + Authenticator and since the server cannot
send "pong", to use the (elongated) "Finished" message to replace the
validating function of the "pong".
> The client (or server,
18 matches
Mail list logo
