Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead

[Ilari Liusvaara]

On Mon, Nov 07, 2016 at 10:16:13PM -0500, Daniel Migault wrote:
> Hi,
> 
> The current draft is only considering TLS1.2. TLS1.3 is only mentioned for
> advocating AEAD.
> 
> Do you think we should add text that details how to proceed with TLS1.3 ?
> If so what do you think of the following text ?
 
That is, I think the dependency on TLS 1.3 should be downgraded to
informative (unless that has already been done).

> 
> Yours,
> Daniel
> 
>The assigned code points are only expected to be used for TLS1.2.
>TLS1.3 does not follow the same name convention.  Instead TLS1.3
>cipher suites are designated according to the AEAD suite as well as
>the hash function used.  The current combination of AEAD algorithms
>and Hash fucntion are already defined in TLS.1.3 so there is no need
>to add additional cipher suites for TLS1.3.

Seems reasonable.

>Instead, in order to used the following ECDHE_PSK authentication
>method.  TLS1.3 uses a combination of the "key_share" and
>"psk_key_exchange_modes" extentions. "psk_key_exchange_modes"
>extension sets its mode to psk_dhe_ke.  The "key_share" extention
>contains a KeyShareEntry structure that carries the ECDHE parameters.
> 

I think 'used the following' -> 'use the' and first period should be
comma.


-Ilari

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

Re: [TLS] (strict) decoding of legacy_record_version?

[Martin Thomson]

On 8 November 2016 at 14:01, Brian Smith  wrote:
> Since this field isn't included in the additional_data of the AEAD in TLS
> 1.3 any more, it isn't authenticated. That means an active MitM can use this
> to transport up to 2 bytes of information hop-to-hop if the receiver doesn't
> check it. That seems like a good reason to check it, and also to check
> TLSCiphertext.opaque_type is application_data. Assuming this is the reason,
> the reasoning should be explicitly called out because it is non-obvious.

I don't think that's the primary reason.  A MitM could use TCP headers
to carry other bits if they wanted.

The main reason I can think of is ecosystem health.  If you permit
junk, then you get junk.  Then you can't use the field any more
because it contains junk.

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

Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

[Martin Thomson]

I don't understand this.  I have no problems with a recommendation
(i.e., SHOULD), but you will find that many implementations will not
comply with these requirements when pushed.

On 8 November 2016 at 14:09, Daniel Migault  wrote:
>The cipher suites defined in this document are based on the AES-GCM
>and AES-CCM Authenticated Encryption with Associated Data (AEAD)
>algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, AEAD_AES_128_CCM, and
>AEAD_AES_256_CCM defined in [RFC5116], AEAD_AES_128_CCM_8 and
>AEAD_AES_256_CCM_8 defined in [RFC6655].
>
>For the AES-128 cipher suites, the TLS Pseudorandom Function (PRF)
>with SHA-256 as the hash function SHALL be used and Clients and
>Servers MUST NOT negotiate curves of less than 255 bits.

This is two statements:

1. The PRF hash for these suites is SHA-256.  That's not a
requirement, you just define it, no 2119 language.

2. Using a weak key negotiation means that your key negotiation is the
weak point.  Here, my preference is to avoid stating a requirement,
but that's only because it's very hard to get right.  Otherwise, use a
SHOULD and copy from HTTP/2:

"When choosing these cipher suites, servers SHOULD select a key
exchange that is at least 2048 bits for cipher suites that use
ephemeral finite field Diffie-Hellman (DHE) [TLS12] and 224 bits for
cipher suites that use ephemeral elliptic curve Diffie-Hellman (ECDHE)
[RFC4492]."

Getting into the exact number of bits is a bit self-defeating.  4Q
isn't 255 bits.  25519 isn't either if you count them all.  Both seem
to be more than adequate in strength though.

>For the AES-256 cipher suites, the TLS PRF with SHA-384 as the hash
>function SHALL be used and Clients and Servers MUST NOT negotiate
>curves of less than 384 bits.

