Re: [TLS] [kitten] Fwd: Last Call: (Channel Bindings for TLS 1.3) to Proposed Standard

[Alexey Melnikov]

Hi Jonathan,

On 05/11/2021 15:34, Jonathan Hoyland wrote:

Hi Simo,

As I said in my email to Sam, my language here was sloppy, I meant 
that the channel binding is included in the key derivation process, 
and thus the output keys will be related to each other.
The term channel bindings has two different meanings using in very 
similar contexts, which leads to great confusion and is why I prefer 
the term compound authentication (see Chapter 4.4 of my thesis) 
. 

A channel binding is a "name" of a channel as you say, but it is also 
used to mean using one channel to authenticate another.
Very specifically if channel `a` is bound to channel `b` then that 
means that if channel `b` is securely authenticated then channel `a` 
was formed honestly (i.e. even if all of the long term key material 
for channel `a` has been leaked, I can be sure that my channel `a` 
peer is the same actor as my channel `b` peer.)


Channel bindings that aren't bound to a specific session are less 
secure than ones that are, so yes, you can use them, but that doesn't 
mean they have the security properties you need.
The purpose of binding a protocol to an underlying TLS session is to 
leverage some of the security guarantees offered by the TLS layer.
If those guarantees are never necessary because the over-the-top 
protocol is always perfectly secure, just run the protocol on the wire 
and drop the TLS complication.
If those guarantees are at least sometimes necessary then you need to 
securely bind the two channels together.


Channel binding does more than simply guarantee that the messages were 
the same, it also guarantees that the identity of the actors at each 
layer remains the same, and that the keys derived in each layer match.
With an appropriately designed channel binding you can use TLS's 
protection against MITM attacks to protect insecure protocols run over 
the top.
Having now looked at SCRAM a little bit, using the TLS channel binding 
guarantees that some malicious server isn't passing the client's 
messages off to another server and performing a malicious 
authentication there.
Using a unique string from SCRAM means that messages from some other 
protocol won't be compatible.
If you don't require a unique string I could write a new protocol 
SCRAM++ with cross-compatible messages, but different security 
guarantees, and use that to compromise SCRAM clients.
Obviously that's a patently malicious example, but it's perfectly 
possible that some new version of SCRAM produces messages that an old 
version of SCRAM misinterprets.
It's even highly likely that a server that supports old versions of 
SCRAM for backwards compatibility would use the same key material for 
all versions.


I've been reading this exchange and I still struggle to understand what 
do you think the issue is. But more importantly, what are the possible 
fixes? If you can propose specific modifications to how 
draft-ietf-kitten-tls-channel-bindings-for-tls13 should be constructing 
channel binding for TLS 1.3, then maybe we can make some progress on this.


Best Regards,

Alexey


Requiring a unique string makes the messages totally unrelated.

I don't find the arguments "It's always been insecure in the past" or 
"We have bad APIs" especially compelling.


Regards,

Jonathan


On Fri, 29 Oct 2021 at 14:55, Simo Sorce > wrote:


Hi Jonathan,

On Thu, 2021-10-28 at 18:46 +0100, Jonathan Hoyland wrote:
> Hi Ruslan,
>
> Yes, two distinct TLS connections having the same exporter key
would be
> really bad, but I'm specifically talking about two runs of some
protocol
> bound to a single TLS session.
> A single TLS session will return the same key (modulo rekeying,
resumption
> etc.) if you call the Exporter API with the same label.
> This means that the channel bindings it produces, which will
then be used
> to derive the keys of the higher layer protocol, will produce
related keys.
>
> The key reason for making the binding retrieval context-specific
is to make
> sure that different protocols run in the same TLS session
produce disjoint
> keys.

Note, Channel Bindings are *not* a key and should never used as such,
so I think you are using a false premise here.
Channel Bindings are, at most, a unique value associated with a
session
(keep in mind that often Channel Bindings do not even bind to a
specific session, see 'tls-server-end-point' which is used in
preference in many cases within HTTPS endpoints because of the way
server termination is built in some scalable architectures).

