Re: [TLS] Design Alternatives for Kerberos + DH

[Rick van Rein]

Hello Benjamin / TLS WG,

I didn't mean to drop the list, so your full response is hereby included.

>>> No, mutual authentication requires the client to receive a message from
>>> the server.
>> Yes, I know -- the server needs to handle the session key or the subkey
>> to prove posession of its KDC-stored service key.  By using it, the client
>> can be convinced or server identity.
>
> Good to hear.  Other readers, perhaps, did not.

>>> This could be implicit
>> I think it automatically is with TLS, since the Finished messages won't
>> succeed until both parties have derived the same master secret, which
>> if it involves the session key or subkey proves the server's identity in an
>> implicit manner.
>
> From just your short descriptions, it was unclear to me what exactly
> went into the master secret from the Kerberos side, so I wanted to be sure.

Yes, balancing with terseness.  The master secret is calculated as
always, incorporating the pre-master secret as well as client/server
random and, under RFC 7627, all of the handshake messages up to and
including ClientKeyExchange.

The pre-master is the combination of the ECDH shared secret and the
session key(s) from Kerberos.  For the latter, we can choose one or more
from:
 * The session key generated by the KDC for this client/server
combination session (lasting as long as the service ticket, usually
about a day)
 * A subkey inserted into the Authenticator by the client for this
particular connection (which can avoid replay during ticket life)
 * Possibly: a random byte string from the server, "decrypted" with the
session key, to form a connection-specific key that hinges on
server-side entropy

I think my preference would be a combination of 2nd and 3rd because that
incorporates entropy from both sides; although entropy from both sides
is also incorporated through the ClientHello and ServerHello Random
bytes, these are not encrypted to conceal it from MITM as in the 2nd and
3rd options.  This is a bit paranoid perhaps --the ECDH mechanism
achieves a similar thing already-- but the appeal of 2nd and 3rd as very
light-weight and makes it much more difficult to crack.
>> I do believe a long-enough Finished message is required though.  For
>> the TLS_ECDHE_KRB_ CipherSuites I've proposed a verify_data_lenth
>> to match the required certainty from the message; if we mix Kerberos
>> client "certificates" info other CipherSuites like TLS_ECDHE_RSA_ then
>> a client SHOULD negotiate a high-enough value and the server MUST
>> support that.  It requires TLS 1.2 to do these things.
>>
>
> Well, hmm, that's an interesting question.  (Note, of course, that the
> current Kerberos AES enctypes only use 96 bits of HMAC-SHA1 for their
> MIC.)


Keyed hashes such as HMAC-SHA1 don't seem to add much here, and they
would have a grave impact on how the hashes are calculated in TLS stacks
(because the key is only known later in the exchange).  I would suggest
that we follow TLS' hash preferences, since we are going to rely on
those hashes having been computed through the prior exchange of TLS
messages, and add those to the IANA Registry for Kerberos Checksum Type
Numbers; this currently includes SHA1 and I doubt that anyone would
protest to extensions with stronger unkeyed hashes.


> The client can obtain information indicating that the server has
> the correct Kerberos key both from the decrypted contents of the
> Finished message

I assume you meant "by matching the Finished message with one generated
locally".

> and also from the integrity protection of the
> TLSCiphertext, since both use material derived from the master secret. 

Yes, TLSCiphertext is also protected, but my main concern is with
Finished, because I would not like accept a TLS connection under
doubtful circumstances, just to be OK when an application only sets up
TLS as a means of authentication.  With the longer Finished messages,
that would not happen.

> So I guess I'm not yet convinced that the verify_data_length should be
> twice the bitlength of the negotiated symmetric cipher, but perhaps I'm
> missing something obvious.

I'm not sure if it should be 1x or 2x the cipher length.  Most important
to me is that it must be longer than the 12 bytes that were standard up
to TLS 1.1 and default in TLS 1.2.

-RIck

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

Re: [TLS] PR for anti-downgrade mechanism

[Short, Todd]