As above, but with bigger numbers.

>TLS enable curve negotiation but not for code point.  This makes
>restrictions on code points hard to implement.  As a result Endpoints
>MAY treat negotiation of key sizes smaller than the lower limits as a
>connection error of type insufficient_security(71) for TLS1.2 and
>TLS1.3.

Nits: 'enables'; there is a space between "TLS" and the version number.

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

Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead

[Daniel Migault]

Hi,

The current draft is only considering TLS1.2. TLS1.3 is only mentioned for
advocating AEAD.

Do you think we should add text that details how to proceed with TLS1.3 ?
If so what do you think of the following text ?

Comments are welcome!


Yours,
Daniel

   The assigned code points are only expected to be used for TLS1.2.
   TLS1.3 does not follow the same name convention.  Instead TLS1.3
   cipher suites are designated according to the AEAD suite as well as
   the hash function used.  The current combination of AEAD algorithms
   and Hash fucntion are already defined in TLS.1.3 so there is no need
   to add additional cipher suites for TLS1.3.

   Instead, in order to used the following ECDHE_PSK authentication
   method.  TLS1.3 uses a combination of the "key_share" and
   "psk_key_exchange_modes" extentions. "psk_key_exchange_modes"
   extension sets its mode to psk_dhe_ke.  The "key_share" extention
   contains a KeyShareEntry structure that carries the ECDHE parameters.



On Tue, Oct 18, 2016 at 12:31 PM, Ilari Liusvaara 
wrote:

> On Tue, Oct 18, 2016 at 04:22:59PM +, Xiaoyin Liu wrote:
> > Why does this draft normatively depend on TLS 1.3, even if the
> > cipher suites defined in this draft use the old syntax, which
> > TLS 1.3 no longer uses?
>
> I don't see any reason why it would normatively depend.
>
> If it claims to be so, IMO that is a mistake and such reference should
> be dropped (TLS 1.3 won't be able to use these anyway), or made in-
> formative, in case the text wants to make a passing reference to TLS
> 1.3.
>
>
> -Ilari
>
> ___
> 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] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

[Daniel Migault]

Hi,

Please find the text I propose. Let me know if you have any comment
regarding the proposed text. Unless I receive comment on it, the text will
be publish as soon as draft submission is possible.

Yours,
Daniel

   The cipher suites defined in this document are based on the AES-GCM
   and AES-CCM Authenticated Encryption with Associated Data (AEAD)
   algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, AEAD_AES_128_CCM, and
   AEAD_AES_256_CCM defined in [RFC5116], AEAD_AES_128_CCM_8 and
   AEAD_AES_256_CCM_8 defined in [RFC6655].

   For the AES-128 cipher suites, the TLS Pseudorandom Function (PRF)
   with SHA-256 as the hash function SHALL be used and Clients and
   Servers MUST NOT negotiate curves of less than 255 bits.

   For the AES-256 cipher suites, the TLS PRF with SHA-384 as the hash
   function SHALL be used and Clients and Servers MUST NOT negotiate
   curves of less than 384 bits.

   TLS enable curve negotiation but not for code point.  This makes
   restrictions on code points hard to implement.  As a result Endpoints
   MAY treat negotiation of key sizes smaller than the lower limits as a
   connection error of type insufficient_security(71) for TLS1.2 and
   TLS1.3.





On Mon, Oct 24, 2016 at 11:22 AM, Daniel Migault <
daniel.miga...@ericsson.com> wrote:

> Hi,
>
> My understanding is that the updated version should not introduce any
> profile. Am I correct ?
>
> BR,
> Daniel
>
> On Mon, Oct 17, 2016 at 1:16 PM, Daniel Migault <
> daniel.miga...@ericsson.com> wrote:
>
>> Hi,
>>
>> I am not very clear on how to update the text of the draft. The problem
>> seems to me that code point restriction are hard to implement. As a result,
>> the session is aborted with - insufficient_security(71) or equivalent -
>> when the code point does not match the security strength. I am encline to
>> think that we should also provide some profiles that achieve 128/256 bit
>> security. These profiles may be described in this document or in another
>> document more related to cryptographic recommendation. What would be the
>> most appropriated way to move forward ?
>>
>> BR,
>> Daniel
>>
>>
>>
>> On Sun, Oct 9, 2016 at 2:59 AM, John Mattsson > > wrote:
>>
>>> Hi Dan, Sean, Nikos,
>>>
>>> First, let me state that I think requiring 128-bit key management for
>>> AES-128 is quite reasonable.
>>>
>>> HTTP/2 [RFC7540] also has some related text in Section 9.2.1 that applies
>>> when TLS is used for HTTP/2. "Endpoints MAY treat negotiation of key
>>> sizes
>>> smaller than the lower limits as a connection error (Section 5.4.1
>>> ) of type
>>> INADEQUATE_SECURITY."
>>>
>>>
>>> I think this is a question for TLS in general,
>>> draft-ietf-tls-ecdhe-psk-aead should just follow what the TLS WG decides
>>> as the general way forward. Wether that is MAY/SHOULD/SHALL treat groups
>>> with insufficient security as an error.
>>>
>>> I think the real problem here are TLS libraries supporting 1024 MODP and
>>> 160 ECC at all, support for these should have been removed before 2010.
>>> Nikos [0] recommends a RCF forbidding weak elliptic curves from TLS 1.2
>>> (i.e. WeakDH DieDieDie!!!). I think this is a great idea and much better
>>> than bundling it into a code-point assignment RFC. (My current plans for
>>> the next update of 3GPP’s TLS and DTLS profiles is simply to forbid
>>> support of anything weaker than 2048 MODP and 255-bit ECC).
>>>
>>> [0]. https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrl
>>> BKvZs0BOQ
>>>
>>>
>>>
>>> Cheers,
>>> John
>>>
>>>
>>> On 11/07/16 22:26, "TLS on behalf of Dan Harkins" >> on
>>> behalf of dhark...@lounge.org> wrote:
>>>
>>> >
>>> >  I'm glad I have to opportunity to make you happy Sean :-)
>>> >
>>> >On Mon, July 11, 2016 7:40 am, Sean Turner wrote:
>>> >> I think I can take this bit:
>>> >>
>>> >> On Jul 10, 2016, at 06:51, Peter Dettman
>>> >>
>>> >> wrote:
>>> >>>
>>> >>> I'm also curious whether there is a precedent in other RFCs for an
>>> >>> explicit minimum curve bits, or perhaps a de facto implementer's
>>> rule?
>>> >>
>>> >> I'd be happy to be wrong here. but to my knowledge no there's not been
>>> >> an explicit minimum for curve bits.  There have however been similar
>>> (at
>>> >> least in my non-cryptographer mind) for RSA key sizes so if we wanted
>>> to
>>> >> define an explicit minimum curve bits then we could.
>>> >
>>> >  draft-ietf-tls-pwd-07 includes a RECOMMENDED practice of ensuring
>>> >the curves used provide commensurate strength with the ciphersuite
>>> >negotiated. Section 10, "Implementation Considerations", says:
>>> >
>>> >   It is RECOMMENDED that implementations take note of the strength
>>> >   estimates of particular groups and to select a ciphersuite providing
>>> >   commensurate security with its hash and encryption algorithms.  A
>>> >   ciphersuite whose encryption algorithm has a keylength less than the
>>> >   strength estimate, or whose hash algorithm has a blocksize that is
>>> >

Re: [TLS] (strict) decoding of legacy_record_version?

[Brian Smith]

David Benjamin  wrote:

> Once you've gotten as far as to switch to TLSCiphertext, I don't see a
> reason not to enforce. Keying on versions is problematic (which is why we
> avoided a transition to enforcement), but keying on whether the record is
> encrypted seems fine. I think it just didn't occur to us to base it on
> that. :-)
>

