On Tue, Dec 29, 2015 at 09:02:25AM -1000, Brian Smith wrote:
>
> Does that matter, though? The CFRG document doesn't allow the sender to set
> the high bit to 1, right? In particular, it says "All calculations are
> performed in GF(p), i.e., they are performed modulo p." and "For X25519,
> the unu
On Tue, Dec 29, 2015 at 10:10:47PM +0200, Karthikeyan Bhargavan wrote:
> As mentioned before, validating Curve25519 public values is necessary in TLS
> 1.2 without session hash.
> Otherwise, as we pointed out in [1], the triple handshake attack returns.
Would it make sense to have session hash as
On Tue, Dec 29, 2015 at 09:05:17AM -1000, Brian Smith wrote:
> On Tue, Dec 22, 2015 at 2:09 PM, Brian Smith wrote:
>
> > If an implementation only implements ECDHE cipher suites then
> > implementing the session hash extension is not necessary, according to RFC
> > 7627. I believe there are also
On Wed, Dec 30, 2015 at 11:52:07AM +0100, Kurt Roeckx wrote:
> On Tue, Dec 29, 2015 at 10:10:47PM +0200, Karthikeyan Bhargavan wrote:
> > As mentioned before, validating Curve25519 public values is necessary in
> > TLS 1.2 without session hash.
> > Otherwise, as we pointed out in [1], the triple h
On 30 December 2015 at 22:16, Ilari Liusvaara wrote:
>> Would it make sense to have session hash as a requirement in TLS
>> 1.2 when you want to use Curve25519?
>
> I don't think that is reasonable.
I think that is entirely reasonable. TLS 1.2 relies on contributory
behaviour. 25519 doesn't pro
Kurt Roeckx wrote:
> On Tue, Dec 29, 2015 at 09:02:25AM -1000, Brian Smith wrote:
> >
> > Does that matter, though? The CFRG document doesn't allow the sender to
> set
> > the high bit to 1, right? In particular, it says "All calculations are
> > performed in GF(p), i.e., they are performed modul
Martin Thomson wrote:
> On 30 December 2015 at 22:16, Ilari Liusvaara
> wrote:
> >> Would it make sense to have session hash as a requirement in TLS
> >> 1.2 when you want to use Curve25519?
> >
> > I don't think that is reasonable.
>
> I think that is entirely reasonable. TLS 1.2 relies on con
Kurt Roeckx wrote:
> On Tue, Dec 29, 2015 at 10:10:47PM +0200, Karthikeyan Bhargavan wrote:
> > As mentioned before, validating Curve25519 public values is necessary in
> TLS 1.2 without session hash.
> > Otherwise, as we pointed out in [1], the triple handshake attack returns.
>
> Would it make
On Thu, Dec 31, 2015 at 09:55:10AM +1100, Martin Thomson wrote:
> On 30 December 2015 at 22:16, Ilari Liusvaara
> wrote:
> >> Would it make sense to have session hash as a requirement in TLS
> >> 1.2 when you want to use Curve25519?
> >
> > I don't think that is reasonable.
>
> I think that is e
I suggest that the entire Appendix A be removed, as it duplicates
draft-irtf-cfrg-curves-11 and it is too difficult and tedious to verify
that it matches what draft-irtf-cfrg-curves-11 says.
Also, it doesn't say anything about X448. I've noticed that the draft has a
few other places that talk spec
On Dec 30, 2015 7:08 PM, "Ilari Liusvaara" wrote:
>
> On Thu, Dec 31, 2015 at 09:55:10AM +1100, Martin Thomson wrote:
> > On 30 December 2015 at 22:16, Ilari Liusvaara
wrote:
> > >> Would it make sense to have session hash as a requirement in TLS
> > >> 1.2 when you want to use Curve25519?
> > >
On Wed, Dec 30, 2015 at 7:23 PM, Watson Ladd wrote:
>
> On Dec 30, 2015 7:08 PM, "Ilari Liusvaara"
> wrote:
> >
> > On Thu, Dec 31, 2015 at 09:55:10AM +1100, Martin Thomson wrote:
> > > On 30 December 2015 at 22:16, Ilari Liusvaara <
> ilariliusva...@welho.com> wrote:
> > > >> Would it make sens
On Wed, Dec 30, 2015 at 07:23:12PM -0500, Watson Ladd wrote:
> On Dec 30, 2015 7:08 PM, "Ilari Liusvaara" wrote:
> >
> > I also think I figured out a way to truly force contributory behaviour
> > without any checks:
> >
> > It is a bit nasty hack: Throw the exchange keys into the PMS, expanding
>
Watson Ladd wrote:
> Why not hash the public values into the result of the key exchange? I
> don't want security to depend on omittable checks.
>
One would need an omittable check in the code to decide whether to do that
extra hashing, so that wouldn't solve the (non-)problem of "omittable
check
On Wed, Dec 30, 2015 at 7:47 PM, Brian Smith wrote:
> Watson Ladd wrote:
>>
>> Why not hash the public values into the result of the key exchange? I
>> don't want security to depend on omittable checks.
>
>
> One would need an omittable check in the code to decide whether to do that
> extra hashi
On Wed, Dec 30, 2015 at 4:03 PM, Brian Smith wrote:
> I think it is a good idea to implement the session hash extension, in
> general. However, I think it is a bad idea to prescribe it as the solution
> for this particular problem because:
>
> 1. draft-irtf-cfrg-curves-11, in sections 6.1 and sec
Adam Langley wrote:
> On Wed, Dec 30, 2015 at 4:03 PM, Brian Smith wrote:
>
> > I think it is a good idea to implement the session hash extension, in
> > general. However, I think it is a bad idea to prescribe it as the
> solution
> > for this particular problem because:
> >
> > 1. draft-irtf-cf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2015-12-31 03:30, Adam Langley wrote:
> I don't mind if the integration of curve25519 in TLS requires a
> zero-check or not, but what property are people hoping to gain? If
> one wants to avoid triple-handshake like issues then session-hash
> is
On Thu, Dec 31, 2015 at 1:23 AM, Alyssa Rowan wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2015-12-31 03:30, Adam Langley wrote:
>
>> I don't mind if the integration of curve25519 in TLS requires a
>> zero-check or not, but what property are people hoping to gain? If
>> one wa
On Thu, Dec 31, 2015 at 06:23:08AM +, Alyssa Rowan wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2015-12-31 03:30, Adam Langley wrote:
>
> > I don't mind if the integration of curve25519 in TLS requires a
> > zero-check or not, but what property are people hoping to gain?
20 matches
Mail list logo
