Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Kyle Nekritz]

I raised this before in PR #693 
(https://www.ietf.org/mail-archive/web/tls/current/msg21600.html).

I'm not sure it makes sense to rename this to legacy while other parts of the 
document still refer to it. But I'm definitely in favor of deprecating it.

From: TLS  on behalf of Dave Garrett 

Sent: Tuesday, March 28, 2017 4:42 PM
To: tls@ietf.org
Subject: Re: [TLS] WGLC: draft-ietf-tls-tls13-19
    
On Tuesday, March 28, 2017 02:23:33 am Kaduk, Ben wrote:
> Should Alert.level be Alert.legacy_level?

Yep. Trivial to fix, so quick PR filed for it.


Dave

___
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls=DwICAg=5VD0RTtNlTh3ycd41b3MUw=l2j4BjkO0Lc3u4CH2z7jPw=ix39YzN5D9ZIP69oc6EpeIHky4mBDPr78L-0dRI3acY=wDljuAs_X9UuW_4VC-TwYR9TkDPrKiVZz7oRdOmL3aA=

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

[TLS] review comments on draft-rescorla-tls-dtls13-01

[Kaduk, Ben]

A few things I noticed while reading the draft to prepare for today’s session:

We talk in a couple places about datagram protocols being “vulnerable” or 
“susceptible” to DoS attacks, which leads me to at least partially read that as 
meaning that the protocol’s own service will be disrupted; as we know, this is 
not the whole story, as the reflection/amplification part can facilitate DoS 
attacks targeted at other services/networks.  So perhaps some rewording is in 
order.

We should catch up to the ClientHello1 being included in the transcript hash as 
the synthetic message_hash message, so the full transcript of it need not be 
stored in the HelloRetryRequest.

On page 20, second paragraph, please be clear that it is the message_seq vs. 
the record sequence_number that must match next_receive_seq.

I also made a note of the different key update behavior of this draft vs. 
draft-ietf-tls-tls13-19, with the epoch change and lockstep rekeying between 
peers.  That was in the presentation as well, but I haven’t had my thoughts 
settle into which flavor I prefer, yet, though the explicit KeyUpdate does have 
some advantages.

-Ben

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

[TLS] review comments on draft-rescorla-tls-subcerts-01

[Kaduk, Ben]

Getting these in email before my printout with red markings gets buried in a 
pile.

We mentioned adding a NUL byte separator in the signature on the 
DelegatedCredential (as well as some other potential tweaks to normalize the 
context strings elsewhere and here).

Do we want to leave the valid SignatureSchemes as all that are defined, or 
mention the Recommended column in the registry, or narrow things even further?  
In other words, should we give some guidance for how to select a scheme to use?

-Ben

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

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Dave Garrett]

On Tuesday, March 28, 2017 02:23:33 am Kaduk, Ben wrote:
> Should Alert.level be Alert.legacy_level?

Yep. Trivial to fix, so quick PR filed for it.


Dave

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

Re: [TLS] draft-ietf-tls-tls13-19 section 1.2 cleanup

[Dave Garrett]

On Tuesday, March 28, 2017 11:31:56 am Short, Todd wrote:
> I didn’t bring this up in the meeting this morning, but I’d like to see 
> section 1.2 “Major Differences from TLS 1.2” cleaned up. We don’t need to 
> list the changes at each draft. Instead, only the major difference from RFC 
> 5246, et al., should be included. It’s difficult to wade through this section 
> as written.
> 
> I refer to RFC5246, section 1.2 as an appropriate (and useful) example.

Yeah, this has come up a few times, also in another post here very recently. 
It's always been on a vague todo list to fixup. I've filed an issue just for 
this so we have it actually tracked.

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


Dave

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

Re: [TLS] 4.1.2 Client Hello ammendment

[Dave Garrett]

