Is table 1 correct?
+---+-++
| Symmetric | ECC | DH/DSA/RSA |
+---+-++
| 80| 163 |1024|
|112| 233 |2048|
I have never understood why 4492 doesn't claim forward secrecy for
ECDH_anon suites. Can someone explain why this doesn't have an 'E'?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
I'd like to see the bits of the cipher suite associated entirely with
ephemeral data tied together roughly by security margin, to avoid
combinations that don't make sense (e.g., straw men of RSA384 + AES256
or AES256 + CRC32). This means: the type/size of the (EC)DHE group and
the symmetric cipher
The current recommendations in NIST SP 800-57 Part 1, Table 2 suggest that
256-bit symmetric strength is matched by ECC strength of 512+ bits. All
of the ECC sizes given in Table 2 are slightly different than given below,
and most are given as ranges, not single values.
http://csrc.nist.gov/publi
On 22 July 2015 at 01:50, Kyle Rose wrote:
> I'd like to see the bits of the cipher suite associated entirely with
> ephemeral data tied together roughly by security margin
I've seen this argument several times, but there are reasons why you
might want a non-homogenous strength profile.
The argu
On Jul 22, 2015, at 10:44 AM, Martin Thomson wrote:
> I have never understood why 4492 doesn't claim forward secrecy for
> ECDH_anon suites. Can someone explain why this doesn't have an 'E’?
I wasn’t there for the original 4492, but I think it’s because the old
anonymous ciphersuites were cal
On 22 July 2015 at 02:20, Yoav Nir wrote:
> They both provide forward secrecy.
The draft specifically excludes ECDH_anon from the following
statement, implying otherwise:
The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward
secrecy.
It might be a good idea to revise that.
PR at
https://github.com/tlswg/rfc4492bis/blob/master/draft-ietf-tls-rfc4492bis.xml ?
> On Jul 22, 2015, at 11:23 AM, Martin Thomson wrote:
>
> On 22 July 2015 at 02:20, Yoav Nir wrote:
>> They both provide forward secrecy.
>
> The draft specifically excludes ECDH_anon from the following
> st
>> I have never understood why 4492 doesn't claim forward secrecy for
>> ECDH_anon suites. Can someone explain why this doesn't have an 'E’?
>
> I wasn’t there for the original 4492, but I think it’s because the old
> anonymous ciphersuites were called DH_anon (no E).
>
> They both provide fo
On Wed, Jul 22, 2015 at 02:16:43AM -0700, Martin Thomson wrote:
> On 22 July 2015 at 01:50, Kyle Rose wrote:
> > I'd like to see the bits of the cipher suite associated entirely with
> > ephemeral data tied together roughly by security margin
>
> I've seen this argument several times, but there a
> Is table 1 correct?
>
> +---+-++
> | Symmetric | ECC | DH/DSA/RSA |
> +---+-++
> | 80| 163 |1024|
> |112| 233 |2048
Ilari Liusvaara writes:
>Furthermore, comparing the strengths of kex, auth, ciphering and PRF seems
>like comparing apples, orangles, pears and kumquants.
>
>Even if the nominal strengths are the same, the scaling of strengths is going
>to be different (e.g. the quadric vs. linear sub-treshold sc
>>Furthermore, comparing the strengths of kex, auth, ciphering and PRF seems
>>like comparing apples, orangles, pears and kumquants.
>>
>>Even if the nominal strengths are the same, the scaling of strengths is going
>>to be different (e.g. the quadric vs. linear sub-treshold scaling for ECDH vs.
>>
On 22 July 2015 at 02:29, Yoav Nir wrote:
> PR at
> https://github.com/tlswg/rfc4492bis/blob/master/draft-ietf-tls-rfc4492bis.xml
> ?
https://github.com/tlswg/rfc4492bis/pull/6
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/t
I do like the dnssec-chain-extension.
I think the server should stick to one chain, from the root to itself,
so it does not have to deal with variable chain blobs per client.
That will allow server code to stick to something like hourly
regenerating the blob for use with all clients.
I do stron
How about removing the RSA/ECDSA from the cipher suite, and making the
SigAlgs extension mandatory for connections requiring authentication?
That halves the number of cipher suites and eliminates an unnecessary
redundancy, while keeping the rest of the cipher suite negotiation
logic intact.
Kyle
Dear all,
the full recording (synchronized video, audio, slides and jabber room) of the
TLS WG session at IETF 93 is available at the following URL:
http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#TLS
In case of problems with the playout, just drop an e-mail to
ietf-supp...@meetecho
Dear all,
the full recording (synchronized video, audio, slides and jabber room) of the
TLS 2nd WG session at IETF 93 is available at the following URL:
http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#TLS_II
In case of problems with the playout, just drop an e-mail to
ietf-supp...@m
On Wednesday, July 22, 2015 10:30:24 am Kyle Rose wrote:
> How about removing the RSA/ECDSA from the cipher suite, and making the
> SigAlgs extension mandatory for connections requiring authentication?
> That halves the number of cipher suites and eliminates an unnecessary
> redundancy, while keepi
On Wednesday, July 22, 2015 07:36:50 am Martin Thomson wrote:
> On 22 July 2015 at 02:29, Yoav Nir wrote:
> > PR at
> > https://github.com/tlswg/rfc4492bis/blob/master/draft-ietf-tls-rfc4492bis.xml
> > ?
>
> https://github.com/tlswg/rfc4492bis/pull/6
Could the cipher suite names be officially
On 22 July 2015 at 19:07, Dave Garrett wrote:
> Could the cipher suite names be officially changed to add the 'E' to them?
> It'd make things simpler to be consistent.
I'd be OK with that. I didn't do it in the PR, but would be happy to
make a new one.
_
I’d like to hear from the chairs if it’s OK to rename stuff in the IANA
registry.
That has some implications for implementations that use these names.
Not to mention that the same issue applies to DH(E)_anon
> On Jul 22, 2015, at 7:09 PM, Martin Thomson wrote:
>
> On 22 July 2015 at 19:07, Da
On Wed, Jul 22, 2015 at 07:45:17AM -0400, Paul Wouters wrote:
> I think the server should stick to one chain, from the root to itself,
> so it does not have to deal with variable chain blobs per client.
> That will allow server code to stick to something like hourly
> regenerating the blob for use
On 22 July 2015 at 19:12, Yoav Nir wrote:
> I’d like to hear from the chairs if it’s OK to rename stuff in the IANA
> registry.
>
> That has some implications for implementations that use these names.
>
> Not to mention that the same issue applies to DH(E)_anon
I believe that renaming entries in
On Wednesday, July 22, 2015 01:20:52 pm Martin Thomson wrote:
> I believe that renaming entries in the IANA registry is possible.
Negotiated FFDHE is renaming an extension identifier in the IANA registry, so
this is not an entirely new issue.
https://datatracker.ietf.org/doc/draft-ietf-tls-negoti
> I'd be OK with that. I didn't do it in the PR, but would be happy to make a
> new one.
Please do.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
One of the topics of discussion at the WG discussion was whether
ServerConfiguration.expiration_date should be an absolute or relative value.
Subodh (CC) dug into our production data and found that nearly half of the TLS
errors we see in production (end user to edge/origin) are due to date misma
On Wed, Jul 22, 2015 at 9:55 PM, Blake Matheny wrote:
> One of the topics of discussion at the WG discussion was whether
> ServerConfiguration.expiration_date should be an absolute or relative
> value. Subodh (CC) dug into our production data and found that nearly half
> of the TLS errors we see
Consensus was my current WIP proposal is not viable, for some of the following
main reasons:
1) cost/benefit analysis doesn't seem to be worth it
2) backwards compatibility handling
3) some argue harder to implement; others argue easier
To start, I'll note that I have not submitted a PR yet.
Th
On Wed, Jul 22, 2015 at 9:55 PM, Blake Matheny
mailto:bmath...@fb.com>> wrote:
One of the topics of discussion at the WG discussion was whether
ServerConfiguration.expiration_date should be an absolute or relative value.
Subodh (CC) dug into our production data and found that nearly half of the
I guess what I'm trying to get at is the following:
Are there a lot of people whose clocks are accurate enough that they will
be able to connect to the server and check the certificate/OCSP but not
accurate enough to process ServerConfiguration if it is in absolute time.
On Wed, Jul 22, 2015 at 10
Ahh. I can't tell, the data I have is only clients with very very broken clocks
who failed validation as a result. My assumption would be that there is a much
larger number of clients that fit what you described (cert/OCSP check passes,
but ServerConfiguration would not be). Since I don’t have t
On Wed, 22 Jul 2015, Viktor Dukhovni wrote:
I think the server should stick to one chain, from the root to itself,
so it does not have to deal with variable chain blobs per client.
That will allow server code to stick to something like hourly
regenerating the blob for use with all clients.
Fr
On Wed, Jul 22, 2015 at 05:23:39PM -0400, Paul Wouters wrote:
> >Should everything other than the first CNAME be in additional
> >records?
>
> I think so.
>
> > Should all the above (with their RRSIGs) be in the answer
> >section, with the union of the supporting DNSKEY/RRSIG/DS records
> >as ad
One place we may run into a lot of those clients are on machines
like the Raspberry Pi and Beaglebone machines. These boards do
not include clock chips, so the machines must get the current
time via NTP every time they power on. If there is a problem
with NTP, or if the shell script to set the
Hubert Kairo found quite a few more spots in need of explicit error
designations, which have been amended into PR #201.
https://github.com/tlswg/tls13-spec/pull/201
I just noticed one error in the current draft text that was wrong and added a
fix for that as well. The Server Hello section said t
Kyle Rose writes:
>In that case, we should dispense with any larger key sizes and recommend
>exactly one per algorithm, and vary only on algorithm. Adopting this would
>simplify things even further by reducing the cipher set list by an order of
>magnitude.
Yup.
>Sadly, I'm guessing there are nu
On Thu, Jul 23, 2015 at 3:38 AM, Bill Frantz wrote:
> One place we may run into a lot of those clients are on machines like the
> Raspberry Pi and Beaglebone machines. These boards do not include clock
> chips, so the machines must get the current time via NTP every time they
> power on. If there
38 matches
Mail list logo