> When someone tries to copy a message from a SCRAM handshake into
some
> GSS-API run on a single TLS connection I want to be sure that it
will be
> rejected, without having to understand exactly how every version
of SCRAM
> and 

Re: [TLS] TLS Export Channel Binding

[Alexey Melnikov]

Hi Sam,

On 04/05/2020 15:39, Sam Whited wrote:
I have updated the draft with these changes: 
https://datatracker.ietf.org/doc/draft-whited-tls-channel-bindings-for-tls13/ 



In the Introduction of your draft you are referencing RFC 5705, which 
can't be used with TLS 1.3. Instead you should reference Section 7.5 of 
RFC 8446.


Best Regards,

Alexey

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

Re: [TLS] TLS Export Channel Binding

[Alexey Melnikov]

Hi Sam,

On 04/05/2020 15:39, Sam Whited wrote:

I'm still not entirely clear if this would be a better draft for the
KITTEN WG or this one. If we update the SCRAM RFCs I think it may be
better to go through KITTEN, but I'm not sure that they'll want to take
that work on. I'll ask. Any advice here would be appreciated since I
know almost nothing about IETF policy or procedures.


IETF doesn't really have rules about situations like this.

I think doing this in KITTEN makes more sense, as long as feedback is 
asked on the TLS mailing list. KITTEN is more likely to have interest to 
drive this work to completion. Having said that, if there is strong 
interest in getting this done in TLS, that would be fine with me.


Best Regards,

Alexey

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

Re: [TLS] TLS Export Channel Binding

[Alexey Melnikov]

Hi Jonathan,

On 04/05/2020 14:14, Jonathan Hoyland wrote:

Hi Sam,

If you wanted to use a SCRAM based SASL auth then you could pick 
`p=SCRAM-SHA256-PLUS`, or any other very specific IANA-registered 
string, and update the SCRAM RFC to require that string with TLS 1.3.
You actively don't want for the same channel binding to be an input to 
multiple different protocols (or even the same protocol but with 
different parameters) because it opens the door to confusion attacks.


Can you elaborate on what you are trying to protect from?

Historically channel bindings were constant once TLS negotiation was 
complete (they could change if TLS renegotiation happens). So they never 
depended on what was sent over the protocol above TLS.


I've only skimmed the SCRAM RFC, but it might make sense to include 
`client-first-message` and `server-first-message` as context to the 
exporter interface, because it seems that the channel binding isn't 
needed until the `client-final-message`.


"the channel binding isn't needed until the `client-final-message`" is 
correct. Can you elaborate on what is problematic with this?


The idea is to use the transcript to bind the channel binding to the 
negotiation of SCRAM parameters, and thus allow you to define a single 
"TLS-SASL-SCRAM" string (or whatever makes sense), rather than have 
one for each possible set of parameters.
Obviously you'd need to think some more about whether that was 
actually secure, but at first glance it seems like a reasonable approach.


Channel bindings that bind both the underlying channel and the 
higher-level protocol make more sense to me that channel bindings that 
only identify the underlying channel, because you don't have to worry 
about the (potentially pathological) behaviours of other users of the 
binding.



Best Regards,

Alexey


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

Re: [TLS] Alexey Melnikov's No Objection on draft-ietf-tls-certificate-compression-08: (with COMMENT)

[Alexey Melnikov]

On Thu, Dec 19, 2019, at 11:56 PM, Victor Vasiliev wrote:
> I believe the intention was to refer to Section 17 of RFC 8447 
> <https://tools.ietf.org/html/rfc8447#section-17>, as it contains details of 
> how Specification Required works with TLS-related registrations. I've sent 
> out a PR to clarify that 
> <https://github.com/tlswg/certificate-compression/pull/32/files>.
Great, thank you.

