Re: [TLS] The case for a single stream of data

[Benjamin Kaduk]

As Ilari says, there's a lot of stuff in here.  I'll put some thoughts
here at the top, and more inline.

First off, it seems somewhat self-evident that if we guarantee 0-RTT
non-replay, then of course it makes sense to just concatenate the
streams.  That is, if 0-RTT data is not replayable, there's not much
special about it to merit separating it off from normal application
data.  This isn't quite exactly true because of the DKG attack, but it
may be close enough to not matter.

However, I'm still not convinced that requiring strong 0-RTT non-replay
is feasible/the right thing to do.  So, I do not consider the question
of single stream vs. block-of-early-data + 1-RTT stream to be settled.

On 05/05/2017 11:28 AM, Colm MacCárthaigh wrote:
>
> I wanted to start a separate thread on this, just to make some small
> aspects of replay mitigating clear, because I'd like to make a case
> for TLS providing a single-stream, which is what people seem to be
> doing anyway. 
>
> Let's look at the DKG attack. There are two forms of the attack, one
> is as follows:
>
> "Client sends a request with a 0-RTT section. The attacker lets the
> server receive it, but suppresses the server responses, so the client
> downgrades and retries as a 1-RTT request over a new connection.
> Repeating the request". 
>

Does the client always downgrade?  We don't require it to do so, in TLS
1.3, though of course browsers would.

> In this case, server-side signaling such as the X-header trick doesn't
> work at all. But thankfully this attack is equivalent to an ordinary
> socket interference attack. E.g. if an attacker today suppressed a
> server response to a HTTP request, then the client will do its retry
> logic. It's the same, and I think everything is compatible with
> today's behavior.
>
> Next is the more interesting form of the attack:
>
> "Client sends a request with a 0-RTT section. For some reason the
> server can't reach the strike register or single use cache, and falls
> back to 1-RTT. Server accepts the request over 1-RTT.  Then a short
> time later, the attacker replays the original 0-RTT section."
>
> In this case, server side signaling to the application (such as the
> neat X- header trick) also doesn't work, and is not backwards
> compatible or secure by default. It doesn't work because the server
> application can't be made idempotent from "outside" the application,
> so any signaling is insufficient, and is equivalent to the
> Exactly-Once message delivery problem in distributed systems. Since a
> request might be retried as in case 1, it needs an application-level
> idempotency key, or a delay-and-retry strategy (but replay will break
> this). There's some detail on all this in the review. End result is
> that a server-side application that was never designed to reach
> duplicates may suddenly be getting exactly one duplicate (that's all
> the attack allows, if servers reject duplicate 0-RTT). 
>

I feel like many applications that use delay-and-retry will see this and
conclude that they should just not attempt to use 0-RTT.

> What is actually needed here, I think, is client-side signaling.
> Careful clients need to be made aware of the original 0-RTT failure. 
>
> So for example, an SDK that writes to an eventually consistent data
> store may treat any 0-RTT failure as a hard failure, and *not* proceed
> to sending the request over 1-RTT. Instead it

Right; nothing *requires* the client to retry failed 0-RTT as 1-RTT; the
application can decide it's willing to take the risk or use some other
strategy.  But I'm not convinced that the TLS stack needs to decide on
its own, without application input.

> might wait its retry period, do a poll, and only then retry the
> request. If the TLS implementation signals the original  0-RTT failure
> to the client, as if it were a connection error, everything is
> backwards compatible again. Well mostly; to be properly defensive, the
> client's retry time or polling interval needs to be greater than the
> potential replay window, because only then can it reason about whether
> the original request succeeded or not. If there is a strict maximum
> replay window, then this behavior is enforceable in a TLS
> implementation: by delaying the original failure notification to the
> client application by that amount. 
>

And if there is not a strict replay window defined in the spec, then the
client must have some way of knowing what window the server is using,
etc., etc..  When I added the 10-second guidance that's currently in
there, I explicitly wanted something concrete, but was not willing to
claim that I knew enough about all possible ways in which TLS can be
deployed to make a normative requirement for all users of the protocol. 
I don't think that's changed; setting a fixed global limit seems to be
asking for trouble.  I suppose if we really needed to we could stick it
in a NST extension, but I don't think we really need to.

> Of course browsers won't do this, and that's ok. 

Re: [TLS] "Encrypted" SNI

[Daniel Kahn Gillmor]

