Re: [TLS] Should we require implementations to send alerts?
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 > doing the wrong thing. Let me correct that for you: A conformant TLS 1.0 implementation will not be version intolerant. If the client does version fallback then it is guaranteed to be doing the wrong thing. Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
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 compression is dropped at the TLS layer, you can still do it at the layer above it. Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Should we require implementations to send alerts?
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 immediately anyways. > >>> Does sending the fatal alert cause a problem other than increase the > >>> likelihood of RSTs? What is the alternative considering that the next > >>> step is to close the connection anyways? > >> > >> I'm trying to explain that any requirement to send fatal alerts will be > >> difficult to implement. With the BSD sockets API, the only way to do > >> that reliable is *not* to close the socket immediately, which is > >> apparently not what you (or existing APIs) expect, and which is where > >> the difficulty lies. > > > > What about SO_LINGER? > > With full-duplex connections, it does not make a difference. TCP will > still detect a data loss event, send the RST segment, and discard the > queued fatal alert. >From what I understand, the RST is send after calling close(), shutdown(SHUT_RD) or shutdown(SHUT_RDWR) and not all data has been read from the socket or more data is received. So my understanding of making sure the other end receives it is calling close() when read() returns 0 (or an error). You might want to do shutdown(SHUT_WR) before that to indicate you're not going to send anything anymore, but that should have no effect since the other end is supposed to close the connection after receiving the alert anyway. You might want to have a timeout and close it anyway. If read() returns any data, you should of course throw it away. It seems that when you using SO_LINGER you might end up turning your non-blocking socket into a blocking one on close() (or shutdown?), and can't even tell if it was received succesfully or not. But I wonder in which cases it's important to receive the fatal alert. I guess it's the cases where it can tell you that connecting again might work, and so would only be during the handshake. The only case I can think of is something like "client certificate required", and as far as I know we don't even currently have something that says that explicitly. Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
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 density. The security should not depend on the entropy density. After the encryption you should not be able to tell what the density was. Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: Clarification on interleaving app data and handshake records
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 handshake? Have you tried running any of your tests against miTLS? Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: Clarification on interleaving app data and handshake records
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 relevant RFC sections that seem to indicate you can do this. Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-curve25519-01 and the X25519 significant bit.
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 unused, most-significant bit MUST be zero." > > If the receiver can detect that the sender is non-conforming, then it > should be able to stop talking to it on that basis alone. I don't know enough about all the various draft to know if this might be a problem or not, but I'm concerned about providing an error oracle. Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?
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 a requirement in TLS 1.2 when you want to use Curve25519? Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms
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 depend on the chosen prefix collision on SHA1, with the MD5 part in TLS 1.0 and 1.1 not adding much. It seems that disabling SHA1 in TLS 1.2 doesn't buy you anything unless you also disable TLS 1.0 and 1.1. Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fixing TLS
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 it's seems non-obvious how to get that correct implementations may delay implementing that part. Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] chacha/poly for http/2
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 would not follow the draft. Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] chacha/poly for http/2
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. > > As far as I know, OpenSSL has an outstanding interop issue with > BoringSSL where OpenSSL would not follow the draft. Oh, it has been commited after all. Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Simplifying signature algorithm negotiation
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 think that's the key thing that would need to be checked > > to see if my suggestion is viable. > > > > Looks like DigiCert's EC intermediates are P-384 and they sign SHA-256 more > often than not. > https://crt.sh/?CN=%25&iCAID=1516 This is my current count of ECDSA based signatures: ECDSA_SHA256| 1970793 ECDSA_SHA384| 53 (That's all valid certificate I know about, most of those have expired.) Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] JPAKE
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 authorisation. These use cases clearly benefit from a PAKE, i.e. > getting deriving a shared cryptographic from a weaker shared password. So when looking at things that might use JPAKE, Thread was one of the things that came up. But if you then go look, it seems to be using EC-JPAKE. Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Broken browser behaviour with SCADA TLS
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 related to TLS, but are extentions / add-ons of the browser itself. Firefox dropped support for the old way of doing extensions in version 57. They also added the WebExtensions API that is also implemented in other browsers. This required major rewrites of the extensions, and some were never changed to work with the new API. Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] ETSI releases standards for enterprise security and data centre management
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 not be issued by standard public CAs. > > top of p. 44 of > https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.1.pdf > > Has anyone set up tools to monitor the CT logs for such a sAN to see > whether that element of the BR is being honored? All the linters will give an error about that, see for instance: https://crt.sh/?id=1009623020&opt=x509lint,cablint,zlint Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Editorial Errata Reported] RFC4492 (4633)
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. Each NamedCurve value takes exactly two
> > bytes, so the floor should have been specified as 2, not 1.
> >
> > To be pedantic wouldn't it be:
> NamedCurve elliptic_curve_list<2..2^16-2>
It's a good point. Looking at various RFCs, 2..2^16-1 and
2..2^16-2 seem to be mixed all over.
Kurt
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] analysis of wider impact of TLS1.3 replayabe data
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.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [solwo...@rites.uic.edu: TLS weakness in Forward Secrecy compared to QUIC Crypto]
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 encouraged by other aspects of the DNS protocol design, but > > let me not get sidetracked here), so trying to deploy new DNS "query > > types" creates operational problems. > > I've been monitoring DANE TLSA adoption in SMTP for some time now, including > monitoring of domains where requests for the novel TLSA records encountered > misconfigured middle-boxes that drop the query. > > Initially (2 years ago), problems were widespread. Now problems are rather > rare and getting more so. Out of ~130,000 DNSSEC domains in my corpus, only > ~40 drop requests for TLSA records. Two years ago there were many thousands > out of a much smaller corpus. Don't you have to look at it the other way? From a client that's behind some broken box that tries to look up TLSA records? I would really hope that if someone deploys DNSSEC that their nameservers would actually support DNSSEC. But that doesn't mean that a client trying to look up the DNSSEC related records is able to. Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Server abort because of unrecognised vs rejected client provided parameters
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. > > While it is a step in good direction in providing users with better messages > in case of connection failure, I think there is one edge case which may ruin > the effort. > > Let's say we have a client that advertises following signature methods: > rsa-ssa-sha256 > rsa-ssa-sha384 > > and this client is connecting to server which requires use of rsa-ssa-sha512 > signatures only, but does implement weaker hashes and the requirement is just > result of administrator requiring high security. > > I think that such connection attempt should end with insufficient_security. > > Problem is, what if the server does not implement some even never RSA > signature format, but client does advertise support for them? > > I think then the connection should end with handshake_failure. So what about the case where the server does implement it, but it's been disabled? For instance because he wanted to disable MD5 he only enabled SHA-1 years ago, but then SHA-2 got implemented and only SHA-1 is enabled. Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] supported_versions question
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
> > when they see them in the version list. That keeps the protocol deployable
> > on the Internet as it exists, avoids having to evaluate too versioning
> > schemes (if you see the extension, you don't bother reading legacy_version
> > at all), while avoiding the weird behavior where, given this ClientHello:
> >
> >legacy_version: TLS 1.2
> >supported_versions: {TLS 1.1}
> >
> > TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2.
>
> Yeah, I don't think it ever makes sense to stick TLS 1.0 or 1.1 into
> supported_versions. There are good reasons to stick TLS 1.2 there tho.
Can you give some more details about those good reasons?
Kurt
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] supported_versions question
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 received but
> > > ClientHello.legacy_version != TLS1.2? Fail the handshake, or just
> > > ignore legacy_version?
> >
> > If legacy_version > TLS1.2, the spec requires server to ignore
> > legacy_version.
> >
> > The case where legacy_version < TLS1.2 IIRC isn't specified, but
> > ignoring legacy_version is reasonable in this case too.
> >
> > > 2) What should a server do if supported_versions is received,
> > > ClientHello.legacy_version == TLS1.2, but supported_versions does not
> > > contain TLS1.3 or TLS1.2 (e.g. it contains TLS1.1 or below)? Fail the
> > > handshake, use the legacy_version, or use use the versions in
> > > supported_versions?
> >
> > There's also the case where supported_versions has TLS 1.1 and TLS 1.4,
> > the latter the server has never heard about...
> >
> > > 3) If the answer to (2) above is ignore the legacy_version, and just
> > > use the versions in supported_versions, which client_version should be
> > > used in the RSA pre-master secret calculation? The one in
> > > legacy_version, or the highest one in supported_versions? Presumably
> > > it has to be the one in legacy_version, otherwise thing will fail when
> > > the client talks to a server that doesn't understand
> > > supported_versions?
> >
> > Yeah, I presume putting the version in legacy_version is the only sane
> > thing to do. But causes other problems with downgrade protection.
> >
> > OTOH, RSA key exchange is known to be very broken and is affected by
> > all kinds of downgrade (and other) attacks. So if one wants actual
> > security, it needs to be removed.
> >
>
> 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
> when they see them in the version list. That keeps the protocol deployable
> on the Internet as it exists, avoids having to evaluate too versioning
> schemes (if you see the extension, you don't bother reading legacy_version
> at all), while avoiding the weird behavior where, given this ClientHello:
>
>legacy_version: TLS 1.2
>supported_versions: {TLS 1.1}
>
> TLS 1.3 says to negotiate TLS 1.1 and TLS 1.2 says to negotiate TLS 1.2.
So I guess you're also saying that a server that implements TLS
1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should
ignore the supported_versions even when it knows about it?
I guess I have same questions but with only TLS 1.3 disabled, to
be sure when we need to look at it.
Kurt
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh
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 supposed to be intercepted and, if they want > > to do that, then they're going to be breaking the spec in places. I > > think they're going to do that no matter what we do so I want to > > ensure that these "interceptable" implementations don't inadvertently > > proliferate. (Because if everything Just Works when you accidentally > > copy such a config to your frontend server, then it'll happen.) > > I had understood that the desire from some large institutions to > intercept TLS connections arose only in a datacenter setting. However, > based on private conversations, it appears that at-least one of those > institutions does this on their public frontends and will very likely > do something worse than persistent ECDHE if that's not possible with > TLS 1.3. Why can't they just decrypt it, possibly encrypt it with some other key, and store that? Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] comments on draft-ietf-tls-tls13-19
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 any thoughts on what text we should insert here? I admit > > > > to being not that familiar with the practical matters of OCSP > > > > stapling. > > > > > > My issue with OCSP when used under TLS was how to determine the > > > validity of the response when the nextUpdate field is missing. I've > > > added some text for that introducing an (arbitrary) upper limit at: > > > https://github.com/tlswg/tls13-spec/pull/974 > > > > > > This text looks good to me, but it is is a normative change and we've > > been through WGLC so I'd like to hear from a few other people that they're > > OK > > with it (or have the chairs tell me that silence is consent). David > > Benjamin? > > Richard Barnes? Ryan Sleevi? > > I searched what minimum standards for "public" CAs say. The maximum > lifetime there is 10 days (but IIRC some widely-used root program has > lower limit, might have been 7 days).. > > Anybody happens to know a CA that doesn't put NextUpdate in? If so, > what's the OCSP issuance frequency? The CA Browser baseline requirements have this in 4.9.7: For the status of Subscriber Certificates: If the CA publishes a CRL, then the CA SHALL update and reissue CRLs at least once every seven days, and the value of the nextUpdate field MUST NOT be more than ten days beyond the value of the thisUpdate field For the status of Subordinate CA Certificates: The CA SHALL update and reissue CRLs at least (i) once every twelve months and (ii) within 24 hours after revoking a Subordinate CA Certificate, and the value of the nextUpdate field MUST NOT be more than twelve months beyond the value of the thisUpdate field. And in 4.9.10: For the status of Subscriber Certificates: The CA SHALL update in formation provided via an Online Certificate Status Protocol at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days. For the status of Subordinate CA Certificates: The CA SHALL update information provided via an Online Certificate Status Protocol at least (i) every twelve months and (ii) within 24 hours after revoking a Subordinate CA Certificate. So for OCSP of a subordinate CAs there doesn't seem to be any requirement for a nextUpdate. Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] comments on draft-ietf-tls-tls13-19
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. That it's specified > is great, but I believe multistaple is, for the general _browser_ case, > unnecessary. That's not to say it's not useful in other venues or in > specialized cases, which is the only reason I haven't complained here. I think your general browser case is that the browsers have worked around it by having a different mechanism to revoke them. I believe it would be better that browsers didn't have to do this, so that it worked properly in all cases. Kurt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