Does the sentinel have to be the first N bytes?

RFC 5246 (S7.4.1.2) specifies Random as a combination of a uint32 time value 
and 28 random bytes.

Rather than risk breaking backwards compatibility by changing the definition of 
the first 4 bytes, perhaps the sentinel can be moved to another location within 
the ServerRandom field? Either the  second set of N bytes or the last set of N 
bytes? Where the sentinel is located shouldn’t really matter. Subsequently, the 
sentinel can be chosen with more freedom. As I recall, one reason (but not the 
only reason) the length was extended to 8 bytes due to the gmt_unix_time issue; 
is an 8-byte sentinel still needed if it’s not overlapping the gmt_unix_time 
(yes, I’m concerned about a reduction of entropy by 25%)?

In extending this, should the ClientHello random value also include the 
sentinel? (Yes, I know this again reduces entropy.) A MITM can implement a 
downgrade attack in either direction. The server can terminate the connection 
that much earlier. (Risk: ~2^{-64} that an older client might be rejected for 
having a mismatched sentinel/version.)

Viktor Dukhovni had proposed a ~5 byte sentinel:

struct {
uint32 gmt_unix_time;
opaque random_bytes[23];
uint8 sentinel[5];
} Random;

--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Oct 17, 2015, at 7:02 PM, Viktor Dukhovni 
mailto:ietf-d...@dukhovni.org>> wrote:

On Sat, Oct 17, 2015 at 03:20:08PM -0700, Eric Rescorla wrote:

I don't feel strongly about this, but I don't see how what you suggest
is any simpler than the version number encoding I proposed.  Arguably,
it's more complicated since you can't implement the sentinel check with
memcmp().

The simplicity I have in mind minimality of the design, not so much
the implementation.

The bit in question could be the high bit of of the first octet of
server random.  The code doing the comparing would need a mutable
copy of the test value, and would clone the bit in question from
the input to the test value, then memcmp.

tls13 = peerrand[0] & 0x80;
sentinel[0] = tls13 | (sentinel[0] & 0x7f);
if (memcmp(srand, test, len) == 0) {
   if (tls13) {
/* Peer indicates TLS >= 1.3 support */
...
   } else {
/* Peer indicates TLS 1.2 support */
...
   }
}

--
Viktor.

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

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

Re: [TLS] PR for anti-downgrade mechanism

[Eric Rescorla]

On Mon, Oct 19, 2015 at 7:37 AM, Short, Todd  wrote:

> Does the sentinel have to be the first N bytes?
>
> RFC 5246 (S7.4.1.2) specifies Random as a combination of a uint32 time
> value and 28 random bytes.
>
> Rather than risk breaking backwards compatibility by changing the
> definition of the first 4 bytes, perhaps the sentinel can be moved to
> another location within the ServerRandom field? Either the  second set of N
> bytes or the last set of N bytes? Where the sentinel is located shouldn’t
> really matter. Subsequently, the sentinel can be chosen with more freedom.
> As I recall, one reason (but not the only reason) the length was extended
> to 8 bytes due to the gmt_unix_time issue; is an 8-byte sentinel still
> needed if it’s not overlapping the gmt_unix_time (yes, I’m concerned about
> a reduction of entropy by 25%)?
>

Maybe it's because I haven't had my coffee yet, but ISTM that overloading
the time field
lowers the risk of false positives because we can choose a sentinel that
will never
collide with a conformant TLS 1.2 ServerHello. By contrast, a sentinel in
the
randomly generated portion always has a 2^{-n} chance of collision.



> In extending this, should the ClientHello random value also include the
> sentinel? (Yes, I know this again reduces entropy.) A MITM can implement a
> downgrade attack in either direction. The server can terminate the
> connection that much earlier
>

How does this help? The attacker will just rewrite the ClientHello.random.

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

[TLS] New Version Notification for draft-schmidt-pake-tls-00.txt

[Schmidt , Jörn-Marc]

Dear all,

