Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1

[Adam Langley]

On Mon, Nov 11, 2019 at 11:33 AM Christopher Wood 
wrote:

> The adoption call is now (belatedly) finished. At this time, there's not
> enough interest to take this on as a WG item. We encourage further
> discussion on the list, perhaps based on subsequent draft updates, and will
> revisit adoption in the future if interest grows.
>

People on this list who manage large corporate networks may wish to pay
attention to this: while you may not have updated servers to TLS 1.3 yet,
eventually it'll happen and I suspect some will find a significant amount
of things like TPMs, in which you currently have client-certificate keys,
which only sign with PKCS#1 v1.5. Without this draft adopted and
implemented ahead of time, it's going to be painful.


Cheers

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

Re: [TLS] TLS Flags extension - not sure it makes sense

[Adam Langley]

On Tue, Jul 23, 2019 at 3:09 PM Chris Inacio  wrote:
> I really want the savings on the wire that TLS flags extension provides – and 
> so I think it’s really good for the future cTLS but I’m not sure when I get 
> to use it in TLS 1.3 negotiation.  It goes in the clientHello message, but 
> how will I know that the server uses this extension?  I envision a future 
> where we will add the flags extension along with the more expensive 4-bytes 
> version for a REALLY long time.

The expectation is that applicable future extensions will be defined
as flags. Therefore, if the server supports the extension that you're
interested in then it'll also have to support the flags extension. If
it doesn't, then the extension will be ignored as normal.


Cheers

AGL

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

Re: [TLS] Question about draft-thomson-tls-sic

[Adam Langley]

On Tue, Jul 23, 2019 at 5:23 PM Watson Ladd  wrote:

> Suppose the following sequence of events happen:
>
> 1: A CA uses a new intermediate for reasons (no longer cross-signing, etc.)
> 2: A site gets a certificate from the new intermediate.
> 3: An older firefox version connects and thinks it knows all the
> certificates in the world.
>
> This would seem to break and it wasn't clear to me how this would be
> handled. Though as Martin points out this extension is merely codification
> of an occasional practice, so maybe this case does actually work out.
>

I think the client would have to fall back and retry the TLS connection
without requesting that intermediates be omitted. In general, I think this
is the only reliable answer as AIA-chasing doesn't always work. (Either the
AIA server can be down, or the chain can be from a private CA that doesn't
support AIA.)


Cheers

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

[TLS] Yet more TLS 1.3 deployment updates

[Adam Langley]

(This is another installment of our experiences with deploying the
RFC-final TLS 1.3—previous messages: [1][2]. We share these with the
community to hopefully avoid other people hitting the same issues.)

In the last update, David reported our experience with a bug[3] in
Java 11's TLS 1.3 implementation. We can confirm that this was fixed
in 11.0.2. However, since then another issue[4] has come to our
attention[8], the fix for which is not in any released version of Java
11. Additionally, we have found a third issue by code inspection which
we'll report on the Java bugtracker.

As such, we continue to fingerprint Java 11 clients on the server and
deny them TLS 1.3. This undercuts TLS 1.3's anti-downgrade measures
and we continue to send a special nonce suffix in that case[2].

Last week we tried sending KeyUpdate messages in Google Chrome, which
went poorly. Several, major OpenSSL-using applications block TLS 1.2
(and prior) renegotiation by installing a callback with OpenSSL and
watching for SSL_CB_HANDSHAKE_START events after the handshake has
completed. Such events are assumed to be renegotiation attempts by a
client and cause the connection to be dropped.

However, OpenSSL 1.1.1a signals SSL_CB_HANDSHAKE_START when TLS 1.3
post-handshake messages are received[5], including KeyUpdate. This
causes KeyUpdate messages to break with, at least, HAProxy, and with
NGINX prior to this commit[6]. (There may well be more, but that level
of breakage was enough to drown any other signal.)

Lastly, OpenSSL 1.1.1a imposes a hard limit of 32 KeyUpdate messages
per connection[7]. Therefore clients that send periodic KeyUpdates
based on elapsed time or transmitted bytes will eventually hit that
limit, which is fatal to the connection.

Therefore KeyUpdate messages are not currently viable on the web, at
least when client initiated.

[1] https://mailarchive.ietf.org/arch/msg/tls/PLtOD4kROZFfNtPKzSoMyIUOzuE
[2] https://mailarchive.ietf.org/arch/msg/tls/pixg5cBXHuwd3MtMIn_xIhWmGGQ
[3] https://bugs.openjdk.java.net/browse/JDK-8211806
[4] https://bugs.openjdk.java.net/browse/JDK-8213202
[5] https://github.com/openssl/openssl/issues/8069
[6] 
https://trac.nginx.org/nginx/changeset/e3ba4026c02d2c1810fd6f2cecf499fc39dde5ee/nginx/src/event/ngx_event_openssl.c
[7] https://github.com/openssl/openssl/issues/8068
[8] https://twitter.com/__subodh/status/1085642001595265024


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] Further TLS 1.3 deployment updates

[Adam Langley]

On Fri, Dec 14, 2018 at 10:50 AM Nico Williams 
wrote:

> If the server rejects resumption I guess the client would still fail,
> but this is much better than failing at 100% of all resumptions and
> better than adding fingerprinting and downgrades.
>

In order for TLS 1.3 deployment to be viable the failure rate needs to be
negligible. It's not feasible to construct things such that moving traffic
across session caching domains causes a wave of handshake failures.
Additionally, if we were to wait for these versions of Java to die out in
the ecosystem, we risk other buggy clients getting established in the mean
time. We are painfully aware that limiting our server-side deployment
allowed this bug to become established and, while we did it to ease
middlebox issues, it may have been a mistake.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Broken browser behaviour with SCADA TLS

[Adam Langley]

On Thu, Jul 5, 2018 at 5:05 AM Peter Gutmann  wrote:
> The crazy thing is that although Chrome rejects a connection to a PFS,
> relatively safe (via the DLP's hardness) 1024-bit DHE server, it's perfectly
> happy connecting to a far less safe (both in terms of factorability and use of
> pure RSA) 1024-bit RSA server.

A 2048-bit minimum for RSA acts via the CA/Browser Forum rules: it
should not be possible to get a publicly-trusted certificate with a <
2048-bit key and, if it happens, we have proportionate measures to
address it.

However, it's not practically possible to fix the small DHE defaults
across all servers and, even if we could, that would have broken many
Java clients. Thus the DHE ecosystem was poisoned and, given that DHE
has been exceeded by ECDHE, it wasn't worth trying to save it.

We have not (at least so far) acted to enforce a 2048-bit RSA minimum
in the client as the CA/BF rules suffice for the vast, vast majority
of users.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

___
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)

[Adam Langley]

On Tue, May 29, 2018 at 6:16 PM Jeffrey Walton  wrote:
> 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).

