Re: [TLS] [lamps] [EXTERNAL] Distinguished names for self certified TLS client authj

[Jeffrey Walton]

On Tue, Jun 14, 2022 at 11:14 PM Phillip Hallam-Baker
 wrote:
>
> Hmm... looks like this is a piece of brokenness in the browsers.

I don't think client certs are a priority for Browsers. That would
significantly hinder support of interception, which is a browser
design goal under Priority of Constituencies [1]. Browsers see
interception as a valid use case for DLP programs.

Instead of client certificates (and Origin Bound Certificates), the
browsers prefer transport schemes so traffic can be intercepted like
FIDO and token binding gear.

(The open question for me is, how does a browser tell "good"
interception from a "good" guy opposed to "bad" interception from a
bad guy).

Jeff

[1] https://w3ctag.github.io/design-principles/#priority-of-constituencies

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

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

[Jeffrey Walton]

On Tue, May 29, 2018 at 4:21 PM, Salz, Rich
 wrote:
>>There's a tradeoff between respecting the official allocation processes
> and avoiding real-world breakage.  I think we can all make our own 
> assessments
> on the former, but for the latter, all the evidence we have so far is a 
> claim
> from Peter that there exists software that hardcodes this number, with no
> indication of scale of deployment or ease of updating such software.
>
> Peter tried very hard to play by all the rules, whether they were enshrined 
> in formal documents, or "just" decisions by WG chairs, and everything 
> in-between.
>
> Peter says the number is in use.
>
> I believe him.
>
> Give him the damn number.

+1.

I also delivered an OpenSSL-based TLS-LTS prototype to a Hoteliers
working group for their smart locks last year. I have no idea how much
of the code they are going to reuse (if any at all).

Jeff

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

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Jeffrey Walton]

