[TLS] No cypher overlap (was: ban more old crap)
I see one possible problem with TLS1.3 not being a superset of TLS1.2. Consider the following: Server which supports TLSv1.3 but is configured to accept only AES256 ciphers. Client which advertises TLSv1.3, but no support for AES256-GCM. The client advertises also CBC ciphers (both AES128 and AES256) as it wants to be able to connect to legacy servers too. Should such a connection end up with TLS1.2 with AES-CBC ciphersuite, or should it be aborted? I think we should go for continue connection with downgraded protocol, but explicitly say that it may not happen if the negotiated ciphersuite would be DES, RC4, export grade... That would allow us to reiterate in the TLS1.3 spec that they are a big no-no, and that if you claim support for TLS1.3 you should never negotiate them with a similarly modern peer. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] No cypher overlap (was: ban more old crap)
On Tue, Jul 28, 2015 at 05:41:58PM +0200, Hubert Kario wrote: > I see one possible problem with TLS1.3 not being a superset of TLS1.2. > > Consider the following: > Server which supports TLSv1.3 but is configured to accept only AES256 > ciphers. > > Client which advertises TLSv1.3, but no support for AES256-GCM. The client > advertises also CBC ciphers (both AES128 and AES256) as it wants to be able > to connect to legacy servers too. > > Should such a connection end up with TLS1.2 with AES-CBC ciphersuite, or > should it be aborted? We already see a similar dilemma with clients that (artificially) support only SSLv2 ciphersuites, but advertise TLS protocol versions. OpenSSL will first choose a common protocol (TLS 1.x) and then fail to find any shared ciphers. To complete the connection, the client must explicitly request only SSL 2.0. There is at present no filtering out of protocol choices for lack of compatible ciphers. > I think we should go for continue connection with downgraded protocol, but > explicitly say that it may not happen if the negotiated ciphersuite would be > DES, RC4, export grade... In that case, it should be said that a client MUST NOT advertise TLS 1.3 unless it offers at least one of the TLS 1.3 MTI ciphers (or perhaps less restrictive at least one TLS 1.3 compatible cipher). Otherwise, there'll be lots of clients whose TLS libraries advertise 1.3 (just because they implement the protocol), but whose cipher configuration includes only TLS 1.2 (or lower) suites (because the application configuration has not been updated). Punishing those clients by having servers abort the handshake is a bad idea. The right outcome is use of TLS 1.2, whether because client implementations of 1.3 need to check that adequate cipher suites are available, or because servers negotiate 1.2 when 1.3 is impossible. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Commentary on the client authentication presentation slides
Sent from the right email this time. (Sorry folks who got it twice. One of these days I'll not mess this up! :-) ) On Tue, Jul 28, 2015 at 6:28 PM David Benjamin wrote: > On Fri, Jul 24, 2015 at 1:02 AM Andrei Popov > wrote: > >> Thanks for the detailed comments, Ilari. >> >> Based on the discussion at the TLS WG meeting, I created a pull request: >> https://github.com/tlswg/tls13-spec/pull/209 >> >> > - Mechanism like proposed looks dangerous when combined with HTTP/2. >> I believe the same issue already exists in HTTP/1 where multiple requests >> can be in flight at the same time. >> The way we handle this in HTTP/1 is by having the server application >> query the HTTP stack for the client cred. >> If there's no cred available, the HTTP stack triggers client >> authentication (and the server application waits until the client cred is >> provided so it can authorize the request). >> > > The issue only exists in HTTP/1 if the client does pipelining. As far as I > know, no current[*] major browser deploys HTTP pipelining by default. > Chrome certainly doesn't. > > [*] Wikipedia says Opera used to do it before they switched to Chromium? > > Are you intending that this mechanism be enabled by default for HTTP/2 or > would the prohibition against renego still apply? Without any way for the > client to tie the CertificateRequest to the HTTP request that triggered it, > this mechanism would have many of the same problems as renego as far as > HTTP/2 is concerned. (I realize Microsoft has a draft floating around for a > TLS_RENEG_PERMITTED HTTP/2 setting. The setting can control this too I > suppose.) > > >> > - Regarding last point about interleaving: Assuming the scheme works >> in 1RTT (and I see no reason for requiring more rounds), you can't >> prevent application_data transmission after certificate_request. >> We discussed at the meeting that this restriction cannot be implemented. >> Instead, a server may block the processing of any in-flight requests >> while waiting for the client to authenticate (if the server's architecture >> requires this). >> > > This requires the server buffer arbitrarily many requests from the client, > which seems poor. For renego-based mid-stream auth, I believe Apache httpd > does not do this and will actually fail the connection on interleave. (But > I've never tested this, just glanced at how they use OpenSSL, so I could be > wrong.) > > > - The certificate_types field in CertificateRequest is pretty much >> useless, since all supported algorithms are of signature type. >> If the signature_algorithms extension officially becomes MTI, then >> perhaps we can discus getting rid of certificate_types in the >> CertificateRequest. Except we may want to use this field when we introduce >> new certificate types (e.g. something like IEEE1609 certs). >> >> > - How does extension_values work? If multiple values for one >> OID are allowed, then the OID/value pair is repeated, once for >> each value? >> Multiple values are DER-encoded per RFC that defines the OID that allows >> multiple values. >> The idea here is to simply reuse the existing OID-parsing code. A TLS >> implementation (or certificate API) that recognizes the OID in the cert, >> already knows how to parse its representation. A TLS implementation (or >> certificate API) that does not recognize the OID in the cert will also skip >> this OID in the extension_values. In the degenerate case, an implementation >> may choose to skip all extension_values. >> >> Cheers, >> >> Andrei >> >> -Original Message- >> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ilari Liusvaara >> Sent: Monday, July 20, 2015 4:11 PM >> To: tls@ietf.org >> Subject: [TLS] Commentary on the client authentication presentation slides >> >> Some commentary on client authentication slides (there is no linked draft >> nor other material yet). >> >> - Mechanism like proposed looks dangerous when combined with HTTP/2. >> Multiplexed protocols are in general not safe to authenticate without >> application-layer signaling (which can be implicit via separate >> connections), especially if dealing with something like web >> environment. >> - Regarding last point about interleaving: Assuming the scheme works >> in 1RTT (and I see no reason for requiring more rounds), you can't >> prevent application_data transmission after certificate_request. >> The best that can be done is to require the client to send all >> the authentication-related data in one go. >> - The certificate_types field in CertificateRequest is pretty much >> useless, since all supported algorithms are of signature type. >> - One can't just remove fields without breaking parse compatiblity, >> but adding field breaks parse compatiblity too, so removing >> field at the same time isn't a problem. >> - How does extension_values work? If multiple values for one >> OID are allowed, then the OID/value pair is repeated, once for >> each value? >> >> >> >> -I
Re: [TLS] draft-shore-tks-dnssec-chains-extension
On Wed, Jul 22, 2015 at 1:16 PM, Viktor Dukhovni
wrote:
> 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 with all clients.
>
> >From the root to its own TLSA RRset, however, this can be complicated
> in the presence of CNAMEs:
>
> www.example.com. IN CNAME cdn.example.net.
> cdn.example.net. IN A 192.0.2.1
> _443._tcp.cdn.example.net. IN CNAME _dane.example.net.
> _dane.example.net. IN TLSA 2 0 1
>
> In this example, three leaf RRsets need to be verified back to the
> root (with notable overlaps in the chains):
>
> www.example.com. IN CNAME
> _443._tcp.cdn.example.net. IN CNAME
> _dane.example.net. IN TLSA
>
> How should these be organized? It seems to me that the immediate
> answer that gets the client going in the right direction is the
> first CNAME, which enables to construct the TLSA base domain,
> and then to follow the second CNAME to the ultimate TLSA RRset.
>
There are a number of possibilities here, including more complicated data
structures. But I think we can use the current linear chain structure and
have it composed of multiple sequences corresponding to intersecting
branches of the DNS tree.
For the following hypothetical example:
_443._tcp.www.example.com. IN CNAMEca.example.net.
ca.example.net. IN TLSA 2 0 1
the getdns library's validation chain function currently returns (RRSIGs
omitted for brevity):
_443._tcp.www.example.com. CNAME
ca.example.net. TLSA
example.com. DNSKEY
example.com. DS
com. DNSKEY
com. DS
. DNSKEY
example.net. DNSKEY
example.net. DS
net. DNSKEY
net. DS
Should everything other than the first CNAME be in additional
> records? Should all the above (with their RRSIGs) be in the answer
> section, with the union of the supporting DNSKEY/RRSIG/DS records
> as additional?
>
> I tried to ask a related question during the meeting, but bandwidth
> to explain the context was limited: Should proofs of non-delegation
> be included, to keep gTLDs and ccTLDs honest for some future CT for
> DNS? Specifically, suppose you see:
>
> _443._tcp.www.example.com. IN TLSA
>
> with an RRSIG from the ".com" zone, should there also be NSEC/NSEC3
> records that demonstrate that "example.com" (and www.example.com)
> are not delegated? (Such records might then be subject to "gossip"
> or related "transparency" counter-measures).
>
I'd prefer to wait till the trans-ct-dnssec draft has progressed a bit more
before considering DNSSEC key transparency issues.
It looks like that draft proposes SCT RRs (with DS+chain data in them,
signed by log providers), so we could in the future incorporate SCT RRs in
the chain. However do we really need to? The TLS server is the one doing
the DNS queries, so it could perform the SCT checks against the logs it
trusts, while querying the chain records, and then build the validated
chain. I'm not sure there is a need for the TLS client to additionally do
these log checks, so it doesn't need to have that info delivered in the
chain.
> > As for ekr's question on why not stuff this inside X.509, that would not
> > be compatible with tls raw pulic keys that only contain a SBKI, and drag
> > back into the protocol more ASN.1 parsing and containers.
>
> This really can't go in the certificate, because then certificates
> would have to be updated as often as RRSIGS are regenerated. That
> seems exceedingly unlikely to be deployable.
>
I believe Eric's question was about why this couldn't be done via a new
'Certificate Type' (and not about embedding the chain in the X.509 cert). I
presume the idea being the new certificate type would allow both the
server's X.509 certificate chain and the corresponding DANE/DNSSEC chain to
be delivered in the server's Certificate Message. I believe the argument
for doing it via a new TLS extension was that it would allow us to mandate
the use of the DANE chain ("Must staple DANE") via the X.509 TLS Feature
Extension.
Shumon Huque
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-shore-tks-dnssec-chains-extension
On 7/28/15 5:44 PM, Shumon Huque wrote:
> I'd prefer to wait till the trans-ct-dnssec draft has progressed a bit
> more before considering DNSSEC key transparency issues.
>
> It looks like that draft proposes SCT RRs (with DS+chain data in them,
> signed by log providers), so we could in the future incorporate SCT RRs
> in the chain.
That draft really is pretty immature and at this point it's not
clear whether and how it's going to progress. Paul Wouters can
speak for himself about where he thinks the draft needs to go
but I think it does bear pointing out that he's offered to help
out with content, given that he's got considerable DNS and DNSSEC
expertise. If the document does continue to progress I would
expect quite substantial changes.
> I believe Eric's question was about why this couldn't be done via a new
> 'Certificate Type' (and not about embedding the chain in the X.509
> cert). I presume the idea being the new certificate type would allow
> both the server's X.509 certificate chain and the corresponding
> DANE/DNSSEC chain to be delivered in the server's Certificate Message. I
> believe the argument for doing it via a new TLS extension was that it
> would allow us to mandate the use of the DANE chain ("Must staple DANE")
> via the X.509 TLS Feature Extension.
Well, sort of. We did talk about creating a new certificate
extension rather than a TLS extension but opted not to. The
one advantage of an X.509 extension would have been that it wouldn't
require protocol changes, but it still would have required modifying
both the server and the endpoint.
Melinda
--
Melinda Shore
No Mountain Software
melinda.sh...@nomountain.net
"Software longa, hardware brevis."
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-shore-tks-dnssec-chains-extension
On Tue, Jul 28, 2015 at 09:44:34PM -0400, Shumon Huque wrote:
> For the following hypothetical example:
>
> _443._tcp.www.example.com. IN CNAMEca.example.net.
> ca.example.net. IN TLSA 2 0 1
This is simpler than the general case, everything is still "linear",
because there's only a CNAME chain leading to the TLSA RRset.
More generally, there's also a CNAME chain leading to the TLSA base
domain:
www.example.com. IN CNAME www.example.com.cdn.example.net.
www.example.com.cdn.example.net IN CNAME node1.example.net.
node1.example.net. IN A 192.0.2.1
_443._tcp.node1.example.net. IN CNAME ca.example.net.
ca.example.net IN TLSA 2 0 1
Here, we have CNAME (perhaps via a DNAME) indirection from the SNI
name (www.example.com) to the actual TLSA base domain (node1.example.net).
And then more CNAME records from there to the CDN provider's TLSA
RRset.
This is no longer the DNS response to a single query (iterative
resolvers generally chase CNAMEs), since one first CNAME expands
the original target hostname to obtain the TLSA base domain (provided
the CNAME chain is validated end-to-end) and then CNAME expands
the _443._tcp. prefixed base domain to find the TLSA RRset.
> the getdns library's validation chain function currently returns (RRSIGs
> omitted for brevity):
>
> _443._tcp.www.example.com. CNAME
> ca.example.net. TLSA
>
> example.com. DNSKEY
> example.com. DS
> com. DNSKEY
> com. DS
> . DNSKEY
> example.net. DNSKEY
> example.net. DS
> net. DNSKEY
> net. DS
The getdns library is unlikely to handle the fully general case,
because first the TLSA base domain has to be found.
> It looks like that draft proposes SCT RRs (with DS+chain data in them,
> signed by log providers), so we could in the future incorporate SCT RRs in
> the chain. However do we really need to? The TLS server is the one doing
> the DNS queries, so it could perform the SCT checks against the logs it
> trusts, while querying the chain records, and then build the validated
> chain. I'm not sure there is a need for the TLS client to additionally do
> these log checks, so it doesn't need to have that info delivered in the
> chain.
The TLS server is not trusted, the whole point is detect malfeasance,
where the DNS operator and TLS server conspire to lie (to selected
clients).
> > This really can't go in the certificate, because then certificates
> > would have to be updated as often as RRSIGS are regenerated. That
> > seems exceedingly unlikely to be deployable.
> >
>
> I believe Eric's question was about why this couldn't be done via a new
> 'Certificate Type' (and not about embedding the chain in the X.509 cert). I
> presume the idea being the new certificate type would allow both the
> server's X.509 certificate chain and the corresponding DANE/DNSSEC chain to
> be delivered in the server's Certificate Message. I believe the argument
> for doing it via a new TLS extension was that it would allow us to mandate
> the use of the DANE chain ("Must staple DANE") via the X.509 TLS Feature
> Extension.
I see. I think the question of whether "must staple DANE" is
supported or not is quite orthogonal to the question of how DANE
stapled data is encoded.
The disadvantage of this being a new certificate type is that AFAIK
it would then not be orthogonal to the choice between X.509 chains
and raw public keys. We might then have a (small) combinatorial mess:
traditional X.509 chain
X.509 chain with stapled DANE evidence
raw public key
raw public key with stapled DANE evidence
I think the extension is a more logical separation of duties, but
I am willing to hear contrary arguments.
--
Viktor.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-shore-tks-dnssec-chains-extension
On Tue, Jul 28, 2015 at 10:05 PM, Viktor Dukhovni
wrote:
> On Tue, Jul 28, 2015 at 09:44:34PM -0400, Shumon Huque wrote:
>
> This is no longer the DNS response to a single query (iterative
> resolvers generally chase CNAMEs), since one first CNAME expands
> the original target hostname to obtain the TLSA base domain (provided
> the CNAME chain is validated end-to-end) and then CNAME expands
> the _443._tcp. prefixed base domain to find the TLSA RRset.
>
Hmm, I guess the DANE ops draft says to look for TLSA records at the alias
target rather than the owner name. This doesn't seem to be how many early
HTTPS sites are deploying TLSA records though, e.g. www.ietf.org.
> the getdns library's validation chain function currently returns (RRSIGs
> > omitted for brevity):
> >
> > _443._tcp.www.example.com. CNAME
> > ca.example.net. TLSA
> >
> > example.com. DNSKEY
> > example.com. DS
> > com. DNSKEY
> > com. DS
> > . DNSKEY
> > example.net. DNSKEY
> > example.net. DS
> > net. DNSKEY
> > net. DS
>
> The getdns library is unlikely to handle the fully general case,
> because first the TLSA base domain has to be found.
>
It probably doesn't today. I'll check into this.
> > It looks like that draft proposes SCT RRs (with DS+chain data in them,
> > signed by log providers), so we could in the future incorporate SCT RRs
> in
> > the chain. However do we really need to? The TLS server is the one doing
> > the DNS queries, so it could perform the SCT checks against the logs it
> > trusts, while querying the chain records, and then build the validated
> > chain. I'm not sure there is a need for the TLS client to additionally do
> > these log checks, so it doesn't need to have that info delivered in the
> > chain.
>
> The TLS server is not trusted, the whole point is detect malfeasance,
> where the DNS operator and TLS server conspire to lie (to selected
> clients).
>
Yeah, I had a feeling you'd say this :-) Fair enough, that's an additional
threat we should take into account.
> > > This really can't go in the certificate, because then certificates
> > > would have to be updated as often as RRSIGS are regenerated. That
> > > seems exceedingly unlikely to be deployable.
> > >
> >
> > I believe Eric's question was about why this couldn't be done via a new
> > 'Certificate Type' (and not about embedding the chain in the X.509
> cert). I
> > presume the idea being the new certificate type would allow both the
> > server's X.509 certificate chain and the corresponding DANE/DNSSEC chain
> to
> > be delivered in the server's Certificate Message. I believe the argument
> > for doing it via a new TLS extension was that it would allow us to
> mandate
> > the use of the DANE chain ("Must staple DANE") via the X.509 TLS Feature
> > Extension.
>
> I see. I think the question of whether "must staple DANE" is
> supported or not is quite orthogonal to the question of how DANE
> stapled data is encoded.
>
Encoded yes, but not necessarily on what protocol element carries the
encoding. It depends on what mechanism is being used for the must-staple
assertion. The X.509 TLS feature extension mechanism requires a list of TLS
extension values to be specified. Using a new TLS certificate type would
not be compatible with that.
The disadvantage of this being a new certificate type is that AFAIK
> it would then not be orthogonal to the choice between X.509 chains
> and raw public keys. We might then have a (small) combinatorial mess:
>
> traditional X.509 chain
> X.509 chain with stapled DANE evidence
> raw public key
> raw public key with stapled DANE evidence
>
> I think the extension is a more logical separation of duties, but
> I am willing to hear contrary arguments.
>
Yes, I agree.
Shumon Huque.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-shore-tks-dnssec-chains-extension
On Tue, Jul 28, 2015 at 10:43:29PM -0400, Shumon Huque wrote: > > This is no longer the DNS response to a single query (iterative > > resolvers generally chase CNAMEs), since one first CNAME expands > > the original target hostname to obtain the TLSA base domain (provided > > the CNAME chain is validated end-to-end) and then CNAME expands > > the _443._tcp. prefixed base domain to find the TLSA RRset. > > > > Hmm, I guess the DANE ops draft says to look for TLSA records at the alias > target rather than the owner name. This doesn't seem to be how many early > HTTPS sites are deploying TLSA records though, e.g. www.ietf.org. With www.ietf.org, the TLSA record for HTTP was there long before the DANE ops draft: www.ietf.org. IN CNAME www.ietf.org.cdn.cloudflare-dnssec.net. _443._tcp.www.ietf.org. IN TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6 www.ietf.org.cdn.cloudflare-dnssec.net. IN A 104.20.1.85 www.ietf.org.cdn.cloudflare-dnssec.net. IN A 104.20.0.85 The DANE ops draft says to look at the end of the CNAME chain (if secure) first, and if there are no TLSA RRs there, only then stick with the original name. So sites that do it the old way (as above) also work. But with the new model cloudflare can provision the "3 1 1" record on their end. In the case of DANE stapling, the CNAME chasing (or not) is done by the server, which should ideally know whether it has a TLSA RRset for the requested SNI domain, or whether it should construct a CNAME chain starting with that name. The point is that clients have to be prepared for either outcome. In essence the server is a DNS proxy for a client that is either cut-off from DNSSEC, or simply unwilling to pay the latency cost. The data consumed by the client is the same whether acquired unilaterally, or via the server. One could almost imagine a VPN tunnel set up by the client and server between the DNS caches on either end, except that for multiple reasons that mental model is rather a crude approximation of the details. It can however be a useful source of inspiration. > > The TLS server is not trusted, the whole point is detect malfeasance, > > where the DNS operator and TLS server conspire to lie (to selected > > clients). > > Yeah, I had a feeling you'd say this :-) Fair enough, that's an additional > threat we should take into account. If and when CT for DNSSEC comes into the picture. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