> 
> On Mon, Dec 16, 2019 at 8:28 AM Alexey Melnikov via Datatracker 
>  wrote:
>> Alexey Melnikov has entered the following ballot position for
>>  draft-ietf-tls-certificate-compression-08: 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-certificate-compression/
>> 
>> 
>> 
>>  --
>>  COMMENT:
>>  --
>> 
>>  I support publication of this document. One small question:
>> 
>>  7.3. Registry for Compression Algorithms
>> 
>>  The procedures for requesting values in the Specification Required
>>  space are specified in [RFC8447].
>> 
>>  RFC 8447 doesn't define "Specification Required", RFC 8126 does. Is there a
>>  more specific section of RFC 8447 that you can point to, as it is unclear 
>> to me
>>  which parts of RFC 8447 apply here.
>> 
>> 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Alexey Melnikov's No Objection on draft-ietf-tls-certificate-compression-08: (with COMMENT)

[Alexey Melnikov via Datatracker]

Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-certificate-compression-08: 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-certificate-compression/



--
COMMENT:
--

I support publication of this document. One small question:

7.3.  Registry for Compression Algorithms

   The procedures for requesting values in the Specification Required
   space are specified in [RFC8447].

RFC 8447 doesn't define "Specification Required", RFC 8126 does. Is there a
more specific section of RFC 8447 that you can point to, as it is unclear to me
which parts of RFC 8447 apply here.


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

[TLS] Alexey Melnikov's No Objection on draft-ietf-tls-sni-encryption-06: (with COMMENT)

[Alexey Melnikov via Datatracker]

Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-sni-encryption-06: 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-sni-encryption/



--
COMMENT:
--

Thank you for this document.

One small thing:

Please use RFC 8314 instead of RFC 2595 as a reference for IMAP over TLS.


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

[TLS] Alexey Melnikov's Yes on draft-ietf-tls-grease-03: (with COMMENT)

[Alexey Melnikov via Datatracker]

Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-grease-03: Yes

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-grease/



--
COMMENT:
--

I am looking forward to this being deployed.

TLS 1.2 should be a Normative reference, despite being obsolete, as some of the
requirements only apply to TLS 1.2.


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

Re: [TLS] Alexey Melnikov's No Objection on draft-ietf-tls-iana-registry-updates-04: (with COMMENT)

[Alexey Melnikov]

Hi Benjamin,

On Tue, Apr 3, 2018, at 10:50 PM, Benjamin Kaduk wrote:
> I will trim the purely editorial stuff, as the authors should be
> able to handle that (and have already started, since the cipher
> suite/hash+signature algorithm thing was already noted).
> 
> On Tue, Apr 03, 2018 at 09:56:16AM -0700, Alexey Melnikov wrote:
> > Alexey Melnikov has entered the following ballot position for
> > draft-ietf-tls-iana-registry-updates-04: No Objection
> > 
> > --
> > COMMENT:
> > --
> > 
> > I support the idea behind this document. I have a few minor issues which I
> > would like to discuss before recommending its approval:
> > 
> > 1) In several places:
> > 
> > "IESG action is REQUIRED for a Yes->No transition."
> > 
> > Firstly, this should be "IESG Approval", not "IESG action" (according to RFC
> > 8126).
> 
> Sure, let's use the right term.
> 
> > Secondly, are you saying that this is the ONLY way to transition from Yes to
> > No? Surely, Standards Action should also be allowed in case there is no 
> > rush?
> > Besides IESG is likely to prefer a document explaining the transition 
> > anyway.
> 
> Is IESG Approval mutaully exclusive with Standards-Action?
> My reading of 8126's:
> 
>New assignments may be approved by the IESG.  Although there is no
>requirement that the request be documented in an RFC, the IESG has
>the discretion to request documents or other supporting materials on
>a case-by-case basis.
> 
> is that a standards-track document could include an "IESG
> Considerations" section that requests the IESG to effect the
> transition.

I suppose this can work, but typically "IESG Approval" is used for exception 
cases, where here it is always used. I think "IETF Consensus or IESG Approval" 
is more natural way of phrasing the intent.