On Wed, Oct 25, 2017 at 12:21 PM, Roland Zink  wrote:
> It could but RFC 7469 section 2.6
> (https://tools.ietf.org/html/rfc7469#section-2.6) says:
>
> "  It is acceptable to allow Pin
>Validation to be disabled for some Hosts according to local policy.
>For example, a UA may disable Pin Validation for Pinned Hosts whose
>validated certificate chain terminates at a user-defined trust
>anchor, rather than a trust anchor built-in to the UA (or underlying
>platform)."
>
> and most browsers seem to follow this mitm exception.

The browsers are also complicit in the coverup. Reporting the broken
pinset to the user or site is a  "should not", even though
organizational policies and regulations may require it.

Jeff

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

Re: [TLS] Update on TLS 1.3 Middlebox Issues

[Jeffrey Walton]

On Sat, Oct 7, 2017 at 11:25 AM, Salz, Rich  wrote:
>
>
>> I suggest we not have this debate now. We'll have a lot more data towards
>> the end of the month and we can have an informed discussion then.
>

> That is what I am asking for.  More information so that the entire WG can
> make an informed decision.  And I was only laying out an option that does
> not seem to have been considered before.

The group (or the IETF) might also consider a policy to answer Ilari
Liusvaara's question, "What you think is acceptable failure rate?"

That is a governance issue. It should probably be [nearly] written in
stone and applied equally to all problems and decisions.

As an example, the US's IRS used to have a policy to support any
browser with 3% market share or more. I don't know what it is
nowadays.

Jeff

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

Re: [TLS] Removing restriction on cross-domain resumption

[Jeffrey Walton]

On Fri, Sep 22, 2017 at 9:15 PM, Martin Thomson
<martin.thom...@gmail.com> wrote:
> On Fri, Sep 15, 2017 at 8:42 AM, Jeffrey Walton <noloa...@gmail.com> wrote:
>> The current models uses origins as a boundary, so they are different
>> security contexts.
>
> That's not relevant here.  A certificate allows a server to speak for
> multiple origins.  The notion of an origin is, as you say, established
> at a higher layer.  TLS establishes a broader notion of identity.

As far as I know, the IETF does not forbid inclusion of logically or
administratively disjoint hosts from a certificate. In a shared
hosting environment with a super cert, it seems like it would be easy
to confuse a user agent into binding the wrong name.

The IETF does not forbid an IP address either, so it seems like IP
addresses could be a sore spot, too.

And the hosting provider could pass the customary checks, like DV
emails. So there does not seem to be a security control available to
contain the risk.

Jeff

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

Re: [TLS] Removing restriction on cross-domain resumption

[Jeffrey Walton]

On Wed, Sep 13, 2017 at 5:57 PM, Victor Vasiliev  wrote:
> Currently, TLS 1.3 specification forbids resuming the session if SNI values
> do not match.  This is inefficient in multiple cases, for example, if you
> have a wildcard domain cert, and the user is likely to visit multiple
> subdomains over a longer timespan, so there is no existing connection to
> pool on (or it's impossible to pool because of different IP addresses).
>
> Last time we discussed this,
>   https://www.ietf.org/mail-archive/web/tls/current/msg21655.html
> no one has pointed out a good security reason why this should be forbidden.

The current models uses origins as a boundary, so they are different
security contexts.

A related twist is, the boundary is established at layer 7, but layer
3/4 has no knowledge of it.

The DBOUND working group was not able to produce a deliverable. There
is no general purpose way to establish those boundaries.

To play devil's advocate, will the TLS stack need to keep a copy of
the certificate or authorized origins (an origin group?) for future
connections?

Jeff

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

Re: [TLS] 32 byte randoms in TLS1.3 hello's

[Jeffrey Walton]

On Tue, Jul 25, 2017 at 9:21 PM, Christian Huitema  wrote:
> ...
> Not sure. I am looking at the implementations of QUIC. QUIC needs its own
> set of random numbers for things like connection ID or initial sequence
> number. The most natural thing to do is do get them from the OS API,
> /dev/random or cryptogenrandom(), but that requires platform specific code...

Somewhat related (but OT for TLS-WG): According to the Linux Kernel
Crypto folks, you should not use /dev/random because it is a
deprecated interface. You should use /dev/urandom, and it has been
recommend for the last decade or so. Also see "[RFC PATCH v12 3/4]
Linux Random Number Generator" (https://lkml.org/lkml/2017/7/20/993)
on the kernel-crypto mailing list.

The BSDs, OS X, DragonFly, and others may be different. But for Linux
the advice is clear.

Jeff

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

Re: [TLS] datacenter TLS decryption as a three-party protocol

[Jeffrey Walton]

On Sun, Jul 23, 2017 at 5:37 PM, Christian Huitema  wrote:
> ...
> Speaking of threat model, one of the main threats is the "Lavabit" case: a
> server is asked to somehow implement a backdoor so existing clients. In that
> case, it is very useful for clients to detect that something has changed.
> They can move away and use another server.

That existed long before LavaBit. Hushmail FTW!

I was saddened to see a Canadian company cooperate with US law
enforcement by backdooring their applet. (Give credit where credit is
due).

Jeff

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

Re: [TLS] Is there a way forward after today's hum?

[Jeffrey Walton]

On Thu, Jul 20, 2017 at 9:35 AM, Robin Wilton  wrote:
>...
> If I am analysing this correctly, there are two "tampering events" involved
> here.
>
> The first is: has someone tampered at the protocol/notification level to
> prevent the client from being notified that static DH is in use?
>
> The second is: when the client decrypts traffic using whatever has resulted
> from the key exchange protocol, can it tell whether the DH key that was used
> is a static one or not?
>
> I don't know enough about your proposed extension to judge whether it's
> reasonable to assume that the finished message processing would detect
> either of those or not (but I freely admit, that's my lack of knowledge).

In my mind's eye, and stepping back to 10,000 feet, the security
engineering problem you are witnessing is:

   * The security community has advised "DH for perfect forward secrecy"
   * RSA key transport was deprecated because it does not provide PFS
   * The proposal does an end-around, and it breaks
expectations/security properties

The security community created the "reasonable expectation" of PFS
when using Diffie-Hellman. A typical developer who follows best
practices will expect it. It was pounded into heir heads. Cf.,
https://www.imperialviolet.org/2013/12/03/forwardsecretforjournalists.html
and https://www.imperialviolet.org/2013/06/27/botchingpfs.html.

The typical developer will not be able to make the distinction between
Diffie-Hellman Ephemeral and Static Diffie-Hellman modulo key vaulting
so traffic can be decrypted later. In the typical developer's eyes,
they have been told to do something because it has certain security
properties but it no longer holds.

The signalling indicates the loss of the security property typical
developers and users have come to expect.

Jeff

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

Re: [TLS] Malware (was Re: draft-green-tls-static-dh-in-tls13-01)

[Jeffrey Walton]

On Mon, Jul 17, 2017 at 10:23 AM, Blumenthal, Uri - 0553 - MITLL
 wrote:
>   And why are you unable to understand that that in the case of an 
> additional layer of
> attacker-generated crypto nestled within a TLS tunnel, as you posited, that 
> the ability
> to simply detect the presence of such an additional layer of unexpected 
> crypto, even
> without the ability to immediately decrypt it, has substantial value in a 
> security context?
>
> It may, or it may not – depending on the sophistication of your adversary. It 
> is not given that you’d be able to “simply detect the presence of an 
> additional crypto layer”, particularly if measures are taken to hide it.

+1.

For example, Rule of 2 in Fishbowl encryption:
https://en.wikipedia.org/wiki/Multiple_encryption.

And since WebCrypto is [mostly] standardized, sometimes it will happen
as JavaScript is encryption applied to the protected stream that
inadvertently gets TLS encryption applied. Its just a matter of time
before it trickles into components like RabbitMQ.

Jeff

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

Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Jeffrey Walton]

On Sat, Jul 15, 2017 at 1:58 AM, 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?

Opt-in is choice. Choice for a consumer is usually a good thing.
Sunlight is the best disinfectant.

The market can punish those who don't respect privacy concerns. I
can't speak for others, but I regularly avoid services that I find
unpalatable.

Some evildoers won't tell the truth. Eventually some will be caught.
The market can punish those who get caught.

EU regulators may be able to exert legal pressure on dishonest
evildoers. I doubt the US will take any action. The oligarchy is
strong on this side of the pond.

I speculate EU entities that were honest about their practices will
sidestep some regulatory actions.

Jeff

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

Re: [TLS] chairs - please shutdown wiretapping discussion...

[Jeffrey Walton]

On Mon, Jul 10, 2017 at 3:37 PM, Stephen Farrell
 wrote:
>
> And if coercion of a server to comply with a wiretap
> scheme like this stills fanciful to you, please check
> out the history of lavabit - had there been a standard
> wiretap API as envisaged here it's pretty certain that
> would have been the device of choice in a case like that.
> While it's easy enough to envisage many other abuses
> that could be based on this wiretap scheme, that one is
> a good match and a real one.

There's a lot of insight based on the history.

If the mechanism operated at layer 3 or 4 (modify the protocol), then
the net is cast overly wide in a shared hosting arrangement. That is,
all virtual host's traffic is captured and recovered.

If it operates at layer 6 or 7 (modify the applications and/or its
libraries, like Apache or Nginx), then there is more precision in
target traffic. That is, only the target's traffic can captured and
recovered.

Jeff

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

Re: [TLS] Security review of TLS1.3 0-RTT

[Jeffrey Walton]

On Tue, May 2, 2017 at 9:45 PM, Colm MacCárthaigh  wrote:
>
> On Tue, May 2, 2017 at 5:51 PM, Viktor Dukhovni 
> wrote:
>>
>> .Some choices are driven by practical engineering considerations.
>>
>> The ticket lifetime is likely to be considerably longer than the
>> replay clock window.  The server should indeed reject replays,
>> but if it is able to flush the replay cache faster, it may be able
>> to handle that job a lot more efficiently under load.
>
> Good point! It's also common for caches to implement LRU, where a shorter
> lifetime is better.
>
>> What is a likely ticket lifetime for a server that supports 0-RTT
>> (let's assume an HTTP server)?
>
> I'm going to guess that providers will set it as high as they can ... every
> little helps. So 7 days.

It seems like this would follow the same policies for session
management and/or authentication and authorizations. If its low value
data (like a GMail account), then let it live longer, like weeks. If
its high value data (like executive compensation, mergers and
acquisitions or pending litigation), then its probably shorter, like
hours to days.

What's the polyfill that allows data sensitivity levels to trickle
down into the transport layer?

Jeff

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

Re: [TLS] Confirming consensus: TLS1.3->TLS*

[Jeffrey Walton]

On Thu, Nov 17, 2016 at 9:12 PM, Sean Turner  wrote:
> At IETF 97, the chairs lead a discussion to resolve whether the WG should 
> rebrand TLS1.3 to something else.  Slides can be found @ 
> https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf.
>
> The consensus in the room was to leave it as is, i.e., TLS1.3, and to not 
> rebrand it to TLS 2.0, TLS 2, or TLS 4.  We need to confirm this decision on 
> the list so please let the list know your top choice between:
>
> - Leave it TLS 1.3
> - Rebrand TLS 2.0
> - Rebrand TLS 2
> - Rebrand TLS 4
>
> by 2 December 2016.

Please forgive my ignorance...

Who are you targeting for the versioning scheme? Regular users? Mom
and pop shops with a web presence? Tech guys and gals? Security folks?

For most tech people and security folks, I don't think it matters
much. However, how many regular users would have clung to SSLv3 and
TLS 1.0 (given TLS 1.2 was available) if they were named SSL 1995 and
TLS 1999 (given TLS 2008 or TLS 2010 was available)?

(Sorry to violate the Hum restriction).

Jeff

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

Re: [TLS] Industry Concerns about TLS 1.3

[Jeffrey Walton]

> PCI requirement providing Intrusion Detection at the entrance to Cardholder 
> Data Environments as well as at critical points inside the Cardholder Data 
> Environment.  Intrusion Detection requires decryption of TLS.  For some 
> large, complex organizations this can be a large number of physical 
> inspection points, more than can be accommodated by MITM.  I understand this 
> may not be a problem for your current environment but others do not have that 
> luxury.
>

This may be less than an ideal requirement.

Malware wants to do three things (with some hand waiving): (1) spread,
(2) collect data, and (3) egress data. I think Step (1) and intrusion
detection is a worthy cause, but not at the cost of breaking the
secure channel.

Perhaps it would be better to focus on (2) and (3). (2) can be tricky
based on how deeply the malware is burrowed in. (3) is much easier
since the malware needs to open a socket.

Policies for (3) are really just whitelist/blacklist approaches. I'm
guessing egress points are wide open at the moment, and the PCI
requirement is fostering blacklists and causing the organization to be
reactive. If the egress points are closed at the organizational
boundary, then the organization is proactive and using a whitelist
approach.

Would it be possible to have the PCI folks re-examine their position
since it seems to be boxing BITS members into something untenable?

Jeff

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

Re: [TLS] Industry Concerns about TLS 1.3

[Jeffrey Walton]

On Fri, Sep 23, 2016 at 5:34 PM, BITS Security
 wrote:
>> you can keep using TLS1.2 in your internal network, can't you?
>
> There are both public and private sector regulators arcing towards being more 
> prescriptive in this area.  It is possible, if not likely, in the not too 
> distant future that my member companies will not have the choice to 
> "downgrade" to "obsolete" TLS versions.

Its not the first time C has worked against security.

Password complexity and rotation policies come to mind; they cause the
security in the system to drop as users are forced to comply.

Would a KMIP/KeyServer help? Hosts can ask the key server server for
its random key or seed material, and then use them key derivation and
for protocol execution. I built a proof of concept interception proxy
to do it a few years ago to help understand the intersection a service
like CipherCloud with C

Jeff

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

Re: [TLS] Industry Concerns about TLS 1.3

[Jeffrey Walton]

> Look, pretty much the entire world is being spied on by national-scale 
> adversaries who are recording all traffic for eventual decryption and 
> correlation.  *Almost everyone* is having their traffic surveilled. The 
> problems of debugging a set of enterprise apps doesn’t amount to a hill of 
> beans in that world. It just doesn't. Same for a particular industry's 
> regulatory requirements.
>

+1, this and what follows is why its important to me.

Years ago I worked with a Vietnamese fellow named Say Ok. We had a
shared locker room, and I noticed Say had six or eight scars on his
chest and abdomen, so I asked what they were. They were the scars from
the bullet holes when the North Vietnamese tried to murder him because
he wanted a democracy and better life for his children.

I can't even talk about some of the obscene things I know are going on
in some US DoD programs. I'm hoping/waiting for Glenn Greenwald, Laura
Poitras and Ewen MacAskill to break those stories.

Jeff

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

Re: [TLS] Industry Concerns about TLS 1.3

[Jeffrey Walton]

On Fri, Sep 23, 2016 at 10:46 AM, Ackermann, Michael
 wrote:
> From the perspective an Enterprise that runs these applications and has 
> invested HEAVILY in the debugging networks.
>
> The reason we are debugging these networks is so that "The 5-6 order of 
> magnitude of folks using them"  will have good service.   If they do not,  
> they will consider competitors and/or generate a litany service calls or 
> complaints.I.E. When these "Folks"  are slow or not working they 
> are just as unhappy as we are.
>

Isn't that the market operating as expected? Those who deliver a
stable product at a competitive price are rewarded, while those who
fail to deliver or deliver at an unreasonable cost are not? (Some hand
waiving).

If all providers failed to deliver or delivered an inferior product,
then it might indicate a major course correction is needed. But I
don't think that's the case here.

Jeff

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

Re: [TLS] chacha/poly interop?

[Jeffrey Walton]

On Mon, Sep 12, 2016 at 8:10 PM, David Benjamin <david...@chromium.org> wrote:
> On Mon, Sep 12, 2016 at 7:35 PM Jeffrey Walton <noloa...@gmail.com> wrote:
>>
>> On Wed, Dec 9, 2015 at 8:02 PM, Salz, Rich <rs...@akamai.com> wrote:
>> > OpenSSL just landed our chacha/poly implementation into master.  We pass
>> > the
>> > RFC test vectors, looking for other implementations to test against.
>>
>> Sorry to dig up an old thread
>>
>> I tested against Bernstein/ECRYPT ChaCha and test vectors from
>> http://tools.ietf.org/html/draft-strombergson-chacha-test-vectors.
>> TLS-ChaCha does not inter-operate with ChaCha.
>>
>> The name should probably be disambiguated somehow.
>
>
> TLS-ChaCha is actually RFC 7539 which comes with its own test vectors and
> isn't TLS-specific.

Oh, my bad... I grabbed the 5 vectors from
http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305. I used them
because I believe the kernel-crypto is using them.

Let me try with RFC 7539 and see how things react with the 7539 vectors.

Jeff

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

Re: [TLS] chacha/poly interop?

[Jeffrey Walton]

On Wed, Dec 9, 2015 at 8:02 PM, Salz, Rich  wrote:
> OpenSSL just landed our chacha/poly implementation into master.  We pass the
> RFC test vectors, looking for other implementations to test against.

Sorry to dig up an old thread

I tested against Bernstein/ECRYPT ChaCha and test vectors from
http://tools.ietf.org/html/draft-strombergson-chacha-test-vectors.
TLS-ChaCha does not inter-operate with ChaCha.

The name should probably be disambiguated somehow.

Jeff

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

Re: [TLS] no fallbacks please [was: Downgrade protection, fallbacks, and server time]

[Jeffrey Walton]

>> That being said, I would prefer the solution to be a compliance test suite
>> that checks if servers do handle correctly future versions, future
>> extensions and future ciphersuites correctly.
>
> I agree with Hubert. The big question is how you get the bug report to the
> server operator.
>
> With servers which are currently maintained, it should be possible, although
> difficult in specific instances to contact the owner. With servers which
> aren't being maintained, e.g. those in imbedded devices, the problem becomes
> much harder.

There are two ways. First, use the Administrative and Technical
contacts in the WHOIS database. They are ICANN contractual
requirements, and they must be valid. Second, RFC 2142, MAILBOX NAMES
FOR COMMON SERVICES, ROLES AND FUNCTIONS.

Jeff

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

Re: [TLS] Alexey Melnikov's Yes on draft-ietf-tls-chacha20-poly1305-04: (with COMMENT)

[Jeffrey Walton]

On Thu, May 5, 2016 at 10:49 AM, Stephen Farrell
 wrote:
>
> Thanks all. I updated the RFC editor note to add the FIPS
> reference.
>

You might also consider mentioning the interop problems that are going
to occur when diverging from Bernstein's reference implementation. Its
already creating open questions on other mailing lists. For example,
linux-crypto and
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1137554.html:

> + chacha20_block(>state[0], out);
> + if (crng->state[12] == 0)
> + crng->state[13]++;

state[12]++? Or why do you increment the nonce?

Jeff

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

Re: [TLS] Limiting replay time frame of 0-RTT data

[Jeffrey Walton]

>> From the browser side of things, 0-RTT is a solution to a very real
>> problem. We are excited about TLS 1.3 supporting 0-RTT (or 0-RTT resumption)
>> and converting QUIC to use the TLS 1.3 handshake as a result.
>
> ...
> TCP in the works? (does TCPCT work on the client side?). Do you have any
> human perception data; to people even notice the 3% at this point? (loading
> google seems remarkably fast!).  There's a very strong temptation to bias
> for what's easy to measure here.

We also lack statistics on the other costs associated with security
failures. The best I can tell, we have no idea of the impact if its
not in US Financial.

I wrote to the United Nations and Human Rights Watch a while back, and
they don't appear to collect statistics on human rights violations
after incidents like Diginotar.

I can't help but wonder how many folks would agree to controls like
Public Key Pinning with Overrides or 0-RTT if their well being and
their family's well being were at stake.

Jeff

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

Re: [TLS] Limiting replay time frame of 0-RTT data

[Jeffrey Walton]

On Sat, Mar 12, 2016 at 12:45 PM, Karthikeyan Bhargavan
 wrote:
> Hi Kyle,
>
> In my talk at TRON, I was also concerned by potential attacks from allowing
> unlimited replay of 0-RTT data. I recommended that TLS 1.3 servers should
> implement replay protection using a cache, but requiring clients to provide
> a timestamp in the client random is a great idea. Perhaps this would also
> allow TLS 1.3 servers to detect clients whose clocks are too out-of-sync
> with

Be careful here. The whole point of 0-RTT is to start consuming data
before its authenticated to save a few milliseconds in network time.
All those parameters are controlled by the attacker.

We never worried about the extra roundtrip using satellite comms with
0.5 to 1.0 second delays. Additionally, most of my delays in fetching
web pages seems to be delays in Google APIs and servings third party
ads. 0-RTT seems to be a solution looking for a problem.

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

Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?

[Jeffrey Walton]

On Thu, Dec 31, 2015 at 1:23 AM, Alyssa Rowan  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2015-12-31 03:30, Adam Langley wrote:
>
>> I don't mind if the integration of curve25519 in TLS requires a
>> zero-check or not, but what property are people hoping to gain? If
>> one wants to avoid triple-handshake like issues then session-hash
>> is the answer.
>
> (I have a terrible cold, so apologies if I am less than coherent!)
>
> I think I prefer this, of the available options. Specify that:
>
> • Both client and server MUST abort if X25519 and/or X448 are
>   offered/chosen but session_hash is not;
> • Explain why in Security Considerations;
> • Test as part of interop/unit tests?

I think the above sets up a situation where the safer curves are tied
to 0-RTT and friends. I'm pretty sure any configuration under my
purview will *not* have 0-RTT enabled. My servers will *not* be
consuming data before it has been authenticated.

I can only say I'm "pretty sure". I won't know for certain until I
actually step the code under a debugger and see what is being consumed
in the negative cases.

My apologies if I am parsing it incorrectly or going against the grain.

Jeff

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

Re: [TLS] TLS 1.3 - Support for compression to be removed

[Jeffrey Walton]

> I have to wonder if it’s worth it. In the last decade bandwidth has increased 
> and prices for networking have gone down much faster than CPU speeds. 10 
> years ago having 1 Mbps at home was  the highest-end broadband you could get. 
> Now you routinely get 100x that. CPU has increased, but nowhere near that. 
> This makes compression less desirable, to the point that people did not 
> complain much when browser vendors removed compression following the CRIME 
> attacks. True, the rise of mobile brought back limited bandwidth, but is this 
> really an issue?
>
I don't think using bandwidth as a factor is a good idea.

On other lists I still see the occasional quip about suffering a low
bandwidth connection. It used to be folks in some European countries,
but most recently I seem to recall South American. (I think we're
seeing the shift because South American countries are going places
American and Europeans have already been with respect to
infrastructure).

In the rural US, I understand low bandwidth is the norm. Those folks
can't get companies like Verizon or Comcast to service them due to
population density. Its just not profitable for the providers to
update the infrastructure. Also see
https://www.google.com/search?q=rural+us+high+speed+internet.

Ironically, Steve Marquess of the OpenSSL Foundation is one of those
affected by provider's decision based on profitability.

Jeff

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

Re: [TLS] TLS Provfiles (Was: Call for consensus to remove anonymous DH)

[Jeffrey Walton]

>> It's a profile.  Call it what you will.  The rest of us call this a
>> profile.  All the more so when profiles are named in an IANA registry.
>> Applications can then very trivially select an appropriate TLS profile
>> using standard profile naming.
>
> Yeah, we don't need to argue semantics. My point is that I'd agree with a 
> more strict profile than what we have now as an addon, but not a more 
> permissive profile, as was the initial suggestion.

I think it would be wise to acknowledge the "compatibility" use case,
and capture it in a profile. It would be more permissive because it
provides compatibility, like SSLv3.

And because SSLv3 is represented in a down level profile for those who
need it, then it could be removed from standard and more defensive
profiles without much fuss.

For me, its about acknowledging "one size does not fit all" and
managing debates. One size fits all ultimately draws out the process
and weakens things even though its not anyone's agenda.

>> > Let me put it this way, I see no way for the WG to reasonably agree on
>> > this without a proposed _set_ of profiles to go with it that we all
>> > could also live with. Just the vague notion of more profiles in
>> > abstract isn't sounding great on its own.
>>
>> We've certainly had a few proposed profiles over time.  Your estimation
>> of what the WG would or would not agree to is not as interesting as, you
>> know, actually attempting to get consensus.
>
> Agreed, which is why I think this discussion would be more useful with actual 
> specific profiles to talk about. ;)

Right, a concrete list would probably be helpful. The list should
probably be based on use cases.

* Compatibility - down level servers that can't be upgraded, and
clients/UAs that must connect to them
* Embedded - low(er) capability crypto, like CAC/PIV cards, smart
cards and Hotelier Locks, and similar use cases
* Opportunistic - capture email, FTP, etc here. Viktor makes the best
arguments here; defer to him
* Standard - where the working group would like to be in a typical
security posture.
* Defensive - where risk adverse folks would like to be in a defensive
security posture.

Defensive is an interesting profile. I imagine it would include TLS
1.2 and/or 1.3 only, no key transport, authenticated encryption mode
ciphers, no HTTPS Pinning Overrides, etc. Then, auditors in industry
like healthcare or PCI can call it out by name and everyone is on the
same page. The auditors and organizations can worry less about patient
or card holder data being leaked because a user was phished or visited
another organization (that required a configuration change to use the
wireless network).

It might also be wise to use "Standard 2015" because in 3 or 5 years,
its going to be revised. Then there's no confusion when things are
updated an "Standard 2019" becomes available.

Jeff

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

Re: [TLS] DSA support in TLS 1.3.

[Jeffrey Walton]

>> > > Also, if DSA was to be supported, one would need to specify how to
>> > > determine the hash function (use of fixed SHA-1 doesn't fly). And
>> > > 1024-bit prime is too small.
>> >
>> > FIPS186-4
>> > (http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf)
>> > partially remediates the issue. DSA now includes 2048 and 3072
>> > sizes.
>
> It still doesn't say exactly which hash should be used with which sizes.

I believe you are supposed to provide equivalent security levels
across algorithms. If you are honoring NIST's recommendations, then
you can find them in SP 800-57 Part 1, Revision 3
(http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf);
and SP 800-131 A-Rev.1 (Draft)
(http://csrc.nist.gov/publications/drafts/800-131A/sp800-131a_r1_draft.pdf).

ECRYPT, NESSIE, and others provide similar recommendations. We can
probably add the IETF to the list :)

> and unlike RSA, the signature itself doesn't specify it either so hash
> truncation attacks are not impossible
>
>> This is true, but if TLS 1.3 was to specify DSA, it should require the
>> 2048 or 3072 sizes (since 1024 is last century's crypto), and
>> existing implementations do not necessarily support those today.
>
> those sizes are not really interoperable:
> https://bugzilla.redhat.com/show_bug.cgi?id=1238369
> because of the above (GnuTLS takes the conservative approach which is
> incompatible with NSS implementation)
>
>> Which really highlights the question: who would actually use it?
>
> Since 1024 bit is too weak and 2048 bit and 3072 bit is underspecified
> for TLS 1.2 it already isn't recommended for use (which means that the
> biggest deployment of DSA - US Gov - can't really use those bigger
> sizes, and in fact the Common Access Card already transitioned to RSA
> with the change to 2048 bit).

Regarding "who would actually use it": folks in US Federal (and those
doing business in US Federal) don't have the choices that others have.

Jeff

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

Re: [TLS] DSA support in TLS 1.3.

[Jeffrey Walton]

 Also, if DSA was to be supported, one would need to specify how to
 determine the hash function (use of fixed SHA-1 doesn't fly). And
 1024-bit prime is too small.

FIPS186-4 (http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf)
partially remediates the issue. DSA now includes 2048 and 3072 sizes.

Jeff

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