I just submitted a draft for integrating PAKE in TLS (see below). The main idea 
is to define one PAKE-identifier that can be used for different schemes alike 
instead of having to specify a ClientHello-Extension for each and every new 
scheme.

Any feedback/comments/further ideas are very welcome.

Best regards,

Jörn


-Ursprüngliche Nachricht-
Von: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Gesendet: Montag, 19. Oktober 2015 17:03
An: Schmidt, Jörn-Marc; Schmidt, Jörn-Marc; "Dennis Kügler"; Dennis Kuegler
Betreff: New Version Notification for draft-schmidt-pake-tls-00.txt


A new version of I-D, draft-schmidt-pake-tls-00.txt
has been successfully submitted by Jörn-Marc Schmidt and posted to the
IETF repository.

Name:   draft-schmidt-pake-tls
Revision:   00
Title:  Using Password-Authenticated Key Agreement (PAKE) schemes in TLS
Document date:  2015-10-19
Group:  Individual Submission
Pages:  14
URL:
https://www.ietf.org/internet-drafts/draft-schmidt-pake-tls-00.txt
Status: https://datatracker.ietf.org/doc/draft-schmidt-pake-tls/
Htmlized:   https://tools.ietf.org/html/draft-schmidt-pake-tls-00


Abstract:
   This document describes how to integrate Password-Authenticated Key
   Agreement (PAKE) schemes into TLS.  These schemes enable two parties
   who share a potentially weak password to derive a common
   cryptographic key, allowing them to establish a secure channel.  The
   current document defines a generic way to integrate PAKE schemes into
   TLS.  In addition, it demonstrates how to use the well-known Password
   Authenticated Connection Establishment (PACE) scheme in TLS as an
   example for the generic construction.


  


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.

The IETF Secretariat



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR for anti-downgrade mechanism

[David Benjamin]

On Mon, Oct 19, 2015 at 11:10 AM Eric Rescorla  wrote:

> On Mon, Oct 19, 2015 at 7:37 AM, Short, Todd  wrote:
>
>> Does the sentinel have to be the first N bytes?
>>
>> RFC 5246 (S7.4.1.2) specifies Random as a combination of a uint32 time
>> value and 28 random bytes.
>>
>> Rather than risk breaking backwards compatibility by changing the
>> definition of the first 4 bytes, perhaps the sentinel can be moved to
>> another location within the ServerRandom field? Either the  second set of N
>> bytes or the last set of N bytes? Where the sentinel is located shouldn’t
>> really matter. Subsequently, the sentinel can be chosen with more freedom.
>> As I recall, one reason (but not the only reason) the length was extended
>> to 8 bytes due to the gmt_unix_time issue; is an 8-byte sentinel still
>> needed if it’s not overlapping the gmt_unix_time (yes, I’m concerned about
>> a reduction of entropy by 25%)?
>>
>
> Maybe it's because I haven't had my coffee yet, but ISTM that overloading
> the time field
> lowers the risk of false positives because we can choose a sentinel that
> will never
> collide with a conformant TLS 1.2 ServerHello. By contrast, a sentinel in
> the
> randomly generated portion always has a 2^{-n} chance of collision.
>