> That is to say, while I have no objection to your proposed (idea
> for) text, I also am not sure that it is qualitatively different
> from the current text.

Best Regards,
Alexey

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

[TLS] Alexey Melnikov's No Objection on draft-ietf-tls-iana-registry-updates-04: (with COMMENT)

[Alexey Melnikov]

Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-iana-registry-updates-04: 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-iana-registry-updates/



--
COMMENT:
--

I support the idea behind this document. I have a few minor issues which I
would like to discuss before recommending its approval:

1) In several places:

"IESG action is REQUIRED for a Yes->No transition."

Firstly, this should be "IESG Approval", not "IESG action" (according to RFC
8126).

Secondly, are you saying that this is the ONLY way to transition from Yes to
No? Surely, Standards Action should also be allowed in case there is no rush?
Besides IESG is likely to prefer a document explaining the transition anyway.

2) In Section 15:

15.  TLS Certificate Types

   Experience has shown that the IETF Consensus registry policy for TLS
   Certificate Types is too strict.  Based on WG consensus, the decision
   was taken to change registration policy to Specification Required
   [RFC8126] while reserving a small part of the code space for
   experimental and private use.  Therefore, IANA [SHALL add/has added]
   a "Recommended" column to the registry.  X.509 and Raw Public Key are
   "Yes".  All others are "No".  In order to register an extension with
   the value "Yes", a Standards Track document [RFC8126] is REQUIRED.

The above sentence.

   Future Certificate Types MUST define the value of this column.  A
   Standards Track document [RFC8126] is REQUIRED to register an entry
   with the value "Yes".

And this is just repeating the above sentence in a different way.

   IESG action is REQUIRED for a Yes->No
   transition.

3) In Section 17:

   Despite the fact that the HashAlgorithm and SignatureAlgorithm
   registries are orphaned, it is still import to warn implementers of

import --> important

   pre-TLS1.3 implementations about the dangers of blinding implementing

blinding --> blindly

   cryptographic algorithms.

And later in the same section:

   WARNING:  Cryptographic algorithms and parameters will be broken or
  weakened over time.  Blindly implementing cipher suites listed

cipher suites --> hash functions/signatures?

  here is not advised.  Implementers and users need to check that
  the cryptographic algorithms listed continue to provide the
  expected level of security.


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

[TLS] Alexey Melnikov's Yes on draft-ietf-tls-dnssec-chain-extension-07: (with COMMENT)

[Alexey Melnikov]

Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-dnssec-chain-extension-07: Yes

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-dnssec-chain-extension/



--
COMMENT:
--

Now that TLS 1.3 is approved for publication, I think adding a Normative
Reference to TLS 1.3 is no brainer. I am clearing my DISCUSS on the assumption
that this would be fixed before publication of the RFC.

1) TLS 1.3 needs to be a normative reference, but it is not even listed in
References.

2) The first mention of NSEC3 need a normative reference.


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

Re: [TLS] Alexey Melnikov's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

[Alexey Melnikov]

Hi,