On Tuesday, March 28, 2017 01:37:29 pm Mark Dunn wrote:
> should the text that reads
>  ClientHellos will contain at least two extensions, 
> “supported_versions” and either “key_share” or “pre_shared_key”.
> be changed to
>  ClientHellos will always contain extensions.
> 
> Both "key_share" and "pre_shared_key" require other extensions, so "at 
> least two extensions" is incorrect.

Um, that's still "at least two". ;)

Taking a look at that section, there's a better line stating this just below in 
another paragraph on the same topic. I've posted a quick PR to rewrite this 
slightly to clean this up a bit.

https://github.com/tlswg/tls13-spec/pull/922


Dave

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

[TLS] 4.1.2 Client Hello ammendment

[Mark Dunn]

should the text that reads
ClientHellos will contain at least two extensions, 
“supported_versions” and either “key_share” or “pre_shared_key”.

be changed to
ClientHellos will always contain extensions.

Both "key_share" and "pre_shared_key" require other extensions, so "at 
least two extensions" is incorrect.


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

Re: [TLS] The alternative idea I had for token buckets.

[Martin Thomson]

On 28 March 2017 at 10:57, Scott Fluhrer (sfluhrer)  wrote:
> Sorry, I wasn't aware that unlinkability was a requirement...

Yeah, it's the only hard requirement. :)

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

Re: [TLS] The alternative idea I had for token buckets.

[Scott Fluhrer (sfluhrer)]

Sorry, I wasn't aware that unlinkability was a requirement...

> -Original Message-
> From: Martin Thomson [mailto:martin.thom...@gmail.com]
> Sent: Tuesday, March 28, 2017 11:51 AM
> To: Scott Fluhrer (sfluhrer)
> Cc: 
> Subject: Re: [TLS] The alternative idea I had for token buckets.
> 
> On 28 March 2017 at 10:48, Scott Fluhrer (sfluhrer) 
> wrote:
> > The server recovers E_K(R) because the client sent it (along with i and the
> protected message).  It recovers R because it also knows K.
> 
> So E_K(R) is sent directly?  That would link packets.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The alternative idea I had for token buckets.

[Martin Thomson]

On 28 March 2017 at 10:48, Scott Fluhrer (sfluhrer)  wrote:
> The server recovers E_K(R) because the client sent it (along with i and the 
> protected message).  It recovers R because it also knows K.

So E_K(R) is sent directly?  That would link packets.

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

Re: [TLS] The alternative idea I had for token buckets.

[Scott Fluhrer (sfluhrer)]

> -Original Message-
> From: Martin Thomson [mailto:martin.thom...@gmail.com]
> Sent: Tuesday, March 28, 2017 11:46 AM
> To: Scott Fluhrer (sfluhrer)
> Cc: 
> Subject: Re: [TLS] The alternative idea I had for token buckets.
> 
> On 28 March 2017 at 10:41, Scott Fluhrer (sfluhrer) 
> wrote:
> > E_K(R); that is, R is encrypted with the server's long term key.
> >
> > (I meant to specify that...)
> 
> 
> OK, so how does the server recover E_K(R)?  The point here is that it doesn't
> know R.

The server recovers E_K(R) because the client sent it (along with i and the 
protected message).  It recovers R because it also knows K.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The alternative idea I had for token buckets.

[Martin Thomson]

On 28 March 2017 at 10:41, Scott Fluhrer (sfluhrer)  wrote:
> E_K(R); that is, R is encrypted with the server's long term key.
>
> (I meant to specify that...)


OK, so how does the server recover E_K(R)?  The point here is that it
doesn't know R.

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

Re: [TLS] The alternative idea I had for token buckets.

[Scott Fluhrer (sfluhrer)]

E_K(R); that is, R is encrypted with the server's long term key.

(I meant to specify that...)