Since this field isn't included in the additional_data of the AEAD in TLS
1.3 any more, it isn't authenticated. That means an active MitM can use
this to transport up to 2 bytes of information hop-to-hop if the receiver
doesn't check it. That seems like a good reason to check it, and also to
check TLSCiphertext.opaque_type is application_data. Assuming this is the
reason, the reasoning should be explicitly called out because it is
non-obvious.

If that isn't a reason to do the check, then I don't think there's any
reason to mandate that implementations do it.

Cheers,
Brian
-- 
https://briansmith.org/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] (strict) decoding of legacy_record_version?

[Eric Rescorla]

On Mon, Nov 7, 2016 at 4:04 PM, David Benjamin 
wrote:

> On Mon, Nov 7, 2016 at 6:50 PM Benjamin Kaduk  wrote:
>
> (was Re: [TLS] PR#625: Change alert requirements)
>
> Digging up an old sub-thread...
>
> On 09/20/2016 08:03 AM, Eric Rescorla wrote:
>
> in Record Layer there's the following text:
>
> legacy_record_version : This value MUST be set to { 3, 1 } for all
> records. This field is deprecated and MUST be ignored for all purposes.
>
> in Record Layer Protection there's the following text:
>
> legacy_record_version : The legacy_record_version field is identical to
> TLSPlaintext.legacy_record_version and is always { 3, 1 }. Note that
> the
> handshake protocol including the ClientHello and ServerHello messages
> authenticates the protocol version, so this value is redundant.
>
> which doesn't say if the version can be ignored completely (skipped while
> parsing) or if it should be verified.
>
>
> These are different fields.
>
>
> There's still the question of whether the receiver should enforce 0x0301
> in either/both cases.
> OpenSSL is implementing and seems to be reading the spec that it MUST be
> ignored (even though I guess strictly speaking that MUST only applies
> before record protection is engaged); if I'm doing my code survey
> correctly, Mint and NSS always enforce, and Boring only checks the first
> octet.
>
> Is there a reason to not do strict enforcement?
>
>
> Before you know the version, it is not safe to enforce. Prior versions of
> TLS did not pin down the value. (BoringSSL checks the first octet because
> OpenSSL did so, and it's vaguely nice to sanity-check on the first few
> bytes of data in the protocol.)
>
> Immediately after you know the version, enforcement is also problematic.
> Alerts sent in response to a ClientHello or ServerHello have somewhat
> ambiguous versions. One side may have decided the version is set while the
> other has not. Prior to 1.3, the record version needs to be set to the
> protocol version (or you break pre-1.3 enforcing implementations). But this
> means a receiver which enforces will fail to parse the alert. Not the end
> of the world, but weird.
>
> Once you've gotten as far as to switch to TLSCiphertext, I don't see a
> reason not to enforce. Keying on versions is problematic (which is why we
> avoided a transition to enforcement), but keying on whether the record is
> encrypted seems fine. I think it just didn't occur to us to base it on
> that. :-)
>

As you say, this is what NSS does. There's no legit reason for a TLS 1.3
encrypted record to have the wrong version number here, so I suggest
changing the text.

-Ekr


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

Re: [TLS] (strict) decoding of legacy_record_version?

[David Benjamin]

On Mon, Nov 7, 2016 at 6:50 PM Benjamin Kaduk  wrote:

(was Re: [TLS] PR#625: Change alert requirements)

Digging up an old sub-thread...

On 09/20/2016 08:03 AM, Eric Rescorla wrote:

in Record Layer there's the following text:

legacy_record_version : This value MUST be set to { 3, 1 } for all
records. This field is deprecated and MUST be ignored for all purposes.

in Record Layer Protection there's the following text:

legacy_record_version : The legacy_record_version field is identical to
TLSPlaintext.legacy_record_version and is always { 3, 1 }. Note that the
handshake protocol including the ClientHello and ServerHello messages
authenticates the protocol version, so this value is redundant.

which doesn't say if the version can be ignored completely (skipped while
parsing) or if it should be verified.