On Wed, Feb 21, 2018, at 4:06 PM, Shumon Huque wrote:
> On Wed, Feb 7, 2018 at 9:05 PM, Shumon Huque <shu...@gmail.com> wrote:>> On 
> Wed, Feb 7, 2018 at 1:22 PM, Alexey Melnikov
>> <aamelni...@fastmail.fm> wrote:
>>> Alexey Melnikov has entered the following ballot position for 
>>> draft-ietf-tls-dnssec-chain-extension-
>>> 06: Discuss
>>>
>>>  -
>>>  -
>>>  DISCUSS:
>>>  -
>>>  -
>>>
>>>  I think this is a useful document and I will ballot Yes once my
>>>  small issues are resolved:
>>>
>>>  1) In 3.4:
>>>
>>> The first RRset in the chain MUST contain the TLSA record set
>>> being presented.  However, if the owner name of the TLSA record
>>> set is an alias (CNAME or DNAME), then it MUST be preceded by
>>> the chain of alias records needed to resolve it.  DNAME chains
>>> should omit
>>>
>>>  SHOULD? What are the implications if this is not followed?>> 
>> Ok. I guess we need the upper case word here, yes.
>> 
>> Implication: If the synthesized CNAME records are included in
>> the chain>> then the client will have to ignore them (they aren't signed and 
>> thus
>> can't be>> validated) - the signed DNAME record is sufficient for the client 
>> to
>> securely>> validate the mapping and continue processing.
>> 
>> It might make things simpler to just make this a MUST. I would
>> guess this>> would not raise any objections from the working group.
> 
> A quick follow-up on this. I think we just keep this as a SHOULD.
> I looked> at what an existing DNS library implementation does, and it
> includes the> synthesized CNAME. It's easy enough for the client to just
> ignore it when> validating the chain.

I think adding some text explaining this would be a good addition to
the document.
Best Regards,
Alexey
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Alexey Melnikov's Discuss on draft-ietf-tls-tls13-26: (with DISCUSS and COMMENT)

[Alexey Melnikov]

Hi Ekr,

On Wed, Mar 7, 2018, at 2:16 PM, Eric Rescorla wrote:
> 
> 
> On Wed, Mar 7, 2018 at 5:29 AM, Alexey Melnikov
> <aamelni...@fastmail.fm> wrote:>> Alexey Melnikov has entered the following 
> ballot position for
>>  draft-ietf-tls-tls13-26: Discuss
>> 
>>  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-tls13/
>> 
>> 
>> 
>>  
>>  -->>  DISCUSS:
>>  
>>  -->> 
>>  Thank you for a well written document. I will be switching to Yes
>>  once the>>  following is addressed/discussed:
>> 
>>  Relationship to TLS 1.2 needs to be clarified. The document is
>>  adding>>  requirements on TLS 1.2 clients. Implementors of TLS 1.2 are not
>>  going to (or>>  very unlikely to) read this document. This looks fishy to 
>> me. Two
>>  examples on>>  page 37:
>> 
>>TLS 1.2 clients SHOULD also check that the last eight bytes  are
>>not equal to>>the second value if the ServerHello indicates TLS  1.1 
>> or below
>> 
>>  and
>> 
>>   A legacy TLS client performing renegotiation with TLS 1.2 or prior
>>   and which>>   receives a TLS 1.3 ServerHello during renegotiation MUST  
>> abort the
>>   handshake>>   with a "protocol_version" alert.  Note that  renegotiation 
>> is not
>>   possible>>   when TLS 1.3 has been negotiated.
>> 
>>  There are similar statements on page 45:
>> 
>>TLS 1.2 implementations SHOULD also process this extension.
>> 
>>  and on page 48:
>> 
>>However, the old semantics did not constrain the signing
>>curve.  If TLS 1.2 is negotiated, implementations MUST be prepared>>
>> to accept a signature that uses any curve that they advertised in>>the 
>> "supported_groups" extension.
>> 
>>  I think you need to clarify whether these normative requirements
>>  apply to pure>>  TLS 1.2 clients or TLS clients that implement both 1.2 and 
>> 1.3 and
>>  choose to>>  use 1.2 for some reason. Or maybe you need to say in the
>>  Abstract/Introduction>>  that although this document obsoletes TLS 1.2 it 
>> also specifies new>>  requirements on TLS 1.2 implementations. (So it is 
>> sort of both
>>  "Obsoletes" and>>  "Updates" TLS 1.2 RFC.)
> 
> 
> The intent is that these affect old TLS 1.2 implementations as well. S
> 1.4 tries> to be clear about this, but maybe it fails.
> 
> I suggest we:
> 
> (1) Add the following sentence to the abstract:
> "This document also specifies new requirements for TLS 1.2
> implementations.> 
> (2) Rewrite the first sentence of S 1.4 to say:
>This document defines several changes that optionally affect
>implementations of TLS 1.2, including those which do not also
>support TLS 1.3
> 
> (3) Strike the following graf:
> 
>An implementation of TLS 1.3 that also supports TLS 1.2 might
>need to>include changes to support these changes even when TLS 1.3 is
>not in>use.  See the referenced sections for more details.
I think this will address my concern.

>   
>> ---
>> --->>  COMMENT:
>>  
>>  -->> 
>>  1) On page 47:
>>   The length of the salt MUST be equal to the length of the digest
>>   algorithm>> 
>>  Length of algorithm?
> 
> Right. Output of.
> 
>  
>> 
>> 2) DER need a Normative Reference on first use. There are some
>>references on>>  2nd/3rd use.
> 
> Thanks.
>  
>> 
>> 3) On page 57:
>> 
>> The
>> server then ignores early data by attempting to decrypt received>> 
>> records in the handshake traffic keys until it is able to receive>> the 
>> client's second flight and complete an ordinary 1-RTT
>> 

[TLS] Alexey Melnikov's Discuss on draft-ietf-tls-tls13-26: (with DISCUSS and COMMENT)

[Alexey Melnikov]

Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-tls13-26: Discuss

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-tls13/



--
DISCUSS:
--

Thank you for a well written document. I will be switching to Yes once the
following is addressed/discussed:

Relationship to TLS 1.2 needs to be clarified. The document is adding
requirements on TLS 1.2 clients. Implementors of TLS 1.2 are not going to (or
very unlikely to) read this document. This looks fishy to me. Two examples on
page 37:

  TLS 1.2 clients SHOULD also check that the last eight bytes  are not equal to
  the second value if the ServerHello indicates TLS  1.1 or below

and

 A legacy TLS client performing renegotiation with TLS 1.2 or prior  and which
 receives a TLS 1.3 ServerHello during renegotiation MUST  abort the handshake
 with a "protocol_version" alert.  Note that  renegotiation is not possible
 when TLS 1.3 has been negotiated.

There are similar statements on page 45:

  TLS 1.2 implementations SHOULD also process this extension.

and on page 48:

  However, the old semantics did not constrain the signing
  curve.  If TLS 1.2 is negotiated, implementations MUST be prepared
  to accept a signature that uses any curve that they advertised in
  the "supported_groups" extension.

I think you need to clarify whether these normative requirements apply to pure
TLS 1.2 clients or TLS clients that implement both 1.2 and 1.3 and choose to
use 1.2 for some reason. Or maybe you need to say in the Abstract/Introduction
that although this document obsoletes TLS 1.2 it also specifies new
requirements on TLS 1.2 implementations. (So it is sort of both "Obsoletes" and
"Updates" TLS 1.2 RFC.)


--
COMMENT:
--

1) On page 47:
 The length of the salt MUST be equal to the length of the digest  algorithm

Length of algorithm?

2) DER need a Normative Reference on first use. There are some references on
2nd/3rd use.

3) On page 57:

   The
   server then ignores early data by attempting to decrypt received
   records in the handshake traffic keys until it is able to receive
   the client's second flight and complete an ordinary 1-RTT
   handshake, skipping records that fail to decrypt, up to the
   configured max_early_data_size.

I read this several times and still don't understand what this is saying. It is
saying "ignores ... until it is able to receive". I think you either don't mean
"ignore" (as in discard the rest) or I misunderstood. I clarifying example or a
reference to another section (e.g. with the diagram) would be very helpful here.

4) On page 82:

   When record protection has not yet been engaged, TLSPlaintext  structures
   are written directly onto the wire.  Once record  protection has started,
   TLSPlaintext records are protected and sent   as described in the following
   section

Just to double check: are you saying that before the handshake TLS application
layer effectively results in plain text messages (with some extra octets to
signal record type)?

5) I am pretty sure that [RFC5116] is a Normative reference. It is required to
be understood to implemented TLS 1.3. Also, you have additional requirements on
AEADs, which again implies understanding of what they are:

On page 84:

   An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion  greater
   than 255 octets

and

   An AEAD algorithm where N_MAX is less than 8  bytes MUST NOT be used with TLS

6) The diagram in section 7.1 was a bit cryptic. Maybe explain that when you
use '0' you mean as many bytes of 0s as needed for various functions.


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

[TLS] Alexey Melnikov's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

[Alexey Melnikov]

Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-dnssec-chain-extension-06: Discuss

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-dnssec-chain-extension/



--
DISCUSS:
--

I think this is a useful document and I will ballot Yes once my small issues 
are resolved:

1) In 3.4:

   The first RRset in the chain MUST contain the TLSA record set being
   presented.  However, if the owner name of the TLSA record set is an
   alias (CNAME or DNAME), then it MUST be preceded by the chain of
   alias records needed to resolve it.  DNAME chains should omit

SHOULD? What are the implications if this is not followed?

   unsigned CNAME records that may have been synthesized in the response
   from a DNS resolver.

2) TLS 1.3 needs to be a normative reference, but it is not even listed in 
References.


--
COMMENT:
--

The first mention of NSEC3 need a normative reference.


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

[TLS] Alexey Melnikov's No Objection on draft-ietf-tls-rfc4492bis-15: (with COMMENT)

[Alexey Melnikov]

Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-rfc4492bis-15: 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-rfc4492bis/



--
COMMENT:
--

I would like to vote Yes on this document, but there are some minor
issues with this document which prevent me from doing so:

0) There is some general awkwardness in text talking about allowed points
formats, considering that only uncompressed form is now allowed. I don't
have recommendations about improving text, other than the following:

If no future formats are expected, it feels almost better to recommend
against inclusion of the Point formats extension, as lack of it means
uncompressed format anyway.

1) In Section 2.3, last paragraph: Does this paragraph apply only to 2.3
or does it also apply to 2.1 and 2.2? If the latter, then it needs to be
moved to section 2.

2) In Section 6:

   Server implementations SHOULD support all of the following cipher
   suites, and client implementations SHOULD support at least one of
   them:

   o  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
   o  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
   o  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
   o  TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

GCM ciphers are not listed in the table earlier in the same section. They
are defined in RFC 5289. This document doesn't have any reference to RFC
5289 and GCM ciphers are not discussed anywhere else in the document.


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

Re: [TLS] Alexey Melnikov's Yes on draft-ietf-tls-chacha20-poly1305-04: (with COMMENT)

[Alexey Melnikov]

On Thu, May 5, 2016, at 03:33 PM, Dang, Quynh (Fed) wrote:
> 
> Hi Stephen,
> 
> The one below can be used.
> 
> [FIPS 180-4]  Federal Information Processing Standards Publication
> (FIPS PUB) 180-4, Secure Hash Standard (SHS), August
> 2015.

There is also RFC 4634, but I am not sure which reference is better.

> Regards,
> Quynh.
> 
> From: TLS <tls-boun...@ietf.org> on behalf of Stephen Farrell
> <stephen.farr...@cs.tcd.ie>
> Sent: Thursday, May 5, 2016 10:14:19 AM
> To: Alexey Melnikov; The IESG
> Cc: draft-ietf-tls-chacha20-poly1...@ietf.org; tls-cha...@ietf.org;
> tls@ietf.org
> Subject: Re: [TLS] Alexey Melnikov's Yes on
> draft-ietf-tls-chacha20-poly1305-04: (with COMMENT)
> 
> On 24/04/16 17:23, Alexey Melnikov wrote:
> > Alexey Melnikov has entered the following ballot position for
> > draft-ietf-tls-chacha20-poly1305-04: Yes
> >
> > 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-chacha20-poly1305/
> >
> >
> >
> > --
> > COMMENT:
> > --
> >
> > Nit: SHA-256 probably needs a normative reference.
> 
> I added an RFC editor note. If someone has the right reference
> to add handy I can add that too. Or I'll get to it in a bit,
> 
> Cheers,
> S.
> 
> >
> >
> > ___
> > 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] Alexey Melnikov's Yes on draft-ietf-tls-chacha20-poly1305-04: (with COMMENT)