Chrome / Google is blocked on code-point assignment for deploying
certificate compression. It appears that 26 is not a good pick and we
thus wait in anticipation for a replacement.

(The extensions space is effectively infinite: if we get close to
running out, we can assign an "extended extensions" code point, which
would contain a nested extensions block with 32-bit numbers instead.
Therefore effort and delays resulting from treating it as a scarce
resource are saddening. Speaking in a personal capacity, it looks like
26 is TLS-LTS, maybe 27 for compression? Or else we could assign them
randomly to avoid issues with concurrent applications and I offer
0xbb31 as a high-quality, random number. Since we had a triple
collision in this case, random-assignment's virtues are currently
particularly clear.)

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] early code points assigned (was Re: early code point assignment for draft-ietf-tls-certificate-compression)

[Adam Langley]

On Thu, May 24, 2018 at 9:52 AM Viktor Dukhovni <ietf-d...@dukhovni.org>
wrote:
> It might still be prudent to get the new code point re-assigned.  I
> can see some TLS-LTS stacks also supporting TLS 1.3, with TLS-TLS
> preferred when using TLS 1.2.

It's also been pointed out that 26 collides with the value in
https://tools.ietf.org/html/draft-ietf-quic-tls-12#section-9.2, authored by
Sean :)

So we have a triple collision on 26, albeit with one candidate being much
more official.

Sean: do you want to kick quic_transport_parameters off 26 then? Move it to
a high, random value until assigned?

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] early code points assigned (was Re: early code point assignment for draft-ietf-tls-certificate-compression)

[Adam Langley]

On Wed, May 23, 2018 at 8:23 PM Peter Gutmann <pgut...@cs.auckland.ac.nz>
wrote:
> That's going to cause clashes with implementations that use that value for
> TLS-LTS, it would be better to use a value other than 26 that isn't
already in
> use.

Obviously I'm not adverse to using the occasional, non-IANA code point. But
they need to be picked randomly and outside the dense, IANA area.
Otherwise, this is certain to happen in short order.

I think quite a lot of clients are going to be advertising compression
using this code point in the coming months. They should only do so when
offering TLS 1.3, which presumably LTS clients would not, so maybe there's
something you could use there.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] extended headers for (D)TLS (and their use with connection-id)

[Adam Langley]

On Wed, Jan 24, 2018 at 8:25 AM, Fossati, Thomas (Nokia -
GB/Cambridge, UK) <thomas.foss...@nokia.com> wrote:
> Do you think this is likely to cause havoc?  Or, in your experience,
> middle-boxes tend to not interfere after the TLS channel is up?

I expect so. There was a move, early in TLS 1.3, to drop the
superfluous version in the record header. I think that was reverted
for the same reason, although I don't recall exactly what data that
was based on.

(I'm also assuming that this is much more useful for DTLS than TLS
since you know that each packet will have a record header in it. With
TLS, the kernel might keep retransmitting some part of the
half-connection's data that doesn't include the connection id at all.)


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] extended headers for (D)TLS (and their use with connection-id)

[Adam Langley]

On Wed, Jan 24, 2018 at 6:31 AM, Fossati, Thomas (Nokia -
GB/Cambridge, UK) <thomas.foss...@nokia.com> wrote:
>
> A few months ago, Nikos (can't remember if on this list or on a side
> conversation) came up with this thought of a generic way to extend the
> TLS/DTLS record header.  So, I've stolen his idea and written it up in
> [1] with the intention of using it to make room for the connection-id.

Our experience with middleboxes suggests that this is likely to fault
afoul of many flaws in these products if deployed with TLS on the
wider internet.

DTLS might survive, though, and the cited motivation
(https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-00) is
DTLS-only. Probably this draft needs to be too.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] Additional TLS 1.3 results from Chrome

[Adam Langley]

On Tue, Dec 19, 2017 at 5:07 AM, Stephen Farrell 
wrote:

> I'm not sure I agree renumbering is the right reaction,
> though I don't object to that. This could be a case where
> it's overall better that those specific devices suffer
> breakage, and hopefully then do get firmware updated to
> support TLS1.3 or TLS-without-extended-random-or-dual-ec
> at some point.
>

I think we would like to avoid deliberately breaking these devices with TLS
1.3. (I think TLS 1.3 has been subject to enough friction already.)

If key_share is renumbered, then presumably extension 40 would be reserved
by IANA. Thus other implementations could send extension 40 if they wish
not to interoperate with extended_random-supporting peers.


Cheers

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

Re: [TLS] Update on TLS 1.3 Middlebox Issues

[Adam Langley]

On Sat, Oct 7, 2017 at 12:17 AM, Hanno Böck <ha...@hboeck.de> wrote:
> Alternative proposal:
>
> 1. Identify the responsible vendors.
> 2. Tell all those vendors "You have 1 month to fix this. Fix it. Oh,
> it's your customers who don't update? Seems you don't have any
> reasonable update system. Call your customers, send some support staff
> to them. Fix this. Now."
> 3. Call for a boycott of the vendors who are not able to fix this.

In the past, Chrome has both steam-rollered over intolerance issues
and used "naming and shaming" when it appeared useful.

Naming and shaming can be an effective strategy when there is a small
percentage of aberrant actors, but that doesn't appear to be the case
here. It's not a single vendor, it's several, and we likely don't have
a complete list because it's very difficult to get
vendor/model/version information from the field. These issues vary
across devices, across firmware versions (for which the active range
is large), and across configurations (similarly large).

As for the steam-roller: while /we/ may understand the issues in
sufficient depth to know where the fault lies, the operating heuristic
in IT is that the last thing that changed is to blame. That makes
steam-rollering expensive. Sometimes we do it anyway, but the levels
of breakage measured for the current TLS 1.3 wire-format are too high
to be viable. There would have to be a fallback, and fallbacks are
terrible. We've only recently gotten out of the last lot of them and
should not do that again.

I understand the share the justifiable anger at companies that are
making profits by handicapping the internet that they depend on; we
are paying their externalities right now. But the problem here is too
widespread for either of the above strategies to be effective.

