🔓Dan Wing | 26 Feb 21:34 2015
Picon

SCSV versioning

I recently became aware that Microsoft IE won't implement SCSV.  Near as I can tell, this is the main concern,
but it is not terribly detailed about the concern:

https://connect.microsoft.com/IE/feedback/details/1002874/internet-explorer-should-send-tls-fallback-scsv

> One of the developers pointed out that the TLS_FALLBACK_SCSV feature has a significant downside--
because it doesn't convey any specific version information, it becomes a general "never fall back"
signal. The problem is that such signals are too broad; fallbacks were only ever introduced because
servers often use TLS stacks with implementation bugs. Any "don't fallback" signal sent by such a server
will be very bad for compat.
> 
> Now, the counterargument is that servers should just implement TLS properly and update when new versions
are released and/or bugs are found, but there's strong precedent showing that this just doesn't happen.
IE's decade long "DocumentMode/CompatibilityView" fiasco comes from the fact that there was a single
"StandardsMode" flag that the majority of pages had opted-into without actually being standards compliant.

Has this concern been discussed in the working group?  Should we resolve this?  (I think a resolution might be
along the lines of "I have previously tried 1.2 and 1.1", but really depends on one's interpretation of the
'significant downside' concern that an IE developer has.)

Yes, I know SCSV has finished WG review and IESG review.

-d
Eric Rescorla | 25 Feb 01:44 2015

Followup on Update

Folks,

I'd like to get a sense of the WG on whether they want to pursue the Update
mechanism [0].

There are several possibilities here, including:

- Just do basic Update
- Move session ticket establishment to Update
- Mode client authentication to Update

My sense from the discussion in HNL was that people were generally
positive on basic Update and unsure on the other two. If that's right,
I'll buff up PR#94 for merge into the spec (pending chair approval).

Thanks,
-Ekr


version of the basic mechanism.

_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
The IESG | 24 Feb 18:05 2015
Picon

Protocol Action: 'TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks' to Proposed Standard (draft-ietf-tls-downgrade-scsv-05.txt)

The IESG has approved the following document:
- 'TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing
   Protocol Downgrade Attacks'
  (draft-ietf-tls-downgrade-scsv-05.txt) as Proposed Standard

This document is the product of the Transport Layer Security Working
Group.

The IESG contact persons are Stephen Farrell and Kathleen Moriarty.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/

Technical Summary

   This document defines a Signaling Cipher Suite Value (SCSV) that
   prevents protocol downgrade attacks on the Transport Layer Security
   (TLS) protocol.  It updates RFC 2246, RFC 4346, and RFC 5246.

Working Group Summary

   Was there anything in the WG process that is worth noting?

   Yes. Lots and lots of argument:-) See the shepherd writeup
   for details. 

   The IETF LC mostly repeated arguments already aired and
   disposed of during the WG process, or was about TLS1.3.

   Consensus for this is rough, but fairly clear. 

Document Quality

   Based on some measurements taken back in November 14.4% 
   of TLS servers on the Internet now support the mechanism described 
   in this draft. 

Personnel

   Sean Turner is the document Shepherd, Stephen Farrell is the irresponsible AD.
Tony Hansen | 24 Feb 15:21 2015
Picon

question on draft-ietf-tls-session-hash-03

I have a question on draft-ietf-tls-session-hash-03. In the description I see:

As described in [TRIPLE-HS], in both the RSA and DHE key exchanges, an active attacker can synchronize two TLS sessions so that they share the same "master_secret". For an RSA key exchange where the client is unauthenticated, this is achieved as follows. Suppose a client, C, connects to a malicious server, A. A then connects to a server, S, and completes both handshakes. For simplicity, assume that C and S only use RSA ciphersuites. (Note that C thinks it is connecting to A and is oblivious of S's involvement.) My question is on the parenthetical comment at the end. I'll repeat it here, expanding C, S and A into CLIENT, SERVER and ATTACKER, respectively:

(Note that CLIENT thinks it is connecting to ATTACKER and is oblivious of SERVER's involvement.)
Am I wrong in thinking that A and S are reversed here, and this should read:

(Note that CLIENT thinks it is connecting to SERVER and is oblivious of ATTACKER's involvement.)
Or, removing the expansion:

(Note that C thinks it is connecting to S and is oblivious of A's involvement.)
That is, ATTACKER A is the malicious man in the middle that the client is not aware of. (For that matter, the server is also probably oblivious of A's involvement.)

    Tony Hansen
_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Albe Laurenz | 23 Feb 11:46 2015
Picon

Substitute for renegotiation in TLS 1.3

While researching a renegotiation problem I saw that TLS 1.3 has done away
with this feature altogether.

During the discussion that led to this
(http://www.ietf.org/mail-archive/web/tls/current/msg12906.html)
most people seemed to favor a new "rekey" facility as a substitute,
and this consensus is expressed in
http://www.ietf.org/mail-archive/web/tls/current/msg13176.html

In a first take, this was accomplished by repurposing ChangeCipherSpec
to create a new master secret:
http://www.ietf.org/mail-archive/web/tls/current/msg12609.html

However, in a later commit
(https://github.com/tlswg/tls13-spec/commit/21099bc7ff338d8deae6c3ae832f03dff29840c2)
ChangeCipherSpec was removed, and I can neither find the discussion leading
to that nor any mention in the commit how "rekey" should be accomplished now.

Does that mean that there is no possibility to renegotiate any more?
That would be unfortunate for my use case (encrypted database connections which
can last arbitrarily long).
Moreover, it would go against the consensus on the list, as quote above.

Yours,
Laurenz Albe
Joseph Salowey | 18 Feb 20:01 2015
Picon

TLS Interim Location

The location of the interim will be hosted at:

F5 Networks
401 Elliott Avenue West
Seattle, WA 98119-4017

We have a lot of folks singed up for the meeting.  I you are thinking of attending let me know now.  I will need to know the names of the attendees to facilitate access to the buildings. 

Thanks,

Joe

_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
internet-drafts | 18 Feb 00:44 2015
Picon

I-D Action: draft-ietf-tls-padding-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the IETF.

        Title           : A TLS ClientHello padding extension
        Author          : Adam Langley
	Filename        : draft-ietf-tls-padding-01.txt
	Pages           : 4
	Date            : 2015-02-17

Abstract:
   This memo describes a TLS extension that can be used to pad
   ClientHello messages to a desired size.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-padding/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-padding-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-padding-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Stephen Farrell | 17 Feb 23:25 2015
Picon
Picon

checking on an scsv point


Hiya,

In going over the threads on this I think there was one point of
Martin's where it wasn't clear to me that the WG considered his
proposal. That might be because it was raised just before the
holidays and was part of a mega-thread and fairly deeply embedded
in a longer message. Anyway, I asked Martin if he could describe
it better and he did (see below) so I'd like to just check that
the WG don't in fact want this.

If you do not want to make this change, silence if fine, but if
you would implement this in your TLS stack then please say so in
the next few days. (Pretty please: let's not side-track - I'm
really only looking for "yes, I'd implement that in my TLS
code" responses, or silence:-)

I figure it's not likely that the WG will want this, but if
there's a groundswell for doing it, we can handle the process
stuff, so don't worry about that.

Thanks,
S.

What I've been asking for time and time again is allowing (adding)
an additional/alternative server behaviour, which a TLS (server)
implementer will be _allowed_ to implement instead of a fatal
handshake failure.

The most simplistic alternative server behaviour would be for
the server to continue the handshake successfully, using

ServerHello.server_version = (ClientHello.client_version + 1)

i.e. negotiating a _higher_ TLS version instead of aborting the
TLS handshake with a fatal error.

A client (and this affects only the clients that assert the
FALLBACK_SCSV) will be able to recognize that the server supports a
higher TLS protocol version than what the TLS client proposed in
ClientHello.client_version, and it will be left to that client to
decide whether the resulting TLS session properties are OK, or wether
the client want to take chances, establishing a new connection,
starting a new handshake and proposing other/additional TLS protocol
features in ClientHello that it might have omitted (for whatever
reason) in the last ClientHello.

This alternative behaviour is better, because it provides actual
*interoperability* between TLS client and TLS server -- and in many
cases the same or reasonably secure TLS session properties without
the need for complex heuristics and a whole new connection establishment
and handshake through the entire application protocol stack
(such as HTTP CONNECT proxy traversals or the stuff before STARTTLS).

Keep in mind that I'm NOT asking to make early adopter servers(!)
non-compliant.  Admittedly, I don't know what exactly the early
adopting clients will currently do when they receive

   ServerHello.server_version = (ClientHello.client_version + 1)
Yoav Nir | 17 Feb 22:40 2015
Picon

RFC4492bis - pull request #5

https://github.com/tlswg/rfc4492bis/pull/5

Hi.

I’ve created this pull request.  The changes are here: https://github.com/tlswg/rfc4492bis/pull/5/files

Basically, the text in RFC 4492 anticipates a standardization of a certificate field that will tell us which hash function to use in a digital signature. Since that never happened pre-TLS1.2 implementations use SHA-1, while TLS 1.2 has added algorithm identifiers to the signature structure. The change reflects this.

Let me know what you think.

Yoav

_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Watson Ladd | 14 Feb 20:23 2015
Picon

Thoughts on Hardware Support

Dear all,

A while ago I promised Michael St. Johns to think hard about his goal
of making it possible to use hardware to secure the record layer
without dirty hacks. For those unaware of the problem, the same key is
used to derive encryption keys that shouldn't go out on the wire, and
IVs that do, and so it becomes difficult to ensure that keys can't be
leaked, if you expose the IV generation.

I think the easiest way is to eliminate the IV derivation entirely,
and have the record layer send the entire nonce each time. if that's
too much a waste of bandwidth, then we can specify entirely the
portion that is in TLS 1.2 derived from the MS. I think this is in
spirit similar to his proposal, but I don't recall the exact details.

I'm sure there are disadvantages of this change I am missing, or
aspects of the problem that I'm neglecting, but I seem to recall this
being the major issue.

Sincerely,
Watson Ladd
internet-drafts | 12 Feb 23:42 2015
Picon

I-D Action: draft-ietf-tls-downgrade-scsv-04.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the IETF.

        Title           : TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks
        Authors         : Bodo Moeller
                          Adam Langley
	Filename        : draft-ietf-tls-downgrade-scsv-04.txt
	Pages           : 8
	Date            : 2015-02-12

Abstract:
   This document defines a Signaling Cipher Suite Value (SCSV) that
   prevents protocol downgrade attacks on the Transport Layer Security
   (TLS) protocol.  It updates RFC 2246, RFC 4346, and RFC 5246.  Server
   update considerations are included.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-downgrade-scsv-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Gmane