[TLS] Fwd: Reminder: Survey on planning for possible online IETF meetings
I thought I would forward this for those would like to participate in the survey but are not on the ietf-announce list. Please take the time to fill out the survey below. spt > Begin forwarded message: > > From: IETF Executive Director > Subject: Reminder: Survey on planning for possible online IETF meetings > Date: May 4, 2020 at 03:03:35 EDT > To: "IETF Announcement List" > Reply-To: ietf108plann...@ietf.org > > This is a reminder that we need the IETF community to help us plan for the > possibility that one or more upcoming IETF meetings in 2020 and possibly 2021 > may not be able to go ahead in person. You can help us with this by filling > out the following survey: > > https://www.surveymonkey.com/r/5328FFJ > > So far we have 114 responses and we would ideally like 500 or more. > > The survey contains the following pages and will take 15-20 minutes to > complete: > > 1. Welcome > 2. Online IETF 107 and the subsequent virtual interims > 3. Replacing a cancelled in-person meeting > 4. Online meeting format and timezone > 5. Replicating humming > 6. Replicating the hallway environment > 7. Fees > 8. Thanks and anything else > > We run the survey in anonymous mode which means that we only see data that > you explicitly provide. > > Thank you in advance for your help. > > -- > Alissa Cooper, IETF Chair > Jay Daley, IETF Executive Director > Colin Perkins, IRTF Chair > > ___ > IETF-Announce mailing list > ietf-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Choice of Additional Data Computation
Hi,
Sorry for chiming in with delay (thanks @Chris for pinging me); I'm not
following the list very closely, feel free to additionally CC me in case.
First of all, let me make sure I correctly understand that
* "on-the-wire header" is what's exemplified in Fig. 4 of the draft
* "pseudo-header" would be a superset, esp. including full epoch, full
sequence number, length, connection ID, ... -- what else?
Further, I understand there is _no_ unique mapping from pseudo-header to
on-the-wire header (as the latter may be compressed in different ways).
The latter, to me, suggests that authenticating the pseudo-header alone
may not be sufficient. It would at least allow on-path modifications to
the on-the-wire header, which I don't expect is intended.
As for the current authentication of the on-the-wire header: We [1] did
an analysis of the record layer of DTLS 1.3 (and QUIC) in which
+ we establish confidentiality, integrity and robustness ("correct
operation under adversarial manipulation")
+ of the record layer deprotecting packets with encoded/abbreviated
sequence numbers to payload fragments
+ under an adversary that can arbitrarily tamper with the packets (in
particular truncate ciphertext, i.e., modify lengths)
+ based on standard AEAD security.
However, our work did not consider
- epochs or key updates (analysis under one key only)
- the full header (only model encoded sequence number entering the AAD)
[- processing of payload fragments into the actual multiplexed data
streams (as in the TLS-related models Chris mentioned [2,3]; this only
applies to QUIC's application interface, and arguably is beyond the
cryptographic operations).]
Our analysis supports the arguments that:
1) The length is implicitly authenticated through the ciphertext itself
-- tampering with the ciphertext, in particular its length, will make
AEAD decryption fail.
2) The full sequence number is implicitly authenticated through the
nonce -- decoding the wrong sequence number will (offset by the IV)
yield a different nonce, leading AEAD decryption to fail.
As said, we didn't consider connection IDs or epochs, but for both I'm wary:
3) Implicit connection IDs clearly aren't authenticated. I'm not sure I
fully understood the concept, but this sounds like a bad idea.
4) I slightly disagree with "epochs determine the key" (true) as, what
I understand is, an argument that "the full epoch is implicitly
authenticated by using the right key", at least in its absoluteness. My
*guess* would be that, due to the key schedule, this argument comes down
to the probability of keys colliding (which is anyway to be avoided, so
probably fine). Still, from a security analysis point of view, showing
security with key updates might be easier if the (full) epoch was
authenticated as part of the AAD.
So, overall I guess my tendency would be to authenticate both what's on
the wire and the reconstructed context. At least from a crypto
perspective, this would be the safest bet. But again, this is
extrapolating beyond what our analyses cover, hence just my two cents.
Best,
Felix
[1] Marc Fischlin, Felix Günther, Christian Janson. Robust Channels:
Handling Unreliable Networks in the Record Layers of QUIC and DTLS.
Preprint for QUIPS 2020 Workshop at https://felixguenther.info/Q20_RC.pdf
[2] Marc Fischlin, Felix Günther, Giorgia Azzurra Marson, Kenneth G.
Paterson. Data Is a Stream: Security of Stream-Based Channels.
https://eprint.iacr.org/2017/1191
[3] Christopher Patton, Thomas Shrimpton. Partially Specified Channels:
The TLS 1.3 Record Layer without Elision. https://eprint.iacr.org/2018/634
On 2020-04-27 02:13 +0200, Martin Thomson wrote:
> A few of the submissions to QUIPS addressed this question for QUIC (which has
> a similar construction to DTLS) and concluded that this was broadly OK. What
> changes is the degree to which we rely on the strength of the AEAD for
> prevention of spoofing.
>
> (I'm sorry, but I can't find the paper that was most directly applicable,
> perhaps Felix can help out. https://eprint.iacr.org/2020/114.pdf does a
> pretty good job, though it is a broader treatment.)
signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Choice of Additional Data Computation
Hi Felix,
Thanks for chiming in!
> First of all, let me make sure I correctly understand that
> * "on-the-wire header" is what's exemplified in Fig. 4 of the draft
> * "pseudo-header" would be a superset, esp. including full epoch, full
> sequence number, length, connection ID, ... -- what else?
Perhaps version and content type, though at least the latter is fixed.
> Further, I understand there is _no_ unique mapping from pseudo-header to
> on-the-wire header (as the latter may be compressed in different ways).
Yes.
> The latter, to me, suggests that authenticating the pseudo-header alone
> may not be sufficient. It would at least allow on-path modifications to
> the on-the-wire header, which I don't expect is intended.
Can we go a bit into this? As mentioned in the original thread
https://mailarchive.ietf.org/arch/msg/tls/VK9e6fA9jdQVFc6tQNWNO8OThU8/
there are some (arguable) considerations of why it has practical benefits
to not cryptographically bind the header _format_ to the record.
Those considerations, however, are secondary to security considerations,
so they didn't surface here so far.
Could we therefore clarify:
Are there any _security_ concerns arising from the modifiability of the
header format assuming the underlying pseudo-header is bound via AEAD?
I don't see one so far, but might miss something. In my head, once the logical
data is authenticated, the entire on-the-wire header merely degrades to a 'hint'
to the receiver as to what the logical header data is, the precise form of which
is entirely irrelevant.
_If_ there are no security concerns (and only then), I'd like to bring up those
secondary
considerations from
https://mailarchive.ietf.org/arch/msg/tls/VK9e6fA9jdQVFc6tQNWNO8OThU8/
regarding modularity, efficiency and flexibility again, arguing in favor of
purely logical AEAD
omitting the wire-format.
> 1) The length is implicitly authenticated through the ciphertext itself
> -- tampering with the ciphertext, in particular its length, will make
> AEAD decryption fail.
> 2) The full sequence number is implicitly authenticated through the
> nonce -- decoding the wrong sequence number will (offset by the IV)
> yield a different nonce, leading AEAD decryption to fail.
Would you expect a change in proof complexity when switching
to explicit length and sequence number authentication in the AEAD?
> 4) I slightly disagree with "epochs determine the key" (true) as, what
> I understand is, an argument that "the full epoch is implicitly
> authenticated by using the right key", at least in its absoluteness. My
> *guess* would be that, due to the key schedule, this argument comes down
> to the probability of keys colliding (which is anyway to be avoided, so
> probably fine). Still, from a security analysis point of view, showing
> security with key updates might be easier if the (full) epoch was
> authenticated as part of the AAD.
Yes, that matches my thinking above - it's probably practically fine, but
a formal argument gets more complex without explicit epoch authentication
because it involves the mapping { epoch id } -> { keys }.
Regards,
Hanno
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