> -Original Message-
> From: Martin Thomson [mailto:martin.thom...@gmail.com]
> Sent: Tuesday, March 28, 2017 11:37 AM
> To: Scott Fluhrer (sfluhrer)
> Cc: 
> Subject: Re: [TLS] The alternative idea I had for token buckets.
> 
> I'm sorry, but I don't understand this proposal.  I'm losing you when you say
> E(R) without specifying the key that you are using.
> 
> On 28 March 2017 at 10:21, Scott Fluhrer (sfluhrer) 
> wrote:
> > Here’s how it would work:
> >
> >
> >
> > -  The server has a long term secret key K, which it never gives out
> >
> > -  When the server wants to give a token to a client, it picks a
> > random value R, and securely gives the client the values R and E_K(R)
> >
> > -  When the client wants to use the token, it picks a value i, and
> > computes the key Hash( R || i).  It uses that key to protect the
> > message, and also sends the server the values E(R) and i
> >
> > -  The server decrypts the value E(R) to recover R, it computes
> > Hash( R || i) to recover the message key, and then decrypts the
> > message
> >
> >
> >
> > That way, the server doesn’t have to send the client N different
> > tokens…
> >
> >
> > ___
> > 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] The alternative idea I had for token buckets.

[Martin Thomson]

I'm sorry, but I don't understand this proposal.  I'm losing you when
you say E(R) without specifying the key that you are using.

On 28 March 2017 at 10:21, Scott Fluhrer (sfluhrer)  wrote:
> Here’s how it would work:
>
>
>
> -  The server has a long term secret key K, which it never gives out
>
> -  When the server wants to give a token to a client, it picks a
> random value R, and securely gives the client the values R and E_K(R)
>
> -  When the client wants to use the token, it picks a value i, and
> computes the key Hash( R || i).  It uses that key to protect the message,
> and also sends the server the values E(R) and i
>
> -  The server decrypts the value E(R) to recover R, it computes
> Hash( R || i) to recover the message key, and then decrypts the message
>
>
>
> That way, the server doesn’t have to send the client N different tokens…
>
>
> ___
> 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] draft-ietf-tls-tls13-19 section 1.2 cleanup

[Short, Todd]

Hi List:

I didn’t bring this up in the meeting this morning, but I’d like to see section 
1.2 “Major Differences from TLS 1.2” cleaned up. We don’t need to list the 
changes at each draft. Instead, only the major difference from RFC 5246, et 
al., should be included. It’s difficult to wade through this section as written.

I refer to RFC5246, section 1.2 as an appropriate (and useful) example.

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


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

[TLS] The alternative idea I had for token buckets.

[Scott Fluhrer (sfluhrer)]

Here's how it would work:


-  The server has a long term secret key K, which it never gives out

-  When the server wants to give a token to a client, it picks a random 
value R, and securely gives the client the values R and E_K(R)

-  When the client wants to use the token, it picks a value i, and 
computes the key Hash( R || i).  It uses that key to protect the message, and 
also sends the server the values E(R) and i

-  The server decrypts the value E(R) to recover R, it computes Hash( R 
|| i) to recover the message key, and then decrypts the message

That way, the server doesn't have to send the client N different tokens...
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Call for adoption of draft-rescorla-tls-dtls13

[Kaduk, Ben]

I support adopting this document and am willing to review it.

-Ben

On 3/22/17, 17:50, "Sean Turner"  wrote:

All,

-00 of draft-rescorla-tls-dtls13 [0][1] was discussed at IETF 97 [2].  It’s 
now at version -01 and GH issues are slowly rolling in.  It’s also on our 
agenda again at IETF 98, and DTLS a chartered work item, so it seems like it’s 
time to get the WG adoption process started for this individual draft.  Please 
let the list know whether you support adoption of the draft and are willing to 
review/comment on the draft before 20170406.  If you object to its adoption, 
please let us know why.

Cheers,

J

[0] https://github.com/ekr/dtls13-spec 
[1] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-dtls13
[2] https://www.ietf.org/proceedings/97/slides/slides-97-tls-dtls-13-01.pdf
___
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] draft-thomson-tls-record-limit-00

[Thomas Pornin]

On Tue, Mar 28, 2017 at 06:35:24AM -0500, Martin Thomson wrote:
> I just submitted a version of the draft we've discussed a little on
> the list.
> 
> I don't think we concluded the discussion about what to do about block
> cipher padding.

I don't have strong preferences on this, but I would incline toward
using the plaintext length in the extension. In any case, adding a
longer-than-necessary padding in order to defeat traffic analysis does
not make sense if it expands the size beyond the minimal record size for
a full record (i.e. if an endpoint wants to add extra padding bytes to a
record with 16384 bytes of padding, it is only _revealing_ extra
information, not hiding it).

I suggest altering this paragraph:

   The size limit expressed in the "record_size_limit" extension doesn't
   account for expansion due to compression or record protection.  It is
   expected that a constrained device will disable compression and know
   - and account for - the maximum expansion possible due to record
   protection based on the cipher suites it offers or selects.  Note
   that up to 256 octets of padding and padding length can be added to
   block ciphers.

into this:

   The size limit expressed in the "record_size_limit" extension doesn't
   account for expansion due to compression or record protection.  If
   and endpoint advertises a size limit which is lower than the
   protocol-defined limit, then the peer SHALL NOT send a record whose
   final, protected size exceeds that of the minimal protected size of a
   record that contains exactly "record_size_limit" plaintext bytes and
   uses no compression.
   
   For instance, if using TLS 1.2 and a cipher suite that mandates
   AES/CBC encryption and HMAC/SHA-256 for protection, and an endpoint
   advertises a "record_size_limit" of 700 bytes, then the minimal
   protected record size for 700 bytes of plaintext contents is 757
   bytes:

 - 700 bytes of plaintext
 - 32 bytes for the HMAC/SHA-256
 - 4 bytes of padding to reach the next multiple of the AES block
   size (which is 16 bytes)
 - 16 bytes for the explicit IV
 - 5 bytes for the record header

   The padding may have length 1 to 256 bytes as per protocol rules;
   but in the presence of a "record_size_limit" of 700 bytes expressed
   by the peer, an endpoint SHALL refrain from sending records whose
   total protected size exceeds 757 bytes.

   It is expected that a constrained device will disable compression;
   moreover, the practice of adding a longer-than-minimal padding is
   done in order to defeat traffic analysis, and sending records longer
   than the minimal size for full records is counterproductive (such a
   record would reveal extra information to onlookers, and thus should
   be avoided).

--

Another unrelated comment: in section 3, there is the following:

   The "max_fragment_length" extension is also ill-suited to cases where
   the capabilities of client and server are asymmetric.  The server is
   required to select a fragment length that is as small or smaller than
   the client offers and both endpoints need to comply with this smaller
   limit.

Actually, it is worse than that: per the wording of RFC 6066, if a
client advertises a length of L bytes, the server must respond with
_exactly_ the same length L; the server is not allowed to select a
smaller length. The relevant RFC text is:

   The "extension_data" field of this extension SHALL contain a
   "MaxFragmentLength" whose value is the same as the requested maximum
   fragment length.

and it is reinforced some lines later:

   Similarly, if a client receives a maximum fragment length negotiation
   response that differs from the length it requested, it MUST also
   abort the handshake with an "illegal_parameter" alert.

The "max_fragment_length" extension is completely client-driven: it is
used only on the client's initiative, and uses the client's length. The
server's only choice is to accept the will of the client, or reject the
connection. Thus, it handles only the case of constrained clients
talking to big servers, not the other way round.


--Thomas Pornin

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

Re: [TLS] A few comments on draft-ietf-tls-dnssec-chain-extension-02.txt

[Shumon Huque]

On Wed, Mar 22, 2017 at 4:50 PM, Viktor Dukhovni 
wrote:

>
> > On Mar 22, 2017, at 10:56 AM, Melinda Shore <
> melinda.sh...@nomountain.net> wrote:
> >
> > The draft could definitely benefit from
> > additional review.
>
> I find it ironic that section 4 includes:
>
>The components of the authentication chain are built by starting at
>the target record set and its corresponding RRSIG.  Then traversing
>the DNS tree upwards towards the trust anchor zone (normally the DNS
>root), for each zone cut, the DNSKEY and DS RRsets and their
>signatures are added.  If DNS responses messages contain any domain
>names utilizing name compression [RFC1035], then they must be
>uncompressed.
>
> while at the same time there is ongoing discussion of *adding* compression
> of the server certificate chain (as a TLS 1.3 extension).  Would the
> compression of server certificates also cover compression of the DNSSEC
> chain extension?  If so, perhaps this would be a belated moral victory
> for DJB[1]. :-)
>

I think the reason for the last sentence quoted above is that DNS name
compression is defined in terms of an offset from the beginning of the
DNS message, and the draft as currently written uses a sequence of RRsets
rather than a complete DNS message. I sympathesize with djb's critique.
If DNS wasn't designed in the early 80's then perhaps we would have had
something different.

I supposed we could redefine name compression for this draft to use an
offset from the beginning of the chain data.

Does the proposed compression of certificate chains include extensions
in the Certificate message also? If so, the DNSSEC chain extension would
automatically be covered. Generally speaking, I would not be opposed to
compressing the DNSSEC chain extension with a normal compression algorithm.
Perhaps some empirical measurements might be useful to determine
whether it yields significant enough savings. Large parts of the dnssec
chain (signatures and keys) probably aren't terribly compressible, although
I guess the same issue exists for certificate chains, and if it's worth it
for
the latter ..

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

Re: [TLS] A few comments on draft-ietf-tls-dnssec-chain-extension-02.txt

[Shumon Huque]

On Thu, Mar 23, 2017 at 12:28 AM, Viktor Dukhovni 
wrote:

>
> > On Mar 22, 2017, at 10:56 AM, Melinda Shore <
> melinda.sh...@nomountain.net> wrote:
> >
> > The draft could definitely benefit from additional review.
>
> A more complete walk through:
>
> > 2.  Introduction
> >
> >This draft describes a new TLS [RFC5246] extension for transport of a
> >DNS record set serialized with the DNSSEC signatures [RFC4034] needed
> >to authenticate that record set.  The intent of this proposal is to
> >allow TLS clients to perform DANE authentication [RFC6698] of a TLS
>
> Should RFC6698 here be replaced or augmented with RFC7671?  In RFC7671,
> the processing of DANE-EE(3) are DANE-TA(2) is modified from what one
> might naively do with just RFC6698.  One of these changes of course
> introduces the UKS problem referenced in this draft, but since this
> draft militates against UKS attacks, that's not a problem.
>

Yes, I agree. We should add a reference to 7671.


>
> >Furthermore,
> >SMTP MTAs usually employ Opportunistic Security [RFC7435], in which
> >the presence of the DNS TLSA records is used to determine whether to
> >enforce an authenticated TLS connection.  Hence DANE authentication
> >of SMTP MTAs [RFC7672] will typically not use this mechanism.
>
> Note that RFC7672 describes opportunistic DANE TLS for SMTP, so RFC7435
> should probably be replaced by RFC7672 here.
>

Yes.


> >The client then authenticates the chain using a pre-configured trust
> >anchor.
>
> Speaking of trust-anchors, the client will ultimately need to have some
> mechanism to deal with root KSK rollover.  If the client has no local
> resolver that is, at least intermittently, able to refresh the root KSK,
> then the client may well also need to use this specification to update
> the root KSK list from the DNSKEY RRsets returned by servers, and to
> persist these for future use.  That's probably worth a mention...
>