[Alexey Melnikov]

Alexey Melnikov has entered the following ballot position for
draft-ietf-tls-chacha20-poly1305-04: Yes

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-chacha20-poly1305/



--
COMMENT:
--

Nit: SHA-256 probably needs a normative reference.


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

Re: [TLS] Correction: early codepoint assignment for Curve25519, Curve448, Ed25519 and Ed448

[Alexey Melnikov]

> On 12 Jan 2016, at 21:31, Ilari Liusvaara  wrote:
> 
>> On Tue, Jan 12, 2016 at 10:21:21PM +0200, Yoav Nir wrote:
>> 
>>> On 12 Jan 2016, at 9:26 PM, Simon Josefsson  wrote:
>>> 
>>> The same concern still applies: what does it mean to allocate code
>>> point for the 4492bis-05 description?
>> 
>> Allocating code points just means an implementation of draft-05 is
>> likely to interoperate just fine with an implementation of the final
>> RFC.
>> 
>> Of course nothing is ever final until the RFC is out, so there’s
>> always a risk involved, but it is considered prudent to allocate
>> numbers when we’re reasonably certain of the calculations and on-
>> the-wire formats. Any debate about whether we should or should not
>> check certain inputs for certain conditions need not be a bar for
>> allocating numbers.
> 
> Assuming CFRG chairs really did declare consensus on Ed448 hash, then
> the final characteristics of Ed448 are known and I have a reference
> implementation.
> 
> And the PKIX draft looks implementable (has wrong example?)
> 
> More serious interop hazard is what to do with X25519/X448 and THS
> (some of the proposed stuff is not wire-compatible).

This CFRG co-chair would like to see an updated CFRG draft before the code 
point is allocated.

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

Re: [TLS] Deprecating tls-unique for TLS 1.3

[Alexey Melnikov]

On 04/11/2015 11:13, Eric Rescorla wrote:
> Can you expand on this a bit? Perhaps propose some text.

So, tls-unique is defined in RFC 5929 as:

   Description: The first TLS Finished message sent (note: the Finished
   struct, not the TLS record layer message containing it) in the most
   recent TLS handshake of the TLS connection being bound to (note: TLS
   connection, not session, so that the channel binding is specific to
   each connection regardless of whether session resumption is used).
   If TLS renegotiation takes place before the channel binding
   operation, then the first TLS Finished message sent of the latest/
   inner-most TLS connection is used.  Note that for full TLS
   handshakes, the first Finished message is sent by the client, while
   for abbreviated TLS handshakes (session resumption), the first
   Finished message is sent by the server.

This is currently independent of the version of TLS used. This is also
broken for TLS 1.2 due to the triple handshake vulnerability.

I don't think we can just redefine this for TLS 1.3 and expect this to
work, because APIs for getting this information out of TLS libraries are
going to be different if Exporters are used.
Also, if "tls-unique" is redefined, an old implementation of
"tls-unique" would be unable to talk to a new implementation. For
example if one end is IMAP client using SCRAM or GS2 against IMAP server
implementing the same.

I think there is desire to fix this for both TLS 1.2 and 1.3. I think
the best way would be to take Simon's draft-josefsson-sasl-tls-cb-03
(Channel Bindings for TLS based on the PRF) and update it for TLS 1.3. I
think conceptually what Simon did is very similar to what was proposed
in the TLS meeting today.


> -Ekr
> 
> 
> On Wed, Nov 4, 2015 at 11:12 AM, Alexey Melnikov
> <alexey.melni...@isode.com <mailto:alexey.melni...@isode.com>> wrote:
> 
> Just to clarify, I think it is fine to define TLS 1.3 replacement
> for tls-unique using Exporters. But I suggest for interoperability
> this should be defined as a new channel binding with a new name, as
> opposed to just redefining tls-unique.

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