Russ Housley | 4 Sep 17:27 2015

TLS 1.3 Key Schedule

In Section 7.1, the document says:

     4. finished_secret = HKDF-Expand-Label(xSS,
                                            "finished secret",
                                            handshake_hash, L)

     5. resumption_secret = HKDF-Expand-Label(master_secret,
                                              "resumption master secret"
                                              session_hash, L)

Why don't we use the master_secret in both the finished_secret and the resumption_secret formula?

Russ
Benoit Claise | 3 Sep 11:52 2015
Picon

Benoit Claise's No Objection on draft-ietf-tls-padding-03: (with COMMENT)

Benoit Claise has entered the following ballot position for
draft-ietf-tls-padding-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-padding/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Like Ben:
-- 5, last sentence:
Do you expect anyone to implement this MAY? It seems like this either
needs to be stronger, or removed as a "why bother"?

In my spec, I usually write this way: 
   Servers SHOULD verify that the extension
   is either empty or contains only zero bytes and log the exceptions.
Sean Turner | 3 Sep 04:39 2015

'15 TLS Fall Interim Logistics

All,

Andrei has graciously offered to host us at Microsoft in Redmond, WA [0].  We’re going to need a list of
those that plan to attend in person in order to make sure there’s a badge for you to get into the buildings. 
Please fill out the following doodle poll if you plan to attend in person: http://doodle.com/ei6px58ip59gr85y.

Note that we’re in different buildings/rooms each day.  Here are the specifics:

09/21: 16071 NE 36th Way, REDMOND, WA, 98052 (East Campus bldg. 37 room 1727)
09/22: 3850 148th Ave NE, REDMOND, WA, 98052 (West Campus Studio H room 1022)

More details as we get them.

The original meeting announcement can be found at:
https://mailarchive.ietf.org/arch/msg/tls/lfJjrpjZoidONUTIvDWzM5V52ug

spt

[0] For those of you flying, you still fly into Seattle, WA.  Don’t be confused when you see the doodle poll
that says “Redmond, WA".
Ben Campbell | 3 Sep 03:28 2015

Ben Campbell's No Objection on draft-ietf-tls-padding-03: (with COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-tls-padding-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-padding/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-- Abstract:
More in the abstract would be nice. Why'd would one want to do this?

-- 1, first paragraph, last sentence:
Can you elaborate on this? The motivation seems weak without a bit more.
When would you choose to use this at all? Wouldn't it make more sense to
fix the bug?

-- 5, last sentence:
Do you expect anyone to implement this MAY? It seems like this either
needs to be stronger, or removed as a "why bother"?

-- 6:
(Continue reading)

Julien ÉLIE | 2 Sep 16:39 2015

RC4 cipher with NNTP (RFC 4642)

Hi all,

Since the publication of RFC 7465 "Prohibiting RC4 Cipher Suites", there 
has been a discrepancy with the requirements of Section 5 of RFC 4642 
"Using Transport Layer Security (TLS) with Network News Transfer 
Protocol (NNTP)":

    NNTP client and server implementations MUST implement the
    TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite and SHOULD implement the
    TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite.  This is
    important, as it assures that any two compliant implementations can
    be configured to interoperate.  All other cipher suites are OPTIONAL.

Shouldn't something be done about that?
Maybe a new RFC obsoleting RFC 4642 (which could at the same time become 
a standard instead of a proposed standard)?  or do you have other ideas?

What would be the best wording to replace the above paragraph?  Should 
one or several ciphers still be explicitly mentioned, or the paragraph 
totally removed?  (RFC 5246 that standardizes TLS 1.2 already has a 
Section 9 about the mandatory TLS_RSA_WITH_AES_128_CBC_SHA cipher suite.)

Of course, if you see other things that should be amended in RFC 4242, 
do not hesitate to tell.

Thanks beforehand,

--

-- 
Julien ÉLIE

(Continue reading)

internet-drafts | 1 Sep 19:27 2015
Picon

I-D Action: draft-ietf-tls-padding-03.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-03.txt
	Pages           : 4
	Date            : 2015-09-01

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:
https://tools.ietf.org/html/draft-ietf-tls-padding-03

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

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/
Alvaro Retana | 1 Sep 18:10 2015
Picon

Alvaro Retana's No Objection on draft-ietf-tls-padding-02: (with COMMENT)

Alvaro Retana has entered the following ballot position for
draft-ietf-tls-padding-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-padding/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

As Alissa, I was wondering why it wasn’t easier to fix the one
implementation instead.  

The shepherd wrote: "Since then it has been found that this extension can
server (sic) to alleviate issues with issues in several vendor's
products.  There was good consensus to move forward with this document as
it may find further applicability in the future.”  So it looks like the
problem is not just one implementation…

If the WG now thinks that this extension may be valuable for other things
besides fixing bugs, then it might be nice to reword some of the document
to not focus on what seems to be one bug and just present the extension
for what it is: padding.
(Continue reading)

Alissa Cooper | 31 Aug 22:36 2015
Picon

Alissa Cooper's No Objection on draft-ietf-tls-padding-02: (with COMMENT)

Alissa Cooper has entered the following ballot position for
draft-ietf-tls-padding-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-padding/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Would be nice to include a reference to something that explains or at
least identifies the implementation that hangs when receiving
ClientHellos of a certain size. Otherwise one wonders why it's easier to
define this extension than it is to just fix that one implementation
(assuming it is only one).
Joseph Salowey | 1 Sep 16:22 2015
Picon

Working Group Last Call for draft-ietf-tls-chacha20-poly1305-00

This is the working group last call for draft-ietf-tls-chacha20-poly1305-00.  Please send any comments on the TLS working group list by September 16, 2015.  

Thanks,

J&S
_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Dang, Quynh | 28 Aug 21:17 2015

DSA support in TLS 1.3.

Hi all, 


DSA is supported in the previous versions of TLS. It would be nice if someone who uses DSA can use it in TLS 1.3 as well. 


People who don't use DSA, then they don't use DSA. People who use DSA right, it should be fine for them to use DSA.


I don't see a convincing reason to remove support of DSA in TLS 1.3.


Quynh. 

_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Eric Rescorla | 28 Aug 19:35 2015

Deprecate DH_anon in favor of raw public keys?

https://github.com/tlswg/tls13-spec/issues/233

Folks,

We presently have some support for DH_anon cipher suites. I agree that this
is a useful use case, but it's yet another mode.

I would like to suggest that we instead deprecate it and instead always use
Raw Public Key mode (https://tools.ietf.org/html/rfc7250). The idea is that
the client would simply indicate support for a raw public key and the
server could then either (a) spin a new key for this use or (b) use a long-term
one. To my mind this has three advantages:

1. Complexity: It means that we have one less operational mode. And all the public key
modes would look cryptographically similar.

2. It resolves the question of how you bind to the server's identity in 0-RTT mode
that goes in the Certificate message.

3. It makes it easier to do an SSH-style leap-of-faith mode since the server can
use the same signing key for a long time while maintaining PFS.

It seems to me that the two major counterarguments are:

1. Extra computational cost from the signature. I'm not worried too much
about that since generally the anonymous contexts don't do a lot of connections
and we don't really want to encourage pure anonymous (i.e., non-TOFU) modes
anyway.

2. It's less explicit that this is unverified. Arguably this is a feature rather than
a bug.

Thoughts?
-Ekr



_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls

Gmane