These are different fields.


There's still the question of whether the receiver should enforce 0x0301 in
either/both cases.
OpenSSL is implementing and seems to be reading the spec that it MUST be
ignored (even though I guess strictly speaking that MUST only applies
before record protection is engaged); if I'm doing my code survey
correctly, Mint and NSS always enforce, and Boring only checks the first
octet.

Is there a reason to not do strict enforcement?


Before you know the version, it is not safe to enforce. Prior versions of
TLS did not pin down the value. (BoringSSL checks the first octet because
OpenSSL did so, and it's vaguely nice to sanity-check on the first few
bytes of data in the protocol.)

Immediately after you know the version, enforcement is also problematic.
Alerts sent in response to a ClientHello or ServerHello have somewhat
ambiguous versions. One side may have decided the version is set while the
other has not. Prior to 1.3, the record version needs to be set to the
protocol version (or you break pre-1.3 enforcing implementations). But this
means a receiver which enforces will fail to parse the alert. Not the end
of the world, but weird.

Once you've gotten as far as to switch to TLSCiphertext, I don't see a
reason not to enforce. Keying on versions is problematic (which is why we
avoided a transition to enforcement), but keying on whether the record is
encrypted seems fine. I think it just didn't occur to us to base it on
that. :-)

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

[TLS] (strict) decoding of legacy_record_version?

[Benjamin Kaduk]

(was Re: [TLS] PR#625: Change alert requirements)

Digging up an old sub-thread...

On 09/20/2016 08:03 AM, Eric Rescorla wrote:
>
> in Record Layer there's the following text:
>
> legacy_record_version : This value MUST be set to { 3, 1 } for all
> records. This field is deprecated and MUST be ignored for all
> purposes.
>
> in Record Layer Protection there's the following text:
>
> legacy_record_version : The legacy_record_version field is
> identical to
> TLSPlaintext.legacy_record_version and is always { 3, 1 }.
> Note that the
> handshake protocol including the ClientHello and ServerHello
> messages
> authenticates the protocol version, so this value is redundant.
>
> which doesn't say if the version can be ignored completely
> (skipped while
> parsing) or if it should be verified.
>
>
> These are different fields.
>

There's still the question of whether the receiver should enforce 0x0301
in either/both cases.
OpenSSL is implementing and seems to be reading the spec that it MUST be
ignored (even though I guess strictly speaking that MUST only applies
before record protection is engaged); if I'm doing my code survey
correctly, Mint and NSS always enforce, and Boring only checks the first
octet.

Is there a reason to not do strict enforcement?

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

Re: [TLS] supported_versions question

[Brian Smith]

Kurt Roeckx  wrote:

> So I guess you're also saying that a server that implements TLS
> 1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should
> ignore the supported_versions even when it knows about it?
>
> I guess I have same questions but with only TLS 1.3 disabled, to
> be sure when we need to look at it.


>From the perspective of the application developer, if I've disabled TLS 1.3
then I'd rather not  have any TLS 1.3 behavior implemented; I'd rather have
the implementation behave the same as before it supported TLS 1.2,
more-or-less. That means in particular that supported_versions should be
ignored if TLS 1.3 and later have been disabled. Put another way, if TLS
1.2 is the maximum version the application has enabled, then the TLS 1.3
specification in total is irrelevant and only RFC 5246 (and perhaps
earlier) apply, and those specifications don't specify supported_versions.

Consider in particular that an application might want to disable (or avoid
enabling) TLS 1.3 to avoid some problem (perhaps a security problem) with
supported_versions processing. It would be bad to not have any way of
disabling supported_versions processing, and it doesn't seem good from a
usability standpoint to have a separate nob to control it.

Cheers,
Brian
-- 
https://briansmith.org/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls