Joseph Salowey (jsalowey | 22 Sep 19:21 2014
Picon

Result of draft-ietf-tls-prohibiting-rc4 working group last call

We've reviewed the discussion resulting from the WGLC for draft-ietf-tls-prohibiting-rc4-00.  The main
complaint was that the "MUST NOT" prohibition of RC4 for servers was too strong and that RC4 is still needed
to interoperate with older implementations.   The consensus of the discussion was to keep the document as
is with respect to prohibiting the negotiation of RC4.  This document will be forwarded to the IESG for
publication.  

J/S
Fox Arcadia | 20 Sep 09:51 2014
Picon

RFC5487 PSK Key Exchange Algorithm with SHA-256/384. Premaster secret if ciphersuites negotiated for TLS V1.2?

Hello

For the ciphersuites defined in RFC 5487  3.1

PSK Key Exchange Algorithm with SHA-256/384

CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA256 = {0x00,0xAE}; CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA384 = {0x00,0xAF}; CipherSuite TLS_PSK_WITH_NULL_SHA256 = {0x00,0xB0}; CipherSuite TLS_PSK_WITH_NULL_SHA384 = {0x00,0xB1};

How is the premaster secret formed if the negotiated version is TLS 1.2?

according to RFC 4279 Pre-Shared key ciphersuites for TLS:

The premaster secret is formed as follows: if the PSK is N octets long, concatenate a uint16 with the value N, N zero octets, a second uint16 with the value N, and the PSK itself. Note 1: All the ciphersuites in this document share the same general structure for the premaster secret, namely, struct { opaque other_secret<0..2^16-1>; opaque psk<0..2^16-1>; };

...

Note 2: Using zeroes for "other_secret" effectively means that only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF is used when constructing the master secret. This was considered more elegant from an analytical viewpoint than, for instance, using the same key for both the HMAC-MD5 and HMAC-SHA1 parts. See [KRAWCZYK] for a more detailed rationale.


but if using a PRF defined in TLS V1.2, then HMAC-MD5 is not used but the HMAC defined by the PRF.
And, in that case, part of the used premaster is zeroes.

should we in that case reuse PSK for other_secret?
Thanks
_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Daniel Kahn Gillmor | 19 Sep 21:52 2014
Picon

Contemplated major revision to draft-ietf-negotiated-ff-dhe

Hi TLS folks--

I'm considering a radical syntactic change to the negotiated-ff-dhe
draft (though it changes the semantics very little if at all) for the
purposes of aligning 1.3 handshake with pre-1.3 handshakes.  Feedback
about this idea would be appreciated.

   The idea is to have the draft drop the proposed FF-DHE TLS extension
   entirely and instead redefine "Supported Elliptic curves" (TLS
   extension 10) [0] to be a "Supported named groups" extension.  Then
   we would allocate some of the currently unallocated codepoints in the
   NamedCurve IANA registry [1] to the proposed FF-DHE groups.

== Advantages ==

The main goal of this change is to simplify the TLS 1.3 handshake while
allowing clients to send a 1.2+1.3 compatible first flight that includes
FF DHE without excessive duplication.

TLS 1.2+1.3 handshakes will be able to reference a single registry for
their preferred groups and handle them in parallel, without an extra
extension.  We also avoid introducing new TLS extensions.  Clients
would be able to send extension 10 without needing to have implemented
EC.

== Further Considerations ==

So, for a TLS 1.2 client that wants to support named FF-DHE groups, it
would just send TLS extension 10 with only FF-DHE codepoints.  It would
include DHE ciphersuites, but need not include any ciphersuites with
ECDHE key exchange.

If a TLS 1.2 client wants to include ciphersuites with ECDHE as well, it
can do so, but can also indicate FF-DHE codepoints in the same TLS
extension that it indicates the available curves.

Servers responding to such a client will fall into two categories: those
aware of the FF-DHE entries in named-curves, and those that are not.

for unaware servers, they should ignore these entries and carry on with
a normal response.

For aware servers, if they select a DHE key exchange they should send an
SKE as indicated in the current draft, with the server's DHParams
modified appropriately.  (possibly, Alfredo's suggestion of sending an
entirely different handshake message instead of SKE in this case offers
a clearer indication to the client that the server has selected a named
group).

== Codepoint Requests ==

The NamedCurve registry is 16 bits, which is *huge* considering the
pressure we've given to the CFRG to limit the number of proposed curves.

This proposal suggests carving out a small space of that registry for
finite field groups.  For simplicity's sake, i imagine something like
"if the high byte is 0x01, it's FF-DHE" (the draft currently only
allocates 1 byte anyway).  But i'd also be OK with just allocating some
specific codepoints and not making any block designation, if folks think
that would make more sense.

== Feedback Please! ==

Please speak up if you find this change terrible for some reason, or if
you've already implemented the proposed draft and think that backing it
out would be misery.  I don't think this proposal changes the semantics
of the draft at all, and i think it would help the 1.3 handshake to have
this established.

If i hear no shouts of horror, i hope to get a revision of
negotiated-ff-dhe published next week with these changes.

I'm likely to need some help in navigating the IANA procedures for a
change like this which isn't exactly a straightforward codepoint
request, so if anyone has suggestions or experience with that, i'd
appreciate pointers.

All the best,

        --dkg

[0] https://tools.ietf.org/html/rfc4492#section-5.1.1
[1] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Sean Turner | 17 Sep 18:32 2014

fall interim attendance check

The chairs are concerned that the participation at the interim will be low and may not be a good use of time.  If
you are planning to attend the interim please send a message to the chairs to let them know.

J/S
Ryan Carboni | 16 Sep 21:08 2014
Picon

RFC 7366 on Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)