We're still testing, but it appears that a few,
security-inconsequential changes to TLS 1.3 make it significantly more
viable to deploy. That has got to be preferable to behaviours like
fallback, which is very security-consequential. This has taken time
because getting good exposure needs changes to both our frontends and
to Chrome Stable, which makes the iteration time long. We can iterate
much faster with local middleboxes (and we've bought several), but the
diversity of firmware versions and configurations means that we can't
get great testing coverage from that approach.

This looks, overwhelmingly, like the best path for TLS 1.3. For the
future, I think we need to ponder changes in the way that we build and
defend protocols. I think that GREASE
(https://tools.ietf.org/html/draft-ietf-tls-grease-00) demonstrates
the sort of change in thinking that is needed, but that we need to go
further.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] WG adoption call: draft-thomson-tls-record-limit

[Adam Langley]

On Fri, Aug 4, 2017 at 5:50 AM, Sean Turner <s...@sn3rd.com> wrote:

> At our IETF 99 session, there was support in the room to adopt
> draft-thomson-tls-record-limit [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 adoption.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG adoption call: SNI Encryption

[Adam Langley]

On Fri, Aug 4, 2017 at 8:37 PM, Christian Huitema <huit...@huitema.net>
wrote:

> Clearly, Section 2 could be turned into some kind of 'problem statement"
> draft. I personally don't like splitting problem statement and proposed
> solution in separate documents, but if that's the group consensus, why not.
>
I don't think it need be split into a separate document. Indeed, I think
explaining the design space and the reasons for that a specific design was
selected should be welcomed in an RFC.

What makes this document distinct are the sentences like "SNI encryption
designs MUST mitigate this attack." This appears to be constraining /other/
documents by saying that such designs are not merely unattractive (in the
views of the author), but forbidden to be considered.

The IETF does do such policy documents from time-to-time, but not mixed
with a technical document like this in my experience.

> If it wants to be a technical document, then the draft includes two very
> different designs with a note saying that one will be chosen at some point.
> So which are we talking about adopting? While drafts evolve during the WG
> process, there's a big gap between the two ideas and I'd support one but
> not the other.
>
> My goal was to list the current state of solutions. The document could be
> split with different drafts presenting different solutions, but I believe
> there is value in an attempt at unification.
>

Eventually we have to pick one, right? I feel that drafts are generally
more opinionated before a call for adoption, although the chairs might well
feel that the design-space span is this document is focused enough already.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG adoption call: SNI Encryption

[Adam Langley]

On Fri, Aug 4, 2017 at 11:03 AM, Tony Arcieri <basc...@gmail.com> wrote:

> On Fri, Aug 4, 2017 at 10:39 AM, Adam Langley <a...@imperialviolet.org>
> wrote:
>
>> If it wants to be a technical document, then the draft includes two very
>> different designs with a note saying that one will be chosen at some point.
>> So which are we talking about adopting? While drafts evolve during the WG
>> process, there's a big gap between the two ideas and I'd support one but
>> not the other.
>>
>
> The tunneling mechanism described in Section 4.1 seems useful (at least to
> me) for more things than encrypted SNI, such as being able to use different
> TLS extensions for the frontend load balancer versus a backend service,
> while still eventually negotiating an end-to-end encrypted session with the
> backend service.
>
> I wonder if the draft should be framed around the TLS-in-TLS tunneling
> mechanism, with encrypted SNI as a potential use case.
>

But my point is that, in this situation, I would expect there to be two
competing drafts—one for each proposal. The WG would then only adopt one of
them.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG adoption call: SNI Encryption

[Adam Langley]

On Fri, Aug 4, 2017 at 5:50 AM, Sean Turner <s...@sn3rd.com> 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.
>

Section two of the draft discusses the design space, which is to be
welcomed, but also MUST/MUST NOTs sections of that design space. While I
generally agree with its opinions, it's confused about whether it's a
technical document or a policy document. If it decides to be a policy
document, then I'm unconvinced of its utility.

If it wants to be a technical document, then the draft includes two very
different designs with a note saying that one will be chosen at some point.
So which are we talking about adopting? While drafts evolve during the WG
process, there's a big gap between the two ideas and I'd support one but
not the other.

Thus I'm not sure that the draft is ready for an adoption call at this time.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Improved nonce generation method for TLS 1.3

[Adam Langley]

On Fri, Jun 2, 2017 at 3:33 PM, Andrey Jivsov <cry...@brainhub.org> wrote:

> The benefits are that the encryption layer doesn't need to deal with a
> record number or its serialization, or the mask. The state is minimal.
> The nonce update code is faster and smaller (e.g. 3 instructions on
> x86_64).
>
> I would like to thank earlier reviewers. As part of these reviews
> RFC7905 was brought up. I appreciate the desire not to update the
> RFC7905, but this should not interfere with the WGLC, and it's a fairly
> new stream cipher anyway.
>

If the encryption layer implements the standard interface[1] then it
doesn't care about any of this anyway. Also, I'm not sure that it is any
faster (the current scheme can be done in three x86-64 instructions
too[2]), but any difference would be immeasurably tiny compared to the work
of the AEAD itself.

The overriding interest here is to avoid having yet another nonce format.
RFC 7905 diverged from TLS 1.2 with the intent that it would align with TLS
1.3. There would have to be a significant reason to add more complexity.

[1] https://tools.ietf.org/html/rfc5116#section-2.1
[2] context struct addr in rax, seq number in rcx: leaq maskOffset(%rax),
%rbx ; xorq (%rbx), %rcx ; movbeq %rcx, 4(%rdi)


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 Record Layer Format

[Adam Langley]

On Mon, Mar 6, 2017 at 7:55 AM, Ilari Liusvaara
<ilariliusva...@welho.com> wrote:
>> Sorry if I missed information about the outcome of these deployment
>> tests but the current spec version still has the old record layer format.
>
> Yeah, I haven't seen those results either.

We have not yet gotten around to doing those tests and, given the
amount of problems that resulted from a test of TLS 1.3 without any
record-header changes, we are wondering whether it's worth doing those
tests.

(We're not yet ready to share details of the deployment problems that
we have encountered so far, but I hope to do so in the coming weeks.)


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] PSS and TLS 1.3

[Adam Langley]

On Fri, Jan 20, 2017 at 11:29 AM, Brian Smith  wrote:
> RSA PSS with a zero-length salt is a deterministic,
> subliminal-channel-free signature scheme. It is one of the few
> signature schemes that structurally prevent an HSM from directly
> leaking (parts of) the private key in an undetectable way.

Brian's disowned recommendation in the TLS 1.3 draft matches what I
suggest for PSS signatures:

* Salt length is the length of the hash function.
* MGF1 hash function is the same as the message hash function.
* The trailer field has the default value.

(I like Brian's idea, but I hate options, so I'm torn here.)

Certificates that don't match that format are at risk of not working
in Google products because we hate excessive options. (We'll see,
practically speaking, much we have to bend on that point, as always)


Cheers

AGL

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

Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh

[Adam Langley]

On Mon, Jan 2, 2017 at 3:57 PM, Adam Langley <a...@imperialviolet.org> wrote:
> I don't expect that those who want to intercept TLS connections will
> see a MUST NOT and go do something else. Rather I think they should
> understand that TLS isn't supposed to be intercepted and, if they want
> to do that, then they're going to be breaking the spec in places. I
> think they're going to do that no matter what we do so I want to
> ensure that these "interceptable" implementations don't inadvertently
> proliferate. (Because if everything Just Works when you accidentally
> copy such a config to your frontend server, then it'll happen.)

I had understood that the desire from some large institutions to
intercept TLS connections arose only in a datacenter setting. However,
based on private conversations, it appears that at-least one of those
institutions does this on their public frontends and will very likely
do something worse than persistent ECDHE if that's not possible with
TLS 1.3.

Thus the hope that we can detect and reject this configuration by
default, and thus prevent unintended loss of forward security, without
pushing people into implementing interception in a way that's even
worse, appears to be gone.

So I'm disappointingly now thinking that we should simply say that DH
values "SHOULD NOT" be cached for more than 10 seconds. Something like
SSLLabs can still warn when that's violated, but clients probably
cannot enforce it without perverse consequences.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh

[Adam Langley]

On Mon, Jan 2, 2017 at 11:43 AM, Yoav Nir  wrote:
> I’m assuming that the server generates private keys and saves them to a file
> along with the time period that they were used, and another machine in a
> different part of the network records traffic. It’s not so much that the
> clocks need to be accurate, as that they need to be synchronized, and there
> will still be some misalignment because of (variable) latency.
>
> I guess we are making guesses about systems that haven’t been written yet.

Addressing a few messages in one:

I didn't intend that this MUST NOT just be a "MUST NOT (but we know
you will)". I agree they're pretty useless. Rather I want this to be
checked in some clients and in tools like SSLLabs. I have some faith
that such measures will work to push an ecosystem towards correctness.

I don't expect that those who want to intercept TLS connections will
see a MUST NOT and go do something else. Rather I think they should
understand that TLS isn't supposed to be intercepted and, if they want
to do that, then they're going to be breaking the spec in places. I
think they're going to do that no matter what we do so I want to
ensure that these "interceptable" implementations don't inadvertently
proliferate. (Because if everything Just Works when you accidentally
copy such a config to your frontend server, then it'll happen.)


Cheers

AGL

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

Re: [TLS] Requiring that (EC)DHE public values be fresh

[Adam Langley]

a prevalence and we can assume that if
other sites did enable (EC)DHE then they would probably make the same
mistakes at a similar rate. But then I subtracted it from 100 and that
really doesn't make sense.

> Also, the Alexa top 1M isn't representative of every use of TLS, but
> rather only one kind of application.
>
>> Lastly, some have proposed[2] (EC)DH reuse as a mechanism for enabling
>> TLS connections to be decrypted and monitored by a middlebox. TLS is
>> not designed to be decrypted by third-parties—that's kind of the
>> point. Thus anyone doing this should not be surprised to hit a few
>> MUST NOTs and, potentially, to have to configure implementations to
>> allow such a deployment.
>
> The (presumably) accidental reuse of keys for long periods of time is
> bad, and this MitM idea is even worse. But, if reuse were made a MUST
> NOT, wouldn't such systems just use a different, perhaps worse, more
> complex, and undetectable mechanism, like the one Dan Brown suggested
> in the earlier thread? I think we should assume that while we may be
> able to help prevent the former accidental badness with such a rule,
> such a mechanism probably isn't going to have much effect on the
> latter intentional badness.

I much prefer people who are going to backdoor their TLS to use DH as
the mechanism rather than something less detectable. I don't expect a
MUST NOT will slow them down at all. I just want to ensure that this
doesn't accidently carry into 1.3, and that any unofficial backdoor
mechanism needed by some organisations doesn't inadvertently get
enabled more widely than planned.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] cross-domain cache sharing and 0rtt (was: Re: Requiring that (EC)DHE public values be fresh)

[Adam Langley]

On Thu, Dec 29, 2016 at 11:08 AM, Eric Rescorla  wrote:
>> >> As an individual, I'd be in favour of this change but reading
>> >> over [1], section 5, I wondered if we'd analysed the effects of
>> >> 0rtt/replayable-data with that kind of cross-domain re-use in mind?
>> >> The situation being where session ID based caches or session ticket
>> >> equivalents in tls1.3 are shared over multiple domains.

I think there is the following interaction:

Given two servers, S1 and S2, which are nominally s1.example.com and
s2.example.com, but which both have a *.example.com cert and share
ticket keys:

An attacker could redirect a 0-RTT handshake that was destined to S1
and feed it to S2. If S2 ignores the SNI value (common) it could
accept and process the 0-RTT data even though it was destined for S1.

However, in that case TLS 1.2 is probably also affected because S2
would likely process a 1.2 handshake that was destined to S1 as well.
(Even without a shared ticket key or session cache.) See
http://antoine.delignat-lavaud.fr/doc/www15.pdf for more.


Cheers

AGL

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

Re: [TLS] Requiring that (EC)DHE public values be fresh

[Adam Langley]

On Thu, Dec 29, 2016 at 11:28 AM, Martin Rex  wrote:
> First of all, forward secrecy is equally defeated by TLS session caching
> (traditional as well as session tickets), and the effect of rfc5077
> TLS session tickets is likely at least a magnitude worse--and cannot
> be "fixed" by clients purging the tickets earlier.

That is true in TLS 1.2, but one of the things that have been addressed in 1.3.

> Reuse of DHE values should not come as a surprise, PFS with DHE is
> prohibitively expensive with 2048+ bit ephemeral keys.  DHE in TLS has
> been well known to be fatally flawed (publicly known since the issue
> was raised by Yngve on the TLS ietf mailing list in 2007).
>   https://www.ietf.org/mail-archive/web/tls/current/msg01647.html
>
> Since Sun/Oracle hardwired DHE to at most 1024 bits up to JavaSE 7,
> i.e. on Billions on devices out there, DHE in TLS is a very dead horse.

Again, true in 1.2 but 1.3 has fixed the groups to stronger values.
Also, the key-generation of DHE is significantly cheaper than the
key-agreement so ephemeral values might be more reasonable then
benchmarks suggest.

As noted, I think specifying a maximum caching duration is plausible.
(Google servers cache QUIC X25519 values for 60-seconds, for example.)
But I'm worried about an endless discussion about how long is too long
(or long enough).

> Now what does it mean when a _client_ that happens to connect to one
> of these 14.4% Alexa top 1M sites that reuse ECDHE values, notices a
> reuse of ECDHE on a repeated full handshake (which will not happen
> immediately due to session caching).  This would result
> is random handshake failures (client aborting the TLS handshake).
> The server doesn't know why the client chokes, only the client can
> decided to retry, but this is unlikely to affect the servers approach
> to reusing the (EC)DHE value at all.

The idea is to establish this in clients early in the life of 1.3 so
that the pressure is enough to keep the ecosystem clean. I don't think
that enforcing it in versions prior to 1.3 is viable.


Cheers

AGL

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

[TLS] Requiring that (EC)DHE public values be fresh

[Adam Langley]

https://github.com/tlswg/tls13-spec/pull/840 is a pull request that
specifies that (EC)DH values must be fresh for both parties in TLS
1.3.

For clients, this is standard practice (as far as I'm aware) so should
make no difference. For servers, this is not always the case:

Springall, Durumeric & Halderman note[1] that with TLS 1.2:
  ∙ 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do so for more
than a day.
  ∙ 14.4% of the Top 1M reuse ECDHE values, 3.4% for more than a day.

Since this defeats forward security, and is clearly something that
implementations of previous versions have done, this change
specifically calls it out as a MUST NOT. Implementations would then be
free to detect and reject violations of this.

This does have a cost because it also excludes the reasonable practice
of amortising public value generation over all connections for a few
seconds. The draft could attempt to specify a precise, maximum
duration for reuse but that is more complex and no value is clearly
optimal.

Also, this cost doesn't seem too high: 85.6% of servers /don't/ reuse
values and manage fine today. The generation of (EC)DH public values
is also a fixed-based operation and thus can be much faster than DH
key-agreement.

Lastly, some have proposed[2] (EC)DH reuse as a mechanism for enabling
TLS connections to be decrypted and monitored by a middlebox. TLS is
not designed to be decrypted by third-parties—that's kind of the
point. Thus anyone doing this should not be surprised to hit a few
MUST NOTs and, potentially, to have to configure implementations to
allow such a deployment.

[1] “Measuring the Security Harm of TLS Crypto Shortcuts”, IMC 2016,
pages 33–47, section 4.4. https://dl.acm.org/citation.cfm?id=2987480
[2] https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] WG adoption call: draft-davidben-tls-grease

[Adam Langley]

On Thu, Dec 8, 2016 at 10:56 AM, Eric Rescorla <e...@rtfm.com> wrote:

> +1
>

I'm not sure whether I could as an independent voice on this topic, but I
strongly support adoption of this draft.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Adam Langley]

On Fri, Nov 18, 2016 at 7:49 AM, Will Serumgard 
wrote:

> At this point it is a little late to change. I say stay with TLS1.3. As
> some others pointed out maybe we can make a jump in the next version.
>

Renumbering SSL 3.1 as TLS 1.0 was a mistake in the first place, but I
don't believe that changing the version of TLS 1.3 (even if monotonic) will
help at this point. Thus I support keeping TLS 1.3.


Cheers

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

Re: [TLS] draft-ietf-tls-tls13-16

[Adam Langley]

On Wed, Sep 28, 2016 at 9:37 AM, Salz, Rich <rs...@akamai.com> wrote:
> On the crypto-library side, boringSSL had equivalence classes so you could 
> specify that by configuring the CIPHER list. If running in a server, and the 
> configured ciphers were like "[AES:CHACHA]:3DES:RC4" for example, then either 
> AES or ChaCha would be picked.  I don't know if Google servers use that, but 
> I'd be a bit surprised if they didn't.
>
> As for OpenSSL, we need to figure out something.  The "ciphers" syntax is 
> showing its age.

The equal-preference groupings have worked pretty well for us in terms
of making the right thing happen and being understandable to
non-experts. I certainly agree that the ciphers mini-language could do
with some renewal overall.

But I think a lot of the need for it is also going away. We've spent
years worrying about should we do forward security? Do we put RC4
ahead of AES-CBC because of BEAST / POODLE / etc? What about the poor
performance of AES-GCM with Java (for a while)?

