RFC Errata System | 29 May 13:39 2015

[Technical Errata Reported] RFC5246 (4382)

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=4382

--------------------------------------
Type: Technical
Reported by: Laura Corcoran <lscorco <at> nsa.gov>

Section: 4.3

Original Text
-------------
In the following example, Datum is defined to be three consecutive
   bytes that the protocol does not interpret, while Data is three
   consecutive Datum, consuming a total of nine bytes.

      opaque Datum[3];      /* three uninterpreted bytes */
      Datum Data[9];        /* 3 consecutive 3 byte vectors */

Corrected Text
--------------
In the following example, Datum is defined to be three consecutive
   bytes that the protocol does not interpret, while Data is three
   consecutive Datum, consuming a total of nine bytes.

      opaque Datum[3];      /* three uninterpreted bytes */
      Datum Data[3];        /* 3 consecutive 3 byte vectors */
(Continue reading)

Barry Leiba | 26 May 18:35 2015
Picon

Barry Leiba's No Objection on draft-ietf-tls-negotiated-ff-dhe-09: (with COMMENT)

Barry Leiba has entered the following ballot position for
draft-ietf-tls-negotiated-ff-dhe-09: 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-negotiated-ff-dhe/

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

The intended status in the document text does, indeed, need to be changed
to "Standards Track".  The last call was issued as "Proposed Standard",
and the IESG ballot is set up for that, so I think we're OK -- please
just fix the text in the next document rev.
Benoit Claise | 26 May 11:51 2015
Picon

Benoit Claise's No Objection on draft-ietf-tls-negotiated-ff-dhe-09: (with COMMENT)

Benoit Claise has entered the following ballot position for
draft-ietf-tls-negotiated-ff-dhe-09: 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-negotiated-ff-dhe/

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

Not issue on the technical content and the publication of this document,
but https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/
and the write-up mention "Standard Track" while the draft status is
Informational, as spotted by Linda in her OPS-DIR review below:

This document is on the Informational Track to specify ways for client
and server to establish common finite-field DH parameters with known
structure and a mechanism for
peers to negotiate support for these groups.
The document is well written and very clear.
A couple questions:
1)    Why this document is not standard track?
2)    Several sections requests range in reference of p, e.g.  “p-1” or p
(Continue reading)

Eric Rescorla | 25 May 19:35 2015

More clarity on resumption and session hash





I'm updating the NSS session hash implementation to conform to the new spec
and I see that it's very clear on what happens when you have a resumption
where the original handshake did not include the extension and the new one
does (thanks David and Martin)

  o  If the original session did not use an extended master secret but
      the new ClientHello does contain the "extended_master_secret"
      extension, the server MUST NOT perform the abbreviated handshake.
      Instead, it SHOULD continue with a full handshake to negotiate a
      new session.

However, it's less clear on what happens when the original handshake included
the extension and the new one does not:

   o  If the new ClientHello does not contain the
      "extended_master_secret" extension, the server SHOULD abort the
      handshake.  If it continues with an abbreviated handshake in order
      to interoperate with legacy peers, then the considerations in
      Section 5.4 apply.

This doesn't seem to distinguish between the two cases (original session
did and did not use the extension), but they seem different, since the
original session not using session hash is a common case (legacy) whereas
an extension->no extension transition is an anomaly. Note that the client
*is* required to send it, so I think there's a reasonably strong
argument that the server should require it.

The two main options appear to be:

    1. Fall back to a full handshake.
    2. Abort the connection

The argument for the first appears to be interop. The argument for the
second appears to be that it's likely there is an error or a mid-flight
reconfiguration on the client (which seems not good). My mild preference
is for abort but I think it's important in any case that the draft be
clear.


Similarly, the text about the client side doesn't seem to draw this
distinction:

      If the new ServerHello does not contain the
      "extended_master_secret" extension, the client SHOULD abort the
      handshake.  If it continues with an abbreviated handshake in order
      to interoperate with legacy peers, then the considerations in
      Section 5.4 apply.

Because above the server is required to provide the extension when
resuming a session where the extension was negotiated, it seems like
we should require the client to fail in that case (that's the sense
of the MUST).

I see there was some discussion on the list 3/10 but it was inconclusive.

-Ekr

_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Xiaoyin Liu | 22 May 15:16 2015

Re: prohibit <1.2 on clients (but allow servers) (was: prohibit <1.2 support on 1.3+ servers (but allow clients))

<!-- .ExternalClass .ecxhmmessage P { padding:0px; } .ExternalClass body.ecxhmmessage { font-size:12pt; font-family:Calibri; } -->From: pgut001 <at> cs.auckland.ac.nz
To: xiaoyin.l <at> outlook.com; azet <at> azet.org; davemgarrett <at> gmail.com
CC: tls <at> ietf.org
Subject: RE: [TLS] prohibit <1.2 on clients (but allow servers) (was: prohibit <1.2 support on 1.3+ servers (but allow clients))
Date: Fri, 22 May 2015 12:30:49 +0000


>So if some sort of BCP is published, it should explicitly target browsers and
>web servers where this kind of upgrade/change is possible.  Telling people to
>throw away their PLCs and replace them with new ones isn't going to fly.
 
Agreed!
 
Xiaoyin
_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Jeffrey Walton | 22 May 04:46 2015
Picon

TLS 1.3 and vendor strings?

Are there any plans to support free form vendor strings?

The use case is similar to Apple's buggy ECDHE-ECDSA SecureTransport
for OS X 10.8 and iOS 7.