On Wed 2017-05-10 12:12:34 -0700, Christian Huitema wrote:
> It certainly was. But then the clear text SNI is a gaping privacy hole
> in TLS, the kind of issue that should keep us awake at night until it is
> resolved. We need to make sure that we make progress, rather than rehash
> the old arguments. Maybe we should invest some time and document the
> various proposals in a draft. I am willing to work on that. Any other
> volunteers?

I agree with Christian's assessment of the problem, and i'd be
interested in collaborating on such a draft.

The DNS folks are making strides to protect name information (the other
main place where this kind of data is leaking).  TLS needs to keep up.

--dkg

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

Re: [TLS] "Encrypted" SNI

[Roland Zink]

Not necessarily as you may for example use the path part of a URL to 
distinguish between services.



Roland




Am 10.05.2017 um 23:50 schrieb Christian Huitema:


On 5/10/2017 2:40 PM, Roland Zink wrote:

The SNI extension is optional, so you don't have to send the literal
value. Indeed quite some number of apps do not send it. Browsers
currently can't know if the SNI is required by the origin servers and
usually send this, but there could be some signal to not send it. One
example could be a HTTP header to tell the browser that SNI should be
send and if it isn't present then no SNI is send. Unfortunately this
would break current sites but still it can be done the other way
around e.g. send a header to not send SNI.

Yes. But this is only possible when each service has a separate IP
address. The privacy gain occurs precisely when several services share
the same address, but that's exactly when the SNI is required. If the
SNI was somehow encrypted, adversaries would not be able to use it to
find which service the user is connecting to.

-- Christian Huitema



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

Re: [TLS] "Encrypted" SNI

[Christian Huitema]

On 5/10/2017 2:40 PM, Roland Zink wrote:
> The SNI extension is optional, so you don't have to send the literal
> value. Indeed quite some number of apps do not send it. Browsers
> currently can't know if the SNI is required by the origin servers and
> usually send this, but there could be some signal to not send it. One
> example could be a HTTP header to tell the browser that SNI should be
> send and if it isn't present then no SNI is send. Unfortunately this
> would break current sites but still it can be done the other way
> around e.g. send a header to not send SNI.

Yes. But this is only possible when each service has a separate IP
address. The privacy gain occurs precisely when several services share
the same address, but that's exactly when the SNI is required. If the
SNI was somehow encrypted, adversaries would not be able to use it to
find which service the user is connecting to.

-- Christian Huitema

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

Re: [TLS] "Encrypted" SNI

[Roland Zink]

The SNI extension is optional, so you don't have to send the literal 
value. Indeed quite some number of apps do not send it. Browsers 
currently can't know if the SNI is required by the origin servers and 
usually send this, but there could be some signal to not send it. One 
example could be a HTTP header to tell the browser that SNI should be 
send and if it isn't present then no SNI is send. Unfortunately this 
would break current sites but still it can be done the other way around 
e.g. send a header to not send SNI.


Regards,

Roland


Am 10.05.2017 um 19:28 schrieb Hubert Kario:

Yes, encrypted SNI was discussed and ultimately rejected.

But do we really have to send the literal value? Don't we need to just make
sure that the client and server agree on the host that the client wants to
connect?

Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending
the salt and the resulting hash, making the server calculate the same hash
with each of the virtual host names it supports and comparing with the client
provided value?

(apologies if that was already proposed and rejected)


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


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

Re: [TLS] "Encrypted" SNI

[Ilari Liusvaara]

On Wed, May 10, 2017 at 07:28:51PM +0200, Hubert Kario wrote:
> Yes, encrypted SNI was discussed and ultimately rejected.
> 
> But do we really have to send the literal value? Don't we need to just make 
> sure that the client and server agree on the host that the client wants to 
> connect?
> 
> Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending 
> the salt and the resulting hash, making the server calculate the same hash 
> with each of the virtual host names it supports and comparing with the client 
> provided value?

What makes encrypting SNI nasty is replay attacks.

There also was proposal for putting SNI mapping into DNS (which limits the
leakage if DNS lookups are private). However, I came up with a way to use
that to attack HTTPS (the usual "default vhost" attacks).


-Ilari

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

Re: [TLS] "Encrypted" SNI

[Benjamin Kaduk]