But since we've now drastically reduced the number of options, and
those options are (fingers crossed) less shitty than before, I'd hope
that a default would work for the vast majority of TLS 1.3 users.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] KeyUpdate and unbounded write obligations

[Adam Langley]

On Sun, Aug 28, 2016 at 11:50 AM, Eric Rescorla <e...@rtfm.com> wrote:
> Yes, I agree separate ladders would fix this. I don't necessarily object to
> this
> change, but I'm not sure it's that big a deal either, because you really
> only get
> into this case when there's a big asymmetry in sending rate, so much that
> one side wants to send multiple updates before the other side has sent
> any data at all.

I think that cases where there's a big asymmetry in sending rates are
in the majority.

> Note: it's also possible to avoid the rollback problem with the existing
> single-ladder system: when you send a key update you compute:
>
> traffic_secret_N+1
> read_key_N+1
> write_key_N+1
>
> You then discard traffic_secret N, write_key_N, but key read_key_N, so if
> you
> are M updates ahead of the other side, you have M read keys outstanding,
> but these cannot be used to produce the write keys. However, this probably
> isn't simpler than just running two ladders if we think this is important.

That works but I agree that splitting the ladders is nicer and I think
that we should do that.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] KeyUpdate and unbounded write obligations

[Adam Langley]

On Thu, Aug 18, 2016 at 5:18 PM, Keith Winstein <kei...@cs.stanford.edu>
wrote:

> Yeah, our reasoning follows yours and goes a little further:
>
> 4) I don't know when I'm going to wake up again.
> 5) I don't want a subsequent compromise of me *or* the other side to
> reveal prior plaintext from the session.
> 6) Because I'm going to sleep, it's now or never to make sure the
> session keys aren't retained.
> 7) Therefore, I'd like to make sure both sides have ratcheted forwards
> before I go to sleep.
>

I don't think that a device can ensure that the other side doesn't get
compromised. Even if it rotates keys, there are plenty of ways that a well
meaning implementation could fail to erase them: copying GCs, swap,
hibernation, coldboots, even hypervisor tricks like moving VMs between
machines.

And I don't think the device can ensure that the keys that it writes to
flash aren't used to protect sensitive data without application-level
support. Consider a device that does a KeyUpdate and gets a KeyUpdate in
reply before sleeping. However, just after echoing the KeyUpdate, the other
side says "oh, and by the way, here are the battle plans...". Those plans
would be encrypted with keys that the device just wrote to flash. So there
has to be an application-level concept of "we're rotating keys now because
I'm going to sleep. These keys are only for authenticating another
KeyUpdate when I wake, don't send me anything." Once you have an
application-level concept like that then you don't need an special
KeyUpdate ack system at the TLS level because the KeyUpdate messages are
sequenced with the application data already.

Probably nothing that elaborate.
>
> The device is concerned that after the session is over (from its
> perspective), the server might get compromised, and the attacker reads
> the key for a long-dormant session out of the server's /dev/mem, and
> uses it to decrypt prior ciphertext.
>
> One approach is that the device should make sure to close every
> session with a secure bidirectional close, where the server actually
> confirms that the session is dead in both directions. But TLS does not
> have a secure bidirectional close. (Even when used, close_notify only
> promises there will be no more data in *that* direction.)
>
> However, the device can try to guarantee that both sides have
> ratcheted past all the keys that could reveal prior plaintext.
>

So you're worried that the server might not notice that a device has closed
a connection and so keep the keys in memory? Why didn't it notice? Because
an attacker cut the communication? If so, couldn't the attacker cut
communication just before the KeyUpdate and achieve the same thing?

Or are you assuming that we can't trust an implementation to erase keys
when a connection closes, but it will erase them for a KeyUpdate or a
bidirectional close? If so, I don't see why that's clearly true. It could
be true in practice, but I suspect that many implementations will do the
same thing in both cases. (And that, even if they try, they might not be
able to securely erase the keys because of swapping etc.)