If I'm understanding things correctly, servers which expect to be the
target of tools like tlsdate (or aren't sure) will be unable to deploy this
mechanism if the sentinel collides with gmt_unix_time. If you're not sure
whether you care about tlsdate, you at least risk some compatibility
problems with anything that might have been making assumptions here.

It seems slightly strange to me to say the reason to do it this way is that
we don't risk collision with conformant TLS 1.2 ServerHellos. The reason
it's not a collision is because it means servers (supporting TLS 1.3) are
now required to produce non-conformant TLS 1.2 ServerHellos.

David


>
>
>> In extending this, should the ClientHello random value also include the
>> sentinel? (Yes, I know this again reduces entropy.) A MITM can implement a
>> downgrade attack in either direction. The server can terminate the
>> connection that much earlier
>>
>
> How does this help? The attacker will just rewrite the ClientHello.random.
>
> -Ekr
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-rfc4492bis-04.txt

[internet-drafts]

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   : Elliptic Curve Cryptography (ECC) Cipher Suites for 
Transport Layer Security (TLS) Versions 1.2 and Earlier
Authors : Yoav Nir
  Simon Josefsson
  Manuel Pegourie-Gonnard
Filename: draft-ietf-tls-rfc4492bis-04.txt
Pages   : 30
Date: 2015-10-19

Abstract:
   This document describes key exchange algorithms based on Elliptic
   Curve Cryptography (ECC) for the Transport Layer Security (TLS)
   protocol.  In particular, it specifies the use of Ephemeral Elliptic
   Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the
   use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new
   authentication mechanism.


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

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc4492bis-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/

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

Re: [TLS] New Version Notification for draft-ietf-tls-rfc4492bis-04.txt

[Yoav Nir]

Of course, if anyone wants to help with the merge via pull requests, that would 
be great.

Yoav

> On 19 Oct 2015, at 6:58 PM, Yoav Nir  wrote:
> 
> Hi
> 
> I’ve submitted version -04 of this draft, incorporating the new curves 
> Curve25519 and Curve448.
> 
> I’m sorry to say that I have made the merge far too quickly and the result is 
> quite sketchy, but I did beat the deadline.
> 
> So I’m hoping to complete the merge soon.
> 
> Yoav
> 
> 
>> Begin forwarded message:
>> 
>> From: internet-dra...@ietf.org 
>> Date: 19 October 2015 at 6:56:17 PM GMT+3
>> To: "Yoav Nir" mailto:ynir.i...@gmail.com>>, "Manuel 
>> Pegourie-Gonnard" mailto:m...@elzevir.fr>>, "Simon 
>> Josefsson" mailto:si...@josefsson.org>>, "Simon 
>> Josefsson" mailto:si...@josefsson.org>>, "Yoav Nir" 
>> mailto:ynir.i...@gmail.com>>, "Manuel 
>> Pegourie-Gonnard" mailto:m...@elzevir.fr>>
>> Subject: New Version Notification for draft-ietf-tls-rfc4492bis-04.txt
>> 
>> 
>> A new version of I-D, draft-ietf-tls-rfc4492bis-04.txt
>> has been successfully submitted by Yoav Nir and posted to the
>> IETF repository.
>> 
>> Name:draft-ietf-tls-rfc4492bis
>> Revision:04
>> Title:   Elliptic Curve Cryptography (ECC) Cipher Suites for 
>> Transport Layer Security (TLS) Versions 1.2 and Earlier
>> Document date:   2015-10-19
>> Group:   tls
>> Pages:   30
>> URL:
>> https://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4492bis-04.txt 
>> 
>> Status: https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/ 
>> 
>> Htmlized:   https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-04 
>> 
>> Diff:   
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc4492bis-04 
>> 
>> 
>> Abstract:
>>   This document describes key exchange algorithms based on Elliptic
>>   Curve Cryptography (ECC) for the Transport Layer Security (TLS)
>>   protocol.  In particular, it specifies the use of Ephemeral Elliptic
>>   Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the
>>   use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new
>>   authentication mechanism.
>> 
>> 
>> 
>> 
>> 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 
>> .
>> 
>> The IETF Secretariat
>> 
> 

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

[TLS] Fwd: New Version Notification for draft-ietf-tls-rfc4492bis-04.txt

[Yoav Nir]

Hi

I’ve submitted version -04 of this draft, incorporating the new curves 
Curve25519 and Curve448.

I’m sorry to say that I have made the merge far too quickly and the result is 
quite sketchy, but I did beat the deadline.

So I’m hoping to complete the merge soon.

Yoav


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Date: 19 October 2015 at 6:56:17 PM GMT+3
> To: "Yoav Nir" , "Manuel Pegourie-Gonnard" 
> , "Simon Josefsson" , "Simon Josefsson" 
> , "Yoav Nir" , "Manuel 
> Pegourie-Gonnard" 
> Subject: New Version Notification for draft-ietf-tls-rfc4492bis-04.txt
> 
> 
> A new version of I-D, draft-ietf-tls-rfc4492bis-04.txt
> has been successfully submitted by Yoav Nir and posted to the
> IETF repository.
> 
> Name: draft-ietf-tls-rfc4492bis
> Revision: 04
> Title:Elliptic Curve Cryptography (ECC) Cipher Suites for 
> Transport Layer Security (TLS) Versions 1.2 and Earlier
> Document date:2015-10-19
> Group:tls
> Pages:30
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4492bis-04.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/
> Htmlized:   https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-04
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc4492bis-04
> 
> Abstract:
>   This document describes key exchange algorithms based on Elliptic
>   Curve Cryptography (ECC) for the Transport Layer Security (TLS)
>   protocol.  In particular, it specifies the use of Ephemeral Elliptic
>   Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the
>   use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new
>   authentication mechanism.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
> 

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

[TLS] Directly signing randoms

[Eric Rescorla]

Folks,

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

At the interim we discussed whether it was worth having digital
signatures explicitly include the client and server random values
rather than just the transcript to enable privilege separation, as
proposed by Nikos. We had a little trouble getting clarity on the
desired use case, but the two we understood were:

1. Having a separate module which is signing for authentication
   and wants to explicitly provide a random value to ensure
   that it's not signing arbitrary data.

2. Having a separate module which is verifying the peer's authentication
   and wants to explicitly provide a challenge to be signed by the
   peer.

The general feeling was that you could achieve both cases by simply
the unprivileged portion of the system provide the module with the
handshake transcript and allow it to verify that the random
was present in the correct location (or at all in case #2) and so
that no change was needed.

As I said, there was some confusion on the exact scenario, so if
I've misunderstood please clarify. Otherwise, I think we have
consensus to close this as WONTFIX.

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

[TLS] Version in record MAC

[Eric Rescorla]

Folks,

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

The additional data field presently includes the version:

  additional_data = seq_num + TLSPlaintext.record_version

However, TLSPlaintext.record_version is now always {3, 1}, so
this is redundant. There seem to be two primary options here:

 1. Don't MAC the version at all.
 2. MAC the negotiated version (which should be clear at
this point).

I could go either way on this (slightly leaning towards #2) but
the current thing seems silly.

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

Re: [TLS] Version in record MAC

[Colm MacCárthaigh]

If (2.) is used, would it be nice to make it  negotiated_version + seq_num?
I think for some algorithms, the MAC can be partially pre-computed if
things are in that order.

On Mon, Oct 19, 2015 at 9:28 AM, Eric Rescorla  wrote:

> Folks,
>
> https://github.com/tlswg/tls13-spec/issues/278
>
> The additional data field presently includes the version:
>
>   additional_data = seq_num + TLSPlaintext.record_version
>
> However, TLSPlaintext.record_version is now always {3, 1}, so
> this is redundant. There seem to be two primary options here:
>
>  1. Don't MAC the version at all.
>  2. MAC the negotiated version (which should be clear at
> this point).
>
> I could go either way on this (slightly leaning towards #2) but
> the current thing seems silly.
>
> -Ekr
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>


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

Re: [TLS] Version in record MAC

[David Benjamin]

What purpose does putting the version in the AD serve? It's not harmful,
sure, but just using the sequence number is simplest. It seems the only
reason we'd consider putting it into the AD is because historically the
record version was in there as part of the record header. In a vacuum, I'm
having a hard time imagining why one would want negotiated_version in there
that wouldn't also apply to putting the whole handshake hash in there. Am I
missing something?

David

On Mon, Oct 19, 2015 at 12:40 PM Colm MacCárthaigh 
wrote:

>
> If (2.) is used, would it be nice to make it  negotiated_version
> + seq_num? I think for some algorithms, the MAC can be partially
> pre-computed if things are in that order.
>
> On Mon, Oct 19, 2015 at 9:28 AM, Eric Rescorla  wrote:
>
>> Folks,
>>
>> https://github.com/tlswg/tls13-spec/issues/278
>>
>> The additional data field presently includes the version:
>>
>>   additional_data = seq_num + TLSPlaintext.record_version
>>
>> However, TLSPlaintext.record_version is now always {3, 1}, so
>> this is redundant. There seem to be two primary options here:
>>
>>  1. Don't MAC the version at all.
>>  2. MAC the negotiated version (which should be clear at
>> this point).
>>
>> I could go either way on this (slightly leaning towards #2) but
>> the current thing seems silly.
>>
>> -Ekr
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>
>
> --
> Colm
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-tls13-10.txt

[internet-drafts]

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   : The Transport Layer Security (TLS) Protocol Version 
1.3
Author  : Eric Rescorla
Filename: draft-ietf-tls-tls13-10.txt
Pages   : 103
Date: 2015-10-19

Abstract:
   This document specifies Version 1.3 of the Transport Layer Security
   (TLS) protocol.  The TLS protocol allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-tls13-10

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


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/

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

Re: [TLS] PR for anti-downgrade mechanism

[Martin Thomson]

On 19 October 2015 at 08:08, Eric Rescorla  wrote:
> overloading the time field
> lowers the risk of false positives because we can choose a sentinel that
> will never
> collide with a conformant TLS 1.2 ServerHello. By contrast, a sentinel in
> the
> randomly generated portion always has a 2^{-n} chance of collision.

Yes, this is right.  The marginal gain is that the proportion of
servers that generate a time here are immune to collisions.  If
servers all servers did that, we wouldn't have to worry about
collisions at all. Unfortunately, we do know that some generate random
values.

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

Re: [TLS] Fwd: New Version Notification for draft-ietf-tls-rfc4492bis-04.txt

[Ilari Liusvaara]

On Mon, Oct 19, 2015 at 06:58:52PM +0300, Yoav Nir wrote:
> Hi
> 
> I’ve submitted version -04 of this draft, incorporating the new curves 
> Curve25519 and Curve448.
> 
> I’m sorry to say that I have made the merge far too quickly and the result is 
> quite sketchy, but I did beat the deadline.
> 
> So I’m hoping to complete the merge soon.

Some comments:

- The document seems to lack obsoletes RFC4492 (or even updates
  RFC4492). Isn't this supposed to supercede that document?
- Curve25519 and Curve448 are called "X25519" and "X448" in the
  (looks to be imminently sent to RFC editor) draft.
- In public key validation, X448 resists invalid point attacks
  the same way as X25519 (of course, all bits of X448 public
  keys can be nonzero, as the value can get to almost 256^56).
- The document still does have restrictions on algorithms used
  to sign the certificate. AFAIK, TLS 1.2 (RFC5246) lifted all
  such restrictions (at least sections 2.2, 5.3 and 5.6).
- Do we want to keep ECDH client keys? Those were used in one
  recent exploit against one implementation of TLS. And using
  one destroys forward secrecy anyway.
- Is this document meant to also include the CFRG signatures
  work? The interfaces to functions are already known.


-Ilari

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

[TLS] [Editorial Errata Reported] RFC5246 (4507)

[RFC Errata System]

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

--
Type: Editorial
Reported by: Benjamin Kaduk 

Section: 7.4.1.2

Original Text
-
After sending the ClientHello message, the client waits for a
ServerHello message.  Any handshake message returned by the server,
except for a HelloRequest, is treated as a fatal error.


Corrected Text
--
After sending the ClientHello message, the client waits for a
ServerHello message.  Any other handshake message returned by the
server, except for a HelloRequest, is treated as a fatal error.

Notes
-
A ServerHello received after a ClientHello should not be treated as a fatal 
error.

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

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

Re: [TLS] Version in record MAC

[Martin Thomson]

On 19 October 2015 at 09:28, Eric Rescorla  wrote:
>  1. Don't MAC the version at all.
>  2. MAC the negotiated version (which should be clear at
> this point).


3. Nothing

The version is implicit in the key derivation (yeah, there are lots of
rounds of HMAC between, but it's there.

The sequence number is fed into the nonce.

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

Re: [TLS] Version in record MAC

[Eric Rescorla]

On Mon, Oct 19, 2015 at 11:06 AM, Martin Thomson 
wrote:

> On 19 October 2015 at 09:28, Eric Rescorla  wrote:
> >  1. Don't MAC the version at all.
> >  2. MAC the negotiated version (which should be clear at
> > this point).
>
>
> 3. Nothing
>
> The version is implicit in the key derivation (yeah, there are lots of
> rounds of HMAC between, but it's there.
>
> The sequence number is fed into the nonce.
>

How is this different from #1?

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

Re: [TLS] Version in record MAC

[Martin Thomson]

On 19 October 2015 at 11:12, Eric Rescorla  wrote:
>
>
> On Mon, Oct 19, 2015 at 11:06 AM, Martin Thomson 
> wrote:
>>
>> On 19 October 2015 at 09:28, Eric Rescorla  wrote:
>> >  1. Don't MAC the version at all.
>> >  2. MAC the negotiated version (which should be clear at
>> > this point).
>>
>>
>> 3. Nothing
>>
>> The version is implicit in the key derivation (yeah, there are lots of
>> rounds of HMAC between, but it's there.
>>
>> The sequence number is fed into the nonce.
>
>
> How is this different from #1?

#1 implies the sequence number is covered by the MAC.

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

Re: [TLS] Version in record MAC

[Eric Rescorla]

On Mon, Oct 19, 2015 at 11:13 AM, Martin Thomson 
wrote:

> On 19 October 2015 at 11:12, Eric Rescorla  wrote:
> >
> >
> > On Mon, Oct 19, 2015 at 11:06 AM, Martin Thomson <
> martin.thom...@gmail.com>
> > wrote:
> >>
> >> On 19 October 2015 at 09:28, Eric Rescorla  wrote:
> >> >  1. Don't MAC the version at all.
> >> >  2. MAC the negotiated version (which should be clear at
> >> > this point).
> >>
> >>
> >> 3. Nothing
> >>
> >> The version is implicit in the key derivation (yeah, there are lots of
> >> rounds of HMAC between, but it's there.
> >>
> >> The sequence number is fed into the nonce.
> >
> >
> > How is this different from #1?
>
> #1 implies the sequence number is covered by the MAC.
>

Yeah, I think that's riding the nonce far too hard.

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

Re: [TLS] Version in record MAC

[Martin Thomson]

On 19 October 2015 at 11:17, Eric Rescorla  wrote:
> Yeah, I think that's riding the nonce far too hard.

On what basis?  Any change in the nonce will cause the record
decryption to fail.  That's the property we're looking for here, isn't
it?

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

[TLS] I-D Action: draft-ietf-tls-cached-info-20.txt

[internet-drafts]

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   : Transport Layer Security (TLS) Cached Information 
Extension
Authors : Stefan Santesson
  Hannes Tschofenig 
Filename: draft-ietf-tls-cached-info-20.txt
Pages   : 17
Date: 2015-10-19

Abstract:
   Transport Layer Security (TLS) handshakes often include fairly static
   information, such as the server certificate and a list of trusted
   certification authorities (CAs).  This information can be of
   considerable size, particularly if the server certificate is bundled
   with a complete certificate chain (i.e., the certificates of
   intermediate CAs up to the root CA).

   This document defines an extension that allows a TLS client to inform
   a server of cached information, allowing the server to omit already
   available information.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-cached-info-20

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


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/

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

Re: [TLS] Version in record MAC

[Russ Housley]

Option #2 seems fine to me.

Russ


On Oct 19, 2015, at 12:28 PM, Eric Rescorla wrote:

> Folks,
> 
> https://github.com/tlswg/tls13-spec/issues/278
> 
> The additional data field presently includes the version:
> 
>   additional_data = seq_num + TLSPlaintext.record_version
> 
> However, TLSPlaintext.record_version is now always {3, 1}, so
> this is redundant. There seem to be two primary options here:
> 
>  1. Don't MAC the version at all.
>  2. MAC the negotiated version (which should be clear at
> this point).
> 
> I could go either way on this (slightly leaning towards #2) but
> the current thing seems silly.
> 
> -Ekr
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

[TLS] Offline configurations

[Martin Thomson]

This is an exploration of what it might take to bootstrap 0RTT without
a prior TLS connection.

https://tools.ietf.org/html/draft-thomson-tls-offline-config-00

There are two important lessons I've learned from this:
  1. authentication is important (and hard to get right)
  2. TLS implicitly includes a bunch of stuff in the server
configuration, these are explicitly manifest here as extensions to the
server configuration

On this latter point, I believe that this identifies the additional
state that needs to be considered as part of a server configuration by
clients.  These are implicitly included in the regular 0RTT setup and
don't get entered into the 0RTT handshake hash.  I don't think that's
a problem, but it might be worth thinking about some.

For instance, if a CertificateRequest alters how the client behaves
for a second connection, should that be covered by the handshake hash
for that connection?  Similar concerns might apply to cipher suite
selection and supported groups.

For an offline configuration, the entire configuration is included
both under a signature and as part of the handshake transcript for the
new connection.  That means that the certificate is covered twice.

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

Re: [TLS] Version in record MAC

[Adam Langley]

On Monday, October 19, 2015, Martin Thomson 
wrote:

> On 19 October 2015 at 11:17, Eric Rescorla >
> wrote:
> > Yeah, I think that's riding the nonce far too hard.
>
> On what basis?  Any change in the nonce will cause the record
> decryption to fail.  That's the property we're looking for here, isn't
> it?


I don't believe that there's any reason to include the sequence number in
the AD input of an AEAD. I think that an empty AD for TLS would be fine now
that the content type is encrypted. (Not that I deeply care either way.)


Cheers

AGL


-- 
Adam Langley a...@imperialviolet.org https://www.imperialviolet.org
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] FW: New Version Notification for draft-zhou-tls-server-redirect-00.txt

[Zhouqian (Cathy)]

Dear all,
This is a new document we have submitted on the TLS extension for server 
redirect. It aims to solve the problems in some applications, e.g., HTTPS 
redirect. 
The "Hello Extensions" message is extended and a new TLS handshake packet is 
defined to support this kind of applications. 
Your comments are welcome.

Best Regards,
Cathy Zhou


> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Monday, October 19, 2015 5:25 PM
> To: Gaohongliang; Gaohongliang; Zhouqian (Cathy); Zhouqian (Cathy)
> Subject: New Version Notification for draft-zhou-tls-server-redirect-00.txt
> 
> 
> A new version of I-D, draft-zhou-tls-server-redirect-00.txt
> has been successfully submitted by Cathy Zhou and posted to the IETF
> repository.
> 
> Name: draft-zhou-tls-server-redirect
> Revision: 00
> Title:The Transport Layer Security (TLS) Extension to Support 
> Server
> Redirect
> Document date:2015-10-19
> Group:Individual Submission
> Pages:6
> URL:
> https://www.ietf.org/internet-drafts/draft-zhou-tls-server-redirect-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-zhou-tls-server-redirect/
> Htmlized:   https://tools.ietf.org/html/draft-zhou-tls-server-redirect-00
> 
> 
> Abstract:
>In some applications, e.g., Hypertext Transfer Protocol Secure
>(HTTPS) visit, a client request needs to be redireted to the
>operator's web server for authentication or overdue processing.  This
>specification defines a new extension of TLS handshake protocol
>[RFC5246] to transmit the redirect Uniform/Universal Resource Locator
>(URL) for HTTPS applications.
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat

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