On 05/10/2017 02:12 PM, Christian Huitema wrote:
>
> On 5/10/2017 12:04 PM, Viktor Dukhovni wrote:
>>> On May 10, 2017, at 2:47 PM, Hubert Kario  wrote:
>>>
>>> But in general, I wonder if we didn't approach the SNI from the wrong side 
>>> - 
>>> as I said, we may not need to encrypt it, we just make sure that client and 
>>> server agree on the virtual host the connection is going to.
>> They can do that with a name in the clear.  If the name is to be hidden
>> from passive observers, then you do need encryption so that only the
>> client and server, and not the passive observers, can recover the name.
>>
>> Encryption means key agreement, and requires delaying SNI by a round-trip,
>> or having published DH shares in DNS, which of course also needs privacy
>> protection for SNI encryption to matter.
>>
>> I do believe this was discussed at some length previously.
> It certainly was. But then the clear text SNI is a gaping privacy hole
> in TLS, the kind of issue that should keep us awake at night until it is
> resolved. We need to make sure that we make progress, rather than rehash
> the old arguments. Maybe we should invest some time and document the
> various proposals in a draft. I am willing to work on that. Any other
> volunteers?
>

It seems like there are a number of ways to encrypt the SNI for the
*second* (and subsequent) exchange with a given server; I have one that
I have some notes on and might try to write up.  But do we think that's
worth doing, or do we want to also provide protection for the initial
contact?  It seems like there is a qualitative difference, there...

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

Re: [TLS] "Encrypted" SNI

[Christian Huitema]

On 5/10/2017 12:04 PM, Viktor Dukhovni wrote:
>> On May 10, 2017, at 2:47 PM, Hubert Kario  wrote:
>>
>> But in general, I wonder if we didn't approach the SNI from the wrong side - 
>> as I said, we may not need to encrypt it, we just make sure that client and 
>> server agree on the virtual host the connection is going to.
> They can do that with a name in the clear.  If the name is to be hidden
> from passive observers, then you do need encryption so that only the
> client and server, and not the passive observers, can recover the name.
>
> Encryption means key agreement, and requires delaying SNI by a round-trip,
> or having published DH shares in DNS, which of course also needs privacy
> protection for SNI encryption to matter.
>
> I do believe this was discussed at some length previously.
It certainly was. But then the clear text SNI is a gaping privacy hole
in TLS, the kind of issue that should keep us awake at night until it is
resolved. We need to make sure that we make progress, rather than rehash
the old arguments. Maybe we should invest some time and document the
various proposals in a draft. I am willing to work on that. Any other
volunteers?

-- Christian Huitema

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

Re: [TLS] "Encrypted" SNI

[Salz, Rich]

> Encryption means key agreement, and requires delaying SNI by a round-trip,
> or having published DH shares in DNS, which of course also needs privacy
> protection for SNI encryption to matter.

With TLS1.3 encryptedExtensions, secure "domain fronting" becomes possible.  

A am long overdue for a writeup on this.

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

Re: [TLS] "Encrypted" SNI

[Viktor Dukhovni]

> On May 10, 2017, at 2:47 PM, Hubert Kario  wrote:
> 
> But in general, I wonder if we didn't approach the SNI from the wrong side - 
> as I said, we may not need to encrypt it, we just make sure that client and 
> server agree on the virtual host the connection is going to.

They can do that with a name in the clear.  If the name is to be hidden
from passive observers, then you do need encryption so that only the
client and server, and not the passive observers, can recover the name.

Encryption means key agreement, and requires delaying SNI by a round-trip,
or having published DH shares in DNS, which of course also needs privacy
protection for SNI encryption to matter.

I do believe this was discussed at some length previously.

-- 
-- 
Viktor.

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

[TLS] "Encrypted" SNI

[Hubert Kario]

Yes, encrypted SNI was discussed and ultimately rejected.

But do we really have to send the literal value? Don't we need to just make 
sure that the client and server agree on the host that the client wants to 
connect?

Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending 
the salt and the resulting hash, making the server calculate the same hash 
with each of the virtual host names it supports and comparing with the client 
provided value?

(apologies if that was already proposed and rejected)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Alerts

[Matt Caswell]

Draft-20 currently contains this text in the section "Server
Certificate Selection":

'If the client cannot construct an acceptable chain using the provided
certificates and decides to abort the handshake, then it MUST abort
the handshake with an"unsupported_certificate" alert."'

However, section 6 lists a number of other generic certificate related alerts:
certificate_revoked
certificate_expired
certificate_unknown
unknown_ca

While section 6 provides descriptions of these they are not mentioned
elsewhere in the spec, so there is no guidance as to when they might
be used.

