Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT)

[Watson Ladd]

On Tue, May 30, 2017 at 1:03 PM, Martin Rex  wrote:
> Eric Rescorla wrote:
>> On Tue, May 23, 2017 at 9:34 PM, Martin Rex  wrote:
>>>
>>> This change _still_ prohibits the server from negotiating these algorithms
>>> with TLSv1.1 and below.
>>>
>>> Could you elaborate a little on where and why you see a problem with this?
>>>
>>
>> For starters, TLS 1.3 has already designed a completely independent
>> mechanism for doing version negotiation outside of ClientHello.version,
>> so doing another seems pretty odd. In any case, it's not something you
>> do between IETF-LC and IESG approval.
>
> The suggestion to accept a recognized TLSv1.2 cipher suite code point
> as an alternative indicator for the highest client-supported protocol
> version is not really a "mechanism".  It's efficient (with 0-bytes on
> the wire), intuitive and extremely backwards-compatible (will not upset
> old servers, neither version-intolerant as the Win2008/2012 servers,
> nor extension-intolerant servers.

It's a substantial change made after WG last call. That alone makes it
improper. If you want to get WG consensus for such a change, go ahead.
But don't try making this in the dead of night.

>
>
>>
>>> As this changes tries to explain, had such a text been used for all
>>> TLSv1.2 AEAD cipher suite code points, then browsers would have never
>>> needed any "downgrade dance" fallbacks, POODLE would have never
>>> existed as a browser problem, and the TLS_FALLBACK_SCSV band-aid
>>> would not been needed, either.
>>
>> I'm not sure this is true, because there were also servers which did
>> not understand extensions.
>
>
> It's worse -- there are still TLS servers out there which choke on
> TLS extensions (and TLS server which choke on extension ordering).

TLS 1.2 demands extensions work. Sending a TLS 1.2 hello without
extensions is going to make it impossible to implement many features
TLS 1.2 security relies on.

>
> Sending TLS extensions is therefore a negotiation scheme that we
> can not ship as patch into the installed base, because we *KNOW*
> that it will break a few existing usage scenarios.  Stuff that needs
> TLS extensions is therefore an opt-in only scheme -- and even when
> making it opt-in, we may have to additonally provide a TLS extension
> exclusion list of hostnames.
>
> It seems that there are others facing the same issue:
>
> https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1.1-and-tls-1.2-as-a-default-secure-protocols-in-winhttp-in-windows
>
> and defer enabling to explicit customer opt-in.
>
>
> Really, a very compatible and extremely robust and useful approach would
> be to allow implied client protocol version indication through presence of
> TLSv1.2-only cipher suite codepoints and this would allow large parts
> of the installed base to quickly start using TLSv1.2--without breaking
> existing usage scenarios and without the hazzle for users having to opt-in
> and test stuff.

The people who have these problems are not "large parts" of the
install base. They are large parts of *your* install base. Don't
confuse these two.

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



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

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

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

[Colm MacCárthaigh]

On Wed, May 31, 2017 at 12:49 PM, Victor Vasiliev 
wrote:

> I think I am not getting my key point across here clearly.  I am not
> arguing
> that they are inconvenient, I am arguing that the guarantee you are trying
> to
> provide is impossible.
>
> I wholeheartedly agree that if it is possible to provide guarantee B (zero
> replays), we really should provide it.  The problem is, we cannot.  Since
> 0-RTT
> is by its very design declinable, there will be always a possibility for at
> least one retry.
>

This is the part we agree on; but as I've said before, the kinds of attacks
enabled by these kinds of client-initiated retries, and by
attacker-initiated replays are fundamentally different.


> Once you concede you can have at least one replay, the difference between
> one
> replay and N replays (for all N > 0) is not that large, which is why I
> refer to
> this as "nebulous bound" (guarantee C).
>

There's a very big difference and it leads to real-world attacks. With many
replays, all sorts of side-channel analyses become possible, and I've
provided examples. It's particularly nasty that the replays can be
out-of-bound and to arbitrary nodes of the attacker's choosing, which makes
the attacks even more effective.


> Your applications already have to
> contend with replays, it's now just the matter of preventing side-channel
> amplification.
>

Yes; applications using 0-RTT do have to make themselves retry-tolerant,
 as they already must in many scenarios (e.g. a browser driven
application).  What concerns me most here is that people are clearly being
confused by the TLS 1.3 draft into mis-understanding how this interacts
with 0-RTT. For example the X-header trick, to derive an idempotency token
from the binder, that one experimental deployment innovated doesn't
actually work because it doesn't protect against the DKG attack. We're
walking into rakes here.

So, in other words, since we're now just bargaining about the value of N,
> operational concerns are a fair game.
>

They're still not fair game imo, because there's a big difference between
permitting exactly
one duplicate, associated with a client-driven retry, and permitting huge
volumes of replays. They enable different kinds of attacks.

I keep forgetting about forward secrecy in all of this, but it's worth
noting that your argument for globally resumable sessions also implies that
we shouldn't really shoot for  FS for some of the most critical user data.
I also find that bizarre.

To clarify, I am not suggesting that two streams would help.  I completely
> agree with you that two streams is not going to mitigate the DKG attack or
> others.  What I meant is that 0-RTT inherently has slightly different
> properties from 1-RTT and must be used with that in mind.  Specifically, I
> meant that it will not be enabled for applications by default, and HTTP
> clients
> would only allow it for methods that RFC 7231 defines as safe.
>

Well in the real world, I think it'll be pervasive, and I even think it
/should/ be. We should make 0-RTT that safe and remove the sharp edges.

>
> I do not believe that this to be the case.  The DKG attack is an attack
> that allows
> for a replay.
>

It's not. It permits a retry. The difference here is that the client is in
full control. It can decide to delay, to change a unique request ID, or
even not to retry at all. But the legitimate client generated the first
attempt, it can be signaled that it wasn't accepted, and then it generates
the second attempt. If it really really needs to it can even reason about
the complicated semantics of the earlier request being possibly
re-submitted later by an attacker.

Replays are different though; the attacker just literally copies the data
and can resend and resend as desired. As I've shown; this breaks real-world
things like authenticated throttling systems, and leads to side-channel and
cache analysis; where only very rarely is one attempt sufficient to
exploit.


> There is an enormous difference between a protocol that does not
> allow replays and the protocol that allows one.  For many applications, it
> only
> takes one replay for things to go terribly wrong.
>
>
>> The only place that the DKG attack can be mitigated is at application
>> layer.
>>
>
> Indeed.
>
>
>> The TLS APIs and different streams are pointless here.
>>
>
> I agree that different streams are pointless.  The only ways APIs can help
> is
> to not send replay-sensitive requests via 0-RTT, and to not accept those
> requests until peer liveness is confirmed.
>

This puts a massive smile on my face :)

