Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05

[Kaduk, Ben]

The one concrete one that I remember (and can't attribute to the HTMLized 
version dropping stuff) is RFC 7030 only in the header.

I guess we can check what we want to do to DTLS as well, as RFC 6347 is listed 
as Updates:-ed but that's the DTLS 1.2 spec.  (6347 itself confusingly claims 
in the body text to "update DTLS 1.0 to work with TLS 1.2" but has an 
"Obsoletes: 4347" header.)  I don't see what specifically we update in 6347.

-Ben

P.S. sorry for top-post; Outlook's quoting options are "bad" and "worse"

On 11/11/19, 12:07, "Stephen Farrell"  wrote:


Hiya,

On 11/11/2019 19:53, Benjamin Kaduk wrote:
> 
> This is a "preliminary" review only because there's some strangeness
> relating to the Updates: (and Obsoletes:) headers, and any changes there
> would make me need to go and recheck the relationship of this document to
> the ones listed.  So, I haven't done any of that yet, in an attempt to 
only
> have to do it once.
> 
> Specifically, there's skew between the list of documents updated in the 
top
> header and the list in Section 1.1. 

Ah, the fun:-)

Will take a look when I get some time, but might be whilst
in or en-route to Singapore. If you've any examples you
noted that might help,

Cheers,
S.


___
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] 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] 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

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Kaduk, Ben]

Unfortunately, Outlook seems to be incapable of properly quoting a message for 
inline replies, so I will have to top-post with the relevant bits.

I’ll try to put together some text on side-channel resistance along with my 
pull request for editorial changes.

With respect to psk_key_exchange_modes, PreSharedKey and KeyShare are enough 
for the existing modes, but my understanding was that the plan with splitting 
the modes out this way was to allow adding new modes in later documents, 
including PSK for server authentication.  Can we guarantee that for all future 
modes we might add, there will be some other extension that indicates what was 
picked?  (I guess we can probably arrange for that to happen with how we 
specify the new modes, so it’s not actually a big deal, but might or might not 
make things more awkward in the future.)

The problematic text about ciphertext length/expansion for tag and other things 
was in the description of the TLSCiphertext ‘length’ field, which says:

   length  The length (in bytes) of the following
  TLSCiphertext.fragment, which is the sum of the lengths of the
  content and the padding, plus one for the inner content type.  The
  length MUST NOT exceed 2^14 + 256.  An endpoint that receives a
  record that exceeds this length MUST terminate the connection with
  a "record_overflow" alert.

(There is no TLSCiphertext.fragment field.)  Assuming it’s talking about the 
length of the “opaque encrypted_record[length]” member (which seems obvious), I 
do not see how the length is the sum of the length of the (plaintext) content 
and padding and content-type octet, since the AEAD-encryption is supposed to 
add some amount of expansion.  Probably the answer is to just remove any 
discussion about what the length represents, since it is not really helping 
anything; the specification for the AEAD in use will specify the ciphertext 
length.

On 11/14/16, 10:44, "Eric Rescorla" <e...@rtfm.com> wrote:



On Mon, Nov 14, 2016 at 8:54 AM, Kaduk, Ben 
<bka...@akamai.com> wrote:

I have reviewed this document and have a few minor comments.  I also have 
many editorial notes that can be addressed out of band.

In the abstract and introduction, we have text about the properties that 
TLS is expected to provide, like confidentiality, authentication, etc.  Do we 
want to say anything about avoiding side channels that might leak information 
about the data being exchanged? 
 I know that we are not 100% confident at what exactly we currently achieve 
in this area, but since we have mechanisms that attempt to achieve it, maybe it 
is worth mentioning.  (In a similar vein, as davidben reminded me recently, an 
attacker “who has complete
 control of the network”, as is our stated adversary, can do things like 
trickle packets in one by one and try to see, e.g., where the end of early data 
is and query handshake state.  So some things may not be avoidable.)




I'd be interested in seeing a PR in this area.





In section 4.2.5.1 we talk about how for FFDH peers SHOULD validate each 
other’s public key Y by ensuring that 1 < Y < p-1, which is supposed to ensure 
that the peer is well-behaved and isn’t forcing the local system into a small 
subgroup.  Somehow I thought
 that additional checks were needed to avoid being forced into a small 
subgroup, but I guess that depends on what group it’s in, and I didn’t pull up 
the RFC 7919 reference when I was reading this document.




These are the recommendations in 7919, I believe




In section 4.2.7, we note that the server MUST NOT send the 
“psk_key_exchange_modes” extension, with the implication that the client must 
observer the types of handshake messages that are subsequently received in 
order to determine what the server selected. 
 I think that we had talked about this already some time ago, but just 
wanted to confirm that we are okay with increasing the size of the client state 
machine in this manner.




It's not subsequent messages. You determine it from the PreSharedKey and 
KeyShare extensions.




In section 4.5.1 we note that when client auth is not used, servers MAY 
compute the remainder of the client-sent messages for the transcript so as to 
issue a NewSessionTicket immediately after the server Finished.  Do we want to 
say anything about why a server
 might wish to do so?




I think I would rather not.





The coverage of record payload protection (around section 5.2) seems to not 
always make careful distinction between TLSPlaintext, TLSCiphertext, 
TLSInnerPlaintext, and the fields therein.  In some sense this is editorial, 
but there were a lot of places that
 I flagged, so I wanted to call it out to the broader audience and get

Re: [TLS] Avoiding Trial Decryption (for 0-RTT)

[Kaduk, Ben]

On 4/2/16, 14:53, "Karthik Bhargavan"  wrote:

>
>Here is a proposal that would avoid trial decryption.
>When the client sends 0-RTT application data, it currently
>ends this flight of messages with an encrypted end_of_early data warning alert.
>How about: if the server rejects trial decryption, the client
>must then send an *unencrypted* end_of_early_data warning alert before
>continuing with 1-RTT handshake data.
>The server could then easily discard all records until it sees this warning 
>alert.
>
>The main disadvantage of this approach seems to be that it reveals to the 
>adversary
>the point at which the 0-RTT application data ends (if this is sensitive 
>information.)
>However, note that if the length of 0-RTT data was sensitive, an attacker
>could probably already obtain it by delaying the server flight.
>
>Does anyone see other practical or security disadvantages to using this alert?

I tried to think of ways that a misbehaving client (or attacker) could cause a 
server relying on the unencrypted alert to consume resources and sit around 
waiting for a long time, but it seems like the unencrypted alert is strictly 
better than trial decryption in that regard (since the server doesn't have to 
burn CPU on decryption).  So, it seems that revealing the length of the 0-RTT 
data is the main disadvantage, but as Ilari notes, there are likely to be other 
channels that would leak that boundary in many cases.

Using the unencrypted alert does also provide a clear indication that the 
client/server failed to exchange 0-RTT data; for a PSK mode with a cache of 
0-RTT sessions this could provide a window into the validity periods used by 
the two parties or as a signal that a finite-sized cache is full and ejecting 
old entries.  Perhaps an attacker could use that signal to determine the rate 
of some other sort of attack that requires getting a session evicted from the 
cache, but the need for such a signal seems pretty hypothetical, given that an 
attacker can already claim to be as many different clients as it wants.

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