Re: [TLS] ETSI releases standards for enterprise security and data centre management

[Kurt Roeckx]

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=x509lint,cablint,zlint


Kurt

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Broken browser behaviour with SCADA TLS

[Kurt Roeckx]

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] comments on draft-ietf-tls-tls13-19

[Kurt Roeckx]

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

Re: [TLS] comments on draft-ietf-tls-tls13-19

[Kurt Roeckx]

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] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh

[Kurt Roeckx]

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] supported_versions question

[Kurt Roeckx]

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] [solwo...@rites.uic.edu: TLS weakness in Forward Secrecy compared to QUIC Crypto]

[Kurt Roeckx]

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] analysis of wider impact of TLS1.3 replayabe data

[Kurt Roeckx]

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] [Editorial Errata Reported] RFC4492 (4633)

[Kurt Roeckx]

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] JPAKE

[Kurt Roeckx]

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] chacha/poly for http/2

[Kurt Roeckx]

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] chacha/poly for http/2

[Kurt Roeckx]

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] Fixing TLS

[Kurt Roeckx]

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

[TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

[Kurt Roeckx]

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] draft-ietf-tls-curve25519-01 and the X25519 significant bit.

[Kurt Roeckx]

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] Fwd: Clarification on interleaving app data and handshake records

[Kurt Roeckx]

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] Should we require implementations to send alerts?

[Kurt Roeckx]

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