I read the discussion on it. The sorts of attacks on cryptographic block ciphers that are less than brute force don't even apply to the typical short messages typically transferred over the internet. Even then, MAC than encrypt doesn't reduce security substantially since even the MAC is encrypted.

Oh, BTW, thanks guys for making the internet work.
_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
RFC Errata System | 12 Sep 05:35 2014

[Technical Errata Reported] RFC5246 (4109)

The following errata report has been submitted for RFC5246,
"The Transport Layer Security (TLS) Protocol Version 1.2".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=4109

--------------------------------------
Type: Technical
Reported by: Christopher Armstrong <radix <at> twistedmatrix.com>

Section: A.4.2

Original Text
-------------
   opaque ASN.1Cert<2^24-1>;

Corrected Text
--------------
   opaque ASN.1Cert<1..2^24-1>;

Notes
-----
The appendix definition of ASN.1Cert leaves out the floor of the variable-length vector, which must be
specified according to the vector syntax specification in section 4.3. Fortunately, the original
definition of ASN.1Cert in section 7.4.2 does specify the floor as 1, so the definition in A.4.2 should be
updated to match.

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 (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5246 (draft-ietf-tls-rfc4346-bis-10)
--------------------------------------
Title               : The Transport Layer Security (TLS) Protocol Version 1.2
Publication Date    : August 2008
Author(s)           : T. Dierks, E. Rescorla
Category            : PROPOSED STANDARD
Source              : Transport Layer Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG
Simon Josefsson | 11 Sep 23:46 2014

Curve25519

Hi again,

I've updated our TLS-Curve25519 document to reference the recent
draft-turner-thecurve25519function document.

https://tools.ietf.org/html/draft-josefsson-tls-curve25519-06

I encourage implementers to let everyone know what their status is.

Thanks,
Simon
_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Simon Josefsson | 11 Sep 23:31 2014

Additional ECC curves

Hi all,

I've updated our "additional curves" document to cover registration of
all Safe Curves currently listed on DJBs page.  While I have only seen
genuine interest for a couple of these for TLS, I think it will drive
more experimentation if they are all included in a single document.

The list of supported curves are now: M-221 (aka Curve2213), E-222,
Curve1174, E-382, M-383, Curve383187, Curve41417 (aka Curve3617),
Ed448-Goldilocks, M-511 (aka Curve511187), and E-521.  Remember,
Curve25519 is covered by my other draft.

http://tools.ietf.org/html/draft-josefsson-tls-additional-curves-01

/Simon
_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Salz, Rich | 11 Sep 16:38 2014

Which browsers support signature_algorithms?

My employer will have to support dual-chains for some of our customers who want to support both current browsers and older embedded devices. We’re trying to figure out how to know when to present SHA-256 vs SHA-1 cert chain, and signature_algorithms seems like the cleanest way to do that.  Google hopes to have it shortly, but what about FF, IE, Opera, etc?

 

Replies to me will be summarized for the list.

 

Thanks.

 

-- 

Principal Security Engineer, Akamai Technologies

IM: rsalz <at> jabber.me Twitter: RichSalz

 

_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Eric Rescorla | 10 Sep 19:01 2014

Re: signature_algorithms extension definition



On Wed, Sep 10, 2014 at 9:57 AM, Peter Bowen <pzbowen <at> gmail.com> wrote:
On Wed, Sep 10, 2014 at 9:42 AM, Eric Rescorla <ekr <at> rtfm.com> wrote:
> On Wed, Sep 10, 2014 at 9:21 AM, Peter Bowen <pzbowen <at> gmail.com> wrote:
>> What is unclear is whether the client MUST be willing and able to
>> verify _certificates_ signed with any of the pairs that it specifies.
>> There are popular clients that support one set of pairs for signing
>> TLS messages (digitally-signed structs) but that support a different
>> set for signing certificates.  For example, they support sha256/rsa
>> and sha1/rsa for TLS signing but only sha1/rsa for certificate
>> signing.
>
> Yes.
>
>> Is the intent that a peer which sends the signature_algorithms
>> extension must be willing to validate certificates signatures using
>> any of the pairs in the extension?  If not, should TLS 1.3 add a flag
>> to indicate which pairs are valid for which types of signatures?
>
> I'd be interested in hearing if this is a problem for a significant number
> of clients.

Google Chrome/Chromium is one notable client.  It uses an internal TLS
implementation but uses the OS crypto stack for certificate
validation, resulting in situations where different algorithm pairs
are supported in different contexts.

Hmm... It seems like Chrome could just offer the intersection of the algorithms,
as NSS/OpenSSL will generally have a superset of the OS algorithms.

-Ekr
 

_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Peter Bowen | 10 Sep 18:21 2014
Picon

signature_algorithms extension definition

The TLS 1.2 RFC is a little ambiguous on the meaning of the contents
of the signature_algorithms extension when included in a ClientHello
message.  It says "pairs [which] may be used in digital signatures"
and "pair[s] that the client is willing to verify".  Later on it says
"If the client provided a 'signature_algorithms' extension, then all
certificates provided by the server MUST be signed by a hash/signature
algorithm pair that appears in that extension."

What is unclear is whether the client MUST be willing and able to
verify _certificates_ signed with any of the pairs that it specifies.
There are popular clients that support one set of pairs for signing
TLS messages (digitally-signed structs) but that support a different
set for signing certificates.  For example, they support sha256/rsa
and sha1/rsa for TLS signing but only sha1/rsa for certificate
signing.

Is the intent that a peer which sends the signature_algorithms
extension must be willing to validate certificates signatures using
any of the pairs in the extension?  If not, should TLS 1.3 add a flag
to indicate which pairs are valid for which types of signatures?

Thanks,
Peter

Gmane