>
> Indeed, but I am not suggesting we ignore those attacks.  The way I see
> this is
> that, originally when we did 0-RTT in QUIC, we had strike registers which
> are
> approximately what you are advocating.
>

Well I'd really advocate for single-use caches, because I think Forward
Secrecy is important :)


> We thought this provided property B
> (at-most-once semantics for 0-RTT), but at 

[TLS] tls - New Meeting Session Request for IETF 99

[IETF Meeting Session Request Tool]

A new meeting session request has just been submitted by Joseph A. Salowey, a 
Chair of the tls working group.


-
Working Group Name: Transport Layer Security
Area Name: Security Area
Session Requester: Joseph Salowey

Number of Sessions: 1
Length of Session(s):  2.5 Hours
Number of Attendees: 120
Conflicts to Avoid: 
 First Priority: curdle uta acme cfrg httpbis rtcweb saag stir tcpinc tokbind 
perc quic
 Second Priority: sacm oauth



People who must be present:
  Eric Rescorla
  Stephen Farrell
  Sean Turner
  Joseph A. Salowey
  Kathleen Moriarty

Resources Requested:

Special Requests:
  
-

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

[TLS] Stopping retransmission DTLS 1.2

[Simon Bernard]

Hi,

   The RFC6347, 4.2.4 [1] say :

"3. The implementation receives the next flight of messages: if 
this

is the final flight of messages, the implementation transitions to
FINISHED. If the implementation needs to send a new flight, it
transitions to the PREPARING state. Partial reads (whether
partial messages or only some of the messages in the flight) do
not cause state transitions or timer resets."

   I would like to know why "partial reads do not cause state timer 
resets".


   I mean if we receive the first "handshake message" of the expected 
"flight". we can assume that the foreign peer received our previous 
flight and so we can stop retransmissions of this flight.
   If the next message is lost, we will never respond and so the 
foreign peer should retransmit the whole flight. We don't need to 
retransmit on our side, so timer should be reset ?


   Did I missed something ?

Thx.

Simon

[1]https://tools.ietf.org/html/rfc6347#section-4.2.4

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

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

[Ilari Liusvaara]

On Tue, May 30, 2017 at 05:38:02PM -0400, Victor Vasiliev wrote:



A couple points:

- Various mechanisms related to conserving IPv4 addresses can result
  client and server disagreeing about server IP address. Or even the
  address family.
- If one has limited number of replays, distributing those among
  multiple servers is the most dangerous.
- If you rely on sticky loadbalancer, you have to ensure that attacker
  can't send requests directly to the servers, bypassing the
  loadbalancer! In some architectures, it is rather easy to
  accidentially expose the backend servers, even if all the honest
  connections flow through the loadbalancer.
- Binders are computationally random, so if you want to shard on
  those for strike register, simple mod N scheme distributes the load
  well.
- 0-RTT scope can be written into tickets. The session ticket scope
  may be larger than that. Routing to datacenters should be relatively
  sticky.
- As noted, this mess with state is just necressary for security if
  you use 0-RTT.
- Could be good idea for clients to blacklist origins for tickets
  (meaning, use GDHE-CERT and possibly (GDHE-)static-PSK handshakes
  only) for some time if duplicate accepts are detected during
  grease testing. That should not cause any servers to actually
  break from user standpoint, since servers need to support those
  handshake modes anyway.


-Ilari

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

[TLS] [Editorial Errata Reported] RFC6347 (5026)

[RFC Errata System]

The following errata report has been submitted for RFC6347,
"Datagram Transport Layer Security Version 1.2".

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

--
Type: Editorial
Reported by: Timm Korte 

Section: 4.1

Original Text
-
   length
  Identical to the length field in a TLS 1.2 record.  As in TLS 1.2,
  the length should not exceed 2^14.

Corrected Text
--
   length
  Identical to the length field in a TLS 1.2 record.  As in TLS 1.2,
  the length MUST NOT exceed 2^14.

Notes
-
The originial comment on length in RFC 5246, 6.2.1 is:
   length
  The length (in bytes) of the following TLSPlaintext.fragment.  The
  length MUST NOT exceed 2^14.
so it has to be "MUST NOT" - instead of "should not" as currently stated.

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. 

--
RFC6347 (draft-ietf-tls-rfc4347-bis-06)
--
Title   : Datagram Transport Layer Security Version 1.2
Publication Date: January 2012
Author(s)   : E. Rescorla, N. Modadugu
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