In this case, OpenSSL had to jump through a number of hoops to
identify the potentially affected clients via fingerprinting.
Fingerprinting was not precise, and it potentially captured unaffected
clients when Apple patched at OS X 10.8.4 and iOS 7.0.3. That is, an
OS X 10.8.5 or iOS 7.0.4 client would potentially be identified as
buggy even though it was patched.

Or is there another way to handle the occasional implementation bug like this?

(And to be clear: patching is not always an option. Apple is not like
Microsoft or Linux. Rather, they left a number of hosts unpatched for
the ECDHE-ECDSA bug; and did the same with CVE-2015-1130 (Goto Fail);
and did the same with CVE-2015-1130 (Hidden Backdoor)).
Jeffrey Walton | 21 May 20:51 2015
Picon

Using Warning Alerts to Accommodate Offline Attacks?

The logjam paper is available at
https://weakdh.org/imperfect-forward-secrecy.pdf.

Note that the authors were successful in exploiting some user agents
because they could send an alert warning to reset the handshake timer.
The timer reset accommodated the offline portion of the attack. Cf.,
page 5.

Is this desired behavior? Or is it a security bug?

Jeff
Dave Garrett | 21 May 18:10 2015
Picon

prohibit <1.2 support on 1.3+ servers (but allow clients)

I was going to hold off on suggesting this due to other topics dominating the list, but we might be in a
kill-the-old-junk mood due to the latest old-junk vulnerability, so...

Old versions of TLS need to be phased out at some point (even the one we're designing now), however the
current modus operandi is generally to wait until a catastrophic breakage forces everyone into a panic
disable. I'd like to at least try to do better prior to the next time. I'd like to propose giving servers &
clients different expectations as a transitional measure:

1) No general change to current TLS other than pointing to the UTA BCP from time to time.
https://tools.ietf.org/html/rfc7525

2) For TLS 1.3, add a blurb to the effect of:
"Server TLS implementations supporting TLS 1.3 or later MUST NOT negotiate TLS 1.0 or TLS 1.1 for any reason.
Client TLS implementations are RECOMMENDED to not support old TLS versions, where possible."

The reasoning here is that major server updates are unfortunately uncommon, but client updates are
routine. Server implementations get updated, but deployments don't/can't keep up. There are no
legitimate clients that do not support TLS 1.2, and even plenty of old ones can support it if actually
enabled (and those vendors should get their act together and push updates to flip that on for all old
versions, regardless of EOL status). The current strategy is basically to support everything forever
and that has been shown to be quite detrimental, especially over the past year.

Note that this is not just about dropping support for versions X & Y. It's about giving implementations a
chance to drop all the baggage that comes with those old versions and focus only on reasonably modern
standards instead.

For those that would disagree with mandating servers drop support for the protocol from 1999, I think it's
reasonable to just require you to have to ignore the RFCs if you really want to keep doing this sort of thing
in 2015. Everyone else should have servers that have at least vaguely reasonable minimum standards
out-of-the-box. Allowing obsolete security to be considered legitimate is a public hazard, and I don't
want to wait around for more exploits to deal with it. Security is only as strong as the weakest link; we need
to start baking this into new specifications

Dave

PS
I am aware some vendors irresponsibly abandoned lots of mobile users on obsolete OS versions. They should
be treated like WinXP+IE6: useless until you download a better browser yourself. If that's not possible,
complain to the hardware vendor that didn't provide updates.
Simon Josefsson | 20 May 19:14 2015

Strawman on EdDSA/Ed25519 in TLS

Dear WG,

Support for EdDSA/Ed25519 in TLS has been suggested a couple of times.
I have started to work on an I-D to describe more precisely what that
would actually mean, and here is an initial strawman document:

https://tools.ietf.org/html/draft-josefsson-tls-eddsa-00

I'm confident I missed some major pieces of the puzzle, but feedback and
review is welcome so the document can be improved into something that
can be implemented and interoperate.

Until the main parts have been fleshed out please email me directly and
I'll try to do the best I can to merge feedback into the document.  If
the WG chairs permit, that discussion could also be done on this list.
The best form of feedback would be in the form of merge requests or a
clearly described issue in the issue tracker.  Please see:

https://gitlab.com/jas/ietf-tls-eddsa

One aspect I'm aware of is that there is no OID allocated nor
specification of PKIX certificates with EdDSA/Ed25519 public keys.  I'm
not sure the above document is the right place for doing that though,
and more thinking around this topic is especially appreciated.

Cheers,
/Simon

_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Joseph Salowey | 20 May 17:47 2015
Picon

Call for WG adoption draft-josefsson-tls-curve25519

This is the WG call for adoption of:

https://www.ietf.org/archive/id/draft-josefsson-tls-curve25519-06.txt

This draft specifies the use of Curve25519 for ephemeral key exchange in the TLS and DTLS.  This draft serves as the starting point (it’s expired and needs to be updated in light of http://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/).  If you object to the adoption of this draft, please let us know why by 20150602.

Note: We’re not doing an early code point assignment for this draft, because it clearly needs to resurrected and tweaked.  Once that happens, there’s nothing stopping a request from the authors for an early code point assignment.

Thanks,

J/S
_______________________________________________
TLS mailing list
TLS <at> ietf.org
https://www.ietf.org/mailman/listinfo/tls
Watson Ladd | 20 May 16:05 2015
Picon

Another IRINA bug in TLS

https://weakdh.org/

Transcript hashing will solve this problem. In the meantime, you want
to turn off DH_EXPORT. There are also implications for false start.
Chrome has already announced countermeasures. I'm pretty sure this
won't be the last issue of this nature.

Sincerely,
Watson Ladd

Gmane