The confirmation is the way for the device to know that the server has
> read its request to ratchet the client-to-server traffic key forwards.
> (And the idea would be, if the device doesn't get that confirmation
> and really wants it, it may have to raise a warning and handle this at
> the application layer -- e.g. by opening a new session to the server
> and issuing a "kill all sessions" command.)


That suggests that you're worried about an active attacker cutting
communications. But why would such an attacker let you open a new session?

> If they have a channel to the user where they are sending a stream of old
> > keys, couldn't they just mirror the plaintext of the connection to keep
> > things simple? I guess you worry about a device that's cooperative
> enough to
> > put in the effort to have their audit channel but lies about the
> plaintext?
>
> Right, exactly. (Ideally, the device doesn't even know it's being
> audited until the user logs in to the Web UI and says, "okay, now,
> ratchet the session and then share the old keys with this auditor that
> I am going to introduce you to, so it can decrypt some earlier
> ciphertext I've been capturing." So we don't want a parallel channel
> and we don't even want the device to have to know about the audit
> beforehand.)
>

I think that this is the most interesting case. I would like to think that
IoTish devices would care this much about doing the right thing, although I
suspect we're more likely to get more fodder for Matthew Garrett (
https://mjg59.dreamwidth.org/43486.html).

I would still tend towards not including the generation because I don't
believe that it's

Re: [TLS] Keeping TLS extension points working

[Adam Langley]

On Wed, Jul 27, 2016 at 9:50 AM, Wan-Teh Chang <w...@google.com> wrote:
> Another source of interop failures is the firewall devices that do
> anomaly detection. Some of them will abort TLS handshakes if they see
> unknown TLS protocol versions or extensions in ClientHello. (They all
> seem to allow unknown cipher suite values.) I suspect they will treat
> the GREASE cipher suite, extension, and named group values as "normal"
> and continue to abort the handshake if they see truly new values. I
> can only hope that these network security devices are updated
> regularly.

Sadly there's very little that we can do to address aggressively bad
devices. None the less, there are several instances of unintentional
bugs in implementations that have caused problems with new-feature
deployment that I believe could have been caught with this proposal.
As ever, bugs are much less costly when found earlier and I believe
that applies equally to the developer and the world as a whole.

I have mind the cases of extension intolerance that we've thankfully
mostly managed to drive out now (because new extensions have been
added for other reasons) and the bug that led to the padding extension
(RFC 7685).

On the other hand, we've seen what's happened to the version field,
which is moving too slowly to resist rusting.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2?

[Adam Langley]

On Wed, Mar 16, 2016 at 6:14 PM, Paterson, Kenny
 wrote:
>>provokes me to bring it up. Here's the crux of it; is it really a
>>security win to recommend the AEAD cipher suites for TLS 1.2 users?

I'm skeptical about the benefit of padding to 16 bytes. While it does
increase the size classes in your Wikipedia example, Wikipedia pages
trigger subresource loads, which also have a size and page-to-page
navigation leaks more information. My takeaway from reading
traffic-analysis papers over the years is that countermeasures are
surprisingly difficult.

On the other hand, the CBC cipher suites are fundamentally broken,
rather slow and, in an attempt to fix them, are now very complex. So I
don't believe that the benefits of padding to 16 bytes comes close to
justifying the use of the CBC modes. Over the coming years I hope that
CBC modes are killed off in the same fashion that RC4 now has been in
several browsers.

Padding at the application-level (e.g. HTTP) is probably the easiest,
reasonable place to add padding (if there's a scheme with solid
justification). Sure, one doesn't get "automatic" padding that using
CBC modes might (somewhat) get you, but I still don't think CBC is a
good tradeoff.


Cheers

AGL

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

Re: [TLS] Accepting that other SNI name types will never work.

[Adam Langley]

On Thu, Mar 3, 2016 at 10:56 AM, Eric Rescorla <e...@rtfm.com> wrote:
> Note: it's already the case that it's forbidden to send >1 of any given type
> of name. NSS does not presently enforce this rule but will do so soon.

(We have enforced that for a while without issues.)


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

[TLS] Accepting that other SNI name types will never work.

[Adam Langley]

The Server Name Indication (SNI) extension in TLS has a provision to
provide names other than host names[1]. None have even been defined to
my knowledge, but it's there.

OpenSSL (and possibly others) have had a long-standing bug[2] (fixed
in master) that means that different types of names will cause an
error. To be clear: I live in a glass house and am not throwing
stones; these things happen. However, it means that a huge fraction of
the TLS deployment will not be able to accept a different name type
should one ever be defined. (This issue might have been caused by the
fact that the original[3] spec didn't define the extension in such a
way that unknown name types could be skipped over.)

Therefore we (i.e. BoringSSL, and thus Google) are proposing to give
up on this and implement our parser such that the SNI extension is
only allowed to contain a single host name value. (This is compatible
with all known clients.) We're assuming that since this is already the
de-facto reality that there will be little objection. I'm sending this
mostly to record the fact so that, if someone tries to define a new
name type in the future, they won't waste their time.

If the community wishes to indicate a different type of name in the
future, a new extension can be defined. This is already effectively
the case because we wouldn't fight this level of incompatibility when
there's any other option.

(I think the lesson here is that protocols should have a single joint,
and that it should be kept well oiled. For TLS, that means that
extensions should have minimal extensionality in themselves and that
we should generally rely on the main extensions mechanism for these
sorts of things.)

[1] https://tools.ietf.org/html/rfc6066#section-3
[2] 
https://github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/ssl/t1_lib.c#L1066
– note that the data pointer is not updated.
[3] https://tools.ietf.org/html/rfc4366#section-3.1


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] Remove 0-RTT client auth

[Adam Langley]

On Sun, Feb 21, 2016 at 11:31 AM, Martin Thomson
<martin.thom...@gmail.com> wrote:
> I'm sitting here in TRON listening to Karthik describe all the various
> ways in which client authentication in 0-RTT is bad.  I'm particularly
> sympathetic to the perpetual impersonation attack that arises when the
> client's ephemeral key is compromised.
>
> We originally thought that we might want to do this for
> WebRTC/real-time.  As it so happens, we have an alternative design
> that doesn't need this, so...
>
> I propose that we remove client authentication from 0-RTT.
>
> This should simplify the protocol considerably.

The token-binding(*) folks care about authenticating 0-RTT requests,
although they are currently working at the application-layer[1] and so
would be recreating 0-RTT client authentication on top of TLS. (They
would thus have all the same issues, but we already knew that.)

If there was still a channel-binding value available at 0-RTT time,
they should be happy.

(* To recap, token-binding wants to eliminate the bearer-token nature
of cookies in order to avoid several issues. For example,
Heartbleed-like leaks of cookie data, origin confusion attacks[2]
etc.)


Cheers

AGL