Yes, and it kind of is mentioned later in the document where there is a
discussion of whether or not to include the trust anchor DNSKEY RRset
in the chain or not. We need to sort out the requirement there.

>As described in the DANE specification [RFC6698], this procuedure
> >applies to the DANE authentication of X.509 certificates.
>
> Or raw public keys as described in 7671, and indeed mentioned below
> in the draft.
>
> > 3.1.  Protocol, TLS 1.2
> >
> >A client MAY include an extension of type "dnssec_chain" in the
> >(extended) ClientHello.  The "extension_data" field of this extension
> >MUST be empty.
>
> One might ask the client to include the port number here, the server
> may not know which port the client used if some load-balancer redirected
> the layer-4 server address.
>

Hmm, I remember you brought up this point a while back, but I can't
remember
the subsequent discussion and what we decided to do about this. I suppose
it may be possible to preconfigure the servers on the other side of the
load
balancer to know the original port to avoid this problem.


> > 3.4.  DNSSEC Authentication Chain Data
>
> >Each RRset in the chain is composed of a sequence of wire format DNS
> >resource records.  The format of the resource record is described in
> >RFC 1035 [RFC1035], Section 3.2.1.  The resource records SHOULD be
> >presented in the canonical form and ordering as described in RFC 4034
> >[RFC4034].
> >
> >  RR(i) = owner | type | class | TTL | RDATA length | RDATA
>
> Note that the TTL in the canonical form is the one in the RRSIG, rather
> that a typically smaller value in response from the resolver.  Whose
> responsibility is it to ensure that the records fed into the signature
> verification algorithm have the correct (maximal) TTL?
>

I would assume the validator on the TLS client side.


>
> >The first RRset in the chain MUST contain the DANE records being
> >presented.  The subsequent RRsets MUST be a sequence of DNSKEY and DS
> >RRsets, starting with a DNSKEY RRset.  Each RRset MUST authenticate
> >the preceding RRset:
>
> Except that of course, as explained below, they don't have to be a
> sequence of "DNSKEY" and "DS" RRsets, because wildcards also necessitate
> NSEC, NSEC3 or possibly (some decade this century unless scalable QCs
> arrive first) NSEC5 records.
>

Yes. The need to include NSEC/3 records for the wildcard DNS record case
is mentioned later in the draft, so this text needs to be reconciled with
it.

Also, on the issue of ordered vs unordered sequence of RRsets, the draft at
the moment appears to have contradictory text on this issues. Earlier in
section 3.4 it says:

  "The record sets and
   signatures are presented in the order returned by the DNS server
   queried by the TLS server, although they MAY be returned in
   validation order, starting at the target DANE record, followed by the
   DNSKEY and DS record sets for each intervening DNS zone up to a 

[TLS] draft-thomson-tls-record-limit-00

[Martin Thomson]

I just submitted a version of the draft we've discussed a little on the list.

I don't think we concluded the discussion about what to do about block
cipher padding.

...
A new version of I-D, draft-thomson-tls-record-limit-00.txt
has been successfully submitted by Martin Thomson and posted to the
IETF repository.

Name:   draft-thomson-tls-record-limit
Revision:   00
Title:  Record Size Limit Extension for Transport Layer Security (TLS)
Document date:  2017-03-27
Group:  Individual Submission
Pages:  6
URL:
https://www.ietf.org/internet-drafts/draft-thomson-tls-record-limit-00.txt
Status: https://datatracker.ietf.org/doc/draft-thomson-tls-record-limit/
Htmlized:   https://tools.ietf.org/html/draft-thomson-tls-record-limit-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-thomson-tls-record-limit-00


Abstract:
   An extension to Transport Layer Security (TLS) is defined that allows
   endpoints to negotiate the maximum size of protected records that
   each will send the other.




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

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

[Kaduk, Ben]

On 3/13/17, 12:30, "Sean Turner"  wrote:

This is a working group last call announcement for draft-ietf-tls-tls13-19, 
to run through March 27.  Please send your reviews to the list as soon as 
possible so we can prepare for any discussion of open issues at IETF 98 in 
Chicago.  

As the price of running the WGLC right during the meeting lead-up, my review 
comes in at the last minute.

Generally, it is in good shape.  I think I still owe some text about what we 
aim for and expect to achieve with respect to side channel resistance, though 
at this point it may be too late to get that text in :(

The following is basically a laundry list of the minor issues; I will send 
editorial notes under separate cover, probably as a pull request.

It was already mentioned that the “major differences from TLS 1.2” section 
should not be a changelog, but I agree with that.

Should Figure 4 (“message flow for a zero round trip handshake”) include a “+ 
early_data” for the server’s flight?  (The legend for Figure 4 also lacks the 
explanation for the ‘+’ symbol.)

The language on page 30 is perhaps unclear:

   Because TLS 1.3 forbids renegotiation, if a server receives a
   ClientHello at any other time, it MUST terminate the connection.

Is that any TLS server, or just one that has negotiated and is using TLS 1.3?

In the description of legacy_compression_methods on page 31, we make 
restrictions on “every TLS 1.3 ClientHello”, but do not say how such things are 
identified.  (Hmm, maybe we also do so elsewhere in the document, too, now that 
I search for where)  we explicitly define what a client “considered to be 
attempting to negotiate using this specification (i.e., a TLS 1.3 ClientHEello) 
on page 87, as supported_versions including 1.3.  Which, is maybe not the most 
future-proof thing.

The description of version negotiation (to populate ServerHello.version) on 
page 32 seems to leave undefined what the server should do when receiving a 
ClientHello that does not contain a supported_versions extension.  (Also, I 
don’t think “ClientHello.supported_versions extension” is a well-defined 
syntax.)

When covering the server_random version downgrade sentinels, we do not mention 
what is to be done when downgrading to TLS 1.0, which I thought was still a 
permitted version by this spec.

It’s a little odd that we list in enum ExtensionType on page 35 a strict subset 
of the extensions enumerated in the table on the following pages.

Do we want to add some commentary about the extant SHA1 collisions when we say 
that {rsa_pkcs1,dsa,ecdsa}_sha1 are only SHOULD NOT?

I’ll note that we define 256 private use ECDHE group code points but only four 
such FFDHE group code points.  Probably fine, but a bit surprising.

Should we forbid duplicate entries in PreSharedKeyExtension.identities?

Conversely, we might want to explicitly say that duplicate 
OIDFilter.certificate_extension_oid fields should be expected in 
OIDFilterExtensions, to enable the case where multiple values must be present.  
Or is that supposed to work by concatenating(?) the multiple values’ DER 
encodings in the certificate_extension_values field?

I’ll call out for Russ’s attention at the end of Section 4.4.3 where we say 
that “implementations MUST NOT combine external PSKs with certificate-based 
authentication.”  Is there any reason not to qualify that as some sort of 
“don’t’ do it until it’s defined”?

Should Alert.level be Alert.legacy_level?

The editors copy has already removed the reference to RFC 4507, which is 
obsoleted by RFC 5077 (and was not cited anywhere, anyway).

Appendix B has a claim that “values listed as _RESERVED were used in previous 
versions of TLS and are listed here for completeness”, though that is not 
exactly true, e.g., for ContentType.invalid_RESERVED(0)

Section C.3 notes that “Certificates should always be verified to ensure proper 
signing by a trusted Certificate Authority”, which does not use RFC 2119 
language, but might be seen as in conflict with opportunistic encryption in 
some circumstances.  I don’t object to this text, but it seems worth mentioning.

Page 113 still has the “[[NOTE: TLS 1.3 needs a new channel binding definition 
that has not yet been defined.]]”, which should not make it into the final spec!

-Ben

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