Re: [TLS] Call for adoption of draft-farrell-tls-wkesni
On Wed 2022-06-08 14:17:03 -0400, Sean Turner wrote: > 1) Whether you are willing to review and contribute to this I-D, and > 2) Whether you support adopting this I-D as a WG item. > > Please include any additional information that is helpful in understanding > your position. > > [0] https://datatracker.ietf.org/doc/draft-farrell-tls-wkesni/ > [1] > https://datatracker.ietf.org/meeting/113/materials/slides-113-dispatch-a-well-known-url-for-publishing-echconfiglists-00 I am willing to review and comment on this I-D, and I believe it should be adopted by the WG. Having a reasonable and standardized way to publish and retrieve ECH config information is critical to making ECH effective, and having full WG discussion about how the mechanisms work (and how they interact with different possible ECH architectures) is worthwhile. I think we'll only get that level of full consideration with WG adoption of this draft. --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OCSP in RFC7525bis
On Mon 2022-01-24 13:06:13 +, John Mattsson wrote: > I think another omission in RFC7525 that should be fixed in RFC7525 is > a discussion on certificate life-times, which is often discussed > together with revocation checking- Short-lived certificates is an > improvement over long-lived certificates, but not at all a replacement > for revocation checking. This might be overstating the case a little bit. If revocation checking is done by OCSP stapling, then the OCSP validity window *is* in effect the duration of a "short-lived certificate". To the extent that a short-lived certificate has the same validity period as an OCSP response, it is indeed a replacement for revocation checking. As an example, the validity window of the stapled OCSP response i see according to the cert i get on port 443 of www.ietf.org has this validity window: This Update: Fri Jan 21 01:21:02 UTC 2022 Next Update: Fri Jan 28 00:36:02 UTC 2022 But when i query the OCSP responder directly i get this validity window: This Update: Mon Jan 24 01:21:00 UTC 2022 Next Update: Mon Jan 31 00:36:00 UTC 2022 The week-long range is pretty comon, and a week-long certificate would offer just as much protection against certificate misuse (an adversary misusing a certificate with stapled OCSP could cache the last "good" OCSP response and continue stapling it until it expires). So unless "revocation checking" is defined to mean "out-of-band confirmation with the issuing authority" (which would introduce both latency and privacy concerns, so let's not go there), then a short-lived certificate is indeed a replacement for revocation checking. However, under the current certificate transparency regime, short-lived certificates pose a challenge to CT logs, which scale with the number of certificates issued over a given time period. Replacing every 3-month certificate with a corresponding number of 1-week certificates would increase the size of CT logs by a factor of at least 12 -- probably more, since certificates are generally issued with some overlap to account for server-side work at cert transition and client-side clock skew. So, arguably, the advantage of revocation checking via OCSP stapling over short-lived certificates today has to do with keeping CT logs a manageable size, not with any particular security gain in terms of revocation functionality. --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Uta] OCSP in RFC7525bis
On Fri 2022-01-21 11:56:04 -0500, Viktor Dukhovni wrote: >> On 21 Jan 2022, at 9:48 am, Daniel Kahn Gillmor >> wrote: > >> Do you think that DNSSEC should be soft-fail for CAA checks, or should >> we urge the CAs to be more strict here? Perhaps that would be another >> recommendation. > > CAA lookups must not softfail. This needs to be the case whether the > domain is signed or not. For signed domains this means that validation > of the response (positive or denial of existence) must succeed. Bogus > replies, lame delegations, timeouts, REFUSED, SERVFAIL, ... need to all > be hard errors (for signed and unsigned domains alike). fwiw, Let's Encrypt's ACME-compliant CA implementation "boulder" apparently does not softfail for CAA validation: https://github.com/letsencrypt/boulder/issues/5903#issuecomment-1018932892 So there's at least one piece of good news in this thread. --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Uta] OCSP in RFC7525bis
On Fri 2022-01-21 15:23:56 +, Salz, Rich wrote: > Second, there is the history of poor behavior by some CA's, which > leads to the primary user agent (browsers, or perhaps TLS runtimes) > not being able to just completely trust them. Perhaps that historic > era has passed, and it is time for user agents to end their probation > of CA's? Not for me to say. The argument of "we don't trust (some of) the CAs" is usually used to mean "we are not willing to accept their cryptographic assertions of identity in certain contexts". But here, you're using it to mean "we are going to accept their cryptographic assertions of identity even in contexts that they claim are not valid". This is a surprising inversion. --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Uta] OCSP in RFC7525bis
Hi Ryan-- I share your skepticism, but i'm still trying to salvage something useful -- for the purpose of defending against CA malfeasance -- from the mechanisms we have available. On Thu 2022-01-20 23:51:22 -0500, Ryan Sleevi wrote: > There are good reasons that clients have not, and potentially will never, > support Must-Staple, whether it be for the technical reasons that many > servers are unfit to support it, or for policy reasons, such as wanting to > be careful about the security policies of their products, and how much of > that is outsourced to CAs. If certificate validation is the process of confirming what a CA says, then a CA that has said "this certificate should not be considered valid unless you also have a reasonable proof of freshness" is pretty unequivocal. maybe the MUST should be "MUST NOT accept unless a reasonable proof of freshness is available, for example a stapled OCSP response"? Of course a client is free to ignore what the CA says and accept the certificate anyway. But once you're ignoring what the CA actually wrote and signed in the certificate, you're on your own. https://datatracker.ietf.org/doc/html/rfc7633#section-4.2.3.1 only says "SHOULD" here, but then it's a bit fuzzy about the exceptional cases for the "SHOULD". the first paragraph of exception is "if it has some other proof of freshness", and the second paragraph is "if you'd fallback to cleartext anyway" -- does the final caveat of "MUST NOT distinguish that connection as secure" refer to both cases, or just the latter? > The choice about whether to require stapling or not _is_ a policy > decision relevant not only to server operators, but also relying > parties, and can be easily abused by CAs if given that lever. What kind of abuse are you anticipating here? can you spell it out in more detail? > Given the concerning practices already seen with respect to > revocation, which are detrimental to the security goals of both server > operators and end users, a full-throated MUST seems a bit incompatible > with the notion of allowing policy flexibility. Do you think that a MUST validate the intended DNS name against the sAN in the certificate is also incompatible with the noton of allowing policy flexibility? > For example, in a world where a client delivers revocation information > out of band, as nearly every major web browser does today (as one > example), "must staple" is of questionable benefit. do major web browsers deliver revocation out of band for end entity certificates? My impression was that most CRLSets would only be updated and pushed for known-compromised CA certs (intermediate or root) and very widely-visited end entities. I don't think a small end entity will benefit from CRLSet distributions, but i'd love to be wrong. > Without wanting to detract too much from the core question of the thread, > how does this address the routing gap? The adversary at the routing layer > just redirects the host being validated to control the key that way, and > simply interrupts the nameserver during the CAA check. In the threat model > you're concerned about (Web PKI), DNSSEC is soft-fail, particularly for CAA > checks. If DNSSEC is soft-fail for the CA verifying CAA checks, then i agree this is insufficient. The letsencrypt implementation is apparently at least logging the info about DNSSEC signatures. https://github.com/letsencrypt/boulder/issues/2700 Do you think that DNSSEC should be soft-fail for CAA checks, or should we urge the CAs to be more strict here? Perhaps that would be another recommendation. > The assumption here for this model to hold is that the CAA information is > infallibly guaranteed to be delivered to the CA (it is not), and that the > CA will properly adhere to it for all threats that are concerning (they do > not). I agree that CAs are not guaranteed to follow the policy guidelines. However, a server operator can choose a CA that it believes *will* follow this guidance, and use a CAA record to indicate that all other CAs would be misissuing if they grant a cert for the operator's name. Then they can use CT to identify the misissuing CA, and use, uh, political(?) channels to try to get that CA taken down for failing to meet the BR. That's where the CRLSet comes in, right? This is a teetering chain of ugly dependencies. I'm not very happy with it. But i don't see what the alternative is in the current landscape if we want folks to be better protected against misissued certificates. > Without those properties, this doesn't provide any value, and that > rather significantly undermines the argument for the MUST for > Must-Staple being made for clients/relying parties. I don't see why it undermines the MUST for RP's supporting Must-Staple. fwiw, this whole revocation system seems much closer to "so complex there are no obvious problems" than "so simple that there are obviously no problems" :( --dkg signature.asc Description: PGP signature ___
Re: [TLS] [Uta] OCSP in RFC7525bis
On Wed 2022-01-19 16:57:07 +0200, Yaron Sheffer wrote: > * Add a SHOULD-level requirement (for TLS 1.3 implementations, > possibly also TLS 1.2 implementations) to fail the handshake if the > OCSP response is missing or invalid. (As far as we can tell, RFC 8446 > is silent on this.) This sounds a lot like a "SHOULD BUT WE KNOW YOU WONT". Why would a client deliberately fail a connection when the problem might be a flaw with an unrelated network service or a client-specific routing failure? I think we can definitely explicitly recommend: A) clients MUST require valid stapled OCSP response when encountering a certificate with "must staple" extension. (this is just following the specs, but i don't think it's as widely supported as it should be; maybe we need some public naming/shaming?) I'm less sure about, but could be convinced of: B) server operators SHOULD use certificates with "must staple" extension. Figuring out how to properly incentivize (B) is the hard part. It looks a lot like the "you should adopt DNSSEC" argument. Most sysadmins find that unconvincing, because they hear it as "your network services need this additional point of failure". Plus, adopting this for your own certificates only helps in the event of secret key theft that the legit admin notices -- she can then respond by revoking the key and trusting the OCSP responder to not issue valid OCSP responses. As Victor rightly points out, a more likely threat model today is that the adversary spoofs your DNS or your routing, and uses that spoofing to get one of the ACME providers (e.g., let's encrypt) to issue new certificates entirely. So the right set of fixes to defend against all these kinds of attacks are: - enable DNSSEC for your zone - signal in your DNS (e.g. via CAA, RFC 8659) that you only want a specific set of CAs to issue certificates in your zone (CAA doesn't explicitly describe an option to require that the CA use must-staple, but it looks like any CA could declare a CAA parameter that would offer that guidance. for example: https://github.com/letsencrypt/boulder/issues/5903) - ensure that your account with those CAs requires must-staple (either with your CA's preferred CAA parameter, or some other way) - monitor CT logs for certificates that violate your CAA policy This should close all the gaps that i can see, making the whole chain as strong as your control over what gets signed by your zone's DNSSEC signing key (and your CA's adherence to CAA policy, of course). --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] publishing ESNIKeys under a .well-known URI...
On Fri 2019-11-22 05:13:13 +, Stephen Farrell wrote: > I'm not sure if this draft ought specify behaviour for > such clients, but I can try add text describing the various > cases I guess. (If that text were to stay in, then I'd > guess that it'll make this document too long to include > in the base ESNI/ECHO draft thus taking that option off > the table maybe.) The other option would be to make non-"zone factory" clients explicitly out of scope, and spend a couple sentences describing why. And then note how if you're going to play these games as a non-"zone factory" client you really need to think it through a lot more than this draft does. --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] publishing ESNIKeys under a .well-known URI...
On Wed 2019-07-03 16:01:21 +0100, Stephen Farrell wrote: > It doesn't take much to encourage me so I just > pushed out that idea in I-D form:-) [1] […] > [1] https://tools.ietf.org/html/draft-farrell-tls-wkesni-00 Thanks for this (and for the -01 update for the draft). I like this work, and i think we should pursue it in the WG. A couple notes/questions: - Clients might use this, not just "zone factories". For instance, consider a client with limited access to the DNS that makes an initial direct connection to the hidden host, leaking SNI. If, in that connection, it also fetches this record, it could use that to bootstrap future connections to the host, right? The draft currently contemplates this briefly for followup queries for some clients, but it doesn't go into it in more detail. - Why is it hosted on the cover server, instead of on the hidden server? is that just so that the zone factory doesn't leak $HIDDEN to the network? Surely on a zone factory update, the zone factory already knows the eSNI for $HIDDEN so it could make the request with eSNI to https://$HIDDEN/.well-known/esni/$HIDDEN.json rather than to https://$COVER/.well-known/esni/$HIDDEN.json At the same time, for $COVER to publish this information potentially puts $COVER at more risk, right? And, a $COVER could *claim* to be a cover for $HIDDEN without approval of the $HIDDEN site by publishing these records; if anyone believes that claim, it could cause traffic to be re-routed through the ersatz $COVER. If it's going to be hosted at $COVER and not $HIDDEN, we should be explicit about what defends against such an attack. There could be an "obvious" reason for the choice of hosting it at $COVER instead of at $HIDDEN, but it should be spelled out in the draft. - If this is treated as a separate/independent source of authority about ESNI data for a host from the DNS (e.g. in the client examples contemplated in my first point above, not just the "zone factory"), then the draft probably needs some text discussing what to do when discovering a discrepancy between what's in the DNS and what's found at .well-known. Regards, --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A flags extension
On Wed 2019-03-27 10:52:20 +0100, Nikos Mavrogiannopoulos wrote:
> Right. What about defining a set of extensions (e.g., 2 extensions) of
> flags as:
>
> struct {
>uint64 flags;
> } Flags;
If we're going to be doing this kind of bit-shaving, this is the way to
go, starting with a single CommonFlags extension -- and maybe even a
uint32 or uint16, with the bitfield registry under tight WG control. If
we exhaust that space, then we just define a CommonFlags2 extension.
If someone wants an experimental boolean extension to play with, they
can always use an empty extension. They can apply for a bit in
CommonFlags if they find that the compactness is warranted.
Keep it simple.
--dkg
signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Negotiated Finite Field Diffie-Hellman shared secret calculation
On Thu 2019-02-21 00:16:54 +, Peter Gutmann wrote: > (A side-note about the 3526 values, they've been independently verified > outside of their publication in the RFC, has anyone done this for the 7919 > ones? Not saying they're suspicious, but it'd be good to get independent > verification that the data values match what's described in the RFC). i'd welcome any additional double-checks. iirc, at the time of publication, Tero Kivinen checked them independently, but i'd welcome any additional checks people want to do. I also published primality proofs (via primo) of the groups here: https://dkg.fifthhorseman.net/ffdhe-primality-proofs/ > That's a weird thing about 7919, throughout the draft process lots of people > pointed out, again and again, that it wasn't going to work if published in > that form. So it got published anyway... i agree that it would have been functionally stronger to define ciphersuite values that identify the use of named FFDHE groups. This would allow clients to signal to servers that they will *only* accept DHE if the server uses the named groups, and would avoid getting DHE handshakes from non-compliant servers. However, the mechanism is still useful as-is for clients that want to signal their preference for a known group to a cooperating server. This is still useful in a world where some clients were failing to accept server-offered DHE shares > 1024-bits (sigh, Java). IIRC, the sense at the time was also that codepoints were scarce resources, and replicating all the _DHE_RSA_ ciphersuites alone would consume another 25 codepoints (replicating all of the _DHE_ ciphersuites would consume 70 additional ones), and then it would also require haggling over how the handshake messages would differ from the standard in those variants, which might then increase implementation complexity. Too bad! At any rate, it turned out to be useful preparation for TLS 1.3, though i presume today the named DHE groups will really only come in handy in case ECDHE turns out to have some kind of serious cryptanalytic setback. --dkg, the guilty party signature.asc Description: PGP signature ___ 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 Sun 2018-12-09 18:35:20 +0100, Kurt Roeckx wrote: > 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 right, so what is to be done about that, when some of these CAs are clearly violating the BRs? Transparency is only as useful as the actions we can take once violations are uncovered. Unactionable transparency just sounds like despair to me. So what's the action? --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] OCSP Stapling confusion
On Mon 2018-12-10 02:24:29 +, Salz, Rich wrote: >> * the status_request TLS extension doesn't provide a mechanism for >stapling OCSP for intermediate certs. > > Nobody does this. There's a handful of reasons, but the end result is: > nobody does this. I'd be interested in hearing the reasons enumerated. It seems to me like being able to promptly revoke an intermediate certificate is a useful bit of mechanism. is it just because we hope the major browsers are clever and responsive enough that they'll push out a CRLset (or equivalent) when they hear of an intermediate that is found to be violating the BRs? >>So i think this is a big swirling mishmash of not-quite-compatible and > not-quite-complete specs, especially as we think about TLS clients and > servers that want to be interoperable with both TLS 1.2 and TLS 1.3. > > Yes, there are many things that could be cleared out with a BCP doc. > I would be interested in helping with that. I agree that a BCP would be pretty helpful in clarifiying the state of play, since it's currently scattered across a few docs over several years. But I think i'm proposing something that is not quite just a "BCP", since it might involve changing the semantics and extensibility of status_request (limiting it to OCSP responses (from the authorities found in the AIA?)) so that "TLS Feature" can actually provide meaningful guarantees of OCSP stapling for X.509v3 certificates. Because right now, with all the extra (currently unused) flexibility in status_request, it's hard to see how a client or server can meaningfully rely on "TLS Feature" as a "must-staple" extension. --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] OCSP Stapling confusion
I was trying to sort out concrete, specific advice for OCSP stapling
that provides security benefits for the server (and not just performance
and privacy benefits). Either i'm easily confused, or it's a mess. I
hope it's the former, please unconfuse me!
Given the IAB's statement from nearly two years ago about the value in
OCSP stapling [0], it's a little distressing to me how difficult it
seems to be to get it right in today's landscape.
[0]
https://mailarchive.ietf.org/arch/msg/ietf-announce/j0JIIGhD-xvbaWxtGm2-pFK0JQ8
In the bullet points below, i'll refer to the status requester as the
"client", and the party returning the status as the "server". I'm aware
that the roles could be reversed if the server is requesting client
certs, but i'm going to punt on that wrinkle for now, since the
straightforward/common case is confusing enough.
* the status_request TLS extension doesn't provide a mechanism for
stapling OCSP for intermediate certs.
* the status_request_v2 extension does provide a mechanism for stapling
intermediate OCSP, but it is deprecated by TLS 1.3 and TLS servers
responding with a TLS 1.3 handshake MUST NOT send
status_request_v2 in the ServerHello.
* the location of the stapled response has changed between TLS 1.2 and
TLS 1.3 -- in 1.2 and below, the OCSP response data is carried in a
CertificateStatus message. In 1.3, it's in an Extension object
associated with a Certificate, which allows certificate stapling for
intermediate certs. this is a good thing! but a TLS client capable
of both 1.2 and 1.3 that wants to be rigorous about stapling in both
protocol versions has a much more complicated set of logic to worry
about.
* the certificate_status extension has its own internal extension
point:
enum { ocsp(1), (255) } CertificateStatusType;
This goes against the "have one joint, and keep it well-oiled" design
pattern we've learned over the years, because now you have the
extension itself (certificate_status) and its own config selector.
This results in another 8-bit registry to maintain: [1]
[1]
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#certificate-status
I think we should have omitted this additional joint, and just
defined the certificate_status extension to be ocsp_status, without
this field. If someone wants to introduce a new status type, they
can introduce a distinct TLS extension later.
* I see no requirement that the CertificateStatusType in the
CertificateStatus record actually matches the CertificateStatusType
in the status_request extension sent by the client.
* In TLS 1.2 and earlier, there is no obligation for a server which
replies with the certificate_status extension to actually publish a
CertificateStatus message.
* Furthermore, if a status_request arrives at a TLS 1.2 or earlier
server with a CertificateStatusType other than ocsp(1), or with
non-empty ResponderID or Extensions members, it's conceivable that
the server couldn't accurately create a corresponding OCSP response
(either because it does not know about, or cannot contact any of the
requested OCSP responders, or is for whatever reason unable to apply
the requested OCSP extension(s).
* the TLS Feature Request x.509v3 extension only indicates which
extensions are supported in a generic, per-extension way. So while a
CA might be able to assert "this server will always reply with a
status_request extension for this certificate", it doesn't appear to
guarantee that (in 1.2) the server will actually send a
CertificateStatus message at all, even if a status_request extension
is sent, let alone whether the contents of that CertificateStatus
message will be related to the client's status_request. And in 1.3
it doesn't guarantee that status_type will be ocsp(1) for the
status_request extension that is sent.
* Without the TLS Feature Request x.509v3 extension in the server's
cert, there's no way to ensure that a compromised server can't just
block the client from ever learning any OCSP details (e.g. by
controlling the client's network).
So i think this is a big swirling mishmash of not-quite-compatible and
not-quite-complete specs, especially as we think about TLS clients and
servers that want to be interoperable with both TLS 1.2 and TLS 1.3.
In trying to figure out reasonable, useful guidance, and to make the TLS
Feature Request X.509v3 extension somehow useful, i'm tempted to try to
write up a clarifying/simplifying specification that actually cleans up
some of the semantics of status_request by cleaning up and enforcing the
currently-expected semantics.
In particular, i would want to propose something like:
* regardless of TLS version, clients SHOULD NOT send status_request_v2,
and servers SHOULD NOT return it even if the client supplies it. If
you want stapling for your intermediate cer
Re: [TLS] draft-dkg-tls-reject-static-dh
On Fri 2018-12-07 07:14:17 +, Peter Gutmann wrote: > I appreciate that people feel strongly about this, and I support the idea of > non-ephemeral DHE detection in principal [0] (along with many, many other > measures to strengthen TLS), but this draft reads a lot like the IETF blowing > raspberries at ETSI. hm, it's true that i'm not happy with ETSI's decision-making process here, but my goal with the draft is to provide a measure of defense for TLS clients on the public Internet who might accidentally/unknowingly come into contact with some errant eTLS server implementation that has escaped the enterprise data center, and not realize it. If you want to suggest ways to reduce the raspberry-blowing-ness of it, i'm all ears. My initial (unpublished) copy of the draft didn't contain the "Problems with static DH" section at all, it was just a quick set of guidance on how to mitigate the risks introduced by this potential ecosystem change. I added the "Problems" section because i wanted to document the very real concerns; it's not a raspberry-blowing doc for the sake of rasberries. > but getting into an arms race you know you can't win seems like, well, > workgroup posturing. Another way that someone who wants to leak secrets could leak them would be to use a bad FFDHE group and small subgroup during key exchange (indeed, this can happen by accident in some cases), or by enabling and encouraging the use of export ciphersuites. But we discourage people from doing bad FFDHE at a protocol level in TLS 1.2 (where arbitrary groups are allowed) by encouraging peers to reject handshakes that are not in the right-sized subgroup. If you can detect that the peer is misbehaving, shouldn't you act on it? Otherwise, what's the point of detection? > [0] "In principal" because there's a fair bit of SCADA gear that does this > because it doesn't have the CPU power to generate new DHE values, as I > found out when I turned on non-DHE checking some years ago. Is this SCADA gear running TLS 1.3? is it clients and servers both, or just one or the other? When was this scan done? i'd love to see more documentation about this practice. --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-dkg-tls-reject-static-dh
On Wed 2018-12-05 18:59:07 +, Stephen Farrell wrote:
> it's feasible and not easily defeated.
TLS endpoints can share their data (key material, cleartext, etc) with
whoever they choose -- that's just how the universe is implemented.
They can even do it out of band, on a channel that the peer has no
knowledge of.
The question for TLS implementers is what to do about risks or leakage
that they *can* become aware of.
> It'd be good to describe in detail a way in which one might
> efficiently retain the client state required, e.g. via a bloom filter
> maybe? (Assuming an occasional false positive isn't too alarming;-)
Yes, that would be great. the way i was going to write it that guidance
was pretty dumb (i was thinking of just a hashtable combined with a
fixed-size ring buffer to be constant-space and roughly constant-time,
and hadn't even considered bloom filters), so i welcome suggested text.
Given that the size of the set of elements to include is effectively
infinite, standard Bloom filters seem likely to be trouble (way too fast
to converge onto false-positives).
Perhaps "stable bloom filters" would represent a better tradeoff:
http://webdocs.cs.ualberta.ca/~drafiei/papers/DupDet06Sigmod.pdf
But hm, even a 0.1% false positive rate sounds pretty alarming too. 1
in a thousand connections failing? yikes! I think we'd want to err on
the false-negative side for this particular use case.
> It might also be good to outline how a survey or CT-like mechanism
> (say logging some value as a witness for the DH public) could be used
> to detect this kind of badness even if common TLS clients didn't
> deploy.
oof, CT itself is *really* heavyweight, and given our overall failure to
get any sort of monitoring that would detect abuse by the CT logs
themselves working (gossip hasn't had the necessary traction), i'm not
sure i have the stamina to go down that route for ephemeral DH values.
If someone wants to try to think that through (how do you ensure it's
not spammed?) i'd be happy to see it as a separate draft, but i don't
think it belongs in this one, which is intended as guidance for TLS
endpoint implementations.
> I think in 3.2 you need to be a bit more precise about which DH values
> you mean, e.g. if doing ESNI then clients will see the same DH value
> from ESNIKeys a number of times. (So I suspect you couldn't implement
> this at a very low level in the crypto engine.)
Yes, that's absolutely right. Proposals for text welcome!
> "MUST avoid accidental" is an interesting phrase:-)
good catch, i'll drop "accidental" :)
> Section 4 could probably do with some text about how not to do this,
> e.g. keeping a list of {servername,[DH values]} would be bad if a
> client's disk were compromised.
right, this would align with the bloom filter (or whatever)
implementation guidance you mention above. I've been thinking about
this, and i'm not sure that we even need servername as part of the key.
is there any reason that a client should ephemeral DH reuse *across*
hosts? If anything, ephemeral DH reuse across hosts *proves* that a DH
secret has been shared (wittingly or unwittingly), which is one of the
things we're trying to avoid, right? Simpler implementations are
probably better, and it's certainly easier to not deal with the
servername.
--dkg
___
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 Thu 2018-12-06 21:08:00 +, Andrei Popov wrote: > In a specific quick test that I did, there was no significant perf > impact with key reuse time > 1 sec. And I could probably get it down > to sub-seconds on my HW. But HW specs differ between TLS servers; our > current "ephemeral" key lifetime is a generous 30 sec., mainly because > we saw no reason to push for a lower key lifetime. Is this on both client side and server side? That is, does SChannel as a client also use an "ephemeral" key lifetime of a generous 30 seconds? > "Truly malicious" is perhaps an overstatement for this easy workaround > explicitly permitted by the "Enterprise TLS" spec: > "In some essential circumstances, the visibility information field may be > omitted." The ETSI "Middlebox Security Protocol" explicitly aims to drop Annex A. They've said that they *want* visibility and that is an explicit goal. Surely the purpose of visibility is to ensure that both parties involved are running the significantly weaker eTLS, and not TLS. Opting for visibility while expecting clients to not do anything with the knowledge gained doesn't make much sense to me. --dkg signature.asc Description: PGP signature ___ 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 Thu 2018-12-06 02:10:06 +, Andrei Popov wrote:
> In our tests, we see significant drop in handshakes/sec on a busy TLS
> server with ephemeral DH share reuse time < 1 sec.
hm, thinking about this optimization approach, i would really like to
know what implementations are doing this. It occurs to me that client
implementations as well as server implementations could be doing this
"for efficiency reasons".
If both sides do it, and two connections are established within the
window before the "ephemeral" keys are disposed of, then you could end
up in a scenario where you actually have a "Handshake Secret" and
"Master Secret" that are reused across a connection, and this would be
entirely observable by a passive monitor.
That leaves the only defense against direct key reuse for encryption on
the wire the entropy in:
* ClientHello and ServerHello (for
{client,server}_handshake_traffic_secret)
* ClientHello and server Finished (for
{client,server}_application_traffic_secret_0 and
exporter_master_secret)
* ClientHello and client Finished (for
resumption_master_secret)
Seems like risky business... we're leaning heavily on HKDF-Expand-Label
to keep a passive observer from being able to identify how the actual
traffic keys across sessions are related to one another. Or am i
missing something? I'd love for someone to correct me here.
Maybe i'll add a section to the draft explicitly forbidding clients from
ever taking this "optimization" step as well.
--dkg
signature.asc
Description: PGP signature
___
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
Hi Andrei-- On Thu 2018-12-06 02:10:06 +, Andrei Popov wrote: > I like the intent of draft-dkg-tls-reject-static-dh-01, but this part will > cost servers some perf: > >"Given the concerns in Section 2 and the necessary client mitigations >in the subsections above, servers need to avoid giving the appearance >of using non-ephemeral DH. Servers MUST NOT reuse ephemeral DH >shares." > > In our tests, we see significant drop in handshakes/sec on a busy TLS > server with ephemeral DH share reuse time < 1 sec. interesting, i'd love to see more details on those tests if you can share them. What kind of load are we talking about? Which server implementation? The cost here is in the fixed-base operation, iiuc, which is the cheapest part of the handshake -- DH share reuse allows you to skip this one step per handshake (or rather, to amortize the one step across multiple handshakes). You mention a cutoff of 1 second. If the amortization is spread across, say, all handshakes within 2 seconds, is the performance impact still significant? If the draft's server guidance were to be amended to suggest avoiding DH reuse for more than 2 seconds, and the guidance for clients to track added a buffer of 2 seconds before rejection, would that satisfy your concerns about performance under load? > Also, won't the "enterprise TLS" server just create a bunch of static > DH shares and send different ones at different times, thereby avoiding > detection by most clients? I don't think that the intent of the ETSI spec is to encourage non-visible use. They've specifically stated visibility to clients as a primary goal, and acknoweldged that "Annex A" servers would be in violation of their own goals. So it's conceivable that truly malicious servers would do this, of course, but they might also just publish the master secret on twitter too, and the client wouldn't know how to detect that inband either. But for the misbehavior that we *can* detect in-band, a responsible client should be aware of it and avoid it, right? --dkg signature.asc Description: PGP signature ___ 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 2018-12-05 20:15:08 +0900, Bret Jordan wrote: >> On Dec 5, 2018, at 7:33 PM, Stephen Farrell >> wrote: >>> On 05/12/2018 10:22, Bret Jordan wrote: >>> I think we should be more open minded and look at the needs from a >>> 360 degree deployment perspective. >> >> I think we should avoid marketing speak. > > This is not marketing speak. This is understanding how these solutions > need to be deployed end to end in all of their scenarios from > consumer, to small business, to enterprise, to service provider, to > content provider, to telco, etc. Perhaps one of the reasons that this might across as marketing speak to some people is that your list of "all their scenarios" appears to be only business use cases (where the individual people involved are at most consumers of business products). You haven't mentioned journalists, disk jockeys, activists, flat earthers, dissidents, students, medical professionals, juggalos, community organizers, gun nuts, cryptozoologists, whistleblowers, LGBTQ folx, refugees, free software developers, elected officials, religious minorities, senior citizens, or any of the other non-business use cases that may depend on TLS for confidentiality, integrity, authenticity, or any of the other information security guarantees that are put at risk by proposals like this. One of the concerns the last time we danced this dance was that the proposal claimed to be interested in one use case only: "the enterprise data center", and yet offered no meaningful way to effectively limit its (ab)use outside the data center. This objection was raised clearly, and the proponents of the protocol change failed to address it. And now it appears that instead of addressing the concern, they forum-shopped until they found a place to publish the same approach without even acknowledging the concern that this could have an impact beyond the data center. A full 360 degree view might acknowledge that doing harm to the core priniciples of a security protocol that everyone relies on for the sake of one particular use case out of many might not be an appropriate step to take. (and that one use case might have other solutions, albeit perhaps more expensive or inconveient ones for people who have already made certain investments) I'm pretty sure we don't want TLS to be all things to all people, right? What are the core goals or guarantees of TLS that you would like to see preserved? --dkg signature.asc Description: PGP signature ___ 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 2018-12-05 17:08:44 +0900, Bret Jordan wrote: > Now this WG is finally starting to talk about a solution to a real > problem and need. We can either address the use case and need here in > the IETF, or we can let the solutions be done else where. I would > personally prefer we take this work item back and solve it here in the > IETF. Or, the IETF can say with relative clarity that this kind of information leakage is inappropriate for and incomaptible with the information security goals of TLS. > Finally, remember, you may not like the use case or need, but that > does not mean the use case is not valid and needed. Sure, but just because someone says it is, doesn't mean that the use case is valid or needed within the scope of TLS either. Throughout the (several years now) discussion of this sort of proposal, we've repeatedly heard about "legal obligations" which somehow evaporate when pressed for details. And we've heard about "operational considerations" which typically amount to cost-shifting concerns (they can come across as: "we've invested a bunch of money in this particular network architecture/application design, please change the infosec guarantees provided by TLS for everyone on the global network so that we don't have to do an expensive re-tooling or staff up on new skills while i'm responsible for this budget line item"). The WG is chartered to make TLS a fast, secure, confidential transport layer. Let's keep the charter goals in mind. --dkg signature.asc Description: PGP signature ___ 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 Sat 2018-12-01 10:02:44 -0800, Christian Huitema wrote:
> Which is indeed a huge problem. Security conscious implementations of
> TLS should detect the use of such "enhancements", and either abort the
> session or automatically treat it as insecure.
This certainly looks like a case of forum-shopping to do an end-run
around the underlying goals of TLS as a 2-party protocol that
prioritizes confidentiality, integrity, and authenticity between the two
peers.
Even worse, the supposed "VisibilityInformation" mechanism is stuffed
into subjectAltName in the server's certificate, which means that it
can't even depend on the "critical bit" that would have been available
to a standard X.509v3 certificate extension. This appears to encourage
deployment to unaware clients.
I've just submitted draft-dkg-tls-reject-static-dh-00, which suggests
that responsible TLS clients that observe a server certificate with a
subjectAltName otherName with the VisibilityInformation type-id (OID
0.4.0.3523.3.1 {itu-t(0) identified-organization(4) etsi(0) msp(3523)
etls(3) visibility(1)}) MUST reject the certificate. I'm open to
feedback on it.
https://datatracker.ietf.org/doc/draft-dkg-tls-reject-static-dh/
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?
--dkg
signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Enforcing Protocol Invariants
On Thu 2018-11-08 18:31:28 -0800, Ryan Carboni wrote: > Encrypting common knowledge is cargo cult fetishism for cryptography. The > files could be sent unencrypted, and protected using subresource integrity. > If you are sharing the same data to multiple second parties to serve to a > single third party, the value of encryption is less than zero. I agree that the widespread move to CDNs makes those CDNs a point of vulnerability and potential compromise. But from a harm reduction point of view, encrypting data that transits a CDN does protect that traffic from surveillance by non-CDN network-based adversaries. There is more research and development work to be done to make that protection even more robust: anti-traffic analysis work, for example. But simply reverting to cleartext would be a mistake. Ryan, your posts in this thread suggest an understandable frustration with cryptographic deployment on the public Internet, and perhaps an even more understandable frustration with cryptographic *deprecation* on the public Internet. However, the web suffers from the same two problems as much of the public Internet: the curse of the deployed base, and a small but non-negligible fraction of confused, interfering middleboxes. I love proposals that happily ignore these problems, because they tend to be elegant, and more often correct than janky old stuff! But, if we want our protocol designs to actually eventually replace old, worse protocol designs, we need to look at deployment/upgrade/deprecation paths, which involves a *lot* of ugliness -- the main job of the TLS WG, afaict. Otherwise, our beautiful new designs will get rolled out, and will simply co-exist alongside the old brokenness :/ --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps
Hi all-- I'm disappointed in how long this WG is taking to get draft-ietf-tls-dnssec-chain-extension out the door. I agree with both Tom and Viktor that the current draft seems to be misaligned between the goals and the stated scope. I wanted the draft to be done by now because i think it will be useful in "greenfield" scenarios -- ones where the use case itself can mandate the extension without negotiation, but i understand Viktor's point that without any sort of negotiated pinning mechanism, the draft is probably not useful for non-greenfield scenarios (without pinning the existence of the extension, it cannot reduce the attack surface represented by the CAs, and instead only represents an additional vector of attack). I can understand why people want to be able to make this useful for non-greenfield scenarios, but it appears that we're hung up on the pinning details. I actually don't think that extension pinning needs to be particularly hard, and i don't think it's as dangerous as HPKP's pinning, but i won't go too far into the weeds here. Just a quick summary of my understanding: * The existence of a pin only requires that the service operator maintain the ability to respond to this extension in the future -- it doesn't require specific keys, or even the use of DANE itself. It is not nearly as large a risk as HPKP's pins were. * Pinning fears are based on two scenarios: (a) footgun, where the service operator makes a mistake, or (b) a malicious pin is set by an adversary who has owned your domain. (a) is overwhelmingly more common, and is what we should focus on. In the (a) scenario, the admin has already deployed the extension, so there is no risk. The (b) scenario only matters if a service cannot deploy the extension as intended, which is more of a chicken/egg problem of deployment and implementation. I don't think that's a huge risk but if we really want to try to cover it, i think there are ways that we could minimize it as well. That said, it sounds like negotiating the details of how to do this pinning is the main blocker, and i'm sick of this proposal being blocked (because i want it for "greenfield" implementations last year). So one way forward would be to complete this extension without the pinning (explicitly acknowledging that it will not be useful for non-greenfield implementations on its own) and get it out the door. Then we can subsequently create a new extension that is only a "how-to-pin-dnssec-chain-extension". This is an approach that would expose at the protocol layer the ugly truth about how hard it is to get something through the IETF process, but if it helps to break the impasse, i'd be all for it. I'm willing to provide text for why this is only useful for greenfield implementations, if asked. Alternately, if people could agree on a simple and clear pinning scheme that we could get out the door all in one piece, i'd be happy with that too. I will be sad if we manage to not get anything at all completed for another year. --dkg, tired of waiting signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Interim meeting information
On Fri 2018-09-14 10:13:23 -0700, Joseph Salowey wrote: > It should be working now. sorry, i'm still getting the same error message i got before. any pointers? same URL as in the untrimmed text below, same failure response :/ if that doesn't work for anyone else, i propose an alternative: I've just made up the URL https://meet.jit.si/tls13-interim, which can also be accessed via: To join your meeting, dial one of these numbers and then enter this PIN: 358305# CountryDial-in Numbers Australia +61.8.7150.1136 Brazil +55.21.3500.0112 Canada +1.647.243.6108 France +33.1.84.88.6478 Germany +49.89.380.38719 Japan+81.3.4510.2372 Spain+34.932.205.409 Switzerland +41.61.588.0496 UK +44.121.468.3154 US +1.512.402.2718 --dkg > On Fri, Sep 14, 2018 at 10:05 AM, Daniel Kahn Gillmor > wrote: > >> On Wed 2018-09-12 07:58:43 -0700, Christopher Wood wrote: >> > https://ietf.webex.com/ietf/onstage/g.php?MTID=e02cf108b5a24e348e10132497d5def9 >> >> when i visit this, i get a page that says:: >> >> This link to the event is no longer valid. >> >> This may be because the event has been cancelled, the event has >> ended, or you have been removed from the invitation list. For more >> information, contact the host. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Interim meeting information
On Wed 2018-09-12 07:58:43 -0700, Christopher Wood wrote: > https://ietf.webex.com/ietf/onstage/g.php?MTID=e02cf108b5a24e348e10132497d5def9 when i visit this, i get a page that says:: This link to the event is no longer valid. This may be because the event has been cancelled, the event has ended, or you have been removed from the invitation list. For more information, contact the host. I think the interim should havejust started now. any pointers for how to connect? --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-tls13-26 is vulnerable to externally set PSK identity enumeration
On Sun 2018-03-18 12:08:13 -0400, Viktor Dukhovni wrote: > The devices that might use external PSKs will likely be unavoidably > fingerprinted by source IP address and the target mothership. I'm not convinced that this is the case -- it's not at all clear that IoT devices will be attached to a stable network (so the source IP may change), and for large deployments, the devices might all share the same "mothership". But the device might still present significant privacy concerns (for example, if it's a device that travels with a person, its presence on the network could be used to track that person). > So I agree with the above approach. It is better to keep external PSKs > simple, with understood limitations, that to attempt (and fail) to turn > privacy up to eleven. fwiw, i agree that a big fat warning about the privacy implications of reused (if you don't reuse, there is no problem) external PSKs is about all we can do at this stage of TLS 1.3. --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Breaking into TLS to protect customers
On Thu 2018-03-15 20:10:46 +0200, Yoav Nir wrote: >> On 15 Mar 2018, at 10:53, Ion Larranaga Azcue wrote: >> >> I fail to see how the current draft can be used to provide visibility >> to an IPS system in order to detect bots that are inside the bank… >> >> On the one hand, the bot would never opt-in for visibility if it’s >> trying to exfiltrate data… > > The presumption is that any legitimate application would opt-in, so > the IPS blocks any TLS connection that does not opt in. Thanks for clarifying the bigger picture here, Yoav. So if this technology were deployed on a network where not all parties are mutually trusting, it would offer network users a choice between surveillance by the network on the one hand (opt-in) and censorship on the other (opt-out and be blocked). Is that right? Designing mechanism for the Internet that allows/facilitates/encourages the network operator to force this choice on the user seems problematic. Why do we want this for a protocol like TLS that is intended to be used across potentially adversarial networks? datacenter operators who want access to the cleartext passing through machines they already control already have mechanisms at their disposal to do this (whether they can do so at scale safely without exposing their customers' data to further risks is maybe an open question, regardless of mechanism). Mechanisms that increase "visibility" of the cleartext run counter to the goals of TLS as an end-to-end two-party secure communications protocol. Regards, --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism
On Thu 2018-03-01 21:52:51 +, Paterson, Kenny wrote: > I think there's a possible timing attack on a naïve implementation of > de-padding. Thanks for observing this, Kenny! I think this came up when we were designing the padding originally, and iirc, the general consensus was: (a) this scheme allows people to not pad at all, which saves bytes in the most heavily traffic-constrained case, and (b) there may well be timing attacks based on the handling of the non-padded data too, and those are likely to be stronger timing effects than the effects in the padding layer. I think with (b) we might have gotten a bit overly nihilistic -- for one thing, depadding probably happens in the TLS layer of the implementation itself, so any response generated by the TLS layer will have tighter timing bounds than anything that does data handling. And, implementers that use any given TLS stack can control their own timing code, but can't necessarily control the code of the TLS implementation that they're sitting atop. TLS implementers probably don't want to leak info that the user has deliberately taken steps to avoid leaking! Our implementer guidance should also already say that the best place to pad is at the application layer, where the implementer can more accurately design padding that meets the expected usage profile -- padding at the TLS layer is available for implementers that don't have this option, but probably isn't the optimal solution. > This padding scheme is quite important for TLS 1.3 because the current > AEAD schemes do leak the length of record plaintexts. thanks for acknowledging the value of the padding. i agree! :) The timing-based size leak you're talking about still looks harder to attack reliably than the direct size leakage we have without the padding. > 1. Do constant-time depadding - by examining every byte in the > plaintext structure even after the first non-00 byte is encountered. do you have concrete implementation suggestions? I'm not sure how to convince a clever compiler to actually run this entire loop if you count from the back -- i can easily see the tail of the walk being optimized away since it has no bearing on the rest of the program control or data flow. You could of course check from the front of the plaintext, keeping every non-zero value: char ptype = 0; for (i = 0; i < plaintext_len; i++) if plaintext[i] ptype = plaintext[i]; but iiuc, this leaks the number of zeros in the plaintext overall, assuming that the store instruction has noticeable time. can you tell i'm not good at devising constant-time code? :P If there's a concrete suggestion that we think will work for common implementations, i would have no problem including it as implementer guidance. > 2. Add an explicit padding length field at the end of the plaintext > structure, and removing padding without checking its contents. (This > should be safe because of the AEAD integrity guarantees.) > > Option 2 is probably a bit invasive at this late stage in the > specification process. Maybe a sentence or two on option 1 could be > added to the spec. It's not only too late to take this approach, i think we explicitly rejected this option because of the cost it imposes on unpadded packets, as mentioned above. --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-huitema-tls-sni-encryption-02.txt
On Wed 2017-06-21 21:25:21 -0700, Christian Huitema wrote:
> We has many discussions of SNI encryption on this list recently, and
> that was enough motivation to write a draft about it. I am pretty sure
> that this will be met with wide approval and no discussion at all :-).
This is my (hopefully not too tardy) review of
draft-huitema-tls-sni-encryption. fwiw, i still believe that the WG
should adopt this draft. Thanks for writing it, Christian and ekr!
* i agree with concerns raised about RFC 2119-style language -- they
don't really fit in the requirements and overall description. That
said, the natural english variants of those words are still relevant,
and shouldn't be ignored. The WG should try to prioritize the
different technical risks and opportunities.
Below are some comments/questions/nitpicks:
* The document uses the terms "Fronting server" and "Gateway", i think
interchangeably. It would be clearer if it stuck to a single term.
* §2.1 (Mitigate Replay Attacks) says "SNI encryption designs MUST
mitigate this attack", but "mitigate" sounds unclear and weak. do
you mean "must successfully prevent this attack" ? It seems like
this is all-or-nothing to me, not something that can be partially
alleviated.
* §2.4 (Do not stick out) While i understand the motivation of this
section, I think it's interesting that it rules out an entire
(simple) class of solution, namely the ssh-style approach: encrypt
first (without authenticating the server), then authenticate within
the encrypted tunnel. While this approach has several drawbacks (an
extra round-trip; leakage of SNI to an active adversary willing to
break connections to learn the desired SNI; difficulties for
non-crypto loadbalancers), it is really simple and straightforward to
implement and deploy (no third-party coordination, etc). (this
proposed approach also violates §2.7, "Fronting Server Spoofing")
If this approach were widely implemented, it wouldn't "stick out" any
more than SNI-free TLS handshakes did 10 years ago. Is it worth
documenting some solution of this class, just to provide a standard
way to do it, so that everyone doing it would at least be mixed into
a single (hopefully large) anonymity set?
* §2.5 (Forward Secrecy) -- "If the corresponding public key was
compromised" should probably be "…corresponding private key…".
"Forward secrecy" is also something of an ill-defined term, since the
window of the forward secrecy depends on key deletion schedules.
What if the private key for SNI encryption was rotated out (and
deleted) daily? would that be "forward secret" enough? how about
weekly? Perhaps this section should state that "designs should
clearly state their temporal window of vulnerable communications
should any non-ephemeral key be compromised"
* §3.2 (Delegation Token) -- i think the delegation token idea might
end up useful not only for §3 ("HTTP Co-Tenancy Fronting"). for
example, it might be usful for announcing either SNI encapsulations
(e.g., §4.2.3) or combined tickets (e.g., §5.3). so its location in the
document
is a bit odd.
* §4.1 (Tunneling TLS in TLS) says "an attacker should not be able to
distinguish these cases" but does not mention timing analysis. if
the Hidden server is not physically adjacent to (or co-tenanted with)
the Gateway, then the response ServerHello will have a different
latency than would a ServerHello that comes from the Gateway itself.
I don't think this is a deal-breaker, but we should probably
acknowledge it.
* §4.2 (Tunneling design issues) this section introduces the idea of a
"RealSNI scheme" without defining it. I think i know what it's
referring to, but perhaps it could be spelled out earlier for
contrast if this document is really exploring the full design space?
I think "conversely, these modes…" is referring to "RealSNI"-style
modes, but it could be mis-read as referring to the tunnelled
ClientHello described in §4.
* §4.2.1 (Gateway Logic) "EncryptedExtensions would be the most
natural, but they were removed from the ClientHello during the TLS
standardization." For those of us with either bad memory or bad
search skills, it would be nice to have a one-sentence summary of
*why* encryptedextensions were shot down, rather than just a "we
can't have this natural thing because reasons" argument by authority.
* §4.2.2 (Early data) "would requires" → "would require"
"delimitate" → "delimit", and "end of these" → "end of the"
Another difference between the posited schemes seems to be that the
double encryption scheme doesn't require the ClientHello to be in its
own separated EarlyData TLS record, while the blind relay case
expects the ClientHello to be isolated to a single record. Is that
correct? if so, it might be worth stating explicitly.
* §5 (SNI encryption with combined tick
Re: [TLS] TLS-in-TLS tunneling use cases (was: SNI Encryption)
On Wed 2017-08-09 22:54:46 -0700, Tony Arcieri wrote: > - The gateway authenticates clients (using e.g. a TLS client certificate) > and authorizes the outbound hostnames against an ACL. This way we can > control which clients are allowed to reach which external endpoints. While i think i understand where you're coming from, Tony, i can't help but note that this use case is difficult to distinguish from a regime that: (a) wants to forbid anonymous speech, and (b) wants to censor "unapproved" information sources, and (c) wants the capacity to undermine freedom of association. That makes me wary, and i hope that SNI Encryption is *not* conflated with these particular use cases. In particular, the requirement of user identification/authentication in combination with a heavily constrained network seems problematic. I don't think that we should design SNI encryption with an intent to facilitate this scenario. --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-tls13-21: TLS 1.3 record padding removal leaks padding size
On Fri 2017-08-11 18:43:15 +0200, Nikos Mavrogiannopoulos wrote: > I don't argue with this but this is not the approach TLS 1.3 took. It > provides a generic padding mechanism to be used across application > protocols. The design approach that TLS 1.3 took was to provide a mechanism for padding at the TLS layer, not to prescribe padding at the application layer. You actually probably need both to defend against traffic analysis in the big picture. Thoughtful, well-designed application-layer padding is likely to be better than generic TLS-layer padding. But not all applications can actually accomodate padding (and it's not clear that folks have done the thoughtful work even on those applications which *can* accomodate padding). TLS offers a generic mechanism to support the cases where the application can't do padding, or where the implementer has no control over (or insight into) the application itself. It'll probably leak in the way you describe, but it'll probably also be better than cleartext. Furthermore, there are TLS messages that are not application data at all -- so those parts *have* to be padded at the TLS layer, as the application cannot directly affect their size. A robust and safe padding approach needs to take into account all layers of the stack at once and coordinate between them. Without the padding mechanism in TLS, it wouldn't be possible to coordinate across the whole stack. --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WG adoption call: SNI Encryption
On Fri 2017-08-04 08:50:33 -0400, Sean Turner wrote: > At our IETF 99 session, there was support in the room to adopt > draft-huitema-tls-sni-encryption [0]. We need to confirm this support > on the list so please let the list know whether you support adoption > of the draft and are willing to review/comment on the draft before > 20170818. If you object to its adoption, please let us know why. I support wg adoption of this draft and am willing to review before 20170818. --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-green-tls-static-dh-in-tls13-01
On Sun 2017-07-16 12:44:04 +0300, Wartan Hachaturow wrote: > On Sat, Jul 15, 2017 at 01:23:35PM +0200, Daniel Kahn Gillmor wrote: > >> > Not to mention the security & troubleshooting applications which >> > require insight into the cryptostream on the wire. >> >> I asked for examples of regulations that specifically require plaintext >> from the network. > > Some countries has got that kind of requirements in the lawful > interception context, in the sense that monitoring is explicitly > required to be fully passive. Could you point me (and the list) to those requirements, please? More specificity than "some countries" would be a useful contribution to this discussion. > However, this mostly means "network equipment that supports some kind > of encryption on the link should be able to pass the traffic in > plaintext for monitoring purposes". Is this quote taken from a specific regulatory context? or do the quotation marks indicate paraphrasing or something else? Regards, --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-green-tls-static-dh-in-tls13-01
On Sat 2017-07-15 07:38:57 +, Dobbins, Roland wrote: >> On Jul 15, 2017, at 13:14, Daniel Kahn Gillmor >> wrote: >> >> * This proposed TLS variant is *never* acceptable for use on the public >> Internet. At most it's acceptable only between two endpoints within >> a datacenter under a single zone of administrative control. > > I would strongly attempt to dissuade anyone from using it across the > public Internet. I agree that it is best-suited for use on networks > within a single span of administrative control, & that's the use for > which it is intended. How strongly would you attempt to dissuade its use across the public Internet? Strongly enough to support a proposal that would require this to be opt-in from both sides, with an explicit and verifiable exfiltration authority, so that no standard implementation of the proposed mechanism could be accidentally turned on unilaterally without detection by the unwitting peer? Because the current proposal isn't nearly that strong at dissuading its use on the public Internet. --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-green-tls-static-dh-in-tls13-01
On Sat 2017-07-15 07:42:58 +, Dobbins, Roland wrote: >> On Jul 15, 2017, at 13:26, Daniel Kahn Gillmor >> wrote: >> >> Could you point to an example of any regulation that requires plaintext >> from network capture specifically? > > It often isn't feasible to obtain the plaintext any other way in a > given circumstance. > > Not to mention the security & troubleshooting applications which > require insight into the cryptostream on the wire. I asked for examples of regulations that specifically require plaintext from the network. This e-mail contains no such example, just an assertion that it's technically easier/simpler to do network capture for some deployments. i believe this assertion, btw, so you don't need to argue it further. Whether it justifies a loss of security is a separate question. If anyone has a specific example of a regulation that mandates network capture, i'd like to know about it. If there are no such examples, and we plan to continue to discuss this draft, i'd appreciate it if folks could take the "regulators require it" argument off of the table, and we can focus on the actual technical merits and risks of the proposal directly. Regards, --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-green-tls-static-dh-in-tls13-01
On Sat 2017-07-15 11:55:44 +0300, Ilari Liusvaara wrote: > Oh, and like any backdoor, this backdoor too has variety of security > problems. And your adversaries would absolutely love to be able to > exploit _you_ using these problems, as that would make their lives much > easier. I'd like to hear from the people who are doing full-take network capture within their datacenters about how they protect the security of the internal decryption systems. It certainly sounds like a tempting target for any adversary interested in datacenter operations. --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-green-tls-static-dh-in-tls13-01
On Fri 2017-07-07 16:04:20 -0400, Russ Housley wrote: > In some industries, there are regulatory requirements that cannot be > met without access to the plaintext. This is surely true, but it's not clear to me that any regulator requires access to the plaintext *from direct network capture*. Could you point to an example of any regulation that requires plaintext from network capture specifically? There are many non-network-based ways that plaintext can be produced as required by the regulated endpoints, without introducing a standardized mechanism that increases the attack surface of widespread implementations on the public Internet. Why should we privilege network capture (e.g. retrospectively decryptable pcap dumps) as a means of meeting regulatory requirements when: (a) other means of meeting regulatory requirements exist, and (b) we know that network capture is widely used adversarially by the kinds of attackers that TLS is explicitly intended to defend against? --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-green-tls-static-dh-in-tls13-01
On Sat 2017-07-15 05:58:31 +, Salz, Rich wrote: > Unless I missed the reply, I did not see any answer to my question as > to why it must be opt-in. Do we think evildoers will tell the truth > about what they are doing? Because presumably the people who do *not* want to do evil want to avoid specifying a mechanism that will be widely implemented that could leak into use outside of the intended scenario. right? As far as i can tell, we're all in agreement here that: * This proposed TLS variant is *never* acceptable for use on the public Internet. At most it's acceptable only between two endpoints within a datacenter under a single zone of administrative control. * Forward secrecy is in general a valuable property for encrypted communications in transit. If there's anyone on the list who disagrees with the above two statements, please speak up! --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS@IETF99 - Additional Session Added and Agenda Bash!
On Fri 2017-07-14 10:51:14 -0400, Sean Turner wrote: > The Secretariat has allocated us the Monday @ 13:30-15:30 slot. hm, that's disappointing for those of us who had other things we'd planned on going to already in that slot. :/ But it's not on the agenda yet, so maybe it has been changed already? https://datatracker.ietf.org/meeting/99/agenda.html > Because the main point of the TLS WG are the TLS and DTLS drafts and > the schedule was already announced, we want to leave those > presentations on Wednesday. What follows is a revised agenda; note > that we’ve alloced 40 minutes for further about > draft-green-tls-static-dh-in-tls13. Please let us know your thoughts. As Stephen points out, it looks like we've allocated 80 minutes to the topic of how to remove the forward secrecy guarantees that we've struggled for over a year to introduce. That's more than we've allocated for the "main point of the TLS WG", which are only 65 minutes combined. --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] "Encrypted" SNI
On Thu 2017-05-11 00:03:15 +0200, Roland Zink wrote: > Not necessarily as you may for example use the path part of a URL to > distinguish between services. if we're talking about HTTPS, this approach raises a series of potential security issues thanks to the same-origin policy and other host- or domain-specific features of the web security model. It doesn't solve the situation where you'd like the services to be independent. --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] "Encrypted" SNI
On Wed 2017-05-10 12:12:34 -0700, Christian Huitema wrote: > It certainly was. But then the clear text SNI is a gaping privacy hole > in TLS, the kind of issue that should keep us awake at night until it is > resolved. We need to make sure that we make progress, rather than rehash > the old arguments. Maybe we should invest some time and document the > various proposals in a draft. I am willing to work on that. Any other > volunteers? I agree with Christian's assessment of the problem, and i'd be interested in collaborating on such a draft. The DNS folks are making strides to protect name information (the other main place where this kind of data is leaking). TLS needs to keep up. --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Security review of TLS1.3 0-RTT
On Tue 2017-05-02 14:57:54 -0500, Nico Williams wrote: > Well, I did say that to me there's not much difference to _me_ between > "connections reusing the same ticket can be correlated to each other" > and "connections reusing the same ticket can be correlated to each other > and the connection whence the ticket". Others might disagree, I disagree, Nico! :) The difference here is between saying: * clients that want the latency benefit of session resumption can be careful to avoid ticket reuse and their connections will be unlinkable to a network observer who records session IDs. versus: * clients that want the latency benefit of session resumption must accept that a network observer can trivially know that each connection is linkable to the previous one. put another way: the difference between 0 required backlinks and 1 required backlink on each individual session resumption is the difference (for a cautious yet session-resuming client) between 0 connections linked by a network observer and all connections linked by a network observer. TLS session linkability is relevant: * When a client is behind a NAT and wants their connections to be mixed with (indistinguishable from) other clients behind the same NAT, to the perspective of a network observer outside the NAT. * When a client moves network locations and doesn't want their network position to be trackable by a network observer. * When a client uses a VPN as an encrypted Internet proxy (or uses Tor or some other similar IP-anonymizing service), and does not want a network observer outside the VPN from being able to distinguish their traffic from the traffic of other users of the anonymity network. --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Confirming consensus: TLS1.3->TLS*
On Fri 2016-12-02 03:33:21 -0500, Peter Gutmann wrote: > If no-one from Microsoft has any objections, can we just rename it back to > what it's always been for everyone but us, SSL? fwiw, the industry (and stackexchange) uses "SSL" to mean all sorts of things, not only TLS. Yesterday i got an e-mail from a reputable CA reseller that said "Your SSL is expiring in two days! Buy a new SSL now!" Surely no one is proposing that we also re-name the X.509 certificate format to "SSL" just because vendors whose business models revolve around these products are confused about terminology. What else should we rename to "SSL" on that basis? Maybe a load-balancer is also "SSL"! Here's a useful and effective meme for convincing bosses that it's ok to turn off SSLv3: all known versions of SSL are broken and should never be used. Please do not break this meme by trying to rename TLS to SSL. I don't care about the bikeshed over the number: i'd be fine with any of TLS 1.3 or TLS 4 or TLS 2017. But can we please not create *even more* confusion by bikeshedding over the name itself? --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
On Wed 2016-11-09 03:31:22 -0600, Martin Rex wrote: > The problem here is that this breaks (network) flow control, existing > (network socket) event management, and direction-independent connection > closure, and does so completely without value. Martin, you keep saying things like "without value", while other people on this thread (Rich, Ilari, Yoav) have given you examples of the value it provides. You don't seem to be trying to understand those positions. Your description of the problems it causes you are difficult to follow, and it doesn't sound like they have been experienced by other implementors. But other people are actively trying to make sure they understand your concerns (like ekr's post downthread here). Could you offer the rest of the list the same courtesy? Your earlier argument that the hidden data is deducable by traffic analysis anyway isn't a satisfying argument, for two reasons: (a) if it were reliably true, then your implementations could simply adopt the traffic analysis approach instead of inspecting the cleartext content types. If it causes too much additional expense, then it should increase the expense for adversaries who are monitoring traffic for these same signals as well, which is a security+privacy win. (b) We're including mechanisms (like padding) to make traffic analysis harder. More research is needed to know how to best provide this sort of indistinguishability. But if we decide instead that it's ok to directly publish any data that could possibly be inferred by traffic analysis, we will never improve the security of TLS for its users against traffic analysis, which will only grow more sophisticated over time. Why should we accept this limitation on TLS? This WG isn't chartered to defend the engineering optimizations made by any particular middlebox vendor. It's chartered to improve the privacy and security guarantees offered to users of TLS. Regards, --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)
On Tue 2016-10-11 13:26:02 -0400, Nick Sullivan wrote: > The major thing that this proposal achieves is that it makes post-handshake > auth an optional part of the implementation. Instead of this, I would also > be in favor of a simpler change that modifies the text to say that > post-handshake CertificateRequest messages are fatal by default and only > permitted if the application permits their use in a given context (say if > the application is HTTP 1.1, only directly after requests). > > Embedded implementations may choose to simply fail on unexpected > CertificateRequests, and that way not have to implement any code around > post-handshake finished messages or updating the transcript when one > arrives. > > This default wording should also apply to other types of post-handshake > messages, though NST and KU could be exceptions that should always be > supported and non-fatal. I don't see the advantage of putting this on the wire during the intial handshake. In the HTTP case, either (a) the requested resource wants a new authentication or (b) it does not. If it does not want new authentication (b), no CertificateRequest message will be forthcoming. If it does want new authentication, then either (a.1) it requires it (meaning the HTTP request will fail if the client can't offer a good cert), or (a.2) it just hopes to send a different response based on some new authentication. in (a.1), the request will simply fail when the client can't send a client cert. So the the client needs to know how to at least reject it gracefully. This is the case even when the client fully implements client auth anyway, since it might not have a client cert available. I don't think it's too much to ask that implementations be able to reject a post-handshake CertificateRequest gracefully, even if they have no intention of ever implementing a proper Client Certificate response. Changes to the wire format here only seems to give a small advantage to the server in one corner case for HTTP (a.2, when the client has no implementation of post-handshake client certs): the server can confidently send the certRequest, knowing that the client will know how to deal with it. But now clients will also need to decide whether they should indicate "i do post-handshake client auth" even if they have no likely client certs available at the time of session establishment, and to keep track of how they signaled over the lifetime of the session (how does this interact with session resumption?). I don't think that's a complexity win overall. If we make it clear that TLS 1.3 clients MUST at least know how to gracefully reject a post-handshake Certificate Request, i think that leaves the ecosystem as a whole with less complexity, and reduces the fiddliness of the wire format. --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Terminology clarification around SSL & TLS
On Wed 2016-08-31 03:35:38 -0400, Julien ÉLIE wrote: > Following a recent discussion about how to name the successor of TLS > 1.2, I wish to share an idea about a possible terminology clarification. > I believe it could help to conciliate people understanding of SSL & TLS. > > We would have 3 notions: > 1/ the technology, > 2/ the protocols, > 3/ the protocol versions. > > The technology is SSL, and is sometimes also refered to as SSL/TLS. > (Note that bare TLS is not a technology.) please no. the technology is TLS. The time for us to have made the other decision was 17 years ago before TLS 1.0 was formalized. i would like to continue to be able to say unambiguously that all known versions of SSL are badly broken and should be avoided. Let's not muddy those waters further. --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 -> TLS 2.0?
On Tue 2016-08-30 16:14:06 -0400, Hubert Kario wrote:
> On Tuesday, 30 August 2016 14:19:33 CEST Dave Garrett wrote:
>> * Keep the version ID as { 3, 4 } (already weird counting; changing risks
>> more intolerance)
>
> IMNSHO this alone is enough of a reason not to do this
>
> it's enough explaining to people that SSLv3.3 is really TLSv1.2, now we'll
> have SSLv3.4 == TLSv1.3 == TLSv2.0
>
> it's silly at this point
Who are you talking to who's fine with looking at the bytes on the wire
but isn't fine with understanding that a 16-bit field might not map
directly to our imagination of decimal?
If that mapping really matters, We could combine this with Erik Nygren's
version inflation suggestion and just jump straight to TLS 34 :P
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
doesn't have a "TLS version" registry. Would it be simpler to have IANA
create that and just populate it with:
Value | Description | Reference
--+-+--
0x30 |SSLv3| RFC 6101, RFC 7568
0x31 | TLSv1.0 | RFC 2246
0x32 | TLSv1.1 | RFC 4346
0x33 | TLSv1.2 | RFC 5246
0x34 |TLSv4| RFC
Then you could tell people to just look it up in the table.
--dkg, tongue only marginally in cheek
signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call for keys used in handshake and data messages
On Thu 2016-06-16 11:26:14 -0400, Hubert Kario wrote: > wasn't that rejected because it breaks boxes that do passive monitoring > of connections? (and so expect TLS packets on specific ports, killing > connection if they don't look like TLS packets) We're talking about the possibility of changing the TLS record framing anyway, which would kill the simplest of those boxes. One theory is if you're going to make such a break, you might as well pull the band aid off in one fell swoop. --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call for keys used in handshake and data messages
On Wed 2016-06-15 12:23:38 -0400, Ilari Liusvaara wrote: > On Wed, Jun 15, 2016 at 09:44:18AM -0400, Daniel Kahn Gillmor wrote: >> On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote: >> >> To be clear, we're being asked to trade these things off against each >> other here, but there are other options which were ruled out in the >> prior framing of the question which don't rule either of them out. >> >> In particular, if we're willing to pay the cost of a slightly more >> complex key schedule (and an increased TLS record size), we could have >> "packet header" keys which protect the content-type itself for all >> non-cleartext TLS records. If we do that, these keys might as well also >> be used to protect the TLS record size itself. This would result in an >> opaque data stream (though obviously record size would still leak in >> DTLS, and timing and framing is still likely to leak the record size in >> the lowest-latency TLS applications). > > Does this need to enlarge TLS record size? Why doesn't encrypting the > content-type/length and then authenticating those off main MAC work maybe i'm not understanding your proposal, but if we're encrypting the record length as well, how do you find (and validate) the main MAC without knowing the record length? > I presume problems from header-flipping (tho in TLS that will kill the > connection if you try...) I'm not sure what header-flipping is... > Also, in DTLS, there could be issues switching the encryption on > (but then, looks like DTLS 1.3 has other unsolved problems > currently..) yes, i think that might be the case. --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call for keys used in handshake and data messages
On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote: > I disagree that this is a low level crypto decision, or at least that this is > mainly so. > > There is the question of whether using the same key for application data and > handshake is harmful. That question is mainly low level crypto and could be > asked of CFRG. > > There is the other question of whether exposing the fact that there are > handshake messages and when they occur is harmful. That is security-related, > but not at all related to crypto. > > Weighing these two potential harms against each other and coming to a > decision is entirely an engineering issue, and we should not offload that to > CFRG. To be clear, we're being asked to trade these things off against each other here, but there are other options which were ruled out in the prior framing of the question which don't rule either of them out. In particular, if we're willing to pay the cost of a slightly more complex key schedule (and an increased TLS record size), we could have "packet header" keys which protect the content-type itself for all non-cleartext TLS records. If we do that, these keys might as well also be used to protect the TLS record size itself. This would result in an opaque data stream (though obviously record size would still leak in DTLS, and timing and framing is still likely to leak the record size in the lowest-latency TLS applications). The current framing of the question pits these things against each other as a tradeoff, but if we want to, we could protect them all. --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call for keys used in handshake and data messages
On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote: > 1. Use the same key for handshake and application traffic (as in the > current draft-13) > > or > > 2. Restore a public content type and different keys Given this choice, i prefer (1). --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Closing on keys used for handshake and data messages
On Fri 2016-06-03 17:54:53 -0400, Joseph Salowey wrote: >Trial decryption has serious implementation problems >- >Double-encrypting handshake messages in both the handshake key and the >application key does not actually provide the required key separation >- >Separately encrypting the content type is inefficient in a number of >ways, especially for DTLS (and would need separate security analysis). This >is probably the most viable of the “try to get both” designs. I'm saddened by this analysis :( I understand that trial decryption precludes inplace decryption, and i can see why that makes it a non-starter for some implementations. I confess i was hoping that double-encrypting would provide some measure of useful key separation for cryptanalysis. I don't think i understand Ilari's explanation in this thread, though, so i'd appreciate any other attempts to clarify. > This leaves us with two primary alternatives: > >1. Use the same key (as in the current draft-13) >2. Restore a public content type and different keys Between these two options, I strongly prefer option 1. > PUBLIC CONTENT TYPES > > Clearly, having a public content type and separate keys for handshake and > application data provides full key separation, at the cost of revealing > whether a given record is handshake or application data (and potentially > alerts). The major question that the group had was whether it was actually > possible to conceal this information effectively, even with encrypted > content types, since hiding the handshake messages in the application > traffic requires detailed knowledge about the application traffic pattern > (e.g., packet lengths, timing, response patterns, etc.). It’s clear some > analysis of this is needed. We know that traffic analysis is difficult, and may in some cases be impossible. This is an area in need of active research. However, deciding to make it *always* impossible to protect because we don't know how to protect it absolutely is "security nihilism", and i hoped we were moving beyond that mindset as a community. If we don't have a mechanism to hide this metadata, then we certainly won't develop any useful practice around actually making it indistinguishable. Protecting users is a multidimensional problem. We should provide a mechanism to make this information indistinguishable in the axis we know how to handle (encrypting the material itself) so that there is a reason for people to work on the axes we don't yet know how to handle (protecting against traffic analysis). --dkg signature.asc Description: PGP signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites
On Wed 2016-03-30 15:20:08 -0400, Ilari Liusvaara wrote:
> On Wed, Mar 30, 2016 at 12:05:26PM -0400, Daniel Kahn Gillmor wrote:
>> On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote:
>> > I am not sure that we want to be in the business of explicitly marking
>> > things as insecure other than our own RFCs, though -- there could be an
>> > implication of more review than is actually the case, which is what this
>> > proposal is trying to get rid of.
>>
>> I think i agree with Ben here: if we have a tri-state:
>> approved/not-approved/known-bad, then the people will infer that the
>> not-approved ciphersuites are better than the known-bad ones, which
>> isn't necessarily the case.
>>
>> I think i'd rather see it stay at "approved/not-approved"
>
> Then how should ciphersuites with explicit diediedie RFCs (currently
> RC4) be presented?
i'd say that they are "not-approved", clearly. :)
We don't represent those RFCs in any way at all right now, and yet they
seem to have some kind of social impact.
I observe that we have a "notes" column in the ciphersuite registry
currently, which indicates one or more RFCs related to the ciphersuite
in question:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
I'm a little disappointed that RFC 7465 ("Prohibiting RC4 ciphersuites")
isn't listed in the Notes column for all ciphersuites using RC4.
Perhaps that change needs to be made as well?
--dkg
signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Why again can't we use TLS signing certs to create short-lived sub-certs?
On Wed 2016-03-30 11:22:15 -0400, Eric Rescorla wrote: > This got a lot of discussion early in the design process and the consensus > was that the risk of having the default mode (with existing certs) allow the > creation of a long-term delegation was too high. See, for instance, the > relative impact of the recent paper by Jager at al. [0] on TLS 1.3 and > QUIC. > > With that said, I think this would be a good feature to look at in future > and the right way to do it is to: > > 1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension to > PKIX. this would need to be a critical extension, since the goal is to have it be unusable by existing endpoints, right? do we have tests about how well existing endpoints will fail closed in the face of unknown critical extensions? > 2. Add a subcert extension to TLS 1.3. This would be necessary for clients to signal that it's ok to use such a delegated cert or subcert. we need to think clearly about how to limit the scope of such a delegation to make it safe. --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites
On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote: > I am not sure that we want to be in the business of explicitly marking > things as insecure other than our own RFCs, though -- there could be an > implication of more review than is actually the case, which is what this > proposal is trying to get rid of. I think i agree with Ben here: if we have a tri-state: approved/not-approved/known-bad, then the people will infer that the not-approved ciphersuites are better than the known-bad ones, which isn't necessarily the case. I think i'd rather see it stay at "approved/not-approved" --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites
On Tue 2016-03-29 21:53:13 -0400, Sean Turner wrote: > 1. The IANA registry rules for the TLS cipher suite registry [1] will be > changed to specification required. > > 2. A new “IETF Recommended” column will be added with two values: “Y” or “N”. > Y and N have the following meaning: > > Cipher suites marked with a “Y” the IETF has consensus on > and are reasonably expected to be supported by widely > used implementations such as open-source libraries. The > IETF takes no position on the cipher suites marked with an > “N”. Not IETF recommended does not necessarily (but can) > mean that the ciphers are not cryptographically sound (i.e., > are bad). Cipher suites can be recategorized from N to Y > (e.g., Curve448) and vice versa. > > 3. We will add a “Note" to the IANA registry itself (i.e., on [0]) that > matches the above so that the same information is available to those who > don’t read the IANA considerations section of the RFC. > > Please indicate whether or not you could support this plan. I support this plan. --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Require deterministic ECDSA
On Mon 2016-01-25 14:10:13 -0500, Yoav Nir wrote: >> On 25 Jan 2016, at 5:08 PM, Salz, Rich wrote: >> >>> But any system running a TLS stack is already going to have a high quality >>> entropy source for client/server randoms and IVs and such >> >> That's assuming a constraint that isn't accurate. > > Eh. Just s/is/should/ Remember that keys (whether in HSMs or not) can be moved between implementations. While it seems (hopefully) likely that most keys will usually be used with a TLS stack with a high-quality entropy source, it's also possible that the key gets used occasionally with some other, less sophisticated code or platform. We should be pushing heavily for deterministic ECDSA, even though it's not something we can require via wire protocol at runtime. --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Record header size?
On Tue 2015-11-17 12:09:30 -0500, Eric Rescorla wrote: > The concern here is backward compatibility with inspection middleboxes which > expect the length field to be in a particular place. We agreed in Seattle to > wait for early deployment experience before modifying the header to move > the length. In particular, if we're going to make a change to the TLS record header, the change would be to remove the version and the type entirely, leaving only two octets of length on each record. Is a two-octet offset going to be problematic? --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-00.txt
On Mon 2015-10-12 09:18:17 -0400, Yaron Sheffer wrote: > I'm not familiar enough with TACK at the moment. I can write something > up, or if you'd like to contribute text, that'll be awesome. i'm not up-to-speed yet either, and am unlikely to be able to get to this soon, sorry! > IMO persisting the master key to disk is less of a problem than > distributing it across cluster members, and this is something that > needs to happen or session resumption will fail regularly. Regular > rotation of the master key means that persisting it to disk is not > such a risk. You are right that a session resumption master key needs > not be backed up, whereas the pinning secret may need to be backed up > securely for disaster recovery. hm, i'm not convinced of this tradeoff in general -- in today's "cloud-y" age, backing up to disk rather than keeping in RAM might trigger writes to data storage that's owned by yet another entity. This means you have the potential for traffic decryption not only to those who can access your CPU and RAM, but those who run your storage backend. Even worse, if the pinning secret is derived from the session resumption master secret as recommended in section 4.2, then the temptation will be to store the session resumption master secret to disk, which puts the forward secrecy of resumed sessions at risk. If admins don't persist the resumption master secret, but persist only the derived secret, then there are two modes of operation: one running from the derived secret, and one running from the backup secret, which sounds messy. Perhaps some implementation guidance is warranted here? > Yes, I was thinking of privacy in the face of passive attackers who > listen in to the TLS handshake. Not when the server itself is out to get > you. I suspect that there is little you can do to protect your privacy > when the server itself is malicious, but I'm sure you are more > knowledgeable about these issues. TLS servers themselves should not be able to track a TLS client in the event that the client decides to not be tracked. For example, a client could refuse to initiate session resumption, and could offer a standardized, common TLS Client Hello. Maybe privacy from a pinned-ticket server can be achieved by a client by simply never sending the ticket pinning extension, or by never sending it on subsequent connections? this would come at the cost of losing the ability to detect when a server's identity gets swapped out, of course. It's not a particularly satisfying tradeoff. > You are right. "Certificate pinning" is the more common term, but is it > less precise. fwiw, "certificate pinning" is also used in https://tools.ietf.org/html/rfc6125#page-11 to describe what browsers often call a "security exception" -- a non-validating certificate that the user explicitly decides to allow for a given site. this kind of additional grant is the *opposite* of the additional restriction you're describing. better to stick to "public key pinning", which has no such connotations. > The longer you keep a keypair, the more likely it is to be compromised. > So you may not want to keep a keypair in "cold storage" for a year, and > then use it as a production cert for another year. > > Depending on your setup, the risk may be much larger on the production > server than on some offline storage, and then your proposed process > makes perfect sense. yes, i intended the proposal to be for an admin who has access to offline storage (though even an encrypted thumb drive locked in a drawer would do). > One difference is that in HPKP, the data stored in (b) is > security-critical, in that its compromise is just as bad as compromise > of the site's regular secret key (you can use it to MITM all > connections to the server). In my proposal the pinning secret is truly > a "second factor". Its compromise is an issue only if you can *also* > generate a fake certificate. I'm not sure about this distinction. No certificate has been issued for the HPKP backup key until just before it is deployed. So the attacker has to get a certificate issued for that secret key anyway, right? > Another major difference is that my proposal avoids the manual > management steps of HPKP (at least until we have ACME widely > deployed). The pinning secret can be generated automatically when the > server is started and rolled over periodically, with no human in the > loop. Since you'd still need to persist the secret to disk in some reliable way that handles rotation, backup, etc. safely if you don't want to risk bricking the site, I think you're saying that hypothetical software stack X has a better chance at successful implementation and deployment than hypothetical software stack Y. ;) Thanks for proposing this, Yaron. --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-00.txt
Hi Yaron--
On Sun 2015-10-11 15:57:38 -0400, Yaron Sheffer wrote:
> We have a standard for certificate pinning (RFC 7469), but it is rather
> hard to use and as a result is rarely deployed. This draft proposes a
> lightweight alternative that allows TLS clients to authenticate the
> server they're connecting to, even if a rogue CA can generate fake
> certificates for that server.
>
> The draft is currently TLS 1.3-only, and is based on the previous draft
> of 1.3 so some minor details may have changed.
I've only just skimmed thus far, but i'm happy to see this proposal. A
few comments below:
TACK
As you note in the draft, it addresses a similar problem as TACK, which
never made it through the standards process:
http://tack.io/draft-tack.html
perhaps it would be useful to have a section next to the Comparison:
HPKP that included a Comparison: TACK ?
(dis)similarity to session tickets
--
In the session-ticket case, most servers (clustered or otherwise) can
afford to treat their session ticket master keys as ephemeral keys -- if
the server is restarted or dies and is re-installed, the worst that
happens is that a client doesn't get to resume their session -- they
have to open a new connection.
If the session ticket resumption master keys are used as recommended
here, it seems like the risk of master key loss is bricking the server,
so the master key becomes necessary to store non-ephemerally.
Writing the master key to disk or storing it off-site someplace can
present a risk to the forward-secrecy of ticket-resumed sessions.
tracking the master key itself seems like it also adds specific
operational overhead for server maintainers that doesn't currently
exist. Does this reduce the advantage of the scheme over TACK or HPKP?
if not, can you explain why not?
Client Privacy
--
section 6.6 says "TODO", and page 5 says:
> The main reason for refreshing the ticket on each connection is
> privacy: to avoid the ticket serving as a fixed client
> identifier. It is RECOMMENDED to include a fresh ticket with
> each response.
If the participating client wants privacy from the server (to avoid the
server using this to track the client) but also wants defense against
broken CAs, how does recomending this behavior from the server actually
allow the client to enforce privacy?
The server is trivially capable of tying together a history of
pinning_ticket objects to track specific clients, right? it just
remembers the two tickets involved every time it generates a
PinningTicket extension. If the pinning tickets returned by the server
are different each time, the client cannot know whether the server is
doing this tracking or not.
public key vs. certificate
--
In your introduction (and in the mail above), you refer to "certificate
pinning" -- but i don't think there is anything out there that is
"certificate pinning" -- HPKP is public key pinning, and it ignores the
certificates that wrap any given public key. So your tables should
really refer to "main public key" and "backup public key", not "main
certificate" or "backup certificate".
HPKP example workflow
-
Your HPKP timeline seems to assume that your "old backup certificate"
can't be used as your "new main certificate" -- what makes you say this?
I agree with you that HPKP end-entity pinning generally makes more sense
(and is more useful at defending against malicious/incompetent CAs) than
authority pinning. But I'd expect an HPKP timeline using end-entity
pinning to be more like:
lower-case letters are public keys. we presume that the site
administrator has the corresponding secret keys backed up
offsite/offline somewhere, and the associated certs and secret keys
needed to operate the web site get deployed as needed.
Initial deployment:
HPKP: { a, b } Cert: A = X.509-wrapped(a)
as A approaches expiry, we generate a new key c (storing its secret key
offline), get a new cert made over b, and switch to:
HPKP: { b, c } Cert: B = X.509-wrapped(b)
As B approaches expiry, we do the same dance, generating d and making a
cert over c:
HPKP: { c, d } Cert: C = X.509-wrapped(c)
and so on.
Does this simpler cycle change your analysis of HPKP?
I tend to think HPKP deployment has been slow because:
(a) the risk of bricking the site makes admins (justifiably) nervous
(b) having to have an additional offsite store (of your HPKP backup
secret key) to avoid site-bricking is a workflow that most admins
don't already have in place.
But i don't think your proposal addresses these issues either (though
the data stored offsite for (b) is slightly different between your
proposal and HPKP). Does it address them in some way that i'm missing?
Regards,
--dkg
signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/li
Re: [TLS] TLS 1.3 - Support for compression to be removed
On Fri 2015-10-02 12:24:24 -0400, Martin Rex wrote: > The value of real padding is highly dependent of whether and how it > will actually get used, and is far from automatic. Sure, but we have no existing mechanism to do that in TLS 1.2 or earlier. We need the mechanism before anyone can establish sensible policy. Understanding what policy is sensible is likely to be endpoint-specific, and is definitely something that needs research. But we can't implement any policy at all without having the mechanism in place. > Btw. retrofitting real padding as "compression alg" into TLSv1.0-TLSv1.2 > would be trivial, and work fine with TLSv1.2 AEAD. "would be trivial" is not "has been specified". It also requires negotiation, whereas hopefully in 1.3, we will not need to negotiate padding. Furthermore, If you treat padding as a "compression alg" in 1.2, then the folks who started this thread who want 1.2 because of its support for compression would not be able to use padding in conjunction with compression (if someone has a use case for such a combination, which seems counterintuitive at first glance). So this proposal doesn't really address the original reason for the suggestion of "stay on 1.2". > encrypted content types looks like lame duck with zero value to me. > > "Is not readily distinguishable by existing deep packet inspection (DPI) > filter types" is pretty much the only thing--and adjusting DPI will be > far from rocket science. I beg to differ -- if there is any interleaving of application_data and other content types, and if records can be arbitrarily-sized, it's not clear to me how a DPI can distinguish one from the other. Can you be more specific? > Trying to make a single bit of information stick out less prominently > will only create a false sense of security whenever that bit of information > can be trivially detected from the traffic pattern. We need to be looking at things the other way around: if there's a sensible way to leak less metadata, we should be leaking less metadata, even if there are other ways that the same information can be recovered by a similar adversary. "don't fix X because Y has the same problem" is a great symmetric recipe for not getting anything done. We should be saying "we need to fix both X and Y" instead. > But the collateral damage is that you break stuff that feeds on the > outer record layer structure and state, which can easily push adoption > of TLSv1.3 from the 5-years-spec-to-usage for TLSv1.2 to the > 15-years-spec-to-marginal-use marginal use seen with IPv6. Can you enumerate the stuff you expect to break from encrypted content type that will cause a decade-long delay in adoption? It would be great to have a list of those things so we can evaluate them. --dkg ___ 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 Fri 2015-10-02 11:24:10 -0400, Salz, Rich wrote: >> Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ? > > They are equivalent. If you use AES-GCM and ECDHE, and you don't need 0RTT, > then there is no compelling reason to use TLS 1.3. ...and you use session-hash, and you either don't do renegotiation or require secure renegotiation, and you don't use TLS-Unique, and you're ok with fully-cleartext handshakes, and (maybe something(s) else i'm forgetting) ... I don't think we should be claiming that TLS 1.2 is equivalent to TLS 1.3 without many more caveats. :) --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)
On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni wrote: > So the client would now need to cache some session data by transport > address, and other data by name and port. That's rather complex. This is already done by HTTP/2 clients, since they can access multiple servers at the same address:port combination. > And how often will the same client visit multiple servers at the > same transport address? *.github.io, *.blogspot.com, massive CDNs, etc. It's a common pattern. > I don't really see this as viable or worth the effort. I disagree -- the metadata leaked to a passive attacker by mandatory SNI is a valuable signal. It is worth trying to protect it. > I don't think SNI hiding is viable without encryption at the > transport or network layers. any encrypted SNI is effectively acting as a shim for transport encryption, yes. Then again, TLS is itself "transport layer security", so we should try to provide it at least as an option. > And there's still a metadata leak via DNS which may prove difficult to > address. The DNS community is working to address the DNS leak in DPRIVE. The TLS community should be working to fix its own part of the metadata leak. --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] encrypted content type and padding
On Mon 2015-09-21 04:43:27 -0700, Watson Ladd wrote: > Is this actually true in the second pull request? No: a moment of > actually reading reveals that the string is inside an AEAD encrypted > packet. There is no way in which this padding could be modified for > use in a side-channel attack. In both pull requests, the padding is inside the AEAD encrypted packet. The intent, after all, is to create a mechanism that provides uncertainty about the length of the cleartext. See, for example: I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis by Brad Miller, Ling Huang, A. D. Joseph, and J. D. Tygar http://arxiv.org/abs/1403.0297 --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Review of PR #209
On Sun 2015-09-20 22:38:45 -0700, Karthikeyan Bhargavan wrote: > As dkg points out, dynamically authenticating clients later in the connection > brings up > API issues of how to notify the application about the scope of this new > authentication event. > > I think it is inevitable that implementation will store the client credential > in the session, and > that the new (authenticated) stream of data will be concatenated to the older > (unauthenticated) stream. > Both of these design choices will lead to the following answers to dkg’s > questions: > (a) all messages in TLS sessions (past and present) will be attested to by > every certificate > (b) all traffic in earlier and future resumed sessions will be attested to by > every certificate > > In other words, if we do allow this change to client authentication, to be > safe, we must analyze the > resulting protocol *as if* applications will use the authentication event to > attest to all > data, past and present, that may be associated with the data in the current > connection. But this combination is pretty weird for servers to deal with. For example: Consider a server has an ongoing session wrapped in TLS that uses client authentication to approve or deny some requests from the client. It remembers what requests the client has made as some sort of relevant state. Let's take an imap server working with a client that has state of a "currently-examined folder", but this applies to servers and clients with much more complex state as well. The client is currently examining folder Y. Some client identities *do not* have authorization to visit folder X. others do. The client requests a change to folder X. The server rejects the change. The client subsequently authenticates to an identity that is authorized to access folder X. What is the currently-examined folder for this session? The "easy" (and right) answer here is "folder Y, of course" -- but telling peers that the authentication should apply retroactively to all previous data sent suggests that maybe it should be folder X. This is confusing. Confusing semantics are bound to lead to problematic implementations and usage :( Sorry that this mail doesn't have a better suggestion to offer. --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] encrypted content type and padding
Hey TLS folks-- apologies for the delay in sending these pull requests. encrypted content type: --- https://github.com/tlswg/tls13-spec/pull/51 This should be uncontroversial, and just needed freshening against the current draft. padding: We're now proposing that handshake padding should be offered by introducing a new HandshakePadding message. I've avoided any sort of padding negotiation in the handshake in favor of making padding always available in TLS 1.3 and up. Life is simpler this way. There are two approaches available for application data padding which we failed to select from at Prague (possibly because this is a bikeshed). My preferred approach is to use a standard tls opaque field for application data padding: https://github.com/tlswg/tls13-spec/pull/249 But if anyone is interested, i've also mocked up using a "padding is all 0x00 up to the first 0x01" approach: https://github.com/tlswg/tls13-spec/pull/250 This last approach is unlike anything else in TLS data structures, but it does give the sender the ability to pad with only one octet. There may be a slight sidechannel difference between offsetting by the size of the TLS opaque padding object (PR #249) when compared to running memchr(cleartext, '\001', cleartext_length) (PR #250), but i suspect that timing difference is small compared to the difference incurred by whatever is processing the cleartext (though if the cleartext processor was designed to be constant time itself, the padding timing sidechannel might be noticable). i personally prefer PR #249 because it is more inline with the traditional layout of TLS data elements, and lacks additional risk of timing differences. Its main downside is its inability to pad by anything less than two octets, which slightly complicates calculations of how much to pad when padding algorithmically. See you all in the morning, --dkg ___ 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 Fri 2015-09-18 15:47:27 -0400, "Salz, Rich" wrote: > Can NNTP and HOB/VPN stay on TLS 1.2 which does have the compression > feature you need? What TLS 1.3 feature is compelling here? I think this line of argument is worrisome -- we should try to avoid leaving behind protocols that need TLS, if we ever want to be able to deprecate TLS 1.2 the way we've (finally) deprecated SSLv3. That said, i think there are multiple approaches for NNTP and HOB/VPN that don't involve using compression at the TLS layer. For instance, with NNTP, if they're certain that CRIME isn't a risk for their use case, they could introduce a STARTCOMPRESSION verb by analogy to STARTTLS. If the only reason they're using TLS in the first place is for compression, this would be a simpler and less-risky approach in terms of software dependencies as well. I don't know enough about HOB's use of TLS to know whether they could shim their own compression layer in between the VPN traffic or not. The TLS WG knows that compression represents a serious risk to encrypted traffic, especially in situations like browsers where an adversary can direct a peer to initiate protocol action. Compression itself also represents added complexity for protocol analysis. I think we should remove compression and we should also explicitly warn users of the protocol about the risks of combining compression with TLS. --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Review of PR #209
On Wed 2015-09-16 13:48:27 -0400, Martin Thomson wrote: > On 16 September 2015 at 08:30, Ilari Liusvaara > wrote: >> As then the application needs to ensure that the authentication >> occurs between TLS handshake and actually starting up the protocol. > > I'm not sure that is necessarily a problem. If the claim is that the > authentication attests to everything prior to its appearance, then you > have no problem. I think that claim is reasonable, but I'm happy to > discuss it. I think this claim sounds confusing, for (at least) two reasons: (a) it interacts oddly with the possibility of > 1 CertificateVerify message -- does it imply that all messages in a TLS session (past and present) are attested to by every client certificate ever sent in the session? (b) it has unclear semantics around session resumption. If i resume a session and send a ClientCert+CertificateVerify, am i retroactively attesting to all the communications from the previous session(s)? What does that even mean to the server which has already processed the traffic from previous sessions? Can we communicate these semantics to application developers who might have an "accelerating" TLS session cache available, or who might share a session cache between systems? Can we help clients make sense of the implications of retroactive attestation when confronted with a certificateRequest? --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Wed 2015-09-16 20:21:11 -0400, Viktor Dukhovni wrote: > The difference between raw public keys (RFC7250 RPK) and anon is: > > - PRO: Dropping anon simplifies the implementation and reduces > cipher count. > > - PRO: Raw keys may facilitate TOFU pinning. > > - CON: Raw keys are not yet implemented in any toolkits I've seen > (a temporary setback perhaps). > > - CON: Raw keys send more traffic (public key in certificate > message, plus signature of key agreement). Byte counts can > matter in some environments. > > - CON: Raw keys consume more CPU (signing the key agreement). > > - CON: Servers lose a simple signal that the client is not > bothering with authentication. and: - PRO: passive attackers on the network lose a simple signal tha tthe client is not bothering with authentication. > The costs are likely noticeable for 4096-bit RSA keys. A server concerned about CPU or bandwidth costs who would have preferred anon_DH suites would be silly to select 4096-bit RSA, whether RPK or cert. They should choose some small ECC key. A client concerned about CPU who would have been fine with anon_DH will simply not verify the signature at all. So that leaves clients concerned about bandwidth, who pretty much have no choice but to eat the handshake message that the server sends them anyway :/ --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for consensus to remove anonymous DH
On Tue 2015-09-15 21:00:39 -0400, Joseph Salowey wrote: > There has been some discussion to remove anonymous DH as described in > https://www.ietf.org/mail-archive/web/tls/current/msg17481.html. I think > ekr's message sums up the pros and cons well. I don't think we have > consensus on this issue yet. Please respond on this message by Monday, > September 21, if you have an opinion. I support removing anonymous DH for the server side[0] of TLS. TLS servers that want to effectively do "anonymous" DH can craft a raw public key or certificate and forge a signed_params to match. They can do this per-session if they do not want to present a persistent identity. For those worried about computational cost: the raw public key or certificate themselves do not have to be valid mathematical objects if the peer is not inclined to check them. The signed_params itself could also be all 0xff or anything you like as long as the peer isn't checking. For those concerned about bandwidth, these objects do not have to be large. This simplifies the expected messages and transitions in a TLS handshake. I think that's a good thing, given the errors we've seen already in state machine implementations. --dkg [0] I do not think that clients engaged in a DH key exchange should be uniformly required to claim an identity at the TLS layer :) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS and KCI vulnerable handshakes
On Tue 2015-08-11 19:59:35 -0400, Martin Thomson wrote: > On 11 August 2015 at 16:38, Clemens Hlauschek > wrote: [ MT wrote: ] >>> NSS (incorrectly) adopts the posture that _ECDH_ suites are >>> half-static: the server share is in the certificate, but the client >>> side is fully ephemeral. This is clearly in violation of RFC 5246, >>> Section 7.4.7 and RFC 4492, Section 3.2. I'm not going to worry about >>> that right now :) >> >> Please elaborate. I do not see how this half-static behaviour >> constitutes any violations of the mentioned RFCs. > > Both the above cited sections say very clearly that for fixed (EC)DH > cipher suites the client where the client has a fixed (EC)DH > certificate, the client MUST send an empty ClientKeyExchange. that's not how i'm reading 5246 §7.4.7 -- i see it as saying if the client has decided to send a fixed (EC)DH cert, then it MUST send an empty ClientKey Exchange. I see no requirement that a client MUST send a certificate if it has one that satisfies the server's CertificateRequest (and i would be strongly opposed to adding such a requirement -- clients should not be forced to reveal identity to a server just because of CertificateRequest message in the handshake). so i think NSS is doing the Right Thing here too. --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New version of draft-lonc-tls-certieee1609-01.txt
On Thu 2015-07-09 15:43:16 +0200, Nikos Mavrogiannopoulos wrote: > This draft uses the rfc6091 cert_type extension. If that is not > intentional, rfc6091 was made obsolete by rfc7250 which uses the > server_certificate_type and client_certificate_type extensions (even > though the text doesn't mention that). There is no explicit "obsoletes:" header in 7250. Should we post an erratum to either 7250 or 6091 or both to provide clearer guidance for future authors? --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-shore-tls-dnssec-chain-extension-00
Thanks for this draft, i'm definitely interested in seeing it push forward. On Wed 2015-07-01 05:58:20 +0200, Viktor Dukhovni wrote: > Instead, there would need to be in various cases: > > * A validated chain of CNAMEs (possibly synthesized via validated > DNAME RRs) leading from the client's requested SNI name to > a final TLSA base domain. (0 or more CNAME/DNAME indirection > records and all the DNSKEY/DS/RRSIG records to validate > these). > > * A validated chain of CNAMES from _port._proto. to > an actual validated TLSA RRset (and ...). > > * The final TLSA RRset with all the requisite validation records. > > * Also a potential change in the client's notion of the reference > identifier to match in certificates, to the final TLSA base domain. Complicating this further, there could be a chain to an SRV or MX record, which then needs to chain to the TLSA, in think (possibly with CNAMEs in the mix). This is potentially a pretty long chain. also: how does a multi-tenanted server know what SRV or MX chain to include in the chain? --dkg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