So, given the text in the "Server Certificate Selection" section,
should a client always send "unsupported_certificate" for all
failures? Or should one of the other alerts be used instead if it
seems more appropriate? E.g. If a client attempts to "construct an
acceptable chain", but finds an expired certificate - should it
respond with "unsupported_certificate" or "certificate_expired"?

There seems to be some inconsistency between server certificate
selection and client certificate selection, i.e. in the former it is
mandated that a specific alert be sent, but in the latter there is no
such requirement.

Additionally, there are a number of other alerts mentioned in section
6 (not just certificate related ones), that are never mentioned
anywhere else in the spec. Do we really need all of these alerts? If
they are needed, shouldn't they be explicitly mentioned elsewhere in
the spec in the locations where they are relevant (associated with
some MUST/SHOULD/MAY requirement)? As things stand the interpretation
of when they should be sent seems quite loose.

Matt

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

Re: [TLS] [Technical Errata Reported] RFC7250 (5013)

[Paul Wouters]

On Wed, 10 May 2017, Sean Turner wrote:


I would definitively re-categorize this “editorial”; there’s no 2119-changes 
proposed and there’s no bits on the wire changes.  And, I’d either reject this 
one because technically the existing text is correct (i.e., they are two 
extensions) and this really ought not of caused an interoperability problem or 
mark it HFDU (hold for document update).  The new text does include the code 
points, but those can be obtained from the registry and don’t absolutely have 
to be included.


Sounds right to me.

Paul

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

Re: [TLS] [Technical Errata Reported] RFC7250 (5013)

[Sean Turner]

I would definitively re-categorize this “editorial”; there’s no 2119-changes 
proposed and there’s no bits on the wire changes.  And, I’d either reject this 
one because technically the existing text is correct (i.e., they are two 
extensions) and this really ought not of caused an interoperability problem or 
mark it HFDU (hold for document update).  The new text does include the code 
points, but those can be obtained from the registry and don’t absolutely have 
to be included.

spt

> On May 10, 2017, at 02:45, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC7250,
> "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram 
> Transport Layer Security (DTLS)".
> 
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5013
> 
> --
> Type: Technical
> Reported by: i 
> 
> Section: 7
> 
> Original Text
> -
>   IANA has allocated two new TLS extensions, client_certificate_type
>   and server_certificate_type, from the "TLS ExtensionType Values"
>   subregistry defined in [RFC5246].
> 
> Corrected Text
> --
>   IANA has allocated two new code points, 19 (0x13) and 20 (0x14), for
>   client_certificate_type and server_certificate_type, respectively,
>   in the "TLS ExtensionType Values" subregistry defined in [RFC5246].
> 
> Notes
> -
> 
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC7250 (draft-ietf-tls-oob-pubkey-11)
> --
> Title   : Using Raw Public Keys in Transport Layer Security (TLS) 
> and Datagram Transport Layer Security (DTLS)
> Publication Date: June 2014
> Author(s)   : P. Wouters, Ed., H. Tschofenig, Ed., J. Gilmore, S. 
> Weiler, T. Kivinen
> Category: PROPOSED STANDARD
> Source  : Transport Layer Security
> Area: Security
> Stream  : IETF
> Verifying Party : IESG

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

[TLS] [Technical Errata Reported] RFC7250 (5013)

[RFC Errata System]

The following errata report has been submitted for RFC7250,
"Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport 
Layer Security (DTLS)".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5013

--
Type: Technical
Reported by: i 

Section: 7

Original Text
-
   IANA has allocated two new TLS extensions, client_certificate_type
   and server_certificate_type, from the "TLS ExtensionType Values"
   subregistry defined in [RFC5246].

Corrected Text
--
   IANA has allocated two new code points, 19 (0x13) and 20 (0x14), for
   client_certificate_type and server_certificate_type, respectively,
   in the "TLS ExtensionType Values" subregistry defined in [RFC5246].

Notes
-


Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC7250 (draft-ietf-tls-oob-pubkey-11)
--
Title   : Using Raw Public Keys in Transport Layer Security (TLS) 
and Datagram Transport Layer Security (DTLS)
Publication Date: June 2014
Author(s)   : P. Wouters, Ed., H. Tschofenig, Ed., J. Gilmore, S. 
Weiler, T. Kivinen
Category: PROPOSED STANDARD
Source  : Transport Layer Security
Area: Security
Stream  : IETF
Verifying Party : IESG

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