On Monday 21 December 2015 14:54:23 Brian Smith wrote:
> Eric Rescorla wrote:
> > Sorry, I'm still confused TLS 1.2 uses a specific PRF. TLS 1.3 uses
> > HKDF. Are you suggesting TLS 1.2 use the TLS 1.2 PRF with SHA-512
> > and that TLS 1.2 use SHA-512 with HKDF, or something different?
>
> I mea
Curve25519, as the name suggests, operates on 255-bit numbers. When
encoded as bytes, there's obviously a 256th bit that needs to be
specified.
Curve25519 implementations didn't set the bit but did used to vary on
how they parsed it. Some would take a 256-bit number and reduce it
while others woul
The current draft [1] says:
Other than this recommended check, implementations do
not need to ensure that the public keys they receive
are legitimate: this is not necessary for security
with Curve25519.
However, Thai Duong (of BEAST fame, among other things) wrote that TLS 1.2
and
Adam Langley wrote:
> Currently
> https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3
> says that implementations SHOULD reject inputs with the high-bit set.
> I think that should be dropped. The X25519 function is specified in
> terms of bytes in draft-irtf-cfrg-curves and I thi
On Dec 22, 2015 4:15 PM, "Brian Smith" wrote:
>
> The current draft [1] says:
>
> Other than this recommended check, implementations do
> not need to ensure that the public keys they receive
> are legitimate: this is not necessary for security
> with Curve25519.
>
> However, Thai D
On Tue, Dec 22, 2015 at 1:36 PM, Brian Smith wrote:
> First, maybe I'm overlooking something obvious, but I'm not seeing it: Why
> are we concerned only with whether the high bit has been set, instead of
> whether the public value has been reduced mod q (q == 2^255-19)? Aren't
> there ~19 interest
On Tue, Dec 22, 2015 at 11:59 AM, Adam Langley
wrote:
> You're correct, but I'm trying to say that the CFRG document defines a
> function that operates on bytestrings so that higher-level protocols
> don't have to worry about things like this. I think TLS should handle
> the byte strings opaquely
On 23 December 2015 at 08:51, Watson Ladd wrote:
> Textbook DH does not ensure contributory behavior. Applications don't
> implement the required checks for poorly designed protocols. If we insert
> checks, applications which fail to make those checks will be vulnerable,
> while fixing protocols c
Martin Thomson wrote:
> Watson Ladd wrote:
> > Textbook DH does not ensure contributory behavior. Applications don't
> > implement the required checks for poorly designed protocols. If we insert
> > checks, applications which fail to make those checks will be vulnerable,
> > while fixing protoco
On 23 December 2015 at 10:23, Brian Smith wrote:
> It may be the case that TLS requires contributory behavior and point
> validation is still unnecessary. Or, it may be the case that TLS doesn't
> really require contributory behavior (though, it seems obvious to me that it
> does, at least for TLS
Martin Thomson wrote:
> On 23 December 2015 at 10:23, Brian Smith wrote:
> > It may be the case that TLS requires contributory behavior and point
> > validation is still unnecessary. Or, it may be the case that TLS doesn't
> > really require contributory behavior (though, it seems obvious to me
On Tue, Dec 22, 2015 at 02:09:32PM -1000, Brian Smith wrote:
> If checking that the shared value isn't zero is sufficient
It should suffice, ideally with a constant-time comparison.
--
Viktor.
___
TLS mailing list
TLS@ietf.org
https://www.iet
On 23 December 2015 at 11:09, 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
It doesn't really say that as far as I can see, though I guess that
you could infer that from this
13 matches
Mail list logo