[1] https://tools.ietf.org/html/draft-ietf-tokbind-protocol-04
[2] http://antoine.delignat-lavaud.fr/doc/www15.pdf

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] Require deterministic ECDSA

[Adam Langley]

On Sat, Jan 23, 2016 at 9:20 PM, Brian Smith <br...@briansmith.org> wrote:
>> I'd like to propose that TLS1.3 mandates RFC6979 deterministic ECDSA.
>
> What about the way BoringSSL (and OpenSSL, I think) does it? It incorporates
> all the inputs that RFC6979 does, but using SHA-512 instead of HMAC. And, it
> also includes a random element in the SHA-512 hash.
>
> Ed25519 uses SHA-512 instead of HMAC for the same purpose and people seem to
> think it works fine.
>
> Also hashing in some randomness seems like it would help avoid some side
> channel leakage. Note that most (all the ones I've looked at for more than 5
> minutes) open-source ECDSA implementations have side-channel issues of
> various levels of significance.
>
> Anyway, I do think that implementations should do something *like this* to
> avoid problems when the RNG is bad, but I think prescribing RFC 6979 as the
> solution is overly-specific, especially when it doesn't even seem to be the
> best way to accomplish the goal in many cases.

I wrote that design before RFC6979 (or, at least, before I was aware
of it). The reason that I included randomness into the mix was because
I worried that someone might be depending on the randomised nature of
ECDSA signatures and suddenly making them deterministic seemed like a
risky thing to do. That's not a problem in TLS.

I think that those implementations that care about DPA-level
side-channel attacks will probably do their thing no matter what the
standard says, so I wouldn't have an objection to putting a "SHOULD"
in the spec for RFC 6979. I suspect that adherence would be poor,
however. As for using that RFC over what I came up with or anything
else: at least RFC 6979 has been written down already.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

___
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?

[Adam Langley]

On Wed, Dec 30, 2015 at 4:03 PM, Brian Smith  wrote:

> I think it is a good idea to implement the session hash extension, in
> general. However, I think it is a bad idea to prescribe it as the solution
> for this particular problem because:
>
> 1. draft-irtf-cfrg-curves-11, in sections 6.1 and section 6.2 already
> require the check for a non-zero result, and that check is sufficient.

As discussed on the CFRG list, the plan is that the final curves RFC
will say that the zero check is a MAY. (See
https://www.ietf.org/mail-archive/web/cfrg/current/msg07611.html)

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. A client can use an RSA key exchange to control the PMS
completely, of course, and, with finite-field DH, a value of zero or
p-1 will usually allow the same.


Cheers

AGL

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

Re: [TLS] draft-ietf-tls-curve25519-01 and the X25519 significant bit.

[Adam Langley]

On Tue, Dec 22, 2015 at 3:15 PM, Brian Smith <br...@briansmith.org> wrote:
> I agree with all of that in principle. In fact, I think that most of section
> 2.3 should be removed in deference to the CFRG document, and only
> TLS-specific concerns should be given.
>
> I still think there is value in requiring senders to send their public value
> in the "normalized" form and for allowing (if not requiring) receivers to
> reject, at least, public values >= q, for the reasons I gave in my previous
> email. Ideally that would happen in the CFRG document. But, what is the
> status of the CFRG document? I've heard that it's past the point where
> changes will be accepted.

The CFRG document is in AUTH48 right now so, indeed, it's probably too
late for that sort of change.

To give some background about why the CFRG document ended up the way it did:

The curve25519 paper only mentions the extra bit to say: "Note that
Curve25519 is not surjective: in particular, its final output bit is
always 0 and need not be transmitted." [1]. It didn't specify whether
it should be ignored or not and implementations started to differ on
that point. Also, in order to keep the code simple, it didn't check
for values >= 2^255-19. Both because that could be more code in the
primitive itself, and because it would mean that the function would
change from being total to partial.

Some years ago, there was a small effort to align the different
implementations around the same behaviour and ignoring the bit was
chosen. I think that decision probably arose from changing the fewest
things and also the thought that people might want to use the extra
bit as a sign bit in the future.

No implementations rejected values >= 2^255-19 from what I recall.

Since the CFRG has standardised Curve25519, in practice the existing
implementations will seed the implementation ecosystem. Changing
something really subtle like the extra bit behaviour, or rejecting
oversized values, without a clear need, doesn't seem to me to be
worthwhile (or, perhaps, even achievable for a spec).

So at this point I'd like to nail down the existing behaviour with
tests, try to make it uniform across most implementations, and try to
avoid other specs interpreting the byte strings.

[1] http://cr.yp.to/ecdh/curve25519-20060209.pdf


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] draft-ietf-tls-curve25519-01 and the X25519 significant bit.

[Adam Langley]

On Tue, Dec 22, 2015 at 1:36 PM, Brian Smith <br...@briansmith.org> wrote:
> First, maybe I'm overlooking something obvious, but I'm not seeing it: Why
> are we concerned only with whether the high bit has been set, instead of
> whether the public value has been reduced mod q (q == 2^255-19)? Aren't
> there ~19 interesting values that don't have the high bit set but which are
> also relevant to this issue?

You're correct, but I'm trying to say that the CFRG document defines a
function that operates on bytestrings so that higher-level protocols
don't have to worry about things like this. I think TLS should handle
the byte strings opaquely so that we have uniform behaviour for
X25519/X448 and only a single place where it needs to be tested. The
behaviour of X25519/X448 for non-reduced values is also specified in
the CFRG document.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] PRF digest function for ChaCha20-Poly1305 cipher suites

[Adam Langley]

On Fri, Dec 18, 2015 at 1:43 PM, Brian Smith <br...@briansmith.org> wrote:
>> The recent renaming of the ChaCha20-Poly1305 cipher suites brought
>> something to my attention that I hadn't thought about before. It seems like
>> it might be better to use HKDF-SHA512 instead of HKDF-SHA512, and
>
>
> That is, it seems it would be better to use HKDF-SHA512 instead of
> **HKDF-SHA256**.

I assume that you mean for TLS 1.3 since you mention HKDF? I updated
the draft recently because David Benjamin noted that the names didn't
include the PRF (which they should these days) and that OpenSSL, at
least, used SHA-256, so might as well make the spec match reality.

So, the current code points are probably SHA-256 now. I don't object
to adding more if people want SHA-384 too. Although, since the hash
function is only used in key derivation with these cipher suites, I'm
not sure that a slower, software implementation of SHA-256 would be a
big problem.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] Early code point assignment request for curve25519 and curve448

[Adam Langley]

On Sat, Nov 14, 2015 at 10:44 AM, Viktor Dukhovni
<ietf-d...@dukhovni.org> wrote:
> AFAIK the signature detailes are not pinned down yet.  Is this
> allocation in anticipation of the final details?

It might well be that the X25519 and X448 code points are suitable for
early assignment while the signature code points are not since the
signature work in CFRG is ongoing. I'll leave that to the chairs.

