On Thu, Sep 17, 2015 at 03:37:29PM -0700, Brian Smith wrote:
>
> A conformant TLS 1.3 implementation will not be version intolerant. If the
> client does insecure version fallback in response to an alert or connection
> close by a conformant TLS 1.3 implementation then it is guaranteed to be
> doi
On Thu, Sep 17, 2015 at 01:23:19PM +, Alewa, Christos wrote:
> Since we at HOB, use SSL to maintain long-running VPN connections, might it
> be possible to - at least - maintain the status quo of the TLS - protocol in
> this aspect, enabling and disabling compression if needed?
If compressio
On Wed, Sep 16, 2015 at 01:54:20PM +0200, Florian Weimer wrote:
> On 09/16/2015 01:51 PM, Henrik Grubbström wrote:
> > On Wed, Sep 16, 2015 at 12:02 PM, Florian Weimer wrote:
> >> On 09/15/2015 06:29 PM, Nico Williams wrote:
> > [...]
> >>>
> >>> But if you have a fatal error you'll be closing imm
On Tue, Sep 22, 2015 at 02:56:36PM -0400, Jeffrey Walton wrote:
>
> If compression increases entropy, then one could argue its a desired
> service with security benefits.
Compression does not change the total amount of entropy. It has
the same entropy but in less bits, so you increase the densit
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 Sun, Dec 06, 2015 at 01:18:51AM +, Peter Gutmann wrote:
>
> I hadn't even thought it through to that point, more that you're not supposed
> to accept anything between Client Hello and Client Keyex except an optional
> Client Certificate.
Please read the start of the thread, that includes r
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
Hi,
After the SLOTH paper, we should think about starting to deprecate
TLS 1.0 and TLS 1.1 and the SHA1 based signature algorithms in TLS
1.2.
As I understand it, they estimate that both TLS 1.2 with SHA1 and
TLS 1.0 and 1.1 with MD5|SHA1 currently require about 2^77 to be
broken. They all depen
On Tue, Jan 12, 2016 at 11:27:02AM -0800, Bill Cox wrote:
>
> I'll just second what David said here. 0-RTT mode is here to stay, and I
> don't see a simple upgrade path from TLS 1.2. Speed matters, and 0-RTT is
> a huge upgrade for users. The trick is doing this securely...
And I think because
On Mon, Jan 18, 2016 at 02:04:17PM +0700, Peter Dettman wrote:
> We (BouncyCastle) have just updated our TLS implementations to
> draft-ietf-tls-chacha20-poly1305-04 and have confirmed interop with OpenSSL.
As far as I know, OpenSSL has an outstanding interop issue with
BoringSSL where OpenSSL wou
On Mon, Jan 18, 2016 at 12:08:22PM +0100, Kurt Roeckx wrote:
> On Mon, Jan 18, 2016 at 02:04:17PM +0700, Peter Dettman wrote:
> > We (BouncyCastle) have just updated our TLS implementations to
> > draft-ietf-tls-chacha20-poly1305-04 and have confirmed interop with OpenSSL.
>
On Tue, Jan 19, 2016 at 10:08:45PM +, David Benjamin wrote:
> On Fri, Jan 15, 2016 at 10:13 PM Brian Smith wrote:
>
> > David Benjamin wrote:
> >
> >> (Whether such certificates exist on the web is probably answerable via CT
> >> logs, but I haven't checked.)
> >>
> >
> > Me neither, and I t
On Tue, Feb 16, 2016 at 12:33:56AM +, Robert Cragie wrote:
> The big assumption here is that SSL/TLS is used solely in browsers. That is
> not how it is being used in Thread, for example, and indeed in other
> similar technologies. In Thread, it is used for local device authentication
> and aut
On Wed, Jul 04, 2018 at 12:01:18PM +0200, Hubert Kario wrote:
> what "browser extensions"? you can't really do a modern TLS 1.2 without
> extensions, let alone TLS 1.3 (which is now enabled by default in NSS). I'm
> quite sure NSS didn't drop any consequential ones...
The extensions are not rela
On Wed, Dec 05, 2018 at 07:07:30AM +0300, Daniel Kahn Gillmor wrote:
> One mitigating factor of the ETSI standard, i suppose, is that the
> CABForum's Baseline Requirements forbid issuance of a certificate with
> any subjectAltName other than dNSName or iPAddress, so otherName looks
> like it must
On Thu, Mar 03, 2016 at 06:49:51PM -0800, Glen Knowles wrote:
> On Wed, Mar 2, 2016 at 12:59 PM, Bodo Moeller wrote:
>
> > RFC Errata System :
> >
> >> struct {
> >> NamedCurve elliptic_curve_list<2..2^16-1>
> >> } EllipticCurveList;
> >>
> >> I agree with this finding
On Sun, Mar 13, 2016 at 04:51:49PM +0200, Yoav Nir wrote:
>
> Is OpenSSL going to implement this?
Personally, I think we should start without 0 RTT until we have a
better understanding of what the consequences are.
Kurt
___
TLS mailing list
TLS@ietf.
On Mon, Apr 11, 2016 at 01:08:39PM -0400, Viktor Dukhovni wrote:
>
> > On Apr 11, 2016, at 12:36 PM, D. J. Bernstein wrote:
> >
> > I agree that the original goal of extensible "query types" in DNS (see
> > RFC 1034, third paragraph) was ruined by poor implementation work (which
> > was in turn
On Fri, Oct 21, 2016 at 03:24:35PM +0200, Hubert Kario wrote:
> Currently TLS has two alert descriptions for when there is no intersection
> between ciphers/sigalgs/groups advertises by client and ones that are enabled
> in server. It's the handshake_failure and insufficient_security alerts.
>
>
On Mon, Oct 31, 2016 at 09:30:10PM +0200, Ilari Liusvaara wrote:
> On Mon, Oct 31, 2016 at 07:11:10PM +, David Benjamin wrote:
> >
> > We could say the versions extension only applies to 1.2 and up. I.e. don't
> > bother advertising 1.1 and 1.0 as a client and servers ignore 1.1 and 1.0
> > wh
On Mon, Oct 31, 2016 at 07:11:10PM +, David Benjamin wrote:
> On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara
> wrote:
>
> > On Mon, Oct 31, 2016 at 06:43:52PM +, Matt Caswell wrote:
> > > A few supported_versions questions:
> > >
> > > 1) What should a server do if supported_versions is
On Mon, Jan 09, 2017 at 02:55:57PM -0500, Adam Langley wrote:
> On Mon, Jan 2, 2017 at 3:57 PM, Adam Langley wrote:
> > I don't expect that those who want to intercept TLS connections will
> > see a MUST NOT and go do something else. Rather I think they should
> > understand that TLS isn't suppose
On Sat, Apr 22, 2017 at 03:00:17PM +0300, Ilari Liusvaara wrote:
> On Sat, Apr 22, 2017 at 07:53:50AM -0400, Eric Rescorla wrote:
> > On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos
> > wrote:
> >
> > > On Tue, 2017-04-11 at 13:47 -0700, Eric Rescorla wrote:
> > >
> > > > Do you have an
On Sun, Apr 23, 2017 at 12:01:08PM -0400, Ryan Sleevi wrote:
> > And the 12 month update interval for intermediates is IMO just crazy,
> > and won't work properly in TLS 1.3, now that multistaple is pretty much
> > a baseline feature.
> >
>
> I have no desire to support multistaple within Chrome.
25 matches
Mail list logo