(While we would use early code-point assignments for X25519/X448 we
don't have plans for using the signature code points at this time.)


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] Review of https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-00

[Adam Langley]

On Thu, Nov 12, 2015 at 10:06 AM, Martin Thomson
<martin.thom...@gmail.com> wrote:
> This is good.
>
> I have an editorial comment: can someone please go through and
> reconcile all the use of bits and bytes throughout.  It actually seems
> like someone did a coin flip on every occurrence to decide which one
> to use.

-01 already has some cleanups.

But there's inevitably going to be some use of both bits and bytes in
a draft such as this since keys are generally measured in bits but
wire protocols are generally measured in bytes. I looked over each use
of "bit" and "byte" in -01 and changed one key length to bits, but
otherwise I think each use is about right.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] Application data during renegotiation handshake

[Adam Langley]

On Wed, Nov 11, 2015 at 10:39 AM, Mike Bishop
<michael.bis...@microsoft.com> wrote:
> Since HTTP/1.1 only has one request per connection and that request is
> waiting on the client certificate to be retrieved via renegotiation, you can
> assume that the client will not send any application data between the new
> ClientHello and sending the Finished message.  (“…it is expected that the
> negotiation will begin before no more than a few records are received from
> the client.”)  Likewise, the server will not emit any application data
> between sending the HelloRequest and sending its own Finished message.
> Since HTTP/2 will have other requests being generated and served in
> parallel, this is no longer the case.  Per the TLS 1.2 spec, that’s
> permitted, but if it’s not been done before, I’m afraid we may be hitting
> less-tested code paths.
>
> I know that BoringSSL explicitly requires that application data flow be
> stopped during renegotiation.  If the HTTP working group adopts this draft,
> do the owners of other TLS implementations expect this to require changes in
> their TLS 1.2 implementations?

Chrome, Android WebView etc treat a HelloRequest when HTTP/2 has been
negotiated as a fatal error. We do not expect to change this.

The TLS 1.3 post-handshake client-auth was intended, as I recall, to
support HTTP/1.1 over TLS 1.3.

With HTTP/2 isn't it cleaner to do client-auth at the HTTP layer (i.e.
by signing exporter values)? SPDY, at one point of development,
supported this via the CREDENTIAL frame. That also avoided a confused
deputy problem: with connection pooling over HTTP/2, there seems to be
a risk of confusion about which requests are authenticated with which
client certificate.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-01.txt

[Adam Langley]

On Tue, Nov 3, 2015 at 8:25 AM, Benjamin Kaduk <bka...@akamai.com> wrote:
> %   1.  The 64-bit record sequence number is serialized as an 8-byte,
> %   big-endian value and padded on the left with 4 zeroes.
>
> I assume you mean zero octets/bytes, and not ASCII '0' (or EBCDIC, or ...)
>
> "padded on the left" also has some potential for ambiguity (though not as 
> much); something about "four zero octets are prepended to the stream" might 
> be less ambiguous.

Sorry, I missed seeing this for -02, but I now have locally, for the
next revision:

"The 64-bit record sequence number is serialized as an 8-byte,
big-endian value and padded on the left with four 0x00 bytes."


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] Version in record MAC

[Adam Langley]

On Tue, Oct 27, 2015 at 8:56 AM, Eric Rescorla <e...@rtfm.com> wrote:
> Yes, that's correct. But we could relax that restriction and make those work
> if we wanted...

Explicit nonces should not be used in TLS. I'm happy to be building
things without them in mind.

SIV modes, if turned into AEADs, would have to authenticate their
nonces internally. RFC 5297 basically says that already
(https://tools.ietf.org/html/rfc5297#section-3). That might mean that
the nonce is prepended to the AD inside the AEAD abstraction, but that
wouldn't be TLS's concern.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] Version in record MAC

[Adam Langley]

On Monday, October 19, 2015, Martin Thomson <martin.thom...@gmail.com>
wrote:

> On 19 October 2015 at 11:17, Eric Rescorla <e...@rtfm.com <javascript:;>>
> wrote:
> > Yeah, I think that's riding the nonce far too hard.
>
> On what basis?  Any change in the nonce will cause the record
> decryption to fail.  That's the property we're looking for here, isn't
> it?


I don't believe that there's any reason to include the sequence number in
the AD input of an AEAD. I think that an empty AD for TLS would be fine now
that the content type is encrypted. (Not that I deeply care either way.)


Cheers

AGL


-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] '15 TLS Fall Interim Minutes

[Adam Langley]

On Wed, Sep 23, 2015 at 3:54 AM, Ilari Liusvaara
<ilari.liusva...@elisanet.fi> wrote:
> One thing to note: The time is 4 octets, and 32 bit time since unix
> epoch runs out a good bit faster than what I would like.

It's an unsigned value so it stretches until 2106 rather than the
standard epoch rollover at least.

>> investigate: using the same construct for server/client sigs.
>
> Huh? Don't both currently use the same construct, except for the
> context string? Are you proposing to remove the context string or
> what?

The on-the-fly client auth messages were envisioned to sign the
certificate and a TLS Exporter value. That point was reflecting a
desire to have the handshake signatures sign the same thing if that
makes sense.

>> 4. We agreed to not allow unsolicited client auth.
>
> What will browser using HTTP/2 do if it receives client reauth request
> when it has stream blocking identity change open?
>
> - Open new connection and ??? to elict certificate request.
> - Reset all streams that block identity change and then change identity.
> - Reset all streams, change identity and retry request.
> - Kill connection (e.g. PROTOCOL_ERROR).
>
> (Just changing the identity is known to be insecure.)

"Unsolicited" means that the TLS server never sent an on-the-fly
CertificateRequest.

So the HTTP/2 situation would involve the server sending a
CertificateRequest which includes an opaque identifier. The
application protocol is free to decide that that identifier means and
HTTP/2 can decide that it's the stream id of the request that
triggered the need for a certificate. The client returns a certificate
(empty or not) and, in the mean time, the connection can continue
flowing. (And other CertificateRequests can be sent while one is
outstanding.)

>> 6. We want a consolidated certificate message and certificate verify.
>
> Just be careful that certificate is still signed, as many signature
> algorithms fail to even properly bind the key, and nothing binds the
> certificate.

Yes, that's understood.

> Parse error. Does this mean something like "how much data current
> ciphers can safely encrypt"?

Yes.

> Huh? This is about collisions between different hash algorithms. I
> don't see how contributory behavior would help there (which is severly
> limited by 1RTT maximum there).

I think we quite possibly didn't understand the concern here. Could
you spell it out at more length?


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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

Re: [TLS] sect571r1

[Adam Langley]

On Wed, Jul 15, 2015 at 1:58 PM, Deirdre Connolly
durumcrustu...@gmail.com wrote:

 So, should it stay or should it go now? Opinions?

 +1 that sect571r1 be removed.

I also believe that it should be removed.


Cheers

AGL

-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org

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